Interviews: Red Hat CEO Jim Whitehurst Answers Your Questions (redhat.com)

You asked, he answered!

For Slashdot's 20th anniversary -- and the 23rd anniversary of the first release of Red Hat Linux -- here's a special treat.

Red Hat CEO Jim Whitehurst has responded to questions submitted by Slashdot readers. Read on for his answers...


What...
by Master5000

...is your day like?

JW: I can tell you this, no two days are the same. Broadly speaking, I strive to prioritize time with customers, partners, and Red Hat associates above other meetings.

When I'm in town, my day starts at 5:30 am with a run. I'll scan email and the news during breakfast and take my kids to school. My first calls usually start at 8 am as I'm driving to the office. Today for instance, I'll meet with a few members of our Corporate Leadership team. I'll then sit down with our chief technologist to hear what's happening in the Office of the CTO.

I usually grab lunch around 11:30 am. I tend to bring my lunch, but will occasionally head to our cafeteria for a sandwich or salad. In the afternoon, I'll get briefed on my schedule for some upcoming events, which will include meetings with partners, customer panels, press, and analysts. I usually spend a few hours a day responding to emails and coordinating activity through email. I try to get home by 6 pm to eat dinner with my family and spend time with my kids. I'll usually jump back on email once everyone is asleep before knocking out around 10 pm.


The plans for CentOS?
By Anonymous Coward

Now that CentOS has received a more official status in the Red Hat world, what are the plans for the project?

JW: The ecosystem around Red Hat Enterprise Linux is sprawling and complex, and that's one of our strengths. You have midnight hobbyists working together with multinational corporations. You have people working on GPU hardware, and you have people working on Ruby apps. Some want the latest-and-greatest, and some want to keep everything exactly the same for years and years. So lots of different kinds of people are doing lots of different kinds of work, and all of them are contributing to this massive project called "Red Hat Enterprise Linux". It's not surprising that we can't accommodate all of that innovation in a single project.

That's one of the reasons we split Fedora and Red Hat Enterprise Linux: we freed up Fedora to be innovative and move quickly, which freed Red Hat Enterprise Linux to be more careful, more conservative, and handle the very important and difficult work of stability and security for code that upstream communities have long since moved past. Fifteen years later, we're still very happy with how that's worked out, and Fedora remains a thriving engine for new ideas that make their way down into Red Hat Enterprise Linux and many other projects.

CentOS solves a very different problem for us. First, there are some people that we can't serve with Red Hat Enterprise Linux today, but we still want to participate in the Red Hat ecosystem. Folks using Xen, for example, may not be able to run today's Red Hat Enterprise Linux, but they can absolutely work with the CentOS project and still participate in the broader ecosystem. Second, there are people and partners who are building software that needs a more stable, Red Hat Enterprise Linux-like lifecycle but want to experiment at the kernel level, stuff which would be impossible for us to support in Red Hat Enterprise Linux. OpenVSwitch and DPDK are a perfect example of this, and the CentOS SIG process has served them really well. They can do all the things they need to do in development and with their partner communities, and their innovations still pass from the upstream communities into Fedora, and ultimately into Red Hat Enterprise Linux, Red Hat Virtualization, and OpenStack.

Meanwhile, changes in hardware and software are changing how we think about a traditional operating system distribution. Things are more automated, hardware is moving faster and less predictably, and containers force us to differentiate between bringing up hardware and creating a stable platform for applications. To address all of these changes, Red Hat is going to need every element of our ecosystem -- Fedora, CentOS, and Red Hat Enterprise Linux -- to respond.


Systemd, WTF???
by rknop

As I understand it, one of the stated goals was to speed up boot times. It's had exactly the opposite effect on my Ubuntu system -- that is, when the boot doesn't die altogether when I try to mount NFS shares. (Also, thanks to systemd, I can't even *reboot* or shut down the machine when there's a hung NFS process. I am forced to hard-reset it.)

For years, warning flags have been raised about systemd. It more or less seems that we're bringing all the disadvantages of the Windows architecture to Linux, without any of the advantages of running Windows.

So, again: systemd, wtf???

JW: We had a lot of systemd questions, so I am replying to them all collectively.

==========================================================================================================
My question is related: is Red Hat, as an organization, at all concerned about the damage that systemd has done to Linux's usability, its reputation, and its community? Is Red Hat concerned with how systemd has driven so many Linux users to FreeBSD?

................................................................................................

And a follow up, why not spend some of RedHat's money on a sane init system?

I'm sure you can put a few dollars and bright minds on a system that works reliably. The last thing I want my embedded system to do is get hung up on an init failure.

................................................................................................

This begs the question, so I'll just ask it: Have any customers ever moved away from Red Hat because of systemd?
==========================================================================================================

JW: First, allow me to address why Red Hat adopted and invested in systemd as it helps to address many of the other questions. Traditional init systems, like System V init, served the UNIX and Linux communities well for decades, but that is a long time and it is not surprising that they have their limitations. The problems an init system needs to solve today are different from the ones that traditional init systems were solving in the 70's, 80's and even the 90's.

Red Hat considered many available options and even used Canonical's Upstart for Red Hat Enterprise Linux 6. Ultimately we chose systemd because it is the best architecture that provides the extensibility, simplicity, scalability, and well-defined interfaces to address the problems we see today and foresee in the future. Of all the passionate debates and disagreements, the fact remains that systemd is the cornerstone of nearly all Linux distributions on its own merits.

Any change like systemd is going to disruptive. We understand that many were not happy with this change and we appreciate the passion of the community. The continued growth and adoption of Red Hat Enterprise Linux, as well as other systemd based distributions, tell us that most users have embraced systemd and there was not a large exodus to FreeBSD or alternatives. We partner with the largest embedded vendors in the world, particularly in the telecom and automotive industries where stability and reliability is the number one concern. They easily adapted to systemd.

We see new users (both new to Linux and prior SysV init users) who truly take the time to learn systemd embrace the simplicity of the interface and its capabilities. We also hear that it is no more difficult to learn than the complexities of init and rc scripts to a new user. It's simply different.

The Debian community provides a thorough, independent evaluation of the systemd initsystem debate. Additionally, the systemd developers provide a list of the biggest myths around systemd.

There are some real advantages, too. Because systemd tracks processes at the service level, daemons can be properly killed, rather than trusting them to do the right thing. This also makes it easy to use cgroups to configure SLAs for CPU, memory, etc. Likewise, security with SELinux and sandboxing become much simpler. The dependency resolution between services is a significant improvement over the sequential ordering of the init rc script mechanism.

Looking forward to all of the exciting innovation taking place around large cloud scalability, OpenStack, Kubernetes, and Containers, we see continued integration and innovation with systemd that would either not be possible or very difficult with init based systems.

So we'll continue to invest in systemd, as it meets our customer's expectations around capabilities, stability, maturity, and community momentum. There's not a realistic alternative today that comes close in terms of adoption and functionality. That said, we're always watching how projects and communities evolve and in that way, systemd is no different from any other component that we ship.

Lastly, I wouldn't dare to debug anyone's setup here, but mounting NFS at boot time is notoriously problematic if you do not have highly available NFS servers. This is a problem that existed before systemd and I think it's much safer to use autofs to mount those volumes on demand or other mount options such as nofail or nobootwait. It is best to not blame systemd for issues that also affect init or are misconfigurations. Ironically, systemd provides more troubleshooting and debug options than init, so that might be helpful to you.


==========================================================================================================
Why isn't Linux on the desktop more widespread?
by snooo53

I'm curious your thoughts on why Linux hasn't grabbed more laptop/desktop marketshare from Windows and MacOS over the years? It seems that with the privacy concerns around Windows 10 and Apple's lack of focus on MacOS there may be a huge opportunity in the near future. What things need to happen in the consumer marketplace and within the OSS community for it to really take off? Can 2017 be the year of the Linux desktop?

................................................................................................

Why not have a consumer desktop?
by Danathar

Given Ubuntu's success at providing a stable, developed and popular desktop environment for non-technical consumer users, why doesn't Red Hat provide the same thing? Why is that right for Ubuntu but not Red Hat?

................................................................................................

Strategy
by olau

Red Hat is big and getting bigger. Where are you heading at the moment? Would Red Hat ever try to move into the the more consumer-focused places where Ubuntu has ventured, or is that just not profitable enough?

................................................................................................

Why does GNOME have such an unusable UI?
by Anonymous Coward

GNOME is a Red Hat project due to the amount of people and funding they get from Red Hat. Then, why does GNOME have such an unusable UI, particularly to the mayor audience of your products? The UI makes basic tasks such as switching between windows a chore unless you install shell extensions, which break frequently and cause unstability.

................................................................................................

Proprietary driver support
by ARos

Many proprietary hardware vendors continue not to take the Linux desktop and workstation markets seriously. Recall, e.g., Linus's rant against NVIDIA. As a leader in the Linux and FOSS communities, what will you do to persuade major vendors to write and maintain functional drivers for Red Hat Enterprise Linux and Fedora? ==========================================================================================================

JW: We also had a lot of great questions on the Linux desktop - let me try to answer collectively:

A functioning, useful desktop is obviously critical to the success of the Linux community. A nice GUI makes Linux more accessible and approachable, and that's why we continue to make investments in projects like GNOME, Wayland, and nouveau. Everyone benefits from improvements in this area, so let's call that the baseline. The primary driver for that work is in Fedora, and I was really glad to see such great reviews of F25. If you haven't tried Fedora in a while, now's a good time to jump in. Personally, I love it.

Of course, one of the perils of the desktop is that "desktop success" is so specific to each individual, since everyone has their own opinion about what a desktop should or must do. That means that even when we think about our "baseline" investment in the Linux desktop, someone's going to be disappointed. What's worse, it's very difficult to make money on a "baseline," since it's something that people just expect to have in the first place. Nevertheless, we spend a lot of time and money on getting these projects right because it is so important to the broader community and the success of our own products.

There's another category of desktop, let's call it the "enterprise desktop". This category requires features that just don't come naturally through a community, and they need some additional investment. The "enterprise desktop" customers who pay for a Linux desktop want that same functioning, useful "baseline" desktop, of course. They also want things like enterprise management features, security tools, compliance tools, identity management, and even simple things, like the windowing system should scale correctly when it's run in a VM on Windows.

You've probably already read my comments on the future of the desktop, and you know that I think the "enterprise desktop" market is changing dramatically. You can see this in how Microsoft has changed their own strategy. Among other things, tablets and phones are far more important than they were just five years ago. We don't think about the software on tablets and phones as part of our core business, so we've left that space alone. But their influence is still there, so the "enterprise desktop" features people are willing to pay for has changed, and that's has an influence on how we invest our resources.

There's a third category, which is the "technical workstation". These are power-hungry people with domain-specific applications, like 3D visualizations, animation, fluid dynamics simulations, stuff like that. They naturally gravitate to Linux because that's where the tools and research that makes them successful starts. We've had great success in that space, and we continue to make investments here.


How do you monetize Open Source?
by mykepredko

What would you recommend to somebody who feels they have a great application idea and are probably ready to go for angel/first round funding but feels that the application should be Open Source?

Do you put in customization/support as the way to fund the endeavor long term or is there another approach for the OSS conscious entrepreneur?

