Re: VI reasons (was Re: Base Set: Suggested additions removals.)
On 15 Jun 1998, Martin Mitchell wrote: Raul Miller [EMAIL PROTECTED] writes: Yes, but note that the current version of ae fixes a lot of these problems. [I found this out while attempting to verify some of my gripes about ae.] Is it just me, or does the vi mode in the current version of ae not work at all? I tried ae -f /etc/ae2vi.rc tst and could not even quit with :q, I had to switch consoles and kill it. i've 'discovered' this several times when booting linux emergency or linux single at the LILO promptunless you remember to run 'open' a few times to get some more virtual consoles, the only way out is to push the reset button. not a good thing to do to a system. the fact is that ae is easy for some people so it should be on the rescue disk (even though it sucks badly - personally, i find it difficult and clumsy to use, and won't use it for anything). joe is a nice easy editor but is much too big. i'd prefer joe on the rescue disk but it won't fit. elvis-tiny is small enough to fit on too (although that may have changed now that we use slang rather than ncurses - can elvis-tiny use slang??) and provides a decent editor for people who can't/won't use crap. Perhaps much of this discussion could be solved if ae managed vi keybindings a little better. Martin. P.S. This test was using ae version 962-20. -- craig sanders -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Release management - technical
On Mon, 22 Jun 1998, Ian Jackson wrote: We should continue to have `long term goals', and I applaud people who work towards them, but we must be able to make a release even when they are not met. It is better to have a release now and goals later than no release now and goals later ! and In future, we should make releases _without regard to long term goals_. Since we have to be incrementally-upgradeable, long term goals can be achieved just as easily out of step with releases. i (mostly) agree. debian's upgradeability is one of it's best features, and it is a feature which isn't matched by any other distribution...at least, not to the same extent. i've long believed that debian is a live distribution, and the best way to use it is to regularly (i.e. every week or two) upgrade to the latest unstablethis has worked for me for the last few years, and the only time i got bitten by a new bug enough to swear about it was when fmirror got upgraded to a bad alpha version and blew away my debian mirror (an expensive mistake at $0.19/megabyte). that's why i think we should have monthly untested snapshot CDs of unstable as well as regular tested official releasesso that those who don't have good net connections can benefit from debian's live nature. anyway, what i really wanted to say here was that sometimes releases do have to be delayed to meet some goals. i think that the upgrade to libc6 was one of them (but i think hamm met that goal around August or September last year, and could have been released anytime after that). I suspect that another such goal will be PAMit doesn't do much good to have half a PAM-enabled system. For PAM, we need all the typical login authentication stuff linked against PAM and we also need PAMified versions of sendmail, smail, etc so that mail can be delivered for users who only exist in a radius or LDAP directory and not in /etc/passwd. craig -- craig sanders -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
On Mon, 22 Jun 1998, Dale Scheetz wrote: There has got to be a better way to deal with this problem (which is fundamentally a sorting problem). Santiago's suggestion of 2.0.7r-1 is more satisfying but, if you consider the situation, doesn't really resolve the long term problem any better. What we need here is a better way of dealing with this problem. My mind has no solution at the moment, but my gut says that there is one, so I will keep looking. The reason I think this is a continuing problem is that the next round of glibc development is just a likely to run through several preX versions before a release is made. IMO, the problem is caused by the fact that the packages are given the new version number before that version is actually released. how about using 2.07pre8-1, 2.07pre8-2, and so on for the next set of glibc pre-releases? maybe this should be policy for all pre-release packages? In the mean time, unless anyone can object within the next several hours, I will construct and upload a new release of glibc with the version number: 2.0.7r-1 cool, that'll solve the immediate problem. craig -- craig sanders -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
On Tue, 23 Jun 1998, Philip Hands wrote: Yann Dirson wrote: Craig Sanders writes: how about using 2.07pre8-1, 2.07pre8-2, and so on for the next set of glibc pre-releases? Seems like it doesn't work: $ dpkg --compare-versions 2.07pre8-1 '' 2.0.8 echo yes || echo no no You missed a dot out of the first one (should be 2.0.7pre8-1) I'd go and get some sleep, or a coffee, if I were you, Yann ;-) actually, it was me who forgot the . before the 7. Yann just copied my mistake. after looking at some of the other comments, i'd change my suggestion to 2.0.7pre8.1-1 for pre-release #1 2.0.7pre8.2-1 for pre-release #2 2.0.7pre8.3-1 for pre-release #3 alternatively, 2.0.7pre8#1-1 (but i don't think # is a valid character and having to escape the # would be an annoyance on the command line and scripts/config files which use # as the comment char.) any of the similar suggestions would be fine too. the exact form doesn't matter, as long as it a) works :) and b) the meaning of the version number is fairly clear. whatever format is chosen, it should be put in policy so that we don't have to figure it all out again in future, and also document a new standard/convention. craig -- craig sanders -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
On Tue, 23 Jun 1998, Philip Hands wrote: for all future time. People make mistakes choosing version numbers, and we have a mechanism for recovering these mistakes. People being ``inventive'' so they can maintain the aesthetic beauty of a control file that is rarely seen by anyone is a waste of all our time. it's more than just 'aesthetic beauty'. 'dpkg -l' output is hard-coded for 80 columns, and there are only a limited number of character positions available for the version number. extracting the version from the listing is not possible for long version strings. yes, this is a bug in dpkg, and should be fixed. but the problem exists now, and if dpkg's revision history is anything to go by will continue to exist for a long long time. craig -- craig sanders -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug #23877: Include autoup.sh and apt in hamm/hamm
On 25 Jun 1998, Ben Gertzfield wrote: Subject: please include apt and autoup in hamm/hamm/upgrade-i386/ To: [EMAIL PROTECTED] -- Package: ftp.debian.org,apt,autoup Version: N/A Well, let's just do it! I see no problem with making such a directory for final hamm. imo this directory should also be populated with symlinks to all the packages which autoup.sh needs to do the upgrade. there should also be a copy of the the bo libc5 dpkg in there, to assist with upgrades from rex/buzz. craig -- craig sanders -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg -S problem
On Fri, 2 Oct 1998, Rainer Dorsch wrote:
$ dpkg -l /usr/bin/printmail
No packages found matching /usr/bin/printmail.
this is normal. you used -l (list packages) when you meant -S (search)
$ dpkg -S /usr/bin/printmail
elm-me+: /usr/bin/printmail
btw, you may want to install jim pick's dlocate hack. it runs a lot
faster than 'dpkg -S' and does the same job (and a lot more) - it is a
very clever use of the GNU locate tool.
$ dlocate /usr/bin/printmail
elm-me+: /usr/bin/printmail
Jim maybe you should package this??? or submit it to the maintainer
of the findutils package. BTW, you probably haven't seen my modified
version before. hope you like my changes.
anyway, here's how to install dlocate.
make the following directory:
mkdir -p /var/lib/dlocate
then install the following files:
---cut here---/usr/sbin/dupdatedb---cut here---
#! /usr/bin/make -f
#
# original shell script by Jim Pick [EMAIL PROTECTED], GPL'd of course
#
# hacked by cas to be a Makefile so it updates the dlocatedb only when
# needed (i.e. when the package *.list files have changed)
/var/lib/dlocate/dlocatedb: /var/lib/dpkg/info/*.list
grep '' /var/lib/dpkg/info/*.list|sed 's,^.*/\(.*\)\.list:,\1: ,' | \
/usr/lib/locate/frcode /var/lib/dlocate/dlocatedb.new
mv -f /var/lib/dlocate/dlocatedb /var/lib/dlocate/dlocatedb.old
mv /var/lib/dlocate/dlocatedb.new /var/lib/dlocate/dlocatedb
---cut here---/usr/sbin/dupdatedb---cut here---
note: this is a Makefile, so lines are indented by a TAB, not spaces!
this makefile needs to be run (as root) by cron once every day (or week,
or whatever) like so:
0 3 * * * make -f /usr/sbin/dupdatedb /dev/null
and the dlocate script itself:
---cut here---/usr/bin/dlocate---cut here---
#!/bin/sh
#
# original script by Jim Pick [EMAIL PROTECTED], GPL'd of course
#
# hacked by cas to use case instead of if/elif/fi
# hacked by cas to add '-ls' option. also added error checking for
# -L and -ls options.
# hacked by cas to add '-conf' and '-lsconf' options.
# hacked by cas to add '-md5sum' and '-md5check' options.
DLOCATEDB=/var/lib/dlocate/
DPKG_INFO=/var/lib/dpkg/info
case $1 in
|-h|-H|--help)
echo Usage: dlocate [-L] [-S] [-ls] [-conf] [-lsconf] [md5sum]
[md5check] string
echo
echo (no option) string list all records that match
echo -Sstring list records where files match
echo -Lstring list all files in package
echo -ls string 'ls -ldF' of all files in
package
echo -conf string list conffiles in package
echo -lsconf string 'ls -ldF' of conffiles in
package
echo -md5sum string list package's md5sums (if any)
echo -md5check string check package's md5sums (if
any)
echo
echo The -L and -S commands are roughly analagous to the
echo equivalent dpkg commands.
;;
-L)
if [ -e $DPKG_INFO/$2.list ] ; then
cat $DPKG_INFO/$2.list
else
echo Package \$2\ not installed.
fi
;;
-S)
locate -d $DLOCATEDB $2 | grep :.*$2.*
;;
-ls)
if [ -e $DPKG_INFO/$2.list ] ; then
ls -ldF $(cat $DPKG_INFO/$2.list)
else
echo Package \$2\ not installed.
fi
;;
-conf)
if [ -e $DPKG_INFO/$2.conffiles ] ; then
cat $DPKG_INFO/$2.conffiles
else
echo Package \$2\ not installed or has no conffiles.
fi
;;
-lsconf)
if [ -e $DPKG_INFO/$2.conffiles ] ; then
ls -ldF $(cat $DPKG_INFO/$2.conffiles)
else
echo Package \$2\ not installed or has no conffiles.
fi
;;
-md5sum)
if [ -e $DPKG_INFO/$2.md5sums ] ; then
cat $DPKG_INFO/$2.md5sums
else
echo Package \$2\ not installed or has no md5sums.
fi
;;
-md5check)
if [ -e $DPKG_INFO/$2.md5sums ] ; then
cat $DPKG_INFO/$2.md5sums | \
awk '{print $1 / $2}' | \
md5sum -v -c /dev/stdin
else
echo Package \$2\ not installed or has no md5sums.
fi
;;
*)
locate -d /var/lib/dlocate/dlocatedb $*
;;
esac
---cut here---/usr/bin/dlocate---cut here---
craig
--
craig sanders
Re: what's after slink
On Sat, 3 Oct 1998, David Welton wrote: As far as something to replace them.. hrmm. Geography has been popular lately.. cities, rivers.. Something international would be good. Lakes? Seas? National parks? Drinks?:- how about endangered species. e.g. tigers, cheetahs, whales, microsoft, etc. craig -- craig sanders
Re: CD images of Slink
On Mon, 5 Oct 1998, Marcelo E. Laurenti wrote: On Mon, Oct 05, 1998 at 03:54:27PM +0200, Rainer Dorsch wrote: I am wondering, if anybody tried to build a CDimage of Slink. Will main fit on one CDROM? For hamm this problem was addressed pretty late (main, contrib, non-free) and the solution was acceptable at best. I have. Slink's main section is about 750 MB right now. boot disks (disks-i386) are about 20 MB more. Documents, 2 MB. tools, 1 MB. 5 MB more for indices (which I like to include on my cd's in case I screw up). 5 MB overhead for the cd-specific things (the table, the translation table, the other translation table, the padding, ...). You end up with 785 MB to put on a single CD. I solve getting only slink//binary- (all/i386)/admin/ there are still a lot of symlinks from slink to hamm. /debian/dists/slink$ du -sckL */binary-i386/ 112169 contrib/binary-i386 769521 main/binary-i386 5727non-US/binary-i386 160401 non-free/binary-i386 1047818 total non-free and non-US don't matter for the CD, but main is 769MB and contrib is 112MB. i think what we need is a kernel driver for swappable CDs - some sort of CD jukebox emulator. or apt could be made to do this without any kernel hacks. just for curiosity's sake, editors, x11, doc, and devel seem to be the largest sections. /debian/dists/slink$ du -sckL main/binary-i386/* | sort -n 447 main/binary-i386/Packages.gz 858 main/binary-i386/hamradio 1298main/binary-i386/electronics 1518main/binary-i386/Packages 1870main/binary-i386/shells 3733main/binary-i386/news 3873main/binary-i386/misc 4883main/binary-i386/comm 9682main/binary-i386/admin 9987main/binary-i386/otherosfs 12022 main/binary-i386/base 15255 main/binary-i386/mail 15700 main/binary-i386/web 17173 main/binary-i386/oldlibs 17376 main/binary-i386/sound 17709 main/binary-i386/utils 20971 main/binary-i386/net 21904 main/binary-i386/libs 22815 main/binary-i386/games 25151 main/binary-i386/graphics 25155 main/binary-i386/interpreters 38269 main/binary-i386/tex 41465 main/binary-i386/math 45991 main/binary-i386/text 69621 main/binary-i386/editors 70242 main/binary-i386/x11 82342 main/binary-i386/doc 172210 main/binary-i386/devel 769520 total craig -- craig sanders
Re: Squid2, how to handle incompatible upgrade
On 8 Oct 1998, Miquel van Smoorenburg wrote: In article [EMAIL PROTECTED], Miquel van Smoorenburg [EMAIL PROTECTED] wrote: However the problem is dat squid-2.0 is totally incompatible with squid-1.2. The cache directory and file format has changed, and the config file format has changed .. in fact it's a new package. Never mind - I forgot how I handled it the last time, from the 1.0 to the 1.1 upgrade. Just test in the preinst for the previous version and show a warning, upgrade instructions and a prompt there. Seemed to work the last time .. so it will probably work this time as well. sounds good to me. btw, i'm already using your squid 1.2-beta23-1 package on several machines. works well. craig -- craig sanders
Re: I2O specs mailed to webmaster
On Thu, 8 Oct 1998, David Welton wrote: On Thu, Oct 08, 1998 at 05:18:01PM -0400, James A. Treacy wrote: Version 2.0a of the I2O spec (dated 3 Feb 1998) has been sent to [EMAIL PROTECTED] Is this the same version that was made available before? no, that was version 1.5. Did it come from anyplace interesting, out of curiousity? it was mailed from a dummy hotmail account ([EMAIL PROTECTED]), and the originating IP was from an ISP in Norway. it contained the following message, along with .pdf files for version 2 of the spec. I am sending the latest spec. on I2O. I belive this psec should be open. This is part #1 due to max. 1000k attachment using hot-mail. Best regards Free software lowers looks like good intentions, legally questionable, and bad spelling :-) craig -- craig sanders
Re: LICENSES [was: Re: Have you seen this?]
On Fri, 9 Oct 1998, Matthias Ettrich wrote: [snip] This GPL argument if taken to it's logical conclusion would prevent all GPL'ed code from running on any non-GPL'ed OS, as the applications have to link with the platform libraries, and are resultantly dependant on the non-GPL'ed OS. Indeed. If you read the GPL word for word you will find that a binary distribution requires ALL libraries to be distributed under the GPL. Debian cheats and claims the GPL is happy with so-called compatible licenses, but that's not true: The GPL explicitely requires GPL. That means, Debian has licensing problems whenever they ship something that links to the libc or glibs (because it's not GPL, but LGPL) or - even worse! - whenever something links against X11, because Xlib is clearly neither GPL nor LGPL. once again, you demonstrate your profound lack of understanding of the GPL. the GPL explicitly makes an exception for libraries which are included with the operating system itself. This includes LGPL libraries distributed with free operating systems, and it includes non-free libraries distributed with non-free operating systems (e.g. win32 on windows, motif on solaris) i suggest that you read the GPL. It might prove instructive. But that is not the point. Debian sometimes is strict, sometimes not. They clearly treat KDE in a different way. yes, we have granted KDE the benefit of the doubt for over a year while trying to get you guys to do something about your licensing problems. KDE has consistently failed to do anything at all to resolve these problems. In fact, you have consistently refused to acknowledge that there is a problem. There *IS* a problem, and pretending it doesn't exist will not make it go away. now we are treating KDE the same as we treat any other program with a questionable license. Debian on the other hand does not want to encourage people to write more free software based on KDE. They probably dislike the basic idea of a user- and developer-friendly framework for linux on its own Combined with a commercial product they hate it so much, that they don't even want to encourage people to work on harmony (what they would do if they shipped KDE). What dissapoints me is that they cannot say this in public. If they said: Debian does not want to encourage people to write software with the KDE libraries, so we remove the packages they would at least be honest. But they are not honest. Instead, they claim that KDE has a mess of a license that forbids them to do what they would like to do: distributing it. This is such a childish excuse, even more since the KDE libraries do not contain any so-called 3rd party code at all. (3rd party code, the word alone is a shame! Are we KDE Incorporated or a bunch of hackers writing free software?!). your paranoid rant barely deserves a reply. all i can say is that if you think we are bullshitting about the license issue then CALL OUR BLUFF. Fix what we claim are your license problems, what we are asking you to do is add an explicit permission in your licenses to link to Qt. How difficult can that be? The hardest part will be that you will have to seek permission from some upstream authors whose code you have used. if you fix all your license problems and debian still refuses to distribute KDE binaries then you have proved your point and demonstrated to the world that debian are a pack of bastards who are out to get KDE. if you fix your license problems and debian does distribute KDE binaries then you are proven to be wrong, BUT on the bright side your software gets more widely distributed and easier for users to install. This is a WIN-WIN situation. You have nothing to lose by fixing your license problems (except maybe a little temporary embarassment, which is nowhere near as important as the software). Debian's claim is pointless. If it was not pointless they could at least come up with one single author of at least one single line of so-called 3rd party GPLed code in a KDE application who actually shares their opinion and states in public: I do not want my line of code to be distributed as binary, that's why I put it under the GPL. Source is ok, though. license permissions are exclusive, not inclusive. any permission not explicitly granted is denied. this is the nature of software licenses and copyright law. what this means is that an author doesn't have to declare no Qt linking any more than they have to declare no illegal copying or no stealing my work. These declarations are implicit in the copyright itself. Until an author of a GPLed work grants permission to link with Qt and distribute the result, NOBODY (except the author) HAS ANY RIGHT TO DO SO. DISCLAIMER: i am a debian developer, but i am speaking for myself, not debian. craig -- craig sanders
Re: LICENSES [was: Re: Have you seen this?]
On 10 Oct 1998, Arnt Gulbrandsen wrote: Craig Sanders [EMAIL PROTECTED] the GPL explicitly makes an exception for libraries which are included with the operating system itself. Not quite so - it makes an exception for binaries that are NOT included with that operating system itself. that's almost the exact opposite of what the GPL says. from clause 3 of the GPL: The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable. the last sentence, from However, as a special exception is particularly relevant here. Debian ships a large number of GPL'd binaries that are linked against LGPL'd libraries (chiefly libc). This practice is not compatible with what Debian says in the statement that started this thread - and I too think such incompatibility may reasonably be called cheating. (Not that it's really relevant, but IMHO Debian's practice is right and the statement wrong.) read the GPL. think about it. read it again. think some more. repeat until all is clear. craig -- craig sanders
Re: Debian logo
On Sat, 10 Oct 1998, Marcus Brinkmann wrote: On Fri, Oct 09, 1998 at 03:58:58PM -0500, Jeff Noxon wrote: I'd prefer a new logo as well (with no offense intended toward the kind person who created the current one!) I would prefer a new logo, too. We shouldn't draw it. We should run a gimp contest. They produced the Gnome logo, and there are artists as well as designer. They'll come up with a good, inspiring logo, I'm sure. We should vote the winner. good idea. i *really* like the GNU Penguin one. (see the default index.html on a new apache install if you don't know what i mean.) something based on that would be great. craig -- craig sanders
Re: LICENSES [was: Re: Have you seen this?]
On Fri, 9 Oct 1998, Steve Lamb wrote: On Sat, 10 Oct 1998 11:33:15 +1000 (EST), Craig Sanders wrote: the last sentence, from However, as a special exception is particularly relevant here. So, if Qt were disttributed with the OS then it would fall under the special exception? :) yes. however the point is moot. Qt is not, and can not, be distributed with debian. it is non-free, it fails the DFSG (Debian Free Software Guidelines) test. if Qt ever becomes DFSG free, then it can be included in debian, but i do not think that is likely to happen. (TrollTech have every right to license their software in the way that they choose, and they choose a non-free license. Neither I, nor anyone sensible, has any argument with TT's license...it's their software, they can do what they like with it.) craig -- craig sanders
Re: LICENSES [was: Re: Have you seen this?]
On 10 Oct 1998, Arnt Gulbrandsen wrote: In my opinion, Qt is not a section of KDE, it is not derived from the KDE and it must be considered independent and separate from the KDE. In other words: The KDE's usage of the GPL does not cause the GPL, and its terms, to apply to Qt. if you link a GPL-ed program and Qt, you are creating a work which is derived from both. Since Qt's license is incompatible with the GPL as far as distribution goes, you may not distribute that derived work without additional permission being granted by the author (unless, of course, you are the author). note that the GPL does not distinguish between static and dynamic linking. RMS, the author of the GPL (whose opinion, therefore, is just more authoritative on this subject than yours), has pointed this out on numerous occasions. note also, that this license conflict is only with regard to distribution of the derived work. what you do on your own machine is your concern. the GPL does not restrict usage or modification in any way, it only restricts re-distribution in order to preserve the free status of GPLed software. All this is just splitting hairs, though. The real question is what is KDE's problem with just adding that additional permission to their license? How does it hurt them to do that? it's not difficult to do, and it would solve the problem for everyone. it would clarify their apparent intention, without harming them in any way. it would give debian (and others) the legal permission they seek to distribute the KDE software. craig -- craig sanders
Re: LICENSES [was: Re: Have you seen this?]
On 10 Oct 1998, Arnt Gulbrandsen wrote: Craig Sanders [EMAIL PROTECTED] if you link a GPL-ed program and Qt, you are creating a work which is derived from both. Since Qt's license is incompatible with the GPL as far as distribution goes, you may not distribute that derived work without additional permission being granted by the author (unless, of course, you are the author). However, the license for that derived work (I'll call it A) claims that the whole of A must be GPL'd. However, Qt is not part of A (the GPL says section of). Qt provides services to A, and A depends on those services: A very different thing. you miss the point. linking the two creates a work which is derived from both. note that the GPL does not distinguish between static and dynamic linking. It distinguishes between separate distribution and distribution as part of A. Not entirely the same thing, but not terribly different either. they are quite different. rms, you and I are all simple persons and speak with the same authority. Only a court speaks with special authority. the author of a work generally has a damn good idea of what his intentions were when he wrote it. Intent is a very important factor when it comes time to interpret a document (or an action, for that matter) in a court of law, especially when the author has repeatedly gone to great lengths to clarify his intentions. case in point: KDE developers *appear* to intend that their software be linked with Qt and redistributed. But whenever they are asked to clarify their intentions, they ignore the question and try to side-step the issue. Why? All that is being asked of them is to clearly state their intention by explicitly granting the permission to link with Qt and distribute. All this is just splitting hairs, though. The real question is what is KDE's problem with just adding that additional permission to their license? How does it hurt them to do that? Is that really not obvious to you? no, it's not obvious. the only thing i can think of is that KDE developers are aware of the license problems but don't want to publicly admit to them because of the ramifications about the other GPLed code that they have used. i prefer to think of KDE developers as merely mistaken (and a bit clueless about licensing issues), rather than as deliberately disingenuous. I will continue to give them that benefit of the doubt until I see clear proof to the contrary. craig -- craig sanders
Re: LICENSES [was: Re: Have you seen this?]
On 10 Oct 1998, Arnt Gulbrandsen wrote: Sorry, I must be too tired. I misread a paragraph of yours, so some of my previous message probably don't make much sense. You say that linking constitutes making a derived works of the object files and libraries being linked together. Does that mean that you think Debian should convert libc and so on from the LGPL to the GPL in order to comply with the license of the GPL'd applications in main? as mentioned at least once before, glibc is distributed with the operating system. therefore the special exception applies. how many times do we have to chase this one around? this hair-splitting is just a distraction from the real question. see previous messages for details. craig -- craig sanders
Re: KDE gone, Lyx next ?
On Fri, 9 Oct 1998, John Lapeyre wrote: Lyx is currently in contrib. Lyx is licensed under the GPL (version 2) . It is dynamically linked against a non-free library (libforms) . According to the GPL and our interpretation of it in the KDE statement, this means we should not be distributing (binaries at least) of Lyx. For instance, these binaries use .h files from libforms. Unlike KDE, it may be all original code, so that a single change of license from the developers will do. Am I missing something ? nope. sounds right to me (but i haven't looked at the licenses concerned, just going from memory of libxforms being no-source and non-free). imo, we should grant Lyx the same courtesy we did KDE. send them a request to change their license, and give them some time (say a few weeks rather than the months that KDE got) to change. if they ignore the request or choose not to change their license then we have to yank the software. craig -- craig sanders
Re: LICENSES [was: Re: Have you seen this?]
On Fri, 9 Oct 1998, Joseph Carter wrote: On Sat, Oct 10, 1998 at 12:35:31PM +1000, Craig Sanders wrote: non-free license. Neither I, nor anyone sensible, has any argument with TT's license...it's their software, they can do what they like with it.) That doesn't mean everyone else ise sensible. I've seen many people DEMAND Troll Tech release Qt under the GPL. I wanted to take a large cluebat to their heads for the reasons you cite above. i agree. people who bash Troll over Qt are missing the point. Worse, they are clouding the issue. IMO, Troll Tech are beyond reproach. they wrote a good library, and they allow people to use it for free in certain circumstances. while i would be happy to see it under an Open Source-compatible license, nobody has any right to demand that they do anythingthat's like demanding caviar from a good neighbour when they give you a sandwich. the only right you have here is to choose to accept their generosity or choose not to accept it. I personally choose not to accept it (the license isn't compatible with what i want to do with free software...also, I don't like C++ :), but i'm grateful for the offer all the same. craig -- craig sanders pgpjHZcwiFO6o.pgp Description: PGP signature
Re: Bad signature!! [was: Re: LICENSES]
-BEGIN PGP SIGNED MESSAGE- On Sat, 10 Oct 1998 [EMAIL PROTECTED] wrote: I'm not going to get into the debate at all at the moment however as I was reading through it I noticed that this message did not match the signature, would someone care to varify who actualy sent this message and what the contents were when it was signed? i wrote the message, but i didn't sign it. i don't normally sign my email. i'll sign this one though :-) craig - -- craig sanders -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: noconv iQEVAwUBNh8KX9U9fGIP1gpVAQEDWwgAhhOikd0x7q584AXLHPxtmZnRCAlSmFiz 0Hkr0p1EmtZcKtL3Y9BenccWswCizG+tYGXMHw99Z0txWibm4NGv3ng/wSrQpRHZ A8xoVJKsbJ4BXpda+OlzWYs2ItXKykdYTgLDVxv2tYbjiE9MbblvxnC6qSB/aBWQ Q40YiLJ+l9cuE/BFdbiKqfqcCNCrmw6IYgIcb08BUTxDwAJCiWkvFLxOGJmqVuI/ e5EO3wg3Kby/xKOi0H0SWA8xntj44O8J3FKBT4AykYSKDZ9S0ADcrIwT0+OoRmPu zoQ9dDOSJVpWdUBfUU+o9HII9WbJb+mNYUm9S+BQMWduLHOPwFvaCw== =YFSu -END PGP SIGNATURE-
Re: Bad signature!! [was: Re: LICENSES]
On Sat, 10 Oct 1998, Zed Pobre wrote: On Sat, Oct 10, 1998 at 02:36:17AM -0400, [EMAIL PROTECTED] wrote: I'm not going to get into the debate at all at the moment however as I was reading through it I noticed that this message did not match the signature, would someone care to varify who actualy sent this message and what the contents were when it was signed? Craig Sanders does not routinely sign his mail. Joseph Carter does. Upon closer examination, one will find that the PGP/MIME signature from Joseph Carter's previous message got attached to Craig Sanders' reply (an impressive message quoting feat, albeit a stupid one... Craig, what are you using for a mailreader?!). pine 4.05 at the moment. it has some improvements over pine 3.96 but is still a bit buggy. also, i have pine configured so that it includes attachements by default...it must have picked up Joseph's signature as a mime attachement and included it, and i forgot to delete it from the Attachment: header. craig -- craig sanders
Re: KDE gone, Lyx next ?
On Fri, 9 Oct 1998, Geoffrey L. Brimhall wrote: The big problem is that KDE includes GPLed code without asking and links it against qt. That is a not legal. I wonder what RMS would do if they provide an kemacs. :-) I guess this is the part which I'm needing a bit more understanding with (because I've not been the best at interpreting the legalese of the gpl). My understanding is that you *don't* have to ask the original author of gpl code for permission to use it or modify it, so long as the modifications are themselves fully published under the GPL. this is mostly correct. the only nit to pick here is that you don't have to publish if you don't want to...but if you do publish, then it MUST be under the terms of the GPL. Based on the above, if you did publish the modifications in the GPL, but the modifications required linking to a proprietary library, then this would be a violation unless the original authors were contacted and OK'd the publication. Correct ? no, the modifications to the source are fine. the GPL does not in any way restrict the kinds of modifications you can make to GPL-ed source code. You have the source, you can do what you want with it. This is one of the freedoms guarranteed to you by the GPL. the problem arises when you compile and link with a non-free library (e.g. Qt or Xforms). doing that creates a combined work (the binary) which is a derivative of both GPL-ed code and non-free code. if you don't wish to distribute this derived work then there is still no problem. If you do, however, wish to distribute the work then you have a complication. The GPL says that if you can not distribute the entire source for all parts of the derived or combined work under the terms of the GPL then you may not distribute it at all. this is the key point. the act of compiling and linking creates a derived work. the derived work may ONLY be distributed if ALL parts of it can be distributed under the terms of the GPL. of course, this doesn't affect the author's right to distribute - they are the copyright holder and aren't limited by their own license - but it does affect what third parties can do. unless additional permission is granted (e.g. this program is licensed under the GPL with the additional permission that you may link with libfoo), a binary may not be distributed by anyone but the author. (as a side note, this is complicated in the case of KDE because KDE has re-used some existing GPL code and linked it to Qt. While they have every right under the GPL to modify the source to do that, the GPL prohibits them from legally distributing binaries until they receive permission from the original author(s)) BTW, this is not a bug in the GPL. it is a feature. it was deliberately designed this way in order to prevent Free Software from being stolen and made proprietary. this is one of the things which makes the GPL so valuable as a Free Software license. it guarantees that once free, always free. It can complicate things sometimes for free/non-free hybrids but it is a Good Thing. it is there to protect the interests of Free Software programmers and users. I find this interesting because there is quite a bit of various efforts to port GPL'd code and programs to the MS Windows environments. Legally, this would imply stepping very carefully because who knows what proprietary libraries might be linked to get the port to work. Am I correct in this statement ? i doubt if this would affect windows ports at all. for one thing, there is a special exemption in the GPL which allows linking with libraries which come with the operating system. this was there so that GNU programs could be linked with Motif (which came with Solaris)...it applies equally to the libraries (DLLs) which come with windows. in any case, why would anyone *want* to port stuff to a dying, moribund toy operating system? sounds a bit far-fetched to me. :-) craig -- craig sanders
Re: KDE gone, Lyx next ?
On Sun, 11 Oct 1998, Raul Miller wrote: Craig Sanders [EMAIL PROTECTED] wrote: no, the modifications to the source are fine. the GPL does not in any way restrict the kinds of modifications you can make to GPL-ed source code. You have the source, you can do what you want with it. This is one of the freedoms guarranteed to you by the GPL. Correct, as long as you don't distribute the modifications. wrong. The GPL allows you to distribute your modified source as long as you distribute it with a GPL license. the GPL makes no restrictions, nor any comment at all, on the kinds of modifications you may make. as mentioned to you previously, you can modify it to work with a non-free library, you can modify it so that it doesn't work at all, you can modify it in any way that you like. The GPL takes no issue whatsoever with the kinds of modifications you may make. The GPL's only question is: is all of what you are distributing under the GPL? (as a side note, this is complicated in the case of KDE because KDE has re-used some existing GPL code and linked it to Qt. While they have every right under the GPL to modify the source to do that, the GPL prohibits them from legally distributing binaries until they receive permission from the original author(s)) The GPL also forbids them from distributing the modified sources. wrong again. the GPL only needs to cover the derived or combined work. there is no combined work until the source is compiled, linked to the non-free library, and a binary produced. craig -- craig sanders
Re: LICENSES [was: Re: Have you seen this?]
On Mon, 12 Oct 1998, Alan Cox wrote: If I use libc, I don't think I am creating a libc. Unless I am, I'm not deriving, I think. If I use libc, I simply use the services. Hence, libc is a section of the thing I am making, and does not derive from it. Your program derives from libc by being linked with it. This is precisely why an LGPL has to exist. true. more precisely: when you compile your program, the binary is a combined work which is derived from both your source code and libc. that derived work may only be distributed if ALL of it's parts (i.e. your source AND the libc) may be distributed under the terms of the GPL. note that there is also an exemption for libraries which normally come with the operating system - and libc definitely qualifies there...but that is a specific exemption which doesn't affect the general rule above. libc is a potentially confusing example, so s/libc/libFOO/ in my first paragraph above. craig -- craig sanders
Re: [ettrich@troll.no: Re: copyright problem]
On Mon, 12 Oct 1998, Michael Meskes wrote: How about this one? I told him I would remove the first sentence but other than that it looks okay to me. looks good to me, with or without the first sentence. it's true, anyway. the GPL is often a source of misunderstanding and confusion. witness KDE, for example. if ettrich is willing to write this for LyX, then maybe he'll do the same for KDE? i hope so. Michael - Forwarded message from Matthias Ettrich [EMAIL PROTECTED] - If we do something like this, I'd rather suggest a text like: The GPL is often a source of missunderstanding and confusion. As we understand the license, redistribution and use of LyX in source and binary forms, with or without modification, are permitted without any additional conditions. Even more, we would explicitely like to encourage people to distribute LyX in both source and binary forms. This permission certainly includes linking against GUI toolkits like XForms, Motif, GTK, Qt or Win32. If that is still ok for Debian, I could live with it. Michael? - End forwarded message - craig -- craig sanders
Re: KDE gone, Lyx next ?
On Mon, 12 Oct 1998, Raul Miller wrote: Craig Sanders [EMAIL PROTECTED] wrote: there is no combined work until the source is compiled, linked to the non-free library, and a binary produced. Please show me where the GPL says this. I'm tired of pointing out this is false, quoting from the GPL to show you were it says different, and having you ignore that. similarly, i am tired of pointing out the errors in your misinterpretation of the GPL. as i suggested before, lets agree to disagree and stop wasting energy on this argument. you are well within your rights to be as wrong as you please. craig -- craig sanders
Re: KDE gone, Lyx next ?
On Mon, 12 Oct 1998, Raul Miller wrote: Craig Sanders [EMAIL PROTECTED] wrote: similarly, i am tired of pointing out the errors in your misinterpretation of the GPL. Er... could you at least back up your assertions with quotes from the GPL which support your position? i have done so on numerous occasions over the last few days. you don't seem to get the point. craig -- craig sanders
login time limits in slink???
anyone know what it is in slink which is enforcing idle-timeout and daily time limits on serial lines? i've hunted all over (even to the point of grepping every file in /etc, /bin, /usr/bin, /sbin, /usr/sbin) for it and can't find it anywhere. how do i turn it off? i don't want time limits. craig -- craig sanders
Re: login time limits in slink???
On 15 Oct 1998, Paul Crowley wrote: Craig Sanders [EMAIL PROTECTED] writes: anyone know what it is in slink which is enforcing idle-timeout and daily time limits on serial lines? I don't have this problem, and I haven't installed idled: Description: Idle Daemon. Removes idle users. Idled is a daemon that runs on a machine to keep an eye on current users. If users have been idle for too long, or have been logged on for too long, it will warn them and log them out appropriately. yeah, i know about idled. i even package a similar daemon for debian (timeoutd). i don't have idled or timeoutd or anything similar installed on the machine in question. that was the first thing i thought of. this idle timeout only seems to occur for logins on a serial line (both terminal and ppp logins), never on console or a pty. thanks for the suggestion, but it doesn't help. this problem seems specific to slink...perhaps a new login binary does it. craig -- craig sanders
Re: Removing Gnome [was: Removing Packages in Slink for Debian 2.1]
On 16 Oct 1998, Manoj Srivastava wrote: If we are going to staret removing packages because of the quality of the software, wonderful. I move to remove all traces of the travesty of editors, vi, from Debian, since obviously as editors they are less than alpha quality software. and we should get rid of that emacs thing too. any editor which takes that much memory and takes that long to start up is way too bloated to be in debian. :-) (a joke. i'm not serious. read on for a more serious comment.) I also want to remove csh and variants, cause they all suck And we should remove them right now, like yesterday. agreed. i'd vote for that. (i'll leave it up to the reader to decide whether i'm serious about this one or not :) Since when has Debian yanked software that seems to work based on quality? It is not as if there were higher quality older versions that were superceded by inferior versins; this is new software, and not likely to violate the principle of least surprise. ordinarily i would agree with you on this issue. however, Jim Pick (who wrote the original message suggesting that gnome should be removed) is the maintainer of the gnome packages. i reckon it's his call...if he doesn't want the bug reports from alpha quality software, that's up to him to decide. maybe a compromise would be to leave the packages in slink, make sure the Description: field highlights their alpha status, and automatically close all non-packaging bugs (and forward them upstream if it makes sense to do so). craig -- craig sanders
Re: login time limits in slink???
On Fri, 16 Oct 1998, Hamish Moffatt wrote: On Thu, Oct 15, 1998 at 12:21:06PM -0400, Mitch Blevins wrote: FWIW - I have the same problem. No idled. No logoutd. No lines in /etc/porttime. Still get booted off the console after several hours. Perhaps it's your shell; tcsh has auto-logout functionality. nope. i create all new accounts with bash (*csh sucks). the problem also occurs with ppp logins - in fact, that was how the problem was noticed. craig -- craig sanders
Re: login time limits in slink???
On Sun, 18 Oct 1998, Bernd Eckenfels wrote: On Sun, Oct 18, 1998 at 10:03:30AM +1000, Craig Sanders wrote: nope. i create all new accounts with bash (*csh sucks). the problem also occurs with ppp logins - in fact, that was how the problem was noticed. perhaps cpu seconds limit enforced by ulimit? See ulimit -a nope. the messages printed are specifically mentioning either 1) that the idle timeout has been exceeded, or 2) that the daily time limit has been exceeded. this is very strange as the machine in question has no timeout daemons (timeoutd, idled, autolog) installed. it's a plain slink install with internet-gateway dialin-server type packages installed (squid, apache, qmail, mgetty, pppd, etc) i've built many similar boxes and haven't encountered this problem before. it seems specific to slink. craig -- craig sanders
Re: login time limits in slink???
On Sun, 18 Oct 1998, Bernd Eckenfels wrote: On Sun, Oct 18, 1998 at 11:30:26AM +1000, Craig Sanders wrote: nope. the messages printed are specifically mentioning either 1) that the idle timeout has been exceeded, or 2) that the daily time limit has been exceeded. Only on serial lines or on telnet/ssh/console, too? Are u sure there are no idle logout daemons installed? Some of them run from crontab so you wont see them in ps. i've only noticed it on serial lines. it certainly doesn't happen on root ssh logins. i don't use telnet, and the machine is at a remote location so i don't know if it happens on the console -- i built it by logging in at the console, of course :-), and i don't remember it happening then. i should test whether it is specific to non-root logins as well. ssh as a normal user rather than as root. craig -- craig sanders
Re: agreeing with the DFSG (was Re: non-free -- non-dfsg)
On Mon, Jan 18, 1999 at 06:19:46PM -0600, Ossama Othman wrote: Hi Craig, I get the impression that my objectivity is being misinterpreted again. not sure what you mean by that. i thought i was quite careful to state that i was using a generic you in my examples, and not referring to you personally. if you got that impression, then i apologise because that was not what i intended. IMHO, the idea that developer's should agree with the DSFG and/or the social contract in their entirety is dangerous and will only hinder Debian. I don't agree with all of Debian's policies, nor should I have to. However, I became a Debian developer knowing full well what Debian's policies are and I will follow them. i agree. i don't think developers have to 100% agree with every single one of debian's policies. I do think, however, that developers should agree to abide by debian policies, and working within debian's constitution to effect any changes, and (more importantly) they should agree with the spirit of the social contract and DFSG. unfortunately, spirit is an ill-defined and nebulous thing, hard to pin down exactly. The Social Contract and the DFSG are a good attempt to define debian's spirit. When I can longer do so, and that may never happen, I will leave. This isn't a threat or anything of the sort. your comments about leaving when/if you can no longer agree with debian's policies is kind of what i meant. i don't think anyone should be kicked out (except perhaps for extreme cases, which i cant/dont want to imagine right now), but that their own priorities for what they feel worthy of donating the time/energy to, and perhaps their own sense of honour, will make the decision to leave. similarly, i think that people who don't have a committment to debian's spirit shouldn't join up as developers in the first place. they should find somewhere more in tune with their own beliefs...they'd be happier and more productive, and so would we. BTW, people have left debian in the past for several reasons - including running out of time (i.e they graduated or got a new job), and also over major disagreements in direction. some have gone on to do other, equally worthwhile and valuable work either by themselves or in another group. My concern is that Debian is becoming (almost) elitist. what's wrong with elitism :-) there's too much mediocrity in the world. more elitist high quality stuff is needed. Some people are flat out saying conform or get out, in a sense. Is this really a healthy attitude for Debian to have? i think you are greatly exaggerating the strength of the comments that have been made. OTOH, if someone ever did something seriously damaging to debian i would hope that they did have the decency to voluntary get out without dragging us all into a huge fight over whether they should be kicked out or not. I happen to admire Debian a great deal. If I feel that Debian may be doing something that may hurt itself then I will speak up about it, just as any Debian user should. yes. should is the right word here. The fact that my opinions go against what is apparently the Debian mainstream way of thinking doesn't mean that I should leave. however, if (after you have had your say) the majority of developers think you are wrong and the vote goes against you then you should either a) shut up about it for a reasonable period of time - several months at least, or b) voluntary leave if you can't do (a). If used properly, diversity of opinion should only help Debian. Those with opinions that differ from the mainstream should not be branded heretics or encouraged to leave. you could have the debian chicken (in a slashed-circle) branded across your forehead. we should put that in our constitution. heretics to be branded and marched out with a cattle-prod. maybe have different brands for the different heresies so that all can see at a glance what kind of perversion the branded one will try to lead them into. btw, if you think that paragraph needed a smilie then you need to get out more and relax a bit. craig -- craig sanders
Re: non-free -- non-dfsg
On Wed, Jan 20, 1999 at 01:18:37AM -0600, Ossama Othman wrote: Ossama Looking at it from the author's point of view, the author may Ossama feel that Debian's definition of free is wrong and his is Ossama right. So he may also think about Debian that there is Ossama indeed something wrong that they should know about. This is all very interesting, and so on, but where is this leading? All kinds of people may have all kinds of opinion about Debian. The point is? The point is that it easy to say I am right and you are wrong. Who makes us right and them wrong? i think you're missing the point. the point has nothing to do with who is right and who is wrong. the point is that as far as Debian is concerned, the DFSG is THE test of whether a program is free or not. if a program passes all of the criteria, it is free. if a program fails any one of the criteria, it is non-free. debian's archives are run according to debian's policies. we'd be hypocrites, otherwise. craig PS: while it is true that a large majority of the free software / linux community tends to agree with debian about what makes software free or non-free (witness the rapid and enthusiastic adoption of the Open Source Definition, which is the DFSG with debian references stripped out), that is also irrelevant... neither software authors, nor users, nor the communities, nor anyone except debian developers get a vote when it comes to debian's policies. nor should they. -- craig sanders
Re: agreeing with the DFSG (was Re: non-free -- non-dfsg)
On Wed, Jan 20, 1999 at 02:32:45AM -0600, Ossama Othman wrote: The fact that my opinions go against what is apparently the Debian mainstream way of thinking doesn't mean that I should leave. however, if (after you have had your say) the majority of developers think you are wrong and the vote goes against you then you should either a) shut up about it for a reasonable period of time - several months at least, or b) voluntary leave if you can't do (a). I'd agree with you more about this if more developers were more vocal about how they feel. Right now less then a quarter of the developers seem to express their opinion or even vote (someone correct me if I am wrong). what this means is that less than a quarter of developers care enough about specific issues to argue it or vote about it. that's no surprise, most developers have time to work on one or two (or a dozen or more) packages but are not at all interested in the political bullshit. ignore the silent majority (and especially ignore anyone claiming to represent them). this is as important in debian as it is in the real world. in debian, the silent majority have their opportunity to debate issues just like anyone else. they have their opportunity to vote. if they choose not to debate or vote, then they either don't care or are just wishing people would stop crapping on and wasting everyone's time. or something else. but whatever it is they think is irrelevant - an abstain vote is neither for or against...it is not counted at all. craig ps: debian-devel isn't a philosophy debating society. -- craig sanders
Re: Dpkg Update Proposal
On Wed, Jan 20, 1999 at 11:36:00PM -0500, Andrew Pimlott wrote:
On Wed, Jan 20, 1999 at 04:03:26PM -0500, fantumn Steven Baker wrote:
Package Naming Scheme
The problem is superficial. Sure, names should be more uniform, but all
this requires is 1) ratifying naming standards and 2) ensuring that the
packaging system handles name changes gracefully.
i agree. in fact, it's more like a solution searching for a problem than
even a superficial problem.
from the descriptions that have been posted of how rpm handles
installing multiple versions of a package, i am *very* glad that debian
doesn't do anything even remotely similar. that way lies madness (and a
broken system).
IMO, debian's de-facto method of handling this (i.e. different package
names) is much better - it puts the responsibility for ensuring that
differing versions of a package are compatible squarely where it
belongs: with the package maintainer.
to illustrate the point:
the following are currently installed on my workstation.
ii libgtk1 1.0.6-2The GIMP Toolkit set of widgets for X
ii libgtk1.1 1.1.2-2The GIMP Toolkit set of widgets for X, unsta
ii libgtk1.1.111.1.11-1 The GIMP Toolkit set of widgets for X, unsta
ii libgtk1.1.121.1.12-1 The GIMP Toolkit set of widgets for X, unsta
ii libgtk1.1.12-de 1.1.12-1 Development files for the GIMP Toolkit, unst
ii libgtk1.1.12-do 1.1.12-1 Documentation for the GIMP Toolkit, unstable
ii libgtk1.1.5 1.1.5-2The GIMP Toolkit set of widgets for X, unsta
ii libgtk1.1.6 1.1.6-1The GIMP Toolkit set of widgets for X, unsta
ii libgtk1.1.9 1.1.9-1The GIMP Toolkit set of widgets for X, unsta
libgtk1 really is a different package from libgtk1.1 - it provides
shared lib support for binaries linked to that particular version of
libgtk, whereas libgtk1.1 provides support for binaries linked against
it's version.
ditto for libgtk1.1.{5,6,9,11,12}.
the libgtk* versions are compatible with each other. the libgtk*-dev
versions, are not (it would be possible to make it so by installing
header files in /usr/include/gtk-VERSION, but you'd still have to modify
every source file that #included it. in other words, it could be done
but probably isn't worth the effort unless it's done upstream as well).
fortunately, the -dev packages conflict with earlier versions, so it's
not a problem.
debian's way of handling this allows for all versions of libgtk to be
installed simultaneously, allowing progress AND backwards compatibility
without conflict.
BTW, this is only a problem because the upstream libgtk1.1.x changes
the programming interface without changing the .so number. they've got
valid reasons for doing so (and they do advertise that fact), so there's
really no need to come up with a general solution to a specific problem
with one or two unstable/rapid development upstream packages.
as soon as libgtk stabilises, the problem will go away of it's own
accord. in the meantime, we can live with a few extra packages in our
unstable dist.
craig
--
craig sanders
Re: Intent to package rolldice, blackjack
On Thu, Jan 21, 1999 at 04:04:20AM -0500, Stevie Strickland wrote: rolldice is a virtual dice roller that takes in a string on the command line in the format used by some fantasy role playing games like Advanced Dungeons Dragons[1] and returns the result of the dice rolls. i wrote some dice-rolling routines several years ago (when i still had time to play RoleMaster, long before i got into linux). it handled all the standard dice-rolling conventions, as well as the high/low/both open-ended rolls used by RM (roll d100, if 01-05 then roll again and subtract, if 96-00 then roll again and add. keep on rolling and adding/subtracting if you get 96) i wrote a bunch of related stuff too. was basically writing myself a GM's reference chart/character gen/campaign notebook/dice-roller/etc for RM, but never got around to finishing it, and then moved to another state and never found time to start a campaign again or find players. that's the good news. the bad news is that it was all done in turbo pascal. however, the algorithms were clean and readable, so easily ported to C. if you're interested, i'll dig up the files (i still have them on tape somewhere...i think. dusty old code from the early 90s :-) and mail them to you. i'll GPL them first, so you can do what you want with them. craig -- craig sanders
Re: Dpkg Update Proposal
On Fri, Jan 22, 1999 at 12:02:55AM -0800, Joey Hess wrote: Craig Sanders wrote: i agree. in fact, it's more like a solution searching for a problem than even a superficial problem. It's a problem that is only evident to people who haven't lived with it for years. That doesn't mean it's not a problem. took me a minute to figure out what you meant. ok, i'll sort-of agree with that. i don't think it's a problem in itself, but it points out a documentation problem. from the descriptions that have been posted of how rpm handles installing multiple versions of a package, i am *very* glad that debian doesn't do anything even remotely similar. that way lies madness (and a broken system). Just because rpm does it wrong doesn't mean dpkg couldn't do it right. true. but i think that the right way of doing it is pretty much the way we are doing it, by putting the soname or version number in the package name to distinguish it from other versions. ii libgtk1.1.12-de 1.1.12-1 Development files for the GIMP Toolkit, unst ii libgtk1.1.12-do 1.1.12-1 Documentation for the GIMP Toolkit, unstable ^^^ By the way, this also illistrates another facet of the problem. Dpkg wasn't even designed with package names this long in mind. yes, that's a bug in dpkg's output routines. it's hard-coded for 80 column displays. it doesn't affect debian's handling of long package names, just the output of 'dpkg -l'. i think i reported this as a bug a long time ago. debian's way of handling this allows for all versions of libgtk to be installed simultaneously, allowing progress AND backwards compatibility without conflict. And there's no reason installing multiple versions of a package and using versioned dependancies and conflicts wouldn't allow the same things. why risk adding complication when what we have works? i think dpkg's existing problems should be fixed before features of doubtful merit are added. This isn't just something that affects a few developmental packages. It affects packages like these: libc5 libc6 procmeter procmeter3 ncftp ncftp2 gimp gimp1 communicator-base-406 communicator-base-407 communicator-base-45 [ above list edited slightly from original to minimise line-count ] libc5 and libc6 ARE different packages. ncftp and ncftp2 appear to be a mainline and a forked version. gimp is the stable release, gimp1 is the unstable beta. the various versions of communicator and navigator conflict with each other. don't know about procmeter/procmeter3. By my crude count there are over 300 packages like these in the distribution that have to mangle their names to differentiate versions. 300 sounds like a lot...are you including all shared libs and -dev and -altdev packages? in any case, i don't see it as a problem. IMO, the fact that they have different package names is USEFUL information. it tells me that there's something possibly weird or dangerous going on and i should be extra careful before i select it in dselect...maybe even switch to another shell and investigate further by unpacking the package in /tmp and reading the changelog or readme.Debian before installing it. craig -- craig sanders
Re: Debian goes big business?
On Wed, Jan 20, 1999 at 06:12:14PM -0500, Ben Pfaff wrote: Laurent Martelli [EMAIL PROTECTED] writes: ChL == Christian Lavoie [EMAIL PROTECTED] writes: ChL Bottom line: Debian should remain developer controlled. What about non-developper users ? Shouldn't they have a word to say, even if they can't or do not have the time to contribute with code ? They should have `a word to say', and they do--they can subscribe to Debian lists and give their feedback and advice, which developers are free to follow or ignore. But they do not, and should not, IMO, have the privilege of voting or otherwise setting policy. Users are not developers and shouldn't presume to be. i mostly agree but wouldn't put it anywhere near that strongly. users are not developers, but they might be one day. one of the good things about debian is that users who are willing to put in some work CAN join up as developers. i started that way a few years ago, and i'll bet that most debian developers did too. craig -- craig sanders
Re: Dpkg Update Proposal
On Fri, Jan 22, 1999 at 02:05:26PM -0800, Joey Hess wrote: in any case, i don't see it as a problem. IMO, the fact that they have different package names is USEFUL information. it tells me that there's something possibly weird or dangerous going on and i should be extra careful before i select it in dselect...maybe even switch to another shell and investigate further by unpacking the package in /tmp and reading the changelog or readme.Debian before installing it. So you want new users to be scared/confused into doing this with all 300 packages? systems administration is a job for an informed and alert mind. a trained chimp can fake it for a while, but will come unstuck when anything 'unusual' happensit's far better for the MCSE genes to be discovered sooner rather than later. craig -- craig sanders
Re: Debian goes big business?
On Fri, Jan 22, 1999 at 10:38:54AM +0100, J.H.M. Dassen wrote: On Fri, Jan 22, 1999 at 20:26:12 +1100, Craig Sanders wrote: i mostly agree but wouldn't put it anywhere near that strongly. I would. Ben's phrasing strongly reminds me of Robert A. Heinlein; especially of the concept of TANSTAAFL and the political system he describes in Starship Troopers, where the right to vote must be earned through a tour of duty of public (not necessary military) service. In the case of Debian, users do not have the right of vote, but can earn it by becoming developers (i.e. by maintaining packages, but also by writing documentation, maintaining the website etc.). such a system works fine for an organisation (like debian) where participation or membership is completely voluntary. it would suck for the real world where participation in the nation state is involuntary, and there's nowhere outside to go to. Heinlein wrote some good books, but you've got to be careful in your reading if you want to avoid adopting some of his more fascist pro-militaristic and ultra-capitalist politics. Also, the sexual politics was certainly quite progressive for the '50s and '60s but comes across is being old-fashioned sexist trash these days. his stuff is still an enjoyable read, though (if you ignore complete crap like the number of the beast). Pournelle's even worse. in partnership with Niven he writes some great stories. take the politics with a large grain of salt, though. Must admit I like the Think of it as evolution in action phrase, though i use it in contexts quite contrary to their usage :-) (BTW: TANSTAAFL was Larry Niven, not Heinlein IIRC) i better stop now before debian-devel detours into an sf crit list for a while. craig -- craig sanders
Re: No intend to package vbox
On Wed, Jan 20, 1999 at 11:36:23AM +0100, Paul Slootman wrote: I was thinking of the following packages: isdnutils contains the basic isdnctrl, ipppd stuff needed for networking isdnmonitoring isdnlog, imon, xisdnload, ... that sort of thing isdndocs the faqs and other docs isdnvbox vbox If anyone has better suggestions (I haven't really thought hard about this yet) I'd like to hear them (please include reasoning). i like the idea. i don't use vbox or isdnlog at all. 'isdnmon' is probably a better name than 'isdnmonitoring'. also, i've been meaning to submit a bug report about the following: one thing that would be really great would be if isdnutils could be upgraded WITHOUT taking down any running ippp connections. it's a bit difficult to upgrade isdnutils on a remote server when your only way of getting to is via an ssh session over the ippp0 link. the ssh package used to have a similar problem - all ssh sessions were terminated when the package was upgraded...which meant i needed a telnet daemon running in order to safely upgrade ssh (which defeated part of the purpose of using ssh). anyway, take a look at how ssh solved that problem...there may be useful ideas in there for you. you want me to submit a real bug report or is this message enough to get it added to your TODO list ? craig -- craig sanders
Re: Reality check! [was: Re: Debian goes big business?]
advantage of it? Or should i better switch to SuSE now and renounce at all what makes Debian superior, just to not waste my time with things i already know and don't need to learn again and which my system could do all alone without my involvement? For professional jobs i need a system which is easy to maintain and which saves my valuable time without requiring the knowledge i've had to acquire. if you can contribute to the bootscripts so that it makes for an easier/faster install then that will be a good thing. ditto for if you can come up with tools or whatever to automate configuration tasks without dumbing it down. but if you can only come up with something which achieves simpler or easier configuration at the price of flexibility then you will not get a lot of support from many people here. install junk like that on your own system if you must, but don't try to turn debian into some sort of linux for untrained chimps. Hey, installations are terribly bothersome processes and Debian's installation is the most cumbersome and lengthy of them all. it aint that bad. it could be streamlined a bit, and there should be an option for non-interactive installs but it works, and it works well. the hardest part is running dselect to select from all the packages. this difficulty is inherent in the number of packages available in debian these days. choosing from 2000 packages takes more time than choosing from 400 packages. hamm was released with a pre-selections wrapper, where you could chose certain sets of pre-selected packages. it works, but could use some improvement and probably needs to be updated for slink - there's a good place for you to expend your energy if you care about this. i build lots of debian systems, most of them very similar to each other in the packages which are installed...so i make use of the tools available: dpkg --get-selections and dpkg --set-selections. used properly, they can eliminate almost entirely the need to run dselect during the initial install. 1. boot on rescue floppy 2. partition and format drives 3. install kernel, modules, and base system 4. reboot 5. after setting the root password, quit immediately from dselect 6. install apt by hand with 'dpkg -i'. configure apt for my local mirror. 7. grab my selections file with ftp and feed it into 'dpkg --set-selections' 8. run dselect, choose apt as the install method 9. if building an 'unstable' system, run Select to resolve any weirdnesses/differences between unstable-NOW and unstable as it was when the --get-selections was run. 10. choose Install from dselect's menu. apart from getting rid of postinst questions in various packages, i don't see how that could be made any simpler or easier. it certainly couldn't be done without limiting my choices and obstructing mewhich may be 'simpler', but it sure as hell wouldn't make it any 'easier'. I'd want to have an installation which would save me quite some hassle and would save me the need to help out my friends when the try installing Debian on their own. Why shouldn't an independent company do something about it? I'd happily pay for a Debian diskset which features a dead easy install and maintenance if it really saves me the precious time i could use for more worthwhile things. What's so bad about that? nothing at all is bad about that. if someone or some company wants to create a simplified distribution based on debian, they they are at liberty to do so. most debian developers would even see that as being a Good Thingtm. We are not talking about plain Debian as it stands now but about another project which is simply and only based on Debian. Don't get confused about it please. good. glad to hear it. i'd hate to see debian itself dumbed-down merely to serve a market which is already adequately catered for, at the expense of the technically-literate market. craig -- craig sanders
Re: Reality check! [was: Re: Debian goes big business?]
On Sat, Jan 23, 1999 at 07:14:35PM +, thomas lakofski wrote: As an experienced Debian user, I'll second these sentiments. Since buzz I've been waiting for the Debian installation process to become a (as it should be) 30 minute process, hopefully with some tools included for mass installations. I use Debian myself exclusively but have to hesitate before recommending it to others new to Linux because the process of getting started is harder than it should be. improvements can certainly be made in the rescue-disk install scripts. i think everyone agrees that they're not perfect. however, the biggest problem is not a matter of easy vs hard. it is a matter of scale. it takes a long time to run dselect when there are over 2000 packages in debian. for mass production of machines, there are tools which can make that faster (see my reply to paul for a summary of the process i use). I also am disappointed with the attitude of some people towards making these things easier to do. Is it some kind of techno-snobbery, maybe? i think it's more practicality than snobbery. there aren't any 'easy' configuration tools which don't achieve their simplicity at the price of flexibility. Making things easier does not necessitate dumbing-down things for more competent users. if you, or anyone else, can implement an easier way without dumbing things down then it will be received very happily. unfortunately, nobody has yet come up with such a thing. Once up and running, a Debian system is far more maintainable than the alternatives -- a great factor in on-going ease of use. agreed. and one of the reasons that debian is more maintainable is because we haven't taken the easy way out and replaced text-file configuration with semi-adequate gui/menu-based configuration. Can some focus be brought to getting there with similar ease? I've been with Debian for over 2 years now and would be sad to have to abandon it in the long run because of 'we don't do that' politicking instead of pragmatism amongst developers. there's two sides to that coin. debian's way is to do it Right. To do something right is hard, a lot harder than doing it wrong. i would like it if debian had a right solution to easier configuration (and for some packages we do...look at sendmailconfig for example)...but i would much rather nothing than doing it wrong. implementing a bad solution now would make it much more difficult (nearly impossible) to migrate to a good solution in the future. craig -- craig sanders
Re: cron has gone to UTC time?
On Wed, Jan 27, 1999 at 09:16:23PM -0600, Steve Greenland wrote:
On 27-Jan-99, 16:54 (CST), Douglas Bates [EMAIL PROTECTED] wrote:
On a slink machine I have a crontab entry that should perform an rsync
of a site that I mirror around 22:40 my time (-0600). I have started to
get the reports from the job a little after 16:40 my time which just
happens to be 22:40 UTC.
[...deleted...]
The other interesting thing would be a list of the packages you have
newly installed or upgraded recently -- Jason Gunthorpe thinks there may
be a relationship. Anything you can think of would be a help...
Assuming, of course, that the machine involved can be used in this way.
If it can't be done, no problem, but if you see it again, please do as
much as the above as you can before you restart cron.
debian-devel folks: if any of you see similar behaviour in cron, and if
you have the time, please try the above experiment.
i've noticed this behaviour in the past, when xntp gets upgraded in the
same dselect run as cron or sysklogd.
what usually happens is that cron and/or sysklogd start running in UTC
time. I think (guess) this happens because cron and syslogd are both
restarted before xntp is restarted.
it happened to me yesterday when i upgraded from xntp3 to the new ntp 4
package.
easily fixed with /etc/init.d/{cron,syslogd} stop, followed by start.
craig
--
craig sanders
Re: WARNING: Re: debhelper /usr/bin/passwd
On Sat, Jan 30, 1999 at 10:06:30PM -0800, Stephen Zander wrote: Brian == Brian May [EMAIL PROTECTED] writes: Brian My versions of dpkg claim that --force-overwrite isn't on Brian be default (otherwise it should have [*] after it): As does mine: and it lies! I've been testing package upgrades dpkg itself is very definately using --force-overwite which is a damn good thing. please, nobody suggest changing the default behaviour until dpkg has a config file in /etc allowing each system admin to choose what the default should be. i get really sick of apt/dselect upgrades not working in unstable because some people have the mistaken belief that --force-overwrite should default to off. yes, you can override it on the dpkg command linebut there is no way to override it if you use dselect or apt. this is evil. craig -- craig sanders
Re: fearless sailtrip (aka the DPL goes on vacation)
On Sat, May 15, 1999 at 01:22:13AM +0200, Wichert Akkerman wrote: Anyway, I hope Debian will still exist and be in good shape when I return. Oh, and with lots less release-critical bugs of course ;) hehe. we know what the mice do when the cat's away, but what mischief do the cats get up to when the catherd's away??? :-) craig ps: i have no idea if catherd is a real word or not. by analogy to shepherd. -- craig sanders
Re: (LONG) Correct non-US solution
On Mon, May 17, 1999 at 12:40:44AM -0700, Jonathan Walther wrote: Package: ssh Export-Restricted: United States Import-Restricted: Russia, France i haven't had time to read or think about your entire proposal yet, but my initial reaction to this is that using country names is wrong, it should instead use the ISO country codes. i.e. us, ru, fr instead of United States, Russia, France. second reaction is that Use-Restricted and Patent-Restriced may be useful fields as well. some countries may not care about import, but do restrict usage, and some may not restrict import or export but patents exist to restrict usage or sale. craig -- craig sanders
VA and debian boxes (was Re: evan leibovitch and the LPI certification tests)
On Tue, May 18, 1999 at 08:35:30PM -0400, Brian Almeida wrote:
As for preinstallation, let me make two points:
a) Debian really has a long way to go for someone to do mass installs
of it, unattended.
it certainly could be easier, but it's not that hard. i build many
debian boxes...it just takes a lot of experience with debian and a good
knowledge of how to use the available tools ('dpkg --get-selections' and
'dpkg --set-selections' are very useful). I usually build them like
this because i like to use unstable rather than stable (in my experience
the only drawback to this is that there are some days when it is unsafe
to build a machine and i have to wait another day or two for fixed
packages to appear in my debian mirror)
for serious assembly line mass-production of boxes using the stable
release of debian, i would build one standard server (or maybe a
selection of two or three standard configurations - web server, file
and print server, and internet gateway) and use 'dd' or 'tar' to
duplicate the drive. finally, follow that up with a perl or sed/sh/ed
script to customise the config files.
i've done this many times (e.g. to build ppp dialin boxes for schools -
except for IP address and hostname and other minor details, the machines
are identical to each other), and it works. There is no difference
between a debian box built this way and one built using the standard
boot floppies.
e.g. put new server on bench, plug into network. boot with floppy which
NFS mounts a directory containing a .tar.gz file of a complete working
debian installation. partition the disks. untar the archive. run lilo.
run a perl script to customise things like hostname, mailname, ip
address, etc.
(alternatively, the same thing could be done with a custom-burnt CD ROM
rather than an NFS mounted tar archive)
any further customisation can be done by the customer using dpkg
and apt-get. prefer postfix over exim? no problem, apt-get install
postfix. don't want samba? no problem, dpkg -r samba. the important
thing is to have debian (at least base and networking) installed and
working...from that point on, maintaining the system and installing
packages is easyeven from thousands of miles away.
...
Also consider this, linux.com is a 100%-debian drive site - from the
impressions I've gotten, the VA people are really big on Debian, but
for the reasons above aren't doing preinstalls of it. Don't be so
quick to judge things.
agreed. VA really like debian (and they do a lot to support us).
my partner recently tried to get two debian servers from VA Research.
The guy she spoke to was quite knowledgeable about debian and understood
the reasons why she wanted debian rather than RH (to summarize:
quality), but was embarassed to admit that VA dont have the staff to
support debian. He said that VA's debian-using customers generally
don't need a lot of support...but when they do, it is for something
really obscure and difficult which their support staff can't handle.
in short, VA would like to provide debian servers but don't have the
staff or time to do so...they're working flat-out already.
Even so, he went to a lot of trouble to find a VA Research employee who
would take a contract job to install debian on the servers (he said many
of their techs use debian). he wasn't able to do so in the time-frame
that my partner had for installing her servers...so she got someone
from Frontier Global (the co-lo facility the servers were going to) to
install debian for herVA supplied the hardware, GF installed debian.
(btw, this was all organised remotely from australia, via email and
telephone).
a few things seem immediately obvious to me from this:
1. maybe there should be official discussions between debian and VA
Research to figure out what features we could add that would enable VA
to start offering debian boxes again...they used to build them in the
past.
2. there may be an opportunity for debian developers and experienced
debian users to provide contract setup, support, and consulting services
for debian boxes through VA Research - it certainly can't hurt to
contact them.
3. if you want a co-located debian box, Frontier Global is a good
option. their main co-lo facility is not far from VA Research, and
they had debian installed and running very quickly after receiving the
hardware from VA.
craig
--
craig sanders
Re: evan leibovitch and the LPI certification tests
On Tue, May 18, 1999 at 06:10:14PM -0500, David Welton wrote: Personally, I'm happy to know that I'm involved in making a kick ass OS, and as long as no one messes with my ability to do that, I'm fine. hear! hear! couldn't agree more. RH isn't competition to debian except in the most positive sense of friendly rivalry. We have different aims, different goals. Their goal is to produce and market a linux distribution which keeps their company financially viable. Our goal is to produce a distribution which does what we want with entirely free software. Sometimes these goals co-incide or complement each other. sometimes they don't. They certainly don't conflict or harm each other. craig -- craig sanders
Re: (LONG) Correct non-US solution
On Wed, May 19, 1999 at 07:51:31PM -0400, Richard Stallman wrote: Also, I am not sure it is useful to distinguish between use-restricted and patent-restricted, given that the consequences would be the same. the reason i suggested having a patent-restriced category is that patents don't necessarily prevent individuals from using the patented technology in their own home, they only prevent the commercial exploitation of that patented technology. e.g. if i hear of a cool idea for a new and/or improved gadget, i can build one myself and use it whenever i like. i can even tell my friends how to do the same. what i can't do, however, is sell it without licensing the technology from the patent holder. what is the difference between sharing the plans for a gadget, and sharing the source code for a program? in other words, it's debatable whether a software patent entitles a company to sue an individual for compiling and using free source code that implements their patented algorithms. craig -- craig sanders
Re: Time to rewrite dpkg
On Wed, May 19, 1999 at 04:12:51PM -0700, Brent Fulgham wrote: Ideally, a library would (in addition to it's C++ functionality) have a C interface that doesn't really deal with the issue of objects. Say, something that would accept some standard C types and structs, and return same. in other words, the sensible thing to do is to write a C library and also write a C++ wrapper for it (as well as perl, python, java, scheme, guile, or whatever wrappers). this is a never-ending debate, it pops up again and again but IMO, C is the common language which can be interfaced to from any other language, so C is the language of choice for general purpose libraries. for example: this, and related reasons, is why GNOME chose C rather than C++ as the base language for GNOME projects. Their decision was sound, and their reasons were sound. craig -- craig sanders
Re: Time to rewrite dpkg IN IDL! :)
On Thu, May 20, 1999 at 08:45:09PM +0200, Marcus Brinkmann wrote: On Fri, May 21, 1999 at 12:27:32AM +1000, Craig Sanders wrote: C++ may be OO, but it's not very good OOand it tends to compile into code which is both bloated and slow. dpkg is already far too slow on old hardware...hell, it's too slow on a P200 with 200MB of RAM, now that the status and available files have over 3300 packages detailed in them. Yeah, it's slow, and it's written in C. And you want to cinvince me by your un-emotional argumentation that it will be even slower in C++? Strange. Last time I took a look at Stroustrups language it seemed that it would be carefully designed to not enforce too much overhead on language features, and no overhead on language features not used. Stroustrups book goes into detail, and always mentions which run time overhead you have to expect when you use a certain language feature. Most features are only one function call away. in theory, theory and practice are the same. in practise, they're different. i've always favoured practical considerations over nice theories. In practice, C++ programs are larger and slower than they ought to be. craig -- craig sanders
Re: Time to rewrite dpkg IN IDL! :)
On Thu, May 20, 1999 at 10:09:34PM +0200, Marek Habersack wrote: Now you've proven it. You're a fanatic. And you offend people. Thanks. there's no excuse for personal attacks. if you have a point to make, then make it but don't stoop to ad hominem attacks. i think i'll just ignore the rest of the thread now...it probably isn't worth reading if it's got down to this level. craig -- craig sanders
Re: evan leibovitch and the LPI certification tests
On Fri, May 21, 1999 at 04:44:08AM -0700, Craig Brozefsky wrote: Tyger Sunshine-Hill [EMAIL PROTECTED] writes: If we don't, what is the point of pouring so much work into making such a useful and _flexible_ distribution? Well, everyone has their own answer to that, but I'm satisfied that me, and my employer and some of my freinds are able to use this marvelous system. precisely! the point of debian (in fact, the point of all free software) is not world domination or market share. the point of it all is that it is available for use, modification, and sharing by those who want it. we're not here to get 100% market share, or 50% or even 20%. we're here to make the best system we can and share it amongst ourselves and with others, and also to encourage others to join in the effort. craig -- craig sanders
intent to orphan: spamdb
i'm finding that the spamdb is of little use these days, as most MTAs today have built-in support for RBL, the DUL RBLs, rejecting mail from unknown domains, and postfix even has regexp header checking now. i had intended to rewrite the package properly in perl - i've always considered the current sh script versions to be just a proof of concept...but it hardly seems worth the effort now, most spam can be filtered out long before spamdb gets involved. i really don't have time to do much work on a package which isn't very useful any more. (another issue is that all the cron-job downloads of SpamDomains and Spammers and SpamNets from my home web server makes my internet connection very slow for most of every Sunday) comments?? craig -- craig sanders
Re: An 'ae' testimony
On Fri, May 21, 1999 at 11:47:59AM +0100, Jules Bean wrote: I was just mindlessly (in a tongue-in-cheek way) evangalising Debian on a mailing list I'm on, and I got a private response from a SuSE user. He had installed Debian from a CD (he didn't say which version, I'm afraid) and 'vi fstab' to mount his old partitions. Then he had attempting to do something which would have worked in vi (he didn't give specifics) but doesn't work in 'ae', which resulted in the file getting mangled, and saved. So he switched to SuSE. I'm aware this isn't a particularly helpful post - I'm not suggesting a solution, I don't know what the solution is. But it makes you think. i think that the solution is for ae to print the following in inverse text on the top line of the screen: THIS IS NOT VI. IT ONLY LOOKS SLIGHTLY LIKE IT. YOU HAVE BEEN WARNED! imo, ae's vi emulation is better than nothing...but can be quite dangerous if you're not aware of the fact that it isn't vi. someone (miquel, perhaps) made elvis-tiny a year or two back, and it fit on the boot disk. would be nice if it could be made to fit again. elvis isn't as good as vim, but it's much better than ae. craig -- craig sanders
Re: An 'ae' testimony
On Sat, May 22, 1999 at 12:04:20AM +0200, Paul Seelig wrote: ae is one of Debian's most overlooked weak spots IMHO... :-( i don't think it's overlooked...this discussion comes up too often for that. it's more that space is very limited on the boot disks. even elvis-tiny needs 65K. craig -- craig sanders
Re: An 'ae' testimony
On Fri, May 21, 1999 at 01:48:03PM -0700, Chris Waters wrote: Craig Sanders [EMAIL PROTECTED] writes: someone (miquel, perhaps) made elvis-tiny a year or two back, and it fit on the boot disk. would be nice if it could be made to fit again. elvis isn't as good as vim, but it's much better than ae. Better for the experts who know vi, not as good for the novices who have no idea what vi is or how to use it. you misunderstand what i meant. i'm not suggesting elvis-tiny in place of ae. i'm suggesting it in place of ae's crappy vi emulation mode. i don't care at all if ae is on the boot disks or not...i'd just like to see a decent vi as well because it's something that always gets me when i'm building a new system (usually when editing /etc/fstab). *i* know it's not really vi. but my fingers don't. hail eris! craig -- craig sanders
Re: An 'ae' testimony
On Fri, May 21, 1999 at 06:01:26PM -0700, Joseph Carter wrote: vi - hard to use, but small. correction: hard to learn, easy to use. small, fast, and powerful. craig -- craig sanders
Re: An 'ae' testimony
On Fri, May 21, 1999 at 11:20:12PM -0700, Joseph Carter wrote: On Fri, May 21, 1999 at 10:51:03PM -0700, Steve Lamb wrote: Then we should ditch the vi idea altogether. Why? Sure, *some* experienced people will expect it. Here's one experienced person who doesn't, however. What I *do* expect is an *easy* editor, not one that conforms to how I work. A simple script that tells them to use ee would be fine I think. They'd live. Gods, it's just a flippin' boot disk for crying out loud! no, it's more than just a boot disk. it's a rescue disk. some version of vi is essential on a rescue disk, regardless of what some windows using loudmouth happens to think (and no, i'm not referring to you here joseph). They WILL SURVIVE. I'd say just leave ae, except that given my problems with it, I would never want to be stuck needing an editor I can't promise will even work in 5 minutes. ae is fine except for the vi emulation mode. it does the job, a simple no-frills no-features text editor. the only problem with it is that it's vi emulation sucks, which isn't ae's fault...it's our fault for trying to make it do more than it can. ee is the right choice. ee is better than ae, no doubt about it. however if there's 50+K available on the rescue disk for ee it would be better to use that space for a decent minimal vi clone (elvis-tiny needs ~67K). craig -- craig sanders
Re: An 'ae' testimony
On Sat, May 22, 1999 at 04:18:45PM -0700, Joseph Carter wrote: On Sat, May 22, 1999 at 05:34:58PM +0200, Marcus Brinkmann wrote: ae barely even WORKS! It's crap in vi mode, it's crap in every other mode, it's just crap! = I'd have to say that _PICO_ is a more functional editor than ae, at least it works. Isn't PICO non-free? (similar to pine). Slap me if I am wrong here. Yes, but it is the standard newbie editor. it's not debian's standard newbie editor and can't be because it's non-free. end of story. pico is out of the picture. if you like pico then write a free clone. I think a growing segment of people agree that ee should replace ae 2, so far. maybe more. nowhere near as many as those who want vi in some form on the boot disks (which is why we have ae's vi emulation mode now...and we'd have elvis-tiny too if we hadn't had to switch to slang). for the base disks. I'm guessing slcurses would be used for that, and I think there is some slight bit of porting involved for that. I'd be interested to know how much there is if anything, I'd be interested in building mp3blaster and joe against slang. curses sometimes has annoying bugs. ae does the job of a simple no-frills editor in ~20K. ee does it in ~50k (*) ae wins. that extra 30k (if it is actually available on the rescue disk) would be better used either as part of the space needed by elvis-tiny (**) or by a second copy of ae hacked to remove the non-modalness which dale said were what is causing the problems with the vi emulation. if the second copy didn't have to carry the baggage of supporting a non-modal mode :-) , it may be possible to get the vi emulation to a decent state. it *almost* works now, which is what is so annoying about it. (*) ee requires ncurses now...but i'm assuming it can be ported to slang's slcurses.h if somebody is motivated enough to do it. (**) elvis-tiny needs ncurses now. again, i'm assuming it can be ported to slang using slcurses.h. i made a start on this yesterday and cleared up a few dozen trivial problems (elvis' own curses.h redefines many slcurses.h macros) but ran into a problem with elvis' qfaddch macro which requires more knowledge about curses than i currently have. craig -- craig sanders
Re: An 'ae' testimony
On Sat, May 22, 1999 at 07:54:57PM -0400, Michael Stone wrote: On Sun, May 23, 1999 at 09:47:33AM +1000, Craig Sanders wrote: that extra 30k (if it is actually available on the rescue disk) would be better used either as part of the space needed by elvis-tiny (**) or by I still don't understand the sentiment that people can only understand vi. it's not that vi is the only editor which is understood. it's more that when you're in a hurry trying to fix some system that has gone down you don't have time to mess around learning some stupid editor which doesn't do any of the things you need it to do. being restricted to a primitive editor after you have become proficient with vi is akin to re-learning how to talk after having a stroke...you've lost some really fundamental ability which you take for granted. when you know vi you don't need to remember the commands, you just think about what changes you want to make and (metaphorically speaking) your fingers do the rest. having to use a primitive editor reduces you to hunt-and-peck typing and having to think about each individual keystroke. Are other editors really so difficult? yes. difficult and clumsy and lacking basic functionality. craig -- craig sanders
Re: An 'ae' testimony
On Sun, May 23, 1999 at 02:40:12AM +0200, Josip Rodin wrote: Well, what can the bootdisk makers say about that, but - who cares?! I use joe all the time, but I do not complain that the boot disk doesn't contain it, and that I am restricted to a primitive editor and I have to think about each individual keystroke etc etc... you are making the mistake of assuming that the boot disk is solely for installation of new debian systems. it's not. it's called the rescue disk for a reason. you are also making the mistake of assuming that joe is in any way a standard tool. it is not. the only two text editors which can lay claim to being a standard part of any unix are ed and vi. You have to have a broader view (is that the expression?) in this case, since it is not only yours boot disk, but everyone elses. i think it is you who needs the broader view. the world is not composed entirely of newbies seeking escape from dos/windows. in fact, it's fair to say that complete newbies aren't our target market, we make a high quality distribution perfectly suited to experienced unix users. even so, we support them by including a simple editor (ae) on the rescue disk...why should we do less for our target market? debian has been criticised in the past for failing to include vi on the rescue floppy. we copped a lot of flack for not having one as it is a tool which any experienced unix user can reasonably expect to find on a rescue floppy.which is why we ended up with ae's vi emulation. it may not be real vi, but it's infinitely better than nothing. If you want all of the stuff you commonly use on the boot disk, modify it yourself. Simple :) i don't want all the stuff i commonly use. i just want the bare minimum, and that includes a decent editor. craig -- craig sanders
Re: An 'ae' testimony
On Sat, May 22, 1999 at 03:16:18PM -0500, John Goerzen wrote: Well put, Dale. I think you have done the correct thing here. If the vi emulation is not sufficiently complete to work as expected of vi, and esp. if it's really bad, remove it. i disagree. while ae's vi emulation is far from perfect, it should not be removed until there is a replacement which can fit on the rescue disk. craig -- craig sanders
Re: An 'ae' testimony
On Sun, May 23, 1999 at 02:35:37AM -0500, Manoj Srivastava wrote: What doesn't ae to? As an editor for a damaged system, it seems to work well. you can't yank lines. you can't cut and paste. you can't exec a program and have the output inserted in the bufer. you don't have multiple undo and redo. you can't pipe a block of text through a program. you can't join lines reliably. to change anything you first have to delete the old text and then type the new text. it's more reliable and less hassle to just re-type an entire line than it is to edit it. you can't do regexp search and replace. there is no way to visually distinguish between tabs and spaces. these are just some of the basic things that are missing or wrong in ae...there are many more, without even beginning to count the more useful advanced functions. ae is an adequate minimal no-frills, no-features text editor. it's better than cat. it's even better than pico (which isn't hard). it's no substitute for vi. being restricted to a primitive editor after you have become proficient with vi is akin to re-learning how to talk after having a stroke.. Ahem. vi non-primitive heh-heh-heh. yes, vi IS non-primitive. do not mock what you fail to understand. .you've lost some really fundamental ability which you take for granted. when you know vi you don't need to remember the commands, you just think about what changes you want to make and (metaphorically speaking) your fingers do the rest. having to use a primitive editor reduces you to hunt-and-peck typing and having to think about each individual keystroke. Are vi users less capable, or more inflexible, than users of better editors? I think you are doing vi users a dissservice, labeling them so incapable and unadapting. no, vi users are not less capable or more inflexible (and there are no better editors -- emacs is not a text editor, it's a programmable editing environment. if you like that kind of thing then more power to you...but emacs is also no substitute for vi). i thought i explained it well enough. vi is the sort of tool that when you get good at it becomes like an extension of your thoughts - you don't have to consciously think about HOW to do something, you just think about WHAT you want to do and it happens. this doesn't mean that vi users are less flexible or less capable. it means that trying to use some other less capable editor is like trying to edit with one hand tied behind your back and three fingers of your remaining hand chopped off. you can do so much more with vi that anything less is a major handicap. i fail to see any further point in this thread. it's gone on way too long already. the fact is that vi is a basic unix tool which should be availablenot providing it on the rescue disk when we can do so would be absurdly laughable if it weren't so outrageously blinkered and pedestrian. Anyway, every one knows that vi is primitive ;-) i expected better of you than pointless cheap shots like this. guess i was mistaken. craig -- craig sanders
Re: An 'ae' testimony
On Sun, May 23, 1999 at 02:40:48AM -0500, Manoj Srivastava wrote: and that includes a decent editor. That rules vi out, then. for politeness' sake i will interpret your remarks in the most positive light possible: you are mistaken. craig -- craig sanders
Re: An 'ae' testimony
On Sun, May 23, 1999 at 02:11:03AM -0700, Joseph Carter wrote: On Sun, May 23, 1999 at 10:10:56AM +1000, Craig Sanders wrote: Are other editors really so difficult? yes. difficult and clumsy and lacking basic functionality. All that missing functionality in ee (and ae in normal mode) is present in ae in vi mode? Yeah. no, most of that functionality is missing from ae's crappy vi mode. that is why it would be good if there were room for elvis-tiny to fit on the boot disks, and that is why i object to the idea of wasting space on the rescue floppy on 'ee' when it is basically the same as 'ae'. if there is any extra space on the boot floppy then it should not be squandered on ee, it should be used for something useful - a decent vi, preferably. You argued that vi mode SHOULD be preserved even if it was broken. yes, i have argued that ae's vi emulation is better than nothing. craig -- craig sanders
Re: How to handle the jargon file?
On Wed, May 26, 1999 at 07:11:49PM +0100, Edward Betts wrote: On Wed, 26 May, 1999, Dave Swegen wrote: Just curious really, but which format does the dict-jargon package use? None, I forgot about that one, it uses its own format. So that is ANOTHER version of jargon, I presume it is still 4.0.0 and not yet updated to 4.1.2 my feeling is that the dict format is the best format to use for the jargon dictionary - then it works for command-line queries and can be wrapped in a cgi for html output. maybe esr could be convinced to use dict as the 'source' format and generate html or whatever else from that? craig -- craig sanders
Re: demo vs. real package: FYI (was Re: Announcing debconf, configuration management for debian)
On Fri, Sep 17, 1999 at 02:45:32PM -0400, Raul Miller wrote: FYI, sash_3.3-5 (which has been sitting in Incoming for the last couple weeks) no longer prompts at postinst time, as the postinst/prerm scripts have been completely redesigned. do they automatically set up sash as root's shell? craig -- craig sanders
Re: sash (was Re: demo vs. real package: FYI (was ...))
On Sun, Sep 19, 1999 at 06:30:37PM -0400, Raul Miller wrote: On Fri, Sep 17, 1999 at 02:45:32PM -0400, Raul Miller wrote: FYI, sash_3.3-5 (which has been sitting in Incoming for the last couple weeks) no longer prompts at postinst time, as the postinst/prerm scripts have been completely redesigned. On Mon, Sep 20, 1999 at 07:18:09AM +1000, Craig Sanders wrote: do they automatically set up sash as root's shell? They don't touch the root account. Instead, they clone it as sashroot and set the shell on the cloned account. cool. i was just checking that the discussion from two weeks ago on how/what to do hadn't been forgotten. This is mentioned in the package description. even better :) craig -- craig sanders
Re: anarchism_7.7-1.deb
On Fri, Sep 24, 1999 at 05:59:07PM -0400, Jaldhar H. Vyas wrote: The criterion should be utility. wrong. we've had this censorship discussion many times before. the only criteria for inclusion in debian is: - is it free? - could someone be bothered doing the work of packaging it? if the answer to both questions is yes, then there is no justification for refusing the package. The Bible as a literary and cultural foundation of Western civilization will be useful to a lot more people than the Anarchism package. 'utility' is a subjective thing. i personally would find the anarchist faq far more useful and interesting than (a bad translation of) religious texts. craig -- craig sanders
Re: Useless packages (was Re: anarchism_7.7-1.deb)
On Sat, Sep 25, 1999 at 02:51:36AM -0500, David Starner wrote: On Sat, Sep 25, 1999 at 07:28:57AM +, Lars Wirzenius wrote: David Starner [EMAIL PROTECTED]: Instead of each developer chose what packages are and aren't useful to them, why don't we look at the popularity contest? A simple, bias-free way of seperating programs on to the CD's, by actual use. That is what it was made for. http://www.debian.org/~apenwarr/popcon/ says *** THIS IS EXPERIMENTAL!! *** Try not to get upset if the results are incorrect, but be sure to e-mail me if you think there's something funny going on. I wouldn't base decisions on it yet. i wouldn't base any decisions on it ever. that's not it's purpose. Is there any reason to think it's not correct? more to the point, is there any reason to think that it matters whether it is correct or not? the popularity contest is for informational (entertainment) purposes only, not for decision making. the usefulness of a package has nothing at all to do with it's popularity - it may be unpopular because it is an obscure and specialised tool but to those who know and need it, it is essential. the survey was never intended to be a means of deciding whether packages are useful or not. nor was it intended for deciding whether to include a package in debian or not. at most, it is a tool for *helping* to order packages on a CD (and even that is of limited use because it mostly shows the popularity of old packages in the last release but not new ones in the current unstable). craig -- craig sanders
Re: anarchism_7.7-1.deb
On Sat, Sep 25, 1999 at 09:10:19PM -0400, Jaldhar H. Vyas wrote: - is it free? - could someone be bothered doing the work of packaging it? if the answer to both questions is yes, then there is no justification for refusing the package. Yes but the maintainer should also ask - Does it enhance Debian? if it is useful or interesting to even one person then it enhances debian. in other words, this is not a useful question to ask - if it wasn't of value to at least one person then they would not have bothered to package it. many of the packages in debian are in debian because the maintainer felt that they were useful to them personallyif others benefit from it too, that is good but it is sufficient that the maintainer has, by their work, made debian that much more useful to themself. i, and i guess many other developers, originally joined debian so that some useful tool or program would become part of debian. this is one of the strengths of debian...all of us are here because we want to make debian better or more useful, and one of the prime motivators is to make it more useful to ourselves. our policy and technical standards are a framework which allows us all to do that without conflicting too much with each other. Not because he has to but because he should want to. And other developers and users should feel free to comment. yes, others are free to comment but there is no justification other than non-freeness for excluding a package from debian. The reason is that we are not just shoveling packages on a CD but at least trying to put together a finished product. and it is the maintainers job to create their package according to policy so that it becomes a smoothly integrated part of the whole that is debian. 'utility' is a subjective thing. i personally would find the anarchist faq far more useful and interesting than (a bad translation of) religious texts. I understand. But would the entire Debian constituency? (Which is what? Just the developers? Developers + users? All Linux users...) If we are interested we could find out. it's irrelevant whether other debian developers or users agree with me or disagree with me about the relative utility of these two packages. by not censoring packages, by refusing to censor packages, we create a distribution which is good and useful for everyone - not just those whose needs are the same as the censors. some find the bible package useful and i don't begrudge them that - if it makes debian more useful to them then it is a good thing that it is included. we should not be censoring, we should not be saying the bible is good but the koran or bhagavid gita or even the anarchist faq is worthless. or vice-versa. if something is free and someone does the work to package it then we accept it in the distribution. This has been a bit of a rant. Let me try and add something constructive. It looks like we are going to 3 CDs. In the future we will only get bigger. How do we manage that growth while not irritating users (swapping CDs sucks) or censoring maintainers? most suggestions have been variations of the following idea: to put all doc and data packages (especially those not directly associated with a program) on a CD by themselves. that seems like a good idea to me. One approach which has been suggested is to make extra cds by section. So a data CD could include the bible, anarchy FAQ etc. Perhaps at some point there will be a ham radio cd, electronics cd etc. This has the advantage of being infinitely extensible but I worry that it narrows the scope of Debian for the general user as most CD vendors especially the cheap ones will probably not bother with the extra CDs. actually, it would increase the scope of debian as a general purpose distribution - there would be something in it for everyone. if we get to the point of having specialty CDs then those who want them will be able to purchase them from specialty vendors or download the packages for free from the net. craig -- craig sanders
Re: Packages should not Conflict on the basis of duplicate functionality
On Sat, Sep 25, 1999 at 01:10:51AM -0400, Raul Miller wrote: Perhaps there are people who want a service enabled by default policy, and perhaps we should accomodate them. However, I'm not one of them and I don't want any services turned on on some of my machines without my explicit ok. then don't install those services. installing a package *IS* an explicit OK. you've been using debian long enough to know that this is the way it worksand IMO, it is the way it should work. i don't want to have to fuck around with explicitly turning services on when i install them - if i didn't want them to run then i wouldn't have installed them. what you are proposing is more work, more hassle, more stupid questions to answer for every install. if you want something different from the default then you can implement in whatever way seems best to you for your systems - but don't force it on everyone else. craig -- craig sanders
Re: Censoring :) (was: Re: anarchism_7.7-1.deb)
On Mon, Sep 27, 1999 at 11:46:19AM +0200, Siggy Brentrup wrote: Craig Sanders [EMAIL PROTECTED] writes: it's irrelevant whether other debian developers or users agree with me or disagree with me about the relative utility of these two packages. by not censoring packages, by refusing to censor packages, we create a distribution which is good and useful for everyone - not just those whose needs are the same as the censors. some find the bible package useful and i don't begrudge them that - if it makes debian more useful to them then it is a good thing that it is included. we should not be censoring, we should not be saying the bible is good but the koran or bhagavid gita or even the anarchist faq is worthless. or vice-versa. Is it really censoring to keep all non-technical packages out of main? I don't say don't package it nor don't make it available. that's a different question entirely, and not one that i'm addressing. my point is that if we accept one into main then we have no justification for not accepting all. if we decide that non-technical documents (i.e. anything which is not documentation or tutorial material for a program - literature, mythology, philosophy, etc) do not belong in main then that applies to all such packages. if it's free and it's packaged then we accept it into the dist in the location defined by policy - at the moment, that's debian main. we probably should, as has been discussed before, have an etexts and a data section for this kind of stuff. if something is free and someone does the work to package it then we accept it in the distribution. There should be one for the main distribution. Assume I want to go into the CD business providing support for packages in the main dist. No major problem with most of the packages, but I am not willing to support packages with philosophical, political or religious contents. that's ludicrous. what support is needed for texts? customer: i can't read foo-text. tech support: have you tried opening your eyes sir? craig -- craig sanders
Re: Packages should not Conflict on the basis of duplicate functionality
On Mon, Sep 27, 1999 at 03:21:34AM -0400, Raul Miller wrote: On Mon, Sep 27, 1999 at 01:05:58PM +1000, Craig Sanders wrote: then don't install those services. installing a package *IS* an explicit OK. You're saying that packages reliably say when they provide daemons? no, but it should be pretty obvious from the description. e.g. a pop server package is going to install a pop server. a web server package is going to install a web server. etc. this should be self-evident. craig -- craig sanders
Re: Packages should not Conflict on the basis of duplicate functionality
On Wed, Sep 29, 1999 at 12:52:16AM -0400, Mark W. Eichin wrote: no, but it should be pretty obvious from the description. e.g. a pop server package is going to install a pop server. a web server package is going to install a web server. etc. this should be self-evident. True, but don't forget the case of an initial install - you pick some profile, and get lots of stuff, with no hints. (In this case, I like they idea of a debconf global flag of prompt me about daemon enablement, which is kind of the *reverse* of what most people want debconf for...) IMO that's the price you pay for saying install a whole bunch of random stuff i haven't personally selected. if you cared, you'd take the time to vet all selections yourself. if you don't care, accept whatever the selection set gives you. if you discover later that you actually DO care, then uninstall or disable the relevant package. (generic you used in above paragraph, not referring to you personally) If you doubt that this is an issue, consider ipmasq: it was part of one of the standard install profiles, I don't even know which one -- but it badly confused one firewall and at least two laptop installs that I know of personally, because it automatically enabled certain safety rules that were wrong in the non-masq multiple-interface case. sounds like a bug in either the ipmasq package or in the selection set. or both. The ipmasq maintainer has since made the rules for firing that much more rational, we did work out some reasonable approach which I forget so it's solved. where's the problem? at the moment - I just want to bring it up as a point of actual experience with the initial install startup case... ok. i just don't think it's as big a deal as some people do. more to the point, i think that doing the opposite (i.e. not enabling services by default when a package is installed) will cause even more problems (and confusion and hassle) to everyone else. i.e. there's a tiny minority who are inconvenienced by daemons being enabled when a package is installed. there would be a huge majority who would be inconvenienced if the reverse were true. it looks to me like it's an either/or situation (i.e. no way of satisfying both parties at once - mutually exclusive needs) so it's a pretty easy choice to make...cause the minimum harm/hassle/inconvenience. craig -- craig sanders
Re: dhcp-dns problems
On Wed, Sep 29, 1999 at 12:58:08AM -0400, [EMAIL PROTECTED] wrote: I have a small network @Home and use dhcp to dole out the ip's, I use the dhcp-dns package so that I can refer to these boxen by name and so that various network utilities will work. Recently I've started getting emails to root from Cron saying update packet failed. have you recently upgraded to the latest bind in potato (8.2.1-1 or later)? if so, then you need to be aware that the config file location changed from /etc/named.conf to /etc/bind/named.conf, and the zonefiles in /var/named now live in /var/cache/bind. make sure you edit /etc/bind/named.conf to include everything that was in /etc/named.conf BTW, your message should have been submitted as a bug report and not posted to debian-devel. debian-devel is for issues related to debian development, not user support. craig (package maintainer for dhcp-dns) -- craig sanders
Re: Packages should not Conflict on the basis of duplicate functionality
On Wed, Sep 29, 1999 at 01:08:31PM -0400, Laurel Fan wrote: Excerpts from debian: 29-Sep-99 Re: Packages should not Con.. by Craig [EMAIL PROTECTED] IMO that's the price you pay for saying install a whole bunch of random stuff i haven't personally selected. if you cared, you'd take the time to vet all selections yourself. In the initial install, is it possible to go in and unselect and select packages after picking profile/tasks (Or just look at what it wants to install)? yes. dselect is run immediately after the pre-selection stage. The install program and the docs say skip the Select step of dselect... Does it mean skip it because you will confuse the installer or you should skip it because it's already done? it means skip it because i don't want pre-selections. that option is to not run the pre-selection script, to jump straight into dselect. it's the option i always choose when building systems because i prefer to select all packages. crai -- craig sanders
Re: Packages should not Conflict on the basis of duplicate functionality
On Wed, Sep 29, 1999 at 02:27:45PM -0400, Mark W. Eichin wrote: it's an either/or situation (i.e. no way of satisfying both parties Actually, it isn't -- there's an easy way of giving users a choice, and two people have suggested it already (debconf). This seems to be the most Debianish way to handle it - technologically superior, and avoids punishing one set of users at the expense of the other (even if it is a small minority, you don't care about that when you're in it :-) if that can be done, then fine. i'm against changing the default so that it only suits a tiny minority. i'm not against increasing choice. the default should remain as is, though - those who want it different should be the ones who have to take whatever action with debconf. craig -- craig sanders
Re: Packages should not Conflict on the basis of duplicate functionality
On Wed, Sep 29, 1999 at 04:30:45AM -0500, Francois Gurin wrote: Minimun hassle/inconvenience is mutually exclusive of minimum harm. Looking at the example set forth by some of the other distributions (and more than a few operating systems), the reduced hassle of installation and administration is traded for security (which I hope most people will agree is harmful). this is a load of crap. enabling daemons by default is not a security problem. if a particular daemon is a security problem then it should be fixed or dropped from the distribution. if the default configuration of a daemon is a security problem then that config should be fixed or the package dropped from the distribution. craig -- craig sanders
Re: Packages should not Conflict on the basis of duplicate functionality
On Wed, Sep 29, 1999 at 06:38:55AM -0400, Michael Stone wrote: The fantasy is over--WELCOME TO REAL LIFE! It turns out that some people install linux without preexisting knowledge of how to securely administer a unix machine. sorry, it's you who needs to wake up to the real world. if people don't know how to administer a unix machine then they need to learn fast. no amount of molly-coddling by the distribution authors (i.e. us) is going to obviate that essential requirement. maintaining security on your own systems requires personal knowledge and experience, it can not be done by proxy. the we-know-better-than-you attitude is what redhat and caldera (and microsoft, for that matter) does. it sucks. debian has always done better than that - our way is to encourage people to learn to do it for themself by not trying to hide the fact that knowledge and experience is required (not just optional or would be nice but absolutly required) When we ship a system with a bunch of stuff enabled by default, we're not only putting their machine at risk but we're also creating problems for everyone else who's system is attacked by someone using the debian machine as a jump-off point. That's bad. that's bad. it's also bullshit. enabling daemons by default is not inherently a security problem. see previous message. if a particular daemon is a problem then it needs to be fixed or replaced or dropped from the distribution. changing the default so that it is only enabled manually will NOT increase security at all. It's really time to get away from the mentality that everyone needs to have everything turned on all of the time; if a persone really *needs* something enabled, they can figure out how to do it. (If they can't, should they really be administering a network node?) if they don't need it then they shouldn't install the package. why run debian (with all it's useful tools like update-inetd and update-rc.d and so on) if you're going to throw away those advantages? This isn't a UI issue, this is a matter of security and of us taking responsibility for the state of quite a few systems out on the internet which will be configured according to *our* defaults. it's not a matter of security, it's a matter of personal preference. enabling daemons when they are installed is not a security problem. it's damned annoying to see people trying to force their personal preferences on everyone else by making loud noises about trumped up nebulous and vague security issues. it would be nicer if such FUD were left behind in the proprietary software world. craig -- craig sanders
Re: Packages should not Conflict on the basis of duplicate functionality
On Wed, Sep 29, 1999 at 08:50:00PM -0400, Clint Adams wrote: the we-know-better-than-you attitude is what redhat and caldera (and microsoft, for that matter) does. it sucks. debian has always done better than that - our way is to encourage people to learn to do it for themself by not trying to hide the fact that knowledge and experience is required (not just optional or would be nice but absolutly required) You don't think that you only can have one daemon for a particular service and it's going to be turned on by default is representative of the we-know-better-than-you attitude? no, because debian doesn't fuck up configuration by forcing you to go though some stupid and limited GUI interface (try doing something non-standard with network interface setup on RH and you'll know what i mean - you can't do it...actually, you can if you spend enough time figuring out their setup but you risk that your custom mods will be blown away the next time someone runs the stupid GUI configurator). debian's attitude is: if you want something different, DIY. and more importantly, it lets you DIY. craig -- craig sanders
Re: Packages should not Conflict on the basis of duplicate functionality
On Wed, Sep 29, 1999 at 09:26:39PM -0400, Clint Adams wrote: debian's attitude is: if you want something different, DIY. and more importantly, it lets you DIY. Err.. what Unix DOESN'T let you DIY? read the rest of my message. the bit that ranted about unix's that get in the way of DIY. RH is one. sun's Netra is another...both are examples of how NOT to do configuration management on unix. craig -- craig sanders
Re: Packages should not Conflict on the basis of duplicate functionality
On Wed, Sep 29, 1999 at 11:45:13PM -0500, Francois Gurin wrote: And why can't there be an option to determine this? You avoided that point. no i didn't. i answered it in another message. to paraphrase: i am against messing with the current default. i am not against (indeed, i am in favour of) increasing choice. if it is possible to add that choice without screwing anything up and without being a pain in the arse then i am all in favour of it. if they don't need it then they shouldn't install the package. And if the package has a dependency? There are many situations dealing with the package system that can lead to daemons installing without your knowledge. mtools for potato includes floppyd, if someone upgrades a slink machine to potato, should floppyd be automatically started? if mtools needs floppyd to run and the user has chosen to install mtools then yes. the user want mtools to work, they don't want mtools to work ONLY if they do some weird and obscure thing (even if it IS documented in the debian changelog, it is still weird and obscure unless they happen to be aware of the fact that this major change has occurred) which they never needed to do in the past... in other words, mtools used to just work, it should continue to just work after an upgrade. not all packages start daemons automatically. Some ask. Wouldn't it be keen if Joe Bloe knew what to expect? those that ask, shouldn't. there are already way too many stupid questions in postinst scripts. if (via debconf or whatever) there is a way for users to voluntarily specify that they want daemon packages to ask then that would be fine...but it should take some deliberate action on the user's part before they get these annoying questions. craig -- craig sanders
Re: Packages should not Conflict on the basis of duplicate functionality
On Wed, Sep 29, 1999 at 10:38:34PM -0400, Clint Adams wrote: read the rest of my message. the bit that ranted about unix's that get in the way of DIY. RH is one. sun's Netra is another...both are examples of how NOT to do configuration management on unix. No. You're talking about doing something your way and then having it wrecked by the RH/whatever way. And if you decide to do something your way in conflict with the Debian way, Debian may wreck your work too. debian provides methods of having your cake and eating it too. it provides tools for integrating your custom changes into the debian system so that you don't ever have to worry about the system screwing up your custom stuff. If I'm running /usr/local/sbin/sillycommercialpop3d, or /opt/sillycommercialpop/sbin/pop3d or wherever it should be stuck, and I want to install php72-pop3 which Requires pop3-server, this is what the dummy package (or whatever it is called is for). fake up as many Provides: lines as you need. and I naively apt-get install php72-pop3, not thinking it would require a local pop server or thinking that my pop server should be sufficient, if you suffer from this naivety then you need to cure it. expecting software to magically perform some miracle is not going to help you do anything but dig yourself into a much deeper hole. I'd probably end up with a nice little tagalog pop server that installs itself in inetd and steals the port. There are two simple solutions to this. this would be a problem caused by insufficient knowledge/experience on the part of the operator. don't fix the symptom, it'll just come back again...fix the cause instead. Either you do it the Debian way and package up sillycommercialpop with a Provides pop3-server yep, this is another good way of doing it. like the dummy package you get to DIY and still retain the benefits of the packaging system. if you don't like that, then there distributions which don't provide such useful system administration tools. try slackware, for example. When I recommend to people that they use kernel-package instead of DIY, they are usually a bit shocked. kernel-package is a useful tool which helps to DIY. it doesn't conflict with the notion of DIY at all, it makes it easier...especially if you like to compile your kernels on your fastest machine and then ship them out with scp to wherever they are needed. craig -- craig sanders
Re: Packages should not Conflict on the basis of duplicate functionality
On Thu, Sep 30, 1999 at 08:34:48AM -0400, Raul Miller wrote:
On Thu, Sep 30, 1999 at 02:16:31PM +1000, Craig Sanders wrote:
to paraphrase: i am against messing with the current default. i am not
against (indeed, i am in favour of) increasing choice.
There is currently no default -- it varies on a per-package basis.
update-inetd and update-rc.d pretty much establish what the current
default is. they are there to be used by the {pre,post}{inst,rm} to
enable and disable services at install/remove time.
craig
--
craig sanders
Re: Packages should not Conflict on the basis of duplicate functionality
On Thu, Sep 30, 1999 at 09:21:09AM -0400, Clint Adams wrote: There is currently no default -- it varies on a per-package basis. I note that ### to run vtund as a server on port 5000, uncomment the following line: #--server-- 5000 isn't uncommented by default. it isn't useful to run the vtund server until it is configured. there is no standard configuration which is suitable for shipping as a default - it MUST be customised for each site, each tunnel must be setup individually. given that, there is no point at all in running vtund until the user has configured it to meet their needs. other daemons, e.g. pop and imap, work with little or no configuration - install them and they start working immediately. it is useful to enable them at install time. craig -- craig sanders
Re: Packages should not Conflict on the basis of duplicate functionality
On Thu, Sep 30, 1999 at 07:02:44AM -0400, Michael Stone wrote: On Thu, Sep 30, 1999 at 08:05:32AM +1000, Craig Sanders wrote: sorry, it's you who needs to wake up to the real world. if people don't know how to administer a unix machine then they need to learn fast. Not true. you discredit your argument with silly assertions like this. Maintaining a unix-like machine for desktop or personal use requires a different skill set than a machine used as a server. People using linux as a windows replacement or because they want to see what linux is *don't need* a bunch of services enabled *by default*. if they *don't need* a bunch of services enabled *by default* then they shouldn't install the packages that provide those services. most workstations do not need a pop or imap server, very few need an ftp server. those workstation users who install these packages have to take responsibility for their own actions, and they should be presumed to know what they are doing. no amount of molly-coddling by the distribution authors (i.e. us) is going to obviate that essential requirement. maintaining security on your own systems requires personal knowledge and experience, it can not be done by proxy. Agreed, for machines that need public services. But I'm talking about defaults. Can you come up with a reason we *need* a bunch of stuff enabled by default? if a service isn't needed then don't install the package that provides that service. what is so difficult to understand about that? it's not as if people are forced to install rsh or telnet servers any more. Anthony has done a great job of splitting up netbase so that these packages are now optional extras. the we-know-better-than-you attitude is what redhat and caldera (and microsoft, for that matter) does. it sucks. debian has always done better than that This is empty we're better than them propaganda. Debian already makes choices in what services are installed and enabled by default. It does not follow that changing the *existing* list of services we enable by default implies a we-know-better-than-you attitude. ok, i see the communication problem now...why we're going round in circles on this point. i think we're talking about completely different things here. i'm not talking about what debian chooses to have installed by default (i.e. base/required packages). i'm talking about the current practice of postinst scripts in various packages enabling the services that they provide (if any). i am not talking at all about which packages are base or required or extra or whatever - i'm talking specifically and ONLY about what the postinst scripts of packages do when they are installed. install a package which provides a daemon and it *should* be enabled in the postinst. if you don't want the service it provides then don't install the package. of course, if debconf or something can provide a mechanism for the system admin to globally choose whether to enable or not enable services when they are installed then that is even better. but until we have such a mechanism, such packages should do what they always done and enable themselves at install time. A system with daemons disabled will always have a better guarantee of security than one with daemons enabled. In the not-so-distant past we've shipped systems with a vulnerable telnetd and a vulnerable ftpd enabled *by default.* which is one of the reasons why they are now split off from the netbase package - so that people can choose whether they want these services installed or not. splitting netbase was the right solution to that problem...installing stuff but leaving it disabled is a PITA, not a solution to a problem. more to the point, it's a bigger and more annoying problem than the one it is purported to solve. why run debian (with all it's useful tools like update-inetd and update-rc.d and so on) if you're going to throw away those advantages? Why does changing default behavior throw away advantages? What prevents you from using those tools if you want them? the advantage of these tools is that packages can enable the services they provide when they are installed. they don't provide much (if any) benefit to the casual command-line user - it's easier to edit inetd.conf manually than it is to remember the args for update-inetd. craig -- craig sanders
Re: Packages should not Conflict on the basis of duplicate functionality
On Fri, Oct 01, 1999 at 03:13:36AM -0500, The Doctor What wrote: Excuse me. I work for TurboLinux. i don't give a damn who you work for. We make it an EXPLICIT policy to disable all daemons, well, bully for you. i guess that must make you so proud. if someone doesn't want a service enabled then they should not install the package that provides that service. if they want the service, then install the appropriate package. simple. their choice to install or not install. now what is so fucking difficult to understand about that? If it really bothers you, then maybe a global switch that sets whether daemons should just start up or ask first. you must be some kind of genius to figure that out all by yourself. gee, i wish i had of thought of that. i wish several other people in this thread had thought of that. oh. that's right. we did. i guess you aren't such a genius after all. I would beg to differ. In some environments, having an unconfigured server running for 30 seconds is too much. And don't tell me to pulling the net cable. What if it's being installed via the net? DON'T INSTALL THE DAEMON IF YOU DON'T WANT TO RUN IT. WHY IS THE BLEEDING OBVIOUS SO FAR BEYOND YOUR COMPREHENSION? this argument has gone way beyond the point of being tiresome, it is tedious. it is especially tedious when some pompous cretin just spews out trivialities based on some misunderstanding of the thread which is explicable only by you not having read it. no regards, craig -- craig sanders
Re: Packages should not Conflict on the basis of duplicate functionality
On Fri, Oct 01, 1999 at 10:20:41AM -0400, Clint Adams wrote: it isn't useful to run the vtund server until it is configured. there is no standard configuration which is suitable for shipping as a default - it MUST be customised for each site, each tunnel must be setup individually. When did useful enter this discussion? usefulness or utility has always been in this discussion. you should pay more attention. pipsecd starts the daemon automatically even though no tunnel has been set up, and even if userlink-modules hasn't been installed. And even though it is of absolutely no use to you, the daemon starts running when you install the package. And if there's some sort of exploitable back door in the code, you're vulnerable. But fine, you think security is a non-issue. if pipsecd turns out to have a security hole then that MUST be fixed regardless of whether it is started at install-time or not. fixing the bug is the solution to the problem. merely not starting it is no solution at all, that's just hiding your head in the sand. You seem to recognize at least one situation where it is counterproductive for Debian to make an assumption about the user's configuration. Why can you not recognize others? i have little interest left in this tedious thread, so i'll say this once and once only. i really hope you can manage to understand it: vtund was my package to create as i saw fit. I personally saw no need to have the vtund running when it wasn't yet configured, so I personally chose not to have it start until the user configured it. The maintainer of pipsecd, according to your report, made a different choice. that is their right. this is not a matter for policy, this is not a matter where a tiny minority of whiners can have artificial hysterics about fantasy security issues and other FUD. my package, my decision. if you feel that the way i manage my package is a problem, then file a bug report - i'll evaluate that bug report and take whatever action (if any) i feel is appropriate. ditto for the pipsecd package, Samuel can make up his own mind about how to look after his package. by the same token, packages containing other daemons belong to their respective maintainers. if there is any conflict between differing packages, then it is up to the relevant maintainers to sort out a solution - e.g. the emacs and xemacs conflict...until the people responsible for those packages put their heads together and figured it out, it was not possible to have both installed at the same time. now, it is no problem at all. what this means is that if there is a great desire to have several pop packages installed at once, then it is up to the maintainers of the pop packages (and other interested parties) to come up with a way that can be achieved without hassle, and without imposing stupid and onerous burdens on the maintainers of unrelated packages. craig -- craig sanders
Re: How not to be a nice person (Was: Re: Packages should not Conflict on the basis of duplicate functionality)
On Fri, Oct 01, 1999 at 09:06:39PM -0500, The Doctor What wrote: I took care in my message above to remove anything offensive towards Craig. Unfortunately Craig didn't do the same. garbage. you went out of your way to be offensive. to quote the opening line of your message: Excuse me. I work for TurboLinux. the implication here is that you know what you are talking about because you work for a real (i.e. commercial) linux distribution. anyone should be able to guess that that particular attitude is not going to go down well in debian-devel. it's akin to saying that proprietary software is better because the programmers get paid to write it (and, by logical extension, that free software authors are just amateur bumblers). i find posturing based on your employer to be particularly annoying - it's a blatant attempt to cash in on borrowed status. it doesn't work that way here, it's not who you work for that's important, it's what you've done. It is my hope that Craig Sanders reads this and thinks about what he has done and why. very little of what i write is done without review and consideration of the effect of my words. i am a very deliberate writer. i presume that others are just as deliberate. if they're not, then they need to learn more caution and control over the language they use. craig -- craig sanders
Re: How not to be a nice person (Was: Re: Packages should not Conflict on the basis of duplicate functionality)
On Fri, Oct 01, 1999 at 11:38:47PM -0400, Steve Willer wrote: When someone writes things like: well, bully for you. i guess that must make you so proud. and now what is so fucking difficult to understand about that? the word deliberate isn't the first that occurs to me. if you can't comprehend that someone might deliberately choose those words, then that is your problem not mine. such paucity of imagination is truly sad. craig -- craig sanders
Re: How not to be a nice person (Was: Re: Packages should not Conflict on the basis of duplicate functionality)
On Fri, Oct 01, 1999 at 11:52:59PM -0500, The Doctor What wrote: You on the other hand show no thought for anyone else. i show no regard for those who demonstrate they are fools. i show contempt for those who demonstrate that they are annoying fools. guess which category you fall into. in short, say something merely stupid and i will ignore you. say something stupid and irritating and i will rub your nose in it. And finally, just to make sure we're all clear on the matter no regards, craig i had some doubts as to whether you might get the picture. in your case, i thought spelling it out was necessary. or at least see that stabbing at people isn't productive. if it makes fools quit their yapping then it can be highly productive. this discussion is a waste of time. craig -- craig sanders
Re: Packages should not Conflict on the basis of duplicate functionality
On Sat, Oct 02, 1999 at 04:36:04PM +0200, Piotr Roszatycki wrote: I've install postgresql on my home computer. I need this daemon only sometimes. I don't want to start it every time I reboot system. you need to do something non-standard, so you should do a little bit of work to accommodate your own needs. if i needed to do the above then i would edit /etc/init.d/postgresql and (in the case statement) change start) to go). this way, it would not get started at boot time, but i could easily start it by running /etc/init.d/postgresql go. pros: simple. takes 20 seconds with vi. minimal change, so follows principle of least surprise. easy to remember. init.d scripts are conffiles so it won't be automatically replaced at the next upgrade. cons: you have to re-do the change if you ever upgrade and answer Y to dpkg's question about replacing /etc/init.d/postgresql. craig -- craig sanders
Re: Is this a bug in grep, or is it me...
On Fri, Oct 01, 1999 at 04:19:51PM +, Dale Scheetz wrote: This leaves me with the unresolved problem of distinguishing between the two package names. I just read through the grep manpage (again) looking for something that will enforce an exact match, when I realised that I can simply skip this step and do the selection in awk (which I was using before to peel off the section name from the grep output), so the right command is: it seems to me that the word you are looking for (i.e. the package name) will always be the first word on a line, so: grep ^PACKAGENAME override.potato will do the job, and is probably significantly faster than an awk script. craig -- craig sanders
Re: SSH never free
On Sat, Oct 02, 1999 at 10:06:24AM +1000, Herbert Xu wrote: They use libssl, which begs the question why isn't libssl in non-US/non-free? i thought that only copyright/license and *not* patent issues determined whether we considered something to be free or non-free. e.g. libssl is completely free software in the free world, but encumbered by a patent problem in the world's favourite police state. craig PS: the RSA patent expires in 2001 (or is it 2002?), anyway. -- craig sanders
