Uh, what? Moc produces C++ code. This is compiled by *suprise*, a C++ compiler.
> Is it really that difficult to split things out when it makes sense to do so? Why oh why does Qt have to have OpenGL support right there in the same library providing everything else? Why can't there be an extra OpenGL library? Or a PostgreSQL one? Or a MySQL one? Or an image loading library? Or any of all those thing that have *zilch* to do with a GUI.
Qt is not a GUI toolkit, but an application development toolkit. It has been since Qt 2.0 or so, and especially since Qt 3.0.
Developers demand features, and TT gives it to them.
> It has a poor clipboard copy system. It is difficult to take a picture and copy it from one Window to the next or copy elements between Windows. It is not as good as the Windows or the Mac.
xdnd.
> You can compare Free-Civ under X-Windows with Civ 3 under Windows and Free-Civ doesn't have as many features and plus it is limited by X-Windows. Free-Civ is not as graphically advanced as Civ 3. The bells and wistles of the Civ 3 is far beyond Free-Civ under X-Windows.
uh, gee gee, I play civ3 under Linux all the time. Oh wait, I guess X is just to antiquated to play (a somewhat old game) such as civ3 or a (new game) such as ut2k3.
> Isn't it about time that the windowing system was directly implemented into the kernel?
There isn't exactly any performance gains to be had to running X in kernel space rather than user space. On the other hand, there are MANY stability problems that could come from that approach.
> KDE/GNOME are hugely bloated by themselves. Much worse for many programs who use them. I don't know if it's poor design or too many cooks or what, but they suck bigtime.
It's because recent versionf of KDE/GNOME are pretty much made for recent hardware? Why? Because users demand new features.
I ran KDE 1.2 on my PowerPC 603e-based 180mhz Mac Clone fine with 48mb of ram. The PowerPC 603e was one of the slowest PowerPCs ever made, too.
> Admittedly, some features a novel - such as the whole UI-over-TCP thing.
It's not UI-over-TCP, but rather, UI-over-sockets. When running locally, UNIX domain sockets are extremely fast. It's been proven time and time again that the bottleneck isn't there.
That's not too bad.. my X uses over 200 mb of ram with kdm running. Of course, the REAL memory usage of X is something like 11mb. Everything else is cached. Most of that 45 mb is also, perhaps 40 mb of it, in fact.
> Sidebars such as Karamba need to be more useful than just show information. There needs to be a way for a user to interact with the information presented to them. Until that happens they will remain pretty much useless (and off my desktop).
Heh.. that's pretty much the goal of SuperKaramba. Interactive Karamba sensors.
The Opteron will be available in a desktop version. The Xeon is not, and will not be.
That means there is a HUGEEEEEEE difference in price.
Also, every review except for Tom's shows the Opteron beating Xeons in more workstation tests --- Tom didn't enable the second memory channel or use DDR400. Both of which limited performance.
The chip tested was a consumer version of the athlon64 (one memory channel). If it cannot run 32 bit code with any reasonable amount of speed (i.e, faster than AXP and comparable to latest p4's), then the chip is destined for failure.
1. He was talking about window transparency.. read the post next time. 2. While you are correct in saying that Windows does not use OpenGL in compositing windows, much of the theory is the same. Replace OpenGL with the GDI, and you have another interface to graphics-card enabled compositing, abiet a slightly less versatile one.
1. He was talking about Transclucence.. read the grandparent poster's SUBJECT. Windows has supported this since Windows2000. 2. While you are correct in saying that Windows does not use OpenGL in compositing windows, much of the theory is the same. Replace OpenGL with the GDI, and you have another interface to graphics-card enabled compositing, abiet a slightly less versatile one.
> JK2, SoF2, RTCW, and Q3A have a significant performance hit on a modern graphics card
I guess it depends on your definition of modern graphics cards. The aforementioned games are all based on the Quake3 Engine.. which is over three years old now. On modern video cards (as in... GeForce2 and up, or original Radeon and up), all of the games above should run smoothly, unless you are running 1600x1200@32 bit@4x FSAA or something crazy like that.
Anyway, these games pretty much have FPS caps where it's not worth getting more FPS. Q3A, for example, 90% of people have their FPS capped at 125 fps. Why? Because it provides the best strafe jumping physics. SOF2, another example, enforces a FPS limit of 90.
> especially if you're running non-nVidia.
I guess Radeon 9700/9800 owners will have something to say about that!
> there's a lag in any "busy" scenes which just isn't there under Windows.
Um.. I didn't notice that at all with my old system GeForce 3 ti200 (on Athlon 1.4), or my current system gf4ti4600 and Athlon XP 2200+.
> A big deal if you're a hardcore gamer? Certainly.
If you are a hardcore FPS gamer, you probably aren't using high graphics detail anyways. I've been a hardcore competitive gamer since 1998 or so (went Quakeworld->Quake3...), and almost everyone in the hardcore competitive scene uses r_picmip 3 or higher, very low res, vertex lighting, etc..
> I am just wondering if we will ever get the performance we get with games under windows
With most games yes.
> I know that they have a couple games ported
More than just a few games work in winex:)
> like FPS where framerates are so important.
Yep.. games based on slightly older engines, such as the quake3 engine (rtcw, moh, jk2, sof2), and Halflife (Counterstrike)... pretty much run at the same speeds in WineX and WIndows already.
What would be interested to see is how new games such as bf1942 run on it.. bf1942 is cpu/gfx card intensive, and doesn't run nateively in Linux (unlike ut2k3..)
> Now flame me if i am wrong, but doesn't wine work on some sort of Virtual Machine, thus adding an extra layer between the hardware and the code?
No... wine is an implemenation of the Windows API.
What incentive do these game developers have in using those cross platform API's rather than something WAY more tested in the real world such as.. uhm... DirectX?
> Anyway, as I've stated elsewhere, you're ignoring the fact that Linux does have games.
Slashdot Mirror
> C++ _compiler_ doesn't know about that moc POS)
Uh, what? Moc produces C++ code. This is compiled by *suprise*, a C++ compiler.
> Is it really that difficult to split things out when it makes sense to do so? Why oh why does Qt have to have OpenGL support right there in the same library providing everything else? Why can't there be an extra OpenGL library? Or a PostgreSQL one? Or a MySQL one? Or an image loading library? Or any of all those thing that have *zilch* to do with a GUI.
Qt is not a GUI toolkit, but an application development toolkit. It has been since Qt 2.0 or so, and especially since Qt 3.0.
Developers demand features, and TT gives it to them.
> "American dream?" I was under the impression that KDE was largely a European effort.
Sure is, but there are plenty of developers outside of Europe these days (e.g, a lot more in North America.)
> It has a poor clipboard copy system. It is difficult to take a picture and copy it from one Window to the next or copy elements between Windows. It is not as good as the Windows or the Mac.
/disaster.html.
xdnd.
> You can compare Free-Civ under X-Windows with Civ 3 under Windows and Free-Civ doesn't have as many features and plus it is limited by X-Windows. Free-Civ is not as graphically advanced as Civ 3. The bells and wistles of the Civ 3 is far beyond Free-Civ under X-Windows.
uh, gee gee, I play civ3 under Linux all the time. Oh wait, I guess X is just to antiquated to play (a somewhat old game) such as civ3 or a (new game) such as ut2k3.
> http://catalog.com/hopkins/unix-haters/x-windows
most of that is old, and depreciated info.
> All the software is designed with absolute positioning of widgets,
Have you used mfc (or atl/wtl/com) within the last ten years?
> The feel of programs is the same
Untrue. You can change quite a bit with Microsoft's Visual Styles in WindowsXP.
> Isn't it about time that the windowing system was directly implemented into the kernel?
There isn't exactly any performance gains to be had to running X in kernel space rather than user space. On the other hand, there are MANY stability problems that could come from that approach.
> KDE/GNOME are hugely bloated by themselves. Much worse for many programs who use them. I don't know if it's poor design or too many cooks or what, but they suck bigtime.
It's because recent versionf of KDE/GNOME are pretty much made for recent hardware? Why? Because users demand new features.
I ran KDE 1.2 on my PowerPC 603e-based 180mhz Mac Clone fine with 48mb of ram. The PowerPC 603e was one of the slowest PowerPCs ever made, too.
> Admittedly, some features a novel - such as the whole UI-over-TCP thing.
It's not UI-over-TCP, but rather, UI-over-sockets. When running locally, UNIX domain sockets are extremely fast. It's been proven time and time again that the bottleneck isn't there.
> Win98SE and Redhat 8 with Gnome
Try replacing Gnome from rh8 (2.0) with KDE 1.2, or GNOME before it hit 1.0. Then compare it to Win98SE.
OR
Try replacing Win98SE with WinXP. Then compare it to GNOME 2.0.
Stop comparing apples with oranges for fuck's sakes.
> Sadly enough, most GUI replacements are mere hacks
Yes, but this is why WindowsXP (or better), has something called Visual Styles. Native themeing, yum. No more hardcoded windows appearance.
> 45 MB for X, whil _only_ xdm is running
That's not too bad.. my X uses over 200 mb of ram with kdm running. Of course, the REAL memory usage of X is something like 11mb. Everything else is cached. Most of that 45 mb is also, perhaps 40 mb of it, in fact.
Uh, difference in clocks speeds DO NOT SCALE LINEARLY in terms of performance. This is true in some instances more than others, of course.
Uh, if you pull the heatsinks off of a Athlon XP 2400+ and p4 2.4, both of them should power down.
I guess you haven't heard that AMD has put in on-die thermal protection on all of their chips for a while now. All Athlon XP's have it, afaik.
ask on the gentoo forums
But SuperKaramba is Karamba, not something completely different. It is simply Karamba... plus a python-based API in top of it.
> What we really need is a service that downloads whole articles to the desktop
You can already pretty much do that with Karamba.
> Sidebars such as Karamba need to be more useful than just show information. There needs to be a way for a user to interact with the information presented to them. Until that happens they will remain pretty much useless (and off my desktop).
Heh.. that's pretty much the goal of SuperKaramba. Interactive Karamba sensors.
The Opteron will be available in a desktop version. The Xeon is not, and will not be.
That means there is a HUGEEEEEEE difference in price.
Also, every review except for Tom's shows the Opteron beating Xeons in more workstation tests --- Tom didn't enable the second memory channel or use DDR400. Both of which limited performance.
Copyright date != date of manufacture... mkay?
The chip tested was a consumer version of the athlon64 (one memory channel). If it cannot run 32 bit code with any reasonable amount of speed (i.e, faster than AXP and comparable to latest p4's), then the chip is destined for failure.
Good news is that it seems like it can.
1. He was talking about window transparency.. read the post next time.
2. While you are correct in saying that Windows does not use OpenGL in compositing windows, much of the theory is the same. Replace OpenGL with the GDI, and you have another interface to graphics-card enabled compositing, abiet a slightly less versatile one.
1. He was talking about Transclucence.. read the grandparent poster's SUBJECT. Windows has supported this since Windows2000.
2. While you are correct in saying that Windows does not use OpenGL in compositing windows, much of the theory is the same. Replace OpenGL with the GDI, and you have another interface to graphics-card enabled compositing, abiet a slightly less versatile one.
> JK2, SoF2, RTCW, and Q3A have a significant performance hit on a modern graphics card
I guess it depends on your definition of modern graphics cards. The aforementioned games are all based on the Quake3 Engine.. which is over three years old now. On modern video cards (as in... GeForce2 and up, or original Radeon and up), all of the games above should run smoothly, unless you are running 1600x1200@32 bit@4x FSAA or something crazy like that.
Anyway, these games pretty much have FPS caps where it's not worth getting more FPS. Q3A, for example, 90% of people have their FPS capped at 125 fps. Why? Because it provides the best strafe jumping physics. SOF2, another example, enforces a FPS limit of 90.
> especially if you're running non-nVidia.
I guess Radeon 9700/9800 owners will have something to say about that!
> there's a lag in any "busy" scenes which just isn't there under Windows.
Um.. I didn't notice that at all with my old system GeForce 3 ti200 (on Athlon 1.4), or my current system gf4ti4600 and Athlon XP 2200+.
> A big deal if you're a hardcore gamer? Certainly.
If you are a hardcore FPS gamer, you probably aren't using high graphics detail anyways. I've been a hardcore competitive gamer since 1998 or so (went Quakeworld->Quake3...), and almost everyone in the hardcore competitive scene uses r_picmip 3 or higher, very low res, vertex lighting, etc..
> I am just wondering if we will ever get the performance we get with games under windows
:)
With most games yes.
> I know that they have a couple games ported
More than just a few games work in winex
> like FPS where framerates are so important.
Yep.. games based on slightly older engines, such as the quake3 engine (rtcw, moh, jk2, sof2), and Halflife (Counterstrike)... pretty much run at the same speeds in WineX and WIndows already.
What would be interested to see is how new games such as bf1942 run on it.. bf1942 is cpu/gfx card intensive, and doesn't run nateively in Linux (unlike ut2k3..)
> Now flame me if i am wrong, but doesn't wine work on some sort of Virtual Machine, thus adding an extra layer between the hardware and the code?
No... wine is an implemenation of the Windows API.
What incentive do these game developers have in using those cross platform API's rather than something WAY more tested in the real world such as.. uhm... DirectX?
> Anyway, as I've stated elsewhere, you're ignoring the fact that Linux does have games.
__Extremely__ few compared to Windows.
> If you play FPSs and like to click effectively, you're better off with a real, dedicated button.
Not really.. an Logitech MX 500 or Intellimouse 3.0 will pretty much beat any other 3-button mouse on the market.
The wheel is useful for switching weapons, in any case.