Please do keep the salts in the database, as not keeping salt there kinda implies using a single site-wide hardcoded salt... stored somewhere a hacker would probably get at just as easily as dumping the hashed passwords from the database.
Your salts are NOT a secret, and you DO want per-user salting.
...and at the same time does away with all resource leaks, not just memory leaks? Your pretty little garbage-collected languages take so much more effort to handle properly than C++'s RAII approach.
(I do Java for my day job, and I kinda think I'd rather do C++ if the jobs were around).
It's not just about free (or gratis, if you want to be anal), but also whether the product you're copying is something that's still pulling in revenue (or is supposed to).
FreeCIV and OpenTTD probably aren't too bad in that respect, and at least for OpenTTD you need to get game data elsewhere (ie., being a pirate or buying the original, thus not causing a lost sale).
I hope people can see there's a difference between doing that, and doing an almost 1:1 copy of a current game.
Breaking up a large and unwieldy function into calls to multiple (private-scoped) functions that are inlined is going to make the resulting binary size larger just how?
Because it's SO much better to thrown an exception - it works super well in tight inner loops, and the logic flow is always sure to a lot easier to follow than a break or goto.
From a technical standpoint though, function calls are fairly expensive so maybe you should avoid calling the function in the first place if you're going to just hit a return in it.
Just how old are the compilers/JIT'ers you're using?:-)
Hopefully, all anti-malware updates are digitally signed. Even for Symantec, which I generally don't have much respect for, I'd be surprised if they didn't have crypto signing for their updates.
Giving access to source code to "important enough" customers isn't really suspicious, but I doubt they'd be including any crypto keys along with that. If somebody finds any private keys in the source dumps, that would be a smoking gun - if not, nothing interesting to see here, move along - only the usual bad security policies.
Where exactly is the FUD? It's against Apple's license to run on non-Apple hardware, and they did go to some lengths to enforce the policy. Whether or not their protection is "a problem for the typical Slashdot reader" changes nothing with regards to those two points.
I'm not sure how they could make it *easier* let alone "trying hard to make it impossible" as you claim.
Perhaps by not writing code that specifically checks if it's running on Apple hardware and refuses to load parts of the OS if it isn't?
Apple did go to some lengths to make it hard running OS X on vanilla x86 systems. Like, AES-encrypting various system kexts and making it impossible to dump the memory of DSMOS driver to get the decryption keys.
Are you sure about that, remember we're talking about native code not DotNet. While DotNet does appear to have distinct 32bit and 64bit compilers the native C++ compiler appears to be only available as a 32bit executable that cross compiles to x64 or ia64 (and probably still 16bit too).
Positive. There's a 32bit native toolchain that can do 32bit and (iirc) 64bit output, whereas the 64bit toolchain can only do 64bit output. It's easy to verify - open the "Visual Studio x64 Win64 Command Prompt (2010)" and "Visual Studio Command Prompt (2010)" shortcuts, fire off a "cl/?" in each, and use Process Explorer to check the image type. One is 32bit, the other is 64bit.
Specifically, the Intel C compiler will generally be able to use all the instructions of the (Intel) CPU you point it at and will end up costing less (time, money or whatever) than doing the job by hand.
Less time, yeah, but not the fastest code. It's not a lot of fields where the fastest code matters, though, acceptable speed and fast time-to-market is the winning combination:)
And even if you have to use a compiler that doesn't understand your special hardware accelerated instruction the inline assembler is normally more than good enough to specify the rules for using it and optimising around it without the compiler knowing exactly what it does.
x64 versions of VC++ don't support inline assembly - it's better using an external assembler anyway, since you can then use the same code with different compilers. And if the code isn't big enough to warrant putting in an external.asm module, it's usually not worth even considering writing it in assembly. You can use intrinsic functions, but I see that mostly as a prototyping (or "enough extra speed without too much effort") tool, you can still do better register allocation by hand... if the algorithm is complex enough. But yes, it's a crapload of effort, and not very often worth it.
And I'll easily admit that I'm not a hot-shot assembly programming guru, so it'd take me disproportionate amounts of time besting today's compilers. Still, they aren't magic, they operate on heuristics designed by humans, and they can't generate 'perfect' code (optimization is NP-hard, and programs are frigging huge:)).
Hm, I haven't built the VS2010 CRT source, but it wasn't a problem with VS2005 or VS2008. The only thing I found a bit peculiar was that a few things (related to exception handling mostly, iirc) was only available in.obj form, no sources... but that didn't make building it problematic.
But what I'm wondering is why they don't switch to some dynamic linking? Modularize it into DLLs (or equivalent), so that each can be linked separately at compile time, and have all these modules pulled in at runtime. It really won't slow down loading much at all.
Except that they used to do that, and pulled a lot of code back into a monolithic xul.dll in order to improve load speed. Has to do with how the PE loader does on-demand page-in of executables, and how LTCG+PGO (apart from other optimizations) can order pages for execution locality.
AFAIK, LTCG doesn't work across EXE/DLL boundaries, "only" objects and (static) libraries within the same EXE/DLL - that does still very quickly add up, though. xul.dll is ~11MB on my FF8 install.
Slashdot Mirror
Use a service with client-side encryption (SpiderOak springs to mind, even if it has a terribad UI), or do your own encryption - problem solved.
IMHO you shouldn't rely solely on cloud backup, though, bad things can happen even to datacenters... but it's a nice supplement to your local backup.
As long as you only do hits on patent trolls, how exactly is it an unethical occupation?
Punchline? Isn't that when she refuses going back to the kitchen?
And considering what other phrases you can find in the Linux kernel tree... well, geez. Some people just don't have anything constructive to do.
Please do keep the salts in the database, as not keeping salt there kinda implies using a single site-wide hardcoded salt... stored somewhere a hacker would probably get at just as easily as dumping the hashed passwords from the database.
Your salts are NOT a secret, and you DO want per-user salting.
Premature optimization is bad. Premature pessimization is worse :)
...and at the same time does away with all resource leaks, not just memory leaks? Your pretty little garbage-collected languages take so much more effort to handle properly than C++'s RAII approach.
(I do Java for my day job, and I kinda think I'd rather do C++ if the jobs were around).
Scandinavia <3
Where education and healthcare are pretty decent, and funded through taxes.
While it lasts. Too many people around who think Teh AmeriKan Way is oh so wonderful are infesting the minds of the people.
It's not just about free (or gratis, if you want to be anal), but also whether the product you're copying is something that's still pulling in revenue (or is supposed to).
FreeCIV and OpenTTD probably aren't too bad in that respect, and at least for OpenTTD you need to get game data elsewhere (ie., being a pirate or buying the original, thus not causing a lost sale).
I hope people can see there's a difference between doing that, and doing an almost 1:1 copy of a current game.
An assembler assembles assembly source code.
Even gcc has been able to inline for many++ years. It's one of the more trivial optimizations.
Breaking up a large and unwieldy function into calls to multiple (private-scoped) functions that are inlined is going to make the resulting binary size larger just how?
Because it's SO much better to thrown an exception - it works super well in tight inner loops, and the logic flow is always sure to a lot easier to follow than a break or goto.
From a technical standpoint though, function calls are fairly expensive so maybe you should avoid calling the function in the first place if you're going to just hit a return in it.
Just how old are the compilers/JIT'ers you're using? :-)
...and what if the close/dispose method of one of those resources throws an exception?
You ruined it :-(
Add to that running sqlite vacuum on the various sqlite databases firefox uses, than defragmenting the files - can help a fair amount.
Hopefully, all anti-malware updates are digitally signed. Even for Symantec, which I generally don't have much respect for, I'd be surprised if they didn't have crypto signing for their updates.
Giving access to source code to "important enough" customers isn't really suspicious, but I doubt they'd be including any crypto keys along with that. If somebody finds any private keys in the source dumps, that would be a smoking gun - if not, nothing interesting to see here, move along - only the usual bad security policies.
Where exactly is the FUD? It's against Apple's license to run on non-Apple hardware, and they did go to some lengths to enforce the policy. Whether or not their protection is "a problem for the typical Slashdot reader" changes nothing with regards to those two points.
I'm not sure how they could make it *easier* let alone "trying hard to make it impossible" as you claim.
Perhaps by not writing code that specifically checks if it's running on Apple hardware and refuses to load parts of the OS if it isn't?
Apple did go to some lengths to make it hard running OS X on vanilla x86 systems. Like, AES-encrypting various system kexts and making it impossible to dump the memory of DSMOS driver to get the decryption keys.
Few companies have done as much for interoperability as Apple has done over the years.
Thanks for the laugh. Hope you're having a nice time in your reality distortion field. Time to clean up the coffee I spewed all over my keyboard.
32bit and 64bit toolchains
Are you sure about that, remember we're talking about native code not DotNet. While DotNet does appear to have distinct 32bit and 64bit compilers the native C++ compiler appears to be only available as a 32bit executable that cross compiles to x64 or ia64 (and probably still 16bit too).
Positive. There's a 32bit native toolchain that can do 32bit and (iirc) 64bit output, whereas the 64bit toolchain can only do 64bit output. It's easy to verify - open the "Visual Studio x64 Win64 Command Prompt (2010)" and "Visual Studio Command Prompt (2010)" shortcuts, fire off a "cl /?" in each, and use Process Explorer to check the image type. One is 32bit, the other is 64bit.
Specifically, the Intel C compiler will generally be able to use all the instructions of the (Intel) CPU you point it at and will end up costing less (time, money or whatever) than doing the job by hand.
Less time, yeah, but not the fastest code. It's not a lot of fields where the fastest code matters, though, acceptable speed and fast time-to-market is the winning combination :)
And even if you have to use a compiler that doesn't understand your special hardware accelerated instruction the inline assembler is normally more than good enough to specify the rules for using it and optimising around it without the compiler knowing exactly what it does.
x64 versions of VC++ don't support inline assembly - it's better using an external assembler anyway, since you can then use the same code with different compilers. And if the code isn't big enough to warrant putting in an external .asm module, it's usually not worth even considering writing it in assembly. You can use intrinsic functions, but I see that mostly as a prototyping (or "enough extra speed without too much effort") tool, you can still do better register allocation by hand... if the algorithm is complex enough. But yes, it's a crapload of effort, and not very often worth it.
And I'll easily admit that I'm not a hot-shot assembly programming guru, so it'd take me disproportionate amounts of time besting today's compilers. Still, they aren't magic, they operate on heuristics designed by humans, and they can't generate 'perfect' code (optimization is NP-hard, and programs are frigging huge :)).
Hm, I haven't built the VS2010 CRT source, but it wasn't a problem with VS2005 or VS2008. The only thing I found a bit peculiar was that a few things (related to exception handling mostly, iirc) was only available in .obj form, no sources... but that didn't make building it problematic.
But what I'm wondering is why they don't switch to some dynamic linking? Modularize it into DLLs (or equivalent), so that each can be linked separately at compile time, and have all these modules pulled in at runtime. It really won't slow down loading much at all.
Except that they used to do that, and pulled a lot of code back into a monolithic xul.dll in order to improve load speed. Has to do with how the PE loader does on-demand page-in of executables, and how LTCG+PGO (apart from other optimizations) can order pages for execution locality.
AFAIK, LTCG doesn't work across EXE/DLL boundaries, "only" objects and (static) libraries within the same EXE/DLL - that does still very quickly add up, though. xul.dll is ~11MB on my FF8 install.