No, it has nothing to do with the WWW. It has a lot to do with poorly designed web browsers written in C/C++ which leak memory like a sieve and treat memory like everything has unlimited quantities of it. A well designed web browser supporting ALL of the HTML, Javascript and other web standards could use a small fraction of what Firefox uses if it is written properly and in a better language like Ruby. With some quality programming, the web browsers could use a fraction of the CPU power they do now by storing off screen graphics in compressed formats, for instance, especially since ending up with disk caching due to using up the RAM is far more resource intensive than decompressing images. There is no reason, NO REASON that Firefox should eat up 1 GB of RAM. The Javascript and HTML engines supporting ALL of the latest standards and ALL legacy standards only take up a few MB of RAM. There is massive memory leakage going on these browsers of forgotten image and multimedia data. Observing the behaviour of Firefox it cannot be anything else, when you open 20 windows and then close all except the first one, memory never goes back down. If web browsers were written in say, Perl or Ruby, I gaurantee that you could easily have browsers that are many times faster than current browsers because the memory usage and swapping would be much less, plus would be much safer without all of the buffer overruns.

The fact that so many experts on the disease die of it is a testament to its extreme contagiousness, and why we really should be scared of this thing. Of all people, experts of the disease take precautions to avoid catching it themselves, when they do, its not a good sign. It only makes sense to put into place travel bans from infected countries. It is important when dealing with this diseases to stop the spread by banning travel from the hot zone. There also needs to be public funding for a vaccine.

An all the way CISC architecture would allow you to have both operands of an instruction to be pointers to memory, the CPU would have the circuitry to load values into a register in the background. That would eliminate manual register loading. You would also have 3 operand versions of the instructions, as well. x86 is not the most CISC architecture out there or take the concept as far as it could. This would be a very programmer friendly environment. AMD expanded the number of registers, they could add even more, I dont know what the reasons are for not having at least 32 GPRs.

MIT shared memory support? This has been in the X server for a long time. Apps can use that to send an image to the server, the server then can take that image and composite it with others for the hardware video output buffer. The application can create the buffer on the server, render to the buffer, and then issue a command to the server that the buffer is finished rendering and can be used for compositing an output frame. The application would be given timing information, such as the frequency and the timebase, so it can know when the deadline is for submitting a finished buffer. Any submission of a buffer after the deadline is saved for the rendering of the next frame. this can work with direct and indirect rendering, in indirect the actual programming of hardware occurs in the X server, you would use GLX to send OpenGL commands to the server.

X itself is useable and was not the issue. The problems were with drivers were due to the lack of drivers, and problems with the device dependant layer (such as lack of auto configuration of drivers or when auto configuration of drivers screwed up) rather than with X itself. These problems would continue no matter what window system was used, because it was not a window system problem, it was a problem with drivers. Wayland mainly solves some slught issues with visual artifacts, as far as I am aware, by addressing issues with vertical synchronization. An X extension could have been created to address these concerns by allowing X applications a clue as to the frequency and timing of vertical synchronization and a double buffering facility that could be used by apps to update their screen contents.

Systemd still supports the system V boot process features, you can still run init scripts from systemd if you wish.

It would be trivial to add a dynamic loader, or if necesary a simple compatability layer for a stable ABI, to the kernel so that old drivers will work fine.The only reason they don't is that Linux developers are anti-social and basically like the idea of Linux being unuseable to most average people, because it makes themselves feel elite to be able to use something that is so difficult to manage. Yes, Linux needs a dynamic loader or compatability layer for drivers, but try telling that to kernel developers who are off in their own world where average people can be expected to learn to love editing configuration files. Most people are not interested in that stuff, they just want to use their computer to get work done and get off, not muck around with recompiling drivers and editing configuration files.

the general concept behind systemd makes sense, its mainly some additional features on top of the current model, such as the ability to have processes started on certain system events. The fact is, if you want your bootup process to be controlled by bash scripts, all you need to do is configure systemd to start your bash script and youve got a more traditional init system. So, systemd does not take away any functionality, only adds it. Systemd supports the system v init process features so you still have all the old model functionality available to you. So, it does not make much sense that people complain about this when they can easily configure things however they want, including having a BSD style init, by having systemd hand off control to your own scripts, including to work the way things always have. People act like systemd has taken away something when it has not, i think many people just hears some soundbite about systemd introducing a new model and assume that they can no longer use things the way they do currently, which is not the case. it seems like people who don't like systemd don't want people to have the additional functionality that it provides, because it does not take away anything. Its open source software, and its something that you can control and configure to your hearts content. Its much ado about nothing. systemd, while being configurable, also will make things easier to use for many users. I think the ado about systemd is more about Linux people who think that Linux should be hard to use except for a small elite and do not want the OS to be useful to less technically adept users. This is even though making it more useable for less adept users does not in any way harm or take away flexibility from experts, who can still configure everything if they want they want to.

i thought they would be looking for industrial gases in the spectrum from planets. It doesnt seem like streetlights and city lights would be significant compared to the amount emitted by suns.

I for one welcome our new moth overlords.

Thats incorrect. Look at the Obfuscated C Code Contest. You can write TOTALLY unmaintainable code in ANY reasonably powerful general purpose language. Such features are necessary to write good software, though of course, anything can be abused.

Still, you have not actually discounted the fact that IBM could if it wanted to operate manufacturing wherever it need to be to compete, it might not be very profitable, but they could have profits in line with the chinese, and keep this business out of hands of the chinese. It seems as though instead, everything has to have a massive, fat profit margin to these companies, that making a modest amount isnt enough. If the chinese can manufacture these goods, albeit at a relatively low profit, IBM could spin off subsidiary to do it.

It could be cheaper to replace the cheap consumer RAID drivers than to buy expensive "enterprise grade" stuff. Maybe the cost of a RAID array with backup is cheaper than all the more expensive stuff.

My solution is the one that would actually allow ISPs to gradually upgrade things over time rther than to replace everything at once, by allowing the interoperation. Its a lot easier if the changes are concentrated at the ISP end rather than effect subscribers as well. Its true that over time as due to the turnover of ipv4 older routers, that ISPs could gradually replace the subcribers routers with newer models. It would also be possible even for ISPs to collect older routers, flash them with new firmware, and put them back out, in the process of customer turnover cancellations and signups. The whole point is the solution i describe gives ISPs a transitiion period.

Theoritically, any block of Ipv4 addresses outside of the local subnet could be used, if an ipv4 address is used as a fake address, and then the user asks DNS address which happens to resolve to a real IPv4 address with the same number, then, the same NAT trick could be used with a mapping between created between another temporary local ipv4 address to the real internet ipv4 address which was already being used locally as a fake ipv4 number. Though, I would only recommend that be used as a fallback if 127.x.x.x is used up. A small part of the of RFC 1918 addreses could also be allocated for the pool of fake ipv4 address, such as maybe 172.20 and 172.21, giving a pool of 131072 ipv4 addresses, plenty for most use cases. I doubt most people will have that many TCP connections at once. Since 127 is not used for local networks, it is the best choice however as the first choice. Again, 127 is so large, i doubt most users would ever exhaust it, especially if the fake ipv4 mappings are timed out after a period of maybe 1 -7 days or so.