News
27th of June 2004
Coolest day of my life
Went to laser tag today, was cool, got some ideas, some motivation, etc. You guys dont care about the details anyway ;)
I want everyone here to do themselves a favor, and me a favor. I want EVERYONE to delete their /usr/src/linux symlinks. Why you might ask?? Because drivers which use it for compilation shouldn't. The truth is that they should be using /modules/lib/2.x.x/build instead of that. This is done with uname. The advantages of this method is it works in 2.4 and 2.6, but will ALWAYS link to the kernel files. /usr/src has the common problem of not being updated automatically so when u need to install a new kernel, you need to manually change it. Try it yourself if you dont believe me, install vanilla kernel 2.6.5, the symlink isn't made automatically anyway, so you need to do it manually, then when you install another kernel, its pointed at the wrong kernel headers/source, so at the end, you end up compiling for the wrong version, so the compilation wont work anyway. But /lib/modules/OUTPUT OF UNAME/build points to the proper place. Sure its a tiny bit more effort, but its better then putting up with compiling a module only to discover it wont work. If anyone differs with my opinion, feel free to tell me, or bring it up on the forums. But overall, its much better for the users (saves incorrect bug reports too). So everyone please tell your favourite kernel module developers when they are using the bad way. Can someone please confirm for me that the install kernel headers for redhat/mandrake utilise /lib/modules/... too (tell me in the forums maybe), or any distro really that has the kernel headers packaged seperately from the kernel.
In other news, I have talked to the Autopackage developers and they agree that linux really needs a stable binary interface on the kernel. Or at least a way of compiling things, so that the #defines can be ignored dynamically in the code, so that a binary module will work in any other version of that kernel (at least), with no modifications, so that users can at least make more changes to their kernel, with no problems. There might be a way to do that already (maybe look at the symbols or something), but preferably, would be nice if there was a much easier way. Fortunately though, for a short time I was worried that some modules would need the kernel source installed to be used, but it doesn't appear that that is a problem anymore, because the freedesktop.org developers on the irc channel have clarified to me that the only things that will need it are kernel patches, and thats bad anyway (if kernel patches are needed for anything, except maybe schedulers, then it means the kernel needs to be reworked anyway to be even more modular.
Unfortunately, I have thought of a system, which could greatly increase the effectiveness of driver on demand, but there is no current infrastructure for it :( What I'd love is a common registry of modules/plugins/module install handlers for different programs (would be nice to have something like firefox where any program could just register itself, and upgrade itself if you request). The reason I want such a thing is that I would really like to hook up driver on demand to anything, and allow it to be used to find new plugins. For starters, it would be a way that Xchat plugins, gaim plugins, etc could be very easily managed (one run every startup maybe to check up updates on plugins), and also, the reason it would be nice mainly, is that such a system would make it trivial for driver on demand to be used by systems like xorg-x11, cups, etc, to auto install drivers for those apps as they are needed.. Guess I'll wait for xorg/whatever else support for driver on demand.. Maybe theres a better way to do it anyway, just gotta think ;)
19th of June, 2004
Proposal of new linuxdriver lists
Sorry for the delay, had exams for the last week.. Finally I started on a new linuxdriver listing format, available here which I need people to look through and give me some suggestions on improvements.
The cool thing is that once this is done, I can finally start on rewriting the server.. The rewrite will effectively allow drivers to be shared amongst many devices, so if a driver is updated, a vendor only needs to update one copy of it on the server, and all the rest will automatically update with it. The rewrite will allow me to add a HTML wizard to add drivers to the list, as well as finally allow rating of drivers to work. The new format will allow every driver in the list to be signed too, so that even most third party drivers could be considered safe.
10th of June, 2004
Restructure of CVS
For those of you who have been looking on the CVS, you probably will have noticed a few changes in the CVS.. mostly the fact that its been completely rearranged.. The changes were made so that it is now easier for people to install driver on demand.. The server files have been put in their own directories, same as the other files, and the submit driver script, as long as development docs are in their own directory..
Of course, you probably dont want to touch the CVS at the moment because the scripts currently dont comply with the state of the directories.. so while they will fulfill the dependencies, they wont copy the files into the right path.. Of course, since I'm also changing from perl to D programming language, anyone using the client no longer needs the perl dependencies..
Changing the client from Perl -> D
Yes, you read right.. I decided that perl just isn't up to the task, so am changing to D.. Most of you are probably asking why I did such a move.. The reasons is that Perl is relatively slow, its more or less aging, and some of the things I wanted to do on it, like add DBUS, would require a major coding effort to get the libraries working. It will take a short time for me to change it to cya
What is D?
D is a very new developmental programming language, developed by Digital Mars (http://www.digitalmars.com). Basically, it is like C/C++/C# on steroids, and porting C libraries to D is relatively trivial. D is also more immune to security flaws then C and C++.
What are the advantages of D, and why not Mono?
Mono is a linux C# .NET library, that is often portrayed as a next generation language.. It is however, it is only portrayed by MS as a next gen language. Overall, it is a java clone, with a few small changes. D has all the advantages of C#, with the benefit of not being controlled by MS, so there are no possible legal problems, Designed to be cross platform, has a free compiler for both windows and linux (not really important though in my case..) and is basically the future of Linux. The legality of Mono is under debate still, and the truth is that even when they do catch up to MS's implementation, MS will just release another version, so it will always be a game of cat and mouse..
I know many people wont agree with me, but we shouldn't have to play cat and mouse with Microsoft forever, which is the main reason I didn't choose Mono, there is nothing that any major organisation can do that will affect the future of D, and the language is just as open source, as linux itself, making it the perfect choice.
So you dislike the Mono project?
I never said I dislike it.. The mono programmers are doing an excellent job, I'm just saying that theres no point pursuing a language which is designed by a company who want to wipe unix/linux off the planet, especially when there are other languages available, which are considered better alternatives to C#..
So what changes will I see as a user?
For starters, you will need to install a D compiler now to install, however, the auto install script will handle that automatically probably. Driver on demand will take less RAM, and run quicker when it does run, however, if it compiles a driver though, your system will still get jumpy regardless, just for not as long (I might try to make it so it can automatically change the niceness value so that installations run at low priority too).
Perhaps the biggest changes you'll see are ones which benefit you (the user), such as the easier implementation of DBUS, which will allow you to be notified on your desktop when a driver is installed..
5th of June 2004 - Exams :(
My First exam starts Monday, so thats why I've been busy, and they last two weeks. I have a 8 day break in between though, so, I might split the repository during that time, and maybe even have enough time to get generic bus support working..
I have also been considering making an easy to use submission script too, which will come in the form of a wizard (unlike the current horrid one where you need to assemble the XML yourself). I've also been investigating DBUS support to allow a windows applet for driver on demand and also intend to start submitting a few drivers to the database (the madwifi/atheros one will probably be my first choice, because it supports PCI and PCMCIA), and its the only PCMCIA and PCI hardware that I have, and so is a good proof of concept.
Expect the first bunch of drivers to join the mirror on Tuesday or Wednesday (the most likely candidate of the first one being added is madwifi, which is a GPL/BSD licensed driver). If you come to the IRC channel and give me enough information, I'll make the corresponding driver list files.
29th of May 2004 - The first server is online..
Yep, we finally have a working driver on demand server (provided by lgchosting.com).. people can start submitting drivers into the database.. The web frontend also works now, properly, which means driver on demand is now usable!!!! Of course, we are always on the lookout for as many servers as we can obtain.. At the very moment, I have exams, so only small fixes for the next 2 weeks will be made, but after that I will get to work on driver on demand alpha 2 (I have been doing some preliminary analysis of the changes needed already). If you want to use the new server, go to the servers list on the side of the page for the details..
By the way, festival is a fun toy (especially when used with gaim).. I highly recommend it.
26th of May
I got the web based lookup working.. so you dont even need to install driver on demand to find drivers.. Unfortunately due to restrictions on the Sourceforge server.. The lookups dont work properly. You can however check out an example here. When I find someone to host a server, then you'll be able to see it in action. I will also soon split Driver On Demand up on the CVS to a server directory, and a client one to make things easier for alpha 2. The script isn't in CVS yet, but it shortly will be (when I get around to splitting the directories). Until that time if you want it, visit the IRC channel and I'll give it to you..
24th of May
I bet you all thought I was dead.. but nope, hate to disappoint you, still alive and kicking here.. Just been working on a computer graphics assignment for university, and a 80 page assignment.. Now only 2 left and exams and its my holidays.
Currently, I am working on a simple web interface for driver on demand, so people can punch in their vendor ID's and stuff and get a list of drivers without the client. Prob is that sourceforge doesn't have the XML-simple module installed though, so I'll have to wait until I get a new server.. Then finally submission will work too.. Then alpha 2 will come out and the DB will need wiping, but thats a while away still.. But the web interface isn't, I'm hoping to have the web interface done within a week. Someone remind me that I need to finally split up driverondemand into a client package, and server package..
THANK YOU FOR ALL YOUR DONATIONS!!!! I actually wish more people donated less anonymously so I could at least thank them individually or/and personally and hear what they want from the software.. I promise them though that the donations wont be wasted and will go towards helping the project. I seriously cannot thank you guys enough.
You'll also notice I made an ideas page.. Dont be too impressed, just really random thinking when I was dopey and tired (only the first 2 things are good.. Wondering whether to wipe the next 2 off, cause they make me look real dumb cause I never researched them).
"Future developments" page also got updated to stuff needed to be done pre alpha 2 (right now).. Of course, thats only if your interested...
15th of May
I'd like to thank the people at Slashdot, who agree with me when saying a system like this can be made more secure then a normal system, and that its advantages outweigh its disadvantages stacks.. I was working on an opengl assignment for uni (only got 9 days to finish it, and software eng), but I think I can get everything done within 5 days and get to Alpha 2 of driver on demand. I plan to format this laptop (which I wish I got enough money to replace one day, because a S3 IX /MX vid card really limits what I want to do, doesn't even support hardware accelleration, and is the second vid card S3 made) which will hopefully get schema's on my computer working again, which might prompt me to actually release a quick Alpha 2 with schema's working (Alpha 1 just has schema's disabled.. schema's are actually pretty much fully there, just need to disable them). Schema's are just used to ensure that driver files are valid.. You'll see a dramatic increase in stability when they are readded (so much added stability, so little effort). In fact, adding schema's pretty much allows me to have a secure enough submission script for a server..
Anyway, I'll get back to opengl so I can try to surprise you guys with a total revamped copy of Driver On Demand that works with at least USB too (if you guys want stuff like firewire though in that release, though, like I said, you'll have to either donate a device for that bus, or money so I can run off and buy one), and quickly add the 100 lines of code or whatever needed to support it.
By the way, I am looking for a job if anyone has any going (I'm a 3rd year computer science student with a focus on programming)..
14th of May, 2004
Yes I am still alive.. I just have 2 major assignments for University due in a week, which is why the CVS has been quiet. After I get these 2 assignments done though I'll release the new driver format, which will hopefully be powerful enough to cover all packaging systems/possibilities (the current one fails on systems like zero install, however I will work on it at soon as possible to get it working well. I'll get around to adding generic bus support using sysFS as well after these assignments. Btw, thank you for the anonymous donation, which will help greatly with acquiring a proper USB device to test, as the only real one I have at the moment has no linux driver (http://www.mnementh.co.uk/sonix/), if anyone's bored, feel free to make one :)
10th of May, 2004
Summary
---------------
Driver On demand is a driver management system designed for Linux, which is designed to automatically install drivers by using a httpd server. Its other intention is to create a universal driver standard for Linux, allowing drivers to be installed easier. Its only purpose is to allow any device you plug in, to work instantly with no installation of drivers required.
Alpha 1 is the first release of this software, and has a wide variety of features including:
- Local installation of drivers
- Automatic installation of PCI devices
- Kernel 2.6 support (kernel 2.4 is supported with a workaround, read below, but its more limited)
- Server lookup's for devices
- Ability to use packages specific to your distribution
- Server digital signatures and vendor side digital signatures to protect drivers against modifications by hackers
- Ability to restrict components of the client
- Full hotplug support.. You plug a PCI/PCMCIA device into the system, hotplug will automatically run driver on demand for that device if theres no existing driver.
- XML based drivers, which even when digitally signed, are easily human editable.
- Simple submission script of new drivers
- Support of multiple different drivers within a single driver definition file, where the driver can be determined manually, or automatically
- Support for different architectures besides ix86 (only AMD64 and ix86 is selectable at this time, but on alpha 2, I'll allow any architecture)
- Kernel matching, which allows drivers to be only installable on certain kernels, to prevent them being installed on unsupported ones.
Expectations for Alpha 2:
---------------------------------------
Alpha 2 will have generic bus support and work for PCI, PCI-express, firewire, or any other possible bus generically. Due to the move to sysfs needed for this, kernel 2.4 users will no longer be able to use driver on demand even with the workaround. The bonus is that Driver On Demand will perform faster and better.
A better signature system to allow 3rd party drivers to be signed.
XML validation.. I'm going to fully format my system and try to get it working again.
Unfortunately, I need a lot of donations of hardware to get Alpha 2 done (especially for testing of firewire and pci-express), so if you work at a hardware store, have some free hardware lying around, or sick of your developmental PCI-express motherboards, and they work in kernel 2.6 (with external drivers or otherwise), please consider providing access of them to me so I can finish Alpha 2 quickly. Even if you don't have any such hardware, think about sending other donations, to help this project.
Expect Alpha 2 to be out as early as 2 weeks from now, however it depends on the amount of time I have and whether I receive access to the hardware I need for testing, because I obviously cant even determine the format I need to support firewire devices or PCI devices when I don't have them.
How Can I help?
------------------------
At the moment I need:
-A server to host the driver profiles on.
-Money to support the project and allow me to buy a bigger hard disk to do the stuff I want to do later (UML/sandboxing of distribution specific drivers to analyse them).. This money will also allow me to buy more hardware to test driver on demand with. Also it will allow me to spend more time programming this because I wont have to seek a job as quickly
-Donate hardware for testing.
At this time I'm not looking for bug testers, because I am aware of the majority of the bugs.