This is true for any technologies of flash and also true for hard disk track. To read something from any media, a small energy transfer is required. It could be very small, but there is always a certain quantity involved. Any media need a refresh after a certain read quantity. For the record, even without read, any media tend to loss energy, mainly due to the thermal agitation and ambient radiation. Certain flash are specified as over 100 years retention time: this is a lot but far from the infinity...

Thanks for the correction. I am not an English speaker.

Actually the reality is that the contents creators are locked by the fact that a few majors manufactures refuse to support free formats.

Now there is a category of people so disconnected from reality that are ok to overpay an already excessively rich phone manufacturer that refuse to support free format, and there only reaction to there frustration is to ask a poor free project to support commercial format. I wonder how many of them have donate something to Wikipedia.

But I am not so surprised. I have observed many times that a lot of people tend to be proud of what there have payed and disregards what there have not payed, even when the reality clearly show that there money was not worth the result. It's a childish behavior to ask others to fix your own false choice.

Sorry but I strongly disagree with you point of view.

A lot of networks settings for example are still into /proc/net. There are not hardware dependent and a lot of them can be acceded in write mode. A lot of different programs or library use them, especially if you build routers like I have do in a early workplace. Just look at how many API and codes exists to simply do a DNS query...

The /proc interface will stay almost forever because it is too deeply part of the UNIX history, but it really a mess after decades of erratic evolution, especially in the Linux kernel that initially put almost anything into it before trying others ways.

In more than 20 years, this is the first time I hear about VSS. Hopefully since according to Wikipedia this was a Windows only product since this time. RCS was the dominant tool in my field of work when I started.

You can always make things different, but this add complexity for the others. having something in common help the grow of communities. Mercurial don't bring any clear advantage over git, but have the big problem that only a few people know it. So peoples that wants to contribute to a project using Mercurial have first to learn Mercurial, and this was not there primary goal. The probability that an user have to learn git only for a project is actually far lower than for Mercurial.

Almost any large project includes peoples with different culture. But there use it to merge new features instead of creating an other project that will never get enough audience to change anything but add complexity to potentials users of the features.

For the same reasons.

Take a look at the reality:

linux$ for i in $(find ./ -mindepth 1 -maxdepth 1 -type d); do r=$(find ./$i -type f -iname "*.c" -print0 | wc -c --files0-from=- | tail -1 | cu)); printf "%16d\t%s\n" $r $i; done | sort -rn
              176570632 ./drivers
                39285154 ./arch
                25360678 ./fs
                16726520 ./sound
                16270981 ./net
                  4178246 ./kernel
                  2149028 ./mm
                  1321702 ./security
                  1196376 ./crypto
                  1138780 ./tools
                  1061679 ./lib
                    789517 ./scripts
                    518658 ./block
                    224637 ./Documentation
                    185020 ./ipc
                    132264 ./virt
                      73918 ./init
                      42353 ./samples
                      12747 ./usr
                        6731 ./firmware
                              0 ./.tmp_versions
                              0 ./include
                              0 ./.git

The fact that modules are optional make the Linux kernel no so monolithic. It also use a lot of kernel threads that can be more or less see as services in a microkernel architecture. You can argue that is't not as fun as a microkernel, but if you want to do with microkernel services all what Linux do, you will probably end up with the same order of code quantity.

Sorry but your "finding" really don't match with the reality: http://lwn.net/Articles/551969/

Sorry if it's hurt your sensibility: this was not my intention.

I thought it was a correct response to the "Linux isn't being engineered anymore" statement.

I actually found Avahi extremely well implemented. It work exactly as expected and I never have identified any problem with it.

I am afraid that the future will make your dbus-free system more and more challenging. I do a lot of embedded system and the dbus-deamon is so critically important that nothing will work without it.

http://www.phoronix.com/scan.php?page=news_item&px=MTQ5NzQ

Exactly. A new standard is not the solution.
Putting DBUS in the kernel has the merit of making an existing good and long established standard available to a wider range of communication demand.

Standard package of dbus should already contain the dbus-monitor and dbus-send commands.
If you want an easy tool, try D-Feet https://wiki.gnome.org/action/show/Apps/DFeet?action=show&redirect=DFeet.

ps and netstat only show the current state. You need very different others tools to modify the state or to dynamically monitor the state transitions. From this point of vire, DBus if far more generic, coherent and cleaner than a lot of others tools.

You can use your own conclusion, but Linux was always driven by the masses of engineers that work on it. There is no other kernel project with so much authors. And this is precisely what make it so successful.

Now if you think that Linux is not a good engineering work, a lot of peoples will be more than happy to learn from you how to make it even better.