Re: libpaper 1.0 on master
joost witteveen wrote: Shouldn't the paper size be an attribute of a print queue, and not an attribute of a machine? Well, it could be argued that Yvess libppaper could look at the current $PRINTER setting, and select the correct papersize depending on the /etc/papersize.printer file or something. But at the moment not very many programmes use libpaper or /etc/papersize, so it's better to have them at least get to recognise a global /etc/papersize than nothing. Yup, sometimes something is better than nothing. Then again, sometimes something part way makes it harder to get to all the way too. If you make it queue-specific, it might be best to add it into /etc/printcap (as opposed to /etc/papersize.queuename). There is precedent for this (with at least one printer I've set up), and it's discussed in at least one popular book about system administration (by Evi Nemeth, under the name printcap extensions). BTW, this book lies thru it's teeth about Solaris 2.x, Parsing /etc/printcap is a simple matter - 20 lines of /bin/sh, or pgetent in the lpd source. An external library, such as libpaper.*, is precisely the right place to put such a thing. AS long as it has a good'n'general interface, the long-term nice-scenario get here eventually. Paper size effect more that just printers. Previewers and tex tools come to mind, there may be others... All I know is right now I've got to tweak quite a few things on a standard debian 1.1 system so that dvips, xdvi, genscript, and a few other programs work well and have the same idea of a default paper size. Well, after you've done the tweaking, maybe it's worth the little extra efford of mailing the patches to the maintainer/bug-system and wait to see them included in the next release? If you don't want to do that, could you send your patches to me, so that try to handle it?
Re: CC's on this mailing list
Mr Stuart Lamble wrote: All very nice, but it dodges the major reason for people disliking duplicate copies of messages: they pay for their PPP link (or UUCP feed, or whatever). Identifying duplicates by their message IDs means that you have to download both messages, unless you can do the filtering at your ISP's end of the link. I'm not overly concerned personally at the moment - I'm at university, and the government pays for my feed :-) - but it's generally not good etiquette full stop. Bandwidth prices have dropped quite healthily in recent years, and they are going to continue to do so. Rambling on about being cc'd, when the bandwidth prices are still dropping, and YOU HAVE alternatives, is silly at best. Those of you who've been going on and on about this, consuming far too much human-time (on this already excessively voluminous list) : 1) Have you switched up to a 28.8kbps modem yet, or at least a 14.4kbps modem? Yes, modems cost money, but shelling out a little for a modem now may save you heavily in bandwidth if you transfer much data - and would save you a lot more than badgering people about cc'ing. 2) Are you transferring your mail gzip'd? If not, why not? Have you bothered to look for an ISP that will help you do this? This too would save you a lot more than badgering people about cc'ing. 3) Have you bothered to look for an ISP that will do upstream filtering? Have you even bothered to ask your current ISP if they'd be willing? If you want to do all your interaction with the internet over a low bandwidth link, and you're concerned about bandwidth costs, then this SHOULD be a deciding factor in your choice of ISP. This also, would save you a lot more than badgering people about cc'ing.
Re: libpaper 1.0 on master
Storing one thing in one place is an excellent goal. Treating multiple things as tho they were one thing (EG all printers use the same paper) can be troublesome. Ideal: keep the option of an /etc/papersize, but allow a user to override /etc/papersize if desired, thru ~/papersize or environment variables. Richard Kaszeta wrote: Shouldn't the paper size be an attribute of a print queue, and not an attribute of a machine? Paper size effect more that just printers. Previewers and tex tools come to mind, there may be others... All I know is right now I've got to tweak quite a few things on a standard debian 1.1 system so that dvips, xdvi, genscript, and a few other programs work well and have the same idea of a default paper size. -- Richard W Kaszeta Graduate Student/Sysadmin [EMAIL PROTECTED]University of MN, ME Dept http://www.menet.umn.edu/~kaszeta
Re: libpaper 1.0 on master
Shouldn't the paper size be an attribute of a print queue, and not an attribute of a machine? Yves Arrouye wrote: Please do not use 0.* versions anymore. The next release (1.0-1) will have a paperconfig paper configuration script instead of having /etc/papersize as a conffile. Yves. -BEGIN PGP SIGNED MESSAGE- Date: 13 Aug 96 17:16 UT Format: 1.6 Distribution: unstable Urgency: Low Maintainer: Yves Arrouye [EMAIL PROTECTED] Source: libpaper Version: 1.0-1 Binary: libpaper Architecture: i386 source Description: libpaper: Library for handling paper characteristics Changes: * abstract interface (struct paper hidden) so that future changes can be made safely. * stores dimensions as double, still in PS points. Files: 6b55151261dc94a835e7581fa4c894dc 55776 text - libpaper_1.0-1.tar.gz 7d7feddde35dcf7f83a6096097ebc997 25340 text optional libpaper_1.0-1_i386.deb -BEGIN PGP SIGNATURE- Version: 2.6.2i iQCVAwUBMhC4aQjpU7xgQoo9AQHK0gP/bD6Pd7Ab3VvzfXI+ikvJ9g/UMZrjaaSJ CZt7f1m3DDZAoKlwhiZGzZGoJzKFkWaqwlMl6tis7hZjOWOXjFeWeGMpxQl/nhpO j+SUKANSXAj/p2iCoryTm2dC1+RuAo6lkxu298wlCMPyJb6V2ts8XhhPaxejE2ST fLxdzD2Rp0w= =vXPH -END PGP SIGNATURE-
Re: Bug#3961: 14 character file name limit in zoo
Martin Schulze wrote: As zoo comes from DOS I'm not sure if it would be a good idea to support long filenames. zoo comes from Rahul Dhesi, and was designed from the ground up to be cross-platform, albeit particularly for use with CBIP. The 14 character limitation is probably a rudiment of linux's roots in minix-386.
Re: Debian, Linux, the FSSTND, the FHS and BSD
Ian Jackson wrote: The latest draft FHS, which they may well publish as it stands, makes the following changes with which I have very strong disagreements: * The mail spool, /var/spool/mail, is moved to /var/mail. This is a positive thing. Both SVR4 and BSD 4.4 put it here. I think any contemporary unix should. * /var/lib is renamed to /var/state (yes, all of it). * /var/lib/games is moved to /var/games. * A new directory /usr/libexec is created to hold command binaries used only internally by programs - these are to be moved from /usr/lib and in some cases /usr/sbin. Oddly there is no corresponding /libexec directory. I don't really care about these. They're the sort of thing that dances around from one unix to the next anyway. The two good changes that I see are (and they are not minor): * /usr/share exists and is defined. * /opt exists and is defined. These are nice. [1] When the original FSSTND was created I argued in favour of /libexec and /usr/libexec, but lost that debate. I'm less convinced now than I was then, but my main reason for opposing it now is that it is too late to change. Nah - we've always got to be careful about it's too late now syndrome. To think otherwise, is to plot a path to obsolescence. They oughta add /libexec, tho. Symlinks help, especially if you keep developers informed that usage Of those symlinks is deprecated.
Re: Perl vs Python vs ....
Brian C. White wrote: Dan Stromberg wrote: There's clearly a place for a stronger scripting language, despite the argument posed above. It's just very sad that it should be perl. perl really fits into many people's stereotypes of unix as inherently cryptic monster, very neatly. I'm sure C and Assembler fit cryptic too. Just think how much further advanced the computer industry would be if neither of those had ever been invented. (that's sarcasm, by the way) And how much further would the industry be, if C had been typesafe (or if some other, typesafe language had been used)? The expertise in language design existed at the time, but C didn't have it. And yet, C was adopted as a major standard - because the people who knew better, didn't bother to speak up. That's not to say that a lot hasn't been accomplished in C - obviously. But we could have done a lot more, if such a simple thing hadn't been put off until ANSI. Also, the code I maintained on my first job, probably would've been a LOT cleaner - many of you are probably in the same boat. I really hated roaming around fixing somebody else's stray pointer references. In fact, I'm pretty sure I recall either K or R, saying that lint should have been just another pass of cc, instead of a separate program. That's a very small design-decision, but it's had a _H_U_G_E impact, for more people than a wanna think about. The choice of a languages is a rather larger decision. There is no point having a religious war over this; this decision was taken a long time ago and can't be changed now, even if we wanted to. This is rhetoric. It could be changed and you know it. What I mean to say is, I really dislike can't when what's meant is won't. I daresay that a linux distribution (or the Hurd, or *BSD, or...) that doesn't fall into the perl trap, should have a brighter future. Oh, give it up! Perl is a fine language. Its powerful and is quite easy to write nice clean code with. It's just not _enforced_ that you write assembler is powerful, and quite easy to write nice clean code with. It was hot stuff at its inception. sendmail is powerful, and quite easy to write nice clean header munging and mail routing with. It was hot stuff at its inception. perl is powerful, and quite easy to write nice clean small-scale scripts with. It was pretty old-news, at its inception. nice clean code. It's also very easy to garbage code, but that isn't enforced, either. As for the truth of your comment... Language syntax and symantics have little to do with a language's success; it's how easy it is to write useful programs with. An operating system's success is due primarily to the amount of software available for it. (Don't believe me? Look at MS-Dos!) Yes, yes, yes, and No, no, no. A language's success is typically 95% who backs it, and 5% how good it is. With the masses, that is. However, for a group that knows what it's doing, it should be 5% who backs it, and 95% how good it is. So it -should- be for debian. The debian project is in a more than adequate position, to set a more-positive direction for the unix industry. One way to do that, is to hang onto /bin/sh until something like guile is ready. Another way to do that, is to move beyond perl to something like python or ML (metalanguage) - right now. It wouldn't take much at all. Once the inertia's there, it's hard to change it. In fact, many people will become angry with you if you do. But it's often very worthwhile to take a step back, and look at the long-term ramifications of a decision.
Re: Perl vs Python vs ....
Ian Jackson wrote: We only have room for one `extra' scripting language, besides the usual sh, awk, sed, c, on the base disks. Perl is widely known. It can solve most problems. There are problems for which it is difficult to get it to work, but these don't often occur at installation time. sh is not suitable for many of the things Perl gets used for - consider update-inetd, update-info c. Actually, a /bin/sh script to add inetd.conf entries, and another to remove entries keyed off the service field, was unmentionably simple to code, and has proved quite reliable in (lots of) practice. For this reason we decided that Perl would be on our base disks, and that packages could use it (well, the subset that's on the base disks) in their preinst/postrm. Packages which want something else must Depend on it and may only use it in their postinst/prerm. There's clearly a place for a stronger scripting language, despite the argument posed above. It's just very sad that it should be perl. perl really fits into many people's stereotypes of unix as inherently cryptic monster, very neatly. There is no point having a religious war over this; this decision was taken a long time ago and can't be changed now, even if we wanted to. This is rhetoric. It could be changed and you know it. What I mean to say is, I really dislike can't when what's meant is won't. I daresay that a linux distribution (or the Hurd, or *BSD, or...) that doesn't fall into the perl trap, should have a brighter future. Ian.
