They probably don't expect this to catch on. But offering something online that nobody downloads is no big deal. It's not like they don't have the couple GB of disk to have this around.
They want to get this in place before its time, because people will get used to whatever method is best when downloading movies becomes feasible. So they set it up and get people to use it as they get the necessary bandwidth. It's too soon to make money on it, but at least it's not too late to establish market share, and it will be really important to catch the early adopters, because they're who people will ask where to get movies when the masses can download them.
In developing nations there aren't going to be the same sorts of major rollouts you see in the US. Hardware doesn't come in as a big purchase; it trickles in piece by piece, depending on what's available and affordable, so you'll just have many instances of "We got another computer, and we put Linux on it."
Linux isn't actually that hard to tune for the low-end, because the core system (kernel, libraries, and such) are actually generally more efficient than they were 8 years ago, not less. Since they ran fine then, they'll run fine now. There are a lot of programs which are just too big and complicated for old hardware, but the old programs run better than they ever did.
Internationalization isn't actually as big an issue as you might think, because people tend to understand a bit of English, and it's mostly jargon anyway (knowing the English words "shell", "prompt", or "window" won't help you understand the computer terms, and having these terms translated into your native language doesn't help either). The issue is really documentation, but if you have an active local user's group, that's better than most of the documentation in any language (for most software, really).
In particular, a new configuration system has to be able to run on rules that the old configuration system can run on, so that both can be in the kernel until people are satisfied with the new one (ironic that Linus rejected CML2 for largely this reason, but then didn't follow this principal with IDE, where it would have been much easier). In order to replace something that everyone has to use, you have to replace it with something that just works for everybody, including the people writing rules, people who want to keep their old configs, people who want to maintain code for both the new kernels and old kernels, and so forth. The whole "Aunt Tillie" thing really is an issue, because important kernel developers don't want to spend more thought on configuring the kernel they're building than Aunt Tillie would, and they already have routine ways of doing that.
"Technical superiority" is a subjective thing, and "does it configure the kernel" is not the only factor. At least as important is "is switching to it easier than continuing to use the existing tools".
Incidentally, the problem with the old build system was not that it was too slow to build but that, if you changes a few things and rebuilt, either you did a complete rebuild, which was too slow, or you just rebuilt the module you were working on, which didn't necessarily catch all of the changes. The new versions are moving toward giving you the ability to rebuild only those things which actually need to be rebuilt without making you know what things these are. People frequently report problems where they've forgotten to do the right thing after they've changed something.
Making the current kernel's configuration available isn't actually difficult at all; it's just that userspace generally has the information anyway (most people copy the config file somewhere parallel to the kernel image). The hard thing is configuring a new kernel version to match the effects of the config file for an old kernel version: sometimes the options change, sometimes there are new options required for old things, etc.
It is (now) kind of ironic, because the static page you get instead of the dynamic page actually does contain the interview. Anyway, if hosed sites give any response, they're more likely to give 500, since they recognize the URL but can't manage to serve the page.
In any case, something which is unintentionally fitting is at least somewhat ironic, unlike the things in the Alanis song, which just suck.
What would have been really ironic would be if the correct id had been, say 304, not 404. And then it would have been even more ironic if there was then a duplicate article...
Then a bunch of people set up stands next to the Tux grove, with "all-you-can-drink" deals for a reasonable price. Of course, they manage it because they don't have to buy lemons, sugar, or water. Plus, the Tux-based stands just make a huge batch every day, because it's no harder to make a lot than it is to make a little if you don't have to pay for the supplies.
Actually, I'd like to see ads with a cleancut Windows drone with a little Tux pin talking about how great Windows is these days, and then he turns and walks away, revealing that he has a "Running Linux and doesn't know it" sign on his back.
I noticed that, in a (vaguely) recent Law & Order episode, the person looking up records at an ebank has a little Tux by his monitor. Nobody mentions it, but it's kind of neat product placement, except that it could be for any of a number of companies, which makes it seem like the people arranging the set just stuck it in.
They're clearly trying to determine whether Open Source could be a more complicated and expensive option. They have to decide whether to start suggesting that companies hire open source hackers to write whatever the companies want. If you look at the demographic survey, they are clearly figuring out that open source hackers are frequently not employed, but could demand a lot of money if someone were going to hire them, and they have the experience to write really complex stuff.
A little less tongue-in-cheek: BCG could probably do well coming in, looking at what your problems are, and telling you which open source hackers you should pay to fix them. Then they can charge a percentage on the whole thing.
There's only a limited amount of money you can spend buying MicroSoft products. It's huge, but you can spend even more on open source if you pay the salaries of the hackers. I mean, they are projects with hundreds or even thousands of contributors. If you give them each $100k...
And MSIL has exactly the features that C# uses, and lacks the features needed for complete implementations of other languages. Whether the issue is the CLR or the bytecode it uses is splitting hairs.
That's not entirely true; the ideal way to do nanotechnology might be to probabilistically arrange groups of atoms into a limited set of arrangements and filter out the undesired ones.
For some applications, you probably actually do want to build your structures exactly and atom-by-atom. But other applications are best suited to a set of catalysts that will construct a random variant of the structure, so long as it has the property you want, or which will only sometimes construct the right thing, but everything else will be destroyed by another catalyst. For that matter, the most successful method has been to put together reasonably large molecules which are built separately.
For that matter, depending on what you're making, you may be perfectly happy with a couple of the desired molecules and a lot of innocuous failures. The failures then are basically packing material (you're not going to deliver someone a single molecule; you're going to deliver a manageable volume of uninteresting solution with an interesting molecule in it).
Having certain events only happen once in a few days is probably good, actually; it's just that the player shouldn't be waiting for just this one thing. There are games where certain things turn up only once in years of play, and people get really excited when they turn up. The rest of the time, they look for other things.
For that matter, if you have a ~once/week occurrence where the player had better be paying attention and has to do something situation-appropriate that isn't the usual thing (like run away as fast as possible), you'll develop a nice paranoia in your players even though it doesn't happen that often. Plus you'll make people not leave the game on autopilot because they'll not want to be gone when something important happens.
Incidentally, that stuff is a whole lot of fun to juggle. It's not difficult once you've got it going, but getting started is very difficult because two blobs in the same hand merge and a blob you're not paying attention to thins out and gets difficult to throw.
For real fun, juggle two blobs of this stuff and one of those plastic toroidal tubes of water, and remember which ones to squeeze each time...
As a former mega-star, it's to his advantage to be independant. But he's selling to the number of people he is now because he got an established fan base as a mega-star. The thing is that you make a lot more money as a signed musician nobody's heard of than as an unsigned one nobody's heard of. And becoming well-known is also a lot easier if you're signed.
So I wonder if Prince would like to get played on internet radio along with other independants, famous and unknown. For that matter, I wonder if he'd like to run an internet radio station and pick the unknowns he thinks should skip the major label phase.
Is the original libvorbis faster (due to making productive use of the FPU), or is the new integer math one faster (because floating point is pretty slow in general)? I'd guess that libvorbis is better on Intel and tremor is better on non-Intel x86 (due to the relative strengths of different vendors), but it's hard to say. Has anyone actually benchmarked them? libvorbis is a noticeable load on one of the machiens I use, so it would be worth switching if it would help.
They're contractors. They wrote this on contract for someone, and the contract allowed them to give it away after a while (IIRC). They weren't selling this in the first place. They wrote the floating-point vorbis, and then they were contacted by a company who wanted a fixed-point version and were willing to pay them to write it. Now they're giving away the fixed-point version in addition to the floating-point version, and probably working on other stuff for other people, with a similar deal.
It's like working for a software company. Once you've written something for them, you give it away (to the company); you continue to make money by getting paid to write more software, not being paid royalties or paid for licenses for the stuff you wrote previously.
You came up with a good way for the RIAA to get a reasonable benefit from online music and get what they are actually due when music is freely available. The RIAA hasn't gone for it, which is hardly surprising, considering that the RIAA are, so far as I can tell, the only people who don't like you.
So what can be done without the RIAA getting involved? Perhaps the RIAA would buy in if someone had gotten something working which was making money and didn't use RIAA-owned materials. I bet it would be possible to put together the music needed to have a site from people who just play for fun and aren't expecting to make money (but want to spend their free time but little money on it).
It's more powerful than other.NET languages because the CLR is designed for C#, which means that all of C# is supported. Other.NET languages are the part of the original language that is possible with the CLR; that is to say,.NET languages are like real languages, except without the features which would make them better than C# for some uses.
Salt water is essentially hydrochloric acid (stomach acid) and sodium hydroxide (lye); it's just that, when combined, they basically exactly cancel each other out.
If you electrify the salt water, they separate. If you turn off the power, they recombine. Anything that was near one side or the other will be pretty effectively fried. Of course, you're not going to entirely separate them, so there's a middle section where it's still just salt water. This device does some fluid mechanics and such to pass anything that is in the incoming water through both regions before the water (now recombined) comes out of the device. It's actually a bit of tricky engineering to make sure that absolutely nothing can get through without going through both regions, which is what this is all about.
The electrolysis experiment is trivial. The trick is being thorough when you've got water flowing through.
I like to just start writing code, but what I'm actually doing is a sketch of the design; it's just that I'm using a programming language rather than something less formal and more ambiguous. Generally, my first version won't remotely compile; it's not to actually be run, but rather to show data structures and flow control. I actually sometimes write it in a different language (Scheme is good for designing some things; Java is great for deciding where you need function pointers). If I've written it in the language I'm going to use, I avoid mistakes in translation.
I think the code you write while designing the structure should be either thrown away and replaced with code written after the structure is designed or should be essentially pseudocode (but in the language you're using: it should have comments or function calls instead of any non-trivial operations, and only idiomatic control structures).
The problem, of course, is that you don't know what features your code will need to have until you write the code that uses it. If you do too much design in advance, you'll have a wonderfully designed project which is impossible to implement (and now I use some information which I haven't been provided access to...) or which has lots of methods which aren't actually useful.
The only reasonable way to write code is to document it at the same time as you're implementing it: afterward, you've forgotten how it works, and before you don't yet know how it works. Of course, you'll want to do higher-level design beforehand, but be aware that your design must be flexible, in case it turns out not to work that way.
Today on slashdot, we have a nanomaterial that focuses light backwards, and also a nanomaterial that can attach to a flat, clean, dry surface well enough to support 200 lbs with a few square inches (using forces thought to only have effects at microscopic scales). The former is found only in labs and is brand new, and the latter is found in gardens and is older than humanity.
It's sort of interesting that the article refers to the negative refraction materials as "unnatural". Nature has been doing nanotech for millions of years now. It's pretty likely that, if these materials turn out to be good for anything that occurs in nature, they can be found there.
Yes, but what does 802.11 have to do with that? It's not like the internet doesn't have more malicious users than you could pack into 3 sq km. And it's a lot harder to track someone who could be anywhere in the world than it would be to track someone in a 3 sq km area.
Actually, I prefer not to use distributions. My home workstation I built from original packages and wrote the scripts (cribbing somewhat from Slackware). I actually know how everything got there and how the scripts work. But Slackware is pretty good for getting your initial installation in place without making it hard to take over maintenence yourself.
A while ago I tried to figure out how to change my IP address, and couldn't find it anywhere. After looking in all the config files I could think of, I tried reading the init scripts to see how it actually got set, and couldn't follow them at all.
I'm actually typing this on a Red Hat box on which I installed my own XFree86 (because I needed a version that Red Hat didn't have yet). At some point one of my coworkers tried doing some updates on this machine and it replaced my 4.x binaries with 3.x binaries, but it didn't replace my config file, so the whole thing failed to work rather badly. (Fortunately, I had the binaries under the version number, so it only messed up a symlink.
Another coworker tried installing a kernel RPM, which replaced the kernel but didn't run lilo correctly.
There's also NetIntercept from Sandstorm (http://www.sandstorm.net/) which is available and deployed at a number of US sites (and has been advertized on slashdot, for that matter).
Slashdot Mirror
They probably don't expect this to catch on. But offering something online that nobody downloads is no big deal. It's not like they don't have the couple GB of disk to have this around.
They want to get this in place before its time, because people will get used to whatever method is best when downloading movies becomes feasible. So they set it up and get people to use it as they get the necessary bandwidth. It's too soon to make money on it, but at least it's not too late to establish market share, and it will be really important to catch the early adopters, because they're who people will ask where to get movies when the masses can download them.
In developing nations there aren't going to be the same sorts of major rollouts you see in the US. Hardware doesn't come in as a big purchase; it trickles in piece by piece, depending on what's available and affordable, so you'll just have many instances of "We got another computer, and we put Linux on it."
Linux isn't actually that hard to tune for the low-end, because the core system (kernel, libraries, and such) are actually generally more efficient than they were 8 years ago, not less. Since they ran fine then, they'll run fine now. There are a lot of programs which are just too big and complicated for old hardware, but the old programs run better than they ever did.
Internationalization isn't actually as big an issue as you might think, because people tend to understand a bit of English, and it's mostly jargon anyway (knowing the English words "shell", "prompt", or "window" won't help you understand the computer terms, and having these terms translated into your native language doesn't help either). The issue is really documentation, but if you have an active local user's group, that's better than most of the documentation in any language (for most software, really).
In particular, a new configuration system has to be able to run on rules that the old configuration system can run on, so that both can be in the kernel until people are satisfied with the new one (ironic that Linus rejected CML2 for largely this reason, but then didn't follow this principal with IDE, where it would have been much easier). In order to replace something that everyone has to use, you have to replace it with something that just works for everybody, including the people writing rules, people who want to keep their old configs, people who want to maintain code for both the new kernels and old kernels, and so forth. The whole "Aunt Tillie" thing really is an issue, because important kernel developers don't want to spend more thought on configuring the kernel they're building than Aunt Tillie would, and they already have routine ways of doing that.
"Technical superiority" is a subjective thing, and "does it configure the kernel" is not the only factor. At least as important is "is switching to it easier than continuing to use the existing tools".
Incidentally, the problem with the old build system was not that it was too slow to build but that, if you changes a few things and rebuilt, either you did a complete rebuild, which was too slow, or you just rebuilt the module you were working on, which didn't necessarily catch all of the changes. The new versions are moving toward giving you the ability to rebuild only those things which actually need to be rebuilt without making you know what things these are. People frequently report problems where they've forgotten to do the right thing after they've changed something.
Making the current kernel's configuration available isn't actually difficult at all; it's just that userspace generally has the information anyway (most people copy the config file somewhere parallel to the kernel image). The hard thing is configuring a new kernel version to match the effects of the config file for an old kernel version: sometimes the options change, sometimes there are new options required for old things, etc.
It is (now) kind of ironic, because the static page you get instead of the dynamic page actually does contain the interview. Anyway, if hosed sites give any response, they're more likely to give 500, since they recognize the URL but can't manage to serve the page.
In any case, something which is unintentionally fitting is at least somewhat ironic, unlike the things in the Alanis song, which just suck.
What would have been really ironic would be if the correct id had been, say 304, not 404. And then it would have been even more ironic if there was then a duplicate article...
Then a bunch of people set up stands next to the Tux grove, with "all-you-can-drink" deals for a reasonable price. Of course, they manage it because they don't have to buy lemons, sugar, or water. Plus, the Tux-based stands just make a huge batch every day, because it's no harder to make a lot than it is to make a little if you don't have to pay for the supplies.
Actually, I'd like to see ads with a cleancut Windows drone with a little Tux pin talking about how great Windows is these days, and then he turns and walks away, revealing that he has a "Running Linux and doesn't know it" sign on his back.
I noticed that, in a (vaguely) recent Law & Order episode, the person looking up records at an ebank has a little Tux by his monitor. Nobody mentions it, but it's kind of neat product placement, except that it could be for any of a number of companies, which makes it seem like the people arranging the set just stuck it in.
They're clearly trying to determine whether Open Source could be a more complicated and expensive option. They have to decide whether to start suggesting that companies hire open source hackers to write whatever the companies want. If you look at the demographic survey, they are clearly figuring out that open source hackers are frequently not employed, but could demand a lot of money if someone were going to hire them, and they have the experience to write really complex stuff.
A little less tongue-in-cheek: BCG could probably do well coming in, looking at what your problems are, and telling you which open source hackers you should pay to fix them. Then they can charge a percentage on the whole thing.
There's only a limited amount of money you can spend buying MicroSoft products. It's huge, but you can spend even more on open source if you pay the salaries of the hackers. I mean, they are projects with hundreds or even thousands of contributors. If you give them each $100k...
So they say they're going to spam you, but don't actually spam you unless you opt in. That's pretty deceptive, but...
And MSIL has exactly the features that C# uses, and lacks the features needed for complete implementations of other languages. Whether the issue is the CLR or the bytecode it uses is splitting hairs.
That's not entirely true; the ideal way to do nanotechnology might be to probabilistically arrange groups of atoms into a limited set of arrangements and filter out the undesired ones.
For some applications, you probably actually do want to build your structures exactly and atom-by-atom. But other applications are best suited to a set of catalysts that will construct a random variant of the structure, so long as it has the property you want, or which will only sometimes construct the right thing, but everything else will be destroyed by another catalyst. For that matter, the most successful method has been to put together reasonably large molecules which are built separately.
For that matter, depending on what you're making, you may be perfectly happy with a couple of the desired molecules and a lot of innocuous failures. The failures then are basically packing material (you're not going to deliver someone a single molecule; you're going to deliver a manageable volume of uninteresting solution with an interesting molecule in it).
Having certain events only happen once in a few days is probably good, actually; it's just that the player shouldn't be waiting for just this one thing. There are games where certain things turn up only once in years of play, and people get really excited when they turn up. The rest of the time, they look for other things.
For that matter, if you have a ~once/week occurrence where the player had better be paying attention and has to do something situation-appropriate that isn't the usual thing (like run away as fast as possible), you'll develop a nice paranoia in your players even though it doesn't happen that often. Plus you'll make people not leave the game on autopilot because they'll not want to be gone when something important happens.
Incidentally, that stuff is a whole lot of fun to juggle. It's not difficult once you've got it going, but getting started is very difficult because two blobs in the same hand merge and a blob you're not paying attention to thins out and gets difficult to throw.
For real fun, juggle two blobs of this stuff and one of those plastic toroidal tubes of water, and remember which ones to squeeze each time...
As a former mega-star, it's to his advantage to be independant. But he's selling to the number of people he is now because he got an established fan base as a mega-star. The thing is that you make a lot more money as a signed musician nobody's heard of than as an unsigned one nobody's heard of. And becoming well-known is also a lot easier if you're signed.
So I wonder if Prince would like to get played on internet radio along with other independants, famous and unknown. For that matter, I wonder if he'd like to run an internet radio station and pick the unknowns he thinks should skip the major label phase.
Is the original libvorbis faster (due to making productive use of the FPU), or is the new integer math one faster (because floating point is pretty slow in general)? I'd guess that libvorbis is better on Intel and tremor is better on non-Intel x86 (due to the relative strengths of different vendors), but it's hard to say. Has anyone actually benchmarked them? libvorbis is a noticeable load on one of the machiens I use, so it would be worth switching if it would help.
They're contractors. They wrote this on contract for someone, and the contract allowed them to give it away after a while (IIRC). They weren't selling this in the first place. They wrote the floating-point vorbis, and then they were contacted by a company who wanted a fixed-point version and were willing to pay them to write it. Now they're giving away the fixed-point version in addition to the floating-point version, and probably working on other stuff for other people, with a similar deal.
It's like working for a software company. Once you've written something for them, you give it away (to the company); you continue to make money by getting paid to write more software, not being paid royalties or paid for licenses for the stuff you wrote previously.
You came up with a good way for the RIAA to get a reasonable benefit from online music and get what they are actually due when music is freely available. The RIAA hasn't gone for it, which is hardly surprising, considering that the RIAA are, so far as I can tell, the only people who don't like you.
So what can be done without the RIAA getting involved? Perhaps the RIAA would buy in if someone had gotten something working which was making money and didn't use RIAA-owned materials. I bet it would be possible to put together the music needed to have a site from people who just play for fun and aren't expecting to make money (but want to spend their free time but little money on it).
It's more powerful than other .NET languages because the CLR is designed for C#, which means that all of C# is supported. Other .NET languages are the part of the original language that is possible with the CLR; that is to say, .NET languages are like real languages, except without the features which would make them better than C# for some uses.
Salt water is essentially hydrochloric acid (stomach acid) and sodium hydroxide (lye); it's just that, when combined, they basically exactly cancel each other out.
If you electrify the salt water, they separate. If you turn off the power, they recombine. Anything that was near one side or the other will be pretty effectively fried. Of course, you're not going to entirely separate them, so there's a middle section where it's still just salt water. This device does some fluid mechanics and such to pass anything that is in the incoming water through both regions before the water (now recombined) comes out of the device. It's actually a bit of tricky engineering to make sure that absolutely nothing can get through without going through both regions, which is what this is all about.
The electrolysis experiment is trivial. The trick is being thorough when you've got water flowing through.
I like to just start writing code, but what I'm actually doing is a sketch of the design; it's just that I'm using a programming language rather than something less formal and more ambiguous. Generally, my first version won't remotely compile; it's not to actually be run, but rather to show data structures and flow control. I actually sometimes write it in a different language (Scheme is good for designing some things; Java is great for deciding where you need function pointers). If I've written it in the language I'm going to use, I avoid mistakes in translation.
I think the code you write while designing the structure should be either thrown away and replaced with code written after the structure is designed or should be essentially pseudocode (but in the language you're using: it should have comments or function calls instead of any non-trivial operations, and only idiomatic control structures).
The problem, of course, is that you don't know what features your code will need to have until you write the code that uses it. If you do too much design in advance, you'll have a wonderfully designed project which is impossible to implement (and now I use some information which I haven't been provided access to...) or which has lots of methods which aren't actually useful.
The only reasonable way to write code is to document it at the same time as you're implementing it: afterward, you've forgotten how it works, and before you don't yet know how it works. Of course, you'll want to do higher-level design beforehand, but be aware that your design must be flexible, in case it turns out not to work that way.
Today on slashdot, we have a nanomaterial that focuses light backwards, and also a nanomaterial that can attach to a flat, clean, dry surface well enough to support 200 lbs with a few square inches (using forces thought to only have effects at microscopic scales). The former is found only in labs and is brand new, and the latter is found in gardens and is older than humanity.
It's sort of interesting that the article refers to the negative refraction materials as "unnatural". Nature has been doing nanotech for millions of years now. It's pretty likely that, if these materials turn out to be good for anything that occurs in nature, they can be found there.
Yes, but what does 802.11 have to do with that? It's not like the internet doesn't have more malicious users than you could pack into 3 sq km. And it's a lot harder to track someone who could be anywhere in the world than it would be to track someone in a 3 sq km area.
Actually, I prefer not to use distributions. My home workstation I built from original packages and wrote the scripts (cribbing somewhat from Slackware). I actually know how everything got there and how the scripts work. But Slackware is pretty good for getting your initial installation in place without making it hard to take over maintenence yourself.
A while ago I tried to figure out how to change my IP address, and couldn't find it anywhere. After looking in all the config files I could think of, I tried reading the init scripts to see how it actually got set, and couldn't follow them at all.
I'm actually typing this on a Red Hat box on which I installed my own XFree86 (because I needed a version that Red Hat didn't have yet). At some point one of my coworkers tried doing some updates on this machine and it replaced my 4.x binaries with 3.x binaries, but it didn't replace my config file, so the whole thing failed to work rather badly. (Fortunately, I had the binaries under the version number, so it only messed up a symlink.
Another coworker tried installing a kernel RPM, which replaced the kernel but didn't run lilo correctly.
There's also NetIntercept from Sandstorm (http://www.sandstorm.net/) which is available and deployed at a number of US sites (and has been advertized on slashdot, for that matter).