From: Luke Kanies Date: 18:11 on 21 Apr 2005 Subject: MP3 players? Linux? I'm not sure, but I know there's hate I don't know why MP3 players and audio are so hard; I really don't. Getting MP3s to work on Gentoo was hours and hours of work, and it only got worse when I wanted to use my external USB headphone amp. But I'm doing something theoretically simple here: I want to play music on my computer, in the least obtrusive and most efficient manner, I want hotkeys to control the playing, and I want simple mechanisms to manage what music I'm playing. So, I've been using XMMS for years, even though its usability is about, oh, 1992. But recently its complete uselessness when it comes to playlists became too much for me. So, I tried rhythmbox again, for about the ninth time. It only lasted about 2 weeks (it just periodically stopped playing with some kind of weird error, it has about 1/10 the prefs it needs, it does absolutely rediculous things with refresh while it's loading the MP3 library, and it finally just played static constantly), but it highlighted another annoying-ass aspect of using mp3 players: I always set up hotkeys for forward, reverse, and pause, because I do them often and I hate having to switch around finding the stupid mp3 player. Well, obviously, I have to switch the hotkeys when I switch mp3 players. So, today, I finally wrote an abstraction for the two players in question, so I can just modify the script (basically just switching default players) and the hotkeys will automatically work, because they're just pointing to my script. Yes, I could have just had the script search through the process table to see which one was running, but I didn't feel like it. This just seems bloody stupid, but I'm not sure who's to blame. Me, for demanding too much? (Nope.) The mp3 players for sucking so much? Metacity, for having such absolutely retarded mechanisms for setting hotkeys (2 years and it _still_ requires me to set the key and command separately, within GConf)? Gnome, for not having a good, integrated mp3 player, or even better, a good mechanism for integrating any mp3 player, or any app? Linux, for not having an even lower-level good mechanism for integrating mp3 players, or any other apps? All OSes, because they basically all lack this feature? I mean, come on; classes of applications (like mp3 players) are members of a class because they share similar features. In some cases those features are not exposed externally (e.g., one might not generally refer to an internal feature of both Gimp and Photoshop in the same way, although it seems like it'd be great to be able to call a filter in either one through an external interface), but in many cases each member of the class has similar features that you want to call from outside the app, say, through hotkeys. Why the hell don't OSes recognize this and make it simple to register applications as members of a class, with the same interface? Then allow the user to pick which member to use, and then send most/all actions through that interface, and the stupid interface is responsible for finding the correct command on the correct app? Why do the damn operating systems expect me to know how everything works? I want music played through my computer, and I want hotkeys that allow me to quickly pause or fast-forward, and I want some mechanism for managing my music. I frankly don't care how this is done, but I categorically don't want to spend 5 hours a month just making sure it all fucking works. Stupid computers.
From: peter (Peter da Silva) Date: 22:17 on 21 Apr 2005 Subject: Re: MP3 players? Linux? I'm not sure, but I know there's hate > I don't know why MP3 players and audio are so hard; I really don't. I do. It's because audio cards aren't just dumb buffered D/A converters, they've got half a dozen legacy interfaces from the old days when you had to shove everything in through a 16-64k window, plus MIDI players from the old days when PCs were singletasking and games took over the machine and the serial port MIDI player connection was the only thing they could depend on, plus thirty dozen plain and fancy incompatible equalizer interfaces, and a joystick port, and now half these things are implemented in the Windows driver in a different way for each card. And MP3 players are hard because the skinnable interface is more important than actually making it work well. XMMS used to drive me insane on a regular basis just for existing. > All OSes, because they basically all lack this feature? CoreAudio seems pretty solid, but it doesn't have to deal with any of the Wintel legacy audio crap listed above. > Why do the damn operating systems expect me to know how everything > works? I want music played through my computer, and I want hotkeys that > allow me to quickly pause or fast-forward, and I want some mechanism for > managing my music. I frankly don't care how this is done, but I > categorically don't want to spend 5 hours a month just making sure it > all fucking works. You are SO ready for a Mac.
From: Luke Kanies Date: 16:02 on 22 Apr 2005 Subject: Re: MP3 players? Linux? I'm not sure, but I know there's hate On Thu, 2005-04-21 at 16:17 -0500, Peter da Silva wrote: > It's because audio cards aren't just dumb buffered D/A converters, they've > got half a dozen legacy interfaces from the old days when you had to shove > everything in through a 16-64k window, plus MIDI players from the old days > when PCs were singletasking and games took over the machine and the serial > port MIDI player connection was the only thing they could depend on, plus > thirty dozen plain and fancy incompatible equalizer interfaces, and a joystick > port, and now half these things are implemented in the Windows driver in a > different way for each card. I would agree with you except that it's never really the drivers or whatever that appears to be the problem; it's the audio stream in the OS. Stupid computers. > And MP3 players are hard because the skinnable interface is more important > than actually making it work well. XMMS used to drive me insane on a regular > basis just for existing. The only thing that drives me more insane than XMMS's existence is that it's the only stable GUI mp3 player on Linux. > > All OSes, because they basically all lack this feature? > > CoreAudio seems pretty solid, but it doesn't have to deal with any of the > Wintel legacy audio crap listed above. > > > Why do the damn operating systems expect me to know how everything > > works? I want music played through my computer, and I want hotkeys that > > allow me to quickly pause or fast-forward, and I want some mechanism for > > managing my music. I frankly don't care how this is done, but I > > categorically don't want to spend 5 hours a month just making sure it > > all fucking works. > > You are SO ready for a Mac. Frankly, Apple is going in the exact opposite direction from what I want -- they're building these functional silos, which might be available via AppleScript or something but generally aren't actually open. Look at iTunes -- it's walled off, and expects to be the only one ever touching its stuff. It's difficult to do syncs between machines, it's difficult to generate playlists through other mechanisms, it's difficult to switch back and forth between different mp3 players, etc. I think OS X is a great OS, but I fucking hate how much Steve Jobs believes in developer control. BeOS was much more interested in user control, which is why they did things like develop Translators for graphical formats. I want all of my applications to be turned inside out; rather than there being a hard shell around all of the functionality, with some limited exposure to that functionality from the outside, I want the whole app to be available from the outside, including the ability to swap pieces in and out according to whim. I do know why this isn't possible, though: because it gives _me_ control of the app, instead of Steve-o, which doesn't fit with his megalomaniacal world model. Thank God Apple is still a niche player -- if they ever got to be as big as Microsoft, I'm convinced they would be 10x worse.
From: peter (Peter da Silva) Date: 20:02 on 22 Apr 2005 Subject: Re: MP3 players? Linux? I'm not sure, but I know there's hate > Look at iTunes -- it's walled off, and expects to be the only one ever > touching its stuff. It's difficult to do syncs between machines, it's > difficult to generate playlists through other mechanisms, it's difficult > to switch back and forth between different mp3 players, etc. Hmmm. I use "cp -pR" to copy my iTunes Music Library to my USB hard drive to take it to work. I have even used "find ... | grep -l" to generate an m3u file for a share. > I want all of my applications to be turned inside out; rather than there > being a hard shell around all of the functionality, with some limited > exposure to that functionality from the outside, I want the whole app to > be available from the outside, including the ability to swap pieces in > and out according to whim. I guess we have different ideas of what this means, because Mac OS seems to be better about this than just about any environment I've used. I mean, I can do stuff to GUI apps on OS X that require source code to do on anything else, whether through Applescript, through the files in the Appdir, or just editing their defaults databases... and while it's nice to have source it sure makes Applescripting look friendly. The opacity of GUI apps on EVERY OTHER OS has been a burning hate for me for years. Mac OS X is like Maalox for my geek soul. > I do know why this isn't possible, though: because it gives _me_ > control of the app, instead of Steve-o, which doesn't fit with his > megalomaniacal world model. Thank God Apple is still a niche player -- > if they ever got to be as big as Microsoft, I'm convinced they would be > 10x worse. That may be true, but that doesn't mean they haven't done a good job here. But then I'm weird, I find good things in every OS, even ones that drive me to despite and despair, so maybe I'm a soft touch.
From: Luke Kanies Date: 20:47 on 22 Apr 2005 Subject: Re: MP3 players? Linux? I'm not sure, but I know there's hate On Fri, 2005-04-22 at 14:02 -0500, Peter da Silva wrote: > Hmmm. I use "cp -pR" to copy my iTunes Music Library to my USB hard drive > to take it to work. I have even used "find ... | grep -l" to generate an m3u > file for a share. I have two powerbooks, two ipods, and multiple Unix machines, all of which I want to have the same music on. However, my wife and I make our own playlists. I want to be able to sync everything in a way that all of the information is available everywhere, including the playlists that each of make. Yes, I'm fully aware that I could manually do that somehow, by parsing the XML files and rewriting them as .m3u files or whatever, but of course that won't work for automatic lists (which is fine, I guess), and I just shudder at the idea of what would happen if I somehow did something iTunes didn't like to its library -- I have already had to rebuild my whole library, including all playlists because I moved the library, opened iTunes, and moved it back. No idea what went wrong, but I never got it to understand its configuration again, so I had to rebuild it from scratch. Not exactly encouraging that it'll be easy to write sync stuff. It doesn't help that Apple seems to despise the mere idea of you syncing in a way they don't approve, or with devices you didn't buy from them. Those guys are dicks sometimes -- I'm pissed that all this extra functionality is being added to .Mac, but if I just want to sync two accounts on two Macs, I have to have a stupid .Mac account. WTF? > > I want all of my applications to be turned inside out; rather than there > > being a hard shell around all of the functionality, with some limited > > exposure to that functionality from the outside, I want the whole app to > > be available from the outside, including the ability to swap pieces in > > and out according to whim. > > I guess we have different ideas of what this means, because Mac OS seems > to be better about this than just about any environment I've used. I mean, > I can do stuff to GUI apps on OS X that require source code to do on anything > else, whether through Applescript, through the files in the Appdir, or just > editing their defaults databases... and while it's nice to have source it > sure makes Applescripting look friendly. > > The opacity of GUI apps on EVERY OTHER OS has been a burning hate for me for > years. Mac OS X is like Maalox for my geek soul. Heh, I didn't mean to imply that other people did this well, just that 1) OS X still does it poorly, and 2) Apple is generally retardly protective and hates you touching their stuff. > > I do know why this isn't possible, though: because it gives _me_ > > control of the app, instead of Steve-o, which doesn't fit with his > > megalomaniacal world model. Thank God Apple is still a niche player -- > > if they ever got to be as big as Microsoft, I'm convinced they would be > > 10x worse. > > That may be true, but that doesn't mean they haven't done a good job here. > > But then I'm weird, I find good things in every OS, even ones that drive me > to despite and despair, so maybe I'm a soft touch. You're right: that is weird. ;)
From: Chris Devers Date: 22:33 on 21 Apr 2005 Subject: Re: MP3 players? Linux? I'm not sure, but I know there's hate On Thu, 21 Apr 2005, Luke Kanies wrote: > Getting MP3s to work on Gentoo was hours and hours of work Stop right there, doctor, I think we've diagnosed the problem. "Doctor doctor, it hurts when I do this." "Then don't do that." As Peter said, you are *so* ready for a Mac... Really, does anyone use Linux as a desktop computer and *enjoy* the experience? Sure, it's an educational experience to have to tweak every damned thing just to do *any* tamned thing, but at what point does it cease to be educational and start to be self-punishment? I think it stopped being fun for me about five years ago. Why anyone would willfully decide to fight against Linux audio, or setting up X-Windows (really, who gives a damn about all the parameters in XF86Config-4? What human should ever have to care about the monitor's HorizSync and VertRefresh rates?) is a complete mystery to me. Sure, it's nice for a server, but the best way to deal with Linux is by keeping it at the far end of a remote ssh session, not sitting on your desk where the ferocious little monster can rip your face off. As Peter said, you are *so* ready for a Mac...
From: Juerd Date: 10:17 on 22 Apr 2005 Subject: Re: MP3 players? Linux? I'm not sure, but I know there's hate Chris Devers skribis 2005-04-21 17:33 (-0400): > Really, does anyone use Linux as a desktop computer and *enjoy* the > experience? Yes, I do. Even though I have been using a Mac for over a month now, I'm glad that at work, I still use Linux. My distribution of choice is Debian. I like that with a simple command, or a simple instruction in one of the GUI frontends, I can install almost any kind of software. If I want to install an MP3 player, I can just try a dozen and pick the one that I liked best and remove the others. (I'm not too picky about this, so I usually settle for Noatun, the media player that comes with KDE.) I've used Gentoo, and indeed, it can be hours before something works. Partly because you need to do a lot of configuration manually, partly because compiling things yourself will always take much longer than just installing binaries. As for the desktop experience, I think that KDE manages this very well. Gnome does too, but I find its simplicity too restrictive. The thing that Windows provides over KDE is some weird kind of consistency between Microsoft software, and bizarre integration between anything. Mac OS X just provides Expose and eyecandy and really not much more than that in terms of usability. You have to install third party utilities for things like virtual desktops and a run program dialog. My dad works with linux too (Kubuntu in particular, after months of Ubuntu). He doesn't know anything about computers and needed me for the initial installation and configuration, but he's using it without any problem and asks for my help much less than he did with MS Windows. I think that in desktop experience, a well organized (non-bloated) Linux distribution and Mac OS X are on the same level, somewhere high above Windows. The problem with most Linux-haters is that they're stuck with an image of how geeks use the platform (in the form of Gentoo, for example), or of a bloated default installation (SuSE, Red Hat, anything with a full KDE installed), or of how Linux used to be years ago. Linux only recently became a good platform for desktop use. > Sure, it's an educational experience to have to tweak every > damned thing just to do *any* tamned thing, but at what point does it > cease to be educational and start to be self-punishment? That is exactly what I mean with how a geek uses Linux. This way of working with an OS is a choice made by the user, as it's by no means necessary. > I think it stopped being fun for me about five years ago. Five years. Have you really no idea of how much has improved in that time? > Why anyone would willfully decide to fight against Linux audio, or > setting up X-Windows (really, who gives a damn about all the parameters > in XF86Config-4? What human should ever have to care about the monitor's > HorizSync and VertRefresh rates?) is a complete mystery to me. Either because they're a geek, or because they picked a rather stupid distribution. Again, with many user friendly distributions, including Ubuntu/Kubuntu, stuff like this is not necessary. X is automatically configured, audio (full duplex, works very well with Skype too) was also automatically configured. And if you WANT TO (for example, because you know your hardware can do more than was autodetected, or because you want to tweak things to more extreme settings, or because you have hardware that in Linux can't be autoconfigured), you can dive into the internals and set things manually there. But that's your choice, unless you do indeed have incompatible (too recent or too exotic) hardware, in which case you should probably just not use Linux. Or a Mac, for that matter. > As Peter said, you are *so* ready for a Mac... So was I. And then I bought a Mac Mini, only to after a month realize that Mac OS X is software like all other, and deserves a good piece of hate. I hate how my terminals sometimes lose their access hotkeys. I hate how in iCal it's very easy to accidentally create an appointment, but it's very hard to delete it. I hate how clicking a dock icon opens a new window only if there's none open already, which means I press the hotkey for opening a new window after clicking the icon, only to often end up with two new windows. (With a screen full of windows, you can't see if there happens to be a window already open.) I hate how Safari won't let me hide referrer headers. I hate how Firefox under this platform won't let me use tab to select hyperlinks and always opens tabs in the foreground. I hate how there is absolutely no telling how keys like home and end will behave in a text input box. I hate how by default radio buttons and checkboxes cannot be focussed with tab. I hate how the terminal can't send page up and down with just those key presses. I hate that iSync often crashes. I hate that the Calculator has no window anymore, and even after a force quit and re-start still doesn't display any calculator. I want my calculator, damnit. I hate that I can't use focus follows mouse because I can't configure the menu bar to be attached to windows instead of the desktop. I hate that there seems to be no good way to navigate the Finder with the keyboard (two enter keys and neither executes the selected program...). I hate that you can't just drag an image to the desktop from a browser to save the image there or use it as wallpaper. I hate that there's no easy way to find out where diskspace is going (like KDE's blocked view in Konqueror). I hate that I can't find where the hell I can set program bindings, so movies start with VLC instead of Quicktime. I hate how long shutting down takes. I hate having to reboot after installing non-kernel software updates. Feels awkwardly like Windows. Maybe I'm better off installing Linux. Juerd
From: Yoz Grahame Date: 11:41 on 22 Apr 2005 Subject: Re: MP3 players? Linux? I'm not sure, but I know there's hate On 4/22/05, Juerd <juerd@xxxxxxxxxxx.xx> wrote: >=20 > The thing that Windows provides over KDE is some weird kind of > consistency between Microsoft software, and bizarre integration between > anything. One man's "weird/bizarre" is another man's "utterly essential". You've really put me off KDE now. At least with Windows, when I start a new app I've never seen before, I can still be fairly certain that I'll know where to find basic things and how to interpret others. Oh, and that it'll pick up all my existing printer and UI settings, for example. And that, say, with a media player, I can skip back and forth between tracks using the special back/forward buttons on my keyboard. Yes, Windows still sucks in a load of areas, and I have been considering moving to either Ubuntu or OSX for a while now (it'll probably be Ubuntu to start with, given my current financial situation). And yes, I know that with freedesktop.org standardisation efforts, things are greatly improving. But I always reconsider when I see people moaning about the lack of things in their OS which Windows has had at least *partially* right for years. That said, ObHate: The way that Windows alerts you to the need for a restart after performing a security update - and after you've chosen "Restart Later", decides that "Later" means in 10 minutes' time, and then 10 minutes after that, and *will not fucking leave you alone whatever you are doing*. (No, there is no "don't bother me again" option. There's only "Later") Obviously, a smooth game of Counter-Strike becomes utterly impossible when it's suddenly switching you back to the desktop every few minutes. -- Yoz
From: Juerd Date: 12:31 on 22 Apr 2005 Subject: Re: MP3 players? Linux? I'm not sure, but I know there's hate Yoz Grahame skribis 2005-04-22 11:41 (+0100): > > The thing that Windows provides over KDE is some weird kind of > > consistency between Microsoft software, and bizarre integration between > > anything. > At least with Windows, when I start a new > app I've never seen before, I can still be fairly certain that I'll > know where to find basic things and how to interpret others. Same with KDE and Gnome applications. But if you use things like Firefox or OpenOffice.org, the consistency is gone. In any of Windows, Linux, OS X. > Oh, and that it'll pick up all my existing printer and UI settings, > for example. Again, this is all working great in KDE and Gnome. > And that, say, with a media player, I can skip back and forth > between tracks using the special back/forward buttons on my keyboard. That's because there's some driver for your keyboard. Probably because your keyboard was made by Microsoft, or by Logitech, who pay Microsoft. I was surprised a while ago to see keyboard hotkeys work in KDE on someone's box. He said it worked without configuration. > Yes, Windows still sucks in a load of areas, and I have been > considering moving to either Ubuntu or OSX for a while now (it'll > probably be Ubuntu to start with, given my current financial > situation). Currently, Kubuntu works better than Ubuntu, IMO. But that's because I find Gnome too restrictive and depressing in its lack of eye candy. Juerd
From: peter (Peter da Silva) Date: 14:36 on 22 Apr 2005 Subject: Re: MP3 players? Linux? I'm not sure, but I know there's hate > Same with KDE and Gnome applications. In Windows, the default is for apps to be WIn32 based, so by default stuff uses the same user interface... and it's actually a pretty good one. There's about forty dozen different sorta compatible development environments, so it's not 100%, but even for really wacked apps it's mostly right. Even Firefox knows about Win32 printers, for example. In Mac OS X, the default is for apps to be Aqua based, so by default stuff uses the same user interface, and it's an OK one... even if the keyboard navigation is kind of wonky it's consistently so. And there's only two main toolkits and they tarck each other, so it's a lot closer to 100% than Windows. In UNIX (Linux, BSD, commercial UNIX other than Mac OS X) the default is for apps to be X11 based, and the standard X11 user interface was a pretty awful one, and the winner of the commercial GUI wars is also pretty bad, AND it's forked at least once, plus there's half a dozen academic UI standards, and two major and at least a couple of minor contenders for the open source user interface standard, and a lot of developers who think they know better (no, they don't), so by default any arbitrary application has maybe a 25% chance of actually following the same user interface as your desktop. Printers? If an app lets me save as Postscript so I can feed it to my Ghostscript printer hack I feel like I'm ahead ofthe game. I suppose if I didn't hate Gnome and KDE both and was willing to spend the time to switch to Gnome or KDE (because that's what you have to do, pick one and stick with it) I could eventually resolve a lot of these problems... but that ain't going to happen. > > And that, say, with a media player, I can skip back and forth > > between tracks using the special back/forward buttons on my keyboard. > That's because there's some driver for your keyboard. Probably because > your keyboard was made by Microsoft, or by Logitech, who pay Microsoft. Um, no, there's actually a standard for this. USB system control. Keyboards that follow it even work on Mac OS X, at leats for media control... I'm using a DELL keyboard on my Mac and it just works.
From: Yoz Grahame Date: 14:44 on 22 Apr 2005 Subject: Re: MP3 players? Linux? I'm not sure, but I know there's hate On 4/22/05, Juerd <juerd@xxxxxxxxxxx.xx> wrote: > Yoz Grahame skribis 2005-04-22 11:41 (+0100): > > At least with Windows, when I start a new > > app I've never seen before, I can still be fairly certain that I'll > > know where to find basic things and how to interpret others. >=20 > Same with KDE and Gnome applications.=20 How good are Gnome apps at picking up KDE settings? > But if you use things like Firefox > or OpenOffice.org, the consistency is gone. In any of Windows, Linux, OS > X. Not on Windows, at least, not from what I've seen - Firefox is pretty consistent with the rest of Windows, OO.o slightly less so but still fine. But that's mainly due to those projects putting more work into Windows integration than on other OSes. > > And that, say, with a media player, I can skip back and forth > > between tracks using the special back/forward buttons on my keyboard. >=20 > That's because there's some driver for your keyboard. Probably because > your keyboard was made by Microsoft, or by Logitech, who pay Microsoft. >=20 > I was surprised a while ago to see keyboard hotkeys work in KDE on > someone's box. He said it worked without configuration. That's because, AFAIK, all those special keys are doing is sending a predefined key combo. No whizzy driverness needed. (But hateful when you innocently apply the same key-combo elsewhere) -- Yoz
From: peter (Peter da Silva) Date: 16:30 on 22 Apr 2005 Subject: Re: MP3 players? Linux? I'm not sure, but I know there's hate > That's because, AFAIK, all those special keys are doing is sending a > predefined key combo. That's exactly what they're NOT doing, not if they're using the usual interfaces and protocols. Plug a USB keyboard in and run a USB endpoint or HID explorer and look at all the funky stuff they do. I'm not sure how PS/2 keyboards do it, but it does seem to be out of band data and not keycodes... even when I look at the keycode stream at a fairly low level it never shows up.
From: Earle Martin Date: 00:22 on 03 May 2005 Subject: Windows Automatic Updates (was: Re: MP3 players? Linux? ...) On Fri, Apr 22, 2005 at 11:41:05AM +0100, Yoz Grahame wrote: > That said, ObHate: The way that Windows alerts you to the need for a > restart after performing a security update - and after you've chosen > "Restart Later", decides that "Later" means in 10 minutes' time, and > then 10 minutes after that, and *will not fucking leave you alone > whatever you are doing*. (No, there is no "don't bother me again" > option. There's only "Later") I think I can top that. I was staying with some relatives the other week; it's a Windows household. (I am one of the mythical happy Linux-on-the-desktop users referred to earlier on this list, but using Windows doesn't bug me too much when I have to.) The other day I got this message: "Updating your computer is almost complete. Your computer needs to be restarted for the updates to take effect. Windows will restart your computer automatically in 5:00 minutes." The time figure was counting down, and a progress bar was creeping up to complete. Underneath it asked, "Do you want to restart your computer now?" And offered two buttons, "Restart Now" and "Restart Later". So far so much the situation you describe. Only in my case, the "Restart Later" button was grayed out! So I had no choice but to drag the damn thing to the edge of the screen - because it insisted on staying in front - and hurriedly closing down all the stuff I was using. Thank fuck I do just about everything in a remote screen session. So let's count the hateworthy misfeatures: 1) Not giving you the "don't restart" option (Yoz's hate). 2) Picking an arbitrarily short time to allow the user to save their data before forcibly restarting the machine. 3) Assuming that only the administrator user should be allowed to decide that the machine should not be restarted [yet, see (1)]. 3) Subsequently displaying a /completely wrong message/. It should have been something like "Due to your administrator scheduling a software update, this machine will automatically restart in five minutes.", wrong though the idea of such a message may be. 4) Providing an option that is not actually an option - a disabled button. And not giving /any/ explanation to the user at /all/ why it is like that, probably leaving the average user in complete confusion. I am at a loss to describe how annoyed this made me. HATE.
From: Yoz Grahame Date: 00:58 on 03 May 2005 Subject: Re: Windows Automatic Updates (was: Re: MP3 players? Linux? ...) On 5/3/05, Earle Martin <hates-software@xxxxxxxx.xxx> wrote: >=20 > "Updating your computer is almost complete. Your computer needs to be > restarted for the updates to take effect. Windows will restart your compu= ter > automatically in 5:00 minutes." >=20 > The time figure was counting down, and a progress bar was creeping up to > complete. Underneath it asked, "Do you want to restart your computer now?= " > And offered two buttons, "Restart Now" and "Restart Later". So far so muc= h > the situation you describe. Only in my case, the "Restart Later" button w= as > grayed out! So I had no choice but to drag the damn thing to the edge of = the > screen - because it insisted on staying in front - and hurriedly closing > down all the stuff I was using. Thank fuck I do just about everything in = a > remote screen session. Wow. That's just astonishingly evil. I should count myself lucky that I my user account has Administrator rights so I never get trapped in *quite* such hell. There's a favourite bit in "About Face - Essentials of User Interface Design" by Alan Cooper (UI god, ex-Microsoft) where he describes how most novice users see dailog boxes: ---------------------- | | | Format hard drive? | | | | [ Now ] [ Later ] | | | ---------------------- ... and those bastards in Redmond ACTUALLY WENT AND IMPLEMENTED IT! -- Yoz
From: Chris Devers Date: 14:03 on 22 Apr 2005 Subject: Re: MP3 players? Linux? I'm not sure, but I know there's hate On Fri, 22 Apr 2005, Juerd wrote: > Chris Devers skribis 2005-04-21 17:33 (-0400): > > If I want to install an MP3 player, I can just try a dozen And this seems sane to you? Who wants to spend their life evaluating a dozen mediocre variants of every kind of application they might want to run? If you're "not too picky", wouldn't it generally be best to just have one or two really good ones that you don't have to agonize over? An overabundance of choice isn't necessarily good; it's suffocation. > > Sure, it's an educational experience to have to tweak every damned > > thing just to do *any* damned thing, but at what point does it cease > > to be educational and start to be self-punishment? > > That is exactly what I mean with how a geek uses Linux. This way of > working with an OS is a choice made by the user, as it's by no means > necessary. In my experience, it's a "choice" if I "choose" to do things like, say, use an mp3 player. Or print something. Or get KDE to quit using cursive fonts everywhere that I asked it to use monospace. Or get KDE to decide if it's going to attach menus to windows, Windows-style, or the top of the screen, Mac-style; I can deal with either, but please just pick one. Or... well really the last time I used KDE (about a year ago) it was such an endless source of unnecessary UI fiddliness that there isn't much point in making a big deal about any particular atrocity. The point being that *everything* is configurable, and the defaults on all of these is, in some minor-but-maddening way, insane, so you end up having to spelunk through endless configuration screens trying to get it to all just work in a way that doesn't give you nightmares, and you keep coming across distracting other options that don't actually get you closer to the change you needed to make in the first place, but they sound interesting and possibly useful, so you start making more adjustments, but then you realize that they're only making things worse, so you have to retrace your steps to get back to how things were before, but there's just so many damned options and so many of them seem to be redundant -- but aren't -- so it takes 45 minutes to figure out where you found that setting for FocusFollowsWhim or whatever, and six hours later and you realize that it's 2am and you never got around to doing what you were supposed to be working on at the outset because you've been trying in vain to just get the UI to get out of your way, but it has foiled your efforts at every damned turn. On the bright side, all the text in these configuration screens is now anti-aliased, so obviously, progress is happening at great speed! > > I think it stopped being fun for me about five years ago. > > Five years. Have you really no idea of how much has improved in that > time? I don't know, have I? At work, everyone with Linux runs Debian stable, which just seems like a supreme exercise in masochism to me. But then again, Debian stable is about 40 years old at this point, so maybe it isn't a fair comparison. In the past year or two, I've spent time with recent (as of that point) editions of RedHat and SuSE, and they both seemed "better" in that the fonts were all anti-aliased now, and the installation took a bit less time and was a bit better at figuring out all the irrelevant-to-humans hardware details that you still have to know on Debian, but that was about it. Once you have a running system (which is, I hasten to add, the whole damned point of installing it), the UI didn't seem fundamentally better now than it was a few years ago when I got sick of Linux, or a few years earlier when I first learned *nix on Solaris machines with TWM. My impression of the average "drank the Kool-aid" Linux user's view of system usability today is something similar to, say, how impressed Soviet citizens must have been with their national airline when Aeroflot got their aerial disaster rate down to under once or twice a week. Yes, progress may have happened, but it's still a dangerous jalopy. > > As Peter said, you are *so* ready for a Mac... > > So was I. And then I bought a Mac Mini, only to after a month realize > that Mac OS X is software like all other, and deserves a good piece of > hate. Ah, sorry, I didn't mean to lead you astray there. OSX is, of course, also a hateful, hateful thing. It's just that, for the most part, much (but not all) of the hate is now in individual applications rather than the system itself, so you're a step up from the Linux hatefulness. > I hate how my terminals sometimes lose their access hotkeys. Oh you can do better than that. Tried to use `screen` with Terminal yet? You'll be wallowing in the hate for hours once you give that a go... > I hate how Safari won't let me hide referrer headers. Tried setting up the local Apache instance as a cleansing proxy? > I hate how there is absolutely no telling how keys like home and end > will behave in a text input box. So don't use them. In most cases, Emacs keybindings will work just fine. > I hate that there seems to be no good way to navigate the Finder with > the keyboard (two enter keys and neither executes the selected > program...). Hint: [cmd]+[o]. It could be better, but I find column view to be fairly friendly to all keyboard usage of the Finder. > I hate that you can't just drag an image to the desktop from a browser > to save the image there or use it as wallpaper. Sure you can! Well, not to make it the wallpaper, but dragging images from the browser to the desktop (or a Finder window, or another app) should work just fine. Something broken on your setup maybe? What browser are you seeing this behaviour with? > I hate that there's no easy way to find out where diskspace is going > (like KDE's blocked view in Konqueror). MenuMeters can help with this, I think... <http://www.ragingmenace.com/software/menumeters/>; > I hate that I can't find where the hell I can set program bindings, so > movies start with VLC instead of Quicktime. Yes, this is annoying. RCDefaultApp helps here: <http://www.rubicode.com/Software/RCDefaultApp/>; > I hate how long shutting down takes. So don't shut down! Just put the thing to sleep when you're done. > I hate having to reboot after installing non-kernel software updates. > Feels awkwardly like Windows. Yes, this one is annoying. Thankfully, it doesn't happen nearly as often now as it did when OSX first came out. > Maybe I'm better off installing Linux. Maybe. After all... "Linux is free if your time is worthless." :-)
From: Juerd Date: 14:23 on 22 Apr 2005 Subject: Re: MP3 players? Linux? I'm not sure, but I know there's hate Chris Devers skribis 2005-04-22 9:03 (-0400): > > I hate how my terminals sometimes lose their access hotkeys. > Oh you can do better than that. Tried to use `screen` with Terminal yet? > You'll be wallowing in the hate for hours once you give that a go... Yes, I use screen all the time. Haven't yet found how that's a problem. Well, in the beginning things would wrap unnecessarily, but I think I accedentally hit some setting somewhere (no undo, no apply - every misclick is definitive instantly - so hateful) that may have made this better than it was. > > I hate how Safari won't let me hide referrer headers. I meant referer, by the way. Another huge hate. > Tried setting up the local Apache instance as a cleansing proxy? That sounds like even more work than configuration, which as you just explained can take a lot of your time. Besides that, I sometimes do want the referer header. I'd like a setting that lets me use them like cookies are accepted: only from/to the same domain. > > I hate how there is absolutely no telling how keys like home and end > > will behave in a text input box. > So don't use them. In most cases, Emacs keybindings will work just fine. Except when they don't, and that inconsistency is what I hate. > > I hate that you can't just drag an image to the desktop from a browser > > to save the image there or use it as wallpaper. > Sure you can! Well, not to make it the wallpaper, but dragging images > from the browser to the desktop (or a Finder window, or another app) > should work just fine. Something broken on your setup maybe? What > browser are you seeing this behaviour with? When I drag an image from browser to desktop, it puts a link to the image there. Which works just as well, except it always uses a browser and stops working when the image is no longer online at that address. I recall it was with both Firefox and Safari, but I'm not sure. Currently, I'm at the office, where I thankfully use a KDE desktop. > > I hate that there's no easy way to find out where diskspace is going > > (like KDE's blocked view in Konqueror). > MenuMeters can help with this, I think... Not really - I want to know that my Movies folder is taking up all the space, so I know where to start cleaning up, not just that it's time to clean up. What I want is like <http://juerd.nl/filesize.png>;. (Hmm, hateful - ksnapshot can't include the cursor.) If MM does this, I'm interpreting the screenshots wrong. > Yes, this is annoying. RCDefaultApp helps here: > <http://www.rubicode.com/Software/RCDefaultApp/>; Thank you. > > I hate how long shutting down takes. > So don't shut down! Just put the thing to sleep when you're done. See next item... > > I hate having to reboot after installing non-kernel software updates. > > Feels awkwardly like Windows. Juerd
From: peter (Peter da Silva) Date: 14:42 on 22 Apr 2005 Subject: Re: MP3 players? Linux? I'm not sure, but I know there's hate > Oh you can do better than that. Tried to use `screen` with Terminal yet? Yeh. What's the problem? Couldn't get the terminfo settings right so it doesn't play silly-bugger games with buffers? That's an old, comfortable hate by now, goes back to the original release of "we like termcap but we're going to do it incompatible for no good reason" Terminfo on System V in the mid-80s. I think I was already hating Terminfo before the original Mac was more than a twinkle in Raskin's eye.
From: Chris Devers Date: 15:06 on 22 Apr 2005 Subject: Re: MP3 players? Linux? I'm not sure, but I know there's hate On Fri, 22 Apr 2005, Peter da Silva wrote: > > Oh you can do better than that. Tried to use `screen` with Terminal > > yet? > > Yeh. What's the problem? The problem, in my case, is that as the only Mac admin among a clutch of Linux admins that are all using the same shared screen session for managing servers, I'm constantly bitten by the way that most of the control keys don't Just Work, so you can't amend typos with backspace, and you can't redraw the view with ^L, and you can't, and you can't, and you can't... ad nauseam. Yes, this is an old Terminfo hate with a long, proud tradition behind it. I don't care. I got into Macs in the first place because I don't *want* to care. I just want the hateful steaming turd of a machine to work, dammit. To mutilate a Douglas Adams quote... I don't want to know about terminfo. I don't want to know about VT100 parameters (I don't. They give me the willies). I don't want to have to worry about what terminfo configuration to use for every system I might want to connect to so that I can get a proper shell to work in a consistent and predictable way. I'm a Mac user, for heaven's sake. This is meant to be easy. (Cf <http://www.douglasadams.com/dna/980707-00-a.html>;, with apologies.) (He'd have been a great source of hate-rants, come to think of it...)
From: Juerd Date: 15:14 on 22 Apr 2005 Subject: Re: MP3 players? Linux? I'm not sure, but I know there's hate Chris Devers skribis 2005-04-22 10:06 (-0400): > you can't amend typos with backspace, I can. > you can't redraw the view with ^L I can. Don't you mean "I can't" where you said "You can't"? :) I think this is a settings issue. Juerd
From: Chris Devers Date: 15:21 on 22 Apr 2005 Subject: Re: MP3 players? Linux? I'm not sure, but I know there's hate On Fri, 22 Apr 2005, Juerd wrote: > Don't you mean "I can't" where you said "You can't"? :) > > I think this is a settings issue. I'm positive that it's a settings issue, but that's the whole point. I DON'T WANT TO CARE ABOUT THIS. I JUST WANT IT TO WORK. The workaround I've settled on is just using X11. It's ugly and it's hobbled, but running xterms is the one thing it's good at, and it's easy enough to make it go away when I'm finished using it. If there's justice in the world -- which there isn't, but oh well -- then I'll install 10.4 in a week and discover that all of these problems have magically gone away. Maybe it'll come with a pony, too!
From: xtina Date: 15:16 on 22 Apr 2005 Subject: Re: MP3 players? Linux? I'm not sure, but I know there's hate And with strange aeons, even Chris Devers replies (Fri, 22 Apr 2005): > Maybe it'll come with a pony, too! Punchline: "With all this shit, there's GOTTA be a pony!" -x -- I've just decided to switch our Friday schedule to Monday, which means that the test we take each Friday on what we learned during the week will now take place on Monday before we've learned it. But since today is Tuesday, it doesn't matter in the slightest. - Mr. Turkentine, "Willy Wonka & the Chocolate Factory"
From: Matt McLeod Date: 15:21 on 22 Apr 2005 Subject: Re: MP3 players? Linux? I'm not sure, but I know there's hate Chris Devers wrote: > On Fri, 22 Apr 2005, Juerd wrote: > > > Don't you mean "I can't" where you said "You can't"? :) > > > > I think this is a settings issue. > > I'm positive that it's a settings issue, but that's the whole point. Thing is, I've seen this problem when the machine on the other end is running Debian, but not with some other Linux distros. I'm not entirely sure that it's Apple's fault that the Debian people have chosen to be jerks in whatever particular way it is they've chosen. (I haven't cared enough to dig around and figure out exactly what it is about Debian that causes this as I have only one Debian machine and it runs more-or-less untouched.) Just like I don't blame Apple because fucking HP use BIOS-alike thingos for "SmartArray" controllers that will work with only a very limited subset of terminal emulators, Terminal.app not being one of them. And, for that matter, I don't blame Apple because our internally-developed account management system assumes you've got a damned VT-220 on your desk and thus you have to enable the "strict keybindings" mode which is otherwise undesirable. Matt
From: peter (Peter da Silva) Date: 19:52 on 22 Apr 2005 Subject: Re: MP3 players? Linux? I'm not sure, but I know there's hate > The problem, in my case, is that as the only Mac admin among a clutch > of Linux admins that are all using the same shared screen session for > managing servers, I'm constantly bitten by the way that most of the > control keys don't Just Work, so you can't amend typos with backspace, > and you can't redraw the view with ^L, and you can't, and you can't, > and you can't... ad nauseam. Sounds like you need to use the same application they're using to access the server. Luckily, you can do that. I believe it even ships with Mac OS X.
From: peter (Peter da Silva) Date: 14:22 on 22 Apr 2005 Subject: Re: MP3 players? Linux? I'm not sure, but I know there's hate > My distribution of choice is Debian. I like that with a simple command, > or a simple instruction in one of the GUI frontends, I can install > almost any kind of software. That was a great idea FreeBSD came up with, wasn't it? I can't tell what's worse. People who think some good idea is great now that Microsoft's finally picked it up, or thinking that some good idea is great just because Linux has finally picked it up. Personally, I prefer not having to run installers at all because apps don't have to get installed in 10 separate directories at once. > The thing that Windows provides over KDE is some weird kind of > consistency between Microsoft software, and bizarre integration between > anything. Mac OS X just provides Expose and eyecandy and really not much > more than that in terms of usability. And even more consistency than Windows, and scripted integration between everything, and drag-and-drop works for everything, and fonts just work, and there's actually commercial software available for it, and... > You have to install third party > utilities for things like virtual desktops and a run program dialog. OK, I don't get this one. Linux is nothing but a bunch of third party utilities flying in cliose formation. That's one of its strengths, even. The idea that "third party utilities" is somehow a bad thing, especially when (in this case) said utilities are free and open source (just like the ones that go into Linux) just boggles my mind. > I think that in desktop experience, a well organized (non-bloated) Linux > distribution and Mac OS X are on the same level, somewhere high above > Windows. I've used Linux, and FreeBSD (which is generally better integrated and less bloated than Linux). I've used KDE and Gnome, and gone back to Windowmaker. I've tried all the file managers that I could find, and ROX Filer annoys me the least and it still sucks. Annoying as Finder is, I haven't found a UNIX file manager that can lay a finger on it. > So was I. And then I bought a Mac Mini, only to after a month realize > that Mac OS X is software like all other, and deserves a good piece of > hate. Yes, but it's a *dry* hate. [Terminal.app and iCal hate] You know you can use the same software you use on Linux, if you want, and in most cases it's just a simple command for Fink or Darwinports. > I hate how clicking a dock icon opens a new window only if there's none > open already, If there is, it pops that window to the top and focuses on it. > I hate how Firefox under this platform won't let me use tab to select > hyperlinks and always opens tabs in the foreground. Have you checked your preferences? > I hate how there is absolutely no telling how keys like home and end > will behave in a text input box. As opposed to Linux, where there's no way to tell how ANY keys will behave in a text input box, and in some pretty important apps (like XV) the key bindings either don't exist or were devised by a crack-addled lemur? > I hate how by default radio buttons and checkboxes cannot be focussed > with tab. Preferences. > I hate how the terminal can't send page up and down with just those key > presses. I love the way Terminal.app doesn't pass keys like that through because 99.5% of the software (including curses software) running inside it doesn't understand it, so you hit "page up" and see a bunch of X3.64 line noise. > I hate that iSync often crashes. I hate iSync and iCal, I use Palm Desktop instead. And before you go on about third party software, remember what Linux *is*. > I hate that I can't use focus follows mouse because I can't configure > the menu bar to be attached to windows instead of the desktop. I used to hate that. I've gotten used to it. It's the price I pay for not having to fight my computer any more. > I hate that there seems to be no good way to navigate the Finder with > the keyboard (two enter keys and neither executes the selected > program...). CMD-O > I hate that you can't just drag an image to the desktop from a browser > to save the image there or use it as wallpaper. Um, I do that ALL THE TIME. > I hate that there's no easy way to find out where diskspace is going > (like KDE's blocked view in Konqueror). Put Finder in list mode. Finder->View->Show View Options. Select "Calculate all Sizes". Sort by size. > I hate that I can't find where the hell I can set program bindings, so > movies start with VLC instead of Quicktime. Click on a movie. Cmd-I or select "Show Info" from the menu. See where it says "Open With"? > I hate having to reboot after installing non-kernel software updates. You don't, most of the time. You will probably need to log out and in again because this usually means there's been a change to the cocoa frameworks somewhere, but if you feel like living dangerously you can just kill the installer and try it.
From: xtina Date: 14:26 on 22 Apr 2005 Subject: Re: MP3 players? Linux? I'm not sure, but I know there's hate And with strange aeons, even Peter da Silva replies (Fri, 22 Apr 2005): > Personally, I prefer not having to run installers at all because apps > don't have to get installed in 10 separate directories at once. Pardon my Windows-based ignorance, but if certain kinds of apps didn't install parts of themselves in certain other directories, how would they talk with other apps? I'm thinking of things that associate file types to them, or that talk to other apps, such as Firefox determining it's the default browser, or iTunes owning .mp3s, or such. >> So was I. And then I bought a Mac Mini, only to after a month realize >> that Mac OS X is software like all other, and deserves a good piece of >> hate. > > Yes, but it's a *dry* hate. *snort* > If there is, it pops that window to the top and focuses on it. *pats her TweakUI* -x -- Until you are willing to be confused about what you already know, what you know will never become wider, bigger or deeper. - Milton Erikson
From: peter (Peter da Silva) Date: 15:29 on 22 Apr 2005 Subject: Re: MP3 players? Linux? I'm not sure, but I know there's hate > Pardon my Windows-based ignorance, but if certain kinds of apps didn't > install parts of themselves in certain other directories, how would they > talk with other apps? Apart from applications that are basically plugins (and which you can in many cases install just by doubleclicking ... the plugin extension gets caught by Finder and it passes them on to the app that needs it), this gets done the first time you run it. A lot of Winodws apps do the same thing, you can install them anywhere and they just work. Some of them do stupid things like stealing associations, but so do a lot of apps that use installers... that's a problem with the specific application, not the general design. [insert great heaving gobs of corrosive hate about Adobe Acrobat here, thanks] > I'm thinking of things that associate file types to them, or that talk to > other apps, such as Firefox determining it's the default browser, or > iTunes owning .mp3s, or such. In Mac OS X this information is stored in a standard property list in the app, so when you open it Finder adds it to the LaunchServices database.
From: Juerd Date: 14:35 on 22 Apr 2005 Subject: Re: MP3 players? Linux? I'm not sure, but I know there's hate Peter da Silva skribis 2005-04-22 8:22 (-0500): > > My distribution of choice is Debian. I like that with a simple command, > > or a simple instruction in one of the GUI frontends, I can install > > almost any kind of software. > That was a great idea FreeBSD came up with, wasn't it? Yes, certainly. It's even better when done right :P > > You have to install third party > > utilities for things like virtual desktops and a run program dialog. > OK, I don't get this one. Linux is nothing but a bunch of third > party utilities flying in cliose formation. Yes, it is. Whenever I say Linux, most of the time I really mean "a good GNU/Linux desktop distribution". > The idea that "third party utilities" is somehow a bad thing, > especially when (in this case) said utilities are free and open source > (just like the ones that go into Linux) just boggles my mind. They are not a bad thing, but some features should be supported by the platform itself. This is exactly the same thinking as wanting sane defaults instead of having to configure everything to sanity yourself. For example, I use QuickSilver, which I like much. But it'd be good if OS X had something like it integrated so it's immediately useful after installing the OS. Of course, there'd still be room for improvement and thus third party utilities. > Annoying as Finder is, I haven't found a UNIX file manager that can > lay a finger on it. Konqueror is rapidly improving. (And going downhill in some areas.) > > I hate how clicking a dock icon opens a new window only if there's none > > open already, > If there is, it pops that window to the top and focuses on it. And because I already pressed the key for a new window, I end up with two new windows instead of just one. I pressed that key because I wanted a new window. If I don't press that key myself, I have to click, wait 5 seconds, and then if there is no new window, press the key anyway. It's too much work to hit F9 for expose and then scan the surface for similar windows before clicking a dock icon. > > I hate how Firefox under this platform won't let me use tab to select > > hyperlinks and always opens tabs in the foreground. > Have you checked your preferences? Yes, and I even have the extension loaded that lets you finetune tab settings. To no avail. > > I hate how there is absolutely no telling how keys like home and end > > will behave in a text input box. > As opposed to Linux, where there's no way to tell how ANY keys will > behave in a text input box, and in some pretty important apps (like > XV) the key bindings either don't exist or were devised by a > crack-addled lemur? Yes. > > I hate how by default radio buttons and checkboxes cannot be focussed > > with tab. > Preferences. "how by default". I think sane defaults are not too much to ask, and I find this default setting pretty insane. > > I hate how the terminal can't send page up and down with just those key > > presses. > I love the way Terminal.app doesn't pass keys like that through > because 99.5% of the software (including curses software) running > inside it doesn't understand it, so you hit "page up" and see a > bunch of X3.64 line noise. Really? The programs I use much (mutt, less, vim) all understand the keys very well. If that's on linux systems, of course. BSD hates me. > > I hate that there's no easy way to find out where diskspace is going > > (like KDE's blocked view in Konqueror). > Put Finder in list mode. > Finder->View->Show View Options. > Select "Calculate all Sizes". > Sort by size. Sounds good. Will try as soon as I get home. Thanks! > > I hate that I can't find where the hell I can set program bindings, so > > movies start with VLC instead of Quicktime. > Click on a movie. Movies I click are usually hyperlinked from web pages. > Cmd-I or select "Show Info" from the menu. > See where it says "Open With"? It's not the place where I expected that, as opening is not information. Juerd
From: peter (Peter da Silva) Date: 15:23 on 22 Apr 2005 Subject: Re: MP3 players? Linux? I'm not sure, but I know there's hate > > > My distribution of choice is Debian. I like that with a simple command, > > > or a simple instruction in one of the GUI frontends, I can install > > > almost any kind of software. > > That was a great idea FreeBSD came up with, wasn't it? > Yes, certainly. It's even better when done right :P I'd like to see that. My experience with Debian is not good, but I understand they've fixed a lot of the stuff I hate about it. Maybe I'll gve it another try some time. I've just been biten by Linux too many times to want to rush back in... > > > You have to install third party > > > utilities for things like virtual desktops and a run program dialog. > > OK, I don't get this one. Linux is nothing but a bunch of third > > party utilities flying in cliose formation. > Yes, it is. Whenever I say Linux, most of the time I really mean "a good > GNU/Linux desktop distribution". That's STILL nothing but a bunch of third party utilities flying in close formation. Someone went out and picked the particular set of utilities for you, but it's still just an exercise in bundling... and that is a good thing. Besides, you still want to add more components, so what's the big deal? > > The idea that "third party utilities" is somehow a bad thing, > > especially when (in this case) said utilities are free and open source > > (just like the ones that go into Linux) just boggles my mind. > They are not a bad thing, but some features should be supported by the > platform itself. Heh. EVERYONE has a different list of what those features are. There's stuff you consider core that I don't even want, and I'm sure the opposite is true. There's still UNIX window managers that dont do virtual screens, even. And people who swear by them. > For example, I use QuickSilver, which I like much. But it'd be good if > OS X had something like it integrated so it's immediately useful after > installing the OS. Of course, there'd still be room for improvement and > thus third party utilities. And I don't like Quicksilver at all, I've tried a dozen similar apps, and I keep ending up typing "open" in Terminal.app. Because, you see, the default command line launcher in Mac OS X is the shell... the default command line launcher in every other UNIX version. > > > I hate how clicking a dock icon opens a new window only if there's none > > > open already, > > If there is, it pops that window to the top and focuses on it. > And because I already pressed the key for a new window, Why did you do that? You click on the dock icon, a window pops up. Whether it's a new window or an old window, it's still a window. > I end up with > two new windows instead of just one. Um, no you don't, you end up with one new window and one old window that was already there. > If I don't press that key myself, I have to click, wait 5 seconds, and > then if there is no new window, press the key anyway. It's too much work > to hit F9 for expose and then scan the surface for similar windows > before clicking a dock icon. So don't hit f9 for expose and scan for similar windows. Ask the app for a window. You have to wait for the window anyway, whether it's new or not. This is a tiny little hate. > > > I hate how Firefox under this platform won't let me use tab to select > > > hyperlinks and always opens tabs in the foreground. > > Have you checked your preferences? > Yes, and I even have the extension loaded that lets you finetune tab > settings. To no avail. Weird. That and your "can't drag images to the desktop" hate makes me wonder if you've broken Firefox somehow. > > > I hate how there is absolutely no telling how keys like home and end > > > will behave in a text input box. > > As opposed to Linux, where there's no way to tell how ANY keys will > > behave in a text input box, and in some pretty important apps (like > > XV) the key bindings either don't exist or were devised by a > > crack-addled lemur? > Yes. Uh... O-kay. > > > I hate how by default radio buttons and checkboxes cannot be focussed > > > with tab. > > Preferences. > "how by default". I think sane defaults are not too much to ask, and I > find this default setting pretty insane. I'm sorry, I can't connect your desire for sane defaults and your preference for Linux in any way that makes sense. > > > I hate that I can't find where the hell I can set program bindings, so > > > movies start with VLC instead of Quicktime. > > Click on a movie. > Movies I click are usually hyperlinked from web pages. Click on a movie in Finder. Your browser and Finder unfortunately use the same Launchservices database, so when you change it in Finder the browser should pick it up. (why unfortunately? <url: http://www.scarydevil.com/~peter/io/apple.html >) > > Cmd-I or select "Show Info" from the menu. > > See where it says "Open With"? > It's not the place where I expected that, as opening is not information. Yeh, "Get Info" should really be called "Properties". This is part of the dry hate of the legacy Finder. I wish Apple had just carbonised Finder and Aquafied the NeXT file manager and let us use either or both as we preferred. Hateful as it is, though, it's better than most. I do kind of like like the classic Windows Explorer (before it got all ActiveDesktopped), and even the old File Manager. Microsoft did a lot of things right in the original Windows GUI. Too bad they couldn't leave well enough alone. PS: I hate whatever software people use that makes it inconvenient to just reply to the Hates Software list instead of CCing everyone so I get multiple copies...
From: Phil!Gregory Date: 16:30 on 23 Apr 2005 Subject: Re: MP3 players? Linux? I'm not sure, but I know there's hate * Peter da Silva <peter@xxxxxxx.xxx> [2005-04-22 08:22 -0500]: > > My distribution of choice is Debian. I like that with a simple command, > > or a simple instruction in one of the GUI frontends, I can install > > almost any kind of software. > > That was a great idea FreeBSD came up with, wasn't it? Is this the ports system, or something else? (The only *BSD I'm even moderately familiar with is OpenBSD.) If you're referring to ports, than I consider the ability to install precompiled binaries to be a significant improvement. If I wanted to recompile all of my programs every time I installed them (and still run Linux), I'd use Gentoo. > Personally, I prefer not having to run installers at all because apps > don't have to get installed in 10 separate directories at once. The trick is to have good *un*installers. I shouldn't have to worry about where programs put their files. This is a computer, and computers are good at keeping track of fiddly stuff like that. This is one thing I think Debian does very well, and much better than any system I've seen on Windows, at least.
From: peter (Peter da Silva) Date: 22:14 on 23 Apr 2005 Subject: Re: MP3 players? Linux? I'm not sure, but I know there's hate > Is this the ports system, or something else? (The only *BSD I'm even > moderately familiar with is OpenBSD.) If you're referring to ports, than > I consider the ability to install precompiled binaries to be a significant > improvement. That's the other half of the Ports system, it's called Packages. You can build a port to install it or produce a package. You can install the package right away or later. > > Personally, I prefer not having to run installers at all because apps > > don't have to get installed in 10 separate directories at once. > The trick is to have good *un*installers. Personally, I prefer not having to run [un]installeres at all because apps don't have to get installed into 10 different directories at once. > I shouldn't have to worry about where programs put their files. There's two ways of avoiding that. First, you can take over the whole installation process with a single central tool that everyone (and I mean everyone) uses, and then make damn sure that there's people willing to take on the task of maintaining this database. If you install a different program, one that isn't supported, you're back in "configure; make; make install" if you're lucky. If you don't want to track the latest version of some file, same thing. But if you're happy tracking the specific versions and options and plugins that the central command likes, it's great. Second, you create an easy framework that lets developers put all their files in one place for each app, and a user preferences structure that makes collissions impossible, and bob's your uncle. > This is a computer, and computers are > good at keeping track of fiddly stuff like that. That applies to both philosophies. > This is one thing I > think Debian does very well, and much better than any system I've seen on > Windows, at least. Windows applies part of both solutions at the same time, badly.
From: Patrick Carr Date: 20:12 on 23 Apr 2005 Subject: Re: MP3 players? Linux? I'm not sure, but I know there's hate On Apr 22, 2005, at 9:22 AM, Peter da Silva wrote: >> I hate how by default radio buttons and checkboxes cannot be focussed >> with tab. > > Preferences. In Safari? Or were you still talking about Firefox? I submitted this bug umpteen years ago for Safari; it was closed with a "we know about this" code. Hello? Not exactly the most intricate standard to comply with. If it is a preference in Safari, where is it? On an unrelated note, if Microsoft applications on Windows are so goddamn consistent, why does Word open multiple windows, and Excel put all open documents in one window, thus preventing you from comparing two spreadsheets? Pat Carr
From: peter (Peter da Silva) Date: 23:05 on 23 Apr 2005 Subject: Re: MP3 players? Linux? I'm not sure, but I know there's hate > In Safari? Or were you still talking about Firefox? Oh, sorry, go ahead. I have no intention of standing in the way of your righteous hate for Safari. > On an unrelated note, if Microsoft applications on Windows are so > goddamn consistent, why does Word open multiple windows, and Excel put > all open documents in one window, thus preventing you from comparing > two spreadsheets? Oh, you can force them BOTH to use MDI if you like. GD&R
From: hv Date: 11:52 on 22 Apr 2005 Subject: Re: MP3 players? Linux? I'm not sure, but I know there's hate Chris Devers <cdevers@xxxxx.xxx> wrote: :Really, does anyone use Linux as a desktop computer and *enjoy* the :experience? Yes. As far as I am concerned, a window manager's job is to let me open enough xterms with vi sessions - I use fvwm, with a 4x4 virtual window, and typically have between 50 and 200 separate vi sessions open, and they're organised so I know where each one is. I use very few graphical programs: a browser, a mail client, a couple of games, and occasionally something to view jpegs or pdfs. I don't use audio. I set up X when the computer was new, then didn't need to do it again. The system hasn't been rebooted except for two power glitches in the 18 months I've lived here, and now it is UPS protected. I also have a G4 powerbook, which I've only ever used when going to overseas conferences - I need a proper keyboard, damnit, and a decent number of mouse buttons, and a decent sized screen, and a system that I can feel properly in control of. Hugo
From: Abigail
Date: 23:27 on 22 Apr 2005
Subject: Re: MP3 players? Linux? I'm not sure, but I know there's hate
--FkmkrVfFsRoUs1wW
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Fri, Apr 22, 2005 at 11:52:32AM +0100, hv@xxxxx.xxx wrote:
> Chris Devers <cdevers@xxxxx.xxx> wrote:
> :Really, does anyone use Linux as a desktop computer and *enjoy* the=20
> :experience?
>=20
> Yes. As far as I am concerned, a window manager's job is to let me open
> enough xterms with vi sessions - I use fvwm, with a 4x4 virtual window,
> and typically have between 50 and 200 separate vi sessions open, and
> they're organised so I know where each one is.
>=20
> I use very few graphical programs: a browser, a mail client, a couple
> of games, and occasionally something to view jpegs or pdfs. I don't
> use audio. I set up X when the computer was new, then didn't need to
> do it again.
Hear, hear.
Same here. I use fvwm2, and I use a configuration file that hasn't
have any significant changes since 1993. I copy the config file from
system to system, and from OS to OS. I've used Linux (Debian, Redhat,
Slackware, SuSe), Solaris, HP-UX and Cygwin in the past dozen years,
and my screen has looked the same on all of them [*]. Same hotkeys as well.
3x3 virtual windows, mostly filled with rxvts. Most of the rxvts run vile
(a vi clone). Mail, news, mud, and IRC are all run from my rxvts. Only a
view programs are 'graphical': web wowser (netscape or mozilla), image
displayer (display), document viewers (xdvi, ghostview, acrobat reader).
The few games I play, I either play on the web (turn-based), or in an
rxvt: angband. And I use 3x3 virtual windows is because that maps nicely
to the positive numbers on the keypad: hitting them switches between the
virtual windows. F5 brings up a new rxvt, F6 kills the current window.
F1 cycles the window (brings it up or down). F12 locks the screen.
Music comes from the radio. In fact, most boxes I use I never can be
bothered to configure sound.
[*] Black background. Non-active windows have a black border, active
windows dark blue. Rxvt uses black letters on a grayish background.
6x13 font. Scrollbar on the right. In the upper left corner of the
screen, from left to right, each 64x64 pixels: xclock, xload and
Fvwm's pager. Spartan for the modern Gnome/KDE, but ideal for me.
But this list is about hate, so I'll just shut up now.
Abigail
--FkmkrVfFsRoUs1wW
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
iD8DBQFCaXpgBOh7Ggo6rasRAqRuAJ9yzTnS78Es55eo9oLPHlITQvhvZwCffykR
c1uSlw4Kw5jveSIgbKy9mwU=
=fFQQ
-----END PGP SIGNATURE-----
--FkmkrVfFsRoUs1wW--
From: Luke Kanies Date: 16:10 on 22 Apr 2005 Subject: Re: MP3 players? Linux? I'm not sure, but I know there's hate On Thu, 2005-04-21 at 17:33 -0400, Chris Devers wrote: > On Thu, 21 Apr 2005, Luke Kanies wrote: > > > Getting MP3s to work on Gentoo was hours and hours of work > > Stop right there, doctor, I think we've diagnosed the problem. > > "Doctor doctor, it hurts when I do this." > "Then don't do that." > > > As Peter said, you are *so* ready for a Mac... I think it's so cute when people 1) don't think I already have a mac (much less a few), and 2) think I don't hate OS X about as much as I hate Linux. I can certainly appreciate that OS X is stable, and I love the fact that my laptop wakes up from sleep very quickly (even if networking still takes 90 seconds to come back up), but there's still plenty to hate about OS X, and that hate is all the more pertinent for me since it could have been based on the most modern OS out there (BeOS) instead of another crappy, outdated, retarded, crappy (did I say that already?) Unix OS. Yes, I know, NextStep was a very good Unix, but that's not saying very damn much -- it's 30 year old tech, and it never was and never will be a good desktop. It's no coincidence that everything that makes OS X good is entirely unrelated to it sitting on top of Unix, so why even bother have it do so? Frankly, in a lot of ways OS X makes me madder than Linux, because I understand that the Linux guys are all just wankers looking for a good time, but the OS X guys are supposed to be making a living building the best OS out there, and instead they wasted 2 full release cycles on toning down their lickability, and they still haven't fucking figured out filetyping. Filename extensions? Seriously? No, seriously? Really? *faints* > Really, does anyone use Linux as a desktop computer and *enjoy* the > experience? Sure, it's an educational experience to have to tweak every > damned thing just to do *any* tamned thing, but at what point does it > cease to be educational and start to be self-punishment? > > I think it stopped being fun for me about five years ago. I don't know that I've had "fun" maintaining any desktop ever. I used to have a lot of fun _using_ BeOS, and there are sometimes apps I have fun using, but in general, I'm a 'wareHater, so it's all misery to me. At least Linux is so far from the mark that it doesn't offend me; OS X could have been a contender (and who knows, maybe they'll go back and reassess some of the other great features in BeOS, now that Spotlight is copying BFS), and instead it's, um, lickable. Because that's sure what I was begging for. > Why anyone would willfully decide to fight against Linux audio, or > setting up X-Windows (really, who gives a damn about all the parameters > in XF86Config-4? What human should ever have to care about the monitor's > HorizSync and VertRefresh rates?) is a complete mystery to me. Totally agree there. > Sure, it's nice for a server, but the best way to deal with Linux is by > keeping it at the far end of a remote ssh session, not sitting on your > desk where the ferocious little monster can rip your face off. > > As Peter said, you are *so* ready for a Mac... I'd be glad to give you my shipping address if you think you can resolve that problem for me.
From: peter (Peter da Silva) Date: 16:40 on 22 Apr 2005 Subject: Re: MP3 players? Linux? I'm not sure, but I know there's hate > about OS X, and that hate is all the more pertinent for me since it > could have been based on the most modern OS out there (BeOS) *choke* I've used BeOS. I've even been excited about BeOS. I used to be pissed off about Apple giving BeOS the cold shoulder. But as I got more familiar with it, and watched Palm floundering around not releasing the BeOS-based Palm OS 6 long after they should have... I've been more and more glad Apple stayed the hell away from it. I don't have time to begin to address my BeOS hate, I'm not sure that much time exists. I'll just say that I can understand them reinventing the wheel, but they should have actually looked at some of the *round* ones available before deciding that a triangle made a better wheel than a pentagon. Oh, and putting necessary metadata in the file system, outside the file, where it is GUARANTEED to get lost as son as you have to deal with the fact that nobody else in the whole world does it the same way as you even if they're daft enough to think it's a good idea, is hateful in so many ways... > toning down their lickability, and they still haven't fucking figured > out filetyping. Filename extensions? Seriously? No, seriously? > Really? *faints* Directories, dude. All the advantages of file types and resource forks, and they don't go BOOM when you back them up. > At least Linux is so far from the mark that it doesn't offend me; OS X > could have been a contender (and who knows, maybe they'll go back and > reassess some of the other great features in BeOS, now that Spotlight is > copying BFS), Um, no, it's not, and that's a GOOD thing.
From: Luke Kanies Date: 16:55 on 22 Apr 2005 Subject: Re: MP3 players? Linux? I'm not sure, but I know there's hate On Fri, 2005-04-22 at 10:40 -0500, Peter da Silva wrote: > > about OS X, and that hate is all the more pertinent for me since it > > could have been based on the most modern OS out there (BeOS) > > *choke* Glad I could help. :) > I've used BeOS. I've even been excited about BeOS. I used to be pissed > off about Apple giving BeOS the cold shoulder. But as I got more familiar > with it, and watched Palm floundering around not releasing the BeOS-based > Palm OS 6 long after they should have... I've been more and more glad > Apple stayed the hell away from it. Well, Palm's inability to release an OS is not really indicative of the worth of BeOS, I would think. BeOS still had some significant work to do (especially in terms of manageability and built-in networking support for things like remote filesystems), but at least it's not Unix. > I don't have time to begin to address my BeOS hate, I'm not sure that > much time exists. Interesting; you would be the first person I've communicated with who actually expresses specific hate about BeOS (I'm obviously ignoring all of the "but it's not free" trolls out there). > I'll just say that I can understand them reinventing the wheel, but they > should have actually looked at some of the *round* ones available before > deciding that a triangle made a better wheel than a pentagon. Examples? > Oh, and putting necessary metadata in the file system, outside the file, > where it is GUARANTEED to get lost as son as you have to deal with the > fact that nobody else in the whole world does it the same way as you even > if they're daft enough to think it's a good idea, is hateful in so many > ways... So I assume that you hate that Unix metadata is in the inode, too? Should vi be managing the contents of text files to include owner and permissions? That seems just daft. Metadata is exactly that: data about the data. It's a meeting point between the OS, the app, and the data, and it doesn't make sense to make the exclusive domain of any of them. Sticking it in the filesystem works just dandily, as long as you provide good, simple tools for converting. And the old "but it's not compatible" excuse is just bull -- if we used that for everything, we'd never get anything done. I love incompatible shit, especially when it's both incompatible and better. > > toning down their lickability, and they still haven't fucking figured > > out filetyping. Filename extensions? Seriously? No, seriously? > > Really? *faints* > > Directories, dude. All the advantages of file types and resource > forks, and they don't go BOOM when you back them up. So now all of my files are directories? I mean, I understand the value of an abstraction, but I just don't think this whole "files are actually just abstractions and don't really exist" thing is a good idea. "No, that's not an app, it's a directory that functions as an abstraction for an app." I think abstractions are powerful tools for encapsulating concepts, but it just doesn't seem right to make core ideas into abstractions, especially when the abstraction isn't normally an abstraction -- a file is normally a file, but on OS X a file is going to become a directory of files? Are those files inside the directory also a directory of files? It's just silly. Metadata in the inode is simple to understand, simple to maintain, incredibly powerful, really fast (because it's in the inode), and pays a legacy compatibility cost. So be it. > > At least Linux is so far from the mark that it doesn't offend me; OS X > > could have been a contender (and who knows, maybe they'll go back and > > reassess some of the other great features in BeOS, now that Spotlight is > > copying BFS), > > Um, no, it's not, and that's a GOOD thing. So Spotlight is not copying BFS to some extent? Curious; it sure seems like they are, with the saved live queries, the live-indexed metadata-based querying system, and the fact that the guy who wrote BFS is working for Apple on that project. What's better about Spotlight, other than the fact that they obviously took the next step and started indexing the internals of the apps (although it's only kind of the next step -- if they were really thinking, they would have written an API for all of those file types, so that anyone could use the same system to get access to the data, instead of using their own internal system for scrying for data).
From: peter (Peter da Silva) Date: 19:47 on 22 Apr 2005 Subject: Re: MP3 players? Linux? I'm not sure, but I know there's hate > Interesting; you would be the first person I've communicated with who > actually expresses specific hate about BeOS (I'm obviously ignoring all > of the "but it's not free" trolls out there). Well, it's just that I've used a lot of realtime operating systems that address the problems that BeOS was supposed to be solving and did it a lot better, as well as one PC operating system that, allowing for the limitations of the hardware it was running on, was a far cleaner basic design. What I don't like about BeOS: 1. C++ is an appalling choice for an implementation language. Either a low level language (like C, BCPL, PL/M, or BLISS) or a true high level language (of which there are ample examples) would have been better. Hell, I'd rather an OS written in Javascript. Well, maybe not, but it's not an open-and-shut case. 2. Like the GNU people with HURD, they deliberately embraced inefficiency for the sake of convenience, depending on Moore's Law to pull them out of the hole. That mostly works, eventually, but it leaves a bad taste in my mouth. I mean, people deride UNIX for being inefficient and bulky... but it can run on a Palm IIIx, and run with a GUI on a machine with less horsepower and RAM then a Mac SE. Not SE/30, plain old 68000-based SE. There's some layering problems: 3. The implementation language is tightly bound into the API. Components communicate through APIs that are written in terms of C++ classes and objects. This means that any other language is going to be a second class citizen to a far greater extent than in an OS like UNIX. Cocoa does this too, though the late binding in Objective C mitigates it there. 4. Concurrency at the application level depends on threads. This means that applications HAVE to be multithreaded, they can't use the simple event loop or dispatch model even where it's adequate. It also means that threads have to be prepared to block. Threads are a lousy way to handle concurrency. In fact, threads don't handle concurrency at all, they hand the whole problem over to the application programmer. It's better to have the API based on explicit messages (preferably with bundling like X11 or queueing like AmigaOS) so the client application can deal with it however it likes. There's more, I really don't have time to go into details... but I've seen the user-visible results of all these decisions and they filled me with hate. > > I'll just say that I can understand them reinventing the wheel, but they > > should have actually looked at some of the *round* ones available before > > deciding that a triangle made a better wheel than a pentagon. > Examples? Just about any real-time operating system in existence. > > Oh, and putting necessary metadata in the file system, outside the file, > > where it is GUARANTEED to get lost as son as you have to deal with the > > fact that nobody else in the whole world does it the same way as you even > > if they're daft enough to think it's a good idea, is hateful in so many > > ways... > So I assume that you hate that Unix metadata is in the inode, too? I do in fact have mixed feelings about the layering of file metadata (the execute bit) on file access data (permissions). The file name is the one apparently inescapable piece of file metadata that lives in the inode. For the past 30 years I have had to be aware of the differences between what different operating systems and file systems allow for file names. UNIX has traditionally been a lot less restrictive about file names than most operating systems... not always the most liberal but liberal enough that at the very least moving files TO UNIX has not normally been a major problem, though Mac OS (another OS with very liberal conventions) has occasionally caused problems by allowing "/" as the local part of a file name. For non-UNIX systems, or moving files from UNIX to other systems, it's been a nightmare. This is one of the reasons I am reluctant to accept this design as anything but a trap. We have finally, after more than forty years of dealing with the problem of just file *names*, reached a point where there's only a few last little bits of pain to deal with - FAT32 file systems, case-sensitive versus case-insensitive file systems, the "/" versus "\" issue... Imagine if we were routinely putting more metadata in the file system rather than in things like magic numbers and structured files. > Metadata is exactly that: data about the data. It's a meeting point > between the OS, the app, and the data, and it doesn't make sense to make > the exclusive domain of any of them. Sticking it in the filesystem > works just dandily, as long as you provide good, simple tools for > converting. Caching it in the file system, or in a database, that's fine. So long as you can throw it away and not lose information. Conversion tools? Dear god, I have been flayed and burned and scarred for life by conversion tools JUST FOR FILE NAMES. We're almost past that now. The corpse has been staked, don't drag it out of the coffin again. > > > toning down their lickability, and they still haven't fucking figured > > > out filetyping. Filename extensions? Seriously? No, seriously? > > > Really? *faints* > > Directories, dude. All the advantages of file types and resource > > forks, and they don't go BOOM when you back them up. > So now all of my files are directories? A lot of them are, yes. Garage Band documents, applications, plugins, rich text documents. > I mean, I understand the value > of an abstraction, but I just don't think this whole "files are actually > just abstractions and don't really exist" thing is a good idea. "No, > that's not an app, it's a directory that functions as an abstraction for > an app." No, that's an app. It happens to be implemented as multiple files in a common directory, but that's an application. It's no more of an abstraction than a file. > Metadata in the inode is simple to understand, simple to maintain, > incredibly powerful, really fast (because it's in the inode), and pays a > legacy compatibility cost. So be it. Metadata that is not exposed to the common POSIX API that finally, after decades, virtually every OS implements is a snare. It's harder to maintain even on an isolated system than metadata in the file or metadata in associated files, it's no more powerful, it's no faster (because if it's really "in the inode" it makes the basic file object bigger and slower, and if it's not it's just a directory you can't really see), and it locks you in to a single platform because anyone using a different operating system... even if their OS has a similar mechanism... can see it. > So Spotlight is not copying BFS to some extent? No. It's a separate database about the file that is just a file in the file system, and it contains information that is extracted from file metadata by applications and plugins that know about those files. I am sure that some idiots will start using it for things that need to be preserved outside the local user's environment, but it's not designed with that in mind... it's just a common place to put stuff like a copy of "iTunes Music Library.xml"... it's not like the UNIX execute bit or the Mac finder info or resource fork. > What's better about Spotlight, other than the fact that they obviously > took the next step and started indexing the internals of the apps The better thing is that it's the map, not the territory. It's the library, not the books. It's a spotlight... it tells you WHERE to go but once you get there you have something you can pick up and take somewhere else without worrying whether it will still work when you get there.
From: John Sinteur Date: 20:41 on 22 Apr 2005 Subject: Re: MP3 players? Linux? I'm not sure, but I know there's hate On Apr 22, 2005, at 20:47, Peter da Silva wrote: > For the past 30 years I have had > to be aware of the differences between what different operating > systems and file systems allow for file names. If we're down to THAT kind of hate, do NOT start about line endings. I would hate to have to have the local authorities evacuate the nearest 7 blocks because of the look on my face once we start talking about line endings. -John
From: peter (Peter da Silva) Date: 00:51 on 23 Apr 2005 Subject: Re: MP3 players? Linux? I'm not sure, but I know there's hate > If we're down to THAT kind of hate, do NOT start about line endings. I > would hate to have to have the local authorities evacuate the nearest 7 > blocks because of the look on my face once we start talking about line > endings. Two byte length, optional two byte line number, optional carriage control, and optionally padded to an even multiple of 80 characters (including the carriage control in the first 80 characters, but not including the line number) with spaces. The file type is supposed to match the line format, but if the file was written with FORTRAN Formatted IO it may not be right. You can usually tell by the second byte in the first record: if it's null then there's a line number. Line numbers and carriage control are almost always mutually exclusive. If you get a record length of zero, you need to skip to the next block boundary because there's sometimes junk after the last line in a block, if they're doing block-aligned lines. I think that covers it.
From: Luke Kanies Date: 20:42 on 22 Apr 2005 Subject: Re: MP3 players? Linux? I'm not sure, but I know there's hate On Fri, 2005-04-22 at 13:47 -0500, Peter da Silva wrote: > Well, it's just that I've used a lot of realtime operating systems that > address the problems that BeOS was supposed to be solving and did it a > lot better, as well as one PC operating system that, allowing for the > limitations of the hardware it was running on, was a far cleaner basic > design. Huh; I guess I never specifically compared BeOS to real-time OSes, and I haven't used any that qualify as such, although I've been meaning to try QNX for a while. I was mostly interested in BeOS's advancements on the desktop. > What I don't like about BeOS: > > 1. C++ is an appalling choice for an implementation language. Either a > low level language (like C, BCPL, PL/M, or BLISS) or a true high level > language (of which there are ample examples) would have been better. > > Hell, I'd rather an OS written in Javascript. Well, maybe not, but > it's not an open-and-shut case. I may be showing my youth and naivete here, but I guess I don't think there's a good high-level, compilable language out there that's got very common usage. Objective-C seems like it might have qualified, I guess, but I don't see much else. I'm in the middle of starting a software company, and I spent a while trying to come up with a good language. I absolutely refuse to use something as low-level as C, because it's so inefficient for the programmer, but I couldn't find anything else that seemed like it might not result in my app not being used because of language difficulties. (I ended up sticking with Ruby, even though I really want something that can be compiled.) I guess what I'm trying to say is: There don't seem to be many good choices. Languages seem to mostly suck, too. In addition to being embarassed that anything resembling Unix is the best OS out there, I'm embarassed that anything resembling C is one of the most popular languages out there. "All of the power of assembly language, combined with the flexibility of assembly language." I'd love to hear what you consider to be a good, high-level language, especially something that is compilable. I'm not saying there aren't any -- LISP, Scheme, and Haskell come to mind, and I've heard people mumble that Objective-C could be good (but again, C?) -- but none of the ones I know of seem to have enough users that one could safely write an OS in them. > 2. Like the GNU people with HURD, they deliberately embraced inefficiency > for the sake of convenience, depending on Moore's Law to pull them out > of the hole. That mostly works, eventually, but it leaves a bad taste > in my mouth. Frankly, I loved this about BeOS -- I'd much rather the computer do extra work than the user or the developer do it. It's _always_ cheaper to have the computer do it. OTOH, I could basically never keep my processors working very hard, so I never (as a user) experienced the inefficiency you're talking about. I wish people would do that more -- I hate being depended on to do something, because the developer was lazy, or because the solution is difficult in the language being used, or whatever. My programming philosophy is that if the computer can do it, it should. I don't know if that's what you mean, but... > I mean, people deride UNIX for being inefficient and bulky... but it can > run on a Palm IIIx, and run with a GUI on a machine with less horsepower > and RAM then a Mac SE. Not SE/30, plain old 68000-based SE. That soooooo doesn't impress me. :) I don't deride Unix for being inefficient or bulky... I deride it for being ancient, and long past its prime. It was great when it was new, but it's embarassing that it's still in use with so much kept over. > There's some layering problems: > > 3. The implementation language is tightly bound into the API. Components > communicate through APIs that are written in terms of C++ classes and > objects. This means that any other language is going to be a second class > citizen to a far greater extent than in an OS like UNIX. Cocoa does this > too, though the late binding in Objective C mitigates it there. Is there any way around this problem while still using an OO language? It seems like you'd always have difficulty integrating two languages. > 4. Concurrency at the application level depends on threads. This means > that applications HAVE to be multithreaded, they can't use the simple > event loop or dispatch model even where it's adequate. It also means > that threads have to be prepared to block. While I would have to bow to your greater knowledge in this area, I will say that one of the things I _loved_ about BeOS is that windows never, ever suffered from the refresh problem, because there was always a thread devoted to refresh. I have that problem on all other OSes, and it drives me nuts. It's especially bad on Linux sometimes, but it still hits on OS X. > Threads are a lousy way to handle concurrency. In fact, threads don't > handle concurrency at all, they hand the whole problem over to the > application programmer. It's better to have the API based on explicit > messages (preferably with bundling like X11 or queueing like AmigaOS) > so the client application can deal with it however it likes. > > There's more, I really don't have time to go into details... but I've seen > the user-visible results of all these decisions and they filled me with hate. Huh. I used the os as a user, not really as a developer, and it seems like most of these complaints affect the developer more. I'm assuming some of the warts I saw resulted from these choices, but over all it was still basically the best computing experience I've ever had. > > > I'll just say that I can understand them reinventing the wheel, but they > > > should have actually looked at some of the *round* ones available before > > > deciding that a triangle made a better wheel than a pentagon. > > > Examples? > > Just about any real-time operating system in existence. Do these OSes even have the same goals? BeOS wasn't really meant to be a RTOS, just a good desktop OS. It did have very low latency, but I don't think that was exactly one of the primary goals, it was just part of the whole package. What other RTOSes specifically do you mean? Amiga and QNX? I really don't know. > I do in fact have mixed feelings about the layering of file metadata > (the execute bit) on file access data (permissions). > > The file name is the one apparently inescapable piece of file > metadata that lives in the inode. For the past 30 years I have had > to be aware of the differences between what different operating > systems and file systems allow for file names. UNIX has traditionally > been a lot less restrictive about file names than most operating > systems... not always the most liberal but liberal enough that at > the very least moving files TO UNIX has not normally been a major > problem, though Mac OS (another OS with very liberal conventions) > has occasionally caused problems by allowing "/" as the local part > of a file name. For non-UNIX systems, or moving files from UNIX to > other systems, it's been a nightmare. Of course, file names are not in the inode, but I see what you mean; the name is in the filesystem somewhere. > This is one of the reasons I am reluctant to accept this design as > anything but a trap. We have finally, after more than forty years > of dealing with the problem of just file *names*, reached a point > where there's only a few last little bits of pain to deal with - > FAT32 file systems, case-sensitive versus case-insensitive file > systems, the "/" versus "\" issue... > > Imagine if we were routinely putting more metadata in the file > system rather than in things like magic numbers and structured > files. I am imagining it, and it is a pleasant vision. I despise magic numbers. I think we're going to just have to agree that the other person is wrong here; normally I would (again) bow to your greater experience, but I just don't think I can bring myself to do so here. Having metadata access and storage be exactly the same for every file, every filetype, everything, on the whole system is just so damn powerful. > Caching it in the file system, or in a database, that's fine. So long as > you can throw it away and not lose information. Conversion tools? Dear > god, I have been flayed and burned and scarred for life by conversion > tools JUST FOR FILE NAMES. We're almost past that now. The corpse has > been staked, don't drag it out of the coffin again. Why does metadata have to be something you can throw away without losing information? That's a new one on me... I consider ID3 tags to be mp3 metadata, but I managed to lose all the track numbers on my mp3s last year, and that loss is still annoying the crap out of me. Frankly, I think metadata is pretty damn important, which is one of the reasons why I want more visibility and better control of it. And I want a standard OS interface for managing it. > > So now all of my files are directories? > > A lot of them are, yes. Garage Band documents, applications, plugins, rich > text documents. Yuck yuck yuck. Quadruple-yuck; I'd hate to explain that one to my mom. "Okay, so open the file up, and get the file from inside it." "...<thump>" > > I mean, I understand the value > > of an abstraction, but I just don't think this whole "files are actually > > just abstractions and don't really exist" thing is a good idea. "No, > > that's not an app, it's a directory that functions as an abstraction for > > an app." > > No, that's an app. It happens to be implemented as multiple files in a > common directory, but that's an application. It's no more of an > abstraction than a file. No, it's not an app. I can CD into the directory, find the actual executable, and run that manually. If it were actually an app, I couldn't do that. It's a directory (with metadata in the fucking name!) that the Finder and only the Finder treats specially. That's a really, incredibly stupid design. > Metadata that is not exposed to the common POSIX API that finally, > after decades, virtually every OS implements is a snare. It's harder > to maintain even on an isolated system than metadata in the file or > metadata in associated files, it's no more powerful, it's no faster > (because if it's really "in the inode" it makes the basic file object > bigger and slower, and if it's not it's just a directory you can't > really see), and it locks you in to a single platform because anyone > using a different operating system... even if their OS has a similar > mechanism... can see it. See, that's just fearmongering. "If it's not part of the standard, it's bad." No, I can't agree. If POSIX came anywhere near being sufficient for handling the metadata that people need to actually deal with, we wouldn't have the total lack of coherence that we have. I just don't see how it's harder; harder for whom? The user? They shouldn't really notice. The developer? It's all API to them, right? The power user? As long as there are good APIs (and CLI tools) available, it should be the same for everyone. And yes, with BFS it was really in the inode; each inode was 1024 bytes (because that's the minimum size on the filesystem), but the OS only needed to store about 300 bytes of data. That meant that every file had 700 or so bytes of free space in the inode. If your metadata was less than that (which is quite a few name/value pairs), then it's in the inode, and is part of the 1024 bytes you have to retrieve to do anything at all with the file. If your metadata was more than that, an extra data block (or more, as necessary) was allocated, but that was entirely transparent, and did not involve hidden directories or whatever, just links to more data blocks. So, yes, it's definitely faster, since it requires 0 extra disk or process accesses, and it doesn't increase the size of the inode at all. And again, I just can't countenace lack of interoperability being a good reason not to do something; I take pride in not being interoperable with crappy systems. MacOS 9 wasn't interoperable but it was still the best OS out there (for many purposes, any way) for a long-ass time. The fact that filetyping and metadata are basically unhandled by every OS out there is indicative that the problem is not solved; therefore, trying to stay compatible with people's crappy, half-assed puny attempts to kind of dance around those problems is just silly. > No. It's a separate database about the file that is just a file in the > file system, and it contains information that is extracted from file > metadata by applications and plugins that know about those files. Ugh, that's too bad. > I am sure that some idiots will start using it for things that need > to be preserved outside the local user's environment, but it's not > designed with that in mind... it's just a common place to put stuff > like a copy of "iTunes Music Library.xml"... it's not like the UNIX > execute bit or the Mac finder info or resource fork. I've been trying to figure out how this would work for a while now. Yuck. Hopefully it won't be all bad, but I'm guessing you can expect some hate from me on that topic before too long... > > What's better about Spotlight, other than the fact that they obviously > > took the next step and started indexing the internals of the apps > > The better thing is that it's the map, not the territory. It's the > library, not the books. It's a spotlight... it tells you WHERE to go > but once you get there you have something you can pick up and take > somewhere else without worrying whether it will still work when you get > there. I don't think I understood that. It's a process that trawls your system looking for metadata, using plugins to understand file contents, right? And then it stores the metadata in a db of some kind...? And the Finder has some mechanisms for accessing that db...? I don't understand the "take with you" part of that statement.
From: Daniel Pittman
Date: 01:30 on 23 Apr 2005
Subject: Re: MP3 players? Linux? I'm not sure, but I know there's hate
On 23 Apr 2005, Luke Kanies wrote:
> On Fri, 2005-04-22 at 13:47 -0500, Peter da Silva wrote:
obSoftwareHate: I hate the way Gnus refuses to notice that this is a
mailing list, despite the obvious hints, and respond only to the list by
default.
I hate the way that this is true of every mail reader, and that the
result of this is abuse of Reply-To being demanded all over the place!
[...]
>> What I don't like about BeOS:
>>
>> 1. C++ is an appalling choice for an implementation language. Either a
>> low level language (like C, BCPL, PL/M, or BLISS) or a true high level
>> language (of which there are ample examples) would have been better.
>>
>> Hell, I'd rather an OS written in Javascript. Well, maybe not, but
>> it's not an open-and-shut case.
>
> I may be showing my youth and naivete here, but I guess I don't think
> there's a good high-level, compilable language out there that's got very
> common usage.
Can we hate people for a while here: I hate the fact that high level
languages are for weak programmers, and that real men still write in
assembly language ^W^W C, or spend their time writing anonymous function
closures in C++ templates, because the designers that shat out ^W^W
created the standard accidentally let the stupid things be Turing
complete, so the morons feel a macho urge to rewrite Common Lisp in C++
templates *again*!
> Objective-C seems like it might have qualified, I guess, but I don't
> see much else.
Java could have been a contender, but it was crippled by targeting a
"portable" virtual machine, and by having a standard library designed by
brain-damaged monkeys on crack who threw around memory like it was free,
and couldn't manage a damn standard, common, operation without
allocating, and destroying, half a dozen objects, and couldn't tell why
anyone would care about performance information on the standard library,
and decided to stick as many "platform dependent" or "implementation
defined" operations into the system as they could, and embraced the
worst standards they could find and...
> I'm in the middle of starting a software company, and I spent a while
> trying to come up with a good language. I absolutely refuse to use
> something as low-level as C, because it's so inefficient for the
> programmer, but I couldn't find anything else that seemed like it
> might not result in my app not being used because of language
> difficulties. (I ended up sticking with Ruby, even though I really
> want something that can be compiled.)
Ruby: all the power of Perl with all the obfuscation of Perl and all
utility of Perl... because we needed another wheel there, oh yeah.
There are no good languages. Common Lisp sucks less, except that no one
actually uses it, and even the good (and costly) implementations are
drifting further and further behind the times.
Common Lisp only sucks less because it makes it easier to write your own
domain specific language anyway. Well, and because the standardisation
process set a reasonable standard for documenting your designs.
For reasonable, of course, read "vaguely competent and half complete."
[...]
> I'd love to hear what you consider to be a good, high-level language,
> especially something that is compilable. I'm not saying there aren't
> any -- LISP, Scheme, and Haskell come to mind, and I've heard people
> mumble that Objective-C could be good (but again, C?) --
Objective-C is C in the same way C++ is C -- not at all, but there is a
vague similarity in some areas, so people keep getting fooled into
thinking they are really the same thing.
[...]
>> There's some layering problems:
>>
>> 3. The implementation language is tightly bound into the API. Components
>> communicate through APIs that are written in terms of C++ classes and
>> objects. This means that any other language is going to be a second class
>> citizen to a far greater extent than in an OS like UNIX. Cocoa does this
>> too, though the late binding in Objective C mitigates it there.
>
> Is there any way around this problem while still using an OO language?
Sure, COM does, in that special was that these things are often solved.
JNI, I believe, does the same thing, but I have not had to hate ^W use
it myself. Perl XS stuff does, in so far as it can.
Of course, COM sucks because they tied it to an bad implementation of
reference counting, stuck a stupid software versioning interface on top
of it, added four different and equally broken threading flags that
no-one understood, then used it to build awful software on top of...
> It seems like you'd always have difficulty integrating two languages.
C++ carefully makes this as hard as possible, by refusing to standardise
the ABI. COM chose a vendor and used their ABI, because that is what
C++ requires. C does the same thing, so I suppose that isn't C++
specific hate...
>> 4. Concurrency at the application level depends on threads. This means
>> that applications HAVE to be multithreaded, they can't use the simple
>> event loop or dispatch model even where it's adequate. It also means
>> that threads have to be prepared to block.
>
> While I would have to bow to your greater knowledge in this area, I will
> say that one of the things I _loved_ about BeOS is that windows never,
> ever suffered from the refresh problem, because there was always a
> thread devoted to refresh.
Whee. Because you couldn't, you know, have an application written by
someone who didn't understand threads, and crash because of this, or
block, because their "calculation" thread excluded the "display" thread
while it did something stupid for five minutes.
> I have that problem on all other OSes, and it drives me nuts. It's
> especially bad on Linux sometimes, but it still hits on OS X.
That would be because designing software is hard, and GUI software is
double-hard. It requires all sorts of concurrency and asynchronous
activity, which most people do not understand in the slightest.
Adding threads to that makes it *more* likely, not less, that people
will write code that blocks, or serialises operations, or performs less
well, or crashes at random.
I don't know if you ever tried to deal with writing threaded code, but I
did. It was my job for several years, in fact, to sit there and explain
to people -- more experienced, better programmers in most ways -- just
why their threaded code was awful.
Concurrency: just say no.
Remember Adobe: our best people, for years, and then we finally got a
threaded Photoshop back to the same performance level as a non-threaded
Photoshop.
Threads: just like cocaine, except without dissolving your nose.[1]
[...]
> Huh. I used the os as a user, not really as a developer, and it seems
> like most of these complaints affect the developer more.
Right up until the point that you curse because Mozilla ^W Firefox
crashed or hung again, it sure is a developer issue. Until you drag and
drop a bit of data, and the application hangs for two minutes because
"creating a file is always fast", so they do when they autosave, and it
takes time to detect that the file server has gone down...
> I'm assuming some of the warts I saw resulted from these choices, but
> over all it was still basically the best computing experience I've
> ever had.
...but sure, it could well be the best experience you have had. The
core seems to have been written by engineers who actually *understood*
concurrency. They had mastered the technology. Their systems didn't
suffer these problems.
The threads really didn't start to suck until the rest of the world got
their hands on them, and then wrote bad software.
[... storing metadata in the filesystem, or not ...]
> I am imagining it, and it is a pleasant vision. I despise magic
> numbers. I think we're going to just have to agree that the other
> person is wrong here; normally I would (again) bow to your greater
> experience, but I just don't think I can bring myself to do so here.
> Having metadata access and storage be exactly the same for every file,
> every filetype, everything, on the whole system is just so damn
> powerful.
I agree with you here: a consistent API to metadata is a great thing.
I disagree with you here: that API should *NOT* be part of the
*filesystem*.
Sticking metadata for a file into the inode: there is a world of pain.
It hurts just as soon as you have more than one person using the
filesystem. It hurts a lot, in fact, right at that point.
Why? Well, because people disagree. Maybe you think Pink Floyd suck,
and I love them. Where do we store our rating for it?
What about the latest Ministry album? Is it rock, or gothic rock, or
light metal, or what? Do we both have to agree? Is this metadata that
shouldn't be in the filesystem?
Maybe we each store our own copy of that metadata. Do we do it for one
tag only, or for the entire block? What if we share that filesystem
with two thousand other students at our school?
What about the icon associated with the file? Is that a shared or
individual bit of data?
Once you shove this crap into the filesystem, you OS designer makes
these decisions. I can see the hate either way:
I hate the fact that OS Y decided to only have shared metadata, so I
lose half my ID3 information is someone else renames a file.
I hate that fact that OS Z decided to have common and per-user metadata
in the file, so now my 3.5K JPEG button image comes with 70K of
metatdata, because I copied a file and shrunk it down.
Feel the pain. Come on, feel it with me now. Really. You know it is
there.
[... files as directories ...]
>>> So now all of my files are directories?
>>
>> A lot of them are, yes. Garage Band documents, applications, plugins, rich
>> text documents.
>
> Yuck yuck yuck. Quadruple-yuck; I'd hate to explain that one to my mom.
> "Okay, so open the file up, and get the file from inside it."
> "...<thump>"
...and you *wouldn't* have this pain talking someone through doing
hard-core data recovery if it was a single file?
Seriously, if you want to talk your mom through hacking inside a
document, rather than just opening the damn thing by entering Garage
Band and selecting Open, or whatever, your would is pain anyhow.
Not that using directories, or zip files and XML like Open Office native
documents, or OLE structured storage like Microsoft Office, is any easy
solution to the metadata issue for shared information...
[...]
>> No, that's an app. It happens to be implemented as multiple files in a
>> common directory, but that's an application. It's no more of an
>> abstraction than a file.
>
> No, it's not an app. I can CD into the directory, find the actual
> executable, and run that manually. If it were actually an app, I
> couldn't do that. It's a directory (with metadata in the fucking name!)
> that the Finder and only the Finder treats specially. That's a really,
> incredibly stupid design.
That would be a design flaw in your shell, then, and a bad decision on
the part of the OS designers, rather than a flaw with Directory-is-app
itself.
Just because you hate the way your shell can't see that this is actually
an application (which isn't just the extension, BTW) doesn't mean that
the concept is broken.
...and boy does my cup o' hate run over today.
I hate it all. I am looking forward to two months without touching a
damn computer, while I holiday, oh yes. Maybe when I come back I will
take up being poor and weaving baskets or something.
Daniel
Footnotes:
[1] Well, until one of these threaded environments is used to manage
radiation dosage from an X-ray machine, at which point it may well
melt your nose away for you...
From: peter (Peter da Silva) Date: 03:30 on 23 Apr 2005 Subject: Re: MP3 players? Linux? I'm not sure, but I know there's hate > Java could have been a contender, but it was crippled by targeting a > "portable" virtual machine, and by having a standard library designed by > brain-damaged monkeys on crack who threw around memory like it was free, ... and yet decided that late binding was horribly hard and ineffecient despite the fact that Smalltalk was doing it on a Z80 in 1978 and MacLisp was doing it and generating better code than Fortran in 1976. So you have all the inifficiencies of an interpreted language, all the overhead of a high level memory structure, and all the frustration of pre-object-oriented early-bound strongly-typed languages. Which is why they... > couldn't manage a damn standard, common, operation without > allocating, and destroying, half a dozen objects, ... because they have to create wrapper layers to hide the types of objects in other objects, so they get all the inefficiency of a naive implementation of late binding because there's no way for the compiler to figure out that all these things HAVE TO BE the same primitive type and it can replace a bunch of wrapper calls with an assert and raw machine code. > > I'd love to hear what you consider to be a good, high-level language, > > especially something that is compilable. I'm not saying there aren't > > any -- LISP, Scheme, and Haskell come to mind, and I've heard people > > mumble that Objective-C could be good (but again, C?) -- Modula or concurrent Euclid seem to be good intermediate-between-C-and-C++ level languages. Aleph is allegedly pretty nice, and has been used as the basis of a pretty good OS, but I've never used it. > >> 3. The implementation language is tightly bound into the API. Components > >> communicate through APIs that are written in terms of C++ classes and > >> objects. This means that any other language is going to be a second class > >> citizen to a far greater extent than in an OS like UNIX. Cocoa does this > >> too, though the late binding in Objective C mitigates it there. > > Is there any way around this problem while still using an OO language? Sure. You give each object a method with a name like "marshall" that it uses to spit out an appropriately packed (and documented) version of itself (which when you're operating in the same protection domain turns out to be a pointer to itself) and sets a flag that says it's read-only until it gets itself back from the other end, as well as a method with a name like "clone" that returns an appropriately packed copy of itself that can be passed out and discarded at the other end. Then you define the system calls in terms of marshalled objects that can be constructed without having to actually have that object in the first place. They don't actually have to be the same as the object the real object would generate, so long as you can efficiently build the object on the other side of the protection boundary. And of course if there's no protection boundary the system call turns into a library call to the routine to unpack the object, and then a method call. This can be made very efficient. > C++ carefully makes this as hard as possible, by refusing to standardise > the ABI. That's why you create the "dumb" packed form that can be passed around between implementations that have different ABIs. The real problem with all this is that in practice nobody bothers to implement a marshalling operating other than "convert to an XML string". > Whee. Because you couldn't, you know, have an application written by > someone who didn't understand threads, and crash because of this, or > block, because their "calculation" thread excluded the "display" thread > while it did something stupid for five minutes. I haven't done that. No, not me. Well, not TOO often. > That would be because designing software is hard, and GUI software is > double-hard. It requires all sorts of concurrency and asynchronous > activity, which most people do not understand in the slightest. That's why I like writing the GUI part in scripting languages that abstract the GUI away from the code that does the heavy lifting. Inefficient? Well, a little, you may need to run 50 or 100 instructions to parse a simple string when the fellow hits a menu... but remember you're ALSO making about a dozen protection boundary crossings and doing print-quality antialiased rendering of 20 short text strings and a 6-frame translucency fade to actually bring the menu up... > >> A lot of them are, yes. Garage Band documents, applications, plugins, rich > >> text documents. > > Yuck yuck yuck. Quadruple-yuck; I'd hate to explain that one to my mom. > > "Okay, so open the file up, and get the file from inside it." > > "...<thump>" Um, what? Your mom doesn't need to do any such thing. She double-clicks on the bundle and garageband opens and she only deals with Garageband. When you look inside the bundle you select "see bundle contents", and you can't tell if what you're looking at are files and directories or a virtual file system mounted automagically on the file when you selected that menu. > Seriously, if you want to talk your mom through hacking inside a > document, rather than just opening the damn thing by entering Garage > Band and selecting Open, or whatever, your would is pain anyhow. Right, it's like trying to talk your mom through HEXEDIT. > >> No, that's an app. It happens to be implemented as multiple files in a > >> common directory, but that's an application. It's no more of an > >> abstraction than a file. > > No, it's not an app. I can CD into the directory, find the actual > > executable, and run that manually. OK, now drag the code part of the app out of the folder it's in, and run it. It doesn't work. Why? because it can't find its resources. Now go to a Classic app that does the same thing with file metadata (the finder info and resource fork), and strip the metadata out, and run it. Same result. The only difference between the two models is that I can take that bundle, copy it to a BeOS system, edit the image files that make up the icons and buttons, toss it over to a Linux system, use "vi" on the plist, send it over to Windows, copy in a new copy of the code I've just downloaded from my Google mailbox, and then bring it back to Mac OS X... JUST USING THE STANDARD OS TOOLS ON EACH OS... and it'll run... WITH the changes made on the other systems. For the Classic app I have to archive it into a packed form that no standard apps on any system other than Mac OS knows how to work with, and use HEXEDIT or equivalent to tweak the bitmaps and resources, and ... no, you don't, because only rocket scientists who are happy doing things like "adb -w /dev/kmem" 5 minutes before a demo to the CEO are going to think that's easy. And they both look exactly the same to your mother.
From: Luke Kanies
Date: 07:05 on 23 Apr 2005
Subject: Re: MP3 players? Linux? I'm not sure, but I know there's hate
On Sat, 2005-04-23 at 10:30 +1000, Daniel Pittman wrote:
> Can we hate people for a while here: I hate the fact that high level
> languages are for weak programmers, and that real men still write in
> assembly language ^W^W C, or spend their time writing anonymous function
> closures in C++ templates, because the designers that shat out ^W^W
> created the standard accidentally let the stupid things be Turing
> complete, so the morons feel a macho urge to rewrite Common Lisp in C++
> templates *again*!
Just as a side note, I think your hate wins, today.
> Java could have been a contender, but it was crippled by targeting a
> "portable" virtual machine, and by having a standard library designed by
> brain-damaged monkeys on crack who threw around memory like it was free,
> and couldn't manage a damn standard, common, operation without
> allocating, and destroying, half a dozen objects, and couldn't tell why
> anyone would care about performance information on the standard library,
> and decided to stick as many "platform dependent" or "implementation
> defined" operations into the system as they could, and embraced the
> worst standards they could find and...
Java just seems retardedly non-dynamic. Which I guess is, um, static.
> Ruby: all the power of Perl with all the obfuscation of Perl and all
> utility of Perl... because we needed another wheel there, oh yeah.
I have to say that I can't agree with you there. I'm a perl refugee, as
it were, and I find ruby both more powerful and less obfuscated. Not
that I'm interested in starting a language hate/love thread or whatever,
but I'm continually astounded at how well ruby works for me.
Iterators in ruby, just by themselves, make it more powerful than perl.
And that plus the block/yield stuff goes a long way.
Ruby is also more dynamic; for instance, I'm trying to write a new
language right now (a configuration management language, akin to
cfengine but more like a complete language), and I found myself working
on the AST object for tests. I have two things and an operator; I don't
really know what those things are, and I don't know what the operator
is. But with Ruby, I can just say:
leftthing.send(operator,rightthing)
to perform the test I'm interested in. Yes, I have to watch for errors,
and stuff, and it wouldn't be a bad idea to verify that the leftthing
responds to operator before I call this (but hey, I can easily do that
in ruby, but, um, how the heck would I do that in perl?). Because these
things might be objects, I can't just stick them in an eval statement in
perl; I have to some annoying escaping and crap. I suppose it'd look
like this:
eval("\$leftthing $operator \$rightthing")
But, of course, I'd also have to modify my language so that it only
accepted correct operators ("=" for numbers, "eq" for strings). Yes,
it's a hack to just directly use the language's operators, but I'm fine
with that hack for now -- it's just an alpha, at this point.
> There are no good languages. Common Lisp sucks less, except that no one
> actually uses it, and even the good (and costly) implementations are
> drifting further and further behind the times.
And, frankly, Lisp just seems to fight so many instincts... When I work
very hard, I can read it, but otherwise...
> Objective-C is C in the same way C++ is C -- not at all, but there is a
> vague similarity in some areas, so people keep getting fooled into
> thinking they are really the same thing.
Ah.
[...]
> Whee. Because you couldn't, you know, have an application written by
> someone who didn't understand threads, and crash because of this, or
> block, because their "calculation" thread excluded the "display" thread
> while it did something stupid for five minutes.
Maybe I was just lucky.
Either way you cut it, though, BeOS had some good ideas, although they
most assuredly had their bad ones. At the least I was excited to see
someone make a bunch of new mistakes (at least, they seemed new to me).
> That would be because designing software is hard, and GUI software is
> double-hard. It requires all sorts of concurrency and asynchronous
> activity, which most people do not understand in the slightest.
>
> Adding threads to that makes it *more* likely, not less, that people
> will write code that blocks, or serialises operations, or performs less
> well, or crashes at random.
>
> I don't know if you ever tried to deal with writing threaded code, but I
> did. It was my job for several years, in fact, to sit there and explain
> to people -- more experienced, better programmers in most ways -- just
> why their threaded code was awful.
Thankfully, no, I've not done so. Who knows, though; maybe soon.
[...]
> Right up until the point that you curse because Mozilla ^W Firefox
> crashed or hung again, it sure is a developer issue. Until you drag and
> drop a bit of data, and the application hangs for two minutes because
> "creating a file is always fast", so they do when they autosave, and it
> takes time to detect that the file server has gone down...
I gotta say, while the Moz port sucked, I otherwise had very few
problems on BeOS. It's quite possible that the user base was just so
small that there wasn't much crap; whatever the reason, though, it
worked pretty damn well.
> I agree with you here: a consistent API to metadata is a great thing.
>
> I disagree with you here: that API should *NOT* be part of the
> *filesystem*.
[...]
> Once you shove this crap into the filesystem, you OS designer makes
> these decisions. I can see the hate either way:
>
> I hate the fact that OS Y decided to only have shared metadata, so I
> lose half my ID3 information is someone else renames a file.
>
> I hate that fact that OS Z decided to have common and per-user metadata
> in the file, so now my 3.5K JPEG button image comes with 70K of
> metatdata, because I copied a file and shrunk it down.
>
>
> Feel the pain. Come on, feel it with
You definitely have a point there, and one of the big problems with BeOS
was that it was entirely single-user, and there were some obvious areas
that wouldn't scale to multiple users.
Dammit, I hate being wrong, but I especially hate having wrong hopes. :/
> ...and you *wouldn't* have this pain talking someone through doing
> hard-core data recovery if it was a single file?
>
> Seriously, if you want to talk your mom through hacking inside a
> document, rather than just opening the damn thing by entering Garage
> Band and selecting Open, or whatever, your would is pain anyhow.
It was a bad example, but just the phrase "cd into the file" points out
how retarded the whole idea is.
> > No, it's not an app. I can CD into the directory, find the actual
> > executable, and run that manually. If it were actually an app, I
> > couldn't do that. It's a directory (with metadata in the fucking name!)
> > that the Finder and only the Finder treats specially. That's a really,
> > incredibly stupid design.
>
> That would be a design flaw in your shell, then, and a bad decision on
> the part of the OS designers, rather than a flaw with Directory-is-app
> itself.
Well, I don't really know what to say, then. At this point you need to
decide what is a directory and what is an app, and kind of pick which
one a given thing is. Seems like OS X can't really make up its mind.
I dunno; it just screams "big nasty hack" to me, but... what do I know,
apparently?
> Just because you hate the way your shell can't see that this is actually
> an application (which isn't just the extension, BTW) doesn't mean that
> the concept is broken.
Heh, you misunderstand: I like the fact that the shell exposes reality
to me, I just hate the reality of it.
> ...and boy does my cup o' hate run over today.
>
> I hate it all. I am looking forward to two months without touching a
> damn computer, while I holiday, oh yes. Maybe when I come back I will
> take up being poor and weaving baskets or something.
Interesting; so you don't get the shakes, then? :)
From: peter (Peter da Silva) Date: 13:35 on 23 Apr 2005 Subject: Re: MP3 players? Linux? I'm not sure, but I know there's hate > Dammit, I hate being wrong, but I especially hate having wrong hopes. :/ I've been there. I started out avoiding BeOS not because of the design, which sounded interesting, but because after watching Amiga crash and burn there's no way I was going to get into something else so obviously pre-doomed. Then when I started learning about it, at an abstract level, I got hopeful and excited. Then I started reading the details of how it came together and I recoiled in pain. C++ really is that bad. RPC really is that bad. Threads really are that painful. > It was a bad example, but just the phrase "cd into the file" points out > how retarded the whole idea is. Why? What's wrong with cd-ing into a file? OS/1100 files were structured objects, containing elements, and people used them like directories and used elemets like files. Windows Explorer lets you open any archive file it's aware of and treat it as a directory tree. The difference between a directory containing files with known names and a file containing attributes or forks with known names is just a matter of API design. Semantically they're the same thing... and a simple API is ALWAYS better than a complex one. > Well, I don't really know what to say, then. At this point you need to > decide what is a directory and what is an app, and kind of pick which > one a given thing is. Seems like OS X can't really make up its mind. You're treating the concept "application" as if it's some kind of holy object that HAS to be reduced to a single file. It's not. An application can contain many executable elements, images, tables and structured data. How many files are there making up "perl" or "netscape"? Making an application into a bundle has been a tremendously good thing. It seemed weird at first, when I ran across the idea in NeXTstep, but it really does make a lot of obvious "necessary" layers of crap like "installers" and hunting for the executable in an application directory on Windows and figuring out all the files you need to remove or update on UNIX when you upgrade an application scatters across 10 directories in /usr/local... all that suddenly doesn't matter. It's no longer necessary, because the whole thing is complete in and of itself. I now have a lot of hate over systems that DON'T do it that way, and I hate Gnome and KDE for not being GNUstep with a hate that keeps on giving.
From: Daniel Pittman
Date: 01:45 on 25 Apr 2005
Subject: Re: MP3 players? Linux? I'm not sure, but I know there's hate
On 23 Apr 2005, Luke Kanies wrote:
> On Sat, 2005-04-23 at 10:30 +1000, Daniel Pittman wrote:
>> Can we hate people for a while here: I hate the fact that high level
>> languages are for weak programmers, and that real men still write in
>> assembly language ^W^W C, or spend their time writing anonymous function
>> closures in C++ templates, because the designers that shat out ^W^W
>> created the standard accidentally let the stupid things be Turing
>> complete, so the morons feel a macho urge to rewrite Common Lisp in C++
>> templates *again*!
>
> Just as a side note, I think your hate wins, today.
I was kind of surprised. I suspect that this comes from my impending
overseas trip, since that is the only real source of stress I can put my
finder on at the moment...
>> Java could have been a contender, but it was crippled by targeting a
>> "portable" virtual machine, and by having a standard library designed by
>> brain-damaged monkeys on crack who threw around memory like it was free,
>> and couldn't manage a damn standard, common, operation without
>> allocating, and destroying, half a dozen objects, and couldn't tell why
>> anyone would care about performance information on the standard library,
>> and decided to stick as many "platform dependent" or "implementation
>> defined" operations into the system as they could, and embraced the
>> worst standards they could find and...
>
> Java just seems retardedly non-dynamic. Which I guess is, um, static.
Oddly, that isn't one of my big hates about the language...
I like the split-up of the whole static/dynamic thing I heard a while
back, breaking it into two axis:
A language can have static or dynamic type information. This is about
what is checked at compile time, and when. Perl is dynamic, C is
static.
A language can have weak or strong type information. This is about what
is checked at runtime. C is weak, Java is strong.
C++ is a weak static typed language, which I *do* hate: one mistake, and
a random block of memory just got misinterpreted.
Java is a strong static typed language, at least where I dealt with it:
it does all the static type stuff, but it actually *checks* that at
runtime, so it is almost impossible to assign an address to a number, or
whatever.
This is annoying as heck, in about seventy percent of code, and really
great in about thirty percent.
Perl, on the other hand, is a (wishy-washy) strong dynamic language:
no easy way to check that the arguments are of the right type at compile
time, but it does check at runtime.
I really want my Common Lisp back, some way or another, since it let me
chose between static and dynamic, and almost always between strong and
weak as well, but defaulted to sensible values, *and* did most of the
work for me.
Actually, I think that is what I miss the most: the Common Lisp people
decided that a sufficiently smart compiler was a good goal, so things
like type inference were built in to it.
All of a sudden you could get optimization, automatic function
specialization and a whole slew of static type stuff done by declaring a
few variable types, whereupon the compiler would think about it and
actually use that information to do clever things *without* being told
to. Also, in my experience, it did them *right*, and it was *trivial*
to extend that list of clever things.[1]
>> Ruby: all the power of Perl with all the obfuscation of Perl and all
>> utility of Perl... because we needed another wheel there, oh yeah.
>
> I have to say that I can't agree with you there. I'm a perl refugee, as
> it were, and I find ruby both more powerful and less obfuscated.
[... good features of Ruby ...]
OK. I buy that: Ruby has value that I had not identified. It actually
looks like someone looked at some of the good features of languages that
were designed over the last four decades and paid attention.
I shall have another look at it one of these days, and see if I like it
more this time around.
>> There are no good languages. Common Lisp sucks less, except that no one
>> actually uses it, and even the good (and costly) implementations are
>> drifting further and further behind the times.
>
> And, frankly, Lisp just seems to fight so many instincts... When I work
> very hard, I can read it, but otherwise...
Sure. I bet most of those instincts come from Algol, which every
*other* language you work with today is derived from. Lisp, being the
other white meat, is actually different.
On the other hand, it is more regular[2], equally powerful, and really
not much harder to work with once you know it.
I can understand why a number of people say that learning Lisp is a
great way to be a better programmer: Lisp isn't anything special as a
language, but it is *different*, and doing something that is completely
unalike the rest of your languages helps.
One of these days I will learn Postscript or Forth for the very same
reason, because they are the third completely different style of
language, so far as I can tell.[3]
[...]
>> Whee. Because you couldn't, you know, have an application written by
>> someone who didn't understand threads, and crash because of this, or
>> block, because their "calculation" thread excluded the "display" thread
>> while it did something stupid for five minutes.
>
> Maybe I was just lucky.
Maybe. Maybe BeOS had only attracted great programmers, or they did
something really clever about concurrency.
Heck, maybe they did something real stupid about it and so the
application never really saw it, despite the SMP system.
> Either way you cut it, though, BeOS had some good ideas, although they
> most assuredly had their bad ones. At the least I was excited to see
> someone make a bunch of new mistakes (at least, they seemed new to
> me).
Yes. I agree: BeOS had a lot of cool stuff. Some of the choices were,
in my opinion, mistakes, but so it goes.
>> That would be because designing software is hard, and GUI software is
>> double-hard. It requires all sorts of concurrency and asynchronous
>> activity, which most people do not understand in the slightest.
>>
>> Adding threads to that makes it *more* likely, not less, that people
>> will write code that blocks, or serialises operations, or performs less
>> well, or crashes at random.
>>
>> I don't know if you ever tried to deal with writing threaded code, but I
>> did. It was my job for several years, in fact, to sit there and explain
>> to people -- more experienced, better programmers in most ways -- just
>> why their threaded code was awful.
>
> Thankfully, no, I've not done so. Who knows, though; maybe soon.
Well, if you are about to enter this territory, let me give you this
advice:
Threads are just like processes, except they give up the advances in
operating system design in the last thirty years ^W^W^W^W^W since
classic MacOS bit the big, and well deserved, bullet.
No memory protection, really and truly, is awful. Shared file tables,
memory allocators, system state[4], current directory[5], shared library
state and related fun are also awful.
Build your code more than one *process*, and communicate through an
internal protocol over file descriptors, Unix domain sockets and/or
shared memory.
If you really love your life, do this by adopting some sort of message
passing library (even if you call it an Object Oriented calling
interface, or RPC, or whatever) where someone *else* did the hard work
of making the above work.
Then revel in the joy of having concurrency be *so* much easier, because
things are shared over a *defined* interface, rather than an implicit
one the size of your entire codebase.
Dance happily when you find that you *can* take advantage of SMP
*without* having to use a single lock anywhere in your code, and that
you never need to understand the semantics of bus-locked atomic
operations.[6]
Just call the routine that you use to launch the sub-process
"create_processing_thread" so that stupid people can't tell that you did
something sane. :)
To stay on topic, I hate the way that software has to use threads to be
cool, and multiple processes is a sign that the design was poor. *Hate*
[...]
>> I agree with you here: a consistent API to metadata is a great thing.
>>
>> I disagree with you here: that API should *NOT* be part of the
>> *filesystem*.
> [...]
>> Once you shove this crap into the filesystem, you OS designer makes
>> these decisions. I can see the hate either way:
>>
>> I hate the fact that OS Y decided to only have shared metadata, so I
>> lose half my ID3 information is someone else renames a file.
>>
>> I hate that fact that OS Z decided to have common and per-user metadata
>> in the file, so now my 3.5K JPEG button image comes with 70K of
>> metatdata, because I copied a file and shrunk it down.
>>
>>
>> Feel the pain. Come on, feel it with
>
> You definitely have a point there, and one of the big problems with BeOS
> was that it was entirely single-user, and there were some obvious areas
> that wouldn't scale to multiple users.
>
> Dammit, I hate being wrong, but I especially hate having wrong hopes.
Yeah, me too. I feel bad about saying all that, because I *know* your
hope -- I used to have the same one. I even tried to design it into the
little toy OS a friend and I wrote[7]...
Then I worked it out. What you really want is a big-ass relational
database type system, which your users *can* access in a standard way,
and which can store this stuff.
It isn't part of the file, in a meaningful way, but the system *should*
be doing *all* the hard work of making it look like that.
Well, *most* of it isn't part of the system. Some bits, like the MIME
type and the ACL, *are* metatdata that belongs in the filesystem.
Other parts, including (I think) the name, should be somewhere else, so
you can translate or customise on a per user basis, if needs be.
...well, when I say MIME type, I actually mean "file type information",
much like MacOS classic did, except using what has become the standard,
universally exchanged version of the same.
Then Apache can ask the system what type this file is, and *know* that
it is a Perl script without having to guess based on the first line...
Any other standard, common, widely used way of identifying the same
would do as well as MIME types. There just isn't one, so far as I can
tell.
>> ...and you *wouldn't* have this pain talking someone through doing
>> hard-core data recovery if it was a single file?
>>
>> Seriously, if you want to talk your mom through hacking inside a
>> document, rather than just opening the damn thing by entering Garage
>> Band and selecting Open, or whatever, your would is pain anyhow.
>
> It was a bad example, but just the phrase "cd into the file" points out
> how retarded the whole idea is.
Sure. That would be because "file" is a bit of computer jargon, with a
specific meaning that isn't "directory."
Personally, I would have said "cd into the document", and been happy
with it, because document is a more nebulous concept that accepts this
use better.
>>> No, it's not an app. I can CD into the directory, find the actual
>>> executable, and run that manually. If it were actually an app, I
>>> couldn't do that. It's a directory (with metadata in the fucking name!)
>>> that the Finder and only the Finder treats specially. That's a really,
>>> incredibly stupid design.
>>
>> That would be a design flaw in your shell, then, and a bad decision on
>> the part of the OS designers, rather than a flaw with Directory-is-app
>> itself.
>
> Well, I don't really know what to say, then. At this point you need to
> decide what is a directory and what is an app, and kind of pick which
> one a given thing is. Seems like OS X can't really make up its mind.
>
> I dunno; it just screams "big nasty hack" to me, but... what do I know,
> apparently?
None of this hate is directed at you, personally; I hope you know that.
Anyway, I don't see using a directory and a set of files to store a
"document" as more of a hack than using a zip file with a different
extension to do so.
I *certainly* don't see it as more of a hack than using the stupid-ass
OLE "structure storage" filesystem to do so.
Boy o boy, if you ever want to teach a "how not to design filesystems"
class, start with FAT and follow up with OLE structure storage. Provide
knives at the door to gouge out your eyes to escape the pain, though,
since most people will want to.
I also consider it less of a hack than one of the suggested uses of
ReiserFS: grab the user-space library version and use *that* as your
backing store in your document format.
Yes, that is correct: take a full general purpose filesystem, stick it
in a file, and store your content in there.
In this "one document, one file" world that probably makes sense.
I can't see the benefit of it over the "one document, one directory"
style, though. Well, maybe for ease of cut-and-paste transfer, or
something.
>> Just because you hate the way your shell can't see that this is actually
>> an application (which isn't just the extension, BTW) doesn't mean that
>> the concept is broken.
>
> Heh, you misunderstand: I like the fact that the shell exposes reality
> to me, I just hate the reality of it.
OK. I can accept your obvious lack of taste here. After all, my views
are clearly the only possibly correct ones, after all. ;)
>> ...and boy does my cup o' hate run over today.
>>
>> I hate it all. I am looking forward to two months without touching a
>> damn computer, while I holiday, oh yes. Maybe when I come back I will
>> take up being poor and weaving baskets or something.
>
> Interesting; so you don't get the shakes, then? :)
No, not really. If I *really* jones for a fix of hate, I can probably
get in on the Internet Cafe computers I use to send email updates to ...
something, where our family can know we have not yet died on the road...
Daniel
Footnotes:
[1] Well, trivial in the same sense that hacking the thread storage
block and the stack makes it trivial to handle system level, rather
than runtime level, exceptions under Windows. It was only a dozen
lines of assembly code; what is hard about that?
[2] Standard Common Lisp, whacking insanely huge thing that it is,
needs 24 specific "functions" implemented by the compiler, or code
walker. The rest is derived from those. This is ... different
from any other language I have met.
[3] Well, "learn" as in be able to actually program in, rather than
"learn" as in hack on Postscript layout generators, and
hand-correct broken PS code.
[4] on some platforms. whee.
[5] on some platforms and, occasionally, some versions of a platform.
[6] One of the biggest pains with SMP code are atomic operations:
no, you *can't* add two values that you manipulate with atomic
operations with a non-atomic operation and expect it to work.
[7] Well, at the time it was going to be the latest greatest thing, bit
I was 19 and had just dealt with first year University, so I knew
everything at the time.
From: peter (Peter da Silva) Date: 03:38 on 25 Apr 2005 Subject: Re: MP3 players? Linux? I'm not sure, but I know there's hate > A language can have static or dynamic type information. This is about > what is checked at compile time, and when. Perl is dynamic, C is > static. Smalltalk is dynamically typed but the Smalltalk compiler can derive enough information about types to do compile time type checking. All static typing does is force the programmer to make assertions about types. A dynamically typed language allows you to defer those assertions to runtime when you can't make them at compile time. Or make the assertions and... hey... now the compiler has all the same type info that it did in the static case. The thing is, about the only time you REALLY can't derive the type information in a dynamically typed language, it's because you REALLY can't derive the types at compile time, so you have to re-implement a run-time type system in your statically typed langauge. And because you're implementing it yourself the compiler doesn't know about it so it can't include that in its code generation, so it can't optimise it away when a dynamically typed language would have. > A language can have weak or strong type information. This is about what > is checked at runtime. C is weak, Java is strong. Again, a good compiler can do this at compile time. And in fact, Java doesn't do it at run time all that often. The compiler does it at compile time. What the runtime does is prove that the compiler didn't screw up... that's an implementation detail. You can compile Java to machine code and that runtime step goes away... but the language is the same. The difference between strong and weak typing has nothing to do with compile time versus runtime. It has to do with whether the language provides a low level escape from the type system so you can more efficiently implement the dynamic typing that you don't get for free with a statically typed language. C lets you completely bypass the type system so you can efficiently implement things like qsort(). Java lets you create a whole bunch of extra methods and wrappers to get to kind of the same place. Lisp lets you define a macro and then gets out of the way so the optimizer can drag it for type information. Perl thinks efficiency is for wimps. > Actually, I think that is what I miss the most: the Common Lisp people > decided that a sufficiently smart compiler was a good goal, so things > like type inference were built in to it. ... oh, I'm preaching to the choir. Nevermind. > One of these days I will learn Postscript or Forth for the very same > reason, because they are the third completely different style of > language, so far as I can tell.[3] Smalltalk and Icon are also pretty nice. > Maybe. Maybe BeOS had only attracted great programmers, or they did > something really clever about concurrency. BeOS big advantage in this kind of discussion is that they didn't last long enough or get big enough to attract any but the most highly motivated developers. And even so, they really screwed up networking. > No memory protection, really and truly, is awful. Shared file tables, > memory allocators, system state[4], current directory[5], shared library > state and related fun are also awful. The lack of memory protection is painful, because when you screw up you scribble on another thread so when you crash you have no idea what went wrong. But you can deal with that. Sharing other operating system state is a lot harder to deal with. AmigaOS had no memory protection, but processes and tasks were dealt with as completely separate units by the OS so you didn't have one thread interrupt another in the middle of a call to some library code that forgot to do enough locking around shared state. > Build your code more than one *process*, and communicate through an > internal protocol over file descriptors, Unix domain sockets and/or > shared memory. AmigaOS message queues were pretty nice too, and DragonFlyBSD is following the same kind of model but building it in a little at a time. > If you really love your life, do this by adopting some sort of message > passing library (even if you call it an Object Oriented calling > interface, or RPC, or whatever) where someone *else* did the hard work > of making the above work. The problem with RPC is it puts you in lockstep with the idiot over on the other side, so even if you're not sharing state with him you're sharing execution context with him by proxy. It's better than just shoving your arm up the concurrency-beast's rear without so much as a rubber glove, but it's still unpleasant. > To stay on topic, I hate the way that software has to use threads to be > cool, and multiple processes is a sign that the design was poor. *Hate* I share your hate. What did you think about Plan 9? > Well, *most* of it isn't part of the system. Some bits, like the MIME > type and the ACL, *are* metatdata that belongs in the filesystem. The ACL, yes, that's not really metadata about the file, it's metadata about who's allowed to touch it. Putting te MIME type in the file system, though, is a great way to end up with all the problems that Mac OS Finder Info can cause when it goes just the slightest bit wrong.
From: Daniel Pittman
Date: 10:05 on 25 Apr 2005
Subject: Re: MP3 players? Linux? I'm not sure, but I know there's hate
On 25 Apr 2005, Peter da Silva wrote:
>> A language can have static or dynamic type information. This is about
>> what is checked at compile time, and when. Perl is dynamic, C is
>> static.
[...]
>> A language can have weak or strong type information. This is about what
>> is checked at runtime. C is weak, Java is strong.
>
> Again, a good compiler can do this at compile time. And in fact, Java
> doesn't do it at run time all that often. The compiler does it at compile
> time. What the runtime does is prove that the compiler didn't screw up...
> that's an implementation detail. You can compile Java to machine code and
> that runtime step goes away... but the language is the same.
My recollection was that the language specification said that the
runtime environment MUST do enough type checking to be sure you couldn't
reinterpret random memory as other random memory, but I could be wrong.
Maybe I should have said Emacs Lisp there, because I *know* that does.
> The difference between strong and weak typing has nothing to do with
> compile time versus runtime. It has to do with whether the language
> provides a low level escape from the type system so you can more
> efficiently implement the dynamic typing that you don't get for free
> with a statically typed language.
That doesn't gel with the division I heard, which suggests that my
memory is wrong, or different people use this detailed breakdown
differently. Hrm.
> C lets you completely bypass the type system so you can efficiently implement
> things like qsort(). Java lets you create a whole bunch of extra methods
> and wrappers to get to kind of the same place. Lisp lets you define a macro
> and then gets out of the way so the optimizer can drag it for type information.
> Perl thinks efficiency is for wimps.
Still, this makes sense. Besides, Perl doesn't think efficiency is for
wimps, it provides all sorts of kew1 optimizations like $a and $b being
hacked into your sort routines symbol table, but only if you don't look
at the arguments to the function. *Hate*
[...]
>> One of these days I will learn Postscript or Forth for the very same
>> reason, because they are the third completely different style of
>> language, so far as I can tell.[3]
>
> Smalltalk and Icon are also pretty nice.
The key feature that Postscript and Forth have, for my learning them, is
the stack based language thing. They are both (as I understand it,
which is to say, not very deeply) based around the same sort of core
execution stack thingy. Well, that or really odd magic, since last time
I really tackled them it felt like that was really the key.
[...]
>> No memory protection, really and truly, is awful. Shared file tables,
>> memory allocators, system state[4], current directory[5], shared library
>> state and related fun are also awful.
>
> The lack of memory protection is painful, because when you screw up you
> scribble on another thread so when you crash you have no idea what went
> wrong. But you can deal with that.
Yup. Also, it encourages an overly broad interface definition, because
it is "easy" to peek into the internal state of the other parts of the
code.
> Sharing other operating system state is a lot harder to deal with.
> AmigaOS had no memory protection, but processes and tasks were dealt
> with as completely separate units by the OS so you didn't have one
> thread interrupt another in the middle of a call to some library code
> that forgot to do enough locking around shared state.
Memory protection isn't something you *need*, but it sure is nice, and
is one of those things that I think represents a real advantage of
modern hardware/software over the older stuff.
If we didn't have it, something akin to the AmigaOS messaging layer
would be even *more* attractive.[1]
[...]
>> If you really love your life, do this by adopting some sort of message
>> passing library (even if you call it an Object Oriented calling
>> interface, or RPC, or whatever) where someone *else* did the hard work
>> of making the above work.
>
> The problem with RPC is it puts you in lockstep with the idiot over on
> the other side, so even if you're not sharing state with him you're
> sharing execution context with him by proxy.
>
> It's better than just shoving your arm up the concurrency-beast's rear
> without so much as a rubber glove, but it's still unpleasant.
Last time I dealt with an RPC system it was asynchronous, but you are
right: most of them are awful things well deserving of the hate they
get from anyone working closely with them, except Microsoft, who seem
immune.
>> To stay on topic, I hate the way that software has to use threads to be
>> cool, and multiple processes is a sign that the design was poor. *Hate*
>
> I share your hate. What did you think about Plan 9?
The same thing I thought when I first heard about it: this will never
fly, but hopefully the good bits will get out to somewhere else.
They seemed to have some great ideas about consistency, and a good grasp
on how to design a good interface to devices, window systems, etc, and
completely awful taste in GUI design.
It always looked like it was going to be an academic project to me,
though, so I never put too much effort into learning it.
Given that, I don't even know if they used a lot of threads, or not.
>> Well, *most* of it isn't part of the system. Some bits, like the MIME
>> type and the ACL, *are* metatdata that belongs in the filesystem.
>
> The ACL, yes, that's not really metadata about the file, it's metadata
> about who's allowed to touch it.
In the context of the discussion, true.
> Putting te MIME type in the file system, though, is a great way to end
> up with all the problems that Mac OS Finder Info can cause when it
> goes just the slightest bit wrong.
Maybe. I still cling to the idea that type identification can be
useful, since everyone wants to do it, and everyone does it differently
and badly.
I wouldn't mind seeing someone try, just to find out, though.
Daniel
...so long as I don't have to write the standard.
Footnotes:
[1] Not that I ever used it, but it makes sense, and you enthuse enough
about it to make it sound great. ;)
From: peter (Peter da Silva) Date: 13:08 on 25 Apr 2005 Subject: Re: MP3 players? Linux? I'm not sure, but I know there's hate > My recollection was that the language specification said that the > runtime environment MUST do enough type checking to be sure you couldn't > reinterpret random memory as other random memory, but I could be wrong. That dosn't require any type checking at runtime, if the input language is completely statically typed checked. It does require parameter type checking at link time, but that's an implementation issue... you can statically link the whole shooting match... and has nothing to do with the languages type model. The only thing you need at runtime is bounds checking on arrays, and that's got nothing to do with types. > > The difference between strong and weak typing has nothing to do with > > compile time versus runtime. It has to do with whether the language > > provides a low level escape from the type system so you can more > > efficiently implement the dynamic typing that you don't get for free > > with a statically typed language. > That doesn't gel with the division I heard, which suggests that my > memory is wrong, or different people use this detailed breakdown > differently. Hrm. I don't know which official taxonomy you're talking about, I'm just talking about what the language's model exposes to the programmer. And the difference between compile time and run time isn't something that the language can really tell you about except in terms of its interaction with the host environment where things like dynamic linking are visible to the programmer. > >> One of these days I will learn Postscript or Forth for the very same > >> reason, because they are the third completely different style of > >> language, so far as I can tell.[3] > > Smalltalk and Icon are also pretty nice. > The key feature that Postscript and Forth have, for my learning them, is > the stack based language thing. Oh, yeh, but they're otherwise really pretty different. Postscript's got a vaguely Forth-like syntax, but semanticaly it's really close to Lisp. Forth is semantically pretty much assembly code, it's about as close to the hardware as you can get without talking about actual machine instructions. > > The problem with RPC is it puts you in lockstep with the idiot over on > > the other side, so even if you're not sharing state with him you're > > sharing execution context with him by proxy. > > It's better than just shoving your arm up the concurrency-beast's rear > > without so much as a rubber glove, but it's still unpleasant. > Last time I dealt with an RPC system it was asynchronous, Perhaps I don't understand what's RPC and what's interface then, but I was under the impression that at the language level an RPC was a rendezvous operation like an ADA message. > It always looked like it was going to be an academic project to me, > though, so I never put too much effort into learning it. Well, Bell Labs was using it in production. > Given that, I don't even know if they used a lot of threads, or not. No threads at all: fork() was it. > >> Well, *most* of it isn't part of the system. Some bits, like the MIME > >> type and the ACL, *are* metatdata that belongs in the filesystem. > > The ACL, yes, that's not really metadata about the file, it's metadata > > about who's allowed to touch it. > In the context of the discussion, true. You can change the ACL without changing the meaning of the file. That kind of metadata is a different kettle of aquatic vertebrates than MIME types. > > Putting te MIME type in the file system, though, is a great way to end > > up with all the problems that Mac OS Finder Info can cause when it > > goes just the slightest bit wrong. > Maybe. I still cling to the idea that type identification can be > useful, since everyone wants to do it, and everyone does it differently > and badly. As far as I'm concerned there's only been one lot that ever did that kind of thing correctly, and ironically they were a videogame company. FORM nnnn 8SVX NAME 000A "Pan Flute" AUTH 0011 "Electronic Arts" ...
From: Daniel Pittman
Date: 13:48 on 25 Apr 2005
Subject: Re: MP3 players? Linux? I'm not sure, but I know there's hate
On 25 Apr 2005, Peter da Silva wrote:
>> My recollection was that the language specification said that the
>> runtime environment MUST do enough type checking to be sure you couldn't
>> reinterpret random memory as other random memory, but I could be wrong.
>
> That dosn't require any type checking at runtime, if the input language
> is completely statically typed checked.
Nor does it. Thanks - that makes that clearer, I hope, in my head.
[...]
>> That doesn't gel with the division I heard, which suggests that my
>> memory is wrong, or different people use this detailed breakdown
>> differently. Hrm.
>
> I don't know which official taxonomy you're talking about, I'm just talking
> about what the language's model exposes to the programmer.
I don't know it was official, but it seemed to be pretty broadly useful.
I think that I had misunderstood, or remembered, it, though, since your
explanation makes it make no sense.
[...]
>>> The problem with RPC is it puts you in lockstep with the idiot over on
>>> the other side, so even if you're not sharing state with him you're
>>> sharing execution context with him by proxy.
>
>>> It's better than just shoving your arm up the concurrency-beast's rear
>>> without so much as a rubber glove, but it's still unpleasant.
>
>> Last time I dealt with an RPC system it was asynchronous,
>
> Perhaps I don't understand what's RPC and what's interface then, but I was
> under the impression that at the language level an RPC was a rendezvous
> operation like an ADA message.
I think it may have been originally; IIRC, DCE and thus Windows RPC is
implemented that way. CORBA, at least, claims RPC and has asynchronous
operation tucked away somewhere within it as I recall.
My last call was an awful "middleware" system that way being used to
make life vastly more difficult for everyone involved in the particular
banking system. Theoretically, it gave value. Practically, they never
used any of that value, so it just made things harder.
Anyhow, what I was thinking of when I said RPC was "any tool that
automatically generates local stub code for message passing."
>> It always looked like it was going to be an academic project to me,
>> though, so I never put too much effort into learning it.
>
> Well, Bell Labs was using it in production.
>
>> Given that, I don't even know if they used a lot of threads, or not.
>
> No threads at all: fork() was it.
I think that Linux has actually taken the best path here: they provide
a 'clone' system call which you tell exactly how much state you want to
share with the other thread (or process).
fork() is share nothing, threads are share everything, and you can do
other stuff if you really want to like share memory but not file table,
or whatever.
That way the few tasks that *do* benefit from threads can take advantage
of them, and you can do equally clever things with other sharing models.
Of course, all of it is non-portable, which is a source of hate, but
hey, we can dream.
[...]
>>> Putting te MIME type in the file system, though, is a great way to end
>>> up with all the problems that Mac OS Finder Info can cause when it
>>> goes just the slightest bit wrong.
>
>> Maybe. I still cling to the idea that type identification can be
>> useful, since everyone wants to do it, and everyone does it differently
>> and badly.
>
> As far as I'm concerned there's only been one lot that ever did that kind
> of thing correctly, and ironically they were a videogame company.
>
> FORM nnnn 8SVX NAME 000A "Pan Flute" AUTH 0011 "Electronic Arts" ...
So you mentioned. I never worked with AIFF format files, except as an
end user, so I don't have much practical experience there.
Daniel
From: peter (Peter da Silva) Date: 14:38 on 25 Apr 2005 Subject: Re: MP3 players? Linux? I'm not sure, but I know there's hate > Anyhow, what I was thinking of when I said RPC was "any tool that > automatically generates local stub code for message passing." Hmmm, I'd lump that in with any other stub generator. So if the underlying message mechanism is queued then the call returns immediately, and you need to make another call later to get the reply? > I think that Linux has actually taken the best path here: they provide > a 'clone' system call which you tell exactly how much state you want to > share with the other thread (or process). Plan 9 fork() is rfork(RFNOWAIT|RFNAMEG|RFENVG|RFFDG|RFPROC), if I've got all my flags right. It's somewhere in the middle between share nothing and share everything. > >> Maybe. I still cling to the idea that type identification can be > >> useful, since everyone wants to do it, and everyone does it differently > >> and badly. > > As far as I'm concerned there's only been one lot that ever did that kind > > of thing correctly, and ironically they were a videogame company. > > FORM nnnn 8SVX NAME 000A "Pan Flute" AUTH 0011 "Electronic Arts" ... > So you mentioned. I never worked with AIFF format files, except as an > end user, so I don't have much practical experience there. Well, there's a lot of other IFF FORMs than AIFF. And that's really the important thing.
From: Daniel Pittman
Date: 15:33 on 25 Apr 2005
Subject: Re: MP3 players? Linux? I'm not sure, but I know there's hate
On 25 Apr 2005, Peter da Silva wrote:
>> Anyhow, what I was thinking of when I said RPC was "any tool that
>> automatically generates local stub code for message passing."
>
> Hmmm, I'd lump that in with any other stub generator.
>
> So if the underlying message mechanism is queued then the call returns
> immediately, and you need to make another call later to get the reply?
Usually. I think one of the systems we dealt with at a former workplace
required you to select on their socket, and then call their code which
would call back to your registered handler or something.
Daniel
From: Aaron J. Grier Date: 00:12 on 28 Apr 2005 Subject: Re: MP3 players? Linux? I'm not sure, but I know there's hate On Fri, Apr 22, 2005 at 02:42:00PM -0500, Luke Kanies wrote: > The fact that filetyping and metadata are basically unhandled by every > OS out there is indicative that the problem is not solved; therefore, > trying to stay compatible with people's crappy, half-assed puny > attempts to kind of dance around those problems is just silly. I keep waiting for VMS users to come out of the woodwork... come on... you know you're out there...
From: David Cantrell Date: 21:34 on 23 Apr 2005 Subject: Re: MP3 players? Linux? I'm not sure, but I know there's hate Peter da Silva wrote: > There's some layering problems [with BeOS]: > > 3. The implementation language is tightly bound into the API. Components > communicate through APIs that are written in terms of C++ classes and > objects. No worse than all the bits of Unix API that are defined in terms of C structs. Dealing with them from some other languages is a gigantic pain in the arse. In fact, such a pain in the arse that a common solution is to write a little C layer that understands something sane and translates it into Unix C struct insanity. Defining something in terms of C structs is a shitty way of defining it, just as shitty as defining it in terms of C++ objects, as a C struct is just as poorly defined and implementation specific. Take, for instance, the mktime function, which takes a struct as an argument. The man page defines the struct, but defines it in C syntax. How about defining it PROPERLY, how the bytes are laid out, so that I can easily create such a structure in some other language? Or look at gettimeofday, one argument to which is a struct containing two longs. Now I have to guess whether long == int, or whether long is twice as big as an int - because the size of 'long' isn't defined anywhere! > The file name is the one apparently inescapable piece of file > metadata that lives in the inode. Palm OS, I think, keeps "file" names (really database names) in the database. All it stores outside the databases is a list of pointers to databases. This works very well for a small system but obviously doesn't scale. > Imagine if we were routinely putting more metadata in the file > system rather than in things like magic numbers and structured > files. Mmmm, structured files. I wonder how those structures would be defined.
From: peter (Peter da Silva) Date: 23:22 on 23 Apr 2005 Subject: Re: MP3 players? Linux? I'm not sure, but I know there's hate > > 3. The implementation language is tightly bound into the API. Components > > communicate through APIs that are written in terms of C++ classes and > > objects. > No worse than all the bits of Unix API that are defined in terms of C > structs. You may occasionally have to write a bit of test code with offsetof and sizeof to be sure you know what's going on... but at least the actual elements can easily be rendered down to hardware types and in most cases you can automate the conversion. And if you really want to write a wrapper anyway, C is a pretty small and simple language to interface to (see below), and because all the stuff in the structs are primitives your C wrapper is a handful of assigns. Try THAT in C++. I don't know, I've written code in Forth on lots of systems, and in every one I had to build native structures and system calls out of Forth primitives which are pretty damn primitive... and UNIX has been nowhere near the worst API to deal with. In fact for RSX-11/M, which DOES define all its structures in terms of well defined assembly code, I finally gave up trying to read a text file from Forth and let Fortran be my wrapper there. And let me tell you, if you think a C wrapper is a pain, try a Fortran one. > mktime mktime(3) is not a system call. > Or look at gettimeofday, one argument to which is a struct containing > two longs. Now I have to guess whether long == int, or whether long is > twice as big as an int - because the size of 'long' isn't defined anywhere! Yes, I remember hating the fact that they decided to wimp out and NOT make long 64 bits on the VAX in 1980. But you only have to learn that once for an implementation, and I've found that there's about 20 important calls and as many structures that you REALLY have to have down before you can build real useful code on UNIX. > > Imagine if we were routinely putting more metadata in the file > > system rather than in things like magic numbers and structured > > files. > Mmmm, structured files. I wonder how those structures would be defined. Well, I like the Electronic Arts/Amiga Interchange File Format.
From: David Cantrell Date: 20:50 on 24 Apr 2005 Subject: Re: MP3 players? Linux? I'm not sure, but I know there's hate On Sat, Apr 23, 2005 at 05:22:10PM -0500, Peter da Silva wrote: > > > 3. The implementation language is tightly bound into the API. Components > > > communicate through APIs that are written in terms of C++ classes and > > > objects. > > No worse than all the bits of Unix API that are defined in terms of C > > structs. > > mktime > mktime(3) is not a system call. It's part of "the Unix API". But if you insist on something that is more intimately tied to Unix, try stat, which is even more hateful. > > Or look at gettimeofday, one argument to which is a struct containing > > two longs. Now I have to guess whether long == int, or whether long is > > twice as big as an int - because the size of 'long' isn't defined anywhere! > Yes, I remember hating the fact that they decided to wimp out and NOT make > long 64 bits on the VAX in 1980. But you only have to learn that once for > an implementation You misunderstand my Hate. I hate that long is *not defined*, just like I hate that a struct is *not defined*. If it were defined I really wouldn't care whether it was 32 bits or 64 bits, because I could just write code to build the structure using my language of choice.
From: peter (Peter da Silva) Date: 23:37 on 24 Apr 2005 Subject: Re: MP3 players? Linux? I'm not sure, but I know there's hate > It's part of "the Unix API". Section 3 is the C runtime. If you're calling things in section 3 you're already using a C wrapper. When I ported Forth to UNIX I just implemented syscal() and then wrote the rest in Forth. It's MUCH easier than linking to a C library. > But if you insist on something that is > more intimately tied to Unix, try stat, which is even more hateful. Hmmm. All the objects defined in sys/stat.h are built up of primitive elements with specific bit sizes or structures defined in similar terms. And they all land on properly aligned word boundaries. There's obviously hardware-specific details like byte order to worry about but if you're porting a language to a computer or writing a language runtime you already know that stuff. Seriously, I don't see that this is particularly bothersome let alone hateful. > You misunderstand my Hate. I hate that long is *not defined*, just like Long is defined FOR EACH SPECIFIC COMPUTER. If you're porting your language to an Alpha, you know that long is 64 bits. If you don't know that, how the hell are you going to generate code for it? > I hate that a struct is *not defined*. The struct is defined in the C include file, which is easy to read and understand... it's barely higher level than the control block structures in RSX-11 and a LOT better documented than the Macro-11 macros that define the RSX-11 system calls. > If it were defined I really > wouldn't care whether it was 32 bits or 64 bits, because I could just > write code to build the structure using my language of choice. Which is what I do, I don't know why you find it hard. The more recent trend for system calls to be defined in terms of shared libraries, now THAT is hateful. That's starting UNIX down the slippery slope to being as language-dependent as BeOS.
From: David Cantrell
Date: 13:13 on 25 Apr 2005
Subject: Re: MP3 players? Linux? I'm not sure, but I know there's hate
On Sun, Apr 24, 2005 at 05:37:15PM -0500, Peter da Silva wrote:
> > But if you insist on something that is
> > more intimately tied to Unix, try stat, which is even more hateful.
> Hmmm. All the objects defined in sys/stat.h are built up of primitive
> elements with specific bit sizes or structures defined in similar
> terms.
I got tired of hunting through a maze of twisty include files and C
pre-processor directives for the exact definitions on a Linux platform,
so just looked in K&R instead. There, struct stat is defined as:
struct stat
{
dev_t st_dev;
ino_t st_ino;
short st_mode;
short st_nlink;
short st_uid;
short st_gid;
dev_t st_rdev;
off_t st_size;
time_t at_atime;
time_t at_mtime;
time_t at_ctime;
};
Even without delving through that maze of twisty include files again to
find out what an off_t is, the very presence of those shorts means that
the structure is not properly defined. Again from K&R, ...
" Each compiler is free to choose appropriate sizes for its own
hardware, subject only to the the restriction that shorts and ints are
at least 16 bits, longs are at least 32 bits, and short is no longer
than int, which is no longer than long. "
> And they all land on properly aligned word boundaries.
Do they? There's *nothing* in the spec that tells me how those shorts
will be aligned. st_nlink may or may not have sixteen bits of empty
space between it and st_uid. Come to think of it, I don't think the
order of the members in memory is even guaranteed! I can easily imagine
a compiler where short == 16 bits and long == 32 bits taking something
like this ...
struct sillyexample {
short foo;
long bar;
short baz;
};
and optimising it to this ...
bits 0 - 15: foo
bits 16 - 31: baz
bits 32 - 63: bar
instead of ...
bits 0 - 15: foo
bits 16 - 31: [wasted because longs should be aligned on four byte
boundaries]
bits 32 - 63: bar
bits 64 - 79: baz
[and perhaps some more wasted space here]
> Seriously, I don't see that this is particularly bothersome let
> alone hateful.
If you can Hate BeOS's API because it is defined in terms of C++
objects, I can Hate Unix just as much because it is defined in terms of
C structs.
There are very good reasons why things like the IP header definition in
RFC 791 is laid out in terms of exactly what bit goes where - it ensures
that software written to the standard will Just Work, regardless of
language or platform. The same can't be said of the fuzzy Unix API
docs, or anything else that assumes All The World's A C Compiler.
From: peter (Peter da Silva) Date: 17:00 on 25 Apr 2005 Subject: Re: MP3 players? Linux? I'm not sure, but I know there's hate > I got tired of hunting through a maze of twisty include files and C > pre-processor directives for the exact definitions on a Linux platform, This can be entirely automated with a script that does something like: > so just looked in K&R instead. Why would you expect a book describing the C language to tell you anything about UNIX system calls? That's an *example*. It's not even a current example. > Do they? There's *nothing* in the spec that tells me how those shorts > will be aligned. What spec? The only spec that matters is the documentation on what the particular hardware and operating system that you're using does. > If you can Hate BeOS's API because it is defined in terms of C++ > objects, I can Hate Unix just as much because it is defined in terms of > C structs. I can create a C struct easily without a C compiler. I can make a UNIX system call without having any C runtime libraries or even a working C compiler on the target system. I have done this, routinely, when I was working on Forth. I can't create a C++ method call easily without a C++ compiler. In fact, I don't just need a working C++ compiler, I need the same C++ compiler that Be uses. I need the same version of the C++ compiler, and for the same target architecture. Oh, technically I suppose I could manually decode the scrambled names and figure out how to populate the object, but it's much much harder. AND, UNIX has no more than a dozen system calls you really need to have down to get your language runtime up and working. BeOS has ... I don't know how many, but there's hundreds. For the GUI, on UNIX, you're in luck. X11 protocol is defined at the network level, so it's not an OS API it's > There are very good reasons why things like the IP header definition in > RFC 791 is laid out in terms of exactly what bit goes where - it ensures > that software written to the standard will Just Work, regardless of > language or platform. So basically you're demanding that there be a single ABI for system calls that is shared by all UNIX systems, whether they're AT&T-derived code or not? I think that's a bit much. An OS ABI is inherently hardware dependant. The difference between UNIX and BeOS here is like the difference between discovering you're out of gas a block from the gas station, and discovering that you're out of gas in the middle of the Sahara... and you don't have any local currency... and there's a war on...
From: Earle Martin Date: 12:55 on 24 Apr 2005 Subject: Mail clients Peter da Silva's mail client wrote: > To: hates-software@xxxxxx.xxxxxxxxx.xxx > Cc: hates-software@xxxxxx.xxxxxxxxx.xxx That is all.
From: peter (Peter da Silva) Date: 15:41 on 24 Apr 2005 Subject: Re: Mail clients > Peter da Silva's mail client wrote: > > To: hates-software@xxxxxx.xxxxxxxxx.xxx > > Cc: hates-software@xxxxxx.xxxxxxxxx.xxx Someone else's did. Mine writes "hate@xxxxxxxxxxxxxx.xxx".
From: Earle Martin Date: 00:28 on 03 May 2005 Subject: Re: Mail clients On Sun, Apr 24, 2005 at 09:41:28AM -0500, Peter da Silva wrote: > > Peter da Silva's mail client wrote: > > > To: hates-software@xxxxxx.xxxxxxxxx.xxx > > > Cc: hates-software@xxxxxx.xxxxxxxxx.xxx > > Someone else's did. Mine writes "hate@xxxxxxxxxxxxxx.xxx". Ah, yours was auto-replying to both addresses, or something. Apologies.
From: Aaron J. Grier Date: 20:08 on 27 Apr 2005 Subject: RTOS On Fri, Apr 22, 2005 at 01:47:31PM -0500, Peter da Silva wrote: > > > I'll just say that I can understand them reinventing the wheel, > > > but they should have actually looked at some of the *round* ones > > > available before deciding that a triangle made a better wheel than > > > a pentagon. > > > Examples? > > Just about any real-time operating system in existence. name some. I for one don't know where to get actual office applications for vxworks or QNX or ecos or ucosII or RTEMS or ... a RADAR from iZ corporation does a fantastic job for sound recording and playback, and as far as I know still runs BeOS under the covers, but it's not a general purpose machine. I hate that the vast majority of audio software is written for OSes that are not hard realtime. apparently it works well enough for most people, but then most people accept reboots and viruses and glitches and trouble with computers in general. it's just a minor background hate... physical analog equivalents have their own hates, but normally I don't have to worry about hating embedded software. "it could be magical gnomes on the inside, but you never know because you never have to open it up because it just works."
From: peter (Peter da Silva) Date: 01:58 on 28 Apr 2005 Subject: Re: RTOS > I for one don't know where to get actual office applications for vxworks > or QNX or ecos or ucosII or RTEMS or ... Yes, it's hateful that the only people who paid attention to realtime in their desktop OS got boned by a fued between two executives. AmigaOS didn't follow through with everything you'd need from a hard realtime OS, but at least it started out with a realtime Exec. And when it looked like the people who bought the wreckage were getting in bed with QNX on a consumer RTOS, I was *really* excited. But it turned out they couldn't actually pay for it, and QNX hadn't actually been told they were doing it on spec, and were only sporadically interested in doing it on their own. > it's just a minor background hate... Yeh, I've gotten used to it. Right now the only RTOS you can buy consumer software for is Kadak AMX, and Palm's license keeps them from providing a real native dev kit...
From: Daniel Pittman
Date: 01:01 on 22 Apr 2005
Subject: Re: MP3 players? Linux? I'm not sure, but I know there's hate
On 22 Apr 2005, Luke Kanies wrote:
[...]
> This just seems bloody stupid, but I'm not sure who's to blame. Me, for
> demanding too much? (Nope.) The mp3 players for sucking so much?
Why not? They all do.
> Metacity, for having such absolutely retarded mechanisms for setting
> hotkeys (2 years and it _still_ requires me to set the key and command
> separately, within GConf)?
Oh, but that is a *feature*, dontcha know? Users could be terribly
confused if you exposed complex ideas like configuration options to
them.
They will clearly be much less confused by using the Linux registry
editor to edit the Linux registry ... ahem. I mean the gconf editor to
edit the gconf registry ^W data store ...
Sorry. Hate. Obviously, it is much better to prevent people having all
these complex choices about how their software operates. Then they can
use it the way ghod, and you, intended. They have no choice.
Except that the developers still want the choice, so they hide it away
in undocumented features and commands. More code complexity for less
effect.
> Gnome, for not having a good, integrated mp3 player, or even better, a
> good mechanism for integrating any mp3 player, or any app?
In my limited[1] experience, KDE sucks a lot less.
KDE: we bring bloat a new name. we expose the hate of C++ under GCC.
we whack crippled QT interfaces over anything that comes near us. we do
stupid stuff by default. we reinvent the wheel, every day in every way.
To balance all that hate up, though, they fail to suck in fundamental
ways, just like GNOME doesn't any more. Nice idea, but it sucks more
and more as they try to make it "better".
> Linux, for not having an even lower-level good mechanism for
> integrating mp3 players, or any other apps? All OSes, because they
> basically all lack this feature?
That sounds like a good target to me.
Daniel
Footnotes:
[1] The hate builds up no matter what "desktop environment" I try to use.
From: Luke Kanies Date: 16:16 on 22 Apr 2005 Subject: Re: MP3 players? Linux? I'm not sure, but I know there's hate On Fri, 2005-04-22 at 10:01 +1000, Daniel Pittman wrote: > Oh, but that is a *feature*, dontcha know? Users could be terribly > confused if you exposed complex ideas like configuration options to > them. Yeah, that just astounds me; I don't care that the asanine Metacity author thinks features are evil(tm), but Gnome is stupid for using it as their main window manager. > They will clearly be much less confused by using the Linux registry > editor to edit the Linux registry ... ahem. I mean the gconf editor to > edit the gconf registry ^W data store ... > > Sorry. Hate. Obviously, it is much better to prevent people having all > these complex choices about how their software operates. Then they can > use it the way ghod, and you, intended. They have no choice. > > Except that the developers still want the choice, so they hide it away > in undocumented features and commands. More code complexity for less > effect. And yet again the OSS crowd fails to deliver a good workaround to someone else's stupidity. I still think the shareware model of software development works best for anything other than nasty-large apps. If this were a Mac (i.e., where there's a strong shareware community), that problem would already be solved. Hell, there are 20 hotkey solutions on Mac.s > In my limited[1] experience, KDE sucks a lot less. I basically agree, but stupid KDE thinks that two rows of workspaces is enough for anyone, and unless I have a 3x3 grid, I get hives and begin shaking uncontrollably. Such a small thing, but that's the reason I can't use KDE. Of course, there are some other insanities -- I've used some of the KApps, and while they do a good job of centralizing configuration info and such, and there's a lot of consistency (which is pretty damn rare on Linux), there was lots of pain, too. > > Linux, for not having an even lower-level good mechanism for > > integrating mp3 players, or any other apps? All OSes, because they > > basically all lack this feature? > > That sounds like a good target to me. "Don't worry, we'll hate the software you like, too." > Footnotes: > [1] The hate builds up no matter what "desktop environment" I try to use. Same here. I keep trying different window managers (Ion, for instance), but... Pick your hate, I guess.
From: Daniel Pittman
Date: 00:43 on 23 Apr 2005
Subject: Re: MP3 players? Linux? I'm not sure, but I know there's hate
On 23 Apr 2005, Luke Kanies wrote:
> On Fri, 2005-04-22 at 10:01 +1000, Daniel Pittman wrote:
>> Oh, but that is a *feature*, dontcha know? Users could be terribly
>> confused if you exposed complex ideas like configuration options to
>> them.
>
> Yeah, that just astounds me; I don't care that the asanine Metacity
> author thinks features are evil(tm), but Gnome is stupid for using it as
> their main window manager.
The ***** Metacity author was one of the leaders of the GNOME project
who decided that 1.4 had failed in the marketplace because it was too
complex.
The set of project leads as a whole made this call. Then they pissed
off anyone who thought different, drove them away to other places, and
proceeded to strip every useful application to the point that it sucked,
because it had bad defaults, and no sane way to change them.
Part of their reasoning was tolerable - a bunch of their core software
was bloated, slow, impossible to understand, and barely useful to
anyone.
This wasn't caused by an excess of options, though. It was caused by
stupid software written by stupid people that used twenty damn CPU
seconds on a P4-1700 to display a directory containing 50 files.
It didn't help that they felt the Microsoft thread-based love, and stuck
threads into everything they could. Mmmm, threads, full of complexity,
slower than non-threaded applications, and the best source of bugs this
side of PHP.
[...]
> Same here. I keep trying different window managers (Ion, for instance),
> but... Pick your hate, I guess.
*nod* All fscking UI sucks.
Daniel
Generated at 10:26 on 16 Apr 2008 by mariachi