I took another look at the link to the paper provided in cid #13 (thanks!) and here are some observations.
The first attack follows directly from the above observation. A passive eavesdropper can intercept all wireless traffic, until an IV collision occurs.
"IV" is "initialization vector" and is the same as what is elsewhere called a "salt". The IV is 24 bits; in a previous paragraph the authors had calculated that for a access point an IV is likely to get reused after about five hours. From this we're apparently supposed to conclude that it's a trivial matter to store every packet until an IV collision occurs, and then use the contents of both packets to recover plaintext. They even seem to be aware that two packets often won't be enough, but fail to mention that you need to save and search another five hours' worth of peak-bandwidth traffic to get anywhere in that case.
To be fair, they do point out a pretty serious flaw in a particular implementation of 802.11b, specifically Lucent's, which sets the IV to zero when the card is initialized and merely increments it for each packet. That does indeed make life way too easy for crackers.
we have been able to successfully intercept WEP-encrypted transmissions by changing the configuration of the drivers. We were able to confuse the firmware enough that the ciphertext (encrypted form) of unrecognized packets was returned to us
I would say that this is likely to be well beyond the capabilities of most script kiddies, and is probably pretty easy for 802.11b equipment vendors to address.
Many 802.11 products come with programmable firmware, which can be reverse-engineered and modified to provide the ability to inject traffic to attackers. Granted, such reverse-engineering is a significant time investment (we have not done this ourselves)
Damn right they haven't. Writing drivers is enough of a pain when the hardware engineer is sitting right next to you. It's harder when you have no access to hardware docs, and harder still when the hardware vendor might actively be attempting to thwart your efforts.
The real problem is not in the paper itself, though, but in the way it was reported. Consider this conclusion, from the paper:
The protocol's problems is a result of misunderstanding of some cryptographic primitives and therefore combining them in insecure ways. These attacks point to the improtance of inviting public review from people with expertise in cryptographic protocol design; had this been done, the problems stated here would have surely been avoided.
Yeah, like there have never been any problems discovered in crypto products from the self-appointed experts. Uh huh. But I'll let that slide. Now, for contrast, here's an excerpt from the ZDnet article:
."During the design process, the crypto community wasn't invited to participate," says Goldberg, now chief scientist at Zero Knowledge Systems Inc., a privacy-software firm in Montreal.
That's a pretty inflammatory statement, and apparently not far from being an outright lie. It was irresponsible (or possibly venal) of Ian Goldberg to make such a statement, and doubly so for WSJ's Jared Sandberg. As I said before, there is a matter for serious concern here, but the scaremongering from these people is not helping. 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.
802.11 already uses spread-spectrum technology. I believe that for 2Mbps 802.11 it's "frequency hopping" SS, and for 11Mbps 802.11b it's "direct sequence" SS. No, I don't really know the difference. What's important is that these attacks are apparently possible despite the use of spread-spectrum technology.
I think a lot of people just don't realize how wireless networking can change the way you feel about computing. Until you've actually surfed from the couch, continued reading on a laptop while you get a drink out of the fridge - or even take a leak - all unencumbered and uninterrupted, I don't think you can fully appreciate the difference. It's amazing to think how accustomed we had all become to the limitations of wired connectivity.
Now this comes along. Right or wrong technically, real or imaginary, this will slow adoption of wireless networking technology. The risk-averse business types who make decisions about deployment will hesitate, so there will be fewer access points both within organizations and in public spaces (hotels, airport lounges, and so on). Companies will forbid their employees to use wireless networking when on the road, or simply not provide the equipment necessary for them to do so. I expect email from our own IT department any moment telling me that wireless is off limits until "investigation of this matter is complete" (which will take months).
All this loss of convenience occurs because a bunch of people who felt left out of a public IEEE standardization process have said the sky is falling. If you read the article, you'll notice that there's practically no real information that would allow anyone to judge how serious the risk really is, and there's a lot of scaremongering about how easy it will be for "script kiddies" to get the right software. How about the hardware? Yes, folks, you need extra hardware to do this, and you also need to be physically proximate to the target. I'm not at all convinced that the script kiddies will be able to take advantage of this hole - whatever it really is.
Yes, it sucks that there's any hole of any size in WEP, and even if the script kiddies can't exploit it the professional crooks might, but the sensationalistic way this is being reported is simply not responsible.
You say a lot about why ARM/XScale processors are not used for general-purpose - and particularly mobile - computing, but not much about why they can not or should not be used in such applications. Seems to me that a processor that's a little slower than a Pentium/Athlon but that dissipates a ton less power/heat would be a big win in many general-purpose environments. Crusoe, which has similar characteristics, is already being touted for both mobile and high-density server applications - by people who know a lot more about pipelines and functional units than you do.
So, the question is: what's wrong with considering an XScale processor for general-purpose use? Is there a real technical stumbling block involved, or is it just a matter of "you should follow the pack"?
A zero-sum game is one in which someone winning requires that someone else lost. Cooperative games, in which players can win without others losing (or vice versa), are therefore not zero-sum.
Zero-sum or not has as much to do with the way people play as with the game itself. For example, some have suggested that RPGs are zero-sum but it's still entirely possible for people to compete and declare a winner based on gold or experience points. That will always be true as long as there's any kind of score involved, and if there's not then people can invent their own scoring methods. On the other side of the coin, zero-sum games can often be played cooperatively or just playfully if some or all participants simply decide they don't care about the score. I've messed up many games of Scrabble just so I could play cool (or rude) words, I've spent my time in racing simulations going backwards and trying for a spectacular collision, and so on. Some games - e.g. frisbee - or puzzles or market simulations can be approached either competitively or cooperatively according to players' wishes. Whether some computer games are cooperative or competitive depends on whether you consider the computer to be a player.
The point is that you can almost always decide whether there are "winners" or "losers" in any game, regardless of the game's internal definitions. IMO it's as important for people to know they can keep their own score as it is to know that not all games are zero-sum.
I was reading the same document, but mistook "The Journaled File System (JFS) provides a log-based, byte-level file system that was developed for transaction-oriented, high performance systems" as meaning that it was a log-structured filesystem.
No, those are hard to find nowadays. Off the top of the head I can't think of any that are used in production.
if you read on, you find that you can get essentially data-level integrity using synchronous writes. I don't know how this affects performance on that filesystem, though.
The effect on performance would be pretty horrendous - worse than data journaling, for most access patterns. Databases and such, which have their own ways of doing caching and logging and so on, use sync FS writes, but it's pretty bad for anything else.
many OS environments actually *DO* have fully journaled fs (OS/400 and BeOS come to mind)
I can't find anything authoritative that answers this question for BeFS, and I can't be bothered looking for anything on OS/400 because I'm tired from debunking the exact same claim for IBM XFS and SGI XFS. Pardon me if I remain skeptical. Do you have anything to back up your claim re: BeFS, or do you just "believe" it without basis like the previous poster did about JFS/XFS?
In any case, whether any claims pan out regarding data-journaling filesystems exist on exotic OSes, the fact remains that Linux doesn't have one. That puts Linux in exactly the same boat as NT, which means that criticizing NT vis-a-vis Linux for only journaling metadata is an extremely poor piece of Linux advocacy. That's the topic of the thread, just in case anyone forgot.
I believe XFS and JFS are both journaled in this way.
And based on what do you believe that? Here's an excerpt from an IBM document:
First, JFS only logs operations on meta-data, so replaying the log only restores the consistency of structural relationships and resource allocation states within the file system.
I can't find anything quite as authoritative for XFS, but there is this, from an SGI document:
The log section (or area, if it is internal to the data section) is used to store changes to filesystem metadata while the filesystem is running
If the log section contained data, one would certainly expect them to mention it. There's also this, from a copy of the Fileystems HOWTO:
File systems update their structural information (called metadata) by synchronous writes...A journaling file system uses a separate area called a log or journal. Before metadata changes are actually performed, they are logged to this separate area
Again, the reference is to metadata but not data. As a professional filesystems developer, I know that even the overhead of journaling metadata is a big problem for journaled filesystem implementors trying to provide performance competitive with non-journaled filesystems. Journaling the data as well would be absolutely horrendous, and I certainly think I would have heard if there had been some breakthrough allowing this to be done efficiently.
There are some filesystem technologies that do provide safety for data in addition to metadata. Log-structured filesystems can include this feature, though they're somewhat out of vogue right now. The only current effort I know of in this direction is the atomic update ("phase tree") methodology in Tux2.
I feel I have lots to learn from older/wiser programmers. Problem is that they're a rarity these days
Too true, too true. I've been somewhat lucky that way, I guess. Part of it is that I'm a kernel hacker, and the growth in my specialty hasn't been an explosive as in yours. It's a real problem, when such growth occurs, to find enough mentors and examples and even experienced journeymen.
After that they move into management. And I don't believe that it's an industry trend to recognize this is a bad thing
This is very likely to be a cultural difference between your specialty and mine, though I agree that good managers are probably the rarest beasts in the whole software-industry menagerie.
I shouldn't know more than people older than me, people with better degrees, etc. but usually they're the ones asking ME for the answers to basic day-to-day questions.
If I were you I'd be extremely careful of how I interpreted that. It could well be that they're asking you questions because the topic falls under your specialty rather than theirs. This occurs on your intellectual turf; that's why people hire consultants. If you went to visit them on their own "home ground" you might have a very different experience. Then it might be you asking lots of questions about what they consider basic knowledge.
I think the reason I like XP is that it's different. It's the anti-methodology. It's not about ceremony or documentation, it's about coordinating people's attitudes, feelings, and fears into a framework that allows people to create quality software.
I must disagree. One man's coordination is another man's coercion, and when you're talking about coordinating people's attitudes and feelings that can be far more invasive than merely coordinating their actions. This whole thread has been an example of how strongly many XP proponents insist on adhering to every minor detail and nuance of the XP methodology.
One of the frustrations with skeptics is when one paints it as "the same as all the other" failed methodologies
Yes. Eventually, skepticism segues into argument by false analogy. Short of that, though, the skeptics' concerns need to be addressed in a forthright manner if one hopes to win them over.
Some of the critiques from Tom Gilb, Craig Larman, etc, espected industry experts, are definite food for thought. But slashdot arguments that effectively say "don't read books!", or "it's bunk, just hire talented developers!"
Absolutely, in the case of the former. Mostly, for the latter, because there is a grain of truth to that. Another poster pointed out the dangers of "cherry-picking" your case studies, rejecting any failures from the sample for specious reasons. I've already tried to point out that a methodology which depends on a uniform higher-than-average level of skill/motivation among developers can be considered fragile. By definition, most teams are not composed of such developers.
So how do you maximize what little talent there is? You use a process to align people's strengths and minimize their weaknesses.
Exactly. For some teams XP might maximize the talent available. For other teams - I would say most teams - it won't, for reasons I've given elsewhere, and it may even be harmful.
NT's data is not journaled; only it's directory structure is. In NT, if power goes out during a file write, data can be corrupted.
This is true of just about any journaled FS, except that data is usually lost rather than corrupted. Data-journaling FSes are extremely rare, mostly because of performance issues, and the only one I know of that's under consideration is Tux2 (which is technically atomic-update rather than journaling, but close enough for this discussion). Criticizing MS for this feature, which it shares with the supposed alternatives, is misguided.
The easy stuff gets done over and over again while the hard stuff gets done once
It's not just the hard stuff that doesn't get done; it's all the boring or tedious or unpleasant stuff as well. Specs. Test tools. Documentation. Standards compliance. Everybody wants to be coding, and only on the easy whiz-bang GUI/web cruft, and very few want to hunker down and do the stuff that commercial OS vendors pay people to do even though it drives them nuts.
Re:So why are they using Linux DNS Servers?
on
Linux Is Going Down
·
· Score: 4
That's not quite the same as saying that Microsoft uses Linux. Microsoft has outsourced certain functionality to Akamai, which uses Linux. The reason the distinction matters is that Microsoft gets a bunch more from their deal with Akamai than just a bunch of Linux boxes. They get a certain level of guarantees regarding functionality, and it's up to Akamai to make good on those guarantees regardless of the quality of the underlying technology.
Microsoft may in fact use Linux in other areas - I've heard that Hotmail or some such was Linux-based - but this particular piece of information about Akamai DNS servers doesn't really mean much.
Usually [threading]'s overused for things (like handling asynchronous behavior (i.e. network/socket communication))
Unfortunately, writing unit tests for programs with asynchronous behavior is likely to be even more difficult than writing unit tests for programs with threads, so the objection re: XP is still valid.
You said you weren't interested in continuing in another thread.
The AC might have been reading in non-threaded mode and seen the posts juxtaposed despite their being in different subthreads. It might also have been one of the people who follows my posts closely. There seem to be quite a few; sometimes they turn out to be people I know, but more often it's a mystery. Every time I get involved in a discussion a couple of "regulars" seem to pop up - sometimes on the opposite side, invariably well informed wrt my posting history. I guess being a prominent devil's advocate gets some people's attention. OTOH, it might just have been someone who saw a good flame war going on and tracked it for a while before jumping in. There are all sorts of possibilities.
In any case, you can rest assured that I don't need to resort to such trickery. I'm not exactly afraid to express controversial opinions right out in the open, or to flame people - as you have seen. Why would I bother posting as an AC? If you ask me, the idea sounds just a tad paranoid. Relax; I'm not that motivated to "get" you.
this "working up the ranks" notion is being obliterated by people that have a higher learning capacity than those that *did* work their way up through the ranks.
That's a myth. Sure, there are a lot of people who think they're smarter than anyone who went before (or anyone else, period) but most of those people are wrong. What do you think, that somehow people from past generations were uniformly stupider than those in the current generation? Do you believe that you just happened to be lucky enough to be born during a period of rapid evolution for the human species?
No, 'fraid not. Older programmers are not, statistically speaking, stupider than younger ones. They may have learned programming when the state of the art was far behind where it is today, but their capacity for learning is no less. For every old dog I've known who couldn't or wouldn't learn new tricks, I've met at least two young pups who think they know everything there is to know after two years (or less) doing easy types of programming. The difference is that experience always counts for something. It may not count as much as a solid grounding in the latest tools and techniques, but everyone picks up some sort of useful tricks in a couple of decades of real work - in any field, not just programming.
The point, as so many other posters have made, is that it's at least as foolish for you to dismiss the concerns of the old hands as it would be for them to dismiss XP, without examining the essentials. They have good reasons to be skeptical. Anyone who has been in this business has seen people talk about all sorts of methodologies exactly the same way folks here are talking about XP now, and most of the talk has turned out to be just hot air. If you want to convince those people of how great XP is you'll have to address their concerns head-on...and you do need to convince them. Those skeptics are going to be or in decision-making positions for a good many years yet, as you try to deploy XP, and if their concerns are not addressed it will be impossible to develop the spirit that is necessary for XP to work. As long as you keep making flippant remarks about learning capacity, neither they nor people your own age will want to get involved with a methodology that requires them to work closely with you.
BTW, since it does seem slightly relevant, I'm 35. This would seem to put me right between the "old dogs" and the "young pups".
part of accomplishing this is setting up educational resources so they DON'T have to work through the ranks -- mainly because those that do generally become managers -- they don't remain programmers
I think there's a growing recognition in the industry that trying to turn good engineers into managers is a dumb idea. What you end up doing is depriving yourself of a good engineer's technical contributions, and getting yourself a medium-to-lousy manager in return (because the optimal temperaments for top-level developers and for managers are almost opposite). This recognition is a good thing.
This also brings me to another point I've been pondering. Our love for egalitarian solutions seems to have become an actual phobia about all forms of hierarchy. Just look at how client/server has given way to P2P. Much of the appeal of XP seems to be that the pair programming approach replaces a more traditional approach in which senior engineers look over the shoulders of junior ones to keep them out of the weeds. Just say those words a couple of times...senior, junior...in today's intellectual climate even the words themselves seem slightly taboo. People love the idea of doing away with such distinctions, even though they've proven very useful. I have to wonder whether this is in part because, with the explosion of the Internet and e-everything, so many shops just don't have any senior engineers and they have to find methodologies that work without them. To be fair, I also wonder if some of the resistance to methodologies like XP is rooted in senior engineers who thoroughly enjoy being "on top" in the traditional model and worry about losing that. I wonder, and I'm sure there's a grain of truth there, but I don't think it's as much of a factor as distrust of "magic bullet" salesmen. I still think that, in an organization that does have the benefit of experienced technical leadership, pairwise programming might be a costly solution to a minor or nonexistent problem.
Again, you may have an answer to this, but the objection - in your colleagues' minds, not necessarily in mine - must be overcome if you want XP to be adopted. You can't just say "read the book" either. You - not "you" specifically but "you" referring to all the XP proponents out there - need to learn how to be effective XP advocates in your own right, and in general the way people have been going about it on this thread so far is definitely not going to be very effective in the workplace. The first thing an effective advocate has to do is learn and accept and admit the limitations and drawbacks of the thing they're advocating, so that they don't immediately lose credibility with people who are accustomed to questioning things and looking for weaknesses. After all, questioning things and looking for weakness are traits we encourage in developers.
If you want a serious discussion about XP, you're not going to get it on Slashdot.
I don't see why not. Yes, there's a lot of crap that gets posted here, but I have had very satisfying conversations here. I've made valuable professional contacts with others in my specialty. I've met people who have offered me money to express my views from a better kind of soapbox, I've met people who've offered me jobs, etc. That kind of thing doesn't happen often, but it does happen. Now that I'm less distracted by your flamage, I'm actually working in another window on a more serious post that I hope will rekindle a little bit of thoughtful discussion here. Or maybe not. It's a small investment, really, one that I don't mind making as a form of recreation, and every once in a while it does pay off.
Do you know about despair.com? One of their slogans is The common element in all of your dysfunctional relationships is you. Cute, huh? I believe I also quoted As ye sow, so shall ye reap to you earlier. In all seriousness, I'd like to suggest that if you never have rewarding interactions here like I do, then your attitude that this is "just a place to flame" might be the reason. If you'd do something besides flame once in a while, you might be surprised at the reaction you get.
You, on the other hand, seem incapable of making anything other than personal attacks.
There you go again. You have yourself commented favorably on some of my earlier posts, and yet now you claim that I "seem incapable" of posting anything but meta-argument. How can anyone have faith in the statements of someone who would so casually contradict themselves to insult an opponent?
I used the term ad hominem in a way which might be technically incorrect
And technical correctness doesn't matter? You used the term, you should be willing to accept correction on that use. Instead, you rejected the first correction, and have been singularly ungracious in accepting the second. Is that how you react when someone corrects a minor error in your code or your specs? To bring this back on topic, all of the chief XP advocates agree that having the proper attitude is critical to success deploying XP. How can you champion XP by so profligately displaying an attitude that would prevent it from working? That, along with everything else, undermines belief in the sincerity of your enthusiasm for XP. You seem much more enthusiastic about "winning" at all costs than about standing up for any kind of ideal or standard or methodology.
I'm sure we're boring and/or annoying everyone else with this, though. There are better ways and places to discuss the deficiencies in your manner of communication than in a public forum like this. Feel free to send me email - my address is easy to find - because I don't intend to respond to your flamebait here any more.
In fact, this is a prime example. "I don't like software methodology because the people who do it either wear suits or they're trying to be cool."
If I may jump in to this little digression...that's a far from prime example. The AC was correct; there was no ad hominem. An ad hominem is an attack against the credentials of a person making an argument. The term does not apply to any arbitrary adverse portrayal of a participant, let alone of third parties. The construction you present - not an accurate paraphrase of the original, but we've come to expect that of you - may be illogical and unconvincing, but it's not an ad hominem. Your use of the term was, simply and bluntly, incorrect.
I don't know whether you believe in "magic bullets" in software, but you certainly seem to think you can find one in this debate. Ain't gonna happen, kid. The only way you're going to get your point across is to take the slow road - stay on topic, stay honest, and convince people by introducing new facts connected with logic. "Rhetoric bombs" such as random insertion of Latin phrases won't do it for you.
I don't generally accuse people who merely misunderstand my posts of lying. Yet again, evidence of that is abundant, accessible, and contrary to your portrayal. With this and other comments, you in particular have shown a propensity for misrepresentation and strawman construction that is hard to explain as innocent misunderstanding. I call 'em as I see 'em, so if you want me to stop calling you a liar then stop lying. Stop misrepresenting opponents' positions, stop claiming references are obscure when they're right in front of your nose, stop claiming contradictions where there are none, stop claiming that other people aren't addressing the issues when they are, etc. etc. etc.
As ye sow so shall ye reap, and you have some nasty rhetorical habits that fully explain how you have been treated. Fix them and people will start listening to what you have to say. I'm sure you have much of value to say on this and other subjects, but with your current writing style it's just too much of a drag to separate the rare wheat from the abundant chaff. Grow up yourself - and that's meant quite sincerely. You're not doing yourself any favors by acting this way.
If I'd known that the link contained opinions which completely disagreed with the opinions you were posting at the time I would have read it
If you misunderstand/misrepresent what someone's saying, and then the person disagrees with the distorted version you present, that's not a contradiction. My opinion and my expression of it have remained consistent throughout this thread, and only your understanding of them has changed.
If you're backing down from your earlier position that dismisses XP out-of-hand
I have never dismissed XP out of hand. In this entire thread, and in the previous thread, I have been quite explicit about that. I believe XP is a good thing, just not as good (not as robust, not as broadly applicable) as some would have us believe. I've said it time and time again, so please stop lying.
In any case, all you're rebutting here are my side comments
It's bad to lie. It's just plain dumb to lie so obviously. Anyone reading your post is just a click away from its parent, which anyone can see is at least as on-topic and informative as anything you've "contributed". If my reply fell short of my own usual standards for content, it's because I was replying to something that itself lacked substantive content - in particular to your earlier misrepresentation of my opinion. I notice you've dropped that particular theme since it was revealed as mere fabrication.
Do you have anything worthwhile to contribute to this conversation, or is it all like this? I'm usually glad to engage in discussion about programming methodologies, but this...this, I'm tired of after only two or three posts. Even as exercises in flaming for its own sake, your posts are pathetic.
You're referring here to a post on another thread.
What, another post from "NT Christ" full of flame, with not one whit about methodologies? What a surprise! And I expected so much better from you.
FYI, the article may have been originally written for another (related) thread, but was explicitly referenced in this thread, right here in the great-grandparent of your own first attempt at flaming. If it's too difficult for you to click on "User #xxx Info" and find it, surely you could look at the head of the thread to which you're responding. No, guess not. Not even that smart, are you? It may have been hard for you to find, but that doesn't make it an obscure reference.
Slashdot Mirror
I took another look at the link to the paper provided in cid #13 (thanks!) and here are some observations.
"IV" is "initialization vector" and is the same as what is elsewhere called a "salt". The IV is 24 bits; in a previous paragraph the authors had calculated that for a access point an IV is likely to get reused after about five hours. From this we're apparently supposed to conclude that it's a trivial matter to store every packet until an IV collision occurs, and then use the contents of both packets to recover plaintext. They even seem to be aware that two packets often won't be enough, but fail to mention that you need to save and search another five hours' worth of peak-bandwidth traffic to get anywhere in that case.
To be fair, they do point out a pretty serious flaw in a particular implementation of 802.11b, specifically Lucent's, which sets the IV to zero when the card is initialized and merely increments it for each packet. That does indeed make life way too easy for crackers.
I would say that this is likely to be well beyond the capabilities of most script kiddies, and is probably pretty easy for 802.11b equipment vendors to address.
Damn right they haven't. Writing drivers is enough of a pain when the hardware engineer is sitting right next to you. It's harder when you have no access to hardware docs, and harder still when the hardware vendor might actively be attempting to thwart your efforts.
The real problem is not in the paper itself, though, but in the way it was reported. Consider this conclusion, from the paper:
Yeah, like there have never been any problems discovered in crypto products from the self-appointed experts. Uh huh. But I'll let that slide. Now, for contrast, here's an excerpt from the ZDnet article:
That's a pretty inflammatory statement, and apparently not far from being an outright lie. It was irresponsible (or possibly venal) of Ian Goldberg to make such a statement, and doubly so for WSJ's Jared Sandberg. As I said before, there is a matter for serious concern here, but the scaremongering from these people is not helping. 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.
802.11 already uses spread-spectrum technology. I believe that for 2Mbps 802.11 it's "frequency hopping" SS, and for 11Mbps 802.11b it's "direct sequence" SS. No, I don't really know the difference. What's important is that these attacks are apparently possible despite the use of spread-spectrum technology.
I think a lot of people just don't realize how wireless networking can change the way you feel about computing. Until you've actually surfed from the couch, continued reading on a laptop while you get a drink out of the fridge - or even take a leak - all unencumbered and uninterrupted, I don't think you can fully appreciate the difference. It's amazing to think how accustomed we had all become to the limitations of wired connectivity.
Now this comes along. Right or wrong technically, real or imaginary, this will slow adoption of wireless networking technology. The risk-averse business types who make decisions about deployment will hesitate, so there will be fewer access points both within organizations and in public spaces (hotels, airport lounges, and so on). Companies will forbid their employees to use wireless networking when on the road, or simply not provide the equipment necessary for them to do so. I expect email from our own IT department any moment telling me that wireless is off limits until "investigation of this matter is complete" (which will take months).
All this loss of convenience occurs because a bunch of people who felt left out of a public IEEE standardization process have said the sky is falling. If you read the article, you'll notice that there's practically no real information that would allow anyone to judge how serious the risk really is, and there's a lot of scaremongering about how easy it will be for "script kiddies" to get the right software. How about the hardware? Yes, folks, you need extra hardware to do this, and you also need to be physically proximate to the target. I'm not at all convinced that the script kiddies will be able to take advantage of this hole - whatever it really is.
Yes, it sucks that there's any hole of any size in WEP, and even if the script kiddies can't exploit it the professional crooks might, but the sensationalistic way this is being reported is simply not responsible.
Do you mean "cool" figuratively, or literally? Or both? ;-)
You say a lot about why ARM/XScale processors are not used for general-purpose - and particularly mobile - computing, but not much about why they can not or should not be used in such applications. Seems to me that a processor that's a little slower than a Pentium/Athlon but that dissipates a ton less power/heat would be a big win in many general-purpose environments. Crusoe, which has similar characteristics, is already being touted for both mobile and high-density server applications - by people who know a lot more about pipelines and functional units than you do.
So, the question is: what's wrong with considering an XScale processor for general-purpose use? Is there a real technical stumbling block involved, or is it just a matter of "you should follow the pack"?
A zero-sum game is one in which someone winning requires that someone else lost. Cooperative games, in which players can win without others losing (or vice versa), are therefore not zero-sum.
Zero-sum or not has as much to do with the way people play as with the game itself. For example, some have suggested that RPGs are zero-sum but it's still entirely possible for people to compete and declare a winner based on gold or experience points. That will always be true as long as there's any kind of score involved, and if there's not then people can invent their own scoring methods. On the other side of the coin, zero-sum games can often be played cooperatively or just playfully if some or all participants simply decide they don't care about the score. I've messed up many games of Scrabble just so I could play cool (or rude) words, I've spent my time in racing simulations going backwards and trying for a spectacular collision, and so on. Some games - e.g. frisbee - or puzzles or market simulations can be approached either competitively or cooperatively according to players' wishes. Whether some computer games are cooperative or competitive depends on whether you consider the computer to be a player.
The point is that you can almost always decide whether there are "winners" or "losers" in any game, regardless of the game's internal definitions. IMO it's as important for people to know they can keep their own score as it is to know that not all games are zero-sum.
No, those are hard to find nowadays. Off the top of the head I can't think of any that are used in production.
The effect on performance would be pretty horrendous - worse than data journaling, for most access patterns. Databases and such, which have their own ways of doing caching and logging and so on, use sync FS writes, but it's pretty bad for anything else.
I can't find anything authoritative that answers this question for BeFS, and I can't be bothered looking for anything on OS/400 because I'm tired from debunking the exact same claim for IBM XFS and SGI XFS. Pardon me if I remain skeptical. Do you have anything to back up your claim re: BeFS, or do you just "believe" it without basis like the previous poster did about JFS/XFS?
In any case, whether any claims pan out regarding data-journaling filesystems exist on exotic OSes, the fact remains that Linux doesn't have one. That puts Linux in exactly the same boat as NT, which means that criticizing NT vis-a-vis Linux for only journaling metadata is an extremely poor piece of Linux advocacy. That's the topic of the thread, just in case anyone forgot.
And based on what do you believe that? Here's an excerpt from an IBM document:
I can't find anything quite as authoritative for XFS, but there is this, from an SGI document:
If the log section contained data, one would certainly expect them to mention it. There's also this, from a copy of the Fileystems HOWTO:
Again, the reference is to metadata but not data. As a professional filesystems developer, I know that even the overhead of journaling metadata is a big problem for journaled filesystem implementors trying to provide performance competitive with non-journaled filesystems. Journaling the data as well would be absolutely horrendous, and I certainly think I would have heard if there had been some breakthrough allowing this to be done efficiently.
There are some filesystem technologies that do provide safety for data in addition to metadata. Log-structured filesystems can include this feature, though they're somewhat out of vogue right now. The only current effort I know of in this direction is the atomic update ("phase tree") methodology in Tux2.
Too true, too true. I've been somewhat lucky that way, I guess. Part of it is that I'm a kernel hacker, and the growth in my specialty hasn't been an explosive as in yours. It's a real problem, when such growth occurs, to find enough mentors and examples and even experienced journeymen.
This is very likely to be a cultural difference between your specialty and mine, though I agree that good managers are probably the rarest beasts in the whole software-industry menagerie.
If I were you I'd be extremely careful of how I interpreted that. It could well be that they're asking you questions because the topic falls under your specialty rather than theirs. This occurs on your intellectual turf; that's why people hire consultants. If you went to visit them on their own "home ground" you might have a very different experience. Then it might be you asking lots of questions about what they consider basic knowledge.
I must disagree. One man's coordination is another man's coercion, and when you're talking about coordinating people's attitudes and feelings that can be far more invasive than merely coordinating their actions. This whole thread has been an example of how strongly many XP proponents insist on adhering to every minor detail and nuance of the XP methodology.
Yes. Eventually, skepticism segues into argument by false analogy. Short of that, though, the skeptics' concerns need to be addressed in a forthright manner if one hopes to win them over.
Absolutely, in the case of the former. Mostly, for the latter, because there is a grain of truth to that. Another poster pointed out the dangers of "cherry-picking" your case studies, rejecting any failures from the sample for specious reasons. I've already tried to point out that a methodology which depends on a uniform higher-than-average level of skill/motivation among developers can be considered fragile. By definition, most teams are not composed of such developers.
Exactly. For some teams XP might maximize the talent available. For other teams - I would say most teams - it won't, for reasons I've given elsewhere, and it may even be harmful.
This is true of just about any journaled FS, except that data is usually lost rather than corrupted. Data-journaling FSes are extremely rare, mostly because of performance issues, and the only one I know of that's under consideration is Tux2 (which is technically atomic-update rather than journaling, but close enough for this discussion). Criticizing MS for this feature, which it shares with the supposed alternatives, is misguided.
It's not just the hard stuff that doesn't get done; it's all the boring or tedious or unpleasant stuff as well. Specs. Test tools. Documentation. Standards compliance. Everybody wants to be coding, and only on the easy whiz-bang GUI/web cruft, and very few want to hunker down and do the stuff that commercial OS vendors pay people to do even though it drives them nuts.
That's not quite the same as saying that Microsoft uses Linux. Microsoft has outsourced certain functionality to Akamai, which uses Linux. The reason the distinction matters is that Microsoft gets a bunch more from their deal with Akamai than just a bunch of Linux boxes. They get a certain level of guarantees regarding functionality, and it's up to Akamai to make good on those guarantees regardless of the quality of the underlying technology.
Microsoft may in fact use Linux in other areas - I've heard that Hotmail or some such was Linux-based - but this particular piece of information about Akamai DNS servers doesn't really mean much.
Unfortunately, writing unit tests for programs with asynchronous behavior is likely to be even more difficult than writing unit tests for programs with threads, so the objection re: XP is still valid.
The AC might have been reading in non-threaded mode and seen the posts juxtaposed despite their being in different subthreads. It might also have been one of the people who follows my posts closely. There seem to be quite a few; sometimes they turn out to be people I know, but more often it's a mystery. Every time I get involved in a discussion a couple of "regulars" seem to pop up - sometimes on the opposite side, invariably well informed wrt my posting history. I guess being a prominent devil's advocate gets some people's attention. OTOH, it might just have been someone who saw a good flame war going on and tracked it for a while before jumping in. There are all sorts of possibilities.
In any case, you can rest assured that I don't need to resort to such trickery. I'm not exactly afraid to express controversial opinions right out in the open, or to flame people - as you have seen. Why would I bother posting as an AC? If you ask me, the idea sounds just a tad paranoid. Relax; I'm not that motivated to "get" you.
That's a myth. Sure, there are a lot of people who think they're smarter than anyone who went before (or anyone else, period) but most of those people are wrong. What do you think, that somehow people from past generations were uniformly stupider than those in the current generation? Do you believe that you just happened to be lucky enough to be born during a period of rapid evolution for the human species?
No, 'fraid not. Older programmers are not, statistically speaking, stupider than younger ones. They may have learned programming when the state of the art was far behind where it is today, but their capacity for learning is no less. For every old dog I've known who couldn't or wouldn't learn new tricks, I've met at least two young pups who think they know everything there is to know after two years (or less) doing easy types of programming. The difference is that experience always counts for something. It may not count as much as a solid grounding in the latest tools and techniques, but everyone picks up some sort of useful tricks in a couple of decades of real work - in any field, not just programming.
The point, as so many other posters have made, is that it's at least as foolish for you to dismiss the concerns of the old hands as it would be for them to dismiss XP, without examining the essentials. They have good reasons to be skeptical. Anyone who has been in this business has seen people talk about all sorts of methodologies exactly the same way folks here are talking about XP now, and most of the talk has turned out to be just hot air. If you want to convince those people of how great XP is you'll have to address their concerns head-on...and you do need to convince them. Those skeptics are going to be or in decision-making positions for a good many years yet, as you try to deploy XP, and if their concerns are not addressed it will be impossible to develop the spirit that is necessary for XP to work. As long as you keep making flippant remarks about learning capacity, neither they nor people your own age will want to get involved with a methodology that requires them to work closely with you.
BTW, since it does seem slightly relevant, I'm 35. This would seem to put me right between the "old dogs" and the "young pups".
I think there's a growing recognition in the industry that trying to turn good engineers into managers is a dumb idea. What you end up doing is depriving yourself of a good engineer's technical contributions, and getting yourself a medium-to-lousy manager in return (because the optimal temperaments for top-level developers and for managers are almost opposite). This recognition is a good thing.
This also brings me to another point I've been pondering. Our love for egalitarian solutions seems to have become an actual phobia about all forms of hierarchy. Just look at how client/server has given way to P2P. Much of the appeal of XP seems to be that the pair programming approach replaces a more traditional approach in which senior engineers look over the shoulders of junior ones to keep them out of the weeds. Just say those words a couple of times...senior, junior...in today's intellectual climate even the words themselves seem slightly taboo. People love the idea of doing away with such distinctions, even though they've proven very useful. I have to wonder whether this is in part because, with the explosion of the Internet and e-everything, so many shops just don't have any senior engineers and they have to find methodologies that work without them. To be fair, I also wonder if some of the resistance to methodologies like XP is rooted in senior engineers who thoroughly enjoy being "on top" in the traditional model and worry about losing that. I wonder, and I'm sure there's a grain of truth there, but I don't think it's as much of a factor as distrust of "magic bullet" salesmen. I still think that, in an organization that does have the benefit of experienced technical leadership, pairwise programming might be a costly solution to a minor or nonexistent problem.
Again, you may have an answer to this, but the objection - in your colleagues' minds, not necessarily in mine - must be overcome if you want XP to be adopted. You can't just say "read the book" either. You - not "you" specifically but "you" referring to all the XP proponents out there - need to learn how to be effective XP advocates in your own right, and in general the way people have been going about it on this thread so far is definitely not going to be very effective in the workplace. The first thing an effective advocate has to do is learn and accept and admit the limitations and drawbacks of the thing they're advocating, so that they don't immediately lose credibility with people who are accustomed to questioning things and looking for weaknesses. After all, questioning things and looking for weakness are traits we encourage in developers.
I don't see why not. Yes, there's a lot of crap that gets posted here, but I have had very satisfying conversations here. I've made valuable professional contacts with others in my specialty. I've met people who have offered me money to express my views from a better kind of soapbox, I've met people who've offered me jobs, etc. That kind of thing doesn't happen often, but it does happen. Now that I'm less distracted by your flamage, I'm actually working in another window on a more serious post that I hope will rekindle a little bit of thoughtful discussion here. Or maybe not. It's a small investment, really, one that I don't mind making as a form of recreation, and every once in a while it does pay off.
Do you know about despair.com? One of their slogans is The common element in all of your dysfunctional relationships is you. Cute, huh? I believe I also quoted As ye sow, so shall ye reap to you earlier. In all seriousness, I'd like to suggest that if you never have rewarding interactions here like I do, then your attitude that this is "just a place to flame" might be the reason. If you'd do something besides flame once in a while, you might be surprised at the reaction you get.
There you go again. You have yourself commented favorably on some of my earlier posts, and yet now you claim that I "seem incapable" of posting anything but meta-argument. How can anyone have faith in the statements of someone who would so casually contradict themselves to insult an opponent?
And technical correctness doesn't matter? You used the term, you should be willing to accept correction on that use. Instead, you rejected the first correction, and have been singularly ungracious in accepting the second. Is that how you react when someone corrects a minor error in your code or your specs? To bring this back on topic, all of the chief XP advocates agree that having the proper attitude is critical to success deploying XP. How can you champion XP by so profligately displaying an attitude that would prevent it from working? That, along with everything else, undermines belief in the sincerity of your enthusiasm for XP. You seem much more enthusiastic about "winning" at all costs than about standing up for any kind of ideal or standard or methodology.
I'm sure we're boring and/or annoying everyone else with this, though. There are better ways and places to discuss the deficiencies in your manner of communication than in a public forum like this. Feel free to send me email - my address is easy to find - because I don't intend to respond to your flamebait here any more.
If I may jump in to this little digression...that's a far from prime example. The AC was correct; there was no ad hominem. An ad hominem is an attack against the credentials of a person making an argument. The term does not apply to any arbitrary adverse portrayal of a participant, let alone of third parties. The construction you present - not an accurate paraphrase of the original, but we've come to expect that of you - may be illogical and unconvincing, but it's not an ad hominem. Your use of the term was, simply and bluntly, incorrect.
I don't know whether you believe in "magic bullets" in software, but you certainly seem to think you can find one in this debate. Ain't gonna happen, kid. The only way you're going to get your point across is to take the slow road - stay on topic, stay honest, and convince people by introducing new facts connected with logic. "Rhetoric bombs" such as random insertion of Latin phrases won't do it for you.
I don't generally accuse people who merely misunderstand my posts of lying. Yet again, evidence of that is abundant, accessible, and contrary to your portrayal. With this and other comments, you in particular have shown a propensity for misrepresentation and strawman construction that is hard to explain as innocent misunderstanding. I call 'em as I see 'em, so if you want me to stop calling you a liar then stop lying. Stop misrepresenting opponents' positions, stop claiming references are obscure when they're right in front of your nose, stop claiming contradictions where there are none, stop claiming that other people aren't addressing the issues when they are, etc. etc. etc.
As ye sow so shall ye reap, and you have some nasty rhetorical habits that fully explain how you have been treated. Fix them and people will start listening to what you have to say. I'm sure you have much of value to say on this and other subjects, but with your current writing style it's just too much of a drag to separate the rare wheat from the abundant chaff. Grow up yourself - and that's meant quite sincerely. You're not doing yourself any favors by acting this way.
If you misunderstand/misrepresent what someone's saying, and then the person disagrees with the distorted version you present, that's not a contradiction. My opinion and my expression of it have remained consistent throughout this thread, and only your understanding of them has changed.
I have never dismissed XP out of hand. In this entire thread, and in the previous thread, I have been quite explicit about that. I believe XP is a good thing, just not as good (not as robust, not as broadly applicable) as some would have us believe. I've said it time and time again, so please stop lying.
It's bad to lie. It's just plain dumb to lie so obviously. Anyone reading your post is just a click away from its parent, which anyone can see is at least as on-topic and informative as anything you've "contributed". If my reply fell short of my own usual standards for content, it's because I was replying to something that itself lacked substantive content - in particular to your earlier misrepresentation of my opinion. I notice you've dropped that particular theme since it was revealed as mere fabrication.
Do you have anything worthwhile to contribute to this conversation, or is it all like this? I'm usually glad to engage in discussion about programming methodologies, but this...this, I'm tired of after only two or three posts. Even as exercises in flaming for its own sake, your posts are pathetic.
What, another post from "NT Christ" full of flame, with not one whit about methodologies? What a surprise! And I expected so much better from you.
FYI, the article may have been originally written for another (related) thread, but was explicitly referenced in this thread, right here in the great-grandparent of your own first attempt at flaming. If it's too difficult for you to click on "User #xxx Info" and find it, surely you could look at the head of the thread to which you're responding. No, guess not. Not even that smart, are you? It may have been hard for you to find, but that doesn't make it an obscure reference.