Not really... the contest machine just needs to periodically push the logs to the publishing machine. This can be done without opening up anything else. There's a slight increased risk of DOS, but if you're generating enough log entries to DOS the machine, your connections alone are probably enough to do the job anyway.
Do you have a source on this that's a little less biased? The author of the linked article is obviously biased towards Christianity. Since he never mentions what the actual translation of the letter that Barlow made into Article 11 is, other than to mention that the Princeton report dismissed it as unimportant, he never actually establishes that the phrase doesn't exist on the copy that Barlow was working from.
Obviously, if the quoted phrase is missing from the other existing copies of the treaty, it would certainly not have any legal force, but I would still like to know if the phrase is present in the letter.
We built 5 flight objects, 2 have gone boom, which accourding to my calculator is a 40 percent failure rate, and your suggesting we should just live with the risk?
Try measuring the risk with a suitable metric before you complain about it. Your 40% failure rate is rather flawed because it doesn't normalize for any of the variables that should go into it--flight hours, flight distances, number of missions per vehicle, etc. The way you measure it, it would be equivalent to buying 5 computers, letting them run 24/7 for 5 years, then complaining about a 40% failure rate when two of them crash the OS (obviously this probably is not any kind of a real OS... even *nixes would have trouble with that kind of uptime... though maybe a NetWare box could do it:).
I believe I would count only 3 of your examples embedded systems, since most of them were fundamentally computers.
And embedded systems are what, exactly? Little boxes with magical fairies that do computation? Let's go through your examples:
microwave oven dishwasher dryer coffee pot
OK, maybe I'm missing something here, but all these three really have as far as embedded systems are concerned are timers. I suppose the dishwasher, dryer, and coffee pot could have temperature sensors, but for the most part these are pretty dumb systems. Not much that can go wrong.
POTS telephone
Unless you're talking about a cordless or a phone with a built-in answering machine or something, this is basically an analog device. Or were you talking about the POTS telephone switches, which these days are most definitely computers?
Embedded systems aren't small and modular because they need to be bulletproof... they're small and modular because they have a restricted problem domain. They're often bulletproof because of that restricted domain, since they're small enough that they can more easily be completely specified
Actually, IIRC, there are seven other sensors sensing the same thing that disagree with this particular sensor. So, it sounds to me like the sensor is not doing its job.
Arrrgh! And you are still missing the other poster's (and now my) point. Nobody said assembly was the right choice. Nobody said C was the right choice. And I agree that a modern optimizing compiler can do a better job than a human can (over the entire program in general, at least), and they're getting better all the time (gcc 4 is looking like it's going to have some really exciting new ways to optimize because it's going to have more knowledge about the whole program before it does optimization). But that wasn't the point.
The point is that by knowing what happens under the hood you know which algorithms and patterns you should use. The point is that the programmer who knows how to program on the bare metal is more likely to be the programmer that:
* Has a good idea where that wierd performance problem is that crops up when the system is under heavy load.
* Has better debugging skills because he's done debugging where there was nothing there to help him (except maybe a logic probe).
* Knows the value of clear documentation, because after a while all assembly (and all high level code:) looks the same.
And those skills are what are going to help you beat the competition to market, and continue to beat them when they arrive. But I agree that if the programmer insists that C is the best tool for a business app, then he's probably not someone you want. But dismissing the programmer because he knows how things work at a level below the flavor of the week language is just foolish, and that's what causes business to fail. I guess my main argument is that if he can code on bare metal, he can code as well or better in a higher level language.
He wasn't saying the people have to program down to the bare metal... he said they should be able to program down to the bare metal. And he's right. I've found that my experience (what little I have:) with assembly language programming on embedded systems has given me a better understanding of what happens in those higher level languages. Sure, for the most part I can ignore it because of how good hardware has become. But if I need to optimize, knowing how the hardware does its job and how the language represents its structures at the hardware level helps tremendously. You may not hire someone who makes the statement "Everyone should be able to program to the bare metal," but personally, a statement like that would give someone bonus points in my book, because that person obviously understands that at the end of the day, no matter what high level language you're using, it eventually has to run on the bare metal.
Wait... they actually failed people out? There are a number of people here that I can't figure out how they passed enough classes to get into the higher level ones. I'm beginning to think that no one fails. I've even had difficulty failing classes that, for all intents and purposes, I was trying to fail.
It always did this during login authentication, though in versions earlier than 2.5, you could still get an idea of what the length of the password was by the size of the packets. Authentication messages are now padded with ignore messages to a constant length (I don't know what that length is though).
The vulnerability was based on a traffic analysis _after_ login. However, I believe it was fixed by just making the server always echo a packet, whether the shell did or not. But don't quote me on it, since I didn't look it up.
At any rate, no OpenSSH version after 2.5 is known to be susceptible to this particular vulnerability, so how it works is more of a historical question for protocol designers.
That's true. But by starting closer to the solution, we increase the probability of finding a solution earlier. So, while the improvement on a brute force search would probably be negligible, a more intelligent dictionary attack would more often find an early solution, thus the effective search time is decreased.
When you're talking about search spaces this big, any amount of intelligence you can add to cut down the size of the search space helps.
Speaking of which, why is it said not to login as root over SSH? The only plausible reason I've ever heard is that the encryption is stronger after the login is complete, so your root password is safer if you 'su' to root after logging into another account.
I think it may be due to an old vulnerability. In versions of OpenSSH earlier than 2.5, you can discover the length of the password using traffic analysis. Basically you look for the following sequence of packets:
Basically, since the x packets aren't echoed, we know that they are the password. We don't know the contents of the packets, but we now know the length of the password, which can help tremendously in brute force and dictionary attacks (we can eliminate a huge portion of the search space by only searching passwords of length x).
This technique worked for both SSH-1 and SSH-2 protocols. For more detail, (and a better, more accurate description of how the vulnerability worked) you can
read the original security advisory.
Another problem with logging in directly as root is that you no longer can audit who is logging in as root in an environment where multiple users have root access.
Hmmm... can you mine it? Then it doesn't exist in this part of the galaxy (I'm not going to comment on whether or not it exists in another part of the galaxy). Just because you can synthesize something doesn't mean it occurs naturally.
Um, any turing complete language can be used to write its own compiler. So that's a completely useless metric. Now whether or not a scripting language's VM is fast enough to support compiler written in that language is another question entirely.
While I agree that it's probably not the best measure, innovations per billion people seems like an intuitive measure of the rate of progress. In an ideal world, one would expect that as the number of people increases, so would the number of innovators, and by extension, the number of innovations.
The main problem with this measure though, is that it assumes all innovations are equally difficult to create, which is obviously not true.
Re: quads = text.split('.')
on
Data Crunching
·
· Score: 2, Informative
Actually, that would depend on where this code lives... if it's in the user interface, sure, using an exception is probably not the right way to do it, since you know right there how to handle it. But what if it's deep in the bowels of a library? A library should validate that its callers are following the contract, but has no way of knowing how to handle the error when the value is out of range, so it should fail early and throw an exception so the higher layers can do something about it.
Besides, as another poster mentioned, using exceptions for flow control is an actual pattern in Python. The Python philosophy is 'it's easier to ask for forgiveness than to ask for permission.' Though, the truly python way would be to build the address and just pass it on, and let someone who knows better validate it.
...to the legal argument. It was a response to the "Oh, it's too hard to write documentation because we don't have anyone to write it for us" argument. I understand that there are also legal requirements that need to be met for any documentation as well, but that was an afterthought in the original poster's comment... it seemed to me that his main excuse for not writing documentation was because it was too hard.
And no, I don't work in the hardware industry, which gives me the ability to look beyond the way things are, and think about how they should be. It's a little thing I like to call 'abstraction'. You know, where you ignore some of the details to get a better look at the problem? I realize that may be difficult for some people, possibly including you, but sometimes you can get too close to a problem to see a solution that's obvious. And the obvious solution is to write user-ready documentation as you build the product, and turn it over to the lawyers to vet when you're done. If nothing else, you have a good reference to use internally. You don't need a separate documentation team, nor should you even really want to isolate that task anyway.
I don't know. I personally find I write code faster when I'm writing the documentation as I go. If I don't have a target to hit, how will I know when I'm done?
Actually, I totally agree--for certain problem domains. Hardware would actually be one of them. Since the requirements for a particular piece of hardware are very limited, and in most cases are well understood, then it should be possible to not only write the end-user documentation first, but also to write formal specifications for that documentation using a language like Z, and prove their correctness. Look at how the space shuttle's on-board group does development, for example.
Unfortunately for more complex systems, up front documentation simply costs too much, unless it's a safety-critical system, since complex systems often have many requirements changes throughout the development cycle. If you require up front documentation for those systems, you end up never writing any code, because every time you finish the docs, you get a change request:)
I'm sorry, but that's ridiculous. You should be writing documentation while creating the product! The documentation should be a part of the product to begin with, not optional. How the hell are people supposed to use your whizbang new gadget if you don't tell them how to do so? More importantly how do you plan on improving the product if you don't know how it works in the current release!. These are the same bullshit excuses we hear time and time again. Not producing documentation is bad engineering, pure and simple, and if it were done in other industries, it would be considered a crime.
Um, that's pretty much how NASA works now. Their in-house engineers come up with the requirements, and some of the design work, then bid it out to various contractors to actually build. NASA pretty much just manages the process. Granted, there are significant portions of the work that are done in house (space shuttle control software comes to mind), but most of the really big stuff is contracted out.
Well attributed by whom? I'm not saying you made it up (and it certainly sounds plausible... Roman punishments were quite harsh), but I couldn't find anything. Granted, I only used Google, but if it's so well attributed, I'd expect some kind of reference in Google. But I'm willing to grant that it was a bad search term or that the references don't appear in Google--Google certainly is not a complete repository of knowledge, though it's sometimes frightening how complete it is:) But, for future reference, generally when someone asks for a reference, it's more productive to provide it, than to call the asker an idiot.
Slashdot Mirror
Not really... the contest machine just needs to periodically push the logs to the publishing machine. This can be done without opening up anything else. There's a slight increased risk of DOS, but if you're generating enough log entries to DOS the machine, your connections alone are probably enough to do the job anyway.
Do you have a source on this that's a little less biased? The author of the linked article is obviously biased towards Christianity. Since he never mentions what the actual translation of the letter that Barlow made into Article 11 is, other than to mention that the Princeton report dismissed it as unimportant, he never actually establishes that the phrase doesn't exist on the copy that Barlow was working from.
Obviously, if the quoted phrase is missing from the other existing copies of the treaty, it would certainly not have any legal force, but I would still like to know if the phrase is present in the letter.
We built 5 flight objects, 2 have gone boom, which accourding to my calculator is a 40 percent failure rate, and your suggesting we should just live with the risk?
Try measuring the risk with a suitable metric before you complain about it. Your 40% failure rate is rather flawed because it doesn't normalize for any of the variables that should go into it--flight hours, flight distances, number of missions per vehicle, etc. The way you measure it, it would be equivalent to buying 5 computers, letting them run 24/7 for 5 years, then complaining about a 40% failure rate when two of them crash the OS (obviously this probably is not any kind of a real OS... even *nixes would have trouble with that kind of uptime... though maybe a NetWare box could do it:).
I believe I would count only 3 of your examples embedded systems, since most of them were fundamentally computers.
And embedded systems are what, exactly? Little boxes with magical fairies that do computation? Let's go through your examples:
microwave oven
dishwasher
dryer
coffee pot
OK, maybe I'm missing something here, but all these three really have as far as embedded systems are concerned are timers. I suppose the dishwasher, dryer, and coffee pot could have temperature sensors, but for the most part these are pretty dumb systems. Not much that can go wrong.
POTS telephone
Unless you're talking about a cordless or a phone with a built-in answering machine or something, this is basically an analog device. Or were you talking about the POTS telephone switches, which these days are most definitely computers?
Embedded systems aren't small and modular because they need to be bulletproof... they're small and modular because they have a restricted problem domain. They're often bulletproof because of that restricted domain, since they're small enough that they can more easily be completely specified
They tried to fix it months ago, and thought they had. It reappeared at the last minute.
Actually, IIRC, there are seven other sensors sensing the same thing that disagree with this particular sensor. So, it sounds to me like the sensor is not doing its job.
Arrrgh! And you are still missing the other poster's (and now my) point. Nobody said assembly was the right choice. Nobody said C was the right choice. And I agree that a modern optimizing compiler can do a better job than a human can (over the entire program in general, at least), and they're getting better all the time (gcc 4 is looking like it's going to have some really exciting new ways to optimize because it's going to have more knowledge about the whole program before it does optimization). But that wasn't the point.
The point is that by knowing what happens under the hood you know which algorithms and patterns you should use. The point is that the programmer who knows how to program on the bare metal is more likely to be the programmer that:
* Has a good idea where that wierd performance problem is that crops up when the system is under heavy load.
* Has better debugging skills because he's done debugging where there was nothing there to help him (except maybe a logic probe).
* Knows the value of clear documentation, because after a while all assembly (and all high level code:) looks the same.
And those skills are what are going to help you beat the competition to market, and continue to beat them when they arrive. But I agree that if the programmer insists that C is the best tool for a business app, then he's probably not someone you want. But dismissing the programmer because he knows how things work at a level below the flavor of the week language is just foolish, and that's what causes business to fail. I guess my main argument is that if he can code on bare metal, he can code as well or better in a higher level language.
He wasn't saying the people have to program down to the bare metal... he said they should be able to program down to the bare metal. And he's right. I've found that my experience (what little I have:) with assembly language programming on embedded systems has given me a better understanding of what happens in those higher level languages. Sure, for the most part I can ignore it because of how good hardware has become. But if I need to optimize, knowing how the hardware does its job and how the language represents its structures at the hardware level helps tremendously. You may not hire someone who makes the statement "Everyone should be able to program to the bare metal," but personally, a statement like that would give someone bonus points in my book, because that person obviously understands that at the end of the day, no matter what high level language you're using, it eventually has to run on the bare metal.
Damn, but the Desktop CSS scheme on that site is scary. Cool, but it takes a seriously disturbed mind to do all that with CSS and Javascript:)
Wait... they actually failed people out? There are a number of people here that I can't figure out how they passed enough classes to get into the higher level ones. I'm beginning to think that no one fails. I've even had difficulty failing classes that, for all intents and purposes, I was trying to fail.
It always did this during login authentication, though in versions earlier than 2.5, you could still get an idea of what the length of the password was by the size of the packets. Authentication messages are now padded with ignore messages to a constant length (I don't know what that length is though).
The vulnerability was based on a traffic analysis _after_ login. However, I believe it was fixed by just making the server always echo a packet, whether the shell did or not. But don't quote me on it, since I didn't look it up.
At any rate, no OpenSSH version after 2.5 is known to be susceptible to this particular vulnerability, so how it works is more of a historical question for protocol designers.
That's true. But by starting closer to the solution, we increase the probability of finding a solution earlier. So, while the improvement on a brute force search would probably be negligible, a more intelligent dictionary attack would more often find an early solution, thus the effective search time is decreased.
When you're talking about search spaces this big, any amount of intelligence you can add to cut down the size of the search space helps.
Speaking of which, why is it said not to login as root over SSH? The only plausible reason I've ever heard is that the encryption is stronger after the login is complete, so your root password is safer if you 'su' to root after logging into another account.
I think it may be due to an old vulnerability. In versions of OpenSSH earlier than 2.5, you can discover the length of the password using traffic analysis. Basically you look for the following sequence of packets:
Basically, since the x packets aren't echoed, we know that they are the password. We don't know the contents of the packets, but we now know the length of the password, which can help tremendously in brute force and dictionary attacks (we can eliminate a huge portion of the search space by only searching passwords of length x).This technique worked for both SSH-1 and SSH-2 protocols. For more detail, (and a better, more accurate description of how the vulnerability worked) you can read the original security advisory.
Another problem with logging in directly as root is that you no longer can audit who is logging in as root in an environment where multiple users have root access.
Hmmm... can you mine it? Then it doesn't exist in this part of the galaxy (I'm not going to comment on whether or not it exists in another part of the galaxy). Just because you can synthesize something doesn't mean it occurs naturally.
Um, any turing complete language can be used to write its own compiler. So that's a completely useless metric. Now whether or not a scripting language's VM is fast enough to support compiler written in that language is another question entirely.
It was still amusing, though:)
No, those are ogres.
While I agree that it's probably not the best measure, innovations per billion people seems like an intuitive measure of the rate of progress. In an ideal world, one would expect that as the number of people increases, so would the number of innovators, and by extension, the number of innovations.
The main problem with this measure though, is that it assumes all innovations are equally difficult to create, which is obviously not true.
Actually, that would depend on where this code lives... if it's in the user interface, sure, using an exception is probably not the right way to do it, since you know right there how to handle it. But what if it's deep in the bowels of a library? A library should validate that its callers are following the contract, but has no way of knowing how to handle the error when the value is out of range, so it should fail early and throw an exception so the higher layers can do something about it.
Besides, as another poster mentioned, using exceptions for flow control is an actual pattern in Python. The Python philosophy is 'it's easier to ask for forgiveness than to ask for permission.' Though, the truly python way would be to build the address and just pass it on, and let someone who knows better validate it.
...to the legal argument. It was a response to the "Oh, it's too hard to write documentation because we don't have anyone to write it for us" argument. I understand that there are also legal requirements that need to be met for any documentation as well, but that was an afterthought in the original poster's comment... it seemed to me that his main excuse for not writing documentation was because it was too hard.
And no, I don't work in the hardware industry, which gives me the ability to look beyond the way things are, and think about how they should be. It's a little thing I like to call 'abstraction'. You know, where you ignore some of the details to get a better look at the problem? I realize that may be difficult for some people, possibly including you, but sometimes you can get too close to a problem to see a solution that's obvious. And the obvious solution is to write user-ready documentation as you build the product, and turn it over to the lawyers to vet when you're done. If nothing else, you have a good reference to use internally. You don't need a separate documentation team, nor should you even really want to isolate that task anyway.
I don't know. I personally find I write code faster when I'm writing the documentation as I go. If I don't have a target to hit, how will I know when I'm done?
Actually, I totally agree--for certain problem domains. Hardware would actually be one of them. Since the requirements for a particular piece of hardware are very limited, and in most cases are well understood, then it should be possible to not only write the end-user documentation first, but also to write formal specifications for that documentation using a language like Z, and prove their correctness. Look at how the space shuttle's on-board group does development, for example.
Unfortunately for more complex systems, up front documentation simply costs too much, unless it's a safety-critical system, since complex systems often have many requirements changes throughout the development cycle. If you require up front documentation for those systems, you end up never writing any code, because every time you finish the docs, you get a change request:)
I'm sorry, but that's ridiculous. You should be writing documentation while creating the product! The documentation should be a part of the product to begin with, not optional. How the hell are people supposed to use your whizbang new gadget if you don't tell them how to do so? More importantly how do you plan on improving the product if you don't know how it works in the current release!. These are the same bullshit excuses we hear time and time again. Not producing documentation is bad engineering, pure and simple, and if it were done in other industries, it would be considered a crime.
Um, that's pretty much how NASA works now. Their in-house engineers come up with the requirements, and some of the design work, then bid it out to various contractors to actually build. NASA pretty much just manages the process. Granted, there are significant portions of the work that are done in house (space shuttle control software comes to mind), but most of the really big stuff is contracted out.
Well attributed by whom? I'm not saying you made it up (and it certainly sounds plausible... Roman punishments were quite harsh), but I couldn't find anything. Granted, I only used Google, but if it's so well attributed, I'd expect some kind of reference in Google. But I'm willing to grant that it was a bad search term or that the references don't appear in Google--Google certainly is not a complete repository of knowledge, though it's sometimes frightening how complete it is:) But, for future reference, generally when someone asks for a reference, it's more productive to provide it, than to call the asker an idiot.