h a l f b a k e r yNo, not that kind of baked.
add, search, annotate, link, view, overview, recent, by name, random
news, help, about, links, report a problem
browse anonymously,
or get an account
and write.
register,
|
|
|
Please log in.
Before you can vote, you need to register.
Please log in or create an account.
|
When you plug in a USB/FireWire/etc. peripheral, the device should send a URL to the host computer. If the computer is on the Internet, it should fetch the driver for that device from the given URL and install it. If you're not on the Internet, it should prompt you for an alternative location (such
as the CD-ROM drive), where it will look for the same URL (with "http://" removed).
That way you don't need to mess with a driver disc, and the hardware vendor can always have the latest version of the driver on their site. Also, since the files on the driver disc will have a consistent, URL-based naming scheme, it's easy to create your own driver discs for any particular collection of hardware.
To support multiple operating systems, the file at the target of the URL would probably not be an actual driver, but rather a "driver directory" in some standard XML-based format describing the location and attributes of all the available drivers for various operating systems.
[link]
|
| |
Waugsqueke: it's bootstrapping. The real driver for a device does things that are much more complex than just sending a string. One uses a fixed, simple protocol to make a system flexible; then builds on top of that flexibility. |
|
| |
Timing: Aren't we running into timing problems with this? Some systems can't load drivers while they're up. You'd have to bring subsystems up in the order CD-ROM, Internet, other drivers; I'm not sure how difficult it is to be online while the system is still booting. |
|
| |
Security: Having
some part of my system automatically contact its vendor upon installation can be more easily abused than, say, printed URLs in a manual, since the URLs are easy to individualize and probably invisible to the user. |
|
| |
A softer, more acceptable form of the technology could have a generic way of pasting a user-visible URL into a normal browser (maybe if you drag-and-drop the device?), giving me an easy, generic way to say "Check for updates for your driver." But of course that's much less cool. |
|
| |
Waugsqueke: What Jutta said. Newer system interface busses like PCI, USB, and FireWire have standard protocols for saying "Hi, I'm a new device, here's my name". I would simply add "... and here's the URL of my driver". |
|
| |
Timing: Well, I was thinking of devices that you could "hot plug" while the system is already running, e.g. USB and FireWire peripherals. Once the driver is installed, this process is no longer necessary; I didn't anticipate that it would download the driver again (unless the user prompts for an update, anyway). |
|
| |
For other devices, the OS could perhaps be smart enough to ignore the device until the system was booted, at which point it would launch the installation process. After installing the driver, you'd probably have to reboot again, but that's really no worse than the current setup. |
|
| |
Of course, a driver for a network card *must* be installed from CD-ROM (unless you have another card), and a driver for a CD-ROM *must* be installed from the network (unless you have another ...). |
|
| |
Security: Abused how? If the hardware vendor is interested in "abuse" they can already do whatever they want. Who else could abuse this setup? It's true that the URL should probably use SSL, so that people can't intercept the download and replace it with malicious bits. |
|
| |
Well, I'd normally be at least a little upset to see IP packets get sent by my CD writer - but you're of course right; we already trust drivers to some extent, and they are in a good position to do things behind their owner's back. This just gives it much better cover. |
|
| |
The current Mac OS actually does some of what you're asking for. I've plugged in a device and had the machine say something like "I don't have a driver for this, should I look for it on the Internet?" (It certainly doesn't download and install anything without permission.) |
|
| |
I've never looked into exactly how this works, though. |
|
| |
Do we need yet another protocol for this??? Devices are already transmitting their names and version number and serial code and whatsoever. Why not put the driver URL into one of these and let the OS be intelligent.
Yes, I know intelligent OS and windoze are not to be used in one sentence, but there actually are OS's that are more in control of themselves AND user friendly.
Why can an OS not realize the URL in the name without explicitly telling him "this is a URL".
Of course never ever automatic driver download, it would be like automatic fortune cookie download. |
|
| |
...I have to kiss the bun on this one. |
|
| |
In a way, this idea has come true. The implementation suggested here is not exactly how it works, but I've seen the described behavior in modern systems that were dragged home from the Fry's Electronics. |
|
| |