Re: Returned Mail
Hi, On Fri, Aug 22, 2003 at 09:33:37PM +1000, Brian May wrote: On Fri, Aug 22, 2003 at 11:51:29AM +0200, Goswin von Brederlow wrote: That usually contains the original message as attachment so your virus filter should catch and destroy those. :) Actually I got one such message where amavisd-new/clamav didn't detect anything wrong. LATER: I see why, the MTA doing the bounce quoted the entire message as ASCII text, so amavisd didn't realize that it contained a encoded binary attachment. Oh well, I guess the virus wouldn't exactly be able to do much damage in this form anyway (even if I did use Outlook)... Let me see what MTA doesn't support bouncing MIME attachments properly... Should have guessed: qmail. That's not a bug, that's a feature! I think it's excellent that these bounces don't have the full message, but show only the first few kB, in a way that breaks the message's MIME structure well and thoroughly. After bouncing, at least a virus can't take advantage of the abysmal Outlook (Express) HTML and MIME handling anymore -- the source of at least 95% of the world's virus problems. Cheers, Emile. -- E-Advies - Emile van Bergen [EMAIL PROTECTED] tel. +31 (0)70 3906153 http://www.e-advies.nl
Re: About NM and Next Release
Hi, On Fri, Aug 08, 2003 at 12:08:38AM +0100, Andrew Suffield wrote: Anybody who has to ask Why should I/we/they contribute? is not suitable for Debian. (The answer, incidentally, is because we can or because it's there, or some other variation; it is a goal in itself, and not a means to an end) I've heard our respected project secretary express a vastly different opinion on this matter. Cheers, Emile. -- E-Advies - Emile van Bergen [EMAIL PROTECTED] tel. +31 (0)70 3906153 http://www.e-advies.nl
Re: About NM and Next Release
Hi, On Fri, Aug 08, 2003 at 07:34:26PM +0100, Andrew Suffield wrote: altruim, [sic] Self-delusion. (It's invariably a form of 'By doing this I can better fit the sort of person I would like to think I am'. People who disagree with this interpretation are probably committing it. Get out of that if you can!) Oh true master, please tell us how you obtained your great wisdom and enlighten us, pityable souls. Cure us from our delusional hopes of transcending the slavery to our perceived self interests through the idea of freedom of choice. We will be eternally grateful. Or at least entertained. Cheers, Emile. -- E-Advies - Emile van Bergen [EMAIL PROTECTED] tel. +31 (0)70 3906153 http://www.e-advies.nl
Re: About NM and Next Release
Hi, On Fri, Aug 08, 2003 at 11:39:25PM +0100, Andrew Suffield wrote: On Fri, Aug 08, 2003 at 09:38:43PM +0200, Emile van Bergen wrote: On Fri, Aug 08, 2003 at 07:34:26PM +0100, Andrew Suffield wrote: altruim, [sic] Self-delusion. (It's invariably a form of 'By doing this I can better fit the sort of person I would like to think I am'. People who disagree with this interpretation are probably committing it. Get out of that if you can!) Oh true master, please tell us how you obtained your great wisdom and enlighten us, pityable souls. Two pounds of flax. Most revered guru, I did not ask, What is the Buddha, nor are you Joshu. I am seeking the source of your profound teaching, that no act of man can come from altruism or compassion, but that the one true motive is to serve the ego, and that all man does is invariably means to this end. -- E-Advies - Emile van Bergen [EMAIL PROTECTED] tel. +31 (0)70 3906153 http://www.e-advies.nl
Re: How to install X-Chat in five hours (or more)
Hi, On Tue, Aug 05, 2003 at 03:15:59PM -0700, Steve Lamb wrote: On Tue, 5 Aug 2003 21:38:19 +0200 Emile van Bergen [EMAIL PROTECTED] wrote: Apple has a great way of doing that. They don't dumb down, they don't belittle you, they assume an intelligent being who can grasp reasonably complex English sentences, but who has less knowledge of computer idiom. *blink, blink* Funny, I consider Apple on of the worst when it comes to dumbing down the interface. Let's not forget they only took about 10 years to get *2* mouse buttons because it was too confusing. To each his own mistakes. The point is that they seem to succeed relatively often in creating messages and dialogues that are both informative to the knowledgeable user and intelligible to a non-computer savvy person. Cheers, Emile. -- E-Advies - Emile van Bergen [EMAIL PROTECTED] tel. +31 (0)70 3906153 http://www.e-advies.nl
Re: How to install X-Chat in five hours (or more)
Hi, On Tue, Aug 05, 2003 at 11:06:53PM +0200, Tollef Fog Heen wrote: * Emile van Bergen | Hi, | | On Tue, Aug 05, 2003 at 10:19:53AM -0700, Ian Hickson wrote: | | And I would scream if you called it /_My_ Variable Data/ too... :-P | | I would even scream at | | /Variable Data/ | | simply because it encourages slow and RSI-inducing click and drag | behaviour, because such path names are impossible to type in (and this | one even requires escaping the space to distinguish between the argument | separator). Tab completion or using /Va* is about as fast as /var. I've considered tab-completion and /Va*, but you must realise that they work only in the shell. Neither tab-completion or globbing is available when I'm editing a file and have to write those path names. There are lots of other cases where you must type a pathname in full. scp (on the remote side) is one that's important. /Va* further has the problem of requiring two awkward shifts. [SNIP] Geeks use systems a lot and for long periods of time, so using more or less obscure interfaces is good, not bad for us. :) I think that we prefer interfaces are ultimately very fast and are willing to live the learning curve and obscurity that currently comes with it. There may be an inherent tradeoff, but I think that we shouldn't be too quickly in dismissing UI changes that improve the linearity of the learning curve, if they can be shown not to harm the efficiency at the end of the curve. Of course, any change that actually shifts the balance from convenience for the frequent user towards ease of use for the incidental user should IMHO be treated with a lot more scepsis -- if not outright rejected. Cheers, Emile. -- E-Advies - Emile van Bergen [EMAIL PROTECTED] tel. +31 (0)70 3906153 http://www.e-advies.nl
Re: Should MUA only Recommend mail-transfer-agent?
Hi,
On Wed, Aug 06, 2003 at 03:03:07PM +0200, Bernhard R. Link wrote:
* Steve Lamb [EMAIL PROTECTED] [030806 13:43]:
On Wed, 6 Aug 2003 13:10:03 +0200
Bernhard R. Link [EMAIL PROTECTED] wrote:
If mutt spoke SMTP, it would be a MTA itself. (Perhaps still missing
the proper interface to link /usr/lib/sendmail to mutt, but that would
be the lesser part).
No, it would not. It would be using another method of accessing an
MTA.
Just because Mozilla speaks HTTP, HTTPS and FTP doesn't make it a web
server,
a secure web server and an ftp server.
Perhaps we disagree what MTA means. I consider for example ssmpt to be a
MTA. (And judging from the package-description, it's maintainer seems
to believe the same).
So netscape and pine, both of which contain an SMTP /client/, are MTAs??
Your definition does not seem to be shared by many people then.
Generally, an MTA is able to do the MX lookup, has a queue, and a few
methods of injecting messages into that queue, perhaps via
/usr/lib/sendmail -t or through SMTP.
I would not consider anything that contains a SMTP client an MTA. A
proxy that handles port 25 is no MTA either. Such strict definitions
('talks SMTP') are generally not very useful.
Cheers,
Emile.
--
E-Advies - Emile van Bergen [EMAIL PROTECTED]
tel. +31 (0)70 3906153 http://www.e-advies.nl
Re: Should MUA only Recommend mail-transfer-agent?
Hi, On Wed, Aug 06, 2003 at 04:36:36PM +0200, Eduard Bloch wrote: #include hallo.h * Bernhard R. Link [Wed, Aug 06 2003, 03:03:07PM]: * Steve Lamb [EMAIL PROTECTED] [030806 13:43]: On Wed, 6 Aug 2003 13:10:03 +0200 Bernhard R. Link [EMAIL PROTECTED] wrote: If mutt spoke SMTP, it would be a MTA itself. (Perhaps still missing the proper interface to link /usr/lib/sendmail to mutt, but that would be the lesser part). No, it would not. It would be using another method of accessing an MTA. Just because Mozilla speaks HTTP, HTTPS and FTP doesn't make it a web server, a secure web server and an ftp server. Perhaps we disagree what MTA means. I consider for example ssmpt to be a MTA. (And judging from the package-description, it's maintainer seems to believe the same). In other words I demand beeing able so send a mail somewhere. (Which includes speaking SMTP, if one wants to reach arbitrary hosts). But your statement was wrong, please reread it. MTA term (for my judgement) implies some program which emulates the sendmail command to send Email (and mutt does not, AFAIK, even if it can accept mail body from stdin) to other hosts and to local users, while the local part of the transport may also be implemented on the smarthost, eg. sharing /var/mail directory and the user database some other system which also acts as the ssmtp's smarthost. You're right, it /is/ a hot day. Sorry. I agree with your definition. Cheers, Emile. -- E-Advies - Emile van Bergen [EMAIL PROTECTED] tel. +31 (0)70 3906153 http://www.e-advies.nl
Re: How to install X-Chat in five hours (or more)
Hi, On Tue, Aug 05, 2003 at 09:55:59AM -0700, Ian Hickson wrote: [SNIP] Why can't we instead have nice friendly messages? e.g.: Startup logging has begun. Log will be stored in '/var/log/boot'. ...instead of bootlogd. [SNIP] Error messages are there for people who know what they need to do. So if I do something wrong (like get the command line arguments to 'apt-get' wrong, as I did), then I don't deserve to be helped by the program? What would be wrong with a helpful message, such as: apt-get: the first argument should be one of 'install', 'remove', 'update', or another operation ...instead of just E: Invalid operation foo? [SNIP] How about a message such as: dselect: to select an installation source, superuser privileges are required (try logging in as root) It's still accurate, but now it's helpful as well, and uses a more friendly voice. (This also changes access method to installation source, which makes more sense to me.) You know, I think these are actually good suggestions. I think there's a lot to be gained *not* by dumbing down, *not* by losing any information that might be useful to a geek or to a new user as (s)he's learning, but by phrasing texts so that they appeal more to generally intelligent human beings, rather than to people that just happen to have some specific knowledge. Apple has a great way of doing that. They don't dumb down, they don't belittle you, they assume an intelligent being who can grasp reasonably complex English sentences, but who has less knowledge of computer idiom. I think this is an area in which software can be improved without scaring the geeks with offensive 'my first Sony' UIs, teletubby landscapes, informationless error messages, and stupid attempts to fix things behind the users back (simply displaying expired pages from a cache for instance). Indeed, Microsoft gets it all wrong, from a UI standpoint. But instead of assuming that we are pushed in that scary direction when someone complains about our UI, we may also realise that there are things that can actually be improved, without harming Unix's strong points, UI-wise. I fully agree with the poster that increasing the number of intelligent and intelligible English sentences that we output is one of those things that can be done without harming the hacker in any way. Of course, like any enhancement, it needs a volunteer who can scratch his or her itch by doing this work. This may actually be one of the bigger problems. Most developers who can do the work have gotten used to the idiom and badly worded error messages. Cheers, Emile. -- E-Advies - Emile van Bergen [EMAIL PROTECTED] tel. +31 (0)70 3906153 http://www.e-advies.nl pgprXSw5bIZGU.pgp Description: PGP signature
Re: How to install X-Chat in five hours (or more)
Hi,
On Tue, Aug 05, 2003 at 10:19:53AM -0700, Ian Hickson wrote:
And I would scream if you called it /_My_ Variable Data/ too... :-P
I would even scream at
/Variable Data/
simply because it encourages slow and RSI-inducing click and drag
behaviour, because such path names are impossible to type in (and this
one even requires escaping the space to distinguish between the argument
separator).
Don't underestimate the typing convenience of TLAs! They may not be the
most descriptive, but at least they're blindingly fast to work with when
you get used to it.
In short, such path names are definitely no improvement from a UI
standpoint, even though it may seem that way from a casual observer.
Even shorter: UIs are rarely obvious. And there must be a reason why
geeks like working with Unix.
One thing for me is that the command line allows me to work almost as
quickly as I think. I really hate it when the UI drags me down ('open
folder, open subfolder, click on file, type Ctrl-C, open other folder,
type Ctrl-V', it's just horrible). The computer should wait for me, not
the other way around!
Cheers,
Emile.
--
E-Advies - Emile van Bergen [EMAIL PROTECTED]
tel. +31 (0)70 3906153 http://www.e-advies.nl
pgpX3JoSsrW5E.pgp
Description: PGP signature
Re: Bug#203498: ITP: decss -- utility for stripping CSS tags from an HTML page.
Hi, On Wed, Jul 30, 2003 at 12:01:29PM -0500, Steve Langasek wrote: On Wed, Jul 30, 2003 at 12:48:55PM -0400, Jim Penny wrote: On Wed, 30 Jul 2003 11:38:12 -0500 Steve Langasek [EMAIL PROTECTED] wrote: On Wed, Jul 30, 2003 at 05:56:32PM +0200, Emile van Bergen wrote: I object to this ITP. Not very strongly, but I still object. I think it's a wonderful idea to have a decss package in Debian. If Debian cannot distribute the decss that allows Debian users to view DVD movies (yet), then distributing this one is a good alternative, I'd say. You're clearly quite mad. Regardless of whether this script is trivial to implement, it's not something anyone should be encouraged to actually*use*. CSS is the *best* feature of the HTML4 standard. Why would anyone in their right mind wish to strip nearly all the logical structure markup out of a document? Uhh, it is to tweak the international copyright cartel, and the RIAA in particular. They have written cease and desist letters to anyone who has a file names deCSS on their system. This is an attempt to make such a filename so common that these letters are pointless, and possibly evidence of illegal activity. If the intent is *only* as a political tool, I would agree that this decss program achieves its aims fairly effectively; but it is in no way a useful piece of *software*, which is what Emile seems to be arguing by disagreeing that it's trivial to implement. The question then is whether we want to include programs in Debian which are useful only as something other than software. I'm not arguing that it isn't almost trivial, I'm arguing that it's non-trivial enough to put in a shell script (at least I would if I'd be performing the operation regularly). Whether it deserves a Debian package has little to do with that, of course. It's much more useful as a political tool if it is at least somewhat useful as a software tool. A file containing some output of /dev/random called decss would be less effective. I see packaging as a good protest that we cannot package the real decss, which would definitely be a candidate for a debian package, as it is required to watch DVDs using DFSG-free software. As soon as we can package the real thing, we should probably rename the HTML/CSS decss as decss-html and release the real decss using a new epoch. The principle is horrible, but in this case I think the confusion would be minimal. Cheers, Emile. -- E-Advies - Emile van Bergen [EMAIL PROTECTED] tel. +31 (0)70 3906153 http://www.e-advies.nl
Re: Bug#203498: ITP: decss -- utility for stripping CSS tags from an HTML page.
Hi, On Wed, Jul 30, 2003 at 04:56:15PM +0200, Sam Hocevar wrote: On Wed, Jul 30, 2003, Keith Dunwoody wrote: * Package name: decss Like that won't be a confusing package name. ;-p If you read the website, that was the point ;) And what is the point of confusing our users and cluttering the package/ executable namespace with a useless program that could be replaced with a sed one-liner? Cluttering the namespace? The name isn't very generic, I'd say. A moderately complex sed one-liner is probably all that's needed, but to have it in a file is nice. If it's so easy to type in, I'd have expected it in your response. I object to this ITP. Not very strongly, but I still object. I think it's a wonderful idea to have a decss package in Debian. If Debian cannot distribute the decss that allows Debian users to view DVD movies (yet), then distributing this one is a good alternative, I'd say. Cheers, Emile. -- E-Advies - Emile van Bergen [EMAIL PROTECTED] tel. +31 (0)70 3906153 http://www.e-advies.nl
Re: Bug#203498: ITP: decss -- utility for stripping CSS tags from an HTML page.
Hi, On Wed, Jul 30, 2003 at 11:38:12AM -0500, Steve Langasek wrote: On Wed, Jul 30, 2003 at 05:56:32PM +0200, Emile van Bergen wrote: I object to this ITP. Not very strongly, but I still object. I think it's a wonderful idea to have a decss package in Debian. If Debian cannot distribute the decss that allows Debian users to view DVD movies (yet), then distributing this one is a good alternative, I'd say. You're clearly quite mad. Regardless of whether this script is trivial to implement, it's not something anyone should be encouraged to actually *use*. CSS is the *best* feature of the HTML4 standard. Why would anyone in their right mind wish to strip nearly all the logical structure markup out of a document? CSS is not the logical structure, it provides hints about the rendering of the logical structure as given by the HTML tags. Cheers, Emile. -- E-Advies - Emile van Bergen [EMAIL PROTECTED] tel. +31 (0)70 3906153 http://www.e-advies.nl
Re: [Debian-au] Debian 10th birthday gear
Hi, On Sun, Jul 13, 2003 at 12:06:03AM -0500, Branden Robinson wrote: Anybody else get a bad cryptographic signature on the message to which I am replying? AOL. -- E-Advies - Emile van Bergen [EMAIL PROTECTED] tel. +31 (0)70 3906153 http://www.e-advies.nl
Re: the RFC mess: tentative summary
Hi, On Sun, Jul 13, 2003 at 12:03:22PM +0100, Andrew Suffield wrote: On Sun, Jul 13, 2003 at 12:17:50PM +0200, Martin Quinson wrote: Answer 1: Nobody asked the right to change the content of the file RFC23423.txt and distribute it as is. This would clearly be wrong and it would be ok to ask for a file rename, for a clear notice changes ^^^ Ask, yes. Require in the license, no. This was established during the LPPL dissection. Contrived example: I have an application that uses rfc23423.txt as input data (reading a table or something), and it is prohibitively difficult to change the filename it looks for. Contrived, indeed. Especially since we should not create our criteria for documentation and standards licenses to especially accomodate non-free software that cannot be modified to accept a different file name. Also, the clause is about appropriately identifying a file as such when distributing a modified copy. No perverse combination of law and license should be able prevent you from installing it on your own system under a file name of your choice. Cheers, Emile. -- E-Advies - Emile van Bergen [EMAIL PROTECTED] tel. +31 (0)70 3906153 http://www.e-advies.nl
Re: Please remove RFCs from the documentation in Debian packages
Hi, On Thu, Jul 03, 2003 at 02:17:29PM -0500, Steve Langasek wrote: On Thu, Jul 03, 2003 at 01:42:01PM -0500, Joshua Haberman wrote: * Branden Robinson ([EMAIL PROTECTED]) wrote: On Thu, Jul 03, 2003 at 03:38:18PM +0200, Marco d'Itri wrote: On Jul 03, Petter Reinholdtsen [EMAIL PROTECTED] wrote: I believe this whole case of RFC standards are not confirming to The Debian Free Software Guidelines display a complete lack of understanding of the value of standards, and should be rejected. Standards are not software, nor software manuals, and should not be treated as such. I fully agree. Banning RFCs from debian is just silly. So, what other non-DFSG-free stuff is it silly to ban? Netscape Navigator? Adobe Acrobat Reader? Keep in mind that this hard-line stance of applying the DFSG to everything in the archive will probably make it more difficult to gain support for the non-free removal resolution. I think our commitment to providing a distribution consisting exclusively of material whose license complies with the freedoms outlined in the DFSG is far more important than the question of whether we continue to distribute non-free alongside. If we are going to allow documentation into main that follows a different set of rules than the ones we use for software, the Social Contract must be amended to unambiguously reflect this point of view. Otherwise, how are redistributors and users supposed to know where the line is between stuff-that's-really-free and stuff-that's-not-free-but-included-anyway? Why not indeed traft a DFDG spec that includes licenses such as the GFDL and IETF's and W3C's licenses, as someone suggested, and add a separate 'Documentation' section? Things that are DFDG-free but not DFSG-free thus remain outside main, and because these things have licenses that conform to a set of defined requirements, it should conflict even less with the Social Contract than the non-free section does. So, no need for amendmends. Really, DFSG has done a lot of good. I can see a similar benefit in harmonizing the various documentation licenses, that serves Free Software and Our Users. Free Software is definitely served by standards and documentation, and convenient off line access to them. Cheers, Emile. -- E-Advies - Emile van Bergen [EMAIL PROTECTED] tel. +31 (0)70 3906153 http://www.e-advies.nl
Re: but I want the GNU versions of packages
Hi, On Tue, Jul 01, 2003 at 10:55:44AM +0800, Dan Jacobson wrote: what's the point? Surely you want the best, not necessarily the GNU version (which might be an incredibly bleeding-edge pre-alpha thing, like for example mailutils was not so long ago)? OK, let's just say I like the GNU guys and would like them to know if there are any bugs in their stuff, otherwise how will it improve? And mawk: development halted years ago. Wouldn't any awk bugs I find be better reported for gawk? So, how does one find the rest of the packages on one's system that Conflicts: with genuine GNU alternative packages. From the tone of your message, I bet there are lots that you fellows have pre-chosen for us new debian users. So far I have discovered mawk, and mailx. So, out with it, what are the rest? There seems to be a classic misunderstanding here. Debian GNU/Linux is not a distribution of the GNU system. People seem to think it is, and that's not too strange, actually. If you try to search for a more or less canonical GNU distribution, you're quite likely to find Debian. Debian is an operating system in its own right, which happens contains a lot of GNU tools, the Linux kernel, and lots of other Free Software, all assembled primarily to suit the users (including the Debian developers packaging it), and much less the original developers of the software. More specifically, Debian does not intend to build an implementation of an abstract system that's more or less defined elsewhere, such as GNU. Debian intends to build the universal operating system, in whatever way that pleases its developers, as long as they keep in harmony with the Social Contract (Debian will remain 100 % Free Software, Our priotities are Our Users and Free Software), the Constitution, and Policy. Debian does not exist to serve the GNU project, although it may help GNU. It exists because it pleases its developers, and serves its users and Free Software. It happens to be that in a lot of cases, the GNU tools are the best tools to build Debian, and this fact is recognised in the name of the distribution. But it doesn't go much further than that. I do agree that a virtual package that depends and conflicts in such a way that selecting it will leave a system that looks as much as possible like the GNU system, containing as few as possible non-GNU tools, would be a nice idea. It's probably the easiest way to allow Debian to be the working system that's closest to GNU. Why should the universal operating system not fit that niche as well? It just needs someone to do it. Since you brought it up and seem to feel passionately about the issue, you're probably the best candidate to create such a package. HTH, Emile. -- E-Advies - Emile van Bergen [EMAIL PROTECTED] tel. +31 (0)70 3906153 http://www.e-advies.nl pgpj0yHadjySe.pgp Description: PGP signature
Re: Bug#198158: architecture i386 isn't i386 anymore
Hi, On Thu, Jun 26, 2003 at 09:04:55AM -0400, David B Harris wrote: On Wed, 25 Jun 2003 14:04:54 -0500 Gunnar Wolf [EMAIL PROTECTED] wrote: And not only 80386 needs this - There is the Sparc64 port which would also benefit from this (http://www.debian.org/ports/sparc/#64bit). If we had support for subarchtectures, not only would the ix86 mess be able to be split in many flavors (i.e. strict 386, 486 and up, 686, or whatever you fancy). And I am sure this can somehow help maintain the non-Linux ports - NetBSD gives us the potential to bring Debian to _many_ new platforms. No it doesn't. I've yet to even hear of an architecture that NetBSD runs on but which Linux doesn't. They just have a different definition of architecture than us. (ie: our hppa may be three or four arches to the NetBSD kernel folk.) Turbochannel machines? VAXen? Cheers, Emile. -- E-Advies - Emile van Bergen [EMAIL PROTECTED] tel. +31 (0)70 3906153 http://www.e-advies.nl
Re: Bug#198158: architecture i386 isn't i386 anymore
Hi, On Wed, Jun 25, 2003 at 01:07:12PM +0200, Tollef Fog Heen wrote: * Colin Walters | On Wed, 2003-06-25 at 03:52, Branden Robinson wrote: | | I believe it would be a mistake to kill off support for the 80386 chip. | | Well, we're limited by what we can sanely support. After all, we don't | support running Debian on a 286. The 386 is really in the same class | nowadays, in my opinion anyways. 386 has protected mode, 286 doesn't. That makes a bit of a difference. It does. It's just that the 286 is a 16-bit CPU and its protected mode MMU mode offers only segmentation, no paging. Cheers, Emile. -- E-Advies - Emile van Bergen [EMAIL PROTECTED] tel. +31 (0)70 3906153 http://www.e-advies.nl
Re: Bug#198602: ITP: debbackup -- Backup and restore Debian specifics (package status, conffiles)
Hi, On Tue, Jun 24, 2003 at 11:44:51AM -0500, Adam Heath wrote: On Tue, 24 Jun 2003, Daniel Stone wrote: Package: wnpp Version: unavailable; reported 2003-06-24 Severity: wishlist * Package name: debbackup Version : 0.1 Upstream Author : Daniel Stone [EMAIL PROTECTED] * URL : http://www.trinity.unimelb.edu.au/~dstone/debbackup/ (not functional yet) * License : GPL Description : Backup and restore Debian specifics (package status, conffiles) debbackup is a supplemental, Debian-specific, backup program. It backs up only what is needed to restore from a fresh install, with data recovered - package information (including holds/etc), conffile changes, Debconf information, and more. debrestore will restore this information - installing/updating required packages, restoring configuration files, and more. Tell me when you upload this, so I can file an rc bug against it, for modifying other packages conffiles. *g* 5 serious replies already -- sorry Adam, I'm afraid there are just too many people that lack even the most basic sense of humour. Cheers, Emile. -- E-Advies - Emile van Bergen [EMAIL PROTECTED] tel. +31 (0)70 3906153 http://www.e-advies.nl pgpeChrcNkxJV.pgp Description: PGP signature
Re: Bug#197907: ITP: quark -- an audio player, for geeks, by geeks.
Hi, On Wed, Jun 18, 2003 at 10:54:11AM -0500, Steve Langasek wrote: On Wed, Jun 18, 2003 at 05:39:40PM +0200, Sam Hocevar wrote: On Wed, Jun 18, 2003, Steve Langasek wrote: Ugh. Since when does the developer's reference recommend this? The article most definitely belongs... It is in 6.2.2: Since the synopsis is a clause, rather than a full sentence, we recommend that it neither start with a capital nor end with a full stop (period). It should also not begin with an article, either definite (the) or indefinite (a or an). It might help to imagine that the synopsis is combined with the package name in the following way: package-name is a synopsis. Grammatically, the article is part of the clause. This recommendation is inconsistent. Since the synopsis is part of a clause... would probably be better, sure. Also, package name contains synopsis could be suggested as a template, see descriptions such as header files for package xyz or ABC support files, development files, KDE core applications, etc. But in any case, no article seems to be the norm: $ grep '^Description:' /var/lib/dpkg/available | wc -l 9025 $ grep '^Description: [Aa][n ]' /var/lib/dpkg/available | wc -l 1163 at least on woody, with just a few small extra repositories. The lowercase recommendation seems much less followed: $ grep '^Description: [A-Z]' /var/lib/dpkg/available | wc -l 7661 $ grep '^Description: [a-z]' /var/lib/dpkg/available | wc -l 1262 Cheers, Emile. -- E-Advies - Emile van Bergen [EMAIL PROTECTED] tel. +31 (0)70 3906153 http://www.e-advies.nl
Re: Debian for x86-64 (AMD Opteron) and migration?
Hi, On Mon, Jun 16, 2003 at 07:33:35AM +0200, Xavier Roche wrote: Then, a nice thing would be on Debian, for a regular user/administrator: - switch the disks to a Opteron box - update the APT sources to a Opteron source, or to a Opteron migration source - then, use something like : apt-get install base-64 to install the essential system files for 64-bit apt-get install libc6-64 .. essential libraries and elements for 64-bit code apt-get kernel-image..-64 64-bit kernel for Opteron I'm not sure that all remarks are wise, but I did not see this (migration) point clearly emerging from the Debian for x86-64 (AMD Opteron) previous discussion Well, to some extent is was mentioned in the subthread by Wichert about dpkg being changed to allow multiple architectures at the same time, so that it's a matter of # echo x86-64 /etc/dpkg/legal-archs or, if ordering matters, # echo x86-64 /etc/dpkg/legal-archs.new # cat /etc/dpkg/legal-archs /etc/dpkg/legal-archs.new # mv /etc/dpkg/legal-archs.new /etc/dpkg/legal-archs and suddenly an # apt-get install fvwm2 will fetch pool/main/f/fvwm/fvwm_2.4.6-2_x86-64.deb from the archive, and pull in packages such as lib64c6, lib64readline4, lib64gtk1.2. In this example, only one version (32 or 64 bit) of an application such as fvwm can exist on the system (package name is the same, only architecture field is different), whereas both libreadline4 and lib64readline4 can exist (package name is different too, and one installs its files in /usr/lib, the other in /usr/lib64 as per the AMD64 ABI). Of course, this may be different for other programs, which do require the '64' in the package name because some other program explicitly depends on a 64 bit version. But in general, this will only be true for libraries because they go in the same address space. Interfaces between programs and other programs will hopefully mostly be 64-bit clean. The biggest objection that was raised is that it will be necessary to make the source package for libreadline4 generate two packages, libreadline4 and lib64readline4. Same for all other libraries. IOW, there's no automatic way to create all these lib64* packages from source. Have I summarised this correctly? Cheers, Emile. -- E-Advies - Emile van Bergen [EMAIL PROTECTED] tel. +31 (0)70 3906153 http://www.e-advies.nl pgp7VIRUBBmvE.pgp Description: PGP signature
Re: Debian conference in the US?
Hi, On Fri, May 23, 2003 at 03:14:48PM -0400, Jaldhar H. Vyas wrote: On Thu, 22 May 2003, Marc Singer wrote: Perhaps we can look at this a different way. I haven't read anyone voicing the opinion that GWB (can't say the name of the beast out loud) is a 'good fellow'. Well since you asked. I think GWB is a 'good fellow'. Yes. Too bad he didn't happily stay being a good fellow on his ranch in Texas. Cheers, Emile. -- E-Advies - Emile van Bergen [EMAIL PROTECTED] tel. +31 (0)70 3906153 http://www.e-advies.nl pgpaRtbeDPTJj.pgp Description: PGP signature
Re: Debian conference in the US?
Hi, On Thu, May 22, 2003 at 10:39:02PM +1000, Russell Coker wrote: On Thu, 22 May 2003 17:06, Miles Bader wrote: You mean the iraq war? What's the point? How is avoiding the U.S. going to help anything, regardless of how strongly you feel about the U.S. governments acts or positions? When tourism goes down the hotel, entertainment, and airline industries suffer. If enough people boycott the US because of this then it'll keep the American economy down. If the US economy stays down long enough then the current government won't last. Rhetoric about imaginary enemies in Iraq doesn't satisfy people who lose their jobs because of the economy sucking. Hm, as could be seen in Iraq, boycotts only strenghen the position of the rogue leaders (See? They are all against us! We need to protect ourselves! You need a strong man to protect you! Etc.) Cheers, Emile. -- E-Advies - Emile van Bergen [EMAIL PROTECTED] tel. +31 (0)70 3906153 http://www.e-advies.nl
Re: Daft Internet Stuff [Re: Returning from vacation. (MIA?)]
Hi, On Tue, May 20, 2003 at 07:14:33AM +0100, Matt Ryan wrote: Emile van Bergen wrote: However, I fail to understand why you want people to refrain from bringing the netiquette under the attention of the people they are receiving email from. Never said they should refrain. I do think that it's a waste of time though. Well, you are completely free to choose whether or not you advocate netiquette-compliance yourself. So if you think it's a waste of time, that's entirely up to you, and in no way interesting to anybody else I think. IOW, if everybody just tries to accomodate some reasonable wishes as stated by the other party as far as is possible without effort (and including a text/plain part is no effort, not forwarding virus hoaxes is no effort, but proving to a robot that you are not *is*), there is no need to drop any netiquette rules. You don't need to drop any rules that you are happy with and comply with yourself. Just don't expect anyone else to do so. Well, I can still ask, can't I? If it's no effort to the other party, and after explaining the arguments, some rules actually makes sense to him or her, then who knows, the other person may even comply. I don't like school boy rules and I thought I'd tell everyone. The netiquette stuff (and others) are a pretty exclusive policy as there are such a myriad of rules that can be broken that its use is more to make the other party look stupid compared to the technical knowledge of their accuser. The fact that netiquette is being abused for such purposes doesn't make it less useful. That goes for any tool, be it technical or social. Cheers, Emile. -- E-Advies - Emile van Bergen [EMAIL PROTECTED] tel. +31 (0)70 3906153 http://www.e-advies.nl
Re: Executable /lib/ld-linux.so breaks noexec
Hi, On Tue, May 20, 2003 at 05:45:21PM +0200, Martin Pitt wrote: Hi! Is there any particular reason to have /lib/ld-linux.so.* exxecutable? If it is used only as a proper library, it need not be executable. The problem is that this breaks the noexec mount option. If /foo is mounted noexec, then one cannot do /foo/myprog, but /lib/ld-linux.so.1 /foo/myprog will work. This prevents proper separation of executable and writable files, thus I consider this as a security hole. Any comments to this? It's not possible if you don't give read permissions on /foo/myprog to users who are not allowed to execute it. If /foo/myprog is a shell script or executable by another interpreter that the user is allowed to run, then you've still got your hole. In short, I think you're trying to place a barrier at a very non-strategic, if not indefensible place. Also, keep in mind that it will prevent anything if that person was prevented from running anything he put on the system himself in the first place. All that is hard to do, and not really necessary if you use the standard Unix permission system sensibly. In general, you should not give access to sensitive files to other and then to try and prevent other from using any sort of command such as /foo/myprog that will give access to those files; you're making it unnecesarily hard for yourself, and you'll almost inevitably leave one or more access methods open. There are just too many ways to do it. Running a non-setuid program as non-root should never be dangerous in the first place, except to the files of the user running it. If it is, you're already in great danger and should fix your security problem. I'm not saying userland security is never needed or useful, but still: never use userland security as a substitute for properly set up filesystem permissions. Cheers, Emile. -- E-Advies - Emile van Bergen [EMAIL PROTECTED] tel. +31 (0)70 3906153 http://www.e-advies.nl pgpuM75iqCpsm.pgp Description: PGP signature
Re: Daft Internet Stuff [Re: Returning from vacation. (MIA?)]
Hi, On Mon, May 19, 2003 at 07:14:07PM +0100, Matt Ryan wrote: Josip Rodin wrote: Well, yeah, sure, but the highway analogy doesn't apply. There isn't a single technical reason why I as a random person need to ever be in any sort of contact with a spammer to keep the system running. There was no mention of spammers in the thread! While they are prone to sending HTML emails its a general comment on people usage of the Internet. If you can limit yourself to contacts who are technical enough to understand the arguments why you don't like it then you can maintain the pretence that it doesn't exist. Those who have to communicate on a wider basis (perhaps for work?) cannot afford to drop mail to /dev/null and so will have to get used to it I think. Few people are advocating to send every non-netiquette compliant mail to the bitbucket. However, I fail to understand why you want people to refrain from bringing the netiquette under the attention of the people they are receiving email from. It's not that receivers of email have a /right/ or that they can enforce compliance, but that was never the case anyway, in case you didn't notice. You can't demand anything, but of course you can filter whatever you like. It's your loss, nobody elses. IOW, if everybody just tries to accomodate some reasonable wishes as stated by the other party as far as is possible without effort (and including a text/plain part is no effort, not forwarding virus hoaxes is no effort, but proving to a robot that you are not *is*), there is no need to drop any netiquette rules. In short, I still fail to see your point. Cheers, Emile. -- E-Advies - Emile van Bergen [EMAIL PROTECTED] tel. +31 (0)70 3906153 http://www.e-advies.nl
Re: Do not touch l10n files
Hi, On Sun, May 18, 2003 at 10:39:21PM +0200, Javier Fernández-Sanguino Peña wrote: On Sun, May 18, 2003 at 06:55:37PM +0200, Marc Haber wrote: On Sun, 18 May 2003 17:10:29 +0200, Javier Fernández-Sanguino Peña [EMAIL PROTECTED] wrote: Unfortunately, there does not seem to be any possibility to prevent translation work from being done on my packages. Unfortunately, there is a large population of the world that does not understand english at all, but only their native language. Highly technical packages like zebra, netfilter-related stuff and linux-atm are most likely to be used by people who know English. Not speaking English will make running routers and/or internet security systems almost impossible anyway. (...) You would be surprised in any case, if speaking English would be a prerequisite for running routers then the Internet would not be as it is today. Yes, most notably the spam levels would be much more bearable. Sorry, couldn't resist. Of course, that's also an argument /for/ translating mail server documentation. Cheers, Emile. -- E-Advies - Emile van Bergen [EMAIL PROTECTED] tel. +31 (0)70 3906153 http://www.e-advies.nl
Re: Daft Internet Stuff [Re: Returning from vacation. (MIA?)]
Hi, On Sun, May 18, 2003 at 10:26:38AM +0100, Matt Ryan wrote: Emile van Bergen wrote: So what do you propose then, to drop everything just because you cynically point out that a lot of rules are being violated today? What I'm saying is that (a lot of) these rules are archaic and irrelevant in today's Internet world. Firstly I doubt any of the people who violate the rules are even aware what an RFC is or what it's for - and if they did they probably wouldn't care. So? I may as well ask the question again. I also don't understand the phrase today's Internet world. You mean with the hordes running Outlook and shopping on the clickable amazing discoveries / quantum shopping / tell sell channel that's the WWW? How does that make sane email communication standards less relevant? Does it matter to the sender that they put a couple of extra lines in their signature and this *may* cause a few extra seconds download time for the recipient? Is forwarding a chain letter going to get them cut off by their ISP? Will their computer explode if they type their message in CAPITALS? The answer to these is no, and I hazard a guess that 'abuse' of any of these rules would end up at the same conclusion - it's not relevant to me therefore I'll dismiss it. So if your ISP doesn't cut you off, or your computer doesn't explode, you'll dismiss the friendly requests and advice given by the people you're communicating with. That doesn't sound very social, does it? Society evolves and with it rules change, we need to accept this and see what evolves - if it turns out to be bad then limits will have to be applied, but I'm not seeing a complete state of anarchy break out yet... Again, I ask: what's the alternative you are proposing? What do you want? It seems you just want to send HTML mail, and not feel sorry for it. Be my guest. Just don't send it my way. Or to a mailing list, or to anybody you don't know, or to somebody of who you don't know whether he or she accepts HTML mail, for that matter. Thanks, Emile. -- E-Advies - Emile van Bergen [EMAIL PROTECTED] tel. +31 (0)70 3906153 http://www.e-advies.nl pgpoK2iqfKpoU.pgp Description: PGP signature
Re: Daft Internet Stuff [Re: Returning from vacation. (MIA?)]
Hi, On Sat, May 17, 2003 at 05:57:31PM +0100, Matt Ryan wrote: [He who should not be named wrote] That .sig is problematic beyond just its content; it is 12 lines long and adds almost 1kb to each of your messages (probably longer than the contents of many messages). Refer to RFC 1855 or any other netiquette document for further information. With statements such as this: Never send chain letters via electronic mail. Chain letters are forbidden on the Internet. Your network privileges will be revoked. Notify your local system administrator if your ever receive one. You can tell this is great advice these days. Like almost all the Internet/Usenet etiquette and behaviour things it only serves 1 purpose - to make the people spouting it look like old fools when 99.999% of the users these days don't give a damn about the 'rules' dreamt up by academics in 1985! So what do you propose then, to drop everything just because you cynically point out that a lot of rules are being violated today? Or were you just trolling? Emile. -- E-Advies - Emile van Bergen [EMAIL PROTECTED] tel. +31 (0)70 3906153 http://www.e-advies.nl
Re: Bug#193017: ITP: ipsvd -- Internet protocol service daemons
Hi, On Mon, May 12, 2003 at 11:58:53PM +0200, Bernd Eckenfels wrote: On Mon, May 12, 2003 at 08:36:18PM +0200, Gerrit Pape wrote: I've written a short comparison before per host concurrency limits were added, see here if you're interested: http://article.gmane.org/gmane.comp.misc.pape.general/293 PErsonally I think Class concurrency is a nice feature, too, since it allows to detect some forms of DDOS agents. Interesting. I've created a patch for tcpserver that counts the number of connections for each source address in the last x seconds, i.e. without looking at concurrent connections. It then provides this count in an extra environment variable to the child it spawns, so you can implement rate limiting. If anybody's interested, I'll put it on the web soon. I used it together with a tarpit patch to limit the total mail output for a mail relay to a certain average. Cheers, Emile. -- E-Advies - Emile van Bergen [EMAIL PROTECTED] tel. +31 (0)70 3906153 http://www.e-advies.nl pgp6E84FF9ChE.pgp Description: PGP signature
Re: The Debian Mentors Project
Hi, On Tue, May 13, 2003 at 03:51:42PM +1000, Anthony Towns wrote: On Mon, May 12, 2003 at 10:48:03PM +0200, Daniel K. Gebhart wrote: --- Debian Mentors Project The mentors core-team is: Christoph Haas (ChrisH)[EMAIL PROTECTED] Ivo Marino (eim) [EMAIL PROTECTED] Daniel K. Gebhart (con-fuse) [EMAIL PROTECTED] Christoph Siess (CHS) [EMAIL PROTECTED] Uh, as far as I can tell, of the above only Daniel is even in the n-m queue; Christoph, Ivo and Christoph appear to not be developers, applicants, or even sponsored maintainers of any packages in the archive. ] In longer terms: only registered Debian developers (DD) are allowed to ] upload packages directly into the official Debian distribution. But ] becoming a DD is a long and painful way. Daniel applied to be a maintainer on 2003-03-18 and was assigned an application manager nine days ago, according to nm.debian.org. Why are we giving debian.net addresses to people who don't want to go through the pain of authenticating themselves to Debian, demonstrating they no what they're doing, and agreeing with Debian's principles? It seems that it's harmless, and its potential usefulness for the sponsors and/or AMs, who /are/ DDs, could warrant a debian.net name, can't it? That no DD had to spend much energy to set this up is only a good thing, isn't it? In short, why pick on this useful initiative? Cheers, Emile. -- E-Advies - Emile van Bergen [EMAIL PROTECTED] tel. +31 (0)70 3906153 http://www.e-advies.nl pgpQePf62zWoU.pgp Description: PGP signature
Re: The Debian Mentors Project
Hi, On Tue, May 13, 2003 at 04:34:08AM -0500, Luca - De Whiskey's - De Vitis wrote: On Tue, May 13, 2003 at 10:02:11AM +0200, Christoph Haas wrote: Please bear with me but from what I was told by a number of package maintainers it is a really long way until one has become a DD. Just because Daniel was assigned an AM does not mean there is a guarantee he will get his DD access in the next weeks. I doubt that. That's may be true or not: i joined Debian in less than a month. There are many factors around that issue. I want to add my two euro-cents too: IMHO is very unfair, for a Debian project, to blame another Debian Project or Debian it self (NM is part of Debian). More over, it seems to me that you intend to help any non-Debian developer to distribute his software regardless of the fact he may want or not to join Debian: that's why i also don't see the point in haveing such a sentence. Regardless, I actually think it's a wonderful scaleability measure to provide some infrastructure that allows DDs to delegate some of the packaging work to NMs in the queue, who can prove that they are worth their salt, or to non-DDs, who can contribute to the project in a controlled manner that way. I think there is a niche for such non-DD contributors. Not only in bugreporting and bugfixing, but also in packaging work. The number of packages is already huge, and arguably more than the DDs can handle, if you look at the number of orphaned packages. Of course, if nobody cares about them, they should be removed, but it may very well be that no DD cares about them enough to continue doing all the packaging work, while other people do care and are willing to work through a sponsor. Allowing DDs to take advantage of the work of lesser gods, whenever that is practical and useful, seems a good thing for all parties concerned. And no, IANADD. Cheers, Emile. -- E-Advies - Emile van Bergen [EMAIL PROTECTED] tel. +31 (0)70 3906153 http://www.e-advies.nl pgpM3uXEUAtYx.pgp Description: PGP signature
Re: The Debian Mentors Project
Hi, On Tue, May 13, 2003 at 09:48:49AM -0500, Luca - De Whiskey's - De Vitis wrote: On Tue, May 13, 2003 at 12:07:12PM +0200, Emile van Bergen wrote: [...] Regardless, I actually think it's a wonderful scaleability measure to provide some infrastructure that allows DDs to delegate some of the packaging work to NMs in the queue, who can prove that they are worth their salt, or to non-DDs, who can contribute to the project in a controlled manner that way. This is conceptually wrong: if a DD wishes to co-maintain his package, Debian offers alioth.d.o which is already up and running; if he wishes to delegate... who wishes to delegate the maintainership of a package? I'd rather say that a DD sponsors other non-DD contributions. That's not mutually exclusive. Also, you ask who would ever wish to delegate the maintainership of a package. I think the answer is every DD who has filed a RFA on a package. There may be DDs who rather see another DD adopt the package, but I imagine that most will rather see a NM or non-DD adopt it, possibly sponsored by himself if he has some time remaining for this package, than seeing it actually orphaned. This is a different, looser form of delegation than working together on Alioth on it. There is a plenty of ways a NM can contribute/join Debian: packaging is only the simpliest. Try to take some job or a package from the QA, a task from http://www.debian.org/devel/todo/ or anything that can came out from the Developer's corner section on the main site. Non-DDs contributing in this way do not help Debian: have you ever read of our lacks of packages? You don't, because we haven't. I know. However, there are *existing* packages for which DDs don't always have enough time or interest. If you think that isn't true, then what are all those orphaned packages doing on WNPP? I think there is a niche for such non-DD contributors. No there is not. The fact is that if one wants to contribute Debian, that is to say help the DDs, he should work in those fields Debian needs help. I know. But because of the packages up for adoption, and the orphaned packages, I was under the impression that the DDs need help with those packages. If that's not the case, why are those orphaned packages not removed outright? Allowing DDs to take advantage of the work of lesser gods, whenever that is practical and useful, seems a good thing for all parties concerned. that's a pity... there is no one here who feels to be a god: unfortunately, there are many outside here that think to be... looser gods. It's just a phrase. I haven't a clue what looser gods are, BTW. Finally, i do not understand why you quoted my mail... I was only objecting with this sentence: But becoming a DD is a long and painful way. Many developers just want to make their software available to Debian users but not become DDs. They are invited to upload their packages here and tell other users about this server. Well, I didn't see why you would object to the second sentence. If somebody's able to maintain a package through a sponsor well, he may still have no desire to become a DD. I agree that the very last sentence is a little questionable; this function may already be provided by apt-get.org. However, from the original announcement I understood that the primary target audience is not the users, but potential sponsors, so that the packages may be (or remain, in the orphaned case) part of Debian -- if the sponsoring DDs think they are worthwhile and the packager did a good job that is. From the original announcement at http://lists.debian.org/debian-devel/2003/debian-devel-200305/msg00756.html This project is a benefit for maintainers (non-DDs) and their sponsors (DDs). Maintainers are able to upload packagages to mentors.debian.net and point their sponsors to this server. Sponsors can download and test this packages by downloading them after expansion their sources.list[2]. If you ask me what i think about mentors.debian.net i'd say we do not need such a service: i would have made any contributor to use alioth (register, work on your favorite package and release it). A better service would have been to create a place to coordinate people looking for sponsorship with those willing to offer it. Well, mentors.debian.net exists, whereas the one you're describing does not, so apparently people felt more need for the former. Cheers, Emile. -- E-Advies - Emile van Bergen [EMAIL PROTECTED] tel. +31 (0)70 3906153 http://www.e-advies.nl pgpetPG5av3hy.pgp Description: PGP signature
Re: The Debian Mentors Project
Hi, On Tue, May 13, 2003 at 10:16:38PM +0200, Fabio Massimo Di Nitto wrote: I think upload must be moderated somehow. Even the uploader himself claim that he is unsure about licence of the product. Well, if the packages can only be downloaded by registered DDs, then the problem's solved I'd say? After all, if I understand correctly, the service is more intended for use by sponsors who would upload them into unstable after checking, than directly for users. Cheers, Emile. -- E-Advies - Emile van Bergen [EMAIL PROTECTED] tel. +31 (0)70 3906153 http://www.e-advies.nl pgpOkzrwU5GwX.pgp Description: PGP signature
Re: Announcing Debian Package Tags
Hi, (sorry to respond) On Tue, Apr 29, 2003 at 07:35:47PM -0400, Colin Walters wrote: On Tue, 2003-04-29 at 14:32, Manoj Srivastava wrote: On Tue, 29 Apr 2003 12:24:19 -0400, David Roundy [EMAIL PROTECTED] said: To be precise, you said Maybe novices should only be shown gui programs after all. Not that novices should be allowed to decide to only view gui programs IF THEY WISH, as you said later. The first message impled that some one other than novices decides what to show them, then you toned it down to being a choice of the end user, which is acceptable. Manoj, the topic here is tuning Debian for different audiences. Believe it or not there are a huge number of people in the world for whom if you said terminal application or gui they just stare at you blankly. In fact they comprise the vast majority of people in the world. For most of these people, most console applications are just not usable. Of course they stare at you blankly, because they are very technical terms. They just want to use the computer for what they need it for. But some people seem to chronically forget that it's just a few years ago that end users needed to type C:\ cd wp51 C:\ wp in order to launch their wordprocessor. Most also learned how to copy files around with copy. People regarded these commands as fully intended for the end users, and they were used by the end users. It was just part of operating the computer. I object to any idea that a command line and non-computer-savvy users don't match. In a lot of cases, there's just as much learning involved in GUI-operated computers, and it often doesn't achieve much more productivity in the end. GUIs tend to be a lot more modal (opening and closing windows!) than a command line. People often have trouble keeping track of where they are, and how to get from a to b in GUI applications. The transition from a to b (eg. close window) is often a lot different from going from b to a (eg. find application in launcher, start application), and this modality is hard, because most things in the world don't work that way. A command line is always the same command line (the only modal behaviour is when you type a quote, causing the next prompt to be different). Also, people tend to have a lot larger memory for words than for images and unpronounceable hieroglyphs (icons, and -- shudder -- tool bars). It's not that I think GUIs are bad in any way. It's just that they are vastly overrated by a lot of people. Just because they're seen often nowadays don't make them natural, remember that. Cheers, Emile. -- E-Advies - Emile van Bergen [EMAIL PROTECTED] tel. +31 (0)70 3906153 http://www.e-advies.nl pgpCNQACbizyL.pgp Description: PGP signature
Re: Bug#191037: /run/, resolvconf and read-only root
Hi, On Mon, Apr 28, 2003 at 05:54:37PM -0400, Sam Hartman wrote: Jamie == Jamie Wilkinson [EMAIL PROTECTED] writes: Jamie This one time, at band camp, Sam Hartman wrote: Until you get general consensus on a specific goal, I'm unlikely to accept such changes if they are submitted to me. As a maintainer I want to be able to look at some statement and answer the following questions: Jamie Hi Sam, Jamie I've just filed the bug with my patch to pam. My goal is Jamie not specifically a read-only root (although that may be a Jamie useful by-product of it) but just to remove any program Jamie state out of /etc. It is my firm belief that programs Jamie should not be writing anything to /etc. I'm not sure I agree with this goal. I don't specifically disagree yet, but what you are proposing is a change in Unix semantics. If the rest of the world goes along with this, I will, but I'm somewhat unconvinced it is the right direction. It's a change, but the meaning of the files that are present in /etc/ won't change. It's only that some more dynamic and volatile files are moved away. The spirit of this idea is already in our FHS. In a lot of cases, its guidelines are already a lot more detailed than those of the commercial unix vendors. Other than that, I think it's safe to say currently that the Free / Open *nixes have become the leading innovators in the field of Unix. I don't think we'll make much progress if we wait till the commercial unixes come up with solutions with the problems we want to solve -- especially if that are problems they care little about, because they cater for a narrower group of users than we do. There are few operating systems that have such broad targets as Debian; the goal is to be the Universal Operating system, no less. Indeed, most Unixes don't run on embedded systems, a lot don't run diskless, most are unsuitable for laptops or even desktops, and so on. I'd certainly feel better if there were a broader consensus than just Debian before moving in this direction. I think if Debian comes up with a good idea that's applicable to any Unix, be it Free/Open/NetBSD or the commercial *nixes, it would be a waste to wait with the implementing it till the others adopt it before us. Also, others may not adopt till they have seen a succesful implementation. Incidentally, this also applies to the FHS. So, for now I'll sit back and see what other people do about /run. If you mean other GNU/Linux distributions or the *BSDs, don't hold your breath. If you mean Debian developers, it seems that a lot of good progress is being made. Cheers, Emile. -- E-Advies - Emile van Bergen [EMAIL PROTECTED] tel. +31 (0)70 3906153 http://www.e-advies.nl pgph51ZQB9X4u.pgp Description: PGP signature
Re: Announcing Debian Package Tags
Hi, On Mon, Apr 28, 2003 at 06:20:54PM -0400, Morgon Kanter wrote: This one time, at band camp, David Roundy [EMAIL PROTECTED] wrote: Maybe novices should only be shown gui programs after all. They probably don't want to be using a shell anyways... I don't really think this would be a good idea at all. I was a novice once while using Debian, and I'm glad that the above wasn't reality. Especially because no GUI has been able so far to create the empowering experience from being able to glue lots of things together, and easily adding the missing bits yourself. In the GUI world, you either have a program or an applet for a specific task, or you're out of luck. There is no way to combine existing tools. You won't learn step by step to be more and more self supporting. There's just one very steep step up: either you write those big tools or you don't. I think that Debian, and Free Software in general, is about empowering the user and trying to bridge the gap between user and developer. Most GUI applications fail miserably in that area; they feed the user nothing but a large set of multiple choice options. They cannot be connected in a meaningful way to anything that developer hasn't explicitly created an interface for. The user can only do what the developer intended; no more, no less. That is not in the best interest of our users, I'd say. Cheers, Emile. -- E-Advies - Emile van Bergen [EMAIL PROTECTED] tel. +31 (0)70 3906153 http://www.e-advies.nl pgpaBQUtBTfZw.pgp Description: PGP signature
Re: i386 compatibility libstdc++
Hi, On Sat, Apr 26, 2003 at 05:07:41PM +0100, Mark Brown wrote: On Sat, Apr 26, 2003 at 10:55:08AM -0400, Bart Trojanowski wrote: * Darren Salt [EMAIL PROTECTED] [030426 10:26]: 486SX. I thought that in-kernel emulation would have solved the gap between 486 DX and SX. It works just as well for 386SX as for 486SX. Note that the SX suffix for 386 means a 16-bit external data bus (instead of a 32-bit one for the DX), whereas for 486 the SX means no FP included. Cheers, Emile. -- E-Advies - Emile van Bergen [EMAIL PROTECTED] tel. +31 (0)70 3906153 http://www.e-advies.nl
Re: i386 compatibility libstdc++
Hi, On Fri, Apr 25, 2003 at 08:53:40PM +1000, Russell Coker wrote: It does sound like it would be a good idea to have a separate build for 386 and 486, then we could optimise everything else for 586+. Hmm... I'd argue for putting the split at either 386 vs 486+ (the latter at least has a math copro and CMPXCHG), or at 386-pentium vs 686+. I say this because the original pentium didn't introduce a lot of new features other than the two pipelines for which you only need some insn scheduling that's fully compatible with the 486, and IIRC wasn't sold nearly as well as the various flavours of the 486. In other words, if you use 486-compatible instructions and pentium scheduling, you're already taking almost full advantage of the pentium. It makes therefore little sense to group the original pentium with the later architectures. Cheers, Emile. -- E-Advies - Emile van Bergen [EMAIL PROTECTED] tel. +31 (0)70 3906153 http://www.e-advies.nl pgpkpnAaCa13L.pgp Description: PGP signature
Re: i386 compatibility libstdc++
Hi, On Fri, Apr 25, 2003 at 09:26:41AM -0500, Steve Langasek wrote: On Fri, Apr 25, 2003 at 08:51:41AM +0200, Matthias Klose wrote: Should Debian further support the i386 target, or make (at least i486) the default for code generation? Asking because I'm unsure how to provide the libstdc++5 package. Realistically, are there any C++ apps on the planet that wouldn't choke an i386 to death anyway? There's nothing wrong with the performance of C++ apps. Years ago I did lots of C++ development on a 16MHz 386SX running DOS. The problem is STL and the fact that a lot of C++ programmers tend to forget to conquer while dividing. Cheers, Emile. -- E-Advies - Emile van Bergen [EMAIL PROTECTED] tel. +31 (0)70 3906153 http://www.e-advies.nl pgpurcLir9xvi.pgp Description: PGP signature
Re: Only .changes files are readable in NEW/
Hi, On Thu, Apr 24, 2003 at 10:00:49PM +0200, Frank Lichtenheld wrote: On Thu, Apr 24, 2003 at 02:30:50PM -0400, christophe barbe wrote: On Thu, Apr 24, 2003 at 02:30:35PM +0200, J?r?me Marant wrote: Yes, it is normal. The reason is crypto-in-main: they have to be checked by ftp-masters first. I don't see why they should not be readable by everyone before being checked by ftp-master. I don't said I disapprove that (for what it would worth) but I don't understand the logic. Can someone explain? When I read http://www.debian.org/legal/cryptoinmain correct, all Software that contains cryptographic functionality must be registered before it can legally be distributed. So the ftp-master must check if a new package contains cryptographic functionality and if it is already registered. Considering the legislators' feeling for these matters, I'm surprised nobody's been able to convince these people to allow registration to happen in write only memory. Cheers, Emile. -- E-Advies - Emile van Bergen [EMAIL PROTECTED] tel. +31 (0)70 3906153 http://www.e-advies.nl
Re: Bug#189370: acknowledged by developer (irrelevant)
Hi, On Wed, Apr 23, 2003 at 04:45:11PM +0900, Atsuhito Kohda wrote: On the other hands, in Debian which is an association of volunteers, a developer can package any DFSG-free TeX components or DFSG-free extra fonts packages freely so we need an infra-structure which provides dynamic texmf.cnf etc. so that every such extra packages can modify texmf.cnf in order that they could be installed and work without problem. I believe this is our (tetex-mantainers') duty. Dynamic TeX package registration is nice, but not through the main texmf.cnf if people feel that's intended for the admin and the admin only. Why not put the dynamic things in a file like texmf-debian.cnf, and tell the admin that if he wants to use newly installed packages automatically, he should include texmf-debian.cnf from the main texmf.cnf (if including is possible at all -- no idea) or make his texmf.cnf a symlink to the texmf-debian.cnf? I.e. have a fully managed file, but leave it to the admin whether or not his real file points to the managed file, or includes it (if possible), or ignores it altogether. Cheers, Emile. -- E-Advies - Emile van Bergen [EMAIL PROTECTED] tel. +31 (0)70 3906153 http://www.e-advies.nl pgpoFklGunLs9.pgp Description: PGP signature
Re: plagiarism of reiserfs by Debian
Hi, On Wed, Apr 23, 2003 at 10:49:09AM -0700, Mark Rafn wrote: That said, I'd prefer Debian NOT remove such advertising, only that we guarantee users the right to do. *And* distribute the result, if you want to be DFSG-free. Cheers, Emile. -- E-Advies - Emile van Bergen [EMAIL PROTECTED] tel. +31 (0)70 3906153 http://www.e-advies.nl pgpXhwApwE0vB.pgp Description: PGP signature
Re: Bug#189347: stop the manage with debconf madness
Hi, On Thu, Apr 17, 2003 at 09:45:54AM -0700, Craig Dickson wrote: Andrew Suffield wrote: On Thu, Apr 17, 2003 at 12:47:38PM +0200, Mike Hommey wrote: On Thursday 17 April 2003 02:32, Colin Walters wrote: On Wed, 2003-04-16 at 20:21, Chris Hanson wrote: I'd rather fix this properly; what you suggest is a workaround. What I consider a proper fix is to redefine the configuration files so that they can be parsed. I have learned, the hard way, that using shell scripts for configuration files is a bad idea. That's true, it's definitely a workaround. The way I did it in fontconfig is the way I think it should be done in packages which can't (or can't easily) losslessly parse their configuration files. OTOH, xml config files (like fontconfig's config) could be losslessly parsed through xslt processing... Much like any other config file can be losslessly parsed by processing them. That's not really very helpful. Yes, but with a standard format such as XML, you don't have to write your own code to parse or generate them. On the other hand, I don't think we really want package configuration scripts to require XML tools, do we? Please, no. In most cases, the only feature that's used (and needed) of XML that it stores a tree of attribute/value pairs. Given limited effort, I am absolutely convinced that it should be possible to come up with a more robust, well defined, simple(!), user and implementor-friendly(!), do-one-thing-and-do-it-well way of doing that. Not by starting from we've got HTML which is being (ab)used for ad-hoc RPC purposes, let's make a more general SGML application to do that which became XML, but starting from the simple requirement stated above: storing and transmitting nested trees of attribute/value pairs with a *limited* number of possible data types. That means *most definitely not* including a programming language to create all kinds of funky new types, like you have with ASN.1 or the DTDs. If the data types offered are not suitable for your application, there's always octet-string; at least that's my humble opinion. If 5% of the values in a configuration tree remain opaque data, we've already gained 95%; right now configuration files are so brittle and hard to edit losslessly that a lot of them must be treated as fully opaque. Definition should be done like you'd treat a network protocol, with a healty dose of be conservative in what you write, be liberal in what you read, to paraphrase the great J. Postel, as it /will/ be a protocol, spoken between package configuration scripts and packages. Anybody interested in such an effort? I've got a few ideas for this, but if people feel the current way of doing things is good enough, then I won't bother you guys with another idea lacking implementation. Cheers, Emile. -- E-Advies - Emile van Bergen [EMAIL PROTECTED] tel. +31 (0)70 3906153 http://www.e-advies.nl pgppmeJQAgvzB.pgp Description: PGP signature
Re: Debian for x86-64 (AMD Opteron)
Hi,
On Thu, Apr 10, 2003 at 06:23:12PM +0200, Arnd Bergmann wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thursday 10 April 2003 16:43, Emile van Bergen wrote:
On Thu, Apr 10, 2003 at 03:33:39PM +0200, Wichert Akkerman wrote:
# echo x86-64 /etc/dpkg/legal-archs
# dpkg -i libgtk2-2.0-1_i386.deb
# dpkg -i lib64gtk2-2.0-1_x8664.deb
libssl0.9.6-0.9.6c-2_i386.deb or
libssl0.9.6-0.9.6c-2_i686.deb;
on a x86-64 you'd have the choice between those same two plus
libssl0.9.6-0.9.6c-2_x8664.deb
These two proposals have a significant difference. The first one
needs more changes to the individual library packages because it
changes not only the file names but also the package names. I'm
not sure how to best handle dependencies on this.
Simple: explicitly. I don't think it'd be a good idea to allow 32-bit
apps to link to 64-bit libraries and vice versa. How would you layout
the (shared) address space? Handling all cases would become a mess
quickly.
You do want to allow both 32-bit and 64-bit versions of libraries to be
installed, for which you need different package names; you want to avoid
adding fields to a package's primary key, so that the dependency tree
assmebly mechanisms can be left as they are.
The second proposal would mean that dpkg will have to be changed
so it can install the same package for both x8664 and {i386,i686}
at the same time, which could prove difficult. The dependencies
here can basically stay the same (e.g. ssh will continue to
depend on libssl0.9.6 even on 64 bit), but dpkg and apt will have
to know about an additional dimension concerning dependencies, e.g.:
That is exactly what Wichert wanted to avoid. I'm sorry, you probably
got this idea because of a most unfortunate typo of mine in the last
.deb I mentioned; I meant lib64ssl0.9.6-0.9.6c-2_x8664.deb there.
There are two distinct issues I wanted to illustrate:
1. different package name (for 64 bits), different architecture,
more than one architecture allowed by dkpg: allows 32-bit and 64-bit
versions of packages to coexist; allows (64-bit) machines to install
packages from compatible (32-bit) architectures. This was Wichert's
idea.
2. same package name, different architecture, more than one
architecture allowed by dpkg: solves CPU optimized libraries in
a transparent way; no changes to dependencies necessary. This is what
Wichert's suggested extension to dpkg would allow when using the same
package name.
Hope it's clear now.
Cheers,
Emile.
--
E-Advies - Emile van Bergen [EMAIL PROTECTED]
tel. +31 (0)70 3906153 http://www.e-advies.nl
pgpEKvXwn6hs9.pgp
Description: PGP signature
Re: Debian for x86-64 (AMD Opteron)
Hi, On Fri, Apr 11, 2003 at 09:42:52PM +0200, Arnd Bergmann wrote: On Friday 11 April 2003 15:49, Emile van Bergen wrote: You do want to allow both 32-bit and 64-bit versions of libraries to be installed, for which you need different package names; you want to avoid adding fields to a package's primary key, so that the dependency tree assmebly mechanisms can be left as they are. Yes, but what I also want to avoid is having to change every single instance of 'Depends: libfoo' to 'Depends: libfoo [! x86_64, sparc64, s390x, ppc64, hppa64], lib64foo [x86_64, sparc64, s390x, ppc64, hppa64]' and then changing them all again for mips64 ;-). You don't need that. Depends: libfoo will just stay Depends: libfoo. No lib64foo will be pulled in, as it has a DIFFERENT PACKAGE NAME. What I have in mind is something along the lines of libfoo 'Provides: libfoo(32bit)' lib64foo 'Provides: libfoo(64bit)' bar 'Depends: libfoo($BITSIZE)' I don't know if it's possible to teach dpkg and the other tools about this. I really have lost all clue of what you think is missing from current behaviour. - lib64foo /already/ provides lib64foo. - bar (a binary 64 bit package) can /already/ depend on lib64foo (and not libfoo). What's the problem? Emile. -- E-Advies - Emile van Bergen [EMAIL PROTECTED] tel. +31 (0)70 3906153 http://www.e-advies.nl pgpbq1ynPSDxN.pgp Description: PGP signature
Re: Debian for x86-64 (AMD Opteron)
Hi, On Thu, Apr 10, 2003 at 03:33:39PM +0200, Wichert Akkerman wrote: [SNIP] So basically, I don't think this is a very good idea. However I think we can solve it differently in a much simpler way: * modify dpkg (already planned) to allow it to install packages from different architectures on a system where it makes sense * change the naming of the libraries, for example by adding '64' to the 64bit version of a library That way you could do something like: # echo x86-64 /etc/dpkg/legal-archs # dpkg -i libgtk2-2.0-1_i386.deb # dpkg -i lib64gtk2-2.0-1_x8664.deb To my untrained eye, this seems an excellent and very general solution. As a slight but positive side effect, it also seems to open the way to per-CPU optimized library versions; if you have a 686, you add 686 (or 686-cmov) to /etc/dpkg/legal-archs, and can install either libssl0.9.6-0.9.6c-2_i386.deb or libssl0.9.6-0.9.6c-2_i686.deb; on a x86-64 you'd have the choice between those same two plus libssl0.9.6-0.9.6c-2_x8664.deb Of course, that's only the dpkg side of things; in any case, you'd still need a way to present the extra choices caused by legal-archs in dselect. How would that be done? Cheers, Emile. -- E-Advies - Emile van Bergen [EMAIL PROTECTED] tel. +31 (0)70 3906153 http://www.e-advies.nl pgprxcutj0URl.pgp Description: PGP signature
Re: Debian for x86-64 (AMD Opteron)
Hi, On Thu, Apr 10, 2003 at 05:23:12PM +0200, Cyrille Chepelov wrote: Le Thu, Apr 10, 2003, à 04:43:57PM +0200, Emile van Bergen a écrit: That way you could do something like: # echo x86-64 /etc/dpkg/legal-archs # dpkg -i libgtk2-2.0-1_i386.deb # dpkg -i lib64gtk2-2.0-1_x8664.deb To my untrained eye, this seems an excellent and very general solution. As a slight but positive side effect, it also seems to open the way to per-CPU optimized library versions; if you have a 686, you add 686 (or 686-cmov) to /etc/dpkg/legal-archs, and can install either libssl0.9.6-0.9.6c-2_i386.deb or libssl0.9.6-0.9.6c-2_i686.deb; That would be lib686ssl0.9.6-0.9.6c-2_i686.deb; or lib686-cmovssl0.9.6-0.9.6c-2_i686-cmov.deb; according to Wichert's proposal (which I think will lead us to a support nightmare, not to mention the ugliness of the naming scheme) No, for dependency-less optimizations you leave them out on purpose; that's the whole idea. You want 32-bit applications that depend on libssl0.9.6, to use either libssl0.9.6-0.9.6c-2_i386.deb or libssl0.9.6-0.9.6c-2_i686.deb; completely transparent to the depending application. I.e. every package becomes slightly virtual in the sense that multiple architectures are allowed. Only 64-bit applications would depend on lib64ssl0.9.6 (from lib64ssl0.9.6-0.9.6c-2_x8664.deb, sorry, missed the 64 in my last mail) instead of depending on libssl0.9.6, which is an entirely different package. I'll stop rambling about this now though as optimization an entirely different subject. I just wanted to second Wichert's idea. Cheers, Emile. -- E-Advies - Emile van Bergen [EMAIL PROTECTED] tel. +31 (0)70 3906153 http://www.e-advies.nl pgpTkcQvWK8uO.pgp Description: PGP signature
Re: Debian for x86-64 (AMD Opteron)
Hi, On Thu, Apr 10, 2003 at 05:27:40PM +0200, Michael Banck wrote: On Thu, Apr 10, 2003 at 04:43:57PM +0200, Emile van Bergen wrote: On Thu, Apr 10, 2003 at 03:33:39PM +0200, Wichert Akkerman wrote: [SNIP] So basically, I don't think this is a very good idea. However I think we can solve it differently in a much simpler way: * modify dpkg (already planned) to allow it to install packages from different architectures on a system where it makes sense * change the naming of the libraries, for example by adding '64' to the 64bit version of a library That way you could do something like: # echo x86-64 /etc/dpkg/legal-archs # dpkg -i libgtk2-2.0-1_i386.deb # dpkg -i lib64gtk2-2.0-1_x8664.deb To my untrained eye, this seems an excellent and very general solution. As a slight but positive side effect, it also seems to open the way to per-CPU optimized library versions; if you have a 686, you add 686 (or 686-cmov) to /etc/dpkg/legal-archs, and can install either libssl0.9.6-0.9.6c-2_i386.deb or libssl0.9.6-0.9.6c-2_i686.deb; on a x86-64 you'd have the choice between those same two plus libssl0.9.6-0.9.6c-2_x8664.deb Please note the wiggy * change the naming of the libraries, for example by adding '64' to wiggy the 64bit version of a library Your above examples all have the same package name, just for a different architecture. AFAICT, this is exactly what Wichert wanted to avoid. Yes, sorry, the last .deb name should have been lib64ssl0.9.6-0.9.6c-2_x8664.deb; it's a different package altogether, and applications need an explicit dependency on it. The other two were correct; the package name is the same, they conflict inherently, and applications cannot specify any particular dependency. The positive side of that is that the rollout of CPU optimized versions of library can happen without having to change depending applications in any way. Cheers, Emile. -- E-Advies - Emile van Bergen [EMAIL PROTECTED] tel. +31 (0)70 3906153 http://www.e-advies.nl pgpiNsZ31ItHK.pgp Description: PGP signature
Re: Pre-linux Windows program - was Re: bill gates Linux
Hi, On Sun, Dec 08, 2002 at 02:25:19PM +, John Lines wrote: Reading the thread on installation from Windows - one thing which might help new Linux users would be a program which they ran from Windows before they started, which would record all the things Windows knows about their system which will be required by a Linux installation. This could include information on the hardware, such as graphics cards, and some things related to the user, such as language settings and time zones. These could be written to a floppy and used to supply the information which Debian Installer will need (a bit like a RedHat Kickstart floppy) Another idea: why not support an installation in an ext2 filesystem which is really a big file on a Windows VFAT partition, mounted using a loopback device? That would do away with all the partitioning; that would only be needed when the user wants to get rid of the relatively minor performance penalty of the extra FS layer. Can Linux work with a loopback root fs, using initrd to set it up? Cheers, Emile. -- E-Advies / Emile van Bergen | [EMAIL PROTECTED] tel. +31 (0)70 3906153| http://www.e-advies.info pgpr258QC6y3r.pgp Description: PGP signature
Re: Pre-linux Windows program - was Re: bill gates Linux
Hi, On Sun, Dec 08, 2002 at 11:31:11AM -0600, Steve Langasek wrote: Why make it a separate program that runs under Windows? Why not mount the Windows partition from the Linux installer, and read the registry from there? Because it's easier for Windows to read its own registry and write a portable ASCII file than it is for Linux, as you'd have to implement a 'fs' driver for it. Not that I think this is all necessarily a good idea though. Before you know, people will go back to Windows to change their IP address in Linux because they don't know how to do it there. Cheers, Emile. -- E-Advies / Emile van Bergen | [EMAIL PROTECTED] tel. +31 (0)70 3906153| http://www.e-advies.info
Re: Pre-linux Windows program - was Re: bill gates Linux
Hi, On Sun, Dec 08, 2002 at 12:24:56PM -0600, Steve Langasek wrote: On Sun, Dec 08, 2002 at 07:08:17PM +0100, Emile van Bergen wrote: On Sun, Dec 08, 2002 at 11:31:11AM -0600, Steve Langasek wrote: Why make it a separate program that runs under Windows? Why not mount the Windows partition from the Linux installer, and read the registry from there? Because it's easier for Windows to read its own registry and write a portable ASCII file than it is for Linux, as you'd have to implement a 'fs' driver for it. Not that I think this is all necessarily a good idea though. Actually, I would find it significantly easier to borrow code from Wine to do registry parsing and run a tool against a Windows partition mounted read-only to extract the information we need, than I would to write a Windows application to do roughly the same thing. Hum, yes, but that probably says more about 1. the excellent capabilities of the Wine team 2. lack of ability and willingness to write windows code on your part than the elegance of the solution - IMHO. Before you know, people will go back to Windows to change their IP address in Linux because they don't know how to do it there. Well, since debconf is not a registry, that would be a little difficult, wouldn't it? Well, I was thinking about horrible scenarios like, you know, I installed this Linux thing, and it used my network settings from Windows fine, but now I can't find out how to change it, so I figured I could change the settings in Windows and then reinstall Linux, so I did. Cheers, Emile. -- E-Advies / Emile van Bergen | [EMAIL PROTECTED] tel. +31 (0)70 3906153| http://www.e-advies.info
Re: location of UnicodeData.txt
Hi, On Thu, Nov 28, 2002 at 10:45:48AM -0600, John Hasler wrote: Richard Braakman writes: But do you think it's _okay_ for such a file not to be free? /usr/share/perl/5.8.0/unicore/UnicodeData.txt, which I assume is the file you are talking about, contains just a table of data. Unless its creation involved creativity rather than just sweat of the brow it is not protected by copyright. I'd say that the definition of Unicode, heck even ASCII, involves a fair amount of creativity. The question is, is the definition of Unicode, as a set of named glyphs and encodings, protected by copyright? If not, then a table in a particular format representing that definition and nothing but that definition is not likely to be copyrightable. However, in these perverse times, where companies patent hyperlinks, I honestly have no idea whether Unicode itself is owned but licensed royalty-free, or as free as say, ASCII or English. Newspeak is free for non-commercial and other non-infringing uses, and when not used to say bad things about Our President. Otherwise, please contact the worldwite patent bureau for a RAND-license. Bah. Cheers, Emile. -- E-Advies / Emile van Bergen | [EMAIL PROTECTED] tel. +31 (0)70 3906153| http://www.e-advies.info pgp4ZYWM8L3hW.pgp Description: PGP signature
Re: location of UnicodeData.txt
Hi, On Thu, Nov 28, 2002 at 11:47:52AM -0600, John Hasler wrote: Emile van Bergen writes: I'd say that the definition of Unicode, heck even ASCII, involves a fair amount of creativity. I don't doubt that the development of Unicode involved creativity: under current law it probably qualifies as a patentable invention. Inventions and ideas, however, cannot be copyrighted: only creative works reduced to tangible form can. I'm arguing that the _creation_ _of_ _that_ _table_ involved no creativity, not that the invention of Unicode didn't. Well, so you say that if I write a novel, all my creativity is in the abstract idea; putting the words down involved no extra creativity; thus the sequence of words cannot be copyrighted? I think your argument doesn't help here... Is it possible to create other Unicode tables that serve the same purpose as that one and differ from it non-trivially? Good question. Under your reasoning, merely writing the list down from the unicode spec, possibly using | as separators instead of :, should do the trick. Cheers, Emile. -- E-Advies / Emile van Bergen | [EMAIL PROTECTED] tel. +31 (0)70 3906153| http://www.e-advies.info pgp1vNT3MXUdd.pgp Description: PGP signature
Re: location of UnicodeData.txt
Hi, On Thu, Nov 28, 2002 at 10:47:02PM +0200, Richard Braakman wrote: On Thu, Nov 28, 2002 at 07:02:07PM +0100, Emile van Bergen wrote: On Thu, Nov 28, 2002 at 11:47:52AM -0600, John Hasler wrote: Is it possible to create other Unicode tables that serve the same purpose as that one and differ from it non-trivially? Good question. Under your reasoning, merely writing the list down from the unicode spec, possibly using | as separators instead of :, should do the trick. Note that this file _is_ part of the unicode spec. As far as I know the character attributes are defined nowhere else. So writing the list down from the unicode spec means copying the file. So the spec is the implementation, and a copyrighted implementation at that? That's lousy, to say the least. So all programs that follow the full Unicode spec are derived works of the implementation of the standard found in that copyrighted table, and have to carry the copyright and disclaimer notice mandated by the Unicode consortium? If so, Unicode cannot be regarded an unencumbered standard, if you're strict about it. Cheers, Emile. -- E-Advies / Emile van Bergen | [EMAIL PROTECTED] tel. +31 (0)70 3906153| http://www.e-advies.info pgp8zIa2iPS5u.pgp Description: PGP signature
Re: Pick a name, any name...
Hi, On Wed, Nov 27, 2002 at 11:03:58AM +0100, Roland Mas wrote: Hi all, As some of you probably know, some people are in the process of installing a Sourceforge site on a Debian machine. It will consist of a slightly patched version of the 2.6 branch of the Debian package sourceforge, with a few scripts to help integration with existing infrastructure (existing accounts and groups should be preserved, for instance). The code is almost ready, the server itself should be OK soon (if not already), and Wichert and I even managed to find a time where both of us can be on the same IRC network at the same time. Now for the *real* important debate: how to call it? What about Avalon? Both a composer (well, hmm) and the place where Excalibur was forged. Cheers, Emile. -- E-Advies / Emile van Bergen | [EMAIL PROTECTED] tel. +31 (0)70 3906153| http://www.e-advies.info pgpK1e1fVLO0d.pgp Description: PGP signature
Re: Pick a name, any name...
Hi, On Wed, Nov 27, 2002 at 11:55:56AM +0100, Roberto Suarez Soto wrote: On Nov/27, Emile van Bergen wrote: What about Avalon? Both a composer (well, hmm) and the place where Excalibur was forged. Being about forging, Orodruin comes also to mind ;-) Yes, although there's already an orodruin.sourceforge.net and Mount Doom is not altogether a nice place ;-)) Cheers, Emile. -- E-Advies / Emile van Bergen | [EMAIL PROTECTED] tel. +31 (0)70 3906153| http://www.e-advies.info pgpcNDOS4wfiS.pgp Description: PGP signature
Re: DAM approval wait time?
Hi, On Wed, Nov 27, 2002 at 12:21:40PM -0800, Jim Lynch wrote: [SNIP] I was hoping you'd say that, but you still have growing up to do. Are you expecting me to prove myself to you in some way? Given some contradictory statements you've made... as a matter of fact, I am expecting you to prove yourself as being a mature developer, or at least showing growth toward becoming mature. I see some inklings, but I also see some steps back. Bleurch, could we skip the belitteling and treat people with a little respect? This arrogance makes me *puke*. Sorry. I don't care who you are or who Andrew is. This is totally out of bounds, in /any/ circumstance. Thanks, Emile. -- E-Advies / Emile van Bergen | [EMAIL PROTECTED] tel. +31 (0)70 3906153| http://www.e-advies.info pgpcvJkY55IGT.pgp Description: PGP signature
Re: Are we losing users to Gentoo?
Hi, On Mon, Nov 25, 2002 at 08:22:23AM -0800, Jon Kent wrote: [SNIP] The reasons I see people switch to Gentoo are : Its more fun Alot more up to date Easier to customise, down to which libraries you want to support I'm tempted to say that Debian has gotten too big, has too many bosses (to coin a phrase) and is hampered at times by its own policy. I've been using Debian for years and have seen it grown alot over time. However, it seems to me that the only _big_ thing Debian has on its side these days is dpkg/apt. Everything else is out of date, a nightmare to setup and, to be honest, not fun anymore. It seems there's a distinction in user categories to make here; of course there's the upgrade-and-tweak-all-day-for-the-heck-of-it type, which will find Gentoo irresistible. And for good reasons. But don't forget there's also a category that runs linux as they would run another unix: as a tool in some production role. Fun in that respect means no worries. And Debian is great for that: stable releases get no new features, only security updates, and you /know/ that those releases work great as they had a lot of QA. In short, linux isn't just for fun, you know. Some people use linux to work on other things than linux itself. And that's where Debian shines. Let's keep it that way. The idea to announce the state of testing/unstable once in a while to show we've got the fancy stuff too does make sense though, IMHO. Cheers, Emile. -- E-Advies / Emile van Bergen | [EMAIL PROTECTED] tel. +31 (0)70 3906153| http://www.e-advies.info pgpw3iFnDXGRe.pgp Description: PGP signature
Re: Need access to an Alpha
Hi, On Sun, Nov 24, 2002 at 09:04:59PM +1000, Andrew Pollock wrote: Hi, I've got a problem with a package I maintain building from source on the Alpha architecture. I'm still going through the NM process, and I believe that once I become a DD I'll get access to a Debian Project Alpha. In the meantime, does someone have an Alpha that they can give me temporary access to? I'd like to troubleshoot this problem quickly, rather than rolling a new package, waiting for sponsor to upload it and then seeing what the Alpha buildd does with it, rinsing and repeating. I have an Alpha here. It's an old 166MHz EV4 with 40Mb RAM, running Potato. But if that's good enough for your purposes, I'm happy to give you an account. It's a noisy space heater (a Multia), so I only switch it on when I need it. I have no problem running it for a week though if you need the time. Cheers, Emile. -- E-Advies / Emile van Bergen | [EMAIL PROTECTED] tel. +31 (0)70 3906153| http://www.e-advies.info pgpLHlwWStLQK.pgp Description: PGP signature
Re: Are we losing users to Gentoo?
Hi, On Thu, Nov 21, 2002 at 08:35:03PM -0600, Manoj Srivastava wrote: Branden It's been said that self-censorship is the worst form of Branden censorship. I guess that isn't the case when we're asking Branden other people to practice it. Is politeness self censorship, then? (that is a pretty damning admission, and one I would have hesitated in levelling against you). Self restraint by a free choice, made by your complete being, to refrain from doing something is not what I'd consider self censorship. It's an ethical concept, and I'm sure the Bhagavat Ghita (Dutch transliteration) talks a lot about it in connection to Dharma. Self censorship is if one side of you is compelled to say something whereas another part of you forbids it. Cheers, Emile. -- E-Advies / Emile van Bergen | [EMAIL PROTECTED] tel. +31 (0)70 3906153| http://www.e-advies.info
Re: Ask yourself some questions
Hi, On Thu, Nov 21, 2002 at 05:10:31PM +0100, Yven Leist wrote: On Thursday 21 November 2002 16:28, Branden Robinson wrote: Well, the dismal failure of that one is noted. Just for the record, I actually found it quite funny. And I'm not exactly in favour of the GR... (just to refute the argument that Branden's joke could only appeal to people on his side in this debate ;-)) Same here, and I'm not exactly in favour of the GR either. Cheers, Emile. -- E-Advies / Emile van Bergen | [EMAIL PROTECTED] tel. +31 (0)70 3906153| http://www.e-advies.info
