> Fact of the matter is, most people cannot do science.

Fact is, most people can do science. While few will have the tremendous insights of an Einstein, most people can observe, record, and _verify_ data, and especially note and report details that don't match the models they understand. That data gathering and verification, and that concern for data that does not fit the model, is a vital part of science that almost every human can participate in.

> Women with actual skills and insights have no problems in the sciences

Nonsense. There is a constant undercurrent in the hiring process of "what if she gets pregnant", even if such bias is outlawed in many states and even if it is never written into candidate review, much as "don't hire Americans, they cost too much" is not explicitly written into hiring policies. The bias is also demonstrated both statistically in overall hiring, and by numerous repetitions of the double blind experiment on scientific papers and job applications, such as:

                    http://blogs.scientificamerica...

They made the distinction, and I agree they used the wrong verb. Perhaps "pillage" would have been better, since they suggested that other galaxies are stealing the hydrogen fuel sources.

If you can't read it in flat text, it's not long-term reliable documentatoin.

Even L1 and L2 lunar orbits are not that stable without attention. Solar forces, such as light pressure and solar wind, tend to destabilize them over time and require station keeping, especially as satellites have low mass and large solar panels.

There are other difficulties for satellites. The increased radiation of all types and even magnetic effects from the Van Allen belts can be very hard on circuitry. Adding shielding is very expensive, and over time even the shielding can become slightly radioactive itself. So I'd be very surprised indeed if any of our current satellites lasts even a single human generation.

The Volkswagen Beetle from the Woody Allen movie, "Sleeper"

        http://www.tin.org/bin/man.cgi...

More realistically, some chemical batteries, such as good lead-acid batteries in cool, dry climates will retain a slight charge for years. But they all have a notable self-discharge rate of at least a few percent a month. The notable exception among battery technologies seems to be this:

        http://en.wikipedia.org/wiki/O...

That device has been running off its battery, at an extremely low rate, since 1840. The bell is much softer now, but it shows no signs of failing.

Those are "the systemd requirements for the filesystem", what systemd needs. It provides no clarity about what goes _in_ those directories, nor why, Compare this checklist with the actual FHS documents, and you'll see the distinction. The result is confusion, such as the systemd migration of "/media" attachable storage to the individual user's owned subdiroectories in "/run".

Allow me to restate your comment:

> Systemd will continue to work for Linux distros that don't care for stateless boot etc

Rather, systemd will continue to re-arrange, and break, stable subsystems without warning to the user communities. OTher examples abound. For example, the new replacement for /etc/resolv.conf says at http://www.tin.org/bin/man.cgi...

          Note that /run/systemd/resolve/resolv.conf should not be used directly but only through a symlink from /etc/resolv.conf.

Who's going to maintain the symlink? If any sysadmin unsuspectingly edits that file directly and breaks the symlink, or exposes their system to puppet, cfengine, chef, or any other system tool that manages /etc/resolv.conf, does it break the link? And what restores the link if it's broken? If the link is broken, DHCP updates to /etc/resolv.conf will no longer be effectively published by the sytemd based DHCP client.

I'm not even going to mention what happens if you accidentally follow generations of sytem standard behavior and install NTP alongside an active systemd NTP daemon. It's not a pretty site, and the accumulated clock management confusion if they're not pointed to the same NTP servers can break Kerberos authentication in startlingly short order.

Until they publish a standard for the layout changes, they're winging it. There is no document that I can find that details the overall changes: it's all "read the code" or "I announced it on this mailing list that only a few people read".

I'm http://www.linuxbase.org/betas... open in front of me.

Mountpoints for removable media are specified as going in "/media", not under "/run/l[whatever]/[userame]/media". While revising this now allows the attached to be mounted under a subdirectory belonging to a particular user and keeping other remotely connected users off the attached media, it creates additional complexities sharing that media. It can be made to work, but it destabilizes the path to the attached media.

For "/run", the FHS says : "This directory contains system information data describing the system since it was booted. . Files under this directory must be cleared (removed or truncated as
appropriate) at the beginning of the boot process." If the systemd authors were folowing the FHS, they'd have to delete the contents of /run on reboot. Not remount them: delete them.

This is one of the typical problems of systemd: they are really making up their own standards and practices on the fly, in violations of anyone else's existing standards. New approaches can be beneficial, but many of the consequences are unclear, and it's breaking stable system software, and existing standards, everywhere.

> Millions of people around the world paying small amounts of money for iOS apps

Mostly, it shows that it can't be done. Most of them go bankrupt as soon as they try to scale beyond a few intrigued users.

Unfortunately, systemd has elected not to work on top of the existing standards. It is breaking everyone else's stable tools though unexpected and unannounced modifications of basic layout.

Then they should have published a proposed FHS. They're making this stuff up on the fly: putting detachable mountpoints under "/run", for example, was quite confusing: I can name more instances if needful.

I missed the part where you mentioned "on top of", excuse me.

The part about how Java error logs tend to spew errors without any indexable reference means you have to add your own. That is, in fact, what Splunk does.

Restarting the same daemon, insistently, without the userland opportunity to manually restart the daemon log or wrap it in a debugger.

Because those databases bulk up, they get corrupted, and then _all_ logs are lost, not merely the specific utility's log file or particular time-stamped, rotated log file.

Been there, done that, had to help clean up the mess that a certified Splunk admin repeatedly made of the Splunk logs. He kept failing to realize that there are many distinct logs which have unique individual formats, and which can overwhelm the Splunk servers very quickly when they start spewing in erronesous states. This is especially of Java servers, which spew the java error codes without oranizable or easily indexed time stamps.