Dev.SN ♥ developers
Sections
Dev.SN
An anonymous coward writes "Former cypherpunk shares his conspiratorial view on Linux security:
Since then, more has happened to reveal the true story here, the depth of which surprised even me. The GTK development story and the systemd debate on Debian revealed much corporate pressure being brought to bear in Linux. [...] Some really startling facts about Red Hat came to light. For me the biggest was the fact that the US military is Red Hat's largest customer:
"When we rolled into Baghdad, we did it using open source," General Justice continued. "It may come as a surprise to many of you, but the U.S. Army is 'the' single largest install base for Red Hat Linux. I'm their largest customer." (2008)
This is pretty much what I had figured. I'm not exactly new to this, and I figured that in some way the military-industrial/corporate/intelligence complex was in control of Red Hat and Linux. [...] But I didn't expect it to be stated so plainly. Any fool should realize that "biggest customer" doesn't mean tallest or widest, it means the most money. In other words, most of Red Hat's money comes from the military and, as a result, they have significant pull in its development. In that respect, the connection between the military and spying agencies, etc. should be obvious.
Next, the FOSDEM: NSA Operation ORCHESTRA Annual Status Report is well worth watching in its entirety (including the Q&A at the end). To me, this turned out to be a road-map detailing how Red Hat is operating on Linux!"
(Score: 2, Informative) by Lagg on Thursday February 20 2014, @05:03AM
Guys, AC submitter included, slow the fuck down. The military buys a lot of support tickets for RHEL from red hat, therefore they are pulling strings in its development and systemd is really a conspiracy? Really? Really?!
I don't understand why people are trying so hard to attribute systemd's success and adoption as a conspiracy or government scheme. Why is it so difficult to believe it's just technically superior? It's asynchronous, the service file syntax is simple .ini absent of boilerplate typical in sysvinit, the level of granularity in journal browsing and the associated metadata is awesome. Yes it can do with some improvement in the decoupling area but I don't doubt there are things going on to make that happen, it is an open project after all. As for the journal files being binary, who gives a damn? journalctl will happily spit out anything you ask for in plain text which can be easily piped to other tools. Just like you do piping to grep and such. And using a binary file format does NOT mean that it's suddenly "OH NOES WINDOWS EVENT VIEWER". Many, many unix tools use binary formats for many things (remember dbm, as just one example). These are the only potentially valid complaints I've seen, the rest are attempts at favoring politics over technical superiority. And that's just not cool when you're dealing with an init system.
Seriously, this is getting pathetic. Almost to the point that I'm forming theories as to why the submitter was anonymous. The military using linux has been a known thing almost since shortly after linux became popular. It's such a huge insult to Red Hat to claim that they're bending over a barrel for the military with no proof beyond documents they themselves made available without issue.
http://lagg.me [lagg.me]
9467 6082 8A35 2E1E 2D6B 76C4 5E9A ED56 076F 9E89
(Score: 2, Interesting) by Dopefish on Thursday February 20 2014, @05:11AM
Hi Lagg! I very much appreciate your counterpoint to AC's submission. I don't see anything particularly nefarious with systemd's rise in use within Linux distributions, Red Hat or RHEL notwithstanding. With the open development process that the Linux kernel and most of the userland is subjected to, it can be rather difficult to quantify a government conspiracy. Still, I felt it was important to hear out what AC had in mind and I hope it didn't rustle too many jimmies in the process.
(Score: 2) by Lagg on Thursday February 20 2014, @05:18AM
http://lagg.me [lagg.me]
9467 6082 8A35 2E1E 2D6B 76C4 5E9A ED56 076F 9E89
(Score: 1) by arachnist on Thursday February 20 2014, @06:35AM
There's one other issue with journald - it seems to miss some entries if you send messages to it fast enough.
(Score: 5, Interesting) by Anonymous Coward on Thursday February 20 2014, @09:13AM
What success? How many people switched to systemd because they wanted systemd? I was there when Arch Linux decided to force people to switch to systemd - and I write "force", because that's what it was. The official announcement said that it was due to lack of volunteers to maintain initscripts, after which they proceeded to ban anyone from the forums who even hinted at volunteering to maintain initscripts.
Who gives a damn about log files being binary? I'll tell you who - cat, vi, grep and all the others. You know, the whole range of unix tools. And no, journalctl will NOT happily spit out anything in plain text. Not when you need it the most, when some major system component like journalctl keeps crashing, and the kernel keeps spitting out log messages (that go to said binary log) telling wtf went wrong.
No, many unix tools do not use binary files. A few do, and they all have one thing in common. They are not a necessary part of the system. Sendmail is one example of such a tool, but when the system is down, sendmail is not the first thing you care about. Find out why the system is down (check the log), get it back up and running, and then worry about sendmail when said binary tools are working again. Nobody ever suggested replacing syslogd with sendmail, because that would be stupid. It still is.
When you say that using a binary format does not mean that it's suddenly Windows Event Viewer, you need to realise that the Windows Event Viewer comparison is not about the GUI or whatever you think it is. It's about a log that needs a special program to show it, a log that can't be read with notepad or vi or awk. And that is exactly what the systemd log format is, according to their own documentation. Saying that its not like Windows Event Viewer, IS saying that it's all plain text, and contradictory to the rest of your argument.
Systemd is everything that for some of us were the reason we did not choose Windows or OSX. And if you want to argue that we are wrong for not wanting to use systemd for the same reasons, you are not just arguing for systemd. You are arguing for switching to OSX or Windows.
(Score: 3, Insightful) by DarkMorph on Thursday February 20 2014, @10:20AM
I still run Gentoo where systemd is an option that isn't enabled by default. OpenRC and initscripts - I'm quite content with them. I also use Arch Linux at work which, of course, has systemd. So far what I've noticed that bugs me is that sometimes the journal daemon will just consume one CPU core to 100% for a short time and I don't see any distinct reason as to why that is.
I also was a little frustrated when certain mechanisms I have with rc-update apparently don't exist with systemctl. And yes, I've done man systemctl to check.
(Score: 1) by minus9 on Thursday February 20 2014, @11:17AM
Sendmail's config files aren't binary, they might look like they are...
Some of the text files are converted to Berkley DB to speed things up.
(Score: 3, Interesting) by Lagg on Thursday February 20 2014, @12:36PM
I've been using Arch since around 2005 and I consider systemd one of the best decisions ever made. My server downtime is reduced significantly and maintenance as a whole when adding/removing services is much safer feeling. No one is forcing you to do anything, there are probably no less than 8 init packages on AUR. As for "banning anyone" I'm guessing that you really mean "banning me" and by volunteering to maintain initscripts I'm guessing you mean "because I was being a flaming jackass". Granted, I will reconsider this position if you link to proof. I would sure as hell want to know if this is happening as I don't want to support such activity.
Could optimize that, but not the point. I've never had journalctl segfault on me on any install so far. Not that I'm dismissing the possibility. But that's hardly an argument against it. Things get bugs, and they'll be fixed.
Try again, sendmail is not the only thing that used dbm by far and it only used it for caching. It was otherwise m4.
When did I say it has anything to do with the GUI? I wouldn't glorify such comparisons to such an extent. What it really is is a knee-jerk reaction. The similarities to event viewer begin and end at the fact that log data isn't plain text. People such as yourself use that as ammo to say "but now I can't read it with vi or awk D:" which is entirely false. People have since forever piped log data, regardless of source, through multiple programs before getting output. That is still easily done with journalctl but with added filtering due to the record metadata.
Huh... That is sure a leap of logic. Are you perhaps the submitter?
http://lagg.me [lagg.me]
9467 6082 8A35 2E1E 2D6B 76C4 5E9A ED56 076F 9E89
(Score: 1) by Subsentient on Thursday February 20 2014, @03:12PM
(Score: 2, Insightful) by knorthern knight on Thursday February 20 2014, @08:58PM
So systemd boots up 2 seconds faster... whoop dee do. Linux is not Windows 95, so the average user is not rebooting a dozen times a day. But Redhat doesn't give a flying f*** about the average user. They only care about themselves. Redhat does cloud computing http://www.redhat.com/solutions/open-hybrid-cloud/ [redhat.com] How do they handle spikes in demand? There are 2 options...
1) Run extra VMs idling 24x7, just in case, which uses up electricity, and increases their power bill at the data centre
2) Run with fewer extra VMs, but rewrite the init system entirely to shave a couple of seconds off the boot time
They go with option 2. It may not sound like much, but when you're handling that many VMs at the data centre, it does make a difference. Rather than running idle VMs, they get by with fewer VMs and use systemd to allow new VMs to spin up a couple of seconds faster. And if it imposes difficulties on average home users, too effing bad.
(Score: 2) by Lagg on Thursday February 20 2014, @11:32PM
and this is my fairly unoptimized setup, a friend of mine is reporting 7 seconds because he bypassed netctl. You must live in a universe where seconds are longer, because here in Earth A we don't exactly call a 75% improvement woopty-do material. Can we stop with the "It's all Red Hat's fault." stuff? Next you'll be telling me Red Hat is just pulling strings in Arch. Oh wait... That's what you and the AC already did implicitly! Nevermind.
http://lagg.me [lagg.me]
9467 6082 8A35 2E1E 2D6B 76C4 5E9A ED56 076F 9E89