Microwaves are *hard*! We got a new microwave, which I didn't have an occasion to use until the other day. Took me like 10 minutes to figure out how to enter the time. I was really hungry at the time, too...
Xizzle isn't another server. It and Kdrive are the driver layer for the spiffy FD.O server. KDrive is the simple, embedded, layer. Xizzle is the XFree86 layer. Eventually, there will be an OpenGL-based one too.
In my opinion: Anybody who has the cajones to rip a major chunk out of XFree86 and transplant it somewhere else can name it "kitten killer 2000" if he wants to.
I think they need to come up with a name for their damn X server. Up until now, calling it the FD.O X server was okay, cuz there was only one X server on freedesktop.org. Now there are two, and all hell has broken loose. It doesn't help that the new X server is called the X.org server, when there is already another X.org server (the X11R6.6 reference implementation).
Ugh. Managed to confuse all the hell out of this. There are two X servers on freedesktop.org. One is X.org, which is a fork of XFree86. The other is based on KDrive, and that's called the FD.O X server.
There are two parts to the FD.O X server. The DIX (device-independent) layer is derived from XFree86. The DDX (device-dependent) layer is new. The libraries are derived from XFree86 too.
Cuz its confusing. What you ran was not the X.org X server, but the freedesktop.org X server. Its where all the fancy transparency stuff is being developed. To support that stuff, they'll have a new driver model designed to take full-advantage of OpenGL. Since those aren't ready yet, they're using the kdrive model, which is where the low-refresh rates and general lack of acceleration come in.
The X.org X server is the XFree86 4.4 codebase, so it is binary-compatible with the ATI/NVIDIA drivers.
Except this isn't the reference implementation, its XFree86 4.4 pre-licensing change. However, since XFree86 is based on the X11R6.6 reference implementation, it should be very compatible.
Let's seperate the code-bases from the organizations. There are a couple of organizations:
XFree86, Inc. - The old organization, mainly consisting of David Dawes at this point.
Xouvert - Splinter group that forked X awhile ago, with the intention of being a cooperative competitor.
X.org - Formerly X Consortium. Bunch of companies and developers working on the X11R6.x reference codebase.
Freedesktop.org - Umbrella project for various desktop-related Linux projects
Now, there are some implementations:
XFree86 - De-facto standard on Linux, by XFree86, Inc. Based on the X11R6.x reference codebase.
Xouvert - Fork of XFree86 (circa 4.3?) by the Xouvert project.
X.org server - Don't confuse this with the X.org reference codebase. This is a fork of XFree86 4.4-RC2 (before the license change). Now its under the X.org umbrella, and is hosted on freedesktop.org (that's the confusing part:)
FD.O X - Keith Packard and friend's new, fancy X server. Development hotbed for new technologies like transparency, OpenGL-acceleration, etc.
There are a couple of seperate sub-components to note here. The FD.O X server supports a number of DDXs (basically, driver layers). There is the kdrive-based DDX, the XFree86-based DDX (called Xizzle, theoretically compatible with XFree86 drivers).
There will eventually be another DDX designed from the ground-up for OpenGL acceleration. The device-independent portion of the FD.O server is, IIRC, derived from an older version of XFree86.
It really depends on your setup. I've got a 133 dpi LCD, and I can definitely say it looks better. Cleartype hints far too aggressively for a display that has that many pixels to play with. For a medium-res CRT, I'd rather have non-anti-aliased, hinted output anyway. If you've got that bytecode hinter on, you'll get identical output (pixel-for-pixel) in that case. Screenshot of my desktop Note, unless you've got a 133 dpi display or higher, the fonts will look unusually large.
In any case, I think FreeType's anti-aliased output at medium resolutions is actually quite good. Read one of my rants on OSNews (search for title "Font comparo thread"). Note the attached screenshot, taken at a more sane resolution.
I'm not complaining that you've got the panel at top. I'm saying you don't have the option to put the window's menu in it. For reasons of fitts law and whatnot.
Additionally, developers are missing a *well* standardized graphics API. Unfortunately, Open/GL is not it. Why not? I used to have lots of complaints about the OpenGL ARB (even wrote an article on it) but they've really got their act together recently. 1.3, 1.4, and 1.5 came out in quick succession since 2001. OpenGL 2.0 looks like a really good evolution of the API.
The gconf hierarchy is much more confusing to understand than KDE configuration panels. And even with gconf, there are lots of things you still cannot configure
GNOME 1.4 didn't have pervasive toolbar editing, but KDE does. GTK+ 2.4 has the infrastructure for it, so we should see it by GNOME 2.8 (2.6 won't have it).
And that's not a top menubar, that's a panel. I'm talking about how OS X does it, with the application's menubar at the top.
Though the earlier screen had told him that his selection would affect his location he was still at the same place, in front of his old PC. ...and... But it didn't matter as he just had deleted his Windows 98 with fdisk.
The "average user" is happy to see that the computer didn't teleport him somewhere else, but can still figure out Windows 98 fdisk???
Online reviews would be much better if we could moderate by throwing rotten fruit at the author...
GNOME is a terrible example. GNOME 2.x caused a lot of GNOME'ers to migrate away from the platform. Its very feature-limited, and even as a Linux guru, I find gconf user-friendly only if you understand the hierarchy already.
Its not just useless features missing in GNOME. Very important things are missing (my personal ones --- no pervasive toolbar editing, no menubar at top).
You dismiss competency, but it's really very important. Well-meaning, non-malicious people can still make mistakes. Its really hard to hack a compile by mistake!
But even if you wrongly trust an evil application vendor, his program still shouldn't be able to run rampant over the machine. True, in theory, but that's just not the case on current machines. Nobody in their right mind runs code from people they don't trust, even on UNIX systems with protection. There are just too many holes for that to be allowed to happen.
[E]mperical evidence has trivially proven the opposite. How so? There have been three or four local exploits in Linux in the last couple of months. mremap() ring a bell? There are local exploits in Windows *constantly*. The thing is that we're not in a very good position as it is. You've got 3-4 million lines of kernel code (plus lots more running as root) that are implicitly trusted. It is very easy for a malicious local user to find an exploit in all that code. When the compiler enforces protection, you've got perhaps several thousand lines of code (a properly designed compiler would have a well-isolated module handling memory security) that could be at fault. Then, all that code that used to be privleged, and thus dangerous, is removed as a threat.
No it isn't. When verifying email origination, you need only determine the sender's identity, not his competency. Competency is not in question here. As long as the sender uses a trusted compiler to compile the code, everything is okay. If you trust the distributor of a given binary, it makes sense to trust that they are not malicious and are not using a hacked compiler. If you don't trust the distributor, you shouldn't be running binaries from them anyway!
a mistake in the compiler used for a high-level application can cause mysterious system-wide failures. And a mistake in the kernel can cause mysterious system-wide failures!
Today, regardless of how wrong the compiler's author might be, it'll only crash his own program, not stomp on other user's memory (or the kernel). In such a system, the kernel is just a bunch of libraries. Instead of the kernel being a central point of failure, the compiler/runtime becomes a central point of failure. You're not increasing the chances of disaster, just moving responsibility elsewhere.
You are in a way proposing that compiler innovation be shutdown, because in your scheme it would be too risky to allow it to be changed. Of course not. Only a small part of the compiler need be concerned with memory protection. Since you've got no pointer arithmatic, you just have to make sure that the compiler outputs array range-checks in the right places. Surely getting that right, even in the face of a constantly improving compiler, is easier than securing 100+ different system-call handlers in a kernel like Linux!
The compiler is not on your computer, so it can't be trusted. Sure it can. All you need is a way to guarantee that the code in question was compiled by a conforming compiler. Its analagous to the problem of guaranteeing that a given e-mail originated from a certain person. If that is too complicated to handle, then distributing code as a high-level IR (like.NET does) and compiling it to native code (via a trusted compiler) at install-time wouldn't be problematic.
Slashdot Mirror
I agree, but I've got one comment:
Microwaves are *hard*! We got a new microwave, which I didn't have an occasion to use until the other day. Took me like 10 minutes to figure out how to enter the time. I was really hungry at the time, too...
You are presuming that there is intelligence on earth...
Bill Clinton is a hottie!
:)
This is going to come back to haunt me sooner or later
Xizzle isn't another server. It and Kdrive are the driver layer for the spiffy FD.O server. KDrive is the simple, embedded, layer. Xizzle is the XFree86 layer. Eventually, there will be an OpenGL-based one too.
In my opinion: Anybody who has the cajones to rip a major chunk out of XFree86 and transplant it somewhere else can name it "kitten killer 2000" if he wants to.
I think they need to come up with a name for their damn X server. Up until now, calling it the FD.O X server was okay, cuz there was only one X server on freedesktop.org. Now there are two, and all hell has broken loose. It doesn't help that the new X server is called the X.org server, when there is already another X.org server (the X11R6.6 reference implementation).
Ugh. Managed to confuse all the hell out of this. There are two X servers on freedesktop.org. One is X.org, which is a fork of XFree86. The other is based on KDrive, and that's called the FD.O X server.
There are two parts to the FD.O X server. The DIX (device-independent) layer is derived from XFree86. The DDX (device-dependent) layer is new. The libraries are derived from XFree86 too.
Cuz its confusing. What you ran was not the X.org X server, but the freedesktop.org X server. Its where all the fancy transparency stuff is being developed. To support that stuff, they'll have a new driver model designed to take full-advantage of OpenGL. Since those aren't ready yet, they're using the kdrive model, which is where the low-refresh rates and general lack of acceleration come in.
The X.org X server is the XFree86 4.4 codebase, so it is binary-compatible with the ATI/NVIDIA drivers.
Didn't I say as much?
The X.org X server is XFree84 4.4-RC2 + bits. It is hosted on freedesktop.org
The FD.O X server is KDrive (which is derived from XFree86, in part) + bits. It is also hosted on freedesktop.org.
Except this isn't the reference implementation, its XFree86 4.4 pre-licensing change. However, since XFree86 is based on the X11R6.6 reference implementation, it should be very compatible.
Let's seperate the code-bases from the organizations. There are a couple of organizations:
:)
XFree86, Inc. - The old organization, mainly consisting of David Dawes at this point.
Xouvert - Splinter group that forked X awhile ago, with the intention of being a cooperative competitor.
X.org - Formerly X Consortium. Bunch of companies and developers working on the X11R6.x reference codebase.
Freedesktop.org - Umbrella project for various desktop-related Linux projects
Now, there are some implementations:
XFree86 - De-facto standard on Linux, by XFree86, Inc. Based on the X11R6.x reference codebase.
Xouvert - Fork of XFree86 (circa 4.3?) by the Xouvert project.
X.org server - Don't confuse this with the X.org reference codebase. This is a fork of XFree86 4.4-RC2 (before the license change). Now its under the X.org umbrella, and is hosted on freedesktop.org (that's the confusing part
FD.O X - Keith Packard and friend's new, fancy X server. Development hotbed for new technologies like transparency, OpenGL-acceleration, etc.
There are a couple of seperate sub-components to note here. The FD.O X server supports a number of DDXs (basically, driver layers). There is the kdrive-based DDX, the XFree86-based DDX (called Xizzle, theoretically compatible with XFree86 drivers).
There will eventually be another DDX designed from the ground-up for OpenGL acceleration. The device-independent portion of the FD.O server is, IIRC, derived from an older version of XFree86.
Methinks that you're confused. X.org is seperate from the FD.O X server. X.org is a derivative of XFree86. FD.O is different.
Let's stamp out this rumor before it spreads further. The new FD.O X server is under the standard MIT X license, not the LGPL!
I've got a Dell Inspiron 8200 laptop with their "UltraSharp" brand LCD.
I think its a Toshiba or Hitachi. Its on a Dell Inspiron 8200 laptop.
It really depends on your setup. I've got a 133 dpi LCD, and I can definitely say it looks better. Cleartype hints far too aggressively for a display that has that many pixels to play with. For a medium-res CRT, I'd rather have non-anti-aliased, hinted output anyway. If you've got that bytecode hinter on, you'll get identical output (pixel-for-pixel) in that case. Screenshot of my desktop Note, unless you've got a 133 dpi display or higher, the fonts will look unusually large.
In any case, I think FreeType's anti-aliased output at medium resolutions is actually quite good. Read one of my rants on OSNews (search for title "Font comparo thread"). Note the attached screenshot, taken at a more sane resolution.
I'm not complaining that you've got the panel at top. I'm saying you don't have the option to put the window's menu in it. For reasons of fitts law and whatnot.
Additionally, developers are missing a *well* standardized graphics API. Unfortunately, Open/GL is not it.
Why not? I used to have lots of complaints about the OpenGL ARB (even wrote an article on it) but they've really got their act together recently. 1.3, 1.4, and 1.5 came out in quick succession since 2001. OpenGL 2.0 looks like a really good evolution of the API.
The gconf hierarchy is much more confusing to understand than KDE configuration panels. And even with gconf, there are lots of things you still cannot configure
GNOME 1.4 didn't have pervasive toolbar editing, but KDE does. GTK+ 2.4 has the infrastructure for it, so we should see it by GNOME 2.8 (2.6 won't have it).
And that's not a top menubar, that's a panel. I'm talking about how OS X does it, with the application's menubar at the top.
Though the earlier screen had told him that his selection would affect his location he was still at the same place, in front of his old PC. ...and...
But it didn't matter as he just had deleted his Windows 98 with fdisk.
The "average user" is happy to see that the computer didn't teleport him somewhere else, but can still figure out Windows 98 fdisk???
Online reviews would be much better if we could moderate by throwing rotten fruit at the author...
GNOME is a terrible example. GNOME 2.x caused a lot of GNOME'ers to migrate away from the platform. Its very feature-limited, and even as a Linux guru, I find gconf user-friendly only if you understand the hierarchy already.
Its not just useless features missing in GNOME. Very important things are missing (my personal ones --- no pervasive toolbar editing, no menubar at top).
You dismiss competency, but it's really very important. Well-meaning, non-malicious people can still make mistakes.
Its really hard to hack a compile by mistake!
But even if you wrongly trust an evil application vendor, his program still shouldn't be able to run rampant over the machine.
True, in theory, but that's just not the case on current machines. Nobody in their right mind runs code from people they don't trust, even on UNIX systems with protection. There are just too many holes for that to be allowed to happen.
[E]mperical evidence has trivially proven the opposite.
How so? There have been three or four local exploits in Linux in the last couple of months. mremap() ring a bell? There are local exploits in Windows *constantly*. The thing is that we're not in a very good position as it is. You've got 3-4 million lines of kernel code (plus lots more running as root) that are implicitly trusted. It is very easy for a malicious local user to find an exploit in all that code. When the compiler enforces protection, you've got perhaps several thousand lines of code (a properly designed compiler would have a well-isolated module handling memory security) that could be at fault. Then, all that code that used to be privleged, and thus dangerous, is removed as a threat.
No it isn't. When verifying email origination, you need only determine the sender's identity, not his competency.
Competency is not in question here. As long as the sender uses a trusted compiler to compile the code, everything is okay. If you trust the distributor of a given binary, it makes sense to trust that they are not malicious and are not using a hacked compiler. If you don't trust the distributor, you shouldn't be running binaries from them anyway!
a mistake in the compiler used for a high-level application can cause mysterious system-wide failures.
And a mistake in the kernel can cause mysterious system-wide failures!
Today, regardless of how wrong the compiler's author might be, it'll only crash his own program, not stomp on other user's memory (or the kernel).
In such a system, the kernel is just a bunch of libraries. Instead of the kernel being a central point of failure, the compiler/runtime becomes a central point of failure. You're not increasing the chances of disaster, just moving responsibility elsewhere.
You are in a way proposing that compiler innovation be shutdown, because in your scheme it would be too risky to allow it to be changed.
Of course not. Only a small part of the compiler need be concerned with memory protection. Since you've got no pointer arithmatic, you just have to make sure that the compiler outputs array range-checks in the right places. Surely getting that right, even in the face of a constantly improving compiler, is easier than securing 100+ different system-call handlers in a kernel like Linux!
The compiler is not on your computer, so it can't be trusted. .NET does) and compiling it to native code (via a trusted compiler) at install-time wouldn't be problematic.
Sure it can. All you need is a way to guarantee that the code in question was compiled by a conforming compiler. Its analagous to the problem of guaranteeing that a given e-mail originated from a certain person. If that is too complicated to handle, then distributing code as a high-level IR (like