I want people to get off this planet.

Why? What do you think is within the reach of human beings in space that is not available on Earth? A reply containing the words "wonder", "exploration" or "adventure" are not acceptable.

Space is mind bogglingly large but despite that the Earth is fucking huge. Helpfully it's also absolutely drenched in the sort of things us humans need to survive. With a bit of preparation we can readily travel to just about anywhere on the surface of the Earth. To simply survive we don't need to bring significant amounts of our home environment along with us.

The Earth is also jam packed with resources. The idea of mining asteroids and comets is laughable. It's ridiculously expensive to actually do and nowhere even remotely close to being cost effective. It's not even a question of profitability, it's simply wasteful to expand the resources to mine a single asteroid when a single mountain on Earth is far more accessible and likely has a much better yield of industrially useful materials. It simply does not make sense to pay thousands or millions of dollars a pound for carbon, ice, or silicon (the primary component of most asteroids and comets). Even for space based industry, launched prices of a thousand dollars a pound means it's more economical to build stuff on Earth and launch it into space.

The idea of "spreading out the species" is another very silly idea. It would take a ridiculous amount of resources to build even a remotely sustainable colony somewhere else in the solar system. There's simply nowhere else in the solar system where humans can easily survive. Even with a self-sustained colony on Mars the odds of humanity being wiped out by a natural disaster (asteroid, etc) aren't significantly improved over all of humanity on a single planet. Without a full ecosystem a Martian colony would eventually die out, likely long before they were able to build their own means to spread to other planets.

While the Martian surface temperatures are fairly low (~63ÂC) the atmosphere is also incredibly thin. At the surface the atmosphere is about 1/100th the density of the Earth's atmosphere. This means the ability for the atmosphere to convect heat away from a spacesuit is 1/100th that you would expect on Earth.

The occupant as well as the electronics and other powered elements of the suit all need a way to bleed of waste heat. A small heat sink on the back might work on the Earth but would need to be much larger to work as effectively in the thin Martian atmosphere. A spacesuit can't "breathe" like insulating clothes would on the Earth.

Such a cooling system likewise needs a method to be shut down or reversed in order to keep the suit's occupant from freezing to death if the outside temperature dropped significantly like in a shadowed valley or at night.

Where does it end is not an argument.

"We won't let 3 year olds drive cars? Where does it end?"

Loading movies and music on a computer is something older geeks do but hardly anyone else. Everyone else is using online services like Netflix, Spotify, and Vudu and just renting/streaming. This is especially true for the college age crowd the Stream and Chromebooks are marketed towards. They're sitting on gigabit Internet connections in their dorms so cloud storage is a no brainer for them.

For anyone wanting to use a Chromebooks or Stream PC as a backup laptop it's cheap to pick up a high speed SD card with a lot of storage. for most tasks they have plenty of power. Loading up a browser with too many extensions is problematic on any machine, not just low end ones.

Depending on the accuracy obtained, such mapping would be highly useful on our farm for figuring out drainage. Some areas of a field might drain better with only a very small slope, if we knew where to put the channel. Currently the only real option is to drive over the field with an RTK GPS receiver and make a GIS map of elevations. Which works well enough (depending on the grid resolution; can get really old driving every 10 feet over 160 acres), but takes quite a long time to do.

Yes that's good practice for any command. Though wget is used behind the scenes by, say, opkg on openwrt boxes, which has to run as root since it's unpacking and installing packages. In fact on embedded devices, most everything runs as root there, typically, even if it's a bad idea, and is going to have to change as the internet of things becomes a fact of life. Never thought I'd need to run selinux on an embedded device, but we're to the point now where that's required.

It's good to have this particular bug fixed at least.

Init scripts work just fine in systemd, and will for as long as there are init scripts. So vendors and apps *can* provide systemd service definition files, but they don't have to. It's backwards compatible just like upstart was in RHEL6. So no there's not a loooooooooong drawn out process to make it work. I'm running a debian box right now with systemd and everything is still in init scripts.

I can tell you haven't used systemd then. It doesn't use a registry at all. And services run in the same manner as they do with the init that you're used to. Talk about FUD.

Good thing systemd works better than my own editing skills. That should be something along the lines of "[because of your question] it's readily apparent you have no clue about systemd."

Today, the competent administrator can control startup, dependencies, etc on a granular basis. With systemd, that control has gone - somewhere else.

How so? Systemd has removed my ability to start and stop services?

How would a package mess with systemd's configuration? It's readily apparently no clue about systemd. Hint, it's no different than it was before. A package drops its own service definition file in a directory (sound familiar?). That's it. It's no different in this area than any other init system. If the file is bad, the service just won't start. Just as it was before. Runlevels or targets are defined the same way: with simple symlinks. Really in this aspect, systemd is no different than upstart or plain old system v init.

