I've been using this at work for a couple months now.
What do you mean by "this"? Sun's GNOME 1.4 packages were just released, that's after all what this article is about. GNOME 1.4 itself has barely been out for a couple of months. Judging from your comment, you could as well be talking about an ancient GNOME 1.2.
It sucks. It's so buggy and incomplete. There are so many problems, like getting multiple monitors working with Gnome, or getting that horrible sound daemon working right. There are so many bugs in the configuration menus for gnome/sawmill that it is rediculous.
Suspicion confirmed. Let me kindly suggest that you update. Sawfish hasn't been called "Sawmill" for a long time now, and it sounds like you are using a very unupdated GNOME 1.2 setup.
It's not surprising. Sun chose to go with a POS enviornment like GNOME that is still very Linux oriented, of course there are a lot of problems with it.
Let me suggest that you update and keep up with the pace of new versions, before calling anything a POS. GNOME is an actively developed desktop environment, contrary to CDE. It changes fast.
By definition, open source has nothing to do with free.
Where's that definition?
There's just plenty of people who don't mind working for nothing. Apple wants to make money, so they'll do that. If you don't like their open source model, then don't help out. There's nothing wrong with companies using open source for profit.
And neither is it wrong with free software companies using free software for profit. There are also a lot of free software companies today selling free software for profit. So I don't understand what you're arguing.
And anyway, darwin is free, which is what's released under Apple's Open Sourece license, so there's no reason why the rest of OSX has to be free (as your post implies).
There has always been a need for free software. That's why we have GNU/Linux today, and lots of companies selling free GNU/Linux distributions.
Oh, and in case you haven't got the point yet, "free" in this context was never about price, it's about freedom. This was what was mentioned in the article, and what you completely failed to realize. I'd recommend reading up a bit on the the definition of free software. There you have a definition.
That's because Ximian/Gnome is and add-on to an existing Gnome installation
Umm, not exactly. You sure can update your existing GNOME installation with it, but you don't have to have an existing GNOME installation: The only prerequirements is an operating system that Ximian supports and a working X.
A word of warning to folks who have been running Ximian/Beta 1.4 stuff on top of RH7. Upgrading to RH7.1 may be a very painful experience for you. My Ximian/1.4/Sawfish environment became increasing unstable after a 7.1 upgrade this weekend, and I ultimately ended up doing a complete reinstall to get the stock Gnome 1.2 stuff on that distro. (This included blowing away any/all GNOME/Ximian/Sawfish settings in accounts.)
Did you try just replacing the Red Hat rep-gtk and librep packages with the Ximian ones? No need to reinstall everything. I did that and suddenly Sawfish worked perfectly again on Red Hat 7.1 with Ximian.
Of course, now I run Ximian GNOME 1.4 on Red Hat 7.1:-)
I'm just interested in the built-for-586 and up stuff.. Maybe RH can generate a 'modern PC'
build?
Optimizing for 586 won't give you anything more than a few percents of performerance boost at the best for most packages. That's not even noticable. What's worse, compiler optimization is often a dangerous business, because you might actually optimize too much and introduce instability. The compiled program might turn up unpredictable under certain circumstances, even if it was fine when everything was normal. So if you care for stability (like all server administrators should do) then you really want to be careful about optimization.
Red Hat doesn't optimize all packages for i586 or above. If you look at the CD, you will find that what they have optimized is where it's really needed and where optimization would really be noticable. I just browsed my CD and some packages that are optimized are packages like the kernel (available in i386, i586, i686 and enterprise flavor, the enterprise kernel is appearantly for systems with more than 4 GB RAM), glibc (called very often, so it makes sense to optimize that), and heavy computational packages like gzip and friends.
The first Red Hat install that works on my desktop is 7.1, because of the lack of support for ATA/66.
You mean the previous lack of support, do you?:-)
I'm glad it works for you now.
Or how 'bout ReiserFS (in since at least 7.2)? Yeah, yeah, we know, it isn't good enough for a production environment. That's why we say it's a good DESKTOP distro. I ain't exactly serving the Yahoo! homepage. The power outage frequency here in SF means that I'm better off taking a little risk with Reiser than sticking with ext2.
I'm not understanding the logic here. Is potential unrecoverable fs corruption better than e2fsck running once in a while at startup? I believe this is even more important for desktop systems, what's on my/home on my desktop is really important to me, but I can't afford expensive backup systems like in "production environments". So avoiding massive data corruption seems important to me in *any* environment.
Why would you try to do a RH 6.2 -> LM 8.0 upgrade on your server? Wouldn't it be better to do a RH 6.2 -> RH 7.1 upgrade?
I'm serious. As other people have pointed out, RH -> LM upgrades are not supported and may not work at all, but RH -> RH upgrades are supported and are at least supposed to work flawlessly. And, for a server, I don't see any reason that makes it worth to switch to Mandrake if you already have a working Red Hat: Red Hat 7.1 and Linux-Mandrake 8.0 are very similar, closer than any other distros.
In the past, it has been posted that Mandrake is "Redhat that works"
I'm curious, what doesn't work in Red Hat?:)
One nice thing with Mandrake vs. Redhat is they are quite good at supporting newer things without breaking old stuff. For example, I have had good USB support in Mandrake using the 2.2.17 kernel. 2.2 didn't have usb support directly. Mandrake backrevved the newer code into it....sweet stuff. Just yesterday I plugged a flash card reader into my USB port, and after probing the appropriate usb-store module (doesn't get done by default), I had a working flash device. That simple!
Uh, Red Hat had 2.2-backported USB with Red Hat 7 too. So it's not exactly an advantage over the other.
FYI, unlike some other companies Mandrakesoft lets people download the ISOs as soon as they are finished.
"Some other companies" being SuSE, eh?:-)
FYI, Red Hat is exactly like Mandrake in this respect, you can get the ISOs immediately when the new release is announced, and have to wait for some weeks if you want to buy the box. I really like that trust in the users.
Re:hmm nice.. now get some work done... right now!
on
Ximian gets new CEO
·
· Score: 2
That's part of why there is an incitive to start the GNOME Packaging Project. That way there can be official GNOME binary packages. Read the link for more info.
Umm, why should Red Hat be fixing problems in Java for Sun? Isn't that Sun's job?
After all, this doesn't affect only Red Hat, this affects all that is Linux, so I think it says more about Linux not being Sun's Tier 1 Java platform (even Sun have admitted in the past that their main Java platform is Windows, so no wonder).
It is available today, from the Red Hat ftp site and mirrors.
I believe the april 24th date only applies to boxed versions. Red Hat is kind of different from distros like SuSE in this apspect; with Red Hat the isos are made available immediately after a new version is announced and weeks before you can buy it in the shop, with SuSE you have to wait for weeks after it is available in the shop to be allowed to download it.
So why did you put the new gcc in a 2.2.x distro, stupid?
gcc is used for more than compiling kernels. Appearantly Red Hat believed that fixing a lot of bugs and brokeness with gcc 2.95.2 was worth the hassle of having to ship another compiler for compiling the 2.2 kernel (which also was broken).
We hear on IRC all the time "I just installed gcc but./configure tells me it can't make executables", we reply "install glibc-dev", they reply "I have glibc", we reply "install glibc-dev", they reply "fuck this, I'm going to use Windows..."
Tell them to install the gcc errata update and/or get the fixes for the program that they are compiling that compiles with more standards-compliant compilers (if the maintainer is unwilling to fix his program if it's his code that's broken, well, that is obviously not an option).
Or how about the guy the other day who chose the "Start with a graphical login" option, yet his X was not configured so he couldn't login until we showed him how to use runlevel 1 to change his default runlevel.
AFAIK, he couldn't have chosen "Start with a graphical login" without being presented with the graphics settings and ignoring them...
Y'all try to get all fancy and Windows-like, yet just end up making things a lot more confusing and complicated.
I'm sorry you feel that way. I don't. I enjoyed Red Hat 7 very much and deeply appreciate the work Red Hat has done for the free software community.
No, Red Hat always makes the isos public on the ftp servers and mirrors the same day a new release is announced, even if you can't buy it in a shop for another week. At least, that's the way it has always been.
So this is kind of different from SuSE, where you can never download an iso until weeks after the announcement and when it has been availiable in shops for quite some time.
I'm not sure what you refer to as "the 7.0 debacle", but if you do a new install of Red Hat 7.1, you get an iptables firewall (you can choose "high", "medium" or "no firewall" in the install, or customize the choices).
Yeah, we know. Red Hat can't even keep their dirty hands out of the linux kernel source tarball. They're not as bad as SuSE in that fashion (screwing with the 'make config' script to compltely foul up certain options- the 'we know better than you' bullshit), but they're pretty close.
So what is your suggestion? Should they ship a kernel in their distro with known bugs, when they instead could easily fix it by applying a patch?
If you want a pristine kernel, download one from kernel.org yourself or rebuild the kernel source rpm with whatever options you want. If you want a stable and well-tested kernel that works well with your distro and is built with the necessary options,
use the kernel that comes with the distro. If you want to know what changes were made, just read the documentation for the kernel source rpm.
Don't confuse your distro with kernel.org; they fill different purposes. kernel.org has to distribute pristine kernels, but they can have serious bugs, that's not their problem. Your distro on the other hand does not have to ship pristine kernels, but they should not contain any serious bugs and it's their problem to make sure it doesn't.
As fas as i know even RedHat distributes many "not so easyly trustable" RPMs with its distribution all the time.
Thank god i am using slackware and compiling from source!
Do you have specific examples? I know that Red Hat takes great care of all packages on the main Red Hat CD:s, and make all of them themselves. I believe the Powertools CD:s are the exception, but I think it's explicitly stated that those are from third parties.
One annoying thing with prepackaged software is that it's hard to mix it with stuff you compile. You'll either have to compile everything from scratch or use nothing but binary packages.
Why? Dependencies. For instance, if you're trying to install GTK as a RedHat package, but you've already compiled GLIB using the source. Now, the GTK package won't install because it can't find GLIB in its "registery" (shudder)...
It's not a "registry", it's the rpm database. Yes, rpm tries to solve dependencies, and no, it doesn't include some obscure logic to figure out what you have compiled and installed on your own on your system and what belongs to what of that. So it has to trust its own database over installed packages.
If you find it annoying that rpm tries to maintain dependencies, there's a very elegant solution: create your own packages. This will require some basic knowledge about rpm, but the advantage is clear. You just have to make an additional step when compiling your software, but it will keep rpm happy, and you can actually make use of the rpm system: Removing software will be a lot easier, and you won't accidentally break something because you removed software that other software depended upon, just as an example.
Slashdot Mirror
Except that they are not forking. Read the article.
What do you mean by "this"? Sun's GNOME 1.4 packages were just released, that's after all what this article is about. GNOME 1.4 itself has barely been out for a couple of months. Judging from your comment, you could as well be talking about an ancient GNOME 1.2.
It sucks. It's so buggy and incomplete. There are so many problems, like getting multiple monitors working with Gnome, or getting that horrible sound daemon working right. There are so many bugs in the configuration menus for gnome/sawmill that it is rediculous.
Suspicion confirmed. Let me kindly suggest that you update. Sawfish hasn't been called "Sawmill" for a long time now, and it sounds like you are using a very unupdated GNOME 1.2 setup.
It's not surprising. Sun chose to go with a POS enviornment like GNOME that is still very Linux oriented, of course there are a lot of problems with it.
Let me suggest that you update and keep up with the pace of new versions, before calling anything a POS. GNOME is an actively developed desktop environment, contrary to CDE. It changes fast.
That said, it's better than CDE.
Now that's what I call an understatement.
Where's that definition?
There's just plenty of people who don't mind working for nothing. Apple wants to make money, so they'll do that. If you don't like their open source model, then don't help out. There's nothing wrong with companies using open source for profit.
And neither is it wrong with free software companies using free software for profit. There are also a lot of free software companies today selling free software for profit. So I don't understand what you're arguing.
And anyway, darwin is free, which is what's released under Apple's Open Sourece license, so there's no reason why the rest of OSX has to be free (as your post implies).
There has always been a need for free software. That's why we have GNU/Linux today, and lots of companies selling free GNU/Linux distributions.
Oh, and in case you haven't got the point yet, "free" in this context was never about price, it's about freedom. This was what was mentioned in the article, and what you completely failed to realize. I'd recommend reading up a bit on the the definition of free software. There you have a definition.
Umm, not exactly. You sure can update your existing GNOME installation with it, but you don't have to have an existing GNOME installation: The only prerequirements is an operating system that Ximian supports and a working X.
Did you try just replacing the Red Hat rep-gtk and librep packages with the Ximian ones? No need to reinstall everything. I did that and suddenly Sawfish worked perfectly again on Red Hat 7.1 with Ximian.
Of course, now I run Ximian GNOME 1.4 on Red Hat 7.1 :-)
Optimizing for 586 won't give you anything more than a few percents of performerance boost at the best for most packages. That's not even noticable. What's worse, compiler optimization is often a dangerous business, because you might actually optimize too much and introduce instability. The compiled program might turn up unpredictable under certain circumstances, even if it was fine when everything was normal. So if you care for stability (like all server administrators should do) then you really want to be careful about optimization.
Red Hat doesn't optimize all packages for i586 or above. If you look at the CD, you will find that what they have optimized is where it's really needed and where optimization would really be noticable. I just browsed my CD and some packages that are optimized are packages like the kernel (available in i386, i586, i686 and enterprise flavor, the enterprise kernel is appearantly for systems with more than 4 GB RAM), glibc (called very often, so it makes sense to optimize that), and heavy computational packages like gzip and friends.
You mean the previous lack of support, do you? :-)
I'm glad it works for you now.
Or how 'bout ReiserFS (in since at least 7.2)? Yeah, yeah, we know, it isn't good enough for a production environment. That's why we say it's a good DESKTOP distro. I ain't exactly serving the Yahoo! homepage. The power outage frequency here in SF means that I'm better off taking a little risk with Reiser than sticking with ext2.
I'm not understanding the logic here. Is potential unrecoverable fs corruption better than e2fsck running once in a while at startup? I believe this is even more important for desktop systems, what's on my /home on my desktop is really important to me, but I can't afford expensive backup systems like in "production environments". So avoiding massive data corruption seems important to me in *any* environment.
No, it has been that way for several years now. I believe it started with 6.0.
I'm serious. As other people have pointed out, RH -> LM upgrades are not supported and may not work at all, but RH -> RH upgrades are supported and are at least supposed to work flawlessly. And, for a server, I don't see any reason that makes it worth to switch to Mandrake if you already have a working Red Hat: Red Hat 7.1 and Linux-Mandrake 8.0 are very similar, closer than any other distros.
I'm curious, what doesn't work in Red Hat? :)
One nice thing with Mandrake vs. Redhat is they are quite good at supporting newer things without breaking old stuff. For example, I have had good USB support in Mandrake using the 2.2.17 kernel. 2.2 didn't have usb support directly. Mandrake backrevved the newer code into it....sweet stuff. Just yesterday I plugged a flash card reader into my USB port, and after probing the appropriate usb-store module (doesn't get done by default), I had a working flash device. That simple!
Uh, Red Hat had 2.2-backported USB with Red Hat 7 too. So it's not exactly an advantage over the other.
"Some other companies" being SuSE, eh? :-)
FYI, Red Hat is exactly like Mandrake in this respect, you can get the ISOs immediately when the new release is announced, and have to wait for some weeks if you want to buy the box. I really like that trust in the users.
That's part of why there is an incitive to start the GNOME Packaging Project. That way there can be official GNOME binary packages. Read the link for more info.
Although this probably isn't the answer you wanted, use Galeon. It really gives a GTK+ look-and-feel to Mozilla :-)
After all, this doesn't affect only Red Hat, this affects all that is Linux, so I think it says more about Linux not being Sun's Tier 1 Java platform (even Sun have admitted in the past that their main Java platform is Windows, so no wonder).
Maybe because gcc 2.96 is a better compiler? Bero has a page that you might want to check out.
Even with text mode installation (type "text" and then enter instead of just pressing enter at the first screen)?
That's for the ordering of the boxed sets. You can download the isos immediately (if you don't mind crowded mirrors).
Umm, gcc 2.95.3 was released like, six months later? How would they include that? They don't have time machines, do they?
I believe the april 24th date only applies to boxed versions. Red Hat is kind of different from distros like SuSE in this apspect; with Red Hat the isos are made available immediately after a new version is announced and weeks before you can buy it in the shop, with SuSE you have to wait for weeks after it is available in the shop to be allowed to download it.
gcc is used for more than compiling kernels. Appearantly Red Hat believed that fixing a lot of bugs and brokeness with gcc 2.95.2 was worth the hassle of having to ship another compiler for compiling the 2.2 kernel (which also was broken).
We hear on IRC all the time "I just installed gcc but ./configure tells me it can't make executables", we reply "install glibc-dev", they reply "I have glibc", we reply "install glibc-dev", they reply "fuck this, I'm going to use Windows..."
Tell them to install the gcc errata update and/or get the fixes for the program that they are compiling that compiles with more standards-compliant compilers (if the maintainer is unwilling to fix his program if it's his code that's broken, well, that is obviously not an option).
Or how about the guy the other day who chose the "Start with a graphical login" option, yet his X was not configured so he couldn't login until we showed him how to use runlevel 1 to change his default runlevel.
AFAIK, he couldn't have chosen "Start with a graphical login" without being presented with the graphics settings and ignoring them...
Y'all try to get all fancy and Windows-like, yet just end up making things a lot more confusing and complicated.
I'm sorry you feel that way. I don't. I enjoyed Red Hat 7 very much and deeply appreciate the work Red Hat has done for the free software community.
So this is kind of different from SuSE, where you can never download an iso until weeks after the announcement and when it has been availiable in shops for quite some time.
I'm not sure what you refer to as "the 7.0 debacle", but if you do a new install of Red Hat 7.1, you get an iptables firewall (you can choose "high", "medium" or "no firewall" in the install, or customize the choices).
So what is your suggestion? Should they ship a kernel in their distro with known bugs, when they instead could easily fix it by applying a patch?
If you want a pristine kernel, download one from kernel.org yourself or rebuild the kernel source rpm with whatever options you want. If you want a stable and well-tested kernel that works well with your distro and is built with the necessary options, use the kernel that comes with the distro. If you want to know what changes were made, just read the documentation for the kernel source rpm.
Don't confuse your distro with kernel.org; they fill different purposes. kernel.org has to distribute pristine kernels, but they can have serious bugs, that's not their problem. Your distro on the other hand does not have to ship pristine kernels, but they should not contain any serious bugs and it's their problem to make sure it doesn't.
Do you have specific examples? I know that Red Hat takes great care of all packages on the main Red Hat CD:s, and make all of them themselves. I believe the Powertools CD:s are the exception, but I think it's explicitly stated that those are from third parties.
Why? Dependencies. For instance, if you're trying to install GTK as a RedHat package, but you've already compiled GLIB using the source. Now, the GTK package won't install because it can't find GLIB in its "registery" (shudder)...
It's not a "registry", it's the rpm database. Yes, rpm tries to solve dependencies, and no, it doesn't include some obscure logic to figure out what you have compiled and installed on your own on your system and what belongs to what of that. So it has to trust its own database over installed packages.
If you find it annoying that rpm tries to maintain dependencies, there's a very elegant solution: create your own packages. This will require some basic knowledge about rpm, but the advantage is clear. You just have to make an additional step when compiling your software, but it will keep rpm happy, and you can actually make use of the rpm system: Removing software will be a lot easier, and you won't accidentally break something because you removed software that other software depended upon, just as an example.