Best job (all things considered) that I ever had. I got to participate at a pretty deep level in the construction of what was (for a few weeks at least, until it was overtaken by other systems) the fastest supercomputer on the planet; learned a lot about computing in general; and made a number of professional connections that persist to this day (I currently share an office with the same guy I shared an office with when I worked at Fermilab).
So why did I leave, you ask? Multiple reasons: Money (if you were there long enough you tended to fall behind the curve on compensation); glass ceiling (I only have a bachelor's degree); and a division reorg that put me under a total putz of a department head (even the best places to work will have one of these occasionally). Overall, I don't regret leaving; it was the right career move for me at the time. But there are definitely aspects of that job I still miss.
I'm certainly not arguing that it shouldn't be recertified! But my point is, (re)certification is a hassle, and the added cost occasionally results in non-optimal solutions. Paradoxically, the safety certification process can result in reduced reliability because it can delay (or prevent!) better solutions from being deployed!
In general, the FAA has a disincentive to allow your new gee-whiz device onto a civilian aircraft. If anything goes wrong and people get hurt, some career bureaucrat's ass is on the line. They'd much rather maintain the status quo, with systems that have a decades-long history of not causing aircraft to crash.
The military is another story -- they want all the latest toys, and operate in an environment where the tradeoffs are different. They are more likely to work with the vendor to get the kinks out of a new system, or (as a last resort) even issue waivers for anomalies that don't significantly compromise safety or security.
Bingo. The Byzantine labyrinth that is DO-178B (ED-12B for those across the pond) attempts to ensure software quality by stipulating that everything is traceable to higher-level requirements specifications, and that every line of code is tested against its corresponding requirement(s). This doesn't ensure quality; all it ensures is that your software does what your (possibly broken) requirements state... and that's assuming you haven't made any mistakes along the way in maintaining the web of traceability relationships. It doesn't enforce good engineering practices, or ensure that your engineers actually have a clue.
If you saw the procedures required to get airworthiness certification from the FAA for a critical piece of software, you would shake your head in disbelief. It is almost all about ensuring that every line of code is traceable to (and tested against) a formal requirement somewhere. In spite of greatly increasing software development costs (due to the additional documentation and audit trails required), the procedures do amazingly little to ensure that the requirements or code are actually any good, or that sound software engineering principles are employed. It does not surprise me that GIGO situations occasionally arise -- it is perfectly plausible that a system could meet the certification criteria but shit's still busted because the formal requirements didn't completely capture what needed to happen.
The cost of compliance can also warp the process. A co-worker once told me a story about an incident that happened years ago at a former employer of his. A software system with several significant bugs was allowed to continue flying because the broken version had already received its FAA airworthiness certification. A new version which corrected the bugs had been developed, but getting the new version through the airworthiness certification process again would've been too costly; so the broken version was allowed to continue flying.
I work in a small (~25 employees) R&D office, located nearly 1000 miles from corporate HQ. We have no full-time IT staff, but do have a couple of people with significant IT admin experience (though their current job descriptions don't explicitly place them in that area). We provide our own tech support, and clean up our own messes. In return, corporate generally leaves us alone. Everybody wins -- we can set things up in a way that is sensible for an R&D facility, and they don't need to fly somebody out every time something breaks.
Given that Chrome has been a Google project from the start, it seems to me you've got it backwards: Chromium is Google Chrome with the branding stripped. I'm not sure what you're trying to accomplish by criticizing Google for wanting to put their name on the browser they developed...
In today's crappy job market, pragmatism trumps ideology. Maybe some developers have realized that one way to improve the odds of landing that next (better) paying gig is to get your name out there, which means maximizing the number of people who are using your code. In this context, someone taking a fork of your code proprietary isn't a bad thing, as long as they've got the decency to preserve your attribution in their version of the source. If a company likes your code well enough to use it, maybe they are impressed enough with your skills to look you up and offer you a job.
I wonder if this has led to increased pressure to use more permissive licenses?
Agreed. I love Chrome (ditched Firefox for Chrome a couple of years ago when the long load times and sluggishness of Firefox on Linux became too much to bear), but this story amounts to little more than playing silly games with statistics.
But it is not unreasonable to expect that people who are less careful with physical possessions may also be less careful in other ways as well. So it would not surprise me if there is a correlation between "tends to lose USB sticks in public places" and "tends to get infected with malware".
Even at today's post-Thailand-flood inflated hard drive prices, your entire e-mail history occupies less than a dollar's worth of disk space. I fail to see the issue.
Yet a few stick it out. Half of the half-life is fifty, and, sure, perhaps 25% of the folks who started as line technologists will still be doing that when they turn fifty ...
by the time you turn thirty-five, you'd better have a plan
I'm just shy of 50, and didn't know I needed a plan when I was 35 (though in retrospect I see it now). When I interviewed at Google, the thought that kept going through my mind was "These people interviewing me are young enough to be my kids!" (And no, I did not get the job at Google.)
I currently make decent money, doing (mostly) interesting stuff at a job which nonetheless has aspects that really piss me off. I have a love-hate relationship with my current job, and have a hard time imagining doing this until I retire; but I'm really unsure what my next move should (or can) be.
If the economy picks up, I may look seriously at going back into consulting (I was self-employed for about 10 years so I've done that sort of thing before). Keeping my skills current is proving to be a bit of a challenge though.
Forgot to mention, I also run the Folding@home distributed computing client. Uploads of completed work units were causing horrible lag spikes until I started routing them through a throttling proxy (implemented via apache + a Python script I cobbled together).
As soon as I start trying to shove (or suck) more bits through the pipe than it can handle, round trip latency to "nearby" points of the Internet increases from ~25 ms to ~1 second. When I need to transfer a lot of data, I use rsync or wget if at all possible, and throttle the transfer to just below the rate the connection can handle; this results in ping times staying sane while only slowing down the transfer slightly. We shouldn't need to resort to doing stuff like this to make the network function properly!
Seems more like another form of Security Theater to me. "Yes, we're doing everything we can to prevent terrorism, honest! Look -- we got Google to kick all those horrible terrorist sites off of their servers!"
Yup, I think I have to agree with this. Banning it from "legit" hosting services will just drive it underground, where it will be more difficult to spot. In this case, the suspect had even purchased a custom domain name for his blog, the registration of which could probably have been traced back to him.
Why would we want to discourage potential terrorists from doing stuff that makes them easier to identify?
Now, if you are in the market for a new HDD, your current best bet is to look at the brick and mortar department stores: Much of their remaining on-the-shelf stock hasn't caught up to the rapidly raises prices yet, which currently makes them a lot cheaper than online vendors... Provided you can still find them.
Yup. I managed to snag a couple of 1TB Seagates at Best Buy a couple of weeks ago at "pre-flood" prices; last two they had in stock. Hopefully that will hold me until things return to semi-normal.
I wonder if prices on other components like CPUs and RAM will drop because OEMs aren't able to move as many systems due to the HDD shortage?
Yes, people who don't need a lot of capacity will switch to SSD. But even at the current inflated prices, HDDs still give you a much bigger bang for the buck in terms of price/GB.
WTF does "a high-voltage cathode requires a very low-voltage anode" even mean? I think ExtremeTech tried to paraphrase something technical, and something got lost in translation.
...marketing people frequently shoot from the hip without having a fscking clue about what they're selling, and sometimes even tell outright lies. Film at 11.
Even if you do that, you still don't know that someone hasn't had access to the drive for long enough to make a copy. The only way to know whether this may have happened would be to seal the drive in a package with tamper-evident seals. And this only tells you the drive may have been tampered with after the fact (after the data has already potentially been copied).
Slashdot Mirror
Quite true. But I'd be willing to bet that a significant percentage (if not an outright majority) of /. readers do, so the OP makes sense in context.
Best job (all things considered) that I ever had. I got to participate at a pretty deep level in the construction of what was (for a few weeks at least, until it was overtaken by other systems) the fastest supercomputer on the planet; learned a lot about computing in general; and made a number of professional connections that persist to this day (I currently share an office with the same guy I shared an office with when I worked at Fermilab).
So why did I leave, you ask? Multiple reasons: Money (if you were there long enough you tended to fall behind the curve on compensation); glass ceiling (I only have a bachelor's degree); and a division reorg that put me under a total putz of a department head (even the best places to work will have one of these occasionally). Overall, I don't regret leaving; it was the right career move for me at the time. But there are definitely aspects of that job I still miss.
I'm certainly not arguing that it shouldn't be recertified! But my point is, (re)certification is a hassle, and the added cost occasionally results in non-optimal solutions. Paradoxically, the safety certification process can result in reduced reliability because it can delay (or prevent!) better solutions from being deployed!
In general, the FAA has a disincentive to allow your new gee-whiz device onto a civilian aircraft. If anything goes wrong and people get hurt, some career bureaucrat's ass is on the line. They'd much rather maintain the status quo, with systems that have a decades-long history of not causing aircraft to crash.
The military is another story -- they want all the latest toys, and operate in an environment where the tradeoffs are different. They are more likely to work with the vendor to get the kinks out of a new system, or (as a last resort) even issue waivers for anomalies that don't significantly compromise safety or security.
Bingo. The Byzantine labyrinth that is DO-178B (ED-12B for those across the pond) attempts to ensure software quality by stipulating that everything is traceable to higher-level requirements specifications, and that every line of code is tested against its corresponding requirement(s). This doesn't ensure quality; all it ensures is that your software does what your (possibly broken) requirements state... and that's assuming you haven't made any mistakes along the way in maintaining the web of traceability relationships. It doesn't enforce good engineering practices, or ensure that your engineers actually have a clue.
If you saw the procedures required to get airworthiness certification from the FAA for a critical piece of software, you would shake your head in disbelief. It is almost all about ensuring that every line of code is traceable to (and tested against) a formal requirement somewhere. In spite of greatly increasing software development costs (due to the additional documentation and audit trails required), the procedures do amazingly little to ensure that the requirements or code are actually any good, or that sound software engineering principles are employed. It does not surprise me that GIGO situations occasionally arise -- it is perfectly plausible that a system could meet the certification criteria but shit's still busted because the formal requirements didn't completely capture what needed to happen.
The cost of compliance can also warp the process. A co-worker once told me a story about an incident that happened years ago at a former employer of his. A software system with several significant bugs was allowed to continue flying because the broken version had already received its FAA airworthiness certification. A new version which corrected the bugs had been developed, but getting the new version through the airworthiness certification process again would've been too costly; so the broken version was allowed to continue flying.
Look up "DO-178B" sometime if you're curious...
I work in a small (~25 employees) R&D office, located nearly 1000 miles from corporate HQ. We have no full-time IT staff, but do have a couple of people with significant IT admin experience (though their current job descriptions don't explicitly place them in that area). We provide our own tech support, and clean up our own messes. In return, corporate generally leaves us alone. Everybody wins -- we can set things up in a way that is sensible for an R&D facility, and they don't need to fly somebody out every time something breaks.
Given that Chrome has been a Google project from the start, it seems to me you've got it backwards: Chromium is Google Chrome with the branding stripped. I'm not sure what you're trying to accomplish by criticizing Google for wanting to put their name on the browser they developed...
Another potential factor:
In today's crappy job market, pragmatism trumps ideology. Maybe some developers have realized that one way to improve the odds of landing that next (better) paying gig is to get your name out there, which means maximizing the number of people who are using your code. In this context, someone taking a fork of your code proprietary isn't a bad thing, as long as they've got the decency to preserve your attribution in their version of the source. If a company likes your code well enough to use it, maybe they are impressed enough with your skills to look you up and offer you a job.
I wonder if this has led to increased pressure to use more permissive licenses?
Agreed. I love Chrome (ditched Firefox for Chrome a couple of years ago when the long load times and sluggishness of Firefox on Linux became too much to bear), but this story amounts to little more than playing silly games with statistics.
But it is not unreasonable to expect that people who are less careful with physical possessions may also be less careful in other ways as well. So it would not surprise me if there is a correlation between "tends to lose USB sticks in public places" and "tends to get infected with malware".
Even at today's post-Thailand-flood inflated hard drive prices, your entire e-mail history occupies less than a dollar's worth of disk space. I fail to see the issue.
Yet a few stick it out. Half of the half-life is fifty, and, sure, perhaps 25% of the folks who started as line technologists will still be doing that when they turn fifty
...
by the time you turn thirty-five, you'd better have a plan
I'm just shy of 50, and didn't know I needed a plan when I was 35 (though in retrospect I see it now). When I interviewed at Google, the thought that kept going through my mind was "These people interviewing me are young enough to be my kids!" (And no, I did not get the job at Google.)
I currently make decent money, doing (mostly) interesting stuff at a job which nonetheless has aspects that really piss me off. I have a love-hate relationship with my current job, and have a hard time imagining doing this until I retire; but I'm really unsure what my next move should (or can) be.
If the economy picks up, I may look seriously at going back into consulting (I was self-employed for about 10 years so I've done that sort of thing before). Keeping my skills current is proving to be a bit of a challenge though.
Forgot to mention, I also run the Folding@home distributed computing client. Uploads of completed work units were causing horrible lag spikes until I started routing them through a throttling proxy (implemented via apache + a Python script I cobbled together).
As soon as I start trying to shove (or suck) more bits through the pipe than it can handle, round trip latency to "nearby" points of the Internet increases from ~25 ms to ~1 second. When I need to transfer a lot of data, I use rsync or wget if at all possible, and throttle the transfer to just below the rate the connection can handle; this results in ping times staying sane while only slowing down the transfer slightly. We shouldn't need to resort to doing stuff like this to make the network function properly!
I sure don't want to be 60+ stories underground when the next magnitude 8 hits!
Seems more like another form of Security Theater to me. "Yes, we're doing everything we can to prevent terrorism, honest! Look -- we got Google to kick all those horrible terrorist sites off of their servers!"
Yup, I think I have to agree with this. Banning it from "legit" hosting services will just drive it underground, where it will be more difficult to spot. In this case, the suspect had even purchased a custom domain name for his blog, the registration of which could probably have been traced back to him.
Why would we want to discourage potential terrorists from doing stuff that makes them easier to identify?
Now, if you are in the market for a new HDD, your current best bet is to look at the brick and mortar department stores: Much of their remaining on-the-shelf stock hasn't caught up to the rapidly raises prices yet, which currently makes them a lot cheaper than online vendors... Provided you can still find them.
Yup. I managed to snag a couple of 1TB Seagates at Best Buy a couple of weeks ago at "pre-flood" prices; last two they had in stock. Hopefully that will hold me until things return to semi-normal.
I wonder if prices on other components like CPUs and RAM will drop because OEMs aren't able to move as many systems due to the HDD shortage?
We've got deposits in the US as well. The problem is that it takes a couple of years to bring a refinery online to process the ore.
Yes, people who don't need a lot of capacity will switch to SSD. But even at the current inflated prices, HDDs still give you a much bigger bang for the buck in terms of price/GB.
Actually, if it is still underwater it is most likely brown now... or whatever color the mud tends to be over there. Not green.
WTF does "a high-voltage cathode requires a very low-voltage anode" even mean? I think ExtremeTech tried to paraphrase something technical, and something got lost in translation.
Still impressive, but not nearly as impressive as it would've been if it had actually been 400,000.
Yes, it is just a simple typo... but it would be nice if people could at least get key details like this right when submitting stories...
...marketing people frequently shoot from the hip without having a fscking clue about what they're selling, and sometimes even tell outright lies. Film at 11.
Even if you do that, you still don't know that someone hasn't had access to the drive for long enough to make a copy. The only way to know whether this may have happened would be to seal the drive in a package with tamper-evident seals. And this only tells you the drive may have been tampered with after the fact (after the data has already potentially been copied).