Adams's Python contributions are well known - he said that what inspired him to get into comedy writing was the thought 'I'm as tall as John Cleese, so I should be as good at writing comedy'. But Dr Snuggles? That is obscure.
All I remember about that show is the horribly catchy theme tune. "Dr Snuggles, friend of the animal world\nDoo doo do doo do do..."
Unfortunately the series itself has been confused in my mind with that awful Teddy Ruxpin merchandising cartoon which also involved an inventor travelling around in an airship or balloon.
You'd think they would run some kind of fuzz test to catch bugs like this. Paste together random strings of plausible-looking HTML (perhaps taken from real web pages) until one of them crashes the browser.
I dunno, I didn't get the feeling that most of the objections to RH8 were saying 'I don't believe the new look and feel is better'. They seemed to be saying 'how dare Red Hat tamper with KDE' etc.
What you propose makes some sense - perhaps Red Hat will decide that it isn't worth the trouble of maintaining two desktop environments and trying to make them have a consistent look and feel. But OTOH, there are lots of useful KDE applications so they ought at least to ship the KDE support libraries. And obviously, it's no good to have inconsistent look and feel between applications, so the KDE libraries need to be configured to have the standard look, as well as using the standard system facilities for things like font configuration. Whether there should be a full 'KDE Desktop' is another matter.
But a totally vanilla, 'just compile the sources and dump it into/usr/' installation clearly isn't a good idea. It would make KDE applications inconsistent with the rest of the system, when what most users want is to have the same look, the same key bindings and the same behaviours. We should be leaving behind the bad old days when every X11 application could be expected to look and act differently from the other apps. It wasn't until KDE came along that someone set out to systematically fix this, and the KDE people did a great job of standardizing many classic X11 tools (clock, terminal, calculator, etc). But the job doesn't end with KDE. All apps on the desktop should have a familiar user interface, no matter what toolkit they were built with.
I agree that KDE provides a 'full desktop experience' but so does Red Hat Linux (or at least it tries to). Well done to the KDE developers on making a consistent, integrated desktop - but they shouldn't complain when others try to do the same.
The 'about KDE' dialogue box and Taiwan stuff is less reasonable, I agree. But then, KDE applications do not come with an 'about Qt' box.
Design by contract is a design method, it doesn't necessarily need support in the language. assert() is just one way of checking the contract at run time; Eiffel's DBC support is a cleaner way of doing the same thing because there is special syntax for it in the language. But you could do design-by-contract in assembly language if you wanted.
I'd like to see 'fuzz testing' that generates random inputs to a function and checks it fulfils its contract for each. This would be easiest to implement in a purely functional language with strong typing, so you know that the function's contract doesn't depend on global state and the input values you generate have a better chance of meeting the preconditions.
I completely agree but it's strange how the desktop projects themselves seem to dislike this. Look at all the complaining about how Red Hat had 'broken' KDE in the 8.0 release by theming it and changing the default browser to Mozilla. Some of the KDE developers seem to think that _they_ should decide the user interface experience, and that a common look and feel between KDE on different platforms (Linux, BSD, Solaris etc) is more important than a common look and feel within a distribution.
(Yet within the desktop project itself, there is no problem with theming the contained applications so they look consistent. When, a few years back, rxvt was adapted to make the original kvt, nobody claimed that the developers had 'broken' rxvt, or spoiled the consistent rxvt user interface across platforms. Of course fixing the look and feel to be consistent with the rest of KDE was more important. But the same principle should be applied more widely - adapting KDE, GNOME, Mozilla , OpenOffice and others to fit in to a single distribution.)
Or how about this: run applications directly from the RPM package. Some temporary directory is created to unpack the RPM into. The C library would need a small amount of fiddling to let the application transparently access its own files and those in other packages it uses. So if the app wants to look at/usr/lib/libfoo.so, this file is searched for in its own package, the other packages it depends on, and perhaps in the global filesystem if there is one. Things like user home directories would always be in the global filesystem of course.
Or instead of patching the C library it could be done with one of the fancy 'overlay' filesystems that OSes like the Hurd seem to support.
This scheme doesn't have much advantage over application directories as used by Mac OS X, the ROX desktop and others. Except that it would allow a gradual migration between installing packages into / and running apps directly from their packages.
And if some company in Taiwan releases a very inexpensive PC-like box for gaming via WineX, a box that sells millions of units, then the future of WineX compatibility is assured.
What about the Xbox? Does WineX run on that? Has anyone yet dared to install the necessary software on Xboxes and market them as cheap Windows-game-playing machines?
If WineX users become a significant part of the market, then game developers will make sure games run well under WineX. Just as they currently test under different versions of Windows, with different graphics cards, and so on.
There might come a time when WineX users outnumber Windows 95 users, for example.
The main cause of crashes on my machine is the hard disk going bye-bye: the disk indicator light stays on, all disk access blocks, so the system is up but things start to freeze when they want to use the disk. Pressing the reset button doesn't always work because the hard disk may seem to be absent at POST. However power-cycling does wake up the disk and I can boot as normal.
I run Linux-Mandrake 9.0, I haven't worked out if this is a problem with the disk itself (Maxtor 52049U4), the motherboard (A7V333), or a bug in the kernel's IDE drivers. The last is most likely, but if so why is the disk still in a 'stuck' state after a reset?
Yep. But in some ideal fantasy world, you could ring a hotline and men wearing hats with sirens and flashing lights on them would burst into your office, take away the computer for inspection and give you a new one. Then they would work out what caused the crash by poking through core dumps.
Or better, software could send a log of what it was doing to some central location, the processor could track the last N instructions executed, and then every crash would be reproducible.
I know both these things tend to happen with Windows licensing and the BSA, but that's not what I'm referring to:-).
I don't get it, why are the instructions telling you to get the raw tarballs and 'make install'? Why not get the source packages from whatever distribution you use and rebuild them with different compiler flags?
It sure would be useful to have a single command equivalent to Gentoo's 'emerge' which means 'download the source packages, build them with my compiler switches and install'. Does any RPM- or dpkg-based distribution have this?
Now all we need is for RMS to reimplement Emacs in Scheme, then we can put Emacs in the kernel, and then finally the UNIX-HATERS people might be happy!
The trouble is, the more accustomed users become to bugs, the harder it is to get them reported and fixed. If my computer crashes, I just reset it and get back to work. I don't bother to investigate what caused the bug, to try to reproduce it, to contact the vendor (hah!) and try to work out the problem. Crashes occur much too frequently for that.
OTOH, if computers were reliable enough to crash only once every few years, then users might report every crash that happens, the vendor can diagnose it, and fix the bug or family-of-bugs so that it never happens again. This is roughly what happens when a mainframe crashes, I believe - it's a big event.
Imagine if when your microwave crashed, you could call some hotline, they would come and replace the microwave and take away the old one for analysis. Instead, even on complex software systems the standard first resort for the help line is 'reboot and see if it goes away'.
What's also interesting is the number of 'before they were famous' names that come up in the text of the book - as authors of messages posted to UNIX-HATERS or to other places. Scott Meyers, Randal Schwartz, Jamie Zawinski, Theodore Ts'o...
Agreed. Read the book and you'll see it is nothing to do with pro-Windows propaganda. It was published in the days of Windows 3.1. The few references to Windows in the text are just as disparaging towards Windows as the rest of the book is towards Unix.
You get a vague idea that what the authors really favour is the old Lisp Machines - like the kind RMS used to hack on before starting GNU.
Today's graphics cards have quite a lot of processing power and onboard memory. And for a home entertainment system you need to do video playback, maybe recording too, but very little else that is computationally intensive.
I wonder if you could port Linux to run on the video card and do without a motherboard?
The first question you should ask is 'relative to what?' If asked to move Mount Fuji relative to myself, I could just walk.
Alternatively, 'by how much'? If you need to move by only a small amount relative to some other mountain, and movement is judged according to the centre of gravity, then moving one rock from the side of the mountain to the other side would shift the centre of gravity a little and so count as moving.
You could also eliminate LRU-caching overhead another way. Keep the files on disk in size order, with smaller files towards the start of the disk. Then instead of having a complex LRU block cache, just cache the bottom N megabytes of disk space in memory (and if you have battery-backed memory available, do long-term write caching as well as read caching). The trouble is how do you shuffle files around when their sizes change...
Slashdot Mirror
Adams's Python contributions are well known - he said that what inspired him to get into comedy writing was the thought 'I'm as tall as John Cleese, so I should be as good at writing comedy'. But Dr Snuggles? That is obscure.
All I remember about that show is the horribly catchy theme tune. "Dr Snuggles, friend of the animal world\nDoo doo do doo do do..."
Unfortunately the series itself has been confused in my mind with that awful Teddy Ruxpin merchandising cartoon which also involved an inventor travelling around in an airship or balloon.
Surely the official abbreviation of 'Doctor Who' should be not 'DW' but 'D?'. Or 'Dr?'.
You'd think they would run some kind of fuzz test to catch bugs like this. Paste together random strings of plausible-looking HTML (perhaps taken from real web pages) until one of them crashes the browser.
I dunno, I didn't get the feeling that most of the objections to RH8 were saying 'I don't believe the new look and feel is better'. They seemed to be saying 'how dare Red Hat tamper with KDE' etc.
What you propose makes some sense - perhaps Red Hat will decide that it isn't worth the trouble of maintaining two desktop environments and trying to make them have a consistent look and feel. But OTOH, there are lots of useful KDE applications so they ought at least to ship the KDE support libraries. And obviously, it's no good to have inconsistent look and feel between applications, so the KDE libraries need to be configured to have the standard look, as well as using the standard system facilities for things like font configuration. Whether there should be a full 'KDE Desktop' is another matter.
/usr/' installation clearly isn't a good idea. It would make KDE applications inconsistent with the rest of the system, when what most users want is to have the same look, the same key bindings and the same behaviours. We should be leaving behind the bad old days when every X11 application could be expected to look and act differently from the other apps. It wasn't until KDE came along that someone set out to systematically fix this, and the KDE people did a great job of standardizing many classic X11 tools (clock, terminal, calculator, etc). But the job doesn't end with KDE. All apps on the desktop should have a familiar user interface, no matter what toolkit they were built with.
But a totally vanilla, 'just compile the sources and dump it into
I agree that KDE provides a 'full desktop experience' but so does Red Hat Linux (or at least it tries to). Well done to the KDE developers on making a consistent, integrated desktop - but they shouldn't complain when others try to do the same.
The 'about KDE' dialogue box and Taiwan stuff is less reasonable, I agree. But then, KDE applications do not come with an 'about Qt' box.
Design by contract is a design method, it doesn't necessarily need support in the language. assert() is just one way of checking the contract at run time; Eiffel's DBC support is a cleaner way of doing the same thing because there is special syntax for it in the language. But you could do design-by-contract in assembly language if you wanted.
I'd like to see 'fuzz testing' that generates random inputs to a function and checks it fulfils its contract for each. This would be easiest to implement in a purely functional language with strong typing, so you know that the function's contract doesn't depend on global state and the input values you generate have a better chance of meeting the preconditions.
I completely agree but it's strange how the desktop projects themselves seem to dislike this. Look at all the complaining about how Red Hat had 'broken' KDE in the 8.0 release by theming it and changing the default browser to Mozilla. Some of the KDE developers seem to think that _they_ should decide the user interface experience, and that a common look and feel between KDE on different platforms (Linux, BSD, Solaris etc) is more important than a common look and feel within a distribution.
(Yet within the desktop project itself, there is no problem with theming the contained applications so they look consistent. When, a few years back, rxvt was adapted to make the original kvt, nobody claimed that the developers had 'broken' rxvt, or spoiled the consistent rxvt user interface across platforms. Of course fixing the look and feel to be consistent with the rest of KDE was more important. But the same principle should be applied more widely - adapting KDE, GNOME, Mozilla , OpenOffice and others to fit in to a single distribution.)
Is it free-as-in-Debian? If so, you might persuade Cheap Bytes or similar reseller to burn copies.
Or how about this: run applications directly from the RPM package. Some temporary directory is created to unpack the RPM into. The C library would need a small amount of fiddling to let the application transparently access its own files and those in other packages it uses. So if the app wants to look at /usr/lib/libfoo.so, this file is searched for in its own package, the other packages it depends on, and perhaps in the global filesystem if there is one. Things like user home directories would always be in the global filesystem of course.
Or instead of patching the C library it could be done with one of the fancy 'overlay' filesystems that OSes like the Hurd seem to support.
This scheme doesn't have much advantage over application directories as used by Mac OS X, the ROX desktop and others. Except that it would allow a gradual migration between installing packages into / and running apps directly from their packages.
What about the Xbox? Does WineX run on that? Has anyone yet dared to install the necessary software on Xboxes and market them as cheap Windows-game-playing machines?
If WineX users become a significant part of the market, then game developers will make sure games run well under WineX. Just as they currently test under different versions of Windows, with different graphics cards, and so on.
There might come a time when WineX users outnumber Windows 95 users, for example.
Talk about 'last words'!
The main cause of crashes on my machine is the hard disk going bye-bye: the disk indicator light stays on, all disk access blocks, so the system is up but things start to freeze when they want to use the disk. Pressing the reset button doesn't always work because the hard disk may seem to be absent at POST. However power-cycling does wake up the disk and I can boot as normal.
I run Linux-Mandrake 9.0, I haven't worked out if this is a problem with the disk itself (Maxtor 52049U4), the motherboard (A7V333), or a bug in the kernel's IDE drivers. The last is most likely, but if so why is the disk still in a 'stuck' state after a reset?
Yep. But in some ideal fantasy world, you could ring a hotline and men wearing hats with sirens and flashing lights on them would burst into your office, take away the computer for inspection and give you a new one. Then they would work out what caused the crash by poking through core dumps.
:-).
Or better, software could send a log of what it was doing to some central location, the processor could track the last N instructions executed, and then every crash would be reproducible.
I know both these things tend to happen with Windows licensing and the BSA, but that's not what I'm referring to
I don't get it, why are the instructions telling you to get the raw tarballs and 'make install'? Why not get the source packages from whatever distribution you use and rebuild them with different compiler flags?
It sure would be useful to have a single command equivalent to Gentoo's 'emerge' which means 'download the source packages, build them with my compiler switches and install'. Does any RPM- or dpkg-based distribution have this?
Now all we need is for RMS to reimplement Emacs in Scheme, then we can put Emacs in the kernel, and then finally the UNIX-HATERS people might be happy!
The trouble is, the more accustomed users become to bugs, the harder it is to get them reported and fixed. If my computer crashes, I just reset it and get back to work. I don't bother to investigate what caused the bug, to try to reproduce it, to contact the vendor (hah!) and try to work out the problem. Crashes occur much too frequently for that.
OTOH, if computers were reliable enough to crash only once every few years, then users might report every crash that happens, the vendor can diagnose it, and fix the bug or family-of-bugs so that it never happens again. This is roughly what happens when a mainframe crashes, I believe - it's a big event.
Imagine if when your microwave crashed, you could call some hotline, they would come and replace the microwave and take away the old one for analysis. Instead, even on complex software systems the standard first resort for the help line is 'reboot and see if it goes away'.
Doesn't MOSIX already do this? Or does MOSIX just migrate a single process from one host to another without 'sharing' memory?
Even swapping over NFS could be considered remote memory, although it is not exactly 'shared'.
What's also interesting is the number of 'before they were famous' names that come up in the text of the book - as authors of messages posted to UNIX-HATERS or to other places. Scott Meyers, Randal Schwartz, Jamie Zawinski, Theodore Ts'o...
Agreed. Read the book and you'll see it is nothing to do with pro-Windows propaganda. It was published in the days of Windows 3.1. The few references to Windows in the text are just as disparaging towards Windows as the rest of the book is towards Unix.
You get a vague idea that what the authors really favour is the old Lisp Machines - like the kind RMS used to hack on before starting GNU.
Today's graphics cards have quite a lot of processing power and onboard memory. And for a home entertainment system you need to do video playback, maybe recording too, but very little else that is computationally intensive.
I wonder if you could port Linux to run on the video card and do without a motherboard?
The first question you should ask is 'relative to what?' If asked to move Mount Fuji relative to myself, I could just walk.
Alternatively, 'by how much'? If you need to move by only a small amount relative to some other mountain, and movement is judged according to the centre of gravity, then moving one rock from the side of the mountain to the other side would shift the centre of gravity a little and so count as moving.
You could also eliminate LRU-caching overhead another way. Keep the files on disk in size order, with smaller files towards the start of the disk. Then instead of having a complex LRU block cache, just cache the bottom N megabytes of disk space in memory (and if you have battery-backed memory available, do long-term write caching as well as read caching). The trouble is how do you shuffle files around when their sizes change...
But the natural ordering would be 'corrected universal time' since in English the adjective comes before the verb.