We installed Jaguar (10.2) on my girlfriend's G3 (one of the fancy blue kinds), and it was certainly a LOT slower than OS9 had been, for doing things like resizing windows and general snapiness. The box has 256Mb of RAM, which isn't a lot, but one would hope it's enough to have snappy-feeling resizing of windows when there's no applications running.
There's other speed issues, too, which I believe are probably tied in to all the extra crap Apple makes to go through to, for instance, minimize a window, or pull up a dialog box. If OSX would just *do* what I want it to do, rather than animating everything possible, it might feel a lot faster. (We've turned off all of the animations you can turn off from the control panels; there may be "hidden" tweaks.)
Personally, I thought it was all right, but perhaps my experience running M[whatever] release Mozillas and KDE2, etc, has made me a bit more accepting. The actual applications ran all right, and having the command line was a dream. My GF absolutely loathed the speed, though. She refuses to have anything to do with it, and compared with OS9 for doing basic tasks, it's easy to see her point.
I'm not sure what kind of graphics card is in there (I've never much paid attention to Mac hardware until OSX came along, because I've thought that the OS was horrendous), so it might not be using their Quartz Extreme (or whatever) technology, which evidentally GL-accelerates all the window management, etc. That would certainly speed things up a bit. Also, I'm fairly sure it's one of the lower-end blue G3s, so a faster machine would probably do better with it.
I'm thinking more along the lines of learning from a text book v.s. learning from The Blithering Idiot's Guide to Database Design.
On a somewhat-related but quite off-topic note, is anyone else totally sick of "Idiot's Guide to This" and "Whatever for Morons" books? I'm not an idiot or a moron! I'm a reasonably intelligent person who just happens to have little experience in the field you're writing a book about! That's the kind of book I'd buy. The Reasonably Intelligent Person's Guide to Database Design.
I refuse to give money to companies that try and make me feel like an idiot.
And Bookpool has it for $29.95 and has the added benefit of having 95% less Evil than amazon. (That's a rough guess on the Evil count, btw, not a scientific measurement.)
Someone else in this thread recommended using arts. Ugh, don't . . . An AC suggested upgrading to the 6.0beta version of Flash; that'll fix the problem right up for you. In case you hadn't heard, the problem was entirely within the Flash plugin. The method they were using to open/dev/dsp forced it to block until it got exclusive access to your soundcard, which means that you'd have to actually STOP xmms or whatever was using your soundcard. It's a really, really, really simple fix, and the code for it was even posted in the Bugzilla bug (search around for it) and sent in to Macromedia, but obviously nobody at Macromedia got around to fixing the thing. Let's hear it for closed-source applications!
It was a really simple fix, too. All you had to do was add a flag to the open() commmand. Macromedia wasn't exactly ignoring the product, either. Since the bug was reported to them (with solution, remember), they've had two or three minor releases of that line of Flash plugin, and nobody there bothered to fix that one line of code. Highly frustrating. One of the more recent posts on the Bugzilla bug was from someone at Macromedia, though, apologizing for how long it's taken, and the 6.0beta does fix the problem.
Anyway, that's more than you probably ever wanted to know about the thing. The only way Mozilla itself could have fixed this was to make all plugins threaded, so if the thread hangs nobody cares, but that's a lot of work that nobody felt like doing. Oh, and people were originally thinking they could just do a binary-patch to the flash plugin, but evidentally the extra flag to open() increases the bytecount of the command by one, which makes doing so rather impossible . . .
Hm, I suppose when I hear "cross-platform" I think UNIX/Win/Mac/etc. Interoperability between various UNIX systems isn't nearly as impressive since they're already so interchangeable on a number of levels. Ah, well.
That would be somewhat nice, but I'd go a step further from "wouldn't be practical" and move into the "would be a complete nightmare" territory.:) Especially with header dependencies + the like to contend with. Plus you're still going to be downloading a sizeable chunk of tarball, and bzip2 isn't exactly processor-easy. It would be pretty nice to just be able to input a.config file and get your minimum kernel, though ...
Yeah, I think the ratios make that 20 minutes pretty negligible. I mean, you're still spending over two hours. I believe that the reason why they've never bothered to split arches out of the kernel tree was specifically because so much of it was platform-independant. I think Linus has mentioned that somewhere, but I don't feel like searching for the reference right now. Maybe on Kernel Notes?
At the company I used to work for, we started using Ant for the build system for a number of our projects, and it ended up working out really well. It'd do all the automatic downloading of files and dependencies, etc. We could use it to build up a development environment in no time at all (just install Java/Ant and then run one command to have everything automatically do cvs checkouts, compile, and all that good stuff). It also made installations a breeze - we cut back on our software install time by a phenomenal amount, because all we needed to do was run one or two commands.
Not that you couldn't do all that stuff in some other way, but it did work out really well for us. The XML-ish syntax was a little hokey, but we had defined so many targets for ourselves that it made life really easy.
The second kind of solution takes a more drastic route. This includes using XML, Python or another language for the build script. These all look very complicated, it is a puzzle to figure out what a build script is actually doing.
Sounds to me like he was dissatisfied with ant. Though I don't know what the Python reference is doing in there. So maybe he was extremely confused about Ant. "Python can't run this. Huh.":P
I don't think trimming off architectures alone would save that much. The 2.4.19 tbz2 is about 25MB. I untarred it, stripped out all arches !i386, retarred, and the resulting tarball was still about 21MB. Not that big of a difference; you're still downloading 21 megs. What's the extra four, really?
pez@arrakis:~/tmp/kernel$ ls -l
total 46628
drwxr-sr-x 2 pez pez 4096 Oct 30 11:40./
drwxr-sr-x 10 pez pez 4096 Oct 30 11:29../
-rw-r--r-- 1 pez pez 21630684 Oct 30 11:35 linux-2.4.19-i386.tar.bz2
-rw-r--r-- 1 pez pez 26042494 Oct 30 11:40 linux-2.4.19.tar.bz2
Spoken like somebody who never had to deal with Netscape Communicator 4.x in Linux four or five years ago.:)
Good fonts are a good thing whether you like eyecandy or not. Obviously this is less of a problem when you're just sitting at an 80x25 console all the time, but eye strain can be a serious problem.
I was under the impression that the goal of the Wine project was to not only implement all of Windows' API, it would also implement the APIs such that any bugs which would occur in Windows would also occur in Wine. To make the environment as nearly identical as possible. I could be wrong, though . . .
Yeah, let's all get pissed off about an alpha version of a new feature of a KDE release that won't happen until next year because the X extension hasn't even been bundled into a release yet. We all know that as soon as something is checked into CVS it never changes, that's the great thing about CVS. Now, let's all write furious posts about it. Fuckin' KDE.
Ah, but then you've gotta take into account the size of the shell running your one-character shell script. On my system,/bin/bash (/bin/sh is typically just a symlink to bash nowadays) is 588340 characters. Plus your shell script is, in turn, executing/usr/bin/w, which in turn on my system is 8932 characters.
You might say, "that's not fair, it gets run, doesn't it?" Well then try running it pedantically:
Try again. Check the contents of/usr/lib/win32. Xine and Mplayer, etc, use Windows DLLs for many of the Codecs they can understand. They're not directly equivalent to the DLLs actually found on your windows machine (you can't copy them over to your Windows box and have it understand that video format), but they are DLLs. Yours are evidentally out of date. (Or, I suppose, Xine and MPlayer might be out of date, too...)
Well, then there you have it. Xine's probably looking for the same (invalid) dll. I just tried on my machine and Xine plays 'em just fine, Xine and all. Peronally, I'd go and reinstall the Win32 codecs you're using, but I'll defer to xine or mplayer lists for that. Good luck!
There's a problem w/ your computer, then, 'cause the sound plays fine over in my neck o' the woods.:) Of course, I was using mplayer, not xine, so I suppose maybe they're in some strange format that xine can't cope with...
Oh, man, I always knew that you could run xscreensavers in the background like that, but never bothered to try it out. Too much fun. Also, you don't need Fluxbox to do that; I'm using Icewm and it's fine, I suspect it'll even work in gnome/kde. After all, it's just drawing graphics on your root window.
Personally, though, I would suggest ifs or fluidballs. Wonderful! For added fun, try setting up a cron job on someone else's box to start up decayscreen after awhile. *snicker* What fun!
Oh, and the xscreensavers might be/usr/[local/]lib/xscreensaver instead, depending on your setup...
Slashdot Mirror
There's other speed issues, too, which I believe are probably tied in to all the extra crap Apple makes to go through to, for instance, minimize a window, or pull up a dialog box. If OSX would just *do* what I want it to do, rather than animating everything possible, it might feel a lot faster. (We've turned off all of the animations you can turn off from the control panels; there may be "hidden" tweaks.)
Personally, I thought it was all right, but perhaps my experience running M[whatever] release Mozillas and KDE2, etc, has made me a bit more accepting. The actual applications ran all right, and having the command line was a dream. My GF absolutely loathed the speed, though. She refuses to have anything to do with it, and compared with OS9 for doing basic tasks, it's easy to see her point.
I'm not sure what kind of graphics card is in there (I've never much paid attention to Mac hardware until OSX came along, because I've thought that the OS was horrendous), so it might not be using their Quartz Extreme (or whatever) technology, which evidentally GL-accelerates all the window management, etc. That would certainly speed things up a bit. Also, I'm fairly sure it's one of the lower-end blue G3s, so a faster machine would probably do better with it.
Or, possibly, some of the true "SlashDot geeks" are staying the hell away from their TV and, oh, I don't know, coding?
I refuse to give money to companies that try and make me feel like an idiot.
It was a really simple fix, too. All you had to do was add a flag to the open() commmand. Macromedia wasn't exactly ignoring the product, either. Since the bug was reported to them (with solution, remember), they've had two or three minor releases of that line of Flash plugin, and nobody there bothered to fix that one line of code. Highly frustrating. One of the more recent posts on the Bugzilla bug was from someone at Macromedia, though, apologizing for how long it's taken, and the 6.0beta does fix the problem.
Anyway, that's more than you probably ever wanted to know about the thing. The only way Mozilla itself could have fixed this was to make all plugins threaded, so if the thread hangs nobody cares, but that's a lot of work that nobody felt like doing. Oh, and people were originally thinking they could just do a binary-patch to the flash plugin, but evidentally the extra flag to open() increases the bytecount of the command by one, which makes doing so rather impossible . . .
I don't know about you, but I've been moving on with my life for some time now. Have you been stuck somehow? :P
Hm, I suppose when I hear "cross-platform" I think UNIX/Win/Mac/etc. Interoperability between various UNIX systems isn't nearly as impressive since they're already so interchangeable on a number of levels. Ah, well.
That would be somewhat nice, but I'd go a step further from "wouldn't be practical" and move into the "would be a complete nightmare" territory. :) Especially with header dependencies + the like to contend with. Plus you're still going to be downloading a sizeable chunk of tarball, and bzip2 isn't exactly processor-easy. It would be pretty nice to just be able to input a .config file and get your minimum kernel, though . ..
Yeah, I think the ratios make that 20 minutes pretty negligible. I mean, you're still spending over two hours. I believe that the reason why they've never bothered to split arches out of the kernel tree was specifically because so much of it was platform-independant. I think Linus has mentioned that somewhere, but I don't feel like searching for the reference right now. Maybe on Kernel Notes?
Not that you couldn't do all that stuff in some other way, but it did work out really well for us. The XML-ish syntax was a little hokey, but we had defined so many targets for ourselves that it made life really easy.
Good fonts are a good thing whether you like eyecandy or not. Obviously this is less of a problem when you're just sitting at an 80x25 console all the time, but eye strain can be a serious problem.
Perhaps they were using something called "sarcasm?"
I don't know... I kind of dig the image of a "bat in a cage." I get the image of this content little fruit bat munching on a nectarine or something. :P
I was under the impression that the goal of the Wine project was to not only implement all of Windows' API, it would also implement the APIs such that any bugs which would occur in Windows would also occur in Wine. To make the environment as nearly identical as possible. I could be wrong, though . . .
Yeah, let's all get pissed off about an alpha version of a new feature of a KDE release that won't happen until next year because the X extension hasn't even been bundled into a release yet. We all know that as soon as something is checked into CVS it never changes, that's the great thing about CVS. Now, let's all write furious posts about it. Fuckin' KDE.
You might say, "that's not fair, it gets run, doesn't it?" Well then try running it pedantically:
Doesn't work so well anymore, does it?Try again. Check the contents of /usr/lib/win32. Xine and Mplayer, etc, use Windows DLLs for many of the Codecs they can understand. They're not directly equivalent to the DLLs actually found on your windows machine (you can't copy them over to your Windows box and have it understand that video format), but they are DLLs. Yours are evidentally out of date. (Or, I suppose, Xine and MPlayer might be out of date, too...)
Well, then there you have it. Xine's probably looking for the same (invalid) dll. I just tried on my machine and Xine plays 'em just fine, Xine and all. Peronally, I'd go and reinstall the Win32 codecs you're using, but I'll defer to xine or mplayer lists for that. Good luck!
There's a problem w/ your computer, then, 'cause the sound plays fine over in my neck o' the woods. :) Of course, I was using mplayer, not xine, so I suppose maybe they're in some strange format that xine can't cope with...
Personally, though, I would suggest ifs or fluidballs. Wonderful! For added fun, try setting up a cron job on someone else's box to start up decayscreen after awhile. *snicker* What fun!
Oh, and the xscreensavers might be /usr/[local/]lib/xscreensaver instead, depending on your setup...