Red Hat Enterprise Linux 6.5 Preps New Capabilities

[Vim_User]

You assert Debian wants to keep the old default. That is wrong.

Really? So how about giving us some links that prove your claim? I receive the Debian newsletters and not in one of them a change to systemd was announced, so maybe I am missing something or you are just making things up again.

[RahulSundaram]

Really? So how about giving us some links that prove your claim? I receive the Debian newsletters and not in one of them a change to systemd was announced, so maybe I am missing something or you are just making things up again.

Debian hasn't switched yet because they move relatively slowly and releases are not that often but it appears that they will considering that the majority according to this survey seems either in favor of systemd or don't care about which init system is being used http://people.debian.org/~stapelberg...y-results.html http://people.debian.org/~stapelberg...-portable.html

[Vim_User]

Debian hasn't switched yet because they move relatively slowly and releases are not that often but it appears that they will considering that the majority according to this survey seems either in favor of systemd or don't care about which init system is being used http://people.debian.org/~stapelberg...y-results.html http://people.debian.org/~stapelberg...-portable.html

Only 43.9% are in favor of systemd, 32.2% don't want systemd as default. 23.7% say that they don't know yet, that doesn't mean that they don't care, but they have to look into it. I doubt that in the end more than 50-55% will be in favor of systemd as default, but of course I have no numbers on that.
Anyways, saying that Debian already wants the switch is plain wrong and another one of Honton's tactics (read: lies) to promote his view.

[Serge]

Debian hasn't switched yet because they move relatively slowly and releases are not that often but it appears that they will considering that the majority according to this survey seems either in favor of systemd or don't care about which init system is being used http://people.debian.org/~stapelberg...y-results.html http://people.debian.org/~stapelberg...-portable.html

Ironically, it was the results of that same survey that caused me to form the opinion that Debian will not be switching to systemd any time soon. Debian very rarely resorts to "majority rules" decision making. Debian places great emphasis on consensus. I think 32% is entirely too high. That means that nearly a third of the survey respondents are explicitly against the direction that you think Debian is heading in.

[Serge]

Pardon me, I don't disagree with what you say, just in the way it seems to be getting commonly implemented. So please let me restate that every so slightly modified...

"We need a solution to configuration and management that doesn't include bash scripts or, in general, opening a cli, but does not forbid using bash scripts or the cli, either."

Back in the day, I've had to do both on order to get my systems running properly, even booting at all. I certainly appreciate all of the auto-configuring gizmos that make my system easier to run and boot, UNTIL they fail to work correctly. Then I just want to do whatever it takes to get running again, and I don't want those same gizmos, sitting in the way, obfuscating the old job I used to be able to readily figure out how to do, or even working against me, undoing my every tweak or fix. Please leave Linux hackable - it seems like there are those trying to turn Linux into Windows. It doesn't have to be that way - we should be able to have both.

I agree with you 100% on this. The general trend is consistently making it harder to use your favorite text editors or tools like sed and awk to administer your system, and I think that's a bad approach from a useability perspective. The new tools lower the learning curve for new sysadmins, which is a good thing, but this should not come at the cost of making the traditional utilities obsolete, as those utilities do allow a sysadmin to be more productive once he or she learns those utilities.

[MartinN]

Pardon me, I don't disagree with what you say, just in the way it seems to be getting commonly implemented. So please let me restate that every so slightly modified...

"We need a solution to configuration and management that doesn't include bash scripts or, in general, opening a cli, but does not forbid using bash scripts or the cli, either."

Back in the day, I've had to do both on order to get my systems running properly, even booting at all. I certainly appreciate all of the auto-configuring gizmos that make my system easier to run and boot, UNTIL they fail to work correctly. Then I just want to do whatever it takes to get running again, and I don't want those same gizmos, sitting in the way, obfuscating the old job I used to be able to readily figure out how to do, or even working against me, undoing my every tweak or fix. Please leave Linux hackable - it seems like there are those trying to turn Linux into Windows. It doesn't have to be that way - we should be able to have both.

Whomever said anything about turning Linux into a non-hackable OS? I love it the way it is, it just needs a top notch, non-X based UI. Everything else should remain as it is. I wasn't trying to revise history either - maybe I wasn't quite specific as serge was... My point about Linux needing a fast gui, detached from the X legacy, still stands. Hackability isn't mutually exclusive with a GUI.

