If Comcast wanted, they wouldn't have to rewrite packets in order to read all your web traffic if they're your ISP. They can just read all of your unencrypted traffic anyway, without modifying it to make you suspicious.
If their proxy isn't standards-compliant, that's somewhat annoying. It's somewhat likely that this actually *improves* anonymity, though, because web sites cannot necessarily track users by IP address. And this doesn't seem to affect SSL-encrypted traffic (which couldn't be proxied without the user agreeing, since SSL resists man-in-the-middle), which is all of the traffic which is at all hidden. This is like looking at people's postcards-- sure, it's not polite, but the things aren't even covered in anything.
I do wonder if this affects their common-carrier status at all, however. If they're doing non-trivial things to the traffic, they could be held liable for pages they pass on to customers.
OS X isn't really the same thing. Sure, it runs just about all the Linux applications you might want, but it acts very differently. According to my friend who is used to linux/solaris and MacOS, it isn't really like either of these.
That all makes perfect sense: why did Apple bother to write OS X, when Linux already worked fine? Because they wanted something different. But if it's different, it makes sense to run Linux instead, if what you want is a Linux system.
There's another factor, which is not about practicality: if you really want to know what this new machine is made of, there's no better way to find out for yourself than to port Linux to it. You'll quickly find out all of the quirks in the hardware with relatively little time spent working on non-platform-specific code.
#1 is a good point. People don't like their interfaces changed on them. I read email in Pine, because that was what my first email program was. When I went to college and couldn't use Pine, I ended up installing linux, forwarding all of my email, and running Pine there. I don't like Gnome or KDE because I'm used to fvwm. Reportedly, some of the desktop software acts like Office, and Wine is reportedly becoming useful for running Office. I haven't tried any of this, because, of course, I can't stand any interface other than the one I'm used to.
Point 2 is misinformed. If you get rid of Windows, you can get rid of the army of windows sysadmins and hire a linux sysadmin or two. Linux is much easier to administer, if only because MicroSoft support is so bad, and you can't fix anything with it. You won't, admittedly, necessarily be able to keep the same support staff without retraining, but the end result is better.
Point 3 is foolish. Nobody will use any software currently available in a year or two. The best way to acquire skills would be to use half KDE and half Gnome. That way, you can't get used to the current interfaces, which will be the out-of-date versions that won't read new documents when you get to the real world.
Win2k owns the world out there now. Pretty soon, it'll be unsupported and unavailable. There are plenty of places that use a mix of windows and linux now, and, if you want to use linux, that just means one fewer machine that breaks each month, and that will have to be bought again in a year or two.
Actually, Windows has used user mode for programs since at least 3.1. If it were in kernel mode for programs, you couldn't get GPFs-- the system would just die, like it did in DOS.
According to Robert Love's benchmarks, the pre-emptive kernel actually does perform better even for computation-intensive tasks. Having a pre-emptive kernel just gives the scheduler better control over the system. I suspect that because most syscalls are i/o-related, everything is better becasue either a process didn't do many syscalls, in which case it would get cheated by processes whose timeslices expired during syscalls, or it did i/o, and didn't get its turn back quite as soon as it could.
Consider, however, the case where the reason a task is preempted in the kernel is that it has used all of its timeslice. Without the preemptable kernel patch, the task cannot be interrupted to schedule another task. In order to make guarantees about how much time will be given to each process, it needs to be possible to stop a process when its time is up essentially no matter what the process is doing.
The issues you raise are a matter of scheduling policy, not of whether the kernel is preemptible. Furthermore, for most interactive tasks, the correct behavior is to react quickly, because those tasks haven't used up their timeslices, since they blocked waiting for input. In this case, interactive processes give up the CPU to wait for input, and then get their time back as soon as they have a use for it.
Of course, this all also applies to tasks which "interact" with the network or the hard drives, which is any task when you have swap space. Processes which are waiting on input want to run as soon as their input is ready, and don't care about time before that. Processes which are not waiting on input want to run as much as possible, and don't care exactly when. Having the scheduler's instructions followed as closely as possible benefits both kinds.
The email described why something significantly less extreme (Gnome should support.NET software, and new software should be written with.NET) is a good idea. Of course, he talks about this for Gnome 3 or 4, which are a long way off-- by that time.NET will be either totally gone, forked by Mono (as UNIX is forked by Linux), or so totally standardized that nobody can change it.
Personally, I think that the idea of a common VM, both language and platform independent, providing runtime services (e.g., memory allocation/garbage collection) and safety (e.g., bounds checking) is a good idea. I think that.NET in particular is somewhat weaker because it was invented by Microsoft, and it is evidentally not sufficiently language-independent to be a suitable target for most languages people would like to use (C++ and python in particular, not to mention Smalltalk, Lisp, or many less common ones).
It seems like there is a need for a common VM and runtime system. CLR evidently fails to be a suitable target for many languages. It's certainly possible to create such a thing: actual machine languages are such. The idea would be a VM that is easy to implement on just about any platform, along with common calling conventions for the various kinds of calls supported by different languages.
It seems to me like the gcc CNI design is a good start, although gcc doesn't target a virtual machine.
It seems to me like the right sort of VM would be a stack-based RISC architecture with bounds-checked pointer arithmatic, and probably some sort of GC. Code would be pointer-referenced blocks. The important part would be that it wouldn't have language-specific and CISC opcodes which would deal with objects and classes; at most it would make sense to have essentially installable microcode for a language's dynamic dispatch mechanism and such.
Note that this isn't Myth II itself, but the metaserver, which allows people's copies of the game to find each other and negotiate games.
This doesn't mean they're opening the Myth II engine; it just means that when bungie.net isn't running a Myth II server, people who want to play online can still do so.
Actually, he feels the Changelog is too detailed for posting to linux-kernel. It's generally best to keep announcements relatively brief. Additionally, prepatch Changelogs are since the last real release, which means that -pre10 would be 10 times as big, and contain 90% old information. A much smaller changelog would be preferable for putting in announcements, with the full changelog available on the web for those who are interested.
Also, there's a lot of cruft in the changelog that just isn't relevant: changeset ids and so forth. All the details of how the changes came to be in the kernel aren't that important.
It is likely that there will emerge a single Linux vendor that will provide Linux to the masses. On the other hand, this is unlikely to cut into the community, because the community has never been about that, nor needed that.
Furthermore, there's no way that the big vendor will get the size necessary to actually produce even a significant fraction of the Linux software. And there's no reason they should: if Apple and Adobe can have a relationship such that people generally buy both MacOS and Photoshop if they buy either, there's no reason that a commercial Linux vendor and a bunch of free software projects can't have this relationship, too. The case of Microsoft, where a single company can actually provide all the software, is unlikely to arise in the Linux world, just because the structure of Linux makes it hard to create or maintain a monopoly, and lacking a monopoly, it is impossible to get the money or the army of programmers.
I think there will be a company that makes a lot of money on packaging Linux and selling it to people who don't want to change it very much and want support for it as is.
I think there will be a number of companies selling Linux software, once a significant portion of consumers can be presumed to have Linux; since there's no Microsoft there, there's the opportunity for another company to sell software.
I think the main effect of the free software which will be available will be to limit the space that companies will write software in. If there is really solid free software in place, companies will use it rather than competing with it. The projects I see as this solid are the kernel, the common libraries (libc, ncurses, libjpeg, zlib, openssl, etc), the GNU utilities, XFree86, emacs, and vi. Companies will, for instance, not try to compete with X, but also not contribute much to it, and use it. Sure, they benefit from it, but only as consumers of a free and useful raw material.
I put a couple hundred dollars into VA a while ago. It seems to me that this money went toward improving Linux software. I lost money on it, of course, but I think I got more back in terms of, say, software I could find due to SourceForge and more reliable hardware and software. While investors are normally in it for the possibility of getting more cash back for the stock than they paid for it, some people invested in Linux companies because, even if the money didn't produce more money, it would produce more value.
But the product of an patch integrator wouldn't be the "real" Linux anyway, since even people who get their kernels from kernel.org wouldn't normally use it. In order to do so, they'd have to get and apply a patch which is explicitly "the patches that Linus hasn't applied". The people who would actually do so are the people whose feedback Linus would want in decided whether to apply the patches.
And what Linus is, in general, concerned about is not the disasters, which are generally cleaned up as soon as they arise, and before anyone who wasn't warned has anything to do with them. He's concerned about directions kernel development could take. He wants to continue to get patches that add functionality he thinks is good, and he wants to avoid stuff he doesn't like creeping in. If someone else is getting the patches, he might not receive a patch which he would find very interesting but someone else might reject out of hand (not that he'd accept it, but he might put in the effort to help the submitter clean it up if he thought the feature was worth it). And if someone else builds up a lot of patches which the developers have been expecting to go in eventually that he has fundamental disagreements with, he might find it hard to reject them and get versions which do things differently.
On the other hand, I think that both of these effects are due to him not looking at all of the patches he gets, not the existence of an intermediary; they are already happening, due to him being overwhelmed by patches. So long as people still send him all of the patches, just in case one of them catches his fancy, and he continues to maintain the official version, the situation can only improve for him, since he can mostly deal with obvious and unexciting patches through the intermediary, who can verify that they make the compiler happier and don't change the behaviour, or are exclusively in sections he isn't interested in anyway.
Re:Use his power for good, not evil (or less good:
on
Borking Outlook Express
·
· Score: 5, Funny
You could, of course, avoid writing emails that would not exclude Outlook users, but you would have to be careful not to
begin any lines of your message wrong, which means that having your mailer arrange the line-breaks for you won't work.
Obviously, working around all of the bugs in software which people might use is a pain, and shouldn't be your
responsibility. After all, it is local mail delivery programs that deal with lines that start with "From". It would suck to
end up having to carefully tune your content to broken implementations. And if you've decided not to support broken mailers
why not trigger the bug intentionally, so people don't read part of your conversation before running into a message
they can't read? I think that people using mailers which don't understand the MIME format shouldn't stop you from using
attachments. If a message conforms to all applicable standards, it's fine by me. Attaching a Word document is perfectly
legitimate, although the document itself doesn't conform to any Internet Standards other than "binary data".
What Stephen King couldn't do was different: getting people to pay to read it once without getting anything for it.
Additionally, Stephen King is a well-known hardcopy author. There probably aren't that many people who found out about him by doing a web search for horror novels, found his book, read it online, and considered paying for it.
On the other hand, if 25% of the people who read the book online pay for a copy, and more than 4 times as many people read it because it should up conveniently in a web search on the subject and they can read it without paying for a book by an author they don't know, he comes out ahead anyway.
The money he fails to make on the people who don't buy it when they read it is probably much much less than the money he'd have to spend on advertizing in order to get the same number of people to read it. The cost of promoting a book (unless you're Stephen King, and don't need to promote it) is greater than the rest of the costs of publication combined.
When I worked there back in the late 90s, my group's furniture was old and needed replacing: the lounge's chairs were kind of ratty, the keyboard trays kept falling off of the desks, and there weren't enough desk chairs for the number of desks.
We never did get any new furniture. If we'd wanted high-end workstations to sit on, we could have had those, but furniture was just impossible.
Probably now groups will take up a collection and buy themselves new furniture, since the lab isn't going to say they'dd buy it but not actually do so.
You can be tried for a crime which you have been accused of committing against after you were last tried for it. If you've been found innocent of beating someone up, you can't then go beat the person up, and escape trial because of having been tried for it before. It's a different crime if there are new events involved, and MicroSoft has done things in the past few years.
I built a new box when 2.4.1 was new, installed that, and didn't have any problems with it. When Linus started 2.5, I decided to get the next 2.4 version, so I'm now running 2.4.17. I've had one lockup, with the ALSA driver for 2.4.17. Of course, this is on my desktop box, which I only turn on when I actually go home from work and still want to do computer things.
With 2.4.1, it didn't have any trouble with giving up cleanly on building Mozilla in too little memory. I don't actually have any swap, since I haven't quite recovered from 1.2.13 with a small swap partition on the only hard drive (with swap, it would slow to a crawl for half an hour *before* killing some things and recovering. Without swap, it would just kill things and recover). I haven't tried doing anything extreme on 2.4.17, although I've been meaning to now that I'm using ext3.
I haven't actually seen a PocketPC yet, so this is just based on MS's subway ad.
There was a Palm and a PocketPC, both showing weather reports. The Palm's report fit on the screen, and included the current day. The PocketPC needed a scrollbar (which is always a pain), and seemed to start without the current day on the screen. The weather reports were entirely different. Guess which one I'd trust.
Evidentally, the PocketPC is a device for people whose requirement in a handheld is a diagonal gradient. I suspect, on the other hand, that most people who actually want to use handhelds for anything already have Palms. The remaining market may only be for people who want a pretty device that doesn't work.
If you can copy & paste someone else's code, and it does what your code is supposed to do, then you shouldn't have been asked to write it yourself. Just use your coworker's code.
If you can copy & paste someone else's code, and change it slightly so that it does what you want it to do, then you're a perl programmer. Or rather, then you can work effectively in languages you don't really know, which is a valuable skill when you're doing elementary programming tasks.
Realistically, if someone has only taken the basic classes and not anything more advanced, I wouldn't give them a task more complicated than a simple cut & paste from a script lying around.
Of course, this is one of the situations where the solution you would use in the real world isn't the desired result. In the real world, everyone would be doing different things (and you could copy the code if you wanted, but it would probably be easier not to), but that would be impossible to assign or grade (unless the problems were in some extremely clever way based on the student's name or ID number or something).
I expect that the sound quality is more a function of the sound driver architecture and common code than of the Yamaha-specific driver; the latter just has to know how to configure the card and where to send the data and in what format and such, while the former is responsible for the actual data conversion and getting the data to the card in time to play it.
Of course, I don't really know much about the details, so I'm not sure. But I think the device-specific driver code is more responsible for stability and feature completeness than for quality.
It started out with Rik's VM in the kernel, since it was a promising new development. However, once it was in Linus's kernel, the fact that Rik's development style was not compatible with Linus's source control style because an issue, because the VM wasn't getting updated in Linus's tree.
So Linus switches to the other VM, which is based more on the original. This means that Rik can do his development without dealing with Linus and the Linus tree can have an up-to-date VM. When Rik's is to the point where he's really happy with it and he doesn't think he'll have to make a lot of patches (and it does all the things he wants), it will probably go back in.
Since then, Rik and Linus have figured out (hopefully) how their interaction failed to work, and what Rik has to say along with his patches to make Linus know they're worth looking at. It turns out that it is possible to automate this process, such that a script will send the patches when appropriate, with the right assurances of freshness (having actually tested them, of course).
Linus wants to be able to ignore any patch that isn't for the part he's thinking about at the time (e.g., non-block-i/o patches around the beginning of 2.5). When it becomes interesting again, however, the original patch may not be right any more. Having not looked at the patch at the time when it was sent, Linus can't determine whether it is still good, since the author may have found bugs, and he doesn't know exactly what the patch was supposed to do. He wants the author to make any updates needed and resend it. It may be, of course, that the patch doesn't need to be changed, and the author doesn't have a new and better patch, but Linus can't tell unless the author sends it again with a note that it's still good.
So Rik's patchbot will test whether the patch still applies and still works, and has not been replaced by a new version, and then will send it again until Linus actually looks at it. This seems to me like a good plan, since it doesn't require Linus to test everyone's old patches and have a complicated mail system. And Linus won't accidentally apply the wrong version of a patch or be unable to find a patch.
IIRC, the OSS driver for Yamaha is reportedly at least as stable as the ALSA one. So it's possible that the final merge will involve a chunk of this code as the Yamaha driver (i.e., as the part in drivers/sound). Just because the architecture is going to change doesn't mean that all of the drivers will just go away...
Why don't the Lindows people subpoena MicroSoft's customer list? I'm sure they could find out a lot of potentially useful information from MS customers. Er, useful in the court case, I mean.
Given MS's record with getting the courts to like them, it doesn't sound too implausible that the court would order them to comply (or drop the suit).
It's true that MicroSoft has a good case here, but that doesn't mean they won't mess it up. They seem not to have realized that, while justice is theoretically blind, it can still you giving it the finger.
The real issue is the possibility that your client will use UDP. UDP is normally fine, but it doesn't handle reliable delivery, and people using it who want reliability won't necessarily do so correctly (i.e., by using TCP, not UDP).
UDP is intended for things like realtime audio. If a packet gets dropped, the receiver doesn't want that packet anyway. (I.e., If packet 3 gets dropped, the receiver will play packets 1, 2, nothing, 4, 5). For file transfer, you want every packet, so that you get the whole thing eventually. If you use UDP (and, in particular, if everyone uses UDP), you'll get a lot of resends in a non-optimal pattern.
So the problem isn't in sending files as packets, it's in sending the packets in an inefficient way. Essentially, they're worried that it will be done like NFS instead of like FTP.
Slashdot Mirror
If Comcast wanted, they wouldn't have to rewrite packets in order to read all your web traffic if they're your ISP. They can just read all of your unencrypted traffic anyway, without modifying it to make you suspicious.
If their proxy isn't standards-compliant, that's somewhat annoying. It's somewhat likely that this actually *improves* anonymity, though, because web sites cannot necessarily track users by IP address. And this doesn't seem to affect SSL-encrypted traffic (which couldn't be proxied without the user agreeing, since SSL resists man-in-the-middle), which is all of the traffic which is at all hidden. This is like looking at people's postcards-- sure, it's not polite, but the things aren't even covered in anything.
I do wonder if this affects their common-carrier status at all, however. If they're doing non-trivial things to the traffic, they could be held liable for pages they pass on to customers.
For the funky flat-panel-on-stalk screen? OS X isn't really much like Linux, and an Athlon doesn't have Apple's exciting and strange hardware.
OS X isn't really the same thing. Sure, it runs just about all the Linux applications you might want, but it acts very differently. According to my friend who is used to linux/solaris and MacOS, it isn't really like either of these.
That all makes perfect sense: why did Apple bother to write OS X, when Linux already worked fine? Because they wanted something different. But if it's different, it makes sense to run Linux instead, if what you want is a Linux system.
There's another factor, which is not about practicality: if you really want to know what this new machine is made of, there's no better way to find out for yourself than to port Linux to it. You'll quickly find out all of the quirks in the hardware with relatively little time spent working on non-platform-specific code.
#1 is a good point. People don't like their interfaces changed on them. I read email in Pine, because that was what my first email program was. When I went to college and couldn't use Pine, I ended up installing linux, forwarding all of my email, and running Pine there. I don't like Gnome or KDE because I'm used to fvwm. Reportedly, some of the desktop software acts like Office, and Wine is reportedly becoming useful for running Office. I haven't tried any of this, because, of course, I can't stand any interface other than the one I'm used to.
Point 2 is misinformed. If you get rid of Windows, you can get rid of the army of windows sysadmins and hire a linux sysadmin or two. Linux is much easier to administer, if only because MicroSoft support is so bad, and you can't fix anything with it. You won't, admittedly, necessarily be able to keep the same support staff without retraining, but the end result is better.
Point 3 is foolish. Nobody will use any software currently available in a year or two. The best way to acquire skills would be to use half KDE and half Gnome. That way, you can't get used to the current interfaces, which will be the out-of-date versions that won't read new documents when you get to the real world.
Win2k owns the world out there now. Pretty soon, it'll be unsupported and unavailable. There are plenty of places that use a mix of windows and linux now, and, if you want to use linux, that just means one fewer machine that breaks each month, and that will have to be bought again in a year or two.
Actually, Windows has used user mode for programs since at least 3.1. If it were in kernel mode for programs, you couldn't get GPFs-- the system would just die, like it did in DOS.
According to Robert Love's benchmarks, the pre-emptive kernel actually does perform better even for computation-intensive tasks. Having a pre-emptive kernel just gives the scheduler better control over the system. I suspect that because most syscalls are i/o-related, everything is better becasue either a process didn't do many syscalls, in which case it would get cheated by processes whose timeslices expired during syscalls, or it did i/o, and didn't get its turn back quite as soon as it could.
Consider, however, the case where the reason a task is preempted in the kernel is that it has used all of its timeslice. Without the preemptable kernel patch, the task cannot be interrupted to schedule another task. In order to make guarantees about how much time will be given to each process, it needs to be possible to stop a process when its time is up essentially no matter what the process is doing.
The issues you raise are a matter of scheduling policy, not of whether the kernel is preemptible. Furthermore, for most interactive tasks, the correct behavior is to react quickly, because those tasks haven't used up their timeslices, since they blocked waiting for input. In this case, interactive processes give up the CPU to wait for input, and then get their time back as soon as they have a use for it.
Of course, this all also applies to tasks which "interact" with the network or the hard drives, which is any task when you have swap space. Processes which are waiting on input want to run as soon as their input is ready, and don't care about time before that. Processes which are not waiting on input want to run as much as possible, and don't care exactly when. Having the scheduler's instructions followed as closely as possible benefits both kinds.
The email described why something significantly less extreme (Gnome should support .NET software, and new software should be written with .NET) is a good idea. Of course, he talks about this for Gnome 3 or 4, which are a long way off-- by that time .NET will be either totally gone, forked by Mono (as UNIX is forked by Linux), or so totally standardized that nobody can change it.
.NET in particular is somewhat weaker because it was invented by Microsoft, and it is evidentally not sufficiently language-independent to be a suitable target for most languages people would like to use (C++ and python in particular, not to mention Smalltalk, Lisp, or many less common ones).
Personally, I think that the idea of a common VM, both language and platform independent, providing runtime services (e.g., memory allocation/garbage collection) and safety (e.g., bounds checking) is a good idea. I think that
It seems like there is a need for a common VM and runtime system. CLR evidently fails to be a suitable target for many languages. It's certainly possible to create such a thing: actual machine languages are such. The idea would be a VM that is easy to implement on just about any platform, along with common calling conventions for the various kinds of calls supported by different languages.
It seems to me like the gcc CNI design is a good start, although gcc doesn't target a virtual machine.
It seems to me like the right sort of VM would be a stack-based RISC architecture with bounds-checked pointer arithmatic, and probably some sort of GC. Code would be pointer-referenced blocks. The important part would be that it wouldn't have language-specific and CISC opcodes which would deal with objects and classes; at most it would make sense to have essentially installable microcode for a language's dynamic dispatch mechanism and such.
Note that this isn't Myth II itself, but the metaserver, which allows people's copies of the game to find each other and negotiate games.
This doesn't mean they're opening the Myth II engine; it just means that when bungie.net isn't running a Myth II server, people who want to play online can still do so.
Actually, he feels the Changelog is too detailed for posting to linux-kernel. It's generally best to keep announcements relatively brief. Additionally, prepatch Changelogs are since the last real release, which means that -pre10 would be 10 times as big, and contain 90% old information. A much smaller changelog would be preferable for putting in announcements, with the full changelog available on the web for those who are interested.
Also, there's a lot of cruft in the changelog that just isn't relevant: changeset ids and so forth. All the details of how the changes came to be in the kernel aren't that important.
It is likely that there will emerge a single Linux vendor that will provide Linux to the masses. On the other hand, this is unlikely to cut into the community, because the community has never been about that, nor needed that.
Furthermore, there's no way that the big vendor will get the size necessary to actually produce even a significant fraction of the Linux software. And there's no reason they should: if Apple and Adobe can have a relationship such that people generally buy both MacOS and Photoshop if they buy either, there's no reason that a commercial Linux vendor and a bunch of free software projects can't have this relationship, too. The case of Microsoft, where a single company can actually provide all the software, is unlikely to arise in the Linux world, just because the structure of Linux makes it hard to create or maintain a monopoly, and lacking a monopoly, it is impossible to get the money or the army of programmers.
I think there will be a company that makes a lot of money on packaging Linux and selling it to people who don't want to change it very much and want support for it as is.
I think there will be a number of companies selling Linux software, once a significant portion of consumers can be presumed to have Linux; since there's no Microsoft there, there's the opportunity for another company to sell software.
I think the main effect of the free software which will be available will be to limit the space that companies will write software in. If there is really solid free software in place, companies will use it rather than competing with it. The projects I see as this solid are the kernel, the common libraries (libc, ncurses, libjpeg, zlib, openssl, etc), the GNU utilities, XFree86, emacs, and vi. Companies will, for instance, not try to compete with X, but also not contribute much to it, and use it. Sure, they benefit from it, but only as consumers of a free and useful raw material.
I put a couple hundred dollars into VA a while ago. It seems to me that this money went toward improving Linux software. I lost money on it, of course, but I think I got more back in terms of, say, software I could find due to SourceForge and more reliable hardware and software. While investors are normally in it for the possibility of getting more cash back for the stock than they paid for it, some people invested in Linux companies because, even if the money didn't produce more money, it would produce more value.
...unfortunately for them, the judge will still see it all, and that's who matters.
But the product of an patch integrator wouldn't be the "real" Linux anyway, since even people who get their kernels from kernel.org wouldn't normally use it. In order to do so, they'd have to get and apply a patch which is explicitly "the patches that Linus hasn't applied". The people who would actually do so are the people whose feedback Linus would want in decided whether to apply the patches.
And what Linus is, in general, concerned about is not the disasters, which are generally cleaned up as soon as they arise, and before anyone who wasn't warned has anything to do with them. He's concerned about directions kernel development could take. He wants to continue to get patches that add functionality he thinks is good, and he wants to avoid stuff he doesn't like creeping in. If someone else is getting the patches, he might not receive a patch which he would find very interesting but someone else might reject out of hand (not that he'd accept it, but he might put in the effort to help the submitter clean it up if he thought the feature was worth it). And if someone else builds up a lot of patches which the developers have been expecting to go in eventually that he has fundamental disagreements with, he might find it hard to reject them and get versions which do things differently.
On the other hand, I think that both of these effects are due to him not looking at all of the patches he gets, not the existence of an intermediary; they are already happening, due to him being overwhelmed by patches. So long as people still send him all of the patches, just in case one of them catches his fancy, and he continues to maintain the official version, the situation can only improve for him, since he can mostly deal with obvious and unexciting patches through the intermediary, who can verify that they make the compiler happier and don't change the behaviour, or are exclusively in sections he isn't interested in anyway.
You could, of course, avoid writing emails that would not exclude Outlook users, but you would have to be careful not to
begin any lines of your message wrong, which means that having your mailer arrange the line-breaks for you won't work.
Obviously, working around all of the bugs in software which people might use is a pain, and shouldn't be your
responsibility. After all, it is local mail delivery programs that deal with lines that start with "From". It would suck to
end up having to carefully tune your content to broken implementations. And if you've decided not to support broken mailers
why not trigger the bug intentionally, so people don't read part of your conversation before running into a message
they can't read? I think that people using mailers which don't understand the MIME format shouldn't stop you from using
attachments. If a message conforms to all applicable standards, it's fine by me. Attaching a Word document is perfectly
legitimate, although the document itself doesn't conform to any Internet Standards other than "binary data".
What Stephen King couldn't do was different: getting people to pay to read it once without getting anything for it.
Additionally, Stephen King is a well-known hardcopy author. There probably aren't that many people who found out about him by doing a web search for horror novels, found his book, read it online, and considered paying for it.
On the other hand, if 25% of the people who read the book online pay for a copy, and more than 4 times as many people read it because it should up conveniently in a web search on the subject and they can read it without paying for a book by an author they don't know, he comes out ahead anyway.
The money he fails to make on the people who don't buy it when they read it is probably much much less than the money he'd have to spend on advertizing in order to get the same number of people to read it. The cost of promoting a book (unless you're Stephen King, and don't need to promote it) is greater than the rest of the costs of publication combined.
When I worked there back in the late 90s, my group's furniture was old and needed replacing: the lounge's chairs were kind of ratty, the keyboard trays kept falling off of the desks, and there weren't enough desk chairs for the number of desks.
We never did get any new furniture. If we'd wanted high-end workstations to sit on, we could have had those, but furniture was just impossible.
Probably now groups will take up a collection and buy themselves new furniture, since the lab isn't going to say they'dd buy it but not actually do so.
You can be tried for a crime which you have been accused of committing against after you were last tried for it. If you've been found innocent of beating someone up, you can't then go beat the person up, and escape trial because of having been tried for it before. It's a different crime if there are new events involved, and MicroSoft has done things in the past few years.
I built a new box when 2.4.1 was new, installed that, and didn't have any problems with it. When Linus started 2.5, I decided to get the next 2.4 version, so I'm now running 2.4.17. I've had one lockup, with the ALSA driver for 2.4.17. Of course, this is on my desktop box, which I only turn on when I actually go home from work and still want to do computer things.
With 2.4.1, it didn't have any trouble with giving up cleanly on building Mozilla in too little memory. I don't actually have any swap, since I haven't quite recovered from 1.2.13 with a small swap partition on the only hard drive (with swap, it would slow to a crawl for half an hour *before* killing some things and recovering. Without swap, it would just kill things and recover). I haven't tried doing anything extreme on 2.4.17, although I've been meaning to now that I'm using ext3.
I haven't actually seen a PocketPC yet, so this is just based on MS's subway ad.
There was a Palm and a PocketPC, both showing weather reports. The Palm's report fit on the screen, and included the current day. The PocketPC needed a scrollbar (which is always a pain), and seemed to start without the current day on the screen. The weather reports were entirely different. Guess which one I'd trust.
Evidentally, the PocketPC is a device for people whose requirement in a handheld is a diagonal gradient. I suspect, on the other hand, that most people who actually want to use handhelds for anything already have Palms. The remaining market may only be for people who want a pretty device that doesn't work.
If you can copy & paste someone else's code, and it does what your code is supposed to do, then you shouldn't have been asked to write it yourself. Just use your coworker's code.
If you can copy & paste someone else's code, and change it slightly so that it does what you want it to do, then you're a perl programmer. Or rather, then you can work effectively in languages you don't really know, which is a valuable skill when you're doing elementary programming tasks.
Realistically, if someone has only taken the basic classes and not anything more advanced, I wouldn't give them a task more complicated than a simple cut & paste from a script lying around.
Of course, this is one of the situations where the solution you would use in the real world isn't the desired result. In the real world, everyone would be doing different things (and you could copy the code if you wanted, but it would probably be easier not to), but that would be impossible to assign or grade (unless the problems were in some extremely clever way based on the student's name or ID number or something).
I expect that the sound quality is more a function of the sound driver architecture and common code than of the Yamaha-specific driver; the latter just has to know how to configure the card and where to send the data and in what format and such, while the former is responsible for the actual data conversion and getting the data to the card in time to play it.
Of course, I don't really know much about the details, so I'm not sure. But I think the device-specific driver code is more responsible for stability and feature completeness than for quality.
It started out with Rik's VM in the kernel, since it was a promising new development. However, once it was in Linus's kernel, the fact that Rik's development style was not compatible with Linus's source control style because an issue, because the VM wasn't getting updated in Linus's tree.
So Linus switches to the other VM, which is based more on the original. This means that Rik can do his development without dealing with Linus and the Linus tree can have an up-to-date VM. When Rik's is to the point where he's really happy with it and he doesn't think he'll have to make a lot of patches (and it does all the things he wants), it will probably go back in.
Since then, Rik and Linus have figured out (hopefully) how their interaction failed to work, and what Rik has to say along with his patches to make Linus know they're worth looking at. It turns out that it is possible to automate this process, such that a script will send the patches when appropriate, with the right assurances of freshness (having actually tested them, of course).
Linus wants to be able to ignore any patch that isn't for the part he's thinking about at the time (e.g., non-block-i/o patches around the beginning of 2.5). When it becomes interesting again, however, the original patch may not be right any more. Having not looked at the patch at the time when it was sent, Linus can't determine whether it is still good, since the author may have found bugs, and he doesn't know exactly what the patch was supposed to do. He wants the author to make any updates needed and resend it. It may be, of course, that the patch doesn't need to be changed, and the author doesn't have a new and better patch, but Linus can't tell unless the author sends it again with a note that it's still good.
So Rik's patchbot will test whether the patch still applies and still works, and has not been replaced by a new version, and then will send it again until Linus actually looks at it. This seems to me like a good plan, since it doesn't require Linus to test everyone's old patches and have a complicated mail system. And Linus won't accidentally apply the wrong version of a patch or be unable to find a patch.
IIRC, the OSS driver for Yamaha is reportedly at least as stable as the ALSA one. So it's possible that the final merge will involve a chunk of this code as the Yamaha driver (i.e., as the part in drivers/sound). Just because the architecture is going to change doesn't mean that all of the drivers will just go away...
Why don't the Lindows people subpoena MicroSoft's customer list? I'm sure they could find out a lot of potentially useful information from MS customers. Er, useful in the court case, I mean.
Given MS's record with getting the courts to like them, it doesn't sound too implausible that the court would order them to comply (or drop the suit).
It's true that MicroSoft has a good case here, but that doesn't mean they won't mess it up. They seem not to have realized that, while justice is theoretically blind, it can still you giving it the finger.
The real issue is the possibility that your client will use UDP. UDP is normally fine, but it doesn't handle reliable delivery, and people using it who want reliability won't necessarily do so correctly (i.e., by using TCP, not UDP).
UDP is intended for things like realtime audio. If a packet gets dropped, the receiver doesn't want that packet anyway. (I.e., If packet 3 gets dropped, the receiver will play packets 1, 2, nothing, 4, 5). For file transfer, you want every packet, so that you get the whole thing eventually. If you use UDP (and, in particular, if everyone uses UDP), you'll get a lot of resends in a non-optimal pattern.
So the problem isn't in sending files as packets, it's in sending the packets in an inefficient way. Essentially, they're worried that it will be done like NFS instead of like FTP.