antisocial X11 apps: xtet42, chimera
I'm not sure that this behavior is buggy, so I'm not casting this as a bug report. I previously reported as a bug that xtet42 hung my system. That was dismissed as a probable problem with my system. I've characterised this a bit more, and thought I'd report the additional info. When either xtet42 or chimera are started up on my 486-40 system, the system appears to hang while these apps are initializing. During this period, mouse movement is unrecognized, ctl-alt-F1 and friends don't work, ctl-alt-backspace doesn't work, and ctl-alt-del doesn't work. This condition persists for: xtet42: 4 () minutes Chimera: eleven (!!!) minutes After this longish time with an apparently hung system, the apps come up and appear to work normally (though xtet42 is veeery slooow). It's easy to misread this as a hung system and hit the reset switch while these apps are starting up. This only affects X11. A quick ctl-alt-F1 before the app starts intializing gets a linux vc which operates normally. Running top(1) on the vc, I see X11 taking lots of CPU. I presume that non-X users would be undisturbed by this. I'm wondering if this is (1) normal? (2) antisocial apps needing upstream attention? (3) something else? I note that other X11 apps which take a long time to start up don't appear to hang the system during startup. Mirrormagic, for example, takes over a minute to start up, but other X11 operations are able to continue normally and the ctrl-alt-* commands work OK during its startup. [EMAIL PROTECTED] (Bill Mitchell)
Re: antisocial X11 apps: xtet42, chimera
Bill Mitchell writes: I'm not sure that this behavior is buggy, so I'm not casting this as a bug report. I previously reported as a bug that xtet42 hung my system. That was dismissed as a probable problem with my system. I've characterised this a bit more, and thought I'd report the additional info. When either xtet42 or chimera are started up on my 486-40 system, the system appears to hang while these apps are initializing. During this period, mouse movement is unrecognized, ctl-alt-F1 and friends don't work, ctl-alt-backspace doesn't work, and ctl-alt-del doesn't work. This condition persists for: xtet42: 4 () minutes Chimera: eleven (!!!) minutes After this longish time with an apparently hung system, the apps come up and appear to work normally (though xtet42 is veeery slooow). It's easy to misread this as a hung system and hit the reset switch while these apps are starting up. This only affects X11. A quick ctl-alt-F1 before the app starts intializing gets a linux vc which operates normally. Running top(1) on the vc, I see X11 taking lots of CPU. I presume that non-X users would be undisturbed by this. I'm wondering if this is (1) normal? (2) antisocial apps needing upstream attention? (3) something else? I note that other X11 apps which take a long time to start up don't appear to hang the system during startup. Mirrormagic, for example, takes over a minute to start up, but other X11 operations are able to continue normally and the ctrl-alt-* commands work OK during its startup. How does something like netscape run on your machine? I don't see why xtet would cause this, it's not like it needs to load fonts or use hellish amounts of ram. It works perfectly on my machine. 486dx2-80 with 16 meg of RAM and I'm in 10 meg of swap with several rxvt's running, inn, netscape and quite a few other things and it took about 3 seconds to pop up. Is your 486 a dx? Do you have any video memory left over for a font cache? How much RAM do you have? What kind of video card? Andrew -- Dehydration - 34%, Recollection of previous evening - 2%, embarrassment factor - 91%. Advise repair schedule:- off line for 36 hours, re-boot startup disk, and replace head - wow, what a night! -- Kryten in Red Dwarf `The Last Day' Andrew Howell [EMAIL PROTECTED] Perth, Western Australia [EMAIL PROTECTED]
Re: md5sum passwords
Karl Ferguson writes (Re: md5sum passwords): I know what you're all saying, but I'd definately like the MD5 in place as an optional extra. Isn't that possible? The extra security as an Internet Provider is a much needed asset... As I wrote earlier, MD5 used in this way is not significantly more secure than traditional crypt. The problem with Unix passwords isn't the length limit, it's the poor diversity and the ease with which an attacker can test a guess. The poor diversity can be protected by making guessing harder; that's what my proposal is intended to do. I dread to think what the consequences will be if we try to go through all of our programs making sure that they cope with longer passwords and longer encrypted passwords, and in any case there would be little point since it doesn't solve either of the problems. I disagree. Setting a minimum length of 10 characters is pretty effective. With pretty much unrestricted password length, people can use a fairly easy to remember sentence, including punctuation, as a password which would be almost impossible to guess and completely infeasible to crack in the way programs like Crack try to work. People trying to break in aren't on the whole dumb enough to sit there trying to guess passwords. While password measures like this are just part of a well implemented secure environment, they're a useful part. Of course the best solution would be to go all the way to a trusted computing base security environment like in DEC's OSF/1. ... Stephen
Re: antisocial X11 apps: xtet42, chimera
On Wed, 22 Nov 1995, Bill Mitchell wrote: I'm wondering if this is (1) normal? (2) antisocial apps needing upstream attention? (3) something else? I just installed xtet42 on my system and is runs fine. I didn't notice any delay in starting (up and playing in less than 20 seconds). The only problem I noticed is at installation time xtet42 depends on X11R6 and I don't run an X server on my Debian machine. My X server is on my Win 95 machine. So to get xtet42 to install I needed to add the --force-depends to the dpkg command line. --- Kenny Wickstrom | gnu - a new generation in s/w devel/support [EMAIL PROTECTED] | Linux - a much improved Un*x clone (708)740-4008 | Debian - a Linux distribution setting the #include std-disclaimer |standard for future distributions
Re: antisocial X11 apps: xtet42, chimera
Kenny Wickstrom writes: The only problem I noticed is at installation time xtet42 depends on X11R6 and I don't run an X server on my Debian machine. My X server is on my Win 95 machine. So to get xtet42 to install I needed to add the --force-depends to the dpkg command line. xtet42 depends on X11R6 and recommends xserver. This is what Ian Murdoch said all X packages should do. Andrew -- Dehydration - 34%, Recollection of previous evening - 2%, embarrassment factor - 91%. Advise repair schedule:- off line for 36 hours, re-boot startup disk, and replace head - wow, what a night! -- Kryten in Red Dwarf `The Last Day' Andrew Howell [EMAIL PROTECTED] Perth, Western Australia [EMAIL PROTECTED]
patch for dipconfig ...
If you have problems with dipconfig please apply the following patch: --- dipconfig.0 Thu Nov 23 09:48:51 1995 +++ dipconfig Thu Nov 23 09:48:44 1995 @@ -5,7 +5,8 @@ $dialog = dialog --backtitle 'Debian GNU/Linux DIP setup'; # redirect STDERR and STDOUT -$rd = 21 /dev/tty; +$tty = `tty`; +$rd = 21 $tty; restart: Thanks, Peter -- Peter TobiasEMail: Fachhochschule Ostfriesland [EMAIL PROTECTED] Fachbereich Elektrotechnik und Informatik [EMAIL PROTECTED] Constantiaplatz 4, 26723 Emden, Germany
Bug#1877: at/batch do not mail output with sendmail installed
On Wed, 22 Nov 1995, Ian Jackson wrote: Are you sure this is true in at 2.9a-1 ? My source tree seems to suggest that they use `mail'. I should probably add a dependency. Yes, I'm pretty sure (unless there is more than one at-2.9a-1 out there). The following diff works for me: --- debian.subs.distSat Oct 28 17:12:34 1995 +++ debian.subs Thu Nov 23 10:45:16 1995 @@ -11,7 +11,7 @@ s:_DAEMON_UID:1:g s:_DAEMON_GID:1:g -s:_MAIL_CMD:/usr/sbin/rmail:g +s:_MAIL_CMD:/usr/lib/sendmail:g s:_PROC_DIR:/proc:g s:_PERM_PATH:$(IROOT)/etc:g Sendmail should provide /usr/sbin/rmail too - that it doesn't is a bug in the Sendmail package. Sendmail does provide /usr/bin/rmail, but I don't think this is suitable for atrun. I tried it and it doesn't work. I chose /usr/lib/sendmail in the diff above, because this is what cron uses. /usr/bin/mail should work also, I think, but as it calls sendmail to deliver the mail (if I remember correctly) I guess we could just as well use /usr/lib/sendmail (which is provided by both smail and sendmail). Harald Schueler Universitaet EssenTel +49-201-1832456 Fachbereich 7 Fax +49-201-1832120 45117 Essen Email [EMAIL PROTECTED]
Re: antisocial X11 apps: xtet42, chimera
Bill Mitchell wrote: When either xtet42 or chimera are started up on my 486-40 system, the system appears to hang while these apps are initializing. During this period, mouse movement is unrecognized, ctl-alt-F1 and friends don't work, ctl-alt-backspace doesn't work, and ctl-alt-del doesn't work. This condition persists for: xtet42: 4 () minutes Chimera: eleven (!!!) minutes Is it Cyrix 486-40 CPU? I remember seeing some similar reports in a linux newsgroup. Peter -- Peter TobiasEMail: Fachhochschule Ostfriesland [EMAIL PROTECTED] Fachbereich Elektrotechnik und Informatik [EMAIL PROTECTED] Constantiaplatz 4, 26723 Emden, Germany
Returned mail (fwd)
Forwarded message: From [EMAIL PROTECTED] Thu Nov 23 20:18:43 1995 From: Mail Router (smail 2.9 dl,da,fa,tu,po,qf,lo,dbm 03/23/95 43) [EMAIL PROTECTED] Message-Id: [EMAIL PROTECTED] Date: 23 Nov 95 12:18:28 GMT Subject: Returned mail To: [EMAIL PROTECTED] Your mail could not be delivered because of the following reason: - Transcript of session follows - No matching or similar name in the people database for 'jasonbramsden'. - Unsent message follows - [Cut my original debian-changes message] Can someone take this guy off the debian-changes list please? He's not getting the email. Regards, ...Karl -- | PO Box 828 Office: (09)316-3036 Fax: (09)381-3909 |OWER INTERNET SERVICES Canning Bridge After Hours: 015-779-828 WA, 6153 Sales Support: [EMAIL PROTECTED] Internet Service Providers and Networking Solutions
Bug#1887: cfengine 1.2.14-2: documentation errors
Bill Mitchell: In my own packages, I've been trying to provide debianized docs which change references to /usr/local to just plain /usr where it's clear from the context that this would be incorrect on a debian system. I've come to think that even this amount of twiddling the upstream docs may be too much, and debian would be better off to adopt a policy of leaving such references untouched and providing clear info in system docs that such references in debian package docs should be taken as references to files in /usr, and not in /usr/local. Comments? I don't see the point in prohibiting such work. However, it is work to make these kinds of corrections... Ideally, once software is configured to be installed at some destination, the installed form of the documentation should also receive this configuration information [unless location doesn't need to be mentioned at all]. Ideally this should be supported by the software's author. We've got a lot a fairly complex package specification already, let's not complicate it with needless rules. -- Raul
Re: antisocial X11 apps: xtet42, chimera
On Thu, 23 Nov 1995, Andrew Howell wrote: Is your 486 a dx? Do you have any video memory left over for a font cache? How much RAM do you have? What kind of video card? Dx -- dunno. Didn't take note when I had it open. I grepped /var/log/messages for a bogomips figure, but that's apparently no longer part of the startup. As I recall under earlier kernels, it was low -- perhaps 6.something. Better than the 386 I used to run, which was about 4.3. 16 MB RAM -- machine unbusy and not swapping. Cirrus video card with 1Mb on it.
Re: antisocial X11 apps: xtet42, chimera
Andrew Howell writes: Bill Mitchell writes: Dx -- dunno. Didn't take note when I had it open. I grepped /var/log/messages for a bogomips figure, but that's apparently no longer part of the startup. As I recall under earlier kernels, it was low -- perhaps 6.something. Better than the 386 I used to run, which was about 4.3. Hmmm you said it was a 40 MHz machine? but you think you get 6 something bogomips, that sounds strange. My understanding of bogomips for 486s is that it's half the clockspeed. My understanding and experience concur with this. 486DX/40 at home gives c. 20 BogoMips. 486DX2/66 at works claims c. 33 BogoMips. ttfn/rjk
Bug#1895: run-parts does not run scripts without #!/...
Package: miscutils Version: 1.3-5 Run-parts does not run scripts not beginning with #!/... This may not be a bug, but it should be documented. run-parts --test, however, displays _all_ scripts, which is rather confusing, and not a test at all. Harald Schueler Universitaet EssenTel +49-201-1832456 Fachbereich 7 Fax +49-201-1832120 45117 Essen Email [EMAIL PROTECTED]
Re: antisocial X11 apps: xtet42, chimera
Dx -- dunno. Didn't take note when I had it open. I grepped /var/log/messages for a bogomips figure, but that's apparently no longer part of the startup. As I recall under earlier kernels, it was low -- perhaps 6.something. Better than the 386 I used to run, which was about 4.3. 16 MB RAM -- machine unbusy and not swapping. Cirrus video card with 1Mb on it. It might be a video-driver problem. Awhile back when I had my 486 with an ATI 8514/A card, I sent mail to the list saying that Netscape would not work for me after some kernel upgrades, Netscape would freeze the system up. Nobody could duplicate the problem, but when I moved my hard drives over into my new system, everything worked fine. So I would suspect a hardware problem (either physical or software driver). Perhaps you could try borrowing a video card from somebody else and seeing if that changes anything? How well do compiles go, do you notice it being slower then it should? Jim
Re: New package: die
Erick Branderhorst writes (New package: die): Description: die: Kill a job by process name, instead of number. Can I ask a stupid question ? In what way does this program differ from `killall', and wouldn't it be better to integrate this a bit better into killall or miscutils or something ? Having lots of packages is good, but half a dozen (probably often poor) implementations of the same tiny script in half a dozen different packages doesn't seem optimal to me. Ian.
Bug#1888: pari 1.39: a few minor Debian bugs
Chris Fearnley writes (Bug#1888: pari 1.39: a few minor Debian bugs): CFLAGS in src/debian.rules gives the -g flag for debugging (almost certainly not necessary). There's nothing wrong with that, so long as it is linked without -g and with -s. -g shouldn't change the generated code; it's supposed (with GCC) just to include extra debugging symbols in the .o files. Ian.
Re: Bug#1887: cfengine 1.2.14-2: documentation errors
Bill Mitchell writes (Bug#1887: cfengine 1.2.14-2: documentation errors): In my own packages, I've been trying to provide debianized docs which change references to /usr/local to just plain /usr where it's clear from the context that this would be incorrect on a debian system. I've come to think that even this amount of twiddling the upstream docs may be too much, and debian would be better off to adopt a policy of leaving such references untouched and providing clear info in system docs that such references in debian package docs should be taken as references to files in /usr, and not in /usr/local. We should document what we ship as we ship it. Ian.
Re: New package: die
On Thu, 23 Nov 1995, Ian Jackson wrote: [...] I Having lots of packages is good, but half a dozen (probably often poor) implementations of the same tiny script in half a dozen different packages doesn't seem optimal to me. I'd expect a rash of package contributions as hordes of new debian users come online. If it gets out of hand, and it well may, we'll need some sort of traffic-cop mechanism on new packages. That'll probably need one or more volunteers to filter submitted packages and/or some sort of pre-submission consultation mechanism. Whatever the mechanism is, it should have a kind and gentle approach to dealing with prospective package submitters. (I don't consider myself qualified to be part of that mechanism)
Re: Linux init-time errors since elf upgrade
I've been seeing this since I installed the elf upgrade packages. I was hoping that someone with a better handle on it than me would report it, but I've seen no report. I'm not casting this as a bug report since I'm not sure where to attribute it. The error I see accurs during processing of /etc/initd/modules. Between Calculating dependencies ... and done, I see about lines of sh: /bin/nm cannot execute binary file. There's noting in between there except depmod -a. Manually running depmod -a after the system is up does not produce these messages. Are these complaints about libbfd.so.2.5.2l.20 These are due to not having /usr mounted (/usr/lib/libbfd.so.2.5.2l.20) is at the point where depmod is run. I havnt got round to reporting this as abug yet 'coz I dont know what lib bfd does yet. :) alvar -- Alvar Bray Meiko LimitedPhone:+44 1454 616171 650 Aztec West Fax: +44 1454 618188 Bristol BS12 4SD E-Mail: [EMAIL PROTECTED] England WWW: http://www.meiko.com Via: Debian GNU/Linux from home.
Re: Bug#1887: cfengine 1.2.14-2: documentation errors
On Thu, 23 Nov 1995, Ian Jackson wrote: We should document what we ship as we ship it. No argument, but that implies lots of work for maintainers when initially building packages and when upgrading to new upstream releases. I'm not sure that it's practical. Some quick grepping around in my fairly sparse installation identified 1388 files in /usr/info and /usr/man/* which mention /usr/local.
Re: New package: die
Having lots of packages is good, but half a dozen (probably often
poor) implementations of the same tiny script in half a dozen
different packages doesn't seem optimal to me.
Of course, there is always...
alias zap 'kill \!:2* `ps -e | grep \!^ | grep -v grep | awk \{print\ \$1\}`'
Crude, but it works.
Brian
( [EMAIL PROTECTED] )
---
In theory, theory and practice are the same. In practice, they're not.
