Re: systemd^wfoo on linux, bar on bsd,so what (Re: /bin/sh (was Re: jessie release goals)
On Fri, 17 May 2013 13:42:30 +0200, Holger Levsen hol...@layer-acht.org wrote: On Freitag, 17. Mai 2013, Marc Haber wrote: We're going to have a TC decision or a GR about this anyway. why do you think so? Because I think that a decision of this magnitude should not be taken by a single developer, not even by M'd. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1udpo2-0006gy...@swivel.zugschlus.de
Re: systemd^wfoo on linux, bar on bsd,so what (Re: /bin/sh (was Re: jessie release goals)
On Mon, 13 May 2013 02:31:02 +0200, m...@linux.it (Marco d'Itri) wrote: Maybe kfreebsd will do, but as I explained at FOSDEM I plan to make udev depend on either upstart or systemd. I would rather not be the one who will choose which one of them, so I hope that we will get to a consensus about this. We're going to have a TC decision or a GR about this anyway. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1udesn-0006mx...@swivel.zugschlus.de
Re: systemd^wfoo on linux, bar on bsd,so what (Re: /bin/sh (was Re: jessie release goals)
Hi Marc, On Freitag, 17. Mai 2013, Marc Haber wrote: We're going to have a TC decision or a GR about this anyway. why do you think so? cheers, Holger signature.asc Description: This is a digitally signed message part.
Re: /bin/sh (was Re: jessie release goals)
On 2013-05-07 14:23:47 +, Thorsten Glaser wrote: Shells suitable for /bin/sh are currently bash, dash, mksh. I forgot about that (partly because of workarounds), but due to the SIGINT problem, I think that *currently*, among these 3 shells, bash is the most suitable one, and mksh is a bit better than dash. Indeed /bin/sh is used by system(), meaning that in particular, it is often executed to run interactive programs, some of which trapping SIGINT. If the shell doesn't implement WCE[*], one may get spurious failures (e.g. when Ctrl-G is typed in some versions of Emacs, Ctrl-C in gdb, etc.). [*] http://www.cons.org/cracauer/sigint.html AFAIK, only bash and ksh93 implement WCE. And mksh has an optimization so than when the mksh -c string consists of only one command, the problem doesn't occur (because in such a case, the shell does not fork, but exec's the command, so that the shell is no longer involved when the signal is sent). I believe posh can be made suitable with a bit of hacking it (e.g. adding fixes from mksh) and coreutils moving /usr/bin/printf to /bin/printf (best way out of the Md issue, really). But posh doesn't implement WCE either. My bug reports: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=683671 for dash http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=708633 for posh http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=708634 for mksh -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130517132350.ga10...@ypig.lip.ens-lyon.fr
Re: /bin/sh (was Re: jessie release goals)
On Sat, May 11, 2013 at 05:29:45PM +0200, Sven Joachim wrote: On 2013-05-11 11:22 +0200, Goswin von Brederlow wrote: While that might be of some interest the real goal of the change was to be able to have more than *2* packages provide /bin/sh. Currently, due to the totaly screwed up way this is done, only dash or bash can be /bin/sh. I think that dash could probably stop diverting /bin/sh, now that bash no longer ships it (as of version 4.2-1). That would make it possible to locally divert /bin/sh for those who want it (#538822, #540512). Double that for multiarch on amd64/i386 because there is bash:i386 and bash:amd64 that both work just fine as /bin/sh. Trying to install a foreign bash or dash fails horribly though with the current diversion hack. Huh? No it doesn't, dpkg handles this just fine (apt doesn't because it does not support crossgrades, but that is another story). Make sure you have dpkg = 1.16.2, though. When I checked that last the mainatienr scripts would fail horribly because you can't have a thrid package doing a diversion. Dpkg never was a problem in itself. Proposed solution: - New virtual package system-shell with something essential depending on it (base-files?) Would probably need pre-depends so that system-shell cannot be removed temporarily (similar situation as with awk). Yes, verry similar. I actualy would like the same solution for awk to fix the problem that during bootstrap there is no awk link. - bash, dash pre-depend on system-shell for the transition - new packages system-shell-name Provides, Replaces, Conflicts: system-shell contains /bin/sh - /bin/name symlink None of system-shell-* would be essential but through the dependency of something essential at least one would always be installed (pseudo-essential). One of them (system-shell-dash) should have a higher priority than the rest to be singled out as the default and the essential package would depend system-shell-dash | system-shell. Choosing /bin/sh is then simply done by installing the right package and dpkg does the change atomically. Only if the packages declare Conflicts/Replaces on every real provider of system-shell, and with apt you lose outright because it insists on removing the conflicting package(s) first. We worked out the system during the second last Debconf, so nearly two years ago. I would have to look up my notes at home but that wasn't a problem. The virtual package works just fine as placeholder for all real packages since they all provide it. And about the removing the conflicting package(s) first I'm not sure if that wasn't an issue because system-shell is a virtual package or if the solution was to use Break/Replaces. But it worked in the right order with a set of dummy packages we made to test the solution. No messing around in pre/postinst/rm scripts or race conditions where the link might disapear for a while. No artificial limit on how many system-shell-* packages there could be. I'm afraid your plan as outlined is not going to work. Cheers, Sven This was just a loose summary of the general idea from memory. I might not have expressed all the finer details (correctly) but the solution we came up with worked. The details also include a bunch of tricky hacks to reassign the diversion during the initial upgrade so that at no time the /bin/sh link disapears. That was actualy the hardest part to figure out. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130516103544.GE2181@frosties
Re: /bin/sh (was Re: jessie release goals)
On Sun, May 12, 2013 at 02:40:39AM +0100, Wookey wrote: +++ Steve Langasek [2013-05-11 09:33 -0700]: On Sat, May 11, 2013 at 11:22:10AM +0200, Goswin von Brederlow wrote: While that might be of some interest the real goal of the change was to be able to have more than *2* packages provide /bin/sh. Currently, due to the totaly screwed up way this is done, only dash or bash can be /bin/sh. This is not a sensible goal. Choice of /bin/sh should *not* be the goal, the goal should be to get a good, fast, minimal, policy-compliant /bin/sh for *everyone*. See also: Linux is not about choice. All this added complexity to provide users a choice about something that doesn't matter undermines the robustness of the base system. Please stop. Yes, the diversion hack should be superseded by a single, static symlink belonging to the dash package, and the rest of this pointless complexity should be jettisoned. I'm very keen to lose the diversion hack. It causes pain for cross-debootstrapping, especially on embedded images. If /bin/sh is no longer a diversion by dash/bash then that frees up the use of diversions for the admin or other packages. So that works too. Someone would need to make a case for replacing dash as /bin/sh. What do we get for enabling /bin/mksh fill that role too, for example? If it really is just better then why not just swap from dash to mksh and everyone can benefit? So lets say I'm convinced mksh is the better /bin/sh for everyone. How do I test that it actualy works at all? How do I get other people to test? Currenlty there is no way to say: Here, try installing this packages and report if anything breaks. Swappable system shells is a nice idea, but Steve is right that it's a critical thing that really does need to work so there has to be some real gain from futzing with it. If it can be done cleanly then great. If not then lets see if we can't just pick one (almost) everyone can live with. Wookey Problem is Debian picked *2* and both created a diversion on /bin/sh and play ping-pong with that. At the time the system-shell-* solution was considered there was no way for e.g. bash to not ship /bin/sh. It seems now that has changed so yeah, maybe we can go to just simply a plain /bin/sh. Then people that want a different /bin/sh, and there are those, are free to use diversions again. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130516104405.GF2181@frosties
Re: /bin/sh (was Re: jessie release goals)
On Sat, May 11, 2013 at 08:44:30PM +0100, Roger Leigh wrote: On Sat, May 11, 2013 at 08:52:29PM +0200, Josselin Mouette wrote: Being able to choose between two entirely different desktop environments, with different user experiences, is a good thing. Being able to choose between two /bin/sh shells or two /sbin/init implementations is not. The shell I can agree with. It is required to provide a POSIX shell, so as long as it is fully functional and performs well, just picking one and sticking with it is absolutely fine. You are disagreeing with yourself, kind of. If there is only exactly one system shell and everything is tuned to work with only that one system shell then the system will no be for a POSIX shell but for THAT shell. The history with bash as /bin/sh has proven that. The only realistic way to keep scripts compatible with a POSIX shell is to have multiple shells that have POSIX as common base. So be truthfull and say you are fine with picking XYZ as system shell and have everything rely on sh being XYZ. I also disagree with the assumption that being able to choose a system shell is a bad thing. I actualy find it kind of important. By picking dash as /bin/sh (and it isn't going to go back to bash, right?) you are forcing dash to be installed. Also bash practically has to be installed simply because dash as interactive shell for users sucks. For a Debian derivativ aimed at some embedded platform it might be far better to simply have one shell that works for both /bin/sh and interactive user shells. This would be greatly simplified by having more than one choice for the system shell in Debian. Support for other shells would be better tested and easier to maintain over time. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130516110324.GG2181@frosties
Re: /bin/sh (was Re: jessie release goals)
On Sun, May 12, 2013 at 02:40:39AM +0100, Wookey wrote: +++ Steve Langasek [2013-05-11 09:33 -0700]: On Sat, May 11, 2013 at 11:22:10AM +0200, Goswin von Brederlow wrote: While that might be of some interest the real goal of the change was to be able to have more than *2* packages provide /bin/sh. Currently, due to the totaly screwed up way this is done, only dash or bash can be /bin/sh. This is not a sensible goal. Choice of /bin/sh should *not* be the goal, the goal should be to get a good, fast, minimal, policy-compliant /bin/sh for *everyone*. See also: Linux is not about choice. All this added complexity to provide users a choice about something that doesn't matter undermines the robustness of the base system. Please stop. Yes, the diversion hack should be superseded by a single, static symlink belonging to the dash package, and the rest of this pointless complexity should be jettisoned. I'm very keen to lose the diversion hack. It causes pain for cross-debootstrapping, especially on embedded images. Someone would need to make a case for replacing dash as /bin/sh. What do we get for enabling /bin/mksh fill that role too, for example? If it really is just better then why not just swap from dash to mksh and everyone can benefit? Nobody wan't to mess with the default (yet). Swappable system shells is a nice idea, but Steve is right that it's a critical thing that really does need to work so there has to be some real gain from futzing with it. If it can be done cleanly then great. If not then lets see if we can't just pick one (almost) everyone can live with. Wookey The current diversion hack is insane. That certainly needs to go. I hope everyone can agree on that. The system-shell idea is a way out of that without loosing the choice what /bin/sh shall be. Currently that choice is between bash and dash. Picking just dash as /bin/sh would be an (acceptable) regression since it would open back the possibility to diver the shell locally (or by other packages). I like the system-shell idea better because it is cleaner (less likely to break) than diverting /bin/sh (both locally and by packages). Note: it would also allow changing the shell (in debian or in derivatives) in the future without running into the same diversion problems again. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130516112005.GI2181@frosties
Re: /bin/sh (was Re: jessie release goals)
Hi Thorsten On 11-05-13 20:26, Thorsten Glaser wrote: Steve Langasek vorlon at debian.org writes: This is not a sensible goal. Choice of /bin/sh should *not* be the goal, the goal should be to get a good, fast, minimal, policy-compliant /bin/sh for *everyone*. Sure. We just disagree which one that is. See also: Linux is not about choice. Debian is not just about Linux. While a choice of $SHELL is useful for a user and something we should support (through things like chsh), I fail to see how a choice of /bin/sh is extremely critical. I also fail to see how the above statement factors in this entire discussion. Oh, sorry, I forgot, you work for Canonical (which totally explains some of your writings in the other eMail too, which I’m not going to comment on). Of course, for *buntu people it’s not about choice. This is an ad-hominem attack, which has no place on -devel. Please take that elsewhere (/dev/null, preferably). [...] In Debian, Developers are also users, and it can only be the UNIVERSAL operating system when there is choice. Wrong. Yes, the diversion hack should be superseded by a single, static symlink belonging to the dash package Why dash? It’s clearly inferiour, buggy and not taken care of well. Because at the time this decision was taken, dash was the only available candidate. [...] choose their system shell. I don’t even care about the default, I’d be happy were it mksh or mksh-static of course, but I don’t. And I’ve successfully run both Debian and Kubuntu with mksh as system shell.) All else being equal, you're right that a choice of shell for /bin/sh is a good thing, and you're also right that changing /bin/sh to some other implementation usually doesn't bring with it any negative effects once it's done. In fact, policy requires that this is possible. However, all else is *not* equal. Contrary to the awk situation, large parts of the Debian packaging format rely on /bin/sh functionalty, and will break (and leave the system in an inconsistent state) if /bin/sh is nonexistent at the wrong moment. I'm not saying it's impossible to implement this the right way, but doing so will cause a lot of pain and a lot of problems before we get there. That is precisely why the /bin/sh change was implemented with a diversion rather than an alternative; the latter is much more fragile and brings with it a much larger risk of screwing the user over and leaving them with a system that won't boot, and can't easily be fixed by just doing dpkg --configure -a. This is a *bad* thing. For an issue that few of our users care about, it is questionable to risk so much. In addition, people who know enough about the issue to want to switch /bin/sh away from dash and to another implementation usually also are knowledgeable enough to just call the ln -sf command manually. We might wish to document the circumstances under which this is a safe thing to do (and why the alternatives system isn't used), but that's about it. No, it is NOT about choice. It is about providing a high quality, free operating system to our users. This ridiculous complexity in /bin/sh But your users may have a more broad horizon than you, as Canonical employee, can imagine. Having met Steve in person and talked with him on multiple occasions, I can assure you that there are few people in Debian who have as broad an understanding of the needs of the Debian (and by extension, Free Software) community and its users. This remark is insulting and not based in fact. Please retract it. -- This end should point toward the ground if you want to go to space. If it starts pointing toward space you are having a bad problem and you will not go to space today. -- http://xkcd.com/1133/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5194c192.60...@debian.org
Re: /bin/sh (was Re: jessie release goals)
On 15-05-13 17:39, Thorsten Glaser wrote: As for your requests of data: I do not provide them. As I said above, I’m pushing for freedom of choice, not switching the default; of course I’d be happy with the latter, even more so actually, but it must be a thing not driven by me; I see. In that case, might I suggest a change of strategy? I understand your desire to not let your own biases get in the way of technically sound decisions (and that's admirable), but in this case, I think it's not the right thing to do. Providing freedom of choice for the system shell isn't something that's wanted by a lot of our users, and it isn't something you'll be likely to get many people to buy in to. On the other hand, if you manage to provide sound technical arguments as to why switching the system shell away from dash and to mksh might be a good idea, I don't see why we would reject it. We'd prefer to avoid having to do yet another switch, so the arguments would have to be fairly compelling; but if they are, hey, more power to you. If you're not really about choice but are about promoting mksh, then that's really what you'd like, too. [...] Using the diversion mechanism to change /bin/sh is highly risky and was never supported. Actually, dash uses a diversion too, so it was supported pretty well. Well, no, not really; it causes many problems... -- This end should point toward the ground if you want to go to space. If it starts pointing toward space you are having a bad problem and you will not go to space today. -- http://xkcd.com/1133/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5194c8ca.6090...@debian.org
Re: /bin/sh (was Re: jessie release goals)
On Wed, May 15, 2013 at 03:39:54PM +, Thorsten Glaser wrote: As for your requests of data: I do not provide them. As I said above, I???m pushing for freedom of choice, not switching the default; of course I???d be happy with the latter, even more so actually, but it must be a thing not driven by me; if there???s enough other people (especially DDs) interested in actually doing that it has potential to get taken a bit seriously at all; if I???m involved, all bets are off (especially now, I guess). There are two issues you mix here: 1) Using mksh as /bin/sh by default. I see no issue with you providing the data. If mksh provides significant benefits, I guess others will jump on the boat as well. Just make sure to include the method of measurement, so others can reproduce the results. If all else fails, your data probably points out some weaknesses in dash, that can result in a better dash. 2) Making /bin/sh configurable. As I and a number of others have explained already, this choice comes at a cost. I'm inclined to say that this cost is even higher than just changing /bin/sh globally. So for this you need even better arguments, since it is hard enough to clean the current mess. The approach to just do the work is indeed a good argument. If the bash maintainer has indeed remained silent on your present work, you might need to take other measures to fix this rc bug in dash. For instance the ctte can be asked for advice (as opposed to overruling a maintainer). Thanks for your work here, I have long dropped this ball after running into silence on other involved parties. Using the diversion mechanism to change /bin/sh is highly risky and was never supported. Actually, dash uses a diversion too, so it was supported pretty well. I was not precise enough here. With diversion mechanism I meant local (i.e. admin controlled) diversion. This is broken precisely because dash is currently (ab)using diversions to change /bin/sh. It was never supported in the sense, that we left the corresponding bug open all the time and changed the release notes instead. So we basically meant the same thing. Helmut -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130516110528.ga14...@alf.mars
Re: /bin/sh (was Re: jessie release goals)
On Tue, May 7, 2013 at 4:23 PM, Thorsten Glaser t...@debian.org wrote: Andreas Beckmann anbe at debian.org writes: now might be the right time to start a discussion about release goals for jessie. Here are some points that come into my mind right now (and * Resolve that /bin/sh issue (see the open RC bugs against dash which just got ignored for a stable release for the *second* time) e.g. by transitioning to Goswin’s system-shell-foo package, and then request (eventually require) packages to declare any dependencies on shell interpreters other than /bin/sh explicitly (begin by changing lintian to not warn about these as bash still and dash newly is Essential, then change Policy(IIRC) to request these dependencies to be explicit), so that jessie+2, if not jessie+1, can be run without dash and bash installed, which would mean encouraging maintainers of “core” tools to not depend on them for their maintainer scripts, init scripts, etc. (debootstrap would probably need to be adjusted to cope but we’ve got two releases time for that). Shells suitable for /bin/sh are currently bash, dash, mksh. I believe posh can be made suitable with a bit of hacking it (e.g. adding fixes from mksh) and coreutils moving /usr/bin/printf to /bin/printf (best way out of the Md issue, really). I believe ksh93 can be made suitably by making 'alias local=typeset' implicit like pdksh did. Solaris 11, OpenSolaris and Illumos use ksh93 as /bin/sh, /usr/bin/sh and /usr/bin/ksh, partially for the massive performance gain over the old Bourne shell and the busybox-like shell builtins (for example ksh93v- comes, among others, with basename cat chgrp chmod chown cksum cmp comm cp cut date dirname egrep expr fds fmt fgrep fold getconf grep head id join ln logname md5sum mkdir mkfifo mktemp mv paste pathchk printf rev rm rmdir stty sum sync tail tee tty uname uniq wc) as builtin, all conforming to the POSIX/SUSv4 standards (tested and certified!!), SystemV extensions and all extensions which are implemented by both GNU and BSD the same way if they do not violate POSIX/SUSv4 in the first place. Josh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caeemktpgvtozhjxjsosyyhhwsa6-pxxufnvqmg5h3mwcw1x...@mail.gmail.com
Re: /bin/sh (was Re: jessie release goals)
]] brian m. carlson On Wed, May 15, 2013 at 02:12:10AM +0200, Michael Biebl wrote: Am 15.05.2013 01:26, schrieb brian m. carlson: On Sat, May 11, 2013 at 10:08:21PM +0200, Josselin Mouette wrote: This is utter bullshit and you should already know it. Systemd is much more reliable as a whole than any other implementation. I have yet to see a use case where it is not better. It is not better if you don't want proprietary binary-format logs in /var/log with no documented way to turn them off. http://www.freedesktop.org/software/systemd/man/journald.conf.html Storage=none Silly me. I expected that if I installed systemd, that the appropriate man pages would be shipped with the package: As you might have noticed, we are not yet shipping the latest upstream version. Upstream has added more documentation in the meantime. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87txm4danb@qurzaw.varnish-software.com
Re: /bin/sh (was Re: jessie release goals)
]] brian m. carlson On Wed, May 15, 2013 at 02:29:40AM +0200, John Paul Adrian Glaubitz wrote: On 05/15/2013 02:16 AM, Michael Biebl wrote: Am 15.05.2013 01:26, schrieb brian m. carlson: On Sat, May 11, 2013 at 10:08:21PM +0200, Josselin Mouette wrote: This is utter bullshit and you should already know it. Systemd is much more reliable as a whole than any other implementation. I have yet to see a use case where it is not better. It is not better if you don't want proprietary binary-format logs in The format may be binary, but it certainly is not proprietary [1] I really can't believe people are still coming up with that non-sense. Maybe because I read it on LWN (http://lwn.net/Articles/468381/): All complaints about UUIDs were quickly overshadowed by another issue once the full proposal was posted: one might charitably say that there is not, yet, a consensus around the proposed new logfile format. In a sense, that is unsurprising, since that format is deliberately undocumented and explicitly subject to change at any time. You'll pardon me if I believe that LWN is a reputable source for information. This was approximately correct a year and a half ago. It's not correct today, partly because people did want the format to be documented and for it to settle down. I have no idea why people assume that a binary format means it can only be processed with a special, proprietary tool. Binary simply means what it means, binary and not text which means it's a more stream-lined and machine-readable format as opposed to a text format with no formatting at all. It means that it works completely differently from every existing Unix log parser on the planet. syslog is hardly no formatting at all. syslog and other log files isn't structured particularly well. And, when it comes to processing, binary data is actually *easier* to process. Everyone who has ever written a text parser themselves will agree. I have written several, and I still prefer plain text. I want to use the same tools to parse my logs that I have used for years, like logcheck. Text files is the Unix way. Nothing stops you from having plain text log files too while using the systemd journal. We're not planning on taking the old/regular-format files away. Adding the journal means you get more information, you get better searchability and so on. If you don't want that, turn it off. I want it, since it'll make it easier for me to manage my systems. Cheers, -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ppwsdahz@qurzaw.varnish-software.com
Re: /bin/sh (was Re: jessie release goals)
On Tue, May 14, 2013 at 08:59:57AM +, Thorsten Glaser wrote: Helmut Grohne helmut at subdivi.de writes: What are the benefits of using shells other than dash for /bin/sh? (as Why does dash get special treatment, anyway? It was ???suddenly??? in Debian after having been used in Ubuntu, but??? there never was an evaluation of shells. dash gets special treatment cause it is /bin/sh now. And that happened because at the time of evaluation it was deemed significantly better than bash. Which leads us to the real question: I still believe the codebase of mksh is better (modulo issues introduced due to the active development), but I???m happy with freedom to choose one???s own system shell??? Can you quantify those benefits of using mksh? To that end I propose a few questions, whose answers may help in this discussion. What issues of dash does mksh solve? How many users are affected? Is there a benefit in performance? How large is the margin? (asides from the two things you mentioned) From what you said I count your argument as a belief argument, because it came without data. Sorry. ??? or provide an mksh-static binary package. Which could also be used in initrd. Having the same shell for /bin/sh and the initrd actually is something that can reduce complexity. Did you talk to the initramfs maintainers about this idea? (Reference?) Most arguments and weighting of benefits and costs was already done by Russ Allbery and Steve Langasek, but one thing was not quite right: Using the diversion mechanism to change /bin/sh is highly risky and was never supported. Even if Debian only supports running dash (or bash) as /bin/sh and we ignore problems from broken scripts, there still is the breakage resulting from the diversion itself. As far as I can tell it still breaks dash upgrades in all cases. So even the ambitious user running mksh as /bin/sh and reporting patches for scripts using dashisms (I never imagined using that word), would be screwed with the next upgrade. From my point of view a change in handling /bin/sh is highly desirable precisely now, because we all know that the current way is broken and it was that way for two releases already. Fixing it will cause other problems (unless all involved parties are geniuses), so fixing it early in the release cycle is important. As far as I can tell from the huge bug log partial fixes are already in place and patches are available for the remainders[1]. IMHO go ahead an break sid now? Waiting longer means never fixing it or dragging it into the next freeze. [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=538822#289 Helmut -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130515065550.ga12...@alf.mars
Re: /bin/sh (was Re: jessie release goals)
Le mardi 14 mai 2013 à 23:26 +, brian m. carlson a écrit : For better or for worse, sysvinit provides a lot of modularity. systemd provides none of that modularity Maybe you should read a bit about systemd before saying such nonsense. The real-world systemd (not the imaginary software you keep criticizing) is much *more* modular than sysvinit. -- .''`. Josselin Mouette : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1368603484.23162.43.camel@pi0307572
Re: /bin/sh (was Re: jessie release goals)
On Sat, May 11, 2013 at 06:26:40PM +, Thorsten Glaser wrote: Oh, sorry, I forgot, you work for Canonical (which totally explains some of your writings in the other eMail too, which I’m not going to comment on). Of course, for *buntu people it’s not about choice. I think you are totally out of order, here. You could equally be criticised of having your judgement clouded by your involvement with MirOS. That would be just as absurd. Steve has been contributing to Debian much longer than you, or I have, or Ubuntu has existed. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130515091755.GC22791@debian
Re: /bin/sh (was Re: jessie release goals)
On 2013-05-07 14:23:47 +, Thorsten Glaser wrote: Shells suitable for /bin/sh are currently bash, dash, mksh. [...] I have no idea whether yash or zsh can be made suitable, but I think both could, if the maintainers and possibly upstream are interested. Though zsh has an option to emulate sh, it may still not be completely compatible. Upstream fixes incompatibilities when it is easy. But some incompatibilities may remain. If sh needs special multibyte (UTF-8) support for some features in UTF-8 locales, there may be a problem with zsh, as in sh emulation mode, multibyte support is completely disabled, and enabling it yields incompatibilities (that's why http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=659932 is still there). -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130515153344.gc24...@ypig.lip.ens-lyon.fr
Re: /bin/sh (was Re: jessie release goals)
Jonathan Dowland jmtd at debian.org writes: I think you are totally out of order, here. You could equally be criticised of having your judgement clouded by your involvement with MirOS. That would I admit being biased for that very reason. And that’s also the reason I try to push for freedom of choice, instead of for a change of the default. be just as absurd. Steve has been contributing to Debian much longer than you, or I have, or Ubuntu has existed. Okay, I accept this. Vorlon writes: A minimum demonstration of competence on the part of anyone proposing to change the shell again is to fix those RC bugs without introducing new ones. The problem here is communication. If you read the bug logs and, IIRC, mailing list maybe too, from that time, and ask Goswin how we tried to get a solution working during DebČevapćičiConf, you’ll find I tried precisely that. The dash maintainer agreed to try out the plan, but the bash maintainer IIRC never replied, and we suffered (and probably still do) from a shortage of people understanding debconf, diversions and other involved magic. So, please do not accuse me of not trying to fix that situation – yet there’s only ever so much a sole DD and a nōn-DD can do (why _is_ Goswin on hold, anyway?). Helmut writes: Did you talk to the initramfs maintainers I did not do that yet. As you can see, it’s hard enough to get taken seriously in the first place (see also #532324 which, by the way, I got told by several other DDs after the CTTE non-ruling that they agree with me). As for your requests of data: I do not provide them. As I said above, I’m pushing for freedom of choice, not switching the default; of course I’d be happy with the latter, even more so actually, but it must be a thing not driven by me; if there’s enough other people (especially DDs) interested in actually doing that it has potential to get taken a bit seriously at all; if I’m involved, all bets are off (especially now, I guess). Using the diversion mechanism to change /bin/sh is highly risky and was never supported. Actually, dash uses a diversion too, so it was supported pretty well. As for “breaking sid”: Yes please. The current diversion that’s already in place prevents another diversion being set, so the only way for squeeze and up for an admin to change their local system shell is to run sudo ln -sf mksh-static /bin/sh (and one for sh.1.gz manpage) and reapply that occasionally after upgrades (of dash only, from what I can gather). And with that, here comes Vorlon again. I see you have facts about the history for me; these are welcome. I think that’s my karma quota for the day; have a nice evening everyone! bye, //mirabilos ObCAPTCHA: earthward (I think Wouter’s sig quote was added automatically, but GMane offering this one to me now is just funny.) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/loom.20130515t172855-...@post.gmane.org
Re: /bin/sh (was Re: jessie release goals)
On 05/14/2013 06:07 PM, Philip Hands wrote: He missed the fact that you were contrasting one non-crashing init, that is capable of restarting dead services, with another non-crashing init setup that is not able to do so (without help). Oh, indeed I missed that point! Thanks Phil. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5193b8c5@debian.org
Re: /bin/sh (was Re: jessie release goals)
On 05/15/2013 05:52 AM, Vincent Bernat wrote: I have still hard time to consider that you absolutely did not mention something related to a bootloader. I believe Phil Hands explained better than I would what I tried to explain. On 05/15/2013 05:52 AM, Vincent Bernat wrote: Like in the previous discussions, you use some twisted tactics to make the consensus difficult to reach I can assure you that I don't have such intention. I'm not trying to make the consensus difficult to reach, at least not through this list : I hope that OpenRC being a workable solution will make it harder to choose though, since I like it a lot and that it will work for kFreeBSD and Hurd, though until then, it's pointless to argue for it, so I'm trying (hard) not to do it... :) Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5193b927.1090...@debian.org
Re: /bin/sh (was Re: jessie release goals)
Am 15.05.2013 02:12, schrieb Michael Biebl: Am 15.05.2013 01:26, schrieb brian m. carlson: On Sat, May 11, 2013 at 10:08:21PM +0200, Josselin Mouette wrote: This is utter bullshit and you should already know it. Systemd is much more reliable as a whole than any other implementation. I have yet to see a use case where it is not better. It is not better if you don't want proprietary binary-format logs in /var/log with no documented way to turn them off. http://www.freedesktop.org/software/systemd/man/journald.conf.html Storage=none And I forgot to mention: systemd is one of the best, if not the best documented open source project I've seen so far. From man pages to blog stories to wiki pages, it's simply amazing how much effort upstream, especially Lennart, is invensting into great documetation. I know from personal experience how hard it is, to write good documentation and also actually keep it up-to-date. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: /bin/sh (was Re: jessie release goals)
On Wed, May 15, 2013 at 05:33:44PM +0200, Vincent Lefevre wrote: Though zsh has an option to emulate sh, it may still not be completely compatible. Upstream fixes incompatibilities when it is easy. But some incompatibilities may remain. If sh needs special multibyte (UTF-8) support for some features in UTF-8 locales, there may be a problem with zsh, as in sh emulation mode, multibyte support is completely disabled, and enabling it yields incompatibilities (that's why http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=659932 is still there). Some years ago, Apple shipped zsh as /bin/sh for Mac OS X. It broke a lot of things at the time, including some of the autotools. I also tried zsh as /bin/sh, but found that debconf didn't work at all. Don't get me wrong, I love zsh, but without some serious work, it isn't at all a viable candidate for /bin/sh. I use mksh-static for /bin/sh. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: /bin/sh (was Re: jessie release goals)
On 05/13/2013 06:05 AM, Josselin Mouette wrote: Le dimanche 12 mai 2013 à 19:40 +0200, Helmut Grohne a écrit : With all due respect, this might be utter bullshit, but is at least [citation needed]. I have yet to see a failing pid 1 (be that sysv, upstart or systemd). Acquiring data on failure modes of any of those systems appears like a difficult task and d-devel might not be the best place to discuss that. Having a rock-stable PID 1 is nice and all, but it doesn’t help you if something important crashes. On a production server, if apache crashes and fails to reload properly because the scripts don’t get the ordering right, it doesn’t help you that init is still running fine. That is quite not truth. Let's say you have a broken HDD, and that you forgot to setup grub on the 2nd HDD or something else that will prevent boot up. In one case, you're totally screwed, on the other, you just restart Apache ! It would help you to have an init implementation that can detect which components can be initialized and at what time. For that, we have stuff like monit, which have been working in production for years without issues, and which has some other very interesting features (like sending you a mail when the process changes PID). You aren't much on the server things are you? Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5191e7ab.80...@debian.org
Re: /bin/sh (was Re: jessie release goals)
Le mardi 14 mai 2013 à 15:28 +0800, Thomas Goirand a écrit : On 05/13/2013 06:05 AM, Josselin Mouette wrote: Having a rock-stable PID 1 is nice and all, but it doesn’t help you if something important crashes. On a production server, if apache crashes and fails to reload properly because the scripts don’t get the ordering right, it doesn’t help you that init is still running fine. That is quite not truth. Let's say you have a broken HDD, and that you forgot to setup grub on the 2nd HDD or something else that will prevent boot up. In one case, you're totally screwed, on the other, you just restart Apache ! Yes of course, because a different init system will magically make your other disk bootable. It would help you to have an init implementation that can detect which components can be initialized and at what time. For that, we have stuff like monit, which have been working in production for years without issues, and which has some other very interesting features (like sending you a mail when the process changes PID). If you use tools like monit, you should be able to understand that such behavior should be standard for daemons shipped in Debian, and that sysadmins should not have to configure it themselves. Such tools also have limitations that systemd and upstart do not have, such as having to use heuristics (sometimes convoluted ones) to detect when a service is ready. You aren't much on the server things are you? I might not have setup any datacenter in a tax haven, but next time, you might want to look at who people are before giving them lessons, especially when you are unable to tell the difference between an init system and a bootloader. kthxbye, -- .''`. Josselin Mouette : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1368521486.3585.1616.camel@pi0307572
Re: /bin/sh (was Re: jessie release goals)
Helmut Grohne helmut at subdivi.de writes: What are the benefits of using shells other than dash for /bin/sh? (as Why does dash get special treatment, anyway? It was “suddenly“ in Debian after having been used in Ubuntu, but… there never was an evaluation of shells. I still believe the codebase of mksh is better (modulo issues introduced due to the active development), but I’m happy with freedom to choose one’s own system shell… (asides from the two things you mentioned) … or provide an mksh-static binary package. Which could also be used in initrd. bye, //mirabilos -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/loom.20130514t105738-...@post.gmane.org
Re: /bin/sh (was Re: jessie release goals)
On 05/14/2013 04:51 PM, Josselin Mouette wrote: Yes of course, because a different init system will magically make your other disk bootable. This is absolutely *NOT* what I said. Nothing in my message compares this or that init system. I just replied that when you have apache, it's easier to recover than with the PID1 crashing. That's it, nothing more, nothing less. If you use tools like monit, you should be able to understand that such behavior should be standard for daemons shipped in Debian, and that sysadmins should not have to configure it themselves. I do think that restarting crashed daemons is a nice feature, yes. Though I believe OpenRC has this feature too (I have no time to check for that fact right now, but I think I remember reading it somewhere). Also, I still believe that monit does its job well on the server side, and that a generalized tool will not be adapted for it. Only for servers, we should receive emails when there's something that happens with a daemon, I don't want my laptop to do that, even for Apache that I run there. So yes, it should be configured by the admin!!! Such tools also have limitations that systemd and upstart do not have, such as having to use heuristics (sometimes convoluted ones) to detect when a service is ready. I'm well aware that cgroups are important, yes. Though no, I don't think systemd or upstart would be good tools to do what monit does (unless they send emails? I haven't seen such a feature in upstart and systemd...) especially when you are unable to tell the difference between an init system and a bootloader. What lead you to believe I can't make such difference? The fact that I hacked a bit with OpenRC (and bloged about it), and that I am mentoring a GSoC around it, should give enough clue that I do know what an init system does. BTW, I didn't intend to make you angry, or to give lessons. Please don't take it this way, I was only kidding you (eg: joking *with* you, not trying to expose you in public). Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/519209bb.5080...@debian.org
Re: /bin/sh (was Re: jessie release goals)
Josselin Mouette j...@debian.org writes: Le mardi 14 mai 2013 à 15:28 +0800, Thomas Goirand a écrit : On 05/13/2013 06:05 AM, Josselin Mouette wrote: Having a rock-stable PID 1 is nice and all, but it doesn’t help you if something important crashes. On a production server, if apache crashes and fails to reload properly because the scripts don’t get the ordering right, it doesn’t help you that init is still running fine. That is quite not truth. Let's say you have a broken HDD, and that you forgot to setup grub on the 2nd HDD or something else that will prevent boot up. In one case, you're totally screwed, on the other, you just restart Apache ! Yes of course, because a different init system will magically make your other disk bootable. Erm, no that's not what he was saying. He was assuming that there must be a fault somewhere, so if it's not in the init scripts, it must be in systemd -- this of course is nonsense, but if you start from that assumption then it is better for apache to fail to restart than it is for systemd to crash. He missed the fact that you were contrasting one non-crashing init, that is capable of restarting dead services, with another non-crashing init setup that is not able to do so (without help). Just thought I'd clear that up. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560]http://www.hands.com/ |-| HANDS.COM Ltd.http://www.uk.debian.org/ |(| 10 Onslow Gardens, South Woodford, London E18 1NE ENGLAND pgpu90seuXXzC.pgp Description: PGP signature
Re: /bin/sh (was Re: jessie release goals)
On Sat, May 11, 2013 at 08:44:30PM +0100, Roger Leigh wrote: ... forcing the rest of the world to conform to our worldview. One desktop environment, and an awful one at that, dictating the init system we use is a complete farce. Debian is a lot bigger than GNOME, and if we have to, I'd vote for junking it entirely. As much as I liked GNOME over competing desktops in the past, this time I have to fully agree with this statement of yours. Kind regards, --Toni++ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130514131241.ga10...@spruce.wiehl.oeko.net
Re: /bin/sh (was Re: jessie release goals)
On Tue, 2013-05-14 at 08:59 +, Thorsten Glaser wrote: Helmut Grohne helmut at subdivi.de writes: What are the benefits of using shells other than dash for /bin/sh? (as Why does dash get special treatment, anyway? It was “suddenly“ in Debian after having been used in Ubuntu, but… there never was an evaluation of shells. [...] Because it's our very own tiny shell: http://en.wikipedia.org/wiki/Debian_Almquist_shell Ben. -- Ben Hutchings Make three consecutive correct guesses and you will be considered an expert. signature.asc Description: This is a digitally signed message part
Re: /bin/sh (was Re: jessie release goals)
On Tue, May 14, 2013 at 08:59:57AM +, Thorsten Glaser wrote: Helmut Grohne helmut at subdivi.de writes: What are the benefits of using shells other than dash for /bin/sh? (as Why does dash get special treatment, anyway? Because /bin/sh is special under Debian policy, as an essential interpreter. So the right thing for the project is to treat *some* POSIX sh implementation specially. I don't think anyone (except you) actually cares if this should be mksh or dash - we care that it should *not* be bash which is too heavyweight, but I don't think there are any strong arguments why mksh or dash should be preferred. Which means that there is no strong argument for switching away from dash, since that change would cause more work and introduce more bugs for no material gain. It was “suddenly“ in Debian after having been used in Ubuntu, but… there never was an evaluation of shells. No, you are apparently lacking in historical context. The effort to switch to dash by default began in Debian; it was accomplished in Ubuntu more quickly because Ubuntu had no established userbase at the time and could ignore the problem of local diversions of /bin/sh. Debian then had to play catch-up with the implementation of its own plan. I still believe the codebase of mksh is better (modulo issues introduced due to the active development), but I’m happy with freedom to choose one’s own system shell… The end user can always add a local diversion again to point /bin/sh at mksh if they choose. But I don't see any reason why an end user should care about this, period. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: /bin/sh (was Re: jessie release goals)
❦ 14 mai 2013 11:54 CEST, Thomas Goirand z...@debian.org : Yes of course, because a different init system will magically make your other disk bootable. This is absolutely *NOT* what I said. Nothing in my message compares this or that init system. I just replied that when you have apache, it's easier to recover than with the PID1 crashing. That's it, nothing more, nothing less. And you conveniently removed you original message: That is quite not truth. Let's say you have a broken HDD, and that you forgot to setup grub on the 2nd HDD or something else that will prevent boot up. In one case, you're totally screwed, on the other, you just restart Apache ! I have still hard time to consider that you absolutely did not mention something related to a bootloader. Like in the previous discussions, you use some twisted tactics to make the consensus difficult to reach by using false claims, repeating them over and over, then claiming otherwise and asking references until everyone gets tired. -- panic(Attempted to kill the idle task!); 2.2.16 /usr/src/linux/kernel/exit.c pgpHJWSiu0FEC.pgp Description: PGP signature
Re: /bin/sh (was Re: jessie release goals)
On Sat, May 11, 2013 at 10:08:21PM +0200, Josselin Mouette wrote: This is utter bullshit and you should already know it. Systemd is much more reliable as a whole than any other implementation. I have yet to see a use case where it is not better. It is not better if you don't want proprietary binary-format logs in /var/log with no documented way to turn them off. It is also not better if you want an init that does not dump its own log messages to LOG_KERN. As a reasonably sane person, it had never occurred to me to put non-kernel logs under LOG_KERN for any reason whatsoever. For better or for worse, sysvinit provides a lot of modularity. systemd provides none of that modularity, and there are a lot of things it does that I'd rather disable (or better yet, uninstall) because they're just wrong. When I've used upstart and sysvinit, I've never had functionality that I wanted to disable and remove. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: /bin/sh (was Re: jessie release goals)
Am 15.05.2013 01:26, schrieb brian m. carlson: On Sat, May 11, 2013 at 10:08:21PM +0200, Josselin Mouette wrote: This is utter bullshit and you should already know it. Systemd is much more reliable as a whole than any other implementation. I have yet to see a use case where it is not better. It is not better if you don't want proprietary binary-format logs in /var/log with no documented way to turn them off. http://www.freedesktop.org/software/systemd/man/journald.conf.html Storage=none -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: /bin/sh (was Re: jessie release goals)
Am 15.05.2013 01:26, schrieb brian m. carlson: On Sat, May 11, 2013 at 10:08:21PM +0200, Josselin Mouette wrote: This is utter bullshit and you should already know it. Systemd is much more reliable as a whole than any other implementation. I have yet to see a use case where it is not better. It is not better if you don't want proprietary binary-format logs in The format may be binary, but it certainly is not proprietary [1] Michael [1] http://www.freedesktop.org/wiki/Software/systemd/journal-files -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: /bin/sh (was Re: jessie release goals)
On 05/15/2013 02:16 AM, Michael Biebl wrote: Am 15.05.2013 01:26, schrieb brian m. carlson: On Sat, May 11, 2013 at 10:08:21PM +0200, Josselin Mouette wrote: This is utter bullshit and you should already know it. Systemd is much more reliable as a whole than any other implementation. I have yet to see a use case where it is not better. It is not better if you don't want proprietary binary-format logs in The format may be binary, but it certainly is not proprietary [1] I really can't believe people are still coming up with that non-sense. I have no idea why people assume that a binary format means it can only be processed with a special, proprietary tool. Binary simply means what it means, binary and not text which means it's a more stream-lined and machine-readable format as opposed to a text format with no formatting at all. And, when it comes to processing, binary data is actually *easier* to process. Everyone who has ever written a text parser themselves will agree. Cheers, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5192d6f4.6090...@physik.fu-berlin.de
Re: /bin/sh (was Re: jessie release goals)
And, when it comes to processing, binary data is actually *easier* to process. Everyone who has ever written a text parser themselves will agree. I guess everyone who has used grep, tr, sed and so on will disagree? -- Salvo Tomaselli http://web.student.chalmers.se/~saltom/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2166875.xrvvLYdKdA@hal9000
Re: /bin/sh (was Re: jessie release goals)
On Wed, May 15, 2013 at 02:29:40AM +0200, John Paul Adrian Glaubitz wrote: On 05/15/2013 02:16 AM, Michael Biebl wrote: Am 15.05.2013 01:26, schrieb brian m. carlson: On Sat, May 11, 2013 at 10:08:21PM +0200, Josselin Mouette wrote: This is utter bullshit and you should already know it. Systemd is much more reliable as a whole than any other implementation. I have yet to see a use case where it is not better. It is not better if you don't want proprietary binary-format logs in The format may be binary, but it certainly is not proprietary [1] I really can't believe people are still coming up with that non-sense. Maybe because I read it on LWN (http://lwn.net/Articles/468381/): All complaints about UUIDs were quickly overshadowed by another issue once the full proposal was posted: one might charitably say that there is not, yet, a consensus around the proposed new logfile format. In a sense, that is unsurprising, since that format is deliberately undocumented and explicitly subject to change at any time. You'll pardon me if I believe that LWN is a reputable source for information. I have no idea why people assume that a binary format means it can only be processed with a special, proprietary tool. Binary simply means what it means, binary and not text which means it's a more stream-lined and machine-readable format as opposed to a text format with no formatting at all. It means that it works completely differently from every existing Unix log parser on the planet. syslog is hardly no formatting at all. And, when it comes to processing, binary data is actually *easier* to process. Everyone who has ever written a text parser themselves will agree. I have written several, and I still prefer plain text. I want to use the same tools to parse my logs that I have used for years, like logcheck. Text files is the Unix way. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: /bin/sh (was Re: jessie release goals)
On Wed, May 15, 2013 at 02:12:10AM +0200, Michael Biebl wrote: Am 15.05.2013 01:26, schrieb brian m. carlson: On Sat, May 11, 2013 at 10:08:21PM +0200, Josselin Mouette wrote: This is utter bullshit and you should already know it. Systemd is much more reliable as a whole than any other implementation. I have yet to see a use case where it is not better. It is not better if you don't want proprietary binary-format logs in /var/log with no documented way to turn them off. http://www.freedesktop.org/software/systemd/man/journald.conf.html Storage=none Silly me. I expected that if I installed systemd, that the appropriate man pages would be shipped with the package: vauxhall ok % man journald.conf No manual entry for journald.conf -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: /bin/sh (was Re: jessie release goals)
❦ 11 mai 2013 22:08 CEST, Josselin Mouette j...@debian.org : I can't agree with having no choice with regard to init. We aren't all using GNOME, and Debian is used in an extremely diverse set of fields for a multitude of different purposes. No one init is appropriate for all of these applications. systemd fails on safety grounds alone for a good number of uses. That much complexity is an unacceptable risk for PID1 failure. This is utter bullshit and you should already know it. Systemd is much more reliable as a whole than any other implementation. I have yet to see a use case where it is not better. Unfortunately, its current implementation in Debian has some serious drawbacks: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=669101 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=697962 Don't get me wrong: I would love to have systemd as a default init. It would solve many problems and bugs like above would be fixed because the burden would not rely on systemd maintainers alone (and I suspect the bugs are here because systemd has to integrate with the current SysV init). I only point the current problems with systemd as an example as what we get with the current situation: inability to fully use systemd. One year ago, there was a good plan for this: 1. Switch to systemd as default init (or Upstart). 2. Provide a conversion system from (more descriptive) systemd unit files to some other still supported systems (like the old SysV) with the ability to override the conversion by shipping an init.d file. There was a GSoC for this. I remember that the code is here but there was no followup. Switching to a default modern init has two benefits: 1. The benefits from the modern init system alone. 2. A proper integration into Debian by removing old cruft from packages making the new init work as intended by upstream (and therefore less buggy) and move the responsability of a working init system to other packages (nobody would blame sysvinit package for a problem in some init.d files, it should be the same for systemd). The conversion mechanism is a compromise solution for those that want freedom of choice on the init system. Unfortunately, switching to systemd unit files is a requirement for the whole thing to work and it implies that we switch to systemd by default and it is a project choice. So, no way to get forward here until we get a consensus. -- Program defensively. - The Elements of Programming Style (Kernighan Plauger) pgp4F2LQZivFp.pgp Description: PGP signature
Re: /bin/sh (was Re: jessie release goals)
On Du, 12 mai 13, 20:31:08, John Paul Adrian Glaubitz wrote: The difference between a shell and an init system is that the former is directly exposed to the user while the latter will only be visible to developers and admins most of the time. It makes sense to be able to customize your user interface, but I don't think it makes sense to be able to customize a core component like the init daemon. AFAICT the discussion is about /bin/sh, not about the login shell. For most users it will not make much difference which of dash, bash, etc. provides /bin/sh. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic signature.asc Description: Digital signature
Re: systemd^wfoo on linux, bar on bsd,so what (Re: /bin/sh (was Re: jessie release goals)
On Mon, May 13, 2013 at 02:31:02AM +0200, Marco d'Itri wrote: On May 13, Holger Levsen hol...@layer-acht.org wrote: actually, while it has been brought up as a theoretical/wrong argument, that we cannot switch our linux installation ship with $this init system, while the kfreebsd port uses $that init system, I'd say nobody is seriously saying this now. We will support several init systems anyway. At least for jessie+X. Maybe kfreebsd will do, but as I explained at FOSDEM I plan to make udev depend on either upstart or systemd. I would rather not be the one who will choose which one of them, so I hope that we will get to a consensus about this. Neither choice is acceptable, as you are undoubtedly aware. There is no need for udev to be dependent upon a specific init system, other than laziness. Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130513074623.go21...@codelibre.net
Re: systemd^wfoo on linux, bar on bsd,so what (Re: /bin/sh (was Re: jessie release goals)
Marco d'Itri m...@linux.it writes: On May 13, Holger Levsen hol...@layer-acht.org wrote: actually, while it has been brought up as a theoretical/wrong argument, that we cannot switch our linux installation ship with $this init system, while the kfreebsd port uses $that init system, I'd say nobody is seriously saying this now. We will support several init systems anyway. At least for jessie+X. Maybe kfreebsd will do, but as I explained at FOSDEM I plan to make udev depend on either upstart or systemd. I would rather not be the one who will choose which one of them, so I hope that we will get to a consensus about this. Do you really think that upstart is a viable option? No matter what the technical merits, the inevitable flame war regarding copyright assignment seems very likely to render upstart a non-starter as an essential element of Debian. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560]http://www.hands.com/ |-| HANDS.COM Ltd.http://www.uk.debian.org/ |(| 10 Onslow Gardens, South Woodford, London E18 1NE ENGLAND pgpkiOv9ltmJL.pgp Description: PGP signature
Re: systemd^wfoo on linux, bar on bsd,so what (Re: /bin/sh (was Re: jessie release goals)
On 2013-05-12 21:31, m...@linux.it wrote: Maybe kfreebsd will do, but as I explained at FOSDEM I plan to make udev depend on either upstart or systemd. do you have a link to a presentation, blog post, or whatever explaining the rationale behind this? i didn't found anything on FOSDEM website thanks -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/839db3167af8c830fff68c3f25b87...@zumbi.com.ar
Re: /bin/sh (was Re: jessie release goals)
On Mon, May 13, 2013 at 12:05:59AM +0200, Josselin Mouette wrote: Having a rock-stable PID 1 is nice and all, but it doesn???t help you if something important crashes. On a production server, if apache crashes and fails to reload properly because the scripts don???t get the ordering right, it doesn???t help you that init is still running fine. It would help you to have an init implementation that can detect which components can be initialized and at what time. The cases you describe still are pretty rare. Having used both implementations as PID 1, I was not able to make this noticeable. On the contrary I had more issued with running gpsd on systemd reliably. My conclusion from this? My data is a random outlier. For many users these benefits are so rare that they most likely don't care. I was all for kfreebsd when it was proposed, but now that it exists and nobody uses it, I am appalled at the idea of using it as an excuse to stop making improvements to the linux ports. Should we stop any migration to a decent networking system because BSD doesn???t support netlink sockets, too? I was not meaning to imply that. On the contrary turning systemd into the default will/would require porting it to kfreebsd, dropping support for kfreebsd, or using different init systems for linux and kfreebsd. The latter implies a limited choice on init systems. This choice actually might make sense as the cost might be lower than porting systemd. So my bottom line here would be: Providing freedom of choice is neither something that is always good nor something that is always bad. It just happens to be useful sometimes. Helmut -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130513143146.gc28...@alf.mars
Re: systemd^wfoo on linux, bar on bsd,so what (Re: /bin/sh (was Re: jessie release goals)
On May 13, gustavo panizzo gfa g...@zumbi.com.ar wrote: On 2013-05-12 21:31, m...@linux.it wrote: Maybe kfreebsd will do, but as I explained at FOSDEM I plan to make udev depend on either upstart or systemd. do you have a link to a presentation, blog post, or whatever explaining the rationale behind this? There is no such thing. The rationale is quite simple: a complex low level package like udev requires complex and tight integration with the boot process, and I do not want to duplicate this effort and then have one of the implementations which will get little or no testing. -- ciao, Marco signature.asc Description: Digital signature
Re: systemd^wfoo on linux, bar on bsd,so what (Re: /bin/sh (was Re: jessie release goals)
On May 13, Philip Hands p...@hands.com wrote: No matter what the technical merits, the inevitable flame war regarding copyright assignment seems very likely to render upstart a non-starter as an essential element of Debian. I think that this is a reasonable element to consider in our decision process. -- ciao, Marco signature.asc Description: Digital signature
Re: systemd^wfoo on linux, bar on bsd,so what (Re: /bin/sh (was Re: jessie release goals)
On Mon, May 13, 2013 at 08:46:23AM +0100, Roger Leigh wrote: There is no need for udev to be dependent upon a specific init system, other than laziness. Except if you want to receive device plug events as triggers to start up / shut down services. The separation then gets quite blurry with whom should handle events and what packages should ship to handle events. Bonus points for dependency handling between services and hotplug events. (There is no udevsettle anymore.) Kind regards Philipp Kern signature.asc Description: Digital signature
Re: systemd^wfoo on linux, bar on bsd,so what (Re: /bin/sh (was Re: jessie release goals)
2013/5/13 Philipp Kern pk...@debian.org: On Mon, May 13, 2013 at 08:46:23AM +0100, Roger Leigh wrote: There is no need for udev to be dependent upon a specific init system, other than laziness. Except if you want to receive device plug events as triggers to start up / shut down services. The separation then gets quite blurry with whom should handle events and what packages should ship to handle events. Bonus points for dependency handling between services and hotplug events. AFAIK in Solaris it is implemented with syseventd and does depend on init system. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/call-q8znk9a7duqm+q0tts4_yh4+dgk756kf508cxavrocy...@mail.gmail.com
Re: systemd^wfoo on linux, bar on bsd,so what (Re: /bin/sh (was Re: jessie release goals)
2013/5/14 Игорь Пашев pashev.i...@gmail.com: 2013/5/13 Philipp Kern pk...@debian.org: On Mon, May 13, 2013 at 08:46:23AM +0100, Roger Leigh wrote: There is no need for udev to be dependent upon a specific init system, other than laziness. Except if you want to receive device plug events as triggers to start up / shut down services. The separation then gets quite blurry with whom should handle events and what packages should ship to handle events. Bonus points for dependency handling between services and hotplug events. AFAIK in Solaris it is implemented with syseventd and does depend on init system. Please, ignore my previous message :-) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CALL-Q8wwxDMMFG+iGi_9sgtoY0LFVYZeyLmJFNc9OqFxen=n...@mail.gmail.com
Re: /bin/sh (was Re: jessie release goals)
On Sun, 12 May 2013 10:40:53 +0800, Thomas Goirand z...@debian.org wrote: On 05/12/2013 03:44 AM, Roger Leigh wrote: We all saw where GNOME took use with their lack of choice: an unusable trainwreck. It's a disgrace that this shipped as the default desktop for wheezy, it really is. Like for everything in Debian, this is bound to someone killing the concept of a default Desktop. It is indeed a shame that nobody worked on that. What is planned to do so? I surely hope that we don't end up building Kebian, Gebian and Xebian Images, which has always striked (stricken?) me as an utter waste. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1ubqfe-0006za...@swivel.zugschlus.de
Re: /bin/sh (was Re: jessie release goals)
On 13209 March 1977, Marc Haber wrote: Like for everything in Debian, this is bound to someone killing the concept of a default Desktop. It is indeed a shame that nobody worked on that. What is planned to do so? I surely hope that we don't end up building Kebian, Gebian and Xebian Images, which has always striked (stricken?) me as an utter waste. Not sure when you did it last (or rleigh or zigo) - but: Take a look at what CDs we over. What you hope - we already do. We have CDs which default to KDE, XFCE or LXDE for those who dislike the GNOME feature-removitis. -- bye, Joerg aj vorlon: would it be less subtle if we replaced red, green and yellow with black, white and a shade of grey? vorlon aj: and this is what a necrotic port looks like? aj vorlon: the arch qualification table, halloween edition? aj vorlon: i heard a faint pinging, and went to the firewall and what greeted my eyes? AN m68k RISED FROM THE GRAVE!!! -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ip2oe1y9@gkar.ganneff.de
Re: /bin/sh (was Re: jessie release goals)
On 05/12/2013 09:56 PM, Joerg Jaspert wrote: Not sure when you did it last (or rleigh or zigo) - but: Take a look at what CDs we over. What you hope - we already do. We have CDs which default to KDE, XFCE or LXDE for those who dislike the GNOME feature-removitis. Which is very different from being able to select, in d-i, what desktop you want (for example using the netinst CD). Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/518fb170.2040...@debian.org
Re: /bin/sh (was Re: jessie release goals)
On Du, 12 mai 13, 23:12:48, Thomas Goirand wrote: Which is very different from being able to select, in d-i, what desktop you want (for example using the netinst CD). This is already possible (from the boot menu). Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic signature.asc Description: Digital signature
Re: /bin/sh (was Re: jessie release goals)
On Sat, May 11, 2013 at 10:08:21PM +0200, Josselin Mouette wrote: This is utter bullshit and you should already know it. Systemd is much more reliable as a whole than any other implementation. I have yet to see a use case where it is not better. With all due respect, this might be utter bullshit, but is at least [citation needed]. I have yet to see a failing pid 1 (be that sysv, upstart or systemd). Acquiring data on failure modes of any of those systems appears like a difficult task and d-devel might not be the best place to discuss that. But regardless, we don???t need more than one init system. We just need a good one. This is completely unrelated to GNOME. The bunch of idiots who try to pin it down on GNOME, Fedora or the Illuminati look like just another group of conspiracy theories lunatics. The problem is not that people disagree on that a good init system is needed, but about what good comprises. Some people believe that a good init system should run on all supported architectures including kfreebsd-*. By this particular metric sysv init still outperforms systemd. In fact for every combination of init systems you will find a metric where one outperforms the other. And this is where choice makes sense IF the benefits outweigh its costs. Unfortunately that if is a very tough question. Let me therefore direct a question to those in favour of a switchable /bin/sh: What are the benefits of using shells other than dash for /bin/sh? (as opposed to other viable mechanisms to select a shell such as the shebang of your scripts) Answers I've seen so far: * Backwards compatibility with systems that still use bashisms. * Users who want to choose /bin/sh to satisfy some belief in superiority. Summaries or references to previous discussion appreciated. Helmut -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130512174058.ga29...@alf.mars
Re: /bin/sh (was Re: jessie release goals)
On 05/12/2013 07:40 PM, Helmut Grohne wrote: With all due respect, this might be utter bullshit, but is at least [citation needed]. I have yet to see a failing pid 1 (be that sysv, upstart or systemd). Acquiring data on failure modes of any of those systems appears like a difficult task and d-devel might not be the best place to discuss that. It's not PID 1 itself that is failing, but the daemons and scripts run by the init daemon. The init daemon therefore needs to be more intelligent and provide mechanisms to deal with crashed daemons. Yes, System V Init has been working for the last three decades. However, we weren't running the very same kernel and plumber land on everything from a smart phone up to a large compute cluster. systemd provides many useful features that help making systems on any scale more reliable and easier to maintain. Of course, you don't care if daemon XYZ crashes on your desktop and you're notified immediately, you just reboot in the worst case. However, you *do* care if that happens to the NFS daemon on your home directory server or your httpd on your web server. You also want to make sure that a single user won't be able to bring down a large login server (systemd's support for cgroups can do that) and you also want remote filesystems always to be mounted reliably when you reboot your system and not being a game of Russian roulette. I have observed both things happen several times on the network of my old university. I also think it's important to have a proper system of resolving dependencies between daemons in a clean and well-defined, intrinsic way and not through hacky bash scripts where scripts like insserv already fail when my last FAI update created a .prefai_copy file of a script in /etc/init.d. Socket-based activation is, in my humble opinion, the only proper way to have a proper means of determining dependencies and starting dependency chains of daemons in a reliable, reproducible and atomic way, e.g. either the whole chain runs or not. I don't think you can implement it with the same reliability and elegance using System V Init scripts. Both Solaris, MacOS X and iOS have dropped the classical System V Init in favor of socket-based activation long time ago and I haven't heard anyone complaining that users got deprived of their choices. The design has proven itself and powers over 100 million iDevices. The problem is not that people disagree on that a good init system is needed, but about what good comprises. Some people believe that a good init system should run on all supported architectures including kfreebsd-*. Ok, so could you please go ahead and make sure I can use things like launchd, ZFS and jails without any limitations on Linux? Honestly, you simply can't expect every single package in Debian to run on any of the supported kernels. If systemd profits from the use of Linux-specific kernel features, which is a good thing in my humble opinion because Linux has many very advanced and useful features, it should use them. I don't understand why these people who are so worried about systemd making the kfreebsd-* ports look bad don't go ahead and port launchd to it. launchd exists and is mature, is largely on feature par with systemd and has been released under a free license. systemd for the Linux ports, launchd for the kfreebsd-* kernels. By this particular metric sysv init still outperforms systemd. In fact for every combination of init systems you will find a metric where one outperforms the other. No, sysvinit has always been slower for me than systemd. The first thing I do after installing a new Debian box is replacing sysvinit with systemd. It's like using Internet Explorer to download Firefox on Windows. Let me therefore direct a question to those in favour of a switchable /bin/sh: What are the benefits of using shells other than dash for /bin/sh? (as opposed to other viable mechanisms to select a shell such as the shebang of your scripts) The difference between a shell and an init system is that the former is directly exposed to the user while the latter will only be visible to developers and admins most of the time. It makes sense to be able to customize your user interface, but I don't think it makes sense to be able to customize a core component like the init daemon. I already think that it's a bit crazy (and geeky) that we have the capability in Debian to choose between different kernels, so I guess it's natural that we have discussions about being able to make choices for init as well :). Cheers, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive:
Re: /bin/sh (was Re: jessie release goals)
2013/5/12 John Paul Adrian Glaubitz glaub...@physik.fu-berlin.de: Honestly, you simply can't expect every single package in Debian to run on any of the supported kernels. If systemd profits from the use of Linux-specific kernel features, which is a good thing in my humble opinion because Linux has many very advanced and useful features, it should use them. I already think that it's a bit crazy (and geeky) that we have the capability in Debian to choose between different kernels, so I guess it's natural that we have discussions about being able to make choices for init as well :). Yeah, that's quite easy ;-) http://cgit.osdyson.org/rsyslog.git/tree/debian/rules#n55 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/call-q8wxh8qs7x63gxph55otexblt61nck_guxshf9ojmpp...@mail.gmail.com
Re: /bin/sh (was Re: jessie release goals)
Le dimanche 12 mai 2013 à 19:40 +0200, Helmut Grohne a écrit : With all due respect, this might be utter bullshit, but is at least [citation needed]. I have yet to see a failing pid 1 (be that sysv, upstart or systemd). Acquiring data on failure modes of any of those systems appears like a difficult task and d-devel might not be the best place to discuss that. Having a rock-stable PID 1 is nice and all, but it doesn’t help you if something important crashes. On a production server, if apache crashes and fails to reload properly because the scripts don’t get the ordering right, it doesn’t help you that init is still running fine. It would help you to have an init implementation that can detect which components can be initialized and at what time. We could buy a piece of the argument if systemd was actually prone to crashing, but it is not. Most of the added features lie in other binaries, not in PID 1 itself. Your system is much more likely to crash because of a buggy driver in the kernel than because of the init system. The problem is not that people disagree on that a good init system is needed, but about what good comprises. Some people believe that a good init system should run on all supported architectures including kfreebsd-*. By this particular metric sysv init still outperforms systemd. In fact for every combination of init systems you will find a metric where one outperforms the other. I was all for kfreebsd when it was proposed, but now that it exists and nobody uses it, I am appalled at the idea of using it as an excuse to stop making improvements to the linux ports. Should we stop any migration to a decent networking system because BSD doesn’t support netlink sockets, too? Cheers, -- .''`. Josselin Mouette : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1368396359.13176.22.camel@tomoyo
systemd^wfoo on linux, bar on bsd,so what (Re: /bin/sh (was Re: jessie release goals)
Hi, On Montag, 13. Mai 2013, Josselin Mouette wrote: I was all for kfreebsd when it was proposed, but now that it exists and nobody uses it, I am appalled at the idea of using it as an excuse to stop making improvements to the linux ports. actually, while it has been brought up as a theoretical/wrong argument, that we cannot switch our linux installation ship with $this init system, while the kfreebsd port uses $that init system, I'd say nobody is seriously saying this now. We will support several init systems anyway. At least for jessie+X. It's just somehwat hard to agree on a new definition for $this in the first place. cheers, Holger signature.asc Description: This is a digitally signed message part.
Re: systemd^wfoo on linux, bar on bsd,so what (Re: /bin/sh (was Re: jessie release goals)
On May 13, Holger Levsen hol...@layer-acht.org wrote: actually, while it has been brought up as a theoretical/wrong argument, that we cannot switch our linux installation ship with $this init system, while the kfreebsd port uses $that init system, I'd say nobody is seriously saying this now. We will support several init systems anyway. At least for jessie+X. Maybe kfreebsd will do, but as I explained at FOSDEM I plan to make udev depend on either upstart or systemd. I would rather not be the one who will choose which one of them, so I hope that we will get to a consensus about this. -- ciao, Marco signature.asc Description: Digital signature
Re: /bin/sh (was Re: jessie release goals)
On Tue, May 07, 2013 at 07:46:43PM +0200, Marc Haber wrote: On Tue, 7 May 2013 16:46:46 +0200, m...@linux.it (Marco d'Itri) wrote: On May 07, Thorsten Glaser t...@debian.org wrote: My stated goal here is, indeed, to be able to run at least some useful configurations of a Debian installation without *both* bash and dash installed. What is the point? A smaller footprint of the intalled system? This may be interesting for embedded things. Greetings Marc While that might be of some interest the real goal of the change was to be able to have more than *2* packages provide /bin/sh. Currently, due to the totaly screwed up way this is done, only dash or bash can be /bin/sh. But we already have 4 working candidates for /bin/sh: bash, bash-static, dash, mksh Add 2 more if dash and mksh build static flavours too. posh, ksh93, (yash or zsh) could also become candidates with a little work it seems. Double that for multiarch on amd64/i386 because there is bash:i386 and bash:amd64 that both work just fine as /bin/sh. Trying to install a foreign bash or dash fails horribly though with the current diversion hack. Double that for kfreebsd with multiarch. kfreebsd-amd64 currently has 16 /bin/sh candidates. The current implementation of /bin/sh handling simply restricts the freedom to choose a /bin/sh. Not because only 2 shells are suitable and maintainable but simply because of the way the /bin/sh link is managed with diversions. Debian is about freedom and choice, right? Proposed solution: - New virtual package system-shell with something essential depending on it (base-files?) - bash, dash pre-depend on system-shell for the transition - new packages system-shell-name Provides, Replaces, Conflicts: system-shell contains /bin/sh - /bin/name symlink None of system-shell-* would be essential but through the dependency of something essential at least one would always be installed (pseudo-essential). One of them (system-shell-dash) should have a higher priority than the rest to be singled out as the default and the essential package would depend system-shell-dash | system-shell. Choosing /bin/sh is then simply done by installing the right package and dpkg does the change atomically. No messing around in pre/postinst/rm scripts or race conditions where the link might disapear for a while. No artificial limit on how many system-shell-* packages there could be. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130511092210.GC3334@frosties
Re: /bin/sh (was Re: jessie release goals)
On 2013-05-11 11:22 +0200, Goswin von Brederlow wrote: While that might be of some interest the real goal of the change was to be able to have more than *2* packages provide /bin/sh. Currently, due to the totaly screwed up way this is done, only dash or bash can be /bin/sh. I think that dash could probably stop diverting /bin/sh, now that bash no longer ships it (as of version 4.2-1). That would make it possible to locally divert /bin/sh for those who want it (#538822, #540512). Double that for multiarch on amd64/i386 because there is bash:i386 and bash:amd64 that both work just fine as /bin/sh. Trying to install a foreign bash or dash fails horribly though with the current diversion hack. Huh? No it doesn't, dpkg handles this just fine (apt doesn't because it does not support crossgrades, but that is another story). Make sure you have dpkg = 1.16.2, though. Proposed solution: - New virtual package system-shell with something essential depending on it (base-files?) Would probably need pre-depends so that system-shell cannot be removed temporarily (similar situation as with awk). - bash, dash pre-depend on system-shell for the transition - new packages system-shell-name Provides, Replaces, Conflicts: system-shell contains /bin/sh - /bin/name symlink None of system-shell-* would be essential but through the dependency of something essential at least one would always be installed (pseudo-essential). One of them (system-shell-dash) should have a higher priority than the rest to be singled out as the default and the essential package would depend system-shell-dash | system-shell. Choosing /bin/sh is then simply done by installing the right package and dpkg does the change atomically. Only if the packages declare Conflicts/Replaces on every real provider of system-shell, and with apt you lose outright because it insists on removing the conflicting package(s) first. No messing around in pre/postinst/rm scripts or race conditions where the link might disapear for a while. No artificial limit on how many system-shell-* packages there could be. I'm afraid your plan as outlined is not going to work. Cheers, Sven -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/8738ttk00m@turtle.gmx.de
Re: /bin/sh (was Re: jessie release goals)
Goswin von Brederlow goswin-v-b at web.de writes: Add 2 more if dash and mksh build static flavours too. posh, ksh93, mksh already builds a static flavour ;-) It’s just not an mksh-static separate binary package because waldi, who kindly sponsored my first several uploads, taught me that binary packages are a costly resource. I intended /bin/mksh-static to be used by initramfs-tools in place of the ash or busybox-sh they use (maybe pick it up automatically once mksh is installed, like it does with busybox if it’s installed). No idea whether approaching them would not be shot down either… plus it’d add a few dozen KiB (more on hurd/kfreebsd due to lack of non- eglibc C libraries there) to the already huge initrd… but you’d get a modern, robust shell, tab completion, the works. Nowadays I mostly run with /bin/sh@ - mksh-static (started on the m68k systems where there’s noticeable benefit, doing it everywhere). Sven Joachim dixit: On 2013-05-11 11:22 +0200, Goswin von Brederlow wrote: Proposed solution: I'm afraid your plan as outlined is not going to work. I’d be delighted if you can explain which part(s) aren’t, and even more if you have a (general) idea how to fix it? We tried several scenarios and did a lot of brainstorming, but in the end it turns out there’s few people who fully understand even one of the subsystems involved… Please keep at least mksh@p.d.o in the loop, eMail wise (can’t talk about the others, but I guess Cc’ing the package address of the shells involved would be sensible). Thanks, //mirabilos -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/loom.20130511t182813-...@post.gmane.org
Re: /bin/sh (was Re: jessie release goals)
On Sat, May 11, 2013 at 11:22:10AM +0200, Goswin von Brederlow wrote: On Tue, May 07, 2013 at 07:46:43PM +0200, Marc Haber wrote: On Tue, 7 May 2013 16:46:46 +0200, m...@linux.it (Marco d'Itri) wrote: On May 07, Thorsten Glaser t...@debian.org wrote: My stated goal here is, indeed, to be able to run at least some useful configurations of a Debian installation without *both* bash and dash installed. What is the point? A smaller footprint of the intalled system? This may be interesting for embedded things. While that might be of some interest the real goal of the change was to be able to have more than *2* packages provide /bin/sh. Currently, due to the totaly screwed up way this is done, only dash or bash can be /bin/sh. This is not a sensible goal. Choice of /bin/sh should *not* be the goal, the goal should be to get a good, fast, minimal, policy-compliant /bin/sh for *everyone*. See also: Linux is not about choice. All this added complexity to provide users a choice about something that doesn't matter undermines the robustness of the base system. Please stop. Double that for multiarch on amd64/i386 because there is bash:i386 and bash:amd64 that both work just fine as /bin/sh. Trying to install a foreign bash or dash fails horribly though with the current diversion hack. Yes, the diversion hack should be superseded by a single, static symlink belonging to the dash package, and the rest of this pointless complexity should be jettisoned. The current implementation of /bin/sh handling simply restricts the freedom to choose a /bin/sh. Not because only 2 shells are suitable and maintainable but simply because of the way the /bin/sh link is managed with diversions. Debian is about freedom and choice, right? No, it is NOT about choice. It is about providing a high quality, free operating system to our users. This ridiculous complexity in /bin/sh handling undermines that quality. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: /bin/sh (was Re: jessie release goals)
Quoting Steve Langasek (2013-05-11 18:33:03) On Sat, May 11, 2013 at 11:22:10AM +0200, Goswin von Brederlow wrote: [...] the real goal of the change was to be able to have more than *2* packages provide /bin/sh. Currently, due to the totaly screwed up way this is done, only dash or bash can be /bin/sh. This is not a sensible goal. Choice of /bin/sh should *not* be the goal, the goal should be to get a good, fast, minimal, policy-compliant /bin/sh for *everyone*. See also: Linux is not about choice. All this added complexity to provide users a choice about something that doesn't matter undermines the robustness of the base system. Please stop. Choice ridiculous to some is relevant to others. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130511181751.18273.37...@bastian.jones.dk
Re: /bin/sh (was Re: jessie release goals)
Steve Langasek vorlon at debian.org writes: This is not a sensible goal. Choice of /bin/sh should *not* be the goal, the goal should be to get a good, fast, minimal, policy-compliant /bin/sh for *everyone*. Sure. We just disagree which one that is. See also: Linux is not about choice. Debian is not just about Linux. Oh, sorry, I forgot, you work for Canonical (which totally explains some of your writings in the other eMail too, which I’m not going to comment on). Of course, for *buntu people it’s not about choice. Now please take that attitude and go back to *buntu, where you *can* force one “desktop environmen”, one system shell, etc. on your users. In Debian, Developers are also users, and it can only be the UNIVERSAL operating system when there is choice. Yes, the diversion hack should be superseded by a single, static symlink belonging to the dash package Why dash? It’s clearly inferiour, buggy and not taken care of well. Oh, I forgot, you work for Canonical, who apparently invested into it. Well, newsflash: there are others who don’t. (And I’ve made it a personal crusade to replace uses of ash as shell, so why not dash either. Yes, this means I’m totally biased as well. I admit it though, and this is why I fight for the freedom for the users to choose their system shell. I don’t even care about the default, I’d be happy were it mksh or mksh-static of course, but I don’t. And I’ve successfully run both Debian and Kubuntu with mksh as system shell.) No, it is NOT about choice. It is about providing a high quality, free operating system to our users. This ridiculous complexity in /bin/sh But your users may have a more broad horizon than you, as Canonical employee, can imagine. They may want to have more of the Open Source ecosystem offered than you want to give them, especially to keep the saying “if it’s not in Debian it doesn’t exist” true. Users in Debian are NOT just desktop end users. They are also developers, both Debian and upstream. They are also systems engineers. And lots more. Including once-deployed embedded devices in remote locations requiring “node” to refer to the hamradio tool (remember this discussion?). bye, //mirabilos -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/loom.20130511t202028-...@post.gmane.org
Re: /bin/sh (was Re: jessie release goals)
On 2013-05-11 20:26, Thorsten Glaser wrote: Oh, sorry, I forgot, you work for Canonical (which totally explains some of your writings in the other eMail too, which I’m not going to comment on). Of course, for *buntu people it’s not about choice. Now please take that attitude and go back to *buntu, where you *can* force one “desktop environmen”, one system shell, etc. on your users. Hi, I believe you are being needlessly rude right now. Please keep in mind that: The Debian Project welcomes and encourages participation by everyone. [1] That includes Canonical and *buntu. ~Niels [1] http://www.debian.org/intro/diversity -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/518e8e6c.1050...@thykier.net
Re: /bin/sh (was Re: jessie release goals)
On Sat, May 11, 2013 at 08:17:51PM +0200, Jonas Smedegaard wrote: Quoting Steve Langasek (2013-05-11 18:33:03) On Sat, May 11, 2013 at 11:22:10AM +0200, Goswin von Brederlow wrote: [...] the real goal of the change was to be able to have more than *2* packages provide /bin/sh. Currently, due to the totaly screwed up way this is done, only dash or bash can be /bin/sh. This is not a sensible goal. Choice of /bin/sh should *not* be the goal, the goal should be to get a good, fast, minimal, policy-compliant /bin/sh for *everyone*. See also: Linux is not about choice. All this added complexity to provide users a choice about something that doesn't matter undermines the robustness of the base system. Please stop. Choice ridiculous to some is relevant to others. I look forward to the addition of /usr/share/cdbs/1/rules/mangle-bin-sh.mk in your next release. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: /bin/sh (was Re: jessie release goals)
Le samedi 11 mai 2013 à 18:26 +, Thorsten Glaser a écrit : See also: Linux is not about choice. Debian is not just about Linux. Yes it is. We have had two releases with kfreebsd, which failed to provide anything usable. Debian is only about Linux, and has always been. In Debian, Developers are also users, and it can only be the UNIVERSAL operating system when there is choice. Let me say that from someone who cannot be suspected of collusion with Canonical: Debian is not about choice. Being able to choose between two entirely different desktop environments, with different user experiences, is a good thing. Being able to choose between two /bin/sh shells or two /sbin/init implementations is not. Why dash? It’s clearly inferiour, buggy and not taken care of well. Oh, I forgot, you work for Canonical, who apparently invested into it. WTF? Seriously you need to bring your crusade elsewhere. Users in Debian are NOT just desktop end users. They are also developers, both Debian and upstream. They are also systems engineers. And lots more. Including once-deployed embedded devices in remote locations requiring “node” to refer to the hamradio tool (remember this discussion?). I want a unique /bin/sh and systemd as sole init system. Not just for my desktops, I want them for my servers too. Especially for my servers. I don’t do embedded devices, but I’m pretty sure I’d prefer simplicity and ease of administration for them too. kthxbye, -- .''`. Josselin Mouette : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1368298349.12318.19.camel@tomoyo
Re: /bin/sh (was Re: jessie release goals)
Niels Thykier dixit: I believe you are being needlessly rude right now. Please keep in mind Probably… but I think Canonical employees and *buntu developers have a conflict of interest, which *does* have “interesting” effects, such as wheezy releasing with different gcc versions being default across architectures. (I like Doko, and he’s very welcoming and helpful, but I can’t help but notice this… “interesting” effect.) GNOME packagers probably have a conflict of interest too, considering that GNOME wants to push their own “OS” with everything integrated, no choices, and even theming forbidden (because they believe that there’s no way to use a desktop but theirs). Yes, it was probably *too* rude for the mailing list… take it as being a Devil’s Advocate. Steve, I would like to apologise for the rudeness and anything that might be taken personal (as opposed to the conflict of interest I believe happens here, and the other stuff). that: The Debian Project welcomes and encourages participation by everyone. [1] That includes Canonical and *buntu. … but that doesn’t give either preferential treatment. That line includes me too, even though that’s apparently liked to be forgotten. Of course, no preferential treatment, either. //mirabilos -- Sorry, I’m annoyed today and you came by as an Arch user. These are the perfect victims for any crime against humanity, like systemd, feminism or social democracy. -- Christoph Lohmann on d...@suckless.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.bsm.4.64l.1305111848330.13...@herc.mirbsd.org
Re: /bin/sh (was Re: jessie release goals)
On 2013-05-11 20:53, Thorsten Glaser wrote: [...] that: The Debian Project welcomes and encourages participation by everyone. [1] That includes Canonical and *buntu. … but that doesn’t give either preferential treatment. I never said that and I never said I took Steve's side; I have not. Personally, I could almost not care any less what shell provides sh as long as it works and it is compatible with the current one. That line includes me too, [...] //mirabilos Yes. If I see someone being obviously rude to you on a public mailing list, I will do my best to step up against that as well. If somebody did that to you, I am sorry that I did not notice it - it was not my intention to single you out. ~Niels -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/518e99d1.2070...@thykier.net
Re: /bin/sh (was Re: jessie release goals)
Le samedi 11 mai 2013 à 18:53 +, Thorsten Glaser a écrit : I believe you are being needlessly rude right now. Please keep in mind Probably… but I think Canonical employees and *buntu developers have a conflict of interest, which *does* have “interesting” effects, such as wheezy releasing with different gcc versions being default across architectures. (I like Doko, and he’s very welcoming and helpful, but I can’t help but notice this… “interesting” effect.) Ben mentioned hotplug stuff, but I believe that the latter if you do not going to replace uses of Fedora problem caused by Knoppix destroy the package manually instead of glibc slow. There’s dependencies are a desktop but I’d be happy were it as long as well; us Germans and he’s apparently did liked to consider is the nvram of well, Yes, this interesting effects, such as they apparently did was booting WiXP. Probably have more of my laptop’s apparently did was about choice and that not buy the only Open Source ecosystem offered than you can force one desktop but as for the conflict of my choice and anything that being a reflection. Merging mentioned hotplug stuff. They think it and upstream; or it doesn’t. And I would like you do: it was doesn’t. //mirabilos -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1368300485.12318.23.camel@tomoyo
Re: /bin/sh (was Re: jessie release goals)
2013/5/11 Josselin Mouette j...@debian.org: We have had two releases with kfreebsd, which failed to provide anything usable. Debian is only about Linux, and has always been. I have some news about it ;-) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CALL-Q8wC9UYa=3g-5vuphm1reen+qs0rournmxwzeuupmdu...@mail.gmail.com
Re: /bin/sh (was Re: jessie release goals)
On Sat, May 11, 2013 at 08:52:29PM +0200, Josselin Mouette wrote: Being able to choose between two entirely different desktop environments, with different user experiences, is a good thing. Being able to choose between two /bin/sh shells or two /sbin/init implementations is not. The shell I can agree with. It is required to provide a POSIX shell, so as long as it is fully functional and performs well, just picking one and sticking with it is absolutely fine. I can't agree with having no choice with regard to init. We aren't all using GNOME, and Debian is used in an extremely diverse set of fields for a multitude of different purposes. No one init is appropriate for all of these applications. systemd fails on safety grounds alone for a good number of uses. That much complexity is an unacceptable risk for PID1 failure. We all saw where GNOME took use with their lack of choice: an unusable trainwreck. It's a disgrace that this shipped as the default desktop for wheezy, it really is. Quite how that happened I have no idea. I absolutely don't want to see a repeat of that horror with the basic operation of our system. The fact that GNOME is going to *require* systemd is really just yet another reflection upon the stupidity of tight-coupling and what happens when you start trying to control others. What are they, Microsoft or something? It's a bad attitude I never thought I'd see in the free software world--up until now we took great pains to be interoperable with each others rather than forcing the rest of the world to conform to our worldview. One desktop environment, and an awful one at that, dictating the init system we use is a complete farce. Debian is a lot bigger than GNOME, and if we have to, I'd vote for junking it entirely. -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130511194430.gb21...@codelibre.net
Re: /bin/sh (was Re: jessie release goals)
Le samedi 11 mai 2013 à 20:44 +0100, Roger Leigh a écrit : I can't agree with having no choice with regard to init. We aren't all using GNOME, and Debian is used in an extremely diverse set of fields for a multitude of different purposes. No one init is appropriate for all of these applications. systemd fails on safety grounds alone for a good number of uses. That much complexity is an unacceptable risk for PID1 failure. This is utter bullshit and you should already know it. Systemd is much more reliable as a whole than any other implementation. I have yet to see a use case where it is not better. We all saw where GNOME took use with their lack of choice: an unusable trainwreck. This is your opinion. There are other users who happen to value features over configurability. Given that iOS and Android sell by millions every week, maybe there are quite a lot of them. It's a disgrace that this shipped as the default desktop for wheezy, it really is. Quite how that happened I have no idea. I absolutely don't want to see a repeat of that horror with the basic operation of our system. We have only had one init system since the first Debian release. Why do we suddenly need more than one? What does make choice important now, that was not relevant before? The fact that GNOME is going to *require* systemd is really just yet another reflection upon the stupidity of tight-coupling and what happens when you start trying to control others. Please go implement a decent user tracking system with the same APIs (which are not tightened to systemd at all), and you’ll see GNOME has no dependency on systemd at all. Oh wait… this is already being worked on. By Ubuntu. But regardless, we don’t need more than one init system. We just need a good one. This is completely unrelated to GNOME. The bunch of idiots who try to pin it down on GNOME, Fedora or the Illuminati look like just another group of conspiracy theories lunatics. What are they, Microsoft or something? It's a bad attitude I never thought I'd see in the free software world--up until now we took great pains to be interoperable with each others rather than forcing the rest of the world to conform to our worldview. One desktop environment, and an awful one at that, dictating the init system we use is a complete farce. The complete farce is having project members saying that a desktop environment is “dictating the init system”. GNOME depends on a working glibc, too. Does it dictate the C library? It only runs on X. Does it dictate the windowing system? Such an amount of stubborn, willing ignorance dismisses anything else you might have to say on this topic. Debian is a lot bigger than GNOME, and if we have to, I'd vote for junking it entirely. Yeah sure, whatever floats your boat. Apparently it floats a lot on hate and not much on rational reasoning. kthxbye, -- .''`. Josselin Mouette : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1368302901.12318.36.camel@tomoyo
Re: /bin/sh (was Re: jessie release goals)
2013/5/12 Josselin Mouette j...@debian.org: GNOME depends on a working glibc, too. Does it dictate the C library? Yes. Portability still makes sense. Portability is a part of the word Free in Free Software. Debian is about Free Software. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/call-q8yededi4ctvhrvt0qucke5te1jrnzza5jaaeaguewb...@mail.gmail.com
Re: /bin/sh (was Re: jessie release goals)
Debian is about Free Software. Actually, about Free Users, isn't it? http://mako.cc/copyrighteous/freedom-for-users-not-for-software bye, //mirabilos -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/kmmadn$u3u$1...@ger.gmane.org
Re: /bin/sh (was Re: jessie release goals)
On Sat, May 11, 2013 at 8:08 PM, Josselin Mouette j...@debian.org wrote: Le samedi 11 mai 2013 à 20:44 +0100, Roger Leigh a écrit : We all saw where GNOME took use with their lack of choice: an unusable trainwreck. This is your opinion. There are other users who happen to value features over configurability. Given that iOS and Android sell by millions every week, maybe there are quite a lot of them. I dare you to answer a simple question - if I don't choose iOS, Android or Blackberry, what other OS comes preinstalled with modern smartphone? -- darkestkhan -- Feel free to CC me. jid: darkestk...@gmail.com May The Source be with You. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CACRpbMhz_1CugK=vihfcedvw08kek2w+qsszxkyoxsyspf6...@mail.gmail.com
Re: /bin/sh (was Re: jessie release goals)
On Sat, 2013-05-11 at 22:08 +0200, Josselin Mouette wrote: Le samedi 11 mai 2013 à 20:44 +0100, Roger Leigh a écrit : I can't agree with having no choice with regard to init. We aren't all using GNOME, and Debian is used in an extremely diverse set of fields for a multitude of different purposes. No one init is appropriate for all of these applications. systemd fails on safety grounds alone for a good number of uses. That much complexity is an unacceptable risk for PID1 failure. This is utter bullshit and you should already know it. Systemd is much more reliable as a whole than any other implementation. I have yet to see a use case where it is not better. So the old discussion is back, nice: let's spend some 100+ post on this again. Maybe the DPL and the tech committe could make their voices heard. Debian can definitely survive without Canonical (and RedHat). Debian is about Free Software (as well as free speech, users choice, user freedom, etc by the Social Contract) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1368306524.4595.64.camel@PackardBell-PC
Re: /bin/sh (was Re: jessie release goals)
+++ Steve Langasek [2013-05-11 09:33 -0700]: On Sat, May 11, 2013 at 11:22:10AM +0200, Goswin von Brederlow wrote: While that might be of some interest the real goal of the change was to be able to have more than *2* packages provide /bin/sh. Currently, due to the totaly screwed up way this is done, only dash or bash can be /bin/sh. This is not a sensible goal. Choice of /bin/sh should *not* be the goal, the goal should be to get a good, fast, minimal, policy-compliant /bin/sh for *everyone*. See also: Linux is not about choice. All this added complexity to provide users a choice about something that doesn't matter undermines the robustness of the base system. Please stop. Yes, the diversion hack should be superseded by a single, static symlink belonging to the dash package, and the rest of this pointless complexity should be jettisoned. I'm very keen to lose the diversion hack. It causes pain for cross-debootstrapping, especially on embedded images. Someone would need to make a case for replacing dash as /bin/sh. What do we get for enabling /bin/mksh fill that role too, for example? If it really is just better then why not just swap from dash to mksh and everyone can benefit? Swappable system shells is a nice idea, but Steve is right that it's a critical thing that really does need to work so there has to be some real gain from futzing with it. If it can be done cleanly then great. If not then lets see if we can't just pick one (almost) everyone can live with. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130512014039.gk2...@stoneboat.aleph1.co.uk
Re: /bin/sh (was Re: jessie release goals)
On 05/12/2013 03:44 AM, Roger Leigh wrote: We all saw where GNOME took use with their lack of choice: an unusable trainwreck. It's a disgrace that this shipped as the default desktop for wheezy, it really is. Like for everything in Debian, this is bound to someone killing the concept of a default Desktop. It is indeed a shame that nobody worked on that. Let's hope someone finds the time to fix that for Jessie. The fact that GNOME is going to *require* systemd is really just yet another reflection upon the stupidity of tight-coupling and what happens when you start trying to control others. What are they, Microsoft or something? It's a bad attitude I never thought I'd see in the free software world--up until now we took great pains to be interoperable with each others rather than forcing the rest of the world to conform to our worldview. One desktop environment, and an awful one at that, dictating the init system we use is a complete farce. Debian is a lot bigger than GNOME, and if we have to, I'd vote for junking it entirely. I 100% agree with the above. Let's hope we can demonstrate that OpenRC is a viable choice. Working on it is so much better than just fighting on -devel. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/518f0135.5060...@debian.org
Re: /bin/sh (was Re: jessie release goals)
On May 07, Thorsten Glaser t...@debian.org wrote: My stated goal here is, indeed, to be able to run at least some useful configurations of a Debian installation without *both* bash and dash installed. What is the point? -- ciao, Marco signature.asc Description: Digital signature
Re: /bin/sh (was Re: jessie release goals)
On Tue, 7 May 2013 16:46:46 +0200, m...@linux.it (Marco d'Itri) wrote: On May 07, Thorsten Glaser t...@debian.org wrote: My stated goal here is, indeed, to be able to run at least some useful configurations of a Debian installation without *both* bash and dash installed. What is the point? A smaller footprint of the intalled system? This may be interesting for embedded things. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1uzlyn-0006s7...@swivel.zugschlus.de
Re: /bin/sh (was Re: jessie release goals)
On Tue, 07 May 2013 19:46:43 +0200 Marc Haber mh+debian-de...@zugschlus.de wrote: On Tue, 7 May 2013 16:46:46 +0200, m...@linux.it (Marco d'Itri) wrote: On May 07, Thorsten Glaser t...@debian.org wrote: My stated goal here is, indeed, to be able to run at least some useful configurations of a Debian installation without *both* bash and dash installed. What is the point? A smaller footprint of the intalled system? This may be interesting for embedded things. If the space taken up by bash on top of dash is sufficient to be a problem for an embedded device, then it may be time to think about a different solution for that device (e.g. buildroot). The device is going to hit ENOSPACE very, very soon if removing bash would make even the slightest difference. Emdebian Grip can shrink normal Debian by 40% on average and there is discussion about how much further should be set as a target. That step will be aiming to shrink installs by another 15-20% - not just a handful of Mb. bash is less than 1Mb. Package: bash Source: bash (4.2+dfsg-1) Version: 4.2+dfsg-1em1 Architecture: armel Maintainer: Matthias Klose d...@debian.org Installed-Size: 944 http://emdebian.org/grip/search.php?arch=armeldistro=sid-grippackage=bash Please don't waste time on shell changes for a supposedly embedded gain. That is a false argument and only serves to weaken the case for change. I see no reason for this particular idea to be a release goal. Certainly not due to any embedded gain or footprint argument. Besides, Emdebian already provides mechanisms to not install bash (or any other package in Debian, whether Debian thinks the package is Essential, required or important) - so swapping out individual packages is not the issue. Much better candidates for embedded footprint improvements are trimming dependency chains in some of our most popular libraries: http://wiki.debian.org/EmdebianCrush (Some of those are out of date, I know.) Those steps are massive gains and, individually at least, are probably less work than changes to the shell. Much of the useful work on dependency chains is at a proof-of-concept already due to the build-profile support and Debian package archives. The remaining question is not whether bash or dash is a problem but whether there is enough interest to make it worth providing the reworked libraries with trimmed dependencies functionality. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgp6LJ0XedVdv.pgp Description: PGP signature
