For those who have been playing with the beta: what's involved in transforming KDE-rh back into "pure" KDE with all the defaults? The article mentions some code changes. The menus have been changed. Would I have to manually edit the menus, dialogs, links etc or is there a "gimme plain KDE" option?
My speculation on why, from the perspective of KDE, this sort of thing is upsetting:
KDE credits removed from "about" boxes. The article admits that they do not (yet) have a policy to give KDE or Gnome due credit.
Code fork. The article mentions code modifications. This means it will be hard to get comparable updates when new versions of KDE appear. Given Red Hat's abysmal record with providing new KDE RPMs, users will be stuck with an obsolete version of KDE.
Gnome favoritism. The article admits that Red Hat does a better job with Gnome than KDE, yet will not let KDE be itself.
Application hiding. Menus dinkered to favor non-KDE apps.
Since you did not explain why your preferred choices are superior, it's hard to agree with you.
Qmail's license is restricted. You cannot redistribute modified versions of Qmail -- even security fixes -- without Bernstein's permission. I doubt if a government wants their project to be potentially held hostage to the whims of a single man, no matter how competent. It would hardly do to free oneself from corporate domination (Microsoft) only to come under another sort of bondage (Bernstein).
Cyrus-IMAP is a solid, powerful and proven IMAP server. Its documentation could use some help, but as an IMAP server I don't know of any significant disadvantage it has relative to Courier-IMAP.
For one thing, iscan (ImageScan!) is simpler and friendlier. Ease of use is crucial, especially when I want to share my scanner with novices. Xsane's UI (like many open source UIs) is clunky by comparison. The other reason is that there is some image enhancement going on in there. Pictures come out looking sharper and with richer colors than in xsane. Now, it is probably possible to get equivalent picture quality from xsane after a lot of work in Gimp, but do you expect me to ask a novice to figure that out?
The other attraction is that hilarious picture of a penguin stuffed into a scanner with its butt in the air and its flattened face appearing on the computer screen. Shows they have a sense of humor.
I don't understand why people think LSB makes UnitedLinux unnecessary. UnitedLinux and LSB are not the same thing: the former builds on top of the latter. In addition to the minimalist feature set in LSB, UL specifies a Java runtime, an SQL server, a printing system (CUPS), assorted networking stuff, KDE 3 and Gnome 2 libraries etc. See their white paper. This is a full, rich platform for third party apps. By contrast, LSB does not even specify Qt or Gtk libraries: you can't even target LSB with GUI apps. LSB alone is just not enough as a platform.
It's not about sharing profiles. That line in prefs.js is what you would set for Netscape 7.0 if you wanted to disable popups. So even if you did not install Mozilla, you could not disable popups that way unless you sacrificed Radio@Netscape.
Why you may not want to disable popups
on
Netscape 7.0 is Out
·
· Score: 3, Informative
From their release notes:
Opening Radio@Netscape may instead open a blank window if you share a profile with Mozilla. Workaround: Remove the following line from prefs.js:
user_pref("dom.disable_open_during_load", true);
It seems Radio@Netscape depends on popups to work.
Yes, but which of those are free and not patent-encumbered? You cannot use Ogg with AVI, from what I read, and no open source Divx codecs use the new mp4 file format. The new, technically superior AAC audio format that is associated with MPEG-4 is also patent-encumbered and requires license fees. And practically speaking, you are going to see DivX movies -- particularly the commercial distributors -- distributed with MP3 or AAC audio. A Divx player that cannot handle both of these formats will be crippled, sort of like a Betamax VCR today.
This patent is more directly relevant to DivX than you described. Basically, classic Divx is an AVI file that combines MPEG-4 video with MP3 audio. Without paying a fee, none of the open source DivX codecs are legal, since they are all using MP3 for their audio.
It's not just the rendering speed that is fast. The GUI is fast too. Of course, a banana slug will look fast when you are looking at Mozilla's GUI, but Opera is pretty snappy in its own right.
The cache handling is probably one of the most noticeable places where Opera is fast. No browser I have seen can whip out a page from cache like Opera. Since my browsing habits involve hitting the "back" button often, the snappiness is noticeable. Moreover, caching is highly configurable. No matter how slow your Internet connection, cache performance makes a difference.
Opera also has some UI conveniences that makes its featues very accessible. The quick preferences menu lets you toggle popups, plugins, GIF animation and proxies by hitting F12 and a click. Toggling image loading is a mouseclick away. My favorite feature is the button that toggles author/user mode styles: on pages with lousy fonts/colors, you get instant readability with a click. All these, too, save time and makes things fast.
There are a couple of Opera features that make it hard for me to switch to any other browser:
Firstly, it pioneered mouse gestures: I'm so used to navigating with the mouse (for example, back/forward through history) that it's annoying to use a browser without this feature.
Secondly, no browser on the planet seems to whip out pages from cache anywhere as fast as Opera. They just seem to snap onto the screen, (again) making browsing through history a breeze.
Finally my favorite: the little author/user mode toggle button. I can't stand the font/color choices on many pages, but a single click of the mouse instantly makes a web page readable in Opera. Not relevant to the IE/Opera debate, but this is a great feature for Linux users as TT fonts often come up too tiny on many web sites.
I think you need more sleep. Do you even realized what you typed?
Kdehelp back button not working: you reported this bug! You filed it as bugs.kde.org: "Bug#31123: Back button in khelpcenter has no effect". There's no denying the bug reported by someone as dependable as your honorable self.
Bad version of Qt: the KDE 2.2.2 release page explicitly tells you not to use Qt 2.3.2. Guess which version of Qt you decided to use with the Red Hat RPMs? Yup: qt 2.3.2 and it's an RPM dependency. The frozen desktop bug is documented at bugs.kde.org as bug 34949 ("system freeze on KDE startup").
So: get some sleep and write again when your fingers are resynced with reality. I want my KDE to work. "Not reproducible here" does not sound like a good excuse at this point.
Junkbuster does not support HTTP/1.1, so a lot of browsers have problems with it. There is no ad-blocking proxy "supported" by RH as far as I know. The apparent successor to Junkbuster is Privoxy: it's not yet officially supported but it seems to usable now.
I have been underwhelmed by Red Hat's packaging of KDE in the past. For example, in a boxed release (either 7.1 or 7.2), kdehelp's "back" and "forward" buttons didn't work. When KDE 2.2.2 RPMs were released, they helpfully included (and required) a version of Qt that froze the desktop: I had to disable klipper. The current KDE3 RPMs for RH 7.2 from Red Hat have their own glitches: ksplash goes kblooie at startup, and konqueror seems to have this big memory leak that bloats its footprint over time. I wonder if anyone at Red Hat even tries to use KDE.
How is KDE3 running on RH 7.3? Does Konq still have that memory leak?
Where are you located? A $40K salary would be pretty comfortable in Iowa, and $63K is going to be tight in Silicon Valley. If you are not in the US, consider also the strength of the US dollar. Considering the exchange rate, cost of living and housing, things may not look so bad.
Right now, it's hard to evaluate office suites for the office environment. The problem, I think, is that techie reviewers usually are not familiar with the problems that they are used to solve. I don't care how well SOT imports memos: there are bigger things.
Excel is an amazing program. Think of it as a visual development platform complete with an IDE with context sensitive help, huge function library, built-in goal-seeking/optimization engine, cross-tabbing, statistics engine, monte carlo simulations, graphing, GUI (you can embed buttons/menus), DB functionality etc. Oh, and WYSIWYG reporting/printing comes free. People develop sophisticated business applications with Excel. Text books exist for this purpose. Real programmers may like to say "use a real programming language!", but the fact is that nonprogrammers can very quickly crank out powerful, maintainable apps relatively free of bugs. And many do: it's the right tool for many jobs.
So what does this have to do with the success of a new office suite? The question is the ease of migration. It's one thing to preserve the formatting of a Word memo. It's another to be able to import sophisticated Excel applications with confidence. Otherwise, the penetration of a rival office suite into the corporate environment will be severely hampered.
Those numbers are rather interesting. KDE has always shared a lot of memory, but previously we could have some idea of what each individual app used by subtracting the SHARE column from the SIZE column. Here, however, KDE apps' SIZE column is at least 50MB-ish, far exceeding the SHARE column. Something funny seems to have happened that affects KDE's memory accounting. Perhaps video memory is being mapped into every single KDE app.
One can compare memory footprint by looking at the free memory available immediately after loading each desktop. This would get around the difficult shared memory accounting.
Too many reviews focus on installation. This review contains less info than the KDE press release. How about a little hands-on insight? How does KDE 3 compare to its predecessor in terms of startup time (with/without prelink/objprelink)? Runtime performance? Memory footprint? Can we see some numbers? It's a pity that reviews geared towards techies are often lacking in quantitative information.
The ad targets Linux too. They hit upon the system's "complexity" and the need to hire "expensive experts". Think about it: Windows, more than any other server OS, can give a perception of user-friendliness. Look at the sysadmin tools on your typical Red Hat distro: we're still working with stone knives and bear skins. I am saying this as a long-time Red Hat user.
This may not improve much. Companies like Red Hat, MySQL AB and Sendmail Inc sell support for essentially free products. There is a certain incentive there to maintain some complexity so they can continue to sell support. Counter-arguments need to be marshalled on the ease of use issue, not to mention real solutions.
"So since you have no fortran programers, and probably can't find a good one, what happens when your pay-roll program breaks, not have payroll for 4 months... ?"
How would an unmodified payroll program that has worked for decades "break", especially if there are no Fortran programmers to break it?
I wouldn't call a half minute startup time "acceptable". While I have 128MB of RAM too, I resent having to surrender so much of it to a single program. With other big apps (KDE, XEmacs, Java) competing, I can ill afford another bulky app. I would rather use Konqueror or Opera. I see some indication of progress on the footprint front. Still, there is no indication that it will relinquish its title of "bulkiest and slowest". So regardless of the machine I use, it will continue to compare poorly to its competition on that score.
Mozilla is the bulkiest, slowest browser available for Linux. I mean that not as a troll, but as a fact from which I am asking this question. I check it out every few months, but have been disappointed with its bulk. Can anyone tell me what the trend is with the memory footprint? Are there measurable improvements?
There are possible replies that have nothing to do with my question, but will probably come up anyway:
"The rendering speed is great!": yeah, but the UI is a slug.
"Galeon bla bla bla...": I am not talking about Galeon, but Mozilla. Besides, Galeon's footprint is not that small either.
"Use a lightweight browser...": I already have links, lynx, Konq, Opera and Dillo. This is a question about Mozilla.
"Get a REAL computer! Memory is cheap!": let me call attention to my PayPal account, where you can deposit funds for my next computer purchase. Seriously, even on a fast PC a slow browser will still look bad relative to its competitors.
"Standards compliant, open source, bla bla": yeah, but it's still a dog.
Yes, but the command line iSiloXC utility is ridiculously complex. You have to write an XML file (no DTD provided) to convert anything! Is there a command line utility less user-friendly than this? I prefer to use wget to save the HTML onto the hard disk. After that I can use the older convertor for iSilo 2 (you can still download it): you only need to specify the root HTML file and it will do the rest. You could use wget in a cron job, and if you decide to switch to Plucker you can simply switch the convertor that you use on the downloaded files.
Red Hat 7.2 has inconsistent policies for its use of Freetype. The freetype library itself has bytecode interpretation disabled so installing your version will greatly enhance its quality. But the X server/xfs was built with bytecode interpretation enabled. This means you can also greatly enhance font rendering by not enabling antialiasing. If you use the core X server font rendering -- which is the default -- the font (if well hinted) will look good.
Slashdot Mirror
For those who have been playing with the beta: what's involved in transforming KDE-rh back into "pure" KDE with all the defaults? The article mentions some code changes. The menus have been changed. Would I have to manually edit the menus, dialogs, links etc or is there a "gimme plain KDE" option?
Chris
Since you did not explain why your preferred choices are superior, it's hard to agree with you.
Qmail's license is restricted. You cannot redistribute modified versions of Qmail -- even security fixes -- without Bernstein's permission. I doubt if a government wants their project to be potentially held hostage to the whims of a single man, no matter how competent. It would hardly do to free oneself from corporate domination (Microsoft) only to come under another sort of bondage (Bernstein).
Cyrus-IMAP is a solid, powerful and proven IMAP server. Its documentation could use some help, but as an IMAP server I don't know of any significant disadvantage it has relative to Courier-IMAP.
For one thing, iscan (ImageScan!) is simpler and friendlier. Ease of use is crucial, especially when I want to share my scanner with novices. Xsane's UI (like many open source UIs) is clunky by comparison. The other reason is that there is some image enhancement going on in there. Pictures come out looking sharper and with richer colors than in xsane. Now, it is probably possible to get equivalent picture quality from xsane after a lot of work in Gimp, but do you expect me to ask a novice to figure that out?
The other attraction is that hilarious picture of a penguin stuffed into a scanner with its butt in the air and its flattened face appearing on the computer screen. Shows they have a sense of humor.
I don't understand why people think LSB makes UnitedLinux unnecessary. UnitedLinux and LSB are not the same thing: the former builds on top of the latter. In addition to the minimalist feature set in LSB, UL specifies a Java runtime, an SQL server, a printing system (CUPS), assorted networking stuff, KDE 3 and Gnome 2 libraries etc. See their white paper. This is a full, rich platform for third party apps. By contrast, LSB does not even specify Qt or Gtk libraries: you can't even target LSB with GUI apps. LSB alone is just not enough as a platform.
It's not about sharing profiles. That line in prefs.js is what you would set for Netscape 7.0 if you wanted to disable popups. So even if you did not install Mozilla, you could not disable popups that way unless you sacrificed Radio@Netscape.
It seems Radio@Netscape depends on popups to work.
Yes, but which of those are free and not patent-encumbered? You cannot use Ogg with AVI, from what I read, and no open source Divx codecs use the new mp4 file format. The new, technically superior AAC audio format that is associated with MPEG-4 is also patent-encumbered and requires license fees. And practically speaking, you are going to see DivX movies -- particularly the commercial distributors -- distributed with MP3 or AAC audio. A Divx player that cannot handle both of these formats will be crippled, sort of like a Betamax VCR today.
This patent is more directly relevant to DivX than you described. Basically, classic Divx is an AVI file that combines MPEG-4 video with MP3 audio. Without paying a fee, none of the open source DivX codecs are legal, since they are all using MP3 for their audio.
LSB does not cover Qt nor KDE, environments that Kapital depends on.
It's not just the rendering speed that is fast. The GUI is fast too. Of course, a banana slug will look fast when you are looking at Mozilla's GUI, but Opera is pretty snappy in its own right.
The cache handling is probably one of the most noticeable places where Opera is fast. No browser I have seen can whip out a page from cache like Opera. Since my browsing habits involve hitting the "back" button often, the snappiness is noticeable. Moreover, caching is highly configurable. No matter how slow your Internet connection, cache performance makes a difference.
Opera also has some UI conveniences that makes its featues very accessible. The quick preferences menu lets you toggle popups, plugins, GIF animation and proxies by hitting F12 and a click. Toggling image loading is a mouseclick away. My favorite feature is the button that toggles author/user mode styles: on pages with lousy fonts/colors, you get instant readability with a click. All these, too, save time and makes things fast.
So: get some sleep and write again when your fingers are resynced with reality. I want my KDE to work. "Not reproducible here" does not sound like a good excuse at this point.
Junkbuster does not support HTTP/1.1, so a lot of browsers have problems with it. There is no ad-blocking proxy "supported" by RH as far as I know. The apparent successor to Junkbuster is Privoxy: it's not yet officially supported but it seems to usable now.
I have been underwhelmed by Red Hat's packaging of KDE in the past. For example, in a boxed release (either 7.1 or 7.2), kdehelp's "back" and "forward" buttons didn't work. When KDE 2.2.2 RPMs were released, they helpfully included (and required) a version of Qt that froze the desktop: I had to disable klipper. The current KDE3 RPMs for RH 7.2 from Red Hat have their own glitches: ksplash goes kblooie at startup, and konqueror seems to have this big memory leak that bloats its footprint over time. I wonder if anyone at Red Hat even tries to use KDE.
How is KDE3 running on RH 7.3? Does Konq still have that memory leak?
Where are you located? A $40K salary would be pretty comfortable in Iowa, and $63K is going to be tight in Silicon Valley. If you are not in the US, consider also the strength of the US dollar. Considering the exchange rate, cost of living and housing, things may not look so bad.
Right now, it's hard to evaluate office suites for the office environment. The problem, I think, is that techie reviewers usually are not familiar with the problems that they are used to solve. I don't care how well SOT imports memos: there are bigger things.
Excel is an amazing program. Think of it as a visual development platform complete with an IDE with context sensitive help, huge function library, built-in goal-seeking/optimization engine, cross-tabbing, statistics engine, monte carlo simulations, graphing, GUI (you can embed buttons/menus), DB functionality etc. Oh, and WYSIWYG reporting/printing comes free. People develop sophisticated business applications with Excel. Text books exist for this purpose. Real programmers may like to say "use a real programming language!", but the fact is that nonprogrammers can very quickly crank out powerful, maintainable apps relatively free of bugs. And many do: it's the right tool for many jobs.
So what does this have to do with the success of a new office suite? The question is the ease of migration. It's one thing to preserve the formatting of a Word memo. It's another to be able to import sophisticated Excel applications with confidence. Otherwise, the penetration of a rival office suite into the corporate environment will be severely hampered.
Those numbers are rather interesting. KDE has always shared a lot of memory, but previously we could have some idea of what each individual app used by subtracting the SHARE column from the SIZE column. Here, however, KDE apps' SIZE column is at least 50MB-ish, far exceeding the SHARE column. Something funny seems to have happened that affects KDE's memory accounting. Perhaps video memory is being mapped into every single KDE app.
One can compare memory footprint by looking at the free memory available immediately after loading each desktop. This would get around the difficult shared memory accounting.
Too many reviews focus on installation. This review contains less info than the KDE press release. How about a little hands-on insight? How does KDE 3 compare to its predecessor in terms of startup time (with/without prelink/objprelink)? Runtime performance? Memory footprint? Can we see some numbers? It's a pity that reviews geared towards techies are often lacking in quantitative information.
The ad targets Linux too. They hit upon the system's "complexity" and the need to hire "expensive experts". Think about it: Windows, more than any other server OS, can give a perception of user-friendliness. Look at the sysadmin tools on your typical Red Hat distro: we're still working with stone knives and bear skins. I am saying this as a long-time Red Hat user.
This may not improve much. Companies like Red Hat, MySQL AB and Sendmail Inc sell support for essentially free products. There is a certain incentive there to maintain some complexity so they can continue to sell support. Counter-arguments need to be marshalled on the ease of use issue, not to mention real solutions.
How would an unmodified payroll program that has worked for decades "break", especially if there are no Fortran programmers to break it?
I wouldn't call a half minute startup time "acceptable". While I have 128MB of RAM too, I resent having to surrender so much of it to a single program. With other big apps (KDE, XEmacs, Java) competing, I can ill afford another bulky app. I would rather use Konqueror or Opera. I see some indication of progress on the footprint front. Still, there is no indication that it will relinquish its title of "bulkiest and slowest". So regardless of the machine I use, it will continue to compare poorly to its competition on that score.
There are possible replies that have nothing to do with my question, but will probably come up anyway:
Yes, but the command line iSiloXC utility is ridiculously complex. You have to write an XML file (no DTD provided) to convert anything! Is there a command line utility less user-friendly than this? I prefer to use wget to save the HTML onto the hard disk. After that I can use the older convertor for iSilo 2 (you can still download it): you only need to specify the root HTML file and it will do the rest. You could use wget in a cron job, and if you decide to switch to Plucker you can simply switch the convertor that you use on the downloaded files.
Red Hat 7.2 has inconsistent policies for its use of Freetype. The freetype library itself has bytecode interpretation disabled so installing your version will greatly enhance its quality. But the X server/xfs was built with bytecode interpretation enabled. This means you can also greatly enhance font rendering by not enabling antialiasing. If you use the core X server font rendering -- which is the default -- the font (if well hinted) will look good.