Ummm... They already *do* force you to decrypt anything they think might be evidence. UK style without-a-subpoena police powers are already doing the rounds through the legislature.
Agreed that this is a beautifully thought out protest.
Your tone about how great rights are in the US strikes me as a bit complacent however. British rights against governmental intrusion, and the poor defence of free speech are poor, rooted in an odd view that these aren't really matters of government at all. However the British track record on rspecting the paper rights that exist are better guaranteed than in the US. Also the US has extraordinary archaicisms existing (and occassionally enforced) at the state level. Check out the ACLU website and weep. I would say that overall, Germans have better rights in practice than Americans.
Lastly, the merits of of a formal constitution are easily overrated. Russians had excellent constitutional rights in th 1930s, and they weren't worth an awful lot.
Let me make my point another way: if one uses S-exps, then one finds oneself looking at an awful lot of nested brackets. With XML, one sees that s match s, etc.
The second point about typing is that, whilst one may easily test whether an S-expression is well-formed, one doesn't need to. In my view, a volutary type discipline such as LISP/Scheme uses is less than half a type discipline.
Lastly, about ease of use: there can be no doubt that using S-exps with LISP/Scheme is very natural: all of these wonderful tools such as quasiquotation. Also very natural to use in a UNIX setting with scsh or guile. But this is a `one size fits all' argument: tools exist in other languages for XML, but they don't for S-exp. I think XML has the edge on XML for ease of reading, but I understand that may be debated; still I think the point about language support trumps the issue.
And I am not getting at Scheme/LISP: scsh is one of my favourite languages...
Actually XML is a bit more general than S-exps in that it allows you to pass parameters, and specify that these parameters are optional, fixed, or have default values. Of course these can be simulated in LISP, but the ways XML handles them is cleaner.
Also XML has something resembling a type system in its DTDs, which seems somehwat alien to the LISP mindset...
It should be possible to write a set of filters to convert between XML and standard configuartion files. Whilst this a lot of work to begin with (ie. such a filter for each different kind of configuration file, which is pretty much one for each different configuration file, if it was possible to begin with a biggie) such as the.xinitrc file, that might create the momentum to convert over the other applications. Writing filters of course obviates the need for the application writers themselves to rework existing code, which may be pretty much impossible with something like X windows.
Of course people have been saying config files should be LISP S-expresions for years; maybe the hype about XML will be enough to make this idea work...
If you are interested in looking into Haskell, my main advice is to be prepared to spend time learning it: if you have never used a lazy functional programming language it takes time to learn how to use these features, and the way Haskell uses state (indirectly via `monads') is tricky to grasp.
the time is worth it in my opinion; laziness provides a powerful heuristic for attacking difficult optimisation problems efficiently: an application of haskell is in providing effiecnt dynamic prgramming solutions to NP hard optimisation problems, and then step-by-step transforming these into industrial strength `C' code. This strategy has produced some of the best solutions to the problem, because laziness captures a fruitful intuition about how to minimise resources in such problems.
If you are not enthusiastic about putting the time in, it is worth having a look at Objective CAML (`ocaml'), a language that combines an excellent marriage of objective and functional programming with one of the best development suites in functional programming. References to both can be found at the FAQ for comp.lang.functional.
Of course both languages lack `prevalence', though that may change, since Simon Peyton-Jones, one of the chief architects of Haskell, has taken a post at Microsoft...
I haven't read either this book or the book on patterns, so I may be well off the mark. However the key idea behind both of them seems to be old chestnuts in software engineering.
For design patterns, read reusability. Some languages, eg. Haskell, support a high degree of reusability in the way they work, and so one can implement the idea-in-itself once and for all, but in most languages you will find yourself reimplementing the same idea again and again.
Similarly with the current book, for refactoring read refinement. If we have programs M and N, and N terminates on the all of the inputs M does, and with the same observables, then N refines M.
Both of these ideas are important, and fraught with hazards in practice, so they are well deserving of a book length treatment. What irritates me is the contention that until now these ideas are ones we were only subconsciously aware of. Absurd: they are old ideas, and ones good sofware engineers are very conscious of.
I agree. It looks as if Microsoft's dominance into the next decade turns on the acceptance of windows 2000 as a server platform. Microsfot servers look badly squeezed: if you want cheap, innovation friendly servers, you can't beat Linux, whilst if you are willing to pay for rock solid, top performance, Solaris grand slams Microsoft.
The months following the full release of W2000 should be very interesting to watch. It could so easily be an OS/2 like disaster.
Back to the old GNU `is programming a manufacturing or service activity?' chestnut. The incentive to create this data in a service activity is different, namely I cannot provide my service unless the object of that service exists: people who need the data have the incentive to create it.
What I think is wrong with the manufacturing analogy is that it is an unnecessarily inclusive view of property: the minimal view of prpoerty is those property rights necessary to avoid conflict over resources, but intellectual property involves no such conflict: in copying your code I do not deny you use of it.
The usual argument for intellectual property one actually hears is: we will lose revenue if copying persists. So what? Southern plantation owners lost revenue when slavery was abolished. The law shouldn't be there to protect potential revenues of established interests.
BTW I am not a libertarian: I am a follower of Hume on these issues.
Stories in the media always seem to overhype artificial life. The idea is compelling, but the results are not so.
The key to artificial life is genetic algorithms. So far these are good at two things: optimising parameters on given designs, and coming up with (frequently surprising and elegant) non-modular solutions to design problems. However real life is highly modular: I have heard of no complex modular solution to a problem originating from a genetic algorithm. Until this happens, artifical life remains a promising idea that doesn't deliver.
When you talk of linux's problems with mulitple processors, I think that you are referring to its limited SMP capacity.
SMP (Symmetric Multi- Processing) is fundamentally different to clustering, as all of the processors in an SMP configuration share the same memory bus, whilst in a cluster the machine architectures are distinct, and we use a high-speed network to exploit parallelism.
Funny about how the history of computing is taught along national lines: I always learnt (I'm British) that the first general purpose computer (the Small Scale Experimental Machine, or SSEM) was built in Manchester, UK, in 1948, and german friends of mine learnt about the Z3 in school. Actually the SSEM was the first machine to store programs in memory: debatably a key component of the general purpose computer. I guess what counts as the first general purpose computer depends upon what you consider a machine needs to count as general purpose. Anyway you can read about the SSEM at Computer 50 .
I don't think karma qualities are symmetric: I haven't seen anyone complain about `interesting' or `insightful' being the kind of comments they don't want to see too much of. The problem is only that some people think that `funny' is overly up moderated.
So how about another test: your karma is as before, but you need at least 5 points of non-funny karma to get `enlightenment'?
Despite the FUD, the article makes a plausible point: Linux will need a lot of luck to displace Windows from the desktop.
And it also points out an important consolation: Linux can still be important without achieving this. Remember that Linus' objective for Linuzx is still not the desktop, but the server.
I think the most important point is: the success that Java and Linux so far have had is to make the MS `one size fits all' strategy look outdated.
An article has appeared in this weeks copy of the Economist online. It is mostly concerned with the impact of internet as a successor technology to the newspaper.
Quote:"Get rid of the need for physical inputs, however, and the economics of the business changes completely. Once the barriers to entry disappear, so does the rationale for the package of content and revenue that makes up a newspaper. Now that being a publisher costs so little, niche publishers can pick off speciality areas of content-the weather, say, or the stockmarket-and build a business around them. Classified advertisers can set up their own sites where prices to advertisers are likely to be lower because they do not have to pay for the physical inputs or subsidise the content. The newspaper, it turns out, was a hundred different businesses rolled into one; and, now that the economic glue that held them together has dissolved, they could fall apart."
Slashdot Mirror
The ruling actually was: use of source code in an explanation of how cryptographic algorithms work is a protected form of free speech.
It doesn't say anything about the content of encrypted communications.
Ummm... They already *do* force you to decrypt
anything they think might be evidence. UK style
without-a-subpoena police powers are already doing
the rounds through the legislature.
If it doesn't come from Bruce, is it a valid question?
In other words, to ESR: what specific thing did Bruce Perens say that you think he shouldn't have said in a public forum?
Agreed that this is a beautifully thought out protest.
Your tone about how great rights are in the US strikes me as a bit complacent however. British rights against governmental intrusion, and the poor defence of free speech are poor, rooted in an odd view that these aren't really matters of government at all. However the British track record on rspecting the paper rights that exist are better guaranteed than in the US. Also the US has extraordinary archaicisms existing (and occassionally enforced) at the state level. Check out the ACLU website and weep. I would say that overall, Germans have better rights in practice than Americans.
Lastly, the merits of of a formal constitution are easily overrated. Russians had excellent constitutional rights in th 1930s, and they weren't worth an awful lot.
Let me make my point another way: if one uses S-exps, then one finds oneself looking at an awful lot of nested brackets. With XML, one sees that s match s, etc.
The second point about typing is that, whilst one may easily test whether an S-expression is well-formed, one doesn't need to. In my view, a volutary type discipline such as LISP/Scheme uses is less than half a type discipline.
Lastly, about ease of use: there can be no doubt that using S-exps with LISP/Scheme is very natural: all of these wonderful tools such as quasiquotation. Also very natural to use in a UNIX setting with scsh or guile. But this is a `one size fits all' argument: tools exist in other languages for XML, but they don't for S-exp. I think XML has the edge on XML for ease of reading, but I understand that may be debated; still I think the point about language support trumps the issue.
And I am not getting at Scheme/LISP: scsh is one of my favourite languages...
Actually XML is a bit more general than S-exps in that it allows you to pass parameters, and specify that these parameters are optional, fixed, or have default values. Of course these can be simulated in LISP, but the ways XML handles them is cleaner.
Also XML has something resembling a type system in its DTDs, which seems somehwat alien to the LISP mindset...
It should be possible to write a set of filters to convert between XML and standard configuartion files. Whilst this a lot of work to begin with (ie. such a filter for each different kind of configuration file, which is pretty much one for each different configuration file, if it was possible to begin with a biggie) such as the .xinitrc file, that might create the momentum to convert over the other applications. Writing filters of course obviates the need for the application writers themselves to rework existing code, which may be pretty much impossible with something like X windows.
Of course people have been saying config files should be LISP S-expresions for years; maybe the hype about XML will be enough to make this idea work...
If you are interested in looking into Haskell, my main advice is to be prepared to spend time learning it: if you have never used a lazy functional programming language it takes time to learn how to use these features, and the way Haskell uses state (indirectly via `monads') is tricky to grasp.
the time is worth it in my opinion; laziness provides a powerful heuristic for attacking difficult optimisation problems efficiently: an application of haskell is in providing effiecnt dynamic prgramming solutions to NP hard optimisation problems, and then step-by-step transforming these into industrial strength `C' code. This strategy has produced some of the best solutions to the problem, because laziness captures a fruitful intuition about how to minimise resources in such problems.
If you are not enthusiastic about putting the time in, it is worth having a look at Objective CAML (`ocaml'), a language that combines an excellent marriage of objective and functional programming with one of the best development suites in functional programming. References to both can be found at the FAQ for comp.lang.functional.
Of course both languages lack `prevalence', though that may change, since Simon Peyton-Jones, one of the chief architects of Haskell, has taken a post at Microsoft...
I haven't read either this book or the book on patterns, so I may be well off the mark. However the key idea behind both of them seems to be old chestnuts in software engineering.
For design patterns, read reusability. Some languages, eg. Haskell, support a high degree of reusability in the way they work, and so one can implement the idea-in-itself once and for all, but in most languages you will find yourself reimplementing the same idea again and again.
Similarly with the current book, for refactoring read refinement. If we have programs M and N, and N terminates on the all of the inputs M does, and with the same observables, then N refines M.
Both of these ideas are important, and fraught with hazards in practice, so they are well deserving of a book length treatment. What irritates me is the contention that until now these ideas are ones we were only subconsciously aware of. Absurd: they are old ideas, and ones good sofware engineers are very conscious of.
I agree. It looks as if Microsoft's dominance into the next decade turns on the acceptance of windows 2000 as a server platform. Microsfot servers look badly squeezed: if you want cheap, innovation friendly servers, you can't beat Linux, whilst if you are willing to pay for rock solid, top performance, Solaris grand slams Microsoft.
The months following the full release of W2000 should be very interesting to watch. It could so easily be an OS/2 like disaster.
Back to the old GNU `is programming a manufacturing or service activity?' chestnut. The incentive to create this data in a service activity is different, namely I cannot provide my service unless the object of that service exists: people who need the data have the incentive to create it.
What I think is wrong with the manufacturing analogy is that it is an unnecessarily inclusive view of property: the minimal view of prpoerty is those property rights necessary to avoid conflict over resources, but intellectual property involves no such conflict: in copying your code I do not deny you use of it.
The usual argument for intellectual property one actually hears is: we will lose revenue if copying persists. So what? Southern plantation owners lost revenue when slavery was abolished. The law shouldn't be there to protect potential revenues of established interests.
BTW I am not a libertarian: I am a follower of Hume on these issues.
Stories in the media always seem to overhype artificial life. The idea is compelling, but the results are not so.
The key to artificial life is genetic algorithms. So far these are good at two things: optimising parameters on given designs, and coming up with (frequently surprising and elegant) non-modular solutions to design problems. However real life is highly modular: I have heard of no complex modular solution to a problem originating from a genetic algorithm. Until this happens, artifical life remains a promising idea that doesn't deliver.
When you talk of linux's problems with mulitple processors, I think that you are referring to its limited SMP capacity.
SMP (Symmetric Multi- Processing) is fundamentally different to clustering, as all of the processors in an SMP configuration share the same memory bus, whilst in a cluster the machine architectures are distinct, and we use a high-speed network to exploit parallelism.
See the Linux Parallel Processing HOWTO for more information.
Funny about how the history of computing is taught along national lines: I always learnt (I'm British) that the first general purpose computer (the Small Scale Experimental Machine, or SSEM) was built in Manchester, UK, in 1948, and german friends of mine learnt about the Z3 in school. Actually the SSEM was the first machine to store programs in memory: debatably a key component of the general purpose computer. I guess what counts as the first general purpose computer depends upon what you consider a machine needs to count as general purpose. Anyway you can read about the SSEM at Computer 50 .
I don't think karma qualities are symmetric: I haven't seen anyone complain
about `interesting' or `insightful' being the kind of comments they don't
want to see too much of. The problem is only that
some people think that `funny' is overly up moderated.
So how about another test: your karma is as before, but you need at least 5 points of non-funny karma to get `enlightenment'?
Easiest way to do this would be to give AC's a score of 0.5. Then any upwardly moderated AC post would appear above a non-AC unmoderated post.
Of course rob would have to change the arithmetic of the system...
Despite the FUD, the article makes a plausible point: Linux will need a lot of luck to displace Windows from the desktop.
And it also points out an important consolation: Linux can still be important without achieving this. Remember that Linus' objective for Linuzx is still not the desktop, but the server.
I think the most important point is: the success that Java and Linux so far have had is to make the MS `one size fits all' strategy look outdated.
An article has appeared in this weeks copy of
the Economist online. It is mostly concerned
with the impact of internet as a successor technology to
the newspaper.
Quote:"Get rid of the need for physical inputs, however, and the economics of the business changes completely. Once the barriers to entry disappear, so does the rationale for the package of content and revenue that makes up a newspaper. Now that being a publisher costs so little, niche publishers can pick off speciality areas of content-the weather, say, or the stockmarket-and build a business around them. Classified advertisers can set up their own sites where prices to advertisers are likely to be lower because they do not have to pay for the physical inputs or subsidise the content. The newspaper, it turns out, was a hundred different businesses rolled into one; and, now that the economic glue that held them together has dissolved, they could fall apart."
The article is available at www.economist.com