Re: getting kernel 2.2 into slink
On Thu, Jan 21, 1999 at 10:01:17PM -0500, Brian White wrote: Would anyone object if kernel 2.2 were packaged up at least as a kernel-source package for slink? 2.0.3x would remain slink's default kernel Not that it matters, really. My only worry is that if somebody compiles the kernel, they will expect it to work. I think it's best to leave 2.2 completely in unstable. It's still available there and will have better support. What about saving some ppl some money? I take there are going to be 4 CD's for slink and I guess there are at least 40 MB free on one of them. Could we include 2.2 as a bonus there? Not visible from dselect, just a few more files on one of the CD's... -source packages maybe, so it's easy for ppl to install and deinstall them... Marcelo
Re: getting kernel 2.2 into slink
Including the source package I could be convinced of. At least then people have to think about what they're doing before causing potential problems. This think about what they are doing thing is precisely one of the reasons the extra priority does exist. According to this it should be fine to include it as an extra package. Perhaps that is a reason for extra, but it's really pointless. If it can be installed, people will install it regardless of its priority. I'd bet most people don't even think about a package's priority, largely because many don't know what the priorities mean. In such case (even if the user install everything, including extra packages) I think there should be no problem if the package is a package containing just the kernel source (because source code, as such, is always harmless). Yup. I don't have any worries about that. My small concern is people expecting it to be supported because it came with the distribution. As I've said, I don't have very strong convictions about a source package. Brian ( [EMAIL PROTECTED] ) --- If you love something, set it free. If it comes back, it was, and always will be yours. If it never returns, it was never yours to begin with.
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: getting kernel 2.2 into slink
Disclamers are of marginal use. It will appear as installable and tell people to install me just as an elevator buttun tells people push me. Installing a kernel 2.2 source package just dumps a tar file in /usr/src. I don't see how this could break a system. Actually building and installing that source package is more difficult than pushing an elevator button (even with kernel-package ;-) [...] But keep in mind we're also talking about a _source_package_. Actually, when I wrote that message we were talking about an image package. Brian ( [EMAIL PROTECTED] ) --- Premature optimization is the root of all evil. -- Donald Knuth
Re: getting kernel 2.2 into slink
Brian White wrote: Actually, when I wrote that message we were talking about an image package. Aha! Well I agree with it WRT images. -- see shy jo
Update was Re: Unsatisfied depends in slink main
First I want to thank everyone for their replies. Second I want to appologize for my incorrect phrasing of the subject line. Several people have pointed out that there are very nice packages that deal with dependencies, while others pointed out that the other ored elements satisfied the dependency needs. I should have made it clear that my intent was to find any and all references, that could not be satisfied in the supplied set of packages. As the Packages file is the weak link in the distribution method, I decided to interrogate the actual packages in the given archive and parse their control files. As it turns out, the issue with ppp stems from the fact that, although I started out with a hamm archive as the seed for my slink mirror, satisfying the symlinks, when the package in hamm changed, and the older version was no longer correct, mirror removed it and then failed to make the link to a non-existant hamm directory on my site. I'll be able to recover any other missing files by looking at the changelog, but this brings up another issue. I had understood that, as packages were changed that these symlinks would go away, so all changed packages in hamm should have also updated in slink, disolving the link? In any case, as we are in a freeze, shouldn't these links be replaced with the actual files? I mean, if slink is in freeze, and hamm is still being upgraded... Thanks, Dwarf -- _-_-_-_-_- Author of The Debian Linux User's Guide _-_-_-_-_-_- aka Dale Scheetz Phone: 1 (850) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_-
Re: Update was Re: Unsatisfied depends in slink main
On Fri, 22 Jan 1999, Dale Scheetz wrote: I should have made it clear that my intent was to find any and all references, that could not be satisfied in the supplied set of packages. As the Packages file is the weak link in the distribution method, I decided to interrogate the actual packages in the given archive and parse their control files. Of course this is not at all true, the package files are generated directly from the .deb files daily they are never wrong, if they were then our tools would stop working! Jason
JFunge
Hey all. I'm kind of new around here (in the devel list), but I have been using Debian for a while, and I want to contribute. I'm not much of a C coder or anything, but I can whack Perl with the rest of them. Anyway, getting to the point, I took a little and coded a Funge interpreter in Perl. This is not useful at all, and is more of a novelty. A funge (to the uninitiated) is a genre of programming language. It has the following `features': - Stack Based Language - N Dimensional Programming - Character based directives more information at: http://www.cats-eye.com/funge/ This language is not useful _at all_, but it *is* a lot of fun to code in. Here's an example: :*.52*,@ That will prompt for a number, and then print the square and a newline. As you can see, it has quite limited use. I wrote this interpreter mainly out of boredom, and because none of the other interpreters are under GPL. I was just wondering if there was any interest for another goofy language (we have intercal for Debian already I beleive) and if anyone would be interested in this. I am planning on extending the Funge specification and making `enhancements' to this language, which I feel is a very novel language indeed. If anyone is interested in the source please contact me, but I am warning you, my code is not the nicest or the fastest, but I am glad to take suggestions/patches. Thanks you guys, for making such a great system for me to use, and I anxiously await any input anyone has in this matter. Thanks, Josh
crypt [Re: off-topic! Anonymous CVS access?]
Hi
Ship's Log, Lt. Tom Lees, Stardate 210199.2014:
The password is anonymous. Generate it like this:-
echo 'main(){printf(%s\n,crypt(password,tL));}'t.c; \
gcc -o t t.c -lcrypt; ./t; rm t t.c
I'd say perl -e 'print crypt(passwd,tL).\n' is much shorter :)
Greetings
--
Alexander N. Benner; [EMAIL PROTECTED]; [EMAIL PROTECTED] (#Hosanna #IXThYS)
PROVERBS 30:4
Who hath ascended up into heaven, or descended?
Who hath gathered the wind in His fists? Who hath bound the waters in a garment?
Who hath established all the ends of the earth?
What is His name, and what is His son's name, if thou canst tell ?
Re: Where does 'www-data' come from?
In article [EMAIL PROTECTED] you write: --6c2NcOVqGQ03X4Wi Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable On Fri, Jan 22, 1999 at 09:39:18AM +1100, Brian May wrote: =20 The only thing my proposal changed was the UID and the GID of the web server, so that the web server doesn't have write access to the web files. It most cases, it is not required that the web server have write access to its files, and in those cases where it is required (eg if CGI scripts need to be able to modify HTML files), then you can change the UID and/or GID of those individual files. But shouldn't it be www:www-data? Or at least put www into group www-data by default if you want to change it. Then you can just chmod g+w if you want write access to some HTML-Files/directories. And the httpd server should be able to read his HTML-files if you ask me :-) even if they are not world-readable. I think you want something that I didn't cater for - non-world readable HTML files. I think that there are numerous conflicting demands, and if you want everything, then it is impossible with the simple UID/GID permissions of Unix: 1) I think you are saying you don't want the Web files world readable - this isn't an issue for me, but might be an issue if data is password protected, etc. This means that the files can only be modified by the UID and/or GID. Valid usable permissons would be rw-rw or rw-r. 2) If you prevent write access by the GID but allow read access (ie rw-r), then the web process can read it using the same GID but can't modify it. However, only the UID can modify the files, and this is not good enough for many situations. 3) If you allow write access by the GID (ie rw-rw), then everyone in the group can modify it. However, if the webserver also shares this GID, then it can modify them to, making any change completely pointless. So in order for this to work, the UID:GID of the server would have to be different, making the permissions rw-rw-r--, and ignoring 1). 4) Ideally, there should be a way to associate to GID for each web file (one ServerGID which has no write permission and one DataGID which was write permissions), however, this is currently not a valid option. I believe ACL (access control lists) will by able to do this though... My personal opinion is that 3) is more important then 1), and I would make the UID:GID different. Any data that I publish on the WWW, IMHO, is public, but others will disagree.
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: getting kernel 2.2 into slink
Allan M. Wind [EMAIL PROTECTED] wrote: There should be _no_ (known) problems when shipped in stable (IMHO). Your favorite newbie has problems enough configurating ppp... dealing with ppp problems on top of that is not going to be well perceived. Er.. wrong. We're not waiting for all bugs to get fixed before releasing slink, just the important ones. That said, I really wish that slink had been released some time ago, and that this discussion was about including 2.2 in the soon-to-be-released potato. [I think dpkg and X have been the two biggest problems. X seems to be under control, but we seem to still be fighting some brittleness in dpkg. [brittleness is a term I use for software which has been modified too much, so that further changes are difficult.]] -- Raul
boot disk question/suggestion
Hi, I am having some real problems booting the current boot disks for potato on my Dell PowerEdge 6300 server system. The problem appears to occur when the rescue disk kernels probes for hardware. Everytime it begins to probe for SCSI hardware the machine just dies. I lose video signal and I end up having to power cycle the machine. On an identical system one of my colleagues installed RedHat 5.2 without much trouble once we figured out the boot options. Logically, I thought that the same kernel boot options would work for Debian. Unfortunately they did not. The machines both have two Adaptec 7890 and one Adaptec 7860 SCSI chipsets installed. Each machine also has a gigabyte of memory and four Intel Pentium II Xeons installed. In order to get RedHat to work we had to fool the kernel into thinking that it had less than a gig of memory since it can't seem to handle more then about 1020MB (confirmation anyone?) of memory. Second we also had to tell the kernel to prevent the aic7xxx driver from probing since it causes the system to crash if it does probe. Here is the boot line: boot: linux mem=1000M aic7xxx=no_probe The RedHat boot disk does no probing at all since SCSI drivers appear to be loaded during the installation process, not during the boot process. OTOH, Debian's kernel loads several SCSI drivers (right?) which appears to be causing my system to crash. The system crashes right after the IDE detection boot step. Is it possible to shut off all SCSI support at the boot: prompt? If not, can anyone suggest a solution? Since RedHat's boot technique appears to work well in situations like mine (new hardware, probing causes crashes), can we or should we do something similar? Are there any new boot disks available besides the ones that were released last on 12/29? I can't make my own boot disks since I currently don't have access to Debian system and I don't want to use master or va to create boot disk images. Any suggestions or comments? Thanks, -Ossama __ Ossama Othman [EMAIL PROTECTED] 58 60 1A E8 7A 66 F4 44 74 9F 3C D4 EF BF 35 88 1024/8A04D15D 1998/08/26
Debian-sci-fi :- (seriously off topic)
On Sat, Jan 23, 1999 at 12:48:47PM +1100, Craig Sanders wrote:
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 :-)
Yeah.. I really like the stories (although the 'rock falls on planet'
theme seems to show up in an inordinate number of their stories, in
some form or another). I can't really stomach some of Pournelle's
compilation books ('there will be war' or something) because of the
heavy political emphasis (and also that dweeb who rewrites greek myths
in sci-fi terms - I hate that). Anyone want to recommend other good
authors to someone who really likes the Pournelle/Niven stories? I
like some David Drake (even though he is even more gory and political,
in some ways, than Pournelle)... Some of Frederick Pohl's work is ok,
too.
I think the thing I really like is that the stories are a bit more
plausible, if you will, instead of some namby-pamby fate of the
universe/origins of god and everything/touchy-feely woo woo crud;-)
i better stop now before debian-devel detours into an sf crit list
for a while.
Better than, to quote you, the 'legal bullshit' :-
Heh, that was fun...
--
David Welton http://www.efn.org/~davidw
Debian GNU/Linux - www.debian.org
Re: getting kernel 2.2 into slink
Ben Collins [EMAIL PROTECTED] writes: On Thu, Jan 21, 1999 at 10:02:52PM -0500, Brian White wrote: No. We had enough problems upgrading from 2.0.35 to 2.0.36. This would be a major change and have corresponding reprocussions. I'm sure it's very stable, but it will have incompatibilities. I'm using nothing but packages from slink/sparc and I see no incompatibilities. Then again the box isn't running X, any of the other sparc devs out there have any input on which kernel provides the 'safest' X for sparc? I haven't touched 2.0.x kernels for the last year on the Sparc platform. I don't trust them. Additionally, the 2.0.35 Debian kernel wouldn't even boot on my Sparc20 (haven't tried 2.0.36), but I've only been running Debian on that machine for about a month (I installed by hand with the 2.1.x kernel I was using for UltraPenguin). X works fine on my Sparc20 and Ultra5, but I can't speak for other systems. The Ultra 5 has run a variety of CVS kernels from about 2.1.125 to 2.2.0-pre4, and the 20 has run an even wider range of 2.1.x kernels with UP, but mostly 2.1.12x kernels with Debian. Steve [EMAIL PROTECTED]
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: logo in Gnome
-BEGIN PGP SIGNED MESSAGE- Try looking at http://www.debian.org/logo (or logos) On 22-Jan-99 Havoc Pennington wrote: Hi, Gnome ships with icons for different kinds of files, and right now .deb packages have the Debian logo as icon. I've been asked to make sure this is OK from a trademark point of view. I can't find the logo license on the web site (?) - could someone clue me in on the current status, or give special permission to use the icon in Gnome? Alternatively, someone could draw a better icon for .deb packages. ;-) Thanks, Havoc = * http://benham.net/index.html * * * -BEGIN GEEK CODE BLOCK- ---* *Darren Benham * Version: 3.1 * * [EMAIL PROTECTED] * GCS d+(-) s:+ a29 C++$ UL++ P+++$ L++* * KC7YAQ * E? W+++$ N+(-) o? K- w+++$(--) O M-- V- PS-- * * Debian Developer * PE++ Y++ PGP++ t+ 5 X R+ !tv b DI+++ D++ * * [EMAIL PROTECTED] * G++G+++ e h+ r* y+* * * --END GEEK CODE BLOCK-- ---* = -BEGIN PGP SIGNATURE- Version: 2.6.3a Charset: noconv iQCVAwUBNqlMAbbps1lIfUYBAQGC0QP/btBb65v9kTn/N6xM5EoCTNYcpITYsr4c 21aMiLXeU43iNt4DVZYAp1pctmGSnU6q2lPScIlw0iWkojfnh425sOMvNclcy3YU akKFL9/WKfeeVwlbSozF7QoUOSO+IdJ5tX6Ft73GuZJ3yk7uS7ySE/tGD2kHvkbc MFWWye6+xpw= =zF04 -END PGP SIGNATURE-
Re: boot disk question/suggestion
Ossama Othman wrote: The machines both have two Adaptec 7890 and one Adaptec 7860 SCSI chipsets installed. Each machine also has a gigabyte of memory and four Intel Pentium II Xeons installed. In order to get RedHat to work we had to fool the kernel into thinking that it had less than a gig of memory since it can't seem to handle more then about 1020MB (confirmation anyone?) of memory. 2.0.x maxes out at 2^30-2^26 = 1006632960 bytes, or 960MB, of RAM. Thus, you'll wanna use mem=960M. You can also adjust some headers (I forget which) to expand the kernel memory / virtual memory split (it is adjustable, and it defaults to 1GB/3GB). Second we also had to tell the kernel to prevent the aic7xxx driver from probing since it causes the system to crash if it does probe. Here is the boot line: boot: linux mem=1000M aic7xxx=no_probe The RedHat boot disk does no probing at all since SCSI drivers appear to be loaded during the installation process, not during the boot process. OTOH, Debian's kernel loads several SCSI drivers (right?) which appears to be causing my system to crash. The system crashes right after the IDE detection boot step. Is it possible to shut off all SCSI support at the boot: prompt? If not, can anyone suggest a solution? Since RedHat's boot technique appears to work well in situations like mine (new hardware, probing causes crashes), can we or should we do something similar? Are there any new boot disks available besides the ones that were released last on 12/29? I can't make my own boot disks since I currently don't have access to Debian system and I don't want to use master or va to create boot disk images. You can switch out the kernel on the rescue disk on any linux system fairly easily: # dd if=resc1440.bin of=/dev/fd0 # mount -t msdos /dev/fd0 /mnt # cd /mnt # rm linux # cp /place/i/have/my/working/kernel linux # ./rdev.sh # cd / # umount /mnt Yes, the rdev.sh script does require that you mount the disk on /mnt. Make sure your rescue disk contains ext2, msdos, ramdisk, initrd, and ELF support. Happy booting. -- Robert Woodcock - [EMAIL PROTECTED] It's like a love-hate relationship, but without the love. -- jwz, on linux
Re: boot disk question/suggestion
Hi Robert, # dd if=resc1440.bin of=/dev/fd0 # mount -t msdos /dev/fd0 /mnt # cd /mnt # rm linux # cp /place/i/have/my/working/kernel linux # ./rdev.sh # cd / # umount /mnt Yes, the rdev.sh script does require that you mount the disk on /mnt. Make sure your rescue disk contains ext2, msdos, ramdisk, initrd, and ELF support. Happy booting. Much obliged!!! I'll give it a whirl once I am done trying out the 2.1.5 boot disks I got off of master. :) Thanks again, -Ossama __ Ossama Othman [EMAIL PROTECTED] 58 60 1A E8 7A 66 F4 44 74 9F 3C D4 EF BF 35 88 1024/8A04D15D 1998/08/26
Re: getting kernel 2.2 into slink
On Fri, Jan 22, 1999 at 03:29:00PM +0100, Marco d'Itri wrote: Kernels are big. Even if you don't pay for download time, many people do. ---end quoted text--- That's what dselect is for...you only download that which you are going to install. By adding the 2.2.0 kernel and or source as an extra package(s), you don't HAVE to download it. It would be there as an additional package that one could download if one chose to. Ivan -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Ivan E. Moore II Rev. Krusty http://www.tdyc.com [EMAIL PROTECTED] -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Imagination is more important than knowledge - Albert Einstien -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- GPG KeyID=0E1A75E3 GPG Fingerprint=3291 F65F 01C9 A4EC DD46 C6AB FBBC D7FF 0E1A 75E3 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Re: boot disk question/suggestion
Hi again, 2.0.x maxes out at 2^30-2^26 = 1006632960 bytes, or 960MB, of RAM. Thus, you'll wanna use mem=960M. You can also adjust some headers (I forget which) to expand the kernel memory / virtual memory split (it is adjustable, and it defaults to 1GB/3GB). Can the 2.1/2.2 kernels handle a gigabyte of memory? Also, I remember reading somewhere that the 2.1/2.2 kernels can handle swap partitions greater than 128MB. Is this also true? Sorry guys, I guess I should be asking this on debian-user. -Ossama
RE: logo in Gnome
On Fri, 22 Jan 1999, Darren Benham wrote: Try looking at http://www.debian.org/logo (or logos) Thanks! It looks like a) the license is expired and b) it doesn't apply to Gnome anyway because Gnome is not clearly half Debian related. Though arguably we're talking about .deb packages rather than all of Gnome, so that's 100% Debian related. Anyway, obviously it's OK for Gnome to use it, but we should have an actual email from someone with the appropriate authority, saying that a license is granted for this purpose. Can whoever would make this decision please just send me a short note? Thanks, Havoc
Re: Debian goes big business?
On Sat, Jan 23, 1999 at 12:48:47PM +1100, Craig Sanders wrote: (BTW: TANSTAAFL was Larry Niven, not Heinlein IIRC) Heinlein, The Moon is a Harsh Mistress, I thought. Actually I never read it but it was a favourite of some people in the local FidoNet region a few years back (as Craig might remember?) Hamish -- Hamish Moffatt VK3TYD [EMAIL PROTECTED], [EMAIL PROTECTED] Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5 CCs of replies from mailing lists are welcome. http://hamish.home.ml.org
Re: Intent to package rolldice, blackjack
On Fri, Jan 22, 1999 at 03:22:58PM +, M.C. Vernon wrote: As well, my roommate and I were going to also make a character sheet program (hence the reason for making the rolldice stuff a library), so we could just enter the data, and either save it to a file or go ahead and print it out... my roommate has been working on GTK+ for the occasion g Why do I get the idea I should bring up once again my hope to gather a sizable group of people to build a game system which is released under free license and available to anyone with a web browser and the like? = IMHO a RMSS character auto-gen would be a Good Thing(TM). It's a pain in the to do by hand (usually with lots of math errors), and there are plenty of 'doze things around. I'll do the maths if someone will do the UI (and docs :) ) You want a system that takes for-freakin'-ever to roll a character, try Champions. 3 hours or so just to have the char dies in 15 minutes! Oh the pain. = The goal of this system was to define the characters generic enough that you could reasonably build a campaign in any setting really, but not take forever to roll up by hand. I've got some ideas for that, but they're best described in terms of other games really. The big problem with the traditional DD/ADD attributes is that while they account well for basic agility needed in traditional middle ages hack and slash combat, they don't even consider more advanced forms of combat. Even arrow combat in ADD seems to have been an afterthought. I have ideas to deal with that problem, but only ideas so far. Of course the real issue is getting the system different enough from other systems that nobody sues us for it. = TSR would have and I bet WotC would too. These companies are in it for the money, they don't care about the gamers. If they cared about the gamers they would start selling their books wirebound (a common request) because wirebound books last longer under gaming use... -- I'm working in the dark here. Yeah well rumor has it you do your best work in the dark. -- Earth: Final Conflict
Re: Intent to package rolldice, blackjack
On Fri, Jan 22, 1999 at 04:30:45PM +0100, Federico Di Gregorio wrote: As well, my roommate and I were going to also make a character sheet program (hence the reason for making the rolldice stuff a library), so we could just enter the data, and either save it to a file or go ahead and print it out... my roommate has been working on GTK+ for the occasion g Why do I get the idea I should bring up once again my hope to gather a sizable group of people to build a game system which is released under free license and available to anyone with a web browser and the like? = I am working at that. But I am writing it in italian... too bad my english is very distant from perfection! Will be released under something similar to Artistic. BTW the name is Aedon, and is a generic set'o'rules. When we play (it's about 3 years we use it) we call it Ab Infinito and is a mix between H.P.Lovcraft and the Rork comics by Andreas. I was actually going to something like GPL or LGPL it. I wanted people to be able to make commercial additions to the system as well as free additions, translations, and to be allowed to publish the core system and mods we make freely.. But like the GPL, I don't want them to be able to stop us from making the same stuff available freely. Slightly off topic this one!!! Depends, I was planning on packaging the system's core files and other things for Debian... = -- I'm working in the dark here. Yeah well rumor has it you do your best work in the dark. -- Earth: Final Conflict
Re: Intent to package rolldice, blackjack
On Fri, Jan 22, 1999 at 03:24:28PM +, M.C. Vernon wrote: Why do I get the idea I should bring up once again my hope to gather a sizable group of people to build a game system which is released under free license and available to anyone with a web browser and the like? = I'm all for it! How about it, anyone else interested? :) aolMe too/aol We could call it gnuice :-) I would have to bop you then... = But it would be under a free software type license, probably GPL or LGPL rewritten so they actually seem to apply to what is essentially going to be documentation and images and the like as opposed to source code to an executable. -- I'm working in the dark here. Yeah well rumor has it you do your best work in the dark. -- Earth: Final Conflict
Re: Intent to package rolldice, blackjack
On Fri, 22 Jan 1999, Joseph Carter wrote: On Fri, Jan 22, 1999 at 03:24:28PM +, M.C. Vernon wrote: Why do I get the idea I should bring up once again my hope to gather a sizable group of people to build a game system which is released under free license and available to anyone with a web browser and the like? = I'm all for it! How about it, anyone else interested? :) aolMe too/aol We could call it gnuice :-) I would have to bop you then... = But it would be under a free software type license, probably GPL or LGPL rewritten so they actually seem to apply to what is essentially going to be documentation and images and the like as opposed to source code to an executable. I guess source code in this context is the \latex source for the rulebook? Matthew -- Elen sila lumenn' omentielvo Steward of the Cambridge Tolkien Society Selwyn College Computer Support http://www.geocities.com/Area51/Chamber/8841/ http://www.cam.ac.uk/CambUniv/Societies/tolkien/ http://pick.sel.cam.ac.uk/
Re: Intent to package rolldice, blackjack
On Sat, Jan 23, 1999 at 10:23:51AM +, M.C. Vernon wrote: I'm all for it! How about it, anyone else interested? :) aolMe too/aol We could call it gnuice :-) I would have to bop you then... = But it would be under a free software type license, probably GPL or LGPL rewritten so they actually seem to apply to what is essentially going to be documentation and images and the like as opposed to source code to an executable. I guess source code in this context is the \latex source for the rulebook? It would be if I were writing latex.. = I'm not, though. I may use debiandoc maybe, but most likely I'm going to use plain HTML. -- I'm working in the dark here. Yeah well rumor has it you do your best work in the dark. -- Earth: Final Conflict
Re: Intent to package rolldice, blackjack
On Sat, 23 Jan 1999, Joseph Carter wrote: On Sat, Jan 23, 1999 at 10:23:51AM +, M.C. Vernon wrote: I'm all for it! How about it, anyone else interested? :) aolMe too/aol We could call it gnuice :-) I would have to bop you then... = But it would be under a free software type license, probably GPL or LGPL rewritten so they actually seem to apply to what is essentially going to be documentation and images and the like as opposed to source code to an executable. I guess source code in this context is the \latex source for the rulebook? It would be if I were writing latex.. = I'm not, though. I may use debiandoc maybe, but most likely I'm going to use plain HTML. I guess HTML makes sense really. I've never tried debiandoc though Matthew -- Elen sila lumenn' omentielvo Steward of the Cambridge Tolkien Society Selwyn College Computer Support http://www.geocities.com/Area51/Chamber/8841/ http://www.cam.ac.uk/CambUniv/Societies/tolkien/ http://pick.sel.cam.ac.uk/
Crypto software that *is* exportable from the USA
Hi there, I am trying to draw attention to what I think is an important piece of software - Mirrordir. It supports strong encryption but is exportable from the US because it does not have encryption compiled in by default. Instead it downloads the scripts it needs from South Africa when it runs for the first time. South Africa has no export restrictions on cryptography. It supports file transfer and secure logins shells. I remember someone was maintaining the debian release of this software (although then, it did not support encryption). Please get the latest version from: ftp://lava.obsidian.co.za/pub/mirrordir/US/ (Note: for the Debian distribution you must download from the `US' tree, and not the `International' tree.) Thanks -paul Obsidian Systems . . . . Linux installations, support, networking [EMAIL PROTECTED] . . . . . . . . . . . . Tel (+27 11) 792 6500 http://www.obsidian.co.za . . . . . . . . Fax (+27 11) 792 6522 __ __ __ __ __ __ __ __ / / / // |/ // / / / \ \/ / / /_ / // /| // /_/ / \ / /___//_//_/ |_/ \// \ /_/\_\
Intent to package bsmtpd
BSMTP mailer for Sendmail completely written in C This package supplies a new mailer to sendmail, which allows to use batched SMTP a protocol. BSMTP is used in UUCP environments and allows to transport many mails as a (compressed) batch instead of transporting every single mail. So bsmtp is an alternative to rmail. Special features of this sendmail bsmtp version: - Completely written in C. - Configurable batch size (automatically sends batch to uux when a defined size is reached). - Creates backups of all outgoing batches (and removes them regularly) The author told me, that the program stands under the GPL. Ciao Roland -- * [EMAIL PROTECTED] * http://www.rhein.de/~roland/ * PGP: 1024/DD08DD6D 2D E7 CC DE D5 8D 78 BE 3C A0 A4 F1 4B 09 CE AF
Re: what needs to be policy?
[I've looked over the other messages in this thread, but this looks like the best message for me to respond to.] Joey Hess [EMAIL PROTECTED] wrote: The question is: What needs to be policy? Specifically, Manoj's point of view seems to be that as we develop programs that tie the system together and are used in many packages (examples are the menu system, update-alternatives, dpkg, etc), the interfaces these programs present eventually assume the weight of policy, and that those interfaces should be codified and included in the policy document. On the other hand, I think that these interfaces need not appear in policy. What I'm seeing is that we're overloading policy with other [rather important] functions, such as standards and even, to some degree, interface definitions. Policy should be rather broad in scope and concise in expression. -- Raul
Re: the Great X Reorganization, package splits, and renaming
On Fri, Jan 22, 1999 at 03:18:51PM +0100, Santiago Vila wrote: Still, it is advisable to install the renamed versions of these packages as soon as is convenient, in the event that their contents do change in the future. This would just postpone the problem until there is a real difference between the old packages and the new ones, but would not make the problem to disappear. It would be just a clock bomb. Imagine the following scenario: --Oh, I upgraded from Debian 2.1 to Debian 2.2 and now my font packages do not work. --Did you read the release notes for the X packages in Debian 2.1. Because it's such a widespread problem, we can assume that Debian 2.2's version of APT will support package renaming in some way. That means we can actually put off solving this problem until Debian 2.2, and even longer if the X fonts don't change. To put it another way: - Upgrading from old-Debian to 2.1 doesn't replace the font packages, but that doesn't cause an immediate problem; - If Debian 2.2 doesn't have new or rearranged fonts, there is still no problem; - If Debian 2.2 _does_ rearrange the font packages, it should implement some package renaming scheme at _that_ time, assuming APT or dselect has been improved with a nice renaming scheme. Why make things ugly before there's an actual reason to do so? Have fun, Avery
Re: the Great X Reorganization, package splits, and renaming
Avery Pennarun [EMAIL PROTECTED] wrote: Because it's such a widespread problem, we can assume that Debian 2.2's version of APT will support package renaming in some way. That means we can actually put off solving this problem until Debian 2.2, and even longer if the X fonts don't change. This means that we're willing to hold off on upgrades to all font packages until the relevant apt support for package renaming is ready. I just hope the rest of the world agrees that this is wise. [What's wrong with using the empty package mechanism, and waiting for apt to give us a way of making defunct empty packages delete themselves?] -- Raul
Re: the Great X Reorganization, package splits, and renaming
On Sat, Jan 23, 1999 at 12:03:55PM -0500, Raul Miller wrote: Avery Pennarun [EMAIL PROTECTED] wrote: Because it's such a widespread problem, we can assume that Debian 2.2's version of APT will support package renaming in some way. That means we can actually put off solving this problem until Debian 2.2, and even longer if the X fonts don't change. This means that we're willing to hold off on upgrades to all font packages until the relevant apt support for package renaming is ready. Sure, why not? Nothing in them has changed. I just hope the rest of the world agrees that this is wise. Uh... yeah, me too. [What's wrong with using the empty package mechanism, and waiting for apt to give us a way of making defunct empty packages delete themselves?] I didn't think there was any plan to add auto-delete defunct empty package support to APT; on the other hand, I've seen lots of package renaming proposals. Besides, if the empty packages are unnecessary, why should we have them crowding things? Have fun, Avery
Re: Crypto software that *is* exportable from the USA
It supports strong encryption but is exportable from the US because it does not have encryption compiled in by default. Instead it downloads the scripts it needs from South Africa when it runs for the first time. This is *extremely* risky behavior. FTP and HTTP sites *are* compromised. Software packages *are* compromised. Look no further than TCP Wrappers... A major part of the security process is having a human involved who knows what software was downloaded. A human may later see a pertinent news report and act on it; scripts will not. A *mandatory* part of a site's security process is having a human who has the final authority to approve the use of a package. A human who can be held accountable, and thus is motivated to pay attention to what's going on. A script blows off this part of the process. South Africa has no export restrictions on cryptography. It supports file transfer and secure logins shells. It can offer secure file transfers and multiple cryptographic checksums, and the end result is just as unacceptable. *We must start with the assumption that the server might be compromised.* If the server is compromised, secure login shells and FTP won't help. If the server is compromised, checksums (even MD5 checksums) won't help. The only thing resilient to compromised servers are cryptographically signed cryptographic checksums. Which requires PGP. Which is not exportable. And which requires a chain of trust to evaluate whether to trust the key used to sign the checksum. What's the answer? Download *PGP* to verify the checksums on that PGP file,... ? As an aside, why would a mirror program even want strong encryption? Encryption != authentication, although the implementatons have significant overlap. Bear Giles [EMAIL PROTECTED]
Re: Crypto software that *is* exportable from the USA
Bear Giles [EMAIL PROTECTED] wrote: The only thing resilient to compromised servers are cryptographically signed cryptographic checksums. Which requires PGP. Which is not exportable. And which requires a chain of trust to evaluate whether to trust the key used to sign the checksum. Actually... for the case of a pre-planned upgrade, a simple md5sum check -- that the downloaded file has a md5sum which matches an archive which has already been examined and seems clean -- would be sufficient (at least in terms of mechanical integrity). -- Raul
Re: Reality check! [was: Re: Debian goes big business?]
On Sat, Jan 23, 1999 at 04:10:52PM +0100, Paul Seelig wrote: The first thing a future Debian entrepreneur interested in financial success would have to address would be to fix all those things which we Debian propeller heads have preferred to mostly neglect up until now: ease of install and ease of useability for both sysadmins and users. These things have to become *at least* as dead easy as it *already is* with SuSE. It would be a very healthy experience for everybody to go out once in a while and purchase a SuSE copy and do a fresh install with it. Some would be astonished and some might even be frightened to see what Debian definitely lacks. These are some excellent points, and I hope people read this and think about it. When you are getting money for something, you have a responsiblity to someone else, usually your company, but also, in the larger picture, whoever ends up paying for what you do. While there are some drawbacks, there are also many positive aspects to this - it forces you, for better or worse, to work with some kind of schedule, and towards some specific goals, instead of just it works for me. Debian right now has all its it works for me ducks in a row - it is great and wonderful for those of us who can appreciate it, but, without some people really working to make it easier (and having the financial backing to maybe do it full time), it probably isn't going to have broad appeal real soon. Once again, to most of us, this is probably not a grave problem - Debian won't have trouble continuing in its present form, it's not like we'll go away because of lack of funds, but, on the other hand, we will continue to occupy an increasingly smaller portion of the market. Maybe now would be a good time to create a debian-business? I'm not sure -consultants is really broad enough. This is something I'm quite interested in. I firmly believe in the ideals of free software, and, infact, like free software so much that I'd like to spend all day working on it/for it. However, I'm not sure that that aspect of things has been sorted out yet... it should be an interesting couple of years:- Ciao, -- David Welton http://www.efn.org/~davidw Debian GNU/Linux - www.debian.org
Re: Reality check! [was: Re: Debian goes big business?]
On 23 Jan 1999, Paul Seelig wrote: and annoyances they'd have with Debian. They won't care about Debian's rather unaccessable technical superiority if the installation hinders them from getting the beast at least easily up and running and will recommend SuSE to the rest of the world. That's how SuSE became the biggest player on the Linux market in Germany. And because SuSE Since when has the purpose of debian been to appease the interests of the mass of unskilled consumers? There are lots of dists that are trying to do that. I'm sure they will do a good job of introducing newbies to Linux. But I never thought that was the purpose of Debian. is even easier to install and maintain than Redhat it will eventually become a major player in the US as well. Debian in comparison is still a far cry from what it's really all about becoming popular for the world. Debian IMHO should be aimed toward the skilled technical user and those who are already Linux skilled. There is no other dist that is trying to fill this role. And it is not possible to please the mass market of unskilled consumers and the skilled technical person at the same time. Their requirments are quite different. I wouldn't recommend Debian to my non Linux savy friends either because i want them to *like* Linux and currently it is really hard for a newbie to find something likeable about Debian. I myself like I started with Slackware. That is the dist that I recommend and install for newbies. The reason I use debian now is because of its technical excellence and such a distribution saves me the time of having to put together my own distribution. If it wasn't for debian I would have to spend a lot of time compiling and editing source to get a technically competent system that gives me the freedom that I require. The first thing a future Debian entrepreneur interested in financial success would have to address would be to fix all those things which we Debian propeller heads have preferred to mostly neglect up until now: ease of install and ease of useability for both sysadmins and users. These things have to become *at least* as dead easy as it *already is* with SuSE. The key to debians future is not market sales of its dist. Debian like UNIX will succeed because it is possible to learn how everything works, and it is designed to accomplish a technical not a commercial goal. It is an excellent example of the fusion of pedagogy and production, of fashion and function. The future lies not in selling to a mass market of unskilled consumers but rather in the technical training and recruitment of a cadre of technical leaders and knowledgable advocates. To be sure, there is much work to be done in the area of technical training. Already there are discissions starting around Linux certification. But this effort may not lead to a program to develop technical competence. In fact it may lead completely away from it. The training/user/developer/distribution/Internet_service collage posses some fascinating possibilites. How debian or its progeny figure in that future will be quite interesting. -steve
Re: the Great X Reorganization, package splits, and renaming
This means that we're willing to hold off on upgrades to all font packages until the relevant apt support for package renaming is ready. I just hope the rest of the world agrees that this is wise. it's not. i'm new here, so i'm not sure if this is an old topoic or not, but debian distributions can get really out of date as it is. xfree86 3.3.3 has been out since november... it's not on slink, and it had some *major* advantages (my display card, for instance) while remaining to my knowledge completely backwards compatible with 3.3.2. if an elegant solution to the problem is impossible, and for the immedieate future it is, better have an ugly hack that will work until we fix the problem *without* depending on software not changing or an earthquake wiping out all debian systems causing them to need to start from scratch anyway or any equally unlikely assumption. in short: ass-ugly is better than either broken or uselessly out of date. [What's wrong with using the empty package mechanism, and waiting for apt to give us a way of making defunct empty packages delete themselves?] why not just have dummy packages delete themselves in postinst, if we're going to use them? the real solution of course is to add a Replaces: or some such to dpkg, because it really does happen that things change names as they evolve. --phouchg, [EMAIL PROTECTED] The reader this signature encounters not failing to understand is cursed.
Re: Reality check! [was: Re: Debian goes big business?]
On Sat, 23 Jan 1999, Steve Shorter wrote: Since when has the purpose of debian been to appease the interests of the mass of unskilled consumers? There are lots of dists that are trying to do that. I'm sure they will do a good job of introducing newbies to Linux. But I never thought that was the purpose of Debian. Please don't let's start *this* kind of discussion yet again. It's *not* about appeasing to the masses of unskilled consumers. It's about increasing ease of installation, use and maintenance. Skilled people definitely benefit from such time saving aspects in their daily jobs. Even professionals don't want to always have to deal with things which explicitly require a professional. Excellence in design doesn't necessarily have to result in awkwardness. The fact that even the mass of unskilled consumers benefit from this is a completely different issue. The point is that what's good for unskilled people can be equally good for skilled people who no by themselves how to provoke trouble if they really want it. ;-) Debian IMHO should be aimed toward the skilled technical user and those who are already Linux skilled. There is no other dist that is trying to fill this role. [ ... ] Where's the problem (other than that *you* don't care) to make Debian comfortable even for the skilled technical user? Hey, i'm skilled enough to handle all this stuff but it would be *really* nice if i wouldn't need to have to be skilled to be able to to certain standard tasks which should rather be automated. That's what computers are good for and i love to sppend my time with other things than being forced to make my hands dirty even if things could be solutioned once and for all for me and everybody else (newbies included). Does it have to be hard to be superior? The key to debians future is not market sales of its dist. Debian like UNIX will succeed because it is possible to learn how everything works, and it is designed to accomplish a technical not a commercial goal. It is an excellent example of the fusion of pedagogy and production, of fashion and function. I don't want to argue about Debian's future nor do i want to redefine any goals of the project. But you shouldn't either BTW. Yes, i've learned my share and now what? Do i still have to use a system which lets me explicitly feel that i *had* to learn my share to take 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. Hey, installations are terribly bothersome processes and Debian's installation is the most cumbersome and lengthy of them all. 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? Please let's clearly differentiate: What Debian is about is a matter of Debian developers. But what an entrepreneur's work based on the Debian distribution is about is a whole different thing. If you don't care about this perspective than just don't bother about it. This is a matter of getting Debian out into the market and making it *really* attractive not only for hackers. I for one would rather base my work on an enhanced and made easy Debian product sold for 59,95 US$ saving me all the need to apply my own expertise than to have to rely on a vanilla Debian from the net requiring that i deal with it the hard way. The latter is a fine product for hackerish people like you. But not everybody wants to be a hacker or devoted sysadmin with any other interests. 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. Thank you, P. *8^) PS: To all: Please *never* CC me. Thanks! -- - Paul Seelig [EMAIL PROTECTED] --- African Music Archive - Institute for Ethnology and Africa Studies Johannes Gutenberg-University - Forum 6 - 55099 Mainz/Germany --- http://www.uni-mainz.de/~pseelig -
Re: Reality check! [was: Re: Debian goes big business?]
On Sat, 23 Jan 1999, Paul Seelig wrote: Please don't let's start *this* kind of discussion yet again. It's *not* about appeasing to the masses of unskilled consumers. It's about increasing ease of installation, use and maintenance. Skilled people definitely benefit from such time saving aspects in their daily jobs. Even professionals don't want to always have to deal with things which explicitly require a professional. Excellence in design doesn't necessarily have to result in awkwardness. The fact that even the mass of unskilled consumers benefit from this is a completely different issue. The point is that what's good for unskilled people can be equally good for skilled people who no by themselves how to provoke trouble if they really want it. ;-) 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. 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? Making things easier does not necessitate dumbing-down things for more competent users. Once up and running, a Debian system is far more maintainable than the alternatives -- a great factor in on-going ease of use. 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. -tl .. please forgive my abrupt ending hre - but my conection is xtrememleyyhiclmelyey BAD hiccuppy etc must sign off - EF D8 33 68 B3 E3 E9 D2 C1 3E 51 22 8A AA 7B 98
Re: Reality check! [was: Re: Debian goes big business?]
On Sat, Jan 23, 1999 at 07:14:35PM +, thomas lakofski wrote: On Sat, 23 Jan 1999, Paul Seelig wrote: 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. My original point was that this is probably not the sort of thing that 'just happens' - it is much more likely to happen in a commercial environment, where it is important, not just an idea of something that might be nice. Being volunteers, we can't just go around saying it should be this way, someone else do it - it just doesn't work like that. If you really want something, start working on it... Obviously, given the lack of an easy install, this hasn't been something anyone has 'really wanted' (heh, and why would we - all of us have already managed to figure out the install..:-) My thought is that this is an area where some free software companies could be useful... spending their time making an easy install. However, I'm not sure how this might work financially, and have it still be Free (which is one of the things it might be interesting to talk about on a debian-business list). -- David Welton http://www.efn.org/~davidw Debian GNU/Linux - www.debian.org
Re: the Great X Reorganization, package splits, and renaming
Jonathan P Tomer [EMAIL PROTECTED] wrote: why not just have dummy packages delete themselves in postinst, if we're going to use them? That can be done.. but it's not quite so simple (dpkg isn't re-entrant unless the nested invocations are read-only). I suppose the trivial implementation would be (in postinst) ( until dpkg --remove xfntwhatever; do sleep 120 done /var/tmp/removexfntwhatever.log 21 ) [The parenthesis mean that the until loop has init as parent, rather than dpkg, and unless the system is rebooted the package will eventually get removed. Perhaps --purge should be used instead of --remove. Perhaps 120 should be replaced with $(perl -le 'srand; print int 600*rand'). Etc.] the real solution of course is to add a Replaces: or some such to dpkg, because it really does happen that things change names as they evolve. And, currently, dpkg is brittle (the implementation has several conflicting designs), which is why we're still talking about slink and aren't freezing potato. Until dpkg is fixed we have to live with its warts. -- Raul
Re: Reality check! [was: Re: Debian goes big business?]
thomas lakofski [EMAIL PROTECTED] wrote: 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? In the context of initial installation, I think it's laziness -- a refusal to examine problems. That said, the boot-floppies people seem to be making progress (perhaps not as fast as everyone would like, but better than what lots of other people have been doing). -- Raul
Re: Article: IBM wants to clean up the license of Linux
On Sat, Jan 02, 1999 at 06:34:27PM -0500, Brandon S. Allbery KF8NH wrote:
(config.guess rant: *why* the exact processor ID? About half of configure
scripts fall over in ECE Linux builds because they don't expect i686.
This should be x86. And if it has to be exact, where are AMD and Cyrix?)
If you configure it for i686-unknown-linux-gnu, then the default compiler will
compile code that is tuned for an i686 (ie, Pentium-Pro, Pentium-II), but still
only use instructions common to all members of the x86 family. Similarly if
you configure it for i386-... it will default to compiling code for a 386
target. I do wish RedHat, S.U.S.E, et al would deliver compilers configured
for a 686 (that being the common computer sold now adays -- also there in the
argument you want the default to be schedule for the high end computers since
those are the users paying the most for performance). Of course it would be
nice if anybody who packages the compiler puts in links to the assembler,
linker, etc. in the install directory so that cross compilers are easy to
make).
Since the GNU model of the world is more towards everybody downloading the
compiler and building it for his/her own machine, this is a reasonable default.
I believe its been in place for some time (I seem to recall it in the 2.6 era,
when I breifly was the x86 coordinator, and you only had two choices 386 or
486).
IOW the correct config.guess triple *should* be x86-pc-linux. Or
x86-gnu-linux; an accurate statement, since the userspace code is
something like 85% FSF code (and this nicely ends the current argument).
i?86-pc-linux-gnu is silly, and i?86-{redhat,suse,...}-linux{,-gnu} is
sillier.
It is a can of worms to open this debate again. Yes, you have valid points,
but I suspect the political (between egcs, FSF, linux, etc.) aarguments will
dward the technical ones.
--
Michael Meissner, Cygnus Solutions (Massachusetts office)
4th floor, 955 Massachusetts Avenue, Cambridge, MA 02139, USA
[EMAIL PROTECTED], 617-354-5416 (office), 617-354-7161 (fax)
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: the Great X Reorganization, package splits, and renaming
On Sat, 23 Jan 1999, Raul Miller wrote: ( until dpkg --remove xfntwhatever; do sleep 120 done /var/tmp/removexfntwhatever.log 21 ) OK. We have three solutions suggested now: a) dummy packages (and live with them) b) dummy packages, which self-remove c) packages with the old names, which tinker with dpkg/dselect's databases so it looks like the new packages are installed instead (which is true, since they have the same contents). I suggest the X maintainer choose one. Jules /+---+-\ | Jelibean aka | [EMAIL PROTECTED] | 6 Evelyn Rd| | Jules aka | [EMAIL PROTECTED] | Richmond, Surrey | | Julian Bean | [EMAIL PROTECTED]| TW9 2TF *UK* | ++---+-+ | War doesn't demonstrate who's right... just who's left. | | When privacy is outlawed... only the outlaws have privacy. | \--/
Re: Reality check! [was: Re: Debian goes big business?]
On Sat, 23 Jan 1999, Raul Miller wrote: thomas lakofski [EMAIL PROTECTED] wrote: 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? In the context of initial installation, I think it's laziness -- a refusal to examine problems. That said, the boot-floppies people seem to be making progress (perhaps not as fast as everyone would like, but better than what lots of other people have been doing). OK, since it seems that this kind of thing will probably only happen in a commercial context, maybe it would make sense to arrange commercial sponsorship of Debian in a bigger way. Debian seems to have many attributes which would make it more suitable for large corporate environments than other dists -- it's possible that if this could be pointed out to the right potential installation sites development funding would be forthcoming -- and with that, the means to pay developers to do stuff that they might not be motivated to do out of the goodness of their hearts. (I guess compare with Red Hat - Intel/Netscape/VCs) I guess I'll ask at my current place of work -- big swiss bank where they use Solaris exclusively and have expressed interest in Linux because of the benefit it would have for the bottom line. -tl .. please forgive my abrupt ending hre - but my conection is xtrememleyyhiclmelyey BAD hiccuppy etc must sign off - EF D8 33 68 B3 E3 E9 D2 C1 3E 51 22 8A AA 7B 98
Re: Crypto software that *is* exportable from the USA
Bear Giles [EMAIL PROTECTED] wrote: The only thing resilient to compromised servers are cryptographically signed cryptographic checksums. Which requires PGP. Which is not exportable. And which requires a chain of trust to evaluate whether to trust the key used to sign the checksum. Actually... for the case of a pre-planned upgrade, a simple md5sum check -- that the downloaded file has a md5sum which matches an archive which has already been examined and seems clean -- would be sufficient (at least in terms of mechanical integrity). But you're biting your own tail here. Where do you get that good checksum? You can't get it from the archive site, since a compromised archive implies that the local MD5 checksum may also be compromised. If the attacker doesn't replace the checksums, great. If he does If you distribute it as part of your package, you can't load newer packages... which makes the entire exercise academic. If you distribute it from a trusted site, then compromising *that* site results in the same problem. Even if you try to bootstrap the system, how do I know that the package I get was the one you wrote? How do I know that the TLD tables haven't been corrupted, or a DNS entry hijacked, or And again, what is the problem you're trying to solve that requires strong encryption in the mirroring software? AFAIK, MD5 checksums are *not* export restricted. Bear Giles [EMAIL PROTECTED]
Re: Crypto software that *is* exportable from the USA
Bear Giles [EMAIL PROTECTED] wrote: But you're biting your own tail here. Where do you get that good checksum? Any place which is acceptable to the package maintainer -- perhaps out of a pgp signed archive. If the package maintainer can't produce a trustable package, it doesn't matter how fancy you get. Bootstrapping is hard -- best you can do for the general case is compare notes after you've gotten a secure system up. The one thing you have going for you is that corrupted packages have to be visible, to someone, or they're no danger. -- Raul
Re: Update was Re: Unsatisfied depends in slink main
On Fri, 22 Jan 1999, Jason Gunthorpe wrote: On Fri, 22 Jan 1999, Dale Scheetz wrote: I should have made it clear that my intent was to find any and all references, that could not be satisfied in the supplied set of packages. As the Packages file is the weak link in the distribution method, I decided to interrogate the actual packages in the given archive and parse their control files. Of course this is not at all true, the package files are generated directly from the .deb files daily they are never wrong, if they were then our tools would stop working! While what you say is in principle true, in practice it doesn't always work out that way. My experience has been that many problems experienced by our users, and much of the fault on broken CDs have been the result of out-of-sync Packages files. In my most recent personal case, that broken sync was caused by a broken mirror configuration WRT symlinks. The result was a package in the Packages file but not in the archives. This can happen through a chain of mirrors in several ways. (Yes, I know that there are safeguards to help, but they are not always used) For myself, I draw through such a narrow straw that it may take days to complete a pass. I know, under these circumstances that I must repeat the mirror until a pass can occure in shorter timeframes. I also know that there are ways to unsync if you have a bigger straw. It's only a matter of timing. Several of the CDs that have been produced by vendors with unspectacular results have been partialy the result of broken Packages files. I have always considered this to be a weak link in the installation process. I know that when I build Packages files using dpkg-scanpackages, that it can take a long time, and that such reconstruction within and FTP install/upgrade is difficult without retrieving the archive, but when the package installation tools can't recover the Packages file, a broken CD is unrecoverable trash. Being able to run against an arbitrary archive is going to become more and more necessary as the distribution becomes larger. Thanks, Dwarf -- _-_-_-_-_- Author of The Debian Linux User's Guide _-_-_-_-_-_- aka Dale Scheetz Phone: 1 (850) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_-
Re: Bug#27050 (fdutils): A cause for security concern?
Previously Anthony Fok wrote: Unfortunately, the suggestion chown root.floppy and chmod [12]754 won't work either because fdmount.c has this check in it: if (geteuid()!=0) die(Must run with EUID=root); You wouldn't believe how many programs have a check like this and still work perfectly when they are not root.. Wichert. -- == This combination of bytes forms a message written to you by Wichert Akkerman. E-Mail: [EMAIL PROTECTED] WWW: http://www.wi.leidenuniv.nl/~wichert/ pgpr5jlgIGX25.pgp Description: PGP signature
Re: the Great X Reorganization, package splits, and renaming
On 23-Jan-99, 14:11 (CST), Raul Miller [EMAIL PROTECTED] wrote: Jonathan P Tomer [EMAIL PROTECTED] wrote: why not just have dummy packages delete themselves in postinst, if we're going to use them? That can be done.. but it's not quite so simple (dpkg isn't re-entrant unless the nested invocations are read-only). Why are we going to this trouble? If you want to rename package a1 to a2, simply make a2 conflict and replace a1 -- dselect or dpkg will do the rest. If you want to make 'upgrade' automatic, then you'll also need to upload a new version of the a1 package (empty would seem to be feasible) that depends upon a2. And yes, I just tried this. It works, using dselect with the apt method anyway. I installed a version of a1 that did not require a2, and then created a new version of a1 that did, and then add a local archive that had both the new version of a1 and a2 in it to my apt sources.list file. Dselect-update,select,install worked just fine. Also went back to the original a1, and ran dpkg --install a1.deb a2.deb. That also worked. There's no need to make the dummy packages do anything. In particular, the xfonts-* packages already have the necessary replaces/conflicts. The only thing necessary is to upload new xfnt-* packages with the necessary depends. Branden has indicated that he's not interested in doing that. Steve
Re: what needs to be policy?
Raul Miller wrote: Policy should be rather broad in scope and concise in expression. Amen. -- see shy jo
Re: the Great X Reorganization, package splits, and renaming
On Sat, 23 Jan 1999, Steve Greenland wrote: Why are we going to this trouble? If you want to rename package a1 to a2, simply make a2 conflict and replace a1 -- dselect or dpkg will do the rest. If you want to make 'upgrade' automatic, then you'll also need to upload a new version of the a1 package (empty would seem to be feasible) that depends upon a2. And yes, I just tried this. It works, using dselect with the apt method anyway. I installed a version of a1 that did not require a2, and then created a new version of a1 that did, and then add a local archive that had both the new version of a1 and a2 in it to my apt sources.list file. Dselect-update,select,install worked just fine. Also went back to the original a1, and ran dpkg --install a1.deb a2.deb. That also worked. There's no need to make the dummy packages do anything. In particular, the xfonts-* packages already have the necessary replaces/conflicts. The only thing necessary is to upload new xfnt-* packages with the necessary depends. Branden has indicated that he's not interested in doing that. I don't think Branden realised that the conf/repl/prov trick will automatically deinstall the xfnt packages. My understanding of his objection was the ugliness of having them hang around. I have Cc:ed [EMAIL PROTECTED] into this email. Jules /+---+-\ | Jelibean aka | [EMAIL PROTECTED] | 6 Evelyn Rd| | Jules aka | [EMAIL PROTECTED] | Richmond, Surrey | | Julian Bean | [EMAIL PROTECTED]| TW9 2TF *UK* | ++---+-+ | War doesn't demonstrate who's right... just who's left. | | When privacy is outlawed... only the outlaws have privacy. | \--/
special boot disk
Hi, About a month ago a developer posted that he had a special boot disk image in his debian.org home directory to alleviate a hang at install time, but I can't locate the post now. Does anyone know the URL? -- David
the .app extension on (some) wmaker apps
I'm trying to package wmsysmon.app -- but I'm not sure about the .app that *some* wmaker apps get -- I'm not sure if I should have the package as wmsysmon.app or just wmsysmon. The tarball is wmsysmon.app, but the binary that gets built is wmsysmon. I built an (undocumented) manpage for wmsysmon.app -- but lintian gives me a binary with no manpage since the binary doesn't have the .app -- hr Should I leave the package as .app, but have the binary/manpage as-is (wmsysmon)? -- always thought the binary/manpages should match the package-name is all.
Upgrading Debian
On Tue, Jan 19, 1999 at 03:25:17PM -0600, Adam Heath wrote: These 'pkgs' will have to remain in the system forever. If someone skips slink, and goes to potato when that is released, the same problem will occur. We have to get rid of old practices at some point. We do not need to make the same error M$ made. Of course there must be a possibility to upgrade. cu Torsten pgpItapHAusRq.pgp Description: PGP signature
Re: Reality check! [was: Re: Debian goes big business?]
On Sat, 23 Jan 1999, thomas lakofski wrote: 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? There is nothing wrong with making things easier. Simplicity is an important technical value. But there is a huge difference between a simple setup/system and automating an install to appease the needs of someone who is about to go through the process without knowledge about what is happening. Is it not better to educate this person a little first? There is nothing snobbish about teaching what you know and insisting that users be interested enough to learn something about the system that they are going to use. The real techno-snobs will teach nothing and insist on installing a system in which control of the system is impossible for the user. Not because [s]he is incapable of assimilating the skills, but simply because the politics of the situation will not allow for training and the transfer of knowledge. Making things easier does not necessitate dumbing-down things for more competent users. Once up and running, a Debian system is far more Perhaps not. But perhaps you should ask yourself the question- Why is debian like it is today and not like something else? The answer is deeply rooted in the role the developers have played in its production AND the role debian has played in the technical lives of the developers. Production for use is a two way street, and it is short and narrow. Nothing prevents what you and some others advocate from happening, except perhaps your own will and ability to facillitate it. But to insist that the creators of a system change it when they are satisfied with it is to fundamentally misunderstand what is happening here and why debian is different than a commercial dist and even why Linux is different than a commercial OS. The requirments of a commercial market driven distribution or OS is not the same as the technical system that debian is evolving into. There is no reason why debian could not be the basis of the system that you want. The freedom to take it and go in that direction is there. But you must stop insisting that others do it for you. The developers have done well and it is BECAUSE they have satisfied their personal requirments (self-interest), understood co-operation and the enlightened self interest that is the origin of the Linux community. Perhaps the answer for what you are seeking is simple. Find others who want the dist to look like you do and organize to create somthing a little different. Debian as the product of wage labour and consumer driven markets would simply not be as good for me or the developers. Is that not the very lesson of Linux/GNU itself? -steve
Re: Reality check! [was: Re: Debian goes big business?]
On Sat, Jan 23, 1999 at 08:51:25PM +, thomas lakofski wrote: On Sat, 23 Jan 1999, Raul Miller wrote: thomas lakofski [EMAIL PROTECTED] wrote: 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? In the context of initial installation, I think it's laziness -- a refusal to examine problems. That said, the boot-floppies people seem to be making progress (perhaps not as fast as everyone would like, but better than what lots of other people have been doing). OK, since it seems that this kind of thing will probably only happen in a commercial context, maybe it would make sense to arrange commercial sponsorship of Debian in a bigger way. I think the first part of your sentence is a bit unfair. To make installation easier requires hard work. If it would be easy, it would have been long done. The trick is to keep flexibility (and don't tell me SuSE is flexibel). Doing it easy for the newbie and configurable for the experienced user requires a well though out configuration and administration system. At least for multi-installation this is currently developed on the debian-admintool list. Hardware autodetection would be another good thing, but only if implemented well and reliable. This does only work with open hardware specifications. It's not the lack of interest, but the lack of real, skilled contributions in this area, which addresses all concerns. Needless to say that any contribution is welcome, be it from volunteers or commercial organizations. But let's not drag Debian too deep into agreements with commercial contributors. If you can convince a company to write a good installation procedure, I am sure nobody will neglect it, provided it is technically convincing. Debian does make decisions on technical grounds, and I would not like to see this changed. Thanks, Marcus -- Rhubarb is no Egyptian god.Debian GNU/Linuxfinger brinkmd@ Marcus Brinkmann http://www.debian.orgmaster.debian.org [EMAIL PROTECTED]for public PGP Key http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09
