Well... All told, I think that went rather well.

I wanted to chime in and thank everyone for participating in what was clearly an insane exercise in trying to cut through the acrimony and vitriol and get some actual information on what systemd is and what it's trying to do. You can't always grok what complex things are about just from the docs. That's why I wanted actual first-hand experiences from people who could point to actual gems they'd found.

To respond to some recurring remarks throughout the comments:

• "Obviously a pro-systemd shill."
  No, I'm not shilling for RedHat or Poettering. In fact, I gave Poettering some stick for the whole corrupt-binary-logs-aren't-a-bug thing a couple weeks ago. I was being forthright in the opening paragraph: The simple fact that systemd has been widely adopted despite widespread protest made me genuinely wonder what I was missing that I hadn't figured out from the docs I'd read. So, no, there's no conspiracy here.
• "Who are you to establish posting rules?"
  Well, gosh, sorry, but I was trying to save everyone time. Seriously, tell me you haven't gone, "Oh, ${DEITY}, another systemd thread; there goes my afternoon as I pick through the rat's nest of comments." So I hoped -- perhaps naively -- that requesting some organization would let us all get to the meat of issues of interest fairly quickly. And enough people did choose the follow the rules that the discussion overall turned out valuable (for me, anyway).
• "Why do you dislike something you admit you know nothing about?"
  For largely the same reason I dislike Windows without having comprehensively pored over the "design" docs for COM, DCOM, MFC/ATL/WTL, WDM, NTFS, NTLM, Direct${THING}, Active${THING}, etc. etc. etc. Poorly-designed systems seem to have a certain "pattern" to them, and systemd at first glance seemed to match that pattern (the use of Windows-style INI files syntax didn't help, either). But the people adopting systemd are clearly not idiots, so I hoped people with actual experience with the thing could convey insights that (for me) the docs so far have not.
• "You're thinking of the ads for Miller Lite, not Bud Light."
  *headdesk* I would like to apologize to a no doubt deeply irritated TV ad executive for completely misattributing their fifteen-odd years and millions of dollars worth of loud beer ads to the wrong company (I think this speaks well to my socially-isolated geek cred, though :-) ).

In the best tradition of USENET, I thought I'd summarize the highlights of what I got out of the whole thing. Most of the good posts have already been modded up, but the ones that especially stood out for me were these:

• http://linux.slashdot.org/comm... , describing what 'systemctl status ' can do.
• http://linux.slashdot.org/comm... , pointing out a point/counterpoint summary on uselessd's Web site.
• http://linux.slashdot.org/comm... , describing that systemd plays nice inside a container, presumably making it easier to create VM-ish setups.
• http://linux.slashdot.org/comm... , where the poster describes how systemd does a better job of stopping processes/daemons. The poster then sticks around, giving clear answers to further questions.
• http://linux.slashdot.org/comm... , describing how systemd exposes Linux cgroups to create limited execution environments for daemons or (it appears) any process.
• http://linux.slashdot.org/comm... , while heavy on the snark, nevertheless links to concrete discussions of the insights and motivations behind systemd.
• http://linux.slashdot.org/comm... discusses how systemd doesn't just launch processes but manages their entire lifetime (although the replies suggest a machine can't survive systemd itself crashing).
• http://linux.slashdot.org/comm... points to a post on the Arch Linux discussion forum which describes their rationale for adopting systemd.
• http://linux.slashdot.org/comm... mentions four systemd features and the issues they solve.
• http://linux.slashdot.org/comm... describes some of the advantages working with systemd's logs, with examples.
• http://linux.slashdot.org/comm... describes how systemd made it easier to resource-limit their daemons.

Thanks again to everyone who chimed in. You've given me a lot to read up on...

Also, 5 failed attempts and you are locked out.

Yeah, I'm not sure how this ruling applies with iOS, given 5 failures means you are reverting to passcode, or 48 hours requires passcode, or even a power off.

I mean, how does the ruling apply if the fingerprint reader gets disabled? (And you can do it by simply using an unregistered finger, tapping with the tip of your finger, or turning off the phone.).

So if they can force you to use the fingerprint reader, what happens when the phone won't let you use the fingerprint reader?

If you know the history of Adreno, you'll know it's actually based on an ATi (now AMD) chip.

Way back when (nearly 15 years ago), ATi was one of the first companies that made a mobile GPU back when people didn't even think you needed one (when embedded chips had framebuffers for graphics). Eventually they sold their mobile GPU division to Qualcomm who rebranded it Adreno.

So a lot of the Adreno's internals are based on AMD insides so a lot of it is actually documented by AMD.

Anyhow, it's likely Qualcomm only wants to support the Android port because that's where all their money is. However, they (and us, who work with Qualcomm to work on smaller projects) do get requests for graphics support on Linux and other OSes, so contributing to a free driver means the community can support their chips and they can sell a few more. Android is still their bread and butter and they probably optimize the heck out of it, but a free community driver for everyone else that handles good enough is great for those smaller projects.

