The point is, 'complete and total freedom for the individual' is not in the best interests of the majority of individuals. The richest and most-powerful indivuduals tend to get richer and more powerful, taking wealth and power away from the little guy.
The laws we have in place now, and what is being proposed here, are designed to put a 'cap' on power and wealth so that the little guy does not get taken advantage of.
One of the first products I can see coming out of this event is little EMP generators that allow you to detect, then blow the living daylight out of the RF circuitry in these things. Remember... any good transmitter is a good receiver, too... find the resonant frequency of this receiver, and you can pump enough energy into it to melt the traces.
It's amazing what the little-recognised Small Office-Home Office sector can come up with, eh? We're a power to be reckoned with! Now... give us some cheap colour laser-printers, dammit!
Okay, okay. I didn't read the article properly first time through. This is multipath from antennae at the same location, not from antennae at different locations. Mod -1, Dumbass:)
This isn't exactly scalable.
on
Reflections
·
· Score: 1, Interesting
What they're proposing is a method of using channels from adjoining (or not so adjoining) cells to improve bandwidth, making the assumption that the adjoining cells has bandwidth to spare. Now, if you're having trouble getting a call through on your EXISTING cell (or data connection, or whatever), what makes you think that stealing bandwidth from adjoining, likely equally-congested, cells is going to help?
Prop Cycle was probably the first 'work hard' video game I ever played. I thought it was great... and I was the only one that played decently in my groupoffriends: I bicycle a lot, and have the stamina for it:)
I personally believe this is not true, so I'd like you to back up your statement with some facts.
(Yuu can just imagine how it could be abused. A prosecutor delays investigation for the sole purpose of extending SOL... nah... I can't see it happening)
These things had better be more reliable than those horrible, horrible CastlewoodORBDrives That were 'all the rage' a few years ago. The disks and/or drives were immensly unreliable. Strangely more so under Linux. The company has already gone out of business (www.castlewood.com doesn't even resolve anymore).
No, all he said was that there were disks marked 'import', but not import prices. Perhaps they put that sticker there to 'explain' the lack of other material, such as a book, or the correct printing on the disk.
'surface noise'. Ah, so... they just detected a fault at QC time, and i'm buying the factory rejects. Thats right!;)
The concept of 'having data that you cannot legally access' has been around for ages already: Adobe Type-On-Call (Not sold anymore, as far as I can tell.)
This was a CD full of fonts - Adobe's entire font library, in fact - where you could not access particular fonts or font collections without sending Adobe a bunch of money first. They'd give you a key to unlock those particular fonts.
I'd been wanting to try and crack it open ever since I was 15 or so, but... looks like I'm not allowed to anymore:)
I agree that it sucks that they've changed their voicemail system so that it takes longer to get to the information you need. I've only just switched to Sprint myself, so I don't know what the old system was like... the new one seems to be okay to me.
However, the really nice feature is that Sprint don't change a cent to get access to voicemail. No airtime, no extra fee, nada! That, I thought, was really nice. So... the extra time to wade through voicemail is just an inconvenience, rather than a revenue generator.
On the assumption that you can't concentrate a 802.11 signal strong enough to punch through the brick walls...
I seriously doubt the roof is made of brick, too:) Assuming that the rooves are slanted, it would be no effort to put a high-gain (directed) antennae in the roofs to point to one or two other buildings. It might even be possible to use omni-directional antenna, and cut down on the number of antennae needed.
There are also 802.11 amplifiers available. In the US, you're allowed to pump them up to 1W before the FCC come knocking. That should be plenty, even with an omnidirectional rather than directional amtenna.
That's what I originally thought, too. But the story title is a typo: They're talking about 150MegaBytes/sec, not bits.
The next version of firewire on the horizon will only be able to do 100Megabytes/sec (800Megabits/sec).
Still, I'd much rather they dump Serial ATA altogether and concentrate on FireWire. 100Megabytes/sec is just plenty, and FireWire is a much more general and flexible standard.
I've been onto their particular game for about half a year now, as evidenced in a warning I wrote here.
In general, you should never give anyone's email address out. Ie, treat it like a phone number; it's not yours to give out, it's the owner's.
I treat the 'send this to a friend' thing in the same way. If you read the privacy statements of a lot of web sites, you'll see that it refers to your privacy, but doesn't mention anything about the privacy of your friends' email addresses that you happen to type into those 'send this to a friend' boxes.
According to the TCPA (Telephone Consumer Protection Act), it is illegal for a business to dial mobile phone numbers for unsolicited telemarketing. Unless there are some weird circumstances on how they got hold of your phone number, you've just earned yourself $500-$1500. Congratulations! You now just need to figure out how to claim it:)
A good resource for this kind of thing is Junkbusters
Actually, I wouldn't object to all my devices connected via ethernet, either. That would be kinda cool:) There's several neat things that Firewire addresses that would also need to be addressed with using Ethernet (all of which are doable):
- Firewire sends power down it's cable, if the device wants it.
- Firewire establishes a protocol for identifying devices and their capabilities
- Firewire defines protocols for several device classes.
- The time between connecting and usability is very small with firewire. (The negotiation period for Gigabit ethernet can be several sections.)
So, I agree that we could very well have used Ethernet instead of Firewire. When Firewire first came out, it addressed several issues that Ethernet could not (such as >100Mbps). Ethernet's certainly caught up in the speed regard, but Firewire was already established at that time... so... there's probably no need to go back to ethernet now, and there's certainly no need to add another standard on top of the current peripheral standards (FireWire and... (ugh) USB 2.0).
And... I certainly wouldn't complain about a 25c/device licensing fee, if it means i get greater interoperability.
Well, given that you need a special drive, and a special controller, for this to work anyway, I really don't see the problem.
Many firewire drives now are simply ATA drives with a bridge chip. Granted, a ATA to Serial/ATA bridge chip is going to be a lot simpler, given that it's likely simply going to be a transport converter, rather than a protocol converter. However, my point still stands: why not use FireWire and develop on that, since it's already established, already very useful.
Can someone explain to me the advantages of Serial/ATA over FireWire?
FireWire currently does all these things that Serial/ATA is promising, and there's even speed increases in the works. It would be really nice if PC motherboards started shipping with internal and external firewire ports as standard, and it would mean we'd start seeing native firewire external HDDs a lot sooner.
The main thing stopping you sending fast signals down parallel cables is transmission line problems. At high speeds, any wire effectively becomes a transmission line.
It's much MUCH easier to get just one wire right for super high speed data than it is to get 8/16/32 wires right. There's also the issue of ensuring that all the signals arrive at the destination at the same time.
So, technically, parallel is faster, but serial is much easier to get going real fast.
The spam does not eat up bandwidth, nor chew up mailbox space, because the 'spamcop method' of filtering email means the mail is blocked before the data portion is received. Ie, its 'sending IP' based, rather than content based.
I use Spamcop to filter my incomming mail at the MTA level, and I've been exceedingly happy with it. Apart from one or two that 'slip through', the only spam I receive nowdays comes through MTAs I have no control over.
Quick brief on how it works. There are two portions:
- Reporting tool, that allows you to forward spam to SpamCop for analysis. This will pick apart the headers and body, find out where the spam originated from (even if it's gone through legitimate relays and aliasing systems, such as mailing lists), and will send complaints to the relevant owners of the IP block owners, MTAs and web sites. It does a VERY good job of figuring out who's responsible.
- Blocking tool that uses a RBL-style blocking list, which lists IP addresses of spam originators. If enough spam gets reported within 24 hours, the IP sending the spam gets added to the list. You can use this to block addresses where spam has originated from so you dont even receive the spam. People get their IP addresses unblocked only if spam stops being sent from that IP.
The system is very good. It relies on you and others reporting spam to SpamCop in a very workable collaberative effort.
That's not true. Spamcop's blocking algoritms work on a RBL-style blacklist, based on IP address of the spammer. Spamassassin uses pattern matching to determine if the spam being received is likely spam and either marking it as such in the headers (so you can procmail it out), or throwing it away. With spamcop, the mail gets rejected even before the DATA portion of the mail.
Slashdot Mirror
The point is, 'complete and total freedom for the individual' is not in the best interests of the majority of individuals. The richest and most-powerful indivuduals tend to get richer and more powerful, taking wealth and power away from the little guy.
The laws we have in place now, and what is being proposed here, are designed to put a 'cap' on power and wealth so that the little guy does not get taken advantage of.
One of the first products I can see coming out of this event is little EMP generators that allow you to detect, then blow the living daylight out of the RF circuitry in these things. Remember... any good transmitter is a good receiver, too... find the resonant frequency of this receiver, and you can pump enough energy into it to melt the traces.
Instant privacy.
It's amazing what the little-recognised Small Office-Home Office sector can come up with, eh? We're a power to be reckoned with! Now... give us some cheap colour laser-printers, dammit!
Okay, okay. I didn't read the article properly first time through. This is multipath from antennae at the same location, not from antennae at different locations. Mod -1, Dumbass :)
What they're proposing is a method of using channels from adjoining (or not so adjoining) cells to improve bandwidth, making the assumption that the adjoining cells has bandwidth to spare. Now, if you're having trouble getting a call through on your EXISTING cell (or data connection, or whatever), what makes you think that stealing bandwidth from adjoining, likely equally-congested, cells is going to help?
Prop Cycle was probably the first 'work hard' video game I ever played. I thought it was great... and I was the only one that played decently in my groupoffriends: I bicycle a lot, and have the stamina for it :)
References, please.
I personally believe this is not true, so I'd like you to back up your statement with some facts.
(Yuu can just imagine how it could be abused. A prosecutor delays investigation for the sole purpose of extending SOL... nah... I can't see it happening)
These things had better be more reliable than those horrible, horrible Castlewood ORB Drives That were 'all the rage' a few years ago. The disks and/or drives were immensly unreliable. Strangely more so under Linux. The company has already gone out of business (www.castlewood.com doesn't even resolve anymore).
No, all he said was that there were disks marked 'import', but not import prices. Perhaps they put that sticker there to 'explain' the lack of other material, such as a book, or the correct printing on the disk.
;)
'surface noise'. Ah, so... they just detected a fault at QC time, and i'm buying the factory rejects. Thats right!
The concept of 'having data that you cannot legally access' has been around for ages already: Adobe Type-On-Call (Not sold anymore, as far as I can tell.)
:)
This was a CD full of fonts - Adobe's entire font library, in fact - where you could not access particular fonts or font collections without sending Adobe a bunch of money first. They'd give you a key to unlock those particular fonts.
I'd been wanting to try and crack it open ever since I was 15 or so, but... looks like I'm not allowed to anymore
Good point. That's an interpretation I did not conjecture.
However, the really nice feature is that Sprint don't change a cent to get access to voicemail. No airtime, no extra fee, nada! That, I thought, was really nice. So... the extra time to wade through voicemail is just an inconvenience, rather than a revenue generator.
On the assumption that you can't concentrate a 802.11 signal strong enough to punch through the brick walls...
:) Assuming that the rooves are slanted, it would be no effort to put a high-gain (directed) antennae in the roofs to point to one or two other buildings. It might even be possible to use omni-directional antenna, and cut down on the number of antennae needed.
I seriously doubt the roof is made of brick, too
There are also 802.11 amplifiers available. In the US, you're allowed to pump them up to 1W before the FCC come knocking. That should be plenty, even with an omnidirectional rather than directional amtenna.
That's what I originally thought, too. But the story title is a typo: They're talking about 150MegaBytes/sec, not bits.
The next version of firewire on the horizon will only be able to do 100Megabytes/sec (800Megabits/sec).
Still, I'd much rather they dump Serial ATA altogether and concentrate on FireWire. 100Megabytes/sec is just plenty, and FireWire is a much more general and flexible standard.
I've been onto their particular game for about half a year now, as evidenced in a warning I wrote here.
In general, you should never give anyone's email address out. Ie, treat it like a phone number; it's not yours to give out, it's the owner's.
I treat the 'send this to a friend' thing in the same way. If you read the privacy statements of a lot of web sites, you'll see that it refers to your privacy, but doesn't mention anything about the privacy of your friends' email addresses that you happen to type into those 'send this to a friend' boxes.
According to the TCPA (Telephone Consumer Protection Act), it is illegal for a business to dial mobile phone numbers for unsolicited telemarketing. Unless there are some weird circumstances on how they got hold of your phone number, you've just earned yourself $500-$1500. Congratulations! You now just need to figure out how to claim it :)
A good resource for this kind of thing is Junkbusters
Actually, I wouldn't object to all my devices connected via ethernet, either. That would be kinda cool :) There's several neat things that Firewire addresses that would also need to be addressed with using Ethernet (all of which are doable):
- Firewire sends power down it's cable, if the device wants it.
- Firewire establishes a protocol for identifying devices and their capabilities
- Firewire defines protocols for several device classes.
- The time between connecting and usability is very small with firewire. (The negotiation period for Gigabit ethernet can be several sections.)
So, I agree that we could very well have used Ethernet instead of Firewire. When Firewire first came out, it addressed several issues that Ethernet could not (such as >100Mbps). Ethernet's certainly caught up in the speed regard, but Firewire was already established at that time... so... there's probably no need to go back to ethernet now, and there's certainly no need to add another standard on top of the current peripheral standards (FireWire and... (ugh) USB 2.0).
And... I certainly wouldn't complain about a 25c/device licensing fee, if it means i get greater interoperability.
Well, given that you need a special drive, and a special controller, for this to work anyway, I really don't see the problem.
Many firewire drives now are simply ATA drives with a bridge chip. Granted, a ATA to Serial/ATA bridge chip is going to be a lot simpler, given that it's likely simply going to be a transport converter, rather than a protocol converter. However, my point still stands: why not use FireWire and develop on that, since it's already established, already very useful.
8) Favoring Big Guys
:)
by PenguinRadio
Does google's policy of "ranking" the sites that have hits favor the "big guys" over more specific smaller traffic websites?
I can certainly vouch for Craig's response. My own site comes up as #1, and it's only three letters
That should be:
"I send you this file in order to have your advice".
Or, perhaps it should be:
"All your base are belong to this file I send in order to have your advice."
Can someone explain to me the advantages of Serial/ATA over FireWire?
FireWire currently does all these things that Serial/ATA is promising, and there's even speed increases in the works. It would be really nice if PC motherboards started shipping with internal and external firewire ports as standard, and it would mean we'd start seeing native firewire external HDDs a lot sooner.
Do we really need ANOTHER standard ?
The main thing stopping you sending fast signals down parallel cables is transmission line problems. At high speeds, any wire effectively becomes a transmission line.
It's much MUCH easier to get just one wire right for super high speed data than it is to get 8/16/32 wires right. There's also the issue of ensuring that all the signals arrive at the destination at the same time.
So, technically, parallel is faster, but serial is much easier to get going real fast.
The spam does not eat up bandwidth, nor chew up mailbox space, because the 'spamcop method' of filtering email means the mail is blocked before the data portion is received. Ie, its 'sending IP' based, rather than content based.
I use Spamcop to filter my incomming mail at the MTA level, and I've been exceedingly happy with it. Apart from one or two that 'slip through', the only spam I receive nowdays comes through MTAs I have no control over.
Quick brief on how it works. There are two portions:
- Reporting tool, that allows you to forward spam to SpamCop for analysis. This will pick apart the headers and body, find out where the spam originated from (even if it's gone through legitimate relays and aliasing systems, such as mailing lists), and will send complaints to the relevant owners of the IP block owners, MTAs and web sites. It does a VERY good job of figuring out who's responsible.
- Blocking tool that uses a RBL-style blocking list, which lists IP addresses of spam originators. If enough spam gets reported within 24 hours, the IP sending the spam gets added to the list. You can use this to block addresses where spam has originated from so you dont even receive the spam. People get their IP addresses unblocked only if spam stops being sent from that IP.
The system is very good. It relies on you and others reporting spam to SpamCop in a very workable collaberative effort.
http://spamcop.net/
That's not true. Spamcop's blocking algoritms work on a RBL-style blacklist, based on IP address of the spammer. Spamassassin uses pattern matching to determine if the spam being received is likely spam and either marking it as such in the headers (so you can procmail it out), or throwing it away. With spamcop, the mail gets rejected even before the DATA portion of the mail.