Performing tests of paravirtual Redhat under Redhat's version of xen (RHEL5.1), it scaled significantly better than ESX under load (concurrent vm's doing kernel compilations on a multi-CPU machine). Tested from 0.5 to 4 fully loaded vms per cpu. Both scaled fairly linearly, but ESX incurred, in comparison, a noticable overhead.
I wouldn't use it (in production) for anything but linux-on-linux virtualization, but if that's the only thing for consideration, the performance advantage is noticable. Combine that with the lack of a linux vic-client and VMWares apparent general disinterest in linux, slow support for new kernel versions, etc, and ESX isn't that palatable an option in comparison.
If you're writing a server to handle 100,000 connections simultaneously you probably want to use threads.
If you're after efficiency you might want to use non-blocking socket IO and avoid both thread or process overhead (or some hybrid model, depending on application and CPU demand).
Yes, covers are partial overlaps, altho not full replacements. And sometimes there are non-exclusive deals (becoming more common with modern distributors). Hence the (generally).
In the case of songs, it has already been so restructured
Mandatory mechanical licensing is indeed a slight step in the right direction. Extend it to all parts of the chain and you'd be a good step on the way (ie, not only is the lyrics and score mandatory licensed, but also recordings/performances). And convert it to percentage of revenue shares, similar to sales taxes, to promote economic efficiency. Oh, and have a government agency (the IRS?) actually handle the transfer of money so we get public accountability over what the scheme costs the economy.
In one fell swoop you'd have a complete solution that can manage all forms of distribution, scaling from private copying through download libraries, from music warehouses to automatic on-demand cd-pressing machines, from commercial broadcasting to public performances.
However, the executive and board gets to decide what they think is the most profitable strategy. Business judgment, as is. The law may prevent outright deliberate destruction of shareholder value, but as long as the executive can reasonably motivate their decisions as being in the interest of the shareholders, long or short term, your options as a shareholder, if you disagree, is to sell the stock or vote to replace the executive.
In the Dodge_v._Ford case you cite, the argument forwarded by Ford had very little to do with shareholder value. Had he done the exact same thing, but motivated it for purposes of expanding market share and increasing future production capacity to meet demand, with any altruistic or external motives being secondary and purely incidental to the business goals, it would probably have been ok.
Any copyrighted work is a government protected monopoly on its own, which makes the distinction harder to make.
While an airline (or two different airlines) and a bus may get you to your destination, the fact is, despite the significant attempts to make everything sound the same, different songs are not the same destination. And you can't (generally) buy the same song from different entities.
they're allowed to collude all they want and nobody bats and eye.
See, the trouble is they don't really need to collude. Monopoly pricing is set in relation to available disposable income; it's a function of what the consumers will spend. You maximize your revenue when you raise prices to the equilibrium point where higher prices mean lower income (as the higher per-unit revenue wont be outweighed by the lost sales), and not a cent below. (This point tends to be at a level where a significant number of customers cannot afford the product, and is also the main reason for things like region coding and parallel import prevention in other similar product areas)
As the monopoly pricing is set as a function of the same thing, all the players will end up with very similar price points. After that, the main competition going on is exposure and channel control (well, apart from friendly copying).
In essence, monopoly rights are irreconcilable with a free market economy. The business logic when you have a protected monopoly simply doesn't work the same way as competitive industries, so there's a permanent conflict of interest between the bigger players and everyone else. A conflict that is unlikely to be resolved until monopoly rights are restructured as non-exclusive revenue share rights, which simply is unlikely to happen any time soon.
While I don't object to caps on principle, I certainly think ISP's should be required to advertise them as having the bandwidth the capped usage allows over time. A connection capped at 250GB should be advertised as a 100Kbit connection (with higher peak transfer rates).
That's perfectly fine. In the longer term though, don't be surprised when the contract manufacturers take over the aftersales business as well.
Retreats upwards in the foodchain, to the more 'profitable' or 'brand value' segments is a standard for corporations who've gotten too heavy to compete. Ultimately they tend to get bought by their more nimble competition.
I don't even rip my DVD's to full quality, so why would I have any interest in paying a premium for a format with larger files? I'm sure it'd just be more work to rip, so basically it'd be paying more for getting less.
I keep all my media centrally organized on a media server, so going back to using the actual disks when I want to watch something would be like going back prior to the industrial revolution and doing everything by hand. I don't want to put a 'disk' in my 'player', I don't want to litter a bookshelf with media or figure out what's in what sleeve, or go look for whatever I want to watch in another room, or whatever.
So, DVD's are fine and will do until the industry gets its act together and will sell me the appropriate un-DRM'ed network delivery service in the future. If they wont, at worst we'll have unmonitorable social darknets doing the same thing.
Now, if they could come up with a high-definition storyline system that might actually be an improvement tho...
An even better example would be OSI. Which, come to think of it, wasn't that different from OOXML. Unwieldy, impractical, with no known implementations and with doubts over even the possibility of implementing it.
I'm sure there are fields wherein ISO serves some sort of purpose (the auditing field, if nothing else...), but their track record in computing doesn't inspire confidence.
In the end I'd say it's better to encourage adoption of requirements that publicly used document 'standard' formats and protocols be available in unencumbered form, with open public domain reference implementations. That, at least, would get closer to what the ISO should be doing in the computing field.
Red Hat does *not* tell us: "Oh, I'm sorry you're not running the latest support pack, no support for you."
I've found it's more likely that _I'm_ telling customers that we should patch to fix problems they have with Redhat systems than Redhat telling me.
We're still running AS4U4
Heh, we have some AS4U2 systems, with only selected patches applied. I suspect some customers have used software from 'enterprise' vendors who don't have quite as strict don't-break-stuff policies with their updates. I can sympathize; I've had vendors change actual major versions of software in 'patches', rather than backport bugfixes.
So I have to agree with you, Redhat is a rare pleasure to deal with in the enterprise software support space.
Myself I use it when I need a quick picture for a project
Yah, I keep trying to use if for things like that myself. Taking pictures off serial numbers on servers (didn't work, the cam cant focus close enough to make out the text), disassembly pictures to know how to put stuff back together (again, focus/detail conflict), snapping shots of stuff at parties (doesn't work, not enough lighting), etc. It seems one has to carry around an industrial lighting and power supply to actually provide the conditions under which a cameraphone can take adequate pictures. Which tends to be rather more difficult to carry around than an actual camera. Not to mention that people might get annoyed when you turn on the floodlights at the party.
No matter what use one tries to put it to, it turns out to be inadequate. Usually I'm better off with a damn pencil, drawing whatever I want a picture off if I don't have a camera handy.
Creating two separate product lines is quite a bit more expensive than one;
You're only counting the production cost. A camera in a cellphone is not 'free' in various design issues such as available space and layout complexity. Not only can you produce a cheaper phone without a camera, you can also produce a smaller one and/or have space for a larger battery, or make it thinner, etc. You catch the customer who wants the camera, but you lose the ones who'd want the alternative features more.
Personally I have to agree with the GP, cameras on cellphones are an utter waste. The required optics and aperture size needed to produce even decent pictures simply cannot be reconciled with the other design requirements on a phone, so it remains a useless gimmick. I could see a use for a bluetooth/usb connected CCD and optical accessory, but the current crop of crap would be better left out.
I never use the popcorn button on my microwave
The popcorn button on your microwave doesn't add 30% to its size or reduce the other functionality. The camera on the phone does.
Not to mention, who is going to release the next Fedora, the next Ubuntu, the next...?
Without IP issues it becomes vastly more simple to build upon and combine works. The 'but who would pay' question has been quite thoroughly answered by the free software community as a whole. Perhaps you'll miss out on a marketing campaign or two, but the evolution of art and entertainment will continue with even less roadblocks.
that's just wrong in some extremely fundamental way
What's even more wrong would be the fact that people are actually getting paid to spend their lives moving bits in a database that could be created by the trillions with the press of a button.
There are barely words for the economic waste that implies. Talk about make-work. Imagine the extra wealth that could have been created had they simply handed those bits to the players who want them and spent the money (and the time of the farmers) on something more productive than updating artificially limited database entries.
Encrypted connection without signed certificates prevent random 'grepping' through tcpdumps. They're not useful for preventing actual targeted attacks, but for many instances of that, neither are CA's (who'd probably sign keys for most government TLA's, as well as anyone who can soceng them, etc).
What mass encryption without CA involvement would do, tho, is make random spying (echelon, etc) and packet inspection much, much more difficult.
The technologies serve different purposes. They should be decoupled.
Mmm, that's rather interesting, and one of the aspects of ZFS I find most interesting. Do you know of any research on the data integrity issue or have any good links on it? I've seen the claims too, but frankly, I haven't noticed data integrity problems as a serious issue, even in a large enterprise environment. I mean, heck, even ECC errors are extremely rare occurances that usually indicate actual broken hardware (and having had Sun techs complain about cosmic radiation corrupting memory being the cause of system crashes I'm a bit leery of claims from Sun).
Non-ECC memory is certainly a large possibility for errors, but again, in my experience even a few defective bits in a memory chip will cause a solid crash so fast you'd notice from the once-a-minute crashes if it was an even remotely common occurance. Not exactly the same thing, but them being 'silent' just hasn't been my experience with data corruption issues.
It would be interesting to see data from a huge installation like Google on how often their data comes back silently corrupted from one of their replicas. Is it common? Does it happen at all in the real world?
In theory, the sheer volumes of data suggest it should happen often. In practice it doesn't appear to be. So I don't know wether I should sha1sum all my data or not:). Or if Linux would do well with an optional dm-checksummer layer in the devicemapper.
Yep; perhaps it would be better to 'share' the available work rather than 'share' the income generated. Cut down working hours across the board to increase (divided) demand and lower the burden on welfare systems. There's an overhead cost for employing people, but then again, I'd suggest that productivity per hour might actually increase for lowered hours... not to mention other benefits like making it easier to sustain longer working lives.
More people working at important/satisfying work is.
Satisfying work isn't necessarily paid work tho; another future alternative is the Iain Banks Culture version of development, where basically production is so automated that whatever 'jobs' humans have could as well be considered 'hobbies' or 'interests'. Important, sometimes, but mainly satisfying.
The entire purpose of the economy and the whole creation of wealth relies on that; it takes less work to accomplish the same thing. That's a good thing. Making things labour intensive aren't an end in itself.
Of course, during earlier eras of increased productivity, such as when going from an agrarian to industrial society, we also cut down on working hours. These days it appears more popular to drive the working part of the population to burnout while they get to support the non-working population. All while whining about 'disappearing jobs'.
yet you can't see the improvement on Linux's model?
Yah, the OOM crashes, flush hangs, dbf fragmentation and performance degradation issues really left a bad aftertaste. I didn't go into those details, as anyone else who'd run ZFS in production for some time would most likely know about them. Some are fixed now, but improvement... lets just say that any improvement I could see was rather outweighed by the problems.
Don't get me wrong, ZFS is nice if you use it where it has it's strengths. It's a perfect filesystem for hardware like thumpers serving out NFS. Unfortunately it seems to be designed with that, and only that, in mind; even worse, technical evangelism at Sun appears to have failed to mentioned that to their tech sales, getting ZFS installed in ways it's not at all suited for.
A more flexible architecture would have allowed ZFS to be great for many things where it can actually get in the way today.
You mean the fact that md is completely broken
So don't use md. Use lvm mirroring. Or hardware mirroring. Or drbd remote mirroring. See, flexibility. If a layer doesn't do what you want it to, change it.
With regards to ZFS, I dream of there being an equivalent on Linux.
Out of curiosity, what particular features in ZFS do you want on Linux? I mean, it's a large step upwards from solaris disksuite, but compared to the linux device-mapper/filesystem paradigm it's not a particularly large improvement (if it is one at all).
Having actually run ZFS in production, there are some serious drawbacks with the remaining features (copy-on-write fragmentation, problems in SAN environments, etc), that may leave one wishing they'd implemented the ZFS features in a more stackable way so you could easily discard inappropriate layers and features.
Is it American chauvinism that makes so many here discount RIM & Nokia?
I suspect it's more a question of what hype you're buying into. Personally I don't find either platform particularly compelling (nor am I particularly impressed by RIM & Nokia). Call it a decades worth of weariness at more or less semi-proprietary offerings that never seem work quite right.
I find the Openmoko far more interesting; I'm sure it'll be... difficult... in the beginning, but the potential for actually evolving into something entirely new (rather than what some particular 'Vision' dictates) makes it something I'll throw some money at.
As long as you only care about internally initiated connections.
Yep, that's the main reason I've gone v6 myself. NAT is all well and fine, but it's much more practical to ssh/scp/etc directly to machines behind the NAT. Configuring 6to4 is easy and having several ipv4 internets address space to myself is nice.
what happens if he doesn't patent it? Someone else does.
Not if the relevant (possibly) patentable materials are already published. Write an article about whatever it is in a trade rag and it will become unpatentable.
Of course, in the gridlock crap system we have, someone else could patent a natural evolution of the subject matter, in which case having a patent to stop them from improving your thing might be useful.
You may have to just grin and bear it.
Or just, which is your duty, carefully disclose every single piece of prior art or similar idea you have read about. Which would strengthen the patent if it actually is issued, but more likely just make it obvious that whatever it is is utterly obvious to anyone actually trying to solve the particular problem.
Slashdot Mirror
Performing tests of paravirtual Redhat under Redhat's version of xen (RHEL5.1), it scaled significantly better than ESX under load (concurrent vm's doing kernel compilations on a multi-CPU machine). Tested from 0.5 to 4 fully loaded vms per cpu. Both scaled fairly linearly, but ESX incurred, in comparison, a noticable overhead.
I wouldn't use it (in production) for anything but linux-on-linux virtualization, but if that's the only thing for consideration, the performance advantage is noticable. Combine that with the lack of a linux vic-client and VMWares apparent general disinterest in linux, slow support for new kernel versions, etc, and ESX isn't that palatable an option in comparison.
If you're writing a server to handle 100,000 connections simultaneously you probably want to use threads.
If you're after efficiency you might want to use non-blocking socket IO and avoid both thread or process overhead (or some hybrid model, depending on application and CPU demand).
who's ever recorded a cover version
Yes, covers are partial overlaps, altho not full replacements. And sometimes there are non-exclusive deals (becoming more common with modern distributors). Hence the (generally).
In the case of songs, it has already been so restructured
Mandatory mechanical licensing is indeed a slight step in the right direction. Extend it to all parts of the chain and you'd be a good step on the way (ie, not only is the lyrics and score mandatory licensed, but also recordings/performances). And convert it to percentage of revenue shares, similar to sales taxes, to promote economic efficiency. Oh, and have a government agency (the IRS?) actually handle the transfer of money so we get public accountability over what the scheme costs the economy.
In one fell swoop you'd have a complete solution that can manage all forms of distribution, scaling from private copying through download libraries, from music warehouses to automatic on-demand cd-pressing machines, from commercial broadcasting to public performances.
agree that it's ridiculous. it is however true.
However, the executive and board gets to decide what they think is the most profitable strategy. Business judgment, as is. The law may prevent outright deliberate destruction of shareholder value, but as long as the executive can reasonably motivate their decisions as being in the interest of the shareholders, long or short term, your options as a shareholder, if you disagree, is to sell the stock or vote to replace the executive.
In the Dodge_v._Ford case you cite, the argument forwarded by Ford had very little to do with shareholder value. Had he done the exact same thing, but motivated it for purposes of expanding market share and increasing future production capacity to meet demand, with any altruistic or external motives being secondary and purely incidental to the business goals, it would probably have been ok.
Any label is not a monopoly.
Any copyrighted work is a government protected monopoly on its own, which makes the distinction harder to make.
While an airline (or two different airlines) and a bus may get you to your destination, the fact is, despite the significant attempts to make everything sound the same, different songs are not the same destination. And you can't (generally) buy the same song from different entities.
they're allowed to collude all they want and nobody bats and eye.
See, the trouble is they don't really need to collude. Monopoly pricing is set in relation to available disposable income; it's a function of what the consumers will spend. You maximize your revenue when you raise prices to the equilibrium point where higher prices mean lower income (as the higher per-unit revenue wont be outweighed by the lost sales), and not a cent below. (This point tends to be at a level where a significant number of customers cannot afford the product, and is also the main reason for things like region coding and parallel import prevention in other similar product areas)
As the monopoly pricing is set as a function of the same thing, all the players will end up with very similar price points. After that, the main competition going on is exposure and channel control (well, apart from friendly copying).
In essence, monopoly rights are irreconcilable with a free market economy. The business logic when you have a protected monopoly simply doesn't work the same way as competitive industries, so there's a permanent conflict of interest between the bigger players and everyone else. A conflict that is unlikely to be resolved until monopoly rights are restructured as non-exclusive revenue share rights, which simply is unlikely to happen any time soon.
But you sold them X bandwidth for $Y a month.
While I don't object to caps on principle, I certainly think ISP's should be required to advertise them as having the bandwidth the capped usage allows over time. A connection capped at 250GB should be advertised as a 100Kbit connection (with higher peak transfer rates).
Random script kiddies on the power grid have a hard time pushing electricity into your sockets and costing you a fortune tho.
But there's nothing preventing them from sending you a flood of packets. What was your IP address again...?
That's perfectly fine. In the longer term though, don't be surprised when the contract manufacturers take over the aftersales business as well.
Retreats upwards in the foodchain, to the more 'profitable' or 'brand value' segments is a standard for corporations who've gotten too heavy to compete. Ultimately they tend to get bought by their more nimble competition.
I don't even rip my DVD's to full quality, so why would I have any interest in paying a premium for a format with larger files? I'm sure it'd just be more work to rip, so basically it'd be paying more for getting less.
I keep all my media centrally organized on a media server, so going back to using the actual disks when I want to watch something would be like going back prior to the industrial revolution and doing everything by hand. I don't want to put a 'disk' in my 'player', I don't want to litter a bookshelf with media or figure out what's in what sleeve, or go look for whatever I want to watch in another room, or whatever.
So, DVD's are fine and will do until the industry gets its act together and will sell me the appropriate un-DRM'ed network delivery service in the future. If they wont, at worst we'll have unmonitorable social darknets doing the same thing.
Now, if they could come up with a high-definition storyline system that might actually be an improvement tho...
As a trivial example
An even better example would be OSI. Which, come to think of it, wasn't that different from OOXML. Unwieldy, impractical, with no known implementations and with doubts over even the possibility of implementing it.
I'm sure there are fields wherein ISO serves some sort of purpose (the auditing field, if nothing else...), but their track record in computing doesn't inspire confidence.
In the end I'd say it's better to encourage adoption of requirements that publicly used document 'standard' formats and protocols be available in unencumbered form, with open public domain reference implementations. That, at least, would get closer to what the ISO should be doing in the computing field.
Red Hat does *not* tell us: "Oh, I'm sorry you're not running the latest support pack, no support for you."
I've found it's more likely that _I'm_ telling customers that we should patch to fix problems they have with Redhat systems than Redhat telling me.
We're still running AS4U4
Heh, we have some AS4U2 systems, with only selected patches applied. I suspect some customers have used software from 'enterprise' vendors who don't have quite as strict don't-break-stuff policies with their updates. I can sympathize; I've had vendors change actual major versions of software in 'patches', rather than backport bugfixes.
So I have to agree with you, Redhat is a rare pleasure to deal with in the enterprise software support space.
Myself I use it when I need a quick picture for a project
Yah, I keep trying to use if for things like that myself. Taking pictures off serial numbers on servers (didn't work, the cam cant focus close enough to make out the text), disassembly pictures to know how to put stuff back together (again, focus/detail conflict), snapping shots of stuff at parties (doesn't work, not enough lighting), etc. It seems one has to carry around an industrial lighting and power supply to actually provide the conditions under which a cameraphone can take adequate pictures. Which tends to be rather more difficult to carry around than an actual camera. Not to mention that people might get annoyed when you turn on the floodlights at the party.
No matter what use one tries to put it to, it turns out to be inadequate. Usually I'm better off with a damn pencil, drawing whatever I want a picture off if I don't have a camera handy.
Your need of having the cam with you will most likely overrule the desire of those that want a cheaper phone
But will it overrule the desire of those that want a smaller phone, or one with a larger battery, or one with a cleaner design?
Creating two separate product lines is quite a bit more expensive than one;
You're only counting the production cost. A camera in a cellphone is not 'free' in various design issues such as available space and layout complexity. Not only can you produce a cheaper phone without a camera, you can also produce a smaller one and/or have space for a larger battery, or make it thinner, etc. You catch the customer who wants the camera, but you lose the ones who'd want the alternative features more.
Personally I have to agree with the GP, cameras on cellphones are an utter waste. The required optics and aperture size needed to produce even decent pictures simply cannot be reconciled with the other design requirements on a phone, so it remains a useless gimmick. I could see a use for a bluetooth/usb connected CCD and optical accessory, but the current crop of crap would be better left out.
I never use the popcorn button on my microwave
The popcorn button on your microwave doesn't add 30% to its size or reduce the other functionality. The camera on the phone does.
Not to mention, who is going to release the next Fedora, the next Ubuntu, the next...?
Without IP issues it becomes vastly more simple to build upon and combine works. The 'but who would pay' question has been quite thoroughly answered by the free software community as a whole. Perhaps you'll miss out on a marketing campaign or two, but the evolution of art and entertainment will continue with even less roadblocks.
that's just wrong in some extremely fundamental way
What's even more wrong would be the fact that people are actually getting paid to spend their lives moving bits in a database that could be created by the trillions with the press of a button.
There are barely words for the economic waste that implies. Talk about make-work. Imagine the extra wealth that could have been created had they simply handed those bits to the players who want them and spent the money (and the time of the farmers) on something more productive than updating artificially limited database entries.
Encrypted connection without signed certificates prevent random 'grepping' through tcpdumps. They're not useful for preventing actual targeted attacks, but for many instances of that, neither are CA's (who'd probably sign keys for most government TLA's, as well as anyone who can soceng them, etc).
What mass encryption without CA involvement would do, tho, is make random spying (echelon, etc) and packet inspection much, much more difficult.
The technologies serve different purposes. They should be decoupled.
Mmm, that's rather interesting, and one of the aspects of ZFS I find most interesting. Do you know of any research on the data integrity issue or have any good links on it? I've seen the claims too, but frankly, I haven't noticed data integrity problems as a serious issue, even in a large enterprise environment. I mean, heck, even ECC errors are extremely rare occurances that usually indicate actual broken hardware (and having had Sun techs complain about cosmic radiation corrupting memory being the cause of system crashes I'm a bit leery of claims from Sun).
Non-ECC memory is certainly a large possibility for errors, but again, in my experience even a few defective bits in a memory chip will cause a solid crash so fast you'd notice from the once-a-minute crashes if it was an even remotely common occurance. Not exactly the same thing, but them being 'silent' just hasn't been my experience with data corruption issues.
It would be interesting to see data from a huge installation like Google on how often their data comes back silently corrupted from one of their replicas. Is it common? Does it happen at all in the real world?
In theory, the sheer volumes of data suggest it should happen often. In practice it doesn't appear to be. So I don't know wether I should sha1sum all my data or not :). Or if Linux would do well with an optional dm-checksummer layer in the devicemapper.
Jobs are harder to find
Yep; perhaps it would be better to 'share' the available work rather than 'share' the income generated. Cut down working hours across the board to increase (divided) demand and lower the burden on welfare systems. There's an overhead cost for employing people, but then again, I'd suggest that productivity per hour might actually increase for lowered hours... not to mention other benefits like making it easier to sustain longer working lives.
More people working at important/satisfying work is.
Satisfying work isn't necessarily paid work tho; another future alternative is the Iain Banks Culture version of development, where basically production is so automated that whatever 'jobs' humans have could as well be considered 'hobbies' or 'interests'. Important, sometimes, but mainly satisfying.
Less jobs, but more ppl.
The entire purpose of the economy and the whole creation of wealth relies on that; it takes less work to accomplish the same thing. That's a good thing. Making things labour intensive aren't an end in itself.
Of course, during earlier eras of increased productivity, such as when going from an agrarian to industrial society, we also cut down on working hours. These days it appears more popular to drive the working part of the population to burnout while they get to support the non-working population. All while whining about 'disappearing jobs'.
yet you can't see the improvement on Linux's model?
Yah, the OOM crashes, flush hangs, dbf fragmentation and performance degradation issues really left a bad aftertaste. I didn't go into those details, as anyone else who'd run ZFS in production for some time would most likely know about them. Some are fixed now, but improvement... lets just say that any improvement I could see was rather outweighed by the problems.
Don't get me wrong, ZFS is nice if you use it where it has it's strengths. It's a perfect filesystem for hardware like thumpers serving out NFS. Unfortunately it seems to be designed with that, and only that, in mind; even worse, technical evangelism at Sun appears to have failed to mentioned that to their tech sales, getting ZFS installed in ways it's not at all suited for.
A more flexible architecture would have allowed ZFS to be great for many things where it can actually get in the way today.
You mean the fact that md is completely broken
So don't use md. Use lvm mirroring. Or hardware mirroring. Or drbd remote mirroring. See, flexibility. If a layer doesn't do what you want it to, change it.
With regards to ZFS, I dream of there being an equivalent on Linux.
Out of curiosity, what particular features in ZFS do you want on Linux? I mean, it's a large step upwards from solaris disksuite, but compared to the linux device-mapper/filesystem paradigm it's not a particularly large improvement (if it is one at all).
Having actually run ZFS in production, there are some serious drawbacks with the remaining features (copy-on-write fragmentation, problems in SAN environments, etc), that may leave one wishing they'd implemented the ZFS features in a more stackable way so you could easily discard inappropriate layers and features.
Is it American chauvinism that makes so many here discount RIM & Nokia?
I suspect it's more a question of what hype you're buying into. Personally I don't find either platform particularly compelling (nor am I particularly impressed by RIM & Nokia). Call it a decades worth of weariness at more or less semi-proprietary offerings that never seem work quite right.
I find the Openmoko far more interesting; I'm sure it'll be... difficult... in the beginning, but the potential for actually evolving into something entirely new (rather than what some particular 'Vision' dictates) makes it something I'll throw some money at.
As long as you only care about internally initiated connections.
Yep, that's the main reason I've gone v6 myself. NAT is all well and fine, but it's much more practical to ssh/scp/etc directly to machines behind the NAT. Configuring 6to4 is easy and having several ipv4 internets address space to myself is nice.
what happens if he doesn't patent it? Someone else does.
Not if the relevant (possibly) patentable materials are already published. Write an article about whatever it is in a trade rag and it will become unpatentable.
Of course, in the gridlock crap system we have, someone else could patent a natural evolution of the subject matter, in which case having a patent to stop them from improving your thing might be useful.
You may have to just grin and bear it.
Or just, which is your duty, carefully disclose every single piece of prior art or similar idea you have read about. Which would strengthen the patent if it actually is issued, but more likely just make it obvious that whatever it is is utterly obvious to anyone actually trying to solve the particular problem.