Windows 8 might be a LSD trip - but how on earth would you see that as a bad thing?;)
On a more serious note, I ended up with Win8 on my work laptop, since nobody at the workplace could point me a a working win7 image - I don't really see any of the FORmetRo crap on a day-to-day basis, so it mostly just feels like a win7 that's slightly faster and smoother. YMMV.
Why should Microsoft be allowed to dictate anything to hardware makers and thus non-Windows users?
I don't believe they should - and I hope I'm not giving off that impression. But I'm trying to deal with the actual facts of this whole miserable situation - which is bad enough without resorting to FUD. Better to stick with the facts, so we can cry (even more) foul if Microsoft violates their own guidelines...
Also, I don't find the idea of a "secure boot" in itself to be such a terribly bad idea... but the way it's being dropped upon us, with ARM being locked out from the beginning, and the level of uncertainty for the x86 future? Not good.
A lot of people I know see low-end dell laptops as a good choice to buy, and with all the talk of 'It's up to the OEMs to decide if to allow the bootloader to be unlocked' you can see where this might be going.
For Windows 8 certification, on x86 hardware, the user must have the option of disabling Secure Boot. See the official requiements (Windows 8 System Requirements PDF), page 121. A couple of select quotes:
17. Mandatory. On non-ARM systems, the platform MUST implement the ability for a physically present user to select between two Secure Boot modes in firmware setup: "Custom" and "Standard". Custom Mode allows for more flexibility as specified in the following:
18. Mandatory. Enable/Disable Secure Boot. On non-ARM systems, it is required to implement the ability to disable Secure Boot via firmware setup. A physically present user must be allowed to disable Secure Boot via firmware setup without possession of PKpriv.
Obviously, this is the requirements for Windows 8, and there's no guarantee Microsoft won't remove that for the next iteration - and it's only for x86, whereas ARM must be locked down. We should definitely be wary & weary, but let's still stick to the facts, right?
A polite "no" might be a good place to start, and then see what their response is. Ask them to explain why they want it removed and what basis they have for asking.
Start by asking the why/what-basis questions, politely, without explicitly declining their request. While waiting for reply, check out which lawyers are available in your area. Depending on Piriform's reply to your inquiry, go and talk to one of those lawyers - even if you're in.eu where IANALs believe you're allowed to do the importing based on laws around interoperability.
I had that turned on - but since click2play in firefox reqires (required?) the element to be visible, a few sites broke without any warning. For instance, the Garmin Communicator plugin I use to upload training sessions from my GPS running watch doesn't have any visible UI widgets.
Unfortunately for folks, this means fans of the game have to give EA the middle finger and pirate it, or simply not buy the game, but at least they've finally released a new version of the game after years.
The Java version is wrong. When you fix it, it is order of magnitudes better. I have no idea if the C# version was wrong too but it wouldn't surprise anyone. The test is rubbish.
He admits to be java novice and he made a novice mistake: The Java IO framework is blocking and was constructed so you would have one thread per connection. He failed to do that. He made it single threaded - and that is just wrong. Apart from making the thing slow as a turtle, it would never work in a real application. One hung connection would make his whole server stuck.
Well, sure, nobody in their right mind would make a blocking server that only supported a single client at a time (and I'd argue that nobody in their right mind would use non-async for high-performance work, thread-per-client is ouch). And apparently the class he derived from is known for bad performance.
Still, comparing the time taken to process a single request is as valid a benchmark as measuring what performance is like under heavy concurrent load. I do agree that on a whole the test is rubbish, and doesn't in any way show what the author believes it does.
Test 1: a low level function, usually done by the http server, is written by the user in java and c#. C# beats java handsdown.
...and even when the Java version has a level of abstraction removed and returns a hardcoded header string, the C# version (keeping it's higher abstraction level) still beats it.
Test 2: A function to generate a "full web site", (actually a simple web page with all the elements and trivial content). Java beats C# hands down.
Yup, what he times here is overhead of two very different frameworks, without actually using any of the framework functionality. No reason for that test to be skewed in any way, right?:-)
...presuming the compiler doesn't convert the if/else-if chain to a jump table.
If you need this kind of optimization, you're going to be doing such compiler (and version!) dependent programming that you might as well break out your trusty assembler. And when working at assembly code level, you can combine the two - heck, it might even make sense to have a few "cmp/je" for the most used cases, perhaps a binary-search-logic series of branching, and finally some jump tables of the rest. Or perhaps jump tables in the binary-search-logic branches, if your ranges are sparse.
Hint: profile your code and know what you're doing before you even consider such a thing. And write tools so you don't have to hand-code it.
Because it would be quite a lot of effort to retro-fit to the existing game? It would require a fair amount of scripting, as well as (possibly) new cinematics, and definitely some extra voice-acting. There's an expansion coming, that expansion has a new planet and new NPCs, and they've taken the time and effort to add gay stuff there. Move along, people, there's no bigotry to be seen here, only time and budget constraints.
None of those rely on the Java browser plugin - which is what gets you pwzned. Having JRE installed isn't a problem as long as you get rid of the browser plugin.
Same in Denmark - and we need it for.gov interaction as well. Remove the plugin from your primary browser, keep it in a secondary browser you launch just for Java stuff - and if you're slightly paranoid, keep that secondary browser in a virtual machine.
Sure, I have the JRE installed on my work laptop - but I sure as hell don't have the browser plugin installed. Nor Flash, nor AdobePDF. When I need Flash, I fire up Chrome for that particular site. When I need Java (which us Danes sadly do for online banking and government interaction), I fire up a virtual machine image dedicated just for that.
And my main browser, FireFox, has NoScript, AdBlockPlus, Ghostery and Certificate Patrol (any more addons I should know about?), work laptop as well as my own machines. But I digress. JRE: not a problem in and by itself. Just stay way clear off the browser plugin. And Flash. And AdobePDF.
...and then you have to build the deployment packages, fire them off to the production servers, etc. Even with automation, that can take a while. Not everybody runs a PHP/ruby/whatever shop and have their git repos on their production servers;p *duck and cover again*
In case it wasn't obvious: this post and the previous one are extremely tongue-in-cheek. I don't really condone hax0ring code straight into the Gibson.
Probably because they'd be ripped to pieces by certain Linux zealots if they released a product that support only a few distros because of support reasons? Or because they release a client that isn't opensource? (Which they probably have a hard time doing because of Pesky Patents and Evil NDAs.)
I personally hate DRM, but I kinda doubt the whole big media mafia will wake up and smell the coffee anytime soon, so what are we going to do in the meantime? Say "screw you, if you treat me like a pirate I'll act like a pirate" and leech.mkv files?
There's unit tests, and then of course the ultimate test: the production environment. If you set up perfect unit tests every single time, then you won't notice the difference between the two. If you're human like the rest of us, then every so often an assumption you hadn't even realized you'd been making will slip through your unit tests and you've got a production bug.
...and if you've left the old code commented out, it's much faster to hotpatch the production servers by flipping some comments around, than doing a full rollback.
So what they're really "predicting" is that some engineer at some medical supply company will get REALLY stupid and build in some back-door-thing that will open the company up to all kinds of lawsuits.
Yeah, I can see that happening. Eventually. Once. And when that company is sued out of existence then, hopefully, we'll all learn that not everything needs access to Facebook.
Under what circumstances do people use a data store that doesn't need data relationships?
Think (huge!) web content management systems with tree-structure, component-based pages where data varies widely from each page-type, and business requirements are constantly in flux.
While there's definitely data relationships, they're not necessarily very comfortable to map in a traditional RDBMS.
AFAIK, the keyfile is only useful to avoid brute-force attacks against your passphrase - it is still derived down to the same encryption/decryption key length as would have been derived from your passphrase. If you've got encrypted partitions loaded, the key is in memory, and the keyfile is utterly irrelevant.
Slashdot Mirror
Windows 8 might be a LSD trip - but how on earth would you see that as a bad thing? ;)
On a more serious note, I ended up with Win8 on my work laptop, since nobody at the workplace could point me a a working win7 image - I don't really see any of the FORmetRo crap on a day-to-day basis, so it mostly just feels like a win7 that's slightly faster and smoother. YMMV.
(Just like how if a thief has a boot CD, that Windows login password of yours isn't going to protect your data.)
EFS? :)
Not that I use it myself (much prefer TrueCrypt), but it sure is convenient and drop-dead transparent.
Why should Microsoft be allowed to dictate anything to hardware makers and thus non-Windows users?
I don't believe they should - and I hope I'm not giving off that impression. But I'm trying to deal with the actual facts of this whole miserable situation - which is bad enough without resorting to FUD. Better to stick with the facts, so we can cry (even more) foul if Microsoft violates their own guidelines...
Also, I don't find the idea of a "secure boot" in itself to be such a terribly bad idea... but the way it's being dropped upon us, with ARM being locked out from the beginning, and the level of uncertainty for the x86 future? Not good.
A lot of people I know see low-end dell laptops as a good choice to buy, and with all the talk of 'It's up to the OEMs to decide if to allow the bootloader to be unlocked' you can see where this might be going.
For Windows 8 certification, on x86 hardware, the user must have the option of disabling Secure Boot. See the official requiements (Windows 8 System Requirements PDF), page 121. A couple of select quotes:
17. Mandatory. On non-ARM systems, the platform MUST implement the ability for a physically present user to select between two Secure Boot modes in firmware setup: "Custom" and "Standard". Custom Mode allows for more flexibility as specified in the following:
18. Mandatory. Enable/Disable Secure Boot. On non-ARM systems, it is required to implement the ability to disable Secure Boot via firmware setup. A physically present user must be allowed to disable Secure Boot via firmware setup without possession of PKpriv.
Obviously, this is the requirements for Windows 8, and there's no guarantee Microsoft won't remove that for the next iteration - and it's only for x86, whereas ARM must be locked down. We should definitely be wary & weary, but let's still stick to the facts, right?
A polite "no" might be a good place to start, and then see what their response is. Ask them to explain why they want it removed and what basis they have for asking.
Start by asking the why/what-basis questions, politely, without explicitly declining their request. While waiting for reply, check out which lawyers are available in your area. Depending on Piriform's reply to your inquiry, go and talk to one of those lawyers - even if you're in .eu where IANALs believe you're allowed to do the importing based on laws around interoperability.
I had that turned on - but since click2play in firefox reqires (required?) the element to be visible, a few sites broke without any warning. For instance, the Garmin Communicator plugin I use to upload training sessions from my GPS running watch doesn't have any visible UI widgets.
Unfortunately for folks, this means fans of the game have to give EA the middle finger and pirate it, or simply not buy the game, but at least they've finally released a new version of the game after years.
There, FTFY.
The Java version is wrong. When you fix it, it is order of magnitudes better. I have no idea if the C# version was wrong too but it wouldn't surprise anyone. The test is rubbish.
He admits to be java novice and he made a novice mistake: The Java IO framework is blocking and was constructed so you would have one thread per connection. He failed to do that. He made it single threaded - and that is just wrong. Apart from making the thing slow as a turtle, it would never work in a real application. One hung connection would make his whole server stuck.
Well, sure, nobody in their right mind would make a blocking server that only supported a single client at a time (and I'd argue that nobody in their right mind would use non-async for high-performance work, thread-per-client is ouch). And apparently the class he derived from is known for bad performance.
Still, comparing the time taken to process a single request is as valid a benchmark as measuring what performance is like under heavy concurrent load. I do agree that on a whole the test is rubbish, and doesn't in any way show what the author believes it does.
Test 1: a low level function, usually done by the http server, is written by the user in java and c#. C# beats java handsdown.
...and even when the Java version has a level of abstraction removed and returns a hardcoded header string, the C# version (keeping it's higher abstraction level) still beats it.
Test 2: A function to generate a "full web site", (actually a simple web page with all the elements and trivial content). Java beats C# hands down.
Yup, what he times here is overhead of two very different frameworks, without actually using any of the framework functionality. No reason for that test to be skewed in any way, right? :-)
Also: profile-guided optimization
.
...presuming the compiler doesn't convert the if/else-if chain to a jump table.
If you need this kind of optimization, you're going to be doing such compiler (and version!) dependent programming that you might as well break out your trusty assembler. And when working at assembly code level, you can combine the two - heck, it might even make sense to have a few "cmp/je" for the most used cases, perhaps a binary-search-logic series of branching, and finally some jump tables of the rest. Or perhaps jump tables in the binary-search-logic branches, if your ranges are sparse.
Hint: profile your code and know what you're doing before you even consider such a thing. And write tools so you don't have to hand-code it.
Because it would be quite a lot of effort to retro-fit to the existing game? It would require a fair amount of scripting, as well as (possibly) new cinematics, and definitely some extra voice-acting. There's an expansion coming, that expansion has a new planet and new NPCs, and they've taken the time and effort to add gay stuff there. Move along, people, there's no bigotry to be seen here, only time and budget constraints.
Proper web browsing hygiene includes not infecting one's browser with the Java plugin to begin with.
There, fixed that for you.
Tell that to Jon "MultiAGP" Lech "DVD-Jon" Johansen... Norway, not Sweden, but still anything from the .us shouldn't have had any jurisdiction there.
None of those rely on the Java browser plugin - which is what gets you pwzned. Having JRE installed isn't a problem as long as you get rid of the browser plugin.
Same in Denmark - and we need it for .gov interaction as well. Remove the plugin from your primary browser, keep it in a secondary browser you launch just for Java stuff - and if you're slightly paranoid, keep that secondary browser in a virtual machine.
Sure, I have the JRE installed on my work laptop - but I sure as hell don't have the browser plugin installed. Nor Flash, nor AdobePDF. When I need Flash, I fire up Chrome for that particular site. When I need Java (which us Danes sadly do for online banking and government interaction), I fire up a virtual machine image dedicated just for that.
And my main browser, FireFox, has NoScript, AdBlockPlus, Ghostery and Certificate Patrol (any more addons I should know about?), work laptop as well as my own machines. But I digress. JRE: not a problem in and by itself. Just stay way clear off the browser plugin. And Flash. And AdobePDF.
...and especially when quoting religious, rather than scientific, reasons for not wanting to get the flu shot, I'm glad they're fired.
...and then you have to build the deployment packages, fire them off to the production servers, etc. Even with automation, that can take a while. Not everybody runs a PHP/ruby/whatever shop and have their git repos on their production servers ;p *duck and cover again*
In case it wasn't obvious: this post and the previous one are extremely tongue-in-cheek. I don't really condone hax0ring code straight into the Gibson.
Probably because they'd be ripped to pieces by certain Linux zealots if they released a product that support only a few distros because of support reasons? Or because they release a client that isn't opensource? (Which they probably have a hard time doing because of Pesky Patents and Evil NDAs.)
I personally hate DRM, but I kinda doubt the whole big media mafia will wake up and smell the coffee anytime soon, so what are we going to do in the meantime? Say "screw you, if you treat me like a pirate I'll act like a pirate" and leech .mkv files?
So, are there PCIe bus implementations (and SSDs) that support hotplug for consumer systems? And are at a reasonable pricetag? :-)
There's unit tests, and then of course the ultimate test: the production environment. If you set up perfect unit tests every single time, then you won't notice the difference between the two. If you're human like the rest of us, then every so often an assumption you hadn't even realized you'd been making will slip through your unit tests and you've got a production bug.
...and if you've left the old code commented out, it's much faster to hotpatch the production servers by flipping some comments around, than doing a full rollback.
/me ducks and covers.
So what they're really "predicting" is that some engineer at some medical supply company will get REALLY stupid and build in some back-door-thing that will open the company up to all kinds of lawsuits.
Yeah, I can see that happening. Eventually. Once. And when that company is sued out of existence then, hopefully, we'll all learn that not everything needs access to Facebook.
"backdoor" -> "remote code execution bug". Discuss.
Under what circumstances do people use a data store that doesn't need data relationships?
Think (huge!) web content management systems with tree-structure, component-based pages where data varies widely from each page-type, and business requirements are constantly in flux.
While there's definitely data relationships, they're not necessarily very comfortable to map in a traditional RDBMS.
AFAIK, the keyfile is only useful to avoid brute-force attacks against your passphrase - it is still derived down to the same encryption/decryption key length as would have been derived from your passphrase. If you've got encrypted partitions loaded, the key is in memory, and the keyfile is utterly irrelevant.