Specifically, Google is saying they will share their patents with anyone else who shares their source code.
It's an unfair deal (unlike the GPL, where the contract is "I share code, you share code"). Until they actually open source their MapReduce (and other) code, this is pure PR spin.
i mean, what do they know? after all, they are not you. . . you who can see into peoples true experiences, and understand that what they thought of as 'easy' was simply a lie, caused by their own competence if nothing else!!!! yes. you, truly, are the bane of clang. thank god you are here on the internet to set poor fools like me correct. poor stupid muzhiks that we are, we need your guidance, we need your holy word, we need your very soul to correct the wrongs of history!
I couldn't agree more. Especially in computer science. An employer does not give a shit about the science. They want someone who can do AD and DNS right away and image 1,000 computers at a time etc.
If all you know is do AD and DNS and image 1k computers, then that's what your employer will be hiring you for.
There's a reason why employers like Google are have these infamous algorithm heavy interviews. They don't want monkeys that can do AD and DNS. They want to hire people who can write systems to do it better than 1000 monkeys.
Well, I just happened to chime in on a discussion thread that mentioned IPOs and millionaires. As I said, you don't have to like Steve Jobs to recognize that he could probably have been able to do a lot of things without Woz.
Anyways, sorry to interrupt your salesmen / marketing scum bashing party. As long as it makes you happy.
I undergraduate degree in in law. And I am now happily employed as a software engineer at a tech company.
But then, of course, it's all networking -- I wouldn't have gotten past the HR resume screeners otherwise. I know some companies will give you an interview if somebody in the company is willing to refer you. And once you get into the interview stage, the degree is usually not a big deal. To be honest though, for younger candidates, the choice of doing a non-CS degree does add a tiny bit of doubt whether (s)he is really committed to a career in tech.... but normally I wouldn't start seriously doubting unless there's other evidence to raise my eyebrows.
As for the education value, well, it depends on how much you already know. I've been very fortunate to be able to learn pretty much everything that would have been covered in an undergraduate CS degree by a mixture of self learning, discussing and exchanging ideas with friends, peers and mentors, and informal training from participating in programming contests, etc. I guess you'll just have to try find out how much you don't know, and try to learn those things. If you find you're often stuck, then perhaps you'll want to get some "proper" education -- but only at a good school with a good CS program.
And if you just need that damn piece of paper, it could be actually cheaper (or at least, quicker) to try get a MSc in CS. I'm sure you could find some institutions that are willing to waive requirements that you have an undergraduate degree in the same field, especially that you already took some programming courses and could demonstrate some knowledge and experience in the field.
After Jobs was booted from Apple, he built two companies, without involvement from Woz.
One merged into Apple. One merged into Disney. The transactions were in the order of billions of dollars, and arguably revitalized the two companies, and helped them keep their positions as the leaders of their respective industries.
Call it salesmanship if you insist -- it was *very* fine salesmanship. Could Jobs have done it without Woz? Yes, he actually did it twice. You don't have to like him personally to recognize that.
In fact, when I learned algorithms, I learned mostly through pseudocode. Incidentally, simple Python code looks really really like "common pseudocode", the kind you'd see in textbooks like "CLRS".
I always thought the anal syntax of C/C++ (especially the latter) was a big distraction in learning the concepts of algorithms (and to a lesser degree, data structures).
However, C is *the* language for systems programming, and because it is low level enough that there are relatively few abstractions from the underlying hardware, and high level enough that it is almost universally portable (at least "ANSI C" is), it is an invaluable tool for learning how your system works without having to understand a gazillion CPU architectures.
These two things are generally quite different disciplines within CS -- there are people who are well versed in one but not the other. I don't know what algorithm class you did, but seriously you probably got the wrong idea from the class if you thought algorithms were trying to be a few percent faster -- usually good algorithms give orders of magnitude speedups, and the final few percent are squeezed out of the hardware by (for example) writing assembler code in the bottlenecks, taking advantage of CPU specific instructions like SSE, etc. I have a friend who programs GPUs to take advantage of their parallel processing capabilities -- but definitely it is not undergraduate material...
Of course, writing the bulk of the code in C/C++ instead of python obviously helps, but unless the focus of your course was really "how to make programs 5% faster", I doubt it really mattered.
'he's too hardware focused and this is a pure software job'. not realizing that there is over 10k lines of c/c++ code in my embedded project, not to mention the linux host side of things (the ip stack).
You're probably going to tell me to get off your lawn (I'm younger than your years of C experience), but anyways... My impression is that the kind of C code written for embedded systems is quite different from the C (or C++) code written for "full" applications. In embedded systems you write your own linked list, whereas in a modern non-embedded system you just #include <list> or something. Whereas the challenge in embedded systems is working with the limited feature set of the device, in non-embedded systems the challenge is really on how to structure the code and design to make things extensible and maintainable in the long run. Whereas in embedded systems it is often necessary to deploy tricks and hacks to optimize for performance, it is usually better to keep the code readable and easy to understand when your system has a quite few cycles left.
At least that's my understanding.
And my anecdotal experience is that people drawn to programming on embedded systems, tinker with hardware, writing low level code, quite often don't really "get" those more subtle nuances of larger scale software design and programming. Especially that you don't seem to have been interested in dabbling in the latest fads of this century (scripting/JIT-ed languages, grandiose "frameworks" etc)
And really, 10k of code is nothing... (especially if it contains a bunch of reimplemented linked lists and binary trees -- when we can #include <map>, those hundreds of lines of reimplementation of standard data structures can be reduced to a few lines)
I mean, I'm pretty much an idiot on low level programming and hardware, and I have quite a bit of respect for people who can tinker with electronics without frying them (I don't know why but I seem to have a talent for frying electronics). But from what I've seen, there is indeed a difference between the mindset of a "software guy" and a "hardware guy", and if that's the concern from the people making hiring decisions in the companies you've interviewed with, perhaps you need to somehow have a response to that, at least more than "I know how to write 10k lines of embedded C code".
Anyway this is what I'd be thinking if I were on the interviewer side for a "pure software" job. I might have been a bit blunt, but I suspect quite a few interviewers/employers would be thinking along these lines. You might want to give it a thought, and perhaps somehow preemptively reassure your prospective employers that you know more than writing glorified assembler (aka C), given that you're having some interviews soon. Good luck:)
You, being a physicist don't generally run into these people. I, on the other hand, have to deal with them daily.
You blame a wording used to more conveniently convey a meaning, because you surround yourself with idiots.
It's not a physicists problem that you end up with uncool friends. Give it up, no amount of "correct" wording is going to make sane people out of crackpots. Your attempts to teach them logic are going to be futile no matter what (hey, you called them crackpots, and you're _still_ arguing with them). Just give it up dude.
However, for passwords specifically, you'll need longer plaintext passwords for this to work. It doesn't matter how many bits your hash function is at, if the average password is only 8 characters of Alphanumeric (which, unfortunately, has entropy much less than 64 bits...). Salts help against things like rainbow attacks, but it won't help if an attacker is trying to crack one specific account that is protected by a 8 character password -- in that case, the speed of the hash function is the only variable in the cracking effort.
We all know we should have longer plaintext passwords, but the fact is -- our puny brains cannot remember random characters that well.
And passphrases haven't really caught on, unfortunately.
The only good thing is that I'll get many years of raises before I'm close to the position ceiling. I spent 7 years at the pay ceiling in a previous job I held for 8 years. Not even inflation raises there.
Maybe you're making a lot, so you wouldn't mind not having raises and stuff. If you asked me, though, the fact that you rationalized how HR offered you a discounted salary by the _promises_ of getting raises in the coming few years, is quite the hallmark of gullibility. I mean, sure, they might keep their promise, but there's nothing to prevent them from reneging on it.
I don't know where you work, but I don't see how come a company (or organization) could not even adjust your salary for inflation. In a way, I guess it's a good thing that you're happy with it, but most people would feel a bit resentful about it, even if it's a fact of life in at your workplace.
I thought the article was talking about 1% of computers very very occasionally giving wrong answers?
It's not like all their operations are failing. The test was run dozens of times per second, and if it fails once every few days, it's still a really low "failure rate" for a failing computer -- the only problem is that we expect the failure rate to be Zero.
Slashdot Mirror
For the record, I don't want to receive pictures of your boobs.
How is a fusion reactor to power every home so much more revolutionary than a smart phone to sit in every pocket?
30 years ago, something with that computational power would be at least the size of a power plant.
So, your laptop fifteen years ago is just like the Mainframes invented 40+ years ago, but smaller, faster and easier to use.
I am so impressed by the tech in your laptop. Obviously it is the greatest invention ever since slice bread.
By the way, the best movie EVER is Jurassic Park and the music the kids listen to these days SUCK. </sarcasm>
Where's your lawn?
Pics, or it didn't happen.
Specifically, Google is saying they will share their patents with anyone else who shares their source code.
It's an unfair deal (unlike the GPL, where the contract is "I share code, you share code"). Until they actually open source their MapReduce (and other) code, this is pure PR spin.
i mean, what do they know? after all, they are not you. . . you who can see into peoples true experiences, and understand that what they thought of as 'easy' was simply a lie, caused by their own competence if nothing else!!!! yes. you, truly, are the bane of clang. thank god you are here on the internet to set poor fools like me correct. poor stupid muzhiks that we are, we need your guidance, we need your holy word, we need your very soul to correct the wrongs of history!
There needs to be more "Right vs. Wrong".
Usually this degenerates to: "I'm right, you're wrong".
I'm concerned about your high Di-hydrogen Monoxide intake.
Yes, as you can see, they're the Good people. :)
I know what you mean, probably could have phrased it better. Anyways.
I couldn't agree more. Especially in computer science. An employer does not give a shit about the science. They want someone who can do AD and DNS right away and image 1,000 computers at a time etc.
If all you know is do AD and DNS and image 1k computers, then that's what your employer will be hiring you for.
There's a reason why employers like Google are have these infamous algorithm heavy interviews. They don't want monkeys that can do AD and DNS. They want to hire people who can write systems to do it better than 1000 monkeys.
No, but the fact that the owner of the Patent has a name that rhymes with poodle does.
I mean, seriously.
You don't have to get emotional over a free phone, and definitely don't have to get emotional over phones that you don't even own...
Well, I just happened to chime in on a discussion thread that mentioned IPOs and millionaires. As I said, you don't have to like Steve Jobs to recognize that he could probably have been able to do a lot of things without Woz.
Anyways, sorry to interrupt your salesmen / marketing scum bashing party. As long as it makes you happy.
I undergraduate degree in in law. And I am now happily employed as a software engineer at a tech company.
But then, of course, it's all networking -- I wouldn't have gotten past the HR resume screeners otherwise. I know some companies will give you an interview if somebody in the company is willing to refer you. And once you get into the interview stage, the degree is usually not a big deal. To be honest though, for younger candidates, the choice of doing a non-CS degree does add a tiny bit of doubt whether (s)he is really committed to a career in tech.... but normally I wouldn't start seriously doubting unless there's other evidence to raise my eyebrows.
As for the education value, well, it depends on how much you already know. I've been very fortunate to be able to learn pretty much everything that would have been covered in an undergraduate CS degree by a mixture of self learning, discussing and exchanging ideas with friends, peers and mentors, and informal training from participating in programming contests, etc. I guess you'll just have to try find out how much you don't know, and try to learn those things. If you find you're often stuck, then perhaps you'll want to get some "proper" education -- but only at a good school with a good CS program.
And if you just need that damn piece of paper, it could be actually cheaper (or at least, quicker) to try get a MSc in CS. I'm sure you could find some institutions that are willing to waive requirements that you have an undergraduate degree in the same field, especially that you already took some programming courses and could demonstrate some knowledge and experience in the field.
After Jobs was booted from Apple, he built two companies, without involvement from Woz.
One merged into Apple. One merged into Disney. The transactions were in the order of billions of dollars, and arguably revitalized the two companies, and helped them keep their positions as the leaders of their respective industries.
Call it salesmanship if you insist -- it was *very* fine salesmanship. Could Jobs have done it without Woz? Yes, he actually did it twice. You don't have to like him personally to recognize that.
Those are two different things.
In fact, when I learned algorithms, I learned mostly through pseudocode. Incidentally, simple Python code looks really really like "common pseudocode", the kind you'd see in textbooks like "CLRS".
I always thought the anal syntax of C/C++ (especially the latter) was a big distraction in learning the concepts of algorithms (and to a lesser degree, data structures).
However, C is *the* language for systems programming, and because it is low level enough that there are relatively few abstractions from the underlying hardware, and high level enough that it is almost universally portable (at least "ANSI C" is), it is an invaluable tool for learning how your system works without having to understand a gazillion CPU architectures.
These two things are generally quite different disciplines within CS -- there are people who are well versed in one but not the other. I don't know what algorithm class you did, but seriously you probably got the wrong idea from the class if you thought algorithms were trying to be a few percent faster -- usually good algorithms give orders of magnitude speedups, and the final few percent are squeezed out of the hardware by (for example) writing assembler code in the bottlenecks, taking advantage of CPU specific instructions like SSE, etc. I have a friend who programs GPUs to take advantage of their parallel processing capabilities -- but definitely it is not undergraduate material...
Of course, writing the bulk of the code in C/C++ instead of python obviously helps, but unless the focus of your course was really "how to make programs 5% faster", I doubt it really mattered.
The Surface doesn't have an arm.
Yeah, they run on Intels.
'he's too hardware focused and this is a pure software job'. not realizing that there is over 10k lines of c/c++ code in my embedded project, not to mention the linux host side of things (the ip stack).
You're probably going to tell me to get off your lawn (I'm younger than your years of C experience), but anyways... My impression is that the kind of C code written for embedded systems is quite different from the C (or C++) code written for "full" applications. In embedded systems you write your own linked list, whereas in a modern non-embedded system you just #include <list> or something. Whereas the challenge in embedded systems is working with the limited feature set of the device, in non-embedded systems the challenge is really on how to structure the code and design to make things extensible and maintainable in the long run. Whereas in embedded systems it is often necessary to deploy tricks and hacks to optimize for performance, it is usually better to keep the code readable and easy to understand when your system has a quite few cycles left.
At least that's my understanding.
And my anecdotal experience is that people drawn to programming on embedded systems, tinker with hardware, writing low level code, quite often don't really "get" those more subtle nuances of larger scale software design and programming. Especially that you don't seem to have been interested in dabbling in the latest fads of this century (scripting/JIT-ed languages, grandiose "frameworks" etc)
And really, 10k of code is nothing... (especially if it contains a bunch of reimplemented linked lists and binary trees -- when we can #include <map>, those hundreds of lines of reimplementation of standard data structures can be reduced to a few lines)
I mean, I'm pretty much an idiot on low level programming and hardware, and I have quite a bit of respect for people who can tinker with electronics without frying them (I don't know why but I seem to have a talent for frying electronics). But from what I've seen, there is indeed a difference between the mindset of a "software guy" and a "hardware guy", and if that's the concern from the people making hiring decisions in the companies you've interviewed with, perhaps you need to somehow have a response to that, at least more than "I know how to write 10k lines of embedded C code".
Anyway this is what I'd be thinking if I were on the interviewer side for a "pure software" job. I might have been a bit blunt, but I suspect quite a few interviewers/employers would be thinking along these lines. You might want to give it a thought, and perhaps somehow preemptively reassure your prospective employers that you know more than writing glorified assembler (aka C), given that you're having some interviews soon. Good luck :)
The meaning of deadlocks is clear, but I'm not sure "volatile" has any specific meaning, it seems language specific.
You, being a physicist don't generally run into these people. I, on the other hand, have to deal with them daily.
You blame a wording used to more conveniently convey a meaning, because you surround yourself with idiots.
It's not a physicists problem that you end up with uncool friends. Give it up, no amount of "correct" wording is going to make sane people out of crackpots. Your attempts to teach them logic are going to be futile no matter what (hey, you called them crackpots, and you're _still_ arguing with them). Just give it up dude.
crowd who think that feminists are coming to take their balls away
Yes they are. At least some of them. If juries trying females were female.
Yeah, measurement of evil is totally about body count.
Generally you're right.
However, for passwords specifically, you'll need longer plaintext passwords for this to work. It doesn't matter how many bits your hash function is at, if the average password is only 8 characters of Alphanumeric (which, unfortunately, has entropy much less than 64 bits...). Salts help against things like rainbow attacks, but it won't help if an attacker is trying to crack one specific account that is protected by a 8 character password -- in that case, the speed of the hash function is the only variable in the cracking effort.
We all know we should have longer plaintext passwords, but the fact is -- our puny brains cannot remember random characters that well.
And passphrases haven't really caught on, unfortunately.
The only good thing is that I'll get many years of raises before I'm close to the position ceiling. I spent 7 years at the pay ceiling in a previous job I held for 8 years. Not even inflation raises there.
Maybe you're making a lot, so you wouldn't mind not having raises and stuff. If you asked me, though, the fact that you rationalized how HR offered you a discounted salary by the _promises_ of getting raises in the coming few years, is quite the hallmark of gullibility. I mean, sure, they might keep their promise, but there's nothing to prevent them from reneging on it.
I don't know where you work, but I don't see how come a company (or organization) could not even adjust your salary for inflation. In a way, I guess it's a good thing that you're happy with it, but most people would feel a bit resentful about it, even if it's a fact of life in at your workplace.
I thought the article was talking about 1% of computers very very occasionally giving wrong answers?
It's not like all their operations are failing. The test was run dozens of times per second, and if it fails once every few days, it's still a really low "failure rate" for a failing computer -- the only problem is that we expect the failure rate to be Zero.