Recent copies of cdrecord and friends know how to talk to ATAPI devices using ide-cd, and don't need to use ide-scsi. Instead of (e.g.) dev=0,0,0 use (e.g.) dev=ATAPI:/dev/hdc. This also works under 2.4 kernels since 2.4.21 or so.
Kernel versions seem more frequent for two reasons:
- The development branch is active. Ideally, devel releases get made once every week or two, and this has been the case for a while AFAIK.
- The 2.4 release process has undergone some... unsnagging. There was about a year of wait between 2.4.19 and 2.4.20 (or was it.18 and.19... ?), and nobody wants to see that happen again. So, Marcelo is paying closer attention to his release schedule to make sure there aren't any more really big, really long kernel releases in his branch.
No offense, but if you can't debug drives not mounting on boot following someone else's instructions, I wouldn't recommend going to build your own distribution.
Have you read the excellent FAQ, or asked on lfs-support?
Good gods. It's 2003, and the FSF still hasn't hammered this point into people's heads?
It's "free" as in "freedom", not "free" as in "Look ma, I don't have to pay for software!" It's a commentary on what you're allowed to do with the software, not how you have to obtain it. RMS doesn't care if you sell your software; in fact, he supported himself before the FSF became a reality by selling tapes of Emacs.
Part of the issue is that with DOS, you have total control over the machine... no operating system to get in the way. I don't particularly consider it "programmer inefficiency" that the copy of Mozilla I'm running can't overwrite the kernel's memory. I can't code a good demo on Linux because I can't access the hardware (among other reasons). I do agree that people don't consider "efficient" programming as much nowadays... but quite frankly, there are a lot of projects that are having trouble just getting "correct" down. Pathological cases of that are probably what started the "premature optimization is the root of all evil" school.
I also disagree on games with "lots of videos and speech" being overkill on standard CDs on the issue of data representation, but I'm not a multimedia expert.
(Also, I dispute your "inside of one or two seconds". Four is about right, from what I remember of the bootup sounds.:3 )
You could have this problem, in theory, on an unswitched Ethernet network with a mixture of 10 Mbps- and 100 Mbps-capable hosts. The problem is that the bandwidth is shared, but not equally, because it just takes some users longer to transmit.
Basically, the way CSMA/CA works, when I want to transmit, I send a jamming signal. If I don't receive a jamming signal in some small amount of time, I can assume with some degree of safety that no-one else is trying to transmit at the same time. So, I go ahead and do my business, during which time no-one else can transmit.
Now, let's say you and the other person on the network are trying to send some large file. Say your networking implementation sends a jamming signal, transmits one TCP packet, and then unjams the channel, waiting for an ACK to send the next packet. The worst case scenario will end up with simple alternation: you send a packet, the other person sends a packet; you send a packet, the other person sends a packet; etc. (This doesn't strike me as terribly likely, but it's probably possible.) In this case, yes, your throughput will effectively be reduced to 1 Mbps; you only transmit data as often as the other person on your network. If you only transmit as much per packet as they do, bam! If, in this case, you transmit larger packets, which TCP allows, the effect will be mitigated somewhat.
This is why years of language study is a useful thing:D I was a bit disappointed, though, because it doesn't give much information on exactly why this happens. Guess I'll have to go see how CSMA/CA is different from CSMA/CD on my own. -- A primary analysis of Wi-Fi network performance anomalies was done by four reserchers of the Institute for Information Technology and Applied Mathematics (IMAG)'s Software Systems Resources unit. Martin Heusse, Franck Rousseau, Gilles Berger-Sabbatel, and Andrzej Duda just published the surprising results of their study for the INFOCOM conference in San Francisco, on of the most prestigious in the domain of networks research. it reveals that in certain very --- circumstances, this type of wireless network produces a relatively penalizing slowdown: users with better connectivity, and thus with better data flow, are penalized by those with degraded connections.
Local wireless networks based on the "Wi-Fi" (IEEE 802.11b) standard are starting to be deployed in a relatively large number of locations, and many models of portable computers already come with a Wi-Fi network card. Attempts providing connectivity in public places, by way of what are called "hot spots", are becoming more common. The number of potential users are increasing rapidly, and the first hot spots are in wide use, but can Wi-Fi networks stand up to the needs of numerous users and increased bandwidth demands?
In their usual operating mode, Wi-Fi networks are built upon on a wired network infrastructure. Wireless access points rely on a local, high-bandwidth network, most commonly Ethernet, and create a link between wireless network equipment and the local wired network, as well as the internet. In practice, wireless network cards use four flow levels with different signal modulation techniques that can be selected according to the quality of the connection to the access point. More simply, a card close to an access point can get good bandwidth, nominally 11 megabits/second; as it gets farther away, the levels go to 5.5 Mbit/s, 2 Mbit/s, and finally 1 Mbit/s, as the signal gets weaker and degrades.
As Wi-Fi networks are created, some users get the best flow (11 Mbit/s) in the access point's coverage area because they're close to the access point. A user enters in this coverage area and, being relatively far away, is connected at 1 Mbit/s. When this user communicates over wireless channels, that is, when he transmits data, it causes a drop in bandwidth for all the others, leaving them at a bandwidth apparently identical to his, 1 Mbit/s. No matter which bandwidth levels the original users are connected at, the weakest will be observed by all hosts.
This anomaly, inherent in networks relying on CSMA/CA (Carrier Sense Multiple Access / Collision Avoidance) which is defined in the Wi-Fi standard and revealed by the CNRS research team, penalises the network users. Despite a good connection, their apparent performance can become strongly degraded in a completely unforseeable manner, due simply to the activity of a third party connected to the same wireless access point at a lower bandwidth level.
However, though it will be observed on any network of this type, the impact of this anomaly should be more or less moderate for two reasons. First, most equipment today connects to the network in a sporadic and non-continuous manner; periods of activity, like downloading a web page, are relatively short compared to the time spent reading it. Conversly, if a long communication takes place - downloading a large video, for example - it will continuously penalize all users. A second mitigating factor comes from higher-level protocols, especially TCP, which perform some sort of flow-control that creates an effect on apparent bandwidth.
The researchers are currently working on solutions to limit or suppress this anomaly, which could become extremely limiting with the development of new communication applications, notably audio and video over the Internet.
Also, the "distributed Bitkeeper development model" pretty much panders to Linus' view of kernel development. This is because Bitkeeper was, after all, more or less started as a project to keep Linus from going crazy.
* CVS is in widespread use, mainly because it is free. It works fairly well for simple tasks, it's better than just using RCS. It has problems as the development effort gets large.
* CVS has a single repository model. Each work area is clear text only which means no revision control in the work area during development.
* BitKeeper provides staging areas. You can mimic CVS by having one master repository and several work areas. You can also extend that to have one master and several staging areas with several work areas below each staging area. This allows people working on related projects to merge amongst themselves before merging into the master. Anyone who has lived through a change that broke the build can see the value of staging areas.
* Merging in CVS is primitive at best.
* Branch management in CVS is a nightmare.
* CVS has no change sets, i.e., no atomic commits of changes which span files.
* CVS has no rename support.
* CVS was based on RCS and still has RCS' limitations. * On the plus side, CVS is free, works well enough for some development projects, and CVS repositories are easily converted to BitKeeper. If you can't afford a good source management product, use CVS, we'll help you migrate off of it when the time comes.
Everyone I've talked to who's ever touched it agrees that branching and merging in CVS is really, really ugly, and I know people who say CVS sucks horribly just because of those limitations. (Well, that and renaming.) OTOH, if your project isn't massively large and horribly complex, CVS is great, and I've had no bad experiences with it personally. Unfortunately, kernel development is massively large (and distributed) and horribly complex ^^;
Okay, first of all, the preferred Linux development method has always been "push patches to a maintainer, the maintainer will push patches to Linus". I don't imagine that many people had commit access to the main repo, though I obviously can't quote you a number. In any case, the preferred development method is still "push patches to a maintainer, the maintainer will push patches to Linus". So what platforms BK does and doesn't run on doesn't really matter one bit for the vast, vast majority of kernel developers.
Now, Linus is probably ALWAYS going to be running x86. I imagine the kernel developers will always be running one of: AIX >4.1.5, FreeBSD, HPUX >10, IRIX >6.5, Linux/Alpha, Linux/IA64, Linux/PARIST, Linux/MISP, Linux/PPC, Linux/SPARC, Linux/ARM, Linux/s390, Mac OS X, NetBSD, or Solaris, so platform compatibility (in practice) probably isn't an issue. (Unless you've written lots of software that runs reliably on that many platforms plus Windows, you really shouldn't be dissing the cross-platform nature of bitkeeper.)
Given his practices in the past, not his words recently, lm will probably be accomodating enough to try and port Bitkeeper to any platform someone Linus says needs commit access uses.
Also, dealing with branches is really bad, from what I've heard. Basically, everyone that I know who's actually deal with branching in CVS says that it blows goats, hard. This is obviously not a good thing for kernel development given Linus' "Linux is really just a bunch of different code trees, and people happen to call the one I run official" view of devolopment.
Bitkeeper's entire world view has basically been set up to pander to Linus' multiple-trees view. I believe cloning a BK repo is the equivalent of a CVS branch, and merging changes from lots of different sources is done fairly well, from what I've heard.
Kernels are cool if you like hardware. I started learning x86 architecture and assembly programming soon after I started with software, so I've always had a soft spot for hardware-related stuff:D
It can make a huge difference in your day-to-day life if you have (eg) a laptop that could benefit from cpufreq CPU clock scaling, or from improved ACPI support.
I think the specific Slashdot obsession is because it's the package that's actually called "Linux" though -_^
Debian uses old versions of everything. Debian is very conservative about what goes into its stable branch, which is good, except that you have things like known broken versions of software sitting around on your system unless you run testing or unstable.
From what I've heard, the 2.5 kernel looks to be a lot better on SMP, both in terms of stability and scalability with number of processors. This isn't something I've tracked much, though, since I only have UP hardware (for now). (What I'd really love to find is an old dual-proc EV56 or even EV67 machine for not too much money... sigh. Two testing grounds in one machine!)
And, Linux is most stable on x86 hardware because that's what most people run it on. Unfortunately, there just aren't as many people running Linux ppc, or the Alpha port, or Linux on Sparc V9, which means less testers and less developers. It would be nice to see the other architectures better off, but...
A jiffy is the kernel scheduler quantum. The kernel wakes up once every jiffy to update internal state and reschedule processes, basically. There's a constant called HZ that determines how long a jiffy is; on x86 HZ used to be 100, so a jiffy was 1 / 100 seconds. HZ is now 1000 on most architectures.
o New i/o scheduler, which seems to improve a lot of people's desktop performance;
o Better scheduler performance under loads with lots of processes;
o Rewritten scheduling and threading code, which, coupled with Ulich Drepper's NTPL library, greatly improves threading performance;
o ALSA for sound, and AGP 3 support;
o Faster and cleaner framebuffer support;
o Faster CD recording that doesn't need ide-scsi;
o Upgrades for NFS (v4), NTFS, and HFS+, as well as merges of JFS and XFS;
o System-level in-kernel profiling support;
o CPU Frequence scaling
o IPSec
More information can be found in Dave Jones' list of things to expect in 2.6. Personally, I think it's great to see features that benefit both big and small systems.
Yeah, I know ^^; Like I said, I'm aware that people reading the article could miss the distinction. But the better thing to do is not to complain about it where the article's author would never see it, but to write the author, IMO. I don't recall the reason Linus seems to think this whole naming issue is silly, either.
You get a lot of folks bashing on RMS because he politely asks people to at least acknowledge the work of the Free Software Foundation by calling the system GNU/Linux, but here you have Torvalds claiming entire responisibility of the OS, granted in response to a question about SCO's involvement in the origins of the OS, but nonetheless claiming total responsibility.
That's funny... in the part of the article you're quoting, Linus is just saying "I wrote the beginning of Linux [yes, he's talking about the kernel] myself, and I'm still the main person responsible for it [yes, he's talking about the kernel]". Which is true, in that he's basically the Linux project manager. (If you disagree with me, try getting something into his tree without convincing him that it's emininently useful and won't break shit.) That's not really saying that he dictates what happens to GNU/Linux, not by a long shot.
Look, as much as I agree with the GNU/Linux terminology in principle, I think it's really clear in context when Linus is talking about Linux and when he's talking about GNU/Linux in this article. Linus may be a bastard with an eye on world domination, but he's not an megalomaniacal bastard with an eye on world domination. (I will not be drawn into the subtleties of this debate here, because my personal opinion is irrelevant, and quite frankly, I have nothing new to bring to either side. And yes, there are people who could read this who don't know the difference; perhaps you should email the article author and ask him to post a revised revision, if you're concerned about it.)
I believe the rest of your comments would be better directed at the conductor of the interview, who's responsible for the content, rather than the people at Slashdot, 99% of whom already know this.
I run Debian. I haven't had any problems. The best thing you can do for Linux on PPC, period, is install the benh kernel from the Linux/PPC website, and then make sure you install the Apple-specific utilities. (You can get a nice list from 'apt-cache search ibook', 'apt-cache search powerbook', or just googling around for the laptop and distribution of your choice.)
I'll always recommend Debian because I've used it, liked it, and always had good experiences with it. (Stale packages aren't as much of an issue if you use testing or unstable.) I've heard good and bad things about Gentoo, not too much bad except that the default compile flags sometimes tend towards overoptimization; I've seen Gentoo build broken python before for AMD systems, for example. (This is especially ironic since portage is based on python.:/ ) I won't say "don't use Gentoo", though, since I've never used it myself; this is just what I've seen of other people's systems, and I have heard many good reviews.
The real lesson there, though, is make sure you really, really know what you're doing if you insist on building your system from scratch. ^_^ This goes double on an arch you don't know, and really for any non-x86 arch, since they don't get as much testing (less users). Also, a binary distribution is usually good for your first distro on a given architecture, since you can see how it sets up important things like boot setup and compare it to what you read about that arch's boot process.
What's the general theme of misfortune in the Gentoo PPC forum threads you've read? It may be just a Linux PPC thing, not a Gentoo thing.
It's not really a Slashdot nono. You don't get any help from kernel developers, period, if you experience problems on a system where any closed-source drivers have ever been loaded during the current power cycle. And for good reason; you can't really analyze the code to see if it's, say, smashing stack, or scribbling on the page cache, if you don't have the source. Since you can't rule out the closed-source elements because of this, it's harder to properly isolate the cause of, say, an oops; also, people like Alan have better things to do than narrow the cause of an oops down to code they can't debug.
Slashdot Mirror
Recent copies of cdrecord and friends know how to talk to ATAPI devices using ide-cd, and don't need to use ide-scsi. Instead of (e.g.) dev=0,0,0 use (e.g.) dev=ATAPI:/dev/hdc. This also works under 2.4 kernels since 2.4.21 or so.
nl - Netherlands
uk - United Kingdom
de - Deutschland
es - Espana
You're kidding, right?
This has been posted here before. Check out Dave's post-halloween document.
Kernel versions seem more frequent for two reasons:
... unsnagging. There was about a year of wait between 2.4.19 and 2.4.20 (or was it .18 and .19 ... ?), and nobody wants to see that happen again. So, Marcelo is paying closer attention to his release schedule to make sure there aren't any more really big, really long kernel releases in his branch.
- The development branch is active. Ideally, devel releases get made once every week or two, and this has been the case for a while AFAIK.
- The 2.4 release process has undergone some
Oi, it's not that hard. www.XX.kernel.org or ftp.XX.kernel.org, where XX is your two-letter country code, like fr for France.
No offense, but if you can't debug drives not mounting on boot following someone else's instructions, I wouldn't recommend going to build your own distribution.
Have you read the excellent FAQ, or asked on lfs-support?
Good gods. It's 2003, and the FSF still hasn't hammered this point into people's heads?
It's "free" as in "freedom", not "free" as in "Look ma, I don't have to pay for software!" It's a commentary on what you're allowed to do with the software, not how you have to obtain it. RMS doesn't care if you sell your software; in fact, he supported himself before the FSF became a reality by selling tapes of Emacs.
Hmmm.
... no operating system to get in the way. I don't particularly consider it "programmer inefficiency" that the copy of Mozilla I'm running can't overwrite the kernel's memory. I can't code a good demo on Linux because I can't access the hardware (among other reasons). I do agree that people don't consider "efficient" programming as much nowadays ... but quite frankly, there are a lot of projects that are having trouble just getting "correct" down. Pathological cases of that are probably what started the "premature optimization is the root of all evil" school.
:3 )
Part of the issue is that with DOS, you have total control over the machine
I also disagree on games with "lots of videos and speech" being overkill on standard CDs on the issue of data representation, but I'm not a multimedia expert.
(Also, I dispute your "inside of one or two seconds". Four is about right, from what I remember of the bootup sounds.
You really need to go play Beatmania. :D
You could have this problem, in theory, on an unswitched Ethernet network with a mixture of 10 Mbps- and 100 Mbps-capable hosts. The problem is that the bandwidth is shared, but not equally, because it just takes some users longer to transmit.
No, you're not.
Basically, the way CSMA/CA works, when I want to transmit, I send a jamming signal. If I don't receive a jamming signal in some small amount of time, I can assume with some degree of safety that no-one else is trying to transmit at the same time. So, I go ahead and do my business, during which time no-one else can transmit.
Now, let's say you and the other person on the network are trying to send some large file. Say your networking implementation sends a jamming signal, transmits one TCP packet, and then unjams the channel, waiting for an ACK to send the next packet. The worst case scenario will end up with simple alternation: you send a packet, the other person sends a packet; you send a packet, the other person sends a packet; etc. (This doesn't strike me as terribly likely, but it's probably possible.) In this case, yes, your throughput will effectively be reduced to 1 Mbps; you only transmit data as often as the other person on your network. If you only transmit as much per packet as they do, bam! If, in this case, you transmit larger packets, which TCP allows, the effect will be mitigated somewhat.
This is why years of language study is a useful thing :D I was a bit disappointed, though, because it doesn't give much information on exactly why this happens. Guess I'll have to go see how CSMA/CA is different from CSMA/CD on my own.
--
A primary analysis of Wi-Fi network performance anomalies was done by four reserchers of the Institute for Information Technology and Applied Mathematics (IMAG)'s Software Systems Resources unit. Martin Heusse, Franck Rousseau, Gilles Berger-Sabbatel, and Andrzej Duda just published the surprising results of their study for the INFOCOM conference in San Francisco, on of the most prestigious in the domain of networks research. it reveals that in certain very --- circumstances, this type of wireless network produces a relatively penalizing slowdown: users with better connectivity, and thus with better data flow, are penalized by those with degraded connections.
Local wireless networks based on the "Wi-Fi" (IEEE 802.11b) standard are starting to be deployed in a relatively large number of locations, and many models of portable computers already come with a Wi-Fi network card. Attempts providing connectivity in public places, by way of what are called "hot spots", are becoming more common. The number of potential users are increasing rapidly, and the first hot spots are in wide use, but can Wi-Fi networks stand up to the needs of numerous users and increased bandwidth demands?
In their usual operating mode, Wi-Fi networks are built upon on a wired network infrastructure. Wireless access points rely on a local, high-bandwidth network, most commonly Ethernet, and create a link between wireless network equipment and the local wired network, as well as the internet. In practice, wireless network cards use four flow levels with different signal modulation techniques that can be selected according to the quality of the connection to the access point. More simply, a card close to an access point can get good bandwidth, nominally 11 megabits/second; as it gets farther away, the levels go to 5.5 Mbit/s, 2 Mbit/s, and finally 1 Mbit/s, as the signal gets weaker and degrades.
As Wi-Fi networks are created, some users get the best flow (11 Mbit/s) in the access point's coverage area because they're close to the access point. A user enters in this coverage area and, being relatively far away, is connected at 1 Mbit/s. When this user communicates over wireless channels, that is, when he transmits data, it causes a drop in bandwidth for all the others, leaving them at a bandwidth apparently identical to his, 1 Mbit/s. No matter which bandwidth levels the original users are connected at, the weakest will be observed by all hosts.
This anomaly, inherent in networks relying on CSMA/CA (Carrier Sense Multiple Access / Collision Avoidance) which is defined in the Wi-Fi standard and revealed by the CNRS research team, penalises the network users. Despite a good connection, their apparent performance can become strongly degraded in a completely unforseeable manner, due simply to the activity of a third party connected to the same wireless access point at a lower bandwidth level.
However, though it will be observed on any network of this type, the impact of this anomaly should be more or less moderate for two reasons. First, most equipment today connects to the network in a sporadic and non-continuous manner; periods of activity, like downloading a web page, are relatively short compared to the time spent reading it. Conversly, if a long communication takes place - downloading a large video, for example - it will continuously penalize all users. A second mitigating factor comes from higher-level protocols, especially TCP, which perform some sort of flow-control that creates an effect on apparent bandwidth.
The researchers are currently working on solutions to limit or suppress this anomaly, which could become extremely limiting with the development of new communication applications, notably audio and video over the Internet.
Also, the "distributed Bitkeeper development model" pretty much panders to Linus' view of kernel development. This is because Bitkeeper was, after all, more or less started as a project to keep Linus from going crazy.
From this page:
* CVS is in widespread use, mainly because it is free. It works fairly well for simple tasks, it's better than just using RCS. It has problems as the development effort gets large.
* CVS has a single repository model. Each work area is clear text only which means no revision control in the work area during development.
* BitKeeper provides staging areas. You can mimic CVS by having one master repository and several work areas. You can also extend that to have one master and several staging areas with several work areas below each staging area. This allows people working on related projects to merge amongst themselves before merging into the master. Anyone who has lived through a change that broke the build can see the value of staging areas.
* Merging in CVS is primitive at best.
* Branch management in CVS is a nightmare.
* CVS has no change sets, i.e., no atomic commits of changes which span files.
* CVS has no rename support.
* CVS was based on RCS and still has RCS' limitations.
* On the plus side, CVS is free, works well enough for some development projects, and CVS repositories are easily converted to BitKeeper. If you can't afford a good source management product, use CVS, we'll help you migrate off of it when the time comes.
Everyone I've talked to who's ever touched it agrees that branching and merging in CVS is really, really ugly, and I know people who say CVS sucks horribly just because of those limitations. (Well, that and renaming.) OTOH, if your project isn't massively large and horribly complex, CVS is great, and I've had no bad experiences with it personally. Unfortunately, kernel development is massively large (and distributed) and horribly complex ^^;
Okay, first of all, the preferred Linux development method has always been "push patches to a maintainer, the maintainer will push patches to Linus". I don't imagine that many people had commit access to the main repo, though I obviously can't quote you a number. In any case, the preferred development method is still "push patches to a maintainer, the maintainer will push patches to Linus". So what platforms BK does and doesn't run on doesn't really matter one bit for the vast, vast majority of kernel developers.
Now, Linus is probably ALWAYS going to be running x86. I imagine the kernel developers will always be running one of: AIX >4.1.5, FreeBSD, HPUX >10, IRIX >6.5, Linux/Alpha, Linux/IA64, Linux/PARIST, Linux/MISP, Linux/PPC, Linux/SPARC, Linux/ARM, Linux/s390, Mac OS X, NetBSD, or Solaris, so platform compatibility (in practice) probably isn't an issue. (Unless you've written lots of software that runs reliably on that many platforms plus Windows, you really shouldn't be dissing the cross-platform nature of bitkeeper.)
Given his practices in the past, not his words recently, lm will probably be accomodating enough to try and port Bitkeeper to any platform someone Linus says needs commit access uses.
Also, dealing with branches is really bad, from what I've heard. Basically, everyone that I know who's actually deal with branching in CVS says that it blows goats, hard. This is obviously not a good thing for kernel development given Linus' "Linux is really just a bunch of different code trees, and people happen to call the one I run official" view of devolopment.
Bitkeeper's entire world view has basically been set up to pander to Linus' multiple-trees view. I believe cloning a BK repo is the equivalent of a CVS branch, and merging changes from lots of different sources is done fairly well, from what I've heard.
Kernels are cool if you like hardware. I started learning x86 architecture and assembly programming soon after I started with software, so I've always had a soft spot for hardware-related stuff :D
It can make a huge difference in your day-to-day life if you have (eg) a laptop that could benefit from cpufreq CPU clock scaling, or from improved ACPI support.
I think the specific Slashdot obsession is because it's the package that's actually called "Linux" though -_^
Think it'll run Duke Nukem Forever?
Debian uses old versions of everything. Debian is very conservative about what goes into its stable branch, which is good, except that you have things like known broken versions of software sitting around on your system unless you run testing or unstable.
... sigh. Two testing grounds in one machine!)
...
From what I've heard, the 2.5 kernel looks to be a lot better on SMP, both in terms of stability and scalability with number of processors. This isn't something I've tracked much, though, since I only have UP hardware (for now). (What I'd really love to find is an old dual-proc EV56 or even EV67 machine for not too much money
And, Linux is most stable on x86 hardware because that's what most people run it on. Unfortunately, there just aren't as many people running Linux ppc, or the Alpha port, or Linux on Sparc V9, which means less testers and less developers. It would be nice to see the other architectures better off, but
A jiffy is the kernel scheduler quantum. The kernel wakes up once every jiffy to update internal state and reschedule processes, basically. There's a constant called HZ that determines how long a jiffy is; on x86 HZ used to be 100, so a jiffy was 1 / 100 seconds. HZ is now 1000 on most architectures.
Well, some of the nice things are:
o New i/o scheduler, which seems to improve a lot of people's desktop performance;
o Better scheduler performance under loads with lots of processes;
o Rewritten scheduling and threading code, which, coupled with Ulich Drepper's NTPL library, greatly improves threading performance;
o ALSA for sound, and AGP 3 support;
o Faster and cleaner framebuffer support;
o Faster CD recording that doesn't need ide-scsi;
o Upgrades for NFS (v4), NTFS, and HFS+, as well as merges of JFS and XFS;
o System-level in-kernel profiling support;
o CPU Frequence scaling
o IPSec
More information can be found in Dave Jones' list of things to expect in 2.6. Personally, I think it's great to see features that benefit both big and small systems.
Yeah, I know ^^; Like I said, I'm aware that people reading the article could miss the distinction. But the better thing to do is not to complain about it where the article's author would never see it, but to write the author, IMO. I don't recall the reason Linus seems to think this whole naming issue is silly, either.
Uhhhh ... wow.
... in the part of the article you're quoting, Linus is just saying "I wrote the beginning of Linux [yes, he's talking about the kernel] myself, and I'm still the main person responsible for it [yes, he's talking about the kernel]". Which is true, in that he's basically the Linux project manager. (If you disagree with me, try getting something into his tree without convincing him that it's emininently useful and won't break shit.) That's not really saying that he dictates what happens to GNU/Linux, not by a long shot.
You get a lot of folks bashing on RMS because he politely asks people to at least acknowledge the work of the Free Software Foundation by calling the system GNU/Linux, but here you have Torvalds claiming entire responisibility of the OS, granted in response to a question about SCO's involvement in the origins of the OS, but nonetheless claiming total responsibility.
That's funny
Look, as much as I agree with the GNU/Linux terminology in principle, I think it's really clear in context when Linus is talking about Linux and when he's talking about GNU/Linux in this article. Linus may be a bastard with an eye on world domination, but he's not an megalomaniacal bastard with an eye on world domination. (I will not be drawn into the subtleties of this debate here, because my personal opinion is irrelevant, and quite frankly, I have nothing new to bring to either side. And yes, there are people who could read this who don't know the difference; perhaps you should email the article author and ask him to post a revised revision, if you're concerned about it.)
I believe the rest of your comments would be better directed at the conductor of the interview, who's responsible for the content, rather than the people at Slashdot, 99% of whom already know this.
I run Debian. I haven't had any problems. The best thing you can do for Linux on PPC, period, is install the benh kernel from the Linux/PPC website, and then make sure you install the Apple-specific utilities. (You can get a nice list from 'apt-cache search ibook', 'apt-cache search powerbook', or just googling around for the laptop and distribution of your choice.)
:/ ) I won't say "don't use Gentoo", though, since I've never used it myself; this is just what I've seen of other people's systems, and I have heard many good reviews.
I'll always recommend Debian because I've used it, liked it, and always had good experiences with it. (Stale packages aren't as much of an issue if you use testing or unstable.) I've heard good and bad things about Gentoo, not too much bad except that the default compile flags sometimes tend towards overoptimization; I've seen Gentoo build broken python before for AMD systems, for example. (This is especially ironic since portage is based on python.
The real lesson there, though, is make sure you really, really know what you're doing if you insist on building your system from scratch. ^_^ This goes double on an arch you don't know, and really for any non-x86 arch, since they don't get as much testing (less users). Also, a binary distribution is usually good for your first distro on a given architecture, since you can see how it sets up important things like boot setup and compare it to what you read about that arch's boot process.
What's the general theme of misfortune in the Gentoo PPC forum threads you've read? It may be just a Linux PPC thing, not a Gentoo thing.
It's not really a Slashdot nono. You don't get any help from kernel developers, period, if you experience problems on a system where any closed-source drivers have ever been loaded during the current power cycle. And for good reason; you can't really analyze the code to see if it's, say, smashing stack, or scribbling on the page cache, if you don't have the source. Since you can't rule out the closed-source elements because of this, it's harder to properly isolate the cause of, say, an oops; also, people like Alan have better things to do than narrow the cause of an oops down to code they can't debug.