From: Luke Kanies Date: 19:54 on 20 May 2006 Subject: OS X packaging is an embarrassment So I picked up a MacBook yesterday, for various reasons but mostly because my 12" powerbook feels really slow these days. After getting my accounts moved over, which took a while (mostly because I have 45GB of music), I went about making it resemble the *nix workstation I know and love. These days, that mostly involves getting X11 installed and then getting RXVT working. I tried Apple's Terminal for a while, but I can't change the ANSI colors and the defaults suck when having a dark background, and it's difficult to automatically tile them, which I always do. So, I install X11 and DarwinPorts. Hmm, nothing works. Ah, DarwinPorts can't find a compiler. Ok, go into XCode and install the compiler. Or, well, install both of them. Nope, still doesn't work. Ok, link gcc-4.0 to gcc. Nope, still doesn't work. Look at the build log, realize it's missing "as". Do some searching, realize that I need another package. This is where I realize, OS X is an embarrassment. See, the DarwinPorts package was a normal OS X package. If OS X had a real packaging system, then the DarwinPorts package would have been able to say, hey, this won't work, you're going to need these 7 packages. Instead, because OS X's packaging is basically a glorified tarball, you just have to try it, and then figure out the failures yourself. Of course, it's not just in the Unix world where OS X's packaging falls flat on its face. "Just drag it into the applications folder" is a nice install method, but it sucks from then on. What packages do I have installed? Have they changed? Are there updates available? No idea, no way to find out, unless maybe it's an Apple package directly. And, of course, even though my motivation for buying this machine was because my 12" feels really slow, this machine feels just about as slow. Particularly, if I am doing more than one thing at a time -- say, Firefox is loading a tab, and I switch workspaces -- then the whole machine bogs down just as badly as my 12" did. I/O seems to just kill OS X. I'd love to think that OS X could be free of software hate, but I don't see it happening any time soon. Give me apt and a decent package manager, and then a kernel that doesn't somehow manage to make a dual-proc 2ghz machine feel dog-slow, and then we'll talk.
From: Bill Page Date: 20:14 on 20 May 2006 Subject: Re: OS X packaging is an embarrassment maybe you shouldn't be a unix faggot, you dickhead* *may have been written at 4:44 am on sunday morning will rely on others to fix this problem without one noticing On 5/21/06, Luke Kanies <luke@xxxxxxx.xxx> wrote: > So I picked up a MacBook yesterday, for various reasons but mostly becaus= e > my 12" powerbook feels really slow these days. After getting my accounts > moved over, which took a while (mostly because I have 45GB of music), I w= ent > about making it resemble the *nix workstation I know and love. > > These days, that mostly involves getting X11 installed and then getting R= XVT > working. I tried Apple's Terminal for a while, but I can't change the AN= SI > colors and the defaults suck when having a dark background, and it's > difficult to automatically tile them, which I always do. > > So, I install X11 and DarwinPorts. Hmm, nothing works. Ah, DarwinPorts > can't find a compiler. Ok, go into XCode and install the compiler. Or, > well, install both of them. Nope, still doesn't work. Ok, link gcc-4.0 = to > gcc. Nope, still doesn't work. Look at the build log, realize it's miss= ing > "as". Do some searching, realize that I need another package. > > This is where I realize, OS X is an embarrassment. > > See, the DarwinPorts package was a normal OS X package. If OS X had a re= al > packaging system, then the DarwinPorts package would have been able to sa= y, > hey, this won't work, you're going to need these 7 packages. > > Instead, because OS X's packaging is basically a glorified tarball, you j= ust > have to try it, and then figure out the failures yourself. > > Of course, it's not just in the Unix world where OS X's packaging falls f= lat > on its face. "Just drag it into the applications folder" is a nice insta= ll > method, but it sucks from then on. What packages do I have installed? H= ave > they changed? Are there updates available? No idea, no way to find out, > unless maybe it's an Apple package directly. > > And, of course, even though my motivation for buying this machine was > because my 12" feels really slow, this machine feels just about as slow. > Particularly, if I am doing more than one thing at a time -- say, Firefox= is > loading a tab, and I switch workspaces -- then the whole machine bogs dow= n > just as badly as my 12" did. I/O seems to just kill OS X. > > I'd love to think that OS X could be free of software hate, but I don't s= ee > it happening any time soon. Give me apt and a decent package manager, an= d > then a kernel that doesn't somehow manage to make a dual-proc 2ghz machin= e > feel dog-slow, and then we'll talk. > > -- > I'm seventeen and I'm crazy. My uncle says the two always go together. Wh= en > people ask your age, he said, always say seventeen and insane. > -- Ray Bradbury > --------------------------------------------------------------------- > Luke Kanies | http://reductivelabs.com | http://madstop.com > >
From: Luke Kanies
Date: 19:21 on 21 May 2006
Subject: Re: OS X packaging is an embarrassment
On Sun, 21 May 2006, Bill Page wrote:
> maybe you shouldn't be a unix faggot, you dickhead*
>
> *may have been written at 4:44 am on sunday morning
> will rely on others to fix this problem without one noticing
I understand it might have been late, but, um... Vitriol is on topic, and
potty mouths are expected, but I think you're being a bit excessive.
Not that luke-hate is surprising, but it's probably not on-topic.
At the least, you could have responded with how you've never had a package
that needed another package to run, or that when you do you just *know* it
so you don't need a wussy tool to tell you that, or that you're so
super-magical that when you have a problem on your computer, you immediately
know what's wrong ("RXVT can't find X11/Intrinsic.h? I must not have
installed the X11 SDK! Of course!").
Just calling me a dickhead for expecting my "I paid extra so it would just
work" computer to just work, even when doing things that not everyone does,
is a bit excessive.
From: Bill Page Date: 02:12 on 22 May 2006 Subject: Re: OS X packaging is an embarrassment On 5/22/06, Luke Kanies <luke@xxxxxxx.xxx> wrote: > On Sun, 21 May 2006, Bill Page wrote: > > > maybe you shouldn't be a unix faggot, you dickhead* > > > > *may have been written at 4:44 am on sunday morning > > will rely on others to fix this problem without one noticing > > I understand it might have been late, but, um... Vitriol is on topic, an= d > potty mouths are expected, but I think you're being a bit excessive. > well ok, yes, i don't remember sending that (amongst a great deal of other things, i imagine), it is somewhat excessive. but it's the using it like a unix machine instead of a mac that's running you into troubles. "If you insist on treating it as a kind of inconvenient subset of Linux you're going to lose out."
From: Daniel Pittman
Date: 01:42 on 21 May 2006
Subject: Re: OS X packaging is an embarrassment
Luke Kanies <luke@xxxxxxx.xxx> writes:
Is hating the hardware allowed here? Because, in a short while you
surely will, assuming that you don't mean the Pro version here:
> So I picked up a MacBook yesterday, for various reasons but mostly because
> my 12" powerbook feels really slow these days.
[...]
> And, of course, even though my motivation for buying this machine was
> because my 12" feels really slow, this machine feels just about as slow.
> Particularly, if I am doing more than one thing at a time -- say, Firefox is
> loading a tab, and I switch workspaces -- then the whole machine bogs down
> just as badly as my 12" did. I/O seems to just kill OS X.
From the Tech Specs:
Intel GMA 950 graphics processor with 64MB of DDR2 SDRAM
shared with main memory
Thanks Apple, for investing so much in using the GPU to provide advanced
video display effects ... then dumping the GPU for a half-assed shared
memory system with very little hardware acceleration in your current
MacBook line.
At least they kept a real GPU in the MacBookPro.
Plus, MacBook: worst product name ever.
Daniel
This is why I continue to not buy Apple. I really don't want to use
Linux or *BSD on this machine but, frankly, Apple is /not/ a step up.
Why can't I run OSX on something built like an IBM Thinkpad, you
bastards?
From: Peter da Silva Date: 05:43 on 21 May 2006 Subject: Re: OS X packaging is an embarrassment > Intel GMA 950 graphics processor with 64MB of DDR2 SDRAM > shared with main memory > > Thanks Apple, for investing so much in using the GPU to provide > advanced > video display effects ... then dumping the GPU for a half-assed shared > memory system with very little hardware acceleration in your current > MacBook line. They pulled this with the Intel Mac mini too, I've already beaten this hate into submission. But then hating Apple hardware is something I've been embarrassing Apple fans with for years now. Their last real desktop, for example, was the Beige G3... and no I don't want Apple relieving me of the burden of buying my own ugly monitor, or buying video cards, thank you very much. As for OSX packaging... it's not a "package system" like the BSD ports system, but then neither is RPM, and neither were Debian packages for many years. I have been told Debian packages have gotten to the point where you can just install a package and have it automatically pull in everything it needs, but that sure wasn't the case back when I was actively looking at switching to Linux in the '90s, and it sure as hell wasn't the case for Red Hat last June. Bootstrapping into a BSD package environment like Darwinports on OSX takes a bit of work. But for just grabbing an application and using it, I'll take OSX packages any day. Just don't install your packages into /Applications, make your own /local/Applications directory. You'll be glad when you upgrade.
From: Bruce Richardson Date: 12:19 on 21 May 2006 Subject: Re: OS X packaging is an embarrassment On Sat, May 20, 2006 at 11:43:22PM -0500, Peter da Silva wrote: > As for OSX packaging... it's not a "package system" like the BSD ports > system, but then neither is RPM, and neither were Debian packages for > many years. I have been told Debian packages have gotten to the point > where you can just install a package and have it automatically pull in > everything it needs, but that sure wasn't the case back when I was > actively looking at switching to Linux in the '90s, Apt was released with Debian 2.1 in 1999. > and it sure as hell > wasn't the case for Red Hat last June. Red Hat has had Up2date (for corporate use) and Yum and even Apt-get for a few years now. Certainly since last June. All of them will let you pull down a package and all of its dependencies. Both Debian and Red Hat treat the management of installed packages and the tracking of available packages as logically separate tasks and built separate tools to do the latter, rather than extending rpm or dpkg. This still seems to be catching some people out. Frankly, the packaging systems for the main Linux distributions are more powerful and sophisticated than those of the various decendants of 386BSD. This isn't so relevant for FreeBSD or OpenBSD, since they are more integrated and centrally managed than any Linux distribution. Different story with OSX, though, where the multiplicity of official packaging systems (so not counting fink) makes for a real mess IMO. I'm used to being able to track the ownership and purpose of any file outside /home or /var. Installing a package by drag-and-drop is a nice feature but there's no reason why that could not have been integrated with decent package management. That's something that both Gnome and KDE offered back in the 90s, ironically. As long as OS X's customer base is mostly the non-technical and Unix geeks who are tired of worrying how their desktop is configured, I don't suppose it matters so much. Those who do care can run Debian on their powerbooks.
From: Peter da Silva Date: 16:21 on 21 May 2006 Subject: Re: OS X packaging is an embarrassment On May 21, 2006, at 6:19 AM, Bruce Richardson wrote: > On Sat, May 20, 2006 at 11:43:22PM -0500, Peter da Silva wrote: >> As for OSX packaging... it's not a "package system" like the BSD ports >> system, but then neither is RPM, and neither were Debian packages for >> many years. I have been told Debian packages have gotten to the point >> where you can just install a package and have it automatically pull in >> everything it needs, but that sure wasn't the case back when I was >> actively looking at switching to Linux in the '90s, > > Apt was released with Debian 2.1 in 1999. Back when everyone was going on about how I'd like it so much more than FreeBSD because it had more drivers and everyone knew it was the most BSD-like Linux, and then boggling that I actually wanted a package *management* tool, and then pointing me at two more things that weren't actually package management tools, it really didn't matter what was going to happen in 1999. And they really did think I was asking a bit much, expecting the system to figure out what I needed. >> and it sure as hell >> wasn't the case for Red Hat last June. > Red Hat has had Up2date (for corporate use) and Yum and even Apt-get > for > a few years now. Certainly since last June. All of them will let you > pull down a package and all of its dependencies. Yep, and you get your choice of a bunch of different collections, but god help you if you get a package that's not set up for the repository you're working with. You're back in the old style groveling around a bunch of repositories looking for the one that's got the bits you need. > Frankly, the packaging systems for the main Linux distributions are > more > powerful and sophisticated than those of the various decendants of > 386BSD. This isn't so relevant for FreeBSD or OpenBSD, since they are > more integrated and centrally managed than any Linux distribution. And OSX is more centrally managed than FreeBSD. > Different story with OSX, though, where the multiplicity of official > packaging systems (so not counting fink) makes for a real mess IMO. > I'm > used to being able to track the ownership and purpose of any file > outside /home or /var. In OSX you know the ownership and purpose of any file because that information is built into the file system. You don't have to look it up, it's right there in the name and owner and type. If you insist on treating it as a kind of inconvenient subset of Linux you're going to lose out. > Those who do care can run Debian on their powerbooks. Why, for god's sake? Apple's laptops are horrid, and even if you bought one and you're stuck with it, you can probably trade it even up for something like a thinkpad that's actually designed for use rather than looks.
From: Luke Kanies Date: 19:38 on 21 May 2006 Subject: Re: OS X packaging is an embarrassment On Sun, 21 May 2006, Peter da Silva wrote: > In OSX you know the ownership and purpose of any file because that > information is built into the file system. You don't have to look it > up, it's right there in the name and owner and type. Sure, just like an *nix or whatever; but you don't know why it's that way, and you don't know if that's correct. Anyone know how Apple's "check disk permissions" tool works? Can I introspect that? $10 says it's just a huge list of permissions, and that it only ever works for OS stuff -- I can't add to the list, for instance. How can I ask my Mac if a given package is installed correctly? Oh, right, I can't. > If you insist on treating it as a kind of inconvenient subset of Linux > you're going to lose out. It's got nothing to do with Linux; it's got to do with the OS being able to answer straightforward questions like, "Are you configured correctly?". > > Those who do care can run Debian on their powerbooks. > > Why, for god's sake? Apple's laptops are horrid, and even if you bought > one and you're stuck with it, you can probably trade it even up for > something like a thinkpad that's actually designed for use rather than > looks. Yeah. Buying a Mac to run Debian is about like buying a Porsche and putting an American engine into it or something ridiculous.
From: peter (Peter da Silva) Date: 20:25 on 21 May 2006 Subject: Re: OS X packaging is an embarrassment > Sure, just like an *nix or whatever; but you don't know why it's that way, > and you don't know if that's correct. In UNIX a typical package involves having files in 10 different obscurely named directories, with names like "/usr/sbin" that are STILL the subject of active debate over whetehr something should be "sbin" or "libexec". In OS X a typical package involves having one directory tree sitting in any convenient folder. This is a HUGE difference. It's why the lack of a heavy duty package system is an annoyance, not a hate. If it was built out of packages like a Linux distro that would be different. > How can I ask my Mac if a given package is installed correctly? Oh, right, > I can't. A properly designed package can't be improperly installed. Really. The package is the installation, there's nothing else to see. > It's got nothing to do with Linux; it's got to do with the OS being able to > answer straightforward questions like, "Are you configured correctly?". Erm... what? I know it can answer the question "what packages do you have installed", but that's a long way from "are you configured correctly".
From: Luke Kanies
Date: 00:06 on 22 May 2006
Subject: Re: OS X packaging is an embarrassment
On Sun, 21 May 2006, Peter da Silva wrote:
> > Sure, just like an *nix or whatever; but you don't know why it's that way,
> > and you don't know if that's correct.
>
> In UNIX a typical package involves having files in 10 different obscurely
> named directories, with names like "/usr/sbin" that are STILL the subject
> of active debate over whetehr something should be "sbin" or "libexec".
That's just semantics, and I don't really care. Pick something, record it
in your package manifest, and do it consistently; that's all I care about.
When I say "why" in this case, I mean: Given a file, why does that file
exist? Is it the correct file?
For instance, in the process of getting DarwinPorts set up yesterday, I had
to install the X11/Intrinsic.h header. You probably have that header on
your computer. You could certainly use find or whatever to find it, if so.
Upon finding it, could you tell me what package installed it? That's the
"why" I'm talking about.
> In OS X a typical package involves having one directory tree sitting
> in any convenient folder.
I'm not convinced. None of the OS packages are that way.
luke@phage(0) $ ls /Library/Receipts/ | wc -l
101
I have maybe installed 10 packages on this machine, which means that my box
shipped with ~90 packages installed. Yet:
luke@phage(0) $ ls /Applications/ | wc -l
37
Hmmm. Something's certainly screwy. How do I figure out that discrepancy?
Well, I certainly can't ask the stupid computer, at least not without
writing a script to understand their receipt format.
Hate.
> This is a HUGE difference.
Eh, I don't agree. I've managed packages that way on Unix, linking things
back to /usr/local or whatever, and it's not much easier. I can whip up a
script in four languages to uninstall a package by hand for any of multiple
decent package formats -- rpm, dpkg, emerge, whatever -- as long as I can
ask the packaging system, "what files are associated with this package?"
With dpkg, I just say, dpkg -L <package name>. I don't care where the files
are; they could each be in a directory named for the file's checksum for all
I care, as long as the package works correctly and I can use tools to do all
the necessary work.
> It's why the lack of a heavy duty package system is an annoyance, not a
> hate. If it was built out of packages like a Linux distro that would be
> different.
It's an annoyance to you; it's very much a hate to me.
And the OS is very clearly built out of confusing packages like Linux.
You're glossing over that and just talking about the applications, many of
which aren't nearly as pretty as you make out.
> > How can I ask my Mac if a given package is installed correctly? Oh, right,
> > I can't.
>
> A properly designed package can't be improperly installed. Really. The
> package is the installation, there's nothing else to see.
Files can't get corrupted? Permissions can't go wrong? Ownership can't get
messed up? Software can't get rooted? Ever? How do you know?
I really do think it's important to know whether the computer looks like
it's supposed to. X files should exist, Y files should by owned by A, and Z
files should have N checksums. Do they?
> > It's got nothing to do with Linux; it's got to do with the OS being able to
> > answer straightforward questions like, "Are you configured correctly?".
>
> Erm... what? I know it can answer the question "what packages do you have
> installed", but that's a long way from "are you configured correctly".
Any package management system worth its salt can exhaustively tell you
whether every single managed file has the right mode, ownership, and
checksum. It might take an hour, but it'll tell you.
Obviously it's up to me to configure the actual functionality of the system,
but with that kind of check at least I know it's me, not the app. And I
know the box hasn't been rooted (yes, I know, they could root the pkg db;
there are ways to handle that, too), and that my app will actually start.
I maintain an automation tool, Puppet
(http://reductivelabs.com/projects/puppet), and I spend a lot of time using
it to make sure configurations don't drift. Apache's log files all need to
exist and be owned by the apache user or it won't start; are they? How do
you know?
Of course, no package management system reaches into configuration files to
perform tests like that right now, but give me a couple of years.
From: peter (Peter da Silva) Date: 02:11 on 22 May 2006 Subject: Re: OS X packaging is an embarrassment > > In UNIX a typical package involves having files in 10 different obscurely > > named directories, with names like "/usr/sbin" that are STILL the subject > > of active debate over whetehr something should be "sbin" or "libexec". > That's just semantics, and I don't really care. Pick something, record it > in your package manifest, and do it consistently; that's all I care about. I like not having to record it anywhere because it's obvious what it does from what it's called and where it is. Having to grovel through what- package-system-does-THIS-box-use-again is hateful. > For instance, in the process of getting DarwinPorts set up yesterday, I had > to install the X11/Intrinsic.h header. You probably have that header on > your computer. You could certainly use find or whatever to find it, if so. > Upon finding it, could you tell me what package installed it? That's the > "why" I'm talking about. It was installed by Apple X11 or the Apple dev kit, and since I'm never going to NOT install them both with all the packages included... I don't care. It's an OS package. It's not optional. It's part of the core. > > In OS X a typical package involves having one directory tree sitting > > in any convenient folder. > I'm not convinced. None of the OS packages are that way. Why would I ever *not* install any of the OS packages on a desktop OS that's chewing up tens of gigabytes no matter what I do? This isn't a server OS, and it's never going to be lean and mean enough to make it worthwhile trying to make it one. The server version of Mac OS X is FreeBSD. > I have maybe installed 10 packages on this machine, which means that my box > shipped with ~90 packages installed. So? Those 90 packages are always installed, why should you care? They're the core system. Linux doesn't have a "core system", so you have to know what's there. The upside to that is you can control what's in your system a lot more precisely. The downside is you have to know what's in your system a lot more accurately. > Eh, I don't agree. I've managed packages that way on Unix, linking things > back to /usr/local or whatever, and it's not much easier. Not the same thing at all. You don't have to link them back to /usr/local-or-whatever on Mac OS X. > I can whip up a > script in four languages to uninstall a package by hand for any of multiple > decent package formats -- rpm, dpkg, emerge, whatever -- as long as I can > ask the packaging system, "what files are associated with this package?" For Mac OS X, for any package you're normally going to have a reason to uninstall, you do it with "rm -r /what-you-use/Applications/Packagename.app". Except for the idiot programs that do their own installer thing. > With dpkg, I just say, dpkg -L <package name>. I don't care where the files > are; they could each be in a directory named for the file's checksum for all > I care, as long as the package works correctly and I can use tools to do all > the necessary work. I see having to have that tool as a problem. I increasingly hate the whole UNIX /usr/ hierarchy. I was already tendin that way when I got into Mac OS X and it's become so finely focussed by the experience of a system that doesn't work that way. > And the OS is very clearly built out of confusing packages like Linux. It's not built of packages I need to care about. I can't not care about Linux packages, because there's no core system (whether that's a common set of packages, or a common tree and some contrib packages, or whatever) that's always the same. Even with the same distro and version two linux systems set up by different people are unlikely to have the same core. > You're glossing over that and just talking about the applications, many of > which aren't nearly as pretty as you make out. There are hateful applications that don't do packaging right, yes, and they are worthy of hate. Because they don't do it right. > Files can't get corrupted? Permissions can't go wrong? Ownership can't get > messed up? Software can't get rooted? Ever? How do you know? I don't, and I don't know that on your Debian system either. Except for the ones put in there by the package system, which are hardly ever the ones I care about... the ones I care about are the ones in $HOME, and the configuration files... the ones that aren't the same as in the package system. Everything else can be reinstalled. The actual configuration and my own files have to be backed up and restored. > > Erm... what? I know it can answer the question "what packages do you have > > installed", but that's a long way from "are you configured correctly". > Any package management system worth its salt can exhaustively tell you > whether every single managed file has the right mode, ownership, and > checksum. It might take an hour, but it'll tell you. That doesn't tell me if ANY of those packages are correctly configured. As for rootkits, tripwire watches all the files, not just the ones the package system put into place. > Apache's log files all need to > exist and be owned by the apache user or it won't start; are they? How do > you know? I have NEVER creates any of apache's log files, and I have NEVER had apache fail to come up as a result. They're all there in /var/log/httpd.
From: Luke Kanies Date: 05:00 on 22 May 2006 Subject: Re: OS X packaging is an embarrassment On Sun, 21 May 2006, Peter da Silva wrote: > > That's just semantics, and I don't really care. Pick something, record it > > in your package manifest, and do it consistently; that's all I care about. > > I like not having to record it anywhere because it's obvious what it does > from what it's called and where it is. Having to grovel through what- > package-system-does-THIS-box-use-again is hateful. Really? What is /usr/include/ltdl.h for? I certainly couldn't guess from what it's called or where it's located. > > For instance, in the process of getting DarwinPorts set up yesterday, I had > > to install the X11/Intrinsic.h header. You probably have that header on > > your computer. You could certainly use find or whatever to find it, if so. > > Upon finding it, could you tell me what package installed it? That's the > > "why" I'm talking about. > > It was installed by Apple X11 or the Apple dev kit, and since I'm never going > to NOT install them both with all the packages included... I don't care. > > It's an OS package. It's not optional. It's part of the core. It *is* optional. In fact, the X11 SDK is one of about 12 optional SDKs, along with a GB of optional developer documentation. Considering that my machine has only a couple of GB free, it's important to conserve where I can. This is one of the things that sucks about OS X -- "I don't know what you need, just install all 25GB and be done". Yeah, thanks. > > > In OS X a typical package involves having one directory tree sitting > > > in any convenient folder. > > > I'm not convinced. None of the OS packages are that way. > > Why would I ever *not* install any of the OS packages on a desktop OS that's > chewing up tens of gigabytes no matter what I do? This isn't a server OS, and > it's never going to be lean and mean enough to make it worthwhile trying to > make it one. I'm already almost out of space -- I was down to 65 MB yesterday. Good enough reason? Thanks. > The server version of Mac OS X is FreeBSD. God forbid I ever pay to run FreeBSD. > > I have maybe installed 10 packages on this machine, which means that my box > > shipped with ~90 packages installed. > > So? Those 90 packages are always installed, why should you care? They're the > core system. The point is that those 90 packages break your whole definition of how OS X's packaging system is so simple. Sure, the apps are easy, but the OS is not. That may be fine for you and your one machine; I can tell you from experience that those with tens, hundreds, or thousands of macs do not find it so trivial or ignorable. > Linux doesn't have a "core system", so you have to know what's there. The > upside to that is you can control what's in your system a lot more precisely. > The downside is you have to know what's in your system a lot more accurately. BS. Debian has a core, Red Hat has a core, Gentoo has a core, Solaris has a core. Yes, these are customizable. Isn't that a feature. > > Eh, I don't agree. I've managed packages that way on Unix, linking things > > back to /usr/local or whatever, and it's not much easier. > > Not the same thing at all. > > You don't have to link them back to /usr/local-or-whatever on Mac OS X. I can still rm -rf /path/to/my/path, and the app goes away. So some automated tool has to clean up the dead links; so? What do I care? > > I can whip up a > > script in four languages to uninstall a package by hand for any of multiple > > decent package formats -- rpm, dpkg, emerge, whatever -- as long as I can > > ask the packaging system, "what files are associated with this package?" > > For Mac OS X, for any package you're normally going to have a reason to > uninstall, you do it with "rm -r /what-you-use/Applications/Packagename.app". > > Except for the idiot programs that do their own installer thing. I don't care about uninstall; I care about upgrading, and whether there's an upgrade available, and I care whether a given package's install has drifted in any way. > > With dpkg, I just say, dpkg -L <package name>. I don't care where the files > > are; they could each be in a directory named for the file's checksum for all > > I care, as long as the package works correctly and I can use tools to do all > > the necessary work. > > I see having to have that tool as a problem. I increasingly hate the whole > UNIX /usr/ hierarchy. I was already tendin that way when I got into Mac OS X > and it's become so finely focussed by the experience of a system that doesn't > work that way. I can't believe you don't want some sort of ability to discern the meaning behind a file. Wow. > > And the OS is very clearly built out of confusing packages like Linux. > > It's not built of packages I need to care about. Then I'm not complaining for you, I'm complaining for those who need to actually manage their systems, not just ride them. > I can't not care about Linux packages, because there's no core system (whether > that's a common set of packages, or a common tree and some contrib packages, > or whatever) that's always the same. Even with the same distro and version > two linux systems set up by different people are unlikely to have the same > core. That's silly. I certainly hope you've tried this with Debian, to make such a sweeping statement about "linux", which, again, doesn't exist as an operating system. Certainly the kernel has no core, just like Mach has no core. > > You're glossing over that and just talking about the applications, many of > > which aren't nearly as pretty as you make out. > > There are hateful applications that don't do packaging right, yes, and they > are worthy of hate. Because they don't do it right. Or because their needs are such that they can't do it "right", because the packaging system is too primitive. > > Files can't get corrupted? Permissions can't go wrong? Ownership can't get > > messed up? Software can't get rooted? Ever? How do you know? > > I don't, and I don't know that on your Debian system either. Except for the > ones put in there by the package system, which are hardly ever the ones I > care about... the ones I care about are the ones in $HOME, and the > configuration files... the ones that aren't the same as in the package > system. I kind of agree with that -- I agree we need a mechanism to care about those files, which is one of the reasons I've developed Puppet. > Everything else can be reinstalled. The actual configuration and my own files > have to be backed up and restored. How do you know if you have to reinstall? Just wait for all hell to break loose? > > > Erm... what? I know it can answer the question "what packages do you have > > > installed", but that's a long way from "are you configured correctly". > > > Any package management system worth its salt can exhaustively tell you > > whether every single managed file has the right mode, ownership, and > > checksum. It might take an hour, but it'll tell you. > > That doesn't tell me if ANY of those packages are correctly configured. Sorry; I used the wrong word originally. It should have been "still installed". Are they still installed correctly, or has there been drift? Can I ask the computer any meaningful questions about itself? Shouldn't I be able to? > As for rootkits, tripwire watches all the files, not just the ones the package > system put into place. Yeah, but it's entirely without meaning -- say file X changed; do you know why? Was it intentional? Was it accidental? Can I recover? Tripwire is a crappy band-aid on a problem the OS should care about. > > Apache's log files all need to > > exist and be owned by the apache user or it won't start; are they? How do > > you know? > > I have NEVER creates any of apache's log files, and I have NEVER had apache > fail to come up as a result. They're all there in /var/log/httpd. Well, then apache has write access to all of your log directories. It doesn't have write access to mine. Mine way's easier to automate, easier to manage, and easier to segment. Your way requires less ability to interact with the computer.
From: sabrina downard Date: 01:22 on 22 May 2006 Subject: Re: OS X packaging is an embarrassment > Yeah. Buying a Mac to run Debian is about like buying a Porsche and putt= ing > an American engine into it or something ridiculous. this analogy makes me cry for the poor hypothetical car. speaking of cars, software, and hate all in one tidy bundle: last year i took a road trip of roughly 3400 miles, nearly all interstate highway but some two-lane highway. i averaged about 33.5 miles to the gallon, which i was reasonably pleased with. i had it serviced directly after. four months later i took another road trip, much shorter, only about 720 miles, all four- and more-lane highway (on clear roads), doing approximately the same speed, and i got 29 miles to the gallon. well, maybe it was a fluke. a month later, the same roadtrip again, and the mileage didn't crack 30. i was *very* unhappy about that, so i called my dealer mechanic to ask about them checking it, asking if the timing could be off and confirming that they had replaced all my spark plugs as part of the previous maintenance (they had), and asking if they had done anything to the ECM during maintenance. the mechanic informed me, rather smarmily, that the timing is quite unadjustable in my car as it's all controlled by "the computer" and they cannot have accidentally changed "the computer." the ECM, the magical all-seeing, all-knowing engine control module, is omnibenevolent and perfectly predictable and if i've magically lost four miles to the gallon it's certainly somehow my fault as the operator. perhaps i just forgot i had upper gears. THE COMPUTER CANNOT BE WRONG. he never actually came out and said "it is not possible that the ECM is malfunctioning or we got it out of whack accidentally," but that was certainly the impression he conveyed. i really, really, really, really, really wanted to say "listen, bub, i work with computers and trust me, they are full of lies," but he probably wouldn't have believed me. because the ECM cannot be wrong. how could it be -- it's software, isn't it! (the really fun part about all his "it's impossible to mess up the ECM!" protestations is that five minutes with google turns up horror stories of people screwing up their VW ECMs ridiculously easily -- like, by replacing a stock stereo with an aftermarket model. i ask you, WHY ON EARTH should the gadget that's in charge of my fuel injectors have anything at all to do with my stereo? could you not afford *two* NVRAM chips? you redesigned the cupholders to fit Starbucks cups, for chrissakes -- i swear to you, the salesman pitched that as a feature improvement in my particular model year -- but you can't separate essential from nonessential electronics?) still incredulous (and hateful), --s.
From: Aaron J. Grier Date: 07:52 on 26 May 2006 Subject: embedded systems On Sun, May 21, 2006 at 07:22:02PM -0500, sabrina downard wrote: > i ask you, WHY ON EARTH should the gadget that's in charge of my fuel > injectors have anything at all to do with my stereo? just because it appears to be hardware, that doesn't mean that deep down there isn't actually software to hate. how is your tire pressure?
From: Luke Kanies Date: 19:34 on 21 May 2006 Subject: Re: OS X packaging is an embarrassment On Sun, 21 May 2006, Bruce Richardson wrote: > Apt was released with Debian 2.1 in 1999. And kicks so much ass over ports that it's not even funny. It's certainly possible that ports was freaking awesome in 1988 or whenever, but it needs to take some hints from Apt. Of course, I think Apt needs to take some hints from Gentoo's emerge system, too, but I love binary packages (I like supporting a single compile of a given package), and I love being able to query against the database from which I'll be installing -- FreeBSD's "portupgrade" tool allows you to specify to only install binary packages, but the "portversion" tool or whatever will *always* query against both compiled and source versions, and since there's always a more recent port, you always get told there's a more recent version. Bloody smart. > Red Hat has had Up2date (for corporate use) and Yum and even Apt-get for > a few years now. Certainly since last June. All of them will let you > pull down a package and all of its dependencies. Yum is dog-slow, but it does work. Mostly. > Both Debian and Red Hat treat the management of installed packages and > the tracking of available packages as logically separate tasks and built > separate tools to do the latter, rather than extending rpm or dpkg. > This still seems to be catching some people out. I think it's a great idea. There are people who have joined apt to other packaging systems, like rpm. > Frankly, the packaging systems for the main Linux distributions are more > powerful and sophisticated than those of the various decendants of > 386BSD. This isn't so relevant for FreeBSD or OpenBSD, since they are > more integrated and centrally managed than any Linux distribution. > Different story with OSX, though, where the multiplicity of official > packaging systems (so not counting fink) makes for a real mess IMO. I'm > used to being able to track the ownership and purpose of any file > outside /home or /var. > > Installing a package by drag-and-drop is a nice feature but there's no > reason why that could not have been integrated with decent package > management. That's something that both Gnome and KDE offered back in > the 90s, ironically. Totally. > As long as OS X's customer base is mostly the non-technical and Unix > geeks who are tired of worrying how their desktop is configured, I don't > suppose it matters so much. Those who do care can run Debian on their > powerbooks. > Right, because people who just want things to work need crappier tools? No, it's actually more important that OS X has great packaging. Why is it that every single OS X tool has to write its own update-checking system?
From: Peter da Silva Date: 17:16 on 21 May 2006 Subject: Re: OS X packaging is an embarrassment > Oh great... I recently had an issue with the Apache runtime not > working with the latest version of Sleepycat (i.e. Berkeley DB) but > which was required for svn (or was it mySQL?, I forget now). In a > nutshell, there was a recursive package dependancy conflict. If you > updated the webserver with all the packages it required, mySQL would > be hosed. If you updated mySQL's package requirements, the webserver > would be hosed. That's part of the problem I had with RPMs last June. Repository conflicts between Apache, Tomcat, Java, Ant, and magic XML that was supposed to glue it all together. I was able to install everything on FreeBSD by downloading the Linux packages from Sun, sticking them in my distfiles directory, and typing "make install"... and waiting six hours. Yeh, recompiling everything takes more time, but it's not *my* time it's wasting.
From: Luke Kanies Date: 19:29 on 21 May 2006 Subject: Re: OS X packaging is an embarrassment On Sat, 20 May 2006, Peter da Silva wrote: > They pulled this with the Intel Mac mini too, I've already beaten this > hate into submission. > > But then hating Apple hardware is something I've been embarrassing > Apple fans with for years now. Their last real desktop, for example, > was the Beige G3... and no I don't want Apple relieving me of the > burden of buying my own ugly monitor, or buying video cards, thank you > very much. Yeah -- why wasn't the G5 just slightly larger than a mini? The largest tower available with the least expandability? Thanks. > As for OSX packaging... it's not a "package system" like the BSD ports > system, but then neither is RPM, and neither were Debian packages for > many years. I have been told Debian packages have gotten to the point > where you can just install a package and have it automatically pull in > everything it needs, but that sure wasn't the case back when I was > actively looking at switching to Linux in the '90s, and it sure as hell > wasn't the case for Red Hat last June. I stupidly posted this to my blog instead of this list a while back: http://madstop.com/articles/2006/04/05/freebsd-is-an-embarrassment I've since come to the conclusion that FreeBSD's ports system is apparently great for those people who like to do everything manually, but it's like kryptonite for anyone trying to automate. I am absolutely convinced it is the least automatable *nix OS available. Yes, it's true, you literally cannot use the provided tools to automate package management -- I'm lucky that both they and my management tools are written in Ruby, or I'd basically just have to give up. If I were continuing to build my own company (I just joined another), I would charge at least 1.5x support rates for FreeBSD. "Services? What are those? Non-interactive package installation? Who would do that? 1983 was freaking awesome, and I'm never leaving."
From: peter (Peter da Silva) Date: 20:17 on 21 May 2006 Subject: Re: OS X packaging is an embarrassment > I've since come to the conclusion that FreeBSD's ports system is apparently > great for those people who like to do everything manually, but it's like > kryptonite for anyone trying to automate. Have you looked at doing "make package" instead of "make install"? Have you looked at "portupgrade"?
From: Luke Kanies Date: 23:53 on 21 May 2006 Subject: Re: OS X packaging is an embarrassment On Sun, 21 May 2006, Peter da Silva wrote: > Have you looked at doing "make package" instead of "make install"? Yeah, but that sucks just as much for my purposes. I have a package name, something like "openssh"; on any other platform, just that name is enough to do just about everything I need, and basically every operation is a single step, although sometimes I need to specify a file to operate on (e.g., Sun boxes require a source for the package). For FreeBSD, I have to convert that package name to a port name, and then I have to cd into the stupid port directory and then I have to run "make package". "make package" is not significantly better than "make install" for the purposes of automation, which is to say, introspection and interaction with the computer. Oh, and because I happen to have INTERACTIVE and UNAME set in my environment for my own use, ports don't actually work at all; took me for freaking ever to figure that one out, but it's an easy fix. > Have you looked at "portupgrade"? Yeah, and that basically works fine, once I've converted the package name to a port name, and once I know that I actually need to upgrade. That's not the hard part. Again, I'm sure this is great for people who like having their own synchronous conversations with computers. I don't work like that, and FreeBSD is easily twice as difficult as anything else out there as a result, even when I have to hunt the stupid packages down myself. Why go to all that effort to make things "easy" if it's not easy to hand off to a computer? It's stupid.
From: peter (Peter da Silva) Date: 01:43 on 22 May 2006 Subject: Re: OS X packaging is an embarrassment > For FreeBSD, I have to convert that package name to a port name, Which can be trivially automated. > and then I > have to cd into the stupid port directory and then I have to run "make > package". Which can be trivially automated. > "make package" is not significantly better than "make install" > for the purposes of automation, which is to say, introspection and > interaction with the computer. If you want to do multiple installs (which is when that trivial automation mentioned above becomes worth arsing around with) the result is that you have a package that you can pkg_add on the rest of your boxes. > Again, I'm sure this is great for people who like having their own > synchronous conversations with computers. I don't find that FreeBSD forces me to have conversations with my computer. Linux kernel configuration, however... > Why go to all that effort to make things "easy" if it's not easy to hand off > to a computer? It's stupid. Because it's easy to hand off to a computer?
From: Luke Kanies Date: 04:45 on 22 May 2006 Subject: Re: OS X packaging is an embarrassment On Sun, 21 May 2006, Peter da Silva wrote: > > For FreeBSD, I have to convert that package name to a port name, > > Which can be trivially automated. luke@freebsd1(0) $ ports_glob '*openldap-client*' net/openldap22-client net/openldap23-client Which one do you pick? FreeBSD has a default version you can use, but, well, you have to manually specify that you would like to use the default version. Expect scripts, here I come! > > and then I > > have to cd into the stupid port directory and then I have to run "make > > package". > > Which can be trivially automated. Hah! "trivial" and "make", in the same sentence. Sweet! > > "make package" is not significantly better than "make install" > > for the purposes of automation, which is to say, introspection and > > interaction with the computer. > > If you want to do multiple installs (which is when that trivial automation > mentioned above becomes worth arsing around with) the result is that you > have a package that you can pkg_add on the rest of your boxes. Except that FreeBSD ships with no tools that can be used to determine if the installed package is the latest version available. The only tool that could work, portversion, checks the ports directory and the package directory, whether you want it to or not. I could find no evidence of a way to only check the package source. So sure, it's automatable, as long as you don't mind every FreeBSD system attempting to upgrade very single package every time you run your verification tool, since every package will show a new port available. Thanks! > > Again, I'm sure this is great for people who like having their own > > synchronous conversations with computers. > > I don't find that FreeBSD forces me to have conversations with my computer. When was the last time you tried to completely automate one? > Linux kernel configuration, however... I use a Linux box every day, and I do stuff with it that should definitely not be done, and I have not had to configure my kernel or make my own kernel in at least three years. And frankly, I it's just silly to talk about "Linux"; talk about Debian, or Red Hat, or Gentoo, but there is no "Linux". There's only one FreeBSD distribution, but each Linux distro is unique and should be treated as a completely separate OS. If you use Slackware, you get what you deserve, but I defy you to somehow find Debian more execreble than FreeBSD. > > Why go to all that effort to make things "easy" if it's not easy to hand off > > to a computer? It's stupid. > > Because it's easy to hand off to a computer? Then you're a better man than I am. That's been part of my job for the last three months, and without exception I've been able to automate everything faster on every other OS than on FreeBSD. Have you actually handed it off? Have you done so in a way that's generic, and whose model can be used on other OSes? Sure, anyone can write a one-off imperative script for any OS; but I contend that if you had to write a single tool that could treat any set of, say, three operating systems equally, then you would find FreeBSD to be the most difficult to model successfully. And that's because it's a pain in the ass to automate, no matter how great it was 15 years ago, or how easy "make install" seems. Yuck.
From: David Champion Date: 07:06 on 22 May 2006 Subject: Re: OS X packaging is an embarrassment * On 2006.05.21, in <Pine.LNX.4.58.0605212232230.32130@xxxxxx.xxxxxxx.xxx>, * "Luke Kanies" <luke@xxxxxxx.xxx> wrote: > > If you use Slackware, you get what you deserve, but I defy you to somehow > find Debian more execreble than FreeBSD. I'd really like to, since you're defying, but I've buried those memories deep. We'll have to settle for "yup, did that." > and whose model can be used on other OSes? Sure, anyone can write a one-off > imperative script for any OS; but I contend that if you had to write a > single tool that could treat any set of, say, three operating systems > equally, then you would find FreeBSD to be the most difficult to model > successfully. Which are the other two?
From: Luke Kanies Date: 15:34 on 22 May 2006 Subject: Re: OS X packaging is an embarrassment David Champion wrote: > * On 2006.05.21, in <Pine.LNX.4.58.0605212232230.32130@xxxxxx.xxxxxxx.xxx>, > * "Luke Kanies" <luke@xxxxxxx.xxx> wrote: >> If you use Slackware, you get what you deserve, but I defy you to somehow >> find Debian more execreble than FreeBSD. > > I'd really like to, since you're defying, but I've buried those > memories deep. We'll have to settle for "yup, did that." I guess I should have added a "now" on the end there. >> and whose model can be used on other OSes? Sure, anyone can write a one-off >> imperative script for any OS; but I contend that if you had to write a >> single tool that could treat any set of, say, three operating systems >> equally, then you would find FreeBSD to be the most difficult to model >> successfully. > > Which are the other two? Solaris and Debian, if I get to pick. I'd recommend HP-UX and OS X if you're trying to make FreeBSD win (I never did find an automated way to reboot HP-UX nicely), but at least both of those OSes have a real concept of a service.
From: Martin Ebourne Date: 08:55 on 22 May 2006 Subject: Re: OS X packaging is an embarrassment On Sun, 2006-05-21 at 19:43 -0500, Peter da Silva wrote: > Linux kernel configuration, however... Whatever are you doing that requires you to configure the kernel?? The only time I've had to do that in recent memory was to fix a broken DSDT when I bought a bleeding edge laptop. Even that was worked around a couple of kernel versions later - are we expecting the kernel team to fortune tell on what hardware vendors might break next? Some linux distros don't even need a recompile for a broken DSDT anyway. I run Fedora on a range of hardware and really don't recognise any of the problems you're reporting. But then you don't seem to have used any Linux machines seriously since, well, five years ago? Sure some of the complaints were valid then (and still are on some distros) but all the mainstream ones are with it these days. And all are improving faster than any other OS on the planet, so soon they'll be way ahead (and they already are in a number of areas). Cheers, Martin. PS. I actually found linux kernel config really rather easy last time I did it. Download the .src.rpm, install it (using the normal package install command), tweak the .config file and rpmbuild it. Then it installs using my normal package manager and is handled just like a distro package. I've never seen any other OS I could do that on in less than 4 steps.
From: Peter da Silva Date: 11:39 on 22 May 2006 Subject: Re: OS X packaging is an embarrassment On May 22, 2006, at 2:55 AM, Martin Ebourne wrote: > Whatever are you doing that requires you to configure the kernel?? Building a custom boot floppy to do remote installs with a special spin. PicoBSD turned out to be just the thing. > I run Fedora on a range of hardware and really don't recognise any of > the problems you're reporting. But then you don't seem to have used any > Linux machines seriously since, well, five years ago? Last June was the last time, but I get roped in to hacking up Linux for projects on a distressingly regular basis, when the Linux fanboys in the office can't figure out how to get something particularly twisted working. I suppose the fact that I only get involved with Linux when something's already broken means I get to see more of the hateful stuff, and certainly I'd rather deal with Linux than Windows (which I also get called in to troubleshoot on a distressingly regular basis). > PS. I actually found linux kernel config really rather easy last time I > did it. Download the .src.rpm, install it (using the normal package > install command), tweak the .config file and rpmbuild it. Then it > installs using my normal package manager and is handled just like a > distro package. I've never seen any other OS I could do that on in less > than 4 steps. FreeBSD: # vi /sys/i386/conf/CONFIGNAME # config CONFIGNAME # cd /sys/compile/CONFIGNAME # make install Tru64: # vi /usr/sys/conf/CONFIGNAME # echo n | doconfig -c CONFIGNAME # cp /usr/sys/CONFIGNAME/vmunix /vmunix Most any BSD-derived system is similar. Having to "echo n" to doconfig to keep it from throwing you into "vi" or hanging on "Do you want to edit the config file" is hateful, but since doconfig is just a wrapper around config I could avoid that tiny hate if I hated it enough.
From: Martin Ebourne Date: 12:21 on 22 May 2006 Subject: Re: OS X packaging is an embarrassment Peter da Silva <peter@xxxxxxx.xxx> wrote: > On May 22, 2006, at 2:55 AM, Martin Ebourne wrote: >> Then it >> installs using my normal package manager and is handled just like a >> distro package. I've never seen any other OS I could do that on in less >> than 4 steps. > > FreeBSD: > # vi /sys/i386/conf/CONFIGNAME > # config CONFIGNAME > # cd /sys/compile/CONFIGNAME > # make install > > Tru64: > # vi /usr/sys/conf/CONFIGNAME > # echo n | doconfig -c CONFIGNAME > # cp /usr/sys/CONFIGNAME/vmunix /vmunix That doesn't seem to be the same thing at all. Sure, you've =20 reconfigured and rebuilt the kernel. But you've not ended up with a package install which can be usefully =20 tracked on your machine. Let alone installed on a different machine =20 (what, you have a compiler on every machine?). And have dependencies =20 managed for you as well. Any unix can do configure && make install, great. The instructions I gave produce an RPM package every bit as complete =20 and reusable as the original vendor one, which from a position of =20 managing multiple machines (or even just reliably managing one) is a =20 totally different result. Cheers, Martin.
From: peter (Peter da Silva) Date: 13:30 on 22 May 2006 Subject: Re: OS X packaging is an embarrassment > That doesn't seem to be the same thing at all. Sure, you've > reconfigured and rebuilt the kernel. Which was the problem at hand. > Any unix can do configure && make install, great. Except Linux.
From: jrodman Date: 13:58 on 22 May 2006 Subject: Re: OS X packaging is an embarrassment On Mon, May 22, 2006 at 07:30:21AM -0500, Peter da Silva wrote: > > That doesn't seem to be the same thing at all. Sure, you've > > reconfigured and rebuilt the kernel. > > Which was the problem at hand. > > > Any unix can do configure && make install, great. > > Except Linux. vi .config; make bzlilo, next? This is all getting tiresome. I though this was "hate software" not "my hateful software is slightly better than your hateful software'. Hate stemming from immediate direct experience is crisp, raw, acrid, and glorious. "6 years ago I walked up a hill both ways in the snow and ..." is vastly inferior.
From: Luke Kanies Date: 19:23 on 21 May 2006 Subject: Re: OS X packaging is an embarrassment On Sun, 21 May 2006, Daniel Pittman wrote: > Is hating the hardware allowed here? Because, in a short while you > surely will, assuming that you don't mean the Pro version here: > > > So I picked up a MacBook yesterday, for various reasons but mostly because > > my 12" powerbook feels really slow these days. > > [...] > > > And, of course, even though my motivation for buying this machine was > > because my 12" feels really slow, this machine feels just about as slow. > > Particularly, if I am doing more than one thing at a time -- say, Firefox is > > loading a tab, and I switch workspaces -- then the whole machine bogs down > > just as badly as my 12" did. I/O seems to just kill OS X. > > From the Tech Specs: > > Intel GMA 950 graphics processor with 64MB of DDR2 SDRAM > shared with main memory > > Thanks Apple, for investing so much in using the GPU to provide advanced > video display effects ... then dumping the GPU for a half-assed shared > memory system with very little hardware acceleration in your current > MacBook line. > > At least they kept a real GPU in the MacBookPro. I don't actually think that's the problem. It seems to be much, much more I/O related than anything else. > Plus, MacBook: worst product name ever. > > Daniel > > This is why I continue to not buy Apple. I really don't want to use > Linux or *BSD on this machine but, frankly, Apple is /not/ a step up. If I wanted to run one of those, I'd just buy a thinkpad. *shudder* I ran Linux on an X31 for a while, and I hope never to have to repeat it. > Why can't I run OSX on something built like an IBM Thinkpad, you > bastards? That would be nice. Seems quite likely this MacBook is going back, though, 10% restocking fee and all. Too hot, SSHKeyChain (or something else) seems to be locking it up constantly, and the I/O is just too debilitating ATM.
From: Robert G. Werner Date: 06:25 on 22 May 2006 Subject: Re: OS X packaging is an embarrassment Luke Kanies wrote: [snip] > > If I wanted to run one of those, I'd just buy a thinkpad. *shudder* I ran > Linux on an X31 for a while, and I hope never to have to repeat it. > I've had good luck running Linux on an X20 for the past couple of versions of Fedora. Can't think of anything that didn't work right off. I thought Thinkpads worked pretty well. What kind of troubles did you have (if you don't mind titilating us with your agony ;-))?
Generated at 10:26 on 16 Apr 2008 by mariachi