JW: Open sourcing an idea is great because you will be able to innovate faster with the community than you would by going it alone. There are many, many open source startups doing exciting things, and many with VC backing. So, there is clearly a path for the OSS conscious entrepreneur. Red Hat chose a subscription model for our business; others have gone the customization/open core route. We believe in an upstream first development model, so open core/customization does not work for us. But, there are certainly many successful open source companies that use this model, and the true answer here is that there are likely a lot of variables depending on what your app is focused on.

Most importantly, recognize the value of the open source development model is around user participation. So building a business model around open source starts with a clear, deliberate strategy on how to get others with different perspectives and expertise involved in writing the code. If you don't have others actively involved in writing the code, then it's hard to get the leverage you need for an open source model to work.

Building a new community is hard. We've started a few at Red Hat, but most of the time we look for existing ones that already have a robust community. Where a robust community exists, open source always wins. From a business model perspective, recognize that you can't sell the value of the functionality, because the functionality is free. So think hard about how you add value around that functionality. For Red Hat products it's typically a combination of commitment to a defined life-cycle with the bits, downstream certifications/eco-system, ability to drive upstream roadmaps to meet our customers need, and support.


Open source?
by martiniturbide

What is the current commitment of Red Hat with open source for 2017? Redhat may be the most profitable software company that endorses open source for their products. What is the recommendation for other companies to be profitable and at the same time remain being good open source citizens?

JW: Red Hat's commitment to open source has never wavered. We are committed to having a 100% open source product portfolio, with an upstream first development model. This means that we do our work to get features integrated into open source projects before we integrate them into Red Hat products. Dave Neary from Red Hat's Open Source and Standards team wrote a good blog post about this approach. And we have followed through on this commitment even with the technologies we acquire â" something I think is pretty unique to Red Hat. In the last few months, we've open-sourced Ansible Tower and Codenvy.

My recommendation to other companies: contribute. In the last few years, we've seen a lot of new voices championing open source. That's great to see, even when it's your competitors. Faster innovation and more choice is always a good thing. But, open source is a commitment, not a buzz phrase. Companies that want to be good open source citizens need to walk the walk. Another must-read on Red Hat's commitment here is this blog post from Paul Cormier.


Building a strong company
by resplin

Red Hat has distinguished itself through its commitment to open source and its ability to remain profitable.

Mike Olson famously said "you can't build a successful stand-alone company purely on open source." He argues that you cannot scale an open source model that does not rely on selling proprietary components because it is too easy for competitors to undercut a vendor's services offerings when they don't have to pay for R&D.

How do you feel about that assessment? Is Red Hat's success impossible to replicate by other open source companies?

JW: First off, let me say that Mike is a great guy. I've known him for many years, since I first joined Red Hat. And I want to applaud him for his work in driving Cloudera to where it is today. I'm thrilled to see their success. But in regards to open source business models, we've agreed to disagree.

I'd argue that Red Hat is a successful company by many metrics, built purely on open source. My contention is that too few open source companies follow the Red Hat model. I don't want to overly bash open core models. Some will be successful, but competitively, I'd argue that there's no faster way to innovate at scale than through open source communities. We've said before that half open is still half closed. I think it's too easy for early adopters to find workarounds to open core offerings, which can hurt a business when it moves past the early adopter phase.

I refer to this a bit earlier in the Q&A, but the important thing to remember in an open source business model is that YOU CAN'T SELL FUNCTIONALITY because it is available for free. If you just think about functionality, then Mike is probably right - you need to add proprietary code that you can sell. But implementing a piece of software in an enterprise context is about so much more than the functionality.

Red Hat is successful because we obsess about finding ways to add value around the code for each of our products. We think of ourselves as helping make open source innovation easily consumable for enterprise customers. Just one example: For all of our products, we focus on life-cycle. Open source is a great development model, but it's "release early, release often" style makes implementing it in production difficult. One important value we play in Linux is that we backport bug fixes and security updates in supported kernels for over a decade, all while never breaking ABI compatibility. That has huge value for enterprises running long-lived applications. We go through this type of process against all of the projects we chose to productize to determine how we add value beyond the source code.

I would agree that this type of business model won't work across every technology category. At Red Hat, we look very deeply at the categories we've expanded into to ask ourselves whether our model can be effective and make an impact in a given space.

What advice do you have for building a sustainable business, especially one that is driven by open source values?

JW: Start off by reading a couple of answers above. To summarize:

1. Start (or find) an open source project that truly benefits from broad participation and work to build (or become involved) in that project. Projects where participation benefits the quality and innovation of the code are inherently advantaged over proprietary code. So you can check the first box - a technology that is superior to competitors.

2. Identify how you can uniquely add value to that technology that transcends the code. This is what I talk about above. The code is free. It's better because of yours and others' contributions. But those are freely given and free to use and therefore are very hard to monetize. Focus on how customers might implement the technology. For Red Hat, we like layers in the stack that are run-times, where enterprises will likely want long-lived support. We also like layers where hardware touches software, because there is huge value in standardization and certifications, which are not attached to the code, but to the products that we rigorously test and build joint support mechanisms for with the hardware vendors. If you identify this, you are well on your way - you have a project that is superior to competitors' and you have a vehicle to uniquely add value to that project in your product.

3. Surround yourself with like-minded, passionate people. Culture always trumps strategy. That's a short paraphrase of a famous quote. Companies too often fail because of internal strife, ethical failings, or simply losing their way. I know that startups have to begin with a product and business model, but durable success happens via people working together to make it a reality. And that's all about culture and leadership.


Recruiting open source talent
by resplin

As Red Hat has scaled, it has to remain staffed with all types of non-technical business professionals. How do you help these professionals learn to "sell free software"? Has it been difficult to train these professionals on the open source business model?

JW: I think that anyone can pretty easily put themselves in our customers' shoes and understand the benefits of open source. For one, no one wants to feel locked into a proprietary solution or data format. We all want choice and flexibility, and open source is a great way to enable that.

For another, everybody wants access to rapidly innovating technology that helps solve their business problems, and our model gives them the ability to consume the latest and greatest technology, but in a way that's stable and secure for the enterprise.

And finally, everybody's experienced the frustration of having something in their car break and not having access to fix it. It seems like many companies deliberately make it difficult for their customers to tinker with or improve their products. Open source is the exact opposite -- we welcome people to take a look under the hood, see how things work or why they're broken, and roll up their sleeves to contribute if they want to make it better. All in all, it's a pretty simple and compelling value proposition that even someone brand new to our company can understand.


Coding Chops
by CrashNBrn

So who wins in a "code off" ?

Jim Whitehurst, Mark Shuttleworth, Tim Cook, Larry Page, or Satya Nadella.

JW: That's a tough one, but I think I could at least compete! I wasn't new to Linux when I joined Red Hat. I'm actually working towards my Red Hat Certified System Administrator (RHCSA) now. It's not an easy certification to get - if I'm successful, I think I'll have hopefully proven my chops. I can compile a Linux kernel and kernel modules and can build pretty decent apps. Though OpenShift makes building apps so easy, I'm not sure that's a huge distinction. (Note: Shameless plug!)

But the actual answer to your question is Linus Torvalds. He really should be on that list!


A long term view on IoT security?
by mlts

Are there any plans or products to help with IoT security?

RedHat is one of the few companies that can step in and do something in regards to device security, even when device makers have little to no interest in this topic, as to them, security has no ROI, or as one IoT company exec told me, "the only person that has ever made money from a padlock is the lock maker."

Being able to lure IoT vendors to use secure tools wouldn't just benefit them, but it would benefit the Internet in a whole. Even something like manifest lists that interact with FirewallD to ensure a device is only able to communicate with authorized devices and cannot take input/output from rogue sources would improve the IoT ecosystem tremendously.

JW: We are already helping with IoT security indirectly. Open source and Linux powers nearly every IoT device that exists. This is an example of open source winning, you can't escape its reach any longer. That said Red Hat has always been a substantial contributor to open source projects and security is always a part of this collaboration. We were doing security before security was cool.

Rather than putting a focus on individual IoT devices, our focus is on the open source ecosystem as a whole. This is an instance where a rising tide lifts all boats. The goal is not help a single device or vendor, but to work on features that will affect the entire industry. By focusing on improving security in the Kernel, the compiler, glibc, the libraries used, even in the graphical user interfaces, we are helping build the future of IoT device security. IoT is changing the rules and perception around security. There is a lot of opportunity to get IoT security right, which means we have to focus on getting open source security right. We all win or we all lose when it comes to IoT security.


OpenStack vs AWS
by resplin

How can we improve the future of OpenStack? The dominance of Amazon has challenged the relevance of well funded players like Microsoft, Google, and IBM. How can OpenStack compete? The network effects around a dominant cloud platform threaten to relegate OpenStack to be a long term niche player, like Linux on the desktop. How can we avoid this fate?

JW: Most important is that the hybrid cloud is real, and it's increasingly part of the dialog we have with users and customers. Cloud isn't either-or. You can have a mutli-cloud deployment where you are using OpenStack for some workloads and AWS for others. We consistently hear from our customers and users that they are in public clouds like AWS *and* their on-premise cloud deployments. The public cloud providers are all great partners of ours, and I view OpenStack as a complementary technology to them.


As corporate IT loads shift to public clouds...
by Anonymous Coward

...does this marginalize the role of operating system vendors? I would imagine that most AWS customers would lean on Amazon for technical support rather than Red Hat.

JW: On the contrary, the emergence of public cloud has made the operating system even more relevant. There are several reasons why:

The first is around application mobility. The vast majority of customers I speak with plan to use more than one public cloud. So portability becomes a major requirement. And since OS is where the application ultimately touches computing resources, having an OS that can consistently run across all major platforms becomes even more important. As with any single platform provider, optimizations for provider unique hardware, architectures, or services may address specific situations in the OS and we have all seen how that played out in the single-source, vertically integrated Unix stacks - hence Linux. So we remain dogged in our drive in working with all our cloud, hardware, and software partners to ensure that RHEL (and all our products) enable as many platforms as possible to reinforce customer choice and application mobility.

Second, much of the value we provide in Linux is around life-cycle. We commit to a decade+ long life-cycle of patching and support of RHEL. That allows enterprises to confidently run long-lived applications on RHEL. That requires a massive engineering investment in skills, tools and processes. I guess others (like public clouds) could ultimately chose to do that, but it's a very different business than they are in today, and I'm not sure why they would chose to do that versus the many other areas of opportunity that more closely match their current capabilities.

Finally, new application models like containers and microservices are bringing the operating system to the forefront. Each and every container has its user-space dependencies in Linux in it, and therefore requires management of those components in the container regardless of where that container runs. As the leading Linux vendor and as a leader in many of the projects around containers, Red Hat is uniquely positioned to help customers as they build and deploy containers on public clouds or on premise.


Product vs Engineering
by Nite_Hawk

Hi Jim,

Thank you for answering our questions! How do you view top-down product driven development vs bottom-up engineering driven development? Are there situations where one excels vs the other?

JW: To be honest, I'm not sure I'm the right person to answer that question. I've had the great fortune of having a very strong engineering leadership team at Red Hat, so I have allowed them to drive how we engage with communities and build our products.

In a broad sense, Red Hat does a bit of both. Our business model is built from the project out to the product, because we so strongly believe in the power of user driven innovation. So I guess you could say that we are more bottom-up engineering developed. But a big part of our value is taking customer needs and driving those into upstream projects so that they end up in our products. So we really are a hybrid.


