Does Redhat not package the KDE environment in pieces? If not - why not?
We do. kdelibs+kdebase is enough to run Konqueror. We aren't splitting things up even more (like, maybe, splitting kcontrol off kdebase) mostly to keep a "ls *.rpm" tree you can bear to look at, and also to save translation cost for package descriptions.
Assuming they'd manage to come up with some way to really protect a DVD from being copied, you could still put it into a hardware DVD player, attach it to a good old traditional VCR and rip it from there... I don't think most people would even notice the quality loss.
I know they're stupid, but are they really stupid enough not to see the obvious?
Actually I commit every patch I make to KDE into CVS right away, unless it's something that simply doesn't make sense for everyone (like changing a default setting to match Red Hat Linux, or making stuff run through consolehelper which isn't avaliable on many other OSes (even other Linux distributions)).
I don't understand why a distro would bother shipping a kernel (or app for that matter) with a patch that was "ad hoc"
Easy: Because a kludgy workaround is preferrable over a bug, and we don't always have the time to fix things the right way.
I think you will find that most distros test their patched kernels thoroughly before releasing them to the world. This would include not only checking that the patch fixes the problem, but that it compiles on all supported architectures and does not jeopradise future modifications to the same bit of code or adjacent or related pieces of code.
This is true - but it doesn't include checking for stuff that's just a workaround for a bug with a relatively bad code quality.
Why they don't submit all the patches to the kernel maintainer I don't know?
Because the guy who wrote the article either didn't check the facts or lied. At least as far as Red Hat is concerned, patches do get submitted.
I am wondering if the distributors themselves don't have too much interest in offering patches upstream
This plain isn't true, and whoever wrote the article on gentoo.org just shows he doesn't have the slightest hint of a clue.
There are some good reasons not to blindly apply distributor patches into the main kernel (for example, we have quite a few workarounds for bugs, but the right way to fix them in the official kernel is to fix them, not to add workarounds), and there are some other things preventing other patches from getting in (e.g. Linus not having the time to handle them immediately).
Other stuff is controversial (such as Red Hat Rawhide kernels putting in the Rik VM rather than the AA VM currently in upstream).
The patches are sent upstream, but at least Red Hat doesn't believe in forcing upstream maintainers to accept all patches we send.
From: Microsoft Legal Department To: Valued Customer Subject: Windows Media Player Usage Report
Hello, we have noticed you have played back pirated episodes of Star Trek Enterprise downloaded from the net.
This is a violation of federal law.
We charge you $10,000 for this information; if we do not receive this amount of money, your registration information (as well as the information you used to register on any websites, as tracked by Internet Explorer) will be forwarded to the MPAA.
Simply report them to the police - identity theft and fraud are considered real crimes even by clueless law enforcement offices that usually don't do anything about spammers. (Yes, I've done it before).
Would you still say this if you received 300 spams a day, and had to pay for your net connection by the minute?
That's the situation many people around here are in.
If you look at it from this point, you'll probably agree that spam is theft.
I'm all for freedom, but requesting a "freedom to spam" is much like requesting the "freedom to commit fraud" or the "freedom to shoot people because you don't like their looks".
I agree, but it's currently not enforcable, at least not in.de.
I've reported a spammer to the police for theft of service, and got a letter back stating "this incident will not be pursued because the damage done was too low".
They sort of compared spamming to stealing $.01 from someone's pocket - it's not strictly legal, but nobody will do anything about it.:(
Like most non-technical people, they simply fail to understand spam is doing more than a little bit of damage.
That would kill off legitimate mailing lists, as well.
Take linux-kernel: It currently has roughly 10000 subscribers, with roughly 100 posts a day.
In your system, the people running it would have to pay $25,000 a day - they'd eventually get it back (assuming the subscribers remember to mark the messages as ok), but losing $25,000 even temporarily isn't something we all can afford (I certainly don't have $25,000, for example).
Another thing that occasionally helps is enforcing terms of use on your mail server.
e.g. if you connect to mail.bero.org port 25, you'll see 220 www.bero.org ESMTP Postfix - SENDING ANY COMMAND OTHER THAN "QUIT" CONSTITUTES ACCEPTANCE OF THE TERMS OF SERVICE OUTLINED AT http://www.bero.org/smtp-tos.html with smtp-tos.html being terms of service forbidding anything related to spam (including delivery).
I'm not 100% sure this is actually enforcable, but it's surely scary enough for some spammers to pay rather than risking it. (And a relatively safe way to at least get off their lists - they don't want to get an invoice again even if they're ignoring it).
Take a look at http://www.bero.org/NoSpam/isp.php - I've put up my apache configuration there. It does just that at least for some unintelligent spambots.
It's not THAT bad.
I regularily use German characters (if only to get the weird ä character in my last name right), and it works.
The problem is just using deadkeys, which isn't that widely used,
and AFAIK can easily be worked around using Compose
(e.g. Try pressing Alt Gr+Shift, then,c to get the
French c character, or Alt Gr+Shift, then "a to get ä).
On the contrary. KDE wouldn't be anywhere near where it is now if it were using anything else.
The default look of Qt may be boring in some people's tastes, but its programming interface beats all other toolkits out there by far.
Try it for yourself: Read the tutorials for, say, Qt, GTK, Motif and Win32. Then implement a simple application in each of them. You'll almost certainly notice you can do it much quicker with Qt.
And Qt 3.0 adds the possibility to load styles as plugins, so you can change the look much better than earlier.
The problem is that the xim patch is vital for people who need Japanese in KDE, so simply removing it is replacing one problem with another (arguably bigger) one, which isn't an option.
It's fixed for real in the current tree (qt3/kde3), the fix can't be backported easily, and I don't have more than 24 hours a day, so this simply has to wait until I have a lot of spare time (getting this right isn't exactly easy for someone like myself who doesn't have the slightest clue about Japanese input methods), or until someone else attaches a patch that fixes both.
One of the reasons, I believe, for RH to sport such an aggressive testing strategy is, that the next RH release will be build entirely with the GCC 3.x compiler
That, and the fact that I don't think it makes sense to leave a version with known bugs in there for too long. A week from now, most of the commonly noticed problems with beta2 will be fixed in CVS, while possibly introducing new ones. Those new ones are the ones we need to know about. (We aren't planning to ship anything official with beta2 - so bugs specific to that version don't matter much - getting bug reports about things that are already fixed is not very useful).
If KDE 3.0 is stable when RH 8.0* hits the market, you can be sure they will include it.
That's the plan (no comment on the version number though). We generally don't throw stuff into rawhide that we aren't planning to ship.
And yes! cups (www.cups.org) look like it is going in too.
It's going in, and Qt, KDE and wine are built with cups support.
This has nothing to do with likes or dislikes of a particular desktop (you'll notice there are no RPMs for the recent GNOME 2.0 alpha either).
There will be packages for beta2 later (probably some time tomorrow); the problem is sheer lack of time. I've tried, but still haven't found a way to work more than 24 hours a day.
And generally, building alpha/beta packages for previous releases is pretty low on my priority list (if you look at rawhide, you'll see KDE 3.0 post-beta2 has been in there for a couple of days).
Getting the next release (7.3, 8.0, Linux XP or whatever it will be called;) ) right is much more important (especially because next release + KDE 3.0 will be an officially supported configuration, 7.2 + KDE 3.0 isn't and probably won't be, releasing such a large errata that even breaks binary compatibility is not very likely to happen).
But FYI, I'm currently building the beta2 packages for 7.2 on x86, ia64 and alpha in a different tty.
kdelibs, kdebase, kdeadmin and kdemultimedia are done, kdegraphics requires some more work because of different gphoto versions, and I haven't started on the others.
These two environments tend to come with huge packages (e.g. gnome-applets, kdenetwork, kdemultimedia, kdegraphics, koffice,...).
Not necessarily.
Take a look at Raw Hide to see what the KDE packages are likely to look like in the next Red Hat Linux release.
I've decided to split up most of them.
Re:The greatest feature about KDE3...
on
KDE 3.0 Beta 2 is out
·
· Score: 3, Informative
It's a marketing-thing.
No, it's a "we may change the API and ABI in major releases" thing.
One of the main points of KDE 3.0 is the switch to Qt 3.0, which brings many advantages, but also breaks the existing ABI (and to a small extent, API).
A company's data can be totally screwed by a defective software product, and the software company be totally non-liable.
Which is a good thing, to an extent.
If there were any law to the contrary, just imagine what would happen to some Open Source projects.
Say you're a 16 year old student who hacked up some PHP board to run his own website, and you're thinking it may be useful to others.
Right now, you simply GPL it and put it up for download.
With a liability law, you'd run the risk of being sued over any defects - and since you typically wouldn't have any income at all, you'd think several times before releasing the code in any way, probably coming to the conclusion that you can't release it at all.
Much the same goes if you apply it for companies only. Take Red Hat:
We do a lot of testing on every release before it's called a release, but of course we don't have access to every piece of hardware in the world that Linux supports.
It's certainly possible that some version of an officially released kernel can cause massive filesystem corruption when the MyFOO ISA SCSI adapter is used.
We'd release an errata update for this type of stuff, but that's pretty much all we can do about it.
With a law holding software companies fully responsible for everything they ship, we'd probably have to disable all drivers that don't get loads of testing (basically all non-standard hardware), and also remove quite a few packages.
The difference between the software and the truck exploding is that you can use the software on very different hardware combinations (and no company in the world has the resources to test on all of them), causing potentially very different results.
Defining the limits of reasonable liability for software bugs would be a very hard task even for an engineer (my take would be something along the lines of "Vendors of proprietary software can be held responsible for data loss and damage caused by bugs in their software if the problem can be reproduced on the hardware recommended by the software vendor and the software is used in its intended way. Makers of Open Source Software and non-profit Software can never be held responsible."), and probably undoable for a (clueless) government.
And since tech-savvy users know how to alter their e-mail address and switch between temporary free accounts without too much disruption, the opt-in vs. opt-out argument really becomes a fight over new (and often ignorant) internet users.
Not really - even tech-savvy users can't change their business or role accounts. I receive e.g. about 100 pieces of spam a day on webmaster at bero dot evenintelligentspambotsshouldntseethis dot org.
It's similar for official contact addresses like security at spambotgotohell dot redhat dot com (which we can't change either...) - and address filters really aren't an option for those either.
I do. Linux all the time, Kernel 2.5.x occasionally (My box dual-boots between the Red Hat Raw Hide kernel and 2.5.whatever).
I actually can't understand people using anything but Linux (or FreeBSD or other similar OSes) for websurfing - Konqueror has quite a few features I haven't seen on any browsers for other OSes (such as getting completion in listboxes right).
Slashdot Mirror
Does Redhat not package the KDE environment in pieces? If not - why not?
We do. kdelibs+kdebase is enough to run Konqueror.
We aren't splitting things up even more (like, maybe, splitting kcontrol off kdebase) mostly to keep a "ls *.rpm" tree you can bear to look at, and also to save translation cost for package descriptions.
Assuming they'd manage to come up with some way to really protect a DVD from being copied, you could still put it into a hardware DVD player, attach it to a good old traditional VCR and rip it from there... I don't think most people would even notice the quality loss.
I know they're stupid, but are they really stupid enough not to see the obvious?
Actually I commit every patch I make to KDE into CVS right away, unless it's something that simply doesn't make sense for everyone (like changing a default setting to match Red Hat Linux, or making stuff run through consolehelper which isn't avaliable on many other OSes (even other Linux distributions)).
Actually the term was chosen correctly - "Red Hat does not submit its patches" is certainly nothing more than a piece of fiction. ;)
I don't understand why a distro would bother shipping a kernel (or app for that matter) with a patch that was "ad hoc"
Easy: Because a kludgy workaround is preferrable over a bug, and we don't always have the time to fix things the right way.
I think you will find that most distros test their patched kernels thoroughly before releasing them to the world. This would include not only checking that the patch fixes the problem, but that it compiles on all supported architectures and does not jeopradise future modifications to the same bit of code or adjacent or related pieces of code.
This is true - but it doesn't include checking for stuff that's just a workaround for a bug with a relatively bad code quality.
Why they don't submit all the patches to the kernel maintainer I don't know?
Because the guy who wrote the article either didn't check the facts or lied.
At least as far as Red Hat is concerned, patches do get submitted.
I am wondering if the distributors themselves don't have too much interest in offering patches upstream
This plain isn't true, and whoever wrote the article on gentoo.org just shows he doesn't have the slightest hint of a clue.
There are some good reasons not to blindly apply distributor patches into the main kernel (for example, we have quite a few workarounds for bugs, but the right way to fix them in the official kernel is to fix them, not to add workarounds), and there are some other things preventing other patches from getting in (e.g. Linus not having the time to handle them immediately).
Other stuff is controversial (such as Red Hat Rawhide kernels putting in the Rik VM rather than the AA VM currently in upstream).
The patches are sent upstream, but at least Red Hat doesn't believe in forcing upstream maintainers to accept all patches we send.
From: Microsoft Legal Department
To: Valued Customer
Subject: Windows Media Player Usage Report
Hello,
we have noticed you have played back pirated episodes
of Star Trek Enterprise downloaded from the net.
This is a violation of federal law.
We charge you $10,000 for this information; if we do not receive this amount of money, your registration information (as well as the information you used to register on any websites, as tracked by Internet Explorer) will be forwarded to the MPAA.
Simply report them to the police - identity theft and fraud are considered real crimes even by clueless law enforcement offices that usually don't do anything about spammers. (Yes, I've done it before).
Would you still say this if you received 300 spams a day, and had to pay for your net connection by the minute?
That's the situation many people around here are in.
If you look at it from this point, you'll probably agree that spam is theft.
I'm all for freedom, but requesting a "freedom to spam" is much like requesting the "freedom to commit fraud" or the "freedom to shoot people because you don't like their looks".
I agree, but it's currently not enforcable, at least not in .de.
:(
I've reported a spammer to the police for theft of service, and got a letter back stating "this incident will not be pursued because the damage done was too low".
They sort of compared spamming to stealing $.01 from someone's pocket - it's not strictly legal, but nobody will do anything about it.
Like most non-technical people, they simply fail to understand spam is doing more than a little bit of damage.
That would kill off legitimate mailing lists, as well.
Take linux-kernel: It currently has roughly 10000 subscribers, with roughly 100 posts a day.
In your system, the people running it would have to pay $25,000 a day - they'd eventually get it back (assuming the subscribers remember to mark the messages as ok), but losing $25,000 even temporarily isn't something we all can afford (I certainly don't have $25,000, for example).
I believe it is (by the way, this message is covered by the bero.org documents license).
Another thing that occasionally helps is enforcing terms of use on your mail server.
e.g. if you connect to mail.bero.org port 25, you'll see 220 www.bero.org ESMTP Postfix - SENDING ANY COMMAND OTHER THAN "QUIT" CONSTITUTES ACCEPTANCE OF THE TERMS OF SERVICE OUTLINED AT http://www.bero.org/smtp-tos.html with smtp-tos.html being terms of service forbidding anything related to spam (including delivery).
I'm not 100% sure this is actually enforcable, but it's surely scary enough for some spammers to pay rather than risking it. (And a relatively safe way to at least get off their lists - they don't want to get an invoice again even if they're ignoring it).
Take a look at http://www.bero.org/NoSpam/isp.php - I've put up my apache configuration there. It does just that at least for some unintelligent spambots.
It's not THAT bad. ,c to get the
I regularily use German characters (if only to get the weird ä character in my last name right), and it works.
The problem is just using deadkeys, which isn't that widely used,
and AFAIK can easily be worked around using Compose
(e.g. Try pressing Alt Gr+Shift, then
French c character, or Alt Gr+Shift, then "a to get ä).
qt, well, just sucks.
On the contrary. KDE wouldn't be anywhere near where it is now if it were using anything else.
The default look of Qt may be boring in some people's tastes, but its programming interface beats all other toolkits out there by far.
Try it for yourself: Read the tutorials for, say, Qt, GTK, Motif and Win32. Then implement a simple application in each of them. You'll almost certainly notice you can do it much quicker with Qt.
And Qt 3.0 adds the possibility to load styles as plugins, so you can change the look much better than earlier.
The problem is that the xim patch is vital for people who need Japanese in KDE, so simply removing it is replacing one problem with another (arguably bigger) one, which isn't an option.
It's fixed for real in the current tree (qt3/kde3), the fix can't be backported easily, and I don't have more than 24 hours a day, so this simply has to wait until I have a lot of spare time (getting this right isn't exactly easy for someone like myself who doesn't have the slightest clue about Japanese input methods), or until someone else attaches a patch that fixes both.
One of the reasons, I believe, for RH to sport such an aggressive testing strategy is, that the next RH release will be build entirely with the GCC 3.x compiler
That, and the fact that I don't think it makes sense to leave a version with known bugs in there for too long. A week from now, most of the commonly noticed problems with beta2 will be fixed in CVS, while possibly introducing new ones. Those new ones are the ones we need to know about. (We aren't planning to ship anything official with beta2 - so bugs specific to that version don't matter much - getting bug reports about things that are already fixed is not very useful).
If KDE 3.0 is stable when RH 8.0* hits the market, you can be sure they will include it.
That's the plan (no comment on the version number though). We generally don't throw stuff into rawhide that we aren't planning to ship.
And yes! cups (www.cups.org) look like it is going in too.
It's going in, and Qt, KDE and wine are built with cups support.
This has nothing to do with likes or dislikes of a particular desktop (you'll notice there are no RPMs for the recent GNOME 2.0 alpha either).
;) ) right is much more important (especially because next release + KDE 3.0 will be an officially supported configuration, 7.2 + KDE 3.0 isn't and probably won't be, releasing such a large errata that even breaks binary compatibility is not very likely to happen).
There will be packages for beta2 later (probably some time tomorrow); the problem is sheer lack of time. I've tried, but still haven't found a way to work more than 24 hours a day.
And generally, building alpha/beta packages for previous releases is pretty low on my priority list (if you look at rawhide, you'll see KDE 3.0 post-beta2 has been in there for a couple of days).
Getting the next release (7.3, 8.0, Linux XP or whatever it will be called
But FYI, I'm currently building the beta2 packages for 7.2 on x86, ia64 and alpha in a different tty.
kdelibs, kdebase, kdeadmin and kdemultimedia are done, kdegraphics requires some more work because of different gphoto versions, and I haven't started on the others.
These two environments tend to come with huge packages (e.g. gnome-applets, kdenetwork, kdemultimedia, kdegraphics, koffice, ...).
Not necessarily.
Take a look at Raw Hide to see what the KDE packages are likely to look like in the next Red Hat Linux release.
I've decided to split up most of them.
It's a marketing-thing.
No, it's a "we may change the API and ABI in major releases" thing.
One of the main points of KDE 3.0 is the switch to Qt 3.0, which brings many advantages, but also breaks the existing ABI (and to a small extent, API).
A company's data can be totally screwed by a defective software product, and the software company be totally non-liable.
Which is a good thing, to an extent.
If there were any law to the contrary, just imagine what would happen to some Open Source projects.
Say you're a 16 year old student who hacked up some PHP board to run his own website, and you're thinking it may be useful to others.
Right now, you simply GPL it and put it up for download.
With a liability law, you'd run the risk of being sued over any defects - and since you typically wouldn't have any income at all, you'd think several times before releasing the code in any way, probably coming to the conclusion that you can't release it at all.
Much the same goes if you apply it for companies only. Take Red Hat:
We do a lot of testing on every release before it's called a release, but of course we don't have access to every piece of hardware in the world that Linux supports.
It's certainly possible that some version of an officially released kernel can cause massive filesystem corruption when the MyFOO ISA SCSI adapter is used.
We'd release an errata update for this type of stuff, but that's pretty much all we can do about it.
With a law holding software companies fully responsible for everything they ship, we'd probably have to disable all drivers that don't get loads of testing (basically all non-standard hardware), and also remove quite a few packages.
The difference between the software and the truck exploding is that you can use the software on very different hardware combinations (and no company in the world has the resources to test on all of them), causing potentially very different results.
Defining the limits of reasonable liability for software bugs would be a very hard task even for an engineer (my take would be something along the lines of "Vendors of proprietary software can be held responsible for data loss and damage caused by bugs in their software if the problem can be reproduced on the hardware recommended by the software vendor and the software is used in its intended way. Makers of Open Source Software and non-profit Software can never be held responsible."), and probably undoable for a (clueless) government.
And since tech-savvy users know how to alter their e-mail address and switch between temporary free accounts without too much disruption, the opt-in vs. opt-out argument really becomes a fight over new (and often ignorant) internet users.
Not really - even tech-savvy users can't change their business or role accounts. I receive e.g. about 100 pieces of spam a day on webmaster at bero dot evenintelligentspambotsshouldntseethis dot org.
It's similar for official contact addresses like security at spambotgotohell dot redhat dot com (which we can't change either...) - and address filters really aren't an option for those either.
Guess the Vulcans can do it, as well...
;) ]):
// Try harder
// fatal error condition
A small http client written in SPOCK (Simple Programming-Oriented Computer Kode [yes, Vulcans use KDE
server=mindmeld(127.0.0.1:80);
if(server.type==Human)
server.send("rm -rf emotions");
if(server.state==illogical)
eyebrow->raise();
think("GET / HTTP/1.1\nHost: 127.0.0.1\n\n");
I do. Linux all the time, Kernel 2.5.x occasionally (My box dual-boots between the Red Hat Raw Hide kernel and 2.5.whatever).
I actually can't understand people using anything but Linux (or FreeBSD or other similar OSes) for websurfing - Konqueror has quite a few features I haven't seen on any browsers for other OSes (such as getting completion in listboxes right).
There's quite a bit of progress going on in gcc HEAD.
It has been a very stable compiler for about 6 weeks.
Oh, and gcc can do mmx since some time before 3.0
was released (e.g. 2.96 can do it).