RPM Package Manager
Things have changed quite a bit since we last posted about the state of Linux Package Management. Over the few months ago, we saw the Connectiva release, which was a RPM front-end to apt-get [?] . Now, for those of you running RH6.x, there are a new program called Aduva Manager. It's kinda like using apt-get update/apt-get dist-upgrade, but checks dependecies and such for RH6.x based systems. They've got screenshots as well as a FAQ/download site. It's designed more for new users, but it looks like a step in the right direction for RPM.
It's been my humble opinion that packaging managers are good for "users" of OS's I just started using debian on my workstations after a co-worker showed me the ease of applying new dependancies. However without getting into a distro jihad here, I still say that for the tried-and-true, the only REAL way to understand and comprehend services on a production box, you really need to compile the source yourself.
How else are you going to be able to troubleshoot or modify any tweaks/perks/or problems that may occur.
Or take for example the debian debacle of a couple weeks ago. I did an upgrade then an install of a couple things only to find out that X was going to crap the bed on me... If I had been less lazy (yes I know that goes against EVERY netadmin's fibre) and had compiled the programs myself I could have saved a couple hours of time in the long run.
But as far as getting *nix out to the masses I applaud RH and Debian for attempting to ease the installation of software for new users.
-- Life: Hate the Game... Love the cereal
...these organic GUIs. Why do we need to have widgets that look like automobile clay models or stuff you'd find if you slit open your guts? What's wrong with good old 3D widgets, which took us like 10 years to get to?
- Linux is in a constant state of change.
A slick program like this takes many man hours to develop. Due to the constant changes done to Linux, developers not only have to do all the effort involved with developing their program, but also have to expend a lot of effort keeping track of every single change to the Linux distributions thrown their way.There is a lot of excitement in the Linux community about getting the latest distribution of (Debian/RedHat/SuSE/Slackware/whatever). This excitement oftentimes results in neglect of older, oftentimes more stable releases of Linux systems.
To RedHat's credit, RedHat still supports releases as far back as RH5.2, in the sense they still releases security upgrades for RH5.2. About a year ago, RedHat silently stopped releasing security upgrades for RH4.2. Since I still run a RH5.2 server (too far away and too mission-critical for me to conveniently upgrade), I dread the day no more security patches are made available for RH5.2.
I know that the people at Linux Weekly News have been making somewhat of a stink over the fact that Debian announced that they would not make available security patches for 2.1 bugs immediately after releasing Debian 2.2.
Anyway, the point being: The "latest and greatest" is not always the best solution.
- Sam
The secret to enjoying Slashdot is to realize that it should not be taken too seriously.
Did anybody see the licensing on this? Read on...
12. Access to the ADUVA Server
Aduva provides at present free of charge access to the ADUVA Server and to the
ADUVA KNOWLEDGE BASE. Aduva may charge in the future for access to the ADUVA
Server and/or the ADUVA KNOWLEDGE BASE. The information and/or any other data
received from the ADUVA Server is the sole property of Aduva and is protected
by copyright and other rights.
I wonder if they have a privacy policy...
--
Give a man a match, you keep him warm for an evening.
Give a man a match, you keep him warm for an evening.
Light him on fire, he's warm for the rest of his life
Unfortunately, all the Linux package managers (apt/dpkg, rpm, etc) lack one vital feature that all the big guys (IBM, Sun, HP) have included for years - the ability to install, but not commit a package.
One of the things "enterprise" Unices have is the ability to upgrade a package, while the system backs up your old package. If the package upgrade breaks something, it's simple to roll back to the prior state. If everything goes OK, it can be run through it's paces for a while, and then eventually "committed", whereby the old information is deleted.
Until some flavor of Linux adds this to their package management, Linux WILL NEVER be able to take over the corporate world (yeah, there's a lot of other things it needs to, like 32-bit UIDs and a journaling filesystem, but at least they're on their way).
This program is just one of many coming out lately that does the same error as Microsoft: Merging functionality and user interface. A package tool should consist of either one (or both) of a) a library b) a command line tool. Merging UI and functionality makes it very hard to change the UI (bringing it to a web-based administration, automation, etc) in the future, if needed.
Unfourtunately, this have been done a lot lately, mainly by KDE developers (No offense, you make a really good GUI, and some really nice functionalities, but could you please separate the two?):
* KMail have functionality to download mails and filter mails to different mailboxes (It should have used fetchmail and procmail for that, and provided only a graphical configuration tool for those two backends).
* QT contains both basic datastructures (Linked lists, hash-tables, etc) and GUI widgets (Buttons, listboxes, etc). In GNOME, those two parts are separated in Gtk+ (GUI widgets) and glib (basic datastructures).
* KDE contains a virtual filesystem that enables the user to transparently use files on remote sites using any KDE application. This functionality should have been in the operating system filesystem layer (There are several projects to achive this (portable): Podfuk, Alex, etc) VirtualFS), since as it is now, only KDE applications benefit. Here I might add that GNOME are unfourtunately heading for the same, developing the gnome-vfs (which stems from the Midnight Commander VFS).
--The knowledge that you are an idiot, is what distinguishes you from one.
It will be skinnable in newer versions
I really hope that by "skinnable" you mean that it will use the widget set that your window manager & desktop environment provides, or at the very least provide that as an option.
That last thing in the world we need are 500 "desktop-ready" applications, each with their own skin format. I already use four different applications that have separate theme formats: XMMS, Nautilus, Mozilla and gkrellm. Combined with GTK and Sawmill, that's 6 different theme formats I have to keep track of. (Well, that's kind of a lie; I have Mozilla installed so I can use Galeon...)
I don't need a themeable package manager, ICQ client, mailreader, image editor, web server, and SETI@Home client. Desktop environments provide those widget sets for a reason...
Jay (=