Re: let's split the systemd binary package
Paul Tagliamonte wrote: On Fri, Oct 25, 2013 at 01:40:55PM +0200, Olav Vitters wrote: I don't see this happening, at all. When the GNOME release team is asked for a solution we make *concrete* decisions: use X, or Y or maybe try and support both. If you want to influence these decisions, I want something more than to a choice between something greatly supported (logind) vs something abandoned (ConsoleKit). So, I have a mild problem with framing the problem this way, when the This means by adopting logind, we should switch init over to systemd, otherwise a major package is using another major package in an unsupported configuration (or at least in a way that the maintainer doesn't wish to support) Since the project (on the whole) is fairly divided, I don't think we should trivialize this to actively developed vs cruft at this stage. I think you misinterpreted his message somehow. The way I see it: In this thread GNOME has been accused of bad faith, of things like intentionally breaking non-systemd configurations for the sake of it and using their position as an installed desktop environment to push unrelated init system changes. However, in reality the practical choice presented to GNOME has been between: * Use good well-supported interfaces. * Use crappy abandoned interfaces. With very little to no activity and no visible prospects of anyone maintaining them; some people are vocally pushing for them to be supported, but not doing the work. It should be obvious that you don't need to assume bad faith to understand why GNOME would choose the first alternative, even if it does imply a dependency on systemd. I don't see how explaining this situation would be an attempt to trivialize things. -- 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/1382711886.1856.75.camel@glyph.nonexistent.invalid
Re: Proposal: let’s have a GR about the init system
Russ Allbery wrote: Bastien beudart bastienbeud...@gmail.com writes: It seems that the tech committee is composed of two well known ubuntu developers. Isn't that biased? I mean do you see them voting against upstart, I know that the decision should be based around technical facts, but that is not in their interest to vote against their project, especially since canonical is isolating itself from the rest of the community, so having Debian support is, I guess, really important, so… Steve and Colin have both been Debian developers for a lot longer than they've been Ubuntu developers. I would indeed be surprised to see Steve vote against upstart, but that would be on the basis of its technical merits as he sees them and as he's made clear in various discussions over the years. Steve Langasek has been consistently posting dishonest FUD against systemd. Maybe you could explain that as excessive zeal following from valid technical considerations, but I'd consider that an excessively charitable interpretation for a member of a body that is supposed to have public trust. -- 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/1382717385.1856.82.camel@glyph.nonexistent.invalid
Re: tech-ctte: Decide which init system to default to in Debian.
Jonathan Dowland wrote: Whilst I think you have honourable intentions in referring this to tech-ctte, I can't help but think it's premature. The systemd maintainers have never said that they believe systemd is ready to be the default init nor whether they could handle supporting it if the decision was made out of their hands. They have proposed a release goal that is probably a necessary prerequisite for default init but has not yet been achieved. (I wouldn't expect it to be, yet. We aren't releasing for ages.) If asked what init system should be default *now* the only reasonable answer is stick but that isn't a useful question. I don't think the release goal of having native files for everything would be a prerequisite; I see no particular reason why it would not be OK to change default while some packages still use sysv compatibility. But it's true that actually changing to default is not a question for right now. However, I still think it would be appropriate to make a decision (and would have already been appropriate to do it earlier). The properties of the systems that the decision should be based on are not likely to change - the future init system should not be decided based on how polished the packaging is at the moment. In fact I'd consider it insane to fully polish everything to be ready for an actual switch, and only THEN make a decision whether to actually use the result or throw everything away. -- 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/1382735781.1856.94.camel@glyph.nonexistent.invalid
Re: Proposal: let’s have a GR about the init system
Colin Watson wrote: I've done some work on Upstart itself and a good deal more designing subsystems around it; no doubt that experience will have a bearing on my vote. The other Technical Committee members will also surely bring relevant experience of one kind or another to the table, as we've all worked on a wide range of systems with considerations that relate to the varying designs of systemd and Upstart. It unfortunately seems that nobody on the ctte is particularly familiar with systemd though (unless someone there has studied it in private), so a decision would need to be mainly based on evaluating the representations of others. Anticipating the kind of accusation that Bastien makes, I talked with Bdale at DebConf in his capacity as TC chair and asked whether he felt I should recuse myself; I don't remember exactly the words he used but I think it was something along the lines of TC members not needing to recuse themselves just because they happen to have relevant technical experience. One thing I will say here and now: if I feel under pressure from my employer to vote a particular way, then I will immediately recuse myself from the vote and from further part in the discussion. I'd hope that I don't think the technical experience would be that much of an issue, but I do see being employed by Canonical as a very substantial conflict of interest. IIRC Canonical has made an official statement that they will keep supporting Upstart and believe in it. This is a fairly visible company choice. Your work environment has at least at some level an official policy that Upstart should be considered better than systemd. Ubuntu still wants to keep using Upstart, but if Debian chooses systemd, Ubuntu will likely also need to admit that Upstart failed and plan for a switch. If your vote decides that Debian will choose systemd, and as a result upstreams conclusively drop any support for Upstart while Ubuntu still wants to keep using it, do you believe this will not have any negative consequences for your career at Canonical? I consider this the biggest question about the conflict of interest, more than direct you must vote this way pressure from your employer. -- 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/1382736975.1856.108.camel@glyph.nonexistent.invalid
Re: Proposal: s have a GR about the init system
Scott Kitterman wrote: Unless there's some kind of disclosure policy for everyone involved in the any technical discussion around Debian, CTTE decisions are quite distinct from any technical discussion. I think it's silly to claim Steve and Colin are inherently unable to separate what's good for Debian from what's good for Canonical. This is just one more symptom of irrational anti- Ubuntu/Canonical bias I see from some people in Debian and I encourage Steven and Colin not to give in to it. A conflict of interest is not the same as claiming the people involved are inherently unable to distinguish different interests. And I'd say this is a very obvious case of conflict of interest - their employer has an official stance, and the decision also has a direct impact on that employer. I do not see what reason you would have to label such concerns silly or symptoms of irrational bias unless you reject the whole concept of conflict of interest and say such concerns are always silly anywhere. Is that your view? I am no longer willing to assume that Steve Langasek would act in good faith in evaluating init systems; he has posted false claims about systemd too many times for me to believe they would all be honest mistakes, and has posted what has clearly been deliberate FUD. This independently of and in addition to any conflict of interest. I don't have anything against Colin Watson, and have nothing in particular to complain about in his reply concerning the conflict of interest. But I don't think there really is much he could even theoretically say to fully remove concerns about the conflict. That there is a conflict of interest is not a statement about him in person; it's a statement about the situation. No matter what gets decided, some people aren't going to like it and will complain. Personally, I don't think there's more than one sane choice for Jessie anyway: 1. Init systems in Debian MUST provided compatibility with sysvinit scripts. 2. Packages needing an init MUST provide a sysvinit script and may provide native init scripts also for alternative systems. 3. For the various CD #1 options, there can be different default init scripts Something like that. Anyone who thinks their pet sysvinit alternate is going to destroy all opposition and become the one true init for Jessie is dreaming. I think the important thing is making a decision on what init system Debian will use in the future. Details of the transition are then secondary. I wouldn't expect every trace of sysvinit scripts to disappear before next release (unless it takes a long enough time...). I don't see what would be the point of CD #1 options for different inits. Is that really a serious suggestion? -- 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/1382763470.1856.157.camel@glyph.nonexistent.invalid
Re: Proposal: switch init system to systemd or upstart
Brian May wrote: As much as I would like to see systemd as the default in Debian (and have switched to it on my Desktops), I see two show stopper issues: * Needs to work (somehow) with other applications (including not in Debian) that need to manage cgroups. In Debian this would include lxc. My understanding is that the _kernel_ side wants to change the cgroup API, and this means that at least in the long term current cgroup-using applications will need to change in any case (possibly by using systemd APIs instead). I'm not familiar with the specific case of lxc, but I really doubt systemd would make it unusable. Generally anything must already work with systemd to be usable on several major distros, so it should be a reasonably safe assumption that things will work. * See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=721775, seems to have the systemd maintainers stuck. To me that looks like a bug in old v44, which no maintainer is using any more. Do you have reason to believe it would be relevant to current unstable/testing? -- 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/1382765682.1856.172.camel@glyph.nonexistent.invalid
Re: let's split the systemd binary package
Thomas Goirand wrote: We've been reading again and again from systemd supporters that it's modular, and that we can use only a subset of it if we like. Now, we're reading a very different thing: that it's modular *but* we need to re-implement every bit of it so that the modularity becomes effective. That's a very different picture... :( Your argument is complete nonsense. First, you're confusing modular architecture with the existence of alternative implementations for every part that can be freely switched without extra work. You've made similar fallacious arguments before - see this post for my earlier reply to one: https://lists.debian.org/1370925376.18948.33.camel@glyph.nonexistent.invalid Second, the earlier discussion was in the context of using systemd as the init system (NOT about trying to use some tools from systemd without actually running systemd the init). Surely you won't claim that tools depending on systemd as init is an argument to not use systemd as init! Also, things like the the boot loader (syslinux, lilo, grub...), the GUI login (kdm, gdm, xdm...), or the system logger (with even some remote server syslogger available), have all for a long time, been interchangeable very easily with just an apt-get install. It used to be very simple and easy, and it should continue this way. We're now being told that we wont be able to choose *anymore*. This last word is the most important of them all: anymore. I (and AFAICT others too) see this as a regression (and this has absolutely nothing to do with the quality of the components of Systemd), and a possible way to be locked-in. People have been locked in to using sysvinit as the init system on Debian. If they are now locked in to using systemd, how is that a regression? And what can they not choose *anymore*? Not that I'd value arbitrary infrastructure choice for its own sake, but it seems that every single part you listed as having been choosable before would remain so with systemd as mandatory init. Since there's a Ubuntu patch, why not? Because the patch is not free to carry and guaranteed to keep working as software is updated. In fact, it's already known that it does NOT keep working without significant extra work. -- 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/1382627323.1856.42.camel@glyph.nonexistent.invalid
Re: systemd effectively mandatory now due to GNOME
Russ Allbery wrote: Christoph Anton Mitterer cales...@scientia.net writes: In sid, gnome-settings-daemon depends now on systemd. I'm missing a key bit of context here. Does gnome-settings-daemon just require that systemd be installed? Or does it require that the init system be systemd? The systemd package itself can be installed without changing init systems, so it's possible that gnome-settings-daemon just needs the non-init parts of this and one can install systemd for those bits and then go on with one's life without changing init systems. However, I don't know if systemd installed this way then starts its various non-init services. This seems like a fairly critical question, since if all that is required is for the systemd package to be installed (but without a change in the init system), this is all a tempest in a teapot. There are multiple distinct APIs GNOME needs. Things like power management may not work without systemd as init, but I'm not really sure. However, the most important part is logind. It probably mostly works without systemd as init with the current v204 systemd packages, but once the package is updated to a newer version it WILL NOT work without systemd as init due to cgroup management changes. And as discussed elsewhere in this thread, it does not appear realistic to keep it working. If someone wants to create a logind for systems not using systemd as init, that would need to be a separate package (maintained by people other than the systemd maintainers), perhaps created by forking logind from old systemd versions. GNOME can run without logind. However, some parts that are considered core functionality will not work. This page has some information about the dependency situation (perhaps someone could give a better one now, I haven't really followed GNOME): http://blogs.gnome.org/ovitters/2013/09/25/gnome-and-logindsystemd-thoughts/ -- 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/1382660824.1856.62.camel@glyph.nonexistent.invalid
Re: systemd effectively mandatory now due to GNOME
Steve Langasek wrote: On Thu, Oct 24, 2013 at 09:47:52AM +1100, Brian May wrote: If Gnome depends on gnome-settings-daemon, which now depends on systemd, this might be a worrying trend, as non-Linux kernels don't support systemd. Well, that's one more reason the init system and the dbus services should be separated out in the packaging. Current logind (in systemd v205+) depends on systemd instead of implementing its own cgroup handling. Thus, if you want to implement the logind API for non-systemd machines, you will need to create and maintain a separate program for that - either create a fork based on the standalone logind code from old systemd or write a new program. Or alternatively implement all the systemd APIs required by current logind in your own init or its helper processes. -- 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/1382576184.1856.8.camel@glyph.nonexistent.invalid
Re: let's split the systemd binary package [Was, Re: systemd effectively mandatory now due to GNOME]
Steve Langasek wrote: On Thu, Oct 24, 2013 at 02:21:25AM +0200, Matthias Klumpp wrote: 2013/10/24 Steve Langasek vor...@debian.org: [...] If Gnome depends on gnome-settings-daemon, which now depends on systemd, this might be a worrying trend, as non-Linux kernels don't support systemd. Well, that's one more reason the init system and the dbus services should be separated out in the packaging. Some of the services consume functions and features provided by systemd (the init system). Which is exactly the kind of embrace-and-extend that Debian should not tolerate having foisted on them in the default desktop by an upstream pushing an agenda. I think the agenda here is mostly make things work, and it's less embrace-and-extend than create new things. If Debian shouldn't tolerate that, then what's the alternative? Tell upstream that nothing must change? Or that it's their responsibility to implement everything new at least twice, with another version for Upstart just so that Ubuntu doesn't need to admit making a mistake with that and deal with a transition to a better system? So splitting it out is not an easy task. Ubuntu manages to do that by heavily patching systemd and their own upstart to support a systemd-less system. So first of all, how hard it is to split is irrelevant. This is work that must be done, and Debian should not accept excuses for it not being done. Second, there's nothing hard at all about applying these patches that have already been written and are being used in Ubuntu. Indeed, AFAICS there's only one patch to the upstream code currently missing from the Debian package: As I already said in my previous mail, this is not at all true for systemd v205+. I think you'd basically need a completely separate logind package for non-systemd systems. And if you think this is work that must be done, then it is YOUR responsibility to do it. It's not the systemd maintainers' responsibility to implement new functionality for non-systemd systems. If you want to keep using another init system, then it's your responsibility to do every part of the work required to ensure needed interfaces are available on such systems. Systemd maintainers should only need to ensure that things work well with systemd and there is a reasonable update path to 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/1382582733.1856.23.camel@glyph.nonexistent.invalid
Re: think twice before enabling -D_FORTIFY_SOURCE=2 for C projects without thorough build-time testing
Steve M. Robbins wrote: On September 21, 2013 09:04:23 PM Bernhard R. Link wrote: The whole point of undefined behaviour in C is that the compiler/implementor/... does not have to care. I strongly suspect the whole point of undefined behaviour is simply that at least two parties on the committee simply couldn't agree on correct behaviour. You're completely wrong. It's not like there would be multiple plausible ways to define a fixed result in this case; the choice is between requiring the implementation to handle this special case or not, and they chose to not require it. And in cases where there's a plausible choice of correct behavior, implementation-defined behavior makes a lot more sense than undefined behavior. Checking every time would make it slower, What are you referring to as it? The compiler? Checking that two arguments to a function are the same doesn't strike me as terribly expensive. The compiler could issue a diagnostic if it can detect that the values of two arguments are the same, and this would detect some of the obvious cases mentioned earlier in the thread. But in general it's not possible to detect this without adding extra runtime checks. For example, if the program has a function my_sprintf that in turn calls sprintf, the compiler can't warn about the call to sprintf in my_sprintf since the validity of that depends on what arguments my_sprintf is called with, and it can't warn about calls to my_sprintf since it doesn't know those should avoid giving the same argument twice (at least unless some kind of global whole-program optimization is used that allows the compiler to see all the code at once). requesting any specific behaviour would make it slower. Nonsense -- it has a specific behaviour now. It does not have specific behavior now. You shouldn't assume that every possible undocumented implementation detail in some versions of a library is specified behavior that will keep working the same way forever. Since the standard says it is undefined, there's nothing stopping us from reverting back to its old behaviour which, arguably, better mached people's expectations -- else they wouldn't have written the buggy code. Moreover, it is the same behaviour used when NOT compiled with _FORTIFY_SOURCE=2. else they wouldn't have written the buggy code is a poor argument - people write lots of buggy code based on completely nonsensical assumptions and expectations. Trying to keep the buggy code silently working is the worst choice, and will just worsen the situation. Any attempts to keep it working should at least ensure there is a visible diagnostic, to prevent the creation of more such bugs and give a chance to fix the existing ones. -- 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/1379860280.23075.24.camel@glyph.nonexistent.invalid
Re: overriding udev rules
Russ Allbery wrote: Kay Sievers k...@vrfy.org writes: Hmm, why would upgrades break? The old file would still be there, rename the devices (if you keep the patch to swap names, which upstream does not support any more), and take precedence over tht new names; the old rules file would just not be updated anymore when new devices appear. Manually-deployed /etc/network/interfaces files that assume a specific device naming come to mind. We have tons of those at work. Why would those break? Just having a manually-deployed /etc/network/interfaces file that uses names like eth0 should not break upgrades, because as mentioned in the part you quoted, the existing already-generated rules should still trigger and keep renaming the same card to eth0. So you need to assume something more to have an example of a problem case. -- 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/1378769281.30447.8.camel@glyph.nonexistent.invalid
Re: Less dinstall FTW?
Ansgar Burchardt wrote:
In comparison the changing part of unstable:
$ du -shc dists/unstable/*/{binary-*,source,Contents*.gz} | tail -1
665Mtotal
So having two dinstall runs per day compared to four would reduce the
amount of changes by roughly 1.3 GB per day. Mirrors also profit from
rsyncable gzip files, but snapshot.d.o does not.
I'm not sure how much dists/ changes in total: I think unstable changes
between every run, but testing changes at most twice a day. And then
there are smaller suites (experimental, proposed-updates, ...). My guess
is that it's about
4* 665 MB (unstable)
1-2* 563 MB (testing)
1-2* 70 MB (experimental)
So maybe 3293-3926 MB per day, i.e. about half of the actual package
changes.
Could dinstall frequency vary by architecture? Most of the benefit in
frequent dinstall runs comes from AMD64, but most of the cost comes from
unimportant architectures. So if there are resource limits, it'd make
sense to concentrate the resources on the architectures that matter.
--
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/1377786085.12282.8.camel@glyph.nonexistent.invalid
Re: overriding udev rules
Ben Hutchings wrote: But you don't actually want that behaviour. You cannot assume anything about the order in which net devices are created and therefore you still need rules for persistent names unless your machines have only one Ethernet(-like) interface (the usual VM case). You'll need to install rules that work out which interface should be 'eth0' (or, better, some meaningful name) based on the site conventions for wiring up network ports. Note that such a convention is already the default in upstream udev [1] (at least assuming the hardware layout on the machines is the same - if it isn't, then it's of course impossible to have any non-site-specific rule which could determine which parts of different hardware layouts should correspond to each other). The udev packages in experimental support that naming scheme, but as a Debian-specific change still default to the old naming rules (the ones that modify configuration when they see a new MAC address for the first time). [1] http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/ -- 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/1377528642.20022.17.camel@glyph.nonexistent.invalid
Re: Survey answers part 3: systemd is not portable and what this means for our ports
brian m. carlson wrote: On Mon, Jul 22, 2013 at 07:17:04PM +0300, Uoti Urpala wrote: If you don't do development, and nobody sharing your views does either, then there's a limit to the extent you can choose your direction just by refusing to follow those that do develop things further. You can't stick with Minix forever even if you think the direction of Linux is undesirable. My point is that Debian developers create lots of great software, and certainly maintain lots of patches to software for which Debian is not upstream. But it's simply not feasible for Debian to be the upstream for all software. That's true, but doesn't affect what I said above. If you can't develop Minix to be competitive then you either have to switch to Linux at some point or you'll become increasingly obsolete. I don't think it's controversial to say that Debian developers prefer upstreams that take concerns relevant to Debian and its users into account. Of course. But my point was that when no other upstreams offer competitive functionality, the friendliness of upstream isn't really relevant when choosing which program to use. The friendliest possible Minix maintainer can't make it a good choice over Linux, no matter how much you despise Torvalds. In the systemd case most of the concerns that upstream has been accused of not taking into account have clearly more been controversial views of some Debian developers than concerns of its users. For example, if kFreeBSD died as a result of lacking systemd support, that would probably be a net win for users. Suppose that in the future systemd does go in a direction you don't like. Now would it have done any good for Debian to not adopt it? Not really, if nobody develops a competitive alternative to its functionality. Not using it would only make Debian obsolete for most use cases. And the most realistic way to create a competitive alternative going in a different direction would be to fork systemd, so adopting current systemd would not make moving to such alternatives harder. The vast majority of the work I do on a Linux box, desktop, laptop, or server, does not involve init in any way. It is therefore not accurate to claim that using an init system other than systemd would make Debian obsolete. The init system matters for dynamic behavior like hardware discovery and network connectivity. It will matter in a lot of typical workflows, and choice of init system of course affects how easy it is to develop a distribution overall. Of course there are lots of tasks that you can still achieve on a 10-year-old machine with 10-year-old software. But even if such a machine does not become completely unusable, it is clearly obsolete. For example, RHEL 6 and Ubuntu use upstart, and I think it's hardly accurate, based on their significant adoption, to call them obsolete. And Debian still defaults to sysvinit, yet I wouldn't call it obsolete yet. But it does already suffer from its init system. For example, if an upstream expresses disinterest in supporting non-PC architectures, that may be a bad piece of software for Debian to place in an important role, even if it currently works on all our architectures, since Debian is very portable among different architectures. Of course, this isn't relevant to systemd, as it has no hardware- specific code and supports embedded platforms for which Debian is too bloated. This was meant as an illustrative example of a common problem with upstreams, not as a problem particular to systemd. systemd upstream has made a lot of controversial decisions that Debian may or may not want to support: combined / and /usr, the journal, logging to the kernel ring buffer, lack of portability to non-Linux kernels, and merging udev and systemd are a few examples. I'd say that mainly shows that systemd upstream has managed to develop things forward. Creating and changing things involves decisions, and there's no way to make everyone happy. And when old things are changed there's bound to be a lot of controversy, even if the old stuff was total crap and new is almost perfect. I do not believe there would have been any chance to achieve a similar amount of progress without controversy. The alternative to this kind of controversy is stagnation, not any magical form of progress with total consensus. If Debian decides that it is preferable for whatever reason not to adopt one or more of these decisions, the willingness of upstream to accept that decision and work with Debian instead of saying, Too bad, so sad, is something that should be considered before making a major change. I'm not saying not to use systemd, I'm just suggesting making a well-reasoned decision. I strongly disagree with the view that being a good upstream should imply accepting such arbitrary demands from distributions. IMO what a good upstream should answer to requests to change most of the things you listed
Re: Survey answers part 3: systemd is not portable and what this means for our ports
brian m. carlson wrote: On Mon, Jul 22, 2013 at 02:59:20AM +0300, Uoti Urpala wrote: Whether your argument was honest or not, I think it was a bad one. OK, perhaps you have concerns about the philosophy behind systemd and where that might take it in the future. Such philosophy issues are rather subjective. But your argument objectively fails at the ... and therefore moving to systemd may not be the right choice part. Your concerns, even if taken seriously, do justify such a conclusion. If systemd development goes in a direction you don't like, the rational answer is to fork it and do better if you can. Leaving Debian behind with an inferior init system is not an answer to your concerns. Since Debian is always in need of developers and volunteers, it isn't objectively reasonable to expect that forking a project will be possible. One thing that needs to be taken into consideration is the *likelihood* that upstream will take development in an undesirable direction, or in a direction that is not acceptable for Debian. If you don't do development, and nobody sharing your views does either, then there's a limit to the extent you can choose your direction just by refusing to follow those that do develop things further. You can't stick with Minix forever even if you think the direction of Linux is undesirable. Suppose that in the future systemd does go in a direction you don't like. Now would it have done any good for Debian to not adopt it? Not really, if nobody develops a competitive alternative to its functionality. Not using it would only make Debian obsolete for most use cases. And the most realistic way to create a competitive alternative going in a different direction would be to fork systemd, so adopting current systemd would not make moving to such alternatives harder. For example, if an upstream expresses disinterest in supporting non-PC architectures, that may be a bad piece of software for Debian to place in an important role, even if it currently works on all our architectures, since Debian is very portable among different architectures. Of course, this isn't relevant to systemd, as it has no hardware- specific code and supports embedded platforms for which Debian is too bloated. IMO being portable should not be considered a positive thing by itself. Being suited to a lot of use cases is positive, but that could be achieved by either porting to more platforms or supporting more use cases on the same platform. Assuming X.Org had supported x86 platforms only and supporting multiple X servers in Debian had not been realistic, do you think Debian should have kept using XFree86 on every platform rather than move to X.Org and drop support for X on non-x86? -- 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/1374509824.21442.82.camel@glyph.nonexistent.invalid
Re: Survey answers part 3: systemd is not portable and what this means for our ports
The Wanderer wrote: On 07/21/2013 05:04 PM, Josselin Mouette wrote: Le samedi 20 juillet 2013 à 19:21 -0400, The Wanderer a écrit : Making the switch away from the entrenched sysvinit is visibly very difficult, at least as a social matter, even in the environment we have. systemd et al., by virtue of the integration which is apparently one of their selling points and the proprietary[0] interfaces they seem to use, look like they would create an environment where a similar switch to whatever comes next would be even harder - at least partly as a technical matter, rather than a social one. Hey guys, I know this “Linux” thing is better than Minix, but it brings a lot of new features that we will be growing accustomed to. If we ever want to switch to Hurd one day, this is going to be much more complicated. My objection has nothing whatsoever to do with growing accustomed to features. (The line further down about without losing other functionality might have hinted at that fact.) I think the Minix comparison is still a very valid one, whatever the exact reasons are that you fear will make a future switch harder. Let's assume there are very valid technical reasons why you think switching to Linux will make a future move to Hurd harder than switching directly from Minix would have been. Is this a good reason to stay with Minix for now? I think the above is a good parallel for the systemd situation. The current alternatives are simply much worse than systemd. Staying with them in the hope of some possible benefit in the far future is not sane. This has to be one of the most twisted and bad faith arguments I ever heard in a situation of change resistance. My argument may perhaps be twisted (that's at least partly a matter of perspective), but it is absolutely not in bad faith. I made my previous post partly in hopes of drawing attention to my honest concerns, and partly in hopes of having those concerns convincingly shot down - and of thereby being reassured about the idea of going forward with systemd. (As I've said, I actually like what I've read about its functionality and so forth; if those concerns could be eliminated, I'd be greatly looking forward to seeing it adopted.) Whether your argument was honest or not, I think it was a bad one. OK, perhaps you have concerns about the philosophy behind systemd and where that might take it in the future. Such philosophy issues are rather subjective. But your argument objectively fails at the ... and therefore moving to systemd may not be the right choice part. Your concerns, even if taken seriously, do justify such a conclusion. If systemd development goes in a direction you don't like, the rational answer is to fork it and do better if you can. Leaving Debian behind with an inferior init system is not an answer to your concerns. -- 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/1374451160.21442.60.camel@glyph.nonexistent.invalid
Re: Survey answers part 3: systemd is not portable and what this means for our ports
Scott Kitterman wrote: On Friday, July 19, 2013 06:35:48 PM John Paul Adrian Glaubitz wrote: On 07/19/2013 06:12 PM, Mathieu Parent wrote: systemd is used regulardly on about 1200 popcon submiters, upstart on about 600 (this is even less than 100 from 2013-07-04, but what happened!). Like several people pointed out before, the popcon entries for the Ubuntu upstart package pointed to Debian which at a particular time which resulted in wrong data being sent to popcon. The data that we have now is the actual data and it shows upstart isn't very popular. sysvinit 148865 99.83% Neither is systemd. The numbers for either are small enough to be meaningless. The 99.83% percentage is meaningless as sysvinit is typically installed even on those machines that use systemd. When considering the absolute numbers, you need to take into account that a large portion of popcon reporters have old installations or aren't in any sense developers or system administrators; those are not even potentially target audience for manually installing a new init system. For a different perspective, systemd has currently 1602 installs, and gcc-4.8 (has been default GCC version for over a month) has 3809. gdb has 27116 (a large portion of those likely old systems that are not being actively updated); systemd is over 5% of that. I think a better comparison would be to pick some packages that are typically manually installed by developers or sysadmins, choose only the systems which contain recently updated versions of those packages, and then see what portion of those systems have systemd installed. But AFAIK the public popcon data does not contain such information about package relationships. -- 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/1374258109.21442.34.camel@glyph.nonexistent.invalid
Re: Survey answers part 3: systemd is not portable and what this means for our ports
Russ Allbery wrote: John Paul Adrian Glaubitz glaub...@physik.fu-berlin.de writes: Popcon however speaks a completely different language: http://qa.debian.org/popcon.php?package=upstart http://qa.debian.org/popcon.php?package=systemd Currently 64 counted installations for upstart versus 1604 counted installations for systemd with a significant drop for upstart shortly after it surged just when upstart in Debian was updated to 1.6. The surge was likely Ubuntu popcon bug sending reports to Debian (so in fact it's never been popular in Debian). I believe the equivalent systemd package to the upstart package is the systemd-sysv package, so 174 rather than 1604 is perhaps the better number to use. I don't think so - the documentation I've seen has always recommended changing kernel command-line to say init=/bin/systemd instead of installing systemd-sysv. In fact I'm somewhat surprised at the fact that according to those numbers more than one tenth of people (or at least popcon users) using systemd must have installed systemd-sysv. -- 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/1374198232.21442.19.camel@glyph.nonexistent.invalid
Re: PulseAudio
Steve Langasek wrote: You misunderstand me. I'm not upset about anything - I'm merely pointing out that Lennart is an unreliable source where claims of production-readiness are concerned. Ubuntu may have fallen for his silver-tongued sales pitch back in 2007, but there's no reason Debian should fail to learn from Ubuntu's mistakes. At least you're consistent in your approach of posting FUD whenever systemd is involved. The move to systemd in Debian is not motivated by Lennart's sales pitch. Though if we're going to talk about bugs, even though the kernel audio drivers have long since adapted to meet pulseaudio's requirements, PA itself still manages to turn up some doozies. https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1019925 Why in 2012 - four years later - does a stable release of pulseaudio manage to *crash* in response to a bluetooth hotplug event? Will systemd also crash in response to hardware hotplug events? :) Even if you want to post FUD, isn't this quite a stretch? The bug report is just one crash backtrace with no analysis; if you want to criticize PulseAudio, doing better than that should not be hard. And Lennart has had little to do with PulseAudio the last couple of years. -- 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/1374095502.21442.11.camel@glyph.nonexistent.invalid
Re: Plan to release a gplv3 compliant debian-based release
David Weinehall wrote: OK, I'll instead quote what Linus wrote in the link I posted: The version 2 of the License, or (at your option) any later version language in the GPL copying file is not - and has never been - part of the actual License itself. It's part of the As far as I know Linus is in the wrong there. Section 9 of GPL-2 allows using any license version if the program does not explicitly specify one, and that would have applied to old Linux versions that only included a COPYING file containing GPL-2, with no text for explicit version choice in the files. The link from Jacub Wilk already pointed to a post from Alan Cox explaining this. I don't see why you would post your link again in full quote after that without explaining why you still thought Linus wasn't wrong. So, that's Linus's stand on whether or not a GPLv3 kernel is feasible. I hope this totally pointless thread can die now. A GPLv3 only Debian distribution is, in my opinion, about as useful as lobotomy performed with a bazooka. Even if some Linux versions are deemed GPLv3-compatible they're probably too old for any realistic use now, so in that sense it doesn't matter. Similar licensing issues apply to other projects too though, so you should try to avoid spreading incorrect information. -- 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/1373030097.18948.56.camel@glyph.nonexistent.invalid
Re: Plan to release a gplv3 compliant debian-based release
David Weinehall wrote: On Fri, Jul 05, 2013 at 04:14:57PM +0300, Uoti Urpala wrote: [snip] a post from Alan Cox explaining this. I don't see why you would post your link again in full quote after that without explaining why you still thought Linus wasn't wrong. I posted it fully because the parent I responded to said that we shouldn't just post links, thus I interpreted it as though the full text of that link was prefered. I meant reposting it after the posting of another link which clearly questioned its correctness, without any comment on why you still thought it valid. As for my opinions: While Alan's opinions are certainly relevant for the large amounts of code *he* has participated, I think anyone would be hard pressed to The reason I replied wasn't so much to comment on the historical licensing of the kernel (it's old enough to not matter much now anyway), but to comment on the legal argument that was the core of Linus's post you linked to. He claimed that including the contents of GPL-2 in a COPYING file with no explicit license statements had always placed the code under GPL v2-only. I think he's wrong. And this actually matters for other projects. Linux is not the only project that had no explicit license statements at some point in its history, and such an interpretation would prevent adding per-file copyright statements with or later without full contact-all-contributors relicensing - and most projects do NOT want to be trapped at one particular version. -- 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/1373071136.18948.71.camel@glyph.nonexistent.invalid
Re: Survey answers part 1: systemd has too many dependencies, …
Michael Stapelberg wrote: Ondřej Surý ond...@sury.org writes: I still think you should also update the table with information if the library is actually used in PID 1 (or in forked process) as hmh suggested: It would be best to enhance http://people.debian.org/~stapelberg/docs/systemd-dependencies.html with information about what runs on PID 1, and what runs after fork() and how critical it is. I don’t understand what you mean by this. The table — as published — already differentiates between PID 1 (section 2 of the document) and all other binaries (section 3 of the document). Anything not listed in section 2 is not required in PID 1. I think what he meant is that section 2 lists libpam.so.0 as a dependency, even though PAM is not run in PID 1. So from the table it is not obvious that libpam is NOT a dependency of the core systemd daemon in the sense that faulty PAM modules would make PID 1 crash etc. -- 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/1371058452.18948.40.camel@glyph.nonexistent.invalid
Re: security policy / root passwords
Daniel Pocock wrote: It was also demonstrated with Windows 7 that users could be tricked by web sites that simply dimmed the background of the browser window - so it is not a perfect solution and I would personally prefer to see users referred to initiate su or sudo on their own. Initiate su or sudo as in from a terminal? Conditioning users to write commands in a terminal when prompted by a dialog sounds even worse than leaking passwords. At least leaking system passwords is less catastrophic when the system allows no remote login. -- 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/1370869938.18948.18.camel@glyph.nonexistent.invalid
Re: Survey answers part 1: systemd has too many dependencies, …
Thomas Goirand wrote: On 06/11/2013 02:23 AM, Henrique de Moraes Holschuh wrote: On Mon, 10 Jun 2013, Thomas Goirand wrote: Then which component would you install, and activate by default? Which component will you make only installable if the user decides to do it actively (for example using apt-get install)? That is an uninteresting option. There is no way we can afford to have two different sets of features for PID 1 under the same name in Debian without it causing support trouble we don't need. So, please assume that every optional PID 1 feature of systemd will be compiled in, and that only stuff that can be disabled at runtime might be disabled. If what you say above is right (I have no opinion on that yet, I just trust what you say), then this renders the systemd is modular argument completely useless, because practically, the user wont be able to choose. Which is why I was asking specifically Michael about this, since he raised the fact that systemd is modular and components can be disabled. As I understand it, the point about modularity was brought up to clarify misunderstandings about systemd architecture, not to suggest that the Debian setup should give users the ability turn arbitrary things on or off just for the sake of having more choices to make. Some people apparently had various misunderstandings about systemd bloat, up to believing that it would have a huge collection of varying functionality in PID 1. The systemd is modular argument shows what's wrong with this bloat view. It still works even if Debian maintainers decide to use all the modules. Your user won't be able to choose would be relevant if the complaint had been that systemd doesn't provide Gentoo users enough switches to turn on or off, but apparently that was not a common complaint in the survey. -- 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/1370925376.18948.33.camel@glyph.nonexistent.invalid
Re: Debian systemd survey
Russ Allbery wrote: There's really no reason to have something like an /etc/default setting for that, the way there is for the rsyncd init script. You can just edit that directly (well, it's systemd, so you have to copy it into /etc and make a new version and then won't know if anything about the default changes -- a truly awful design, but that's another argument). You don't necessarily need to copy the file into /etc to change something. Depending on the change, it may be more appropriate to create a new file using .include for the old file and then overriding only one particular setting. Telling people to blindly copy everything is bad advice IMO - if you have even the settings you _don't_ want to override in the /etc file, then merging is necessary on upgrades if you still want to follow changes to those default settings. Whether there are notifications from the packaging system when package upgrades change the default file has nothing to do with systemd design. That's up to the Debian packaging. Tollef Fog Heen just said in a post yesterday it's quite likely we'll go with an approach that uses ucf and does notify on update-with-changes. Of course rsync has another maintainer who might or might not choose the same behavior, and obviously he hasn't enabled any notifications at the moment. But if you disagree with that, blaming the design of upstream systemd is not the right target. -- 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/1370196033.3628.343.camel@glyph.nonexistent.invalid
Re: Custom Reload command/signal in upstart
Zygmunt Krynicki wrote: W dniu sob, cze 1, 2013 o 12:52 ,nadawca John Paul Adrian Glaubitz glaub...@physik.fu-berlin.de napisał: On 06/01/2013 12:24 PM, Vincent Bernat wrote: I don't know how systemd behaves in this way (so this is not something to hold against upstart), but there are so many daemons that need to be started after the network has been configured that it should be easy to do this. For example, most daemons binding to a specific address needs to be started after the address has been configured. Which is exactly the very one design decision which is wrong in upstart. Starting any service as soon as all its dependencies are fulfilled, is putting the dependency chain upside down and doesn't make any sense. There is no point to start a daemon unless you actually need it. Correct about the design, but not about the practical use. Even under systemd, the default configuration is typically to make services always start without waiting for on-demand loading. I believe there was a counter example of using CUPS where unless you really start it, other machines won't discover it via avahi and you won't be able to print to a networked printer. That's not a counterexample to the substantial points though. It shows that you shouldn't be too careless in setting up on-demand loading if you want it, but that isn't really what was being discussed. -- 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/1370089583.3628.219.camel@glyph.nonexistent.invalid
Re: systemd .service file conversion
Salvo Tomaselli wrote: You have the context wrong here. considering systemd as a default init is too vague. Wikipedia says: A default, in computer science, refers to a setting or a value automatically assigned to a software application, computer program or device, outside of user intervention. What's vague about that? It's the meaning of considering that was too vague, not the meaning of default. Considering whether systemd is a suitable choice for default init vs considering whether current Debian systemd packages are in a state where they should be made the default, and so on. Yes, there is integration work left. But that's really about the question is Debian ready to switch all user machines to systemd right now using the current packages?, and I think nobody would answer yes to that Good so that was exactly my point: let's have this thread when systemd is a production ready alternative. Your error is that you mix up the status of systemd and the status of systemd Debian integration. Systemd is a production ready system the same way Apache is a production ready system. Systemd Debian integration is not yet complete to that degree (not that it would be particularly bad; people don't have to be insane to already use it on production servers). He was confusing what were likely integration issues with what would be more fundamental issues with systemd itself (that would make it less desirable to do the integration work and switch at all), and I tried to explain the difference. I didn't say it has fundamental architectural flaws that can't be addressed, I said it should be care of the people who want it as default to take care of the flaws and make it a viable alternative before talking about it. Most likely the problem you encountered was no flaw of any kind in upstream systemd. It could have been a flaw Debian systemd setup, or a flaw in another package entirely that just happened to trigger under systemd. The latter kind aren't even particularly the responsibility of people working on systemd support, even if they do need to be fixed for systemd Debian integration. So, to sum it up: Upstream systemd is ready for production and suitable to be chosen as the default Debian init. Current Debian systemd packages are not ready to be made the default for all users; nobody is claiming they would be. Encountering some shallow problems is expected as more users test them, and this is pretty much unavoidable while integration work is still going on. You mixed up these two things (you also talked about use in Fedora, which obviously says nothing about Debian packaging). It's also obvious your time figures were completely made up (a few years to mature). -- 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/1370113345.3628.250.camel@glyph.nonexistent.invalid
Re: systemd .service file conversion
Marc Haber wrote: On Sat, 01 Jun 2013 12:42:33 +0200, John Paul Adrian Glaubitz glaub...@physik.fu-berlin.de wrote: What's the point in doing that work when, in the end, hardly anyone is using it? Freedom. It is not free to take away freedom just because too few people have chosen to exercise freedom. Why would kFreeBSD particularly matter for freedom? As opposed to any other random piece of software? Debian regularly removes old buggy packages that few people use. Are you saying that is wrong, and for the sake of freedom people should be given the ability to keep installing them even if few actually want to? If not, what makes kFreeBSD special so that it is more about real freedom? Do you claim that the existence of kFreeBSD is likely to somehow make the world a better place for someone in the long run? I myself believe that working on software that actually gets used is beneficial on average, while I think the world would be a better place if kFreeBSD had never been started at all - the negative effects on other Debian development outweight any benefits. Or is it about some ideal notion of freedom you have? I don't think anything in common free software philosophy at least would imply that kFreeBSD is important. -- 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/1370116640.3628.277.camel@glyph.nonexistent.invalid
Re: systemd .service file conversion
Wouter Verhelst wrote: On 30-05-13 22:36, Uoti Urpala wrote: While there is room for reasonable disagreement about the relative benefits of different configuration setups, completely inferior even to dpkg-conffile handling is not part of any reasonable disagreement. That claim is simply false. No. That claim is an expression of opinion. Calling something an opinion does not make it valid. It may be someone's opinion that 1+1=3, but that's simply false whether it's an opinion or not. Marc believes that dpkg-conffile handling is superior to having defaults in /usr/lib (or thereabouts) and only overriding those from /etc. To begin with, that's comparing apples to oranges. You're comparing the behavior of the packaging system on upgrades to the behavior of the application in use. The most plausible way I can construct something reasonable-sounding from your text is the comparison application default config in /etc and user modifies existing files to configure; dpkg-conffile handling of those files on package upgrades vs application default config in /usr/lib and user can add files to /etc to override everything or just particular options; package upgrades always simply update files in /usr/lib to new version with no other special action for configuration. Now you could have different reasonable opinions about the tradeoffs in these two cases, though completely inferior would still be exaggerated hyperbole at best. But this comparison does not match the original context of the discussion, where application behavior by itself was criticized. Obviously the application is not responsible for what Debian packaging does on upgrades, and the package upgrades could easily behave differently. If you want to post your opinion about a controversial topic, at least you should do a better job of phrasing exactly what it is that you're claiming. If people don't agree to begin with, you shouldn't expect them to make all the same implicit assumptions you do. And here it seems more like sloppy thinking where even you yourself hadn't thought through your assumptions. Also, these issues were already covered in the thread a year ago (and your post doesn't look like you'd have understood the arguments there but disagreed). -- 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/1370124763.3628.310.camel@glyph.nonexistent.invalid
Re: systemd .service file conversion
Svante Signell wrote: On Sat, 2013-06-01 at 22:57 +0300, Uoti Urpala wrote: Debian regularly removes old buggy packages that few people use. Are you saying that is wrong, and for the sake of freedom people should be given the ability to keep installing them even if few actually want to? If not, what makes kFreeBSD special so that it is more about real freedom? Both kFreeBSD and Hurd have contributed to multiple upstreams suddenly realizing they are creating buggy and non-portable software. This is a very important issue wrt software quality, and should be counted as one major reason to continue to support non-linux systems. I think this is the broken window fallacy. No doubt some related changes involved improving upstream code, but then about any other changes could have done the same. In general, finding things that could be improved is very easy and does not justify significant effort unless it's for specific things like bad security bugs. And you didn't answer the question of what this has to do with *freedom* at all. Additionally, Debian is about software freedom, not about lock-in of customers as for commercial vendors. Debian is promoting software freedom, if they stopped doing that then the whole idea of Debian would be lost (and should be discontinued, letting RedHat, Ubuntu, et al take over the whole (Linux) market). This again raises the same question. What does software freedom have to do with kFreeBSD or Hurd? You imply that dropping Hurd would make things less free. Why would it do that more significantly than dropping some obsolete package nobody uses? -- 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/1370126988.3628.322.camel@glyph.nonexistent.invalid
Re: systemd .service file conversion
Helmut Grohne wrote: On Fri, May 31, 2013 at 01:44:12AM +0300, Uoti Urpala wrote: Steve Langasek wrote: I can't speak to other distributions, but in Debian, the systemd maintainers are in no position to decide that Debian will agree to rewrite its Focusing on position to decide seems less than constructive. I believe that you are mistaking Steve's point here. His statement appears merely factual to me. And that is what it is. Some of the paths you were talking about are explained in the Debian policy as exceptions to FHS, and clearly it is not individual maintainers to decide how to change the policy. Individual maintainers are generally not in position to support systemd in Debian if everyone else opposes, but you're in no position to introduce systemd to Debian would still be less than constructive. I don't know what you mean by that FHS bit - I don't think anything under /etc/default is listed as exception to FHS? It makes a lot of sense to standardize those files across distributions. You don't seem to disagree with Debian following the FHS for example (or was your attitude to that our current paths work quite well already, thankyouverymuch too?). Why would custom /etc file locations be the very purpose of Debian's existence in a way that prohibits standardization, if other filesystem layout isn't? Again you appear to have a difficult time getting the argument. The purpose outlined was the integration work, not specific paths. Specific paths are merely a tool to get there. They can change, but that requires a lot of work and usually breaks tons of stuff. Indeed Debian is adopting a number of things from different distributions. That is a hard thing to do though, even for things that are already defacto standards. For example adopting the required filename encoding from Fedora turned out to be harder than expected (#701081). So given the work required to change such an aspect, the ones who want the change need pretty good arguments. Nothing in Steve Langasek's message mentioned the amount of work. What he said was This integration, which is *the very purpose* of Debian's existence, is not for systemd upstream (or any upstream) to dictate. Claiming that he was actually making an argument about how difficult the change would be to implement seems rather far-fetched. Obviously _you_ want to comment on the implementation aspect, but that's not what I was replying to earlier, and not something I failed to get. The argument for changing is pretty obvious: standardization. I think you're exaggerating the difficulty of changing for most of those files. I think discussing the difficulty in more detail would not be meaningful without considering particular cases. Anyway, my position is that switching to cross-distro locations used by systemd is desirable; I'm not saying it would have to be done for every file no matter what the cost if something is particularly hard in practice. Whereas Langasek was objecting more generally - he was clearly against such changes even if easily doable. If you think there is something actually wrong with the default choices currently used by systemd, a much more constructive approach would be to get that fixed across distros, rather than have Debian use a different custom layout. Note that standardizing on the current Debian locations across distros would not have been a good choice for the above two files, as they include the rather arbitrary /default/ path. More often than not, there is no wrong with specific naming in standards. It just happens that you have to pick one. Indeed systemd appears to have come a bit late to the party and Debian has had a standard long before. Arguably systemd could be the one opting to adopt an existing standard. I already addressed exactly this point in the text you're replying to: Note that standardizing on the current Debian locations across distros would not have been a good choice for the above two files, There was good reason to use paths different from the traditional Debian ones for those two files. Systemd did adopt the Debian location for other files. (Now this is of course false, because RedHat had their own file name policy well before the invention of systemd.) I'm not sure what you were trying to say here (it's unclear what of your previous text the false refers to). Anyway the systemd goal of more standard paths meant discarding lots of Red Hat-specific paths too, like things under /etc/sysinit/ (approximately equivalent to Debian /etc/default/). This is more true for the socket activation API that systemd could have reasonably adopted from upstart, but chose not to do. Didn't systemd actually have a socket activation API before upstart? I don't remember exactly, but IIRC upstart at least got it rather late and there was no standard long before systemd. If you oppose them just because they come from systemd upstream, well... It appears
Re: systemd .service file conversion
Salvo Tomaselli wrote: I have tried systemd, and I like the approach it has, and in a few years I believe it has potential. But... using it to restart my computer i need to do an hard reset (and think of how happy would I be if my computer had been a server in a rack on the other side of the planet), and gave me several problems related to switching from X11 to vt and vice versa. Do you have any reason at all to believe that these were problems with systemd, rather than problems in Debian configuration or mostly independent bugs in other software that happened to trigger under systemd? Most likely the init that works most reliably in Debian for basic tasks like booting up a common default system and rebooting is still sysvinit. But that's not because of any positive quality of sysvinit, but rather because a lot of effort has been spent to paper over any problems. ANY init system can be tweaked to be able boot up and reboot a simple default system. That's not a relevant criterion to choose between them. If boot fails completely, in most cases that just demonstrates a lack of final polish. To make meaningful comparisons between systems, you need to at least see whether there are more fundamental problems underlying the failures, or why fixing or working around them takes more effort with some system. On a side note about Poettering, sometimes pulseaudio gets pulled in by some package that I install, and when this happens I stop hearing sounds from my computer, then I know I just need to remove it and everything will be fine I don't think PulseAudio works as an argument against him. See this mail for more details: https://lists.debian.org/1354241767.1887.76.camel@glyph.nonexistent.invalid -- 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/1369921815.3628.71.camel@glyph.nonexistent.invalid
Re: systemd .service file conversion
Mathieu Parent wrote: 2013/5/30 Marco d'Itri m...@linux.it: and the invent a new a configuration files scheme because it better suits RPM and Red Hat policies deal. Do you have an example? I think he's referring to the etc-overrides-lib semantics that systemd uses for configuration files. But it's wrong to describe that as better suits RPM and Red Hat policies; it's simply a better system than always having all configuration files in /etc and expecting users to possibly modify those same files, for reasons that are not specific to Red Hat. -- 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/1369922163.3628.75.camel@glyph.nonexistent.invalid
Re: systemd .service file conversion
Jonathan Dowland wrote: On Thu, May 30, 2013 at 04:50:15PM +0300, Uoti Urpala wrote: Do you have any reason at all to believe that these were problems with systemd, rather than problems in Debian configuration or mostly independent bugs in other software that happened to trigger under systemd? Whether or not systemd is responsible is not important if we are considering systemd as a default init: even if it is not responsible, if it exposes You have the context wrong here. considering systemd as a default init is too vague. important bugs, those bugs need to be addressed before we could make a switch. What we need to make sure works is systemd in Debian, that is, integration is where all the work is going to be. Yes, there is integration work left. But that's really about the question is Debian ready to switch all user machines to systemd right now using the current packages?, and I think nobody would answer yes to that (before also updating systemd to a much newer upstream version, etc). I'm pretty sure that was not the context of the mail I was replying to. He was confusing what were likely integration issues with what would be more fundamental issues with systemd itself (that would make it less desirable to do the integration work and switch at all), and I tried to explain the difference. -- 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/1369927900.3628.93.camel@glyph.nonexistent.invalid
Re: systemd .service file conversion
Matthias Klumpp wrote: 013/5/30 Marco d'Itri m...@linux.it: On May 30, Mathieu Parent math.par...@gmail.com wrote: [···] There is also the kill features Red Hat does not care about deal, Do you have an example? Persistent naming of network interfaces. ... is entirely optional, and can be disabled if someone doesn't want it - but I can't see what is bad about it... Also, rationale and introduction to this feature is nicely documented: http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/ Or do you mean something else? I think Marco meant udev dropping support for the older variant of persistent names, the one the article you linked to refers at 'For a longer time udev shipped support for assigning permanent ethX names to certain interfaces based on their MAC addresses.'. As described in the article, there certainly were reasons other than Red Hat does not care about it to drop this feature. Whether it would have been preferable to keep optional support somewhat longer for backwards compatibility is another question. -- 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/1369931671.3628.106.camel@glyph.nonexistent.invalid
Re: systemd .service file conversion
Marc Haber wrote: On Thu, 30 May 2013 17:07:08 +0200, Matthias Klumpp m...@debian.org wrote: So, this is not really RHEL specific, and some other non-RH software also has this scheme of storing config files. And it is still completely inferior even to dpkg-conffile handling, which has huge wishes left open as well. False. The message you replied to already listed advantages over dpkg-conffile handling. This was also already discussed before: https://lists.debian.org/1336580040.28230.9.camel@glyph.nonexistent.invalid -- 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/1369935171.3628.110.camel@glyph.nonexistent.invalid
Re: systemd .service file conversion
Russ Allbery wrote: Uoti Urpala uoti.urp...@pp1.inet.fi writes: Marc Haber wrote: And it is still completely inferior even to dpkg-conffile handling, which has huge wishes left open as well. False. The message you replied to already listed advantages over dpkg-conffile handling. This was also already discussed before: https://lists.debian.org/1336580040.28230.9.camel@glyph.nonexistent.invalid We've had this discussion a lot. There is an ongoing technical disagreement of opinion about the tradeoffs. While there is room for reasonable disagreement about the relative benefits of different configuration setups, completely inferior even to dpkg-conffile handling is not part of any reasonable disagreement. That claim is simply false. Pointing out that you've previously posted your side of the argument isn't any more likely to change anyone's mind than it did when you posted it the first time. The people who disagreed with your arguments the first time are still going to I did not post the link to point out I've previously posted my side, but to avoid repeating the same discussion again. To show what the benefits are without posting the same thing a second time, and to generally show that there already was a discussion about this topic before. I doubt everyone remembers a discussion from a year ago even if they did read it at the time, and it's not obvious to what degree Marc Haber himself was aware of it; at least he did not participate in that discussion. -- 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/1369946197.3628.131.camel@glyph.nonexistent.invalid
Re: systemd .service file conversion
Steve Langasek wrote: I'm assuming you're talking here about things like /etc/default/locale and /etc/default/keyboard, which systemd upstream fails to handle. I can't speak to other distributions, but in Debian, the systemd maintainers are in no position to decide that Debian will agree to rewrite its Focusing on position to decide seems less than constructive. system-level integration code (which works quite well already, thankyouverymuch) to conform to an arbitrary rule from systemd upstream. This integration, which is *the very purpose* of Debian's existence, is not for systemd upstream (or any upstream) to dictate. It makes a lot of sense to standardize those files across distributions. You don't seem to disagree with Debian following the FHS for example (or was your attitude to that our current paths work quite well already, thankyouverymuch too?). Why would custom /etc file locations be the very purpose of Debian's existence in a way that prohibits standardization, if other filesystem layout isn't? If you think there is something actually wrong with the default choices currently used by systemd, a much more constructive approach would be to get that fixed across distros, rather than have Debian use a different custom layout. Note that standardizing on the current Debian locations across distros would not have been a good choice for the above two files, as they include the rather arbitrary /default/ path. If you oppose them just because they come from systemd upstream, well... Of course Debian can choose to use different locations/semantics for the files if there is some actual justification. But IMO it's completely reasonable for upstream to decide that they should not be the ones who bear the burden of maintaining the patches for any such distro-specific divergences. -- 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/1369953852.3628.149.camel@glyph.nonexistent.invalid
Re: Debian systemd survey
Lucas Nussbaum wrote: I went through the various init systems threads again during the last few days. My understanding of the consensus so far is the following: - Both systemd and upstart bring many useful features, and are a clear improvement over sysvinit. Yes, both are an improvement over sysvinit. It is not clear which one of systemd or upstart is the best on the technical level. Many of the differences have grounds in differences of philosophy, which can easily be seen as pros or cons. I think this is false, both as a description of fact and as a description of claimed consensus view. Systemd has advanced significantly further than upstart, and this is more a technical reality than a matter of opinion like something such as preferred GUI behavior; this is better compared to whether Linux or MINIX was a more promising platform for future development in the 1990s. There is a lack of consensus, rather than a consensus that it's a matter of opinion or philosophy with no clear technical arguments. - It is also hard to say which one is best on the development/support community level. Upstart is strongly supported by Canonical, which is an organization with which we are quite used to work with. However, contributions to Upstart are subject to the Canonical contributor agreement. Systemd has already been adopted by most of the other major distributions. A related point which I think is very important is the effect of Debian's decision on the larger community. Having Linux distributions permanently split in systemd and upstart camps would have major costs for the overall Linux community. Systemd is already guaranteed to live, but Debian could succeed in killing upstart, both by making it costly for Ubuntu to maintain and by having a working systemd setup that Ubuntu could easily switch to. Maintaining and extending such a split between distros should be seen as a big negative, regardless of how upstart would work internally within Debian. - Neither systemd nor upstart are likely to be ported to kfreebsd soon, as they both rely on many Linux-specific features and interfaces. IMO essentially irrelevant distractions such as effects on marginal systems like kFreeBSD shouldn't be brought up at all. As Debian, we have two different problems: 1. We need to decide which init systems we want to support, and how. 2. We need to decide which init system should be the default. 1. Deciding which init systems we want to support, and how -- I'm not talking about shipping them inside Debian (we already do that), but about providing the necessary service config files (upstart job files / systemd service files) so that users actually benefit from switching to systemd or upstart. The above seems as if it's based on a somewhat inaccurate view of what the actual benefits are. Systemd offers better functionality than sysvinit (both what users can do on their systems, and APIs offered to the rest of the system) even if some services don't have native service files. We don't need to select a single init system at this point, and it would make sense to try to support all of sysvinit, upstart and systemd, at least for some time. I don't think it's at all obvious that it would make sense to support more than systemd and the minimum level of sysvinit necessary for update support. From distro point of view, much of the actual benefit of converting scripts to service files is that service files are much easier to maintain and less buggy; trying to seriously maintain other forms for longer than necessary loses this benefit. Implementing support would of course teach maintainers something about the different systems, but large scale conversions and serious fit-for-use maintenance of all three systems sounds like a rather costly way to compare; it's unlikely to reveal much you couldn't already see from other distros and smaller tests on Debian. Though perhaps it'd help motivate a larger amount of people to learn enough to be capable of informed discussion and decisions (even if the information to be learned is already available without that effort). -- 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/1369191001.3628.56.camel@glyph.nonexistent.invalid
Re: Bug#707740: general: fails with video Hi10p
Josselin Mouette wrote: Hi10p is a useless hack that makes videos unreadable with hardware acceleration. I wouldn’t recommend using it in the general case. The The useless hack part is false. 10-bit H264 is a clear improvement in video compression for some types of videos. Existing hardware video accelerators[1] lack support for decoding it, but that does not make it useless. [1] Accelerators is a somewhat misleading term, as typically multithreaded software decoding on modern AMD64 CPUs is faster. -- 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/1368279115.1926.50.camel@glyph.nonexistent.invalid
Re: Re: jpeg8 vs jpeg-turbo
Bill Allombert wrote: On Sat, Apr 27, 2013 at 08:55:28AM +0200, Ondřej Surý wrote: P.S.: You still haven't answered my questions in the previous email. I don't think they are unreasonable. Let start with the beginning: I became the maintainer of libjpeg62 in November 2001, the package having been unmaintained for 3 years. During the last twelve year, Guido has served as the upstream maintainer, helping me to deal with bug reports, providing patches to fix issues, and finally releasing libjpeg7 which included, inter alia, patches I wrote for the need of the Debian package (the DP xxx patches in the changelog). Guido also agreed to the release of libjpeg 6b1 which is libjpeg 6b with versionned symbols, which was needed to move forward with libjpeg7. Since the release of libjpeg7, Guido makes one release (minor or major) each year in January. During that time, it became obvious that Guido has a deep understanding of the libjpeg code and the JPEG technology, What do you base this on? It seems nobody is particularly impressed by his attempts to improve the format. Can you personally evaluate this, or whose opinion do you rely on? and at the same time that the quality of libjpeg is very high (there have been no security vulnerability reported against libjpeg6b in 15 years. Compare that number to libtiff, libpng or even libjpeg-turbo.) But it seems libjpeg6 was created by different people (though nobody has clearly answered the question of who the maintainers actually are and have been). So this hardly seems like an argument to prefer Guido as an upstream, at most an argument to stop any attempts at further improvement and just stay with the old code. On the other hand, it is also obvious that the libjpeg-turbo upstream does not have a full understanding of the libjpeg code, so we are better off with Guido as upstream maintainer. Do you have some references for that obviousness? Other distributions do not seem to consider it so obvious. And on the other hand, several problems with Guido's work have been mentioned here (such as in Ondřej Surý's mail you're replying to). While his positive accomplishments as a maintainer don't seem all that many; much of the new work has been in new extensions that are considered dubious. -- 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/1367496958.1926.17.camel@glyph.nonexistent.invalid
Re: multiarch and interpreters/runtimes
Helmut Grohne wrote: On Sat, Apr 20, 2013 at 04:44:08AM +0300, Uoti Urpala wrote: 3) P runs a script using system interpreter X, and depends on the interpreter environment supporting functionality provided by Q. Q needs to work for the arch matching installed version of X. P (all) +-- X (any) `-- Q (any) The interpreter will most likely be M-A:allowed. So all P has to do here is not add :any to its dependencies. Then everything should work out here. But that 'not add :any' is completely impractical. The default system interpreter can only have one architecture - what #!/usr/bin/python3 executes. Multiple versions of that can not be coinstallable, and so it's completely unreasonable for a foreign package containing Python scripts to demand that you change your _default_ Python interpreter to another architecture. It would immediately lead to conflicts. In a sane system scripts written in pure Python must work with the default system interpreter, whatever architecture that is. In the light of the above I do not quite understand what is missing to support your use cases yet (besides an implementation). Can you explain them in more detail? Examples would be helpful. Consider a package that contains a Python script (#!/usr/bin/python) doing image manipulation using python-imaging (Depends: python, python-imaging) and an i686 binary using embedded Python (Depends: libpython2.7, python-levenshtein). As above, installing this package must not require changing your default system python to i686. So the effective dependencies are: python:any, python-imaging:whatever python is, libpython2.7:i686, python-levenshtein:i686. -- 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/1366468972.1964.44.camel@glyph.nonexistent.invalid
Re: multiarch and interpreters/runtimes
Helmut Grohne wrote: You point out a limitation that I'd consider to be a feature. My proposal requires that every package has a single set of running architectures that has to apply to all code contained. Should that set of running architectures be just architecture? I think that after adding such splitting of packages the system could represent the required constraints, but I'm not sure if such splitting is a practical way. Having to split a small number of packages to achieve true multiarch seems like a good trade off to complicating the dependency syntax to me. Have you tried to somehow count the affected packages? Where did you get the small number from? There are over 2500 packages with a dependency relationship on python alone that are not named python-* (to exclude python module packages). Is the proportion of those with Python scripts in addition to other code really that low? Would something like apt-file be split into 3 - apt-file, apt-file-perl-scripts, apt-file-python-scripts? -- 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/1366501352.1964.55.camel@glyph.nonexistent.invalid
Re: multiarch and interpreters/runtimes
Helmut Grohne wrote: Barring any mistakes this appears like a possible solution to the problem. Did you spot anything obviously wrong? Any example where you don't see how to work it out? It seems correct at first glance, but not enough to solve all the issues mentioned. Currently existing package relationships lack information that is necessary to do the right thing in all cases. Consider different kinds of dependencies a package P can have on package Q: 1) P contains code for arch that links with code from Q. Q needs to work for arch. 2) P executes a binary provided by Q. Any arch for Q is OK. 3) P runs a script using system interpreter X, and depends on the interpreter environment supporting functionality provided by Q. Q needs to work for the arch matching installed version of X. 4) P runs a script in an embedded interpreter in its arch code, and depends on the interpreter environment supporting functionality provided by Q. Q needs to work for arch. In the most common case dependencies on a package Q are either all of type 1 or all of type 2, as long as Q only exposes one kind of interface; in the current multiarch spec Q indicates this by Multi-Arch: same for 1 and foreign for 2. However, dependency types 3 and 4 require adding more information in the depending package to allow determining what arch needs to be supported for Q. -- 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/1366422248.1964.26.camel@glyph.nonexistent.invalid
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
Samuel Thibault wrote: Uoti Urpala, le Mon 01 Apr 2013 05:12:46 +0300, a écrit : Distributions that make latest software available are necessary for free software development. Again, that's one of the things experimental is for. It is not. You can't reasonably install things from experimental rather than unstable by default, nor is there a flag for this really should be in unstable if not for badly managed release which would allow autoinstalling those packages. Consider the GDB example I mentioned earlier; GDB 4.5 should be installed by default for users of unstable, rather than expecting them to notice that their system has become too outdated, investigate it and find out which package to manually update. It is unreasonable to tell the users and upstreams that Debian is going to keep users on a known inferior version by default for a long time, just in case more testing is needed to discover problems in the release version (often in addition to multiple already discovered problems that Debian is intentionally leaving for users to suffer from, as the most natural way to fix them would be to update to a newer upstream version). Also, many things don't get separately packaged in experimental, like GDB 4.5 isn't (I don't know whether this particular case is due to release or maintainer otherwise not keeping it up to date, but there are lots of extra issues due to release, and most of them are unlikely to be because of maintainer being too busy with other release work). -- 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/1364816331.1928.103.camel@glyph.nonexistent.invalid
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
Neil McGovern wrote: On Mon, Apr 01, 2013 at 02:38:51PM +0300, Uoti Urpala wrote: It is unreasonable to tell the users and upstreams that Debian is going to keep users on a known inferior version by default for a long time, just in case more testing is needed to discover problems in the release version (often in addition to multiple already discovered problems that Debian is intentionally leaving for users to suffer from, as the most natural way to fix them would be to update to a newer upstream version). You may consider it most natural, the rest of the project values stability and not introducing untested new features. I think you misunderstood that as saying I wanted to change packages in stable; the above was from the perspective of unstable (the natural way to fix known issues in unstable would be to upload a new upstream version). I do not believe there is any project-wide consensus to avoid newer versions in unstable. Perhaps you may feel more at home in a different distribution which aligns with your priorities more. I think unstable works reasonably well outside release problems (there are sometimes issues with new enough packages not being available, but I think those are mostly due to activity of individual maintainers, not project priorities). And I don't believe it to be a shared view of all Debian maintainers that only stable releases matter, and users of unstable are only tools to use to polish stable. Nor do I believe that all other users of unstable are only trying to help create stable releases for others to use, intentionally sacrificing their own experience to do so. And whatever distro I personally choose, as upstream of packaged software I certainly do not approve of Debian leaving its upstable users at a known inferior version during long release freezes. -- 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/1364827693.1928.122.camel@glyph.nonexistent.invalid
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
Philipp Kern wrote: On Sun, Mar 31, 2013 at 12:33:46PM -0500, Dirk Eddelbuettel wrote: I cannot influence the R release cycle which happens within our freeze. As have a few previous R releases, and none of those created any trouble. Thanks for trading the R release cycle with Debian's and for delaying the release. The harm has already been done, so somebody should probably go and create a transition tracker for it? IMO it's important to remember that it's fundamentally the release team that is at fault for problems here, not the R maintainer. Unstable has already been frozen for much longer than is in any way reasonable for either development of Debian, users of Debian unstable, or upstreams whose current software is either not being packaged at all or is only in experimental. I've personally seen as upstream many users suffering from problems caused by old version in unstable (and had to deal with those problems caused by Debian). And as a Debian user I've suffered in multiple cases from outdated software myself; latest was just today when I noticed that Debian's GDB version is too old to understand the default debug information format produced by current GCC. I've used Debian because I think that much of the packaging has been done well technically. But releases have never been Debian's strong point, and when you have to compile basic software like GDB yourself it's hard to recommend the distro for development either (in this case there was no working version in experimental either; having it only there would have been better than manual compiling but not in any way adequate IMO). -- 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/1364766488.1928.22.camel@glyph.nonexistent.invalid
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
Neil Williams wrote: On Mon, 01 Apr 2013 00:48:08 +0300 Uoti Urpala uoti.urp...@pp1.inet.fi wrote: Philipp Kern wrote: Thanks for trading the R release cycle with Debian's and for delaying the IMO it's important to remember that it's fundamentally the release team that is at fault for problems here, not the R maintainer. The length of the freeze is not the fault of the release team. The length of the freeze is down to all of the contributors to Debian not fixing enough RC bugs - I count myself in that, I've managed to get massively less done for this release than for previous ones. There are reasons, it doesn't change the reality that the freeze is still ongoing. IMO it is at some level the fault of the release team, either in setting the goals for the release or in carrying out the implementation of those goals. Package maintainers were able to keep unstable in a much better shape before release freeze, and I see no reason to believe they would have failed to continue if not for interference from the release process. And there is no inherent reason that a release would have to interfere that badly. Perhaps the task of making a release with existing resources is simply too hard, so that the people trying to do the work should not be blamed overly much for failing, and instead the goals should be lowered. But IMO it's a fact that the release management has been a failure; the release process has caused problems for users and upstreams, and the release will once again be largely obsolete by the time it's out. The release team have been looking for help to triage unblock requests and some help has been given, but even if unblocks were all handled, there remain too many RC bugs and that is and always has been the core problem. The release team are not responsible for fixing RC bugs - that's down to the rest of us. Release-critical bugs delay releases, not the release team. Note that my main criticism was not about the delay of the release itself, but about the harm the release process causes to unstable. Unstable matters to both users and upstreams (and probably several derivatives too). Having latest upstream versions easily available to users is important for the development of many projects, and IMO Debian is big enough that it keeping users of even unstable on old versions is a serious issue. I see the Debian release situation as closely analogous to how big banks were bailed out with taxpayer money due to being too big to fail; the release process is similarly too big to fail. In most cases, if developers can't implement something without seriously harming users and other developers, then they simply can't do it. But if the release team lacks the competence or resources to create a release without hurting users and other developers, then they get to hurt them, as completely failing to release is seen as an unacceptable alternative. -- 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/1364774845.1928.60.camel@glyph.nonexistent.invalid
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
Scott Kitterman wrote: If I'm reading you correctly, you seem to believe that creating the release is somehow the release team's job. It's not. The job belongs to all of us. No, that's not what I'm saying. But I think the release team is primarily responsible for the policies that harm the work other maintainers do on unstable. A release must not be the only goal for package maintainers, and IMO it should not be an overriding one either. Distributions that make latest software available are necessary for free software development. It's not responsible for Debian to say development of new software should happen on a distro like Arch, we'll just use the results. And Debian is too big to be just for people that care about releases only; if it gathers packagers and then actively hinders their ability to work on packaging the latest versions, that hurts free software development overall. So keeping unstable in good shape and up to date is an important goal, independently of its usefulness as material for releases. If the release process only failed to create a new release in a timely manner and before it's already obsolete, that alone wouldn't be so much of an issue. But the way it's now done actively keeps other maintainers from doing useful work that they would otherwise be doing. And I don't think they should have done some other different work first is enough of an excuse to justify that. -- 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/1364782366.1928.78.camel@glyph.nonexistent.invalid
Re: Linux Future
Russ Allbery wrote: Adam Borowski kilob...@angband.pl writes: There are two ways to design a system: * a monolithic well-integrated system, granting features and efficiency at the cost of portability and hackability * the traditional Unix way, with a stress on replaceable tools that do only one thing, granting freedom to tinker, using the system in a way not envisioned by its creators ...at the cost of occasional complex, difficult-to-debug interactions between the separate components, and a larger total code base to support fallbacks and alternatives to provide loose coupling between the components. Just to complete both sides of the picture. (I'm more of a second camp person myself, but they both have drawbacks.) The traditional UNIX way is great if everyone can agree on a clean and minimal API between the components that enables thorough independent testing of the components and minimizes complex multi-component interactions. Were that this were always the case Most of the places where people reach for other strategies are places where it's not clear those conditions hold. Whenever you have a complex programming problem, break it into a client and a server. Now you have two complex programming problems, a protocol design problem, and a security vulnerability. I'd add to this that the appropriate approach to the same problem can change over time. Using modular components can be a good strategy when you're trying to get the basic functionality working and it's likely it turns out you need to completely redo parts of the approach. However, when increasing the quality of something, it's natural for integration level to go up. Few real problems are truly modular. At a basic level you have can just have independent parser for file format X and IO layer, but when you get closer to optimal program behavior, parse file format X when input comes from disk and parse file format X when input comes from network stream may no longer be the same task. You could build a basic browser from components like UI for displaying bitmaps and relaying mouse clicks, an IO layer, and a HTML renderer that lists required extra resource files, then after getting the contents of those returns a rendered bitmap of the page. These could have simple APIs and could be developed by different people with little interaction. But when you move to higher-quality browsers, you'll at least need APIs with hundreds of elements. Those will require the developers to cooperate much more closely, and it won't be easy to switch to an equivalent component. -- 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/1359133652.1887.25.camel@glyph.nonexistent.invalid
Re: Stuff from /bin, /sbin, /lib depending on /usr/lib libraries
Petter Reinholdtsen wrote: When /usr/ is a LVM partition, this block LVM from being shut down, and leave /usr/ in a dirty state and LVM not properly shut down before poweroff. Why would this be harder to support than having / itself on LVM? Or are you saying the latter need not be supported? -- 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/1355656064.26124.6.camel@glyph.nonexistent.invalid
Re: Really, ...
Russ Allbery wrote: John Paul Adrian Glaubitz glaub...@physik.fu-berlin.de writes: Yes, I do accept vocals against systemd, but only if these are actually valid arguments. Because I want software development to be driven on technical merits and not on sympathies against or for certain people neither the stance to reject any modern developments. Free software is a social activity. The past history of qmail should be informative here (or, for that matter, both gcc and glibc, which had to go through disruptive forks to sort out long-term issues). One of the determiners of the long-term success of a free software project is the social skills of the primary maintainers, regardless of their skill as software designers. Systemd does much better than its competitors as a social activity. Neither OpenRC nor Upstart (with its highly questionable form of contributor agreement) can match systemd. You shouldn't confuse the existence of a group of vocal naysayers as the lack of a thriving community. I'm on the side of wanting to support a variety of different choices in the archive so that people can experiment and evaluate and choose what works best for them. I question the usefulness of this approach for init systems. Yes, developers do need a degree of familiarity to evaluate the merits of the systems. But personalized init systems don't make much sense; everyone deciding what works best for *them* is not a good approach. And when talking about a larger number of people and how well things work in their personal use in practice (as opposed to more in-depth technical evaluation), what matters is largely the amount of effort spent on polishing the most typical cases. Sysvinit has worked well for a significant number of people; but that's not because it wouldn't suck, but because a lot of effort has been used to paper over the problems. But to the extent that we have to pick winners and losers (and, to be clear, I think it's premature to do that for init systems), I think there's already enough evidence to show that systemd is clearly the best choice. How much more would you expect to have before it would not be premature any more? -- 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/1354230001.1887.16.camel@glyph.nonexistent.invalid
Re: Really, ...
Russ Allbery wrote: Uoti Urpala uoti.urp...@pp1.inet.fi writes: Russ Allbery wrote: Free software is a social activity. The past history of qmail should be informative here (or, for that matter, both gcc and glibc, which had to go through disruptive forks to sort out long-term issues). One of the determiners of the long-term success of a free software project is the social skills of the primary maintainers, regardless of their skill as software designers. Systemd does much better than its competitors as a social activity. Neither OpenRC nor Upstart (with its highly questionable form of contributor agreement) can match systemd. You shouldn't confuse the existence of a group of vocal naysayers as the lack of a thriving community. You've made your opinion quite clear. Message received. I think there are enough ways to measure things objectively that it's more than just my personal opinion. I'm on the side of wanting to support a variety of different choices in the archive so that people can experiment and evaluate and choose what works best for them. I question the usefulness of this approach for init systems. No one is expecting you to help, so your statement that you don't think this activity is useful is just noise. Would you expect anyone who thinks such activity is not useful to help with it? This would seem to lead to the absurd conclusion that expressing a negative view/evaluation of anything would always be just noise, regardless of technical arguments or anything else. I would consider the metadiscussion of what is an appropriate way to test/choose init systems to be meaningful. Even if it were not immediately relevant to practice, that wouldn't make it just noise. One of the features of free software is that there is no need to concern onself with the (presumably billions) of people who *don't* want to work on something. Only the people who *do* want to work on something matter, provided that they include the resources to do the minimum amount of work required to coordinate this sort of flexibility. This would be more applicable if I had been telling you exactly how you should go about adding support for init systems other than systemd. But I didn't. I think there's already enough evidence to show that systemd is clearly the best choice. How much more would you expect to have before it would not be premature any more? I don't see any need to have a firm answer to that question at this time. The point is less about the amount of evidence required and much more about the fact that there's no reason to make this decision unless and until we actually need to as a project. We're not at that point. There's no need for Debian to make a formal decision that will be set in stone no matter what. But what you said was that it would be premature to pick winners and losers for init systems. I don't consider it premature to pick systemd as a winner; there's a difference between keeping your options open and claiming that they're all still equal. You don't need to make a _final_ decision yet. But that does not mean it would be premature to say that it seems pretty clear what the decision should be. At this point, the single most annoying thing about systemd is the people who are advocating it on debian-devel at every opportunity and seem incapable of shutting up about it for more than a week, even though the repeated conversations are both useless to the project as a whole and don't vary with repetition. This thread was started by an anti-systemd poster, not people advocating it. I don't see any justification for you to focus your blame on systemd *supporters*. Since you wrote this in a reply to me, I assume you meant that people advocating it to apply to me at least to some degree. The primary reason I wrote my original reply is that you made a misleading comparison between qmail (lack of working community) and systemd (working community, outsiders who complain). I can't see how you could claim that you're not significantly more guilty yourself of useless posting (or whatever your exact complaint is) than I am. -- 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/1354237847.1887.48.camel@glyph.nonexistent.invalid
Re: Really, ...
Andrej N. Gritsenko wrote: John Paul Adrian Glaubitz has written on Friday, 30 November, at 1:04: Absolutely true. And this is actually why I don't understand so many people get so emotional when it comes to software like systemd or Pulse-Audio. Well, without any emotions. In last 2 years I've installed Ubuntu and Debian systems 7 times. 3 times sound just haven't worked. 2 times sound worked unstable from beginning. 1 time sound worked but I've got complain after a month that it sometimes ceases to work so they had to reboot the system. All those systems were fixed by deinstalling Pulse-Audio. Only on one laptop Pulse-Audio worked (unfortunately it has been stolen shortly so I cannot tell now if it worked stable). What I suppose to think about Pulse-Audio? You can tell me million times I am dumb and Pulse-Audio is the best, I will never trust you, I'm sorry but experience tells me just otherwise. I've looked at PulseAudio myself recently due to issues users reported with it. My view is that it's quite buggy, but there isn't much reason to blame Lennart for that, while creating the project does show sound technical judgment. On a general level, a high-level sound system like PulseAudio is necessary for general desktop use. I mostly use raw ALSA for my own playback, but that doesn't mean it would be fine as the default solution. From what I've seen of the PulseAudio code, it seems OK on a general level (I haven't looked at that much of it, but enough to debug a few different issues). Such a daemon was/is required, the general design looks OK, and nobody else has done better. So I think overall it should be taken to show that Lennart does know what he's doing. (The design is not perfect though - especially I think the client-side API could be easier to use without hurting functionality.) The people who claim just not using PulseAudio would be a fine alternative overall (on distribution level, rather than as a alternative working for certain users) don't know what they're talking about. However, current PulseAudio is still quite buggy. But I wouldn't place too much of the blame for that on Lennart (other than him not dedicating more of his time to polishing it). AFAIK he hasn't been involved much in its development for the last couple of years. And his past involvement is unlikely to be the explanation for not having better development later; other similar audio work doesn't seem to attract that many developers either - in fact some of the issues affecting PulseAudio users are due to problems at lower levels of the audio stack. -- 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/1354241767.1887.76.camel@glyph.nonexistent.invalid
Re: Really, ...
Russ Allbery wrote: Uoti Urpala uoti.urp...@pp1.inet.fi writes: Would you expect anyone who thinks such activity is not useful to help with it? This would seem to lead to the absurd conclusion that expressing a negative view/evaluation of anything would always be just noise, regardless of technical arguments or anything else. If they haven't heard the evaluation, then it may be useful information for them. Once you've already communicated the evaluation and established that they don't agree with you, then yes, this is exactly true. I'm pretty sure I haven't said anything similar about methods of comparing init systems before. Note that I did not say it's not worth comparing because it's obvious that systemd would win anyway (that's probably true, but it's something that _has_ been said before). I talked about the limitations of such an approach without reference to any particular systems being tested. It's just like a vim user going on about how horrible Emacs is. No one cares. The Emacs developers are going to keep developing on Emacs because I criticized a proposed method to compare vim and Emacs. Not vim or Emacs. There's no need for Debian to make a formal decision that will be set in stone no matter what. But what you said was that it would be premature to pick winners and losers for init systems. I don't consider it premature to pick systemd as a winner; there's a difference between keeping your options open and claiming that they're all still equal. Yes, it's been obvious for months that you think there's enough data to make a decision right now. But we're still not going to, and that isn't going to change just because you've stated your opinion for the 51st time. Just to make it clear, I'm not arguing that Debian should make a formal decision right now. What I said was about technical evaluation, not formal decision-making. And here claiming that it's premature to make a technical evaluation is itself a claim about the situation, not a neutral position (saying that you haven't yet reached an evaluation yourself is a neutral position; saying that making an evaluation is premature is not). Since you wrote this in a reply to me, I assume you meant that people advocating it to apply to me at least to some degree. The primary reason I wrote my original reply is that you made a misleading comparison between qmail (lack of working community) and systemd (working community, outsiders who complain). You misread my message. I didn't compare qmail directly to systemd. I was using qmail among others to make a general argument against the position that social factors do not matter when choosing software. I think the message you replied to had little to do with a position that social factors do not matter when choosing software, especially social factors relevant to maintaining a development community as your reply talked about. It was about the relevance of there being outsiders who complain. So maybe I read your message differently than how you intended it - but I think that was pretty natural if your intent was replying to something that hadn't actually been said. -- 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/1354246066.1887.107.camel@glyph.nonexistent.invalid
Re: Really, ...
Chow Loong Jin wrote: On 30/11/2012 10:16, Uoti Urpala wrote: However, current PulseAudio is still quite buggy. But I wouldn't place Is it, really? I haven't noticed any major issues with Pulseaudio in the past couple of years running Ubuntu. That and sound has worked out of the box with all the Ubuntu and Fedora systems I've installed in the past couple of months. I looked into it because there had been complaints about issues related to PulseAudio from users, and I was able to quickly find and analyze several bugs with no prior familiarity with the code. I do consider myself better than an usual developer, and could probably find some bugs in most projects, but I think that's still pretty strong evidence against current PulseAudio being polished code. Here's an example of one of the nastier bugs: http://cgit.freedesktop.org/pulseaudio/pulseaudio/commit/?id=29f064aa3d3a83e275361aad3f9e7efdc84b8ad0 I first sent a patch fixing that bug. A PulseAudio developer then posted an alternative approach to fixing the issue a month later. Then nothing happened for 2.5 more months until the fix was finally committed. So I think bug fixing for known bugs is not working particularly efficiently either. -- 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/1354247198.1887.117.camel@glyph.nonexistent.invalid
Re: Gentoo guys starting a fork of udev
Steve Langasek wrote: Pretty sure you have this backwards. The decision to implement upstart and use it in Ubuntu was a technical [corrected] one. The decision to NIH a dependency-based init system and then try to strongarm everyone into using it by breaking compatibility was the political one. The decision to create upstart was a technical decision. However, upstart had design flaws, and so systemd was created to do better. This was also a technical decision. Do you seriously claim that it would have been possible to work within the existing upstart project to bring it to the level of current systemd? I find that totally implausible. Ubuntu still sticking to upstart is a political decision as far as I can see; there is no technical reason why it would be a better alternative even for their own use than systemd. BTW, if systemd is a good design, why does it rely so heavily on socket-based activation, which has fundamentally unmaintainable security? What exactly do you mean by this fundamentally unmaintainable security claim? -- 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/1352929546.1952.10.camel@glyph.nonexistent.invalid
Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages
Steve Langasek wrote: On Thu, Oct 25, 2012 at 05:17:10PM +0800, Thomas Goirand wrote: On 10/25/2012 02:48 AM, Steve Langasek wrote: On Thu, Oct 25, 2012 at 01:57:12AM +0800, Thomas Goirand wrote: I remember when I started a thread about 6 months ago, willing to take over maintainership of a clearly unmaintained package (since then, all other packages of this maintainer have been orphaned...). It (unwillingly) created a huge thread about when and when not taking over a maintainer, with some of the thread participant having no clue what so ever if the old maintainer was still alive or not. Do you also remember WHY it created a huge thread? It created a huge thread BECAUSE YOU HAD PROPOSED TO TREAT SILENCE AS ASSENT. This claim seems to be false. What? Could you explain what I did? Silence from who? The old maintainer? Other DDs reading the list? So, if nobody objects within the next following 2 or 3 days, and if Jack doesn't show up and oppose to this procedure, we'll do that. https://lists.debian.org/debian-devel/2012/05/msg01362.html That's equating silence with assent. Perhaps that wasn't what you intended, but that is what you said, and that was a factor in the resulting blow-up. The mail also talked about we and us (eg: the PKG-PHP Pear team). That implies he already had the support of someone else, and they could have sent ACKs if needed (but there was no need to, as he wanted to know whether anyone opposed; the number of me toos didn't matter). None of the mails starting the discussion questioned whether the number of people in favor was sufficient. -- 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/1351312739.10719.19.camel@glyph.nonexistent.invalid
Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host
Marc Haber wrote: Amen. I find it derogatory towards the people spending months of their private time to make exotic ports work to call their work toy ports. There are people who use their time doing things like hopping across a continent on one foot. That is a lot of work, but it's not particularly useful to anyone. Amount of work alone does not imply something deserves support. At best it's harmless; if the people doing it insist others help them, or otherwise hinder others doing more useful things, then it's contemptible. -- 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/1345375164.1896.23.camel@glyph.nonexistent.invalid
Re: CD sizes again (and BoF reminder!)
Simon Paillard wrote: On Sat, Jul 21, 2012 at 09:25:50PM +0300, Uoti Urpala wrote: So at least in this case the biggest performance problem by far is the inappropriate use of fsync() or other disk synchronization primitives, and CPU use for unpacking is pretty much irrelevant. Though the kernel will have to sync sooner or later The normal background writes to disk don't affect performance all that much. The problem is sync operations that force disk waits before continuing with the install. Copying the debootstrap directory from tmpfs to disk after installation took about 6 seconds, whereas doing the syncs between installation steps added about two minutes to the install time. , I understand debian-installer ask dpkg not to fsync: - Run dpkg with --force-unsafe-io during installation; syncing is This only affects one particular instance of syncing (which I think may be useless anyway on normal ext4 after write+rename reliability was improved in kernel commit 7d8f9f7d150dded7b68e61ca6403a1f166fb4edf). It does not disable ALL disk sync operations in dpkg, like installer/debootstrap use should. I tested installing and purging libqt4-dev and some dependencies on ext4 (total 17 packages). With just force-unsafe-io in dpkg config: aptitude install libqt4-dev: 16 seconds aptitude --purge-unused purge libqt4-dev: 14 seconds eatmydata aptitude install libqt-dev: 4-5 seconds eatmydata aptitude --purge-unused purge libqt4-dev: 4-5 seconds So unless this is fixed in dpkg, the installer might want to use eatmydata... BTW eatmydata doesn't seem to work with cdebootstrap. I guess it uses chroot or something in a way which breaks that. -- 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/1342976322.3820.68.camel@glyph.nonexistent.invalid
Re: CD sizes again (and BoF reminder!)
Joey Hess wrote: Hideki Yamane wrote: I tested as well, and sometimes decompression with xz is so slw, it takes 6-8 times than default gz. I was just watching your DebConf presentation Lets shrink Debian package archive and I think there you said decompression with xz was between 2x and 6x slower. Is that the current number? I'm concerned with the thought that installation of Debian (as well as debootstrap) could take twice or more as long if xz were used for say, every package on a Gnome desktop CD. In d-i we try to make installation faster; slow installs make people less happy. It would be useful to have some real-world installation time benchmarks with and without xz. Does unpacking really take a substantial portion of the time used by the installer? In my experience the installer takes a LOT longer than it would take to unzip a CDs worth of data. Most of the time taken by cdebootstrap is wasted by dpkg on doing useless file syncs: cdebootstrap --arch=amd64 unstable debian-tree/ from local package cache on ext4: 138 seconds on tmpfs where dpkg can't waste time on useless syncs: 21 seconds (and a significant portion of that is used by package scripts with sleep 1) So at least in this case the biggest performance problem by far is the inappropriate use of fsync() or other disk synchronization primitives, and CPU use for unpacking is pretty much irrelevant. -- 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/1342895150.3820.11.camel@glyph.nonexistent.invalid
Re: CD sizes again (and BoF reminder!)
brian m. carlson wrote: On Sat, Jul 21, 2012 at 09:25:50PM +0300, Uoti Urpala wrote: So at least in this case the biggest performance problem by far is the inappropriate use of fsync() or other disk synchronization primitives, and CPU use for unpacking is pretty much irrelevant. My understanding is that dpkg uses fsync properly; that is, to guarantee the data is on the disk before exiting or doing things that require that data to be present. I don't currently see any bugs on dpkg that There are no things that would require that data to be present on disk in the middle of a dpkg invocation. There may be write ordering requirements if you want to guarantee some type of consistency after a crash, and there are AFAIK still no good functions to express such requirements in Linux (though I haven't checked recently); but it's important to understand the difference - the data is on physical disk semantics of fsync() are NEVER what you want within a dpkg run. Whatever the semantics are when using dpkg on a running system, all attempts to ensure on-disk consistency are wrong for installer and cdebootstrap use. If the machine crashes in the middle of installation or debootstrap directory creation, I'm not going to attempt continuing the operation from where it stopped, so on-disk consistency of the partial installation is worthless. And as the timings show, you can speed up installation by more than a factor of 5 by skipping the useless disk waits (I verified that's still true even if you add moving the directory to a persistent filesystem and then running sync after the tmpfs installation). -- 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/1342909103.3820.43.camel@glyph.nonexistent.invalid
Re: Summary: Moving /tmp to tmpfs makes it useless
Wouter Verhelst wrote: I don't think compiling C code has been CPU bound since before I was born (and I was born in the late 70s, so that's quite a while). C++ is a different matter, but still. Bullshit. GCC uses a lot of CPU unless you compile without optimization, and is surprisingly slow even if you do (nowhere near linear disk access speed). -- 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/1340068942.23020.5.camel@glyph.nonexistent.invalid
Re: Handling of changelogs and bin-nmus
Guillem Jover wrote: By definition a binNMU cannot produce a source package anyway, so I fail to see the point in this artifical need to distinguish “source” and “binary” changelogs through different files, AFAIR I already Why artificial? Isn't it a completely natural and consistent view to say that the main changelog documents changes to the source package? Binary rebuilds aren't really changes at all in this sense; the main reason they need to be tracked explicitly at this level is to generate consistent version numbers for the different binaries. Unlike entries documenting source package changes, binNMU changelog entries are not kept in future versions of the package. Doesn't that alone show there is a real significant distinction? [ Note: not crossposted everywhere like the original ] -- 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/1339522369.21597.113.camel@glyph.nonexistent.invalid
Re: Summary: Moving /tmp to tmpfs makes it useless
Serge wrote: 2012/6/10 Adam Borowski wrote: Some people asked for a thread summary. So here it is. Seriously, can't you even read what's written to you? Yes, I know it was a biased summary. So as yours. But there's a difference between mine and yours. Mine is based on some real-world applications, You've posted blatantly false claims. If you post claims like 1+1 equals 2 because the moon is made of cheese, then you're a moron, even if 1+1 does equal 2. And even if some of your arguments are valid, if you can't yourself tell the valid arguments apart from the crackpot claims that doesn't help your credibility. Do you dismiss the theory (confirmed by Uoti Urpala test script) that tmpfs+swap INCREASE number of writes and are hence bad for SSD? I think what the script shows is that there can be significant problems using tmpfs to hold large amounts of data, even if you have a lots of swap so that running out is not an issue. It doesn't show that the number of writes would increase on average. In general you seem to be quite clueless about the actual behavior of cache/swap, but you've still continued to make various claims 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/1339341085.21597.72.camel@glyph.nonexistent.invalid
Re: Summary: Moving /tmp to tmpfs makes it useless
Serge wrote: 2012/6/10 Uoti Urpala wrote: You've posted blatantly false claims. If you post claims like 1+1 equals 2 because the moon is made of cheese, then you're a moron, even if 1+1 does equal 2. (I like this example :)) It could be, it's impossible to know everything in the world, I can be wrong. What false claim are you talking about? The problem is that you've posted quite a few of those false claims, and don't seem a have a clear distinction between things you actually know and things you only have a vague guess about. You seem to make claims about both equally. For example, the page you linked for your SSDs can take 50 years of writing before they wear out claim has a first paragraph saying durability IS again an issue - much more so than it was in 2007 when the original article with the 50 years claim was written (and even then that seems to have been some particularly durable high-end server hardware). As another example, this part from your FAQ is nonsense: When you read from ext3, the oldest part of the filecache is dropped and data is placed to RAM. But reading from swap means that your RAM is full, and in order to read a page from swap you must first write another page there. I.e. sequential read from ext3 turns into random write+read from swap. There is no such difference reading from a normal filesystem or reading from swap. Iterating reads from swap can trigger writes, but if that's what you're referring to here, you've clearly either failed to understand what actually happens or are writing a very misleading description. Do you dismiss the theory (confirmed by Uoti Urpala test script) that tmpfs+swap INCREASE number of writes and are hence bad for SSD? I think what the script shows is that there can be significant problems using tmpfs to hold large amounts of data, even if you have a lots of swap so that running out is not an issue. It doesn't show that the number of writes would increase on average. In general you seem to be quite clueless about the actual behavior of cache/swap, but you've still continued to make various claims about it. I was referencing your words: Yes, I did say that it can generate writes in some circumstances. However, that does not imply your tmpfs increases writes claim in general. In what has been a default installation, I think you'd normally start hitting the tmpfs size limit before the problematic behavior shown by the script would become a serious issue. It mainly shows that make the size limits bigger may not be a good solution to the space issue. -- 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/1339354920.21597.97.camel@glyph.nonexistent.invalid
Re: Moving /tmp to tmpfs makes it useless
Goswin von Brederlow wrote: Uoti Urpala uoti.urp...@pp1.inet.fi writes: I haven't read the relevant kernel code, but that doesn't match the behavior I see. Reading a large file from tmpfs and then allocating memory results in large swap writes every time, even if the newly allocated memory is not itself immediately swapped out and the file should already be in swap from before. But does it rewrite the pages it has just read back? Or does it swap out some other pages it didn't have swapped out before? It might consider a page it just had to swap in to be more valuable than a page it had lying around for a long time and rather swap out the old page than forget the just read page. So this doesn't proof that data in tmpfs is rewritten again and again. There shouldn't be gigabytes of other pages to write. The set of changing pages in memory that would always differ from what has already been written to swap shouldn't be that large. The script below can be used to test the behavior. It creates a file, then loops alternatively reading the file and allocating+freeing memory. It's noteworthy that sometimes the read performance also drops over iterations (maybe the swap layout becomes more fragmented?). I used the given sizes for testing on a machine with 8 GiB memory. This load does run faster on ext4 than tmpfs. What kernel? I initially tested it on some older kernel; retried on 3.3. Did you not try the script yourself if you expected different results? If you did test, what results did you get? -- 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/1338900090.21597.60.camel@glyph.nonexistent.invalid
Re: Moving /tmp to tmpfs makes it useless
Goswin von Brederlow wrote:
Le vendredi 25 mai 2012 à 16:01 +0300, Uoti Urpala a écrit :
There is one significant difference though. When you read data back to
memory from swap, the kernel does not remember that it already exists on
disk; when the data is evicted from memory again, it is unnecessarily
rewritten to disk rather than just dropped. Thus, if you do multiple
read iterations through a large set of data (which does not fit in
memory) on tmpfs, each iteration does disk read AND write rather than
just read.
Linux certainly has a notion of cached swap, i.e. pages from swap that
are also unmodified in memory. As long as you have enough swap the
kernel should not reap the swapped data and know that it is already on
disk when it wants to evict the page.
I haven't read the relevant kernel code, but that doesn't match the
behavior I see. Reading a large file from tmpfs and then allocating
memory results in large swap writes every time, even if the newly
allocated memory is not itself immediately swapped out and the file
should already be in swap from before.
The script below can be used to test the behavior. It creates a file,
then loops alternatively reading the file and allocating+freeing memory.
It's noteworthy that sometimes the read performance also drops over
iterations (maybe the swap layout becomes more fragmented?). I used the
given sizes for testing on a machine with 8 GiB memory. This load does
run faster on ext4 than tmpfs.
#!/usr/bin/python3
FILESIZE = 50
MEMSIZE = 65
FILENAME = '/tmp/alloctest'
from time import time
def main():
print(creating file)
t = time()
with open(FILENAME, 'wb') as f:
ss = FILESIZE
while ss:
s = min(ss, 100)
f.write(b'x' * s)
ss -= s
print(file creation time: %.1f % (time() - t))
i = 0
while 1:
print(iteration %d, reading file % i)
i += 1
t0 = time()
t = t0
with open(FILENAME, 'rb') as f:
while f.read(100):
pass
print(file read time: %.1f % (time()-t))
print(filling memory)
t = time()
s = b'x' * MEMSIZE
print(memory fill time: %.1f % (time()-t))
t = time()
b'aaa' in s
del s
print('memory read time: %.1f' % (time()-t))
print(total time: %.1f % (time()-t0))
print(press return for next iteration)
input()
main()
--
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/1338571137.21597.28.camel@glyph.nonexistent.invalid
Re: Orphaning php-codesniffer, then take it over by the PHP PEARteam
Steve Langasek wrote: On Thu, May 31, 2012 at 06:15:47PM +0200, Bernd Zeimetz wrote: Especially do I fail to understand why a member of the TC, who took part in such discussions before (https://lists.debian.org/debian-devel/2006/05/msg00457.html to name an example), and encouraged people to do so (that is how I understand the mentioned mail), So to be clear, no, I was not endorsing a hijacking of that package. My The bacula package *was* in bad shape at that time, and something needed to be done. That doesn't mean the particular something that was done - starting a painful flamewar on debian-devel that led to the previous maintainer deciding to walk away from the package (i.e., voluntarily orphaning it after being demotivated) was the right thing to do. However, since the maintainer did walk away voluntarily, the TC didn't really have grounds to intervene... and probably wouldn't have sided with him anyway, so probably wouldn't have been less painful. I don't think the outcome can be accurately described as voluntarily orphaning it after being demotivated. He didn't really orphan it; he only gave up trying to get it back after it had already been hijacked and he could not find sponsors to upload his competing version. Many of the earlier hijack mails on debian-devel also followed a very different process than the one described in the present thread (e.g., allowing an indeterminate amount of time, resulting in the original maintainer resuming maintenance of the package - https://lists.debian.org/debian-doc/2006/09/msg00071.html); or resulted The linked-to mail does not show such a resolution; changelog shows that the original maintainer made one more upload, there was one NMU, and then the would-be hijacker took over the package anyway. in amicable resolutions, with the previous maintainer explicitly approving the hijacking (https://lists.debian.org/debian-devel/2001/05/msg00183.html); or were intercepted by someone in the know, who diverted the hijack to an NMU (https://lists.debian.org/debian-devel/2006/07/msg00568.html). Unfortunately, it seems this has served as precedent, and the message people have taken away is that it's perfectly ok to hijack packages... when almost none of the hijacking statements have ever resulted in anything of the sort. In 3 of those 4 cases the maintainer did change. I think making extra bureaucracy a hard requirement would likely have a negative total effect, due to some desirable takeovers like the Bacula one not happening at all as a result. is now on a killing spree. All he is doing is to encourage people to give up their idea to improve Debian. From hijacks to killing sprees... yes, I definitely think there's a language barrier of some kind here. ;) You seem to think it's a contradiction to both use a term with negative connotations such as hijack to describe an action and to say that the action is the right thing to do. I don't consider it contradictory. The word hijack acknowledges that it is a controversial action, one which you should expect to defend, and which perhaps wouldn't be required in an ideal world. But it can still be the best choice in practice. -- 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/1338591082.21597.51.camel@glyph.nonexistent.invalid
Re: Moving /tmp to tmpfs makes it useful
Serge wrote: you eat cache memory. Meaning, you store /tmp files in cache even when they're not used, so kernel cannot use that memory to store some useful files. This increases I/O and makes the system slower. The tmpfs files will be written to swap if they aren't accessed much and the kernel wants to cache other files. I mean, why would people want that feature? The only case I can think of: people with notebooks having SSD-disks, who want to reduce number of disk writes. And they usually want to do that for the whole disk, not just /tmp. There're a lot of ways to do that (starting from tuning kernel The reason normal filesystems write data to disk relatively soon is not that it would be good for performance, but to avoid losing data in a crash. Even if you're willing to accept a somewhat higher risk of data loss on such a notebook, you'd very rarely want to use settings appropriate for /tmp where it's OK to lose any or all writes done since the machine was booted up. Thus your do that for the whole disk comparison is wrong. Also, nowadays normal filesystems are journaled; using a journal for writes to /tmp damages the SSD for zero benefit. -- 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/1338414409.21597.13.camel@glyph.nonexistent.invalid
Re: Moving /tmp to tmpfs makes it useless
Josselin Mouette wrote: Files which are written on a regular filesystem stay on memory. This is called the buffer cache. Whenever they are not used and/or the system needs to reclaim memory, they are trashed. Files which are written on a tmpfs stay on memory. Whenever they are not used and/or the system needs to reclaim memory, they are swapped. There is one significant difference though. When you read data back to memory from swap, the kernel does not remember that it already exists on disk; when the data is evicted from memory again, it is unnecessarily rewritten to disk rather than just dropped. Thus, if you do multiple read iterations through a large set of data (which does not fit in memory) on tmpfs, each iteration does disk read AND write rather than just read. -- 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/1337950893.1831.25.camel@glyph.nonexistent.invalid
Re: RFC: OpenRC as Init System for Debian
Philip Hands wrote: The traditional Debian approach to /etc is largely self documenting, to the extent that one can generally walk into a site cold and (having established that they have decent backups) cheerfully do an upgrade on their Debian servers without anything breaking (I do this regularly). If you walk into a site cold, how do you tell if they have weird local configuration for something? It's much easier to check if there's something under /etc than to start checking whether the files match what's expected for the package version, if the the default files are always there even if nothing has been configured. The sources of potential breakage are highlighted by the packaging system, at which point you can read up on any package that needs attention with which you're not already familiar, while ignoring the ones that upgrade cleanly. And why would this have to be any worse with etc-overrides-lib? Why would this cause problems for Debian, except at most needing some changes to tools to better support this case? Or do you think implementing that would be hard? Are you volunteering to do that? If not then stop making assertions that simply require someone else to do a load of work to pander to your unusual tastes. If you are volunteering, then that's somewhat better (although I would prefer that we simply fix the packages to behave themselves in a proper Debian way instead). No, I'm not volunteering, mainly because I don't want to program in shell (which ucf seems to be implemented in). I can still estimate what such an implementation would need to do. You can't argue that everything which has not already been implemented would be a huge fundamental problem. If you want to argue that etc-overrides-lib would be fundamentally bad, hard to support, or undesirable to even try to support in Debian, then you should say more about implementation difficulties than just it's not implemented at the moment. George Danchev gave a proposed implementation of change alerts in an earlier mail: http://lists.debian.org/201205110212.30503.danc...@spnet.net While there are things you'd want to improve in a real implementation for packager convenience and better user interface (and the ucf part looks like it'd incorrectly create the file under /etc by default), I think that's enough to demonstrate this is not a particularly hard problem. -- 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/1336737949.2227.181.camel@glyph.nonexistent.invalid
Re: RFC: OpenRC as Init System for Debian
George Danchev wrote: On Thursday 10 May 2012 00:22:11 Uoti Urpala wrote: Steve McIntyre wrote: No, really - please *do* do this. The fact that a lot of the software coming out of RedHat development seems to be designed solely for their use, including working around the missing/broken features of RPM, is seriously annoying. Configuration belongs in /etc, we know this. We have a well-designed and implemented set of tools in Debian based on that standard. Machine-specific configuration belongs in /etc. The default behavior of the tools doesn't. For some reason or another the vast majority of applications have not been following this approach. I'm not going to argue whether is makes sense or not. The reason why most old applications do not follow that approach (at least not yet) is pretty obvious: their authors never considered it. etc-overrides-lib semantics have only become a seriously considered alternative fairly recently. Josh Triplett provided multiple technical reasons why etc-overrides-lib is preferable. The ONLY technical reason you gave to prefer traditional conffiles was that there already is a set of tools for that in Debian. Your comparison is misguided. Which comparison are you talking about? From your following text it seems you mean the comparison between 1) criticizing Red Hat for (allegedly) letting packaging system limitations affect the choice of configuration format and 2) saying Debian should choose its preferred configuration format based on the limitations of its packaging system, though that comparison does not appear in the text you quoted. The vast majority of applications do not follow etc-overrides-lib (some will never follow) so their configuration files should be properly managed as well, and dpkg's conffiles facility, dpkg's maintainer scripts in conjunction with things like ucf and debconf are quite powerful mechanisms to employ which have been proven for the last decade. Contrast this to the rpm systems trashing locally modified configuration files in /etc/ for the last decade. It is also trivial for the debian packages to contain default configuration files so users and tools could refer to them on demand, and this has nothing to do with the packaging system itself. You're pretty much just saying that dpkg and helpers like ucf have implemented better functionality than rpm. I don't see how that's relevant to the discussion. I don't think it makes the above comparison any less valid. And generally, I don't think the packaging system issues would be so difficult that they should have a major influence on what configuration model to use. OTOH, applications following etc-overrides-lib happily run on Debian systems in the way they run on others. It is not like the semantics of separating the default and locally modified configuration files in two directories is some sort of giant invention, never heard of before. It is also trivial to guess that their configuration files could also be managed by calling tools from dpkg's maintainer scripts in order to communicate with the user or provide assistance Yes, nobody has brought up reasons why this wouldn't work. -- 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/1336668798.2227.58.camel@glyph.nonexistent.invalid
Re: RFC: OpenRC as Init System for Debian
Marco d'Itri wrote: On May 10, Bjørn Mork bj...@mork.no wrote: Agree. Copying a large set of default policies into /etc just because they *can* be overridden is not user friendly. And it does not make the defaults any more configuration either. It just hides important local changes and makes it difficult both for the user and the application itself to distinguish between defaults and configuration overrides. Wrong: You're not addressing what he said about the generally desirable /etc semantics at all, only talking about what current Debian tools would do without modifications. Do you have a reason to oppose beyond this would need some tool changes? since you have to copy the whole file to override it, Wrong: as mentioned in this thread before, one of the advantages of the etc-overrides-lib model is the option of having a file in /etc that first includes the one in /lib, then overrides just one particular value. This allows handling more updates without needing manual changes, as you can automatically pick up other updated values while keeping the override, without needing to do 3-way merges. and files in /lib have no conffiles handling, after an upgrade you will not know what was changed by you and what was changed upstream. IIRC dpkg does not store the original file (while ucf does), so currently you always lose track of what was changed by you unless you make a copy manually (or with extra tools like etckeeper). Anyway, this is about the specifics of what is supported by Debian tools now, not about any intrinsic problem with the behavior. Obviously this is not a problem for Red Hat since they do not support upgrades between major releases. Why would this cause problems for Debian, except at most needing some changes to tools to better support this case? Or do you think implementing that would be hard? -- 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/1336674656.2227.72.camel@glyph.nonexistent.invalid
Re: RFC: OpenRC as Init System for Debian
Don Armstrong wrote: On Thu, 10 May 2012, Uoti Urpala wrote: You're pretty much just saying that dpkg and helpers like ucf have implemented better functionality than rpm. I don't see how that's relevant to the discussion. The reason why it is relevant is because I don't see how the following would make this comparison with rpm relevant. in the etc-overrides-lib model you are unable to trivially merge local changes with upstream or packaging changes unless you add additional logic in the postinst to handle etc-overrides-lib. Having configuration files in /etc and using ucf or similar enables you to deal with this problem easily. Yes, you do need some tool improvements to be able to alert the user about changes. This has been mentioned before. I don't think this would be hard to add though, and not overall harder than what is already implemented for traditional conffile handling; this is not a fundamental problem with the etc-overrides-lib model. And as also mentioned before, the include option should reduce the number of cases where you need to do 3-way merging. -- 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/1336675601.2227.84.camel@glyph.nonexistent.invalid
Re: RFC: OpenRC as Init System for Debian
George Danchev wrote: On Thursday 10 May 2012 19:53:18 Uoti Urpala wrote: The reason why most old applications do not follow that approach (at least not yet) is pretty obvious: their authors never considered it. etc-overrides-lib semantics have only become a seriously considered alternative fairly recently. Implying that a fairly simplistic semantics of providing two distinct directories with configuration files, has never been considered for the last 40 years and painting it as a revolution in the application development is naive, at best. Someone certainly has considered it during the last 40 years. But most people creating applications did not consider it when deciding the default semantics of their application. Do you really want to seriously argue this? Your remark about painting it as a revolution seems to be completely made up. configuration format and 2) saying Debian should choose its preferred configuration format based on the limitations of its packaging system, Let me tell you a secret: Debian should not decide whether or not tens of thousand of applications follow a particular style of reading their configuration files. This is in the realm of application development and anyone should be free to choose their style. It would be a segregation if Debian bans applications simply because their style of reading configuration files looks funny... and Debian does not segregate. This is not a secret. Did you read what I was originally replying to? It talked about symlinking the /lib and /etc directories to the same one. Debian would not ban the application, but it _was_ about overriding the upstream choice of configuration model. You're pretty much just saying that dpkg and helpers like ucf have implemented better functionality than rpm. I don't see how that's relevant to the discussion. I don't think it makes the above comparison any less valid. And generally, I don't think the packaging system issues would be so difficult that they should have a major influence on what configuration model to use. What I was saying, I already wrote. Retelling it wrong is useless. If you had some other point, it wasn't clear. And your reply certainly does not clarify anything. If you still want to reply, try to include more factual content or arguments. -- 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/1336676978.2227.99.camel@glyph.nonexistent.invalid
Re: etc-overrides-non-etc configuration file model [Re: RFC: OpenRC asInit System for Debian]
Don Armstrong wrote: On Thu, 10 May 2012, Uoti Urpala wrote: I don't see how the following would make this comparison with rpm relevant. This is debian-devel, and we're talking about configuration file handling in Debian, which makes ucf and dpkg relevant. Yes, ucf and dpkg are relevant to the discussion. However, that doesn't mean every remark about them would be. Yes, you do need some tool improvements to be able to alert the user about changes. Right. So for every package which does this, you have to check to see whether a configuration file in /etc has had it's corresponding non-etc configuration file changed, and then offer to merge them together. dpkg does not currently offer merge functionality, so if you implement that you're actually improving over what dpkg can do now. And I believe supporting this should be a reasonably simple extension to ucf. Thus, when you fully implement etc-overrides-non-etc, you have to handle configuration files in non-etc *exactly* as if they were in etc to start with. [Lets not even start with trying to figure out how you would handle deleting a non-etc configuration file when there's a difference between a non-existent file and an empty one.] If the application requires the deletion of a file under /lib to achieve particular configuration semantics, I think that's clearly a broken application. I don't see how such brokenness would be any more relevant with etc-overrides-lib than without. So there's basically no advantage to etc-overrides-non-etc unless one hasn't bothered to implement proper configuration file handling. Advantages I mentioned earlier would still be there: It's easier to see what is local non-default configuration. Original default file is always available in a known location (and very easy to revert to, temporarily for testing or permanently). You can use .include /lib/defaultsfile then override some value, which in most cases is more maintainable than the 3-way merging required by traditional conffiles. -- 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/1336681268.2227.112.camel@glyph.nonexistent.invalid
Re: RFC: OpenRC as Init System for Debian
George Danchev wrote: On Thursday 10 May 2012 21:46:41 Uoti Urpala wrote: I don't see how the following would make this comparison with rpm relevant. It was a comparison of the packaging system facilities to handle upgrades of the configuration files of the applications. This was initially started by you as a misguided comparison between etc-overrides-lib (apples) vs. dpkg conffiles (oranges). Basically you're mixing up packaging system facilities to handle No, I didn't mix those up like that. I think you're referring to my comment about Josh Triplett providing technical reasons to prefer using etc-overrides-lib semantics, but Steve McIntyre's reply only mentioning existing set of tools as a counterargument (which was silly given his rpm comments). That was comparing the quality of their arguments, not comparing etc-overrides-lib model vs dpkg functionality. I didn't initially parse the comparison in your original post that way, because it doesn't seem like a plausible way to read my original post. Yes, you do need some tool improvements to be able to alert the user about changes. This has been mentioned before. I don't think this would You need to at least start reading some man-pages (a good start would be ucf(1), ucfr(1), ucfq(1), debconf-devel(7)) before keep jamming suggestion like improvements to be able to alert the user about changes. This is already there, and has been there for a long time, as also mentioned before. I was talking about the etc-overrides-lib case; did you misunderstand that? Do those tools already have functionality which could be used for that case as is? If they do, I don't think it has been mentioned. And as also mentioned before, the include option should reduce the number of cases where you need to do 3-way merging. You don't seem to understand that style of reading of configuration files of the applications is in the realm of the applications themselves and packaging systems facilities which help handling upgrades of these application configuration files can not frivolously add include or any other convenient option directives you are suggesting to these application configuration files. Of course I do understand that include directives require application support. I don't know where you got the idea that such directives would be added by any automatic packaging helper; this is about how user modifies configuration (use include+override rather than copy+modify). -- 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/1336683674.2227.138.camel@glyph.nonexistent.invalid
Re: RFC: OpenRC as Init System for Debian
Don Armstrong wrote: On Thu, 10 May 2012, Ben Hutchings wrote: In the etc-overrides-lib model, program defaults and local configuration are effectively being merged every time the program starts. This seems to assume that the program would always read both. systemd unit files don't work this way; rather, if the file exists in /etc, then only that version is read. However, you can use .include in the file to read the default version and then override only parts. So you can choose which semantics you want for each file you modify. This is only the case if the configuration files are fine grained enough that overrides to a configuration file wouldn't also need to incorporate upstream/packaging changes. In such a case, etc-overrides-non-etc makes perfect sense, and you wouldn't normally distribute a configuration file at all (or if you did, it'd just contain commented, current default values for commonly altered values). I don't see why you'd equate it being reasonable to override just a few values and there being no need for a distro configuration file at all. Why would it be rare for a program to need distro configuration but have some things the user would want to override independently? In cases where the configuration files are not (or co-mingled with application logic), then etc-overrides-lib is the same as running dpkg with --force-conf-old and having the configuration files in /etc. That's assuming you don't improve the tools; etc-overrides-lib does not intrinsically imply that. And of course you'd still have the other advantages which would not be the same. -- 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/1336689772.2227.158.camel@glyph.nonexistent.invalid
Re: RFC: OpenRC as Init System for Debian
Tollef Fog Heen wrote: ]] Philipp Kern You will not, however, get a conffile update prompt when the system file changes (e.g. to update your own local copy to incorporate the fix). This is something I'm pondering if we should handle in either a systemd trigger or a tool that packages shipping systemd files can call to tell the user about any changes. (Basically a wrapper around ucf, probably.) It's not specific to systemd. Any program that reads configuration under /etc can use similar etc-overrides-lib semantics, and I'd expect the number of such programs to increase. -- 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/1336573555.27990.3.camel@glyph.nonexistent.invalid
Re: RFC: OpenRC as Init System for Debian
Roger Leigh wrote: Can't we just do things the Debian way, and just provide them directly as conffiles in /etc? It's nice that systemd provides its mechanism to symlink/include the units provided elsewhere, but is this either necessary or desirable on a Debian system? Not having the files in /etc by default does have technical advantages. It's easier to see what is local non-default configuration. Original default file is always available in a known location (and very easy to revert to, temporarily for testing or permanently). You can use .include /lib/defaultsfile then override some value, which in most cases is more maintainable than the 3-way merging required by traditional conffiles. It's also preferable to avoid unnecessarily differing from the setup used on other distros. -- 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/1336580040.28230.9.camel@glyph.nonexistent.invalid
Re: RFC: OpenRC as Init System for Debian
Gergely Nagy wrote: Uoti Urpala uoti.urp...@pp1.inet.fi writes: Not having the files in /etc by default does have technical advantages. It's easier to see what is local non-default configuration. Original default file is always available in a known location (and very easy to revert to, temporarily for testing or permanently). You can use .include /lib/defaultsfile then override some value, which in most cases is more maintainable than the 3-way merging required by traditional conffiles. Perhaps then the packages that right now ship symlinks to /lib/systemd/ stuff could be changed to ship a file that consists of a single .include line? Note that the general case is not just about existing symlinks, but also cases were /etc contains no file unless you want to override default configuration, and the program then reads the default from /lib instead. That way, they can be treated as normal conffiles without any of the disadvantages of a symlink. diffing and whatnot will magically work, and we'd still have the benefit of having /lib/systemd/ separate from the /etc/systemd/ overrides. I don't see how this would avoid the need to improve dpkg diffing or add another tool. When would the change alerts trigger? dpkg wouldn't warn about the file in /lib, because it would never be modified from the default distro state by the user; and it wouldn't warn about the file under /etc, because it'd almost never change between package versions (every version would contain just the same include line). To provide alerts, something needs to be aware of the connection between the files - show an alert if the user has created/modified a file under /etc AND a corresponding file under /lib changes between package versions. Note that as described above, due to the include option cases where you actually need to do anything manually in response to such alerts should become rarer. -- 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/1336595598.2227.14.camel@glyph.nonexistent.invalid
Re: RFC: OpenRC as Init System for Debian
Steve McIntyre wrote: Josh Triplett wrote: Marco d'Itri wrote: The more I think about it, the more I suspect that the correct solution would be to just symlink /lib/udev/rules.d/ to /etc/udev/rules.d/ and so on. Please don't. As a user, I find it highly preferable for packages to install their default configuration in /lib and just have overrides in /etc, and I'd love to see that trend continue. That setup lets me trivially construct personal configuration packages that ship the overriding files in /etc, without having to play ugly games with dpkg-divert of conffiles. It also means that I don't get a pile of noise in etckeeper from all the upgrades of default configurations, so that my commits to etckeeper primarily consist of my own local changes. No, really - please *do* do this. The fact that a lot of the software coming out of RedHat development seems to be designed solely for their use, including working around the missing/broken features of RPM, is seriously annoying. Configuration belongs in /etc, we know this. We have a well-designed and implemented set of tools in Debian based on that standard. Machine-specific configuration belongs in /etc. The default behavior of the tools doesn't. Josh Triplett provided multiple technical reasons why etc-overrides-lib is preferable. The ONLY technical reason you gave to prefer traditional conffiles was that there already is a set of tools for that in Debian. Who's the one choosing his preferred configuration format based on the limitations of his preferred packaging system here? Hint: it's not Red Hat. -- 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/1336598531.2227.23.camel@glyph.nonexistent.invalid
Re: RFC: OpenRC as Init System for Debian
Steve McIntyre wrote: Uoti Urpala wrote: Who's the one choosing his preferred configuration format based on the limitations of his preferred packaging system here? Hint: it's not Red Hat. *yawn* When you've got something constructive to add to Debian development, let us know. Until that point, please go away and stop trolling. I have given technical reasons to prefer etc-overrides-lib semantics. You failed to address any of the reasons I or others have given. Instead you started by bashing Red Hat, and then gave as your only reason to prefer traditional conffile semantics the same motivation you had just alleged Red Hat of having and had bashed them for. If you post fallacious nonsense, there usually isn't much more to say to that except point out that it IS fallacious nonsense. If you want to have a constructive discussion, then try to explain what you think is wrong with the arguments for etc-overrides-libs, or what technical advantages you think the traditional conffile model has which would be more important. -- 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/1336605182.2227.34.camel@glyph.nonexistent.invalid
Re: RFC: OpenRC as Init System for Debian
Dmitry Nezhevenko wrote: On Mon, Apr 30, 2012 at 01:49:57AM +0300, Uoti Urpala wrote: Marco d'Itri wrote: - configuration files in /etc/ overriding configuration files in /lib/, to work around the inferior configuration files handling of RPM I'm not convinced that the traditional Debian way of directly editing package-created files under /etc would be preferable. I think the etc-overrides-lib alternative is technically superior in many ways: the original version is kept in a known location, it's trivial to (temporarily) revert to defaults when you suspect a problem is caused by local configuration, it's easier to see what has been locally modified and what hasn't, and especially if the program supports file inclusion (to include then override the default version) you can resolve more updates without needing to do 3-way merges by hand. The main argument against etc-overrides-lib has been that dpkg can automatically give warnings about some of the cases where you may need to update your local configuration. But this ability isn't really inherent to the directly-editing case, nor only implementable with it. I Currently dpkg allows not only warnings about some of the cases. It always warns user when config file was changed in package and user edited installed copy. And provides a a nice way to quickly take a look to changes, choose which version to use or even start shell for resolving it manually. So you just can't miss time when config should be edited at all. Wrong. Any program behavior change may require changing custom configuration, but such changes need not be accompanied by changes in the default configuration file. Currently dpkg lacks any mechanism to show warnings in these cases, even if the maintainers are aware of it. The only workaround would be to make dummy changes to the configuration files just to trigger the dpkg warnings, but this would cause other problems. Thus can't miss at all is false. With etc-overrides-lib it's not possible at all... This is not true either. You could develop tools that work in this case. I think there is no fundamental reason why such tools couldn't work better than current dpkg behavior with equal effort. An easy starting point (requiring no per-package work at all) would be to show a warning if an updated package owns a directory under /etc, and that directory contains non-package-owned files. With some extra work, still no worse than what's required for current dpkg handling, you should be able to include information about changes to the corresponding default files (if any). -- 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/1335786282.1766.57.camel@glyph.nonexistent.invalid
Re: RFC: OpenRC as Init System for Debian
Dmitry Nezhevenko wrote: On Mon, Apr 30, 2012 at 02:44:42PM +0300, Uoti Urpala wrote: Wrong. Any program behavior change may require changing custom configuration, but such changes need not be accompanied by changes in the default configuration file. Currently dpkg lacks any mechanism to You are talking about changing default values, right? Other cases More generally about things not necessarily directly related to any particular option. For example changing heuristics in the program, which may require using different options to override (even if the options themselves didn't change). With etc-overrides-lib it's not possible at all... This is not true either. You could develop tools that work in this case. Yeah. I agree. It's _currently_ not possible at all. It is possible the with etc-overrides-libs behavior. Your _currently_ not possible is about the current state of the Debian tools, not about etc-overrides-libs. My original point was exactly that the issues are due to limitations of the existing Debian tools, not fundamental problems with the etc-overrides-libs model itself. But again, it's possible but introduce new issues complications for users. I don't think it would be any more complicated to use once you're familiar with the model. -- 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/1335795081.1766.69.camel@glyph.nonexistent.invalid
Re: RFC: OpenRC as Init System for Debian
George Danchev wrote: It is entirely possible to manage configuration files from dpkg's maintainerscripts (postinst on 'configure' stage, and resp. postrm) as you find fit, or by means of ucf, and possibly in combination with debconf. One can ship a bunch of configuration files in /usr/share/$pkg, or rather /usr/share/doc/$pkg/examples/ to avoid redundancy, and have them copied to /etc/$whatever or whatever is needed. You seem to be talking about something else, not about using etc-overrides-lib semantics the same way as was meant in the messages you replied to. -- 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/1335804141.1766.76.camel@glyph.nonexistent.invalid
Re: RFC: OpenRC as Init System for Debian
Roger Leigh wrote: One of the definining characteristics of the Linux ecosystem, including Debian, has been that the system has been made up of a set of loosely- coupled compoments with well-defined interfaces. This is in stark contrast to, e.g. Windows, MacOS and other proprietary systems, which have extremely tight coupling between their components, and where being able to swap out one component for another is almost unheard of. Given that this loose coupling has enabled experimentation with a wide variety of different solutions to problems, and allowed the evolution Recent innovation related to init systems has largely happened in systemd. More conservative approaches have failed to show enough progress to solve even the immediate problems. IMO there's enough evidence that the part which needed new innovation was the interfaces and the integration between them, not the individual pieces trying to work within the limitations of the old interfaces. While sysvinit is clearly inferior, it gives us (Debian) something the others do not: control over our own destiny, and the ability to modify every aspect of it and the init scripts to fit our needs. Both systemd and upstart are largely influenced by third parties. But given the rapid speed at which systemd is growing and swallowing up more and more functionality previously served by different tools, would we have the ability and will to continue to patch every bit that didn't fit our needs, and keep that working over time? If we can't, we'll potentialy end up with a technically superior system... which meets the needs of Gnome/Fedora and other distributions, rather than our own. You're not offering any competitive alternative to systemd. In fact, you're pretty much saying that that it's not realistic to maintain an alternative. If you're given a choice between using Debian from 10 years ago or the latest Fedora, would you choose the old Debian because it was made for our needs? I think there's a quite direct equivalence between preferring the 10-year-old Debian and preferring to stay with sysvinit just to control our own destiny. -- 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/1335733859.1766.23.camel@glyph.nonexistent.invalid
Re: Re: RFC: OpenRC as Init System for Debian
Marco d'Itri wrote: I am on friendly terms with many Red Hat people, but it is a fact that they take design decisions which are aligned with the needs of RHEL and these needs are often far from what is good for other distributions. - configuration files in /etc/ overriding configuration files in /lib/, to work around the inferior configuration files handling of RPM I'm not convinced that the traditional Debian way of directly editing package-created files under /etc would be preferable. I think the etc-overrides-lib alternative is technically superior in many ways: the original version is kept in a known location, it's trivial to (temporarily) revert to defaults when you suspect a problem is caused by local configuration, it's easier to see what has been locally modified and what hasn't, and especially if the program supports file inclusion (to include then override the default version) you can resolve more updates without needing to do 3-way merges by hand. The main argument against etc-overrides-lib has been that dpkg can automatically give warnings about some of the cases where you may need to update your local configuration. But this ability isn't really inherent to the directly-editing case, nor only implementable with it. I think this is better characterized as a case of Debian preferring an inferior format because that's the only thing its existing tools already support, while Red Hat is free to choose the superior format without drawbacks as it never had such tools at all. -- 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/1335739797.1766.43.camel@glyph.nonexistent.invalid
Re: state of security hardening build flag efforts
Russ Allbery wrote:
Uoti Urpala uoti.urp...@pp1.inet.fi writes:
Russ Allbery wrote:
+pie causes a fairly ordinary regular binary (gnubg) to die with a bus
error immediately upon execution. If someone could figure out why and
whether it's a general class of problems or something peculiar to that
code, I'd be feeling more optimistic about enabling PIE more broadly.
I tried building it with +pie on AMD64. It ran without crashing.
Try on i386. That's where I had the problem. (Sorry, I should have said
that.)
I tried it on i386 now. The binary didn't start; however, I did not see
any bus error. Rather, the kernel immediately kills the new process with
SIGKILL before any code starts executing. The issue is triggered by the
huge static amMoves array declared in eval.c function GenerateMoves, and
only occurs with address space randomization enabled (it runs fine under
gdb by default, unless you do set disable-randomization off). The
following program demonstrates the same issue if compiled with -pie:
char a[19500];
int main(void) { return a; }
I think the reason for this behavior is that with address space
randomization and PIE the array is placed in or above the mmap segment
of process memory, and that has a predetermined size which may be too
small for big objects. The same program actually works if I use ulimit
-s 50, which reserves more space at the top of the address space.
--
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/1335128169.1791.20.camel@glyph.nonexistent.invalid
Re: state of security hardening build flag efforts
Russ Allbery wrote: +pie causes a fairly ordinary regular binary (gnubg) to die with a bus error immediately upon execution. If someone could figure out why and whether it's a general class of problems or something peculiar to that code, I'd be feeling more optimistic about enabling PIE more broadly. I tried building it with +pie on AMD64. It ran without crashing. -- 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/1333809738.2347.15.camel@glyph.nonexistent.invalid
Re: On init in Debian
Russ Allbery wrote: Josselin Mouette j...@debian.org writes: I’ve not seen many people interested specifically in upstart in this discussion, apart from Canonical employees. For the record, I'm interested specifically in upstart because I think that alignment with Ubuntu is a major win for Debian in terms of the ecosystem and aiding our already extensive sharing of packages. I don't consider that benefit to be overwhelming, and I could be convinced that systemd is the way to go even if it doesn't give us that if it's sufficiently technically better. But I think it's an important thing to keep in mind. Alignment with Ubuntu could give short-term benefits. But using Upstart would practically ensure that the init systems used by major distributions would continue to differ. This is definitely not in the long-term interest of the Linux ecosystem as a whole. Fedora will not switch to a technically inferior system for the sake of compatibility with Debian. On the other hand, I'm not aware of any reasons why Ubuntu would need to keep its own init system, other than NIH and the short-term cost of switching. If it's determined that systemd is the best init system for Debian, then IMO the most appropriate way to ensure alignment would be to put pressure on Ubuntu to abandon Upstart. If Debian implements a well-tuned systemd setup then adopting that in Ubuntu should not be too difficult. To view this from another angle: the major wins of Debian-Ubuntu alignment apply equally much or more to Ubuntu. Why should you consider the Ubuntu decisions to be set in stone, and the Debian side obligated to bear the costs of compatibility by adapting to Ubuntu decisions, even if those decisions are considered suboptimal? -- 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/1333287018.24970.55.camel@glyph.nonexistent.invalid
Re: On init in Debian
Russ Allbery wrote: Samuel Thibault sthiba...@debian.org writes: It is apparently trying to be a *Linux* standard, being adopted by all distributions. That's not at all clear to me. It seems more to be trying to be a good init system used by Fedora, and beyond that it's left to people to make up their own minds, although of course the author thinks it's good and more people should use it. Most people like the things they've written. :) I think systemd does clearly aim to be a Linux standard. A number of features exist specifically for the sake of allowing better cross-distro compatibility. Some previous distribution-specific interfaces on Fedora have been deprecated. Upstream has explicitly talked about a goal standardizing interfaces between distributions and about specific integration issues with other distributions that affect systemd design (for example in http://0pointer.de/blog/projects/on-etc-sysinit.html). Some GNOME features have started using systemd interfaces and deprecated the previous implementation (at least ConsoleKit). The goal seems to be to eventually have systemd in a position similar to udev, which is now quite standard and is not usually considered as distro-specific 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/1333215588.24970.25.camel@glyph.nonexistent.invalid
Re: On init in Debian
Martin Wuertele wrote: * Uoti Urpala uoti.urp...@pp1.inet.fi [2012-03-23 19:44]: IMO your [Steve Langasek's] upstart advocacy and anti-systemd FUD crosses the line between having your own opinions and having your own facts. There was neither FUD nor advocacy in Steves mail and no hostile attitude towards systemd. IMO calling comments like The current [bad] state of upstart in Debian is a reflection of the upstart maintainers' respect for Debian and desire to not destabilize the distribution advocacy is perfectly accurate. Especially when systemd in Debian works much better, without causing such destabilization. Note that my comment about his FUD posting was not based only on the mail I was replying to. I've already commented on false claims he's made earlier: http://lists.debian.org/debian-devel/2012/02/msg00935.html http://lists.debian.org/debian-devel/2012/02/msg01177.html http://lists.debian.org/debian-devel/2012/02/msg01182.html In contrast to your systemd advocacy as the new default init Steve outlined the necessary changes to provide upstart as an alternative to He posted some actual information and some quite dubious claims. My posts about systemd have been more objective. The RHEL 6 uses upstart [1] and while it is true that Fedora is using systemd I could not find any evidence that RHEL intends to change any time soon. I think the evidence I described in my mail is quite significant. Whether the switch actually happens soon is another question; but that's due to RHEL being maintained in a very conservative manner. Note that Steve wrote no indication, and without any qualification such as soon. Would you really honestly say there's no indication of RHEL switching away from upstart? -- 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/1332778117.1709.24.camel@glyph.nonexistent.invalid
Re: On init in Debian
Steve Langasek wrote: The current state of upstart in Debian is a reflection of the upstart maintainers' respect for Debian and desire to not destabilize the distribution by triggering an avalanche of package conversions that could quickly take us past the point of no return for bit rot of our init scripts. While systemd has been introduced without such destabilization... Whereas there's no indication that RHEL is switching away from upstart. Really? Fedora switching to systemd and Red Had employees adding systemd-dependent features to other projects doesn't indicate anything whatsoever? IMO your upstart advocacy and anti-systemd FUD crosses the line between having your own opinions and having your own facts. -- 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/1332527357.25977.89.camel@glyph.nonexistent.invalid
Re: upstart: please update to latest upstream version
Steve Langasek wrote: There are also complications to using cgroups, in that suddenly any service that needs to be able to spawn long-running processes that outlive the service has to start caring about cgroups - both so that they survive the service being shut down from the outside, and so that the supervisor knows not to count these processes as evidence that the service is still running. In most cases the daemon does not need to care about these, and at most simple options in the .service file are needed. systemd has a concept of main process which is used to determine whether or not the service has failed (with a couple of possible ways to identify this - for nicely behaving daemons this is just the process originally started by systemd). The KillMode option in .service files can be used to control which processes are killed (default is everything in the cgroup, alternatives are just the main process or nothing). The systemd.service man page is worth reading to see the available settings. ssh is going to be the first problem in this regard, though I'm sure there will be others. Has someone patched openssh to be cgroup-aware? As above, setting KillMode is enough to avoid killing spawned processes. Logins through ssh do have their own cgroup rather than being placed under the sshd.service cgroup. However, I think that doesn't happen due to any changes in sshd, but is probably handled by the generic user session management triggered through libpam-systemd. -- 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/1331165930.25977.22.camel@glyph.nonexistent.invalid
Re: A few observations about systemd
Bernhard R. Link wrote: While there might be some problems originating from some architecture, but most problems you will see and people claim to be problems specific to fringe architectures are actual bugs in the program you just do not *yet* see on your usual pet architectures. And some more because the program is just doing some very narrowing assumptions. Yes, such bugs do exist. However, I think the benefit of testing on other architectures to uncover such bugs has been exaggerated. Many of the problems that end up taking the most time are toolchain issues specific to the architecture. Typical free software projects already have multiple known issues that actually affect people even on popular architectures; ability to find one more thing that's in principle broken is not particularly valuable. It's mainly the relatively simple projects or projects with exceptional developer resources (like parts of the kernel) where ability to find more bugs results in quality improvements with any kind of consistency. Debugging things on architectures you don't normally use, often remotely on unfamiliar systems, is likely to be slow and not have a particularly good results/effort ratio. Note that I'm not opposing having Debian on multiple hardware architectures. But that's mainly because I think it doesn't necessarily require major extra effort, not because I'd consider such hardware support to be essential. Imagine how long amd64 would have taken, if people had not had years to fix all those 64 bit bugs on alpha first (Which never really got a mainstream architecture and where it was used was quite server-only. Who would have guessed that fixing games to run there would have had benefits in a so soon future?) I'm not sure exactly how long more AMD64 support would have taken without Alpha, but I think it would have become supported reasonably fast in any case, and likely with substantially less overall effort than by fixing issues as they come up through Debian Alpha builds. First upstream developer of a game gets an AMD64 machine and makes the game run on it is just inherently a lot more efficient than Debian maintainer forwards reports about game not working on Alpha. Considering the introduction of AMD64 overall, I think Debian did a pretty bad job - avoiding the fuck-ups in the introduction of the architecture in Debian would have helped a lot more than the 64-bit preparation with Alpha. If you want to help the development of upstream projects in general, there's an obvious thing that could use more resources: make sure that the latest upstream code is always available in Debian unstable (or if it's likely to cause breakage, at least in experimental), and don't let the introduction of new upstream versions in unstable stop around releases. Getting more feedback about changes quickly is a lot more important than testing on unusual architectures. -- 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/1330375471.5387.174.camel@glyph.nonexistent.invalid
Re: upstart: please update to latest upstream version
Steve Langasek wrote: If no one's measured it, then converting scripts to C programs to avoid the added exec() calls is premature optimization. If the only You keep repeating the same FUD. Again, avoiding shell is not just an optimization, much less a premature one. Also, if I understand the original poster correctly, this included cases where you would not have needed any separate C program either with systemd. One of the worst contributors to the use of 'script' in upstart jobs instead of 'exec' is the need for backwards-compatibility with pre-upstart /etc/default/* files. The options here are all fairly poor: - ignore the admin's /etc/default settings when switching init systems - migrate any local changes to /etc/default into the upstart job at upgrade time, by editing a conffile in a maintainer script - keep sourcing /etc/default at runtime I guess systemd has largely chosen option 1 (in part because there's a weird view in the systemd community that these jobs belong upstream, so Debian integration issues are entirely ignored). For many upstart jobs in Ubuntu, The systemd view is that this configuration should be standardized rather than every distro using a random different method. I don't think that view is at all weird. Debian integration issues are entirely ignored is again FUD - standardization does require some kind of transition, but Debian has in no way been ignored here (and no this standardization does not mean simply adopting the old Fedora setup or anything like that). -- 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/1330377076.5387.192.camel@glyph.nonexistent.invalid
Re: upstart: please update to latest upstream version
Goswin von Brederlow wrote: Steve Langasek vor...@debian.org writes: /etc/default/* files. The options here are all fairly poor: Option 2 is also bad. There is a reason why we have /etc/default instead of setting the options in the init.d scripts directly. Most importantly the init.d scripts can be updated without dpkg questions. See http://0pointer.de/blog/projects/on-etc-sysinit.html for a description of the systemd upstream view (which also shows that Debian has hardly been ignored like Steve Langasek claimed). The comments also address some of the issues. -- 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/1330383187.5387.200.camel@glyph.nonexistent.invalid
