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.
This is true, but there is in this case a trade off between being secure, and being easy to learn. Although I don't think it's much of a trade off, because I don't think any user would find it hard to use Synaptic. Choose the software you want to install from the list, click install, wait for the package to be installed... easy!
Oh come on, now you are just being intentionally daft. Do you really think I was talking about compression there?
I assume that when you right click a file and choose 'make archive' it fires up Stuffit and makes an archive.
No, [packaging] 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.
As I stated, packaging most programs for Debian is similarly very straight-forward. I'm sure you could write a script on OS X to do all the things I mentioned, but then you wouldn't be using the application bundle system any more, would you--which is what we are comparing to Debian in the first place. Besides, any script a random software publisher came up with would be unlikely to be as robust as the tools that Debian provides for packages to use, which have matured over many years of use.
No, configuration files are not stored inside the bundle.
So removing the bundle wouldn't completley remove the software from the user's machine. By contrast, removing a Debian package leaves the configuration in place, and tracked by the packaging system (in case the package was removed by accident, for example) until the package is purged.
It's only "not a problem" until you are screwed by an app shipping an out-of-date private copy of a library. The fact is that your system is potentially vulnerable as soon as you have one application present that ships a private copies of a library. This is not the case on Debian, because there is a single copy of each library; when a flaw is discovered, there is only one package to upgrade to ensure that you are safe.
My png and zlib examples were to illustrate that vendors often *don't* bother to issue updates rolling in the latest versions of these libraries
I don't know about there being less choice. The last release of Debian contained 15,197 packages; unstable currently contains 17,550!
Obviously you do have to trust the Debian Developers to review the packages that they upload; this job is possible because packages may only enter Debian if they are accompanied by the complete source code of the package.
This task is also performed by the ftpmasters, who are a small group that administrate the archive itself; they ensure that the packages uploaded comply with the Debian Free Software Guidelines, and that they aren't malware, and so on.
About the security of the keys; the keys for the verification live on the system itself, so you can't redirect a query to your own site as you described. The system is described pretty well in section 7.4 of the Securing Debian Manual; but basically when a package is downloaded, it is checked against the checksums present in the repository it was downloaded from; each repository can provide a PGP key that is used to ensure that these checksums are valid.
When freshly installed, a system will already have the Debian Archive signing key installed. If you broke into ftp.uk.debian.org and replaced the package of Firefox with your own Firefox+Gator, and fudged the checksums in the Packages and Release files, the Release file would fail to verify against the Debian Archive signing key already present on the user's system.
Every point you raise (except for the wget one) applies as equally to any package download site you care to name.
But I'm not talking about a package download site; I want the ease-of-use and security afforded by Apt, which is impervious to these attacks:
Since only Debian Developers are able to upload packages, a malicious software vendor would have a hard time getting their package into the archive in the first place.
Since Apt verifies all downloaded packages against the repository's PGP key, an attacker is unable to trick me into downloading their software by breaking into a Debian mirror or play with DNS to redirect me to their site.
Using Apt isn't just about the ease of upgrading--it is also a security thing. I can trust that there are no viruses, trojans, spyware or other malware in Debian's archive; I can't make the same assumption if I download software from a vendor's web site directly.
VersionTracker has a product to sell and a reputation to maintain. They are a trusted site, just like the package download sites.
VT has admins that are capable of removing listings. Also, VersionTracker has product ratings and a comment system. If a product turns out to be spyware or something, someone will end up reporting it. If it looks like someone is astroturfing their own product under different usernames, you can send a report in to the admins.
So one must just hope that such problems are reported and fixed before one has the chance to download the software? Besides, if the price was right, who is to say that the company behind VersionTracker wouldn't deliberatly point users at malware, or take just that little bit longer to remove the bad software from their listing?
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".
And if you wanted to find out how to install additional software, you would have seen explanations and a step by step guide in the manual.
Basically, "Users are too dumb! They need to learn!"
What is wrong with education? Are users so dumb that they are unable to learn?
I note that you haven't bothered to address the point I raised, that users somehow managed to learn how to use the web to download new software for their PCs in the first place, often encountering setbacks such as viruses, trojans, spyware and the need to reinstall their PCs upon the way; not to mention that they learned how to use a PC or perform $any_other_task in the first place. Or were you born with this knowledge built in?
As a Mac user, you of all people should understand the problem with "GNU/Linux should just duplicate $what_i_am_used_to exactly".
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.
Compression is built in to the deb package format.
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 fail to understand that good packaging is hard.
It's as easy to make a bundle for a random piece of end-user desktop software as it is to make a Debian package of that software; the difference is that the Debian packages can do so much more. Show me how you can make a bundle of, say, Apache that will, when installed, automatically configure and start the server. When upgraded (since you can't apt-get upgrade, we'll overlook the tedious browse/download/mount/delete old bundle/copy new bundle process), your bundle should automatically upgrade the user's configuration, taking into account the (possibly extensive) modifications the user has made. Oh, I guess we can't forget the tedious process, since by deleting the old bundle we just vaped the user's configuration. Oh well. Along with the newly upgraded^Wfreshly-installed Apache, we also want PHP. How would you make a bundle that, when installed, automatically updates Apache's configuration so that the PHP handler is invoked for files ending with.php?
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.
Although the wasted storage space is a disadvantage, we are talking about having to upgrade every application when there's a bug or vulnerability in a library that these applications all duplicate.
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.
This sentence contradicts itself. If this argument does not apply then no applications exist that ship their own copies of libraries. 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. That's if the software publisher even bothers to update their own copy--most vendors of software for Windows never bothered to issue advisories relating to the libpng flaws of last (or the previous?) year. Microsoft released a scanning tool that could be ported to Bourne shell thus:
find / -name libpng.dll && echo 'Copies of libpng were detected on your system. Please check with the person you got each copy from to make sure they have not given you a vulnerable version of the library.'
I don't even want to *think* about how many vulnerable copies of zlib there are statically linked throughout a typical Windows system.
debian/ubuntu systems: 1) Google all over the Internet to find solution for your problem 2) Wade through the pages of flamewars on which competing software is better (VI or Emacs, only god knows for sure)
Let's just count these as "find some software you want to install", shall we? They are common steps for all three platforms.
3) Call grandson to see how to enter "app-get install Vimacs" 4) type "apt-get install Vimacs"
5) Call grandson to ask where the icon is to run Vimacs 6) Be confused as to what grandson is talking about, still wonder where the icon is, all the rest of the applications have one?
Policy states that all applications should register in the standard system-wide menu. Any packages that do not do so are buggy.
The Debian approach basically *does* boil down to 'install the foobar package'.
But it's not Free Software, and it costs money (in fact it seems to be a subscription service, yuck!), and it won't upgrade apps that aren't listed on the site, and it won't touch the applications that come with the Mac OS. It's not even close.
Oh, the irony of a Mac OS user complaining about programs that use non-standard GUI toolkits! Mac users lost the right to complain about this when Mac OS X shipped.:)
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?
Pull the other one; it has got bells on.
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?
Because the web is a familiar environement, while things like "Synaptic" and "address of a package repository" are pretty much moonspeak.
The entire problem is one of familiarity. The user who is familiar with downloading an installer from a web site will not be familiar with the use of Apt; but terms such as "web site address", "download", "installer", "double-click", "license agreement", "spyware", "trojan horse", "virus", "malware", "crash", "uninstall" and "reinstall" were also once so much moonspeak. Not to mention "web browser", "email", "mouse", "computer", "internet", "icon", "chair", "car", "money", "food", "house" and so on ad birth.
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 anyone who wants to use your software can file a bug requesting that it be packaged. That automatically ensures that your software is available to Debian users, and the users of all Debian-derived distributions. That someone can even be you!
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. Having used Debian for some time, I believe that it is the role of the software publisher to just make their software available; those who know how to package should create excellent packages that install and work, and keep on working.
If an application depends on a library that is not shipped by Apple, and is not included with the application, then where does it load the library from?
On Version Tracker, I get 48 results for "barcode." The top two have been downloaded more that 10,000 times each. I'd say that's free of trojans...
Tens of thousands of systems are inflicted with Gator, Comet Cursor, Sony's root kit, and so on. I guess that means that these pieces of software are beneficial?
Besides, how do you know that an attacker hasn't put their own trojaned copy of the software on the publisher's web site? How do you know that an attacker hasn't subverted the software publisher's DNS server and isn't redirecting requsts for the software to their own modified copy? How do you know the software has really been downloaded tens of thousands of times, and the VersionTracker web site isn't lying to you in order to get you to download the malicious software, or that the tens of thousands of downloads weren't just triggered by wget in a for loop in order to boost the software's popularity on this site?
Which can bring in new versions of a library, which in turn brings in new versions of another application, which may be broken in some way (like any app can be).
You obviously have no idea what you are talking about.
And nobody will ever use it, so what does it matter?
The abundance of software already available from such repositories indicates that you are incorrect.
The minute you start require people to re-configure repository lists, you've lost way over 90% of your audience already.
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?
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.
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.
In practice, you're stuck with whatever your distro maker makes available.
So does Windows, though. Neither Windows nor Linux uses kernel audio mixing -- they rely on hardware mixing instead. All somewhat modern sound cards have several PCM subchannels that operating systems use in order to play several sounds simultaneously, and, yes, it is perfectly supported by Linux. Last I tried (admittedly, that was some time ago, but I can't remember just how long), using Windows with a single-channel sound card meant that I could only play one sound at a time.
Must have been over 6-7 years ago then, since Windows has had automatic software mixing since Windows 2000. These days however, the point is irrelevant since ALSA has had software mixing enabled by default since version 1.0.9.
ALSA's software mixing has actually been around for a few years, but because it was not turned on by default, hundreds of web pages sprung up to provide faulty advice on how to enable it, so until recently it was quite hard to get working properly.
Freedom of choice! As long as you only ever choose things approved by your distro maker!
Which is complete nonsense. Anyone can set up an apt repository and use a web server to make it available to anyone on the Internet; and anyone can add third party apt sources to their system to enable the use of such software.
Slashdot Mirror
It's only "not a problem" until you are screwed by an app shipping an out-of-date private copy of a library. The fact is that your system is potentially vulnerable as soon as you have one application present that ships a private copies of a library. This is not the case on Debian, because there is a single copy of each library; when a flaw is discovered, there is only one package to upgrade to ensure that you are safe.
My png and zlib examples were to illustrate that vendors often *don't* bother to issue updates rolling in the latest versions of these libraries
I wish that driver was in the kernel. Well, I wish the rewrite that makes it not shit was finished and therefore in the kernel.
Like LSH? :)
I don't know about there being less choice. The last release of Debian contained 15,197 packages; unstable currently contains 17,550!
Obviously you do have to trust the Debian Developers to review the packages that they upload; this job is possible because packages may only enter Debian if they are accompanied by the complete source code of the package.
This task is also performed by the ftpmasters, who are a small group that administrate the archive itself; they ensure that the packages uploaded comply with the Debian Free Software Guidelines, and that they aren't malware, and so on.
About the security of the keys; the keys for the verification live on the system itself, so you can't redirect a query to your own site as you described. The system is described pretty well in section 7.4 of the Securing Debian Manual; but basically when a package is downloaded, it is checked against the checksums present in the repository it was downloaded from; each repository can provide a PGP key that is used to ensure that these checksums are valid.
When freshly installed, a system will already have the Debian Archive signing key installed. If you broke into ftp.uk.debian.org and replaced the package of Firefox with your own Firefox+Gator, and fudged the checksums in the Packages and Release files, the Release file would fail to verify against the Debian Archive signing key already present on the user's system.
Using Apt isn't just about the ease of upgrading--it is also a security thing. I can trust that there are no viruses, trojans, spyware or other malware in Debian's archive; I can't make the same assumption if I download software from a vendor's web site directly.
So one must just hope that such problems are reported and fixed before one has the chance to download the software? Besides, if the price was right, who is to say that the company behind VersionTracker wouldn't deliberatly point users at malware, or take just that little bit longer to remove the bad software from their listing?
I note that you haven't bothered to address the point I raised, that users somehow managed to learn how to use the web to download new software for their PCs in the first place, often encountering setbacks such as viruses, trojans, spyware and the need to reinstall their PCs upon the way; not to mention that they learned how to use a PC or perform $any_other_task in the first place. Or were you born with this knowledge built in?
As a Mac user, you of all people should understand the problem with "GNU/Linux should just duplicate $what_i_am_used_to exactly".Compression is built in to the deb package format.You fail to understand that good packaging is hard.
It's as easy to make a bundle for a random piece of end-user desktop software as it is to make a Debian package of that software; the difference is that the Debian packages can do so much more. Show me how you can make a bundle of, say, Apache that will, when installed, automatically configure and start the server. When upgraded (since you can't apt-get upgrade, we'll overlook the tedious browse/download/mount/delete old bundle/copy new bundle process), your bundle should automatically upgrade the user's configuration, taking into account the (possibly extensive) modifications the user has made. Oh, I guess we can't forget the tedious process, since by deleting the old bundle we just vaped the user's configuration. Oh well. Along with the newly upgraded^Wfreshly-installed Apache, we also want PHP. How would you make a bundle that, when installed, automatically updates Apache's configuration so that the PHP handler is invoked for files ending with
The Debian approach basically *does* boil down to 'install the foobar package'.
Doesn't upgrade all programs on the machine though.
But it's not Free Software, and it costs money (in fact it seems to be a subscription service, yuck!), and it won't upgrade apps that aren't listed on the site, and it won't touch the applications that come with the Mac OS. It's not even close.
So basically, there is no equivalent.
Why is this? Do applications expect to be able to write to their own directories? :/
Oh, the irony of a Mac OS user complaining about programs that use non-standard GUI toolkits! Mac users lost the right to complain about this when Mac OS X shipped. :)
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?The entire problem is one of familiarity. The user who is familiar with downloading an installer from a web site will not be familiar with the use of Apt; but terms such as "web site address", "download", "installer", "double-click", "license agreement", "spyware", "trojan horse", "virus", "malware", "crash", "uninstall" and "reinstall" were also once so much moonspeak. Not to mention "web browser", "email", "mouse", "computer", "internet", "icon", "chair", "car", "money", "food", "house" and so on ad birth.But anyone who wants to use your software can file a bug requesting that it be packaged. That automatically ensures that your software is available to Debian users, and the users of all Debian-derived distributions. That someone can even be you!
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. Having used Debian for some time, I believe that it is the role of the software publisher to just make their software available; those who know how to package should create excellent packages that install and work, and keep on working.
If an application depends on a library that is not shipped by Apple, and is not included with the application, then where does it load the library from?
Tens of thousands of systems are inflicted with Gator, Comet Cursor, Sony's root kit, and so on. I guess that means that these pieces of software are beneficial?
Besides, how do you know that an attacker hasn't put their own trojaned copy of the software on the publisher's web site? How do you know that an attacker hasn't subverted the software publisher's DNS server and isn't redirecting requsts for the software to their own modified copy? How do you know the software has really been downloaded tens of thousands of times, and the VersionTracker web site isn't lying to you in order to get you to download the malicious software, or that the tens of thousands of downloads weren't just triggered by wget in a for loop in order to boost the software's popularity on this site?
Then we're back to the original point: if there's a bug in the library that needs fixing, every app that contains it needs to be upgraded.
It's like being back in the dark ages, where everything was statically linked.
ALSA's software mixing has actually been around for a few years, but because it was not turned on by default, hundreds of web pages sprung up to provide faulty advice on how to enable it, so until recently it was quite hard to get working properly.
If they're not part of the base system, then they have to be included in each app.
I hope the Firefox of tomorrow won't have its own garish skinning system and use MDI, then. :)