The problem is that even with a translation layer for block access, flash-based devices have limitations, which means that different usage patterns can dramatically change the performance of the device.

For a (simplified) example, to write a file in ext3, you need to store the new data for the file, but you also need to store other metadata: the location of the data blocks themselves in the inode, the file size in the directory, the journaling data. This means that you have four 'internal block descriptors' open for writing at the same time.

But block descriptors are a limited resource in SSDs, and even more so for low-cost eMMC devices. This means that with only two or three open files with regular writing, you could quite easily lead to some kind of thrashing state, with the device quickly opening and closing descriptors. Since flash memory writing is strongly constrained, this means that a whole block (2 MiB block size is common) containing a descriptor will need to be erased before its next use. As a result, each block only contains little interesting data, and writing only a small amount of data leads to a lot of flash write and erase access. This problem is called write amplification, and reduces both the disk's performance and its durability.

The F2FS design is a log-based design, where all files on the disk share 6 common writing areas, for each kind of stored data, where the information is stored as it arrives. This will have a very positive effect against the write amplification problem, and is an example of how an adapted file system can have a positive impact, even on block-based devices.

Why do YOU lie ? On iOS, Apple is already the gatekeeper and you can't avoid it.

And from their current moves, it clearly looks like both Apple and Microsoft would do it on their desktop environments if they could get away with it. They cannot right now, and the warnings from Notch, Gabe Newell, etc. are clearly there to raise awareness on this issue, and try to foil the OS makers' strategy.

There was an other explanation for the very high price of recorded media in Japan. From what I understood, it was impossible to sell recorded media with rental restrictions, which meant that the price of a VHS/Laserdisc (at that time) was set to what rental shops could afford. As a result, the price was set much higher than in western countries, where you have different markets for rental and home video.

Valve does not prevent a developer from distributing games through any other mean, and there is no lack of concurrence in the Digital Game Delivery market. Self-publication is very cheap, and platforms like Steam are intended for developers that are ready to invest money to respect Valve's conditions, in exchange for an improved revenue through a better exposition to gamers that are used to buy their games.

This is quite different from the current Microsoft and Apple tactics of using their power as an OS provider to extract a "gatekeeper tax" on all programs sold for their platform.

It is legal to encrypt anything in France since 1996 for 128-bit symmetrical keys, and for any key since 2004. While the law was valid for a long time, I do not have knowledge of any prosecution on that basis.

There is a big effort in progress among well-known SoC manufacturers to work towards a unified ARM kernel, as a result of Linus Torvalds's crictics last year. Today, we see Texas Instruments, Freescale, ST/Ericsson and Samsung working to integrate their existing platforms into this new model, whereas the newer platforms - CSR's prima2 for example - are required to use all the new features: Device tree for ARM, the unified clock framework, pinmux, etc. must be used to get a new platform accepted in the mainline.

But for now, there is no sign of integrating the sunxi platform, supporting the Allwinner A10 chip, in the mainline. The available repository for the kernel is based on Linux 3.0.x with Android patches, before the implementation of many of these new features, and there were no attempts to submit the new architecture to the ARM Linux mailing list. This means that there is no chance of getting the A10 supported by Linus's tree before a long time.

Another problem is the sign-off for the commits that need to enter in the mainline. If the A10 support code was written by Allwinner employees, it will be necessary to get their sign-off, as it is required for any code integrated in the kernel nowadays. This means that no third party may commit their code until this is done, even if it is correctly marked as GPLv2. This was added in the wake of the SCO fiasco, to ensure that all source code lines could be attributed to their original writer, and thus have the author's word that it is not copied closed source code.

As long as all these issues are not resolved, the Allwinner based devices will remain second class citizens in the Linux world.

Apple paid $1 billion to Nokia, plus $8 per device for patent infringement because iPhone's technical parts were infringing Nokia patents. And that is for real, hardware patents, not bouncing menus or pinch-to-zoom. Apple is as much guilty as Samsung may be, and I really wish Nokia went all the way and refused licensing instead, to give Apple a taste of its own medecine.

There may have been other reasons for this issue, as a misconfigured enviroment, but I can assure you the I have encountered this kind of problem...

A single example: the "make xconfig" tool for the Linux kernel requires a specific variant of the QT toolkit to build, and the correct variant is QT3 for 2.6.32.x, while it is QT4 for the current dev branch. If the build environment points to the wrong QT version, the build will fail with cryptic messages, which means that you would need to sandbox your kernel compilation to compile both on the same machine. Of cource, most of the people in this situation uses the "make menuconfig" option, that uses libcurses in a terminal emulator instead.

I don't know whether this is a problem with the kernel's developpers or a general QT3/4 problem, but this is for sure a bad situation, and I expect that other projects have had the same kind of issues (forward & backward incompatibilities on the source level) with QT.

The "concatenated SMS" protocol, which removes this limit in exchange for a higher message count, existed before twitter started to be relevant: It is defined in GSM/3GPP release R99, which was already widely deployed even in low-cost devices in 2006, when twitter was created.

The newest Renesas application chips are based on ARM, with a SH4 core only as a coprocessor, so this particular monster will probably never exist.

Do you realize that the chip on the other end of a SATA link - typically the controller in the SSD you're using right now - has a lot of chances to be an ARM chip ? It is the case for common SSD disk controllers (Marvell or Sandforce).

And even if it is not common in today's products, there are a lot of recent high-level ARM SoCs that offer SATA - not least because its low pin count makes it easier to route on the board in the end than a parallel bus. For example, TI's OMAP5, Freescale i.MX53 or CSR's Prima 2 have SATA support.

Given that UTC dates from 1961, and that the leap second concept comes from this, it rather means that a lot of coders are dealing with time without being careful, rather than a fault from the astronomers, who mostly use TAI (without the leap seconds) anyway.

Leap years, daylight saving time, local calendars, all those are also complex issues that need to be taken into account when writing software that needs to correctly handle time. And this is before taking into account the issues brought by the hardware, as clock drift, RTC limitations and integer wraparound, that need to be addressed by the OS developers.

All this means that when it comes to time, most developers should leave it to the OS and language libraries. And those implementing these libraries should take their work seriously, because time is a complex matter, as Y2K and the current issue remind us.