Apparently on slashdot, the plural of anecdote is the exception that proves the rule. So five or 10 people have seen witching work. Therefore it doesn't work.

Gas lines, water lines, sewer lines, coaxial lines, electric lines can all be found with a minimum of effort without witching sticks. All you have to do is go to a random spot, any old spot, it doesn't even have to be within 1000 miles of a human settlement, and dig. If you do not hit one of the above, you will at the very least cut the only fiber connection to an entire continent.

I think unions were great at busting up some frankly inhumane hiring practices. These days, it seems like you need a union against the union as the percentage they take from you is probably about equal to the percentage cut you would have to take if you didn't have the union backing you.

This is my problem, too. The problem is that companies not only expect you to to work late into the evening "when necessary", meaning on days that end in "y", but they also expect that the fact that you worked a 20 hour shift on Monday does not mean you can come in late on Tuesday, and you certainly cannot expect to be allowed to take a half hour to go run some errands during the day, unless you are willing to give up your lunch hour to run those errands instead of maintaining your health so that you can be a more productive employee.

In the vast majority of places I have worked, they have claimed that I am an exempt employee and thus cannot be paid overtime, although that is not true by the letter of the law in most cases. Also, in most of those places, they do allow you an hour for lunch and you are not actually "on the clock", however, they also expect you to work 8:30 to 5:30, not 9 to 5. So you still work at least a full 8 hours.
Recently I was told by my boss that I need to bring my laptop to lunch in case there is a problem at work. That means, as far as I can tell, that I am not actually on a lunch break at all. Also, it means that I am limited to eating places that have free public wifi, because they won't pay for tethering and I'm sure not going to pay for it just for their use, and also that wherever I go has electric outlets within reach of the table because the battery on my 4 year old laptop only lasts about 10-15 minutes.

Green Eggs and Ham FTW!

One of my favorite things to do during a conference call is to wait for somebody to start some tirade after hitting mute and then to say "By the way, IT says they will have the mute button fixed by Friday."

I've been thinking about getting a dashcam. I commute less than 40 miles round trip each day and yet almost every day I witness at least one bonehead move that could have killed someone. If I could record these, at least it could be put up on a wall of shame somewhere and maybe it ought to be admissible as evidence for attempted vehicular manslaughter. At the very least, if one of these maneuvers does eventually cause an accident, i will be able to present video evidence.
Some of the illegal maneuvers are done by cops, as well. I saw one yesterday that i wanted to call in for a possible drunk driver. Weaving around, getting at least a tires width into neighboring lanes at times, etc. But he was probably just surfing the internet on his police computer. Oh, and speeding. About 75 in the 60 zone. Then sometimes I see officers throwing lit cigarettes or other trash out of the car. Excessively speeding without using their lights, etc.

The problem with accidental breakage is that it it always occurs when it would have corroborated the defendants story. The problem with this ubiquitous recording is that it never seems to be able to be used for your benefit. My friend had his debit card used at a local branch ATM. it had never left his possession, so he was curious as to who had used it. He requested the tapes from the bank. Of course, the camera had not been working that day. Undoubtedly they would have been working that day if someone had tried to steal the money out of the ATM though. Perhaps if he had gotten a subpoena, the bank may have changed their story. Or perhaps not. How can an outsider prove whether the camera system was working or not? If the bank wants the cameras to have been broken, then they were broken.

Several parts are written as libraries, so you can just rip them out and use them on your own. Almost everything in systemd can be removed at compile time. There is also documentation for removing even those things that doesn't have compile time configure switches (really tiny embedded systems may have special needs):
http://freedesktop.org/wiki/So...

You can't rip out random parts of the systemd package and expect them to work as intended (probably rare to do in any Linux project). That doesn't mean systemd is monolithic, but rather that it is modular, in the same sense that lego bricks are modular; you can't rip out random parts or bricks from a lego project, and effortless combine them with eg. Playmobil, or another brick system that isn't designed to be lego compatible. Systemd have well defined interfaces, just like lego bricks, so you can use the systemd API's, or even make you own tool variants or replacements if you want too.

The same command on systemd is "journalctl -f" . Notice how you don't need to give a path. Notice that in both instances you need a executable (tail vs journalctl) to view the logs.

