Stories
Slash Boxes
Comments

SoylentNews is people

posted by Dopefish on Thursday February 20 2014, @07:30AM   Printer-friendly
from the penguins-everywhere dept.

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!"

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 2, Insightful) by knorthern knight on Friday February 21 2014, @12:58AM

    by knorthern knight (967) on Friday February 21 2014, @12:58AM (#3933)

    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.

    Starting Score:    1  point
    Moderation   +1  
       Insightful=1, Total=1
    Extra 'Insightful' Modifier   0  

    Total Score:   2  
  • (Score: 2) by Lagg on Friday February 21 2014, @03:32AM

    by Lagg (105) on Friday February 21 2014, @03:32AM (#4044) Homepage Journal

    anthony@frontline ~ % systemd-analyze blame
              4.663s netctl@main.service
              4.296s mysqld.service
              3.456s systemd-fsck-root.service
              2.703s systemd-logind.service
              2.511s systemd-vconsole-setup.service
              2.384s systemd-modules-load.service
              1.768s systemd-fsck@dev-disk-by\x2duuid-8e71def0\x2dcd0f\ x2d4253\x2d8a57\x2d9f1b17704626.service
              1.454s systemd-binfmt.service
              1.390s dev-mqueue.mount
              1.292s sys-kernel-debug.mount
              1.267s dev-hugepages.mount
              1.136s systemd-tmpfiles-setup-dev.service
              1.002s proc-sys-fs-binfmt_misc.mount
               764ms systemd-udev-trigger.service
               603ms smbd.service
               566ms nmbd.service
               444ms systemd-sysctl.service
               331ms systemd-journal-flush.service
               244ms openntpd.service
               188ms systemd-user-sessions.service
               145ms systemd-remount-fs.service
               116ms sshdgenkeys.service
                91ms systemd-udevd.service
                67ms systemd-tmpfiles-setup.service
                64ms systemd-update-utmp.service
                31ms dev-disk-by\x2duuid-6337734b\x2d7cb0\x2d48d0\x2d8c ac\x2d1f310de45052.swap
                20ms home.mount
                14ms winbindd.service
                 3ms systemd-tmpfiles-clean.service
                 1ms tmp.mount
                 1ms sys-kernel-config.mount

    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] 🗿