Originally posted by Honton
View Post
Announcement
Collapse
No announcement yet.
Red Hat Enterprise Linux 6.5 Preps New Capabilities
Collapse
X
-
Originally posted by Vim_User View PostReally? 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.
Comment
-
Originally posted by RahulSundaram View PostDebian 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
Anyways, saying that Debian already wants the switch is plain wrong and another one of Honton's tactics (read: lies) to promote his view.
Comment
-
Originally posted by RahulSundaram View PostDebian 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
Comment
-
Originally posted by phred14 View PostPardon 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.
Comment
-
Originally posted by phred14 View PostPardon 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.
Comment
-
Originally posted by Serge View PostI 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.
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.)
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.
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.
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.
"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.
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.
Comment
-
Originally posted by RahulSundaram View PostDebian 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
Most notably, it's compatible with Linux and the BSDs and it's under a more liberal BSD license.
Comment
-
Originally posted by intellivision View PostYou 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.
Comment
-
Originally posted by liam View PostMore 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 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 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).
*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?
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 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.
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.
Comment
Comment