apologies, but "you're not using your servers" is a dump truck of horse shit. oh so our elastic cloud has free time, eh? electricity is now free? we dont know how to scale, how to utilize?

maybe if someone actually had quantified what kind of utilization end to end SSL required, you'd have half a leg to stando n. but citing google's use in this case means exactly what? you've cited a figure thats not an absolute value, so let me ask, 1% of what? you think their gmail servers are just dumping static text files over the network, that its 1% of almost nothing and thus SSL is free? or is there a chance those servers work their ass off, and they work so hard and do so much that what could be a colossal ssl task is margin error, simply because gmail is atlas, crunching the full text of your and 20GB account realtime with ease? it is impossible to do anything but guess, given your wishy washy proclamation.

last, maybe you have the budget to be running as many servers and to be hogging as much energy as you want, but what about all the mobile phone users connected to your site? is it acceptable that every single little AJAX interaction now has to go through the encryption/decryption straw on their 400 mhz oldschool mobile phone? what about places where, for various reasons, encryption is controlled or restricted? are we going to tell them no, unless you have full end to end encryption, you cant use the web?

the hubris of "just throw more end to end encryption" at it is bullshit, rotten wrong incorrect bullshit. what we need is a cookie solution not susceptible to man in the middle attacks. anything else is irresponsible overkill, and ignorant to the real problem and diverse requirements and use cases of the web. authentication does not have to be tied to end to end encryption, at least thats my mangled crippled understanding of Kerberos.

MeeGo is a Linux. That largely defines MeeGo and sets it apart. Oh sure, Android and countless other consumer electronics systems have Linux, but that distinction is relegated to some machinery under the hood kept far far away from users and often developers. MeeGo, on the other hand, is a Linux distribution, one with an integrated desktop environment that defines the distro, but it is still 'merely' a distro. It runs X. "Linux programs" will run on it.

Android threw out Linux. Nokia hopefully isnt dumb enough to hop on that bandwagon. Isnt dumb enough to turn over the fate of their company to an OS where they'll be able to have only the most meager means of distinguishing themselves, where distinguishing yourself will earn you animosity for fracturing the local ecosystem, where Nokia's existing code base will be useless.

Nokia can leverage huge code bases like GStreamer to get video conferencing, hardware supported media playing, to build DLNA systems on top of. You want that 21st century network functionality on Android? Have run rebuilding it chums. It's the same story, up and down, Android's core platform is tiny whereas the amount of Linux code out there to build off of is colossal.

Last, remember who bought Qt, and consider then that MeeGo is based on Qt.

MeeGo is a consumer Linux. That puts it in an elite realm with only one peer: Maemo. For this to become epic, only one thing is needed, UX. Everything non-technical must be done well. Even at these early stages, the netbook profile certainly is incredibly slick and integrated, hopefully the mobile profile will be similarly cared for.

let's add in some perspective: no matter what io scheduler you are using, that scheduler relies upon the user and the user's applications to tell the scheduler what priority to run things at. ionice is that program. if you dont use ionice or something equivalent, io intensive ops will starve other applications, because the scheduler wont know that it's a low priority job. that said, if you are experiencing programs utterly freezing, you might consider the Deadline scheduler, which uses response time for a request as it's performance metric. by default, it tries to insure all reads are satisfied within 500ms and all writes are satisfied within 5s, and this is tunable.

I just enjoyed the fact that 5-6Gb/s is a breath-stealing 150% the speed of a single lane of PCIe v2.0, and equal to SATA3's rate. Your implicit question of "what actually runs this SAN," whats behind this interfaces propositioned as blazing fast, is oh so much more dirt on the grave of this fluff piece. Still, from the outset, the "facts" present are already pretty funny.

Ok, perhaps not. However the idea that a digital cable could affect your systems sound is perfectly valid, as that digital signal-- even if remaining bit perfect between sender and receiver-- is emitting EM radiation that could affect the analog components of your computer. If people started using magnetrons for SATA cables, or other such absurdum, this issue could indeed become valid. Notching it down from absurdity, a well shielded cable will by definition cause less interference to the surrounding system components than a poorly shielded cable, and that is worth something. Whether SATA interference could manifest audibly is a question I wont attempt to entertain.

