uptime13:07:37 up 33 days, 19:33
It is so disapointing when linux makes me reboot. I really would like to get my desktop to go for months
without a reboot.
How long have we been on this lifeboat?
Thirty-three days, sir?
A Generation Lost in the Bazaar
Quality happens only when someone is responsible for it.
Thirteen years ago, Eric Raymond's book The Cathedral and the Bazaar (O'Reilly Media, 2001) redefined our vocabulary and all but promised an end to the waterfall model and big software companies, thanks to the new grass-roots open source software development movement. I found the book thought provoking, but it did not convince me. On the other hand, being deeply involved in open source, I couldn't help but think that it would be nice if he was right.
The book I brought to the beach house this summer is also thought provoking, much more so than Raymond's (which it even mentions rather positively): Frederick P. Brooks's The Design of Design (Addison-Wesley Professional, 2010). As much as I find myself nodding in agreement and as much as I enjoy Brooks's command of language and subject matter, the book also makes me sad and disappointed. ...
Dipping my toes into Linux recently, I felt a need to support systemd
for starting some customer services. It was, initially, a major pain
The problem now is that if you're packaging an application you have to support *both* sysvinit and systemd. Although systemd can be configured to honor sysvinit scripts, there is no guarantee that your underlying OS has it built that way.
What a pity, I really enjoyed just running services directly out of /etc/inittab, with each service's "don't go into the background" flag set. If a daemon crashed for whatever reason, init would just restart it. The "upstart" init replacement which was included in nonstandardbuntu for a while had a way to configure auto-respawns, but one line in inittab was TEH R0X0R.
Now, if it doesn't exist already, someone's going to have to write an "install this as a service" script that feels-out the underlying environment and does the right thing.
The tricky bit, for me, was dealing with the daemonization of the service.
systemd can react in one of three ways, if I recall, to this... it can expect the executable to run as if it were being run on a command line, without relinquishing control and all that. It can expect the executable to run as if it were fully daemonized (gives up the console, pushes itself in the background, and all that jazz). And I forget the third option... but I think it's kind of a half-way between those two.
But detecting that is apparently non-trivial. I forget the name of the tool I used to trace what was going on with my executable, but it didn't do a great job of informing me of what was happening with the spawned threads, and I think it did nothing to tell me of whether or not the console was relinquished.
That said, the only other tricky bit involved ensuring other things that I needed running were in fact running when my service started. But, y'know, Windows has this problem, too. I think systemd is more flexible in its approach, but it's complicated. Like a lot of relationships.
Hm... dunno what consequences exist if you don't daemonize the code and let systemd deal with it. Maybe none... although writing your code to work only with systemd might not be ideal if you want your stuff to work on other systems.
"there is no escaping that the entire dot-com era was a disaster for IT/CS in general and for software quality and Unix in particular."
Bold words. I'm not sure I would go that far. Except if I were talking about PHP. >:-P
Ford ][ would be eating that article up.
Well, if systemd takes over the universe, we'll eventually get to the point where the few init scripts that are left will have ampersands in them.
They seem to have a pretty good run, but Solaris will not likely shift to that model. We'll have init scripts for a long time yet.
Make sure you update.
As examples of "lost in the bazaar" he cites:
* All of the baristas-turned-web-developers during the Dot Com Boom
* The FreeBSD ports tree
He conveniently leaves out all of the places where quality is present because someone is paying attention to it, or even better, because there are customers paying for it (Red Hat, Oracle, etc).
The comments were more fun than the "get off my lawn" article.
Definitely that was a lot of "get off my lawn", but he might as well have been talking about Red Hat or Ubutu or Debian instead of the freebsd ports, because the Linux userland is *exactly the same source base as* the FreeBSD ports tree. And it has many of the same dependency hell problems.
From the outside looking in ( I haven't written Windows code since toy projects in high school ) it actually looks like Windows might have ended up getting more things right (except for their appalling filesystem semantics) than Linux did, because Linux grew by accretion and Windows was kinda sorta architected.
He conveniently leaves out all of the places where quality is present
because someone is paying attention to it, or even better, because
there are customers paying for it (Red Hat, Oracle, etc).
But see he wasn't talking about the freebsd ports tree, he was talking about the upstream sources that feed into that. And now you're coming along and saying "don't worry, Red Hat will put lipstick on it."
That sounds like "no one is worrying about quality control except for the people who are paid to be responsible for quality control."
The QA toons are paid to find bugs (can we pay them by the bug? I digress.) They are not paid to ensure quality in the sense he was talking about.