Puppet versus Ansible?
by waveclaw

Where do you see the configuration management market going in the next year or two?

JW: First things first, it's interesting to note that Ansible started as an orchestration platform that also happens to be able to do configuration management as well.

Orchestration is the hot topic right now for automation versus last year's configuration management tools. Ansible is more orchestration than configuration management. Puppet and Chef require tools like mCollective to pick up the orchestration piece. Red Hat now runs Tower. And Tower now ships as part of the Red Hat Ceph storage product. Red Hat's Satellite product is based on the Foreman which includes Salt, Puppet, Chef and Ansible support.

But where is this market heading? Are we likely to see consolidation? Integrations? Or even a flood of config management system tied products from vendors?

JW: Orchestration isn't a natural capability of many of the other tools on the market, but if you think about it, the ability to orchestrate configurations is really pretty critical. As it turns out, the order in which you provision IT applications and environments is really, really important. And Ansible handles this by design.

That being said, we have a number of customers that use other configuration management platforms like Puppet and Chef, and they use Ansible to deploy and manage agents, and then to orchestrate application deployments by deploying configurations as defined by these other tools. So really, it's easily a "yes, and" story, not an "either or".

Then we have Ansible Tower -- which actually, Red Hat was a paying Ansible Tower customer before we acquired them. Tower helps orgs operationalize automation across all their teams and IT environments in ways other tools cannot easily do otherwise. It's also key to plumbing automation into devops workflows.

There is some possible consolidation, but there's still a lot of market adoption to be had. We come across customers every day that have previously not used any configuration management solution at scale. This is a problem for those companies that want to scale, and running workloads in the cloud or with containers is nearly impossible without a mature automation and configuration management posture. So while there's some consolidation possible, there's still a lot of growth out there. As for config management being tied to vendors, I suspect that you'll continue to see other organizations mirror our approach to hybrid here. For an IT org that is trying to juggle deployments both on-premesis as well as in the cloud, they need tools that will work just as well in either location. This is a particular strength of things like Ansible.


Are there plans to tighten Ansible Integration
by waveclaw

We use and love Ansible, but it still seems to be a separate product. Are there plans to integrate it more? Having it as an integrated deployment option for JBOSS Operations network (JON) would be good.

JW: When we acquired Ansible, we knew we had to be careful not to immediately crush them with all of our scaling requirements. At this point, roughly 18 months post-acquisition, we can say that the Ansible team is heavily engaged with nearly every Red Hat product team. So whether you're talking about Red Hat Enterprise Linux, OpenStack, OpenShift Container Platform, Ceph Storage, CloudForms, Insights, or many of our other offerings, Ansible is either already integral to those offerings, or is being planned for a near release. It's an important piece across our portfolio.

Specifically to JBoss and our middleware offerings, several of our consulting teams came together to create a Ansible Roles to ease the deployment and management of various JBoss offerings. And I think that illustrates perfectly what Ansible means to us -- even our services teams are engaging in the Ansible community and getting involved. Which is both a testament to what Ansible can enable customers to do, but also to the love that so many different teams across Red Hat have for Ansible.


If meritocracy over democracy...
by turkeydance

if meritocracy over democracy is his choice, who decides what is "merit"?

JW: Great question. One thing that's important to me is that we continually question how well we apply the principle of meritocracy in practice. In general, we try to define our business goals and the problems we're trying to solve in clear and objective terms, so that it's obvious to everyone what the best and most feasible ideas are. You can get a feel for what kinds of information and detail we share internally by checking out the Open Decision Framework, which is a collection of our best practices for making open and inclusive decisions. We think of meritocracy as a leadership behavior, and you can see how we define it here. (PS: You can also find it on GitHub under a Creative Commons license.)

In practice at Red Hat, people with a long history of contribution and good ideas build their reputations as people to be listened to. It's not a perfect process, but because it is a "multi-round game" with reputations built over many interactions, it's a pretty good way for informal leaders to emerge.


Enterprise Desktop Market / Emerging / Demand
by GioMac

I am running more than 250 Linux desktops at the company and can get even more, but there is no centralized management solutions for that, and that's an issue with customization and security too. KDE desktop is very good at some point with it's ability to have strict configuration files and immutable options, that does about 25% of what we can get with Microsoft and Group Policy Object, and we see that a little effort is required to make things work.

Can we expect that Red Hat will enter that market in the nearest (3-4 Y) future?

JW: I appreciate the feedback and idea for a new market for us. Let me take that feedback back to our desktop team. I really can't talk about future product plans in this venue, but I'll make sure they know that you see an opportunity here.


RHCA Exams
by kamilyunis

My question is about Red Hat Certified Architect exams. It is very good and we are very happy about Red Hat's new subscription-based trainings. It is great. But when it comes to RHCA, it is limited for locations.

RHCA level exams are very expensive, and travel and accomodations make it more expensive. I am 2xRHCE, because of these exams is available in my location. Azerbaijan Baku, MIddle EAST, Caucasus does not have center to take exam. Please take this into consideration. Vmware, Cisco, Microsoft, AWS, OpenStack make their exams available in everywhere online, so it is easy for everyone to take it. Why open source company limits people passions to location.

I believe that me and people like me can become multi level RHCA if they get chance to take exam in their own location. And this will help recognition and value of RedHat in regions also. Please make this available as Cisco for us. At least make it possible on Kiosk In Georgia or Azerbaijan so we can take exams also. I am from Azerbaijan, Baku. With Loves to best open source company in the world.

JW: We recognize the need to reach people who are interested in certification throughout the world. We are constantly expanding our global testing options, and increasing the number of ways we offer testing for our certifications, including adding secure, preconfigured kiosks and laptops with our Red Hat Training Partners.


==========================================================================================================
Red Hat Enterprise Linux is too static to keep pace with kernel devel.
by nbritton

I have found that Red Hat Enterprise Linux is too stagnate / static to keep pace with the rate at which the kernel is now developed. The 3.10 kernel is four years old at this point and the fact that Red Hat Enterprise Linux 7 will be in production support until 2024 is disheartening because the enterprise industry will be a decade behind the latest kernel developments and updates from associated projects. Compared to other vendors' Linux offerings, when I use Red Hat Enterprise Linux I get the same feelings I got when I was force to use AIX, HP-UX, and Solaris. I hated administrating those products because they were stuck with defaults like ksh from a decade ago.

My question is, would Red Hat ever consider releasing a Linux distribution with a shorter development cycle and with more aggressive tracking of upstream projects? I see a place for a distribution that is somewhere in between Red Hat Enterprise Linux and Fedora. Perhaps you could morph or fork CentOS into the upstream development for Red Hat Enterprise Linux? For example: Upstream --> Fedora (Bleeding Edge) --> CentOS (Next Release of Red Hat Enterprise Linux) --> Red Hat Enterprise Linux. This would give system engineers and architects a greater range of products to choose from and it could help stabilize Red Hat Enterprise Linux even more then it already is.

In short, the Linux kernel is the largest and the fastest moving software project in the world, so what changes are you going to make to keep up with it?

.....................................................................................................................................................................................................................................

The Price of Reliability
by hcs_$reboot

Worked on SunOS, Solaris, MacOS, Red Hat, CentOS, and, more recently, Ubuntu. CIOs choose Red Hat mainly for support and reliability. Reliability is the word that comes to most engineers mind when the RH and CentOS OSes are mentioned (certainly for good reasons). Reliability mainly relies on using older kernels and features, that have been patched over and over ; sure, that works, reliability wise. But on a number of rather recent projects, comparing Ubuntu server and RH/CentOS, it appears setting services up (eg Samba) was way easier on the newer Ubuntues than on the latest RH/Centos (not mentioning the many issues migrating from 6 to 7) . Also, using newer kernels, Ubuntu performs well, taking advantage of the newest internals, memory management and sharing, IPC etc ... and no specific reliability issue (IMHO, reliability wise, Ubuntu and the like are as solid as RH nowadays).

Question: in 2017, does reliability still mean using long-tested, but older kernels and features?
==========================================================================================================

JW: There's a common misperception that Red Hat Enterprise Linux pulls a Fedora kernel and stays on it for 10+ years while the world moves onto newer kernel versions with better features and newer hardware. It's true that we standardize on a specific kernel version for the life of a major release, but that's not the whole story.

Our stability is actually in our kernel ABI (kABI), which is a promise of stability that a kernel developer can rely on for the life of a Red Hat Enterprise Linux release. When we release a major version of Red Hat Enterprise Linux we actually backport many key features from newer kernels, bugfixes, etc. and we do it in a surgical way that not only delivers new features and hardware on an older kernel, but also preserves the kABI. For example, Red Hat Enterprise Linux 6 was based on the 2.6.32, but when we released Red Hat Enterprise Linux 6 it also had an additional 2600 patches (features, hardware, bugfixes, CVEs) and this continues for the development life of the release. The stats on Red Hat Enterprise Linux 7 are similar. This provides a customer expected balance between stability and innovation. We also have a driver update program (DUP) that makes it easy to add kernel drivers prior to the public availability of the next minor release.

So don't take the kernel version at face value -- we spend a lot of time backporting newer kernel features into every major release! If you want the latest and greatest and don't care about kABI, ABI and long-term stability, Fedora is ready for you.

Enterprise customers continue to expect stability, security, scalability and reliability, but also want higher levels of automation and ease of use, multiple deployment methods (bare metal, virtualization, containers and cloud) and the new features as they appear upstream and with hardware and userspace tools that can help to exploit them. If we sense critical new features going upstream that will break kABI and can't be backported, we will plan accordingly.

Comments

Complete cop-out

[Anonymous Coward]

A complete cop-out over systemd, we're hurting from the bugs and the architecture, not the change of itself. Unfortunate, I'd hoped for more than a standard systemd marketing blurb cut and paste.

Re:Complete cop-out

[ShanghaiBill]

A complete cop-out over systemd

He answered the question. Just because you don't agree with him doesn't make his answer a "cop out". What were you expecting? Red Hat created Systemd. It is their baby. They are not going to abandon it. If it is so important to you, then install Slackware, and you will not only be able to tweak your init system, but you can tweak anything else you want, and experience pure raw Linux.

Re:Complete cop-out

[drinkypoo]

It's a cop out because it's lies and misdirection. "The problems an init system needs to solve today are different from the ones that traditional init systems were solving in the 70's, 80's and even the 90's." No, it's doing the same goddamned job. "This also makes it easy to use cgroups to configure SLAs for CPU, memory, etc." No, since redhat used boilerplate for all initscripts, it would have been easy to insert the simple shell commands to create cgroups and put daemons into them into every initscript. "the sequential ordering of the init rc script mechanism" was already addressed in redhat, since their initscripts had dependencies listed. You could just use OpenRC in parallel mode, and they had included all the information needed to do that already. "meets our customer's expectations around capabilities, stability, maturity, and community momentum" is also pure horse shit. It does not add any new capabilities, it is horribly unstable, it is not even close to mature, and much of the community has rejected it outright.

People who tell lies are liars. Jim Whitehurst is a liar.

Re: Complete cop-out

[Zero__Kelvin]

You have a reading comprehension problem combined with literally zero knowledge of systemd. I have investigated it thoroughly as well as put in the relatively minimal effort to understand and leverage it. Everything he said was spot on.

