If you're using separate I/O devices, it's a different issue. In particular, device size doesn't matter much; it can be 1" square if you never have to hold it. The real issue is the size of the I/O devices, which you have to actually deal with directly, rather than just carrying. If you have a earphone in your ear and a mic on your collar, the device is longer than a finger (just not continuous in between). Personally, I think a mic on the wrist would be best, since then you cover your mouth when you're talking on the phone.
If you're going to have this always ready, you need a non-voice interface, or you'll be calling everyone whose name you mention in conversation or every phone number you try to tell someone. In any case, people tend to know a lot of phone numbers by feel, and failing to provide that interface will make people really unhappy.
It seems to me that Microsoft does tend to abandon platforms frequently, and tends to force upgrades of programs where the new versions aren't available in some of the streams, which is essentially the same as abandoning the stream, although they may actually intend to release new versions eventually.
On the other hand, neither KDE nor Gnome will ever go away, not become unsupported, because the direction of the open source community as a whole is totally irrelevent; each of these has its own community, which prefers it, and which will continue to use and support it.
As evidence for this, I should mention that even much older and less popular alternatives continue to be supported. I'm now using fvwm, like I have been for the past 6 years, and it has continued to meet my needs and be supported despite the fact that it's mostly ignored by the rest of the world.
The issue with games isn't so much that the development cycle is so short, it's that there's some much artistic content in games these days.
Games consist of an engine and some content. The content is generally a lot of work, not usefully designed by a community, and has little reuse value (in the sense of code reuse). It's also generally encoded to avoid spoiling the plot.
Engines are a good candidate for open source development, except that, since the engine is really used directly by game developers (and only somewhat indirectly by players), the usual userbase of the programmers themselves isn't really there. The game developers are hard to convince to use open source engines, especially because they tend to want to make it as difficult as possible to get the content out (other than playing it), because the proprietary engines are ahead, and because the in-house engine developers tend not to mind that the game gets spoiled for them so the developers can ask for the features they actually want.
If this is going to replace a cell phone, it had better be long enough to reach from your mouth to your ear. If it's not big enough to have at least a 3x4 grid of spots you press reliably, you're not going to have much fun dialing it (let alone putting in other information). Current cell phone size is essentially constrained by the interface requirements.
A lot of wishlist items aren't going to come true simply because if they did, the device would then be useless.
Yes, in the last 30 years, the C language family has finally gotten as slow and large as the Lisp family has been all along, and now processor speed and memory size have gotten up to the level needed to do things usefully in Lisp.
You have to respect a language which is so much ahead of its time that it can compete with languages developed decades later, even if it was too slow for most applications on most hardware in the intervening time.
On the other hand, CL's huge library makes it an enormous project to implement, whereas Scheme can be implemented in a weekend.
Someday someone will write a good CL library in Scheme, and we'll all be happy, except for the people who want to know the truth value of the empty list.
If you've got other music which you're selling (under a different license, of course), being acknowledged is publicity. Even if you're other licensing your music differently, if you also sell CDs of it for people who want to actually buy it, the situation is essentially an above-board version of the Napster situation, which we all know leads to more people buying your music.
If he had not specifically accepted the possibility of more than two files, it would be a case of someone exploiting a loophole in his challenge. But the challenger actually asked about the loophole, and was told that it was okay. If you're making bets like this, you ought to be sufficiently attentive to not permit loopholes if the person asks about them before using them.
In this case, the challengee specifically asked if the challenger would permit multiple files, and the challenger said yes. It's hard to argue that, simply because he *intended* to say either no, or "yes, but you have to include metadata size on all files after the first" or something else that would actually require compression, that he should be let off the hook. He was asked a straightforward question and gave a straight and wrong answer, and should lose because of that.
Perhaps a better place to fight this...
on
Sean In The Middle
·
· Score: 1
Is in college admissions offices. If I were an admissions officer (or, for that matter, a potential employer), I would look quite unfavorably on a degree from such a high school. In fact, I would probably consider Sean's educational history better than that of his classmates, and I would consider him a more suitable person to have around, even from the school administrators' account of the incident.
There are, in fact, significant checks on what a high school can do to its students, provided the information actually gets out, because the high school's reputation does matter.
Can high schools do this sort of thing? Sure, but if it's reported with actual names and dates and so forth, and mentioned to colleges, it could quickly lead to "You're from that school in Texas, right? So, are you an abusive jerk, full of repressed anger, or just too boring to be noticed?" If the school's reputation starts hurting students' chances, I bet parents will be pressuring administrators to shape up pretty quickly.
Will it succeed? Not any time soon. Will it fail? Probably not. Sega got out of the business because they're a business and have to do well. If this works like most open source projects, they'll probably not be depending on it having a lot of income to pay the workers. They could just put it together, sell it for cost of parts + time, and do fine because the people have day jobs (or whatever they do in their non-spare time). At a minimum, they could exist as a hardware suggestion list, a simple Linux distribution, and a list of open source games.
If nothing else, this could end up as a linux gaming site that doesn't assume you've already got the hardware, but tells you what's the best buy as far as support (with the exact system configuration, so you don't run into compatibility problems with similar hardware) and price, etc. Even that would be useful, as a direct way to make it more worthwhile to support Linux well.
If they get a reasonable number of orders, they could actually assemble the systems themselves, and make it even more straightforward to get such a machine set up.
In any case, it would give developers an idea of what system configuration would be good for them to have when trying to port games to Linux. If they already want to support Linux desktop boxes, they might as well support this, too, since it should be a no-op.
Actually, having someone selling PCs configured to be good for playing Linux games is essentially trivial (once you've worked out the system specs once-- and many people have already for their own purposes). Then all you do is buy parts, build the machines, test them, and ship them out. If you can skip some hardware (doesn't need that big a hard drive, doesn't need a monitor if it does TV out), you have a box at about normal console prices.
The clients (or some of them) could have the spiffy rendering stuff on them, instead of going over the LAN for it. After all, you don't even do extensive graphics over the system bus today. If the video card's on the client side, the bandwidth from server to client's a lot lower.
I could easily see a client with a minimal processor, a spiffy video card with a bunch of extra memory for textures and stuff, and a monitor running Q3A really well with the program actually running on a different machine.
Didn't the FCC consider having AIM open a requirement for the merger with Time/Warner? Simply including an AIM binary in your free client must then be fine, because the entire binary is part of the protocol, which has been forced into the public domain. If the successfully sue someone for distributing it, they're getting into anti-trust suits and asking to have their AIM servers taken down by government agents.
Re:So where does the information come from?
on
A Map to Nowhere?
·
· Score: 1
The genome's not just any CD-ROM-worth of data, though. There are a lot of things that happen with a sequence other than simply building proteins straight from it.
Consider it like a CD with a DOS filesystem and a Linux filesystem on it in the same places. The contents read each way are totally different, because the reading mechanism reads different things and combines them differently. Then it additionally has things that are both Mac binaries and Intel binaries that do totally different things.
So it's less like a Windows CD than like a best of Obfuscated C Contest CD, where they picked all of the programs that do a bunch of totally different things, except that they interact and include, among them, obfuscated versions of all of the utilities.
The latest news is that straightforward compilation of all of the files doesn't produce all that much of the interesting stuff.
In fact, what breathes life into the genome is the complex set of ways the DNA is used, and all of the ways that the raw data is interpreted, from compiling it with different sections commented out to compiling it with a somewhat different compiler to passing chunks of the source code to the linker as well as the compiler. This set of ways is packaged with the DNA (and can be reconstructed from it later, too).
Thin client doesn't have to mean central (= big corp) control. It's certainly possible that in a couple of years you'll have a linux box under the stairs and flat-screen clients on all your walls. I know I've had a lot of luck with a home machine with screen and sshd; I have my own machine, but it shows up wherever I want it, including a thin ssh client.
In fact, for a while I was using the machine to actually sit at, but I would still run an xterm with the screen session, making it act as a thin client for itself.
I could really see an application with all of the components running on the client (possibly downloaded from home, if it's unusual), and the stuff that puts them together on your home machine, and an encrypted connection between them which doesn't demand too much bandwidth.
"We think Office has so many new features for making it easier to use that Clippy is no longer useful."
Since when have new Microsoft features made anything easier to use? Didn't I just read a review of XP which said that it wasn't intuitive to people used to previous Windows variants?
We just have more medium-term storage. The sorts of things that won't last more than a couple dozen years are generally things which, in the old days, wouldn't have lasted a minute: music couldn't be stored at all until recently, and many conversations we have by email (which could degrade) would have been done in person and never stored at all.
Enormous damages aren't actually required, since just losing the suit would effectively destroy Monsanto's business model. It would create a precendent for anyone who didn't buy their seed and found it on their land suing for damages. If farmers can do better by buying non-Monsanto seed, selling their produce and suing Monsanto than by buying Monsanto seed and selling the produce from that, Monsanto's in trouble.
What is needed is a period when people can drink, but are discouraged from doing so without guidence. This was, in fact, the original idea (at least in many places) when the age limit of 21 was introduced: people under 21 would only be able to drink with someone older willing to be responsible for them who provided the alcohol. This would promote a period of responsible drinking before people were able to drink be themselves.
Unfortunately, this idea seems to have been lost, and, instead, people under 21 can generally only drink irresponsibly, and thus have bad drinking habits when they are later allowed to drink as they want.
It might be worth ditching core support for a certain set of features (some kinds of color depths that nobody uses, e.g.) and having more direct support for the current common case: local X clients trying to do the sorts of things modern windowing systems do.
On the other hand, backwards compatibility, especially at the source level, is very important. But it could be only supported through a compatibility layer. (Xnest for Berlin, perhaps?)
A lot of the point of expensive certs is that they involve having Someone Trusted (e.g. VeriSign) attest to your identity. This is, of course, expensive.
On the other hand, people generally don't care at all exactly who you are: they do a web serach on the product they want, find an site that sells it, go there, and then consider buying from them. Or they do care who they're buying from, but it's not a stranger they have to trust verisgn to identify: they have the catalog or have been to the store before.
In the former case, the customer wants to know that the site is some business in good standing. What they'd probably want is a certificate from the Better Business Bureau or from the place where the company is incorporated, neither of whom needs online verification of identity.
In the latter case, the customer wants to know they're ordering from the company with the flyer they have. So the company should really provide a self-signed certificate with a fingerprint in the catalog. The user gets the certificate, checks that it matches the catalog, and knows they're in the right place.
VeriSign is preforming some mixture of these tasks, checking that the site belongs to someone traceable and also that it isn't trying to be confused with someone else. But most users don't even consider the CA, so if the CA messed up, they wouldn't know which one to blame or even realize that someone supposedly checked out the site if it was using SSL.
Slashdot Mirror
If you're using separate I/O devices, it's a different issue. In particular, device size doesn't matter much; it can be 1" square if you never have to hold it. The real issue is the size of the I/O devices, which you have to actually deal with directly, rather than just carrying. If you have a earphone in your ear and a mic on your collar, the device is longer than a finger (just not continuous in between). Personally, I think a mic on the wrist would be best, since then you cover your mouth when you're talking on the phone.
If you're going to have this always ready, you need a non-voice interface, or you'll be calling everyone whose name you mention in conversation or every phone number you try to tell someone. In any case, people tend to know a lot of phone numbers by feel, and failing to provide that interface will make people really unhappy.
It seems to me that Microsoft does tend to abandon platforms frequently, and tends to force upgrades of programs where the new versions aren't available in some of the streams, which is essentially the same as abandoning the stream, although they may actually intend to release new versions eventually.
On the other hand, neither KDE nor Gnome will ever go away, not become unsupported, because the direction of the open source community as a whole is totally irrelevent; each of these has its own community, which prefers it, and which will continue to use and support it.
As evidence for this, I should mention that even much older and less popular alternatives continue to be supported. I'm now using fvwm, like I have been for the past 6 years, and it has continued to meet my needs and be supported despite the fact that it's mostly ignored by the rest of the world.
The issue with games isn't so much that the development cycle is so short, it's that there's some much artistic content in games these days.
Games consist of an engine and some content. The content is generally a lot of work, not usefully designed by a community, and has little reuse value (in the sense of code reuse). It's also generally encoded to avoid spoiling the plot.
Engines are a good candidate for open source development, except that, since the engine is really used directly by game developers (and only somewhat indirectly by players), the usual userbase of the programmers themselves isn't really there. The game developers are hard to convince to use open source engines, especially because they tend to want to make it as difficult as possible to get the content out (other than playing it), because the proprietary engines are ahead, and because the in-house engine developers tend not to mind that the game gets spoiled for them so the developers can ask for the features they actually want.
If this is going to replace a cell phone, it had better be long enough to reach from your mouth to your ear. If it's not big enough to have at least a 3x4 grid of spots you press reliably, you're not going to have much fun dialing it (let alone putting in other information). Current cell phone size is essentially constrained by the interface requirements.
A lot of wishlist items aren't going to come true simply because if they did, the device would then be useless.
Yes, in the last 30 years, the C language family has finally gotten as slow and large as the Lisp family has been all along, and now processor speed and memory size have gotten up to the level needed to do things usefully in Lisp.
You have to respect a language which is so much ahead of its time that it can compete with languages developed decades later, even if it was too slow for most applications on most hardware in the intervening time.
On the other hand, CL's huge library makes it an enormous project to implement, whereas Scheme can be implemented in a weekend.
Someday someone will write a good CL library in Scheme, and we'll all be happy, except for the people who want to know the truth value of the empty list.
Hmm... IP over UPS truck...
What looks like a quick paint program scrawl of the words "secure me".
That this many people would all want to look at a serious RFC at the same time.
If you've got other music which you're selling (under a different license, of course), being acknowledged is publicity. Even if you're other licensing your music differently, if you also sell CDs of it for people who want to actually buy it, the situation is essentially an above-board version of the Napster situation, which we all know leads to more people buying your music.
If he had not specifically accepted the possibility of more than two files, it would be a case of someone exploiting a loophole in his challenge. But the challenger actually asked about the loophole, and was told that it was okay. If you're making bets like this, you ought to be sufficiently attentive to not permit loopholes if the person asks about them before using them.
In this case, the challengee specifically asked if the challenger would permit multiple files, and the challenger said yes. It's hard to argue that, simply because he *intended* to say either no, or "yes, but you have to include metadata size on all files after the first" or something else that would actually require compression, that he should be let off the hook. He was asked a straightforward question and gave a straight and wrong answer, and should lose because of that.
Is in college admissions offices. If I were an admissions officer (or, for that matter, a potential employer), I would look quite unfavorably on a degree from such a high school. In fact, I would probably consider Sean's educational history better than that of his classmates, and I would consider him a more suitable person to have around, even from the school administrators' account of the incident.
There are, in fact, significant checks on what a high school can do to its students, provided the information actually gets out, because the high school's reputation does matter.
Can high schools do this sort of thing? Sure, but if it's reported with actual names and dates and so forth, and mentioned to colleges, it could quickly lead to "You're from that school in Texas, right? So, are you an abusive jerk, full of repressed anger, or just too boring to be noticed?" If the school's reputation starts hurting students' chances, I bet parents will be pressuring administrators to shape up pretty quickly.
Will it succeed? Not any time soon. Will it fail? Probably not. Sega got out of the business because they're a business and have to do well. If this works like most open source projects, they'll probably not be depending on it having a lot of income to pay the workers. They could just put it together, sell it for cost of parts + time, and do fine because the people have day jobs (or whatever they do in their non-spare time). At a minimum, they could exist as a hardware suggestion list, a simple Linux distribution, and a list of open source games.
If nothing else, this could end up as a linux gaming site that doesn't assume you've already got the hardware, but tells you what's the best buy as far as support (with the exact system configuration, so you don't run into compatibility problems with similar hardware) and price, etc. Even that would be useful, as a direct way to make it more worthwhile to support Linux well.
If they get a reasonable number of orders, they could actually assemble the systems themselves, and make it even more straightforward to get such a machine set up.
In any case, it would give developers an idea of what system configuration would be good for them to have when trying to port games to Linux. If they already want to support Linux desktop boxes, they might as well support this, too, since it should be a no-op.
Actually, having someone selling PCs configured to be good for playing Linux games is essentially trivial (once you've worked out the system specs once-- and many people have already for their own purposes). Then all you do is buy parts, build the machines, test them, and ship them out. If you can skip some hardware (doesn't need that big a hard drive, doesn't need a monitor if it does TV out), you have a box at about normal console prices.
The clients (or some of them) could have the spiffy rendering stuff on them, instead of going over the LAN for it. After all, you don't even do extensive graphics over the system bus today. If the video card's on the client side, the bandwidth from server to client's a lot lower.
I could easily see a client with a minimal processor, a spiffy video card with a bunch of extra memory for textures and stuff, and a monitor running Q3A really well with the program actually running on a different machine.
Didn't the FCC consider having AIM open a requirement for the merger with Time/Warner? Simply including an AIM binary in your free client must then be fine, because the entire binary is part of the protocol, which has been forced into the public domain. If the successfully sue someone for distributing it, they're getting into anti-trust suits and asking to have their AIM servers taken down by government agents.
The genome's not just any CD-ROM-worth of data, though. There are a lot of things that happen with a sequence other than simply building proteins straight from it.
Consider it like a CD with a DOS filesystem and a Linux filesystem on it in the same places. The contents read each way are totally different, because the reading mechanism reads different things and combines them differently. Then it additionally has things that are both Mac binaries and Intel binaries that do totally different things.
So it's less like a Windows CD than like a best of Obfuscated C Contest CD, where they picked all of the programs that do a bunch of totally different things, except that they interact and include, among them, obfuscated versions of all of the utilities.
The latest news is that straightforward compilation of all of the files doesn't produce all that much of the interesting stuff.
In fact, what breathes life into the genome is the complex set of ways the DNA is used, and all of the ways that the raw data is interpreted, from compiling it with different sections commented out to compiling it with a somewhat different compiler to passing chunks of the source code to the linker as well as the compiler. This set of ways is packaged with the DNA (and can be reconstructed from it later, too).
You can have a dual p4; you just have to have one of them disabled at any given time...
Actually, I wonder if they could build a motherboard where, if one CPU got too hot, it would switch over to the other one.
Thin client doesn't have to mean central (= big corp) control. It's certainly possible that in a couple of years you'll have a linux box under the stairs and flat-screen clients on all your walls. I know I've had a lot of luck with a home machine with screen and sshd; I have my own machine, but it shows up wherever I want it, including a thin ssh client.
In fact, for a while I was using the machine to actually sit at, but I would still run an xterm with the screen session, making it act as a thin client for itself.
I could really see an application with all of the components running on the client (possibly downloaded from home, if it's unusual), and the stuff that puts them together on your home machine, and an encrypted connection between them which doesn't demand too much bandwidth.
"We think Office has so many new features for making it easier to use that Clippy is no longer useful."
Since when have new Microsoft features made anything easier to use? Didn't I just read a review of XP which said that it wasn't intuitive to people used to previous Windows variants?
We just have more medium-term storage. The sorts of things that won't last more than a couple dozen years are generally things which, in the old days, wouldn't have lasted a minute: music couldn't be stored at all until recently, and many conversations we have by email (which could degrade) would have been done in person and never stored at all.
Enormous damages aren't actually required, since just losing the suit would effectively destroy Monsanto's business model. It would create a precendent for anyone who didn't buy their seed and found it on their land suing for damages. If farmers can do better by buying non-Monsanto seed, selling their produce and suing Monsanto than by buying Monsanto seed and selling the produce from that, Monsanto's in trouble.
What is needed is a period when people can drink, but are discouraged from doing so without guidence. This was, in fact, the original idea (at least in many places) when the age limit of 21 was introduced: people under 21 would only be able to drink with someone older willing to be responsible for them who provided the alcohol. This would promote a period of responsible drinking before people were able to drink be themselves.
Unfortunately, this idea seems to have been lost, and, instead, people under 21 can generally only drink irresponsibly, and thus have bad drinking habits when they are later allowed to drink as they want.
It might be worth ditching core support for a certain set of features (some kinds of color depths that nobody uses, e.g.) and having more direct support for the current common case: local X clients trying to do the sorts of things modern windowing systems do.
On the other hand, backwards compatibility, especially at the source level, is very important. But it could be only supported through a compatibility layer. (Xnest for Berlin, perhaps?)
A lot of the point of expensive certs is that they involve having Someone Trusted (e.g. VeriSign) attest to your identity. This is, of course, expensive.
On the other hand, people generally don't care at all exactly who you are: they do a web serach on the product they want, find an site that sells it, go there, and then consider buying from them. Or they do care who they're buying from, but it's not a stranger they have to trust verisgn to identify: they have the catalog or have been to the store before.
In the former case, the customer wants to know that the site is some business in good standing. What they'd probably want is a certificate from the Better Business Bureau or from the place where the company is incorporated, neither of whom needs online verification of identity.
In the latter case, the customer wants to know they're ordering from the company with the flyer they have. So the company should really provide a self-signed certificate with a fingerprint in the catalog. The user gets the certificate, checks that it matches the catalog, and knows they're in the right place.
VeriSign is preforming some mixture of these tasks, checking that the site belongs to someone traceable and also that it isn't trying to be confused with someone else. But most users don't even consider the CA, so if the CA messed up, they wouldn't know which one to blame or even realize that someone supposedly checked out the site if it was using SSL.