Yay.. I am not the only one who got bit by this one.:)
I had assumed that std::list::size() was O(1).. Was 'enlightened' when, two threads jumping around a container segfaulted, costing me a couple of sleepless nights.
We can completely skip loading the application and its data parts from a slow disk, since all of them are already addressable directly in memory. We only have to deal with the 'initialization time' taken by the applications.
We actually did consider a similar option for an embedded system solution. A few MBs of "battery backed" RAM apart from the normal volatile memory. But well, the client ran away.. so..:-S
While you're dreaming, dream up an OS written from the start for such modern advances.
I am actually..:D But well, can only dream.. sigh!
Just imagine: - A power-cycle would leave the machine exactly where it was. Well, that would be a problem with buggy software. But, for such cases we could have a hard-reset of some sort.. - Absolutely no waiting for shutdown/power-up/etc. - Stuff like 'object serialization', 'state persistence', 'configuration persistence' etc.. would just be there. We wont have to deal with the whole lot of parsing, etc. nonsense. - Application startup would be blazingly fast. etc. etc.
Yeah, those chains need to be broken. The 21st century feels like stone age:-/
Building circuitry with sensors made out of low-cost ink printed on paper or an inexpensive plastic means the same hulking printers used to make labels can be used to make smart labels. But since it's not my field, I might just be full of hooey.
:) Like print it on a bundle of papers and make a cluster out of them?:D
I had the opportunity to try MeeGo on one of their devices (I am not sure which one that was). It was pretty good actually. They could have gotten somewhere if they had not been shifting from one technology to another like changing underwear.:-/
Slashdot Mirror
From "search" to "mobile" to "telecom" .. Way to go?
Things that get refreshed often dont get cached anyways. AJAX interactions mostly.
Coz thats where most of the Indian Intelligence Agencies spend their time on :-/
That's not the whole story. Don't forget that Ubuntu has shat out a turd called Ubiquity, too.
With GNOME 3.0, Ubiquity, and the uncertainty around QT/KDE, I haven't been this scared for my Linux desktop in years.
But, why is every one so scared of change? ;)
Qt's 'persumed' superiority over GTK is debatable.
"Can you imagine what's on Osama bin Laden's hard drive?"
Porn? :P
Oh yeah.. I agree. 'quick learning' can wait.. :D
Yes yes, I am jumping at the same thing :) I want 'the matrix' style 'quick learning'.. NOW NOW NOW :)
If obtaining API keys was the target, then we are gonna have a fresh wave of spam. Shyte.
I dont see how this is more painful than the media people trying to make money out of the situation.
Yay.. I am not the only one who got bit by this one. :)
I had assumed that std::list::size() was O(1) .. Was 'enlightened' when, two threads jumping around a container segfaulted, costing me a couple of sleepless nights.
I agree to "sticking with the standard".
They got to spend all those hard-earned dollars somewhere. :P
- Application startup would be blazingly fast.
What would battery-backed ram do to help that?
We can completely skip loading the application and its data parts from a slow disk, since all of them are already addressable directly in memory. We only have to deal with the 'initialization time' taken by the applications.
No.. seriously... :P
We actually did consider a similar option for an embedded system solution. A few MBs of "battery backed" RAM apart from the normal volatile memory. But well, the client ran away.. so .. :-S
While you're dreaming, dream up an OS written from the start for such modern advances.
I am actually.. :D But well, can only dream.. sigh!
Just imagine:
- A power-cycle would leave the machine exactly where it was. Well, that would be a problem with buggy software. But, for such cases we could have a hard-reset of some sort..
- Absolutely no waiting for shutdown/power-up/etc.
- Stuff like 'object serialization', 'state persistence', 'configuration persistence' etc.. would just be there. We wont have to deal with the whole lot of parsing, etc. nonsense.
- Application startup would be blazingly fast.
etc. etc.
Yeah, those chains need to be broken. The 21st century feels like stone age :-/
Checked it out. pretty cool :)
But still, 'persistent' memory gives too many opportunities.. I've been dreaming since morning about it. :D
With some lazy writing to solid-state-chips.. :D
Yeah, I am dreaming.. Sigh!! :-/
Building circuitry with sensors made out of low-cost ink printed on paper or an inexpensive plastic means the same hulking printers used to make labels can be used to make smart labels. But since it's not my field, I might just be full of hooey.
:) Like print it on a bundle of papers and make a cluster out of them? :D
On the whole, Microsoft has a probable benefit. For Nokia on the other hand, I am not so sure given Microsoft's past.
Its a BIG win for Microsoft. All of a sudden, they get to compete with the other big guys (iOS, Android, etc.) :P
I had the opportunity to try MeeGo on one of their devices (I am not sure which one that was). It was pretty good actually. They could have gotten somewhere if they had not been shifting from one technology to another like changing underwear. :-/