GENIVI: moving an industry to open source

By Michael Kerrisk
August 8, 2012

Given this editor's recent history (3 years working there), an article on the GENIVI Alliance was perhaps inevitable, and perhaps it's better done sooner while the experience is still fresh. However, GENIVI is more than just a matter of personal interest and experience: the development of GENIVI has some interesting lessons on the adoption of free and open source software, and the results of the consortium's work are soon likely to be directly visible to many readers of this article on a daily basis.

Goals and history

The name GENIVI is an acronym based on the name of the Swiss city, Geneva, and "IVI". Geneva holds no special significance to the consortium beyond the fact that it hosted an industry meeting where some early discussions about formation of the consortium took place; the consortium itself is incorporated in the United States as a 501(c)(6) nonprofit organization.

The first question of course is: what is GENIVI? The brief answer is that it is a consortium of companies whose goal is to define a standardized common software platform for developing in-vehicle infotainment (IVI) systems and to nurture a development ecosystem around that platform. IVI systems, known in the trade as head units, are the computer systems commonly found in high-end cars and commercial vehicles—and increasingly in mid-range cars and other vehicles—that provide a range of entertainment and other functions.

Typical IVI functions include control of the media system (e.g., music player, radio, rear-seat video), navigation assistance and location-based services, and display from the rear-view camera on vehicles that provide one. Input to a modern IVI system is via physical wheel devices and buttons or a touch-screen interface, and, commonly, voice recognition. Many modern IVI systems provide integration with consumer-electronics devices via technologies such as Bluetooth and USB. The most interesting such devices are of course smart phones, where integration with the IVI system allows functionality such as playback of media hosted on the phone and hands-free, voice-activated calls conducted via the head-unit audio system. This type of integration also allows conveniences such as automatically turning the volume of the radio down when an incoming caller rings the phone.

The formation of the consortium was announced at the start of 2009, although there is some prehistory to its foundation that we'll briefly return to in a moment. The founding membership consisted of 8 companies that typify several categories of what is by now a much larger membership: automotive manufacturers (BMW Group, PSA Peugeot Citroën, General Motors), tier 1 automotive suppliers (Delphi, Magneti-Marelli, Visteon), Silicon vendors (Intel), and operating system vendors (Wind River Systems, then an independent company, now a subsidiary of Intel). During the subsequent three years, membership in each of the aforementioned categories has swelled (notably, a number of ARM Silicon vendors now balance out the heavyweight Intel among the Silicon vendors). In addition, ISVs (independent software vendors), middleware vendors, and software services companies with an interest in the automotive sector have also joined the consortium, with the result that the GENIVI membership has now grown to over 150 companies spread across Europe, America, and South and East Asia.

Above, I said GENIVI's goal is to define a standardized common software platform. That platform is not a complete IVI system. Rather, it is a packaging of operating system and middleware components that implement a range of non-differentiating functionalities that all IVI systems require. (Bluetooth connectivity is an example of what automotive manufacturers might consider non-differentiating functionality: manufacturers want a working implementation, but don't market their IVI systems to customers based on the Bluetooth implementation.) In effect, one of GENIVI's goals is to decrease the cost of developing the base system, so that developer resources can be devoted to innovating at higher levels in the software stack, such as the human-machine interface.

Linux and open source software were chosen as for the GENIVI software platform during an evaluation project that predated the foundation of the consortium. That project (conducted by BMW, Magneti Marelli, Intel, and Wind River) was motivated by the desire to balance two opposing requirements. On one side stand ever-increasing demands on the development and scope of IVI systems: to drivers, an IVI system starts to look more and more like other consumer electronics devices, and drivers expect to see similar levels of functionality and rapid development cycles. Furthermore, there is a market pressure to see IVI systems in all vehicle categories, rather than just the high end. On the other side, the costs of IVI system development have grown astronomical—a figure of $100 million to bring a solution from the drawing board to dashboard is not unheard of, and such costs are becoming intolerable for all but the largest automotive manufacturers.

In the evaluation phase, a number of platform alternatives were considered, including proprietary systems such as Windows CE and QNX. However, it quickly became clear that a platform based on Linux and free software had the most to offer, based on factors such as the economies available from reuse of software components and, importantly, the realization that free software would allow the greatest degree of control of the content and development of the platform. On that basis, the evaluation project embarked (successfully) on a proof-of-concept implementation of a prototype head-unit system based on Linux and free software components.

GENIVI outputs

In addition to code projects worked on by members, the consortium produces two primary outputs: a compliance specification and a baseline software release.

