Yeah, you're right, I forgot about it! We are still working on it (and a new plugin for geeklog to handle direct editing of the tables - presently we are imputting everything via html) - and there will be directions in English on the frontpage (short descriptions of the tables and such) when we're done.
lol, you may know more about CRTs than I do (been reading up on LCD technologies and OLEDs in the past year). I don't know if the values given are designed around the phosphors or the capabilities of the tube.
I can't seem to find the link to the article about corellation b/w refresh rate and EM radiation (seemed very convincing when I read it, and it makes sense: why would a vendor recommend lower refresh rates at given resolutions if the monitor is capable of doing more? it might be to preserve its lifetime though...).
If you did read up and think I'm wrong, I would be pleased to read about it:)
LCD monitors don't have to be 100hz. In fact, hz value only determines the maximum framerate, so having a 60HZ lcd (at native resolution on a DVI link, analog link is usually 75hz) that only means that you get 60fps, which is more than enough for movies that only do 25 or 30, and games as well.
hz in CRT's is important because it is the refresh rate of pixels. A pixel in an LCD monitor doesn't refresh, it stays the same color until it is directed otherwise, in other words, there is no flicker at all (good for eyes). Now the biggest bullshit CRT monitor vendors pulled is the values they give for refresh rate. Before you turn your monitor to its maximum refresh rates, check out the default values your vendor gives for them! This is because CRT monitors have to adhere to certain standards. The TCO standars for instance defines the maximum radiotion a monitor might have. However, vendors cheat in a way that a TCO '03 monitor will only work at low radiation levels if you use it at the 'suggested' values. In other words, if your monitor's suggested resolution is 1600x1200@85hz, you should leave it at that, even if your monitor can do 110hz@1600x1200, because at 110Hz your TCO '03 monitor might not conform even to TCO '95 specs, and you will end up sitting before an electron cannon radiating at a level that wasn't OK even 10 years ago.
Long answer:
There are 3 lcd panel technologies: TN, *VA (MVA, PVA) and IPS. TN panels have achieved a very fast response time last year. My viewsonic vx912 has a response time of ~12ms, which is fine not only for movies, but for fast paced fps as well. The downside of TN panels is the smaller viewable angles, especially the vertical ones, and 6 bit panels (that achieve 16.2 million colors with a 'trick'). Contrast ratio is average.
*VA panels had an average of 25ms - that was fine for movies, and not so fine with games. Especially since 25ms was usually the black-to-white-to-black response time, and for some colors, switching could took as much as 60ms. However, *VA panels have excellent color reproduction capabilities (truly 8 bit panels) and excellent viewing angles, and high contrast ratio. S-IPS panels has also 25ms response time, but that's more or less even for every color transition. So a 25ms S-IPS panel is much faster than a *VA, has great viewing angles, good color reproduction, and sucky contrast. Newer S-IPS panels have improved on contrasts however a lot. APPLE displays have S-IPS panels (from LG.Philips).
Recently, various panel vendors (AUO, Samsung, Fujitsu) have experimented with increasing the response time of *VA panels. You'll see those panels described as P-MVA (premium mva) or S-MVA (super MVA), that boast a grey-to-gray response time of 8ms, while having still 25ms average response for non grey to grey transitions. Still, they proved to be excellent gaming monitors even for fps, without sacrificing viewing angles and contrast like in the case of IPS and TN panels, and they are out on the market and affordable. There is little or no reason to buy CRT-s now, because LCD Monitors are actually cheaper if you don't consider the initial price only! My 19'' LCD's average power consumption is 35W. A CRT with similar size (that would be a 20'' CRT) will consume 110+ Watts. Depending on your usage pattern, the additional cost of an LCD monitor can be saved up on energy usage in one to three years. Moreover, LCD monitors have perfect geometry (important for cad related works).
Ok, but you forgot one thing: you can't have radio buttons and menus for features like swapping the kernel scheduler. If you do, you need to have menus or radio buttons for everything. Which will prove to be a different kind of problem: finding the right button or menu entry in a probably very very cluttered interface;)
Now, just by looking at these lines - how do you accomplish the above task? Can there be a more straightforward way than this? So yes, editing textfiles to configure something is not necessarily arcane or difficult:)
Linux forks 5 times faster than BSD, but that's been known for years.
Hmmm... where did you read that? Even in the fefe test, freebsd and linux have very similar performance characteristics, and that's a two year old benchmark.Quote:
"FreeBSD looks like it would scale O(1) if I could create more processes with it, but as long as I can't confirm it, I can only give it the second place.
"
Check the graphs... and the corrections (author did not read man tuning, sysctl, the handbook... well, the documentation in general at first, so did not know how to set kern.maxproc).
Yeah, as others said, why don't you read the article? Care to explain why this comparison is flawed?
Since Apple sells xserve with an os x supposedly tuned for servers, in other words, it sells it as a package, it absolutely makes sense to compare it with other solutions. Whether fanboys like the results or not (and even if some have spare mod points to moderate a comment "insightful" even though except for stating that "the comparison is flawed" doesn't say much)
I think Sybase and Oracle found the linuxthreads package:) FreeBSD 4.x and early 5.x had problems with multithreaded applications like mysql, which has been solved in the newer versions. That's what the article says as well:
"This means that applications use slower user-level threads like in FreeBSD and not fast kernel threads like in Linux. It seems that FreeBSD 5.x has somewhat solved the performance problems that were typical for user-level threads, but we are not sure if Mac OS X has been able to take advantage of this.
In order to maintain binary compatibility, Apple might not have been able to implement some of the performance improvements found in the newer BSD kernels."
Yes, server performance with the xserve seems terrible right now, but I think that will be solved in the future, as apple will incorporate the enhanchements from fbsd 5, and more importantly 6. They are cooperating (freebsd and apple) it seems on many issues.
I understand that - actually your experience is in line with mine:) One problem is memory: firefox needs a lot. These machines had 96Mb or below.
Also, on windows, as I said, the problem is less visible. Moreover, if you want to see the problem, you have to do some CPU intensive task in the background (where CPU usage is more or less constant), start with a clean cache, and compare rendering some pages (especially ones with complex tables like this one. If your computer is more or less idle, and has plenty of ram (256 is fine, but if you upgrade to 512, it will be firefox where you'll notice significant perfomance improvement, especially with lots of tabs open) - you won't see much of a difference!
To make this long comment short: gecko uses more memory and more CPU to achieve the same speed as other browsers, including IE. Plus some platforms are more affected than others (linux, bsd, don't know about the Macs).
Yeah, I noticed the memory too - that's why I haven't even tried it on 64meg machines:( WinXP is where the slowness is less pronounced (but maybe because I haven't stress tested it, I mean running cpu intensive tasks in the background), but it is there on FreeBSD (my desktop machine and the workstation I tried) and linux as well. (Slackware on my desktop machine).
I tried several tweaks I found on the net (some specifically aimed at low end/high bandwidth machines) but they didn't make much of a difference - even though it was possible to limit memory usage. The problem is mem+cpu, in other words, it is a resource hog (which you won't notice if you run it on a more or less idle machine). Increasing memory has a huge impact on its performance, but it doesn make it on par with opera or khtml.
Disclaimer: I don't write this because I don't like Firefox. I write it because I care about it and free software in general. I spent considerable time for writing howtos and tips for various OS software I install on the machines in the small comp. lab I sysadmin: gimp, gaim (the most popular among the users), firefox (made it the default, yet some more computer savy users put back the IE icon on the desktop, so it was not that successful), etc. Also, I have the get firefox logo on the page near my username (www.tftpanel.hu) as well as on another site I maintain. I'm afraid however, that as the feature gap b/w IE and FF closes (with tabbed browsing and all in IE 7) users would find even less reason to switch (ordinary users, no./ readers mind you), especially if FF's performance is not on par with other browsers. There are three workstations that run FreeBSD with Blackbox and a simplified menu serving as "internet terminals" (that's how I named them so not to scare users with *nix talk). They are actually useful and well liked, but I had to install Opera on them, because they previously ran win98se (which was a nightmare to maintain), and my users only know that previously "the internet worked fine" (IE 5.x was not slow even on these machines) and now (with firefox) it doesn't (terrible load time, and clearly perceptible rendering slowdown). So firefox, after a short stay was replaced with Opera (even though opera is not a perfect solution either, because it has issues with more pages than FF).
As sad as it sounds, sometimes only publicity of a problem convinces developers to shift gears or change attitude (like in apple vs. khtml case) - and I don't see that (negative) publicity for the slowness of ff and gecko. I see lots of apologies, and I understand that, because we care, and we want Firefox to succeed, but actually this does disservice to FF on the long run. FF devs should realize that there is a serious issue (I know they know about it, they just don't see their users clamoring for change). Then they should throw whatever resources they have (and they have more than some other, equally important open source projects) at the problem. I wait with great anticipation for 1.1, but frankly, seeing the attitude of some of their developers, I don't have high hopes - I'm thinking of criticizing khtml devs for not cutting corners and keeping correctness, compactness (only 140.000 lines?) and cleanliness of code as important as features, even though those qualities make optimizations easier.
Thanks for your comment! This has been driving me nuts. I installed firefox on various hardware, and on low and machines, it really really sucked. So I've been arguing for some time that the gecko engine (I notice the cpu-usage spikes as well) is really slow, compared to ie, opera or khtml. And always someone replied that he or she tried it, and it wasn't slow, like here. I had (and still have) little reason to doubt those comments, but they are run contrary to my own experience.
Also, it's not on one machine, its on multiple machines running various OSs. The lower you go, the slower gecko gets. On a 533mhz machine (IBM PC 300) with 96Mb ram, firefox (and epiphany, tried both,hoping that epiphany might contain some gecko optimizations) was slower to render some pages while doing nothing else than opera was while compiling software in the background. The slowness is less pronounced on newer hardware, and curiously on windows! But I can still see it very clearly on my home pc (athlon xp 2400+ with 512RAM) if I do something CPU intensive in the background (like having multiple compiles running, downloading a huge file, listening to music at the same time). On an idle computer, you won't really see the difference, but if you have a cpu-monitoring tool running (I h ave kcpuload) you can easily notice that gecko to render the same pages with the same speed as khtml, grabs a lot more of the CPU than the latter. When those resources are scarce, it will be significantly slower than browsers built on other engines (Opera seems to kick ass along with khtml).
...If they started to give out modules that provided certain functionality...
I was looking for help on url_rewrite on google, when I bumped into some threads where users complained about $company's url_rewrite module not working as expected. He said that he regrets paying for it now. Others suggested him to try out isapi rewrite... another pay for module that only provides freaking rewrite functionality. When I read those, I was soooo glad I never had to deal with IIS - I would have never thought that IIS users must go out hunting on google and actually pay for new modules for IIS that are compeletely free (and immediately available) for apache...
Oh, I was referring to ebrahim's blog:))) Sorry if it wasn't clear:) - it was a bit annoying to see how mockery is not enough, they have to talk about possible trademark violations, which is such a nonsense in this case! So my comment was directed against the blog entry, not your post:)
Now that is nitpicking at its worst - they don't sell their product under the brand Firefox. They merely state that their product is based on Firefox - is there anything wrong with that? At least it is more informative than saying that it is based on gecko - which can be the gecko present in Mozilla, Firefox, or any other derivative.
The irony is, that this is exactly what the INQ. article is about. Furthermore:
It can create a bad impression on Mozilla applications if other apps that proudly boast that they're based on such apps don't release updates in a timely manner.
Have you read the article actually? It is exactly about the unneded mockery of Goodger, who fails to note that Netscape released an update as fast as humanly possible - less than a day after release. I think that qualifies as "timely manner".
FUD doesn't need to be an outright lie. Quote from the article:
As we reported, Goodger said of Netscape's v8.0 browser: ""If security is important to you, this demonstration should show that browsers that are redistributions of the official Mozilla releases are never going to give you security updates as quickly as Mozilla will itself for its supported products". He was referring to the fact that Netscape initially made v8.0 available, which was based on Firefox 1.03.
There's one important fact that Mr. Goodger forgets... less than 24 hours after the initial Netscape v8.0 was posted, AOL made available version 8.01 which is based in Firefox 1.04 and hence fixes the three vulnerabilities present in Firefox 1.03. In fact, when I clicked the "download Netscape 8.0" link on early Friday in order to test it and write my review, I already got the fixed version 8.01. That does speak quite well of AOL's reaction time after the initial mishap of shipping their browser based on Firefox 1.03.
Now that might qualify as FUD - but at any rate, it is a very close to it. Goodger presents his view in such a way that one gets the impression that only Mozilla Foundation can guarantee the security of (gecko based) browsers. True or not? Well, it is true, but this is not the result of these competitors being lazy or slow, it is partly the result of the lack of cooperation and coordination on the part of the Project. Yeah, I read all the apologies in the previous./ thread - and I don't agree with them. It seems to me that some think that you can't be both a fan and critical of Mozilla Found. I think you can... in fact, if you really are a fan, then it is prudent to criticize if you feel your fav. project is heading in the wrong direction.
And it does... take a step back and read the Inq. article - is it really unreasonable? I think it makes a lot of sense, especially if you read the paragraphs below the ones I quoted, and see where such arrogance might lead. (Yeah, arrogance the same arrogance you could see in their response to the apple/khtml "issue").
Perhaps you should ask the KDE folks (or browse their mailing list) - they just converted from CVS to subversion. Being such a large project and all, they must have encountered most of the issues one can in such a conversion.
Once I criticized this guy (in a comment) for an even more shallow review FreeBSD 5.3 - because I firmly believed (and I still believe) that he didn't even bother to install it:)) He wrote a review on 5.2 a few months before that, which was very critical (and rightfully so, 5.2 was a quite flaky release) but at the same a really good review. In his 5.3 review he basically recirculated the points he made for 5.2, and even got some really weird factual mistakes. His response was to put me on his foe list... now that's a pretty childish behaviour, isn't it?
Later he wrote an article on newsforge about "Being Free is Hard to Do" on free software, than he submitted this article to slashdot under his nick (ValourX), describing it in the following terms:
What is more important to you -- the four freedoms of Free Software, or the ability to maximize the value of your computer? It's a question that comes up on Slashdot often, but rarely is it so well argued as it is in this NewsForge article.Link.
What shameless self promotion! It is a pity, for once this guy wrote excellent reviews and articles, but what he does lately is prostitution, not journalism.
Well, true... but the fact that you can install an application (even a fairly large one like KDE) in a chroot/jail environment is not news. The news is that the blog shows how to do it on Solaris. Which is fine and all but I am not sure if it is supposed to be a front page matter or not... just look at the comments;)
On the other hand, a rewording of the submission (something like "how can I do this in linux/bsd") would have been better to provoke discussion - for instance, installing kde in a jail is fairly straightforward, migrating it outside the jail (making it available system wide) might not be as easy as in Solaris it seems. Or who knows - I haven't thought about it, so it might be trivial...
Bad story icon
on
KDE in a Zone
·
· Score: 2, Insightful
This is not penguin news, this is about kde on solaris.
One interesting comparison is memory usage of new kate compared to present one. KDE developers do an amazing job when it comes to code optimizations - and it seems they will do it again for KDE 4.
I began using Linux with RH 7.3 & KDE 3.0 on an old 700Mhz Duron with 256Mb SDRAM. I kept running linux - and later FreeBSD - and KDE on this machine for two years, and every major KDE release seemed like a minor hardware upgrade. That is one of the reasons I kept that old machine for that long - and longer, previously it had win98se installed. First, I thought I will either replace it completely or buy more RAM, better CPU in half a year. Then as I went through each KDE realese - and probably better C++ support in gcc also helped - I felt less and less the need to upgrade the hw. I wonder how long they can keep up producing more efficient code that runs better and better on old hardware. Currently KDE 3.4 has only one 'serious' requirement: memory. If you have 256+, itt will run nicely on a 300Mhz celeron, but of course, you'll have to turn off some eyecandies to reach an agreeable performance.
Slashdot Mirror
They might complain about xfree 4.3
Yeah, you're right, I forgot about it! We are still working on it (and a new plugin for geeklog to handle direct editing of the tables - presently we are imputting everything via html) - and there will be directions in English on the frontpage (short descriptions of the tables and such) when we're done.
I can't seem to find the link to the article about corellation b/w refresh rate and EM radiation (seemed very convincing when I read it, and it makes sense: why would a vendor recommend lower refresh rates at given resolutions if the monitor is capable of doing more? it might be to preserve its lifetime though...).
If you did read up and think I'm wrong, I would be pleased to read about it :)
hz in CRT's is important because it is the refresh rate of pixels. A pixel in an LCD monitor doesn't refresh, it stays the same color until it is directed otherwise, in other words, there is no flicker at all (good for eyes). Now the biggest bullshit CRT monitor vendors pulled is the values they give for refresh rate. Before you turn your monitor to its maximum refresh rates, check out the default values your vendor gives for them! This is because CRT monitors have to adhere to certain standards. The TCO standars for instance defines the maximum radiotion a monitor might have. However, vendors cheat in a way that a TCO '03 monitor will only work at low radiation levels if you use it at the 'suggested' values. In other words, if your monitor's suggested resolution is 1600x1200@85hz, you should leave it at that, even if your monitor can do 110hz@1600x1200, because at 110Hz your TCO '03 monitor might not conform even to TCO '95 specs, and you will end up sitting before an electron cannon radiating at a level that wasn't OK even 10 years ago.
Long answer:
There are 3 lcd panel technologies: TN, *VA (MVA, PVA) and IPS. TN panels have achieved a very fast response time last year. My viewsonic vx912 has a response time of ~12ms, which is fine not only for movies, but for fast paced fps as well. The downside of TN panels is the smaller viewable angles, especially the vertical ones, and 6 bit panels (that achieve 16.2 million colors with a 'trick'). Contrast ratio is average.
*VA panels had an average of 25ms - that was fine for movies, and not so fine with games. Especially since 25ms was usually the black-to-white-to-black response time, and for some colors, switching could took as much as 60ms. However, *VA panels have excellent color reproduction capabilities (truly 8 bit panels) and excellent viewing angles, and high contrast ratio. S-IPS panels has also 25ms response time, but that's more or less even for every color transition. So a 25ms S-IPS panel is much faster than a *VA, has great viewing angles, good color reproduction, and sucky contrast. Newer S-IPS panels have improved on contrasts however a lot. APPLE displays have S-IPS panels (from LG.Philips).
Recently, various panel vendors (AUO, Samsung, Fujitsu) have experimented with increasing the response time of *VA panels. You'll see those panels described as P-MVA (premium mva) or S-MVA (super MVA), that boast a grey-to-gray response time of 8ms, while having still 25ms average response for non grey to grey transitions. Still, they proved to be excellent gaming monitors even for fps, without sacrificing viewing angles and contrast like in the case of IPS and TN panels, and they are out on the market and affordable. There is little or no reason to buy CRT-s now, because LCD Monitors are actually cheaper if you don't consider the initial price only! My 19'' LCD's average power consumption is 35W. A CRT with similar size (that would be a 20'' CRT) will consume 110+ Watts. Depending on your usage pattern, the additional cost of an LCD monitor can be saved up on energy usage in one to three years. Moreover, LCD monitors have perfect geometry (important for cad related works).
I put a site, a community effort to create a table of what's what in LCD land. The site is here. direct link to monitor table, and a direct link to LCD-TV table. If you are looking for characteristics of various panels (not end products), you'll find them here.
Ok, but you forgot one thing: you can't have radio buttons and menus for features like swapping the kernel scheduler. If you do, you need to have menus or radio buttons for everything. Which will prove to be a different kind of problem: finding the right button or menu entry in a probably very very cluttered interface ;)
Yes, absolutely agree, here is an example (for straightforwardness):
Now, just by looking at these lines - how do you accomplish the above task? Can there be a more straightforward way than this? So yes, editing textfiles to configure something is not necessarily arcane or difficultTask: change the kernel scheduler.
Solution:
Hmmm... where did you read that? Even in the fefe test, freebsd and linux have very similar performance characteristics, and that's a two year old benchmark.Quote:
"FreeBSD looks like it would scale O(1) if I could create more processes with it, but as long as I can't confirm it, I can only give it the second place.
"
Check the graphs ... and the corrections (author did not read man tuning, sysctl, the handbook... well, the documentation in general at first, so did not know how to set kern.maxproc).
You're welcome (to this information) :)
Since Apple sells xserve with an os x supposedly tuned for servers, in other words, it sells it as a package, it absolutely makes sense to compare it with other solutions. Whether fanboys like the results or not (and even if some have spare mod points to moderate a comment "insightful" even though except for stating that "the comparison is flawed" doesn't say much)
"This means that applications use slower user-level threads like in FreeBSD and not fast kernel threads like in Linux. It seems that FreeBSD 5.x has somewhat solved the performance problems that were typical for user-level threads, but we are not sure if Mac OS X has been able to take advantage of this.
In order to maintain binary compatibility, Apple might not have been able to implement some of the performance improvements found in the newer BSD kernels."
Yes, server performance with the xserve seems terrible right now, but I think that will be solved in the future, as apple will incorporate the enhanchements from fbsd 5, and more importantly 6. They are cooperating (freebsd and apple) it seems on many issues.
Also, on windows, as I said, the problem is less visible. Moreover, if you want to see the problem, you have to do some CPU intensive task in the background (where CPU usage is more or less constant), start with a clean cache, and compare rendering some pages (especially ones with complex tables like this one. If your computer is more or less idle, and has plenty of ram (256 is fine, but if you upgrade to 512, it will be firefox where you'll notice significant perfomance improvement, especially with lots of tabs open) - you won't see much of a difference!
To make this long comment short: gecko uses more memory and more CPU to achieve the same speed as other browsers, including IE. Plus some platforms are more affected than others (linux, bsd, don't know about the Macs).
I tried several tweaks I found on the net (some specifically aimed at low end/high bandwidth machines) but they didn't make much of a difference - even though it was possible to limit memory usage. The problem is mem+cpu, in other words, it is a resource hog (which you won't notice if you run it on a more or less idle machine). Increasing memory has a huge impact on its performance, but it doesn make it on par with opera or khtml.
Disclaimer: I don't write this because I don't like Firefox. I write it because I care about it and free software in general. I spent considerable time for writing howtos and tips for various OS software I install on the machines in the small comp. lab I sysadmin: gimp, gaim (the most popular among the users), firefox (made it the default, yet some more computer savy users put back the IE icon on the desktop, so it was not that successful), etc. Also, I have the get firefox logo on the page near my username (www.tftpanel.hu) as well as on another site I maintain. I'm afraid however, that as the feature gap b/w IE and FF closes (with tabbed browsing and all in IE 7) users would find even less reason to switch (ordinary users, no ./ readers mind you), especially if FF's performance is not on par with other browsers. There are three workstations that run FreeBSD with Blackbox and a simplified menu serving as "internet terminals" (that's how I named them so not to scare users with *nix talk). They are actually useful and well liked, but I had to install Opera on them, because they previously ran win98se (which was a nightmare to maintain), and my users only know that previously "the internet worked fine" (IE 5.x was not slow even on these machines) and now (with firefox) it doesn't (terrible load time, and clearly perceptible rendering slowdown). So firefox, after a short stay was replaced with Opera (even though opera is not a perfect solution either, because it has issues with more pages than FF).
As sad as it sounds, sometimes only publicity of a problem convinces developers to shift gears or change attitude (like in apple vs. khtml case) - and I don't see that (negative) publicity for the slowness of ff and gecko. I see lots of apologies, and I understand that, because we care, and we want Firefox to succeed, but actually this does disservice to FF on the long run. FF devs should realize that there is a serious issue (I know they know about it, they just don't see their users clamoring for change). Then they should throw whatever resources they have (and they have more than some other, equally important open source projects) at the problem. I wait with great anticipation for 1.1, but frankly, seeing the attitude of some of their developers, I don't have high hopes - I'm thinking of criticizing khtml devs for not cutting corners and keeping correctness, compactness (only 140.000 lines?) and cleanliness of code as important as features, even though those qualities make optimizations easier.
Also, it's not on one machine, its on multiple machines running various OSs. The lower you go, the slower gecko gets. On a 533mhz machine (IBM PC 300) with 96Mb ram, firefox (and epiphany, tried both,hoping that epiphany might contain some gecko optimizations) was slower to render some pages while doing nothing else than opera was while compiling software in the background. The slowness is less pronounced on newer hardware, and curiously on windows! But I can still see it very clearly on my home pc (athlon xp 2400+ with 512RAM) if I do something CPU intensive in the background (like having multiple compiles running, downloading a huge file, listening to music at the same time). On an idle computer, you won't really see the difference, but if you have a cpu-monitoring tool running (I h ave kcpuload) you can easily notice that gecko to render the same pages with the same speed as khtml, grabs a lot more of the CPU than the latter. When those resources are scarce, it will be significantly slower than browsers built on other engines (Opera seems to kick ass along with khtml).
I was looking for help on url_rewrite on google, when I bumped into some threads where users complained about $company's url_rewrite module not working as expected. He said that he regrets paying for it now. Others suggested him to try out isapi rewrite ... another pay for module that only provides freaking rewrite functionality. When I read those, I was soooo glad I never had to deal with IIS - I would have never thought that IIS users must go out hunting on google and actually pay for new modules for IIS that are compeletely free (and immediately available) for apache...
Oh, I was referring to ebrahim's blog :))) Sorry if it wasn't clear :) - it was a bit annoying to see how mockery is not enough, they have to talk about possible trademark violations, which is such a nonsense in this case! So my comment was directed against the blog entry, not your post :)
The irony is, that this is exactly what the INQ. article is about. Furthermore:
It can create a bad impression on Mozilla applications if other apps that proudly boast that they're based on such apps don't release updates in a timely manner.
Have you read the article actually? It is exactly about the unneded mockery of Goodger, who fails to note that Netscape released an update as fast as humanly possible - less than a day after release. I think that qualifies as "timely manner".
There's one important fact that Mr. Goodger forgets... less than 24 hours after the initial Netscape v8.0 was posted, AOL made available version 8.01 which is based in Firefox 1.04 and hence fixes the three vulnerabilities present in Firefox 1.03. In fact, when I clicked the "download Netscape 8.0" link on early Friday in order to test it and write my review, I already got the fixed version 8.01. That does speak quite well of AOL's reaction time after the initial mishap of shipping their browser based on Firefox 1.03. Now that might qualify as FUD - but at any rate, it is a very close to it. Goodger presents his view in such a way that one gets the impression that only Mozilla Foundation can guarantee the security of (gecko based) browsers. True or not? Well, it is true, but this is not the result of these competitors being lazy or slow, it is partly the result of the lack of cooperation and coordination on the part of the Project. Yeah, I read all the apologies in the previous ./ thread - and I don't agree with them. It seems to me that some think that you can't be both a fan and critical of Mozilla Found. I think you can ... in fact, if you really are a fan, then it is prudent to criticize if you feel your fav. project is heading in the wrong direction.
And it does ... take a step back and read the Inq. article - is it really unreasonable? I think it makes a lot of sense, especially if you read the paragraphs below the ones I quoted, and see where such arrogance might lead. (Yeah, arrogance the same arrogance you could see in their response to the apple/khtml "issue").
For GOD's sake, check the dates before you moderate!
Perhaps you should ask the KDE folks (or browse their mailing list) - they just converted from CVS to subversion. Being such a large project and all, they must have encountered most of the issues one can in such a conversion.
Now only if I could learn to spell correctly ;)))
Hey, forgot to add your hobbyhorse. Or was it deliberate?
Later he wrote an article on newsforge about "Being Free is Hard to Do" on free software, than he submitted this article to slashdot under his nick (ValourX), describing it in the following terms:
What shameless self promotion! It is a pity, for once this guy wrote excellent reviews and articles, but what he does lately is prostitution, not journalism.On the other hand, a rewording of the submission (something like "how can I do this in linux/bsd") would have been better to provoke discussion - for instance, installing kde in a jail is fairly straightforward, migrating it outside the jail (making it available system wide) might not be as easy as in Solaris it seems. Or who knows - I haven't thought about it, so it might be trivial...
This is not penguin news, this is about kde on solaris.
I began using Linux with RH 7.3 & KDE 3.0 on an old 700Mhz Duron with 256Mb SDRAM. I kept running linux - and later FreeBSD - and KDE on this machine for two years, and every major KDE release seemed like a minor hardware upgrade. That is one of the reasons I kept that old machine for that long - and longer, previously it had win98se installed. First, I thought I will either replace it completely or buy more RAM, better CPU in half a year. Then as I went through each KDE realese - and probably better C++ support in gcc also helped - I felt less and less the need to upgrade the hw. I wonder how long they can keep up producing more efficient code that runs better and better on old hardware. Currently KDE 3.4 has only one 'serious' requirement: memory. If you have 256+, itt will run nicely on a 300Mhz celeron, but of course, you'll have to turn off some eyecandies to reach an agreeable performance.
Keep up the good work guys and gals!