Re: And now for something completely different... etch!
Manoj Srivastava [EMAIL PROTECTED] (va, manoj) writes: On Wed, 22 Jun 2005 07:22:33 -0400 (EDT), Freddie Unpenstein [EMAIL PROTECTED] said: - inetd begone! - xinetd (better mechanism to control DoS, separation, etc.) xinetd begone. There is no justification for using anything resembling inetd on a modern system. What planet do you live on? I want MORE use of inetd, not less. I want to be able to select a service, and tell the system whether I want it running all the time, or only when needed. Why? What you offer here are preferences and opinions, with nothing to back them up. Previous posters in the discussion have offered reasons not to use inet daemons -- off the top of my head, it was a) in the current day and age, an idling daemon does not consume a significant amount of resources, b) a inted daemon adds complexity to the mix, and another point of failure/attack c) It adds latency to response for the daemon (I may have missed other points). What do you have to counter these points? I can speculate that you may disagree with point a above, but if so, I think in my experience point a has been justified. manoj What amounts to significant is higly usage dependent. In embeded use, e.g. all those wireless routers with linux out there, wasting an extra MB ram might be critical. On the other hand the ram has to be available in case the service does get used anyway. But there might be cases where only one of several alternative services is in use at any given time (e.g. either telnet or http configuration frontend). Having both always loaded needs more resources. Using inetd means services don't have to be manualy restarted when the config file is changed (as that is parsed on each connect). Inetd gives a single point to control access. A single point to filter out unwanted or unalowed access. Easier than to implement the same access restrictions in every daemon. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: And now for something completely different... etch!
On Thu, Jun 23, 2005 at 09:58:31PM +0200, Tollef Fog Heen wrote: * Paul TBBle Hampson | The charset of your terminal is orthogonal to the charset you're | talking on the IRC network with to my mind, since even the built-in | recode support lets you set a default charset for IRC traffic. No, it's not, since at least one of the most popular IRC clients (irssi) doesn't have recode support (yet). Which version are you running? There's recode.pl and charsetwars.pl in irssi-scripts in Woody, and if you grab a CVS build, there's recode support built in too. (Actually, I don't know that charsetwars.pl was in Woody. I only discovered it recently. ^_^) I've been using irssi from a UTF-8 terminal on SJIS channels on my Woody web server since September 2003, at least. The enormous time between irssi releases means I've had to run a CVS version on my unstable local box for about twelve months, to fix interesting DCC and frontend bugs. -- --- Paul TBBle Hampson, MCSE 8th year CompSci/Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) [EMAIL PROTECTED] No survivors? Then where do the stories come from I wonder? -- Capt. Jack Sparrow, Pirates of the Caribbean This email is licensed to the recipient for non-commercial use, duplication and distribution. --- pgpLZKzzTBN3T.pgp Description: PGP signature
Re: And now for something completely different... etch!
* Paul TBBle Hampson | The charset of your terminal is orthogonal to the charset you're | talking on the IRC network with to my mind, since even the built-in | recode support lets you set a default charset for IRC traffic. No, it's not, since at least one of the most popular IRC clients (irssi) doesn't have recode support (yet). -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: And now for something completely different... etch!
- inetd begone! - xinetd (better mechanism to control DoS, separation, etc.) xinetd begone. There is no justification for using anything resembling inetd on a modern system. What planet do you live on? I want MORE use of inetd, not less. I want to be able to select a service, and tell the system whether I want it running all the time, or only when needed. In several cases as it is, I've taken services out of the boot sequence and placed them into ppp.d, inetd, or simply only start them when I need to. Fredderic ___ Join Excite! - http://www.excite.com The most personalized portal on the Web! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: And now for something completely different... etch!
On Wed, 22 Jun 2005 07:22:33 -0400 (EDT), Freddie Unpenstein [EMAIL PROTECTED] said: - inetd begone! - xinetd (better mechanism to control DoS, separation, etc.) xinetd begone. There is no justification for using anything resembling inetd on a modern system. What planet do you live on? I want MORE use of inetd, not less. I want to be able to select a service, and tell the system whether I want it running all the time, or only when needed. Why? What you offer here are preferences and opinions, with nothing to back them up. Previous posters in the discussion have offered reasons not to use inet daemons -- off the top of my head, it was a) in the current day and age, an idling daemon does not consume a significant amount of resources, b) a inted daemon adds complexity to the mix, and another point of failure/attack c) It adds latency to response for the daemon (I may have missed other points). What do you have to counter these points? I can speculate that you may disagree with point a above, but if so, I think in my experience point a has been justified. manoj -- Rome was not built in one day. John Heywood Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: And now for something completely different... etch!
On 06/22/05 12:02:53PM -0500, Manoj Srivastava wrote: On Wed, 22 Jun 2005 07:22:33 -0400 (EDT), Freddie Unpenstein [EMAIL PROTECTED] said: - inetd begone! - xinetd (better mechanism to control DoS, separation, etc.) xinetd begone. There is no justification for using anything resembling inetd on a modern system. What planet do you live on? I want MORE use of inetd, not less. I want to be able to select a service, and tell the system whether I want it running all the time, or only when needed. Why? What you offer here are preferences and opinions, with nothing to back them up. Previous posters in the discussion have offered reasons not to use inet daemons -- off the top of my head, it was a) in the current day and age, an idling daemon does not consume a significant amount of resources, b) a inted daemon adds complexity to the mix, and another point of failure/attack c) It adds latency to response for the daemon (I may have missed other points). What do you have to counter these points? I can speculate that you may disagree with point a above, but if so, I think in my experience point a has been justified. From the security aspect using xinetd automatically gets you things like connection rate limiting, tcp wrappers support, source address restrcitions, available time restrictions, connection logging, interface binding, etc. Sure some daemons already sport those options, but not all do and if a standard is to be chosen it should be safer one. If you know the service well enough to configure it you probably also know how to disable the xinetd instance and enable the init script. manoj Jim. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: And now for something completely different... etch!
On Friday 17 June 2005 22:06, Steve Langasek [EMAIL PROTECTED] wrote: But if someone can change the cache of data written by prelink then why couldn't they also change the program that does the md5 checks to make it always return a good result? They can, but I've never seen a rootkit with that level of sophistication; There have been root-kits that hide files and show the original versions to programs that do checks. This is not really difficult to do with a kernel module. and if there was one, there's still the option of booting from read-only media to check (which is the only safe way to audit your system anyway). True. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: And now for something completely different... etch!
On Thu, Jun 16, 2005 at 01:51:04PM +1000, Russell Coker wrote: regarding prelink On Thursday 16 June 2005 08:18, Steve Langasek [EMAIL PROTECTED] wrote: One of the points of the md5sum verification is to ensure that the binaries haven't been tampered with. If one can tamper with the binaries by modifying some file in /var/cache instead, doesn't that just reintroduce the same problem? There are two basic reasons why people want md5sums of their binaries: to know when their filesystem is eating files, and as an extra layer of security to tell them their binaries have been modified by an intruder. In the first instance, removing the cache and regenerating it would be sufficient to eliminate any corrupted files; in the second instance, removing the cache and regenerating it would be sufficient to eliminate any trojaned files (though, what a strange attack vector that would be :). I think that the idea would be: Prelink changes certain fixed parts of the binary, most of the file is never changed. The parts that are changed would have their original values stored so that a checking tool can do a md5 or sha sum of the main part of the file plus the original values for the parts that prelink changes. In which case, /var/cache is absolutely the wrong place to store those original values, since they can't be regenerated based on information on the rest of the system. I figured people were going the other way around with this, and suggesting that prelink store its *output* in /var/cache, with support in the dynamic loader for merging it in at the correct moment. But if someone can change the cache of data written by prelink then why couldn't they also change the program that does the md5 checks to make it always return a good result? They can, but I've never seen a rootkit with that level of sophistication; and if there was one, there's still the option of booting from read-only media to check (which is the only safe way to audit your system anyway). -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: And now for something completely different... etch!
Enrico Zini dijo [Thu, Jun 09, 2005 at 12:49:39PM +0200]: I've been it_IT.UTF-8 for quite a while with no problems. And I also get to be able to write the name of my girlfriend, which Latin1 cannot encode, together with accented Italian words, which BIG5 cannot encode. H... Silly me thought that Italian was the only Latin language which used no diacritics. Which kind of accents does it have? (yes, OT and couple-of-days-late, I know) -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)1451-2244 / 5623-0154 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF
Re: And now for something completely different... etch!
On Thu, Jun 16, 2005 at 01:01:17AM -0500, Gunnar Wolf wrote: Enrico Zini dijo [Thu, Jun 09, 2005 at 12:49:39PM +0200]: I've been it_IT.UTF-8 for quite a while with no problems. And I also get to be able to write the name of my girlfriend, which Latin1 cannot encode, together with accented Italian words, which BIG5 cannot encode. H... Silly me thought that Italian was the only Latin language which used no diacritics. Which kind of accents does it have? acute and grave accented vowels. -- Steve Langasek postmodern programmer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: And now for something completely different... etch!
Steve Langasek schrieb am Dienstag, 14. Juni 2005 um 03:12:09 -0700: Consistent LFS support - Steve Langasek [EMAIL PROTECTED] Short question: What does LFS mean? The first thing which comes into my mind is Linux from Scratch. Seems not to fit in this context. -- JFriedrich There are only 10 types of people: Those who understand binary and those who don't.
Re: And now for something completely different... etch!
On 6/16/05, Russell Coker [EMAIL PROTECTED] wrote: But if someone can change the cache of data written by prelink then why couldn't they also change the program that does the md5 checks to make it always return a good result? A long, long time ago, you were supposed to boot from a read-only floppy and run the virus scanner from there. I guess the same applies here, if you really wish to be sure.
Re: And now for something completely different... etch!
On 6/16/05, Joerg Friedrich [EMAIL PROTECTED] wrote: Steve Langasek schrieb am Dienstag, 14. Juni 2005 um 03:12:09 -0700: Consistent LFS support - Steve Langasek [EMAIL PROTECTED] Short question: What does LFS mean? The first thing which comes into my mind is Linux from Scratch. Seems not to fit in this context. http://www.google.com/search?q=define:lfs My guess: Large File Support, specifically files larger than 2Gb on 32-bit systems.
Re: And now for something completely different... etch!
Ummm... And if instead of asking the user for a disk change, this mini-initrd just keeps polling the floppy for a non-erroneous read (this means, the drive is not empty) with the correct magic at the correct place? I don't think you actually have to read anything. You can use the disk change line to see if a disk has been inserted or not. Cheers, Peter (p2). signature.asc Description: Digital signature
Re: And now for something completely different... etch!
On Wednesday 15 Jun 2005 10:09, Steve Langasek wrote: On Wed, Jun 15, 2005 at 10:31:45AM +0200, Petter Reinholdtsen wrote: I didn't see anyone proposing prelinking so far. I've seen rumors that program start time for some programs decrease a lot if prelinking is enabled. It would be nice if we could speed up the login time, or for example the openoffice start time. Is prelinking the way to go? Should it be enabled by default? Using prelink invalidates the md5sums of files belonging to Debian packages. Has anyone done any work to address this? Not that I know of, and that's why we do not enable it by default in OOo. Actually, on the subject of OOo load time, that should decrease significantly once we have it compiled with the new gcc that has symbol visibility support. 75% of OOo startup time is spent in the dynamic linker, so reducing the number of symbols that need to be resolved will make a big difference. Chris -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: And now for something completely different... etch!
On Thu, Jun 16, 2005 at 01:01:17AM -0500, Gunnar Wolf wrote: H... Silly me thought that Italian was the only Latin language which used no diacritics. Which kind of accents does it have? Italian can have accents over vowels, some are read differently if they are grave or acute: it's also matter of debate if the accent over a, i or u is grave or acute. Dieresis are used in poetry, to split a diptongue (pit) as well as when writing words coming from some dialect (sira). Circumflexes were used in the past when a word becoming plural would end in double 'i' (decliv). More could show up when spelling arcaic Italian (who sometimes had an extra letter for a sweet 'z' sound), dialects (who have all sort of diacritics that can change from dialect to dialect and from spelling method to spelling method) or of course when writing mixed languages in the boundary regions where there is more than one official language. Ciao, Enrico -- GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: And now for something completely different... etch!
Gunnar Wolf wrote: Enrico Zini dijo [Thu, Jun 09, 2005 at 12:49:39PM +0200]: I've been it_IT.UTF-8 for quite a while with no problems. And I also get to be able to write the name of my girlfriend, which Latin1 cannot encode, together with accented Italian words, which BIG5 cannot encode. H... Silly me thought that Italian was the only Latin language which used no diacritics. Which kind of accents does it have? Even en_GB has diacritics. Hopefully all this encoding problems disappear with the growing popularity of UNICODE/UTF-8. E.g. besides German, Hungarian, Slowenian und Croation are official languages here in Austria, which must be supported through local government. Choosing Latin1 is a common mistake, 'Eastern Latin' would be the better choice. Besides it would IMHO be more political correct to write the names of all the Polish, Balkan, French, Eastern, Scandinavian and Latinos living here with original diacritics. Helmut Wollmersdorfer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: And now for something completely different... etch!
On Thu, Jun 09, 2005 at 10:09:06AM +0200, Tollef Fog Heen wrote: * Christian Perrier | Again, do not mess with cultures you do not understand. | | Do you have real examples? IRC. An example is the current irssi in Debian which doesn't do recoding between different locales. (And that is needed, since IRC doesn't have a charset concept and there are still loads and loads of users out there with clients which interpret everything as Latin1.) I'm not clear how this is an argument against UTF-8 by default...? The charset of your terminal is orthogonal to the charset you're talking on the IRC network with to my mind, since even the built-in recode support lets you set a default charset for IRC traffic. -- --- Paul TBBle Hampson, MCSE 8th year CompSci/Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) [EMAIL PROTECTED] No survivors? Then where do the stories come from I wonder? -- Capt. Jack Sparrow, Pirates of the Caribbean This email is licensed to the recipient for non-commercial use, duplication and distribution. --- pgpFwhEZSTmSu.pgp Description: PGP signature
Re: And now for something completely different... etch!
I didn't see anyone proposing prelinking so far. I've seen rumors that program start time for some programs decrease a lot if prelinking is enabled. It would be nice if we could speed up the login time, or for example the openoffice start time. Is prelinking the way to go? Should it be enabled by default? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: And now for something completely different... etch!
On Wed, Jun 15, 2005 at 10:31:45AM +0200, Petter Reinholdtsen wrote: I didn't see anyone proposing prelinking so far. I've seen rumors that program start time for some programs decrease a lot if prelinking is enabled. It would be nice if we could speed up the login time, or for example the openoffice start time. Is prelinking the way to go? Should it be enabled by default? Using prelink invalidates the md5sums of files belonging to Debian packages. Has anyone done any work to address this? -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: And now for something completely different... etch!
On Tue, Jun 14, 2005 at 03:12:09AM -0700, Steve Langasek wrote: On Tue, Jun 07, 2005 at 01:03:12AM +0200, Javier Fernández-Sanguino Peña wrote: So, without further delay, here's my Etch-wishlist, it's biased on some of the things I've personally worked on and would like to keep working on for etch. I would love to hear the Release Managers opinion on what they believe should be Release Goals for etch besides the things we all already know about (non-free documentation purged from main, changes in supported architectures...) Feel free to add some new items or add (hopefully new) information to the ones I list below: Ok, sure. Here are a few one-liners about various things I'm aware of that one person or another wants to see happen in the etch timeframe, together with the name of the person who has claimed responsibility: Toolchain update to gcc/g++ 4.0 - Matthias Klose [EMAIL PROTECTED] Switch to dependency-based init.d handling -- Lars Wirzenius [EMAIL PROTECTED] Drop libpng2/libpng10-0/libpng3 packages - Josselin Mouette [EMAIL PROTECTED] Drop libmysqlclient10/libmysqlclient12 packages - Adam Conrad [EMAIL PROTECTED] Consistent LFS support - Steve Langasek [EMAIL PROTECTED] Bend all library packages to my will - Steve Langasek [EMAIL PROTECTED] You seem to have a rather long wishlist of your own; are these all things that you personally plan to work on during the etch cycle? If so, kudos! If not, which ones are you expecting to spend your time on, and which are you looking for help with? Hi Steve, I was thinking of Bridge, at least the little I know about the game, where you guess how many tricks(in this case tasks) you can get in the game -- a contract I think. Would it be cruel to make some such page of 'contracts' updated by each DD and have someone update the list of completed tasks monthly. Since volunteers in Debian work on what floats their boat, I'd be curious to see by release's end, who has lived up to their own expectations of their contract. Any one for betting? Would having a public airing of one's own goals be motivating or not? just feeling in a devilish mood ;-) Cheers, Kev -- counter.li.org #238656 -- goto counter.li.org and be counted! `$' $' $ $ _ ,d$$$g$ ,d$$$b. $,d$$$b`$' g$b $,d$$b ,$P' `$ ,$P' `Y$ $$' `$ $ ' `$ $$' `$ $$ $ $$g$ $ $ $ ,$P $ $$ `$g. ,$$ `$$._ _. $ _,g$P $ `$b. ,$$ $$ `Y$$P'$. `YP $$$P' ,$. `Y$$P'$ $. ,$. signature.asc Description: Digital signature
Re: And now for something completely different... etch!
On Wed, Jun 15, 2005 at 02:09:49AM -0700, Steve Langasek wrote: On Wed, Jun 15, 2005 at 10:31:45AM +0200, Petter Reinholdtsen wrote: I didn't see anyone proposing prelinking so far. I've seen rumors that program start time for some programs decrease a lot if prelinking is enabled. It would be nice if we could speed up the login time, or for example the openoffice start time. Is prelinking the way to go? Should it be enabled by default? Using prelink invalidates the md5sums of files belonging to Debian packages. Has anyone done any work to address this? The only way to address that is to update the md5sum after prelinking is done. However, doing that is rather problematic, as it would either require a check of the md5sum before the prelinking phase, or result in a binary where the md5sum isn't useful anymore (it might have been compromised in the time between the installation of the package and the last update of the md5sum). -- The amount of time between slipping on the peel and landing on the pavement is precisely one bananosecond -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: And now for something completely different... etch!
On Wed, 2005-06-15 at 12:45 +0200, Wouter Verhelst wrote: Using prelink invalidates the md5sums of files belonging to Debian packages. Has anyone done any work to address this? The only way to address that is to update the md5sum after prelinking is done. I might be talking out of my arse (99% probability ;-)) but I thought I'd heard that it was possible to store the pre-linking information separately to the binaries, under /var/cache or something for example. Am/was I imagining things? Ian. -- Ian Campbell Current Noise: Slayer - Jesus Saves Randal can write one-liners again. Everyone is happy, and peace spreads over the whole Earth. -- Larry Wall in [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: And now for something completely different... etch!
On 6/15/05, Ian Campbell [EMAIL PROTECTED] wrote: On Wed, 2005-06-15 at 12:45 +0200, Wouter Verhelst wrote: Using prelink invalidates the md5sums of files belonging to Debian packages. Has anyone done any work to address this? The only way to address that is to update the md5sum after prelinking is done. I might be talking out of my arse (99% probability ;-)) but I thought I'd heard that it was possible to store the pre-linking information separately to the binaries, under /var/cache or something for example. Am/was I imagining things? I was thinking about that solution too. If it doesn't exist, we'll just have to create it. :)
Re: And now for something completely different... etch!
Ian Campbell [EMAIL PROTECTED] writes: I might be talking out of my arse (99% probability ;-)) but I thought I'd heard that it was possible to store the pre-linking information separately to the binaries, under /var/cache or something for example. Am/was I imagining things? One of the points of the md5sum verification is to ensure that the binaries haven't been tampered with. If one can tamper with the binaries by modifying some file in /var/cache instead, doesn't that just reintroduce the same problem? -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: And now for something completely different... etch!
On 6/15/05, Russ Allbery [EMAIL PROTECTED] wrote: Ian Campbell [EMAIL PROTECTED] writes: I might be talking out of my arse (99% probability ;-)) but I thought I'd heard that it was possible to store the pre-linking information separately to the binaries, under /var/cache or something for example. Am/was I imagining things? One of the points of the md5sum verification is to ensure that the binaries haven't been tampered with. If one can tamper with the binaries by modifying some file in /var/cache instead, doesn't that just reintroduce the same problem? But it leaves the choice of using prelinking to the user instead of 'forcing' the entire system to use it.
Re: And now for something completely different... etch!
On Wed, 2005-06-15 at 13:10 -0700, Russ Allbery wrote: Ian Campbell [EMAIL PROTECTED] writes: I might be talking out of my arse (99% probability ;-)) but I thought I'd heard that it was possible to store the pre-linking information separately to the binaries, under /var/cache or something for example. Am/was I imagining things? One of the points of the md5sum verification is to ensure that the binaries haven't been tampered with. If one can tamper with the binaries by modifying some file in /var/cache instead, doesn't that just reintroduce the same problem? I guess so, but then the prelinking tool could just store the md5 sums of the prelink data files somewhere. Ian. -- Ian Campbell I HAVE to buy a new DODGE MISER and two dozen JORDACHE JEANS because my viewscreen is USER-FRIENDLY!! signature.asc Description: This is a digitally signed message part
Re: And now for something completely different... etch!
On Jun 15, Olaf van der Spek [EMAIL PROTECTED] wrote: But it leaves the choice of using prelinking to the user instead of 'forcing' the entire system to use it. There is no need to choose. If prelinking works, all users should use prelinking. -- ciao, Marco signature.asc Description: Digital signature
Re: And now for something completely different... etch!
[ Note: I was unsubscribe to -devel due to a hw problem in my current
mail-end so this quoting is suboptimal, had to use the web archives ]
Steve said:
Ok, sure. Here are a few one-liners about various things I'm aware of
that one person or another wants to see happen in the etch timeframe,
together with the name of the person who has claimed responsibility:
Added to my list (will resubmit it when the thread settles down).
You seem to have a rather long wishlist of your own; are these all things
that you personally plan to work on during the etch cycle? If so, kudos!
If not, which ones are you expecting to spend your time on, and which are
you looking for help with?
I'm neither brilliant enough nor do I have enough spare time to work
on all of those. I pumped up the list for others to discuss and
(maybe) take over. I'm working or plan to work in:
- QA of base packages (did my share of NMUs to some already and I'm
willing to do more, if the maintainers allow me to :)
- Security audits of core and extra packages
- Improvements of checksecurity and cron for sysadmins
- Documentation improvements (and better exposure of i18n docs)
- QA of Dummy and unmaintained packages
I would like maintainers to get involved in any and all the items of
the wishlist that they feel are worth working on. The discussion in
this thread highlights many things that people believe should be
improved on (even though there might be different POVs on some
issues). I'm sad to see some important (to me) features that
nobody else thinks are worth discussing about but if they are not done
it's no big deal.
Javier said:
[ Release improvements ]
- Prune packages from release based on popularity, packages which are not
used by anyone should not go in! (not enough peer review, probably
not audited, bug ridden with bugs, including security making security
handling a nightmare)
It is, after all, quite difficult to determine that a package is not used by
*anyone*. You can use popcon to give you prospective candidates, but popcon
doesn't prove the package is unused (and, well, a simple statement from the
maintainer is counterevidence).
That doesn't mean I think you're using the wrong metric; I'm just noting
that the payoff for looking for unused packages tends to be very low
:)
When doing automatic source code security auditing of some basic stuff
(/tmp races) early this year I've found an important correlation
between the popcon value and whether ASAT (my Advanced Security Audit
Tool (TM) [1]) had found a real security bug or it was just a false
positive. The lower the popcon value, the higher the chance of it
being a real security bug.
In any case, popcon is currently, IMHO, a better metric to detect low
quality stuff than bug counts since over-used packages (with,
consequently, have higher popularity values) attrack far more bugs
than packages that are only used by 1 person (its maintainer). Maybe
considering also the frequency of uploads to the archive or the time
of the last upload would help in detecting under-maintained stuff. I'll
let the QA team decide on that :-)
Regards
Javier
[1] Actually it was something like:
for each package in the distribution;
unpack in {package_dir}
run find {package_dir} -xdev -type f 2/dev/null |xargs grep -ir /tmp |
grep -v ^/usr/share/doc
:-)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: And now for something completely different... etch!
On Wed, Jun 15, 2005 at 01:10:57PM -0700, Russ Allbery wrote: Ian Campbell [EMAIL PROTECTED] writes: I might be talking out of my arse (99% probability ;-)) but I thought I'd heard that it was possible to store the pre-linking information separately to the binaries, under /var/cache or something for example. Am/was I imagining things? One of the points of the md5sum verification is to ensure that the binaries haven't been tampered with. If one can tamper with the binaries by modifying some file in /var/cache instead, doesn't that just reintroduce the same problem? There are two basic reasons why people want md5sums of their binaries: to know when their filesystem is eating files, and as an extra layer of security to tell them their binaries have been modified by an intruder. In the first instance, removing the cache and regenerating it would be sufficient to eliminate any corrupted files; in the second instance, removing the cache and regenerating it would be sufficient to eliminate any trojaned files (though, what a strange attack vector that would be :). -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: And now for something completely different... etch!
Goswin von Brederlow dijo [Sun, Jun 12, 2005 at 08:46:47AM +0200]: Intermittendly we had a multi floppy setup. The first floppy contains the kernel and a minimal initrd. That prompts for the second floppy and the user to press return and then adds the contents of the 2nd floppy to tmpfs. There was just one problem with it: The floppy was to small to include usb keyboard support. Ummm... And if instead of asking the user for a disk change, this mini-initrd just keeps polling the floppy for a non-erroneous read (this means, the drive is not empty) with the correct magic at the correct place? Greetings, -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)1451-2244 / 5623-0154 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: And now for something completely different... etch!
Gunnar Wolf wrote: Ummm... And if instead of asking the user for a disk change, this mini-initrd just keeps polling the floppy for a non-erroneous read (this means, the drive is not empty) with the correct magic at the correct place? This assumes that the kernel works better than it really does. You'll get oopes on some machines, I can tell you from experience. -- see shy jo signature.asc Description: Digital signature
Re: And now for something completely different... etch!
regarding prelink On Thursday 16 June 2005 08:18, Steve Langasek [EMAIL PROTECTED] wrote: One of the points of the md5sum verification is to ensure that the binaries haven't been tampered with. If one can tamper with the binaries by modifying some file in /var/cache instead, doesn't that just reintroduce the same problem? There are two basic reasons why people want md5sums of their binaries: to know when their filesystem is eating files, and as an extra layer of security to tell them their binaries have been modified by an intruder. In the first instance, removing the cache and regenerating it would be sufficient to eliminate any corrupted files; in the second instance, removing the cache and regenerating it would be sufficient to eliminate any trojaned files (though, what a strange attack vector that would be :). I think that the idea would be: Prelink changes certain fixed parts of the binary, most of the file is never changed. The parts that are changed would have their original values stored so that a checking tool can do a md5 or sha sum of the main part of the file plus the original values for the parts that prelink changes. Changing the parts of the file which were changed by prelink such that the md5 or sha matches even after changing the body of the file would require cracking md5 or sha - this may be possible but is still quite difficult. But if someone can change the cache of data written by prelink then why couldn't they also change the program that does the md5 checks to make it always return a good result? -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: And now for something completely different... etch!
Joey Hess dijo [Wed, Jun 15, 2005 at 09:40:59PM -0400]: Gunnar Wolf wrote: Ummm... And if instead of asking the user for a disk change, this mini-initrd just keeps polling the floppy for a non-erroneous read (this means, the drive is not empty) with the correct magic at the correct place? This assumes that the kernel works better than it really does. You'll get oopes on some machines, I can tell you from experience. What can I do but long at the Amiga? ;-) -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)1451-2244 / 5623-0154 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF
Re: And now for something completely different... etch!
Andrew Suffield dijo [Tue, Jun 07, 2005 at 02:32:53PM +0100]: - Separate runlevels: 2 for multi, no net, 3 for multi no X, 4 for X, 4=5 No way. Debian has always avoided mindlessly dictating what runlevels must be used for. There's no reason to destroy this feature now. And there's no advantage to consuming an entire runlevel just to say /etc/init.d/xdm stop or /etc/init.d/networking stop, which is all that you are proposing. We could provide default settings that lead to the LSB-specified functionality that Javier suggests, but without falling in RedHat's IMHO fucked up habit of starting [xwkg]dm not from an explicit script (/etc/rc?.d/Sxx?dm), but directly from /etc/inittab, hiding it from the user. If our display manager packages are set up to start only from runlevel 4 or higher, but you and me can set them up to start on any lower ones, we'll all be happy, won't we? Same thing for networking. Greetings, -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)1451-2244 / 5623-0154 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF
Re: And now for something completely different... etch!
[Darren Salt] ISTM that a non-standard disk format (21 sectors per track and/or more tracks) would help - or would this just cause too many problems? I think it's safe to assume anyone can boot and read a 1600 kB floppy. 1743 kB is common but possibly problematic. signature.asc Description: Digital signature
Re: And now for something completely different... etch!
On Mon, Jun 13, 2005 at 04:00:25PM -0500, John Hasler wrote: Nothing, except for the fact that most admins haven't the foggiest idea how to do that. Thus the suggestion that the default runlevels be what most people expect them to be. And it _does_ come with predefined options and settings: ones unique to Debian. 5 runlevels acting exactly the same way? -- Jesus Climent info:www.pumuki.org Unix SysAdm|Linux User #66350|Debian Developer|2.6.10|Helsinki Finland GPG: 1024D/86946D69 BB64 2339 1CAA 7064 E429 7E18 66FC 1D7F 8694 6D69 Bates Motel... 12 rooms, 12 vacancies. --Norman Bates (Psycho) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: And now for something completely different... etch!
On Tue, Jun 07, 2005 at 01:03:12AM +0200, Javier Fernández-Sanguino Peña wrote: So, without further delay, here's my Etch-wishlist, it's biased on some of the things I've personally worked on and would like to keep working on for etch. I would love to hear the Release Managers opinion on what they believe should be Release Goals for etch besides the things we all already know about (non-free documentation purged from main, changes in supported architectures...) Feel free to add some new items or add (hopefully new) information to the ones I list below: Ok, sure. Here are a few one-liners about various things I'm aware of that one person or another wants to see happen in the etch timeframe, together with the name of the person who has claimed responsibility: Toolchain update to gcc/g++ 4.0 - Matthias Klose [EMAIL PROTECTED] Switch to dependency-based init.d handling -- Lars Wirzenius [EMAIL PROTECTED] Drop libpng2/libpng10-0/libpng3 packages - Josselin Mouette [EMAIL PROTECTED] Drop libmysqlclient10/libmysqlclient12 packages - Adam Conrad [EMAIL PROTECTED] Consistent LFS support - Steve Langasek [EMAIL PROTECTED] Bend all library packages to my will - Steve Langasek [EMAIL PROTECTED] You seem to have a rather long wishlist of your own; are these all things that you personally plan to work on during the etch cycle? If so, kudos! If not, which ones are you expecting to spend your time on, and which are you looking for help with? It would be nice to see more communication still from maintainers when they're planning large transitions in unstable; for instance, GNOME 2.10 started being uploaded to unstable without anyone letting the release team know it was coming, and I'm told there are a couple of places where this might make the toolchain transition more complicated than it needed to be. [ Release improvements ] - Prune packages from release based on popularity, packages which are not used by anyone should not go in! (not enough peer review, probably not audited, bug ridden with bugs, including security making security handling a nightmare) It is, after all, quite difficult to determine that a package is not used by *anyone*. You can use popcon to give you prospective candidates, but popcon doesn't prove the package is unused (and, well, a simple statement from the maintainer is counterevidence). That doesn't mean I think you're using the wrong metric; I'm just noting that the payoff for looking for unused packages tends to be very low :) - Remove _all_ out of date dummy packages! (see #308711 and other bugs!) Ongoing area of work; Jeroen has bumped these bugs to 'serious' now, so they ought to find themselves cleaned up fairly quickly, I think. - Better (not manual!) tracking of bugs associated with testing release Which we get when version tracking is added to the BTS. Cheers, -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: And now for something completely different... etch!
Steve Langasek [EMAIL PROTECTED] writes: Toolchain update to gcc/g++ 4.0 - Matthias Klose [EMAIL PROTECTED] Switch to dependency-based init.d handling -- Lars Wirzenius [EMAIL PROTECTED] Drop libpng2/libpng10-0/libpng3 packages - Josselin Mouette [EMAIL PROTECTED] Drop libmysqlclient10/libmysqlclient12 packages - Adam Conrad [EMAIL PROTECTED] Consistent LFS support - Steve Langasek [EMAIL PROTECTED] libpcap0.9 transition - myself (more on that later) -- ,''`. : :' :Romain Francoise [EMAIL PROTECTED] `. `' http://people.debian.org/~rfrancoise/ `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: And now for something completely different... etch!
On Tue, Jun 14, 2005 at 02:00:02PM +0200, Romain Francoise wrote: Steve Langasek [EMAIL PROTECTED] writes: Toolchain update to gcc/g++ 4.0 - Matthias Klose [EMAIL PROTECTED] Switch to dependency-based init.d handling -- Lars Wirzenius [EMAIL PROTECTED] Drop libpng2/libpng10-0/libpng3 packages - Josselin Mouette [EMAIL PROTECTED] Drop libmysqlclient10/libmysqlclient12 packages - Adam Conrad [EMAIL PROTECTED] Consistent LFS support - Steve Langasek [EMAIL PROTECTED] libpcap0.9 transition - myself (more on that later) Getting rid of circular dependencies - myself Several menu transitions - myself Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: And now for something completely different... etch!
On Monday 13 June 2005 23.00, John Hasler wrote: Jesus Climent writes: Exactly my point, what impedes an admin to set some defaults wether the system comes as it comes now or with some predefined options and settings? Nothing, except for the fact that most admins haven't the foggiest idea how to do that. Thus the suggestion that the default runlevels be what most people expect them to be. The people you probably mean when you write admin (with the quotes) usually, in my experience, go into blank-stare-mode when I mention the word 'runlevel' or even 'command line'. I guess you can count me to the the people who care will have their own ideas anyway, 90% of all others don't know anything and so wouldn't be able to take advantage of any special runlevel configuration fraction. cheers -- vbi -- Today is Setting Orange, the 19th day of Confusion in the YOLD 3171 pgp5HgMg0W1UA.pgp Description: PGP signature
Re: And now for something completely different... etch!
On Mon, 13 Jun 2005 22:01:58 +0200, Jesus Climent [EMAIL PROTECTED] said: On Thu, Jun 09, 2005 at 09:25:22AM +1000, Matthew Palmer wrote: On Thu, Jun 09, 2005 at 01:13:16AM +0200, Javier Fernández-Sanguino Peña wrote: to find their own (sometimes flawed) solution to a very common problem. Years using Linux: 10. Times I've absolutely needed an X-less boot when an XDM was installed: 0. How common was that problem you were trying to solve, again? Years using linux: 11 (argh, or 12, i cannot even remember) Times I needed the above discussed feature: several. That common is common enough? Not really. There is nothing to indicate that how you fashioned your run levels would make sense for, say, me. People whoi really want tailored run-levels often have very definite ideas about how these run-levels would be tailored; it is unlikely that a predefined solution designed by committee in Debian would suit their needs, and they would have to roll their own, anyway, and a predefined solution would just get in their way. _Why_ did you not create you own run level schema, BTW, if you have indeed needed them so often? (I haven't felt that itch yet, or I would have; creating differentiated run levels is not exactly rocket science). manoj -- The Schizophrenic: An Unauthorized Autobiography Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: And now for something completely different... etch!
Maybe I can shed some light on this ** Manoj Srivastava :: That common is common enough? Not really. There is nothing to indicate that how you fashioned your run levels would make sense for, say, me. People whoi really want tailored run-levels often have very definite ideas about how these run-levels would be tailored; it is unlikely that a predefined solution designed by committee in Debian would suit their needs, and they would have to roll their own, anyway, and a predefined solution would just get in their way. _Why_ did you not create you own run level schema, BTW, if you have indeed needed them so often? (I haven't felt that itch yet, or I would have; creating differentiated run levels is not exactly rocket science). I think this all evades the real questions, that are: (1) LSB -- which Debian's policy vows to follow -- mandates the default differentiated runlevels. Why are not doing it? (2) The differentiated runlevels by default *do* have practical, and in many cases important, utilizations (the X-freezing is a good example). Why not? (3) Substituting diferentiated runlevels by the old, 3-runlevel scheme is relatively easy, as it is to create otherwise customized runlevels, independently of where one comes from. So, why not? (4) It *does* generate an unnecessary difference between Debian and *all* *other* distros, with no reasonable motive at all. IE, IMHO, Debian should adopt the 6-runlevel scheme dictated by the LSB (0=off, 1=single, 2=multi,no-net, 3=multi, 4=5=multi+DM, 6=reboot) because (1) it's praxis to the other distros, (2) it's in the LSB and (3) there is no good reason not to. -- HTH, Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: And now for something completely different... etch!
On Tue, 14 Jun 2005 14:14:45 -0300, Humberto Massa Guimarães [EMAIL PROTECTED] said: Maybe I can shed some light on this ** Manoj Srivastava :: That common is common enough? Not really. There is nothing to indicate that how you fashioned your run levels would make sense for, say, me. People whoi really want tailored run-levels often have very definite ideas about how these run-levels would be tailored; it is unlikely that a predefined solution designed by committee in Debian would suit their needs, and they would have to roll their own, anyway, and a predefined solution would just get in their way. _Why_ did you not create you own run level schema, BTW, if you have indeed needed them so often? (I haven't felt that itch yet, or I would have; creating differentiated run levels is not exactly rocket science). I think this all evades the real questions, that are: (1) LSB -- which Debian's policy vows to follow -- mandates the default differentiated runlevels. Why are not doing it? The Debian technical policy does no such thing. Could yopu point to me the section that says otherwise, if you think I am wrong? Certainly, some Debian developers have expressed support for the LSB, and have put in work to ensure we comply where we can, but there is no mandated policy which is being ignored here. (2) The differentiated runlevels by default *do* have practical, and in many cases important, utilizations (the X-freezing is a good example). Why not? There is nothing that states that there is a run level schema that would fit most users better than the one we have now. We have mechanisms to allow for starting, or not, of daemons at far fner granularity than a static, 3-more-diffrentiated-levels schemas that I have seen. (3) Substituting diferentiated runlevels by the old, 3-runlevel scheme is relatively easy, as it is to create otherwise customized runlevels, independently of where one comes from. So, why not? It is work, and most users seem to not care. The few that do, often do not agree with each other about what a run level schema oughty to look like. (4) It *does* generate an unnecessary difference between Debian and *all* *other* distros, with no reasonable motive at all. We differ on what we considered reasonable. IE, IMHO, Debian should adopt the 6-runlevel scheme dictated by the LSB (0=off, 1=single, 2=multi,no-net, 3=multi, 4=5=multi+DM, 6=reboot) because (1) it's praxis to the other distros, (2) it's in the LSB and (3) there is no good reason not to. Shrug. Talk to the people whoi do the work, then, or those responsible for these packages. manoj -- To be or not to be, that is the bottom line. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
mail clients and threading... (was: Re: And now for something completely different... etch!)
On Tuesday 14 June 2005 19.14, Humberto Massa Guimarães wrote: [...] Hmmm. Is it just my kmail, or does your mailer produce strange (or no?) In-Reply-To headers? All your posts I saw (and none others afaict) appeared to be in reply to some completely irrelevant other message in the same thread - it's extremely annoying to read your postings that way. cheers -- vbi -- Beware of the FUD - know your enemies. This week * Patent Law, and how it is currently abused. * http://fortytwo.ch/opinion pgp0zUh6k4URu.pgp Description: PGP signature
RE: And now for something completely different... etch!
** Manoj Srivastava :: (4) It *does* generate an unnecessary difference between Debian and *all* *other* distros, with no reasonable motive at all. We differ on what we considered reasonable. But not *one* reasonable motive for differing was cited in this whole thread. So, right, we differ on what we consider reasonable, but why is differing in this point considered reasonable? IE, IMHO, Debian should adopt the 6-runlevel scheme dictated by the LSB (0=off, 1=single, 2=multi,no-net, 3=multi, 4=5=multi+DM, 6=reboot) because (1) it's praxis to the other distros, (2) it's in the LSB and (3) there is no good reason not to. Shrug. Talk to the people whoi do the work, then, or those responsible for these packages. I assumed they would be on-list... -- Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mail clients and threading... (was: Re: And now for something completely different... etch!)
On Tue, Jun 14, 2005 at 08:06:07PM +0200, Adrian von Bidder wrote: On Tuesday 14 June 2005 19.14, Humberto Massa Guimarães wrote: [...] Hmmm. Is it just my kmail, or does your mailer produce strange (or no?) In-Reply-To headers? It's not just you. All your posts I saw (and none others afaict) appeared to be in reply to some completely irrelevant other message in the same thread - it's extremely annoying to read your postings that way. X-Mailer: Internet Mail Service (5.5.2653.19) Idiotic MS junk, I believe... -- Society is never going to make any progress until we all learn to pretend to like each other. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: And now for something completely different... etch!
Adrian von Bidder writes: The people you probably mean when you write admin (with the quotes) usually, in my experience, go into blank-stare-mode when I mention the word 'runlevel' or even 'command line'. There are many who have a primitive notion of what runlevels are and how to use them but have no idea how to change them. The advice to boot to runlevel 3 to fix X is commonly seen even on debian-user. -- John Hasler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: And now for something completely different... etch!
On Tue, Jun 14, 2005 at 02:14:45PM -0300, Humberto Massa Guimarães wrote: Maybe I can shed some light on this ** Manoj Srivastava :: That common is common enough? Not really. There is nothing to indicate that how you fashioned your run levels would make sense for, say, me. People whoi really want tailored run-levels often have very definite ideas about how these run-levels would be tailored; it is unlikely that a predefined solution designed by committee in Debian would suit their needs, and they would have to roll their own, anyway, and a predefined solution would just get in their way. _Why_ did you not create you own run level schema, BTW, if you have indeed needed them so often? (I haven't felt that itch yet, or I would have; creating differentiated run levels is not exactly rocket science). I think this all evades the real questions, that are: (1) LSB -- which Debian's policy vows to follow -- mandates the default differentiated runlevels. No. Please read http://refspecs.freestandards.org/LSB_2.1.0/LSB-Core-generic/LSB-Core-generic/runlevels.html. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: And now for something completely different... etch!
On Tue, Jun 14, 2005 at 01:01:25PM -0500, Manoj Srivastava wrote: (3) Substituting diferentiated runlevels by the old, 3-runlevel scheme is relatively easy, as it is to create otherwise customized runlevels, independently of where one comes from. So, why not? It is work, and most users seem to not care. The few that do, often do not agree with each other about what a run level schema oughty to look like. There's pretty strong agreement, actually, that it should look like the one used by Red Hat et al., which is clearly defined and has a long history... IE, IMHO, Debian should adopt the 6-runlevel scheme dictated by the LSB (0=off, 1=single, 2=multi,no-net, 3=multi, 4=5=multi+DM, 6=reboot) because (1) it's praxis to the other distros, (2) it's in the LSB and (3) there is no good reason not to. Shrug. Talk to the people whoi do the work, then, or those responsible for these packages. So you would have the maintainers of the display manager packages implement these changes unilaterally? -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: And now for something completely different... etch!
On Tue, Jun 14, 2005 at 11:47:38AM -0500, Manoj Srivastava wrote: On Mon, 13 Jun 2005 22:01:58 +0200, Jesus Climent [EMAIL PROTECTED] said: _Why_ did you not create you own run level schema, BTW, if you have indeed needed them so often? (I haven't felt that itch yet, or I would have; creating differentiated run levels is not exactly rocket science). Because other did it for me. It is called LSB, and i think we should adhere to it, while keeping the possibility of configuring your runlevels the way you please. The question is: why is the Debian default any better than the LSB one, if we can keep the possibility of self-configuration? -- Jesus Climent info:www.pumuki.org Unix SysAdm|Linux User #66350|Debian Developer|2.6.10|Helsinki Finland GPG: 1024D/86946D69 BB64 2339 1CAA 7064 E429 7E18 66FC 1D7F 8694 6D69 You're just jealous because I'm a real freak and you have to wear a mask. --Penguin (Batman Returns) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: And now for something completely different... etch!
Steve Langasek [EMAIL PROTECTED] writes: On Tue, Jun 14, 2005 at 02:14:45PM -0300, Humberto Massa Guimarães wrote: (1) LSB -- which Debian's policy vows to follow -- mandates the default differentiated runlevels. No. Please read http://refspecs.freestandards.org/LSB_2.1.0/LSB-Core-generic/LSB-Core-generic/runlevels.html. Given that they *suggest* a set of runlevels, which provides one spare for local config, would it be out of order for users to file wishlist bugs on packages not following these guidelines? cheers, Rich. -- rich walker | Shadow Robot Company | [EMAIL PROTECTED] technical director 251 Liverpool Road | need a Hand? London N1 1LX | +UK 20 7700 2487 www.shadow.org.uk/products/newhand.shtml -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: And now for something completely different... etch!
Em Dom, 2005-06-12 s 00:38 +0200, Frans Pop escreveu: IMO we should try very hard to keep floppy installation supported. Everything depends on how much we're 'paying' for such a support. If the overhead gets very hard to handle we better choose to drop some support in order to keep ourselves sane. You will allways have the option of bootstraping your system using an older version of Debian, for example, and then upgrading to the version you actually want to use. We should not be exchanging our developers' sanity for somewhat rare corner cases which you can work around in a somewhat easy way. See ya, -- [EMAIL PROTECTED]: Gustavo Noronha http://people.debian.org/~kov Debian: http://www.debian.org * http://www.debian-br.org signature.asc Description: This is a digitally signed message part
Re: And now for something completely different... etch!
Andreas Gredler [EMAIL PROTECTED] writes: On Sun, Jun 12, 2005 at 02:17:08PM +1000, Russell Coker wrote: On Sunday 12 June 2005 09:14, Frans Pop [EMAIL PROTECTED] wrote: Some older BIOSes don't allow booting from CD-ROM, let alone netbooting or It's easy to solve the problem of a BIOS that doesn't support booting from CD-ROM. You have a boot loader on a floppy disk that loads the kernel and initrd from CD. This is of course a good workaround. But this floppies have to be available. Does debian have such floppies? People who have really old hardware should ask at their local LUG if someone has any unused computers that they don't need. I've offered quite a few old computers for free to members of my LUG. Recently I offered a P3-800 machine with broken PSU and a Pentium 200 machine that was fully operational and found no-one who wanted them. It seems that at my LUG there's no-one who has lesser hardware. I've seen a lot of servers for small companies, which are older ;-( greets Jimmy The i386 CD images contain a floppy image of the smart boot manager (sbm) that allows you to boot cdroms on hardware that doesn't. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: And now for something completely different... etch!
Steve Greenland([EMAIL PROTECTED])@2005-06-09 10:06: I suspect that the problem is that you're confusing obsolete with not current. Obsolete caries the connotation of useless except for entertainment/hobbiest purposes. For example, steam engine cars are obsolete. The 1999 Toyota Camry is not. Of course, one should remember that obsolescence is subjective. Some might argue that the 1999 Toyota Camry was obsolete at birth while a steam engine car is still an attractive proposition :-) Steve -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: And now for something completely different... etch!
On 2005-06-12, Goswin von Brederlow [EMAIL PROTECTED] wrote: The best way to make multi floppy boot work would be to use initramfs with a static C binary linked against klibc that does the prompting and loading of the 2nd/3rd/... floppy. That way you can save as much space as possible for kernel and modules (or similar with initrd for 2.4.x). I don't know anything about klibc, but I would like to add that you don't necessarily need to link against any libc in order to prompt and load more as long as you only use kernel syscalls. One good example of this are the initrd's created by loop-aes's build-initrd.sh which only use syscalls to mount another partition; it then uses a trick to mount this second partition as /lib so you can have there a full glibc and any other libraries, binaries and/or modules. This gives you a nice 2KiB initrd. (Recent versions of build-initrd.sh link against dietlibc, but don't initialize it, the reason for this is to allow parameter passing to init, but it still delivers a nice small 2-3KiB initrd) -- Greetings from Oostende (BE) -*- Danny Cautaert (DaCa) Write me in Dutch, French or English * GnuPG preferred Meet me at LinuxTag * 22-25 June 2005 * Karlsruhe (DE) or at DebConf 5 * 10-17 July 2005 * Helsinki (FI) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: And now for something completely different... etch!
On Saturday 11 June 2005 08:34 am, David Weinehall wrote: 2.6.25?! The current release pace for the 2.6-kernel is somewhere along 2-3 months / kernel. The kernel version now is 2.6.11, but 2.6.12 is out any day now, hopefully. Unless there are some radical changes, there won't be more than 6-8 new kernels released 18 months from now. So we're more looking at 2.6.20. Yes, and how overdue was Sarge? I think it's laughable to say what will happen. 2.6.25 may be a conservative estimate. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: And now for something completely different... etch!
I demand that Marco d'Itri may or may not have written... On Jun 12, Frans Pop [EMAIL PROTECTED] wrote: I have a very nice Pentium I (my internet gateway) that has a broken CD-drive and no USB (and certainly wouldn't boot from USB even if it had) but that installs perfectly from floppy. You said it: it's *broken*. Expecting to support some old hardware is OK, expecting to support old and broken hardware is not. In that case, replace the CD-ROM drive. ;-) There are also other platforms that only do floppy boots (older macs, probably m68k too). Looks like they should use floppy + netboot then. An install on a Risc PC can be done without any removable installation media, although it's possible that the newer or less common Ethernet cards aren't supported. -- | Darren Salt | linux (or ds) at | nr. Ashington, | sarge,| youmustbejoking | Northumberland | RISC OS | demon co uk | Toon Army | URL:http://www.youmustbejoking.demon.co.uk/ (PGP 2.6, GPG keys) Oh my! Another kludge! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: And now for something completely different... etch!
I demand that Andreas Gredler may or may not have written... On Thu, Jun 09, 2005 at 07:58:11PM -0400, Joey Hess wrote: [snip] Since d-i currently puts the initrd that reads the second floppy (or other USB media) on the boot floppy with the kernel, we either have to shoehorn that initrd, which is currently 644k, onto the same floppy, reducing its size by 414k somehow. I have to take a look at the initrd. 414k sounds much to me :-( ISTM that a non-standard disk format (21 sectors per track and/or more tracks) would help - or would this just cause too many problems? [snip] -- | Darren Salt | nr. Ashington, | linux (or ds) at | sarge,| Northumberland | youmustbejoking | RISC OS | Toon Army | demon co uk | Say NO to software patents Academy: A modern school where football is taught. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: And now for something completely different... etch!
On Thu, Jun 09, 2005 at 09:25:22AM +1000, Matthew Palmer wrote: On Thu, Jun 09, 2005 at 01:13:16AM +0200, Javier Fernández-Sanguino Peña wrote: to find their own (sometimes flawed) solution to a very common problem. Years using Linux: 10. Times I've absolutely needed an X-less boot when an XDM was installed: 0. How common was that problem you were trying to solve, again? Years using linux: 11 (argh, or 12, i cannot even remember) Times I needed the above discussed feature: several. That common is common enough? -- Jesus Climent info:www.pumuki.org Unix SysAdm|Linux User #66350|Debian Developer|2.6.10|Helsinki Finland GPG: 1024D/86946D69 BB64 2339 1CAA 7064 E429 7E18 66FC 1D7F 8694 6D69 Problem? I haven't got a problem. I've got fucking problems. Plural. --Ted the Bellhop (Four Rooms) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: And now for something completely different... etch!
On Thu, Jun 09, 2005 at 01:18:39PM +0200, Josselin Mouette wrote: How would these runlevels be wasted? We're only talking about the default configuration, not about something a system administrator couldn't change. Exactly my point, what impedes an admin to set some defaults wether the system comes as it comes now or with some predefined options and settings? -- Jesus Climent info:www.pumuki.org Unix SysAdm|Linux User #66350|Debian Developer|2.6.10|Helsinki Finland GPG: 1024D/86946D69 BB64 2339 1CAA 7064 E429 7E18 66FC 1D7F 8694 6D69 This is ridiculous. It's crazy. I feel like I'm babysitting, except I'm not getting paid. --Stef (The Goonies) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: And now for something completely different... etch!
Jesus Climent writes: Exactly my point, what impedes an admin to set some defaults wether the system comes as it comes now or with some predefined options and settings? Nothing, except for the fact that most admins haven't the foggiest idea how to do that. Thus the suggestion that the default runlevels be what most people expect them to be. And it _does_ come with predefined options and settings: ones unique to Debian. -- John Hasler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: And now for something completely different... etch!
On Tuesday 14 June 2005 02:32, Darren Salt [EMAIL PROTECTED] wrote: ISTM that a non-standard disk format (21 sectors per track and/or more tracks) would help - or would this just cause too many problems? AFAIK it's not possible for the BIOS to boot from a 21 sector track. I have heard of people formatting track 0 as 18 sectors and giving it the code needed to switch to 21 sector mode for the other tracks. It's an ugly hack and difficult to produce. For floppy disks to be widely usable we want them to be writable on random machines. In the past I've used Windows, DOS, and OS/2 machines to write Linux disks. A disk with different numbers of sectors on different tracks would probably only be writable on Linux. 21 sector track disks can be written on DOS and used to be writable on Windows (not sure how they work with NT). Having an initial disk in 18 sector mode that then loads from 21 sector disks might be viable. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: And now for something completely different... etch!
Andreas Gredler [EMAIL PROTECTED] writes: On Thu, Jun 09, 2005 at 07:58:11PM -0400, Joey Hess wrote: Andreas Gredler wrote: Is there a way to handle this? Could a kernel be patched to read data from multiple floppy disks? I know that this question sounds a little bit stupid, but floppies still seem to be the most reliable way to boot. [EMAIL PROTECTED]:/bootls -l vmlinuz-2.6.11-1-386 -rw-r--r-- 1 root root 1170465 May 20 04:54 vmlinuz-2.6.11-1-386 Since d-i currently puts the initrd that reads the second floppy (or other USB media) on the boot floppy with the kernel, we either have to shoehorn that initrd, which is currently 644k, onto the same floppy, reducing its size by 414k somehow. I have to take a look at the initrd. 414k sounds much to me :-( Intermittendly we had a multi floppy setup. The first floppy contains the kernel and a minimal initrd. That prompts for the second floppy and the user to press return and then adds the contents of the 2nd floppy to tmpfs. There was just one problem with it: The floppy was to small to include usb keyboard support. The best way to make multi floppy boot work would be to use initramfs with a static C binary linked against klibc that does the prompting and loading of the 2nd/3rd/... floppy. That way you can save as much space as possible for kernel and modules (or similar with initrd for 2.4.x). MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: And now for something completely different... etch!
#include hallo.h * Joey Hess [Thu, Jun 09 2005, 07:58:11PM]: Andreas Gredler wrote: Is there a way to handle this? Could a kernel be patched to read data from multiple floppy disks? I know that this question sounds a little bit stupid, but floppies still seem to be the most reliable way to boot. [EMAIL PROTECTED]:/bootls -l vmlinuz-2.6.11-1-386 -rw-r--r-- 1 root root 1170465 May 20 04:54 vmlinuz-2.6.11-1-386 ... Or we could make make some compromise, such as using the kernel initrd loader to load the initrd from a second floppy, which might cause problems for USB floppy installs (does the kernel initrd loader support usb floppies?) and would break the floppy+usb stick install path. It would also add yet another floppy to the install, probably. These problems (kernel too large, post-loading initrd from non-floppy media not reliable) has been existing even with b-fs three years ago. The best idea in those days came IIRC from Herbert, suggesting to modify the boot loader (syslinux) in order to preload the initrd while beeing in BIOS mode, having access to all devices it provides. It looks a bit unusual if the initrd is to be loaded before the kernel floppy, but it could work, IMO. Regards, Eduard. signature.asc Description: Digital signature
Re: And now for something completely different... etch!
Eduard Bloch [EMAIL PROTECTED] writes: #include hallo.h * Joey Hess [Thu, Jun 09 2005, 07:58:11PM]: Andreas Gredler wrote: Is there a way to handle this? Could a kernel be patched to read data from multiple floppy disks? I know that this question sounds a little bit stupid, but floppies still seem to be the most reliable way to boot. [EMAIL PROTECTED]:/bootls -l vmlinuz-2.6.11-1-386 -rw-r--r-- 1 root root 1170465 May 20 04:54 vmlinuz-2.6.11-1-386 ... Or we could make make some compromise, such as using the kernel initrd loader to load the initrd from a second floppy, which might cause problems for USB floppy installs (does the kernel initrd loader support usb floppies?) and would break the floppy+usb stick install path. It would also add yet another floppy to the install, probably. These problems (kernel too large, post-loading initrd from non-floppy media not reliable) has been existing even with b-fs three years ago. The best idea in those days came IIRC from Herbert, suggesting to modify the boot loader (syslinux) in order to preload the initrd while beeing in BIOS mode, having access to all devices it provides. It looks a bit unusual if the initrd is to be loaded before the kernel floppy, but it could work, IMO. Regards, Eduard. Why would it have to be before the kernel? Actualy all floppies should contain the bootloader and any order should work. Let the bootloader sort the chunks into the right place. The extra code needed for this is minimal. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: And now for something completely different... etch!
El Domingo 12 Junio 2005 01:24, Russell Coker escribió: On Tuesday 07 June 2005 19:31, Cesar Martinez Izquierdo [EMAIL PROTECTED] wrote: What about switching from getty to mingetty? Is there any reason to use getty by default? Is there any reason to change? Well, I'm not very well informed about the subject, but some time ago I run in problems with getty freezing. Then I discovered mingetty, which claims to be small, efficient. I also discovered that getty has some code to allow dial in our computer, which most of the people don't use nowadays and it makes getty more complex than required. Then I switched to mingetty and I never had problems with it. I sold my old hardware before the bug in getty got fixed. Now it seems that the problem is fixed (according to DBTS), but anyway I think that it is not a bad idea to switch to the simpler, smaller program that just-do-the-work. I think that the users that need a different *getty program have very specific needs and they know how to swich form mingetty to *getty (and anyway maybe they don't use getty but mgetty). On the other hand, I see that the memory usage diferences between getty and mingetty are really small, so maybe the change is not worthy... Regards, César
Re: And now for something completely different... etch!
Moin Goswin! Goswin von Brederlow schrieb am Sonntag, den 12. Juni 2005: Why would it have to be before the kernel? Actualy all floppies should Because you can do it before the kernel needs to be running (including the whole userspace overhead needed to prompt the user to insert the usb floppy, for example, and work with it). contain the bootloader and any order should work. Let the bootloader sort the chunks into the right place. The extra code needed for this is minimal. Aha. Then do it, thank you. Regards, Eduard. -- Delenn: We are star stuff. We are the universe made manifest trying to figure itself out. -- Quotes from Babylon 5 -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Why apt-get is not a proper software search engine (was Re: And now for something completely different... etch!)
[Christian Aichinger] The reverse dependency count just isn't a very good metric for is an end-user package. I think it's also a job for debtags or something like it, to tell us what is an end-user package and what isn't. Or popularity-contest could be enhanced to note auto-installed packages. Now that aptitude is gaining traction (particularly in command-line mode - I guess people have been using it in full-screen mode for awhile), the aptitude auto-install flag probably actually means something for a good % of popcon participants. Come to think of it, that's a good wishlist bug for popcon anyway. signature.asc Description: Digital signature
Re: And now for something completely different... etch!
* Brian May | klibc? Not yet in Debian, is there any reason for this? It's just been ITP-ed; http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=312563 -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: And now for something completely different... etch!
Eduard Bloch wrote: Why would it have to be before the kernel? Actualy all floppies should Because you can do it before the kernel needs to be running (including the whole userspace overhead needed to prompt the user to insert the usb floppy, for example, and work with it). FWIW, the NetBSD bootloader supports something like this. The default install kernel comes to around 2.7mb. The bootloader reads the kernel and mfs image containing the installer off a couple of floppy discs (which don't contain normal filesystems but instead some kind of multi-volume tar archive for extra perversity). Cameron. signature.asc Description: Digital signature
Re: And now for something completely different... etch!
On Sunday 12 June 2005 19:54, Cesar Martinez Izquierdo [EMAIL PROTECTED] wrote: El Domingo 12 Junio 2005 01:24, Russell Coker escribió: wrote: What about switching from getty to mingetty? Is there any reason to use getty by default? Is there any reason to change? Then I discovered mingetty, which claims to be small, efficient. I also discovered that getty has some code to allow dial in our computer, which most of the people don't use nowadays and it makes getty more complex than required. -rwxr-xr-x 1 root root 12904 Mar 3 00:13 /sbin/mingetty -rwxr-xr-x 1 root root 14264 Mar 23 01:21 /sbin/getty 1360 bytes difference. Also note that both file sizes are between 12K and 16K in size. On a ReiserFS file system with tails enabled this may actually save some disk space. On an ext2/3 file system it won't make any difference to disk space. Memory is also allocated in 4K chunks so it's unlikely to make any difference to memory use. Then I switched to mingetty and I never had problems with it. I sold my old hardware before the bug in getty got fixed. Now it seems that the problem is fixed (according to DBTS), but anyway I think that it is not a bad idea to switch to the simpler, smaller program that just-do-the-work. I think that the users that need a different *getty program have very specific needs and they know how to swich form mingetty to *getty (and anyway maybe they don't use getty but mgetty). The problem is that a change is likely to cause problems for some people. Without any clear benefit it's probably not worth the bother. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page
Re: And now for something completely different... etch!
On Sun, Jun 12, 2005 at 02:17:08PM +1000, Russell Coker wrote: On Sunday 12 June 2005 09:14, Frans Pop [EMAIL PROTECTED] wrote: Some older BIOSes don't allow booting from CD-ROM, let alone netbooting or It's easy to solve the problem of a BIOS that doesn't support booting from CD-ROM. You have a boot loader on a floppy disk that loads the kernel and initrd from CD. This is of course a good workaround. But this floppies have to be available. Does debian have such floppies? People who have really old hardware should ask at their local LUG if someone has any unused computers that they don't need. I've offered quite a few old computers for free to members of my LUG. Recently I offered a P3-800 machine with broken PSU and a Pentium 200 machine that was fully operational and found no-one who wanted them. It seems that at my LUG there's no-one who has lesser hardware. I've seen a lot of servers for small companies, which are older ;-( greets Jimmy -- Andreas Jimmy Gredler ,'`. http://www.g-tec.co.at/ | [EMAIL PROTECTED] ( grml.org -» Linux for texttool-users and sysadmins `._, http://www.grml.org/| [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: And now for something completely different... etch!
On Sun, Jun 12, 2005 at 12:52:58AM +0200, Marco d'Itri wrote: On Jun 12, Russell Coker [EMAIL PROTECTED] wrote: Why not use a USB flash device for booting? All the recent machines I've tried have booted from a 64M USB device which gives plenty of space for such things. Older machines would be restricted to booting from CD-ROM. Agreed. While it would take me some work to find a working blank floppy to copy something on, it would be much faster for me to boot from the network, USB flash drive or CD (in this order). - Network boot: PXE cards in older HW are as rare as motherboards booting from USB, IMO. - USB: Even my notebook (about 3 years old) is too stupid to boot from USB - CD-ROM: Often had a problem with SCSI cards with old BIOS But I agree, that it's hard to find working floppies and I'd be happy when I'd could throw away all floppy disks and drives. But unfortunately I sometimes really need them. greets Jimmy -- Andreas Jimmy Gredler ,'`. http://www.g-tec.co.at/ | [EMAIL PROTECTED] ( grml.org -» Linux for texttool-users and sysadmins `._, http://www.grml.org/| [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: And now for something completely different... etch!
* Andreas Gredler | - Network boot: PXE cards in older HW are as rare as motherboards | booting from USB, IMO. A new PXE-capable networking card costs in the range of 20 and should work on most machines. -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `-
Re: And now for something completely different... etch!
Matthew == Matthew Palmer [EMAIL PROTECTED] writes: Add to the list of daemon related features the not start daemons by default and wait for the admin to define which ones to start from /etc/defaults or whatever. Matthew Jesus, meet policy-rc.d. Not all packages use/support this. Most recent example I have personally identified is udev (when creating a Debian system using a script in a chroot, the script couldn't unmount the partition when it was finished, because udev was running and had mounted additional filesystems - the only solution I could come up with was to stop the daemon in the chroot before unmounting the file-system). -- Brian May [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: And now for something completely different... etch!
Grzegorz == Grzegorz B Prokopski [EMAIL PROTECTED] writes: Grzegorz On Tue, 2005-07-06 at 01:03 +0200, Javier Grzegorz Fernández-Sanguino Peña wrote: [ Installation improvements ] - Firewall configuration during installation (ala Fedora Core or SuSE): module for d-i. Currently, the system is exposed just during installation on some systems (empty root password?) Grzegorz Right. Especially for workstation installation Grzegorz something like below would allow to connect from Grzegorz workstation to anywhere else, but not to any servers ran Grzegorz on workstation. I would suggest shorewall with a very simple default configuration. IMHO, shorewall seems to be easy to use and configure, and can be used in very simple single computer setups to very complicated networks. The difficulty with supporting firewalls is that people will expect if I install package X, then it should automatically adjust the firewall to allow it to work. I really do *not* want to go down this path. The firewall is up to the administrator to decide on, not the package maintainers. -- Brian May [EMAIL PROTECTED]
Re: And now for something completely different... etch!
On Jun 11, Brian May [EMAIL PROTECTED] wrote: Not all packages use/support this. Then they should be fixed. Udev has good reasons to work differently, and the chroot case was fixed a long time ago. -- ciao, Marco signature.asc Description: Digital signature
Re: And now for something completely different... etch!
On Fri, Jun 10, 2005 at 12:20:14AM +0200, Giuseppe Sacco wrote: Il giorno gio, 09-06-2005 alle 19:06 +0200, Frans Pop ha scritto: On Thursday 09 June 2005 18:45, Marco d'Itri wrote: On Jun 09, Adrian von Bidder [EMAIL PROTECTED] wrote: Dropping 2.4 can easily be done on relatively short notice prior to etch release, so no need to worry about now. It would be too late, because at that time we would have wasted a couple of years trying to support them. This kind of decision should be taken early in the development cycle. Making the decision early would also help d-i development as we could then start cleaning e.g. keyboard selection (and console-data). Being able to rely on sysfs being present would also simplify hardware detection in some cases. Right, this would really simplify d-i development. My personal opinion is that 2.6.8 isn't enought mature to be used on server installation with multidisk, lvm and XFS. But, when Etch will be released, we will probably have 2.6.25 or such available. I think, in this case, 2.6 could really be offered as a complete replacement for 2.4. 2.6.25?! The current release pace for the 2.6-kernel is somewhere along 2-3 months / kernel. The kernel version now is 2.6.11, but 2.6.12 is out any day now, hopefully. Unless there are some radical changes, there won't be more than 6-8 new kernels released 18 months from now. So we're more looking at 2.6.20. I totally agree about goes 2.6.xx full out, however. 2.6.11 is already pretty stable, 2.6.12 promise to be even more so. Regards: David Weinehall -- /) David Weinehall [EMAIL PROTECTED] /) Rime on my window (\ // ~ // Diamond-white roses of fire // \) http://www.acc.umu.se/~tao/(/ Beautiful hoar-frost (/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: And now for something completely different... etch!
On Thu, Jun 09, 2005 at 07:58:11PM -0400, Joey Hess wrote: Andreas Gredler wrote: Is there a way to handle this? Could a kernel be patched to read data from multiple floppy disks? I know that this question sounds a little bit stupid, but floppies still seem to be the most reliable way to boot. [EMAIL PROTECTED]:/bootls -l vmlinuz-2.6.11-1-386 -rw-r--r-- 1 root root 1170465 May 20 04:54 vmlinuz-2.6.11-1-386 Since d-i currently puts the initrd that reads the second floppy (or other USB media) on the boot floppy with the kernel, we either have to shoehorn that initrd, which is currently 644k, onto the same floppy, reducing its size by 414k somehow. I have to take a look at the initrd. 414k sounds much to me :-( uclibc is one possibility, but 409-some kilobytes of that 644k are used for kernel modules and other stuff that uclibc wouldn't effect (much); only 235k is used for libc currently, and I fear those numbers don't add up to uclibc making it small enough, unless uclibc occupys only 5k of the compressed disk. Maybe other changes, like using initramfs for that image, a little kernel hacking to remove a few modules that are barely used (like ide-core which is on there for only 1 symbol on 2.4; didn't check 2.6), and so on might just make it work. Removing kernel modules might work for 2.6 but I'm afraid that the kernel will still grow and we will sometimes end up with a kernel, which will never fit on a floppy disk again. But maybe I'm too pessimistic ;-) (But maybe there won't be any motherboards left, that aren't able to boot from USB) Or we could make make some compromise, such as using the kernel initrd loader to load the initrd from a second floppy, which might cause problems for USB floppy installs (does the kernel initrd loader support usb floppies?) and would break the floppy+usb stick install path. It would also add yet another floppy to the install, probably. I think one more floppy would be ok, if initrd loader is able to load the initrd from usb floppies or anything else. IMO the first boot media is always the most problematic one. Maybe I can't boot from USB, but I can boot from floppy and then read data (like initrd) from a usb-device. greets Jimmy -- Andreas Jimmy Gredler ,'`. http://www.g-tec.co.at/ | [EMAIL PROTECTED] ( grml.org -» Linux for texttool-users and sysadmins `._, http://www.grml.org/| [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: And now for something completely different... etch!
Hi, On Tuesday, 07 Jun 2005, you wrote: Feel free to add some new items or add (hopefully new) information to the ones I list below: - A lot of programms use tcpwrapper which I appreciate a lot. However, it is quite often not too easy to find out what to write in hosts.allow to allow access to exactly that program. Frankly speaking, having that information always in the manpage seems a good idea to me. (i would like to see that as recommondation for packages in etch) - IPv6 Readyness packages in etch should be able to handle IPv6. There are still a bunch of packages which are not able to handle IPv6. - packages in base or packages up to priority standard must not use savelog. There is at least one package in base i know off which uses savelog to rotate logfiles. Using logrotate is a more save way, as it gives the user the possibility to configure more easyly when logfiles are rotated. I would like to see 5(j) of etch release-policy adjusted or best, to say, all packages must use logrotate. Greetings Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: And now for something completely different... etch!
On Friday 10 June 2005 09:58, Joey Hess [EMAIL PROTECTED] wrote: Since d-i currently puts the initrd that reads the second floppy (or other USB media) on the boot floppy with the kernel, we either have to shoehorn that initrd, which is currently 644k, onto the same floppy, reducing its size by 414k somehow. Why not use a USB flash device for booting? All the recent machines I've tried have booted from a 64M USB device which gives plenty of space for such things. Older machines would be restricted to booting from CD-ROM. A combination of USB flash storage for the rare new machines that don't have CD/DVD drives and CD-ROM for older machines will cater for the vast majority of machines that are out there. New laptops tend to ship without floppy drives and desktop machines will surely follow soon. Plans for future hardware support should not involve floppy disks. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: And now for something completely different... etch!
On Tuesday 07 June 2005 19:31, Cesar Martinez Izquierdo [EMAIL PROTECTED] wrote: What about switching from getty to mingetty? Is there any reason to use getty by default? Is there any reason to change? -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: And now for something completely different... etch!
On Tuesday 07 June 2005 19:12, Wouter Verhelst [EMAIL PROTECTED] wrote: On Tue, Jun 07, 2005 at 01:47:12AM +0200, Marco d'Itri wrote: On Jun 07, Javier Fernández-Sanguino Peña [EMAIL PROTECTED] wrote: - _No_ bugs in base packages (well, at least no old bugs). Base system should be upgraded to latest upstream (forward patches!) this includes PAM, modutils... In my wishlist there is NO support of 2.4 kernels, so modutils would become unneeded. 2.4.x kernels are already obsolete by now except that for some doorstop architectures, I do not know about any other modern distribution which still installs one. Since (at least) potato, Debian has always supported more than one major line of kernels. I don't see why we suddenly would need to change that now. For architectures that require older kernels we can keep them. But for i386 and other platforms that work well on 2.6.x we should not support older kernels. Some features that are planned for Etch such as SE Linux require a 2.6.x kernel. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page
Re: And now for something completely different... etch!
On Sunday 12 June 2005 00:24, Russell Coker wrote: New laptops tend to ship without floppy drives and desktop machines will surely follow soon. Plans for future hardware support should not involve floppy disks. Please, we do not only support new hardware. I have a very nice Pentium I (my internet gateway) that has a broken CD-drive and no USB (and certainly wouldn't boot from USB even if it had) but that installs perfectly from floppy. There are also other platforms that only do floppy boots (older macs, probably m68k too). IMO we should try very hard to keep floppy installation supported. pgpEme5MM7QKV.pgp Description: PGP signature
Re: And now for something completely different... etch!
On Jun 12, Russell Coker [EMAIL PROTECTED] wrote: Why not use a USB flash device for booting? All the recent machines I've tried have booted from a 64M USB device which gives plenty of space for such things. Older machines would be restricted to booting from CD-ROM. Agreed. While it would take me some work to find a working blank floppy to copy something on, it would be much faster for me to boot from the network, USB flash drive or CD (in this order). -- ciao, Marco signature.asc Description: Digital signature
Re: And now for something completely different... etch!
On Jun 12, Frans Pop [EMAIL PROTECTED] wrote: I have a very nice Pentium I (my internet gateway) that has a broken CD-drive and no USB (and certainly wouldn't boot from USB even if it had) but that installs perfectly from floppy. You said it: it's *broken*. Expecting to support some old hardware is OK, expecting to support old and broken hardware is not. There are also other platforms that only do floppy boots (older macs, probably m68k too). Looks like they should use floppy + netboot then. -- ciao, Marco signature.asc Description: Digital signature
Re: And now for something completely different... etch!
On Sunday 12 June 2005 00:51, Marco d'Itri wrote: On Jun 12, Frans Pop [EMAIL PROTECTED] wrote: I have a very nice Pentium I (my internet gateway) that has a broken CD-drive and no USB (and certainly wouldn't boot from USB even if it had) but that installs perfectly from floppy. You said it: it's *broken*. Pardon my French, but that's bullshit. The system is perfectly fine. Since when is a CD drive an essential component. Since never! Expecting to support some old hardware is OK, expecting to support old and broken hardware is not. Some older BIOSes don't allow booting from CD-ROM, let alone netbooting or booting from USB. Are we going to be like M$ and force users to buy the latest and greatest hardware to run Debian? I hope not if it can be avoided with a little bit of extra effort. As long as the kernel supports it, we should try to allow people to install Debian on it. For me, it's one of the attractions of Open Source. pgpciJI6k5JLo.pgp Description: PGP signature
Re: And now for something completely different... etch!
Joey == Joey Hess [EMAIL PROTECTED] writes: Joey Since d-i currently puts the initrd that reads the second Joey floppy (or other USB media) on the boot floppy with the Joey kernel, we either have to shoehorn that initrd, which is Joey currently 644k, onto the same floppy, reducing its size by Joey 414k somehow. I suggest having a look at yaird. URL:http://www.xs4all.nl/~ekonijn/yaird/yaird.html Downloads at URL:http://www.xs4all.nl/~ekonijn/yaird/ Yaird appears to be newer and better then mkinitrd, and may help lower the size of the image. Also, it uses initramfs/cpio, supports both Debian and Fedora, looks like it would be easy to customize, etc. I am not sure it is appropriate to use yaird for d-i, I haven't investigated this in depth. Even if it is not suitable out of the box, I suspect it should be possible to customize it so that it is suitable. On my system (using standard libc6), there is a huge difference in size: [521] [snoopy:bam] ~ ls -l /tmp/test.img /boot/initrd.img-2.6.8-2-k7 -rw-r--r-- 1 root root 4648960 Jun 5 12:49 /boot/initrd.img-2.6.8-2-k7 -rw--- 1 root root 1107666 Jun 12 09:00 /tmp/test.img By default, only essential files (+jbd!!!) are copied (my system is IDE RAID using ext3): [520] [snoopy:bam] ~ sudo zcat /tmp/test.img | cpio --list . bin bin/cat bin/dash bin/mkdir bin/mknod bin/mount bin/sleep bin/umount dev dev/console dev/null etc home home/bam home/bam/local home/bam/local/lib home/bam/local/lib/yaird home/bam/local/lib/yaird/exec home/bam/local/lib/yaird/exec/run_init lib lib/modules lib/modules/2.6.8-2-k7 lib/modules/2.6.8-2-k7/kernel lib/modules/2.6.8-2-k7/kernel/drivers lib/modules/2.6.8-2-k7/kernel/drivers/ide lib/modules/2.6.8-2-k7/kernel/drivers/ide/pci lib/modules/2.6.8-2-k7/kernel/drivers/ide/pci/via82cxxx.ko lib/modules/2.6.8-2-k7/kernel/drivers/ide/ide-core.ko lib/modules/2.6.8-2-k7/kernel/drivers/ide/ide-disk.ko lib/modules/2.6.8-2-k7/kernel/drivers/ide/ide-generic.ko lib/modules/2.6.8-2-k7/kernel/drivers/md lib/modules/2.6.8-2-k7/kernel/drivers/md/md.ko lib/modules/2.6.8-2-k7/kernel/drivers/md/raid1.ko lib/modules/2.6.8-2-k7/kernel/fs lib/modules/2.6.8-2-k7/kernel/fs/ext3 lib/modules/2.6.8-2-k7/kernel/fs/ext3/ext3.ko lib/modules/2.6.8-2-k7/kernel/fs/jbd lib/modules/2.6.8-2-k7/kernel/fs/jbd/jbd.ko lib/modules/2.6.8-2-k7/kernel/fs/mbcache.ko lib/tls lib/tls/libc-2.3.2.so lib/tls/libm-2.3.2.so lib/tls/libpthread-0.60.so lib/tls/librt-2.3.2.so lib/tls/libc.so.6 lib/tls/libm.so.6 lib/tls/libpthread.so.0 lib/tls/librt.so.1 lib/ld-2.3.2.so lib/libblkid.so.1.0 lib/libuuid.so.1.2 lib/ld-linux.so.2 lib/libblkid.so.1 lib/libuuid.so.1 mnt proc sbin sbin/insmod sbin/mdadm sys var init 4926 blocks No doubt this would be even more with klibc. The only downside I see is that it is still being developed, and considered incomplete at the moment. Also, it is not in Debian. I have not yet tested i for booting. Joey uclibc is one possibility, but 409-some kilobytes of that Joey 644k are used for kernel modules and other stuff that uclibc Joey wouldn't effect (much); only 235k is used for libc Joey currently, and I fear those numbers don't add up to uclibc Joey making it small enough, unless uclibc occupys only 5k of the Joey compressed disk. Maybe other changes, like using initramfs Joey for that image, a little kernel hacking to remove a few Joey modules that are barely used (like ide-core which is on Joey there for only 1 symbol on 2.4; didn't check 2.6), and so on Joey might just make it work. klibc? Not yet in Debian, is there any reason for this? -- Brian May [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: And now for something completely different... etch!
Brian May wrote: Yaird appears to be newer and better then mkinitrd d-i images are not created with mkinitrd. -- see shy jo signature.asc Description: Digital signature
Re: And now for something completely different... etch!
On Sunday 12 June 2005 08:38, Frans Pop [EMAIL PROTECTED] wrote: On Sunday 12 June 2005 00:24, Russell Coker wrote: New laptops tend to ship without floppy drives and desktop machines will surely follow soon. Plans for future hardware support should not involve floppy disks. Please, we do not only support new hardware. I have a very nice Pentium I (my internet gateway) that has a broken CD-drive and no USB (and certainly wouldn't boot from USB even if it had) but that installs perfectly from floppy. I have a couple of very nice Cobalt machines that have no option for booting from removable media. I installed Debian on them by removing the hard disks and using a desktop machine to do the install. The same method would work for broken hardware such as you possess. There are also other platforms that only do floppy boots (older macs, probably m68k too). It seems that M68K Macs will be different from all other supported machines in every way. There's no reason to upgrade the Debian install process on those machines. IMO we should try very hard to keep floppy installation supported. There's nothing stopping someone who has ancient hardware from installing Woody or Sarge and then upgrading. There's no reason for us not to require that the installer only support hardware that is 10 years old and fully functional. Incidentally the going price for CD-ROM drives is $10 or less. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: And now for something completely different... etch!
On Sunday 12 June 2005 09:14, Frans Pop [EMAIL PROTECTED] wrote: Some older BIOSes don't allow booting from CD-ROM, let alone netbooting or It's easy to solve the problem of a BIOS that doesn't support booting from CD-ROM. You have a boot loader on a floppy disk that loads the kernel and initrd from CD. I hope not if it can be avoided with a little bit of extra effort. As long as the kernel supports it, we should try to allow people to install Debian on it. For me, it's one of the attractions of Open Source. Supporting old kernels also takes time, not only from the people who maintain the kernels but from people who maintain applications that depend on kernel functionality. People who have really old hardware should ask at their local LUG if someone has any unused computers that they don't need. I've offered quite a few old computers for free to members of my LUG. Recently I offered a P3-800 machine with broken PSU and a Pentium 200 machine that was fully operational and found no-one who wanted them. It seems that at my LUG there's no-one who has lesser hardware. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: And now for something completely different... etch!
Le jeudi 09 juin 2005 à 18:03 +0200, Wouter Verhelst a écrit : How would these runlevels be wasted? We're only talking about the default configuration, not about something a system administrator couldn't change. In theory. In practice, many third-party applications will make assumptions about the availability and configuration of runlevels, and will break horribly if anything is different from what they expect; this has happened on those RedHat systems that I've tried this on. If they already exist, they're likely to check for a Debian system, and to make Debian-specific assumptions about the runlevel configuration, so the problem is the same. Furthermore, I don't think basing our decisions on what broken, third-party software can do is a good idea. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom
Re: And now for something completely different... etch!
Darren Salt [EMAIL PROTECTED] writes: I demand that Rich Walker may or may not have written... Matthew Palmer [EMAIL PROTECTED] writes: How common was that problem you were trying to solve, again? Presumably, you never used an S3 video card. (Locks up on leaving X in many card/X permutations). IME (one S3 ViRGE), that's VESA driver territory. (No lockup problems, though - at least, not that I recall...) Specifically, it was using Xserver-s3v rather than X 4. If you left X, the machine became un-usable: I recall having to connect over the network to shut it down, and having to document how to do that for the customer. I know; I should have used a different card: but there were deadlines involved... cheers, Rich. -- rich walker | Shadow Robot Company | [EMAIL PROTECTED] technical director 251 Liverpool Road | need a Hand? London N1 1LX | +UK 20 7700 2487 www.shadow.org.uk/products/newhand.shtml -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: And now for something completely different... etch!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Adrian von Bidder [EMAIL PROTECTED] writes: On Tuesday 07 June 2005 23.32, Roger Leigh wrote: Frans Pop [EMAIL PROTECTED] writes: On Tuesday 07 June 2005 23:02, Roger Leigh wrote: Existing installs are already configured with debconf. Their /etc/locale.gen will not be touched. If you do dpkg-reconfigure locales, then users could have the locale switch to UTF-8 if they so choose. AFAIK locales are automatically regenerated when the locales package is upgraded, so this _would_ effect every existing install directly on upgrade to the new release. locale-gen is run, but /etc/locale.gen is not necessarily altered. If you don't change it, it will regenerate the same locales you already have. But 'the same locale I already have' would probably mean 'the locale with the name of the locale I previously had' which has now suddenly changed its behaviour. This would be safe, since the locale codeset is part of the name. When the current locale selections are merged with i18n/SUPPORTED, it wouldn't change anything behind your back. But this is probably the wrong approach, as others have said. I've since made a patch, and filed this as bug #312927. I'd appreciate any comments. It's a trivial and (I hope!) non-controversial change. It certainly won't affect the choices of or the behaviour of the available locales; it rather just recommends that UTF-8 locales be used unless the user has a good reason not to. Regards, Roger - -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ Debian GNU/Linuxhttp://www.debian.org/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 http://mailcrypt.sourceforge.net/ iD8DBQFCqgNnVcFcaSW/uEgRAjXFAKCL4YoHDw9OI4mhs/LnQ9pjZK0ucACbB4Ch vFjugEqBcVCNMlTVoMRV4cU= =usOo -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: And now for something completely different... etch!
Again, do not mess with cultures you do not understand. Do you have real examples? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: And now for something completely different... etch!
* Christian Perrier | Again, do not mess with cultures you do not understand. | | Do you have real examples? IRC. An example is the current irssi in Debian which doesn't do recoding between different locales. (And that is needed, since IRC doesn't have a charset concept and there are still loads and loads of users out there with clients which interpret everything as Latin1.) -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: And now for something completely different... etch!
9.06.2005 pisze Tollef Fog Heen ([EMAIL PROTECTED]): | Again, do not mess with cultures you do not understand. | Do you have real examples? IRC. An example is the current irssi in Debian which doesn't do recoding between different locales. (And that is needed, since IRC doesn't have a charset concept and there are still loads and loads of users out there with clients which interpret everything as Latin1.) s/Latin1/any 8-bit encoding from the iso-8859-* range/ Jubal -- [ Miros/law L Baran, baran-at-knm-org-pl, neg IQ, cert AI ] [ 0101010 is ] [ BOF2510053411, makabra.knm.org.pl/~baran/, alchemy pany ] [ The Answer ] Say the secret word and the duck is yours. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: And now for something completely different... etch!
on Thu, Jun 09, 2005 at 02:30:26AM +0200, Wesley J. Landaker wrote about Re: And now for something completely different... etch!: I don't often customize runlevels very much, but usually the first thing I do when I install a Debian system is remove all the xdm's from 2 and 3 and add them to 5. I switch between those all the time on systems that are The first thing I do after installing xdm is often (not on single workstations) disabling the startup of the X server because the machine running xdm is a central application server i.e. client workstations start X with -query / ... to get a login on the application server. I don't want an X server running on the application server so I change xdm's default configuration. I want to start an X server on the client, so I create a startup script to start the X server in a non conventional way. Currently, the runlevel indicates which things are started and these things can be anything. I consider it a nice and flexible abstraction. The proposal however, indicates that a runlevel would be dedicated to X. In my setup, this would mean that my application server would have to run in this dedicated X runlevel because xdm happens to be started there. However, this machine doesn't run X at all ... It doesn't seem to feel right i.e. the abstraction is polluted with implementation issues. mostly lights servers but sometimes need to become desktops on the fly when an extra warm body shows up. -- Wesley J. Landaker [EMAIL PROTECTED] OpenPGP FP: 4135 2A3B 4726 ACC5 9094 0097 F0A9 8A4C 4CD6 E3D2 -- [EMAIL PROTECTED] Those who do not understand Unix are condemned to reinvent it, poorly. -- Henry Spencer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: And now for something completely different... etch!
On Wed, Jun 08, 2005 at 07:58:32PM +0200, Javier Fernández-Sanguino Peña wrote: On Wed, Jun 08, 2005 at 03:34:26PM +0200, Wouter Verhelst wrote: Nobody. However, you're assuming that xdm et al will keep trying to start an X server, even if it fails. Luckily, the respective initscripts are far more clever than that. I've had a laptop that froze because of X starting up and using the wrong driver to access the card (some of the embedded graphic cards in laptops are really crappy). The only way to fix this was to startup with a rescue CD and preventing xdm from running with an 'exit 0' in its initd script (or by removing its links). At the time, I would have appreciated the opportunity to bootup in a runlevel that wouldn't try to start up the X environment until I had fixed the issue. Now, that is why we have runlevel 1. But in most cases, wasting runlevels to things that could just as easily be fixed by ending the attempts to start is silly. -- The amount of time between slipping on the peel and landing on the pavement is precisely one bananosecond -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
