Forgot your password?
typodupeerror
Operating Systems Software Linux

Could Apple's Intel Desktop Threaten Linux? 818

Posted by CmdrTaco
from the not-bloody-likely dept.
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."
This discussion has been archived. No new comments can be posted.

Could Apple's Intel Desktop Threaten Linux?

Comments Filter:
  • Beautiful (Score:5, Insightful)

    by AKAImBatman (238306) * <akaimbatman@@@gmail...com> on Wednesday June 08, 2005 @10:03AM (#12757023) Homepage Journal
    After looking at the screenshots, allow me to be the first to say: Wow. That's so beautiful, it brought a tear to my eye.

    The one thing that stands out at me is that Symphony uses Yet Another(TM) packaging system that is supposed to fix all the woes of the previous packaging system. Haven't we learned yet? In a complex system, packages are just as bad (actually worse) for users than DLL Hell. And they certainly don't solve the issue of maintaining the sanctity of applications, and maintaining file associations across deletes/manual installs/program moves. These are some of the greatest break points in the Windows OS. Yet Mac OS X has none of these problems thanks to its amazing .APP application scheme, and IOKit interface which tracks files by INode instead of path.

    Under OS X, installation consists of downloading the application, and optionally extracting it from an archive. That's it, nothing more. You can run the app from any location (although the "standard" is the Applications folder), including right out of the DMG archive! File associations are easy: Just have the program on your hard drive. That's it! The OS takes care of querying the program for its associations. If you move the program, the OS knows. And if you delete the program, the OS removes the association. No mucking around with manual configuration. The *only* thing you can change is the default program!

    Given that OS X has shown us the power of this method, why haven't any distros latched onto it? Yes, it means that the OS must promise a base set of shared libraries, but the user experience is so much better!
    • Re:Beautiful (Score:3, Informative)

      Given that OS X has shown us the power of this method, why haven't any distros latched onto it? Yes, it means that the OS must promise a base set of shared libraries, but the user experience is so much better!

      Well, you can get a similar experience by using static binaries. They have the libraries compiled into the binary and have no other dependencies. The downside is increased disk and memory footprint. Also if there is a vulnerability in the library it uses the entire binary must be recompiled. Per

    • Re:Beautiful (Score:3, Informative)

      by dabadab (126782)
      "[i]In a complex system, packages are just as bad (actually worse) for users than DLL Hell.[/i]"

      I think you have missed something.

      Packages are a GREAT way to handle things.
      The simple & dumb way as OS X handles packages is just that: it can not handle dependencies, or anything, it just puts some files on your computer.
      It works moderately well, if you only use it for applications and those are statically linked, but nothing else.
      Now, take Debian's package system: it handles dependencies, version conflic
      • Re:Beautiful (Score:3, Informative)

        by Sentry21 (8183)
        Ah, but you miss the point of OS X's simplicity. The standard OS X development environment provides the vast majority of functionality that programmers require to make all but the most complex applications. There's no mucking about with 'this application requires libpng 0.4.20b and libpcap 2.1.2' as on Linux, or 'this application requires msvbvr70.dll'. An application requires Mac OS X Panther or Tiger or 10.2 or somesuch.

        If developers DO require more functionality, they can put that extra code into librar
        • by Saeger (456549)
          "This application requires Linux Standards Base (LSB) 3.0" ... ah, who has time for that standards crap anyway.
        • Re:Beautiful (Score:3, Interesting)

          by Tony Hoyle (11698)
          If developers DO require more functionality, they can put that extra code into libraries that are inside the application bundle

          OSX has /usr/local/lib just like every other Unix. It has library dependencies and LD_LIBRARY_PATH just like every other Unix as well.

          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 .pkg scripts t
          • Re:Beautiful (Score:5, Informative)

            by javaxman (705658) on Wednesday June 08, 2005 @12:41PM (#12759075) Journal
            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..

            1) 97% of all applications fall into the "very simple applications" category, if needing libraries not already installed with OS X is your metric. The point the parent was trying to make is that Apple errs on the side of providing everything by default- they've given up on trying to keep the OS footprint small. Unless it's code specific to your app, it's likely already provided. Please provide an example if you want to refute that point- maybe there's something they should be including that they don't.

            2) It doesn't actually have to be a single statically linked binary- that's just what most programmers do, because it's simple, and easier for the user to manage if you have everything self-contained in the application package. If you want, you can create your own application frameworks, and place them in standard locations ( not /usr/local, but rather /System/Library/Frameworks or ~/Library/Frameworks ). Frameworks have certain advantages ( versioning support being just one ) over standard dynamic libraries, and they're quite easy to use. Most OS X programmers don't do that because, well, they don't want to have to write an uninstaller.

            Just because OS X is 'like Unix' doesn't mean that's all it is. I don't even want to know what you're doing to your mini that you've felt the need to reformat and reinstall twice. That's just crazy. May I recommend Fink for your Unix-ported program needs? The /sw directory is an excellent idea...

            I've seen prepackaged binaries ( generally of ported Unix apps ) which write into /usr/local, and I have to say I personally dislike that practice. That said, if you choose to go that route and use /usr/local, managing it is no different than under any other OS- you have to do it yourself.

      • by kollivier (449524) on Wednesday June 08, 2005 @11:36AM (#12758235)
        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.

      • Re:Beautiful (Score:4, Informative)

        by myov (177946) on Wednesday June 08, 2005 @12:24PM (#12758863)
        Mac OS X has a package system (.pkg) with a gui installer. However, Apple encourages developers to build an app that can just be copied to /Applications, rather than building a package. It's easier for the end user, and easier to keep the related files together - avoiding the "what app installed /foo/bar?" question.
    • Re:Beautiful (Score:5, Informative)

      by Bruce Perens (3872) <bruce@perens.com> on Wednesday June 08, 2005 @10:17AM (#12757188) Homepage Journal
      The main problem with package management is managing dependencies upon other packages. The installation system you write about is elegant, but you don't describe how (or if) it fixes that problem. Most naive-user packaging systems fix the problem by including the kitchen sink (all applicable DLLs) in their own package to reduce dependencies. Debian's package system works fine for their users because there is one huge repository with management of the proper cross-dependencies within that repository, rather than many repositories with little coordination. Once you add repositories, they go out of phase and the problems pop up.
      • Re:Beautiful (Score:5, Informative)

        by AKAImBatman (238306) * <akaimbatman@@@gmail...com> on Wednesday June 08, 2005 @10:46AM (#12757518) Homepage Journal
        Hi Bruce!

        The installation system you write about is elegant, but you don't describe how (or if) it fixes that problem.

        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.

        It is of interest to note that the same is true of Windows. While the ability to install system wide DLLs exists, the reality is that only Microsoft tends to distribute anything that's useful for multiple programs. Modern Linux distros have started down the same path with a set of default APIs, but they tend to fall flat due to a lack of standardization and incompatible library versions.

        For the APP concept to work on a Linux system, the system must promise a very precise set of APIs with precise minimum versions. Programs should be aligned along the use of this standard, with programs upgrading when the OS upgrades the standard. (Analogous to OS X 10.3 -> 10.4 and Windows 95 -> Windows 2000.) If a developer wants to use a newer version of an API or a non-bundled API, then he should bundle it with his program. It's possible that he's use up slightly more memory than necessary, but it shouldn't matter in the grand scheme as long as he doesn't try to replace the entire OS. (In which case, something is wrong with either the programmer or the OS.)

        Now traditional packaging systems are sufficient for core OS components like these. You *want* a consistent OS at that level. But at the application level, these dependencies (or more often, dependencies of dependencies) tend to get messed up and deny the installation of a program that will function correctly. There's no reason for this. A prelink can be done, and the program can gracefully error out if there's a problem. There's no reason to place the user through the teeth gnashing pain of solving those dependency issues.

        An excellent example of a system that manages to use this scheme is the Java Virtual Machine. Love it or hate it, programmers always have access to a specific set of APIs, then are able to add more as they're program requires. The only duplication of libraries tends to occur in places where the JVM had not yet added an API. (e.g. XML parsers, Logging, etc.) Once an API is added, then the number of duplicate libraries drops. Rinse and repeat.

        Is that a little clearer? (Not sure if I'm coming across too well.)

        Debian's package system works fine for their users because there is one huge repository with management of the proper cross-dependencies within that repository, rather than many repositories with little coordination.

        There's a couple of problems with this:

        1) 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.

        2) 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.

        3) There are still constant arguments over where to put things on a Unix system. The APP solution solves everything, as everything always goes in the APP folder. This is actually *closer* to the Unix philosophy of having a standard set of subfolders (e.g. bin, lib, man, src, etc.) inside every major folder. So if someone invents a new sort of meta-data (e.g. desktop icons, info pages, etc.) there would no longer be a question about where to standardize on their location.
        • Re:Beautiful (Score:5, Insightful)

          by Bruce Perens (3872) <bruce@perens.com> on Wednesday June 08, 2005 @11:00AM (#12757733) Homepage Journal
          Thanks for going into depth.

          This seems to boil down to an argument that cathedral-style management of all APIs relevant to third-party applications is necessary if they are to work. Certainly they will be made to work more easily that way.

          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.

          Bruce

          • Re:Beautiful (Score:3, Interesting)

            by AKAImBatman (238306) *
            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 agr
            • Re:Beautiful (Score:3, Interesting)

              by Coryoth (254751)
              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
          • Re:Beautiful (Score:5, Interesting)

            by pmjordan (745016) on Wednesday June 08, 2005 @12:00PM (#12758568)
            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
        • Re:Beautiful (Score:3, Interesting)

          by Coryoth (254751)
          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. A
    • There's already gnustep using exactly that package system. (Well at the moment most gnustep .apps are simply folders, but I think that's very easy to change). Look at how popular it is.
    • Re:Beautiful (Score:3, Interesting)

      by DenDave (700621)
      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 Li
    • Re:Beautiful (Score:3, Insightful)

      by ssj_195 (827847)

      why haven't any distros latched onto it? Yes, it means that the OS must promise a base set of shared libraries

      You just answered your own question :) Seriously, the need to guarantee the presence of a basic toolkit is the only real obstacle here - the rest is pretty much cake - just add a GUI wrapper around dpkg/ whatever such that the act of dragging an app somewhere installs it at the given place; create some kind of meta-deb/ RPM that contains its dependencies as sub-debs that are installed as a shar

    • Re:Beautiful (Score:3, Informative)

      by listen (20464)
      Your rosy eyed view of Mac OS X packaging is quite amusing. From someone who actually knows something about the issue, Mike Hearn of the autopackage project, in his own words [osnews.com]:


      Does the Mac fare any better? Unfortunately not. MacOS X has (in theory) totally eschewed installers in favour of App Folders, which are specially marked directories, the idea being that you simply drag and drop the app into the Applications directory. To uninstall, just drag it to the wastebasket. This is good UI, but bad everythi
      • Re:Beautiful (Score:5, Insightful)

        by AKAImBatman (238306) * <akaimbatman@@@gmail...com> on Wednesday June 08, 2005 @11:11AM (#12757877) Homepage Journal
        If I may be so bold, none of the "issues" leveled against the OS X APP system are inherent deficiencies in the design. For example, there is nothing that prevents a Linux APP design from adding installer/uninstaller hooks. And most installers on OS X are used for either upgrading system components (via auto-update), installing Unix components (which can't be APPed), or to manually build an APP from a highly compressed archive or tailored to the system. Nothing actually prevents such installers from being APPs themselves.

        I honestly have never understood this hostility toward the APP scheme. It's a good scheme, that actually *works*, as opposed to packages that constantly *don't*. Yet OSS developers just keep sticking their fingers in their ears and screaming "I can't hear you! La la la! I *like* having a completely unremovable mess of files across the entire system! La la la! I *like* the fact that I'm screwed if my package database should every get lost or corrupted! La la la!"

        It's just a... weird... reaction.
        • Re:Beautiful (Score:3, Insightful)

          by Ilan Volow (539597)
          I've found that geeks (especially OSS ones) are often unable to understand the concept of an engineering tradeoff that makes a sacrifice in program's technical elegance and efficiency to gain a better and more robust experience for end users. That's what the app bundle system basically is, an engineering tradeoff that Apple made to benefit users that placed a higher priority on usability robustness and consistency than efficiency and elegance of design.

          I liken witnessing OSS developers attack the app bundl


    • 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 d
  • by Craig Maloney (1104) * on Wednesday June 08, 2005 @10:03AM (#12757027) Homepage
    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.
  • by Adrilla (830520) * on Wednesday June 08, 2005 @10:04AM (#12757039) Homepage
    Interesting. An advertisment, disguised as an Apple article, disguised as a Linux topic. Interesting.
  • Wow.... (Score:2, Insightful)

    by Rod76 (705840)
    Its a really sad day when Mac OS X becomes a potential threat to one of its close relatives.
  • This is more than linux with a very very slightly different desktop environment (dock? check. hot corners? check. active desktop? check. ugly chrome... it'll get uglier in time.) how?
  • Only if (Score:4, Insightful)

    by Kilz (741999) on Wednesday June 08, 2005 @10:08AM (#12757074)
    Apple wants to commit suicide and alow the Mac os to be run on generic pc's. So far what Iv read says that the Mac os will still only run on Mac's. Apple has no plans on releasing the os as software to run on any pc.
  • x86 != PC (Score:5, Insightful)

    by FidelCatsro (861135) <fidelcatsro AT gmail DOT com> on Wednesday June 08, 2005 @10:08AM (#12757081) Journal
    Apple are moving to X86 yes , but it wont be standard PC equipment .
    This is no threat to linux , Apple are going to keep with their custom hardware and linux for A-x86 will spring up and take over in a few years from linux for PPC (well not totally )
    • actually, I imagine it will more likely be linux-ppc compiled for x86 (more or less)

      Apart from some chipset specific stuff, it should be similar inside to a ppc, but will need to be compiled for an x86 instruction set.
  • They put a link to Wikipedia right in the article! How will I karma whore now?
  • Could Apple's Intel Desktop Threaten Linux?

    Does this mean that OS.X will now take over from Windows as the 'Root of all Evil'?
  • Next... (Score:2, Insightful)

    by null etc. (524767)
    If Linux enthousiasts don't want Mac OSX on Intel to become a threat for the future of Linux Desktop, they must rethink the concept of Desktop has we know it today.

    Oh yeah? Why is that? Why does it matter if Mac OSX uses Intel or PowerPC or Transmeta for that matter? Apple will still lock their platform, still charge too much for accessories (such as RAM), still take 20 years to develop a 2-button mouse.

    Tell me, fearmonger, why should I start running down the streets in panic?

  • Porting yellowdog back to intel should be a snap. The only problem will be that their market will shrink as the powerpc chip vanishes it will be hard to compete with mature intel based distros.
  • by MrHanky (141717) on Wednesday June 08, 2005 @10:14AM (#12757151) Homepage Journal
    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.
    • by ooze (307871) on Wednesday June 08, 2005 @10:48AM (#12757573)
      Well, my two reasons to switch to Apple a few months ago (apart from usual Windows frustration), was is doesn't use x86 CPUs and is has OpenFirmware.

      Both will get dropped. iwon't buy any Mac with an x86 CPU or without OpenFirmware. Simple as that.

      Anyone who knows a little about Chip design or actually just did some Assembly programming on more than just x86 knows what a crippled and cumbersome Archtecture x86 is.
      And anyone who knows a little about PC Startup knows what cumbersome and crippled process the whole BIOS (in combination with the good ol' blessed x86 real mode) is.

      The recent Slashdot story about the Mach kernel with all the wrappers around it being an intense Performance hog did make me think a little. Mircrokernels rule, Mach is just an outdated implementation put into wrappers to make it backward compatible. Now Apple computers will have the same sticky things happening on the CPU level as well.

      I guess I'll start building my own computer. ARM Kits aren't that expensive. And with a few friends in manufactoring I can put them in shiny cases too. Or that new open Cell Platform could be interesting too.
  • by Kjella (173770) on Wednesday June 08, 2005 @10:14AM (#12757156) Homepage
    ...the corporate desktop? I doubt it. The primary advantage of Linux here is to set up simple, free desktops for users which are not locked in to Windows.

    ...the tinkerer's desktop? Nope. They'll keep going with Linux just as they did before Linux could compare to either Windows or Mac (at least on the desktop side).

    ...the mass market desktop? Maybe. Except Linux never really had it to begin with. As for OS X being so much better - well, I must say that I could build a much better Windows experience with Win+commercial apps than I could with Linux, if I had endless cash or no ethical problem with copyright infringement. Still, Linux and the free legal desktop interests me. I don't think it will be significantly different with Linux vs OS X.

    Kjella
  • by macshit (157376) *
    I looked at the symphony os page, and while the guy has a few good ideas, I was disappointed to see he's yet another UI fascist, proclaiming that consistency of experience trumps user choice.

    It's one of gnome's most grating and annoying properties, that the developers have decided that user configurability is undesirable; since of course they are targetting the novice/clueless user, this means that gnome's interface sucks more and more for the experienced/clueful user, and at the same time they are reducin
  • coral cache... (Score:2, Informative)

    by Anonymous Coward
    Take it easy on the main server, here's the Coral cache...

    http://www.symphonyos.com.nyud.net:8090/ [nyud.net]
  • I don't think the move by Apple to x86 has anything to do with linux at all. If Apple has shown one thing by using so many Open Source components it's that the Open Source community is a great counter balance to a monopoly. Should either side (MS or Apple) gain a lot of sway, the other side will be able to grab code from the Open source community and fire back. Therefore it's in everyone's interest to keep some open *nix alive.

    Both co.'s will be just fine with Linux as long as they retain market dominan

  • by m50d (797211)
    This is just another divisive effort with the same goals as most of the major desktops. Why not focus on improving existing usability? Or even joining one of the other "new useable desktop from scratch" projects. Not that any of them are successful, and for a good reason.

  • I'm not using Linux to "compete with Windows and OSX". I'm not helping out Gnome to make it more competitive. I'm using Linux and Gnome because it happens to fit the way I work very well and I help the Gnome project (by translating a bit, mostly) because it is enjoyable and I get to chat with some very fun people.

  • Apple on Intel is like the original Porsche 924 [itgarage.com]. Either it's a very bad marketing decision or a precursor to a play for a much larger chunk of the mainstream market...

    A long established sports car company Porsche, like Apple, use their unique design and reputation for performance and quality to set itself apart from other players in the same market.

    In 1976 Porsche released the Porsche 924 as an entry level introduction for new customers to the Porsche brand. The 924 may have been designed by Porsche, b

  • by Nooface (526234) on Wednesday June 08, 2005 @10:17AM (#12757190) Homepage
    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.
  • How? (Score:2, Insightful)

    by ampathee (682788)
    How will MacOS on intel threaten linux?

    It's not like you'll be able to install it on any old x86 box - you will still have to buy a Mac.

    It's just the internals of the black box that will change - the end user won't see any major difference (performance aside).

    I don't see how anyone deciding between linux or a mac would be influenced by this change.
  • Ok, I'll bite. (Score:3, Insightful)

    by Weaselmancer (533834) on Wednesday June 08, 2005 @10:24AM (#12757264)

    The Linux Desktop Community must encourage such initatives massively to compete against Mac OSX and Windows.

    Why?

    Maybe I'm missing something and /. can enlighten me. I use Linux. OSX gets a lot of fans.

    So, exactly how does this involve me at all?

    I keep seeing that OSX might become a "threat". How exactly? Will OSX suddenly become self-aware and begin deleting Linux from the entire Internet or something?

    Maybe it's just me, but I just don't feel a threat here. They're both fairly posix/unix, so I'm reallly seeing a potential ally here more than anything else.

  • by guacamole (24270) on Wednesday June 08, 2005 @10:25AM (#12757292)
    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.
  • A few things (Score:3, Insightful)

    by grasshoppa (657393) <skennedy AT tpno-co DOT org> on Wednesday June 08, 2005 @10:28AM (#12757321) Homepage
    1) We don't know how to do a desktop. If you want proof, look at what we've got so far.

    2) We don't *want* to do desktops. This, too, should be fairly obvious by the effort ( or lack thereof ) put forth up to this point.

    If OSX is a great desktop OS on commodity hardware ( it won't be, but that's the assumption at this point ), why should we spin our wheels coming up with yet another version of the wheel? The focus, I believe, should be server side. We should be making file/print and directory services under linux so damned impressive that no one would want to bother with the MS alternative.
  • Threaten how? (Score:5, Insightful)

    by solios (53048) on Wednesday June 08, 2005 @10:45AM (#12757507) Homepage
    Everybody I know who's a linux user but wants a useable desktop they don't have to mess with has already bought a Mac and "switched" to OS X. They still use linux, but the machines are either console-only or headless.

    Of the dozen or so people I know who've "switched", they've all been linux or *bsd users, and they switched because Apple provides a useable desktop experience that Just Works Out Of The Box.

    Of course, these are people with lives who don't like plinking around with their computers just for the hell of it - they use the things to Do Work.
  • by daemonc (145175) on Wednesday June 08, 2005 @10:46AM (#12757527)
    First of all, I doubt that OSX, evens if it runs on commodity x86 hardware, will seriously decrease Linux's marketshare. Linux enthusiasts and Free Software advocates are not suddenly going to switch over to a new proprietary OS just because it's available. (Raging anti-Microsoft zealots might though, but that's a segment of the population I think we can do without.)

    However, this is a unquie opportunity for the Linux community and Apple to help one another and both gain a big chunk of Microsoft's userbase.

    Imagine if Apple started contributing funds and/or developers to the Wine project [winehq.com], basically doing for Wine what they did for Khtml.

    Imagine being able to tell someone that, yes, they can switch to Linux/OSX and still run all their Windows programs/games.

    Imagine what that would do for the marketshare of both operating systems.
    • Raging anti-Microsoft zealots might though, but that's a segment of the population I think we can do without

      Perhaps Mr. Torvalds is no anti-Microsoft zealot. But you can't say the same about many of the early leaders of the Free software world.

      In particular, Richard Stallman, who is largely responsible for gcc, emacs, binary tools, the FSF foundation, the GPL license. He is even (arguably) largely responsible for the success of Linux in general. Yet he is incredibly anti-Microsoft and very well critic
  • by The Dodger (10689) on Wednesday June 08, 2005 @10:49AM (#12757602) Homepage

    Q: "Could Apple's Intel Desktop Threaten Linux?"
    A: No.

    The concept of Apple-on-Intel threatening Linux might be valid if Linux was a commercial operating system, sold by a company whose market share and profits might suffer if Apple were to compete successfully against them.

    But it isn't.

    You can't threaten Linux. If Red Hat and all the other Linux companies were to drop Linux and switch to something else, if Dell, IBM and all the other box suppliers stopped supporting Linux, if all the hardware manufacturers who currently provide Linux drivers for their products all stopped supporting Linux, it still wouldn't be dead. You'd still have people like Torvalds and Cox writing code in their spare time and there'd still be geeks downloading Linux and installing it on old PCs.

    Giving people an alternative to Linux isn't a threat - it's a choice. It's freedom of choice and freedom is what Linux is all about.

    More and more, we see articles and talk about Linux's market share, whether it's going to be successful on the desktop, whether it's going to be able to compete against Windows, against Solaris, et cetera, et cetera, et ad infinitum cetera.

    Linux doesn't compete against Windows, MacOS X or Solaris. Linux vendors, like Red Hat, compete against Microsoft, Apple and Sun. Linux just is. The fact that it's supported by various companies is great but it's not essential for Linux survival. The fact that the amount of people and companies using Linux is huge and growing is terrific, but it's not essential. If everyone, right up to and including Linus abandoned Linux, I'd still be able to dig out my Red Hat CDs and install it on an old PC.

    This article is just typical of /. these days - it's a stupid, hype-ridden question, which hundreds of clueless fuckwits will comment inanely on, wasting bandwidth and electrons.

    Wake up and take your heads out of your asses.


    D.
    ..is for Don't. Be so. Fucking. Stupid.

    • "Linux doesn't compete against Windows, MacOS X or Solaris. Linux vendors, like Red Hat, compete against Microsoft, Apple and Sun. Linux just is. The fact that it's supported by various companies is great but it's not essential for Linux survival. The fact that the amount of people and companies using Linux is huge and growing is terrific, but it's not essential."

      These are all valid points, but you forgot one subtle thing...

      Vendors having access to a Free (and free) operating system, Linux in this

  • by argoff (142580) on Wednesday June 08, 2005 @10:55AM (#12757692)

    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.
    • by American AC in Paris (230456) * on Wednesday June 08, 2005 @11:30AM (#12758142) Homepage
      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.

      Linux will continue to improve, but so will Apple; the question we need to ask is which one will improve faster in the GUI department. In this regard, my money is on Apple, simply because they have near total control over the user interface. They can stand up and say, "the behavior for X will by Y," and that's how it will work. Linux simply does not have this luxury. With Linux, you still have situations where applications work wonderfully with GUI A but have "quirks" if you try using certain features in GUI B, C, or D. Until there's a standard that desktop environment developers agree on and adhere to, you're going to have a fracured desktop experience.

      Yes, in another few years, the Linux GUI will quite possibly be as "good" as the Apple GUI is today. You're fooling yourself, though, if you think Steve is gonna sit back and say, "well, that's good enough." The real challenge for Linux GUIs will be to get better faster than Apple can--and I'm not sure they can, for the reasons stated above.

  • by Andy_R (114137) on Wednesday June 08, 2005 @11:04AM (#12757788) Homepage Journal
    The only Linux this is a threat to is Yellow Dog.

    Apple are staking their entire company on OSX not being pirated to other x86 platforms. OSX will not support any non-Apple hardware, so it's not a threat, unless you count possible increased Apple market share due to lower prices.
  • by 21chrisp (757902) on Wednesday June 08, 2005 @11:17AM (#12757965)
    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.
  • by Nice2Cats (557310) on Wednesday June 08, 2005 @12:33PM (#12758965)
    There is no way that anybody can "kill" Linux on the desktop, because Linux can't go out of business like Microsoft and Apple can. What can happen, of course, is that KDE and Gnome can fall behind so far that nobody uses them.

    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.

  • by LionKimbro (200000) on Wednesday June 08, 2005 @12:34PM (#12758976) Homepage
    What interested me most about Symphony OS is that he put togther a bunch of mock-ops and explanations about how things worked, before coding.

    It seems to me that we're moving towards a specification-based development model. Even some of the GNOME guys are talking about making GNOME a ''specification,'' rather than a particular ''implementation.''

    If we can do this, then it's a great thing, because it means we'll have the basis of a not-just-coders development model. We'll have something where the body of developers are separate from the body of designers. This leads the way for even more decentralization, which is exactly what we need: Right now, the developers are the bottleneck in pretty much all operation. There is very little separation of work, except for website maintenance.

    The more we can make clusters of people working on specific tasks, with well defined roles, the greater we can scale this Free Software thing.

Machines that have broken down will work perfectly when the repairman arrives.

Working...