Ok, so honestly - who on here didn't see this coming? We've only had the DARPA autonomous vehicle challenge won the last two years - both off-road conditions (first year), and urban conditions (this year). It's just a matter of reducing the size and costs of the computer systems driving the vehicles, and maturing the technology even more. First company to do so will likely be handsomely rewarded.
I had even said in the last couple weeks that I didn't expect to have to teach my kids (if my wife & I have any) to drive as the autonomous vehicular technology is maturing fast enough that I fully expect there to be driverless vehicles available to the average citizen by then - so that would be within the next 16 years assuming my wife gave birth today. (No, she's not pregnant yet.)
Needless to say, I find GM's timeline very achievable and directly in line with the maturity rate of the autonomous vehicle industry. Hopefully the other supporting industries (GPS, road maps, etc.) will mature equally as well, which shouldn't be a problem.
You can already improve your mileage on the interstate (or autobahn) by using your cruise control.
Watching my gas gauge I've noticed I can due better myself than using the cruise control.
Of course, I've also noticed that 70 MPH does get better MPG than 65 MPH too, and both do better than 55 MPH.
And of course, standards/manuals still get better MPG than automatics.
My point being - computers don't necessarily do too well with getting better fuel economy than people.
It wouldn't race to the next red light, but infuriate you (like I do my passengers) by taking its virtual foot off the virtual gas pedal as soon as the light ahead turned red
No, it'll just infuriate everyone else on the road too that isn't using the auto-driver. Seriously - it's one thing to just let the vehicle coast (i.e. not necessarily braking, but not adding gas either) or letting the engine brake its way down (e.g. no extra gas, down-shifting), but to slow down and then move 20 MPH slower for a half-mile simply to not stop doesn't help anyone, and only annoys everyone else behind you.
It wouldn't pick the route with the most stop signs
Well...it'll likely pick the shortest route - whether their are stop signs, lights, round-abouts, or other means of traffic control. But you won't likely get as annoyed as you wouldn't be (necessarily) driving.
I can easily enough agree with your other points though.
So apparently you have trouble seeing taillights/headlamps?
Considering some cyclists are equipping their bikes with lights that barely meet spec - i.e. LEDs that shine bright but are really small - I can see how they would per cyclists, at least with tail-lights. You probably would too.
At least in Britain, most motorcycle accidents are caused by a car, not by the motorcyclist.
Not a motocyclist (yet!), but from what I understand - it's the same in the U.S. However...
Unfortunately, the news mostly just covers results of the crotch-rocket idiots - such as one in Maryland where the cyclists were doing 100MPH+ on a stretch with lights where regular traffic only moved somewhere between 35 MPH and 55 MPH, light changed (red for the cyclists), and vehicles pulled out and turned left. The cyclists were going fast enough that there was no time for reactions, and the vehicles turning had no warning of them. Needless to say, they plowed right into the back of the vehicles...their bikes didn't survive, and I'm not sure the cyclists did either. I'm sure there are similar stories in Britain too.
Most cyclists are quite cautious and well behaved, and know enough to do better than play by the rules - but also to look out for their own safety since other drivers typically don't.
That said, I've almost hit one a long time back while merging. Didn't see him in the mirrors at all - must have been in my blind spot, but I think he was trailing another car closer than he should have too. Needless to say, I heard his horn and we both reacted well enough to ensure his safety.
It's not necessarily a matter of other drivers intending to not see them - it's just more difficult due to their size ratio compared to other vehicles, and their maneuverability as cyclists tend to move quickly between positions at time. I do my bets to keep track, and hate it when I loose track, of them - but it happens. (Of course, it drives me nuts when I lose track of any vehicle around me, regardless of size. Doesn't happen much though, and almost always is because behind me turned and I didn't expect it.)
Enough ranting...your point is valid in the U.S. too, but public perception is now skewed about it.
Maybe things are different in the US. I don't know of a major Canadian university that doesn't have a software engineering department, in the faculty of engineering where it belongs. Here, the CS department is actually IN the math building. Some of the courses are shared between eng and CS, but the programs are completely distinct.
Things are quite different in the U.S. Even the "Ivy League" schools barely recognize Software Engineering as its own discipline, AFAIK Carnegie Mellon is the only one. Glad to hear its different in Canada.
I don't think it's unrealistic to look 20 years out. In the last twenty we haven't really had any big SCIENCE changes. Lots of engineering ones, but not really any science ones. No, the CS people won't be able to predict what things are going to look like in twenty years, but they are working on things now that will determine what computing and IT looks like in the future, certainly beyond five years.
Only reason I really say 5 years is that we really need to bring better discipline to the field first. Then things will become more predictable too - or at least easier to do so. Unfortunately, a lot of the people in the computer industry in the U.S. (and I've seen a lot of this on slashdot, with the exception of this article and its comments) refuse to really follow a discipline when it comes to programming unless their industry (e.g. robots, avionics) forces them to for other reasons - and then, they usually came out of Electrical Engineering instead of CS.
So yes, they are doing things that will determine the future - but that future could come faster and be more predictable with better discipline. Some in industry are fighting for it, only to have the people in the project chains reject it. I'm on one project now where part of the team refuses to use the tools to manage requirements - which the people above them are using. It drives me nuts. (They end up writing every document from scratch! And doing all the trace-abilities by hand! And it only drives them off schedule that much more.)
Computer science isn't about going out and doing stuff that "the industry" wants today. It's about figuring out how to do what the industry is going to be wanting twenty years from now. Or forty. Or a hundred.
I think its a bit of a stretch at this point to say CS is about what the industry is going to want 20/40/100 years from now. We can barely see what's coming 5 years from now. CS has its place - namely to produce more CS, not S/w Engineers - but programming/development/etc. has outgrown CS. It's been likened to me before of the physicist vs. the engineer; and we really need to start setting up real engineering around software creation instead of this bastardization we call CS.
Yes, there are probably WAY too many people in computer science. They need to all be booted over to software engineering where they belong.
Sadly though, there are probably less than 20 college/universities even offering a real software engineering program, while there are hundreds or thousands offering computer science. Additionally, try convincing the profs of those CS dept.'s that they need a separate software engineering program/department. That's where part of the problem lies.
Honestly - I agree. The first course CS/SE students should take should be something like Engineering 101 where you get a taste of the different kinds of engineering and a basic foundation that equally applies so as to guide you to the right one. But first we have to have Software Engineering Departments at more than a mere handful of academic institutions.
I know I'll get flamed for saying it, but this is exactly the sort of problem that a TPM can solve.
No, TPM was designed to solve the problem of Microsoft losing Windows as a monopoly by preventing you from installing anything else.
The solution to this problem is correct usages of the Admin (root) accounts, which Unix/Linux has had solved for more than a decade; but according to TFA Microsoft has yet to solve. This, of course, Microsoft's fault.
So please, don't try use use TPM to solve this. It won't. If I bet (but I don't), I'd bet you could even get Windows on a TPM machine to overwrite the MBR in the same manner as the article is mentioning. TPM won't solve the job that the OS is meant to - other than to deny you from running that OS, which is its real purpose.;-) Too bad Microsoft is the entity behind TPM; otherwise we might be able to use TPM to move everyone off of Windows.;-)
I list them because they hold a lot of wisdom, and wanted to draw special attention to them for such as well.
When I was in college I got really ticked at the level of theory - there was too much of it. It wasn't balanced well enough with implementation; and as I looked around, I noticed that was pretty common place among academic institutions (colleges AND universities - and I'm not talking about trade schools either). That was before they moved their curriculum to using Java for the first couple classes; and after they did, I had already heard some stories about the upper classes getting some of these "new" students and not being able to focus on the class materials because they had to teach these students C/C++ first and the students had a harder time getting it. (Not so the other way around.)
That said, I've started thinking about how I would put together a curriculum for teaching computer programming/science/engineering. (I'm not talking about computer _hardware_ engineering, btw.) I even did some tutoring after college. So what would I do?
I'd start students with a language that can be used to teach the real basic skills and concepts (variables, functions, etc.) - even vbscript could be used at this level; but I'd also quickly move them on to more advanced concepts (in the case of vbscript, it would only be used for a couple weeks at most), moving from language to language to bring not only a depth of concepts and understanding, but also a breadth of computer languages and kinds of tasks. I'd also ensure that somewhere in the curriculum students would be exposed to Assembly, and have found that even a small exposure makes a big difference in programming styles and philosophies for programmers.
Furthermore, I'd break the curriculum into two parts. One part would start from the ground up; and the other would start from the top down. Both would be required of students. The idea being one part would be more focused on the theoretical, while the other would be more focused on the substantial - implementation. Both would work together to produce a well-rounded student. Additionally, it would be designed such that students that wanted to work on operating systems would simply follow the one from start to end; while other students would be able to leave for more focused courses at the layer of their choice. (Students wanting OS would still have other courses for focus work too, btw.) The primary idea being that even a web-app developer needs to know the underlying systems, and even the OS developer needs to understand the abstractions of the web-app developer.
I'd also have the overall curriculum be far more software engineering focused. Yes, if people want to really be computer "scientists", then they could do that; but industry really needs software engineers, not computer scientists. Real programs require engineers, and sadly, this is strongly lacking from most all academic computer programs. (Some have changed it, but not many.)
I'd also think that this approach would be very favorable to the authors of TFA and the comments I've linked. The ideas probably need a bit more refinement, but the general approach would be sound - and it's not what academia is doing today by any stretch of the imagination.
FWIW - While I am relatively young (college grad of 2003), my main strength is C prog
I think this is primarily because the schools started/are pushing Java so much that they can only get Java programmers to fill entry level positions. It's sad, but that's the reality. Push something else, and the industry will demand something else.
Personally, I'd recommend teaching real programming, and let the industry figure out what it wants. But I'll cover that in another post.
Back when I was in High School I got the starter set to learning Visual Basic 5 that Microsoft Press put out. It came with two books, one was more thorough on Visual Basic, but the other (the title of which escapes me at the moment) went into all the controls and GUI elements, etc. And (while most here would not like this) I would use Visual Basic as a tool to teach GUI design and focus on content like that book had - which, btw, went into accelerator keys, how controls relate, and more. (I'd use VB only because you can ignore most of the rest of the program and focus on GUIs alone; I'd use and recommend other languages for all other aspects of programming.)
So you're basically saying that science has no business trying to figure out what goes on with dream content, which is silly. You make do with what capabilities you have, however limited. As my freshmen physics professor said, "There's no such thing as an exact science."
Yes, and no. It's bad science to try to draw conclusions from data you do not have, which is what this guy basically did since he did not have the actual dream content or any ability to truly say what the dream content was.
Yes, you make do with what you have, and you push as far as it allows. This is going beyond that, and such should be taken for the grain of salt that it is, if it is even that.
BTW, this is also the kind of thing that people and a lot of scientists criticize Intelligent Design for. Not necessarily supporting Intelligent Design, but it goes both ways.
Too bad it's bad science - unless someone invented one of those dream viewer things that you put on someone to get a visual representation of exactly what they were dreaming...otherwise...there really is no way to know, and taking guesses at what someone is dreaming about or why is just plain stupid to do. Please inform me when we get real science here.
Strict C? do you perhaps mean ISO C? Offically the following code is not valid: "struct foot_t{...};/* other stuff */ foo_t myfoo;" but that is because the valid code is "struct foo_t{...};/* other stuff */ struct foo_t myfoo;". However, because many people do not like the requirement to include the struct keyword all the time, they simply typedef the struct, often times never give the struct a name, resulting in an anonymous struct.
As I said, with compilers such as Microsoft VS 2005 C compiler, that does not necessarily work very well. It wants the typedef there even for the initial struct declaration:
typedef struct foot {...};
The best solution though is to go "struct foo_t {...} foo_t;". That allows "foo_t myfoo" to work, but "struct foo_t myfoo" still works fine too. Further should still be possible to forward declare this struct. Please note that this solution is valid C and C++. One word of warning though: do not do a "typedef struct foo_t foo_t;" after the forward declaration. That would work, except that the real declaration of the struct includes the same typedef, and while C++ allows duplicate typedefs, C does not.
I am fully aware of the practice of typedef'ing shortcut names. I am still talking about the original struct declaration. I typically don't like mixing the two for clarity purposes.
Colour me confused about the Microsoft headers. Is there some docs about this? I'm curious because I am suspecting something is wonky with my include files and maybe you are describing the problem.
If you are getting it to compile, then you are past the issue.
Otherwise, you can simply include Windows.h, or you can be more minimalist (like I like to be), and figure out the individual files to include, which will actually be better for your program. If I remember correctly, you have to start with WTypes.h, which is the basic Windows types (HANDLE, etc.). It's a pain to figure out but works wonderfully once you've done it. It also requires a bit of research whenever you add a new Microsoft header/API/data type/etc. It's been a while since I've done it, and I don't have a project I can pull from readily available to give you better info.
Don't forget about header include guarding - as mentioned by this comment, for example. One of the reasons I really hate using Microsoft's headers - they don't do include guards so the order of the includes matters; they use the #pragma once guard, which is not really a guard as you then have to get the order right, and God help you if you have to include your header before another header that ends up creating a circular loop due to the #pragma once guards.
Lack of structure tags, preventing forward declaration. Don't do typedef struct {... } foo_t; do struct foo_t { }; and a typedef if necessary.
Well...except that when working with Strict C and a compiler such as Microsoft's VS 2005 C compiler, you have to typedef the struct. Annoying but required or else you get all kinds of errors. Been there. Done that. And technically for Strict C, you should be. In C++, however, you are right, but why break the backwards compatibility?
Also, don't forget lack of comments in general either.
The next time you're in a car accident, you probably won't consider that it's government regulations that mandated crumple zones, seat belts, air bags, and other innovations that saved your life.
Actually, airbags, seat belts, and the likes were initially initiatives by the car companies that became so common place that the government then mandated as a safety aspect after the they were out by a majority of manufacturers.
For instance, in 1994 it was common to have dual airbags; by 1998 it was common to see side-airbags too. Now it seems as if its required. You can get more info on Airbags at WikiPedia, which seems pretty accurate from other news sources I've seen in the past.
That doesn't mean that the gov't regulation since hasn't been good, but it's not a good analogy to use the car industry for regulation - most car companies are proactive when it comes to safety. Where the car industry fails is on recalls of defects, and gov't regulation there helps as then they pay out more than just the lawsuits, which sad to say has been required to make them do some recalls. (E.g. the early Ford Mustangs had problems with their gas tanks exploding on impact...so did the Pinto.)
I'm a little confused by your projections since I don't understand why the Boxster went up to $70,000 and fuel went down to $15,000, or why the Mazda3 went to $52,500 and the price down to $11,500? I think you or I might have mixed up some figures. But if the Mazda3 is $18,000 and we're spending $2,300 a year on fuel, if it lasts 15 years we are here:
Mazda3 (new) $18,000 + regular maintenance not included, probably more than Tesla + $2,300 x 15 = 52,500 or $3,500 a year.
In other words, a used Tesla over 15 years might actually cost less than a Mazda3, if Tesla maintenance costs can be kept under control. If gas prices went up it might wind up being cheaper, even substantially cheaper, to run the used Tesla once they become available.
Not sure why...the first number is the cost to date - e.g. the 10 year is initial buy, while 15 and beyond are the cost from the previous cost. The second number is the gas/electricity costs for the period - e.g. 10 year initial, and then 5 year increments thereafter. The first set is the initial; the others are incremental from it. Regular maintenance was left out; overall that part should be able the same - maintenance costs for a combustion engine (e.g. oil, oil filter, coolant, etc.) and the difference of maintaining batteries should roughly equate, or go in favor of the batteries. Any how...that's how it was figured.
I began noticing this with Windows 95. The bastards said it would run in 4MB of memory. Technically it would, if you only ever wanted to start it up.
Hmm...brings back memories of trying to install Win95 on a 386 with 4 MB of RAM. Sadly, it doesn't work to install - you have to have 8 MB to install it. I had a system that we had to borrow memory from another system to get it up to 8 MB to do the install; and then return the memory to the other system. Win95 ran fine on the system. The system was used primarily by students of a programming class - we used Borland's TurboPascal 7.0 and TurboC++ 4.5, as well as the built-in Qbasic at the time. The systems were all upgraded later - new hardware and WinNT4, and the Microsoft VS replaced TP,TC, and QB.
In fact, I got a kick out of that system - we could run Win95 + IE showing a webpage where javascript scrolled some text in the status bar, and a couple other tasks; meanwhile the Mac (MacOS 7.5 I think) with more RAM couldn't run Netscape Navigator (4.7, I think) showing the same page alone - it would crash the Mac. About the only time I knew Windows to have an advantage over Mac.
Hmm...so it might actually work...supposing you could solve the plasma cooling in an open system in orbit. I was mostly jesting around with ideas...may be it is just too realistic for a jest?;-)
Not sure about your comment about "gravitational lensing", there isn't enough mass to do anything of the sort. The sun barely deflects light as it is. Now using magnetic fields to trap material in space in order to refract light such that you create a lens.... maybe.
Actually, I was thinking about curving light around the "shield" instead of poking holes through it to provide sunlight. Not using the sun to provide gravitional lensing, but creating one. It wouldn't work b/c it would have to have a stronger gravity than the sun, thus the sun would get sucked into it - as would the rest of the solar system and we'd be in greater trouble.
So, in other words, it's some of the most perfect rock to be used for spacecraft, space elevator cable, space docks (for building and repairs), and numerous other stuff that requires high strength metals...if we could only figure out how to mine it, return it to earth orbit for processing and use, and also figure out how to process it.
Suppose they create some kind of shield between Venus and the sun, for instance with a swarm of thin foil satellites. The surface temperature would fall down to bearable levels, perhaps to the point of solidifying the CO2, which would make the atmospheric pressure fall. But even assuming that kind of technology, I see no way to get Venus rotating close to the Earth and Mars rates of about 24 hours.
Hmm...well...perhaps two birds with one stone?
That is...suppose you create a large shield as you say. Problem is, it would have to cool somehow due to the temperature from the sun. So, perhaps you make it a large array of smaller shields - when one gets too hot, it rotates so that its hot side is now facing away from the sun, and then a cool side is presented. You could then use this to control day-light by controlling how much light is allowed through.
Of course, you could also do it with plasma cooling to suck the heat away...but that wouldn't be any fun. (Water cooling just wouldn't be effective enough.) Of course, that would be one freaking large heat sink...you could still get the two birds by having some kind of panel system that could allow some light through too.
Or may be we just turn it into a big magnet too and use some gravitational lensing...then again, that might eat the sun up.
All the example of the Roman general proves is that it's not a good idea to make predictions, especially about the future. Sure, the Roman general would probably have laughed at you if you told him about a time, two thousand years in the future, where people would...worship a crucified Jew.
Just a slight correction - there were Roman generals that would have certainly believed that part...especially given
this Roman Centurion. Though, there were also a few Caesars too (can't remember which off hand). So that was definitely believable.
Actually, road trips are usually made with your kids and spouse, so you could have one family member own a large vehicle and the other own an electric and still be perfectly cost effective as long as the electric was not prohibitively expensive.
All depends on age range. Sure, that would be the normal case for a family. However, there are a lot of people at college age that would make long distances too on a regular basis. There are also a lot of people in their 20's and early 30's that do not have family that travel a quite a bit too. There are also a lot of elderly that travel a lot. So, it is hard to say that that would be the norm, or that it would even be cost effective for all the various age groups.
Of course, you also have to think about all the different jobs that people travel for (e.g. real-estate, painting, newspaper delivery, journalism, etc.) that do not require SUV type vehicles - they may still at times travel a couple hundred miles a day easily.
So, true - for a family that can afford to have two cars (for example, my parents couldn't at one point - so my mom got up, took my dad to work, and then returned home so she could take us to school and do her errands, etc.) it may be possible to do just that. Just remember - not everyone is so lucky, nor may it necessarily be possible even for those that do have two vehicles.
Incidentally, if you look at the advertised specs of the Tesla, it's quite a bit cheaper to run than gas cars because the electric drivetrain is super-efficient. If we take the Tesla's claim of 150mpg equivalent, and compare that to a typical Porsche at 20mpg equivalent, we find that the gas car gets about $ 0.15 per mile (at 20mpg) while the electric gets $ 0.02 per mile (assuming $3 a gallon gas). If we drive 20,000 miles a year, Porsche costs $ 3,000 and Tesla costs $ 400 per year. Over a 200,000 mile lifespan, Porsche will cost $30,000 and Tesla $4,000. So the costs are interesting:
Porsche Boxster - $40,000 + $30,000 = $70,000
Tesla = $90,000 + $4,000 = $94,000
So if you look at the pure costs Tesla costs 225% of the Boxster, but over its lifespan it will cost you only about 34% more.
That's assuming a 10 years life span - most that try not to replace vehicles often try to push out 15 years, sometimes even 20 years. The Porsche will definitely outlast that. True - it may cost another $10k to replace the batteries every 10 years - which is probably good to leave as part of the mechanical up keep (not listed in your pricing due to simplicity), but then again - by then batteries should be cheaper. So, it's probably more like this:
I put the Mazda3 in to compare to a commuter vehicle, and assumed its lower gas milage of 26 mpg - I typically get 32 mpg on the highway though. (20k miles/26mpg * $3/g ~= $2,300 per year.)
I suspect you represent only about 1% of drivers, though, and the gasoline system isn't going to go away overnight, so you can still buy what you need. If the USA could even go 50% electric, it would be a huge achievement and do a world of good to us. We're not (hopefully!) trying to force anyone into a means of transport that doesn't suit their needs.
At that time, probably. But there are a lot of college students that do that kind of traveling for holidays as well as the beginning and end of the school year. So it may be a bit higher - I'd gander between 1% and 3%. You'd have to get a census that related college students to colleges and home locations to really see.
But I never said it'd happen overnight - just that the economics would be there to support doing it. Some parts of the U.S. might have trouble due to infrastructure (thinking mostly of the western United States and areas of Alaska), but most of the U.S. at least should be good.
Presently, my commute is 48 miles one way, so even a 150 miles per charge and a 1/2 hour recharge would do me fine - for a commuter car alone, but then we'd still have to have another vehicle for people/kids/distances so it's not necessarily economically viable.
Aptera
https://aptera.com/
All-electric version is $27,000, range of 120 miles, top speed of 95. This would be your around-town model.
Electric/gas hybrid is $30,000. Electric drive with a tiny combustion engine to charge the batteries. Unlimited range.
Cool. So is the Chevy Volt hybrid that is suppose to be released in 2010 - same basic design as the electric drive w/ gas assist.
If Aptera really wants to make it as a company though, they'll have to get the prices down to the same as a commuter car ($15k to $22k). Should be pretty doable in the next couple years. Once they're there, then they'll be fully competing with commuter cars, and could storm the market. I'd buy/reserve one myself if I had the spare $$.
Slashdot Mirror
Ok, so honestly - who on here didn't see this coming? We've only had the DARPA autonomous vehicle challenge won the last two years - both off-road conditions (first year), and urban conditions (this year). It's just a matter of reducing the size and costs of the computer systems driving the vehicles, and maturing the technology even more. First company to do so will likely be handsomely rewarded.
I had even said in the last couple weeks that I didn't expect to have to teach my kids (if my wife & I have any) to drive as the autonomous vehicular technology is maturing fast enough that I fully expect there to be driverless vehicles available to the average citizen by then - so that would be within the next 16 years assuming my wife gave birth today. (No, she's not pregnant yet.)
Needless to say, I find GM's timeline very achievable and directly in line with the maturity rate of the autonomous vehicle industry. Hopefully the other supporting industries (GPS, road maps, etc.) will mature equally as well, which shouldn't be a problem.
Of course, I've also noticed that 70 MPH does get better MPG than 65 MPH too, and both do better than 55 MPH.
And of course, standards/manuals still get better MPG than automatics.
My point being - computers don't necessarily do too well with getting better fuel economy than people.
No, it'll just infuriate everyone else on the road too that isn't using the auto-driver. Seriously - it's one thing to just let the vehicle coast (i.e. not necessarily braking, but not adding gas either) or letting the engine brake its way down (e.g. no extra gas, down-shifting), but to slow down and then move 20 MPH slower for a half-mile simply to not stop doesn't help anyone, and only annoys everyone else behind you. Well...it'll likely pick the shortest route - whether their are stop signs, lights, round-abouts, or other means of traffic control. But you won't likely get as annoyed as you wouldn't be (necessarily) driving.
I can easily enough agree with your other points though.
Unfortunately, the news mostly just covers results of the crotch-rocket idiots - such as one in Maryland where the cyclists were doing 100MPH+ on a stretch with lights where regular traffic only moved somewhere between 35 MPH and 55 MPH, light changed (red for the cyclists), and vehicles pulled out and turned left. The cyclists were going fast enough that there was no time for reactions, and the vehicles turning had no warning of them. Needless to say, they plowed right into the back of the vehicles...their bikes didn't survive, and I'm not sure the cyclists did either. I'm sure there are similar stories in Britain too.
Most cyclists are quite cautious and well behaved, and know enough to do better than play by the rules - but also to look out for their own safety since other drivers typically don't.
That said, I've almost hit one a long time back while merging. Didn't see him in the mirrors at all - must have been in my blind spot, but I think he was trailing another car closer than he should have too. Needless to say, I heard his horn and we both reacted well enough to ensure his safety.
It's not necessarily a matter of other drivers intending to not see them - it's just more difficult due to their size ratio compared to other vehicles, and their maneuverability as cyclists tend to move quickly between positions at time. I do my bets to keep track, and hate it when I loose track, of them - but it happens. (Of course, it drives me nuts when I lose track of any vehicle around me, regardless of size. Doesn't happen much though, and almost always is because behind me turned and I didn't expect it.)
Enough ranting...your point is valid in the U.S. too, but public perception is now skewed about it.
So yes, they are doing things that will determine the future - but that future could come faster and be more predictable with better discipline. Some in industry are fighting for it, only to have the people in the project chains reject it. I'm on one project now where part of the team refuses to use the tools to manage requirements - which the people above them are using. It drives me nuts. (They end up writing every document from scratch! And doing all the trace-abilities by hand! And it only drives them off schedule that much more.)
Any how...you get my point by now...
Honestly - I agree. The first course CS/SE students should take should be something like Engineering 101 where you get a taste of the different kinds of engineering and a basic foundation that equally applies so as to guide you to the right one. But first we have to have Software Engineering Departments at more than a mere handful of academic institutions.
The solution to this problem is correct usages of the Admin (root) accounts, which Unix/Linux has had solved for more than a decade; but according to TFA Microsoft has yet to solve. This, of course, Microsoft's fault.
So please, don't try use use TPM to solve this. It won't. If I bet (but I don't), I'd bet you could even get Windows on a TPM machine to overwrite the MBR in the same manner as the article is mentioning. TPM won't solve the job that the OS is meant to - other than to deny you from running that OS, which is its real purpose.
First, some of the best comments in this thread: Comment 1 Comment 2 Comment 3 Comment 4 Comment 5 Comment 6
I list them because they hold a lot of wisdom, and wanted to draw special attention to them for such as well.
When I was in college I got really ticked at the level of theory - there was too much of it. It wasn't balanced well enough with implementation; and as I looked around, I noticed that was pretty common place among academic institutions (colleges AND universities - and I'm not talking about trade schools either). That was before they moved their curriculum to using Java for the first couple classes; and after they did, I had already heard some stories about the upper classes getting some of these "new" students and not being able to focus on the class materials because they had to teach these students C/C++ first and the students had a harder time getting it. (Not so the other way around.)
That said, I've started thinking about how I would put together a curriculum for teaching computer programming/science/engineering. (I'm not talking about computer _hardware_ engineering, btw.) I even did some tutoring after college. So what would I do?
I'd start students with a language that can be used to teach the real basic skills and concepts (variables, functions, etc.) - even vbscript could be used at this level; but I'd also quickly move them on to more advanced concepts (in the case of vbscript, it would only be used for a couple weeks at most), moving from language to language to bring not only a depth of concepts and understanding, but also a breadth of computer languages and kinds of tasks. I'd also ensure that somewhere in the curriculum students would be exposed to Assembly, and have found that even a small exposure makes a big difference in programming styles and philosophies for programmers.
Furthermore, I'd break the curriculum into two parts. One part would start from the ground up; and the other would start from the top down. Both would be required of students. The idea being one part would be more focused on the theoretical, while the other would be more focused on the substantial - implementation. Both would work together to produce a well-rounded student. Additionally, it would be designed such that students that wanted to work on operating systems would simply follow the one from start to end; while other students would be able to leave for more focused courses at the layer of their choice. (Students wanting OS would still have other courses for focus work too, btw.) The primary idea being that even a web-app developer needs to know the underlying systems, and even the OS developer needs to understand the abstractions of the web-app developer.
I'd also have the overall curriculum be far more software engineering focused. Yes, if people want to really be computer "scientists", then they could do that; but industry really needs software engineers, not computer scientists. Real programs require engineers, and sadly, this is strongly lacking from most all academic computer programs. (Some have changed it, but not many.)
I'd also think that this approach would be very favorable to the authors of TFA and the comments I've linked. The ideas probably need a bit more refinement, but the general approach would be sound - and it's not what academia is doing today by any stretch of the imagination.
FWIW - While I am relatively young (college grad of 2003), my main strength is C prog
Personally, I'd recommend teaching real programming, and let the industry figure out what it wants. But I'll cover that in another post.
Back when I was in High School I got the starter set to learning Visual Basic 5 that Microsoft Press put out. It came with two books, one was more thorough on Visual Basic, but the other (the title of which escapes me at the moment) went into all the controls and GUI elements, etc. And (while most here would not like this) I would use Visual Basic as a tool to teach GUI design and focus on content like that book had - which, btw, went into accelerator keys, how controls relate, and more. (I'd use VB only because you can ignore most of the rest of the program and focus on GUIs alone; I'd use and recommend other languages for all other aspects of programming.)
Yes, you make do with what you have, and you push as far as it allows. This is going beyond that, and such should be taken for the grain of salt that it is, if it is even that.
BTW, this is also the kind of thing that people and a lot of scientists criticize Intelligent Design for. Not necessarily supporting Intelligent Design, but it goes both ways.
Too bad it's bad science - unless someone invented one of those dream viewer things that you put on someone to get a visual representation of exactly what they were dreaming...otherwise...there really is no way to know, and taking guesses at what someone is dreaming about or why is just plain stupid to do. Please inform me when we get real science here.
Don't forget about header include guarding - as mentioned by this comment, for example. One of the reasons I really hate using Microsoft's headers - they don't do include guards so the order of the includes matters; they use the #pragma once guard, which is not really a guard as you then have to get the order right, and God help you if you have to include your header before another header that ends up creating a circular loop due to the #pragma once guards. Well...except that when working with Strict C and a compiler such as Microsoft's VS 2005 C compiler, you have to typedef the struct. Annoying but required or else you get all kinds of errors. Been there. Done that. And technically for Strict C, you should be. In C++, however, you are right, but why break the backwards compatibility?
Also, don't forget lack of comments in general either.
For instance, in 1994 it was common to have dual airbags; by 1998 it was common to see side-airbags too. Now it seems as if its required. You can get more info on Airbags at WikiPedia, which seems pretty accurate from other news sources I've seen in the past.
That doesn't mean that the gov't regulation since hasn't been good, but it's not a good analogy to use the car industry for regulation - most car companies are proactive when it comes to safety. Where the car industry fails is on recalls of defects, and gov't regulation there helps as then they pay out more than just the lawsuits, which sad to say has been required to make them do some recalls. (E.g. the early Ford Mustangs had problems with their gas tanks exploding on impact...so did the Pinto.)
In fact, I got a kick out of that system - we could run Win95 + IE showing a webpage where javascript scrolled some text in the status bar, and a couple other tasks; meanwhile the Mac (MacOS 7.5 I think) with more RAM couldn't run Netscape Navigator (4.7, I think) showing the same page alone - it would crash the Mac. About the only time I knew Windows to have an advantage over Mac.
That is...suppose you create a large shield as you say. Problem is, it would have to cool somehow due to the temperature from the sun. So, perhaps you make it a large array of smaller shields - when one gets too hot, it rotates so that its hot side is now facing away from the sun, and then a cool side is presented. You could then use this to control day-light by controlling how much light is allowed through.
Of course, you could also do it with plasma cooling to suck the heat away...but that wouldn't be any fun. (Water cooling just wouldn't be effective enough.) Of course, that would be one freaking large heat sink...you could still get the two birds by having some kind of panel system that could allow some light through too.
Or may be we just turn it into a big magnet too and use some gravitational lensing...then again, that might eat the sun up.
However, your basic point stands.
Of course, you also have to think about all the different jobs that people travel for (e.g. real-estate, painting, newspaper delivery, journalism, etc.) that do not require SUV type vehicles - they may still at times travel a couple hundred miles a day easily.
So, true - for a family that can afford to have two cars (for example, my parents couldn't at one point - so my mom got up, took my dad to work, and then returned home so she could take us to school and do her errands, etc.) it may be possible to do just that. Just remember - not everyone is so lucky, nor may it necessarily be possible even for those that do have two vehicles.
That's assuming a 10 years life span - most that try not to replace vehicles often try to push out 15 years, sometimes even 20 years. The Porsche will definitely outlast that. True - it may cost another $10k to replace the batteries every 10 years - which is probably good to leave as part of the mechanical up keep (not listed in your pricing due to simplicity), but then again - by then batteries should be cheaper. So, it's probably more like this:
10 year:
Mazda3 = $18,000 + $23,000 = $41,000
Porsche Boxster = $40,000 + $30,000 = $70,000
Tesla = $90,000 + $4,000 = $94,000
15 year:
Mazda3 = $41,000 + $11,500 = $52,500
Porsche Boxster = $70,000 + $15,000 = $85,000
Tesla = $94,000 + $2,000 = $96,000
20 year:
Mazda3 = $52,500 + $11,500 = $82,000
Porsche Boxster = $85,000 + $15,000 = $100,000
Tesla = $96,000 + $2,000 = $98,000
I put the Mazda3 in to compare to a commuter vehicle, and assumed its lower gas milage of 26 mpg - I typically get 32 mpg on the highway though. (20k miles/26mpg * $3/g ~= $2,300 per year.)
But I never said it'd happen overnight - just that the economics would be there to support doing it. Some parts of the U.S. might have trouble due to infrastructure (thinking mostly of the western United States and areas of Alaska), but most of the U.S. at least should be good.
Presently, my commute is 48 miles one way, so even a 150 miles per charge and a 1/2 hour recharge would do me fine - for a commuter car alone, but then we'd still have to have another vehicle for people/kids/distances so it's not necessarily economically viable.
If Aptera really wants to make it as a company though, they'll have to get the prices down to the same as a commuter car ($15k to $22k). Should be pretty doable in the next couple years. Once they're there, then they'll be fully competing with commuter cars, and could storm the market. I'd buy/reserve one myself if I had the spare $$.