"I respect their right to make a living by selling their productions."
I see few objecting to anyone making a living by selling their productions. I do see objections to anyone controlling what anyone else may produce.
Increasing Bill the Chairmakers ability to collect revenue by forbidding anyone else from making similar chairs isnt a sane free market policy. The fact that immaterial products are easier to copy doesnt change the basic premise just as the development of a chair-duplicator would suddenly make a chair monopoly a useful policy.
Intellectual 'property' is essentially a welfare system implemented as a feudal-style delegated taxation right. If we really want and need the incentive created by such a welfare system to we should at least have the intellectual honesty to call it what it is and run it under democratically controlled budgets and fiscal management to at least attempt to ensure the public gets its moneys worth. The system isnt free just because it's hidden in externalized economic flows, the costs are just less apparent. Nor would it be that hard to replace the horrendously inefficient monopoly pricing with simply taxing revenue derived from duplication of a work and handing the benefits directly to the creative talent originating the work, thus solving both the payment problem and the 'piracy' problem at once (your work gets duplicated and the copies sell, you automatically get your share of the collected revenue, and 'piracy' would simply become yet another tax-evasion issue if someone duplicates media for profit without paying the 'IP sales tax').
Well, except every other filesystem on LVM as snapshots have been a feature of LVM since, like, forever...
"If you are really worried about it, don't upgrade the OS for a while."
Or implement the functionality as distinct and separate replaceable layers. Small parts, each good at their own thing, combined to form a flexible and powerful whole. Reminds me of the traditional philiosophy of that old OS, what was it called...
"GPL and CDDL code can't be mixed due to GPL's restrictive nature."
You mean, the CDDL's restrictive nature. The main contention issues appear to be the CDDL's choice of venue restriction, and patent conflict auto-termination issue. IE, restrictions beyond the GPL.
As the GPL protects the freedom of the GPL protected derived code from the restrictions imposed by the CDDL, you can hardly say the GPL is the restrictive license...
'"Business doesn't like the GPL": true when they are on the receiving end, but false when they are on the giving end.'
I'd change that to "true when they are in the middle". Business on the recieving end _loves_ GPL code. It means they dont have to worry about a supplier going bellyup, it means they can change providers, it means they can hire outside help with the code, it means the software isnt going to fork into a bazillion proprietary incompatible versions and it means it's there long term, and that invested time and money isnt going to vanish.
It's the middlemen, who want to recieve freedom but not give it to anyone else who dont like the GPL.
"This is partly why I've tried to convert my projects to BSD licenses. I have a substantial amount of code that I've written GPL"
As long as you're the copyright holder you can change the license when you wish. Or put your contributions to a GPL project under revised BSD or even in the public domain.
"its hard to remember who wrote what."
Ah, there's the rub. That's hardly the GPL's fault tho, is it? That's copyright law and your failure to do what copyright makes it necessary for you to do. Join the crowd and work for copyright abolition if you dont want to bother with that part.
"I don't feel comfortable using my own code because its GPL'd."
You dont feel comfortable using _their_ code because it's GPL you mean. You could have asked for copyright assignment if you wanted to accept the patches in that case. This is not a GPL problem, this is a situation you've put yourself in.
Of course, if the license were not the GPL, or you required copyright assignment, then maybe those contributors wouldn't have contributed. I sure know I wouldn't contribute anything non-trivial under a non-copyleft (preferably GPL) license.
"BSD licensing is the way to go, imo."
Nah, seen too much BSD code get proprietarized and used to screw end users. Not with my code they dont. They can write it all on their own if they want power over others that bad.
Actually, I was thinking more about messing around with perror and the human readable versions (that are translated and such). Of course, it might not be possible to intercept and add code to perror, but if anything could, that would be something as intrusive as SELinux or other MAC layers, as intercepting system calls is their main territory.
"What most people forget is that you can set SELinux to be permissive"
Unfortunately, there's also a whole bunch of people who naively thought permissive mode would only log and not interfere with anything, spent two days troubleshooting some problem, finally _disabled_ SELinux and had it work perfectly from the default two days ago.
I'm sure there were perfectly logical reasons for it to happen, but it's that kind of random, seemingly inexplicable and above all, unlogged problems that turn people off of MAC security. It's not unique to SELinux, I've seen the same kind of crap on other systems like eTrust.
And unfortunately, once you start distrusting the security software (and it doesnt take many instances of such failures), the first line of debugging always becomes - shut it off, shut it off completely and utterly, because I'm not wasting my time again.
"I think part of this problem is that previously there has been no easy way to look as SELinux messages and manage the policies."
I'd say it's the the most important part of the problem. For some reason, designers of these kinds of softwares tend to act as if it's a wholly separate part of the system, with the common result that they're signalling errors in encrypted morse code on a LED on the dark side of the moon. There are standard ways to signal system errors, standard header files defining system messages, and many programs use these facilities to signal what was wrong (such as permission denied). It would be far more acceptable if these were used, and a program would signal 'Permission denied by MAC policy', which would give an easy way to know what to fix.
"Vista likes RAM for the simple fact that it scales extra RAM beyond application/OS usage and standard caching."
That's mainly noticable for those of us who more or less never turn their systems off or reboot, and it's been that way for a long time now.
Personally I cant say I'm complaining about the DRAM market saturation tho, as I run diskless workstations served over iSCSI and Xenified servers, the DRAM prices make me go all fuzzy.
"If G.W.Bush thinks he can overcome a full fledged russian nuclear strike, he is even more of a nutcase than Putin."
Putin may be a nasty customer, but I dont doubt for a second that GWB is far more of a nutcase than Putin is.
And IMO, that's where the problem is. It doesnt really matter if US interceptor bases in Europe stands a realistic chance against a Russian launch or not; it's enough that Bush or some other nutcase on the US throne thinks it may stand a chance. And with the aid of GOD they WILL be shot DOWN!
Bush has repeatedly shown that he will not listen to either real intelligence or military advise, so why would he listen if the military says the bases wont defend against Russia (especially if they secretly put in a few more and better interceptors, after all, our pals in the defense industry promised these were really great and we paid a lot for them)?
Russia is left with no choice but to ensure that in no way, no how, can these bases be in any way, even with the help of GOD, ever be imagined to be capable of shooting down a Russian strike. Or they risk that some current or future utterly deranged administration may think they'll profit from another oil crisis, small scale armed attack, etc, whatever a far gone US administration can imagine to be profitable as long as they do not risk a retaliatory strike.
It's Dr. Strangelove all over again. What good is a doomsday device if you dont tell the world about it? It's not enough that you _can_ screw the other guy, the other guy has to _know_ you'll screw him. If he thinks, even in his raving delusional psychosis, that he can get away with it, the deterrent just isnt enough.
"I could point you at dozens of 'dead end' Linux distros."
Distros are a bit different tho, they are usually not under the GPL as a whole. But for the parts that are, improvements and changes can be merged into main branches, even if the offshoot dies.
"There is no antidote to the end of software development projects"
As long as the source is available there is no end to the project. There may be a hiatus or a lack of progress, but Free sources do not die the way proprietary codebases do.
"It scares the HELL out of me to think that the only thing left might someday be Linux, or some GPL-bound codebase."
It doesnt scare me the same way having only proprietary codebases would. It would be boring and not a good idea from an idea-evolutionary point of view tho.
As a whole tho, I'd prefer the abolition of copyright as a monopoly right and replacing it revenue rights/incentive rights instead, which would bypass the whole issue.
"I couldn't be so certain if I were staring at the screen of a display attached to a Tivo device, it seems."
Indeed. An update can turn your Tivo off permanently. And you do not have the cryptographic keys needed to make it work again. Which is one thing the GPL v3 tries to address.
"I'd like to have somebody draw up for me the big bloody flow diagram of 'failed' BSD systems."
There's a fairly good one (which includes most unixes, both successful and otherwise (it lacks some tho, DG/UX is one I've worked with which I note is not there)) at http://www.levenez.com/unix/.
"GPL 3 type tactics merely encourage companies to reinvent the wheel,"
You mean, encourage companies _who do not want to share back_ to reinvent the wheel.
When they are free to proprietarize the open code, then _everyone else_ has to reinvent the wheel. Take a look at the vast horde of failed or utterly changed BSD based proprietary unixes over the last two decades.
Copylefts minimize the duplication of effort by ensuring that all effort cooperatively survives and evolves; allowing proprietary offshoots merely raises the baseline off which the duplication and NIH syndrome starts.
"It squeezes the middle between the hobbyists at one end and the big companies at the other."
Again, the last two decades indicate otherwise. I see few small to midsize BSD companies these days; the main winners seem to be the large companies. Which fits well when you have a joint baseline; the large companies can throw more resources on building above the baseline than the small, and as they dont have to give back, the smaller ones will have a hard time competing in the next round.
"While it suggests (even states) there is no significant difference between disk types their conclusions are not supported by any scientific methodology or even base consistancy."
IMO, the methodology is useful, as long as it's clearly stated. Running a statistically significant test under controlled environmental and operating conditions would be prohibitively expensive and difficult to accomplish. While the operating conditions may vary, as long as they are within reasonable parameters (ie, operating ranges stated by vendor), and the statistical distribution is fairly even, it serves the purpose for the test (and, I'd suggest that conditions would tend to be skewed towards expensive disks being better taken care of).
"This makes this paper far more dangerous than marketing material, where at least you can go back to the vendor for some accountability."
I'd be much more confident in disk vendors accountability if it werent for the IBM deathstar incident.
And, you know, the vendors do have the data themselves. Still, I have yet to see one actually publish it. Which rather makes me less inclined to trust them.
Still, I wouldn't present the paper to execs without making sure they understood the method with which the raw data was obtained.
"use to companies that are not google."
Yes, the problem with Googles report is that it's geared towards a highly redundant infrastructure where they can live with disks crapping out regularly. However, that infrastructure is also built to provide the best price/performance ratio, and more companies would be better off going with cheap high redundancy rather than expensive, exclusive and at best only slightly more reliable hardware.
"I do not want to have 3 copies of each important machine just to save $47000 per system (as if)."
I'd suggest you're reading things into what I'm saying. Like the article we're talking about, I'm not saying you should stick local disk and triple your machine park.
I'm saying you'd be better off with COTS SATA arrays shared over iSCSI over dedicated redundant gigabit (or 10GB) ethernet. With mirroring, backups and/or rsynced/revisioned data.
"fail to appreciate the environments and demands in which a SAN is a perfectly justifiable, cost efficient solution."
I've worked in such environments for ten years. I've worked with such SANS. In my experience their failure rate is vastly higher than COTS hardware. Not because they get disk or hardware failures, but because their complexity and relative rarity has the whole infrastructure riddled with buggy firmwares, crap drivers, random incompatiblity and inexperienced 'certified' service technicians.
Which means you cant rely on the storage anyway and have to use host level mirroring to cope with relatively frequent SAN failures and/or maintenance (to be fair, the last few years have seen improvements, but it still aint there, and the consumer hardware just keeps getting "there" faster). Which means you could just as well be using less expensive COTS solutions.
Migrating from local disk to SAN promised to save time on storage maintenance work. It hasnt. The sysadmins may not be replacing disks anymore (which the vendors or "disk-monkeys" usually did anyway) but now they have to work on SAN storage migrations, remirroring systems after maintenance, remirroring systems after SAN failures, dealing with substandard drivers, etc. As a whole I'd say far more time is spent on storage with SAN attached systems than the non-SAN attached systems. And to top that off, you usually get storage delivery times that are several times more than what it'd take to buy COTS disk and shove it in yourself. And prices that are orders of magnitude higher than the COTS disk.
SAN vendor costs are not justifiable, but not because they're high priced. They're not justifiable because they dont deliver what they promise. That means if you replace them with a solution that delivers what a SAN _actually_ delivers (as opposed to what they promise), you'd get a far cheaper solution.
You know, all of a sudden I gain a whole new understanding of why some women willingly wear a burka.
I can see a whole new fashion genre being driven by our emerging everpresent surveillance and recording. When will ThinkGeek get a 'privacy enhanced clothing' section?
"Additionally, SATA drives are not as reliable long term as SCSI."
The CMU study by Bianca Schroeder and Garth A. Gibson would suggest otherwise. In fact, there was no significant difference in replacement rates between SCSI, FC, or SATA drives.
"They want the system to phone home when a drive starts getting errors"
Of course, the other recent study by Google showed that predictive health checks may be of limited value as an indicator of impending catastrophic disk failure.
Basically, empirical research has shown that the SAN storage vendors are screwing their customers every day of the week.
"Saving 47K on a SAN is great, unless it breaks 3 years from now"
Of course, saving 47K on a SAN means you can easily triple your redundancy, still save money, and when it breaks, you have two more copies.
At the same time, the guy spending the extra 47k on an 'Enterprise Class Ultra Reliable SAN', will get the same breakage 3 years from now, he wont have been able to afford all those redundant copies, and as he examines his contract with the SAN vendor, he notes that they actually dont promise anything.
"But by all means, get a rep from EMC or HP in so the decision makers completely understand what they're buying."
Premium grade bovine manure with (fake) gold flakes?
Really, handing the decision makers several scientific papers and a few google search strings would leave them much better equipped to make a rational decision.
Having several years experience with the kind of systems you're talking about I can just say, I've experienced several situations where, if we didnt have system-level redundancy, we would have suffered not only system downtime but actual data loss on expensive 'enterprise grade' SANs. That experience, as well as the research, has left me somewhat sceptical towards the claims of SAN vendors.
"what in the World does a common "everyman" need with that kind of storage?"
Consolidate your multimedia and run MythTV for a while. Once you rip and encode several TV series, all your DVD films, and have the Myth recording your favourite shows, a terabyte doesnt seem that much. If you want an idea for future examples of massive storage consumptions, imagine having MythTV recording all channels all the time, so you'd basically be able to decide post-transmission what you want to view and save...
Of course, while I agree most NAS and SAN solutions are grotesquely overpriced and mainly useful for separating fools from their money, I cant really see why one would bring up ZFS and OpenSolaris for this purpose. Something like Openfiler would be vastly more appropriate, proven and easy to manage.
"Since the problem seems to be the benzene part, I assume it's just as bad."
Perhaps. Looking over it a bit more it seems the occurrence of benzene is mostly caused by ascorbic acid (vitamin C) combined with benzoates and stored at relatively high temperatures over long periods, rather than the benzoates themselves (usually you'll combine it with citric acid when preserving, at least in most recipies I've seen). Naturally occuring benzoates, of course, carry no guarantee of being separate from vitamin C.
As such, I'd consider the article scaremongering and dishonest; for what it's worth, you could as well say 'vitamin C causes cancer', and blame apples and cranberries rather than soft-drinks.
Of course, it might still be a good idea to avoid drinking soft-drinks stored beyond expiration date in above room temperature (which I'd avoid anyway, and especially if it didn't have any preservatives). Or avoiding drinking soft-drinks at all. For a whole host of other reasons. But avoiding benzoates probably shouldnt be one of the more serious concerns.
"But it occurs only in trace amounts and people don't eat that much stone fruits"
Potassium bensoate, on the other hand, occurs naturally in _higher_ than approved FDA levels in some fruits.
The whole point of it is to use it as a preservative (even when naturally occuring, so the berries get eaten and the seed propagated rather than rotted and wasted), and the levels for effective anti-bacterial and fungicidal function doesnt change wether it's in a cranberry or a canned good.
Again, if it doesnt rot off the branch in a few days, it may very well contain at least as much potassium bensoate as any preserved goods.
I'd tend to consider this new scare 'alarmist' rather than 'alarming'.
Sodium benozate is one of the oldest additives known to man; it's naturally occuring in a whole host of fruit and berries (naturally occuring in combination with fruit acids it's a very good anti-bacterial and fungicidal agent, ie, anything that doesnt rot off the branch in a few days might very well contain it).
Preserving with it, as in adding either sodium benzoate, or adding fruit, berries or something else containing it to your canned homemade goods has been done since time immemorial.
Perhaps sodium benzoate carries some hard to determine long term risks, but avoiding it, and thus not eating a whole host of fruit and berries and exposing yourself to a whole host of fungus and bacteria will quite likely carry a whole lot more and much shorter term health risks.
As long as the winner-takes-all systems remain, and until the US gets proportional representation this wont change.
Of course, as the current system favours the incubent parties and is extremely beneficial to those who wish to buy a very small number of candidates the situation is unlikely to improve.
"What about an office in either USPTO or LOC that registers copyright holders?"
How about they also pay the dividends and collect the royalties? Instead of having to obtain permission, replace it with simply paying a mandatory reproduction fee as a percentage of obtained revenue.
Authors and artists wouldn't have to bother with the whole painful contract business that rarely has them in the strong position anyway, they could just register their copyright and they'd get paid as their work got distributed and sold, and the sales-points wouldnt have to worry about contract issues or obtaining permissions, they could just pay the fee and be in the clear.
"The existing system is clearly not flexible enough to deal with todays technology."
More like it's not flexible enough to deal with todays rate of communications, and the development of mankinds knowledge turning into a million small, trivial, and disclosed steps.
What makes the software sector special is the extremely low barrier of entry into the market, the massively componentized approach to development and the prevalence of use of modern communications and collaboration methods. This, however, does not mean that the same change isn't happening/can't happen in other sectors, nor that patents wont be as damaging and hinder progress as much there.
In fact, a realistic economic analysis of the investment patterns in the protected sectors strongly suggest a suboptimal use of capital, where much more is geared towards capitalizing on the monopoly of patents than in researching to gain more patents.
So while disqualifying software from patenting might be a useful start, restructuring the innovation incentive systems to actually reward useful research without causing the economic damage inherent in monopolies, extending across all sectors, would be much better in the long term. Because while I'd like to enjoy a future with software being continually improved, I might enjoy a future where we'd be getting five times the medical research for the same money we already spend today even more.
"The world still demands an occassional demonstration that you can be trusted to follow instructions, complete assignments, take pride in your own work."
Actually, in the case of writing papers I'd say the real world very much assigns such work to those employed to do it, and outsourcing/hiring consultants to write reports would often be an entirely appropriate way of producing such a thing (assuming, of course, you werent primarily employed to write such reports. In which case someone might be pissed off that you were outsourcing your work yourself before they could do it to you).
The point, tho, is that since it's become quite obvious that the production of a paper doesnt actually demonstrate the following of instructions, completition of assignments (well, arguably) or pride in work, perhaps it's time to change the assignment in such a way as to better actually demonstrate the necessary skills.
The educational establishment is far too lazy when it comes to adapting to the dizzying speed with which the methods of assimilation and dissemination of knowledge are changing today. No wonder the students get lazy when the schools are stuck using century old methods of evalution. A hundred years ago a term paper might have been a useful measurement. Today I wouldnt be surprised to find a perl script that could write one with options for the class...
Slashdot Mirror
"I respect their right to make a living by selling their productions."
I see few objecting to anyone making a living by selling their productions. I do see objections to anyone controlling what anyone else may produce.
Increasing Bill the Chairmakers ability to collect revenue by forbidding anyone else from making similar chairs isnt a sane free market policy. The fact that immaterial products are easier to copy doesnt change the basic premise just as the development of a chair-duplicator would suddenly make a chair monopoly a useful policy.
Intellectual 'property' is essentially a welfare system implemented as a feudal-style delegated taxation right. If we really want and need the incentive created by such a welfare system to we should at least have the intellectual honesty to call it what it is and run it under democratically controlled budgets and fiscal management to at least attempt to ensure the public gets its moneys worth. The system isnt free just because it's hidden in externalized economic flows, the costs are just less apparent. Nor would it be that hard to replace the horrendously inefficient monopoly pricing with simply taxing revenue derived from duplication of a work and handing the benefits directly to the creative talent originating the work, thus solving both the payment problem and the 'piracy' problem at once (your work gets duplicated and the copies sell, you automatically get your share of the collected revenue, and 'piracy' would simply become yet another tax-evasion issue if someone duplicates media for profit without paying the 'IP sales tax').
"Contrast to every other filesystem"
Well, except every other filesystem on LVM as snapshots have been a feature of LVM since, like, forever...
"If you are really worried about it, don't upgrade the OS for a while."
Or implement the functionality as distinct and separate replaceable layers. Small parts, each good at their own thing, combined to form a flexible and powerful whole. Reminds me of the traditional philiosophy of that old OS, what was it called...
"GPL and CDDL code can't be mixed due to GPL's restrictive nature."
You mean, the CDDL's restrictive nature. The main contention issues appear to be the CDDL's choice of venue restriction, and patent conflict auto-termination issue. IE, restrictions beyond the GPL.
As the GPL protects the freedom of the GPL protected derived code from the restrictions imposed by the CDDL, you can hardly say the GPL is the restrictive license...
'"Business doesn't like the GPL": true when they are on the receiving end, but false when they are on the giving end.'
I'd change that to "true when they are in the middle". Business on the recieving end _loves_ GPL code. It means they dont have to worry about a supplier going bellyup, it means they can change providers, it means they can hire outside help with the code, it means the software isnt going to fork into a bazillion proprietary incompatible versions and it means it's there long term, and that invested time and money isnt going to vanish.
It's the middlemen, who want to recieve freedom but not give it to anyone else who dont like the GPL.
That's something I can live with.
"This is partly why I've tried to convert my projects to BSD licenses. I have a substantial amount of code that I've written GPL"
As long as you're the copyright holder you can change the license when you wish. Or put your contributions to a GPL project under revised BSD or even in the public domain.
"its hard to remember who wrote what."
Ah, there's the rub. That's hardly the GPL's fault tho, is it? That's copyright law and your failure to do what copyright makes it necessary for you to do. Join the crowd and work for copyright abolition if you dont want to bother with that part.
"I don't feel comfortable using my own code because its GPL'd."
You dont feel comfortable using _their_ code because it's GPL you mean. You could have asked for copyright assignment if you wanted to accept the patches in that case. This is not a GPL problem, this is a situation you've put yourself in.
Of course, if the license were not the GPL, or you required copyright assignment, then maybe those contributors wouldn't have contributed. I sure know I wouldn't contribute anything non-trivial under a non-copyleft (preferably GPL) license.
"BSD licensing is the way to go, imo."
Nah, seen too much BSD code get proprietarized and used to screw end users. Not with my code they dont. They can write it all on their own if they want power over others that bad.
'So returning a "new and wonderfull" error code'
Actually, I was thinking more about messing around with perror and the human readable versions (that are translated and such). Of course, it might not be possible to intercept and add code to perror, but if anything could, that would be something as intrusive as SELinux or other MAC layers, as intercepting system calls is their main territory.
"What most people forget is that you can set SELinux to be permissive"
Unfortunately, there's also a whole bunch of people who naively thought permissive mode would only log and not interfere with anything, spent two days troubleshooting some problem, finally _disabled_ SELinux and had it work perfectly from the default two days ago.
I'm sure there were perfectly logical reasons for it to happen, but it's that kind of random, seemingly inexplicable and above all, unlogged problems that turn people off of MAC security. It's not unique to SELinux, I've seen the same kind of crap on other systems like eTrust.
And unfortunately, once you start distrusting the security software (and it doesnt take many instances of such failures), the first line of debugging always becomes - shut it off, shut it off completely and utterly, because I'm not wasting my time again.
"I think part of this problem is that previously there has been no easy way to look as SELinux messages and manage the policies."
I'd say it's the the most important part of the problem. For some reason, designers of these kinds of softwares tend to act as if it's a wholly separate part of the system, with the common result that they're signalling errors in encrypted morse code on a LED on the dark side of the moon. There are standard ways to signal system errors, standard header files defining system messages, and many programs use these facilities to signal what was wrong (such as permission denied). It would be far more acceptable if these were used, and a program would signal 'Permission denied by MAC policy', which would give an easy way to know what to fix.
With those pronounciation rules, I sense a certain irony in the pronounciation of FCC.
"Vista likes RAM for the simple fact that it scales extra RAM beyond application/OS usage and standard caching."
That's mainly noticable for those of us who more or less never turn their systems off or reboot, and it's been that way for a long time now.
Personally I cant say I'm complaining about the DRAM market saturation tho, as I run diskless workstations served over iSCSI and Xenified servers, the DRAM prices make me go all fuzzy.
"If G.W.Bush thinks he can overcome a full fledged russian nuclear strike, he is even more of a nutcase than Putin."
Putin may be a nasty customer, but I dont doubt for a second that GWB is far more of a nutcase than Putin is.
And IMO, that's where the problem is. It doesnt really matter if US interceptor bases in Europe stands a realistic chance against a Russian launch or not; it's enough that Bush or some other nutcase on the US throne thinks it may stand a chance. And with the aid of GOD they WILL be shot DOWN!
Bush has repeatedly shown that he will not listen to either real intelligence or military advise, so why would he listen if the military says the bases wont defend against Russia (especially if they secretly put in a few more and better interceptors, after all, our pals in the defense industry promised these were really great and we paid a lot for them)?
Russia is left with no choice but to ensure that in no way, no how, can these bases be in any way, even with the help of GOD, ever be imagined to be capable of shooting down a Russian strike. Or they risk that some current or future utterly deranged administration may think they'll profit from another oil crisis, small scale armed attack, etc, whatever a far gone US administration can imagine to be profitable as long as they do not risk a retaliatory strike.
It's Dr. Strangelove all over again. What good is a doomsday device if you dont tell the world about it? It's not enough that you _can_ screw the other guy, the other guy has to _know_ you'll screw him. If he thinks, even in his raving delusional psychosis, that he can get away with it, the deterrent just isnt enough.
"I could point you at dozens of 'dead end' Linux distros."
Distros are a bit different tho, they are usually not under the GPL as a whole. But for the parts that are, improvements and changes can be merged into main branches, even if the offshoot dies.
"There is no antidote to the end of software development projects"
As long as the source is available there is no end to the project. There may be a hiatus or a lack of progress, but Free sources do not die the way proprietary codebases do.
"It scares the HELL out of me to think that the only thing left might someday be Linux, or some GPL-bound codebase."
It doesnt scare me the same way having only proprietary codebases would. It would be boring and not a good idea from an idea-evolutionary point of view tho.
As a whole tho, I'd prefer the abolition of copyright as a monopoly right and replacing it revenue rights/incentive rights instead, which would bypass the whole issue.
"I couldn't be so certain if I were staring at the screen of a display attached to a Tivo device, it seems."
Indeed. An update can turn your Tivo off permanently. And you do not have the cryptographic keys needed to make it work again. Which is one thing the GPL v3 tries to address.
"I'd like to have somebody draw up for me the big bloody flow diagram of 'failed' BSD systems."
There's a fairly good one (which includes most unixes, both successful and otherwise (it lacks some tho, DG/UX is one I've worked with which I note is not there)) at http://www.levenez.com/unix/.
"GPL 3 type tactics merely encourage companies to reinvent the wheel,"
You mean, encourage companies _who do not want to share back_ to reinvent the wheel.
When they are free to proprietarize the open code, then _everyone else_ has to reinvent the wheel. Take a look at the vast horde of failed or utterly changed BSD based proprietary unixes over the last two decades.
Copylefts minimize the duplication of effort by ensuring that all effort cooperatively survives and evolves; allowing proprietary offshoots merely raises the baseline off which the duplication and NIH syndrome starts.
"It squeezes the middle between the hobbyists at one end and the big companies at the other."
Again, the last two decades indicate otherwise. I see few small to midsize BSD companies these days; the main winners seem to be the large companies. Which fits well when you have a joint baseline; the large companies can throw more resources on building above the baseline than the small, and as they dont have to give back, the smaller ones will have a hard time competing in the next round.
"While it suggests (even states) there is no significant difference between disk types their conclusions are not supported by any scientific methodology or even base consistancy."
IMO, the methodology is useful, as long as it's clearly stated. Running a statistically significant test under controlled environmental and operating conditions would be prohibitively expensive and difficult to accomplish. While the operating conditions may vary, as long as they are within reasonable parameters (ie, operating ranges stated by vendor), and the statistical distribution is fairly even, it serves the purpose for the test (and, I'd suggest that conditions would tend to be skewed towards expensive disks being better taken care of).
"This makes this paper far more dangerous than marketing material, where at least you can go back to the vendor for some accountability."
I'd be much more confident in disk vendors accountability if it werent for the IBM deathstar incident.
And, you know, the vendors do have the data themselves. Still, I have yet to see one actually publish it. Which rather makes me less inclined to trust them.
Still, I wouldn't present the paper to execs without making sure they understood the method with which the raw data was obtained.
"use to companies that are not google."
Yes, the problem with Googles report is that it's geared towards a highly redundant infrastructure where they can live with disks crapping out regularly. However, that infrastructure is also built to provide the best price/performance ratio, and more companies would be better off going with cheap high redundancy rather than expensive, exclusive and at best only slightly more reliable hardware.
"I do not want to have 3 copies of each important machine just to save $47000 per system (as if)."
I'd suggest you're reading things into what I'm saying. Like the article we're talking about, I'm not saying you should stick local disk and triple your machine park.
I'm saying you'd be better off with COTS SATA arrays shared over iSCSI over dedicated redundant gigabit (or 10GB) ethernet. With mirroring, backups and/or rsynced/revisioned data.
"fail to appreciate the environments and demands in which a SAN is a perfectly justifiable, cost efficient solution."
I've worked in such environments for ten years. I've worked with such SANS. In my experience their failure rate is vastly higher than COTS hardware. Not because they get disk or hardware failures, but because their complexity and relative rarity has the whole infrastructure riddled with buggy firmwares, crap drivers, random incompatiblity and inexperienced 'certified' service technicians.
Which means you cant rely on the storage anyway and have to use host level mirroring to cope with relatively frequent SAN failures and/or maintenance (to be fair, the last few years have seen improvements, but it still aint there, and the consumer hardware just keeps getting "there" faster). Which means you could just as well be using less expensive COTS solutions.
Migrating from local disk to SAN promised to save time on storage maintenance work. It hasnt. The sysadmins may not be replacing disks anymore (which the vendors or "disk-monkeys" usually did anyway) but now they have to work on SAN storage migrations, remirroring systems after maintenance, remirroring systems after SAN failures, dealing with substandard drivers, etc. As a whole I'd say far more time is spent on storage with SAN attached systems than the non-SAN attached systems. And to top that off, you usually get storage delivery times that are several times more than what it'd take to buy COTS disk and shove it in yourself. And prices that are orders of magnitude higher than the COTS disk.
SAN vendor costs are not justifiable, but not because they're high priced. They're not justifiable because they dont deliver what they promise. That means if you replace them with a solution that delivers what a SAN _actually_ delivers (as opposed to what they promise), you'd get a far cheaper solution.
You know, all of a sudden I gain a whole new understanding of why some women willingly wear a burka.
I can see a whole new fashion genre being driven by our emerging everpresent surveillance and recording. When will ThinkGeek get a 'privacy enhanced clothing' section?
"Additionally, SATA drives are not as reliable long term as SCSI."
The CMU study by Bianca Schroeder and Garth A. Gibson would suggest otherwise. In fact, there was no significant difference in replacement rates between SCSI, FC, or SATA drives.
"They want the system to phone home when a drive starts getting errors"
Of course, the other recent study by Google showed that predictive health checks may be of limited value as an indicator of impending catastrophic disk failure.
Basically, empirical research has shown that the SAN storage vendors are screwing their customers every day of the week.
"Saving 47K on a SAN is great, unless it breaks 3 years from now"
Of course, saving 47K on a SAN means you can easily triple your redundancy, still save money, and when it breaks, you have two more copies.
At the same time, the guy spending the extra 47k on an 'Enterprise Class Ultra Reliable SAN', will get the same breakage 3 years from now, he wont have been able to afford all those redundant copies, and as he examines his contract with the SAN vendor, he notes that they actually dont promise anything.
"But by all means, get a rep from EMC or HP in so the decision makers completely understand what they're buying."
Premium grade bovine manure with (fake) gold flakes?
Really, handing the decision makers several scientific papers and a few google search strings would leave them much better equipped to make a rational decision.
Having several years experience with the kind of systems you're talking about I can just say, I've experienced several situations where, if we didnt have system-level redundancy, we would have suffered not only system downtime but actual data loss on expensive 'enterprise grade' SANs. That experience, as well as the research, has left me somewhat sceptical towards the claims of SAN vendors.
Consolidate your multimedia and run MythTV for a while. Once you rip and encode several TV series, all your DVD films, and have the Myth recording your favourite shows, a terabyte doesnt seem that much. If you want an idea for future examples of massive storage consumptions, imagine having MythTV recording all channels all the time, so you'd basically be able to decide post-transmission what you want to view and save...
Of course, while I agree most NAS and SAN solutions are grotesquely overpriced and mainly useful for separating fools from their money, I cant really see why one would bring up ZFS and OpenSolaris for this purpose. Something like Openfiler would be vastly more appropriate, proven and easy to manage.
"Since the problem seems to be the benzene part, I assume it's just as bad."
Perhaps. Looking over it a bit more it seems the occurrence of benzene is mostly caused by ascorbic acid (vitamin C) combined with benzoates and stored at relatively high temperatures over long periods, rather than the benzoates themselves (usually you'll combine it with citric acid when preserving, at least in most recipies I've seen). Naturally occuring benzoates, of course, carry no guarantee of being separate from vitamin C.
As such, I'd consider the article scaremongering and dishonest; for what it's worth, you could as well say 'vitamin C causes cancer', and blame apples and cranberries rather than soft-drinks.
Of course, it might still be a good idea to avoid drinking soft-drinks stored beyond expiration date in above room temperature (which I'd avoid anyway, and especially if it didn't have any preservatives). Or avoiding drinking soft-drinks at all. For a whole host of other reasons. But avoiding benzoates probably shouldnt be one of the more serious concerns.
"But it occurs only in trace amounts and people don't eat that much stone fruits"
Potassium bensoate, on the other hand, occurs naturally in _higher_ than approved FDA levels in some fruits.
The whole point of it is to use it as a preservative (even when naturally occuring, so the berries get eaten and the seed propagated rather than rotted and wasted), and the levels for effective anti-bacterial and fungicidal function doesnt change wether it's in a cranberry or a canned good.
Again, if it doesnt rot off the branch in a few days, it may very well contain at least as much potassium bensoate as any preserved goods.
I'd tend to consider this new scare 'alarmist' rather than 'alarming'.
Sodium benozate is one of the oldest additives known to man; it's naturally occuring in a whole host of fruit and berries (naturally occuring in combination with fruit acids it's a very good anti-bacterial and fungicidal agent, ie, anything that doesnt rot off the branch in a few days might very well contain it).
Preserving with it, as in adding either sodium benzoate, or adding fruit, berries or something else containing it to your canned homemade goods has been done since time immemorial.
Perhaps sodium benzoate carries some hard to determine long term risks, but avoiding it, and thus not eating a whole host of fruit and berries and exposing yourself to a whole host of fungus and bacteria will quite likely carry a whole lot more and much shorter term health risks.
As long as the winner-takes-all systems remain, and until the US gets proportional representation this wont change.
Of course, as the current system favours the incubent parties and is extremely beneficial to those who wish to buy a very small number of candidates the situation is unlikely to improve.
"What about an office in either USPTO or LOC that registers copyright holders?"
How about they also pay the dividends and collect the royalties? Instead of having to obtain permission, replace it with simply paying a mandatory reproduction fee as a percentage of obtained revenue.
Authors and artists wouldn't have to bother with the whole painful contract business that rarely has them in the strong position anyway, they could just register their copyright and they'd get paid as their work got distributed and sold, and the sales-points wouldnt have to worry about contract issues or obtaining permissions, they could just pay the fee and be in the clear.
"The existing system is clearly not flexible enough to deal with todays technology."
More like it's not flexible enough to deal with todays rate of communications, and the development of mankinds knowledge turning into a million small, trivial, and disclosed steps.
What makes the software sector special is the extremely low barrier of entry into the market, the massively componentized approach to development and the prevalence of use of modern communications and collaboration methods. This, however, does not mean that the same change isn't happening/can't happen in other sectors, nor that patents wont be as damaging and hinder progress as much there.
In fact, a realistic economic analysis of the investment patterns in the protected sectors strongly suggest a suboptimal use of capital, where much more is geared towards capitalizing on the monopoly of patents than in researching to gain more patents.
So while disqualifying software from patenting might be a useful start, restructuring the innovation incentive systems to actually reward useful research without causing the economic damage inherent in monopolies, extending across all sectors, would be much better in the long term. Because while I'd like to enjoy a future with software being continually improved, I might enjoy a future where we'd be getting five times the medical research for the same money we already spend today even more.
"The world still demands an occassional demonstration that you can be trusted to follow instructions, complete assignments, take pride in your own work."
Actually, in the case of writing papers I'd say the real world very much assigns such work to those employed to do it, and outsourcing/hiring consultants to write reports would often be an entirely appropriate way of producing such a thing (assuming, of course, you werent primarily employed to write such reports. In which case someone might be pissed off that you were outsourcing your work yourself before they could do it to you).
The point, tho, is that since it's become quite obvious that the production of a paper doesnt actually demonstrate the following of instructions, completition of assignments (well, arguably) or pride in work, perhaps it's time to change the assignment in such a way as to better actually demonstrate the necessary skills.
The educational establishment is far too lazy when it comes to adapting to the dizzying speed with which the methods of assimilation and dissemination of knowledge are changing today. No wonder the students get lazy when the schools are stuck using century old methods of evalution. A hundred years ago a term paper might have been a useful measurement. Today I wouldnt be surprised to find a perl script that could write one with options for the class...