From: Michael G Schwern Date: 00:31 on 29 Apr 2005 Subject: Utilities vs Applications Apple wisely placed all applications into a simple, flat /Applications directory as opposed to scattering them all over the filesystem or creating some sort of hierarchy. This is good. Now I can find shit. So I get on a Mac and I look in Applications for X11... its not there. Terminal? Not there. Digital Color Meter? Not there. Grab? NetInfo? ColorSync? Console? Not bloody there! OOhhhhhhh, they're cleverly hidden in /Applications/Utilities. What's a utility? What's the difference between an application and a utility? How do I decide which is which? Why is a program to take a screenshot (Grab) a utility and one to decompress a file (Stuffit Expander) an application? iSync is an application but RsyncX is a utility. How is a user supposed to know the difference? Why even have this artificial split? About the only distinction I can see is Apple put things into Utilities it would rather its dumb users not stumble onto such as the Terminal or X11 or the Disk Utility lest they shoot themselves in the foot and generate money wasting support calls. Ok, maybe I can see that... but Grab? Just how much trouble can you get into making screenshots? Unix does this, too, with the whole bin vs sbin thing. traceroute and ifconfig being the two I'm always losing. As always... hate.
From: David Champion Date: 00:41 on 29 Apr 2005 Subject: Re: Utilities vs Applications * On 2005.04.28, in <20050428233116.GA15440@xxxxxxxx.xxxxxxx.xxx>, * "Michael G Schwern" <schwern@xxxxx.xxx> wrote: > > How is a user supposed to know the difference? Why even have this artificial > split? The split makes sense to me. It's Apple's choices for each category that make no sense. > Unix does this, too, with the whole bin vs sbin thing. traceroute and > ifconfig being the two I'm always losing. That's a hate, indeed, because it used to mean something, once upon a time. Sbin was for static tools, the sort of thing you don't want to crap out because your libc is hosed, or not yet mounted. These days no vendors put any stock in separation or recoverability. Most would prefer to stow everything onto one filesystem and dynamlically link everything. On Solaris it's getting near impossible to static-link anything, because basic OS services are *able* to use DSOs for lookups and such, and libdl only comes shared. HATE. Actually I've all but given up hating in this arena. Sanity lost that battle years ago.
From: Michael G Schwern
Date: 01:08 on 29 Apr 2005
Subject: Re: Utilities vs Applications
On Thu, Apr 28, 2005 at 06:41:09PM -0500, David Champion wrote:
> > How is a user supposed to know the difference? Why even have this artificial
> > split?
>
> The split makes sense to me. It's Apple's choices for each category
> that make no sense.
Maybe you could explain why it makes sense to someone whose eyes are too
blind with fury to see it.
> > Unix does this, too, with the whole bin vs sbin thing. traceroute and
> > ifconfig being the two I'm always losing.
>
> That's a hate, indeed, because it used to mean something, once upon a
> time. Sbin was for static tools, the sort of thing you don't want to
> crap out because your libc is hosed, or not yet mounted.
Isn't that /bin vs /usr/bin (and /sbin vs /usr/sbin) ?
OS X, curse it, does not staticly compile their /bin executables.
$ otool -L /bin/ls
/bin/ls:
/usr/lib/libncurses.5.dylib (compatibility version 5.0.0, current version 5.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 71.0.0)
Debian does an ok job in at least everything is linked against /lib
instead of /usr/lib so you can get somewhere if /usr craps out. This is
at least on par with the FHS.
schwern@mungus:~$ ldd /bin/ls
librt.so.1 => /lib/librt.so.1 (0x40021000)
libacl.so.1 => /lib/libacl.so.1 (0x40033000)
libc.so.6 => /lib/libc.so.6 (0x4003a000)
libpthread.so.0 => /lib/libpthread.so.0 (0x4016d000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
libattr.so.1 => /lib/libattr.so.1 (0x401be000)
> These days
> no vendors put any stock in separation or recoverability. Most would
> prefer to stow everything onto one filesystem and dynamlically link
> everything. On Solaris it's getting near impossible to static-link
> anything, because basic OS services are *able* to use DSOs for lookups
> and such, and libdl only comes shared. HATE.
>
> Actually I've all but given up hating in this arena. Sanity lost that
> battle years ago.
Set the way back machine to circa 1998. Linux/PowerPC is just getting off
the ground. I'm sick of running MacOS 9 on my Wallstreet Powerbook so I
install Debian/PowerPC in its early days. One of the more fun things about it
was libc would be broken about one in every three updates which in turn
broke... well everything including the ability to put in a new libc.
As a fledging unix admin I rapidly learned how staticly compile all my
basic utilities. fileutils, textutils, bash, etc... and set root to use
sash (Stand Alone SHell). I learned ALOT from those days.
From: Robert G. Werner Date: 04:29 on 29 Apr 2005 Subject: Re: Utilities vs Applications Michael G Schwern wrote: [snip] > As a fledging unix admin I rapidly learned how staticly compile all my > basic utilities. fileutils, textutils, bash, etc... and set root to use > sash (Stand Alone SHell). I learned ALOT from those days. > > Talk about learning by doing. I can just imagine the hatfulness oozing out of that situation. Upgrading glibc was why I decided I needed some sort of package manager on linux.
From: peter (Peter da Silva) Date: 11:47 on 29 Apr 2005 Subject: Re: Utilities vs Applications > Talk about learning by doing. I can just imagine the hatfulness > oozing out of that situation. Yeh, you needed to wear a lot of hats in those days.
From: peter (Peter da Silva) Date: 11:57 on 29 Apr 2005 Subject: Re: Utilities vs Applications > Isn't that /bin vs /usr/bin (and /sbin vs /usr/sbin) ? No, the /bin vs /usr/bin is an older split, from before the days of shared libraries. /bin was operating system stuff that you always needed, so you put it in the system disk. /usr/bin was stuff that users needed so you put it on the user disk which wasn't always mounted. That's when an RL01 was 5MB and an RL02 was 10MB and a fast fixed head disk like you might have root or swap on if you were a real hotrodder was often less than 1MB, with bits almost big enough to read with a pinch of iron filings. One day I walked into Cory Hall and saw the DEC PM spit-polishing the surface of the swap disk on the undergraduate 11/70. Great days, boys, great days indeed.
From: Robert G. Werner Date: 09:36 on 30 Apr 2005 Subject: Re: Utilities vs Applications Peter da Silva wrote: >>Isn't that /bin vs /usr/bin (and /sbin vs /usr/sbin) ? > > > No, the /bin vs /usr/bin is an older split, from before the days of > shared libraries. /bin was operating system stuff that you always > needed, so you put it in the system disk. /usr/bin was stuff that users > needed so you put it on the user disk which wasn't always mounted. > > That's when an RL01 was 5MB and an RL02 was 10MB and a fast fixed head > disk like you might have root or swap on if you were a real hotrodder > was often less than 1MB, with bits almost big enough to read with a > pinch of iron filings. One day I walked into Cory Hall and saw the DEC > PM spit-polishing the surface of the swap disk on the undergraduate > 11/70. Great days, boys, great days indeed. > > Guys who go as far back as you do should be declaird national treasures just for the lore you hold ;-).
From: peter (Peter da Silva) Date: 01:01 on 29 Apr 2005 Subject: Re: Utilities vs Applications > What's a utility? What's the difference between an application and a > utility? A utility is apparently something that Apple wrote that the user is not normally expected to run directly. It's subjective, yes, and some of the choices are weird. I don't "get" Grab. Stuffit is an Application because whoever owns it this week said so. iSync because it's Important (me, I hate it, I've got a Clie full of duplicate address records because it sucks).
From: Chris Devers Date: 02:17 on 29 Apr 2005 Subject: Re: Utilities vs Applications On Thu, 28 Apr 2005, Peter da Silva wrote: > A utility is apparently something that Apple wrote that the user is > not normally expected to run directly. Oh, but it's more fun than that. The "normally" in that sentence is important: they're saying that in most cases, most people wouldn't want to run any of these programs, but sometimes you might, so they put them somwhere that, with a little effort, they'll turn up eventually. By contrast, take a look in your /System/Library/CoreServers folder, where all kinds of interesting things like. Finder. Dock. Help Viewer. Software Update. loginwindow. Et cetera. Now, okay, sure, these ones probably really shouldn't be invoked directly by casual users, but why are these ones squirrelled away somewhere so obscure, when other ones that seem just as esoteric are out in the open in the Utilities folder? Why, for example, is Network Setup Assistent hidden under the System folder, but the Airport, Bluetooth, and Printer Setup Assistants aren't? The argument is probably that the latter are all more likely to come up on a system that has been up & running for a while, while the Network Setup Assistant is only ever likely to be run once, at the beginning. But in that case, why not just have it delete itself after finishing? Hidden away like it is, it's not like most people will find it to run it again later, so why waste the disc space? There's some logic to this, but it seems pretty tenuous... > iSync because it's Important (me, I hate it, I've got a Clie full of > duplicate address records because it sucks). Yeah, that was fun. Only took me a weekend to clean up, too :-/ Supposedly, Tiger breaks backwards compatibility with iSync in such a way that it'll tend to want to duplicate everything *again*: <http://www.macfixit.com/article.php?story=20050426071411251&query=isync>; I predict many headaches from just this one "feature". Yay.
From: peter (Peter da Silva) Date: 02:27 on 29 Apr 2005 Subject: Re: Utilities vs Applications > On Thu, 28 Apr 2005, Peter da Silva wrote: > Setup Assistant is only ever likely to be run once, at the beginning. > But in that case, why not just have it delete itself after finishing? Because then when you removed /var/db/netinfo to get the system back to factory settings it wouldn't be there to run. > Supposedly, Tiger breaks backwards compatibility with iSync in such a > way that it'll tend to want to duplicate everything *again*: Another reason I'm glad I went back to Palm Desktop.
From: John Sinteur Date: 05:50 on 29 Apr 2005 Subject: Re: Utilities vs Applications On Apr 29, 2005, at 1:31, Michael G Schwern wrote: > money wasting support calls. Ok, maybe I can see that... but > Grab? Just > how much trouble can you get into making screenshots? Back in the days of Mac OS 7 or 8 or so, all memory space was shared, and virtual memory wasn't really something you could count on. Somebody I know had an application out that reserved some memory at startup (32K to be exact), and whenever a memory allocation call failed, he would free that 32K so the application would be able to run for just a little while longer, and he would put up an alert: "memory is getting too low to continue. please save your work and stop the application. do not try to do anything else". Not this exact words, but it would get the message across, or so we hoped. Until one day when we got a support call from a user who attemted to make a screen shot at this point, to show to support with the question what to do. The screenshot utility starved the machine of memory to the point where it crashed totally, hosing the users work. I recall the walls getting some extra dents that day from us banging our heads against it. -John
Generated at 10:26 on 16 Apr 2008 by mariachi