How about "journalctl _EXE=/usr/sbin/smartd -f" ? Now you are "tailing" the output from a single executable.
Don't worry that the command line seems long: there is tab-comppletion for everything. That is the power of an index log file: every process, daemon, commandline, kernel subsystem etc. that have ever written to the log file are indexed so they are tab'able. The journal have total knowledge of all entries; they can all be traced back to whatever wrote them. Notice the underscore in the field value _EXE, that means that there is kernel guarantee the entry isn't faked.

Spend some hours playing around with journalctl. You will never want to go back to unstructured text log files again.

That is a perfect description of the tools in systemd.

OS containers are a big thing (tm). Because systemd is running as PID1 and have total control and supervision of all processes in the system and can control them with e.g. cgroups, it is possible to have OS containers that runs _unmodified_ from the host system. That is beyond a humongously big thing (tm). No need to "Dockerize" your OS/app.

"Dumb" init systems like Sysvinit, who just throws some processes up in the air and then promptly forgets all about them, are unable to so.

Systemd is seriously the most cool technology that have come to Linux for years. It really saddens me that the joy of hacking new Linux technology seem to have disappeared.

Totally wrong. I mere point to the fact that almost none of the ranting systemd detractors have a clue what they talk about, for the very simple reason they haven't read the systemd documentation (which is quite large), looked at the source code, or even glanced the 'man' pages.

The amount of straight up factual nonsense you hear from systemd detractors is simply staggering, they just repeat memes spouted on some blog by a swivel eyed loony, instead of simply starting to read the systemd documentation:

Like or not, systemd is the future of Linux, the vast majority of all Linux distros will use systemd, so every Linux user should cram up on systemd, the sooner the better.

So is Hammer FS portable to Linux without major reworking? I don't think so. All BSD kernel functionality from init rc, to hardware detection etc. are made only with BSD in mind. Of course they are.

systemd doesn't run on non-Linux systems, simply because those systems doesn't offer the kernel services systemd requires. It is a moot point anyway; no BSD could have a GPL program controlling boot and services, it is simply not their business model, so they would never use it, even if the systemd developer limited its functionality to work on BSD too.

BSD is of course welcome to clone systemd. OpenBSD is already trying to do that to some extent.
And some day BSD will get a modern init system like systemd too. It is only a matter of time.

It is you who are the propaganda victim of what other people rant about systemd, I have actually read some of the systemd documentation and used some of is functions.

I have read Brooks, and unlike you I can distinguish between contributors and lead developers. I think that there are around 12 people with commit access to the systemd tree, working on various aspect of systemd. There are however hundreds of people who have contributed to project by submitting patches to the mailing list. The systemd project is organized pretty much like the Linux kernel in that respect. (Oh, you must just hate the Linux kernel because of all the people contributing patches to it).

That is just crazy talk. Of course booting is central to any OS; it during booting all devices are discovered, configured, and this information relayed to other parts of the OS, and the kernel is told where the rest of the OS is on the disk etc. This is exactly what systemd does, and e.g. because it can be initiated in initramfs, and then jump back to the root FS, it can obtain early boot logging info, and securely control and supervise system processes from the very beginning.

This is a major fallacy among systemd detractors. Your lack of factual knowledge about systemd, and your irrational, emotional hate against systemd makes it impossible for you to conduct a levelheaded analysis of the situation.

All future work on DE's like Gnome, KDE, LXDE, XFCE is based on systemd. Without an alternative to systemd's "logind" there will be no secure rootless X, probably no Wayland, no fully functional desktop on multiuser systems (suspend, powersave etc.).

Systemd detractors are simply ignoring any request from upstream projects about helping them out to support non-systemd distros because of attitudes like yours, which is exactly the reason why upstream projects will eventually stop supporting non-systemd platforms.

And how do you make a distro agnostic GUI to control networking, time and locale setting on non-systemd platforms? The answer is you don't! Piece of cake to do on systemd distros, so this is why upstream projects target it. The systemd detractors offers no help to upstream projects to support their choices however.

That attitude is exactly why systemd detractors have lost the discussion on all major Linux distros; you favor negative campaigning against systemd and named open source developers instead of arguing about technical aspects based on factual knowledge.

"systemd" is a tool and daemon collection. Each of those tools, like "systemctl" or "hostnamectl" or daemons, like "journald" does one thing only, and can therefore easily described with a single line.

some examples:
"localectl" - control the system locale and keyboard layout settings
"hostnamectl" - control the system hostname
"journalctl" - query the systemd journal

So, yes systemd as a project is capable of many things, but it does so in simple, modular way.