[liam]

I do believe that marketing would do far more for increasing usage share of Linux-based and *BSD OS'es than any one other thing, but the point I was trying to get across is that we do need many things, not just any one thing, I disagree with you on specifics, however.

More than any one thing? Maybe. It really depends on what constitutes "one thing". If adobe ported all of their desktop apps to linux that would be HUGE. If OOTB linux could handle both low latency and throughput as well as osx that would be a huge feature (the fact that we have even lower latency than osx without massive throughput loss for the vast majority of workloads is already a big deal but I don't know of an entity offering that setup for the desktop that also has support). Honestly, I keep going back to latency b/c that tells you much about the reliability of your underlying system.
We also need a really good DE. I'm not aware of one that is both fast, stable and "full featured" (for Windows user's definition of that).

"We need standards."
(Sorry if I am strawmanning you on this one; I wasn't 100% sure what you meant by "we need standards", so I took a guess.)

Heh, I'm not sure either. What's clear to me, however, is that there is massive duplication of effort (yay, that old standard). Packaging format/tooling isn't a huge deal b/c, well, deb and rpm are structurally very similiar and, basically, work alike. A much bigger deal is not being able to rely on standard system-level apis. Systemd, as ericg says above, goes a long, long ways towards fixing this. Since we are talking about linux, I'm not considering the bsds (at any rate, i think they serve a different, and shrinking market, IMHO). LSB, in practice, seems to address mainly naming and placement conventions (very important, obviously) but the adopting the actual apis in the lsb would be a great thing (again, largely unneeded with systemd). As for debian/ubuntu, I think ubuntu spins are going to increasingly diverge. Mir is not helping, but systemd just offers too many advantages with standardization being a really nice bonus.

Do you mean we need to increase compatibility across multiple Linux-based OSes ("distributions") by way of standards? Well, we have LSB and that's been a failure. LSB mandates standards that are in conflict with what distribution developers feel is the best approach. LSB was dead on arrival. Experienced standards bodies have figured out - and developed policies and operating guidelines in accordance with - that one does not simply "mandate" standards, period. Something must first become a de facto standard before it can hope to have success as a de jure standard.

The big "problem" is that, by their nature, linux draws people who prize their independence over most anything else. The fact that most any distro can be spun to handle most any duty gives proof that those changes the other distros have felt had to made just weren't necessary. That's not to say ALL forks aren't worthwhile but anything beneath the ui frameworks needs to be quite standard (at least api standard if not abi).

LSB tried to force consensus where consensus had failed to develop naturally. The various distributions did things the way they did because they felt that their approach was the best. For example, Debian developers and developers of distros based on Debian felt that the .deb packaging format had advantages over the .rpm format. If they did not feel this way, they would have switched to .rpm on their own, without being prompted by LSB. And on the other hand, requiring support for BOTH sides of an incompatibility, as was done with Gtk+ and Qt, just leads to bloat.

The best consensus don't always happen naturally. Glastnost wasn't natural. It was the result of LOTS of high level diplomacy between two parties. The linux community consists of WAY more than two groups, which would argue for natural consensus, but, at a high level, the deb/rpm split seems to work well as a short hand. On one side you have debian, and the other you have fedora/suse. The big blocker with debian seems to be their insistence on keeping a bsd kernel as a drop-in when it should, arguably, be a tier 2 project. The entire community should'nt be held back b/c of something like that. How many people are using debian userspace with bsd? Some certainly, but I'd bet its less than 1%. Why hold back the entire project for those few?
About deb/rpm. While there are some differences this has really become a religious issue, AFAICT. Gtk/Qt should be the place where differences in the system apis can hide and if thats what everyone used there'd be little problem but proprietary apps, especially art and cad apps can/do use their own toolkits. For them, having a stable system api is a must. So, what they currently have to do is package to RHEL/SLES version X. That could go away. We wouldn't have to have people repackaging (assuming its even possible) for every damn distro. Packaging is simply the largest user of resources AFAICT.

I think that cross-distribution compatibility is very important, but I do not believe that this problem can be solved very easily. Standards by themselves will always fail to gain acceptance and adoption as long as the underlying causes of the incompatibilities are not addressed. Take, for example, FFmpeg vs Libav. Those are two projects with deeply ingrained animosity towards each other, and growing incompatibility between the two leads end users and downstream developers not directly involved with either project to take sides as well. Backing one with a standard and ignoring the other will result in the standard failing and will not have a strong impact on adoption of one over the other.

Although the FFmpeg-Libav conflict is caused by engineers, there are other artificial incompatibilities* that are created by managers (hint: http://translate.google.com/#en/ru/peace). Driving more open source projects towards corporate control will not fix this problem. Instead, we'll trade freedom and incompatibilities born of passion for vendor lock-in and incompatibilities born of marketing / sales needs ("market segmentation", "product differentiation").

*My appologies to any FFmpeg or Libav developers. I've read up on the projects and realize that the FFmpeg and Libav incompatibilities are not entirely artificial.

Sorry, I haven't been following that rift closely so I can't comment.

"Alsa needs to be fixed."
I'm not qualified to write about whether it's ALSA or something else in our audio stack that needs to be fixed, but I don't believe it's all that important for the typical desktop user. I'm not saying that typical users don't care about audio, I'm saying that for typical users our audio is "good enough". My direct experience is that audio in Linux-based OS'es still sucks for professional use, but I think that doesn't impact typical users that much.

Yes, alsa has issues. As its been explained to me, pulseaudio can do low latency work if alsa were made to use plls for timing. That is basically Core Audio. Having that as part of the standard desktop is a really big deal even though the number of musicians/engineers are pretty small absolutely.
I'm sure ninez could explain this more thoroughly.


I think we largely agree, it's just that I don't think marketing is the biggest issue right now. Once we get wayland (or something like it) working well, the open drivers in better shape (basically working as well as r600 is now, but for nvidia/intel as well), systemd more or less completed (reliable hibernation and low power usage are hugely important), AND one really good DE THEN I think a marketing campaign would be hugely beneficial. Right now I just don't think we are good enough in the areas that people will really notice.

[intellivision]

Debian hasn't switched yet because they move relatively slowly and releases are not that often but it appears that they will considering that the majority according to this survey seems either in favor of systemd or don't care about which init system is being used http://people.debian.org/~stapelberg...y-results.html http://people.debian.org/~stapelberg...-portable.html

You forgot to mention the discussion of moving Debian to OpenRC that occurred, there were quite a few interesting posts there.
Most notably, it's compatible with Linux and the BSDs and it's under a more liberal BSD license.

[RahulSundaram]

You forgot to mention the discussion of moving Debian to OpenRC that occurred, there were quite a few interesting posts there. Most notably, it's compatible with Linux and the BSDs and it's under a more liberal BSD license.

Systemd has far more support than any other init system in that survey. The main contenders are upstart and systemd and neither are compatible with anything other than Linux and similar in terms of licensing with upstart fairing worse due to CLA. openrc just doesn't have enough support outside of Gentoo.

[Serge]

More than any one thing? Maybe. It really depends on what constitutes "one thing". If adobe ported all of their desktop apps to linux that would be HUGE. If OOTB linux could handle both low latency and throughput as well as osx that would be a huge feature (the fact that we have even lower latency than osx without massive throughput loss for the vast majority of workloads is already a big deal but I don't know of an entity offering that setup for the desktop that also has support). Honestly, I keep going back to latency b/c that tells you much about the reliability of your underlying system.
We also need a really good DE. I'm not aware of one that is both fast, stable and "full featured" (for Windows user's definition of that).

I tend to think of OS X as the golden standard for a good graphical experience. I think the Metro style has great potential and will replace the desktop metaphor in graphical shell design once it has matured a little, but at the moment, I think it is so incomplete that it is actually a regression from Aero and whatever they used to call it before that. I have never been a fan of the destkop metaphor and am always curious to see projects try to break the mold of what a traditional, desktop-themed graphical shell should look like. I think the desktop metaphor was a clever attempt to make the then-nascent graphical shells more naturally intuitive to office workers, and to some extent it did have success there, but overall I think people's comfort with such "traditional" approaches is due more to familiarity with the desktop metaphor than to a natural inclination towards interacting with their computer in this way.

I think that somewhere out there is a much better way to graphically represent and facilitate interaction with the functionality of a computer to human beings than what has been done with the desktop metaphor. I don't know what that way is. I really liked where Maemo was going with their graphical experience. (note: I am referring to Maemo before Maemo 5; I have never tried Maemo 5 and have no idea what it looks like, so I can't comment on whether or not I think it's an improvement on pre-5 or if it is worse) In fact, when I first saw Maemo, my immediate reaction was, "Finally! This is the one! This is the way graphical interfaces should have always been!" But that's a dead end now. OLPC's Sugar sounds great in concept but in practice I'm always disappointed when I check it out. So that's why I am curious to see where Microsoft takes the "Metro style". It's horrible right now, though. So for the time being the only graphical environments that I find truly impressive are those that still build on the old desktop metaphor, and of those the best I think belongs to OS X. As for Linux-based GUIs vs Windows pre-Metro GUIs, I think that the later, more mature offerings in the GNOME 3 and KDE 4 series are now roughly up to par with the one found in Windows 7, which I feel remains the best Windows GUI to date.

TL;DR: Ok, sorry, let me get back on topic. What I mean to say is, I think that GNOME and KDE are already comparable to the Windows graphical experience, but the real king of graphical experiences for the time being is OS X, not Windows.

Heh, I'm not sure either. What's clear to me, however, is that there is massive duplication of effort (yay, that old standard). Packaging format/tooling isn't a huge deal b/c, well, deb and rpm are structurally very similiar and, basically, work alike. A much bigger deal is not being able to rely on standard system-level apis. Systemd, as ericg says above, goes a long, long ways towards fixing this. Since we are talking about linux, I'm not considering the bsds (at any rate, i think they serve a different, and shrinking market, IMHO). LSB, in practice, seems to address mainly naming and placement conventions (very important, obviously) but the adopting the actual apis in the lsb would be a great thing (again, largely unneeded with systemd). As for debian/ubuntu, I think ubuntu spins are going to increasingly diverge. Mir is not helping, but systemd just offers too many advantages with standardization being a really nice bonus.

The best technology doesn't always win. I'd like to see wider systemd adoption, but for the time being there are compelling reasons for Debian to not make the switch, and for the time being Ubuntu continues to stand behind Upstart, and as I've already mentioned in an earlier post, over 60% of the distributions listed on distrowatch.com are either Debian or Ubuntu based. In the future, all of this can of course change. The Debian project might decide that Debian misses out on too much functionality when not using systemd and this can lead to an upsurge in interest in switching to systemd, or Canonical might decide that continued Upstart development does not provide a sufficient return on their investment and that continued development of systemd compatibility layers is just not worth the effort when a switch to systemd would eliminate the need for these layers. But those are just two speculative scenarios. Right now, it does not appear that either project is going to be switching to systemd.

The big "problem" is that, by their nature, linux draws people who prize their independence over most anything else. The fact that most any distro can be spun to handle most any duty gives proof that those changes the other distros have felt had to made just weren't necessary. That's not to say ALL forks aren't worthwhile but anything beneath the ui frameworks needs to be quite standard (at least api standard if not abi).

Not too long ago I got it into my head that I wanted a CLI-only OS in a 512MB volume to handle boot management and do system recovery without a live USB. I started with Debian, as that's what I was most familiar with, but the standard installation image failed to create an install that fit. Next, I tried Arch Linux and ended up having to delete the localization files, the man pages, and mount the package cache in tmpfs in order to get a useable system without sacrificing useful tools like procps. Then I tried Slackware and got a fully useable system with all of the nice desired tools, with no hacking, in about half the space. That, to me, is a sign of fundamental philosophical differences that have real, practical consequences*. There are many projects that I feel do not bring anything significantly new or different to the table, but I feel that the major meta-distros all have something unique and worthwhile about them. As for specialty projects like ClearOS and BackTrack / Kali: sure, any meta-distro can do what they do, but sometimes it's nice to just get something that can perform such a specialized purpose with minimal hacking.

*The philosophical differences that I learned about from that experiment is that Arch Linux's philosophical focus on the bleeding edge has caused the project to make sacrifices with other core philosophies like simplicity and minimalism, whereas Slackware, which values practicality over rapid technology adoption, has not had to sacrifice its own simplicity and minimalism philosophies.

The best consensus don't always happen naturally. Glastnost wasn't natural. It was the result of LOTS of high level diplomacy between two parties. The linux community consists of WAY more than two groups, which would argue for natural consensus, but, at a high level, the deb/rpm split seems to work well as a short hand. On one side you have debian, and the other you have fedora/suse. The big blocker with debian seems to be their insistence on keeping a bsd kernel as a drop-in when it should, arguably, be a tier 2 project. The entire community should'nt be held back b/c of something like that. How many people are using debian userspace with bsd? Some certainly, but I'd bet its less than 1%. Why hold back the entire project for those few?

Yes, you are right about consensus reached through deliberation. The XDG/Portland/freedesktop.org standards, for example, required both GNOME and KDE developers to make compromises in the name of interoperability. But deliberations like that are kinda an exception. Normally, it is really hard to "force" consensus. You need various stakeholders to compromise, and the standard will fail if too many of them do not make the necessary compromises. I think it is more likely for Debian to switch to systemd, for example, out of necessity than as a voluntary compromise in the name of interoperability.

About deb/rpm. While there are some differences this has really become a religious issue, AFAICT. Gtk/Qt should be the place where differences in the system apis can hide and if thats what everyone used there'd be little problem but proprietary apps, especially art and cad apps can/do use their own toolkits. For them, having a stable system api is a must. So, what they currently have to do is package to RHEL/SLES version X. That could go away. We wouldn't have to have people repackaging (assuming its even possible) for every damn distro. Packaging is simply the largest user of resources AFAICT.

Well, packaging is traditionally the responsibility of each distro and its packagers, not of upstream projects. The reason things have turned out that way is because for the longest time, the proprietary software vendors shunned free operating systems, so as a result the GNU project, the *BSD projects, and the Linux ecosystem developed a very rich library of free and open software that provided reasonable alternatives to the proprietary software. So packaging for a specific distro was a task best handled by the distro in question. But then proprietary software vendors start expressing an interest, and the established way of having the distros handle their own packaging is no longer an option because the source code is not available, and in that model it's the upstream vendors themselves who end up having to package for the various distros. See, it's a manageable problem as long as the distros have access to the source code. Then the distros can just say, "Well, 'foo' works on Ubuntu, but it takes us extra effort to package 'foo' for our distro because we're not completely compatible with Ubuntu so we have to solve some problems in order to get 'foo' to run on our system. Is it really worth the extra effort, or should we instead focus on removing the differences between our distro and Ubuntu so that it's easier to get programs like 'foo' running on our distro with less effort?" And they can then decide if their differences are really that important or not, because they're the ones who are having to pay the price of incompatibility. But when it's upstream that has to do the packaging, then it's not the distros' problem anymore, so the distros are not as motivated to remove the differences anymore, either. But I'm a supporter of free and open source software, and I try to avoid using proprietary software as much as possible, so to me the only interest in making it easier for proprietary software vendors to make software for Linux-based OS'es is in that it might bring greater attention to the ecosystem at large and hence lead to the improvement of the free and open software as well. So I'm in favor of seeing more proprietary software running on free OS'es, but it's not as important for me given my priorities, and I don't like the idea of compromises to free OS'es that mainly benefit proprietary vendors.

I think we largely agree, it's just that I don't think marketing is the biggest issue right now. Once we get wayland (or something like it) working well, the open drivers in better shape (basically working as well as r600 is now, but for nvidia/intel as well), systemd more or less completed (reliable hibernation and low power usage are hugely important), AND one really good DE THEN I think a marketing campaign would be hugely beneficial. Right now I just don't think we are good enough in the areas that people will really notice.

The main reason I am still kinda hung up on marketing is because I think Linux-based and *BSD OS'es already have so much to offer to the world's computer users. I think that there is already so much here, there is definitely enough material for marketing experts to sink their teeth into if there was financial incentive for them to do so.

I do think that Valve's attention to a Linux base, and the upcomming Steam OS, are doing a heck of a lot of the marketing that I'm hoping for. Google Chromebooks benefit from marketing. Presumably Intel's Tizen laptops will be backed with marketing efforts from Intel as well. All of this kind of marketing raises user awareness for Linux-based OS'es in general, and projects like Debian who rely on no budget and a tiny team of volunteers for their marketing will end up benefiting from this as well.

So part of the reason why I keep coming back to marketing is because I think it's important, part of the reason is because I think we already have so much that is worth marketing, and finally part of the reason is because I see that marketing coming our way already. (And that's good news!) But it's as you say, otherwise we largely agree. There's plenty of room for improvement across the board, and I don't think that efforts in one area, like marketing, are mutually exclusive with efforts in another area, like continued efforts at standardization.