Nokia workers are a large chunk of those laid off, but still only a fraction of the workers laid off. They laid off a very large number of non-Nokia Microsoft employees as well.
And "products people wanted to buy" is irrelevant. If you're a good coder, then you can code regardless of the popularity of the product with the fan base. Anyone who hires employees based upon the successfulness of their previous companies is very short sighted. They don't even do that for hiring CEOs where having run a failed company and extracted all resources from it is not considered a black mark at all.
The reason Nokia made products that people didn't want to buy is because Microsoft's Elop took over and trashed it.
Note that if you use "bash -r -c" instead that you get a restricted shell (ie, more secure) and you don't get the vulnerability. Although I don't think there's a portable way to get a restricted shell with all shells out there (dash doesn't seem to have that ability), so things that want to execute a subshell to execute commands are in a pickle, either use the default shell with no restricted option or know which type of shell is being used underneath the hood.
Nothing I hope uses csh or tcsh as the default shell for scripts. They may use it as a default user shell, but those are too broken for use as a scripting shell.
Not sure why there's all this bash bashing. It's a great shell, and now it has an exploit but it's being patched. Why did the bashing occur before this exploit was found, and will the apologies come out when these other shells turn out to have some exploits?
Is this because the shell scripts were using incompatible features, or that they mistakenly used "#!/bin/bash" instead of "#!/bin/sh"? If you link bash to/bin/sh then you get a reasonably compatible shell version. But I have seen people things like "#!/bin/dash" which is just as misguided.
Because the original Bourne Shell was limited in many ways as a scripting environment (vastly better than csh of course). That's why people kept doing different shells. Korn Shell was a big improvement over/bin/sh, even with just scripting. And if you want just play/bin/sh, do you want the earliest version or the later versions that started adding features? Do you want/bin/sh to be Bourne Shell or do you want it to be a POSIX compliant shell?
The reason bash succeeded wildly is because it a great job of unifying both the easy of use of csh with the scripting of sh, along with the more advanced features and scripting from ksh, and it was POSIX compliant. Even better, if you invoke it as/bin/sh (which most systems do) then you get a subset of bash functionality for POSIX and sh compatibiliy (especially with respect to startup), meaning you can have portable shell scripts which can work on other shells.
Also the original/bin/sh had some licensing issues for awhile. It was AT&T intellectual property. People wanted an alternative implmentation. You can't get the "real" Bourne sh on many systems anymore, and if you could it was last updated back in 1989 I think so it's out of date with many things and not fully POSIX compliant.
Personally I think that's kind of goofy, their reasoning at least. It's not dash because of security, but dash because they think bash is big and bulky. Which is not a great argument on a PC (a good argument for an embedded system, which Debian isn't targeting). OpenWRT makes sense because it's an embedded system, so a full featured bash is not appropriate compared to a stripped down and limited shell.
This mis-feature is suppressed in restricted shells (bash -r), which I suspect is a good workaround for systems that use subshells but which can't guarantee that bash is patched. Except for this description with a restricted environment, I see nothing in the man page that hints that this feature exists.
I think it's actually a side effect of having exported functions be implemented as exported environment variables. A weird feature that lets you do "export func='() { commands; };'". This means that anything can export functions to a bash subshell. It's just plain weird in my view, but I guess if the only way to communicate to a subshell is with the plain environment then that's the only way to export functions.
Though, for future reference, different countries use different words for the same thing. Even English speakers do not all use the same slang used in England. It's called the pound key because for much longer than a century the "#" was used as abbreviation for pound (avoirdupois, not sterling) in ledgers and signs in groceries. You must be new to computers I suspect to not realize the hundreds of names assigned to '#'.
The competition isn't on the up and up though. Skilled workers are being pushed aside in preference to cheap workers with less skills. Then the work doesn't get done or doesn't get done well, and even more cheap workers are hired to make up for it. Competing does not mean being the cheapest.
It possibly comes around to need for short term quarterly profits, rather than long term profits. Thus hire the cheap people now, make it look like you're cutting costs, but remain rather mediocre with few technological advances (or get a huge fan base so that trivial tweaks cause them to buy new products on demand). You see this in technology, the new breakthrough products, small companies that get noticed for innovation, start off with local highly talented workers, then later when it's time to grow the company and it's publicly traded you get lots of cheaper workers to milk it for you.
The difference I think is that Microsoft has the gall to time this badly, just after massive layoffs, plus the gall to defend this publicly instead of quietly bribe the senators behind closed doors.
They can get 10, 20, or 50% cheaper jobs within the US too, just put the jobs in a cheaper area of the country. No different that picking an inexpensive area of Canada for the jobs instead of picking Vancouver.
Not quite right. Giving $100 to charity does not reduce your taxes by $100, instead it reduces your taxable income by $100. You do not "write off" that $100.
I agree, that was a bad video hitting all the corporate dogmas. It makes an unwarranted assumption behind the scenes that only H1-B workers have computer or technological skills. And that's the lie being told, that no domestic worker with the skills can be found, despite these jobs often needing only basic IT drone skills.
As for Microsoft, it should be made to prove under penalty of perjury that for any H1-B worker they want to get that they did not lay off a worker that had those skills.
I don't think I was implying this. However many times a candidate may be hired with the expectation that they be promoted after a year if they appear to be working out well. Sometimes the PhD may be hired for a specific purpose rather than a generic developer, as in someone who focused on security in school would be steered towards a track of becoming a security owner/guru (though not the only one necessarily).
Obviously if the person doesn't have the skills to be senior, then the person won't get there.
I wouldn't necessarily look for one that requires PhD, but there are many many many jobs that will hire a PhD even when one is not needed. Just avoid the elitist anti-education interviewers.
A lot of jobs you run across some buffoon who thinks the trivia is important. Such as someone who has started worshipping at the altar of design patterns and expects everyone else to have read the same book and know the names of the patterns. Or who wants to know the N rules of effective X development from some popular book.
I haven't done C++ in 5 years, but um, list, vector, map. There may be some obscure things like deque maybe, but no one uses though. I felt STL was highly overrated and generated bloated code (copying in entire structures via copy constructors rather than just being type safe containers of pointers). I've seen people implement the most trivial of things using std::map as if the chainsaw was the only tool in their toolbox, such as using a map that was guaranteed to have only one entry at any time.
But for C++ programming there is some concern about knowing some basics. Granted you don't have to know this to get a C++ job but it helps. Such as knowing about virtual destructors and why/when you need them. A few quick cramming sessions should be good enough to get a PhD person past that though.
And to be fair, I ask programming questions on interviews (for C). We get too many candidates for a job that involves programming every day who can't seem to do basic coding, or can't even do the coding that their resume implies they have experience with. But a CS PhD graduate who has done programming as part of the research should not have a problem with this.
Slashdot Mirror
Nokia workers are a large chunk of those laid off, but still only a fraction of the workers laid off. They laid off a very large number of non-Nokia Microsoft employees as well.
And "products people wanted to buy" is irrelevant. If you're a good coder, then you can code regardless of the popularity of the product with the fan base. Anyone who hires employees based upon the successfulness of their previous companies is very short sighted. They don't even do that for hiring CEOs where having run a failed company and extracted all resources from it is not considered a black mark at all.
The reason Nokia made products that people didn't want to buy is because Microsoft's Elop took over and trashed it.
Note that if you use "bash -r -c" instead that you get a restricted shell (ie, more secure) and you don't get the vulnerability.
Although I don't think there's a portable way to get a restricted shell with all shells out there (dash doesn't seem to have that ability), so things that want to execute a subshell to execute commands are in a pickle, either use the default shell with no restricted option or know which type of shell is being used underneath the hood.
Nothing I hope uses csh or tcsh as the default shell for scripts. They may use it as a default user shell, but those are too broken for use as a scripting shell.
Not sure why there's all this bash bashing. It's a great shell, and now it has an exploit but it's being patched. Why did the bashing occur before this exploit was found, and will the apologies come out when these other shells turn out to have some exploits?
Is this because the shell scripts were using incompatible features, or that they mistakenly used "#!/bin/bash" instead of "#!/bin/sh"? If you link bash to /bin/sh then you get a reasonably compatible shell version. But I have seen people things like "#!/bin/dash" which is just as misguided.
Because the original Bourne Shell was limited in many ways as a scripting environment (vastly better than csh of course). That's why people kept doing different shells. Korn Shell was a big improvement over /bin/sh, even with just scripting. And if you want just play /bin/sh, do you want the earliest version or the later versions that started adding features? Do you want /bin/sh to be Bourne Shell or do you want it to be a POSIX compliant shell?
The reason bash succeeded wildly is because it a great job of unifying both the easy of use of csh with the scripting of sh, along with the more advanced features and scripting from ksh, and it was POSIX compliant. Even better, if you invoke it as /bin/sh (which most systems do) then you get a subset of bash functionality for POSIX and sh compatibiliy (especially with respect to startup), meaning you can have portable shell scripts which can work on other shells.
Also the original /bin/sh had some licensing issues for awhile. It was AT&T intellectual property. People wanted an alternative implmentation. You can't get the "real" Bourne sh on many systems anymore, and if you could it was last updated back in 1989 I think so it's out of date with many things and not fully POSIX compliant.
Personally I think that's kind of goofy, their reasoning at least. It's not dash because of security, but dash because they think bash is big and bulky. Which is not a great argument on a PC (a good argument for an embedded system, which Debian isn't targeting). OpenWRT makes sense because it's an embedded system, so a full featured bash is not appropriate compared to a stripped down and limited shell.
This mis-feature is suppressed in restricted shells (bash -r), which I suspect is a good workaround for systems that use subshells but which can't guarantee that bash is patched. Except for this description with a restricted environment, I see nothing in the man page that hints that this feature exists.
I think it's actually a side effect of having exported functions be implemented as exported environment variables. A weird feature that lets you do "export func='() { commands; };'". This means that anything can export functions to a bash subshell. It's just plain weird in my view, but I guess if the only way to communicate to a subshell is with the plain environment then that's the only way to export functions.
Actually it rhymes better with hash.
Though, for future reference, different countries use different words for the same thing. Even English speakers do not all use the same slang used in England. It's called the pound key because for much longer than a century the "#" was used as abbreviation for pound (avoirdupois, not sterling) in ledgers and signs in groceries. You must be new to computers I suspect to not realize the hundreds of names assigned to '#'.
I used to think Adventure Shell was safe, until I met a grue in the dark.
Same as moving workers from Redmond to Detroit.
The competition isn't on the up and up though. Skilled workers are being pushed aside in preference to cheap workers with less skills. Then the work doesn't get done or doesn't get done well, and even more cheap workers are hired to make up for it. Competing does not mean being the cheapest.
It possibly comes around to need for short term quarterly profits, rather than long term profits. Thus hire the cheap people now, make it look like you're cutting costs, but remain rather mediocre with few technological advances (or get a huge fan base so that trivial tweaks cause them to buy new products on demand). You see this in technology, the new breakthrough products, small companies that get noticed for innovation, start off with local highly talented workers, then later when it's time to grow the company and it's publicly traded you get lots of cheaper workers to milk it for you.
The difference I think is that Microsoft has the gall to time this badly, just after massive layoffs, plus the gall to defend this publicly instead of quietly bribe the senators behind closed doors.
What is "seniorship"?
I was also discouraged that I had to debase myself and visit Facebook to see the video.
They can get 10, 20, or 50% cheaper jobs within the US too, just put the jobs in a cheaper area of the country. No different that picking an inexpensive area of Canada for the jobs instead of picking Vancouver.
Not quite right. Giving $100 to charity does not reduce your taxes by $100, instead it reduces your taxable income by $100. You do not "write off" that $100.
I agree, that was a bad video hitting all the corporate dogmas. It makes an unwarranted assumption behind the scenes that only H1-B workers have computer or technological skills. And that's the lie being told, that no domestic worker with the skills can be found, despite these jobs often needing only basic IT drone skills.
As for Microsoft, it should be made to prove under penalty of perjury that for any H1-B worker they want to get that they did not lay off a worker that had those skills.
What about neighbor's houses? Shoot them up, they're ugly and block your view of all the flat stuff that's on the other side.
Isn't the yuppie crowd a niche also?
So we basically just switch them from suck to blow?
Do you have any transcripts for your heart?
I don't think I was implying this. However many times a candidate may be hired with the expectation that they be promoted after a year if they appear to be working out well. Sometimes the PhD may be hired for a specific purpose rather than a generic developer, as in someone who focused on security in school would be steered towards a track of becoming a security owner/guru (though not the only one necessarily).
Obviously if the person doesn't have the skills to be senior, then the person won't get there.
I wouldn't necessarily look for one that requires PhD, but there are many many many jobs that will hire a PhD even when one is not needed. Just avoid the elitist anti-education interviewers.
People get programming jobs while undergraduates? Full time jobs or just part time on-campus stuff that no one will care about later?
A good employer may be employable for entry level jobs from the get go, but an advanced degree will pay off later.
A lot of jobs you run across some buffoon who thinks the trivia is important. Such as someone who has started worshipping at the altar of design patterns and expects everyone else to have read the same book and know the names of the patterns. Or who wants to know the N rules of effective X development from some popular book.
I haven't done C++ in 5 years, but um, list, vector, map. There may be some obscure things like deque maybe, but no one uses though. I felt STL was highly overrated and generated bloated code (copying in entire structures via copy constructors rather than just being type safe containers of pointers). I've seen people implement the most trivial of things using std::map as if the chainsaw was the only tool in their toolbox, such as using a map that was guaranteed to have only one entry at any time.
But for C++ programming there is some concern about knowing some basics. Granted you don't have to know this to get a C++ job but it helps. Such as knowing about virtual destructors and why/when you need them. A few quick cramming sessions should be good enough to get a PhD person past that though.
And to be fair, I ask programming questions on interviews (for C). We get too many candidates for a job that involves programming every day who can't seem to do basic coding, or can't even do the coding that their resume implies they have experience with. But a CS PhD graduate who has done programming as part of the research should not have a problem with this.