As I said, hardware that you compile code for doesn't make sense as a stack machine. A stack machine is like a register machine with an unbounded number of semi-inconveniently named registers. This only makes sense if you don't want to specify how many registers you have. But you know how many registers a given chip will have, so you might as well say.
Actually, register windowing is somewhat like a stack machine; you have one stack/register, and you push or pop the whole window at once around function calls. Again, you want to hide the depth at which you spill into memory and pretend that the depth is infinite, so you use stack-machine-like semantics.
So there are hardware stack machines (sort of) pretending to be register machines and hardware register machines implementing stack machines, and even hardware stack machines pretending to be register machines running software emulation of stack machines.
On the code morphing front, Crusoe really ought to run java byte code as if it were native.
You'd need it to be a browser feature, rather than a feature implemented by the browser while running javascript in the page. Obviously, this involves a lot of changes, but this is theoretical research anyway.
There's presumably a mediating variable: if you're spamming more people, it's probably because you're selling something people are less likely to want and you're probably using even more slimy tactics, and you chase off anyone who actually might buy your product.
In order words, if you send to only a small number of people, you're likely to have a product that people actually buy. Spam that goes to everybody is for products that nobody wants, and nobody buys them.
People won't trust sites to actually randomize the data. Actually, people probably won't notice that the site is promising to, or take this as a reason to give good results. What they should do is set up a system where the randomization is done by the browser (which people trust), in accordance with a distribution specified by the site and provided to the user.
That way, the browser tells you that your entry will be randomized to tell the site your age +-30 years, or give your actual gender 20% more frequently. Based on the numbers the site is using, you can decide whether to answer accurately, knowing just how hard it would be to track you based on this information. The web site would then be able to remove the noise from the aggregate data, and have a confidence based on the distribution they ask for (aside from people who think the margin is too small and lie).
Stack machines... you mean, like the Java Virtual Machine? Or PostScript printers? Nope, nobody using that idea any more. Actually, a number of the neat old ideas in computers turn out to be great for something somewhat different, or somewhat later. Stack machines are a great idea if you don't know how many registers you have. With real machines running compiled software, this is stupid; but for virtual machine or for document-formatting instructions, it's great.
In any case, it's not neat ideas that sell machines, it's solved problems. Code morphing is a great idea, and it'll be really big as soon as someone wants to do something that it's good for.
Having just heard from the Fair Use people, the government has decided to share their favorite comic book with millions of their closest friends.
Cool, my computer is surrounded by a glowing green light! That'll keep those cyberterrorists out!
Anyway, back on topic, this software is part of a program to protect critical non-government services. They're definitely not going to introduce any new vulnerabilities with it. The NSA's mission includes both development of spy technology for the gov't to use and development of counter-intelligence and security technology to protect the US. Spying on most Windows users is so easy that the gov't actually wants to make it harder, so their special technology is actually necessary.
The problem isn't resolution; the problem is that digital artifacts, if not dealt with, are much more noticeable than analog artifacts. That is, jaggies are noticeable at a much higher resolution than blurriness, because our eyes target high-frequency noise and straight lines (which don't occur by chance much in nature).
Film, being a chemical process, tends to lose high-frequency noise and sharp corners, which means that the jaggies wouldn't survive the transition to analog for distribution to analog theaters.
I suspect that they just didn't properly anti-alias the digital version for raw output. The logo, after all, would have been trivial to anti-alias so that it looks nice (anti-aliasing line graphics is about the simplest thing). Of course, it it were anti-aliased, the analog version (which is what almost everyone saw) might have been marginally more blurry.
Of course, the real solution is to have the digital projectors project gaussian dots instead of sharp squares (until digital is common enough to care) unless the movie is actually filmed for square pixels.
Regular expressions aren't theoretically interesting anymore. Regexps, in the sense of a way of specifying regular (and some non-regular) expressions, shows significant change over time. In much the same way, English isn't theoretically different from Indo-European, but you won't get very far using only Indo-European these days.
Rather than having the merge program part of the version control project, it ought to be at least partially separate. You often want to make a few changes to a project from somewhere you don't have a working directory, in which case, you'll want to be able to resolve conflicts in TTY mode if need be.
Furthermore, if your merge tool is separate, it may become independantly popular, and may be used with other version control systems. Of course, there may be issues with creating a general interface for the metadata that different systems provide.
Using fvwm2, I can grab a window and wave it around on top of other windows (including on top of a konqueror window), and it leaves at most a small trail (dragging it slowly across a complex window). The window on top is not redrawn at all unless I carefully get it behind another window and drag it without raising it. When I resize a window, I just get the frame until I actually select a size. I suspect that more recent window managers are not working to minimize the redraw efforts. The X window manager model is fine-- it's just that window managers frequently don't do a good job. (Applications these days also seem in too much of a hurry to get something on the screen; there's no reason you should see holes).
You can leave off doing word wrap until you're done with the document, and then do a single (hard) word wrap pass. If you get in the habit of separating paragraphs with (at least) a blank line, emacs will redo your word-wrap for a paragraph if you type Esc-q, removing leftover newlines.
Stray processes seem to be a desktop integration thing. As far as I can tell, the desktops start up a ton of stuff for sharing information between applications, which then doesn't get cleaned up.
XFree86 will change resolutions between the ones defined for your setup if you hold ctrl and alt and press + or - on the keypad. Of course, that's virtual resolutions; if you've reduced it, you can move the area you can see with the mouse. I find this very handy for looking at details, reading small print with tired eyes, and letting a roomful of people read things on my screen. I'm not sure what other use there is for lower resolution, but this feature may not serve your purposes (what do you expect to happen to windows which are entirely off the screen in the new resolution?).
I agree that fsck should have an option to say that nobody who uses this machine will have a better idea of what to do about the filesystem that the fsck maintainer, so fsck should use its best judgement. But the only time I've seen a large number of errors, it was due to the memory in the machine being flaky.
NFS isn't really that great a file sharing mechanism: it's insecure and fragile outside a trusted network and doesn't work very well where the client machines are controlled by their users. It is mostly useful for a server distributing files to clients, rather than users sharing files with each other and with themselves across client machines. A better solution is ssh-agent and scp/ssh; hopefully someday there will be an ftp-like or even filesystem interface to this mechanism.
Good thing you can still with your current installation for the rest of your life without being forced to migrate to some other one, then. If Linux is perfect for you, that saves you a lot of time following projects and installing software, doesn't it? (I know I find it disturbing just how much time everyone seems to spend installing and learning to use programs that replace programs they liked)
Unstable series often start off with versions which break everything, because whatever fundamental change is first up for the series has gone in and the drivers and so on haven't been updated. It was a long time in 2.5 before it was really sensible for people to work on it (aside from the bio work), and people were actually doing their development on 2.4 even after 2.5 had started. In part, this wasn't even an issue of stability: Linus just wasn't taking patches on other subsystems. If 2.7 starts when 2.6 comes out, and major changes go into 2.7.1, people will stay on 2.6 until the first major set of changes in 2.7 has stabilized. Provided that the first thing under development in 2.7 isn't broken in 2.6 (in which case, the people who could fix it would be working on 2.7), everyone important to fixing obscure bugs in 2.6 will still be working on 2.6, but sitting on their patches, because they can't go into 2.6 (not fixes). As the interfaces for 2.7 (where they differ from 2.6) become known, people will start using them, but, until that point, 2.6 and 2.7 are basically the same, except that you can get 2.6 running to develop on.
This information shouldn't be considered secret; after all it's not terribly hard to find out what AT&T will ask if you call up pretending to be an employee or customer: just call up, pretending to be an employee or customer and see what they ask you. If they've designed their procedures sensibly, you still shouldn't be able to spoof them.
Of course, the really great hack would be to call up Kevin Mitnick pretending to be an officer of the court, and get the information from him.
People seem to have agreed that, just because there's a patent, everyone shouldn't do things differently. At issue here is who should determine such a standard, and who should promote it.
It seems to me that the extent of the W3C's involvement should be to determine the people to pass the standard of to, whether it be an interested subset of the members of the committee that found the patent, an entirely different group of people, or a different standards body. Presumably the people interested in implementing the patented technology would be represented, so the standard would not need to be recommended by a standards body, as it had been developed by the people who would then use it.
So long as it's possible to have a patent that interferes with a standard (such that the standard cannot simply be fixed to avoid the patented part), the W3C has to have some clear idea of what to do when a committee finds themselves stuck.
The lesson to take away from that is that small talk is not that complicated, at least on the surface. It would be much harder, for example, to make an AI that could read a newspaper article and discuss it with someone. Or to have a conversation that was actually interesting as well as convincing. Or even to pay attention to the subtext in the small talk it was having.
Any sufficiently limited task in AI is relatively easy, although it may lead to interesting applications (expert systems, etc). The fact that the competition doesn't make as good small talk doesn't really say anything about the relative merits of the programs. In fact, it is likely that ALICE should be complementary to another AI program, which could try to form opinions of the person which ALICE takes care of the social niceties.
I think the losses (and I think they are starting to do actually worse these days, maybe even worse by more than other people) come in part from sharing. But much more, I think they come from an increasing perception that paying for recorded music doesn't benefit anyone deserving (unless you can somehow get in touch with the artists personally). Better to copy the music, get it used, listen to stuff you already have, etc, and then reward the bands you like by going to their concerts.
People like bands. That's all that's ever made money for the RIAA. Increasingly, high-profile bands have been saying that the RIAA does nothing good for them. Nobody wants to pay a third party to screw over everyone involved.
Furthermore, it's been easy for a long time to avoid paying the RIAA; early 90s consumer equipment will give you good, fast copies of tapes (and tape copies of CDs). People bought copies of things their friends had because they thought it was the right thing to do. Now the perception is that it is better not to buy music when possible. So long as people have this attitude, the RIAA is in serious trouble.
But copyright infringement suits aren't cases of stealing, under the law. That wouldn't make sense, because then the goal of the plaintiffs would be to get their property back. It's hardly a theft case if the prosecution presents, as evidence, the fact that the defendants offered to give back the goods for free.
In these cases, they don't want their property back, they want money. How much money? An illegally large amount. Of course, the amount of money as sort of a vague "damages" thing, anyway, which makes it extra difficult to figure out: they say they lost $X, but they were setting prices illegally, so they deserved to lose some amount which may be less or may be more than $X.
It's not terribly significant by itself, but it's great ammunition for the next time they sue anyone for copyright infringement, though...
"Your honor, the group of companies suing us has been convicted of conspiracy. That court put on them a cease and desist order which they are violating by bringing this suit. We're filing a countersuit, and move to dismiss their suit."
Saying that your opponents are preventing you from illegal price fixing is a little tricky.
Of course, these days the MPAA is much more of a problem than the RIAA, which seems to have largely killed their market.
There's a lot of places where the four of them do the same thing in different ways. One of the ideas was to have the common journalling code be shared between the different filesystems, and to have the various changes that need to be made to the general filesystem and disk code to support the operations needed for journalling be done in one way, rather than with different modifications for the different filesystems.
Obviously, they're not all going to be exactly the same: they have different on-disk formats and different consistency constraints. But there's a lot of stuff which should work with any journalling filesystem with the same code that ought to be straightened out between the different filesystems.
Considering the number of things that are supposed to go in, including things that aren't really even started (beyond looking a bit at the issues) and things that are likely to be disruptive that haven't started to be merged, Halloween seems rather unrealistic. Of course, pushing off things that haven't been acceptably merged by then until 2.7 would probably make for the reduced-feature 2.6 that nobody wanted to commit to explicitly.
Personally, I like the idea of a 2.6 as soon as the big things which are partially merged are finished, with everything else put off until 2.7 and everyone who got their stuff into 2.6 responsible for making sure it's stable under wide testing. There are a number of big improvements already in 2.5, and cutting over to a stable release with those features would be nice. And maybe Marcello could be swindled into maintaining it because it's not _that_ different from 2.4...
If Moby has just now moved into the mainstream, why does he think that his lack of CD sales are due to a techie following? If that effect were the case, you'd expect that the earlier CDs would have sold surprisingly badly, and the new one would have sold much better with all the mainstream airplay. Now, if the new album sold a ton of copies and he were trying to explain that he's always been that popular, it would make sense.
It seems much more likely that his CD sales are being hurt by his fans not wanting to give any money to the RIAA (and maybe that his style had drifted away from what his fans like).
...tell your computer to move a folder inside another, and just by pointing with your finger, it would happen... a natural language, multilingual conversation system that can understand and respond to normal speech... a self-configuring, decentralized wireless network... He points to electricity as a resource that works this way, in that it's ubiquitous, but also unobtrusive.
I don't know about him, but I generally interact with electricity by putting little plugs in little sockets. The interface makes it quite difficult to accidentally do something different from what I wanted, and there's nothing left up to interpretation. Things always work exactly the same way, unless something's gone terribly wrong.
With a good interface, you can tell a new user how it works, and the user will be able to predict everything that will happen when they do anything with it, and will be able to do the things they want to do reliably without ever doing something unintended.
How often do you hand a $20 to a cashier and get change for a $5 or a $10 until you complain? I know it's happened to me pretty often (especially right after they changed the $5 and $10 to look like the $20). It would be nice if the different denominations all looked entirely different (although stylistically similar, so that they look like US money).
US money should have different arrangements
on
Greenbacks No More
·
· Score: 2
If you look at the traditional US currency from a distance (both sides), you'll find that it all looks exactly the same, except for the $2, which has a big picture on the back. Of course, few people regularly use the $2. It was really nice when the new $20 came out, because it looked really different from the other bills, while still looking somewhat like US money. Then they came out with $10 and $5 bills that looked like $20 bills (since I'd gotten used to $20 bills looking the new way).
Rather than using different colors, they should use different designs: leave the $1 the way it's always been, the $20 the new way, make the $5 and $10 different in other ways, make the front of the $2 like the back (wide, rounded image). Make $100+ bills different colors.
Of course, they could make the bills all different colors, but leave the $1 the same way we're used to. I think the identifying feature of US currency is the fact that there are all the busy sections of little lines, more than the color.
Software, as written, is just going to have a number of bugs proportional to the amount of code. The number of security holes is proportional to the number of bugs, with some constant depending on language and programming style.
Then there's testing and debugging. It seems to me that essentially nobody just goes through open source code for fun, trying to find bugs; people who look at the code generally join the projects. So, in either case, the team writing the software is also mostly the team that tests it. So you'd expect about the same results.
The security advantage to open source is that, if you really care about security, you can examine the source yourself and determine how good it is, to the best of your abilities. With closed-source, you have to trust whoever wrote and tested the software, since you can't do it yourself.
Of course, almost nobody cares that much. Of course, you can probably bet that if the NSA doesn't change something in the version intended for government agency use, it's right. (Even if the NSA were putting in holes only they know about, they wouldn't leave any pre-existing holes)
Slashdot Mirror
As I said, hardware that you compile code for doesn't make sense as a stack machine. A stack machine is like a register machine with an unbounded number of semi-inconveniently named registers. This only makes sense if you don't want to specify how many registers you have. But you know how many registers a given chip will have, so you might as well say.
Actually, register windowing is somewhat like a stack machine; you have one stack/register, and you push or pop the whole window at once around function calls. Again, you want to hide the depth at which you spill into memory and pretend that the depth is infinite, so you use stack-machine-like semantics.
So there are hardware stack machines (sort of) pretending to be register machines and hardware register machines implementing stack machines, and even hardware stack machines pretending to be register machines running software emulation of stack machines.
On the code morphing front, Crusoe really ought to run java byte code as if it were native.
You'd need it to be a browser feature, rather than a feature implemented by the browser while running javascript in the page. Obviously, this involves a lot of changes, but this is theoretical research anyway.
There's presumably a mediating variable: if you're spamming more people, it's probably because you're selling something people are less likely to want and you're probably using even more slimy tactics, and you chase off anyone who actually might buy your product.
In order words, if you send to only a small number of people, you're likely to have a product that people actually buy. Spam that goes to everybody is for products that nobody wants, and nobody buys them.
People won't trust sites to actually randomize the data. Actually, people probably won't notice that the site is promising to, or take this as a reason to give good results. What they should do is set up a system where the randomization is done by the browser (which people trust), in accordance with a distribution specified by the site and provided to the user.
That way, the browser tells you that your entry will be randomized to tell the site your age +-30 years, or give your actual gender 20% more frequently. Based on the numbers the site is using, you can decide whether to answer accurately, knowing just how hard it would be to track you based on this information. The web site would then be able to remove the noise from the aggregate data, and have a confidence based on the distribution they ask for (aside from people who think the margin is too small and lie).
Stack machines... you mean, like the Java Virtual Machine? Or PostScript printers? Nope, nobody using that idea any more. Actually, a number of the neat old ideas in computers turn out to be great for something somewhat different, or somewhat later. Stack machines are a great idea if you don't know how many registers you have. With real machines running compiled software, this is stupid; but for virtual machine or for document-formatting instructions, it's great.
In any case, it's not neat ideas that sell machines, it's solved problems. Code morphing is a great idea, and it'll be really big as soon as someone wants to do something that it's good for.
Having just heard from the Fair Use people, the government has decided to share their favorite comic book with millions of their closest friends.
Cool, my computer is surrounded by a glowing green light! That'll keep those cyberterrorists out!
Anyway, back on topic, this software is part of a program to protect critical non-government services. They're definitely not going to introduce any new vulnerabilities with it. The NSA's mission includes both development of spy technology for the gov't to use and development of counter-intelligence and security technology to protect the US. Spying on most Windows users is so easy that the gov't actually wants to make it harder, so their special technology is actually necessary.
The problem isn't resolution; the problem is that digital artifacts, if not dealt with, are much more noticeable than analog artifacts. That is, jaggies are noticeable at a much higher resolution than blurriness, because our eyes target high-frequency noise and straight lines (which don't occur by chance much in nature).
Film, being a chemical process, tends to lose high-frequency noise and sharp corners, which means that the jaggies wouldn't survive the transition to analog for distribution to analog theaters.
I suspect that they just didn't properly anti-alias the digital version for raw output. The logo, after all, would have been trivial to anti-alias so that it looks nice (anti-aliasing line graphics is about the simplest thing). Of course, it it were anti-aliased, the analog version (which is what almost everyone saw) might have been marginally more blurry.
Of course, the real solution is to have the digital projectors project gaussian dots instead of sharp squares (until digital is common enough to care) unless the movie is actually filmed for square pixels.
Regular expressions aren't theoretically interesting anymore. Regexps, in the sense of a way of specifying regular (and some non-regular) expressions, shows significant change over time. In much the same way, English isn't theoretically different from Indo-European, but you won't get very far using only Indo-European these days.
Rather than having the merge program part of the version control project, it ought to be at least partially separate. You often want to make a few changes to a project from somewhere you don't have a working directory, in which case, you'll want to be able to resolve conflicts in TTY mode if need be.
Furthermore, if your merge tool is separate, it may become independantly popular, and may be used with other version control systems. Of course, there may be issues with creating a general interface for the metadata that different systems provide.
Using fvwm2, I can grab a window and wave it around on top of other windows (including on top of a konqueror window), and it leaves at most a small trail (dragging it slowly across a complex window). The window on top is not redrawn at all unless I carefully get it behind another window and drag it without raising it. When I resize a window, I just get the frame until I actually select a size. I suspect that more recent window managers are not working to minimize the redraw efforts. The X window manager model is fine-- it's just that window managers frequently don't do a good job. (Applications these days also seem in too much of a hurry to get something on the screen; there's no reason you should see holes).
You can leave off doing word wrap until you're done with the document, and then do a single (hard) word wrap pass. If you get in the habit of separating paragraphs with (at least) a blank line, emacs will redo your word-wrap for a paragraph if you type Esc-q, removing leftover newlines.
Stray processes seem to be a desktop integration thing. As far as I can tell, the desktops start up a ton of stuff for sharing information between applications, which then doesn't get cleaned up.
XFree86 will change resolutions between the ones defined for your setup if you hold ctrl and alt and press + or - on the keypad. Of course, that's virtual resolutions; if you've reduced it, you can move the area you can see with the mouse. I find this very handy for looking at details, reading small print with tired eyes, and letting a roomful of people read things on my screen. I'm not sure what other use there is for lower resolution, but this feature may not serve your purposes (what do you expect to happen to windows which are entirely off the screen in the new resolution?).
I agree that fsck should have an option to say that nobody who uses this machine will have a better idea of what to do about the filesystem that the fsck maintainer, so fsck should use its best judgement. But the only time I've seen a large number of errors, it was due to the memory in the machine being flaky.
NFS isn't really that great a file sharing mechanism: it's insecure and fragile outside a trusted network and doesn't work very well where the client machines are controlled by their users. It is mostly useful for a server distributing files to clients, rather than users sharing files with each other and with themselves across client machines. A better solution is ssh-agent and scp/ssh; hopefully someday there will be an ftp-like or even filesystem interface to this mechanism.
Good thing you can still with your current installation for the rest of your life without being forced to migrate to some other one, then. If Linux is perfect for you, that saves you a lot of time following projects and installing software, doesn't it? (I know I find it disturbing just how much time everyone seems to spend installing and learning to use programs that replace programs they liked)
Unstable series often start off with versions which break everything, because whatever fundamental change is first up for the series has gone in and the drivers and so on haven't been updated. It was a long time in 2.5 before it was really sensible for people to work on it (aside from the bio work), and people were actually doing their development on 2.4 even after 2.5 had started. In part, this wasn't even an issue of stability: Linus just wasn't taking patches on other subsystems. If 2.7 starts when 2.6 comes out, and major changes go into 2.7.1, people will stay on 2.6 until the first major set of changes in 2.7 has stabilized. Provided that the first thing under development in 2.7 isn't broken in 2.6 (in which case, the people who could fix it would be working on 2.7), everyone important to fixing obscure bugs in 2.6 will still be working on 2.6, but sitting on their patches, because they can't go into 2.6 (not fixes). As the interfaces for 2.7 (where they differ from 2.6) become known, people will start using them, but, until that point, 2.6 and 2.7 are basically the same, except that you can get 2.6 running to develop on.
This information shouldn't be considered secret; after all it's not terribly hard to find out what AT&T will ask if you call up pretending to be an employee or customer: just call up, pretending to be an employee or customer and see what they ask you. If they've designed their procedures sensibly, you still shouldn't be able to spoof them.
Of course, the really great hack would be to call up Kevin Mitnick pretending to be an officer of the court, and get the information from him.
People seem to have agreed that, just because there's a patent, everyone shouldn't do things differently. At issue here is who should determine such a standard, and who should promote it.
It seems to me that the extent of the W3C's involvement should be to determine the people to pass the standard of to, whether it be an interested subset of the members of the committee that found the patent, an entirely different group of people, or a different standards body. Presumably the people interested in implementing the patented technology would be represented, so the standard would not need to be recommended by a standards body, as it had been developed by the people who would then use it.
So long as it's possible to have a patent that interferes with a standard (such that the standard cannot simply be fixed to avoid the patented part), the W3C has to have some clear idea of what to do when a committee finds themselves stuck.
The lesson to take away from that is that small talk is not that complicated, at least on the surface. It would be much harder, for example, to make an AI that could read a newspaper article and discuss it with someone. Or to have a conversation that was actually interesting as well as convincing. Or even to pay attention to the subtext in the small talk it was having.
Any sufficiently limited task in AI is relatively easy, although it may lead to interesting applications (expert systems, etc). The fact that the competition doesn't make as good small talk doesn't really say anything about the relative merits of the programs. In fact, it is likely that ALICE should be complementary to another AI program, which could try to form opinions of the person which ALICE takes care of the social niceties.
I think the losses (and I think they are starting to do actually worse these days, maybe even worse by more than other people) come in part from sharing. But much more, I think they come from an increasing perception that paying for recorded music doesn't benefit anyone deserving (unless you can somehow get in touch with the artists personally). Better to copy the music, get it used, listen to stuff you already have, etc, and then reward the bands you like by going to their concerts.
People like bands. That's all that's ever made money for the RIAA. Increasingly, high-profile bands have been saying that the RIAA does nothing good for them. Nobody wants to pay a third party to screw over everyone involved.
Furthermore, it's been easy for a long time to avoid paying the RIAA; early 90s consumer equipment will give you good, fast copies of tapes (and tape copies of CDs). People bought copies of things their friends had because they thought it was the right thing to do. Now the perception is that it is better not to buy music when possible. So long as people have this attitude, the RIAA is in serious trouble.
But copyright infringement suits aren't cases of stealing, under the law. That wouldn't make sense, because then the goal of the plaintiffs would be to get their property back. It's hardly a theft case if the prosecution presents, as evidence, the fact that the defendants offered to give back the goods for free.
In these cases, they don't want their property back, they want money. How much money? An illegally large amount. Of course, the amount of money as sort of a vague "damages" thing, anyway, which makes it extra difficult to figure out: they say they lost $X, but they were setting prices illegally, so they deserved to lose some amount which may be less or may be more than $X.
It's not terribly significant by itself, but it's great ammunition for the next time they sue anyone for copyright infringement, though...
"Your honor, the group of companies suing us has been convicted of conspiracy. That court put on them a cease and desist order which they are violating by bringing this suit. We're filing a countersuit, and move to dismiss their suit."
Saying that your opponents are preventing you from illegal price fixing is a little tricky.
Of course, these days the MPAA is much more of a problem than the RIAA, which seems to have largely killed their market.
There's a lot of places where the four of them do the same thing in different ways. One of the ideas was to have the common journalling code be shared between the different filesystems, and to have the various changes that need to be made to the general filesystem and disk code to support the operations needed for journalling be done in one way, rather than with different modifications for the different filesystems.
Obviously, they're not all going to be exactly the same: they have different on-disk formats and different consistency constraints. But there's a lot of stuff which should work with any journalling filesystem with the same code that ought to be straightened out between the different filesystems.
Considering the number of things that are supposed to go in, including things that aren't really even started (beyond looking a bit at the issues) and things that are likely to be disruptive that haven't started to be merged, Halloween seems rather unrealistic. Of course, pushing off things that haven't been acceptably merged by then until 2.7 would probably make for the reduced-feature 2.6 that nobody wanted to commit to explicitly.
Personally, I like the idea of a 2.6 as soon as the big things which are partially merged are finished, with everything else put off until 2.7 and everyone who got their stuff into 2.6 responsible for making sure it's stable under wide testing. There are a number of big improvements already in 2.5, and cutting over to a stable release with those features would be nice. And maybe Marcello could be swindled into maintaining it because it's not _that_ different from 2.4...
If Moby has just now moved into the mainstream, why does he think that his lack of CD sales are due to a techie following? If that effect were the case, you'd expect that the earlier CDs would have sold surprisingly badly, and the new one would have sold much better with all the mainstream airplay. Now, if the new album sold a ton of copies and he were trying to explain that he's always been that popular, it would make sense.
It seems much more likely that his CD sales are being hurt by his fans not wanting to give any money to the RIAA (and maybe that his style had drifted away from what his fans like).
...tell your computer to move a folder inside another, and just by pointing with your finger, it would happen... a natural language, multilingual conversation system that can understand and respond to normal speech... a self-configuring, decentralized wireless network... He points to electricity as a resource that works this way, in that it's ubiquitous, but also unobtrusive.
I don't know about him, but I generally interact with electricity by putting little plugs in little sockets. The interface makes it quite difficult to accidentally do something different from what I wanted, and there's nothing left up to interpretation. Things always work exactly the same way, unless something's gone terribly wrong.
With a good interface, you can tell a new user how it works, and the user will be able to predict everything that will happen when they do anything with it, and will be able to do the things they want to do reliably without ever doing something unintended.
How often do you hand a $20 to a cashier and get change for a $5 or a $10 until you complain? I know it's happened to me pretty often (especially right after they changed the $5 and $10 to look like the $20). It would be nice if the different denominations all looked entirely different (although stylistically similar, so that they look like US money).
If you look at the traditional US currency from a distance (both sides), you'll find that it all looks exactly the same, except for the $2, which has a big picture on the back. Of course, few people regularly use the $2. It was really nice when the new $20 came out, because it looked really different from the other bills, while still looking somewhat like US money. Then they came out with $10 and $5 bills that looked like $20 bills (since I'd gotten used to $20 bills looking the new way).
Rather than using different colors, they should use different designs: leave the $1 the way it's always been, the $20 the new way, make the $5 and $10 different in other ways, make the front of the $2 like the back (wide, rounded image). Make $100+ bills different colors.
Of course, they could make the bills all different colors, but leave the $1 the same way we're used to. I think the identifying feature of US currency is the fact that there are all the busy sections of little lines, more than the color.
Software, as written, is just going to have a number of bugs proportional to the amount of code. The number of security holes is proportional to the number of bugs, with some constant depending on language and programming style.
Then there's testing and debugging. It seems to me that essentially nobody just goes through open source code for fun, trying to find bugs; people who look at the code generally join the projects. So, in either case, the team writing the software is also mostly the team that tests it. So you'd expect about the same results.
The security advantage to open source is that, if you really care about security, you can examine the source yourself and determine how good it is, to the best of your abilities. With closed-source, you have to trust whoever wrote and tested the software, since you can't do it yourself.
Of course, almost nobody cares that much. Of course, you can probably bet that if the NSA doesn't change something in the version intended for government agency use, it's right. (Even if the NSA were putting in holes only they know about, they wouldn't leave any pre-existing holes)