You simply parrot atrowe's advice to get a lawyer.
Excuse me? Who's parroting whom here? I had already suggested seeing a lawyer, and tried to offer significant other perspective besides, before you even showed up. Several others had done likewise by the time you tried to present the most basic and oft-repeated bit of advice as your own unique free-thinking insight. Your attempt to project your faults onto others - as an AC, no less - is laughable.
Most of these people seem to be under the impression that you should give away all of your code
I don't think anyone's saying he should give away his code so much as that, in the eyes of the law, it might not be his code to start with. This fellow's first priority should be to get a lawyer's professional, informed opinion on what the legal reality is now before plotting strategy. Dozens of people, at least a few of whom have real-world experience in this area and are no more "teenage code monkeys" than you are, had already made that suggestion before you rode in on your high horse to set us all straight. Your post was not only offensive in tone but redundant in content.
A lot depends on exactly what your employment agreement says. Depending on how it's worded, your employer might have - or, just as importantly, think they have, a claim on this work you present as your own. Obviously if any part - repeat: any part - of your project was done on their time or equipment, you're practically guaranteed to be SOL. If you have a copy on your machine at work, even if you never worked on it there, that's almost as bad. Even if none of these apply, they could go after you on intellectual-property grounds, non-compete, non-solicitation, or any other basis. Find out what they're likely to think and/or do. Talk to a lawyer, show them your employment agreement (don't just describe it), etc.
Another thorny issue, even if your employer doesn't have a claim on the work, is that they do have a claim on your time. If you refuse a job-related assignment, even if it's due to conflict of interest, they can simply fire you.
I think the idea of trying to set up a business and get them to buy your product as they would from any other vendor (never mind that it doesn't exist yet) is a sure loser. If they know the vendor is you it won't be treated any differently than if you'd negotiated directly, and if they don't know but find out later they could call it fraud. You need to show good faith. Negotiate with your employer openly and honestly. Only consider other options if they insist on being assholes about it. Bear in mind that most other options would involve you going into court bearing the burden of proof that you were not in violation of your employment agreement, did not steal any of their intellectual property, did not derive the idea from contacts made as their employee, etc. If you're not absolutely positively convinced that you can prove all of that, you might not have any other options. Sorry.
I think that's a little unfair. The comparison was between Tux2 and ext3, and if one is vapor then both are. They're at similar stages in development and their authors present similar pictures of their progress.
The future, IMHO, is a log structured file system with NO journaling and atomic updates. This creature already exists, and it is called FFS
Please, please, please try to keep straight the differences between journaling and log-structured filesystems. There's enough confusion on this issue already, and FFS is not log-structured. AFAIK nothing being actively developed for Linux is log-structured.
I think you're right, though, about journaling vs. soft updates (of which I think Tux2's atomic update is a sub-category, though DP might disagree). Soft updates are more flexible than journaling, and - with a filesystem whose basic structures are designed to take advantage - perform better than journaling. I find it just slightly weird that there's so much focus on journaling when a superior alternative is known. I shouldn't bitch, though. For years certain people's ignorance, unwillingness to learn, and territoriality stood in the way of any progress in this area, and I for one am glad that the threat of competition has finally shaken their "hours-long fsck is OK for me" complacency. It would have been even nicer if they had responded by embracing the new entries instead of scrambling to maintain the incumbent's dominance by upgrading it just enough to stay competitive (does that remind anyone else of MS tactics?) but one can't make a purse out of a sow's ear.
Disclaimer: all views expressed are my own. If my employer took my views more seriously, their stock might not have tanked so badly.
Does that mean that there are no other definitions of "real time"?
No, not at all. Other definitions may and do exist, and some other definition might even become the dominant one someday if it's more useful than the definition already in place. That's sort of why I suggested that maybe we need new terms; having new terms is better than overloading old ones with contradictory meanings.
In the context of the current conversation, I think it's important for people to understand what people who use QNX are likely to mean when they say "realtime" and how that differs from other usage of the term
IRC certainly can be considered a real time application. AFAIK, Prior to it, there was no way having a more-or-less instantaneous conversation with someone on the internet.
Incorrect. When I first encountered IRC it was still less than a year old. By that time I had already been using chat, talk, and similar programs on UNIX and other systems for years. Some of those programs even supported more than two people talking at once.
Such anomalies are a part of the way our minds think, our english language, and even of our jargon. Might be wise to just get used to it.
As a general philosophy, "just get used to it" sucks. Its proponents might claim they're exhibiting adaptability, but more often than not they're just demonstrating laziness. Precision matters. Definitions matter. Extreme inflexibility can be a bad thing, but I don't think there's anything wrong with reminding people of the most common, most relevant definition of a term they're (mis)using.
The key is that a cache miss is more expensive than not using the cache at all, because you still have to check tags etc. to find out it's not there. This difference is generally very small (single-cycle) in a uniprocessor, but in a large multiprocessor it can be a lot more. If there's a code path that is just barely too long to make a deadline when every access is a cache miss, and using uncached access guarantees that it will always complete on time (even if it also always uses 99% of its time slot) then that's considered a good thing.
Keep in mind, too, that that's just an example, and perhaps an extreme one. The same principle gets applied to disks (high RPM beats big sector cache), networks (token ring beats CSMA/CD), and just about everything else that might get connected to the system. RT is like living with Murphy of Murphy's Law. The question is always: what performance do we get if everything goes wrong?
The difference is, in soft RT systems timing is not of great importance. If a process finishes 200us later than it should have, it is no end of the world.
According to the terminology I was taught, that's wrong. All realtime systems require that deadlines be met, and the distinction between "hard" and "soft" is merely a matter of how long the deadlines are. If you have a lot of 5us deadlines, that's hard; if none of your deadlines are less than 10ms, that's soft.
The problem is that lots of people call things realtime that aren't realtime. Interacting with humans generally isn't realtime. Realtime stock quotes or airline-reservation systems aren't truly realtime in the sense we're talking about. Chatting sure as hell isn't realtime, in this sense. Avionics, nuclear power plant control, medical equipment - those are realtime. Maybe we need new terminology, such as "time-critical" vs. "time-sensitive" or something, to distinguish these different meanings. Until then, though, any system that treats a missed deadline as anything less than a major problem deserving of individual attention by the app developer is not realtime.
Basically, any application that needs extremely fast response from the system itself will require realtime facilities.
Wrong. Realtime is about deterministic response, not necessarily fast response. In fact, realtime systems often sacrifice speed for predictability; the thinking is all about worst case, not average case. For example, a cache that's twice as fast as main memory and has a hit rate of over 99% is generally great for performance. However, I've seen real-time guys turn off caching because main memory access times, though slower on average, were more predictable. As far as they were concerned, the big thing to worry about was that if every one of 5031 memory references in a code path (yes, they count) missed in cache, the two-cycle cache miss penalty would cause them to miss a deadline. Never mind that the odds against that are astronomically high, never mind that in fact it could probably be proven that at least 1179 of the memory accesses would always hit in cache because of the way they followed other accesses. They didn't have time for such a complex analysis, and statistical thresholds are antithetical to their method. For them, it's just important that they have M accesses and each one has an upper bound of N cycles.
I know this is drifting a little off-topic, but I just can't help myself. SCSI has some good points, but it also has some pretty severe warts. Things like disconnect/reconnect and tagged command queuing are good - unless you consider them so obvious and necessary that any interface lacking them is brain-dead. Some aspects of SCSI error reporting are good, such as the way that an error reply can specify exactly which bit in a request caused it to be rejected. Very nice.
Now for some of the warts. The termination and ID-assignment issues in the original SCSI spec drove many people insane. The speed/width negotiations are still having that effect. The handling of resets still leaves much to be desired, particularly in a multi-initiator environment. Similarly, the way sense data are maintained (or not) sucks rocks in a multi-initiator. The lack of AEN support is not really a protocol flaw, but it's annoying enough that I have to mention it anyway. Some of these issues are specific to old-style parallel SCSI, but some others are shared with FC.
The long and the short of it is that, at a protocol level, SCSI is light-years beyond IDE but still somewhat short of what I'd call a "well designed protocol".
I've actually had to think about these issues quite a bit lately, for reasons I'm not comfortable disclosing, so I have a few observations that others might find interesting:
In the most general sense, claims regarding specific inventions in which the employer was not involved (e.g. prior to employment) are not enforceable even if they're in the employee agreement.
However, it can be more difficult than you might expect to prove that a specific invention was in your possession prior to employment. If you don't have something written down and in the possession of people you can count on to testify as to its provenance, you're on dangerous ground.
Ideas tend to get entangled with one another. Even if you can prove ownership of one invention, the employer might come at you with claims regarding related or secondary inventions. The burden of disentanglement will be yours, and a sufficiently determined employer can sometimes rule out all possible expressions or means of implementation even while ceding ownership of the core invention to you.
Beware the "doctrine of negative knowledge". This is the idea that, when you try to do something, you quickly find out many wrong ways to do it; this is called negative knowledge, and it is the property of your employer in the eyes of most courts. Jeff Merkey of Timpanogas Research Group is a well-known victim of this doctrine, and Novell vs. Timpanogas is a case with which anyone interested in intellectual-property law should be familiar.
In short, then, you can often win a battle over an invention but still end up losing the war. If you think you might ever want to work on something on your own that is in any way related to what you do at your job, make damn sure you know exactly where you stand with regard to these issues.
ISP's continually operate at near peak usage. They dont leave lots of empty bandwidth laying around because someone *might* use it.
Yes, they do. Network traffic is notoriously bursty, so to accomodate peak usage a network provider does indeed overprovision so that during non-peak there's a lot of unused bandwidth. There are actually some really neat opportunities there, for a heavy-data-transfer application that's smart enough to use time-shifting and caching to move traffic off-peak.
1000 people on alpine would be no different than 1000 people on napster, a 1000 people on freenet
Wrong. Protocol affects bandwidth need/usage, and a brain-dead protocol will use more bandwidth than a cleverly-designed one to accomplish the same task. That's what I and apparently several others have been trying to tell you.
Show me a peering application that does not maximize use of your bandwidth in a large network
You're missing the point. There's a difference between effective bandwidth and total bandwidth (which includes protocol overhead). Maximizing effective bandwidth is good; maximizing total bandwidth is antisocial, and ultimately reduces the effective bandwidth left over for getting real work done. With your protocol, all of the capacity will be sucked into a black hole doing queries, and actual downloads will slow to a crawl.
The query process is iterative, and can be halted, slowed, at any point in time.
The more you throttle it down, the longer it takes to get past the overwhelming majority of negative response to the few positive ones, so you can have slow response because you didn't throttle your traffic or slow response because you did. Yippee.
Sure, there are various criteria that indicate a bad or good peer. These include, among other things:
Is a framework for collecting, collating, and using this information already thought out, or did you make up this list only in response to my query?
Only your initial upstream router is receiving them
You need to look further than that. If you have a Napster-like number of users there will be thousands of routers out there connected to thousands of ALPINE users each generating queries. When you multiply things out to get total traffic, as was just done for Gnutella, you do get a level of traffic that will make the router owners sit up and take notice.
Sending the same data to 10K hosts in separate packets not only doesn't scale, but it's an extremely antisocial abuse of the network
Funny, I thought web servers acted this way...
Increasingly, in the era of second-gen content distribution networks, they don't. Where they do, they pay dearly for the privilege of sucking up so much bandwidth. I don't think you do yourself any favors by pushing a first-gen "solution" when the second gen is already out there and some people - such as myself - are already working on gen three.
If you find the reply your looking for, then there is no need to query the remaining peers
You won't get the answer until you've already sent queries to the next batch. Net result: not only are you consuming all this bandwidth and creating all this congestion, then you turn around and drop those packets on the floor. That's just adding insult to injury, as far as your upstream is concerned.
The adaptive nature of the protocol
Please describe how this adaptation occurs. The details are not on your website, it's a complex problem, and I think you're just handwaving about something you don't understand.
you are sending a large number of packets, but each peer is only receiving one of them
But the intervening routers are receiving them - and the replies - in huge clumps. That's just like a DDoS.
I have to admit that it's a little bit strange posting something with such a subject line from the conference hall at the O'Reilly P2P conference in SF, but I can't help myself.
Implementing a pseudo-broadcast by sending separately to all destinations is stupid. Real network designers have known this for years. First off, to send to N destinations you have to shove N packets down your local pipe, which may be narrow. Even at 60 bytes per packet, if you're trying to send to 10000 nodes that's 600K. Then the replies start coming in - in clumps - further clogging that pipe. That single UDP socket you're using does have a finite queue depth, so it will start dropping replies left and right after the first few. Well, maybe not, but only because your ISP's routers will have dropped them first because they overflowed their own queue depths.
Sending the same data to 10K hosts in separate packets not only doesn't scale, but it's an extremely antisocial abuse of the network. The traffic patterns ALPINE will generate are like nothing so much as a DDoS attack, with the query originator and their ISP as the victims. In the same Gnutella thread in which you started hyping ALPINE, some slightly clueful people were suggesting tree-based approaches. Those ideas, as stated e.g. by Omnifarious, are a little naive, but well-known technology in mesh routing and distributed broadcast can easily enough be applied to create and maintain self-organizing adaptive distributed broadcast trees (phew, that was a mouthful) for this purpose. Read the literature. The pitfalls in what you're suggesting are already so well known that they should be part of any computer-networking curriculum, and much more reasonable solutions to the same problems are only scarcely less well known. There is no need to reinvent the wheel, especially if your wheel is square.
As Clay Shirky mentioned in his talk here yesterday, "peer to peer" can be considered a little bit of a misnomer. It's a lot more about addressing and identity issues, and even more about scalability, and having N^2 connections in a network of N nodes is no route to scalability. ALPINE's scaling characteristics will be worse than Gnutella's. Pemdas made a good point that you seem to have a talent for marketing. Stick to it. Unlike Pemdas I can evaluate the technical merits of what you're proposing, and you are headed 180 degrees away from a solution.
I'll bet Slashdot offers an even better substrate than spam. Carefully chosen variants of comments about how MS/Microsoft/Microsloth sucks/sux/blows/bites could easily be used to encode a message. Ditto for other "hot words" such as Linux, BSD, JonKatz, Natalie Portman, goatsex, etc. With a little creativity we could probably get something like Spam Mimic working, but with a much more favorable compression ratio. What's even better is that you don't even have to use your own storage. Just post the encoded version to Slashdot and your friend can pick it up any time, while it remains totally indistinguishable from all the other random garbage people (including me) post here.
I'll bet that every one of the people who fails to take you or your opinions as seriously as you feel they should knows exactly how it feels because they went through exactly the same thing when they were your age. In fact, that's why some of them do it to you now; it's a rite of passage sort of thing, and they feel that if they had to go through it then you should too. Builds character, or something. I'm not saying that's right, but when you get right down to it that's what motivates a lot of their behavior.
I can also think of a few other reasons you might get these sorts of reactions. One is that here may be some issue with how you present your opinions. Like it or not, it is your responsibility to understand your audience and convey your views in a way that is convincing to them. In this sense it's not so much an age thing as a culture thing; an older person from "outside the culture" who didn't present things "the right way" would get the same reaction. Consider what happens when a sales guy or an exec walks into a room full of engineers.
Lastly, we come up against the fact that older people do have some advantages over younger ones. For example:
Older people have usually learned at some point (usually the hard way) the dangers of making brash assertions or over-optimistic predictions, so they can usually be counted on not to make those particular errors. They may often err in the opposite direction, in fact, but that's a whole different problem.
Older people, even the ones who seem pretty inept socially, will always alwaysalways have a finer appreciation for the human dimensions of problem-solving than any fresh-out ever did.
Older people don't just have ideas and knowledge, but can place them in context. A common failing among young techies - and the brightest are usually the most susceptible - is that they get caught up in an individual idea or technology's coolness but don't have the background to see how it will interact with other ideas or technologies. The older folks may not know as much about current technology, but what they do know they know in a deeper or broader sense, connecting it to a whole bunch of other little pieces of information that may (or may not) turn out to be critical.
Despite all that, there's a lot to be said for fresh perspectives and youthful enthusiasm. Your ideas may seem flighty or unreasonable to some, but a wise man once said that because reasonable men don't try to change the world all progress depends on unreasonable men. My point here is that you can't expect them to subscribe to your idea of "merit" without some justification. Just as they have ways of doing technical things and won't change those without good reason, they have ways of doing social things and won't change those without good reason. Show them the reasons. Anticipate their objections, address their concerns, and show them in terms they will accept how things would work better if they were more accepting of ideas from "people like you".
BTW, I'm 35. I get flak from both the youngsters and the oldsters. It's like "no man's land" in the battle between generations.
I wrote an article on Using Test Suites to Validate the New Linux Kernel.
Excellent! The article and, even more importantly, the activities to which it refers are exactly the sort of thing Linux needs most. Kudos to all who are involved in the grueling and usually thankless effort to bring Linux testing up to an acceptable level.
Ian Goldberg is just one of the best crypto-hackers out there...if he's complaining of insufficient access to the standards process for cryptanalytic purposes, he does so with good reason.
CDNF. The man may be technically brilliant, and I'll gladly take your word for that, but brilliance does not imply that he lacks baser motivations such as publicity-seeking or hope for profit as the new CTO of a security-related company. His comments on this particular matter were and are irresponsible, regardless of anything else he has ever done.
I'd also be curious to know more about your participation in the cryptographic community that you refer to
I never claimed to be involved personally in the cryptographic community, nor do any of my comments depend on such a claim. Please take ad hominem attacks elsewhere.
Yes, you can. Trivially. Often you don't even need special tools, it's right there in the driver config.
Other people have suggested approaches for preventing this problem, most of a preventive nature. If you want more of a "honeypot" kind of solution that lets you catch a spy, here's an idea. Leave the device in place. Filter out all actual IP traffic going through it, and set up alarms to go off when someone makes a link-level connection. With the right equipment you can pinpoint their exact location when the alarm goes off, but even if you don't do that at least you get a chance to look around for people who seem to be in places they shouldn't.
It's not totally foolproof. In particular, it's possible to do truly passive listening that wouldn't get detected, but if you're dealing with someone that sophisticated I doubt you're looking for tips on Slashdot.;-) Most off-the-shelf access points won't send out any signal at all when they have zero link-level connections, so that's the dead giveaway.
Ho hum. Not a single argument that was not completely predictable. Oh well, guess I'll have to restate the obvious for your benefit.
Thus we have total expected storage requirements of ~45 GB, and a total running time of 400 hours to decrypt all future traffic on the network
That's a non-trivial effort. Do you think the average script kiddie is going to take their wireless-equipped laptop, with 45GB worth of storage, and go sit within range of the target network for 400 hours, and then apply all the compute power to crack the keys? Dream on. Yes, some people can do this, but those are specialized organizations devoted to this kind of task - not random script kiddies.
Do you understand the term "script kiddie" at all?
Yes, I do, thanks very much for asking. Do you? One of the things about script kiddies that you seem to have missed is that the programs they like to use are relatively easy to write and don't care very much about the exact flavor of the underlying hardware. The "confusing the firmware" exploit we're talking about would have to be repeated for every hardware/firmware combination, and would not be at all easy to write. Half of this hardware doesn't even work on Linux due to lack of driver support. Do you really think more skill and effort will be applied to "confusing the firmware" than has been to unconfusing it and getting it to work? Again, dream on.
Of course, you're right that all it takes is one person to write the program and thousands to use it, but it might still take a while before that one person gets done. With a responsible approach to security, it might have taken them long enough that the vendors would already have plugged the holes by the time the exploit code was ready.
Your hope that equipment manufacturers address this problem is probably misgiven
That's your opinion. Please back it up.
Do you really think it's that hard for vendors to incorporate a 4096-bit cryptographically secure certificate into the firmware image, such that the card will refuse to operate if the certificate is invalid? Think again. I've worked on firmware, and this is the easiest thing in the world for them. Lots of cards have to decompress their firmware as part of the bootstrap procedure anyway; once you're decompressing, it's trivial to add validation. There is no need for the "hardcoded drivers" (what an absurd concept) or other strawmen you suggest.
However, I do know that if this protocol was indeed opened up to peer review as you seem to suggest (without any evidence)
It's an IEEE standard, moron. Do you know what that means? The IEEE goes to extraordinary lengths to solicit and incorporate input from interested parties, many of whom I'm sure are pretty well qualified in their fields. We're not talking about some obscure closed trade group here. IEEE standards are in many ways more open than the not-really-standards of open source. Without IEEE standards we probably wouldn't be talking. How do you think your packets get to slashdot? In large part you owe thanks to IEEE for that.
It's your claim, that the process was somehow not open, that is absurd and that requires proof. Get to it.
Frankly, I can't believe that any serious peer review wouldn't flag the problems....
You just don't know anything about peer review, do you? How many of these sorts of activities have you participated in? The fact is that when you're dealing with complex new technology people sometimes make mistakes. Sometimes the mistakes are real howlers in retrospect. That's life. How many problems do you suppose these guys anticipated and dealt with that you would have flubbed if you'd been in their place? It's really easy to jeer from the peanut gallery, with full benefit of hindsight, but really people who do that are just being pricks.
The right thing to do would have been to alert the equipment manufacturers, discreetly, and let them decide how they want to alert their customers
This is so beyond ludicrous I'm not even going to touch it.
No, really, try to give us a responsible rebuttal, instead of trying to substitute sneering for reasoning. Try, anyway. What you dismissed so flippantly is actually a very hot issue among security professionals: who gets to find out first?
Now, I knew when I suggested it that the "tell the vendors" approach wouldn't be very popular here on ScriptKiddieDot, but that doesn't make it a troll (and neither does calling it one). It's worth considering how this audience differs from the Real World. For one, the attitude here is "openness at all costs". There's no room allowed for discretion or careful handling of delicate issues. No, I'm not talking about "security through obscurity" because that never works. What I'm talking about is giving the vendors a reasonable timeframe in which to fix problems before letting every black hat in the world have the info. Let's face it, for every white hat on this site there are probably a hundred black hats, and I doubt that there's a single person involved in this discussion in a position to do good rather than harm with this information. How do you think it benefits anyone but the script kiddies to publicize this problem in this fashion? It doesn't help the problems get fixed any faster, it just maximizes the damage that gets done before the problem is fixed. Screw your "information wants to be free" dogma, and think about social implications for once.
In case you missed it the first time, and the second time, let me repeat a third time: I agree that there's cause for concern in this. Nobody's disputing that. What pisses me off is that people are trying to enhance their own images by panicmongering. The actual security threat here has not been shown to be effectively distinguishable from zero, and yet these people are acting like any semi-literate cracker might already have everyone's credit card numbers. Believe me, we're all threatened much more by existing security problems in the wired network than by any implications of these findings. If there's one thing that's obvious from all this, it's that the biggest security problem is people not even using the security facilities available to them.
This is the biggie - the WEP authentication protocol relies on DNS
Can you explain this further? I was unaware of any dependency between 802.11b and DNS, and I certainly didn't have to make any DNS changes to get my setup working - including full encryption. Is this an optional part, perhaps related only to the key-distribution you give as concern #1?
wow, you have really got to be a dedicated gek to take your laptop with you when you are taking a leek.
Well, yeah. I am.;-)
I guess I could claim that I was testing the transmitter's range or something, but it really was just a "because I can" sort of thing. I don't expect I'll be making a habit of it, though it might be handy next time I get a bad burrito or something and expect an extended bathroom stay.
Slashdot Mirror
Excuse me? Who's parroting whom here? I had already suggested seeing a lawyer, and tried to offer significant other perspective besides, before you even showed up. Several others had done likewise by the time you tried to present the most basic and oft-repeated bit of advice as your own unique free-thinking insight. Your attempt to project your faults onto others - as an AC, no less - is laughable.
I don't think anyone's saying he should give away his code so much as that, in the eyes of the law, it might not be his code to start with. This fellow's first priority should be to get a lawyer's professional, informed opinion on what the legal reality is now before plotting strategy. Dozens of people, at least a few of whom have real-world experience in this area and are no more "teenage code monkeys" than you are, had already made that suggestion before you rode in on your high horse to set us all straight. Your post was not only offensive in tone but redundant in content.
A lot depends on exactly what your employment agreement says. Depending on how it's worded, your employer might have - or, just as importantly, think they have, a claim on this work you present as your own. Obviously if any part - repeat: any part - of your project was done on their time or equipment, you're practically guaranteed to be SOL. If you have a copy on your machine at work, even if you never worked on it there, that's almost as bad. Even if none of these apply, they could go after you on intellectual-property grounds, non-compete, non-solicitation, or any other basis. Find out what they're likely to think and/or do. Talk to a lawyer, show them your employment agreement (don't just describe it), etc.
Another thorny issue, even if your employer doesn't have a claim on the work, is that they do have a claim on your time. If you refuse a job-related assignment, even if it's due to conflict of interest, they can simply fire you.
I think the idea of trying to set up a business and get them to buy your product as they would from any other vendor (never mind that it doesn't exist yet) is a sure loser. If they know the vendor is you it won't be treated any differently than if you'd negotiated directly, and if they don't know but find out later they could call it fraud. You need to show good faith. Negotiate with your employer openly and honestly. Only consider other options if they insist on being assholes about it. Bear in mind that most other options would involve you going into court bearing the burden of proof that you were not in violation of your employment agreement, did not steal any of their intellectual property, did not derive the idea from contacts made as their employee, etc. If you're not absolutely positively convinced that you can prove all of that, you might not have any other options. Sorry.
Strong? Definitely. Central? Not so clear.
I think that's a little unfair. The comparison was between Tux2 and ext3, and if one is vapor then both are. They're at similar stages in development and their authors present similar pictures of their progress.
Please, please, please try to keep straight the differences between journaling and log-structured filesystems. There's enough confusion on this issue already, and FFS is not log-structured. AFAIK nothing being actively developed for Linux is log-structured.
I think you're right, though, about journaling vs. soft updates (of which I think Tux2's atomic update is a sub-category, though DP might disagree). Soft updates are more flexible than journaling, and - with a filesystem whose basic structures are designed to take advantage - perform better than journaling. I find it just slightly weird that there's so much focus on journaling when a superior alternative is known. I shouldn't bitch, though. For years certain people's ignorance, unwillingness to learn, and territoriality stood in the way of any progress in this area, and I for one am glad that the threat of competition has finally shaken their "hours-long fsck is OK for me" complacency. It would have been even nicer if they had responded by embracing the new entries instead of scrambling to maintain the incumbent's dominance by upgrading it just enough to stay competitive (does that remind anyone else of MS tactics?) but one can't make a purse out of a sow's ear.
Disclaimer: all views expressed are my own. If my employer took my views more seriously, their stock might not have tanked so badly.
No, not at all. Other definitions may and do exist, and some other definition might even become the dominant one someday if it's more useful than the definition already in place. That's sort of why I suggested that maybe we need new terms; having new terms is better than overloading old ones with contradictory meanings.
In the context of the current conversation, I think it's important for people to understand what people who use QNX are likely to mean when they say "realtime" and how that differs from other usage of the term
Incorrect. When I first encountered IRC it was still less than a year old. By that time I had already been using chat, talk, and similar programs on UNIX and other systems for years. Some of those programs even supported more than two people talking at once.
As a general philosophy, "just get used to it" sucks. Its proponents might claim they're exhibiting adaptability, but more often than not they're just demonstrating laziness. Precision matters. Definitions matter. Extreme inflexibility can be a bad thing, but I don't think there's anything wrong with reminding people of the most common, most relevant definition of a term they're (mis)using.
The key is that a cache miss is more expensive than not using the cache at all, because you still have to check tags etc. to find out it's not there. This difference is generally very small (single-cycle) in a uniprocessor, but in a large multiprocessor it can be a lot more. If there's a code path that is just barely too long to make a deadline when every access is a cache miss, and using uncached access guarantees that it will always complete on time (even if it also always uses 99% of its time slot) then that's considered a good thing.
Keep in mind, too, that that's just an example, and perhaps an extreme one. The same principle gets applied to disks (high RPM beats big sector cache), networks (token ring beats CSMA/CD), and just about everything else that might get connected to the system. RT is like living with Murphy of Murphy's Law. The question is always: what performance do we get if everything goes wrong?
According to the terminology I was taught, that's wrong. All realtime systems require that deadlines be met, and the distinction between "hard" and "soft" is merely a matter of how long the deadlines are. If you have a lot of 5us deadlines, that's hard; if none of your deadlines are less than 10ms, that's soft.
The problem is that lots of people call things realtime that aren't realtime. Interacting with humans generally isn't realtime. Realtime stock quotes or airline-reservation systems aren't truly realtime in the sense we're talking about. Chatting sure as hell isn't realtime, in this sense. Avionics, nuclear power plant control, medical equipment - those are realtime. Maybe we need new terminology, such as "time-critical" vs. "time-sensitive" or something, to distinguish these different meanings. Until then, though, any system that treats a missed deadline as anything less than a major problem deserving of individual attention by the app developer is not realtime.
Wrong. Realtime is about deterministic response, not necessarily fast response. In fact, realtime systems often sacrifice speed for predictability; the thinking is all about worst case, not average case. For example, a cache that's twice as fast as main memory and has a hit rate of over 99% is generally great for performance. However, I've seen real-time guys turn off caching because main memory access times, though slower on average, were more predictable. As far as they were concerned, the big thing to worry about was that if every one of 5031 memory references in a code path (yes, they count) missed in cache, the two-cycle cache miss penalty would cause them to miss a deadline. Never mind that the odds against that are astronomically high, never mind that in fact it could probably be proven that at least 1179 of the memory accesses would always hit in cache because of the way they followed other accesses. They didn't have time for such a complex analysis, and statistical thresholds are antithetical to their method. For them, it's just important that they have M accesses and each one has an upper bound of N cycles.
I know this is drifting a little off-topic, but I just can't help myself. SCSI has some good points, but it also has some pretty severe warts. Things like disconnect/reconnect and tagged command queuing are good - unless you consider them so obvious and necessary that any interface lacking them is brain-dead. Some aspects of SCSI error reporting are good, such as the way that an error reply can specify exactly which bit in a request caused it to be rejected. Very nice.
Now for some of the warts. The termination and ID-assignment issues in the original SCSI spec drove many people insane. The speed/width negotiations are still having that effect. The handling of resets still leaves much to be desired, particularly in a multi-initiator environment. Similarly, the way sense data are maintained (or not) sucks rocks in a multi-initiator. The lack of AEN support is not really a protocol flaw, but it's annoying enough that I have to mention it anyway. Some of these issues are specific to old-style parallel SCSI, but some others are shared with FC.
The long and the short of it is that, at a protocol level, SCSI is light-years beyond IDE but still somewhat short of what I'd call a "well designed protocol".
I've actually had to think about these issues quite a bit lately, for reasons I'm not comfortable disclosing, so I have a few observations that others might find interesting:
In short, then, you can often win a battle over an invention but still end up losing the war. If you think you might ever want to work on something on your own that is in any way related to what you do at your job, make damn sure you know exactly where you stand with regard to these issues.
Yes, they do. Network traffic is notoriously bursty, so to accomodate peak usage a network provider does indeed overprovision so that during non-peak there's a lot of unused bandwidth. There are actually some really neat opportunities there, for a heavy-data-transfer application that's smart enough to use time-shifting and caching to move traffic off-peak.
Wrong. Protocol affects bandwidth need/usage, and a brain-dead protocol will use more bandwidth than a cleverly-designed one to accomplish the same task. That's what I and apparently several others have been trying to tell you.
You're missing the point. There's a difference between effective bandwidth and total bandwidth (which includes protocol overhead). Maximizing effective bandwidth is good; maximizing total bandwidth is antisocial, and ultimately reduces the effective bandwidth left over for getting real work done. With your protocol, all of the capacity will be sucked into a black hole doing queries, and actual downloads will slow to a crawl.
The more you throttle it down, the longer it takes to get past the overwhelming majority of negative response to the few positive ones, so you can have slow response because you didn't throttle your traffic or slow response because you did. Yippee.
Is a framework for collecting, collating, and using this information already thought out, or did you make up this list only in response to my query?
You need to look further than that. If you have a Napster-like number of users there will be thousands of routers out there connected to thousands of ALPINE users each generating queries. When you multiply things out to get total traffic, as was just done for Gnutella, you do get a level of traffic that will make the router owners sit up and take notice.
Increasingly, in the era of second-gen content distribution networks, they don't. Where they do, they pay dearly for the privilege of sucking up so much bandwidth. I don't think you do yourself any favors by pushing a first-gen "solution" when the second gen is already out there and some people - such as myself - are already working on gen three.
You won't get the answer until you've already sent queries to the next batch. Net result: not only are you consuming all this bandwidth and creating all this congestion, then you turn around and drop those packets on the floor. That's just adding insult to injury, as far as your upstream is concerned.
Please describe how this adaptation occurs. The details are not on your website, it's a complex problem, and I think you're just handwaving about something you don't understand.
But the intervening routers are receiving them - and the replies - in huge clumps. That's just like a DDoS.
I have to admit that it's a little bit strange posting something with such a subject line from the conference hall at the O'Reilly P2P conference in SF, but I can't help myself.
Implementing a pseudo-broadcast by sending separately to all destinations is stupid. Real network designers have known this for years. First off, to send to N destinations you have to shove N packets down your local pipe, which may be narrow. Even at 60 bytes per packet, if you're trying to send to 10000 nodes that's 600K. Then the replies start coming in - in clumps - further clogging that pipe. That single UDP socket you're using does have a finite queue depth, so it will start dropping replies left and right after the first few. Well, maybe not, but only because your ISP's routers will have dropped them first because they overflowed their own queue depths.
Sending the same data to 10K hosts in separate packets not only doesn't scale, but it's an extremely antisocial abuse of the network. The traffic patterns ALPINE will generate are like nothing so much as a DDoS attack, with the query originator and their ISP as the victims. In the same Gnutella thread in which you started hyping ALPINE, some slightly clueful people were suggesting tree-based approaches. Those ideas, as stated e.g. by Omnifarious, are a little naive, but well-known technology in mesh routing and distributed broadcast can easily enough be applied to create and maintain self-organizing adaptive distributed broadcast trees (phew, that was a mouthful) for this purpose. Read the literature. The pitfalls in what you're suggesting are already so well known that they should be part of any computer-networking curriculum, and much more reasonable solutions to the same problems are only scarcely less well known. There is no need to reinvent the wheel, especially if your wheel is square.
As Clay Shirky mentioned in his talk here yesterday, "peer to peer" can be considered a little bit of a misnomer. It's a lot more about addressing and identity issues, and even more about scalability, and having N^2 connections in a network of N nodes is no route to scalability. ALPINE's scaling characteristics will be worse than Gnutella's. Pemdas made a good point that you seem to have a talent for marketing. Stick to it. Unlike Pemdas I can evaluate the technical merits of what you're proposing, and you are headed 180 degrees away from a solution.
I'll bet Slashdot offers an even better substrate than spam. Carefully chosen variants of comments about how MS/Microsoft/Microsloth sucks/sux/blows/bites could easily be used to encode a message. Ditto for other "hot words" such as Linux, BSD, JonKatz, Natalie Portman, goatsex, etc. With a little creativity we could probably get something like Spam Mimic working, but with a much more favorable compression ratio. What's even better is that you don't even have to use your own storage. Just post the encoded version to Slashdot and your friend can pick it up any time, while it remains totally indistinguishable from all the other random garbage people (including me) post here.
I'll bet that every one of the people who fails to take you or your opinions as seriously as you feel they should knows exactly how it feels because they went through exactly the same thing when they were your age. In fact, that's why some of them do it to you now; it's a rite of passage sort of thing, and they feel that if they had to go through it then you should too. Builds character, or something. I'm not saying that's right, but when you get right down to it that's what motivates a lot of their behavior.
I can also think of a few other reasons you might get these sorts of reactions. One is that here may be some issue with how you present your opinions. Like it or not, it is your responsibility to understand your audience and convey your views in a way that is convincing to them. In this sense it's not so much an age thing as a culture thing; an older person from "outside the culture" who didn't present things "the right way" would get the same reaction. Consider what happens when a sales guy or an exec walks into a room full of engineers.
Lastly, we come up against the fact that older people do have some advantages over younger ones. For example:
Despite all that, there's a lot to be said for fresh perspectives and youthful enthusiasm. Your ideas may seem flighty or unreasonable to some, but a wise man once said that because reasonable men don't try to change the world all progress depends on unreasonable men. My point here is that you can't expect them to subscribe to your idea of "merit" without some justification. Just as they have ways of doing technical things and won't change those without good reason, they have ways of doing social things and won't change those without good reason. Show them the reasons. Anticipate their objections, address their concerns, and show them in terms they will accept how things would work better if they were more accepting of ideas from "people like you".
BTW, I'm 35. I get flak from both the youngsters and the oldsters. It's like "no man's land" in the battle between generations.
Excellent! The article and, even more importantly, the activities to which it refers are exactly the sort of thing Linux needs most. Kudos to all who are involved in the grueling and usually thankless effort to bring Linux testing up to an acceptable level.
CDNF. The man may be technically brilliant, and I'll gladly take your word for that, but brilliance does not imply that he lacks baser motivations such as publicity-seeking or hope for profit as the new CTO of a security-related company. His comments on this particular matter were and are irresponsible, regardless of anything else he has ever done.
I never claimed to be involved personally in the cryptographic community, nor do any of my comments depend on such a claim. Please take ad hominem attacks elsewhere.
Yes, you can. Trivially. Often you don't even need special tools, it's right there in the driver config.
Other people have suggested approaches for preventing this problem, most of a preventive nature. If you want more of a "honeypot" kind of solution that lets you catch a spy, here's an idea. Leave the device in place. Filter out all actual IP traffic going through it, and set up alarms to go off when someone makes a link-level connection. With the right equipment you can pinpoint their exact location when the alarm goes off, but even if you don't do that at least you get a chance to look around for people who seem to be in places they shouldn't.
It's not totally foolproof. In particular, it's possible to do truly passive listening that wouldn't get detected, but if you're dealing with someone that sophisticated I doubt you're looking for tips on Slashdot. ;-) Most off-the-shelf access points won't send out any signal at all when they have zero link-level connections, so that's the dead giveaway.
Ho hum. Not a single argument that was not completely predictable. Oh well, guess I'll have to restate the obvious for your benefit.
That's a non-trivial effort. Do you think the average script kiddie is going to take their wireless-equipped laptop, with 45GB worth of storage, and go sit within range of the target network for 400 hours, and then apply all the compute power to crack the keys? Dream on. Yes, some people can do this, but those are specialized organizations devoted to this kind of task - not random script kiddies.
Yes, I do, thanks very much for asking. Do you? One of the things about script kiddies that you seem to have missed is that the programs they like to use are relatively easy to write and don't care very much about the exact flavor of the underlying hardware. The "confusing the firmware" exploit we're talking about would have to be repeated for every hardware/firmware combination, and would not be at all easy to write. Half of this hardware doesn't even work on Linux due to lack of driver support. Do you really think more skill and effort will be applied to "confusing the firmware" than has been to unconfusing it and getting it to work? Again, dream on.
Of course, you're right that all it takes is one person to write the program and thousands to use it, but it might still take a while before that one person gets done. With a responsible approach to security, it might have taken them long enough that the vendors would already have plugged the holes by the time the exploit code was ready.
That's your opinion. Please back it up.
Do you really think it's that hard for vendors to incorporate a 4096-bit cryptographically secure certificate into the firmware image, such that the card will refuse to operate if the certificate is invalid? Think again. I've worked on firmware, and this is the easiest thing in the world for them. Lots of cards have to decompress their firmware as part of the bootstrap procedure anyway; once you're decompressing, it's trivial to add validation. There is no need for the "hardcoded drivers" (what an absurd concept) or other strawmen you suggest.
It's an IEEE standard, moron. Do you know what that means? The IEEE goes to extraordinary lengths to solicit and incorporate input from interested parties, many of whom I'm sure are pretty well qualified in their fields. We're not talking about some obscure closed trade group here. IEEE standards are in many ways more open than the not-really-standards of open source. Without IEEE standards we probably wouldn't be talking. How do you think your packets get to slashdot? In large part you owe thanks to IEEE for that.
It's your claim, that the process was somehow not open, that is absurd and that requires proof. Get to it.
You just don't know anything about peer review, do you? How many of these sorts of activities have you participated in? The fact is that when you're dealing with complex new technology people sometimes make mistakes. Sometimes the mistakes are real howlers in retrospect. That's life. How many problems do you suppose these guys anticipated and dealt with that you would have flubbed if you'd been in their place? It's really easy to jeer from the peanut gallery, with full benefit of hindsight, but really people who do that are just being pricks.
No, really, try to give us a responsible rebuttal, instead of trying to substitute sneering for reasoning. Try, anyway. What you dismissed so flippantly is actually a very hot issue among security professionals: who gets to find out first?
Now, I knew when I suggested it that the "tell the vendors" approach wouldn't be very popular here on ScriptKiddieDot, but that doesn't make it a troll (and neither does calling it one). It's worth considering how this audience differs from the Real World. For one, the attitude here is "openness at all costs". There's no room allowed for discretion or careful handling of delicate issues. No, I'm not talking about "security through obscurity" because that never works. What I'm talking about is giving the vendors a reasonable timeframe in which to fix problems before letting every black hat in the world have the info. Let's face it, for every white hat on this site there are probably a hundred black hats, and I doubt that there's a single person involved in this discussion in a position to do good rather than harm with this information. How do you think it benefits anyone but the script kiddies to publicize this problem in this fashion? It doesn't help the problems get fixed any faster, it just maximizes the damage that gets done before the problem is fixed. Screw your "information wants to be free" dogma, and think about social implications for once.
In case you missed it the first time, and the second time, let me repeat a third time: I agree that there's cause for concern in this. Nobody's disputing that. What pisses me off is that people are trying to enhance their own images by panicmongering. The actual security threat here has not been shown to be effectively distinguishable from zero, and yet these people are acting like any semi-literate cracker might already have everyone's credit card numbers. Believe me, we're all threatened much more by existing security problems in the wired network than by any implications of these findings. If there's one thing that's obvious from all this, it's that the biggest security problem is people not even using the security facilities available to them.
Can you explain this further? I was unaware of any dependency between 802.11b and DNS, and I certainly didn't have to make any DNS changes to get my setup working - including full encryption. Is this an optional part, perhaps related only to the key-distribution you give as concern #1?
Hm. Looked fine in preview, but something seems to've been lost. What I meant to say was "for a totally saturated access point".
Well, yeah. I am. ;-)
I guess I could claim that I was testing the transmitter's range or something, but it really was just a "because I can" sort of thing. I don't expect I'll be making a habit of it, though it might be handy next time I get a bad burrito or something and expect an extended bathroom stay.