Re:Complete cop-out

[Anonymous Coward]

"much of the community has rejected it outright"

If you bothered to read his response, you would have read that the # of customers has increased steadily since systemd was introduced. So what you said are pure lies.

People who tell lies are liars. Martin Espionoza is a liar.

Re:Complete cop-out

[Anonymous Coward]

Red Hat did not create systemd. It's not their baby, they just adopted it.

None of the "answers" here really answer any of the questions, with the possible exception of the initial "What is your day like?" It's all just empty marketing speak that doesn't tell us anything.

Re: Complete cop-out

[Anonymous Coward]

Your comment would carry more weight if you weren't a well known Lennart fanboi who in previous discussions on systemd showed a distinct lack of understanding and then started cheering yourself on using an AC sock puppet once the jig was up.

Re:Complete cop-out

[ArchieBunker]

Redhat's business model is selling support so creating something that easily fucks up your system is their cash cow. Expect /etc to be morphed into a single binary database next. Just you wait...

Re:Complete cop-out

[squiggleslash]

No, it's doing the same goddamned job.

No, it really isn't. Since the 1990s, we've heavily moved to hotpluggable hardware thanks to USB, networking has gone from "Basic and optional" to "Ubiquitous and complex" thanks to high speed Internet, wireless mobile Internet (be it cellular or multiple WiFi hotspots), software firewalls, etc, and those are just two major differences off the top of my head that will impact an operating system's core start up and daemon management system.

And, let's be clear here, init was always shit too. I had numerous problems back in the 1990s with it if, say, a key service couldn't be started.

It's not a cop out. He's not lying, you're just yelling "Lah lah lah" because you don't want to accept the basic reality that systemd is there to solve a legitimate problem. And the bit that gets me is you don't have to live in an alternative universe where init is still viable to criticize systemd. It's legitimate to say "Yeah, but systemd has problems X, Y, and Z."

What's a cop out is you pretending that everything's fine with an init system, that virtually every serious professional Unix-like OS - from Solaris to macOS, and almost all GNU/Linuxes even before systemd came along - has thrown out, is fine, and that therefore systemd is unnecessary. Because that cop out, aside from being wrong, lets you off the hook in terms of building a case against systemd.

And the reason you need to be off that hook, is because actually it's relatively hard to build a legitimate, non-nitpicky, case against systemd. It's actually a pretty good system. There's been problems, I'm still annoyed at that security hole involving numeric usernames and its handling for example, but by and large it's a massive improvement on what we had before. Massive.

Re:Complete cop-out

[Anonymous Coward]

He answered the question. Just because you don't agree with him doesn't make his answer a "cop out".

Well no, what he actually gave was $STOCK_CORPORATE_RESPONSE, it's pretty much word-for-word what we've already seen repeated ad naseum whenever our complaints are ignored. I'd have hoped for a little more insight or originality, but then I guess they don't hire CEOs to be original thinkers.

Re:Complete cop-out

[Anonymous Coward]

If you bothered to read his response, you would have read that the # of customers has increased steadily since systemd was introduced. So what you said are pure lies.

Another nice bit of misdirection there. The # customers was increasing steadily before systemd was introduced, also. You can read the success story here, and then consider that systemd didn't get included in a saleable Redhat product until mid-2014.

Looking at the figures, the best you can say is that systemd was a monumental waste of time for the whole industry.

Re:Complete cop-out

[Anonymous Coward]

you forgot training and testing.

Re:Complete cop-out

[Anonymous Coward]

Yes, it is much worse than a cop-out.

Embrace, extend, extinguish. systemd is clearly in the second category. The extinguish comes next because systemd introduces a nasty -- encrypted log files. That's all you have to do to break things for the 99% -- and that is the only group that matters.

Re:Complete cop-out

[Anonymous Coward]

"No, it really isn't. Since the 1990s, we've heavily moved to hotpluggable hardware thanks to USB,"

Who the fuck has hotpluggable USB devices in their server room?

Smart people run RHEL on VMs and moving hardware like disks etc is NOT fucking done via USB.

systemd is SIMPLER???? Yeah... nmcli is a fucking joy to use. firewalld is a hot piece of trash.

Re:Complete cop-out

[Anonymous Coward]

Oh...you mean the System Registry?

Re:Complete cop-out

[iggymanz]

CEO is copping out and you are spewing in ignorance.

macos is a desktop system, and I'll agree systemd might be fine for a desktop system.

The other Unix have superior systems to systemd for init that actually address enterprise needs and also still prove traditional functionality/compatibility. Bringing them up is a fine way to start discussion of how systemd went off the rails as a failed attempt to make something better

Systemd does not solve any problem nor address any need for the hundreds of servers I administer. Systemd has proven to be unreliable and put systems in unstable states on those couple dozen of our servers that have that have it

Systems far more stable and well engineered than GNU/Linux, e.g. the BSD, perform wonderfully without systemd with more traditional init systems (which by the way are evolving in a sane way)

Re:Complete cop-out

[TheRaven64]

SystemD is created by Lennart Poettering, who is employed as a software developer at RedHat and was for all of the time that he worked on SystemD. In what way does this mean to you that 'Red Hat did not create systemd'?

Re: Complete cop-out

[Anonymous Coward]

This.

Re:Complete cop-out

[HiThere]

I'm not sure how much it's lies, but it left me feeling that there was it was adopted because of some agenda that wasn't being revealed.

Personally, I have seen *NO* advantage in systemd, and as a Debian user I felt the adoption of it was an unpleasant surprise and never justified.

There are several features of it that I do not like, particularly the lack of transparency. With shell scripts I could figure out what was happening, with systemd It's "depend on the developers".

That said, I can see use cases where it is probably a real advantage, they just don't help me, or any other person running a small number of machines. There may be some benefit that's invisible to me, but every justification I've encountered has been either patently false, or not true on experiment, or, at best, dubious. And I've encountered a few times when it was a real problem.

I'm not the kind of person who "fights city hall", so I haven't switched away from debian, but I've sure considered it a few time, and if there were a bsd system with read/write support for ext4, or even ext3, I probably would have. And I'm keeping an eye on Devuan...if they seem to be a stable distribution I may switch.

Re:Complete cop-out

[xkahn]

Red Hat may make money from support, but consider that every time a support case is opened, Red Hat is losing money. Most businesses work very hard to reduce the number of support cases that get opened because of this. Red Hat won't be an exception there.

Re:Complete cop-out

[Anonymous Coward]

Was it propagated on its merits, or was it chained to Gnome desktop?

Should systemd be subject to peer review by being replaced by something else better, Or is it augered into the distribution with no hope of innovation outside systemd allowing it to happen?

Re:Complete cop-out

[Tough Love]

A complete cop-out over systemd, we're hurting from the bugs and the architecture, not the change of itself. Unfortunate, I'd hoped for more than a standard systemd marketing blurb cut and paste.

I would go further and characterize every one of Jim's responses as completely and utterly devoid of inspiration. Worse actually, he gives me reason to worry about the deleterious effect that Red Hat has had and and will have on the community if he continues shitting in the nest. But that's what you get when you hire an MBA to run a technology company: a nest full of shit. Enough shit, and there will no longer be room for birds. I say, it is high time for a change of "White" hats.

Re:Complete cop-out

[Tough Love]

Expect /etc to be morphed into a single binary database next. Just you wait...

Expect Gnome 4 to build and run as a kernel module.

Re:Complete cop-out

[Rakarra]

"No, it really isn't. Since the 1990s, we've heavily moved to hotpluggable hardware thanks to USB,"

Who the fuck has hotpluggable USB devices in their server room?

Here is the assumption that the only RHEL use is for the server room, and that if the rest of the world needs a more full-featured boot environment, that the server room should have some separate for. There are quite a few RHEL desktops for those who don't like the instability of Fedora/Ubuntu/etc and need the commercially-supported OS for the commercial end-user software that runs on top of it.

Re:Complete cop-out

[Rakarra]

The extinguish comes next because systemd introduces a nasty -- encrypted log files.

I... buh. Of all the charges against systemd, this is one of the weirdest. There's nothing stopping you from having journald also write logs to text files as well.

Re: Complete cop-out

[Zero__Kelvin]

Since those things aren't true, you would think my comment would carry more weight, yet it carries the exact same weight. It seems we have found incontrovertible evidence that you have no idea how comments work. Off you go now little troll ...

Re:Complete cop-out

[renegadesx]

and much of the community has rejected it outright.

Yeah considering all the major distros use it now, you are talking bullshit. Gentoo lets you choose to not use it, but the default is SystemD.
Slackware is the only holdout left for any distro that has ever been of any consequence. SystemD is the standard for Linux, it already won that fight.

Re: Complete cop-out

[Anonymous Coward]

Classic Zero__Sense

Re:Complete cop-out

[Anonymous Coward]

> Who the fuck has hotpluggable USB devices in their server room?

Who the fuck parks their car in the server room?

Ever heard about embedded systems? No? Then maybe read a bit on wikipedia?

Re:Complete cop-out

[Eunuchswear]

And, let's be clear here, init was always shit too. I had numerous problems back in the 1990s with it if, say, a key service couldn't be started.

It wasn't init that was shit, it was sysvinit (i.e. all the crap under /etc/init.d and /etc/rc?.d) that was shit.

Poor old init(1) didn't have a chance, buried under piles of crapulous /bin/sh scripts.

Re:Complete cop-out

[Eunuchswear]

The idea that "binary, in a documented format" means "encrypted" is pretty weird. What exactly does the AC think text files are?

Re:Complete cop-out

[AdamWill]

"Red Hat created Systemd. It is their baby. They are not going to abandon it."

This isn't true, though. We would happily abandon it if something better for our purposes showed up. We've other things written by Red Hat for superior alternatives before; sometimes the alternatives were RH projects, sometimes not. Jim even said this in his answer.

Re:Complete cop-out

[rastos1]

Since the 1990s, we've heavily moved to hotpluggable hardware thanks to USB, networking has gone from "Basic and optional" to "Ubiquitous and complex" thanks to high speed Internet, wireless mobile Internet (be it cellular or multiple WiFi hotspots), software firewalls, etc

Number of USB devices I've plugged in during last 10 years that are not HID keyboard, HID mouse or mass storage: 0
Number of wifi networks in range at home: 13
Number of wifi networks in range at work: 2
Number of wifi networks to which my linux machines connects wirelessly: 0
Number of problems systemd solves for me: 0
Am I alone?

Re:Complete cop-out

[Anonymous Coward]

SystemD is the standard for Linux, it already won that fight.

Which is a shame, because it puts us right back where we were with the UNIX vendor wars of the 80s/90s. Every single daemon and service out there has special systemd patches just for Linux, which is now incompatible with the standards. All because Redhat wanted to extend Linux with their own proprietary technology to gain full control over it to secure their position in the commerical cloud computing war. The more services systemd worms its way into and replaces, the more Redhat owns Linux.

Re:Complete cop-out

[Anonymous Coward]

> Number of wifi networks to which my linux machines connects wirelessly: 0

It's okay: not everyone uses Linux on desktop machines. If you are more comfortable with Windows or OSX, that's fine.

Re: Complete cop-out

[shevegen]

You haven't explained anything Zero Kelvin - please try again to prove that what you claim is accurate.

Re: Complete cop-out

[shevegen]

