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.
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
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)
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...
Change 'em, then complain...
kenneth
... sometimes I fly with the white swan to my Liffey home.
...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.
TWW
"Encyclopedia" is to "Wikipedia" what "Library" is to "Some people at a bus stop"
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?
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.
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
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.
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.
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.
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
The 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.
>Easy. Slackware has no package management system
>to speak of.
Last I heard, the definition of a "package management system" does not list a dependency system as a mandatory requirement. It is a feature of Slackware.
(I'm a Debian user, but I'm equally comfortable with Slack.)
>What's there has no dependency system, (which
>drove me to Debian). Tools like this are totally
>dependant on underlying package management
>systems, and tgz doesn't cut it.
Would it be better to say, that dependency system is required for the tool to run, and tgz is "not compatible"? Lacking a dependency database does not make it "not cut it".
By the way, is there a dependency system that does not keep track of a database? Instead, how about one that looks for stuffs on your machine in real time? e.g. use 'ldd' to search for installed libraries and 'which' to search for installed executables.
Although I don't know what to do with version numbers, does ELF provide a facility to store (a non-strippable) version numbers directly into the executable? If so it'd be great. Just like the version resources of Windows programs. One of the few features that I like. Another being the concept of the "Program Files" directory.
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.
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.
Ummm, this is pretty serious in my books. Admittedly, I haven't downloaded this yet, but if true then Ximian is ignoring a growing base of people that use Linux with X other than XFree. What about those running Xig, or (as in our case) the wonderfully stable and robust HP X? This package would be useless to me if it insisted on installing XFree...anyone verified this?
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...
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.
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..
It's not YAPM in that sense. It interfaces with your distribution's existing package management system, presenting a uniform interface to it regardless of whether you're using Debian, Red Hat or SuSe while at the same time giving you various extra features that you may (or may not) need. It's not a replacement for RPMs or Debs, it's a replacement for things like dselect.
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.
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.
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?
> 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.
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
* 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
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.
Any sufficiently advanced technology is indistinguishable from a rigged demo
--Andy Finkel (J. Klass?)