'Solid-state' was the term invented to differentiate vacuum tube technology from semiconductor (solid-state) technology... Summary is not just wrong, it gets it exactly OPPOSITE this time.

Well, the first link was for a transistor amp that goes to THz speeds.

The second link was for a semiconductor fabbed amp that uses vacuum tube style technology to make it work. It isn't, ,however, at all close to your traditional vacuum tube. First, there's no filament - just applying a differential voltage (10-15V) is enough to start shedding electrons off the cathode. The gap is so small that the low voltage is adequate, and you almost never need to use a vacuum - you could operate it in regular atmospheric air, or improve performance by using helium. (the gap is so small, that there's few air molecules that'll get in the way so performance doesn't suffer too much.

It works based on vacuum tube principles - a cathode sheds electrons, which flow through a regulating gate to an anode. But it's all made using current semiconductor processes on silicon. It's basically a solid state vacuum tube.

Think back to the epic holy wars of the past. Emacs vs. Vi. Big vs. Little Endian. Motorola vs. Intel. Amiga vs. Atari ST. ASCII vs. EDBIC.

vi*. Little-endian. Motorola. Amiga. ASCII**. Obviously.

(* with great respect to those who are able to use EMACS well.)

(** Seriously, who not using punched cards ever actually liked EBCDIC?)

Actually you've demonstrated the parent's point very well. Pulseaudio like systemd solves very real problems. It had teething issues and now seems to work rather well.

The problem stems from the fact that they solve very hard problems. Audio IS hard - it's not just putting a stream to a card and having a beep come out from a speaker anymore - nowadays audio is FAR more complex. Most computers now have various ways to get audio in and out - a hardware ADC/DAC (sound card), Bluetooth, HDMI, digital (S/PDIF, TOSLINK), built in speakers/microphones, etc. etc. etc.

And the one you use at a given time depends on what you're doing. If you're on a VoIP call, you want to have its audio routed to a communications port (which may or may not be separate from the main audio out), you may or may not want to mute the main audio (or just lower the volume), and so forth.

Then there's the common case of mixing - you're watching a YouTube video and someone IMs you, so you need to mix the two streams together to play it out the main output.

Oh, now you unplugged the laptop from your desk and what was using the optical or HDMI audio outputs now needs to switch to the onboard speaker and microphone.

It turns out init isn't all that simple either. Because even SysVInit is fairly complex - it has to reap zombies (every process has init as its parent, eventually). It has to manage daemons (yes, even SysVInit has to manage daemons - take a look, you probably have a bunch of lines where it manages getty). It also has to run the hack that are RC scripts which appear to implement a lamer version to manage daemons. Oh yeah, it also has to shutdown and restart the computer, too. (And I don't mean stopping daemons and such, either).

So after all this, SysV already handles two forms of daemon management (each with their own plusses and minuses), it has to reap processes (to free up kernel resources), shuts down or reboots the computer, and it also has to handle starting up the computer.

It's a third party that the person with the private feed didn't authorize, reading their tweets.
Also whether or not they retain the information, and what they do with it if they do.

Doesn't matter.

Just because you marked the tweet as private and only viewable to a few, is still viewable to all.

THERE IS NO PRIVACY SETTINGS. Once you post, even if it's "friends only", it is still public.

Because anyone who sees it is free to screenshot it (how many tweets have been deleted only to live on in screenshots?), copy/paste, retweet, report, etc.

If you're typing it out on the internet and someone else can see it, it's public information. A private feed or post is just like sharing a secret - it ain't a secret no more.

Hell, is it just as bad if all they did was provide a web interface where concerned users could copy and paste said tweets into it? In this case, the user (who you authorized) is reporting to a third party as well.

I don't know if I'm being paranoid, but I'm pretty sure there are backdoors in every major open source project : gcc, the linux kernel, ssh, gpg and bash to name a few.
They've been either actively introduced by NSA/FSB/... or found and jealously kept secrets.
It's not like recent history has proven this theory wrong. :-/

Except that shellshock dates to 1989. That's when the "feature" to export functions was added to bash per commit logs. And that predates Linux 0.1 by a couple of years, so your FBI/NSA/etc would have to have extreme foresight to believe that some piece of software would suddenly be popular, aided by an unknown barely-functional OS released a couple of years later, etc., etc., etc.

And if you're paranoid, use OpenBSD, where every line of code has been audited.

So now Motorola phones will have spyware and bugware like the Huawei ones?

Don't forget Xiaomi as well. Their mi5 software is actually given away because Xiaomi wants to become a cloud company and not a hardware company (i.e., they don't want to follow Apple's footsteps in making nice phones, but Google's footsteps by making nice phones that collect data).

The mi5 software is part of that and is why they give it away - to help collect data for the cloud.

Even Williams Electronics, an arcade game maker that used an upside-down Motorola logo, spun off its video game business to Midway, which is now part of Time Warner.