I don't see how your comment has more weight - to me it evidently has less weight due to it not containing anything relevant to what the poster you replied to wrote. The fact that you need to call someone else a "troll" shows that you are still at kindergarten level. Please try to leave the kindergarten and man up.

Re: Complete cop-out

[Zero__Kelvin]

Why would I re-explain It? Whitehurst broke it down quite nicely, and even provided links you are clearly too lazy to follow. Every myth that you hear over and over again from the people who are claiming to be Linux experts, and anti-systemd, is exposed in that write-up. The truth, I suspect, is that these idiots either are anti-Linux. The other option is that they are woefully incompetent. People aren't leaving Linux for the BSDs, and if anyone would know Whitehurst would. And despite the claims that they are backing it because 'It is their baby", the truth is if it wasn't worth backing then all the major distributions would not be doing so. To claim that Debian (e.g.) uses it "because Red Hat" is beyond fucking stupid.

Re:Complete cop-out

[omnichad]

What exactly do you think encrypted means? Whatever your answer, it's wrong.

Re:Complete cop-out

[renegadesx]

How is it proprietary? Last time I checked it was licensed under the GPL All the distros wanted off init. Canonical did Upstart, which Red Hat even adopted for RHEL/CentOS 6 and designed SystemD to basically solve some of the issues with Upstart.
If SystemD never came about, everyone would have moved to Upstart.
X is not coming back either. Canonical tried their hand at Mir but Wayland is the future. The entire point of open source is the best technology wins out, and all the distos out there went with SystemD. Unless your distro is "EL" based you don't have to use it. Hell Debian and Red Hat are still nothing alike and Debian went down the SystemD path.

Never comment but...

[Anonymous Coward]

Read Slashdot since 2003, but I almost never post. Sure, I'm still posting as AC. Posting here in the (hopeless) hope that somebody will read this and reconsider...

I've been an (advanced but uncertified) RHEL and CentOS system administrator and user for 15 years now. My first work started with Redhat Linux 9. I am now holding on to RHEL 6 for dear life despite spending significant effort evaluating RHEL 7. I find systemd distributions to be buggier, less reliable in general, and harder to administer. I won't go into details in this post, because they are amply present elsewhere on the web. I find the community surrounding systemd, especially with respect to "principle of least surprise"-violating behavior to be disheartening to say the least.

I viewed RHEL 4, RHEL 5, and RHEL 6 with excitement, and I embraced the changes that came with each distribution as mostly improvements. I am not afraid of learning a new system for the sake of improvement. With RHEL 6 end-of-life fast approaching, however, I am preparing to switch all the institutions and environments I support to FreeBSD. This isn't meant as any sort of threat but just as a fact that I have sadly resigned myself to accepting. In the early days of RHEL 7, I vehemently hoped that RHEL 8 would move off systemd. As the years marched on without any signs of such a decision and an apparently doubling down on systemd, I feel like I have no options for a reliable init system without the wealth of bugs and breaking decisions systemd developers seem to feel comfortable routinely making.

With all due respect, and choosing my words very carefully, I think you are somewhat mistakenly perceiving the nature of the broad acceptance of systemd across distributions. I think its somewhat component-viral nature has forced its adoption in many cases, and it seems quite apparent that this has happened to the effect of far greater antagonism and technical pitfalls than of advantages.

This is deliberately not written as a technical critique. Those can be found elsewhere. This is written as an entreaty from a random anonymous coward on the Internet on behalf of many anonymous cowards that, in my experience, systemd may not be as well-received as it seems. Definitely too late for RHEL 8, I know, and I don't approach a FreeBSD transition lightly. I know how silly it must sound to transition from the Linux to BSD philosophy and environment over an init system, but reliability is key for me and for those I serve.

Thanks for your responses.

Re:Never comment but...

[Anonymous Coward]

SYSTEMD IS SHIT.

Re:Never comment but...

[Anonymous Coward]

Meanwhile, the rest of us have adapted, find systemd works just fine and have moved on with our lives.

A BAD WORKMAN ALWAYS BLAMES HIS TOOLS

Re:Never comment but...

[Anonymous Coward]

A BAD WORKMAN ALWAYS BLAMES HIS TOOLS

A professional tool is more forgiving than a crap tool, every professional knows that. A crap tool that you are forced to use is a special kind of bad.

Meanwhile, the rest of us have adapted, find systemd works just fine and have moved on with our lives.

No you haven't, you just haven't been in a situation where systemd fucked you. Here is an example taht happened the other day to me, svchostd, erh systemd, remaps the keyboard in some distributions (Linux Mint 17) so that the pipe character isn't accessible from the keyboard when you use a console, like in a system recovery situation.

oh no, blame your distribution, is the predictable response.

Re:Never comment but...

[Anonymous Coward]

I don't think it's fair to put it mildly to so quickly characterize OP as a bad workman. OP claims to be seasoned and claims a history of welcoming adaptation. Hell, 15 years is longer than I've done sysadmin work but its mostly gotten easier over the years.

I'm in almost the same situation as the OP with EL 6 death. Considered other distros but have no confidence that SystemDeath won't penetrate them too. FreeBSD is the safest choice long-term and thats where I'm headed. If you personally have never been screwed by any of the unpreparable gotchas then good for you but that doesn't make you better than OP or me. Might mean you havent done enough work to hit the rarer corner cases that dont get adequately tested.

Re:Never comment but...

[Anonymous Coward]

Linux Mint is developed by assclowns. Stupid security breaches, stupid package name conflicts, and their attempt at a rolling-release Debian Edition was a complete clusterfuck. Also, no one takes your desktop issues seriously. If that's all you use Linux for, suck it up and buy a Mac. The rest of us are concerned with the world's foremost server platform, and our ideas about stability and reliability are in direct opposition to your shiny-UI mentality.

Also, "it remaps the keyboard" => "I don't know how to configure locales correctly, waaaaaaah!"

Re:Never comment but...

[TheRaven64]

A BAD WORKMAN ALWAYS BLAMES HIS TOOLS

True. A good workman, in contrast, picks the correct tool as the first step in working on any job and sidesteps a lot od the problems that a bad workman faces.

Re:Never comment but...

[nctritech]

You don't shoot an IMAX movie with iPhones. You can say a bad workman always blames his tools...but when he's a carpenter and he's handed a piece of rebar and some chewing gum to measure, cut, and hammer, he has to go out of his way to learn to become MacGyver to work with the garbage tools he's been handed. Even then he's still going to produce some pretty crude work.

systemd is rebar and chewing gum in the hands of a carpenter.

Re:Never comment but...

[bluelip]

systemd is 'popular' for the same reason IE is. They're included with the OS. Neither would be chosen on their own merits.

Re: Never comment but...

[Anonymous Coward]

Unfortunately, every major distro maintainer disagrees with you. Should make you think.

Re:Never comment but...

[Anonymous Coward]

And yet they still manage to patch root kernel vulnerabilities months before Redhat lazily get around to it. The time to patch and critical exposure to known vulnerabilities on Redhat is appalling.

Re:Never comment but...

[Anonymous Coward]

Enjoy BSD, it's a fine OS family, and you can take your Bash scripting skills with you to the grave.

Re: Never comment but...

[Anonymous Coward]

Yes. Every member of the Debian technical committee voted for systemd -- it was a unanimous decision! /s

Re:Never comment but...

[Anonymous Coward]

I'm adding this here as the most technically egregious offenses related to systemd

Part of the reason why this award was given:
https://www.csoonline.com/arti...

Systemd dies if there is no cgroup support in the kernel.
Poettering: "To make this work weâ(TM)d need a patch, as nobody of us tests this"

R! /dir/.* destroys root.
Poettering: "I am not sure I'd consider this much of a problem. Yeah, it's a UNIX pitfall, but "rm -rf /foo/.*" will work the exact same way, no?"

Processes owned by a user with a leading zero in the name are started with root privilege..
Pottering: "I don't think there's anything to fix in systemd here"

Systemd kill background processes after user logs out.
Poettering: "In my view it was actually quite strange of UNIX that it by default let arbitrary user code stay around unrestricted after logout."

'I have an issue with journal corruptions and need to know what is the accepted way to deal with them.'
Poettering: "Yupp, journal corruptions result in rotation, and when reading we try to make the best of it. they are nothing we really need to fix hence."

'Poettering locked and limited conversation to collaborators on 17 Apr'

Re:Never comment but...

[mvdwege]

Systemd dies if there is no cgroup support in the kernel. Poettering: "To make this work weÃ(TM)d need a patch, as nobody of us tests this"

And this very first entry made me stop reading. You're a moron.

In order to be able to constrain services' resource usage, systemd needs cgroup support, that's why it is, among other things, a cgroup manager. Obviously running without cgroups is not a supported configuration right now, as who in his right mind would run a fucking cgroup manager without cgroups?

Re:Never comment but...

[Anonymous Coward]

You say he's a moron, yet you're the one that ignored all the other good points because of one you didn't think was correct. You're the fucking moron.

Re:Never comment but...

[mvdwege]

I'm just being efficient. If the very first point of a longer post is moronic, I can expect the rest to be the same tired FUD, so I just skip it.

Re: Never comment but...

[Anonymous Coward]

Nobody voted for sysvinit. Though Devuan was started to provide only sysvinit as a supported init system (choice is bad!).

Re:Never comment but...

[Eunuchswear]

I viewed RHEL 4, RHEL 5, and RHEL 6 with excitement,

You need to get out more.

Re:Never comment but...

[Eunuchswear]

Don't worry, the others are moronic too.

Re:Never comment but...

[Anonymous Coward]

If you mean Poettering's responses to these issues are moronic, I agree

If you are saying the poster is moronic, please explain, citing history as to why those are not valid criticisms? I'm pretty sure the actual history and his quotes are accurate.

Re: Never comment but...

[Anonymous Coward]

You might want to review the relevant discussion on the Debian mailing lists.
The so-called TC "vote" was anything but.

Re:Never comment but...

[david_thornley]

Except that, if you want Windows, you take what Microsoft offers, which includes built-in IE. (It's perfectly usable to download a decent browser. Don't knock it too much.)

Every Linux distro is a different but similar OS. It's entirely possible to keep systemd out of a distro, but nobody actually does. If it were really that horrible, someone would have a non-systemd distro that would become popular. Until this actually happens, I don't see how systemd can be that bad.

Re:Never comment but...

[TechnoJoe]

Perfect is the enemy of good. For all of my use-cases, good is good-enough. Then again, my use-cases are not your use-cases.

Now, you have piqued my interest. What sort of use-cases do you have that are dependent on a specific init system? The only thing I can think of is something so integrated into the low-level OS stuff, like starting/stopping the process, or system logging, that it will require a lot of development work to rewrite for systemd.

Care to fill me in?

Re:Never comment but...

[shevegen]

Yeah. It is unfortunate that Linux MINT went the systemd route. You can look at their blogs how they praise systemd. Of course they never gave specific examples as to how this makes: a) their life easier and, more importantly b) the life of users easier The usual "argument" is "we use it because all distributions use it". And, honestly - that is not a good argument at all.

no question about remote display

[e70838]

gnome 3 and others are focusing on desktop use where most of the enterprise use of RHEL I have encountered is using remote display. I feel as if the desktop team is killing the main use case.

Thanks!

[Mike Frett]

