This is because the transformers in TVs emit a high-pitched whine that only some people have the hearing range to hear. This is not exactly mysterious.
What is wrong with education? Are users so dumb that they are unable to learn?
This has nothing to do with it. Good design should absolutely minimize the amount a user needs to learn. You may enjoy learning things about computers, but most people do not. This is the absloute basics of user-friendly design.
Compression is built in to the deb package format.
Oh come on, now you are just being intentionally daft. Do you really think I was talking about compression there?
You fail to understand that good packaging is hard.
No, it is made hard. You can make installers and scripts and any fancy thing you want for Mac OS X too, but the important point is that very few apps actually need this.
What I was trying to say is that your average program that a user will actually want to install can simply be zipped up on the developers machine, and given to the user to unzip. They then get an icon which they can click to run the program. This is incredibly simple and convenient, both for the user and the programmer, and covers at least 90% of all applications. The rest is harder, but there are other mechanisms in place to handle those.
You example of Apache is completely atypical, since it is both a program of daunting complexity (unnecessary complexity, I'd say, but that's another topic entierly), and not a program a normal user would ever install. OS X has it pre-installed for you, if you want it. It is in every way a special case.
PS:
since by deleting the old bundle we just vaped the user's configuration.
No, configuration files are not stored inside the bundle.
As soon as two applications ship the same library, you are in the situation where you must upgrade both in order to make sure you are not vulnerable to a bug or security flaw in that library.
Sure, and in practice, this is not a problem. You're updating apps to fix security vulnerabilities all the time anyway. This will not signficantly change that, since dangerous vulnerabilities in these libraries are much more rare than vulnerabilities in the actual apps, and the number of apps that use a specific library is very small anyway. You keep using examples like zlib, which is a very common library and thus wouldn't be included in the app, but in the OS (As it is under Mac OS X - and what Windows programs do has nothing to do with this argument).
Uh, framework bundles are designed to contain multiple versions of libraries for exactly this reason. There's no need to "imagine doing this since KDE 1.0. And GNOME 1.0", as you would only need to have the versions that actually introduce incompabilities since you started packaging them as frameworks.
Furthermore, the reason that people keep breaking compatibility in libraries at the drop of a hat is because they know you'll have to recompile anyway. If you take that away, library developers will be forced to think a bit harder about whether they can afford to do this or not.
Saying there's no central control is a total cop-out - each project has central control over itself, no? Why shouldn't they be able to handle this themselves?
This is such basic knowledge for anyone who has installed Debian that I don't know how you could have missed it. Maybe you should have read the manual?
I did what most normal users would do - I put in an Ubuntu disc, answered some questions, and I got a working system. That part was very good. I never once had to worry about a "repository" or a "Synaptic".
The entire problem is one of familiarity...
Basically, "Users are too dumb! They need to learn!"
That is not how you get anyone to use your software.
I've wasted far too much of my time working around various software publisher's brain-dead ideas about how to package their software for Windows and the Mac OS.
In Mac OS X, I generally package my software by right-clicking the app bundle and selecting "Create Archive". If it is any harder to do than that, that's the fault of the OS.
Linux users in general seem to consider the fact that packaging software for their OS is much to difficult as some sort of natural law, that is to be worked around by complex technical and social solutions with repositories and other people packaging your software for you, instead of actually fixing the OS so that it's not such an incredible pain in the ass to distribute software for it.
Most apps only use the base install libraries. This would be stuff like Cocoa.framework and Carbon.framework. These are shipped with the OS.
Some apps use a custom framework or two. They include these in the app bundle. Chances are, any such library will exist in one or two app bundles on your system only. This is a minor waste of space for a huge increase in convenience. None of your arguments apply, since most apps just use the base libaries, and those libraries that are included in apps are used by very few apps.
The abundance of software already available from such repositories indicates that you are incorrect.
I am a fairly experienced computer user, who has used Linux for many years on my work computer. I have no idea where to find such a repository, nor any idea how to find out. If I don't know anything about this, how will anyone less experienced than me to this?
People are perfectly capable of entering the address of a web site into their web browser, clicking on a link to a program, downloading the target of the link, running it, and pressing next several times. Why are they incapable of entering the address of a package repository into Synaptic, clicking on the name of their program and pressing the big INSTALL button?
Because the web is a familiar environement, while things like "Synaptic" and "address of a package repository" are pretty much moonspeak.
That's ok, I will just use some other program that has already been packaged. But you don't need to learn the ins and outs of packaging for yourself: if your software is Free Software then someone else has probably done it already.
They haven't, because my software is not popular enough to attract one of the very, very rare people who have the actual skills to do this.
And nobody will ever use it, so what does it matter? The minute you start require people to re-configure repository lists, you've lost way over 90% of your audience already.
Not that I as a software developer would ever go through the bother to do it in the first place, either. If there was just one system, it would be feasible, but I don't even know how many different software distribution methods there are for Linux any longer, to speak nothing of the BSDs and so on, and I definitely have no idea how to set something up for all of them.
In practice, you're stuck with whatever your distro maker makes available.
On the linux box (I am going to choose Debian as I'm familiar with it). Fire up synaptic from the gnome menu. Search for barcode. Two results returned. Both of these programs I know to be free of trojans, compatable with my system & configured for it. To install, I double click.
Gee, I dunno, that sounds like using centralized software repositories to me.
Yes, let's take an example that has nothing to do with the discussion at hand, and is completely unrealistic! Nobody said that core libraries should not be dynamically linked. Mac OS X is the model for this discussion, and if you look at it, you'll find that every app doesn't contain its own copy of Cocoa.framework, as you say. It sure is easy to win arguments against strawmen, isn't it?
> This is not counting the various specialized libraries that individual GDE apps might use (like libbrainz).
These are the ones that should go in app bundles or some equivalent, because they are specialized and only used by one or two apps.
Both operating systems (unlike you) understand the importance of using dynamic libraries to save disk space.
If every file on your mac was statically compiled, we would be talking gigabytes, not megabytes.
Considering the fact that they're not, and nobody suggested they should be, I fail to see what on Earth this argument of yours is about. The point, if you had been paying attention, was exactly that OS X has a decent set of default dynamic libraries that you can assume are always available, and anything above and beyond that is fairly rare, and therefore can be included in the app bundle.
You only find it totally hilarious because you fail to understand the difference between making it convenient for users to use software from a central source and forcing users to use software from a central source.
Yeah! Everybody can just compile the software that isn't in repositories from source! Especially software with external dependencies that aren't in repositories, or don't have a new enough version in repositories.
Try running that one by your family and see how they like it.
I also find it totally hilarious how Linux users are now advocating a completely centralized model of software distribution. Freedom of choice! As long as you only ever choose things approved by your distro maker!
Remember, pointing out that Slashdot routinely publishes crackpot luddite articles is -1, Offtopic!
This is because the transformers in TVs emit a high-pitched whine that only some people have the hearing range to hear. This is not exactly mysterious.
what
What is wrong with education? Are users so dumb that they are unable to learn?
This has nothing to do with it. Good design should absolutely minimize the amount a user needs to learn. You may enjoy learning things about computers, but most people do not. This is the absloute basics of user-friendly design.
Compression is built in to the deb package format.
Oh come on, now you are just being intentionally daft. Do you really think I was talking about compression there?
You fail to understand that good packaging is hard.
No, it is made hard. You can make installers and scripts and any fancy thing you want for Mac OS X too, but the important point is that very few apps actually need this.
What I was trying to say is that your average program that a user will actually want to install can simply be zipped up on the developers machine, and given to the user to unzip. They then get an icon which they can click to run the program. This is incredibly simple and convenient, both for the user and the programmer, and covers at least 90% of all applications. The rest is harder, but there are other mechanisms in place to handle those.
You example of Apache is completely atypical, since it is both a program of daunting complexity (unnecessary complexity, I'd say, but that's another topic entierly), and not a program a normal user would ever install. OS X has it pre-installed for you, if you want it. It is in every way a special case.
PS:
since by deleting the old bundle we just vaped the user's configuration.
No, configuration files are not stored inside the bundle.
As soon as two applications ship the same library, you are in the situation where you must upgrade both in order to make sure you are not vulnerable to a bug or security flaw in that library.
Sure, and in practice, this is not a problem. You're updating apps to fix security vulnerabilities all the time anyway. This will not signficantly change that, since dangerous vulnerabilities in these libraries are much more rare than vulnerabilities in the actual apps, and the number of apps that use a specific library is very small anyway. You keep using examples like zlib, which is a very common library and thus wouldn't be included in the app, but in the OS (As it is under Mac OS X - and what Windows programs do has nothing to do with this argument).
Uh, framework bundles are designed to contain multiple versions of libraries for exactly this reason. There's no need to "imagine doing this since KDE 1.0. And GNOME 1.0", as you would only need to have the versions that actually introduce incompabilities since you started packaging them as frameworks.
Furthermore, the reason that people keep breaking compatibility in libraries at the drop of a hat is because they know you'll have to recompile anyway. If you take that away, library developers will be forced to think a bit harder about whether they can afford to do this or not.
Saying there's no central control is a total cop-out - each project has central control over itself, no? Why shouldn't they be able to handle this themselves?
This is such basic knowledge for anyone who has installed Debian that I don't know how you could have missed it. Maybe you should have read the manual?
I did what most normal users would do - I put in an Ubuntu disc, answered some questions, and I got a working system. That part was very good. I never once had to worry about a "repository" or a "Synaptic".
The entire problem is one of familiarity...
Basically, "Users are too dumb! They need to learn!"
That is not how you get anyone to use your software.
I've wasted far too much of my time working around various software publisher's brain-dead ideas about how to package their software for Windows and the Mac OS.
In Mac OS X, I generally package my software by right-clicking the app bundle and selecting "Create Archive". If it is any harder to do than that, that's the fault of the OS.
Linux users in general seem to consider the fact that packaging software for their OS is much to difficult as some sort of natural law, that is to be worked around by complex technical and social solutions with repositories and other people packaging your software for you, instead of actually fixing the OS so that it's not such an incredible pain in the ass to distribute software for it.
You seem a bit slow to catch on here.
Most apps only use the base install libraries. This would be stuff like Cocoa.framework and Carbon.framework. These are shipped with the OS.
Some apps use a custom framework or two. They include these in the app bundle. Chances are, any such library will exist in one or two app bundles on your system only. This is a minor waste of space for a huge increase in convenience. None of your arguments apply, since most apps just use the base libaries, and those libraries that are included in apps are used by very few apps.
The abundance of software already available from such repositories indicates that you are incorrect.
I am a fairly experienced computer user, who has used Linux for many years on my work computer. I have no idea where to find such a repository, nor any idea how to find out. If I don't know anything about this, how will anyone less experienced than me to this?
People are perfectly capable of entering the address of a web site into their web browser, clicking on a link to a program, downloading the target of the link, running it, and pressing next several times. Why are they incapable of entering the address of a package repository into Synaptic, clicking on the name of their program and pressing the big INSTALL button?
Because the web is a familiar environement, while things like "Synaptic" and "address of a package repository" are pretty much moonspeak.
That's ok, I will just use some other program that has already been packaged. But you don't need to learn the ins and outs of packaging for yourself: if your software is Free Software then someone else has probably done it already.
They haven't, because my software is not popular enough to attract one of the very, very rare people who have the actual skills to do this.
But why are you assuming they would be included in every app? That would be stupid, and you would obviously not do it the stupid way.
Yeees... and?
And nobody will ever use it, so what does it matter? The minute you start require people to re-configure repository lists, you've lost way over 90% of your audience already.
Not that I as a software developer would ever go through the bother to do it in the first place, either. If there was just one system, it would be feasible, but I don't even know how many different software distribution methods there are for Linux any longer, to speak nothing of the BSDs and so on, and I definitely have no idea how to set something up for all of them.
In practice, you're stuck with whatever your distro maker makes available.
Except nobody said that libraries that every app uses should be included in each app.
On the linux box (I am going to choose Debian as I'm familiar with it). Fire up synaptic from the gnome menu. Search for barcode. Two results returned. Both of these programs I know to be free of trojans, compatable with my system & configured for it. To install, I double click.
Gee, I dunno, that sounds like using centralized software repositories to me.
Yes, let's take an example that has nothing to do with the discussion at hand, and is completely unrealistic! Nobody said that core libraries should not be dynamically linked. Mac OS X is the model for this discussion, and if you look at it, you'll find that every app doesn't contain its own copy of Cocoa.framework, as you say. It sure is easy to win arguments against strawmen, isn't it?
> This is not counting the various specialized libraries that individual GDE apps might use (like libbrainz).
These are the ones that should go in app bundles or some equivalent, because they are specialized and only used by one or two apps.
Both operating systems (unlike you) understand the importance of using dynamic libraries to save disk space.
If every file on your mac was statically compiled, we would be talking gigabytes, not megabytes.
Considering the fact that they're not, and nobody suggested they should be, I fail to see what on Earth this argument of yours is about. The point, if you had been paying attention, was exactly that OS X has a decent set of default dynamic libraries that you can assume are always available, and anything above and beyond that is fairly rare, and therefore can be included in the app bundle.
You only find it totally hilarious because you fail to understand the difference between making it convenient for users to use software from a central source and forcing users to use software from a central source.
Yeah! Everybody can just compile the software that isn't in repositories from source! Especially software with external dependencies that aren't in repositories, or don't have a new enough version in repositories.
Try running that one by your family and see how they like it.
My god! That will use up megabytes of disk space!
I also find it totally hilarious how Linux users are now advocating a completely centralized model of software distribution. Freedom of choice! As long as you only ever choose things approved by your distro maker!
Now what I don't understand is...
Yes, the fact that you don't understand this is pretty much the point that the grandparent poster was making. Congratulations.
I'm pretty sure neither you nor I can imagine that, what with never having seen or held one of them.
Precompiled binaries is what Windows users use because Windows supports them, unlike Linux.
Scientologists are also very fond of yelling about religious oppression as soon as things go badly for them.
Religion is not, and should never be, a shield to hide your misdeeds behind.
Slashdot: News for luddites, stuff that scares us.
Stop trying to ruin the Luddite article slant with actual facts!
Why do you (and about half the other commenters so far) naturally assume that the technology is that simple?
Welcome to Slashdot, where every teenager in his basement is smarter than an army of engineers and scientists.
Where would the Fantasy genre be if Tolkien had copyrighted most of his "ideas" instead of only his books?
It would either be far, far better, or non-existent. Either seems a step up from the current situation to me.