Re: Bug#727708: Fsck SystemD and its developers and its users. GR to override this please.
On 02/11/2014 12:53 PM, Clint Byrum wrote: Excerpts from Thomas Goirand's message of 2014-02-10 20:20:36 -0800: On 02/11/2014 04:10 AM, John Paul Adrian Glaubitz wrote: Do we allow users to choose their FireWire stack, WiFi or Audio Driver stack in the kernel? There were several alternative implementations of these, yet we only provide one of each. I don't see why we would explicitly forbid this choice (which has nothing to do with what we provide by default). Last time I checked, it was possible for our users to rebuild their own kernel. We even provide some userland tools for that. In the case of init system choice, having choice means having packages that work poorly with the non-default init system. Nobody wants to forbid OpenRC or Upstart. Having all four working init systems is a lot like having kFreeBSD and Hurd. However, the reason we can have kFreeBSD is basically POSIX. Some things don't work, but the majority of things do work. There is a long standing set of rules that things play by for the most part, and when they diverge, that is a choice they make. By and large these init systems work nothing like eachother. So having lots of them, means having lots of variation in init scripts, or having a lowest common denominator init format which AFAIK does not exist and would not achieve anything a switch away from sysvinit is intended to solve. So, perhaps if we teach Upstart and OpenRC to read systemd unit files, and they all can be expected to behave similarly, this will work out. Otherwise, giving everyone a choice just makes work for little gain. You are talking as if we were starting from zero. Reality: all of our packages support both sysv-rc and OpenRC. We only have to maintain that, which is anyway important for our non-linux ports, and none of us have a crystal ball to predict how it will happen. I don't think it's a good idea to just give-up, or to spread the word that we should (give-up) before things even happen. The situation with upstart or systemd, if not chosen as default, will be quite different, since not all packages are supporting them directly right now. One of these 2 will suffer from the choice of default init system. Cheers, Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52f9d91e.8040...@debian.org
Re: Bug#727708: Fsck SystemD and its developers and its users. GR to override this please.
Excerpts from Svante Signell's message of 2014-02-10 21:49:56 -0800:
On Mon, 2014-02-10 at 20:53 -0800, Clint Byrum wrote:
So, perhaps if we teach Upstart and OpenRC to read systemd unit files,
and they all can be expected to behave similarly, this will work out.
Otherwise, giving everyone a choice just makes work for little gain.
Why should OpenRC and Upstart adapt to a format that is not standardized
in _any_ way? The format specification should be written by Debian
people (including downstream), and be a common denominator for all init
systems wanting to be compatible. The proposal could be based on the LSB
headers, and a good extension to that has recently been proposed by the
sysvinit maintainer: Two line init.d scripts
https://lists.debian.org/debian-devel/2014/02/msg00106.html
Meh. Pick one.
Additionally a very good proposal for a PID 1 program was in
http://ewontfix.com/14/ Broken by design: systemd, copied here for
convenience:
#define _XOPEN_SOURCE 700
#include signal.h
#include unistd.h
int main()
{
sigset_t set;
int status;
if (getpid() != 1) return 1;
sigfillset(set);
sigprocmask(SIG_BLOCK, set, 0);
if (fork()) for (;;) wait(status);
sigprocmask(SIG_UNBLOCK, set, 0);
setsid();
setpgid(0, 0);
return execve(/etc/rc, (char *[]){ rc, 0 }, (char *[]){ 0 });
}
Indeed, I have no problem with this approach and I'm not crazy about
systemd's scope. But if the default ends up as systemd, it gets a bonus
as the one to follow in the Linux world so IMO it is an easier choice to
just use their syntax.
--
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/1392105255-sup-5...@fewbar.com
Re: Bug#727708: Fsck SystemD and its developers and its users. GR to override this please.
On 02/11/2014 03:09 AM, Vitaliy Filippov wrote: Excuse me, but this reply isn't appropriate, just as much as the OP. Redirecting him to another Unix distribution isn't the thing to do. Instead, you should have informed the OP that we will continue to support not only systemd, upstart, or whichever becomes the default. Because that's the plan. And nobody will force anyone to use the default settings, just like nobody is forced to use the default desktop. It seems that in case of systemd it may end being forced, doesn't Gnome 3 depend on it? We have between 40 and 50 window managers in Debian. Nobody forces you to use Gnome. How about switching to TWM! :) I have another idea - maybe systemd could be split in parts in Debian? I think it would fix some objections. This has been discussed at large already. It would. But neither upstream nor the Debian package maintainers wish to have (or wish to do the work so that) systemd (is) split into relevant independent parts. This is a shame, because that's the most controversial issue, but that's a a view which can be defended: they believe in the current design, where each component is used by another. I.e. for example, systemd-journal looks like the most bloated part of systemd to me, with its binary log format, QR codes and built-in HTTP server - so maybe it could be disabled via a patch? Or even packaged separately so you can choose whether to install it? Is anyone familiar with systemd code - does it look possible and/or simple task to you? As much as I understood, systemd-journal is the part which is the most optional, and which you can avoid completely currently. Problem is: we have no idea how long this is going to be truth (as it happened with logind and other components). I don't think it is reasonable to expect Debian systemd maintainers will do the work of separating each components to make them independent. They haven't stated that this is what they want to do. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52f9dbb1.7000...@debian.org
Re: Bug#727708: Fsck SystemD and its developers and its users. GR to override this please.
Excerpts from Thomas Goirand's message of 2014-02-11 00:02:38 -0800: On 02/11/2014 12:53 PM, Clint Byrum wrote: Excerpts from Thomas Goirand's message of 2014-02-10 20:20:36 -0800: On 02/11/2014 04:10 AM, John Paul Adrian Glaubitz wrote: Do we allow users to choose their FireWire stack, WiFi or Audio Driver stack in the kernel? There were several alternative implementations of these, yet we only provide one of each. I don't see why we would explicitly forbid this choice (which has nothing to do with what we provide by default). Last time I checked, it was possible for our users to rebuild their own kernel. We even provide some userland tools for that. In the case of init system choice, having choice means having packages that work poorly with the non-default init system. Nobody wants to forbid OpenRC or Upstart. Having all four working init systems is a lot like having kFreeBSD and Hurd. However, the reason we can have kFreeBSD is basically POSIX. Some things don't work, but the majority of things do work. There is a long standing set of rules that things play by for the most part, and when they diverge, that is a choice they make. By and large these init systems work nothing like eachother. So having lots of them, means having lots of variation in init scripts, or having a lowest common denominator init format which AFAIK does not exist and would not achieve anything a switch away from sysvinit is intended to solve. So, perhaps if we teach Upstart and OpenRC to read systemd unit files, and they all can be expected to behave similarly, this will work out. Otherwise, giving everyone a choice just makes work for little gain. You are talking as if we were starting from zero. Reality: all of our packages support both sysv-rc and OpenRC. We only have to maintain that, which is anyway important for our non-linux ports, and none of us have a crystal ball to predict how it will happen. I don't think it's a good idea to just give-up, or to spread the word that we should (give-up) before things even happen. One point of moving to a system like upstart or systemd is that the sysvinit scripts do not run as scripts. They are little tiny declarative files that run all or most in C. This speeds up boot, but only makes sense if all of the early stage boot things make use of it. Leaving most things to just use the sysvinit compatibility layer means not realizing one of the more important benefits of the default init system if it should in fact turn out to be systemd. So at best you're talking about maintaining two for every daemon. That is still roughly twice the maintenance work and twice the testing. Not saying I like it, but that is where choice hurts Debian. Perhaps having the choice will also help Debian enough to make it worthwhile. -- 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/1392107208-sup-...@fewbar.com
Re: Bug#737634: dpkg-dev: please reject native/non-native version when building native/non-native source packages
On Mon, 10 Feb 2014 22:13:45 +0100 Wouter Verhelst wou...@debian.org wrote: Sigh. On Wed, Feb 05, 2014 at 12:59:23PM +, Neil Williams wrote: Using packages to support upstream development is a common problem /common problem/common source of problems/ and this is exactly where things get awkward. No, it is not a *problem*; it is a *method* of doing things. ... one which I've used consistently for more years than I've been a DD and had frequent problems with various assumptions in various tools and in more distributions than just Debian and its derivatives. Hopefully the clarification will show that I'm not questioning the methods of anyone (other than possibly my own). It is not your place (nor mine) to question another person's methods of doing things; especially not if said methods are done outside of Debian, as is here the case. ... and in my ongoing work. If using distribution tools for upstream development was easy, we might not have had people developing tools like pypi, ruby gems, CPAN or a whole range of other non-distribution distributive tools. This isn't just a Debian problem. (Indeed fixing it in Debian isn't going to fix the problems because upstreams will rarely fixate on a single distribution across the entire team - for entirely sane reasons.) It is right for upstream to want to deploy to FHS compliant paths and use dependencies from the main distribution system etc. None of the distribution tools for any of the distributions actually make it easy to then develop within those paths without either rebuilding unreleased upstream packages or copying files into privileged paths. Both of these routes need sudo access which just makes things harder again. Why must every developer have sudo access on the development box? That is exactly why pypi and buildout have got so much traction. It annoys me that I have to use such methods for upstream work because dpkg-dev is too constrained by rules which *only* relate to official builds. Doing a quick native build of a non-native package for use and distribution within a known team is a *common requirement* for upstream teams. (e.g. it means that developers can push to a branch, get a quick native package built, uploaded locally, installed via an inotify and available to test without the unnecessary step of building an .orig.tar.gz in the middle.) It's not quite as clean or DRY as restarting a daemon directly from a user-privilege git clone but it is workable. Why should that require two branches of the packaging files? Developing using Debian is not just about development of Debian. Upstream teams use dpkg-dev too. Constraints which are entirely warranted for developing packages destined for ftp-master are directly harmful for developing packages destined for a repository on 192.168. Yes this could work with overrides but those overrides need to be build specific (not package specific or version specific). This is exactly why a ~/.gbp.conf is the right approach. Not true. There are options to use debuild or pdebuild or dpkg-buildpackage in-place. e.g. I use: [DEFAULT] #builder = git-pbuilder builder = debuild cleaner = fakeroot debian/rules clean pristine-tar = True [git-buildpackage] export-dir = ../build-area/ tarball-dir = ../tarballs/ Even if so, this increases the complexity of the system, and requires people to learn yet another tool to Just Do what was previously possible with no extra fluff. It's okay for a tool (like dpkg) to warn if something doesn't look right. It's not okay for a tool (like dpkg) to pretend to be smarter than the person operating said tool. True - however, there will always be a need for tools like git-bp and it is common to use aliases and JDTRT scripts to provide a consistent interface no matter what changes beneath. Thankfully, none of those hacks make it into Debian but that does mean that people within Debian don't get to see how the tools are actually used. Switching a non-native package to native arbitrarily is a necessary use of dpkg and it needs to be supported cleanly and in a way which is easy to override using a per-build configuration option. -- Neil Williams = http://www.linux.codehelp.co.uk/ signature.asc Description: PGP signature
Re: Bug#727708: Fsck SystemD and its developers and its users. GR to override this please.
We have between 40 and 50 window managers in Debian. Nobody forces you to use Gnome. How about switching to TWM! No problem, I never actually used Gnome3, because I dislike it even more than systemd... I only tried it several times... :) I.e. for example, systemd-journal looks like the most bloated part of systemd to me, with its binary log format, QR codes and built-in HTTP server - so maybe it could be disabled via a patch? Or even packaged separately so you can choose whether to install it? Is anyone familiar with systemd code - does it look possible and/or simple task to you? As much as I understood, systemd-journal is the part which is the most optional, and which you can avoid completely currently. Problem is: we have no idea how long this is going to be truth (as it happened with logind and other components). Maybe it's optional, but there's no option to disable it currently. You can only configure it to not store logs and send them to syslog - so it will be still running. I don't think it is reasonable to expect Debian systemd maintainers will do the work of separating each components to make them independent. They haven't stated that this is what they want to do. I think Debian project is significant enough to have some influence on systemd development, i.e. at least send patches, and in this case Debian won't end up using any non-standard version. This can also reduce the risk of vendor-lock, because the speed Lennart adds features to systemd is so fast that I won't be really surprised if he adds HKEY_LOCAL_MACHINE and HKEY_CURRENT_USER next. And everyone will be forced to use that new feature [registry] if Debian project won't have any influence on systemd. That's what I call vendor-lock :) As I understand systemd has relatively active community with many developers from different distros (am I right?) so it should be no problem for Debian developers to also join it. I mean that Debian systemd maintainers could try to untangle that ball of current design, where each component is used by another and even try to upstream this work! :) ...and it really seems like a good decision to me, because it would really fix some of its problems and make systemd-haters feel better... :) -- With best regards, Vitaliy Filippov -- 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/op.xa3z7njo0ncgu9@vitalif.vhome
Re: Bug#727708: Fsck SystemD and its developers and its users. GR to override this please.
On Ma, 11 feb 14, 00:31:18, Clint Byrum wrote: Leaving most things to just use the sysvinit compatibility layer means not realizing one of the more important benefits of the default init system if it should in fact turn out to be systemd. So at best you're talking about maintaining two for every daemon. That is still roughly twice the maintenance work and twice the testing. Not saying I like it, but that is where choice hurts Debian. Perhaps having the choice will also help Debian enough to make it worthwhile. According to Russ Allbery, it's easier to maintain both systemd and upstart declarations than one sysv init script. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic http://nuvreauspam.ro/gpg-transition.txt signature.asc Description: Digital signature
Re: Bug#727708: Fsck SystemD and its developers and its users. GR to override this please.
On Ma, 11 feb 14, 06:49:56, Svante Signell wrote: On Mon, 2014-02-10 at 20:53 -0800, Clint Byrum wrote: So, perhaps if we teach Upstart and OpenRC to read systemd unit files, and they all can be expected to behave similarly, this will work out. Otherwise, giving everyone a choice just makes work for little gain. Why should OpenRC and Upstart adapt to a format that is not standardized in _any_ way? The format specification should be written by Debian people (including downstream), and be a common denominator for all init systems wanting to be compatible. And the obligatory XKCD: http://xkcd.com/927/ Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic http://nuvreauspam.ro/gpg-transition.txt signature.asc Description: Digital signature
Re: don't panic - rejoice: jessie will be awesome and supporting lots of inits! (was: Re: Bug#727708: Fsck SystemD and its developers and its users. GR to override this please.
Le lundi 10 février 2014 à 22:13 +0100, Holger Levsen a écrit : And probably jessie should come with a slogan once again: Debian - there can be more than one init system - or something like this :) Supporting multiple init systems is the least relevant thing to do, since it multiplies the work to be done. http://islinuxaboutchoice.com/ -- .''`.Josselin Mouette : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1392109535.18551.1433.camel@dsp0698014
Re: Bug#727708: Fsck SystemD and its developers and its users. GR to override this please.
On Tue, Feb 11, 2014 at 06:49:56AM +0100, Svante Signell wrote: Additionally a very good proposal for a PID 1 program was in http://ewontfix.com/14/ Broken by design: systemd, copied here for convenience: I like how people copy/paste blog articles. Did you read this article? It completely lacks detail and where it does, it is conflicting with itself. E.g. Reboot to Upgrade, while a bit later: systemd's systemctl has a daemon-reexec command to make systemd serialize its state, re-exec itself. Meaning: reboot to upgrade is not needed, answer is given in the same text. The objections to daemon-reexec are vague. It's nice to copy/paste this blog, but moving all functionality from pid1 and putting them in pid2 is cool. But you're still totally relying on everything in pid2, so same difference. It pretends to be technical, but the technical bits it does discuss are conflicting. -- Regards, Olav -- 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/20140211090835.ga24...@bkor.dhs.org
Re: Bug#727708: Fsck SystemD and its developers and its users. GR to override this please.
On Mon, Feb 10, 2014 at 11:09:10PM +0400, Vitaliy Filippov wrote: I.e. for example, systemd-journal looks like the most bloated part of systemd to me, with its binary log format, QR codes and built-in HTTP server - so maybe it could be disabled via a patch? Or even packaged separately so you can choose whether to install it? Is anyone familiar with systemd code - does it look possible and/or simple task to you? QR codes is optional Built-in HTTP server is optional Binary logging - yeah, it logs stuff. Calling logging functionality in a program which is meant to log things is a bit much. You cannot separate it, if you look at status output of a service it'll use the journal to give you useful output. Splitting things has sideeffects. If the gain is uncertain of vague (I don't like it / UNIX philosophy), then IMO time to trust the package maintainer. -- Regards, Olav -- 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/20140211091356.gb24...@bkor.dhs.org
Re: Bug#727708: Fsck SystemD and its developers and its users. GR to override this please.
On Tue, Feb 11, 2014 at 12:51:13PM +0400, Vitaliy Filippov wrote: I think Debian project is significant enough to have some influence on systemd development, i.e. at least send patches, and in this case - Debian has sent patches upstream - Mageia is *much* smaller distribution, that packager has attended *various* systemd hackfests - Mageia package maintainer sent various patches upstream - Patches are *not* accepted based on how many people you represent or which company you work for (e.g. some Red Hat dude got a no during hackfest before FOSDEM) Debian won't end up using any non-standard version. This can also reduce the risk of vendor-lock, because the speed Lennart adds features to systemd is so fast that I won't be really surprised if he adds HKEY_LOCAL_MACHINE and HKEY_CURRENT_USER next. And everyone will be forced to use that new feature [registry] if Debian project won't have any influence on systemd. That's what I call vendor-lock :) Features are discussed beforehand at loads of conferences. I think resorting to Windows registry to make a point says enough. The project is under active development, that's is a good thing. If you have needs, make them known. Be positive, not distrustful and you'll go a long way. As I understand systemd has relatively active community with many developers from different distros (am I right?) so it should be no problem for Debian developers to also join it. AFAIK people are already active. I mean that Debian systemd maintainers could try to untangle that ball of current design, where each component is used by another and even try to upstream this work! :) This is all very vague and non specific. -- Regards, Olav -- 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/20140211092139.gc24...@bkor.dhs.org
Re: Bug#727708: Fsck SystemD and its developers and its users. GR to override this please.
On 02/11/2014 05:20 AM, Thomas Goirand wrote: It's like being able to customize internal parts of your cars engine when ordering one from your dealer. Customers don't care who the manufacturer of your ignition system is as long it's the best possible one. (Yes, I know comparisons with cars are bad ;)). That's partly not truth. Some customers care, and do customization of their car. No, it's absolutely not. You can have the choice for the interior design, the paint job, the radio, the type of engine and comfort features, but you certainly cannot have the choice on internal parts like the ignition system or starter motor. Furthermore, if you do decide to replace these parts on your own, you will end up losing your car manufacturer's warranty. And this is very much what I would see in Debian. Use your desktop and applications of choice and you will get support, but if you want to change core components, you are free to do so, but you will lose support. A very reasonable approach in my opinion as you weigh the cost of maintenance vs. advantage of being able to choose. Neglecting reliability and maintainability for the sake of being able to choose such a core component is a bad idea. I do not think it's really feasible to maintain several init systems, it just affects too many components of the system. It's just up to the volunteers, which was my message. If some of us car, it's going to be possible. If there's not enough interest, then you are right. And since there are virtually no volunteers for OpenRC besides you and the other two OpenRC maintainers, Roger and Benda, it will be unsupported at some point when you guys step down. Do you really think this is a desirable situation for our users? I have seen you asking for help on OpenRC so many times during these discussion, but I am yet to see people raise their hands and say Yes Thomas, I am going to help you! All I read are statements from you like Yes, it would work in general if we had someone to implement it, I don't have the time right now unfortunately. See, I am one of the people involved in the m68k port of Debian. Just recently, one of our main contributors decided to jump the ship who cannot be replaced by someone else easily as public interest in the m68k port is simply way too low meaning we have lost lots of development manpower. Thus, I fully agree that m68k has been abandoned as a release architecture long time ago. It's nice that it's there, but there isn't any official support and the rest of Debian shouldn't have to worry about it. We don't even manage to maintain two versions of ffmpeg (the original and the fork) even though many users actually prefer the original. How should this even work with the init system then? Maybe no DD cares enough for ffmpeg? No, it's because it's not possible to have libav and ffmpeg packaged at the same time due to conflicting so names and the fact that reverse dependencies would have to be taken care of as well. On 02/11/2014 04:10 AM, John Paul Adrian Glaubitz wrote: Again, I do not understand how our users will actually profit from being able to choose their init system. It doesn't mater, we don't force our thinking on you. Nor it's a good idea that you try to convince everyone that they should adopt *your* choice. I believe there's been enough discussion so that you will agree not everyone shares your view on systemd. I don't see it as a problem anymore. It's not *my* choice, systemd is the choice of the majority of the Linux community. OpenRC and upstart are used in Gentoo and Ubuntu only (ChromeOS doesn't really count in that context, it's a more or less closed system by Google), while virtually every other of the large distributions has adopted systemd. Using something which is not widely adopted and has very few supporters in the development community means that if any of the OpenRC or Upstart people will decide to retire, these systems will lose much more development manpower than systemd does. Can you imagine this being an option in Debian Installer just like you can configure your time zone or filesystems? What would you write to the description texts of the different choices? Ubuntu users have a choice of installer: the Debian one and the standard Ubuntu one. I don't use the standard Ubuntu installer, though I have no pb with others using it. That's not what I said. I asked whether it's possible to choose the init system in the installer and it's not possible in either the Ubuntu or Debian installer. It's crazy just to think about it. I don't see any craziness, it's just like all of Debian: volunteer based, and depending on everyone's motivation and involvement. And that's the exact problem with OpenRC and Upstart - besides the technical side - there are just a handful of volunteers in the whole Linux community while systemd has a very large community meaning even if any of their main developers decide to step back at some point,
Re: Bug#737634: dpkg: is_native version checks in dpkg 3.0 Native
Le Wed, Feb 05, 2014 at 09:08:04PM +0100, Guillem Jover a écrit : Sorry, I should have added here my usual note about being open to reconsideration *if* convincing arguments are put forward. But I was pretty much unimpressed with the way this had been brought up. Way more so now with the threats of TC force, but I guess that's the new Debian-way… Hi Guillem, I would like you to consider that, what you would feel if the TC would push a decision on you, we feel it when you push your decision on us. Clearly, when my work was first interrupted by dpkg-dev after upgrading it, and when I realised through the changelog and the bug log that it was an unconcerted top-down decision, my feeling was that the contribution that I was making was not as welcome as I thought, and that I should find a better way to spend my time. For example, what does ikiwiki (a native package with a native version) has to do with anything? The Ikiwiki package, which uses a native version number for a clearly non-native work in the sense of Policy's section 3.2.1 (packages which have been written especially for Debian), shows how inconsistent is the concept of a native package. It shows that there is no problem with the version number indicating one thing and the source format indicating another one. So please revert your change, which solves no practical problems. Cheers, -- Charles Plessy Tsurumi, Kanagawa, Japan -- 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/20140211093947.ga17...@falafel.plessy.net
Re: Bug#727708: Fsck SystemD and its developers and its users. GR to override this please.
On 02/11/2014 09:02 AM, Thomas Goirand wrote: The situation with upstart or systemd, if not chosen as default, will be quite different, since not all packages are supporting them directly right now. One of these 2 will suffer from the choice of default init system. What? That's not true. As people have explained here before - even directly to you - both Upstart and systemd have perfect backwards compatibility with sysvinit scripts. And at least for systemd, you can simply install the package and start using it with init=/bin/systemd from the next reboot on. No further changes are necessary and everything works right out-of-the-box. And if you want to go back to sysvinit, just remove the init line from the kernel command line and uninstall the systemd package. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52f9edf8.5020...@physik.fu-berlin.de
Re: Bug#727708: Fsck SystemD and its developers and its users. GR to override this please.
On 02/11/2014 09:13 AM, Thomas Goirand wrote: It seems that in case of systemd it may end being forced, doesn't Gnome 3 depend on it? We have between 40 and 50 window managers in Debian. Nobody forces you to use Gnome. How about switching to TWM! :) Window managers are leaf packages, at least they should be. If awesome or fvwm are broken, other window managers or desktops won't be affected at all. If you are running into problems with your init system, you are risking to affect hundreds of other packages. Core components like init should be carefully chosen and maintained to be able to guarantee a stable environment. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52f9eee8.4050...@physik.fu-berlin.de
Re: Call to fork
Hi, On Tue, Feb 11, 2014 at 01:29:47AM +, Sam Hartman wrote: In all seriousness. Forking, or creating a Debian downstream because you'd like a different boot approach sounds like exactly the sort of constructive approach that will help you solve your problems and get an operating system you're happy with. For me there is a lot more reason to fork: - Dropping Architectures - Gnome3 Bullshit - systemd Debian is not as useful as it was a couple years back. I started with debian because of m68k and later contributed the first mips and mipsel packages and hosted the first buildds for mips and mipsel. Debian has lost me since - The discussion about dropping and factual dropping of architectures - the Gnome3 stuff which is/was far from production quality (e.g. #698340, #698781), brokeness in debian installer (#712879) and now the systemd stuff. systemd hurts my minimalistic approach and beeing non portable is an absolute show stopper for me. Stuff which used to work gets broken and nobody cares. Probably i am an oldtimer and should switch to Windows or something (Which i never used). For me Debian over the last 5 years diverted far away from what i saw as my Desktop and Server OS. People in my surrounding switch to Mint, Ubuntu and whatever and i have no arguments to get them back because i also fight on a daily basis. So Debian - You lost me Just some feelings about my 15+ Year involvement with Debian. Flo PS: I dont think a fork would really work out but if some people would listen to the noise the systemd issue makes. IMHO its not about systemd per se. The past decisions about architectures and now systemd splits off some parts of our userbase. For me Debian has long lost the Universal in Universal Operating System. -- Florian Lohoff f...@zz.de signature.asc Description: Digital signature
Re: Bug#727708: Fsck SystemD and its developers and its users. GR to override this please.
On Tue, 2014-02-11 at 10:08 +0100, Olav Vitters wrote: On Tue, Feb 11, 2014 at 06:49:56AM +0100, Svante Signell wrote: Additionally a very good proposal for a PID 1 program was in http://ewontfix.com/14/ Broken by design: systemd, copied here for convenience: I like how people copy/paste blog articles. Did you read this article? Of course I've read it. It completely lacks detail and where it does, it is conflicting with itself. E.g. Reboot to Upgrade, while a bit later: systemd's systemctl has a daemon-reexec command to make systemd serialize its state, re-exec itself. Meaning: reboot to upgrade is not needed, answer is given in the same text. The objections to daemon-reexec are vague. I'll do some more reading on daemon-rexec before saying more. But: Don't you se the the current development is heading towards a Windows locked-in situation, and a reboot is necessary for every upgrade? kdbus, udev, gnome, network-manager, pulseaudio, wayland, (add to the list here) -- 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/1392112663.18980.46.ca...@g3620.my.own.domain
Re: Bug#727708: Fsck SystemD and its developers and its users. GR to override this please.
On Tue, 2014-02-11 at 10:27 +0100, John Paul Adrian Glaubitz wrote: See, I am one of the people involved in the m68k port of Debian. Just recently, one of our main contributors decided to jump the ship who cannot be replaced by someone else easily as public interest in the m68k port is simply way too low meaning we have lost lots of development manpower. All people are replaceable, how could companies continue making products when seniors retire and juniors replace them? -- 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/1392112995.18980.50.ca...@g3620.my.own.domain
Re: Bug#727708: Fsck SystemD and its developers and its users. GR to override this please.
On 02/11/2014 11:03 AM, Svante Signell wrote: On Tue, 2014-02-11 at 10:27 +0100, John Paul Adrian Glaubitz wrote: See, I am one of the people involved in the m68k port of Debian. Just recently, one of our main contributors decided to jump the ship who cannot be replaced by someone else easily as public interest in the m68k port is simply way too low meaning we have lost lots of development manpower. All people are replaceable, how could companies continue making products when seniors retire and juniors replace them? Sure, they are replaceable. However, it's sometimes simply not possible to find someone who has both the necessary expertise and is willing to help. And this is why this needs to be factored in the decision making process. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52f9fc3c.9050...@physik.fu-berlin.de
Re: Bug#727708: Fsck SystemD and its developers and its users. GR to override this please.
On 11/02/14 10:57, Svante Signell wrote: kdbus, udev, gnome, network-manager, pulseaudio, wayland, (add to the list here) I fail to see what your point is here. -- 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/52f9ffb7.2040...@debian.org
Re: Bug#727708: Fsck SystemD and its developers and its users. GR to override this please.
- Debian has sent patches upstream - Mageia is *much* smaller distribution, that packager has attended *various* systemd hackfests - Mageia package maintainer sent various patches upstream - Patches are *not* accepted based on how many people you represent or which company you work for (e.g. some Red Hat dude got a no during hackfest before FOSDEM) Glad to hear that! :) QR codes is optional Built-in HTTP server is optional Binary logging - yeah, it logs stuff. Calling logging functionality in a program which is meant to log things is a bit much. It's not just calling logging functionality, it's running an own logging daemon that supports a lot of other things. calling logging functionality is syslog(3) or maybe even printf(3) :))) and it should be enough for software that just logs stuff. :) You cannot separate it, if you look at status output of a service it'll use the journal to give you useful output. Splitting things has sideeffects. If the gain is uncertain of vague (I don't like it / UNIX philosophy), then IMO time to trust the package maintainer. Of course it has side effects! That's why people call it monolithic and that's why it needs some decoupling. Do you agree that a modular program is generally better than a non-modular one? And yes, I can't say how much I don't like Windows-like ideas of binary logs / binary configs / unified registry and etc. Yeah, yeah, I know there are no binary configs in systemd, that's just an example. :) And it seems I'm not the only one who doesn't like it! And I'm sure that at least 50% of swear words addressed to systemd could be stopped at once if the journal was made ALSO optional. So why not just do it?... I'm not familiar with systemd code, but since it seems Debian faces systemd becoming the default, I even want to try to make journal optional by myself... :) the downside is that I don't know if systemd developers will like it 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/7d88a7a010afdbb7ce8132d639bda...@yourcmc.ru
Re: conflict between system user and normal user
Simon McVittie smcv at debian.org writes: If we standardize on _* (or capital letters or whatever) for packaged Users with capital letters sometimes cannot receive eMail correctly. (Using _ in my packages since I think the BSDs’ approach sensible.) accounts, then adduser --system could also start accepting _* without needing --force-badname, if desired. No. “adduser --system” is for the local admin to use, too, and _they_ should have the extra warning. bye, //mirabilos -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/loom.20140211t123222-...@post.gmane.org
Re: Bug#727708: Fsck SystemD and its developers and its users. GR to override this please.
On Tue, 2014-02-11 at 11:47 +0100, Emilio Pozuelo Monfort wrote: On 11/02/14 10:57, Svante Signell wrote: kdbus, udev, gnome, network-manager, pulseaudio, wayland, (add to the list here) I fail to see what your point is here. systemd dependencies of course, the vendor lock-in strategy is successful: (the packages below are all from the source systemd) build-rdeps libsystemd-login-dev colord gnome-packagekit gnome-disk-utility pulseaudio dbus accountsservice weston gvfs packagekit build-rdeps libgudev-1.0-dev umockdev entangle gnomad2 shotwell gst-plugins-good1.0 udisks2 indicator-session update-notifier webkitgtk rhythmbox libgusb gst-plugins-bad1.0 network-manager-applet gimp gnome-settings-daemon thunar gammu upower modemmanager thunar-volman udisks cheese gnome-dvb-daemon handbrake gst-plugins-good0.10 xfburn gst-plugins-base1.0 gnome-boxes buzztard python-gudev gxine network-manager gvfs simple-scan empathy gudev-sharp-1.0 libmbim libwacom colord spice-gtk cinnamon gst-plugins-base0.10 build-rdeps libsystemd-journal-dev == packagekit realmd dbus build-rdeps libudev-dev === libvirt mountall upstart xserver-xorg-input-evdev qwbfsmanager libdrm hplip libsdl2 udisks mesa pulseaudio vlc tcplay cgminer media-ctl libusbx gqrx-sdr multipath-tools xserver-xorg-video-ati bfgminer libsigrok udevil libldm qthid-fcd-controller connman consolekit qtmobility simpleburn spacefm bluez xboxdrv libopenusb ofono qextserialport xserver-xorg-video-nouveau umockdev qtserialport-opensource-src weston urfkill olpc-kbdshim xserver-xorg-video-intel flightgear xorg-server xserver-xorg-video-modesetting gvfs xwiimote xf86-input-wacom libatasmart petitboot xf86-video-omap system-config-printer chromium-browser razorqt libcec higan pcsc-lite pyqt5 enna guvcview kde4libs linphone xbmc kde-workspace lvm2 network-manager qtbase-opensource-src pyudev Do you want more examples? -- 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/1392117503.18980.60.ca...@g3620.my.own.domain
Re: Bug#727708: Fsck SystemD and its developers and its users. GR to override this please.
On Tue, Feb 11, 2014 at 10:27:04AM +0100, John Paul Adrian Glaubitz wrote: And this is very much what I would see in Debian. Use your desktop and applications of choice and you will get support, but if you want to change core components, you are free to do so, but you will lose support. [ Below all not directed to John, just additional comments ] If suddenly OpenRC (or whatever) gets loads and loads of contributors, gets lots of init scripts, solves/provides an logind alternative and does whatever to improve then it should be supported. However, the support should come from the OpenRC team / interested people. You cannot assign :-P IMO (and I'm an interested part / GNOME dude, so no say): blocking progress is bad. So if someone wants to add OpenRC scripts to packages and maintenance is low: as packager you should be allowing that to happen. As long as the time required on packagers part is minimal. Only by not blocking progress things can move to working nicely. But that also means that it really falls under the task of people interested in something different to make such change happen. At the moment there is too much blocking progress going on IMO (but then against anything other than sysvinit). -- Regards, Olav -- 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/2014022358.gd24...@bkor.dhs.org
Re: amd64 arch and optimization flags?
Tollef Fog Heen tfheen at err.no writes:
]] Jaromír Mikeš
Aha ... so these default flags are added by compiler and they are not
controlled by debian tools at all?
Can I see somewhere default flags for different archs?
run gcc -dumpspecs on the different platforms and you can see them.
No, that won’t display them either.
gcc/gcc/config/i386/i386.[ch] and …/linux*.h would have them, for example
(shortened):
if (TARGET_64BIT)
{
/* Enable by default the SSE and MMX builtins. */
target_flags |= (MASK_SSE2 | MASK_SSE | MASK_MMX |
MASK_128BIT_LONG_DOUBLE);
ix86_fpmath = FPMATH_SSE;
}
else
{
ix86_fpmath = FPMATH_387;
}
bye,
//mirabilos
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/loom.20140211t124236-...@post.gmane.org
Re: Bug#727708: Fsck SystemD and its developers and its users. GR to override this please.
On Tue, Feb 11, 2014 at 03:02:13PM +0400, vita...@yourcmc.ru wrote: QR codes is optional Built-in HTTP server is optional Binary logging - yeah, it logs stuff. Calling logging functionality in a program which is meant to log things is a bit much. It's not just calling logging functionality, it's running an own logging daemon that supports a lot of other things. calling logging functionality is syslog(3) or maybe even printf(3) :))) and it should be enough for software that just logs stuff. :) But all those other things are optional. You mention e.g. maybe even printf(3): Loads of desktop software prints error output. Which is then pretty hidden from any user. Unless you know about ~/.xsession-errors and the various other files. The journal allows (with some work) to log this output and identify which application generated those messages and do this quickly. This across desktops, without duplicating code across desktops. So you could have a GUI which shows you the warnings/errors/etc of Firefox / Iceweasel. Without having to know what firefox-bin and so on means. You cannot separate it, if you look at status output of a service it'll use the journal to give you useful output. Splitting things has sideeffects. If the gain is uncertain of vague (I don't like it / UNIX philosophy), then IMO time to trust the package maintainer. Of course it has side effects! That's why people call it monolithic and that's why it needs some decoupling. Do you agree that a modular program is generally better than a non-modular one? That's very vague statement to make. It is never modular is better or worse than non-modular. E.g. Linux kernel is monolithic, micro kernel might be more modular. Practically: Linux has modules. Other example: $ wget http://packages.debian.org/wheezy/amd64/coreutils/filelist -O- | grep bin -c 102 This coreutils package has 102 binaries. Is it modular? According to you, no! Try splitting this up into subpackages. What is the gain? And it seems I'm not the only one who doesn't like it! And I'm sure that at least 50% of swear words addressed to systemd could be stopped at once if the journal was made ALSO optional. So why not just do it?... People will not like and complain no matter. It is better to make informed judgements than to respond purely on emotional responses. Making a journal optional has a tradeoff. It's not free. Try splitting coreutils up into 5 separate subpackages to get an impression of such tradeoffs. -- Regards, Olav -- 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/2014023543.ge24...@bkor.dhs.org
Re: Bug#727708: Fsck SystemD and its developers and its users. GR to override this please.
Hi, Svante Signell: But: Don't you se the the current development is heading towards a Windows locked-in situation, and a reboot is necessary for every upgrade? How so? You can upgrade systemd. (SysVinit doesn't have any features beyond re-reading /etc/inittab you might want to upgrade _for_ …) kdbus, udev, gnome, network-manager, pulseaudio, wayland, (add to the list here) kdbus is a kernel module, you don't upgrade that without upgrading the kernel. I see no good solution to do a non-reboot kernel upgrade any time soon; if you do need that, process migration works these days, so put a second box beside the original one which takes over temporarily. You can restart pulse. No big problem except temporary interrupt of audio, which cannot be avoided. Presumably it'll never be possible to seamlessly re-exec Wayland, but then that was never possible with X11, so what exactly are you complaining about? You can restart udev. No problem. So can network-manager; not quite as seamlessly, but then your network connections should tolerate a few seconds of outage; if they don't don't use NM. So if that's your biggest argument against systemd, I guess you'll have no problem when Debian switches to it. -- -- Matthias Urlichs signature.asc Description: Digital signature
Re: Bug#727708: Fsck SystemD and its developers and its users. GR to override this please.
Hi, Svante Signell: All people are replaceable, how could companies continue making products when seniors retire and juniors replace them? A company can tell its workers now you either do that or we won't pay you and your family won't eat. (And even then, people you can reasonably tell that to might not be available.) Debian cannot. We'd end up with another ConsoleKit situation – unmaintained, needs work, plus there's something better available right now, so why would anybody bother … Any other not-well-thought-out arguments? -- -- Matthias Urlichs signature.asc Description: Digital signature
Re: Bug#727708: Fsck SystemD and its developers and its users. GR to override this please.
On Tue, Feb 11, 2014 at 12:18:23PM +0100, Svante Signell wrote: systemd dependencies of course, the vendor lock-in strategy is successful: (the packages below are all from the source systemd) [..] Do you want more examples? You skipped over the bit explaining: - where the vendor lock in is? See http://en.wikipedia.org/wiki/Vendor_lock-in and e.g. Microsoft software carries a high level of vendor lock-in, based on its extensive set of proprietary APIs and how this relates to your list - how systemd is driving this possibility (aka the forcing) vs developers just making their lives easier -- Regards, Olav -- 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/2014024046.gf24...@bkor.dhs.org
Re: dpkg-dev: please reject native/non-native version when building native/non-native source packages
Wookey wookey at wookware.org writes: Do I understand this correctly - that it prevents a package cross-binutils-0.1 to generate binaries called binutils-arm-linux-gnueabi-2.24-3 binutils-arm-linux-gnueabihf-2.24-3 Actually, these packages will be buggy usually: debhelper uses the source version number to decide whether to install the Debian changelog as native (changelog.gz) or nōn-native (changelog.Debian.gz) file, which makes lintian complain. I’ve got a source package to “build” multiple Firefox® binary packages (which are, really, just the Mozilla™ builds with nssckbi.so symlinked to the system-wide one) locally, on which running lintian points out this problem. I’m not sure whether there are other subtle differences between native and nōn-native packages like this, but they’ll be buggy. (I’ll probably just convert the source package to 3.0 with multiple orig tarballs some day, but that did not exist back when it was initially needed at $workplace.) So, be careful. bye, //mirabilos -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/loom.20140211t130044-...@post.gmane.org
Re: Call to fork
Le mardi, 11 février 2014, 11.12:24 Florian Lohoff a écrit : Debian is not as useful as it was a couple years back. I started with debian because of m68k and later contributed the first mips and mipsel packages and hosted the first buildds for mips and mipsel. Cool, thanks! Debian has lost me since - The discussion about dropping and factual dropping of architectures - the Gnome3 stuff which is/was far from production quality (e.g. #698340, #698781), brokeness in debian installer (#712879) and now the systemd stuff. Stuff which used to work gets broken and nobody cares. I'd rather say that it's because _you_ don't care enough. You know, we don't drop architectures because it's cool or because it makes any of us happy, only because there's globally not enough manpower to make them sustainable on sufficiently long terms, as well as releasable as part of our stable releases. More architectures would certainly be in jessie if there were enough people standing behind each port, making sure that the latest gcc works, that the kernels don't suddenly segfault or panic, etc etc. The same goes for Gnome3: some things could get fixed given enough involvement. Some upstream choices will probably not be reverted, but could otherwise be implemented differently. The MATE Desktop Environment is making its way into Debian, because enough people wanting that to happen, jumped in the boat and made sure it would. Wishing that things should happen doesn't make them become reality; it needs real work from people. You know, we're all volunteers here, why don't you join us and fix (or help fix) the things that are broken for you? Cheers, OdyX signature.asc Description: This is a digitally signed message part.
Re: Bug#727708: Fsck SystemD and its developers and its users. GR to override this please.
On 02/11/2014 12:23 PM, Olav Vitters wrote: On Tue, Feb 11, 2014 at 10:27:04AM +0100, John Paul Adrian Glaubitz wrote: And this is very much what I would see in Debian. Use your desktop and applications of choice and you will get support, but if you want to change core components, you are free to do so, but you will lose support. [ Below all not directed to John, just additional comments ] The name's Adrian :). If suddenly OpenRC (or whatever) gets loads and loads of contributors, gets lots of init scripts, solves/provides an logind alternative and does whatever to improve then it should be supported. However, the support should come from the OpenRC team / interested people. You cannot assign :-P Yes, but we are not talking about hypothetical things. I am also not planning my life for the case that I am winning the lottery tomorrow. The current situation is that OpenRC has little adoption and a very small development team while systemd is quite the opposite on both terms. And this is an important fact you cannot ignore. IMO (and I'm an interested part / GNOME dude, so no say): blocking progress is bad. So if someone wants to add OpenRC scripts to packages and maintenance is low: as packager you should be allowing that to happen. As long as the time required on packagers part is minimal. Only by not blocking progress things can move to working nicely. But that also means that it really falls under the task of people interested in something different to make such change happen. At the moment there is too much blocking progress going on IMO (but then against anything other than sysvinit). I agree. In any case, the OpenRC supporters should understand that their system isn't high priority just as the m68k port isn't high priority meaning I am not going to block you from doing your own thing, but don't expect me to invest lots of time and efforts into it. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52fa13d0.7010...@physik.fu-berlin.de
Re: Bug#727708: Fsck SystemD and its developers and its users. GR to override this please.
You can restart pulse. No big problem except temporary interrupt of audio, You mean a temporary presence of audio that will immediately go away as soon as pulse is running again right? -- Salvo Tomaselli Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di senso, ragione ed intelletto intendesse che noi ne facessimo a meno. -- Galileo Galilei http://ltworf.github.io/ltworf/ -- 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/2529929.PhjoMSv4SL@vulcano
Re: Bug#727708: Fsck SystemD and its developers and its users. GR to override this please.
Hi, vita...@yourcmc.ru: And it seems I'm not the only one who doesn't like it! And I'm sure that at least 50% of swear words addressed to systemd could be stopped at once if the journal was made ALSO optional. So why not just do it?... Because it's work, for no apparent gain. I mean, the systemd people didn't just code up all that journal stuff for no good reason, but because they perceived a need to have it. And let's face it, the ability to just see the stderr output from $FAILED_JOB with systemctl status is a whole damn lot better than to restart the thing in the foreground and hope to be able to reproduce the problem that caused it to die. You can split off systemd-journal and its supporting files into a separate binary package. That'd probably be quite simple. The question is, why would you even want to ..? -- -- Matthias Urlichs signature.asc Description: Digital signature
Re: Bug#727708: Fsck SystemD and its developers and its users. GR to override this please.
Hi, Salvo Tomaselli: You can restart pulse. No big problem except temporary interrupt of audio, You mean a temporary presence of audio that will immediately go away as soon as pulse is running again right? Don't be daft. My audio works perfectly. So does lots of other people's. If yours doesn't, file a bug. -- -- Matthias Urlichs signature.asc Description: Digital signature
Re: Call to fork
Thanks for sharing this. So, you're frustrated and very disappointed because Ddebian, something you cared about deeply has drifted so far away from what you want that you can no longer support it? I hope that if you decide to fork, you succeed in creating something that meets your needs. I hope that where appropriate we (both the Debian community and the broader FLOSS community) can work together where appropriate. Again, thanks for being open and sharing how this is affecting you. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/01442145887a-984e7e4a-29b0-4e71-8a2a-53a8f44c45b9-000...@email.amazonses.com
Re: Bug#727708: Fsck SystemD and its developers and its users. GR to override this please.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 02/11/2014 04:21 AM, Olav Vitters wrote: On Tue, Feb 11, 2014 at 12:51:13PM +0400, Vitaliy Filippov wrote: This can also reduce the risk of vendor-lock, because the speed Lennart adds features to systemd is so fast that I won't be really surprised if he adds HKEY_LOCAL_MACHINE and HKEY_CURRENT_USER next. And everyone will be forced to use that new feature [registry] if Debian project won't have any influence on systemd. That's what I call vendor-lock :) Features are discussed beforehand at loads of conferences. I think resorting to Windows registry to make a point says enough. The project is under active development, that's is a good thing. If you have needs, make them known. Be positive, not distrustful and you'll go a long way. I think this touches on - or possibly misses - a key point. I do not trust the systemd project to not do things I consider bad or even insane, because they've already done such things, and they show no regret or repentance over having done so. I've seen the same thing with the Mozilla project. I've seen the same thing with Microsoft. I believe all of those groups are acting in good faith, working towards what they see as good goals, with good intentions, and I trust them to continue to do that; based on the evidence of history, I no longer trust that the result of that work will be - or, if it once is, will continue to be - something *I* would consider good. As such, advice to not be distrustful seems to me to be lacking an essential foundation. - -- The Wanderer Secrecy is the beginning of tyranny. A government exists to serve its citizens, not to control them. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCgAGBQJS+i48AAoJEASpNY00KDJryhMP/09fQu7JS9tpmGxgI247rBGI xPcgiunZ0tllSe/ltTaQaiZCY6BJP/tWwSUdudjIrFMH+ffdKtiGtuc/ZpCxuqTQ dsqFIoGeEz0dfHAj8Duiaz5S8ouITZofHbpbCuk+8Fu1kxtUWrkyqBEIJvOJE00v b0YkBBYjWpR96P5Gri5LAHSUki4m37osMub/+YCj3uV6dr5U4rDR4Vqo/488ejuM yPfOo4qf4SeVrp0VDl8vt9lGBTmpEOqESmD7XyFO5PSfMWvnWtgUfZuTeCd2Xylj uRIStMqYMH7e+tzn49CXL6r5UJSKYxl00PNDvd2GXSSJsUbN1GRHMilt2L0s85Ka HSHjF3p3+wePXDs0X5rFGIvjNpHdwgVCaQTTe0j48FXypjyXCUSrAUnhMVH69FmA kNu8JMIE9QyISQlL5jjL2yVA3QGw38s/g7+b50M89tALxb3CWp0ZhIihQ+mMJIvt ptq+8uJK8ZpctoqJlamaTyzx6mMKkc687Sem0emL4M7cIiS9HyJhhTv3Q6A8OlRv Oag5ehnHuOvqjNEMdCsKG2Gpctu7fyMDxnq67mkzAGw2vjf+n7TTDWl31JGZeIkg nDC9KTrdaxqG0AcLdpy7y2y2DWNFKQjS2dUNUf76/uocMo9cnW6gG5SVYl/ucIfa u01rGm3PEzF+OujvQrXq =H81w -END PGP SIGNATURE- -- 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/52fa2e3c.2030...@fastmail.fm
Re: Bug#727708: Fsck SystemD and its developers and its users. GR to override this please.
On Tue, Feb 11, 2014 at 10:27:04AM +0100, John Paul Adrian Glaubitz wrote: It's not *my* choice, systemd is the choice of the majority of the Linux community. OpenRC and upstart are used in Gentoo and Ubuntu What? I see many people who don't like systemd and won't use it. I don't see that systemd is the choice of the _majority_. But i see that systemd funs simply shout louder than others. -- 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/20140211140639.GB14055@localhost
Re: Call to fork
On Tue, Feb 11, 2014 at 09:06:46AM -0500, Sam Hartman wrote: Thanks for sharing this. So, you're frustrated and very disappointed because Ddebian, something you cared about deeply has drifted so far away from what you want that you can no longer support it? I hope that if you decide to fork, you succeed in creating something that meets your needs. I hope that where appropriate we (both the Debian community and the broader FLOSS community) can work together where appropriate. Again, thanks for being open and sharing how this is affecting you. I think i made my point that forking will not help the issue. I am telling you that by all the technical discussions which of the systems is superior over the other you forget about your users. My estimation is that 99% of the users dont care - sysvinit is sufficient and works. 0.5% think they need this little tiny bit of feature which only upstart can give them, 0.5% think they need a feature only systemd can give them. By following either of the 0.5% majority you piss off 50% because their beloved sysvinit which has been doing what it should for decades is gone. And i think i made the point that the voice who said fork debian is just telling you in their way that Debian has lost another supporter. Debian - The Universal operating system whose priority are their users? The systemd issue has gone out of proportion by far - Its a technical issue which is getting debated over a lot. But i think the systemd proponents have made a much broader issue from it which is now about trust, choice, and taste. You cant win here. Flo PS: I talking about Debian as you because i dont feel beeing part of Debian anymore. -- Florian Lohoff f...@zz.de signature.asc Description: Digital signature
Re: Bug#727708: Fsck SystemD and its developers and its users. GR to override this please.
Because it's work, for no apparent gain. I mean, the systemd people didn't just code up all that journal stuff for no good reason, but because they perceived a need to have it. And let's face it, the ability to just see the stderr output from $FAILED_JOB with systemctl status is a whole damn lot better than to restart the thing in the foreground and hope to be able to reproduce the problem that caused it to die. You can split off systemd-journal and its supporting files into a separate binary package. That'd probably be quite simple. The question is, why would you even want to ..? Because I want logs to be plaintext in my system, not binary. And I don't see why a binary log format is needed to implement the stderr capture. -- With best regards, Vitaliy Filippov -- 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/e2da4a65eec4579296f20f4cb4037...@yourcmc.ru
Re: Call to fork
On Tue, Feb 11, 2014 at 03:39:49PM +0100, Florian Lohoff wrote: I am telling you that by all the technical discussions which of the systems is superior over the other you forget about your users. Our users shouldn't care what init system we use. It's an implementation -- and purely technical -- detail of the OS. My estimation is that 99% of the users dont care - sysvinit is sufficient and works. You're right they don't care, but I don't think it's sufficient or that it works as a long-term solution. Bringing in a correct / modern init system is vital. Not just for the speedup at startup (which, for the record, matters a lot to users, which sysvinit can't quite manage, also, systemd is only fast because it's correct, not because it was designed to be fast) 0.5% think they need this little tiny bit of feature which only upstart can give them, 0.5% think they need a feature only systemd can give them. By following either of the 0.5% majority you piss off 50% because their beloved sysvinit which has been doing what it should for decades is gone. These numbers seem off to me. Can I see the poll that was conducted? And i think i made the point that the voice who said fork debian is just telling you in their way that Debian has lost another supporter. We've managed when we've lost users over other technical decisions, but they've been worth it in the past, and we net gain users due to the technical win in the core of the OS. Debian - The Universal operating system whose priority are their users? I don't understand the question. The systemd issue has gone out of proportion by far - Its a technical issue which is getting debated over a lot. Technically, it's a no-contest between sysvinit and systemd. As for systemd vs upstart vs openrc, that's open to debate. Each of those init systems outclass sysvinit straight. But i think the systemd proponents have made a much broader issue from it which is now about trust, choice, and taste. You cant win here. If you don't trust Debian, don't use it. If you don't like the choice, change it. If you don't like the taste, add salt. Flo PS: I talking about Debian as you because i dont feel beeing part of Debian anymore. -- Florian Lohoff f...@zz.de Cheers, Paul -- .''`. Paul Tagliamonte paul...@debian.org | Proud Debian Developer : :' : 4096R / 8F04 9AD8 2C92 066C 7352 D28A 7B58 5B30 807C 2A87 `. `'` http://people.debian.org/~paultag `- http://people.debian.org/~paultag/conduct-statement.txt signature.asc Description: Digital signature
Re: Call to fork
Our users shouldn't care what init system we use. It's an implementation -- and purely technical -- detail of the OS. Sorry to interfere with your discussion, but it really sounds like some kind of proprietary software idea :) I'm sure a big percent of GNU/Linux (and especially Debian GNU/Linux) users like to know and understand what's going under the hood. Debian users are certainly not average PC users. :) -- With best regards, Vitaliy Filippov -- 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/14fceb839262a279e8d3b6cfa9d46...@yourcmc.ru
Re: Call to fork
On 11/02/2014 15:39, Florian Lohoff wrote: On Tue, Feb 11, 2014 at 09:06:46AM -0500, Sam Hartman wrote: Thanks for sharing this. So, you're frustrated and very disappointed because Ddebian, something you cared about deeply has drifted so far away from what you want that you can no longer support it? I hope that if you decide to fork, you succeed in creating something that meets your needs. I hope that where appropriate we (both the Debian community and the broader FLOSS community) can work together where appropriate. Again, thanks for being open and sharing how this is affecting you. I think i made my point that forking will not help the issue. I am telling you that by all the technical discussions which of the systems is superior over the other you forget about your users. My estimation is that 99% of the users dont care - sysvinit is ^^ sufficient and works. 0.5% think they need this little tiny bit of feature which only upstart can give them, 0.5% think they need a feature only systemd can give them. By following either of the 0.5% majority you piss off 50% because their beloved sysvinit which has been doing ^^ They don't care but sysvinit is beloved to them? Oximoron alert! federico -- Federico Di Gregorio federico.digrego...@dndg.it Di Nunzio Di Gregorio srl http://dndg.it The reverse side also has a reverse side. -- Japanese proverb signature.asc Description: OpenPGP digital signature
Re: Call to fork
On Tue, Feb 11, 2014 at 07:02:19PM +0400, vita...@yourcmc.ru wrote: Our users shouldn't care what init system we use. It's an implementation -- and purely technical -- detail of the OS. Sorry to interfere with your discussion, but it really sounds like some kind of proprietary software idea :) How so? systemd is free software and it complies with the DFSG. People are *able* to change it, we're only discussing defaults. I'm sure a big percent of GNU/Linux (and especially Debian GNU/Linux) users like to know and understand what's going under the hood. Debian users are certainly not average PC users. :) Yeah, we're only discussing defaults - users can still change things (which I mention at the end of my email) -- With best regards, Vitaliy Filippov Cheers, Paul -- .''`. Paul Tagliamonte paul...@debian.org | Proud Debian Developer : :' : 4096R / 8F04 9AD8 2C92 066C 7352 D28A 7B58 5B30 807C 2A87 `. `'` http://people.debian.org/~paultag `- http://people.debian.org/~paultag/conduct-statement.txt signature.asc Description: Digital signature
Re: Bug#727708: Fsck SystemD and its developers and its users. GR to override this please.
Well if a bug can be solved by killing the buggy process and getting better functionality than when the process is running is certainly a very very bad bug! Don't be daft. My audio works perfectly. So does lots of other people's. If yours doesn't, file a bug. -- Salvo Tomaselli Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di senso, ragione ed intelletto intendesse che noi ne facessimo a meno. -- Galileo Galilei http://ltworf.github.io/ltworf/ -- 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/4286868.atK1gMq04I@vulcano
Re: Bug#727708: Fsck SystemD and its developers and its users. GR to override this please.
On Tue, Feb 11, 2014 at 06:06:39PM +0400, Oleg wrote: On Tue, Feb 11, 2014 at 10:27:04AM +0100, John Paul Adrian Glaubitz wrote: It's not *my* choice, systemd is the choice of the majority of the Linux community. OpenRC and upstart are used in Gentoo and Ubuntu What? I see many people who don't like systemd and won't use it. I don't see that systemd is the choice of the _majority_. But i see that systemd funs simply shout louder than others. There are various technical reasons to choose systemd. Various developers have chosen for this. It is not something you can gloss over like e.g. the colour of a bikeshed. There are technical reasons behind why projects are relying on the additional value it provides. It's quite sad to be summarized as someone who simply shouts louder. :-( Shouting is not how logind (optional) dependency was decided upon! -- Regards, Olav -- 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/20140211145208.gg24...@bkor.dhs.org
Re: Bug#727708: Fsck SystemD and its developers and its users. GR to override this please.
Le mardi 11 février 2014 à 18:30 +0400, vita...@yourcmc.ru a écrit : And I don't see why a binary log format is needed to implement the stderr capture. It is of course well-known that systemd developers like to make their life more complicated and love to implement binary formats instead of writing simple text parsers, just for the sake of having fun programming them, and absolutely not because they need things like indexing. The same goes for relational databases developers, for example. How silly of them all. -- .''`.Josselin Mouette : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1392130843.18551.1446.camel@dsp0698014
Bug#738649: ITP: omnisharp-server -- HTTP server allowing C# editor plugins to be written in any language
Package: wnpp Severity: wishlist Owner: Sebastian Ramacher sramac...@debian.org * Package name: omnisharp-server Version : 0~git20140211 Upstream Author : Jason Imison * URL : https://github.com/nosami/OmniSharpServer * License : Expat Programming Lang: C# Description : HTTP server allowing C# editor plugins to be written in any language OmniSharpServer provides an HTTP wrapper around NRefactory. It acts as server component for the OmniSharp vim plugin [1] which adds (among other features) code completion, rename refactoring, find usage, code formatting for C# projects. A more recent version of YouCompleteMe (packages as vim-youcompleteme) uses OmniSharpServer to provide code completion for C#. (I'll write a better long description once I'm more familiar with OmniSharpServer.) Regards [1] https://github.com/nosami/Omnisharp -- Sebastian Ramacher signature.asc Description: Digital signature
Re: Bug#727708: Fsck SystemD and its developers and its users. GR to override this please.
On Feb 11, 2014, at 3:06 PM, Oleg lego12...@yandex.ru wrote: What? I see many people who don't like systemd and won't use it. I don't see that systemd is the choice of the _majority_. But i see that systemd funs simply shout louder than others. systemd is used as the default init system in: - Fedora - Arch Linux - Mageia - openSUSE - SLES (upcoming) - RHEL7 - Frugalware - (see Wikipedia) Plus companies like Intel and BMW are using it in their embedded platforms. The reason why you perceive the systemd opponents as being the majority than the supporters lies in the fact that the former are more vocal. It's also usually comes from people who are running or affiliated with Gentoo or Ubuntu. The rest of the community already made up their minds. What I don't get is why are those people trying to push Debian's decision when they are primarily using a different platform. But I guess it's pure politics and trying to push their own projects. Adrian -- 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/af16d566-82f2-4f8d-be34-564a6adad...@physik.fu-berlin.de
Re: Call to fork
On Tue, Feb 11, 2014 at 09:18:48AM -0600, Serge Hallyn wrote: FWIW, disagree - I rarely set up a machine (little laptop or server or container) where I don't need to do one thing or another custom at boot. Throttle back cpus to prevent overheating, register dynamic dns, whatever. You're hardly an average user (and I do mean this fondly) :) Cheers, Paul -- :wq signature.asc Description: Digital signature
Re: Bug#727708: Fsck SystemD and its developers and its users. GR to override this please.
On Tue, 2014-02-11 at 15:47 +0100, John Paul Adrian Glaubitz wrote: What I don't get is why are those people trying to push Debian's decision when they are primarily using a different platform. But I guess it's pure politics and trying to push their own projects. I'm pretty sure there are _many_ Debian users and developers among the people not being happy with the way things are heading :-( Make your voices heard! -- 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/1392131591.18980.101.ca...@g3620.my.own.domain
Re: Bug#727708: Fsck SystemD and its developers and its users. GR to override this please.
On Tue, Feb 11, 2014 at 09:05:48AM -0500, The Wanderer wrote: I think this touches on - or possibly misses - a key point. I don't think so. I do not trust the systemd project to not do things I consider bad or even insane, because they've already done such things, and they show no regret or repentance over having done so. You're talking about yourself and none of what you say contains specifics. What bad and insane things have systemd done? It seems to be that you're ignoring that they attend almost every conference out there, discuss everything up front and hold loads and loads of presentations where they specifically ask for feedback. Saying I do not trust: I think you have a level of expectation for systemd that is at a completely different level than any other project. I've seen the same thing with the Mozilla project. I've seen the same thing with Microsoft. I believe all of those groups are acting in good faith, working towards what they see as good goals, with good intentions, and I trust them to continue to do that; based on the evidence of history, I no longer trust that the result of that work will be - or, if it once is, will continue to be - something *I* would consider good. You are not specific. Systemd is GPL. You can fork it, you can change it, there is no CLA. What do you mean?!? There are no specifics at all in most of the objections. Only a bunch of I don't like it, while if you look at it objectively, it seems that the bar is different for systemd than it is for something such as coreutils. As such, advice to not be distrustful seems to me to be lacking an essential foundation. You're turning things around. I'm being specific and giving examples. Your answer is: but I don't trust them. Ok, whatever, I concluded that already. -- Regards, Olav -- 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/20140211151508.gh24...@bkor.dhs.org
Re: Call to fork
Quoting Paul Tagliamonte (paul...@debian.org): On Tue, Feb 11, 2014 at 03:39:49PM +0100, Florian Lohoff wrote: I am telling you that by all the technical discussions which of the systems is superior over the other you forget about your users. Our users shouldn't care what init system we use. It's an implementation -- and purely technical -- detail of the OS. FWIW, disagree - I rarely set up a machine (little laptop or server or container) where I don't need to do one thing or another custom at boot. Throttle back cpus to prevent overheating, register dynamic dns, whatever. -- 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/20140211151848.GB5025@sergelap
Re: Bug#727708: Fsck SystemD and its developers and its users. GR to override this please.
On Tue, Feb 11, 2014 at 03:51:33PM +0100, Salvo Tomaselli wrote: Well if a bug can be solved by killing the buggy process and getting better functionality than when the process is running is certainly a very very bad bug! As mentioned before: File a bug. -- Regards, Olav -- 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/20140211151850.gj24...@bkor.dhs.org
Re: Bug#727708: Fsck SystemD and its developers and its users. GR to override this please.
On Tue, Feb 11, 2014 at 06:30:24PM +0400, vita...@yourcmc.ru wrote: Because I want logs to be plaintext in my system, not binary. Install syslog. Or maybe Debian will use both journal and syslog. And I don't see why a binary log format is needed to implement the stderr capture. Try to find an efficient way to show the output of a particular daemon. Now of a cgroup. Now anything of a user. It's not about capturing, it is about doing something useful with it. You want to capture various properties with each message. -- Regards, Olav -- 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/20140211151801.gi24...@bkor.dhs.org
Re: Bug#727708: Fsck SystemD and its developers and its users. GR to override this please.
On 02/11/2014 04:31 PM, Clint Byrum wrote: One point of moving to a system like upstart or systemd is that the sysvinit scripts do not run as scripts. They are little tiny declarative files that run all or most in C. This speeds up boot, but only makes sense if all of the early stage boot things make use of it. Leaving most things to just use the sysvinit compatibility layer means not realizing one of the more important benefits of the default init system if it should in fact turn out to be systemd. I agree with the above. So at best you're talking about maintaining two for every daemon. That is still roughly twice the maintenance work and twice the testing. Yes, that's my proposal, and as well deprecate sysv-rc in the favor of OpenRC, and allow OpenRC runscript files *only* if there's support for the default init system (because this way the default init system will not use them, so the runscript format is possible). Yes, testing and maintenance will be double the amount of work, which is why I wrote that it will all depend on contributions. I didn't write support for it would be mandatory, but on best effort basis, which I think is fair. Also, that will enable support for our non-linux ports. Not saying I like it, but that is where choice hurts Debian. Perhaps having the choice will also help Debian enough to make it worthwhile. That's what I believe, yes. On 02/11/2014 05:03 PM, Andrei POPESCU wrote: According to Russ Allbery, it's easier to maintain both systemd and upstart declarations than one sysv init script. s/sysv init/sysv-rc/ --- Please don't do this mistake, it's really sysv-rc that uses the init scripts, and OpenRC, which has a declarative format, still uses sysvinit. Anyway, to some degree, I agree with Russ here, which is why I think we should replace sysv-rc by OpenRC completely at some point (which is when we have stabilized support for *all* arch, which isn't the case right now, latest Hurd patches broke support for kFreeBSD). On 02/11/2014 05:31 PM, John Paul Adrian Glaubitz wrote: On 02/11/2014 09:02 AM, Thomas Goirand wrote: The situation with upstart or systemd, if not chosen as default, will be quite different, since not all packages are supporting them directly right now. One of these 2 will suffer from the choice of default init system. What? That's not true. As people have explained here before - even directly to you - both Upstart and systemd have perfect backwards compatibility with sysvinit scripts. You missed one very important word: *directly*. Probably I should have write *natively*. Sorry for this. On 02/11/2014 05:27 PM, John Paul Adrian Glaubitz wrote: No, it's absolutely not. You can have the choice for the interior design, the paint job, the radio, the type of engine and comfort features, but you certainly cannot have the choice on internal parts like the ignition system or starter motor. Furthermore, if you do decide to replace these parts on your own, you will end up losing your car manufacturer's warranty. The car analogy can only go so far... My point was saying that people do customize things, and do it. That's a way more the case with computers than with cars. On 02/11/2014 05:27 PM, John Paul Adrian Glaubitz wrote: And since there are virtually no volunteers for OpenRC besides you and the other two OpenRC maintainers, Roger and Benda, it will be unsupported at some point when you guys step down. That's truth for every bit of Debian, however, package gets orphaned, adopted, etc. Please don't through this type of argument, especially when we have co-maintainers already. On 02/11/2014 05:27 PM, John Paul Adrian Glaubitz wrote: I have seen you asking for help on OpenRC so many times during these discussion, but I am yet to see people raise their hands and say Yes Thomas, I am going to help you! Yet, it happened. Not in this list though... On 02/11/2014 05:27 PM, John Paul Adrian Glaubitz wrote: All I read are statements from you like Yes, it would work in general if we had someone to implement it, I don't have the time right now unfortunately. Please read the debian/changelog of OpenRC in Experimental, and measure the work that has been done so far. I don't think this counts for nothing, and I really see progress. Hurd kFreeBSD support, and lsb2rcconf comes to mind. Plus this doesn't include all what has been done before the package entered Debian. It's not *my* choice, systemd is the choice of the majority of the Linux community. OpenRC and upstart are used in Gentoo and Ubuntu only (ChromeOS doesn't really count in that context, it's a more or less closed system by Google), while virtually every other of the large distributions has adopted systemd. Using something which is not widely adopted and has very few supporters in the development community means that if any of the OpenRC or Upstart people will decide to retire, these systems will lose much more development manpower than systemd does.
Re: Bug#727708: Fsck SystemD and its developers and its users. GR to override this please.
It is of course well-known that systemd developers like to make their life more complicated and love to implement binary formats instead of writing simple text parsers, just for the sake of having fun programming them, and absolutely not because they need things like indexing. The same goes for relational databases developers, for example. How silly of them all. 1) If you really need a binary index, it could be initially put in a separate file. 2) Binary index isn't needed at all if you just want to print output of a service - you can just put output of each unit to its own log file and just tail it. 3) If you don't want to print only last X lines, but want to print full output of a service since last start - you can remember the previous log position in the service state structure. 4) At a first glance I don't see any _real_ index (i.e. btree) implementation in systemd journal, so I assume it still does fullscans to print logs for a service - am I correct? 5) After all, I don't see why writing 1 regexp is a hard task. And it won't be really slower because of (4). DBMS is an incorrect example because DBMS is originally _meant_ to store and query structured data in different formats. -- With best regards, Vitaliy Filippov -- 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/6e0bd604d79e10a06ca5d08631300...@yourcmc.ru
Re: Bug#727708: Fsck SystemD and its developers and its users. GR to override this please.
On 02/11/2014 07:23 PM, Olav Vitters wrote: IMO (and I'm an interested part / GNOME dude, so no say): blocking progress is bad. So if someone wants to add OpenRC scripts to packages and maintenance is low: as packager you should be allowing that to happen. As long as the time required on packagers part is minimal. Only by not blocking progress things can move to working nicely. But that also means that it really falls under the task of people interested in something different to make such change happen. At the moment there is too much blocking progress going on IMO Yes, I agree with what's above. On 02/11/2014 08:13 PM, John Paul Adrian Glaubitz wrote: Yes, but we are not talking about hypothetical things. I am also not planning my life for the case that I am winning the lottery tomorrow. Chances to win the lottery are 1 against 14 000 000 (at least in my country). Claiming this kind of odds for supporting OpenRC is IMO an overstatement, especially considering that we have LSB header scripts for *all* of our packages right now. Cheers, Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52fa49b2.5020...@debian.org
Re: Bug#727708: Fsck SystemD and its developers and its users. GR to override this please.
Because I want logs to be plaintext in my system, not binary. Install syslog. Or maybe Debian will use both journal and syslog. I dislike the idea of binary logs so much that I want to really and totally disable journal. And I don't see why a binary log format is needed to implement the stderr capture. Try to find an efficient way to show the output of a particular daemon. Now of a cgroup. Now anything of a user. It's not about capturing, it is about doing something useful with it. You want to capture various properties with each message. No problem: one regexp, one more regexp, one more regexp. And if I _really_ needed a binary index, I would put it in a separate file. -- 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/e8c169d969d7e2f5b4d52aee88f20...@yourcmc.ru
Re: Bug#727708: Fsck SystemD and its developers and its users. GR to override this please.
Excerpts from Josselin Mouette's message of 2014-02-11 07:00:43 -0800: Le mardi 11 février 2014 à 18:30 +0400, vita...@yourcmc.ru a écrit : And I don't see why a binary log format is needed to implement the stderr capture. It is of course well-known that systemd developers like to make their life more complicated and love to implement binary formats instead of writing simple text parsers, just for the sake of having fun programming them, and absolutely not because they need things like indexing. The same goes for relational databases developers, for example. How silly of them all. And how silly of all other tool makers to create full text binary search indexes from text logs, giving simplicity with efficiency at the same time. The real heroes got rid of that scourge, the text logs. -- 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/1392135574-sup-3...@fewbar.com
Bug#738659: ITP: soundscaperenderer -- tool for real-time spatial audio reproduction
Package: wnpp Severity: wishlist Owner: IOhannes m zmoelnig zmoel...@iem.at * Package name: soundscaperenderer Version : 0.4.1 Upstream Author : Matthias Geier, Jens Ahrens et al. * URL : http://spatialaudio.net/ssr/ * License : GPL Programming Lang: C++ Description : tool for real-time spatial audio reproduction The SoundScape Renderer (SSR) is a tool for real-time spatial audio reproduction providing a variety of rendering algorithms, e.g. Wave Field Synthesis, Higher-Order Ambisonics and binaural techniques. . It is possible to interact with a soundscape (moving sound sources, adjusting levels) either via a graphical user interface or via network commands. this software is targeted at spatial audio research (which happens to be my field of work) and provides a uniform interface to multiple spatialization techniques. it's probably comparable to OpenAL, but differs in the methodology (soundscaperenderer is a (collection of) application(s), OpenAL is a library) and the target audience (SSR can be used for concert reproduction, whereas OpenAL is more game orientend)- I would like to do the packaging under the pkg-multimedia-team umbrella (if somebody there is interested :-)) fgmasdr IOhannes -- 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/20140211163455.19032.85625.reportbug@ferrari.iemnet
Re: Call to fork
Hi, Florian Lohoff: My estimation is that 99% of the users dont care - sysvinit is sufficient and works. 0.5% think they need this little tiny bit of feature which only upstart can give them, 0.5% think they need a feature only systemd can give them. (a) please tell us which feature is only available with upstart. (b) if those 99% don't care, then they'll be equally happy with systemd. (c) I for one don't just think I need a couple of systemd features. For instance, a daemon which fails to start under sysvinit will not even prevent the services which depend on it from starting up. How terminally stupid is that? We've lived with the faults of sysvinit long enough. I can't help but think that some people have grown so accustomed to all these niggly little (or not so little) problems that they feel lost without them... -- -- Matthias Urlichs signature.asc Description: Digital signature
Re: Bug#727708: Fsck SystemD and its developers and its users. GR to override this please.
On Tue, Feb 11, 2014 at 07:57:18PM +0400, vita...@yourcmc.ru wrote: 2) Binary index isn't needed at all if you just want to print output of a service - you can just put output of each unit to its own log file and just tail it. Now show everything of a particular user. Systemd allows you to do this quickly (barring some performance bugs). 3) If you don't want to print only last X lines, but want to print full output of a service since last start - you can remember the previous log position in the service state structure. Then you also need to handle logrotate. 4) At a first glance I don't see any _real_ index (i.e. btree) implementation in systemd journal, so I assume it still does fullscans to print logs for a service - am I correct? You're not. 5) After all, I don't see why writing 1 regexp is a hard task. And it won't be really slower because of (4). A regexp is unreliable and slow. Lots of ssh blocking tools have had various security issues due to this. -- Regards, Olav -- 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/20140211163234.gk24...@bkor.dhs.org
Re: Bug#727708: Fsck SystemD and its developers and its users. GR to override this please.
2014-02-11 17:03 GMT+01:00 vita...@yourcmc.ru: [...] And if I _really_ needed a binary index, I would put it in a separate file. Guess what journald is doing ;-) And if the journal is not running in persistent mode, this extra logfile only exists temporarily and everything is forwarded to rsyslog, so you gat your syslog-textfile (but with much more structured content) First try the software, then complain. Complaining about something you never tried and/or don't know about doesn't make any sense. Cheers, Matthias -- Debian Developer | Freedesktop-Developer I welcome VSRE emails. See http://vsre.info/ -- 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/CAKNHny9mx2ggVMepf0eADjtP=wqdjkmvoo3dcas1j+wjpdg...@mail.gmail.com
Re: Bug#727708: Fsck SystemD and its developers and its users. GR to override this please.
Hi, vita...@yourcmc.ru: Because I want logs to be plaintext in my system, not binary. Why? (Seriously.) -- -- Matthias Urlichs signature.asc Description: Digital signature
Re: Bug#727708: Fsck SystemD and its developers and its users. GR to override this please.
vita...@yourcmc.ru writes: It is of course well-known that systemd developers like to make their life more complicated and love to implement binary formats instead of writing simple text parsers, just for the sake of having fun programming them, and absolutely not because they need things like indexing. The same goes for relational databases developers, for example. How silly of them all. 1) If you really need a binary index, it could be initially put in a separate file. 2) Binary index isn't needed at all if you just want to print output of a service - you can just put output of each unit to its own log file and just tail it. 3) If you don't want to print only last X lines, but want to print full output of a service since last start - you can remember the previous log position in the service state structure. 4) At a first glance I don't see any _real_ index (i.e. btree) implementation in systemd journal, so I assume it still does fullscans to print logs for a service - am I correct? 5) After all, I don't see why writing 1 regexp is a hard task. And it won't be really slower because of (4). Here's a challenge then: Implement everything the journal does, without using a binary format, and show us it's not only doable, but performs similarly. I would first recommend you read up - and try! - what the journal has to offer. It's not as simple as you make it out to be. -- |8] -- 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/87a9dxtxpf.fsf@algernon.balabit
Re: Bug#727708: Fsck SystemD and its developers and its users. GR to override this please.
On 02/11/2014 17:03, vita...@yourcmc.ru wrote: Try to find an efficient way to show the output of a particular daemon. Now of a cgroup. Now anything of a user. It's not about capturing, it is about doing something useful with it. You want to capture various properties with each message. No problem: one regexp, one more regexp, one more regexp. http://xkcd.com/1171/ Ansgar -- 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/52fa5163.8020...@43-1.org
Can we please change the Subject: ?
It's annoying to read and no longer relates to the discussion. I don't think the original poster deserves this publicity. Thanks Andreas -- 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/52fa59cc.3060...@debian.org
Re: Bug#727708: Fsck SystemD and its developers and its users. GR to override this please.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 02/11/2014 11:26 AM, Matthias Urlichs wrote: Hi, vita...@yourcmc.ru: Because I want logs to be plaintext in my system, not binary. Why? (Seriously.) In my case: because I want to be able to read them conveniently at a glance, without requiring the presence of a functioning specialized tool for doing so. As the UNIX Philosophy puts it, text streams ... [are] a universal interface. Also because when writing a parser, it's easier to determine the format (in terms of meaning and start/stop of each field) of a text file than it is of a binary one, when working without known-reliable documentation. (And I'm not willing to assume that I'll always have such documentation.) There's a *reason* the vast majority of kernel userspace-interface files are in plain-text form, after all. - -- The Wanderer Secrecy is the beginning of tyranny. A government exists to serve its citizens, not to control them. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCgAGBQJS+lgYAAoJEASpNY00KDJrKekP/2kuE1RegQe0zhC9qpI3keaa +P1Pghdup+U9BhwQptN046sOCS2Ku8nMf+2vvkO4gNlUprPPuU6szUsj3e9ya+zt t5BnvcAWOx4QDM09AHP4d2Pi42dOf1ZPzKLwIrgIjPaxg1wRZNuOyo3ihMgZLs5Z 6J9JG6bBvfDnED2x1FGB9MTF2rQMLiD0YkcQ6qQzo/iFFuC6UsdjVpc8mXvjhMh5 0vxkp3345ZAi+DRqkRb4kljJIuDcjPZKlpdoSENFC6W2flqt3GRqeKuc5FyGaE4Q l2SmhXoqNIQ285eTie8seHONBjITtXcHphOTS/36zpLrsBjbzOYjBloNrALJoxHC xCjyXwKzRnj19rbECzBRiv65R7OsubqI0int1luN0Y/RgJcwTIWowI57s6eJ+Wlv JkX+57Ex8saUIvf/Z+xr655lupy1blCJgMK04vUbPHrdr+Ds+avsTJWNxofXC7ot Sox1s6iZsAqSfg1BXkSCc1+iSF3QaDuNmawBW6Klua6Wz2W4YdLGVglI+T0202BB jRs6n+wuK6pdsmKi4ZccyBygIuvaBzMj9pXaKkVdftDZ3jz9L/3FrzR0kk8pI+8K INxfh7lykqf0jx9tHXyOHK3yZQ17G9uOzhIk5DJT1h4Rc4dfkoQBAQ+F2M+gtOIk aX6/TvXkH5VFZiuMC4k7 =oxjb -END PGP SIGNATURE- -- 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/52fa5818.6070...@fastmail.fm
Re: Bug#727708: Fsck SystemD and its developers and its users. GR to override this please.
On Tue, Feb 11, 2014 at 10:26 AM, Matthias Urlichs sm...@smurf.noris.de wrote: Hi, vita...@yourcmc.ru: Because I want logs to be plaintext in my system, not binary. Why? (Seriously.) To use standard text based tools, eg. grep. -mz -- 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/CAOLfK3X6Zpz=ysi8-yxypgdohohqfxevt2zhrasd9uaw5tv...@mail.gmail.com
Re: Bug#727708: Fsck SystemD and its developers and its users. GR to override this please.
On Feb 11, 2014, at 5:02 PM, Thomas Goirand z...@debian.org wrote: On 02/11/2014 08:13 PM, John Paul Adrian Glaubitz wrote: Yes, but we are not talking about hypothetical things. I am also not planning my life for the case that I am winning the lottery tomorrow. Chances to win the lottery are 1 against 14 000 000 (at least in my country). Claiming this kind of odds for supporting OpenRC is IMO an overstatement, especially considering that we have LSB header scripts for *all* of our packages right now. That was not my point. I was not talking about the functionality. I don't have any doubts that OpenRC is doing what it was designed for already. However, I do not think that the current feature set of OpenRC is enough to justify preferring it over systemd and, now coming back to my lottery metapher, I do not think that it is very likely that OpenRC is going to be able to catch up any time soon. Don't get me wrong, I really appreciate what you and the other maintainers are working on. But I think that it's not leading anywhere. The only advantage I have with OpenRC is its portability but that doesn't justify to waive for important systemd features that users need in a productive environment. People need resource management and process isolation, process tracking, CPU affinity settings, consistent and easily searchable logs, reliable daemon startup and dependencies without having to resort to sleep. systemd actually solves lots of real world problems that everyone who gets a salary for administrating a large Linux server setup has heard of before. Arguing that portability to Hurd or BSD is more important than reliability and robustness in a productive environment is just crazy, sorry! Adrian -- 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/3c4da05d-b04b-49c5-bbb2-9f9ecbf8a...@physik.fu-berlin.de
Re: Bug#727708: Fsck SystemD and its developers and its users. GR to override this please.
Here's a challenge then: Implement everything the journal does, without using a binary format, and show us it's not only doable, but performs similarly. I would first recommend you read up - and try! - what the journal has to offer. It's not as simple as you make it out to be. Given that Debian transitions to systemd - it seems an option to me. ) But first I'll try to disable it completely, of course. IMHO it's also a suitable solution. I understand there's more functionality than you can build up only using regexes. The point is - I don't understand why an INIT SYSTEM (!) should depend on these, generally non-trivial, features. -- With best regards, Vitaliy Filippov -- 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/op.xa4n8hx70ncgu9@vitalif.vhome
Re: Bug#727708: Fsck SystemD and its developers and its users. GR to override this please.
Guess what journald is doing ;-) And if the journal is not running in persistent mode, this extra logfile only exists temporarily and everything is forwarded to rsyslog, so you gat your syslog-textfile (but with much more structured content) What it's doing? Isn't it storing the log files themselves in a binary format? -- With best regards, Vitaliy Filippov -- 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/op.xa4ocxpc0ncgu9@vitalif.vhome
Re: Bug#727708: Fsck SystemD and its developers and its users. GR to override this please.
The Wanderer wande...@fastmail.fm writes: In my case: because I want to be able to read them conveniently at a glance, without requiring the presence of a functioning specialized tool for doing so. As the UNIX Philosophy puts it, text streams ... [are] a universal interface. All the folks who are upset about the journal are aware, I hope, that, as configured in the current systemd packages in Debian at least (I haven't tried a generic upstream install), all journal messages are forwarded directly to syslog, right? All the text files that you are looking for still exist in the same form they always have. The journal serves as a mechanism for routing some things into syslog that wouldn't otherwise go there (such as stderr output from daemons) and as a data store for some nice but entirely optional systemd debugging features, such as show me all the output logged from this particular daemon but not any of the others. It doesn't replace syslog. I am in wholehearted agreement with the people who want all their log messages to go into syslog so that they can be processed, routed, and so forth just as they are today. I, and I suspect many others who like systemd, would be quite unhappy if that didn't happen. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87y51hr1lf@windlord.stanford.edu
Re: Bug#727708: Fsck SystemD and its developers and its users. GR to override this please.
5) After all, I don't see why writing 1 regexp is a hard task. And it won't be really slower because of (4). A regexp is unreliable and slow. Lots of ssh blocking tools have had various security issues due to this. That only depends on whether you know the format of that what you parse. Binary log with an unknown/unstable format may also be unreliable. -- With best regards, Vitaliy Filippov -- 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/op.xa4ol2h50ncgu9@vitalif.vhome
Re: Bug#727708: Fsck SystemD and its developers and its users. GR to override this please.
Vitaliy Filippov vita...@yourcmc.ru writes: Here's a challenge then: Implement everything the journal does, without using a binary format, and show us it's not only doable, but performs similarly. I would first recommend you read up - and try! - what the journal has to offer. It's not as simple as you make it out to be. Given that Debian transitions to systemd - it seems an option to me. ) But first I'll try to disable it completely, of course. IMHO it's also a suitable solution. I understand there's more functionality than you can build up only using regexes. The point is - I don't understand why an INIT SYSTEM (!) should depend on these, generally non-trivial, features. I suggest you read the rationale behind the Journal, in particular the design docs: https://docs.google.com/document/pub?id=1IC9yOXj7j6cdLLxWEBAGRL6wl97tFxgjLUEHIX3MSTs (But, if you have comments about it, please take it upstream or keep it to yourself, in all honesty. We've been over this and other aspects of systemd many times.) -- |8] -- 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/871tz9tuod.fsf@algernon.balabit
Re: Bug#727708: Fsck SystemD and its developers and its users. GR to override this please.
Because I want logs to be plaintext in my system, not binary. Why? (Seriously.) Because I count the wide use of transparent plaintext formats everywhere - in logs, configs and shell commands is one of the biggest advantages of Linux/Unix systems. And to use standard text processing tools, parsers and have a simple way of archiving logs, yeah. -- With best regards, Vitaliy Filippov -- 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/op.xa4o1pqa0ncgu9@vitalif.vhome
Re: Bug#727708: Fsck SystemD and its developers and its users. GR to override this please.
The Wanderer wande...@fastmail.fm writes: Also because when writing a parser, it's easier to determine the format (in terms of meaning and start/stop of each field) of a text file than it is of a binary one, when working without known-reliable documentation. (And I'm not willing to assume that I'll always have such documentation.) Stop right there. You're so very wrong there, you cannot even imagine. Without documentation, you cannot assume *anything* about neither text nor binary. If you think you do, think again, you will be wrong. There's a *reason* the vast majority of kernel userspace-interface files are in plain-text form, after all. Interface? Yes. You give textual commands to journalctl, and it gives you text output back. Same way you echo something into files under /sys, or cat them, and something behind it *translates* that. The only difference is that journalctl is a user-space program, while the files under /sys are translated by the kernel. -- |8] -- 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/87wqh1sfqs.fsf@algernon.balabit
Bug#738665: ITP: python-pysam -- interface for the SAM/BAM sequence alignment and mapping format
Package: wnpp Severity: wishlist Owner: Andreas Tille ti...@debian.org * Package name: python-pysam Version : 0.7.5 Upstream Author : Heng Li l...@sanger.ac.uk * URL : http://code.google.com/p/pysam/ * License : MIT Programming Lang: C, Python Description : interface for the SAM/BAM sequence alignment and mapping format Pysam is a Python module for reading and manipulating Samfiles. It's a lightweight wrapper of the samtools C-API. This package is maintained by the Debian Med team at git://anonscm.debian.org/debian-med/python-pysam.git -- 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/20140211180401.24615.29219.report...@mail.an3as.eu
Re: Bug#727708: Fsck SystemD and its developers and its users. GR to override this please.
On 02/11/2014 06:30 PM, Vitaliy Filippov wrote: I understand there's more functionality than you can build up only using regexes. The point is - I don't understand why an INIT SYSTEM (!) should depend on these, generally non-trivial, features. Because the tasks of init and syslog are very closely tied together. Init is responsible for starting all processes and managing them while syslog is responsible for logging all process activity. And since the init daemon is the parent of every other process running on your system, it can - with the help of cgroups - track every single activity of every process and thus has lots of information that syslog has never any access to on its own. systemd knows which process has which PID and when it was started and with the help of the journal, it's very easy to find this information. systemd virtually sets itself in front of all standard communication channels of a process and tracks what's going on. systemd knows exactly which log messages belong to which process and can pass all this information to the journal. It is able to prioritize log messages and have this information accessible through the journal. With syslog, you just have all processes using the log randomly write into a large log file in a non-standardized format where as systemd enforces a format and therefore allows you to easily find what you are looking for. If you want to know, what Apache errors occurred during the last week, you issue one specific journalctl command and get the information you need within the blink of an eye. With syslog, you have to open your syslog file and start grepping around hoping you remember the correct error strings you have to be looking for to find any errors within the past week. So, while the journal introduces a binary format and makes logging part of PID1, it actually gives you a very powerful tool at hand which allows you to get any information about the state about any services and processes on your machine at a glance. And this is what matters to most users, not the fact whether it's part of PID1 or not. And, as it has been reiterated several times, if you still want a classic syslog, you can simply install and use it. There is nothing in systemd that will keep you from doing so. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52fa69e3.6000...@physik.fu-berlin.de
Re: Bug#727708: Fsck SystemD and its developers and its users. GR to override this please.
On 02/11/2014 06:47 PM, Vitaliy Filippov wrote: And to use standard text processing tools, parsers and have a simple way of archiving logs, yeah. It's not simple if you have to write a script for every single service whose log messages you want to parse. The journal already gives you an out-of-the-box working solution. There is no need to use any external tools. And, again, if you want to continue to use syslog, you still can. http://i3.kym-cdn.com/entries/icons/original/000/006/759/both.png :) Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52fa6a95.9070...@physik.fu-berlin.de
Re: Bug#727708: Fsck SystemD and its developers and its users. GR to override this please.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/11/2014 06:04 PM, The Wanderer wrote: Also because when writing a parser, it's easier to determine the format (in terms of meaning and start/stop of each field) of a text file than it is of a binary one, when working without known-reliable documentation. (And I'm not willing to assume that I'll always have such documentation.) The point is, with the journal and it's binary format, you do not need to write a parser anymore for any daemon. All the information is logged in a common and standardized format. The very same code parses all your Apache log messages and all your Exim log messages. And you can just go ahead and query the journal about error messages conveniently like a database. Not having to write a parser is without doubt easier than having to write one at all. Adrian - -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBCAAGBQJS+mtSAAoJEHQmOzf1tfkT4AYP/175DbFf6hjj/fbMBJABuNoB SWxsuf09texJmf5u2MGMcLliQ+qe7H2daISEwelGV9Eea6rUr16rTkYIV7tYU4Bk kQUzZMp2olvBeuZUgu3bQDxRMZLV6bvaf3aiCkq2dnGsx2czAP92LSOQCr90DRVQ PRo73kMHFfSdo0BcruzJ2qj8gyCd3C1Ems6W2+Z5z6YBTMX9AUskY2o3SDFBJvYj Ikbsfljvf8I3Sph91bpuLkU195NsyaqW2/2naT32aWgc1DWXfbcil8I+aSmcZOph XUSk4FNG0KNo2yF0+CNqvJZX5uAVx9Ks54YMZd6NaMpJ//7YWFF/Q1n+ejOMbIxj Ac7jc9+AmMBubN9z+xd6LdxDIH0GGXSKQ2FihQH9lrwjRnBIQfG0cTMu1+MJ6v6U xJyBlOo72NVJA5h27XByAVs68pA9xMkHNt6ysPEx1+Y7rn15KK1SJ6ni+jKEgXxG eaqAtPnDsPTzBHtb6e9ZTY22hRQ+JeFJTSdyiyONR0Dsywd03y/Sns8VH+gucwDP piPrjMs4ulVBXETr7dzoKLH5z/1g5B1ZzgnuA89wg2kVBnRSasJ8Do39kJKW2sfP NzcuDpg5iB5AP/6u78vxyEMVIqe4Qqf6GnRQwh5d9BE6eZ3QYfQfustzDAAKLKLF scSAs2o3xWPV42GCd5IS =7j1w -END PGP SIGNATURE- -- 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/52fa6b53.60...@physik.fu-berlin.de
Re: Can we please change the Subject: ?
Hi, Andreas Beckmann: It's annoying to read and no longer relates to the discussion. I don't think the original poster deserves this publicity. Your email has no old Subject:, no References: and no In-Reply-To: headers. So … whatever or whoever you're talking about … -- -- Matthias Urlichs signature.asc Description: Digital signature
Re: Bug#727708: Fsck SystemD and its developers and its users. GR to override this please.
Hi, Vitaliy Filippov: Guess what journald is doing ;-) And if the journal is not running in persistent mode, this extra logfile only exists temporarily and everything is forwarded to rsyslog, so you gat your syslog-textfile (but with much more structured content) What it's doing? Isn't it storing the log files themselves in a binary format? You can tell it to do that, yes. You can also set it to forward them to rsyslog without storing anything. Or both. Read http://man7.org/linux/man-pages/man5/journald.conf.5.html and be enlightened. ;-) -- -- Matthias Urlichs signature.asc Description: Digital signature
Re: Call to fork
previously on this list Matthias Urlichs contributed: For instance, a daemon which fails to start under sysvinit will not even prevent the services which depend on it from starting up. How terminally stupid is that? Perhaps you should rethink that whilst considering the complexities. I disagree and could easily argue doing so is stupid. I have also done just that for services not designed to work together within rc.local. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or 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/345050.99715...@smtp150.mail.ir2.yahoo.com
Re: Call to fork
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/11/2014 04:21 PM, Paul Tagliamonte wrote: You're hardly an average user (and I do mean this fondly) :) Reminds me of this, bro: http://www.youtube.com/watch?v=CmPKDeo9Oow#t=3251 Do you see how many people are using alternative window managers here? Adrian - -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBCAAGBQJS+nYtAAoJEHQmOzf1tfkT/d4QALLn5vSTncP/L3D8ShuCLNty VH7AGhNlL6wlGPWLZnA+4xu7w4lLm7HaCt91WkBsV31T0jwiGT4cinQExPFv85xa 7Y31XlCw1Bdjjt/I5Qjvk+V8ZbCaKOPvuA6Qlf4mPkmcocVAoO68DQt+UHaYnaF4 9k3fQ4AK7eKbjYGS/uGeHrVJ2bN8qlswWxZq1lcU+40B3xAAI8mwUz5iBek/+Riw v65Pwi1YtGNfXCvruRY/V1FLM6rBXrhlf2QxUBNpVZ82IOXXA6iLw9TaSAhu17Zn qk3ha51GWKYhc+kGY7pFd1IoceIqZlo/Cf4coVAH4Ps6hiVCQYeTW6gxOKv2HfAR s7JpLOJ/qlKctKCnuZPvNwpskZNnxiUWPHKJzw+wdbahc6iOCu/wMKyBi2T5BppL PBKB4Qi+OxiEO5jOeI2ax7kBn5CAMSCOy58tH0wRx53bv9RbVNbQ900qzr71NcIw g59IdwHne/Cj7s5XhUxUjPeyl+pHKPkTzQoMt/NJHfYLefs2dciIJ7POH6k3KIo2 eF1OqEnVm0N7vO96a706OVkJYCATE2P/yKbGCYEWy94ArSik1z4AOxEkQ9s0gD4F aIu02B9AIW1NMJIAT6hFZsmbvKH0g8TeozPJyqOVKfI+s7Krme53jkJvyJnBxq16 vLS/ZD7xbwkMeLbSG1c6 =aTpc -END PGP SIGNATURE- -- 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/52fa762d.4080...@physik.fu-berlin.de
Re: Call to fork
On 02/11/2014 04:18 PM, Serge Hallyn wrote: FWIW, disagree - I rarely set up a machine (little laptop or server or container) where I don't need to do one thing or another custom at boot. Throttle back cpus to prevent overheating, register dynamic dns, whatever. All of that is possible or even easier with systemd. I don't see your point. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52fa76bd.2070...@physik.fu-berlin.de
Re: Can we please change the Subject: ?
On Tue, Feb 11, 2014 at 07:50:32PM +0100, Matthias Urlichs wrote: Hi, Andreas Beckmann: It's annoying to read and no longer relates to the discussion. I don't think the original poster deserves this publicity. Your email has no old Subject:, no References: and no In-Reply-To: headers. So … whatever or whoever you're talking about … About The Thread. -- WBR, wRAR signature.asc Description: Digital signature
Re: Bug#727708: Fsck SystemD and its developers and its users. GR to override this please.
On 02/11/2014 04:19 PM, Thomas Goirand wrote: On 02/11/2014 05:27 PM, John Paul Adrian Glaubitz wrote: No, it's absolutely not. You can have the choice for the interior design, the paint job, the radio, the type of engine and comfort features, but you certainly cannot have the choice on internal parts like the ignition system or starter motor. Furthermore, if you do decide to replace these parts on your own, you will end up losing your car manufacturer's warranty. The car analogy can only go so far... My point was saying that people do customize things, and do it. That's a way more the case with computers than with cars. Again, you have to differentiate. People customize their cars, correct. What they don't usually do is replacing core components like the starter motor, engine control circuitry, carburetor (ok, some do) and other parts usually opaque to the driver. And, when they do - because some people are crazy enough to - you will lose the warranty. On the other side, to be able to get back to the analogy to our discussion, when you buy your car, you get a limited set of choices which usually don't allow to choose for core components to be from a specific manufacturer. However, the things that you can choose from are always covered by the warranty and usually do not affect the overall generic functionality of a car. Like choosing your favorite editor does. On 02/11/2014 05:27 PM, John Paul Adrian Glaubitz wrote: And since there are virtually no volunteers for OpenRC besides you and the other two OpenRC maintainers, Roger and Benda, it will be unsupported at some point when you guys step down. That's truth for every bit of Debian, however, package gets orphaned, adopted, etc. Please don't through this type of argument, especially when we have co-maintainers already. Correct. However, there is a huge difference whether it affects an essential package like your init daemon or your favorite editor. If the latter is affected by an RC bug, Britney can kick the package out of testing without any consequences for the rest of the system and users. When you have an RC bug in your init daemon and no maintainer and no one knowledgeable enough to fix the problem you really have a problem. Thus, this risk should be kept at a minimum which is only guaranteed when you use a software which is widely adopted in the community and has a large group of developers behind and not just 6. On 02/11/2014 05:27 PM, John Paul Adrian Glaubitz wrote: I have seen you asking for help on OpenRC so many times during these discussion, but I am yet to see people raise their hands and say Yes Thomas, I am going to help you! Yet, it happened. Not in this list though... How many people where there to actually start contributing now? On 02/11/2014 05:27 PM, John Paul Adrian Glaubitz wrote: All I read are statements from you like Yes, it would work in general if we had someone to implement it, I don't have the time right now unfortunately. Please read the debian/changelog of OpenRC in Experimental, and measure the work that has been done so far. I don't think this counts for nothing, and I really see progress. Hurd kFreeBSD support, and lsb2rcconf comes to mind. Plus this doesn't include all what has been done before the package entered Debian. This progress is still not enough - by far - to catch up with systemd. It's not *my* choice, systemd is the choice of the majority of the Linux community. OpenRC and upstart are used in Gentoo and Ubuntu only (ChromeOS doesn't really count in that context, it's a more or less closed system by Google), while virtually every other of the large distributions has adopted systemd. Using something which is not widely adopted and has very few supporters in the development community means that if any of the OpenRC or Upstart people will decide to retire, these systems will lose much more development manpower than systemd does. Please stop spreading useless FUD. I could do that saying: what happens if both Keith and Lennart stop developing systemd, but you would rightly find it very silly, no? It's not FUD, it's the truth when you compare the bare numbers: http://www.ohloh.net/p/openrc Current Contributors: 17 http://www.ohloh.net/p/systemd Current Contributors: 164 I hope you agree that 164 is a larger number than 17 and that a larger community makes it much more unlikely for a project to be abandoned than a small number of contributors. Furthermore, which was initiated by Lennart as well was mostly left behind by him, yet the project is still very much active: http://www.ohloh.net/p/pulseaudio Btw, the other guy you are talking about is called Kay Sievers, not Keith Sievers :). Plus I'm replaceable, if others see enough interest in the package (which seems to be the case). Define enough? When an init system is adopted mainly by one distribution and has only a handful of developers I don't consider the interest to be enough,
Re: Bug#727708: Fsck SystemD and its developers and its users. GR to override this please.
previously on this list Svante Signell contributed: What I don't get is why are those people trying to push Debian's decision when they are primarily using a different platform. But I guess it's pure politics and trying to push their own projects. I'm pretty sure there are _many_ Debian users and developers among the people not being happy with the way things are heading :-( Make your voices heard! heading? I have faith and if not I shall just switch distro with a little more work or less convenience for offline machines but miss the guarantee of stability and have some worries and dashed hopes for the future of debian embedded. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or 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/357212.23464...@smtp119.mail.ir2.yahoo.com
Re: Bug#727708: Fsck SystemD and its developers and its users. GR to override this please.
previously on this list John Paul Adrian Glaubitz contributed: On 02/11/2014 05:20 AM, Thomas Goirand wrote: It's like being able to customize internal parts of your cars engine when ordering one from your dealer. Customers don't care who the manufacturer of your ignition system is as long it's the best possible one. (Yes, I know comparisons with cars are bad ;)). That's partly not truth. Some customers care, and do customization of their car. No, it's absolutely not. You can have the choice for the interior design, the paint job, the radio, the type of engine and comfort features, but you certainly cannot have the choice on internal parts like the ignition system or starter motor. I'm under the impression Americans customise almost routinely. I know one of my Dad's favourite features of the original mini (mini's may be simple but they won many rallies and are still going) was that almost anyone could take it apart completely in his garage and put it all back together optionally replacing parts. Only the interfaces have to match. That was until he rolled it into a ditch and is still unable to work out how he physically managed to scramble out of the tiny triangular window. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or 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/619879.21733...@smtp145.mail.ir2.yahoo.com
Re: Bug#727708: Fsck SystemD and its developers and its users. GR to override this please.
previously on this list John Paul Adrian Glaubitz contributed: systemd is used as the default init system in: - Fedora - Arch Linux - Mageia - openSUSE - SLES (upcoming) - RHEL7 - Frugalware - (see Wikipedia) Plus companies like Intel and BMW are using it in their embedded platforms. So some distros with relatively few users out of the huge number that exist. and two companies shipping products that actually are embedded in a dash and I'm guessing not actually embedded devices or at the very highest end. You don't call a high powered quad arm seven server embedded, do you? Which is a bit like an SME having a minimum of 200 employees when 85% of companies have four. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or 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/876122.10768...@smtp101.mail.ir2.yahoo.com
Re: Bug#727708: Fsck SystemD and its developers and its users. GR to override this please.
You can tell it to do that, yes. You can also set it to forward them to rsyslog without storing anything. Or both. Read http://man7.org/linux/man-pages/man5/journald.conf.5.html and be enlightened. ;-) OK, it's good they've added none option at least... It wasn't there in the initial journal design document. So, if the storage is disabled, journalctl, systemctl status and other systemd parts that query journal just see an empty result? I.e. everything looks like you just run syslog, only messages sent from systemd get to it through journal, not directly? Do some messages get lost in that case, for examples the ones logged before rsyslog is started? Or are they forwarded to kernel log buffer? -- With best regards, Vitaliy Filippov -- 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/op.xa4tlxrp0ncgu9@vitalif.vhome
Bug#738674: ITP: nancy - lightweight framework for building HTTP based services in C#
Package: wnpp Severity: wishlist Owner: Sebastian Ramacher sramac...@debian.org Control: block 738649 by -1 * Package name: nancy Version : 0.22.0 Upstream Author : Andreas Håkansson, Steven Robbins and contributors * URL : http://nancyfx.org/ * License : Expat Programming Lang: C# Description : lightweight framework for building HTTP based services in C# Nancy is lightweight framework for building HTTP based services in C#. It is designed to handle DELETE, GET, HEAD, OPTIONS, POST, PUT and PATCH requests and provides a domain specific language for returning a response with just a couple of lines of code. Regards -- Sebastian Ramacher signature.asc Description: Digital signature
Re: Bug#727708: Fsck SystemD and its developers and its users. GR to override this please.
On 02/11/2014 08:11 PM, Kevin Chadwick wrote: So some distros with relatively few users out of the huge number that exist. These distros which you attest of having a few users are the major distributions out there. Novell's SLES runs on most of the top500 super computers while RHEL is largely used by many enterprises. Arch, openSUSE and Fedora are among the most popular and widely used Linux distributions where most of the upstream development happens. and two companies shipping products that actually are embedded in a dash Those two are multi-billion dollar companies. On the other hand, what companies and distributions and companies actively support Upstart and OpenRC. Don't diminish the achievements by the systemd developers when the competition isn't even remotely on par when it comes to momentum and community and company support. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52fa7c17.5030...@physik.fu-berlin.de
Re: Bug#727708: Fsck SystemD and its developers and its users. GR to override this please.
On 02/11/2014 08:11 PM, Kevin Chadwick wrote: I'm under the impression Americans customise almost routinely. While they loose the warranty which is my main point. Yes, you can replace your init system with anything you like, but don't expect everyone else in Debian to actively support you. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52fa7c5e.2020...@physik.fu-berlin.de
Bug#738676: ITP: ruby-albacore -- suite or Rake tasks for building C# projects
Package: wnpp Severity: wishlist Owner: Sebastian Ramacher sramac...@debian.org Control: block 738674 by -1 * Package name: ruby-albacore Version : 0.3.5 Upstream Author : Derick Bailey * URL : http://albacorebuild.net/ * License : Expat Programming Lang: Ruby Description : suite of Rake tasks for building C# projects Albacore provides a suite of Rake tasks intended to make building C# projects easier. It includes tasks to generate assembly info, build assemblies, run test suites and generate test coverage reports. Regards -- Sebastian Ramacher signature.asc Description: Digital signature
Proposal: SystemD.pushers/forcers be physically beaten as revenge.
Proposal: SystemD pushers/forcers be physically beaten as revenge. The people, such as Adrian, who are pushing systemd as the one and only init system for debian should be physically harmed. They are wresting from all of us a nice unix like OS, they argue against choice and if they have their way the systemv scripts will be removed, and other non-systemd inits will not be allowed. . This is top-down dictatorship. This is how the systemd people operate. Go to any of their discussions. They say they are trying to help debian. This is similar to how the church in the middle ages helped men's souls, by burning them alive or torturing them. Debian exists for people, it is not a religion. It is not a sculpture. The systemd pushers/forcers say they are trying to improve debian by forcing one choice of init on all of us (especially Adrian). Debian exists not for itself, but for all of us. Adrian and the other systemd pushers are trying to take debian away from us and make it suitable only for them and their users (ie their citizens subjects people they rule over). Those of us who do not want systemd, but instead want to keep an low profile, low attack surface, proven, reliable, resolute, simple init need to do something if we wish to keep a unix like option for debian linux. Since the systemders are using the debian process to overrule choice and freedom, some other method will be needed to keep them from implementing their goal of having systemd as the only init system for debian. I think we will have to physically attack the exclusive systemd people. Words do not phase them. Arguments are useless. They dismiss everything and declare themselves victorious. They corrupt the process and always seek to remove choice and freedom and use every kind of metaphore to accomplish that. I simply want to beable to continue to use what I have used thus-far. I am sure many system admins would like the same. . Adrian and other systemd pushers are not apt to allow that. They need to be physically restrained or beaten untill they come to a different conclusion or enter a state where they are no longer capable of coming to any conclusions. We owe them nothing, but they seek to own us or remove us from debian, and linux in general. We should fight back. In any way that is expedient.
Re: Can we please change the Subject: ?
Andrey Rahmatullin w...@wrar.name writes: About The Thread. The Thread That Shall Not Be Named. (to be more precise :) -- Stig Sandbeck Mathisen signature.asc Description: PGP signature
