The Intel bits are vanilla, but even Intel don't make all the components on the board. I've got an Intel DX79SR, and its USB3 controller is by Renesas (formerly NEC). The USB3 controller has a firmware bug (that pauses the machine for a minute during every boot), which can be fixed by updating its firmware. The firmware can only be updated from Windows -- not just DOS but real Windows. I downloaded one of those (surely hooky) Windows rescue CDs, but even then the firmware updater refused to run, saying that "OLEDLG.DLL" wasn't found.

Thing is, I know what OLE is, I know what a DLG is, and I even know what a DLL is. And I know that there's no damn reason on earth for a firmware updater to need any of those things.

Peter

It's not that they're broken in themselves, it's that they've been added to a language that can't support them properly. People say, oooh, you must write exception-safe code. What they're saying is, there's a property the code needs to have, which a compiler cannot test for, which you can't even easily unit-test for. And without this property -- exception-safety -- the code is unsafe. (It's not the code that throws or catches exceptions that you need to worry about: it's routines whose callees might throw and whose callers might catch. Those routines have secondary control flows through them, ones you can't see, but which need to be correct for the program to be safe.)

It's not an innovation of the TDD community to say, that if something in your code isn't tested, you can't swear it works. In particular, you can't swear it will continue to work when future maintenance occurs. Because exception safety can't be "defended" against future breakage, I don't think you can hand-on-heart deliver C++ software written with exceptions and claim that it works.

I'm not against exceptions as a programming technique: I think they work great in managed languages such as Python, Java, or ML. In those languages, it's not possible to write code that isn't "exception-safe" in the C++ sense. That's where exceptions belong. Throwing exceptions through unmanaged code was a brave experiment on C++'s part, but it's a misfeature, and I've got more confidence in codebases which forbid that (despite whatever problems they have with two-stage initialisation) than codebases which don't.

Peter

Nor this http://survex.com/~olly/rheolism/: real Tetris in one line of BBC BASIC, 255 bytes after tokenisation. All the shapes are stored in one 32-bit constant. It's just amazing.

Peter

This is basic stuff to anyone who actually maintains a build, but Slashdot hasn't been a forum mostly populated by engineers for a number of years, now.

This appears to be due to link-time optimization blowing up the resident memory size of the linker, taking it past 3GB (which is already a non-standard hack the 32 bit build has had to do). Firefox is large, yes, but this has nothing to do with the final binary - which appears to be about 100MB total including all libraries in the Aurora builds.

I used to routinely run out of 32 bit address space compiling executables for a 64MB embedded ARM platform. This was due to symbol bloat, not executable size (which was 8MB). I also ran out of space compiling for a DSP with 288KB of RAM and 1MB flash, but that was mostly piss poor tools (Tasking). In fact, doesn't Chrome and even the Android sources already require building on a 64 bit host?

I don't have to explain:

Theora really can't even compete with MPEG-1 on either video quality at a given bitrate, or performance. It was very specifically designeed for extremely low quality, extremely low resolution, extremely low bitrate streaming video, over a decade ago...

This isn't true. There's plenty of results out there which say Theora is, while not the best, a good codec. To quote Wikipedia: More recently however, Xiph developers have compared the 1.1 Theora encoder to YouTube's H.264 and H.263+ encoders, in response to concerns raised in 2009 about Theora's inferior performance by Chris DiBona, a Google employee. They found the results from Theora to be nearly the same as YouTube's H.264 output, and much better than the H.263+ output.

There are plenty of people proclaiming that because it doesn't come out top, it's useless. Theora is far from useless: the results in any scenario that H.264 (even main profile) would be used, are still usable if you select Theora instead. They just aren't as pretty, because it's just not designed to the same constraints as H.264.

Becoming the HDTV standard would be an unrealistic goal. You attribute Theora not becoming the dominant standard due to Xiph's mishandling of the codec. The more obvious reason is politics: the MPEG group exists specifically to create audio/video standards which can be licensed. Broadcasters and content providers generally only use MPEG standards, and they just love licensing.

I'm interested to know what your theory is that Xiph could drive HDTV standards and have handled this better than a small company could?