Its a misnomer to say that Linux has fonts. The window manager have them and to put it bluntly they suck. You are in denial if you don't notice this. Okay, so:
a) You're blind, because any idiot can see that the fonts on a modern Linux system look fine;
b) You have no idea how fonts on Linux work.
Without a standard window manager and a standard API to program for (thanks GNOME vs KDE war), What's the standard API in Windows? The XP Common Controls (used by IE, Explorer, etc), the Office Toolkit (used by Office), the.NET toolkit (Visual Studio), or WinFX (Longhorn)? That's not to consider other toolkits and APIs like MFC, VCL, Swing, etc.
What's wrong with the existing fonts? Freetype renders just great on the majority of systems, and depending on your tastes, better than Cleartype on very high resolution systems. RedHat 9 and up have very nice looking fonts indeed.
Well, the vera fonts come with most distros today, but even if they didn't, installing them is a matter of copying the fonts to/usr/share/fonts. Just like in Windows!
I never said that Python can leak. Given the GC, I'd suspect it cannot. I said that Scheme couldn't leak.
Your example about a server process isn't necessarily a leak though. If the app is keeping references to that data (ie: it's not finished using that data), then its not leaking. If it *isn't* keeping references to that data, but it still does not get reclaimed, then it is a leak.
Interacting with the computer isn't an end in itself. However, many jobs these days require interacting with the computer for hours on end. The more efficient the interface, the faster the work. Look at it this way: say you have Japanese co-workers who don't speak English, and you don't speak Japanese. Do you work together for years on end, communicating by pointing and grunting at things, or do you try to establish a common language?
Now, I'm not going to say that a CLI is the ideal human-computer interface. But I will say that current GUIs, based on "real world" metaphors aren't ideal either. The ideal interface utilizes both visual and linguistic skills, where appropriate. Visual elements can be very efficient for certain situations (data visualization, looking for patterns, etc), motor elements can be efficient for others (designing, drawing, etc), and linguistic elements for others (generally, telling the computer what you want it to do in an expressive way).
This paper goes into a lot of detail about these issues.
Bah. People have, rightly, compared point-and-click interfaces to primitive "point and grunt" communication. You don't have to be a novelist to communicate well. The very fact that your brains have evolved to support them shows the sheer power of the system. Its the difference between interfacing with the computer at the level of an animal and interfacing with it at the level of a human.
Leak has a very specific meaning. A memory leak is memory that is no longer referenced by the program, but is not freed within an indefinite period of program runtime. Memory has been leaked when it can be proved that the memory manager cannot collect that memory at any point in the future. Thus, you can have leaks without hitting an out-of-memory error (if leaking is slow enough that you don't fill memory during program execution), and you can have out-of-memory errors without necessarily having leaks (your program references too much memory).
Guess what: appending an infinite number of items to a list causes a memory leak in Java, C++, C, assembly, Scheme, sh, Perl and every other programming language in the world. Properly implemented, Scheme should never leak memory. Even if you try to add an infinite number of items to a collection, you'll get an out-of-memory error before you'd get a leak.
Functional programming in C++ is like pulling teeth with your fingers. It's not pretty. Boost.Lambda is completely impossible to debug. Lack of type inference is a major PITA.
I'm a big fan of C++. However, its being pushed into a domain where its just bursting at the seams. The STL, all the stuff in "Modern C++ Design," etc, is just a plea from C++ designers for a Lisp-like language.
Compilers that compile to C use C as something of a portable assembler. Usually, the source constructs map only loosly to C constructs --- functions to functions, class references to void*, etc. Memory management is handled via a conservative GC, which can deal with C code.
So, it wasn't the processor specifically, but THE ARCHITECTURE BUILT AROUND IT? For crying out loud, if the supporting architecture doesn't actually support you then you're not doing so well. Eh? The UltraSPARC performed very poorly on things like SPEC, that were mainly CPU benchmarks. However, Sun machines generally performed well in real-world server scenarios, where the better architecture made up for deficiencies in processor power.
Additionally, the UltraSPARC processors weren't as fast as x86 but they scale much better and have no end in sight How well a CPU scales is more a function of the machines memory and bus architecture than the CPU itself. x86 CPUs like the Opteron can scale very well --- its just that Sun machines are much more commonly equiped with the cross-bar memory controllers and other system support that you need to get a scalable machine.
whereas the x86 can't compete in large multiprocessor systems and are starting to show future caps in terms of power, heat, and size I wouldn't compare SPARC so much with x86 as I would compare it with PowerPC, the former Alpha, PA-RISC, and Itanium. Relative to the other major RISC architectures, SPARC CPUs themselves were never very impressive.
x86 CPUs have very few registers to save, so hardware context switches (the x86 does have them via TSS segments) don't buy you anything.
Hardware context switching is not why SPARC machines can handle huge amounts of load. The handle huge amounts of load because they have crossbar memory controllers, multiple I/O busses, and an OS (Solaris) especially tuned for high load situations.
Suns were fast not because the UltraSPARC chips were really good (they actually kinda sucked) but because of the insanely fast memory and I/O busses in a Sun machine. UltraSPARC being canceled is actually a good thing. It lets Sun concentrate on making good machines, and leaves the CPUs to companies who are good at making them.
That would be the case if the music companies weren't a cartel. Go read a basic economics text to see the distinction between a cartel trying to set prices and the market trying to do the same.
The only way you're going to get that level of scripting ability is to rewrite all apps in some interpreted language with remote method invocation and, to make life easier, reflection. Actually, libSMOKE provides full remote method invocation and reflection for Qt and KDE.
But there are lots of companies that make the products that those companies make. They may be huge, and sometimes beligerent, but they aren't monopolies. Of course, I don't think Intel is a monopoly either, not since AMD became a competitive firm, and not with the recent revival of chipmaking at IBM.
Bah. You threw me off. Neither kdrive or xizzle are servers, they are DDX'es. However, its a common bit of laziness to use the word kdrive to mean X server DIX + kdrive DDX. Xizzle, however, is just the XFree86 DDX. Clear as mud?
Dylan is a bit like Scheme (lisp-1, pattern-matching macros) but is overall more influenced by Common Lisp. Its feature-set is most nearly a super-set of Scheme's (excepting continuations) or a subset of CL's.
I take that to mean that 'right now...kdrive itself is not intended to be a replacement for XFree86.' That would certainly be a true statement. However, I think the overall goal is that the advancements in the fd.o X server will be mainlined when they are done. Whether that is accomplished by making kdrive a stable replacement for xfree86/x.org or whether the advancements in kdrive will be ported to xfree86/x.org remains to be seen. Remember that all the X server codebases that we're talking about are related, so if kdrive continues to remain experimental, the changes can be ported to the stable servers. Indeed, the XDamage and XFixes extensions have already been ported to X.org's CVS branch.
I've got no clue what the new Xfree license entails... And it really shows in your post!
But nonetheless, I think the community is overreacting. Right. Because RedHat and Debian are *such* reactionary GPL-fundamentalists organization.
(yeah, there are forks, but they haven't been around long enough to prove their stability or their worth). You do realize that X.org is the maintainer of the reference X11R6.x codebase, and that X11R6.7 is a continuation of XFree86 4.4-RC2, which is a derivative of that reference codebase?
If we can create a modern standardized windowing protocol (which is what X11 essentially is, only broken and outdated), What is broken and outdated about the X11 protocol? Taking into account widely-supported extensions like RENDER, the X11 protocol is surprisingly Good. There are warts, to be sure (the color model, for example), but every long-lived system has those.
we can maxamize portability between platforms Eh? X11 is the most portable windowing system in existance!
and radically simplify software development. So X12 will be written in Lisp:) I'd go jump on that bandwagon!
Even Microsoft would jump on the bandwagon. Have you lost *complete* touch with reality???
and seek to accomplish far too much and form their own proprietary standards. What proprietory standards???? Do you have the slightest idea what you're talking about?
We need a completely new protocol so that everyone can work together and maintain compatibility. We need to ditch a widely-supported, well-tested, mature, easily-extensible, and highly compatible protocol, and create a new, untested, immature, and unsupported one, in order to maintain compatibility?
Its not so much a matter of GPL-incompatible == not free, but a GPL-incompatible component being a central part of a overwhelmingly GPL system. The kernel is GPL'ed, the gcc toolchain is GPL'ed/LGPL'ed, GNOME and KDE are LGPL'ed, GTK+ is LGPL'ed, Qt is GPL'ed, Mozilla and OpenOffice have GPL as one of their licenses, etc. GPL-incompatible software in that environment is just not appropriate.
Slashdot Mirror
Are you dense?
.NET toolkit (Visual Studio), or WinFX (Longhorn)? That's not to consider other toolkits and APIs like MFC, VCL, Swing, etc.
Its a misnomer to say that Linux has fonts. The window manager have them and to put it bluntly they suck. You are in denial if you don't notice this.
Okay, so:
a) You're blind, because any idiot can see that the fonts on a modern Linux system look fine;
b) You have no idea how fonts on Linux work.
Without a standard window manager and a standard API to program for (thanks GNOME vs KDE war),
What's the standard API in Windows? The XP Common Controls (used by IE, Explorer, etc), the Office Toolkit (used by Office), the
What's wrong with the existing fonts? Freetype renders just great on the majority of systems, and depending on your tastes, better than Cleartype on very high resolution systems. RedHat 9 and up have very nice looking fonts indeed.
Well, the vera fonts come with most distros today, but even if they didn't, installing them is a matter of copying the fonts to /usr/share/fonts. Just like in Windows!
I never said that Python can leak. Given the GC, I'd suspect it cannot. I said that Scheme couldn't leak.
Your example about a server process isn't necessarily a leak though. If the app is keeping references to that data (ie: it's not finished using that data), then its not leaking. If it *isn't* keeping references to that data, but it still does not get reclaimed, then it is a leak.
Interacting with the computer isn't an end in itself. However, many jobs these days require interacting with the computer for hours on end. The more efficient the interface, the faster the work. Look at it this way: say you have Japanese co-workers who don't speak English, and you don't speak Japanese. Do you work together for years on end, communicating by pointing and grunting at things, or do you try to establish a common language?
Now, I'm not going to say that a CLI is the ideal human-computer interface. But I will say that current GUIs, based on "real world" metaphors aren't ideal either. The ideal interface utilizes both visual and linguistic skills, where appropriate. Visual elements can be very efficient for certain situations (data visualization, looking for patterns, etc), motor elements can be efficient for others (designing, drawing, etc), and linguistic elements for others (generally, telling the computer what you want it to do in an expressive way).
This paper goes into a lot of detail about these issues.
Bah. People have, rightly, compared point-and-click interfaces to primitive "point and grunt" communication. You don't have to be a novelist to communicate well. The very fact that your brains have evolved to support them shows the sheer power of the system. Its the difference between interfacing with the computer at the level of an animal and interfacing with it at the level of a human.
Leak has a very specific meaning. A memory leak is memory that is no longer referenced by the program, but is not freed within an indefinite period of program runtime. Memory has been leaked when it can be proved that the memory manager cannot collect that memory at any point in the future. Thus, you can have leaks without hitting an out-of-memory error (if leaking is slow enough that you don't fill memory during program execution), and you can have out-of-memory errors without necessarily having leaks (your program references too much memory).
Guess what: appending an infinite number of items to a list causes a memory leak in Java, C++, C, assembly, Scheme, sh, Perl and every other programming language in the world.
Properly implemented, Scheme should never leak memory. Even if you try to add an infinite number of items to a collection, you'll get an out-of-memory error before you'd get a leak.
Functional programming in C++ is like pulling teeth with your fingers. It's not pretty. Boost.Lambda is completely impossible to debug. Lack of type inference is a major PITA.
I'm a big fan of C++. However, its being pushed into a domain where its just bursting at the seams. The STL, all the stuff in "Modern C++ Design," etc, is just a plea from C++ designers for a Lisp-like language.
Compilers that compile to C use C as something of a portable assembler. Usually, the source constructs map only loosly to C constructs --- functions to functions, class references to void*, etc. Memory management is handled via a conservative GC, which can deal with C code.
So, it wasn't the processor specifically, but THE ARCHITECTURE BUILT AROUND IT? For crying out loud, if the supporting architecture doesn't actually support you then you're not doing so well.
Eh? The UltraSPARC performed very poorly on things like SPEC, that were mainly CPU benchmarks. However, Sun machines generally performed well in real-world server scenarios, where the better architecture made up for deficiencies in processor power.
Additionally, the UltraSPARC processors weren't as fast as x86 but they scale much better and have no end in sight
How well a CPU scales is more a function of the machines memory and bus architecture than the CPU itself. x86 CPUs like the Opteron can scale very well --- its just that Sun machines are much more commonly equiped with the cross-bar memory controllers and other system support that you need to get a scalable machine.
whereas the x86 can't compete in large multiprocessor systems and are starting to show future caps in terms of power, heat, and size
I wouldn't compare SPARC so much with x86 as I would compare it with PowerPC, the former Alpha, PA-RISC, and Itanium. Relative to the other major RISC architectures, SPARC CPUs themselves were never very impressive.
x86 CPUs have very few registers to save, so hardware context switches (the x86 does have them via TSS segments) don't buy you anything.
Hardware context switching is not why SPARC machines can handle huge amounts of load. The handle huge amounts of load because they have crossbar memory controllers, multiple I/O busses, and an OS (Solaris) especially tuned for high load situations.
As well, who should we point to as good at making processors?
IBM, Fujitsu (SPARC-64), and Intel (Itanium).
Suns were fast not because the UltraSPARC chips were really good (they actually kinda sucked) but because of the insanely fast memory and I/O busses in a Sun machine. UltraSPARC being canceled is actually a good thing. It lets Sun concentrate on making good machines, and leaves the CPUs to companies who are good at making them.
1) Its Apple's implementation of GL that's less than perfectly optimized. On Windows and Linux, OpenGL is as fast as D3D.
2) OpenGL has numerous releases in the last few years. 1.3, 1.4, and 1.5 were all released in quick succession. What rock have you been hiding under?
They mean OpenGL ES.
That would be the case if the music companies weren't a cartel. Go read a basic economics text to see the distinction between a cartel trying to set prices and the market trying to do the same.
The only way you're going to get that level of scripting ability is to rewrite all apps in some interpreted language with remote method invocation and, to make life easier, reflection.
Actually, libSMOKE provides full remote method invocation and reflection for Qt and KDE.
But there are lots of companies that make the products that those companies make. They may be huge, and sometimes beligerent, but they aren't monopolies. Of course, I don't think Intel is a monopoly either, not since AMD became a competitive firm, and not with the recent revival of chipmaking at IBM.
Bah. You threw me off. Neither kdrive or xizzle are servers, they are DDX'es. However, its a common bit of laziness to use the word kdrive to mean X server DIX + kdrive DDX. Xizzle, however, is just the XFree86 DDX. Clear as mud?
Not quite right:
- kdrive is Keith's experimental X server.
- Xizzle is a kdrive DDX that can load XFree86/X.org drivers.
Dylan is a bit like Scheme (lisp-1, pattern-matching macros) but is overall more influenced by Common Lisp. Its feature-set is most nearly a super-set of Scheme's (excepting continuations) or a subset of CL's.
I take that to mean that 'right now...kdrive itself is not intended to be a replacement for XFree86.' That would certainly be a true statement. However, I think the overall goal is that the advancements in the fd.o X server will be mainlined when they are done. Whether that is accomplished by making kdrive a stable replacement for xfree86/x.org or whether the advancements in kdrive will be ported to xfree86/x.org remains to be seen. Remember that all the X server codebases that we're talking about are related, so if kdrive continues to remain experimental, the changes can be ported to the stable servers. Indeed, the XDamage and XFixes extensions have already been ported to X.org's CVS branch.
I've got no clue what the new Xfree license entails...
:) I'd go jump on that bandwagon!
And it really shows in your post!
But nonetheless, I think the community is overreacting.
Right. Because RedHat and Debian are *such* reactionary GPL-fundamentalists organization.
(yeah, there are forks, but they haven't been around long enough to prove their stability or their worth).
You do realize that X.org is the maintainer of the reference X11R6.x codebase, and that X11R6.7 is a continuation of XFree86 4.4-RC2, which is a derivative of that reference codebase?
If we can create a modern standardized windowing protocol (which is what X11 essentially is, only broken and outdated),
What is broken and outdated about the X11 protocol? Taking into account widely-supported extensions like RENDER, the X11 protocol is surprisingly Good. There are warts, to be sure (the color model, for example), but every long-lived system has those.
we can maxamize portability between platforms
Eh? X11 is the most portable windowing system in existance!
and radically simplify software development.
So X12 will be written in Lisp
Even Microsoft would jump on the bandwagon.
Have you lost *complete* touch with reality???
and seek to accomplish far too much and form their own proprietary standards.
What proprietory standards???? Do you have the slightest idea what you're talking about?
We need a completely new protocol so that everyone can work together and maintain compatibility.
We need to ditch a widely-supported, well-tested, mature, easily-extensible, and highly compatible protocol, and create a new, untested, immature, and unsupported one, in order to maintain compatibility?
Its not so much a matter of GPL-incompatible == not free, but a GPL-incompatible component being a central part of a overwhelmingly GPL system. The kernel is GPL'ed, the gcc toolchain is GPL'ed/LGPL'ed, GNOME and KDE are LGPL'ed, GTK+ is LGPL'ed, Qt is GPL'ed, Mozilla and OpenOffice have GPL as one of their licenses, etc. GPL-incompatible software in that environment is just not appropriate.