I find that short-sighted and offensive. I do not recall ever having down voted a post because of my beliefs on the subject matter.
Sigh. Anecdote is not the singular of data. While there are certainly good, effective moderators -- I'm one of them, for whatever good it does -- the majority are not, and the evidence -- in the form of lots and lots of data -- is in the veritable reams of high-quality, 0-rated anonymous posts that remain at zero, the well stated but contrary opinions on climate change, linux viability, Apple policies and so on and so on that get down-rated.
This post will get modded down because it is entirely individual, insightful, conflicts with herd-think and does not massage egos with a straight-forward conclusion that supports an already established and unfounded viewpoint.
It starts out modded down because your anonymous status is incorrectly conflated with low value by the site's basic posting and default reading mechanisms.
It's correct. Slashdot's moderators routinely downrate good posts on the basis of "disagree", and the system itself hides good conversations, muzzles the moderators, incorrectly presumes anonymity is a bad thing for posts (wrong), while assuming anonymity is a good thing for moderators (wrong again), and does nothing effective about moderation abuse. The best thing you can say about it is that it can be ignored if you properly configure your browsing options. By far the best way to read slashdot is at -1. I've been doing it for years.
I wasn't complaining about high speed. Network speeds have been improving. We had 10. Then 10/100. Then 10/100/1000. I doubt it'll stop there. Might go optical or something, but it'll still probably be TCP for a while.
My objection is to the raving mess that is USB when it's looked at from a multi-platform perspective, and I think there are advantages to network connected devices that USB really can't touch anyway over and beyond cross platform compatibility.
I write multi-platform software that utilizes some fairly dense data streams. Some of the devices are USB; some are Ethernet.
For the curious, it's software defined radio; it's not unusual to see 16-bit data at 4 MHz coming in across the interface, which is a 64 Mb/s load, doable, but heavy, for a 100 Mb/s connection. There are devices that do 18 MHz at 16 bits. That can take up a considerable portion of a 1 Gb connection - 288 Mb/s. Day to day on my machine, I work with 800 kHz 16 bit data, or about 12 Mb/s for a 400 kHz receive bandwidth. All of these add some overhead on top of the main data stream too, as does TCP itself, so really, the loads are heavier.
Ethernet support basically has to be written once. How networking operates can be abstracted to be the same across OSX, linux, and Windows without much effort at all (Qt does this), and the TCP network stack is generally pretty fast and well behaved. And it is stable. (I could insert a rant about Apple's half-assed UDP support here, but...)
USB support varies considerably from one platform to another. Abstracting it is a huge PITA, requires lots of conditional compilation, and doesn't turn out that well, either. And that's without dealing with new USB drivers coming from the OS manufacturer that overwrite (and break) previously installed drivers. Nothing as fun as a user telling me "everything was working, now nothing is."
It's to the point where I won't directly support new USB SDRs. Every one I've done so far has added to my support load; whereas adding a new network-based SDR is painless, works the day I release it, and is still working a year later. In fact, if they adhere to the established SDR networking protocols, I don't even have to do *anything*, it'll just work. When someone asks me to support a new USB SDR, I tell them to write a network server for it using the established networking protocols. That way, when the USB breaks, as it seems it inevitably will, it's the responsibility, and support load, of the network server author, rather than mine.:)
It's also worth noting that as networking speeds have gone up, previous networking devices still work, and the new ones can crank pretty fast.
Then we get to remote issues; how far can you place a USB device from the computer that's talking to it? How about firewire or Thunderbolt? Now consider Ethernet. I can run an SDR that is quite a bit more distant from my computer, and I don't really have to do much to make that happen. I can have a bunch of them on the same subnet or even remote them out in the world. And then there's sharing. Same device, no reconfiguration, I can use it from OSX or Windows or linux without it even knowing that's happening. I can even go wireless transparently. I routinely sit on the couch and surf the HF and VHF bands on my laptop using WIFI as the data transport from the SDRs.
For any device that can manage it and still obtain acceptable performance, Ethernet looks like an excellent solution to me. If you really must have bus-like speeds, as in graphics engines and SSDs, ok, fine, Thunderpants, Displaypunt, Firepliers, etc. But please, if you're designing a peripheral with any kind of lesser bandwidth requirements, consider Ethernet as your interface. Everything is so much easier to deal with.
I wrote this "nowcast" application to keep me up to date on sky, planetary, and auroral conditions. Since my dark spot is about ten minutes from my home, I can get right to it in a timely manner.
How about, don't ride your totally unsafe, flimsy, difficult to see, acceleration-poor, crumple-bait bicycle on the same pavement with high powered, extremely heavy vehicles?
That will reduce biking accidents. Of course, it also requires common sense, and that... that... oh, right. Right. WTF am I thinking.
Maybe stick to actual bike paths? What, not enough bike paths? After all, lack of appropriate, safe paths doesn't stop me from driving my powered barstool or Riverine in traffic. No, wait, dammit, yes it does. Son of a...
It's not a question of being "willing." Any such responsibility is mine, there isn't a thing I can (or should) do to change that. The only choice available to me is to deny that responsibility in an act of moral cowardice. I decline to do that. It doesn't just apply to death, either.
Idiots like you can say anything they want about inaction, but it's not the same as action no matter how you slice it.
Only if you're one of those people who have no idea what the word "responsibility" means. You don't exist in isolation; when a choice arrives on your doorstep that affects other people, intentionally ignoring that choice is a choice, and one for which you had, and bear, full responsibility.
I think Rush said it well: "If you choose not to decide, you still have made a choice"
You have free will. That doesn't mean you have a free pass.
Nothing unusual about sparrows flying under elephant power. I think they like the risk of being downed by elephant dung. African sparrows, of course. European sparrows typically fly under mixed power: nuclear, coal, solar, oil, etc.
Anything else I can help you with? I have more scotch...
Limit attempts to log in to any specific account to once every minute or so. Failure locks the account for a minute, so it doesn't matter what IP or console or program the request comes in from, etc., it's once per minute, period. That's 1440 attempts / day, max.
Attempts to try every password will take forever on even a moderately stiff PW. So ensure passwords are at least moderately stiff. Or better.
After some small number of failed attempts from one IP, blacklist the IP or console. After some small number of highly concurrent failed attempts from multiple IPs, blacklist all of them.
This prevents using constant PW attempts as a trivial DOS and causes uniform attrition in botnets -- not only can that IP or console not attack that user, they can't attack any other, either.
If you've allowed people to get ahold of your password hashes or lists, you're completely hammered. So create a password server that does nothing else. Provide hardened physical security for same. Create a custom hardware bridge that does nothing but handle passwords in a very specific manner, complete with the built-in delays. No other connectivity. Passwords are now as secure as your physical plant allows for.
This puts the least load on the legit user and transfers such heavy work to the cracker that it becomes pointless to try. It's not even all that technically challenging.
Now, making your actual application secure... that, apparently, is beyond the ability of most programmers today. Sigh.
Slashdot Mirror
Didn't someone rather insightfully describe that as "slashdot zen"?
Great read, thank you. Also, yes.
Distributing them, for any reason, beyond the bounds of the relationship without permission is one thing. Contracts, informed consent, etc. Obvious.
Simply keeping them is quite another.
Well and sanely said.
Sigh. Anecdote is not the singular of data. While there are certainly good, effective moderators -- I'm one of them, for whatever good it does -- the majority are not, and the evidence -- in the form of lots and lots of data -- is in the veritable reams of high-quality, 0-rated anonymous posts that remain at zero, the well stated but contrary opinions on climate change, linux viability, Apple policies and so on and so on that get down-rated.
I wrote this in 2004: http://slashdot.org/journal/89818/slashdot-needs-some-fixes
The *fact* is, this is -- generally -- how slashdot's moderation operates. There's no getting 'round it.
If you let the smoke out...
oh, never mind.
you are.... unworthy
The data insecurity and NSA pre-packaging they offer is a big advantage but not for you
FTFY
It starts out modded down because your anonymous status is incorrectly conflated with low value by the site's basic posting and default reading mechanisms.
Somehow? Are you not aware that firehose is advisory only, and that the rankings attained in it have no effect upon which stories post?
It's correct. Slashdot's moderators routinely downrate good posts on the basis of "disagree", and the system itself hides good conversations, muzzles the moderators, incorrectly presumes anonymity is a bad thing for posts (wrong), while assuming anonymity is a good thing for moderators (wrong again), and does nothing effective about moderation abuse. The best thing you can say about it is that it can be ignored if you properly configure your browsing options. By far the best way to read slashdot is at -1. I've been doing it for years.
I wasn't complaining about high speed. Network speeds have been improving. We had 10. Then 10/100. Then 10/100/1000. I doubt it'll stop there. Might go optical or something, but it'll still probably be TCP for a while.
My objection is to the raving mess that is USB when it's looked at from a multi-platform perspective, and I think there are advantages to network connected devices that USB really can't touch anyway over and beyond cross platform compatibility.
I write multi-platform software that utilizes some fairly dense data streams. Some of the devices are USB; some are Ethernet.
For the curious, it's software defined radio; it's not unusual to see 16-bit data at 4 MHz coming in across the interface, which is a 64 Mb/s load, doable, but heavy, for a 100 Mb/s connection. There are devices that do 18 MHz at 16 bits. That can take up a considerable portion of a 1 Gb connection - 288 Mb/s. Day to day on my machine, I work with 800 kHz 16 bit data, or about 12 Mb/s for a 400 kHz receive bandwidth. All of these add some overhead on top of the main data stream too, as does TCP itself, so really, the loads are heavier.
Ethernet support basically has to be written once. How networking operates can be abstracted to be the same across OSX, linux, and Windows without much effort at all (Qt does this), and the TCP network stack is generally pretty fast and well behaved. And it is stable. (I could insert a rant about Apple's half-assed UDP support here, but...)
USB support varies considerably from one platform to another. Abstracting it is a huge PITA, requires lots of conditional compilation, and doesn't turn out that well, either. And that's without dealing with new USB drivers coming from the OS manufacturer that overwrite (and break) previously installed drivers. Nothing as fun as a user telling me "everything was working, now nothing is."
It's to the point where I won't directly support new USB SDRs. Every one I've done so far has added to my support load; whereas adding a new network-based SDR is painless, works the day I release it, and is still working a year later. In fact, if they adhere to the established SDR networking protocols, I don't even have to do *anything*, it'll just work. When someone asks me to support a new USB SDR, I tell them to write a network server for it using the established networking protocols. That way, when the USB breaks, as it seems it inevitably will, it's the responsibility, and support load, of the network server author, rather than mine. :)
It's also worth noting that as networking speeds have gone up, previous networking devices still work, and the new ones can crank pretty fast.
Then we get to remote issues; how far can you place a USB device from the computer that's talking to it? How about firewire or Thunderbolt? Now consider Ethernet. I can run an SDR that is quite a bit more distant from my computer, and I don't really have to do much to make that happen. I can have a bunch of them on the same subnet or even remote them out in the world. And then there's sharing. Same device, no reconfiguration, I can use it from OSX or Windows or linux without it even knowing that's happening. I can even go wireless transparently. I routinely sit on the couch and surf the HF and VHF bands on my laptop using WIFI as the data transport from the SDRs.
For any device that can manage it and still obtain acceptable performance, Ethernet looks like an excellent solution to me. If you really must have bus-like speeds, as in graphics engines and SSDs, ok, fine, Thunderpants, Displaypunt, Firepliers, etc. But please, if you're designing a peripheral with any kind of lesser bandwidth requirements, consider Ethernet as your interface. Everything is so much easier to deal with.
IMHO.
I wrote this "nowcast" application to keep me up to date on sky, planetary, and auroral conditions. Since my dark spot is about ten minutes from my home, I can get right to it in a timely manner.
Thanks. :)
How about, don't ride your totally unsafe, flimsy, difficult to see, acceleration-poor, crumple-bait bicycle on the same pavement with high powered, extremely heavy vehicles?
That will reduce biking accidents. Of course, it also requires common sense, and that... that... oh, right. Right. WTF am I thinking.
Maybe stick to actual bike paths? What, not enough bike paths? After all, lack of appropriate, safe paths doesn't stop me from driving my powered barstool or Riverine in traffic. No, wait, dammit, yes it does. Son of a...
Carry on.
"40 hz of current"
Is that like four cc's of amplification? 18 db of sugar? 16 mph of cotton?
Someone help me here, I'm drowning.
if they're lawyers, all of them.
It's not a question of being "willing." Any such responsibility is mine, there isn't a thing I can (or should) do to change that. The only choice available to me is to deny that responsibility in an act of moral cowardice. I decline to do that. It doesn't just apply to death, either.
Only if you're one of those people who have no idea what the word "responsibility" means. You don't exist in isolation; when a choice arrives on your doorstep that affects other people, intentionally ignoring that choice is a choice, and one for which you had, and bear, full responsibility.
I think Rush said it well: "If you choose not to decide, you still have made a choice"
You have free will. That doesn't mean you have a free pass.
Autonomous cars should be programmed to hit cars with lawyers in them.
Nothing unusual about sparrows flying under elephant power. I think they like the risk of being downed by elephant dung. African sparrows, of course. European sparrows typically fly under mixed power: nuclear, coal, solar, oil, etc.
Anything else I can help you with? I have more scotch...
Wait, I know this one. It's that same narcissistic bastard, day after day.
Limit attempts to log in to any specific account to once every minute or so. Failure locks the account for a minute, so it doesn't matter what IP or console or program the request comes in from, etc., it's once per minute, period. That's 1440 attempts / day, max.
Attempts to try every password will take forever on even a moderately stiff PW. So ensure passwords are at least moderately stiff. Or better.
After some small number of failed attempts from one IP, blacklist the IP or console. After some small number of highly concurrent failed attempts from multiple IPs, blacklist all of them.
This prevents using constant PW attempts as a trivial DOS and causes uniform attrition in botnets -- not only can that IP or console not attack that user, they can't attack any other, either.
If you've allowed people to get ahold of your password hashes or lists, you're completely hammered. So create a password server that does nothing else. Provide hardened physical security for same. Create a custom hardware bridge that does nothing but handle passwords in a very specific manner, complete with the built-in delays. No other connectivity. Passwords are now as secure as your physical plant allows for.
This puts the least load on the legit user and transfers such heavy work to the cracker that it becomes pointless to try. It's not even all that technically challenging.
Now, making your actual application secure... that, apparently, is beyond the ability of most programmers today. Sigh.
I see. So it'd be fair to say we would need a different kind of photon detector, then.