Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

This is just a hack, nothing more.

Well, it is the cornerstone of Apple's highly successful and entirely transparent transition from PPC to x86, including drag-and-drop application installation/uninstallation. Couple it with Apple's compiler drivers and well-designed multi-architecture SDKs, and it becomes dead-simple to support multiple architectures and OS releases. Just build your binaries with -arch i386 -arch ppc -isysroot /Developer/SDKs/MacOSX10.4u.sdk

It also supports Apple's transparent selection of armv7/armv6 binaries on the iPhone 3GS.

I'd say it's pretty useful, and not really a hack at all.

The only arguments I've heard against it involve package managers and shell scripts, which demonstrates such a remarkable lack of understanding of ease of use and user behavior that I don't even know where to start, other than to say: This is why popular adoption of Linux on the desktop is not going to happen any time soon.



Apple, on the other hand, doesn't have anything even close to a package manager, for example. Also, "transition". There is no transition for Linux. Nobody is really interested in completely phasing out an old platform and port everything to a completely different new one, which is what Apple did. Apple's Mac OS has rather limited hardware support, in fact you shouldn't even try to run it on anything that doesn't have Apple sticker. Linux is expected to run everywhere on everything.

I can't see any possible difference for the fatelf solution and the package manager and scripts solution for an end user. It's not about the ease of use, because there is no difference.


Also, "transition". There is no transition for Linux.

ARM netbooks? That said, part of why there's no 'transition' is that providing easy-to-use (for consumers) third-party application binaries is this side of impossible given the lack of stable APIs across distributions and releases.

I can't see any possible difference for the fatelf solution and the package manager and scripts solution for an end user. It's not about the ease of use, because there is no difference.

I can drag-install any third-party application I want to download, and I can expect it to work on any machine. The author doesn't have to wait to get it packaged by a distribution, set up a package repository, etc. I don't have to wait 3-12 months for the latest version.

I can drag it over to my PPC iMac, and it'll work there, too.

How is that not 'different'?


ARM netbook with its limited SSD disk space is really a great usecase for something that makes binaries two (three, or even more) times larger, while I need only the binary for ARM. (Yeah, it's not that much for > 100G HDD, still, it can be quite a lot for 4 or 8G SSD. Especially when it is completely useless for the computer.)

It's not different, because fatelf doesn't help with this. You can still make some tiny wrapper, and have completely the same thing. Vendor still have to make a package fit for your system, for the set of libraries that you have, correct versions of them, and so on. Yes, Mac OS X system has two or three recent different versions, mostly mutually compatible. If you were trying to make a package for only one or two mostly compatible Linux distributions and one or two of their versions, then it would be also that easy. But it is not, and fatelf doesn't make any difference.


Yeah. I hear double clicking on an rpm/dpkg is really difficult.


I'm not saying this is a hack, but just because it has proved a useful strategy in Apple's situation, doesn't mean that it is the right strategy for Linux.

Apple succeeded by going against the conventional wisdom; now, in many ways, Apple is the conventional wisdom. In the end, I think the most important thing is for people to do what feels right for them, not blindly copying what has worked for others.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: