AFAIK, DFM is supposed to at least be inspired by the Workplace Shell. I can't say how good an imitation it is, since I haven't used OS/2, but I think it's supposed to be a partial imitation. DFM is available at http://dfm.online.de.
"However, in the US & other countries, the only way adults can get AIDS is by sharing drug needles or promiscuous/unprotected sex.
Careful here. Are you presuming that screening out of HIV-infected blood is 100% effective? Even if it is 99.9999% effective, that still leaves 0.0001%. If I were you, I'd be leery of presuming that there was absolutely no possibility of getting HIV from a blood transfusion.
"Therefore, I have absolutely no sympathy for adults in the US that get AIDS now as a result of their unhealthy behavior."
Ok, how about this scenario. Say a husband goes off on a business trip, has, um, an indiscretion, with someone who turns out to be infected with HIV, and unknowingly gets infected himself. Husband comes home and makes love to his wife, who in turn gets infected with HIV.
Now are you saying that you have no sympathy for the wife here? Would you honestly consider unprotected sex between husband and wife to be unhealthy or irresponsible behavior?
"Both are free script language which more or less share the same goal: be a more readable Perl."
I can't speak for Ruby since I know little about it but the name, but I'd hardly call Python "a more readable Perl."
Perl is a language that was meant at the beginning to do jobs that were just out of reach of the sed, awk and shell--which is why Perl tends to resemble sed, awk and shell to a fair extent.
Python was meant to be a very clean, orderly language, which is why it has such features as using indentation for statement grouping, and can have something like "foo foo) and (x bar)". Readablity seems to be Python's reason for being.
I won't claim that either language is better than the other, but they strike me as thoroughly different in culture, lineage, and goals.
IMHO, a better answer to "what the heck do I do with this linux driver on disk?" is to follow the instructions in the README or INSTALL file that came with it.
"If you want near-WYSIWYG editing tools, TeX/LaTeX is only a good choice if you stay in UNIX, since there are no good near-WYSIWYG editing tools (that I know of) for MAC, and perhaps not even for Windows."
For Windows, there's "Scientific Word" at http://www.mackichan.com/.
Actually, another difference is H&J--hyphenation & justification. Loosely speaking, TeX does its H&J by trying out different ways of breaking a paragraph into lines and filling it, assigning each way a "badness" score, and choosing the way with the least badness. The result is H&J that looks rather nice and seldom has ugly gaps between words or too many words scrunched together. WYSIWYG document processors do their H&J on the fly, which means they *can't* do things like try out different ways of breaking a paragraph and so on, so it doesn't always look as good.
"It seems these days that every document available from Gov't websites is available as Text, PDF, and WordPerfect. WordPerfect is available for Linux. I don't know about that for OpenBSD."
If OpenBSD's Linux emulation is anything like FreeBSD's, then running WordPerfect for Linux on OpenBSD wouldn't be a problem.
"It starts, 'Consider a world without copyright enforcement', which makes me think, great, someone has come up with what they think is a great idea, but is probably untested, or even been thoroughly debated."
The "Street Performer Protocol" is not a manifesto. It is a partial solution to the question of how to make money in a world where copyright is difficult to enforce.
When "Street Performer Protocol" says "Consider a world without copyright enforcement," it is not thinking of a utopia where copyright is banished on ethical grounds, a la the world as RMS would like to see it, but rather a world in which technology is making the flouting of copyright law so much easier that, right or wrong, enforcement of copyright is becoming more of an uphill struggle--a world which the real world resembles more and more nowadays.
BTW, this is *not* an undergraduate student's thesis. Take a look at the authors:
John Kelsey is a cryptographer at Counterpane Systems, co-designer of Twofish and Yarrow, and the author of dozens of academic papers on cryptography.
E-mail: kelsey@counterpane.com
Bruce Schneier is president of Counterpane Systems, the author of Applied Cryptography (John Wiley & Sons, 1994 & 1996), and an inventor of the Blowfish, Twofish, and Yarrow algorithms. He serves on the board of the International Association for Cryptologic Research, EPIC, and VTW. He is a contributing editor to Dr. Dobb's Journal, and a frequent writer and lecturer on cryptography. Counterpane Systems is a five-person consulting firm specializing in cryptography and computer security. Counterpane provides expert consulting in, design and analysis, implementation and testing, threat modeling, product research and forecasting, classes and training, intellectual property, and export consulting. Contracts range from short-term design evaluations and expert opinions to multi-year development efforts.
E-mail: schneier@counterpane.com
I suggest giving the paper a good read. It's fairly pragmatic and well-thought out.
"I think that it's fair to say that GNOME is approaching "critical mass" on the *u*x* desktop front. I myself use and prefer to use KDE2, but GNOME looks like it will just have the numbers."
Maybe yes, maybe no. I highly doubt that we will know which desktop will become the most popular until it happens, if it happens. Remember, Sun is waiting until GNOME 2.0 comes out before it starts putting it on its machines, which will be quite some time from now, at least a year. A lot can happen in a year. Wait and see.
That depends on what one wants to do with the GPL'd software in question. If the idea is to try to make money directly from GPL'd software, then one may have a problem. If however, one is trying to create a standard software infrastructure on which to build that everyone holds in common, then GPL'd and LGPL'd software is a good way to go. The latter seems to be Sun is going.
"The week you spend playing Bard's Tale is one week of delayed revenues for Ultima 2001 Pro Special Gold Edition"
Not necessarily. That assumes that those who play the older games would want to play the newer ones. To some extent, that also assumes that the newer games are even comparable to the older ones, which may not be the case if the older games are of different genres, have different rules, different feel, etc.
The main problem with Lout is that while it is easy to customize section headings, Lout is rigid about where things like prefaces, tables of contents, or indices go. I can't choose in a Lout document whether the table of contents will be before or after the preface, or even whether to put the table of contents in the back (which is a common practice in some countries). The "report" document format in Lout will repeat the lines in the title page at the top of the first page of the report. I've found that I've ended up needing to use the "book" format for maximum flexibility.
IMHO, I find it kind of sad that rigidity in some aspects of Lout frustrates the usefulness of the customizability of other aspects. If Lout lost some of that rigidity and gained a way to do bold Greek fonts without teq (maybe via an overstriking command like eqn's "fat"?) it would be just the slightest bit superior than TeX/LaTeX, IMHO.
"Nothing is good or bad, but thinking makes it so". (it's a paraphrase, too lazy to find it on the web)
Everyone has different morals, and no-one should ever be subject, against their will, to someone else's morals or beliefs."
Careful here. You basically leapt from the premise that "you will always have debates about degrees of rightness or wrongness" to the conclusion that "Nothing is good or bad."
There is a vast difference between saying that the line between right and wrong is fuzzy, and saying that it doesn't exist at all.
The ruling was that "indecent" expression is protected while "obscene" is not, and what was considered "obscene" by the Supreme Court was, if I remember right, the kind of stuff that would probably be vile enough to make the author of goatse.cx throw up, that is, pretty raw, hard core stuff. Curse words, like the F-word and such, would be considered "indecent" rather than "obscene," I believe.
"Don't try to cover up deficiencies by pretending that such possbilities don't exist."
In all fairness, I suspect that spohl figured that what was going on was happening intentionally, by design. It's not necessarily obvious what the problem is unless one peers into the contents of a package tarball.
"Maybe because a depending package with a greater version number might incorporate new features and design changes, which might cause the main package to break."
Except in this case that wasn't the problem. Like I said, the XFce binaries could make use of either version of esound.
The problem seems to be the way dependencies are specified in the package tarball. From the +CONTENTS file of the most recent FreeBSD (not the one that I tried, which was 4.1.1):
The dependencies for toolbox are especially telling, since Toolbox 0.4.6 was written well before Qt 2.2.1 existed, and not that long after Qt 2.0 came out.
What seems to be going on is that the package depends on a package with a particular name, such as grizzle-1.0.2, and the version number is hardcoded into the name of the package itself. So even though XFce could have used esound 0.2.20, the xfce-3.5.0 package itself specified a dependence specifically on the esound-0.2.17 package.
My guess is that if I had more experience with FreeBSD I could have worked around that limitation, but still, it's a limitation.
No, no, no. That's not what I was trying to say. The software binaries themselves, the ones for XFce in this case, could have used an up-to-date version of the esound library. The package info within the xfce-3.5.0 package, though, required the esound-0.2.17 package.
My point was that the package manager didn't seem to have a mechanism so that a package could specify a dependence on a package with a version number greater than or equal to a particular value, i.e. something that would let the xfce package specify a dependence on esound version 0.2.17 *or greater*.
One thing the FreeBSD packaging system seems to lack is a way for a package to depend on a package with a version greater than or equal to a particular version number. I noticed that, for example, package xfce-3.5.0 would depend on esound-0.2.17 exactly. esound-0.2.20 would not be satisfactory to the package manager, even though as far as the xfce binary was concerned, either version of esound would have worked. There also didn't seem to be a way to upgrade a package per se, aside from uninstalling the last version and then installing the newer version.
There may have been a way around those problems that I just missed, or a different way of handling things that I missed, but I couldn't find them.
I remember when I was using FreeBSD myself that the port of GTK+ 1.2 had gtk-config renamed to gtk12-config, and GTK+ 1.3 had gtk-config renamed to gtk13-config, in order that both versions of GTK+ could be on the system. Arguably, this is useful, but it's not standard for a GTK+ installation, so configure scripts and Makefiles that look for the standard-issue "gtk-config" don't work. The problem here is more a matter of the porter of GTK+ taking some liberties rather than the programmer of those napster-clones using Linux-isms.
Making a symlink "gtk-config" pointing to gtk12-config should solve the problem.
Depends on what one means by something "being a Unix."
If by "being a Unix," one means that the OS is an "official" Unix somehow, either by the OS code being based on the Unix code from AT&T, or by getting whatever certifications are necessary from the OSF, Open Group, etc., then the GNU/Linux combo is not a Unix.
If by "being a Unix," one means that the OS has Unix-style APIs and interfaces, then the GNU/Linux combo is definitely a Unix, the recursive acronym in GNU notwithstanding.
Sex in the Bible is not "bad." Adultery, yes. Fornication, yes. But sex? Let's see:
"God created humankind in his image, . . . *male* and *female* he created them" (Gen. 1:27, emphasis mine)
"Therefore a man leaves his father and mother and clings to his wife, and they become one flesh." (Gen. 2:24)
"How fair and pleasant you are,
O loved one, delectable maiden!
You are stately as a palm tree,
and your breasts are like its clusters.
I say I will climb the palm tree
and lay hold of its branches."
(Song of Solomon/Song of Songs 7:6-8)
May I remind you that the Israelite priests were a *hereditary* class, which is rather hard to accomplish without sex. Not even Paul, who is not exactly known for being pro-marriage, *ever* described sex as in itself somehow tainted. He discouraged marriage because it tended to promote divided interests rather than a single-minded focus on God (1 Cor. 7:32-33), yet even he had said that to marry is not sin (1 Cor. 7:28,36).
Considering sex to be bad in and of itself is not Biblical, and Christians or Jews who think sex is bad are not paying enough attention to their own Scriptures.
What about Qt itself? Trolltech had advised not to use gcc 2.96 or glibc 2.1.92 with Qt due to some troubles with how gcc 2.96 handles Qt's signals and slots. xI gather that you must have gotten Qt to compile, but I wonder though about the stability of Qt compiled with gcc 2.96.
"Why would they create a bill with such a narrow emphasis?"
A bill with a narrow emphasis probably has a better chance of getting passed. If it does get passed, it may provide leverage for further reform. Sometimes it's better to attack something piecemeal than all at once.
Slashdot Mirror
AFAIK, DFM is supposed to at least be inspired by the Workplace Shell. I can't say how good an imitation it is, since I haven't used OS/2, but I think it's supposed to be a partial imitation. DFM is available at http://dfm.online.de.
"However, in the US & other countries, the only way adults can get AIDS is by sharing drug needles or promiscuous/unprotected sex.
Careful here. Are you presuming that screening out of HIV-infected blood is 100% effective? Even if it is 99.9999% effective, that still leaves 0.0001%. If I were you, I'd be leery of presuming that there was absolutely no possibility of getting HIV from a blood transfusion.
"Therefore, I have absolutely no sympathy for adults in the US that get AIDS now as a result of their unhealthy behavior."
Ok, how about this scenario. Say a husband goes off on a business trip, has, um, an indiscretion, with someone who turns out to be infected with HIV, and unknowingly gets infected himself. Husband comes home and makes love to his wife, who in turn gets infected with HIV.
Now are you saying that you have no sympathy for the wife here? Would you honestly consider unprotected sex between husband and wife to be unhealthy or irresponsible behavior?
IIRC, it was *Sound Wave* that was the Decepticon tape deck. *Shockwave* transformed into a weapon.
"Both are free script language which more or less share the same goal: be a more readable Perl."
I can't speak for Ruby since I know little about it but the name, but I'd hardly call Python "a more readable Perl."
Perl is a language that was meant at the beginning to do jobs that were just out of reach of the sed, awk and shell--which is why Perl tends to resemble sed, awk and shell to a fair extent.
Python was meant to be a very clean, orderly language, which is why it has such features as using indentation for statement grouping, and can have something like "foo foo) and (x bar)". Readablity seems to be Python's reason for being.
I won't claim that either language is better than the other, but they strike me as thoroughly different in culture, lineage, and goals.
"to remove a program
/path/and/program_name.rpm"
rpm -e
Actually, it's just "rpm -e program_name"
IMHO, a better answer to "what the heck do I do with this linux driver on disk?" is to follow the instructions in the README or INSTALL file that came with it.
"If you want near-WYSIWYG editing tools, TeX/LaTeX is only a good choice if you stay in UNIX, since there are no good near-WYSIWYG editing tools (that I know of) for MAC, and perhaps not even for Windows."
For Windows, there's "Scientific Word" at http://www.mackichan.com/.
Actually, another difference is H&J--hyphenation & justification. Loosely speaking, TeX does its H&J by trying out different ways of breaking a paragraph into lines and filling it, assigning each way a "badness" score, and choosing the way with the least badness. The result is H&J that looks rather nice and seldom has ugly gaps between words or too many words scrunched together. WYSIWYG document processors do their H&J on the fly, which means they *can't* do things like try out different ways of breaking a paragraph and so on, so it doesn't always look as good.
"It seems these days that every document available from Gov't websites is available as Text, PDF, and WordPerfect. WordPerfect is available for Linux. I don't know about that for OpenBSD."
If OpenBSD's Linux emulation is anything like FreeBSD's, then running WordPerfect for Linux on OpenBSD wouldn't be a problem.
"It starts, 'Consider a world without copyright enforcement', which makes me think, great, someone has come up with what they think is a great idea, but is probably untested, or even been thoroughly debated."
The "Street Performer Protocol" is not a manifesto. It is a partial solution to the question of how to make money in a world where copyright is difficult to enforce.
When "Street Performer Protocol" says "Consider a world without copyright enforcement," it is not thinking of a utopia where copyright is banished on ethical grounds, a la the world as RMS would like to see it, but rather a world in which technology is making the flouting of copyright law so much easier that, right or wrong, enforcement of copyright is becoming more of an uphill struggle--a world which the real world resembles more and more nowadays.
BTW, this is *not* an undergraduate student's thesis. Take a look at the authors:
John Kelsey is a cryptographer at Counterpane Systems, co-designer of Twofish and Yarrow, and the author of dozens of academic papers on cryptography.
E-mail: kelsey@counterpane.com
Bruce Schneier is president of Counterpane Systems, the author of Applied Cryptography (John Wiley & Sons, 1994 & 1996), and an inventor of the Blowfish, Twofish, and Yarrow algorithms. He serves on the board of the International Association for Cryptologic Research, EPIC, and VTW. He is a contributing editor to Dr. Dobb's Journal, and a frequent writer and lecturer on cryptography. Counterpane Systems is a five-person consulting firm specializing in cryptography and computer security. Counterpane provides expert consulting in, design and analysis, implementation and testing, threat modeling, product research and forecasting, classes and training, intellectual property, and export consulting. Contracts range from short-term design evaluations and expert opinions to multi-year development efforts.
E-mail: schneier@counterpane.com
I suggest giving the paper a good read. It's fairly pragmatic and well-thought out.
"I think that it's fair to say that GNOME is approaching "critical mass" on the *u*x* desktop front. I myself use and prefer to use KDE2, but GNOME looks like it will just have the numbers."
Maybe yes, maybe no. I highly doubt that we will know which desktop will become the most popular until it happens, if it happens. Remember, Sun is waiting until GNOME 2.0 comes out before it starts putting it on its machines, which will be quite some time from now, at least a year. A lot can happen in a year. Wait and see.
That depends on what one wants to do with the GPL'd software in question. If the idea is to try to make money directly from GPL'd software, then one may have a problem. If however, one is trying to create a standard software infrastructure on which to build that everyone holds in common, then GPL'd and LGPL'd software is a good way to go. The latter seems to be Sun is going.
"The week you spend playing Bard's Tale is one week of delayed revenues for Ultima 2001 Pro Special Gold Edition"
Not necessarily. That assumes that those who play the older games would want to play the newer ones. To some extent, that also assumes that the newer games are even comparable to the older ones, which may not be the case if the older games are of different genres, have different rules, different feel, etc.
The main problem with Lout is that while it is easy to customize section headings, Lout is rigid about where things like prefaces, tables of contents, or indices go. I can't choose in a Lout document whether the table of contents will be before or after the preface, or even whether to put the table of contents in the back (which is a common practice in some countries). The "report" document format in Lout will repeat the lines in the title page at the top of the first page of the report. I've found that I've ended up needing to use the "book" format for maximum flexibility.
IMHO, I find it kind of sad that rigidity in some aspects of Lout frustrates the usefulness of the customizability of other aspects. If Lout lost some of that rigidity and gained a way to do bold Greek fonts without teq (maybe via an overstriking command like eqn's "fat"?) it would be just the slightest bit superior than TeX/LaTeX, IMHO.
"I also agree that it would be nice to have things like named variables instead of \count0 ... "
Plain TeX uses \pageno as an alias for \count0.
LaTeX if I remember right uses \thepage.
BTW, \pageno is buried in the back of the TeXBook, so I can understand you not knowing about it.
"Exactly, Shakespeare quotes it best in Hamlet:
"Nothing is good or bad, but thinking makes it so". (it's a paraphrase, too lazy to find it on the web)
Everyone has different morals, and no-one should ever be subject, against their will, to someone else's morals or beliefs."
Careful here. You basically leapt from the premise that "you will always have debates about degrees of rightness or wrongness" to the conclusion that "Nothing is good or bad."
There is a vast difference between saying that the line between right and wrong is fuzzy, and saying that it doesn't exist at all.
The ruling was that "indecent" expression is protected while "obscene" is not, and what was considered "obscene" by the Supreme Court was, if I remember right, the kind of stuff that would probably be vile enough to make the author of goatse.cx throw up, that is, pretty raw, hard core stuff. Curse words, like the F-word and such, would be considered "indecent" rather than "obscene," I believe.
"Don't try to cover up deficiencies by pretending that such possbilities don't exist."
In all fairness, I suspect that spohl figured that what was going on was happening intentionally, by design. It's not necessarily obvious what the problem is unless one peers into the contents of a package tarball.
I don't think he was "pretending" anything.
"Maybe because a depending package with a greater version number might incorporate new features and design changes, which might cause the main package to break."
/usr/X11R6
/usr/X11R6
Except in this case that wasn't the problem. Like I said, the XFce binaries could make use of either version of esound.
The problem seems to be the way dependencies are specified in the package tarball. From the +CONTENTS file of the most recent FreeBSD (not the one that I tried, which was 4.1.1):
@name xfce-3.5.2
@cwd
@pkgdep xpm-3.4k
@pkgdep tiff-3.5.5
@pkgdep png-1.0.8_1
@pkgdep libungif-4.1.0b1
@pkgdep libaudiofile-0.1.9
@pkgdep jpeg-6b
@pkgdep imlib-1.9.8.1
@pkgdep gtk-1.2.8
@pkgdep glib-1.2.8
@pkgdep gettext-0.10.35
@pkgdep esound-0.2.20
Or the +CONTENTS file from the latest package of toolbox-0.4.6 (a configuration tool for Blackbox 0.5x.x)
@name toolbox-0.4.6
@cwd
@pkgdep qt-2.2.1
@pkgdep png-1.0.8_1
@pkgdep jpeg-6b
@pkgdep Mesa-3.2.1_1
The dependencies for toolbox are especially telling, since Toolbox 0.4.6 was written well before Qt 2.2.1 existed, and not that long after Qt 2.0 came out.
What seems to be going on is that the package depends on a package with a particular name, such as grizzle-1.0.2, and the version number is hardcoded into the name of the package itself. So even though XFce could have used esound 0.2.20, the xfce-3.5.0 package itself specified a dependence specifically on the esound-0.2.17 package.
My guess is that if I had more experience with FreeBSD I could have worked around that limitation, but still, it's a limitation.
No, no, no. That's not what I was trying to say. The software binaries themselves, the ones for XFce in this case, could have used an up-to-date version of the esound library. The package info within the xfce-3.5.0 package, though, required the esound-0.2.17 package.
My point was that the package manager didn't seem to have a mechanism so that a package could specify a dependence on a package with a version number greater than or equal to a particular value, i.e. something that would let the xfce package specify a dependence on esound version 0.2.17 *or greater*.
One thing the FreeBSD packaging system seems to lack is a way for a package to depend on a package with a version greater than or equal to a particular version number. I noticed that, for example, package xfce-3.5.0 would depend on esound-0.2.17 exactly. esound-0.2.20 would not be satisfactory to the package manager, even though as far as the xfce binary was concerned, either version of esound would have worked. There also didn't seem to be a way to upgrade a package per se, aside from uninstalling the last version and then installing the newer version.
There may have been a way around those problems that I just missed, or a different way of handling things that I missed, but I couldn't find them.
I remember when I was using FreeBSD myself that the port of GTK+ 1.2 had gtk-config renamed to gtk12-config, and GTK+ 1.3 had gtk-config renamed to gtk13-config, in order that both versions of GTK+ could be on the system. Arguably, this is useful, but it's not standard for a GTK+ installation, so configure scripts and Makefiles that look for the standard-issue "gtk-config" don't work. The problem here is more a matter of the porter of GTK+ taking some liberties rather than the programmer of those napster-clones using Linux-isms.
Making a symlink "gtk-config" pointing to gtk12-config should solve the problem.
Depends on what one means by something "being a Unix."
If by "being a Unix," one means that the OS is an "official" Unix somehow, either by the OS code being based on the Unix code from AT&T, or by getting whatever certifications are necessary from the OSF, Open Group, etc., then the GNU/Linux combo is not a Unix.
If by "being a Unix," one means that the OS has Unix-style APIs and interfaces, then the GNU/Linux combo is definitely a Unix, the recursive acronym in GNU notwithstanding.
Sex in the Bible is not "bad." Adultery, yes. Fornication, yes. But sex? Let's see:
"God created humankind in his image, . . . *male* and *female* he created them" (Gen. 1:27, emphasis mine)
"Therefore a man leaves his father and mother and clings to his wife, and they become one flesh." (Gen. 2:24)
"How fair and pleasant you are,
O loved one, delectable maiden!
You are stately as a palm tree,
and your breasts are like its clusters.
I say I will climb the palm tree
and lay hold of its branches."
(Song of Solomon/Song of Songs 7:6-8)
May I remind you that the Israelite priests were a *hereditary* class, which is rather hard to accomplish without sex. Not even Paul, who is not exactly known for being pro-marriage, *ever* described sex as in itself somehow tainted. He discouraged marriage because it tended to promote divided interests rather than a single-minded focus on God (1 Cor. 7:32-33), yet even he had said that to marry is not sin (1 Cor. 7:28,36).
Considering sex to be bad in and of itself is not Biblical, and Christians or Jews who think sex is bad are not paying enough attention to their own Scriptures.
What about Qt itself? Trolltech had advised not to use gcc 2.96 or glibc 2.1.92 with Qt due to some troubles with how gcc 2.96 handles Qt's signals and slots. xI gather that you must have gotten Qt to compile, but I wonder though about the stability of Qt compiled with gcc 2.96.
Any further info?
"Why would they create a bill with such a narrow emphasis?"
A bill with a narrow emphasis probably has a better chance of getting passed. If it does get passed, it may provide leverage for further reform. Sometimes it's better to attack something piecemeal than all at once.