Feel free to continue to use what works for you.

It's not just a tiny number of organizations though. More and more organizations are deploying virtual machines and containers. In a more dynamic server system like this, the old way of doing things shows its limits. I have written my own restart scripts on many occasions, but it sucks and I'm tired of the hacks. Even in a small organization, I've had race conditions with NFS, openldap, and network connectivity stop booting in its tracks on many occasions. I used to change inittab to start a getty right at the beginning of the init process so I could log in and kick things when necessary (requiring physical access to the server, which sucked big time, but virtualized consoles improved that dramatically). So even for small organizations of one or two servers, the init script system does have problems still.

Maybe you should read up a bit on systemd before you post this kind of untrue stuff, or maybe run it and see just what it does. Systemd does *not* cram everything in pid 1! To say it does is false, plain and simple. You'd know this if you took some time to examine a system that runs systemd. It also does not require a reboot for most updates to systemd. Everything that can possibly be done outside of pid 1 is done outside of pid 1. If you do an update, the package manager issues systemctl daemon-reexec and all the systemd subsystems restart with the new binaries. If something was changed in pid 1 then, like upstart or system v, a reboot is required. But that just doesn't happen very often. I've installed maybe 2 updates to the systemd packages on RHEL 7, and did not need a reboot.

I don't mind actual arguments being made against systemd, but I rarely find any in these discussions! Just mumblings about philosophy and theoretical problems, completely ignoring the very real and ongoing problems with system v and the like, which are impacting a lot of sysadmins. Which is pretty crazy. We've had maybe a half dozen stories on it in the last month on the other sites, and no one can say anything other than FUD it appears.

I'm not arguing for systemd so much as taking issue with the way people are spreading this sort of misinformation, and taking issue with the idea that system v wasn't broken (it is broken, especially with modern, hot-plugged server hardware).

Systemd is actually quite modular. Only the logic that is necessary to be there is in pid 1. So the quote in the summary is FUD, pure and simple. It's certainly not the windows-ization of Linux.

Except that init scripts have always been very fragile and complicated. In short they've never worked that well. They are full of hacked logic to check for running instances using all manner of devices (PID files, grep for the process name in ps, check /proc), they don't lend themselves to parallel execution, and they have no facilities whatsoever for process supervision. Sure you can hack a cronjob (and many a sysadmin has done that!), or use a third-party supervisor daemon (who watches the watchers?). Every commercial unix out there has ditched system V init scripts for these reasons. For example, Solaris hasn't had init scripts ever since maybe Solaris 9? Apple ditched init scripts in OS X quite a long time ago. 10.4 I think?

Systemd isn't that complicated. It's highly modular also. It does a good job and it is remarkably stable for such a new project. Rather than hacking a complex init script, I can create a service in just 3 or 4 lines of a simple, clear, conf file now. In fact it dramatically simplifies the development of custom services. I don't even have to do the fancy fork dance to put a daemon in the background. From a sysadmin point of view, this sort of thing has been sorely lacking in Linux. If I feel inclined, I can integrate with systemd's socket management system, and get instant, transparent parallel startup capability. But the same daemon can still run on non-systemd machines (if I actually implemented daemonization myself). I'm hard pressed to find any negatives, really. And this is coming from a guy who had nothing good to say about systemd before I actually used it. Seems like most of the FUD comes from people like me, folks who've not interacted with it much at all. It's not the only game in town, but it certainly works, and I have no problems with major distros standardizing on it.

On a related note, I would not want to live without pulseaudio either. I currently use pulseaudio regularly to do things that were never possible with ALSA before, such as directing certain program's outputs to certain audio devices. Very handy indeed.

You can boycott systemd if you want, of course. Anyone is free to roll their own distro if they feel like their distro of choice has been bought out by some nefarious power. There are several alternative init systems to choose from.

QuickBasic was an interesting cross between a compiler, IDE, and a live environment. Code was parsed as you typed, and after running the program, you could interact with it in immediate mode after the program stopped running, or after breaking out of execution. You could then type in BASIC statements and query and set variables. It was a unique blend of the live environment the author seems to be pining for, and the modern compiler IDE.

Python for me fits this niche rather well. I can fire up the interpreter in a second or two, run a few statements, etc. Modules I'm currently working on can be imported quickly and tested interactively. I understand the IDLE provides something similar in a full IDE environment.

I personally don't worry about a computer being "instant on." Wasn't useful back then either. At least, Cassette BASIC was never useful to me anyway. I needed to have a disk operating system running so I could load and save files to the disk drive. Even on Apple II I rarely used the command-reset to break out to integer basic. I much preferred teh BASIC that booted up with Apple DOS. Kind of funny to think that BASIC pretty much was DOS back then. At least the user interface to it on Apple. And it did provide a fairly low barrier to entry to budding programmers. Boot it up, break out a book and start coding. I wish I still had the book that my parents gave me when I was about 7. Can't even remember the title but it contained simple games (guessing games, etc) in BASIC that taught basic skills like input, variable, logic, loops, output.

I'm having a blast programming Arduino in C. That's 8-bit programming, and you have to be careful with cycles and resource usage. Arduino code ports quite easily to larger platforms too. It's cool to be able to load small programs on an AtTiny chip and have it be completely functional with no support circuitry.

I suppose if you're using this technology to route around a privacy infringing government, then this doesn't matter since you'll already be breaking the law, and justifiably so.

Now, radio in general can use a variety of frequencies (as the article states), some regulated, some not, and this technology will work with any of these underlying bands in general. But don't try using it with on HAM bands, please. It is certainly not legal to do so in most countries that have HAM licenses, but also it's not ethical, at least within the jurisdiction of countries like the US and Canada. HAM operators pride themselves on operating in the clear, according to string self regulation.

Feel free to use it on unlicensed bands though!

It didn't work out so well. Was very unstable when using hardware-accelerated playback. And frankly I don't really see any mini arm-based PC working quite as well as a regular Intel machine running a full-blown OS. Maybe and Android device would be workable.

But for now, I get the most utility with a mini Intel i5 box running full Windows 7. Tried Linux for a while, but flash sucks in it, and likely always will. And since a lot of web-based TV content is delivered via flash, that was that.

I'm not sure why this is actually making such a splash right now. The investigating committee went over this, and while it was always a possibility, for whatever reason (probably good reasons at the time), no rescue was ever mounted, so it's a bit pointless to take this theoretical rescue plan and make anything of it. Maybe in hindsight the engineering committee's decisions were wrong, but we can only know that now in hindsight. And it's not at all clear that a rescue would have been feasible. So at most it's an interesting footnote to history. Nothing more.

It's sad that the shuttle program ended; it was a fantastic machine. But I'm excited to see companies like SpaceX fill the gap, and probably do things that NASA needs better and cheaper.

I like the look and feel better than soylent's. Granted soylent is using the old slashdot code verbatim. Anyway, I'll be following this site and hope to contribute useful comments and stories. Any chance of merging efforts with soylent? This is a much better name for the site, and a nicer look and feel.