This post is one example why the debate gets so heated. People like you post stuff that's only nearly half true, without knowing anything about systemd, except the name of one of the authors. FUD plain and simple. A technical debate is fine, but you've got to actually know what you're talking about before you start debating. So far I've seen zero technical debate on this site regarding systemd. Certainly no one is willing to own up to the flaws in traditional init that have led to systemd's development. It's extremely disheartening to see this kind of irrational fear instead of technical discussion.

What Red Hat does is between them and their customers, plain and simple. People can complain about freedom of choice all they want (hint, you still have it), and you, as an experienced admin, are free to plot your own course.

I don't believe Red Hat has made this move on RHEL 7 in error. I think they have a pretty good handle on their customers and their needs. From what I can see on the RHEL lists that have many professional admins, there's been no hue and cry, no sky falling, etc.

I'm not quite sure what a "veteran administrator" is that the article speaks of, but I managed a fair number of servers professionally for quite a few years and I have no problem with systemd. It works stably and well (and no a reboot is not required for most updates as the daemons can be restarted on the fly if necessary). As I've said on many occasions, I've had race conditions completely stop boot scripts in their tracks before (pre-upstart RHEL). Any talk of a binary log is a red herring, plain and simple. Running CentOS 7 right now and syslog is still there, logging away to a normal log file. If one wishes to use it, there is journald to pour through when you need greater granularity and detail in debugging a problem. That has the potential to be of tremendous value for system administrators when tracking down obscure bugs and problems. The traditional syslog is still there to satisfy the record-keeping needs of many organizations, possibly under law in some cases.

As for the unix philosophy, init systems pre-systemd hardly did just one thing and hardly did it well.

How does systemd remind you of windows? Have you actually *used* either in a system administration capacity?

What does SSL have to do with it? As you say yourself, as long as you are checking the signing key on each package, you can guarantee that the package is intact and genuine, not matter what the MITM tries to do. The worst that happens with http is that someone can determine which file you downloaded. Hence the injecting of malware can't happen to Linux packages (if the private key is secured by the distro maker). Couldn't happen to any signed executable either, but on Windows users often blindly allow programs to run even with bad signatures.

Obviously there is a way, since their malware driver was detecting it and *then* changing the pid to 0x0000. In fact you can see source code for this that someone posted to the Linux Kernel Mailing list a few days ago. Hopefully the new driver will do exactly as you suggest, though I think a big warning message box saying that the device is not genuine, but continue to function might be enough for end users to let companies know their devices are using the fake chips.

Well the fact of the matter is that Google is only interested in making sure their app store is the only trusted store. The choice to make it all or nothing was deliberate on their part. They could easily have implemented user-selectable trust of signing certificates. Granted 90% of android users don't even understand the problem, let alone the solution.

Still, though, this vulnerability appears to be firmly in the area of social engineering because why would I want to download an encrypted image file that requires another separate, random app to decrypt and view it?

So you know the majority of system administrators? That's an awful lot of people.

I follow the RHEL mailing list and there are a lot of very smart sysadmins on that list, and none of them have expressed any concern or even comment about systemd. And it's certainly shipping, and it's been on the roadmap for some time. In short, for many people it's a non issue.

This is, by all appearances, a tempest in a teacup, mostly existing here on on slashdot, where groupthink has moved against systemd without any real argument against it other than mumblings about philosophy, or theoretical problems that haven't been shown to even exist in systemd.

If these "supervision" frameworks of which you speak were redundant, then why do they exist in the first place? Clearly system v has had some pretty big limitations. I've personally hacked many a cronjob to supervise processes started by sys v init scripts (some of the init scripts I wrote myself... yuck). Also as servers move into virtual space, and deal with hotplugging of various resources, it just wasn't enough. Took years to get consistent naming on network interfaces, for example, and even then I could never be sure which interface was which when I first brought them up (they usually followed motherboard numbering, but not always). To say nothing of adding other hotplug interfaces of different sorts. Even after the udev hacks brought some sanity, every time I'd change out a network card, or clone it to a new system with a new MAC address I'd have to either delete the udev config for it, or have it change to eth1, eth2, etc. And by the way, it's not even systemd that does all this now, it's systemd-udevd. So it's still modular and you could replace systemd with uselessd, and then run a separately-packaged udev.

It's also telling that other major commerical Unix vendors (say, Solaris, for example) have abandoned sys v init as well, or at least abandoned shell scripts as part of the init system, for a more comprehensive and capable system and framework. I'm not sure if Apple ever used system v init, but they certainly abandoned the script system in general with 10.4 and LaunchDaemon. They had good reasons to do so.