It's always puzzled me why, when so many bikes are bought for fitness, their purchasers seek out light weight and efficiency, which only reduces the fitness benefit.
Well, you could do it that way, and ride N miles on your heavy bike; or you could ride 3*N miles on a lighter bike and get the same amount of exercise while going faster and farther.
Most people prefer the latter, although YMMV. The real masochists go for the fixie bikes, of course, because gears are for the weak...
All "safe" solutions appear to be around restricting the solution space. It is like cutting off everyone's hands because some people have touched a hot stove. Yes, it is now guaranteed that no hot stoves will be touched but... there are consequences.
Rust seems to have a pretty good solution to that problem -- if you absolutely need to do something unsafe, you can tag a section of your code as "unsafe" and then do whatever dark magic you need to do in that unsafe section -- at your own risk of course.
The advantage of this is that (hopefully) the vast majority of your codebase won't need to be written as unsafe-code, which means that the vast majority of your code will automatically receive the benefit of compiler-guaranteed safety, while the small portion that does need free reign will be tagged with a big red blinking UNSAFE sign so that anyone who is tempted to modify it will know to be extra careful.
Hopefully Tesla will continue to be honest, but the underlying issue is a valid one; if it's in the manufacturer's financial interest to put the driver at fault, what's to stop a less-than-scrupulous auto manufacturer from "doctoring" the automobile's driving logs (either before, during, or after the accident) in a way that would be very difficult for the humans involved to defend against? Especially after a few years/decades of the public (and judges and juries) being trained through experience to believe that the computers don't miss any details and never lie...
Remember the original Tron movie, where the software programs all looked just like the person who created them, except with neon duct tape on their clothes?
There's a lot of truth to that. The design of a piece of software will inevitably reflect the way its author thinks, his views about what the problem-space is and which techniques and engineering tradeoffs are appropriate, and the designer's own unique approach to problem-solving.
Moreover, the designer of the software is the person who has the most invested in that software's success, and thus the most motivation to keep its quality as high he is capable of -- other people may work on the codebase as well, but they are only step-parents, who may do a good enough job to keep things working (as far as customers can tell), but won't necessarily go the extra mile to make the software really shine, because hey, it's not their baby. To them, everything about the software looks like a bit of a mess, mainly because it wasn't implemented the way they would have done it. So why would they spend any more time on it than they have to?
So, when management decided to lay off Joe because they thought that with the app feature-complete they didn't need him anymore, they were unknowingly signing the death warrant for Joe's app at the same time. It won't die right away, since other programmers can come in, fix bugs, and add the occasional minor feature, but every time someone does that, the integrity and reliability of the codebase suffers a bit more, as the new developer's approach is different from Joe's approach, and thus the new code doesn't fit quite right with the old code. Eventually, development of the codebase slows to a near-halt, as the time, effort, and risk of making any further significant changes starts to outweigh the benefits that could be secured by making the changes. In another year or three, the app will be effectively dead, and the company will have to hire another Joe to write new software from scratch.
Basically, this is an admission that the average programmer is fairly shitty.
Surely that was common knowledge already?
Then again, you don't want average programmers working on anything important, so by sticking with c, you're not going to get the "rust, rust, baby" programmers.
Because management is wise enough to understand the pitfalls of the C language and the risks of hiring a mediocre programmer, and will instead let the critical position remain open and let the product's shipping-schedule slip indefinitely until a Really Good C programmer finally comes along -- no matter how long that takes?
I think you are giving management a little too much credit there:)
Hire competent C developers and you should be good to go. Hire dumb-asses and sure the future doesn't look bright.
A competent C developer will make only a very small number of mistakes per N lines of code, so that's a good thing.
Of course, it only takes a single tiny mistake to produce potentially devastating consequences, so unless every single one of your C developers is not just good, but infallible, then by hiring "only" competent C programmers you are guaranteeing that your software will include a security hole, sooner or later.
The problem with infallible C programmers is that they do not exist. The problem with competent C programmers is that there are only a limited number of them around, and it's not always easy to tell up front the competent C programmers from the seemingly-competent ones. Not to mention that every competent C programmer started out as a less-than-competent C programmer; if companies hired only competent C programmers, there would not be any competent C programmers since nobody would be able to make a living as a C programmer during the first N years of their programming career.
Since the whole point of computers is to automate processes to make them quicker, easier, and less susceptible to human error, why would you not want to automate the creation of secure software, to the extent it is practical to do so?
The linux kernel is in its 3rd decade, as most gnu/bsd tools and all of that is written in plain C. They are good and safe.
Why do you think the Linux kernel is good and safe? It has suffered from many security holes in the past, and will probably suffer from more in the future. There are almost certainly multiple gaping security holes in the Linux kernel right now, just waiting to be discovered and exploited. And this is despite it being written by competent guys.
Imagine how much more robust the Linux kernel would be if the competent guys were also using a language that caught more of their mistakes at compile-time, rather than leaving them to be discovered by testers, users or hackers at some later date. Dunno if Rust is the language to do that, but it's hard to see how automatic coding-error detection wouldn't be a big improvement over the status quo.
Yes. Formal verification of most production programs will not happen in my lifetime or yours, or possibly ever, because it's expensive and nobody's paying for it.
The idea with Rust is that the Rust compiler does a significant amount of formal verification so that human beings don't have to.
It won't guarantee that your program does what you intended, but at least if your Rust program compiles, you have a pretty good assurance that it won't be corrupting its memory space and suffering from (potentially-exploitable) Undefined Behavior when it runs.
The simple fact is that there's a hue and cry about security but nobody really cares about it, because nobody's willing and able to pay what it would take to fix it.
There's some truth to that; in most cases, people are only going to invest a modest, finite amount of additional time/effort/money into making code secure.
Which is why it makes sense to minimize the cost of making code secure, e.g. by building the necessary checks into the language itself so that all programs benefit from them "for free".
No doubt a self-steering bike is possible, and it would make a good tech demo.
I'm not convinced that any bike riders actually want that feature, though. Has anyone ever complained that they have too much control over their bicycle, and would like to cede some of that control to an algorithm?
Whenever Trump bursts out with another one of his brilliant ideas, immediately pass legislation to outlaw whatever it was he proposed. Yes, I can see some wisdom there.
I am talking about a bicycle you still have to pedal but it steers and brakes itself.
I applaud your ambition, but that sounds terrifying. Keep in mind that steering a bike is largely accomplished by leaning your weight to one side, which means that with a self-steering bike you would have to be constantly on hair-trigger alert, ready to lean when the bike wants to turn -- and if your attention ever wanders, you're likely to get dumped off the bike the next time it tries to turn and you don't cooperate:)
It would need a pedal powered GPS, sensors, and a fancy gear system that can engage and disengage the pedals from the drive train so you can keep pedalling when it brakes so that you can keep the GPS and other systems powered (maybe from a backup battery).
This bike might interest you; it's not self-steering but it has a lot of rest of the above.
Tell us. How old is too old for someone to drive a car without auto-braking? Is 86 years old too old? Is 100 years old too old?
There's no set age; it's going to depend on the individual. The standard DMV testing methodology is to sit the person down and have them play OutRun; if they can get to the third checkpoint without crashing, their license is renewed.
Why is it so goddamned important for the United States of America to maintain compatibility with the measurement system used by Myanmar and Liberia?!!
For the same reason it's so goddamned important for people to run Microsoft Windows and Microsoft Office at their businesses, even though cheaper and safer alternatives exist.
Tomorrow's United States of America wants to maintain backwards compatibility with today's United States of America.
Well, of course. Using that narrow definition of "purpose", the purpose of every commercial product is to generate income for the company that is manufacturing and selling that product; any desirable functionality of the product is only a means toward that end.
That's a true observation, but also an obvious and unremarkable one, except to anyone who was under the impression that corporations were a type of public-service-oriented nonprofit.
What's relevant is whether or not the product serves the customer's needs well, or not.
1. Why is Musk telling us this fanciful story that is obviously NOT going to happen and 2. What does he really intend to put in that hole? AND (more to the point) 3. Who is paying him to put it there?
Your far more likely to die from being trampled in an earthquake than from a tunnel collapse. We are not talking about mine shafts but rather oversized concrete tubes. A tube could split in half and move 3 inches and still be perfectly fine and usable.
I wonder how much the above remains true if you are moving through the tunnel at 125 MPH at the time of the quake?
Presumably this would be useful against malware that doesn't have root privilege (or whatever it's called in Windows-land). Currently, any software running at user-privilege level has the ability to munge the user's files, which by unfortunate coincidence are usually also the files that are the most valuable and most difficult to recreate after they get destroyed.
I'm not sure what would be sufficient to defend against malware that has root access, since presumably any defense you put up could be removed by the malware. Perhaps something involving custom hardware, e.g. a second drive with a drive controller that is hard-coded to allow only certain types of access to the data on it?
That's actually what has me wondering why this costs so damn much. Isn't the "technology" exactly the same as a floating oil rig, except instead of doing the considerably harder task of sending a pipe down to a fixed spot on the sea floor, they're just sticking a wind turbine on top of it?
I guess the next question would be, how much does it cost to set up an oil rig? It may be that a floating rig is expensive to set up regardless of what you do with it.
OTOH, if you're right, and there's no inherent reason for the additional expense, then I would expect costs to come down quickly once it has been established what works and what doesn't work in terms of off-shore wind. Everything costs more the first time, since you are still experimenting and often making sub-optimal or overly-conservative choices, and not operating at scale.
Slashdot Mirror
It's always puzzled me why, when so many bikes are bought for fitness, their purchasers seek out light weight and efficiency, which only reduces the fitness benefit.
Well, you could do it that way, and ride N miles on your heavy bike; or you could ride 3*N miles on a lighter bike and get the same amount of exercise while going faster and farther.
Most people prefer the latter, although YMMV. The real masochists go for the fixie bikes, of course, because gears are for the weak...
All "safe" solutions appear to be around restricting the solution space. It is like cutting off everyone's hands because some people have touched a hot stove. Yes, it is now guaranteed that no hot stoves will be touched but ... there are consequences.
Rust seems to have a pretty good solution to that problem -- if you absolutely need to do something unsafe, you can tag a section of your code as "unsafe" and then do whatever dark magic you need to do in that unsafe section -- at your own risk of course.
The advantage of this is that (hopefully) the vast majority of your codebase won't need to be written as unsafe-code, which means that the vast majority of your code will automatically receive the benefit of compiler-guaranteed safety, while the small portion that does need free reign will be tagged with a big red blinking UNSAFE sign so that anyone who is tempted to modify it will know to be extra careful.
Hopefully Tesla will continue to be honest, but the underlying issue is a valid one; if it's in the manufacturer's financial interest to put the driver at fault, what's to stop a less-than-scrupulous auto manufacturer from "doctoring" the automobile's driving logs (either before, during, or after the accident) in a way that would be very difficult for the humans involved to defend against? Especially after a few years/decades of the public (and judges and juries) being trained through experience to believe that the computers don't miss any details and never lie...
Remember the original Tron movie, where the software programs all looked just like the person who created them, except with neon duct tape on their clothes?
There's a lot of truth to that. The design of a piece of software will inevitably reflect the way its author thinks, his views about what the problem-space is and which techniques and engineering tradeoffs are appropriate, and the designer's own unique approach to problem-solving.
Moreover, the designer of the software is the person who has the most invested in that software's success, and thus the most motivation to keep its quality as high he is capable of -- other people may work on the codebase as well, but they are only step-parents, who may do a good enough job to keep things working (as far as customers can tell), but won't necessarily go the extra mile to make the software really shine, because hey, it's not their baby. To them, everything about the software looks like a bit of a mess, mainly because it wasn't implemented the way they would have done it. So why would they spend any more time on it than they have to?
So, when management decided to lay off Joe because they thought that with the app feature-complete they didn't need him anymore, they were unknowingly signing the death warrant for Joe's app at the same time. It won't die right away, since other programmers can come in, fix bugs, and add the occasional minor feature, but every time someone does that, the integrity and reliability of the codebase suffers a bit more, as the new developer's approach is different from Joe's approach, and thus the new code doesn't fit quite right with the old code. Eventually, development of the codebase slows to a near-halt, as the time, effort, and risk of making any further significant changes starts to outweigh the benefits that could be secured by making the changes. In another year or three, the app will be effectively dead, and the company will have to hire another Joe to write new software from scratch.
TL;DR: Programmers are not interchangeable parts.
People lose their minds over the landfill "problem", so it seems Mr. Musk is going to have a hard time convincing them to switch to solar.
It's not too difficult -- just demonstrate a way to recycle old solar equipment into new products. It's perfectly doable using today's technology.
Basically, this is an admission that the average programmer is fairly shitty.
Surely that was common knowledge already?
Then again, you don't want average programmers working on anything important, so by sticking with c, you're not going to get the "rust, rust, baby" programmers.
Because management is wise enough to understand the pitfalls of the C language and the risks of hiring a mediocre programmer, and will instead let the critical position remain open and let the product's shipping-schedule slip indefinitely until a Really Good C programmer finally comes along -- no matter how long that takes?
I think you are giving management a little too much credit there :)
Hire competent C developers and you should be good to go. Hire dumb-asses and sure the future doesn't look bright.
A competent C developer will make only a very small number of mistakes per N lines of code, so that's a good thing.
Of course, it only takes a single tiny mistake to produce potentially devastating consequences, so unless every single one of your C developers is not just good, but infallible, then by hiring "only" competent C programmers you are guaranteeing that your software will include a security hole, sooner or later.
The problem with infallible C programmers is that they do not exist. The problem with competent C programmers is that there are only a limited number of them around, and it's not always easy to tell up front the competent C programmers from the seemingly-competent ones. Not to mention that every competent C programmer started out as a less-than-competent C programmer; if companies hired only competent C programmers, there would not be any competent C programmers since nobody would be able to make a living as a C programmer during the first N years of their programming career.
Since the whole point of computers is to automate processes to make them quicker, easier, and less susceptible to human error, why would you not want to automate the creation of secure software, to the extent it is practical to do so?
The linux kernel is in its 3rd decade, as most gnu/bsd tools and all of that is written in plain C. They are good and safe.
Why do you think the Linux kernel is good and safe? It has suffered from many security holes in the past, and will probably suffer from more in the future. There are almost certainly multiple gaping security holes in the Linux kernel right now, just waiting to be discovered and exploited. And this is despite it being written by competent guys.
Imagine how much more robust the Linux kernel would be if the competent guys were also using a language that caught more of their mistakes at compile-time, rather than leaving them to be discovered by testers, users or hackers at some later date. Dunno if Rust is the language to do that, but it's hard to see how automatic coding-error detection wouldn't be a big improvement over the status quo.
Yes. Formal verification of most production programs will not happen in my lifetime or yours, or possibly ever, because it's expensive and nobody's paying for it.
The idea with Rust is that the Rust compiler does a significant amount of formal verification so that human beings don't have to.
It won't guarantee that your program does what you intended, but at least if your Rust program compiles, you have a pretty good assurance that it won't be corrupting its memory space and suffering from (potentially-exploitable) Undefined Behavior when it runs.
The simple fact is that there's a hue and cry about security but nobody really cares about it, because nobody's willing and able to pay what it would take to fix it.
There's some truth to that; in most cases, people are only going to invest a modest, finite amount of additional time/effort/money into making code secure.
Which is why it makes sense to minimize the cost of making code secure, e.g. by building the necessary checks into the language itself so that all programs benefit from them "for free".
The point is, somebody else already chose the correct way for the indentation to look [...] If you're choosing, you're doing it wrong
Or, you might be working on your own project. I know, it's a bizarre corner case, but it occasionally still happens.
No doubt a self-steering bike is possible, and it would make a good tech demo.
I'm not convinced that any bike riders actually want that feature, though. Has anyone ever complained that they have too much control over their bicycle, and would like to cede some of that control to an algorithm?
Whenever Trump bursts out with another one of his brilliant ideas, immediately pass legislation to outlaw whatever it was he proposed. Yes, I can see some wisdom there.
I am talking about a bicycle you still have to pedal but it steers and brakes itself.
I applaud your ambition, but that sounds terrifying. Keep in mind that steering a bike is largely accomplished by leaning your weight to one side, which means that with a self-steering bike you would have to be constantly on hair-trigger alert, ready to lean when the bike wants to turn -- and if your attention ever wanders, you're likely to get dumped off the bike the next time it tries to turn and you don't cooperate :)
It would need a pedal powered GPS, sensors, and a fancy gear system that can engage and disengage the pedals from the drive train so you can keep pedalling when it brakes so that you can keep the GPS and other systems powered (maybe from a backup battery).
This bike might interest you; it's not self-steering but it has a lot of rest of the above.
having to deal with AI-driven cars with dozing drivers inside
Sounds like a step up from the usual manually-driven cars with dozing drivers inside...
I only write it. Reading code is for the little people.
Tell us. How old is too old for someone to drive a car without auto-braking? Is 86 years old too old? Is 100 years old too old?
There's no set age; it's going to depend on the individual. The standard DMV testing methodology is to sit the person down and have them play OutRun; if they can get to the third checkpoint without crashing, their license is renewed.
Why is it so goddamned important for the United States of America to maintain compatibility with the measurement system used by Myanmar and Liberia?!!
For the same reason it's so goddamned important for people to run Microsoft Windows and Microsoft Office at their businesses, even though cheaper and safer alternatives exist.
Tomorrow's United States of America wants to maintain backwards compatibility with today's United States of America.
There is no dark side of the moon really.
Surely they meant the inside. It's very dark in there.
Well, of course. Using that narrow definition of "purpose", the purpose of every commercial product is to generate income for the company that is manufacturing and selling that product; any desirable functionality of the product is only a means toward that end.
That's a true observation, but also an obvious and unremarkable one, except to anyone who was under the impression that corporations were a type of public-service-oriented nonprofit.
What's relevant is whether or not the product serves the customer's needs well, or not.
There's nobody on a deserted island to make use of any plastic bottles that are there.
1. Why is Musk telling us this fanciful story that is obviously NOT going to happen and 2. What does he really intend to put in that hole? AND (more to the point) 3. Who is paying him to put it there?
You forgot: 4. Has he stopped beating his wife?
Your far more likely to die from being trampled in an earthquake than from a tunnel collapse. We are not talking about mine shafts but rather oversized concrete tubes. A tube could split in half and move 3 inches and still be perfectly fine and usable.
I wonder how much the above remains true if you are moving through the tunnel at 125 MPH at the time of the quake?
I don't recall Musk ever taking a vow of public service. If his intentions are purely selfish, then so be it. He doesn't owe you jack.
Presumably this would be useful against malware that doesn't have root privilege (or whatever it's called in Windows-land). Currently, any software running at user-privilege level has the ability to munge the user's files, which by unfortunate coincidence are usually also the files that are the most valuable and most difficult to recreate after they get destroyed.
I'm not sure what would be sufficient to defend against malware that has root access, since presumably any defense you put up could be removed by the malware. Perhaps something involving custom hardware, e.g. a second drive with a drive controller that is hard-coded to allow only certain types of access to the data on it?
That's actually what has me wondering why this costs so damn much. Isn't the "technology" exactly the same as a floating oil rig, except instead of doing the considerably harder task of sending a pipe down to a fixed spot on the sea floor, they're just sticking a wind turbine on top of it?
I guess the next question would be, how much does it cost to set up an oil rig? It may be that a floating rig is expensive to set up regardless of what you do with it.
OTOH, if you're right, and there's no inherent reason for the additional expense, then I would expect costs to come down quickly once it has been established what works and what doesn't work in terms of off-shore wind. Everything costs more the first time, since you are still experimenting and often making sub-optimal or overly-conservative choices, and not operating at scale.
[EMET] promptly broke almost all of our Java application (Kills the virtual machine).
Sounds like it knows just what to do. If it gets rid of Flash as well, we're golden. ;)