Is it just me, or does 6 seem like a counter intuitive number of cores ?
Remember they need to put other stuff on the silicon too. The XBox 360's CPU uses three quarters of the die for three processors and puts the shared cache etc. in the fourth quarter. Six + support circuitry probably fits a square die better than eight + support.
If the interviewer can't tell the difference between good and bad code, they should probably delegate the technical assessment to somebody who can.
My point is that you can't review an arbitrary commit in some FLOSS project without deep understanding of the whole codebase. How would you know that the perfectly sensible looking patch to files A and B will break without an equivalent patch to file C, or that the changes you can see break some fundamental assumptions made elsewhere in the code, or that the patch ignores some common corner cases that occur in that project, or that the patch reimplements some other function that could have just been reused in a better safer way, etc.? Those things are the difference between good and bad code and without putting effort into investigating the existing project beyond the specimen patches you're not able to make that judgement.
If you wanted to delegate to someone who can judge those patches you'd have to either have an in-house expert on that FLOSS project or ask an external third party who you don't necessarily trust.
Alternatively I can give you the interview tests I've given dozens of times before and I know inside out. That's no extra effort for me and I have a good baseline to work against.
Evidently. So what, pray tell, was his point? Zero-tolerance of moody receptionists? The expectation that all deadlines pause, all office life stops when an interview candidates walks through the door for they need constant, immediate attention? Or something else?
8/10 times, in my experience.. an employer is just as happy to browse my Mercurial repositories as they are to give me a test.
Really? How does an employeer with no deep technical knowledge of your FLOSS codebase tell the difference between a good commit and a horribly buggy commit that was nevertheless intented and commented properly? At least with their own tests they're on their own turf.
That sort of treatment of a potential employee is disrespectful. If they'd interviewed me, decided they liked me and wanted to verify some skills and asked if I would take a test, that would be completely different.
I don't understand. Obviously they need to know that 1) they can work with you and 2) you're up to the job, but why does it matter which order they check them in?
Yes, they could have done their initial pleasantries better. But you basically binned the job because their receptionist had had a bad morning.
Before ALSA, one would open audio devices just like files, acquire audio data just like reading files, play audio just like writing files. ALSA went the Redmond way, one different API for each different type of data.
You mean it's a higher level abstraction. It's not just Microsoft who do that:-p
And isn't that more appropriate for audio? Who wants to implement their own mixer, link in format decoders to every app, etc? Sound is a resource shared across the whole desktop - don't you need something more complex to manage it than a simple pipe to the hardware? Do you have technical issues with the API or just philosophical ones?
It may be the basis, but it's a fairly easy to exploit basis.
So everyone keeps saying without actually backing that up.
It ought to be hard to get a wrong certificate. Issuing the wrong cert should have enough consequences for the CA they should be very careful that they never do. And we should make the mechanisms there are to update everyone's root certs and revocation lists, e.g. Microsoft's Root Certificate Update they roll out through Windows Update every few months, more familiar to users and more frequent.
I accept we can never make it impossible to get a fraudulent cert but I see no reason why it shouldn't be very hard. And no-one's convinced me that it actually isn't.
Much as I hate to say it, I think the best option is Microsoft. They can take an aggressive stance on removing bad root CAs from IE through root certificate updates they roll out through Windows Update every few months.
It's more direct than trying to sue the CA. The CA could try and fight MS legally to get the cert reinstated (there's probably contracts) but you wouldn't take on MS lightly. They have enough market share to make it hurt for the CA and can fight legal battles better than other browser vendors like Mozilla (say) can.
I'm not a business, but I do run websites and I like security.
Sure, me too. But certs without proper authentication are worthless, and authentication requires time and effort and that costs money. So if you want widely-trusted security you unfortunately have to pay for it. If you just want to secure your blog admin UI a self-signed cert is perfectly good enough because you're the only one that has to trust it.
That said, even if certs were free most hobbyist hosting packages don't include SSL hosting so you'll always have to pay extra.
Do you realize how easy it is to get a certificate from a vendor?
No. Citation needed. I've bought certs from Thawte and Comodo and both wanted copious documentation. Comodo even made us jump through a few hoops on trivial points before they'd issue the cert.
Now maybe there's other irresponsible CAs out there now but if they can be proven negligent they should get shutdown and their parent CAs - the ones whose certs are in our browsers - should take responsibility for making that happen. This is the basis for trust on the internet and it has to be made to work.
I have a bit of a mixed opinion of this - Certainly it's useful on untrusted websites... but I often have to use firefox with various exchange webmail servers... All using self-signed certificates.
So collect all the certs and install them as trusted roots in your browser? Job done.
Playing devils adv...Or the "whiny" webmaster will say that IE works fine and tell users to use that instead.
IE lets you temporarily trust a cert without jumping though as many hoops but it does give you an equivalent serious warning with lots of red text and "not recommended"s. They daren't do anything else really, no browser maker does.
Where do you get these magical $10/year SSL certs (assuming they're from CAs that are included by default in Windows, OSX, and Firefox)? I could use something like 10 of them.
Good idea. But the browser should automatically accept self signed certs. After all, it'll automatically accept insecure (http) connections.
No! You switch to https to get a secure connection to who you're intending to talk to. A self-signed certificate doesn't tell you anything about who you're talking to. If you don't want security, stay on http.
I'll assume someone paid the ransom at least once. So what key did they use to decrypt? Do us a favor and post it.
As for it being a trick to crack a root signing key, would they not have to have the private key to encrypt with to start? ... huh?
It works like this:
1. Virus generates a random encryption key and encrypts your data with it. Let's call this K. 2. Virus encrypts the random key with a RSA public key and instructs you to email that, R(K), and your money, to the ransomers. 3. The ransomers use their RSA private key to decrypt the encrypted random encryption key, R(K), into K. 4. You use the random encryption key they sold back to you, K, to rescue your data.
Someone else's decryption key, K', is not useful to you because your data was encrypted with a different random key K. You have an RSA-encrypted copy of your own random key, R(K), because that's what the ransomers need you to send them so they can sell you the decryption key K. We're trying to crack the RSA private key so we can generate K from R(K) without having to pay them money, i.e. sidestep step 3.
Even in a small company with 2 developers/engineers, this can often mean that they need 8 licenses.
1 for each developer/engineer for their primary machine = 2 licenses 1 for each developer/engineer for their home machine = 2 licenses 1 for each developer/engineer for their notebook = 2 licenses 1 for each test lab machine = 2 licenses
In total, we are now looking at 8 licenses for 2 blokes, when in reality only one of them will ever be using it at a time anyway. I know MS tools best and virtually none of your points apply to them. To start with they're per developer head not per install - in your example you'd need exactly 2 licenses for 2 blokes. No copy protection. Free 'express' edition downloads. etc.
And "we'll tell all our friends"? Are all of your friends developers??? The market for dev tools isn't anywhere near as big as say for office tools.
Why would the management invest $200 in saving you a week of overtime when they don't have to pay you for it? Because a week's unpaid overtime when it's not your fault pisses you off, and pissed-off programmers leave for better jobs elsewhere. Workforce morale isn't free - sometimes management need to invest money for morale's sake.
The part that doesn't follow for me is that tools failure implies unpaid overtime. Things go wrong you go straight back to management and sort it out - pressing on regardless is never the answer, especially when it's on your own time.
And LOTS of such code has been written. Examples include Internet Explorer, Windows Media Player, etc. FUD. Can you cite actual examples of them using secret APIs?
I've heard this repeated so often but no-one's ever convinced me it's true.
Didn't you say you wrote your own firmware? The article doesn't quite say that - it says they were developing one but not that they'd already rolled it out.
Slashdot Mirror
Is it just me, or does 6 seem like a counter intuitive number of cores ?
Remember they need to put other stuff on the silicon too. The XBox 360's CPU uses three quarters of the die for three processors and puts the shared cache etc. in the fourth quarter. Six + support circuitry probably fits a square die better than eight + support.
Not true. There are cases where it will matter.
OK, but you wouldn't ask "++i or i++" in isolation like the post I replied to did.
If the interviewer can't tell the difference between good and bad code, they should probably delegate the technical assessment to somebody who can.
My point is that you can't review an arbitrary commit in some FLOSS project without deep understanding of the whole codebase. How would you know that the perfectly sensible looking patch to files A and B will break without an equivalent patch to file C, or that the changes you can see break some fundamental assumptions made elsewhere in the code, or that the patch ignores some common corner cases that occur in that project, or that the patch reimplements some other function that could have just been reused in a better safer way, etc.? Those things are the difference between good and bad code and without putting effort into investigating the existing project beyond the specimen patches you're not able to make that judgement.
If you wanted to delegate to someone who can judge those patches you'd have to either have an in-house expert on that FLOSS project or ask an external third party who you don't necessarily trust.
Alternatively I can give you the interview tests I've given dozens of times before and I know inside out. That's no extra effort for me and I have a good baseline to work against.
That's the point going over your head.
Evidently. So what, pray tell, was his point? Zero-tolerance of moody receptionists? The expectation that all deadlines pause, all office life stops when an interview candidates walks through the door for they need constant, immediate attention? Or something else?
how about this one. "Ok, you know C. Which is correct? ++i or i++?" You just removed even more with that one.
In C? Why does it matter?
The issue with pre-vs-post increment is temporary object lifetimes in *C++*. Not C.
8/10 times, in my experience .. an employer is just as happy to browse my Mercurial repositories as they are to give me a test.
Really? How does an employeer with no deep technical knowledge of your FLOSS codebase tell the difference between a good commit and a horribly buggy commit that was nevertheless intented and commented properly? At least with their own tests they're on their own turf.
That sort of treatment of a potential employee is disrespectful. If they'd interviewed me, decided they liked me and wanted to verify some skills and asked if I would take a test, that would be completely different.
I don't understand. Obviously they need to know that 1) they can work with you and 2) you're up to the job, but why does it matter which order they check them in?
Yes, they could have done their initial pleasantries better. But you basically binned the job because their receptionist had had a bad morning.
Before ALSA, one would open audio devices just like files, acquire audio data just like reading files, play audio just like writing files. ALSA went the Redmond way, one different API for each different type of data.
You mean it's a higher level abstraction. It's not just Microsoft who do that :-p
And isn't that more appropriate for audio? Who wants to implement their own mixer, link in format decoders to every app, etc? Sound is a resource shared across the whole desktop - don't you need something more complex to manage it than a simple pipe to the hardware? Do you have technical issues with the API or just philosophical ones?
It may be the basis, but it's a fairly easy to exploit basis.
So everyone keeps saying without actually backing that up.
It ought to be hard to get a wrong certificate. Issuing the wrong cert should have enough consequences for the CA they should be very careful that they never do. And we should make the mechanisms there are to update everyone's root certs and revocation lists, e.g. Microsoft's Root Certificate Update they roll out through Windows Update every few months, more familiar to users and more frequent.
I accept we can never make it impossible to get a fraudulent cert but I see no reason why it shouldn't be very hard. And no-one's convinced me that it actually isn't.
And who is going to make them make that happen?
Much as I hate to say it, I think the best option is Microsoft. They can take an aggressive stance on removing bad root CAs from IE through root certificate updates they roll out through Windows Update every few months.
It's more direct than trying to sue the CA. The CA could try and fight MS legally to get the cert reinstated (there's probably contracts) but you wouldn't take on MS lightly. They have enough market share to make it hurt for the CA and can fight legal battles better than other browser vendors like Mozilla (say) can.
I'm not a business, but I do run websites and I like security.
Sure, me too. But certs without proper authentication are worthless, and authentication requires time and effort and that costs money. So if you want widely-trusted security you unfortunately have to pay for it. If you just want to secure your blog admin UI a self-signed cert is perfectly good enough because you're the only one that has to trust it.
That said, even if certs were free most hobbyist hosting packages don't include SSL hosting so you'll always have to pay extra.
Do you realize how easy it is to get a certificate from a vendor?
No. Citation needed. I've bought certs from Thawte and Comodo and both wanted copious documentation. Comodo even made us jump through a few hoops on trivial points before they'd issue the cert.
Now maybe there's other irresponsible CAs out there now but if they can be proven negligent they should get shutdown and their parent CAs - the ones whose certs are in our browsers - should take responsibility for making that happen. This is the basis for trust on the internet and it has to be made to work.
I have a bit of a mixed opinion of this - Certainly it's useful on untrusted websites... but I often have to use firefox with various exchange webmail servers... All using self-signed certificates.
So collect all the certs and install them as trusted roots in your browser? Job done.
That's more trustworthy than trusting a third party to do the same, is it not?
Yes, but *far* less convenient. Would you actually do that? Or would you move on to a competing site?
And is it really? How do your callers know the phone call hasn't been MITMed?
CHECK if it is MY self-signed certificate
If it's YOUR self-signed certificate, you add the signing root to your Firefox as a trusted root. Job done.
Self-signed certs are only an issue when you need to authenticate to someone else.
Yeah, cause we all want to spend +$100 for a company to say "yeah, it's real".
Well those companies only actually do that if they're confident it is. Most have some financial guarantees to back that up.
Besides, $100 is chump change to a business.
Playing devils adv...Or the "whiny" webmaster will say that IE works fine and tell users to use that instead.
IE lets you temporarily trust a cert without jumping though as many hoops but it does give you an equivalent serious warning with lots of red text and "not recommended"s. They daren't do anything else really, no browser maker does.
Where do you get these magical $10/year SSL certs (assuming they're from CAs that are included by default in Windows, OSX, and Firefox)? I could use something like 10 of them.
We use Comodo InstantSSL. Nearer $100 but very widely trusted.
Good idea. But the browser should automatically accept self signed certs. After all, it'll automatically accept insecure (http) connections.
No! You switch to https to get a secure connection to who you're intending to talk to. A self-signed certificate doesn't tell you anything about who you're talking to. If you don't want security, stay on http.
Ugh, still no token ring support.
It had token ring support circa 2000 and you can probably resurrect the drivers if you need it.
OTOH if you're still using Token Ring you probably have Madge or Olicom cards whereas the best Linux support was for chipsets like the IBM Olympic.
As for it being a trick to crack a root signing key, would they not have to have the private key to encrypt with to start? ... huh?
It works like this:
1. Virus generates a random encryption key and encrypts your data with it. Let's call this K.
2. Virus encrypts the random key with a RSA public key and instructs you to email that, R(K), and your money, to the ransomers.
3. The ransomers use their RSA private key to decrypt the encrypted random encryption key, R(K), into K.
4. You use the random encryption key they sold back to you, K, to rescue your data.
Someone else's decryption key, K', is not useful to you because your data was encrypted with a different random key K. You have an RSA-encrypted copy of your own random key, R(K), because that's what the ransomers need you to send them so they can sell you the decryption key K. We're trying to crack the RSA private key so we can generate K from R(K) without having to pay them money, i.e. sidestep step 3.
1 for each developer/engineer for their primary machine = 2 licenses
1 for each developer/engineer for their home machine = 2 licenses
1 for each developer/engineer for their notebook = 2 licenses
1 for each test lab machine = 2 licenses
In total, we are now looking at 8 licenses for 2 blokes, when in reality only one of them will ever be using it at a time anyway. I know MS tools best and virtually none of your points apply to them. To start with they're per developer head not per install - in your example you'd need exactly 2 licenses for 2 blokes. No copy protection. Free 'express' edition downloads. etc.
And "we'll tell all our friends"? Are all of your friends developers??? The market for dev tools isn't anywhere near as big as say for office tools.
The part that doesn't follow for me is that tools failure implies unpaid overtime. Things go wrong you go straight back to management and sort it out - pressing on regardless is never the answer, especially when it's on your own time.
I've heard this repeated so often but no-one's ever convinced me it's true.