Articles / What Aduva's Up To

What Aduva's Up To

A recent Slashdot story sparked a great deal of discussion about Aduva's plans for simplifying Linux administration. Aduva's Izar Tarandach says it sparked a great many misconceptions as well. Today, he tries to put the record straight. Aduva was recently featured in a Slashdot article, where we were erroneously cataloged as "an RPM package manager" and "some tool for Red Hat".

While we are really very happy to have appeared there (and to have drawn the kind of comments we did) we feel that there are some points we have to clear up with the community.

It's a common fact of life that people first exposed to Linux may suffer a complete culture shock if they happen to have a background on other operating systems.

Mostly, this is characterized by the difficulty to grasp the intricacies and relations between different parts of the system that were probably "hidden" by the interface of their previous experience. What is this kernel thing they keep telling me to upgrade? Where is the setup.exe for this package? What do you mean, "dependencies"?

This "frustration factor" is one of the leading reasons why people go back to inferior closed source operating systems even after being introduced to more advanced alternatives. That feeling of "I know where everything is" and "Hey, it's not supposed to work flawlessly" can fast subdue the curiosity and excitement of a new challenge.

Then throw in the location effect. Not everybody knows of the many search engines in the Net, nor the many great sites available for searching and downloading packages, be they in whatever format, and, in some cases, the package one finds is not the version one needs. Bafflement and confusion follow.

apt-rpm, autorpm, rpmfind, up2date/RHUN, and urpmi/rpmdrake/Mandrake Update, as well shown in an editorial by Alfredo Kojima, do similar tasks in solving part of these problems.

What we are trying to achieve at Aduva is to take one additional step towards the new user while, at the same time, giving more power to the experienced system administrator.

We hope to achieve this by providing much-needed testing and functionality not found in any of the existing solutions. Also, by providing newbies with a less painful learning curve, we hope to help more people settle down in Linuxland, and at the same time we are developing technologies to help the seasoned system administrator better his time management (Quake, anyone?).

What we are doing

Besides the obvious job of package installation, we are trying to deal with hardware detection and installation, kernel compilation, and, above all, basic quality assurance of the installed packages.

We have people responsible for component hunting. These guys are just like your average Joe User, but they just happen to know what to look for and where to look for it, and they are very good at it. They are talking to the people that write the packages, making sure that we know when a new version is out as soon as it hits a public directory.

Their job is to pass the data to the guys that do research, your regular hacker ground zero, where very experienced Linux enthusiasts, ranging from 10+-years-of-experience sysadmins to bugtraq-breathing white-hat "hackers" will do the actual job of opening the package, seeing what it needs and what it breaks, and writing the rules that are fed to a logical engine.

These guys interact with our Lab, where banks over banks of different hardware (we have a lot of hardware here) churn 24x7 over the different configurations of Linux distributions, eating the rules written and verifying their completeness and applicability. Take into consideration that this process takes many iterations, and that the Lab is continually tightening the bounds on the tests applied. Having approximately 15,000 HW & SW components on the database makes this a quite complex, time consuming process. This is the sort of dependency we use -- based on the dependencies announced by the package, but vetted by us and, usually, much more restrictive (if needs be) and all-encompassing.

Of course, this recursive and partly-automated process cannot be and is not 100% infallible. That's why we have a human QA department that is responsible for the final OK on the rules.

Why are we doing this?

Yes, we are a company. We aim at making money. But we come from the Linux Community, and we are part of it, and we are proud of it. We have a commitment to give back to the Community what we received from it: support, nurturing, and knowledge.

Early in our development, we decided to give away the Aduva Manager freely for home use, as stated in the Aduva License. We will not be charging the home user for access to our database. That is final.

We have access to a lot of information on what's running on your host and what you decided to install. I, myself, would never be 100% relaxed knowing that someone had that sort of knowledge of my box, but the whole design of the program was done so that we don't need to know what's in there. That added a lot of difficulties, but we saw it as fundamental. We have a privacy policy that we firmly stand behind and that can be summarized as: We won't get anything from you that:

  1. you don't agree explicitly to give us,
  2. you don't know we are getting.

We need the feedback on the conflicts and "unknown to us" packages people are using on their hosts to better the service, but we will not take it if you don't agree to give it to us, and we will tell you that there are things we might be interested in (e.g., unknown packages, unknown hardware) and ask for your permission to send them to us. If you don't agree, we get nothing, and in no way -- absolutely no way -- will your personal information (IP, hostname, nothing) be related to the information you pass us.

Eventually, though, we come back to that green thing. We aim to extend the service to the corporate world, to bring our management services to the enterprises that are using (and will be using) Linux in its many distro forms and flavours. For that, we will be charging money, but it's a different product; it's just based on the same technology. So, money means lawyers, and that means licenses written so that you can actually do something useful with a corporation without the risk of getting sued for wearing the wrong color of (ugh!) tie when you visit them. That's why the license looks so "suit", and that's why we are, for the moment, holding back on releasing source code. We will go GPL. Bear with us for a while more; we need to polish the tarball. :)

