Consider the 'carpet bombing' exploit that was discovered in Safari a while back. It allowed a website to save any number of files to the default download location without any interaction or notification to the user. The exploit worked on OS X and Windows but was a far greater threat on Windows due to some changes Apple made when porting Safari from OS X. Despite the public discovering this Apple dragged its feet and tried to claim it wasn't an attack vector.

So what where the difference between the original Mac version and the same code ported over to Windows, which in theory should have simply replaced the OS specific calls? First the Windows port changed the default download location to the desktop, despite the fact that Windows has a downloads folder just like Mac. That means files get deliberately dumped all over the desktop until the screen is a mess. That's a minor thing though it does help make Windows seem cluttered to the average user.

The major change was they removed the code that marked downloads as untrusted. So when a hostile website silently saved an executable file called Safari.exe (directly to the users desktop) there was no untrusted flag. No other browser on Windows works this way; IE, Firefox, Chrome and Opera all mark downloaded files as untrusted to prevent them from being accidently run without a user notification. Safari on OS X marks downloaded files as untrusted so that users are shown a notification. But the port removes this basic functionality. And taking away that safe guard makes it a lot easier for malware to be installed on Windows when a user is browsing with Safari - not just the Safari specific exploit that silently downloaded files, but also the wealth of executable malware that likes to pretend to be a legitimate file (such as websites that attempt to give users an executable file in lieu of a promised video or torrent download)

It really doesn't take a lot of power to read an eBook. Some of us have been doing it since the Palm days (for reference I had no problem reading eBooks on a 4MB Palm IIIx, which used a 16 Mhz low power SoC version of the CPU that powered the Apple Lisa).

Reading the specs for the device it seems that its 4 GB of storage are used to hold 4 bit uncompressed bitmaps - the companion app must render each page as a bitmap, send it to the device by bluetooth and then the device just dumps it on the screen with no processing power at all. That would seem to be the 'cost savings': take out the CPU and RAM and replace it with a simple 8 bit controller linking BlueTooth, flash and display, or at least that must have been the original sales pitch before anyone actually sat down to design it.

By comparison a $30 photo frame contains a CPU powerful enough to decode JPG files fast enough to display them as a slide show. That's more powerful then the Palm at half the cost of the Beagle. Part of that is because the cheap ARM CPU inside costs under $2 and has all the power you could need.

