The Xerox patent was GRANTED in 97. They _developed_ Unistrokes BEFORE the first Pilot came out. Also, the patent is not quite as trivial as "single stroke" letters. Because the strokes are single letters, they can be superimposed in the same space, without ambiguity in recognition. Furthermore, the direction of the stroke can be used to assist the recognition algorithm. These were the ideas that were patented.
196 _can't_ be the only number < 10,000 with this property of never generating a palindrome. In fact, 887, 1675, and 7436 must also have this property:
Clearly, if any of 887, 1675, or 7436 eventually lead to a palindrome, then so will 196. So why do people just keep talking about the special 196? It might be the first, but certainly not the only one < 10,000.
I don't see the 'wine' approach ever becoming glitch-free enough to be useful.
Try win4lin - it runs just about every useful windows app I need to run (office & quicken work perfectly). The only downside is you need to have a copy of windows 98.
Btw win4lin is much faster than vmware.
Well if you use Jython, than you don't need a python interpreter installed. If only all these scripting languages could target the JVM or.Net then we would only need the jvm and.net to be able to run all of them.
Crutcher said:
Okay, what, exactly, do we ship from Red Hat? Why, we ship 2.5 GIGS worth of community developed software in Red Hat Linux 7. THe bugs we track, for the most part, for the OVERWHELMING part, are not in Red Hat written code, they are in community code. I say this with confidence, because most of the software is community code.
Be that as it may, 'Red Hat Linux' is treated and will be treated as a platform. Saying the bug is in "community software" so it's not your problem is ridiculous since the whole point of commercial distributions is adding value, so that the whole is much greater than the sum of its parts. You can't say "look how awesome our distro is" when things are good and then say "oh, that bug is not our problem" when things go bad.
If a distro is not adding value (by adding stability, ease of use, tech support, etc...) the distro is worthless.
The most exciting new feature for me is the Logical Volume Manager included in 2.3.47. I've spent a lot of time administering AIX systems and the LVM is a Godsend for the harried system administrator. I don't know yet what the Linux LVM can do, but on AIX you can expand volumes while the system is running. I've heard that on HP you can shrink volumes as well. Even if the Linux LVM doesn't have all the bells and whistles, you can bet they will appear quickly now that the feature is in the mainstream kernel.
Yes but will it include support for large files (> 2 GB) on 32 bit machines? I've asked this before but have yet to get an absolutely definitive response:(
Now I actually agree with every one of your points about Java, and I'm not starting a flame war here. But it is a very important point to note that even C++ has some bizzare idioms. Your c++ code given above has a bug: go ahead an run it on a test file. It won't work: the final word will be printed twice, with an incorrect position the second time. The correct code is the following:
For/. readers who don't know what the value of the expression 'cin >> word' is, please read Stroustrup's book before responding. It evaluates to a bool, NOT the value of word. The bug in the first version has to do with exactly when the eof bit of the stream is set. So C++ makes it nearly impossible to do something very trivial correctly. Pretty scary stuff, eh? For all I know, even my version of the program might not work in some bizarre scenario. I'd have to check, cause the manpages sure don't document things precisely enough.
Well make sure to read the source for his explanation. You may have read it but for those who didn't bother:
<!-- Greetings, Lynx users. There is a reason this page doesn't use ALT tags on the images. The reason is that the bozos responsible for both MSIE and Netscape Confusicator 4.0 decided that they would display the ALT tags of images every time you move the mouse over them -- even if the images are loaded, and even if they are not links. The ALT attribute to the IMG tag is supposed to be used *instead of* the image, not *in addition to* the image.
This looks absolutely terrible, so I don't use ALT tags any more in self-defense.
If they wanted to implemented tooltips, they should have used the TITLE attribute to the A tag. That's in the HTML 1.2 spec and everything.
I had to decide between making this page look good for the vast majority of viewers, or making it be readable by the miniscule minority of you stuck in the 70s. Those of you in the retro contingent lost. Sorry.
-->
Re:Yeah there are some at tucows
on
SSH v. SRP
·
· Score: 1
You can get the TTSSH plugin for TerraTerm. It supports port forwarding, rsa authentication, shosts, etc...
Many/.ers are taking the stance "we don't need no stinking newbies." Think about what you're saying. Unless you are a kernel hacker yourself, there are many out there that consider you a newbie. When you install an app, do you rpm? Well then the./configure;make;make install'ers consider you a newbie. Do you./configure;make;make install? Well you nubian, why don't you do the configuring by hand tweaking every last parameter yourself, instead of relying on autoconf? The bottom line is, you can't just say "screw the newbies" without screwing yourself in turn. If linux configuration were more consistent and automated, you'd have time to do bigger and better things (like setting up beowulf cluster;)
Do you think there would have been enough developer support on linux for gnome, kde, mozilla, java etc... if the number of linux users hadn't gone up dramatically in the past 2 years? The rise in the user base helps everyone
Why is it that Cray computing withered away? Exactly because true power comes from using commodity parts that everyone uses, and customizing them. Where is this analogy headed? When the linux user base reaches critical mass, it will help all linux users. The same way that intel cpu's reaching critical mass caused their price/performance to reach a point where now any of us can build beowulf clusters rivaling Crays. When technology becomes cheap and heavily supported, we all see the benefits, especially with linux since it's open for hackers to customize as they see fit. Linux is already cheap (free!), so now we just need heavy support.
I believe that there never was a limit in the filesystem code. I don't know if the OS limitations have been lifted (I suspect they have). But a lot of applications won't "just work" and they won't "just work" on 64-bit machines either.
The problem is that to fix the 2GB limit you need to change every program to understand that they cannot just seek to an integer (or long) location. This kind of type change simply cannot be easily done, there are too many problems that can arise. Therefore even on 64-bit machines many programs only use 32-bit constructs and will require workarounds.
I'm not worried about having to recompile. As long as the kernel supports > 2GB on 32 bit machines, I'm sure rpms/debs etc... will let me drop in new/usr/bin/* which are 64 bit-filesize aware. When I say just work I mean I want glibc etc... to let me recompile apps so that there is no limit. I'm sure the common binaries (tar, cat, etc...) will be rereleased with support if the kernel limit is removed. I'm a developer, not a user, who is constantly hitting this limit. My tar example was probably misleading: I actually really don't care about tar;)
Anyway if anyone knows definitively whether 2.4 will have support for large files on 32 bit machines, please please speak up and give details. Thanks.
Does anyone know whether 2.4 will include support for > 2 GB files on 32 bit machines?
It is surprisingly difficult to find a definitive answer on this. I'm aware of the LFS patches at ftp://mea.tmt.tele.fi/linux/LFS/, but I need everything to 'just work', including iostream libraries etc...
In redhat 6.2 or 6.3, what are the chances that a tar cvzf stuff.tgz/data/* will just work without truncating my tarball to 2GB?
why don't you do the math? You and all the other repliers have no understanding of basic probability and expectation.
Yes, someone will win the weekly lottery: # of people playing the lottery x probability of winning = some reasonable number.
However, every single person on the planet typing away at a keyboard will have no effect on producing Macbeth, because # of people hacking x probability of producing macbeth != some reasonable number
Try again. It would take more than a few hundred thousand, or even a few million tosses. Given that MacBeth has over 100,000 letters in its entirety, it would take 26^100000 tosses. That's a 10 with 141,000 zeroes after it.
Do the math. Not going to happen even if you tossed the dice once every microsecond since the Big Bang:
15x10^9 years * 365*24*60*60*1x10^6 microseconds/year =~ only
4x10^23 tosses possible since the Big Bang
So no, random chance can't even produce MacBeth in 15 Billion years.
I was an intern at xerox parc back in 97 and 98. They actually showed us the video where unistrokes and the concept behind them were first demonstrated. Goldberg invented it long ago (it was around since at least 1993).
The salient point is that touch screens have more information than just the shape of the stroke: they can also recognize the direction of the stroke - something that doesn't apply to pencil/paper. By making each character represented by a single stroke, so that the pen is never lifted, AND by taking into account the pen movement as the stroke is made, accuracy is greatly enhanced. This in fact was a novel idea.
Xerox will never want to hurt Palm Pilots, in fact they are ubiquitious at PARC !! They do tons of research using PalmPilots. I suspect they just want to get a reasonable licensing fee for their research.
The problem is NOT with database/PHP/Zope/etc... driven site. They pose no problem to decent crawlers, since they behave like standard pages. Any dynamic html generation is done at the server, and is invisible to the client:
You GET a url, and back comes HTML.
The problem is with forms and javascript which happen to co-occur fairly often for obvious reasons with database driven sites. As long as url's (it doesn't matter if they end in.php or whatever) are provided as links, the crawler will have no problem in traversing them. But what about the target of a FORM 'action'?
How can a crawler deal with forms and javascript? Javascript may not always be so bad, if the crawler can execute the javascript. But how does a bot fill out a form (in other words how will the bot generate an appropriate query string)? If a form is the only entry point to a collection of information, that information is currently inaccessible to crawlers.
So how did you eventually resolve the NSI issue? I'm in a similar bind now where NSI just won't change the IP for a DNS server. What finally worked? It has been 5 days, and I can't spare anymore. It needs to be done now. thanks
Finally after wading through pages of garbage, people begin giving the correct info.
Slashdot quality has plummeted and even with personalized logins (to get only moderated messages) it is sometimes impossible to weed through the crap.
People just start typing away at the keyboard and don't give a damn about the facts. They don't bother to check anything they write. They just start making things up when they don't know anything about the matter.
Of course since this message is off topic, it is also crap, but since anonymous cowards can't filter by moderation score, I will be precisely reaching my target audience with this post.
A CPAN like mechanism would work well for languages that have very well defined, unambiguous specifications. Perl, for instance, behaves pretty much the same way on all (at least Unix) machines. Java and Python, as well as most other "interpreted" languages also share this characteristic.
C and C++, being much older, with more carryover "baggage", however, do not have the luxury of a fully specified language definition. In the ANSI spec for C/C++, there isn't even a set size for the basic data types! All that is required are various ambiguous properties such as sizeof(long) >= sizeof(int) >= sizeof(short)
A generic C/C++ code repository would face much difficulty in maintaining portable code that would just work for anyone, given the nature of these languages. As far as Perl, Java, and Python go, there are already many code repositories available: CPAN, Gamelan, and Python.org all contain links for downloadable "modules" for these languages, repsectively.
The problem with creating a single monolothic open source repository stuffed with functions and class libraries for everything under the sun is that people's needs are far too diverse. The current model, where tidbits of functionality for specific topics are maintained by various organizations considered "authoritative" in that field, has proved fairly effective. Some notable examples include netlib, libwww, ARPACK and of course CPAN.
I'm not sure what purpose would be served by bringing all of these various efforts under a single roof. They all have differing philosophies, goals, and styles. Some, such as ARPACK, are highly domain specific, and its maintainers are unlikely to care about "generic code repositories." The STL filled a very important niche, but having gotten the basic algorithms and data structures out of the way, creating a massive interdisciplinary code repository is an unachievable and perhaps undesirable feat.
There are two cases that apply to the conjecture that "Information Wants To Be Free".
The first is the situation where the distributor of the information would like to keep the information secret, while the recipient either has no preference, or would like to publicize the information. This case corresponds to the movie/music/software industry attempting to enforce copy protection. It clearly can never be done with 100% enforcement. At some point, regardless of the encryption scheme and protocol used, the information HAS to be converted to plaintext before the intended recipient can view the information. Thus the decision to keep the information secure is up to the recipient.
The second case is when both the distributor AND the recipient would like to keep the information secret. In this case, by using a sufficiently well tested and well designed encryption scheme and secure protocol for exchange, the information can be kept secret against all forms of attack.
So the ball is in the recipients court: the distributor has little control, and while security of information in the context of private email and so forth is entirely achievable, in the context of "copy protection" it is, as the borg say, futile.
Slashdot Mirror
The Xerox patent was GRANTED in 97. They _developed_ Unistrokes BEFORE the first Pilot came out. Also, the patent is not quite as trivial as "single stroke" letters. Because the strokes are single letters, they can be superimposed in the same space, without ambiguity in recognition. Furthermore, the direction of the stroke can be used to assist the recognition algorithm. These were the ideas that were patented.
196 _can't_ be the only number < 10,000 with this property of never generating a palindrome. In fact, 887, 1675, and 7436 must also have this property:
196 + 691 = 887
887 + 788 = 1675
1675 + 5761 = 7436
Clearly, if any of 887, 1675, or 7436 eventually lead to a palindrome, then so will 196. So why do people just keep talking about the special 196? It might be the first, but certainly not the only one < 10,000.
I don't see the 'wine' approach ever becoming glitch-free enough to be useful. Try win4lin - it runs just about every useful windows app I need to run (office & quicken work perfectly). The only downside is you need to have a copy of windows 98. Btw win4lin is much faster than vmware.
Your soundcard's DAC can make a *huge* difference. What soundcard are you using?
Well if you use Jython, than you don't need a python interpreter installed. If only all these scripting languages could target the JVM or .Net then we would only need the jvm and .net to be able to run all of them.
You DO have access to both drives. It swaps master/slave, affecting which gets BOOTED.
Interesting that it looks like Gore's won the popular vote..
Keep in mind though that not even Gore got a majority of the popular vote. So you can't exactly say he won it.
Be that as it may, 'Red Hat Linux' is treated and will be treated as a platform. Saying the bug is in "community software" so it's not your problem is ridiculous since the whole point of commercial distributions is adding value, so that the whole is much greater than the sum of its parts. You can't say "look how awesome our distro is" when things are good and then say "oh, that bug is not our problem" when things go bad.
If a distro is not adding value (by adding stability, ease of use, tech support, etc...) the distro is worthless.
You're right! I wonder why a bigger deal wasn't made of it when it happened. I can barely find this mentioned anywhere, ie on kernel mail archives.
Yes but will it include support for large files (> 2 GB) on 32 bit machines? I've asked this before but have yet to get an absolutely definitive response :(
while (cin)
{
- cin >> word;
}word_positions[word].push_back((int)cin.tellg() - word.size());
Now I actually agree with every one of your points about Java, and I'm not starting a flame war here. But it is a very important point to note that even C++ has some bizzare idioms. Your c++ code given above has a bug: go ahead an run it on a test file. It won't work: the final word will be printed twice, with an incorrect position the second time. The correct code is the following:
while ( cin >> word )
{
- word_positions[word].push_back((int)cin.tellg() - word.size());
}For /. readers who don't know what the value of the expression 'cin >> word' is, please read Stroustrup's book before responding. It evaluates to a bool, NOT the value of word. The bug in the first version has to do with exactly when the eof bit of the stream is set. So C++ makes it nearly impossible to do something very trivial correctly. Pretty scary stuff, eh? For all I know, even my version of the program might not work in some bizarre scenario. I'd have to check, cause the manpages sure don't document things precisely enough.
Well make sure to read the source for his explanation. You may have read it but for those who didn't bother:
<!-- Greetings, Lynx users. There is a reason this page doesn't use ALT tags on the images. The reason is that the bozos responsible for both MSIE and Netscape Confusicator 4.0 decided that they would display the ALT tags of images every time you move the mouse over them -- even if the images are loaded, and even if they are not links. The ALT attribute to the IMG tag is supposed to be used *instead of* the image, not *in addition to* the image.
This looks absolutely terrible, so I don't use ALT tags any more in self-defense.
If they wanted to implemented tooltips, they should have used the TITLE attribute to the A tag. That's in the HTML 1.2 spec and everything.
I had to decide between making this page look good for the vast majority of viewers, or making it be readable by the miniscule minority of you stuck in the 70s. Those of you in the retro contingent lost. Sorry.
-->
You can get the TTSSH plugin for TerraTerm. It supports port forwarding, rsa authentication, shosts, etc...
Both are fully free.
Many /.ers are taking the stance "we don't need no stinking newbies." Think about what you're saying. Unless you are a kernel hacker yourself, there are many out there that consider you a newbie. When you install an app, do you rpm? Well then the ./configure;make;make install'ers consider you a newbie. Do you ./configure;make;make install? Well you nubian, why don't you do the configuring by hand tweaking every last parameter yourself, instead of relying on autoconf? The bottom line is, you can't just say "screw the newbies" without screwing yourself in turn. If linux configuration were more consistent and automated, you'd have time to do bigger and better things (like setting up beowulf cluster ;)
Do you think there would have been enough developer support on linux for gnome, kde, mozilla, java etc... if the number of linux users hadn't gone up dramatically in the past 2 years? The rise in the user base helps everyone
Why is it that Cray computing withered away? Exactly because true power comes from using commodity parts that everyone uses, and customizing them. Where is this analogy headed? When the linux user base reaches critical mass, it will help all linux users. The same way that intel cpu's reaching critical mass caused their price/performance to reach a point where now any of us can build beowulf clusters rivaling Crays. When technology becomes cheap and heavily supported, we all see the benefits, especially with linux since it's open for hackers to customize as they see fit. Linux is already cheap (free!), so now we just need heavy support.
I believe that there never was a limit in the filesystem code. I don't know if the OS limitations have been lifted (I suspect they have). But a lot of applications won't "just work" and they won't "just work" on 64-bit machines either.
The problem is that to fix the 2GB limit you need to change every program to understand that they cannot just seek to an integer (or long) location. This kind of type change simply cannot be easily done, there are too many problems that can arise. Therefore even on 64-bit machines many programs only use 32-bit constructs and will require workarounds.
I'm not worried about having to recompile. As long as the kernel supports > 2GB on 32 bit machines, I'm sure rpms/debs etc... will let me drop in new /usr/bin/* which are 64 bit-filesize aware. When I say just work I mean I want glibc etc... to let me recompile apps so that there is no limit. I'm sure the common binaries (tar, cat, etc...) will be rereleased with support if the kernel limit is removed. I'm a developer, not a user, who is constantly hitting this limit. My tar example was probably misleading: I actually really don't care about tar ;)
Anyway if anyone knows definitively whether 2.4 will have support for large files on 32 bit machines, please please speak up and give details. Thanks.
Does anyone know whether 2.4 will include support for > 2 GB files on 32 bit machines?
It is surprisingly difficult to find a definitive answer on this. I'm aware of the LFS patches at ftp://mea.tmt.tele.fi/linux/LFS/, but I need everything to 'just work', including iostream libraries etc...
In redhat 6.2 or 6.3, what are the chances that a tar cvzf stuff.tgz /data/* will just work without truncating my tarball to 2GB?
why don't you do the math? You and all the other repliers have no understanding of basic probability and expectation.
Yes, someone will win the weekly lottery: # of people playing the lottery x probability of winning = some reasonable number.
However, every single person on the planet typing away at a keyboard will have no effect on producing Macbeth, because # of people hacking x probability of producing macbeth != some reasonable number
Try again. It would take more than a few hundred thousand, or even a few million tosses. Given that MacBeth has over 100,000 letters in its entirety, it would take 26^100000 tosses. That's a 10 with 141,000 zeroes after it.
Do the math. Not going to happen even if you tossed the dice once every microsecond since the Big Bang:
So no, random chance can't even produce MacBeth in 15 Billion years.
I was an intern at xerox parc back in 97 and 98. They actually showed us the video where unistrokes and the concept behind them were first demonstrated. Goldberg invented it long ago (it was around since at least 1993).
The salient point is that touch screens have more information than just the shape of the stroke: they can also recognize the direction of the stroke - something that doesn't apply to pencil/paper. By making each character represented by a single stroke, so that the pen is never lifted, AND by taking into account the pen movement as the stroke is made, accuracy is greatly enhanced. This in fact was a novel idea.
Xerox will never want to hurt Palm Pilots, in fact they are ubiquitious at PARC !! They do tons of research using PalmPilots. I suspect they just want to get a reasonable licensing fee for their research.
The problem is NOT with database/PHP/Zope/etc... driven site. They pose no problem to decent crawlers, since they behave like standard pages. Any dynamic html generation is done at the server, and is invisible to the client:
You GET a url, and back comes HTML.
The problem is with forms and javascript which happen to co-occur fairly often for obvious reasons with database driven sites. As long as url's (it doesn't matter if they end in .php or whatever) are provided as links, the crawler will have no problem in traversing them. But what about the target of a FORM 'action'?
How can a crawler deal with forms and javascript? Javascript may not always be so bad, if the crawler can execute the javascript. But how does a bot fill out a form (in other words how will the bot generate an appropriate query string)? If a form is the only entry point to a collection of information, that information is currently inaccessible to crawlers.
So how did you eventually resolve the NSI issue? I'm in a similar bind now where NSI just won't change the IP for a DNS server. What finally worked? It has been 5 days, and I can't spare anymore. It needs to be done now. thanks
Finally after wading through pages of garbage, people begin giving the correct info.
Slashdot quality has plummeted and even with personalized logins (to get only moderated messages) it is sometimes impossible to weed through the crap.
People just start typing away at the keyboard and don't give a damn about the facts. They don't bother to check anything they write. They just start making things up when they don't know anything about the matter.
Of course since this message is off topic, it is also crap, but since anonymous cowards can't filter by moderation score, I will be precisely reaching my target audience with this post.
A CPAN like mechanism would work well for languages that have very well defined, unambiguous specifications. Perl, for instance, behaves pretty much the same way on all (at least Unix) machines. Java and Python, as well as most other "interpreted" languages also share this characteristic.
C and C++, being much older, with more carryover "baggage", however, do not have the luxury of a fully specified language definition. In the ANSI spec for C/C++, there isn't even a set size for the basic data types! All that is required are various ambiguous properties such as sizeof(long) >= sizeof(int) >= sizeof(short)
A generic C/C++ code repository would face much difficulty in maintaining portable code that would just work for anyone, given the nature of these languages. As far as Perl, Java, and Python go, there are already many code repositories available: CPAN, Gamelan, and Python.org all contain links for downloadable "modules" for these languages, repsectively.
The problem with creating a single monolothic open source repository stuffed with functions and class libraries for everything under the sun is that people's needs are far too diverse. The current model, where tidbits of functionality for specific topics are maintained by various organizations considered "authoritative" in that field, has proved fairly effective. Some notable examples include netlib, libwww, ARPACK and of course CPAN.
I'm not sure what purpose would be served by bringing all of these various efforts under a single roof. They all have differing philosophies, goals, and styles. Some, such as ARPACK, are highly domain specific, and its maintainers are unlikely to care about "generic code repositories." The STL filled a very important niche, but having gotten the basic algorithms and data structures out of the way, creating a massive interdisciplinary code repository is an unachievable and perhaps undesirable feat.
There are two cases that apply to the conjecture that "Information Wants To Be Free".
The first is the situation where the distributor of the information would like to keep the information secret, while the recipient either has no preference, or would like to publicize the information. This case corresponds to the movie/music/software industry attempting to enforce copy protection. It clearly can never be done with 100% enforcement. At some point, regardless of the encryption scheme and protocol used, the information HAS to be converted to plaintext before the intended recipient can view the information. Thus the decision to keep the information secure is up to the recipient.
The second case is when both the distributor AND the recipient would like to keep the information secret. In this case, by using a sufficiently well tested and well designed encryption scheme and secure protocol for exchange, the information can be kept secret against all forms of attack.
So the ball is in the recipients court: the distributor has little control, and while security of information in the context of private email and so forth is entirely achievable, in the context of "copy protection" it is, as the borg say, futile.