You Canucks don't know fat from freedom fries. Obese? We're at 31%, and you polite national-health-plan hockey-playing doofuses aren't even half that. Yee haw, my ass.
The free market does a piss-poor job of dealing with external costs (those not paid by the consumer), and the government is the appropriate mechanism for connecting the costs back to the people who create them. The problem, in this case, is that the government is imperfect and got more or less hijacked by the farm lobby (and this is hardly the only time this has happened).
A better approach would simply be to impose a GHG tax -- taxes on the various gasses, for the various industries that produce them. According to the work I've read by Pimentel, that would probably kill corn ethanol, because fertilizer would get much more expensive. There's a chance they could thread the needle by using the sugar-depleted byproducts to feed cattle, which would in turn be less gassy, and which would reduce their GHG tax.
I would say, "no", even though I am in much the same boat (except, because my bicycle is non-stationary and I use it to commute, I clearly also deserve the same CO2-avoidance subsidy that Prius buyers get). The problem is measurement and proof -- can you prove that you ride your bike? Can I prove that I ride mine? Can I prove that I ride my bike to offset actual commuting, as opposed to riding it in circles, so I am actually reducing CO2 emissions?
If, however, the incentives are implemented with taxes on things we are expected to avoid, and if the taxes are made revenue-neutral by reducing some other tax , then there's no need to prove anything -- you'll avoid the junk food, you'll save a little money by not paying that tax, and you'll save a little money because (say) the income tax was reduced. This works very well with a gasoline tax to discourage CO2 emission, for example.
This works least well for your exercise. If I'm commuting by bike, I can save on gasoline, so there is some small reward. If we tied auto insurance more closely to miles-per-year, I'd save there, but I don't, but you can see how that would work. It's possible to "subsidize" non-stationary biking as they do in Northern Europe, with everything from well-designed bike paths and bike-friendly traffic laws to hill-climbing lifts for bicycles. On a stationary bicycle, you get none of this. So clearly, you need to get out more, though that big bright thing in the blue ceiling might tarnish your minty-green slashdot complexion.
Years ago (mid 1996), when Java was young, some of us (compiler hackers) looked at this interpreted browser language, and said "this is a fine language for general-purpose computing, people are going to program great big servers in it, multiprocessors, even" -- and we decided to use write a compiler for it, instead of, say, debugging tools. And we didn't know squat about marketing and sales, we talked to the wrong people, etc, etc. (We did fun stuff -- we could scale the Volano benchmark out to 800 rooms on 2-processor x86 box -- that's 32000 threads. We kicked ass on Trade2. But we never made any money. And since then, working at Sun, I've learned about cool new stuff you can do with scalable synchronization, that if I had known back then, would have allowed us to REALLY kick ass and not make money. So don't think that there's nothing for you to learn at MegaCorp, either.)
So if you are lucky enough to have MegaCorp waving money in your face, I would negotiate the best possible deal, and take the money. You will want to do more than one thing in your life, anyway. My father worked on guidance systems for years (everything from torpedo gyros run by a spring, to B52 gyros run in a vacuum suspended by electrostatic force, so even that is not the single boring job that it seems), did solar hot water for a hobby, then worked on medical devices in "retirement", and right now he's politically active in a major grass-roots sort of way.
So, heck, if you don't need the money for retirement, you could get into politics.
This is certainly what I have heard, and angels can yank money at the drop of a hat, too.
Growing your own company, with sales and market and support and etc, is HARD. It's probably not fun, it's probably not what you're good at. Knowing what I know now (worked at Sun, then worked at 4 startups, now back at Sun), I recommend assuming that you will do the deal with MegaCorp, but also be sure you are prepared for the negotiation (you might want professional help). And don't be afraid to say "no"; they're going to make the smallest offer they think you are likely to accept.
And be prepared for life without your great little company. It will help you make better decisions.
I'm saying that in the absence of a dedicated bike lane, radical differences between the fastest and slowest vehicles on the road are the most common root cause of accidents that don't involve some form of impairment.
#1, I thought you were talking about traffic jams -- which usually are not caused by accidents, at least not on the surface streets where bicycles are most common, and #2 your assertion is not true anyway. Overtaking accidents are rare (you can look it up), and the place where they are most common (last time I checked the stats) was in rural areas.
So I don't know what you're getting at. Interesting theory, but not based on facts.
In terms of "it's a car problem", you can get traffic jams with no bicycles at all, just from the sheer density of cars. This indicates to me that traffic jams are not caused by bicycles, and since they are caused by simply cramming too many cars onto one piece of pavement, that moving drivers out of cars and onto bicycles might just help.
I'm sure you know all this already since you comment with such authority, but two good sources of information are Effective Cycling ( byJohn Forester ) and a presentation by John Pucher on cycling in Northern Europe. Pucher is a fan of bike lanes, not because they are necessary to the free flow of auto traffic, but because they make cyclists feel safe enough to ride en masse. Forester is lukewarm on paths and downright anti-lane, but he makes the point rather well (with plenty of numbers) that there is nothing incompatible about bikes and cars on the same road. However, in terms of getting bikes on the road, he views it as a problem of education, which means his approach is doomed. (Step one: ignore your fear of overtaking vehicles. Lots of people never make it to step two.)
What you say is not true anywhere that I have ever lived (FL, TX, CA, MA). Except in business districts (in some states), not one of your assertions is true; cars need to provide a few feet (3 or 4, I think it depends on jurisdiction), it is legal for a bike to pass on the right or the left (and between lanes would be lane-splitting, also apparently legal in CA and MA), and in most cases, riding on the sidewalk, though unwise, is legal. I've only ever seen it banned in business districts (which is pretty common).
Source (for most of it): http://www.massbike.org/bikelaw/statelaws.htm
And http://bikexprt.com/massfacil/laws/drivmanl.htm
And also http://www.bikexprt.com/massfacil/laws/passright.htm .
Interestingly, at the time this was written, Uniform Vehicle Code generally allowed bikes to pass on the right at their own risk, where Massachusetts, technically speaking, only allows it if the car is also moving. This is not the sort of thing that keeps me up late at night worrying; Massachusetts has many quaint laws, which are appropriately (un)enforced (read the first of the two bikexprt pages for amusing details).
We must be misunderstanding each other. I ride my bike to work twice per week, every week (except holidays), 10 miles one way, about 200 miles per month. Snow tires go on once it starts snowing, stay on till we are getting good melting. That's about 4 months, for a little less than 800 miles. Then I take them off, and put on the other tires.
Snow tires are commuter grade Nokians (H106) or Schwalbe (Marathon Winter). No flats, but the studs do eventually get a little rounded and oriented away from the road/ice, so the traction degrades.
So what I'm trying to say is, you ought to be able to bike even when the snow is not melted, if you got some snow tires, and used them only for those months, and your wear was like my wear. With those assumtions, you ought to be able to get about 1200-1600 miles out of them (2000-2500 km). 13km/day, times 20, gives 260km/month, or 8-10 months (roughly), spread over at least two winters, maybe three.
How insurance is funded has a lot to do with this "works" issue. I drive a Honda Civic, near Boston. Fuel-efficient car, in an area (in)famous for its driving, plus a do a significant fraction (40%) of my commuting by bike. I spend about as much on insurance as I do on gasoline. The last time I asked the insurance company for a low-mileage discount (years ago, with a car that I was only driving 1k/year) I was offered at 10% reduction in rate for a 60% reduction in estimated mileage. Pretty much, insurance is a high flat rate, plus a low per-mile cost.
In that world, using the car rarely but more than zero, has a high cost. It might push you to get rid of the car altogether because of the cost, but it's inconvenient.
Switching to a true pay-per-mile system (say, GPS + black boxes) or an approximate pay-per-mile system (gas surcharge, either linked to your insurance company through your credit card, or just run as a state system) rewards you more for not driving, while still allowing the convenience of having a car when you need it (such a change would probably doom ZipCar, but oh well).
Of course, there's also the interesting assertion that the car "works" for anyone. Last I noticed, I live in a nation full of fat people who don't get enough exercise. If that's your norm, the risk from cardiovascular disease of continuing to drive the car to the exclusion of biking and walking, is very high -- much higher than the risk of injury from biking.
I think you missed my point, and I think you are confused about the cause of the traffic jams.
First, I would not normally propose putting bikes on interstates; they're not designed for it, they're not safe, it's not pleasant. Many places, it's technically not legal (as if traffic laws were enforced). There are usually alternative routes.
But, on ordinary roads, on ordinary commutes, if your commute is already frequently impeded by traffic jams, bikes are not going to make it worse. Someone who chooses not to drive because of traffic jams, is another car not in the jam, not in your way. The crucial element in the traffic jam seems to be cars.
Your post also assumes that cars are the norm, and not themselves the case of problems. Notice that, in a car-bike mix, with stopped cars and moving bikes, you (and for that matter, I) call it a "traffic jam". The cars are "traffic", the bikes are something else. How many bikes would there need to be, before we decided that the traffic was flowing well and it was just a car problem? This is similar to the "bikes take the whole lane" gripe I sometimes hear. The car stuck behind the bike needs "the whole lane", and the bike just happens to be taking a fraction of it that the car needs. If the car were smaller (a Smart Car, e.g.) or a scooter, or another bicycle, it would not be impeded by a single bicycle in front of it in a 10-foot lane. It's a car problem, not a bike problem.
That employer parking costs someone money, and if employees weren't using it for cars, your employer could make some other use of it, lease it out to someone else, put a building on it or offices in it.
Mandated underground parking is a tax on business; why not expose the cost of parking, and let people make their own decisions?
A cargobike plus an electricassist will carry a load of groceries and/or a kid or two, and will do it with a daily range that is depressingly competitive with a lot of the e-cars being discussed nowadays (i.e., 40 miles -- 20 in a day on a human-powered cargo bike is a no-brainer). Wouldn't necessarily work in the boonies, but lots and lots of people drive in places that where 20-40 miles per day, most days, is enough.
One hopes that I won't hear the same tired excuses about rain, snow, dark, ice, and locusts; you're not supposed to bike naked (NSFW). That's why we have fenders, raincoats, gloves, and snow tires. What mostly lacks is a place that feels safe enough to ride; what we have now probably IS safe enough, but it seems unsafe, so that's the end of it for most people.
Or maybe the problem is that you think bicycles are slow.
Or maybe you think you'll miss taking your SUV off-roading.
I ended up with the LM258 because it fit my application -- controlling BuckPuck output on a hub dynamo-driven bike light. It needs to be making sense of its inputs with as little as 7.5 volts of power (when the LEDs begin to light) and not catch fire till 32V.
But boy howdy, I used a bunch of LM324s in a theater lightboard almost 30 years ago.
What's amazing to me is how the op-amps have been improved. I checked out of analog chips for about 25 years, then had occasion to use them. LM258 -- runs on 3 to 32 volts, rail-to-rail inputs and outputs, uses a whole milliamp to run.
Or the LMC6462 -- 3 to 15 volts, rail-to-rail in and out, 50 microamps supply, and an input resistance of 10 TeraOhms.
That's a little surprising, given that Linux is said to be a monolithic OS, not a kernel OS like Minix, and thus should contain lots of stuff that has nothing to do with device drivers or page tables. Are you sure this is not an artifact of by-hand inlining for efficiency? In other systems I've worked on or looked at, the truly "unsafe" stuff is quite small and confined to a few smallish modules -- but either they don't sweat the efficiency of a procedure call, or assume that inlining will make it better (or both).
I suspect very much that the number you report is an artifact of working in a language that is by default unsafe; there's no disincentive to sticking little unsafe bits of code here and there, so programmers do, and the result is a large volume of "unsafe" functions where you ought to just have a few unsafe functions that are frequently called. For example, Java "floatToIntBits" is a safe operation, but it has an unsafe implementation (it has a loophole, which can be used in an unsafe way). If you call the method, the calling code is safe, but if you inline it by hand, then it contains an unchecked cast, which is not known to be safe without further examination of the code.
Note that Singularity, SPIN, and Cedar all take a strategic approach to efficiency; by leveraging type safety, they can avoid the costs of a user/kernel context switch and constant rechecking of user inputs. The SPIN guys, long ago, reported great performance results from doing what in Linux would be the equivalent of putting the http server in the kernel. I've worked on Java systems that were designed in much the same way -- rather than invoking "native" code (which can be surprisingly costly, depend on GC and thread details) just drop into the "unsafe" implementation extension.
The actual rules for enforcing safety in language like Modula-3 or Cedar are simple, easy to understand, and not too hard to get right. That's not rocket science. Concurrent parallel realtime garbage collection -- that's rocket science, but if your application demands higher levels of assurance, you either work very hard at verifying and proving the GC, or else you use a less sexy algorithm (e.g., original Baker-style read barriers, or plain old stop-N-copy) and add more memory.
There have been quite a few "safe" languages (e.g., Java) that also had an unsafe extension that allowed you to code the icky bits when you needed to. The first language I know of to be explicitly structured like that was Cedar Mesa at Xerox PARC, then some PARC refugees at DEC-SRC and Acorn Research developed Modula-2+, and from that Modula-3. You can see the ideas now in C#, with "managed" and "unmanaged" code. There have been at least three the-Java-TM-Programming-Language-ish systems that included this as part of their implementation techniques, though they did not expose it to end users. A colleague who once worked at Curl reports that they had something similar there.
The idea is to only enable the unsafe stuff when it is truly necessary (and probably, to have code reviews where the default answer to any unsafe code is to reject it unless it can be justified). If you need to peek and poke device registers, you can do it, but by default, your code is safe and immune to buffer overflows. On a percentage basis, very little of a kernel is actually talking to bare metal; most of it is talking about talking to the bare metal.
The biggest problem I have seen with unsafe extensions is when ex-C -programmers, in their usual pursuit of premature optimization, immediately turn on the unsafe bit and start spraying bugs all over the place. The ex-Curl colleague reports a similar experience. (And the easiest way to get a confirmed negative opinion of C programmers, is to watch them do this.)
Slashdot Mirror
You Canucks don't know fat from freedom fries. Obese? We're at 31%, and you polite national-health-plan hockey-playing doofuses aren't even half that. Yee haw, my ass.
(See http://www.nationmaster.com/graph/hea_obe-health-obesity )
The free market does a piss-poor job of dealing with external costs (those not paid by the consumer), and the government is the appropriate mechanism for connecting the costs back to the people who create them. The problem, in this case, is that the government is imperfect and got more or less hijacked by the farm lobby (and this is hardly the only time this has happened).
A better approach would simply be to impose a GHG tax -- taxes on the various gasses, for the various industries that produce them. According to the work I've read by Pimentel, that would probably kill corn ethanol, because fertilizer would get much more expensive. There's a chance they could thread the needle by using the sugar-depleted byproducts to feed cattle, which would in turn be less gassy, and which would reduce their GHG tax.
For some discussion of food production (which gives some idea of the GHG production of farming corn), see Eschel and Martin, Diet, Energy, and Global Warming
I would say, "no", even though I am in much the same boat (except, because my bicycle is non-stationary and I use it to commute, I clearly also deserve the same CO2-avoidance subsidy that Prius buyers get). The problem is measurement and proof -- can you prove that you ride your bike? Can I prove that I ride mine? Can I prove that I ride my bike to offset actual commuting, as opposed to riding it in circles, so I am actually reducing CO2 emissions?
If, however, the incentives are implemented with taxes on things we are expected to avoid, and if the taxes are made revenue-neutral by reducing some other tax , then there's no need to prove anything -- you'll avoid the junk food, you'll save a little money by not paying that tax, and you'll save a little money because (say) the income tax was reduced. This works very well with a gasoline tax to discourage CO2 emission, for example.
This works least well for your exercise. If I'm commuting by bike, I can save on gasoline, so there is some small reward. If we tied auto insurance more closely to miles-per-year, I'd save there, but I don't, but you can see how that would work. It's possible to "subsidize" non-stationary biking as they do in Northern Europe, with everything from well-designed bike paths and bike-friendly traffic laws to hill-climbing lifts for bicycles. On a stationary bicycle, you get none of this. So clearly, you need to get out more, though that big bright thing in the blue ceiling might tarnish your minty-green slashdot complexion.
There is that. The chain that starts fresh in April, and is barely worn by November, is completely consumed by the next April.
I'm thinking seriously about a bike upgrade, including sealed rear hub and some amount of chain case.
Years ago (mid 1996), when Java was young, some of us (compiler hackers) looked at this interpreted browser language, and said "this is a fine language for general-purpose computing, people are going to program great big servers in it, multiprocessors, even" -- and we decided to use write a compiler for it, instead of, say, debugging tools. And we didn't know squat about marketing and sales, we talked to the wrong people, etc, etc. (We did fun stuff -- we could scale the Volano benchmark out to 800 rooms on 2-processor x86 box -- that's 32000 threads. We kicked ass on Trade2. But we never made any money. And since then, working at Sun, I've learned about cool new stuff you can do with scalable synchronization, that if I had known back then, would have allowed us to REALLY kick ass and not make money. So don't think that there's nothing for you to learn at MegaCorp, either.)
So if you are lucky enough to have MegaCorp waving money in your face, I would negotiate the best possible deal, and take the money. You will want to do more than one thing in your life, anyway. My father worked on guidance systems for years (everything from torpedo gyros run by a spring, to B52 gyros run in a vacuum suspended by electrostatic force, so even that is not the single boring job that it seems), did solar hot water for a hobby, then worked on medical devices in "retirement", and right now he's politically active in a major grass-roots sort of way.
So, heck, if you don't need the money for retirement, you could get into politics.
This is certainly what I have heard, and angels can yank money at the drop of a hat, too.
Growing your own company, with sales and market and support and etc, is HARD. It's probably not fun, it's probably not what you're good at. Knowing what I know now (worked at Sun, then worked at 4 startups, now back at Sun), I recommend assuming that you will do the deal with MegaCorp, but also be sure you are prepared for the negotiation (you might want professional help). And don't be afraid to say "no"; they're going to make the smallest offer they think you are likely to accept.
And be prepared for life without your great little company. It will help you make better decisions.
I'm saying that in the absence of a dedicated bike lane, radical differences between the fastest and slowest vehicles on the road are the most common root cause of accidents that don't involve some form of impairment.
#1, I thought you were talking about traffic jams -- which usually are not caused by accidents, at least not on the surface streets where bicycles are most common, and #2 your assertion is not true anyway. Overtaking accidents are rare (you can look it up), and the place where they are most common (last time I checked the stats) was in rural areas.
For example, see http://www.metroplanorlando.com/site/upload/documents/Bicyclist_Crash_Study_OrlandoArea.pdf , page 10. Out of 17 fatalities in the study, only one was an overtaking accident.
So I don't know what you're getting at. Interesting theory, but not based on facts.
In terms of "it's a car problem", you can get traffic jams with no bicycles at all, just from the sheer density of cars. This indicates to me that traffic jams are not caused by bicycles, and since they are caused by simply cramming too many cars onto one piece of pavement, that moving drivers out of cars and onto bicycles might just help.
I'm sure you know all this already since you comment with such authority, but two good sources of information are Effective Cycling ( byJohn Forester ) and a presentation by John Pucher on cycling in Northern Europe. Pucher is a fan of bike lanes, not because they are necessary to the free flow of auto traffic, but because they make cyclists feel safe enough to ride en masse. Forester is lukewarm on paths and downright anti-lane, but he makes the point rather well (with plenty of numbers) that there is nothing incompatible about bikes and cars on the same road. However, in terms of getting bikes on the road, he views it as a problem of education, which means his approach is doomed. (Step one: ignore your fear of overtaking vehicles. Lots of people never make it to step two.)
What you say is not true anywhere that I have ever lived (FL, TX, CA, MA). Except in business districts (in some states), not one of your assertions is true; cars need to provide a few feet (3 or 4, I think it depends on jurisdiction), it is legal for a bike to pass on the right or the left (and between lanes would be lane-splitting, also apparently legal in CA and MA), and in most cases, riding on the sidewalk, though unwise, is legal. I've only ever seen it banned in business districts (which is pretty common).
Source (for most of it): http://www.massbike.org/bikelaw/statelaws.htm
And http://bikexprt.com/massfacil/laws/drivmanl.htm
And also http://www.bikexprt.com/massfacil/laws/passright.htm .
Interestingly, at the time this was written, Uniform Vehicle Code generally allowed bikes to pass on the right at their own risk, where Massachusetts, technically speaking, only allows it if the car is also moving. This is not the sort of thing that keeps me up late at night worrying; Massachusetts has many quaint laws, which are appropriately (un)enforced (read the first of the two bikexprt pages for amusing details).
We must be misunderstanding each other. I ride my bike to work twice per week, every week (except holidays), 10 miles one way, about 200 miles per month. Snow tires go on once it starts snowing, stay on till we are getting good melting. That's about 4 months, for a little less than 800 miles. Then I take them off, and put on the other tires.
Snow tires are commuter grade Nokians (H106) or Schwalbe (Marathon Winter). No flats, but the studs do eventually get a little rounded and oriented away from the road/ice, so the traction degrades.
So what I'm trying to say is, you ought to be able to bike even when the snow is not melted, if you got some snow tires, and used them only for those months, and your wear was like my wear. With those assumtions, you ought to be able to get about 1200-1600 miles out of them (2000-2500 km). 13km/day, times 20, gives 260km/month, or 8-10 months (roughly), spread over at least two winters, maybe three.
How insurance is funded has a lot to do with this "works" issue. I drive a Honda Civic, near Boston. Fuel-efficient car, in an area (in)famous for its driving, plus a do a significant fraction (40%) of my commuting by bike. I spend about as much on insurance as I do on gasoline. The last time I asked the insurance company for a low-mileage discount (years ago, with a car that I was only driving 1k/year) I was offered at 10% reduction in rate for a 60% reduction in estimated mileage. Pretty much, insurance is a high flat rate, plus a low per-mile cost.
In that world, using the car rarely but more than zero, has a high cost. It might push you to get rid of the car altogether because of the cost, but it's inconvenient.
Switching to a true pay-per-mile system (say, GPS + black boxes) or an approximate pay-per-mile system (gas surcharge, either linked to your insurance company through your credit card, or just run as a state system) rewards you more for not driving, while still allowing the convenience of having a car when you need it (such a change would probably doom ZipCar, but oh well).
Of course, there's also the interesting assertion that the car "works" for anyone. Last I noticed, I live in a nation full of fat people who don't get enough exercise. If that's your norm, the risk from cardiovascular disease of continuing to drive the car to the exclusion of biking and walking, is very high -- much higher than the risk of injury from biking.
I think you missed my point, and I think you are confused about the cause of the traffic jams.
First, I would not normally propose putting bikes on interstates; they're not designed for it, they're not safe, it's not pleasant. Many places, it's technically not legal (as if traffic laws were enforced). There are usually alternative routes.
But, on ordinary roads, on ordinary commutes, if your commute is already frequently impeded by traffic jams, bikes are not going to make it worse. Someone who chooses not to drive because of traffic jams, is another car not in the jam, not in your way. The crucial element in the traffic jam seems to be cars.
Your post also assumes that cars are the norm, and not themselves the case of problems. Notice that, in a car-bike mix, with stopped cars and moving bikes, you (and for that matter, I) call it a "traffic jam". The cars are "traffic", the bikes are something else. How many bikes would there need to be, before we decided that the traffic was flowing well and it was just a car problem? This is similar to the "bikes take the whole lane" gripe I sometimes hear. The car stuck behind the bike needs "the whole lane", and the bike just happens to be taking a fraction of it that the car needs. If the car were smaller (a Smart Car, e.g.) or a scooter, or another bicycle, it would not be impeded by a single bicycle in front of it in a 10-foot lane. It's a car problem, not a bike problem.
Bikes. Flow through traffic jams like water, no subsidies, no parking fees, they don't tear up the roads.
The only problem is that biking turns you into a total asshole anytime starts a discussion of commuting :-).
That employer parking costs someone money, and if employees weren't using it for cars, your employer could make some other use of it, lease it out to someone else, put a building on it or offices in it.
Mandated underground parking is a tax on business; why not expose the cost of parking, and let people make their own decisions?
A dinky commute like that, I think you could make a pair of snow tires last 3 years. I get 2 years out of mine.
You need a scarier bike.
There was a Gary Larson cartoon, "Nature's way of saying, 'Beware!' " That's your model.
And CDs will never sound as real as vinyl....
Or drive much smaller vehicles.
A cargo bike plus an electric assist will carry a load of groceries and/or a kid or two, and will do it with a daily range that is depressingly competitive with a lot of the e-cars being discussed nowadays (i.e., 40 miles -- 20 in a day on a human-powered cargo bike is a no-brainer). Wouldn't necessarily work in the boonies, but lots and lots of people drive in places that where 20-40 miles per day, most days, is enough.
One hopes that I won't hear the same tired excuses about rain, snow, dark, ice, and locusts; you're not supposed to bike naked (NSFW). That's why we have fenders, raincoats, gloves, and snow tires. What mostly lacks is a place that feels safe enough to ride; what we have now probably IS safe enough, but it seems unsafe, so that's the end of it for most people.
Or maybe the problem is that you think bicycles are slow.
Or maybe you think you'll miss taking your SUV off-roading.
Would you like them enough to buy 20 acres of them? That might get you a price closer to $1/watt.
My misake -- they have a biggish office in Marlborough, Mass.
ATI was Mass based until AMD bought them. Akamai is in Cambridge. I'm sure I'll think of others in a while.
Google has a branch office in Cambridge.
Oracle and Microsoft also have branch offices out here.
But yes, overall non-competes are a total crock.
I ended up with the LM258 because it fit my application -- controlling BuckPuck output on a hub dynamo-driven bike light. It needs to be making sense of its inputs with as little as 7.5 volts of power (when the LEDs begin to light) and not catch fire till 32V. But boy howdy, I used a bunch of LM324s in a theater lightboard almost 30 years ago.
What's amazing to me is how the op-amps have been improved. I checked out of analog chips for about 25 years, then had occasion to use them. LM258 -- runs on 3 to 32 volts, rail-to-rail inputs and outputs, uses a whole milliamp to run.
Or the LMC6462 -- 3 to 15 volts, rail-to-rail in and out, 50 microamps supply, and an input resistance of 10 TeraOhms.
That's a little surprising, given that Linux is said to be a monolithic OS, not a kernel OS like Minix, and thus should contain lots of stuff that has nothing to do with device drivers or page tables. Are you sure this is not an artifact of by-hand inlining for efficiency? In other systems I've worked on or looked at, the truly "unsafe" stuff is quite small and confined to a few smallish modules -- but either they don't sweat the efficiency of a procedure call, or assume that inlining will make it better (or both).
:-).
http://www.cs.washington.edu/research/projects/spin/www/
SPIN says "most" of their code was written in the safe subset of Modula-3. They don't give an explicit line count, so I am guessing that means 49% was unsafe
Singularity reports 90% in (safe) Sing#, about half of the unsafe code is the garbage collector. http://research.microsoft.com/apps/pubs/default.aspx?id=69431
I suspect very much that the number you report is an artifact of working in a language that is by default unsafe; there's no disincentive to sticking little unsafe bits of code here and there, so programmers do, and the result is a large volume of "unsafe" functions where you ought to just have a few unsafe functions that are frequently called. For example, Java "floatToIntBits" is a safe operation, but it has an unsafe implementation (it has a loophole, which can be used in an unsafe way). If you call the method, the calling code is safe, but if you inline it by hand, then it contains an unchecked cast, which is not known to be safe without further examination of the code.
Note that Singularity, SPIN, and Cedar all take a strategic approach to efficiency; by leveraging type safety, they can avoid the costs of a user/kernel context switch and constant rechecking of user inputs. The SPIN guys, long ago, reported great performance results from doing what in Linux would be the equivalent of putting the http server in the kernel. I've worked on Java systems that were designed in much the same way -- rather than invoking "native" code (which can be surprisingly costly, depend on GC and thread details) just drop into the "unsafe" implementation extension.
The actual rules for enforcing safety in language like Modula-3 or Cedar are simple, easy to understand, and not too hard to get right. That's not rocket science. Concurrent parallel realtime garbage collection -- that's rocket science, but if your application demands higher levels of assurance, you either work very hard at verifying and proving the GC, or else you use a less sexy algorithm (e.g., original Baker-style read barriers, or plain old stop-N-copy) and add more memory.
There have been quite a few "safe" languages (e.g., Java) that also had an unsafe extension that allowed you to code the icky bits when you needed to. The first language I know of to be explicitly structured like that was Cedar Mesa at Xerox PARC, then some PARC refugees at DEC-SRC and Acorn Research developed Modula-2+, and from that Modula-3. You can see the ideas now in C#, with "managed" and "unmanaged" code. There have been at least three the-Java-TM-Programming-Language-ish systems that included this as part of their implementation techniques, though they did not expose it to end users. A colleague who once worked at Curl reports that they had something similar there.
The idea is to only enable the unsafe stuff when it is truly necessary (and probably, to have code reviews where the default answer to any unsafe code is to reject it unless it can be justified). If you need to peek and poke device registers, you can do it, but by default, your code is safe and immune to buffer overflows. On a percentage basis, very little of a kernel is actually talking to bare metal; most of it is talking about talking to the bare metal.
The biggest problem I have seen with unsafe extensions is when ex-C -programmers, in their usual pursuit of premature optimization, immediately turn on the unsafe bit and start spraying bugs all over the place. The ex-Curl colleague reports a similar experience. (And the easiest way to get a confirmed negative opinion of C programmers, is to watch them do this.)
how much, how much, how much?
There's this thing called the internet, you can answer these questions for yourself. Otherwise, you're just concern trolling.
There's about 20 countries with universal healthcare and better health outcomes than ours. That's one heck of a pattern.