People should really check out their blog, it's full of interesting tidbits. It seems SpiderOak are genuinely good guys, with a genuinely good service... even if sync between multiple computers is a bit wonky:)
I know how GL extensions work, and it definitely wasn't a fun model to work with. It's nice being able to test new features, yes, and back when new DirectX versions were ages between GL had the upper hand here... but having to manage several different vendor-specific codepaths sucked.
I don't agree that vendor extensions means OpenGL will always be ahead of DirectX anyway, since the platform as a whole isn't. With DX (especially after they dropped the crappy caps flags) you pretty much know what you're going to get...
IMHO if your IDE is typing 2/3rds of what needs to be typed without getting it wrong then there is something fundamentally wrong with the language. The autogenerated verbosity simply does not need to be there in that case.
Really depends on the type of autocompletion, IMHO.
I'll take (reasonably) verbose variable, function and class names over unix-C-style abbreviations any day - but it does require an IDE with decent autocompletion if you don't want to go insane... But given a decent IDE with "camelhumps" style autocompletion you end up typing less than the unix C programmer, while getting clearer source code.
I find that I spend a lot longer thinking about code architecture than on actual typing - even if using Notepad++ instead of an IDE - goes for all of the languages I use (C, C++, Java, C#). But it's definitely still nice having tools that reduce repetitive mechanical strain as well as letting me navigate large-ish codebases comfortably.
For added hilarity, the OS now allows applications to insert their own machine firewall exceptions.
What's your point? An app can do exactly the same on linux or BSD. Yeah, requires root, just like adding firewall exception requires admin privileges Windows. Besides, a rogue app will only succeed in turning off the firewall on the machine it's running on...
Ignoring AWE, VirtualAlloc doesn't give any guarantees about physical memory - it, at most, gives you a contiguous range of address space. Yes, you can specify MEM_COMMIT, but this doesn't guarantee that memory won't eventually be paged out.
There's VirtualLock, but "Each version of Windows has a limit on the maximum number of pages a process can lock. This limit is intentionally small to avoid severe performance degradation."
Good luck breaking into Sony/Nintendo and getting at the machines holding their private keys, though.
Again: this attack lets you extract leaked bits form the private keys - doesn't help in deriving private key from public key, which is what you'd want to break devices that verify code signing.
While it might sound like this attact is über-theoretical, do keep in mind that voltage fuzzing was recently used to (partially) break the PlayStation3 hypervisor... that's definitely not an open-source chip:)
It becomes harder to crack, indeed - especially because it it might not be easy to automatically locate the various triggers that need remote content. But it's certainly not impossible to do - in the application scene, hosting code and/or data on dongles and/or remote servers has been done for years, and even some of the really nasty protections have eventually been broken.
But if games are going to take as long to crack as Cubase, most of the piracy will probably be stopped. I wonder if there'll be any sales left either, though.
Don't overestimate the capability of slashdot readers. Really.
Some of the trojans today are pretty darn advanced. The executables have complex layers of encryption and polymorphic mutation, control connections are verified cryptographically (you can't just hack into and disinfect the botnet), et cetera.
Try reading malware analysis and reversing blogs:)
Who said anything about a hardcoded IP leading to the bot-master's own computer? It's not as if DNS entries would magically obscure the IP anyway, so a handful of hardcoded IPs for hacked or "safely setup colo" boxes could be employed.
Why rely on master control servers anyway? Hide control commands on blog comments, twitter updates, et cetera - might be slow crawling around finding these, so perhaps not super feasible for "flood that sucker now" commands... but could be used to supply new control server DNS/IP, updates, you name it.
Things [i]have[/i] changed since XP:) - by default it's cache system is pretty conservative. You can get around that by setting LargeSystemCache=1 (except if you're using ATI drivers - nastier-than-normal BSODs galore!). Then 32bit and the kernel/user address space split becomes the limiting factor.
With more physical RAM, a larger address-space, the cache has more room to play - and it doesn't hurt that Win7 (like Vista) is less conservative than XP was:)
There's a couple of things to keep in mind wrt. memory-mapped files, though. First, there's the pagetable entries required for the mapping when you MapViewOfFile - these aren't "free cache". You'll be using roughly 4kb PTE data for each 4mb you map, excluding other OS overhead and 1st-level PT (I don't think mmf utilizes the extend 4mb or 2mb pages, but I could be wrong)
Second, you have to consider that you'll be introducing a lot of (cpu, not disk) pagefaults - not really a problem on modern machines, but still something to keep in mind; you'll get a #PF for each 4kb touched, whereas with raw file I/O you can get away with a ring3ring0 switch for each 64kb on XP-and-older, or 4mb (Vista) or even 64mb (2008 server) of data.
mmap sure as hell is convenient though, especially on 64bit:)
Well, if you look at page activity per second, you'll get a good indication of whether the system is bogged down memory-wise. Trimming working sets might flush stuff to the pagefile, but won't give high continuous pages/sec rate.
Btw, "unused library" isn't best example - those can generally just be discarded and re-read from image, rather than having to be flushed to pagefile:)
Slashdot Mirror
+5 insightful. Or funny? Can't decide.
+1 for that.
People should really check out their blog, it's full of interesting tidbits. It seems SpiderOak are genuinely good guys, with a genuinely good service... even if sync between multiple computers is a bit wonky :)
Disclaimer: I'm using SO, the unpaid version.
...and you develop on those embedded systems?
Nice try.
I believe there is a setting to force enable the hardware acceleration, but i forget what its called...
Which is probably a bad idea if you don't have stable drivers :)
Wow, a perfectly reasonable & pragmatic comment on /.?
I'm in awe.
Ambiguous as "I'm not entirely sure whether that guy is straight or not", I take it?
I know how GL extensions work, and it definitely wasn't a fun model to work with. It's nice being able to test new features, yes, and back when new DirectX versions were ages between GL had the upper hand here... but having to manage several different vendor-specific codepaths sucked.
I don't agree that vendor extensions means OpenGL will always be ahead of DirectX anyway, since the platform as a whole isn't. With DX (especially after they dropped the crappy caps flags) you pretty much know what you're going to get...
...so, where are the fully open-source OpenGL library + drivers that has more features than (or even just feature parity with) DirectX 11?
Oh, I see.
IMHO if your IDE is typing 2/3rds of what needs to be typed without getting it wrong then there is something fundamentally wrong with the language. The autogenerated verbosity simply does not need to be there in that case.
Really depends on the type of autocompletion, IMHO.
I'll take (reasonably) verbose variable, function and class names over unix-C-style abbreviations any day - but it does require an IDE with decent autocompletion if you don't want to go insane... But given a decent IDE with "camelhumps" style autocompletion you end up typing less than the unix C programmer, while getting clearer source code.
I find that I spend a lot longer thinking about code architecture than on actual typing - even if using Notepad++ instead of an IDE - goes for all of the languages I use (C, C++, Java, C#). But it's definitely still nice having tools that reduce repetitive mechanical strain as well as letting me navigate large-ish codebases comfortably.
For added hilarity, the OS now allows applications to insert their own machine firewall exceptions.
What's your point? An app can do exactly the same on linux or BSD. Yeah, requires root, just like adding firewall exception requires admin privileges Windows. Besides, a rogue app will only succeed in turning off the firewall on the machine it's running on...
Ignoring AWE, VirtualAlloc doesn't give any guarantees about physical memory - it, at most, gives you a contiguous range of address space. Yes, you can specify MEM_COMMIT, but this doesn't guarantee that memory won't eventually be paged out.
There's VirtualLock, but "Each version of Windows has a limit on the maximum number of pages a process can lock. This limit is intentionally small to avoid severe performance degradation."
OK, thanks for the clarification :)
Good luck breaking into Sony/Nintendo and getting at the machines holding their private keys, though.
Again: this attack lets you extract leaked bits form the private keys - doesn't help in deriving private key from public key, which is what you'd want to break devices that verify code signing.
While it might sound like this attact is über-theoretical, do keep in mind that voltage fuzzing was recently used to (partially) break the PlayStation3 hypervisor... that's definitely not an open-source chip :)
I'm guessing here, but probably elliptic curve crypto.
Hate to break it to you, but ether & duct tape works just fine there as well. That, or a punch in the face - disciplining, as we call it.
That's almost my pickup line - except I go with ether instead of Chloroform. So much easier than slipping roofies in their drinks :)
It becomes harder to crack, indeed - especially because it it might not be easy to automatically locate the various triggers that need remote content. But it's certainly not impossible to do - in the application scene, hosting code and/or data on dongles and/or remote servers has been done for years, and even some of the really nasty protections have eventually been broken.
But if games are going to take as long to crack as Cubase, most of the piracy will probably be stopped. I wonder if there'll be any sales left either, though.
Their DRM is very easily circumvented, though: ether and duct tape.
Don't overestimate the capability of slashdot readers. Really. Some of the trojans today are pretty darn advanced. The executables have complex layers of encryption and polymorphic mutation, control connections are verified cryptographically (you can't just hack into and disinfect the botnet), et cetera. Try reading malware analysis and reversing blogs :)
Who said anything about a hardcoded IP leading to the bot-master's own computer? It's not as if DNS entries would magically obscure the IP anyway, so a handful of hardcoded IPs for hacked or "safely setup colo" boxes could be employed.
Why rely on master control servers anyway? Hide control commands on blog comments, twitter updates, et cetera - might be slow crawling around finding these, so perhaps not super feasible for "flood that sucker now" commands... but could be used to supply new control server DNS/IP, updates, you name it.
Ah, thanks for the clarification - didn't know that cached included dirty pages!
As for "shouldn't disable pagefile", that really depends on how much memory you have and how heavily you push it.
Things [i]have[/i] changed since XP :) - by default it's cache system is pretty conservative. You can get around that by setting LargeSystemCache=1 (except if you're using ATI drivers - nastier-than-normal BSODs galore!). Then 32bit and the kernel/user address space split becomes the limiting factor.
With more physical RAM, a larger address-space, the cache has more room to play - and it doesn't hurt that Win7 (like Vista) is less conservative than XP was :)
There's a couple of things to keep in mind wrt. memory-mapped files, though. First, there's the pagetable entries required for the mapping when you MapViewOfFile - these aren't "free cache". You'll be using roughly 4kb PTE data for each 4mb you map, excluding other OS overhead and 1st-level PT (I don't think mmf utilizes the extend 4mb or 2mb pages, but I could be wrong)
Second, you have to consider that you'll be introducing a lot of (cpu, not disk) pagefaults - not really a problem on modern machines, but still something to keep in mind; you'll get a #PF for each 4kb touched, whereas with raw file I/O you can get away with a ring3ring0 switch for each 64kb on XP-and-older, or 4mb (Vista) or even 64mb (2008 server) of data.
mmap sure as hell is convenient though, especially on 64bit :)
Well, if you look at page activity per second, you'll get a good indication of whether the system is bogged down memory-wise. Trimming working sets might flush stuff to the pagefile, but won't give high continuous pages/sec rate.
Btw, "unused library" isn't best example - those can generally just be discarded and re-read from image, rather than having to be flushed to pagefile :)