Re: congratulations to our ftp-master team
Anand Kumria [EMAIL PROTECTED] writes: A simple assurance that your package will be rejected from the NEW queue if no ftp-master approves it within 2 weeks would actually be a benefit. Why? It seems like, if that's the way that you want the world to work, you could already just pretend that this is the case. If your package has gone for more than two weeks, it seems to me like you could decide to treat it in all respects as if it had been rejected and just go on with your life. If it ends up getting accepted, you could orphan it, or decide to pick it up again. -- 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: udev event completion order (was: Re: Debian Installer team monthly meeting minutes (20051214 meeting))
On Dec 18, Darren Salt [EMAIL PROTECTED] wrote: An alternative appears to be to process events in series... or maybe delaying This was the precedent approach, and it's much slower (also, it cannot be implemented anymore with just udevd). -- ciao, Marco signature.asc Description: Digital signature
Re: Debian Installer team monthly meeting minutes (20051214 meeting)
On Saturday 17 December 2005 09.30, Marco d'Itri wrote: On Dec 17, Christian Perrier [EMAIL PROTECTED] wrote: It is currently very likely that systems with two network interfaces will end up with both switched on the installed system after the reboot. This is of course a blocker. This will happen no matter how the system was installed, because modules are loaded concurrently and the first one to finish its setup wins. Arrrgh! I'd say this is extremely critical because - it happens not only when configuration changes, but also between reboots without any changes - most modern PC have more than one interfaces because the firewire interface is detected as a network device, too. - it will render servers in remote locations randomly unaccessible after reboot, and people not familiar with udev will be absolutely stumped as to why even if they get access again after the next reboot... I hope this will be solved soon! cheers -- vbi -- Fang jetzt zu leben an, und z\xE4hle jeden Tag als ein Leben f\xFCr sich. -- Lucius Annaeus Seneca (4-65 n.Chr.) pgp44CIOC6Tf7.pgp Description: PGP signature
Re: Packaging swftools for Debian
On Dec 17, 2005 at 18:48, Simo Kauppi praised the llamas by saying: On Sat, Dec 17, 2005 at 03:21:41PM +0100, Lionel Elie Mamane wrote: No, you have to _remove_ the offending code. Not only disable it at build-time, but not ship it at all, also not in the source. Distributing infringing source code, not only infringing binaries, is an infringement to the patent. (The right mailing list for discussing this particular point is debian-legal@lists.debian.org) Sorry for being a little vague. What I meant was that it uses liblame library by default and that dependency can be disabled at build time. My understanding is that there is no offending code in the swftools itself (at least I haven't noticed any, but I have to double check :) So, by disabling lame, it compiles and runs without users needing to install any non-free software (the liblame library). The only drawback is, that two of its binaries, avi2swf and wav2swf, cannot be used. Since it has many other useful tools, I would like to see a Debian package from it anyway. The obvious solution would be something that ldopened liblame, so a user could install liblame if they wanted and get the functionality that they would have done if it was compiled in now. I believe that would be allowed in Debian, as we wouldn't be distributing anything patent-encumbered. -- David Pashley [EMAIL PROTECTED] Nihil curo de ista tua stulta superstitione. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Please test new sysvinit, sysv-rc, initscripts
On Dec 18, Graham Wilson [EMAIL PROTECTED] wrote: I do not remember a consensus about this. Changes in Debian are generally decided by package maintainers, not by consensus. Good to know. So I'm happy that nobody will complain when I will make udev mandatory. -- ciao, Marco signature.asc Description: Digital signature
Re: congratulations to our ftp-master team
On Sun, Dec 18, 2005 at 04:34:54PM +1100, Anand Kumria wrote: On Wed, Dec 14, 2005 at 09:30:15AM +, David Pashley wrote: On Dec 14, 2005 at 00:25, Anand Kumria praised the llamas by saying: I'd like to congratulate our ftp-master team on their ability to timely process packages progressing through the NEW queue. http://ftp-master.debian.org/new.html [1] I think you are an excellent example of people who are too busy for Debian. I must say that I am particularly impressed that you've managed to frustrate our users for over 1 year with the package 'xvidcap'. Truly the works of Gods among both Debian users _and_ Debian developers. If only more of the infrastructure teams displayed your attitude and dedication to volunteering for the benefit of all Debian users and developers. 2875 + Dec 13 18:17 Debian Installer ( 0) irssi_0.8.10-1_multi.changes is NEW 2876 + Dec 13 23:48 Debian Installer ( 0) irssi_0.8.10-1_multi.changes ACCEPTED 5.5 hours for a package to make it through NEW. I think you owe some people an apology. - 8126 T Oct 25 Debian Installe ( 46) xmovie_1.9.13-0_i386.changes is NEW 10552 T Dec 14 Joerg Jaspert ( 23) xmovie_1.9.13-0_i386.changes REJECTED How many hours is that, David? Yours is a rejection of a problematic package, David's isn't. Is it so strange that ftp-masters try to do a better job than I'm rejecting this, because I'm not entirely sure this is going to be allowed, but I don't have the time to investigate right now and doing so would take longer than 5 hours? -- .../ -/ ---/ .--./ / .--/ .-/ .../ -/ ../ -./ --./ / -.--/ ---/ ..-/ .-./ / -/ ../ --/ ./ / .--/ ../ -/ / / -../ ./ -.-./ ---/ -../ ../ -./ --./ / --/ -.--/ / .../ ../ --./ -./ .-/ -/ ..-/ .-./ ./ .-.-.-/ / --/ ---/ .-./ .../ ./ / ../ .../ / ---/ ..-/ -/ -../ .-/ -/ ./ -../ / -/ ./ -.-./ / -./ ---/ .-../ ---/ --./ -.--/ / .-/ -./ -.--/ .--/ .-/ -.--/ .-.-.-/ / ...-.-/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Checking package builds on hppa/arm/m68k?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Benjamin Mesing wrote: Please (re)check, if the package can be built by g++ 3.4 on [hppa/arm/m68k]? Do I simply remove the explicit build dependency on g++, upload the package and wait if it succeeds (and probably create another package version with the build dependencies re-added again if it still fails)? As Matthias Klose in his announce [1], this workaround is no longer needed (if you are speaking about the issue affecting a lot of QT/KDE My issue was the ICE which occured on these platforms for (also non-Qt/KDE) c++ builds (I think this is not related to the mt_alloc issue): http://lists.debian.org/debian-gcc/2005/11/msg00123.html Since this bug seems to be solved now, and Matthias also said Please (re)check, if the package can be built I was just wondering what the proper way of checking is. Best Regards, Andreas - -- Andreas Fester mailto:[EMAIL PROTECTED] WWW: http://www.littletux.net ICQ: 326674288 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDpTaOZ3bQVzeW+rsRAqssAKCIm2IibmZ+21T0/cOXcnHiExcBRACg86lb g3/efB0Nful/iyDqfD8SMng= =f138 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Please test new sysvinit, sysv-rc, initscripts
[Marco d'Itri] I do not remember a consensus about this. Changes in Debian are generally decided by package maintainers, not by consensus. Good to know. So I'm happy that nobody will complain when I will make udev mandatory. You seem to have mixed up lack of complaints with decision delegation. Perhaps you got other things wrong as well, but it is hard to tell from the little you write. :) You should expect lots of complains if you do something stupid with your packages, and you are also expected to adjust the packages to work as well as possible based on the input and arguments provided to you. And the decision is yours for the packages you maintain, and if you are doing a really bad job the technical committee might overrule your decision. If any of this come as a surprise to you, I suggest you reconsider your maintenence practice. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Please test new sysvinit, sysv-rc, initscripts
On Sun, Dec 18, 2005 at 10:39:53AM +0100, Marco d'Itri wrote: Changes in Debian are generally decided by package maintainers, not by consensus. Good to know. So I'm happy that nobody will complain when I will make udev mandatory. I won't complain, I'll just send a friendly assassin to your house :-) /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
You've Been Added!
This message is to confirm the addition of your email address: debian-devel@lists.debian.org to the Alharamain Sermon(english) Subscribe Me mailing list. If you feel you have received this notice in error, please visit the Alharamain Sermon(english) Subscribe Me mailing list at our website: http://alharamainsermons.org to remove yourself automatically, or click the link below: http://www.alharamainsermons.org/cgi-bin/subscribe/s.pl?r=1l=1[EMAIL PROTECTED] Thank you, Alharamain Sermon(english) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Size matters. Debian binary package stats
Hi I've run some scripts to find out the size of binary pakcages in debian and how theycould be made smaller, here's the results: http://www.linuks.mine.nu/sizematters/ Comments are welcome... Yours, Gürkan
Re: Size matters. Debian binary package stats
On Sun, Dec 18, 2005 at 12:34:56PM +0100, Gürkan Sengün wrote: I've run some scripts to find out the size of binary pakcages in debian and how theycould be made smaller, here's the results: My comments are about the same as on IRC: - Disk space is cheap, bandwidth is cheap. - CPU doesn't grow nearly as fast as those three. - Human power grows even slower. - The administrative overhead of transitioning to a new .deb format would be huge. Thus, anything sacrificing lots of human power and CPU power to save on disk or bandwidth just doesn't make sense. /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Size matters. Debian binary package stats
Gürkan Sengün [EMAIL PROTECTED] wrote: I've run some scripts to find out the size of binary pakcages in debian and how theycould be made smaller, here's the results: http://www.linuks.mine.nu/sizematters/ Afaict from the webpage 7zip (LZMA) is quite a bit slower bzip2. - Have you perhaps run some benchmarks? cu andreas -- The 'Galactic Cleaning' policy undertaken by Emperor Zhark is a personal vision of the emperor's, and its inclusion in this work does not constitute tacit approval by the author or the publisher for any such projects, howsoever undertaken.(c) Jasper Ffforde -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian menu entries(was Re: Debian and the desktop)
On Sat, Dec 17, 2005 at 10:23:54PM -0800, Eduardo Silva wrote: As a lurker to debian-devel, I would like to point to all a deficiency in the current KDE way of naming menus, and hope that if Debian menu goes this way, it should improve on it. The current way KDE names programs is: Type of Program (Application name) So, for amarok it's: Audio Player (amarok) I find this actually bad, because it's almost a new hierachy in the menu (one that Debian menu actually has, I think). On the other hand, if the Gnome way was used, it would be better, since it makes sense in english: Amarok Audio Player Name of the app + program type. But the position of program type should change acording to the language used. When using KDE in portuguese, it actually becomes correct in syntax, although the parentesis () stops making sense: Leitor de ?udio (amarok) So, my sugestion is, if this is done in Debian menu, the position of the application type is moved before or after the application type, according to the language use and without the use of parethesis: English: Amarok Audio Player Portuguese: Leitor de ?udio Amarok Eduardo P.S.-Could you CC: me any replies? I'll also keep an eye on the list archive site, for possible replies. OH MY ... http://www.geocities.com/jobezone/index.html __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] I think that type (name) is how KDE do it. In kcontrol you can change it to Name (description). On my test box GNOME doesn't seem show the type infomation. I have no real views on how Debian should do it, since I change most things to suit me. Pete -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Size matters. Debian binary package stats
2005/12/18, Andreas Metzler [EMAIL PROTECTED]: Gürkan Sengün [EMAIL PROTECTED] wrote: I've run some scripts to find out the size of binary pakcages in debian and how theycould be made smaller, here's the results: http://www.linuks.mine.nu/sizematters/ Afaict from the webpage 7zip (LZMA) is quite a bit slower bzip2. - Have you perhaps run some benchmarks? That page has compression and decompression speeds, putting 7zip at about 40% slower than bzip2 and 90% slower than gzip. The decompression speed of 7zip is better than bzip2 but still nothing to write home about. Anyone know a good heuristic for measuring bang for buck for compression algorithms? Have a nice day, Martijn
Re: /run vs /var/run (was: Please test new sysvinit)
Marco d'Itri wrote: I do not remember a consensus about this. Perhaps the last hold-outs can be convinced this time? :) Bernd Eckenfels wrote: and if it is placed in a tmpfs (which is really the best thing anyway) it doesnt matter under which mountpoint it is located. It does matter, because /run needs to be usable before other filesystems are mounted, and a filesystem can get mounted on /var, thus hiding anything that was stored at /var/run prior to this. One might propose shifting things around, but this quickly gets into race problems. And then it is much cleaner to have only one. Peter Samuelson wrote: Given the need, and now the reality, of /run, is there any need for a separate /var/run? Need is probably too strong, but it's certainly convenient if we don't have to change the way we currently use /var/run/. Steve Langasek wrote: (We also shouldn't need to specify a policy for mounting any particular filesystem on /run, but merely mount /run early iff it's present in /etc/fstab and leave the implementation details to the local admin.) I think that packages Depending on initscripts = 2.86.ds1-7 should be entitled to assume that /run/* is a writable location available very early after boot. Initscripts 2.86.ds1-7 includes /run and mountvirtfs mounts a tmpfs on it, thus causing this assumption to be true. If the local admin wants something else then he or she can edit the script in such a way that the aforementioned assumption remains true. If there is demand for an alternative standard operation mode that satisfies the assumption then that can be implemented, of course, but offhand I can't think of why anyone would need anything but the default configuration. Matthew Garrett wrote: Has anyone talked to the FHS guys about this? Yes, I have talked to them about it and there is no objection. I think I have read all the discussions of this issue in the archives and I have yet to hear any strong reason why we should _not_ implement /run. I do not count It's ugly! as a strong reason. Background information at: http://panopticon.csustan.edu/thood/readonly-root.html -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /run vs /var/run (was: Please test new sysvinit)
(OK, this time reformatted to make my webmail composer happy.) Marco d'Itri wrote: I do not remember a consensus about this. Perhaps the last hold-outs can be convinced this time? :) Bernd Eckenfels wrote: and if it is placed in a tmpfs (which is really the best thing anyway) it doesnt matter under which mountpoint it is located. It does matter, because /run needs to be usable before other filesystems are mounted, and a filesystem can get mounted on /var, thus hiding anything that was stored at /var/run prior to this. One might propose shifting things around, but this quickly gets into race problems. And then it is much cleaner to have only one. Peter Samuelson wrote: Given the need, and now the reality, of /run, is there any need for a separate /var/run? Need is probably too strong, but it's certainly convenient if we don't have to change the way we currently use /var/run/. Steve Langasek wrote: (We also shouldn't need to specify a policy for mounting any particular filesystem on /run, but merely mount /run early iff it's present in /etc/fstab and leave the implementation details to the local admin.) I think that packages Depending on initscripts = 2.86.ds1-7 should be entitled to assume that /run/* is a writable location available very early after boot. Initscripts 2.86.ds1-7 includes /run and mountvirtfs mounts a tmpfs on it, thus causing this assumption to be true. If the local admin wants something else then he or she can edit the script in such a way that the aforementioned assumption remains true. If there is demand for an alternative standard operation mode that satisfies the assumption then that can be implemented, of course, but offhand I can't think of why anyone would need anything but the default configuration. Matthew Garrett wrote: Under Linux, can't all of this be done with mount --move anyway? I'm not convinced that we actually need a /run any more. The /run approach is simple and robust. Other approaches that have been proposed introduce some sort of race possibility, dealing with which makes those approaches more complex than the /run approach. I am sure that something could be worked out on the basis of mount --move, but I can't see why we should go to that trouble when we have a simpler alternative. Matthew Garrett wrote: Has anyone talked to the FHS guys about this? Yes, I have talked to them about it and there is no objection. I think I have read all the discussions of this issue in the archives and I have yet to hear any strong reason why we should _not_ implement /run. I do not count It's ugly! as a strong reason. Background information at: http://panopticon.csustan.edu/thood/readonly-root.html -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Your Confirmation Required
This message is to verify that you wish to have your email address: debian-devel@lists.debian.org removed from the Alharamain Sermon(english) Subscribe Me mailing list. You MUST click on the link below to have your address removed from our list. This is to ensure that someone doesn't remove your address from our list without your knowledge or consent. Thank you, http://www.alharamainsermons.org/cgi-bin/subscribe/s.pl?r=1l=1[EMAIL PROTECTED]p=343315 America Online users, please click: A HREF=http://www.alharamainsermons.org/cgi-bin/subscribe/s.pl?r=1l=1[EMAIL PROTECTED]p=343315BHere/B/A Alharamain Sermon(english) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: xmcd
On Sun, Dec 18, 2005 at 01:28:18 +0100 (+0100), Elimar Riesebieter wrote: On Sun, 18 Dec 2005 the mental interface of Matthew Palmer told: On Sat, Dec 17, 2005 at 08:37:28PM +0100, Elimar Riesebieter wrote: does one know why xmcd isn't upgraded since 31 of May in 2003? The package is neither orphaned nor up for adoption, which I would do then. Have you asked the maintainer, Adrian Bridgett? He's around (last made an upload less than a month ago, for tkdiff), so I don't see why he wouldn't be able to give you a reasonable answer to your question. Done. Hi, sorry for not responding earlier, I've less and less time for Debian stuff as time goes by (busy). There are substantial changes upstream in v3 - not least of which involves some distinctly non-free add-ons. Adrian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /run vs /var/run (was: Please test new sysvinit)
On Dec 18, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I have yet to hear any strong reason why we should _not_ implement /run. I do not count It's ugly! as a strong reason. It's not needed (since we have /dev/shm/), so it's harmful. -- ciao, Marco signature.asc Description: Digital signature
Re: Size matters. Debian binary package stats
Steinar H. Gunderson wrote: On Sun, Dec 18, 2005 at 12:34:56PM +0100, Gürkan Sengün wrote: I've run some scripts to find out the size of binary pakcages in debian and how theycould be made smaller, here's the results: My comments are about the same as on IRC: - Disk space is cheap, bandwidth is cheap. In many parts of the world. Nos so much in others. - CPU doesn't grow nearly as fast as those three. ??? In 1995 I had a Pentium 166 and a 56 kbps modem. Now, today the fastest CPU you can get from Intel is 3.6 GHz. However, the fastest dial modem you can get today is still 56k (remember that the majority of people worldwide are still on dial up). That means that for a 2200% increase in the maximum speed of a consumer-grade processor, there has a been 0% increase in the maximum speed of a dial up modem. A similar phenomenon has occurred for disk space. - Human power grows even slower. OK. - The administrative overhead of transitioning to a new .deb format would be huge. This is quite true. Thus, anything sacrificing lots of human power and CPU power to save on disk or bandwidth just doesn't make sense. That really depends. I routinely see posts on debian-user asking about how to use a friend's fast DSL or cable connection to download packages to install on a Debian box that has only dial up access to the Internet. I think that the biggest problem is really updates. Packages like XFree86 (no X.org) and Openoffice.org are *huge*. A simple security update to one of those packages causes all subordinate binary packages to get a version bump. That means that if there was a bug in the XFree86 driver for video card foo and I use video card bar, I still get download a many dozens of MB update. IIRC, something similar caused a major strain on security.debian.org shortly after the Sarge release. If we focus our energy on anything to reduce bandwidth, it should be making apt/dpkg smart enough to only need to grab the single changed binary package out of the 50 produced by source package foo, or maybe to employ and rsync-like approach. -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~roberto -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
You've Been Removed!
This message is to confirm the removal of your email address: debian-devel@lists.debian.org from the Alharamain Sermon(english) Subscribe Me mailing list. We're sorry to see you go! If you feel you have received this notice in error, please visit the Alharamain Sermon(english) Subscribe Me mailing list at our website: http://alharamainsermons.org to add yourself automatically, or click on the link below to automatically re-subscribe yourself: http://www.alharamainsermons.org/cgi-bin/subscribe/s.pl?a=1l=1[EMAIL PROTECTED] Thank you, Alharamain Sermon(english) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Size matters. Debian binary package stats
On 12/18/05, Roberto Sanchez [EMAIL PROTECTED] wrote: I think that the biggest problem is really updates. Packages like XFree86 (no X.org) and Openoffice.org are *huge*. A simple security update to one of those packages causes all subordinate binary packages to get a version bump. That means that if there was a bug in the XFree86 driver for video card foo and I use video card bar, I still get download a many dozens of MB update. IIRC, something similar caused a major strain on security.debian.org shortly after the Sarge release. If we focus our energy on anything to reduce bandwidth, it should be making apt/dpkg smart enough to only need to grab the single changed binary package out of the 50 produced by source package foo, or maybe to employ and rsync-like approach. It would be nice to make it even smarter and grab only the files that actually changed instead of the entire package.
Re: Size matters. Debian binary package stats
On 12/18/05, Steinar H. Gunderson [EMAIL PROTECTED] wrote: On Sun, Dec 18, 2005 at 12:34:56PM +0100, Gürkan Sengün wrote: I've run some scripts to find out the size of binary pakcages in debian and how theycould be made smaller, here's the results: My comments are about the same as on IRC: - Disk space is cheap, bandwidth is cheap. - CPU doesn't grow nearly as fast as those three. - Human power grows even slower. - The administrative overhead of transitioning to a new .deb format would be huge. Why would this be huge? Why is it that hard to plugin another codec?
Re: /run vs /var/run
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [EMAIL PROTECTED] (Marco d'Itri) writes: On Dec 18, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I have yet to hear any strong reason why we should _not_ implement /run. I do not count It's ugly! as a strong reason. It's not needed (since we have /dev/shm/), so it's harmful. It is certainly needed. How strongly can I put this? /dev/shm is for *shared memory*, not for random junk. /dev/shm is for POSIX shared memory and semaphores created with sem_open() and shm_open(). We don't want random breakage because people put files in there. /dev/shm is reserved. Because of this, it's *actively harmful* for /dev/shm to be used by initscripts, or indeed anything except the glibc POSIX shm_*() and sem_() implementation. Where was it ever written down that any package could use /dev/shm? They can't. 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.2 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8+ http://mailcrypt.sourceforge.net/ iD8DBQFDpWtzVcFcaSW/uEgRAoRHAKC4QgBqoiKBTnYa9/mA6ufn7BZhTACfRA1A /jJqmirucyfZUY+BiJXFJRg= =qC5b -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Size matters. Debian binary package stats
On Sun, Dec 18, 2005 at 08:41:03AM -0500, Roberto Sanchez wrote: - CPU doesn't grow nearly as fast as those three. In 1995 I had a Pentium 166 and a 56 kbps modem. Now, today the fastest CPU you can get from Intel is 3.6 GHz. However, the fastest dial modem you can get today is still 56k (remember that the majority of people worldwide are still on dial up). That means that for a 2200% increase in the maximum speed of a consumer-grade processor, there has a been 0% increase in the maximum speed of a dial up modem. A similar phenomenon has occurred for disk space. So? We're talking “bandwidth”, not “dial-up modem bandwidth” -- thankfully, the world is progressing, and we're moving away from dial-up at lightning speeds. :-) In 1995 I had a 28.800 modem -- today, I have 6Mbit at about the same price (probably a bit lower). That's a 21300% increase to match your 2200% increase :-) Not to mention that a DVD-R can fit about three million times as much data as a floppy disk, which was the dominant way of distributing software at the time. We can continue keep playing these number games, but I don't really see the point :-) If we focus our energy on anything to reduce bandwidth, it should be making apt/dpkg smart enough to only need to grab the single changed binary package out of the 50 produced by source package foo, or maybe to employ and rsync-like approach. Splitting packages makes sense for this sort of thing, and X did just that. /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: buildd administration -- TeX related FTBFS
Hi, I realize TeX is tough program to maintain. Thanks to Frank. One quick and easy way to avoid TeX related build issues are to avoid using TeX related tools during build time. So the results will be Debian only ships documentations in plain text and HTML. (No PS and no PDF). But is it what we should do? On Sat, Dec 17, 2005 at 01:38:25PM +1000, Anthony Towns wrote: On Fri, Dec 16, 2005 at 11:24:39AM +0100, Frank Küster wrote: ... It's been in experimental for more than half a year. Err, that's kind of absurdly long too. But I din not use it then :-( ... Six months is a lot of time; and experimental should provide you with the space and machine power to handle the rebuilding. Yes and no. Rebuilding Debian Reference takes few hours on 2GHz machine. So it is not easy but possible with 6 months. But tracking down cause of failure is not that simple. tetex-base has over 70MB as installed (bigger than kernel source.) So it is quite time consuming and close to impossible for non-tex expert. I don't know how many source changes are necessary to do the rebuilding, though. The changes may be few strings but ... where? So either we could have delayed teTeX 3.0 until god-knows-when, Uh, no. The whole point is to delay _less_, not more. Yes. Many document build scripts implement some special case fix thus it will break with upgrades. Also new major upgrade tends to pull in minor bugs into huge tetex package. Thus these will cause FTBFS (RC) bugs on many documentation packages whose maintainers are not always ready for making complicated adjustment to TeX upgrades. Recent changes to TeTeX 3 was easier than woody days. For example, when I got FTBFS RC bug due to tetex, I reassigned it to tetex. I should have reduced severity but I did not do it partly because of my wish to get Frank's attention and his assistance to fix it from Tetex package. Sorry. This may be the reason Frank felt about FTBFS/RC. It is not FTBFS for him and that was not RC for him. I wish that tetex upgrade happens more like gcc upgrades. So testing both versions are much easier and, if needed, we can specify older version ones. Much worse, there are a couple of cases where we had to NMU the packages, either because the maintainers where inactive, or in one case because he said no time here, just go ahead. Except for this one case this couldn't have been done with the packages in experimental, since failing to cooperate with a package in experimental isn't RC, is it? Not only do you not have to have an RC bug as an excuse to NMU; but uploads to experimental (which these presumably would be) have even less need for care and caution. Of course, in principle, we could have created our own compatible_with_teTeX-3.0 repository and uploaded fixed packages there, and do all the testing there. But then I don't understand what unstable is for... Generally, experimental fits the above role. Unstable's for uploading new development of packages that will hopefully work, but might turn out not to. In particular, though, they need to be fixed pretty quickly -- six months in experimental, and another two so far in unstable isn't quickly. I agree. Yes, the problem is that bugs in other packages keep popping up slowly. Like #341849 in debiandoc-sgml: We already had checked that debiandoc-sgml didn't have one of the usual incompatibility bugs, but then it turned out that there is still one, which is only triggered when a far-east document is typeset in a certain encoding. It was FTBFS for documentation packages which used debiandoc-sgml. A far-east document is typeset in a certain encoding doesn't sound like an RC bug; and therefore not something that should hold up transitioning to testing. Certainly, fix it ASAP once it's found, but that's the desired result for any bug. Exactly. I should have reduced severity. ... That would be bad, but I can't see how I can speed up tetex's evolution to be releasable by letting it rot in experimental. That's true; the idea isn't to let it rot in experimental, it's to have a quick pass through experimental that catches the most obscene bugs, then to put it in unstable where you catch a few more, then to let things progress to testing naturally, if necessary by having the RMs remove tetex related packages that aren't getting updated to the latest version in a timely or successful fashion. I think one to ease tension is to make tetex packages to coexist in archive just like many gcc. Current strict FTBFS rule will likely to make many documentations provided only in HTML, I think. Because fixing TeTeX related PDF/PS generation issues are quite difficult with short notice without tetex maintainer helping us. (They usually do.) We do not have soft and slow transition like gcc. I hope situation will be better soon but I am still struggling why debiandoc-sgml-doc fails to build nicely. (Yes, I know I can get by by
Re: Size matters. Debian binary package stats
On Sun, Dec 18, 2005 at 02:56:10PM +0100, Olaf van der Spek wrote: Why would this be huge? Why is it that hard to plugin another codec? You'd have to rewrite about every single tool in the world handling .debs, make up a transition plan and upgrade from that. Not to mention that you'd have to make sure it works on all kinds of obscure platforms actually using the thing. (And yes, I have used ar and tar to extract debs, and consider it a quite useful feature.) The .deb format is _fixed_ -- this isn't AVI where you just “plug in another codec” and hope it works. /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /run vs /var/run (was: Please test new sysvinit)
On Sun, Dec 18, 2005 at 02:37:28PM +0100, Marco d'Itri wrote: On Dec 18, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I have yet to hear any strong reason why we should _not_ implement /run. I do not count It's ugly! as a strong reason. It's not needed (since we have /dev/shm/), so it's harmful. Does not follow. Cars aren't needed either (you can always take the train, or go by bus), but that doesn't make them harmful. Furthermore, /dev/shm is a mount point with a _very_ specific function. It's a bad idea to start using it for something else. -- .../ -/ ---/ .--./ / .--/ .-/ .../ -/ ../ -./ --./ / -.--/ ---/ ..-/ .-./ / -/ ../ --/ ./ / .--/ ../ -/ / / -../ ./ -.-./ ---/ -../ ../ -./ --./ / --/ -.--/ / .../ ../ --./ -./ .-/ -/ ..-/ .-./ ./ .-.-.-/ / --/ ---/ .-./ .../ ./ / ../ .../ / ---/ ..-/ -/ -../ .-/ -/ ./ -../ / -/ ./ -.-./ / -./ ---/ .-../ ---/ --./ -.--/ / .-/ -./ -.--/ .--/ .-/ -.--/ .-.-.-/ / ...-.-/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /run vs /var/run
In article [EMAIL PROTECTED] you wrote: However there a big differences: /var/run is much smaller than /run, and if sorry i meant to say: /var/run is much smaller (bytewise) as /usr/lib. Gruss Bernd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: xmcd
On Sun, 18 Dec 2005 the mental interface of adrian told: On Sun, Dec 18, 2005 at 01:28:18 +0100 (+0100), Elimar Riesebieter wrote: On Sun, 18 Dec 2005 the mental interface of Matthew Palmer told: On Sat, Dec 17, 2005 at 08:37:28PM +0100, Elimar Riesebieter wrote: does one know why xmcd isn't upgraded since 31 of May in 2003? The package is neither orphaned nor up for adoption, which I would do then. Have you asked the maintainer, Adrian Bridgett? He's around (last made an upload less than a month ago, for tkdiff), so I don't see why he wouldn't be able to give you a reasonable answer to your question. Done. Hi, sorry for not responding earlier, I've less and less time for Debian stuff as time goes by (busy). There are substantial changes upstream in v3 - not least of which involves some distinctly non-free add-ons. Do you mean the cdda-gracenote stuff? mp3- and faacencoding can be suppressed while buildtime. Elimar -- The path to source is always uphill! -unknown- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /run vs /var/run
In article [EMAIL PROTECTED] you wrote: Bernd Eckenfels wrote: and if it is placed in a tmpfs (which is really the best thing anyway) it doesnt matter under which mountpoint it is located. It does matter, because /run needs to be usable before other filesystems are mounted, and a filesystem can get mounted on /var, thus hiding anything that was stored at /var/run prior to this. One might propose shifting things around, but this quickly gets into race problems. Yes of course. I meant: it does not matter if you place it on /run instead of /var since it does not take up more ressources. Gruss Bernd y -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian Installer team monthly meeting minutes (20051214 meeting)
In article [EMAIL PROTECTED] you wrote: I hope this will be solved soon! use nameif. Gruss Bernd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Size matters. Debian binary package stats
On Sun, Dec 18, 2005, Andreas Metzler wrote: Have you perhaps run some benchmarks? Thanks to Kingsley Morse Jr.: http://adn.diwi.org/debian/p7zip/7za.jpg Even more precise at http://www.linuxjournal.com/article/8051 -- adn Mohammed Adnène Trojette -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian Installer team monthly meeting minutes (20051214 meeting)
On Sunday 18 December 2005 15:34, Bernd Eckenfels wrote: In article [EMAIL PROTECTED] you wrote: I hope this will be solved soon! use nameif. This has been suggested before but AIUI nameif has problems/limitations renaming eth0. The correct solution seems to be to use udev rewriting rules to make sure interfaces keep their name. We will work on implementing this in Debian Installer before the next beta release. Both Ubuntu and Marco d'Itri have offered to help with that. For existing users we should make sure this issue will be documented in the Release Notes for Etch. I'm filing a bug against release-notes as a reminder. pgpQRkSVAJr2o.pgp Description: PGP signature
Bug#343887: ITP: libpod-tests-perl -- Perl extension for excts embedded tests and code examples from POD
Package: wnpp Severity: wishlist Owner: Jonas Genannt [EMAIL PROTECTED] * Package name: libpod-tests-perl Version : 0.18 Upstream Author : Adam Kennedy [EMAIL PROTECTED] * URL : http://search.cpan.org/~adamk/ * License : GPL Description : Perl extension for excts embedded tests and code examples from POD This is a specialized POD viewer to extract embedded tests and code examples from POD. It doesn't do much more than that. pod2test does the useful work. New build depend for #329990 -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.6.8-2-686-smp Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: congratulations to our ftp-master team
Russ Allbery [EMAIL PROTECTED] writes: Anand Kumria [EMAIL PROTECTED] writes: A simple assurance that your package will be rejected from the NEW queue if no ftp-master approves it within 2 weeks would actually be a benefit. Why? It seems like, if that's the way that you want the world to work, you could already just pretend that this is the case. If your package has gone for more than two weeks, it seems to me like you could decide to treat it in all respects as if it had been rejected and just go on with your life. If it ends up getting accepted, you could orphan it, or decide to pick it up again. When the ftp masters reject a package, they say why it has been rejected as a rule. So at least that part can't be substituted for in this way. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Kernel 2.4 in Etch (was: Re: Re: /run vs /var/run)
Are we seriously expecting to ship etch with 2.4 kernels? Is anyone still doing active security support for it? This point isn't too bad yet. As you've seen 2.4 had a security update a few days ago. Sure, it's from August, but 2.6 isn't doing better anyway. Some Debian kernel team people (such as Horms) seem to be dedicated to backport upstream's security work. A better question is whether there will be active security support for 2.4 if it sticks in Etch. This is unlikely to be much the case, considering that with the number of regressions in 2.6 continually dropping, when Etch releases 2.4 will probably look nearly as bad as 2.2 did when Sarge released (that was, no upstream release since over a year). So if we want 2.4 in Etch and decent security, the kernel team may have to do better than upstream... Another more interesting question is whether it's worth keeping 2.4 in Etch (which should mean about 3 years of backporting) assuming that the stable security infrastructure isn't fixed before Etch releases. 3.1r1 was delayed due to kernel updates, and when it's ready to be released it has a 4 months old package. 3 months of updatedness gained, 4 lost. In this context, if the security team doesn't change, removing half of the kernels would be a real help for the security of the rest of stable. But for the first question, if there isn't a decision (and I don't know by who and how this decision will be made) about this in the few next monthes, the not so long schedule for Etch may make it impossible to do such a large change IMO. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /run vs /var/run (was: Please test new sysvinit)
On Sun, Dec 18, 2005 at 01:26:45PM +0100, [EMAIL PROTECTED] wrote: It does matter, because /run needs to be usable before other filesystems I realise your heart's set on /run, but is there any possibility of putting it under /lib/run or /boot/early-writable-fs instead of introducing a new directory on / that's of very limited use? (/usr, /var, /home, /opt, /srv and /tmp are out in that they'll get over-mounted; /dev, /sys and /proc are out because they're all sorts of weirdness and aren't appropriate anyway; /mnt and /media are out; /bin, /sbin, and /root are inappropriate; that leaves /boot and /lib. And I guess /boot is out since it's often a separate partition too) Matthew Garrett wrote: Has anyone talked to the FHS guys about this? Yes, I have talked to them about it and there is no objection. Huh? URL? I'm surprised there isn't at least a pro-forma objection to creating a new directory in /. I do not count It's ugly! as a strong reason. You should; especially since it seems solvable by hiding it in /lib alongside /lib/modules. Cheers, aj signature.asc Description: Digital signature
Re: /run vs /var/run (was: Please test new sysvinit)
On Dec 18, Wouter Verhelst [EMAIL PROTECTED] wrote: It's not needed (since we have /dev/shm/), so it's harmful. Does not follow. Cars aren't needed either (you can always take the train, or go by bus), but that doesn't make them harmful. Cars and trains are different thigs, but a tmpfs is a tmpfs. Furthermore, /dev/shm is a mount point with a _very_ specific function. It's a bad idea to start using it for something else. Reality check: packages have been using it for a long time and the world has not fallen yet. -- ciao, Marco signature.asc Description: Digital signature
Re: /run vs /var/run
On Dec 18, Roger Leigh [EMAIL PROTECTED] wrote: How strongly can I put this? /dev/shm is for *shared memory*, not for random junk. /dev/shm is for POSIX shared memory and semaphores /dev/shm is a tmpfs which happens to be used by POSIX SHM. I have not seen yet a good reason why it should not be used by other users too. created with sem_open() and shm_open(). We don't want random breakage because people put files in there. /dev/shm is reserved. Actually people have been putting files there for a while, even in packages in a stable release. Can you point us to some examples of the random breakage you suggest has happened? Where was it ever written down that any package could use /dev/shm? They can't. Oops. They already do. -- ciao, Marco signature.asc Description: Digital signature
Bug#343897: ftp.debian.org: Please remove all webmin related packages
Package: ftp.debian.org Severity: wishlist I am asking for the immediate removal of the following source packages and all their binaries: usermin usermin-contrib webmin webmin-cluster webmin-contrib webmin-exim webmin-extra webmin-optional webmin-snort webmin-virtual-server It should be blindingly obvious that these packages are not really being maintained anymore. I have always been more or less the only person looking after them. I have had a lot of positive feedback from users (and even some money on occasion) but I'm finding less and less time and motivation to keep at it. It is better to drop them now rather than perpetrate the cruel joke that these are Debian-quality packages; especially because newbies often rely on webmin to administer their systems and keep them secure. And we owe it to Jamie Cameron, the author of webmin, not to besmirch his name and product with buggy crap. Why don't I just orphan them? Well I already tried that and I'm sure like then, there will be an initial flurry of interest and offers to help but they almost never pan out. I ended up doing all the work anyway. If someone really, really wants webmin in Debian, they should prove it by doing an ITP and reintroducing it themselves. There is one current security problem in sarge which I will assist the security team with resolving but other than that, as of this day I wash my hands of webmin. -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.6.10-xenU-p4-e1000 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /run vs /var/run
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[EMAIL PROTECTED] (Marco d'Itri) writes:
On Dec 18, Roger Leigh [EMAIL PROTECTED] wrote:
How strongly can I put this? /dev/shm is for *shared memory*, not for
random junk. /dev/shm is for POSIX shared memory and semaphores
/dev/shm is a tmpfs which happens to be used by POSIX SHM. I have not
seen yet a good reason why it should not be used by other users too.
There could be a naming conflict. The entire namespace is reserved
for SHM, right? That means if someone does a
int shm = shm_open(/foobar, O_CREAY, 0600)
and some thoughtless prat already put something by than name there,
they are completely stuffed.
They should use a tmpfs mounted somewhere else.
Here's a sample program to demonstrate:
#include sys/mman.h
#include sys/types.h
#include sys/stat.h
#include fcntl.h
#include errno.h
#include stdio.h
#include stdlib.h
#include string.h
int
main (void)
{
int fd = shm_open(/foobar, O_CREAT, 0600);
if (fd 0)
{
fprintf(stderr, ERROR: %s\n, strerror(errno));
exit(1);
}
fprintf(stderr, SUCCESS\n);
exit(0);
}
created with sem_open() and shm_open(). We don't want random breakage
because people put files in there. /dev/shm is reserved.
Actually people have been putting files there for a while, even in
packages in a stable release. Can you point us to some examples of the
random breakage you suggest has happened?
It hasn't happened, but POSIX shm will inevitably take time to gain
users. That doesn't mean abusing it is a good idea in the meantime.
Where was it ever written down that any package could use /dev/shm?
They can't.
Oops. They already do.
Correct, but does that make it OK? I find it disgustingly bad
practice, and now we have /run, they can move to using that. /run is
a good idea for this reason alone, because it will correct this abuse.
I fail to see why anyone can consider abuse of an unrelated subsystem
because it's there is good engineering practice. Any package
abusing /dev/shm is deserving of an RC bug.
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.2 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8+ http://mailcrypt.sourceforge.net/
iD8DBQFDpZ2cVcFcaSW/uEgRApREAJ9tyP3j5T8nXJEUyq/2yidKjxIlfgCgkMAr
iOv0KKusOB1opxHOmcGzRUQ=
=8W5l
-END PGP SIGNATURE-
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Please test new sysvinit, sysv-rc, initscripts
Steinar H. Gunderson [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] I won't complain, I'll just send a friendly assassin to your house :-) A friendly assasin? Is that the type that comes in, talks with you for a while, and eventually offers you a poisioned beer? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /run vs /var/run (was: Please test new sysvinit)
Marco d'Itri [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Furthermore, /dev/shm is a mount point with a _very_ specific function. It's a bad idea to start using it for something else. Reality check: packages have been using it for a long time and the world has not fallen yet. Hmm... Lets see: 1. POSIX (or at least SuS v3) does not gaurentee the existence of /dev/shm, or that if it does exist, that it can be be read as a block device, or that if it can, it has a file system on it. 2. Neither does FHS. 3. The Linux 2.6 device list states that as of now, if /dev/shm exists it should have a tmpfs filesystem. But makes no guarentees that it exists, or that it will remain a filesystem So AIUI: 1. It exists only on Linux-based OS's 2. There is no gaurentee that it will continue to be there at all 3. There is no guareteee that it will remain a filesystem in the future even if it is there. 4. There is no gaurentee that it exists at all. Sounds it sounds to me like it is a bad idea to use it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Size matters. Debian binary package stats
On Sun, 2005-12-18 at 15:02 +0100, Steinar H. Gunderson wrote: On Sun, Dec 18, 2005 at 08:41:03AM -0500, Roberto Sanchez wrote: - CPU doesn't grow nearly as fast as those three. In 1995 I had a Pentium 166 and a 56 kbps modem. Now, today the fastest CPU you can get from Intel is 3.6 GHz. However, the fastest dial modem you can get today is still 56k (remember that the majority of people worldwide are still on dial up). That means that for a 2200% increase in the maximum speed of a consumer-grade processor, there has a been 0% increase in the maximum speed of a dial up modem. A similar phenomenon has occurred for disk space. So? We're talking “bandwidth”, not “dial-up modem bandwidth” -- thankfully, the world is progressing, and we're moving away from dial-up at lightning speeds. :-) In 1995 I had a 28.800 modem -- today, I have 6Mbit at about the same price (probably a bit lower). That's a 21300% increase to match your 2200% increase :-) But there are still many people stuck on dial-up, because of where they live. -- - Ron Johnson, Jr. Jefferson, LA USA You're a good example of why some animals eat their young. Jim Samuels
Re: Size matters. Debian binary package stats
On Sun, 2005-12-18 at 12:59 +0100, Steinar H. Gunderson wrote: On Sun, Dec 18, 2005 at 12:34:56PM +0100, Gürkan Sengün wrote: I've run some scripts to find out the size of binary pakcages in debian and how theycould be made smaller, here's the results: My comments are about the same as on IRC: - Disk space is cheap, bandwidth is cheap. Spoken like someone who's never had to pay for a server room. -- - Ron Johnson, Jr. Jefferson, LA USA Man, I'm pretty. Hoo Hah! Johnny Bravo
switching to vim-tiny for standard vi?
As you can see below and in the BTS, vim's maintainer has managed to create a vim-tiny package that is vim without some of the extras such as syntax highlighting. It's now only marginally larger than nvi, which is the standard vi included in the base system (amazingly, it's smaller than nano, the other editor in the base system). Stefano suggested that vim-tiny could replace nvi and become part of base, and I think it's a good idea. There are obviously users who will prefer nvi to vim (and others who prefer some other vi), but I get the impression there are rather more who prefer vim, it's probably the most commonly used vi in linux these days. One argument I can think of for keeping nvi in base is that it is the closest to bug-compatible with the original vi. However, I don't think that will prevent hardcore vi users from easily using vim-tiny if it's in base. - Forwarded message from Stefano Zacchiroli [EMAIL PROTECTED] - From: Stefano Zacchiroli [EMAIL PROTECTED] Date: Sun, 18 Dec 2005 16:19:50 +0100 To: Joey Hess [EMAIL PROTECTED] Cc: Len Sorensen [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: vim-tiny is in unstable User-Agent: Mutt/1.5.11 On Tue, Nov 01, 2005 at 01:46:27PM -0500, Joey Hess wrote: Do you like me to ping you again when the packaging is in its final shape - perhaps after the upload to unstable - so that you can start the thread on d-d (after all you're the submitter and a member of the d-i team) or what? Yes that would be fine. Hi Joey, vim-tiny is available in debian/unstable. There are still some minor bugs, but the package is fine. The installed-size of it and of vim-common are as I anticipated (776 + 232 on i386); the only additional dependencies are libc6 and libncurses5. Feel free to start the discussion on d-d for the inclusion of vim-tiny in the base system in place of nvi (or just ask and I will do it). Cheers. -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. -!- - End forwarded message - -- see shy jo signature.asc Description: Digital signature
Re: switching to vim-tiny for standard vi?
On Sun, Dec 18, 2005 at 01:38:57PM -0500, Joey Hess wrote: There are obviously users who will prefer nvi to vim (and others who prefer some other vi), but I get the impression there are rather more who prefer vim, it's probably the most commonly used vi in linux these days. Count me as an nvi person. Vim is great - but not as the default in the most basic system, no matter how stripped down. One argument I can think of for keeping nvi in base is that it is the closest to bug-compatible with the original vi. However, I don't think that will prevent hardcore vi users from easily using vim-tiny if it's in base. Will it work fine over a serial console? Is it fine for ex-Solaris/HP-UX /AIX admins who may have got used to nvi? Unfortunately, the vi/vim flamewars are not yet concluded :( All IMHO, ATB, Andy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /run vs /var/run (was: Please test new sysvinit)
Anthony Towns wrote: is there any possibility of putting it under /lib/run or /boot/early-writable-fs instead of introducing a new directory on / that's of very limited use? That is certainly possible, but I don't see anything wrong with putting it at the top level either. FWIW I asked Chris Yeoh for his opinion on the name and he said that /run sounded preferable to both /etc/run and /lib/run. Huh? URL? I'm surprised there isn't at least a pro-forma objection to creating a new directory in /. The main condition is that we have good reasons for adding it. Also, its use should be restricted to Debian infrastructure packages until such time as the directory gets officially recognized by the FHS. I do not count It's ugly! as a strong reason. You should; especially since it seems solvable by hiding it in /lib alongside /lib/modules. The problem is that some people find /lib/run uglier than /run. ;) -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: switching to vim-tiny for standard vi?
su, 2005-12-18 kello 13:38 -0500, Joey Hess kirjoitti: One argument I can think of for keeping nvi in base is that it is the closest to bug-compatible with the original vi. However, I don't think that will prevent hardcore vi users from easily using vim-tiny if it's in base. I'm one of the people who prefers nvi over vim. I do so quite strongly, because I find that nvi obeys my fingers and vim does not. The differences are minute, of course, but they are really irritating. Unfortunately, I can't enlist them properly, since my fingers don't talk to me: I notice vim's incompatibility from the fact that my fingers have to keep correcting text under vim, but not under nvi. On days when I'm generally annoyed already, if I accidentally use vim instead of nvi, I can get quite lyrical with my cursing. I'm not bothered at all by switching nvi with vim-tiny in base. As long as I can install nvi if I want to, I'm happy. I'd even be happy without any vi-like editor in base. As long as there is one editor in base that I can without great difficulty in an emergency (nano seems to qualify), I don't need anything more. In fact, given that it's good for base to be small, I'd like to suggest that we don't have more than one editor there. -- The most difficult thing in programming is to be simple and straightforward. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: switching to vim-tiny for standard vi?
* Lars Wirzenius wrote: In fact, given that it's good for base to be small, I'd like to suggest that we don't have more than one editor there. We already have two editors in the base system, nvi and nano. Norbert -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: switching to vim-tiny for standard vi?
On Dec 18, Andrew M.A. Cater [EMAIL PROTECTED] wrote: Will it work fine over a serial console? Is it fine for ex-Solaris/HP-UX Sure, I often use vim over serial consoles. -- ciao, Marco signature.asc Description: Digital signature
Re: /run vs /var/run (was: Please test new sysvinit)
On Dec 18, Joe Smith [EMAIL PROTECTED] wrote: 1. POSIX (or at least SuS v3) does not gaurentee the existence of /dev/shm, or that if it does exist, that it can be be read as a block device, or that if it can, it has a file system on it. 2. Neither does FHS. 3. The Linux 2.6 device list states that as of now, if /dev/shm exists it should have a tmpfs filesystem. But makes no guarentees that it exists, or that it will remain a filesystem Debian guarantees that it exists on debian systems. 1. It exists only on Linux-based OS's 2. There is no gaurentee that it will continue to be there at all 3. There is no guareteee that it will remain a filesystem in the future even if it is there. 4. There is no gaurentee that it exists at all. These points apply to the proposed tmpfs-based /run as well. Sounds it sounds to me like it is a bad idea to use it. Only because you have no clue of what you are talking about. -- ciao, Marco signature.asc Description: Digital signature
Re: /run vs /var/run (was: Please test new sysvinit)
On Dec 18, Thomas Hood [EMAIL PROTECTED] wrote: FWIW I asked Chris Yeoh for his opinion on the name and he said that /run sounded preferable to both /etc/run and /lib/run. Competition with /root in tab-completion, for a start. -- ciao, Marco signature.asc Description: Digital signature
Re: Size matters. Debian binary package stats
On 12/18/05, Steinar H. Gunderson [EMAIL PROTECTED] wrote: On Sun, Dec 18, 2005 at 02:56:10PM +0100, Olaf van der Spek wrote: Why would this be huge? Why is it that hard to plugin another codec? You'd have to rewrite about every single tool in the world handling .debs, make up a transition plan and upgrade from that. Not to mention that you'd Why is the knowledge of how to decode a .deb distributed over so many tools? have to make sure it works on all kinds of obscure platforms actually using the thing. (And yes, I have used ar and tar to extract debs, and consider it a quite useful feature.) Why would that stop working if you switch compression schemes? I guess tar is coded to use gzip with -z and bzip2 with -j, but why is there no generic way to add coders/decoders (codecs) to tar (and other applications that wish to use compression filters)? The .deb format is _fixed_ -- this isn't AVI where you just plug in another codec and hope it works.
Re: congratulations to our ftp-master team
Thomas Bushnell BSG [EMAIL PROTECTED] writes: Russ Allbery [EMAIL PROTECTED] writes: Anand Kumria [EMAIL PROTECTED] writes: A simple assurance that your package will be rejected from the NEW queue if no ftp-master approves it within 2 weeks would actually be a benefit. Why? It seems like, if that's the way that you want the world to work, you could already just pretend that this is the case. If your package has gone for more than two weeks, it seems to me like you could decide to treat it in all respects as if it had been rejected and just go on with your life. If it ends up getting accepted, you could orphan it, or decide to pick it up again. When the ftp masters reject a package, they say why it has been rejected as a rule. So at least that part can't be substituted for in this way. Yes, but that's a different conversation. Anand didn't say anything about getting a reason. The proposal was that packages be automatically rejected if no ftp-master approves it within two weeks. I don't understand how that helps anyone. You still don't get any explanation, and now there's not even a chance someone will find time to look at it. -- 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: Size matters. Debian binary package stats
* Steinar H. Gunderson: My comments are about the same as on IRC: - Disk space is cheap, bandwidth is cheap. Depends. Decent IP service costs a few EUR per gigabyte in most parts of the world. Thus, anything sacrificing lots of human power and CPU power to save on disk or bandwidth just doesn't make sense. My main concern is that changing the compression algorithm alone optimizes for the wrong case (initial install), which you can do from CD anyway if you are bandwidth-starved. Delta compression for .debs would be far more interesting, I guess, but I have no idea how to implement them in a sane way. 8-/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /run vs /var/run (was: Please test new sysvinit)
On Sun, Dec 18, 2005 at 01:03:37PM -0500, Joe Smith wrote: 1. POSIX (or at least SuS v3) does not gaurentee the existence of /dev/shm, or that if it does exist, that it can be be read as a block device, or that if it can, it has a file system on it. 2. Neither does FHS. 3. The Linux 2.6 device list states that as of now, if /dev/shm exists it should have a tmpfs filesystem. But makes no guarentees that it exists, or that it will remain a filesystem Also Linux allows to not build support for a full-blown tmpfs that supports all posix filesystem operations, but also a cut-down version that's just enough for posix shm. You can't use read or write on files in /dev/shm in that case. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: switching to vim-tiny for standard vi?
su, 2005-12-18 kello 20:17 +0100, Norbert Tretkowski kirjoitti: * Lars Wirzenius wrote: In fact, given that it's good for base to be small, I'd like to suggest that we don't have more than one editor there. We already have two editors in the base system, nvi and nano. Yes, that being the bloat I was referring to. -- C is the *wrong* language for your application. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Size matters. Debian binary package stats
On Sun, Dec 18, 2005 at 12:34:56PM +0100, Gürkan Sengün wrote: Hi I've run some scripts to find out the size of binary pakcages in debian and how theycould be made smaller, here's the results: http://www.linuks.mine.nu/sizematters/ FWIW : https://wiki.ubuntu.com/Dpkg7Zip Actual maintainer of dpkg is evaluating the possibility to use 7zip. Even if the decision of using 7zip by default is far from being taken, it looks likely that dpkg will at least start supporting it. Cheers, -- Raphaël Hertzog -+- http://www.ouaza.com Freexian : des développeurs Debian au service des entreprises http://www.freexian.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Size matters. Debian binary package stats
* Andreas Metzler: Afaict from the webpage 7zip (LZMA) is quite a bit slower bzip2. - Have you perhaps run some benchmarks? Memory use during decompression would be interesting, too. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /run vs /var/run (was: Please test new sysvinit)
su, 2005-12-18 kello 20:18 +0100, Marco d'Itri kirjoitti: Sounds it sounds to me like it is a bad idea to use it. Only because you have no clue of what you are talking about. Marco, would please keep the discussion technical, and not attack the people taking part, even if you think they're wrong? Concentrating on the issues is productive, discussing people isn't, in the long run. -- Never underestimate the power of a small tactical Lisp interpreter. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: buildd administration
Anthony Towns aj@azure.humbug.org.au wrote: On Fri, Dec 16, 2005 at 11:24:39AM +0100, Frank Küster wrote: No, that would be unsuitable for release. Which is a problem that should either be fixed quickly, or means you're trying to make a big enough change that you should be working out how to get it done without breaking other packages in a separate area, such as experimental. It's been in experimental for more than half a year. Err, that's kind of absurdly long too. Yes, I had a three months no-Debian-work-at-all break, and slow progress due to real-life issues after that, too. We could have tried to install and use every depending, and build every build-depending package. But that is simply not feasible with the manpower, time and machine power that's available to the teTeX maintainers. Six months is a lot of time; and experimental should provide you with the space and machine power to handle the rebuilding. I don't know of any autobuilders that build packages from sid against build-dependencies in experimental. I don't know how many source changes are necessary to do the rebuilding, though. None for the bugs found so far. The library issues will have to be handled later. Of course, in principle, we could have created our own compatible_with_teTeX-3.0 repository and uploaded fixed packages there, and do all the testing there. But then I don't understand what unstable is for... Generally, experimental fits the above role. Unstable's for uploading new development of packages that will hopefully work, but might turn out not to. In particular, though, they need to be fixed pretty quickly -- six months in experimental, and another two so far in unstable isn't quickly. There are no real RC bugs in tetex, and haven't been most of the time. The RC bugs are in the large number of packages that depend on tetex, and sometimes break tetex-bin's installation, sometimes only themselves. A far-east document is typeset in a certain encoding doesn't sound like an RC bug; and therefore not something that should hold up transitioning to testing. The package with the RC bug is debian-reference, which builds documents in different languages from sgml source for its binary packages. If this package fails to create one of its documents, this is a FTBFS and of course RC. A year before sarge's release, we were at around 400 RC bugs in testing, and 600 in unstable; Err, that should read 3 months before everybody thought sarge would be released. Uh, no, it shouldn't. Next December is when sarge will be released, A year before sarge's release was June 2004, and at that time all unenlightened DDs believed we would freeze on August 1st (or something around that date) and release in September + x. For that very reason I handled teTeX much more conservatively than I had done had I known that I had one year left[1], and had I known the truth I would have made changes (namely upload the betas of the upstream version now in discussion) that would have raised the RC bug count for a while. Instead I was *extremely* careful (and did lots of duplicate work). I expect that others had acted similar. That doesn't mean that I will now act as if etch would be released with a 1-year-delay, too - on the contrary, just as I did with sarge. That's true; the idea isn't to let it rot in experimental, it's to have a quick pass through experimental that catches the most obscene bugs, then to put it in unstable where you catch a few more, then to let things progress to testing naturally, if necessary by having the RMs remove tetex related packages that aren't getting updated to the latest version in a timely or successful fashion. That sounds all very nice. But currently, I didn't even have time to build a lists of packages we filed RC bugs on, and track whether they have been properly fixed. Before that I can't judge whether it should proceed to testing, or which packages would need to be removed. I (and some others) manage teTeX as a volunteer in my free time. If Debian thinks that this is not enough, it should either help us with manpower or drop teTeX and depending packages. Just ranting at how we handle the package doesn't help us, our users or the release process. Regards, Frank [1] and I have no indication that the RC bugs count had any influence on the sarge delay between summer 04 and march 05. -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: /run vs /var/run
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [EMAIL PROTECTED] (Marco d'Itri) writes: On Dec 18, Joe Smith [EMAIL PROTECTED] wrote: 1. POSIX (or at least SuS v3) does not gaurentee the existence of /dev/shm, or that if it does exist, that it can be be read as a block device, or that if it can, it has a file system on it. 2. Neither does FHS. 3. The Linux 2.6 device list states that as of now, if /dev/shm exists it should have a tmpfs filesystem. But makes no guarentees that it exists, or that it will remain a filesystem Debian guarantees that it exists on debian systems. But what about the future, and what about it being specifically for POSIX-SHM? 1. It exists only on Linux-based OS's 2. There is no gaurentee that it will continue to be there at all 3. There is no guareteee that it will remain a filesystem in the future even if it is there. 4. There is no gaurentee that it exists at all. These points apply to the proposed tmpfs-based /run as well. /run doesn't especially /need/ to be a tmpfs fs does it? It could equally be on the root fs, or a symlink to somewhere else. The important thing is that is exists and is standardised; it's then up to the local admin how he wants it to behave. Now that it's in sysvinit, the first criterion is satisfied, and hopefully in the fullness of time the second will also, if and when it's added to the FHS. Sounds it sounds to me like it is a bad idea to use it. Only because you have no clue of what you are talking about. On the contrary, he made several good points, which you would do well to fully consider before dismissing them out of hand. 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.2 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8+ http://mailcrypt.sourceforge.net/ iD8DBQFDpbu5VcFcaSW/uEgRAgByAKDE6wLZXsUQnEJYsDNw60m7wy+huACfVckj M1jpWNCF2SrYm1QQniyEckg= =x/ht -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Size matters. Debian binary package stats
On Sun, Dec 18, 2005 at 08:23:56PM +0100, Olaf van der Spek wrote: On 12/18/05, Steinar H. Gunderson [EMAIL PROTECTED] wrote: On Sun, Dec 18, 2005 at 02:56:10PM +0100, Olaf van der Spek wrote: Why would this be huge? Why is it that hard to plugin another codec? You'd have to rewrite about every single tool in the world handling .debs, make up a transition plan and upgrade from that. Not to mention that you'd Why is the knowledge of how to decode a .deb distributed over so many tools? Probably, it's because there's no [C] library that would allow those tools to deal with .deb files. Hence everybody start writing the tool by creating one more parser for the .deb format. -- Misha signature.asc Description: Digital signature
Re: buildd administration
On Sun, Dec 18, 2005 at 08:34:04PM +0100, Frank Küster wrote: Six months is a lot of time; and experimental should provide you with the space and machine power to handle the rebuilding. I don't know of any autobuilders that build packages from sid against build-dependencies in experimental. I thought I did build alot of packages from sid against your tetex from experimental, and reported the results to you. I guess you found more problems after the ones I got? Anyway, I'm willing to do build tests for such things. Feel free to ask me. I'd rather have that those bugs are known before they hit unstable. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: switching to vim-tiny for standard vi?
On Sun, Dec 18, 2005 at 06:54:42PM +, Andrew M.A. Cater wrote: On Sun, Dec 18, 2005 at 01:38:57PM -0500, Joey Hess wrote: There are obviously users who will prefer nvi to vim (and others who prefer some other vi), but I get the impression there are rather more who prefer vim, it's probably the most commonly used vi in linux these days. Count me as an nvi person. Vim is great - but not as the default in the most basic system, no matter how stripped down. Why is nvi better if the size of nvi and vim-tiny are comparable? -- gram -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: switching to vim-tiny for standard vi?
Lars Wirzenius wrote: I'm one of the people who prefers nvi over vim. I do so quite strongly, because I find that nvi obeys my fingers and vim does not. The differences are minute, of course, but they are really irritating. Unfortunately, I can't enlist them properly, since my fingers don't talk to me: I notice vim's incompatibility from the fact that my fingers have to keep correcting text under vim, but not under nvi. On days when I'm generally annoyed already, if I accidentally use vim instead of nvi, I can get quite lyrical with my cursing. Yeah, I understand the feeling (coming at it from the exact opposite side). It would be helpful if there were an analysis of the major differences somewhere; the ones I am most aware of incude: - home, end, page up, page down, and delete, all do something reasonable in vim in insert or append mode, but do nothing very useful in nvi in those modes. - in vim the arrow keys always move around even in insert mode. In nvi they do too (surely it diverges from real vi here?), but if you arrow to the end of a line, it flashes the screen and drops you out of insert mode. - vim wordwraps long lines by default as they are inserted (bloody annoying); nvi usefully just logically wraps the single long line for display - backspace in vim deletes the character to the left, instead of just moving the cursor back and temporarily turning off insert mode - backspace in vim can delete text you have not just inserted; in nvi it only backspaces through the just inserted text - delete in vim deletes the character under the cursor and if you delete all the way to the end of the line, pulls the next line up and begins deleting it too, whereas in nvi delete begins backspacing through the remainder of the line if you reach the end of the line, and it never deletes other lines - vim supports multiple levels of undo; in nvi the second undo undoes your undo - some commands like 'cw' display differently in vim, although the end result of the keystrokes is the same for all the standard vi commands I use - nvi flashes the screen/bell when a command fails; vim does not - :help vi-differences in vim describes some other differences that are less noticible I'm not bothered at all by switching nvi with vim-tiny in base. As long as I can install nvi if I want to, I'm happy. I'd even be happy without any vi-like editor in base. As long as there is one editor in base that I can without great difficulty in an emergency (nano seems to qualify), I don't need anything more. In fact, given that it's good for base to be small, I'd like to suggest that we don't have more than one editor there. IIRC the reason we have a vi in base, and at priority important at that is because of the definition in policy that: `important' Important programs, including those which one would expect to find on any Unix-like system. If the expectation is that an experienced Unix person who found it missing would say What on earth is going on, where is `foo'?, it must be an `important' package. Which of course includes a vi. (Note that the paragraph goes on to explicitly rule out emacs.) -- see shy jo signature.asc Description: Digital signature
Re: switching to vim-tiny for standard vi?
Andrew M.A. Cater wrote: Will it work fine over a serial console? Yes, vim works fine over a serial console. You might want to turn off part of the status line if using it at less than 9600 baud. Is it fine for ex-Solaris/HP-UX /AIX admins who may have got used to nvi? I imagine they might have gotten used to non-bash shells too; I don't think the goal of Debian is to exactly replicate those systems, and we should instead strive to pick default unix tools that are the commonly recognised best of breed today. -- see shy jo signature.asc Description: Digital signature
Re: switching to vim-tiny for standard vi?
Oh, another possible advantage to having vim-tiny in base is that it includes the vimtutor command, which is a fairly good way to learn how to use vim (or any vi; it avoids most vim-isms). The tutor is how I finally learned (to love) vi after years of badly using and loathing it as the base editor on other unixes. Having our base vi be self-teaching like that could be nice. -- see shy jo signature.asc Description: Digital signature
Re: Size matters. Debian binary package stats
On Sun, 18 Dec 2005 15:02:55 +0100 Steinar H. Gunderson [EMAIL PROTECTED] wrote: Not to mention that a DVD-R can fit about three million times as much data as a floppy disk, which was the dominant way of distributing software at the time. We can continue keep playing these number games, but I don't really see the point :-) Anyway, ~ 3 000 times, not ~ 3 000 000 times, sadly! -- Luca Brivio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: switching to vim-tiny for standard vi?
su, 2005-12-18 kello 14:57 -0500, Joey Hess kirjoitti: Yeah, I understand the feeling (coming at it from the exact opposite side). It would be helpful if there were an analysis of the major differences somewhere; the ones I am most aware of incude: I'm not personally very interested in this. If the size of vim-tiny is not bigger than nvi, I really couldn't care less which one is the default. Either is good enough as a vi clone for base; the incompatibilities are small enough not to matter for that case. I don't want to spend any effort (again, personally) in convincing people to switch their preferred editor, or preferred vi clone. That being said, I'd like to point out the minor error in the list you wrote so far: - vim supports multiple levels of undo; in nvi the second undo undoes your undo In nvi, to undo more than one level, you use the repeat last edit command (bound to period); u undoes an undo (and period after that repeats, so undoes further undos). For some people this is quite logical, and it drives other people nuts. IIRC the reason we have a vi in base, and at priority important at that is because of the definition in policy that: `important' Important programs, including those which one would expect to find on any Unix-like system. If the expectation is that an experienced Unix person who found it missing would say What on earth is going on, where is `foo'?, it must be an `important' package. Which of course includes a vi. (Note that the paragraph goes on to explicitly rule out emacs.) In the name of reducing base's size, I would support a policy change here, excempting vi clones, but I suspect I'd be shouted down. Personally, I think standard would be the appropriate priority for for the vi clone. -- Fundamental truth #2: Attitude is usually more important than skills. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: switching to vim-tiny for standard vi?
Lars Wirzenius wrote: In the name of reducing base's size, I would support a policy change here, excempting vi clones, but I suspect I'd be shouted down. Personally, I think standard would be the appropriate priority for for the vi clone. In which case it wouldn't really reduce base's size, since standard is installed anyway on (most) systems. -- see shy jo signature.asc Description: Digital signature
Re: Size matters. Debian binary package stats
On Sun, Dec 18, 2005 at 09:08:21PM +0100, Luca Brivio wrote: Not to mention that a DVD-R can fit about three million times as much data as a floppy disk, which was the dominant way of distributing software at the time. We can continue keep playing these number games, but I don't really see the point :-) Anyway, ~ 3 000 times, not ~ 3 000 000 times, sadly! Oops. Oh well, good thing the error consisted of zeros only ;-) /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: xmcd
On Sun, Dec 18, 2005 at 15:40:46 +0100 (+0100), Elimar Riesebieter wrote: On Sun, 18 Dec 2005 the mental interface of adrian told: [snip] Hi, sorry for not responding earlier, I've less and less time for Debian stuff as time goes by (busy). There are substantial changes upstream in v3 - not least of which involves some distinctly non-free add-ons. Do you mean the cdda-gracenote stuff? mp3- and faacencoding can be suppressed while buildtime. Yep. I hadn't investigated it fully, just marked it as a concern. xmcd also seems to be a bit clunky cf some other players out there. OTOH I suppose it supports some hardware that others don't (jukeboxes mainly). Adrian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Size matters. Debian binary package stats
On Sun, Dec 18, 2005 at 08:23:56PM +0100, Olaf van der Spek wrote: Why would that stop working if you switch compression schemes? I guess tar is coded to use gzip with -z and bzip2 with -j, but why is there no generic way to add coders/decoders (codecs) to tar (and other applications that wish to use compression filters)? Get real. gzip is probably understood by 99.9% of all installed UNIX systems in the world, and you cannot possibly hope to get anywhere near that for a relatively obscure alternative. (The -j flag to tar is a Debian specific extension, BTW -- I'm not sure if the -z flag is a GNU-specific extension, but it wouldn't surprise me.) /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /run vs /var/run (was: Please test new sysvinit)
On Sat, Dec 17, 2005 at 06:09:05PM -0600, Peter Samuelson wrote: Given the need, and now the reality, of /run, is there any need for a separate /var/run? I vote we migrate to /var/run - /run, at least in the default install. If /run is tmpfs, it means everything stored there eats virtual memory. So a musch metter strategy would be to move everything from /run to /var/run at the end of the boot process. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences -
Re: /run vs /var/run
[EMAIL PROTECTED] (Marco d'Itri) writes: On Dec 18, Thomas Hood [EMAIL PROTECTED] wrote: FWIW I asked Chris Yeoh for his opinion on the name and he said that /run sounded preferable to both /etc/run and /lib/run. Competition with /root in tab-completion, for a start. Under what circumstances would you be typing /rTAB rather than ~/ ? 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: switching to vim-tiny for standard vi?
Graham Wilson [EMAIL PROTECTED] writes: On Sun, Dec 18, 2005 at 06:54:42PM +, Andrew M.A. Cater wrote: Count me as an nvi person. Vim is great - but not as the default in the most basic system, no matter how stripped down. Why is nvi better if the size of nvi and vim-tiny are comparable? Among other things, because it doesn't do the obnoxious auto-indent thing that you have to work around with :set paste. I have no objections to vim as an editor, but it would be nice for vi to be, er, vi. vim isn't really vi; it's something that was originally based on vi and is now something slightly different. (Of course, nvi isn't exactly vi either, but it's a lot closer.) This isn't really new information. I guess I'm just speaking up to represent those people who do indeed care about tighter compatibility to the original vi than vim offers. I won't lose lots of sleep if I lose this argument. :) -- 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: Size matters. Debian binary package stats
On 12/18/05, Steinar H. Gunderson [EMAIL PROTECTED] wrote: On Sun, Dec 18, 2005 at 08:23:56PM +0100, Olaf van der Spek wrote: Why would that stop working if you switch compression schemes? I guess tar is coded to use gzip with -z and bzip2 with -j, but why is there no generic way to add coders/decoders (codecs) to tar (and other applications that wish to use compression filters)? Get real. gzip is probably understood by 99.9% of all installed UNIX systems in the world, and you cannot possibly hope to get anywhere near that for a relatively obscure alternative. (The -j flag to tar is a Debian specific extension, BTW -- I'm not sure if the -z flag is a GNU-specific extension, but it wouldn't surprise me.) I guess what I'm asking is, why are tar and other applications using gzip instead of a generic library that handles all compression/decompression and can be easily extended.
Re: /run vs /var/run (was: Please test new sysvinit)
On Sun, Dec 18, 2005 at 04:50:33AM +, Matthew Garrett wrote: Steve Langasek [EMAIL PROTECTED] wrote: On Sun, Dec 18, 2005 at 03:57:35AM +, Matthew Garrett wrote: Under Linux, can't all of this be done with mount --move anyway? I'm not convinced that we actually need a /run any more. So you would have these files stored in /var/run from the beginning, and use mount --move to shuffle them around if /var is a separate mount point? I'm pretty sure --move is a 2.6-only feature, too, and we haven't yet gotten rid of 2.4 for etch; and is there an equivalent solution for non-Linux ports? Yeah, it's 2.6 only. Are we seriously expecting to ship etch with 2.4 kernels? Is anyone still doing active security support for it? I'm eager to be able to drop 2.4 for etch, but I don't think it's completely clear yet whether the hardware support in 2.6 will be broad enough to meet users' needs. I expect we'll need to work with porters over the next months to begin pruning architectures from the 2.4 tree, and evaluate what's left at the end. Yes, lack of active security support for 2.4 is a concern. Also, bear in mind that even if 2.4 isn't shipped with etch, we still have to provide an upgrade path for users of sarge, so some thought would need to go into what that would look like. The linux-onlyness of it is a bit more awkward, but non-Linux OSs tend to be lacking things like decent ram filesystems anyway, so the semantics are going to vary in any case. But I guess if it's difficult, sticking with /run might be easier. Has anyone talked to the FHS guys about this? (I haven't actually checked whether it's in there, so the answer may well be yes :) ) I'm not sure if anyone has talked to the FHS folks lately about this, no. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Size matters. Debian binary package stats
Steinar H Gunderson [EMAIL PROTECTED] writes: On Sun, Dec 18, 2005 at 08:23:56PM +0100, Olaf van der Spek wrote: Why would that stop working if you switch compression schemes? I guess tar is coded to use gzip with -z and bzip2 with -j, but why is there no generic way to add coders/decoders (codecs) to tar (and other applications that wish to use compression filters)? Well, tar supports --use-compress-program. [...] (The -j flag to tar is a Debian specific extension, BTW No, the Debian extension was -I (and even that was present for a while in upstream). It was changed to -j because that's what upstream did. The -j flag is present upstream as of 1.13.18. -- 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: Size matters. Debian binary package stats
On Sun, Dec 18, 2005 at 10:15:31PM +0100, Olaf van der Spek wrote: I guess what I'm asking is, why are tar and other applications using gzip instead of a generic library that handles all compression/decompression and can be easily extended. General complexity, I'd guess. If you want “easily extended”, you'll have to cope with dynamic, shared libraries -- look to NSS for a case on how evil that can get. (And tar is really something you'd like to stay small and simple.) Also, having to hunt down the right plug-in module for whatever format somebody had the bright idea to use at some point can be a real pain. (Ever had to use one of those “codec packs” for Micosoft Windows?) Besides, UNIX does this a different way, traditionally -- via separate programs. “gzip -d file.tar.gz ; tar xf file.tar” gives you most of the same functionality, with zero extra complexity. (Try --use-compress-program in GNU tar, but that probably doesn't exist in anything else.) /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: switching to vim-tiny for standard vi?
On Sun, Dec 18, 2005 at 02:57:17PM -0500, Joey Hess wrote: Lars Wirzenius wrote: I'm one of the people who prefers nvi over vim. I do so quite strongly, because I find that nvi obeys my fingers and vim does not. The differences are minute, of course, but they are really irritating. Unfortunately, I can't enlist them properly, since my fingers don't talk to me: I notice vim's incompatibility from the fact that my fingers have to keep correcting text under vim, but not under nvi. On days when I'm generally annoyed already, if I accidentally use vim instead of nvi, I can get quite lyrical with my cursing. Yeah, I understand the feeling (coming at it from the exact opposite side). It would be helpful if there were an analysis of the major differences somewhere; the ones I am most aware of incude: :set compatible will switch Vim's behavior for all of these, except for: - in vim the arrow keys always move around even in insert mode. In nvi they do too (surely it diverges from real vi here?), but if you arrow to the end of a line, it flashes the screen and drops you out of insert mode. In compatible, arrow keys don't work at all in insert mode, like vi (set esckeys to revert). I'm not sure how to get the moving cursor past the end of line drops out of insert mode behavior. - some commands like 'cw' display differently in vim, although the end result of the keystrokes is the same for all the standard vi commands I use (don't know) - nvi flashes the screen/bell when a command fails; vim does not :set visualbell -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /run vs /var/run (was: Please test new sysvinit)
On Sun, Dec 18, 2005 at 05:24:40PM +0100, Marco d'Itri wrote: Reality check: packages have been using it for a long time and the world has not fallen yet. Emphasis on yet. /dev/shm was created to be used uniquely by shm_open(), and violating this _will_ cause some problems after a certain level of abuse. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences -
Re: /run vs /var/run (was: Please test new sysvinit)
On Sun, Dec 18, 2005 at 01:03:37PM -0500, Joe Smith wrote: 1. POSIX (or at least SuS v3) does not gaurentee the existence of /dev/shm, or that if it does exist, that it can be be read as a block device, or that if it can, it has a file system on it. AFAIK /dev/shm is just an internal detail of glibc's implementation of shm_open() on Linux 2.6 kernels, so it has nothing to do with POSIX. 2. Neither does FHS. Ditto. 1. It exists only on Linux-based OS's 2. There is no gaurentee that it will continue to be there at all 3. There is no guareteee that it will remain a filesystem in the future even if it is there. 4. There is no gaurentee that it exists at all. Yep. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: switching to vim-tiny for standard vi?
Glenn Maynard wrote: :set compatible will switch Vim's behavior for all of these, except for: Nope, I was running vim in compatible mode (the default without a ~/.vimrc) for all of them. In compatible, arrow keys don't work at all in insert mode, like vi (set esckeys to revert). They do here. -- see shy jo signature.asc Description: Digital signature
Re: switching to vim-tiny for standard vi?
On Sun, Dec 18, 2005 at 06:54:42PM +, Andrew M.A. Cater wrote: Will it work fine over a serial console? Is it fine for ex-Solaris/HP-UX /AIX admins who may have got used to nvi? As an ex-Solaris/AIX admin I can say that I used vim there too (except when the filesystem containing vim did not come up for some reason :-) And yes, it works fine on a real vt220. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /run vs /var/run (was: Please test new sysvinit)
[Anthony Towns] I realise your heart's set on /run, but is there any possibility of putting it under /lib/run or /boot/early-writable-fs instead of introducing a new directory on / that's of very limited use? /lib is no more appropriate than /sbin. That it is already overloaded in the FHS to mean libraries, executables and data does not excuse putting, effectively, temporary files there. If anything, /etc/run, since /etc used to be the preferred dumping ground for things which have now moved to /dev/shm (ick) and /run. Peter signature.asc Description: Digital signature
Re: switching to vim-tiny for standard vi?
On Sun, Dec 18, 2005 at 04:44:13PM -0500, Joey Hess wrote: Glenn Maynard wrote: :set compatible will switch Vim's behavior for all of these, except for: Nope, I was running vim in compatible mode (the default without a ~/.vimrc) for all of them. /etc/vim/vimrc sets nocompatible, among other things. Comment that out, or run :set compatible. -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: switching to vim-tiny for standard vi?
On Sun, Dec 18, 2005 at 03:05:40PM -0500, Joey Hess wrote:
Oh, another possible advantage to having vim-tiny in base is that it
includes the vimtutor command, which is a fairly good way to learn how
The vimtutor content is not available if vim-runtime is not installed,
and it wont be in the base system ('vim-runtime' is the huge 13 Mb
monster package).
--
Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy
[EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/
If there's any real truth it's that the entire multidimensional infinity
of the Universe is almost certainly being run by a bunch of maniacs. -!-
signature.asc
Description: Digital signature
Re: switching to vim-tiny for standard vi?
On Sun, Dec 18, 2005 at 01:11:32PM -0800, Russ Allbery wrote: Among other things, because it doesn't do the obnoxious auto-indent thing that you have to work around with :set paste. I have no objections to vim Well, this is a matter of configuration, not really a matter of editor. Debian's vim has autoindent enabled in system-wide vimrc, but it can be disabled. -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. -!- signature.asc Description: Digital signature
Re: Size matters. Debian binary package stats
On 12/18/05, Steinar H. Gunderson [EMAIL PROTECTED] wrote: On Sun, Dec 18, 2005 at 10:15:31PM +0100, Olaf van der Spek wrote: I guess what I'm asking is, why are tar and other applications using gzip instead of a generic library that handles all compression/decompression and can be easily extended. General complexity, I'd guess. If you want easily extended, you'll have to cope with dynamic, shared libraries -- look to NSS for a case on how evil that can get. (And tar is really something you'd like to stay small and simple.) Also, having to hunt down the right plug-in module for whatever format somebody had the bright idea to use at some point can be a real pain. (Ever had to use one of those codec packs for Micosoft Windows?) Besides, UNIX does this a different way, traditionally -- via separate programs. gzip -d file.tar.gz ; tar xf file.tar gives you most of the same functionality, with zero extra complexity. (Try --use-compress-program in GNU tar, but that probably doesn't exist in anything else.) I guess that's even easier. Just use/write a filter that looks at the header and invoke the right coder/decoder internally.
Re: congratulations to our ftp-master team
Russ Allbery [EMAIL PROTECTED] writes: Thomas Bushnell BSG [EMAIL PROTECTED] writes: Russ Allbery [EMAIL PROTECTED] writes: Anand Kumria [EMAIL PROTECTED] writes: A simple assurance that your package will be rejected from the NEW queue if no ftp-master approves it within 2 weeks would actually be a benefit. Why? It seems like, if that's the way that you want the world to work, you could already just pretend that this is the case. If your package has gone for more than two weeks, it seems to me like you could decide to treat it in all respects as if it had been rejected and just go on with your life. If it ends up getting accepted, you could orphan it, or decide to pick it up again. When the ftp masters reject a package, they say why it has been rejected as a rule. So at least that part can't be substituted for in this way. Yes, but that's a different conversation. Anand didn't say anything about getting a reason. The proposal was that packages be automatically rejected if no ftp-master approves it within two weeks. I don't understand how that helps anyone. You still don't get any explanation, and now there's not even a chance someone will find time to look at it. Oh, I was taking automatically rejected as a statement of the policy, not the mechanism. I was assuming that the rejections would still happen in the usual way. I agree that if they are mechanical, then they are pointless. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#343940: ITP: gecode -- generic constraint development environment
Package: wnpp Severity: wishlist Owner: Kari Pahula [EMAIL PROTECTED] * Package name: gecode Version : 1.0.0 Upstream Author : Christian Schulte [EMAIL PROTECTED] and others * URL : http://www.gecode.org/ * License : BSD Description : generic constraint development environment Gecode is an attempt to construct an open, free, portable, accessible, and efficient environment for developing constraint-based systems and applications. Gecode is radically open for programming: it can be easily interfaced to other systems. It supports the programming of new propagators (as implementation of constraints), branching strategies, and search engines. New variable domains can be programmed at the same level of efficiency as finite domain and integer set variables that come predefined with Gecode. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.14 Locale: LANG=C, [EMAIL PROTECTED] (charmap=ISO-8859-15) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: xmcd
On Sun, 18 Dec 2005 the mental interface of adrian told: On Sun, Dec 18, 2005 at 15:40:46 +0100 (+0100), Elimar Riesebieter wrote: On Sun, 18 Dec 2005 the mental interface of adrian told: [snip] Hi, sorry for not responding earlier, I've less and less time for Debian stuff as time goes by (busy). There are substantial changes upstream in v3 - not least of which involves some distinctly non-free add-ons. Do you mean the cdda-gracenote stuff? mp3- and faacencoding can be suppressed while buildtime. Yep. I hadn't investigated it fully, just marked it as a concern. xmcd also seems to be a bit clunky cf some other players out there. OTOH I suppose it supports some hardware that others don't (jukeboxes mainly). Hmm, to build the CDDB² we have to use the only as binaries available http://www.ibiblio.org/tkan/download/cddb2supp/3.3.0/lib/linux-x86-libc5/cddb2supplib.tar.gz but we won't ;) The pure cddb as in versions 2.* is used by http://www.ibiblio.org/tkan/download/xmcd/3.3.2/src/xmcd-3.3.2.tar.gz so I don't see a reason to not upgrade the package yet? Could someone please check xmcd from my small repos at deb http://www.lxtec.de/debarchiv binary-i386/ deb-src http://www.lxtec.de/debarchiv sources/ It is build without lame and faac encoding yet, but why not? Elimar -- Excellent day for drinking heavily. Spike the office water cooler;-)
Re: /run vs /var/run (was: Please test new sysvinit)
This one time, at band camp, Marco d'Itri said: On Dec 18, Thomas Hood [EMAIL PROTECTED] wrote: FWIW I asked Chris Yeoh for his opinion on the name and he said that /run sounded preferable to both /etc/run and /lib/run. Competition with /root in tab-completion, for a start. Well, that's certainly a much more important reason than all the other things mentioned so far. Not. -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: /run vs /var/run
In article [EMAIL PROTECTED] you wrote: If /run is tmpfs, it means everything stored there eats virtual memory. So a musch metter strategy would be to move everything from /run to /var/run at the end of the boot process. tmpfs stores run ressources in vm more efficiently (since they are otherwise in th buffercache and the filesystem). And you cant really move the run ressources. I vote for having run a tmpfs and having /var/run - symlinked to /run. Gruss Bernd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: udev event completion order (was: Re: Debian Installer team monthly meeting minutes (20051214 meeting))
On Sun, Dec 18, 2005 at 09:52:42AM +0100, Marco d'Itri wrote: On Dec 18, Darren Salt [EMAIL PROTECTED] wrote: An alternative appears to be to process events in series... or maybe delaying This was the precedent approach, and it's much slower (also, it cannot be implemented anymore with just udevd). Right, you could request event-by-event from the kernel and wait for it to finish for devices that you know to have initialized first, but that sounds like a bad idea. The whole device enumeration by module load order-thing never worked too reliably and will never work again. Everybody just needs to get used to the fact that while you can add and remove devices at any point in time from a running system, it can never give predictable simple enumerations, like the kernel names are. We implemented persistent device links for disks, which is on almost all distros today and SUSE has persistent network device names implemented by automatically writing udev rules from the device event. Persistent naming is the way to go and to work on improving and extending the current system. The /dev/disk/* link model should work for other subsystems in a similar way, it's just that somebody needs to do it. :) There is also the plan to do parallel device probing inside the kernel some day, that will make the situation of relying on kernel names even more fragile. I will remove the %e from the udev rules some day too, cause it never worked correctly outside of udevstart and udevstart is also no longer recommended to use cause you can't match on event properties which are only available from the event itself but not in sysfs. Thanks, Kay -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
