If I understand right, the camera was to be taken back up in the LM anyway. Now, that means that there was just a smidgen of additional weight while reentering the atmosphere, but the variance on weight between missions leaves a simple camera in the noise.
In addition to the other replies, I'll add that some (most?) sites implement passwords poorly. The worst offender is a length limit, which I've seen capped at 20 or less. I still have to use some old Unix systems that won't recognize anything beyond 8 (and "This Is " isn't exactly a good password).
Until sites do things right, passphrases won't work.
Good, unique passwords are fine until you have more than a handful of accounts. Even using a base password with something unique per site will only get you so far.
Password managers are the next step, but they have to be available wherever you happen to be. That either means a smartphone (but typing in the password from my phone defeats the purpose and is a pain with truly strong passwords, a lost/stolen phone becomes a nightmare, and I don't have a smartphone anyway) or a website I can log into and copy/paste from (which then puts all my eggs in one basket, and brings up a whole mess of other issues, especially with public terminals), or a USB drive (which hopefully isn't locked out on the system you need to use, and has the potential for spreading viruses to every computer it touches).
Oh, and then there's password resets... which effectively turn your password into your mother's maiden name. Stored in the clear, of course.
I agree. Passwords are a mess. The problem is, I have no clue how to replace them. Do you?
And remember, the biggest problem isn't the major sites you visit every day... it's the 100 small sites you visit less often (such as Wine HQ). Having a SecurID token for each site won't work, for example.
The reason for using old technology is usually due to a customer requirement, and is never an excuse for the degradation of your own skills. It's amazing what you can learn from what used to be state-of-the-art.
I would never refuse to hire someone because their last job didn't use Python and the new features of Java 7... but an inability to learn new technology at need raises all sort of red flags to me.
Why do I care what version of Java they use, really?
CI is a good way of doing things, but is by no means essential or even the best way of developing software for all environments.
You should be able to use just about any version control system out there, without any training. Why do I care which one they use?
No place I've worked at had automatic unit or regression testing. The most we had was a set of manual instructions on how to run the software to make sure everything worked in general. I never had a reason to complain. Automatic tests would have been nice, but why am I asking about this during the interview?
In short, these questions, while interesting and informative, will never be a part of my decision to take or leave a job. There's many more things that are so much more important to know and ask.
Honestly, you're trying to apply the idea of a regression test to the real world. "I could have avoided this problem by asking about their java version during the interview" is a lot like setting up an automatic regression test against 'javac -version'. Such a thing works when automated by a nightly build, but easily becomes a nightmare when done manually. Your list of questions would never be exhaustive.
Besides, you can usually gather if there's a systemic problem (such as using Java 1.2, no version control whatsoever, and more), by just sitting down with one of the developers after the interview and chat informally about their work.
I think that by declaring the VirtualBox driver to be "tainted crap" they've basically said that it's not worth fixing, or at least that fixing it right would be a large undertaking.
If you're willing to put in the time, I'm sure everybody involved would be grateful... just don't expect it to be a quick fix.
This is exactly why even the smallest projects need to use basic tools like version control right from the very start.
Once anything I'm working on gets larger than, say, a couple files or a hundred lines, I set up a version control system for it. If I find myself doing something (such as copying binaries to a machine) more than a few times, I make a script for it and check that in. I set up a Makefile for even the most basic programs. Then, as the software gets larger or more people work on it, that's already in place, and adding other features (configure scripts, for example) are less of a hassle to put in.
Although it depends on your situation, you might be able to make a difference simply by applying these principles yourself.
For example, set up your own Subversion repository. Set up unit and regression tests -- just for the things you change at first, but you can branch out as you go. Create a cron job for a nightly build. Report your findings (such as bugs the unit tests find) to your supervisors. Make build and installation scripts. Check these tools into your repository, so that changes to them are tracked and so that others who want to use them use the repository, too. Most of all, make life easier for yourself.
As you go, share your tools with the other developers. With time, such tools become the normal way of doing things. At some point, go to your manager or supervisor and show the benefits of what you've done and how it would benefit the entire group. With their blessing, you just move the repository to an official server along with all the scripts and tools you made.
My word of caution (from experience) is to make sure the things you do have that final goal in mind. The scripts have to be high quality, not haphazard. At the same time, realize that the change will be gradual, with acceptance coming as people realize that there is a reason for these practices.
3% of successful infections used a feature that nobody I know about has ever used (beyond accidentally pressing F1).
Just goes to show that even the most benign features could potentially harbor a security risk if the programmers didn't do their job right, regardless of operating system.
I did some more digging on this. Apparently, when upgrading from Win3.1, Program Manager groups are converted to start menu entries (citation). Installing a legacy program on a clean Win95 box doesn't create convert them automatically, it seems, but opening a.grp file adds the entries for you.
So, I think MS did it mostly right, or at least as well as can be expected.
Back when Win95 came out, programs designed for Win3.1 created entries intended for the Program Manager. Did Win95 have any sort of mechanism for accessing these items? I think the Program Manager was still around (for those who cared), but I don't think there was any sort of entry automatically created in the Start Menu.
My point? What you're seeing is exactly what happened with the move to Win95. Nothing new, and I'm sure there will be some sort of workaround in place before Win8 is launched.
That said, I doubt the solution will be pretty, obvious, or intuitive, just like with the transition to Win 95.
The "three-fingered-salute" used to be a closely-guarded secret, a magical combination of buttons that few knew about. After all, you wouldn't want someone to mistakenly reboot your computer while you had an important document open.
Now it's essential knowledge to operating a computer. What happened?
Wait a sec. I must be missing something here. You HOVER over something to get a menu?
Maybe I'd have to see it to understand, but that seems to be even less intuitive than going to the Start menu to begin with. The rest of your description just makes things worse. Why would I go into a settings menu to shutdown/restart/logoff?
Not only that, but I thought Win8 was supposed to be tablet-friendly. How are you supposed to hover on a touch screen? Maybe they're going for "you never need to shutdown?"
The original Pirates of the Caribbean got that both right and wrong. At the beginning you see Sparrow paying his respects to a couple of skeletons still hanging from their nooses just off shore. Later, he is forced to walk the plank.
A little history and a little bit of TV make-believe. I guess I'm ok with that.
The combination of the submission title and the quote being in past tense ("After four years sailing through space, the Dawn spacecraft was expected to slip into orbit late Friday around a giant asteroid...") made me think something went wrong!
They were connected because the information on them is unclassified. Yeah, they might prefer that the files wouldn't be disclosed to attackers, but in the end, the information isn't super secret. The convenience of the internet (easy collaboration with other engineers around the country, being able to use people that don't have a security clearance, or saving on the cost of a separate computer network) outweighs the risk in this case.
Believe it or not, the most blindingly obvious step in securing classified data (putting it on a separate network that's unconnected to the internet, a concept that I came up with before I was 10 years old and I'm sure I wasn't the youngest) has already been taken. It's a good thing, too... computer security is hard, and you don't want to take that risk with anything that poses a threat to national security.
Not all of the patents have been overturned yet, mind you, but the case isn't looking good for Oracle.
I think there's two reasons you don't hear of this happening: first, I think a lot of companies just settle out of court instead of going through the mess. Second, and more significantly, I think it has to be a high-profile case with companies that Slashdot cares about (such as Google).
The company claims that two patents are affected. Patent 7,506,190, awarded in March 2009, and patent 7,937,599, awarded in May of this year. Both patents describe “thermal and power management for computer systems.”
While this clearly has been a novel approach, it is questionable if it was novel when the original patent claimed by IPventure was filed on June 22, 2007 and there may be a good chance that prior art could invalidate both of its patents.
It's almost the opposite, actually. They sued almost as soon as one of the patents was awarded.
On the other hand, the older of the two was filed in 2007, while SpeedStep was introduced on the Pentium III in about 2000 or 2001. What their patents describe is essentially the thermostat logic: step down frequency when the temperature gets too hot. Surely that idea has existed from the introduction of dynamic frequency scaling?!?
But, the patents also talk about fan speed control... I'm pretty sure that was the whole point of AMD's Cool'n'quiet.
You left out some details about bounds checking that deserve some notice:
According the the C++ Standard, std::vector::operator[] does not do bounds checking -- if you want an exception to be thrown, use std::vector::at(). As an aside, I which they would have switched which one does checking and which one doesn't, but it is the way it is.
Visual C++ has an extension to do bounds checking on operator[]. Compile with _SECURE_SCL 1, which is the default. When an access goes out of bounds, the program will terminate. You can set another macro if you want an exception to be thrown, however.
I' think that Visual C++'s behavior is completely acceptable according to the standard (which only requires undefined behavior). However, it makes some C++ programmers uneasy because it's adding overhead to a very common operation that will often be found in inner loops (and with the safe option readily available). Hopefully the compiler can eliminate most of the checks by detecting loop bounds or somesuch.
Another detail about vectors: I've repeatedly heard that you can't use vectors when interfacing with C functions, as they operate on normal arrays. This isn't the case: just pass in the address of the first element (&vect[0]). Yes, this behavior is backed by the standard. The only caveat I'm aware of is that you have to be careful when doing anything to the vector that would cause it to move around in memory (such as call push_back() when it's already full) -- but that's already true of C arrays created with malloc().
However, there is one good reason to use C arrays in C++: when you need a small array allocated on the stack. As of C++0x, however, you should be using std::array for this purpose instead. The only other factor to consider are VLAs, which aren't part of standard C++ and I don't think Visual C++ supports them anyway.
Slashdot Mirror
If I understand right, the camera was to be taken back up in the LM anyway. Now, that means that there was just a smidgen of additional weight while reentering the atmosphere, but the variance on weight between missions leaves a simple camera in the noise.
In fact, I bet they knew about it at landing as they probably inventoried everything that came back.
You'd lose that bet. This was a camera that was never supposed to come back anyway. They never could have inventoried it.
In addition to the other replies, I'll add that some (most?) sites implement passwords poorly. The worst offender is a length limit, which I've seen capped at 20 or less. I still have to use some old Unix systems that won't recognize anything beyond 8 (and "This Is " isn't exactly a good password).
Until sites do things right, passphrases won't work.
Good, unique passwords are fine until you have more than a handful of accounts. Even using a base password with something unique per site will only get you so far.
Password managers are the next step, but they have to be available wherever you happen to be. That either means a smartphone (but typing in the password from my phone defeats the purpose and is a pain with truly strong passwords, a lost/stolen phone becomes a nightmare, and I don't have a smartphone anyway) or a website I can log into and copy/paste from (which then puts all my eggs in one basket, and brings up a whole mess of other issues, especially with public terminals), or a USB drive (which hopefully isn't locked out on the system you need to use, and has the potential for spreading viruses to every computer it touches).
Oh, and then there's password resets ... which effectively turn your password into your mother's maiden name. Stored in the clear, of course.
I agree. Passwords are a mess. The problem is, I have no clue how to replace them. Do you?
And remember, the biggest problem isn't the major sites you visit every day ... it's the 100 small sites you visit less often (such as Wine HQ). Having a SecurID token for each site won't work, for example.
This just in, all our competition sucks, news at 11.
On the other hand, what surprised me was the download links for Chrome, and Firefox on the browser comparison page.
The only thing that would have surprised me more would have been links to the Chrome and Firefox security features.
The reason for using old technology is usually due to a customer requirement, and is never an excuse for the degradation of your own skills. It's amazing what you can learn from what used to be state-of-the-art.
I would never refuse to hire someone because their last job didn't use Python and the new features of Java 7 ... but an inability to learn new technology at need raises all sort of red flags to me.
Why do I care what version of Java they use, really?
CI is a good way of doing things, but is by no means essential or even the best way of developing software for all environments.
You should be able to use just about any version control system out there, without any training. Why do I care which one they use?
No place I've worked at had automatic unit or regression testing. The most we had was a set of manual instructions on how to run the software to make sure everything worked in general. I never had a reason to complain. Automatic tests would have been nice, but why am I asking about this during the interview?
In short, these questions, while interesting and informative, will never be a part of my decision to take or leave a job. There's many more things that are so much more important to know and ask.
Honestly, you're trying to apply the idea of a regression test to the real world. "I could have avoided this problem by asking about their java version during the interview" is a lot like setting up an automatic regression test against 'javac -version'. Such a thing works when automated by a nightly build, but easily becomes a nightmare when done manually. Your list of questions would never be exhaustive.
Besides, you can usually gather if there's a systemic problem (such as using Java 1.2, no version control whatsoever, and more), by just sitting down with one of the developers after the interview and chat informally about their work.
I think that by declaring the VirtualBox driver to be "tainted crap" they've basically said that it's not worth fixing, or at least that fixing it right would be a large undertaking.
If you're willing to put in the time, I'm sure everybody involved would be grateful ... just don't expect it to be a quick fix.
This is exactly why even the smallest projects need to use basic tools like version control right from the very start.
Once anything I'm working on gets larger than, say, a couple files or a hundred lines, I set up a version control system for it. If I find myself doing something (such as copying binaries to a machine) more than a few times, I make a script for it and check that in. I set up a Makefile for even the most basic programs. Then, as the software gets larger or more people work on it, that's already in place, and adding other features (configure scripts, for example) are less of a hassle to put in.
Although it depends on your situation, you might be able to make a difference simply by applying these principles yourself.
For example, set up your own Subversion repository. Set up unit and regression tests -- just for the things you change at first, but you can branch out as you go. Create a cron job for a nightly build. Report your findings (such as bugs the unit tests find) to your supervisors. Make build and installation scripts. Check these tools into your repository, so that changes to them are tracked and so that others who want to use them use the repository, too. Most of all, make life easier for yourself.
As you go, share your tools with the other developers. With time, such tools become the normal way of doing things. At some point, go to your manager or supervisor and show the benefits of what you've done and how it would benefit the entire group. With their blessing, you just move the repository to an official server along with all the scripts and tools you made.
My word of caution (from experience) is to make sure the things you do have that final goal in mind. The scripts have to be high quality, not haphazard. At the same time, realize that the change will be gradual, with acceptance coming as people realize that there is a reason for these practices.
3% of successful infections used a feature that nobody I know about has ever used (beyond accidentally pressing F1).
Just goes to show that even the most benign features could potentially harbor a security risk if the programmers didn't do their job right, regardless of operating system.
I did some more digging on this. Apparently, when upgrading from Win3.1, Program Manager groups are converted to start menu entries (citation). Installing a legacy program on a clean Win95 box doesn't create convert them automatically, it seems, but opening a .grp file adds the entries for you.
So, I think MS did it mostly right, or at least as well as can be expected.
Someone please remind me of some history.
Back when Win95 came out, programs designed for Win3.1 created entries intended for the Program Manager. Did Win95 have any sort of mechanism for accessing these items? I think the Program Manager was still around (for those who cared), but I don't think there was any sort of entry automatically created in the Start Menu.
My point? What you're seeing is exactly what happened with the move to Win95. Nothing new, and I'm sure there will be some sort of workaround in place before Win8 is launched.
That said, I doubt the solution will be pretty, obvious, or intuitive, just like with the transition to Win 95.
The "three-fingered-salute" used to be a closely-guarded secret, a magical combination of buttons that few knew about. After all, you wouldn't want someone to mistakenly reboot your computer while you had an important document open.
Now it's essential knowledge to operating a computer. What happened?
Wait a sec. I must be missing something here. You HOVER over something to get a menu?
Maybe I'd have to see it to understand, but that seems to be even less intuitive than going to the Start menu to begin with. The rest of your description just makes things worse. Why would I go into a settings menu to shutdown/restart/logoff?
Not only that, but I thought Win8 was supposed to be tablet-friendly. How are you supposed to hover on a touch screen? Maybe they're going for "you never need to shutdown?"
The original Pirates of the Caribbean got that both right and wrong. At the beginning you see Sparrow paying his respects to a couple of skeletons still hanging from their nooses just off shore. Later, he is forced to walk the plank.
A little history and a little bit of TV make-believe. I guess I'm ok with that.
The combination of the submission title and the quote being in past tense ("After four years sailing through space, the Dawn spacecraft was expected to slip into orbit late Friday around a giant asteroid...") made me think something went wrong!
Here's hoping all goes well!
It's called journalism. It only takes 10 or fewer words to give that context, and your readers are much better off for it.
But you're right -- this is slashdot. If you're expecting proper journalism, you're looking in the wrong place.
They were connected because the information on them is unclassified. Yeah, they might prefer that the files wouldn't be disclosed to attackers, but in the end, the information isn't super secret. The convenience of the internet (easy collaboration with other engineers around the country, being able to use people that don't have a security clearance, or saving on the cost of a separate computer network) outweighs the risk in this case.
Believe it or not, the most blindingly obvious step in securing classified data (putting it on a separate network that's unconnected to the internet, a concept that I came up with before I was 10 years old and I'm sure I wasn't the youngest) has already been taken. It's a good thing, too ... computer security is hard, and you don't want to take that risk with anything that poses a threat to national security.
http://yro.slashdot.org/story/11/06/23/1419230/USPTO-Rejects-Many-of-Oracles-Android-Claims
Not all of the patents have been overturned yet, mind you, but the case isn't looking good for Oracle.
I think there's two reasons you don't hear of this happening: first, I think a lot of companies just settle out of court instead of going through the mess. Second, and more significantly, I think it has to be a high-profile case with companies that Slashdot cares about (such as Google).
FTFA:
The company claims that two patents are affected. Patent 7,506,190, awarded in March 2009, and patent 7,937,599, awarded in May of this year. Both patents describe “thermal and power management for computer systems.”
While this clearly has been a novel approach, it is questionable if it was novel when the original patent claimed by IPventure was filed on June 22, 2007 and there may be a good chance that prior art could invalidate both of its patents.
It's almost the opposite, actually. They sued almost as soon as one of the patents was awarded.
On the other hand, the older of the two was filed in 2007, while SpeedStep was introduced on the Pentium III in about 2000 or 2001. What their patents describe is essentially the thermostat logic: step down frequency when the temperature gets too hot. Surely that idea has existed from the introduction of dynamic frequency scaling?!?
But, the patents also talk about fan speed control ... I'm pretty sure that was the whole point of AMD's Cool'n'quiet.
That's why I only use natural ingredients in my shoe deodorizer: onions and peaches.
It's even endorsed by the baseball legend Clyde "Sweet Feet" Livingston!
You left out some details about bounds checking that deserve some notice:
According the the C++ Standard, std::vector::operator[] does not do bounds checking -- if you want an exception to be thrown, use std::vector::at(). As an aside, I which they would have switched which one does checking and which one doesn't, but it is the way it is.
Visual C++ has an extension to do bounds checking on operator[]. Compile with _SECURE_SCL 1, which is the default. When an access goes out of bounds, the program will terminate. You can set another macro if you want an exception to be thrown, however.
I' think that Visual C++'s behavior is completely acceptable according to the standard (which only requires undefined behavior). However, it makes some C++ programmers uneasy because it's adding overhead to a very common operation that will often be found in inner loops (and with the safe option readily available). Hopefully the compiler can eliminate most of the checks by detecting loop bounds or somesuch.
Another detail about vectors: I've repeatedly heard that you can't use vectors when interfacing with C functions, as they operate on normal arrays. This isn't the case: just pass in the address of the first element (&vect[0]). Yes, this behavior is backed by the standard. The only caveat I'm aware of is that you have to be careful when doing anything to the vector that would cause it to move around in memory (such as call push_back() when it's already full) -- but that's already true of C arrays created with malloc().
However, there is one good reason to use C arrays in C++: when you need a small array allocated on the stack. As of C++0x, however, you should be using std::array for this purpose instead. The only other factor to consider are VLAs, which aren't part of standard C++ and I don't think Visual C++ supports them anyway.
Without weed, would he have been an astronaut?
Weed vs. rockets:
Both get you high, one just gets you higher than the other.
If I did that, I'd be permanently unemployed.
Self-employment wouldn't be much better.