Actually, if my memory is correct, 3com shouldn't even have gotten 3com.com. Before some date, domain names were not allowed to start with a digit. I seem to recall reading rules to that effect from an ostensibly authoratative and current source long after 3com.com came to be.
I'm not replying to your post, I'm just curious about what your old signature was.
;-)
Re:.. but software modems are evil?
on
GNU Radio
·
· Score: 1
Exactly my first thought too:-)
But really, the reason most slashdotters dislike software modems is not just that they steal a few cpu cycles from quake3, but that a) they do it in a closed source driver and b) the manufacturer often doesn't bother to tell you that you're getting less of a modem.
If you take those problems out of the picture, offloading part of a device's function to the CPU can be a good thing. Stuff that was being done in a chip with no published specs can be done in free software. If the main computer is capable enough (processing speed, bus bandwidth), then why not replace all sorts of modems, radio/tv cards, etc. with software?
All these things eventually boil down to the same thing: one or more wires get connected to the computer and a signal is read or generated on those wires. It would be pretty cool if computers just had a multitude of physical connectors and you could address each pin of each of them. You get a new internet connection (ISDN, ADSL, cable, some kind of wireless thing) and you just plug the cable into the computer and download the appropriate module. HDTV transmissions become available in your area? Just download the module and sign up!
Practical issues aside (like whether today's computers could actually handle all this), I think more of this development is a good thing. Just think of how long Linux users (let alone users of more obscure systems) often have to wait for good drivers for radio/tv tuners to become available because driver developers have to understand each device's undocumented and unique interface, and then consider that the signals these devices are receiving are all well understood, unchanging, and even regulated by government!
I noticed that neither the Actual Depth page nor the TechTV writeup talked about this at all. Both presented this device as something that simply gives you two planes to work with: "Imagine editing video, for example, and having your video displayed full-screen under your timeline and other editing palettes.".
I'm aware of the technique of putting a vertical grating on top of a screen to block every other line from each eye, then drawing the right eye image on the odd lines and the left eye image on the even ones, creating a 3D image. You seem to be talking about something like that, with the front monitor taking over the role of the grating. In that case, I think "This is the difficult part!" is an understatement. Can you explain further? Or are you talking about a different principle?
That's not enough. It's not an April fool's gag unless the people taken in actually go somewhere, do something, or call someone as a result. And while visiting a site might technically qualify, it's pretty damn weak. At least Linus's post to lkml required you to email him. Still weak, but better.
Sort of like putting a sail on one end of a skateboard and a fan blowing air on it on the other end. It still isn't going anywhere.
Hey, we did that in physics class once. It wasn't a skateboard, it was one of those little carts you do momentum displays with, but there was a fan blowing into a sail (actually a stiff board) and we were supposed to guess what would happen. It moved toward the sail side.
That's not entirely correct. While the majority of Pre-X MacOS installations don't have an interactive shell, they do have an AppleScript interpreter. Remember the/. story of the stolen Mac recovered with the aid of Timbuktu? A key element was the use of an applescript placed in some folder where it was executed on boot.
Now, I have only a superficial acquaintance with MacOS, but it seems to me that the applescript interpreter can be used by an attacker in many of the same ways that/bin/sh can be used. The Chooser can't be called with commandline paramaters, but do you know if it has an AppleScript interface? (I don't.)
I agree that his predictions are ridiculously optimistic for the most part (except that much of the wearable stuff has already happened).
But pointing that out isn't nearly as fun as letting yourself believe it for a while. Let your mind wander, get sucked in, imagine the possibilities, be inspired. Wouldn't it be great if we could see some of the wackier advances in our lifetimes? Hell, I'd settle for just the toy soldiers.
I have a wireless internet connection at home. A guy came and installed a directional antenna on the roof. He had me ping their gateway and he oriented the antenna while I read ping times to him over a two-way radio.
Well, I wasn't happy with the latency, so later I adjusted the antenna myself. But I didn't have anyone to read ping times to me and I wasn't too thrilled about this method anyway, so I came up with something better.
I wrote a perl script that would ping a host, wait for a reply (or a one second timeout), play a tick sound, and repeat the process. It sounds like a Geiger counter. The more frequent and steady the ticks, the better the connection. Also, every five seconds the script calls Festival to speak the average ping time. So, I get a nice intuitive feel for the connection through the stream of ticks, and a concrete measurement too.
Speakers out the window, full blast. Me on the roof. Neighbours' quizzical faces in the windows:-)
When evaluating new systems, people tend to be critical, and rightly so; implementing the system is costly, and a lot could go wrong.
But I feel that often the risks and costs of the old system are not given as much weight.
Let's take an example. Some years back, an argument raged in my community about a proposed tunnel under a fjord. The tunnel would allow people to get to the other side in 6 minutes instead of following the outline of the fjord for 45 minutes on a narrow, winding, often steep road.
The risks of the the new system, the tunnel, got a lot of press. We were treated to many horrifying predictions, each fit for a disaster movie. The proponents of the tunnel pointed out that while the road does not make a good disaster movie, people regularly die in car crashes on it.
My observasion is that this argument got considerably less recognition than it should have if people had viewed the issue rationally.
In light of this, can we perhaps enrich the discussion on this particular new system (digital signatures) by identifying the risks and costs of the old system (handwritten signatures on paper).
I can see a few.
1) Signatures can be forged. It takes talent, skill and effort to do it well, but only rarely do you need to do it well, because the signature is rarely verified by anyone who actually knows how to do it. (It's not always verified at all. I saw a bogus check hanging in a store once, signed Donald Duck or something like that. The clerk had actually accepted this check as payment.)
2) The piece of paper needs to be in the same place as the signer. This can't always be arranged easily and sometimes people accept the dangerous alternative of doing business with no signature at all (or a weaker version of the digital signature, the pin code).
3) Handwriting recognition can't be automated (or has the software gotten good enough?), with the same results as in point 2 (think ATMs).
I'm thinking of things like online shopping and tax returns at the same time here, but to get a clear picture the applications of signatures should probably be categorized. Also note that I haven't decided in favour of digital signatures. I just want to promote this idea of mine that we should give equal weight to the risks and costs of the system already in place as to the risks and costs of the system being proposed.
In Iceland, I pay slightly more for 256/128, also with a 3GB limit. Fortunately, traffic within the country is unmetered, so if you use local mirrors for everything big, you can get by with a much lower limit.
Sounds like a real champion of animal rights, huh?
Hmm. Please clarify. Do you mean that his statement is wrong and sex with animals does always involve cruelty? Or do you mean that what he said is true, but he shouldn't have said it? In that case, why?
Only the best listeners can tell a 128kbps mp3 from the original? Holy crap, I must be some kind of listening prodigy, because 128kbps mp3's sound like shit to me. Clearly identifiable shit too.
Maybe it's the Sennheisers.
Alright, instead of beating my head against the wall, trying to convince everybody that 128kbps won't cut it, how about I solicit some useful advice just for those of us who need more:
Can Vorbis currently make files that sound about as good as 256kbps mp3's(1) and take less space? Is Vorbis even paying any attention to high bitrate encoding?
1) Which, in my case, is almost the same as cd quality. Very rarely do I hear the difference (one example is the sound of the crowd in the beginning of some tracks on Live Art by Béla Fleck & The Flecktones)
...but you gain absolutely nothing by limiting choice
Yes, you do. Here's an example. I'm looking for a good gui database front-end. You know, the kind of thing you use to design tables, set access permissions, enter sample data, browse, try out queries, etc. Many people have written such tools for Windows and Linux. On Windows, there's basically one variable: the database server. Each tool may or may not work with the database server I'm using. On Linux, there are more variables.
One is the package format/distribution support. Some frontends aren't packaged for Debian so getting them to work on my system is a little harder (I may need to manually satisfy some library dependency or whatever).
Another is the application framework or widget set. One tool uses Gnome, another uses KDE, there's one using Tcl/Tk, and an old one uses Motif. Only some of them really fit my Gnome desktop. I can still use the others, but that's not the point. The point is that one developer has learned Gnome programming and another has learned KDE and they're not ever going to work on the same GUI together. One guy's choice of a desktop has prevented another guy from contributing to the project.
The end result of all this is that I've spent hours browsing freshmeat, downloading software, compiling it, and finding that none of it is really good. (BTW, I'm still looking, so suggestions are welcome.)
I believe choice in software is a good thing, but it's wrong to say that it doesn't come at a price or that the alternative has no merits at all.
I can't think of any "useful everyday" uses, but surely a lot of different people have a lot of different ideas about what to do with a supercomputer.
When I was a kid I played with particle systems. I'd set up a cloud of particles with mass and/or electrical charge and see how their simple interactions created large-scale behaviour. It was a simple system that didn't scale well (I made some attempt to break the space up into cubes and treat the contents of far away cubes as one particle, but it wasn't a seamless transition). Even with the limited number of particles I could play with (a few hundred), I still saw a lot of interesting things happen, like the material breaking up into 2 or 3 separate clusters. If I had oodles of CPUs, I'd enjoy figuring out good ways to split the load between them.
In today's society (those societies whose members waste time on Slashdot, anyway), life isn't just about making a living. So in essence, these machines can be used for having fun, which is a good enough reason to make them.
P.S. It's no reason to build a cluster, but if SETI@home doesn't turn you on, perhaps Folding@home will.
Not that he's necessarily correct, but he does address that argument:
Another common criticism is that by simply shooting low-level clerks in department stores, we don't get to the true perpetrators of surveillance in higher places. Nothing could be further from the truth. Shooting at low level clerks creates a problem they can't deal with. The clerks then get their managers. The managers see the problem, and very quickly the matter escalates to head-office. The quickest way to get to speak with a manager is to photograph the low-level clerks. You get to speak to a manager much faster than if you merely ask to speak to a manager (in which case they often lie and claim that the manager is not present, or is in a meeting).
A novel solution, if I ever heard one. No-one dies -> everyone lives forever -> eventually everyone's familiar with how the system works and uses it comfortably
When I was a kid, I spent countless hours browsing through a big book of WWII planes. In the "funny looking" category, I certainly remember the Me-163, but I always found the Dornier Do-335 "Pfeil" even more fascinating.
They could attach a mic to this gizmo and listen for clicks.
As someone who routinely works with large datasets, you might want to learn to spell "terabyte". ;-)
Actually, if my memory is correct, 3com shouldn't even have gotten 3com.com. Before some date, domain names were not allowed to start with a digit. I seem to recall reading rules to that effect from an ostensibly authoratative and current source long after 3com.com came to be.
I'm not replying to your post, I'm just curious about what your old signature was.
;-)
But really, the reason most slashdotters dislike software modems is not just that they steal a few cpu cycles from quake3, but that a) they do it in a closed source driver and b) the manufacturer often doesn't bother to tell you that you're getting less of a modem.
If you take those problems out of the picture, offloading part of a device's function to the CPU can be a good thing. Stuff that was being done in a chip with no published specs can be done in free software. If the main computer is capable enough (processing speed, bus bandwidth), then why not replace all sorts of modems, radio/tv cards, etc. with software?
All these things eventually boil down to the same thing: one or more wires get connected to the computer and a signal is read or generated on those wires. It would be pretty cool if computers just had a multitude of physical connectors and you could address each pin of each of them. You get a new internet connection (ISDN, ADSL, cable, some kind of wireless thing) and you just plug the cable into the computer and download the appropriate module. HDTV transmissions become available in your area? Just download the module and sign up!
Practical issues aside (like whether today's computers could actually handle all this), I think more of this development is a good thing. Just think of how long Linux users (let alone users of more obscure systems) often have to wait for good drivers for radio/tv tuners to become available because driver developers have to understand each device's undocumented and unique interface, and then consider that the signals these devices are receiving are all well understood, unchanging, and even regulated by government!
I'm aware of the technique of putting a vertical grating on top of a screen to block every other line from each eye, then drawing the right eye image on the odd lines and the left eye image on the even ones, creating a 3D image. You seem to be talking about something like that, with the front monitor taking over the role of the grating. In that case, I think "This is the difficult part!" is an understatement. Can you explain further? Or are you talking about a different principle?
That's not enough. It's not an April fool's gag unless the people taken in actually go somewhere, do something, or call someone as a result. And while visiting a site might technically qualify, it's pretty damn weak. At least Linus's post to lkml required you to email him. Still weak, but better.
Hey, we did that in physics class once. It wasn't a skateboard, it was one of those little carts you do momentum displays with, but there was a fan blowing into a sail (actually a stiff board) and we were supposed to guess what would happen. It moved toward the sail side.
LOL
Once again, I'd like to recommend our viewers watch something else.
Now, I have only a superficial acquaintance with MacOS, but it seems to me that the applescript interpreter can be used by an attacker in many of the same ways that /bin/sh can be used. The Chooser can't be called with commandline paramaters, but do you know if it has an AppleScript interface? (I don't.)
But pointing that out isn't nearly as fun as letting yourself believe it for a while. Let your mind wander, get sucked in, imagine the possibilities, be inspired. Wouldn't it be great if we could see some of the wackier advances in our lifetimes? Hell, I'd settle for just the toy soldiers.
I have a wireless internet connection at home. A guy came and installed a directional antenna on the roof. He had me ping their gateway and he oriented the antenna while I read ping times to him over a two-way radio.
:-)
Well, I wasn't happy with the latency, so later I adjusted the antenna myself. But I didn't have anyone to read ping times to me and I wasn't too thrilled about this method anyway, so I came up with something better.
I wrote a perl script that would ping a host, wait for a reply (or a one second timeout), play a tick sound, and repeat the process. It sounds like a Geiger counter. The more frequent and steady the ticks, the better the connection. Also, every five seconds the script calls Festival to speak the average ping time. So, I get a nice intuitive feel for the connection through the stream of ticks, and a concrete measurement too.
Speakers out the window, full blast. Me on the roof. Neighbours' quizzical faces in the windows
But I feel that often the risks and costs of the old system are not given as much weight.
Let's take an example. Some years back, an argument raged in my community about a proposed tunnel under a fjord. The tunnel would allow people to get to the other side in 6 minutes instead of following the outline of the fjord for 45 minutes on a narrow, winding, often steep road.
The risks of the the new system, the tunnel, got a lot of press. We were treated to many horrifying predictions, each fit for a disaster movie. The proponents of the tunnel pointed out that while the road does not make a good disaster movie, people regularly die in car crashes on it.
My observasion is that this argument got considerably less recognition than it should have if people had viewed the issue rationally.
In light of this, can we perhaps enrich the discussion on this particular new system (digital signatures) by identifying the risks and costs of the old system (handwritten signatures on paper).
I can see a few.
1) Signatures can be forged. It takes talent, skill and effort to do it well, but only rarely do you need to do it well, because the signature is rarely verified by anyone who actually knows how to do it. (It's not always verified at all. I saw a bogus check hanging in a store once, signed Donald Duck or something like that. The clerk had actually accepted this check as payment.)
2) The piece of paper needs to be in the same place as the signer. This can't always be arranged easily and sometimes people accept the dangerous alternative of doing business with no signature at all (or a weaker version of the digital signature, the pin code).
3) Handwriting recognition can't be automated (or has the software gotten good enough?), with the same results as in point 2 (think ATMs).
I'm thinking of things like online shopping and tax returns at the same time here, but to get a clear picture the applications of signatures should probably be categorized. Also note that I haven't decided in favour of digital signatures. I just want to promote this idea of mine that we should give equal weight to the risks and costs of the system already in place as to the risks and costs of the system being proposed.
In Iceland, I pay slightly more for 256/128, also with a 3GB limit. Fortunately, traffic within the country is unmetered, so if you use local mirrors for everything big, you can get by with a much lower limit.
Hmm. Please clarify. Do you mean that his statement is wrong and sex with animals does always involve cruelty? Or do you mean that what he said is true, but he shouldn't have said it? In that case, why?
Maybe it's the Sennheisers.
Alright, instead of beating my head against the wall, trying to convince everybody that 128kbps won't cut it, how about I solicit some useful advice just for those of us who need more:
Can Vorbis currently make files that sound about as good as 256kbps mp3's(1) and take less space? Is Vorbis even paying any attention to high bitrate encoding?
1) Which, in my case, is almost the same as cd quality. Very rarely do I hear the difference (one example is the sound of the crowd in the beginning of some tracks on Live Art by Béla Fleck & The Flecktones)
Dude, get a felt tip pen and draw one on your monitor.
Yes, you do. Here's an example. I'm looking for a good gui database front-end. You know, the kind of thing you use to design tables, set access permissions, enter sample data, browse, try out queries, etc. Many people have written such tools for Windows and Linux. On Windows, there's basically one variable: the database server. Each tool may or may not work with the database server I'm using. On Linux, there are more variables.
One is the package format/distribution support. Some frontends aren't packaged for Debian so getting them to work on my system is a little harder (I may need to manually satisfy some library dependency or whatever).
Another is the application framework or widget set. One tool uses Gnome, another uses KDE, there's one using Tcl/Tk, and an old one uses Motif. Only some of them really fit my Gnome desktop. I can still use the others, but that's not the point. The point is that one developer has learned Gnome programming and another has learned KDE and they're not ever going to work on the same GUI together. One guy's choice of a desktop has prevented another guy from contributing to the project.
The end result of all this is that I've spent hours browsing freshmeat, downloading software, compiling it, and finding that none of it is really good. (BTW, I'm still looking, so suggestions are welcome.)
I believe choice in software is a good thing, but it's wrong to say that it doesn't come at a price or that the alternative has no merits at all.
When I was a kid I played with particle systems. I'd set up a cloud of particles with mass and/or electrical charge and see how their simple interactions created large-scale behaviour. It was a simple system that didn't scale well (I made some attempt to break the space up into cubes and treat the contents of far away cubes as one particle, but it wasn't a seamless transition). Even with the limited number of particles I could play with (a few hundred), I still saw a lot of interesting things happen, like the material breaking up into 2 or 3 separate clusters. If I had oodles of CPUs, I'd enjoy figuring out good ways to split the load between them.
In today's society (those societies whose members waste time on Slashdot, anyway), life isn't just about making a living. So in essence, these machines can be used for having fun, which is a good enough reason to make them.
P.S. It's no reason to build a cluster, but if SETI@home doesn't turn you on, perhaps Folding@home will.
A friend of mine solved that problem. He got a desk lamp and placed it above his mouse mat.
Another common criticism is that by simply shooting low-level clerks in department stores, we don't get to the true perpetrators of surveillance in higher places. Nothing could be further from the truth. Shooting at low level clerks creates a problem they can't deal with. The clerks then get their managers. The managers see the problem, and very quickly the matter escalates to head-office. The quickest way to get to speak with a manager is to photograph the low-level clerks. You get to speak to a manager much faster than if you merely ask to speak to a manager (in which case they often lie and claim that the manager is not present, or is in a meeting).
A novel solution, if I ever heard one. No-one dies -> everyone lives forever -> eventually everyone's familiar with how the system works and uses it comfortably
The author's name is Viðar, not Viar.
That squiggly little character is an eth, coded in HTML as ð. When you can't type it, a "d" is a suitable replacement.
At least you're free to ignore his ramblings.
When I was a kid, I spent countless hours browsing through a big book of WWII planes. In the "funny looking" category, I certainly remember the Me-163, but I always found the Dornier Do-335 "Pfeil" even more fascinating.