Thanks Mr. Whitehurst for taking the time to answer our questions! Personally I'd like to see Red Hat or Canonical make a push to switching Government, Health Care and School systems over to something besides Windows.

Re:Thanks!

[Koen Lefever]

Personally I'd like to see Red Hat or Canonical make a push to switching Government, Health Care and School systems over to something besides Windows.

They could join Debian, Gentoo and OpenSUSE at the Public Money, Public Code campaign.

It sounds like you might want to sign the petition there.

A CEO who can code, that's a news!

[Cyberax]

A CEO of a multi-billion corporation who actually tries to keep up with his technology down to the nitty gritty details. No wonder RedHat is going well!

Re:A CEO who can code, that's a news!

[ShanghaiBill]

A CEO of a multi-billion corporation who actually tries to keep up with his technology down to the nitty gritty details.

You are assuming he wrote all his own replies with no help from any of his 10,700 employees.

Re:A CEO who can code, that's a news!

[AdamWill]

He probably did. Quite a lot of Red Hatters have a story about getting an email from Jim out of the blue asking for help with some crazy-ass nerd project he's working on. He once mailed me asking about getting the out-of-tree Poulsbo drivers working (which is something I was messing around with at the time) for some funky device he was trying to get Fedora running on.

He's not a full-time engineer or anything, but he's as much of a tinkerer as many /. readers. That was one of the things that got him hired as CEO, he was already tinkering around with Linux when he was at Delta.

Summary of systemd NFS answer; on "merit" adoption

[rknop]

"[b]It is best not to blame systemd for problems that go away when you stop using systemd.[/b]"

Do I [i]know[/i] that systemd was the problem? Nope. Have I had things go much more smoothly for me since I moved away from an extremely popuar distribution that uses systemd? Yep.

What's more, the argument that everybody is using systemd based on its merits is specious. That's the same as the argument that Windows and Word and the like is what's most used in the corporate world on its merits. When your octopus wraps its tentacles around so many different things, it eventually gets impossible to ignore your octopus. You can keep trying to move away, but sooner or later it's just easier to give in and deal with it, rather than keep trying to fight it. This is what happened with Internet Explorer back when it had loads of incompatible extensions that sellers of corporate software would use; you had no [i]choice[/i] but to use it. And now that systemd has sucked in so many subsystems, it's become more effort to try to keep using versions of those subsystems than it is to just give in and use systemd. That's not giving in to systemd based on its merits. It's giving in to a company who has used embrace and extend as a bully tactic based on its strength and control over key things in the ecosystem.

Missing the point

[MadTinfoilHatter]

"Any change like systemd is going to disruptive."

And that's where he completely misses the point. In the UNIX world, swapping out one component for another doing the same thing should be like swapping out a Lego (tm) brick for a different colored one. It doesn't have to be disruptive, and if it is YOU'RE FUCKING DOING IT WRONG!!!

Re:Missing the point

[Anonymous Coward]

Except it's not doing the same thing.

The old inits just started a process and left it at its own devices, and you had a few functions to use the pidfile to instruct the process to do something using a signal.

SystemD is the whole middleware where init and service management are just one part of it. Even if you don't use (and shouldn't!) badly reinvented wheels like resolved, networkd, timesyncd, hostnamed, ...d, the core of it is init + process management + containerization of services, not just fire-and-forget-and-maybe-send-a-signal-using-pidfile-for-reference.

The fact remains that THAT set of functions are good. Using a simple INI-like file to set up how a service starts, how it stops, how it is contained (ro, rw dirs, host-side mounts, capabilities, syscall filters, ...) is really superior than any alternative in the Linux world. And all the start jobs and stop jobs that interrupt the start up or shutdown process, are actually exposing the problems in those services. PLUS, just set a very low timeout and it'll mimic the old "kill on sight if term is not obeyed" functionality.

The REAL problem here are distro maintainers who obviously do NOT understand SystemD and then proceed configuring things BADLY. Bind in Ubuntu does not observe env in /etc/defaults/bind because the maintainer wrote a bad unit file. Dovecot suddenly unable to write mail files because the maintainer set ProtectSystem=full without allowing rw paths mounted separately.

Of all the issues I've had with SystemD so far, vast majority were due to bad configuration or bad integration in the distro. That's the problem, those people voted for SystemD and then.... did not actually made any effort to ACTUALLY use it as it should be used...

And sure, there's a number of intrinsic bugs, developer attitude and ignorance of standards, etc... thankfully, that shit can be easily worked around, and even then the good parts (mentioned above) still outweigh these bad things.

BTW, inb4 someone complains, ain't nobody gonna tell me how to spell SySteMD.

Re: Missing the point

[Anonymous Coward]

I'm not going to complain. You're spelling SystemD in the correct ASCII penis style.

Re:Missing the point

[AmiMoJo]

If nothing was disruptive there would be no progress. Part of the reason Windows was so buggy and crap was all the legacy compatibility stuff in there.

Re:Missing the point

[gosand]

"Any change like systemd is going to disruptive."

And that's where he completely misses the point. In the UNIX world, swapping out one component for another doing the same thing should be like swapping out a Lego (tm) brick for a different colored one. It doesn't have to be disruptive, and if it is YOU'RE FUCKING DOING IT WRONG!!!

I haven't done extensive research on systemd, but I did notice stability issues with my distro of choice (Mint) when they switched to it. I can't cleanly shutdown or restart my system. I have seen no advantages with it, only annoyances. But despite all of that, what I don't understand is the flippant attitude around systemd and distros where systemd is referred to as "just another component". It's not! If it were then I, or someone with much more skill than me who works on it for a living, would be able to easily replace it with something else. The fact that it can't be easily done, or given as an option for a distro, illustrates how it goes against the grain of the *nix philosophy. It honestly reminds me of the inability to uninstall IE in Windows problem. Except that we shouldn't have that problem in the *nix world.

Philosophically, I like the idea of systemd in that I believe in the inherent worth of trying to create something new, maybe it will take off and be better than what was there before. But it should do that on its own merits! Like so many things in the FOSS community have done over the years. Systemd seems to be different to me. It seems to be more of a force-fit, a group-think mentality. The CEO himself says so as an endorsement of systemd "There's not a realistic alternative today that comes close in terms of adoption and functionality." That's like Microsoft crowing about the adoption rates of Windows 10, right after strong-arming people to adopt it. Granted, it's not quite like that in the Linux world, but when distros adopt it simply because everyone else is doing it, it's not that far off.

We still have some choices though, thankfully. I am still using systemd, but I am not happy with it. I am pretty loyal to my distro, but systemd is one of those thorns in my side that I will gladly miss if/when I switch to a different one.

Re:Missing the point

[Anonymous Coward]

Tell me again how moving from Firefox to WebKit to Chrome was disruptive. All of the developers I know never complained about them, but instead bitched about having to code for the lowest common closed source denominator, a shitty version of IE.

Re:Missing the point

[Anonymous Coward]

Argh, still no 'like' button!

Re:Missing the point

[Etcetera]

SystemD is the whole middleware where init and service management are just one part of it. Even if you don't use (and shouldn't!) badly reinvented wheels like resolved, networkd, timesyncd, hostnamed, ...d, the core of it is init + process management + containerization of services, not just fire-and-forget-and-maybe-send-a-signal-using-pidfile-for-reference.

The fact remains that THAT set of functions are good. Using a simple INI-like file to set up how a service starts, how it stops, how it is contained (ro, rw dirs, host-side mounts, capabilities, syscall filters, ...) is really superior than any alternative in the Linux world.

The thing is, THAT set of functions could also be provided by a service hanging off of a traditional init and traditional rc-level, script-based startup process.

Need proof? We already have something that does half of that:
xinetd

Those of us that need socket-based activation, environment cleaning, log file descriptor tracking, auto-restart-on-fail, or simultaneous startup (for things this actually provides a benefit for, which is less than you think) can use tools like inet, xinetd, or monit, runit, or daemontools/supervise (or one of its clones) to handle that. And what doesn't exist already can pretty easily be patched in, or added to runscripts (or, as was mentioned, initscript boilerplate in /etc/init.d/functions).

If no one added cgroup support to xinetd, or wanted it setting up tmpfs mounts everywhere, it was because no one really saw a need for it. But these features could have been added without blowing up the startup process the way systemd has.

systemd biggest fallacies

[rknop]

Also, since he links to the partially-good-argument, partially-prevarication "systemd Biggest Myths" article, it's also worth linking to this few-years-old "biggest fallacies" article.

Re:systemd biggest fallacies

[AmiMoJo]

I think a lot of the technical arguments about systemd are really just because Pottering is an asshat and poisoned the well early on. Debian are mostly correct about it, it's basically a good idea and while there are implementation issues from time to time it's not like any other init system is perfect either.

The real problem is that the developers are dismissive and don't always take good advice on board. Maybe that's partly because of all the hostility and every minor issue being turned into a huge drama, but failure to recognize serious issues like the recent root escalation flaw is a serious problem.

Re:systemd biggest fallacies

[Anonymous Coward]

Pottering created the Pulse audio system and that's pretty awful as well

Re:systemd biggest fallacies

[Anonymous Coward]

That wasn't root ESCALATION flaw. That was unpriv user DE-ESCALATION flaw. Services are always root unless instructed not to be, in every init system since the dawn of.... init systems. That's a HUGE distinction right there.

Was it a big problem? Fuck yea. Is it worth all the drama that it accrued and the CVSS score it got? Fuck no. Should Poettering be fired because of his response to the problem? Yes. RH reputation is being harmed because of Poettering's ignorance.

Re:systemd biggest fallacies

[TheSunborn]

No it's not. Pulse audio is far better then what we had before. The ability to control audio volumes per application, and the viewer which shows all input and output is really really good.
 

Re:systemd biggest fallacies

[Anonymous Coward]

Don't forget that Poettering won the Pwnie award for the worst vendor response.

Re:systemd biggest fallacies

[Anonymous Coward]

No, they really are technical arguments. They were at the time and they still are now. The personality thing was not the point, it was the personality rejecting the technical arguments out of hand because they had no technical response, that made him the arsehole.

Let's not revise history with 'some people just don't get along'.

(to be fair the response of quite a few to not getting a reasoned technical response also made them behave like arseholes.)

Re:systemd biggest fallacies

[Anonymous Coward]

Not that one again, alsa does that fine and has for a long time.

It's not pulseaudio existance thats the problem. It's the had depends on it,

Same with

On a plus side firefox no long having alsa support + a plugin to prevent autoplay and buffering of video now means I can using the open with mpv plugin outside the browser, don't have to hunt for the tab making all the noise.

I would never have thought that applications moving away from code I use could have such positive outcomes.

Re:systemd biggest fallacies

[Anonymous Coward]

The REAL problem is that systemd is so difficult to avoid and extract -- given all of the unnecessary, arbitrary dependencies on it.

Re:systemd biggest fallacies

[TeknoHog]

I guess software volume control is enough for the same kids who think lossy-compressed music over white iBuds is the beez kneez.

Re:systemd biggest fallacies

[Rakarra]

Alsa was really only good if you were trying to do the basic, bare-bones configuration and you had an audio card with proper hardware and properly-supported hardware. As soon as you got into things like a sound card that didn't do hardware stream mixing and then you had to try to configure also to do dmix and a bunch of other things, you were in for a world of hurt, and pulseaudio was a breath of fresh air.

