This is true and good, so long as you're interested in making software that can be done entirely with existing technologies. As soon as you hit the brick wall of "but there isn't anything in the standard library that does this," you need the old graybeards who spent their entire careers making the standard libraries you rely on.

Speaking as one of them, the pay and hours are both good and it keeps me on the cutting edge of some fascinating technologies.

The common idea is that we over-40s who've been doing this professionally for 25+ years can't adapt to modern software dev practices. Quite the opposite, really. Mostly we're kept so busy that we don't have the time.

None of this is meant to disrespect what the younger generation does with (as you say) "connect the dots library calls". That code needs to be written, and it's best if it's written by smart people who care about their work. :)

"Raw Press Releases."

C'mon, guys, this is copy-pasted marketing fluff. Better is expected of you.

Terrible. It insulted my intelligence at every opportunity. To pick just three:

1. A hard drive that's been at Ground Zero of a Chernobyl-level event, exposed to hundreds of sieverts of ionizing radiation, extraordinary extremes of temperature, a hydrogen-oxygen explosion with such tremendous overpressure that it blew the containment dome, and seawater pumped through the building as a last-ditch effort at cooling the core, is still somehow so readable that it just requires a classified forensics program to recover it fully.
2. The main bad guy's ultimate plan involves speculating on the future of a commodity that isn't exactly rare.
3. Targeting nuclear reactors in the U.S. and China as a practice run for the real attack is pretty stupid, as the practice run is so devastating that it guarantees an immediate and vigorous reaction from two world-power countries known to have active cyberwarfare programs, thereby announcing your presence to exactly the people you want to keep completely in the dark

This movie insulted my intelligence at every turn. I have a long (and spoilerific) list of all the what-the no-they-didn't good-Christ moments I saw in the movie; if there's interest I'll post them here.

The photon has zero rest mass, yes.

E = mc**2 is a nice popularization; it's also wrong. It's actually E**2=(mc**2)**2 + (pc)**2, where p is the momentum. When momentum is zero, you can usually simplify this to E=mc**2, but a photon's existence is defined mostly by its momentum. Since m is zero for a photon, this means the energy of a photon is given by entirely by E=pc.

Hope this helps!

"Good evening, ladies and gentlemen; some substitutions. Tonight, the role of Genghis Khan will be played by John Wayne."

So, the NJ State Senate Majority Leader admits that New Jersey's law, which would make smart guns mandatory within three years of the first commercially-available smart gun being sold anywhere in the United States, can be reversed... if only the NRA will agree to stop obstructing the sale of smart guns within the United States, which they do specifically because of the New Jersey law?

I don't see the problem. The NRA is obstructing a law that goes against their stated interests, and New Jersey is promising to reverse that law if only the NRA will stop obstructing what that law regulates?

For the NRA's stated position, see here. Particularly:

NRA does not oppose new technological developments in firearms; however, we are opposed to government mandates that require the use of expensive, unreliable features, such as rigging a firearm so that it could not fire unless it received an electronic signal from an electronic bracelet worn by the firearm's lawful owner (as was brought up in Holder's recent testimony).

That's their stated policy, right there.

Not quite. Courts have been willing to hold businesses liable for damages due to foreseeable criminal acts, yes, but so far no court has been willing to hold businesses liable for damages due to acts of war levied by a foreign state.

That's a pretty big jump to make, incidentally.

The risk is not that the courts might hold the theater chain responsible -- the courts wouldn't, on the grounds that the theater chain isn't responsible for protecting their clientele against acts of war from a foreign nation-state. The risk is that the lawsuit would be filed and it would cost the theater $20 million or more just to get the courts to dismiss all charges.

That $20 million is probably considerably more than they would make from screening The Interview, so the logical business case is to not screen it.

It's sad, but ... the real problem is not that the courts might hold the theater liable: it's that in our current system, getting sued is, in itself, its own punishment.

The NRA does not object to smart gun technologies, and believes that people who wish to be allowed to buy them should be allowed to buy them.

The NRA objects to smart guns becoming mandatory, because the technology for smart guns is nowhere near mature.

The number one desired trait in a firearm, moreso than caliber or capacity or anything else, is reliability. The reason why Glocks are so popular isn't because of caliber, capacity, or aesthetics -- all of which other firearms do better. It's because a Glock is as reliable as gravity. If you chamber a round and pull the trigger, it goes boom. If you don't pull the trigger, it won't.

I have personally seen a Glock get thrown into a bucket of wet, goopy mud and left there for fifteen minutes just so the mud had the opportunity to permeate the whole of the firearm. At the end of the fifteen minutes the owner pulled the Glock out, shook it precisely three times to dislodge mud from the barrel, and fired one hundred seventy rounds through it in the space of about five minutes, just one magazine after another after another... just to prove the weapon was reliable.

Do you believe the current crop of smart gun technologies are equally reliable? The ones I've had the chance to play around with definitely aren't. They can't even agree on whether they need to fail safe or fail deadly.

