Why not use system codecs? Because you're not solving the original problem. The problem was dependency on externally variable code that was frequently proprietary to render the web. Instead of requiring Flash to view websites in a default web browser, now we'll require K-Lite Codec Pack Max Extreme 2.0++?

Which codec would you use? Theora isn't implemented on most systems. h264 won't work on Windows by default (7 will, but that's just a small portion of the market). VC-1 won't work on Mac and Linux. MPEG-2 isn't even guaranteed to be found.

Congratulations...you've just opened a whole 'nother can of worms.

I think the contribution of Nielsen's idea, if any, is to remind us all that security always involves tradeoffs. You're right that masking passwords provides some protection--most security measures, even the inane ones, provide some protection. You know, someone really could hide a bomb in their shoe.

But of course that is not the end of the story. Nielsen, and others such as Bruce Schneier, want us to ask how much security the solution provides, what the costs are, and whether it provides a good tradeoff. If shoulder surfing is relatively rare, and the possible harm for the site in question is small, and the costs are relatively large (lost customers etc), then maybe a site or program shouldn't mask passwords even if they provide some security.

Sure, Jakob Nielsen may be wrong about the tradeoff in this case, and may not have enough evidence to back up his arguments, but I would argue that pointing out that the solution provides a nonzero amount of security does not resolve the question.

That's not true at all. Firefox, since 2.0, has had memory caching just like Opera does. Go to about:config and tweak how much is used (which is default-set based on your system capacity, just like Opera). It's called "browser.cache.memory.capacity".

I understand why they don't agree with the practice, but this is hardly front-page Slashdot news. The summary is, if anything, very misleading. This has NOTHING to do with Mozilla's plans for HTML5 or web openness, it's everything to do with some nameless blogger disagreeing with another nameless blogger's implementation of video fallback.

This is non-news, to say the least.

Some random Mozilla Hacks (note the word Hacks) blogger posts some code that web developers can use to implement HTML5 video (which does not use javascript, contrary to the implications in this article and summary?) and also provide a fallback path for non-HTML5 Video browsers (IE, Opera, etc). Their particular method of providing the fallback code uses javascript to determine browser capability, and uses Flash if HTML5 Video is not there.

Why is this upsetting to anyone? The implication from the summary is this is a less "open" way to do it, but last I checked Javascript/ECMAScript is a standard that all browsers implement already.

I cannot fathom why anyone would be so upset by some blogger providing JS-implemented video fallback implementations.

Have you heard of IP over DNS? The DNStunnel software sends IP packets as TXT records over a real DNS, the client sends data in the request itself. Since these are real resolvable DNS records, proxying port 53 won't work. When I tried this software, I could only get a single stream over the tunnel, so I ran SSH over the DNStunnel and used ssh to forward a TCP port that I then ran OpenVPN on. This actually works, but it is very slow. And I can imagine that people would eventually find out because the wifi provider's DNS cache will fill up with IP data.

Firefox 3.5 implements the majority of those. IIRC Webkit and Safari are almost there too, and even MS is making a sprint to HTML 5 -- IE8 has started implementation there.

As for editors, yes -- they are under development.

Apple was far from the first company to implement multi-touch, it's just the first people think of. Multi-touch, and its patents, go back for quite a long time.

By definition, a superscalar processor does not need to be instruction re-ordering, speculative execution, or branch prediction. All a superscalar processor needs to do to be called superscalar is to dispatch more than one instruction per clock cycle to redundant functional units on the processor -- the 360's CPU is absolutely superscalar.

Incidentally, you are incorrect other aspects anyway: the Xenon cores DO have branch prediction, just in a significantly diminished capacity compared to what we're used to on the PC (small history tables, simpler logic, etc). The Cell's SPEs have none at all, and rely on "branch hints" instead where the programmer or compiler specifies which path may be likely at any given point. As a result, it also has speculative execution.

But you are correct in that the 360's CPUs -- like the Cell's PPU and SPEs -- is in-order and thus does not re-order instructions. It is up to the compilers to generate optimally ordered instructions, which isn't as big a deal as you may think on a closed-box system with optimized compilers. Back in '03-'04 I worked in IBM's compiler group on this very thing.

While it certainly sounds like you know what you're talking about, it's pretty clear to anyone with a game-dev background you do not.

Cell's SPEs are actually PRIMARILY used as aids to graphics processing (T&L) by most developers. Look into how games like Heavenly Sword use the SPEs as part of its "faux" HDR or games like Killzone 2 use SPEs to implement deferred rendering for awesome smoke effects. The SPEs are, in PRACTICAL TERMS to PS3 game developers, very essential to the 3D rendering side of the console.

While RSX is "powerful enough" to do its own T&L, it cannot compare to the standalone power of the 360's Xenos chip. There are many reasons for this (6 fixed vertex shaders on RSX vs the unified shaders on the 360 which permit far higher vertex workloads, to the RSX's limited bandwidth vs the 360's eDRAM bandwidth, to triangle setup rates). On the PS3, developers need to leverage Cell in intelligent ways to draw comparable graphics to the 360. If an intelligent and determined PS3 developer really leverages Cell, it can make unparalleled graphic in the console world. The problem is, it costs a fortune in time and money to do it and very few developers can. It's simply not worth it to even attempt it for most developers.

As a sidenote, Cell is not at all good for most game AI for many reasons (not the least of which is the lack of branch predictors in the SPEs).

Additionally, people keep making the mistake of assuming the PPU in the Cell is basically the same as each core in the 360's CPU. That's not at all true. There are some significant differences, including native Direct3D format support in the 360's CPU to the new VMX128 vector units (which have 128 registers per context per core [6 total], vs 32 on the PPU) as well as additional instructions specifically tailored towards 3D games (like single-cycle dot-product instructions). The combined triple VMX-128 units on the 360 are still faster than most quad-core Core i7 in vector processing, so I'm perplexed by the notion that it's somewhat slow or underpowered from what I've read from some people.

If you're truly interested in how PS3 games use Cell, check out the Beyond3D community where PS3 developers post in detail about how they do what they do. And Cell is a major factor in 3D rendering on the PS3. It has to be.

Surely not any more ridiculous than having to re-code your applications in Objective C and having to deal with Cocoa.

All administrative functions and duties under this title, except as otherwise specified, are the responsibility of the Register of Copyrights as director of the Copyright Office of the Library of Congress. The Register of Copyrights, together with the subordinate officers and employees of the Copyright Office, shall be appointed by the Librarian of Congress, and shall act under the Librarian's general direction and supervision.

a. The keeper of a register; a REGISTRAR. (In common use c 1580-1800.)