Quote:
Originally Posted by AdamWill
For a start, there's several things I can do on my Linux system that I can't on the Windows system in the house, principle among which is running Evolution, the best email client I've ever used.
|
What are these "several things" that you can only do on Linux? There is nothing that the most recent version of Evolution does that Outlook 2003 does not do.
I wish the Linux guys would get together and actually develop an innovative PIM that doesn't just imitate Outlook. Evolution is sad because its scheduling and todo data models are verbatim copies of Outlook. Take a look at Ecco Pro sometime (it runs under Wine, just don't use the phonebook, or it crashes) for a look at what could have been. Or for another viewpoint, try the old Lotus Agenda for DOS. Each of these apps can do serious, important things that Outlook doesn't do. Evolution is just a boring copy.
Quote:
| The outliner point is taken, but it's in a common genre - small apps that certain specialist groups need. I don't need one, and there's no other specialist apps I need that are lacking.... My typical everyday desktop consists of Evolution, Rhythmbox, Firefox, Totem, Gaim and Nautilus. |
It doesn't sound like your needs are very complicated at all, so I'm not surprised that Linux can meet them. Apart from your mail client/PIM, none of the programs you mention are productivity tools, and all have Windows analogs. Most adults generally have more sophisticated needs. They might not need an outliner, and they may not need a photo management package like iPhoto or Picasa, and they may not need DVD authoring software like iDVD or Movie Factory, and they may not need project management tools like Ecco, but there's a good chance that an average person will want at least one of those things. In all of those categories, there is no reasonably comparable Linux tool.
Quote:
| Apps like Totem, Rhythmbox, Goobox are beautiful, clean, simple and ridiculously easy to use. Goobox is one of my favourite apps I've come across lately - it's a CD player / ripper. You run it, it reads the CD in the drive, queries FreeDB and fills in the information. It displays it in a beautiful, clean uncluttered interface with simple playback options. You can then hit 'CD / extract tracks', pick a location, and it delivers a set of perfectly encoded Vorbis tracks in a sane directory format in that location through a nice efficient gstreamer pipeline. |
This is precisely my point. Linux developers spend a disproportionate amount of their time developing the "flashy" and "fun" programs, like music and video players. Does Linux really need another half dozen media players? Another two dozen window managers? Another three distributions? Who cares about any of these things? It needs basic productivity tools, which have enormous code bases and take years of hard work and testing to get out the door.
Quote:
"There needs to be a standard where commercial software vendors can release one binary that runs on any decent distribution with library versioning behavior at least on par with Windows 3.1."
There *is*. Build the app statically, like most OS X and Windows apps are built, build it against a common glibc version, and it'll work on practically anything. I mean, there already *are* commercial apps like this; Java, Realplayer, Firefox, Acrobat Reader and several other apps are available in statically compiled Linux archives that run on practically any Linux box. No compilation and no distro-specific packages required. I've always been a bit confused when I've come across this argument, because the thing is, it really does work already. People just seem to think it doesn't, for some odd reason. |
You're confused because you don't understand why libraries exist. The solution you propose -- static linking everything -- would not solve the problem and is not practical. Your comment that most Windows and OS X apps are statically linked is total bull. Why do you think there are so many DLLs floating around on Windows systems?
It is not possible to static link to all the system libraries a program uses, for the following reasons:
- as new versions of operating systems are released, the syntax of the system configuration files (or the registry, or whatever) invariably changes; if you have core system libraries statically linked into applications, they're stuck referencing the configuration files in the old syntax/location, which may no longer be valid
- static linking dramatically increases system memory requirements and lowers performance because OS page sharing is no longer possible -- just imagine if the entire Windows XP or Gnome operating environment, including all the core system libraries, had to be statically linked into every application! Even the simplest apps like notepad would have a memory footprint close to one hundred megabytes
- you cannot statically link in all possible device drivers in the world to every program; at some point there must be a dynamic interface to devices
- if you want old versions of software to benefit from improvements in usability and security as common environments evolve (e.g. if you want old programs to use the current file dialog in whatever new version of Gnome you're currently using), the only solution is shared, dynamically linked libraries.
There are many other reasons.
Linux needs a good, consistent solution for shared library versioning, at least on par what Windows 3.1 had, or it will remain unusable for many people and a massive, sometimes insurmountable, headache for commercial developers.
Quote:
| And wodgy, one more thing. Package management is great. It's the single most reliable and robust software delivery infrastructure yet designed. I have a single database I can query to discover virtually all software installed on my system, what software owns *any* given file, check versions, descriptions, interdependencies and so on and so forth. Who wouldn't want that? |
Package management is a massive kludge to get around library versioning problems and a workaround for incompatibilities between distributions. Yes, it is nice to have a common directory of programs installed, but that is not the core reason why package managers exist. You wouldn't need to have a system for tracking interdependencies if interdependencies weren't such a colossal problem to begin with! Look at OS X (or GNUstep for that matter). It's Unix, but with no need for any package managers (unless you want to run ported Unix and Linux apps that bring versioning hell with them) because Apple made a series of basic decisions about library versioning and implemented them. Likewise, using MSI on Windows is optional, not necessary. I can still run Windows 3.1 applications on Windows XP that were written with cheesy Visual Basic installers. One of my core apps, Ecco, hasn't been updated since 1997, yet it still runs fine on Windows XP. In Linux, you're lucky if a compiled binary of any complexity still runs on distributions released a year later, and you're divinely lucky if it runs on a different distribution at all.
In fact, the entire distribution system for Linux is just an ugly kludge. It doesn't make sense any more, but the Linux geeks can't see the forest for the trees. Distributions made sense in the early '90s, when no one had high speed Internet connections and it was only practical to distribute Linux with a variety of apps on CD. (I still have a Yggdrasil Linux CD distribution from 1992.) But now, all that distributions do is make up for the fact that there is no standardization of anything and no reasonable library versioning scheme. All the energy that distribution maintainers have to expend making sure that packages compile and work on their distribution is just wasted energy. If every distribution didn't put files in different places and use different versions of libraries with no basic versioning compatibility scheme, there would be no need for distribution maintainers to "maintain packages." Imagine if Microsoft or Apple had to "maintain packages" for every single third party application developed for every single different version of their OSes? It's ludicrous. And the solution isn't to offload the package maintenance chores onto the software developers -- the solution is to eliminate the need to do this entirely, as Apple did with OS X. It's stupid to argue that this couldn't be done with Linux as well. I'm not arguing for the death of multiple distributions. Having a variety of default configurations is fine, but the core "package maintenance" function that distributions perform is just a huge amount of wasted energy and a big, ugly kludge.
