AOL couldn't give a damn about anything in computer land which is not Win32. Witness their recent decision to axe their Mozilla developers and throw their lot in with Microsoft.
If there were a more shortsighted and ultimately stupid business decision than to let your closest competitor implement your content rendering engine locking you into their operating system then I'd like to know about it. Why not allow a mental patient to shave your balls with a razor blade while you're at it?
Well, I suppose Mac users might get some rich IM content, but I suspect AOL are hoping to foist that work onto Apple.
If it were just a case of replacing a G3 with a G4 then people could just order a new chip and swap them over. Unfortunately it isn't like that at all, with most acceleration solutions consist of a daughter board of some kind.
Either this daughter board sits in the ZIF or replaces your existing processor card. Either way it is constrained by the limitations built into the rest of the motherboard. If the motherboard only operates at a certain clock speed, or has bus constraints, or anything else then so does your upgrade. And all for a premium price, with no guarantees from Apple or anyone else that it will support future versions of the OS.
Anyone who buys a G4 400 Mhz sans monitor for $355 is insane. And if it's *with* monitor then you can add that into your calculations.
Besides which, the bottom line is I managed to upgrade a six year old PC to a respectable spec for $350. All it cost me was the time to browse Komplett.ie for the spec I wanted and about an hour with a dremel to cut away a proprietary moulding on the back of my Gateway case. Other than that, I got a brand new machine with little effort at all.
I don't deny that *some* Mac upgrade paths exist but they pale totally in comparison with the PC world. Hell, you could buy a new PC in Walmart for the price that an upgrade would cost in Mac land.
As mentioned previously I own a Mac (two if you count a Mac SE I have living in a cupboard), so I'm not denying its other charms but future proofing and cheap upgrade paths are certainly not amongst them.
No it isn't new. The motherboard, cpu and memory certainly are, but the rest of it - keyboard, mouse, PSU, case, monitor, gfx card, harddrive, modem - are not. In other words, I have taken off the shelf parts (costing around $350) swapped them for the old ones and completely rejuvenated my machine. It's not some wacky daughter board that sits in the CPU socket of my old board and twiddles the voltage and clock speeds the new CPU to work, it is a brand new PC indistinguishable from any other and has no compromises on its performance. Hell, I expect I could even slap an 64-bit Athlon board in there at some stage.
The same is not at all true for the Mac. You can forget off the shelf for starters. If you're lucky you'll find some third party who'll sell you some solution for your particular model, but you'll most likely be hobbled by the original motherboard architecture (e.g. some kludge to fit a G4 into a G3 socket), memory limitations, bus speed etc. or expect to do major surgery to do it. And all for 150-200% markup on the price that generic parts would have cost. Certainly if you buy Compaq or HP you might find yourself in the same boat with regards to custom cases that don't accept generic parts, but that's entirely avoidable in the PC world, not so in the Mac world.
I haven't seen anything in the replies to suggest otherwise - Macs have built in obselescence and it's quite obvious they do. The death knell is already ringing for G3 people and I expect my G4 will hear it in two or three years from now. Now I appreciate Macs for other reasons and would advocate their style, design and OS X over PCs any day, but not on this point.
Re:Wow, this is totally wrong
on
G5s Start Shipping
·
· Score: 1, Informative
What I mean is that after 4 or so years Apple basically dump support for a model. As soon as you buy a Mac, the clock is already ticking on how long you can expect the operating system and new software to work on it. Look at people who own a G3 towers, and ask if their days are numbered now.
The same is not true at all in PC land because even if you have a machine which is genuinely so obsolete that it couldn't run XP for example, you could still swap parts out of it until it could. A case in point would be a Gateway 450 that I own - I replaced the motherboard, stuck in a faster Athlon and more memory and it's as good as new, all with off the shelf parts. I even have an older machine (now retired) which was 12 years old, starting first as a 486sx 25Mhz (before the first Gulf war no less), then upgrading to a DX266, then a DX4100, and then a P133. Even up to the end it still served a purpose, running Mandrake Linux as a firewall.
Try that with a Mac sometime. If you're lucky some third party will offer some accelerator board but for the price of those you might as well go out and buy a new Mac. Still, I suppose when all's said and done you might be able to install Linux on it, but forget running OS X.
My point is that Windows 95 made grandiose claims about being 32-bit when it wasn't at all. It was 32-bit icing on a 16-bit DOS layer. Apple is doing much the same. While the hardware might be 64-bit the software most certainly isn't so touting it as such is either stretching the truth or deliberately misleading depending on how charitable you're feeling.
Now I agree that Ghz is nice and I suspect the 32-bit / 64-bit modes are handled much more nicely that in x86 land, but if what you're buying here is not 64-bit. It's a Ferrari with a speed limiter since the issue of 64 vs 32 is not just about memory, since this chip contains a number of advanced modes e.g. better pipelining operations, branch prediction etc. such that software would greatly benefit from recompilation.
I don't know about you, but I feel rather uneasy about the whole prospect. Macs are hardly known for their long shelf life (i.e. builtin obscelesence) so it seems that the best strategy is to wait for a machine which actually delivers on its promises (and throws in some extra Ghz in the meantime) and not some half baked go-between.
Now perhaps I'll succumb eventually, but I've been down this road before and I find it's best to hang off a little until the fact seperates from the FUD and people can see what's what.
The one button mouse is probably the most valid in the list by a long stretch and not just as a whine. I have to wonder if there is anyone stuck in front of a Mac all day long who hasn't forked out for a decent mouse - one with two buttons or preferably three with a wheel.
There can be few users, novice or otherwise who can't cope with more buttons these days. Perhaps that wasn't true once, but persisting with the one button design means new users get a crappy mouse and a crappier 'experience' neither of which is what Apple wants.
I don't see a machine like this being the ressurection of Apple until they produce a consumer version. That leaves the professional Apple users and there are only so many in the world, especially those who *need* a new Mac.
Of course many Mac heads would love a new machine for the sake of it (count me in since my dual CPU G4 runs like a slug) but I wonder how many will justify the expense of it.
I also have my doubts of forking out for a machine which regards '64-bit' in the much same sense as Windows 95 did with '32-bit'. Maybe the hardware is 64-bit but I wonder how long it will take for the operating system let alone anything else to make proper use of it. And if we're talking some months, it seems that waiting is the most prudent thing to do. Hey, it's not like Apple haven't had production problems before now (*cough* G4 cube) so maybe this is smart anyway.
Or (horrors!) make smbpasswd a small shell script which invokes the proper command in the net command.
Or do what the likes of busybox, gzip, bzip2 etc. do and look at the name of the executable / link that invoked it and perform that action. For example in busybox you can make links to it called ls, rm, mv etc. and it does the right thing when they're invoked. It doesn't seem too dissimilar if this net program did the same, checking if argv[0] says 'smbpasswd' and just invoke that functionality.
When does the invasion begin?
on
TAM 5 Has landed
·
· Score: 5, Funny
Now that Ireland is clearly within range to launch an UAV attack on the US, we can expect the invasion to happen shortly.
It's not just market share. Windows has reasonably well defined interfaces to write drivers and reasonably well defined mechanisms to install them.
Linux has no installer at all and the kernel interfaces keep changing all the time, so vendors must resort to a mishmash of wacky rpm / script solutions. It's not uncommon to look for a driver and be confronted with a choice of 10 or so different RPMs compiled for different dists or kernerls. Or to grab some uber script like NVidia's installer that decides to royally fuck up file permissions leading to weird errors because the umask was different than it expected (e.g. because the machine was running with a higher security level).
And expecting vendors to ship their driver as source (even if they wanted to) and compile it to the installed kernel is the answer either, since lots of dists might not even include a compiler which renders the issue academic. Besides which, people who don't even install gcc are probably those most likely to be using Linux as a consumer device.
Linux really, really needs a mechanism that makes it easy (as in EASY) for vendors to deploy drivers to some random dist. Even if there is some performance hit from doing so, I truly believe the likes of Red Hat, Mandrake, SuSE etc. should come together and produce a set of binary APIs and a deployment mechanism. Until they do, Linux is always going to be lagging behind Windows (and the Mac) when it comes to supported hardware.
I'm aware of it, but it has a different form factor from the T2, using a keypad instead of graffiti and is a lot larger. I wonder if this is because of the 802.11b specifically or because it was easier to retrofit wifi into their existing W model.
I might yet get a T2 and stick a 802.11b card into it when I need that functionality.
Yes in theory bluetooth should be dirt cheap. For many devices such as PDAs, computers we're talking some small extra circuitry, a chip or two and some wires, adding maybe a dollar at most onto the design. At that price it should become ubiquitous, if not for accessories costing a fortune.
I can tenously understand that a wireless headset must also ship with a charger, a docking station and a battry in the headset, which all adds to the price but $100+ is still way too much. A conventional phone headset can be picked up for a tenth of the price and needs none of this stuff. I also wonder what the point of a wireless headset is - you might not have a wire, but now you need a mains adapter and dock instead! So much for technology.
So far, 802.11b is still king for me. I'd love to see support for both but I suspect it's going to be an either / or situation which is a shame. I love the Palm Tungsten devices but I'd much rather have the 802.11b support than bluetooth in the T2 design.
If my local CarphoneWarehouse is anything to go by - a fucking fortune. Headsets cost over 100.
Which is why bluetooth is one of those cool but rather pointless technologies. Having a mini network is kind of cool, but if the choice is between the minor inconvenience of connecting devices together with a cable or paying many multiples more for bluetooth, I'll what I'd pick former.
I would be happy to reconsider, but I think the prices are taking the piss at the moment, probably because there are a lot of chumps out there.
The law has zip to do with it. Red Hat could easily ship everything except the part that does the CSS decoding since Xine can play other kinds of media and even region unencoded DVD titles too without problem. And there are no issues with shipping mp3 either assuming it is done from a reference implementation.
As it stands, getting Xine to work is a hopelessly complicated task requiring the download of 15 or so seperate packages, assuming you know where to look for them.
No, Red Hat doesn't even ship a bloody MP3 or DVD player! Though they might have legal reasons for this, that attitude will have to change if they expect to encourage widespread adoption of their dist.
Novices and consumers want automatic updates, since they expect their computers to just work. Binary patches offers an ideal chance for Linux to offer this. Otherwise Linux risks being polluted with exploitable boxes because people are too lazy (or busy doing other stuff) to update their machines and everyone suffers.
I don't suppose people who like to control their machines would like a feature, but for consumer level it's good enough. Personally I wouldn't mind the feature but I would prefer the OS asked me before installing them.
But the thing is there is no 2.6.0. There are 2.6.0-test releases, but there is a way to go yet. Even Linus says as much. And if you read the kernel traffic & post halloween documents you'll see there are a lot of things that have not been fixed or tested, especially some of the less common drivers.
And drivers and stability are the two most important things dists are interested in. And just like the 2.4.x series it was only after several more iterations after 2.4.0 that both of these things are likely to be achieved for mass consumption. Mandrake might pick it up pretty quickly once 2.6.0 is out proper but I imagine that 2.4 is still going to be the mainstay of dists until they go through their next major iterations.
And it's binary patches which make it such a pain in the arse to keep Linux up to date. Really, everytime someone finds an exploit in glibc or the kernel which involves a few line patch, everyone is expected to download a 20Mb package!
That's fine if you happen to be broadband but sucks if you don't. In an ideal world, everyone would be motivated to waste the hours to grab the update, but how many bother, especially with the workings of Linux becoming more opaque and the users less knowledgable? The consequence is lot more unpatched Linux machines with all that entails.
Linux desperately needs binary patch support for this reason. I wonder how hard it might be to do. If someone has RH8 - i.e. a known configuration with RPMs of a certain version, it should be possible to produce incremental patches from that baseline that were a mere fraction of a full download. Instead of a 20Mb download, users would be faced with patches measuring in a few hundred k. Instead of hours to download, we're talking minutes at most. It even opens the possibilty to have an automatic download (and installation) functionality built into Linux, much like that found in MS Windows.
But MS Windows only uses automatic updates for small hotfixes for the same reason that service packs are humungus. How long before MS produce incremental patches for their OS? Here is the chance for Linux to take the lead for once.
Not to put too fine a point on it, but 2.6 isn't out yet and is extremely unlikely to be for several months possibly even six months from now. The 2.6 test and prerelease stages are only starting and is likely to go through a significant number of iterations before being called 2.6.0. Therefore, unless Mandrake intend to release what is essentially a alpha state kernel with broken drivers and the ensuing carnage when it trashes or doesn't work in various machines, it would seem highly unlikely to me.
Of course they could always include it as a 'try this if you dare' advanced feature, which might make some sense, but one would hope that they kept the 2.6 package up to date with the latest changes if they did that.
The thing is, XML is just plain ascii too (assuming you mandate not to use Unicode or some weird charset), so therefore you're not reducing the ability of people to read the text. At worst they'd be inconvenienced by extra tags if they tried to read it raw, but then again they wouldn't have to.
The reason for this is XML is easily translatable into just about anything else that the grammar allows for. So I don't see it would make any difference to the project goals if the 'master copy' for every document were in XML and a plain ASCII transform was immediately produced and kept in sync with it. People could still grab a.txt file if they wanted, but for those of us who want to read something on a palm pilot, or comfortably in a browser, we'd be able to do just that.
Yeah but the entire point of XML is that it defines structure not presentation. If you want to go off and produce something which is readable in some other format (e.g. text), feed the document through some XSL transformation or perl script and it pops out the other end in any way you desire. Someone else can feed it through something that produces a PDF, someone else a Palm e-Book, someone else braille. And this can all be automated on the server. Everyone is happy.
As for XML being long dead, this is highly unlikely. XML is just structured data and is itself just text. It would be trivial 5, 10, or even 100 years from now to pull out the data from the xml format in any way you please. Unless the grammar is horribly mangled (MS Office), it would even be possible to infer it without even knowing the grammar. I would trust Gutenberg to collectively come up with a format which would be simple for proof readers and parsers alike.
Gutenberg is great and all, but it really needs to dump the text format. So much information is lost that it makes reading some texts extremely difficult. Some format that preserved chapter headings, footnotes, illustrations etc. would be a massive step forward.
Now let's turn this around... IE crashes, you don't know why but you have 100 users depending on it working properly. Unless you have some expensive support contract and can snap your fingers and make Microsoft jump you're basically fucked. Just hope and pray you can get finance approval to escalate this issue up the various support tiers until someone in MS listens and more importantly acts. After all, it's no good if the problem is fixed in IE 7 or you must upgrade to Windows 2003 to get it.
Now consider the same in Mozilla. Mozilla crashes, you don't know why blah blah. Your first port of call is Bugzilla and best case you find the bug is already logged. Reading through the comments you learn of a trivial to workaround (e.g. disable a pref). Better yet someone has already produced a patch so you roll your own version of Moz and apply it or wait for the next and reasonably frequent milestone releases. Problem solved. If there is no bug, log one, track it, ask the community for help. If you get no response, pay whoever it might be Sun, Red Hat, Netscape / AOL $$$ to fix it.
So worst case you're no more out of pocket than you were with MS. Best case you get fast and free support, a detailed description of the issue and progress updates as it is worked on.
Sorry but this silly. How many crash bugs do you think there are in IE, Windows, Office, or any other commercial product by any other company for that matter? If IE doesn't have hundreds of crash bugs I would be enormously surprised.
If you think the answer is zero, or that commercial software is any better you would be mistaken. The only difference between Mozilla and other software is you can read the bugs and therefore gauge the risk and even produce workarounds if necessary. With commercial software bug reports disappear into a black hole - they might be fixed or they might not but you'll never know until an update appears and you can try to replicate the problem.
Slashdot Mirror
If there were a more shortsighted and ultimately stupid business decision than to let your closest competitor implement your content rendering engine locking you into their operating system then I'd like to know about it. Why not allow a mental patient to shave your balls with a razor blade while you're at it?
Well, I suppose Mac users might get some rich IM content, but I suspect AOL are hoping to foist that work onto Apple.
Either this daughter board sits in the ZIF or replaces your existing processor card. Either way it is constrained by the limitations built into the rest of the motherboard. If the motherboard only operates at a certain clock speed, or has bus constraints, or anything else then so does your upgrade. And all for a premium price, with no guarantees from Apple or anyone else that it will support future versions of the OS.
Besides which, the bottom line is I managed to upgrade a six year old PC to a respectable spec for $350. All it cost me was the time to browse Komplett.ie for the spec I wanted and about an hour with a dremel to cut away a proprietary moulding on the back of my Gateway case. Other than that, I got a brand new machine with little effort at all.
I don't deny that *some* Mac upgrade paths exist but they pale totally in comparison with the PC world. Hell, you could buy a new PC in Walmart for the price that an upgrade would cost in Mac land.
As mentioned previously I own a Mac (two if you count a Mac SE I have living in a cupboard), so I'm not denying its other charms but future proofing and cheap upgrade paths are certainly not amongst them.
The same is not at all true for the Mac. You can forget off the shelf for starters. If you're lucky you'll find some third party who'll sell you some solution for your particular model, but you'll most likely be hobbled by the original motherboard architecture (e.g. some kludge to fit a G4 into a G3 socket), memory limitations, bus speed etc. or expect to do major surgery to do it. And all for 150-200% markup on the price that generic parts would have cost. Certainly if you buy Compaq or HP you might find yourself in the same boat with regards to custom cases that don't accept generic parts, but that's entirely avoidable in the PC world, not so in the Mac world.
I haven't seen anything in the replies to suggest otherwise - Macs have built in obselescence and it's quite obvious they do. The death knell is already ringing for G3 people and I expect my G4 will hear it in two or three years from now. Now I appreciate Macs for other reasons and would advocate their style, design and OS X over PCs any day, but not on this point.
The same is not true at all in PC land because even if you have a machine which is genuinely so obsolete that it couldn't run XP for example, you could still swap parts out of it until it could. A case in point would be a Gateway 450 that I own - I replaced the motherboard, stuck in a faster Athlon and more memory and it's as good as new, all with off the shelf parts. I even have an older machine (now retired) which was 12 years old, starting first as a 486sx 25Mhz (before the first Gulf war no less), then upgrading to a DX266, then a DX4100, and then a P133. Even up to the end it still served a purpose, running Mandrake Linux as a firewall.
Try that with a Mac sometime. If you're lucky some third party will offer some accelerator board but for the price of those you might as well go out and buy a new Mac. Still, I suppose when all's said and done you might be able to install Linux on it, but forget running OS X.
Now I agree that Ghz is nice and I suspect the 32-bit / 64-bit modes are handled much more nicely that in x86 land, but if what you're buying here is not 64-bit. It's a Ferrari with a speed limiter since the issue of 64 vs 32 is not just about memory, since this chip contains a number of advanced modes e.g. better pipelining operations, branch prediction etc. such that software would greatly benefit from recompilation.
I don't know about you, but I feel rather uneasy about the whole prospect. Macs are hardly known for their long shelf life (i.e. builtin obscelesence) so it seems that the best strategy is to wait for a machine which actually delivers on its promises (and throws in some extra Ghz in the meantime) and not some half baked go-between.
Now perhaps I'll succumb eventually, but I've been down this road before and I find it's best to hang off a little until the fact seperates from the FUD and people can see what's what.
There can be few users, novice or otherwise who can't cope with more buttons these days. Perhaps that wasn't true once, but persisting with the one button design means new users get a crappy mouse and a crappier 'experience' neither of which is what Apple wants.
Of course many Mac heads would love a new machine for the sake of it (count me in since my dual CPU G4 runs like a slug) but I wonder how many will justify the expense of it.
I also have my doubts of forking out for a machine which regards '64-bit' in the much same sense as Windows 95 did with '32-bit'. Maybe the hardware is 64-bit but I wonder how long it will take for the operating system let alone anything else to make proper use of it. And if we're talking some months, it seems that waiting is the most prudent thing to do. Hey, it's not like Apple haven't had production problems before now (*cough* G4 cube) so maybe this is smart anyway.
Or do what the likes of busybox, gzip, bzip2 etc. do and look at the name of the executable / link that invoked it and perform that action. For example in busybox you can make links to it called ls, rm, mv etc. and it does the right thing when they're invoked. It doesn't seem too dissimilar if this net program did the same, checking if argv[0] says 'smbpasswd' and just invoke that functionality.
Now that Ireland is clearly within range to launch an UAV attack on the US, we can expect the invasion to happen shortly.
Linux has no installer at all and the kernel interfaces keep changing all the time, so vendors must resort to a mishmash of wacky rpm / script solutions. It's not uncommon to look for a driver and be confronted with a choice of 10 or so different RPMs compiled for different dists or kernerls. Or to grab some uber script like NVidia's installer that decides to royally fuck up file permissions leading to weird errors because the umask was different than it expected (e.g. because the machine was running with a higher security level).
And expecting vendors to ship their driver as source (even if they wanted to) and compile it to the installed kernel is the answer either, since lots of dists might not even include a compiler which renders the issue academic. Besides which, people who don't even install gcc are probably those most likely to be using Linux as a consumer device.
Linux really, really needs a mechanism that makes it easy (as in EASY) for vendors to deploy drivers to some random dist. Even if there is some performance hit from doing so, I truly believe the likes of Red Hat, Mandrake, SuSE etc. should come together and produce a set of binary APIs and a deployment mechanism. Until they do, Linux is always going to be lagging behind Windows (and the Mac) when it comes to supported hardware.
I might yet get a T2 and stick a 802.11b card into it when I need that functionality.
I can tenously understand that a wireless headset must also ship with a charger, a docking station and a battry in the headset, which all adds to the price but $100+ is still way too much. A conventional phone headset can be picked up for a tenth of the price and needs none of this stuff. I also wonder what the point of a wireless headset is - you might not have a wire, but now you need a mains adapter and dock instead! So much for technology.
So far, 802.11b is still king for me. I'd love to see support for both but I suspect it's going to be an either / or situation which is a shame. I love the Palm Tungsten devices but I'd much rather have the 802.11b support than bluetooth in the T2 design.
Which is why bluetooth is one of those cool but rather pointless technologies. Having a mini network is kind of cool, but if the choice is between the minor inconvenience of connecting devices together with a cable or paying many multiples more for bluetooth, I'll what I'd pick former.
I would be happy to reconsider, but I think the prices are taking the piss at the moment, probably because there are a lot of chumps out there.
As it stands, getting Xine to work is a hopelessly complicated task requiring the download of 15 or so seperate packages, assuming you know where to look for them.
No, Red Hat doesn't even ship a bloody MP3 or DVD player! Though they might have legal reasons for this, that attitude will have to change if they expect to encourage widespread adoption of their dist.
I don't suppose people who like to control their machines would like a feature, but for consumer level it's good enough. Personally I wouldn't mind the feature but I would prefer the OS asked me before installing them.
And drivers and stability are the two most important things dists are interested in. And just like the 2.4.x series it was only after several more iterations after 2.4.0 that both of these things are likely to be achieved for mass consumption. Mandrake might pick it up pretty quickly once 2.6.0 is out proper but I imagine that 2.4 is still going to be the mainstay of dists until they go through their next major iterations.
That's fine if you happen to be broadband but sucks if you don't. In an ideal world, everyone would be motivated to waste the hours to grab the update, but how many bother, especially with the workings of Linux becoming more opaque and the users less knowledgable? The consequence is lot more unpatched Linux machines with all that entails.
Linux desperately needs binary patch support for this reason. I wonder how hard it might be to do. If someone has RH8 - i.e. a known configuration with RPMs of a certain version, it should be possible to produce incremental patches from that baseline that were a mere fraction of a full download. Instead of a 20Mb download, users would be faced with patches measuring in a few hundred k. Instead of hours to download, we're talking minutes at most. It even opens the possibilty to have an automatic download (and installation) functionality built into Linux, much like that found in MS Windows.
But MS Windows only uses automatic updates for small hotfixes for the same reason that service packs are humungus. How long before MS produce incremental patches for their OS? Here is the chance for Linux to take the lead for once.
Of course they could always include it as a 'try this if you dare' advanced feature, which might make some sense, but one would hope that they kept the 2.6 package up to date with the latest changes if they did that.
The reason for this is XML is easily translatable into just about anything else that the grammar allows for. So I don't see it would make any difference to the project goals if the 'master copy' for every document were in XML and a plain ASCII transform was immediately produced and kept in sync with it. People could still grab a
As for XML being long dead, this is highly unlikely. XML is just structured data and is itself just text. It would be trivial 5, 10, or even 100 years from now to pull out the data from the xml format in any way you please. Unless the grammar is horribly mangled (MS Office), it would even be possible to infer it without even knowing the grammar. I would trust Gutenberg to collectively come up with a format which would be simple for proof readers and parsers alike.
Gutenberg is great and all, but it really needs to dump the text format. So much information is lost that it makes reading some texts extremely difficult. Some format that preserved chapter headings, footnotes, illustrations etc. would be a massive step forward.
Now consider the same in Mozilla. Mozilla crashes, you don't know why blah blah. Your first port of call is Bugzilla and best case you find the bug is already logged. Reading through the comments you learn of a trivial to workaround (e.g. disable a pref). Better yet someone has already produced a patch so you roll your own version of Moz and apply it or wait for the next and reasonably frequent milestone releases. Problem solved. If there is no bug, log one, track it, ask the community for help. If you get no response, pay whoever it might be Sun, Red Hat, Netscape / AOL $$$ to fix it.
So worst case you're no more out of pocket than you were with MS. Best case you get fast and free support, a detailed description of the issue and progress updates as it is worked on.
If you think the answer is zero, or that commercial software is any better you would be mistaken. The only difference between Mozilla and other software is you can read the bugs and therefore gauge the risk and even produce workarounds if necessary. With commercial software bug reports disappear into a black hole - they might be fixed or they might not but you'll never know until an update appears and you can try to replicate the problem.