Stories
Slash Boxes
Comments

SoylentNews is people

posted by n1 on Friday August 29 2014, @07:53AM   Printer-friendly
from the a-tip-of-the-fedora dept.

Longtime employee and CTO of RedHat is leaving the company.

“We want to thank Brian for his years of service and numerous contributions to Red Hat’s business. We wish him well in his future endeavors,” said Jim Whitehurst, President and CEO of Red Hat.

ZDNet reports:

Stevens' eyes may have been wandering elsewhere because of conflicts with Red Hat's president of products and technologies Paul Cormier. Cormier will be taking over the office of the CTO for the time being.

His future? It's unclear but it's possible he's moving to greener pastures, "a major California-based technology company."

Commence wild speculation! What does this mean for RedHat and GNU/Linux? Anything?

 
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) by PizzaRollPlinkett on Friday August 29 2014, @04:52PM

    by PizzaRollPlinkett (4512) on Friday August 29 2014, @04:52PM (#87280)

    I've used RH since 5 or 6. I can't remember. I stuck with it for a long time mainly because it ran IBM's Linux versions for their database and other stuff (like Websphere, MQ). Recently, IBM has diversified Linux support much more. But for a long time, IBM built their stuff for RH. So I got used to it. No matter how bad RH has been in the past, it seems like the past few years have taken bad to a whole new quantum level. I don't really do system administration anymore, so the new init stuff has kind of passed me by. If what I'm hearing is true, it's not a good thing, especially if the log formats are binary files. (Remember, you read those files when the system won't boot, so they need to be easily accessible.) Gnome 3 was created by people who had no idea how anyone used a computer and didn't want to know. I'm not going to change decades of the way I work. Instead, I changed desktops. But the installer not working is what really got to me. How can installing Fedora 20 on the exact same hardware as Fedora 19 cause the installer to fail? How could it be that broken? I could understand if I had some weird new hardware they'd never tested on, but this is a vanilla PC that ran Fedora 19's installer just fine. I can put up with quirks, and have for quite some time. But when I can't instlal the OS, things have gone horribly wrong.

    And whoever said RH was trying to make RHEL into Windows Server - well, I built 2 PCs with the same hardware at the same time. I didn't use Windows Server, because the box was for development, but Windows 8 Pro installed flawlessly. When Fedora 20 can't be installed and Windows installs flawlessly, then we have a problem.

    --
    (E-mail me if you want a pizza roll!)
    Starting Score:    1  point
    Karma-Bonus Modifier   +1  

    Total Score:   2  
  • (Score: 2) by frojack on Friday August 29 2014, @08:23PM

    by frojack (1554) on Friday August 29 2014, @08:23PM (#87352) Journal

    Many years ago, I took a tour of linux while choosing a distro. I ran many of the main stream distros, each for a month or two, then backed up MY files and nuked it and started on another. Ran each long enough to get use to it and get everything running, including my programming environment. This went on for over a year (between Life and my regular work).

    I found that RedHat and most of its derivatives all installed insecurely at that time, (I'm told this hasn't changed much since), and all sorts of services and ports were open out of the box. I got one redhat machine pwned on the internet. My fault, for not securing it. But after installing several other distros previously and having to manually go in and turn on services, etc, I just assumed all distors installed locked down.

    I ended up with SuSE, still using Opensuse today, as well as a few installations of SLES. Not happy with SystemD, but I'm sticking with opensuse while at the same time putting up OpenBSD as my new principal file server.

    --
    No, you are mistaken. I've always had this sig.
    • (Score: 2) by Marand on Saturday August 30 2014, @12:45AM

      by Marand (1081) on Saturday August 30 2014, @12:45AM (#87408) Journal

      I found that RedHat and most of its derivatives all installed insecurely at that time, (I'm told this hasn't changed much since), and all sorts of services and ports were open out of the box. I got one redhat machine pwned on the internet. My fault, for not securing it. But after installing several other distros previously and having to manually go in and turn on services, etc, I just assumed all distors installed locked down.

      Noticed that myself. Fighting with Redhat's "every port is open, pwn me plz" design back when I was a newbie was a pain in the ass and one of the reasons I looked into alternatives.

      I ended up with SuSE, still using Opensuse today, as well as a few installations of SLES. Not happy with SystemD, but I'm sticking with opensuse while at the same time putting up OpenBSD as my new principal file server.

      I've mentioned this elsewhere, but you can still avoid systemd as init in Debian, even in the testing/unstable releases currently, by installing systemd-shim. With that package installed, the other parts of systemd (logind, primarily) that are being tied to bits like udev still function without systemd being the init. The init part is what I'm most opposed to, so I run sysv-init and ignore the rest.

      My preference would be to not have any part of systemd, but as long as it's not the init, I can tolerate it in the same I tolerate some other parts of the system I don't necessarily agree with or want.

  • (Score: 2) by Marand on Saturday August 30 2014, @12:37AM

    by Marand (1081) on Saturday August 30 2014, @12:37AM (#87404) Journal

    Yeah, I caught that bit about you using it since the 90s and figured you'd started using it at a similar time that I did, but I wasn't going to let facts get in the way of a good ribbing ;)

    Honestly, it's not even that I was unhappy with RedHat at the time. I was new and it was suggested to me because it's what was used at the job I had, so I didn't know about alternatives. I loved using it when it worked, but that was more a case of "I liked Linux" than anything specific about Redhat.

    I just ran into a lot of little problems over the course of using it. One was the kernel version*, but I also got to enjoy rpm hell and dealing with redhat installing and auto-starting every damn service possible. The security issues were what pushed me to evaluate other distros, and I ended up settling on Debian (potato).

    Debian at the time had its own share of problems, but its problems taught me more about Linux**, and once it was running it was rock-solid and secure; while Redhat's problems just taught me about redhat's problems.

    I'd heard later on that they largely cleaned up their act, but by then it was too late, especially with the relationship Redhat has with GNOME, not-invented-here, and dev attitudes. Poettering, of pulseaudio and systemd infamy, works for Redhat, among others, and everything has this stink of "we didn't make it so it's wrong". There's always been this combativeness on the GNOME side that I didn't like.

    I remember multiple instances of non-GNOME/RH/gtk devs implementing features months, years before them, and everyone accepting them as de-facto standards...and then when the GNOME/RH crew decided they needed that feature, they reimplemented it themselves, refused to consider the existing version, and then demanded everybody else follow suit. If that sounds familiar, it should. This shit bothers me because, while I mostly use KDE now, I've historically been a frequent WM/DE switcher, so every time GNOME does that, it makes life inconvenient for every user of every other option.

    What we're seeing with systemd being being foisted on everyone is just more of the same old. Even if sysv-init is considered broken and in need of replacement (arguable), the fix isn't an init that gets it tentacles into every part of your system. There are other inits available, have been for years; why not find one that looks promising, try to improve its weak areas, and go from there? Why do you want to reimplement every part of the OS inside the init? Maybe they want the system to panic more often so you can see those sweet, sweet boot times.

    Also, yes, the bit about binary log formats is true. Not just that, systemd itself corrupts the logs sometimes, and they flagged the bug WONTFIX because it's considered a non-problem. Their view is that systemd just rotates out the logfile if it becomes corrupted, so who cares, notabug, go away. They even take this same sort of arrogant attitude with the kernel devs, which resulted in Kay Sievers (the udev guy, another systemd maker) getting told off by Linus over it. The gist of it was that Kay got told to fuck off for having busted code and then demanding the kernel devs change things to accomodate bad systemd designs.

    At least Debian hasn't completely forced systemd on me yet. Parts of it are required, but there's a systemd-shim package that lets you retain your non-systemd init without the other parts of systemd complaining. I use it and keep the old sysv one. I'd rather not deal with systemd at all, it doesn't seem mature enough yet, and I'd prefer another system instead, but it's a good-enough compromise for now. If we're lucky, it will end up like pulseaudio: Poettering will get bored, find a new project, everybody will come in behind him and clean up his shit, and it will be mostly usable and still optional. I'm still happily running a pulse-free system without problems. :)

    --

    * I know Wikipedia says RH5 had a 2.0 kernel, but I recall it having both and, for whatever reason, I ended up with the 1.2 kernel in my install.

    ** I went through the debian installer probably a dozen times before I got a working system and learned a lot about the kernel, partitioning, etc.