And outlawing goats. And reducing human population in the neighboring desert states to sustainable levels, particularly avoiding urban growth. And stable enough governments in these regions to maintan such policies.
I'm afraid that while it's technologically sustainable farming you're suggesting, politically it's impossible. The populations there are not wealthy enough and do not give enough rights to women to curbe the population growth.
The main trouble is that where you used to have low water use grasses, you now have high water use crops. The result drains the water supplies, and food animals like goats are raised on the grasses, and they eat _everything_. So the stabilizing grasses are gone, the ground can't retain water. So what used to be stable grasslands is turned into desert.
The same sort of thing happened in Oklahoma in the 1930's in the USA, called the 'Dust Bowl'. Look it up.
Because we _caused_ the desert. Overpopulation, Overgrazing goats, digging for aquifers, using imported fertilizers, etc., helped destroy modest existing ecosystems that stabilized the soil and retained soil at the desert's border. Looked at over thousands of years of geological and archaelogical history, it seems clear that humans created or wildly expanded the deserts. There were amazing small areas that weren't overfarmed and avoided overpopulated, as experiments, and they showed up as remaining green and fertile as the desert grew right past them. It made the cause of desert growth quite clear.
Circuit City was mostly an excuse to sell resources at normal prices to suckers. I looked: those "closing" prices were the same as other commercial retailers, with perhaps a 5% discount, at least in my neighborhood.
Service contracts and customer lists. There are a stack of fiscal and paperwork handling companies that used OpenServer for relatively inexpensive x86 based servers, for years, and wrote very important in-house toolkits on which their companies are founded. I had a long chat with a corporate partner 3 years ago about exactly this, because SCO hardware compatibility seriously lagged anything that wasn't in bankruptcy. They chose to stay with their existing software environment rather than do a complete database migration in a ruch, and have been engaged in a very careful and cautious code cleanup, to get their toolchain under source control and virtualization, so that they can retain access to old data and old environments, while they build a new environment. With that careful toolchain migration and cleanup, they're _much_ better off than they would have been migrating in one giant leap 3 years ago, and are ready to select their next major OS, whether that be OpenServer or Solaris or any other OS that's obviously about to go out of business.
OK, I'm kidding, but they remain unconvinced that any Linux OS is stable enough. And they've got a point with Linux's eagerness to embrace new toolkits and utilities. For companies with 30 year mortgages, database stability rules over database performance and new features.
There is apparently some actual compoetent open source work for SCO systems, over at http://aplawrence.com/cgi-bin/indexget.pl?OSR5. This site was an important resource for their cleanup work, especially the notes on VMware and on getting open source tools like gcc and SSH and HTTPD to work properly. Mr. Lawrence is real open source and freeware champion doing very difficult work and deserves all the paying work and support we can send his way. (I had a harsh argument with my corporate partner friend, saying that he should be cutting Mr. Lawrence a _big_ check.)
Given the ease of faking a pedigree, what exactly is your point? You need to do actual carbon dating and other potentially destructive tests to verify some of these items, and even then the 'legbone of King Tut' is indistinguishable from 'the legbone of the slave in the burial chamber in the smaller pyramid next door'.
I remember the Cobalt's. Even Sun's own tech support no idea of how those things loaded kernels, so running your own performance optimized kernel was out of the question. They were a great idea with a few critical missing bits that made them impossible to sell in bulk when I supported them.
This was common to Sun products. Too bad Java turned out the same: those missing bits only became fixed when Sun actually open sourced it. I have to assume that there was some tier of management at Sun where people rose to their level of incompetence and poisoned the next round of development because this _kept happening_ with different Sun product lines. Heck, Sun couldn't figure out how to name its software products! JDK, J2EE, JRE, J2RE, JSDK, etc, etc., etc., and the several times revised numbering scheme make figuring out which Java toolkit to install a nightmare. And don't get me started on that "wrapper an RPM in an installer that breaks things" that they provide for RPM based Linuxes.
> That's not really the same fashion. You install Flash once [a week] to play [the latest] Flash games on the internet;
I fixed that for you. The tendency of the flash games designers to insist on the latest version, for absolutely no performance reason, is burdensome to web clients.
Laptops make great lightweight backup machines with a stack of USB external drives on them, as print servers, or especially as modest capacity monitoring systems to report on and provide alerts for upstream switches, datacenter power, etc. With their built-in wireless and modem ports, they have another two ways to reach out and send alerts without buying new components. And they're certainly suitable as migration servers for what's been running on someone's server since 1993 and needs to be transferred to contemporary hardware, especially with virtualization capabilities to simply image and run the old OS in a virtual environment.
The papers on it go back more than a dozen years in the publications of the US Department of Transportation. Besides the anecdotal reports of "that idiot was using a cell phone when he cut me off!!!!" and personal opinions, there does seem to be reliable evidence of both minor and major accidents increasing for driving cell phone users.
I was actually referring to CB and shortwave radios when I referred to radio, and I was unclear about that. Thank you for notifying me of my confusing language.
That's like saying "in and of itself, using a cell phone or radio while driving is not bad". There are a very few exceptions where it's helpful. Communications for long-haul trucking is very helpful, and for delivery personnel to get directions at the delivery point in slow traffic. But it's so overused and so destructive in its normal use.
Let's see why they want to do this. Is there some specific click behavior that frames enforce that forces additional clicks to ad pages? Or that significantly reduces bandwidth for the servers?
I admit that most frames are very, very badly designed, creating incompatibilities with browsers.
Especially since, done properly, it's easy to install as a fake and pop right off for when you do want a recording of the judge's hijinx in the court room
Sun's mistakes go back a ways. They explored display Postscript, and discarded it in favor of X11. While X11 was open source, display Postscript was much faster and easier to program in, and gave cleaner displays. But they then screwed up X11, proprietizing it and making it incompatible.
Sun's marketing plans have also failed miserably by refusing to admit that people wanted better versions of what already worked, rather than the "next big marketing plan". The switch to from SunOS to Solaris for the sun4m architecture was a clever hook to force the switchover, until it became clear that the sun4m could easily run SunOS and their Tatung partners started selling better configured hardware with SunOS on it. Like Microsoft selling Vista, it turned out people were happier with their old OS.
I've had too much fun in the last few years migrating systems off of Solaris and other commercial UNIX's to Linux, for the increased availibility of higher end open source tools.
Here's to making websites run on Lynx. They're invariably far faster, usually far more readable, far more usable for those with visual or manual problems, far lighter in bandwidth, and require far less testing for a variety of standards-violating clients.
Is OpenBSD useful for anything _besides_ OpenSSH? Sparkling clean, secure code is wonderful, but when it's years behind the times in basic software kits. The same problem applies in various ways to enterprise software bundles such as RHEL, but there we at least have Fedora to provide access to the leading edge tools if we need to trade stability for features.
I sell some of mine back, to a local used game store, just to free up some space and let kids who are short on spare cash play old games. It also lets me play some slightly old games I didn't bother to buy new.
To share the open source maps. Steam and userbuilt games like Sven Coop are burdened by lengthy load times for new maps. And game downloads for purchased games like Darwinia or Half-Life 2 are pretty painful at times.
I met a man who made Society for Creative Anachronism scale armor out of sliced up AOL disks. I tried it on and got hit a few times: it was surprisingly light and effective armor.
Andrew Tannenbaum actually has a clue about this: Linus Torvalds based some of his Linux work on Minix. And the Linux kernel has gotten big enough, with enough disparate features, that stability is a big concern. Minix does have a very good reputation, well-earned, against crashing the hardware drivers or network stack and imperiling the kernel itself. Such stability has big, big advantages in a 24x7 data center.
The "multiple computers" idea is fine, when you have lots of money. But when your computer runs the power grid, or all your systems turn out to be vulnerable to the same flaw or same attack, then you still get crashing of all your nice failover systems. This is especially true when the failover system itself, or the load balancer or cluster manager, dies.
Slashdot Mirror
And outlawing goats. And reducing human population in the neighboring desert states to sustainable levels, particularly avoiding urban growth. And stable enough governments in these regions to maintan such policies.
I'm afraid that while it's technologically sustainable farming you're suggesting, politically it's impossible. The populations there are not wealthy enough and do not give enough rights to women to curbe the population growth.
The main trouble is that where you used to have low water use grasses, you now have high water use crops. The result drains the water supplies, and food animals like goats are raised on the grasses, and they eat _everything_. So the stabilizing grasses are gone, the ground can't retain water. So what used to be stable grasslands is turned into desert.
The same sort of thing happened in Oklahoma in the 1930's in the USA, called the 'Dust Bowl'. Look it up.
Because we _caused_ the desert. Overpopulation, Overgrazing goats, digging for aquifers, using imported fertilizers, etc., helped destroy modest existing ecosystems that stabilized the soil and retained soil at the desert's border. Looked at over thousands of years of geological and archaelogical history, it seems clear that humans created or wildly expanded the deserts. There were amazing small areas that weren't overfarmed and avoided overpopulated, as experiments, and they showed up as remaining green and fertile as the desert grew right past them. It made the cause of desert growth quite clear.
Circuit City was mostly an excuse to sell resources at normal prices to suckers. I looked: those "closing" prices were the same as other commercial retailers, with perhaps a 5% discount, at least in my neighborhood.
Service contracts and customer lists. There are a stack of fiscal and paperwork handling companies that used OpenServer for relatively inexpensive x86 based servers, for years, and wrote very important in-house toolkits on which their companies are founded. I had a long chat with a corporate partner 3 years ago about exactly this, because SCO hardware compatibility seriously lagged anything that wasn't in bankruptcy. They chose to stay with their existing software environment rather than do a complete database migration in a ruch, and have been engaged in a very careful and cautious code cleanup, to get their toolchain under source control and virtualization, so that they can retain access to old data and old environments, while they build a new environment. With that careful toolchain migration and cleanup, they're _much_ better off than they would have been migrating in one giant leap 3 years ago, and are ready to select their next major OS, whether that be OpenServer or Solaris or any other OS that's obviously about to go out of business.
OK, I'm kidding, but they remain unconvinced that any Linux OS is stable enough. And they've got a point with Linux's eagerness to embrace new toolkits and utilities. For companies with 30 year mortgages, database stability rules over database performance and new features.
There is apparently some actual compoetent open source work for SCO systems, over at http://aplawrence.com/cgi-bin/indexget.pl?OSR5. This site was an important resource for their cleanup work, especially the notes on VMware and on getting open source tools like gcc and SSH and HTTPD to work properly. Mr. Lawrence is real open source and freeware champion doing very difficult work and deserves all the paying work and support we can send his way. (I had a harsh argument with my corporate partner friend, saying that he should be cutting Mr. Lawrence a _big_ check.)
Given the ease of faking a pedigree, what exactly is your point? You need to do actual carbon dating and other potentially destructive tests to verify some of these items, and even then the 'legbone of King Tut' is indistinguishable from 'the legbone of the slave in the burial chamber in the smaller pyramid next door'.
Its compatibility mode may not have been as good when it started out: I just wanted to play my games.
Or maybe he runs Word *and* a browser, at the same time?
I did, to play certain old Win9x based games. Also, it was cheaper to get Win9x and put Linux on a second hard drive to do any real work.
I remember the Cobalt's. Even Sun's own tech support no idea of how those things loaded kernels, so running your own performance optimized kernel was out of the question. They were a great idea with a few critical missing bits that made them impossible to sell in bulk when I supported them.
This was common to Sun products. Too bad Java turned out the same: those missing bits only became fixed when Sun actually open sourced it. I have to assume that there was some tier of management at Sun where people rose to their level of incompetence and poisoned the next round of development because this _kept happening_ with different Sun product lines. Heck, Sun couldn't figure out how to name its software products! JDK, J2EE, JRE, J2RE, JSDK, etc, etc., etc., and the several times revised numbering scheme make figuring out which Java toolkit to install a nightmare. And don't get me started on that "wrapper an RPM in an installer that breaks things" that they provide for RPM based Linuxes.
> That's not really the same fashion. You install Flash once [a week] to play [the latest] Flash games on the internet;
I fixed that for you. The tendency of the flash games designers to insist on the latest version, for absolutely no performance reason, is burdensome to web clients.
It pays a good bit more than flipping burgers, and is a lot more honest than telemarketing.
Laptops make great lightweight backup machines with a stack of USB external drives on them, as print servers, or especially as modest capacity monitoring systems to report on and provide alerts for upstream switches, datacenter power, etc. With their built-in wireless and modem ports, they have another two ways to reach out and send alerts without buying new components. And they're certainly suitable as migration servers for what's been running on someone's server since 1993 and needs to be transferred to contemporary hardware, especially with virtualization capabilities to simply image and run the old OS in a virtual environment.
The papers on it go back more than a dozen years in the publications of the US Department of Transportation. Besides the anecdotal reports of "that idiot was using a cell phone when he cut me off!!!!" and personal opinions, there does seem to be reliable evidence of both minor and major accidents increasing for driving cell phone users.
I was actually referring to CB and shortwave radios when I referred to radio, and I was unclear about that. Thank you for notifying me of my confusing language.
Kingdom of Loathing is pretty modest in requirements. It does use JavaScript.
It's also frankly much better than many high end, graphical games.
That's like saying "in and of itself, using a cell phone or radio while driving is not bad". There are a very few exceptions where it's helpful. Communications for long-haul trucking is very helpful, and for delivery personnel to get directions at the delivery point in slow traffic. But it's so overused and so destructive in its normal use.
Let's see why they want to do this. Is there some specific click behavior that frames enforce that forces additional clicks to ad pages? Or that significantly reduces bandwidth for the servers?
I admit that most frames are very, very badly designed, creating incompatibilities with browsers.
Especially since, done properly, it's easy to install as a fake and pop right off for when you do want a recording of the judge's hijinx in the court room
Sun's mistakes go back a ways. They explored display Postscript, and discarded it in favor of X11. While X11 was open source, display Postscript was much faster and easier to program in, and gave cleaner displays. But they then screwed up X11, proprietizing it and making it incompatible.
Sun's marketing plans have also failed miserably by refusing to admit that people wanted better versions of what already worked, rather than the "next big marketing plan". The switch to from SunOS to Solaris for the sun4m architecture was a clever hook to force the switchover, until it became clear that the sun4m could easily run SunOS and their Tatung partners started selling better configured hardware with SunOS on it. Like Microsoft selling Vista, it turned out people were happier with their old OS.
I've had too much fun in the last few years migrating systems off of Solaris and other commercial UNIX's to Linux, for the increased availibility of higher end open source tools.
Here's to making websites run on Lynx. They're invariably far faster, usually far more readable, far more usable for those with visual or manual problems, far lighter in bandwidth, and require far less testing for a variety of standards-violating clients.
Is OpenBSD useful for anything _besides_ OpenSSH? Sparkling clean, secure code is wonderful, but when it's years behind the times in basic software kits. The same problem applies in various ways to enterprise software bundles such as RHEL, but there we at least have Fedora to provide access to the leading edge tools if we need to trade stability for features.
I sell some of mine back, to a local used game store, just to free up some space and let kids who are short on spare cash play old games. It also lets me play some slightly old games I didn't bother to buy new.
To share the open source maps. Steam and userbuilt games like Sven Coop are burdened by lengthy load times for new maps. And game downloads for purchased games like Darwinia or Half-Life 2 are pretty painful at times.
I met a man who made Society for Creative Anachronism scale armor out of sliced up AOL disks. I tried it on and got hit a few times: it was surprisingly light and effective armor.
Andrew Tannenbaum actually has a clue about this: Linus Torvalds based some of his Linux work on Minix. And the Linux kernel has gotten big enough, with enough disparate features, that stability is a big concern. Minix does have a very good reputation, well-earned, against crashing the hardware drivers or network stack and imperiling the kernel itself. Such stability has big, big advantages in a 24x7 data center.
The "multiple computers" idea is fine, when you have lots of money. But when your computer runs the power grid, or all your systems turn out to be vulnerable to the same flaw or same attack, then you still get crashing of all your nice failover systems. This is especially true when the failover system itself, or the load balancer or cluster manager, dies.