Far be it from me to defend Broadcom (as no one in their right mind
should choose the BCM1250), but the 1250 is an old, nearly unmaintained
CPU. It was done about 6 years ago, when the HT spec was hardly off
the ground. So, yes, it implements a non-standard version of HT; but
the HT spec was still evolving.
Instead of the harping on the implementation (which was done in a slapdash, amatuerish fashion by SiByte in order to make a quick buck - and screw the customer), you should blast Broadcom for basically
dropping support for this CPU. Broadcom has done almost nothing whatsoever
to improve the CPU. In fact, they go far out of their way to avoid the
needed improvements. Witness the completely bogus (and nearly useless)
JTAG support for the 1250.
They used to have GDB support for it for free. That's all gone; and
in fact no longer works with the new Rev C 1250's. Instead, you have
nearly useless third-party support from Corelis and Greenhills.
Forget source code debugging if you have a ClearCase SCM, unless you
want to go through a bit of pain and hackery.
And, hells bells, let's not talk about the memory controller, which is
the worst one I've ever seen. If there were ever anything which needed
improvement, it is that.
In short, if you chose the BCM1250, you were an idiot and deserve what
you got. No sane embedded person would do so. A clueless architect might,
but not a real embedded engineer.
I once had to inherit this mess; and I'm delighted to be done with it.
So just avoid Broadcom altogether. They have an established track record
of leaving you high and dry should you make the mistake of depending
on them. And they just don't give a damn about their customers.
"... the clients can have a real voice in what features are important to them in the future..."
Do they? One thing not mentioned in either TFA or your post is what does a customer do if the service is no longer meeting their needs? This industry has historically been about vendor tie-in. And about companies constantly ignoring what their customers want; and telling the customer what they will get once they are locked in.
The obvious example for slashdot is Microsoft; but I can think of so many others that it seems like it's the closed-source rule in this business.
It strikes me that once you've bought in to one propriatary service, it then becomes EXTREMELY expensive to switch to a competitors service. And that assumes that it's even possible at all.
So, my question to you is how easy do you think it is to switch services? I honestly don't know, as SaaS isn't my thing.
If it is indeed expensive or impossible to switch, then this strikes me as a field which is ripe for open standards. That is, empowering the customer with choices, rather than reducing that power by vendor tie-in.
I've spoken with some of the people who worked at Netscape; and their words confirmed my own observations about the source code (as well your observations).
One key flaw at Netscape was due to the engineering mismangement. It was a combination of micromanagement combined with little to no responsibility for the source code. Anyone could make changes to any part of the source code at any time. Not only did you have to worry about implementing your changes using varios API's; but those API's could change right out from under you, and you had no warning about it.
This is understandable when you've got management which apparently doesn't trust the engineers to do their job.
I find it very amusing that the big VC's in Silicon Valley (KP for one) have continually flouted former high-ranking Netscape managers to their prize startups. And from what I've seen, those startups have had their engineering staff decimated by the same mismanagement which killed Netscape.
The Harvard report seems to go after the low-hanging fruit from a top-down level. A pity that they don't focus on what's required for building the foundations a company needs to sustain itself. Without those foundations, death of the company is guaranteed IMHO; and Netscape is an unfortunate prime example.
There's a lot of drivel being written based upon what the article says. Unfortunately, the article is so poorly written, that it's not possible to adequately judge what's being claimed.
He has a sample exploit there on an OpenBSD system.
Here's the guy's bio from the talk:
Loïc Duflot
Security Issues related to Pentium System Management Mode
Loïc Duflot is a security engineer and researcher for the scientific division of the french Central Directorate for Information Systems Security in Paris. He is also a 2nd-year Phd student in Paris XI university. His research work is mostly focused on the security aspects of interactions between hardware components and software. He's also interested in innovative hardware attacks on cryptographic tokens and smartcards.
Note that the French have one of the best security agencies in the world. The main caveat is whether there's anything in the PPT presentation which can exploit your system. I wouldn't put it past the French whatsoever. So, you might be wise to view the presentation on a secure system of yours (preferrably not an x86 one?:) ).
"what's going to convince them that this is a bad idea?"
That's easy. Identify who "them" is, and narrow down all the SSN's, driver's license info, etc. and just publish that for the people who are responsible for posting this stuff. If you really wanted change the situation, just add a few of the high ranking politicians for the county to the list.
There are even ways of making this stuff a permanent part of the Internet, though I'll refrain from giving the less technically clueful some ideas.
I have a strong suspicion that the officials responsible for this would change their tune fairly quickly once they became educated on how having too much public information can be abused.
And, just to be clear, I'm not advocating that anyone do this. I wouldn't advocate this even for those beaurecrats in Florida.
On the positive side of things, if all the counties in the U.S. did this, it would
certainly force the banking industry to change.
I'm simply quoting the guy who made the decision, and pointing out the facts about the FDA. There's really no argument to be made with how things actually work at the FDA.
I also think you missed the point. The FDA was putting corporations first because the question of what was actually "safe" wasn't raised at all. Instead, they went with what was the least amount of radiation emissions that businesses could live with.
Determining what was actually safe wasn't an issue, since it would take too much time and too much money.
Or in essence, the U.S. population was one great lab experiment, all because of the pressure from businesses to ship product.
Many people (myself included before this) are under the impression that the FDA is there to protect the public. In reality, in at least some cases, business interests come first, before public safety.
Putting aside the terms "Capitalist" and "Socialist", I'd rather deal with what really goes on when the Feds make decisions like this. If you blindly assume that they are there to protect the population, you are sadly mistaken, with all due respect.
The interests of business play a very large part in the decision making. Furthermore, this has been the situation for a very long time.
A case in point are the standards for Microwave Oven Emissions. Now, one might think that these were based upon actual trials and lots of scientific studies. Nope. The main
determining factor was the minimum level that businesses could live with.
The following quotes were passed on to me by a friend, who went to a talk last year by
"a veteran physiologist, Dr. George Leong". Dr. Leong worked at the FDA, and was the main government official responsible for setting the current standards for Microwave Ovens. Here is what was reported:
"Dr. Leong emphasized
that the effects [of ionizing radiation] are cumulative and long-term. A person exposed to
increased levels of radio waves in their teen years may not develop
cataracts etc. until they are in their mid-40s.
I asked how the government arrives at "safe" levels. He said in effect
that "your starting point is that you need to let people run their
business". In other words, standards are set by working backwards from
what the industry feels they can (just about) accept. "Acceptable"
standards are NOT set based on years or decades of study of whether any
ill effects arise in humans. (For one thing, such studies would be
unethical. For another, decade-long studies would be extremely expensive.)"
So, please understand the reality of the FDA. They have an established history of put businesses first, and people's safety second.
Re:One more key point - lack of security
on
Gmail vs Pine
·
· Score: 1
I guess we'll have to disagree on the seriousness of the attacks. You can downplay them all you want, but most people in this business take them seriously.
If you're interested in attacks which leave your files exposed, just do a google search for "javascript buffer overflow". I got 629,00 hits. And yes, this stuff is still occurring.
You can also downplay things by trying to pin the blame on the implementation. That doesn't mitigate things when they happen (have you ever had to clean up these messes?). If things were done cleanly, then JS issues wouldn't be a constant, reoccurring theme for the past 10 years or so.
The point remains that JS is a weakpoint. If you had the OpenBSD folks (or even people with their attitude) in charge of things, then the situation might change. But until that time, the fact is that you are safer surfing with it turned off, and not on.
Re:One more key point - lack of security
on
Gmail vs Pine
·
· Score: 1
"Javascript has never had the issues of being able to install files on the local machine, or anything similar, that's all done via activeX which is why the mozilla family of browsers is safe from this vector. So far, the worse JS security issues is that it can popup a billion windows and kill a machine."
No, with all due respect, you are very much mistaken. Javascript has had horrible security issues, which keep popping up (pun intended). Not quite as bad as MS Windows, but certainly a contender.
"Show me an attack vector that works with just javascript."
Ok, since you didn't qualify your statement, here are a few from a quick google search, since I'm lazy. Note the email-related ones. Study the issues around javascript (including its architecture) if you want more information.
I've already mentioned that what most people do leaves them open. Most people don't understand security. And most people really don't care. Your original question was directed towards myself. Anyone calling themselves a security expert who blindly lives by depending on remote maintainence is one who is an easy target. Knowledgeable users know how to protect themselves. And the best actually do, since the loss of reputation capital is significant (see how Kevin Mitnick got taken down the last time).
Re:One more key point - lack of security
on
Gmail vs Pine
·
· Score: 1
Thanks for the clarification; I appreciate the information. I'll take your word on it, and gratefully stand corrected on the point.
However, there is a big diffeence between claiming something which "is required", and something which may work. My experience with Yahoo is that they stand behind their non-js version.
Regarding the non-js version of maps, this must be since their initial release. It didn't work when I first tried it out, and I haven't bothered with it since. I am delighted to hear that it does now.
And no, I don't trust Yahoo to do anything more than what most other businesses would do. I do trust them slightly more than Google, since they haven't required tracking my social networks via invites to get started with things. That is just plain sureptitious and dishonest.
As far as "most of us trust google", forgive me, but most people surf with js turned on, along with other worse things; and really haven't a clue about security (though again, many people think they do). A case in point is your claim about "As is the nature of every web based email system.". Sorry, that's just wrong. Please show me an attack vector to install spyware (or just do a buffer overflow) via plain html with standard browsers that have javascript turned off.
Regarding your final question, yes, I do audit the source code that I use. Your statement about "remote being better" indicates you neither really understand security, nor are concerned about it. With all due respect.
Re:One more key point - lack of security
on
Gmail vs Pine
·
· Score: 1
"JavaScript and cookies must be enabled on all browsers"
Yahoo at least doesn't keep their non-javascript interface hidden; they switch to it dynamically once they detect your browser doesn't support javascript. That's how it should be if it's properly implemented. Plus they have a version of maps which doesn't require javascript either.
Clearly Yahoo has someone in charge there who actually does understand security, and takes it seriously. Google is (curiously and somewhat surprisingly) far behind in this regard.
Regarding C, there's a huge difference between placing trust in a remote server that I can't audit, and a simple local program that I can.
One is at their mercy when it comes to spyware should they change the definition of "no evil" in the future. The best that one can do is to audit what comes across the connection. Aside from being tedious, it's also after the fact.
One more key point - lack of security
on
Gmail vs Pine
·
· Score: 2, Insightful
There's one key point about gmail that you left out. You need to have an inherently insecure browser just to be able to use it. Specifically, it requires javascript, which has had terrible security issues over the years.
I presume you also need cookies as well, but I can't say, as I avoid gmail like the plague.
I really don't see how one can come to that conclusion when the very title of the article is "Interest in embedded Linux remains low, survey finds".
I'm sorry, but not only are they not publishing the whole story, they are deliberately putting a negative spin on it. That is, they explicitly imply no one is using Linux, when the truth is it's one of the most (if not THE most) widely used embedded O.S.. Had they been interested in publishing the whole truth, they would have mentioned this fact. And the fact that its marketshare growth has been explosive.
Instead, they refrained from mentioning what past surveys had found, as well as the growth of Linux. By doing so, and implying that few are using Linux, it's clearly aimed at generating FUD.
And, while you may not care about this for your own work, there are many, many PHB's out there who do read this stuff, and challenge their engineers' selection of O.S.. I daresay it's the sad norm in the business; at the least, it's all too typical. And articles like this add fuel to the fire.
Microsoft is well-known for having shills who are employed at various rags. They've used this tactic before with trade publications; this has been reported in the past on Slashdot. I've even seen it first hand.
It's a pity that Dylan McGrath has decided to appear as one, instead of going after what the real story is. But, I guess journalistic standards aren't of interest for some. A pity it applies to the EE Times.
The EE Times article, and the conference survey are not news at all. This has been reported in the past over at linuxdevices.com. In fact, the numbers are in the same ballpark last I looked.
However, what's NOT being reported by the EE Times is what's significant here.
If you look at the linuxdevices.com survery, the number of systems using linux is about 20-25% IIRC. Say it's 20%. This is in line with the survey.
But the REAL interesting thing here is that Linux has come from virtually nowhere in the past 5 years, to now actually become one of THE dominant Embedded OS's in the marketplace, if not the single most dominant one.
Contrast this to VxWorks. About 5-6 years ago, WindRiver was crowing that they had the dominant OS, with about a 33% marketshare. According to the linuxdevices.com survery, that has now dropped to about 12% IIRC, and is fading. Witness, in fact, WindRiver's huge adoption of Linux recently (and their large hiring of Linux developers).
Microsoft's OS's are each well behind Linux; and even combined, still add up to slightly less marketshare (or at best, comparable) than Linux.
So, the bottom line is that Linux has come from absolutely nowhere in the past 5 years to become one of the key players in the embedded space. Completely contrary to the EE Times article. Shame on them for their attempt to completely distort the truth here.
Linux in the embedded space is only going to keep on growing; the advantages with it over the closed-source solutions are just too huge.
Why in the world do we need trials? Aren't they all guilty?
Once again, the marketplace should act as a filter
on
Idea Stock Exchange
·
· Score: 1
"What's to prevent the company from screwing you from a compensation standpoint?"
Not a single thing. However, note that there is a feedback loop here; it's in the companys' long term interest not to do this. If the company is run by the typical quick-buck artists, then word gets around, and people aren't as motivated to offer their best ideas to the company.
If a competitor has a better compensation plan for employees, then this implementation plan should (in theory) work better there; and over the long term the competitor should do better.
So, in short, market competition between companies over the long term ought to result in filtering out the poorer implementations of this.
Which is refreshing; this sort of approach makes the current standards in industry look positively feudal.
A client is someone who pays for something. Dell isn't paying for anything. What you fail to realize is that it's Dell's clients (or potential clients) who are asking for this. And that's only some members of the "Linux community". The rest realize that Dell produces sheer junk, and prefer to send their business elsewhere.
So the GP's points are not moot whatsoever; they are spot-on.
The basic problem here is that much of modern Corporate America doesn't see their customers as anything but an ends to a means. Not a partner, not someone to serve; simply an ends to the next bonus. Dell is an excellent example of this; and if they truly wanted to serve their customers, they'd be providing what their customers wanted - not what Dell says they want.
No, your point in the first place was what I quoted, that you couldn't find qualified engineers. I'm sorry, but that's just B.S.. Whenever someone says that, what they always mean is that they can't find qualified engineers who will work for peanuts. At least not in Silicon Valley.
You seem to be under the impression that what you offered for a salary would attract someone qualified; and reality showed you differently.
I have worked with a lot of hardware engineers doing low-level work; on bringup projects of different types of complexity (from rather simple, to truly sophisticated cutting edge work; usually the latter). They are out there, you just have to know how to find them. And to attract them. And to keep them.
I wish you luck with your project. Personally, I wouldn't dream of offshoring work like that if it was critical to my companys' success. I've worked with projects that have outsourced locally to a company 30 minutes away; and that caused enough headaches that it was a questionable decision. I can't see how offshoring something like that is going to work in any sort of timely fashion, for anything other than a toy project. There are just way too many things to go wrong; and debugging with a team half-way around the world will make you rethink whether that $200K salary is, as you said, "absurd".
It's not absurd whatsoever, if time is more valuable than money.
Especially when these kinds of engineers usually want just $150K, which is typical for these engineers working in startups currently. In fact, I'll even bet you remember this conversation if you haven't gone through the complete debug cycle. *grin*.
In the meantime though, those hardware engineers that you couldn't attract are working for your competition, I'm afraid to say. That's not exactly a competitive advantage. But I do wish you luck.
"not because it was cheap, but because we simply couldn't find enough qualified engineers locally in the valley "
Pure, utter, B.S.. It was ALL about economics; there are plenty of qualified engineers out there.
I can guarantee you that, for a $200K per year salary, I can find you ANY number of qualified engineers. I suspect that you'd agree.
Heck, if you're serious, offer the typical 20% fee you'd pay to a recruiting agency to anyone here on Slashdot who can find your ideal candidate, and you'll have a wealth of qualified candidates to choose from.
So, we can attribute your decision to pure economics, and not that you couldn't find qualified engineers. One can always find qualified engineers; it's only a matter of how much you're willing to pay.
Ooo, RSS feeds is a brilliant idea. Nice one! That seems like it's a "must have".
Unfortunately, most of the current discussion doesn't seem to focus on technology, yet that's what I think the original question wanted. Let me add some more technology issues:
1. No mandatory javascript. This one always seems to elude the lesser webmasters. Javascript has had an extremely large number of attacks on it, possibly second only to MS Windows. So, if you're into security, and looking for a job, you either have to open yourself up to an attack, use a less secure system, or go to a different site.
Really, if you can't do a website without javascript, you'll drive some people to your competitors, who you may want to attract.
2. Ratings of agencies and job seekers. Ok, this is controversial. But I'd really like some indication that the agent I'm dealing with isn't a scum bag. I'm sure they'd like the same about job seekers. More than just references. What comes to mind is whether the seeker isn't really another agent trying to steal a client.
3. It would also be nice if you could generally view the site, and get a general idea of what they have without signing up. Registration is a pain (and one more stupid password to remember). Let me look before I decide it's worth it.
In general, I find dice.com has many of the things that I need. It's not perfect, but orders of magnitude better than the competition.
Slashdot Mirror
Instead of the harping on the implementation (which was done in a slapdash, amatuerish fashion by SiByte in order to make a quick buck - and screw the customer), you should blast Broadcom for basically dropping support for this CPU. Broadcom has done almost nothing whatsoever to improve the CPU. In fact, they go far out of their way to avoid the needed improvements. Witness the completely bogus (and nearly useless) JTAG support for the 1250.
They used to have GDB support for it for free. That's all gone; and in fact no longer works with the new Rev C 1250's. Instead, you have nearly useless third-party support from Corelis and Greenhills.
Forget source code debugging if you have a ClearCase SCM, unless you want to go through a bit of pain and hackery.
And, hells bells, let's not talk about the memory controller, which is the worst one I've ever seen. If there were ever anything which needed improvement, it is that.
In short, if you chose the BCM1250, you were an idiot and deserve what you got. No sane embedded person would do so. A clueless architect might, but not a real embedded engineer.
I once had to inherit this mess; and I'm delighted to be done with it.
So just avoid Broadcom altogether. They have an established track record of leaving you high and dry should you make the mistake of depending on them. And they just don't give a damn about their customers.
Do they? One thing not mentioned in either TFA or your post is what does a customer do if the service is no longer meeting their needs? This industry has historically been about vendor tie-in. And about companies constantly ignoring what their customers want; and telling the customer what they will get once they are locked in.
The obvious example for slashdot is Microsoft; but I can think of so many others that it seems like it's the closed-source rule in this business.
It strikes me that once you've bought in to one propriatary service, it then becomes EXTREMELY expensive to switch to a competitors service. And that assumes that it's even possible at all.
So, my question to you is how easy do you think it is to switch services? I honestly don't know, as SaaS isn't my thing.
If it is indeed expensive or impossible to switch, then this strikes me as a field which is ripe for open standards. That is, empowering the customer with choices, rather than reducing that power by vendor tie-in.
One key flaw at Netscape was due to the engineering mismangement. It was a combination of micromanagement combined with little to no responsibility for the source code. Anyone could make changes to any part of the source code at any time. Not only did you have to worry about implementing your changes using varios API's; but those API's could change right out from under you, and you had no warning about it.
This is understandable when you've got management which apparently doesn't trust the engineers to do their job.
I find it very amusing that the big VC's in Silicon Valley (KP for one) have continually flouted former high-ranking Netscape managers to their prize startups. And from what I've seen, those startups have had their engineering staff decimated by the same mismanagement which killed Netscape.
The Harvard report seems to go after the low-hanging fruit from a top-down level. A pity that they don't focus on what's required for building the foundations a company needs to sustain itself. Without those foundations, death of the company is guaranteed IMHO; and Netscape is an unfortunate prime example.
So, here's a link to the actual PowerPoint presentation. Don't just click on it without reading the caveats below.
He has a sample exploit there on an OpenBSD system.
Here's the guy's bio from the talk:
Loïc Duflot
Security Issues related to Pentium System Management Mode
Loïc Duflot is a security engineer and researcher for the scientific division of the french Central Directorate for Information Systems Security in Paris. He is also a 2nd-year Phd student in Paris XI university. His research work is mostly focused on the security aspects of interactions between hardware components and software. He's also interested in innovative hardware attacks on cryptographic tokens and smartcards.
Note that the French have one of the best security agencies in the world. The main caveat is whether there's anything in the PPT presentation which can exploit your system. I wouldn't put it past the French whatsoever. So, you might be wise to view the presentation on a secure system of yours (preferrably not an x86 one? :) ).
That's easy. Identify who "them" is, and narrow down all the SSN's, driver's license info, etc. and just publish that for the people who are responsible for posting this stuff. If you really wanted change the situation, just add a few of the high ranking politicians for the county to the list.
There are even ways of making this stuff a permanent part of the Internet, though I'll refrain from giving the less technically clueful some ideas.
I have a strong suspicion that the officials responsible for this would change their tune fairly quickly once they became educated on how having too much public information can be abused.
And, just to be clear, I'm not advocating that anyone do this. I wouldn't advocate this even for those beaurecrats in Florida.
On the positive side of things, if all the counties in the U.S. did this, it would certainly force the banking industry to change.
And I presume you meant "typo", not "type". :)
The words within the blocks "[...]" are mine alone. Thanks for catching the typo.
I also think you missed the point. The FDA was putting corporations first because the question of what was actually "safe" wasn't raised at all. Instead, they went with what was the least amount of radiation emissions that businesses could live with.
Determining what was actually safe wasn't an issue, since it would take too much time and too much money.
Or in essence, the U.S. population was one great lab experiment, all because of the pressure from businesses to ship product.
Many people (myself included before this) are under the impression that the FDA is there to protect the public. In reality, in at least some cases, business interests come first, before public safety.
The interests of business play a very large part in the decision making. Furthermore, this has been the situation for a very long time.
A case in point are the standards for Microwave Oven Emissions. Now, one might think that these were based upon actual trials and lots of scientific studies. Nope. The main determining factor was the minimum level that businesses could live with.
The following quotes were passed on to me by a friend, who went to a talk last year by "a veteran physiologist, Dr. George Leong". Dr. Leong worked at the FDA, and was the main government official responsible for setting the current standards for Microwave Ovens. Here is what was reported:
"Dr. Leong emphasized that the effects [of ionizing radiation] are cumulative and long-term. A person exposed to increased levels of radio waves in their teen years may not develop cataracts etc. until they are in their mid-40s.
I asked how the government arrives at "safe" levels. He said in effect that "your starting point is that you need to let people run their business". In other words, standards are set by working backwards from what the industry feels they can (just about) accept. "Acceptable" standards are NOT set based on years or decades of study of whether any ill effects arise in humans. (For one thing, such studies would be unethical. For another, decade-long studies would be extremely expensive.)"
So, please understand the reality of the FDA. They have an established history of put businesses first, and people's safety second.
If you're interested in attacks which leave your files exposed, just do a google search for "javascript buffer overflow". I got 629,00 hits. And yes, this stuff is still occurring.
You can also downplay things by trying to pin the blame on the implementation. That doesn't mitigate things when they happen (have you ever had to clean up these messes?). If things were done cleanly, then JS issues wouldn't be a constant, reoccurring theme for the past 10 years or so.
The point remains that JS is a weakpoint. If you had the OpenBSD folks (or even people with their attitude) in charge of things, then the situation might change. But until that time, the fact is that you are safer surfing with it turned off, and not on.
No, with all due respect, you are very much mistaken. Javascript has had horrible security issues, which keep popping up (pun intended). Not quite as bad as MS Windows, but certainly a contender.
"Show me an attack vector that works with just javascript."
Ok, since you didn't qualify your statement, here are a few from a quick google search, since I'm lazy. Note the email-related ones. Study the issues around javascript (including its architecture) if you want more information.
http://www.anu.edu.au/mail-archives/link/link9704/ 0016.html
8 95
? index=781
http://www.peacefire.org/security/hmattach/
http://esj.com/security/article.asp?EditorialsID=
http://www.opera.com/support/search/supsearch.dml
"but for the adverage person, remote is better"
I've already mentioned that what most people do leaves them open. Most people don't understand security. And most people really don't care. Your original question was directed towards myself. Anyone calling themselves a security expert who blindly lives by depending on remote maintainence is one who is an easy target. Knowledgeable users know how to protect themselves. And the best actually do, since the loss of reputation capital is significant (see how Kevin Mitnick got taken down the last time).
However, there is a big diffeence between claiming something which "is required", and something which may work. My experience with Yahoo is that they stand behind their non-js version.
Regarding the non-js version of maps, this must be since their initial release. It didn't work when I first tried it out, and I haven't bothered with it since. I am delighted to hear that it does now.
And no, I don't trust Yahoo to do anything more than what most other businesses would do. I do trust them slightly more than Google, since they haven't required tracking my social networks via invites to get started with things. That is just plain sureptitious and dishonest.
As far as "most of us trust google", forgive me, but most people surf with js turned on, along with other worse things; and really haven't a clue about security (though again, many people think they do). A case in point is your claim about "As is the nature of every web based email system.". Sorry, that's just wrong. Please show me an attack vector to install spyware (or just do a buffer overflow) via plain html with standard browsers that have javascript turned off.
Regarding your final question, yes, I do audit the source code that I use. Your statement about "remote being better" indicates you neither really understand security, nor are concerned about it. With all due respect.
"JavaScript and cookies must be enabled on all browsers"
Yahoo at least doesn't keep their non-javascript interface hidden; they switch to it dynamically once they detect your browser doesn't support javascript. That's how it should be if it's properly implemented. Plus they have a version of maps which doesn't require javascript either.
Clearly Yahoo has someone in charge there who actually does understand security, and takes it seriously. Google is (curiously and somewhat surprisingly) far behind in this regard.
Regarding C, there's a huge difference between placing trust in a remote server that I can't audit, and a simple local program that I can.
One is at their mercy when it comes to spyware should they change the definition of "no evil" in the future. The best that one can do is to audit what comes across the connection. Aside from being tedious, it's also after the fact.
I presume you also need cookies as well, but I can't say, as I avoid gmail like the plague.
I'm sorry, but not only are they not publishing the whole story, they are deliberately putting a negative spin on it. That is, they explicitly imply no one is using Linux, when the truth is it's one of the most (if not THE most) widely used embedded O.S.. Had they been interested in publishing the whole truth, they would have mentioned this fact. And the fact that its marketshare growth has been explosive.
Instead, they refrained from mentioning what past surveys had found, as well as the growth of Linux. By doing so, and implying that few are using Linux, it's clearly aimed at generating FUD.
And, while you may not care about this for your own work, there are many, many PHB's out there who do read this stuff, and challenge their engineers' selection of O.S.. I daresay it's the sad norm in the business; at the least, it's all too typical. And articles like this add fuel to the fire.
Microsoft is well-known for having shills who are employed at various rags. They've used this tactic before with trade publications; this has been reported in the past on Slashdot. I've even seen it first hand.
It's a pity that Dylan McGrath has decided to appear as one, instead of going after what the real story is. But, I guess journalistic standards aren't of interest for some. A pity it applies to the EE Times.
However, what's NOT being reported by the EE Times is what's significant here.
If you look at the linuxdevices.com survery, the number of systems using linux is about 20-25% IIRC. Say it's 20%. This is in line with the survey.
But the REAL interesting thing here is that Linux has come from virtually nowhere in the past 5 years, to now actually become one of THE dominant Embedded OS's in the marketplace, if not the single most dominant one.
Contrast this to VxWorks. About 5-6 years ago, WindRiver was crowing that they had the dominant OS, with about a 33% marketshare. According to the linuxdevices.com survery, that has now dropped to about 12% IIRC, and is fading. Witness, in fact, WindRiver's huge adoption of Linux recently (and their large hiring of Linux developers).
Microsoft's OS's are each well behind Linux; and even combined, still add up to slightly less marketshare (or at best, comparable) than Linux.
So, the bottom line is that Linux has come from absolutely nowhere in the past 5 years to become one of the key players in the embedded space. Completely contrary to the EE Times article. Shame on them for their attempt to completely distort the truth here.
Linux in the embedded space is only going to keep on growing; the advantages with it over the closed-source solutions are just too huge.
Why in the world do we need trials? Aren't they all guilty?
"What's to prevent the company from screwing you from a compensation standpoint?"
Not a single thing. However, note that there is a feedback loop here; it's in the companys' long term interest not to do this. If the company is run by the typical quick-buck artists, then word gets around, and people aren't as motivated to offer their best ideas to the company.
If a competitor has a better compensation plan for employees, then this implementation plan should (in theory) work better there; and over the long term the competitor should do better.
So, in short, market competition between companies over the long term ought to result in filtering out the poorer implementations of this.
Which is refreshing; this sort of approach makes the current standards in industry look positively feudal.
No, he didn't expect to win. He was just getting experience so he could go work for SCO. *rimshot*
Last I checked, I still had to pay for a Dell box myself. That makes me their client; and them a vendor.
I could care less what Dell wanted. I know what I want, and Dell doesn't provide it.
So the GP's points are not moot whatsoever; they are spot-on.
The basic problem here is that much of modern Corporate America doesn't see their customers as anything but an ends to a means. Not a partner, not someone to serve; simply an ends to the next bonus. Dell is an excellent example of this; and if they truly wanted to serve their customers, they'd be providing what their customers wanted - not what Dell says they want.
You seem to be under the impression that what you offered for a salary would attract someone qualified; and reality showed you differently.
I have worked with a lot of hardware engineers doing low-level work; on bringup projects of different types of complexity (from rather simple, to truly sophisticated cutting edge work; usually the latter). They are out there, you just have to know how to find them. And to attract them. And to keep them.
I wish you luck with your project. Personally, I wouldn't dream of offshoring work like that if it was critical to my companys' success. I've worked with projects that have outsourced locally to a company 30 minutes away; and that caused enough headaches that it was a questionable decision. I can't see how offshoring something like that is going to work in any sort of timely fashion, for anything other than a toy project. There are just way too many things to go wrong; and debugging with a team half-way around the world will make you rethink whether that $200K salary is, as you said, "absurd".
It's not absurd whatsoever, if time is more valuable than money. Especially when these kinds of engineers usually want just $150K, which is typical for these engineers working in startups currently. In fact, I'll even bet you remember this conversation if you haven't gone through the complete debug cycle. *grin*.
In the meantime though, those hardware engineers that you couldn't attract are working for your competition, I'm afraid to say. That's not exactly a competitive advantage. But I do wish you luck.
This is a superb and succienct summary of the situation, even given some of the fine engineers that I've seen in India.
Pure, utter, B.S.. It was ALL about economics; there are plenty of qualified engineers out there.
I can guarantee you that, for a $200K per year salary, I can find you ANY number of qualified engineers. I suspect that you'd agree.
Heck, if you're serious, offer the typical 20% fee you'd pay to a recruiting agency to anyone here on Slashdot who can find your ideal candidate, and you'll have a wealth of qualified candidates to choose from.
So, we can attribute your decision to pure economics, and not that you couldn't find qualified engineers. One can always find qualified engineers; it's only a matter of how much you're willing to pay.
Unfortunately, most of the current discussion doesn't seem to focus on technology, yet that's what I think the original question wanted. Let me add some more technology issues:
1. No mandatory javascript. This one always seems to elude the lesser webmasters. Javascript has had an extremely large number of attacks on it, possibly second only to MS Windows. So, if you're into security, and looking for a job, you either have to open yourself up to an attack, use a less secure system, or go to a different site.
Really, if you can't do a website without javascript, you'll drive some people to your competitors, who you may want to attract.
2. Ratings of agencies and job seekers. Ok, this is controversial. But I'd really like some indication that the agent I'm dealing with isn't a scum bag. I'm sure they'd like the same about job seekers. More than just references. What comes to mind is whether the seeker isn't really another agent trying to steal a client.
3. It would also be nice if you could generally view the site, and get a general idea of what they have without signing up. Registration is a pain (and one more stupid password to remember). Let me look before I decide it's worth it.
In general, I find dice.com has many of the things that I need. It's not perfect, but orders of magnitude better than the competition.