NT4 installed in about 10 minutes and flies in VMware, while the Win98 install is taking *forever* (60 minutes!). My guess is that the emulator, like the Pentium Pro, is far better at running 32-bit code than 16-bit...
I tried BeOS R4.0 (I have a 4.1 beta at home that I haven't tried yet, but don't expect any different results). The floppy boots up to "Examining disks..." then displays the empty "Rescan for boot volumes" screen. No matter how many times I choose "rescan", it never finds the Be CD-ROM. If I hold down F1 while booting and check the BeOS debugging that comes out of COM1 (which VMWare conveniently lets me redirect to a file), I see:
cam_load_modules... cam: attempting to load 'busses/scsi/buslogic/v1' (internal) buslogic: sim_install() buslogic: no controller found cam: module 'busses/scsi/buslogic/v1' cannot be loaded cam: attempting to load 'busses/scsi/aic78xx/v1' (internal) adaptec: sim_install() adaptec: no controller found cam: module 'busses/scsi/aic78xx/v1' cannot be loaded cam: attempting to load 'busses/scsi/53c8xx/v1' (internal) symbios: sim_install() symbios: no controller found cam: module 'busses/scsi/53c8xx/v1' cannot be loaded Creating startup devices... flo_init: problem creating cylinder buffer area IDE PCI -- find_devices: intel 82371AB (PIIX4) chipset IDE PCI -- find_devices: controller supports DMA IDE PCI -- create_prd_table_area: couldn't create dma table area IDE PCI -- find_devices: disabled dma IDE PCI -- create_prd_table_area: couldn't create dma table area IDE PCI -- find_devices: disabled dma IDE -- send_ata: drive select failed no device IDE -- send_ata: drive select failed no device IDE PCI -- find_devices: intel 82371AB (PIIX4) chipset IDE PCI -- find_devices: controller supports DMA IDE PCI -- create_prd_table_area: couldn't create dma table area IDE PCI -- find_devices: disabled dma IDE PCI -- create_prd_table_area: couldn't create dma table area IDE PCI -- find_devices: disabled dma IDE -- send_ata: drive select failed no device IDE -- send_ata: drive select failed no device cam: B_MODULE_INIT ---> publish_devices_dsk has no devices
and the VMWare log file says:
Mar 15 16:26:22: Booting Virtual Machine Mar 15 16:26:22: Mar 15 16:27:03: VIDE: (0x1F0) OUTB Cmd 0xA1, Erroring Invalid ATA on drive 0 Mar 15 16:27:38: DISK: ROOT COWDisk/vmware/BeOS/BeOS.dsk (433/15/63) Mar 15 16:27:41: MainPowerOff-- Shutting down devices
I'll send this info to VMWare and see what they have to say. If anyone at Be sees this message and would like to comment, that would be cool too. I *will* buy this program if it supports BeOS. Being able to keep up with the latest BeOS happenings without having to leave the comfort of Linux is well worth $300 to me. Of course, even without BeOS support, I may still buy VMWare, it's just that cool!
Ah, but there's one flaw in your argument. The main reason most people didn't complain when "gay" morphed to mean "homosexual" is that we already had plenty of other words in the English language that mean "happy", so it wasn't a big loss.
Unfortunately, as others have posted, there's no convenient replacement word for "hacker", so if we let it take on bad connotations, we'll have to find another term to describe ourselves. "Expert computer programmer" is just too long. "ECP" maybe?:)
Umm, if you release too much EMF into space, your enemy *could* detect you. Electromagnetic energy, unlike sound, travels through a vacuum. So "running silent" (metaphorically speaking) makes perfect sense from a physics standpoint.
From what I've heard from Ellison and McNealy, they would've done exactly the same things if they only knew how. If Sun had succeeded in their vision of Java Everywhere (forgive me, "Write Once Run Anywhere"), they would've been no different from Microsoft's vision of Windows Everywhere, and we would have just substituted one tyrant for another.
I have more respect for Andreessen because he actually wrote code. I don't think Ellison is even sure what his company *does*, much less have any deeper technical insight than the average PHB-who-wants-to-be-a-samurai.
Reminds me of the type of economy that exists with the cigarette makers (I wish my friend who told me about this had remembered what it's called): Many vendors competing, not on price or features, but mostly on "imaginary differences in quality."
Of course I won't say the differences between, say, Redhat and Debian, are imaginary, like say the difference between Marlboro and Camel (if that were the case, I wouldn't have recently switched from RedHat to Debian on both of my boxes), but from the average corporation (or even software developer) point of view, all of your software should work on any distro anyway, so they might as well be imaginary differences.
Don't worry if RedHat becomes the preferred distro of PHB's, you'll always be free to choose what works for you.
Others have already commented on the fallacy of your argument (that Windows is in fact fragmented, and IT managers have to constantly worry about mass upgrade migrations of their desktops to the next latest thing).
While UNIX is already useful in making "vendor lockin" much more difficult, keep in mind that free UNIX's like Linux and FreeBSD have a further benefit: Open Source. There's nothing stopping you from keeping all of your systems running Linux 2.0 kernel, or even Linux 1.2 if you're happy with it. Even if you want to upgrade 1000 desktop machines to Linux 2.2, or the latest version of your favorite distribution, the changes are likely to be so small that all of your old apps should still work, with so few exceptions that I can count them on one hand (RealPlayer breaks with Kernel 2.2 because of a bug in RealPlayer, and some apps which use private glibc symbols will break with GLIBC 2.1). If you find any bugs, you're free to fix them yourself in-house, or pay any programmer to fix them for you. You can use RedHat, or Debian, or even Slackware, because even if the original maintainer of the distribution stops supporting it, almost certainly you'll find other volunteers taking up the crusade to maintain it.
This point was driven home to me on the Squeak web page. They say, "What will happen if the Squeak developers stop working on it?" The answer was, "You have the source code, you can support it yourself even if we stopped supporting it." I thought this was very sensible.
A bit like the Unix mode: 1/ Berkeley student gets a bright idea, 2/ Berkeley writes half-baked code and paper, 3/ POSIX casts the API in stone any any mistakes... ?
No, it's more like:
1/ Berkeley student gets a bright idea, 2/ Berkeley writes half-baked code and paper, 3/ AT&T writes gratuitously incompatible but slightly more full-featured implementation, 4/ POSIX standardizes on a third API based on both AT&T and Berkeley, but gratuitously incompatible with either.
For example, Berkeley sgtty turns into SYSV termio, which turns into POSIX termios. Or Berkeley termcap turns into SYSV termlib, which turns into SYSV curses (with a broken BSD implementation followed later by a proper free version, ncurses).
I remember hearing about this game back in late '97 and how it was going to be available for BeOS, Windows, and OS/2. I even signed on to their beta list, but never received any email. Looks like Be loses yet again to the Linux juggernaut, despite the fact that it'd probably be easier to port the game to BeOS, with its nice DirectWindow and sound API's, than to X and/dev/dsp.
It's just as well, since I use Linux more than BeOS anyway. I'll definitely have to download this and check it out.
Actually, you're wrong. Even if you *do* pick a language which supports subclassing (such as Python), you still can't extend your C++ application if you've used SWIG wrappers.
In order for SWIG to handle this case, it would need to create a C++ subclass which overrode *all* of the virtual functions and then checked every time one was called to see if your script had overridden it. It would certainly be possible to add this support to SWIG, but it's going to involve some significant run-time performance penalties, and AFAIK, nobody has done it yet.
Too bad, because it would be nice if one could use SWIG to extend something like BeOS (or KDE) to let you write full-fledged GUI apps using SWIG bindings. I looked into that back in late '97, but due to the subclassing problem, gave up on it.
I'm not exactly sure why, but there's just something amusing about crack. I guess it's because it's just so terrible that if you ever try it, you probably deserve what's coming to you. As a result, it's difficult to think of a more whack habit for someone to have, and therefore "crackhead" becomes perhaps the least offensive of the "offensive epithets" to hurl at someone.
Or maybe it's because, if it weren't for the U.S. War On Drugs that hasn't benefitted anyone except the DEA and law enforcement (thanks to the wonderful world of "asset forfeiture"), not to mention the companies that make the black helicopters that we send to Latin America, the U.S. wouldn't have a problem with crack today. The absurdity of a world where something like crack not only exists, but flourishes (in the inner cities at least), bespeaks of an absurdity one usually only sees in Camus novels, not in real life.
So chill out, take a virtual toke, and try not to get all hot and bothered when someone exercises their First Amendment rights in a relatively harmless (and humorous) way.
Great summary! This week, prodded by the latest/. survey results, I installed Debian for the first time (2.1 prerelease) and I'm very impressed. As someone else pointed out, the hardware detection is non-existent, unlike RH, so you have to know what's going on in order to configure your network and soundcard. Without much better hardware detection, Debian will definitely remain "too techie and hard to install." Fortunately, they appear to have the right infrastructure (dpackage, etc.) to add better hardware detection in the future, it's just that nobody's written it yet.
Also, there are a lot of bugs, but because there's so much more functionality than RH, and so many more people working on fixing the bugs, I feel like pitching in to help fix the bugs myself, rather than complaining. As soon as I become a little more familiar with the system, and learn how to make packages, I'm definitely going to sign up as a maintainer. I'm pretty good at writing documentation, so maybe I can start with that, as well as fixing the few installation bugs I noticed with slink.
One other nice thing is that the bleeding edge (unstable branch) is much easier to download than the RH equivalent (Rawhide), which AFAIK is only available for FTP from rawhide.redhat.com, which is completely overloaded all the time.
Finally, regarding the new GLIBC 2.1, I have much more confidence that Debian will survive that transition relatively unscathed (in particular, Debian uses a library naming scheme which will allow C++ programs linked with GLIBC 2.0 to coexist with those linked with GLIBC 2.1). My experience with Rawhide on this matter has not been very pleasant, and if you've installed EGCS 1.1.x on Redhat, you'll probably find all of your C++ binaries break when RedHat 6 comes out (in a nutshell, Redhat uses libstdc++.so.2.9.0 for both the GLIBC 2.0 and 2.1 version of libstdc++, which are incompatible with each other). Bad luck for people who compiled KDE or other C++ apps themselves using EGCS 1.1.1 (luckily, the KDE binary RPMs are built with an older version of EGCS which uses libstdc++.so.2.8.0, and so won't conflict with the new libstdc++ for GLIBC 2.1).
Maybe it's because RedHat 5.2 uses Linux 2.0.36, which ships with SMP disabled. Sure, you could (gasp!) recompile your own kernel (preferably 2.2, which has *far* superior SMP support), but RH is probably playing it safe and waiting until they release RH6 (which should use Linux 2.2) to start certifying SMP systems. At any rate, it's tough to "certify" a system where your OS, out of the box, doesn't even acknowledge the existence of the second CPU.
Another question is if RedHat will start making two different kernel RPMs (one with SMP, one without), or just compile the default with SMP enabled for their next release, since an SMP kernel shouldn't be a big performance hit to those without SMP machines.
The FULL cost of windows should be returned. Its like taking something that is defective back to the store, and the store telling you that you'll get half your money back.
Ever hear of "15% restocking fee"? Some stores (like Circuit City) try to pull that on you when you return stuff, even within 30 days, and even if it's obviously defective (like Packard Bell computers). Not that I'd be foolish enough to buy a Packard Bell computer from Circuit City, but my sister's roommate did, and they pulled that on her when she asked for a refund, even though it had some serious hardware problems.
Don't forget that cassettes, as with all analog recording devices, have the problem of generational decay, i.e. a copy of a copy of a copy doesn't sound anywhere near as good as the original. This works to the RIAA's advantage, because pirated tapes can only spread for a couple of generations before the quality degrades too much to be listenable. Either way, the quality is going to be worse than the CD, so if you get a bootleg cassette, and you like the music, you'll probably want to buy the original to get the best quality.
Naturally, this limitation doesn't apply to digital media, because the n'th generation copy is bit-for-bit identical with the original. This is why the RIAA was so scared of DAT when it came out (and through legal wrangling managed to essential kill the format), and later MiniDisc and now MP3. The only difference is that, because MP3 is open, they can't extort any money from the makers as they seem to have done with MD.
A quick amazon.com search would have revealed the title:
Practical File System Design with the Be File System
by Dominic Giampaolo
From this book, you could literally write your own compatible implementation of BFS for Linux. The question is: would BeOS compatibility be worth missing the opportunity to create a new filesystem tuned for what Linux is used for? The nice thing about dbg's book is that he covers the reasoning behind every decision that he made when developing BFS. Clearly, some of these decisions are closely tied to what BeOS is being targeted for (a single-user power desktop for media professionals), rather than what Linux is most often used for (a multi-user Internet server).
My god, how long does it take to fsck such a beast? Unfortunately, I haven't looked into the journalled filesystem that's supposedly available for Linux (I think it's commercial), but a journalled filesystem is exactly what you'll need for this. Even with a UPS, hour-long fsck times are not my cup of tea.
The original Mac used a 68000 processor, which lacks an MMU (Memory Management Unit), without which it's *impossible* to have hardware memory protection. In order to run a "real" memory protected OS, such as Linux, on a 68k Mac (or Amiga or Atari), you need at least a 68020 + external MMU chip.
In a similar vein, in the Intel world, you need at least an 80386 to have a "real" OS, because earlier x86's didn't have an MMU either.
Looking at other OS's from the 80's, the Amiga didn't have memory protection either, but it did at least have preemptive multitasking. Windows 3.1 had neither, but OS/2 had both. The question is not why MacOS didn't have memory protection in 1984 (it wouldn't have run on an original Mac if it did!), but why they never added memory protection, even when they had the perfect opportunity with the 68k->PowerPC transition.
Slashdot Mirror
-Jake
NT4 installed in about 10 minutes and flies in VMware, while the Win98 install is taking *forever* (60 minutes!). My guess is that the emulator, like the Pentium Pro, is far better at running 32-bit code than 16-bit...
-Jake
Hmm, you probably won't be able to run Cakewalk considering it doesn't support MIDI yet.
-Jake
I tried BeOS R4.0 (I have a 4.1 beta at home that I haven't tried yet, but don't expect any different results). The floppy boots up to "Examining disks..." then displays the empty "Rescan for boot volumes" screen. No matter how many times I choose "rescan", it never finds the Be CD-ROM. If I hold down F1 while booting and check the BeOS debugging that comes out of COM1 (which VMWare conveniently lets me redirect to a file), I see:
/vmware/BeOS/BeOS.dsk (433/15/63)
cam_load_modules...
cam: attempting to load 'busses/scsi/buslogic/v1' (internal)
buslogic: sim_install()
buslogic: no controller found
cam: module 'busses/scsi/buslogic/v1' cannot be loaded
cam: attempting to load 'busses/scsi/aic78xx/v1' (internal)
adaptec: sim_install()
adaptec: no controller found
cam: module 'busses/scsi/aic78xx/v1' cannot be loaded
cam: attempting to load 'busses/scsi/53c8xx/v1' (internal)
symbios: sim_install()
symbios: no controller found
cam: module 'busses/scsi/53c8xx/v1' cannot be loaded
Creating startup devices...
flo_init: problem creating cylinder buffer area
IDE PCI -- find_devices: intel 82371AB (PIIX4) chipset
IDE PCI -- find_devices: controller supports DMA
IDE PCI -- create_prd_table_area: couldn't create dma table area
IDE PCI -- find_devices: disabled dma
IDE PCI -- create_prd_table_area: couldn't create dma table area
IDE PCI -- find_devices: disabled dma
IDE -- send_ata: drive select failed no device
IDE -- send_ata: drive select failed no device
IDE PCI -- find_devices: intel 82371AB (PIIX4) chipset
IDE PCI -- find_devices: controller supports DMA
IDE PCI -- create_prd_table_area: couldn't create dma table area
IDE PCI -- find_devices: disabled dma
IDE PCI -- create_prd_table_area: couldn't create dma table area
IDE PCI -- find_devices: disabled dma
IDE -- send_ata: drive select failed no device
IDE -- send_ata: drive select failed no device
cam: B_MODULE_INIT
---> publish_devices_dsk has no devices
and the VMWare log file says:
Mar 15 16:26:22: Booting Virtual Machine
Mar 15 16:26:22:
Mar 15 16:27:03: VIDE: (0x1F0) OUTB Cmd 0xA1, Erroring Invalid ATA on drive 0
Mar 15 16:27:38: DISK: ROOT COWDisk
Mar 15 16:27:41:
MainPowerOff-- Shutting down devices
I'll send this info to VMWare and see what they have to say. If anyone at Be sees this message and would like to comment, that would be cool too. I *will* buy this program if it supports BeOS. Being able to keep up with the latest BeOS happenings without having to leave the comfort of Linux is well worth $300 to me. Of course, even without BeOS support, I may still buy VMWare, it's just that cool!
-Jake
Ah, but there's one flaw in your argument. The main reason most people didn't complain when "gay" morphed to mean "homosexual" is that we already had plenty of other words in the English language that mean "happy", so it wasn't a big loss.
:)
Unfortunately, as others have posted, there's no convenient replacement word for "hacker", so if we let it take on bad connotations, we'll have to find another term to describe ourselves. "Expert computer programmer" is just too long. "ECP" maybe?
-Jake
Umm, if you release too much EMF into space, your enemy *could* detect you. Electromagnetic energy, unlike sound, travels through a vacuum. So "running silent" (metaphorically speaking) makes perfect sense from a physics standpoint.
-Jake
Yeah, wasn't that a French Canadian accent the Commodore had?
-Jake
Holographic lighting systems? You mean like Bill Gates' house?
-Jake
I've got only one thing to say to that: no co-ed shower scene! Now *that* made Starship Troopers a great movie. :)
-Jake
From what I've heard from Ellison and McNealy, they would've done exactly the same things if they only knew how. If Sun had succeeded in their vision of Java Everywhere (forgive me, "Write Once Run Anywhere"), they would've been no different from Microsoft's vision of Windows Everywhere, and we would have just substituted one tyrant for another.
I have more respect for Andreessen because he actually wrote code. I don't think Ellison is even sure what his company *does*, much less have any deeper technical insight than the average PHB-who-wants-to-be-a-samurai.
-Jake
Reminds me of the type of economy that exists with the cigarette makers (I wish my friend who told me about this had remembered what it's called): Many vendors competing, not on price or features, but mostly on "imaginary differences in quality."
Of course I won't say the differences between, say, Redhat and Debian, are imaginary, like say the difference between Marlboro and Camel (if that were the case, I wouldn't have recently switched from RedHat to Debian on both of my boxes), but from the average corporation (or even software developer) point of view, all of your software should work on any distro anyway, so they might as well be imaginary differences.
Don't worry if RedHat becomes the preferred distro of PHB's, you'll always be free to choose what works for you.
-Jake
Others have already commented on the fallacy of your argument (that Windows is in fact fragmented, and IT managers have to constantly worry about mass upgrade migrations of their desktops to the next latest thing).
While UNIX is already useful in making "vendor lockin" much more difficult, keep in mind that free UNIX's like Linux and FreeBSD have a further benefit: Open Source. There's nothing stopping you from keeping all of your systems running Linux 2.0 kernel, or even Linux 1.2 if you're happy with it. Even if you want to upgrade 1000 desktop machines to Linux 2.2, or the latest version of your favorite distribution, the changes are likely to be so small that all of your old apps should still work, with so few exceptions that I can count them on one hand (RealPlayer breaks with Kernel 2.2 because of a bug in RealPlayer, and some apps which use private glibc symbols will break with GLIBC 2.1). If you find any bugs, you're free to fix them yourself in-house, or pay any programmer to fix them for you. You can use RedHat, or Debian, or even Slackware, because even if the original maintainer of the distribution stops supporting it, almost certainly you'll find other volunteers taking up the crusade to maintain it.
This point was driven home to me on the Squeak web page. They say, "What will happen if the Squeak developers stop working on it?" The answer was, "You have the source code, you can support it yourself even if we stopped supporting it." I thought this was very sensible.
-Jake
No, it's more like:
1/ Berkeley student gets a bright idea, 2/ Berkeley writes half-baked code and paper, 3/ AT&T writes gratuitously incompatible but slightly more full-featured implementation, 4/ POSIX standardizes on a third API based on both AT&T and Berkeley, but gratuitously incompatible with either.
For example, Berkeley sgtty turns into SYSV termio, which turns into POSIX termios. Or Berkeley termcap turns into SYSV termlib, which turns into SYSV curses (with a broken BSD implementation followed later by a proper free version, ncurses).
-Jake
Minor correction: every *window* gets its own thread (for the event loop), but not every GUI widget.
-Jake
I remember hearing about this game back in late '97 and how it was going to be available for BeOS, Windows, and OS/2. I even signed on to their beta list, but never received any email. Looks like Be loses yet again to the Linux juggernaut, despite the fact that it'd probably be easier to port the game to BeOS, with its nice DirectWindow and sound API's, than to X and /dev/dsp.
It's just as well, since I use Linux more than BeOS anyway. I'll definitely have to download this and check it out.
-Jake
Actually, you're wrong. Even if you *do* pick a language which supports subclassing (such as Python), you still can't extend your C++ application if you've used SWIG wrappers.
In order for SWIG to handle this case, it would need to create a C++ subclass which overrode *all* of the virtual functions and then checked every time one was called to see if your script had overridden it. It would certainly be possible to add this support to SWIG, but it's going to involve some significant run-time performance penalties, and AFAIK, nobody has done it yet.
Too bad, because it would be nice if one could use SWIG to extend something like BeOS (or KDE) to let you write full-fledged GUI apps using SWIG bindings. I looked into that back in late '97, but due to the subclassing problem, gave up on it.
-Jake
I'm guessing it'll run on x86's too, but the new QNX kernel (Neutrino) is fully cross-platform, so technically, Amiga doesn't *have* to go Intel.
-jake
Or maybe it's because, if it weren't for the U.S. War On Drugs that hasn't benefitted anyone except the DEA and law enforcement (thanks to the wonderful world of "asset forfeiture"), not to mention the companies that make the black helicopters that we send to Latin America, the U.S. wouldn't have a problem with crack today. The absurdity of a world where something like crack not only exists, but flourishes (in the inner cities at least), bespeaks of an absurdity one usually only sees in Camus novels, not in real life.
So chill out, take a virtual toke, and try not to get all hot and bothered when someone exercises their First Amendment rights in a relatively harmless (and humorous) way.
-Jake
Great summary! This week, prodded by the latest /. survey results, I installed Debian for the first time (2.1 prerelease) and I'm very impressed. As someone else pointed out, the hardware detection is non-existent, unlike RH, so you have to know what's going on in order to configure your network and soundcard. Without much better hardware detection, Debian will definitely remain "too techie and hard to install." Fortunately, they appear to have the right infrastructure (dpackage, etc.) to add better hardware detection in the future, it's just that nobody's written it yet.
Also, there are a lot of bugs, but because there's so much more functionality than RH, and so many more people working on fixing the bugs, I feel like pitching in to help fix the bugs myself, rather than complaining. As soon as I become a little more familiar with the system, and learn how to make packages, I'm definitely going to sign up as a maintainer. I'm pretty good at writing documentation, so maybe I can start with that, as well as fixing the few installation bugs I noticed with slink.
One other nice thing is that the bleeding edge (unstable branch) is much easier to download than the RH equivalent (Rawhide), which AFAIK is only available for FTP from rawhide.redhat.com, which is completely overloaded all the time.
Finally, regarding the new GLIBC 2.1, I have much more confidence that Debian will survive that transition relatively unscathed (in particular, Debian uses a library naming scheme which will allow C++ programs linked with GLIBC 2.0 to coexist with those linked with GLIBC 2.1). My experience with Rawhide on this matter has not been very pleasant, and if you've installed EGCS 1.1.x on Redhat, you'll probably find all of your C++ binaries break when RedHat 6 comes out (in a nutshell, Redhat uses libstdc++.so.2.9.0 for both the GLIBC 2.0 and 2.1 version of libstdc++, which are incompatible with each other). Bad luck for people who compiled KDE or other C++ apps themselves using EGCS 1.1.1 (luckily, the KDE binary RPMs are built with an older version of EGCS which uses libstdc++.so.2.8.0, and so won't conflict with the new libstdc++ for GLIBC 2.1).
-Jake
Maybe it's because RedHat 5.2 uses Linux 2.0.36, which ships with SMP disabled. Sure, you could (gasp!) recompile your own kernel (preferably 2.2, which has *far* superior SMP support), but RH is probably playing it safe and waiting until they release RH6 (which should use Linux 2.2) to start certifying SMP systems. At any rate, it's tough to "certify" a system where your OS, out of the box, doesn't even acknowledge the existence of the second CPU.
Another question is if RedHat will start making two different kernel RPMs (one with SMP, one without), or just compile the default with SMP enabled for their next release, since an SMP kernel shouldn't be a big performance hit to those without SMP machines.
-Jake
Ever hear of "15% restocking fee"? Some stores (like Circuit City) try to pull that on you when you return stuff, even within 30 days, and even if it's obviously defective (like Packard Bell computers). Not that I'd be foolish enough to buy a Packard Bell computer from Circuit City, but my sister's roommate did, and they pulled that on her when she asked for a refund, even though it had some serious hardware problems.
-Jake
Don't forget that cassettes, as with all analog recording devices, have the problem of generational decay, i.e. a copy of a copy of a copy doesn't sound anywhere near as good as the original. This works to the RIAA's advantage, because pirated tapes can only spread for a couple of generations before the quality degrades too much to be listenable. Either way, the quality is going to be worse than the CD, so if you get a bootleg cassette, and you like the music, you'll probably want to buy the original to get the best quality.
Naturally, this limitation doesn't apply to digital media, because the n'th generation copy is bit-for-bit identical with the original. This is why the RIAA was so scared of DAT when it came out (and through legal wrangling managed to essential kill the format), and later MiniDisc and now MP3. The only difference is that, because MP3 is open, they can't extort any money from the makers as they seem to have done with MD.
-Jake
A quick amazon.com search would have revealed the title:
Practical File System Design with the Be File System
by Dominic Giampaolo
From this book, you could literally write your own compatible implementation of BFS for Linux. The question is: would BeOS compatibility be worth missing the opportunity to create a new filesystem tuned for what Linux is used for? The nice thing about dbg's book is that he covers the reasoning behind every decision that he made when developing BFS. Clearly, some of these decisions are closely tied to what BeOS is being targeted for (a single-user power desktop for media professionals), rather than what Linux is most often used for (a multi-user Internet server).
-Jake
My god, how long does it take to fsck such a beast? Unfortunately, I haven't looked into the journalled filesystem that's supposedly available for Linux (I think it's commercial), but a journalled filesystem is exactly what you'll need for this. Even with a UPS, hour-long fsck times are not my cup of tea.
-Jake
The original Mac used a 68000 processor, which lacks an MMU (Memory Management Unit), without which it's *impossible* to have hardware memory protection. In order to run a "real" memory protected OS, such as Linux, on a 68k Mac (or Amiga or Atari), you need at least a 68020 + external MMU chip.
In a similar vein, in the Intel world, you need at least an 80386 to have a "real" OS, because earlier x86's didn't have an MMU either.
Looking at other OS's from the 80's, the Amiga didn't have memory protection either, but it did at least have preemptive multitasking. Windows 3.1 had neither, but OS/2 had both. The question is not why MacOS didn't have memory protection in 1984 (it wouldn't have run on an original Mac if it did!), but why they never added memory protection, even when they had the perfect opportunity with the 68k->PowerPC transition.
-Jake