Damn right! I'd much rather buy my clothes from the government, who has experts working on the problem day and night, than some handmade outfit by a glamorous designer!
If you link to high-quality sites then you are adding more value to the high-quality sites than to your own. Sure there are ways to hack the system. You can pay people to link to your site for instance. If that is not an option, then it has always been possible to
hack SciAm into publishing a hoax that you concocted.
Yer even dumber than your handle suggests. Linking to someone doesn't add as much value as being linked by someone. Linking to someone is not as expensive as being linked by someone. In this way you can establish the "cost" or "value" of each page as you crawl the a tree and have it hardly matter where you start.
"There has grown in the minds of certain groups in this country the notion that because a man or corporation has made a profit out of the public for a number of years, the government and the courts are charged with the duty of guaranteeing^W taking away from him such profit in the future, even in the face of changing circumstances and contrary to public interest. This strange doctrine is not supported by statute or common law. Neither individuals nor corporations have any right to come into court and ask that the clock of history be stopped, or turned back."
The only sensible model is to charge people for posting. They're the ones who reload pages most and the only people who care enough anyway.
The last thing you should do is make people pay for not seeing the ads. If anything you should be denying ads and promotional offers to non-subscribers. This way you could even offer content that actually costs something. For a change. You know. Do your own research and stuff.
No, actually Raskin does prove a few things in his book. Not groundbreaking stuff, but very interesting analyses nevertheless, ranging from what kind of input method is fastest given what type of input, and how you measure "fastness" in the first place, that kind of stuff.
Well, okay, you're with the Church of OOP and DESIGN METHODOLOGY. That is wonderful. I suppose that by obscuring the workings of your program (by encapsulating stuff inside, say, an object), it becomes possible to maintain code without having to understand what it does. That's good. The problem is that it leads to people maintaining code without understanding what it does. And that's bad. What any of this has to do with engineering I'm not sure.
A few years ago the IPv4 address shortage seemed more urgent than it is now for a couple of reasons. One of them is obviously the web monoculture -- Internet access has become virtually synonymous with web browsing. This allows a lot of corners to be cut.
Another thought that occurred to me is that the predicted explosion of TCP/IP-enabled devices never really took off. It's interesting to see how many devices instead use USB, or serial, or some other means still to connect to eachother, instead of TCP/IP over Ethernet. This is something that I think was overlooked in earlier predictions.
Those 20 million people really were one virus writer's victims. Sheer volume does not somehow move the writer's responsibility to microsoft.
I wasn't trying to blame Microsoft. Sorry if I gave that impression. I was actually trying to move blame away from Microsoft and shift a bit of it towards each of the 20 million people who opened the trojans. Of all the analogies I think the best one is that the Net is like a huge river full of junk floating past your door. I feel that you have a responsibility to keep the shit from piling up I guess, and I really don't like the way Symantec and McAfee are profiling themselves as the guardians of the Internet (I exaggerate. The virus writers themselves are obviously the main problem in this whole picture).
Investors would be wary of investing in companies that didn't have rigorous design, testing, and production methods. Etc. etc. etc.
In other words, you want software to confirm to a wide range of standards. A checklist so to speak. The example I gave you shows you how these ideas turn out in reality. The government requires POSIX? Microsoft writes you the most miserable POSIX implementation around. Problem solved!
Heh. No, it is more like me not excercising proper hygiene, thereby through gross negligence and a moist puddle on a McDonalds toilet seat exposing you and your brethren to a most lethal strain of smallpox.
You talk as if all these problems have been solved. But they haven't. You cannot just say "software engineering methodology" and "design for change" and get something that works. Because the goal is not so much to "design for change" or to "make it very easy to change and replace objects": the goal is to deliver correct, efficient code within budget and on time. A software engineering methodology is only "worth it's (sic) salt" in so far as it helps you achieve that goal. And as much as I hate to be the one to have to bring it to you, "making it very easy to change and replace objects" might be a lot of fun, and it sure sounds expensive, but it is not by itself conducive towards the goal.
OOP might make it twice as easy to maintain your code (whatever that means), but that is not necessarily a benefit if it means your code has to anticipate four times as many calling contexts, and you have to consider sixteen times as many code paths -- both (although a bit exaggerated perhaps) natural results of the code reuse that you get with OOP. That's not to say that OOP does not have its use: of course it does. But you are making a trade-off, and although current fashions dictate that the trade-off is always worth it: this is just not so. It may be, or it may not be. Sometimes designing for change is necessary, but sometimes not. Sometimes OOP is nice, but sometimes not. It comes down to the fact that you don't design "for change", but for the customer. Granted, there are aesthetics involved. OOP captures some of these very nicely. But when you focus on the problem, and not the "methodology", you find that these and other aesthetics exist in every other language and every other methodology as well: from C to Scheme, from bash to VBScript, from the quick hack to the deep thought.
There is a lot of merit in a more managerial (because that is what most of the "software methodologies are: they have very little to do with engineering) approach to software development. Management requires measurement, and without procedure it becomes impossible to measure. So, software developers need to follow procedures, adopt a certain style of programming and adhere to standards. Otherwise it becomes impossible to measure progress. But you have to be careful not to confuse the measurements with the actual goal: just because the project follows a "design methodology" doesn't mean that the customer has to like the end result.
You are missing the point. Algorithms that work for ASCII will not work (and at the very least, are not certified to work) with Unicode. Programs that depend on IPv4 may not work (and at the very least, are not certified to work) with IPv6. And the notion that "most programs are around for such short periods anyway" is what brought us Y2K.
You're simply mistaken. Government agencies have long, long lists of requirements that need to be satisfied before they will purchase a particular piece of software. POSIX adherence comes to mind.
The problem is: these lists don't help. Vendors just put in the minimal effort required to satisfy the government's checklists, and you end up with an implementation that is for all purposes useless, except to pass the checklists and close the contract. This is what Microsoft did when they needed Windows NT to support POSIX. That the customer ends up with a severely braindamaged (but still compliant) product does not seem to matter.
The problem is not that people don't design. The problem is that software depends on other software.
When you build a bridge you can be certain that the laws of gravity won't change. When you build software you cannot be sure that in ten years time you'll be using ASCII, or TCP/IP.
It doesn't matter how much time you spend designing upfront. Obviously it is better to have a good design than a bad design or no design at all, but the design which is impervious to change simply does not exist. If your code is being used you will always need to go back and change your it. In the process errors creep in, no matter what. It does not help to make the errors very expensive. That just makes the software very expensive, very late, and very restricted. With possibly less errors. Because that is the problem: how will you know? We don't know now -- how does increasing the price help?
In any case, considering the scale and duration of the US military operation in Afghanistan, how can you maintain that the US is respecting Afghan sovereignty within Afghan borders? A nation that cannot maintain sovereignty within its borders is not a nation. Ergo, the US destroyed the Afghan nation.
This argument has been made in the past but it died. Now ESR is regurgitating this -- why?
The PC pricewars came and went years ago. It was the age of the sub-$1000 PC, E-machines, Ellison's network computer, and all that. None of it happened of course. The market has stabilized since then. Computers are not getting that much cheaper anymore. You get a lot more value for your money each year: but in dollar figures the prices aren't dropping that fast anymore, if at all.
On the one hand you have the US holding an entire nation responsible for the crimes committed on 9/11. However, when millions upon millions of people open suspect attachments, then suddenly everybody agrees that the only person to blame is the virus writer. Without wanting to equate the two events, I don't see how you could argue that these positions do not in some way contradict each other.
Agreed. But the purpose of establishing guilt is to establish penalty. People who live in rough neighborhoods may not be guilty as such, but they are being subjected to harsher penalties than other people (i.e. increased cost of insurance). FWIW.
Slashdot Mirror
Damn right! I'd much rather buy my clothes from the government, who has experts working on the problem day and night, than some handmade outfit by a glamorous designer!
So the system is hackable. So what.
Yer even dumber than your handle suggests. Linking to someone doesn't add as much value as being linked by someone. Linking to someone is not as expensive as being linked by someone. In this way you can establish the "cost" or "value" of each page as you crawl the a tree and have it hardly matter where you start.
"There has grown in the minds of certain groups in this country the notion that because a man or corporation has made a profit out of the public for a number of years, the government and the courts are charged with the duty of guaranteeing^W taking away from him such profit in the future, even in the face of changing circumstances and contrary to public interest. This strange doctrine is not supported by statute or common law. Neither individuals nor corporations have any right to come into court and ask that the clock of history be stopped, or turned back."
The last thing you should do is make people pay for not seeing the ads. If anything you should be denying ads and promotional offers to non-subscribers. This way you could even offer content that actually costs something. For a change. You know. Do your own research and stuff.
Of course. /. has always been that way. In the past you had to pay homage to the Taco party line. In the future you just pay.
The point is that when you know the encrypted data resembles a bank account, this makes cracking much easier.
Have them watch TV!
No, actually Raskin does prove a few things in his book. Not groundbreaking stuff, but very interesting analyses nevertheless, ranging from what kind of input method is fastest given what type of input, and how you measure "fastness" in the first place, that kind of stuff.
Well, okay, you're with the Church of OOP and DESIGN METHODOLOGY. That is wonderful. I suppose that by obscuring the workings of your program (by encapsulating stuff inside, say, an object), it becomes possible to maintain code without having to understand what it does. That's good. The problem is that it leads to people maintaining code without understanding what it does. And that's bad. What any of this has to do with engineering I'm not sure.
Another thought that occurred to me is that the predicted explosion of TCP/IP-enabled devices never really took off. It's interesting to see how many devices instead use USB, or serial, or some other means still to connect to eachother, instead of TCP/IP over Ethernet. This is something that I think was overlooked in earlier predictions.
No, not really. Problem not solved. See my point?
Heh. No, it is more like me not excercising proper hygiene, thereby through gross negligence and a moist puddle on a McDonalds toilet seat exposing you and your brethren to a most lethal strain of smallpox.
OOP might make it twice as easy to maintain your code (whatever that means), but that is not necessarily a benefit if it means your code has to anticipate four times as many calling contexts, and you have to consider sixteen times as many code paths -- both (although a bit exaggerated perhaps) natural results of the code reuse that you get with OOP. That's not to say that OOP does not have its use: of course it does. But you are making a trade-off, and although current fashions dictate that the trade-off is always worth it: this is just not so. It may be, or it may not be. Sometimes designing for change is necessary, but sometimes not. Sometimes OOP is nice, but sometimes not. It comes down to the fact that you don't design "for change", but for the customer. Granted, there are aesthetics involved. OOP captures some of these very nicely. But when you focus on the problem, and not the "methodology", you find that these and other aesthetics exist in every other language and every other methodology as well: from C to Scheme, from bash to VBScript, from the quick hack to the deep thought.
There is a lot of merit in a more managerial (because that is what most of the "software methodologies are: they have very little to do with engineering) approach to software development. Management requires measurement, and without procedure it becomes impossible to measure. So, software developers need to follow procedures, adopt a certain style of programming and adhere to standards. Otherwise it becomes impossible to measure progress. But you have to be careful not to confuse the measurements with the actual goal: just because the project follows a "design methodology" doesn't mean that the customer has to like the end result.
You are missing the point. Algorithms that work for ASCII will not work (and at the very least, are not certified to work) with Unicode. Programs that depend on IPv4 may not work (and at the very least, are not certified to work) with IPv6. And the notion that "most programs are around for such short periods anyway" is what brought us Y2K.
The problem is: these lists don't help. Vendors just put in the minimal effort required to satisfy the government's checklists, and you end up with an implementation that is for all purposes useless, except to pass the checklists and close the contract. This is what Microsoft did when they needed Windows NT to support POSIX. That the customer ends up with a severely braindamaged (but still compliant) product does not seem to matter.
When you build a bridge you can be certain that the laws of gravity won't change. When you build software you cannot be sure that in ten years time you'll be using ASCII, or TCP/IP.
It doesn't matter how much time you spend designing upfront. Obviously it is better to have a good design than a bad design or no design at all, but the design which is impervious to change simply does not exist. If your code is being used you will always need to go back and change your it. In the process errors creep in, no matter what. It does not help to make the errors very expensive. That just makes the software very expensive, very late, and very restricted. With possibly less errors. Because that is the problem: how will you know? We don't know now -- how does increasing the price help?
No, they shouldn't be. Unless you are paying for the certifications, that is.
The point is, when you willfully execute an email attachment, you share some of the blame.
In any case, considering the scale and duration of the US military operation in Afghanistan, how can you maintain that the US is respecting Afghan sovereignty within Afghan borders? A nation that cannot maintain sovereignty within its borders is not a nation. Ergo, the US destroyed the Afghan nation.
The PC pricewars came and went years ago. It was the age of the sub-$1000 PC, E-machines, Ellison's network computer, and all that. None of it happened of course. The market has stabilized since then. Computers are not getting that much cheaper anymore. You get a lot more value for your money each year: but in dollar figures the prices aren't dropping that fast anymore, if at all.
On the one hand you have the US holding an entire nation responsible for the crimes committed on 9/11. However, when millions upon millions of people open suspect attachments, then suddenly everybody agrees that the only person to blame is the virus writer. Without wanting to equate the two events, I don't see how you could argue that these positions do not in some way contradict each other.
Agreed. But the purpose of establishing guilt is to establish penalty. People who live in rough neighborhoods may not be guilty as such, but they are being subjected to harsher penalties than other people (i.e. increased cost of insurance). FWIW.