One is that there's no guarantee that even switching to another provider would actually help the situation.
There are few guarantees in life, bucko. But a quick swing by traceroute.org will suggest that above.net does not yet have an iron grip on connecting to macromedia, much less the whole of the internet.
Saying that the alternative to accepting censorship is to create your own multinational corporation is not a strong argument.
Luckily, I'm not saying that, for two reasons. One, this isn't censorship. Censorship is the suppression of speech based on the content. Above.net says that they won't deliver packets to anybody who the RBL lists as spam-friendly; spamming is a behavior that is content-neutral. And two, in practice there seem to be lots of ISPs that don't use above.net for transit to macromedia. So unless you have some reason to believe that they are likely to get a monopoly shortly, maybe you could cease to whine about problems that exist only in theory?
But your restaraunt analogy points out that there are some aspects of a service that we consider to be essential, not optional, and businesses that fail to provide them should be shut down.
Exactly. Note that McDonald's is obligated to provide food that is sanitary, which is a restriction that applies equally regardless of the type of food. But McDonald's is not obligated to provide you with any kind of food you want, and they are certainly not obliged to provide food that is nutritious or good for you. The government makes no determination about quality, taste, or value. Other than minimum safety standards, the government lets people vote with their wallets.
The bigger point is that getting access to web sites is not an optional service for a web provider.
That's not obviously true, at least not for all web sites everywhere. That may be what *you* want out of a service provider. Heck, that's probably what i want out of a service provider. But non-techies (i.e., 99% of internet users) may not feel that way.
During one of the big email worm scares, a number of providers shut down access to a range of IP addresses that the worm was using to report stolen passwords and possibly to propagate, which included legitimate web sites. Is this a denial of service that Jamie would probably rail against? Sure. Is it a judgement call the ISP gets to make? Sure. Are most of the ISP customers happy having the ISP deal with this? Again, yes.
From the point of view of above.net, this is no different. Spam is network abuse. They don't want to talk to known recalcitrant spammers ever, and have delegated the power to make that determination to MAPS. I would like MAPS to be more transparent about how they determine this stuff, but I think the people at Above.net and the people who buy services from Above.net are adults and are allowed to make their own minds up about how they run their businesses.
If all ISPs choose a solution like RBL, how is it an opt-in for their consumers?
Even if all ISPs used the RBL today you could go out and start your own ISP tomorrow that didn't use it. And given that above.net is, AFAIK, the only major ISP to use it for blocking anything other than mail, you're safe so far. And given how much outrage it seems to cause, it looks like there will always be a market for ISPs that allow non-mail traffic to RBL-listed sites.
I'm afraid your analogies don't really match up. Microsoft doesn't count; it has a monopoly, and above.net doesn't. The encryption of DVD is more a cartel, but the RBL doesn't have one of those, either. And leaded gasoline and smoky flights were both outlawed by the government because they were health hazards. Even in Paul Vixie's wildest dreams I doubt the feds will be mandating RBL usage anytime soon.
This is a frog-in-the-pot argument...
Not really; that would require that the RBL were somehow quietly infectious. Even if you, playing the role of frog, wake up to realize that the sinister anti-spam forces have assimilated some ISP other than above.net, it looks like their are plenty of cooler puddles to hop to.
Except in my locality broadband is a monopoly! I CAN'T choose someone else. Otherwise I'd be more inclined to agree with you.
Assuming that your link is to your broadband connection, I don't buy it. There may be only one company the provides cheap high-speed connections in your area, but I'd bet you can get cheap low-speed connections or pricey high-speed ones.
If you're only willing to pay for low-budget, you shouldn't expect a lot of control over the outcome. At a fancy restaurant, they'll make whatever you want as long as they have the ingredients. At McDonald's, you only can order what's on the menu.
I think like 99% of stories on Slashdot today you're blowing it totally out of proportion.
Amen. I note that Jamie has violated Godwin's Law, and therefore automatically loses the argument. Here's the text from the jargon file:
Godwin's Law prov. [Usenet] "As a Usenet discussion grows longer, the probability of a comparison involving Nazis or Hitler approaches one." There is a tradition in many groups that, once this occurs, that thread is over, and whoever mentioned the Nazis has automatically lost whatever argument was in progress. Godwin's Law thus practically guarantees the existence of an upper bound on thread length in those groups. However there is also a widely- recognized codicil that any intentional triggering of Godwin's Law in order to invoke its thread-ending effects will be unsuccessful.
Why do I get the feeling that if somebody sneezed while Jamie was talking he'd declare it a cynical cryptofascist attempt to interfere with his right to speak without interference and demand an immediate boycott of all sneezers and mandatory administration of Benadryl?
This is basically true. A local restaurant decided that they would call themselves McSushi. Before they even opened, the McLawyers sent them a "cease and desist" letter. They are now called We Be Sushi. True to their name, they serve perfectly adequate sushi at a great price.
so when i paint a new picture in real life, where do i put it? do i put it on the shelf in the den, or do i file it in the basement with my college art? real life models in many places where things need places to exist... what computers may be able to do for us is improve/automate the process. hiding the fact that things go places may not actually help.
This is only moderately true even in the real world, and not at all true for computers.
If you paint one picture, you can put it one place. If you make ten prints of one lithograph, you can put them ten places, and none is intrinsically more important than the other. And what if you're a poet? You think of a poem, so it's filed in one place: your head. Then you teach it to a friend. And then you recite it at a public reading. Where is your poem "filed" now?
Computers are even worse. When I create an image with Photoshop, where is it filed? Well, in truth, it exists only as a bunch of variances in magnetic fields on a number of spots scattered across several metal plates inside one or more metal boxes inside my computer. Unless, of course, I'm using a network, in which case it's inside computers that I may not know the location of and may never see. That's the only "fact" about where it is. Hiding the fact that that things go places is more than helpful; it's vital. If I had to specify the exact physical locations of the components of my Photoshop file, it would be ridiculous.
That's not to say that making things work like they physical world is wrong. The metaphor of a desk, complete with a desktop, filing cabinets, folders, and so on made the Mac useful to a lot of people. But there's no need to stick with a metaphor past the point where it is useful.
The web is a great example of this. Thanks to Google, I rarely bookmark anything; I just search for it. And if I do remember something about the URL, I usually remember only the domain name, finding the actual document I'm after via navigation bars and search forms. Would it be possible to force this into a real-world metaphor, where each "thing" is in exactly one "place"? Sure. Would it be useful? Absolutely not.
Categories and subcategories map well to the real world. If I have only a few files (documents, whatever) they can be in one place. But if I have many, then I?ll want them to be organized somehow, and hierarchically makes a lot of sense for that.
That's nearly true. Categories and subcategories map well to a particular view of the world. But to make effective use of the hierarchy, you are forced to use that view of the world.
Take an example. Say I create an Excel spreadsheet for a 2002 budget projection for a project for one of my clients. What folder and subfolder do I put it in? The top level of the hierarchy could be my role (personal documents vs business documents); it could be the entity the document belongs to (the client's name); it could be the topic of the document (a budget); the period it covers (2002); the type of document (a spreadsheet); the application used to create it (Excel); the date it was created (2001-05-17); or the name of the project. Or something else entirely.
So which is my top-level folder and which are subfolders? It depends on which I consider most "important" or "intuitive", which varies from person to person and from day to day. Heck, if you grew up with Windows you may believe the best place for an Excel document is in the C:\Program Files\Excel directory. I know secretaries who keep all their files right in with the program files because they never learned to make or change directories.
I haven't read Raskin's book yet, but when I dream of better ways to do this, I imagine history lists, search boxes, and hierarchies with multiple roots and automatic filing of documents based on things like name, date, creator, type, and keywords and categories chosen by the author. So when I'm looking for that budget projection, I can browse based on any of those criteria I mentioned above.
but I have the strange feeling I'm only getting 1/2 the story here.
I feel that way with almost anything Jamie posts. His writing is so completely one-sided that my natural inclination is to assume he's wrong. Even though I've thought for years that Scientology was sinister and repugnant, my first guess was that this guy must have been a kook. It wasn't until I read some of Keith Henson's postings that I thought Jamie might actually be right.
Really, I'm happy for people to post opinion pieces, but these jumbled mixes of news story and opinion piece just read like propaganda.
The CD-ROM drives I have on my desktop are all awful for ripping; in particular, they are slow, error-prone, and woefully intolerant of scratches. One is so lousy that it will take 3 hours to rip a 45-minute CD.
Happily, one of them just died, so I'm looking for a replacement. What EIDE CD-ROMs are best for ripping? Or are they all equally good these days?
You mention that Autorip stalls when it can't find the CD info... how would you prefer it worked? Unfortunately, without a display, the only option would be to silently eject the disc so you can go on to the next, and you'd never know that that disc didn't RIP.
Were I doing this kind of bulk ripping, I'd want it to rip the disc and put the files aside in a special directory. Then I would come back at the end of the day and enter the track info in a big batch. That way I could feed it disc after disc without thinking about it until I was ready.
The Holocaust trials held after WWII were extraordinary circumstances. Germany had just lost a war and had no respectable legal infrastructure. This is by no means the norm.
Interesting theory, especially given that they were filing US lawsuits against German companies for Nazi slave labor compensation as recently as 1998. I guess those Germans must still be rebuilding their legal infrastructure, eh?
-
Alas, the rest of your analogies are equally flawed.
The difference between a web page and spam is that I ask for one and am tricked into taking the other.
The difference between porn and spam is that porn is a type of content that can come through any delivery medium; spam, whether the content is bible verses or hot teens, is a method of abusing a delivery medium.
The difference between changing the channel and installing spam filters is the difference between moving to a quieter area of a public park and installing bars on my windows to keep people from climbing in.
And so on, ad nauseam.
With all of the issues involved with the Net, while spam may be one of the most annoying, it is not something that infringes greatly on our lives.
So you're saying it's not a big enough problem yet? How long would you like to wait? Ten years ago, I recevied zero spam. Now about half my unfiltered mail is spam. Ten years ago, the global cost of spam was the occasional lecture from a sysadmin. Now it costs around ten billion dollars a year. And it's still growing, despite the massive effort put into fighting it. So you let me know the dollar figure where you think it becomes a "real" problem, and we'll give you a call back then.
It's my right to write a post that you may find ignorant. This is not murder. This is not theft. This is a minor inconvenience.
You indeed have the legal right to say anything you please, smart or dumb. But if you try to do it outside my house with a megaphone at 3 am despite my requests to stop, the cops will come by to haul you away pronto, no matter how much you point out that it is neither murder nor theft, and despite any waving of the first ammendment. And thus it should be with spam.
Do you honestly think I haven't heard this argument before, or thought of the analogous real-world situation? Obviously I've already considered this.
It may be obvious to you, but it sure isn't obvious from your post.
Perhaps you should have read the first sentence there more carefully. I'll repeat it again: The only concept of "private property" on the Internet is through implementing security measures.
Thanks for your assistance, but I think I read it pretty well the first time. You're making a raw assertion, not obviously based in fact or law.
Your basic theory seems to be the the internet is so entirely different from the real world that traditional notions of property are completely inapplicable. This may have merit with things like the copying of intellectual property. But it's complete bunk in relation to spam.
As far as I can tell, traditional notions of private property map pretty well to servers. E.g., ownership, trespass, theft, vandalism, and dumping are all obvious problems both in the real world and on line. So the theory seems swell. In practice, there are two big problems, both of them temporary.
The first is one of ignorance: the internet is a new thing; people take time to adjust, and the details of the law take even longer to catch up. But catch up they will; western countries have had laws against computer trespass for a while, and other countries are catching up. And western countries are now, a decade after the Green Card incident, now waking up to the need for spam laws.
The second temporary problem is one of immature technology: the basic structure of the internet does very little to make people accountable for their actions. Thanks in part to the aggressiveness of spammers in seeking out and exploiting every bit of trust in the original protocols, accountability is rapidly increasing.
So as far as I can tell, the concept of "private property" on the internet is the same as the old, boring real-world one.
the bandwidth issue is a red herring. If you want to put a dent in bandwidth usage, shut down the porn newsgroups on USENET.
Gosh, if the goal is to reduce bandwidth usage, the simple way is to just turn off all the routers.
Of course, that's not the goal. The goal is for us to stop having to pay for a lot of bandwidth and hassle that does not benefit us. If you don't want alt.binaries.* coming down the pipe to your news server, you can change a configuration file and you're good to go. But if you don't want spam coming to your mail server, that's not the case. Indeed, despite the large amount of effort put into fighting spam, a lot still gets through.
Any spam legislation will only affect U.S. entities physically located in the U.S. sending to U.S. recipients. If any of those prerequisites is missing, any U.S. legislation means precisely dick!
Ah, you would be a lawyer, then?
I'm not either, but my understanding is that this would affect any company with US assets. It's certainly the case that non-US citizens can sue in the US for things that happened outside the US. Note, for example, the suit by Holocaust survivors in US Federal Court against many Germany-based companies.
The only way to stop spam is to stop the source, close all open gateways, close access to all open gateways, or (most effective, but most difficult) get Americans to stop patronizing businesses that spam.
Yes, that's the only way to stop spam. But pending the day that all american consumers make all purchases with wisdom and foresight, perhaps we can pass some legislation that will reduce spam.
The only concept of "private property" on the Internet is through implementing security measures. If you want only those who have your permission to e-mail you, then you can configure your SMTP server or mail client to do that. Problem solved, and I guarantee it'll be much more effective than anything a government can do.
Gosh! This is brilliant. We should extend this to the real world!
Does your neighbor let his dog poop on you lawn? Don't ask him to stop; just build a really high wall around your grass! Somebody peeking in your windows while you undress? Brick 'em up! Is it hard to breath because your neighbor is burning hundreds of tires each day? Well it's your fault for letting outside air into your house. Just configure your house to let only oxygen and nitrogen in. Problem solved, and I guarantee it'll be much more effective than anything a government can do.
We don't do pair programming (I'd like to try it some day)
Try it! It sounds ridiculous and takes a little adjustment, but I really enjoyed it once I got the hang of it. My big tip: start slow. Do it for an hour a day for a while and then ramp up.
The biggest problem is that the codebase you're developing tends to gravitate towards many different goals, and thus design decisions you made early on may be irrelevant now. After every 4 or 5 development phases, the customer has to realize that you have to take 3 months and consolidate all of the code you've already written. Otherwise you proceed towards chaos.
The XP answer to this is that you do the redesign continuously, whenever a piece of ugliness gets in your way. The trick is to do the redesign in little steps, as suggested in Martin Fowler's Refactoring. But you can only do this effectively with some of the other XP practices, particularly good unit tests, tight teams, and good version control.
It's almost enough to make me wonder whether the people pushing XP so hard here have some sort of vested interest.
My vested interest is never having to work death-march hours another project with overly ambitious goals and inadequate resources until the whole thing collapses in a big blame-fest. XP has a lot of practices that I find useful in that regard.
Well, duh. For anyone who learned something from the advice about programmers programming, managers managing and customers choosing, I have this amazing revelation: it gets dark at night. Trouble doesn't come when organizations don't do this (obvious) stuff.
That's pretty much bullshit. I see trouble come all the time when people don't do this allegedly obvious stuff. Customers try to dictate the schedule; programmers ignore customer requests and add features that they think are important; managers do stuff straight out of Dilbert. Every professional programmer I know can tell project horror stories that are directly traceable to these kinds of errors. You want examples or more details, go read McConnell's Rapid Development, which is full of 'em.
The problems are the boundary cases... Clearly program scheduling and product positioning are 'business decisions,' but where are the lines between these and task estimates and customer feature priorities?
In the XP model, the lines are very clear. The customer says "in this cycle I want X, Y, and Z." The developers estimate and say, "you can only have two of those in this cycle." The customer then says, "Oh, I want X and Z then." And feature Y goes back on the pile of features to look at for the next cycle.
This basically works like a kid with an allowance. He goes into the store and picks whatever he wants as long as it adds up to the amount of money in his pocket right now, based on the prices the developers set. Next time he gets his allowance, he gets to buy more stuff.
The customer is happy because he gets what he wants, and the developer is happy because he sold the products at prices he decided were the right ones. Each group is in control of the things that they are most knowledgeable about. And the process allows for a lot of feedback and error correction, so that if there is a bad choice or a bad estimate, the consequences are small.
Who insures that objects with state transitions are able to negotiate transitions forwards and backwards (or that they can't when they shouldn't?)
As another poster pointed out, this is what unit tests are for.
The designer has to be able to do a complete job of writing specifications based not merely on what the existing customer base asks for, but on what the objects involved reveal as posibilities.
Yes and no. This is certainly true if your system is brittle or hard to change. But if your design is flexible and you aren't scared of changing your code, then you can do tomorrow's work tomorrow.
The book that made me see the light on this aspect of it is Martin Fowler's Refactoring. Before I read it, design was always a big scary thing, like laying the foundation for a building. If you didn't get it right the first time, you were basically fucked forever. But Refactoring shows how to make small, incremental changes to continuously improve design.
This doesn't mean that you can turn your brain off; I still find it valuable to think about where I'm going down the road. But I've stopped doing a ton of work based on my design theories and instead put the labor into what's actually needed.
The clients will come back and ask for those very features when they see the system in operation.
XP's answer is that you add those features then. Either that or you say up front "wouldn't you like X instead?" But either way you don't just sneak features in. You trust the customer to decide what they need; the customer trusts you do build the stuff properly.
If you have a cycle time of years between releases, this of course doesn't work; the feedback loop is too slow. But XP should only be used on projects where you can use an iterative process.
Not to sound rebellious against the article, but looking at things from an outside perspective this isn't so called "Extreme Programming" to me, its more like custom programming. Not all customers need the same features in a program so who will be the thinktank customer to help with the foundations of it all?
Excellent question! Beck's book covers this in more detail.
The theory here is that you want the developers to have complete control over the "how" and the customer to have control over the "what". And that "when" emerges from this process. The goal is to avoid the nightmare where a manager says "build X features in Y time for Z dollars" by pulling the numbers out of his ass.
In the case where you are making a product for a large, diverse body of customers, you get a proxy for them. Typically, this is is somebody from marketing. This person then is the one to say "of these 323 features that we think would be cool, these five are the most important ones." The developers then give estimates on how long those features will take, and the developers and the proxy customer go back and forth until they all agree on the things to tackle next.
In this case, though, I strongly recommend doing frequent user tests with real users. As Jakob Nielsen is happy to tell you, the difference between what we think people want and what they actually want is often miles apart.
But to a large extent, the developers will have to trust that the marketing person knows what he is doing, in the same way that the marketing person has to trust that the developers know what they're doing. Normally this is pretty scary for both sides, but the short release cycles and continuous feedback make it work out pretty well in practice.
So, they're saying, "Figure out what's good and do it," huh? Well, it's good advice, but isn't it pretty much what we're supposed to in the first
place?
I've never had someone come up to me and say "Write good code!"
Sure, this is what people are supposed to do. In theory, businesses run sanely, politicians govern wisely, bueaucrats manage efficiently, and citizens behave responsibly. As you may have noticed, reality is somewhat different than theory.
According to McConnell's Rapid Development, "about two-thirds of all projects substantially overrun their estimates." And despite all this extra time and money, we all know there is a lot of crappy software out there. This suggests that the implict "write good code" is not sufficient. Realize "best you can do" is only the best you currently know how to do, and that there might possibly be ways to make the "best you can do" even better.
Extreme Programming is an interesting look at some of the reasons why things often go wrong in the software development process. And it presents some interesting solutions. It's not the holy grail and I don't buy all of it, but I have tried a number of the XP practices, and they are surprisingly effective.
If you want to be a serious professional programmer working in a team environment, Extreme Programming is absolutely worth reading, even if you never adopt any of it. For those who always work alone, it's only moderately interesting, especially if you already write lots of unit tests and are comfortable using a short-cycle iterative development model.
That's what cookies are for. If you know the problems with IP numbers, why try to use them for something that's clearly inappropriate and fraught with error?
There are circumstances where this is impossible. Like, say, for last year's logs.
I'll grant that this method is fraught with error and that using IP addresses to count noses is the work of the devil. Setting that aside, could a few folks who are running unique cookies on a large site count 'em and count IP addresses in the same period and give us their ratio?
My rough rule of thumb is that the ratio is around 1:1 but it has been several years since I verified this.
One interesting compromise is to use O/R mapping layers; you put all your data in a traditional SQL database and describe a mapping to objects.
A couple of interesting open-source ones are Castor and Osage. I haven't had the chance to use either one in a serious project yet, but as a NeXT refugee I'm looking forward to using a good O/R mapping layer again. Do people have any recommendations?
2600 magazine has a long history ("Fun at Costco") of giving people instructions on how to knowingly break the law, and it's pointless to pretend otherwise.
Bollocks. In my daily work as administering my work network, I'm having to review security on various elements of our network.
As the fellow says, it's pointless to pretend otherwise.
This is not to dis 2600; I still have all my back issues. But pretending that the primary use of this magazine is to help secure systems is just talking stupid. It may be useful for that, but that's nothing new; e.g., "to catch a thief, set a thief".
The thing I loved (and really, still love) about 2600 is its cheerful immorality. Or rather, its different sort of morality, wherein clever exploration is the highest value, and things like property rights are strictly secondary. This doesn't mean that is a magazine for criminals in the ordinary sense; were someone to describe how to break into a bank's systems, the exciting part wouldn't be the opportunity to steal, it would be the clever hacking required to get in. I think of it a journal for geeky pranksters, not a magazine for the mob.
Alas, I no longer share 2600's philosophy entirely, but I do appreciate it. But the value of it would be pretty hard to convey to an authority figure; 2600's anti-authoritarian tone is not exactly calculated to warm the alleged heart of an appeals-court judge.
sev 1: crashing bug, or data corruption
sev 2: feature broken, no workaround
sev 3: feature incomplete, or broken w/ workaround.
sev 4: cosmetic or UI flaw
This strikes me as pretty reasonable except for the "or UI" part. A bad or buggy UI can lead to user behaviors that destroy just as much data as a fandango on core does.
One of my favorite examples of this comes from the NeXT 1.0 OS release, which was a slick GUI on top of a BSD-derived Unix. As appropriate in a GUI OS, you could click on a floppy (mounted in the filesystem, of course) and choose "format" from a menu to erase the disk (after a little "are you sure you want to erase this disk" messsage.
But you would get the identical warning if you tried to format any other partition in the file system, even your root partition. And it was awfully easy to mistakenly select the directory that the floppy was mounted in rather than the floppy itself. In one sense, this is "just" a UI flaw. But it's certainly not a just cosmetic one; it should be classified as severity 1.
Slashdot Mirror
One is that there's no guarantee that even switching to another provider would actually help the situation.
There are few guarantees in life, bucko. But a quick swing by traceroute.org will suggest that above.net does not yet have an iron grip on connecting to macromedia, much less the whole of the internet.
Saying that the alternative to accepting censorship is to create your own multinational corporation is not a strong argument.
Luckily, I'm not saying that, for two reasons. One, this isn't censorship. Censorship is the suppression of speech based on the content. Above.net says that they won't deliver packets to anybody who the RBL lists as spam-friendly; spamming is a behavior that is content-neutral. And two, in practice there seem to be lots of ISPs that don't use above.net for transit to macromedia. So unless you have some reason to believe that they are likely to get a monopoly shortly, maybe you could cease to whine about problems that exist only in theory?
But your restaraunt analogy points out that there are some aspects of a service that we consider to be essential, not optional, and businesses that fail to provide them should be shut down.
Exactly. Note that McDonald's is obligated to provide food that is sanitary, which is a restriction that applies equally regardless of the type of food. But McDonald's is not obligated to provide you with any kind of food you want, and they are certainly not obliged to provide food that is nutritious or good for you. The government makes no determination about quality, taste, or value. Other than minimum safety standards, the government lets people vote with their wallets.
The bigger point is that getting access to web sites is not an optional service for a web provider.
That's not obviously true, at least not for all web sites everywhere. That may be what *you* want out of a service provider. Heck, that's probably what i want out of a service provider. But non-techies (i.e., 99% of internet users) may not feel that way.
During one of the big email worm scares, a number of providers shut down access to a range of IP addresses that the worm was using to report stolen passwords and possibly to propagate, which included legitimate web sites. Is this a denial of service that Jamie would probably rail against? Sure. Is it a judgement call the ISP gets to make? Sure. Are most of the ISP customers happy having the ISP deal with this? Again, yes.
From the point of view of above.net, this is no different. Spam is network abuse. They don't want to talk to known recalcitrant spammers ever, and have delegated the power to make that determination to MAPS. I would like MAPS to be more transparent about how they determine this stuff, but I think the people at Above.net and the people who buy services from Above.net are adults and are allowed to make their own minds up about how they run their businesses.
If all ISPs choose a solution like RBL, how is it an opt-in for their consumers?
Even if all ISPs used the RBL today you could go out and start your own ISP tomorrow that didn't use it. And given that above.net is, AFAIK, the only major ISP to use it for blocking anything other than mail, you're safe so far. And given how much outrage it seems to cause, it looks like there will always be a market for ISPs that allow non-mail traffic to RBL-listed sites.
I'm afraid your analogies don't really match up. Microsoft doesn't count; it has a monopoly, and above.net doesn't. The encryption of DVD is more a cartel, but the RBL doesn't have one of those, either. And leaded gasoline and smoky flights were both outlawed by the government because they were health hazards. Even in Paul Vixie's wildest dreams I doubt the feds will be mandating RBL usage anytime soon.
This is a frog-in-the-pot argument...
Not really; that would require that the RBL were somehow quietly infectious. Even if you, playing the role of frog, wake up to realize that the sinister anti-spam forces have assimilated some ISP other than above.net, it looks like their are plenty of cooler puddles to hop to.
Except in my locality broadband is a monopoly! I CAN'T choose someone else. Otherwise I'd be more inclined to agree with you.
Assuming that your link is to your broadband connection, I don't buy it. There may be only one company the provides cheap high-speed connections in your area, but I'd bet you can get cheap low-speed connections or pricey high-speed ones.
If you're only willing to pay for low-budget, you shouldn't expect a lot of control over the outcome. At a fancy restaurant, they'll make whatever you want as long as they have the ingredients. At McDonald's, you only can order what's on the menu.
Amen. I note that Jamie has violated Godwin's Law, and therefore automatically loses the argument. Here's the text from the jargon file: Why do I get the feeling that if somebody sneezed while Jamie was talking he'd declare it a cynical cryptofascist attempt to interfere with his right to speak without interference and demand an immediate boycott of all sneezers and mandatory administration of Benadryl?
Mc*® is a registered trademark of McDonalds®.
This is basically true. A local restaurant decided that they would call themselves McSushi. Before they even opened, the McLawyers sent them a "cease and desist" letter. They are now called We Be Sushi. True to their name, they serve perfectly adequate sushi at a great price.
so when i paint a new picture in real life, where do i put it? do i put it on the shelf in the den, or do i file it in the basement with my college art? real life models in many places where things need places to exist ... what computers may be able to do for us is improve/automate the process. hiding the fact that things go places may not actually help.
This is only moderately true even in the real world, and not at all true for computers.
If you paint one picture, you can put it one place. If you make ten prints of one lithograph, you can put them ten places, and none is intrinsically more important than the other. And what if you're a poet? You think of a poem, so it's filed in one place: your head. Then you teach it to a friend. And then you recite it at a public reading. Where is your poem "filed" now?
Computers are even worse. When I create an image with Photoshop, where is it filed? Well, in truth, it exists only as a bunch of variances in magnetic fields on a number of spots scattered across several metal plates inside one or more metal boxes inside my computer. Unless, of course, I'm using a network, in which case it's inside computers that I may not know the location of and may never see. That's the only "fact" about where it is. Hiding the fact that that things go places is more than helpful; it's vital. If I had to specify the exact physical locations of the components of my Photoshop file, it would be ridiculous.
That's not to say that making things work like they physical world is wrong. The metaphor of a desk, complete with a desktop, filing cabinets, folders, and so on made the Mac useful to a lot of people. But there's no need to stick with a metaphor past the point where it is useful.
The web is a great example of this. Thanks to Google, I rarely bookmark anything; I just search for it. And if I do remember something about the URL, I usually remember only the domain name, finding the actual document I'm after via navigation bars and search forms. Would it be possible to force this into a real-world metaphor, where each "thing" is in exactly one "place"? Sure. Would it be useful? Absolutely not.
Categories and subcategories map well to the real world. If I have only a few files (documents, whatever) they can be in one place. But if I have many, then I?ll want them to be organized somehow, and hierarchically makes a lot of sense for that.
That's nearly true. Categories and subcategories map well to a particular view of the world. But to make effective use of the hierarchy, you are forced to use that view of the world.
Take an example. Say I create an Excel spreadsheet for a 2002 budget projection for a project for one of my clients. What folder and subfolder do I put it in? The top level of the hierarchy could be my role (personal documents vs business documents); it could be the entity the document belongs to (the client's name); it could be the topic of the document (a budget); the period it covers (2002); the type of document (a spreadsheet); the application used to create it (Excel); the date it was created (2001-05-17); or the name of the project. Or something else entirely.
So which is my top-level folder and which are subfolders? It depends on which I consider most "important" or "intuitive", which varies from person to person and from day to day. Heck, if you grew up with Windows you may believe the best place for an Excel document is in the C:\Program Files\Excel directory. I know secretaries who keep all their files right in with the program files because they never learned to make or change directories.
I haven't read Raskin's book yet, but when I dream of better ways to do this, I imagine history lists, search boxes, and hierarchies with multiple roots and automatic filing of documents based on things like name, date, creator, type, and keywords and categories chosen by the author. So when I'm looking for that budget projection, I can browse based on any of those criteria I mentioned above.
but I have the strange feeling I'm only getting 1/2 the story here.
I feel that way with almost anything Jamie posts. His writing is so completely one-sided that my natural inclination is to assume he's wrong. Even though I've thought for years that Scientology was sinister and repugnant, my first guess was that this guy must have been a kook. It wasn't until I read some of Keith Henson's postings that I thought Jamie might actually be right.
Really, I'm happy for people to post opinion pieces, but these jumbled mixes of news story and opinion piece just read like propaganda.
The CD-ROM drives I have on my desktop are all awful for ripping; in particular, they are slow, error-prone, and woefully intolerant of scratches. One is so lousy that it will take 3 hours to rip a 45-minute CD.
Happily, one of them just died, so I'm looking for a replacement. What EIDE CD-ROMs are best for ripping? Or are they all equally good these days?
You mention that Autorip stalls when it can't find the CD info... how would you prefer it worked? Unfortunately, without a display, the only option would be to silently eject the disc so you can go on to the next, and you'd never know that that disc didn't RIP.
Were I doing this kind of bulk ripping, I'd want it to rip the disc and put the files aside in a special directory. Then I would come back at the end of the day and enter the track info in a big batch. That way I could feed it disc after disc without thinking about it until I was ready.
Interesting theory, especially given that they were filing US lawsuits against German companies for Nazi slave labor compensation as recently as 1998. I guess those Germans must still be rebuilding their legal infrastructure, eh?
-
Alas, the rest of your analogies are equally flawed.
- The difference between a web page and spam is that I ask for one and am tricked into taking the other.
- The difference between porn and spam is that porn is a type of content that can come through any delivery medium; spam, whether the content is bible verses or hot teens, is a method of abusing a delivery medium.
- The difference between changing the channel and installing spam filters is the difference between moving to a quieter area of a public park and installing bars on my windows to keep people from climbing in.
- And so on, ad nauseam.
With all of the issues involved with the Net, while spam may be one of the most annoying, it is not something that infringes greatly on our lives.So you're saying it's not a big enough problem yet? How long would you like to wait? Ten years ago, I recevied zero spam. Now about half my unfiltered mail is spam. Ten years ago, the global cost of spam was the occasional lecture from a sysadmin. Now it costs around ten billion dollars a year. And it's still growing, despite the massive effort put into fighting it. So you let me know the dollar figure where you think it becomes a "real" problem, and we'll give you a call back then.
It's my right to write a post that you may find ignorant. This is not murder. This is not theft. This is a minor inconvenience.
You indeed have the legal right to say anything you please, smart or dumb. But if you try to do it outside my house with a megaphone at 3 am despite my requests to stop, the cops will come by to haul you away pronto, no matter how much you point out that it is neither murder nor theft, and despite any waving of the first ammendment. And thus it should be with spam.
Do you honestly think I haven't heard this argument before, or thought of the analogous real-world situation? Obviously I've already considered this.
It may be obvious to you, but it sure isn't obvious from your post.
Perhaps you should have read the first sentence there more carefully. I'll repeat it again: The only concept of "private property" on the Internet is through implementing security measures.
Thanks for your assistance, but I think I read it pretty well the first time. You're making a raw assertion, not obviously based in fact or law.
Your basic theory seems to be the the internet is so entirely different from the real world that traditional notions of property are completely inapplicable. This may have merit with things like the copying of intellectual property. But it's complete bunk in relation to spam.
As far as I can tell, traditional notions of private property map pretty well to servers. E.g., ownership, trespass, theft, vandalism, and dumping are all obvious problems both in the real world and on line. So the theory seems swell. In practice, there are two big problems, both of them temporary.
The first is one of ignorance: the internet is a new thing; people take time to adjust, and the details of the law take even longer to catch up. But catch up they will; western countries have had laws against computer trespass for a while, and other countries are catching up. And western countries are now, a decade after the Green Card incident, now waking up to the need for spam laws.
The second temporary problem is one of immature technology: the basic structure of the internet does very little to make people accountable for their actions. Thanks in part to the aggressiveness of spammers in seeking out and exploiting every bit of trust in the original protocols, accountability is rapidly increasing.
So as far as I can tell, the concept of "private property" on the internet is the same as the old, boring real-world one.
the bandwidth issue is a red herring. If you want to put a dent in bandwidth usage, shut down the porn newsgroups on USENET.
Gosh, if the goal is to reduce bandwidth usage, the simple way is to just turn off all the routers.
Of course, that's not the goal. The goal is for us to stop having to pay for a lot of bandwidth and hassle that does not benefit us. If you don't want alt.binaries.* coming down the pipe to your news server, you can change a configuration file and you're good to go. But if you don't want spam coming to your mail server, that's not the case. Indeed, despite the large amount of effort put into fighting spam, a lot still gets through.
Any spam legislation will only affect U.S. entities physically located in the U.S. sending to U.S. recipients. If any of those prerequisites is missing, any U.S. legislation means precisely dick!
Ah, you would be a lawyer, then?
I'm not either, but my understanding is that this would affect any company with US assets. It's certainly the case that non-US citizens can sue in the US for things that happened outside the US. Note, for example, the suit by Holocaust survivors in US Federal Court against many Germany-based companies.
The only way to stop spam is to stop the source, close all open gateways, close access to all open gateways, or (most effective, but most difficult) get Americans to stop patronizing businesses that spam.
Yes, that's the only way to stop spam. But pending the day that all american consumers make all purchases with wisdom and foresight, perhaps we can pass some legislation that will reduce spam.
The only concept of "private property" on the Internet is through implementing security measures. If you want only those who have your permission to e-mail you, then you can configure your SMTP server or mail client to do that. Problem solved, and I guarantee it'll be much more effective than anything a government can do.
Gosh! This is brilliant. We should extend this to the real world!
Does your neighbor let his dog poop on you lawn? Don't ask him to stop; just build a really high wall around your grass! Somebody peeking in your windows while you undress? Brick 'em up! Is it hard to breath because your neighbor is burning hundreds of tires each day? Well it's your fault for letting outside air into your house. Just configure your house to let only oxygen and nitrogen in. Problem solved, and I guarantee it'll be much more effective than anything a government can do.
We don't do pair programming (I'd like to try it some day)
Try it! It sounds ridiculous and takes a little adjustment, but I really enjoyed it once I got the hang of it. My big tip: start slow. Do it for an hour a day for a while and then ramp up.
The biggest problem is that the codebase you're developing tends to gravitate towards many different goals, and thus design decisions you made early on may be irrelevant now. After every 4 or 5 development phases, the customer has to realize that you have to take 3 months and consolidate all of the code you've already written. Otherwise you proceed towards chaos.
The XP answer to this is that you do the redesign continuously, whenever a piece of ugliness gets in your way. The trick is to do the redesign in little steps, as suggested in Martin Fowler's Refactoring. But you can only do this effectively with some of the other XP practices, particularly good unit tests, tight teams, and good version control.
It's almost enough to make me wonder whether the people pushing XP so hard here have some sort of vested interest.
My vested interest is never having to work death-march hours another project with overly ambitious goals and inadequate resources until the whole thing collapses in a big blame-fest. XP has a lot of practices that I find useful in that regard.
Well, duh. For anyone who learned something from the advice about programmers programming, managers managing and customers choosing, I have this amazing revelation: it gets dark at night. Trouble doesn't come when organizations don't do this (obvious) stuff.
That's pretty much bullshit. I see trouble come all the time when people don't do this allegedly obvious stuff. Customers try to dictate the schedule; programmers ignore customer requests and add features that they think are important; managers do stuff straight out of Dilbert. Every professional programmer I know can tell project horror stories that are directly traceable to these kinds of errors. You want examples or more details, go read McConnell's Rapid Development, which is full of 'em.
The problems are the boundary cases... Clearly program scheduling and product positioning are 'business decisions,' but where are the lines between these and task estimates and customer feature priorities?
In the XP model, the lines are very clear. The customer says "in this cycle I want X, Y, and Z." The developers estimate and say, "you can only have two of those in this cycle." The customer then says, "Oh, I want X and Z then." And feature Y goes back on the pile of features to look at for the next cycle.
This basically works like a kid with an allowance. He goes into the store and picks whatever he wants as long as it adds up to the amount of money in his pocket right now, based on the prices the developers set. Next time he gets his allowance, he gets to buy more stuff.
The customer is happy because he gets what he wants, and the developer is happy because he sold the products at prices he decided were the right ones. Each group is in control of the things that they are most knowledgeable about. And the process allows for a lot of feedback and error correction, so that if there is a bad choice or a bad estimate, the consequences are small.
Who insures that objects with state transitions are able to negotiate transitions forwards and backwards (or that they can't when they shouldn't?)
As another poster pointed out, this is what unit tests are for.
The designer has to be able to do a complete job of writing specifications based not merely on what the existing customer base asks for, but on what the objects involved reveal as posibilities.
Yes and no. This is certainly true if your system is brittle or hard to change. But if your design is flexible and you aren't scared of changing your code, then you can do tomorrow's work tomorrow.
The book that made me see the light on this aspect of it is Martin Fowler's Refactoring. Before I read it, design was always a big scary thing, like laying the foundation for a building. If you didn't get it right the first time, you were basically fucked forever. But Refactoring shows how to make small, incremental changes to continuously improve design.
This doesn't mean that you can turn your brain off; I still find it valuable to think about where I'm going down the road. But I've stopped doing a ton of work based on my design theories and instead put the labor into what's actually needed.
The clients will come back and ask for those very features when they see the system in operation.
XP's answer is that you add those features then. Either that or you say up front "wouldn't you like X instead?" But either way you don't just sneak features in. You trust the customer to decide what they need; the customer trusts you do build the stuff properly.
If you have a cycle time of years between releases, this of course doesn't work; the feedback loop is too slow. But XP should only be used on projects where you can use an iterative process.
Not to sound rebellious against the article, but looking at things from an outside perspective this isn't so called "Extreme Programming" to me, its more like custom programming. Not all customers need the same features in a program so who will be the thinktank customer to help with the foundations of it all?
Excellent question! Beck's book covers this in more detail.
The theory here is that you want the developers to have complete control over the "how" and the customer to have control over the "what". And that "when" emerges from this process. The goal is to avoid the nightmare where a manager says "build X features in Y time for Z dollars" by pulling the numbers out of his ass.
In the case where you are making a product for a large, diverse body of customers, you get a proxy for them. Typically, this is is somebody from marketing. This person then is the one to say "of these 323 features that we think would be cool, these five are the most important ones." The developers then give estimates on how long those features will take, and the developers and the proxy customer go back and forth until they all agree on the things to tackle next.
In this case, though, I strongly recommend doing frequent user tests with real users. As Jakob Nielsen is happy to tell you, the difference between what we think people want and what they actually want is often miles apart.
But to a large extent, the developers will have to trust that the marketing person knows what he is doing, in the same way that the marketing person has to trust that the developers know what they're doing. Normally this is pretty scary for both sides, but the short release cycles and continuous feedback make it work out pretty well in practice.
So, they're saying, "Figure out what's good and do it," huh? Well, it's good advice, but isn't it pretty much what we're supposed to in the first
place?
I've never had someone come up to me and say "Write good code!"
Sure, this is what people are supposed to do. In theory, businesses run sanely, politicians govern wisely, bueaucrats manage efficiently, and citizens behave responsibly. As you may have noticed, reality is somewhat different than theory.
According to McConnell's Rapid Development, "about two-thirds of all projects substantially overrun their estimates." And despite all this extra time and money, we all know there is a lot of crappy software out there. This suggests that the implict "write good code" is not sufficient. Realize "best you can do" is only the best you currently know how to do, and that there might possibly be ways to make the "best you can do" even better.
Extreme Programming is an interesting look at some of the reasons why things often go wrong in the software development process. And it presents some interesting solutions. It's not the holy grail and I don't buy all of it, but I have tried a number of the XP practices, and they are surprisingly effective.
If you want to be a serious professional programmer working in a team environment, Extreme Programming is absolutely worth reading, even if you never adopt any of it. For those who always work alone, it's only moderately interesting, especially if you already write lots of unit tests and are comfortable using a short-cycle iterative development model.
That's what cookies are for. If you know the problems with IP numbers, why try to use them for something that's clearly inappropriate and fraught with error?
There are circumstances where this is impossible. Like, say, for last year's logs.
I'll grant that this method is fraught with error and that using IP addresses to count noses is the work of the devil. Setting that aside, could a few folks who are running unique cookies on a large site count 'em and count IP addresses in the same period and give us their ratio?
My rough rule of thumb is that the ratio is around 1:1 but it has been several years since I verified this.
One interesting compromise is to use O/R mapping layers; you put all your data in a traditional SQL database and describe a mapping to objects.
A couple of interesting open-source ones are Castor and Osage. I haven't had the chance to use either one in a serious project yet, but as a NeXT refugee I'm looking forward to using a good O/R mapping layer again. Do people have any recommendations?
For those interested in the topic, there is useful information at Scott Ambler's site, including his white paper The Design of a Robust Persistence Layer for Relational Databases.
This is not to dis 2600; I still have all my back issues. But pretending that the primary use of this magazine is to help secure systems is just talking stupid. It may be useful for that, but that's nothing new; e.g., "to catch a thief, set a thief".
The thing I loved (and really, still love) about 2600 is its cheerful immorality. Or rather, its different sort of morality, wherein clever exploration is the highest value, and things like property rights are strictly secondary. This doesn't mean that is a magazine for criminals in the ordinary sense; were someone to describe how to break into a bank's systems, the exciting part wouldn't be the opportunity to steal, it would be the clever hacking required to get in. I think of it a journal for geeky pranksters, not a magazine for the mob.
Alas, I no longer share 2600's philosophy entirely, but I do appreciate it. But the value of it would be pretty hard to convey to an authority figure; 2600's anti-authoritarian tone is not exactly calculated to warm the alleged heart of an appeals-court judge.
long durations of time, usually when I have to go to the bathroom.
That should clear up if you get more fiber in your diet.
sev 1: crashing bug, or data corruption
sev 2: feature broken, no workaround
sev 3: feature incomplete, or broken w/ workaround.
sev 4: cosmetic or UI flaw
This strikes me as pretty reasonable except for the "or UI" part. A bad or buggy UI can lead to user behaviors that destroy just as much data as a fandango on core does.
One of my favorite examples of this comes from the NeXT 1.0 OS release, which was a slick GUI on top of a BSD-derived Unix. As appropriate in a GUI OS, you could click on a floppy (mounted in the filesystem, of course) and choose "format" from a menu to erase the disk (after a little "are you sure you want to erase this disk" messsage.
But you would get the identical warning if you tried to format any other partition in the file system, even your root partition. And it was awfully easy to mistakenly select the directory that the floppy was mounted in rather than the floppy itself. In one sense, this is "just" a UI flaw. But it's certainly not a just cosmetic one; it should be classified as severity 1.