The incident you are thinking of is, I think, when Neil Armstrong crashed in the Lunar Module Simulator.
http://www.huffingtonpost.com/...
Apparently the story goes that he was back in his office eating lunch a few hours later like nothing happened.
The RSO's are actually not even from NASA. They are from the US Air Force 45th Space Wing (I knew that was true at KSC and Wikipedia confirms it's the same group that does Wallops).
...except that I'm talking about *corrupt* logs, not *correct* logs. I maintain that in the face of corruption, a human parsing an ASCII log will beat a computer parsing a non-ASCII log any day.
NO! I don't see why this is so hard to get. ASCII is a one to one mapping with human language. "Binary" logs (i.e., logs with an encoding other than 7 bit ASCII since we're going to be SUPER pedantic here apparently) are not. Especially if they are compressed or the encoding is complicated in other ways. When stuff gets corrupted the best filter for that corruption is the human brain. But that assumes the brain can parse the encoding. I can parse the English alphabet (and the Spanish one on a good day).
What do you think will happen if I want journald to parse, say, "ap#@1e2: p@#$ission denied"? Is that going to correctly end up with "apache2: permission denied"? I doubt it. But I probably will. Especially if I already know that I'm having issues with Apache. And if you don't like that example, I'm sure I can come up with a lot more.
The implication isn't that SysV init is problem free. The implication is that SysV init is *debuggable*. A 900+ edge directed graph that controls my system startup is *not* debuggable. Especially when some of the nodes and edges are created implicitly (if you're wondering what I'm talking about, ask systemd to produce a dot formatted graph of the startup process. Just don't ask it to do that in a chroot environment because it won't, but that's a different rant). Oh - and it seems to ignore some of the dependencies (edges in the graph) but not others.
Because 85% (a number I just made up) of the point of log files is to *figure stuff out when things go wrong*. When things go wrong, binary logs sometimes end up corrupted (witness all of my journald logs from last week - no, I don't know why yet). I am a *LOT* better at sifting through a corrupt text log than a computer is at sifting through a corrupt binary log. Journald just says "your log is corrupt" and I lose. I've noticed that even "strings" doesn't get text out of a (non-corrupt) journald log (at least not all the logs, maybe some of them?). Now please give me *one* advantage of binary logs over properly formatted text logs. The reason syslog is so hard to parse is that it splits lines stupidly. There's no (modern) reason for that. So when I say "properly formatted", I definitely don't mean syslog as is. Think syslog with lines of any length.
Err... Western Design Center sells them. Mouser claims to have a few hundred 65c02's in stock in a variety of form factors (PLC-44, QFP-44, and DIP-40) as well as 65816's. The 65816 is compatible enough that if you clocked it at 1MHz, you'd almost certainly end up with a 100% compatible design (though if I remember back to my Apple IIgs days correctly, there are a few minor incompatibilities, even when running the 65816 in 8 bit mode).
It may only do one thing, but it most *certainly* does not do it well. I've yet to have a system with an NFS mounted root filesystem correctly shut down under systemd.
Yeah: Inability to debug what is wrong with the init system when you aren't doing exactly the use case that "normal" people use. I have a number of problems with it, but here's one:
I've been trying for the last two weeks to end up in a place where my root filesystem was served up by NFS and
In SysV init, I would've seen stuff whining about permission denied errors on the console (instead of all the output being eaten, despite turning on debug mode and journal+console mode) and realized I probably didn't have the filesystem mounted right. For the
I don't think that the former poster is complaining that the source trees happen to be managed the same way. He's complaining that dependencies are being created between different pieces of software that don't need it. If systemd were set up to where there was a standard
The ability to quickly design and produce an ASIC is hardly new or innovative here. ASICs are one of the few pieces of computing that you can get done faster if you just throw more people at the problem. Plus, I have a strong suspicion that most Bitcoin mining ASICs are Gate Array ASICs (http://www.fujitsu.com/emea/services/microelectronics/asic/asic/techprod/gatearray/) which, if my understanding of them is correct, use a bunch of standard layers and interconnect them with a few custom layers. That reduces the number of masks needed as well as reducing NRE charges and minimum quantities. Essentially, it's an FPGA where the interconnection is hard wired.
Now as to your prediction that multipurpose CPUs may go away (or become a small piece of a computer), that may turn out to be true. Special purpose ASICs to solve specific problems in high performance computing have been proposed many times, though to my knowledge, not actually built. At some point, though, someone will build one. Especially as the feature sizes stop getting smaller, going to custom logic to solve problems will be the next logical way to speed things up. However, the current generation of Bitcoin mining isn't going to be contributing anything to it.
Apparently (and this is my understanding with no inside knowledge, so take it with a grain of salt), they don't have live video telemetry from the stage during decent. They have a variety of engineering data, but to get decent video, they need to get the stage back. Given that it blew up, I'm guessing that's unlikely. Last time, they had some spotty video relayed off a tracking aircraft, but they had to wait for the aircraft to land before anyone saw it. Maybe the same will happen here? Also, as a company, I have a suspicion that they aren't thrilled with releasing videos of their rockets exploding. While a lot of people here understand that that's likely inevitable, given how complex a task they're trying to achieve, the general public probably won't....
What server do you have that makes it through the BIOS so fast that the difference between systemd and SysV is meaningful?
And if your server is so critical that the ~2 minute difference (on a good day) in boot times is a serious business issue, you should really consider running redundant servers anyway since there are a variety of other failures that a fast boot time isn't going to help....
Partially guilty. I certainly believe that a 2 minute boot time is acceptable *to me*, but I'm not irritated by people who want fast boot. I'm irritated that their zeal for fast boot resulted in an extremely poorly engineered piece of software that breaks the ability of some of my machines to boot *at all*.
- Binary Logs: Sorry, but there is no advantage to not being able to easily look at a log file.
Technically, there is an easy way to look at the logs, it just requires a utility that is not cat or grep. But I get your meaning. Binary logs are certainly not my preference, but for tools that need to interact with and parse the logs, it is a necessity. There are ways to get your text logs back, though, and some distributions configure it this way by default.
...which will almost certainly break if the logs get corrupted at all. The great thing about text logs is that my brain can figure out what values are probably garbage and which ones are the remnants of the (now corrupt) log a lot better than a computer can. There are certainly ways of hardening binary logs, but why? syslog is a PITA to parse by machine not because it's text-only, but because the formatting is from the 1960's. I'm not arguing it has to be syslog format, just text.
- Failure to Log to the Console:
It is in the log.
...until you don't GET the log because it wasn't *WRITTEN*, which probably hasn't happened to you because you're probably booting a fairly standard configuration. But it took me 3 f'ing hours to debug the fact that my permissions were wrong on my NFS server when I was net-booting because I got no shell and no log (because the permissions were wrong). That would've take 20 seconds with logging to the console and knowing more about systemd wouldn't have fixed that.
- Failure to Drop to a Shell When It Breaks:
Once again, it is in the log. I'm not sure why being dropped to a busybox shell gives you a much better way to debug than just reading the log messages. If you want to test individual systemd services, you can do that with systemctl start/stop/etc.
Because sometimes it's a lot nicer to try to reproduce the failure right then and not have to reboot the system in order to get to the log. Remember, no shell means you can't read the log *at all* without rebooting.
However, if you use that command as root, it tells you not to run it as root. If you do it as a normal user, it doesn't have permission to read all the files to tell you what it's doing.
If that is true, it is a bug.
Maybe, but systemd --test --system prints "Don't run test mode as root" on OpenSuSE 12.3 and Fedora 20.... While trying a few other distro's to post this comment, I ran across "systemd-analyze --order --system plot" (which wasn't in the original distro that I was debugging, but it was ARM so maybe it was weird) which appears to be able to generate a graph in SVG, which, while huge, appears to help me a lot.
- Races: I no longer have any idea what order things are starting in.
If a dependency issue is causing your boot to randomly fail, then your systemd configuration is horribly broken.
...until something doesn't work. Yeah, the config I've got *IS* horribly broken. I'd like there to be some reasonable way for me to figure out how to fix it. And sometimes I don't *PREFER* an order, sometimes I *REQUIRE* an order. On my desktop? Couldn't care less because it "Just Works(tm)' and I rarely change the distribution's defaults. On my servers, it's more complex. Maybe "prefer" in this case means it will always honor that?
Have you every really had to deal with the complexities of the sysV init system? It is not pretty. "Jiggling the cord" until it works is about all you can reasonably do with sysV when you have a complex init.
Yes. I obviously have no idea what your experience is, and maybe you had a horrible one with SysV. I've had my share of battles with it and I'd never argue it's perfect, but it's a lot easier to debug than systemd. When everything starts in serial order....
It doesn't "mount filesystems" at a single time during boot the way sysV does. You can move service files to other filesystems, but then you need to tell the service config that you did this so that it can bring up that filesystem before starting the service. This is actually a lot easier to do with systemd than with sysV.
In SysV, almost *nothing* happened before filesystems, so I rarely had to touch *anything* in
Well, this is more of a rant than a series of legitimate complaints. You can't expect the systemd people to understand your issues if you haven't even taken the time to learn how systemd works first.
Yeah, it *IS* a rant. But that doesn't mean that the stuff I'm complaining about isn't a real problem. I've always hated the "let's make it complicated and blame the user if they can't figure it out" philosophy. I will waste hours figuring it out. Why is this a waste? Because in the end, I've gained *no* capability that I didn't already have except faster boots and since I boot my servers less than once a month, that gains me nothing. It's awesome that Linux is gaining share on the desktop. udev, for all its warts, was *sorely* needed since I don't wanna run "mkdev" every time I plug a USB device (etc). However, until systemd, the changes for the desktop played nicely (and in most cases added capability) to the server use cases. systemd just doesn't.
Oh, I knew I'd think of something else. systemd even managed to break shutdown on a netboot'd system since, apparently, it's weird set of dependencies don't check to see if the root filesystem is mounted over the network before shutting down the network.... Again, obviously distribution dependent, so if you know of one that can actually deal correctly with an NFS root, let me know...
What's wrong with it? Here's my starting list and I'm sure I'll think of more....
- Binary Logs: Sorry, but there is no advantage to not being able to easily look at a log file.
- Failure to Log to the Console: There is nothing more frustrating than watching 5 screens of "Failed, use journalctl to blah, blah, blah..." come by when you know that your root filesystem isn't mounted read/write. There went *ALL* your debug information.
- Failure to Drop to a Shell When It Breaks: If my boot is broken,I want a shell. Not a hang. There's a way to force it to go to a shell, but that's before it does *anything* so you don't get to debug the failure, you get to guess what the failure might be and see if you can debug *that*.
- No way to see WTF it's doing: There's supposedly a command to make it tell you what order (and presumably what'll happen in parallel) things are going to start in. However, if you use that command as root, it tells you not to run it as root. If you do it as a normal user, it doesn't have permission to read all the files to tell you what it's doing.
- Races: I no longer have any idea what order things are starting in. I've had a cluster where everything worked fine. Until the a week and a few reboots later and then it occasionally failed. Don't even start to tell me that "I must have my dependencies wrong". I *KNOW* they're wrong. But I have no tools to help me figure out what "right" is. Plus, have you looked at how many unit files systemd starts on a normal system? I can't hold that much of a graph in my head. With SysV init, unless I turned on some weird parallel mode, everything starts in the same order every time.
- Complexity: I'm not a professional sysadmin. I'm a developer who has to maintain development systems (as well as personal systems) part time. If I worked with systemd every day, I'd probably be able to figure out ways to make it work for me. But I don't. SysV is just shell scripts. I *DO* deal with *those* every day so it's pretty easy to debug.
- Complexity, Part 2: The previous version of init essentially had no bugs. Ok, I'm sure that's not really true but they sure didn't surface very often. Since the results of your Process #1 dumping core are catastrophic (ie, a kernel panic), ideally that process should do as little as possible. That is *CLEARLY* not the design philosophy of systemd. Further, it consumes a decent amount of RAM and the more RAM you consume, the more likely (statistically) you are of hitting a memory error.
- YACL (Yet Another Config Language): Ok, so this is really a minor complaint but I get to learn yet another way of writing config files.
- Filesystems: SysV init tended to mount local filesystems *very* early in boot (some of that broke when udev got involved, but you could usually hack around that) and network filesystems not long after. I'm not entirely sure where systemd mounts filesystems, but it breaks *HORRIBLY* if you move some of the files needed by a service onto a filesystem that's not a "normal" filesystem. I'm sure there's some way to set all the dependencies to make that work, too, but see above, I have no f'ing way of figuring out what should depend on what.
From all outward appearances, the developers have *no* interest in fixing much of any of those complaints. The whole "debug on the kernel command line" fiasco is a pretty clear indication that they "don't play well with others". In the end, I'll see what Slackware has or maybe move (back) to the BSDs.
Receiving a million dollars tax free will make you feel better than being flat broke and having a stomach ache. -- Dolph Sharp, "I'm O.K., You're Not So Hot"
