CVS has a lot of short-comings. Most people that use CVS are ready to admit that, I think. Maybe CVS works for gcc, but gcc has multiple persons with write access to the tree. The kernel bitkeeper repository has only one single person with write-access; Linus himself. Linus himself decides what goes in and what doesn't, by pulling from other developer's trees, or by applying normal patches.
Then again, CVS would probably be able to handle the kernel too. But Linus doesn't like CVS one single bit, and since he doesn't, the choice wasn't CVS vs BK, but rather no source-management system vs BK.
Oh, and Bitkeeper is in no way mandatory for kernel-development. Alan Cox and Alexander Viro, for instance, don't use BK, and have no trouble getting their contributions into the kernel. In fact, Viro commented that it got easier, since Linus got relieved of some work.
The fact that gcc was a prerequisite for the Linux-kernel doesn't change the fact that CVS is far inferior to BK. Oh, and it's not like BK is totally non-free. As long as you accept to have your changelogs logged to a server, you get the program for free. Furthermore, the source-code is available, and you are allowed to modify it, as long as it still passes the regression-tests and does nothing to circumvent the open-logging. To finnish off, the program will become GPL if BitMover ceases to exist (can't remember the exact terms, sorry...)
I'm not saying that I'm thrilled with having one important part of the kernel-development process non-free, but I agree when Larry McVoy says that people should spend their time coding a replacement instead of complaining.
While I'm all for science, the exploration of
space et al., I'd still consider far more important to spend your time getting your representative in the senate to realise the insanity of such laws such as the DMCA and the SSSCA, and to hinder further steps down that lane. If you make your voice heard, better do it about someone worth being heard about.
Sorry for replying to myself, but it seems I forgot to answer your question... No, zOS is not a Unix. zOS is OS/390 for the z900 (which is the 64-bit version of the S/390.)
Depends on how new AS/400's we're talking about, I think. The older AS/400's will never run Linux; no reasonable MMU. As for converting the applications, well, I'm pretty confident a lot of Linux-hackers would be happy to earn a living on turning old Cobol-code into C/Perl/Python/Befunge/[insert favourite language here]. I don't think IBM will do it, though.
We're not talking about AS/400's (the iSeries), but about the S/390's (the zSeries.) The AS/400 ran an operating-system called OS/400 which was some kind of Database-like operating system. The S/390 has seen quite a lot of different OS:es, MVS, OS/390 (now known as zOS) and some others. There is a Unix-version to be run on the S/390, but afaik not for the AS/400. The AS/400 is pretty special hardware, after all.
Re:the kernel? my god man
on
Debian NetBSD
·
· Score: 1
Well, I don't know why he'd want that. Probably personal preference. Maybe he has hardware not supported by the FreeBSD-kernel, maybe he wants some feature of the Linux-kernel not available in the FreeBSD-kernel. But is that really interesting?! It can be done, the code is open-sourced, and a real hacker doesn't do things out of real use anyway, but out of the hackvalue.
Re:the kernel? my god man
on
Debian NetBSD
·
· Score: 1
Not really, something I consider a good sign. I've applied about 15 bugfixes since December 2000, and intend to add some 4-5 more before the release of 2.0.40.
Grow up. No, the code has not been stolen in any way (and for that matter, using it wouldn't be stealing anyway, because of the license... But that's beside the point.) Rik van Riel has been talking a lot with the FreeBSD VM-wizards, and looked at the FreeBSD code. He has then developed a VM of his own for the Linux-kernel.
Oh, and it's not like *BSD is totally free from influence from the Linux-kernel... Just face it, the point of open-source is to help eachother out.
Re:the kernel? my god man
on
Debian NetBSD
·
· Score: 4, Informative
Why on earth why would you want a linux kernel in BSD userland? Do you really want a horribly broken VM system and every yahoo who can type hello world submitting patches? Thats why I like BSD. Theres a core group in charge of what goes and what stays. Who has the final say so in the linux kernel?
Ever heard of Linus Torvalds? Oh, and for the v2.4 kernel it's Marcelo Tosatti, for v2.2 it's Alan Cox. For v2.0, it's yours truly. It's hardly like anyone can get their code into the kernel. Anyone is free to submit patches though. That doesn't mean it'll get in.
As for the VM, yes, there have been problems (mostly with corner-cases, though), but v2.0.xx has a stable VM, v2.2.xx has a stable VM now, v2.4.xx has a stable, if somewhat unoptimal VM now, and v2.6 will hopefully have Rik van Riel's VM, which shares a lot of similarities with the VM from FreeBSD, but with some Linux-specific adaptments.
Yes, but Apple is one single vendor, and can't possible match the joint offerings from all the different PC-laptop vendors. They have to focus on a few products, and do those extremely well. Imho they've been quite successful.
As for the $799 iMac, it's available at the Apple online store, and is for everyone, not just students. But I agree, it's a limited machine. But you asked for a sub $1000-machine, not for a powerful sub $1000-machine in your original post...
Apple is, and remains, a high-end, high-quality vendor for a niche market with a particular taste. In comparison, no matter how nice a car an RX-7 may be, not everybody will want to drive one. Apple will not take over the world, at least not with its current product range. Most sorely missing from their product range is a smaller, cheap desktop (a sub-$1000 cube, maybe) and an ultralight laptop.
You mean, like the $799 iMac (the non-LCD generation) and the TiBook (although 2.45 kg might not be ultra-light, it's still acceptably light, imho)?!
By the way, does the Superdrive mean they are re-evaluating their rejection of the floppy drive. Since Superdrives can read and write floppies, they have to support the format, even if there is not the actual hardware such as a floppy drive controller. Just wondering...
Huh? Where the f**k did you dream up that?! The Superdrive is a combined reader/recorder for DVD-R and standard CD-RW's, nothing else. And I'd really
want one too...
I'm not a US resident, and I don't intend to ever become, because I want to be able to develop open-source software without having to worry about being prosecuted for implementing devices for copyright circumvention because I don't implement copyprotection-schemes in each and every program...
But this is becoming waaay off-topic.
You do of course realise, that by supporting their claim for need of control, you also implicitly support things such as region-coding, CPRM, CSS, MacroVision and other things all implemented just to control the content.
The concerns of the RIAA and the MPAA is not really about the loss of money, because in most cases the people that download 10 GB's of MP3's wouldn't buy the records anyway, it's the loss of control they are worry about. They worry when they can't decide when an album is released in which country, and when and if a movie becomes available on DVD in a country. They worry when they can't decide for the end-user what fair use is, and they worry when they can't decide for the end-user what should be the preferred media and hardware.
And you really expect them to borrow me the record?! Because I won't stand for an hour in a record-store to listen to a record, and I will sure as hell not stand there for several hours to listen to the record several times (I almost never decide after the first listen, barring some masterpieces like Dark Side of the Moon by Pink Floyd.)
Look, I don't dislike Metallica's music, and I've bought every damn record they've released (barring some "best of"-collections and special editions); I've even got the original prints of Garage Days Revisited and Garage Days Re-revisited. However, I want to be able to listen to a record before I buy it. AND (most, not just Metallica's) records are at least twice as expensive as they ought to be.
As most bands/artists know that a good relation with the fans is the key to success, and that their record-companies takes most of the profit anyway,they don't really see MP3's as a threat, but rather as a momentum to spread their music and gain popularity, hence creating the opportunity for more sales. I'd guess the only larger band to actually support the RIAA would be Metallica...
No, you're getting it wrong. The code must not rely on the onboard DSP-chip that some modems hade, rather do all the signal-processing in software. If you don't process the signals, you can't have a modem, duh...
While Linux might not be perfect when it comes to SMP, it scales better than most other operating-systems for 1-8 processors. If you claim that Windows excels in SMP, you're definitely out on a limb.
Another serious setback for Linux is the lack of a journalling file system. This makes data storage unreliable, and backup and recovery a dicey proposition. SGI said they would port the IRIX file system to Linux, but I haven't heard anything about this yet. However, when you look at the major commercial NOS's, they all have journalling file systems, including Sun, SCO, Windows NT, Banyan Vines, HP/UX, AIX, and Novell. Windows has cleary beaten Linux to the punch here.
Huhhh? v2.4.14 contains ReiserFS, a fully journalled filesystem, and JFFS2, a journalled flash filesystem. v2.4.15-pre6 also contains ext3, another fully journalled filesystem. IBM's filesystem JFS is ported completely to Linux and awaiting merging, ditto for SGI's XFS, eventhough the latter has some things to sort out first. Check your facts first, please?!
The problem with CML1 isn't readability, but expressibility. The language suffers sane ways to define dependencies. CML2 provides this. Of course, it's likely to take some time for people to get used to CML2, but then again, people still make a lots of mistakes with CML1...
Well, first of all, I've as of yet never fucked up my tree (but I do start from scratch every 10-15 th kernel, just to get rid of any removed files, since patch doesn't remove empty files), and second, it only takes me a couple of minutes to download a complete kernel, untar it and apply any patches onto it... And soon (at the end of this year), when GigaSunet is finished, the download will be even faster. Yummie.
The only source I'm really careful not to mess up is the v2.0.40-sourcetree, mainly because noone else has it:-)
Re:Joystick still broken
on
Linux 2.4.13
·
· Score: 1
s/Linus d/Alan d/
But I think that was obvious to most people...
Re:Kernel 2.4.13 is out..yay....
on
Linux 2.4.13
·
· Score: 1
Oh my! The last two releases had bugs?! Gasp!
If you expect software to be totally bugfree, expect no software more advanced than hello world, and even then, greatly delayed by rigorous QA...
Seriously though, v2.4.11 was a disaster, and Linus noticed and thus released v2.4.12 as soon as he could, which IHMO was a smart move. Because of this rushed release, a few small details wasn't 100% merged (parport springs to mind), but v2.4.12 is mostly working.
Still, if you don't participate in the in between kernel QA yourself (by using the pre-patches), don't complain. Linux is made by volunteers, who do it in their spare time. Contribute instead of complaining!
Re:Joystick still broken
on
Linux 2.4.13
·
· Score: 1
No, as Linus has explained time and time again on the list, he does not "sit" on stuff. If a submitted patch hasn't gone into the next two or three pre-patches, it's because he's dropped it, either due to too much e-mail (the most common reason), missing/bad description of what it does (second most common) or bad/unwanted code (not too common.)
So, most presumably, Vojtech submitted the patch, but didn't resubmit it when Linus didn't react. Or, he submitted it to Alan only. And since Linus doesn't forward patches to Linus unless explicitly asked to if the subsystem has a maintainer, the patch probably got stuck there.
Slashdot Mirror
CVS has a lot of short-comings. Most people that use CVS are ready to admit that, I think. Maybe CVS works for gcc, but gcc has multiple persons with write access to the tree. The kernel bitkeeper repository has only one single person with write-access; Linus himself. Linus himself decides what goes in and what doesn't, by pulling from other developer's trees, or by applying normal patches.
Then again, CVS would probably be able to handle the kernel too. But Linus doesn't like CVS one single bit, and since he doesn't, the choice wasn't CVS vs BK, but rather no source-management system vs BK.
Oh, and Bitkeeper is in no way mandatory for kernel-development. Alan Cox and Alexander Viro, for instance, don't use BK, and have no trouble getting their contributions into the kernel. In fact, Viro commented that it got easier, since Linus got relieved of some work.
The fact that gcc was a prerequisite for the Linux-kernel doesn't change the fact that CVS is far inferior to BK. Oh, and it's not like BK is totally non-free. As long as you accept to have your changelogs logged to a server, you get the program for free. Furthermore, the source-code is available, and you are allowed to modify it, as long as it still passes the regression-tests and does nothing to circumvent the open-logging. To finnish off, the program will become GPL if BitMover ceases to exist (can't remember the exact terms, sorry...)
I'm not saying that I'm thrilled with having one important part of the kernel-development process non-free, but I agree when Larry McVoy says that people should spend their time coding a replacement instead of complaining.
While I'm all for science, the exploration of space et al., I'd still consider far more important to spend your time getting your representative in the senate to realise the insanity of such laws such as the DMCA and the SSSCA, and to hinder further steps down that lane. If you make your voice heard, better do it about someone worth being heard about.
I'm fully aware of that. I was commenting on older AS/400's. If I wasn't clear enough on that, then I'm sorry.
Sorry for replying to myself, but it seems I forgot to answer your question... No, zOS is not a Unix. zOS is OS/390 for the z900 (which is the 64-bit version of the S/390.)
Depends on how new AS/400's we're talking about, I think. The older AS/400's will never run Linux; no reasonable MMU. As for converting the applications, well, I'm pretty confident a lot of Linux-hackers would be happy to earn a living on turning old Cobol-code into C/Perl/Python/Befunge/[insert favourite language here]. I don't think IBM will do it, though.
We're not talking about AS/400's (the iSeries), but about the S/390's (the zSeries.) The AS/400 ran an operating-system called OS/400 which was some kind of Database-like operating system. The S/390 has seen quite a lot of different OS:es, MVS, OS/390 (now known as zOS) and some others. There is a Unix-version to be run on the S/390, but afaik not for the AS/400. The AS/400 is pretty special hardware, after all.
Well, I don't know why he'd want that. Probably personal preference. Maybe he has hardware not supported by the FreeBSD-kernel, maybe he wants some feature of the Linux-kernel not available in the FreeBSD-kernel. But is that really interesting?! It can be done, the code is open-sourced, and a real hacker doesn't do things out of real use anyway, but out of the hackvalue.
Not really, something I consider a good sign. I've applied about 15 bugfixes since December 2000, and intend to add some 4-5 more before the release of 2.0.40.
Grow up. No, the code has not been stolen in any way (and for that matter, using it wouldn't be stealing anyway, because of the license... But that's beside the point.) Rik van Riel has been talking a lot with the FreeBSD VM-wizards, and looked at the FreeBSD code. He has then developed a VM of his own for the Linux-kernel.
Oh, and it's not like *BSD is totally free from influence from the Linux-kernel... Just face it, the point of open-source is to help eachother out.
Ever heard of Linus Torvalds? Oh, and for the v2.4 kernel it's Marcelo Tosatti, for v2.2 it's Alan Cox. For v2.0, it's yours truly. It's hardly like anyone can get their code into the kernel. Anyone is free to submit patches though. That doesn't mean it'll get in.
As for the VM, yes, there have been problems (mostly with corner-cases, though), but v2.0.xx has a stable VM, v2.2.xx has a stable VM now, v2.4.xx has a stable, if somewhat unoptimal VM now, and v2.6 will hopefully have Rik van Riel's VM, which shares a lot of similarities with the VM from FreeBSD, but with some Linux-specific adaptments.
So please, don't spread FUD.
Yes, but Apple is one single vendor, and can't possible match the joint offerings from all the different PC-laptop vendors. They have to focus on a few products, and do those extremely well. Imho they've been quite successful.
As for the $799 iMac, it's available at the Apple online store, and is for everyone, not just students. But I agree, it's a limited machine. But you asked for a sub $1000-machine, not for a powerful sub $1000-machine in your original post...
You mean, like the $799 iMac (the non-LCD generation) and the TiBook (although 2.45 kg might not be ultra-light, it's still acceptably light, imho)?!
Huh? Where the f**k did you dream up that?! The Superdrive is a combined reader/recorder for DVD-R and standard CD-RW's, nothing else. And I'd really want one too...
I'm not a US resident, and I don't intend to ever become, because I want to be able to develop open-source software without having to worry about being prosecuted for implementing devices for copyright circumvention because I don't implement copyprotection-schemes in each and every program... But this is becoming waaay off-topic.
You do of course realise, that by supporting their claim for need of control, you also implicitly support things such as region-coding, CPRM, CSS, MacroVision and other things all implemented just to control the content.
The concerns of the RIAA and the MPAA is not really about the loss of money, because in most cases the people that download 10 GB's of MP3's wouldn't buy the records anyway, it's the loss of control they are worry about. They worry when they can't decide when an album is released in which country, and when and if a movie becomes available on DVD in a country. They worry when they can't decide for the end-user what fair use is, and they worry when they can't decide for the end-user what should be the preferred media and hardware.
And you really expect them to borrow me the record?! Because I won't stand for an hour in a record-store to listen to a record, and I will sure as hell not stand there for several hours to listen to the record several times (I almost never decide after the first listen, barring some masterpieces like Dark Side of the Moon by Pink Floyd.)
Look, I don't dislike Metallica's music, and I've bought every damn record they've released (barring some "best of"-collections and special editions); I've even got the original prints of Garage Days Revisited and Garage Days Re-revisited. However, I want to be able to listen to a record before I buy it. AND (most, not just Metallica's) records are at least twice as expensive as they ought to be.
As most bands/artists know that a good relation with the fans is the key to success, and that their record-companies takes most of the profit anyway,they don't really see MP3's as a threat, but rather as a momentum to spread their music and gain popularity, hence creating the opportunity for more sales. I'd guess the only larger band to actually support the RIAA would be Metallica...
No, you're getting it wrong. The code must not rely on the onboard DSP-chip that some modems hade, rather do all the signal-processing in software. If you don't process the signals, you can't have a modem, duh...
While Linux might not be perfect when it comes to SMP, it scales better than most other operating-systems for 1-8 processors. If you claim that Windows excels in SMP, you're definitely out on a limb.
Huhhh? v2.4.14 contains ReiserFS, a fully journalled filesystem, and JFFS2, a journalled flash filesystem. v2.4.15-pre6 also contains ext3, another fully journalled filesystem. IBM's filesystem JFS is ported completely to Linux and awaiting merging, ditto for SGI's XFS, eventhough the latter has some things to sort out first. Check your facts first, please?!
The problem with CML1 isn't readability, but expressibility. The language suffers sane ways to define dependencies. CML2 provides this. Of course, it's likely to take some time for people to get used to CML2, but then again, people still make a lots of mistakes with CML1...
Well, first of all, I've as of yet never fucked up my tree (but I do start from scratch every 10-15 th kernel, just to get rid of any removed files, since patch doesn't remove empty files), and second, it only takes me a couple of minutes to download a complete kernel, untar it and apply any patches onto it... And soon (at the end of this year), when GigaSunet is finished, the download will be even faster. Yummie.
The only source I'm really careful not to mess up is the v2.0.40-sourcetree, mainly because noone else has it :-)
But I think that was obvious to most people...
Oh my! The last two releases had bugs?! Gasp!
If you expect software to be totally bugfree, expect no software more advanced than hello world, and even then, greatly delayed by rigorous QA...
Seriously though, v2.4.11 was a disaster, and Linus noticed and thus released v2.4.12 as soon as he could, which IHMO was a smart move. Because of this rushed release, a few small details wasn't 100% merged (parport springs to mind), but v2.4.12 is mostly working.
Still, if you don't participate in the in between kernel QA yourself (by using the pre-patches), don't complain. Linux is made by volunteers, who do it in their spare time. Contribute instead of complaining!
No, as Linus has explained time and time again on the list, he does not "sit" on stuff. If a submitted patch hasn't gone into the next two or three pre-patches, it's because he's dropped it, either due to too much e-mail (the most common reason), missing/bad description of what it does (second most common) or bad/unwanted code (not too common.)
So, most presumably, Vojtech submitted the patch, but didn't resubmit it when Linus didn't react. Or, he submitted it to Alan only. And since Linus doesn't forward patches to Linus unless explicitly asked to if the subsystem has a maintainer, the patch probably got stuck there.