I think this is an *excellent* point. The quoted figures are fairly obviously meaningless - either an enormous number of people are looking for this stuff, or there is a much smaller number of apparently very stupid and very persistent people, or it is largely robots, or the numbers are made up.
I think detailed statistics are needed before this data is even worth considering seriously. How many accesses, from how many distinct users with an indication of certainty, and to how many distinct places, and for each place, who decided that it was child porn? I think all this can be published without revealing either user details, or enough about what they were trying to access that it can be used by someone else to access this material. It's important, in particular, to publish the details of who made the decision, and why: there can be no good reason to conceal this.
"Runs trivial little games and applications using Java" means that one of the things which is seriously profitable to mobile operators - downloaded games - uses Java. That's actually a big deal.
It's not the saboteurs you should be worrying about (or rather, you should be worrying, but this won't stop them), it's the fools. The people who think it's fine to take something home and put it on their machine, which is sitting on a DSL line without much security. Your corporate firewall is now as weak as the security on this machine.
I know Lisp is not the ideal language - its ugly, illegible, and slower than compiled languages
Ugly and illegible are matters of opinion - most Lisp people will gladly trade a certain amount of syntactic suger for extensibily. `Slower than compiled languages' is just silly: modern (say, in the last 30 years) Lisp implementations are (a) compiled, and (b) not generally slow.
`Encrypting the data first' sounds good, until you think for a bit. The application needs to be able to decrypt the data, and to do that it needs some key. Where does it keep that key? In memory from where it can be paged to disk, from where the key can be recovered. Oops.
There are two solutions I can think of:
1. enhance the system so memory pages can be marked as `never copy this to disk'. This probably works, but would interact in interesting ways with suspend/resume features (as in: stop them working).
2. Do the crypto somewhere which isn't ever stored in memory, such as on some kind of smart card.
Well, I have 50 minutes a day of (offpeak) free calls, and I spend the week away from my partner, so I probably use most of them. that's, say, 250 minutes a week (4x50 + maybe 30-50 minutes peak-time calls), or 1000 minutes in 4 weeks.
I think HTML is a bad choice because it fails to be programming.
But it's almost a good choice. If there was a system which had as little syntax as HTML, and in which it was terribly easy to produce HTML pages as output, as everyone can look at them, but was a programming language, then it would be very interesting.
Javascript fails this horribly because it's a complete other syntax and it just is going to confuse people. PHP may be better, I don't know it. Personally, I'd go for one of the Lisp-based HTML-generation things: since Lisp syntax is tagged-bracket-based, like XML, they are a very close match:
(:html
(:head
(:title "my first page"))
(:body
(loop for i from 1 to 10
do (htm (:p (fmt "paragraph %d" i))))
(:hr)
(:p "Final paragraph, bye bye")))
PHP may be as lightweight as that, in which case it might be a better match.
I've always been amused by the people who boast about how their laptop (usually) drive is encrypted using some million-bit filesystem and is therefore `secure' even if someone steals the machine.
Of course, they don't remember the million bits, oh no, they have a passphrase, which is something they can reliably type blind and remember, probably some few 10s of effective bits (as it's probably English).
Yeah, it's a lot of money, but it costs much less then some of the jewelry worn at the Oscars... and this is much cooler then some bling-bling necklace.
Actually, it's ugly as fuck, isn't it? If I had that kind of money to spend on a car I'd definitely try and buy something that didn't look quite so horrible. An AC Ace (for instance) is probably just as fun to drive and a lot more interesting (so it's 50 years old, who actually cares?). I'm sure a souped-up Lotus of some kind is just as exciting to drive, much prettier. You could both, and say a Bristol for day-to-day use, and a house, with the same money.
So, well, I think this is definitely appealing to the I-have-something-to-make-up-for crowd.
Well, it might be everywhere, but it probably won't work when you need it to: when the terminal type is not set right, or when you're editing from a glass tty or worse (in the old days a paper console, nowadays a mobile phone), or when/tmp isn't writable.
The issue isn't really whether it runs Windows, it's whether the ship has a single point of failure, and whether that single point of failure involves software. A warship should have as few single points of failure as it can, and if it must have them, they should be extremely well-protected. For software that means some combination of multiple redundant everything, multiple independent implementations, proved code, and other things (for instance: the power supply to the machines is now a potential single point of failure...). What it doesn't mean is something as trite as `use Linux', sorry.
The Yorktown is a well-known example of a design in which some of these requirements were obviously not met. I fully expect that this ship will also fail to meet them, but perhaps they have learnt their lesson.
It's not that simple. The hardware is cheap, and the software is fairly cheap, but being able to configure it so it works remains expensive. `Works' generally means at least the following. It must be there all the time - you need to decide what you have to survive (a machine failure? a fire? a bomb or other event which means you can't get access to your data centre for a week?) with what effects (how long can it be down for? how much data can you afford to lose?), and at what cost. It must be seamlessly reconfigurable: grow, shrink, or reallocate storage, replace failed disks or arrays, including boot disks, with no interruption to service. Physically migrate storage from place to place with no interruption to service. Recover within a small number of seconds if any of these operations fails half way through. And so on. And you have to make sure that the systems you choose will meet your requirements, which they almost certainly will not do out of the box. This is still hard, although the tools to do it are improving.
The flip side of this is that this is likely irrelevant for google. If I have a free email account, I don't think I should expect that they back it up for me! So long as they don't lose too many disks, they can afford to just lose people's mail once in a while. And, of course, offer a non-free email account which *is* backed up...
Yes, they have bash and OpenSSL. Bash has been in at least the `everything' install since 8 (and probably smaller ones too, and of course you can always just add the packages), OpenSSL since 9 I think.
If you install the Sun bonus CD (? I forget the name, anyway its one of the ones that comes with the media if you have that, and you can also download it), you also get a load of free software packages including emacs (both of them), most of the gnu stuff including gcc &c &c, kde and so on. And there's yet more at sunfreeware of course.
If you want to get remote access from a PC, get cygwin and install the XFree86 packages. Then is't pretty much as simple as XWin:0 -query host Although you may need to set font paths.
Well, we run 7 and 8 in production and 9 in development, and I have just a huge mass of free software. which I've built. I admit it's been a while since I compiled anything really huge (bigger than gcc say, and even there I think we're still on 3.3), but I don't often have problems. I have built gnome in the past and I don't remember it being a saga. I'd not bother building it now since it ships with 9, but I kind of assume it builds OK since it does ship with 9...
Maybe the issue is not using gcc? A substantial proportion of `C' software is actually *gcc* software, so you really need it. In just the same way a large number of linux `shell scripts' are actually `bash scripts'.
There are many languages that can compile into IL, allowing for greater flexibility.
Well. You can compile languages for.NET reasonably easily providing they're suitably similar to C# or Java. It's not at all all easy to compile languages which aren't. Say a language with a type system which is not tree structured: you end up having to implement your own type system, which kind of defeats the point, and makes integration with other languages hard. Such languages exist, for instance Common Lisp.
Of course, the JVM has these issues too, but it never claimed to be language-neutral.
As others have pointed out, that's not the same thing at all: what Verisign want to do is to usurp the basic look-up-a-name service.
In fact, I'd expect Microsoft &co to *strongly* object to this, since what it will mean is that dns lookups will eseentially never fail, so you'll never see the search page from IE &c. Essentially Verisign are going to start providing the service that MS now does for IE users, and google now does for Mozilla!
Once upon a time there was a programming language called Lisp. It had a small market share, but not by any means nothing. There were some people in the Lisp community who didn't like recent developments in Lisp very much and thought they'd go off and invent a new language which would be Lisp, but `better'. They did this, the language was called Dylan, and maybe it was better than Lisp. Of course in the process of doing this they annoyed some Lisp people who thought all this effort would be better spent on Lisp, but that was probably inevitable.
What they then did was to commit slow suicide, and make a good attempt to take Lisp with them.
What Dylan needed was some market share. There were two (well, there were more than two, but I'm allowed to simplify on/.) possible markets to aim at:
The Lisp market was small, possibly shrinking (actually not, it turns out), and many players were not well disposed to the Dylan people. Lisp was actually meeting the challenges of its market quite well: despite the propaganda it's an extremely good language for solving certain classes of problems.
The C++ market was enormous, and growing at a huge rate. It was becoming apparent even then that C++ simply wasn't a suitable language for the applications which it was being used to develop: C++ projects were late, buggy, and expensive, where they didn't fail altogether. Managers of C++ projects didn't know Dylan from Adam, but they were definitely interested in anything that wasnn't C++.
So what did they do? They tried to get the Lisp market. They were never going to get all of it, so their best possible case was to get maybe half of it. It wasn't growing very fast, and it wasn't likely to do so any time soon for various reasons, so it wasn't like both Dylan and Lisp could win. Finally, being ex-Lisp people, and thus even more socially inept than most computing people (which is saying something), they tried to compete by badmouthing the competition.
In the end they got none of the Lisp market, and Dylan just died, leaving a trail of damage and ill-will in its wake.
Meanwhile, some other people (some of them ex Lisp people even) were working on a new language with some of the characteristics of Lisp - particularly garbage collection. They were rather smarter than the Dylan people, so they did a good deal better job of designing the language, making it simple enough to be usable by average programmers (where both Lisp and Dylan fail). Being smarter than the Dylan (or Lisp) people, they also went for the C++ market. And though they've not yet destroyed it, they've made enormous inroads, and they've certainly had more impact than Lisp and Dylan put together in the last 10 years. The language they designed was Java.
Linux seems to be intent on doing a Dylan, with Unix playing the Lisp role. Maybe Linux will win, but it's just aiming at the wrong target: who wants a part of a small, slowly-growing market?
Unfortunately the analogy breaks down here: Windows plays the role of C++, but Linux has epsilon chance of getting more than a tiny chunk of the Windows market. Instead it needs to find a new market, and not grovel around fighting Unix. My bet would be embedded systems: there are billions and billions of these things, they either are now or will shortly be easily competent to run a Unix-family OS, and neither Windows nor Unix has any market share here at all.
But of course it's easier to sit around badmouthing Unix than to think.
I don't know about surfing the net, but I use CVS tunnelled over ssh via BT / GPRS all the time. It's really bandwidth-efficient, and I can write stuff anywhere there's mobile coverage (not just in the few places where there happens to be WiFi).
Of course Sun want to have MS's market share: all companies want to have a monopoly on a large market. Don't you? I certainly do! It is not wrong for companies to want this, it is just a completely natural part of how capitalism works: you make more money for less effort if you are a monopolist. What should happen is that companies desperately want to become monopolies, but the legal system prevents them doing so.
What is wrong is that the legal system seems to have failed to prevent MS from being a monopolist.
I live in a cob house, which is at least 200 years old, and parts of which may be much older. There are cob houses close to where I live which are 7-800 years old (I'm in the UK). Cob is a fine building material so long as you keep it fairly dry - if the roof comes off the building then the walls will disolve as rain & frost eat them from the top down.
The main thing with houses built to last is that you can't build some `perfect' house which will then sit there for hundreds of years with no maintenance. Instead you build something which is sound, and maintainable and then you maintain it. Cob (for instance) is good for that because a cob house is basically a mud hut - it's a pile of stuff on which you can pile other stuff, and old cob houses will have had new bits added to them more-or-less continuously over their lives. Of course, eventually there's nothing left of the original structure, but this probably takes thousands of years, unless you deliberately pull bits down (the 7-800 year-old houses I mentioned above are substantially original: my house for instance might easily be based on something which is that old, but there is not very much left now, if anything - maybe a wall somewhere).
This brings up the question of how old a house actually is: if it's all been incrementally replaced is it old any more? The question is really meaningless of course, since the whole point of building something maintainable is that you can replace more-or-less all of it incrementally. Typically, I guess, houses are defined as old if some substantial part of their still-existing structure is old: using that definition, cob houses, well maintained, can probably last 1000 years fairly easily, as can other constructions.
In many cases, the limit on how long a house or other structure lasts is not that it wears out, but that it becomes somewhere people don't want to live any more. No-one *wants* to live in a castle - or not in a real, defensible, castle - because they have no windows. You live in a castle because you have to, and the moment you stop having to - either because the world is now safer, or because you can't defend the castle anyway because someone has invented guns - you build some nice house with thinner walls and windows and go and live in that instead. Similarly, people stopped wanting to live in the medieval cob houses around here, which typically had one room for the people, with a hole in the roof for the smoke and one room for the animals with a drain running down it, and tiny windows &c. Many of them became barns, and many of the rest got converted by adding floors, chimneys, more rooms and so on, until the original house was unrecognisable (you can often tell the house is really old by finding smoke-blackened timbers in the roof structure). For those that are still houses, you have to accept them for what they are if you live in them: sometimes cold, sometimes damp, walls occasionally fall down, and so on. Lots of people can't hack that (and lots of old houses have been badly damaged by people who can't live with their properties: vinyl paint seals in the damp, so the house is `dry', except the damp is now trapped in the walls, which eventually disolve for instance).
So I think the answer is that building to last is not that hard: don't build in crucial components which will wear out (like structurally-critical steel, which will rust through in a few hundred years), and build for maintenance, and you'll be fine. There are enormous numbers of really old houses in Europe. But building a house that people will *want* to live in in hundreds of years is a different issue. Personally, I like my mud hut, but lots of people might not.
Putting the cost of making the caller is just exactly a solution to the problem, if you make it enough. How much spam would there be if it cost 10 cents (say) to send an email? Not much, I guess.
Making the person who is causing the trouble pay for it is in general a much better way of solving the problem than legislating it out of existence.
Other solutions that work for me - I was an IT contractor and in the IT frenzy I used to get a lot of agent calls are:
Multiple numbers. It's very cheap to have multiple numbers on phones here, and they can have different ring tones or be forwarded differently. We have one `company' number which goes to whoever is meant to be answering company calls, and then each of us has a public number (which we tell agents ) and a private number which we tell no-one. Forwarding calls within our telco is free, so we just set things up as we like.
voicemail. Also free for us, and quite often I set the public and/or company numbers just to go to voicemail and then, maybe, listen to it later.
But mostly, thre fact that it actually costs people to make a call means that only people who actually want to talk to you will call.
Seriously, while no one (well, not me) is going to want to watch porn on some poxy PDA screen, I've thought about something like this. I actually think that phones and PDAs will become the same thing - take a phone, get rid of the keyboard and replace the whole front of it with a LCD touch screen with a *picture* of a keyboard, and it looks pretty much like a palmpilot. I thought of this in 1999, so loads of people must have thought of it before me. So why hasn't it happened? Well, one reason is that PDAs aren't that useful compared to mobiles. Here in the UK, nerdy people and flashy management types have PDAs, but *everyone* has a mobile. I mean, I have *three*, and I'm a late-adopter. I just moved house, and the only reason I got a landline was because I wanted ISDN (it's really remote, no ADSL). I don't have a PDA though.
I think the killer-app is micro-billing. Telcos have billing systems which can bill down to a few cents, and make money doing it. They should become proxies for other people who want to do that. A phone is (fairly) secure, and with bluetooth you can have a nice transaction with the phone (and hence the telco) to charge tiny amounts.
These people have no idea what they're doing. Eight years ago they didn't see SMS coming. Four years ago, awash with cash, they saw the web, and got together in a big committee and decided that the future was a cut-down version of that, so they formed another big committee and invented WAP, which was a dismal failure. Two years ago they spent all their money on 3G licenses and infrastructure, thus making the problem of finding a killer app somewhat urgent. But they still have no idea. The best thing they can think of is video on demand, but who is going to pay for porn on a tiny phone screen? So here they are again, with another big committee trying to invent the next big thing.
I don't know what the next big thing for mobiles is, but I do know that it's not going to be invented by this, or any other, big committee. It is safe to ignore anything these people do.
Slashdot Mirror
I think this is an *excellent* point. The quoted figures are fairly obviously meaningless - either an enormous number of people are looking for this stuff, or there is a much smaller number of apparently very stupid and very persistent people, or it is largely robots, or the numbers are made up.
I think detailed statistics are needed before this data is even worth considering seriously. How many accesses, from how many distinct users with an indication of certainty, and to how many distinct places, and for each place, who decided that it was child porn? I think all this can be published without revealing either user details, or enough about what they were trying to access that it can be used by someone else to access this material. It's important, in particular, to publish the details of who made the decision, and why: there can be no good reason to conceal this.
"Runs trivial little games and applications using Java" means that one of the things which is seriously profitable to mobile operators - downloaded games - uses Java. That's actually a big deal.
It's not the saboteurs you should be worrying about (or rather, you should be worrying, but this won't stop them), it's the fools. The people who think it's fine to take something home and put it on their machine, which is sitting on a DSL line without much security. Your corporate firewall is now as weak as the security on this machine.
Ugly and illegible are matters of opinion - most Lisp people will gladly trade a certain amount of syntactic suger for extensibily. `Slower than compiled languages' is just silly: modern (say, in the last 30 years) Lisp implementations are (a) compiled, and (b) not generally slow.
`Encrypting the data first' sounds good, until you think for a bit. The application needs to be able to decrypt the data, and to do that it needs some key. Where does it keep that key? In memory from where it can be paged to disk, from where the key can be recovered. Oops.
There are two solutions I can think of:
1. enhance the system so memory pages can be marked as `never copy this to disk'. This probably works, but would interact in interesting ways with suspend/resume features (as in: stop them working).
2. Do the crypto somewhere which isn't ever stored in memory, such as on some kind of smart card.
Well, I have 50 minutes a day of (offpeak) free calls, and I spend the week away from my partner, so I probably use most of them. that's, say, 250 minutes a week (4x50 + maybe 30-50 minutes peak-time calls), or 1000 minutes in 4 weeks.
So why is 1025 minutes such a lot?
I think HTML is a bad choice because it fails to be programming.
But it's almost a good choice. If there was a system which had as little syntax as HTML, and in which it was terribly easy to produce HTML pages as output, as everyone can look at them, but was a programming language, then it would be very interesting.
Javascript fails this horribly because it's a complete other syntax and it just is going to confuse people. PHP may be better, I don't know it. Personally, I'd go for one of the Lisp-based HTML-generation things: since Lisp syntax is tagged-bracket-based, like XML, they are a very close match:
(:html
(:head
(:title "my first page"))
(:body
(loop for i from 1 to 10
do (htm (:p (fmt "paragraph %d" i))))
(:hr)
(:p "Final paragraph, bye bye")))
PHP may be as lightweight as that, in which case it might be a better match.
I've always been amused by the people who boast about how their laptop (usually) drive is encrypted using some million-bit filesystem and is therefore `secure' even if someone steals the machine.
Of course, they don't remember the million bits, oh no, they have a passphrase, which is something they can reliably type blind and remember, probably some few 10s of effective bits (as it's probably English).
So how secure is this data, again?
Actually, it's ugly as fuck, isn't it? If I had that kind of money to spend on a car I'd definitely try and buy something that didn't look quite so horrible. An AC Ace (for instance) is probably just as fun to drive and a lot more interesting (so it's 50 years old, who actually cares?). I'm sure a souped-up Lotus of some kind is just as exciting to drive, much prettier. You could both, and say a Bristol for day-to-day use, and a house, with the same money.
So, well, I think this is definitely appealing to the I-have-something-to-make-up-for crowd.
vi is everywhere? I think not.
/tmp isn't writable.
Well, it might be everywhere, but it probably won't work when you need it to: when the terminal type is not set right, or when you're editing from a glass tty or worse (in the old days a paper console, nowadays a mobile phone), or when
What you really need to know is ed.
--tim
The issue isn't really whether it runs Windows, it's whether the ship has a single point of failure, and whether that single point of failure involves software. A warship should have as few single points of failure as it can, and if it must have them, they should be extremely well-protected. For software that means some combination of multiple redundant everything, multiple independent implementations, proved code, and other things (for instance: the power supply to the machines is now a potential single point of failure...). What it doesn't mean is something as trite as `use Linux', sorry.
The Yorktown is a well-known example of a design in which some of these requirements were obviously not met. I fully expect that this ship will also fail to meet them, but perhaps they have learnt their lesson.
It's not that simple. The hardware is cheap, and the software is fairly cheap, but being able to configure it so it works remains expensive. `Works' generally means at least the following. It must be there all the time - you need to decide what you have to survive (a machine failure? a fire? a bomb or other event which means you can't get access to your data centre for a week?) with what effects (how long can it be down for? how much data can you afford to lose?), and at what cost. It must be seamlessly reconfigurable: grow, shrink, or reallocate storage, replace failed disks or arrays, including boot disks, with no interruption to service. Physically migrate storage from place to place with no interruption to service. Recover within a small number of seconds if any of these operations fails half way through. And so on. And you have to make sure that the systems you choose will meet your requirements, which they almost certainly will not do out of the box. This is still hard, although the tools to do it are improving.
The flip side of this is that this is likely irrelevant for google. If I have a free email account, I don't think I should expect that they back it up for me! So long as they don't lose too many disks, they can afford to just lose people's mail once in a while. And, of course, offer a non-free email account which *is* backed up...
I don't think so. I've had 1GB of spam in a week, and I'm sure I'm not unusual. Their spam filtering will have to be pretty good.
Yes, they have bash and OpenSSL. Bash has been in at least the `everything' install since 8 (and probably smaller ones too, and of course you can always just add the packages), OpenSSL since 9 I think.
:0 -query host
If you install the Sun bonus CD (? I forget the name, anyway its one of the ones that comes with the media if you have that, and you can also download it), you also get a load of free software packages including emacs (both of them), most of the gnu stuff including gcc &c &c, kde and so on. And there's yet more at sunfreeware of course.
If you want to get remote access from a PC, get cygwin and install the XFree86 packages. Then is't pretty much as simple as
XWin
Although you may need to set font paths.
Only if you have a functioning brain. So probably not.
Well, we run 7 and 8 in production and 9 in development, and I have just a huge mass of free software. which I've built. I admit it's been a while since I compiled anything really huge (bigger than gcc say, and even there I think we're still on 3.3), but I don't often have problems. I have built gnome in the past and I don't remember it being a saga. I'd not bother building it now since it ships with 9, but I kind of assume it builds OK since it does ship with 9...
Maybe the issue is not using gcc? A substantial proportion of `C' software is actually *gcc* software, so you really need it. In just the same way a large number of linux `shell scripts' are actually `bash scripts'.
Of course, the JVM has these issues too, but it never claimed to be language-neutral.
As others have pointed out, that's not the same thing at all: what Verisign want to do is to usurp the basic look-up-a-name service.
In fact, I'd expect Microsoft &co to *strongly* object to this, since what it will mean is that dns lookups will eseentially never fail, so you'll never see the search page from IE &c. Essentially Verisign are going to start providing the service that MS now does for IE users, and google now does for Mozilla!
What they then did was to commit slow suicide, and make a good attempt to take Lisp with them.
What Dylan needed was some market share. There were two (well, there were more than two, but I'm allowed to simplify on
So what did they do? They tried to get the Lisp market. They were never going to get all of it, so their best possible case was to get maybe half of it. It wasn't growing very fast, and it wasn't likely to do so any time soon for various reasons, so it wasn't like both Dylan and Lisp could win. Finally, being ex-Lisp people, and thus even more socially inept than most computing people (which is saying something), they tried to compete by badmouthing the competition.
In the end they got none of the Lisp market, and Dylan just died, leaving a trail of damage and ill-will in its wake.
Meanwhile, some other people (some of them ex Lisp people even) were working on a new language with some of the characteristics of Lisp - particularly garbage collection. They were rather smarter than the Dylan people, so they did a good deal better job of designing the language, making it simple enough to be usable by average programmers (where both Lisp and Dylan fail). Being smarter than the Dylan (or Lisp) people, they also went for the C++ market. And though they've not yet destroyed it, they've made enormous inroads, and they've certainly had more impact than Lisp and Dylan put together in the last 10 years. The language they designed was Java.
Linux seems to be intent on doing a Dylan, with Unix playing the Lisp role. Maybe Linux will win, but it's just aiming at the wrong target: who wants a part of a small, slowly-growing market?
Unfortunately the analogy breaks down here: Windows plays the role of C++, but Linux has epsilon chance of getting more than a tiny chunk of the Windows market. Instead it needs to find a new market, and not grovel around fighting Unix. My bet would be embedded systems: there are billions and billions of these things, they either are now or will shortly be easily competent to run a Unix-family OS, and neither Windows nor Unix has any market share here at all.
But of course it's easier to sit around badmouthing Unix than to think.
I don't know about surfing the net, but I use CVS tunnelled over ssh via BT / GPRS all the time. It's really bandwidth-efficient, and I can write stuff anywhere there's mobile coverage (not just in the few places where there happens to be WiFi).
Of course Sun want to have MS's market share: all companies want to have a monopoly on a large market. Don't you? I certainly do! It is not wrong for companies to want this, it is just a completely natural part of how capitalism works: you make more money for less effort if you are a monopolist. What should happen is that companies desperately want to become monopolies, but the legal system prevents them doing so.
What is wrong is that the legal system seems to have failed to prevent MS from being a monopolist.
I live in a cob house, which is at least 200 years old, and parts of which may be much older. There are cob houses close to where I live which are 7-800 years old (I'm in the UK). Cob is a fine building material so long as you keep it fairly dry - if the roof comes off the building then the walls will disolve as rain & frost eat them from the top down.
The main thing with houses built to last is that you can't build some `perfect' house which will then sit there for hundreds of years with no maintenance. Instead you build something which is sound, and maintainable and then you maintain it. Cob (for instance) is good for that because a cob house is basically a mud hut - it's a pile of stuff on which you can pile other stuff, and old cob houses will have had new bits added to them more-or-less continuously over their lives. Of course, eventually there's nothing left of the original structure, but this probably takes thousands of years, unless you deliberately pull bits down (the 7-800 year-old houses I mentioned above are substantially original: my house for instance might easily be based on something which is that old, but there is not very much left now, if anything - maybe a wall somewhere).
This brings up the question of how old a house actually is: if it's all been incrementally replaced is it old any more? The question is really meaningless of course, since the whole point of building something maintainable is that you can replace more-or-less all of it incrementally. Typically, I guess, houses are defined as old if some substantial part of their still-existing structure is old: using that definition, cob houses, well maintained, can probably last 1000 years fairly easily, as can other constructions.
In many cases, the limit on how long a house or other structure lasts is not that it wears out, but that it becomes somewhere people don't want to live any more. No-one *wants* to live in a castle - or not in a real, defensible, castle - because they have no windows. You live in a castle because you have to, and the moment you stop having to - either because the world is now safer, or because you can't defend the castle anyway because someone has invented guns - you build some nice house with thinner walls and windows and go and live in that instead. Similarly, people stopped wanting to live in the medieval cob houses around here, which typically had one room for the people, with a hole in the roof for the smoke and one room for the animals with a drain running down it, and tiny windows &c. Many of them became barns, and many of the rest got converted by adding floors, chimneys, more rooms and so on, until the original house was unrecognisable (you can often tell the house is really old by finding smoke-blackened timbers in the roof structure). For those that are still houses, you have to accept them for what they are if you live in them: sometimes cold, sometimes damp, walls occasionally fall down, and so on. Lots of people can't hack that (and lots of old houses have been badly damaged by people who can't live with their properties: vinyl paint seals in the damp, so the house is `dry', except the damp is now trapped in the walls, which eventually disolve for instance).
So I think the answer is that building to last is not that hard: don't build in crucial components which will wear out (like structurally-critical steel, which will rust through in a few hundred years), and build for maintenance, and you'll be fine. There are enormous numbers of really old houses in Europe. But building a house that people will *want* to live in in hundreds of years is a different issue. Personally, I like my mud hut, but lots of people might not.
Putting the cost of making the caller is just exactly a solution to the problem, if you make it enough. How much spam would there be if it cost 10 cents (say) to send an email? Not much, I guess.
Making the person who is causing the trouble pay for it is in general a much better way of solving the problem than legislating it out of existence.
Other solutions that work for me - I was an IT contractor and in the IT frenzy I used to get a lot of agent calls are:
Multiple numbers. It's very cheap to have multiple numbers on phones here, and they can have different ring tones or be forwarded differently. We have one `company' number which goes to whoever is meant to be answering company calls, and then each of us has a public number (which we tell agents ) and a private number which we tell no-one. Forwarding calls within our telco is free, so we just set things up as we like.
voicemail. Also free for us, and quite often I set the public and/or company numbers just to go to voicemail and then, maybe, listen to it later.
But mostly, thre fact that it actually costs people to make a call means that only people who actually want to talk to you will call.
...on vibrate, presumably.
Seriously, while no one (well, not me) is going to want to watch porn on some poxy PDA screen, I've thought about something like this. I actually think that phones and PDAs will become the same thing - take a phone, get rid of the keyboard and replace the whole front of it with a LCD touch screen with a *picture* of a keyboard, and it looks pretty much like a palmpilot. I thought of this in 1999, so loads of people must have thought of it before me. So why hasn't it happened? Well, one reason is that PDAs aren't that useful compared to mobiles. Here in the UK, nerdy people and flashy management types have PDAs, but *everyone* has a mobile. I mean, I have *three*, and I'm a late-adopter. I just moved house, and the only reason I got a landline was because I wanted ISDN (it's really remote, no ADSL). I don't have a PDA though.
I think the killer-app is micro-billing. Telcos have billing systems which can bill down to a few cents, and make money doing it. They should become proxies for other people who want to do that. A phone is (fairly) secure, and with bluetooth you can have a nice transaction with the phone (and hence the telco) to charge tiny amounts.
These people have no idea what they're doing. Eight years ago they didn't see SMS coming. Four years ago, awash with cash, they saw the web, and got together in a big committee and decided that the future was a cut-down version of that, so they formed another big committee and invented WAP, which was a dismal failure. Two years ago they spent all their money on 3G licenses and infrastructure, thus making the problem of finding a killer app somewhat urgent. But they still have no idea. The best thing they can think of is video on demand, but who is going to pay for porn on a tiny phone screen? So here they are again, with another big committee trying to invent the next big thing.
I don't know what the next big thing for mobiles is, but I do know that it's not going to be invented by this, or any other, big committee. It is safe to ignore anything these people do.