Either you have stuck around with too many bad lisp programmers, or you haven't paid enough attention to what they were doing - no usefulness can come from code which uses lists for anything more than they were designed for - sequences of data. (-:
Also, it is not very rewarding to just clip the first element off the list you gave - it will still be around (not being garbage collected until the pointer to the head is), so why bother?
Scheme is not, in any way I can think of, over-extended. It is designed to be a minimalistic language - hells, it even has minimalistic syntax. Please check your facts before you claim such things. Common Lisp does have a hell of a standard, though. But see Greenspun's tenth rule for why.
And concerning your hate of paranthesis, I can only believe that you have mapped your () buttons to the wrong keys - using them from a non-shifted key (dump those []s, for example (-;) makes them much easier to type (and having an editor which can operate with the lists your code forms, helps too - use vi -l or emacs).
you would not even need to define any new macros for the stuff that is shown in the review, IMHO - before, after, around-methods and call-next-method already exist in the lisp standard. (cue greenspun's tenth rule of programming).
Honestly, You should check out EMacro (linked to from the Emacro site, a project that aims to provide the user with a usable first configuration, which should be "intuitive" to someone who is used to using "sane" editors (-;
Though I bet you would not give up your working emacs config if you have one, it is still worth checking out if you have not spent lots of time to configure emacs before.
Still, it was not possible to integrate them into the release for obvious reasons: lack of time and the release cycle.
But, judging from the comments (and Ben's addition to the original article) here, 4.75 is already available for those who want it, thus invalidating the arguments of the three of us.
This
means that at release, packages are dead-stable (they wont crash)
Sorry for the minor nitpick here: it does not mean that the packages won't crash, it just means that none of them have release-critical bugs (== bugs with a severity above "important") in the Bug Tracking system that can be fixed before the release.
If they can not, they will have to wait until the next revision (that would be 2.2r1) and go into the release notes.
With physical access, there is no such thing as security.
There was a (no, more than one, actually) flamewar on debian-devel on this issue. One about the autofs daemon, and one about the MBR that is set up on initial install.
They all started with your argument, and they ended with the participants throwing nothing but profanities at each other. So, before you reply to this post saying something along the lines of "But lilo should be secure, too!", please, please check out the Debian List archives to see whether your point has already been made!
IIRC, the postinst of netbase (it was netbase, wasn't it?) asked whether you wanted to disable daytime, exec etc. services in the inetd.conf file, about since a month ago.
Dunno whether the author of the article missed it, or whether the postinst was changed again, but I'm pretty convinced that this point is invalid.
Isn't that a little self-centered? While "everyone" was speaking latin, IIRC, China was already up and running (it seems like China was up and running even 1500 years before that).
Just because most of the english-speaking people are richer and generally more well-taught does not mean that the others are irrelevant, you know...
As for the "world empire" stuff: Every "world empire" tells its people that it is The Thing and that the others are irrelevant. It's just the basic propaganda that keeps the state from falling apart.
Becoming a historical world empire, then, is just a matter who believes the people who tell you this stuff. Western historians tend to believe the Greek and Roman stuff. That's what makes them anyone.
There are no "more interesting" people. You better get used to that.
"The fingerprint doesn't change even if the sound is compressed, converted to a different file format, broadcast over the radio,...</i>"
...sung at a karaoke event, covered, remixed, hummed by any being with vocal chords, played on a bagpipe, and so on. --
this post was brought to you by Andreas Fuchs.
Sorry, you misunderstood what I meant, yet did not write:
The tool should grow with the user's knowledge. Advanced tools are great for advanced users, and simple tools are great for novice users; yet, none of them is really user-friendly. Unser-friendliness depends on two things:
the tool hides the parts of the system the user does not need to understand (eg. the way regexps are matched against text)
the tool does not hide parts of the sysmtem that the user understands already and wants to exploit. (eg. the tool has an extension language -- elisp, AutoLISP or guile)
Windows, KDE and Gnome are (IMHO!) notorious about forgetting the second point, whereas Unix tools (IMHO again!) often forget about the first.
--
this post was brought to you by Andreas Fuchs.
And we all know that geeks don't care too much for easy-to-use interfaces, but more for powerful ones
(I'm speaking about the "typical geek" here: proficient with >= 1 programming language, knows his/her way around Unix/Linux, etc)
That is right. Geeks prefer advanced, difficult, powerful user interfaces, whereas novice users prefer simple, easy, "magical" UIs. This is because geeks already know their way around. They know how things depend on each other. They have already mapped the Interface in their brain.
Novices have not. They need to learn the UI, begin to place pieces of the map in the right places in their heads.
So, GNOME and KDE are trying to make life easier for the novice by providing them with simple user interfaces that they can use. Of course, they should be consistent. This is one of the most important points of UIs: to make life easy for the user, so that he/she can easily get acquainted with a tool.
But, what if the user already knows the tool? What if he/she has used it often and thououghly enough to have a mental map of what it does in his/her head? If this happens, most tools seem restrictive to advanced users, and therefore, when given the tools to do it, they construct these powerful, hard-to-learn environments.
But that's not the way to do it, IMHO. Instead of producing a one-size-fits-all tool, you (and you, and you) should create tools that are fit for differently experienced users to use. See UN*X, for example. It's philosophy was:
"Write programs that do one thing and do it well. Write programs to work together. Write programs that handle text streams, because that is a universal interface." (Peter H. Salus, A quarter century of UNIX[TM])
This is a concept that is both simple and powerful. It brought forth tools like sed, grep and so on. These are extremely simple to understand, and if you understand them, they are extremely powerful. Why noone has succeeded in creating an equally powerful and simple concept in GUIs escapes me, but it's definitely time to go create one. --
this post was brought to you by Andreas Fuchs.
must... suppress...
This gives "diskspace dicksize war" a whole new name.
aaargh! Now look what you've made me do! --
this post was brought to you by Andreas Fuchs.
Hm. Looks nice, but what are its access times? How much will it cost in mass-production, how reliable is it and how soon will it be on the market?
To compete in the portable sector (and I bet that such an invention will), it will have to be reasonably cheap, and appear before remote storage gets secure and cheap enough --- Why carry your bookshelf (however small or light) if it can be stolen at any time? Why not rely on somebody else to store your data in a secured disk(or vial)farm? --
this post was brought to you by Andreas Fuchs.
There are (or at least, there were) efforts to use the BSD kernel inside Debian. If the list archive search weren't broken (internal server error), I could have posted a link. {-:
BTW, wouldn't there be four branches at least during the QA phase (unstable, testing, frozen, stable)?
Slashdot Mirror
Now that you're asking, no, there isn't.
Either you have stuck around with too many bad lisp programmers, or you haven't paid enough attention to what they were doing - no usefulness can come from code which uses lists for anything more than they were designed for - sequences of data. (-:
Also, it is not very rewarding to just clip the first element off the list you gave - it will still be around (not being garbage collected until the pointer to the head is), so why bother?
Scheme is not, in any way I can think of, over-extended. It is designed to be a minimalistic language - hells, it even has minimalistic syntax. Please check your facts before you claim such things. Common Lisp does have a hell of a standard, though. But see Greenspun's tenth rule for why.
And concerning your hate of paranthesis, I can only believe that you have mapped your () buttons to the wrong keys - using them from a non-shifted key (dump those []s, for example (-;) makes them much easier to type (and having an editor which can operate with the lists your code forms, helps too - use vi -l or emacs).
you would not even need to define any new macros for the stuff that is shown in the review, IMHO - before, after, around-methods and call-next-method already exist in the lisp standard. (cue greenspun's tenth rule of programming).
"um" indeed. Do 1.5 * 10^6 really make up 40% of infinity, or was that a misplaced semicolon? (-:
No, my geek room doesn't contain any mirrors. Hell, I want it to be comfortable, not scary!
Now that you have read this, you will have to pay me USD 10,90. Or not.
--
this post was brought to you by Andreas Fuchs.
Cars? Whaddya mean by cars? I thought they was called "horseless carriages"!
In my time, we had to manipulate the ino^H^H^Hwheels with magnets!
--
this post was brought to you by Andreas Fuchs.
Honestly, You should check out EMacro (linked to from the Emacro site, a project that aims to provide the user with a usable first configuration, which should be "intuitive" to someone who is used to using "sane" editors (-;
Though I bet you would not give up your working emacs config if you have one, it is still worth checking out if you have not spent lots of time to configure emacs before.
--
this post was brought to you by Andreas Fuchs.
Still, it was not possible to integrate them into the release for obvious reasons: lack of time and the release cycle.
But, judging from the comments (and Ben's addition to the original article) here, 4.75 is already available for those who want it, thus invalidating the arguments of the three of us.
Moderator! Get me four "Redundant"s here! (-;
--
this post was brought to you by Andreas Fuchs.
Seems to work, but I dunno if there is a risk connected to it. Symlink attacks anyone?
--
this post was brought to you by Andreas Fuchs.
It is not. Binpatching non-free software is not very funny, indeed. You could ask the fortify maintainers (-:
But back to topic: how can it be Debian's fault if non-free (thus, not really patchable) software has bugs?
(thinks)
Just following the Karma recipe, or was that supposed to be humorous? (-:
--
this post was brought to you by Andreas Fuchs.
Sorry for the minor nitpick here: it does not mean that the packages won't crash, it just means that none of them have release-critical bugs (== bugs with a severity above "important") in the Bug Tracking system that can be fixed before the release.
If they can not, they will have to wait until the next revision (that would be 2.2r1) and go into the release notes.
--
this post was brought to you by Andreas Fuchs.
There was a (no, more than one, actually) flamewar on debian-devel on this issue. One about the autofs daemon, and one about the MBR that is set up on initial install.
They all started with your argument, and they ended with the participants throwing nothing but profanities at each other. So, before you reply to this post saying something along the lines of "But lilo should be secure, too!", please, please check out the Debian List archives to see whether your point has already been made!
Thank you for avoiding trouble. (-:
--
this post was brought to you by Andreas Fuchs.
Dunno whether the author of the article missed it, or whether the postinst was changed again, but I'm pretty convinced that this point is invalid.
--
this post was brought to you by Andreas Fuchs.
Just because most of the english-speaking people are richer and generally more well-taught does not mean that the others are irrelevant, you know...
As for the "world empire" stuff: Every "world empire" tells its people that it is The Thing and that the others are irrelevant. It's just the basic propaganda that keeps the state from falling apart.
Becoming a historical world empire, then, is just a matter who believes the people who tell you this stuff. Western historians tend to believe the Greek and Roman stuff. That's what makes them anyone.
There are no "more interesting" people. You better get used to that.
--
this post was brought to you by Andreas Fuchs.
It's GNU, and it's there already. And it's as "portable" as the original author describes.
--
this post was brought to you by Andreas Fuchs.
"The fingerprint doesn't change even if the sound is compressed, converted to a different file format, broadcast over the radio, ...</i>"
...sung at a karaoke event, covered, remixed, hummed by any being with vocal chords, played on a bagpipe, and so on.
--
this post was brought to you by Andreas Fuchs.
The tool should grow with the user's knowledge. Advanced tools are great for advanced users, and simple tools are great for novice users; yet, none of them is really user-friendly. Unser-friendliness depends on two things:
- the tool hides the parts of the system the user does not need to understand (eg. the way regexps are matched against text)
- the tool does not hide parts of the sysmtem that the user understands already and wants to exploit. (eg. the tool has an extension language -- elisp, AutoLISP or guile)
Windows, KDE and Gnome are (IMHO!) notorious about forgetting the second point, whereas Unix tools (IMHO again!) often forget about the first.--
this post was brought to you by Andreas Fuchs.
(I'm speaking about the "typical geek" here: proficient with >= 1 programming language, knows his/her way around Unix/Linux, etc)
That is right. Geeks prefer advanced, difficult, powerful user interfaces, whereas novice users prefer simple, easy, "magical" UIs. This is because geeks already know their way around. They know how things depend on each other. They have already mapped the Interface in their brain.
Novices have not. They need to learn the UI, begin to place pieces of the map in the right places in their heads.
So, GNOME and KDE are trying to make life easier for the novice by providing them with simple user interfaces that they can use. Of course, they should be consistent. This is one of the most important points of UIs: to make life easy for the user, so that he/she can easily get acquainted with a tool.
But, what if the user already knows the tool? What if he/she has used it often and thououghly enough to have a mental map of what it does in his/her head? If this happens, most tools seem restrictive to advanced users, and therefore, when given the tools to do it, they construct these powerful, hard-to-learn environments.
But that's not the way to do it, IMHO. Instead of producing a one-size-fits-all tool, you (and you, and you) should create tools that are fit for differently experienced users to use. See UN*X, for example. It's philosophy was:
"Write programs that do one thing and do it well. Write programs to work together. Write programs that handle text streams, because that is a universal interface."
(Peter H. Salus, A quarter century of UNIX[TM])
This is a concept that is both simple and powerful. It brought forth tools like sed, grep and so on. These are extremely simple to understand, and if you understand them, they are extremely powerful. Why noone has succeeded in creating an equally powerful and simple concept in GUIs escapes me, but it's definitely time to go create one.
--
this post was brought to you by Andreas Fuchs.
Well, I guess that The Jargon File would have to be updated (-:
--
this post was brought to you by Andreas Fuchs.
I don't dare to think about _where_ you would...
must... suppress...
This gives "diskspace dicksize war" a whole new name.
aaargh! Now look what you've made me do!
--
this post was brought to you by Andreas Fuchs.
Hm. Looks nice, but what are its access times? How much will it cost in mass-production, how reliable is it and how soon will it be on the market?
To compete in the portable sector (and I bet that such an invention will), it will have to be reasonably cheap, and appear before remote storage gets secure and cheap enough --- Why carry your bookshelf (however small or light) if it can be stolen at any time? Why not rely on somebody else to store your data in a secured disk(or vial)farm?
--
this post was brought to you by Andreas Fuchs.
If you can't beat them, eat them.
There are (or at least, there were) efforts to use the BSD kernel inside Debian. If the list archive search weren't broken (internal server error), I could have posted a link. {-:
BTW, wouldn't there be four branches at least during the QA phase (unstable, testing, frozen, stable)?
--
this post was brought to you by Andreas Fuchs.
And bash is installed, which should renders some of the rants posted here irrelevant.
So, check the machine description on the site!
Hell, even bc is installed (-:
--
this post was brought to you by Andreas Fuchs.