First, I understand the "paranoid" desire to encrypt everything, everwhere, but I prefer to be realistic. I really don't care if people want to watch everything I do -- it might be a little embarassing, but it's not going to cause nations to fail. That being said...
Walking into an office and plugging yourself into an ethernet port is "latching oneself into the cable plant." There aren't many offices (relatively speaking) where one could just walk in and plug into the ethernet. I always made sure conference rooms, and the like, were connected to (monitored) switched ports that were disabled when not in use. I also never let non-employees plug things into non-switched ports -- unless they are bound by an NDA.
I understand the arguement for one universal solution, but I don't think it should be unconditionally applied. Should every URL begin https://? I say no. Very little network traffic genuinely deserves to be scrambled. On one hand, this is pure paranoia. On the other, it's a pointless protest against "The Man" (be that government(s), large corporations, your boss, or that guy down the street who looked at you funny last year.)
I can offer a suggestion on the effects of the sword... Most holographic projection systems in the real world use lasers. We'll have to apply the Hollywood Filter (tm) and say they were using high powered (visable?) lasers -- which I admit is a real damned bad idea:-) The apparent lack of blood supports this.
While that _can_ explain the broadsword, it does nothing to explain the effects of the flintlock.
Note: in ST:TNG, their holograms are light held in a force field (magnetic?) The force field is what presents the danger -- and the fact of matter/energy conversion [holodeck matter won't maintain molecular cohesion outside the holodeck.]
The prevailing theory I've always heard suggests that the body's perception of death (in a dream or whatever) results in neuro-chemical shock usually ending in a heart attack and death. But we cannot exactly go ask dead people if this is true:-)
I'm thinking the encryption is not so much to protect the information "end to end" but to protect the "over the air where bad people can hear it without me being able to stop them." Intercepting a wired communication is much more difficult that that of a radio transmission. Additionally, the wireless traffic is generally going to be "local" traffic.
For example, someone places a wireless network behind their corp. firewall so the workers can use laptops around the office -- or place a printer where there's no drop, whatever. This is traffic you certainly don't want the rest of the world to be able to access or even observe. Latching oneself into the cable plant would be far harder than driving through the parking lot with a receiver in the trunk...
Just a guess, but maybe the new card powered up in 11Mbit mode. It's certainly not going to be able to talk to a 1MBit card like that. Or maybe it's using a different signalling system.
True, microwave ovens don't mutate your food (much). The microwave frequency is centered on the hydrogen vibration frequency of a water molecule -- the two hydrogen atoms in H2O aren't in a rigid alignment. The microwave energy intensifies the vibration thus heating the substance -- temperature equals average kenetic energy. This has the net effect of driving the water out of most things -- take for example, bread... need I say more?
However, water is not the only "perfect receiver". Sugar also absorbes the microwave energy very well. So well in fact, that the "water" in the sugar can be wrenched out of the sugar molecules leaving behind the carbon. (It's a fun experiment, but I'm not responsible for any damage to your microwave, person, house, pets, etc.)
This brings me to the non-ionizing radiation part... This is true. The microwave signal isn't going to hit a strand of DNA and break it like a gamma ray. However, many of the molecular substances in the human body will absorb microwave energy and eventually be damaged. In your example of standing infront of a microwave with the door open, if you stood there long enough, it would blind you. (Of course, if you stood there "too long", your blood would boil and you would subsequently explode -- odds are, you'd already be well on your way to dead by then anyway.)
And the proof is in society. So far,there really aren't any problems. Aside from insane and/or stupid people placing living things (babies, dogs, etc.) in their microwave.
PS: This is also why the 2.4GHz band is unlicensed. Too many things in the environment absorb or otherwise interfere with the signal(s).
Physically, yes. However, that's not all it does. There's good bit of processing inside there. For the simple case of two machines, an "ad-hoc" network is perfectly ok -- both cards talk directly to each other.
In an "infrastructure" network, all the cards talk to an access point. This has the net effect of doubling the range between mobile units. As a mobile unit moves around, it can switch from one AP to another -- which ever one has the best signal, just like a cell phone. With enough access points placed throughout a building, one can move freely about the complex and never lose connectivity.
As I understand from looking at some of the earlier hardware (3 years ago to present), the older hardware (1 and 2 mbit) is/was FHSS -- you could program the hop times on some cards. The new hardware uses DSSS as that's about the only way to get into the higher speeds and ranges at the same power levels.
Every card I've ever been "allowed" *grin* to take apart had Raytheon transmitter components. In fact, they were all OEM Raytheon Raylink adapters. (Breezecom, WebGear, a few "non-companies"...) I don't know what AT&T put in their cards...
[I would caution people thinking wireless is the holy grail... the transmitter may not fry you and your pets, but it can interfere and even in rare cases damage components inside your computer. My breezecom card does interesting things to audio playback and messes up a few VHF channels. (If I look closely, I can see pixel interference on the screen too.)]
Get a clue and stop being so damned paranoid. Machine A has to know machine B's MAC to talk to it. (That's what ARP is all about.) Next thing you're going to suggest is hiding our IP addresses?
First, _WE_ have jobs. That means we have more important things to do than write free software -- no matter how much we may like writing code for Cosm. Second, there are very few core people writing code for Cosm -- and we are actually writing code, not using someone else's stuff (most of DCTI's cores originated outside DCTI. DCTI eventually generated their own 'core' code or optimized the aquired code.)
As for "releas[ing] something", the Cosm development has been open to the public for a year. There's an IRC channel on EFNet, several mailing lists, a web site full of information, and a public cvs tree of the code. I invite you to go look. (the irc channel is #cosm, btw)
Yes, there are weeks that go by when "nothing" happens. We have lives to live and jobs that pay our bills to attend to. Work may be slow at times, but it's never at a full stand-still. There's alot of stuff going on that isn't in the CVS tree (yet) pending some legal wording to prevent people from stealing our work as their own. (Plus there's no point in making it available yet. And before you ask, I'm refering to stats processing code -- extremely fast and efficient. (Blindingly fast compared to the existing DCTI stats.))
My philsophy is that there is no such thing as "bug free". However, there is a distinction to be made where things are supposed to work. This is called "testing" and "verification" in the software industry. In this specific case, DCTI failed to verify proper functionality of sharing buffer between machines -- a published feature, or it used to be.
As I understand it from dB's note, it's not any one client that's broken. The problem is introduced by sharing buffers between different endian machines. Intels will read it's buffers correctly; Sparcs will read it's buffers correctly. HOWEVER, a sparc reading an intel buffer and vice versa will corrupt the counts (and possibly more, but no one has said anything about that.)
There's no way they can point a finger at any specific binary. And in fact, detecting the corruption is not easy -- just how many nodes qualifies as "messed up"?
This is a very bad omen for Distributed.Net. It's taken two years to deploy OGR only to see it broken out of the starting gate. This is a very stupid mistake; one that would not have happened if people had paid attention to their work and tested a supported function (buffer sharing)
Here we are in a code freeze preparing for a 2.4 release and Linus includes a "small" change to the networking structure -- a structure widely deployed, tested, and proven to be functional -- that breaks every network driver in existance and introduces highly untested and possibly unstable code into the tree. I'm all for progress, but now is not the time to be introducing things that break everything. I trust I don't need to quote Linus' on words to this effect.
A word to the one(s) breaking things... you deleted three elements from the network device structure; how hard is it to grep the other drivers and fix what the #^#!%#^ you just broke? Answer: TRIVIAL. I did it in an hour -- and I had to figure out what your were up to.
And while I'm ranting... the last update to the raid code (arounf 2.3.43?) failed to include a file... 'xor.c' so now software raid is broken. Of course, the documentation is four (4) YEARS out-of-date so finding the development patches is out of the question -- in fact, the raidtools on kernel.org haven't been updated in months (Aug 24 1999) YES, programmers are the worst people ever to document anything, but it only takes a few seconds to update a URL in a header.
Actually, U2W tops out at 80MB/s. That's a limitation of the SCSI bus, NOT the PCI bus. And throughput tends to be non-linear as you increase the number of devices on a SCSI bus. I've seen graphs of some controller tests as the number of drives increased -- most controllers started to suck at 5 drives. (Of course, this was several years ago -- long before U2W, LVD, U160, and fiber channel.)
The advantage of 64bit/66MHz PCI is for hardware (read: very large cached) RAID controllers [the Mylex extremRAID 3000 comes to mind] and multiport Gigabit ethernet cards.
Actually, it's alot more complex... This chip is only the physical layer transceiver. A NIC, hub, switch, etc. would also need some form of ethernet controller (something to look at the bits and move bits between ports.) Most switches have more than one multi-gigabit channel on the "backplane" -- called a cross-bar latice (a "switching matrix"). A few years ago, FORE had the fastest switching matrix -- 24 ports all active at 100Mb/s with no measurable performance degradation.
Technology advances fast:-) I've got some glossies from a company making gigabit ethernet switches -- Tantera?? (I'll have to go find those glossies.) I've also seen terabit routers:-) (I'm not going to say from whom as I don't think they've annouced them.)
As for the extra 40m... the cable length is mostly dependant on signal propigation speed. The first bit signaled onto the cable has to have reached the other end of the cable before you transmit the last bit otherwise you could fail to detect a collision. In a direct, full-duplex, node-to-node setup, you can ignore most of the rules <grin> The "we can even go 140m" is a kudoo for their DSP logic/programming.
Umm, yes. Generally, those who use AOL are of sufficiently below average computer intellegence that I would suggest avoiding them. As for recovering from what AOL 5.0 (or just about any windows installer) does, the average user is never going to figure it out -- that's why we have tech support (i.e. helpdesk.) Adding a new DUN entry is trivial; if you cannot do that, return the computer to place of purchase and never again approach a computer. If you are unwilling to call the people who's job is to make sure you can do your job when something doesn't work (and you've tried to figure it out,) then you're an idiot.
Every organization has system support staff. Rarely is it their problem to keep your family computer working right. If you have to work from home, then most places will issue a computer that they manage -- i.e. keep your damned 14 yo away from it.
If you ever work from home, you have your own machine from which to work and don't let anyone fuck with it. If you work from a common PC, then don't be surprised when something that worked two weeks ago no longer works.
If DeCSS is not a copying tool, then exactly what the hell is it? It copies DVD files to ones hard drive while decrypting them. It doesn't "output [them] directly to the viewscreen..."; it puts them on your hard drive where anything can mess with them (copy them to other media, convert them to other forms, and even transmit to other people/computers.)
Your "cp" and "cat" commands cannot copy CSS encrypted files off a DVD disk by themselves. Until the disk has been "unlocked" (authentication via CSS), not one damned bit can be read from the disk.
[The CSS authentication process was figured out long before DeCSS ruined everything for everyone. Now even that code will be forbidden -- and that's much more along the lines of interop.]
Exactly how is DeCSS an "interoperablity tool"? This isn't a matter of disassmbling MS Word so StarOffice can read/write Office 2000 files.
When will people realize law is not about right and wrong, or good and bad. It's simply the law. This isn't about copyright violation(s); it's a matter of violating the terms of the DMCA by facilitating copyright violations.
No one has said anything of the kind. You can write as many DVD players as you want. However, you cannot include CSS technology in your player without licensing it from DVD CCA.
1) Why are half of your "support people" installing AOL 5? (don't bother answering that.)
2) If your "support people" are doing "emergency" work, don't you think it would be a good thing for them to have the brain-power to create a DUN entry? (Exactly what do these people support?)
With other planets, you don't have governments complaining about being spied upon. That's the only thing preventing us from doing that right now. (And I'm sure there are highly detailed topographic maps of the earth. They just aren't public knowledge.)
This isn't SETI@Home; NASA isn't going to look for the lander for years. One week worth of data can be processed in a little over two weeks. It would take d.net six months to a year to put DSP capabilites into the client, proxy network, keymaster, and stats. Hell, in the time it would take to even get the Board to decide to do it, NASA would already be done.
Gez, you people never went to school did you? You won't be made to take it off; you'll be made to turn it inside out so the text is no longer (readily) visable.
Slashdot Mirror
First, I understand the "paranoid" desire to encrypt everything, everwhere, but I prefer to be realistic. I really don't care if people want to watch everything I do -- it might be a little embarassing, but it's not going to cause nations to fail. That being said...
Walking into an office and plugging yourself into an ethernet port is "latching oneself into the cable plant." There aren't many offices (relatively speaking) where one could just walk in and plug into the ethernet. I always made sure conference rooms, and the like, were connected to (monitored) switched ports that were disabled when not in use. I also never let non-employees plug things into non-switched ports -- unless they are bound by an NDA.
I understand the arguement for one universal solution, but I don't think it should be unconditionally applied. Should every URL begin https://? I say no. Very little network traffic genuinely deserves to be scrambled. On one hand, this is pure paranoia. On the other, it's a pointless protest against "The Man" (be that government(s), large corporations, your boss, or that guy down the street who looked at you funny last year.)
I can offer a suggestion on the effects of the sword... Most holographic projection systems in the real world use lasers. We'll have to apply the Hollywood Filter (tm) and say they were using high powered (visable?) lasers -- which I admit is a real damned bad idea :-) The apparent lack of blood supports this.
While that _can_ explain the broadsword, it does nothing to explain the effects of the flintlock.
Note: in ST:TNG, their holograms are light held in a force field (magnetic?) The force field is what presents the danger -- and the fact of matter/energy conversion [holodeck matter won't maintain molecular cohesion outside the holodeck.]
The prevailing theory I've always heard suggests that the body's perception of death (in a dream or whatever) results in neuro-chemical shock usually ending in a heart attack and death. But we cannot exactly go ask dead people if this is true :-)
As for being wired to a machine... DUH!
Hmm, anyone got a "Assistant" Unreal skin? muhahaha
I'm thinking the encryption is not so much to protect the information "end to end" but to protect the "over the air where bad people can hear it without me being able to stop them." Intercepting a wired communication is much more difficult that that of a radio transmission. Additionally, the wireless traffic is generally going to be "local" traffic.
For example, someone places a wireless network behind their corp. firewall so the workers can use laptops around the office -- or place a printer where there's no drop, whatever. This is traffic you certainly don't want the rest of the world to be able to access or even observe. Latching oneself into the cable plant would be far harder than driving through the parking lot with a receiver in the trunk...
Just a guess, but maybe the new card powered up in 11Mbit mode. It's certainly not going to be able to talk to a 1MBit card like that. Or maybe it's using a different signalling system.
True, microwave ovens don't mutate your food (much). The microwave frequency is centered on the hydrogen vibration frequency of a water molecule -- the two hydrogen atoms in H2O aren't in a rigid alignment. The microwave energy intensifies the vibration thus heating the substance -- temperature equals average kenetic energy. This has the net effect of driving the water out of most things -- take for example, bread... need I say more?
However, water is not the only "perfect receiver". Sugar also absorbes the microwave energy very well. So well in fact, that the "water" in the sugar can be wrenched out of the sugar molecules leaving behind the carbon. (It's a fun experiment, but I'm not responsible for any damage to your microwave, person, house, pets, etc.)
This brings me to the non-ionizing radiation part... This is true. The microwave signal isn't going to hit a strand of DNA and break it like a gamma ray. However, many of the molecular substances in the human body will absorb microwave energy and eventually be damaged. In your example of standing infront of a microwave with the door open, if you stood there long enough, it would blind you. (Of course, if you stood there "too long", your blood would boil and you would subsequently explode -- odds are, you'd already be well on your way to dead by then anyway.)
And the proof is in society. So far,there really aren't any problems.
Aside from insane and/or stupid people placing living things (babies, dogs, etc.) in their microwave.
PS: This is also why the 2.4GHz band is unlicensed. Too many things in the environment absorb or otherwise interfere with the signal(s).
Physically, yes. However, that's not all it does. There's good bit of processing inside there. For the simple case of two machines, an "ad-hoc" network is perfectly ok -- both cards talk directly to each other.
In an "infrastructure" network, all the cards talk to an access point. This has the net effect of doubling the range between mobile units. As a mobile unit moves around, it can switch from one AP to another -- which ever one has the best signal, just like a cell phone. With enough access points placed throughout a building, one can move freely about the complex and never lose connectivity.
As I understand from looking at some of the earlier hardware (3 years ago to present), the older hardware (1 and 2 mbit) is/was FHSS -- you could program the hop times on some cards. The new hardware uses DSSS as that's about the only way to get into the higher speeds and ranges at the same power levels.
Every card I've ever been "allowed" *grin* to take apart had Raytheon transmitter components. In fact, they were all OEM Raytheon Raylink adapters. (Breezecom, WebGear, a few "non-companies"...) I don't know what AT&T put in their cards...
[I would caution people thinking wireless is the holy grail... the transmitter may not fry you and your pets, but it can interfere and even in rare cases damage components inside your computer. My breezecom card does interesting things to audio playback and messes up a few VHF channels. (If I look closely, I can see pixel interference on the screen too.)]
Get a clue and stop being so damned paranoid. Machine A has to know machine B's MAC to talk to it. (That's what ARP is all about.) Next thing you're going to suggest is hiding our IP addresses?
First, _WE_ have jobs. That means we have more important things to do than write free software -- no matter how much we may like writing code for Cosm. Second, there are very few core people writing code for Cosm -- and we are actually writing code, not using someone else's stuff (most of DCTI's cores originated outside DCTI. DCTI eventually generated their own 'core' code or optimized the aquired code.)
As for "releas[ing] something", the Cosm development has been open to the public for a year. There's an IRC channel on EFNet, several mailing lists, a web site full of information, and a public cvs tree of the code. I invite you to go look. (the irc channel is #cosm, btw)
Yes, there are weeks that go by when "nothing" happens. We have lives to live and jobs that pay our bills to attend to. Work may be slow at times, but it's never at a full stand-still. There's alot of stuff going on that isn't in the CVS tree (yet) pending some legal wording to prevent people from stealing our work as their own. (Plus there's no point in making it available yet. And before you ask, I'm refering to stats processing code -- extremely fast and efficient. (Blindingly fast compared to the existing DCTI stats.))
My philsophy is that there is no such thing as "bug free". However, there is a distinction to be made where things are supposed to work. This is called "testing" and "verification" in the software industry. In this specific case, DCTI failed to verify proper functionality of sharing buffer between machines -- a published feature, or it used to be.
As I understand it from dB's note, it's not any one client that's broken. The problem is introduced by sharing buffers between different endian machines. Intels will read it's buffers correctly; Sparcs will read it's buffers correctly. HOWEVER, a sparc reading an intel buffer and vice versa will corrupt the counts (and possibly more, but no one has said anything about that.)
There's no way they can point a finger at any specific binary. And in fact, detecting the corruption is not easy -- just how many nodes qualifies as "messed up"?
This is a very bad omen for Distributed.Net. It's taken two years to deploy OGR only to see it broken out of the starting gate. This is a very stupid mistake; one that would not have happened if people had paid attention to their work and tested a supported function (buffer sharing)
Here we are in a code freeze preparing for a 2.4 release and Linus includes a "small" change to the networking structure -- a structure widely deployed, tested, and proven to be functional -- that breaks every network driver in existance and introduces highly untested and possibly unstable code into the tree. I'm all for progress, but now is not the time to be introducing things that break everything. I trust I don't need to quote Linus' on words to this effect.
A word to the one(s) breaking things... you deleted three elements from the network device structure; how hard is it to grep the other drivers and fix what the #^#!%#^ you just broke? Answer: TRIVIAL. I did it in an hour -- and I had to figure out what your were up to.
And while I'm ranting... the last update to the raid code (arounf 2.3.43?) failed to include a file... 'xor.c' so now software raid is broken. Of course, the documentation is four (4) YEARS out-of-date so finding the development patches is out of the question -- in fact, the raidtools on kernel.org haven't been updated in months (Aug 24 1999) YES, programmers are the worst people ever to document anything, but it only takes a few seconds to update a URL in a header.
Actually, U2W tops out at 80MB/s. That's a limitation of the SCSI bus, NOT the PCI bus. And throughput tends to be non-linear as you increase the number of devices on a SCSI bus. I've seen graphs of some controller tests as the number of drives increased -- most controllers started to suck at 5 drives. (Of course, this was several years ago -- long before U2W, LVD, U160, and fiber channel.)
The advantage of 64bit/66MHz PCI is for hardware (read: very large cached) RAID controllers [the Mylex extremRAID 3000 comes to mind] and multiport Gigabit ethernet cards.
Actually, it's alot more complex... This chip is only the physical layer transceiver. A NIC, hub, switch, etc. would also need some form of ethernet controller (something to look at the bits and move bits between ports.) Most switches have more than one multi-gigabit channel on the "backplane" -- called a cross-bar latice (a "switching matrix"). A few years ago, FORE had the fastest switching matrix -- 24 ports all active at 100Mb/s with no measurable performance degradation.
:-) I've got some glossies from a company making gigabit ethernet switches -- Tantera?? (I'll have to go find those glossies.) I've also seen terabit routers :-) (I'm not going to say from whom as I don't think they've annouced them.)
Technology advances fast
As for the extra 40m... the cable length is mostly dependant on signal propigation speed. The first bit signaled onto the cable has to have reached the other end of the cable before you transmit the last bit otherwise you could fail to detect a collision. In a direct, full-duplex, node-to-node setup, you can ignore most of the rules <grin> The "we can even go 140m" is a kudoo for their DSP logic/programming.
So the gist...
Umm, yes. Generally, those who use AOL are of sufficiently below average computer intellegence that I would suggest avoiding them. As for recovering from what AOL 5.0 (or just about any windows installer) does, the average user is never going to figure it out -- that's why we have tech support (i.e. helpdesk.) Adding a new DUN entry is trivial; if you cannot do that, return the computer to place of purchase and never again approach a computer. If you are unwilling to call the people who's job is to make sure you can do your job when something doesn't work (and you've tried to figure it out,) then you're an idiot.
Every organization has system support staff. Rarely is it their problem to keep your family computer working right. If you have to work from home, then most places will issue a computer that they manage -- i.e. keep your damned 14 yo away from it.
If you ever work from home, you have your own machine from which to work and don't let anyone fuck with it. If you work from a common PC, then don't be surprised when something that worked two weeks ago no longer works.
If DeCSS is not a copying tool, then exactly what the hell is it? It copies DVD files to ones hard drive while decrypting them. It doesn't "output [them] directly to the viewscreen..."; it puts them on your hard drive where anything can mess with them (copy them to other media, convert them to other forms, and even transmit to other people/computers.)
Your "cp" and "cat" commands cannot copy CSS encrypted files off a DVD disk by themselves. Until the disk has been "unlocked" (authentication via CSS), not one damned bit can be read from the disk.
[The CSS authentication process was figured out long before DeCSS ruined everything for everyone. Now even that code will be forbidden -- and that's much more along the lines of interop.]
Exactly how is DeCSS an "interoperablity tool"? This isn't a matter of disassmbling MS Word so StarOffice can read/write Office 2000 files.
When will people realize law is not about right and wrong, or good and bad. It's simply the law. This isn't about copyright violation(s); it's a matter of violating the terms of the DMCA by facilitating copyright violations.
No one has said anything of the kind. You can write as many DVD players as you want. However, you cannot include CSS technology in your player without licensing it from DVD CCA.
Ok...
1) Why are half of your "support people" installing AOL 5? (don't bother answering that.)
2) If your "support people" are doing "emergency" work, don't you think it would be a good thing for them to have the brain-power to create a DUN entry? (Exactly what do these people support?)
With other planets, you don't have governments complaining about being spied upon. That's the only thing preventing us from doing that right now. (And I'm sure there are highly detailed topographic maps of the earth. They just aren't public knowledge.)
This isn't SETI@Home; NASA isn't going to look for the lander for years. One week worth of data can be processed in a little over two weeks. It would take d.net six months to a year to put DSP capabilites into the client, proxy network, keymaster, and stats. Hell, in the time it would take to even get the Board to decide to do it, NASA would already be done.
Gez, you people never went to school did you? You won't be made to take it off; you'll be made to turn it inside out so the text is no longer (readily) visable.
First, it's "DVD CCA" ... CSS is an algorythm; DVD CCA is the organization.
DVD CCA is a non-profit organization which by definition means they do not make money.
And it's IIS 3.0 at that...
(Yes, my NT box is running 3.0 too, but it ain't accessable outside my living room.)