Use CRIU (Checkpoint Restore in Userspace) to checkpoint a hot version of grep that has been started and given a couple seconds to load in the dictionary and build it's pattern matcher and is thus just awaiting stdin (which you haven't given it). Restore a fresh instance for every new email, and pass the new email into the just-opened stdin for that restored, hot, waiting to go instance.
Instead of launching a fresh grep and initializing it with your corpus, this will create a grep that you can online which will be ready to go, awaiting input.
Ma-fucking-gic.
Traditionally one could achieve this effect by forking child workers, but that's a fucking huge pain in the ass as far as program design goes, making things really complicated- instead of a single program doing a single thing, it couples many uses of a program into a single programs lifestyle. Daemonized apps require system level management and have to be running. Service apps require complex interfaces to handle the different servicings they are performing. Decouple concerns (stay unix'y: stdin->program->stdout), and CRIU the bitch. Just use a hot program, rather than a cold one.
If the problem persists: fuck grep, it's pattern matching is rubbish and it's worthless. Please let us know. You might also consider 'head' 'ing the first 64k or some such of your email to avoid pattern matching the entire doc.
I'd love to be helping to polish and work on Pandora, AnonymousCoward, but after placing an order two months in, early December 08, I have no hardware and little hope.
OpenPandora has not disclosed how many units have made it out into the field. OpenPandora has not told us anything about the current rate of fulfillment for backlogged units. OpenPandora claims to be out of funds. OpenPandora claim to be using new sales to fund the backlog.
But we've been strung along for four years already, and I'd be shocked if I ever saw a thing from the $330 I mail ordered to them.
Get classic OpenPandora preorders fulfilled? Um, no, not at all. My guess is they've fulfilled considerably less than 1/2.
The devs state they don't have funds to fulfill orders, and that they're using new revenue to help fulfill the massive backlog they presently cannot afford.
I was in fairly early in the queue, early December `08. I've listened to hopeful progress report after hopeful progress report, but I'm skeptical I'll ever see a thing from the $330 I mail ordered them. If OpenPandora disclosed any information about the backlog fulfillment rate, I might have a hope, but they've left pre-orders hanging indefinitely and provided no solid information to build expectations or hopes against.
I'm not upset at what seems like my loss of $330: it was a good notion, I'm sure it's been a wild adventure, and I doubt anyone's going to bed on large piles of money, but getting strung along for four years, being told they've run out of money, and are trying to use sales to earn themselves back into the black... after four years of being strung along, I don't believe I'll ever see a thing.
CALEA's "Second Report & Order" states it's providers that must foot the bill. If our government paid for MS to acquire Skype perhaps there are shady deals afoot, but the US law states providers must pay the costs of snooping: the aforementioned shady deals would be very bad behavior from the US of A government, paying to acquire CALEA compliance.
The costs of running a couple thousand Linux nodes & paying bandwidth can not be that bad. MS certainly knew they'd have to remake Skype when they bought them, that the old P2P structure would have to go. I would want to think no grand conspiracy was involved, that what happened, the remodeling to a snoop-friendly infrastructure was simply due. It will be interesting to see going forwards, with the tentative thumbs up given to Skype plus the upcoming WebRTC technologies, how CALEA enforcement can be maintained: WebRTC certainly suggests decentralized models, although of course STUN & the various tunneling protocols are ripe for deliberately avoiding the easiest P2P routes & tunneling through glassboxes.
This premise, a managed AST you can manipulate programmatically (a SOM, Source Object Model), plus a managed compiler pipeline to compile, is nothing new. Boo language was doing this on.NET , and I'm sure there are many examples before it: Boo was started in 2003.
Yet another place the JWST (James Webb Space Telescope) would be fantastically useful!
Also, how seriously would the presence of previously undetectable ultra-cool stars affect the search for dark matter? Aren't we looking for energy/matter based off some energy level, and might that mass be tucked away in the form of ultra-cool stars, just to cool to detect?
i wasnt aware the addon had a toolbar. what i was aware of, is that it attempts to detect phone numbers on the page, and replaces those numbers with a graphical link that launches a skype call to that number.
it's pretty aggressive. just found out about it a couple months ago. QEMU based. they're doing some cool stuff with virtual devices; qxl is their accelerated graphics driver for Linux & Windows, and is probably gonna end up taking over for NX client now that they're closed source. and yes, i am aware there is a difference between a remote desktop and vm.
interested to see how RHEL manufacture disk images for the individual clients; needing a dedicated disk image for each OS is pretty bogus, but fairly common practice.
ecomotors sells diesel variants already. EM100, EM30, &c. they're ungodly expensive, but basically unparalleled if you need a high power high efficiency engine for a smallish drone aircraft.
a normal two stroke has recirculating air in the combustion chamber. when you exhaust you dump some fuel. when you intake you mix with existing fuel/air. air is coming and going from the same general area.
axial flow is the key to opposing piston. the chamber is shuffling a little forwards and backwards in opposed piston design, exposing intake and exhaust ports at opposite ends of the chamber. since air is moving in a net direction, circulation can be much more tightly controlled. there's huge potential to get air behaving according to design and engineering wishes-- the trick, the reason these guys are spending money and this hasnt taken over already, is that this timing is incredibly difficult and exacting. if done right, you get a two stroke that breathes as well as a four stroke. it's just not easy.
opposed piston's been championed for high efficiency and high power density since the 1950's. this is why. given the tooling we now have at our disposal to understand complex factors like airflow and thermal dynamics, it should be no surprise these things are gonna see a huge resurgence.
however it's old tech that was the leader in power density and efficiency, right up until they got upstaged by gas turbine. axial flow keeps air moving in one direction and not recirculating, which can go a huge way to mitigate the down sides of the two stroke design, while playing to two strokes natural power density advantage. coupled with increased kinetic capture (% of combustion surface which is piston v. chamber), opposed piston makes a lot of sense.
as far as replacements go, the only viable example i can think of is Fuel Cell, and frankly we arent energy rich enough to throw power away compressing and processing inputs to supply ourselves with a fuel replacement. fuel cell will make more economic sense in fifty years when petrofuels are expensive and grid power is cheap. for now, we have nearly a billion vehicles on the road and doubling the power/weight and fuel efficiency of the next ones we build makes a lot of sense.
also, power density has it's own merits at times, and these are unparalleled, being extremely efficient two strokes.
the fact is ICE has a lot of life left, and a lot of strengths. given that absolute 100% fact, this tech is sensible and ought be pursued.
Yes opposed piston is an old idea. For a time they were popular for high power density applications, and high efficiency applications (awesome axial flow properties). The reason this old creation fell out of favor is that, for the high-density extreme-efficiency uses fulfilled, there was an all around better replacement: gas turbines.
Gas turbines, however, have their own host of issues which make them unsuitable for all applications. Captone's 30kW microturbine, for example, is itself small, but has a sizable host of systems to support it and deal with the high temperatures, and costs a decent fraction of a million dollars last I checked. It and it's upsized bretheren are found in buses, and the occasional exotic-- see the CMT-380: a car custom built around the sizable & demanding microturbine power plant.
Given the challenges of using gas turbines, EcoMotors opting to dust off and enhance the next best thing makes some sense. There's big opportunity to evolve this already uber efficient two stroke's airflow with modern techniques and tooling. You've pointed out a number of mechanical challenges, but these seem to me considerably more mundane than the challenges of adapting a gas turbine to an every day machine. It may be old tech, but it's considerably better than what powers nearly a billion motorized vehicles on the roads and in the fields today.
I'd say the revival is both well timed and worth pausing to examine. Please feel free to contribute alternative reasons for their having fallen out of favor; would be most interesting to collect more facts or anecdotes.
Agreed that his motor is "smaller, lighter," and indeed it is a great product, but it sure as salt is not anything near less expensive, not now at least. Their EM100-- good for ~325 HP-- is well over $100k.
Great tech, would love to build a trike with a small one of these, but the price is insanely high atm.
i would've much rather someone developed a UPnP/DLNA realtime screen encoder, and then have used something like WiGig to wirelessly shuffle that completely bog standard DLNA stream to whatever series of displays it needs to go to. i'm sure there are advantages to one off'ing a wireless protocol, but i'd rather have had a standard for generic wireless communication, and a separate standard for system to system media sharing. all that really was needed to make that possible was, as i've said, realtime encoding of the screen into a DLNA compatible stream. that would've been much more flexible: any UPnP/DLNA device could consume the stream, assuming it has enough bandwidth to read all the bits. instead, you have to go out and buy dedicated transmitter and receivers just for this. truly a gratiutous waste of wideband, and media streaming.
keep in mind, WiDi requires an Intel Core processor and special software on the computer doing the realtime encoding. Can anyone confirm whether Wireless Display is compatible with the existing spec called Wireless HD? Wikipedia forwards WiDi to WirelessHD, but my understanding was Intel's spec was not inter-compatible.
1% of Google's CPU load.... that's 1% of the biggest collection of the largest data centers on the planet. Find a real metric for SSL cost, including any additional latency full end to end induces on each request, or GTFO.
Conversely, people saying "it's expensive" should have some numbers as well. Both on cpu utilization, request latency, effects on http pipelining, &c &c &c. SSL has numerous "costs", including places where full end to end encryption is not permitted. Ultimately the argument that seals the deal is the last one: this is an authentication problem, a trivial MITM attack; that doesnt require end to end encryption, that just requires authentication (see: Kerberos). Cookies, by themselves, just happen to not cut it there.
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.
Slashdot Mirror
Use CRIU (Checkpoint Restore in Userspace) to checkpoint a hot version of grep that has been started and given a couple seconds to load in the dictionary and build it's pattern matcher and is thus just awaiting stdin (which you haven't given it). Restore a fresh instance for every new email, and pass the new email into the just-opened stdin for that restored, hot, waiting to go instance.
Instead of launching a fresh grep and initializing it with your corpus, this will create a grep that you can online which will be ready to go, awaiting input.
Ma-fucking-gic.
Traditionally one could achieve this effect by forking child workers, but that's a fucking huge pain in the ass as far as program design goes, making things really complicated- instead of a single program doing a single thing, it couples many uses of a program into a single programs lifestyle. Daemonized apps require system level management and have to be running. Service apps require complex interfaces to handle the different servicings they are performing. Decouple concerns (stay unix'y: stdin->program->stdout), and CRIU the bitch. Just use a hot program, rather than a cold one.
If the problem persists: fuck grep, it's pattern matching is rubbish and it's worthless. Please let us know. You might also consider 'head' 'ing the first 64k or some such of your email to avoid pattern matching the entire doc.
I'd love to be helping to polish and work on Pandora, AnonymousCoward, but after placing an order two months in, early December 08, I have no hardware and little hope.
OpenPandora has not disclosed how many units have made it out into the field.
OpenPandora has not told us anything about the current rate of fulfillment for backlogged units.
OpenPandora claims to be out of funds.
OpenPandora claim to be using new sales to fund the backlog.
But we've been strung along for four years already, and I'd be shocked if I ever saw a thing from the $330 I mail ordered to them.
Get classic OpenPandora preorders fulfilled? Um, no, not at all. My guess is they've fulfilled considerably less than 1/2.
The devs state they don't have funds to fulfill orders, and that they're using new revenue to help fulfill the massive backlog they presently cannot afford.
I was in fairly early in the queue, early December `08. I've listened to hopeful progress report after hopeful progress report, but I'm skeptical I'll ever see a thing from the $330 I mail ordered them. If OpenPandora disclosed any information about the backlog fulfillment rate, I might have a hope, but they've left pre-orders hanging indefinitely and provided no solid information to build expectations or hopes against.
I'm not upset at what seems like my loss of $330: it was a good notion, I'm sure it's been a wild adventure, and I doubt anyone's going to bed on large piles of money, but getting strung along for four years, being told they've run out of money, and are trying to use sales to earn themselves back into the black... after four years of being strung along, I don't believe I'll ever see a thing.
CALEA's "Second Report & Order" states it's providers that must foot the bill. If our government paid for MS to acquire Skype perhaps there are shady deals afoot, but the US law states providers must pay the costs of snooping: the aforementioned shady deals would be very bad behavior from the US of A government, paying to acquire CALEA compliance.
The costs of running a couple thousand Linux nodes & paying bandwidth can not be that bad. MS certainly knew they'd have to remake Skype when they bought them, that the old P2P structure would have to go. I would want to think no grand conspiracy was involved, that what happened, the remodeling to a snoop-friendly infrastructure was simply due. It will be interesting to see going forwards, with the tentative thumbs up given to Skype plus the upcoming WebRTC technologies, how CALEA enforcement can be maintained: WebRTC certainly suggests decentralized models, although of course STUN & the various tunneling protocols are ripe for deliberately avoiding the easiest P2P routes & tunneling through glassboxes.
This premise, a managed AST you can manipulate programmatically (a SOM, Source Object Model), plus a managed compiler pipeline to compile, is nothing new. Boo language was doing this on .NET , and I'm sure there are many examples before it: Boo was started in 2003.
Re: dark matter, apparently not. http://science.slashdot.org/comments.pl?sid=2332984&cid=36800042
Yet another place the JWST (James Webb Space Telescope) would be fantastically useful!
Also, how seriously would the presence of previously undetectable ultra-cool stars affect the search for dark matter? Aren't we looking for energy/matter based off some energy level, and might that mass be tucked away in the form of ultra-cool stars, just to cool to detect?
i wasnt aware the addon had a toolbar. what i was aware of, is that it attempts to detect phone numbers on the page, and replaces those numbers with a graphical link that launches a skype call to that number.
http://www.redhat.com/virtualization/rhev/desktop/spice/
http://www.spicespace.org/
it's pretty aggressive. just found out about it a couple months ago. QEMU based. they're doing some cool stuff with virtual devices; qxl is their accelerated graphics driver for Linux & Windows, and is probably gonna end up taking over for NX client now that they're closed source. and yes, i am aware there is a difference between a remote desktop and vm.
interested to see how RHEL manufacture disk images for the individual clients; needing a dedicated disk image for each OS is pretty bogus, but fairly common practice.
ecomotors sells diesel variants already. EM100, EM30, &c. they're ungodly expensive, but basically unparalleled if you need a high power high efficiency engine for a smallish drone aircraft.
a normal two stroke has recirculating air in the combustion chamber. when you exhaust you dump some fuel. when you intake you mix with existing fuel/air. air is coming and going from the same general area.
axial flow is the key to opposing piston. the chamber is shuffling a little forwards and backwards in opposed piston design, exposing intake and exhaust ports at opposite ends of the chamber. since air is moving in a net direction, circulation can be much more tightly controlled. there's huge potential to get air behaving according to design and engineering wishes-- the trick, the reason these guys are spending money and this hasnt taken over already, is that this timing is incredibly difficult and exacting. if done right, you get a two stroke that breathes as well as a four stroke. it's just not easy.
opposed piston's been championed for high efficiency and high power density since the 1950's. this is why. given the tooling we now have at our disposal to understand complex factors like airflow and thermal dynamics, it should be no surprise these things are gonna see a huge resurgence.
i agree on everything except your conclusion. yes this is old tech. wikipedia lists examples as far back as 1907: http://en.wikipedia.org/wiki/Opposed-piston_engine .
however it's old tech that was the leader in power density and efficiency, right up until they got upstaged by gas turbine. axial flow keeps air moving in one direction and not recirculating, which can go a huge way to mitigate the down sides of the two stroke design, while playing to two strokes natural power density advantage. coupled with increased kinetic capture (% of combustion surface which is piston v. chamber), opposed piston makes a lot of sense.
as far as replacements go, the only viable example i can think of is Fuel Cell, and frankly we arent energy rich enough to throw power away compressing and processing inputs to supply ourselves with a fuel replacement. fuel cell will make more economic sense in fifty years when petrofuels are expensive and grid power is cheap. for now, we have nearly a billion vehicles on the road and doubling the power/weight and fuel efficiency of the next ones we build makes a lot of sense.
also, power density has it's own merits at times, and these are unparalleled, being extremely efficient two strokes.
the fact is ICE has a lot of life left, and a lot of strengths. given that absolute 100% fact, this tech is sensible and ought be pursued.
Yes opposed piston is an old idea. For a time they were popular for high power density applications, and high efficiency applications (awesome axial flow properties). The reason this old creation fell out of favor is that, for the high-density extreme-efficiency uses fulfilled, there was an all around better replacement: gas turbines.
Gas turbines, however, have their own host of issues which make them unsuitable for all applications. Captone's 30kW microturbine, for example, is itself small, but has a sizable host of systems to support it and deal with the high temperatures, and costs a decent fraction of a million dollars last I checked. It and it's upsized bretheren are found in buses, and the occasional exotic-- see the CMT-380: a car custom built around the sizable & demanding microturbine power plant.
Given the challenges of using gas turbines, EcoMotors opting to dust off and enhance the next best thing makes some sense. There's big opportunity to evolve this already uber efficient two stroke's airflow with modern techniques and tooling. You've pointed out a number of mechanical challenges, but these seem to me considerably more mundane than the challenges of adapting a gas turbine to an every day machine. It may be old tech, but it's considerably better than what powers nearly a billion motorized vehicles on the roads and in the fields today.
I'd say the revival is both well timed and worth pausing to examine. Please feel free to contribute alternative reasons for their having fallen out of favor; would be most interesting to collect more facts or anecdotes.
Agreed that his motor is "smaller, lighter," and indeed it is a great product, but it sure as salt is not anything near less expensive, not now at least. Their EM100-- good for ~325 HP-- is well over $100k.
Great tech, would love to build a trike with a small one of these, but the price is insanely high atm.
i would've much rather someone developed a UPnP/DLNA realtime screen encoder, and then have used something like WiGig to wirelessly shuffle that completely bog standard DLNA stream to whatever series of displays it needs to go to. i'm sure there are advantages to one off'ing a wireless protocol, but i'd rather have had a standard for generic wireless communication, and a separate standard for system to system media sharing. all that really was needed to make that possible was, as i've said, realtime encoding of the screen into a DLNA compatible stream. that would've been much more flexible: any UPnP/DLNA device could consume the stream, assuming it has enough bandwidth to read all the bits. instead, you have to go out and buy dedicated transmitter and receivers just for this. truly a gratiutous waste of wideband, and media streaming.
millisecond? but i want it nnnoowww
keep in mind, WiDi requires an Intel Core processor and special software on the computer doing the realtime encoding. Can anyone confirm whether Wireless Display is compatible with the existing spec called Wireless HD? Wikipedia forwards WiDi to WirelessHD, but my understanding was Intel's spec was not inter-compatible.
1% of Google's CPU load.... that's 1% of the biggest collection of the largest data centers on the planet. Find a real metric for SSL cost, including any additional latency full end to end induces on each request, or GTFO.
Conversely, people saying "it's expensive" should have some numbers as well. Both on cpu utilization, request latency, effects on http pipelining, &c &c &c. SSL has numerous "costs", including places where full end to end encryption is not permitted. Ultimately the argument that seals the deal is the last one: this is an authentication problem, a trivial MITM attack; that doesnt require end to end encryption, that just requires authentication (see: Kerberos). Cookies, by themselves, just happen to not cut it there.
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.