Anyways, to my main point. You're *still* going to have dependency problems. This isn't a magic wand. It works well in Debian because a) there are hundreds of mirrors, they all carry the exact same packages, and they're all administered with a decent degree of competence. And b), the Debian packagers *care*. The packages install so easily because, generally speaking, Debian Developers arn't lazy. In fact, following the Debian Policy(a big reason why packages under Debian install and work so well) is actually kind of a pain in the ass. But it's still followed.
Yeah, apt-get is great. But it's just a tool to deal with packages. If the packages it's dealing with are crap, then it won't help you one lick. Most Debian Developers take care of a *single* package. There is a decent minority that takes care of a number of packages each, and there are a very very few that take care of dozens of packages each. And these people *use* their packages; they use the apps they package, they use Debian, they use their Debian packages.
Can you say all that about Red Hat? How many thousands of packages do they have, and how many package maintainers? A few dozen? Full-time? That's being optimistic. You're still looking at a stunning lack of man-power(when compared with the alternatives).
It would surprise me if there are any "unmaintained" packages in any major distro, since if it's not maintained and not used, there is no point in including it and thus wasting CD space for it. So I think it's safe to assume that each package has a maintainer. Also, Red Hat surely has more than "a few dozen" developers. If you take a look at people.redhat.com you'll find lots of more or less well-known Red Hat developers. All in all, 150 people are listed.
I also counted all the binary RPM packages included on the two installation CD's of the Red Hat Linux 7.2 release. There are 1232 of these packages.
This gives us an average of roughly 8.21 packages per maintainer. deno was so kind as to provide statistics for Debian in his comment where he gets an average of 9.16 binary packages pro Debian maintainer.
So, on an average, the Red Hat maintainers appearto have to care about slightly fewer packages pro person than their Debian collegues.
This also reflects my personal experience. The Red Hat packages are of high quality. Everything you said about the Debian packaging can most likely be said about the Red Hat ones too. No serious distribution would ship packages in their distro that were untested and not carefully packaged according to a package quality plan. I have trouble remembering any packaging error with any package included in Red Hat Linux.
The packages that don't come from any Linux distribution though sure often match a lot of what you described. In fact, mot problems I've heard about bad RPM packages involved one or more of the following:
User used package intended for another distribution than the one used
User used package intended for another major version of the distribution than the one used
User grabbed package from "somewhere on the net", not reflecting too much about where it came from or the quality of the package
User compiled and installed some of the package's dependencies from source, and wonders why the package manager doesn't find them
User fetched the package from the distribution's bleeding edge repository and didn't pay too much attention to warnings
...and so on. Maybe I'm exaggerating a bit, but in my experience it usually is either pilot error or low-quality packages fetched from somewhere on the net, and eventually all gets blamed on RPM or the distributor.
If these features matter to you, a good way to make the chance that they get implemented bigger would be to report them at GNOME Bugzilla (please check that they haven't been reported before, only one feature per bug report, try to be simple and conscise, etc.)
My experience is that the Galeon hackers are very much listening to feature requests, but those should really be reported in Bugzilla so that they can be tracked.
Gnome probably needs the users testing it out and giving feed back
True for the coming beta releases probably, but this is a platform alpha release and not intended for end users, as several people have already pointed out.
It's intended for developers that want to be able to port their applications to the GNOME2 platform (or develop new ones on GNOME2) more easily, that's all. There are very few actual end user applications that have already been ported. The panel is one of the few ones.
If it was only to play catchup with version numbers, it would have already been GNOME 3.0. But we don't do that game.
The truth is that this is a major change/rewrite of the platform, which requires a new major version number (2.0). It is nothing like the 1.x platform (and requires porting of applications), and labelling it 1.x.something would thus be very confusing.
Use SuSE. It has great Spanish support from what I've seen. As for setting it up, you can change the language *after* installation, too, I believe.
So does Red Hat Linux too... and it wouldn't surprise me if also Mandrake Linux had it. Spanish is a big language, and most of the well-known distributions prioritize support for Spanish. So you should really make the distribution choice mainly for other reasons.
I agree. Gnome on Solaris is slow. This is a Sunblade as well. Last night I was bored and installed Debian unstable on it though. Interestingly enough, Gnome is quite a bit faster now (and Naultilus doesn't crash nearly as much). So maybe the boys at Sun are doing something wrong..
It's all about versions. Sun's preview release of GNOME is outdated. Debian's version of GNOME and included software is updated continously. Ximian's version too, but their Solaris version is also outdated, it's the GNU/Linux versions for popular distributions that are updated the most.
In particular Nautilus has had lots of performerance fixes lately. So what the Sun boys are doing "wrong" is not updating their preview to be in par with the latest state of the art.
"Linux" isn't all that much better, since it's also not pronounced as it's written in English
I'm curious, why is it that all names in the world should have to be pronounced as they are written in English?
That's the impression I get from your comment. Sorry in advance if I misinterpreted something.
3. Embrace and extend. RedHat has positioned itself to be the high-market-share distro. However, RedHat intentionally releases broken standards (RH 7's egcs for one?)
Red Hat 7 doesn't use egcs. If you meant gcc-2.96-rh, you should probably have a look at http://www.bero.org/gcc296.html
for lots of reasons why gcc 2.96 could be a good choice.
and moves things around in such a way that if a software developer writes a program to be installed on a RedHat Linux system, it won't install on any non-RedHat-based distribution.
Red Hat 7 and later plays rather nicely with FHS...
If it does install, the crazy egcs release will keep it from running on the new machine.
Use binaries compiled for the platform you're using, or compile yourself. Complaining that some binary compiled for JoeRandomsDistro won't work with your Red Hat install isn't very relevant, IMHO.
RedHat often screws with things like init scripts just enough to make them UNIX-like, but to break POSIX standards.
Examples?
What pisses me off about RedHat is how deliberate their embrace-and-extend design policies are. I don't recommend RedHat for anything, because learning the quirks of RedHat puts users into bad practices of using their proprietary tools
What proprietary tools exactly? Red Hat doesn't do proprietary tools.
or expecting the proprietary behavior of their tools to be standard cross-platform.
A behavior cannot be proprietary (unless it's patented), afaik.
It's sort of like how a lot of linux distros have a 'route' command that, for some reason, won't accept 'route add -net default' (which is standard across UNIX) but will accept 'route add default gw'... annoying.
It's not free software. As far as I understand it, it puts restrictions on how this software can be used, which is against one of the basic free software freedoms.
I thought RH and Ximian were playing nicely together. Hopefully this is something that will be sorted out before the final release, but it does not look that way from the comments in the release note.
I don't think it amounts to that they "are not playing nicely together". I don't believe there's any secret agenda regarding this or some intentional incompabilities.
Really, I think it's just basic design decisions and different playing fields. Ximian is a "desktop distro"; what they are doing is packaging one desktop, but for multiple operating systems and GNU/Linux distributions. They make design decisions in packaging and packaging policies based on how smooth it will work with all the distributions they have decided to support, with all the differences in package managers, distro packaging policies, included software, etc. Red Hat on the other hand have to make design decisions on how changes in packaging will affect upgrades and the like from previous releases, which is a different thing. I also think Red Hat should be allowed to continue using their packaging policy and what solution they believe is best, regardless of what other packaging schemes other unrelated companies have invented.
So really, I don't think there's anything to worry about. Ximian made a decision to build a complex product on top of Red Hat (and that in fact replace parts of Red Hat), and so they are the ones that will have to update. And given that they are usually fast in supporting the latest release, I don't think there's much to worry about. Ximian has a policy though not to support beta distro releases though, so you'll have to wait until after the official Red Hat release for updates from Ximian.
Can you explain how to access the GUI frontend to do this. What's the name of the program and is it installed by default?
The default file manager in GNOME is called Nautilus, you'll find it in the GNOME foot menu (or just double-click the home icon on the desktop), and yes, it is installed by default if you do a default GNOME install.
Umh, does rpm fetch your package from the server and isntall it for you? It is still a pain in the ass to go download the rpm yourself and worry about whatever depends you might have to go back to the server for. apt-get install package does it all.
$ up2date <package>
will download and install <package> and its dependencies for you.
Seriously, that was pretty fuckin' uncalled for. I don't care how insecure RH may be out of the box compared to some other distros, but shit, Linux is Linux, right? You have to secure every distro, and AFAIK, none of them ship with a chrooted apache, bind, and sendmail (or better yet, qmail or postfix). Gimme a break.
True. Anyone who thinks that Red Hat nowadays would be any more insecure out of the box than any other Linux distro is out of touch with reality. IMHO, of course, but really, in the end they run mostly the same deamons, and all sane distros, Red Hat inclusive, don't install network-listening deamons by default, but rather a firewall.
Earlier I tried a build somebody did using some sort of Xwindows-MSwindows thingy, like cygwin/wingtk, but I honestly don't remember where I got it. I scanned it pretty hard for virii, I remember, so it probably didn't come from the Galeon site... it was even more broken than the linux version (which was massively unstable at the time) and I couldn't get it to do anything but crash.
Well, sounds like there's your problem. If you want to try Galeon out, I'd recommend a tested platform and official binaries, or compile it yourself. I'd never believe any binary, from an unknown source, compiled for an unsupported platform with the help of XX unstable compability libraries, would be anything but very unstable and hardly usable.
I hate the idea of having newsgroups and Email integrated into the browser, I want fast tools that do a single job well. But the last two versions of Galeon I tried (using both linux & MSwindows) were so hideously unstable I couldn't really use them.
Umm, I'm not sure Galeon even compiles on Windows (I've never heard of anyone trying to)? Are you sure it was Galeon you tested on Windows, not some other browser?
Besides, I've not had a Galeon crash for ages here, so I believe that you may be using older versions (you don't mention what versions). Also what Mozilla version is installed would be useful information.
RedHat wants a DB. RedHat likes the GPL. There are good, GPL'd DB's available.
Where's the justification for reinventing the wheel?
They are not reinventing the wheel, on the contrary. They are using PostgreSQL as the base, according to the article. They will be putting developers on hacking a version of PostgreSQL (with more features, I suppose) that they can bundle with support and their distribution. If they follow track, their sources will be available from day 0 and patches sent to the PostgreSQL maintainers.
The most advanced Free/OpenSource RDBMS is sapDB. Problem is that sapDB is GPL, and Great Bridge and Red Hat are planning to bring new features and keep it's source closed for a while. In this way they will make money. The plan is not to _fork_ the code but to release the new features _later_ to have a competitive advantage.
First of all, Great Bridge and Red Hat will not be working together. Red Hat will be putting developers on Postgres, but the companies won't be working together. All explained in the article.
Second, I don't see why Red Hat would keep changes for themselves, even for a short time. They're an opensource company, and to this day they have always released source immediately when their products are released. I don't see why that would change. Their patches might not be accepted by Postgres maintainers, but that's another issue that the future will tell. Even then, I'm confident RHDB will be available in source from day 0.
Slashdot Mirror
Yeah, apt-get is great. But it's just a tool to deal with packages. If the packages it's dealing with are crap, then it won't help you one lick. Most Debian Developers take care of a *single* package. There is a decent minority that takes care of a number of packages each, and there are a very very few that take care of dozens of packages each. And these people *use* their packages; they use the apps they package, they use Debian, they use their Debian packages.
Can you say all that about Red Hat? How many thousands of packages do they have, and how many package maintainers? A few dozen? Full-time? That's being optimistic. You're still looking at a stunning lack of man-power(when compared with the alternatives).
It would surprise me if there are any "unmaintained" packages in any major distro, since if it's not maintained and not used, there is no point in including it and thus wasting CD space for it. So I think it's safe to assume that each package has a maintainer. Also, Red Hat surely has more than "a few dozen" developers. If you take a look at people.redhat.com you'll find lots of more or less well-known Red Hat developers. All in all, 150 people are listed.
I also counted all the binary RPM packages included on the two installation CD's of the Red Hat Linux 7.2 release. There are 1232 of these packages.
This gives us an average of roughly 8.21 packages per maintainer. deno was so kind as to provide statistics for Debian in his comment where he gets an average of 9.16 binary packages pro Debian maintainer.
So, on an average, the Red Hat maintainers appearto have to care about slightly fewer packages pro person than their Debian collegues.
This also reflects my personal experience. The Red Hat packages are of high quality. Everything you said about the Debian packaging can most likely be said about the Red Hat ones too. No serious distribution would ship packages in their distro that were untested and not carefully packaged according to a package quality plan. I have trouble remembering any packaging error with any package included in Red Hat Linux.
The packages that don't come from any Linux distribution though sure often match a lot of what you described. In fact, mot problems I've heard about bad RPM packages involved one or more of the following:
My experience is that the Galeon hackers are very much listening to feature requests, but those should really be reported in Bugzilla so that they can be tracked.
What "tricks" are you referring to?
What's the state of UTF-8 support in GNU/Emacs 21? Does this release include UTF-8 support, or is it still in development?
True for the coming beta releases probably, but this is a platform alpha release and not intended for end users, as several people have already pointed out.
It's intended for developers that want to be able to port their applications to the GNOME2 platform (or develop new ones on GNOME2) more easily, that's all. There are very few actual end user applications that have already been ported. The panel is one of the few ones.
The truth is that this is a major change/rewrite of the platform, which requires a new major version number (2.0). It is nothing like the 1.x platform (and requires porting of applications), and labelling it 1.x.something would thus be very confusing.
Could you elaborate on what you feel more integrated with software packages than in RH Linux? I'm curious.
It's not true anymore, and hasn't been for a long time. You don't get any network-enabled services with a default install of Red Hat Linux nowadays.
So does Red Hat Linux too... and it wouldn't surprise me if also Mandrake Linux had it. Spanish is a big language, and most of the well-known distributions prioritize support for Spanish. So you should really make the distribution choice mainly for other reasons.
What isn't secure about the default installation?
It's all about versions. Sun's preview release of GNOME is outdated. Debian's version of GNOME and included software is updated continously. Ximian's version too, but their Solaris version is also outdated, it's the GNU/Linux versions for popular distributions that are updated the most.
In particular Nautilus has had lots of performerance fixes lately. So what the Sun boys are doing "wrong" is not updating their preview to be in par with the latest state of the art.
Yes, Evolution is GPL. I really doubt that will ever change, since a lot of Evolution hackers are really committed to free software.
I'm curious, why is it that all names in the world should have to be pronounced as they are written in English?
That's the impression I get from your comment. Sorry in advance if I misinterpreted something.
Red Hat 7 doesn't use egcs. If you meant gcc-2.96-rh, you should probably have a look at http://www.bero.org/gcc296.html for lots of reasons why gcc 2.96 could be a good choice.
and moves things around in such a way that if a software developer writes a program to be installed on a RedHat Linux system, it won't install on any non-RedHat-based distribution.
Red Hat 7 and later plays rather nicely with FHS...
If it does install, the crazy egcs release will keep it from running on the new machine.
Use binaries compiled for the platform you're using, or compile yourself. Complaining that some binary compiled for JoeRandomsDistro won't work with your Red Hat install isn't very relevant, IMHO.
RedHat often screws with things like init scripts just enough to make them UNIX-like, but to break POSIX standards.
Examples?
What pisses me off about RedHat is how deliberate their embrace-and-extend design policies are. I don't recommend RedHat for anything, because learning the quirks of RedHat puts users into bad practices of using their proprietary tools
What proprietary tools exactly? Red Hat doesn't do proprietary tools.
or expecting the proprietary behavior of their tools to be standard cross-platform.
A behavior cannot be proprietary (unless it's patented), afaik.
It's sort of like how a lot of linux distros have a 'route' command that, for some reason, won't accept 'route add -net default' (which is standard across UNIX) but will accept 'route add default gw'... annoying.
It's not free software. As far as I understand it, it puts restrictions on how this software can be used, which is against one of the basic free software freedoms.
I don't think it amounts to that they "are not playing nicely together". I don't believe there's any secret agenda regarding this or some intentional incompabilities.
Really, I think it's just basic design decisions and different playing fields. Ximian is a "desktop distro"; what they are doing is packaging one desktop, but for multiple operating systems and GNU/Linux distributions. They make design decisions in packaging and packaging policies based on how smooth it will work with all the distributions they have decided to support, with all the differences in package managers, distro packaging policies, included software, etc. Red Hat on the other hand have to make design decisions on how changes in packaging will affect upgrades and the like from previous releases, which is a different thing. I also think Red Hat should be allowed to continue using their packaging policy and what solution they believe is best, regardless of what other packaging schemes other unrelated companies have invented.
So really, I don't think there's anything to worry about. Ximian made a decision to build a complex product on top of Red Hat (and that in fact replace parts of Red Hat), and so they are the ones that will have to update. And given that they are usually fast in supporting the latest release, I don't think there's much to worry about. Ximian has a policy though not to support beta distro releases though, so you'll have to wait until after the official Red Hat release for updates from Ximian.
The default file manager in GNOME is called Nautilus, you'll find it in the GNOME foot menu (or just double-click the home icon on the desktop), and yes, it is installed by default if you do a default GNOME install.
$ up2date <package>
will download and install <package> and its dependencies for you.
True. Anyone who thinks that Red Hat nowadays would be any more insecure out of the box than any other Linux distro is out of touch with reality. IMHO, of course, but really, in the end they run mostly the same deamons, and all sane distros, Red Hat inclusive, don't install network-listening deamons by default, but rather a firewall.
Well, sounds like there's your problem. If you want to try Galeon out, I'd recommend a tested platform and official binaries, or compile it yourself. I'd never believe any binary, from an unknown source, compiled for an unsupported platform with the help of XX unstable compability libraries, would be anything but very unstable and hardly usable.
Umm, I'm not sure Galeon even compiles on Windows (I've never heard of anyone trying to)? Are you sure it was Galeon you tested on Windows, not some other browser? Besides, I've not had a Galeon crash for ages here, so I believe that you may be using older versions (you don't mention what versions). Also what Mozilla version is installed would be useful information.
A new Galeon release, targeted for Mozilla 0.9.2, will be released Monday.
Where's the justification for reinventing the wheel?
They are not reinventing the wheel, on the contrary. They are using PostgreSQL as the base, according to the article. They will be putting developers on hacking a version of PostgreSQL (with more features, I suppose) that they can bundle with support and their distribution. If they follow track, their sources will be available from day 0 and patches sent to the PostgreSQL maintainers.
Go troll somewhere else.
First of all, Great Bridge and Red Hat will not be working together. Red Hat will be putting developers on Postgres, but the companies won't be working together. All explained in the article.
Second, I don't see why Red Hat would keep changes for themselves, even for a short time. They're an opensource company, and to this day they have always released source immediately when their products are released. I don't see why that would change. Their patches might not be accepted by Postgres maintainers, but that's another issue that the future will tell. Even then, I'm confident RHDB will be available in source from day 0.