Actually, when it was spun off, it was Williams-Bally-Midway. In the 80s, Williams experimented with arcade games, and then acquired Midway to be their arcade division. (WIlliams also acquired Bally for pinball). Depending on the mood, the game would either be released under Williams or Midway (likewise for pinballs under Williams or Bally). Eventually more and more of it just went towards Midway until it was basically doing all the arcade games and got spun off later.

Williams-Bally today makes gaming devices (slot machines), having decided to shut down their pinball division instead of either suspending or spinning it off.

where Gates & Jobs got all their ideas from.

Actually, Jobs just brought people over to see the demo. No one actually saw any code.

It's why Woz had to invent (and patent) "regions" which was needed because it's the way to handle overlapping windows. (Woz got in a plane accident a short while later where he supposedly told Jobs when he visisted, "Don't worry, I didn't forget regions").

It was only after it was all said and done did someone from Xerox tell Woz their Alto didn't have overlapping windows.

For years, these MCX folks allowed NFC payments, meaning potentially Google Wallet payments. Apple Pay comes out with an EMV based solution, and instantly block all NFC, taking Apple Pay and Wallet down together. So, Google was never seen as a threat, or at least never passing the threshold of needing-to-ban, even after years of use, but Apple is seen as a potential threat from literally Day One.

I wonder why Apple is seen as a threat more? Their network of friends? Number of potential users can't be it - many more Android phones than iPhone 6s. Number of cards already in iTunes? Ease of use (i never even tried Google Wallet)? Did Google leak some of the info back to the retailers where Apple is balking at that info leak?

Because Google Wallet and Apple Pay work in opposite ways.

For a retailer to support Google Wallet, they need to work with Google and their merchant processor to support Google Wallet. Because what really happens is the transaction details are forwarded to Google who then charges your payment method (credit card, debit, Paypal, bank account, etc). This is why Google knows everything about your transaction whenever you use Google Wallet. (Basically Google gets to know everything about what you're buying).

Apple Pay is nothing more than EMV so it's just an electronic credit card. Once you register your card through Apple Pay, Apple is no longer in the transaction. As long as the retailer takes credit cards, and has an NFC reader, Apple Pay will work. Most of the retailers listed by Tim Cook? They did diddly squat to support it. They just had working readers and probably someone came over and tried it and was successful.

Because to support Apple Pay means you need an EMV compatible terminal (swipe, chip+pin, NFC) and processor, and because of October 2015 legislation, people are supporting it by default since practically all new terminals have it. So all a retailer needs to do to get Apple Pay support is make sure their hardware (terminals) is upgraded (which they're doing anyways over the next year) and their processor supports EMV (which if they're doing chip+pin, they're going to have support for).

However, for Apple Pay to work, Apple needs to work with banks to ensure when a user scans a credit card,, they can get a token assigned in its place (the token is private between the user and the bank, and is basically just an index so the bank can determine who to bill).

So Google Wallet requires no effort by banks, etc., and effort by retailers to support. Apple Pay only requires hardware updates they're doing anyways which is minor, but effort by the banks to support EMV.

That's why Google Wallet's penetration has been low - there are probably more retailers that support Bitcoin than Google Wallet just because. (Though if your processor is adding support for Bitcoin, they probably have Google Wallet support as well).

For Apple Pay, because for retailers it "comes for free", which means its market penetration is far higher than what Tim Cook had in his presentation. Because retailers who already have NFC terminals practically already support EMV and that makes them Apple Pay compatible with zero effort.

So retailers may be inadvertently supporting Apple Pay when they don't want to because Apple Pay just shows up as a credit card.

What if the first thing that shows up in a google search about you is a court filing about someone else that shares the same name as you? Any HR department that takes a google search at face value isn't doing its job.

I think the "right to be forgotten" idea has good intentions but the problem is similar to the RIAA's resistance to the internet. A better reaction would be to give an alternative to people treating search engines and random internet sites as authoritative sources of information and instead give people something that they can trust that includes all relevant information. It could be similar to a credit score or a government run webpage that includes every individual's public information.

Sure, that's great, if you have a common enough name that millions probably share it. But if you have an uncommon name, or a unique spelling such that Google only turns up a few people, it's rapidly very easy to see who's who.

The right to be forgotten does not remove source articles. Just because you submit a request, doesn't mean the newspaper is forced to remove the article from its archives. No, the right to be forgotten applies to links. Perhaps if you Google your name, it brings up a DUI from 20 years ago you did (you were a young, reckless college student). All it means is that if people do the search of your name only, that no longer shows up. If they search by DUIs, then yes, your name shows up because it's true. But it shouldn't be the first damn thing that shows up if you've lead an exemplary life from then on.

In fact, rich people don't need this right because they hire "brand managers" that do this very thing. These companies use SEO and other techniques to bury bad news later on in the search because they know only about 30% of people make it to the second page of results, maybe 10% to the third, and 1% to the fourth. If you can get some bad thing put on page 10, it's "forgotten".