Slashdot Mirror
Ximian's Red Carpet Released
Red Carpet Release Info, from Ximian You have waited frothingly in anticipation. You have endured a perpetual release date of "two more weeks." You may have, in a senseless act of anxiety over this amazing work of art, even whispered the "V"-word[1] under your breath. You have tormented the developers on IRC. You have begun the chanting. You have burned towns. You have seized ships and blockaded ports.
Red Carpet is here.
Red Carpet is the next generation Ximian updater and software management application. Based around the concept of "channels," or content groupings, Red Carpet will be able to present you with a virtually endless array of software for your GNU/Linux and Unix systems. In addition to just updating packages already installed on your system, Red Carpet allows you to install new software and remove existing software. Red Carpet operates seamlessly with your existing packaging tools on both RPM and dpkg-based systems, giving you a consistent interface for managing your software on any Linux distribution. And, with DepTricketyTrackTrackTronixTron 9000, our amazing dependency and conflict resolution system, the nightmare of dependencies all but vanish from your life. Rejoice.
We will now move into the question and answer section of our release announcement:
Q. Is this a beta? 0.9? What's going on here? Where am I? Why am I wearing a clown wig?
A. With our best efforts we have tried to find every bug, duplicate every
dependency situation, become one with both RPM and dpkg, and click on
everything rapidly and repeatedly. However, we are most ashamed to admit
that we did not discover every possible bug, could not duplicate all of the
horrors that are your packaging database, failed to achieve spiritual
enlightenment, and simply cannot click as fast as you can. As a result,
we present this application to you in beta form. Frankly, we want you to
do thangs to it. You find bugs, we'll fix em.
Q. How do I get it?
A. Binary packages for Red Hat 6, Red Hat 7, and Debian GNU/Linux systems are
available now through the Red Carpet mirror in the Ximian GNOME Updater.
For Debian users, add this line to your /etc/apt/sources.list:
deb ftp://spidermonkey.ximian.com/pub/red-carpet/binary/debian-22-i386/ ./
You can also get them, as well as the source tarball, from
ftp://ftp.ximian.com/pub/red-carpet. Because we're in the process of
moving our office and we overwork our build people, binary RPMs for the
remainder of our supported Linux distributions will be available a little
later. Sorry.
Q. Okay, I've got it. Now what?
A. Give it a whirl. You can find Red Carpet from the Programs->System menu
on the foot launcher or on the top menu bar. After it downloads all of
the channel bar, you should probably verify that your system's dependencies
are fulfilled by choosing "Verify Installed Packages" from the File menu.
After that, go buck wild. Subscribe to channels, install new software,
check out our totally l33t About page, whatever you want.
Q. "I found a bug" or "Red Carpet sucks! How do I tell you how bad you suck?"
A. In the unlikely event that you find a bug, please submit them to the Ximian
bugzilla at http://bugzilla.ximian.com. We've created a public mailing
list, red-carpet@ximian.com, for you to tell us exactly how much we suck.
Or rule. We're ready for it. We can take it. You can subscribe to it at
http://lists.ximian.com/mailman/listinfo/red-carpet. By the way, help
control the pet population: have your pets spayed or neutered.
Q. Tell me more about channels.
A. That's not really a question, but I would be happy to. With channels we
are able to provide you with a much wider variety of software and in a
much cleaner way than what was possible with our old updater technology.
Channels can be subscribed to selectively, meaning that you only ever
receive information on updates of software that interest you.
Q. So, uh, does that mean it'll update my distribution, too?
A. Oh yeah. Red Carpet detects what distribution you are running and
presents a channel of it, with all of the updates issed from the vendor.
Red Carpet can install any software on your system, as long as there's a
channel for it. In essence, Red Carpet becomes the central point for
installing, updating, and managing software on your computer.
Q. What about package signing and verification?
A. You'll want to install GnuPG to verify package signatures. We have
included the public keys for Ximian, Red Hat, Caldera, TurboLinux,
Mandrake, and SuSE. Most distros provide them these days. If you don't
have it, Red Carpet will still run fine.
Q. Does this replace the Ximian GNOME Updater?
A. Because this is a beta, we don't want to prevent people from updating
their system in the event that it breaks. As Red Carpet is an infinite
improvement over the old updater that we introduced in March 2000 in
every way, it will replace the Ximian GNOME Updater at some point in the
future. In the meantime, however, they should both work.
Q. You broke my Evolution snapshots. What the hell? A. Sorry bout that. It was necessary to eliminate a pointless dependency on Red Carpet. Your Evolution will be broken until you install new snapshots (which should be built tonight). Look on the bright side, though, you'll be able to install those snapshots with Red Carpet! Sweet!
Q. Who worked on Red Carpet?
A. Red Carpet is the result of months of work by the following people:
DEVELOPERS:
Ian Peters
Joe Shaw
Vladimir Vukicevic
CONTRIBUTORS:
Jacob Berkman
USER INTERFACE DESIGN:
Anna Dirks
ARTWORK:
Tuomas Kousmannen
Jakub Steiner
In addition, many thanks go out to Larry Ewing and Radek Doulik for their work on GtkHTML, on which Red Carpet heavily relies. They've had to deal with our constant pestering in addition to those of the pesky Evolution developers. All too often our conversations went like this:
"Dude, there is a bug in GtkHTML."
"That isn't a GtkHTML bug."
"Yeah dude, it is.
"Dude, no it isn't."
"Dude, it is."
"No, dude, it isn't."
Pause.
"Hmm. You're right, it isn't. Sorry, dude."
Thanks, guys. We're dorks.
Lastly, special thanks go out to Matt Wilson, who, aside from his help, plain and simply totally rules.
Q. How many inside jokes are in this release announcement?
A. I quit counting around eight. Joe Shaw, however, will give one hundred
AMERICAN dollars to the first person to identify all of them and their
origins.
[1] Vapo(u)rware.
What I think he means is; stuff from the base-system (like telnetd, inetd etc.) cannot be upgraded using the ports-system. But that's not
what the ports-system is about. If you want to upgrade/patch stuff from the base-system, you can easily do that via cvs. Just checkout the new version of telnetd, and compile and install it.
--sn0w
Thanka for making the point - I didn't have the time time to illustrate the full sequence.
.Deb specific. You could install Conectiva or the Mandrake 8 beta, both of which are APT based RPM distributions.
But APT isn't Debian or
I know that - but that isn't what the error message says, which was what I was originally posting about. The original message implied (to me anyway) that it wouldn't install that package because of the package version (i.e. the software within it). It's a crappy error message.
Anyway - firmly off the beaten track now.
"don't fall into the fallacy of believing that Perl can solve social problems. Maybe Perl 6 can, but that's a ways off"
Read the press release and the web page moron.
It specifically mentions this, you have an inconsistent RPM database, so some dependancies could be stuffed.
I'm me. I think.
All you people complaining about minor updates requiring the removal of great swathes of your systems, did you even read the press release and the posts on news.gnome.org from the developers, and the red carpet web site.
This is a known problem, not with Red Carpet but with your package databases (specially the RPM one), thats why they tell you to verify installed dependacies before you do anything else.
once I got rid of the problems in my rpm db (double installs of auth_ldap and kdesupport, which RC detected and told me there were problems with), RC worked perfectly, cept for some issues of crashing when installing the RPMS but that was a gal issue.
I'm me. I think.
Hey what ever happened to those goat pictures? we got em still on soul, right? :)
Mike Roberto
- GAIM: MicroBerto
Berto
Ummm, call HP and ask to purchase their Visualize Linux workstations. :) It was a very smart move on their part - it's easily the most stable X/OpenGL that I have personally run on Linux. Definitely faster than XFree and more powerful in the OpenGL dept. Obviously ported from their HPUX.
It runs *instead* of XFree, and we use these workstations to make money, so if some update app refuses to work unles we use XFree(which apparently isn't the case - thank's Joe!), then we can't use it. The HP Visualize stations start with a standard Redhat install, then install their X over top. Believe me, when you're in the high end - all the "cool" stuff XFree provides is meaningless when you're looking for serious OpenGL performance. The Mesa guys are the first to admit that - it's not in that league yet.
Red Carpet is not a complete platform installation updater, but rather only for one version of the GUIs supported. M$, inspite of my intense dislike for them, deserves credit here: their updater updates most of the platform in one updater: quite slick and very time- and error-saving. Now if it just compiled from source each time ;-) When is the Linux vendor community going to quit their package wars and band together to help make Linux easier to install. HINT: start with XFree86!
Somebody's got to pay the Akamai bills. None of us can afford to do it alone!
On the other claw, Ximian could use Skycache/Sidera for their web caching, since they use linux & netbsd instead of the proprietary code that Akamai is built around... I don't know what the billing & performance differences are.
--Charlie
Your criticism is interesting, but unfounded. The FreeBSD ports system does maintain version information in the package database, represented in the filesystem as the /var/db/pkg heirarchy. Also, you can query the package versions through the "pkg_version" command. There's also a way to use the pkg_version command to automatically update any ports that are out of date, or to list all the installed packages.
Since each installed port has an entry in the packages database, ALL the package management tools work well with ports. For example, you can use pkg_delete to cleanly uninstall a port in a way which will track dependencies.
To be honest, I tend to access the raw filesystem directly more often than I use the various pkg_* commands. For example, seeing what version of qmail I have installed is as simple as "ls -d /var/db/pkg/qmail*",
My one concern with all these kinds of systems is infrastructure. For one, I can remember when getting an RPM from redhat.com was a pain because they didn't have their mirror's set up and their ftp site was getting hammered all the time, but I'm not really concerned about scalabilty bottleknecks, that's really just relationship building and it sounds like you have a lot of friends. ;) What I'm more concerned about is "channel" maintenance and what the chain is for that?
Does channel == ftp server?
Who maintains that channel?
What would be a reasonable timeframe to expect an update to a channel in the case of say, the bind security problem from a few weeks back?
Too often it seems to me that the web of trust between me as a sys admin and package maintainer x is not as stable as a simple `gpg --verify`. I realize that your updater is probably not geared towards me, but I need to understand the system which I am utilizing before I could consider adding your monkeys to my arsenal.
this space intentionally left blank (oops)
Yeah ok but what about the other stuff on www.ximian.com? Like gnome etc..?
pkg_version -v ouputs something like this (and a whole lot more of this):
screen-3.9.8_3 needs updating (index has 3.9.8_5)
sox-12.16 needs updating (index has 12.17.1)
tcl-8.3.1 * multiple versions (index has 8.0.5,8.2.3,8.3.1)
tiff-3.5.5 = up-to-date with index
As you can see this says enough about versions, and it also tells you what needs an update, and what doesn't...
Er, I have automatic updates. I have dependency tracking. I have channels too - in fact, I update my Helix Gnome regularly using them. It's called apt/dpkg, and it's a standard part of Debian.
Now, a GUI tool for setting up and administering APT could be very cool - I'm not making a CLI vs GUI argument here - but why might I want another system to do basically the same job bolted onto the side? If there are things that Red Carpet does that apt/dpkg doesn't, wouldn't it be best to fix apt/dpkg?
The Helix people know Debian, so I'm sure they've anticipated this question, but I'm surprised not to see it answered here.
--
Xenu loves you!
Red Carpet seems quite interesting... as soon as the Ximian ftp lets me in or if I find a mirror that already has it, I'll try it
I have one simple question though :
This "updater" will update all the Ximian Gnome part of the system (to replace the Helix updater) but also the core of the distribution (Debian users won't be much affected, but RedHat users like me will)... but can it manage other groups of packages???
I'm asking this because I maintain many useful custom RedHat 7 RPMs people really seem to like available from http://redhat.aldil.org/ and it would be great if I could (and others that trust me too of course) put my public GPG key into my Red Carpet and manage all my custom RPMs from it. I'm ready to make xml files describing my packages on my server (if that's how it works) etc. to get things working.
Does anyone know if this would/will be possible? I would be soooo pleased if it was :-)
-- Life wasn't meant to be easy...
That's what I meant. But if I upgrade the base-system using CVS, doesn't this mean, for example, that old files are left lying around, configuration files will be over-written or not upgraded, etc? And that you can't later ask the system, "where exactly did THIS file come from?"
Damn thats an unclear error message then - surely it should read:
only packages with RPM file format version <= 3.x are supported by this version of RPM
or similar? I was looking at the error and thinking but it's 0.something! that's <= 3...
"don't fall into the fallacy of believing that Perl can solve social problems. Maybe Perl 6 can, but that's a ways off"
Nope. You can use 'Mergemaster' for that.
(Simply merge any changes)
Check the FreeBSD handbook on updating your
system...
http://www.freebsd.org/handbook
--sn0w
Change 'em, then complain...
kenneth
... sometimes I fly with the white swan to my Liffey home.
It is beta software. One thing it does is try to update your kernel in RH7, badly. Auto kernel updates are a bad idea, but other than that it does have promise.
...is a superior OS to linux
Friends don't let friends use multiple inheritance.
logan@xxxx:~$ cat /etc/slackware-version
/var/log/packages/sendmail
./sendmail.tgz
7.1.0
logan@xxxx:~$ head
PACKAGE NAME: sendmail
COMPRESSED PACKAGE SIZE: 873 K
UNCOMPRESSED PACKAGE SIZE: 2230 K
PACKAGE LOCATION:
PACKAGE DESCRIPTION:
PACKAGE DESCRIPTION:
PACKAGE DESCRIPTION:
PACKAGE DESCRIPTION:
PACKAGE DESCRIPTION:
sendmail: sendmail 8.11.0.
Might be a bad idea to depend on a company with an equally crappy buisness plan. If you don't think it is a crappy plan, explain how they will ever make enough money to reach the point where they can do research in addition to development.
TWW
"Encyclopedia" is to "Wikipedia" what "Library" is to "Some people at a bus stop"
In debian's aptitude program, you can hit ctrl+c on a package to see it's changelog
Umm.. it's not that they hate slack, but slack does not have much of a packaging system. At least not as sophisticated as apt/dpkg let alone rpm. Hence it makes their jobs harder. I doubt they'll get around it.
I refreshed and saw the text: 0 of 1 comment. ;) I'll say something interesting.
I clicked on the "read more button".
5 comments, 2 below your current threshhold.
Bullcrap.
Anyway, so that I'm not offtopic
Why would we need YAPM (Yet Annother Package Manager)??
At the moment there are RPM's, DEB's (apt) and they are cool enough.. then there's the good old tarballs, and BeOS PKGs', then there's QNX' package manager, and loads of time..
Ok. Anyway.. nice work...
For those using ximian on a debian system know, updating packages can often bork your system because Debian wants you to download debian gnome and I want ximian gnome. Becuase of this, if I don't specify all of the ximian packages over the possible more recent debian packages, the system gets borked. Will RC make sure that it only installs ximian gnome packages, but still install standard debian packages?
I am actually thinking of setting this up after I looked through the website,
does anyone have any expereience with it, and how hard it is to get running? Or is it just one RPM to download and it works?
This is a good tool, but it only hides the problem and doesn't solve it. So now you have one GUI and one tool to keep track of dependencies and get the packages, but you still need the rpm-tools, the deb/apt tools, you have both databases, you need perl for most debs and you need GNOME to use the tool.
Just because I can imagine doing a hippopotamus, doesn't mean I'd like to do it.
All right, now I'm quite convinced. I'm still new to this BSD stuff so I'm happy this got all cleared.
Dependencies of course.
For me: orbit dep liborbit0 (=0.5.3-helix1) but have 0.5.7-1
__
__
Arse
What the hell.
How come ximian doesn't support slackware?
A couple of days ago, KDE people told us that they're also planning on creating their own installer, but since this red carpet is so good, maybe they can become one of the channels on the red carpet installer.
--- Sigmentation Fault - Comments Dumped
Red Carpet owes a lot to WindowsUpdate.
Take a look.
There is one minor difference...
Red Carpet is far less likely to fail installing updates, force you to reboot and corrupt vital system compoents. WindowsUpdate does that flawlessly.
Overall, Red Carpet is far better than the Redhat Update script / wizard, and beats MandrakeUpdate hands down.
IMHO, anyway.
-----
Same here, the weird thing is that it wants to remove only my games and game libraries. I would understand if in the update list there were newer version of quake2, kingpin, or clanlib. But there isn't. Whats the deal? A feature that should be added is the ability to install with out removal. I can't upgrade to Gnome 1.4 using this tool with out removing the above items and everything else in the list. Jim
"Life is art...Paint your destiny"
I updated Gnapster just fine without updating my kernel. It never said I had to do anything with the kernel to install it.
I've got KDE 2.1 beta 2 rpms installed on my box, downloaded from kde.org. RC wants to remove them and install 'official' kde 1.xx rpms from the redhat 6.2 site. And it does not offer me any option to leave those packages alone for a while, and just upgrade the packages that I selected.
What it *should* do is allow me to leave the packages on the system, even if it thinks there are 'newer' or 'better' versions available. Debian allows you to "hold" packages at their current state (installed, not installed, whatever), and takes this hold value into account when calculating dependencies.
If only "common" sense was actually that common...
I had the exact same problem when I went to upgrade screen. Apparently the problem was that I had a duplicate install of Mesa (two different versions, I must have used --force). It probably picked a duplicate to uninstall, and wanted to take every dependency out with it. This happened to be KDE. This also happened with gkrellm -- multiple versions of the same package installed. I removed the duplicate packages manually, and everything worked fine after that.
This is my fault, of course, for using --force and --nodeps which naturally can risk messing up your dependency database. I suspect a machine that uses strictly packages, properly installed (perhaps using Red Carpet from the start) will work great.
One person who replied to you suggested that this was a big anti-KDE conspiracy from Ximian. Please, grow up, people (Macka).
Jason.
I think (but am not sure) that GtkHTML is mostly for standalone applications that want to do slightly fancy things with text. I don't think it's suitable for web browsing at this point.
Though I could be wrong, and often am.
GOAT? they probably will, but mandrake has different packages and dependencies
I don't run into the same problem as you, I've got KDE2.1b2 rpms installed on an RH6.2 system, and RC doesn't say a thing about it. Did you --force any of the installs of the rpms? That's something that RC has trouble with, although I agree that "holding" packages back is definitely a feature worth adding to RC.
Also, you do understand that this does not mean Ximian is trying to remove KDE from your system. This other guy thinks that Ximian is in some plot to remove all KDE rpms from people's systems.
I downloaded it onto my RH7 system and went to the Ximian GNOME Desktop channel. It tells me there is one minor update (a newer version of gdm). Selecting gdm and clicking Update Packages, it tells me it needs to remove autorun, kdebase, kdegames, kdemultimedia, and kdeutils, in addition to needing gimp and kdelibs! Why does it want to remove half of KDE for gdm???
Doesn't some other linux company own the word "red" ?
For instance, consider a financial report with a movable, customizable graph inside it. Very difficult to do with standard HTML. Very easy to do when GtkHTML. As for security, the HTML is locally generated, and the embedded widget is from local code.
Theoretically, you *could* use GtkHTML's abilities to do an ActiveX-like job, but that would be bad practice and no code using GtkHTML does it AFAIK.
Any sufficiently advanced technology is indistinguishable from a rigged demo
--Andy Finkel (J. Klass?)
In my experience, none of the automatic upgrades are entirely reliable. Debian is so dependent on automatic upgrades that packaging bugs get fixed more frequently, but problems occur even with Debian and can be very annoying. I see little reason to upgrade continuously. If it isn't broken, don't fix it.
I'm behind a firewall at work. Those Red Carpet have support for a proxy server?
Think like a man of action, act like a man of thought.
While I'm not saying it will go that far, the logical end point of this might be that you go to a web site, type in the bits and pieces of stuff you want, and have your raw disk image updated regularly. User-visible client-side package management would become irrelvant, you'd be completely dependent on the subscription, and you could forget about CD-ROMs or other disconnected installations.
Yes, some form of convenient download and dependency checking is needed. And both RedHat and Ximian probably have the best intentions. But I'm not convinced that this is the right overall route to go in the long run.
Citing Windows 2000 as an example of an OS with built-in package management is highly misleading. Windows 2000 is just barely a year old and was the first Windows to have anything approximating package management. Their implementation appears to be quite poor. I've heard promises of DLL hell being a thing of the past, but I've seen several Win2K boxes go down in flames running only MS software and maintained by people highly proficient with Windows. (For example on a clean install, VB6 ate SQL7's lunch.)
No, RH and Debian were the first consumer oriented OS's with Package Management (I forget, did BeOS too?).
And what the heck does "bolt-on" mean? On a Linux box, everything is bolt-on except the kernel. A better word is "modular".
---
Very nice, but not for production yet. First thing it wanted when I tried to upgrade minor package on RedHat is to remove all KDE and Mesa installation altogether, without explaining reasons, and there were no way to make it to download that package (which has no relation neither to KDE not to Mesa - it was bind-util) and install it without blowing out half of my system.
So, I know it's beta and it's expected - but don't try it to manage your production sites yet, or you'll be sorry. I hope they'll fix all the things, since the tool is looking very nice and promising and as soon as they will exorcize all devils from all the small things that would be the killer tool.
-- Si hoc legere scis nimium eruditionis habes.
This clashes quite nicely with Eazel's Nautilus Software Catalogue. To quote their page:
So which one of the two options are the distributions like Redhat going to promote? Or will they add a third choice?
Macka
The only reason I am itching to get back into Linux is this
For a windows user - linux install and shit floating everywhere - PAIN IN THE ASS
also
Dude, there is a bug in GtkHTML."
"That isn't a GtkHTML bug."
"Yeah dude, it is.
"Dude, no it isn't."
"Dude, it is."
"No, dude, it isn't."
Pause.
"Hmm. You're right, it isn't. Sorry, dude."
that is fucking funny
The ultimate network admin tool needs HELP!
While I hated Aduva, I like this a lot. It still doesn't update my kernal correctly, but I've mostly stopped trying to update kernal rpm's through package management - it just doesn't work. The main thing that's interesting to me is how they have stated that they will use it to integrate with HPUX and Solaris 8. If I could have one package manager GUI (and I am assuming there is a CLI in there somewhere) to handle all my Linux servers, HPUX machines and Solaris machines... well that would just simply rule. Package managemnt on HPUX and Solaris is a real bitch.
According to the Red Carpet homepage:
If you're an ISV or other software developer, and would like to have your software deployed with a Red Carpet channel, please visit our partners page and let us know.
Following the partners got me to an error page but it's clear that Ximian wants to make money by having people pay for having a red carpet channel.
While I understand that they have to make money somehow, I find it very disturbing that the only way to get my software listed is to pay Ximian or to have it included in all distributions.
Of course the software is GPL'd and it could be hacked to have a "add channel" menu (it would be really cool if clicking a link in mozilla or a file in Nautilus would do this) but such a patch will probably never make it into the distributions.
Monkey sense
The problem with the ports system is the same problem as Slackware has: it works great, it's easy to use, it seems powerful, but it isn't a package management system. Why not?
/var/spool/mqueue
What version of smtp are you running? Well, without version support, it's hard to find out. (You could telnet to port 25 on localhost to find out.) Or, I can type: rpm -q --whatprovides smtpdaemon which tells me: sendmail-8.9.3-20 This gives me a central place to track software versions and dependancies.
And, if I file a mysterious file or directory on my computer, I can find out what it does by asking the package manager! rpm -qf
As you manage more and more machines at the same time, real package management becomes more and more needed. Dependancies are wonderful. Listing all the installed packages are wonderful. Being able to erase a package without a care is wonderful. The ports collection has a long way to go before it can handle these problems. (And, if you just want each package to be compiled from scratch each time, you source RPMs or DEBs.)
This
Redhat Errata
( ED ) Ximian has asked that we include the following to their press release: "ALL YOUR BASE ARE BELONG TO US"
Thank you. Continue on your way. Nothing to see here.
I downloaded this a few minutes ago (installed beautifully through Helix.) Unfortunately, I was afraid to actually install any updated packages, since it listed the install of XFree86 3.3.6 as "necessary" upgrade (makes sense, Gnome without X would be somewhat less useful.)
I don't particularly want to install XFree 3.3.6, though, since I'm currently running 4.0.2 (d'oh! Not installed through packages. In fact, packages weren't available when I installed it.)
I don't suppose anyone out there has any ideas for working around this? Do I list it as a bug, or is the problem between the chair and the computer?
MichaelThe strongest point it has for me is that it works.
The RedHat updater has consistently crashed on my 6.2 workstation every time I have ever attempted to use it, through multiple versions.
Red Carpet worked great first time, and finally updated some things I was deliberately leaving sit (because they weren't vital) until I could hit them with a GUI. I could have updated them manually, but I wanted to test the GUIs more than I wanted them updated.
This is a good program. Anything that makes it easier for my grandma to use Linux means more cheap hardware and more drivers for me.
-
Someone should moderate me down with "offtopic" or something so as not to confuse others.
Guess I deserve to loose a couple of Karma points for jumping in with both feet.
Macka
There is a standard package downloading tool for .deb and .rpm - APT. The Mandrake 8 beta we've been testing for the last month includes it as the common package downloading tool, and it works *really* well.
Sign up to the mandrake-expert list to get details about where to download the ISO images and help test it.
Oh, and re: Red carpet: with any luck, the functionality will be in libso, so if you want scripting, or you're an old-school Unix bearded guy, a command line version shouldn't be too hard.
The big question is: will APT and Red Carpet resolve the installation of a package in a similar way? Will the package repositopries on Ximian match the distribution vendors (likely,, but still important) and (more importantly) the the third party application developers?
Things like Red Carpet (and the older HelixUpdate) really help out new users
Red Carpet might 0Slashdotted so I can't see, and there's no Mandrake version - odd because Mandrake has the highest desktop share according to most surverys but Helix Update definitely did not help out new users.
Because it force installed all its packages. And that *really* pisses a new user off when they find their system refuses to be upgraded because Ximian assumed their own packages would always be better. I'm angry the tool did this, I'm angry they didn't tell anyone, I'm angry about the wasted mailing list time to support the users who had their systems raped by Ximian.
* Mandrake 8 beta does it too
* The tool basically exists because currently there are no quality GUI tools for APT (or DEB or RPM for third-party stuff, for that matter). If nobodies been bothered fopr the last couple of years, chances are they won't be in the future. Most non-Unix/BSD experiences Linux users would avoid remebering command line switches if they have to.
* You could simply take the tool and craft it to use APT as a backend. I think this might be the way to go.
* IT satisfies dependencies by downloading and installing them (if you want). This removes the endless headache of hunting, downloading, and installing that it currently takes to update a single package (Gimp needs newer GTK, GTK needs newer glibc, etc)
* It can easily install multiple RPMS simultaneously - you can't point kpackage at more than one file
* It hopefully doesn't have stupid error messages like "KPACKAGE MUST BE RUN AS ROOT!!!" though it might. If I download it, run it as a regular user, and it gives me this sort of (pardon the language) shit (instead of just asking me for the password) I, like many other users, will uninstall it.
Found it mirrored here... after Ximians download site is not reacting for me anymore.
/ pu b/red-carpet/binary/
/ pu b/red-carpet/source/
u b/red-carpet/binary/debian-22-i386/ ./
Binaries:
http://www.mirror.ac.uk/sites/ftp.helixcode.com
Sources:
http://www.mirror.ac.uk/sites/ftp.helixcode.com
Debian apt sources.list:
deb http://www.mirror.ac.uk/sites/ftp.helixcode.com/p
Have fun.
This shouldn't be that hard to implement. They've made it sound as though it was written to be easily extended.
"Homo sum: humani nil a me alienum puto"
(I am a man: nothing human is alien to me)
My only political goal is to see to it that no political party achieves its goals.
Dude, I've got KDE on my system and RC makes NO attempt to remove it. The only reason RC would try to remove is because the install of KDE was --forced. Try doing a little thinking before you declare war! :(
Aduva was just ludicrous, even when you don't count the fact that it totally screwed up my box.
It was graphically over the top, and the first time I launched it, without any message saying "checking libraries" or something, it took about 10 minutes to launch.
This is sweet, and it's pretty cool that you can use HelixUpdate to install it as well.
While Aduva is far from perfect, my experience with it was not that bad, I was able to successfully update many packages without any major problem . I just hope it will improve in the future. I haven't tested the Ximian Updater yet, but I guess that it will bring more competition, and this good for Linux.
Was it me, or was that one of the cooler release statements. The humor strewn throughout the otherwise informative release statment shows me that, hey, these are just some guys working on a good product. The statement even made fun of themeselves! You don't see that very often. That's the one thing I like most about the hacker culture, is things like this. I just feel comfortable with these people. "Dude, use our new tool! It's cool. Here's why..."
Why on earth are you still using dselect? Pretty much everything you want to do should be covered by apt-get install, apt-get dist-upgrade, apt-get remove, and apt-cache search.
A lot faster, a lot simpler, and much less of a pain.
(occasionally using apt-get autoclean is good to keep the package cache down in size, too)
DNA just wants to be free...
In order to update Gnapster, it requires that I update my kernel!!!! One step closer to Microsoft land!
Like many other good ideas in Gnome they took this from KDE. kfm the KDE1.x file manager used this for html 3 support.
Maybe one day they will switch to the new khtml with gtkhtml and you will be even more amazed. Beats Mozilla most of the time and is improving at high speed.
If you don't believe me look here:
http://cvs.gnome.org/lxr/source/gtkhtml/AUTHORS
--
Moritz
The title said enough...
My problem is with the issue of bolt-on updaters. I personally have used these things before, and I have found that they are more trouble than they are worth.
Define bolt-on. When it comes to Debian, for instance, you're merely replacing the package management utilities that come with the system (dpkg and apt) with another one that uses the same data files. There's no difference in the amount of underlying control over the operating system.
I would not trust my operating system to a third-party updater; after all, given that Unix is a server OS, you should compile from scratch anyway (to ensure maximum speed and so on) - the value of this is limited.
Ah, right - this would explain your confusion. You're missing the point entirely. Many people don't want to have to download and compile every piece of software they want to use. They want to be able to say "I want that" and for it to appear on their machine. This isn't limited to users. I admin over 20 machines consisting of 4 different architectures. If I had to compile everything by hand it would take me forever. However, the wonders of the Debian package management system mean that I can keep them running, up to date and secure while at the same time doing a full-time degree. Package management is a wonderful example of a labour-saving device. Don't knock it just because you're a die-hard "compile everything from source" freak.
If you want this, you should get an OS where this facility is integrated; for example, Windows 2000 now has built-in management and update facilities, and this might be a more appropriate route to take.
Uhm. Linux (in the shape of Debian, Red Hat, Mandrake, Caldera, SuSe, the vast majority of other distributions) is an OS that has had a package management system integrated for several years. The copy of AIX I have here from 1992 had a package management facility. Doing everything the long, hard, painful way for minimal gain is not the UNIX way.
While you nitpick over whether an article 'belongs' on Slashdot or Freshmeat we have SET UP YOU THE BOMB!
You would be wise to MAKE YOUR TIME. Soon you will find that your inattention to your base has brought about your doom.
five bucks says Ximian and Eazel announce a merger within 6 months.
Eazimian? Xeazel?
--
Hemos doesn't want to be among the 25% to be cut. He is trying to get Ximian to buy a banner ad.
Read the release. They say they will release Mandrake binaries (among others) soon.
apt-get install apt-listchanges
Slack does have RPM along with updatepkg (installpkg), why not use the RPM feature of Slack? Also, whats wrong with installpkg? Just curious, Jim
"Life is art...Paint your destiny"
Obviously, the KDE camp can't require use of another desktop environment to maintain its own. However, a KDE installer using the same backend "guts" as Red Carpet or Eazel's updater for its rpm and deb database maintenance and inventorying would be productive, such that the Qt/KDE and GTK+/GNOME/Ximian or Eazel installation systems are interchangeable.
I imagine this would mostly be focused on the login/authentication and subscription management sides of things, since once you're past that, it is mostly leaving things to RPM and dpkg.
The only problem with debian changelogs is that they are by definition, the changelog for the debian package, not necessarily the changelog for the software that the package encapsulates. All too often, the changelog just says "New upstream release", which says nothing about what makes this new release interesting or what could bite you hard.
"A few atoms won't even light a match" - Dr Jones, 1933
im using debian woody and after verifying :(
dependencies, it wants to remove 139 packages
and then trying to upgrade a couple of other
programs, it gives cannot resolve dependencies
crap. maybe i'll use it at work where bandwidth
isn't an issue.
"I keep looking in the want-ads under 'revolutionary' but there don't seem to be any listings.. "
No need to immediately leap to conclusions.
To quote Vladimir Vukicevic off Gnome News: "One of the things that red carpet demands currently is that the database (especially for rpm) be in a consistent state. This is often not the case, especially on systems that have been around for a while."
So if any packages have dependency problems which Red Carpet can't fulfil by installing a necessary package, it instead prompts you to remove them. Which means that if, for example, your installation of QT has a dependency problem (as mine did), you will be prompted to remove most of KDE.
Rather than uninstalling, though, you can just sort out the conflict. In my case the problem was a hand-compiled version of Mesa (for my voodoo card). I should have built an RPM when I compiled it, but a quick rpm --justdb on a generic Mesa RPM left the files as they were but updated the database as necessary. Presto!
(PS Future versions of Red Carpet will tell you more about the nature of the conflicts, and hopefully help you deal with them more constructively)
Which means if you like to stay on the bleeding edge (or help main one of the big packages like GTK+) this won't help you much. It seems to me that package management in general makes maintaining your system much more difficult if you run a non-standard setup. (Not that I'm knocking it; I'd never go back to slakware.)
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
Are you forgetting rpm --rebuild and apt-get --compile source ? Both RPM and deb support compiling source packages.
Here's my DeCSS mirror, where's yours?
Ximian doesn't support Slackware officially because Slackware doesn't have a dependency management system. See the detailed explanation and unofficial workarounds listed at: http://primates.ximian.com~/aaron/slack.html a.
Besides that, the filtering would work better if the editors would respect the topics. I've realized there are certain subjects that cause me to flame uncontrollably (Napster, censorware, patents, Jon Katz) and I've turned off the relevant topics but stories keep streaming through. Like the Napster story under "Money," apparently because Napster is offering money to the record labels.
Well, since installing libgtk1.2-doc removes half your Gnome that's only more than fair ;-P.
Monkey sense
New to slashdot - wanna be Nerd, but dumb as an empty box! Love the banter and learning great stuff. No comments too small / all worthy. Keep talkin.
> Want a GTK+ widget in the middle of your HTML page? Set up a custom tag for it and there you go. No mess, no fuss (well, not quite, but almost), and incredibly powerful .
Didn't we crucify Microsoft for doing exactly this with IE some years back? Not that the tag was terribly nice looking, but the idea was sound. And the controls were even digitally signed. Maybe their fault was the folly of thinking this was appropriate for the public internet, but I remember plenty of people trashed the very idea behind it. Now 5 years later...
--
I've finally had it: until slashdot gets article moderation, I am not coming back.
What a lovely sight it was. "Son," he said "today we will change ourselves despite all logical understanding of the universe. We will use our emotions to overthrow logic and reason, overlooking the fact that regardless of physics and the probability involved, we will "eventually" get it right and mutate." Then he explained his master plan of how, despite the odds and nature involved, one creature would mutate, but yet in a 'safe' way... but with incompatable genes (and often different numbers of chromosomes), yet amazingly another critter of the opposite sex would miraculously mutate in the EXACT same way, in the same area, allowing them to mate and propogate the new species.
One day a monk will, much like a child observes nature, notice the similarities and conclude that because of the similarities that they must of course come from the same base creature. Thus completely ignoring the element of "style" and that even if spontaneous change works, that it would be more logical to realize that it is a pattern of environment and circumstance.
Years later others will find out through science, that this theory is horribly flawed, but yet hold on to it with a Zeal that out does even the most fervent religous fundamentalist.
Yeah...try to compile a rather large package on your 486DX/33MHz box with 8mb of ram..see how long it takes to compile something large, like for example, emacs.
And if you say that you're compiling it yourself so you know its not backdoored, well do you check ever single line of code for backdoors? I didn't think so.
The 'Ports' collection on FreeBSD/OpenBSD/NetBSD, still one of the best working systems! And it works without 'X'. APT from Debian is the next best thing. But the Ports Collection simply rules, never any compile or dependency failures. It's fast, clean AND easy.
Life without the ports-system would suck.
I love my FreeBSD with the Ports system!
--sn0w
If you'd read the announcement, you should have known that no, it is not yet another package manager for a specific environment. It is a package manager that is not restricted to a specific package system (can for instance use both deb's and RPMs), and is not restricted to a specific distribution. As long as there's a channel available for your distribution or environent, you should be able to update almost anything with it.
Even if you are a CLI true believer, tell your friends, co-workers and people on the street that: "Yes, Linux has many graphical updaters. And here is another one". One of the biggest misconceptions about Linux is that it is hard to maintain, "So many packages, so many patches/upgrades. How can I possibly manage this mess?".
Things like Red Carpet (and the older HelixUpdate) really help out new users who just want to be told what to update (and why). HelixUpdate (don't have RC yet :-), shows a list of available updates organised by importance (security fixes, bug fixes, new packages etc) and with brief explanations on what they are for. I don't think there are similar programs for Windows (or Mac?) that let you check for updates, not only for your OS, but other applications as well.
With RC and most under Linux updaters, they provide updates for many common packages so you can update your browsers, irc client and print software all at one go (actual example). If this isn't ease of use, I don't know what is.
====
Codeala - Just another mindless drone
The copy of AIX I have here from 1992 had a package management facility.
That's true. I remember AT&T's UNIX SysVr4 also had a limited package manager called sysadm. That was the whole point of /install and /opt directories on those systems. I don't know how old that release is but its probably at least a decade old.
The clash of honour calls, to stand when others fall.
So if they claim to support all of these distributions, why did they only make RPM's for redhat? I have Mandrake 7.2, and although the rpm would probably work, i'm just going to compile. If they're going to support packages for these systems, you'd expect them to MAKE packages of the updater for them too, no??? At least some .src.rpms, which i can't find either!
Mike Roberto
- GAIM: MicroBerto
Berto
I wish all press releases were like that. Funny, informative and short. I bet the author has read "The Cluetrain Manifesto":
http://www.cluetrain.com/
* IT satisfies dependencies by downloading and installing them (if you want). This removes the endless headache of hunting, downloading, and installing that it currently takes to update a single package (Gimp needs newer GTK, GTK needs newer glibc, etc)
m l is 404 outta order.
:) I'm even building a Debian box here so I can see for myself. In the meantime, I have RPM-based systems to deal with.
And herein lies the value proposition.
The traditional method of keeping your RPM packages updated:
a) keep track of new release announcements
b) find the RPMs for your architecture and distro
c) download all of them, one by one.
d) try to install them
e) find out that the RPMs you just downloaded require package foolib0.6.8, when you only have foolib0.6.7, and have no idea what foolib even is.
f) do an rpmfind search for foolib, finding 0.6.8 RPMs for every distro but yours
g) track down foolib on freshmeat, but find that its info hasn't been updated in 6 months, and the homepage link to some scary URL like http://students.rthu.ru:73473/~bruno/sw/foolib.ht
h) completely kick yourself in the ass for wasting all that time when you type in http://www.foolib.org/ and the RPMs are right there waiting for you.
i) download and install foolib
j) install the other RPMs - the ones you were trying to install in the first place.
The Red Carpet way:
a) select the newly available packages you'd like to install
b) click 'install packages'
Hell yes, that would save me eons of time and endless amounts of frustration.
And yes, I'd pay something like $25/year for such a service.
* Note to Debian evangelists: why yes, I've heard about the wonders of apt-get
--
A big part of the Microsoft bashing came from the lack of security inherent in the scheme. In particular:
l .
1) ActiveX stuff could do whatever it wanted with your machine
2) The digitally signed stuff was a joke at the time. All you had to do was submit a credit card and address, and they'd give you a signature.
3) When someone pointed this out to Microsoft and eventually the Seattle Post-Intelligencer, the response from Microsoft was "The security would be too hard to fix, and we'd like you to meet the Verisign legal team."
Go see Fred McLain's story at http://www.halcyon.com/mclain/ActiveX/welcome.htm
Somehow, I feel like I should expect to meet the Verisign legal team soon. From what I've heard, Verisign has become more careful about the signatures. And as we've all heard, Microsoft still thinks fixing security holes is too hard to be worth the effort (to be worthwhile for their shareholders, of course, since they are publicly held).
-Paul Komarek
IIRC, gtkHTML 2 is based on completely new source code. I did see a preview of it somewhere, but lost it... I'll try and dig it out
This allows your application to define a custom tag for the render to catch and call you - thus allowing your code to use HTML for displaying interfaces with complex parts drawn by custom GTK components. There are no security problems as they cannot be put on the Internet.
What does this do differently than kpackage?
I'm not trying to troll here, I really would like to know.
K45.
This signature has eleven vowels.
One thing that seems to be missing from Red Carpet (as well as any other tool i've used) is a summary of changes between the version installed and the updated version. That would really kick ass.
I suspect you need to count in the "one hundred AMERICAN dollars" too if you want to win the prize. Dunno it's origin and such though. :-(
- Steeltoe
http://www.debunkingskeptics.com/
How about a package management system that compiles everything from source... That's what the FreeBSD ports do, isn't it?
@ .
Any sufficiently advanced technology is indistinguishable from a rigged demo
--Andy Finkel (J. Klass?)