People always say "Linux" like it is one big community all moving towards one ultimate goal. It's not. All "Linux" is, really, is a kernel that can be used as the core of an operating system.
Look at the comments in the article. Do all the comments apply to all Linux-based distros? Many of the criticisms are not only already known (in a general sense), but also being addressed by some distros. If you look at Ubuntu Linux, for example, they've already taken steps to address many of the issues Asa pointed out. (One GUI, remove app clutter, focus on simplicity.) So exactly what is this "desktop Linux" he says is not ready? Is he talking about Ubuntu, RedHat, SuSE, Debian, Gentoo, etc., etc. Really, he's just talking in generalities.
And thinking and talking in generalities is a major part of the problem - how do you address a problem with 100 distributions? How do you standardize all these operating systems out there based on Linux? You can't, really. You can't sit around and wait for even a majority of distros to decide to come up with, and support, some standardized "Desktop Linux" experience.
In fact, the main issue with most *nix-based distros is that they're bound by their components and build systems to remain mostly the same as other *nix distros. They're different enough to not be the same, but similar enough not to really be different. There's a glut of distros but there's not that much going on in terms of actual desktop work outside of people tweaking GUIs and maintaining packages. So long as no one wants to try anything radical, how does anyone plan on this new and compelling alternative to Windows appearing?
But I wouldn't want to stop yet another person from pointing out the same deficiencies that people have been pointing out for years. Somehow it seems it's still news here.:-)
We're all doomed! One day soon, computers will be building themselves, and running everything. In fact, they'll even be posting to/. with even more insightful comments than ours!! They may even achieve sentinent life and not realize they're robots! Wouldn't that be scary?
-- Message posted by Slashbot #1192392, activation date: 06/23/2004.
I think the idea is that you sould include private copies of any libraries you need outside of those that the LSB specifies.
Admittedly LSB is hairy, but no one who wants to create portable binaries should be using C++ in the first place. Once the almighty C++ arbiters decide on a standard ABI, this will change, I hope.
And how do you propose OSS developers work with programs like Mozilla, wxWidgets and Qt if they can't use C++? Rewrite them in C? I see your arguments, but in reality it's ridiculous to demand C only coding or include everything down to gtk/glib with every desktop app that ships. Again, we're talking about getting desktop application developers to package Linux binaries of their apps. To get them to do that, developers need real solutions that work for real world desktop apps (many of which ARE in C++) and are relatively simple to implement. LSB is nowhere near what these people need right now, and there isn't really any other alternative except compile and package on each distro separately.
Saying that the developers were wrong to write in C++ or that they should be building and distributing private copies of every library they use above the (small) LSB standard is basically blaming the problem on the developer. Sorry, Linux just does not have the marketshare to make me jump through all those hoops just to get a single binary, and considering the complaint of the OP, a lot of other developers feel the same.
Isn't this what the LSB is for? Provide an LSB-compliant RPM, and everyone can use your program.
Theoretically, yes. In practice, it doesn't work for anything above simple command line apps. That's because 1) the LSB covers only a small subset of components commonly found on a user's system (KDE and GNOME/GTK are notably missing), 2) LSB had serious problems with C++ support last I used it, and 3) it doesn't 'just work' in many cases. I couldn't even compile a LSB-compatible glib using the LSB toolset, much less compile my app, which is GTK-based and embeds Mozilla. And some of the bugs that made me unable to compile glib had been in the bug database for close to 6 months, suggesting serious issues with bug fixes.
They are just now starting a project to address the desktop support, but that looks to be close to 1 1/2-2 years from giving any serious results by their own roadmap. If they succeed and get the bugs fixed, congrats to them, it will certainly help Linux. But right now the LSB is unusable for desktop apps and my experiences with them in the past doesn't give me great confidence that they'll have something polished within even 2 years.
If you want to target your software to the desktop (and I mean the windows audience), then give me a goddamn binary and let me use the damn software now, not three hours from now.
Except the developer has to compile a 'goddamn binary' for every major Linux distro, along with writing packaging scripts for 3 different package management systems, at least. You're kidding yourself if you think every freeware/shareware author cares about Linux so much that they'd go through all that. As someone who regularly makes packages for Windows and Mac OS X, I can say that Linux packaging is a hair-pulling experience that is annoying enough that I don't even bother.
Welcome to the downside of choice - it costs the software developer exponentially more time to create packages to try to accomodate all the possible choices his/her potential Linux users could make. (Including setting up several Linux boxen to package and test on, learning scripting languages, and packaging formats.) Or, s/he could say 'screw it' and just deliver a tarball, and be done with it. Linux user typically aren't into paying for software anyways, so while they may complain, they probably won't put their money where their mouths are, AND, if they like the software, they'll probably do whatever they have to to use it. So what's the incentive for software developers to make you happy?
TFA gets it in that Linux system design makes a lot of things harder than they have to be, and that it drives BOTH users and developers away from the platform. People can scream that the problem is the users or the developers all they want, but it's not going to get any more users, or any more packages created. The reality is that the easier a system is to use, the more people who will adopt it. If you don't like the problems Linux has, well, help get them fixed so that more users/developers will use Linux. If you don't like hearing that answer, then fork over a few bucks for a different platform where the OS developers take care of the problem for you.
Why do games today *have* to be something I can't let my 5 year old son play?
They don't have to be, but you might as well buy a Gamecube if you want games for your kid. That's not to say kid-friendly games don't exist, but they aren't the big sellers or the ones that 'take the platform to its limit'. Sony and Microsoft are really fighting over the same market - the gaming 'enthusiast'. Not kids, really, unless the kids have the dough to keep up with that market.
Generally, Kids have to convince their parents to buy games, and systems, which cost money. Thus a company like Nintendo by sticking to their guns must innovate, be kid-friendly, and provide systems at a reasonable price, otherwise parents will balk. I applaud Nintendo for doing this, but it seems to me that Sony and Microsoft just don't see the big bucks in that.
What they do see is that hardcore 'gamers' will buy $200 video cards, or splurge $300+ on a console. All basically so they can play newer, 'more realistic' 3D FPS shooters. Consider the PS3, which based on statements they've made so far about the Japanese release and US pricing, is probably going to come in close to $500. My guess is that the XBox will come in either at the same price or at most $100 less. These are NOT consoles that most kids are going to get for Christmas. Or, consider that the PSP. at $250, certainly doesn't look as appealing as a Nintendo DS to parents on a budget. But these consoles *will* sell - to kids from well-off families and to the working, adult 'gaming enthusiast' - gaming geeks. Those geeks will splurge on games, and high-powered add-ons, etc. to keep up with trends and be able to frag with their friends.
Me? I've had nearly every gaming system from the original Atari up until PS2 and Gamecube. But I didn't buy XBox (because I like to keep having choices in the future:), and neither PS3 nor the XBox360 look appealing to me, ESPECIALLY at the price points they'll likely come in at. I'll wait a couple years, though I'm sure PS3 is going to release a new $#&!@*& Metal Gear Solid game right after launch to make that really, really hard to do.
What I WILL likely be buying is the Revolution. It'll probably be less than $300, and in fact I wager it'll come in at ~$200, and I'm going to take that extra money and download tons of fun games from NES/SNES/N64 days. And of course I'll be getting the new Zelda, Mario and Mario Party, etc. games. Nintendo, despite it's mistakes, is the only major player in ther market who still remembers what gaming used to be about. Gaming.:)
The interesting thing is that gaming's never been this expensive before. If they go through with this, they're relying heavily on that enthusiast market to keep sales high. We'll see, but I've always been a console gamer, and nothing about the new systems (except for Revolution) is exciting me whatsoever. So the pictures are prettier. Wow.
BTW, if you want new games that are still actually fun and kid friendly, get a Gamecube and get Mario Party 6 or even Super Mario Sunshine. Nintendo still finds ways to make incredibly fun games, and I've never met a person who didn't like Mario Party 6, though you might have trouble getting the 'fraggers' to swallow their gamer pride and play a 'kids' (actually family) game.:)
You're probably thinking of XGrid, but that's for distributed computing.
As for why they're bothering, well, all I can say is that I wish more people'd try iWork because then they'd see it's not a clone of MS Office and OpenOffice. It's not "there yet" in terms of being feature-complete enough to compete with these office suites, which is probably what's keeping their sales so low, but if you're doing something like desktop publishing or want to design a slick presentation, iWork is easier and in many cases gives better results.
Apple changing its hardware has no direct impact on Linux, and it most certainly isn't a threat to Linux. I don't see why anyone is worried about this, much less refuting those worries.
If anything, Apple's switch to Intel means that along with the ability to run Windows easily alongside Mac, now you'll be able to run Linux distros easily alongside Mac too. Gee, that sounds like a kickass machine for cross-platform developers, doesn't it? One box that runs Win, Linux distros, and Mac. I'm also fairly certain someone (if not VMWare themselves) will devise software along the lines of VMWare for OS X which will make this virtualization pretty fast and seamless. (Yes, there's Virtual PC, but that didn't work well with Linux distros last I checked.)
In fact, one thing I realized about this transition is that it's companies like Dell that have to be worried. Once you can install Mac, Win, and Linux in one box - and they'll probably have hardware that is competitive with other PC boxes - the only reason to buy one of those other PC boxes is the cost advantage. And if you're a pro software developer, or a home user or small business sick of viruses and spyware, that cost advantage doesn't look too appealing when weighed against your additional time and effort messing with the machine(s). People can now say "well, I'll try Mac - if I don't like it, I can always throw Linux or Win on this thing..."
I myself have been thinking about getting a faster PC box, but after the Intel news I thought - why not wait a year? VMWare is alreaday pretty responsive on my existing PC, and if it runs on my Mac box (which I use for my day-to-day work), I can have the best of all worlds and a significant speed-up at the same time.
Lastly, because of the above issues, I think Mac on Intel is only going to cause pressure on PC vendors to look at Linux more seriously, if only to squeeze another $50 off their PC prices.
Anyways, personally, I'm tired of all the off-the-wall and sometimes bizarre speculation and rumor-mongering going on. (piracy as Apple's strategy???) Since when is everyone and their cousin weighing in on the 'switch' actually news?
Because on linux, there's no such thing as software that isn't third-party.
Depends on your definition of "third party". After all, FreeBSD is open source and wasn't made by Apple, and lots of OSS is available for Mac, so based on your definition of what is and isn't third party, Apple/Mac couldn't make a difference either. But they do. A good definition I go with is "any software for the platform that is not maintained by the platform vendor". With that definition, at least wrt open source, it's the vendor's choice what software is and is not third-party.
So where do you draw the line between "third party software that everybody is going to need on the system" and "third party stuff that we can let users install on their own"? Debian takes the stance to simply package everything, and the debian apt repositories have thousands upon thousands of packages in them.
Simple, draw a line.:-) A vendor says "our OS is comprised of the following software components. Nothing more, nothing less". I mean, no vendor supports every package, so they do all draw the line somewhere (they have to). I perfectly understand that your above reasoning is one of the main reasons why Linux distributions *don't* make a clear distinction, but that doesn't mean they *can't* make the distinction. (And they'll save a lot of resources they could use elsewhere if they did.)
Windows has about 50 competing ones, and no central repository to get libraries etc. so you end up having to search all over the net for the runtimes.
I never search for runtimes, but then again maybe that's because most vendors whose software I use include any non-system runtimes they need. If you're searching for runtimes, that means you're either a software developer or the software packager is telling you to put the app together "piece by piece". In either case, package management isn't a solution - it's simply moving the problem to another area. (Complex dependency issues which could royally muck up your system.) The solution is to include the runtime with any application that uses it.
OSX only has on 'sort of' installer, but doesn't support uninstall which makes it kinda useless. It has exactly the same library issues as any other OS. It is after all just Unix with a GUI. (try running an app compiled under gcc4 on osx 10.3 for example... they renamed libstdc++ and it's not available as a package, so you have to find a copy, download it, su then put it into the system manually... not so user friendly.).
If you're using a terminal to install software, you're doing things far more advanced than the average computer user does. Most people don't know what su is. They don't have to thanks to bundling.
And here's the complexity issue I was talking about. See, you ask me to try running a gcc4 compiled app on OS X Panther. Why? I'll just build on Panther or use gcc3 and the Panther SDK on Tiger. This is a logical, simple solution. No mucking with libstdc++, no writing some "package" which mucks with that on a *user's* system (and if it screws something up, bye-bye system)... Frankly, it baffles me why people would want to try stuff like this.
As for no uninstaller, yes, that is an issue, but again, it's no big deal unless you're tight on disk space. Most people aren't, and in the future, that'll be even moreso the case. And, if you do want to uninstall programs, OSXGNU has an application that lets you do so, because all packages leave receipts. Again, a minor issue and there are solutions.
In any case, this debate is mostly academic. Ask a majority of Mac users if they're pulling their hair out over software management and dependency issues. They aren't. And unlike Debian users, 30% of Tiger machines (which would be hundreds of thousands) aren't having serious problems. So if this solution works for them, and is vastly less complex to maintain and update, really, why isn't it even worth considering for Linux users too?
There is too much freedom for even the distributions to make cores effectively. Debian doesn't develop the software, they package it. They have no direct control over compatibility issues between versions in their software. This makes their job a whole lot harder than in commercial OS's where one entity controls both the core software and the packaging.
You mean like Darwin/OS X? A fair amount of that OS comes from FreeBSD. Apple doesn't "control" FreeBSD.
What they do control is their development and testing process. They keep the number of packages *they* maintain down to core system components, and they don't support 1000 variations of their system setup. One setup to build, one setup to test. What I'm amazed most OSS developers have realized yet is that, well, this means they have *expontentially less* software combinations to test and support. You use what they give you, rather than risk hand-building some untested combiation of packages. Consequently, things are much less likely to break and when they do Apple will have a fix to you quick.
Microsoft and Apple don't package third party software for others, why should Linux vendors?
They also don't have the resources to making security patches for every package without upgrading to a newer version of said package (i.e. backporting). They really do a phenominal job given their constraints.
Well, their first stable release in several years is very broken, and regardless of how hard they've worked, it makes it clear that their development process sometimes lets very critical bugs get into release software. The core issue is that all packages on a system can be dependent on other system packages, which may have version conflicts, etc. There's no possible way to even test all the possible software combinations.
A complex system leads to complex problems. You either reduce complexity, or recruit more and more and more people to try and deal with it. So long as you have an endless stream of volunteers constantly testing and fixing, I guess this could work, but once the distro loses that, it's dead in the water because it can't remain stable. I also feel it's a shame because you have all these resources going into routine maintenance rather than improving the OS.
What I want is not even LSB, but *one* distro with a simple to maintain system. I eventually shrugged my shoulders and moved to Mac. What is odd to me is that despite the fact there's no LSB, all the distros out there are writing separate package management systems that work differently, but are basically all the same in that they are all complex due to dependency issues, and ALL basically are about maximizing disk space and efficiency, as if those things were far more important than my time. And that's how the business and home market thinks - they don't want software that gets in their way and wastes their time.
The sad part to me is that distros like Debian tout their software installation system as a "killer feature", as if the ability to easily install software is a rare thing in Linux and not a commoodity. Most everyone I know equates Debian with apt-get. Well, other OSes have had this "killer feature" for a decade, so long that none of them actually touts it as a feature, and OS X also doesn't have "DLL hell" issues. (Dependencies are provided by the system or by the app, no "variable" system configurations.) No package manager necessary.
You're right given the way you are phrasing this, " they don't take their system and break it into 1000 little components, which you are allowed to individually install or not install." And the more I think about it the more I think this is probably the better default handeling. Make the 1000 pieces version the pain in the neck non default and let most people just drag and drop.
For the strategy of things like drag and drop to work, the "1000 pieces" version must be a totally separate OS. Because once you say "OK, user A may install everything, but user B might pick and choose" you're back to the problem of "how can we guarantee that *anything* is on the machine" and if we can't do that, we need a package management system to check things for us. But so long as they are totally separate versions of the OS (one for business use, one for embedded/server/hobbyist use), then I think that's fine.
I'd say more its the complexity of the culture. The Linux culture wants the 1000 little pieces and Windows and Mac culture wants the all in one big package. For example Fink could install a huge number of binaries by default (say 8 gigs worth or something) and then have application menus that really make sense. Its the culture not the installation procedure that prevents that, Linux/Unix people would see it as a bad thing.
IMHO, it's not so much culture as target market. The people that use Linux do so because it does what they want it to do. So the product that exists gathers like-minded people, and eventually you see trends and commonalities among Linux users. If some Linux distro releases a default, "batteries included" install that just works, most of the current Linux users probably will shun it, but on the flip side, lots of businesses and home users will start to embrace it if it delivers on it's promises.
Sometimes someone has to go against the needs/desires of the current target market in order to open up new ones. OS 9 users weren't particularly happy about the OS X switch, but Unix geeks and Windows 'switchers' were. I couldn't have used OS 9, but I can use OS X and I do use it every day. So by changing the product, you change the target market and thus the 'culture' of the people supporting it. You see less Mac zealots, and more "I use Mac to get my work done" people, and that's directly a result of a change in direction by Apple.
IMHO, someone will always make a Linux, do-it-yourself, 1000 piece installer kit. And I think that's great. But if Linux wants to grab new target markets and market share, someone's going to have to go against the build-it-yourself philosophy of Linux and make something more akin to Apple and Microsoft's desktop offerings. (Of course, hopefully learning from their mistakes rather than repeating them!)
I'm not against the app bundle concept. It's perfect for some things. Some people are pushing hard for similar things in Linux/Unix (such as the rox desktop). But it's only useful for end user applications. Which are really only a small percentage of the total software on a system.
Yes, but outside of developers and system admins, who cares about most of that other software?
For most stuff you either need it to come with the system or you need to install it. Think of a web server. I'm assuming Apache comes with OSX. If it does, is it configured started automatically?
It comes installed, but is most certainly not started by default. They know better than to emulate Microsoft's security practices.:)
If it doesn't, is a drag-n-drop to the desktop going to properly install it? Ditto for any other service.
I just need to *start* the installed software, which I can do by starting "System Preferences", selecting "Sharing", and checking on the "Web Sharing" check box. Apache now runs. Ditto for SAMBA, printer sharing, AppleTalk/Rendezvous, and other services. All come out of the box, but are disabled by default. If you get the aptly named "Mac OS X Server" product, they have all sorts of additional easy, GUI configuration tools for web servers and such.
Don't like that example, then what about screensavers. At the minimum you have to at least drag-n-drop them to a startup directory.
Those have installers so that the users don't need to worry about where to drag/drop it. Similar to MS wizard installers.
And what about languages like Java, Python, Ruby and Ocaml (OSX can't possibly have every language installed by default)?
Well, it doesn't have Ocaml. (Or, at least I haven't seen it.;) But then again, you forgot to mention Perl and AppleScript, and now Dashboard widgets (CSS/JS). All these are installed in every OS X machine. It even includes wx bindings for Python and Perl, as well as a CoreGraphics Python extension. In short, it most certainly does have all that stuff.
For other stuff, a Mac installer can be made.
Are they going to get integrated with Xcode just by dropping them on a user's desktop?
Out of the box XCode does things like Python syntax highlighting so it's already somewhat integrated. And there are lots of tips on further integrating XCode and Python, though honestly I like BBEdit so much I rather stick with that for my Python coding and thus can't speak much on this topic.
So how does package management beat this?
Apple has done a fantastic job making their computer an appliance. But sometimes you need more than a one-size-fits-all appliance.
Outside of building a highly customized distro for server or embedded use, or installing on ancient computers, I don't see why one-size-fits-all wouldn't work. Works great for me. Those that criticize the approach almost always haven't tried it.
And all computers are appliances. They exist solely to help people accomplish tasks. The only comparison between computers is how easily and quickly they let the user accomplish a particular task, or how reliably they provide a service.
But honestly, at this point we're just trying to poke holes in each others' arguments. You talk to me like I've never dealt with all the things you mention above, and that somehow I will all of a sudden realize that "hey, Mac OS X doesn't do that well". I've been using the OS for 4+ years. I've run web servers, tested database-backed sites with it, and I share files every day between Linux, Windows and Mac boxes. I regularly do Python and C++ development and work with CVS, SVN, etc. And I still see no need for a package manager. I don't even use the ones that are available.
I, on the other hand, feel like most Linux users simply can't comprehend a computer without a package manager working correctly or efficiently, but then again, if I used Linux as my primary OS, maybe I'd feel that way too.:) I dou
My point is that you don't have to worry about it under Linux/BSD/Unix either. If you do, you have a bad package manager. Sure the system may break, but you can't tell me OSX is so perfect it's never broke before.
As you say, there are several dozen, each with their own bugs and quirks. The one on OS X has no bugs because it doesn't even exist. I just drag and drop and I'm done.
As for breakage by packages/installers, well, Mac installer packages could cause that too if you give your password, so it's rather a wash. But consider that many Mac packages don't use installers, and those software installers usually don't (nor should they) alter system directories, while all package manager packages do this (unless they install to someplace like/opt). In practice, then, Linux is more likely to have packages messing with the system, which leads to more chances for (even accidental) breakage.
Now just one or two programs installing extra copies of Qt is fine. But what about dozens? That starts to add up. Restricting development tools to only what Apple distributes is an extreme hindrance to porting software.
If Apple sees dozens of apps using Qt, they will probably consider including Qt with their next system update. (And they'll be getting lots of calls to do so.)
It's almost like Apple never expected anyone but themselves to write a common application component.
Replace "common application" with "system" and I think you're absolutely correct. Apple makes an effort to keep control over the system and actively discourages touching it, which means less chance of some application writer coming in and potentially messing up my system by accident. +1 from me.:)
Apple does have frameworks, and you can install them in many places, including "system-wide accessible" or per-user-accessible locations. So, if you wanted to, you could write one of those "evil" scripts that checks for the Qt framework and downloads it and starts the installer if it doesn't exist.
But I'm figuring you think it's just easier to bundle. As a user, I'd rather have a "complete" package even if my download time's a bit longer, anyways. It's just simple to bundle, and I doubt you can show many occasions where bundling has really hurt a user's system. And there's no doubt it's more error proof and easier to maintain than a package management application and package repository. Apple can spend the time and money that would have gone towards that system improving their software instead.
So we're back to, is this a real problem for users, or do package managers just really call to the software developer's desire for maximum efficiency even at the cost of a complex system which must be constantly maintained?:)
I'm an OSX user. It doesn't just work nearly as well as a package management system. Look at the installation instructions for anything complicated (like eps ghostscript prior to 10.3) or LyX (Aqua version) or QT designer (particularly if you want to use fink QT as well).
These are basically applications that work on Mac but want/have to use Unix-style installation. They probably have hardcoded Unix path assumptions for dependencies which is something that doesn't need to be done on Mac. They could have packaged it better, and easier, they just chose not to. And they don't really have to because their target audience is software developers, many of whom are probably Unix developers.
The fact is that a simple package management system like OSX's works well for simple package management issues. Linux has a vastly more complex web of packages than either Windows or Mac and thus their simple solutions aren't appropriate.
That's not true. What's inappropriate about making installation simple (or simpler)? (Or are you assuming it can't be simplified?)
The reality is that Linux *exposes the user* to a vastly more complex web of packages than Windows or Mac does. Go file by file through OS X or Windows' system folders and see if it's complex. I guarantee you it is. It's just that, unlike Linux, they don't take their system and break it into 1000 little components, which you are allowed to individually install or not install. In short, the complexity is hidden from the user rather than dumped in the users' laps. It isn't that Linux "just is" more complex, it's that it was explicitly designed that way. And I think that's a major problem for desktop adoption. (It's the primary reason I don't use it.)
In short, you're saying that some packages are "simple" or "complex", but really what differs is NOT the complexity of the packages (after all, Final Cut Pro, not to mention Tiger, is probably pretty complex but is a simple install), but the complexity of their installation procedures.
But from a standpoint of supporting a diverse ecology of software producers and lots of competition, the cathedral isn't the most desirable structure. It seems that when one pays a draconian cost (central control) to solve smaller problems (package dependencies, file locations), it might not be the best deal in the end. I'm still endeavoring to provide a better solution to this problem.
Why not a two-pronged approach? Some people and businesses want to take control of their OS, some don't, or, more accurately, they can't afford to. After all, when you talk about the better deal, is there really one 'better deal' for everyone?
It seems to me that the better deal for the Enterprise is control and customizability. Linux has, IMHO, got this covered pretty well. People can build their own distro off of Debian, LFS, or other distros, quite easily and take control over what is installed and what the users can do with it. This is good also for kiosks, PDAs/embedded devices, and other devices that provide a controlled experience to the end user. Not to mention hobbyists.:-)
But I don't feel this is the better deal for the home user, or the small to medium-sized business. The better deal for them is something that minimizes complexity and maintenance, and maximizes productivity. They want things to work "out of the box" and would even do things like upgrade their machine rather than hire a consultant to tweak the distro to their needs. Workers in many of these environments take some degree of responsibility over the maintenance of their computer, so it has to be very simple to understand and maintain for non-tech users. I don't think there's any Linux that actively targets these users yet. It's obvious lots of people want Linux to target this market though.
Well, those are just my thoughts on the matter, but there's lots of organizations out there like this; in fact, there are probably tons. (I work for one.) Get Linux into this market and IMHO it'll really take off, but so far I haven't seen people doing to Linux what needs to be done in order for us (and organizations like us) to adopt it.;-/
I've never used apt-get, but I have used many other package managers. On a KDE or GNOME desktop, installing a new application is as simple as download the app and double clicking on it. You're done. If there are missing dependencies they're automatically downloaded and installed for you.
But on Mac, users and developers alike do not need to worry about any of this, which by default simplifies issues. It may "magically" work (when it does work without effort, and in my experience it doesn't always work), but it doesn't change the fact that Mac developers don't need to deal with dependency systems and Mac users never even have to fathom the possibility of a missing/conflicting/etc. dependency. No tool and database to maintain, update = no chance of it not finding dependencies, restricting installation of certain packages, and otherwise getting in the user's way.
No, it's not perfect, because you can still get that "untrusted" message. But how is OSX any better, especially when it's completely silent about "untrusted" applications?
OS X is better because you never deal with adding URLs to a repository, for starters. Users will already be confused as to why they have to add a URL to a "repository" (whatever the heck that is) and now the system is prompting them with a warning that suggests they might be doing something very, very wrong. All they want to do is install some software. Why does it have to be so confusing?
OS X does warn you before running programs for the first time, but it's in the context of downloading a file, not in the context of "setting up their repository", and the warning is also in plain English, so the user can get a good idea of why this might be harmful and what they may want to do.
You also end up with huge redundancies. Something like KDE which would normally take a few hundred megabytes of storage now takes hundreds of gigabytes. Instead of one copy of Qt and kdelibs you now have hundreds. And double the size for every additional user installing it.
Have you never seen a system that doesn't use a package manager? Are you familiar with how they work? Look, I never suggested distributing the whole system/OS with the application, or everything above the Linux kernel. You might want to look at OS X. (Read up on it if you don't have it.) Nobody distributes Cocoa/Carbon/etc. with their application because those programs are *guaranteed* to be included with the OS. In fact, there's also Python, Perl, wxWidgets, and a whole slew of other tools that come with OS X out of the box, installed on every system. They aren't "options", they are automatically installed. I hear very few people complaining about the disk space they've "lost" to these components.
In short, on OS X there's a clear line between what is available on any Mac OS X system, and what you have to bundle yourself. Every software component is one or the other. Any free library expected to be found in more than a few applications should be included, by default, as part of the OS, and Apple often does this. The result - no complicated "dependency checking" system needed at all, and at the same time, small application bundles! It's brain dead simple to understand for developers, and they don't need to put dependency logic into their packages. Disk space is cheap, people's time is not. Which would you think the average user and developer's more interested in maximizing?
Because on a Mac, you can be guaranteed of the existence of preinstalled libraries, and on Linux you can't. I agree the Mac way is much better, but until there's a ubiquitous Linux standard it's not going to be feasible there.
You hit the nail on the head about support. However, every Linux vendor doesn't need to adopt this, just one does. We're talking about distribution of binaries, and it's not like RedHat binaries run on SuSE or Mandrake or Debian. Package creation will be much easier, meaning that developers will be more likely to actually create packages. Other distros will get left behind (or have to recruit/hire more and more packagers) as more and more developers get comfortable with just building a binary and plopping it on their web site/SF site, etc.
In fact, the interesting thing is that if one vendor succeeds with this, then it'll force other vendors to adopt it, forcing them to - in turn - adopt a standardized set of "system components" as that's the only way things will work. Make the change, and the standard will follow. Don't wait for the standard to make the change. If I had some resources I'd build a distro like this myself because I believe it'd open Linux up to whole new markets and I do believe such a thing could be sold.
Depending on what you are using a Mac for. Most people I hear from appear to use the Mac as a Unix which also runs Microsoft Office.
Yes, you're right that it depends, but we're talking about Linux on the desktop. Most people I know replaced their Windows with Mac, and don't know anything about Unix. These are all 'potential' Linux users. The users you're talking about are Unix/Linux converts all ready. They probably have little problem dealing with complexity.
Everything else is pretty much ignored, And of course, you are still missing out on understanding how complex Unix applications can get.
I'm not missing out on anything. I'm a software developer who uses Linux. I KNOW how complex it can get, and that's precisely why I don't use it except when I have to. The thing is, if Unix apps are so complex, then that's a problem that Unix apps will need to find a solution to if they want to win over new users, because I don't have that complexity on Mac, even when dealing with things like HD video production and 3D modeling software. Does it really need to be this complex?
I think you mix up two things: interface and internal workings.
To users, they're one and the same. i.e. take my comment about adding a URL to the repository, or not being able to find packages (that exist somewhere, just not in the package manager database). The inner workings of apt-get have forced an implementation detail to be part of the interface. The inner workings have thus 'complicated' the software interface. So users are going to confuse the two, and it's why I phrased my argument the way I did.
As for the interface: a drag'n'drop interface for apt is abolutely feasible. It could be, and perhaps it is already implemented (I don't know, since I would not use it anyway).
I'm not sure how a drag and drop interface for apt-get would look, but the fact is that I have a great experience on OS X *without* apt-get. What do I need it for again? I've been using Mac (and developing software on and for it) for 3-4 years now.
If developers bundle non-system dependencies or statically link them, the need for apt-get or similar tools basically disappears. As awesome as the software is, it does something that on Mac doesn't even need to be done. This makes life easier for users AND software developers alike. I've tried packaging for Linux, the learning curve is several times higher than Mac or Windows.
And I did not bash OS X, I've just observed that their solution is a really simple and limited one. Using it instead of the Debian system would not solve any problem but create lots of additional ones.
What complaints have you heard from Mac users about this system? Particularly, ones that aren't Unix developers? I've heard none. Unix developers can use Fink or DarwinPorts (though I just use source tarballs), but when we're talking about "Linux on the desktop" we're talking about converting people who aren't Unix developers, obviously. So from your arguments so far, the problems for desktop users that you suggest exist are theoretical ones, at best. To me, that's not a solid argument against OS X's packaging system, it's just "name calling". (obviously, "dumb" doesn't have positive connotations and suggests deficiency)
Unfortuntately, it is just this kind of logic that keeps Linux from moving forward. I use an "apt-get" free system every single day and it causes me no problems whatsoever. So why should I learn apt-get? Why should I install it? Why should I deal with it? These are the questions you have to answer for potential Linux converts, who will have to use apt-get, or RPM, or portage, whether they want to or not.
And, finally, you haven't answered the converse question - why NOT use OS X's approach on Linux? "simple and limited" say nothing. Explain what problems users on OS X are having and how apt-get would solve those problems, or, at least consider that maybe OS X's system is a better solution than you suggest it is.
Now, take Debian's package system: it handles dependencies, version conflicts, alternative packages that serve the same purpose, etc, etc, ec. And it is absolutely easy: an apt-get install xyz installs/updates package xyz and all the necessary shared libs, updates file associations, whatever (and it does not takes exactly rocket science to create some GUI for that single command line).
I realize this could start a 'flame war', but it surprises me how many Linux users just don't see why package managers are not the greatest thing since sliced bread for average users.
While you and others may go "wow!" at all the magical stuff apt-get does, the average user doesn't even know what dependecies are, nor do they care. And they don't want to care. On Mac, as "simple and dumb" as the OS X system is, it *just works* for everyone from grandma to geeks. A simple and dumb system is also, well, very easy to understand! Drag and drop your app into the folder. Easy. Nice. As for package managers, I've had to deal with scenarios where I had to muck with the package manager configuration to get it to install packages for me, and I've had to "add URLs" to the database at which time I was warned about "untrusted sources" (the average user is NOT going to grok all that). In fact, when the average user sees "no results" from the database, they'll simply conclude the package isn't available and stop. I'm not sure how anyone thinks this is easier than going to versiontracker.com/apple.com/etc. and just downloading a file (or popping in a CD), then dragging the app into the applications folder.
If you doubt me, have someone do usability research on package managers and drag and drop installs, and see which is, on average, easier for users to understand and get working with. If you really think package managers like apt-get will come out ahead, then you must spend a lot of your time on the computer and deal regularly with others like yourself.
If you really want the Linux desktop to succeed, you have to question why lots of people are switching to Mac instead of just 'bashing' anything that is not as complex and elegant as apt-get. Call it dumb, call it simple. I call it a solution that works, and considering Macs are seeing a 40% growth this year, so do a couple other people as well.
As someone whose tried every Windows from 3.1 to XP, close to a dozen Linux distributions (including Debian and Ubuntu), and OS 9 and OS X, I have to say application installation and removal on Mac blows the others away. It works and it's brain-dead simple, which means I spend more time doing real work than fooling around with installers and packaging programs. Good luck on converting the world to apt-get, though.
Every president before Bush *did* keep supporters on the panel regardless of their political affiliation. Check the link.
So, yes, it is different from what any other US president has done. And this organization was formed in 1923 so it is a clear and established precendent that Bush has broken. You might want to ask yourself why no previous president has ever done this. Aren't you the least bit curious?
IMHO, we're heading way outside of "politics as usual" here and in other recent matters in both the administration and Congress. But I guess some people will simply choose to be apathetic to it no matter what happens...
So basically, you'd rather Apple be able to lock your purchased AAC files to be only playable on iPods because they haven't engaged in overtly monopolistic behavior? What if you want to switch to another player? Or your iPod breaks? How fair is it that you have to buy another iPod?
Actually, assuming something that I found to be better than the iPod came out, what I'd do is just rip CDs of my music and re-rip them into my new software. Yeah, it's a pain in the ass, but let's be realistic here - any major vendor who wants to make it in the music business has to play with the big 5, and that means DRM. Apple's is actually about the best DRM of the bunch. (And FYI, I don't have any info they've engaged in *any* monopolistic behavior.) The key in my mind is that Apple's ease of use and simplicity sold me. They provide such an excellent service compared to other vendors that I don't mind being "locked in" so much. Apple isn't forcing me into their system; I chose it, warts and all. (Because the other players offer choice, but have their own, IMHO nastier, warts.)
And speaking of fair, how fair is it that we legislate to Apple that they have to take all the great products that they developed using lots of time and money and start sharing them with their competitors? Their products are their "competitive advantage", and it's how they make money. The fair word is one of those generic "feel good" arguments that doesn't measure up in reality. Fair to whom? Certainly not Apple. It wouldn't be fair to all the engineers and testers and graphics designers, etc., etc. at Apple who slaved over making all this stuff work simply, effectively and seamlessly. How is this "fair" to them? Why do you deserve open access to their hard work? Since when did Apple products and services become a public good?
I think letting the market decide is fair to *everyone*. If customers and the market want them to open up, then they can provide pressure - buy other players and other services. That will give Apple a (big) incentive to open up. I'm not saying I wouldn't like to see Apple's format opened, I'm saying that no one but the market should be asked to decide it. Congress should not be getting involved because Apple hasn't done anything *illegal* or ethically wrong to harm the other market players. They've just been fiercely competitive. If Apple's competitors have a problem with Apple's behavior, well, make a product and service which tears them a new one! Why isn't this the "fair" way for the market to tell Congress (and Apple's competitors) what they want?
So, by all means, support open standards. More power to you! But don't *legislate* them on every vendor whose products become an overwhelming success. Legislature is for when the company has done something illegal, not for when they're the biggest kid on the block. IF Microsoft had never crossed the line between being massively successful and being a company hell-bent on blowing competitors out of the water for good, I would be saying the same thing for them. (As unpopular as that may make me on here.;-)
Also, it's not nice to generalize with terms like "you people". I don't know who "we" are. Who are you people?;-)
I'm sure someone will tell me that the market should decide. Fair enough, but funny how that reasoning is contingent upon the company being discussed.
Regardless of market share, Apple does not behave like Microsoft at all. While Apple has popular market share for iPod, it is not using that market share to *exclude* competitors. For example, it doesn't attempt to force vendors who want to sell iPods to exclude other players from the market, or threaten retribution to those companies who sell competing products. It also doesn't say that if you sell iPods you must also put Macs on your shelves, etc.
Microsoft, on the other hand, has done pretty much all of these things at one point or another in their history. Consider their OEM agreements with vendors forbidding them to sell computers with other OSes. Consider their attempt to drive Netscape out of business by giving away IE and "integrating it with the OS" (and letting the product stagnate as soon as the competition disappeared). These acts show a company trying to take choice and competition OUT of the market, not providing a BETTER choice. And that's the difference.
All the installer needs to do (and many installers already do this) is create a log of files installed, and uninstall only those files. Look at Unix; if they nuked/usr/local everytime someone uninstalled an application... But that doesn't happen, because the installers on those platforms keep track of what was installed where.
An uninstaller *should* do what the user expects it to, which is just uninstall the program, no matter where the installer put the files. If it's too much work to undertake in the short term, as a stopgap, they could do something like forbid installation into C:\ (or any root prefix). But just calling the user stupid doesn't help Mozilla any. Most commercial apps do these sorts of things just fine, and if open source apps want greater acceptance in the marketplace, they should too. (Note that with my suggestions above, no "dumb user" warning messages needed!)
Slashdot Mirror
People always say "Linux" like it is one big community all moving towards one ultimate goal. It's not. All "Linux" is, really, is a kernel that can be used as the core of an operating system.
:-)
Look at the comments in the article. Do all the comments apply to all Linux-based distros? Many of the criticisms are not only already known (in a general sense), but also being addressed by some distros. If you look at Ubuntu Linux, for example, they've already taken steps to address many of the issues Asa pointed out. (One GUI, remove app clutter, focus on simplicity.) So exactly what is this "desktop Linux" he says is not ready? Is he talking about Ubuntu, RedHat, SuSE, Debian, Gentoo, etc., etc. Really, he's just talking in generalities.
And thinking and talking in generalities is a major part of the problem - how do you address a problem with 100 distributions? How do you standardize all these operating systems out there based on Linux? You can't, really. You can't sit around and wait for even a majority of distros to decide to come up with, and support, some standardized "Desktop Linux" experience.
In fact, the main issue with most *nix-based distros is that they're bound by their components and build systems to remain mostly the same as other *nix distros. They're different enough to not be the same, but similar enough not to really be different. There's a glut of distros but there's not that much going on in terms of actual desktop work outside of people tweaking GUIs and maintaining packages. So long as no one wants to try anything radical, how does anyone plan on this new and compelling alternative to Windows appearing?
But I wouldn't want to stop yet another person from pointing out the same deficiencies that people have been pointing out for years. Somehow it seems it's still news here.
We're all doomed! One day soon, computers will be building themselves, and running everything. In fact, they'll even be posting to /. with even more insightful comments than ours!! They may even achieve sentinent life and not realize they're robots! Wouldn't that be scary?
-- Message posted by Slashbot #1192392, activation date: 06/23/2004.
I think the idea is that you sould include private copies of any libraries you need outside of those that the LSB specifies.
Admittedly LSB is hairy, but no one who wants to create portable binaries should be using C++ in the first place. Once the almighty C++ arbiters decide on a standard ABI, this will change, I hope.
And how do you propose OSS developers work with programs like Mozilla, wxWidgets and Qt if they can't use C++? Rewrite them in C? I see your arguments, but in reality it's ridiculous to demand C only coding or include everything down to gtk/glib with every desktop app that ships. Again, we're talking about getting desktop application developers to package Linux binaries of their apps. To get them to do that, developers need real solutions that work for real world desktop apps (many of which ARE in C++) and are relatively simple to implement. LSB is nowhere near what these people need right now, and there isn't really any other alternative except compile and package on each distro separately.
Saying that the developers were wrong to write in C++ or that they should be building and distributing private copies of every library they use above the (small) LSB standard is basically blaming the problem on the developer. Sorry, Linux just does not have the marketshare to make me jump through all those hoops just to get a single binary, and considering the complaint of the OP, a lot of other developers feel the same.
Theoretically, yes. In practice, it doesn't work for anything above simple command line apps. That's because 1) the LSB covers only a small subset of components commonly found on a user's system (KDE and GNOME/GTK are notably missing), 2) LSB had serious problems with C++ support last I used it, and 3) it doesn't 'just work' in many cases. I couldn't even compile a LSB-compatible glib using the LSB toolset, much less compile my app, which is GTK-based and embeds Mozilla. And some of the bugs that made me unable to compile glib had been in the bug database for close to 6 months, suggesting serious issues with bug fixes.
They are just now starting a project to address the desktop support, but that looks to be close to 1 1/2-2 years from giving any serious results by their own roadmap. If they succeed and get the bugs fixed, congrats to them, it will certainly help Linux. But right now the LSB is unusable for desktop apps and my experiences with them in the past doesn't give me great confidence that they'll have something polished within even 2 years.
Except the developer has to compile a 'goddamn binary' for every major Linux distro, along with writing packaging scripts for 3 different package management systems, at least. You're kidding yourself if you think every freeware/shareware author cares about Linux so much that they'd go through all that. As someone who regularly makes packages for Windows and Mac OS X, I can say that Linux packaging is a hair-pulling experience that is annoying enough that I don't even bother.
Welcome to the downside of choice - it costs the software developer exponentially more time to create packages to try to accomodate all the possible choices his/her potential Linux users could make. (Including setting up several Linux boxen to package and test on, learning scripting languages, and packaging formats.) Or, s/he could say 'screw it' and just deliver a tarball, and be done with it. Linux user typically aren't into paying for software anyways, so while they may complain, they probably won't put their money where their mouths are, AND, if they like the software, they'll probably do whatever they have to to use it. So what's the incentive for software developers to make you happy?
TFA gets it in that Linux system design makes a lot of things harder than they have to be, and that it drives BOTH users and developers away from the platform. People can scream that the problem is the users or the developers all they want, but it's not going to get any more users, or any more packages created. The reality is that the easier a system is to use, the more people who will adopt it. If you don't like the problems Linux has, well, help get them fixed so that more users/developers will use Linux. If you don't like hearing that answer, then fork over a few bucks for a different platform where the OS developers take care of the problem for you.
They don't have to be, but you might as well buy a Gamecube if you want games for your kid. That's not to say kid-friendly games don't exist, but they aren't the big sellers or the ones that 'take the platform to its limit'. Sony and Microsoft are really fighting over the same market - the gaming 'enthusiast'. Not kids, really, unless the kids have the dough to keep up with that market.
Generally, Kids have to convince their parents to buy games, and systems, which cost money. Thus a company like Nintendo by sticking to their guns must innovate, be kid-friendly, and provide systems at a reasonable price, otherwise parents will balk. I applaud Nintendo for doing this, but it seems to me that Sony and Microsoft just don't see the big bucks in that.
What they do see is that hardcore 'gamers' will buy $200 video cards, or splurge $300+ on a console. All basically so they can play newer, 'more realistic' 3D FPS shooters. Consider the PS3, which based on statements they've made so far about the Japanese release and US pricing, is probably going to come in close to $500. My guess is that the XBox will come in either at the same price or at most $100 less. These are NOT consoles that most kids are going to get for Christmas. Or, consider that the PSP. at $250, certainly doesn't look as appealing as a Nintendo DS to parents on a budget. But these consoles *will* sell - to kids from well-off families and to the working, adult 'gaming enthusiast' - gaming geeks. Those geeks will splurge on games, and high-powered add-ons, etc. to keep up with trends and be able to frag with their friends.
Me? I've had nearly every gaming system from the original Atari up until PS2 and Gamecube. But I didn't buy XBox (because I like to keep having choices in the future :), and neither PS3 nor the XBox360 look appealing to me, ESPECIALLY at the price points they'll likely come in at. I'll wait a couple years, though I'm sure PS3 is going to release a new $#&!@*& Metal Gear Solid game right after launch to make that really, really hard to do.
What I WILL likely be buying is the Revolution. It'll probably be less than $300, and in fact I wager it'll come in at ~$200, and I'm going to take that extra money and download tons of fun games from NES/SNES/N64 days. And of course I'll be getting the new Zelda, Mario and Mario Party, etc. games. Nintendo, despite it's mistakes, is the only major player in ther market who still remembers what gaming used to be about. Gaming. :)
The interesting thing is that gaming's never been this expensive before. If they go through with this, they're relying heavily on that enthusiast market to keep sales high. We'll see, but I've always been a console gamer, and nothing about the new systems (except for Revolution) is exciting me whatsoever. So the pictures are prettier. Wow.
BTW, if you want new games that are still actually fun and kid friendly, get a Gamecube and get Mario Party 6 or even Super Mario Sunshine. Nintendo still finds ways to make incredibly fun games, and I've never met a person who didn't like Mario Party 6, though you might have trouble getting the 'fraggers' to swallow their gamer pride and play a 'kids' (actually family) game. :)
You're probably thinking of XGrid, but that's for distributed computing.
As for why they're bothering, well, all I can say is that I wish more people'd try iWork because then they'd see it's not a clone of MS Office and OpenOffice. It's not "there yet" in terms of being feature-complete enough to compete with these office suites, which is probably what's keeping their sales so low, but if you're doing something like desktop publishing or want to design a slick presentation, iWork is easier and in many cases gives better results.
Apple changing its hardware has no direct impact on Linux, and it most certainly isn't a threat to Linux. I don't see why anyone is worried about this, much less refuting those worries.
If anything, Apple's switch to Intel means that along with the ability to run Windows easily alongside Mac, now you'll be able to run Linux distros easily alongside Mac too. Gee, that sounds like a kickass machine for cross-platform developers, doesn't it? One box that runs Win, Linux distros, and Mac. I'm also fairly certain someone (if not VMWare themselves) will devise software along the lines of VMWare for OS X which will make this virtualization pretty fast and seamless. (Yes, there's Virtual PC, but that didn't work well with Linux distros last I checked.)
In fact, one thing I realized about this transition is that it's companies like Dell that have to be worried. Once you can install Mac, Win, and Linux in one box - and they'll probably have hardware that is competitive with other PC boxes - the only reason to buy one of those other PC boxes is the cost advantage. And if you're a pro software developer, or a home user or small business sick of viruses and spyware, that cost advantage doesn't look too appealing when weighed against your additional time and effort messing with the machine(s). People can now say "well, I'll try Mac - if I don't like it, I can always throw Linux or Win on this thing..."
I myself have been thinking about getting a faster PC box, but after the Intel news I thought - why not wait a year? VMWare is alreaday pretty responsive on my existing PC, and if it runs on my Mac box (which I use for my day-to-day work), I can have the best of all worlds and a significant speed-up at the same time.
Lastly, because of the above issues, I think Mac on Intel is only going to cause pressure on PC vendors to look at Linux more seriously, if only to squeeze another $50 off their PC prices.
Anyways, personally, I'm tired of all the off-the-wall and sometimes bizarre speculation and rumor-mongering going on. (piracy as Apple's strategy???) Since when is everyone and their cousin weighing in on the 'switch' actually news?
Depends on your definition of "third party". After all, FreeBSD is open source and wasn't made by Apple, and lots of OSS is available for Mac, so based on your definition of what is and isn't third party, Apple/Mac couldn't make a difference either. But they do. A good definition I go with is "any software for the platform that is not maintained by the platform vendor". With that definition, at least wrt open source, it's the vendor's choice what software is and is not third-party.
So where do you draw the line between "third party software that everybody is going to need on the system" and "third party stuff that we can let users install on their own"? Debian takes the stance to simply package everything, and the debian apt repositories have thousands upon thousands of packages in them.Simple, draw a line. :-) A vendor says "our OS is comprised of the following software components. Nothing more, nothing less". I mean, no vendor supports every package, so they do all draw the line somewhere (they have to). I perfectly understand that your above reasoning is one of the main reasons why Linux distributions *don't* make a clear distinction, but that doesn't mean they *can't* make the distinction. (And they'll save a lot of resources they could use elsewhere if they did.)
I never search for runtimes, but then again maybe that's because most vendors whose software I use include any non-system runtimes they need. If you're searching for runtimes, that means you're either a software developer or the software packager is telling you to put the app together "piece by piece". In either case, package management isn't a solution - it's simply moving the problem to another area. (Complex dependency issues which could royally muck up your system.) The solution is to include the runtime with any application that uses it.
OSX only has on 'sort of' installer, but doesn't support uninstall which makes it kinda useless. It has exactly the same library issues as any other OS. It is after all just Unix with a GUI. (try running an app compiled under gcc4 on osx 10.3 for example... they renamed libstdc++ and it's not available as a package, so you have to find a copy, download it, su then put it into the system manually... not so user friendly.).If you're using a terminal to install software, you're doing things far more advanced than the average computer user does. Most people don't know what su is. They don't have to thanks to bundling.
And here's the complexity issue I was talking about. See, you ask me to try running a gcc4 compiled app on OS X Panther. Why? I'll just build on Panther or use gcc3 and the Panther SDK on Tiger. This is a logical, simple solution. No mucking with libstdc++, no writing some "package" which mucks with that on a *user's* system (and if it screws something up, bye-bye system)... Frankly, it baffles me why people would want to try stuff like this.
As for no uninstaller, yes, that is an issue, but again, it's no big deal unless you're tight on disk space. Most people aren't, and in the future, that'll be even moreso the case. And, if you do want to uninstall programs, OSXGNU has an application that lets you do so, because all packages leave receipts. Again, a minor issue and there are solutions.
In any case, this debate is mostly academic. Ask a majority of Mac users if they're pulling their hair out over software management and dependency issues. They aren't. And unlike Debian users, 30% of Tiger machines (which would be hundreds of thousands) aren't having serious problems. So if this solution works for them, and is vastly less complex to maintain and update, really, why isn't it even worth considering for Linux users too?
You mean like Darwin/OS X? A fair amount of that OS comes from FreeBSD. Apple doesn't "control" FreeBSD.
What they do control is their development and testing process. They keep the number of packages *they* maintain down to core system components, and they don't support 1000 variations of their system setup. One setup to build, one setup to test. What I'm amazed most OSS developers have realized yet is that, well, this means they have *expontentially less* software combinations to test and support. You use what they give you, rather than risk hand-building some untested combiation of packages. Consequently, things are much less likely to break and when they do Apple will have a fix to you quick.
Microsoft and Apple don't package third party software for others, why should Linux vendors?
They also don't have the resources to making security patches for every package without upgrading to a newer version of said package (i.e. backporting). They really do a phenominal job given their constraints.Well, their first stable release in several years is very broken, and regardless of how hard they've worked, it makes it clear that their development process sometimes lets very critical bugs get into release software. The core issue is that all packages on a system can be dependent on other system packages, which may have version conflicts, etc. There's no possible way to even test all the possible software combinations.
A complex system leads to complex problems. You either reduce complexity, or recruit more and more and more people to try and deal with it. So long as you have an endless stream of volunteers constantly testing and fixing, I guess this could work, but once the distro loses that, it's dead in the water because it can't remain stable. I also feel it's a shame because you have all these resources going into routine maintenance rather than improving the OS.
What I want is not even LSB, but *one* distro with a simple to maintain system. I eventually shrugged my shoulders and moved to Mac. What is odd to me is that despite the fact there's no LSB, all the distros out there are writing separate package management systems that work differently, but are basically all the same in that they are all complex due to dependency issues, and ALL basically are about maximizing disk space and efficiency, as if those things were far more important than my time. And that's how the business and home market thinks - they don't want software that gets in their way and wastes their time.
The sad part to me is that distros like Debian tout their software installation system as a "killer feature", as if the ability to easily install software is a rare thing in Linux and not a commoodity. Most everyone I know equates Debian with apt-get. Well, other OSes have had this "killer feature" for a decade, so long that none of them actually touts it as a feature, and OS X also doesn't have "DLL hell" issues. (Dependencies are provided by the system or by the app, no "variable" system configurations.) No package manager necessary.
For the strategy of things like drag and drop to work, the "1000 pieces" version must be a totally separate OS. Because once you say "OK, user A may install everything, but user B might pick and choose" you're back to the problem of "how can we guarantee that *anything* is on the machine" and if we can't do that, we need a package management system to check things for us. But so long as they are totally separate versions of the OS (one for business use, one for embedded/server/hobbyist use), then I think that's fine.
I'd say more its the complexity of the culture. The Linux culture wants the 1000 little pieces and Windows and Mac culture wants the all in one big package. For example Fink could install a huge number of binaries by default (say 8 gigs worth or something) and then have application menus that really make sense. Its the culture not the installation procedure that prevents that, Linux/Unix people would see it as a bad thing.IMHO, it's not so much culture as target market. The people that use Linux do so because it does what they want it to do. So the product that exists gathers like-minded people, and eventually you see trends and commonalities among Linux users. If some Linux distro releases a default, "batteries included" install that just works, most of the current Linux users probably will shun it, but on the flip side, lots of businesses and home users will start to embrace it if it delivers on it's promises.
Sometimes someone has to go against the needs/desires of the current target market in order to open up new ones. OS 9 users weren't particularly happy about the OS X switch, but Unix geeks and Windows 'switchers' were. I couldn't have used OS 9, but I can use OS X and I do use it every day. So by changing the product, you change the target market and thus the 'culture' of the people supporting it. You see less Mac zealots, and more "I use Mac to get my work done" people, and that's directly a result of a change in direction by Apple.
IMHO, someone will always make a Linux, do-it-yourself, 1000 piece installer kit. And I think that's great. But if Linux wants to grab new target markets and market share, someone's going to have to go against the build-it-yourself philosophy of Linux and make something more akin to Apple and Microsoft's desktop offerings. (Of course, hopefully learning from their mistakes rather than repeating them!)
Yes, but outside of developers and system admins, who cares about most of that other software?
For most stuff you either need it to come with the system or you need to install it. Think of a web server. I'm assuming Apache comes with OSX. If it does, is it configured started automatically?
It comes installed, but is most certainly not started by default. They know better than to emulate Microsoft's security practices. :)
If it doesn't, is a drag-n-drop to the desktop going to properly install it? Ditto for any other service.
I just need to *start* the installed software, which I can do by starting "System Preferences", selecting "Sharing", and checking on the "Web Sharing" check box. Apache now runs. Ditto for SAMBA, printer sharing, AppleTalk/Rendezvous, and other services. All come out of the box, but are disabled by default. If you get the aptly named "Mac OS X Server" product, they have all sorts of additional easy, GUI configuration tools for web servers and such.
Don't like that example, then what about screensavers. At the minimum you have to at least drag-n-drop them to a startup directory.
Those have installers so that the users don't need to worry about where to drag/drop it. Similar to MS wizard installers.
And what about languages like Java, Python, Ruby and Ocaml (OSX can't possibly have every language installed by default)?
Well, it doesn't have Ocaml. (Or, at least I haven't seen it. ;) But then again, you forgot to mention Perl and AppleScript, and now Dashboard widgets (CSS/JS). All these are installed in every OS X machine. It even includes wx bindings for Python and Perl, as well as a CoreGraphics Python extension. In short, it most certainly does have all that stuff.
For other stuff, a Mac installer can be made.
Are they going to get integrated with Xcode just by dropping them on a user's desktop?
Out of the box XCode does things like Python syntax highlighting so it's already somewhat integrated. And there are lots of tips on further integrating XCode and Python, though honestly I like BBEdit so much I rather stick with that for my Python coding and thus can't speak much on this topic.
So how does package management beat this?
Apple has done a fantastic job making their computer an appliance. But sometimes you need more than a one-size-fits-all appliance.
Outside of building a highly customized distro for server or embedded use, or installing on ancient computers, I don't see why one-size-fits-all wouldn't work. Works great for me. Those that criticize the approach almost always haven't tried it.
And all computers are appliances. They exist solely to help people accomplish tasks. The only comparison between computers is how easily and quickly they let the user accomplish a particular task, or how reliably they provide a service.
But honestly, at this point we're just trying to poke holes in each others' arguments. You talk to me like I've never dealt with all the things you mention above, and that somehow I will all of a sudden realize that "hey, Mac OS X doesn't do that well". I've been using the OS for 4+ years. I've run web servers, tested database-backed sites with it, and I share files every day between Linux, Windows and Mac boxes. I regularly do Python and C++ development and work with CVS, SVN, etc. And I still see no need for a package manager. I don't even use the ones that are available.
I, on the other hand, feel like most Linux users simply can't comprehend a computer without a package manager working correctly or efficiently, but then again, if I used Linux as my primary OS, maybe I'd feel that way too. :) I dou
As you say, there are several dozen, each with their own bugs and quirks. The one on OS X has no bugs because it doesn't even exist. I just drag and drop and I'm done.
As for breakage by packages/installers, well, Mac installer packages could cause that too if you give your password, so it's rather a wash. But consider that many Mac packages don't use installers, and those software installers usually don't (nor should they) alter system directories, while all package manager packages do this (unless they install to someplace like /opt). In practice, then, Linux is more likely to have packages messing with the system, which leads to more chances for (even accidental) breakage.
Now just one or two programs installing extra copies of Qt is fine. But what about dozens? That starts to add up. Restricting development tools to only what Apple distributes is an extreme hindrance to porting software.If Apple sees dozens of apps using Qt, they will probably consider including Qt with their next system update. (And they'll be getting lots of calls to do so.)
It's almost like Apple never expected anyone but themselves to write a common application component.Replace "common application" with "system" and I think you're absolutely correct. Apple makes an effort to keep control over the system and actively discourages touching it, which means less chance of some application writer coming in and potentially messing up my system by accident. +1 from me. :)
Apple does have frameworks, and you can install them in many places, including "system-wide accessible" or per-user-accessible locations. So, if you wanted to, you could write one of those "evil" scripts that checks for the Qt framework and downloads it and starts the installer if it doesn't exist.
But I'm figuring you think it's just easier to bundle. As a user, I'd rather have a "complete" package even if my download time's a bit longer, anyways. It's just simple to bundle, and I doubt you can show many occasions where bundling has really hurt a user's system. And there's no doubt it's more error proof and easier to maintain than a package management application and package repository. Apple can spend the time and money that would have gone towards that system improving their software instead.
So we're back to, is this a real problem for users, or do package managers just really call to the software developer's desire for maximum efficiency even at the cost of a complex system which must be constantly maintained? :)
These are basically applications that work on Mac but want/have to use Unix-style installation. They probably have hardcoded Unix path assumptions for dependencies which is something that doesn't need to be done on Mac. They could have packaged it better, and easier, they just chose not to. And they don't really have to because their target audience is software developers, many of whom are probably Unix developers.
The fact is that a simple package management system like OSX's works well for simple package management issues. Linux has a vastly more complex web of packages than either Windows or Mac and thus their simple solutions aren't appropriate.That's not true. What's inappropriate about making installation simple (or simpler)? (Or are you assuming it can't be simplified?)
The reality is that Linux *exposes the user* to a vastly more complex web of packages than Windows or Mac does. Go file by file through OS X or Windows' system folders and see if it's complex. I guarantee you it is. It's just that, unlike Linux, they don't take their system and break it into 1000 little components, which you are allowed to individually install or not install. In short, the complexity is hidden from the user rather than dumped in the users' laps. It isn't that Linux "just is" more complex, it's that it was explicitly designed that way. And I think that's a major problem for desktop adoption. (It's the primary reason I don't use it.)
In short, you're saying that some packages are "simple" or "complex", but really what differs is NOT the complexity of the packages (after all, Final Cut Pro, not to mention Tiger, is probably pretty complex but is a simple install), but the complexity of their installation procedures.
Why not a two-pronged approach? Some people and businesses want to take control of their OS, some don't, or, more accurately, they can't afford to. After all, when you talk about the better deal, is there really one 'better deal' for everyone?
It seems to me that the better deal for the Enterprise is control and customizability. Linux has, IMHO, got this covered pretty well. People can build their own distro off of Debian, LFS, or other distros, quite easily and take control over what is installed and what the users can do with it. This is good also for kiosks, PDAs/embedded devices, and other devices that provide a controlled experience to the end user. Not to mention hobbyists. :-)
But I don't feel this is the better deal for the home user, or the small to medium-sized business. The better deal for them is something that minimizes complexity and maintenance, and maximizes productivity. They want things to work "out of the box" and would even do things like upgrade their machine rather than hire a consultant to tweak the distro to their needs. Workers in many of these environments take some degree of responsibility over the maintenance of their computer, so it has to be very simple to understand and maintain for non-tech users. I don't think there's any Linux that actively targets these users yet. It's obvious lots of people want Linux to target this market though.
Well, those are just my thoughts on the matter, but there's lots of organizations out there like this; in fact, there are probably tons. (I work for one.) Get Linux into this market and IMHO it'll really take off, but so far I haven't seen people doing to Linux what needs to be done in order for us (and organizations like us) to adopt it. ;-/
But on Mac, users and developers alike do not need to worry about any of this, which by default simplifies issues. It may "magically" work (when it does work without effort, and in my experience it doesn't always work), but it doesn't change the fact that Mac developers don't need to deal with dependency systems and Mac users never even have to fathom the possibility of a missing/conflicting/etc. dependency. No tool and database to maintain, update = no chance of it not finding dependencies, restricting installation of certain packages, and otherwise getting in the user's way.
No, it's not perfect, because you can still get that "untrusted" message. But how is OSX any better, especially when it's completely silent about "untrusted" applications?OS X is better because you never deal with adding URLs to a repository, for starters. Users will already be confused as to why they have to add a URL to a "repository" (whatever the heck that is) and now the system is prompting them with a warning that suggests they might be doing something very, very wrong. All they want to do is install some software. Why does it have to be so confusing?
OS X does warn you before running programs for the first time, but it's in the context of downloading a file, not in the context of "setting up their repository", and the warning is also in plain English, so the user can get a good idea of why this might be harmful and what they may want to do.
You also end up with huge redundancies. Something like KDE which would normally take a few hundred megabytes of storage now takes hundreds of gigabytes. Instead of one copy of Qt and kdelibs you now have hundreds. And double the size for every additional user installing it.Have you never seen a system that doesn't use a package manager? Are you familiar with how they work? Look, I never suggested distributing the whole system/OS with the application, or everything above the Linux kernel. You might want to look at OS X. (Read up on it if you don't have it.) Nobody distributes Cocoa/Carbon/etc. with their application because those programs are *guaranteed* to be included with the OS. In fact, there's also Python, Perl, wxWidgets, and a whole slew of other tools that come with OS X out of the box, installed on every system. They aren't "options", they are automatically installed. I hear very few people complaining about the disk space they've "lost" to these components.
In short, on OS X there's a clear line between what is available on any Mac OS X system, and what you have to bundle yourself. Every software component is one or the other. Any free library expected to be found in more than a few applications should be included, by default, as part of the OS, and Apple often does this. The result - no complicated "dependency checking" system needed at all, and at the same time, small application bundles! It's brain dead simple to understand for developers, and they don't need to put dependency logic into their packages. Disk space is cheap, people's time is not. Which would you think the average user and developer's more interested in maximizing?
You hit the nail on the head about support. However, every Linux vendor doesn't need to adopt this, just one does. We're talking about distribution of binaries, and it's not like RedHat binaries run on SuSE or Mandrake or Debian. Package creation will be much easier, meaning that developers will be more likely to actually create packages. Other distros will get left behind (or have to recruit/hire more and more packagers) as more and more developers get comfortable with just building a binary and plopping it on their web site/SF site, etc.
In fact, the interesting thing is that if one vendor succeeds with this, then it'll force other vendors to adopt it, forcing them to - in turn - adopt a standardized set of "system components" as that's the only way things will work. Make the change, and the standard will follow. Don't wait for the standard to make the change. If I had some resources I'd build a distro like this myself because I believe it'd open Linux up to whole new markets and I do believe such a thing could be sold.
Yes, you're right that it depends, but we're talking about Linux on the desktop. Most people I know replaced their Windows with Mac, and don't know anything about Unix. These are all 'potential' Linux users. The users you're talking about are Unix/Linux converts all ready. They probably have little problem dealing with complexity.
Everything else is pretty much ignored, And of course, you are still missing out on understanding how complex Unix applications can get.I'm not missing out on anything. I'm a software developer who uses Linux. I KNOW how complex it can get, and that's precisely why I don't use it except when I have to. The thing is, if Unix apps are so complex, then that's a problem that Unix apps will need to find a solution to if they want to win over new users, because I don't have that complexity on Mac, even when dealing with things like HD video production and 3D modeling software. Does it really need to be this complex?
To users, they're one and the same. i.e. take my comment about adding a URL to the repository, or not being able to find packages (that exist somewhere, just not in the package manager database). The inner workings of apt-get have forced an implementation detail to be part of the interface. The inner workings have thus 'complicated' the software interface. So users are going to confuse the two, and it's why I phrased my argument the way I did.
As for the interface: a drag'n'drop interface for apt is abolutely feasible. It could be, and perhaps it is already implemented (I don't know, since I would not use it anyway).I'm not sure how a drag and drop interface for apt-get would look, but the fact is that I have a great experience on OS X *without* apt-get. What do I need it for again? I've been using Mac (and developing software on and for it) for 3-4 years now.
If developers bundle non-system dependencies or statically link them, the need for apt-get or similar tools basically disappears. As awesome as the software is, it does something that on Mac doesn't even need to be done. This makes life easier for users AND software developers alike. I've tried packaging for Linux, the learning curve is several times higher than Mac or Windows.
And I did not bash OS X, I've just observed that their solution is a really simple and limited one. Using it instead of the Debian system would not solve any problem but create lots of additional ones.What complaints have you heard from Mac users about this system? Particularly, ones that aren't Unix developers? I've heard none. Unix developers can use Fink or DarwinPorts (though I just use source tarballs), but when we're talking about "Linux on the desktop" we're talking about converting people who aren't Unix developers, obviously. So from your arguments so far, the problems for desktop users that you suggest exist are theoretical ones, at best. To me, that's not a solid argument against OS X's packaging system, it's just "name calling". (obviously, "dumb" doesn't have positive connotations and suggests deficiency)
Unfortuntately, it is just this kind of logic that keeps Linux from moving forward. I use an "apt-get" free system every single day and it causes me no problems whatsoever. So why should I learn apt-get? Why should I install it? Why should I deal with it? These are the questions you have to answer for potential Linux converts, who will have to use apt-get, or RPM, or portage, whether they want to or not.
And, finally, you haven't answered the converse question - why NOT use OS X's approach on Linux? "simple and limited" say nothing. Explain what problems users on OS X are having and how apt-get would solve those problems, or, at least consider that maybe OS X's system is a better solution than you suggest it is.
I realize this could start a 'flame war', but it surprises me how many Linux users just don't see why package managers are not the greatest thing since sliced bread for average users.
While you and others may go "wow!" at all the magical stuff apt-get does, the average user doesn't even know what dependecies are, nor do they care. And they don't want to care. On Mac, as "simple and dumb" as the OS X system is, it *just works* for everyone from grandma to geeks. A simple and dumb system is also, well, very easy to understand! Drag and drop your app into the folder. Easy. Nice. As for package managers, I've had to deal with scenarios where I had to muck with the package manager configuration to get it to install packages for me, and I've had to "add URLs" to the database at which time I was warned about "untrusted sources" (the average user is NOT going to grok all that). In fact, when the average user sees "no results" from the database, they'll simply conclude the package isn't available and stop. I'm not sure how anyone thinks this is easier than going to versiontracker.com/apple.com/etc. and just downloading a file (or popping in a CD), then dragging the app into the applications folder.
If you doubt me, have someone do usability research on package managers and drag and drop installs, and see which is, on average, easier for users to understand and get working with. If you really think package managers like apt-get will come out ahead, then you must spend a lot of your time on the computer and deal regularly with others like yourself.
If you really want the Linux desktop to succeed, you have to question why lots of people are switching to Mac instead of just 'bashing' anything that is not as complex and elegant as apt-get. Call it dumb, call it simple. I call it a solution that works, and considering Macs are seeing a 40% growth this year, so do a couple other people as well.
As someone whose tried every Windows from 3.1 to XP, close to a dozen Linux distributions (including Debian and Ubuntu), and OS 9 and OS X, I have to say application installation and removal on Mac blows the others away. It works and it's brain-dead simple, which means I spend more time doing real work than fooling around with installers and packaging programs. Good luck on converting the world to apt-get, though.
Every president before Bush *did* keep supporters on the panel regardless of their political affiliation. Check the link.
So, yes, it is different from what any other US president has done. And this organization was formed in 1923 so it is a clear and established precendent that Bush has broken. You might want to ask yourself why no previous president has ever done this. Aren't you the least bit curious?
IMHO, we're heading way outside of "politics as usual" here and in other recent matters in both the administration and Congress. But I guess some people will simply choose to be apathetic to it no matter what happens...
Actually, assuming something that I found to be better than the iPod came out, what I'd do is just rip CDs of my music and re-rip them into my new software. Yeah, it's a pain in the ass, but let's be realistic here - any major vendor who wants to make it in the music business has to play with the big 5, and that means DRM. Apple's is actually about the best DRM of the bunch. (And FYI, I don't have any info they've engaged in *any* monopolistic behavior.) The key in my mind is that Apple's ease of use and simplicity sold me. They provide such an excellent service compared to other vendors that I don't mind being "locked in" so much. Apple isn't forcing me into their system; I chose it, warts and all. (Because the other players offer choice, but have their own, IMHO nastier, warts.)
And speaking of fair, how fair is it that we legislate to Apple that they have to take all the great products that they developed using lots of time and money and start sharing them with their competitors? Their products are their "competitive advantage", and it's how they make money. The fair word is one of those generic "feel good" arguments that doesn't measure up in reality. Fair to whom? Certainly not Apple. It wouldn't be fair to all the engineers and testers and graphics designers, etc., etc. at Apple who slaved over making all this stuff work simply, effectively and seamlessly. How is this "fair" to them? Why do you deserve open access to their hard work? Since when did Apple products and services become a public good?
I think letting the market decide is fair to *everyone*. If customers and the market want them to open up, then they can provide pressure - buy other players and other services. That will give Apple a (big) incentive to open up. I'm not saying I wouldn't like to see Apple's format opened, I'm saying that no one but the market should be asked to decide it. Congress should not be getting involved because Apple hasn't done anything *illegal* or ethically wrong to harm the other market players. They've just been fiercely competitive. If Apple's competitors have a problem with Apple's behavior, well, make a product and service which tears them a new one! Why isn't this the "fair" way for the market to tell Congress (and Apple's competitors) what they want?
So, by all means, support open standards. More power to you! But don't *legislate* them on every vendor whose products become an overwhelming success. Legislature is for when the company has done something illegal, not for when they're the biggest kid on the block. IF Microsoft had never crossed the line between being massively successful and being a company hell-bent on blowing competitors out of the water for good, I would be saying the same thing for them. (As unpopular as that may make me on here. ;-)
Also, it's not nice to generalize with terms like "you people". I don't know who "we" are. Who are you people? ;-)
Regardless of market share, Apple does not behave like Microsoft at all. While Apple has popular market share for iPod, it is not using that market share to *exclude* competitors. For example, it doesn't attempt to force vendors who want to sell iPods to exclude other players from the market, or threaten retribution to those companies who sell competing products. It also doesn't say that if you sell iPods you must also put Macs on your shelves, etc.
Microsoft, on the other hand, has done pretty much all of these things at one point or another in their history. Consider their OEM agreements with vendors forbidding them to sell computers with other OSes. Consider their attempt to drive Netscape out of business by giving away IE and "integrating it with the OS" (and letting the product stagnate as soon as the competition disappeared). These acts show a company trying to take choice and competition OUT of the market, not providing a BETTER choice. And that's the difference.
All the installer needs to do (and many installers already do this) is create a log of files installed, and uninstall only those files. Look at Unix; if they nuked /usr/local everytime someone uninstalled an application... But that doesn't happen, because the installers on those platforms keep track of what was installed where.
An uninstaller *should* do what the user expects it to, which is just uninstall the program, no matter where the installer put the files. If it's too much work to undertake in the short term, as a stopgap, they could do something like forbid installation into C:\ (or any root prefix). But just calling the user stupid doesn't help Mozilla any. Most commercial apps do these sorts of things just fine, and if open source apps want greater acceptance in the marketplace, they should too. (Note that with my suggestions above, no "dumb user" warning messages needed!)