fflush is unrelated to the business of flushing data to disk. It's just a libc FILE* thing. It causes libc to empty the (typically tiny) stdio buffer associated with the FILE* using the write() system call.
Good to see this summit involving the kernel developers, since their past situation sounds rather bleak interaction-wise: using kernel version from 2009 and haven't tested the improvements in the (2012) 3.2 kernel.
BTW, Linux provides the direct I/O O_DIRECT interface that allows apps to bypass the kernel caching business altogether. This is also discussed in Mel Gorman's message that this blog borrows from.
This is a common technique so no surprise they are similar. However, there seem to be slight differences in the way the chunk edges are made seamless.
In Trigger Rally, there are additional vertices being added to the lower LOD chunk side of the seam to avoid T-junctions in the mesh topology.
In the OP demo, the vertices on the higher LOD side of the seam are morphed so that they will be flat with the lower LOD side of the seam. This should also help reduce "snapping" when moving to higher LOD levels.
This is fiction. At best (long journeys) planes have per-seat co2 emissions comparable to an entire 5-person car, that's 5x. On journeys where planes actually compete with cars, double that. Add to that the 2-4x multiplier (greenhouse effect of co2 injected into upper atmosphere vs ground level).
Mercury is used in production with PrinceXML  and ODASE . ATS is used in production in the implementation of a bitcoin mining pool . OCaml is heavily used by Jane St . SML (via the MLton implementation) is used in industry . Rust is not ready for production, I agree, but is being used to develop Servo by Mozilla and Samsung .
That said I'd hope that systems like ATS, Mercury, MLTon and OCaml being open source make it easier to contribute to the implementation for issues that come up and this would offset any 'not enough real world' problems that they have. If you don't like those languages, pick another (eg. Haskell).
Another early system programming language: CMU Bliss. Bliss was used to develop operating systems within Digital Equipment Corporation (DEC), including VMS / OpenVMS.
If anyone here is interested in experimenting with a Bliss compiler, there's one installed on the gein.vistech.net VMS server, and there are free accounts available there. Visit http://deathrow.vistech.net for account registration details.
FWIW, the UCSD P-System and p-code and the Pascal compiler was easily portable, but the tools were also very buggy (at least) on the Terak boxes, and — even for the era — very slow. Folks were always working around some bug or another, or some slowness.
It's not just bugs and slowness. At least in those days, Pascal had the size of an array as part of the type of the array. This meant that you could not have a variable-sized array, because you could not give it a type.
True story: I took over a numerical simulation on a 2D grid that ran slowly, because it implemented the 2D grid as a linked list. If you wanted to refer to the node directly below the current one, and the grid was 60x60, you had to follow 60 links to do it! I looked down on the guy who wrote it as being somehow hung up on linked lists, like it was his favorite data structure from school or something. Only later did I find out that he had no choice - he couldn't allocate a variable-sized array. So we re-wrote it to allocate the biggest array we had memory to hold, and to only use part of it.
But if we were trying to write a portable operating system, or something of that sort, our kludge would not have worked. Allocating the biggest possible size needed is not good behavior for an OS...
It will be a sign of things to come to see how many releases are supported on the first-generation Firefox OS phone that I have (ZTE Open). This doesn't mention it, and a quick Googling doesn't show any positive signs... anyone know?
I am quite sure that backwards compatibility won't be an issue. As you may know Firefox OS is aimed at low-end phones, so I don't think they plan on ending support for first generation phones… ever?. The only issue is the manufacturer, which has to take care for the Firmware updates for his own handsets. ZTE doesn't look very eager to give its users constant updates.
I guess it will take some time for ZTE to provide 1.3 for their phones, because v1.3 is in pre-release stage for the moment. ZTE took quite some time to provide v1.1, but then 1.2 followed quite quickly .
Any open source replacement for the Raspberry Pi GPU driver is going to rely pretty heavily on reverse engineering too. The code they've released runs on the VPU, a custom-designed scalar processor within the VideoCore IV that Broadcom still haven't released architecture documentation or a toolchain for. Without a whole bunch of low-level reverse engineering (much of which was already in progress) it won't even be possible to compile the stuff Broadcom have released. Without working VPU code you can't even boot the Pi, let alone make use of graphics.
That's not correct. The code that's been released is for BCM21553, which doesn't have a VPU. There are bits and pieces of VPU assembler in there, but they're unused on the ARM target. The intention is that people port this (ARM-based) drop to run on the ARM on BCM2835. No reverse engineering required.