Beyond Package Management

Today, the Aduva Manager can install and upgrade a kernel that will fit your machine. We don't (presently) claim that it will be the most optimized kernel possible for your configuration, but we do go to great lengths towards providing you with a functional kernel that serves all the hardware we could find on your machine.

We try to provide a solution for the total newbie by creating a single point of contact where you can, at a glance (OK, perhaps you do have to do some mouse clicking, but we'll revamp the GUI), see the complete status of your system and news about packages that interest you or package news in general, with single-click installation of those same packages.

Our Intelligence Department keeps a keen eye on security patches. The Aduva Manager begins its run with a security check, offering the patches needed to the packages you have, and to the kernel if necessary. Only then do we move on to upgrading the available components. For the more advanced user, we offer dependency resolution and stability all across the board, again with single click installations. Our logical engine will get to the most stable configuration possible or die trying, while keeping you informed of all that is going on in the process. For the user needing script capabilities, we provide a CLI that can be used to do the same job as the GUI.

Why RPM? Why Red Hat?

We had to begin somewhere. :)

No, really. Our marketing people told us that we had to go with the biggest guy on the playground if we wanted to show that we could play. This does not mean that we are married to RH. Our solution will shortly be extended to SuSe and other distributions, and the inclusion of .deb, while not trivial, is not such a big leap.

In the end, we all aim for world domination.

Izar Tarandach ( is the Director of Technologies and Daemon Exorcist at Aduva, Inc. Previously, he was a member of the Razor Team at Bindview, Inc. He has been an avid Linux enthusiast since the first kernel, and has been pushing Linux into business for the last 9 years.

T-Shirts and Fame!

We're eager to find people interested in writing editorials on software-related topics. We're flexible on length, style, and topic, so long as you know what you're talking about and back up your opinions with facts. Anyone who writes an editorial gets a freshmeat t-shirt from ThinkGeek in addition to 15 minutes of fame. If you think you'd like to try your hand at it, let know what you'd like to write about.

Recent comments

13 Dec 2001 00:04 Avatar hiker

Re: yawn
I am a new Linux user; I could no longer tolerate the high price not of the program cost of Windows but the incessant maintenance and virus fights.
You have an elitist attitude about Linux; I think you would be happy to keep it to a small group of Uberusers who alone understand it. Is it the mark of a great OS when it is so arcane only the geeks understand it? Why does it SUCK to make it more easily used and upgraded? Or do you think it is complete as it sits? The fact is that if Linux is to stay alive and grow, as it must to stay alive, it would be helpful to make the addition of devices and programs less dependant on the command line. That would make it more accessible to the great unwashed masses though, eh?

14 Jan 2001 09:47 Avatar imipak

One Solution to the Package Manager Conundrum
Other writers here are correct, IMHO, in asserting that we don't need Yet Another Packake Distribution System.

However, also IMHO, they are INCORRECT in asserting that package management is doomed to failure, because people use different systems.

I addressed this same problem in my "RelFS" proposal for the Software Carpentary competition, but will provide a much more generic solution here.

What you need is a kernel module which detects if/when a file is opened for write. The module then simply needs to call a userspace package database query script which checks to see if this file exists in the database. If it does, then the module should flag some daemon that this package has been altered, that the package should be probed "later" for it's new version, and that this change should be forwarded to the package manager database.

If the file is NOT in the database, but IS in one of a pre-defined set of directories which are of interest, then the file needs to be added to a list of "homeless" files. A "Package Construction Kit" would then allow the user to group files into new packages, or add them to existing packages. Any executable or library that's not grouped up is assigned to a "temporary" package, based on it's filename.

The end result is that you could then use RPM, PKG, TAR, or any combination thereof, and ==ALL== package managers would remain in perfect sync with each other.

14 Jan 2001 05:28 Avatar karellen

Ugh not another easy to use thingie for Linux so average Joe
Dotcommie can use it. Heck why isn't any company working on
a Linux ports thingie like all those latest and greatest BSDs
have? Well yes there are some, Linuxports @
and that Gentoo Linux thing [which has "obsoleted" most of the
standard packages I like eg. syslogd, inetd]. Doh! I hope
Linuxports gets usable one day and I can continue bitching about
lame easy-to-use package thingies for Joe BraindamagedLinuxUser.
Face the linux bastardization with setup.exe.

13 Jan 2001 23:34 Avatar lokoboko


No, I don't drive an SUV. I think they're a menace to other cars on the road and they need too much gasoline. Cost mucho dinero, too.

Is this relevant to the editorial at hand? No.


13 Jan 2001 21:22 Avatar davidcorrea

"leave and not visit the website anymore"
Do you drive an SUV also?


Project Spotlight

Kigo Video Converter Ultimate for Mac

A tool for converting and editing videos.


Project Spotlight


An efficient tagger for MP3, Ogg/Vorbis, and FLAC files.