btamail.net.cn is indeed a major repeat spammer - this doesn't have anything to do with "all Chinese being clueless", though.
If you go the "Since one machine in China is a major spammer, all Chinese are clueless" route, don't forget to equate the US with AOL, spammers.net and similar resources.
A problem with ISPs in China is that most Chinese people don't speak English (which, again, doesn't mean they're stupid - how many English speaking people speak Chinese?), so dropping the ISP a note saying "your user foo is sending spam" will be as understandable to some of them as spam in Chinese is to you.
Judge Motz's office's fax number is (410) 962-7574 - let them know this will only help M$, maybe a lot of messages can convince them to do the right thing(tm).
We've all seen the interview where bin Laden called for the murder of all Americans reguardless of whether they were in the armed forces.
Along with a translation provided by CNN.
Can we really be sure the translation is accurate?
Judging from the overall media coverage of this war (and other wars), I wouldn't be too surprised if the translation was edited to make him sound even more like a villain than he actually is, to gather support for any actions against Afghanistan, both legitimate (going after real terrorists) and illegitimate (throwing splinter bombs, throwing food at mine fields and any other action taken against civilians).
(Not saying it happened that way, though - maybe he actually did say these things, nobody who can't listen to and understand what he originally said can tell for sure.)
Re:Redhat Linux 7.2 is "stable"?????
on
KDE 2.2.2
·
· Score: 2
Are you saying redhat-update will be able to update to 2.2.2
Yes, almost certainly.
no need for rawhide
Installing the packages currently in rawhide is a bad idea(tm) because they're linked against the newer libpng from rawhide.
If so, how long does the QA take?
This can take quite a while, because they're VERY busy with other things (ports to other architectures etc).
Simply use the packages from ftp.kde.org, they're the same thing.
I've also pit libxml2 and libxslt (correct versions)
on ftp.kde.org along with the kde core packages.
Not every mirror has picked up the change, though.
Oops, master.kde.org and ftp.kde.org are no longer the same.;) Didn't notice.
master.kde.org has the correct packages, but isn't accessible to the public, so you'll have to wait until mirrors pick them up (ftp.kde.org has already started doing so).
Re:Redhat Linux 7.2 is "stable"?????
on
KDE 2.2.2
·
· Score: 4, Informative
The reason you're perceiving 7.2 as less stable is that we're releasing more errata packages these days - which does not necessarily mean the initial packages were all that bad.
KDE 2.2-* (as shipped with 7.2) wasn't bad, and nevertheless we'll release the 2.2.2 packages in errata as soon as QA approved them.
The correct libxslt and libxml2 packages are part of the release on ftp.kde.org.
Re:Are 5% speedup noticable ?
on
KDE 2.2.2
·
· Score: 4, Informative
(using RH 7.2 packages - i don't know if they were objprelink-build - Bero, if you read me, how did u build those packages ?)
They aren't built with objprelink because I consider objprelink a crude hack.
prelink is a much nicer solution (it does prelinking for the whole system, not just the KDE libraries), and you can't use both at the same time.
No unusual tweaks applied to the packages... But they were built with a newer compiler (gcc 2.96-100), maybe Jakub added some optimizations on the compiler side, as well.
Re:SuSE RPM's
on
KDE 2.2.2
·
· Score: 3, Informative
If this is true, it means they either broke the kde-packager agreement or packaged a CVS version and called it 2.2.2. They weren't supposed to release 2.2.2 binary packages before the official release, neither was anyone else.
Re:Objprelink?
on
KDE 2.2.2
·
· Score: 5, Informative
prelink works better (if your ld.so and binutils support it), and fixes the whole problem rather than just adding a workaround for the specific case of KDE.
Because the moment you sell it, Qt isn't under the GPL anymore, its under the commercial use license. Qt/Free is GPL'ed only for non-profit products.
This is not true.
Qt/Free is GPLed, period. You may not link proprietary software to GPLed libraries, so if you want to make proprietary software, you need to buy different licensing.
If your software is GPLed and for-profit, there's no problem.
Can we use the Free Edition while developing our non-free application [...] The Free Edition is intended for free software.
This refers to free as in software/speech, not price. Ask RMS for the definition of free.;)
Can I charge for my application?
If you have the Professional Edition: Yes, of course. If you use the Free Edition your software must be freely redistributable and you must include the source.
freely redistributable != available from you at $0.
It's perfectly legal to GPL an application and sell it at $500,000 per unit.
Anyone who buys it can freely redistribute it, of course - but it doesn't have to be $0...
Re:But does it have to start that slow?
on
KDE Wins 3 awards
·
· Score: 4, Insightful
This is related to the fact that the dynamic linker is slow when it comes down to resolving loads of C++ symnbols.
It's a deficiency recent versions binutils fix - try the (WARNING: not yet 100% stable) stuff from rawhide.
It'll probably be in 8.0 - the initial release of
2.96 was quite buggy (at least as much so as 3.0.1),
and our compiler people managed to stabilize it in
less than a minor release cycle.
They'll do the same thing to 3.0.x.
That's why I said "most" config tools.
I know there are some exceptions (mostly due to schedules that had to be kept - we can't always get all wanted features into the first version...).
The non bandaid solution is to standardize on a particular format for config files
This is true - but I don't think you can get every project to follow the same standard.
We actually talked about something like this internally (basically, "provide one standard library for every config stuff, then fork every app to make use of it and ask maintainers to apply the patch"), but dismissed the idea quite quickly because that would definitely be a nonstandard thing giving people legitimate reasons to complain about ("Oh, you're using the Red Hat version of my application? Then I can't help you, I don't know anything about it, and I don't like their config layout"), and more "Red Hat is just like Microsoft, now they're forcing everyone to use their crap rather than compiling from source!" type FUD.
In an ideal world, we'd all be using the same format for config files (how do you represent/etc/sendmail.cf in key=value or xml, by the way?) - but it's almost certainly not going to happen, at least not anytime soon.
Even OSes that try to enforce one config scheme on everything (e.g. M$ registry) end up with applications that create their own config files using something totally different.
A HA! There is no/etc/rc.d/init.d/rc.local! Its/etc/rc.d/rc.local!
See! Not even the RH developers can keep track of RH's changes!:)
It's not a change, it's always been there and surely belongs there.
KDE? People are still using that???
Posting this reply using Konqueror 2.2.1...
When did the C++ language come out of beta
Huh? I thought C was an early beta of C++?;))
what's the best way to learn the specifics of a particular distro
Good question... I've never seen a document describing them, probably mostly because most people aren't familiar with much more than one distribution.
Take the issue.net prob for example
This is common to virtually all distributions, by the way.
It's because most distributions use mingetty for the normal console login these days (less bloat), and a different getty for network and serial logins (mingetty doesn't support them) - and they're not 100% compatible in the options they take (and issue.net/issue macros).
I'm all but anti-open source, but here you go...
on
Opposing Open Source?
·
· Score: 3, Interesting
I've read a lot of FUD from Microsoft and similar companies - it all comes down to a number of arguments that can be easily refuted (classical example: "Open Source is a security problem - since everyone can see the source, everyone can see the bugs"), plus exactly 2 somewhat valid things:
NDAs. Since we aren't in a perfect world, some information is released under NDAs only, and those NDAs include not publishing the source code of applications that use the information.
There's no fix for this one, other than simply avoiding anything that requires a restrictive NDA.
Making money is somewhat harder. For an Open Source OS or server, you can always sell support and services - but how do you make a lot of money from Open Source games?
I can think of 3 ways to circumvent this problem, but neither of them is very nice (still better than proprietary code, if you ask me):
Delayed Licensing: Release it as proprietary code first, Open Source it a year later.
Make the code Open Source, but keeping the data files (graphics and all) under a very restrictive license.
A combination of the previous 2 things: Release the code from the beginning, but don't allow copying the data files for a year or so (I'd probably pick this option if I had to)
Slashdot Mirror
btamail.net.cn is indeed a major repeat spammer - this doesn't have anything to do with "all Chinese being clueless", though.
If you go the "Since one machine in China is a major spammer, all Chinese are clueless" route, don't forget to equate the US with AOL, spammers.net and similar resources.
A problem with ISPs in China is that most Chinese people don't speak English (which, again, doesn't mean they're stupid - how many English speaking people speak Chinese?), so dropping the ISP a note saying "your user foo is sending spam" will be as understandable to some of them as spam in Chinese is to you.
Judge Motz's office's fax number is (410) 962-7574 - let them know this will only help M$, maybe a lot of messages can convince them to do the right thing(tm).
We've all seen the interview where bin Laden called for the murder of all Americans reguardless of whether they were in the armed forces.
Along with a translation provided by CNN.
Can we really be sure the translation is accurate?
Judging from the overall media coverage of this war (and other wars), I wouldn't be too surprised if the translation was edited to make him sound even more like a villain than he actually is, to gather support for any actions against Afghanistan, both legitimate (going after real terrorists) and illegitimate (throwing splinter bombs, throwing food at mine fields and any other action taken against civilians).
(Not saying it happened that way, though - maybe he actually did say these things, nobody who can't listen to and understand what he originally said can tell for sure.)
Are you saying redhat-update will be able to update to 2.2.2
Yes, almost certainly.
no need for rawhide
Installing the packages currently in rawhide is a bad idea(tm) because they're linked against the newer libpng from rawhide.
If so, how long does the QA take?
This can take quite a while, because they're VERY busy with other things (ports to other architectures etc).
Simply use the packages from ftp.kde.org, they're the same thing.
Will KDE appear on Redhat Network one day?
;)
Yes, after QA has checked the new version doesn't break anything (which can take some time).
I have never found anything interesting there
You call fixes for root exploits not interesting?
What was your IP again?
some minor bug fixes, no real upgrades
That's what it's there for.
It fixes security bugs and other problems without changing the core system.
I've also pit libxml2 and libxslt (correct versions)
on ftp.kde.org along with the kde core packages.
Not every mirror has picked up the change, though.
Oops, master.kde.org and ftp.kde.org are no longer the same. ;) Didn't notice.
master.kde.org has the correct packages, but isn't accessible to the public, so you'll have to wait until mirrors pick them up (ftp.kde.org has already started doing so).
The reason you're perceiving 7.2 as less stable is that we're releasing more errata packages these days - which does not necessarily mean the initial packages were all that bad.
KDE 2.2-* (as shipped with 7.2) wasn't bad, and nevertheless we'll release the 2.2.2 packages in errata as soon as QA approved them.
I added them 3 days ago, some time yesterday morning. Guess mirrors need some time to sync.
Spontaneously, I don't see any extra requirements you'd need to update on 7.1, aside from those provided on ftp.kde.org (libxml2, libxslt, qt).
;)
But 7.1 was LOOONG ago, so don't expect me to remember everything about it.
The correct libxslt and libxml2 packages are part of the release on ftp.kde.org.
(using RH 7.2 packages - i don't know if they were objprelink-build - Bero, if you read me, how did u build those packages ?)
They aren't built with objprelink because I consider objprelink a crude hack.
prelink is a much nicer solution (it does prelinking for the whole system, not just the KDE libraries), and you can't use both at the same time.
No unusual tweaks applied to the packages... But they were built with a newer compiler (gcc 2.96-100), maybe Jakub added some optimizations on the compiler side, as well.
If this is true, it means they either broke the kde-packager agreement or packaged a CVS version and called it 2.2.2. They weren't supposed to release 2.2.2 binary packages before the official release, neither was anyone else.
prelink works better (if your ld.so and binutils support it), and fixes the whole problem rather than just adding a workaround for the specific case of KDE.
Red Hat has just released an
alternative proposal.
Basically, it comes down to "Microsoft can put all the money in hardware, we'll provide the software for free".
At least at Red Hat, people do meet in the weekends - on the net, to keep hacking on Linux. ;)
If popups don't count, I'd just go ahead and create
my own "Enter the URL you want to view here" page, causing the entered URL
to show up in a popup.
Back to free access...
Because the moment you sell it, Qt isn't under the GPL anymore, its under the commercial use license. Qt/Free is GPL'ed only for non-profit products.
;)
This is not true.
Qt/Free is GPLed, period. You may not link proprietary software to GPLed libraries, so if you want to make proprietary software, you need to buy different licensing.
If your software is GPLed and for-profit, there's no problem.
Can we use the Free Edition while developing our non-free application [...] The Free Edition is intended for free software.
This refers to free as in software/speech, not price. Ask RMS for the definition of free.
Can I charge for my application?
If you have the Professional Edition: Yes, of course. If you use the Free Edition your software must be freely redistributable and you must include the source.
freely redistributable != available from you at $0.
It's perfectly legal to GPL an application and sell it at $500,000 per unit.
Anyone who buys it can freely redistribute it, of course - but it doesn't have to be $0...
This is related to the fact that the dynamic linker is slow when it comes down to resolving loads of C++ symnbols.
It's a deficiency recent versions binutils fix - try the (WARNING: not yet 100% stable) stuff from rawhide.
Sure - try DOSEMU with FreeDOS ripcord.
If it doesn't work, try dosemu with DR-DOS - not open source, but at least $0.
Just tried accessing msn.com with Konqueror 2.9 - it still states I need to "upgrade" to M$IE.
I wonder what the DOJ will say on this.
It'll probably be in 8.0 - the initial release of
2.96 was quite buggy (at least as much so as 3.0.1),
and our compiler people managed to stabilize it in
less than a minor release cycle.
They'll do the same thing to 3.0.x.
That's why I said "most" config tools.
/etc/sendmail.cf in key=value or xml, by the way?) - but it's almost certainly not going to happen, at least not anytime soon.
I know there are some exceptions (mostly due to schedules that had to be kept - we can't always get all wanted features into the first version...).
The non bandaid solution is to standardize on a particular format for config files
This is true - but I don't think you can get every project to follow the same standard.
We actually talked about something like this internally (basically, "provide one standard library for every config stuff, then fork every app to make use of it and ask maintainers to apply the patch"), but dismissed the idea quite quickly because that would definitely be a nonstandard thing giving people legitimate reasons to complain about ("Oh, you're using the Red Hat version of my application? Then I can't help you, I don't know anything about it, and I don't like their config layout"), and more "Red Hat is just like Microsoft, now they're forcing everyone to use their crap rather than compiling from source!" type FUD.
In an ideal world, we'd all be using the same format for config files (how do you represent
Even OSes that try to enforce one config scheme on everything (e.g. M$ registry) end up with applications that create their own config files using something totally different.
A HA! There is no /etc/rc.d/init.d/rc.local! Its /etc/rc.d/rc.local!
:)
;))
See! Not even the RH developers can keep track of RH's changes!
It's not a change, it's always been there and surely belongs there.
KDE? People are still using that???
Posting this reply using Konqueror 2.2.1...
When did the C++ language come out of beta
Huh? I thought C was an early beta of C++?
what's the best way to learn the specifics of a particular distro
Good question... I've never seen a document describing them, probably mostly because most people aren't familiar with much more than one distribution.
Take the issue.net prob for example
This is common to virtually all distributions, by the way.
It's because most distributions use mingetty for the normal console login these days (less bloat), and a different getty for network and serial logins (mingetty doesn't support them) - and they're not 100% compatible in the options they take (and issue.net/issue macros).
There's no fix for this one, other than simply avoiding anything that requires a restrictive NDA.
I can think of 3 ways to circumvent this problem, but neither of them is very nice (still better than proprietary code, if you ask me):
(I'd probably pick this option if I had to)