The person who said "pulseaudio is awful" and the one who said "pulseaudio is far better than what we had before" are both right. For a number of years, pulseaudio was absolutely awful, and these awful versions made it into a number of 'stable' distributions. Somewhere around version 0.9.21, it started to stabilize and become reliable, and it seems pretty good now. But of course, that early reputation lingers, because it was pretty bad.

Re:systemd biggest fallacies

[Anonymous Coward]

Until you have to do something that isn't a desktop.

Re:systemd biggest fallacies

[Eunuchswear]

given all of the unnecessary, arbitrary dependencies on it.

If the dependencies are unnecessary then they should be pretty easy to fix, yes?

Re:systemd biggest fallacies

[shevegen]

> I think a lot of the technical arguments about systemd are really just because Pottering is an > asshat and poisoned the well early on. This was never my problem. Poettering may be an asshat or not, I have no idea. What I do know is that he has been wrong numerous times and still isn't learning from his past mistakes. But this is also not the interesting part. Systemd itself is also not interesting. The, to me, MUCH more interesting part is how distributions adopted systemd without asking the users. Now THAT is true asshattery. Understandable that Red Hat is doing so because it's a shitty greedy corporation, but that debian (!) went to betray its users - now THAT is really the most interesting part of it all. The Arch situation is no issue, ever since jud left, arch died. VoidLinux is the new Arch there. > Debian are mostly correct about it, it's basically a good idea Huh? How, why and where is it a "good idea"? You have not given any argument, as is typical for pro-systemd posters. > The real problem is that the developers are dismissive and don't always take > good advice on board. Maybe that's partly because of all the hostility and > every minor issue being turned into a huge drama, This is not a "minor issue". The fact that you have so many people oppose systemd speaks for itself. You also have distributions that specifically do NOT use systemd. So, a totally disruptive technology - and you call it a "minor issue"? That shows that you are blind.

Re:systemd biggest fallacies

[shevegen]

Where would it be "better"? It added a lot of complexity, along with its own new failures. > The ability to control audio volumes per application, and the viewer which > shows all input and output is really really good. That is like cherry picking one thing and ignore the rest. How about the systems where pulseaudio does not work, the daemon not starting and can not be started? The increasing complexity in keeping your system up to date - which systemd also pushed onto people. So, no - your comment is factually wrong.

I don't like RHEL and Centos

[Anonymous Coward]

I regularly use Centos and I strongly dislike it, and in turn, I dislike RHEL. While most of the comments focus on systemd, which is not particularly interesting to debate, I have other issues. I understand the desire to provide an enterprise platform that will have a long period of extended support. That's great. However, newer software often contains dependencies that aren't satisfied by RHEL and Centos. That makes it necessary to enable third party repos that may or may not be trustworthy and can introduce compatibility issues when enabling multiple third party repos. That makes Centos a hassle to work with. They're constrained by the packages provided by Red hat, which means if RHEL is using an old version or doesn't include some packages, Centos will have the same issues. It would be very helpful to have a single trusted source of packages that might not receive the same level of support and maintenance as the main distribution, but provides newer versions and additional packages. Give users the choice of whether to enable it or not, but eliminate the need for third party repos. I use some closed source software that's built to dynamically link to the libraries available in RHEL and Centos, and those versions of the libraries may not be available for other distros like Ubuntu. That's why I run Centos in the first place, but it's a headache when you're missing libraries or newer versions of software and have to mess with third party repos.

Re:I don't like RHEL and Centos

[Anonymous Coward]

I hate to point out the obvious, but your beef is with your proprietary software vendor, not CentOS or even RH/RHEL.

It's not Redhat's fault your vendor only supports a relatively obsolete enterprise-focused distribution. It's not Redhat's fault you're trying to simultaneously run other (unnamed) software on it that doesn't support that version of RHEL/CentOS.

And Redhat does provide a "trusted repository" of more up-to-date stuff -- it's called EPEL, which is an offshoot of the Fedora project.

If your favorite software/library/application/whatever isn't available, how about volunteering some of your time to create or maintain an EPEL package for that software, instead of complaining about how someone else isn't jumping to satisfy your requests, for free?

Re: I don't like RHEL and Centos

[Anonymous Coward]

While I agree that some of the problem is with the vendor, even with EPEL enabled, there's still a lot of software that just isn't available. Centos is pretty common in academic environments and the closed source software is developed with federal funds but the university that owns the intellectually property wants to license it commercially. It's easily the best tool available to do some types of work, but they're not about to release the source code. In many cases, the source code doesn't get released for research projects in academia, for a variety of reasons, which is unfortunate.

In terms of your final paragraph, that's presumptuous of you, and such comments are frustrating. As I just noted, I wish more research projects would release source code, because it allows others to build upon their research but also to ensure the results are reproducible. The latter is a key part of science that is too often neglected. I do release my source code under the GPLv3, and I do make an effort to maintain it. My projects aren't part of the EPEL repository or anything like that, but they can be downloaded and freely used. Just because I'm not contributing to the EPEL repository and maintaining packages there doesn't mean that I'm not contributing to the availability of free software and it shouldn't disqualify me from commenting on it. Your comment is not helpful.

Re: I don't like RHEL and Centos

[Anonymous Coward]

The crux of the AC's complaint is that software they want/need isn't conveniently available for CentOS, while strongly implying that Redhat or whomever should have already done the not-insubstantial work to make it convenient for them, for free. Which is preposterous, as there isn't an endless supply of volunteer hours to satisfy every special snowflake's requirements.

The text that the GPL recommends -- "This software is released in the hope it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE." makes it clear that the software is a gift to the world; The author owes precisely nothing more to anyone, and expecting (much less demanding) anything more is downright arrogant at best. [*]

And as someone who's released their own efforts under a F/OSS license, I suspect you've encountered entitled users too.

[*] Unless the author was paid for it or otherwise entered into some sort of contract that says otherwise.

Re: I don't like RHEL and Centos

[Anonymous Coward]

I am the same AC, and I reread my post to make sure I didn't misspeak. I said I have a strong dislike for Centos, which is my right. It is no more arrogant than those complaining loudly about systemd elsewhere in the comments.

Nowhere did I actually say that anyone was required to meet my needs, and I made sure of that when I read over my post. I did say that there are shortcomings of RHEL and Centos. It is absolutely reasonable for users to point out where FOSS isn't meeting their needs. That provides feedback to developers, which they can either choose to address or ignore. It is the right of the developers to do as they please with those comments, though it may be wise to take them under advisement. A project that's more widely used will probably attract more developers to maintain it, and as you suggest, more people are needed to maintain repositories. It also means that users are more likely to donate their money to support their projects. I am far more likely to donate to a project that meets my needs and that I use.

In my case, I don't actually accept donations from individuals for my software, but it's still in my interests to meet the needs of other users. A lot of scientific research is funded by the government or grants from private foundations. If I can show that my software is being used by many other people, I can use that as justification for funding when I write proposals for new grants. Even though I'm not directly receiving any money from those users, it's in my best interest to support them to the best of my ability.

There are other ways to support free software as well. Many times, free software for scientific research isn't maintained once the initial funding expires. I try to contribute fixes for the software to help others who many need to use it. Also, many researchers don't really provide a lot of documentation for their software, so creating third party documentation is also useful.

I don't think it's preposterous to point out the shortcomings of FOSS. We do agree on one thing, that free software still requires work to develop and maintain. As I said, I work in an academic environment. When universities bring in grants, they charge overhead, usually about 50% of the direct costs of the grant. These are called indirect or F&A costs. Users who deploy free software on a wide scale and charge overhead costs should recognize that the free software also has costs to develop and maintain. Given the scale of these grants, often in the tens or hundreds of thousands of dollars, it would be pocket change to budget a bit of money to support the developers of the software. Considering the excesses often funded in these grants, supporting FOSS that's used to do the research would be a small pint of money that's well spent.

Re:I don't like RHEL and Centos

[jabuzz]

You know what it's 2017. Run a different distro that actually has the libraries you need for this particular software package and run that as a virtual machine all of it's own.

My view is the problem is developers insisting on using the newest features of everything for no particular reason that they are new.

Re:I don't like RHEL and Centos

[TheRaven64]

My view is the problem is developers insisting on using the newest features of everything for no particular reason that they are new.

A bunch of the stuff I work with moved quite aggressively to C++11 and then C++14 when the compiler and standard library support became available. This switch improved memory safety and improved performance. Those both seem like pretty good reasons. This is pretty common for libraries: new features are added because they make life for consumers better either by making things faster, more secure, less code, or some combination of the above.

Red Hat is pretty good at doing security back ports for popular things, but if upstream has EOL'd the version that ships with a particular RHEL release and someone finds a vulnerability then you may not get an update with RHEL. You're then stuck compiling a bunch of stuff from source, using a third-party repo (which may cause interesting conflicts), or switching to a different distro / OS.

Re: I don't like RHEL and Centos

[Etcetera]

Centos is pretty common in academic environments and the closed source software is developed with federal funds but the university that owns the intellectually property wants to license it commercially. It's easily the best tool available to do some types of work, but they're not about to release the source code. In many cases, the source code doesn't get released for research projects in academia, for a variety of reasons, which is unfortunate.

That is unfortunate, but the entire point of Enterprise Linux is that it's a platform. Your upstream vendor (who's obviously aware of Linux, Linux distributions, and "support"), should ensure that it and its dependencies are packaged and available if they claim to support the OS. And if they disclaim support for the OS, you should ask your bosses why they think buying a closed source product for an OS that's not supported was going to work out.

If you're using some weird newfangled .io product that just had it's 4th ABI break of the year this month, then yes, Enterprise Land is not where you want to be. Most other products actually are decently workable on EL6 fine, or have a requirement on something that can be downloaded on a Software Collection ecosystem.

If worst comes to worse, then yes move to EL7. Or see if your fast-moving vendor will commit to supporting Fedora with its 13-month lifecycles.

Re: I don't like RHEL and Centos

[Eunuchswear]

I don't think it's preposterous to point out the shortcomings of FOSS.

Your main complaint about FOSS is that it doesn't make it easy to run proprietary closed source software. Maybe you are aiming at the wrong target?

Re:Question, why is Trump such a dumb faggot

[Anonymous Coward]

I mean honestly. Treason like nobody would notice? Get a rope.

True. Paying for lies from the Kremlin to use against a political candidate is treason deserving of death.

Oh, wait, it was HILLARY who colluded with Fusion GPS and the Russians to lie about Trump?!?!

What? Hillary lied?!?!

What, did the sun rise in the east?

Re:Summary of systemd NFS answer; on "merit" adopt

[Gravis Zero]

"It is best not to blame systemd for problems that go away when you stop using systemd."

That reminds me of the new book from O'Reilly. ;)

Can we actually talk about NFS?

[emil]

I would actually use a cron @reboot entry for NFS mounts. I generally have a /root/afterboot.sh where I start Oracle database units, manipulate the firewall, then *lastly* mount NFS volumes. This method never hangs a boot, and it's more portable and less work than trying to configure an rc.local. I suppose that I could use systemd timer units to accomplish this, but I've never felt motivated. Vixie cron runs on a lot of other init systems.

Re:Can we actually talk about NFS?

[Anonymous Coward]

