This is a very small attack surface, though, and if it's protected with a per-CPU unique ID and asymmetric encryption it could very well be 'uncrackable' unless the private key is leaked.
Sure, it could be - OTOH, it could also lead to online bullying perhaps being noticed before a poor kiddo commits suicide?
I used to hang out at the pub with a couple of my teachers every now and then, if facebook had been around back then it really wouldn't have been weird friending them. But hey, I live in Denmark - one of those countries that still has a bit of sanity left.
Myst was large for it's time, but if this "infinite" engine was to be used for something that doesn't just instantiate the same objects over and over, how much storage would it require? Good luck distributing even 1TB of map data... which probably wouldn't amount to all that much. But hey, we'll see - until the Euclideon publishes something substantial, all we can do is educated guesses.
And since it's been a year since they last uttered anything and they still aren't showcasing animations or decent lighting, well, my guess is that this won't amount to anything. Remember when The Next Big Thing was raytracing? Where are those game engines?
There was hype, but none of those really ludicrous claims that Euclideon are bringing. Furthermore, Doom had better lighting and it had animation. Oh, and the finite data didn't take up an insane amount of storage:)
I'm not saying the engine is a hoax, in fact I believe it to be very real. But until we see proper shading, animation and physics, it's utterly boring. Also, I'd like to hear Euclideon speak a bit about the size of data-on-disk. That is, when used for something interesting, and not their current boring "let's just instantiate the same objects a zillion times" map. Infinite quality, they say... infinite storage capability too?
What part of the video is new, though? Apart from cutting in video clips from more recent games, the "unlimited" stuff being shown doesn't look much different.
That's something I can fully agree with - I like what Chrome does with Java content (too bad it doesn't do the same for flash). It's good for helping against drive-by exploits, and it's simple enough to not confuse the Johns and Janes too much.
Of course it doesn't help for sites that lure people to enable whatever with the promise of "zomg hilarious pictures" or "britney dyking out with olsen twins", but you can't really help people who fall for that anyway.
AdBlock implemented default in browsers? Oh my an outcry there'd be... and there'd be a lot more incentive for trying to circumvent AB, leading to more websites where those of us running AB wouldn't have ads automatically blocked - ugh.
NoScript is simply a too advanced feature for Regular Joe & Jane. They'd be confused to death why 90% of the internet suddenly breaks for them, and they don't have the skills to selectively whitelist just the non-dangerous stuff. If you think noscript is trivial, your whitelist is probably too permissive.
All that said, I'm not an investor, just someone who wants to see the BTC succeed for my own needs as someone who needs to send money internationally on a regular basis.
In other words, you're a terrorism supporter! Good-for-nothing national security undermining "currency" humbug!
</troll>
Putting plugins (stuff like flash, silverlight, pdf plugin etc.) in a separate process and sandboxing that isn't a bad idea - but putting every addon in a separate process? Ugh, that would bloat up memory usage and slow down stuff because of inter-process communication. Not a viable solution, and I believe not even Chrome is doing that.
And I'm not sure there's much you can do to prevent memory leaks from addons. If somebody is accidentally keeping references around that aren't needed, no matter how smart a garbage collector is, it can't reap the memory. That's why you still see memory leaks in Java and C# applications as well.
Indeed, don't - blame Mozilla for not using SQLite correctly.
Using SQLite for history and bookmarks isn't such a bad idea, imho - by itself, SQLite is pretty damn light-weight (to the point where SQLite authors recommends to use it as a replacement for ad-hoc file storage). The problem with FireFox is it does things wrong - writes data too often, and writes it from the GUI thread and thus blocking the GUI. But having history and bookmarks in SQLite means you can do some pretty fast searches in it - might not be of value to you, but for some of us it's invaluable.
At one point, I ended up hacking into the chrome directory, grepping for "/usr/bin/Abiword-2.7" in a config file, and replacing it with "/usr/bin/abiword". When that config info ends up in an SQLite RDBMS, that hack is no longer possible.
Good thing it's in mimeTypes.rdf in XML format, then?:)
Assuming that's a correct estimate, that is a fair amount of code... but still isn't much compared to what FireFox ends up sucking up at the end of the day;)
DOS was *almost* exclusively used for bootstrapping Win9x, though, unless you installed 'unknown' drivers in config.sys. For normal systems, there would be no DOS or BIOS code used once Windows had booted. There were still thunks down to 16-bit protected mode code for parts that had been ported over from win3.x and hadn't been upgraded to full 32bit yet - but that's nowhere near DOS.
Just how much memory do the 32bit libraries take up, compared to the memory allocated by firefox? 8? 16? 32 megs? How much larger are the allocated data structures going to be, with int and pointer sizes doubling?
You can thank not having a stable kernel ABI for that - so it's more like "the kernel not playing well with proprietary drivers" than it's "the driver not playing well with the kernel".
Sometimes I wonder if one of the main reasons for not providing a stable kernel ABI is to make life hard for proprietary drivers, rather than "being able to optimize stuff".
Then again, ATi is notorious for making bad drivers. One of the only times I've had really bad crashes on Windows (after moving to NT) was because of ATi... and that was spectacular enough to result in two complete losses of data. Hurray backups!
He has no problems admitting quotes that are way sillier than the 640kb quote (which isn't so silly if you consider when it was allegedly said) - so I'm inclined to believe him on this one.
Just to be pedantic: we can actually address almost 64kb above 1mb in 16bit rm, see http://en.wikipedia.org/wiki/High_memory_area , Furthermore, on 386 and later CPUs, tricks can be employed to enter "unreal mode", "flat real mode" (etc.) so your code is still running 16bit realmode, but you have access to the full 32bit address space.
The there's PAE, introduced on the PPro well before the x64 architecture, which allows the use of "quite a bit more than 4gb" in 32bit mode - but of course only addressing 4gb at once, mapping the additional physical memory not entirely unlike how we mapped EMS or XMS back in the days. PAE also means it's no trouble at all utilizing a full 4GB physical memory on a 32bit OS, Windows (for some reasons - a few good, a lot not so good) won't let you use PHYSICAL_ADDRESSes > 4GB since XP SP1 (pre-SP1 it was 4gb physical memory total, not phy_addr limited).
Slashdot Mirror
Ah, those were the days <3
This is a very small attack surface, though, and if it's protected with a per-CPU unique ID and asymmetric encryption it could very well be 'uncrackable' unless the private key is leaked.
Admin passwords or admin privileges?
Taking local privilege escalation exploits into consideration, there's a damn big difference between the two.
Inappropriate? Creepy? Why?
Sure, it could be - OTOH, it could also lead to online bullying perhaps being noticed before a poor kiddo commits suicide?
I used to hang out at the pub with a couple of my teachers every now and then, if facebook had been around back then it really wouldn't have been weird friending them. But hey, I live in Denmark - one of those countries that still has a bit of sanity left.
Myst was large for it's time, but if this "infinite" engine was to be used for something that doesn't just instantiate the same objects over and over, how much storage would it require? Good luck distributing even 1TB of map data... which probably wouldn't amount to all that much. But hey, we'll see - until the Euclideon publishes something substantial, all we can do is educated guesses.
And since it's been a year since they last uttered anything and they still aren't showcasing animations or decent lighting, well, my guess is that this won't amount to anything. Remember when The Next Big Thing was raytracing? Where are those game engines?
When we first saw Doom, we could run doom.
There was hype, but none of those really ludicrous claims that Euclideon are bringing. Furthermore, Doom had better lighting and it had animation. Oh, and the finite data didn't take up an insane amount of storage :)
I'm not saying the engine is a hoax, in fact I believe it to be very real. But until we see proper shading, animation and physics, it's utterly boring. Also, I'd like to hear Euclideon speak a bit about the size of data-on-disk. That is, when used for something interesting, and not their current boring "let's just instantiate the same objects a zillion times" map. Infinite quality, they say... infinite storage capability too?
What part of the video is new, though? Apart from cutting in video clips from more recent games, the "unlimited" stuff being shown doesn't look much different.
Sarcasm? On the intarwebs? Wow, that'd be a frist!
That's something I can fully agree with - I like what Chrome does with Java content (too bad it doesn't do the same for flash). It's good for helping against drive-by exploits, and it's simple enough to not confuse the Johns and Janes too much.
Of course it doesn't help for sites that lure people to enable whatever with the promise of "zomg hilarious pictures" or "britney dyking out with olsen twins", but you can't really help people who fall for that anyway.
AdBlock implemented default in browsers? Oh my an outcry there'd be... and there'd be a lot more incentive for trying to circumvent AB, leading to more websites where those of us running AB wouldn't have ads automatically blocked - ugh.
NoScript is simply a too advanced feature for Regular Joe & Jane. They'd be confused to death why 90% of the internet suddenly breaks for them, and they don't have the skills to selectively whitelist just the non-dangerous stuff. If you think noscript is trivial, your whitelist is probably too permissive.
Context comprehension fail.
See the other wiki article on polymorphism.
I don't get "slashdot bitcoin" - I do get "slashdot delete account", though...
Which one of those two are the gullible sheeple most likely to read, though?
All that said, I'm not an investor, just someone who wants to see the BTC succeed for my own needs as someone who needs to send money internationally on a regular basis.
In other words, you're a terrorism supporter! Good-for-nothing national security undermining "currency" humbug! </troll>
Oh, that's just a false-flag operation to lull us all to sleep. And considering what has been leaked, boy golly they must be hiding some nasty secret!
Putting plugins (stuff like flash, silverlight, pdf plugin etc.) in a separate process and sandboxing that isn't a bad idea - but putting every addon in a separate process? Ugh, that would bloat up memory usage and slow down stuff because of inter-process communication. Not a viable solution, and I believe not even Chrome is doing that.
And I'm not sure there's much you can do to prevent memory leaks from addons. If somebody is accidentally keeping references around that aren't needed, no matter how smart a garbage collector is, it can't reap the memory. That's why you still see memory leaks in Java and C# applications as well.
*snip*
Don't blame the people that wrote SQLite.
Indeed, don't - blame Mozilla for not using SQLite correctly.
Using SQLite for history and bookmarks isn't such a bad idea, imho - by itself, SQLite is pretty damn light-weight (to the point where SQLite authors recommends to use it as a replacement for ad-hoc file storage). The problem with FireFox is it does things wrong - writes data too often, and writes it from the GUI thread and thus blocking the GUI. But having history and bookmarks in SQLite means you can do some pretty fast searches in it - might not be of value to you, but for some of us it's invaluable.
At one point, I ended up hacking into the chrome directory, grepping for "/usr/bin/Abiword-2.7" in a config file, and replacing it with "/usr/bin/abiword". When that config info ends up in an SQLite RDBMS, that hack is no longer possible.
Good thing it's in mimeTypes.rdf in XML format, then? :)
Assuming that's a correct estimate, that is a fair amount of code... but still isn't much compared to what FireFox ends up sucking up at the end of the day ;)
He probably meant 64-bit clean :)
DOS was *almost* exclusively used for bootstrapping Win9x, though, unless you installed 'unknown' drivers in config.sys. For normal systems, there would be no DOS or BIOS code used once Windows had booted. There were still thunks down to 16-bit protected mode code for parts that had been ported over from win3.x and hadn't been upgraded to full 32bit yet - but that's nowhere near DOS.
Just how much memory do the 32bit libraries take up, compared to the memory allocated by firefox? 8? 16? 32 megs? How much larger are the allocated data structures going to be, with int and pointer sizes doubling?
A vanilla install of firefox doesn't seem that bad - but once you add a handful of addons, things do get leaky as hell.
Would that be Mozillas fault, or the addon writers?
You can thank not having a stable kernel ABI for that - so it's more like "the kernel not playing well with proprietary drivers" than it's "the driver not playing well with the kernel".
Sometimes I wonder if one of the main reasons for not providing a stable kernel ABI is to make life hard for proprietary drivers, rather than "being able to optimize stuff".
Then again, ATi is notorious for making bad drivers. One of the only times I've had really bad crashes on Windows (after moving to NT) was because of ATi... and that was spectacular enough to result in two complete losses of data. Hurray backups!
He has no problems admitting quotes that are way sillier than the 640kb quote (which isn't so silly if you consider when it was allegedly said) - so I'm inclined to believe him on this one.
Just to be pedantic: we can actually address almost 64kb above 1mb in 16bit rm, see http://en.wikipedia.org/wiki/High_memory_area , Furthermore, on 386 and later CPUs, tricks can be employed to enter "unreal mode", "flat real mode" (etc.) so your code is still running 16bit realmode, but you have access to the full 32bit address space.
The there's PAE, introduced on the PPro well before the x64 architecture, which allows the use of "quite a bit more than 4gb" in 32bit mode - but of course only addressing 4gb at once, mapping the additional physical memory not entirely unlike how we mapped EMS or XMS back in the days. PAE also means it's no trouble at all utilizing a full 4GB physical memory on a 32bit OS, Windows (for some reasons - a few good, a lot not so good) won't let you use PHYSICAL_ADDRESSes > 4GB since XP SP1 (pre-SP1 it was 4gb physical memory total, not phy_addr limited).