Thank you for correcting me, there... I had already posted a big question mark about my original assertion about the newspaper... I suspected I had that wrong shortly after posting it.
Even as a Canadian living there, now back in Canada, I get very patriotic about Switzerland. The country got blind-sided by the ferocity of the American media in 1996-1998, and took an image loss that they didn't deserve.
The balance ends up being less "official state channels" as much as "not overtly commercial channels". "State" channels there tend to be "democratic" channels; not that it's perfect, but it works well because of a high degree of democratic participation. I question, in return, the frightening concept that only candidates with a major fund-raising organisation, capable of mounting a major media assault, are allowed a real voice in North American "democracy".
Limitations on "free speech" are inevitable. They choose to make different ones; ones which support a very lively political culture. (Albeit something of a tempest in a little Alpine teapot at times:-) )
As for WWII: The hard questions were definitely asked; whether CNN found them sensational enough to report on this side of the ocean I don't know. In many cases, they were also asked 40 years ago, and are "old news" to the Swiss. Just as hard questions about nuking opponents, turning away Jewish refugees, and numerous war-crimes perpetrated by Allied forces in Europe, prompted soul searching here. Wars are not fought out of moral obligation.
... settled problem... after attempts to do so in 1948 and the late 60's. Bronfman was looking for an issue to make hay on, and if you followed it closely, made less hay than he had hoped.
No country is without their historical blemishes. I'll look at the modern U.S. if you'll look at modern Switzerland. Deal?
For their size, their location in what was, until recently, an occasionally very nasty part of Europe, they have done remarkably well as an example of civil society and democracy.
Modern Switzerland took in more refugees per capita in the late 1990's than any other country in the world. Almost 1 in a 100 living there was a refugee at one point; 3 times more than Germany. This was done with stunning generosity and generated surprisingly little social stress or internal conflict. There are many instances during WWII as well where the generous character of the Swiss (generalising again) was apparent.
Sadly, overcoming slavery had as much to do with economics as rights.
My experience in Europe has shown me how a brush with really, really bad government can instill an enthusiasm for good government and constitutional democratic change. Witness Germany, and if my bets are right, watch Croatia.
These solutions can't really be called "European" in the sense of the European Union: Switzerland isn't a member.
The Swiss (if I may generalise horribly) would see leveraging your wealth to get to voters to be a violation of free speech. You are, by merit of money alone, able to drown out others and dominate discussions. I'd be surprised if that same case couldn't be made in the U.S.
As for women and the vote, the earliest referenda on that were held although the Swiss voted in a referendum about giving women the vote as early as 1914 (if I recall correctly), it was simply, democratically, rejected. Discussions started in 1885 on the topic.
Things tend to move a little slowly over there... usually a good thing, I think.
I don't think we're actually off that much on our opinion. Maybe I expressed the point "I've found that the more versions of the code there are..." a little unfortunately. I agree fully about keeping expressions such that they have a unique point to make, that content has to win over form (as noted in that Agile Modelling site).
I'm just saying that where content is not directly testable, inspection fills that consistency checking gap. But you seem to agree with me there...:-)
Good points, I'm not talking about creating non-executable stuff for the sake of it, just where there is a genuine need for another expression of the system, keep it consistent.
For example, the big-big-boss might say "We need a more efficient and faster transaction handling system." and might not say anything more. That expression of the "system requirements" is in "big-big-boss" language and must be executed by his staff. For a large system that means inevitable intermediate expressions of the code. I think the problem lies in how one keeps them consistent without increasing the workload, i.e. by making that consistency almost automatic.
My comment was intended to imply not that there should be many redundant code expressions, just that where there are any, and they are truly required, keeping them consistent catches a lot of problems.
I've heard your type of objection many times, usually by people who have been burdened by a heavyweight process that isn't delivering savings. It's a shame that poor process has given so many people a nasty taste in their mouth for efforts in that direction; I saw that a lot where I worked. I also saw a project that rejected my advice slip 3 years over on their 2 year schedule, swearing every quarter that they were only 6 months from release.
My team of 2 cracked out a mathematical analysis system with 56K operating lines of low-redundancy analysis code, 40K lines of support code with about 80% of that in support documentation, fully tested, cross referenced etc. in 8 months. It ran 2 years in production and never failed. I credit low-effort design techniques that maintained consistency to being able to do that.
... by banning partisan political advertising on TV, in newspapers and on the radio. You want to know about issues in an upcoming referendum or election there? You can ask for position papers from the candidates, listen to debates open to all candidates, read reports in the three daily and several weekly newspapers from independent publishers across the political spectrum. Posters are permitted, as are a limited number of mass-mailings, if they are directly addressed.
Suddenly, campaigning gets cheap! No more competition by who can afford the most attack ads during the 6pm news slot.
Then again, Swiss democracy is 500 years older than American democracy. I suppose it could take a while for the U.S., and Canada for that matter, to catch up... *sigh*... (I'm Canadian, but lived in Switzerland for 6 years).
What bothers me, is that the process being plugged here doesn't address methods for keeping all of the expressions of the program consistent. Tests are a (limited) alternate expression of the program's functionality that are trivial to compare to the original. Yes, they need to be good. What about documentation (which I define separately from annotated indexing, such as doxygen or Javadoc produce), which is another, separate expression (usually not in an executable language) of the program?
Until these authors address how to keep the entire structure from docs down to code consistent during a refactoring I think they are missing an important point. I've pointed this way before on Slashdot, but the only good way I've found for ensuring that non-executable forms of the program are consistent with executable forms, is formal Software Inspection (see Gilb's stuff at Result Planning ). I've found that the more versions of the code there are (requirements, user docs, code itself, tests etc.) that are kept truly consistent, the more likely it is you will not make mistakes in the final expression (the code you ship).
The refactoring process can be even less "like walking a tightrope without a net"; you're net is a web built out of the relationship between all of these documents, not just the code and tests!
I noticed that they have certain important safety features:
from the web site:The Canadian Arrow is aerodynamically stable throughout the entire flight, and even with loss of active guidance the vehicle would continue on a ballistic trajectory. The first stage carries a range safety device that can be detonated to ensure down range safety.
... I can see it now... "Er, sorry 'boat this, but could wannofya push that red button, eh?"
It is a little less precise, but then again I usually have my window manager set up so that I hardly ever reach for the mouse. The ergonomics consultant at the back shop said that the best solution is to use two mice, a conventional and a vertical, then switch about every half hour or so. You can get a "Y" connector that lets you put two on one port.
About 10 years ago until about 7 years ago their keyboards were made in the U.S.A. or Ireland. I bought two Natural Keyboards in 2000, both made in Taiwan. The crappy keyswitches butchered my hands and the key switches started wearing out within two months so that when you pressed shift or any broad key it would just jam in the "up" position and not go down. That was also a major cause of pain, eventually.
Now, my hands are 26cm (~11in?) thumb-tip to pinky-finger-tip, so the average keyboard and things like my Logitech "ergonomic" mouse were far too small.
So I dropped by an ergonomic equipment specialist in Holland and after trying out a bunch of keyboards I spent the dosh, and got a
Kinesis Ergo Elan
keyboard. For my huge hands it was a good size, and the ultra-light keyswitches and 6 keys under each thumb, all arranged in two bowls, have meant hours of typing without pain. Combine that with a Anir Vertical Mouse and I'm a happy hacker. I made sure work bought be one as well. At home I've got a huge Countour Perfit mouse to fit my hand
As for my fave keyboard. The Union Bank of Switzerland (now UBS AG) used to be the biggest IT shop in the country. They were even developing their own Unix workstation at one point. They manufactured a keyboard for traders with 4 or 5 extra rows of keys over the normal QWERTY layout plus a number pad, with a 4 line LCD display built in. Talk about lots of short-cut buttons...:-)
Re:the real terrorists are governments and media
on
Cyber-Attacks?
·
· Score: 2, Informative
Well put. My browser just made the sound of a nail being hit squarely on the head.
A conference I was to attend got cancelled in the wake of the Sept. 11 attacks. Since I had the plane ticket, I flew anyway and spent the weekend kayaking around Washington D.C.
Being acclimatised to European media, I found the propaganda pouring from my car radio stunning and repulsive. The real dissonance in the whole experience, though, was the refreshingly critical and well informed views of my fellow kayakers (most of whom, contrary to popular image, are healthy, intelligent, independant-minded folks).
My compliments to you and all such Americans who are displaying an ability to think, something you would hardly guess from your media or your government spokesmen.
IIRC (and I don't have a theory text handy) equivalence is decidable for finite memory machines, so therefore for practical examples. NP-completeness I thought, since the only proof would be an exhaustive search of all possible states. I could be wrong there...
As for "measure"... I mean that in the sense that when we "test", we establish a lower bound on how "close" two programs are. If the single test fails then the distance could be said to be 1. If the test passes then the distance is bounded below by 0, but could be higher. Similarly with inspection. If the inspection fails (finds N_m major defects) then the "distance" between the two statements of functionality is bounded from below by N_m. If all measures of program equivalence are zero, then we have not proved equivalence (a very hard problem) but we have shown that the "distance" could be 0.
Again, violent agreement. Why? Testing is basically just writing the code again, only in a more restricted form. You take a known input, and then program the output expected (rather than derive it another way) and then compare the two implementations.
Inspection, on the other hand, compares the program with it written in another form: human language. Since human language is generally too vague to execute automatically, the only way to test the equivalence of the two is to inspect.
Remember, proving two statements are the same is the halting problem, and is NP-complete (i.e. you must check all possible solutions). Testing is a measure of code against code, inspection a measure of code against requirements. Together they kill a lot of bugs because they find different discrepancies between three statements of the same problem.
I'm a little rusty, but here goes... the following is a rough, call it first draft translation of the WebWereld.NL article (c) I suppose on the original site. http://www.webwereld.nl
Courts: Exchange Service KaZaA is Legal
Thurs 28.03.2002 - The music exchange service KaZaA is not responsible for the copyright violations of users of its program.
That was the decision of the Court today in Amsterdam. The Court reversed the decision of Judge R. Oribio de Castro in the matter de Buma/Stemra had raised against KaZaA.
According to de Buma/Stemra KaZaA's program facilitated copyright violation. The software was used primarily for exchanging music without the authors rights being considered.
Oribio De Castro judged therefore that KaZaA had to take measures to stop copyright violation. Failure to do so would result in a heavy fine. The founders of KaZaA then decided to sell the software on the Australian firm Sharman.
A Little Bitter
That seems not to have been necessary. The Amsterdam Court overruled the judgement of Oribio de Castro, deciding that KaZaA was not responsible for the copyright violations perpetrated by its users. "Inasmuch as authors rights are relevant the actions are taken by the users of the software and not by KaZaA".
Christiaan Alberdingk Thijm is very satisfied with the judgement, but was a little bitter about how the whole thing had run its course. Also the CEO Niklas Zennstrom took the judgement "with mixed feelings". "For KaZaA this comes too late. I hope that music organisations [publishers?] like Buma/Stemra will be more amenable to making an agreement rather than just taking it to the courts" according to Zennstrom.
The court clearly distinguished between Napster and KaZaA, according to Alberdingk Thijm "Napster has a central server, which is not the case with KaZaA. Furthermore, fate played to our side in that not just music can be exchanged with KaZaA".
Practical Application
"It remains to be seen what the practical application of this ruling is for KaZaA", said KaZaA in a press release. The exchange service said that the previous judgement forced the shutdown of their world-wide operations, after which they sold their most important business components.
This was recognized by the court: "One may assume that they [KaZaA] would not have taken these measures had they had in their power any other way to obey the [previous] judgement"
This means that Buma forced a judgement to be executed that was not valid, explains Alberdingk Thijm. "In theory, Buma is therefore responsible for the fact that the sale was done at a price much lower than was otherwise the case". It is not yet clear whether steps will be taken against the copyright organisation.
... or removing the device forceably, by what ever means (depending on how brutal the kidnapper is that could be truly brutal) then dropping it down a storm drain to throw off the trail... law enforcement and fire trucks spend hours on a risky rescue of... a Wherifier...
... or throwing it onto a passing freight train going in the other direction...
This device will save nobody and can become a handy tool in the hands of the well informed criminal.
Read John Kenneth Galbraith "The New Industrial State" (1967 ?). The central thesis is that a lot of the economy is based on demand that is generated by companies, rather than met by them.
This, I think, is where the RIAA blew it. Napster generated demand for their product. The internet generated demand for the higher-quality CD-Audio and the physical artifact. In addition, the internet is allowing other artists to generate demand for their products (performances, CD's).
There are, of course, limits to generation of demand, but as long as you can make people feel they need a higher-quality product (and let's face, MP3's sound like you've thrown a wet blanket on your speakers) or some other un-reproducable good (e.g. the concert experience) then the question remains, simply, how to use the existing tools.
The internet, fortunately, puts the same tools in the hands of the artists as the RIAA... so yes, I too think the RIAA is doomed...
Hydrogen combusts with a fuel/air ratio between 5 and 95%, the widest of any hydrocarbon. Methane, if I remember my combustion engineering, was about 8 to 13%. Hydrogen is a wonderful fuel until your first rear-ender, in which you are practically guaranteed to be incinerated if your fuel tank ruptures. Metal tanks that can take an impact are too heavy to truck around, and tanks from carbon-fibre or such stuff are light, but (as the X-33 project found out) relatively brittle.
Scrrreeecchh, whunk... kaboom! Guaranteed every time.
Could cut down on injury insurance claims though...:-)
What is a GUI really but a flexible visual analogue of a keyboard and selector system? These days they even have virtual pop-up sticky notes as little non-graphical reminders of what the tiny picture means in case you're not from the U.S. west coast. Many GUI-bound systems don't have a non-graphical representation, though, making the underlying functions impossible to manipulate non-graphically. GUIs are usually oriented towards a particular style of work and a particular set of expectations; they use a language that usually has to obscure the real operation in favour of a metaphor.
We are visual creatures, a computer is quite definitely not. Fundamentally the command line is closer to the Turing Machine nature of what a computer truly is, and with less abstraction comes more sophistication and potential. As a programmer becomes more expert this becomes extremely useful, since the programmer has grown to truly understand the nature of the machine and abstractions get in the way. The programmer masters the machine itself, not an approximation.
For example, in a current project I need Perl, Java, Ada, C/C++ and Python programs written on NT, Unix and VMS to communicate with a system over sockets, ACMS and various species of CORBA. Visual-Foo++ isn't going to handle the single representation of the workflow that I wrote in language X that gets translated and compiled into the interface for the various legacy components. It probably could be forced to, but why when make, lex and yacc can make quick work of the problem? On the other hand, if my application is of the "fill in a form, save, edit, delete data in a database" type then a GUI-based tool is going to be fine for developing it. Some semi-GUI tools like visual debuggers can produce visual representations of data that often help comprehension, but even these often fail when the going gets genuinely tough.
GUI dev env's will be with us for a long time; my favourite ones are those that disappear when it's time to get hard work done...
I started playing with computers (Commodore PET's, PDP/8's) because it was fun, it appealed to my geek tendencies and I could hang out with other geeks. In the ensuing 20 years I've used 38 languages (grouping together BASIC's) on 11 systems (grouping together Windozes, Unices and 80's micros) and guess what? It's still fun! I still get to hang out with geeks!
Let's not forget that what get's kids fired up is a rewarding experience. They need the sense of having accomplished something, something visible, of getting positive feedback for legitimate effort.
It's probably a good idea to teach a computer language that gets kids solving problems and producing results without having to deal with unnecessary syntactic baggage. Python is would be my choice, just because it has a clean syntax and lots of functionality built in without having to resort to too many libraries (and it is popular where I work (a major Swiss bank)). Ruby is probably also good, but I've not had a reason to try it out yet. Java relies too much on its libraries IMHO for the beginner. Lisp and recursion are probably not the best starting point.
Programming language was 10% of what got me into computers; I survived PET-BASIC, FORTRAN and FOCAL. It sounds like the teacher here is a good one, which is 50% of the battle, and that he's thinking hard about an engaging curriculum, which I think is 30%. 10% is chance, I'd guess...:-) If the kids get an enthusiasm for it, and learn they can accomplish things with computers, they're set.
Slashdot Mirror
Thank you for correcting me, there... I had already posted a big question mark about my original assertion about the newspaper... I suspected I had that wrong shortly after posting it.
Even as a Canadian living there, now back in Canada, I get very patriotic about Switzerland. The country got blind-sided by the ferocity of the American media in 1996-1998, and took an image loss that they didn't deserve.
The balance ends up being less "official state channels" as much as "not overtly commercial channels". "State" channels there tend to be "democratic" channels; not that it's perfect, but it works well because of a high degree of democratic participation. I question, in return, the frightening concept that only candidates with a major fund-raising organisation, capable of mounting a major media assault, are allowed a real voice in North American "democracy".
Limitations on "free speech" are inevitable. They choose to make different ones; ones which support a very lively political culture. (Albeit something of a tempest in a little Alpine teapot at times :-) )
As for WWII: The hard questions were definitely asked; whether CNN found them sensational enough to report on this side of the ocean I don't know. In many cases, they were also asked 40 years ago, and are "old news" to the Swiss. Just as hard questions about nuking opponents, turning away Jewish refugees, and numerous war-crimes perpetrated by Allied forces in Europe, prompted soul searching here. Wars are not fought out of moral obligation.
No country is without their historical blemishes. I'll look at the modern U.S. if you'll look at modern Switzerland. Deal?
For their size, their location in what was, until recently, an occasionally very nasty part of Europe, they have done remarkably well as an example of civil society and democracy.
Modern Switzerland took in more refugees per capita in the late 1990's than any other country in the world. Almost 1 in a 100 living there was a refugee at one point; 3 times more than Germany. This was done with stunning generosity and generated surprisingly little social stress or internal conflict. There are many instances during WWII as well where the generous character of the Swiss (generalising again) was apparent.
Hmmm... actually... I'll have to look up the newspaper rules... parties seemed to be able to publish ads about positions on upcoming referenda...
Sadly, overcoming slavery had as much to do with economics as rights.
My experience in Europe has shown me how a brush with really, really bad government can instill an enthusiasm for good government and constitutional democratic change. Witness Germany, and if my bets are right, watch Croatia.
These solutions can't really be called "European" in the sense of the European Union: Switzerland isn't a member.
The Swiss (if I may generalise horribly) would see leveraging your wealth to get to voters to be a violation of free speech. You are, by merit of money alone, able to drown out others and dominate discussions. I'd be surprised if that same case couldn't be made in the U.S.
As for women and the vote, the earliest referenda on that were held although the Swiss voted in a referendum about giving women the vote as early as 1914 (if I recall correctly), it was simply, democratically, rejected. Discussions started in 1885 on the topic.
Things tend to move a little slowly over there... usually a good thing, I think.
I'm glad this comment has generated some debate!
I don't think we're actually off that much on our opinion. Maybe I expressed the point "I've found that the more versions of the code there are..." a little unfortunately. I agree fully about keeping expressions such that they have a unique point to make, that content has to win over form (as noted in that Agile Modelling site).
I'm just saying that where content is not directly testable, inspection fills that consistency checking gap. But you seem to agree with me there... :-)
Good points, I'm not talking about creating non-executable stuff for the sake of it, just where there is a genuine need for another expression of the system, keep it consistent.
For example, the big-big-boss might say "We need a more efficient and faster transaction handling system." and might not say anything more. That expression of the "system requirements" is in "big-big-boss" language and must be executed by his staff. For a large system that means inevitable intermediate expressions of the code. I think the problem lies in how one keeps them consistent without increasing the workload, i.e. by making that consistency almost automatic.
My comment was intended to imply not that there should be many redundant code expressions, just that where there are any, and they are truly required, keeping them consistent catches a lot of problems.
I've heard your type of objection many times, usually by people who have been burdened by a heavyweight process that isn't delivering savings. It's a shame that poor process has given so many people a nasty taste in their mouth for efforts in that direction; I saw that a lot where I worked. I also saw a project that rejected my advice slip 3 years over on their 2 year schedule, swearing every quarter that they were only 6 months from release.
My team of 2 cracked out a mathematical analysis system with 56K operating lines of low-redundancy analysis code, 40K lines of support code with about 80% of that in support documentation, fully tested, cross referenced etc. in 8 months. It ran 2 years in production and never failed. I credit low-effort design techniques that maintained consistency to being able to do that.
Suddenly, campaigning gets cheap! No more competition by who can afford the most attack ads during the 6pm news slot.
Then again, Swiss democracy is 500 years older than American democracy. I suppose it could take a while for the U.S., and Canada for that matter, to catch up... *sigh*... (I'm Canadian, but lived in Switzerland for 6 years).
What bothers me, is that the process being plugged here doesn't address methods for keeping all of the expressions of the program consistent. Tests are a (limited) alternate expression of the program's functionality that are trivial to compare to the original. Yes, they need to be good. What about documentation (which I define separately from annotated indexing, such as doxygen or Javadoc produce), which is another, separate expression (usually not in an executable language) of the program?
Until these authors address how to keep the entire structure from docs down to code consistent during a refactoring I think they are missing an important point. I've pointed this way before on Slashdot, but the only good way I've found for ensuring that non-executable forms of the program are consistent with executable forms, is formal Software Inspection (see Gilb's stuff at Result Planning ). I've found that the more versions of the code there are (requirements, user docs, code itself, tests etc.) that are kept truly consistent, the more likely it is you will not make mistakes in the final expression (the code you ship).
The refactoring process can be even less "like walking a tightrope without a net"; you're net is a web built out of the relationship between all of these documents, not just the code and tests!
I noticed that they have certain important safety features:
from the web site: The Canadian Arrow is aerodynamically stable throughout the entire flight, and even with loss of active guidance the vehicle would continue on a ballistic trajectory. The first stage carries a range safety device that can be detonated to ensure down range safety.It is a little less precise, but then again I usually have my window manager set up so that I hardly ever reach for the mouse. The ergonomics consultant at the back shop said that the best solution is to use two mice, a conventional and a vertical, then switch about every half hour or so. You can get a "Y" connector that lets you put two on one port.
About 10 years ago until about 7 years ago their keyboards were made in the U.S.A. or Ireland. I bought two Natural Keyboards in 2000, both made in Taiwan. The crappy keyswitches butchered my hands and the key switches started wearing out within two months so that when you pressed shift or any broad key it would just jam in the "up" position and not go down. That was also a major cause of pain, eventually.
Now, my hands are 26cm (~11in?) thumb-tip to pinky-finger-tip, so the average keyboard and things like my Logitech "ergonomic" mouse were far too small.
So I dropped by an ergonomic equipment specialist in Holland and after trying out a bunch of keyboards I spent the dosh, and got a Kinesis Ergo Elan keyboard. For my huge hands it was a good size, and the ultra-light keyswitches and 6 keys under each thumb, all arranged in two bowls, have meant hours of typing without pain. Combine that with a Anir Vertical Mouse and I'm a happy hacker. I made sure work bought be one as well. At home I've got a huge Countour Perfit mouse to fit my hand
As for my fave keyboard. The Union Bank of Switzerland (now UBS AG) used to be the biggest IT shop in the country. They were even developing their own Unix workstation at one point. They manufactured a keyboard for traders with 4 or 5 extra rows of keys over the normal QWERTY layout plus a number pad, with a 4 line LCD display built in. Talk about lots of short-cut buttons... :-)
Well put. My browser just made the sound of a nail being hit squarely on the head.
A conference I was to attend got cancelled in the wake of the Sept. 11 attacks. Since I had the plane ticket, I flew anyway and spent the weekend kayaking around Washington D.C.
Being acclimatised to European media, I found the propaganda pouring from my car radio stunning and repulsive. The real dissonance in the whole experience, though, was the refreshingly critical and well informed views of my fellow kayakers (most of whom, contrary to popular image, are healthy, intelligent, independant-minded folks).
My compliments to you and all such Americans who are displaying an ability to think, something you would hardly guess from your media or your government spokesmen.
Um, good points in the replies.
IIRC (and I don't have a theory text handy) equivalence is decidable for finite memory machines, so therefore for practical examples. NP-completeness I thought, since the only proof would be an exhaustive search of all possible states. I could be wrong there...
As for "measure"... I mean that in the sense that when we "test", we establish a lower bound on how "close" two programs are. If the single test fails then the distance could be said to be 1. If the test passes then the distance is bounded below by 0, but could be higher. Similarly with inspection. If the inspection fails (finds N_m major defects) then the "distance" between the two statements of functionality is bounded from below by N_m. If all measures of program equivalence are zero, then we have not proved equivalence (a very hard problem) but we have shown that the "distance" could be 0.Again, violent agreement. Why? Testing is basically just writing the code again, only in a more restricted form. You take a known input, and then program the output expected (rather than derive it another way) and then compare the two implementations.
Inspection, on the other hand, compares the program with it written in another form: human language. Since human language is generally too vague to execute automatically, the only way to test the equivalence of the two is to inspect.
By far the best inspection book is Software Inspection by Tom Gilb. His very generous web site contains a ton of supplementary material.
Remember, proving two statements are the same is the halting problem, and is NP-complete (i.e. you must check all possible solutions). Testing is a measure of code against code, inspection a measure of code against requirements. Together they kill a lot of bugs because they find different discrepancies between three statements of the same problem.
really a recycled Tandy 100 ...
Have a poke around in a country-side antiques place in the North American mid-west or somewhere similarly, um, oblivious to such concerns.
It's usually called "Depression Glass" since a lot of it was made in the 1930's.
I had a piece for the longest time and it really is a pretty yellow colour. Not particularly radioactive either...
I'm a little rusty, but here goes... the following is a rough, call it first draft translation of the WebWereld.NL article (c) I suppose on the original site. http://www.webwereld.nl
Courts: Exchange Service KaZaA is Legal
Thurs 28.03.2002 - The music exchange service KaZaA is not responsible for the copyright violations of users of its program.
That was the decision of the Court today in Amsterdam. The Court reversed the decision of Judge R. Oribio de Castro in the matter de Buma/Stemra had raised against KaZaA.
According to de Buma/Stemra KaZaA's program facilitated copyright violation. The software was used primarily for exchanging music without the authors rights being considered.
Oribio De Castro judged therefore that KaZaA had to take measures to stop copyright violation. Failure to do so would result in a heavy fine. The founders of KaZaA then decided to sell the software on the Australian firm Sharman.
A Little Bitter
That seems not to have been necessary. The Amsterdam Court overruled the judgement of Oribio de Castro, deciding that KaZaA was not responsible for the copyright violations perpetrated by its users. "Inasmuch as authors rights are relevant the actions are taken by the users of the software and not by KaZaA".
Christiaan Alberdingk Thijm is very satisfied with the judgement, but was a little bitter about how the whole thing had run its course. Also the CEO Niklas Zennstrom took the judgement "with mixed feelings". "For KaZaA this comes too late. I hope that music organisations [publishers?] like Buma/Stemra will be more amenable to making an agreement rather than just taking it to the courts" according to Zennstrom.
The court clearly distinguished between Napster and KaZaA, according to Alberdingk Thijm "Napster has a central server, which is not the case with KaZaA. Furthermore, fate played to our side in that not just music can be exchanged with KaZaA".
Practical Application
"It remains to be seen what the practical application of this ruling is for KaZaA", said KaZaA in a press release. The exchange service said that the previous judgement forced the shutdown of their world-wide operations, after which they sold their most important business components.
This was recognized by the court: "One may assume that they [KaZaA] would not have taken these measures had they had in their power any other way to obey the [previous] judgement"
This means that Buma forced a judgement to be executed that was not valid, explains Alberdingk Thijm. "In theory, Buma is therefore responsible for the fact that the sale was done at a price much lower than was otherwise the case". It is not yet clear whether steps will be taken against the copyright organisation.
Buma/Stemra could not be reached for comment.
... or removing the device forceably, by what ever means (depending on how brutal the kidnapper is that could be truly brutal) then dropping it down a storm drain to throw off the trail ... law enforcement and fire trucks spend hours on a risky rescue of ... a Wherifier ...
...
... well done ...
... or throwing it onto a passing freight train going in the other direction
This device will save nobody and can become a handy tool in the hands of the well informed criminal.
Well done
Is it just me or is the guy using the keyboard on the car dashboard driving in the middle of the road, right over double yellow lines?
The message there is pretty clear... :-)
Read John Kenneth Galbraith "The New Industrial State" (1967 ?). The central thesis is that a lot of the economy is based on demand that is generated by companies, rather than met by them.
This, I think, is where the RIAA blew it. Napster generated demand for their product. The internet generated demand for the higher-quality CD-Audio and the physical artifact. In addition, the internet is allowing other artists to generate demand for their products (performances, CD's).
There are, of course, limits to generation of demand, but as long as you can make people feel they need a higher-quality product (and let's face, MP3's sound like you've thrown a wet blanket on your speakers) or some other un-reproducable good (e.g. the concert experience) then the question remains, simply, how to use the existing tools.
The internet, fortunately, puts the same tools in the hands of the artists as the RIAA... so yes, I too think the RIAA is doomed...
Hydrogen combusts with a fuel/air ratio between 5 and 95%, the widest of any hydrocarbon. Methane, if I remember my combustion engineering, was about 8 to 13%. Hydrogen is a wonderful fuel until your first rear-ender, in which you are practically guaranteed to be incinerated if your fuel tank ruptures. Metal tanks that can take an impact are too heavy to truck around, and tanks from carbon-fibre or such stuff are light, but (as the X-33 project found out) relatively brittle.
Scrrreeecchh, whunk ... kaboom! Guaranteed every time.
Could cut down on injury insurance claims though... :-)
Maybe we could used gelled hydrogen.
The Hindenburg BTW was actually supposed to be filled with Helium, but the U.S. wouldn't sell the gas to Germany at the time (for obvious reasons)...
What is a GUI really but a flexible visual analogue of a keyboard and selector system? These days they even have virtual pop-up sticky notes as little non-graphical reminders of what the tiny picture means in case you're not from the U.S. west coast. Many GUI-bound systems don't have a non-graphical representation, though, making the underlying functions impossible to manipulate non-graphically. GUIs are usually oriented towards a particular style of work and a particular set of expectations; they use a language that usually has to obscure the real operation in favour of a metaphor.
We are visual creatures, a computer is quite definitely not. Fundamentally the command line is closer to the Turing Machine nature of what a computer truly is, and with less abstraction comes more sophistication and potential. As a programmer becomes more expert this becomes extremely useful, since the programmer has grown to truly understand the nature of the machine and abstractions get in the way. The programmer masters the machine itself, not an approximation.
For example, in a current project I need Perl, Java, Ada, C/C++ and Python programs written on NT, Unix and VMS to communicate with a system over sockets, ACMS and various species of CORBA. Visual-Foo++ isn't going to handle the single representation of the workflow that I wrote in language X that gets translated and compiled into the interface for the various legacy components. It probably could be forced to, but why when make, lex and yacc can make quick work of the problem? On the other hand, if my application is of the "fill in a form, save, edit, delete data in a database" type then a GUI-based tool is going to be fine for developing it. Some semi-GUI tools like visual debuggers can produce visual representations of data that often help comprehension, but even these often fail when the going gets genuinely tough.
GUI dev env's will be with us for a long time; my favourite ones are those that disappear when it's time to get hard work done...
I started playing with computers (Commodore PET's, PDP/8's) because it was fun, it appealed to my geek tendencies and I could hang out with other geeks. In the ensuing 20 years I've used 38 languages (grouping together BASIC's) on 11 systems (grouping together Windozes, Unices and 80's micros) and guess what? It's still fun! I still get to hang out with geeks!
Let's not forget that what get's kids fired up is a rewarding experience. They need the sense of having accomplished something, something visible, of getting positive feedback for legitimate effort.
It's probably a good idea to teach a computer language that gets kids solving problems and producing results without having to deal with unnecessary syntactic baggage. Python is would be my choice, just because it has a clean syntax and lots of functionality built in without having to resort to too many libraries (and it is popular where I work (a major Swiss bank)). Ruby is probably also good, but I've not had a reason to try it out yet. Java relies too much on its libraries IMHO for the beginner. Lisp and recursion are probably not the best starting point.
Programming language was 10% of what got me into computers; I survived PET-BASIC, FORTRAN and FOCAL. It sounds like the teacher here is a good one, which is 50% of the battle, and that he's thinking hard about an engaging curriculum, which I think is 30%. 10% is chance, I'd guess... :-) If the kids get an enthusiasm for it, and learn they can accomplish things with computers, they're set.