I would actually use a cron @reboot entry for NFS mounts. I generally have a /root/afterboot.sh where I start Oracle database units, manipulate the firewall, then *lastly* mount NFS volumes. This method never hangs a boot, and it's more portable and less work than trying to configure an rc.local.

Longtime Unix admin here. You need to stop making static NFS mounts and use an automounter. It is much safer and much less error prone.

Back in the day (early 1990s) if we had to reboot the data center (which happened for maintenance, etc) we had to remember the particular order to reboot systems. We always had to bring the NFS server up first so the NFS clients could mount it. Otherwise, the client would come up first, fail to mount the server, and now part of your filesystem is unavailable.

Then we had the NFS automounter, and that solved our problem. Any interruption on the network, or any outage on the NFS server, and the NFS clients work it out for themselves. Actually, if no one was using the NFS share when the NFS server went down, no one would notice.

Re: Can we actually talk about NFS?

[emil]

My introduction to UNIX was SCO on a 386 in '87, so I might outrank you. In any case, I have two mounts among thirty servers, and I don't think the automounter is worth my time. I need to worry about /home and /rpmpatchdir. I ripped out the HP-UX automounter when I started my current job, and it was more trouble than it was worth then. All of my NFS mounts are no auto, and I am essentially using pdsh to control their Mount status. Look at Linux Journal on 11/1 for more details.

NATALIE PORTMAN NAKED AND PETRIFIED

[DG]

You know, the whole time that meme was in force, I interpreted "petrified" as "physically turned to stone" - which made it harmless.

But with the Harvey W. stuff that has been finally dragged to light, it seems that "petrified" was more likely to actually be"frozen in place with fear"... which is just icky and creepy. Who'd wish that on anybody?

Not me for sure.

Anyway, Red Hat - I still have my RH 5 floppies. I transitioned to Ubuntu a few years ago, but I still have a soft spot for RH. You never forget your first.

I tell you though, there's a big difference between the P1-233 that I started with, and the Ryzen 1700X I'm on now, boy howdy.....

Whoops, the microwave dinged. Grits are hot! Now where are my pants....

Re:NATALIE PORTMAN NAKED AND PETRIFIED

[Anonymous Coward]

which is just icky and creepy. Who'd wish that on anybody?

jews. The answer is jews. The goyim know.

Re:Summary of systemd NFS answer; on "merit" adopt

[jfdavis668]

Comparing it to Internet Explorer? Why don't you just start an open source project to give it some competition, like Firefox did to IE?

How long before the dramatic reveal of the Endgame

[Anonymous Coward]

How long until Redhat subsumes control of Linux Via PID 1 and starts sending patent and copyright trolls around to other vendors and projects? Did the US Government increase your grants and investment capital to help speed this up?

New history book about Open Source Software...

[Anonymous Coward]

Check out "For Fun and Profit: A History of the Free and Open Source Software Revolution (History of Computing)" by Christopher Tozzi and Jonathan Zittrain (The MIT Press).

Re: New history book about Open Source Software...

[Anonymous Coward]

Creimer affiliate spam. Please mod down.

For me, systemd itself isn't the problem.

[SIGBUS]

As init systems go, I actually like systemd, far more than Upstart or, especially, Solaris SMF. The XML-laden can of worms known as SMF is particularly something I hope I never have to work with again (then again, with Solaris being barely on life support now, that's a pretty good bet). The only thing I'd wish is for systemd to confine itself to being an init system. Tying important system components tightly into systemd, on the other hand, is something I think is a Bad Idea.

I've ripped-and-replaced several of my CentOS 7 installations with Ubuntu Server 16.04 recently, though, and any new CentOS installs that I do will be KVM guests. Last spring, on a project, the client wanted to use an old server as a development system. I fire it up to do an installation, and whaddya know, the RAID controller doesn't show up. On a hunch, I tried Ubuntu Server just to see what would happen, and it worked fine. Unfortunately, some of the software we were using didn't support Ubuntu, so we ended up buying a cheap refurbished desktop as a development box. I could have just run CentOS as a KVM guest, but that seemed more trouble than it was worth.

It turned out that the RAID controller was deprecated in C6 and the driver was yanked in C7. No "this driver is now unsupported" warning, it was just ripped out completely. Then I discovered that the SAS HBA in my home NAS was deprecated in C7, so C8 would be a no-go unless I ate the cost of a new HBA.

That became academic when C7-1708 was released. The final straw was that the ZFS modules wouldn't build on the new kernel. Between that and the perennial problems with DKMS and weak-updates that required occasional manual cleanups, and Ubuntu shipping with prebuilt ZFS modules, it was clear to me that it was time to switch.

Kernel backporting

[Zeromous]

Boy I bet you wish you had backported Samba2 support to 2.6 kernel.

Thanks, Jim!

[Anonymous Coward]

Cheers to Red Hat and Canonical for successfully monetizing Linux and rolling it out on a large scale. You have done so much more for open source than all the haters combined ever could. Capitalism is good. Making money means you are serving lots of customers and creating real value in the market.

yum vs dnf

[Anonymous Coward]

I see that yum 4 was released for CentOS in testing recently. What does this mean for the future of yum and dnf for Fedora and RHEL. It seems like it will be difficult to maintain yum v3, v4, and dnf simultaneously across different OSes. Are there any plans to merge these projects across the Red Hat platforms in the nearterm?

Re:yum vs dnf

[mattdm]

I see that yum 4 was released for CentOS in testing recently. What does this mean for the future of yum and dnf for Fedora and RHEL. It seems like it will be difficult to maintain yum v3, v4, and dnf simultaneously across different OSes. Are there any plans to merge these projects across the Red Hat platforms in the nearterm?

Yum 4 is a frontend backed by DNF. Yum 3 is on its way out; not my area but I expect it will be maintained for the life of the RHEL versions that depend on it, but only for security updates and any very serious bugs.

I'm not sure what we'll do in Fedora with the DNF vs Yum 4 name.

Re: How long before the dramatic reveal of the End

[Anonymous Coward]

That's not going to happen.

technical issues with systemd

[Anonymous Coward]

I'm adding this here as the most technically egregious offenses related to systemd

Part of the reason why this award was given:
https://www.csoonline.com/arti...

Systemd dies if there is no cgroup support in the kernel.
Poettering: "To make this work weÃ(TM)d need a patch, as nobody of us tests this"

R! /dir/.* destroys root.
Poettering: "I am not sure I'd consider this much of a problem. Yeah, it's a UNIX pitfall, but "rm -rf /foo/.*" will work the exact same way, no?"

Processes owned by a user with a leading zero in the name are started with root privilege..
Pottering: "I don't think there's anything to fix in systemd here"

Systemd kill background processes after user logs out.
Poettering: "In my view it was actually quite strange of UNIX that it by default let arbitrary user code stay around unrestricted after logout."

'I have an issue with journal corruptions and need to know what is the accepted way to deal with them.'
Poettering: "Yupp, journal corruptions result in rotation, and when reading we try to make the best of it. they are nothing we really need to fix hence."

'Poettering locked and limited conversation to collaborators on 17 Apr'

Re: Summary of systemd NFS answer; on "merit" adop

[Anonymous Coward]

LOLOLOL!!!

So that explains...

[Anonymous Coward]

So he only learned to compile kernels and kernel modules now?
This sh*t is stuck in his head for decades:
"So don't take the kernel version at face value -- we spend a lot of time backporting newer kernel features into every major release! If you want the latest and greatest and don't care about kABI, ABI and long-term stability, Fedora is ready for you."
In reality _our_ reality, the Linux kernel is _and allways has been_ 100% stable towards userspace.
That's the MOST IMPORTANT thing in kernel development.
In reality _our_ reality, the idiotic backporting done by Red Hat means that these old - relatively untested - newly patched kernels are the least stable of _any_ decent distribution out there (ok, maybe except for Fedora?).

You talk about a 'kABI', well I guess you mean 'a stable kernel device driver API', well, Mr. Idiot, there happens to be file in the Documentation subdirectory of the Linux kernel tree, yes, the one started by your - and our - hero: Linus Torvalds. The title says it all: "stable_api_nonsense.txt". It's been part of the Linux kernel even from before the time you started this backporting idiocy. And maybe at that time it made sense, at that time (2.4 and early 2.6 kernels) there were actually more and less stable releases of the Linux kernel. But much has changed since then...
This policy doesn't add value to Red Hat any more, it makes it less valuable, problematic to run on new server hardware and impossible on laptops. This story, you keep on repeating, hurts your business and OpenSource in general. Just stop and reconsider... get your head out of the past and become a little bit smarter!

Re:Summary of systemd NFS answer; on "merit" adopt

[hey00]

Comparing it to Internet Explorer? Why don't you just start an open source project to give it some competition, like Firefox did to IE?

You are dishonest and you know it, but in the off chance you actually think you are honest, let me break it down for you:

SysV, Runit, OpenRC, Upstart, etc. There is competition, but the playing field is not even.

Since those have already been dropped by most distributions (and since the ease of supporting systemd was a primary factor for its adoption by most distributions), there is absolutely no way that a traditional init system will be supported by a distribution currently supporting systemd.

I could make the best init system ever, it doesn't matter if distributions don't support it.

The problem with systemd is not systemd itself, it's how most of us have no choice but to use it. Comparing to IE is actually wrong, because at least with IE, you can install Firefox without half of your OS breaking. Try that with systemd.

forget systemd - he ignored gnome

[Anonymous Coward]

Interesting that there were really two contentious questions - systemd and gnome.

With systemd he directly confronted the question and answered it (perhaps not the way people wanted, but he did answer it and give direct support to systemd and its future).

On the other hand, the gnome question was answered in standard politician mode where he talked about everything but gnome. Perhaps an indication that gnome isn't viewed quite as highly inside Red Hat and that maybe some changes may be possible.

Re: Summary of systemd NFS answer; on "merit" adop

[emil]

Systemd does a number of important things. It lets software installations drop service files and start them immediately. It lets services run as non-root users, where the inittab does not. It lets services run chroot()ed, where inittab does not. It provides a (bad) interface to inotify/crown/socket/nspawn/etc, where inittab does not. To argue for inittab is to argue for a straightjacket - that is systemd.

Fuck you very much Jim.

[Eunuchswear]

My first calls usually start at 8 am as I'm driving to the office.

Scum.

Re:Summary of systemd NFS answer; on "merit" adopt

[Eunuchswear]

but the playing field is not even.

The playing field is exactly as even as a Luxembourg/Germany world cup qualifying match.

Re:Summary of systemd NFS answer; on "merit" adopt

[hey00]

but the playing field is not even.

The playing field is exactly as even as a Luxembourg/Germany world cup qualifying match.

No. The playing field is as even as if Luxembourg decided to play a new game of football-curling, and the fifa, referees, broadcasters, etc. decided to support and cover only that new football-curling.

Germany is still good at playing football, but it doesn't matter if noone with power organizes football tournaments and broadcast football matches, but only show football-curling, where there is only one team.

The state of init is the same. Systemd decided to do things radically differently (which isn't an issue by itself), and distributions decided to only support that kind of init now. It doesn't matter if upstart, openRC or runit are good init systems, as long as they don't do it the systemd way, they won't get any support.

The playing field is not even.

Re:How long before the dramatic reveal of the Endg

[AdamWill]

We're aiming for next Tuesday, but we might not quite hit the deadline; we've had some technical issues with the volcano in the underground lair...