Slashdot Mirror
Could Apple's Intel Desktop Threaten Linux?
esavard writes "
If Linux enthusiasts don't want
Mac OSX on Intel to become a threat
for the future of Linux Desktop, they must rethink the concept of Desktop as we know it today.
Symphony OS did exactly that and propose some fresh concepts about how a desktop should and should not be.
If you want to know more about Symphony OS, a good starting point is a Wikipedia article
describing the innovations proposed by this new desktop OS. The Linux Desktop Community must encourage such initatives
massively to compete against Mac OSX and Windows."
Is it just me, or does the Symphony look a great deal like the Apple Lisa and other early attempts at GUIs? I'm not saying there isn't anything to see here, but it reminded me of screenshots of the Lisa interface.
We discussed this earlier this week when Dvorak trie d to piss on everyone's parade with the same opinion.
It was BS then. Its BS now. All Apple on x86 does is give street cred to the idea of switching away from the Bitch from Redmond. Eveeryone else benefits at that point.
In other news - the sun shines, the earth rotetes, life goes on.
After all, Intel OS X will probably only run on Apple computers (although I think there will be a hacked version, possibly using OpenDarwin, for the pirate market). And while OS X is a damn nice desktop OS, it doesn't really cater to the same audience as Linux. I use Linux only on my Mac, not only because it performs better, but because the apps I wanted to use all work in X11, but not all of them are ported to Aqua.
Mobile devices are the future:
Here are some market stats for the first quarter of 2005:
Mobile Phone Handsets:
170 million units sold (19% growth YTY)
PCs:
46.2 million units sold (11% growth YTY)
iPods:
5.3 million units sold (558% growth YTY)
PDAs:
3.4 million units sold (25% growth YTY)
Video Games (Portable):
3.8 million units sold (72% growth YTY)
Volume rules...control mobile platforms, and the desktop comes for free. That's where Linux UI developers should focus their efforts.
Nooface
In Search of the Post-PC Interface
By the standard applied above Win XP's 'package manager' isn't ready for the desktop
Ok, for one, that's just putting words in my mouth. I never said that any package systems "were not ready for the desktop". I said that package systems create a dependency hell in complex systems that's just as bad as DLL Hell.
Secondly, my post pointed out that Windows tends to fall flat with mislinked associations, broken application, and other "minor" issues that are quite annoying to users.
Thirdly, *what* Windows XP package manager? The closest thing Microsoft has to such a beast is the MSI format. And that's not so much a package format (where package format is defined as a standard structure to track dependencies and thus maintain system integrity) as it is a standardized installer archive. And even then, I've met a couple of programs that I couldn't install because something was screwed up in the checks done by the MSI or Installer program.
Javascript + Nintendo DSi = DSiCade
I think that x86 Mac is attempting to threaten Linux. Apple is a very Linux unfriendly company with no moves to support anything that smells like linux. rather they are pushing their Open Source concept Darwin. Marklar (secret OSX/X86) program has reportedly fed enormously on the Darwin project and will continue to do so. By pushing their apps on a mass market platform it is obvious that the Apple digital lifestyle (iLife etc..) is coming to a Joe Bloe near you. Whether they will succeed to put a dent in Linux remains to be seen. For many commercial users OSX on X86 will be a great alternative for Windows and that is the main market. I would suggest to many x86 users to consider the move sincerely. However, as a recent x86/linux to Mac/PPC switcher I must say I am unhappy as I feel left in the cold. Not only has Linux/OpenSource on PPC been a slow mover, it now looks dead in the water. All future developement will be on x86 and even Bill Fink will have to acknowledge that much of his efforts have been in vain.
... OSx's future is 32 bit and not nearly as OpenSource as their drumbeating would suggest..Why heck even Linus was using a PPC64...
Oh well, my macs will be up for grabs (to be shoved up Stevo's you-know-what) as I move back to Fedora on 64bit.. I wanted OSX because it was 64 bit and Open Source.. I was a sucker, I believed the marketing
-if at first you don't succeed, stay the heck away from paragliding.
Can someone explain me what makes MacOS X running on Intel-based Apple hardware any more of a threat to Linux compared to MacOS X running on PPC-based Apple hardware?
Supposedly Intel processor makes Apple somehow better? What is it, speed? What else? But then, does this mean that the Linux community is filled with people who don't use MacOS X ONLY because Apple isn't making Intel-based Macs? I somehow find this to be hard to believe.
The fact is that the Linux GUI is constatnly approaching "Apple Quality" and it will only be a metter of a few years before it gets there. Apple is trying to position themselves so that they can skimm off the top of the Linux boom and cut out a niche for themselves.
True. I was running out of time, so I ended up shortening it to "the OS must promise a specific set of APIs". What I was trying to get at, is that nearly all APIs that are useful to multiple programs that you may have installed (i.e. I probably won't have two Word processors, so sharing Word processor specific APIs is pointless) tend to be provided by the OS vendor. Apple handles this via the use of "frameworks", a package similar to APPs. The catch is that only Apple tends to distribute these frameworks. As a result, Apple has made themselves the only source for system wide APIs.
And that's a very lovely idea and will make for very easy packag installation. It is not something you'll ever get on FOSS Linux however. The FOSS software community improves it software in an evolutionary sort of way - you get a whole lot of different versions of basic libraries and tools, and eventually you get some consensus on them. The key is that the whole system can be overturned - perhaps E17 will turn out to be truly amazing and a shift will occur, perhaps Y-Windows will get completed and turn out to be well worth pursuing... the point is that these decisions are made not by corporate management, but simply by what manages to get the most hackers interested in and coding for/with it.
What I'm really trying to say is that FOSS is utterly chaotic, but draws strength from those chaotic qualities. What you're talking about is eliminating some of that chaos - and I think there's certainly merit in that idea, I just don't think it will mix well with FOSS. If you want a organised mandated structured set of required libraries and APIs use Apple (or start your own OS). If you want the masses of software and vitality of the FOSS world, you have to accept a certain amount of chaos in return. What we need is better mays of managing that chaos: I don't think we can eliminate it.
Even singular repositories screw up. A few years ago when I tried Debian, I ran into dependency hell out of the main repository. That wasn't supposed to happen. I've even had it happen in my favorite repository, the FreeBSD ports tree.
But things are getting better. Check out Smart a new dependency resolver with far better algorithms than apt (along with more flexibility at the backend package level). As I said, I don't think you can eliminate the chaos, but you can do a lot better job of dealing with it.
Repositories are useless for commercial software. I understand that OSS developers think everything should be free as in Airplane Peanuts, and free as free to go to a Hawaian Backyard Party, but there are still plenty of examples of commercial software that can't go in these repositories.
And that's where things like Autopackage come in. As long as your base libraries are managed by something like Smart, then Autopackage is fine for those 3rd party extras - it will use the libraries if you have them, but it can grab whatever else it needs if you don't.
Don't fight FOSS's strengths, instead figure out how best to cope with the weaknesses that are the flipside of the strengths.
Jedidiah.
Craft Beer Programming T-shirts
I don't understand why everyone seems to think KDE and Gnome are so unusable. They both seem very usable to me. In fact, I get around more easily in KDE than OS X. OS X is just more "pretty." I prefer KDE to Gnome, but I can certainly use Gnome just fine. Why do so many people buy into the OS X hype? Not that OS X sucks.. not by a long shot. I use it every day and enjoy it (love would be an exagerartion). Really though.. what makes desktop linux so bad? Everybody I know who has tried and taken the time to learn it ends up enjoying it. It's only those not willing to try or don't want to learn something new that say it sucks.
Thanks for responding, Bruce.
:-)
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.
The part that boggles my mind about this argument is that the Cathedral already exists. Distro maintainers that use central packaging systems have already agreed to be that Cathedral. If they could leverage that Cathedral slightly more (e.g. a standard API base), then there would be less work and fewer frustrations for everyone.
Javascript + Nintendo DSi = DSiCade
See, that's the issue. Programs should come as one single file that can be conveniantly added or removed. Drag and drop. Installing a program should never ever involve updating system files or altering any other applications files. There should be no "Package Managers". Microsoft doesn't get that. The Linux crowd doesn't get that. Apple, I think, wants to get that, but that's all a long ways off.
bance.net
The part that boggles my mind about this argument is that the Cathedral already exists. Distro maintainers that use central packaging systems have already agreed to be that Cathedral. If they could leverage that Cathedral slightly more (e.g. a standard API base), then there would be less work and fewer frustrations for everyone.
I'm really not so sure that would work as well as you suggest. Many of the distros survive by letting you install as much or as little as you want, by letting use GNOME or KDE or XFCE or *box or play with dev versions of E17. The distros themselves work hard to remain flexible in what software they suck up and include in the distribution.
I'm sure, if you wanted to you could mandate a firm API - just don't expect FOSS developers to necessarily agree and develop against the paritcular APIs you chose. Try telling the Firefox crew to abandon XUL and use pure GTK+ or QT. Who knows where the next must have app will come from - maybe someone will develop a truly revolutionary new "must have" application using Mono - are you using Mono for your mandated API?
There is as much life and vitality in FOSS as there is because the developer can use whatever library, whatever API suits his or her needs. The distributions, in turn, keep an open and flexible system to make it easy to add new libraries or applications using new or different or otherwise obscure APIs.
Linux, I think, does as well as it does because it can rally such a vast array of applications, and it does that by supporting applications using the console, pure GTK+, QT, GNOME, KDElibs, FLTK, Edje, XUL, Mono, or whatever takes your fancy. Apple does well because it has cornered a niche and has a pretty guaranteed market, so plenty of people are willing to develop for it - particularly in the commercial software for designers realm. Apple also gets support via Fink, but from what I gather that's back to the dependency management and lack of rigid APIs thatb you're complaining about. A new OS, or distro is not going to get much use if it can't get enough applications - if you can't promise a market like Apple can, and you can't promise freedom to develop however you like as Linux can, well... I suspect you end up like BeOS and NeXT, just hoping you can get bought out by someone bigger.
Jedidiah.
Craft Beer Programming T-shirts
If developers DO require more functionality, they can put that extra code into libraries that are inside the application bundle
/usr/local/lib just like every other Unix. It has library dependencies and LD_LIBRARY_PATH just like every other Unix as well.
.pkg scripts to install things into the right places on the hard drive.
OSX has
If you need libraries you're going to have to install them. OSX might want you to put everything into a single statically linked binary but it really doesn't work that way, except for very simple applications.. that's why you build
Unfortunately because there's no uninstall your hard drive gets clogged up with all the apps you've installed and you eventually have to reformat. I've had to do this twice since I got my Mini due to libraries and whole applications sticking themselves on the disk and unable to remove them.
Ah, but you miss the point of OS X's simplicity.
There is nothing "simple" about having a different package upgrade mechanism for every program.
If developers DO require more functionality, they can put that extra code into libraries that are inside the application bundle. Since it's usually very application-specific code, it's not going to be something that other apps are going to need/want, so there's no issues with wasted space due to non-dynamic libraries.
You're confusing cause and effect. It's not that Apple has magically figured out which packages make most real-worlddevelopers happy, it's that Apple's developer and user community has become reduced to a group of people that happen to be happy with very little. For a regular UNIX user, the Macintosh is painfully limiting.
I believe Debian's apt is great for system-wdie upgrades, but if individual users want to install programs (ie, in their home directories) autopackage is the way to go. it'll allow you to install any autopackage in your home directory. What's even better is the package manager is contained in the package archive meaning there is no software to install to allow you to install autopackages. everyone should check this out. give it a shot by installing one of the autopackages available on the autopackage website. www.autopackage.org
I've thought about this occasionally. I'd agree that a monolithic repository system is not the way to go. It still doesn't solve the problem of being able to just download a piece of software and just being able to install it without problems. Debian fares no better than RPM-based distros in this respect, and installing core packages is no problem on either of the existing distros' architectures.
A solution that seems to make the most sense to me, which nobody seems to have tried yet, is the following:
Don't rely on one big repository (e.g. debian, gentoo, etc.) but also don't make the whole thing file-based like in OSX. Do keep repositories if you want, but in addition to having a bunch of basic repositories, (e.g. Ubuntu vs. Debian Unstable) you also put information not only on what other packages are required, but also how to get those other packages into each package.
For example, this could be done by pointing to a bunch of mirrored URLs that point to some XML data describing the package at that mirror. The installer could pick the most recent version, choose the fastest mirror, whatever.
Additionally, some sort of 'compound packages' would be useful. That way, you can ship rare libraries directly with the application. They may or may not be installed once downloaded, depending if you've already got the same or a newer version of them on your system. This could be especially helpful for systems that don't have internet connectivity. (gasp!)
Sure, it's not perfect, but it beats RPMs (I use SUSE so I experience this myself) and the debian system any day, because you can just go and download packages off the internet and install them, without having to go and hunt for the dependencies yourself. Most likely whoever made the package actually had the necessary libraries installed (and the package system can remember where he got them from!) so all that is needed is to convey that information to the user's system.
The case where it breaks down is of course when all the mirrors eventually die, for example if a package ends up becoming unmaintained. But if it's not been updated for that long, it and its dependencies could be added to the various monolithic repositories. I'm sure organisations would pop up that would keep 'dead' packages around for people to use. The way to combat this would be to have as much redundancy as possible, of course.
I don't know. It might just work better than what we've got at the moment?
~phil
Thirdly, *what* Windows XP package manager?
The thing that you can find in Control Panel > Software. It's far from perfect, but at least it lets me see all the installed software on a system and remove it with a single mouse click. It's not as nice as Linux package managers, but it's a whole lot nicer than Macintosh, where I have to go hunting around the file system and can never be sure whether dragging the application into the trash will actually remove all traces of it (in fact, it won't).
Secondly, my post pointed out that Windows tends to fall flat with mislinked associations, broken application, and other "minor" issues that are quite annoying to users.
Macintosh and Windows both permit, but don't require, applications to modify global system directories on install. Applications that do will be susceptible to this on either platform. So, there is no intrinsic difference between Windows and Macintosh in this area.
Having said that: If Linux doesn't come up with a live search technology like Spotlight in OS X, the personal desktop aspect of it is dead in the water. "Tiger" comes with a lot of hype (I am completely underwhelmed by Automator, for example) but Spotlight is awesome. Together with the Neolight plugin for the OpenOffice format (thanks for the quick work, guys!), live search has changed the way I use my computer in a very basic way. Want to listen to a certain song? Just type in the name. Need somebody's telephone number? Just type in the name. It takes a while to get used to, but after a while it becomes the interface of choice. For those of us who don't like mice (regardless of how many buttons they have), it is bliss.
So, there is simply no way I will be using an operating system for my desktop anymore that doesn't have this function. Unfortunately, and this is where I wonder if Linux can cut it, because Spotlight seems to involve changing the code of very basic Unix commands like cp to work. How is Linux going to make that happen? The patch would seem to apply not only to the kernel, but also to user space programs that are outside of the kernel developer's control. And remember, Spotlight also works from the command line, too. This is a biggie.
I'm really wondering how this is going to get into Linux.
If there is OSX running on x86 there will be a patch to run it on a PC 10 days after release.
If Microsoft could not stop people for running Linux on the Xbox, even with full control of the hardware, what can Apple do against someone making a patch to make it run on PCs..... !!!?????
Thats much easier to do, and probably you will not require a modchip, and if you think you need hardware to emulate the firmware, then someone will make the hardware mod.
In conclusion, if OSX is released for inteles, it will run in regular PC's sooner than later. I bet you there will be dual boot PC's in a few months afterwards. I hope Steve Jobs is considering that.....
-Ale
Admittedly I'm a reluctant user of OSX, having to use it at work from time to time and haven't spend more than a couple of weeks working with it. From the outset, a useability deficit was immediately apparent; OSX still hasn't provided a means of finding software and delivering it to the user.
How depressing it was to find that Apple users are still stuck with the oldest problem in software installation, and that is finding the software first. Windows users considering switching will find this to be as depressing as it was on win32, and similarly we hear Mac users that have moved to Linux cheer endlessly about the ease of software installation using a system such as apt.
So boring it is to spend countless hours trawling around websites looking for software, and there's so little on the machine out-of-the-box. OSX really doesn't push much further than the windows paradigm in this regard. There's this fink but last time I tried it was all a bit hacky and suffered issues worse than those in any Linux distribution I've used.
In short, nothing I've tried comes close to software installation in Linux; Linux brings the software to me.
Where the *.dmg is concerned, while convenient (once you have actually found the bloody thing), it is certainly not unique to the Apple platform. Linux already has two perfectly good solutions to this would-be problem.
One is http://autopackage.org/, and a completely different approach (and quite impressive) is Klik http://klik.atekon.de/.
Then again last time I looked searching for a package and clicking the conspicously named "Install" button in Kpackage or Synaptic seems to suit vast numbers of lazy, or just plain busy Linux users out there.
The beauty of Autopackage is, as a developer, I can make one package for all distributions of Linux. With Klik, I only 'install' the software for that session (in fact it is run from cache).
I found a nice and detailed review about SymphonyOS on this site.