I have a rabid hatred of XML. It's just such a hideously ugly language that I could never stand to use it.
Then you really should study it more closely.
Yes, indeed, XML is an extraordinarily complex syntax for writing what are essentially SEXPRs; however, it's a single, common, generic, internationally and openly agreed syntax, for writing files which are both human readable and machine parseable.
If you are going to start again from scratch and define new syntax for UN*X configuration files, and you choose to use anything other than XML, you really are going to need to have a very good reason for doing so.
And remember, if you really find XML syntax so ugly, it's trivial to convert XML SEXPR syntax into LISP SEXPR syntax and back again.
Better stop ranting now... I am going back to my POS 98 laptop, fondly remembering the days when a reliable, pretty, configurable Unix still existed: it was called NeXTStep:-(...
Oh no, oh no, oh no, oh no... I hated NeXTStep with a passion, and the reason I hated it was that fscking lusers would use those pretty graphical administration tools to get themselves into configuration messes that those same tools couldn't get them out of. And you'd be called in to find a totally crashed machine that wouldn't boot, and the luser twittering on about how he 'just did this'. So after considerable mucking with the bootloader you finally get the thing up into run-level one, where you don't have any access to the pretty graphical user interface and - whoopee! you can't fix any bloody thing because the config files are not ascii text anymore, they're some horrible undocumented binary format.
No. Not NeXTStep. Not anything like NeXTStep. And may Steve Jobs have his fingernails and toenails pulled out slowly one by one over a hot fire for even thinking of it.
There's two things here. Firstly most people are not competent to configure a computer, don't have time to learn to be competent, and don't want to learn to be competent. It isn't their job and they shouldn't have to do it, and most important of all they shouldn't be provided with tools which make it look as if it's easy. It just inherently isn't easy.
Second of all, configuration files should remain simple ascii files which can be manipulated by a competent person even on a totally crashed machine. If you must write pretty graphical front ends, make sure that they keep their config in plain text files, and make sure they can still parse those files even after they have been human edited (provided the human is competent enough to follow the syntax rules, of course).
Efficiency isn't exactly exciting. Unless I am using a Palm Pilot, I really don't care if my PentiumIII or Alpha is sucking 34W and my Nvidia GeForce is sucking another 30. What I care about is how fast my performance is. How many transactions can I run? How many frames per second am I getting? How many polygons can I push?
You really, really still don't get it, do you? Firstly, Crusoe is the first chip Transmeta has got out the door. It's the simplest possible silicon, with the hard bits done in software. But there's no hard line between what functions can be done in hardware and what can be done in software. It's just that software is cheaper to tune.
When Transmeta have got code-mophing tuned the way they like it there is nothing to stop them releasing a new chip with the code-morphing engine in hardware.
But even if they don't, the limitation on performance computing design is cooling, as Cray amply showed. Crusoe consumes 1/32 the power of your PIII; so, for a given cooling system, you can stick 32 Crusoes in the same box. If each Crusoe gives you 66% of the compute power of the PIII, you've got a box which is going to deliver you more than 21 times the number of polygons your PIII can push.
One thing I haven't yet seen quoted is the part-price for a Crusoe, but if the silicon is as simple as people are suggesting the part-price could be very low - small dies have relatively lower reject rates because if you have one flaw per square inch, every inch square chip has a flaw whereas only one in ten 0.3 inch chips does.
By contrast your PIII is inherently an expensive part - it isn't expensive because Intel are profiteering, it's actually expensive to make. If Transmeta start shipping Crusoes at (say) around $10 per part in quantity, there isn't any way Intel can compete anywhere along the line.
I currently run two PII/300s in my desktop box. I bought them because two 300MHz parts and a motherboard to accomodate them were, at the time I bought them, a lot cheaper than one 500MHz part. If I can get, say, 8 400MHz Crusoes for the price of one 700 MHz Intel part, I will be quite happy to run them, and so I expect will a lot of other people.
Assuming, of course, that Linux 2.4 will run 8-way parallel on Crusoes, but I'm kind of prepared to bet it will:-)
Alternatively, the Lisp Machine people might find it a slick idea if Transmeta provided microcode to provide a Lisp-oriented instruction set that (notably) provides a really tightly microcoded set of garbage collector instructions.
ohshit.iwantit iwantitnow.
What killed those beautiful things like the Ivory is that they were made in such small numbers that they were fiercely expensive... This makes not just modern LispMs but also all sorts of other special purpose processing possible. Xerox were working on a really cool processor design in the mid-eighties which did selector-method resolution for object oriented languages as a single (very CISC) machine instruction. If it's possible to write your own instruction sets for this beastie, that could become a realistic possiblity.
Ten years plus ago, I had a lot of machines out with customers with Western Digital drives in. I think every last one of those drives ate itself for breakfast within a year, and I had some very unhappy customers. I haven't used Western Digital since; they may have got better.
Recently a friend's company had a spate of Samsung drives go down, most less than a month old.
These days I consciously choose better quality disks because the extra cost is considerably less than the cost of a lost customer, or even having to go out and swap a disk in a hurry. Disks are about the only critical mechanical parts left in a modern computer (except bl**dy chip-fans), and are among the things most likely to die. Buying cheap ones is (in my opinion) a very poor economy.
The story isn't quite as you beleive. Check out http://www.mackido.com/Interface/ui_history.html and see what you think.
Well speaking as someone who actually used Xerox Stars, Dandelions and Daybreaks, the article you cite is completely untrue. Like modern X window managers, the Xerox desktops were very configurable, and a very large number of different looks-and-feels were being experimeted with. There were window managers with mass and gravity, for heaven's sake - if you moved a window it kept on moving until something stopped it, or it went into orbit around a larger window.
There were also a number of different mice, although I can't remember a one button one. I've still got a Xerox two button mechanical mouse dating from about 1980, and three button optical mice were used on all the InterLISP machines. People used to joke about five button mice, which apparently did exist. I never saw or heard of a 'chording keyboard', but there were a lot of creative things going on and I'm prepared to believe that such a thing existed. The keyboards I used, though, were conventional, if chunky and solid.
But, to be absolutely clear, most of the features of the Lisa interface were available on the Xerox machines Jobs saw. The original Macintosh interface, which came later, was somewhat different. And while I don't know the truth behind the story of Jobs giving Xerox stock, I do know that a number of people at PARC felt pretty abused at the time.
Too many people, as my father was fond of observing, know too many things which are not so.
RFC 1035 paragraph 2.3:
The domain system has several conventions dealing with low-level, but fundamental, issues. While the implementor is free to violate these conventions WITHIN HIS OWN SYSTEM, he must observe these conventions in ALL behavior observed from other hosts.
OK, maybe I am a bit extreme on this; but what I do is write code generators, which generate HTML, XML and related languages. Consequently I've possibly given the matter more thought than most people.
HTML is a language with which servers talk to clients. The server doesn't know what the client is, and doesn't know what capabilities the client has. Some clients are graphical browsers, and some aren't; of those, some have Netscape's special bugs and obscurities, and some don't.
Correctly written, standards-compliant HTML will work with every standards compliant client, whether it's a graphical browser, a blind person's speaking browser, a mobile phone, or a digester.
Slashdot won't.
As a community, Linux users suffer considerably from badly written Web pages which 'work' in Microsoft IE4; on our screens these pages often have unreadble fonts, and unreadable point sizes. Unless people who create Web sites care about standards, and care about quality workmanship, we are continuing to fragment the Web into increasingly separate, increasingly non-interoperable ghettoes. We claim to be the masters of technology, not it's slave: we of all people should know how to get it right.
If you care about the quality of the work you do, you should care about things like that.
Re:uncle? what has he got to do with that?
on
Linux Kernel 2.2.14
·
· Score: 1
Pardonez moi, ma petit choux de Pays-Bas, but tout le monde et sa tante a dit ca en la France pendant touts les annis.
[Or something. I don't really speak French].
Off topic (see thread): AWT and Swing
on
The ROX Desktop
·
· Score: 1
OK, well, the thing is this.
Run an AWT app on a Macintosh platform and it will look and feel reasonably Mac-ish. Run it on a Linux platform with the standard AWT bindings for Linux and exactly the same binary will look and feel reasonably Motif-ish. Run it on a WinXX PC and it will look as if it came from Redmond. And the reason this is so is that it isn't carrying around any personal baggage, it uses the real window toolkit of the environment it finds itself in. Consequently, if somebody invented a significantly different user-interface metaphor, and wrote AWT bindings for it, every AWT app would, if loaded in that environment, immediately look and feel (reasonably) native in that environment.
It would be entirely feasible to build a RISC OS like (or a KDE) binding for AWT and immediately all existing AWT applications would work in it.
This ain't possible with Swing, because Swing provides a look and feel (this is also why Swing is so huge and bloated).
In my opinion it would have been better to persevere with AWT...
Why would the code need to be cleaned up? It looks good in lynx and netscape, which is surely a good enough practical acid test
<rant quality="weary">
Is there really any other industry on earth that would put up with sloppy, incompetent, unprofessional workmanship just because it looked good on the surface? I mean, come off it. I like/., but I can quite see why these guys don't want to release their engine. If my engine was producing output as bad as this I wouldn't release it either.
And it isn't any sort of excuse to claim that the majority of websites (particularly expensive ones) are also produced by sloppy incompetents who wouldn't know what an RFC was if it fell out of a tree on them. This is true. We know it. We can do better. And if we can't do better, what claim do we really have to being techs?
OK, I loved RISC OS; and I wrote some of my best software ever on that platform. It had many wins. Yes, the drag-and-drop was really well done and really clean, but there were lots of other things that were really clean. The menuing system was a particular one. Look at any Windows / Mac / Motif / KDE / Gnome application, and you see a great squodge of real estate permanently wasted - the menu bar. RISC OS applications have no menu bar. Instead, the menu always pops up when you hit the middle mouse button - and, of course, it's always context-sensitive.
The other thing that RISC OS did - well - differently was file typing. Files were typed with (effectively) an unsigned short in the directory structure. This is sort of a kludge; it meant there was a finite number of file types, and by the early nineties they were already in short supply. I remember we asked Acorn for a block of sixteen, and, after intense negotiation, were actually awarded eight.
But it had the advantage that when a file icon was dragged to your application, you got a request which said, effectively, here's one of these files, and it's this size, how do you want to handle it?. This saves an awful lot of messing about... The other nice thingb was that when the user selected a file and didn't drag it to a particular icon, the file was offered to the existing running copy of the application it was registered to, rather than starting a new copy. And if a file registered to your application was dragged to the printer, your application got alerted to decide how to render it on an abstract output stream, which the printer driver then translated to the particular printer actually in use.
People elsewhere in this discussion have criticised RISC OS's collaborative multi-tasking. Yes, if your application failed to make it's next wimp_poll() call in due time for whatever reason the whole desktop locked up - so it was vital that you caught and handled all your own errors. But the upside was responsiveness. Yes, the ARM was faster than any other microprocessor available at the time by a good margin, but that didn't really account for the whole improvement in responsiveness that users percieved. Another big part of that responsiveness was due to the very low system overhead.
However, nostalgia over. What can we learn from this and take forward? Well, one of the things we can learn is that RISC OS died in the marketplace (I know: my company was trying hard to sell it into big industry). Part of the reason it died was that it was different. People didn't take time to look past the difference to see that it was actually better. Part of the reason it died was lack of applications (although by 92 this was ceasing to be a real issue - most of the things people really needed were there, and most of them were very good). Part of the reason was that too few people will pay even a little more for a genuinely superior product. Part of the reason was single-vendor - 'what do we do if they go bust'. A lot of the reason was the old unfair reasons of the computer industry: FUD, whispers, lies, dishonest marketing.
There are a lot of lessons out of RISC OS for the Linux community. And at some stage I think a desktop based on RISC OS-like drag-and-drop will win out over all the different cruddy file dialogs and stuff. But if I was designing a desktop application now would I write for this desktop? Well, I wouldn't, because a desktop needs critical mass. This is a chicken and egg situation... what we really need to be doing in application design is separating out the functionality into layers with well abstracted boundaries between them, so that if I wanted to put a ROX-compliant shell around, say, Mozilla or the GIMP it would be reasonably straightforward to do. Because whether ROX is it or not, some day there really is going to be a really creative new user interface metaphor which comes along and sweeps away the Windows-style GUI we're all currently using. It will come quicker if it's easier to experiment with new metaphors; and when it comes we'll all want to get our favourite applications working on it as soon as possible.
Off topic, this is why I like the Abstract Window Toolkit so much, and think Swing is, in effect, a retrograde step.
Linux as it exists at this moment is an operating system developed by technologists for technologists, and by and large we're happy with it which is why we're using it. I have (and have paid for) a number of commercial applications for Linux, and one excellent commercial game - CivCTP; and I'm glad they are emerging because they are useful. But there are a number a number of reasons why I'm glad Linux isn't a mainstream OS and hope it won't become a mainstream OS.
We're motivated to develop Linux the way it is because it works for us, it provides us with what we need. In ESR's terms, we've been scratching our own itches. The masses who need all this luser-molly-coddling aren't competent to develop and maintain an OS; they need other people to do it for them. I don't see who has the motivation to do that except for money. So it seems to me entirely appropriate that the commerical OS businesses - Apple, Be, Microsoft - should use the commercial model to develop software for the people who cannot develop it for themselves. They have a motivation which we don't.
Next, and more importantly, it isn't at all clear to me that you can add all these luser-molly-coddling features as gloss, as a thin shell on the top. It seems to me that at least some of them must percolate quite deeply into the system. If this is the case we may find that by converting Linux into a system which lusers can use we may have converted it into a system which we find significantly less useful and less comfortable.
There is a myth that one size fits all. It doesn't. This is why, for example, Apple still exists: because it offers an OS which is significantly and usefully different from the mainstream to offer real benefits to a significant community of users. Similarly, Linux as it currently is provides significant benefits for a significant community of users - and that community is us.
I'm with you. It's pretty clear that, whatever you think of trademarking the name 'Leonardo', the arts foundation got there first. While I was at University in Lancaster, the International Committee of the Red Cross was having a campaign to stop other organisations using the name 'red cross' and served a 'cease and desist' notice on the Red Cross Inn in Lancaster. The inkeeper turned round and pointed out that the Red Cross Inn (founded, like most other pubs of the same name, by a returning crusader) had been trading under that name for more than seven hundred and fifty years, and politely asked how long they'd been using it. The ICRC retired hurt.
I don't think Leonardo Finance are in a good legal position here, under any country's laws (although I confess I'm no expert on France). What's more interesting is what the Gendarmerie were up to. If you tried that sort of thing on a Scottish policeman he'd say 'civil matter, none of my business' and send you on your way.
If you go to the Xerox Parc map server you'll see there's a squigly bit to the left with a top blob and a bottom blob. The United States of America is in the top blob. It's not the whole of the top blob, but it's in there somewhere.
Now, if you look in the middle sort of three-quarters of the way up you'll find another funny shaped bit that's called 'Europe'. In Europe there's a country called 'France'. Now the bit that you may not have noticed is this: it isn't part of the United States of America. Furthermore, the people there fart in the general direction of your Supreme Court. They think that your president is a hamster and that your senate smells of elderberies. In short, they're FRENCH.
Now the point about this story is it happens in France. The people there are French. The goodies in this story are French. The baddies are French. Even the bold Gendarmes are French.
Messing about with American tort law, or sending American execs who break American laws to American prisons, is going to worry them not one little bit.
If the US patent office continues to hand out patents for trivial, obvious or non-original 'inventions', the US will have to face sooner or later a situation in which the Europeans and the Japanese cease to honour any US patents at all. We can't go on for ever offering reciprocal rights to a patent office which is neither competent nor responsible.
In a recent letter to my Member of Parliament I listed ten US software patents covering techniques my company (and hundreds of others around the world) had been using before the patent was filed (yes, the Amazon one was among them). This situation just cannot continue. Either you have to get your patent office to behave sensibly or you will have to face a situation where you effectively cannot export.
This is a field where Linux could be leading the pack, but is instead an example where I think we are lagging behind. (I hope someone can point me to a group that is bringing XML deep into the linux os)
Not so, fortunately. A certain very large telco (which I'm not yet allowed to name) is now running its Intranet directory on an XML/XSL application which I've written. The application was developed on Linux and is currently running on Linux, although the customer intends to move it to Solaris.
My XML intro course is online; it's a little out of date at the moment but will be updated over the next few months.
XML and particularly RDF do have a lot to offer for search engines - see my other note further up this thread.
Is it even possible to index dynamic pages? They don't really exist until the page is generated.
Yes, for a very large category of dynamic pages, it is. For example, in an online shop, the actual number of a particular product in stock at the moment may very from minute to minute, the price of that product in the user's preferred currency may change from week to week, but the product itself doesn't change much over months over months or years. It makes perfect sense to index the product page, because although some of the contained data may be transient, a great deal more is not.
Or take another example: the weather forecast for a particular area. The forecast itself may change regularly, but the page always contains a current forecast and that fact is worth indexing. The best technology available for this sort of thing is probably RDF and the Dublin Core metadata specification. Of course, the search engines still have to be persuaded to take heed of this...
It doesn't really prevent booting. By their statements it merely requires the power be pushed again. In most cases not that difficult. Really it isn't.
Oh yes, and I do that when I'm asleep in my bed half a mile away exactly how? The one thing a server has to do is reboot cleanly, and as an absolute minimum reliably come back up to a state in which it can be remotely administered. If it can't you keep it on your network - I surely don't want it on mine!
This could kill small co and open-source software
on
New Patent Treaty
·
· Score: 2
The most pernicious thing about this sort of idiocy is what it potentially does to the likes of us. Big companies can afford to take out speculative patents on any computing technique which looks in the least promising. The fact that these patents would be struck down as prior art if challenged is irrelevent to them because they know that small companies and individuals cannot afford to mount challenges.
This really is one for your political representative. If this gets to stand, all open source software (and all small software companies) are dead.
It may sound ridiculously self important, but these are revolutionary times and what we are all doing is revolutionary. Obviously, what some people are doing is more revolutionary than others, and what the Open Source advocates are doing is - obviously - revolutionary.
But just because it's the most obviously revolutionary thing happening doesn't make it the most revolutionary. What CmdrTaco and the boys are doing is pretty revolutionary too - to take another of today's stories, for example, it's the Slashdot effect which surges huge flows of traffic around the Web. It isn't the Times effect, the CNN effect or the BBC effect, and it isn't because these bodies, skilled and resourced at newsgathering as they are, have not managed to exploit this new medium in the way that Slashdot has.
What I'm suggesting is that Slashdot may be to Berners-Lee as The Times was to Caxton, or CNN has been to Logie Baird: the body which has most effectively discovered the formula to harness the new technology to journalism, and which will in the long run influence the way in which journalism on the medium is presented.
Of course I may be wrong here; I may be simply absurdly overestimating Slashdot's importance. But at the same time I can't help betting that there are executives in half the media coroprations in the world lying awake at night wondering how they let Andover get away with such a bargain, and executives at Andover lying awake at nights wondering what to do with it.
We all (I assume) believe this medium is powerful, and yet we're all continually being surprised by how powerful it is. And so, from time to time, we get surprised when stories like this blow up out of nowhere. This is another sort of Slashdot effect, a consequence of using a powerful technology when you don't have enough experience with it to know instinctively the potential consequences of your actions.
What I liked about this story is that it is Slashdot introspecting about Slashdot. Introspection is something which, as Eric Raymond has often pointed out, we in the open source movement don't do enough of. When what you're doing is revolutionary, when the waters which you are navigating are uncharted, if you don't think carefully about what you're doing you are likely to do much less well than you otherwise might.
So Rob (and everyone else who has contributed), don't be upset by accusations of self indulgence. Sometimes looking at what we're doing, trying to understand what we're doing, and, most importantly, trying to understand the consequences of what we're doing, are as important as doing it.
Well, one of the most powerful examples of a group embracing an epithet which was originally used as an insult is the Quakers. And yes, it is a powerful thing to do. I have no difficulty whatsoever in describing myself as a geek. I am a geek; I'm a good geek, and I'm proud of it.
I live comfortably and happily with a fellow geek of the opposite gender whom I met on Usenet. We've been living together two years now - she's reading news on the machine next to mine as I type.
There's a lot to be said for living with another geek - she keeps the same sort of hours as I do, has the same tolearnce for mess as I do, and wants to go out and socialise as often as I do. Furthermore, she can do tricks with SQL that leave me gasping in awe, so my code has improved in places...
Oh, and she's seriously cute as well.
Yes: live in Techno Talking Babe very much recommended.
If it's a big database intensive project, performance could easily be the bottleneck.
Speaking as one who writes a lot of database intensive Web interfaced systems, the technology you use to bridge between the database and the Web still doesn't have a very big hit on performance. As I've said above my testing shows that compiled C performs best (of the technologies I've tested) for CGIs, and by a substantial margin.
However, I personally prefer to use Java Servlets, for reasons of code reusability, portability, and most importantly, code readability. And the reason that I feel that the (relatively) poor performance of servlets doesn't matter very much is that the real performance hit is in the database engine. The largest proportion of the time responding to any given response is the database engine doing it's stuff.
Using servlets I save time on starting the servlets (because they're permanently loaded) and setting up database connections (because they're permanently open in a pool, and it's only if there aren't enough in the pool I need to create another), and this saves more performance than the minor relative inefficiency of the JVM costs. Of course you could achieve similar benefits with mod_perl, but in my opinion Java still scores for code readability.
Slashdot Mirror
Then you really should study it more closely.
Yes, indeed, XML is an extraordinarily complex syntax for writing what are essentially SEXPRs; however, it's a single, common, generic, internationally and openly agreed syntax, for writing files which are both human readable and machine parseable.
If you are going to start again from scratch and define new syntax for UN*X configuration files, and you choose to use anything other than XML, you really are going to need to have a very good reason for doing so.
And remember, if you really find XML syntax so ugly, it's trivial to convert XML SEXPR syntax into LISP SEXPR syntax and back again.
You really, really still don't get it, do you? Firstly, Crusoe is the first chip Transmeta has got out the door. It's the simplest possible silicon, with the hard bits done in software. But there's no hard line between what functions can be done in hardware and what can be done in software. It's just that software is cheaper to tune.
When Transmeta have got code-mophing tuned the way they like it there is nothing to stop them releasing a new chip with the code-morphing engine in hardware.
But even if they don't, the limitation on performance computing design is cooling, as Cray amply showed. Crusoe consumes 1/32 the power of your PIII; so, for a given cooling system, you can stick 32 Crusoes in the same box. If each Crusoe gives you 66% of the compute power of the PIII, you've got a box which is going to deliver you more than 21 times the number of polygons your PIII can push.
One thing I haven't yet seen quoted is the part-price for a Crusoe, but if the silicon is as simple as people are suggesting the part-price could be very low - small dies have relatively lower reject rates because if you have one flaw per square inch, every inch square chip has a flaw whereas only one in ten 0.3 inch chips does.
By contrast your PIII is inherently an expensive part - it isn't expensive because Intel are profiteering, it's actually expensive to make. If Transmeta start shipping Crusoes at (say) around $10 per part in quantity, there isn't any way Intel can compete anywhere along the line.
I currently run two PII/300s in my desktop box. I bought them because two 300MHz parts and a motherboard to accomodate them were, at the time I bought them, a lot cheaper than one 500MHz part. If I can get, say, 8 400MHz Crusoes for the price of one 700 MHz Intel part, I will be quite happy to run them, and so I expect will a lot of other people.
Assuming, of course, that Linux 2.4 will run 8-way parallel on Crusoes, but I'm kind of prepared to bet it will :-)
Ten years plus ago, I had a lot of machines out with customers with Western Digital drives in. I think every last one of those drives ate itself for breakfast within a year, and I had some very unhappy customers. I haven't used Western Digital since; they may have got better.
Recently a friend's company had a spate of Samsung drives go down, most less than a month old.
These days I consciously choose better quality disks because the extra cost is considerably less than the cost of a lost customer, or even having to go out and swap a disk in a hurry. Disks are about the only critical mechanical parts left in a modern computer (except bl**dy chip-fans), and are among the things most likely to die. Buying cheap ones is (in my opinion) a very poor economy.
Well speaking as someone who actually used Xerox Stars, Dandelions and Daybreaks, the article you cite is completely untrue. Like modern X window managers, the Xerox desktops were very configurable, and a very large number of different looks-and-feels were being experimeted with. There were window managers with mass and gravity, for heaven's sake - if you moved a window it kept on moving until something stopped it, or it went into orbit around a larger window.
There were also a number of different mice, although I can't remember a one button one. I've still got a Xerox two button mechanical mouse dating from about 1980, and three button optical mice were used on all the InterLISP machines. People used to joke about five button mice, which apparently did exist. I never saw or heard of a 'chording keyboard', but there were a lot of creative things going on and I'm prepared to believe that such a thing existed. The keyboards I used, though, were conventional, if chunky and solid.
But, to be absolutely clear, most of the features of the Lisa interface were available on the Xerox machines Jobs saw. The original Macintosh interface, which came later, was somewhat different. And while I don't know the truth behind the story of Jobs giving Xerox stock, I do know that a number of people at PARC felt pretty abused at the time.
RFC 1035 paragraph 2.3:
RFC 1035, paragraph 2.3.1:
<domain> ::= <subdomain> | " "
<subdomain> ::= <label> | <subdomain> "." <label>
<label> ::= <letter> [ [ <ldh-str> ] <let-dig> ]
<ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str>
<let-dig-hyp> ::= <let-dig> | "-"
So, in summary:
--
Simon, muttering fierce things about 'he who knows not...'
For the anally retentive, like myself, who can't help checking these things out, the document you need is RFC 1035 paragraph 2.3.1.
OK, maybe I am a bit extreme on this; but what I do is write code generators, which generate HTML, XML and related languages. Consequently I've possibly given the matter more thought than most people.
HTML is a language with which servers talk to clients. The server doesn't know what the client is, and doesn't know what capabilities the client has. Some clients are graphical browsers, and some aren't; of those, some have Netscape's special bugs and obscurities, and some don't.
Correctly written, standards-compliant HTML will work with every standards compliant client, whether it's a graphical browser, a blind person's speaking browser, a mobile phone, or a digester.
Slashdot won't.
As a community, Linux users suffer considerably from badly written Web pages which 'work' in Microsoft IE4; on our screens these pages often have unreadble fonts, and unreadable point sizes. Unless people who create Web sites care about standards, and care about quality workmanship, we are continuing to fragment the Web into increasingly separate, increasingly non-interoperable ghettoes. We claim to be the masters of technology, not it's slave: we of all people should know how to get it right.
If you care about the quality of the work you do, you should care about things like that.
Pardonez moi, ma petit choux de Pays-Bas, but tout le monde et sa tante a dit ca en la France pendant touts les annis.
[Or something. I don't really speak French].
OK, well, the thing is this.
Run an AWT app on a Macintosh platform and it will look and feel reasonably Mac-ish. Run it on a Linux platform with the standard AWT bindings for Linux and exactly the same binary will look and feel reasonably Motif-ish. Run it on a WinXX PC and it will look as if it came from Redmond. And the reason this is so is that it isn't carrying around any personal baggage, it uses the real window toolkit of the environment it finds itself in. Consequently, if somebody invented a significantly different user-interface metaphor, and wrote AWT bindings for it, every AWT app would, if loaded in that environment, immediately look and feel (reasonably) native in that environment.
It would be entirely feasible to build a RISC OS like (or a KDE) binding for AWT and immediately all existing AWT applications would work in it.
This ain't possible with Swing, because Swing provides a look and feel (this is also why Swing is so huge and bloated).
In my opinion it would have been better to persevere with AWT...
<rant quality="weary">
Is there really any other industry on earth that would put up with sloppy, incompetent, unprofessional workmanship just because it looked good on the surface? I mean, come off it. I like
And it isn't any sort of excuse to claim that the majority of websites (particularly expensive ones) are also produced by sloppy incompetents who wouldn't know what an RFC was if it fell out of a tree on them. This is true. We know it. We can do better. And if we can't do better, what claim do we really have to being techs?
</rant>
The other thing that RISC OS did - well - differently was file typing. Files were typed with (effectively) an unsigned short in the directory structure. This is sort of a kludge; it meant there was a finite number of file types, and by the early nineties they were already in short supply. I remember we asked Acorn for a block of sixteen, and, after intense negotiation, were actually awarded eight.
But it had the advantage that when a file icon was dragged to your application, you got a request which said, effectively, here's one of these files, and it's this size, how do you want to handle it?. This saves an awful lot of messing about... The other nice thingb was that when the user selected a file and didn't drag it to a particular icon, the file was offered to the existing running copy of the application it was registered to, rather than starting a new copy. And if a file registered to your application was dragged to the printer, your application got alerted to decide how to render it on an abstract output stream, which the printer driver then translated to the particular printer actually in use.
People elsewhere in this discussion have criticised RISC OS's collaborative multi-tasking. Yes, if your application failed to make it's next wimp_poll() call in due time for whatever reason the whole desktop locked up - so it was vital that you caught and handled all your own errors. But the upside was responsiveness. Yes, the ARM was faster than any other microprocessor available at the time by a good margin, but that didn't really account for the whole improvement in responsiveness that users percieved. Another big part of that responsiveness was due to the very low system overhead.
However, nostalgia over. What can we learn from this and take forward? Well, one of the things we can learn is that RISC OS died in the marketplace (I know: my company was trying hard to sell it into big industry). Part of the reason it died was that it was different. People didn't take time to look past the difference to see that it was actually better. Part of the reason it died was lack of applications (although by 92 this was ceasing to be a real issue - most of the things people really needed were there, and most of them were very good). Part of the reason was that too few people will pay even a little more for a genuinely superior product. Part of the reason was single-vendor - 'what do we do if they go bust'. A lot of the reason was the old unfair reasons of the computer industry: FUD, whispers, lies, dishonest marketing.
There are a lot of lessons out of RISC OS for the Linux community. And at some stage I think a desktop based on RISC OS-like drag-and-drop will win out over all the different cruddy file dialogs and stuff. But if I was designing a desktop application now would I write for this desktop? Well, I wouldn't, because a desktop needs critical mass. This is a chicken and egg situation... what we really need to be doing in application design is separating out the functionality into layers with well abstracted boundaries between them, so that if I wanted to put a ROX-compliant shell around, say, Mozilla or the GIMP it would be reasonably straightforward to do. Because whether ROX is it or not, some day there really is going to be a really creative new user interface metaphor which comes along and sweeps away the Windows-style GUI we're all currently using. It will come quicker if it's easier to experiment with new metaphors; and when it comes we'll all want to get our favourite applications working on it as soon as possible.
Off topic, this is why I like the Abstract Window Toolkit so much, and think Swing is, in effect, a retrograde step.
We're motivated to develop Linux the way it is because it works for us, it provides us with what we need. In ESR's terms, we've been scratching our own itches. The masses who need all this luser-molly-coddling aren't competent to develop and maintain an OS; they need other people to do it for them. I don't see who has the motivation to do that except for money. So it seems to me entirely appropriate that the commerical OS businesses - Apple, Be, Microsoft - should use the commercial model to develop software for the people who cannot develop it for themselves. They have a motivation which we don't.
Next, and more importantly, it isn't at all clear to me that you can add all these luser-molly-coddling features as gloss, as a thin shell on the top. It seems to me that at least some of them must percolate quite deeply into the system. If this is the case we may find that by converting Linux into a system which lusers can use we may have converted it into a system which we find significantly less useful and less comfortable.
There is a myth that one size fits all. It doesn't. This is why, for example, Apple still exists: because it offers an OS which is significantly and usefully different from the mainstream to offer real benefits to a significant community of users. Similarly, Linux as it currently is provides significant benefits for a significant community of users - and that community is us.
We would be mad to change it.
I'm with you. It's pretty clear that, whatever you think of trademarking the name 'Leonardo', the arts foundation got there first. While I was at University in Lancaster, the International Committee of the Red Cross was having a campaign to stop other organisations using the name 'red cross' and served a 'cease and desist' notice on the Red Cross Inn in Lancaster. The inkeeper turned round and pointed out that the Red Cross Inn (founded, like most other pubs of the same name, by a returning crusader) had been trading under that name for more than seven hundred and fifty years, and politely asked how long they'd been using it. The ICRC retired hurt.
I don't think Leonardo Finance are in a good legal position here, under any country's laws (although I confess I'm no expert on France). What's more interesting is what the Gendarmerie were up to. If you tried that sort of thing on a Scottish policeman he'd say 'civil matter, none of my business' and send you on your way.
Now, if you look in the middle sort of three-quarters of the way up you'll find another funny shaped bit that's called 'Europe'. In Europe there's a country called 'France'. Now the bit that you may not have noticed is this: it isn't part of the United States of America. Furthermore, the people there fart in the general direction of your Supreme Court. They think that your president is a hamster and that your senate smells of elderberies. In short, they're FRENCH .
Now the point about this story is it happens in France. The people there are French. The goodies in this story are French. The baddies are French. Even the bold Gendarmes are French.
Messing about with American tort law, or sending American execs who break American laws to American prisons, is going to worry them not one little bit.
If the US patent office continues to hand out patents for trivial, obvious or non-original 'inventions', the US will have to face sooner or later a situation in which the Europeans and the Japanese cease to honour any US patents at all. We can't go on for ever offering reciprocal rights to a patent office which is neither competent nor responsible.
In a recent letter to my Member of Parliament I listed ten US software patents covering techniques my company (and hundreds of others around the world) had been using before the patent was filed (yes, the Amazon one was among them). This situation just cannot continue. Either you have to get your patent office to behave sensibly or you will have to face a situation where you effectively cannot export.
Not so, fortunately. A certain very large telco (which I'm not yet allowed to name) is now running its Intranet directory on an XML/XSL application which I've written. The application was developed on Linux and is currently running on Linux, although the customer intends to move it to Solaris.
My XML intro course is online; it's a little out of date at the moment but will be updated over the next few months.
XML and particularly RDF do have a lot to offer for search engines - see my other note further up this thread.
Yes, for a very large category of dynamic pages, it is. For example, in an online shop, the actual number of a particular product in stock at the moment may very from minute to minute, the price of that product in the user's preferred currency may change from week to week, but the product itself doesn't change much over months over months or years. It makes perfect sense to index the product page, because although some of the contained data may be transient, a great deal more is not.
Or take another example: the weather forecast for a particular area. The forecast itself may change regularly, but the page always contains a current forecast and that fact is worth indexing. The best technology available for this sort of thing is probably RDF and the Dublin Core metadata specification. Of course, the search engines still have to be persuaded to take heed of this...
Oh yes, and I do that when I'm asleep in my bed half a mile away exactly how? The one thing a server has to do is reboot cleanly, and as an absolute minimum reliably come back up to a state in which it can be remotely administered. If it can't you keep it on your network - I surely don't want it on mine!
The most pernicious thing about this sort of idiocy is what it potentially does to the likes of us. Big companies can afford to take out speculative patents on any computing technique which looks in the least promising. The fact that these patents would be struck down as prior art if challenged is irrelevent to them because they know that small companies and individuals cannot afford to mount challenges.
This really is one for your political representative. If this gets to stand, all open source software (and all small software companies) are dead.
But just because it's the most obviously revolutionary thing happening doesn't make it the most revolutionary. What CmdrTaco and the boys are doing is pretty revolutionary too - to take another of today's stories, for example, it's the Slashdot effect which surges huge flows of traffic around the Web. It isn't the Times effect, the CNN effect or the BBC effect, and it isn't because these bodies, skilled and resourced at newsgathering as they are, have not managed to exploit this new medium in the way that Slashdot has.
What I'm suggesting is that Slashdot may be to Berners-Lee as The Times was to Caxton, or CNN has been to Logie Baird: the body which has most effectively discovered the formula to harness the new technology to journalism, and which will in the long run influence the way in which journalism on the medium is presented.
Of course I may be wrong here; I may be simply absurdly overestimating Slashdot's importance. But at the same time I can't help betting that there are executives in half the media coroprations in the world lying awake at night wondering how they let Andover get away with such a bargain, and executives at Andover lying awake at nights wondering what to do with it.
We all (I assume) believe this medium is powerful, and yet we're all continually being surprised by how powerful it is. And so, from time to time, we get surprised when stories like this blow up out of nowhere. This is another sort of Slashdot effect , a consequence of using a powerful technology when you don't have enough experience with it to know instinctively the potential consequences of your actions.
What I liked about this story is that it is Slashdot introspecting about Slashdot. Introspection is something which, as Eric Raymond has often pointed out, we in the open source movement don't do enough of. When what you're doing is revolutionary, when the waters which you are navigating are uncharted, if you don't think carefully about what you're doing you are likely to do much less well than you otherwise might.
So Rob (and everyone else who has contributed), don't be upset by accusations of self indulgence. Sometimes looking at what we're doing, trying to understand what we're doing, and, most importantly, trying to understand the consequences of what we're doing, are as important as doing it.
Viva la revoluçion!
I am not, however, a nerd.
I live comfortably and happily with a fellow geek of the opposite gender whom I met on Usenet. We've been living together two years now - she's reading news on the machine next to mine as I type.
There's a lot to be said for living with another geek - she keeps the same sort of hours as I do, has the same tolearnce for mess as I do, and wants to go out and socialise as often as I do. Furthermore, she can do tricks with SQL that leave me gasping in awe, so my code has improved in places...
Oh, and she's seriously cute as well.
Yes: live in Techno Talking Babe very much recommended.
If it's a big database intensive project, performance could easily be the bottleneck.
Speaking as one who writes a lot of database intensive Web interfaced systems, the technology you use to bridge between the database and the Web still doesn't have a very big hit on performance. As I've said above my testing shows that compiled C performs best (of the technologies I've tested) for CGIs, and by a substantial margin.
However, I personally prefer to use Java Servlets, for reasons of code reusability, portability, and most importantly, code readability. And the reason that I feel that the (relatively) poor performance of servlets doesn't matter very much is that the real performance hit is in the database engine. The largest proportion of the time responding to any given response is the database engine doing it's stuff.
Using servlets I save time on starting the servlets (because they're permanently loaded) and setting up database connections (because they're permanently open in a pool, and it's only if there aren't enough in the pool I need to create another), and this saves more performance than the minor relative inefficiency of the JVM costs. Of course you could achieve similar benefits with mod_perl, but in my opinion Java still scores for code readability.