heee
Discussion on:
View:
Show:
I am a long-time Ubuntu user, since back in the 7.x era. I have been using a mixture of 10.04 and 11.04. But that tech is getting old. I just upgraded to Ubuntu 11.10 this week on three of four computers of various ages and specs. I would have switched from Ubuntu after Unity if I had not found Mate Desktop from Mint. It has the old Gnome 2.x features that I like that went missing with Gnome 3 and Unity. I tried Cinnimon but it was also lacking the features I like. Thanks to the Mate Desktop, I can continue using the Linux Distro I feel comfy with.
Paul
Paul
I am fed up with all of those microsoft's nonsenses they force us for money. But, to change I would need some pictures here....
http://distrowatch.com/dwres.php?resource=major
http://www.whylinuxisbetter.net/
Of course these are stock installs, you can change them to look like anything. One guy changed the desktop and icons to look exactly like XP. Why, I dunno.
http://www.whylinuxisbetter.net/
Of course these are stock installs, you can change them to look like anything. One guy changed the desktop and icons to look exactly like XP. Why, I dunno.
While choice of course it good, too much choice is often proving to have a negative effect.
Linux is rocking as a server platform. Those who use it on the desktop are either developers or work in companies that have adopted it. In the latter case, most of the users have no idea what flavor of Linux they use, or that they use Linux at all. They most likely use applications such as Open/LibreOffice or/and web based applications such as Google Apps.
It is also there Linux has its growth potential as a desktop, not as a general purpose desktop OS. The move to using web based applications makes the underlying OS less and less important. Organizations will be able to save a ton of money selecting a rock solid Linux Desktop that gives them enough features to run the apps their staff needs. Not only on the software license costs, but also be able run on less powerful hardware, saving not only investment costs but surely also on electricity.
Until Linux cracks the application installation, updating general management, and of course the lack of games and other native applications, it wont be an option for home users. They just want things that works and what everyone else uses. If you would show them all the various desktop options listed here they would have a hard time understanding they are based on the same OS.
Linux is rocking as a server platform. Those who use it on the desktop are either developers or work in companies that have adopted it. In the latter case, most of the users have no idea what flavor of Linux they use, or that they use Linux at all. They most likely use applications such as Open/LibreOffice or/and web based applications such as Google Apps.
It is also there Linux has its growth potential as a desktop, not as a general purpose desktop OS. The move to using web based applications makes the underlying OS less and less important. Organizations will be able to save a ton of money selecting a rock solid Linux Desktop that gives them enough features to run the apps their staff needs. Not only on the software license costs, but also be able run on less powerful hardware, saving not only investment costs but surely also on electricity.
Until Linux cracks the application installation, updating general management, and of course the lack of games and other native applications, it wont be an option for home users. They just want things that works and what everyone else uses. If you would show them all the various desktop options listed here they would have a hard time understanding they are based on the same OS.
I have frequently advocated for a little more monolithic approach to Linux, eg do we really need 21 different file management apps? 5 barely compatible sound architectures??
I always get slammed for it, and the arguments for the status quo are compelling. It just seems if the top 20 distributions put their heads together to produce one distribution the result would be able to give windows and Mac a run for the desktop money.
I always get slammed for it, and the arguments for the status quo are compelling. It just seems if the top 20 distributions put their heads together to produce one distribution the result would be able to give windows and Mac a run for the desktop money.
We need choices, especially when most of them suck.
I'm pretty sure that if anyone was able to ensure that fifty percent of the options for file managers went away, making things more "monolithic", the options that suck least would be among the first to go.
I'd love to see five separate, interchangeable sound architectures. The problem is not that there are too many; it is that, in order to do everything most people want to do, one has to have all five of them at the same time. It's a damned disaster area, and that's because of the general development philosophy that has become ascendant in the Linux community, not because of "too much choice".
I think that if "the top 20 distributions put their heads together to produce one distribution" the result would be the worst distribution I had ever seen, because there would be effectively unlimited development resources set free to develop huge piles of some of the worst, most contradictory, least functional new pieces of garbage the Linux world has ever seen, and they would all insist on throwing away things that work in favor of something brand new, built from scratch, for no other reason than pathological neophilia.
. . . and none of it would be stable, easy to use or configure, or at all portable.
I'm pretty sure that if anyone was able to ensure that fifty percent of the options for file managers went away, making things more "monolithic", the options that suck least would be among the first to go.
I'd love to see five separate, interchangeable sound architectures. The problem is not that there are too many; it is that, in order to do everything most people want to do, one has to have all five of them at the same time. It's a damned disaster area, and that's because of the general development philosophy that has become ascendant in the Linux community, not because of "too much choice".
I think that if "the top 20 distributions put their heads together to produce one distribution" the result would be the worst distribution I had ever seen, because there would be effectively unlimited development resources set free to develop huge piles of some of the worst, most contradictory, least functional new pieces of garbage the Linux world has ever seen, and they would all insist on throwing away things that work in favor of something brand new, built from scratch, for no other reason than pathological neophilia.
. . . and none of it would be stable, easy to use or configure, or at all portable.
The Steve Jobs of Linux.. someone to say, "yeah that's nice, but can you make it load faster?" I think that is the one thing that is truly wrong with the Linux design philosophy. Being so open means that anyone gets a say. And when that happens, everyone puts in their two cents, to make their mark or because they personally like it better, which would be fine if you're the sole user. But the result on a released product is that cohesiveness suffers, and cohesiveness is what impresses end-users.
There already is a Steve Jobs of Linux. His name is Linus Torvalds, and he runs the Linux kernel project. You seem to want a Steve Jobs of Everything That Uses Linux, which would mean he'd control development of some Linksys routers, all Android smartphones, all Linux distributions, and so on. That's pretty unreasonable, really.
The problem isn't that everyone gets a say. It's that the community credulously accepts the say of some very crazy people, and this is a cultural problem rather than a hierarchical problem. The FreeBSD community doesn't have the same kind of cultural issue you see in the Linux community, for instance.
The problem isn't that everyone gets a say. It's that the community credulously accepts the say of some very crazy people, and this is a cultural problem rather than a hierarchical problem. The FreeBSD community doesn't have the same kind of cultural issue you see in the Linux community, for instance.
the personality type drawn to OSS development creates a culture that is counterproductive to OSS development.
Crazies and egos.
OK, so my "20 top" daydream excludes the actual culture that would participate. Let's say the IBM complex in Binghamton takes on this task...
Crazies and egos.
OK, so my "20 top" daydream excludes the actual culture that would participate. Let's say the IBM complex in Binghamton takes on this task...
QUOTE: the personality type drawn to OSS development creates a culture that is counterproductive to OSS development.
That's not my point at all. There are many different personality types drawn to open source software development, and many different cultures that could arise. The problem is that 98% of people drawn to open source development are arrogant jackasses, lunatics, and assorted other bad influences -- exactly the same as in closed source development. If the right people get themselves into the right places within the early formation of a community, or somehow manage to take over those places and exert influence to change the direction of "the ship of state", you can end up with a good culture that develops good software, as in the case of various BSD Unix communities and other open source development communities. Luckily, the lunatics, arrogant jackasses, and assorted other bad influences are mostly incapable of founding a major open source software community, so there's hope for good communities and good cultures to develop, as happened with (for instance) the FreeBSD community.
Consider, for instance, the pwmt, suckless, conformal, and 9front communities, all of which work on excellent software. Each community has its dysfunctions, of course, as do all the closed source software vendors' employee "communities", but in those cases the dysfunctions do not result in something like PulseAudio as another snarl in the hairball, the GNOME and XFCE projects (potentially) abandoning portability, or Firefox screwing its own release schedule's usefulness until it's a slobbering, weeping wreck in the middle of the street. Those latter cases are the result of communities that let themselves get taken over, and had their culture redefined, by the arrogant jackasses, lunatics, and assorted other bad influences -- in many cases by becoming popular and not insulating the core development team from takeover by those bad influences. PulseAudio in particular is one of several problem areas where a single individual has achieved great popularity in a highly dysfunctional Linux community as a whole -- not the kernel community, but the community that extends far past the kernel and involves Linux distibutions, users, application developers, and so on.
That's not my point at all. There are many different personality types drawn to open source software development, and many different cultures that could arise. The problem is that 98% of people drawn to open source development are arrogant jackasses, lunatics, and assorted other bad influences -- exactly the same as in closed source development. If the right people get themselves into the right places within the early formation of a community, or somehow manage to take over those places and exert influence to change the direction of "the ship of state", you can end up with a good culture that develops good software, as in the case of various BSD Unix communities and other open source development communities. Luckily, the lunatics, arrogant jackasses, and assorted other bad influences are mostly incapable of founding a major open source software community, so there's hope for good communities and good cultures to develop, as happened with (for instance) the FreeBSD community.
Consider, for instance, the pwmt, suckless, conformal, and 9front communities, all of which work on excellent software. Each community has its dysfunctions, of course, as do all the closed source software vendors' employee "communities", but in those cases the dysfunctions do not result in something like PulseAudio as another snarl in the hairball, the GNOME and XFCE projects (potentially) abandoning portability, or Firefox screwing its own release schedule's usefulness until it's a slobbering, weeping wreck in the middle of the street. Those latter cases are the result of communities that let themselves get taken over, and had their culture redefined, by the arrogant jackasses, lunatics, and assorted other bad influences -- in many cases by becoming popular and not insulating the core development team from takeover by those bad influences. PulseAudio in particular is one of several problem areas where a single individual has achieved great popularity in a highly dysfunctional Linux community as a whole -- not the kernel community, but the community that extends far past the kernel and involves Linux distibutions, users, application developers, and so on.
The Linux kernel, while not necessarily perfect, is a rather successful project. Maybe that's because of Linus, perhaps in spite of him. I don't know. To be honest, I've never been involved in an OSS project from that side of the fence, so maybe I'm not qualified to make suggestions.
It seems to me as though every ship needs a captain, and a QA department, to set the course, define a consistent interface, and ensure that development is done on the parts that need it. (How many projects grow in features, while never actually completing core functionality, for instance.)
To say an oversight committee is needed on "everything that uses Linux" is beyond my wishes. I guess I would like to see a core platform.. a kernel, a shell, a set of tools, an audio framework, something akin to X but with a fresh design, and maybe a single general-purpose window manager, that can all be considered de-facto. The "reference" platform if you will. We're pretty close to that, but it's still a bit ala-carte to be a supportable platform.
At that point, we can have all the alternates the community could ever want, for whatever specific (or not) tasks they excel at. For those that want the choice, they've got it, but an application should support the reference platform at minimum.
Realistic? I dunno. But I think it would go a long way toward bringing Linux-on-the-Desktop to fruition.
It seems to me as though every ship needs a captain, and a QA department, to set the course, define a consistent interface, and ensure that development is done on the parts that need it. (How many projects grow in features, while never actually completing core functionality, for instance.)
To say an oversight committee is needed on "everything that uses Linux" is beyond my wishes. I guess I would like to see a core platform.. a kernel, a shell, a set of tools, an audio framework, something akin to X but with a fresh design, and maybe a single general-purpose window manager, that can all be considered de-facto. The "reference" platform if you will. We're pretty close to that, but it's still a bit ala-carte to be a supportable platform.
At that point, we can have all the alternates the community could ever want, for whatever specific (or not) tasks they excel at. For those that want the choice, they've got it, but an application should support the reference platform at minimum.
Realistic? I dunno. But I think it would go a long way toward bringing Linux-on-the-Desktop to fruition.
QUOTE: The Linux kernel, while not necessarily perfect, is a rather successful project.
I think that's a fair statement, depending on your definition of "successful". By many reasonable definitions, it's successful.
QUOTE: Maybe that's because of Linus, perhaps in spite of him. I don't know.
I think Linus mostly makes good decisions about project direction, and even in cases where some people (like me) might disagree he at least takes a consistent approach with articulable reasons for the choices he makes, so I think that a whole lot of the reason for the project's success is Linus' captaining of the project.
(Some people disagree with his banning of C++ from the kernel; I do not disagree with him. Some people agree with his choice of license; I disagree with him. The consistency of his decision making is in many ways at least as important as the quality of his decision making, though.)
QUOTE: It seems to me as though every ship needs a captain, and a QA department, to set the course, define a consistent interface, and ensure that development is done on the parts that need it.
You just described how Linus' management of the project looks to me. "Consistent interface" may be a bit strong, but he seems to have a consistent policy for the interface at least.
QUOTE: I guess I would like to see a core platform.. a kernel, a shell, a set of tools, an audio framework, something akin to X but with a fresh design, and maybe a single general-purpose window manager, that can all be considered de-facto.
Apart from "a single general-purpose window manager," where I assume you mean something that most people would be willing to use day in and day out, you've just described the difference between Linux-based systems and any of the major BSD Unix projects. The major BSD Unix projects each basically do exactly what you describe (there's actually more "standardized" for each of them), while for the most part there's no such thing as a Linux-based OS project with both real longevity and real stability of the core system. Debian used to be pretty stable in the configuration of the core of the system, but things have changed pretty radically in that respect over the last half dozen years or so; I hear rumors even Slackware has undergone a little upheaval in that respect during that time period.
QUOTE: We're pretty close to [a "reference" platform], but it's still a bit ala-carte to be a supportable platform.
Are we? I don't see any kind of closeness to such a thing.
QUOTE: Realistic? I dunno. But I think it would go a long way toward bringing Linux-on-the-Desktop to fruition.
Just work on BSD Unix on the Desktop instead. I think that if a little more effort were put into supporting something like iXsystems' PC-BSD project, it would get there a lot faster than any Linux distribution -- because any Linux distribution is the Linux kernel plus the distribution's monkeying about, which means that the people trying to build a "desktop system" are probably going to end up screwing around with a lot of stuff that gets very close to the kernel without any particular rein on the wilder ideas. Meanwhile, something like PC-BSD is built on top of the FreeBSD base system, which is well and carefully maintained at least as well as the Linux kernel itself, and to ensure continuing stability and ease of maintenance for the PC-BSD project the people working on that project are unlikely to make big changes to the base system that the FreeBSD maintainers would reject. It seems like a much better basis for development of a desktop system that does not lose sight of the benefits of what underlies all the frippery -- does not, in other words, sabotage the very thing that made it worth using as the basis for development of a desktop system in the first place.
Ubuntu started out using Debian the same way PC-BSD uses FreeBSD as its core, but from day one Canonical started monkeying around with the core OS to differentiate it from Debian. I think part of the reason compatibility was not maintained is the fact that the developers regarded Debian as no more fundamental than Ubuntu as an OS project, because both are just collections of software on top of a kernel. The sharing of code between the two ended up being more two-way, rather than one contributing code back while using the whole pieces of software of the other without making local changes to the code too much (the former being the Debian/Ubuntu relationship and the latter the FreeBSD/PC-BSD relationship). As a result, Debian and Ubuntu ended up in a sort of codependent relationship, rather than one OS project and another usability layer project built on top of the OS project. In the end, there was no stable basis for a desktop project, but rather just another OS project that did things in its own way -- and it was a very haphazard way that, because of its near-compatibility with the originating project, infected that originating project.
I think something similar to what exists with FreeBSD and PC-BSD is eminently possible, technically, on top of the Linux kernel. I think a combination of licensing and culture make it highly improbable, however -- and by "highly improbable" I mean "I have a better chance of winning the lottery than ever seeing that day come."
I suppose your mileage may vary.
I think that's a fair statement, depending on your definition of "successful". By many reasonable definitions, it's successful.
QUOTE: Maybe that's because of Linus, perhaps in spite of him. I don't know.
I think Linus mostly makes good decisions about project direction, and even in cases where some people (like me) might disagree he at least takes a consistent approach with articulable reasons for the choices he makes, so I think that a whole lot of the reason for the project's success is Linus' captaining of the project.
(Some people disagree with his banning of C++ from the kernel; I do not disagree with him. Some people agree with his choice of license; I disagree with him. The consistency of his decision making is in many ways at least as important as the quality of his decision making, though.)
QUOTE: It seems to me as though every ship needs a captain, and a QA department, to set the course, define a consistent interface, and ensure that development is done on the parts that need it.
You just described how Linus' management of the project looks to me. "Consistent interface" may be a bit strong, but he seems to have a consistent policy for the interface at least.
QUOTE: I guess I would like to see a core platform.. a kernel, a shell, a set of tools, an audio framework, something akin to X but with a fresh design, and maybe a single general-purpose window manager, that can all be considered de-facto.
Apart from "a single general-purpose window manager," where I assume you mean something that most people would be willing to use day in and day out, you've just described the difference between Linux-based systems and any of the major BSD Unix projects. The major BSD Unix projects each basically do exactly what you describe (there's actually more "standardized" for each of them), while for the most part there's no such thing as a Linux-based OS project with both real longevity and real stability of the core system. Debian used to be pretty stable in the configuration of the core of the system, but things have changed pretty radically in that respect over the last half dozen years or so; I hear rumors even Slackware has undergone a little upheaval in that respect during that time period.
QUOTE: We're pretty close to [a "reference" platform], but it's still a bit ala-carte to be a supportable platform.
Are we? I don't see any kind of closeness to such a thing.
QUOTE: Realistic? I dunno. But I think it would go a long way toward bringing Linux-on-the-Desktop to fruition.
Just work on BSD Unix on the Desktop instead. I think that if a little more effort were put into supporting something like iXsystems' PC-BSD project, it would get there a lot faster than any Linux distribution -- because any Linux distribution is the Linux kernel plus the distribution's monkeying about, which means that the people trying to build a "desktop system" are probably going to end up screwing around with a lot of stuff that gets very close to the kernel without any particular rein on the wilder ideas. Meanwhile, something like PC-BSD is built on top of the FreeBSD base system, which is well and carefully maintained at least as well as the Linux kernel itself, and to ensure continuing stability and ease of maintenance for the PC-BSD project the people working on that project are unlikely to make big changes to the base system that the FreeBSD maintainers would reject. It seems like a much better basis for development of a desktop system that does not lose sight of the benefits of what underlies all the frippery -- does not, in other words, sabotage the very thing that made it worth using as the basis for development of a desktop system in the first place.
Ubuntu started out using Debian the same way PC-BSD uses FreeBSD as its core, but from day one Canonical started monkeying around with the core OS to differentiate it from Debian. I think part of the reason compatibility was not maintained is the fact that the developers regarded Debian as no more fundamental than Ubuntu as an OS project, because both are just collections of software on top of a kernel. The sharing of code between the two ended up being more two-way, rather than one contributing code back while using the whole pieces of software of the other without making local changes to the code too much (the former being the Debian/Ubuntu relationship and the latter the FreeBSD/PC-BSD relationship). As a result, Debian and Ubuntu ended up in a sort of codependent relationship, rather than one OS project and another usability layer project built on top of the OS project. In the end, there was no stable basis for a desktop project, but rather just another OS project that did things in its own way -- and it was a very haphazard way that, because of its near-compatibility with the originating project, infected that originating project.
I think something similar to what exists with FreeBSD and PC-BSD is eminently possible, technically, on top of the Linux kernel. I think a combination of licensing and culture make it highly improbable, however -- and by "highly improbable" I mean "I have a better chance of winning the lottery than ever seeing that day come."
I suppose your mileage may vary.
I guess I need to get out more. I've never used Debian, nor Ubuntu, but I've seen the installer, and I was impressed that WiFi was working from the Live CD. I've heard it's somewhat tumultuous, and I've laughed at some of the strange decisions. (Wait, everyone gets sudo access? uhhhh...)
Also never used BSD of any variant. I think maybe I should. I'm intrigued by how you're saying they've nailed down the core to give it a fighting chance of being a stable, complete package.
BTW, when I say "we're close", I mean just about any given Linux distribution comes with the Linux kernel (with some patches), one of a few RC managers that mostly work the same way, bash, the GNU coreutils and fileutils type stuff, and Xorg. Though it looks like X is (finally?) being slowly squeezed out of its seat. The window manager (and for that matter, package management) are really the wildcards. The directory tree could be a little more consistent. (sysconfig... var... srv...)
So, I consider that close. Not close enough -- and it'll never be an enterprise contender (on the desktop) until there's a policy management framework and other integration bits and pieces.
Also never used BSD of any variant. I think maybe I should. I'm intrigued by how you're saying they've nailed down the core to give it a fighting chance of being a stable, complete package.
BTW, when I say "we're close", I mean just about any given Linux distribution comes with the Linux kernel (with some patches), one of a few RC managers that mostly work the same way, bash, the GNU coreutils and fileutils type stuff, and Xorg. Though it looks like X is (finally?) being slowly squeezed out of its seat. The window manager (and for that matter, package management) are really the wildcards. The directory tree could be a little more consistent. (sysconfig... var... srv...)
So, I consider that close. Not close enough -- and it'll never be an enterprise contender (on the desktop) until there's a policy management framework and other integration bits and pieces.
I can't reply below your comment, it's too "deep" in the thread for a mere visitor like me...
I agree with your comparison of BSD with Linux. The problem BSD faces is it's primarily going to attract users from the Linux world, rather than attract windows users.
Unless and until someone invests in advertising, neither Linux or BSD are going to be the go-to desktop system.
I hear you loud and clear on Linux's wild inconsistencies resulting from the choices a distribution makes as to what things should do and what they should look like.
My distribution of choice, Mandriva, just tore the heart of their most stable release ever (sysvinit) and replaced it with the mostly incompatible systemd. The reason stated was this is the direction fedora is going, and systemd is supposedly more capable, more granular in it's approach to starting/running the system.
Now get this... that's a huge change, but rather than actually make sure the dang thing worked, they spent tons of time writing up scripts so that the old style sysvinit commands would work (somewhat) with systemd.
I'd prefer they just tell me to get over it and learn the new commands. Instead, there's this false hope that issuing a sysv type command will result in the desired behavior. Of course they didn't get this entirely right.
I doubt this is the last huge change in the works. Ironically, the fact that better methods are always coming along, that development is healthy and active, has and will continue to keep Linux from being a stable, standardized desktop environment. As you point out even Debian and Slack are being bitten by the 'latest-greatest' bug.
In contrast, BSD is far more "stable" so far as the core not undergoing drastic changes.
I agree with your comparison of BSD with Linux. The problem BSD faces is it's primarily going to attract users from the Linux world, rather than attract windows users.
Unless and until someone invests in advertising, neither Linux or BSD are going to be the go-to desktop system.
I hear you loud and clear on Linux's wild inconsistencies resulting from the choices a distribution makes as to what things should do and what they should look like.
My distribution of choice, Mandriva, just tore the heart of their most stable release ever (sysvinit) and replaced it with the mostly incompatible systemd. The reason stated was this is the direction fedora is going, and systemd is supposedly more capable, more granular in it's approach to starting/running the system.
Now get this... that's a huge change, but rather than actually make sure the dang thing worked, they spent tons of time writing up scripts so that the old style sysvinit commands would work (somewhat) with systemd.
I'd prefer they just tell me to get over it and learn the new commands. Instead, there's this false hope that issuing a sysv type command will result in the desired behavior. Of course they didn't get this entirely right.
I doubt this is the last huge change in the works. Ironically, the fact that better methods are always coming along, that development is healthy and active, has and will continue to keep Linux from being a stable, standardized desktop environment. As you point out even Debian and Slack are being bitten by the 'latest-greatest' bug.
In contrast, BSD is far more "stable" so far as the core not undergoing drastic changes.
You replied correctly, TR doesn't let anyone go deeper than this.
nwallette:
QUOTE: I've seen the installer, and I was impressed that WiFi was working from the Live CD.
The various LiveCDs have mostly got stuff like that right, which is nice. For some reason, installing from a LiveCD fails on some things the LiveCDs themselves got right probably about five percent of the time, in my experience -- maybe a little less often than that.
QUOTE: Also never used BSD of any variant. I think maybe I should. I'm intrigued by how you're saying they've nailed down the core to give it a fighting chance of being a stable, complete package.
The core teams for the various major BSD Unix systems are generally very invested in ensuring they build very stable, secure systems, and have a tendency to put in the extra time to get things right the first time. This is in contrast to the way a lot of Linux distributions do things, where they come up with an idea and try to rush it out in a new release as quickly as they reasonably can, even if that means things are broken in numerous subtle ways or one or two big, surprising ways, and even if this means they inconvenience a lot of users with new design ideas.
That's not to say that BSD Unix developers don't occasionally make a hasty decision a little like the way I just describe the Linux community doing things, or that some Linux distributions don't make very deliberate, careful decisions from time to time. For instance, with FreeBSD 9.0, a new installer that changes the way things are done was used; some places that relied on specific capabilities of the older installer (sysinstall) for installation scripting were inconvenienced by the way the new installer (bsdinstall) was just swapped in place of the old, as opposed to what they had been led to believe would happen (an install-time or download-time choice of which installer would be used). It's my understanding that a knowledgeable user can still create an installation CD image using sysinstall relatively easily, but this is still a suboptimal approach in my opinion, when giving users a choice of installers during a transitional period before a later release (FreeBSD 9.1, perhaps) would have deflected any such problems entirely.
So much for recent examples of BSD Unix projects making ill-considered decisions in the style of the Linux community. Nothing else comes to mind. Nothing much comes to mind at all for Linux distribution teams recently making decisions in the deliberate, thoughtful manner I've come to expect from BSD Unix projects. I'm sure they're out there, but they haven't arisen in such a way that they caught my notice, probably in part because they're drowned out by the din of hasty, ill-considered approaches to presenting new technologies to users. Even Debian, once a fairly rock-solid operating system project, has been seduced by the siren call of neophilia. From what I have heard, Arch Linux probably does a better job these days of making deliberate, thoughtful technology decisions, but the one time I decided to try it out the installer would not recognize any of the partitions on the system where I wanted to install it as available for installation except the two that already had operating systems, so that didn't happen.
QUOTE: I mean just about any given Linux distribution comes with the Linux kernel (with some patches), one of a few RC managers that mostly work the same way, bash, the GNU coreutils and fileutils type stuff, and Xorg. Though it looks like X is (finally?) being slowly squeezed out of its seat.
RC/init managers are becoming a problem area in recent Linux distribution project development. A lot of systems are jumping on the neophiliac ride toward "new must be better, even if it isn't ready". If you check out pgit's comment, you should see what I mean, with a description of what Mandriva is doing. The fact that there are problems arising with systemd should be no surprise to anyone who is paying attention, of course, because it was written by Lennart Poettering -- who has become the poster child for all of the recent problems with the Linux community's attitude toward software development, and who was deeply involved in the development of some (probably most) of the most screamingly awful ideas to make it into wide distribution, notably including systemd (as already noted), PulseAudio, and the XDG Base Directory Specification. In any case, even if you just accept that systemd should be used by your favorite Linux distribution (which I don't, necessarily, especially given its authorship), a better approach to migration for Mandriva would be an install-time option during a transition period before backward compability scripts are completely tested and provide comprehensive coverage. That way, people who depend on the capabilities of the older init system that are lacking in systemd will not just be left out in the cold; they can help contribute to systemd backward compatibility coverage or adjust to systemd on their own schedules (or spend some time picking a better distribution, if it comes to that).
Bash is a compromise in the worst sense of the term. It is barely more useful as an interactive shell than the old Bourne shell and its many functionally-equivalent clones, it offers enough programming-oriented features to entice people who don't know any better (and some who should know better) into trying to do actual application development in bash but but not enough to actually make it particularly easier, and it has an absurd level of dependency on other libraries and software for a shell. Some of the advanced Korn shell descendants (pdksh perhaps, and mksh definitely) and zsh are easily better choices for a feature-rich interactive user shell, making bash look like CP/M compared to a modern BSD Unix system. Meanwhile, csh and sh are the "safe" options, reasonably simple in design, lacking some of the entirely unnecessary "advanced" programming features that might otherwise tempt people to try to write actual user applications in wholly inappropriate languages (and all of the interactive command shell languages are wholly inappropriate for application development), and avoiding dependencies that could contribute to additional problems if there are filesystem errors. My favorite interactive command shells, by contrast to bash, are zsh for its rich feature set as an interactive shell and tcsh for its coverage of the basics while still remaining pretty clean in design and offering a slightly more friendly syntax than competing shell families. If I need something for shell scripting, it's sh or nothing, for purposes of stability and portability -- and even because its simplicity and lack of features forces me to pick a real programming language early if I find myself expanding a script into something that goes beyond a simple "batch file" style of admin scripting.
Core utilities are important; you can't really have a reasonable Unix environment without them. For the most part, the GNU coreutils collection is more trouble than it is worth, though. It eschews things like command portability and compatibility, screws around with expected behavior to suit GNU project developers' whims, encourages non-Unixy ways of doing things, favors long arguments over short for even some of the most central capabilities of a tool, demands far too many dependencies for some utilities, is plagued by sloppy coding under the hood, and so on. It should be no wonder that the major BSD Unix projects are all (finally) working pretty seriously on replacing what GNU utilities they still distribute.
X11 needs replacing at this point, I think. It should be replaced carefully, though, and not in a haphazard, overly enthusiastic manner that takes no user needs into account.
QUOTE: The window manager (and for that matter, package management) are really the wildcards.
That used to be the case, but things are getting to the point lately where even when different Linux distributions use the same software for certain things the unpredictable results of such use and how these things are integrated can result in a very "wildcard" kind of feel. Pick eight different (really different, not just the same with a different window manager) distributions that use PulseAudio, and you'll probably find at least eight different ways that the distributions' sound subsystems can be broken by it.
QUOTE: The directory tree could be a little more consistent. (sysconfig... var... srv...)
This is only getting worse. Check out recent news from Fedora, for instance, where traditional and well-understood filesystem hierarchy choices are being jettisoned to make way for Poettering's "contributions". A while ago (six years, at a guess), everyone was excited about the Filesystem Hierarchy Standard (FHS), and I admit that at the time I was credulous enough to buy into it as well -- though I've learned a bit about more traditional ways to organize things and the very good reasons for doing so. The appeal of the FHS was that it would make choices about filesystem hierarchy compatible across Linux distributions and give people and understanding of how and why things are "supposed to" be organized, as a standard should. The result, though, was that a bunch of Linux distribution projects with investment in filesystem hierarchies that were unique to their own ways of doing things (or at least to their Linux distribution families' ways of doing things) got involved in the process of developing the FHS in such a manner that it turned into a mess of suboptimal compromises. Worse, a lot of the mutually incompatible ways of doing things ended up being subsumed under the heading of acceptable alternatives within the FHS. In cases where that did not allow sufficient flexibility to let the major Linux distributions to avoid changing anything about how they did anything, they often just decided they would ignore part of the standard. In some cases, "standard compliance" was achieved by doing things exactly the same as always, but providing symlinked directories to provide nominal compliance. The FHS ended up completely ignoring the same de facto standards of good organization the Unix world had developed over decades of real use and testing-in-deployment that many Linux distributions had been ignoring all along -- and the FHS even discouraged some of those good decisions established as Unix traditions. In short, it was a "success" on paper and a ridiculous failure in practice. The only real (but even then, somewhat dubious) good that came of the FHS was that some new distributions at least aimed for the middle of the standard, and ended up providing compatible filesystem organization between themselves, which may otherwise have never happened. Now, things are getting worse, with various distributions (like Fedora) changing their filesystem hierarchies as systemd adoption expedient measures, so that even the half-baked "benefits" of the FHS are being deprecated.
. . . and, of course the XDG Base Directory Specification throws more chaos into the mix, mandating cluttered explosions of pointless bureaucratic nonsense all over various parts of the filesystem hierarchy. Luckily, most people credulous enough to try to follow the specification are actully not aware it exists, as far as I've noticed.
QUOTE: So, I consider that close. Not close enough -- and it'll never be an enterprise contender (on the desktop) until there's a policy management framework and other integration bits and pieces.
Such things have been developed, and will continue to be developed, but the tensions between corporate members of the Linux community with their mutually exclusive "Not Invented Here" preferences, coupled with the neophiliac tendency to throw away even good systems currently in development before they achieve maturity in favor of whatever's newest (regardless of its ludicrous levels of incompleteness and failure to learn from history), ensures that such toolsets and projects are mostly obscurities rather than widespread, useful parts of "enterprise" software ecosystems.
---
pgit:
QUOTE: I agree with your comparison of BSD with Linux. The problem BSD faces is it's primarily going to attract users from the Linux world, rather than attract windows users.
This has mostly been true for a long time, with a few here and there coming from commercial UNIX shops and the like. The server sysadmin world has been the biggest pool for BSD Unix recruitment for quite a while. PC-BSD and similar projects (GhostBSD, DesktopBSD before the project was shut down, and so on) can offer new, more desktop oriented paths to adoption, though. Things may change in this regard in the (otherwise) foreseeable future. It's not entirely a bad thing that BSD Unix systems draw new users from the Linux pool, anyway; if the most thoughtful developers move on due to a distaste for the haphazard approach to development that is increasingly becoming the norm in the Linux community, the BSD Unix communit(y|ies) will benefit from an influx of talent that can do it some good. I flatter myself to think I'm a good example of that.
QUOTE: Unless and until someone invests in advertising, neither Linux or BSD are going to be the go-to desktop system.
That may well be the case. IBM actually invested in TV advertisement a few years ago, but it didn't last long, and was pretty narrow in its scope. It also had kind of a patronizing feel to it.
Regarding systemd in Mandriva, I commented somewhat on this in my response to nwallette in this comment, above. I think the best approach would be to develop a framework for providing an init-compatible interface (which the Mandriva developers are trying to do), but at the same time to also offer the option of installing the old init system for those who want to make use of tools dependent on the way init does things rather than just those who want to test new, incomplete backward compatibility coverage.
QUOTE: Ironically, the fact that better methods are always coming along, that development is healthy and active, has and will continue to keep Linux from being a stable, standardized desktop environment.
The real problem is that better methods are not always coming along. New methods, certainly -- but often not "better". Even when they are better (which does happen from time to time), they are often inextricably attached to other things that are worse or at best neutral and pointless. In the rare best-case scenario, where everything about the new way of doing things is better in the long run, the way these things are deployed is generally quite poorly conceived, disrupting everything for no good reason and adding to incompatibilities all over the place. Then, of course, regardless of whether the new way of doing things is better overall or not, it's likely to get replaced by something in two to five years -- something less mature, deployed in a brainless and inconsistent manner, and quite possibly worse.
I am not at all opposed to change. I'm opposed to poorly considered change just for change's sake.
QUOTE: In contrast, BSD is far more "stable" so far as the core not undergoing drastic changes.
There are some big changes underway. For instance, GCC has been replaced by Clang in the FreeBSD base system, and GNU coreutils are being replaced by BSD-specific utilities wherever they can reasonably be replaced, with work being done to make it reasonable to replace more of them. To the extent BSD Unix systems have been tied to the vagaries of the Linux development community, they are cutting those ties. That is turning out to be a pretty big set of changes, but the effort is being undertaken in a more thoughtful, better planned migration than the sort of thing we're seeing in the Linux community -- and the result is that the various BSD Unix systems are becoming better insulated against being affected by those problems.
FreeBSD also has a new package system in development, called pkgng. It's coming along nicely, though it is not recommended for production use yet. In the Linux world, of course, half a dozen major distributions would have already adopted something at this level of completion for their default toolsets. Meanwhile, helpful port system management tools include both portupgrade and portmaster -- and both of these are covered extensively in documentation, equally available and supported by the platform, and developed to work as additions to the underlying ports system rather than as (even partial) replacements for it. It should be obvious how this differs from the way similar things would be done in much of the Linux world.
There's definitely something positive to be said for the "go nuts, trial by fire" approach to development and deployment of software. Such a thing is great for people who love the bleeding edge. The problem is that people in the Linux world seem intent on applying such a "go nuts, trial by fire" approach to everything, everywhere, leaving nowhere for people to go when they want to have a stable, clean, unsurprising system that works well in the same ways as older systems worked.
. . . except maybe BSD Unix.
QUOTE: I've seen the installer, and I was impressed that WiFi was working from the Live CD.
The various LiveCDs have mostly got stuff like that right, which is nice. For some reason, installing from a LiveCD fails on some things the LiveCDs themselves got right probably about five percent of the time, in my experience -- maybe a little less often than that.
QUOTE: Also never used BSD of any variant. I think maybe I should. I'm intrigued by how you're saying they've nailed down the core to give it a fighting chance of being a stable, complete package.
The core teams for the various major BSD Unix systems are generally very invested in ensuring they build very stable, secure systems, and have a tendency to put in the extra time to get things right the first time. This is in contrast to the way a lot of Linux distributions do things, where they come up with an idea and try to rush it out in a new release as quickly as they reasonably can, even if that means things are broken in numerous subtle ways or one or two big, surprising ways, and even if this means they inconvenience a lot of users with new design ideas.
That's not to say that BSD Unix developers don't occasionally make a hasty decision a little like the way I just describe the Linux community doing things, or that some Linux distributions don't make very deliberate, careful decisions from time to time. For instance, with FreeBSD 9.0, a new installer that changes the way things are done was used; some places that relied on specific capabilities of the older installer (sysinstall) for installation scripting were inconvenienced by the way the new installer (bsdinstall) was just swapped in place of the old, as opposed to what they had been led to believe would happen (an install-time or download-time choice of which installer would be used). It's my understanding that a knowledgeable user can still create an installation CD image using sysinstall relatively easily, but this is still a suboptimal approach in my opinion, when giving users a choice of installers during a transitional period before a later release (FreeBSD 9.1, perhaps) would have deflected any such problems entirely.
So much for recent examples of BSD Unix projects making ill-considered decisions in the style of the Linux community. Nothing else comes to mind. Nothing much comes to mind at all for Linux distribution teams recently making decisions in the deliberate, thoughtful manner I've come to expect from BSD Unix projects. I'm sure they're out there, but they haven't arisen in such a way that they caught my notice, probably in part because they're drowned out by the din of hasty, ill-considered approaches to presenting new technologies to users. Even Debian, once a fairly rock-solid operating system project, has been seduced by the siren call of neophilia. From what I have heard, Arch Linux probably does a better job these days of making deliberate, thoughtful technology decisions, but the one time I decided to try it out the installer would not recognize any of the partitions on the system where I wanted to install it as available for installation except the two that already had operating systems, so that didn't happen.
QUOTE: I mean just about any given Linux distribution comes with the Linux kernel (with some patches), one of a few RC managers that mostly work the same way, bash, the GNU coreutils and fileutils type stuff, and Xorg. Though it looks like X is (finally?) being slowly squeezed out of its seat.
RC/init managers are becoming a problem area in recent Linux distribution project development. A lot of systems are jumping on the neophiliac ride toward "new must be better, even if it isn't ready". If you check out pgit's comment, you should see what I mean, with a description of what Mandriva is doing. The fact that there are problems arising with systemd should be no surprise to anyone who is paying attention, of course, because it was written by Lennart Poettering -- who has become the poster child for all of the recent problems with the Linux community's attitude toward software development, and who was deeply involved in the development of some (probably most) of the most screamingly awful ideas to make it into wide distribution, notably including systemd (as already noted), PulseAudio, and the XDG Base Directory Specification. In any case, even if you just accept that systemd should be used by your favorite Linux distribution (which I don't, necessarily, especially given its authorship), a better approach to migration for Mandriva would be an install-time option during a transition period before backward compability scripts are completely tested and provide comprehensive coverage. That way, people who depend on the capabilities of the older init system that are lacking in systemd will not just be left out in the cold; they can help contribute to systemd backward compatibility coverage or adjust to systemd on their own schedules (or spend some time picking a better distribution, if it comes to that).
Bash is a compromise in the worst sense of the term. It is barely more useful as an interactive shell than the old Bourne shell and its many functionally-equivalent clones, it offers enough programming-oriented features to entice people who don't know any better (and some who should know better) into trying to do actual application development in bash but but not enough to actually make it particularly easier, and it has an absurd level of dependency on other libraries and software for a shell. Some of the advanced Korn shell descendants (pdksh perhaps, and mksh definitely) and zsh are easily better choices for a feature-rich interactive user shell, making bash look like CP/M compared to a modern BSD Unix system. Meanwhile, csh and sh are the "safe" options, reasonably simple in design, lacking some of the entirely unnecessary "advanced" programming features that might otherwise tempt people to try to write actual user applications in wholly inappropriate languages (and all of the interactive command shell languages are wholly inappropriate for application development), and avoiding dependencies that could contribute to additional problems if there are filesystem errors. My favorite interactive command shells, by contrast to bash, are zsh for its rich feature set as an interactive shell and tcsh for its coverage of the basics while still remaining pretty clean in design and offering a slightly more friendly syntax than competing shell families. If I need something for shell scripting, it's sh or nothing, for purposes of stability and portability -- and even because its simplicity and lack of features forces me to pick a real programming language early if I find myself expanding a script into something that goes beyond a simple "batch file" style of admin scripting.
Core utilities are important; you can't really have a reasonable Unix environment without them. For the most part, the GNU coreutils collection is more trouble than it is worth, though. It eschews things like command portability and compatibility, screws around with expected behavior to suit GNU project developers' whims, encourages non-Unixy ways of doing things, favors long arguments over short for even some of the most central capabilities of a tool, demands far too many dependencies for some utilities, is plagued by sloppy coding under the hood, and so on. It should be no wonder that the major BSD Unix projects are all (finally) working pretty seriously on replacing what GNU utilities they still distribute.
X11 needs replacing at this point, I think. It should be replaced carefully, though, and not in a haphazard, overly enthusiastic manner that takes no user needs into account.
QUOTE: The window manager (and for that matter, package management) are really the wildcards.
That used to be the case, but things are getting to the point lately where even when different Linux distributions use the same software for certain things the unpredictable results of such use and how these things are integrated can result in a very "wildcard" kind of feel. Pick eight different (really different, not just the same with a different window manager) distributions that use PulseAudio, and you'll probably find at least eight different ways that the distributions' sound subsystems can be broken by it.
QUOTE: The directory tree could be a little more consistent. (sysconfig... var... srv...)
This is only getting worse. Check out recent news from Fedora, for instance, where traditional and well-understood filesystem hierarchy choices are being jettisoned to make way for Poettering's "contributions". A while ago (six years, at a guess), everyone was excited about the Filesystem Hierarchy Standard (FHS), and I admit that at the time I was credulous enough to buy into it as well -- though I've learned a bit about more traditional ways to organize things and the very good reasons for doing so. The appeal of the FHS was that it would make choices about filesystem hierarchy compatible across Linux distributions and give people and understanding of how and why things are "supposed to" be organized, as a standard should. The result, though, was that a bunch of Linux distribution projects with investment in filesystem hierarchies that were unique to their own ways of doing things (or at least to their Linux distribution families' ways of doing things) got involved in the process of developing the FHS in such a manner that it turned into a mess of suboptimal compromises. Worse, a lot of the mutually incompatible ways of doing things ended up being subsumed under the heading of acceptable alternatives within the FHS. In cases where that did not allow sufficient flexibility to let the major Linux distributions to avoid changing anything about how they did anything, they often just decided they would ignore part of the standard. In some cases, "standard compliance" was achieved by doing things exactly the same as always, but providing symlinked directories to provide nominal compliance. The FHS ended up completely ignoring the same de facto standards of good organization the Unix world had developed over decades of real use and testing-in-deployment that many Linux distributions had been ignoring all along -- and the FHS even discouraged some of those good decisions established as Unix traditions. In short, it was a "success" on paper and a ridiculous failure in practice. The only real (but even then, somewhat dubious) good that came of the FHS was that some new distributions at least aimed for the middle of the standard, and ended up providing compatible filesystem organization between themselves, which may otherwise have never happened. Now, things are getting worse, with various distributions (like Fedora) changing their filesystem hierarchies as systemd adoption expedient measures, so that even the half-baked "benefits" of the FHS are being deprecated.
. . . and, of course the XDG Base Directory Specification throws more chaos into the mix, mandating cluttered explosions of pointless bureaucratic nonsense all over various parts of the filesystem hierarchy. Luckily, most people credulous enough to try to follow the specification are actully not aware it exists, as far as I've noticed.
QUOTE: So, I consider that close. Not close enough -- and it'll never be an enterprise contender (on the desktop) until there's a policy management framework and other integration bits and pieces.
Such things have been developed, and will continue to be developed, but the tensions between corporate members of the Linux community with their mutually exclusive "Not Invented Here" preferences, coupled with the neophiliac tendency to throw away even good systems currently in development before they achieve maturity in favor of whatever's newest (regardless of its ludicrous levels of incompleteness and failure to learn from history), ensures that such toolsets and projects are mostly obscurities rather than widespread, useful parts of "enterprise" software ecosystems.
---
pgit:
QUOTE: I agree with your comparison of BSD with Linux. The problem BSD faces is it's primarily going to attract users from the Linux world, rather than attract windows users.
This has mostly been true for a long time, with a few here and there coming from commercial UNIX shops and the like. The server sysadmin world has been the biggest pool for BSD Unix recruitment for quite a while. PC-BSD and similar projects (GhostBSD, DesktopBSD before the project was shut down, and so on) can offer new, more desktop oriented paths to adoption, though. Things may change in this regard in the (otherwise) foreseeable future. It's not entirely a bad thing that BSD Unix systems draw new users from the Linux pool, anyway; if the most thoughtful developers move on due to a distaste for the haphazard approach to development that is increasingly becoming the norm in the Linux community, the BSD Unix communit(y|ies) will benefit from an influx of talent that can do it some good. I flatter myself to think I'm a good example of that.
QUOTE: Unless and until someone invests in advertising, neither Linux or BSD are going to be the go-to desktop system.
That may well be the case. IBM actually invested in TV advertisement a few years ago, but it didn't last long, and was pretty narrow in its scope. It also had kind of a patronizing feel to it.
Regarding systemd in Mandriva, I commented somewhat on this in my response to nwallette in this comment, above. I think the best approach would be to develop a framework for providing an init-compatible interface (which the Mandriva developers are trying to do), but at the same time to also offer the option of installing the old init system for those who want to make use of tools dependent on the way init does things rather than just those who want to test new, incomplete backward compatibility coverage.
QUOTE: Ironically, the fact that better methods are always coming along, that development is healthy and active, has and will continue to keep Linux from being a stable, standardized desktop environment.
The real problem is that better methods are not always coming along. New methods, certainly -- but often not "better". Even when they are better (which does happen from time to time), they are often inextricably attached to other things that are worse or at best neutral and pointless. In the rare best-case scenario, where everything about the new way of doing things is better in the long run, the way these things are deployed is generally quite poorly conceived, disrupting everything for no good reason and adding to incompatibilities all over the place. Then, of course, regardless of whether the new way of doing things is better overall or not, it's likely to get replaced by something in two to five years -- something less mature, deployed in a brainless and inconsistent manner, and quite possibly worse.
I am not at all opposed to change. I'm opposed to poorly considered change just for change's sake.
QUOTE: In contrast, BSD is far more "stable" so far as the core not undergoing drastic changes.
There are some big changes underway. For instance, GCC has been replaced by Clang in the FreeBSD base system, and GNU coreutils are being replaced by BSD-specific utilities wherever they can reasonably be replaced, with work being done to make it reasonable to replace more of them. To the extent BSD Unix systems have been tied to the vagaries of the Linux development community, they are cutting those ties. That is turning out to be a pretty big set of changes, but the effort is being undertaken in a more thoughtful, better planned migration than the sort of thing we're seeing in the Linux community -- and the result is that the various BSD Unix systems are becoming better insulated against being affected by those problems.
FreeBSD also has a new package system in development, called pkgng. It's coming along nicely, though it is not recommended for production use yet. In the Linux world, of course, half a dozen major distributions would have already adopted something at this level of completion for their default toolsets. Meanwhile, helpful port system management tools include both portupgrade and portmaster -- and both of these are covered extensively in documentation, equally available and supported by the platform, and developed to work as additions to the underlying ports system rather than as (even partial) replacements for it. It should be obvious how this differs from the way similar things would be done in much of the Linux world.
There's definitely something positive to be said for the "go nuts, trial by fire" approach to development and deployment of software. Such a thing is great for people who love the bleeding edge. The problem is that people in the Linux world seem intent on applying such a "go nuts, trial by fire" approach to everything, everywhere, leaving nowhere for people to go when they want to have a stable, clean, unsurprising system that works well in the same ways as older systems worked.
. . . except maybe BSD Unix.
Thanks, Slayer_ good to know it's not that I'm in the dog house...
Apotheon: WoW. You wrote two excellent articles in one response. Thank you for the effort. It was well worth it. (eg you made me shudder thinking I certainly would be better off learning the inner workings of BSD)
I especial amen this:
"...coupled with the neophiliac tendency to throw away even good systems currently in development before they achieve maturity in favor of whatever's newest (regardless of its ludicrous levels of incompleteness and failure to learn from history), ensures that such toolsets and projects are mostly obscurities rather than widespread, useful parts of "enterprise" software ecosystems."
That is the #1 cause of problems when deploying Linux. Users are probably as much to blame for the 'gotta be cutting edge at all cost' mentality. All the major distros have daily build development projects and a lot of users running their production machines with it.
The most lively and interesting feedback developers get is from that facet of the community. Once there is a frozen 'official' release developers would naturally be less than enthusiastic about looking backward to squash bugs.
Besides, they're working on that whatever new gee-whiz system that's going to entirely replace the guts of past releases that they'll release prematurely anyway.
Every incentive points away from creating a truly stable (forget about long term) release.
I still haven't decided which BSD I'll look into. Probably whichever provides the best desktop experience for the occasion a user wants a desktop on their file server.
Apotheon: WoW. You wrote two excellent articles in one response. Thank you for the effort. It was well worth it. (eg you made me shudder thinking I certainly would be better off learning the inner workings of BSD)
I especial amen this:
"...coupled with the neophiliac tendency to throw away even good systems currently in development before they achieve maturity in favor of whatever's newest (regardless of its ludicrous levels of incompleteness and failure to learn from history), ensures that such toolsets and projects are mostly obscurities rather than widespread, useful parts of "enterprise" software ecosystems."
That is the #1 cause of problems when deploying Linux. Users are probably as much to blame for the 'gotta be cutting edge at all cost' mentality. All the major distros have daily build development projects and a lot of users running their production machines with it.
The most lively and interesting feedback developers get is from that facet of the community. Once there is a frozen 'official' release developers would naturally be less than enthusiastic about looking backward to squash bugs.
Besides, they're working on that whatever new gee-whiz system that's going to entirely replace the guts of past releases that they'll release prematurely anyway.
Every incentive points away from creating a truly stable (forget about long term) release.
I still haven't decided which BSD I'll look into. Probably whichever provides the best desktop experience for the occasion a user wants a desktop on their file server.
For the easiest install and friendliest desktop environment, you're probably better off with something like PC-BSD or GhostBSD than other options. PC-BSD is the more mature of the two, comes with an interesting alternative software installation and management system called PBI, and uses KDE by default. GhostBSD uses GNOME by default. I know that PC-BSD is based on FreeBSD, and I'm pretty sure that GhostBSD is as well. Neither is really to my taste, so I'm not too terribly familiar with either of them, but PC-BSD really is FreeBSD, just with extra tools, a default environment ready to install, and a different installer -- which, by the way, will actually let you install FreeBSD more directly than the slightly modified PC-BSD variant. In fact, I'm getting ready to use the PC-BSD installer to install a vanilla FreeBSD system in the near future (more on that in a moment).
QUOTE: Apotheon: WoW. You wrote two excellent articles in one response.
Thanks for the compliment. If CBSi had not decided to stop letting me contribute articles to TR for bureaucratic reasons, I would probably have submitted a couple of real articles -- better organized, more broadly useful in their final forms, more fully linked and otherwise referenced, and so on -- for publication by TR directly. C'est la vie.
QUOTE: I certainly would be better off learning the inner workings of BSD
That depends on a lot of things, and obviously you are best qualified to determine that. There are some things that may suit you better about certain Linux distributions.
In fact, I have been using a Linux distribution pretty heavily for almost exactly one year, because of lack of driver support for Sandybridge graphics architecture on FreeBSD. There has been work on that, though, paid for by the FreeBSD Foundation. Experimental support for the new GEM/KMS stuff needed to get the graphics architecture in my primary laptop working with FreeBSD has been included in a new PC-BSD installer, and I'm making preparations to install it on this laptop. Because of some local issues (e.g. my backup server is *full*, without any room for more drives, so I'm setting up a new server so I can back up the laptop in question before using the PC-BSD installer to install yet another OS on it -- FreeBSD, of course), there are some things I need to do before installing FreeBSD on the laptop, finally. I'm looking forward to it.
Vanilla FreeBSD is in many ways comparable to the major Linux distributions in much the same way the major Linux distributions were to MS Windows a decade ago: more stable, easier to fix if something goes wrong down the road (but much less likely to have such problems -- see "more stable" earlier in the sentence), and more easily and fully tweakable to suit your specific preferences if you have the technical knowledge, but sometimes requiring more technical know-how to get things set up to satisfy your preferences and needs. That last item sometimes proves more prohibitive than tolerable for some people's situations. I had been using Debian for a while, doing minimal installs then building up my environment from there using apt-get, when I started using FreeBSD in 2005; with that experience, I found FreeBSD only slightly more work to learn to use effectively than what would have been required for another major Linux distribution at the time. Things are of course a bit different now, in that switching Linux distributions for many people means just learning how to click around in a slightly different GUI environment. This is why PC-BSD or GhostBSD might be a better choice for many people -- people who have probably not had the same kind of experience with minimalist installs of some Linux distribution like Debian was then, like I used "back in the day". No reason not to give some kind of BSD Unix system a whirl, though; learning is always good, and if you stick with it you might find you like it more than whatever you had been using before that.
QUOTE: All the major distros have daily build development projects and a lot of users running their production machines with it.
This is true -- and, now that I think about it, I suppose some of those Linux community developers might end up with a feeling that it's okay to push alpha-quality software into production releases, or even lose the ability to meaningfully differentiate between alpha-quality software and release-quality software if they aren't careful (if they ever had that ability). I wonder if there is a newer generation of Linux community developers who simply never learned to differentiate meaningfully, having cut their teeth on alpha-quality software in the first place.
I don't know if this is related, but I know that a Drupal developer of my recent acquaintance has mentioned some troublesome differences between "old guard" developers and a new generation of open source developers, where the latter is very consciously "culturally sensitive". This later generation seems to be made up of people who expect everyone to notice they're female, or Pakistani, or gender dysphoric, or whatever, and value that as a contribution to the development community; the former (the "old guard") generation, meanwhile, had grown into a community that until recently valued people who could hack code well, and everyone tended more to leave his or her differences at the door. According to this Drupal developer's commentary -- and I find that this matches some of my own experience -- it used to be normal to regard other developers with whom one collaborates online as a username and a set of skills, with nobody pushing their non-coder labels on others expecting acknowledgement of them, but now the opposite seems to be increasingly true. I think such shifts are, however, slower to affect the BSD Unix community.
QUOTE: Once there is a frozen 'official' release developers would naturally be less than enthusiastic about looking backward to squash bugs.
I kinda get the impression that there's less of an impulse toward mentoring in open source software than used to be prevalent, for the most part. I think bug squashing used to be more commonly used as a way to mentor new developers in the community, pointing them at bugs to fix then reviewing their work, so that both old and new developers were involved in the bugfixing process. Now, it seems like nobody's interested in the mentoring process any longer. New developers want immediate recognition as top-quality contributors, and old developers want to work on stuff they find interesting in and of itself rather than fixing bugs and helping new developers. There are always exceptions, of course, but it seems like this is the case, and the new developers -- lacking the practiced discipline of auld -- are writing code from scratch to try to contribute something both because of the perception this will be worth more to them in terms of reputation and because they find it easier to embark on a brand new hair-brained scheme than to take the time to learn about someone else's code well enough to hunt down bugs and fix them. They're right, too; it's easier to write new code than tackle the complexities of old code when there's nobody available to help them out along the way. I suppose I might just be misreading the trail, though.
QUOTE: Apotheon: WoW. You wrote two excellent articles in one response.
Thanks for the compliment. If CBSi had not decided to stop letting me contribute articles to TR for bureaucratic reasons, I would probably have submitted a couple of real articles -- better organized, more broadly useful in their final forms, more fully linked and otherwise referenced, and so on -- for publication by TR directly. C'est la vie.
QUOTE: I certainly would be better off learning the inner workings of BSD
That depends on a lot of things, and obviously you are best qualified to determine that. There are some things that may suit you better about certain Linux distributions.
In fact, I have been using a Linux distribution pretty heavily for almost exactly one year, because of lack of driver support for Sandybridge graphics architecture on FreeBSD. There has been work on that, though, paid for by the FreeBSD Foundation. Experimental support for the new GEM/KMS stuff needed to get the graphics architecture in my primary laptop working with FreeBSD has been included in a new PC-BSD installer, and I'm making preparations to install it on this laptop. Because of some local issues (e.g. my backup server is *full*, without any room for more drives, so I'm setting up a new server so I can back up the laptop in question before using the PC-BSD installer to install yet another OS on it -- FreeBSD, of course), there are some things I need to do before installing FreeBSD on the laptop, finally. I'm looking forward to it.
Vanilla FreeBSD is in many ways comparable to the major Linux distributions in much the same way the major Linux distributions were to MS Windows a decade ago: more stable, easier to fix if something goes wrong down the road (but much less likely to have such problems -- see "more stable" earlier in the sentence), and more easily and fully tweakable to suit your specific preferences if you have the technical knowledge, but sometimes requiring more technical know-how to get things set up to satisfy your preferences and needs. That last item sometimes proves more prohibitive than tolerable for some people's situations. I had been using Debian for a while, doing minimal installs then building up my environment from there using apt-get, when I started using FreeBSD in 2005; with that experience, I found FreeBSD only slightly more work to learn to use effectively than what would have been required for another major Linux distribution at the time. Things are of course a bit different now, in that switching Linux distributions for many people means just learning how to click around in a slightly different GUI environment. This is why PC-BSD or GhostBSD might be a better choice for many people -- people who have probably not had the same kind of experience with minimalist installs of some Linux distribution like Debian was then, like I used "back in the day". No reason not to give some kind of BSD Unix system a whirl, though; learning is always good, and if you stick with it you might find you like it more than whatever you had been using before that.
QUOTE: All the major distros have daily build development projects and a lot of users running their production machines with it.
This is true -- and, now that I think about it, I suppose some of those Linux community developers might end up with a feeling that it's okay to push alpha-quality software into production releases, or even lose the ability to meaningfully differentiate between alpha-quality software and release-quality software if they aren't careful (if they ever had that ability). I wonder if there is a newer generation of Linux community developers who simply never learned to differentiate meaningfully, having cut their teeth on alpha-quality software in the first place.
I don't know if this is related, but I know that a Drupal developer of my recent acquaintance has mentioned some troublesome differences between "old guard" developers and a new generation of open source developers, where the latter is very consciously "culturally sensitive". This later generation seems to be made up of people who expect everyone to notice they're female, or Pakistani, or gender dysphoric, or whatever, and value that as a contribution to the development community; the former (the "old guard") generation, meanwhile, had grown into a community that until recently valued people who could hack code well, and everyone tended more to leave his or her differences at the door. According to this Drupal developer's commentary -- and I find that this matches some of my own experience -- it used to be normal to regard other developers with whom one collaborates online as a username and a set of skills, with nobody pushing their non-coder labels on others expecting acknowledgement of them, but now the opposite seems to be increasingly true. I think such shifts are, however, slower to affect the BSD Unix community.
QUOTE: Once there is a frozen 'official' release developers would naturally be less than enthusiastic about looking backward to squash bugs.
I kinda get the impression that there's less of an impulse toward mentoring in open source software than used to be prevalent, for the most part. I think bug squashing used to be more commonly used as a way to mentor new developers in the community, pointing them at bugs to fix then reviewing their work, so that both old and new developers were involved in the bugfixing process. Now, it seems like nobody's interested in the mentoring process any longer. New developers want immediate recognition as top-quality contributors, and old developers want to work on stuff they find interesting in and of itself rather than fixing bugs and helping new developers. There are always exceptions, of course, but it seems like this is the case, and the new developers -- lacking the practiced discipline of auld -- are writing code from scratch to try to contribute something both because of the perception this will be worth more to them in terms of reputation and because they find it easier to embark on a brand new hair-brained scheme than to take the time to learn about someone else's code well enough to hunt down bugs and fix them. They're right, too; it's easier to write new code than tackle the complexities of old code when there's nobody available to help them out along the way. I suppose I might just be misreading the trail, though.
A lot of that is redundant, like maybe there are about four genuine items to mention but they've been subdivided to pad out the list to 10.
The list items are almost all superficial and faddish rather than meaningful.
Some of this stuff glosses over tremendous problems in Linux-oriented development, including some stuff that purports to address important issues but mostly just tosses yet another kludge onto the pile and ends up screwing up some of the things that were already there and working well (e.g. additions of PulseAudio, continuing development direction of NetworkManager, and Unity's wholesale rejection of things that work in favor of what amounts to an alpha quality interface with fancy drop shadows, transparency, rounded corners, reflection effects, and so on). Probably the worst thing about all this stuff is that pointless neophilia passing itself off as innovation is actually destroying previous good work on making usable systems based on the Linux kernel.
I think the relentless pursuit of confection to compete with MS Windows and Apple MacOS X has blinded a lot of Linux developers that, in addition to matching those systems in terms of gloss and flash, the system must also offer something better than those other OSes to give people a reason to switch. If you destroy your advantages while pursuing parity on the things that are not advantages, you're just going to end up looking like a pale imitation.
. . . and let's not forget that a lot of the more prominent developers in the Linux community have started arguing against ensuring software portability. When your numbers are smaller than the competition, portability provides gateway drugs that can lure people to your system. Abandoning portability concerns is just burning the bridges people might otherwise cross to try out your system.
The list items are almost all superficial and faddish rather than meaningful.
Some of this stuff glosses over tremendous problems in Linux-oriented development, including some stuff that purports to address important issues but mostly just tosses yet another kludge onto the pile and ends up screwing up some of the things that were already there and working well (e.g. additions of PulseAudio, continuing development direction of NetworkManager, and Unity's wholesale rejection of things that work in favor of what amounts to an alpha quality interface with fancy drop shadows, transparency, rounded corners, reflection effects, and so on). Probably the worst thing about all this stuff is that pointless neophilia passing itself off as innovation is actually destroying previous good work on making usable systems based on the Linux kernel.
I think the relentless pursuit of confection to compete with MS Windows and Apple MacOS X has blinded a lot of Linux developers that, in addition to matching those systems in terms of gloss and flash, the system must also offer something better than those other OSes to give people a reason to switch. If you destroy your advantages while pursuing parity on the things that are not advantages, you're just going to end up looking like a pale imitation.
. . . and let's not forget that a lot of the more prominent developers in the Linux community have started arguing against ensuring software portability. When your numbers are smaller than the competition, portability provides gateway drugs that can lure people to your system. Abandoning portability concerns is just burning the bridges people might otherwise cross to try out your system.
I currently have Mint Linux installed on 2 or 3 machines around the house (mainly as replacements for Ubuntu and the flaky Unity interface). Talk about painless installations! Mint's got it. You don't have to jump through hoops to get the restricted drivers i/e flash plugins, nVidia, etc.. The interface is clean and fast unless you're working with slower than 1.5 ghz. single core processors and less than 512 mb. of RAM. Everything is right where you need it. Updates work, and software installation/removal for pretty much everything available.. works. The only quirk I've found is on some older machines is the auto-ethernet start doesn't always work, although you only need to click on the taskbar icon and 'auto-eth' and it starts right up. With everything from full blown CRM's to fancy audio apps, it's one of the most universal OS's to date. Did I mention that it looks nice too?
I have experimented with Linux since the days of Red Hat Linux. Red Hat had an awful user manual that must have been written by a third grade dropout.
Then I tried Mandrake, now Mandriva and maybe soon no more, which, had a much better user manual. On to SuSe that had the best user and administrator's manual I have found with a Linux distribution and still use for a reference from time to time.
At one time, I favored Mandriva, and it's derivative PC Linux, perhaps becuase the audio always worked and it was the only distribution where the number lock worked after installation,
I never could get excited about Ubunta. I'm not sure why. But I did like Linux Mint when I first installed it. But now the problem. For some reason, many Linux distributions have trouble detecting and setting up sound cards. It's gotten to the point that I will not use any distribution that cannot detect and set up my sound card. It just waste too much time going through the procedure to do it manually. Which brings up a new problem. I have Linux Mint 7 installed on a older PC. Linux Mint 7 detected my sound carrd and set it up properly when I installed the program. Recently I decided to upgrade to Linux Mint 12 based on a lot of favorable reviews. I was disappointed to discover that Linux mint 12, unlike Linux Mint 7, was unable to detect and setup the sound card on the same PC.
To me, this is the biggest weakness of Linux. There is no consistency between, or within, distirbutions. Yes, we get nicer graphics all the time. But you still feel like you have an old clunker under the hood.
Then I tried Mandrake, now Mandriva and maybe soon no more, which, had a much better user manual. On to SuSe that had the best user and administrator's manual I have found with a Linux distribution and still use for a reference from time to time.
At one time, I favored Mandriva, and it's derivative PC Linux, perhaps becuase the audio always worked and it was the only distribution where the number lock worked after installation,
I never could get excited about Ubunta. I'm not sure why. But I did like Linux Mint when I first installed it. But now the problem. For some reason, many Linux distributions have trouble detecting and setting up sound cards. It's gotten to the point that I will not use any distribution that cannot detect and set up my sound card. It just waste too much time going through the procedure to do it manually. Which brings up a new problem. I have Linux Mint 7 installed on a older PC. Linux Mint 7 detected my sound carrd and set it up properly when I installed the program. Recently I decided to upgrade to Linux Mint 12 based on a lot of favorable reviews. I was disappointed to discover that Linux mint 12, unlike Linux Mint 7, was unable to detect and setup the sound card on the same PC.
To me, this is the biggest weakness of Linux. There is no consistency between, or within, distirbutions. Yes, we get nicer graphics all the time. But you still feel like you have an old clunker under the hood.
The favorable reviews are comparing it to Ubuntu, which is really bad. But new Mint is pretty bad too, it uses much more hardware resources and produces an uglier GUI (thanks entirely to GNOME 3). It also has funky hardware issues.
Try Mint 11, it still uses GNOME 2 and properly works.
Try Mint 11, it still uses GNOME 2 and properly works.
As Apotheon has said above, the sound system has always been a source of headaches in Linux. You'd think it would be easy to get right. Video (graphics, not multimedia), too -- at least that one is more to do with hardware vendors holding their cards close to their chests and making life difficult for OSS developers.
As essential as these two things are, they're still broken. I feel like a complete fool when I argue over Linux stability and then can't even get something like on-the-fly secondary monitor support to work reliably. Even XP can detect a monitor being plugged in and configure it as a desktop extension without too much trouble.
I don't even try to get Bluetooth working. I haven't had a compelling need yet, though.
Having done some ALSA programming, the underlying architecture doesn't appear to be too terribly bad. Maybe not ideal, but workable. Things just go to pot when you throw in X Windows and KDE or Gnome.
As essential as these two things are, they're still broken. I feel like a complete fool when I argue over Linux stability and then can't even get something like on-the-fly secondary monitor support to work reliably. Even XP can detect a monitor being plugged in and configure it as a desktop extension without too much trouble.
I don't even try to get Bluetooth working. I haven't had a compelling need yet, though.
Having done some ALSA programming, the underlying architecture doesn't appear to be too terribly bad. Maybe not ideal, but workable. Things just go to pot when you throw in X Windows and KDE or Gnome.
When I first started using FreeBSD for my own purposes, back in 2005, getting sound working consisted of issuing two or three simple commands that were well documented. By the time I got around to scripting that, FreeBSD had already obviated the need for those commands so that it would always "just work" without issuing any commands at all. I have never had to do anything to get sound working since.
This is the sort of "don't screw with things that work by replacing them with things that don't" approach to development the Linux community needs to relearn.
This is the sort of "don't screw with things that work by replacing them with things that don't" approach to development the Linux community needs to relearn.
- Keyboard Shortcuts:
- Prev
- Next
- Toggle
