Intelligent design and evolution are not mutually exclusive. Even if life was once designed, evolution is still possible. Evolution means that, through genetic mutations, the best adapted individuals survive and pass their genes on to the next generation. When done often enough, the species can become dramatically different from the original. Genetic mutation is well-known and is a proven phenomenom.
Have you even TRIED Gnome? The menus are highly descriptive. gedit is listed as "Text Editor" and Sabayon is listed as "User Profile Editor". You're whining about an already solved issue.
I don't know where you have been the past 4 years, but font rendering isn't a problem now. Most likely you're either using an outdated distro which doesn't have a modern font system, or you don't have good fonts. Download the Bitstream Vera fonts or copy the Arial/Times New Roman fonts from your Windows partition and you're done.
I didn't say they're exactly the same, I said they're almost the same. Look at the layout.
As for your comment: you can. The GTK list box supports type-as-you-find since 2.6, and the list box in the file selector is focused by default so you can immediately begin typing. For a comparison, look at the MacOS X open file dialog - it also doesn't have a filename entry, just like the GTK one!
Though yeah, the GTK has a horrific file selection browser that's supposedly designed to be "user friendly"
Is MacOS X friendly? You'd probably say yes. Is the MacOS X file selector friendly? You'd probably say yes. Well here's a surprise for you: the GTK file selector is almost identical to the MacOS X file selector. Then how come the GTK file selector is bad and the MacOS X file selector is good? Please, do explain this. The only reason I can come up with is that people these days like to bash Linux-based stuff and like to praise OS X, even when they've never used the latter.
"I haven't tried Gimp on Mac to know how out-of-place it's file selector is there."...... Dude, the GTK file selector looks almost identical to the MacOS X file selector! How come people complain at the GTK file selector, but praise the Mac file selector, when they're almost identical?
Besides, even that can be prevented by the OS. Fedora ships ExecShield (no idea why most other distros don't ship this) which makes the app crash (instead of letting an attacker take over) when a buffer overflow occurs.
"If the patch will break alot of situations, it won't get in."
The C++ ABI breakage broke many, many, many things, and got in. So I'm not convinced that this is a valid argument to reject it.
That side, from what I've seen: Michael Meek's patches are not rejected, but ignored. That's even worse than rejected. His fixes aren't only about some x% speedup, but also very low-level things like sanatizing ELF symbol conflict resolution. His patch wasn't reviewed, it was tested, it wasn't discussed - but ignored.
Do something about it? I already do. And that is exactly why I'm "bitching" - but I prefer to call it constructive criticism.
So basically what you're saying is that Autopackage is the wrong solution because incompatibilities between distros exist?
Autopackage aside, my entire point was that incompatibilities like that *shouldn't* exist. Too many people take the incompatibilities for granted, that is the problem. They think the incompatibilities is something natural, something that shouldn't/can't be fixed, something that is acceptable. In other words, a cultural problem, not a technical one. Its not that things cannot be fixed - they can, look at Michael Meek's glibc patches. Its that the community don't recognize the problems -> for example: Michael Meek's patches was rejected/ignored.
Unless the distro people and many people in the community recognize that the incompatibilities are unacceptable, things won't get fixed, and I'm afraid Linux will not succeed on the desktop until that happens. For instance, one of my classmates, who recently installed a Linux distro, complained about how hard it is to install software on Linux.
However binary distribution of C++ apps impossible? Give me a break. You speak as if upgrading the core components of a system are a daily tasks for the user. We have packages for that and the distribution compiles the code and makes a binary package for the distribution!!! See, thats easy. If you're favorite software has been updated then wait for your disitribution to update it. No different than having to wait for Office 2009! Same thing.
That isn't the point. Try running a C++ binary, which was compiled on distro X, on distro Y. If you're lucky, it works. If you're not lucky, it crashes for mysterious reasons. This is caused by C++ ABI breakages and ELF symbol conflicts. See this for a technical introduction about the C++ ABI incompatibility problem, and this for more technical information about C++ problems, and this for technical information about problems in ELF.
Notice that I mentioned the word "technical" several times. So yes we know what we're talking about. If you don't believe us, feel free to proof read our technical documents and proof us wrong.
Anyway, that was just to prove you that the C++ binary problems exist and are real. Now to my following (also very important!) point: Open source software DO need to be able to distribute cross-distribution binaries. The need to distribute cross-distribution binaries isn't specific to proprietary software, as too many people seem to believe. Normal users don't, and shouldn't have to, care about compiling. It is their right - after all, they may have a legitimate reason to not learn it (too busy with work, for example). Therefore, the ability to easily install applications (without compiling!) is a good thing. But for that to happen, it must be possible to run a binary on multiple distributions! This implies that we cannot rely the distribution to take care of *all* the packaging. Its simply not possible, there is not enough manpower for that. I'm not saying that distributions should not package software, but it should be possible for the upstream (open source!) developers to distribution binaries (for their open source software!).
Notice how I keep emphasizing open source. Too many people associate "proprietary" with "evil" so I'm trying hard to point out that open source software needs to be easily installable too! Upstream open source software developers should be able to create binaries that run on multiple distributions!
Sigh, I should write an article about all this some time. A few years ago I thought working on an installation framework and the binary compatibility problems is enough. The past year I've realized that we're also fighting against a culture problem - namely a culture which believes that open source software doesn't have to have binaries that run on multiple distributions and that compilation is acceptable for everyone, even people like my mom.
BWAHAHA! Try to tell that to the developers of the preferred Linux desktop environment, KDE, which is entirely written in C++. And I'm not even mentioning such non-working programs as Firefox and Inkscape.
You don't understand the issue here. Mike did not mean that C++ the language is unusable. He means that C++ binary compatibility is a hell. A C++ binary built on one distro can fail on the other distro because of things like C++ ABI incompatibilities and the way glibc handles symbol conflicts. See this for a technical introduction about the C++ ABI incompatibility problem, and this for more technical information about C++ problems, and this for technical information about problems in ELF.
Notice that I mentioned the word "technical" several times. So yes we know what we're talking about. If you don't believe us, feel free to proof read our technical documents and proof us wrong.
That says more about you than about developers. I am a developer too and I don't care whether I did something wrong or my dog did, I want the thing to be stable and I want it to be good.
Given the following open statements: p(x): x is a fact q(x): x is a truth
If x is a fact, then it is a truth, so p(x)->q(x). If x is a truth, then it is a fact (opinions are never always true since they vary from person to person), so q(x)->p(x). Therefore, p(x)<->q(x), so "fact" is equivalent to "truth".
Are you telling me that somehow "fact" and "truth" are not the same thing?
Uhm, no. I've used both GNOME and KDE, for months. The first few years of using Linux, I switch between them from time to time. But these days, I don't want to waste time configuring silly things. I want the interface to be clean and simple and to just work. Today, I use GNOME, with an occasional KDE app (running inside GNOME).
Re:KDE has superior apps, more energetic users &am
on
Torvalds Says 'Use KDE'
·
· Score: 4, Insightful
I'd say: who the hell cares? I don't care about this stupid GNOME-vs-KDE war that's artificially being kept alive by Slashdot. I use KDE apps in GNOME and vice-versa.
I didn't tell those people that she's a bot. I also used it in an MMORPG, where the average player age is 13 (and where ppl talk liek th1s omg lol/no1 heal plz/thx), and even those people could figure it out after a few sentences.
"This is a small app and she will talk with you - pretty well."
Dude, this is nonsense. I maintain my own modified version of Alice, and I have heavily modified and extended the responses to perform much better than Alice. But every single time, without exception, people figure out that it's a bot only after 2 or 3 sentences. Some even figure out after 1. And when they've figured it out, they try everything possible to damage it, like asking "do you want sex" and that kind of stuff.
Please explain then, I don't recall that Windows had less market share in 2001-2003. The anti-trust cases in the US didn't even make a dent in Windows's market share.
"Then you haven't checked hard enough. You can create a user-level rpm database and use that to install as a user to a user-defined location. See the --prefix option combine with --nodeps if you want to skip duplicating the system db."
I know about that, but it isn't useful in practice. The fatal problems are: 1. The most important of all: programs packaged in RPMs are not designed to be relocatable. Path names for data file lookup are hardcoded into the binary. You can install RPMs to your home folder but the programs won't even work! So what's the point? 2. Since you have to specify --nodeps, it defeats the point of the package manager? No dependency checking, no dependency resolution, no yum/apt support. 3. There is no easy and friendly graphical way to do this. Typing commands is unacceptable for people like my dad. This is simply unacceptable for desktop end users.
Point 1 is still the most important though. RPM'ed programs installed to the home folder simply don't work! In order for RPMs to be useful *in practice*, they must be installed as root.
"See the --noscripts option."
1. And you've just broken all the packages that rely on the preinstall and postinstall scripts to setup things. What's that I hear? You can review the scripts before you install? Well, you can do that with autopackages too! 2. There is no easy and friendly graphical way to do this. Typing commands is unacceptable for people like my dad. Even if there is, people like my dad are not capable of reviewing scripts.
Look at the post I replied to. "What if Adobe wants to distribute Photoshop CS on Linux?" And there currently is no alternative to Photoshop. If even mention Gimp, you'll be instantly flamed down by thousands of Slashdotters who say Gimp is nowhere near being able to take on Photoshop. Or how about things like Flash? Or the NVidia drivers? No good open source alternatives.
But that aside, even assuming that there *are* good open source alternatives, you'll still have a problem because the distro guys say "We don't care about inter-distro compatibility. Not our problem.". And this affect open source software too!
"Proprietary software is a security nightmare because if you can't see the sources then you can't be sure of what the binaries are doing."
I'm becoming more and more critical to statements like that. Autopackage is fully open source. Anybody can check autopackages for trojans. Yet some people still say that autopackages contain "arbitrary untrusted code" (never mind the fact that upstream developers aren't untrusted sources). You are contradicting yourselves.
Slashdot Mirror
Pronouncable to who? Try telling a Japanese, Chinese or Korean to pronounce it. America != world.
Intelligent design and evolution are not mutually exclusive. Even if life was once designed, evolution is still possible. Evolution means that, through genetic mutations, the best adapted individuals survive and pass their genes on to the next generation. When done often enough, the species can become dramatically different from the original. Genetic mutation is well-known and is a proven phenomenom.
Have you even TRIED Gnome? The menus are highly descriptive. gedit is listed as "Text Editor" and Sabayon is listed as "User Profile Editor". You're whining about an already solved issue.
That ain't right. The correct version should be:
Roses are #ff0000,
Violets are #0000ff.
If you h4x0r my code,
I'm going to fr4g j00!
I don't know where you have been the past 4 years, but font rendering isn't a problem now. Most likely you're either using an outdated distro which doesn't have a modern font system, or you don't have good fonts. Download the Bitstream Vera fonts or copy the Arial/Times New Roman fonts from your Windows partition and you're done.
I didn't say they're exactly the same, I said they're almost the same. Look at the layout.
As for your comment: you can. The GTK list box supports type-as-you-find since 2.6, and the list box in the file selector is focused by default so you can immediately begin typing. For a comparison, look at the MacOS X open file dialog - it also doesn't have a filename entry, just like the GTK one!
Is MacOS X friendly? You'd probably say yes. Is the MacOS X file selector friendly? You'd probably say yes. Well here's a surprise for you: the GTK file selector is almost identical to the MacOS X file selector. Then how come the GTK file selector is bad and the MacOS X file selector is good? Please, do explain this. The only reason I can come up with is that people these days like to bash Linux-based stuff and like to praise OS X, even when they've never used the latter.
"I haven't tried Gimp on Mac to know how out-of-place it's file selector is there." ......
Dude, the GTK file selector looks almost identical to the MacOS X file selector!
How come people complain at the GTK file selector, but praise the Mac file selector, when they're almost identical?
Besides, even that can be prevented by the OS. Fedora ships ExecShield (no idea why most other distros don't ship this) which makes the app crash (instead of letting an attacker take over) when a buffer overflow occurs.
"If the patch will break alot of situations, it won't get in."
The C++ ABI breakage broke many, many, many things, and got in. So I'm not convinced that this is a valid argument to reject it.
That side, from what I've seen: Michael Meek's patches are not rejected, but ignored. That's even worse than rejected. His fixes aren't only about some x% speedup, but also very low-level things like sanatizing ELF symbol conflict resolution. His patch wasn't reviewed, it was tested, it wasn't discussed - but ignored.
Do something about it? I already do. And that is exactly why I'm "bitching" - but I prefer to call it constructive criticism.
So basically what you're saying is that Autopackage is the wrong solution because incompatibilities between distros exist?
Autopackage aside, my entire point was that incompatibilities like that *shouldn't* exist. Too many people take the incompatibilities for granted, that is the problem. They think the incompatibilities is something natural, something that shouldn't/can't be fixed, something that is acceptable. In other words, a cultural problem, not a technical one. Its not that things cannot be fixed - they can, look at Michael Meek's glibc patches. Its that the community don't recognize the problems -> for example: Michael Meek's patches was rejected/ignored.
Unless the distro people and many people in the community recognize that the incompatibilities are unacceptable, things won't get fixed, and I'm afraid Linux will not succeed on the desktop until that happens. For instance, one of my classmates, who recently installed a Linux distro, complained about how hard it is to install software on Linux.
That isn't the point. Try running a C++ binary, which was compiled on distro X, on distro Y. If you're lucky, it works. If you're not lucky, it crashes for mysterious reasons. This is caused by C++ ABI breakages and ELF symbol conflicts.
See this for a technical introduction about the C++ ABI incompatibility problem, and this for more technical information about C++ problems, and this for technical information about problems in ELF.
Notice that I mentioned the word "technical" several times. So yes we know what we're talking about. If you don't believe us, feel free to proof read our technical documents and proof us wrong.
Anyway, that was just to prove you that the C++ binary problems exist and are real. Now to my following (also very important!) point:
Open source software DO need to be able to distribute cross-distribution binaries.
The need to distribute cross-distribution binaries isn't specific to proprietary software, as too many people seem to believe. Normal users don't, and shouldn't have to, care about compiling. It is their right - after all, they may have a legitimate reason to not learn it (too busy with work, for example). Therefore, the ability to easily install applications (without compiling!) is a good thing. But for that to happen, it must be possible to run a binary on multiple distributions! This implies that we cannot rely the distribution to take care of *all* the packaging. Its simply not possible, there is not enough manpower for that. I'm not saying that distributions should not package software, but it should be possible for the upstream (open source!) developers to distribution binaries (for their open source software!).
Notice how I keep emphasizing open source. Too many people associate "proprietary" with "evil" so I'm trying hard to point out that open source software needs to be easily installable too! Upstream open source software developers should be able to create binaries that run on multiple distributions!
Sigh, I should write an article about all this some time. A few years ago I thought working on an installation framework and the binary compatibility problems is enough. The past year I've realized that we're also fighting against a culture problem - namely a culture which believes that open source software doesn't have to have binaries that run on multiple distributions and that compilation is acceptable for everyone, even people like my mom.
You don't understand the issue here. Mike did not mean that C++ the language is unusable. He means that C++ binary compatibility is a hell. A C++ binary built on one distro can fail on the other distro because of things like C++ ABI incompatibilities and the way glibc handles symbol conflicts. See this for a technical introduction about the C++ ABI incompatibility problem, and this for more technical information about C++ problems, and this for technical information about problems in ELF.
Notice that I mentioned the word "technical" several times. So yes we know what we're talking about. If you don't believe us, feel free to proof read our technical documents and proof us wrong.
Good usability? Every time I read a Linux article I see tons of "+5 Insightful" posts claiming that Linux is nowhere near being ready for the desktop.
That says more about you than about developers. I am a developer too and I don't care whether I did something wrong or my dog did, I want the thing to be stable and I want it to be good.
Given the following open statements:
p(x): x is a fact
q(x): x is a truth
If x is a fact, then it is a truth, so p(x)->q(x).
If x is a truth, then it is a fact (opinions are never always true since they vary from person to person), so q(x)->p(x).
Therefore, p(x)<->q(x), so "fact" is equivalent to "truth".
Are you telling me that somehow "fact" and "truth" are not the same thing?
Uhm, no. I've used both GNOME and KDE, for months. The first few years of using Linux, I switch between them from time to time. But these days, I don't want to waste time configuring silly things. I want the interface to be clean and simple and to just work. Today, I use GNOME, with an occasional KDE app (running inside GNOME).
I'd say: who the hell cares? I don't care about this stupid GNOME-vs-KDE war that's artificially being kept alive by Slashdot. I use KDE apps in GNOME and vice-versa.
I didn't tell those people that she's a bot. I also used it in an MMORPG, where the average player age is 13 (and where ppl talk liek th1s omg lol /no1 heal plz /thx), and even those people could figure it out after a few sentences.
"This is a small app and she will talk with you - pretty well."
Dude, this is nonsense. I maintain my own modified version of Alice, and I have heavily modified and extended the responses to perform much better than Alice. But every single time, without exception, people figure out that it's a bot only after 2 or 3 sentences. Some even figure out after 1. And when they've figured it out, they try everything possible to damage it, like asking "do you want sex" and that kind of stuff.
Not Europe. Almost everybody here seem to use MSN. And I mean 99.9% market share!
Please explain then, I don't recall that Windows had less market share in 2001-2003. The anti-trust cases in the US didn't even make a dent in Windows's market share.
What campaign? Everybody's already using Windows. What do they possibly have to gain from a marketing campaign?
I know about that, but it isn't useful in practice. The fatal problems are:
1. The most important of all: programs packaged in RPMs are not designed to be relocatable. Path names for data file lookup are hardcoded into the binary. You can install RPMs to your home folder but the programs won't even work! So what's the point?
2. Since you have to specify --nodeps, it defeats the point of the package manager? No dependency checking, no dependency resolution, no yum/apt support.
3. There is no easy and friendly graphical way to do this. Typing commands is unacceptable for people like my dad. This is simply unacceptable for desktop end users.
Point 1 is still the most important though. RPM'ed programs installed to the home folder simply don't work! In order for RPMs to be useful *in practice*, they must be installed as root.
1. And you've just broken all the packages that rely on the preinstall and postinstall scripts to setup things. What's that I hear? You can review the scripts before you install? Well, you can do that with autopackages too!
2. There is no easy and friendly graphical way to do this. Typing commands is unacceptable for people like my dad. Even if there is, people like my dad are not capable of reviewing scripts.
"And you can't see why?"
Look at the post I replied to. "What if Adobe wants to distribute Photoshop CS on Linux?" And there currently is no alternative to Photoshop. If even mention Gimp, you'll be instantly flamed down by thousands of Slashdotters who say Gimp is nowhere near being able to take on Photoshop.
Or how about things like Flash? Or the NVidia drivers? No good open source alternatives.
But that aside, even assuming that there *are* good open source alternatives, you'll still have a problem because the distro guys say "We don't care about inter-distro compatibility. Not our problem.". And this affect open source software too!
"Proprietary software is a security nightmare because if you can't see the sources then you can't be sure of what the binaries are doing."
I'm becoming more and more critical to statements like that. Autopackage is fully open source. Anybody can check autopackages for trojans. Yet some people still say that autopackages contain "arbitrary untrusted code" (never mind the fact that upstream developers aren't untrusted sources). You are contradicting yourselves.