I think the simple truth is that 80-90% of the material cost of the Beagle (and it's competitors like the entry level Kindle, Nook, Kobo models) probably comes from the eInk screen and the NAND memory. There just wasn't a huge savings to be had by eliminating the CPU and RAM. They seem to have saved $10 after markup over their competitors (who not only have CPUs but touch screens and rechargable batteries as well). This seems like a pie in the sky sales pitch that wasn't aborted as soon as they discovered the cost savings where not there.

Valve has been in the unique position of having some hit titles in the past that they had good publishing deals on. That's given them the financial cushion to run things however they wanted with whomever they wanted, without any of those pesky obligations most developers have to meet to pay the bills. And then of course they stumbled onto Steam, the patching platform turned online store where they get a cut of all the other developers profits.

To highlight a similar scenario, 3D Realms was able to dick around for almost 15 years (1996-2009) thanks to the big pot of cash they had from the first Duke 3D game and a few farmed out expansions. We know for sure now that those years where not spent under some masterful system of management creating the most polished game ever, they where terribly managed years in which the same game was reinvented every 4-6 months everytime Broussard saw a new game.

Valve management is certainly not the disaster that was 3D Realms, but at the same time it's very hard to apply their near-zero management style without also having access to their near-zero financial obligations. Valve can afford to mess around in the kitchen for years tossing meal after meal into the garbage until they have something they like. Other developers have to feed their family tonight.

So I guess what I'm saying is that regardless of whether the bossless model works for Valve, other companies have to actually produce games on time and on budget. Where exactly is Half Life 3...

To expand on this Salesforce.com has two different blocks of storage allocated for any Salesforce instance. One is data storage which is for tables and you start at 1GB for your database. This is where the quote of $3000 for each additional GB comes from. The other is file storage, where you save PDFs and other record attachments. You start off with 30GB and it is much more in line with normal cloud data storage prices. Your usage of both is displayed seperately on your companies Salesforce admin page.

As the parent said the cost of that 1GB is not really the disk space but the expected transaction cost in terms of servers. The number of bytes shown as used is not even based on any actual disk usage (this would be complicated with table structure, overhead, indexes and fragmentation). For most tables they use a formula of 2KB per record - it doesn't matter if it's an contact record which is probably stuffed with much more then 2KB, or a very simple custom sales record containing a name and a dollar amount. There are a few special tables that are treated at 512 bytes per record, like the table containing chatter updates (Salesforce.com's social media like notifications). Taken all together this means that the "1GB" of data allowance is really 250,000+ records, depending on how much is chatter vs. actual records and not anything related to disk space. It's just easier to explain it as 1GB to a management person rather then as a complex relationship between records, transactions and indexes.

You've got lots of answers about cabling, some for cooling and a few for power. One tiny thing you don't want to overlook is the door. You should ensure there is a plus sized pathway (check for tight turns) all the way from outside the building to the computer room where you'll have an extra tall, extra wide outward opening door. If you are building a smaller room this is really important since it may become impractical to disassemble a rack and reassemble it in such a small space (remember that there will be other running equipment you don't want to accidently knock about). Also make sure you have a properly sized ramp (and that the ramp is factored into any path and turn calculations) if you have steps or a raised floor. Unless there are security considerations a good setup would be for the server room door to be close to a large side door which in turn is close to the server rooms air conditioning units (when there is eventually a problem it would be terrible for the repair guy to have to walk back and forth through a machineshop to fix it).

A widely used web package has a backdoor inserted.

Scary.

One of the regional mirrors of the largested software respository containing tens of thousands of projects is either hacked or was a plant from the start.

Scarier.

The backdoor code looks to be the work of someone who learned PHP on Monday.

Scariest.

Honestly, the only way it could have been more obvious is if the file was called backdoor.php. There was no attempt made to disguise the location or what the code was doing which is why it got caught so quickly. A complete amateur got caught with control over a chunk of Sourceforge downloads. In computer security when you find a breach you don't just close the obvious point of entry, you have to take a big step back and seriously ask 'what else was compromised'. In this case the big question is who else.

If this clown could do it and didn't get caught until an end user saw the stupidly obvious file and its stupidly obvious code (as opposed to a server log or other Sourceforge audit turning it up) what are the competent hackers up to. Real backdoors are blended into the existing code instead of being added as a seperate file. Real backdoors are designed to be hidden from casual inspection instead being completely obvious in their function and 'I don't belong here status'. Really good backdoors are designed to not look like intentionally malicious code even after they are found (ex. the wait4 backdoor attempt in the Linux kernel was pretty good, it got caught because the CVS hack used to insert it in a regional CVS mirror was flawed in several ways that raised alarms).

So, what kind of security/procedure/audit could have been in place, needs to be in place, so that something like this will raise an alarm even when the hacker isn't the most incompetent backdoor author in history? What kind of audit is needed to be sure it hasn't already happened?

In the 90s Microsoft was accused of and then convicted of monopoly behavoir against OEMs to push OS/2 (and other PC OSs) out of the market in favor of Windows.

Back then Microsoft provided 3 choices for OEMs:

• 1. Don't play with Microsoft at all (sell PCs with OS/2 or other OS, operate as a niche dealer)
• 2. Play with Microsoft but without a club membership (buy Windows licences at full price, sell however they want)
• 3. Join Microsoft's club (get discounted licences but pay them on a basis of one licence per computer regardless of actual configuration)

Microsoft argued that this was not anti-competitive; they claimed the discount simply represented Microsoft not having to keep track of individual licences and that OEMs where free to buy licences individually instead. They lost that argument because it was found that since Windows already had a majority market share (for the time being) an OEM had to load Windows on a majority of their systems to satisfy consumers. Because of the pricing scheme OEMs could not be competitive with other OEMs if they took option 2, forcing them into 3 where Microsoft's terms made it uncompetitive to sell PCs with another operating systems. So Microsoft was convicted under the Sherman Antitrust Act.

Let's look at Google and its club the Open Handset Alliance (OHA):

• 1. Don't use any official Android distributions (operate as a niche/self-supported market, ie. Amazon)
• 2. Use any combination of Android and forked android-derived distributions, but can't join the OHA
• 3. Join the OHA and use only an official Google Android derived OS

The official Android distribution can be seen as something wanted by the majority of customers (looking for a non-Apple/Microsoft or a inexpensive phone) at this time (unless you have something else big enough to get people to come to you, like Amazon) so most Android/android OEMs would be giving up the majority of their customers if they dumped official Android entirely; that removes option 1. Much like the licence discount a membership in the OHA represents a major competitive advantage - the OEMs are already way behind in keeping official Android up to date in their design and production pipelines even with that inside track and help from Google. An OEM on its own trying to make an official Android device is thus at a large disadvantage against OEMs that are part of the OHA. This makes option 2 uncompetitive, forcing any serious OEM into option 3. Option 3 goes even farther then Microsoft in the 90s - it doesn't just apply a tax, it outright bans the alternative.

So does the same 90s logic applied by the court - that regardless of Microsoft/Google's excuse for the 3 choices it isn't really a choice at all, and that the only viable choice blocks competition - still apply today?

A CD or 'compact disc' was an ancient precursor to the DVDs that you can still find in some stores today. During their heyday CDs where mainly used to store a primitive type of mp3 called '16bit uncompressed PCM' but could also store regular data. A typical CD could hold between 650 and 700 'megabytes' worth of small files. A 'megabyte' was an older unit of storage; One megabyte was just 1/1000 of a gigabyte!

It has nothing to do with "older" devices and how well they run ICS, but budget devices even from this year. Your Nexus One and Nexus S (circa Jan 2010 and Dec 2010) still run circles around budget Android phones like a Galaxy Pocket (circa Feb 2012).

A 2 year old used Nexus One is still selling for more then budget Android phones sold outside the subsidized market of North America. Just because your Porsche 911 is 10 years old doesn't put it in the same racing category as a 2012 Kia Rio.

The PDK does address an issue that Google shouldn't have made an issue to begin with - manufacturers actually getting some lead time. But it doesn't address the issue of why Gingerbread itself is still such a big chunk of the market.

ICS simply can't run on budget Android devices. The Android makers that are making money (Samsung) are targeting a much wider market then just the high end subsidized North American market. Samsung is able to turn a profit because they're spreading their costs over a much wider net with both mid range phones like the Ace line and a lot of super-low end ones (Y, Mini, Pocket) that compete directly with feature phones and in emerging markets. ICS is never going to run on those and Samsung and others won't try - they're still releasing brand new phones, 8 months later, running Gingerbread with no hope for an upgrade.

Android will continue to be 'fragmented' between Gingerbread and whatever the latest and greatest is for a long time, at least as long as the gulf exists between heavily carrier subsized phones in a few countries (allowing iPhones, Samsung Galaxy Ss and HTC One Xs to sell in any quantity) and full cost phones in other countries where (Gingerbread) Android's price point is the biggest selling point against more expensive smart phones and increasingly identically priced feature phones.

Googles thinks Microsoft is sending proxies to do its legal work, or at the least is trying to convince someone of that fantasy?

Microsoft hasn't shown any problems going after Android makers openly and directly. Sure it doesn't always make the front page but that's because Microsoft wants to licence the technology, not use the patents to block companies from the market entirely like Apple. This has always been Microsoft's business stategy from all the back in the days when it was Bill writing BASIC interpreters - find a place in the middle of the supply or technology chain so that no matter what company or product consumers are wild about this day of the week, Microsoft is getting paid somehow. A 'horizontal' instead of vertical market integration. That Android phone in your hand? Microsoft got paid a cut of it. I believe the slashdotter term is 'the Microsoft tax'.

Either Google is on a conspiracy bent to try and explain why so many companies have dirt on them without considering that maybe it's because they copied from all of them to assemble Android, or they're just cooking up so they can get Microsoft beat up by the EU bigwigs the way Opera did.

"The root cause of this problem is an email server compromise. The email server belongs to one of our team members."

A poorly secured email server is not the failure in this statement.

The failure is what was a non-essential piece of software, what sounds like someone's personal software, doing on this server or even on the same firewalled subnet?