He's implying that developers will specify a complete environment where every DLL available to the application within the environment is exactly what the developer used. There is no DLL hell because you run what the developer ran, and it doesn't matter if you have seventeen different incompatible versions of (to pick windows example everyone's familiar with) mfc42.dll, because things inside the container won't know that you have those dlls.

In that case, why bother with dynamic linking at all? Why not statically link everything? The effect is essentially the same -- you get exactly what the developer had. You also get no shared code pages -- even if you're using exactly the same library as someone else -- and bloated memory and disk usage since you have your own private copy of everything. Disk may be "cheap," but it's still surprisingly easy to fill up a 16GB eMMC device.

Am I getting hopelessly old and unable to appreciate new things, or is this not anywhere near as whoop-de-doo as they're making out?

"You can update transactionally!!" Great. What does that mean? Is it like git add newapp; git commit -a? If so, how do I back out a program I installed three installations ago?

Transactional updates have lots of useful properties: if they are done well, you can know EXACTLY what's running on a particular system, [ ... ]

dpkg -l

You can roll updates back, [ ... ]

dpkg -i <previous_version>

...lets you choose exactly the capabilities you want for yourself, rather than having someone else force you to use a particular tool.

#include <cheap_shots/systemd.h>

Because there is a single repository of frameworks and packages, and each of them has a digital fingerprint that cannot be faked, two people on opposite ends of the world can compare their systems and know that they are running exactly the same versions of the system and apps.

debsums

Developers of snappy apps get much more freedom to bundle the exact versions of libraries that they want to use with their apps.

...Did this guy just say he brought DLL Hell to Linux? Help me to understand how he didn't just say that.

I bet the average system on the cloud ends up with about three packages installed, total! Try this sort of output:

$ snappy info
release: ubuntu-core/devel
frameworks: docker, panamax
apps: owncloud

That's much easier to manage and reason about at scale.

No, it isn't!! What the hell is OwnCloud pulling in? What's it using as an HTTP server? As an SSL/TLS stack? Is it the one with the Heartbleed bug, the POODLE bug, or some new bug kluged in by the app vendor to add some pet feature that was rejected from upstream because it was plainly stupid?

Honestly, I'm really not getting this. It just sounds like they created a pile of tools that lets "cloud" administrators be supremely lazy. What am I missing here?

I worked for NTG/3DO for just under five years, so I know (knew) the machine inside and out. It will be interesting to go through this code and see what kind of tradeoffs were made.

Some comments on the README:

My friends at 3DO were begging for DOOM to be on their platform and with christmas 1995 coming soon (I took this job in August of 1995, with a mid October golden master date), I literally lived in my office, only taking breaks to take a nap and got this port completed.

*snerk* I could have told you at the time that a ten-week dev cycle was crazy talk.

Shortcuts made...

3DO's operating system was designed around running an app and purging, there was numerous bugs caused by memory leaks. So when I wanted to load the Logicware and id software logos on startup, the 3DO leaked the memory so to solve that, I created two apps, one to draw the 3do logo and the other to show the logicware logo. After they executed, they were purged from memory and the main game could run without loss of memory.

An interesting and valid approach (3DO's OS had full memory tracking). I'd be interested to know which of the 3DO libs was leaking memory on you.

The verticle walls were drawn with strips using the cell engine. However, the cell engine can't handle 3D perspective so the floors and ceilings were drawn with software rendering. I simply ran out of time to translate the code to use the cell engine because the implementation I had caused texture tearing.

Were the floor/ceiling textures not power-of-two dimensions on each side? As I recall, you only got texture cracking when the dimensions were not power-of-two.

You could have decomposed the floor/ceiling textures into strips as well, but ultimately the lack of perspective correction meant you were going to have to do some heavy lifting somewhere.

I had to write my own string.h ANSI C library because the one 3DO supplied with their compiler had bugs! string.h??? How can you screw that up!?!?! They did! I spent a day writing all of the functions I needed in ARM 6 assembly.

Ah, yes, the Norcroft compiler (or, as I always called it, Norcruft). It was a piece of shit. It was also the only thing available that would run on the Mac. It was never anything but a C compiler, but kept throwing unblockable warnings about constructs that C++ would have problems with (such as implicit cast from void*). There was no MacOS port of GCC, and there were no usable ARM backends for GCC available at the time, anyway. (Bear in mind, this was before the Web existed in any familiar form, and you had to go trawling through USENET for clues -- not even AltaVista existed yet).

I hope that everyone who looks at this code, learns something from it, and I'd be happy to answer questions about the hell I went through to make this game. I only wished I had more time to actually polish this back in 1995 so instead of being the worst port of DOOM, it would have been the best one.

I'm sure many memories will come flooding back.

Didn't this very topic come up a few days ago? I recall the general consensus being that it's an anti-spam measure, and (is supposed to) only happen when connecting on port 25 to a non-local machine (port 25 is supposed to be for server-server communication only). Normal clients are supposed to be able to avoid the issue by changing your MUA to submit mail on port 465 (smtps) or 587 (smtp). I suspect people running their own SMTP servers will probably need to negotiate with their ISPs, or relay their mail through their ISP's SMTP server as a smarthost.

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...

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?)

That's exactly the sort of thing I hoped to hear about.