For those of you who think this is interesting, you can also check out meta-level compilation, implemented as an extension to gcc.
And for those of you wondering how useful stuff like this is, it's already caught bugs in the Linux kernel, among other things. So that low-level, tricky race condition that was fixed in the newest version? It might have been pointed out by this tool.
The solution under TrustedBSD is to delegate the root responsibilities to various executables. I'm not sure what this solves if root still has access to these new executables. Any ideas on how this will be accomplished?
The main idea is that you'll have a capability (for example) that says "this user can bind to ports numbered lower than 1024" and all executables that require such privileges will be only executable by that user (or some group, or whatever). If you make enough capabilities at a fine-grained level, then you'll be able to limit root's all-knowing, all-seeing power. Obviously this capability isn't a big one, but it's the only one I can quickly recall.
Is Raster and/or Mandrake still working for VA, by the way?
Mandrake is most definitely not, as you can find out by reading his web page at http://mandrake.net/. Raster appears (from his webpage, http://www.rasterman.com/) to still be working there, albeit it in Australia.
Not a good thing? KHTML is cool, IMHO. It allows many KDE programs to view Web pages right inside their program. This is good.
Yes, it is good. But you missed the whole point of the earlier statement. KHTML is not a part of the OS any more than X or Qt or KDE itself. Now, you can argue that one can uninstall IE and therefore it's not a part of the OS, but that's not a debate to have here (and IIRC, such a demonstration didn't work out too well during the anti-trust trial).
And I'm posting this from Mozilla on Windows, not IE, so I do have a choice there.
That's debateable. LISP has no typing, function arity, partial evaluation, composition, list comprehension, or even function predicates (not sure if that's the right name, it's where it only applies the function if the predicate matches).
I'm guessing by "function arity" you mean functions taking arbitrary numbers of arguments. Sorry. Common Lisp has those (so does Scheme, as a matter of fact).
Composition of functions? Lisp has had those for a long time. So what if you have to write the function to do it yourself? It's not that hard (think two lines or so).
Partial evaluation == lazy evaluation? Can be done. A macro and a function -- less than five lines total.
Function predicates? Where you check the arguments of a function before executing it? Not that hard and can even be integrated with the type-checking (see above).
I don't know what you mean by list comprehension, but I'm willing to bet that it's not hard.
Functional languages are somewhat open to argument. If you're talking about pure functional languages, then no, Lisp is not a functional language. However, I would argue that much of the research on functional languages and the techniques used in their compilation have come from Lisp. And if you're willing to fudge a little bit, Lisp looks a lot like a functional language.
All the languages that you mentioned are Turing-complete, so you can do anything in one language that you can do in another. It's my opinion that you can do it all easier in Lisp (what's the deal with the syntax of OCaml or Haskell? very very ugly! no syntactic abstraction like Lisp).
If you think Lisp is just Pascal, then you haven't looked at Lisp very closely. Try "On Lisp" by Paul Graham or "The Art of the Metaobject Protocol" by Kiczales et al to see a few things that Lisp is capable of doing.
You are letting the DVD industry take away something from you that you love: watching movies.
He never said he loved watching movies. He just said that if he couldn't watch movies because of his boycott on CSS, that's the price you pay for standing up for something.
But quit watching DVD movies? Let them control my viewing habits? Why? Why take away something I love to do? Why cut my nose to spite my face?
They're not controlling your viewing habits at all. It's a conscious choice on your part to not watch DVDs.
Getting changes made requires sacrifice. People have been throw in jail in order to change things. People have been killed in order to change things. Not being able to watch movies on DVDs sounds pretty pale in comparison.
Are you willing to do anything about what you believe to be right? Do you believe that CSS is a bad thing? Then stop supporting it while you lobby your Congressperson to overturn CSS-friendly legislation.
I was pretty upset about ReiserFS not getting into the kernel before 2.4.0, Linux absolutely NEEDS a Journaling Filesystem, and ReiserFS works beautifully and is the most mature.
Disclaimer: I don't use ReiserFS; ext2 works well enough for me.
Since when does Linux need anything? It works fine for me; all my favorite software runs on it. Therefore I can say that Linux categorically does not need anything, based on my experience.
Now, if we're going to talk about Linux making inroads in the server market, then a case might be able to be made for more whiz-bang features. But the same argument still holds: extra features are simply that: extra. The operating system works, with a ton of programs already written for it. It talks to the dhcp server here at school, it sends mail out for my mailing lists, and lets me serve web pages off my machine. Mentioning everything else is simply an exercise in boredom.
Besides, if ReiserFS has been distributed as a patch, what's so wrong with that? Lots of other kernel subsystem changes have been distributed via patches (kernel debuggers, asynchronous I/O, etc.). It's available. If he (Hans) wants his filesystem in 2.4 (with minor version numbers as appropriate), then maybe he could help with some of the changes the core kernel developers are saying need to be made. Rather than insisting that he has the answer and that his changes are all that matter.
It does not even work on glibc 2.0 even if you hand compile it. Trust me.
If you were following Mozilla development, you might have noticed this bug which tells you that glibc 2.0 is broken with regards to Mozilla. Don't do it. Upgrade to glibc 2.1.
And if you were really serious about compiling from source, you might have taken a look at the Mozilla Detailed Unix Build Instructions. This page even gives you a link to a patch that makes glibc 2.0.7 behave so that you can compile with Mozilla.
Somehow people have no problem with upgrading their system with security fixes, but ask them to upgrade system stuff that's broken to fix a bug and they go all to pieces.
Yes, konqueror. 1. It can be started in super user mode. 2. It can open a view which is a terminal emulation.
Every other file manager in the world can be started in super-user mode. I don't think that's what the original poster wanted. Something more along the lines of:
Execute operation that requires root privileges. (cp passwd.new/etc/passwd)
File manager realizes that it requires root privileges.
File manager prompts for root password.
User enters root password and file manager goes about its merry way
Starting a file manager as root is not an acceptable solution.
Terminal emulation? Big deal. Nearly every worthy filemanager (mc, gentoo) includes some ort of mechanism for spawning a shell. Try again.
Is it so strange that the GNOME team primarily write GNOME components? GTK+ is a small and fast widget set and I think huge complex components like the GNOME canvas is the last thing it needs.
I have nothing against the GNOME team writing GNOME components. I do have a problem with them writing incredibly useful components that could be used at a lower level than GNOME. Now, it's hard to decide exactly what should get backported from GNOME to GTK+, but if nothing else, things could get separated out to only depend on GTK+. Then GNOME could use those -- much better code reuse. That keeps GTK+ a "small and fast" widget set and benefits those programmers who don't care for GNOME but would like some GNOME-type functionality in their app.
AFAIK the only "GNOME html component" around is the GtkHTML component (used for example in the Helix Code Installer, Updater and some wizards). I'm pretty sure it works in GTK+ only apps too.
Well gosh, why don't you check out the Debian package page for GtkHTML and explain to me how it only depends on GTK+. And no, I'm not concerned about the image libraries; those are pretty standard and easily compilable.
If you want to use some little GNOME program, you run the helix-code installer. It finds and downloads all the libraries you needs, finds a place for them and installs them.
And for those of us who don't want to use the helix-code installer? Oh, that's right! We're screwed.
Miguel's article is spot on. I love everything about Unix except the fact that Component Based programming is so underused. If there is only one thing Microsoft has done right, it is the way they have developed and pushed COM. With COM, I can write a piece of software that performs a task (be it a Widget or piece of middleware) and COMify it.
Except that GNOME is going about this entirely the wrong way. They're writing a lot of useful stuff (the canvas, html components, etc.) except they can't figure out why somebody would want to use this stuff outside of GNOME. GTK+ could benefit from the standard inclusion of some of these things and it's likie fighting for a firstborn to move them out of GNOME into GTK+.
Example: In the previous article about Miguel speaking (sorry, no reference), one poster mentioned how he had gotten flamed for taking the GNOME html component and removing the GNOME dependencies. Clearly, an html component that everybody can use is a good thing. Requiring GNOME to use this html component is not a good thing.
Write the reusable software at the right level; don't GNOMEify everything in the name of "software reuse".
It seems to me that the author simply lacks experience with RPM. RPM in its more recent incarnations has a Prefix option so that you can define relocations from/usr to/usr/local or from/usr/doc to/usr/share/doc or whatever. You simply specify directories that can be relocated without breaking the package.
It's nice that recent versions of RPM use this. However, it's not quite so nice when somebody decides to make a package with a brand-spanking-new version of RPM which I try to download. 'Cause it breaks.
RPM has some serious issues. Among them (some detailed earlier):
No central package authority. Red Hat sort of counts, but they don't package nearly enough stuff. Forget even trying to use contrib.redhat.com, unless you want to use the SRPMs. And if you're going that route, you might as well just download the source tarball yourself.
Package dependencies. Yes, this is a good thing, but sometimes the packagers get a little too zealous in what they depend on. Sometimes I don't want version 4.5.6.73445 of the whizzy installer that requires GNOME 1.4435.8beta10. There needs to be an easy way to specify such things (perhaps there is and I haven't found it yet).
Version incompatibilities. We all know about version incompatibilities between programs (can you say glibc?).
I have RPM on my box, but that's only because I run Red Hat -- I'm familiar with it. Nearly everything else (including new versions of included packages) gets installed in/usr/local.
Every time I install Red Hat I tell myself I'm going to walk the Path of RPM. Every time it's too much of a pain and I go back to.tar.gz.
I think this was metioned in the other story, but it's such a good idea that it bears repeating here.
How about making kuro5hin based on a trust metric?
Here's how it might start out. rusty and Inoshiro and a few trusted other (perhaps loyal kuro5hin readers) would start off as the web of trust. As people begin to submit stories and get them moved to the front page, they can get "moderated" up to be trusted to submit reasonable stories. Perhaps as people gain trust, they can have their stories moved to the front page faster. Presumably, these same people would eventually be included in the trust web and extended "moderation" privileges. And soon you would have enough people that the load would be distributed evenly.
Of course, there could also be an increasingly (exponential) penalty for submitting crap, eventually cumulating in the banishment of the user/IP from submitting stories for some amount of time. If the banishment is not for all time, then the trust would have to be slowly extended back to this person. This would hopefully prevent cyclical occurences of spammation.
I think this preserves the idea of kuro5hin, allowing the community to decide what gets posted, while limiting the community to something reasonable. The same idea could even be applied to comments as well, to prevent people from screwing the comment queue as well.
Thinking of it in Slashdot terms, for those of you who are die-hard Slashdot fans, the trust web is akin to karma.
I really miss kuro5hin. This was the first idea that popped into my head for fixing things.
Heh. Why don't you check out gtk.themes.org and see just how many engine themes there are. There are about an order of magnitude more pixmap themes than engine themes.
You guessed wrong, about as completely opposite as it gets. Function arity refers to typing a function by how many args it takes, which is useful when the function is overloaded (which LISP doesn't support, either).
If functions do different things, then name them different things. And as a reply already noted, the object system in Lisp (CLOS) supports overloading of methods (check out defmethod)
Wrong again. Think "currying".
Fine. Lisp doesn't have syntax for it. But it can be done. Easily, in fact.
Do me a favor, learn what I'm talking about before responding to it. Learn a little about Haskell or ocaml first perhaps? I'm really too tired to flame, but you would deserve it otherwise.
Sorry if I had questions or appeared ignorant. It happens when people are learning or when confronted with unfamiliar language (partial evaluation == currying? whatever!). Lisp has list comprehensions and has for some time. Check the SERIES package if you want to see what I mean. Functional programming in Lisp! Amazing!
But just like a blind person may listen to the TV and glean some information from the shows, they still miss the whole experience. Yet no-one complains that all TV shows should be fully 'backward' compatible so that blind people don't miss out.
TVs render both video and audio (even text, if you have closed captioning on). But text-based browsers rely nearly exclusively on the text that you seem so fond to throw out in favor of more "advancced" methods of presentation. So you can't exactly have some "glearning" of information if the site doesn't include some sort of textual content. Ergo, text is necessary and as long as you have some on your page, you might as well go to the trouble of making your site look purty to everything.
Maybe I'm missing the point of separating the GUI from the application but what in addition to being slower doesn't that make the entire program more unstable, in someone just cutting up the HTML file and destroying the interface?
I don't suppose you've ever been concerned about Windows users destroying your DLLs, have you? What you speak of and wiping out C:\WINDOWS\SYSTEM are exactly the same thing. If the user wants to mess with the HTML interface files and screw them over, that's his/her problem. Besides, it offers more flexibility in that the user could even rearrange the interface if he/she wanted to. People who want to learn how to do this will. The majority of users will not care. And if the user goes into no man's land, he/she has to deal with the possible consequences.
INFO just seems so prickly to me; I hate having to use it. 'man' is so ubiqitous (can you say de-facto?)
Is there something about 'man' that is somehow non-free? or anti-GNU? Why/did/ GNU come up with INFO?
I wondered that myself for a while. I think it becomes clear if you look at the info pages for a little while. Notice that you have linked sections -- what basically amounts to a hypertext browser. Some info pages are even smart enough to link to info pages for other GNU programs, ultimately creating a "web" of documentation that you can jump around in. I don't think `man' can do that.
If you ask why GNU didn't use html, the answer was it didn't exist way back when in the dark ages of computing.:) `info' pages also provided a method to generate nice printed documentation for those of us who don't always like to read our documentation on the screen.
man pages also had acquired a reputation for being short and rather terse on some topics. I believe GNU wanted to avoid this as well (although I still find myself baffled by the info format sometimes). Quite simply, it was the best available solution they had at the time. Or rather, the best solution they could come up with, since I doubt similar systems were free in those days.
Do the other benchmark sites have fair benchmarks? I only looked at AMD's site and it seemed as though every benchmark was made with the disclaimer, "This motherboard is not commercially available." Obviously, AMD wants to show its processor in the best light, but it would be nice to see comparisons of computers real people can build, not just the engineers at AMD.
Slashdot Mirror
For those of you who think this is interesting, you can also check out meta-level compilation, implemented as an extension to gcc.
And for those of you wondering how useful stuff like this is, it's already caught bugs in the Linux kernel, among other things. So that low-level, tricky race condition that was fixed in the newest version? It might have been pointed out by this tool.
-sugarescent
The solution under TrustedBSD is to delegate the root responsibilities to various executables. I'm not sure what this solves if root still has access to these new executables. Any ideas on how this will be accomplished?
The main idea is that you'll have a capability (for example) that says "this user can bind to ports numbered lower than 1024" and all executables that require such privileges will be only executable by that user (or some group, or whatever). If you make enough capabilities at a fine-grained level, then you'll be able to limit root's all-knowing, all-seeing power. Obviously this capability isn't a big one, but it's the only one I can quickly recall.
-sugarescent
Is Raster and/or Mandrake still working for VA, by the way?
Mandrake is most definitely not, as you can find out by reading his web page at http://mandrake.net/. Raster appears (from his webpage, http://www.rasterman.com/) to still be working there, albeit it in Australia.
-sugarescentNot a good thing? KHTML is cool, IMHO. It allows many KDE programs to view Web pages right inside their program. This is good.
Yes, it is good. But you missed the whole point of the earlier statement. KHTML is not a part of the OS any more than X or Qt or KDE itself. Now, you can argue that one can uninstall IE and therefore it's not a part of the OS, but that's not a debate to have here (and IIRC, such a demonstration didn't work out too well during the anti-trust trial).
And I'm posting this from Mozilla on Windows, not IE, so I do have a choice there.
-sugarescent
That's debateable. LISP has no typing, function arity, partial evaluation, composition, list comprehension, or even function predicates (not sure if that's the right name, it's where it only applies the function if the predicate matches).
I'm not sure what you mean by no typing. Perhaps you haven't looked at the types and classes section of the Common Lips HyperSpec. Maybe you also forgot how to declare the types of arguments your function takes.
I'm guessing by "function arity" you mean functions taking arbitrary numbers of arguments. Sorry. Common Lisp has those (so does Scheme, as a matter of fact).
Composition of functions? Lisp has had those for a long time. So what if you have to write the function to do it yourself? It's not that hard (think two lines or so).
Partial evaluation == lazy evaluation? Can be done. A macro and a function -- less than five lines total.
Function predicates? Where you check the arguments of a function before executing it? Not that hard and can even be integrated with the type-checking (see above).
I don't know what you mean by list comprehension, but I'm willing to bet that it's not hard.
Functional languages are somewhat open to argument. If you're talking about pure functional languages, then no, Lisp is not a functional language. However, I would argue that much of the research on functional languages and the techniques used in their compilation have come from Lisp. And if you're willing to fudge a little bit, Lisp looks a lot like a functional language.
All the languages that you mentioned are Turing-complete, so you can do anything in one language that you can do in another. It's my opinion that you can do it all easier in Lisp (what's the deal with the syntax of OCaml or Haskell? very very ugly! no syntactic abstraction like Lisp).
If you think Lisp is just Pascal, then you haven't looked at Lisp very closely. Try "On Lisp" by Paul Graham or "The Art of the Metaobject Protocol" by Kiczales et al to see a few things that Lisp is capable of doing.
-sugarescent
You are letting the DVD industry take away something from you that you love: watching movies.
He never said he loved watching movies. He just said that if he couldn't watch movies because of his boycott on CSS, that's the price you pay for standing up for something.
But quit watching DVD movies? Let them control my viewing habits? Why? Why take away something I love to do? Why cut my nose to spite my face?
They're not controlling your viewing habits at all. It's a conscious choice on your part to not watch DVDs.
Getting changes made requires sacrifice. People have been throw in jail in order to change things. People have been killed in order to change things. Not being able to watch movies on DVDs sounds pretty pale in comparison.
Are you willing to do anything about what you believe to be right? Do you believe that CSS is a bad thing? Then stop supporting it while you lobby your Congressperson to overturn CSS-friendly legislation.
You are writing your Congressperson, aren't you?
-sugarescent
I was pretty upset about ReiserFS not getting into the kernel before 2.4.0, Linux absolutely NEEDS a Journaling Filesystem, and ReiserFS works beautifully and is the most mature.
Disclaimer: I don't use ReiserFS; ext2 works well enough for me.
Since when does Linux need anything? It works fine for me; all my favorite software runs on it. Therefore I can say that Linux categorically does not need anything, based on my experience.
Now, if we're going to talk about Linux making inroads in the server market, then a case might be able to be made for more whiz-bang features. But the same argument still holds: extra features are simply that: extra. The operating system works, with a ton of programs already written for it. It talks to the dhcp server here at school, it sends mail out for my mailing lists, and lets me serve web pages off my machine. Mentioning everything else is simply an exercise in boredom.
Besides, if ReiserFS has been distributed as a patch, what's so wrong with that? Lots of other kernel subsystem changes have been distributed via patches (kernel debuggers, asynchronous I/O, etc.). It's available. If he (Hans) wants his filesystem in 2.4 (with minor version numbers as appropriate), then maybe he could help with some of the changes the core kernel developers are saying need to be made. Rather than insisting that he has the answer and that his changes are all that matter.
-Nathan
a) Konqueror can be started as root from the Panel.
This is still a bad idea. And not at all what the original poster meant.
b) it can contain a view that is a Terminal window, i.e. the content pane is replaced by an embedded terminal.
Great. So I can't navigate my filesystem in comfort and have a shell command line at the same time.
-Nathan
It does not even work on glibc 2.0 even if you hand compile it. Trust me.
If you were following Mozilla development, you might have noticed this bug which tells you that glibc 2.0 is broken with regards to Mozilla. Don't do it. Upgrade to glibc 2.1.
And if you were really serious about compiling from source, you might have taken a look at the Mozilla Detailed Unix Build Instructions. This page even gives you a link to a patch that makes glibc 2.0.7 behave so that you can compile with Mozilla.
Somehow people have no problem with upgrading their system with security fixes, but ask them to upgrade system stuff that's broken to fix a bug and they go all to pieces.
-Nathan
Yes, konqueror. 1. It can be started in super user mode. 2. It can open a view which is a terminal emulation.
Every other file manager in the world can be started in super-user mode. I don't think that's what the original poster wanted. Something more along the lines of:
Starting a file manager as root is not an acceptable solution.
Terminal emulation? Big deal. Nearly every worthy filemanager (mc, gentoo) includes some ort of mechanism for spawning a shell. Try again.
-Nathan
Is it so strange that the GNOME team primarily write GNOME components? GTK+ is a small and fast widget set and I think huge complex components like the GNOME canvas is the last thing it needs.
I have nothing against the GNOME team writing GNOME components. I do have a problem with them writing incredibly useful components that could be used at a lower level than GNOME. Now, it's hard to decide exactly what should get backported from GNOME to GTK+, but if nothing else, things could get separated out to only depend on GTK+. Then GNOME could use those -- much better code reuse. That keeps GTK+ a "small and fast" widget set and benefits those programmers who don't care for GNOME but would like some GNOME-type functionality in their app.
AFAIK the only "GNOME html component" around is the GtkHTML component (used for example in the Helix Code Installer, Updater and some wizards). I'm pretty sure it works in GTK+ only apps too.
Well gosh, why don't you check out the Debian package page for GtkHTML and explain to me how it only depends on GTK+. And no, I'm not concerned about the image libraries; those are pretty standard and easily compilable.
-Nathan
If you want to use some little GNOME program, you run the helix-code installer. It finds and downloads all the libraries you needs, finds a place for them and installs them.
And for those of us who don't want to use the helix-code installer? Oh, that's right! We're screwed.
-Nathan
Miguel's article is spot on. I love everything about Unix except the fact that Component Based programming is so underused. If there is only one thing Microsoft has done right, it is the way they have developed and pushed COM. With COM, I can write a piece of software that performs a task (be it a Widget or piece of middleware) and COMify it.
Except that GNOME is going about this entirely the wrong way. They're writing a lot of useful stuff (the canvas, html components, etc.) except they can't figure out why somebody would want to use this stuff outside of GNOME. GTK+ could benefit from the standard inclusion of some of these things and it's likie fighting for a firstborn to move them out of GNOME into GTK+.
Example: In the previous article about Miguel speaking (sorry, no reference), one poster mentioned how he had gotten flamed for taking the GNOME html component and removing the GNOME dependencies. Clearly, an html component that everybody can use is a good thing. Requiring GNOME to use this html component is not a good thing.
Write the reusable software at the right level; don't GNOMEify everything in the name of "software reuse".
-Nathan
It seems to me that the author simply lacks experience with RPM. RPM in its more recent incarnations has a Prefix option so that you can define relocations from /usr to /usr/local or from /usr/doc to /usr/share/doc or whatever. You simply specify directories that can be relocated without breaking the package.
It's nice that recent versions of RPM use this. However, it's not quite so nice when somebody decides to make a package with a brand-spanking-new version of RPM which I try to download. 'Cause it breaks.
RPM has some serious issues. Among them (some detailed earlier):
I have RPM on my box, but that's only because I run Red Hat -- I'm familiar with it. Nearly everything else (including new versions of included packages) gets installed in /usr/local.
Every time I install Red Hat I tell myself I'm going to walk the Path of RPM. Every time it's too much of a pain and I go back to .tar.gz.
-Nathan
Have you seen Advogato? They do exactly this.
That's kind of where I got the idea from. :)
I think this was metioned in the other story, but it's such a good idea that it bears repeating here.
How about making kuro5hin based on a trust metric?
Here's how it might start out. rusty and Inoshiro and a few trusted other (perhaps loyal kuro5hin readers) would start off as the web of trust. As people begin to submit stories and get them moved to the front page, they can get "moderated" up to be trusted to submit reasonable stories. Perhaps as people gain trust, they can have their stories moved to the front page faster. Presumably, these same people would eventually be included in the trust web and extended "moderation" privileges. And soon you would have enough people that the load would be distributed evenly.
Of course, there could also be an increasingly (exponential) penalty for submitting crap, eventually cumulating in the banishment of the user/IP from submitting stories for some amount of time. If the banishment is not for all time, then the trust would have to be slowly extended back to this person. This would hopefully prevent cyclical occurences of spammation.
I think this preserves the idea of kuro5hin, allowing the community to decide what gets posted, while limiting the community to something reasonable. The same idea could even be applied to comments as well, to prevent people from screwing the comment queue as well.
Thinking of it in Slashdot terms, for those of you who are die-hard Slashdot fans, the trust web is akin to karma.
I really miss kuro5hin. This was the first idea that popped into my head for fixing things.
What do people think?
Heh. Why don't you check out gtk.themes.org and see just how many engine themes there are. There are about an order of magnitude more pixmap themes than engine themes.
You guessed wrong, about as completely opposite as it gets. Function arity refers to typing a function by how many args it takes, which is useful when the function is overloaded (which LISP doesn't support, either).
If functions do different things, then name them different things. And as a reply already noted, the object system in Lisp (CLOS) supports overloading of methods (check out defmethod)
Wrong again. Think "currying".
Fine. Lisp doesn't have syntax for it. But it can be done. Easily, in fact.
Do me a favor, learn what I'm talking about before responding to it. Learn a little about Haskell or ocaml first perhaps? I'm really too tired to flame, but you would deserve it otherwise.
Sorry if I had questions or appeared ignorant. It happens when people are learning or when confronted with unfamiliar language (partial evaluation == currying? whatever!). Lisp has list comprehensions and has for some time. Check the SERIES package if you want to see what I mean. Functional programming in Lisp! Amazing!
-sugarescent
But just like a blind person may listen to the TV and glean some information from the shows, they still miss the whole experience. Yet no-one complains that all TV shows should be fully 'backward' compatible so that blind people don't miss out.
TVs render both video and audio (even text, if you have closed captioning on). But text-based browsers rely nearly exclusively on the text that you seem so fond to throw out in favor of more "advancced" methods of presentation. So you can't exactly have some "glearning" of information if the site doesn't include some sort of textual content. Ergo, text is necessary and as long as you have some on your page, you might as well go to the trouble of making your site look purty to everything.
Maybe I'm missing the point of separating the GUI from the application but what in addition to being slower doesn't that make the entire program more unstable, in someone just cutting up the HTML file and destroying the interface?
I don't suppose you've ever been concerned about Windows users destroying your DLLs, have you? What you speak of and wiping out C:\WINDOWS\SYSTEM are exactly the same thing. If the user wants to mess with the HTML interface files and screw them over, that's his/her problem. Besides, it offers more flexibility in that the user could even rearrange the interface if he/she wanted to. People who want to learn how to do this will. The majority of users will not care. And if the user goes into no man's land, he/she has to deal with the possible consequences.
INFO just seems so prickly to me; I hate having to use it. 'man' is so ubiqitous (can you say de-facto?)
Is there something about 'man' that is somehow non-free? or anti-GNU? Why /did/ GNU come up with INFO?
I wondered that myself for a while. I think it becomes clear if you look at the info pages for a little while. Notice that you have linked sections -- what basically amounts to a hypertext browser. Some info pages are even smart enough to link to info pages for other GNU programs, ultimately creating a "web" of documentation that you can jump around in. I don't think `man' can do that.
If you ask why GNU didn't use html, the answer was it didn't exist way back when in the dark ages of computing. :) `info' pages also provided a method to generate nice printed documentation for those of us who don't always like to read our documentation on the screen.
man pages also had acquired a reputation for being short and rather terse on some topics. I believe GNU wanted to avoid this as well (although I still find myself baffled by the info format sometimes). Quite simply, it was the best available solution they had at the time. Or rather, the best solution they could come up with, since I doubt similar systems were free in those days.
Do the other benchmark sites have fair benchmarks? I only looked at AMD's site and it seemed as though every benchmark was made with the disclaimer, "This motherboard is not commercially available." Obviously, AMD wants to show its processor in the best light, but it would be nice to see comparisons of computers real people can build, not just the engineers at AMD.