Yes. Most definately. Font rendering was never one of BeOS's strongest points. It was okay (better than Windows at the time), but the Bitstream renderer was showing its age. I was looking forward to the licensing deal with Bitstream to embed FontFusion (their new renderer) but that never happened. I saw FontFusion in action in QNX RtP and it was incredible. However, the version of FreeType in CVS right now is even better:)
Actually, with the FreeType CVS, the free Postscript fonts look just great. I've currently got the bytecode interpreter disabled because the autohinter in FreeType CVS is so good with Postscript fonts that it looks much better on my LCD than the hinted TrueType fonts. Letter shapes are a whole lot more accurate, while the outlines are still sharp. Read the FreeType mailing list (devel) sometime.
They've stopped sucking for a long time now. I don't know what cookie-cutter distro you use, but my Gentoo installed automatically included a TT-bytecode interpeter enabled FreeType and MS Windows fonts. When I got my UXGA laptop, there was initially some problem because the LCD looked best when all fonts were anti-aliased (it has enough resolution that AA text looks sharp rather than blurry) but all I had to do was download FreeType2 CVS, get some nice Postscript fonts, and I ended up with font rendering that whips OS X all over the place and easily matches ClearType.
Umm, whose logic is flawed? The original poster bashed RedHat for bowing to political pressures and dissing the Taiwanese. All you did was prove that it was in there best interest (economically, if not ethically) to do so.
The relevent clauses are 7 and 8 in the GPL Interestingly, the MP3 situation seems a bit fuzzy. They say that if you cannot redistribute the source freely (because of patents), then you cannot distribute the program at all. This does not necessarily mean that a GPL program cannot implemented patented non-open/free protocols. It just means that it can't implement such protocols if they require a license fee per copy, which until recently MP3 did not. Also, since most MP3 players are distributed mainly as source, it is questionable whether they violate the GPL. After all, FreeType includes the bytecode interpreter in the source, but that doesn't violate Apple's patent unless an actual product (binary) is generated with the bytecode interpreter enabled.
The font handling in Mozilla (and almost every other non-Qt or GTK 2.x app) sucks. Perhaps it has certain cases where it works, but throw something even mildly non-standard at it and it chokes. Currently, I just can't get Mozilla 1.1 to correctly display fonts. My setup, of course, is insane (CVS version of FreeType, Xft2, and 100% Type-1 fonts) but it works just fine on every build of KDE 3.x I've ever imposed it on. While all Qt based apps display text with incredible clarity, Mozilla's fonts look truely god aweful. And Phoenix, which kicks immense amounts of ass in Windows, only seems to be able to display what looks like Comic Sans (which is strange, because I don't HAVE Comic Sans) in Linux. I've tried editing unix.js to no avail. These custom font handling routines have gotta go (that includes you too, Abiword!) Just use Xft for god-sakes and stop trying to roll your own!
I wasn't pushing a particular language as the best. My post was a reaction to the original poster who claimed that in 5 years time everyone would be using C#. I was pointing out that everytime one of these new languages like Java and C# come out, everyone claims that C/C++ is finally dead, but those claims have yet to come true.
Almost every major open source project is in C or (sometimes) C++. Most major Windows programs are in C. It is only in custom programming situations that programs are writting in things like Java or C#.
But do you know how to change your tires? Replace gaskets? Fold down the rear seat? Replace a broken tail-light? Use the wipers? These are basic things you should know how to do in order to (safely) drive a car. I agree that the average user doesn't need to be a programmer, but requiring a basic understanding of what everything is and what parts do what isn't far-feteched and should be expected.
Hey, there is nothing wrong with elitists. If more people were elitists, and more people tried to be elite, then the general stupidity of the population would decrease...
Most of your complaints arise from bad design or poor tools. Its just as easy to make multiple threads communicate via well defined interfaces (messaging) as to make multiple processes communicate via well defined interfaces. There is the incentive to use global variables and whatnot, but that's just bad programming, and doesn't reflect on threads as a design feature. The main advantage of threads vs processes is that current APIs have a good deal of support of multithreaded programs, but not multiprocess programs. It's a lot easier to create a GUI program that handles all drawing and user-interface tasks in a seperate thread than to create a GUI program that handles these tasks in a seperate process, because the GUI toolkits have some level of support for threads.
I'm typing this in beta2 right now, and holy shit this is fast. My P4 2 GHz running Gentoo (freakish optimizations, check) now feels just as fast (UI-wise) as my old 750 MHz Duron running Win2K! And it (my P4, not beta2) compiles stuff a lot faster too! Beta2 only took 4 hours (kdelibs + kdebase, still building the other stuff:)
True, I should have qualified this. I was mainly referring to GUI code, where there is are a whole lot of disjoint tasks that could easily be multithreaded, but generally aren't on *NIX platforms.
I don't have to guess why. I know why SMP setups are more responsive under background loads. I don't like you're tone of voice. As for multithreading, I was talking about GUI apps, which generally aren't multithreaded on *NIX, not background apps.
To make optimal use of hyperthreading, I'm guessing the OS guys will have to do some work, like making sure that two threads with huge, non-overlapping data sets don't get scheduled at once, and trying to schedule threads who have overlapping datasets together. And it points out another thing. Again, just when we thought we had enough, we need MORE MEMORY BANDWIDTH. The tests show that while the dual channel RDRAM was fast enough for the two HT-enabled Xeon 2.0 GHz, it wasn't enough for the two 2.4 GHz Xeons.
Um, HT doesn't require supersentient compilers, it requires mildly sentient developers. Namely, developers have to make their programs multithreaded. In the Windows world, this happens already, far less so in the Linux world. Speaking of supersentient compilers, Intel C++ 6.0 supports OpenMP, even on Linux.
But I'd but it gives quite a boost to interactive performance. SMP setups tend to be wonderfully responsive under background loads (much more so than the sum of the CPU speeds would suggest) so I'd guess that allowing the CPU to run more than one thread at a time would make the UI a little more responsive on single-proc machines. Now, all we need are the UNIX developers to stop being afraid of multithreading and maybe some of us UNIX users would be able to take advantage of this:0
The "review" isn't meant to be useful in that sense. OSNews isn't, and doesn't claim to be, a site you go to to research and impending purchase. It's meant to be entertaining, to expose the OSNews readership to something they don't see everyday. It gives a little perspective on where the desktop OSs that people use everyday (Linux, Windows and MacOS) stand in relation to workstation OSs like IRIX. It's a computer-interest piece. And note, it's an "Introduction to IRIX." The word "review" doesn't appear in either the OSNews article OR the Slashdot post.
A pretty desktop doesn't necessarily require more power, just some taste. The IRIX color scheme, for one, is horrid. Then take the check-marks on the boxes. Really ugly. It would cost 0% performance to use a nicer looking checkmark. A bitmap is a bitmap, and an ugly one doesn't blit any faster than a nice-looking one.
Congratulations on failing to miss the point completely. She wasn't trying to do a review of IRIX as a server or workstation OS (which would logically be what you'd expect from an IRIX review). Her line of interest is in GUI/desktop usability, and she found it interesting to take a look at an OS that most people don't get to use, from a different perspective. It's not an evaluation of IRIX, but rather a look at it from her own particular field of interest.
It's not really something measurable by benchmarks. Most code (tar, gcc, etc) won't run faster. But in certain cases (like window rendering speed in X, image drawing speed in Qt, etc) the optimizations really kick in and it feels significantly faster. Unfortunately, there is no benchmark for UI speed (x11perf doesn't count because that's mostly HW accelerated) on Linux. There's one on Windows, so maybe that could be cloned?
Slashdot Mirror
I accidentally stepped on my StarCraft CD once. You bet I wish I had backed it up :)
Actually, toolkits and window managers will have to be tweeked to support the changes. Read the RandR docs on Keith Packard's site.
Yes. Most definately. Font rendering was never one of BeOS's strongest points. It was okay (better than Windows at the time), but the Bitstream renderer was showing its age. I was looking forward to the licensing deal with Bitstream to embed FontFusion (their new renderer) but that never happened. I saw FontFusion in action in QNX RtP and it was incredible. However, the version of FreeType in CVS right now is even better :)
Actually, with the FreeType CVS, the free Postscript fonts look just great. I've currently got the bytecode interpreter disabled because the autohinter in FreeType CVS is so good with Postscript fonts that it looks much better on my LCD than the hinted TrueType fonts. Letter shapes are a whole lot more accurate, while the outlines are still sharp. Read the FreeType mailing list (devel) sometime.
They've stopped sucking for a long time now. I don't know what cookie-cutter distro you use, but my Gentoo installed automatically included a TT-bytecode interpeter enabled FreeType and MS Windows fonts. When I got my UXGA laptop, there was initially some problem because the LCD looked best when all fonts were anti-aliased (it has enough resolution that AA text looks sharp rather than blurry) but all I had to do was download FreeType2 CVS, get some nice Postscript fonts, and I ended up with font rendering that whips OS X all over the place and easily matches ClearType.
Umm, whose logic is flawed? The original poster bashed RedHat for bowing to political pressures and dissing the Taiwanese. All you did was prove that it was in there best interest (economically, if not ethically) to do so.
The relevent clauses are 7 and 8 in the GPL Interestingly, the MP3 situation seems a bit fuzzy. They say that if you cannot redistribute the source freely (because of patents), then you cannot distribute the program at all. This does not necessarily mean that a GPL program cannot implemented patented non-open/free protocols. It just means that it can't implement such protocols if they require a license fee per copy, which until recently MP3 did not. Also, since most MP3 players are distributed mainly as source, it is questionable whether they violate the GPL. After all, FreeType includes the bytecode interpreter in the source, but that doesn't violate Apple's patent unless an actual product (binary) is generated with the bytecode interpreter enabled.
The font handling in Mozilla (and almost every other non-Qt or GTK 2.x app) sucks. Perhaps it has certain cases where it works, but throw something even mildly non-standard at it and it chokes. Currently, I just can't get Mozilla 1.1 to correctly display fonts. My setup, of course, is insane (CVS version of FreeType, Xft2, and 100% Type-1 fonts) but it works just fine on every build of KDE 3.x I've ever imposed it on. While all Qt based apps display text with incredible clarity, Mozilla's fonts look truely god aweful. And Phoenix, which kicks immense amounts of ass in Windows, only seems to be able to display what looks like Comic Sans (which is strange, because I don't HAVE Comic Sans) in Linux. I've tried editing unix.js to no avail. These custom font handling routines have gotta go (that includes you too, Abiword!) Just use Xft for god-sakes and stop trying to roll your own!
I wasn't pushing a particular language as the best. My post was a reaction to the original poster who claimed that in 5 years time everyone would be using C#. I was pointing out that everytime one of these new languages like Java and C# come out, everyone claims that C/C++ is finally dead, but those claims have yet to come true.
Almost every major open source project is in C or (sometimes) C++. Most major Windows programs are in C. It is only in custom programming situations that programs are writting in things like Java or C#.
Heh heh. Newbs are so funny. First its VB. Then its Java. Now its C#. Meanwhile, everyone is STILL USING C.
But do you know how to change your tires? Replace gaskets? Fold down the rear seat? Replace a broken tail-light? Use the wipers? These are basic things you should know how to do in order to (safely) drive a car. I agree that the average user doesn't need to be a programmer, but requiring a basic understanding of what everything is and what parts do what isn't far-feteched and should be expected.
Hey, there is nothing wrong with elitists. If more people were elitists, and more people tried to be elite, then the general stupidity of the population would decrease...
Most of your complaints arise from bad design or poor tools. Its just as easy to make multiple threads communicate via well defined interfaces (messaging) as to make multiple processes communicate via well defined interfaces. There is the incentive to use global variables and whatnot, but that's just bad programming, and doesn't reflect on threads as a design feature. The main advantage of threads vs processes is that current APIs have a good deal of support of multithreaded programs, but not multiprocess programs. It's a lot easier to create a GUI program that handles all drawing and user-interface tasks in a seperate thread than to create a GUI program that handles these tasks in a seperate process, because the GUI toolkits have some level of support for threads.
I'm typing this in beta2 right now, and holy shit this is fast. My P4 2 GHz running Gentoo (freakish optimizations, check) now feels just as fast (UI-wise) as my old 750 MHz Duron running Win2K! And it (my P4, not beta2) compiles stuff a lot faster too! Beta2 only took 4 hours (kdelibs + kdebase, still building the other stuff :)
True, I should have qualified this. I was mainly referring to GUI code, where there is are a whole lot of disjoint tasks that could easily be multithreaded, but generally aren't on *NIX platforms.
I don't have to guess why. I know why SMP setups are more responsive under background loads. I don't like you're tone of voice. As for multithreading, I was talking about GUI apps, which generally aren't multithreaded on *NIX, not background apps.
To make optimal use of hyperthreading, I'm guessing the OS guys will have to do some work, like making sure that two threads with huge, non-overlapping data sets don't get scheduled at once, and trying to schedule threads who have overlapping datasets together. And it points out another thing. Again, just when we thought we had enough, we need MORE MEMORY BANDWIDTH. The tests show that while the dual channel RDRAM was fast enough for the two HT-enabled Xeon 2.0 GHz, it wasn't enough for the two 2.4 GHz Xeons.
Um, HT doesn't require supersentient compilers, it requires mildly sentient developers. Namely, developers have to make their programs multithreaded. In the Windows world, this happens already, far less so in the Linux world. Speaking of supersentient compilers, Intel C++ 6.0 supports OpenMP, even on Linux.
But I'd but it gives quite a boost to interactive performance. SMP setups tend to be wonderfully responsive under background loads (much more so than the sum of the CPU speeds would suggest) so I'd guess that allowing the CPU to run more than one thread at a time would make the UI a little more responsive on single-proc machines. Now, all we need are the UNIX developers to stop being afraid of multithreading and maybe some of us UNIX users would be able to take advantage of this :0
The "review" isn't meant to be useful in that sense. OSNews isn't, and doesn't claim to be, a site you go to to research and impending purchase. It's meant to be entertaining, to expose the OSNews readership to something they don't see everyday. It gives a little perspective on where the desktop OSs that people use everyday (Linux, Windows and MacOS) stand in relation to workstation OSs like IRIX. It's a computer-interest piece. And note, it's an "Introduction to IRIX." The word "review" doesn't appear in either the OSNews article OR the Slashdot post.
A pretty desktop doesn't necessarily require more power, just some taste. The IRIX color scheme, for one, is horrid. Then take the check-marks on the boxes. Really ugly. It would cost 0% performance to use a nicer looking checkmark. A bitmap is a bitmap, and an ugly one doesn't blit any faster than a nice-looking one.
Actually, its just a matter of personal preference whether you put the comma after the last item before the "and" in a list.
You're a pedant, stickler, and an ignoramus.
is as correct as
You're a pedant, stickler and an ignoramus.
Congratulations on failing to miss the point completely. She wasn't trying to do a review of IRIX as a server or workstation OS (which would logically be what you'd expect from an IRIX review). Her line of interest is in GUI/desktop usability, and she found it interesting to take a look at an OS that most people don't get to use, from a different perspective. It's not an evaluation of IRIX, but rather a look at it from her own particular field of interest.
It's not really something measurable by benchmarks. Most code (tar, gcc, etc) won't run faster. But in certain cases (like window rendering speed in X, image drawing speed in Qt, etc) the optimizations really kick in and it feels significantly faster. Unfortunately, there is no benchmark for UI speed (x11perf doesn't count because that's mostly HW accelerated) on Linux. There's one on Windows, so maybe that could be cloned?