"Traditional" turbine designs are already up to 80% theoretical maximum efficiency. Trying to eke that last 20% is not really going to save the planet since we're nowhere near using that much wind in the first place.
That is - if you want to get FOSS to improve tech adoption, direct it to making things more affordable or accessible, not toward having more expensive higher-efficiency, higher-complexity devices.
It's more astonishing to think of what having a billion dollars as an individual means. Think about this. The median income for a person in the US is something like $50k (rounding to make math easy). A billion is one million thousand. So a billion dollars is twenty thousand years of median income. It's an absurd amount of money for an individual.
I'm generally not in the "limit people's wealth" camp, but it starts getting strange to think that it's reasonable for any individual to have wealth equivalent to more that even, oh, say, 1000 years of income.
I'm all for hybrid and electric vehicles, but I'm really not happy that every industry is going to over-the-air update models.
There are of course the security issues, but there is also the more insidious side effect that it promotes a "ship it now" mentality instead of "ship it when it's ready" mentality.
I'm hoping the "right to repair" movement maintains its momentum and also includes "right to not require connectivity."
Back when just backup cameras, not the auto-braking, was made mandatory in the US, it was something like 300-400 backup-related deaths per year estimated saved at a cost of about $200 per vehicle, or about $3.4 B total cost to the US market per year, or something like $8-$11M per life saved.
We are well past the economically sensible rate of return on investment for these features (per capita GDP is only about $2.5M per lifetime). But when western culture is "prevent harm at any cost" this is what happens.
It's unpopular and perhaps insensitive to say it - because none of us wants to be the person affected by such an accident - but those are the hard numbers. Generally speaking, in rich countries, we are throwing unsustainable sums of money at the long tail of some hazards while eschewing much higher ROI activities.
For instance, if we spent $3.5B on coronary bypass surgeries instead of backup cameras we'd probably save close to 45000 lives per year (and that's at the high mean cost of $75k per bypass surgery in the US). That's more than all automotive deaths per year in the US by a significant amount, and safely two orders of magnitude more than just the cost/benefit for backup cameras.
I've never liked the 'unsafe' keyword. It gives two false impressions: code that uses it is unsafe and code that doesn't use it is safe.
A much better keyword is probably 'unmanaged', because that doesn't connote incorrect assumptions and actually represents what the keyword means.
I'm also a firm believer that the most severe software bugs are due to code that isn't designed but merely written. Code is often written only looking at a "nominal" use case without considering failure modes, so even in the rare instances where there are tests in place the tests don't often catch the errors (just look at stuff like the recent Malwarebytes-eating-all-the-RAM thing).
No language is ever going to be able to eliminate software development culture errors. And by "software development culture" I mean things like you need a design, you need tests, and those tests need to adequately cover off-nominal use cases.
How is this not automated? Should just be a computer program that does "find the N points such that each point is the closest point to exactly P/N people."
That is, make a Voronoi diagram on population, not geometric distance.
No politics involved at all, but probably people wouldn't like it...
They also only talk about percentage, not absolute numbers. The article does mention that Norway only has a population of 5.3 million though.
This shows they Norway only has a market for about 200k vehicles per year.
The US market is about 17600k vehicles per year for comparison. This
suggests that the US has almost 200k electric vehicles a year sold - so a greater total number than Norway.
So I guess the US is not doing too bad in aggregate, even without crazy subsidies, but we're doing really poorly as a market share.
The "market" can only (at best) make profitable decisions, it cannot make wise decisions.
It may not be the case that "government" makes wise decisions, but something other than the market itself is necessary to make decisions based on things other than profit.
What some consider "waste" I consider a "feature": the extra redundant analog information in AM/FM that allows me to listen to (or watch) a distant signal with fairly high noise. Now you either get a station or you don't, there is no "I'm beyond the design signal to noise ratio so I get a little static but otherwise no big deal."
If you are doing things in which you need to be sure about security and/or safety you should be using static and dynamic tests and checks, which would find most of those issues with pointers and arrays. You should do those things even with a managed language.
Also, I would much prefer a language that allows me low level things (there is no reason you cannot implement a Pascal-style string in C, for instance) instead of forcing some restricted choice of operations decided by the language or library committees.
As for garbage collection - if you are really into security or safety, the most robust approach is to have no dynamic memory allocation at all. But when dynamic memory allocation is required, it really would be nice if deterministic (in both runtime and time-of-run) garbage collectors were available.
Sadly it seems it doesn't matter; only money seems to matter. Around where I live, I've seen at least 100 acres of forest razed in the past year to put up shopping centers and subdivisions. And yes I mean forests - there is plenty of blighted urban area around, but instead of re-using that, they are razing forests...
It's like there isn't even any consideration of how this will affect the overall environment - what happens is the city planners say "sweet, we'll get property tax revenue on 300 more housing units!" and forget about all the ancillary effects. They even gloss over the short term effects like massive increases in traffic (putting 300 new residential units in an already congested area is baffling), how can you expect them to consider effects on climate change that will manifest over 50-100 years?
This was my thought too - if you have a critical component in a system, you want to make it as difficult as possible to get wrong.
Especially if there is clearly a "correct" and "incorrect" way to do something. There's a reason most sane cables either make it extremely difficult to connect in the wrong orientation or even better make it so all the likely orientations are serviceable.
The tools and frameworks could pick up the ball and make it more difficult to get things wrong, this would be much less an issue.
This was kind of my thought too - why do they need maps? I learned to drive without a map. I had to learn directions to local areas as I went. And when I do need a map, they are not "ridiculously detailed" - a road atlas has a pretty coarse scale.
Maybe part of the difficulty in achieving autonomous cars is that people seem to be trying to have the autonomous agents "know everything" at time of manufacture, rather than learn as they go.
We also have the situation that climate in the media has now reached the point where people make movies like Geostorm. I saw a preview for that this weekend and hadn't actually realized just how ridiculous things are until that moment. I mean, I kind of knew society is crazy, but that made me feel it viscerally.
I'd say 8MB is "bleeding edge" not "state of the art" - but it's still the same order of magnitude. Mostly because (even with all the OBD overhead) that much code space just isn't required and it costs a lot.
And also, yes, while there may be 20 modules connected, most of them are nowhere near as complex as the heavy-lift controllers (engine control, supervisory, etc.) so they are not likely to have the modules with expensive 8MB parts.
I also have yet to see an instance where calibration data size exceeds code size - out of about a dozen projects, so I'm not talking one-offs here. But I'd be curious what types of vehicle controllers have more cal flash than code flash.
Forget about needing100 million lines of code - it's not even physically possible to put that much code in the critical components of a vehicle.
A typical state-of-the-art engine controller only has maybe 2-4 MB of flash (yes, M, not G). This puts an easy upper limit on the number of lines of code in the engine controller at something on the order of 100s of thousands (not millions) of lines of code - figuring about 10 bytes of generated code per line.
That 100 million lines probably includes Windows or Linux or whatever is being put in the infotainment systems - not in the actual vehicle control systems.
This was my thought too. This UI is really pushing the assumption that autopilot and similar features are going mainstream - if that's the case then you wouldn't need that "eyes always on the road" tactile feedback.
I can't say the side of me that enjoys driving is pleased, but that is the way things are going.
It seems you missed the half-joking nature of my OP... or perhaps didn't care?
Yes, it is possible to create flawless software - if you have no constraints on budget or time and the requirements are actually unvarying and correct.
Code itself isn't the problem, which is why the language du jour never eliminates the problem. It is very rare that a project is willing to even attempt to produce "flawless" software. And even our best efforts (MISRA, RTCA, ISO, and the like) at "safety critical" software processes fail to prevent seemingly trivial flaws - so there is something that is beyond technology.
So yes, perhaps calling it "conservation of bugs" is a bit trite. I don't know what else to call it though.
I suspect that there is something like a "law of conservation of bugs" or something in software - you take away one vector for bugs to originate and you just move them into another place.
Dynamic languages do have an easy way to introduce bugs - especially languages like javascript that simply create new variables if you have a typo.
But there is the old adage in statically typed compiled languages "Hey, my code compiles! Now I get to find out where all my bugs really are."
This also applies to other aspects of programming languages. Consider the arguments about manual vs automatic memory management. Managed code still has bugs, just not memory management bugs.
Slashdot Mirror
Rent-seeking: great if you're the property-owner, terrible for absolutely everyone else.
"Traditional" turbine designs are already up to 80% theoretical maximum efficiency. Trying to eke that last 20% is not really going to save the planet since we're nowhere near using that much wind in the first place.
That is - if you want to get FOSS to improve tech adoption, direct it to making things more affordable or accessible, not toward having more expensive higher-efficiency, higher-complexity devices.
It's more astonishing to think of what having a billion dollars as an individual means. Think about this. The median income for a person in the US is something like $50k (rounding to make math easy). A billion is one million thousand. So a billion dollars is twenty thousand years of median income. It's an absurd amount of money for an individual.
I'm generally not in the "limit people's wealth" camp, but it starts getting strange to think that it's reasonable for any individual to have wealth equivalent to more that even, oh, say, 1000 years of income.
I'm all for hybrid and electric vehicles, but I'm really not happy that every industry is going to over-the-air update models.
There are of course the security issues, but there is also the more insidious side effect that it promotes a "ship it now" mentality instead of "ship it when it's ready" mentality.
I'm hoping the "right to repair" movement maintains its momentum and also includes "right to not require connectivity."
Back when just backup cameras, not the auto-braking, was made mandatory in the US, it was something like 300-400 backup-related deaths per year estimated saved at a cost of about $200 per vehicle, or about $3.4 B total cost to the US market per year, or something like $8-$11M per life saved.
We are well past the economically sensible rate of return on investment for these features (per capita GDP is only about $2.5M per lifetime). But when western culture is "prevent harm at any cost" this is what happens.
It's unpopular and perhaps insensitive to say it - because none of us wants to be the person affected by such an accident - but those are the hard numbers. Generally speaking, in rich countries, we are throwing unsustainable sums of money at the long tail of some hazards while eschewing much higher ROI activities.
For instance, if we spent $3.5B on coronary bypass surgeries instead of backup cameras we'd probably save close to 45000 lives per year (and that's at the high mean cost of $75k per bypass surgery in the US). That's more than all automotive deaths per year in the US by a significant amount, and safely two orders of magnitude more than just the cost/benefit for backup cameras.
I've never liked the 'unsafe' keyword. It gives two false impressions: code that uses it is unsafe and code that doesn't use it is safe.
A much better keyword is probably 'unmanaged', because that doesn't connote incorrect assumptions and actually represents what the keyword means.
I'm also a firm believer that the most severe software bugs are due to code that isn't designed but merely written. Code is often written only looking at a "nominal" use case without considering failure modes, so even in the rare instances where there are tests in place the tests don't often catch the errors (just look at stuff like the recent Malwarebytes-eating-all-the-RAM thing).
No language is ever going to be able to eliminate software development culture errors. And by "software development culture" I mean things like you need a design, you need tests, and those tests need to adequately cover off-nominal use cases.
How is this not automated? Should just be a computer program that does "find the N points such that each point is the closest point to exactly P/N people."
That is, make a Voronoi diagram on population, not geometric distance.
No politics involved at all, but probably people wouldn't like it...
What, you mean you don't value eyesight at approximately 17 years of median income?
They also only talk about percentage, not absolute numbers. The article does mention that Norway only has a population of 5.3 million though.
This shows they Norway only has a market for about 200k vehicles per year.
The US market is about 17600k vehicles per year for comparison. This suggests that the US has almost 200k electric vehicles a year sold - so a greater total number than Norway.
So I guess the US is not doing too bad in aggregate, even without crazy subsidies, but we're doing really poorly as a market share.
The "market" can only (at best) make profitable decisions, it cannot make wise decisions.
It may not be the case that "government" makes wise decisions, but something other than the market itself is necessary to make decisions based on things other than profit.
That is terrifying.
What some consider "waste" I consider a "feature": the extra redundant analog information in AM/FM that allows me to listen to (or watch) a distant signal with fairly high noise. Now you either get a station or you don't, there is no "I'm beyond the design signal to noise ratio so I get a little static but otherwise no big deal."
If you are doing things in which you need to be sure about security and/or safety you should be using static and dynamic tests and checks, which would find most of those issues with pointers and arrays. You should do those things even with a managed language.
Also, I would much prefer a language that allows me low level things (there is no reason you cannot implement a Pascal-style string in C, for instance) instead of forcing some restricted choice of operations decided by the language or library committees.
As for garbage collection - if you are really into security or safety, the most robust approach is to have no dynamic memory allocation at all. But when dynamic memory allocation is required, it really would be nice if deterministic (in both runtime and time-of-run) garbage collectors were available.
Sadly it seems it doesn't matter; only money seems to matter. Around where I live, I've seen at least 100 acres of forest razed in the past year to put up shopping centers and subdivisions. And yes I mean forests - there is plenty of blighted urban area around, but instead of re-using that, they are razing forests...
It's like there isn't even any consideration of how this will affect the overall environment - what happens is the city planners say "sweet, we'll get property tax revenue on 300 more housing units!" and forget about all the ancillary effects. They even gloss over the short term effects like massive increases in traffic (putting 300 new residential units in an already congested area is baffling), how can you expect them to consider effects on climate change that will manifest over 50-100 years?
There are many ways to have unwanted interaction that don't involve improperly shared global state.
But a knife doesn't just slit your throat while you're holding the handle and trying to cut a piece of meat.
A knife might be dangerous, but it's not "easy to get wrong."
You can also have fully unit tested code, and as soon as you start integrating it into another system, things fall apart.
Integration testing is much much harder than unit testing.
This was my thought too - if you have a critical component in a system, you want to make it as difficult as possible to get wrong.
Especially if there is clearly a "correct" and "incorrect" way to do something. There's a reason most sane cables either make it extremely difficult to connect in the wrong orientation or even better make it so all the likely orientations are serviceable.
The tools and frameworks could pick up the ball and make it more difficult to get things wrong, this would be much less an issue.
This was kind of my thought too - why do they need maps? I learned to drive without a map. I had to learn directions to local areas as I went. And when I do need a map, they are not "ridiculously detailed" - a road atlas has a pretty coarse scale.
Maybe part of the difficulty in achieving autonomous cars is that people seem to be trying to have the autonomous agents "know everything" at time of manufacture, rather than learn as they go.
We also have the situation that climate in the media has now reached the point where people make movies like Geostorm. I saw a preview for that this weekend and hadn't actually realized just how ridiculous things are until that moment. I mean, I kind of knew society is crazy, but that made me feel it viscerally.
I'd say 8MB is "bleeding edge" not "state of the art" - but it's still the same order of magnitude. Mostly because (even with all the OBD overhead) that much code space just isn't required and it costs a lot.
And also, yes, while there may be 20 modules connected, most of them are nowhere near as complex as the heavy-lift controllers (engine control, supervisory, etc.) so they are not likely to have the modules with expensive 8MB parts.
I also have yet to see an instance where calibration data size exceeds code size - out of about a dozen projects, so I'm not talking one-offs here. But I'd be curious what types of vehicle controllers have more cal flash than code flash.
Forget about needing100 million lines of code - it's not even physically possible to put that much code in the critical components of a vehicle.
A typical state-of-the-art engine controller only has maybe 2-4 MB of flash (yes, M, not G). This puts an easy upper limit on the number of lines of code in the engine controller at something on the order of 100s of thousands (not millions) of lines of code - figuring about 10 bytes of generated code per line.
That 100 million lines probably includes Windows or Linux or whatever is being put in the infotainment systems - not in the actual vehicle control systems.
This was my thought too. This UI is really pushing the assumption that autopilot and similar features are going mainstream - if that's the case then you wouldn't need that "eyes always on the road" tactile feedback.
I can't say the side of me that enjoys driving is pleased, but that is the way things are going.
It seems you missed the half-joking nature of my OP... or perhaps didn't care?
Yes, it is possible to create flawless software - if you have no constraints on budget or time and the requirements are actually unvarying and correct.
Code itself isn't the problem, which is why the language du jour never eliminates the problem. It is very rare that a project is willing to even attempt to produce "flawless" software. And even our best efforts (MISRA, RTCA, ISO, and the like) at "safety critical" software processes fail to prevent seemingly trivial flaws - so there is something that is beyond technology.
So yes, perhaps calling it "conservation of bugs" is a bit trite. I don't know what else to call it though.
I suspect that there is something like a "law of conservation of bugs" or something in software - you take away one vector for bugs to originate and you just move them into another place.
Dynamic languages do have an easy way to introduce bugs - especially languages like javascript that simply create new variables if you have a typo.
But there is the old adage in statically typed compiled languages "Hey, my code compiles! Now I get to find out where all my bugs really are."
This also applies to other aspects of programming languages. Consider the arguments about manual vs automatic memory management. Managed code still has bugs, just not memory management bugs.