Not sure how consumers are supposed to understand the dangers. Halo 1 was released November 2001... gamers were supposed to avoid buying Halo 1 and every intervening xbox game for nine years because Microsoft may potentially be royal jerkoffs and decide for absolutely no good reason to shut down the old servers? That seems like a potentially large self sacrifice, considering how improbable it is Microsoft would be such absolute turd-sandwiches. The reality is, its incredible Microsoft pursued such a very small operational advantage for themselves over the interests of their customers-- the ground truth wasnt consumer ignorance, wasnt consumer protection, just Microsoft yanking peoples chain. Anyways, VPN is a solution to cirumvent MS deciding they didnt want to maintain XBox Live on Xbox1. Some mild thoughts on the issue here: http://games.slashdot.org/comments.pl?sid=1633946&cid=32014618

I too am rather surprised VPN isnt the main story here. Interesting to hear of a matchmaking service up to aid and assist, but I would've assumed the forums and anyone who gave a shit would have rallied together and carved out a niche in whatever VPN system needed. Honestly I was really hoping it'd prompt that kind of hacker spirit in gamers, that the closure would be a net good thing by getting people involved with their infrastructure and technology again. Who knows, maybe they are doing cool things, it just doesnt make as good a story. Albiet, yes, VPN is not a cure-all; matchmaking in particular seems like a very very difficult thing to deal with. I have no idea what happens when you throw 1000 XBox's on a LAN and start up System Link, but I dont think its very pretty / usable (iirc system link tended to assume there would only be one lan session per game going on). Would love to know!

"LAN play" is referred to in system, btw, as "System Link", and is just a crossover cable or LAN connection. Support is fairly comprehensive -- http://en.wikipedia.org/wiki/List_of_Xbox_System_Link_games -- but sometimes limited to two player.

The hard part was continuing backwards compatibility for the XBox Live service. It would've been maybe couple hundred man hours of devel/test costs a year just to make sure XBox1 was still working as they continue to roll out enhanced Xbox360 software.

That said, they're definitely a bunch of penny pinching scrooges. I've been businesses make similar heavyhanded "profit saving" measures w/r/t what they will and will not support, and lets just say the customers ended up not being very understanding or pleased finding their "working fine" setup kicked to the curb and them being saddled with a compromised "upgraded" hardware unit of dubious parity.

I had a BP6 with dual 450's running 575. Not nearly the same % increase, but the 450's were barely more expensive than the 300's by the time I mustered up the cash for the mobo and first cpu.

is your svn hosted on a 386? is it in someone's closet, on a dsl line? why is your source repository humiliatingly unbearably slow, and why does it take minutes for an svn update to even start? is the abominable performance a hardware, or software issue?

The 2.3kW of this sterling engine doesnt speak to that promise. The 40kW they hope to have a ground system producing doesnt instill much confidenc either. ISS produces around 130kW, via a colossal truss-work of solar panels. These are all far short of the 400kW power needed for the target baseline VASIMR engine, and well short of the multi MW power levels VASIMR really is designed for.

Nuclear power generates heat. Heat differential is then used to drive turbines. In space, you may be able to make heat, but what is there for the other end of this power generation equation; where does the cool body of mass come from, the essential other integral to power generation?

VASIMR itself, at high ISP's, is generating 10 megakelvin plasma. That itself has cooling challenges.

Right now, I dont see how these ideas are practical.

I wonder what the improvement of NX v. XCB is. XCB, I believe, does away with the sychronous request/reply nature of X and allows for async event handling. Pure conjecture, but that might provide a comparable advantage to the round-trip reductions provided by NX.

I used NX server for a hot six weeks as a persistent desktop I could remotely attach to; its main duty was holding open a session of XMMS. But the NX server was a perpetual pain. Configuring it was hellish, and sometimes it would crash. Lack of a rootless mode and the undocumented/proprietary nature were the final nails: I gave up the experiment. This was a long long time ago.

adding more disks is not the solution. the solution is more active and correcting consistency checking. the reason raid 5 and raid 1 rebuilds fail is because data is replicated, but errors are only discovered when something fails, when the shits already hit the fan. zfs, hammer, btrfs, they're all running headlong towards consitency checking because that is not good enough and not pre-emptive enough.

maybe now the cock-arsed moderators at wikipedia will stop deleting the 4.2.2.2 article.