[FoRK] Robotic cars, software / Internet in cars, and Linux Ksplice, was: Re: > Re: The future of politics. Can, politicians prepare society for the major technology challenges ahead?, With Darren Reynolds.

Stephen D. Williams sdw at lig.net
Thu Feb 11 14:55:48 PST 2010


Marty Halvorson wrote:
> --- On Tue, 2/9/10, Stephen Williams <sdw at lig.net> wrote:
> >
> > We already have perfected, to a basic but workable extent,
> > UAV and in-traffic driving automation capabilities.?
>
> That may be true.  But recent Toyota troubles with drive and stop by 
> wire are an indication that not all is well on auto automation.

Toyota continues to insist that it is all about floor mats wedging a 
poorly-designed accelerator.  Some of the people who have experienced 
the problem don't believe it.  Floor mats seem to be a verified problem, 
but there could be another race/failure condition lurking.  They need 
black-box-like telemetry...

Odd that people don't think of shifting into neutral and shutting off 
the engine, or at least driving into the back of a vehicle going the 
same direction to get some non-fatal resistance.  Especially the cop.

The Prius brake issue _is_ software related.  I was just saying to 
(other) friends recently that A) in the next cycle or two every vehicle 
will have a wireless Internet connection (for a variety of uses) and B) 
(highly verified) software upgrades will just download when the vehicle 
is off.  Even with current economics, the car companies are stupid for 
not having had the forethought to make an Amazon Kindle-like deal with 
Sprint/Verizon for that kind of thing.  Easy to bury the costs in an 
already-expensive sector, lots of up sell possibilities, and one severe 
recall and everyone easily comes out ahead.

Considering that I'm typing this at 37K feet over NE Kansas via WiFi, 
I'd say that having an Internet connection anywhere is solved 
technically.  Car companies have no excuse.  Oops, now I"m in Missouri.

Of course, if car companies had wireless Internet (On Star et al), 
they'd charge a huge premium for it.  If they even thought of it, they 
probably evaluated whether consumers would buy into fat mega-loaded 
pricing rather than Amazon/Google style economy of scale pricing.  Even 
Apple, which charges a premium to some extent, gives a reasonable deal 
considering the range of features with high design / quality.

No vision.  Car companies: You suck.

In any case, robotics will be the answer soon.  The current car 
companies are just too timid to go beyond marginal uses of computers.

Talking about updating on the fly, have you guys seen or tried Ksplice?  
Freaking awesome.  I'll pay $3.95/mo. for that!  (My Linux sever has 
been up for 191 days, since I last upgraded it.  Basically, I just 
reboot it when the fans or hard drives die.)  Something Windows will 
never have (until it is finally, 20 years too late, Linux Windows).
http://en.wikipedia.org/wiki/Ksplice
> Ksplice is a free and open source extension of the Linux kernel which 
> allows system administrators to apply security patches to a running 
> kernel without having to reboot the operating system. Ksplice has been 
> implemented for Linux on the x86-32 and x86-64 architectures. It is 
> currently being developed by Ksplice, Inc.
> Design
>
> Ksplice can apply patches to the Linux kernel without rebooting the 
> computer. Ksplice takes as input a unified diff and the original 
> kernel source code, and it updates the running kernel in memory. Using 
> Ksplice does not require any preparation before the system is 
> originally booted (the running kernel does not need to have been 
> specially compiled, for example). In order to generate an update, 
> Ksplice must determine what code within the kernel has been changed by 
> the source code patch. Ksplice performs this analysis at the ELF 
> object code layer, rather than at the C source code layer.
>
> To apply a patch, Ksplice first freezes execution of a computer so it 
> is the only program running. The system verifies that no processors 
> were in the middle of executing functions that will be modified by the 
> patch. Ksplice modifies the beginning of changed functions so that 
> they instead point to new, updated versions of those functions, and 
> modifies data and structures in memory that need to be changed. 
> Finally, Ksplice resumes each processor running where it left off.
>
> To be fully automatic, Ksplice's design was originally limited to 
> patches that did not introduce semantic changes to data structures, 
> since most Linux kernel security patches do not make these kinds of 
> changes. An evaluation against Linux kernel security patches from May 
> 2005 to May 2008 found that Ksplice was able to apply 100% of the 64 
> significant kernel vulnerabilities discovered in that interval. For 
> patches that do introduce semantic changes to data structures, Ksplice 
> requires a programmer to write a short amount of additional code to 
> help apply the patch. This was necessary for 12% of the updates in 
> that time period.[1].

Catch that?  Kernel developers are adding code to their patches / 
packages that translate in-memory data structures to the new format so 
that the new code can start running with existing data.  All by 
preempting (at a stopping point) and doing arbitrary surgery on a 
running kernel!  I've unloaded kernel modules to upgrade to one that I'd 
just hacked, but this is getting so far from 
reboot-Windows-to-change-IP-address like madness (laziness) as to be in 
magic land.

sdw
>
> Peace
> Marty Halvorson
>



More information about the FoRK mailing list