The first of April.

This is aimed at companies like Facebook, Google, Amazon, and the like. When managing thousands of servers, any number of components will die on a fairly regular basis. Some will die withing a few weeks of them going online. When you have 200k servers and a component with a 1% infant mortality rate, having the ability to quickly and easily change the component is a blessing. You can do this with just about all of the components in a server accept the processor (relatively speaking).

As for why would you want the ability to switch between architectures as the drop of a hat. It is actually really simple. What is the cheapest that day? If the processor in a server goes and you have to find the exact processor that is compatible with that motherboard, you cannot use the cheapest component. Most likely you will have to go with something that is more expensive. With this design, you can simply go to the bin, grab any processor card, and slap it into the server. You might have to change a flag in your server management software saying that node should now network boot the ARM image rather than the x86 image, but that is about it.

I have one of these TVs which I started to try and hack. What he means is that there is no way to access the filesystem or change files yourself. You have to use an exploit to gain command line access which voids the warranty. Thus there is no independent way to fix this without voiding the warranty. The fact that this person has found a Zero Day that effects all models gives me hope that my TV will finally be supported by SamyGo (http://www.samygo.tv/).

http://www.dell.com/us/soho/p/xps-13-linux/pd?dgc=SM&cid=245280&lid=4585108

Whenever I hear someone say this I always correct them. I tell them it is actually the Odin particle. That it is the presumption of the common man to believe it proves the existence of the Jewdeo-Christian god. Amazingly some people actually believe me.

Yes, but it is not the Microsoft version of the API. Sure it is close, but not everything is 100% perfect and probably never will be. As such the behavior is not identical to Windows. It works, and in many instances it works great. As you said it is a library that calls other Linux system libraries, its behavior is directly linked to how those system libraries behave. With Windows you have a small subset of behaviors to look for. There is Windows XP, Windows Vista, Windows 7, and possibly some of the various Windows Server versions. With Linux there are so many distros and so many permutations of libraries I can see it being nearly impossible to correctly identify them all as WINE. Blizzard is looking for people who have altered libraries and effected system behavior for the purposes of cheating. The game allows you to sell items in a real world auction house. As such they have to protect their investment, or a bunch of people with server farms could farm items and flood the market with powerful items for shit money. Blizzard said flat out that they were going to be very strict on cheating so it does not surprise me that systems that are not behaving like a perfect version of Windows are getting banned. They were very explicit in the list of supported OSes and Linux with WINE is not one.

Why not have a very simple but signed boot loader that turns around and loads an unsigned bootloader like Grub2. I have had to do similar things before when I installed Ubuntu on a Mac.

What I have found through the years is that it is always best to stick with whatever distro you are using's default even if you are not a super fan of it. For instance when I install OpenSuSE on a system I install KDE. When I install Ubuntu on a system I go with the Gnome variant. There always seems to be bugs, issues, or lack of polish on the alternative windowing managers when trying to interface with the distro specific controls. I attribute this to the fact that fewer people tested the alternative windowing manager during the distro build process and there are fewer people using the alternative windowing manager out in the wild.

The power company where I live charges an extra five dollars per month to install one directly on your meter. This is a great option for me as I am a renter and did not feel like investing money in my landlords property. It took them all of five minutes to install it, so I assume replacing it would be just as fast if it blew. To install it, they basically took the meter off, put a plate that fit into the same space as the meter in, and then connected the meter to that plate. The plate had the surge protector in it.

Set up the hotel like a small DSL ISP. Each room has a DSL modem that connects back to the phone closet and a wifi access point. This ensures that each room has a strong signal, and it means that the hotel does not have to rewire as it will use the existing phone wiring. I have seen this setup in numerous hotels I have stayed at so I know it works.

What bothers me about this is that there are plenty of tablet devices out there that could benefit from the source code. Yes it would be absolutely stupid for people to install Gingerbread on a cell phone. It was not designed for this and the user interface would be utter crap. But there are devices like the Nook Color from Barnes and Noble that would greatly benefit from this code release. The Nook Color already has the developer preview version of Gingerbread running on it, but it has numerous problems. This is because there is no source code that can be adjusted for the device. I know of many other tablet devices out there that are running older versions of Android that would greatly benefit from the features in Gingerbread, but are not directly compatible with the developer preview image. I believe this has more to do with pressure from manufacturers than anything else. They would rather not see Gingerbread back ported to these devices and would rather have people go out and purchase new ones.

I fully agree that most people here are missing the point. Redhat (and CentOS) use a 2.6.18 kernel, which they back port patches and driver to as they turn up. This is actually a major problem because those back ports do not always work and require some major structural changes to the driver code. The initial 2.6.18 kernel was released in Sept 2006 and the final update to that release branch 2.6.18.8 was released in Feb. 2007. It is ridiculous in the world of Linux to base a mission critical application on a 4 year old code base. In addition to this the stock Redhat kernel is a compromise between desktop usability and server performance. If you need any kind of throughput, say for a database server, you have to recompile the kernel and change a whole bunch of settings. If you have ever tried to do this you will find out how much of a nightmare it is on a Redhat system which doesn't even fully support udev. I have had to do this more often than I care to count and every time I insist that my clients either send the server to me, or get an IP KVM and a remotely switchable power strip.

The requirements to perform this type of surgery is multiple redundant internet connections, and if a single one of them goes out before the surgery begins they do not perform it. There is also a back up surgeon ready to take over if there are complications with the connection / equipment during the surgery. That being said, I highly doubt that any sane surgeon would perform a heart surgery in London on a patent in New York for issues such as latency. I am betting it would be more likely a surgeon in Boston performing one on a patent in New York.