In related news: I've just submitted IBM, the makers of the (falling-over-like-)Domino email server, to rfc-ignorant.org because they don't seem to accept email (hence, no email to abuse@ and postmaster@):
$ host -t mx ibm.com
ibm.com mail is handled by 0 ns.watson.ibm.com.
$ host -t any ns.watson.ibm.com
ns.watson.ibm.com has address 198.81.209.2
$ telnet 198.81.209.2 smtp
Trying 198.81.209.2...
telnet: connect to address 198.81.209.2: Connection refused
My -rmap VM is a patch against marcelo's standard 2.4 kernel, because that is the thing people have. It just doesn't make sense to release patches against kernels nobody has.
Also note that -rmap replaces pretty much all parts from the -aa VM I don't agree with, while at the same time integrating some parts from the -aa VM that I do like.
It is hard to believe that all this is going on with what is meant to be a stable kernel version, ie 2.4.x
So far the VM has been replaced twice, and now the rmap patch is apparently going to be added despite the fact that "something is seriously messed up in the reverse-map implementation".
Ummmm, -rmap is still under development. If there are any plans to put it into 2.4.x, people sure haven't told me about them.;)))
(and personally, I'd prefer to keep -rmap separate for quite a while more... development is much more efficient in a fork)
I am a little leary about using the rmap in prouction as of yet, it seems to be killing things each nigh, (no shit) that dont drop with 2.4.17 or 2.4.9
Interesting. I've not managed to run into bugs like that on my computers here, so you must be running a very different workload to trigger such a bug.
Would you have the time to help me debug this problem and is it still happening with the latest rmap VM ?
What a nice article and it seems to come at a time just then everyone is talking about "Fork this and Fork that" that in fact this is exactly what is needed in this healthy debate.
Indeed, forks are (IMHO) the best way of doing development. Doing your development in the main kernel will just lead to contradictory code being integrated and the code never working quite right because it's missing fixes (guess why RH's 2.4.9 runs faster... it does have the fixes).
One minor nitpick though... I never released an -rmap VM against 2.4.18-pre3, the latest is still against 2.4.17. I suspect that the crashes Moshe saw are due to some change in 2.4.18-pre3 conflicting with the -rmap VM patch, especially since rmap-11c has survived the kernel torture lab at RH.;)
The problem is simple: maintainers of any parts of the kernel get flooded by email, maintainers of the whole kernel (Linus, Alan, Marcelo) get flooded even worse.
You really cannot expect these people to read all their email all the time, so patches and bugfixes get lost and may need to be resent various times before they get noticed.
Add to that the fact that many of the people writing these patches are also extremely busy and may not get around to resending the patch all the time (I know I don't).
The solution here would be to have the patch re-sent automatically as long as it still works ok with the latest kernel version... this can all be checked automatically.
Indeed, it is important to optimise the VM to work right on such large machines. I guess what I wanted to say is that the VM isn't just optimised for high-end machines, but also for machines on the low end.
To be honest though, optimising for machines of different sizes really is a no-brainer compared to having to make the VM work with really diverse workloads;)
Actually Conectiva started out as a RedHat clone, some 5 years ago and it's been using its own code base for a few years now.
Sure, it has imported some ideas from Debian (apt-get, alternatives) but current Conectiva is about as much a clone of Debian as it is a clone of RedHat;)
Oh, and of course distributions like Debian and RedHat are also taking back in some of the work done by Conectiva. I guess open source must be working.
I wonder what Rik has to say about the new "blessed" VM? If he thinks it's a better all-around VM, then the debate can stop pretty quickly I would think.
Well, since you wanted to know;)
First let me explain that most of the time in the beginning of 2.4 was spent making the VM stable, stopping it from chrashing on highmem machines, etc... Speed improvements were a secondary thing, to do later on. Secondly, Linus is a very busy man and didn't seem to have the time even to apply critical bugfixes at times, so his kernel has had a big disadvantage over Alan's kernel.
Around the time where the VM in Alan's kernel got stable, I was finally getting the time to work on speed improvements and Linus still lagged a few patches, suddenly Andrea surprised us all by posting the first version of his new VM online. An even bigger surprise was that Linus integrated this into the kernel within 24 hours, without even asking Andrea!
As to why Andrea's VM is faster for desktop use... it was optimised for speed on low to medium loads in exactly the same way the 2.2 kernel was. Note that this also means the server falls over quicker under high load and it is basically impossible to tune the system to run decently under all loads... just like 2.2.
My VM was slower for desktop loads, but since the thing stabilised I put in some time to make things faster and I seem to have mostly caught up with Andrea on the speed front now. The benchmark results posted on the linux-kernel mailing list seem to indicate that Andrea's VM is faster for some things, while my VM is faster for some other things.
Personally, I think it is easier to make a solid VM fast than it would be to make a fast VM solid. This opinion was formed because of the living hell of the Linux 2.2 VM, which was undocumented and horribly subtle.
In the future, I know I'll always be optimising for (1) maintainability, (2) correctness/stability and (3) performance, in that order...
Indeed, the US outlawing something is one thing. That's their business, if it turns out to hurt them too much they can always revert the law. It's a democratic country, isn't it ?
OTOH, the US outlawing something shouldn't mean that all these good things are suddenly no longer available to the rest of the world. We need a place to publish the things which are outlawed in the US, without getting prosecuted for publishing these things to the US.
Such a site has been started (well, not quite, but we're busy getting it up and running) and we hope there will soon be a place to publish crypto research, security information and other useful tools which are not allowed in the US. The only small gotcha is that in order to publish it legally, some kind of access controll will have to be put in place so US citizens cannot get at the archive. Unfortunate, but so be it.
Last year, Conectiva ported apt-get to RPM and Conectiva Linux 6.0 is using apt-get with RPM.
Mandrake's beta distribution (Cooker) is also using apt-get and various people have set up their own private apt-get archives for Red Hat.
This means that "apt-get vs rpm" is plain stupid, since they work together just fine. It should be ".deb vs.rpm", but those two are so similar that it doesn't make much sense to fight over;)
What good is it to have different flavours of ice cream if they're all cold?:)
But seriously... personally I think it is good to have different flavours of Linux that cater to the many different tastes people have.
On the other hand, I also think it would be good if all the distributions would be compatible enough that you can install the same 3rd party software packages on each system...
I hope that Conectiva 6.0 with its apt-get for RPM will bring us a step in the right direction. The main reason I hope lots of people will be using Conectiva 6.0 is that a whole bunch of my friends have spent a large amount of time working on it;)
But in the long run the only thing that's really important to me is that every computer user will have the opportunity to run that system that (s)he likes most while still being compatible with the rest of the world. It's about usability and freedom of choice...
this caused a 3-month delay in Conectiva 6.0 ;)
on
An RPM Port Of APT
·
· Score: 1
The fact that apt-get depends on proper dependancy information caused the Conectiva Linux developers (who started out on a RedHat source base 3 years ago) quite a bit of pain at first;)
It took the people here a few months to clean up all the dependancies of every package, but now we've finally got a nice RPM-based distro which has all the dependancies right...
For me personally (I'm just doing kernel hacking and no distro stuff) this has caused no end to my joy... since the distro folks got all the dependancies right I'm using apt-get and don't have to bother with system administration of my box any more;)
Various people are working on this. It looks like we'll have a whole list of apt-get frontends soon. Not just dselect and aptitude, but also the front-end from gnorpm should be available soon...
This should be good news for the people who are afraid that apt-get for RPM is a problem for Debian... the fact that apt-get has been ported to another package format simply means more apt-get frontends will be available soon, one for
everybody's tastes. And the fact that Debian and the RPM-based distro's are closer together now means it'll be easier for everyone to choose the distro of his/her taste without having to choose for (in)compatibility with other stuff at the same time.
"Even though" I work for Conectiva, I really hope that this will be nothing but a boost for Linux as a whole and a good thing for Debian as well.
People often get fooled by the idea that Linux companies only want to advance their own distribution, but the reality is that different distro's simply appeal to different tastes (like different tastes of ice cream) and that the Linux companies make most of their their money by services, not by selling boxes of CD's...
In fact, a lot of the apt-rpm things were developed in good communication with the Debian people and most developers here aren't all that happy with the fact that marketing let one "Conectiva invents apt-get" press release out... they've since been cluebatted and all the other press releases list Debian too like they should;)
Disclaimer: I work for Conectiva and maintain a conectiva 6.0 ftp mirror... (but since I could get a job pretty much anywhere, I'm keeping my loyalty with the Linux _users_, not with any particular company!)
The way apt-get works, either the majority of the RPM-based distros will have to get it right or everybody will have to maintain their own repositories.
Personally I'm seeing quite a bit of activity in the LSB and the various RPM-based distros are so compatible with each other that it shouldn't be all that difficult to get things to work.
At least, while there were some overheated email going in both directions, there never were political arguments involved there's no reason to fear that Linux development will fork or halt as a result of infighting.
Truth is that in the heat of the email thread both sides wrote up some things that just weren't there. And after yesterday's invention of the "VFS flamefest" here on Slashdot, it seems logical that some of the people who weren't on linux-kernel but were on Slashdot yesterday get a bit worried.
Well, I guess this is how rumours come into existance:) Lets forget this whole thing and get back to coding like we always do...
Ok, we all know that this is definitely a Bad Thing. Now, what do we do about it? If all of the intelligent slashdotters got together and helped these guys argue their case in court, I'm sure that the MPAA wouldn't win the lawsuit.Ok, we all know that this is definitely a Bad Thing. Now, what do we do about it? If all of the intelligent slashdotters got together and helped these guys argue their case in court, I'm sure that the MPAA wouldn't win the lawsuit.
I believe the EFF is helping the defendants and that a defense fund will be (is?) set up. Things should not be that hard from the legal side.
On the front of public opinion, however, there is a lot to be done. If everyone who reads this article would phone or mail their local newspaper and tell them what's up (or just point them to the right sources), then we'll be able to make an impact.
Just point your local journalists to this site and explain them (politely and patiently) that the movie industry is (illegally) trying to take away consumer's rights. Your rights, their rights!
And remember, nobody will be interested in the story until you can show them that it is relevant to them too. In this case it is, so please use that facet of the story to get publicity...
The legal basis for this latest attack is as absent as in the other lawsuit. It is clear that the movie industry is trying to win this one by intimidation and public opinion.
Help the DVD defandants, help defend your consumer rights! Spread awareness of the OpenDVD.org campaign!
> I was one who... showed up. Wonder if it helped.
The battle isn't over. The Open Source community will have to continue showing up. On the Internet, in the traditional media and in the strangest places imaginable.
Our story must be heard and made clear to the press, the general public and everyone else.
At http://www.opendvd.org/ the Open Source (OpenDVD) community will continue to "show up" for the next weeks, probably months. Please visit the site and point others at the site. Contact me if you're interested in helping out with the site.
IDG has an email form on their web site where you only have to know the name of the person you're writing. Go to that page and send them a letter like mine...
And remember, it's a company. This means that its only weak spot is its wallet. Hit them where it hurts the most -- tell all your friends to buy O'Reilly instead!
-------
Dear mrs. Drewelow,
I have seen the letter that you sent to the administrator of the mailing list who was unfortunate enough to have subscribers who sent an email with a "for dummies" subject to his list.
I must inform you that I am outraged by your uninformed decision to hold someone responsible for archiving an email message that came by on his list and threaten them because of "trademark dilution".
I hope that you will learn a bit about the situation and apologize to Mr. Dietz.
kind regards,
Rik van Riel
PS. If you choose to proceed with your cease and decist policy in the uninformed matter that you are doing now, I promise you that I will advice anyone against buying one of your books. This policy, when continued, will be a good source of income for Tim O'Reilly and other, properly behaving, publishers.
After all, who will buy a computer book from a publisher who has shown, in public, that it doesn't understand a bit about how the internet works?
A new home (Re:Who Exactly Is Homeless?)
on
R.I.P. Linuxbox
·
· Score: 1
Of course I agree that Chris should be payed by his paying customers. He really doesn't deserve to be left in the cold.
On the other hand, I don't think he should bear the cost of hosting Open Source projects either. There are some less costly methods of hosting those projects.
For example, I have a host at the University of Utrecht who is allowing me to use some of their bandwidth for free. I am willing to host some open source projects and have all the resources available. Whenever I need more bandwidth, hardware or whatever, there's always been a nice company that came up and offered help.
Just mail me (email on my home page) if you need to host an Open Source project on NL.linux.org...
Slashdot Mirror
$ host -t mx ibm.com
ibm.com mail is handled by 0 ns.watson.ibm.com.
$ host -t any ns.watson.ibm.com
ns.watson.ibm.com has address 198.81.209.2
$ telnet 198.81.209.2 smtp
Trying 198.81.209.2...
telnet: connect to address 198.81.209.2: Connection refused
My -rmap VM is a patch against marcelo's standard 2.4 kernel, because that is the thing people have. It just doesn't make sense to release patches against kernels nobody has.
Also note that -rmap replaces pretty much all parts from the -aa VM I don't agree with, while at the same time integrating some parts from the -aa VM that I do like.
(and personally, I'd prefer to keep -rmap separate for quite a while more ... development is much more efficient in a fork)
Interesting. I've not managed to run into bugs like that on my computers here, so you must be running a very different workload to trigger such a bug.
Would you have the time to help me debug this problem and is it still happening with the latest rmap VM ?
Thanks to Alan Cox, Red Hat (and most Linux distributions) do have the patches for my VM that Linus didn't have the time for.
One minor nitpick though ... I never released an -rmap VM against 2.4.18-pre3, the latest is still against 2.4.17. I suspect that the crashes Moshe saw are due to some change in 2.4.18-pre3 conflicting with the -rmap VM patch, especially since rmap-11c has survived the kernel torture lab at RH. ;)
You really cannot expect these people to read all their email all the time, so patches and bugfixes get lost and may need to be resent various times before they get noticed.
Add to that the fact that many of the people writing these patches are also extremely busy and may not get around to resending the patch all the time (I know I don't).
The solution here would be to have the patch re-sent automatically as long as it still works ok with the latest kernel version ... this can all be checked automatically.
To be honest though, optimising for machines of different sizes really is a no-brainer compared to having to make the VM work with really diverse workloads ;)
This is quite interesting since I haven't begun tuning -rmap for speed yet ;)
Sure, it has imported some ideas from Debian (apt-get, alternatives) but current Conectiva is about as much a clone of Debian as it is a clone of RedHat ;)
Oh, and of course distributions like Debian and RedHat are also taking back in some of the work done by Conectiva. I guess open source must be working.
Well, since you wanted to know ;)
First let me explain that most of the time in the beginning of 2.4 was spent making the VM stable, stopping it from chrashing on highmem machines, etc... Speed improvements were a secondary thing, to do later on. Secondly, Linus is a very busy man and didn't seem to have the time even to apply critical bugfixes at times, so his kernel has had a big disadvantage over Alan's kernel.
Around the time where the VM in Alan's kernel got stable, I was finally getting the time to work on speed improvements and Linus still lagged a few patches, suddenly Andrea surprised us all by posting the first version of his new VM online. An even bigger surprise was that Linus integrated this into the kernel within 24 hours, without even asking Andrea!
As to why Andrea's VM is faster for desktop use ... it was optimised for speed on low to medium loads in exactly the same way the 2.2 kernel was. Note that this also means the server falls over quicker under high load and it is basically impossible to tune the system to run decently under all loads ... just like 2.2.
My VM was slower for desktop loads, but since the thing stabilised I put in some time to make things faster and I seem to have mostly caught up with Andrea on the speed front now. The benchmark results posted on the linux-kernel mailing list seem to indicate that Andrea's VM is faster for some things, while my VM is faster for some other things.
Personally, I think it is easier to make a solid VM fast than it would be to make a fast VM solid. This opinion was formed because of the living hell of the Linux 2.2 VM, which was undocumented and horribly subtle.
In the future, I know I'll always be optimising for (1) maintainability, (2) correctness/stability and (3) performance, in that order...
OTOH, the US outlawing something shouldn't mean that all these good things are suddenly no longer available to the rest of the world. We need a place to publish the things which are outlawed in the US, without getting prosecuted for publishing these things to the US.
Such a site has been started (well, not quite, but we're busy getting it up and running) and we hope there will soon be a place to publish crypto research, security information and other useful tools which are not allowed in the US. The only small gotcha is that in order to publish it legally, some kind of access controll will have to be put in place so US citizens cannot get at the archive. Unfortunate, but so be it.
The site? http://thefreeworld.net/
Mandrake's beta distribution (Cooker) is also using apt-get and various people have set up their own private apt-get archives for Red Hat.
This means that "apt-get vs rpm" is plain stupid, since they work together just fine. It should be ".deb vs .rpm", but those two are so similar that it doesn't make much sense to fight over ;)
But seriously ... personally I think it is good to have different flavours of Linux that cater to the many different tastes people have.
On the other hand, I also think it would be good if all the distributions would be compatible enough that you can install the same 3rd party software packages on each system...
I hope that Conectiva 6.0 with its apt-get for RPM will bring us a step in the right direction. The main reason I hope lots of people will be using Conectiva 6.0 is that a whole bunch of my friends have spent a large amount of time working on it ;)
But in the long run the only thing that's really important to me is that every computer user will have the opportunity to run that system that (s)he likes most while still being compatible with the rest of the world. It's about usability and freedom of choice...
Disclaimer: I work for Conectiva and even run a Conectiva 6.0 ftp mirror...
It took the people here a few months to clean up all the dependancies of every package, but now we've finally got a nice RPM-based distro which has all the dependancies right ...
For me personally (I'm just doing kernel hacking and no distro stuff) this has caused no end to my joy ... since the distro folks got all the dependancies right I'm using apt-get and don't have to bother with system administration of my box any more ;)
Disclaimer: I work for Conectiva and even run a Conectiva 6.0 ftp mirror...
This should be good news for the people who are afraid that apt-get for RPM is a problem for Debian ... the fact that apt-get has been ported to another package format simply means more apt-get frontends will be available soon, one for
everybody's tastes. And the fact that Debian and the RPM-based distro's are closer together now means it'll be easier for everyone to choose the distro of his/her taste without having to choose for (in)compatibility with other stuff at the same time.
Disclaimer: I work for Conectiva and even run a Conectiva 6.0 ftp mirror...
People often get fooled by the idea that Linux companies only want to advance their own distribution, but the reality is that different distro's simply appeal to different tastes (like different tastes of ice cream) and that the Linux companies make most of their their money by services, not by selling boxes of CD's...
In fact, a lot of the apt-rpm things were developed in good communication with the Debian people and most developers here aren't all that happy with the fact that marketing let one "Conectiva invents apt-get" press release out ... they've since been cluebatted and all the other press releases list Debian too like they should ;)
Disclaimer: I work for Conectiva and maintain a conectiva 6.0 ftp mirror... (but since I could get a job pretty much anywhere, I'm keeping my loyalty with the Linux _users_, not with any particular company!)
Personally I'm seeing quite a bit of activity in the LSB and the various RPM-based distros are so compatible with each other that it shouldn't be all that difficult to get things to work.
Disclaimer: I work for Conectiva and even run an ftp mirror of Conectiva 6.0 ...
Truth is that in the heat of the email thread both sides wrote up some things that just weren't there. And after yesterday's invention of the "VFS flamefest" here on Slashdot, it seems logical that some of the people who weren't on linux-kernel but were on Slashdot yesterday get a bit worried.
Well, I guess this is how rumours come into existance :) Lets forget this whole thing and get back to coding like we always do...
I believe the EFF is helping the defendants and that a defense fund will be (is?) set up. Things should not be that hard from the legal side.
On the front of public opinion, however, there is a lot to be done. If everyone who reads this article would phone or mail their local newspaper and tell them what's up (or just point them to the right sources), then we'll be able to make an impact.
Just point your local journalists to this site and explain them (politely and patiently) that the movie industry is (illegally) trying to take away consumer's rights. Your rights, their rights!
And remember, nobody will be interested in the story until you can show them that it is relevant to them too. In this case it is, so please use that facet of the story to get publicity...
Help the DVD defandants, help defend your consumer rights! Spread awareness of the OpenDVD.org campaign!
http://www.opendvd.org/
The battle isn't over. The Open Source community will have to continue showing up. On the Internet, in the traditional media and in the strangest places imaginable.
Our story must be heard and made clear to the press, the general public and everyone else.
At http://www.opendvd.org/ the Open Source (OpenDVD) community will continue to "show up" for the next weeks, probably months. Please visit the site and point others at the site. Contact me if you're interested in helping out with the site.
Thanks,
Rik
Visit the FUD-counter site at:
http://fud-counter.nl.linux.org/
The project is still new and we could use a few volunteers to help us out...
And remember, it's a company. This means that its only weak spot is its wallet. Hit them where it hurts the most -- tell all your friends to buy O'Reilly instead!
-------
Dear mrs. Drewelow,
I have seen the letter that you sent to the administrator of the mailing list who was unfortunate enough to have subscribers who sent an email with a "for dummies" subject to his list.
I must inform you that I am outraged by your uninformed decision to hold someone responsible for archiving an email message that came by on his list and threaten them because of "trademark dilution".
I hope that you will learn a bit about the situation and apologize to Mr. Dietz.
kind regards,
Rik van Riel
PS. If you choose to proceed with your cease and decist policy in the uninformed matter that you are doing now, I promise you that I will advice anyone against buying one of your books. This policy, when continued, will be a good source of income for Tim O'Reilly and other, properly behaving, publishers.
After all, who will buy a computer book from a publisher who has shown, in public, that it doesn't understand a bit about how the internet works?
On the other hand, I don't think he should bear the cost of hosting Open Source projects either. There are some less costly methods of hosting those projects.
For example, I have a host at the University of Utrecht who is allowing me to use some of their bandwidth for free. I am willing to host some open source projects and have all the resources available. Whenever I need more bandwidth, hardware or whatever, there's always been a nice company that came up and offered help.
Just mail me (email on my home page) if you need to host an Open Source project on NL.linux.org...