people who drive a little will continue to drive a little with this insurance or not
The CO2 savings is supposed to come from those who will subsequently drive less to save insurance cost. You didn't really miss that, did you?
I'm all for this. Tax by the mile as well. I'd rather this green tyranny hit the broadest spectrum of voters than be amortized out sight by some federal level "cap and trade" scheme the common blockbuster patron will never encounter directly.
Not that we won't end up with both. Enjoy saving the planet, or something.
Ambiguous results. Naturally "they" confuse the results by suggesting that energy extracted offsets the energy increase caused by global warming, thus a small net change and happy bunnies everywhere.
My guess: pulling tens of terawatts of energy out of the atmosphere will effect the climate.
Call it Atmospheric Thermal Depletion, and credit me.:)
I see discrete Ethernet phys, VGA, USB, etc.; all the horrible stuff blades are supposed to consolidate away. Turns out all the proprietary silicon, software and exotic backplanes necessary to make that real costs too much and is creepy.
And you can quit calling it "cloud" now... they're just hosting providers and you know it.
Please try not to leave behind useful features. Yes, misfeatures should be abandoned. Sometimes mere obsolescence can move a feature into the misfeature column. However, merely uncommon or obscure != "mis". It requires a pragmatic grownup to detect the difference.
The feature set begins with BIND 9. Too many major revisions of fundamental systems fail to achieve feature parity and long after the "new" is production solid the user base remains stratified into the (neglected) old and the (indifferent) new.
You must know that after the (entirely reasonable) half decade is spent to produce 10 it will take years to migrate the majority of the user base. The justifiably conservative nature of the BIND user base is such that dropped functionality will retard adoption dramatically. Better to provide parity with BIND 9's feature set and remove one excuse to sit on 9 till 2020.
Put it on the list of goals, near the top; "Feature Parity with BIND 9". Make it clear that the user base can take this for granted; if BIND 9 can do it, BIND 10 can do it.
I think you'll find if not a lot more support, at least less resistance. I know you will cut the migration period dramatically.
17 days ago STS-125, the forth in-orbit service of Hubble, ended successfully 12 days ago Gov. Schwarzenegger dedicated the largest laser on Earth to fusion research Last week the DOE produced video of a potential carbon nanotube memory device in operation. 3 days from now 7 people will blast into orbit, rendezvous with the ISS and further the construction of a giant orbital laboratory.
No government in history has ever, is now, or will ever again (post dollar collapse) facilitate as much raw research as the US federal government.
Or did someone in the entertainment industry worry that using Ethernet for connecting entertainment devices would make it too easy for those evil hacker types to connect a computer to the setup and break their DRM?
Forgive me; I'm going to offer something other than 0MG iT'5 Ev1L DEE-ARE-EM zors.
Ethernet is slow. 10Gbit Ethernet is still exotic and costly. Gigabit Ethernet is much too slow for digital video, and gigabit phys cost more than what high volume TV manufactures will tolerate. An HDMI phy manufactured in 2003 sources or sinks 4.9Gbit/s. Two subsequent revisions have doubled this twice to 10Gbit and then 20Gbit. Basically HDMI provides an order of magnitude more bandwidth than the sort of common Ethernet you have in mind. Uncompressed digital video and audio (what HDMI does) requires emense bandwidth.
Ethernet is designed for the LAN use case. Consider the magic 300m minimum distance copper Ethernet is built around. This distance is desirable because it covers a large percentage of facilities where LANs exist without additional infrastructure. Among other things, signal frequency and copper (read cheap) cable construction are both bound by this. HDMI has no such requirement and thus does not incur the cost to achieve it.
HDMI clearly distinguishes between sources and sinks and has different expectations of each. Your digital TV will never suddenly begin transmitting Gbits of data someone will wish to render. It is exclusively a sink. Ethernet doesn't make provision for this sort of asymmetry which means both ends are peers and both suffer a certain minimum amount of complexity (read cost) because of it.
Ethernet is overly robust for digital TV. There are no packet collisions between your cable box and your TV. While HDMI does provide for error detection and correction, the remedy is radically different than what occurs on a LAN (retransmission usually.) The bad data is just spaced. The moment has passed and whatever pixel(s) or audio samples were corrupted are replaced by new bits before you perceive it (hopefully.) Here is some language from HDMI 1.3, 7.7:
The behavior of the Sink after detecting an error is implementation-dependent. However, Sinks should be designed to prevent loud spurious noises from being generated due to errors. Sample repetition and interpolation are well known concealment techniques and are recommended.
You wouldn't need to read many IEEE 802.whatever documents see just how far computer networking is from the design of HDMI. It is an entirely distinct use case.
Finally, HDMI provides timing guarantees that are totally absent in Ethernet. Devices are made cheaper through accurate timing (your TV doesn't need a larger high speed buffer for instance.) Recently so-called "Data Center Ethernet" has emerged to address this so that Ethernet can be used in latency sensitive applications. HDMI had this baked-in on day #1.
Some people are convinced that DRM is the only concievable reason for creating HDMI and all other claims offered are a smokescreen. That's the fashion around Slashdot, anyhow. Don't believe it. Those folks don't know what digital TV is.
Fork, then announce it on Slashdot. Or is it obvious that this wouldn't be taken seriously? Hmm. Think hard about why you feel that way. Seeking affirmation from John Q. Geek for your fork is not how this has been done. Perhaps there is a reason.
I imagine that from the perspective of the Wine developer community what you've just done is set the drama fan to 11 and fire a giant shit cannon at it. You playing politics by leveraging whatever pressure you can gin up. That behavior, by itself, puts me on whatever side of the fence you're not.
Fork. If anyone notices and follows then good for you. Otherwise STFU.
'Adverse commercial agenda'... How much thought did you put into those weasel words before you hit submit?
How fast are they going relative to some arbitrarily fixed point in the universe?
I am also manipulating a soda container at 552 km/s (1.23M mph), relative to the CMB rest frame. Most highly trained soda operators are capable of this.
A repeat of that, and also a repeat of the GCC/EGCS fork. This isn't the first major fork in FOSS history and it won't be the last. Both the Xfree86/Xorg and GCC/EGCS forks resulted in improvements to the progress and maintenance of these systems/tools.
Perhaps another glibc fork is overdue. Remember that the GNU C library that Ulrich is paid by Redhat to maintain was, for a long time, forked by Linux kernel developers. Consider also that there are already at least 5 alternative C library implementations (Bionic, dietlibc, uClibc, Newlib, Klibc) for Linux, all revolving around the embedded use case. Is it any wonder this fork pre-appends E for embedded as a name? Embedded Linux is absolutely crucial to the future of Linux generally; Linux has its foot in the door of many institutions because it's easy to embed.
There is no actual technical reason (including performance regressions) a C library implementation need be exlusively 'embedded' or not. It certainly makes development more difficult as more conditions appear in the source and the build system gets more complex. C library developers/maintainers should be capable of dealing with that degree of complexity. Lightweights need not apply.
By its nature a C library must contend with so many architectures and use cases that no one developer can possibly encompass all the required knowledge. Perhaps having a prima donna like Ulrich play gate keeper is not optimal.
It's a nice little sekret that even many reasonably knowledgeable people don't know about and those who do don't want it popularized. I don't care if a couple adds show up on NoScript's site, particularly if that means it remains free and updates continue. Stop talking about it.
You had Microsoft convinced that you felt burdened by having to explicitly command your machine to act on media. Microsoft believed you perceived operating systems that failed to automatically engage new media as somehow less sophisticated or friendly. You complained when required to perform any number of minor steps to begin utilizing your media, and you were happy when arbitrary programs were automatically launched to consume arbitrary content with no effort on your part.
You had to be dragged over the coals of malware to learn that this naivety is painful. You had to be fleeced by keyloggers and had your careers ruined by worms. Billions had to be pissed away before you got it. Now that you appear to have acquired clues sufficient to overcome your obstinacy, Microsoft now perceives that you will not throw a fit when inserting a flash drive doesn't automatically launch hundreds of megs of software. Congratulations!
* Those of you that put in the effort to discover, document and apply the various registry hacks, group policy modifications and other various and sundry non-default bullshit to prevent autorun are excluded, of course. Those of you who propagated this insanity to the Gnome/KDE/et al. environments can eat a dick. Get busy and take it out (for read-only media as well, thank you) now that you've been shown the way by the only influence you appear to recognize.
Agreed. Patently obvious to me as well. Wouldn't even require any public 'investment'; just give rail operators easier right of way and they'll replace 95% of the trucking industry with no further help.
Whatever. Out here in flyover country we're guaranteed not to see a dime of Obama's 'rail' money. Do whatever you want with your scrip printers. Print more. Hurry. Bring this happy horseshit to it's knees so it can be dealt with it once and for all.
For the DHS line eater: Taxes. 2nd Amendment. Waco. Ruby Ridge. Janet Reno. Janet Napolitano. Teabag. 30 Rounds. Crazy veterans. Fuck you.
Anyone who thinks concatenation is a good thing, much less better than striping...
Concatenation, by itself, would certainly be unwise. I'll give Exchange admins the benefit of the doubt and assume this "concatenation" is in addition to whatever redundancy features are provided.
From the story:
JBOD support lets you concatenate disks rather than stripe them into a redundant array
I find that statement confusing. Why is Exchange, a mail server/collaboration platform/etc., managing storage devices? Is the story conflating Windows Server 2008 features with Exchange, or is Exchange directly responsible for storage devices (like Oracle ASM)?
No, "they" said nothing about that meaningless debate. Administrations generally don't design rockets in the federal budget.
Prediction: the heavy lift Ares V or its moral equivalent (Ares IV, DIRECT, yada yada...) will never be built. I will refer back to this in half a decade and you will acknowledge my brilliance.
The new budget commits only to Orion and it's launch vehicle (Ares I). That's the bare minimum necessary to replace the Shuttle in its LEO ISS crew transport and resupply role. Finishing Orion and Ares I is the politically easy thing to do because without it Obama would have to explain the end of US manned space flight, which is politically difficult.
Ares V, on the other hand, is several years down the road and a much bigger commitment. What's been done to-date can be dropped and quietly swept under the rug. It's not a 2012 issue and after that it doesn't matter, just as long as the NEA gets its dough.
This is McNealy quoting an unnamed "federal official" regarding an unnamed project at some arbitrary point in the past. Feel free to go all pretzel like over it if you wish, but it seems far more likely to me that any lack of progress "open source" (however McNealy defines that...) has made is more likely due to cozy relationships between politicians their favorite vendors than the ideological hang-ups of some bureaucrat.
I've developed software as a DOD contractor. It's a very big government so I can't claim to speak for every case, but my experience was that the DOD doesn't give a flying **** what licenses are involved in their systems. They want it Tuesday. Right, wrong, whatever... Tuesday.
But hey, it's Friday and beating up on fictional government merchantilists is fun.
doesn't actually do anything. See the relevent code here.
More importantly, kernel developers believe the drop_caches mechanism to be unsafe. It is a hack to permit easy benchmarking and other testing.
I must agree with the the GP; Linux VM behavior has been and continues to be poor. I particularly dislike the way inactive code pages are removed to buffer IO when there is clearly no reason to do so. You suffer this every time you copy a large file.
Linux is, indeed, based on what is now a very old paradigm - approaching half a century. Concepts have advanced since
No, actually, concepts have not advanced. The hardware is larger and faster, but from the perspective of software the design of any modern OS, from PDA to supercomputer, is entirely familiar to anyone that wrote system software for an IBM 360-67 (virtual memory and 32 bit addressing) as early as 1966. With the possible exception of extraordinarily high real concurrency (and some of its consequences such as STM) everything we see today was present and fully exploited by software in those systems.
The fact that it didn't take very long to produce software designs sufficient to fully exploit the hardware doesn't mean the software is designed incorrectly. It just means the problem space isn't that complex. There are many research operating systems for the same reason; they're not hard to make.
A prime example is the notion of "restarting" a computer. Why, these days...
Damage accumulates. Resource leaks, fragmentation, failed subsystems that aren't designed to restart without power cycle, cosmic rays, etc. All of these "concepts" are ancient and unchanged. They won't be changing for the foreseeable future.
Solutions to these problems exist but remain expensive and imply limitations on the resulting product that confines their application to highly vertical and/or costly systems. The general purpose, inexpensive systems on which you expect to run practically any trash you might throw at it do not meet that standard. They could be made to at the cost of becoming unaffordable. You would also find the inflexibility of a rigorously reliable system intolerable for a personal, general purpose use.
You're the reason, in other words.
Is it possible that some new OS design can reduce the costs? I don't know. What I do know is that the ideas behind Phantom OS have been tried before, and you and I are still running 30-40 year old designs to read about the many attempts.
The concept of "files" is archaic
The concept of a named persistent sequence of data is not going away no matter what you call it or how many abstractions you pile on top. If the word "file" is too prosaic feel free to employ the "document" euphemism.
Where the **** are my mod points when I need them.
You want to 'protect' American jobs? Get your savior to fulfill his campaign promises to the unions and stand up to Europe, Asia and the rest and start restricting and/or banning imports. Renegotiate NAFTA.
If you do it right host names don't matter. The important thing is Service names.
Server foo.bar.com may host HTTP proxies, mail, NFS shares or whatever. Create CNAMES for the services. Never expose the "foo" name for public services. ftp.bar.com may then move freely without being tied to some specific host.
Number the service names. Almost any non-trivial service will need to be duplicated if your organization grows. ftp.bar.com should be ftp01.bar.com, because there will eventually need to be an ftp02.
Host names can be made to reflect geography. This is helpful in large organizations. jane.boston-colo-01.bar.com. You've separated the service names from the host names, so none of that administratively helpful geographical noise is exposed to the public.
Do these three things and you've solved 98% of the problem. The rest won't be suffered long enough to worry about before someone else takes over and reorganizes the whole shebang anyhow.
Now that you've liberated the service names from the host names feel free to employ whatever amusing server naming scheme you wish. I find dictator names are fun; stalin, chavez, pinochet, etc. The shorter the better.
If CERN leaves the window open long enough by failing to produce real collisions in the LHC that don't destroy the planet the alarmists WILL achieve their goals and get it shut down. Have no doubt. Politicians of all stripes thrive on alarmist nonsense. This 'story' is exactly the sort of double-speak that can lend just enough credibility to the alarmist argument to get the ball rolling.
Slashdot Mirror
people who drive a little will continue to drive a little with this insurance or not
The CO2 savings is supposed to come from those who will subsequently drive less to save insurance cost. You didn't really miss that, did you?
I'm all for this. Tax by the mile as well. I'd rather this green tyranny hit the broadest spectrum of voters than be amortized out sight by some federal level "cap and trade" scheme the common blockbuster patron will never encounter directly.
Not that we won't end up with both. Enjoy saving the planet, or something.
amazon + Bletchley = 2791
It registers fine.
isc 0x009811009211521 AK
safety campaigners fear there's little to stop the television being used at the wheel
Silly safety campaigners... don't they know we're too busy texting on our mobile phones while driving to watch TV?
2004 NIH study on this: http://www.pubmedcentral.nih.gov/articlerender.fcgi?artid=526278
Ambiguous results. Naturally "they" confuse the results by suggesting that energy extracted offsets the energy increase caused by global warming, thus a small net change and happy bunnies everywhere.
My guess: pulling tens of terawatts of energy out of the atmosphere will effect the climate.
Call it Atmospheric Thermal Depletion, and credit me. :)
Stimulus....package
Too easy. (not hard?)
STOP NOW!
The new 'blade'; 19" wide and 1.75" tall.
I see discrete Ethernet phys, VGA, USB, etc.; all the horrible stuff blades are supposed to consolidate away. Turns out all the proprietary silicon, software and exotic backplanes necessary to make that real costs too much and is creepy.
And you can quit calling it "cloud" now... they're just hosting providers and you know it.
Please try not to leave behind useful features. Yes, misfeatures should be abandoned. Sometimes mere obsolescence can move a feature into the misfeature column. However, merely uncommon or obscure != "mis". It requires a pragmatic grownup to detect the difference.
The feature set begins with BIND 9. Too many major revisions of fundamental systems fail to achieve feature parity and long after the "new" is production solid the user base remains stratified into the (neglected) old and the (indifferent) new.
You must know that after the (entirely reasonable) half decade is spent to produce 10 it will take years to migrate the majority of the user base. The justifiably conservative nature of the BIND user base is such that dropped functionality will retard adoption dramatically. Better to provide parity with BIND 9's feature set and remove one excuse to sit on 9 till 2020.
Put it on the list of goals, near the top; "Feature Parity with BIND 9". Make it clear that the user base can take this for granted; if BIND 9 can do it, BIND 10 can do it.
I think you'll find if not a lot more support, at least less resistance. I know you will cut the migration period dramatically.
17 days ago STS-125, the forth in-orbit service of Hubble, ended successfully
12 days ago Gov. Schwarzenegger dedicated the largest laser on Earth to fusion research
Last week the DOE produced video of a potential carbon nanotube memory device in operation.
3 days from now 7 people will blast into orbit, rendezvous with the ISS and further the construction of a giant orbital laboratory.
No government in history has ever, is now, or will ever again (post dollar collapse) facilitate as much raw research as the US federal government.
Just STFU please. Thanks.
Or did someone in the entertainment industry worry that using Ethernet for connecting entertainment devices would make it too easy for those evil hacker types to connect a computer to the setup and break their DRM?
Forgive me; I'm going to offer something other than 0MG iT'5 Ev1L DEE-ARE-EM zors.
Ethernet is slow. 10Gbit Ethernet is still exotic and costly. Gigabit Ethernet is much too slow for digital video, and gigabit phys cost more than what high volume TV manufactures will tolerate. An HDMI phy manufactured in 2003 sources or sinks 4.9Gbit/s. Two subsequent revisions have doubled this twice to 10Gbit and then 20Gbit. Basically HDMI provides an order of magnitude more bandwidth than the sort of common Ethernet you have in mind. Uncompressed digital video and audio (what HDMI does) requires emense bandwidth.
Ethernet is designed for the LAN use case. Consider the magic 300m minimum distance copper Ethernet is built around. This distance is desirable because it covers a large percentage of facilities where LANs exist without additional infrastructure. Among other things, signal frequency and copper (read cheap) cable construction are both bound by this. HDMI has no such requirement and thus does not incur the cost to achieve it.
HDMI clearly distinguishes between sources and sinks and has different expectations of each. Your digital TV will never suddenly begin transmitting Gbits of data someone will wish to render. It is exclusively a sink. Ethernet doesn't make provision for this sort of asymmetry which means both ends are peers and both suffer a certain minimum amount of complexity (read cost) because of it.
Ethernet is overly robust for digital TV. There are no packet collisions between your cable box and your TV. While HDMI does provide for error detection and correction, the remedy is radically different than what occurs on a LAN (retransmission usually.) The bad data is just spaced. The moment has passed and whatever pixel(s) or audio samples were corrupted are replaced by new bits before you perceive it (hopefully.) Here is some language from HDMI 1.3, 7.7:
The behavior of the Sink after detecting an error is implementation-dependent. However, Sinks
should be designed to prevent loud spurious noises from being generated due to errors. Sample
repetition and interpolation are well known concealment techniques and are recommended.
You wouldn't need to read many IEEE 802.whatever documents see just how far computer networking is from the design of HDMI. It is an entirely distinct use case.
Finally, HDMI provides timing guarantees that are totally absent in Ethernet. Devices are made cheaper through accurate timing (your TV doesn't need a larger high speed buffer for instance.) Recently so-called "Data Center Ethernet" has emerged to address this so that Ethernet can be used in latency sensitive applications. HDMI had this baked-in on day #1.
Some people are convinced that DRM is the only concievable reason for creating HDMI and all other claims offered are a smokescreen. That's the fashion around Slashdot, anyhow. Don't believe it. Those folks don't know what digital TV is.
Fork, then announce it on Slashdot. Or is it obvious that this wouldn't be taken seriously? Hmm. Think hard about why you feel that way. Seeking affirmation from John Q. Geek for your fork is not how this has been done. Perhaps there is a reason.
I imagine that from the perspective of the Wine developer community what you've just done is set the drama fan to 11 and fire a giant shit cannon at it. You playing politics by leveraging whatever pressure you can gin up. That behavior, by itself, puts me on whatever side of the fence you're not.
Fork. If anyone notices and follows then good for you. Otherwise STFU.
'Adverse commercial agenda'... How much thought did you put into those weasel words before you hit submit?
2004 called; they want their Java 'ecosystem' back.
How fast are they going relative to some arbitrarily fixed point in the universe?
I am also manipulating a soda container at 552 km/s (1.23M mph), relative to the CMB rest frame. Most highly trained soda operators are capable of this.
a repeat of the whole xfree86/x.org thing ?
A repeat of that, and also a repeat of the GCC/EGCS fork. This isn't the first major fork in FOSS history and it won't be the last. Both the Xfree86/Xorg and GCC/EGCS forks resulted in improvements to the progress and maintenance of these systems/tools.
Perhaps another glibc fork is overdue. Remember that the GNU C library that Ulrich is paid by Redhat to maintain was, for a long time, forked by Linux kernel developers. Consider also that there are already at least 5 alternative C library implementations (Bionic, dietlibc, uClibc, Newlib, Klibc) for Linux, all revolving around the embedded use case. Is it any wonder this fork pre-appends E for embedded as a name? Embedded Linux is absolutely crucial to the future of Linux generally; Linux has its foot in the door of many institutions because it's easy to embed.
There is no actual technical reason (including performance regressions) a C library implementation need be exlusively 'embedded' or not. It certainly makes development more difficult as more conditions appear in the source and the build system gets more complex. C library developers/maintainers should be capable of dealing with that degree of complexity. Lightweights need not apply.
By its nature a C library must contend with so many architectures and use cases that no one developer can possibly encompass all the required knowledge. Perhaps having a prima donna like Ulrich play gate keeper is not optimal.
Don't talk about NoScript, damn it.
It's a nice little sekret that even many reasonably knowledgeable people don't know about and those who do don't want it popularized. I don't care if a couple adds show up on NoScript's site, particularly if that means it remains free and updates continue. Stop talking about it.
Thanks.
Why wasn't this the default to begin with?
*You.
You had Microsoft convinced that you felt burdened by having to explicitly command your machine to act on media. Microsoft believed you perceived operating systems that failed to automatically engage new media as somehow less sophisticated or friendly. You complained when required to perform any number of minor steps to begin utilizing your media, and you were happy when arbitrary programs were automatically launched to consume arbitrary content with no effort on your part.
You had to be dragged over the coals of malware to learn that this naivety is painful. You had to be fleeced by keyloggers and had your careers ruined by worms. Billions had to be pissed away before you got it. Now that you appear to have acquired clues sufficient to overcome your obstinacy, Microsoft now perceives that you will not throw a fit when inserting a flash drive doesn't automatically launch hundreds of megs of software. Congratulations!
* Those of you that put in the effort to discover, document and apply the various registry hacks, group policy modifications and other various and sundry non-default bullshit to prevent autorun are excluded, of course. Those of you who propagated this insanity to the Gnome/KDE/et al. environments can eat a dick. Get busy and take it out (for read-only media as well, thank you) now that you've been shown the way by the only influence you appear to recognize.
Agreed. Patently obvious to me as well. Wouldn't even require any public 'investment'; just give rail operators easier right of way and they'll replace 95% of the trucking industry with no further help.
Whatever. Out here in flyover country we're guaranteed not to see a dime of Obama's 'rail' money. Do whatever you want with your scrip printers. Print more. Hurry. Bring this happy horseshit to it's knees so it can be dealt with it once and for all.
For the DHS line eater: Taxes. 2nd Amendment. Waco. Ruby Ridge. Janet Reno. Janet Napolitano. Teabag. 30 Rounds. Crazy veterans. Fuck you.
Anyone who thinks concatenation is a good thing, much less better than striping...
Concatenation, by itself, would certainly be unwise. I'll give Exchange admins the benefit of the doubt and assume this "concatenation" is in addition to whatever redundancy features are provided.
From the story:
JBOD support lets you concatenate disks rather than stripe them into a redundant array
I find that statement confusing. Why is Exchange, a mail server/collaboration platform/etc., managing storage devices? Is the story conflating Windows Server 2008 features with Exchange, or is Exchange directly responsible for storage devices (like Oracle ASM)?
No, "they" said nothing about that meaningless debate. Administrations generally don't design rockets in the federal budget.
Prediction: the heavy lift Ares V or its moral equivalent (Ares IV, DIRECT, yada yada...) will never be built. I will refer back to this in half a decade and you will acknowledge my brilliance.
The new budget commits only to Orion and it's launch vehicle (Ares I). That's the bare minimum necessary to replace the Shuttle in its LEO ISS crew transport and resupply role. Finishing Orion and Ares I is the politically easy thing to do because without it Obama would have to explain the end of US manned space flight, which is politically difficult.
Ares V, on the other hand, is several years down the road and a much bigger commitment. What's been done to-date can be dropped and quietly swept under the rug. It's not a 2012 issue and after that it doesn't matter, just as long as the NEA gets its dough.
This is McNealy quoting an unnamed "federal official" regarding an unnamed project at some arbitrary point in the past. Feel free to go all pretzel like over it if you wish, but it seems far more likely to me that any lack of progress "open source" (however McNealy defines that...) has made is more likely due to cozy relationships between politicians their favorite vendors than the ideological hang-ups of some bureaucrat.
I've developed software as a DOD contractor. It's a very big government so I can't claim to speak for every case, but my experience was that the DOD doesn't give a flying **** what licenses are involved in their systems. They want it Tuesday. Right, wrong, whatever... Tuesday.
But hey, it's Friday and beating up on fictional government merchantilists is fun.
This bit:
echo 0 > /proc/sys/vm/drop_caches
doesn't actually do anything. See the relevent code here.
More importantly, kernel developers believe the drop_caches mechanism to be unsafe. It is a hack to permit easy benchmarking and other testing.
I must agree with the the GP; Linux VM behavior has been and continues to be poor. I particularly dislike the way inactive code pages are removed to buffer IO when there is clearly no reason to do so. You suffer this every time you copy a large file.
Linux is, indeed, based on what is now a very old paradigm - approaching half a century. Concepts have advanced since
No, actually, concepts have not advanced. The hardware is larger and faster, but from the perspective of software the design of any modern OS, from PDA to supercomputer, is entirely familiar to anyone that wrote system software for an IBM 360-67 (virtual memory and 32 bit addressing) as early as 1966. With the possible exception of extraordinarily high real concurrency (and some of its consequences such as STM) everything we see today was present and fully exploited by software in those systems.
The fact that it didn't take very long to produce software designs sufficient to fully exploit the hardware doesn't mean the software is designed incorrectly. It just means the problem space isn't that complex. There are many research operating systems for the same reason; they're not hard to make.
A prime example is the notion of "restarting" a computer. Why, these days...
Damage accumulates. Resource leaks, fragmentation, failed subsystems that aren't designed to restart without power cycle, cosmic rays, etc. All of these "concepts" are ancient and unchanged. They won't be changing for the foreseeable future.
Solutions to these problems exist but remain expensive and imply limitations on the resulting product that confines their application to highly vertical and/or costly systems. The general purpose, inexpensive systems on which you expect to run practically any trash you might throw at it do not meet that standard. They could be made to at the cost of becoming unaffordable. You would also find the inflexibility of a rigorously reliable system intolerable for a personal, general purpose use.
You're the reason, in other words.
Is it possible that some new OS design can reduce the costs? I don't know. What I do know is that the ideas behind Phantom OS have been tried before, and you and I are still running 30-40 year old designs to read about the many attempts.
The concept of "files" is archaic
The concept of a named persistent sequence of data is not going away no matter what you call it or how many abstractions you pile on top. If the word "file" is too prosaic feel free to employ the "document" euphemism.
Where the **** are my mod points when I need them.
You want to 'protect' American jobs? Get your savior to fulfill his campaign promises to the unions and stand up to Europe, Asia and the rest and start restricting and/or banning imports. Renegotiate NAFTA.
For instance, when the euros start yelling about 'buy American' language in the Obama payoff bill you'll need to grow a pair and ignore it.
Don't bitch when the prices double or triple, and whatever you do DO NOT ask yourself if IBM is actually right and if so why.
If you do it right host names don't matter. The important thing is Service names.
Server foo.bar.com may host HTTP proxies, mail, NFS shares or whatever. Create CNAMES for the services. Never expose the "foo" name for public services. ftp.bar.com may then move freely without being tied to some specific host.
Number the service names. Almost any non-trivial service will need to be duplicated if your organization grows. ftp.bar.com should be ftp01.bar.com, because there will eventually need to be an ftp02.
Host names can be made to reflect geography. This is helpful in large organizations. jane.boston-colo-01.bar.com. You've separated the service names from the host names, so none of that administratively helpful geographical noise is exposed to the public.
Do these three things and you've solved 98% of the problem. The rest won't be suffered long enough to worry about before someone else takes over and reorganizes the whole shebang anyhow.
Now that you've liberated the service names from the host names feel free to employ whatever amusing server naming scheme you wish. I find dictator names are fun; stalin, chavez, pinochet, etc. The shorter the better.
when are you going to start treating us as equals?
Right about the time you figure out how to govern without dictators.
Actually, the whole exchange is rather refreshing. I dream of similar behavior from some of our 'leaders' and citizens...
Worker: I won't be needing 24 months of unemployment money printed up, thanks.
Unions: We provide actual value that potential members want so we won't be needing card check legislation to prosper, thanks.
Surf: We're not actually starving out here so please don't drop another $20 billion of food stamps on us, thanks.
If CERN leaves the window open long enough by failing to produce real collisions in the LHC that don't destroy the planet the alarmists WILL achieve their goals and get it shut down. Have no doubt. Politicians of all stripes thrive on alarmist nonsense. This 'story' is exactly the sort of double-speak that can lend just enough credibility to the alarmist argument to get the ball rolling.