The goal of the compliance specification is to ensure that compliant GENIVI products ease integration of third-party software components, rather than guaranteeing full API or ABI compatibility across implementations. (In other words, GENIVI doesn't set out to be a standardization body.) Compliance is currently based on self-certification, but in time the plan is move to a more test-driven form of certification. The compliance specification is currently a members-only document.

The GENIVI baseline software release is essentially an internal proof-of-concept for the compliance specification. It is a packaging of the components required by a specific release of the compliance specification on top of a Linux distribution. The baseline isn't directly available outside the GENIVI membership, but is indirectly available via a number of GENIVI respins created by incorporating the baseline component set into an upstream distribution. These respins are created by GENIVI members and available to anyone for download. GENIVI respins are currently created for Ubuntu, Tizen, and Yocto.

What is the problem that GENIVI is trying to solve?

Technically speaking, implementing partial or complete IVI systems on Linux isn't fundamentally different or more difficult than using the platforms traditionally employed in the automotive industry. The pre-GENIVI proof-of-concept work, the recent Cadillac CUE system, and a range of demonstrator systems that appear at the twice-yearly GENIVI member meetings provide ample evidence of that fact. This raises the questions: why don't we already have (more) Linux-based IVI systems on the road and why is an alliance like GENIVI even necessary?

To answer those questions requires understanding that GENIVI's objective is not to solve a software technical problem, but rather to solve a software business problem. Escalating software costs mean that automotive manufacturers need to escape their traditional cycle of constantly reimplementing individually developed, tailor-made solutions for their IVI systems. The name of the game is to share development costs by collaborating on the development of a common, reusable software platform. The challenge then becomes: how does a diverse group of companies transform their traditional business and software development practices, stepping toward a new model to collaboratively define a common platform and bring it to reality? In practice that has proved to be quite a challenge.

The rocky road from prototype to product

To see why the path forward for GENIVI has been difficult requires some understanding of the traditional software development model in the automotive industry.

The traditional approach to IVI software development is rather waterfall in style: the automotive manufacturer develops a set of requirements and then, armed with a large checkbook, enters into a contract with a tier 1 supplier who does all of the software development to fulfill those requirements (in fact, the tier 1 supplier is often tasked with delivering the whole package of IVI hardware and software). Once development is completed, the manufacturer black-box tests the resulting software, and then ships it in vehicle head units. (In this traditional approach, it's worth noting that the manufacturer typically has few software engineers, and does little software development.)

Given their historical role as holders of the checkbooks, it's perhaps unsurprising that automotive manufacturers at first tried to remake GENIVI in the mold that was familiar to them. Thus, in its initial incarnation, although GENIVI's stated goal was to create a (largely) open source platform, the proposed development process was rather waterfall style, driven from the top down by the automotive manufacturers. The proposed process consisted of traditional phases: gathering of requirements, discovering an architecture, mapping the architecture to software components, and then selecting (existing) open source software components, and implementing new components to fill the gaps. Waterfall-style development is prone to be complex and time consuming; what made it even worse in GENIVI's case was trying to the scale the development process to handle multiple participating companies.

For many readers, it is probably no surprise that the results of trying to employ such a model to select and create open source software were not as successful as hoped: internal teams got bogged down in trying to define the process, and the alliance found it too unwieldy to implement in practice. Further complicating the problem was the fact that information was not open equally to all members of the alliance (there were restrictions on access to information such as draft specifications and other in-progress work according to the paid-for level of membership). The consequence of that differential access to information was to further impede participation in the work of the consortium.

What happened in response to the early low participation levels is something of a textbook lesson for any company, or, more particularly, any industry group trying to move to open source. Recognizing the problem, the consortium's Board of Directors implemented some simple but radical steps: membership-based restrictions to information inside the consortium were abolished and the top-down waterfall model described above was replaced by requirements gathering and implementation driven from the bottom, via domain-specific "Expert Groups" that any interested member company was free to participate in. The results of these changes became apparent quite rapidly: the level of mailing-list traffic, wiki activity, scheduled face-to-face meetings, and code contribution all increased dramatically.

Engaging with the open source community

Having read this far, the question you may be left wondering is: is GENIVI open?

From a process perspective, the answer is no. Access to various internal resources such as the wiki, issue tracker, and mailing lists is limited to the (paying) membership. Similarly, attendance at face-to-face meetings is limited to the membership. However, the boundary between members and nonmembers is already somewhat permeable. For example, a number of open source developers with relevant expertise have been invited to GENIVI meetings and provided valuable input—among them Kay Sievers and Lennart Poettering (systemd), Marcel Holtmann (BlueZ, ConnMan, oFono), Samuel Ortiz (ConnMan), and Kristian Hoegsberg (Wayland). In time, it can be expected that the boundary between members and nonmembers may become even more permeable; it's an ongoing process.

From a code perspective, GENIVI is not fully open source, but it's getting steadily closer. As noted above, the GENIVI baseline respins are publicly available, but the repositories of GENIVI-developed code are not (even though the code in those repositories is all under OSI-approved licenses). However, that situation is likely to change quite soon, as moves are afoot to open GENIVI work more widely to the outside world (so that individual GENIVI code projects have open code repositories, bug trackers, and mailing lists). At that point, it's likely that activity on GENIVI will notch up yet further, as outside developers start to take a closer interest in pieces of the code. (It should be noted GENIVI's goal is, as far as possible, to reuse open source software components; new components are developed by GENIVI members only in cases where no suitable free software component can be found. Thus, there are to date relatively few GENIVI code projects, for example, an automotive specific audio manager and a graphics layer management system; the vast majority of the components in the GENIVI respins are direct from the open source ecosystem.)

Looking in the other direction, GENIVI is increasingly participating in upstream projects, with members getting involved via code or conversations in a number of open source projects, such as systemd and ConnMan. In recent times, GENIVI has even been getting involved with kernel development, sponsoring development of kernel patches to improve D-Bus performance. (As noted in an earlier LWN article, the attempt to upstream this work has not so far proved successful. However, D-Bus is viewed as a key component of GENIVI, and it's likely that further work will be done to come up with a kernel solution to improving D-Bus performance that may be acceptable to the maintainer of the Linux networking stack.)

Challenges

There are a number of ongoing challenges for GENIVI, and one or two that remain unresolved. Some of the challenges can be easily guessed at, or can be deduced with a little reflection. For example, as with most open source projects, more contributors would always speed up development.

The process of adapting from closed software development in competition with peers to a model of collaboratively working and sharing ideas (so far, mainly within the membership) is ongoing. For companies that have not previously done so (which includes much of the GENIVI membership), contributing code under open source licenses involves educating both developers and company lawyers. But considering the heavily proprietary origins of automotive software, the progress has already been considerable.

A notable challenge for automotive manufacturers is that, by virtue of being distributors of open source software in their head units, they now need to ensure their engineers and lawyers are well educated about free software licenses. Furthermore, their code management processes need to be adapted to satisfy the obligations of those licenses, in particular, of course, the source code redistribution requirements of the GPL. By and large, the manufacturers seem to understand the challenge and are rising to it.

The GNU GPLv3 remains a so-far unresolved challenge for GENIVI. Already, a small but significant percentage of free software projects use this license, and over time more can be expected to do so. However, automotive manufacturers feel that they can't use software under this license in IVI systems. The problem hinges on the so-called anti-Tivoization clause of the GPLv3. In essence, this clause says that if GPLv3-licensed object code is placed on a computer system, then, either the system must prevent updates to that code by all users (i.e., no one, including the manufacturer, can perform updates) or, if the system does allow updates to the GPLv3-licensed software (e.g., so that the manufacturer can make updates), then the software recipient (i.e., the car driver) must likewise be permitted to update the software. The automotive manufacturers' position is that they need to be able to update the software in an IVI system, but they can't let the driver do so.

The issues for the manufacturers are driver safety, and manufacturer liability and reputation. Even if head-unit systems where fully isolated from the in-vehicle networks that control safety-critical functions such as the braking system (and in most automotive architectures they are not fully isolated), there are features of IVI systems that can be considered safety-impacting. It's easy to see that accidents could result if the navigation system directs the driver in the wrong direction up a one-way street or the picture from the rear-vision camera is delayed by 2 seconds. Consequently, the manufacturers' stance is that the only software that they can permit on the head unit is software that they've tested. Since the GPLv3 would in effect require manufacturers to allow drivers to perform software updates on the head unit, GPLv3-licensed software is currently considered a no-go area. (An oft-proposed resolution to the manufacturers' conundrum is the "solution" that the manufacturer should simply void the warranty if the driver wants to make software updates to the head unit. However, that's not a palatable option: such disclaimers may or may not hold up in court, and they don't protect reputations in the face of newspaper headlines along the lines of "4 killed following navigation failure in well-known manufacturer's car".)

The future

With respect to IVI systems, the future for GENIVI in particular, and Linux in general, looks bright. A number of manufacturers plan to have GENIVI-based head units in production within the next two years. In addition, at least one other Linux-based product (the Cadillac CUE) is already in production, and other Linux-based systems are rumored to be under development. Overall, a substantial body of automotive interest seems to be coalescing around Linux, so it's perhaps no surprise that the Linux Foundation is organizing the second Automotive Linux Summit next month in England. It seems likely that in a few years, we'll be living in a world where Linux in automotive IVI systems is as common as it is in today's consumer electronic devices.

to post comments

GPL v3

Posted Aug 9, 2012 3:01 UTC (Thu) by Richard_J_Neill (subscriber, #23093) [Link] (34 responses)

I'm not really convinced by this as a problem: it should be easy to keep both sides (lawyers and programmers) happy. For example, only updating the software by plugging in a USB key; keeping the USB socket under a cover with some kind of awkward screwdriver (eg pentalobe), and then breaking a paper label that would denote the warranty is void.

i.e. Users should be free to modify their device's software, but with some clear restriction to "experts only, at your own risk" would be a reasonable balance.

As for "(and in most automotive architectures they are not fully isolated)", that sounds to me completely crazy. I don't think that feeding a music player with a malicious file should ever be able, even in theory, to interfere with the brakes!

GPL v3

Posted Aug 9, 2012 3:22 UTC (Thu) by epa (subscriber, #39769) [Link] (1 responses)

I was thinking that the entire computer device would have to be removed from the car to access the USB port, but only authorized dealers have the special tool required to insert the computer back again.

GPL v3

Posted Aug 10, 2012 13:58 UTC (Fri) by ewan (guest, #5533) [Link]

That would then simply be a GPLv3 violation.

GPL v3

Posted Aug 9, 2012 8:40 UTC (Thu) by mkerrisk (subscriber, #1978) [Link] (24 responses)

If we broadly consider the car-with-IVI-system as a consumer device, a car is a consumer device with a distinctive property: it can kill the user (and of course nonusers). As a consequence, lawyers at car companies are extremely cautious: accidents where liability can be demonstrated to lie with the manufacturer can be catastrophic for business. (I think it's enlightening to place oneself in the position of a lawyer at a multibillion dollar car company. Knowing that the decisions you make could fatally affect the business would likely make any of us extremely conservative.) Even cases where, legally speaking, the automotive manufacturer is not at fault, there is still the possibility of damage to reputation, which can likewise be bad for business.

IVI systems are not fully isolated from other networks in the car, since in practice they take information from other parts of the car (e.g., speed, engine diagnostics). In practice, it would probably be extremely difficult to trigger an effect on another network in the car via software on the IVI system. However, lawyers worry (reasonably) that there might be a nonzero chance that this can occur.

As I explained in the article, "modify the IVI system and the warranty is void" approaches are not a solution that keeps lawyers happy.

Automotive manufacturers are not taking this stance on the GPLv3 easily. Deciding not to use GPLv3-licensed software has costs for them. One might wonder if there is a hidden agenda, for example, maintaining control of the device in order to profit from an apps market. While this is possible, I've concluded by now that it's improbable. Some industry studies have shown that drivers in practice spend an extraordinarily small amount of time interacting with IVI devices. Thus, while the market in novel apps for the IVI unit may exist, because the consumer mental bandwidth available for interaction with IVI systems is orders of magnitude smaller than for tablets or smart phones, the apps market seems unlikely to be profitable for automotive manufacturers

GPL v3

Posted Aug 9, 2012 9:31 UTC (Thu) by miahfost (guest, #51602) [Link] (3 responses)

I agree that the App market is not likely to be something that car makers care all that much about. While its likely great to have a bunch of fun driving apps available, the key revenue stream is the purchase of the vehicle with the head unit.

But that does not mean that the entire customer relationship is not worth protecting jealously. For example, certified auto parts are a huge business, as is the automotive aftermarket in general. The OEMs are very interested in blocking third party success in that market and keeping that revenue for themselves.

The OEMs have not been successful so far blocking software updates, there exists software to modify your ECU today. That software is significantly more prone to catastrophic failure because it bypasses things like the air to fuel mixture that the car maker carefully calibrated for safety and efficiency. Good article on this very topic: http://nyti.ms/Nf4Vry

I think allowing car owners to update their IVI systems would be much more appropriate and the argument currently being used by automotive legal eagles may not be particularly persuasive, i.e. blocking the GPL v3 is for safety's sake. I think there are a lot of business considerations that are behind this.

GPL v3

Posted Aug 10, 2012 2:28 UTC (Fri) by dlang (guest, #313) [Link] (2 responses)

> I agree that the App market is not likely to be something that car makers care all that much about.

I disagree with this in the long run.

Think of the money to be made by allowing the kids in the back to install their games, watch movies, and do all the other things that they could do with android apps running on the car IVI system (assuming that the car companies charge some markup for their branded store)

All it will take is one company doing this and all of the sudden, the others will change their tune to cash in on the windfall.

GPL v3

Posted Aug 23, 2012 13:26 UTC (Thu) by miahfost (guest, #51602) [Link] (1 responses)

But this will likely happen on tablets, game consoles, phablets, etc. The RSE (Rear Seat Entertainment unit) is likely only going to show movies and the like, not be a full blown computer.

GPL v3

Posted Aug 24, 2012 2:27 UTC (Fri) by dlang (guest, #313) [Link]

"show movies and the like" now includes doing things like being able to play games.

besides, it's easier to just install a plain android device in the car for this, it handles so many formats, functions, networks, etc without any development effort.

GPL v3

Posted Aug 9, 2012 10:25 UTC (Thu) by NRArnot (subscriber, #3033) [Link] (19 responses)

a car is a consumer device with a distinctive property: it can kill the user

Actually that argument could be applied to a toaster as well. (If the user trusts the firmware and the firmware has a bug that one day causes the toast to catch fire and set fire to the kitchen ....)

I'd suggest going a bit further than merely a "warranty void" sticker that might fall off (or be caused to fall off. WD40 works great :-) Put the device in a case that cannot be opened without cutting through something. Have a program-enable jumper that cannot be set without irreversibly recording that fact in (say) a fusible-link PROM. Surely that would suffice to prove "not our fault" in law.

GPL v3

Posted Aug 10, 2012 8:17 UTC (Fri) by fb (guest, #53265) [Link] (18 responses)

> Actually that argument could be applied to a toaster as well. (If the user trusts the firmware and the firmware has a bug that one day causes the toast to catch fire and set fire to the kitchen ....)

The question is not just whether it 'can' kill the user, but how 'likely' that is. One way to determine that is to ask:

- How often are people killed by toaster accidents?
- How often are people killed by car accidents?

GPL v3

Posted Aug 10, 2012 15:05 UTC (Fri) by dlang (guest, #313) [Link] (3 responses)

do you measure by the number of toasters in use vs the number of cars in use, or by the number of hours that toasters are used vs the number of hours that cars are used?

I suspect that if you measured by the number of hours they are in use, the numbers would be a lot closer than you expect.

GPL v3

Posted Aug 10, 2012 15:24 UTC (Fri) by fb (guest, #53265) [Link] (2 responses)

> do you measure by the number of toasters in use vs the number of cars in use, or by the number of hours that toasters are used vs the number of hours that cars are used?

I honestly measure the totals (as in total # of injured or killed by per year), as that gives the cost of the toast/car safety to society (which are different words for "how likely a citizen to suffer from it").

It amounts to my original question asking how many are killed (or injured) by either per year in total.

(Now for the absurd argument...) Active volcano's are far more dangerous than toasters or cars /per minute/ but since the amount of minutes I get exposed to them is so low, I tend to worry a lot more about cars. (No, I don't have any idea of how we could hack a volcano (sorry)).

GPL v3

Posted Aug 10, 2012 15:38 UTC (Fri) by dlang (guest, #313) [Link] (1 responses)

raw fatality numbers are about the worst possible value to use when comparing two things and how dangerous they are.

to compare the risk you need to evaluate the costs compared to the amount of usage.

or you can do a risk analysis from a cost/benefit point of view, but there you again can't just compare the cost, you would have to quantify the benefits of the particular tool/technology.

Just comparing the resulting costs leads to absurd conclusions.

GPL v3

Posted Aug 10, 2012 15:55 UTC (Fri) by fb (guest, #53265) [Link]

> raw fatality numbers are about the worst possible value to use when comparing two things and how dangerous they are.

Go back and re-read my post.

I am not -in the least- interested in measuring the absolute danger level of something per minute (see the volcano example). I am interested in much danger that is for me, or my family, or my neighbor (I don't worry about volcanos).

The total is already the combination of danger per minute and rate of usage thought society.

> or you can do a risk analysis from a cost/benefit point of view, but there you again can't just compare the cost, you would have to quantify the benefits of the particular tool/technology.

My whole point in this discussion is that using toaster analogies with cars is pointless. Cars are far more dangerous, as in `the actual likelihood one will suffer from it in the next 12 months`.

GPL v3

Posted Aug 10, 2012 15:20 UTC (Fri) by nix (subscriber, #2304) [Link] (13 responses)

You need to ask other questions too. How often are toaster-induced fatalities triggered by end-user modifications? How often are car-induced fatalities triggered by end-user modifications? How much could these rates go up if large-scale modifications were permitted?

I think you'll find that most toaster-induced fatalities are fires and electrical-system failures (particularly in the US with your literally terrifying electrical regulations, plugs that can shoot sparks when you unplug devices and all that): modifications to toasters are rare and generally the worst you'll do is make it not work. I think you'll find that most car-induced fatalities are caused by human error and/or the car functioning as designed, or by failure of manufacturer-provided systems. Car hardware is modded all the time: do those mods increase the fatality rate perceptibly?

I have no idea if this is true: I don't drive. I know that *some* mods, e.g. bull bars, *do* increase the fatality rate, but in the US, land of the SUV, bull bars are probably provided by the manufacturer and don't count as end-user mods. Heck, I wouldn't be *too* surprised to find the manufacturers providing sharp spikes on the front to get inconvenient pedestrians out of the way, and hood-mounted cannon to rapidly clear those unfortunate traffic jams. :P

I note that it is perfectly legal to modify your car to do all sorts of things, but that in the UK at least you have to regularly pass a test to make sure the thing is roadworthy before you can drive it anywhere but on a private road: so mods that made the car notably more likely to roll over onto pedestrians would probably be detected. It seems unlikely that mods to in-car entertainment systems would be anywhere near that dangerous -- but it is also true that your average garage owners cannot possibly diagnose faults in the software the way they can diagnose problematic hardware mods, and there's not much chance of government regulation keeping up with it either (at least in the UK, this is regulation enabled by legislation, not legislation itself: the MOT is routinely revised without Parliamentary involvement, but revisions to cover software mods seem hard to implement).

So I am of two minds -- and literally an outsider in this, since I'm about as likely to learn to drive as I am to learn to swim in molten rock.

GPL v3

Posted Aug 16, 2012 19:08 UTC (Thu) by Kluge (subscriber, #2881) [Link] (12 responses)

I think you'll find that most toaster-induced fatalities are fires and electrical-system failures (particularly in the US with your literally terrifying electrical regulations, plugs that can shoot sparks when you unplug devices and all that)...

This is waaay off-topic, but I would be very interested in hearing how and why the US electrical regulations are so terrifying.

GPL v3

Posted Aug 16, 2012 21:37 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (10 responses)

US electrical plugs are horrible. They can be too easily unplugged and it's actually _possible_ to touch plug's tines while they are still in contact with the wall socket. Doubleplusungood.

Most European countries adopted a plug design where the plug is recessed into the socket so any sparks are contained within it and naked live wires can't be physically touched.

Besides, US voltage is 110V versus 220-240V in Europe, so it gives rise to much higher (4 times) currents and much higher ohmic heating of wires.

GPL v3

Posted Aug 16, 2012 21:47 UTC (Thu) by dlang (guest, #313) [Link] (5 responses)

> Most European countries adopted a plug design where the plug is recessed into the socket so any sparks are contained within it and naked live wires can't be physically touched.

that must be a relatively recent development (it wasn't that way the last time I traveled)

what do the power strips and extension cords look like that have this sort of protection?

by the way, as for the voltage difference, the argument can also be made that the higher European voltage is more dangerous.

but voltage differences are not "terrifying regulations", nor are they regulations that allow "shoot sparks when you unplug devices" (something that's more likely with higher voltages)

GPL v3

Posted Aug 16, 2012 23:47 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

It's ancient, at least 30 years old. Extension cords look like this: http://ufa.dorus.ru/photos/1109129.jpg or http://upload.wikimedia.org/wikipedia/commons/e/e1/Surge_...

>but voltage differences are not "terrifying regulations", nor are they regulations that allow "shoot sparks when you unplug devices" (something that's more likely with higher voltages)
Sparks probably also happen within European plugs, but they happen _within_ them.

GPL v3

Posted Aug 17, 2012 12:16 UTC (Fri) by man_ls (guest, #15091) [Link]

Yes, sparks do happen and I've seen them even recently (due to a voltaic arc between socket and plug pin, I believe). But as you say they are contained in the socket. With the old flat design sparks could come dangerously close to fabrics or even your own hand.

GPL v3

Posted Aug 17, 2012 13:19 UTC (Fri) by ekj (guest, #1524) [Link] (2 responses)

If you design the plug like this: http://www.electronic-shisha-charcoal.com/images/euro-plu... (that's a non-grounded one), with only the tips made out of conductive material, then the entire conducting surface is inside the hole before electrical connection is made.

No, this ain't new. It's been this way for atleast a decade, possibly 2.

GPL v3

Posted Aug 24, 2012 22:24 UTC (Fri) by JanC_ (guest, #34940) [Link]

The radio I got as a kid had such a plug. That was in the late 1970s or early 1980s… (so about 30-35 years ago).

GPL v3

Posted Aug 24, 2012 23:49 UTC (Fri) by anselm (subscriber, #2796) [Link]

It's been this way for atleast a decade, possibly 2.

As a matter of fact, that type of plug was standardised in the early 1960s. It has been around literally for generations.

This »Europlug« design is popular for devices requiring up to 2.5 A which do not need to be grounded, in all European countries except the UK, Ireland, and a few other places that use the UK system like Malta or Cyprus. The Swiss system is also subtly different. There are other, more sturdy plugs used for equipment that requires stronger currents, must be earthed, or is used outside.

The UK system uses large plugs with three rectangular prongs. These plugs are usually fused, and are incompatible with the Europlug, although UK bathrooms will often feature Europlug sockets to accommodate electric shavers. It is possible to manufacture »converter« plugs that fit around a Europlug, contain the requisite fuse, and have the three prongs required for a UK socket.

GPL v3

Posted Aug 17, 2012 13:21 UTC (Fri) by nix (subscriber, #2304) [Link] (3 responses)

I will admit that the European recessed design is nice: I wish the UK added recessing to its earthed socket design, but changing the entire installed base of plugs and sockets is so hard that it's unlikely ever to happen.

GPL v3

Posted Aug 20, 2012 9:50 UTC (Mon) by etienne (guest, #25256) [Link] (2 responses)

> UK ... earthed socket design

Ever seen someone using a pair of scissor in the earth of a UK socket to open the live holes and plug-in by force a european 2 pin plug?

GPL v3

Posted Aug 20, 2012 12:08 UTC (Mon) by BlueLightning (subscriber, #38978) [Link] (1 responses)

For conformant EU plugs and UK sockets, the pins are too large and narrowly spaced for that to work.

GPL v3

Posted Aug 20, 2012 22:25 UTC (Mon) by nix (subscriber, #2304) [Link]

Yes, but there do exist (cheap and horrible firetrap) adaptors which convert EU prong spacing into UK prong spacing without bothering to provide anything as plebeian as an earth prong. Then the scissor trick is needed.

It is perhaps thirty years since I saw anyone resorting to *that*. :)

GPL v3

Posted Aug 17, 2012 13:19 UTC (Fri) by nix (subscriber, #2304) [Link]

The plug and socket design is horrible: two pin, no earth, easily broken, easily touched when removing or inserting plugs, with live interiors of sockets often accessible trivially (not shielded). None of this is true of (in particular) UK three-pin sockets, which are almost always switched and separately fused, with further fusing at the house ring mains, in the street, and at the transformer (which is *not* per-house, but often per-street or per-block, allowing significantly greater efficiency and protection than the per-house scheme common in the US). The higher voltage also means that it is exceedingly rare for plugs or cables to even get warm, let alone hot enough to set anything on fire.

There are minimal regulations regarding electrical equipment in waterlogged areas like bathrooms: the UK forbids anything not internally earthed, anything running at above trivial voltages and in certain parts of the bathroom forbids anything electrical at all modulo pull cords. You never, ever see things like washing machines in bathrooms, and it is very rare for people to get electrocuted in bathrooms (the primary cause is manufacturing defects in electric showers).

Electrical fires and fatal electrocutions still happen in the UK, but they are so rare as to be national news when they do happen. So, yes, from my perspective US domestic electrical regulations are terrifyingly lax.

The real reason for all this of course is that electric kettles are ubiquitous in the UK, and we need our cups of tea fast! :)

GPL v3

Posted Aug 9, 2012 16:27 UTC (Thu) by ScottMinster (subscriber, #67541) [Link] (2 responses)

I don't see why you would need to even prevent access to the interface. After all, there is quite easy access to any number of pieces of hardware on the car, that if modified incorrectly could easily cause injury or death to humans nearby. Are these car manufacturers as worried that I might drain all the oil from the engine, then drive around until the engine seizes? What if I mess with the brakes? How is changing the SW in the car really any different?

Quite frankly, it would be much better if the various pieces of firmware and IVI software were open source and available. Then third parties, like auto mechanics, could have access to this information and be able to do repairs. As it currently is, all SW repairs have to be done through the dealer. They are bad enough with proprietary diagnostic tools (why the "check engine" light is on).

IANAL, but I believe there have been cases in the past where car manufacturers tried similar tricks on hardware to prevent third party repairs and were smacked down by the courts. I don't see why SW would be so fundamentally different, there just haven't been enough court cases yet.

When you buy something, be it a car or a computer, it should be yours to tinker with as you please. Manufacturer lock downs should be as unwelcome in cars as they are in computers or tablets. Of course, if you do change something, and you hurt or kill someone as a result, you better be prepared to accept the consequences.

GPL v3

Posted Aug 9, 2012 21:16 UTC (Thu) by rvfh (guest, #31018) [Link] (1 responses)

Fully agreed. And I would love to be able to fix that stupid bug in my car speed regulator!

GPL v3

Posted Aug 10, 2012 0:35 UTC (Fri) by dlang (guest, #313) [Link]

you can do that today. Just go buy a ODB-II interface kit and you can reprogram the speed limiter in your current car computer.

GPL v3

Posted Aug 9, 2012 19:26 UTC (Thu) by iabervon (subscriber, #722) [Link] (3 responses)

I think that the right thing, from the point of view of allocating responsibility, would be to check at boot that the image is signed by a key stored in a PROM (or ROM) in a ZIF socket inside the dashboard. If you want to change your firmware, you have to change the PROM to hold a key you have the private part to, and sign your new firmware. Then, if the system malfunctions in an unsafe way, it'll point to you as the responsible party. More generally, if the owner of the vehicle wants to install a Bose IVI system in a Ford car, they can do this with no more hassles that it used to be to put in a custom stereo, but they're also clearly shifting the safety responsibility to Bose from Ford, removing the chip that says "Ford IVI" and putting in the one from the Bose box. (While they're at it, use JTAG to install firmware images, to make the sort of equipment needed to install new firmware at all comparable to the sort of equipment needed to install a different public key.)

GPL v3

Posted Aug 11, 2012 8:58 UTC (Sat) by jospoortvliet (guest, #33164) [Link] (2 responses)

As was said, that's beautiful, but might still not hold up in court - the car maker gave you the possibility to screw up so it is their responsibility. Or something like that...

Moreover, you think a journalist would bother checking if the car software was modified? No, headlines will just say "4 killed in $CARBRAND".

I understand the reluctance to adopting GPLv3. I hadn't thought of these issues but they make it rather clear to me that GPLv3 has a big problem...

GPL v3

Posted Aug 11, 2012 9:59 UTC (Sat) by dlang (guest, #313) [Link]

it's already big business to modify car computers, brakes, engines, and everything else that's safety related on a car.

What makes software so different?

GPL v3

Posted Aug 12, 2012 0:48 UTC (Sun) by iabervon (subscriber, #722) [Link]

Letting you use the steering wheel and gas pedal is clearly a much larger way in which car makers give you the possibility to screw up. They also give you the possibility to neglect safety-critical maintenance. Anyway, when 4 people are actually killed in a car, the make of the vehicle doesn't necessarily show up in the story, let alone the headline; it's unfortunately far too common an occurrence. People collecting safety statistics are much more likely to take after-market modifications into account; and this sort of aggregate statistic is unlikely to really be affected by anything an IVI system could do, anyway.

GENIVI: moving an industry to open source

Posted Aug 9, 2012 7:56 UTC (Thu) by paulj (subscriber, #341) [Link] (7 responses)

Consequently, the manufacturers' stance is that the only software that they can permit on the head unit is software that they've tested.

Replace "software" in this statement with "parts", and "head unit" with "car" to see how ridiculous this statement is. Indeed, preventing 3rd party modification or repairs would be *illegal* in many major jurisdictions and/or laws exist to require car manufacturers to make necessary tools (including software diagnostics) available to 3rd parties and/or openly specified.

GENIVI: moving an industry to open source

Posted Aug 9, 2012 11:04 UTC (Thu) by Klavs (guest, #10563) [Link]

My thoughts exactly. The exact same "problem" about bad press, would arise if someone put in some shuddy engine part - making the car perform badly - or if they simply damaged the parts by doing something stupid.

GENIVI: moving an industry to open source

Posted Aug 9, 2012 12:31 UTC (Thu) by fb (guest, #53265) [Link] (4 responses)

> Replace "software" in this statement with "parts", and "head unit" with "car" to see how ridiculous this statement is.

Software is not a mechanical component, i.e. "part", and a head-unit is not a car. For one, the complexity of "parts" is several orders of magnitude smaller than that of "software" (do you disagree?).

(You could also talk about replacing software with giraffe and head unit with tomato...)

GENIVI: moving an industry to open source

Posted Aug 9, 2012 12:51 UTC (Thu) by paulj (subscriber, #341) [Link] (3 responses)

Replacing software with giraffe would turn the argument into an analogy, which usually are imperfect (ridiculously so for giraffe/tomato). Replacing software with part and head-unit with car however is valid, because the software *is* a part of the car - it is not an analogy.

If you accept that the parts of a car must be serviceable by arbitrary 3rd parties, then the software must be. Otherwise, you must argue only /some/ parts should, and/or some not. In which case, the argument you use for why software should not be must not apply to those other parts (otherwise, your argument is non-sensical).

That software is not mechanical is such an argument. But why does that matter? If by mechanical, you mean the solid stuff, well the oil isn't that either. That's seems a strangely arbitrary argument.

As for complexity, the car in its entirety may well be just as complex as the software (excluding the software). The car in its entirety certainly must be least as complex as the software, so the extension of your argument to the car would mean that /no/ component of it should be serviceable or modifiable.

GENIVI: moving an industry to open source

Posted Aug 9, 2012 15:12 UTC (Thu) by fb (guest, #53265) [Link] (2 responses)

> If you accept that the parts of a car must be serviceable by arbitrary 3rd parties, then the software must be.

I accept that car parts must be serviceable, but I do not expect software of embedded parts to be arbitrarily serviceable.

> Otherwise, you must argue only /some/ parts should, and/or some not.

Which was exactly what I was saying.

> In which case, the argument you use for why software should not be must not apply to those other parts (otherwise, your argument is non-sensical).

My position is that software of an embedded "head unit" (weird term) is fundamentally different from "car parts". So I really don't see why the serviceability requirement of car parts would be, by default, valid for it.

From my perspective, it is up to you to make a case for the need to service such parts...

> As for complexity, the car in its entirety may well be just as complex as the software (excluding the software). The car in its entirety certainly must be least as complex as the software, so the extension of your argument to the car would mean that /no/ component of it should be serviceable or modifiable.

I really do not buy any this. How many millions of lines of code are we talking about in the Linux kernel? How often that code changes?

How often do you hear about serious engineering SNAFUs relating to new released cars or car's mechanical parts? How often you get that with new software releases? Surely, if the complexity and rate of changes is comparable it would somehow in the same ball park? (not saying that cars don't get recalled for bad parts, just saying that SNAFU frequency is a /lot/ lower).

Car parts are serviceable because they have an extraordinary level of well designed specifications, specifications which are designed for future compatibility and maintenance, and all things considered, those parts do not change that much from one year to another. Compare that to software change rates.

The same countries that made car part serviceability a legal requirement, also made an engineer's license or degree a requirement to design such parts. Do we have anything like that in software 'engineering'?

GENIVI: moving an industry to open source

Posted Aug 10, 2012 0:41 UTC (Fri) by dlang (guest, #313) [Link] (1 responses)

> The same countries that made car part serviceability a legal requirement, also made an engineer's license or degree a requirement to design such parts.

No they didn't. Anyone can create a car part and put it on their car.

There are a small handful of exceptions where the components are supposed to be government approved (headlights and tires are two examples), but in practice this requirement is generally even more ignored than the speed limits.

If you have a suitably equipped garage, you can build the entire vehicle from piles of metal.

There is not degree or engineers license required to do this.

Now, when you start selling parts to other people, there are more requirements.

GENIVI: moving an industry to open source

Posted Aug 10, 2012 2:23 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]

That actually depends on a country. In Russia it's technically unlawful even to replace the built-in stereo because the combination technically loses its certified status.

GENIVI: moving an industry to open source

Posted Aug 10, 2012 2:30 UTC (Fri) by dlang (guest, #313) [Link]

> Replace "software" in this statement with "parts", and "head unit" with "car" to see how ridiculous this statement is.

The car manufacturers tried to make exactly this same claim several years ago regarding parts, and they lost that battle so badly that the practice was made illegal.

I wonder is the same laws could be applied to the digital "parts" of the car?

GENIVI: moving an industry to open source

Posted Aug 9, 2012 13:53 UTC (Thu) by dskoll (subscriber, #1630) [Link] (33 responses)

I just don't get the whole IVI concept. Studies show consistently that distracted drivers drive as badly as those with blood alcohol over the legal limit.

Are we so in love with shiny things that we want to add more distractions to drivers and increase the carnage on the road?

I hope at some point that IVI manufacturers are hit with a punishing class-action lawsuit for their callous disregard for human life.

To be sure, some of the IVI features like rear-facing cameras are probably a good idea. But encouraging people to take calls while driving or to consider their cars as an "entertainment centre" is criminally negligent.

GENIVI: moving an industry to open source

Posted Aug 9, 2012 14:31 UTC (Thu) by maxpolun (guest, #85717) [Link] (29 responses)

The biggest distraction danger right now is not IVI systems, but people using phones while driving. I'd much rather have people using an interface designed to be used while driving than using their phones.

And you can make the same argument against radio/stereo systems that have been in cars for decades. Distraction is a real danger, but the only way to prevent it is to educate people about how dangerous it is. Taking out IVI systems will not help one whit.

GENIVI: moving an industry to open source

Posted Aug 10, 2012 0:43 UTC (Fri) by dlang (guest, #313) [Link] (26 responses)

and cell phones are nowhere near as distracting to the driver as a couple of kids fighting in the back seat.

And once you outlaw all distractions, you will then have problems due to people falling asleep, zoneing out, etc behind the wheel, especially on long drives.

GENIVI: moving an industry to open source

Posted Aug 10, 2012 2:23 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (22 responses)

> and cell phones are nowhere near as distracting to the driver as a couple of kids fighting in the back seat.

Yep, cellphones are even MORE distracting. Seriously. They are as bad as driving drunk.

GENIVI: moving an industry to open source

Posted Aug 10, 2012 2:35 UTC (Fri) by dlang (guest, #313) [Link] (21 responses)

> Yep, cellphones are even MORE distracting. Seriously. They are as bad as driving drunk.

except you can hang up a phone quickly in response to changing road conditions, you can't sober up quickly.

and where is the study that says that talking on a cell phone is more distracting than trying to deal with a couple of kids fighting in the back seat?

the "cell phones are as bad as being drunk" is a catchy soundbite, but it's far from being the real story.

GENIVI: moving an industry to open source

Posted Aug 10, 2012 2:42 UTC (Fri) by dlang (guest, #313) [Link]

The lack of distractions can be a problem in and of itself

Long Haul trucking companies consider having a radio/CD player/etc in the truck to be a positive safety feature, the lack of any distraction for long, monotonous drives can result in drivers effectively being mesmerized by the constant scenery, causing them to be very slow to react to new events. Having the slight "distraction" of a radio can prevent this and reduce the chance of accidents.

GENIVI: moving an industry to open source

Posted Aug 10, 2012 7:09 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (19 responses)

Quite a few accidents happen if one doesn't notice something and/or distracted and doesn't react quickly enough.

GENIVI: moving an industry to open source

Posted Aug 10, 2012 15:03 UTC (Fri) by dlang (guest, #313) [Link] (18 responses)

> Quite a few accidents happen if one doesn't notice something and/or distracted and doesn't react quickly enough.

and who disputes this?

There is a big difference between this undisputed fact and equating distractions (especially cell phones) with drunk driving.

GENIVI: moving an industry to open source

Posted Aug 10, 2012 15:27 UTC (Fri) by dskoll (subscriber, #1630) [Link] (17 responses)

There is a big difference between this undisputed fact and equating distractions (especially cell phones) with drunk driving.

University of Utah study concluded "Three years after the preliminary results first were presented at a scientific meeting and drew wide attention, University of Utah psychologists have published a study showing that motorists who talk on handheld or hands-free cellular phones are as impaired as drunken drivers."

GENIVI: moving an industry to open source

Posted Aug 10, 2012 15:28 UTC (Fri) by dskoll (subscriber, #1630) [Link] (8 responses)

Oh, and from the same study:

The study reinforced earlier research by Strayer and Drews showing that hands-free cell phones are just as distracting as handheld cell phones because the conversation itself – not just manipulation of a handheld phone – distracts drivers from road conditions.

GENIVI: moving an industry to open source

Posted Aug 10, 2012 15:40 UTC (Fri) by dlang (guest, #313) [Link] (7 responses)

so we need to also ban conversations with other people in the car if it's the conversation that's so horribly distracting.

or we need to admit that there isn't really anything so special about cell phones.

GENIVI: moving an industry to open source

Posted Aug 10, 2012 16:50 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (5 responses)

Nope. Real face-to-face conversation in cars tend to be much less distracting. Again, it's confirmed by multiple studies.

GENIVI: moving an industry to open source

Posted Aug 10, 2012 18:50 UTC (Fri) by anselm (subscriber, #2796) [Link]

Real face-to-face conversation in cars tend to be much less distracting.

One would certainly hope that any conversation taking place in a car and involving the driver would not be a face-to-face conversation.

GENIVI: moving an industry to open source

Posted Aug 10, 2012 19:23 UTC (Fri) by dlang (guest, #313) [Link] (3 responses)

apparently so are conversations that involve push-to-talk hardware (various two way radio systems, CB, Ham, etc)

or so it would seem due to the fact that they have been explicitly exempted from the laws regulating cell phones.

I just don't see why phone conversations are so much worse than all of these other types of distraction. I think it all boils down to a nice sounding soundbite.

I also have a hard time with the fact that they are equating something that slows reaction time (distraction) with something that impairs judgment (drunk driving)

While you have accidents caused by both causes, they are really not equivalent.

If you can retain your judgment, you can reduce distractions when conditions get worse (heavier traffic, weather conditions, etc). If you don't have judgment you don't realize there is any need to change anything.

GENIVI: moving an industry to open source

Posted Aug 10, 2012 20:13 UTC (Fri) by dskoll (subscriber, #1630) [Link]

I just don't see why phone conversations are so much worse than all of these other types of distraction. I think it all boils down to a nice sounding soundbite.

Multiple studies have confirmed that indeed, there's something special about being on a cell phone that distracts us much more than other things. I've posted a link to one such study and you can easily find others with a few minutes of googling.

I'm not a psychologist so I don't know why it's the case, but I'm certainly convinced that it is the case.

GENIVI: moving an industry to open source

Posted Aug 10, 2012 20:15 UTC (Fri) by dskoll (subscriber, #1630) [Link] (1 responses)

If you don't have judgment you don't realize there is any need to change anything.

People who talk on cell phones while driving lack judgement. QED.

GENIVI: moving an industry to open source

Posted Aug 17, 2012 12:23 UTC (Fri) by man_ls (guest, #15091) [Link]

Check mate. Well played! And thanks for the laugh.

GENIVI: moving an industry to open source

Posted Aug 10, 2012 20:11 UTC (Fri) by dskoll (subscriber, #1630) [Link]

As another poster said, face-to-face conversations are much, much less distracting than phone conversations. Also, if you have other people in the car, they can see the traffic conditions and be aware when it's time to shut up or yell "Look out!". Someone on the other end of the phone lacks that info.

GENIVI: moving an industry to open source

Posted Aug 24, 2012 2:29 UTC (Fri) by dlang (guest, #313) [Link] (7 responses)

by the way, there are now starting to be studies coming out asking why, if using a phone is so bad, are the laws against cell phones (and the measured drop in cell phone usage) not showing any results in the accident or fatality rates.

a couple cases in point:

http://news.sciencemag.org/sciencenow/2012/08/why-cell-ph...

http://esciencenews.com/articles/2011/12/14/wayne.state.s...

GENIVI: moving an industry to open source

Posted Aug 27, 2012 16:59 UTC (Mon) by mathstuf (subscriber, #69389) [Link] (6 responses)

Without reading your links, some questions I would have are:

- How is the drop in usage measured? Self-reporting? If so, there might be bias there.
- Is age factored out? I would think teens are more likely to flaunt those laws and are at higher risk anyways.
- In-car navigation systems and the like seem to be rising in popularity as well. Maybe there is some cancellation there?

Really, a decrease in the percentage of the rates due to cell phones would be the interesting numbers.

GENIVI: moving an industry to open source

Posted Aug 27, 2012 22:12 UTC (Mon) by dlang (guest, #313) [Link] (5 responses)

These (and apparently other) studies were started to research the strange phenomenon that all these anti-cell phone laws have been passed on the justification that they would improve safety, but the accident and fatality rates have not changed as a result of the laws being passed.

so either

A) everyone is ignoring the law

B) cell phone use may not have been as much a factor as people thought.

In one of the links, they were reviewing the data from one of the early studies that showed that cell phone use was so horrible. They found that when the study was comparing "accident" days with "non-accident" days, they didn't account for the miles driven. If they changed the calculation to be by miles rather than by days, the rate of accidents with cell phone use was 1/5 the rate calculated in the original study, bringing it down to almost the accident rate for non-cell phone use.

In the other study, they did question people on their cell phone usage, and then had them drive the same route. They found that the people who reported high cell phone usage had many other driving habits that made them more likely to get into accidents (higher speeds +5mph, 2x more lane changes, etc), raising the question of if the cell phone use was the _cause_ of these people tending to have higher accident rates, or merely a _correlation_ with their other driving habits. This is just looking at the more extremes (use a phone frequently, and almost never use a phone), so it's hardly definitive either, but they are counterpoints to the "Cell phone usage is as bad as drunk driving" drumbeat that we ahve been hearing, so I thought I'd mention them.

GENIVI: moving an industry to open source

Posted Aug 27, 2012 22:33 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (3 responses)

Accidents decrease in the areas with _strict_ no-phone law enforcement. Unfortunately, they're hardly ever enforced - people just ignore them.

GENIVI: moving an industry to open source

Posted Aug 27, 2012 23:54 UTC (Mon) by dlang (guest, #313) [Link] (2 responses)

do you have something to show this?

Also, if they are cracking down on no-phone rules, are they cracking down on all other questionable driving habits as well? if so, is it possible that that part of the crackdown is the cause of any decrease in the accident rate?

GENIVI: moving an industry to open source

Posted Aug 28, 2012 0:15 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

Yes, I have a link to a police report about it. Only I can't find it right now.

Of course, it can be a result of the general crackdown. However, phones are clearly a contributing factor in a significant number of sever accidents.

GENIVI: moving an industry to open source

Posted Aug 28, 2012 1:11 UTC (Tue) by dlang (guest, #313) [Link]

the question is over how much of a contribution the phone is (especially compared to other distractions) and if it's really a "significiant" number of accidents.

I don't think that anyone disputes that some people drive significantly worse while talking on the phone, or that this results in some accidents.

The dispute comes when you assume that banning phones will significantly reduce accidents.

So far it appears that this isn't the case.

P.S. A law against something bad that everyone ignores is worse than not having a law against that same something, it encourages people to think of the law as something that doesn't really mean much, and it leads to people looking at cases where laws are enforced with the slant of "why were they really out to get that person"

Talking while driving

Posted Aug 28, 2012 1:20 UTC (Tue) by man_ls (guest, #15091) [Link]

"All else being equal" is a tricky proposition even on the best days. There may be multiple arguments to explain why the accident rate has not gone down after forbidding "talking while driving", besides the two you mention:

Talking while driving did not account for a large percentage of accidents.
Talking while driving was forbidden when cellphones were not so popular, so the amount of talking while driving has kept more or less stable (including people who disregard the law).
Any other combination of outside factors has increased accident rates compensating for any talking while driving laws.
My favorite is that people now use hands-free cellphones, which are just as dangerous as hands-on cellphones -- ergo the lack of effect.

I suppose that all the new studies are taking these factors into account, but best methodology would be to check similar countries with different laws and see how they fare. I don't know if that is possible.

Personally I think that the cellphone laws is not a good idea; one must exercise extreme caution when talking while driving, but also when talking hands-free, smoking (those who do), changing the music, talking to your spouse, seeing an accident nearby, and any other condition that diminishes your attention to the road. Since those other things are not going to be forbidden it makes little sense to fixate on cellphones.

I think that the worst habit is filming a movie while driving; those actors that look to the passengers for minutes on end drive me crazy.

GENIVI: moving an industry to open source

Posted Aug 10, 2012 15:26 UTC (Fri) by dskoll (subscriber, #1630) [Link] (2 responses)

and cell phones are nowhere near as distracting to the driver as a couple of kids fighting in the back seat.

Cell phones are far more distracting. There are many studies showing that the impairment from being on a cell phone while driving is as bad as the impairment from being legally drunk.

I won't even mention texting while driving which is in a whole other category of WTF.

GENIVI: moving an industry to open source

Posted Aug 10, 2012 15:49 UTC (Fri) by jwakely (subscriber, #60262) [Link]

I know someone who took part in a highly unscientific experiment involving some very experienced drivers, a test track, mobile phones and alchohol. Using a phone make your driving worse than alcohol does.

(N.B. this was on a test track, not public roads!)

GENIVI: moving an industry to open source

Posted Aug 17, 2012 12:30 UTC (Fri) by man_ls (guest, #15091) [Link]

I won't even mention texting while driving which is in a whole other category of WTF.

I have texted while driving on one of the old phones with a numeric keypad; it is not so hard once you learn all the key positions. Of course I did it while in a traffic jam to warn my wife; the vehicle was almost completely stopped. I will admit that it increases risk, but at that point risk was negligible.

There is a similar trick on the movie The Departed, but without driving -- too easy.

The problem with regulations is that they are always too generic or too specific; using a mobile is banned even when stopped or moving at 10 km/h. But if hundreds of lives are saved per year then it is well worth it.

GENIVI: moving an industry to open source

Posted Aug 10, 2012 15:30 UTC (Fri) by dskoll (subscriber, #1630) [Link] (1 responses)

And you can make the same argument against radio/stereo systems that have been in cars for decades.

Not really. You don't need to look at a radio to change stations (well, except in my Prius which replaced nice tactile radio buttons with a context-sensitive touchscreen... there's a real WTF.)

You also don't need to concentrate much to listen to the radio, unlike talking to someone on a cell phone.

GENIVI: moving an industry to open source

Posted Aug 10, 2012 15:46 UTC (Fri) by dlang (guest, #313) [Link]

> You also don't need to concentrate much to listen to the radio, unlike talking to someone on a cell phone.

that depends on what you are listening to.

listening to a talk radio host that has you yelling back at the radio is almost certainly as distracting as listening to a phone call :-)

listening to background music is not going to be that distracting, although listening to music that you like well enough to start singing along and moving to the music probably is far more distracting.

listening to books on tape could also range wildly, most of the time it's not going to eat that much of your attention, but when you get to the cliffhanger section of a thriller, It can eat a lot of your attention.

The effect of all of these distractions vary greatly from person to person.

GENIVI: moving an industry to open source

Posted Aug 10, 2012 8:14 UTC (Fri) by fb (guest, #53265) [Link] (2 responses)

> I just don't get the whole IVI concept.

I think the idea is NOT to serve entertainment to the driver, but to build something to show/manage:

- video feed from rear camera while parking/etc
- proximity sensor warning display, also used while parking for instance
- GPS navigation

I believe the entertainment aspect (as far as the driver goes) is to control the video display at the back-seat terminals that the children are watching (like turning it off once they fall asleep). Not very different from selecting radio stations.

The units at the back-seat will probably have a stronger entertainment aspect.

[...]

On a personal note, I used a car with proximity sensors last week, found them wonderful. There was a large warning at the display about "look to confirm safety" (or words to this effect).

I thought it was silly until I thought that many will just stop looking anywhere else. Like folks that drive into a river because the GPS told them so.

GENIVI: moving an industry to open source

Posted Aug 10, 2012 16:17 UTC (Fri) by nix (subscriber, #2304) [Link] (1 responses)

What? A proximity sensor that requires you to look at a separate display to see if it's fired? (Or was this projected onto the windscreen?)

There have long been proximity sensors that emit increasingly frequent beeps when near something, like old-time movie radar. They're useful when parking.

GENIVI: moving an industry to open source

Posted Aug 10, 2012 16:33 UTC (Fri) by fb (guest, #53265) [Link]

> What? A proximity sensor that requires you to look at a separate display to see if it's fired? (Or was this projected onto the windscreen?)

The car had 6 such sensors ({front, back} x {left, center, right}), while the beeping would increase AND its position was simulated by the car's stereo system, the car also had a large screen display (one such 'head unit') which also displayed the car and each (of possibly many) beeping sensors.

I found checking the screen easier than relying on the stereo direction to know which was the triggered sensor.

This is what GPLv3 was designed to protect us from

Posted Aug 9, 2012 15:24 UTC (Thu) by mikapfl (subscriber, #84646) [Link] (1 responses)

While I can see why car manufacturers don't like the GPLv3, I am not at all declined to sympathize with them. I can entirely see why Google or Apple would /love/ a linux kernel under a two-clause BSD license. Of course the vendors love non-copyleft licenses. But copyleft is designed to protect users from vendors. And where simple copyleft can only go so far when source code is conveyed but the device actively hinders using the four freedoms, the GPLv3 adresses this issue, reinforcing user's four freedoms, disallowing technical countermeasures against the spirit of copyleft.

And this is a real problem, not a philosophical. Yes, the vendor might want to try limiting the life-span of the car via software to drain the market of used cars, encouraging to buy new cars. It might sound like this couldn't be possibly legal, but beware. This is what smartphone vendors routinely do. Like, have a car with android in it, ship security updates for three years. There you go. This is what GPLv3 was designed to protect us from. While it is not nice to hear car vendors actually want to keep control over the very device they sold us, it is good to hear car vendors are trying to work around GPLv3 licensed software because the GPLv3 does not allow them to do, as this means the GPLv3 is actually considered effective by their lawyers.

This is what GPLv3 was designed to protect us from

Posted Aug 22, 2012 8:28 UTC (Wed) by ortalo (guest, #4654) [Link]

Agreed. This once again exhibits excessive (IMO) greed from manufacturers trying to gather hidden costs from their victims. [1]

Another problem is that such greed prevents everyone from actually progressing in clear system designs (e.g. bug versus feature, critical versus non-critical function, etc.) that would help improve the overall system.

[1] I know this vocabulary may sound strong from a manufacturer perspective. However, let's say it clearly: things like paying for software bug corrections (in an embedded system or any system) or even for something as basic as a computer-assisted automatic diagnostic has resemblance with extortion. (No, they do not cost anything to produce.)