Provides: scheme-interpreter
I'm trying to package up tex2page and noticed that there is no virtual package for scheme-interpreter. I would like to specify in the "Depends:" that some sort of scheme-interpreter is required instead of having to list each of them individually. Any thoughts on this suggestion? -- Chad Walstrom <[EMAIL PROTECTED]> http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: mass bug filing on packages that are blocking use of cdebconf
Joey Hess <[EMAIL PROTECTED]> wrote: > This is your third and final reminder. I count 542 packages > remaining, down only 9 from last month. I assume most of the people > below do not read debian-devel, so I've taken the librerty of BCCing > you all. :-P Absolutely right. ;-) d-d is too busy. Thanks for the Bcc, but I would not have objected to a bug report. Also, I agree that a lintian/linda rule would be helpful here. -- Chad Walstrom <[EMAIL PROTECTED]> http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Debian experimental package pending upload
In response to the Request For Package (RFP) #280209, [1]_ I've hacked up a quick codeville package. The diff is attached. There are some debian-legal matters concerning Open Source License v2.0 (and even v2.1), so it'll probably end up in non-free (not that I agree with these legal banterings at all). We'll see what the ftp masters do with it. I recall seeing a note on the codeville.org website that the next release may be under a BSD-style license. Is this still applicable? I don't have a LOT of time to maintain the package, so I would be perfectly happy to co-maintain it with someone (anyone interested)? The codeville package is installed against Python 2.3, the default python package for Sarge. If you feel that there should be further restrictions to version dependency or if you would like version specific packages, let me know. (Personally, I think it's overkill unless you're making module packages.) References == .. [1] http://bugs.debian.org/280209 -- Chad Walstrom <[EMAIL PROTECTED]> http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ signature.asc Description: Digital signature
Re: binaries for different architectures in debian packages
I don't read the Debian Devel list all that often, as it's traffic rate is far too much for me to keep up with. ;-) In any case, I was referred to your post by the Debian Weekly News article on it (you're pretty popular right now). I would have to agree with posters that suggested you follow the standard FHS recommendations for file placement: binary files in a /usr/lib subdirectory, architecture independent files in a /usr/share directory, etc. The reason I say this is because coupled with dpkg's ability to specify the root directory for installation, sharing files over the network can be customized by the operating system tools available. For example, using NFS with NIS or LDAP and the automount daemon can automate mounting for diskless clients to the correct, architecture-dependent (/usr/lib) shares as well as the architecture-independent (/usr/share) shares. Installing packages under /srv/arch-os and /srv/common is a real possibility. As a bonus, you can use the same root directories with all (most) Debian packages for all of your diskless clients. A trick with mount, the --bind option, would allow you to bind the /srv/common/usr/share directory to /srv/arch-os/usr/share. NFS, Samba, and Netatalk wouldn't know the difference, allowing you to mount /srv/arch-os as your root filesystem for arch-os. You just need to be careful about how you split up your packages. Using an arch-independent package for the /usr/share files (a common package) and arch-dependent packages for the /usr/lib files should make this type of setup easy. The NFS/NIS book by O'Reilly is a great place to start for planning a network shared infrastructure. Pay particular attention to some of automount's mapfile structure and its ability to specify programs to resolve shares and mount points. -- Chad Walstrom <[EMAIL PROTECTED]> http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ signature.asc Description: Digital signature
Re: [OT] Re: Changes in formal naming for NetBSD porting effort(s)
On Wed, Dec 17, 2003 at 07:43:27PM -0800, Nunya wrote: > The US is pretty adamant about separation of church and state. Which is why the phrase "In God We Trust" is engraved or printed on all the US currency. That's why the Pledge of Allegiance has the phrase, "Under God.." Yeah, adamant. -- Chad Walstrom <[EMAIL PROTECTED]> http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ pgpBTIrBp9QEP.pgp Description: PGP signature
Re: [OT] Re: Changes in formal naming for NetBSD porting effort(s)
On Wed, Dec 17, 2003 at 11:42:27AM -0800, Nunya wrote: > > IOW, lighten up, people. Otherwise, we'll be referring to Debian > > GNU/That Which Shall Not Be Named... > > Nah, bullshit. I've heard enough racists use that kind of reasoning. > "It's no big deal." Face it, you have to respect people. And way out from Right Field... > OTOH, I myself am going to lighten up. :-) Excellent! Maybe this thread will eventually drop. Or maybe I'll just killfile it like I should have a week ago. -- Chad Walstrom <[EMAIL PROTECTED]> http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ pgpSixT4XR20W.pgp Description: PGP signature
[OT] Re: Changes in formal naming for NetBSD porting effort(s)
On Wed, Dec 17, 2003 at 04:42:28PM +0100, Sven Luther wrote: > Well, just for the record, i personnally would prefer we don't use > demon name for keyword if possible. Forgive me for the gratuitous Harry Potter reference, but "fear of a name increases fear for the thing itself." ;-p IOW, lighten up, people. Otherwise, we'll be referring to Debian GNU/That Which Shall Not Be Named... -- Chad Walstrom <[EMAIL PROTECTED]> http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ pgp2BvcsJjaUc.pgp Description: PGP signature
[OT] Re: Changes in formal naming for NetBSD porting effort(s)
On Mon, 15 Dec 2003 17:51:47 -0800, Russ Allbery <[EMAIL PROTECTED]> said: > Well, it depends on what mythology you're working from. In the > Christian mythology, which is probably the dominant context for > evaluating that sort of question, On Tue, Dec 16, 2003 at 01:29:15PM -0600, Manoj Srivastava wrote: > And, pray tell, why is that? Hindu mythology had demons far longer > than Christianity (indeed, probably longer than any of the faiths of > the descendents of Abraham). So what makes the Christian mythology > "more dominant"? I don't think Russ was digging for a fight when he made that statement. Most likely his mind was wandering on more interesting topics, so he didn't qualify each statement with a disclaimer about his opinion. I'm still amused that people equate Loki with evil. ;-) He's just misunderstood! -- Chad Walstrom <[EMAIL PROTECTED]> http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ pgpANGVkzQzE2.pgp Description: PGP signature
Re: No list archives getting updated at all
On Tue, Dec 16, 2003 at 02:52:50PM +0100, Ulrich Eckhardt wrote: > I'm wondering if there's some IMAP (read-only) access to the lists? It > recently occured to me that that would be a Nice Feature(tm), or do I > have a flaw in that idea? No real reason for this. Just grab the compressed mbox once per month and drop it into your mail folder (uncompressed if necessary). We don't need to be eating up system resources for R-O IMAP. -- Chad Walstrom <[EMAIL PROTECTED]> http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ pgp3n2smB2JTT.pgp Description: PGP signature
Re: Proposed change to debian release system
On Mon, Dec 15, 2003 at 08:55:03AM +0100, Marc Haber wrote: > After taking a look at the RC bug count, I don't see debian-installer > holding up things at the moment. Never the less, it has been one of those "must do" items, one of the milestones that needs to be reached before a release is even considered. RC bugs continue to accumulate as long as people feel they have time to fix them and as long as testing is unfrozen. When the release manager makes the announcement that a release is approaching, our attentions are diverted from our own personal projects and packages to those that have received less care. The announcement for release preparation is made, and the cry for help goes out. Hopefully it is heard. Organize some BSP's, people! They are sorely needed. We found out on Saturday's Minneapolis BSP that many of the RC bugs were quick fixes. The 0-day NMU is a blessing (personally, I think this should be a 365-day, full-time policy). Let's take advantage of it. -- Chad Walstrom <[EMAIL PROTECTED]> http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ pgp0eyCRqtLk1.pgp Description: PGP signature
Re: Proposed change to debian release system
On Sun, Dec 14, 2003 at 03:29:10PM -0600, Graham Wilson wrote: > I don't think that is true. I think developers (and users) have a wide > range of opinions as to how often there should be a new Debian > release. I like the "Debian is ready when it's ready" argument. Two years between releases may be a bit long for my taste. A year would be nice, and six months is highly optimistic. Once debian-installer is polished, things should move quicker. -- Chad Walstrom <[EMAIL PROTECTED]> http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ pgpwRp5O6SbzO.pgp Description: PGP signature
Re: debian pxe dhcp netinstall (debconf enterprise fai etc.)
On Thu, Dec 11, 2003 at 08:36:34PM -0500, Nathan Hawkins wrote: > I used grub, though instead of PXE. (Most of the hardware was old, and > very few, if any, of the the NIC's supported PXE.) grub can be built > with network support, and it supported all the NIC's we had. It also > loads the kernel and filesystem from the network faster than from > floppy. :) Heh. grub is among the first things I install, along with screen, sudo, vim, and ssh. ;-) I had forgotten about grub's netboot capabilities. Very cool feature. -- Chad Walstrom <[EMAIL PROTECTED]> http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ pgpAsVZAFi3KD.pgp Description: PGP signature
Re: Bad version number based on date advice in policy?
On Mon, Dec 08, 2003 at 04:20:07PM +, Colin Watson wrote:
> That always struck me as a rather poor idea. What if we have two
> versions of a package, 1:1.0 and 2:1.0? Both will be foo_1.0_$ARCH.deb
> at the moment.
IIRC, the actual filename in the archive is
foo_1.0-${EPOCH}%3a${DEBVER}_${ARCH}.deb.
--
Chad Walstrom <[EMAIL PROTECTED]> http://www.wookimus.net/
assert(expired(knowledge)); /* core dump */
pgpup9YCHZ7kU.pgp
Description: PGP signature
Initrd rocks! (was Re: Backporting 2.4.23 kernel packages)
On Sat, Dec 06, 2003 at 05:11:50PM +1100, Russell Coker wrote: > What is needed for initrd-tools? I've given up on using initrd's for > kernels I compile. That's sad. initrd saved my bacon more than once. ;-) If you like to compile vanilla kernels, either find the Debian cramfs-initrd patch or use romfs. Then change mkinitrd.conf(5) to look like this: MKIMAGE="genromfs -d %s -f %s" I've had problems with "BUSYBOX=yes", so I don't include it. (I should have debugged it -- had to do w/mount and /etc/fstab, but I didn't have the time.) mkinitrd is pretty good about finding your required modules, but it sometimes doesn't get it right. Always mount the romfs file and make sure the modules are there and will be loaded (/etc/modules). Good luck! -- Chad Walstrom <[EMAIL PROTECTED]> http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ pgpCWQVvYCpps.pgp Description: PGP signature
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
On Sat, Dec 06, 2003 at 01:40:58AM -0600, Manoj Srivastava wrote: > -- until there exists a mechanism to convert .desktop entries into > things that the back-end WM's can grok, we are stymied Agreed. > (since we have a system that works, however imperfectly, and dropping > support for these window mangers would be a regression). Never suggested it. Personally, I like menu files. They're simple, direct, and provide a great service to Debian. > The other part is, of course, teaching developers how to write the > .desktop menu item, and I for one, have never seen one. That hasn't stopped us before. ;-p I agree though, it's a learning process. I haven't looked at the menu code, so I don't know how difficult it'ld be to "throw in" a .desktop file parser/converter. Don't get me wrong, I didn't ever suggest abandoning Debian menu. I only suggested that participating in something that may turn out to be a "standard" amongst desktop environments will only benefit us. -- Chad Walstrom <[EMAIL PROTECTED]> http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ pgpnDHrLTlFif.pgp Description: PGP signature
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
On Fri, Dec 05, 2003 at 04:08:41AM -0600, Manoj Srivastava wrote: > > ... It only stands to reason that if both the KDE and Gnome desktop > > camps wish to formalize on the format that we should adopt it as > > well, if only as an extension of our menu system. We would > > have to generate .desktop files anyway, when Gnome and KDE move form > > their own native menu formats. > > You talk as if the whole universe of window managers is merely > gnome and kde. I understand how you might get that, but you have to admit that they are the most visible of the desktop environments. I didn't mention window managers specifically because I don't see the need to make the distinction in this case. The .desktop files has the same goal and focus as a .menu file -- providing a convenient interface to finding and launching applications, so let's keep that the focus of the discussion. -- Chad Walstrom <[EMAIL PROTECTED]> http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ pgpQm2EmGr3TA.pgp Description: PGP signature
Re: debian pxe dhcp netinstall (debconf enterprise fai etc.)
On Fri, Dec 05, 2003 at 01:13:57AM -0800, Mark Ferlatte wrote: > FAI is good, but it doesn't handle updating the systems once you have > them installed. You're absolutely right. The cfengine scripts are also slightly difficult to re-use after the initial installation. A good cfengine setup is hard to beat for managing multiple boxes, but cvsup is certainly a good way to do it. It just goes to show that there is no One Right Way(tm) to do things. I'm excited about debian-installer's modularity. It has the potential to do installs the "right way". -- Chad Walstrom <[EMAIL PROTECTED]> http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ pgpX7N1tLJeLd.pgp Description: PGP signature
Re: debian pxe dhcp netinstall (debconf enterprise fai etc.)
On Thu, Dec 04, 2003 at 05:37:49PM -0800, Mark Ferlatte wrote: > I did what you are trying to do using systemimager, cvs, and cvsup. > ... There are a few rough spots (mostly in that I don't have a fully > automatic way to restart daemons that have been updated in the golden > client, so I have to restart them by hand), but in general it works > very well, and has saved me a lot of time. This is all very well and find if you're using a single architecture with nearly identical hardware setups. Granted, with discover and read-edid, things are a little easier. When you need extreme customizability in installs, FAI does a very good job. It "feels" like a kludge at times, but once you wrap your head around the process, it's actually pretty easy to follow. For your debconf database, you could always create a quick script to copy over an existing database. Or you could possibly look into hacking on the LDAP backend for debconf. I was intrigued by Progeny's autoinstall Python script, but never had a chance to look into it further. -- Chad Walstrom <[EMAIL PROTECTED]> http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ pgpbbRdXTbW5y.pgp Description: PGP signature
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
On Thu, Dec 04, 2003 at 04:49:45PM -0200, Felipe Almeida Lessa wrote: > I think only one thing is blocking the whole idea of moving from > Debian Menu style to freedesktop.org style: the work that need to be > done. In other words, people don't wanna use the .desktop format > because the have already write a debian/menu. Then extend the functionality of the Debian menu system to use .desktop format as both an OPTIONAL target and an optional SOURCE. Doing so might ease the burden and barrier to utilizing .desktop files. It only stands to reason that if both the KDE and Gnome desktop camps wish to formalize on the format that we should adopt it as well, if only as an extension of our menu system. We would have to generate .desktop files anyway, when Gnome and KDE move form their own native menu formats. -- Chad Walstrom <[EMAIL PROTECTED]> http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ pgpVGrAVUYx4B.pgp Description: PGP signature
Re: Two different libpng2_1.0.12-3.woody.3_i386.deb?
On Wed, Dec 03, 2003 at 06:30:16PM +0100, Jeroen van Wolffelaar wrote: > On Wed, Dec 03, 2003 at 05:44:36PM +0100, Santiago Vila wrote: > > file=main/libp/libpng/libpng2_1.0.12-3.woody.3_i386.deb > > wget -q -O 1.deb http://ftp.debian.org/debian/pool/$file > > wget -q -O 2.deb http://security.debian.org/pool/updates/$file > > diff 1.deb 2.deb > > > Binary files 1.deb and 2.deb differ The security archive are updates to the stable archive. The stable archive does not get updated on a regular or even semi-regular basis. It only gets updated periodically, when a new release of stable is made. This is a very formal event. Updates that have accumulated in the security archive may be moved over into the standard archive at this time. Otherwise, they do not intermingle. If in doubt, use the latest stable debian version of the software, regardless of which archive (security or standard) it comes from. -- Chad Walstrom <[EMAIL PROTECTED]> http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ pgpIMdLl8YCZG.pgp Description: PGP signature
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
On Wed, Dec 03, 2003 at 08:02:42AM +0100, Matthias Urlichs wrote: > IMHO, there's no need to discuss this to death -- .desktop files make > sense, therefore packages should supply them. There's no sane way to > ask maintainers to do so except to file bugs, therefore bugs should be > filed, and that's all there is to it. Agreed. If someone has taken the time to create a *.desktop file for the binaries in your package, accept the file and drop it in place. This doesn't invalidate the Debian Menu system in any way. If it turns out to be a better source of data concerning the application for desktop or menuing environments, so be it. It will prompt a critical look at the menuing system as we know it. If anyone wants to create *.desktop files for pnm2ppa or gtimer (currently being adopted by a new maintainer), feel free. -- Chad Walstrom <[EMAIL PROTECTED]> http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ pgptxmCgSKcOQ.pgp Description: PGP signature
Re: debsums for maintainer scripts (was: Re: Revival of the signed debs discussion)
On Tue, Dec 02, 2003 at 02:01:23PM +0100, Bernhard R. Link wrote: > > A true IDS is needed, such as aide, tripwire, or cfengine to detect > > post-installation intrusion. Tie in aide or tripwire database > > checks/updates with the apt.conf "PostInst" option in addition to a > > daily cronjon to ensure the database is updated in a timely manner. > > I think this is even more stupid than using *.md5sums. When they are > daily generated, you have no chance at all to be sure they are not > modified. I'm not following your logic, if that's what you call it. You're saying that checking the current filesystem on a daily basis is NOT a good way to verify filesystem integrity? Update your system when you introduce a known change (a must). Check it daily (a must). What is incorrect about this policy? -- Chad Walstrom <[EMAIL PROTECTED]> http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ pgpHEmhCfxdqF.pgp Description: PGP signature
Re: [custom] Debian Enterprise - a Custom Debian Distribution
On Tue, Dec 02, 2003 at 05:43:21AM +1100, Zenaan Harkness wrote: > - GNU ERP software project ?name? GNU Enterprise (gnue) http://www.gnue.org/ -- Chad Walstrom <[EMAIL PROTECTED]> http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ pgppwhG5wx4GS.pgp Description: PGP signature
Using selections (was Re: [custom] Custom Debian Distributions)
On Tue, Dec 02, 2003 at 05:38:15AM +1100, Zenaan Harkness wrote: > * you can't always create a flavour to do what you want # From a currently installed machine (or chroot)... shell$ dpkg --get-selections > selections shell$ vim selections shell$ mv selections desktop.selections shell$ mailx -s 'my desktop selections' [EMAIL PROTECTED] < \ > desktop.selections # on friend's computer shell$ dpkg --get-selections > my.selections shell$ diff my.selections desktop.selections shell$ sudo dpkg --set-selections < desktop.selections shell$ sudo apt-get dselect-upgrade -u > * improving our mechanisms for supporting "flavours" helps derived > distros and their users I'd be in favor of setting up user's favorite selections lists. Perhaps this would be appropriate for community forum sites, such as DebianPlanet.org? KISS. If the solution isn't simple and elegant, it's probably not ready for prime time. Distributing selection lists via forums, websites and the like is an easy way of creating flavors w/o making structural changes to the Debian project or increasing the package dependency jungle. If you find your "flavor" is quite popular and isn't being sufficiently covered by an existing Debian Subproject, propose a new one. -- Chad Walstrom <[EMAIL PROTECTED]> http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ pgpe41aXyx4KP.pgp Description: PGP signature
Re: debsums for maintainer scripts (was: Re: Revival of the signed debs discussion)
On Mon, Dec 01, 2003 at 06:08:28PM +0100, Eduard Bloch wrote: > Kinda off-topic but nowhere in the discussion the question of checking > already installed files was adressed and it should be asked: md5sums and signatures are most useful in the context of installation. Post-installation, you cannot be guaranteed that an intrusion rootkit doesn't compromise the md5sum files themselves. Using the installed *.md5sum files to check the integrity gives you a false sense of security unless those *.md5sum files are signed or CRC'd as well. Regardless, using md5sums of selected files does not identify files that are not part of that set. A true IDS is needed, such as aide, tripwire, or cfengine to detect post-installation intrusion. Tie in aide or tripwire database checks/updates with the apt.conf "PostInst" option in addition to a daily cronjon to ensure the database is updated in a timely manner. For install-time integrity checking, GnuPG signatures or the existing chain of md5sum and signed Release files should be sufficient without adding undue complexity. Integration of debsigs would be a welcome addition to dpkg. Folling it's creation, does anyone have a case study or success story hailing the usefulness of debsigs? -- Chad Walstrom <[EMAIL PROTECTED]> http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ pgpNJcsrrHvdf.pgp Description: PGP signature
Re: RFC: Create d-user-woody, d-user-sarge maillists, deactivate d-user
On Mon, Dec 01, 2003 at 03:51:44AM -0800, Hereon wrote: > Request For Comment on: > Enhancing the Debian mailing lists by: > Creating debian-user-woody and debian-user-sarge mailing lists, > and deactivating debian-user. Bad idea. It's generally wrong to assume that more email lists will result in better coverage. The more people subscribed to the debian-user list, the more people there are to answer questions. If you split the list, you're not guaranteed that you'll have an even distribution of email across the new lists. Because newbies don't give enough details in their emails to debian-user is not a problem with too many subscribers, it's a problem of information dissemination. They aren't paying attention to the "welcome" message or the info on lists.debian.org. By adding more lists, it will be confusing to users which one they should subscribe to. There is already confusion around the idea of "Which flavor of Debian to you use?" Why perpetuate this by making newbies try to discern which email list they should belong to. "Join debian-user," is simple, concise, and understandable. Finding information on the list is subject to a good indexing application. Some MUA's are very good with searching. You have the mbox for each email list Debian hosts. Download the mbox, import it into your client, and search. -- Chad Walstrom <[EMAIL PROTECTED]> http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ pgpQdiySvGCir.pgp Description: PGP signature
Re: Tabs v.s. spaces
On Tue, Nov 18, 2003 at 11:32:36AM -0800, Tom wrote: > Serious #1: > > *It looks like multi-line method invocations require parenthesis to be > indented at the paren level. Sometimes that's useful, but often I > like to pack arguments tighter than that and indent only once on > subsequent lines: > myreallylongmethodname(bar, bar, bar, bar, bar, > baz, baz, baz); > myreallylongmethodname(bar, bar, bar, bar, bar, >baz, baz, baz); No, this is not true. You are describing implicit line joining, which is described in the Library Reference[1] Section 2.1.3[2]. "Expressions in parentheses, square brackets or curly braces can be split over more than one physical line without using backslashes... The indentation of the continuation lines is not important. Blank continuation lines are allowed." Besides, you don't NEED ';' in Python to end a single statement. > Serious #2: > > Multiple statements per line in diagnostic code and error flow control. > > The operant value in both these cases is some code is relatively > unimportant to the main flow of the program and doesn't warrant gobs of > space. "Real" code should be indented like Python, but if everything is > "proper", "important" code gets lost in a bunch of scaffolding. > Obiviously high equality code should be simple, but sometimes other > values weigh slightly higher than writing perfect code, and flexibility > is useful. You can combine statements (Compound Statements[3]) on a single line with the ';' character... print 'ERROR: You are mistaken'; sys.exit(1) Or control flow constructs... if test: if test2: print x Which could just as easily be written if test: if test2: print x > Light-hearted: > > Sometimes I just feel like writing crappy multi-line, write-only code > because it's not intended to change the world, and I want to see it > all on the screen at once. Many real-world tasks are like this. yay. REFERENCES 1. http://www.python.org/doc/current/ref/ 2. http://www.python.org/doc/current/ref/implicit-joining.html 3. http://www.python.org/doc/current/ref/compound.html -- Chad Walstrom <[EMAIL PROTECTED]> http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ pgpSfe8N5dbhn.pgp Description: PGP signature
Re: Tabs v.s. spaces (was Re: Programming first steps.)
On Mon, Nov 17, 2003 at 06:02:40PM -0800, Tom wrote: > If whitespace mistakes are always caught at compile-time, then I > probably wouldn't care about them either. So I'm not bashing python; > having never used it: I'm bashing languages where syntatic mistakes > are not caught at compile-time. I have no idea if Python is in that > category or not. Python does catch inconsistent indenting at compile time. If you want to catch mixed tabs/spaces for block indenting, run python with -tt. As Stephen clarified earlier, Python uses significant indentation, not significant whitespace. Variables and objects are not defined by whitespace, the nested scope of logical blocks are. -- Chad Walstrom <[EMAIL PROTECTED]> http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ pgpEOupM14RAx.pgp Description: PGP signature
Re: Tabs v.s. spaces (was Re: Programming first steps.)
On Mon, Nov 17, 2003 at 02:19:02PM -0500, H. S. Teoh wrote: > Also, as an off-topic note, blank lines that contain tabs or spaces > are Pure Evil(tm), especially in code. One of these days I should > write a sed script to eliminate all incarnations of this Pure Evil(tm) > from /usr/src. Python did away with that requirement for scope in 2.x. If you want to use blank lines for code logic separation in python < 2.0, you must nest the line as far as the current block. For that reason, I don't use blank lines within class or method definitions when writing for Python 1.5.x. -- Chad Walstrom <[EMAIL PROTECTED]> http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ pgpoxeZnYjtzN.pgp Description: PGP signature
Tabs v.s. spaces (was Re: Programming first steps.)
On Mon, Nov 17, 2003 at 11:13:59PM +0800, Cameron Patrick wrote: > I believe that tabs aren't a problem with Python so long as they > really do indent to a multiple of 8 spaces. Editors which interpret > tabs differently are broken^W^W can cause problems when editing Python > code with tabs and spaces mixed though. This seems to be Python's greatest Achille's Heel as well as one of its greatest assets. Working code in Python has a consistent look and feel. Improper indenting will give a descriptive error that is easy to track down. New programmers feel right at home with it, because it isn't all that significant of a change from psuedo-code outlines. 1. step 1 1.1 substep 1 1.2 substep 2... In addition, you're not forced to use a program like indent(1) or astyle(1) to enforce coding style; it's built into the Python interpretor. I have a love-hate relationship with the significant whitespace. I have always disliked 8 spaces per tab, because it takes up too much screen real estate on an 80 column display. Whenever I coded in C, I set my vi editor to interpret the tabs as 4 spaces. My mistake in using this was displayed when I tried to print with a2ps or enscript, when they were once again interpreted as 8 spaces. Arg! I then switched back to using only spaces for indentation, and this seems to be a consistent approach, but because personal opinion in coding style seems to be a right of passage amongst C coders, I could never get anyone to agree with me. ;-) Even the venerable linux kernel only accepts tabs, IIRC[1]. Another problem. Try cut-n-paste in X between code that uses tabs[2]. Sometimes the tabs are not preserved. Very odd and annoying. In any case, the documentation about how tabs and spaces are interpreted in Python are in the Language Reference[3]. Here's the relavent passage: First, tabs are replaced (from left to right) by one to eight spaces such that the total number of characters up to and including the replacement is a multiple of eight (this is intended to be the same rule as used by Unix). The total number of spaces preceding the first non-blank character then determines the line's indentation. If you continue reading this passage, you will understand why the authors of Python (namely GvR) choose this. It's simple to implement scope via significant whitespace. So, tabs v.s. spaces isn't really a concern except when mixing the two. If you use eight spaces for all indentation, it won't matter. If you use some other number, it's best to use spaces exclusively. If you use tabs exclusively, changing the appearance in your editor may simply be a configuration option away. What will I use? I still haven't decided; probably tabs/8 spaces. ;-p REFERENCES 1. http://www.linuxjournal.com/article.php?sid=5780 2. http://mail.python.org/pipermail/python-list/2001-December/075764.html 3. http://www.python.org/doc/current/ref/indentation.html -- Chad Walstrom <[EMAIL PROTECTED]> http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ pgpAJEKWCjID3.pgp Description: PGP signature
Re: Programming first steps.
On Sun, Nov 16, 2003 at 08:45:51PM +0800, David Palmer wrote: > I thought that I might make a beginning at learning. I've searched > the web, found information that goes beyond the definition of > plethora, so I thought that I'd ask here. C is useful, stable, has a huge following. C++ is useful, changing, and has a huge following. You will most likely find people who know C than C++, and you will often find C++ programmers who write mostly C style code within C++. Perl and Python have different histories. Perl was an evolutionary language whose origin was to replace sed and awk. Python was written as a full-fledged programming language and benefits from this consistency. (Can you tell which one I prefer?) Perl has its usefulness, but I often hear of complaints over maintability when it is use in large projects. You won't find that in Python. > I've already decided to use Vim, steep learning curve apparently, but > comprehensive functionality when you get there. Also extended > capability with lots of plugins. Good choice. Can't go wrong with learning vi and vim. -- Chad Walstrom <[EMAIL PROTECTED]> http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ pgpGqhPgBqn3K.pgp Description: PGP signature
Re: Debian communication and attitude [was: Re: Example of really nasty DD behavior]
On Sun, Nov 16, 2003 at 12:14:38PM +0100, Martin Pitt wrote: > Why should he? If writing an ITP as the very first action is what you > think best, then do it like this, but that doesn't mean that everybody > must do that. It's simply a matter of timing and fact. The sooner you ITP, the less likely someone else will package the software you're interested in. Simple. Factual. -- Chad Walstrom <[EMAIL PROTECTED]> http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ pgpfHGaZjHJ0k.pgp Description: PGP signature
Re: Example of really nasty DD behavior
Please don't misinterpret my terse replies for annoyance or flaming. This is really a non-issue, and my email reflects that. On Sun, Nov 16, 2003 at 02:14:48PM +0100, Duck wrote: > As Martin Pitt said, I think it's wise contacting related persons, > look at the program, and then, when you relly want to package it, > write an ITP. Wise to contact upstream, sure. Necessary, no. Wise and necessary to look at the package before sending an ITP. Yes. Obviously the other developer looked at the software and found it valuable. He simply didn't ITP it. Perhaps it didn't take him that long to make the package. Who cares. Non-issue. > I was just complaining about his behavior, i don't mind having this > package or not. But he did NOTHING WRONG. He did what developers do, they package software. You lost your opportunity to "own" the package because of timing, not becase of someone's supposed bad behavior. Let me reitterate, "The early bird gets the worm." Let's put the stigma of "my package" and "her package" aside, as well as the idea of loosing "effort" for one reason or another. Let's concentrate on improving Debian. -- Chad Walstrom <[EMAIL PROTECTED]> http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ pgpneHIKmpKKu.pgp Description: PGP signature
Re: Example of really nasty DD behavior
On Sat, Nov 15, 2003 at 11:55:46PM +0100, Duck wrote: > I was writing an ITP when you posted that and suddendly, saw all my > work preparation turned into ashes. Duck, perhaps you should have written the ITP earlier. Instead of complaining, why don't you thank your fellow developer and offer to co-maintain the package. Perhaps the package could benefit from your combined efforts. -- Chad Walstrom <[EMAIL PROTECTED]> http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ pgpacm25aDgft.pgp Description: PGP signature
Re: Bug#220401: ITP: linux-experimental -- Linux 2.4 kernel [EXPERIMENTAL PACKAGE]
On Wed, Nov 12, 2003 at 11:26:26AM -0600, Marcelo E. Magallon wrote: > > * Package name: linux-experimental > > I really don't care either way, but would you consider using > kernel-linux-whatever instead? Just for consistency's sake. As > someone else said, eventually there will be a kernel-freebsd or > kernel-netbsd, and having an uniform scheme to call these things would > be nice. Seconded. -- Chad Walstrom <[EMAIL PROTECTED]> http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ pgpjaebHxN0C9.pgp Description: PGP signature
Re: Bug#218832: ITP: libnettle -- a low-level cryptographic library
On Thu, Nov 06, 2003 at 11:53:38AM -0500, John Belmonte wrote: > Marek Habersack wrote: > >* License : GPL, LGPL, Public Domain > > What does this mean exactly? > > My guess is that it means some parts of the library are under GPL, some > under LGPL, and some in the public domain. If that's the case, the > library as a whole must be considered to be under the GPL, correct? Not necessarily. If work is done on the Public Domain portion of code, and the author wants to continue releasing changes to that portion under the same license, he or she may do so without "poisoning" it with GPL. The same is true for the LGPL portions of the library. GPL doesn't conflict with LGPL or Public Domain in any way. -- Chad Walstrom <[EMAIL PROTECTED]> http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ pgphun8oYkF6q.pgp Description: PGP signature
Re: Advices on choosing a documentation license for an upstream project
On Tue, Nov 04, 2003 at 07:49:38PM +0100, Arnaud Quette wrote: > Knowing that: > - NUT is a pure GPL project, thus we need a _free_ > documentation licence, > > So, what are your advices about choosing a _free_ > documentation licence for NUT? Why not use the GPL to cover the documentation as well? If you tarball the documents with the software, it would be considered a single work, covered by the same license. -- Chad Walstrom <[EMAIL PROTECTED]> http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ pgpIrkyxRIJTY.pgp Description: PGP signature
Re: Debian should not modify the kernels!
On Wed, Sep 24, 2003 at 04:47:13PM -0500, Chad Walstrom wrote: > Doesn't this have to do with the cramfs patch? Man, this is quite the delay. I guess that's what I get for misconfiguring my email server with the wrong origin setting. ;-) -- Chad Walstrom <[EMAIL PROTECTED]> http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ pgpxcqCPKG2aH.pgp Description: PGP signature
Re: Debian should not modify the kernels!
martin f krafft wrote: MFK> make-kpkg and kernel-patches/modules work just fine with vanilla MFK> sources. Matt Zimmerman wrote: MDZ> Except with --initrd. Doesn't this have to do with the cramfs patch? Wasn't this patch rejected by Linus for some reason? IIRC, the cramfs patch is something very specific to Debian kernels and is a workaround for a cramfs bug. I did a google search on this because I wasn't familiar w/the current/past discussion on the topic. It looks like our reference documentation actually touches on this topic[1]. In any case, --initrd can be configured to use a different filesystem for the initrd in /etc/mkinitrd/mkinitrd.rc file. Could someone explain why we still use the cramfs route if it's not being adopted by the kernel gods in general? Is there a more "accepted" filesystem that gives us the benefits of cramfs? I saw one person suggest ISO. ext2 works fine. Perhaps cramfs' size profile was the smallest in the kernel, which made it a good solution for Debian? 1. http://www.debian.org/doc/manuals/reference/ch_kernel.en -- Chad Walstrom <[EMAIL PROTECTED]> http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ pgphbDDQrDoKP.pgp Description: PGP signature
Re: Bug#207300: tmda: Challenge-response is fundamentally broken
On Thu, Aug 28, 2003 at 12:35:25PM +0100, Karsten M. Self wrote: > Thanks to all who've commented on this topic. Interesting reading. Likewise, Karsten. That was a very well written rebuttal to a C-R systems. You followed up with suggetions on using C-R only as a last resort in a mail management tool and only after a modest attempt at detecting spoofed headers was made. I think you've hit upon the core of the issue: no one filtering techniqueue is bullet-proof on its own. The author of TMDA acknowledges this on the TMDA website. It really shouldn't be used as a sledgehammer solution. -- Chad Walstrom <[EMAIL PROTECTED]> http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ pgpeSkyhtZvsW.pgp Description: PGP signature
Re: GR: Disambiguation of Section 4.1.5 of the constitution
On Thu, Aug 21, 2003 at 11:24:11PM -0500, Manoj Srivastava wrote: > I am now formally looking for seconds for this proposal. Seconded. -- Chad Walstrom <[EMAIL PROTECTED]> http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ pgpSp5kuhETPm.pgp Description: PGP signature
Magic tab completion in VIM
On Wed, Aug 06, 2003 at 04:28:24PM -0500, Gunnar Wolf wrote:
> ... So vim is just vi becoming Emacs? I know the hard-core vi guys
> just hated Ctrl-combinations.
Straight from the VIM help system, you too can map the key to
useful, magical completion...
" Clever Tab from VIM Help
function! CleverTab()
if strpart(getline("."), 0, col('.')-1) =~ '^\s*$'
return "\"
else
return "\"
endfunction
inoremap =CleverTab()
Very cool stuff.
--
Chad Walstrom <[EMAIL PROTECTED]> http://www.wookimus.net/
assert(expired(knowledge)); /* core dump */
Re: python 2.2 -> python 2.3 transition
On Wed, Aug 06, 2003 at 11:18:53AM +0200, Josip Rodin wrote: > Am I the only one who has a disgusting reminiscence of netscape*.* > packages every time python* is mentioned? :P On Wed, Aug 06, 2003 at 02:59:00PM +0200, Domenico Andreoli wrote: > hmmm.. just curious... why? The short of it: he's joking. Note the smiley. Even though package names that have version numbers tends to bloat the archive, but there really isn't a more graceful way for allowing two versions of the software to exist on a system at the same time. Josip knows this, hence the smiley. -- Chad Walstrom <[EMAIL PROTECTED]> http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ pgpHqipr7YdXq.pgp Description: PGP signature
Re: Bug#203498: ITP: decss -- utility for stripping CSS tags from an HTML page.
On Wed, Jul 30, 2003 at 03:52:51PM +, [EMAIL PROTECTED] wrote: > Package: wnpp > Version: unavailable; reported 2003-07-30 > Severity: wishlist > > * Package name: decss Like that won't be a confusing package name. ;-p -- Chad Walstrom <[EMAIL PROTECTED]> http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */
Re: proposal: per-user temporary directories on by default?
On Wed, Jul 23, 2003 at 12:35:15AM -0600, Joel Baker wrote: > Except for OS types or versions that don't support that, or people who > actually want /tmp when they explicitly request it, even if > TMPDIR=~/tmp is fine most of the time. For example, when your home directory is actually on an NFS mounted volume. Changing your TMPDIR to ~/tmp is pretty much insane in that case, setting yourself up for painfully slow write operations on files that SHOULD be considered "throw-away" anyway. Now, per-user temp directories to some configurable local disk or tmpfs would be ideal. -- Chad Walstrom <[EMAIL PROTECTED]> http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */
Re: Work-needing packages report for Jul 11, 2003
On Fri, Jul 11, 2003 at 08:49:46AM +0200, Marcelo E. Magallon wrote: > >py-xmlrpc (#161224), orphaned 296 days ago > > Description: Implementation of the XML-RPC protocol for Python > > Let me guess... the snake lovers came up with something better? py-xmlrpc is integrated into the Python 2.2 library. http://www.python.org/doc/current/lib/module-xmlrpclib.html. I don't even see the package in woody. -- Chad Walstrom <[EMAIL PROTECTED]> http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ pgp5zokIJiJg9.pgp Description: PGP signature
Re: Please remove RFCs from the documentation in Debian packages
On Fri, Jul 04, 2003 at 01:18:02PM -0500, Steve Langasek wrote: > Which is why no one is doing any such thing. Instead, we are pointing > out that the RFCs do not comply with the DFSG, and thus, under the > Social Contract as written, should not be included in main. Yes, I read more into the thread than was necessary. Its easy to forget the the rule of staying within the boundaries of the subject in question when tangentials are being thrown around freely. -- Chad Walstrom <[EMAIL PROTECTED]> http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ pgpbUqVoV2yLJ.pgp Description: PGP signature
Re: Please remove RFCs from the documentation in Debian packages
On Fri, Jul 04, 2003 at 07:36:13PM +0100, Andrew Suffield wrote: > Bullshit. It is common for RFCs to be revised over time, and > formulated into new documents. This license prohibits agencies other > than the IETF from revising an RFC and publishing the result. Yes, and the new document is given a new reference number. You've said the words yourself, "formulated into new documents." The new document is referenced as RFC (MAX+1). The revision process itself shows that the document is static. Individual documents may prohibit editing, but the process encourages it. I suggest reading RFC 2026 in its entirety. > In addition, this license prohibits taking text from an RFC and using > it in free documentation, or even in the --help output for free > software. Hmmm... In RFC 2026[1], which describes the Notifications to be included in each standards-related documentation, suggestes in section 10.4.(C) that such fair-use is allowed. Interesting that you would interpret it otherwise. > It's non-free whichever way you slice it. I never said it wasn't. You're stating the obvious, because you're being pedantic about the DFSG. Like I said before, and a statement you conveinently overlooked in order to drag this thread out, that's fine. If you don't think it should be in main or even contrib, that's understandable. I stated that it SHOULD be packaged. Whether or not we include it in non-free is up for debate in yet another thread and mailing list, debian-legal. (See: beat dead horse) I apologize for getting into this thread to begin with, because I see we've become terribly off-topic. The original question was, "Should we include RFC documentation in Official Debian packages?" The answer, if we follow pedantic procedure with respect to DFSG and the Social Contract, is "No." End of discussion. > Respect the wishes of the original authors of the software and use it > in the "proper" manner: they way they intended it to be used, > unmodified. ...[snip]... Oh, oops. Exactly. Now you're getting it. Those English and Grammar classes must be paying off. References == 1. http://www.ietf.org/rfc/rfc2026.txt -- Chad Walstrom <[EMAIL PROTECTED]> http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ pgpmiIEiOlIES.pgp Description: PGP signature
Re: Please remove RFCs from the documentation in Debian packages
On Thu, Jul 03, 2003 at 10:43:10PM +0100, Andrew Suffield wrote: > You have some free software, and it comes with a manual. Your counter example does not apply to IETF Standards documentation. It is not software. In a more general reaction to posts on the list, to say an RFC is an editable document is downright silly. It is a literary work that is intended to be a static document, a reference for protocol implementation. An RFC goes through very little editorial changes once it's been published. The very process used by the IETF perserves previous versions of the documentation, this is why you find "This document superceeds: ..." Their copyright reflects this process. To require or demand that the IETF changes their copyright policy or their publishing practices to cater to someone else's idea of what the document should be used for is plain arogance. Respect the wishes of the original authors and the established, reliable publishing policy of the IETF, and use the document in the proper manner: reference it in your own supplemental documentation. If you really feel you must implement your software in a manner that doesn't comply with an existing RFC's, which is certainly acceptable, place that in your README or appropriate text. I really don't see what's wrong with the RFC copyright. It is freely distributable reference documentation. It is not software. Perhaps it shouldn't be distributed in Debian "main" because of a pedantic interpretation of the DFSG, (there's that software reference again) and Social Contract. Fine, but it should still be packaged. It is a valuable reference, and having the convenience of package installation improves it's distribution amongst developers. -- Chad Walstrom <[EMAIL PROTECTED]> http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ pgp4SsLR4JOmT.pgp Description: PGP signature
[Bug#193320] RFA: gtimer - GTK-based X11 task timer
Package: wnpp Version: N/A; reported 2003-05-14 Severity: normal Due to lack of interest in the gtimer package, I am requesting an adopter. The application is fairly useful, but could use some improvements, the biggest one being a preference dialog box to set up a preferred HTML browser instead of netscape or mozilla. I don't forsee this enhancement being on the top of my list of things to do. The upstream author has expressed that he intends to update the software periodically from code contributions via patches. I've forwarded most of our patches, as hackish or ugly as they might be, and most of the problem reports to him. He has largely ignored these patches in the past and has not given me much feedback until recently. He may have decided to give more attention to the project, so give him the benefit of the doubt. A new version was released in March that fixed a few things. I've used the opportunity to rewrite the package using the DBS and separated out the individual patches. This software is pretty much in a maintenance mode. I don't expect to see many upstream changes, but you may be surprised. So, if you use this package or are interested in improving it, go ahead and adopt. If not, I'm satisfied with maintaining it for the time being. Who knows. Maybe I'll get an itch to improve this thing one day in the distant future. The package description is: Program to track how your time is spent. This useful piece of software allows multiple clocks to run simultaneously, allows for text annotations, and provides useful and portable reports (HTML and TXT formats.) -- System Information Debian Release: 3.0 Architecture: i386 Kernel: Linux skuld 2.4.20-k7 #1 Sun Mar 30 23:08:26 CST 2003 i686 Locale: LANG=C, LC_CTYPE=C -- Chad Walstrom <[EMAIL PROTECTED]> http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ pgplhkfzhnjk2.pgp Description: PGP signature
Re: Returning from "vacation". (MIA?)
On Wed, May 14, 2003 at 12:10:08PM -0500, Clay Crouch wrote: > I truly didn't expect to be attacked on my first post. I also truly > didn't expect to be further lambasted from all quarters for responding > to them. IIRC, the debian-devel mailing list has always been a no-nonsense forum. Honestly, the anti-spam technique you employ is very simple, but also very draconic, in-flexible, and rude. It is far better to set up some sort of cookie handshake autoresponder than to /dev/null everything. There are procmail recipies for this, and if you're slightly resourceful with google, I'm sure you'll find them. If you want a polished system, use TMDA. > I know now that I have no place in your current culture. Debian has > moved on, and so have I. The old saw about never being able to go > "back" has just been reinforced in my mind. I would urge you to seriously reconsider the scope of the "problem" here. It's not simply an incompatibility amongst the Debian developer crowd, but an incompatibility amongst most of the Internet population in general. Reconsider your anti-spam policies. > Please consider me permanently retired, and configure my LDAP entry > accordingly. It is a shame that such a simple scuffle on-list has sent you packing. > I wish you all the best of luck. Keep up the excellent work. -- Chad Walstrom <[EMAIL PROTECTED]> http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ pgpoDxxSU72sg.pgp Description: PGP signature
Re: Common Policy Proposal
"Wafula Okumu" <[EMAIL PROTECTED]> wrote: > Dear Debian and Chad: > > Is it possible for you to assist me by sharing with me a framework for > a comm on defence and security policy proposal. HUH? OK. Let's give this a try. I'm thinking that a couple Patriot Missle batteries would be essential in any common defense and security policy proposal. I mean, if you're really going to deter your foes, why not do it the right way. They're a rightous weapon, and they attract the babes like a basket full of Cadbury Chocolate Easter Eggs. Now, you're going to have to hire at least enough mercenaries for a 5:1 ratio of your upper division staff, the people you most want to protect. You could drop down to 1:20 for the rest of your company staff, maybe even 1:50. If you're trying to protect a country, well, I can't give you exact numbers, but you're going to want tens of thousands of troops. That might be a bit expensive to pay mercenaries, so try instilling a draft. In any case, make sure you keep them busy on the off time by helping hide those Easter Eggs in the mine-field. It's a diversion tactic. Your foes won't be able to resist the temptation of a good egg hunt. Before you ask, chemical weapons are right out. It's just too messy and way to problematic. You'll likely kill half of your own troops trying to pull off any sort of attack. Train them in how to defend against such warfare, but don't give them the means to participate in any other way. You do want some sort of credibility, don't you? If you really must, send your foes truckloads of "Peeps", you know, the marshmello sugar bombs. If that doesn't devestate your foe completely, they'll at least be busy shoveling out the latrine for weeks. Weapons of mass distruction? Again out. Don't even bother. Just be smart on how you deploy your forces and you'll do fine. If you can, however, try to get your hands on a "Holy Hand Grenade of Antioch". They're quite effective, especially against vorpal bunnies, but rare indeed. I suggest that you train your special forces in using this awesome weapon by screening Monty Python's, "The Search for the Holy Grail." It is the defacto standard training material for Holy weaponry. Remember, you must pull the pin and toss the Grenade on "three". > I would be most grateful if you can share with me this information at > your ea rliest possible convenience. My pleasure. I hope my information has helped you out... OK, not really. -- Chad Walstrom <[EMAIL PROTECTED]> http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */
Observation on syslinux/lilo/grub w/rsp to old Toshiba Laptops
(Removed cross-post to debian-boot, since I'm not on that list). On Fri, Apr 12, 2002 at 12:42:10PM -0500, Branden Robinson wrote: > Also, PGI currently uses syslinux and will continue to do past its 1.0 > release. PGI works on i386, of course, and may be a good candidate > for legacy hardware support when the official Debian installer can't > bend over backwards that far anymore. (PGI does not, however, support > floppy-disk-based installs.) I would agree. We can't "Be everything to everyone". I've just recently acquired a laptop (my first!). It's a Toshiba T3400CT, an old 486/sx with a whopping 6.5" /color/ LCD! ;-) I've been able to boot it with tomsrtbt, but the debian rescue discs, even the lowmem ones from slink, do not work. DOS boots fine and the NetBSD discs boot as well (but I don't fancy a floppy installation). At 4 MB of ram and a picky BIOS, my best bet for getting this thing installed w/a base Woody installation is to create a custom boot disc that mounts an NFS root. To do so, it has to run pcmcia for the new Linksys NIC I purchased for it. But like Brandon said, this is a great example of a legacy hardware setup that we can simply not support as default. Also considering that this particular laptop may not work with anything but a zImage kernel (if it has the same problems as the Tecra series), it really wouldn't fall into the "default" category. BTW, I'll let you know how it goes. ;-) If anyone has suggestions or ideas that might help me get this little sucker fired up, I'm all ears. -- Chad Walstrom <[EMAIL PROTECTED]> | a.k.a. ^chewie http://www.wookimus.net/| s.k.a. gunnarr pgpUPOlaPhCrQ.pgp Description: PGP signature
