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.

Not always. His yacht was hideous!

Always good to hear things from the original source! Thanks for posting.

Just fyi, your "homepage" link refers to your old Easy Software web site, which no longer exists. Apparently an e-cigarette company has bought up your old domain name!

MS Windows is still the dominant platform, and it doesn't seem to have any guidelines or standard widgets anymore. Every app seems to use s different set of widgets and owner-drawn window decorations are a plague in certain spaces like anti-malware and anti-virus. MS themselves started this trend by using a different set of widgets with every release of MS Office. I just laugh when people talk about Linux apps being all different and not fitting into together. Windows is at least as bad these days, if not worse. And yes Chrome has made the problem even worse, and now Firefox.

If I could use classic theme restorer plus the GTK theme addon for Firefox I'd be a happy camper. As it is I'm stuck on ESR 24 for the time being.

Here's a real product that seems to almost do what the original poster is wanting, but not quite. But the it's a similar solution to what I described, but instead of discarding packets to allow the fasted packet to win, it aggregates bandwidth. Different problem, but similar solution.

http://www.pcpro.co.uk/news/br...