Well, not so fast. Most people seem to think that the dependencies in a package system are there only to be overridden by some command line switch. News flash: they exist for a reason.
For example, glib is included in Ximian Gnome, a package upon which a lot of other packages (i.e. programs) depend upon (for actual functionality!). If you want to remove the Ximian version of glib, you need to replace it with the RH (or whatever distro's) version. Simply removing it will break your system.
So my advice is to remove all Ximian packages that no packages but other Ximian packages depend upon, until you have a very short list left (glib, gtk and probably a few others), and then make sure that you have the corresponding RH rpm's in place and do an "rpm -Uvh --force" on those packages. That way you are minimizing the risk of breaking your system.
One way could be to "rpm -qa |grep ximian > ximian_rpms", edit out glib, gtk and other rpm's that affect non-ximian packages, and then "rpm -e ximian_packages". Finally, apply the replacement procedure described earlier. That being said, I _really_ think there should be an easier way provided by Ximian for example, that automatically re-installs the distro-specific rpm's.
Hmm...I am pretty sure that a configure script can figure what $KDEDIR is, which sets the prefix (to/usr) and then libdir/bindir/whateverdir is set according to that. So actually the only thing you need to do is "./configure". Couldn't be simpler.
Sooner than you might think, actually. In KDE3 there is a section in KControl which lets you configure Xft stuff, such as "exclude range" of fonts to AA, and an "enable subpixel hinting" checkbox.
The "major version update" refers to the distribution as a whole, i.e. 6.x -> 7.x or 7.x -> 8.x. Even though 2.95 -> 2.96 is a minor version increase of the package gcc, it breaks binary compability, and thus the major version number of RH is increased. I did not say that "when a package that breaks binary compability increases its major version number by one, the distribution also increases its major number by one", but rather "when binary compability breaks (for what ever reason) , the major version number of the distribution is increased by one".
Check your facts:
gcc 2.96 (RH 7.0) is not binary compatible with 2.95 (RH 6.2). Also, glibc 2.1.92 (pre-release of 2.2) is not binary compatible with 2.1.3.
Follows the pattern quite well.
Actually, I am pretty sure the next RH release will be 8.0. The RH release policy is to increase the major number when binary compability breaks, something that is closely linked to the glibc and gcc packages. If you look in Rawhide, you will notice that glibc is 2.2.90 (pre-2.3-release) and gcc is 3.1-0.x (pre-3.1-release), both of which break binary compability with the 7.x releases.
It does not load fine even in Opera 6.0 tp2. Opera doesn't hide the part of the list that you're supposed to scroll to make visible. Look at it in Mozilla and compare.
Speed is not everything. KHTML seems to have problems with layers - check this page out. There's supposed to be a scrolling menu on the upper right, which does not show at all in Konqueror. Opera also has problems with that page. It may be poorly written JavaScript/DHTML or something, I don't know.
It's just my experience that Gecko is more advanced than KHTML in terms of standards compliance/technology support.
One thing that I really would like to see is a better integration of Gecko in Konqueror. I know it's already possible to switch rendering engine, but it's highly unstable in my experience.
Now here's an example of an area in which many of the largest open source projects (Mozilla, GNOME, KDE) could collaborate, benefit from each other's work and find a common standard - the HTML rendering engine. Imagine the Konqueror, Galeon, Mozilla and Nautilus teams putting their efforts behind Gecko development...it would be one important step towards a more unified Linux desktop. Unified as in common standards and shared components, not unified as in lack of choice.
Well, Nvidia's drivers seem to be able to lock up the system hard - even beyond the Alt+SysRq magic sometimes. I guess that's due to the "NVdriver" kernel module being inside protected memory space.
I think it' s a very useful feature, at least when you have the freedom to choose between tabs and new windows (unlike Opera).
A few issues though:
1. There should be a way to jump between tabs using keyboard shortcuts - Next/previous tab.
2. The closing cross button as well as the page scrollbar disappears when you open more tabs that there is room for in the main window. Not good idea - they should always be present.
3. If you open tabs a described in section 2 above, and close enough to make them fit inside the main window again, the rightmost tab's shadow will have disappeared.
Think I'll post the above as bugs/whishes when I get around to it.
I can't believe no one has pointed this out...well anyway:
Debian is three distros, not one.
1. Stable: Most things are a year old, but more or less bug free. Probably the most stable (GNU/)Linux distro available.
2. Testing: Comparable to most ordinary distros, reasonably recent software although quite stable.
3. Unstable: Development version. _Very_ recent material, 5 min behind Freshmeat.
So you have choices within the choice. Debian is not old. Debian stable is old (but reliable).
I'm not sure how hard it is to get the actual code these days, but I thought this might be a good opportunity to spread it a little. I'll put a tarball up on my machine for a couple of hours. Don't wanna get sued;-).
I can see before me a slightly modified version of the James Hetfield - Lars Ulrich (of Metallica) flash movie circulating a couple of months ago, only with Bill Gates screaming "Money GOOD - Open Source BAD!"
Re:Half the ram and twice as fast?
on
Mozilla 0.9 Out
·
· Score: 1
Well, if you remove half the ram you should get a 20% decrease in performance, not 25%.
Start with memory amount M, double it to 2M and get 1.25 the performance (25% gain), then remove half of that back to M and return to performance 1.0, which is a 20% loss.
Slashdot Mirror
...when 1.0 is actually released:
"Today's headlines: Mozilla releases 1.0, reports of flying pigs, hell freezes over. Film at 11."
Well, not so fast. Most people seem to think that the dependencies in a package system are there only to be overridden by some command line switch. News flash: they exist for a reason.
For example, glib is included in Ximian Gnome, a package upon which a lot of other packages (i.e. programs) depend upon (for actual functionality!). If you want to remove the Ximian version of glib, you need to replace it with the RH (or whatever distro's) version. Simply removing it will break your system.
So my advice is to remove all Ximian packages that no packages but other Ximian packages depend upon, until you have a very short list left (glib, gtk and probably a few others), and then make sure that you have the corresponding RH rpm's in place and do an "rpm -Uvh --force" on those packages. That way you are minimizing the risk of breaking your system.
One way could be to "rpm -qa |grep ximian > ximian_rpms", edit out glib, gtk and other rpm's that affect non-ximian packages, and then "rpm -e ximian_packages". Finally, apply the replacement procedure described earlier. That being said, I _really_ think there should be an easier way provided by Ximian for example, that automatically re-installs the distro-specific rpm's.
Hmm...I am pretty sure that a configure script can figure what $KDEDIR is, which sets the prefix (to /usr) and then libdir/bindir/whateverdir is set according to that. So actually the only thing you need to do is "./configure". Couldn't be simpler.
Sooner than you might think, actually. In KDE3 there is a section in KControl which lets you configure Xft stuff, such as "exclude range" of fonts to AA, and an "enable subpixel hinting" checkbox.
The "major version update" refers to the distribution as a whole, i.e. 6.x -> 7.x or 7.x -> 8.x. Even though 2.95 -> 2.96 is a minor version increase of the package gcc, it breaks binary compability, and thus the major version number of RH is increased. I did not say that "when a package that breaks binary compability increases its major version number by one, the distribution also increases its major number by one", but rather "when binary compability breaks (for what ever reason) , the major version number of the distribution is increased by one".
Check your facts: gcc 2.96 (RH 7.0) is not binary compatible with 2.95 (RH 6.2). Also, glibc 2.1.92 (pre-release of 2.2) is not binary compatible with 2.1.3. Follows the pattern quite well.
Actually, I am pretty sure the next RH release will be 8.0. The RH release policy is to increase the major number when binary compability breaks, something that is closely linked to the glibc and gcc packages. If you look in Rawhide, you will notice that glibc is 2.2.90 (pre-2.3-release) and gcc is 3.1-0.x (pre-3.1-release), both of which break binary compability with the 7.x releases.
It does not load fine even in Opera 6.0 tp2. Opera doesn't hide the part of the list that you're supposed to scroll to make visible. Look at it in Mozilla and compare.
Speed is not everything. KHTML seems to have problems with layers - check this page out. There's supposed to be a scrolling menu on the upper right, which does not show at all in Konqueror. Opera also has problems with that page. It may be poorly written JavaScript/DHTML or something, I don't know.
It's just my experience that Gecko is more advanced than KHTML in terms of standards compliance/technology support.
One thing that I really would like to see is a better integration of Gecko in Konqueror. I know it's already possible to switch rendering engine, but it's highly unstable in my experience.
Now here's an example of an area in which many of the largest open source projects (Mozilla, GNOME, KDE) could collaborate, benefit from each other's work and find a common standard - the HTML rendering engine. Imagine the Konqueror, Galeon, Mozilla and Nautilus teams putting their efforts behind Gecko development...it would be one important step towards a more unified Linux desktop. Unified as in common standards and shared components, not unified as in lack of choice.
my GOD that's almost the exact same setup as I run at work! spooky...only I run ns6.2 for browsing.
* * *
Well, Nvidia's drivers seem to be able to lock up the system hard - even beyond the Alt+SysRq magic sometimes. I guess that's due to the "NVdriver" kernel module being inside protected memory space.
I think it' s a very useful feature, at least when you have the freedom to choose between tabs and new windows (unlike Opera).
A few issues though:
1. There should be a way to jump between tabs using keyboard shortcuts - Next/previous tab.
2. The closing cross button as well as the page scrollbar disappears when you open more tabs that there is room for in the main window. Not good idea - they should always be present.
3. If you open tabs a described in section 2 above, and close enough to make them fit inside the main window again, the rightmost tab's shadow will have disappeared.
Think I'll post the above as bugs/whishes when I get around to it.
Does this release compile with gcc 3.0.x? And what about the RH/MDK 2.96 line?
I can't believe no one has pointed this out...well anyway:
Debian is three distros, not one.
1. Stable: Most things are a year old, but more or less bug free. Probably the most stable (GNU/)Linux distro available.
2. Testing: Comparable to most ordinary distros, reasonably recent software although quite stable.
3. Unstable: Development version. _Very_ recent material, 5 min behind Freshmeat.
So you have choices within the choice. Debian is not old. Debian stable is old (but reliable).
How the fsck did that post get score 2 anyway?
I have now taken down the link. Will shut down webserver in a while as well.
Ok, I located the missing tarball, so go get it while you can. Also, the DeCSS mp3 is available :-).
ARGH! Seems I've lost the source...damn it! Don't download that link, it's just some windoze binaries. Sorry.
I'm not sure how hard it is to get the actual code these days, but I thought this might be a good opportunity to spread it a little. I'll put a tarball up on my machine for a couple of hours. Don't wanna get sued ;-).
It's kernel, not kernal.
Interesting link.
I can see before me a slightly modified version of the James Hetfield - Lars Ulrich (of Metallica) flash movie circulating a couple of months ago, only with Bill Gates screaming "Money GOOD - Open Source BAD!"
Well, if you remove half the ram you should get a 20% decrease in performance, not 25%.
Start with memory amount M, double it to 2M and get 1.25 the performance (25% gain), then remove half of that back to M and return to performance 1.0, which is a 20% loss.
...the software industry? They are the ones that write code, right?
What about dpkg -l somestring? It lists every package that is available in your distro-of-choice and matches the regexp "somestring".