Bittorrent, for example, can integrate seemlessly through the web. This kind of file sharing would be very hard to stop--- to the point where the RIAA would have to crack down on search engines.
Cleartype looks like shit with CRT monitors. It was developed for LCD monitors. Assuming that you have one, have you tried enabling a form of sub-pixel hinting under XFree 4.2, whether it be RGB, BGR, or the vertical variations of such. These are, like cleartype, meant for usage on LCD monitors.
> I guess perhaps TightVNC is better over ADSL connections, but remote guis will always be painful over those kind of things, might as well stick to the command line.
TightVNC is perfectly usable for ADSL connections. There is no problem using it from a "typical" ADSL line (such 128 kbit upload.) I routinely use tightvnc even from dialup (vncviewer in dialup, vncserver on a machine with a fat pipe.. the opposite couldn't be done.) It's usable, but is painful (especially the latency). I only usually use it for monitoring things anyways.
As for LANs, you're right that VNC is not as efficient as X, but using the RAW protocol in VNC fixes many of the latency issues with LANs.. it use very large amounts of bandwidth, but this shouldn't matter anyways with a lan.
> Basically yes - it's not uncommon to see machines dedicated to serving up individual applications, rather than entire desktops. The useful thing about X network transparency is that it acts at the windowing level.
> win95 runs on a 386 with 8mb ram if you push it.
I used XFree86 3.0 back in 1994 on my Compaq DeskPro 33 (386dx @ 33mhz).. I forgot how much memory it had, but I suspect either 8 or 12 mb.
It's still sitting in my closet:-)
Re:The problem of rewriting/forking XFree
on
XFree86 Politics
·
· Score: 1
> With the current X11R6 standard comming out 1996 I keep wondering how many of todays cool new applciations will actually work on a server offering only what is part of the standard from back then...
Where are you getting this from? The current standard (6.6), came out in 2001.
> but after using emacs for a while, I realise how much I miss stuff like typeahead find, registers (for text, not just positions), instant splits and so on.
Why not just use emacs on windows?
> or gtk-html genereated docs are far easier to read than stuff on MSDN, which invariably only looks good on huge screens (with IE of course).
I've have to agree.. gtk's API references are far easier to read than most stuff on MSDN. However, MSDN has nice search facilities that makes it easy to find stuff however.
> But it's not just QT it is the whole KDE architecture.
The core kdelibs are pretty evenly split between kdecore (non UI classes) and kdeui. This has been the case since around KDE 0.6 or so.
The other libs in kdelibs (i.e, kjs) are also pretty much non-UI related. Some of course, like khtml, serve both functions, but for sanities sake, I don't think khtml sould be split between khtmlui and khtmlcore:)
Harmony is pretty dead... if you want to see how dead it is, go to the old kde-freeqt mailing list here . Hasn't had messages since Nov 2000, and hasn't really been active since around March 1999.
Focus following mouse always has bothered me to a point where its the first thing I turn off if it's on by default.
I've used MacOS since 1985, started using Windows around 1993, and the Linux Desktops around 1999, so it's pretty well ingrained behavior in me and at least 90% of the world's users.
However, almost 95% of what Glib does is already handled by Qt (and in some places, in a more natural manner, such as QObject vs. GObject)
Qt provides the same easy ways to use C strings as glib does.
Anyways, aRts uses glib because it wants to be somewhat desktop agnostic. GNOME would probably never want to depend on Qt (it's GPL'd, not LGPL'd)
Anyways, either way you look at it, depending glib on kde causes perhaps unnecessary dependancy bloat, and depending qt on gnome would do the same thing.
HOWEVER, I think that glib and Qt are both widespead enough that it doesn't really matter.
> Just think of a console program using container classes from qt - it has to be linked to the libqt, containing all the qt stuff (GUI etc.). Because the ld.so doesn't load the whole stuff, this doesn't mean that this is harmless. C++ container classes just don't have anything to do with GUI classes.
Uh, you missed a serious point. kbabel is a strings translation app used primarily by developers and translators. "the average computer user" will likely never use it anyways.
Slashdot Mirror
File Sharing/p2p is becoming more and more novel.
Bittorrent, for example, can integrate seemlessly through the web. This kind of file sharing would be very hard to stop--- to the point where the RIAA would have to crack down on search engines.
Yes, those indeed look very nice. What fonts are you using?
Cleartype looks like shit with CRT monitors. It was developed for LCD monitors. Assuming that you have one, have you tried enabling a form of sub-pixel hinting under XFree 4.2, whether it be RGB, BGR, or the vertical variations of such. These are, like cleartype, meant for usage on LCD monitors.
I don't think redhat wants some award from a yahoo geocities-based page. haha
fuck you, bitch.
/me thinks you need to releive your repressed sexual energy somewhere. And please wipe off your keyboard afterwards, thanks.
Anyhoo, replace "LGPL" with "GPL" in your post, and you're going in the right step.
> Someone tell me how this post got +3 informative, just by saying "yep"??
yep.
> Because of the viral licensing in the LGPL, they have to have a compatible license for their browser components.
This is not true at all for the LGPL. Things that wrap around the LGPL code do NOT have to be under a compatable license (unlike the GPL)
khtml is LGPL'd
> Last I checked, GPL'd code cannot link to or be linked to from a non-compatible licensed program.
yep.
> Though it might be the case anyway since I'm pretty sure KDE is LGPL, not GPL
yep, kdelibs (including khtml and kjs which Apple use) are LGPL.
> I guess perhaps TightVNC is better over ADSL connections, but remote guis will always be painful over those kind of things, might as well stick to the command line.
TightVNC is perfectly usable for ADSL connections. There is no problem using it from a "typical" ADSL line (such 128 kbit upload.) I routinely use tightvnc even from dialup (vncviewer in dialup, vncserver on a machine with a fat pipe.. the opposite couldn't be done.) It's usable, but is painful (especially the latency). I only usually use it for monitoring things anyways.
As for LANs, you're right that VNC is not as efficient as X, but using the RAW protocol in VNC fixes many of the latency issues with LANs.. it use very large amounts of bandwidth, but this shouldn't matter anyways with a lan.
> Basically yes - it's not uncommon to see machines dedicated to serving up individual applications, rather than entire desktops. The useful thing about X network transparency is that it acts at the windowing level.
But you can do that with WindowsXP off-the-bat.
> win95 runs on a 386 with 8mb ram if you push it.
:-)
I used XFree86 3.0 back in 1994 on my Compaq DeskPro 33 (386dx @ 33mhz).. I forgot how much memory it had, but I suspect either 8 or 12 mb.
It's still sitting in my closet
> With the current X11R6 standard comming out 1996 I keep wondering how many of todays cool new applciations will actually work on a server offering only what is part of the standard from back then...
Where are you getting this from? The current standard (6.6), came out in 2001.
Try metrox from metrolink and the server from xi graphics.
> The most "painful" part for me in using KDE, which I love, is the initial startup
Do you use prelink at all? Much of KDE's startup costs are not related to KDE at all. Some (but not all), is fixed with prelink.
> but after using emacs for a while, I realise how much I miss stuff like typeahead find, registers (for text, not just positions), instant splits and so on.
Why not just use emacs on windows?
> or gtk-html genereated docs are far easier to read than stuff on MSDN, which invariably only looks good on huge screens (with IE of course).
I've have to agree.. gtk's API references are far easier to read than most stuff on MSDN. However, MSDN has nice search facilities that makes it easy to find stuff however.
>Oh, a decent command line is useful too.
indeed.
> With the terrible legacy DOS support in XP for things like games you are almost forced to run them emulated in linux (dosemu, etc..
:)
Or you can use doxbox, which, in my experience, works better than dosemu for old dos games. And it runs on XP natively
> But it's not just QT it is the whole KDE architecture.
:)
The core kdelibs are pretty evenly split between kdecore (non UI classes) and kdeui. This has been the case since around KDE 0.6 or so.
The other libs in kdelibs (i.e, kjs) are also pretty much non-UI related. Some of course, like khtml, serve both functions, but for sanities sake, I don't think khtml sould be split between khtmlui and khtmlcore
> Plus you'd be introducing a C++ requirement into GNOME
so? libfam is already C++, and epiphany is also (from what I've heard, it might be in gnome soon),
Harmony is pretty dead... if you want to see how dead it is, go to the old kde-freeqt mailing list here . Hasn't had messages since Nov 2000, and hasn't really been active since around March 1999.
Focus following mouse always has bothered me to a point where its the first thing I turn off if it's on by default.
I've used MacOS since 1985, started using Windows around 1993, and the Linux Desktops around 1999, so it's pretty well ingrained behavior in me and at least 90% of the world's users.
However, almost 95% of what Glib does is already handled by Qt (and in some places, in a more natural manner, such as QObject vs. GObject)
Qt provides the same easy ways to use C strings as glib does.
Anyways, aRts uses glib because it wants to be somewhat desktop agnostic. GNOME would probably never want to depend on Qt (it's GPL'd, not LGPL'd)
Anyways, either way you look at it, depending glib on kde causes perhaps unnecessary dependancy bloat, and depending qt on gnome would do the same thing.
HOWEVER, I think that glib and Qt are both widespead enough that it doesn't really matter.
> Just think of a console program using container classes from qt - it has to be linked to the libqt, containing all the qt stuff (GUI etc.). Because the ld.so doesn't load the whole stuff, this doesn't mean that this is harmless. C++ container classes just don't have anything to do with GUI classes.
:)
There is always TinyQ(t)
But anyways, repeat after me: Qt is not a GUI toolkit, but an application toolkit
Uh, you missed a serious point. kbabel is a strings translation app used primarily by developers and translators. "the average computer user" will likely never use it anyways.