[gentoo-user] Re: Debian just voted in systemd for default init system in jessie
The 17/02/14, Canek Peláez Valdés wrote: It depends; right now you can't switch back and forth between OpenRC and systemd without reemerging some stuff. Interesting. Didn't know that. What packages need to be recompiled? BTW, respect for your patience in this thread! -- Nicolas Sebrecht
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On 18/02/2014 05:46, Mark David Dumlao wrote: On Tue, Feb 18, 2014 at 3:53 AM, Alan McKinnon alan.mckin...@gmail.com wrote: On 17/02/2014 17:29, Stroller wrote: On Sun, 16 February 2014, at 4:41 pm, Alan McKinnon alan.mckin...@gmail.com wrote: ... Whatever problems Red Hat are trying to solve in the Red Hat space are problems that do not affect me, so I do not need Red Hat's solution. As for Gnome, I have yet to see a valid reason why Gnome *must* use systemd; that is simply not true at all. I thought this all boiled down to trying to login to GDM using accessibility functions and a bluetooth hearing aid (or bluetooth keyboard, for that matter). That was the classic rationale for no separate /usr without an initrd in udev - the claimed need to have any arbitrary runnable code available to be run before the entire system is up and running. Red Hat's reasons for pushing systemd are more fuzzy and nothing I've read so far tells me we have the full picture. Two things seem highly plausible: 1. An init system that can use modern features of the Linux kernel (most often Linux-only at this point) like cgroups 2. Extremely fast boot times to spin up virtual machines in a fraction of the time it currently takes. #1 may or may not be desirable, I honestly don't know. What I have seen is a lot of theory and not much reproducable fact. init scripts, in general, are ad-hoc, quirky, and incomplete implementations of service supervision in bash. They're reliable so long as the daemon can be relied on to advertise one or all of its processes in a pid file. Thing is, there are way too many different possible setups for services for that to be the case. In the average case watching a PID file works. And since most people use average software, most people don't care. That's ok. Thing is an init isn't just for most people. It's for all people. It should be reliable for all services. I used to use cherokee. Fast, light, awesome, and with a web admin. The init script always failed me. /etc/init.d/cherokee stop was not a guaranteed stop to all forked cherokee processes - the parent pid dies, but some forked process or something, usually related to rrdtool, doesn't. Or the parent does exit and erases the pid file but it returns control immediately and its not yet done exiting. Something like that or other. Point is, I've several times had to ps aux|grep ... kill; zap; start - on production servers. Valid point. Other than vixie-cron (damn thing just never seems to die properly on any platform so restarts always fail) I don't really run into these issues What I do run into is daemons that drop privs on start up, like tac_plus. Unwary new sysadmins always try start/stop it as root, causing an unholy mess. Root the owns the log and pid files, when tac_plus drops privs it can't record it's state so continues to service requests but fails to log any of them. For an auth daemon, that's a serious issue. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On Tue, February 18, 2014 10:47, Alan McKinnon wrote: On 18/02/2014 05:46, Mark David Dumlao wrote: I used to use cherokee. Fast, light, awesome, and with a web admin. The init script always failed me. /etc/init.d/cherokee stop was not a guaranteed stop to all forked cherokee processes - the parent pid dies, but some forked process or something, usually related to rrdtool, doesn't. Or the parent does exit and erases the pid file but it returns control immediately and its not yet done exiting. Something like that or other. Point is, I've several times had to ps aux|grep ... kill; zap; start - on production servers. Valid point. Other than vixie-cron (damn thing just never seems to die properly on any platform so restarts always fail) I don't really run into these issues Interesting, I have never had issues with restarting vixie-cron using the supplied init-scripts. What I do run into is daemons that drop privs on start up, like tac_plus. Unwary new sysadmins always try start/stop it as root, causing an unholy mess. Root the owns the log and pid files, when tac_plus drops privs it can't record it's state so continues to service requests but fails to log any of them. For an auth daemon, that's a serious issue. Shouldn't sysadmins use the init-scripts for that? If done correctly, permissions should not be an issue. Restarting services without keeping file ownership into account will always cause issues. Regardless of the init-system used. And tac_plus not checking if it is allowed to write to the log during the initialization phase should be considered a bug. -- Joost
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On Sun, February 16, 2014 22:16, Canek Peláez Valdés wrote: On Sun, Feb 16, 2014 at 2:58 PM, Volker Armin Hemmann volkerar...@googlemail.com wrote: oh? I can pipe that output into cat or any any daemon I like? Doesn't look like so. But it does, you can cat with journalctl; it's one of its output options: -o, --output= cat generates a very terse output only showing the actual message of each journal entry with no meta data, not even a timestamp. As I do not have systemd installed on any machine, I can't check the man-pages. But, if that is the only method to get parseable text from journalctl, then that is less then useless. I would expect an export option providing the same detail level as I currently find in /var/log/messages. A timestamp is a minimum required for logging system output. -- Joost
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On 18/02/2014 11:52, J. Roeleveld wrote: On Tue, February 18, 2014 10:47, Alan McKinnon wrote: On 18/02/2014 05:46, Mark David Dumlao wrote: I used to use cherokee. Fast, light, awesome, and with a web admin. The init script always failed me. /etc/init.d/cherokee stop was not a guaranteed stop to all forked cherokee processes - the parent pid dies, but some forked process or something, usually related to rrdtool, doesn't. Or the parent does exit and erases the pid file but it returns control immediately and its not yet done exiting. Something like that or other. Point is, I've several times had to ps aux|grep ... kill; zap; start - on production servers. Valid point. Other than vixie-cron (damn thing just never seems to die properly on any platform so restarts always fail) I don't really run into these issues Interesting, I have never had issues with restarting vixie-cron using the supplied init-scripts. What I do run into is daemons that drop privs on start up, like tac_plus. Unwary new sysadmins always try start/stop it as root, causing an unholy mess. Root the owns the log and pid files, when tac_plus drops privs it can't record it's state so continues to service requests but fails to log any of them. For an auth daemon, that's a serious issue. Shouldn't sysadmins use the init-scripts for that? If done correctly, permissions should not be an issue. It's a little more complex than just that. It's an auth service and user are frequently added, removed and modified. The daemon does syntax checking on it's config file at startup or after being HUP'ed but that only finds static errors. It catches things like adding people to a grop instead of to a group, but misses dynamic mistakes like adding users to groups that don't exist. It's exactly analogous to compile-time vs runtime errors, compilers can't catch the latter. Despite this all being run out of cron with wrapper scripts to check validity, automated additions and safety checks between all three daemons, plus being fully documented on the internal wiki and in bold blinking red caps in the login motd, people still find ways to do stuff things in an attempt to fix it. The daemon also tries to log these errors, by writing to a log file it has no write permissions on. There is nothing I can do about the quality of sysadmins, I have no input into the HR process and damagement think cheaper is always better, including skills. What I can do, is find ways to make the software more resistant to errors than it already is. Restarting services without keeping file ownership into account will always cause issues. Regardless of the init-system used. And tac_plus not checking if it is allowed to write to the log during the initialization phase should be considered a bug. -- Joost -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On Mon, 17 Feb 2014 19:09:40 -0600 Canek Peláez Valdés wrote: How Integrated? The TCP/IP stack *is* integrated. But it is *protocol* integration, *standards* integration not *software* integration. You do want tight integration where it just can't work otherwise, but the design of Unix provides (well, again repeating this), and almost any robust design should provide, the ignorance of one abstraction level about another. Why HAL? Why udev? Why drivers as modules? Why not just go and integrate all stuff into the kernel, well (again!) like MS do, and don't please say I compare wrong things just because MS is not OSS. You make a wrong comparison, because MS is not free (libre) software. With Linux, and systemd, and OpenRC, and HAL, and devfs, and sysv, we have been able to try new technologies (and see that some of them fail, like HAL [yuck!]), because we have the source. But the comparison is quite right. When one have to deal with software lock-in, this means that one have to fork a huge stack of software which is theoretically doable (because software is free), but is impractical unless one owns a corporation with large number of full time paid developers. The same way one in theory can change everything in MS by changing assembler code of their software. Well, this will require some time, but asm is nothing more than low-level programming language, thus formally one have the sources. The key feature here is deliberate and malicious lock-in: as long as software enforces one, it is non-free in practical terms. As you said, you can replace the whole of Linux if you so desire (and have the technical ability). You will never be able to do that with any MS software, and so the comparison makes no sense. Hey, but people are already doing this! Google for ReactOS or Wine. The thing (and that's also my point), apparently *most* of the people willing and able to create cool software have decided that systemd is the way to go. And, even if you want to attribute that to a simple monetary issue, most of them do it *happily* because many things are just easier to do with systemd. Most people should never care what init system is in charge while writing end-user software. If software (e.g. some daemon) depends on specific init system, it is broken by design. They'll be able to stuff everything into it, making effectively a thing in itself which will dictate you where to go and what to do, just because you're not technically competent enough to deal with it -- hence more support calls and more $ etc etc. Oh, but nobody will be able to do that to me. I know how to write code. I'm willing (and I believe able) to write and/or modify software if I don't like how it does things. I've done it before; I could do it again. Even if you have superior and outstanding programming skills I doubt you have time and resources to rewrite the whole software stack (e.g. systemd and everything depending on it) yourself. If *someone*, *willing* AND *able* steps up to do ALL that work, MAYBE it would happen. But don't complain if no one does, and it doesn't. That's your point -- and mine. We aren't complaining -- we want to prevent this. Prevent what? People writing new software that offers cool features, and therefore distros are using them? Prevent loosing our freedom in practical sense: while the software will be still free in FSF license terms, it will be so locked onto itself that it will be eventually impossible for anyone besides large corporations to replace it. Thus in the end we'll be dictated what to do and how to do. The forward-looking people must unite, it may sound ridiculous, against systemd You cannot stop people for writing new cool stuff, nor distros for wanting to using them. You CAN write your own cool stuff, and convincing people that is better than the alternative. And you can't force people to use your cool stuff because you're assuming it is cool. That's called freedom, freedom of choice. That is what I love Gentoo for. That's why I support systemd profile propose. That's why I will do my best to protect this freedom in our community. You know what it is: everything's free but nothing to choose from. We had it before, it's called communism. Maybe it is not that bad but we don't want it anymore. (Really? A cold war reference?) Yes, we have a software^Wcorporation war right upon us. Best regards, Andrew Savchenko pgpwNStDaxmGV.pgp Description: PGP signature
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On 2014-02-17 3:17 PM, Andrew Savchenko birc...@gmail.com wrote: OK, my choice of words was not appropriate. I mean that not every kernel dev is happy that kdbus is in the kernel now. Noted... Also, please don't CC me, I'm on the list...
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On Tue, Feb 18, 2014 at 5:52 PM, J. Roeleveld jo...@antarean.org wrote: On Tue, February 18, 2014 10:47, Alan McKinnon wrote: On 18/02/2014 05:46, Mark David Dumlao wrote: I used to use cherokee. Fast, light, awesome, and with a web admin. The init script always failed me. /etc/init.d/cherokee stop was not a guaranteed stop to all forked cherokee processes - the parent pid dies, but some forked process or something, usually related to rrdtool, doesn't. Or the parent does exit and erases the pid file but it returns control immediately and its not yet done exiting. Something like that or other. Point is, I've several times had to ps aux|grep ... kill; zap; start - on production servers. Valid point. Other than vixie-cron (damn thing just never seems to die properly on any platform so restarts always fail) I don't really run into these issues Interesting, I have never had issues with restarting vixie-cron using the supplied init-scripts. What I do run into is daemons that drop privs on start up, like tac_plus. Unwary new sysadmins always try start/stop it as root, causing an unholy mess. Root the owns the log and pid files, when tac_plus drops privs it can't record it's state so continues to service requests but fails to log any of them. For an auth daemon, that's a serious issue. Shouldn't sysadmins use the init-scripts for that? If done correctly, permissions should not be an issue. Restarting services without keeping file ownership into account will always cause issues. Regardless of the init-system used. That's just the thing though. As a sysadmin, how do you debug a service that isn't starting to begin with? Let's say your new to the service. You're not even sure if you got the config right the first time around. Or maybe you're adjusting a setting somewhere, and you're confused why it isn't taking effect. All the /upstream documentation/, all the /man pages/, all the /usr/share/doc stuff will tell you to start it _raw_. The init script obscures the starting options, environment variables, and sometimes even the running user from you. What are you gonna do, play a human shell script parser? Nobody's perfect, do it enough times and you're going to casually gloss over the line where --safe-mode is appended to the string depending on the phase of the moon... If you're lucky, you've never had to start an unfamiliar service, or debug someone else's unfamiliar config under time pressure... -- This email is:[ ] actionable [ ] fyi[x] social Response needed: [ ] yes [x] up to you [ ] no Time-sensitive: [ ] immediate[ ] soon [x] none
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On Tue, February 18, 2014 12:54, Mark David Dumlao wrote: On Tue, Feb 18, 2014 at 5:52 PM, J. Roeleveld jo...@antarean.org wrote: On Tue, February 18, 2014 10:47, Alan McKinnon wrote: On 18/02/2014 05:46, Mark David Dumlao wrote: I used to use cherokee. Fast, light, awesome, and with a web admin. The init script always failed me. /etc/init.d/cherokee stop was not a guaranteed stop to all forked cherokee processes - the parent pid dies, but some forked process or something, usually related to rrdtool, doesn't. Or the parent does exit and erases the pid file but it returns control immediately and its not yet done exiting. Something like that or other. Point is, I've several times had to ps aux|grep ... kill; zap; start - on production servers. Valid point. Other than vixie-cron (damn thing just never seems to die properly on any platform so restarts always fail) I don't really run into these issues Interesting, I have never had issues with restarting vixie-cron using the supplied init-scripts. What I do run into is daemons that drop privs on start up, like tac_plus. Unwary new sysadmins always try start/stop it as root, causing an unholy mess. Root the owns the log and pid files, when tac_plus drops privs it can't record it's state so continues to service requests but fails to log any of them. For an auth daemon, that's a serious issue. Shouldn't sysadmins use the init-scripts for that? If done correctly, permissions should not be an issue. Restarting services without keeping file ownership into account will always cause issues. Regardless of the init-system used. That's just the thing though. As a sysadmin, how do you debug a service that isn't starting to begin with? This isn't what Alan was talking about. He was talking about restarting an existing, working service. Let's say your new to the service. You're not even sure if you got the config right the first time around. Or maybe you're adjusting a setting somewhere, and you're confused why it isn't taking effect. In an environment where Alan works, I wouldn't be the only person around. There should be someone on call who knows. All the /upstream documentation/, all the /man pages/, all the /usr/share/doc stuff will tell you to start it _raw_. The init script obscures the starting options, environment variables, and sometimes even the running user from you. What are you gonna do, play a human shell script parser? Nobody's perfect, do it enough times and you're going to casually gloss over the line where --safe-mode is appended to the string depending on the phase of the moon... If you're lucky, you've never had to start an unfamiliar service, or debug someone else's unfamiliar config under time pressure... I have been on both ends of this. I have multiple times been in a situation where I was under time-pressure to get services running again on unfamiliar systems. Talking untrained admins through the process by phone-communication only. It is not easy, but by staying calm and focused, mistakes are avoided. Also, in my experience, a calm systematic approach is usually faster then the cowboy-method of trying everything I can find on Google. I have also, too often, had to clean up the mess caused by these cowboy tactics. -- Joost
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On Tue, February 18, 2014 12:17, Alan McKinnon wrote: On 18/02/2014 11:52, J. Roeleveld wrote: On Tue, February 18, 2014 10:47, Alan McKinnon wrote: What I do run into is daemons that drop privs on start up, like tac_plus. Unwary new sysadmins always try start/stop it as root, causing an unholy mess. Root the owns the log and pid files, when tac_plus drops privs it can't record it's state so continues to service requests but fails to log any of them. For an auth daemon, that's a serious issue. Shouldn't sysadmins use the init-scripts for that? If done correctly, permissions should not be an issue. It's a little more complex than just that. It's an auth service and user are frequently added, removed and modified. The daemon does syntax checking on it's config file at startup or after being HUP'ed but that only finds static errors. It catches things like adding people to a grop instead of to a group, but misses dynamic mistakes like adding users to groups that don't exist. The auth-service gets the current state from a static file that is only read upon service-start? It's exactly analogous to compile-time vs runtime errors, compilers can't catch the latter. Despite this all being run out of cron with wrapper scripts to check validity, automated additions and safety checks between all three daemons, plus being fully documented on the internal wiki and in bold blinking red caps in the login motd, people still find ways to do stuff things in an attempt to fix it. (OT: Does the bold blinking red caps work on all terminals? :) ) The daemon also tries to log these errors, by writing to a log file it has no write permissions on. setuid on the group with group-write in the umask not an option? There is nothing I can do about the quality of sysadmins, I have no input into the HR process and damagement think cheaper is always better, including skills. What I can do, is find ways to make the software more resistant to errors than it already is. And only grant access permissions to these rookies once they have proven they understand rule #1: If In Doubt, Call Someone Who Knows! But yes, I fully understand the methods of HR and Damagement. It is a financial mistake and risk not to include technical expertise checks in the recruitement fase for technical positions. How much does it cost the company each time this goes wrong and someone like you has to come online to fix the issue? That is what Damagement needs to understand. -- Joost
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On Mon, 17 Feb 2014 23:30:42 -0600 Canek Peláez Valdés can...@gmail.com wrote: On Mon, Feb 17, 2014 at 8:05 PM, Gevisz gev...@gmail.com wrote: [ snip ] How can you be sure if something is large enough if, as you say below, you do not care about probabilities? By writing correct code? No, by arguing that fixing bugs in a 200K line program is as easy as fixing a bug in 20 10K line programs. It is just not true, just the opposite. SysVinit code size is about 10 000 lines of code, OpenRC contains about 13 000 lines, systemd — about 200 000 lines. If you take into account the thousands of shell code that SysV and OpenRC need to fill the functionality of systemd, they use even more. Also, again, systemd have a lot of little binaries, many of them optional. The LOC of PID 1 is actually closer to SysV (although still bigger). Even assuming systemd code is as mature as sysvinit or openrc (though I doubt this) you can calculate probabilities of segfaults yourself easily. I don't care about probabilities; If you do not care (= do not now anything) about probabilities (and mathematics, in general), you just unable to understand that debugging a program with 200K lines of code take 20!/(1!)^20 more time than debugging of 20 different programs with 10K lines of code. You can try to calculate that number yourself but I quite sure that if the latter can take, say, 20 days, the former can take millions of years. It is all the probability! Or, to be more precise, combinatorics. My PhD thesis (which I will defend in a few weeks) is in computer science, specifically computational geometry and combinatorics. It is even more shameful for you to not understand such a simple facts from elementary probability theory (which is mostly based on combinatorics). And, believe me, here, in this mailing list, there are a lot people that have there PhD defended a long time ago. However, they do not thing it is appropriate to use such facts in their arguments about merits or dismerits of one or the other approach to computer programming. But hey, thanks for the lesson. Not at all. I care about facts: FACT, I've been using systemd since 2010, in several machines, and I haven't had a single segfault. Have you ever tried forex? If yes, you should have been warned that no past performance guarantee the future one. I never said that. I trust the quality of the code, measured by my own judgment and bug reports, etc. Not past performance. And even if a bug goes by, then what? The world will end? No, the bug will be reported, and fixed. And life will go on. And if you do not believe that (and do not care about probability and all the stuff like that), you should visit any of the forex forums where you will be suggested a magical money winning strategy that, in the past, behaved very well and earned 200 or even 500% a month. Thanks for the tip, but I have never understood the people that believes economics is closer to mathematics than sociology. FACT: almost no bug report in systemd involves a segfault in PID 1. All of them are different tools providing one capability to systemd as a whole. So systemd is a collection of tools, where each one does one thing, and it does it well. By your definition, systemd perfectly follows the unix way. no, it isn't. How are those binaries talk to each other? dbus, which is about to be integrated into the kernel with kdbus. And this is a very, very bad idea. Looks like you don't know matter at all: to begin with kdbus protocol is NOT compatible dbus and special converter daemon will be needed to enable dbus to talk to kdbus. kdbus uses a different wire protocol than dbus; but for clients that doesn't matter; libsystemd-dbus will offer a compatibility layer (talk about standard and replaceable), so if your application uses dbus today, it will work with kdbus. Of course, new applications will take advantage of the new features of kdbus. The whole kdbus technology is very questionable itself (and was forcefully pushed by RH devs), Sorry, but it's you who doesn't know the matter at hand: kdbus was (and is) written by Greg Kroah-Hartman, Linus' right hand, and who works for the Linux Foundation. Lol, he seems to start to use the arguments like You even do not know my elder brother/acquaintance from the street nearby who can easily hit you down! If you don't think Greg's words have any weight in a Linux-related technical discussion, then I'm afraid we will need to agree to disagree on any technical subject. So, here, I would like to thank everybody in this discussion who helped me to understand the danger of systemd and note that it is now became pointless to continue this discussion with this unpayed systemd promoter. Getting personal, are we? I am
Re: [gentoo-user] Re: Debian just voted in systemd for default init system in jessie
On Tue, Feb 18, 2014 at 2:19 AM, Nicolas Sebrecht nsebre...@piing.fr wrote: The 17/02/14, Canek Peláez Valdés wrote: It depends; right now you can't switch back and forth between OpenRC and systemd without reemerging some stuff. Interesting. Didn't know that. What packages need to be recompiled? Some packages need to be emerged with USE=-systemd when going from systemd to OpenRC, and with USE=systemd the other way around. Different code paths are selected in each case. As I said before, the code paths could be chosen at run time, but I don't think any upstream will accept patches supporting this, or think that they are useful BTW, respect for your patience in this thread! Thanks; I've been on the list since 2002, so I think I can say that this thread has been actually pretty civil and technically oriented (except for a couple of trolls). Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
[gentoo-user] How to properly set up Bluetooth
Hi, i'm trying to set up a simple bluetooth keyboard, but somehow it won't work :-) This is my setup: Systemd + GDM + Fluxbox (this is the easiest way for me to use gnome-stuff like gnome-keyring-daemon, ... In the background my fluxbox is also running a gnome-settings-daemon) hcitool dev successfully detects my bluetooth device. According to [1] I tried to set up my keyboard using the command line. But actually simple-agent doesn't seem to be available in bluez 5.x. So I tried to use blueman-applet. This is a snippet of the output of blueman-applet: Function on_manager_state_changed on RecentConns Failed Traceback (most recent call last): File /usr/lib64/python2.7/site-packages/blueman/main/PluginManager.py, line 220, in Run ret = getattr(inst, function)(*args, **kwargs) File /usr/lib64/python2.7/site-packages/blueman/plugins/applet/RecentConns.py, line 195, in on_manager_state_changed adapters = self.Applet.Manager.ListAdapters() File /usr/lib64/python2.7/site-packages/blueman/bluez/utils.py, line 28, in warp raise errors.parse_dbus_error(exception) DBusException: org.freedesktop.DBus.Error.UnknownMethod: Method ListAdapters with signature on interface org.bluez.Manager doesn't exist It seems to me that this is a dbus problem or something like that, but I don't know what I am doing wrong. I started systemctl start bluetooth and my user is in the group plugdev. Any suggestions? [1] http://wiki.gentoo.org/wiki/Bluetooth Regards Ralf
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On Tue, Feb 18, 2014 at 3:54 AM, J. Roeleveld jo...@antarean.org wrote: On Sun, February 16, 2014 22:16, Canek Peláez Valdés wrote: On Sun, Feb 16, 2014 at 2:58 PM, Volker Armin Hemmann volkerar...@googlemail.com wrote: oh? I can pipe that output into cat or any any daemon I like? Doesn't look like so. But it does, you can cat with journalctl; it's one of its output options: -o, --output= cat generates a very terse output only showing the actual message of each journal entry with no meta data, not even a timestamp. As I do not have systemd installed on any machine, I can't check the man-pages. They are online [1]. But, if that is the only method to get parseable text from journalctl, then that is less then useless. I only put that option as tongue-in-cheek, since someone complained about not being able to cat the logs. Many more options are available. I would expect an export option providing the same detail level as I currently find in /var/log/messages. A timestamp is a minimum required for logging system output. Everybody agrees with that; that's why the journal supports a lot of formatting options. From [2]: -o, --output= Controls the formatting of the journal entries that are shown. Takes one of the following options: short is the default and generates an output that is mostly identical to the formatting of classic syslog files, showing one line per journal entry. short-iso is very similar, but shows ISO 8601 wallclock timestamps. short-precise is very similar, but shows timestamps with full microsecond precision. short-monotonic is very similar, but shows monotonic timestamps instead of wallclock timestamps. verbose shows the full-structured entry items with all fields. export serializes the journal into a binary (but mostly text-based) stream suitable for backups and network transfer (see Journal Export Format[1] for more information). json formats entries as JSON data structures, one per line (see Journal JSON Format[2] for more information). json-pretty formats entries as JSON data structures, but formats them in multiple lines in order to make them more readable for humans. json-sse formats entries as JSON data structures, but wraps them in a format suitable for Server-Sent Events[3]. cat generates a very terse output only showing the actual message of each journal entry with no meta data, not even a timestamp. So you can have the default; journalctl -b | head: -- Logs begin at Tue 2013-09-24 13:39:03 CDT, end at Tue 2014-02-18 08:28:44 CST. -- Feb 10 09:50:37 centurion systemd-journal[371]: Runtime journal is using 712.0K (max 198.0M, leaving 297.1M of free 1.9G, current limit 198.0M). Feb 10 09:50:37 centurion systemd-journal[371]: Runtime journal is using 716.0K (max 198.0M, leaving 297.1M of free 1.9G, current limit 198.0M). Feb 10 09:50:37 centurion systemd-journal[371]: Journal started Feb 10 09:50:37 centurion systemd-modules-load[370]: Inserted module 'fuse' Feb 10 09:50:37 centurion systemd[1]: Starting Swap. Feb 10 09:50:37 centurion systemd[1]: Reached target Swap. Feb 10 09:50:37 centurion systemd-modules-load[370]: Inserted module 'kvm_intel' Feb 10 09:50:37 centurion systemd[1]: Starting Local File Systems. Feb 10 09:50:37 centurion systemd-journal[371]: Missed 107 kernel messages (The -b option shows the logs from the current boot; you can get the previous one with -b -1, the one before with -b -2, etc.) You can have short; journalctl -b -o short | head, which for the first lines of my current boot look the same as the default. You can have ISO timestamps; journalctl -b -o short-iso: -- Logs begin at Tue 2013-09-24 13:39:03 CDT, end at Tue 2014-02-18 08:31:54 CST. -- 2014-02-10T09:50:37-0600 centurion systemd-journal[371]: Runtime journal is using 712.0K (max 198.0M, leaving 297.1M of free 1.9G, current limit 198.0M). 2014-02-10T09:50:37-0600 centurion systemd-journal[371]: Runtime journal is using 716.0K (max 198.0M, leaving 297.1M of free 1.9G, current limit 198.0M). 2014-02-10T09:50:37-0600 centurion systemd-journal[371]: Journal started 2014-02-10T09:50:37-0600 centurion systemd-modules-load[370]: Inserted module 'fuse' 2014-02-10T09:50:37-0600 centurion systemd[1]: Starting Swap. 2014-02-10T09:50:37-0600 centurion systemd[1]: Reached target Swap. 2014-02-10T09:50:37-0600 centurion systemd-modules-load[370]: Inserted module 'kvm_intel' 2014-02-10T09:50:37-0600 centurion systemd[1]: Starting Local File Systems. 2014-02-10T09:50:37-0600 centurion systemd-journal[371]: Missed 107 kernel messages You can have nanosecond precision; journalctl -b -o short-precise | head: -- Logs begin at Tue 2013-09-24 13:39:03 CDT, end at Tue
Re: [gentoo-user] How to properly set up Bluetooth
Ralf ralf+gen...@ramses-pyramidenbau.de wrote: Hi, i'm trying to set up a simple bluetooth keyboard, but somehow it won't work :-) This is my setup: Systemd + GDM + Fluxbox (this is the easiest way for me to use gnome-stuff like gnome-keyring-daemon, ... In the background my fluxbox is also running a gnome-settings-daemon) hcitool dev successfully detects my bluetooth device. According to [1] I tried to set up my keyboard using the command line. But actually simple-agent doesn't seem to be available in bluez 5.x. So I tried to use blueman-applet. This is a snippet of the output of blueman-applet: Function on_manager_state_changed on RecentConns Failed Traceback (most recent call last): File /usr/lib64/python2.7/site-packages/blueman/main/PluginManager.py, line 220, in Run ret = getattr(inst, function)(*args, **kwargs) File /usr/lib64/python2.7/site-packages/blueman/plugins/applet/RecentConns.py, line 195, in on_manager_state_changed adapters = self.Applet.Manager.ListAdapters() File /usr/lib64/python2.7/site-packages/blueman/bluez/utils.py, line 28, in warp raise errors.parse_dbus_error(exception) DBusException: org.freedesktop.DBus.Error.UnknownMethod: Method ListAdapters with signature on interface org.bluez.Manager doesn't exist It seems to me that this is a dbus problem or something like that, but I don't know what I am doing wrong. I started systemctl start bluetooth and my user is in the group plugdev. Any suggestions? [1] http://wiki.gentoo.org/wiki/Bluetooth I would like to have simple-agent back as well, at least the script part -- I think the other bits are still there, why they would take away something so ssimple I have no idea. -- Your life is like a penny. You're going to lose it. The question is: How do you spend it? John Covici cov...@ccs.covici.com
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On Tue, Feb 18, 2014 at 5:35 AM, Andrew Savchenko birc...@gmail.com wrote: On Mon, 17 Feb 2014 19:09:40 -0600 Canek Peláez Valdés wrote: How Integrated? The TCP/IP stack *is* integrated. But it is *protocol* integration, *standards* integration not *software* integration. You do want tight integration where it just can't work otherwise, but the design of Unix provides (well, again repeating this), and almost any robust design should provide, the ignorance of one abstraction level about another. Why HAL? Why udev? Why drivers as modules? Why not just go and integrate all stuff into the kernel, well (again!) like MS do, and don't please say I compare wrong things just because MS is not OSS. You make a wrong comparison, because MS is not free (libre) software. With Linux, and systemd, and OpenRC, and HAL, and devfs, and sysv, we have been able to try new technologies (and see that some of them fail, like HAL [yuck!]), because we have the source. But the comparison is quite right. When one have to deal with software lock-in, this means that one have to fork a huge stack of software which is theoretically doable (because software is free), but is impractical unless one owns a corporation with large number of full time paid developers. The same way one in theory can change everything in MS by changing assembler code of their software. Well, this will require some time, but asm is nothing more than low-level programming language, thus formally one have the sources. You cannot distribute changes that you do to proprietary disassembled code. So again, the comparison makes no sense. The key feature here is deliberate and malicious lock-in: as long as software enforces one, it is non-free in practical terms. We are running around in circles; I told you why is not a reasonable comparison, and I failed to convince you. You told me that it's a right comparison to make, and you failed to convince me. We could keep beating a dead horse, but it's better if we agree to disagree on this point. (Which kinda makes the rest of the discussion moot, but whatever). As you said, you can replace the whole of Linux if you so desire (and have the technical ability). You will never be able to do that with any MS software, and so the comparison makes no sense. Hey, but people are already doing this! Google for ReactOS or Wine. I mentioned ReactOS in this thread; from [1]: If enough people, willing and able, want to do it, they will. Look at ReactOS. Or Syllable. Or Hurd. Or Debian/kFreeBSD. However, the ReactOS people aren't disassembling code; they are coding a different (but compatible) implementation. Same goes with Wine. And even if you say that disassembled code is the same as carefully written code (which is not), we have comments inside the code [2], and DCSV logs [3], and tons of documentation. With proprietary code we don't; sometimes a little documentation for how to *use* the code, but not how to *change* it or *understand* it. The thing (and that's also my point), apparently *most* of the people willing and able to create cool software have decided that systemd is the way to go. And, even if you want to attribute that to a simple monetary issue, most of them do it *happily* because many things are just easier to do with systemd. Most people should never care what init system is in charge while writing end-user software. If software (e.g. some daemon) depends on specific init system, it is broken by design. They don't care about the init system. They care about the *features* systemd provides; logind, the journal, timedated, hostnamed, etc. Obviously systemd is much more than just an init system. They'll be able to stuff everything into it, making effectively a thing in itself which will dictate you where to go and what to do, just because you're not technically competent enough to deal with it -- hence more support calls and more $ etc etc. Oh, but nobody will be able to do that to me. I know how to write code. I'm willing (and I believe able) to write and/or modify software if I don't like how it does things. I've done it before; I could do it again. Even if you have superior and outstanding programming skills I doubt you have time and resources to rewrite the whole software stack (e.g. systemd and everything depending on it) yourself. As I said, that is moot since Linux+systemd+GNOME are taking Linux to the place I always wanted it to be. If *someone*, *willing* AND *able* steps up to do ALL that work, MAYBE it would happen. But don't complain if no one does, and it doesn't. That's your point -- and mine. We aren't complaining -- we want to prevent this. Prevent what? People writing new software that offers cool features, and therefore distros are using them? Prevent loosing our freedom in practical sense: while the software will be still free in FSF license terms, it will be so locked onto itself that it will
Re: [gentoo-user] How to properly set up Bluetooth
On Tue, Feb 18, 2014 at 8:34 AM, Ralf ralf+gen...@ramses-pyramidenbau.de wrote: Hi, i'm trying to set up a simple bluetooth keyboard, but somehow it won't work :-) This is my setup: Systemd + GDM + Fluxbox (this is the easiest way for me to use gnome-stuff like gnome-keyring-daemon, ... In the background my fluxbox is also running a gnome-settings-daemon) hcitool dev successfully detects my bluetooth device. According to [1] I tried to set up my keyboard using the command line. But actually simple-agent doesn't seem to be available in bluez 5.x. So I tried to use blueman-applet. This is a snippet of the output of blueman-applet: Function on_manager_state_changed on RecentConns Failed Traceback (most recent call last): File /usr/lib64/python2.7/site-packages/blueman/main/PluginManager.py, line 220, in Run ret = getattr(inst, function)(*args, **kwargs) File /usr/lib64/python2.7/site-packages/blueman/plugins/applet/RecentConns.py, line 195, in on_manager_state_changed adapters = self.Applet.Manager.ListAdapters() File /usr/lib64/python2.7/site-packages/blueman/bluez/utils.py, line 28, in warp raise errors.parse_dbus_error(exception) DBusException: org.freedesktop.DBus.Error.UnknownMethod: Method ListAdapters with signature on interface org.bluez.Manager doesn't exist It seems to me that this is a dbus problem or something like that, but I don't know what I am doing wrong. I started systemctl start bluetooth and my user is in the group plugdev. Any suggestions? Can you install gnome-bluetooth and run bluetooth-wizard? Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On Tue, 18 Feb 2014 11:46:14 +0800 Mark David Dumlao wrote: init scripts, in general, are ad-hoc, quirky, and incomplete implementations of service supervision in bash. They're reliable so long as the daemon can be relied on to advertise one or all of its processes in a pid file. Thing is, there are way too many different possible setups for services for that to be the case. In the average case watching a PID file works. And since most people use average software, most people don't care. That's ok. Thing is an init isn't just for most people. It's for all people. It should be reliable for all services. I used to use cherokee. Fast, light, awesome, and with a web admin. The init script always failed me. /etc/init.d/cherokee stop was not a guaranteed stop to all forked cherokee processes - the parent pid dies, but some forked process or something, usually related to rrdtool, doesn't. Or the parent does exit and erases the pid file but it returns control immediately and its not yet done exiting. Something like that or other. Point is, I've several times had to ps aux|grep ... kill; zap; start - on production servers. Was it cherokee's fault? Maybe. But the init script should have told me that. Or even better, the init script should have done its job and terminted the processes. See, pid files are just a proxy, they don't work for all services and all setups. Maybe a process crashes before it kills its forks. Maybe the server has a restart feature that fails to write the pid file because the init script created it as root but the daemon relinquished privileges. Maybe there's a bug somewhere. Maybe the pid file gets overwritten accidentally. Maybe the pid file is stale because of a power failure. Point is you don't know until the service restart which should just take a sec costs you maybe an hour or two in billable time. With supervised cgroups that's not a problem. Because all process forks are grouped together, it doesn't matter if there's a pid file or not. When its kill time, the daemon and all forks and children go down. Because they're dynamically created on start, they don't get stale or point to the wrong process. Sounds to me like the right tool for the job. I agree with you. But openrc has cgroups support now for each service started. Thus systemd is not the only solution solving problem you described above. Best regards, Andrew Savchenko pgpPRQOqUQGFy.pgp Description: PGP signature
Re: [gentoo-user] How to properly set up Bluetooth
On 02/18/14 16:05, Canek Peláez Valdés wrote: install gnome-bluetooth and run blue This is what I get: (bluetooth-wizard:3156): Bluetooth-WARNING **: Pair() failed: Timeout was reached ** (bluetooth-wizard:3156): WARNING **: Setting up 'KC1280 BT Keyboard' failed: Timeout was reached The keyboard works fine with my android phone. Regards Ralf
Re: [gentoo-user] How to properly set up Bluetooth
On Tue, Feb 18, 2014 at 9:49 AM, Ralf ralf+gen...@ramses-pyramidenbau.de wrote: On 02/18/14 16:05, Canek Peláez Valdés wrote: install gnome-bluetooth and run blue This is what I get: (bluetooth-wizard:3156): Bluetooth-WARNING **: Pair() failed: Timeout was reached ** (bluetooth-wizard:3156): WARNING **: Setting up 'KC1280 BT Keyboard' failed: Timeout was reached The keyboard works fine with my android phone. OK, I think I see the problem. Do you have the bluetooth service running? What's the output for: systemctl status bluetooth.service Supposedly it should autostart by dbus activation. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-user] How to properly set up Bluetooth
On Tue, Feb 18, 2014 at 10:14 AM, Ralf ralf+gen...@ramses-pyramidenbau.de wrote: On 02/18/14 17:10, Canek Peláez Valdés wrote: systemctl status bluetooth.service Yes, sure, as I wrote above. Active: active (running) since Tue 2014-02-18 16:57:05 CET; 15min ago ps auxw|grep bluetoot root 3571 27.6 0.0 21200 2112 ?Rs 16:57 4:29 /usr/libexec/bluetooth/bluetoothd As you see everything is actually running fine... I even tried to restart it several times OK, sorry, I hadn't read carefully your first post. blueman-applet fails because it uses the 4.x dbus API from bluez. gnome-bluetooth uses the 5.x dbus API, and AFAIK, right now it's the only tool using it. So, with gnome-bluetooth you can detect your keyboard but the pairing fails? You say you paired the keyboard correctly with your android phone; you don't need to do something in the keyboard to pair it to a different hosts? Something like keep pressing the power button? Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-user] How to properly set up Bluetooth
On 02/18/14 17:10, Canek Peláez Valdés wrote: systemctl status bluetooth.service Yes, sure, as I wrote above. Active: active (running) since Tue 2014-02-18 16:57:05 CET; 15min ago ps auxw|grep bluetoot root 3571 27.6 0.0 21200 2112 ?Rs 16:57 4:29 /usr/libexec/bluetooth/bluetoothd As you see everything is actually running fine... I even tried to restart it several times
[gentoo-user] systemd as a Profile - practical or not?
Hi all, Ok, before I go and open up a bug requesting this... I know there have to be a lot of people on this list who can answer this question... Is making the use of systemd or not based on a selected Profile, as opposed to manually trying to do it via USE flags etc, a practical request, or not? Meaning: 1. is it doable, 2. how hard (on a scale of 1/easy to 10/hard to impossible) would it be to do this, and 3. regardless of the difficulty in achieving it, how hard would it be (on a scale of 1 (easy) to 10 (hard to impossible)) to maintain in the long run? I'm hoping that even if the answer to #2 above is 7+, if the answer to #3 is 'relatively easy' or better, then maybe it still stands a chance of getting done. And incidentally, Canek, if I was a programmer, I'd be happy to volunteer to take it on, but alas I'm just a lowly user... Thanks...
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On Mon, 17 Feb 2014 18:35:34 -0600 Canek Peláez Valdés wrote: [...] Complexity means bugs. Bugs get reported, bugs get fixes. Life goes on. You didn't answered this, did you? Bugs are different. Bugs are bugs, period. And they get reported and fixed. Bugs are not equal. They differ in at least two dimensions: significance depending on the component affected and severity of the bug itself. Bugs in the critical system components are critical to the whole system. Yeah, that's why we have unit testing and QA teams and stable and unstable releases, etc. Every decent project has QA and unit tests one way or another. But the larger project is, the more bugs it has. And I do not want bugs in PID 1, that's why it should be small and sound, not bloated (even with some components split as separate binaries) and broken by design. If Libreoffice or browser segfaults, some data may be lost and inconvenience created, but the system will continue to run. If PID 1 segfaults — everything is lost, you have a kernel panic. And the world will end? The same happens if the kernel has an error. Kernel has mature error correction infrastructure (Oops handling) and much wider community. That's why critical components should be as simple and clean as possible. Like the kernel? You call that simple? Don't mix user space and kernel space, please. There are more secure by design micro kernels out there (like Hurd), but they're out of the scope of this discussion. I'm sorry, but you are (IMO) wrong: critical components should be thoroughly tested and debugged, and have integrated unit testing, and a large enough group of volunteers to test new releases before they go into the general public. You're pointing to valid issues, but not to the whole picture. Critical components should _start_ from good design, sound modular architecture and _then_ with QA and testing. You're omitting the most important stuff, though. SysVinit code size is about 10 000 lines of code, OpenRC contains about 13 000 lines, systemd — about 200 000 lines. If you take into account the thousands of shell code that SysV and OpenRC need to fill the functionality of systemd, they use even more. If that code will fail, this wouldn't be critical at system level. Thus scope of fatal error is limited. Even assuming systemd code is as mature as sysvinit or openrc (though I doubt this) you can calculate probabilities of segfaults yourself easily. I don't care about probabilities; I care about facts: FACT, I've been using systemd since 2010, in several machines, and I haven't had a single segfault. FACT: almost no bug report in systemd involves a segfault in PID 1. You need facts? Here is one for you (systemd-208): http://fly.osdn.org.ua/~mike/img/misc/systemd-segfault.jpg Looks broken. Broken by design. The worst form of broken. By your opinion, not others. That is not just an opinion. There is a science and experience behind system's design. Yeah, what do you think about Greg Kroah-Hartman, Linus' right hand, or Keith Packard of X.org fame? None of them works for Red Hat; both of them know more about Unix and Linux than you and me together, and both of them promote systemd. I respect Greg for most of his work, but this doesn't mean he is an oracle we need to adhere to. But in FOSS reputation is not that important, though clean technical reasons are. And all that science was ignored during systemd architecture process if there was any at all. You should read systemd-devel and Lennart's blog posts before saying something like that. I did. I read that blog. No valid reason were found (if we're comparing systemd to what is outside of systemd's world, not only to bare sysvinit). But what I found it that blog is a lack of thorough project design (it looks like many components were added by the fly without preliminary planning) and a lot of religious statements. Best regards, Andrew Savchenko pgpko_nMZl2xr.pgp Description: PGP signature
[gentoo-user] Re: systemd as a Profile - practical or not?
On Tue, 18 Feb 2014 11:24:05 -0500, Tanstaafl tansta...@libertytrek.org wrote: Hi all, Ok, before I go and open up a bug requesting this... I know there have to be a lot of people on this list who can answer this question... Is making the use of systemd or not based on a selected Profile, as opposed to manually trying to do it via USE flags etc, a practical request, or not? How is this different from the status quo? There are several systemd profiles available that make use of the files in /usr/portage/profiles/targets/systemd/ to make the proper package settings for using systemd on gentoo. AFAIU, a user should only need to switch the profile, install and configure systemd itself and configure their bootloader to start using systemd. -- eroen signature.asc Description: PGP signature
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On Tue, 18 Feb 2014 04:05:03 +0200 Gevisz wrote: I mean, I myself know a thing or two about computing and Linux, and I promote systemd (and nobody pays me, BTW), but obviously you don't need to believe in my credentials. I have said you, he is just an unpayed fanatic systemd promoter! Frankly, I have doubts he is unpayed. Though as long as arguments are technical this doesn't matter. Though when arguments are down to Said who? Listen to the Oracle! it starts to. Best regards, Andrew Savchenko pgp3mkVhNVMFr.pgp Description: PGP signature
Re: [gentoo-user] How to properly set up Bluetooth
I got it working! But I can't reproduce what i did.. I played around with bluetoothctl which seems to be a interactive replacement for simple-agent. After powering my bluetooth device on and off, trusting and untrusting, pairing and unpairing for several times it now *seems* to work. It even connects automatically after turning it on :-) Bluetooth stuff is really weird Thanks! On 02/18/14 17:20, Canek Peláez Valdés wrote: On Tue, Feb 18, 2014 at 10:14 AM, Ralf ralf+gen...@ramses-pyramidenbau.de wrote: On 02/18/14 17:10, Canek Peláez Valdés wrote: systemctl status bluetooth.service Yes, sure, as I wrote above. Active: active (running) since Tue 2014-02-18 16:57:05 CET; 15min ago ps auxw|grep bluetoot root 3571 27.6 0.0 21200 2112 ?Rs 16:57 4:29 /usr/libexec/bluetooth/bluetoothd As you see everything is actually running fine... I even tried to restart it several times OK, sorry, I hadn't read carefully your first post. blueman-applet fails because it uses the 4.x dbus API from bluez. gnome-bluetooth uses the 5.x dbus API, and AFAIK, right now it's the only tool using it. So, with gnome-bluetooth you can detect your keyboard but the pairing fails? You say you paired the keyboard correctly with your android phone; you don't need to do something in the keyboard to pair it to a different hosts? Something like keep pressing the power button? Regards.
Re: [gentoo-user] systemd as a Profile - practical or not?
On Tue, Feb 18, 2014 at 10:24 AM, Tanstaafl tansta...@libertytrek.org wrote: Hi all, Ok, before I go and open up a bug requesting this... I know there have to be a lot of people on this list who can answer this question... Is making the use of systemd or not based on a selected Profile, as opposed to manually trying to do it via USE flags etc, a practical request, or not? Meaning: 1. is it doable, Of course it is. 2. how hard (on a scale of 1/easy to 10/hard to impossible) would it be to do this, and Well, doing it I think it's easy. 3. regardless of the difficulty in achieving it, how hard would it be (on a scale of 1 (easy) to 10 (hard to impossible)) to maintain in the long run? That's the pickle, isn't? Forget about how hard it is. The problem, as I see it, is that this systemd profile is being pushed by the people that *don't* want to use systemd, because they want it restricted to a separated profile so their machines are not tainted by systemd. If it was the other way around (systemd users wanting a systemd profile), there would be no problem, since they would happily do the job. But as it is it makes no sense; if you want to maintain a systemd profile, you need to *use* systemd to do the testing and supporting. Are the people that don't want to use systemd, will use systemd to test and support a profile so they don't need to use systemd? Really? (And never mind that more and more packages in the stack will want to use systemd's features, and some of them probably will not work, or work with limited functionality, without said features. And a profile is not going to change that.) That being said, the GNOME team introduced a gnome/systemd profile (and later the KDE team did the same). I've never saw the point in doing that, but that's what they decided and is fine. If the Gentoo developers that use and prefer systemd decide to create a systemd profile, then it will (easily, I think) happen. But it's the systemd users the ones you should convince to do it; not anyone *not* using it or avoiding it. I'm hoping that even if the answer to #2 above is 7+, if the answer to #3 is 'relatively easy' or better, then maybe it still stands a chance of getting done. The possibility exists, sure. You can talk to Michał and the other members of the systemd project in Gentoo. If you convince them that it is a good idea (and good for systemd, obviously), they will do it. But anyone that wants to help this happen will need to use systemd to support a systemd profile. That's simple logic. And incidentally, Canek, if I was a programmer, I'd be happy to volunteer to take it on, but alas I'm just a lowly user... I would, but I don't think is worth it. It's not an unreasonable idea, but I think it will make thinks muddy when someone chooses the not systemd profile, and they will discover that anyhow they need systemd to run a lot of things. And, I repeat, usually when someone pushes for an X profile, it's because they want to use X. In this case you are asking for an X profile so you don't need to even see X; it makes no sense, since the X profiles needs the people maintaining it to use X. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-user] How to properly set up Bluetooth
Oh no... After turning of the keyboard, bluetoothd start to consume 100% CPU... I have to run systemctl restart bluetooth after unconnecting my device. Come on... On 02/18/14 17:49, Ralf wrote: I got it working! But I can't reproduce what i did.. I played around with bluetoothctl which seems to be a interactive replacement for simple-agent. After powering my bluetooth device on and off, trusting and untrusting, pairing and unpairing for several times it now *seems* to work. It even connects automatically after turning it on :-) Bluetooth stuff is really weird Thanks! On 02/18/14 17:20, Canek Peláez Valdés wrote: On Tue, Feb 18, 2014 at 10:14 AM, Ralf ralf+gen...@ramses-pyramidenbau.de wrote: On 02/18/14 17:10, Canek Peláez Valdés wrote: systemctl status bluetooth.service Yes, sure, as I wrote above. Active: active (running) since Tue 2014-02-18 16:57:05 CET; 15min ago ps auxw|grep bluetoot root 3571 27.6 0.0 21200 2112 ?Rs 16:57 4:29 /usr/libexec/bluetooth/bluetoothd As you see everything is actually running fine... I even tried to restart it several times OK, sorry, I hadn't read carefully your first post. blueman-applet fails because it uses the 4.x dbus API from bluez. gnome-bluetooth uses the 5.x dbus API, and AFAIK, right now it's the only tool using it. So, with gnome-bluetooth you can detect your keyboard but the pairing fails? You say you paired the keyboard correctly with your android phone; you don't need to do something in the keyboard to pair it to a different hosts? Something like keep pressing the power button? Regards.
Re: [gentoo-user] Re: systemd as a Profile - practical or not?
On 2014-02-18 11:39 AM, eroen er...@falcon.eroen.eu wrote: On Tue, 18 Feb 2014 11:24:05 -0500, Tanstaafl tansta...@libertytrek.org wrote: Hi all, Ok, before I go and open up a bug requesting this... I know there have to be a lot of people on this list who can answer this question... Is making the use of systemd or not based on a selected Profile, as opposed to manually trying to do it via USE flags etc, a practical request, or not? How is this different from the status quo? There are several systemd profiles available that make use of the files in /usr/portage/profiles/targets/systemd/ to make the proper package settings for using systemd on gentoo. AFAIU, a user should only need to switch the profile, install and configure systemd itself and configure their bootloader to start using systemd. Interesting! I guess it's been a while since I looked at the available profiles, because I don't remember seeing those: # eselect profile list Available profile symlink targets: [1] default/linux/amd64/13.0 * [2] default/linux/amd64/13.0/selinux [3] default/linux/amd64/13.0/desktop [4] default/linux/amd64/13.0/desktop/gnome [5] default/linux/amd64/13.0/desktop/gnome/systemd [6] default/linux/amd64/13.0/desktop/kde [7] default/linux/amd64/13.0/desktop/kde/systemd [8] default/linux/amd64/13.0/developer [9] default/linux/amd64/13.0/no-multilib [10] default/linux/amd64/13.0/x32 [11] hardened/linux/amd64 [12] hardened/linux/amd64/selinux [13] hardened/linux/amd64/no-multilib [14] hardened/linux/amd64/no-multilib/selinux [15] hardened/linux/amd64/x32 [16] hardened/linux/uclibc/amd64 So, does this mean we will eventually have systemd choices for *all*? Ie: # eselect profile list Available profile symlink targets: [1] default/linux/amd64/13.0 * [1] default/linux/amd64/13.0/systemd [2] default/linux/amd64/13.0/selinux [1] default/linux/amd64/13.0/selinux/systemd etc?
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On Mon, 17 Feb 2014 23:30:42 -0600 Canek Peláez Valdés wrote: On Mon, Feb 17, 2014 at 8:05 PM, Gevisz gev...@gmail.com wrote: [ snip ] How can you be sure if something is large enough if, as you say below, you do not care about probabilities? By writing correct code? Real world code without mistakes and larger than Hello, world! exercises is not possible. Large systems must have error suppression and correction techniques, modular and replaceable design is one of them, KISS is another one. Systemd has none known to me. I don't care about probabilities; If you do not care (= do not now anything) about probabilities (and mathematics, in general), you just unable to understand that debugging a program with 200K lines of code take 20!/(1!)^20 more time than debugging of 20 different programs with 10K lines of code. You can try to calculate that number yourself but I quite sure that if the latter can take, say, 20 days, the former can take millions of years. It is all the probability! Or, to be more precise, combinatorics. My PhD thesis (which I will defend in a few weeks) is in computer science, specifically computational geometry and combinatorics. You're not the one here on the list with PhD (either defended or near its end). And argument Listen to me! I'm PhD here! looks miserable. Please stop this. I care about facts: FACT, I've been using systemd since 2010, in several machines, and I haven't had a single segfault. Have you ever tried forex? If yes, you should have been warned that no past performance guarantee the future one. I never said that. I trust the quality of the code, measured by my own judgment and bug reports, etc. Not past performance. And even if a bug goes by, then what? The world will end? This depends on what bug at what component occurred. Just imagine pid 1 segfault on medical life support equipment. With systemd going into embedded this is not just pure speculation, though, of course medical stuff should have extra safeguards. But any FT or at least HA setup is a combination of multiple layers. I do not want to allow badly broken core component on mine setups even if its faults may be compensated by other means. Yet again, I respect ones right to use whatever one wants, but I ask to respect mine as well. That's why I propose a separate systemd profile for those willing to use it. Sorry, but it's you who doesn't know the matter at hand: kdbus was (and is) written by Greg Kroah-Hartman, Linus' right hand, and who works for the Linux Foundation. Lol, he seems to start to use the arguments like You even do not know my elder brother/acquaintance from the street nearby who can easily hit you down! If you don't think Greg's words have any weight in a Linux-related technical discussion, then I'm afraid we will need to agree to disagree on any technical subject. You know, common sense should always override person's prestige. History knows many examples. Sir Isaac Newton enforced corpuscular point of view on the light's nature. And while he was genius in other physical aspects, he was mistaken here. Albert Einstein was rejective to probabilistic nature of quantum mechanics and even proposed an entangled particles paradox as an example of its flawed nature. Though as we know these days such systems exist and are quite well used in numerous experiments. My point is simple: do not blindly adhere to someone's words, even if this person has high authority. Common sense must prevail. Period. Best regards, Andrew Savchenko pgpdeThnp3qdq.pgp Description: PGP signature
Re: [gentoo-user] systemd as a Profile - practical or not?
How to unsubscribe? 2014.02.18. 17:26 ezt írta (Tanstaafl tansta...@libertytrek.org): Hi all, Ok, before I go and open up a bug requesting this... I know there have to be a lot of people on this list who can answer this question... Is making the use of systemd or not based on a selected Profile, as opposed to manually trying to do it via USE flags etc, a practical request, or not? Meaning: 1. is it doable, 2. how hard (on a scale of 1/easy to 10/hard to impossible) would it be to do this, and 3. regardless of the difficulty in achieving it, how hard would it be (on a scale of 1 (easy) to 10 (hard to impossible)) to maintain in the long run? I'm hoping that even if the answer to #2 above is 7+, if the answer to #3 is 'relatively easy' or better, then maybe it still stands a chance of getting done. And incidentally, Canek, if I was a programmer, I'd be happy to volunteer to take it on, but alas I'm just a lowly user... Thanks...
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On Tue, Feb 18, 2014 at 10:36 AM, Andrew Savchenko birc...@gmail.com wrote: [...] Bugs are not equal. They differ in at least two dimensions: significance depending on the component affected and severity of the bug itself. I've never said that they don't have different significance, severity or scope. I said that all bugs are bugs (which is a tautology), and that you only need to fix them once to go on. Bugs in the critical system components are critical to the whole system. Yeah, that's why we have unit testing and QA teams and stable and unstable releases, etc. Every decent project has QA and unit tests one way or another. But the larger project is, the more bugs it has. And I do not want bugs in PID 1, that's why it should be small and sound, not bloated (even with some components split as separate binaries) and broken by design. Of course the larger a project is the *potential* number of bugs increases, but so what? With enough developers, users and testers, all bugs are *potentially* squashed. That's the important thing; you should not emasculate a project just to keep it simple under *your* definition of simple; have you looked at most of systemd code? It's actually pretty small and simple, and with well defined interfaces and boundaries. If Libreoffice or browser segfaults, some data may be lost and inconvenience created, but the system will continue to run. If PID 1 segfaults — everything is lost, you have a kernel panic. And the world will end? The same happens if the kernel has an error. Kernel has mature error correction infrastructure (Oops handling) and much wider community. And systemd has a *much* wider community than any other init system. So it can handle a larger code base. That's why critical components should be as simple and clean as possible. Like the kernel? You call that simple? Don't mix user space and kernel space, please. There are more secure by design micro kernels out there (like Hurd), but they're out of the scope of this discussion. I'm not mixing kernel/user space; I'm saying that critical components don't need to be simple; they need to be *reliable*. I'm sorry, but you are (IMO) wrong: critical components should be thoroughly tested and debugged, and have integrated unit testing, and a large enough group of volunteers to test new releases before they go into the general public. You're pointing to valid issues, but not to the whole picture. I just have a different point of view for the bigger picture. Critical components should _start_ from good design, sound modular architecture and _then_ with QA and testing. You're omitting the most important stuff, though. But systemd has a *good* design, a modular architecture (that's why it's splited in dozens of, you know, modules), and *besides* it has QA and testing. I'm not omitting nothing; I just don't share the same opinion as you as to what constitutes a good design. And this is debatable; with design, nothing is absolute. SysVinit code size is about 10 000 lines of code, OpenRC contains about 13 000 lines, systemd — about 200 000 lines. If you take into account the thousands of shell code that SysV and OpenRC need to fill the functionality of systemd, they use even more. If that code will fail, this wouldn't be critical at system level. Thus scope of fatal error is limited. Also in systemd, since most of its code is not critical (again; logind, datetimed, localed, etc., failing, has no impact whatsoever on the rest of the system). Even assuming systemd code is as mature as sysvinit or openrc (though I doubt this) you can calculate probabilities of segfaults yourself easily. I don't care about probabilities; I care about facts: FACT, I've been using systemd since 2010, in several machines, and I haven't had a single segfault. FACT: almost no bug report in systemd involves a segfault in PID 1. You need facts? Here is one for you (systemd-208): http://fly.osdn.org.ua/~mike/img/misc/systemd-segfault.jpg I've never said there was no segfaults; I said I had not a single one. Also, there are also segfaults for SysV, and for OpenRC, and for almost any other software out there. The important thing is the ratio of segfaults. Again, search for yourself in the case of PID 1 in systemd. And yeah, it will be larger than SysV, but SysV has, what, 40 years of existence? systemd has 4. Looks broken. Broken by design. The worst form of broken. By your opinion, not others. That is not just an opinion. There is a science and experience behind system's design. Yeah, what do you think about Greg Kroah-Hartman, Linus' right hand, or Keith Packard of X.org fame? None of them works for Red Hat; both of them know more about Unix and Linux than you and me together, and both of them promote systemd. I respect Greg for most of his work, but this doesn't mean he is an oracle we need to adhere to. But in FOSS reputation is not that important,
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On Tue, 18 Feb 2014 20:43:22 +0400 Andrew Savchenko birc...@gmail.com wrote: On Tue, 18 Feb 2014 04:05:03 +0200 Gevisz wrote: I mean, I myself know a thing or two about computing and Linux, and I promote systemd (and nobody pays me, BTW), but obviously you don't need to believe in my credentials. I have said you, he is just an unpayed fanatic systemd promoter! Frankly, I have doubts he is unpayed. Sorry, for partially incorrect statement. :-) Though as long as arguments are technical this doesn't matter. Though when arguments are down to Said who? Listen to the Oracle! it starts to. It is what I meant. Thank you for your explanations. Best regards, Andrew Savchenko
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On Tue, Feb 18, 2014 at 10:43 AM, Andrew Savchenko birc...@gmail.com wrote: On Tue, 18 Feb 2014 04:05:03 +0200 Gevisz wrote: I mean, I myself know a thing or two about computing and Linux, and I promote systemd (and nobody pays me, BTW), but obviously you don't need to believe in my credentials. I have said you, he is just an unpayed fanatic systemd promoter! Frankly, I have doubts he is unpayed. Really? You are also going to get personal. Though as long as arguments are technical this doesn't matter. Though when arguments are down to Said who? Listen to the Oracle! it starts to. I explained in my last mail why I dropped Greg and Keith names. Don't twist my words. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-user] systemd as a Profile - practical or not?
Burst out laughing reading this mail after reading this thread and the other systemd one. Anyways you'll find instructions here http://www.gentoo.org/main/en/lists.xml. On Tue, Feb 18, 2014 at 10:39 PM, Simon László wingtsun.misk...@gmail.com wrote: How to unsubscribe? 2014.02.18. 17:26 ezt írta (Tanstaafl tansta...@libertytrek.org): Hi all, Ok, before I go and open up a bug requesting this... I know there have to be a lot of people on this list who can answer this question... Is making the use of systemd or not based on a selected Profile, as opposed to manually trying to do it via USE flags etc, a practical request, or not? Meaning: 1. is it doable, 2. how hard (on a scale of 1/easy to 10/hard to impossible) would it be to do this, and 3. regardless of the difficulty in achieving it, how hard would it be (on a scale of 1 (easy) to 10 (hard to impossible)) to maintain in the long run? I'm hoping that even if the answer to #2 above is 7+, if the answer to #3 is 'relatively easy' or better, then maybe it still stands a chance of getting done. And incidentally, Canek, if I was a programmer, I'd be happy to volunteer to take it on, but alas I'm just a lowly user... Thanks...
Re: [gentoo-user] systemd as a Profile - practical or not?
On Tuesday 18 February 2014 09:54 PM, Tanstaafl wrote: Hi all, Ok, before I go and open up a bug requesting this... I know there have to be a lot of people on this list who can answer this question... Is making the use of systemd or not based on a selected Profile, as opposed to manually trying to do it via USE flags etc, a practical request, or not? Meaning: 1. is it doable, Yes. 2. how hard (on a scale of 1/easy to 10/hard to impossible) would it be to do this, and Peanuts. 3. regardless of the difficulty in achieving it, how hard would it be (on a scale of 1 (easy) to 10 (hard to impossible)) to maintain in the long run? I don't think this is difficult. I've been using gnome/systemd since 1 month I have a Gentoo server which uses systemd as well. I'm hoping that even if the answer to #2 above is 7+, if the answer to #3 is 'relatively easy' or better, then maybe it still stands a chance of getting done. And incidentally, Canek, if I was a programmer, I'd be happy to volunteer to take it on, but alas I'm just a lowly user... Thanks...
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On Tue, Feb 18, 2014 at 11:06 AM, Andrew Savchenko birc...@gmail.com wrote: On Mon, 17 Feb 2014 23:30:42 -0600 Canek Peláez Valdés wrote: On Mon, Feb 17, 2014 at 8:05 PM, Gevisz gev...@gmail.com wrote: [ snip ] How can you be sure if something is large enough if, as you say below, you do not care about probabilities? By writing correct code? Real world code without mistakes and larger than Hello, world! exercises is not possible. Large systems must have error suppression and correction techniques, modular and replaceable design is one of them, KISS is another one. Systemd has none known to me. It is modular. It is simple under the (larger) scope it tries to cover. It will have bugs (like *any* other non-trival program, as you said), obviously; but in time those bugs will be fixed and everything will be fine. I don't care about probabilities; If you do not care (= do not now anything) about probabilities (and mathematics, in general), you just unable to understand that debugging a program with 200K lines of code take 20!/(1!)^20 more time than debugging of 20 different programs with 10K lines of code. You can try to calculate that number yourself but I quite sure that if the latter can take, say, 20 days, the former can take millions of years. It is all the probability! Or, to be more precise, combinatorics. My PhD thesis (which I will defend in a few weeks) is in computer science, specifically computational geometry and combinatorics. You're not the one here on the list with PhD (either defended or near its end). And argument Listen to me! I'm PhD here! looks miserable. Please stop this. And you please stop twisting my words. I mentioned my background only because someone was trying to teach me about combinatorics (which has nothing to do with this, BTW). It was not to give any weight to any other argument. I care about facts: FACT, I've been using systemd since 2010, in several machines, and I haven't had a single segfault. Have you ever tried forex? If yes, you should have been warned that no past performance guarantee the future one. I never said that. I trust the quality of the code, measured by my own judgment and bug reports, etc. Not past performance. And even if a bug goes by, then what? The world will end? This depends on what bug at what component occurred. Just imagine pid 1 segfault on medical life support equipment. With systemd going into embedded this is not just pure speculation, though, of course medical stuff should have extra safeguards. But any FT or at least HA setup is a combination of multiple layers. I do not want to allow badly broken core component on mine setups even if its faults may be compensated by other means. There are stable releases and testing releases; you put in live-dependent code the most rock solid software you have. The one that has been thoroughly tested and used. Really, small and modular don't guarantee anything either; anyhow you need to test it and use it before putting in live-dependent systems. Yet again, I respect ones right to use whatever one wants, but I ask to respect mine as well. That's why I propose a separate systemd profile for those willing to use it. Then write. Just be aware that to write a systemd profile, you need to use systemd. Sorry, but it's you who doesn't know the matter at hand: kdbus was (and is) written by Greg Kroah-Hartman, Linus' right hand, and who works for the Linux Foundation. Lol, he seems to start to use the arguments like You even do not know my elder brother/acquaintance from the street nearby who can easily hit you down! If you don't think Greg's words have any weight in a Linux-related technical discussion, then I'm afraid we will need to agree to disagree on any technical subject. You know, common sense should always override person's prestige. History knows many examples. Sir Isaac Newton enforced corpuscular point of view on the light's nature. And while he was genius in other physical aspects, he was mistaken here. Albert Einstein was rejective to probabilistic nature of quantum mechanics and even proposed an entangled particles paradox as an example of its flawed nature. Though as we know these days such systems exist and are quite well used in numerous experiments. My point is simple: do not blindly adhere to someone's words, even if this person has high authority. Common sense must prevail. Period. I don't blindly adhere to *anyone* points. There are arguments that Greg, Lennart and Kay had made which I don't agree with. But in the big picture I'm with those guys. And so it seems the majority of the Linux world; you say it's because monetary reasons. I said it is because of the technical advantages of systemd. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
I'll try to be short. On 18.02.2014 05:09, Canek Peláez Valdés wrote: The whole point of creating new software is making things easier. Easier to use, easier to maintain, easier to remove. Well, systemd is easier to use after a little time learning how it works. And it seems to be easier to maintain that thousands of lines of spaghetti shell code. And, I'm sorry, did you just said easier to remove? Seriously? You, as a person declaring ability to code, must understand what removal/substitution of components is important for. You think the kernel is easier to remove? Or glibc? The difference is, the kernel wasn't designed to be removed, neither was glibc. I don't think the development of such projects as Debian/kFreeBSD, uClibc etc is easy. Systemd is going to be even harder to remove -- officially limiting itself to Linux kernels. How Integrated? The TCP/IP stack *is* integrated. But it is *protocol* integration, *standards* integration not *software* integration. You do want tight integration where it just can't work otherwise, but the design of Unix provides (well, again repeating this), and almost any robust design should provide, the ignorance of one abstraction level about another. Why HAL? Why udev? Why drivers as modules? Why not just go and integrate all stuff into the kernel, well (again!) like MS do, and don't please say I compare wrong things just because MS is not OSS. You make a wrong comparison, because MS is not free (libre) software. With Linux, and systemd, and OpenRC, and HAL, and devfs, and sysv, we have been able to try new technologies (and see that some of them fail, like HAL [yuck!]), because we have the source. I knew you'd say this, ignoring my warning. Will you also claim that comparing Oracle and Postgres also doesn't have sense? Or comparing Photoshop and GIMP? As you said, you can replace the whole of Linux if you so desire (and have the technical ability). You will never be able to do that with any MS software, and so the comparison makes no sense. BTW, I asked purely technically: why not integrate everything into the kernel, since we're having a working example? -- not because of its design, technical details etc, but because otherwise in short time you'll end up comparing systemd to itself. ? ...because there'll be nothing left to compare systemd to. The code is out there. You can choose to pick any point in time of the whole stack (ca. 2009, before systemd existed), and wrote from there if you have enough people willing and able to. So you eventually agree that it all converges on money. Enough people, competent enough in init systems, is quite 'enough' money. No one is taking anything from any one. No one is forcing nothing. No, no. No forcing. Just an offer you can't refuse. Free software is being written and offered, and knowledgeable people are choosing to use it in their distros. You are against that? Then wrote your own version with the same (or better) features. Heck of an argument. You don't like that stupid program on your TV? C'mon broadcast yours own. You don't like that road crossing with hundreds of traffic accidents? C'mon stand there directing traffic instead of the road police. Etc. You call the software free? Then put up with criticism and make conclusions on the feedback. If you don't or can't, don't claim it's free software. Nothing personal, Canek, I respect your POV and your eagerness to help people and make the world better that you always show in this ML. :) -- Best wishes, Yuri K. Shatroff
Re: [gentoo-user] How to properly set up Bluetooth
On Tue, Feb 18, 2014 at 10:57 AM, Ralf ralf+gen...@ramses-pyramidenbau.de wrote: Oh no... After turning of the keyboard, bluetoothd start to consume 100% CPU... I have to run systemctl restart bluetooth after unconnecting my device. Please don't top-post. That seems like a bug. What does the logs say? journalctl -b -u bluetooth.service Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-user] How to properly set up Bluetooth
Ralf ralf+gen...@ramses-pyramidenbau.de wrote: Oh no... After turning of the keyboard, bluetoothd start to consume 100% CPU... I have to run systemctl restart bluetooth after unconnecting my device. Come on... On 02/18/14 17:49, Ralf wrote: I got it working! But I can't reproduce what i did.. I played around with bluetoothctl which seems to be a interactive replacement for simple-agent. After powering my bluetooth device on and off, trusting and untrusting, pairing and unpairing for several times it now *seems* to work. It even connects automatically after turning it on :-) Bluetooth stuff is really weird Thanks! On 02/18/14 17:20, Canek Peláez Valdés wrote: On Tue, Feb 18, 2014 at 10:14 AM, Ralf ralf+gen...@ramses-pyramidenbau.de wrote: On 02/18/14 17:10, Canek Peláez Valdés wrote: systemctl status bluetooth.service Yes, sure, as I wrote above. Active: active (running) since Tue 2014-02-18 16:57:05 CET; 15min ago ps auxw|grep bluetoot root 3571 27.6 0.0 21200 2112 ?Rs 16:57 4:29 /usr/libexec/bluetooth/bluetoothd As you see everything is actually running fine... I even tried to restart it several times OK, sorry, I hadn't read carefully your first post. blueman-applet fails because it uses the 4.x dbus API from bluez. gnome-bluetooth uses the 5.x dbus API, and AFAIK, right now it's the only tool using it. So, with gnome-bluetooth you can detect your keyboard but the pairing fails? You say you paired the keyboard correctly with your android phone; you don't need to do something in the keyboard to pair it to a different hosts? Something like keep pressing the power button? Any documentation on bluetoothctl? There is no man page at all. -- Your life is like a penny. You're going to lose it. The question is: How do you spend it? John Covici cov...@ccs.covici.com
Re: [gentoo-user] systemd as a Profile - practical or not?
On Tuesday 18 February 2014 10:46 PM, Yohan Pereira wrote: Burst out laughing reading this mail after reading this thread and the other systemd one. Anyways you'll find instructions here http://www.gentoo.org/main/en/lists.xml. Don't you like jokers? ;-) No offense, but RTFM!
Re: [gentoo-user] systemd as a Profile - practical or not?
Am Dienstag 18 Februar 2014, 11:24:05 schrieb Tanstaafl: Is making the use of systemd or not based on a selected Profile, as opposed to manually trying to do it via USE flags etc, a practical request, or not? Have a look at the files in profiles/targets/systemd/ http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/profiles/targets/systemd/ That's all that is different in the systemd subprofiles. Easy to do manually. -- Andreas K. Huettel Gentoo Linux developer kde, council
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On Mon, 17 Feb 2014 18:49:47 -0600 Canek Peláez Valdés wrote: The whole deep integration approach and lack of inter-module boundaries doesn't allow one to write replaceable blocks without crazy hacking. Well, then go and show them how it's done. And please don't say that it's already done, because if that were the case, no distro would have adopted systemd. They adopted it because of the features it offers. What features? As far as I can see if we compare to openrc, the only missed feature is logind for which it is declared to be better than consolekit. I can't argue here because I never used either one. At this moment I have about 50 Gentoo boxes (in hardware) at my control including both personal and work hardware including laptops, desktops, production servers and two HPC setups (not to count hundreds of LXC containers). And I see neither reason nor need for systemd here. From what I can see, all this systemd boom started from Gnome's GDM dropping support for anything aside from systemd. Afterwards distributions started to switch to systemd one after another in order to fully support Gnome-3 setups. And now we have a little fact here: Lennart Poettering is a long time Gnome contributor. Which leads me to only one conclusion: situation we have now is a deliberate sabotage in order to acquire as much influence by RH as possible. Influence leads to a sales market expansion, which leads to a profit. So we have money here as a root cause of all this boom — a root of all evil and a root of systemd. All features and benefits are nothing more than just an excuse for the aim for market domination and more profit. Just imagine that one have PCI-E bus and this bug is being replaced with some other PC-systemd bus, where one have to interface each component differently. And if one removes e.g. audio card some other seemingly independent component e.g. network controller becomes broken. That is the nature of systemd and that is many people dislike this technology. That is a broken analogy; if logind has a bug, that doesn't affect timedated, nor udev. No, it is not. You can not remove systemd-udevd and replace it with mdev or static dev without broking most of other systemd components. The same way in my analogy you can not remove audio card without broking network controller. That said, it seems to me that, for now at least, it isn't that big a deal to switch back and forth between systemd and, for example, OpenRC. It depends; right now you can't switch back and forth between OpenRC and systemd without reemerging some stuff. Some of those packages *could* be made to switch functionality at run time instead of compile time, but SOMEONE has to write that support, and it's probably that the upstream for the package will not accept those changes, since for binary distributions it makes no sense to have the complexity on the code of switching behavior at runtime when doing at compile time is easier and the distribution generates one binary per architecture for all its users. The most sane and fair solution was already proposed: create a systemd profile for those who need it. I personally highly dislike systemd technology, but I respect the right of other to shoot them in the leg (or head) as much as they want to. This is Gentoo: a universal constructor providing people means to build any system in any shape they need. If someone willing and able provides any choice, that choice will be available. What choice? For features neither used nor needed before? Before systemd we had our choice: sysvinit, openrc, runit, epoch... By enforcing unwanted features to us systemd takes our freedom and our choice. Unfortunately chances are that in future some software may become unusable or unsupported outside of systemd profile. But patches may be created and other profiles will continue to live the same way hardened exists now and will continue to exist later. Yeah, and that's my whole point: if you want that the world outside of systemd keeps working, you need to step in. Complaining about systemd will get no one nowhere. That's the point of systemd adepts: we'll break things the way we want, fix them yourself if you dare. Behind the curtain you're just offloading your work to others or, more precisely, your time efforts to others. I don't like that. Do whatever you want to do, but please do not be intrusive into other domains and respect the freedom of choice of others. BTW it was shown at the recent LVEE Winter 2014 conference that GDM can be easily freed from systemd and OpenBSD guys have an interesting idea for faking systemd presence for applications requesting one mandatory. Though IMO any end-user application strictly dependable on any init system is broken by design: for a daemon there should be no difference by which tool it was started. GNOME depends on logind, not systemd. And no one has been willing and
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On Tue, Feb 18, 2014 at 11:24 AM, Yuri K. Shatroff yks-...@yandex.ru wrote: I'll try to be short. [ snip ] You, as a person declaring ability to code, must understand what removal/substitution of components is important for. In some cases it is; in some others it just creates a chaos, like it was the plumbing layer in Linux before systemd. You think the kernel is easier to remove? Or glibc? The difference is, the kernel wasn't designed to be removed, neither was glibc. I don't think the development of such projects as Debian/kFreeBSD, uClibc etc is easy. Systemd is going to be even harder to remove -- officially limiting itself to Linux kernels. I agree with you on this one: systemd is *not* designed to be removed. But at not point has anybody said anything about not being able to use Linux (the kernel) without systemd. That it could happen anyhow? It's possible. Don't want it to happen? Write code that doesn't needs systemd. It's really that simple. [ snip ] You make a wrong comparison, because MS is not free (libre) software. With Linux, and systemd, and OpenRC, and HAL, and devfs, and sysv, we have been able to try new technologies (and see that some of them fail, like HAL [yuck!]), because we have the source. I knew you'd say this, ignoring my warning. Will you also claim that comparing Oracle and Postgres also doesn't have sense? Or comparing Photoshop and GIMP? Well, it depends. It's totally valid to compare Linux with Windows as OSes. It's totally valid to compare Photoshop to Gimp as image editors. It's totally valid to compare Oracle and PostgreSQL as databases. It's *NOT* valid to compare Microsoft to the Linux Foundation (for the arguments I gave). It's *NOT* valid to compare Adobe to the Gimp developers. It's *NOT* valid to compare Oracle (the company) to the PostgreSQL Global Development Group. It's *NOT* valid to compare the lock-in enforced by Microsoft, to software libre being created by RedHat employers. As you said, you can replace the whole of Linux if you so desire (and have the technical ability). You will never be able to do that with any MS software, and so the comparison makes no sense. BTW, I asked purely technically: why not integrate everything into the kernel, since we're having a working example? I'm pretty sure someone crazy enough did this. But nobody in the community will want to use that code. Some years ago, someone sent a patch to the LKML to support single mode Linux (basically removing multiuser support). Nobody wanted to use that code either. On the contrary, a *lot* of people want to use systemd. I do, the GNOME project does, Debian just choose it, etc. See the difference? -- not because of its design, technical details etc, but because otherwise in short time you'll end up comparing systemd to itself. ? ...because there'll be nothing left to compare systemd to. I'm pretty sure OpenRC will never go away (and neither SysV, BTW). And if you want alternatives to systemd, *write them*. The code is out there. You can choose to pick any point in time of the whole stack (ca. 2009, before systemd existed), and wrote from there if you have enough people willing and able to. So you eventually agree that it all converges on money. Enough people, competent enough in init systems, is quite 'enough' money. No, I don't agree with your monetary reasons. Almost nobody payed for Linux development at the beginning. Nor for GNOME development, at the beginning. And, AFAIK, nobody actually pay for Gentoo development (everybody, make a donation!) If some willing and able want to, they will support anything. Being payed or not. No one is taking anything from any one. No one is forcing nothing. No, no. No forcing. Just an offer you can't refuse. You CAN refuse. It's just that no one is going to do the work for you. Free software is being written and offered, and knowledgeable people are choosing to use it in their distros. You are against that? Then wrote your own version with the same (or better) features. Heck of an argument. You don't like that stupid program on your TV? C'mon broadcast yours own. The analogy doesn't make sense; I use my Linux boxen to work, and I (personally) don't watch TV (at least from the air). You don't like that road crossing with hundreds of traffic accidents? C'mon stand there directing traffic instead of the road police. Etc. Another analogy that doesn't makes sense. I pay taxes so my government fixes the road crossing. You call the software free? Then put up with criticism and make conclusions on the feedback. If you don't or can't, don't claim it's free software. Hey, I'm here putting up with criticism and feedback for software I didn't even make! Nothing personal, Canek, I respect your POV and your eagerness to help people and make the world better that you always show in this ML. :) Thanks; the thing is, really, that in 1996 when I joined the Linux community, if someone
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On Tue, 18 Feb 2014 11:22:23 -0600 Canek Peláez Valdés wrote: Yet again, I respect ones right to use whatever one wants, but I ask to respect mine as well. That's why I propose a separate systemd profile for those willing to use it. Then write. Just be aware that to write a systemd profile, you need to use systemd. Or to create a non-systemd profile :) Best regards, Andrew Savchenko pgpKEksCQfVOx.pgp Description: PGP signature
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On Tue, Feb 18, 2014 at 12:07 PM, Andrew Savchenko birc...@gmail.com wrote: On Tue, 18 Feb 2014 11:22:23 -0600 Canek Peláez Valdés wrote: Yet again, I respect ones right to use whatever one wants, but I ask to respect mine as well. That's why I propose a separate systemd profile for those willing to use it. Then write. Just be aware that to write a systemd profile, you need to use systemd. Or to create a non-systemd profile :) That's the best response I've read in, like, many years. That's perfect; I'm 100% behind it. I even volunteer to help (with testing) to anyone going for this. You guys create a systemd-sucks-we-dont-want-it profile, and I promise to give you guys a hand. Make a profile that frees users from using systemd, and I think even several Gentoo developers will get behind that. Now we are talking; this has been my whole point the whole time. Everybody that don't want to use systemd; help this idea, and if there are enough of you, you'll pulled through. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On Tue, Feb 18, 2014 at 11:44 AM, Andrew Savchenko birc...@gmail.com wrote: On Mon, 17 Feb 2014 18:49:47 -0600 Canek Peláez Valdés wrote: The whole deep integration approach and lack of inter-module boundaries doesn't allow one to write replaceable blocks without crazy hacking. Well, then go and show them how it's done. And please don't say that it's already done, because if that were the case, no distro would have adopted systemd. They adopted it because of the features it offers. What features? As far as I can see if we compare to openrc, the only missed feature is logind for which it is declared to be better than consolekit. I can't argue here because I never used either one. Exactly. I (and many others) do *use* those features. We *want* those features. Therefore, distros want to *provide* those features, because I'm not in the minority. If you don't wnat those features that's fine, of course. At this moment I have about 50 Gentoo boxes (in hardware) at my control including both personal and work hardware including laptops, desktops, production servers and two HPC setups (not to count hundreds of LXC containers). And I see neither reason nor need for systemd here. That's fine; I think it would make your life easier, specially with the containers (check out systemd-nspawn), but nobody is forcing you to use systemd. From what I can see, all this systemd boom started from Gnome's GDM dropping support for anything aside from systemd. Afterwards distributions started to switch to systemd one after another in order to fully support Gnome-3 setups. And now we have a little fact here: Lennart Poettering is a long time Gnome contributor. Which leads me to only one conclusion: situation we have now is a deliberate sabotage in order to acquire as much influence by RH as possible. Influence leads to a sales market expansion, which leads to a profit. So we have money here as a root cause of all this boom — a root of all evil and a root of systemd. All features and benefits are nothing more than just an excuse for the aim for market domination and more profit. I've never payed RedHat a single cent. I've donated money to some Linux projects, but never to RedHat. I really don't see your point: I *want* the features systemd provides, it makes *my* life easier. Mine and of many others. That is completely orthogonal to you using (or not) or wanting (or not) systemd. Just imagine that one have PCI-E bus and this bug is being replaced with some other PC-systemd bus, where one have to interface each component differently. And if one removes e.g. audio card some other seemingly independent component e.g. network controller becomes broken. That is the nature of systemd and that is many people dislike this technology. That is a broken analogy; if logind has a bug, that doesn't affect timedated, nor udev. No, it is not. You can not remove systemd-udevd and replace it with mdev or static dev without broking most of other systemd components. The same way in my analogy you can not remove audio card without broking network controller. But you can remove logind (and systemd, in fact), and have udev working. The others are simple software dependencies. You cannot remove Gtk+ from GNOME, nor Qt from KDE. You cannot remove Linux if you want to use LXC. What's the problem with that? That said, it seems to me that, for now at least, it isn't that big a deal to switch back and forth between systemd and, for example, OpenRC. It depends; right now you can't switch back and forth between OpenRC and systemd without reemerging some stuff. Some of those packages *could* be made to switch functionality at run time instead of compile time, but SOMEONE has to write that support, and it's probably that the upstream for the package will not accept those changes, since for binary distributions it makes no sense to have the complexity on the code of switching behavior at runtime when doing at compile time is easier and the distribution generates one binary per architecture for all its users. The most sane and fair solution was already proposed: create a systemd profile for those who need it. I personally highly dislike systemd technology, but I respect the right of other to shoot them in the leg (or head) as much as they want to. This is Gentoo: a universal constructor providing people means to build any system in any shape they need. If someone willing and able provides any choice, that choice will be available. What choice? For features neither used nor needed before? *You* don't need them; *you* don't use them. Many of us do. Before systemd we had our choice: sysvinit, openrc, runit, epoch... By enforcing unwanted features to us systemd takes our freedom and our choice. Who's enforcing anything on you? Go on and roll your own Linux distribution free from the systemd virus. You will be *always* be able to do that, because the
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On 2014-02-18 1:14 PM, Canek Peláez Valdés can...@gmail.com wrote: On Tue, Feb 18, 2014 at 12:07 PM, Andrew Savchenko birc...@gmail.com wrote: On Tue, 18 Feb 2014 11:22:23 -0600 Canek Peláez Valdés wrote: Yet again, I respect ones right to use whatever one wants, but I ask to respect mine as well. That's why I propose a separate systemd profile for those willing to use it. Then write. Just be aware that to write a systemd profile, you need to use systemd. Or to create a non-systemd profile :) That's the best response I've read in, like, many years. That's perfect; I'm 100% behind it. I even volunteer to help (with testing) to anyone going for this. Canek, You've referred many times to other programs that *require* systemd. I'm curious as to the extent of these programs, and to what extent they *truly* require systemd. I can't for the life of me think of any reason that server daemons like postfix, dovecot, apache, etc would or could ever *require* systemd. I couldn't care less about gnome (don't use it, never used it, don't wanna use it), but what others are there? Also, for those that do require it, what feature of systemd (that doesn't have an alternative available) is it that the program uses? Thx
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/18/14 17:56, Gevisz wrote: On Mon, 17 Feb 2014 23:30:42 -0600 Canek Peláez Valdés can...@gmail.com wrote: On Mon, Feb 17, 2014 at 8:05 PM, Gevisz gev...@gmail.com wrote: [ snip ] How can you be sure if something is large enough if, as you say below, you do not care about probabilities? By writing correct code? No, by arguing that fixing bugs in a 200K line program is as easy as fixing a bug in 20 10K line programs. It is just not true, just the opposite. SysVinit code size is about 10 000 lines of code, OpenRC contains about 13 000 lines, systemd — about 200 000 lines. If you take into account the thousands of shell code that SysV and OpenRC need to fill the functionality of systemd, they use even more. Also, again, systemd have a lot of little binaries, many of them optional. The LOC of PID 1 is actually closer to SysV (although still bigger). Even assuming systemd code is as mature as sysvinit or openrc (though I doubt this) you can calculate probabilities of segfaults yourself easily. I don't care about probabilities; If you do not care (= do not now anything) about probabilities (and mathematics, in general), you just unable to understand that debugging a program with 200K lines of code take 20!/(1!)^20 more time than debugging of 20 different programs with 10K lines of code. You can try to calculate that number yourself but I quite sure that if the latter can take, say, 20 days, the former can take millions of years. It is all the probability! Or, to be more precise, combinatorics. My PhD thesis (which I will defend in a few weeks) is in computer science, specifically computational geometry and combinatorics. It is even more shameful for you to not understand such a simple facts from elementary probability theory (which is mostly based on combinatorics). TBH I don't understand your estimate. Where did permutations come from? are you comparing all the different combinations of lines of code? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJTA6wWAAoJEK64IL1uI2ha5nIH/iUl2VNVAabzJzRJzC29zmWg t7KwGcfrtx2D40N7n4yM4LB7VBmnyoQ6+Iroh/uk3S33S/YK/5igN8UfuhvV+lvU 85X3T3RE3oK3kURLq68bb4Ri2zLFQ8y1rQdrrUr9ABzy+F4Xfo+W4t+lLsHSQ+dY f4F7ByfJAHwh9OziFKh2/qwLj4z0Trv8AzZZhP8M29kTNWEWGyo5rGg8vRqm8Klm kHR3RvvTdV4AgYGHqxdtrO7qpB50VXZA8ihzl7lbmsBJj3pWBo1osFNWNP82yy7r s4hev5QrCpgOlEebtYi/noX8Vxx335SUirGCgjN/W9xhIwt3jfMqRes6zD+bi7A= =F5to -END PGP SIGNATURE-
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On Tue, Feb 18, 2014 at 12:31 PM, Tanstaafl tansta...@libertytrek.org wrote: On 2014-02-18 1:14 PM, Canek Peláez Valdés can...@gmail.com wrote: On Tue, Feb 18, 2014 at 12:07 PM, Andrew Savchenko birc...@gmail.com wrote: On Tue, 18 Feb 2014 11:22:23 -0600 Canek Peláez Valdés wrote: Yet again, I respect ones right to use whatever one wants, but I ask to respect mine as well. That's why I propose a separate systemd profile for those willing to use it. Then write. Just be aware that to write a systemd profile, you need to use systemd. Or to create a non-systemd profile :) That's the best response I've read in, like, many years. That's perfect; I'm 100% behind it. I even volunteer to help (with testing) to anyone going for this. Canek, You've referred many times to other programs that *require* systemd. I meant in the Gentoo context (more below). And programs depend on *features* provided by systemd, not PID 1. I don't think any program will ever require a certain PID 1, and I would call that a bug. I'm curious as to the extent of these programs, and to what extent they *truly* require systemd. I don't understand what you mean by the extent of these programs. As to what extent they *truly* require systemd, the don't require systemd the package, they require some of the features provided by it. In particular, logind it's the one being used by GNOME (and Xfce and KDE soon, optionally, as in GNOME). I can't for the life of me think of any reason that server daemons like postfix, dovecot, apache, etc would or could ever *require* systemd. Neither of those packages would ever require systemd (nor any init system). If they do, I would call that a bug. All of those programs can use features provided by systemd (like socket activation, using the more advances features of the journal, etc.), but they can be made optional. I couldn't care less about gnome (don't use it, never used it, don't wanna use it), but what others are there? Well, KDE is talking about doing basically the same as GNOME and using logind. ConsoleKit will be still supported, as is (technically) in GNOME, and I just read that CK is actually being maintained. I don't know if it's getting new features, though, and logind is. Also, for those that do require it, what feature of systemd (that doesn't have an alternative available) is it that the program uses? Again, basically logind. And there *is* ConsoleKit available as an alternative. But basically all the GNOME developers are using systemd, so the CK support is getting bitrotten. That's why the Gentoo GNOME team decided to depend on systemd, although the requirement is really logind. If *someone* creates a logind compatible replacement (it uses a simple dbus API[1]), then even the GNOME suit in Gentoo could drop the requirement for systemd. Ubuntu has been working on something like this, and Mark Shuttleworth said that they will continue to work on it, even with Ubuntu choosing systemd[2], so if/when that's available, there will be no program that *requires* systemd, AFAIK. (Well, gnome-logs depends on the journal, but it's a GUI for a systemd specific feature). Like I've been saying; no one is forcing nothing on no one. But someone has to write/support/maintain the alternative. Regards. [1] http://www.freedesktop.org/wiki/Software/systemd/logind/ [2] http://www.markshuttleworth.com/archives/1316 -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On 2014-02-18 1:54 PM, Canek Peláez Valdés can...@gmail.com wrote: On Tue, Feb 18, 2014 at 12:31 PM, Tanstaafl tansta...@libertytrek.org wrote: I'm curious as to the extent of these programs, and to what extent they *truly* require systemd. I don't understand what you mean by the extent of these programs. Sorry, worded that badly... I meant, basically, how many programs now require systemd... I can't for the life of me think of any reason that server daemons like postfix, dovecot, apache, etc would or could ever *require* systemd. Neither of those packages would ever require systemd (nor any init system). If they do, I would call that a bug. Then why should XFCE requiring it also not be a bug? I totally get XFCE *supporting* the use of logind, but why should it ever support *only* logind? That would seem insane to me. All of those programs can use features provided by systemd (like socket activation, OpenRC will supposedly soon support the use of sockets... using the more advances features of the journal, etc.), but they can be made optional. Exactly... it is the question of *requiring* it, or *only* supporting it, that doesn't make sense to me. Also, for those that do require it, what feature of systemd (that doesn't have an alternative available) is it that the program uses? Again, basically logind. And there *is* ConsoleKit available as an alternative. Ok, so the numerous times you and others have made comments about the 'many new features' of systemd, you only really meant logind? But basically all the GNOME developers are using systemd, so the CK support is getting bitrotten. That's why the Gentoo GNOME team decided to depend on systemd, although the requirement is really logind. If *someone* creates a logind compatible replacement (it uses a simple dbus API[1]), then even the GNOME suit in Gentoo could drop the requirement for systemd. Ubuntu has been working on something like this, and Mark Shuttleworth said that they will continue to work on it, even with Ubuntu choosing systemd[2], so if/when that's available, there will be no program that *requires* systemd, AFAIK. (Well, gnome-logs depends on the journal, but it's a GUI for a systemd specific feature). Like I've been saying; no one is forcing nothing on no one. But someone has to write/support/maintain the alternative. Excellent... so apparently, the only real new features that have any kind of dependency are logind and maybe journald, so all that would be needed are compatible replacements, and all of the noise about systemd consuming the world has been just that... noise?
Re: [gentoo-user] Re: Debian just voted in systemd for default init system in jessie
On Tue, Feb 18 2014, Canek Peláez Valdés wrote: On Tue, Feb 18, 2014 at 2:19 AM, Nicolas Sebrecht nsebre...@piing.fr wrote: The 17/02/14, Canek Peláez Valdés wrote: It depends; right now you can't switch back and forth between OpenRC and systemd without reemerging some stuff. Interesting. Didn't know that. What packages need to be recompiled? Some packages need to be emerged with USE=-systemd when going from systemd to OpenRC, and with USE=systemd the other way around. Different code paths are selected in each case. I think the consolekit USE flag also has to be changed. Systemd: USE=+systemd -consolkit OpenRC: USE=-systemd +consolkit At least that is what I did when I switched OpenRC--Systemd (with Canek's help). Now I have no global USE flags, thanks to the systemd subprofile. newlap-wireless gottlieb # eselect profile show Current /etc/portage/make.profile symlink: default/linux/amd64/13.0/desktop/gnome/systemd newlap-wireless gottlieb # allan
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On Tue, 18 Feb 2014 22:07:12 +0400, Andrew Savchenko wrote: Then write. Just be aware that to write a systemd profile, you need to use systemd. Or to create a non-systemd profile :) We already have many of those, because systemd is not the default. Part of making it the default, if that decision is ever taken, would be to modify the current profiles to support systemd, at which point the old versions would become the non-systemd profiles. Yes, it does take systemd users/devs to create a systemd profile, but they are the one that will want to use it anyway. The rest already have what they want. This is the way things have moved with the GNOME and KDE profiles, expect others to follow suit. I'm still uncomfortable with the pervasiveness of systemd, although Canek does put forward persuasive arguments, through a mixture of expertise and remaining calm. So GNOME want to use logind, which may well be superior to ConsoleKit, but why should that require a change of init system? A login daemon should be started by the init system, not be an integral part of it. What happens when logind no longer fulfils developers needs, as is the case with ConsoleKit now, how can it be replaced with an improved service when it is so closely tied to the init system. -- Neil Bothwick Windows '96 artificial intelligence: Unable to FORMAT A: Having a go at C: signature.asc Description: PGP signature
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On Tue, Feb 18, 2014 at 1:09 PM, Tanstaafl tansta...@libertytrek.org wrote: On 2014-02-18 1:54 PM, Canek Peláez Valdés can...@gmail.com wrote: On Tue, Feb 18, 2014 at 12:31 PM, Tanstaafl tansta...@libertytrek.org wrote: I'm curious as to the extent of these programs, and to what extent they *truly* require systemd. I don't understand what you mean by the extent of these programs. Sorry, worded that badly... I meant, basically, how many programs now require systemd... The packages requiring loingd. I can't for the life of me think of any reason that server daemons like postfix, dovecot, apache, etc would or could ever *require* systemd. Neither of those packages would ever require systemd (nor any init system). If they do, I would call that a bug. Then why should XFCE requiring it also not be a bug? If XFCE requires systemd the *init system*, I agree it's a bug. I totally get XFCE *supporting* the use of logind, but why should it ever support *only* logind? That would seem insane to me. If someone writes the support for non-logind systems (like the *BSDs), everything is dandy and you and I are happy as clams. All of those programs can use features provided by systemd (like socket activation, OpenRC will supposedly soon support the use of sockets... I suppose it will be different; but probably it can be made to work for both. Again, if *someone* writes the support for each. using the more advances features of the journal, etc.), but they can be made optional. Exactly... it is the question of *requiring* it, or *only* supporting it, that doesn't make sense to me. If the project supports both no one will complain. The thing is that there will be projects that will only actively support logind, because it works so much better than ConsoleKit. That's the case with GNOME. If someone writes the famous logind replacement, again, everybody is happy as a clam. Also, for those that do require it, what feature of systemd (that doesn't have an alternative available) is it that the program uses? Again, basically logind. And there *is* ConsoleKit available as an alternative. Ok, so the numerous times you and others have made comments about the 'many new features' of systemd, you only really meant logind? No, we meant logind, the journal, hostnamed, timedated, the socket activation, the new networking tool that will arrive with 209, and all the features to handle and monitor services. By the way, both GNOME and KDE (and I'm sure Xfce, eventually) are planning on using systemd --user to handle the desktop session. The normal session handling will keep working in both desktops, but (and this is just an educated guess from my part) I think it will happen the same as with logind: the new way to do things will work so much better, and the other way will bitrot. Unless *someone* gives time and code to maintain it. But basically all the GNOME developers are using systemd, so the CK support is getting bitrotten. That's why the Gentoo GNOME team decided to depend on systemd, although the requirement is really logind. If *someone* creates a logind compatible replacement (it uses a simple dbus API[1]), then even the GNOME suit in Gentoo could drop the requirement for systemd. Ubuntu has been working on something like this, and Mark Shuttleworth said that they will continue to work on it, even with Ubuntu choosing systemd[2], so if/when that's available, there will be no program that *requires* systemd, AFAIK. (Well, gnome-logs depends on the journal, but it's a GUI for a systemd specific feature). Like I've been saying; no one is forcing nothing on no one. But someone has to write/support/maintain the alternative. Excellent... so apparently, the only real new features that have any kind of dependency are logind and maybe journald, systemd --user will be used at lest by GNOME and KDE. so all that would be needed are compatible replacements, Exactly. If someone is willing and able to write and support those replacements, your non-systemd world doesn't needs to change. and all of the noise about systemd consuming the world has been just that... noise? That's been my *whole* point. Nobody is forcing nothing on no one. Now, from the point of view of a distribution, they can decide that the supported init system is only systemd. That's their choice. That's what Fedora, OpenSUSE and Arch did. Debian will set systemd as *default* init, but it will keep (I suppose) supporting multiple init systems. They need to, since the non-Linux ports will never get systemd support. I'm pretty sure Ubuntu will switch at some point to only support systemd. I think Gentoo will be like Debian; we will support multiple init systems basically forever (and Gentoo also works in FreeBSD). It's possible the council will decide to make systemd the default init system... in twenty or forty years. So no, the sky isn't falling, and the systemd virus is not spreading to touch everything
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On Tue, Feb 18, 2014 at 1:32 PM, Neil Bothwick n...@digimed.co.uk wrote: On Tue, 18 Feb 2014 22:07:12 +0400, Andrew Savchenko wrote: Then write. Just be aware that to write a systemd profile, you need to use systemd. Or to create a non-systemd profile :) We already have many of those, because systemd is not the default. Part of making it the default, if that decision is ever taken, would be to modify the current profiles to support systemd, at which point the old versions would become the non-systemd profiles. Yes, it does take systemd users/devs to create a systemd profile, but they are the one that will want to use it anyway. The rest already have what they want. This is the way things have moved with the GNOME and KDE profiles, expect others to follow suit. After seeing Andreas K. Huettel response in the other thread[1], I think it's fine even with a systemd profile. It just sets the systemd USE flags, mask genkernel (and dracut is so much better, IMO), mask some USE flags (static-flags for udev, cryptsetup, and lvm2; static for dmraid; and consolekit in general). It's really simple; putting that on a profile or doing by hand (which I do in my no-GNOME servers) is the same to me. I'm still uncomfortable with the pervasiveness of systemd, although Canek does put forward persuasive arguments, through a mixture of expertise and remaining calm. Thanks Neil. So GNOME want to use logind, which may well be superior to ConsoleKit, but why should that require a change of init system? Well, the logind dbus interface is available for anyone to implement independently from systemd[2]. Ubuntu is trying to do that. It's just that the systemd developers saw that using the features of systemd, doing user session management was really easy, and they did. Those systemd features are not gratuitous; that's why Ubuntu is having trouble doing an independent replacement. A login daemon should be started by the init system, not be an integral part of it. What happens when logind no longer fulfils developers needs, as is the case with ConsoleKit now, how can it be replaced with an improved service when it is so closely tied to the init system. Well, if that happens then they will use the support for the improved service and logind will die like HAL or devfs. The thing is that logind exists now, it solves real problems, and people are using it because of that. If someone else writes something better, I'm sure they will use that instead. I don't see the point on worrying about what could happen when dozens of technologies have already been tried in Linux; some strive, and some die. Apparently, Upstart will die; it was a waste then when RedHat choose it for RHEL 6 (or 5, I don't know, never used it), or that Ubuntu used it? No, lessons were learned from it. And from devfs, and OSS, and HAL. That's how free software evolves. It only needs people willing and able to write and maintain new cool software. Regards. [1] http://article.gmane.org/gmane.linux.gentoo.user/272668 [2] http://www.freedesktop.org/wiki/Software/systemd/logind/ -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On 16.02.2014 21:56, Volker Armin Hemmann wrote: Hello List. and all are linked (not compilelink) in such a manner that you can't just pick and choose. Oh no, you get the full treatment if you like it or not. A few weeks ago I wanted to see what systemd is really like so I started a little test and switched to systemd on my private gentoo desktop system. I don't care what people say, if possible only my personal experience matters. First I thought that with systemd I have to use all the things shipped with systemd like journald (which I don't like because I think that a binary file for syslogs is just broken) so I looked into the config files of systemd, deactivated journald and configured logging to rsyslog instead. And just like journald many (if not most or even all, I'm still at the surface of systemd configuration) of the new and ugly tools can be replaced by the good old tools we like and love. Out of experience I can now say that many of the point said against systemd a just not true. Please everyone, make use of a rainy winter evening, install a virtual maschine with an systemd distribution and look into its options, configurations and workings. Just for the sake of getting rid of all the little wrong statements and rumors. Then we can concentrate on the real issues and problems of systemd. Greetings Sebastian Beßler
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On Feb 18, 2014 3:05 PM, Sebastian Beßler sebast...@darkmetatron.de wrote: On 16.02.2014 21:56, Volker Armin Hemmann wrote: Hello List. and all are linked (not compilelink) in such a manner that you can't just pick and choose. Oh no, you get the full treatment if you like it or not. A few weeks ago I wanted to see what systemd is really like so I started a little test and switched to systemd on my private gentoo desktop system. I don't care what people say, if possible only my personal experience matters. First I thought that with systemd I have to use all the things shipped with systemd like journald (which I don't like because I think that a binary file for syslogs is just broken) so I looked into the config files of systemd, deactivated journald and configured logging to rsyslog instead. In the spirit of correctness, I should mention that you don't disable the journal; you can configure it so it doesn't stores its binary logs, but it's still running. And you always can run other legacy logger alongside the journal, and have both things; binary logs for fast retrieval, and text logs if you so desire. And just like journald many (if not most or even all, I'm still at the surface of systemd configuration) of the new and ugly tools can be replaced by the good old tools we like and love. Out of experience I can now say that many of the point said against systemd a just not true. Please everyone, make use of a rainy winter evening, install a virtual maschine with an systemd distribution and look into its options, configurations and workings. Just for the sake of getting rid of all the little wrong statements and rumors. Then we can concentrate on the real issues and problems of systemd. Regards.
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
Am Dienstag, 18.02.2014 um 14:09 schrieb Tanstaafl tansta...@libertytrek.org: I can't for the life of me think of any reason that server daemons like postfix, dovecot, apache, etc would or could ever *require* systemd. Neither of those packages would ever require systemd (nor any init system). If they do, I would call that a bug. Then why should XFCE requiring it also not be a bug? I totally get XFCE *supporting* the use of logind, but why should it ever support *only* logind? That would seem insane to me. I'm not sure if I understand you correctly but I'm using XFCE, thunar and nautilus without systemd and everything is working fine.
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On 18/02/2014 23:32, Canek Peláez Valdés wrote: And you always can run other legacy logger alongside the journal, and have both things; binary logs for fast retrieval, and text logs if you so desire. Please do not use that phrase legacy in this context. Classic syslogging is not legacy. It is current. The systemd method is not the new thing that replaces and deprecates the old thing, it is merely a new (and unproven) kid on the block. Legacy in the context of logging can only really mean the old syslogger protocol as implemented by syslogd. It has no standard behind it and is correctly described as whatever syslogd does, whereas there is a new syslogging protocol, with an RFC. This is most certainly not a legacy standard. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On 18/02/2014 13:54, Mark David Dumlao wrote: Shouldn't sysadmins use the init-scripts for that? If done correctly, permissions should not be an issue. Restarting services without keeping file ownership into account will always cause issues. Regardless of the init-system used. That's just the thing though. As a sysadmin, how do you debug a service that isn't starting to begin with? Let's say your new to the service. You're not even sure if you got the config right the first time around. Or maybe you're adjusting a setting somewhere, and you're confused why it isn't taking effect. All the /upstream documentation/, all the /man pages/, all the /usr/share/doc stuff will tell you to start it _raw_. The init script obscures the starting options, environment variables, and sometimes even the running user from you. What are you gonna do, play a human shell script parser? Nobody's perfect, do it enough times and you're going to casually gloss over the line where --safe-mode is appended to the string depending on the phase of the moon... I do all of that, I've been around long enough to have learned. Like yourself. ps and tailing a daemon's log file is my standard approach to really verify that a daemon is running. The other side of the coin is I usually start with the distro's init scripts and assume for argument sake they work. When the facts prove that wrong, I dig deeper. The list of daemons I use that are not well behaved wrt init scripts are rather short in reality If you're lucky, you've never had to start an unfamiliar service, or debug someone else's unfamiliar config under time pressure... Nope, not so lucky. Not even close. We're getting OT, but by far the worst behaved daemons out there are non-OSS paid-for things for a corproate market. Like Ossec. Oracle databases. Sybase. Anything and everythign that purports to do backups. I shan't mention Oracle's various offerings for business use for fear my brain shall explode. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On 18/02/2014 14:16, J. Roeleveld wrote: On Tue, February 18, 2014 12:17, Alan McKinnon wrote: On 18/02/2014 11:52, J. Roeleveld wrote: On Tue, February 18, 2014 10:47, Alan McKinnon wrote: What I do run into is daemons that drop privs on start up, like tac_plus. Unwary new sysadmins always try start/stop it as root, causing an unholy mess. Root the owns the log and pid files, when tac_plus drops privs it can't record it's state so continues to service requests but fails to log any of them. For an auth daemon, that's a serious issue. Shouldn't sysadmins use the init-scripts for that? If done correctly, permissions should not be an issue. It's a little more complex than just that. It's an auth service and user are frequently added, removed and modified. The daemon does syntax checking on it's config file at startup or after being HUP'ed but that only finds static errors. It catches things like adding people to a grop instead of to a group, but misses dynamic mistakes like adding users to groups that don't exist. The auth-service gets the current state from a static file that is only read upon service-start? Yes. It's a good design for reasonably static userbases. The user details, priviledge definitions, passwords hashes and such are stored in a single flat file readable only by root and protected by file permissions. Overall protection is provided by restricted shell access to the host. We're not talking about ATT's radius servers for dsl users here who sign up on a web form - for that you would use a database backend - this is for the company's network support personnel who log into the backbone and configure the network itself. There's no rush to add new (and unproven...) users so this scheme suits me just fine. Yes, it has quirks but these no longer bother me myself, we get caught out by new sysadmins who have not felt that pain yet It's exactly analogous to compile-time vs runtime errors, compilers can't catch the latter. Despite this all being run out of cron with wrapper scripts to check validity, automated additions and safety checks between all three daemons, plus being fully documented on the internal wiki and in bold blinking red caps in the login motd, people still find ways to do stuff things in an attempt to fix it. (OT: Does the bold blinking red caps work on all terminals? :) ) Um, OK, you got me there. I was exaggerating! The daemon also tries to log these errors, by writing to a log file it has no write permissions on. setuid on the group with group-write in the umask not an option? Hmmm, that's worth investigating. I hadn't really considered that as I have an aversion to trying to use umask as a control for anything. There is nothing I can do about the quality of sysadmins, I have no input into the HR process and damagement think cheaper is always better, including skills. What I can do, is find ways to make the software more resistant to errors than it already is. And only grant access permissions to these rookies once they have proven they understand rule #1: If In Doubt, Call Someone Who Knows! Hah! I fought that good fight for years and fought it well. They don't call me the sysadmin from hell around here without good reason. And I did manage to get a cowboy network under control and instill respect for how much breakage Cisco's products can cause. It's getting harder to grant access based purely on expertise, especially when someone crunched the numbers. It turns out that the cost of fixing mistakes is far less than the cost of leaving new untrained people unutilized and have support tickets pile up... But yes, I fully understand the methods of HR and Damagement. It is a financial mistake and risk not to include technical expertise checks in the recruitement fase for technical positions. Interesting story: I once had a good shouting match with a support manager about the quality of his recruits. I demanded to know why he hired so many clueless idiots (my exact words). This manager knows me well so he just smiled and said Alan, you didn't get to see the applicants we rejected. These are the best in the market who applied. *That* was a wake-up call of note :-) How much does it cost the company each time this goes wrong and someone like you has to come online to fix the issue? That is what Damagement needs to understand. Surprisingly, it's not too expensive. There's always one of us on duty or standby and outages don't continue unnoticed for long. Longest that I recall is 3 minutes, then the phone starts ringing non-stop. remember, this system is internal, it does not service customers. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] systemd as a Profile - practical or not?
On 18/02/2014 18:24, Tanstaafl wrote: Hi all, Ok, before I go and open up a bug requesting this... I know there have to be a lot of people on this list who can answer this question... Is making the use of systemd or not based on a selected Profile, as opposed to manually trying to do it via USE flags etc, a practical request, or not? Meaning: 1. is it doable, 2. how hard (on a scale of 1/easy to 10/hard to impossible) would it be to do this, and 3. regardless of the difficulty in achieving it, how hard would it be (on a scale of 1 (easy) to 10 (hard to impossible)) to maintain in the long run? I'm hoping that even if the answer to #2 above is 7+, if the answer to #3 is 'relatively easy' or better, then maybe it still stands a chance of getting done. And incidentally, Canek, if I was a programmer, I'd be happy to volunteer to take it on, but alas I'm just a lowly user... Didn't we discuss this very question a few months back? (it might have been on -dev though) I recall a distinct sticking point being the immediate doubling of number of profiles - you'd need as many as there are no, doubled. 1 for a systemd version, 1 for a non-systemd version -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On Tue, Feb 18, 2014 at 4:35 PM, Alan McKinnon alan.mckin...@gmail.com wrote: On 18/02/2014 23:32, Canek Peláez Valdés wrote: And you always can run other legacy logger alongside the journal, and have both things; binary logs for fast retrieval, and text logs if you so desire. Please do not use that phrase legacy in this context. I apologize. I did not intended to use legacy as a pejorative term. I use rsyslog myself in some servers. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-user] LDAP server questions
On Feb 18, 2014 1:13 PM, J. Roeleveld jo...@antarean.org wrote: On 18 February 2014 06:03:02 CET, Pandu Poluan pa...@poluan.info wrote: Hello list! I'm planning to replace an Active Directory server currently functioning *only* as an LDAP server, with a dedicated Linux-based LDAP server. Now, the function of the LDAP server is at the moment: * Provide the settings database for Axigen email server * Provide group membership for BlueCoat proxy (who allowed to access what) * Provide group membership for FreeRADIUS * Provide group membership for Fortinet VPN The day-to-day management will be handled be another division, and I'm quite sure that they prefer a GUI, so the solution really should have a GUI support (either Windows-based 'client' or web-based admin console). Apparently, there are now many implementations of LDAP in the *nix world, such as OpenLDAP, OpenDS, ApacheDS, and 389DS. Have any of you experiences with them? Which one do you think is the most mature and supported? And, quite importantly, which one has a GUI front-end? Rgds, -- Openldap has a webbased gui: phpldapadmin. Both are in the tree. I use this myself for all the user accounts. Allowing me to only maintain a single repository for all the services and desktops. Not been able to get ms windows to authenticate against it though. But that requires further tools to be properly configured. (Think samba as a DC) Interesting... thanks for the heads up! MS Windows authentication is not necessary, since this AD server is not used for that purpose... Rgds, --
Re: [gentoo-user] LDAP server questions
On 19 February 2014 05:11:12 CET, Pandu Poluan pa...@poluan.info wrote: On Feb 18, 2014 1:13 PM, J. Roeleveld jo...@antarean.org wrote: On 18 February 2014 06:03:02 CET, Pandu Poluan pa...@poluan.info wrote: Hello list! I'm planning to replace an Active Directory server currently functioning *only* as an LDAP server, with a dedicated Linux-based LDAP server. Now, the function of the LDAP server is at the moment: * Provide the settings database for Axigen email server * Provide group membership for BlueCoat proxy (who allowed to access what) * Provide group membership for FreeRADIUS * Provide group membership for Fortinet VPN The day-to-day management will be handled be another division, and I'm quite sure that they prefer a GUI, so the solution really should have a GUI support (either Windows-based 'client' or web-based admin console). Apparently, there are now many implementations of LDAP in the *nix world, such as OpenLDAP, OpenDS, ApacheDS, and 389DS. Have any of you experiences with them? Which one do you think is the most mature and supported? And, quite importantly, which one has a GUI front-end? Rgds, -- Openldap has a webbased gui: phpldapadmin. Both are in the tree. I use this myself for all the user accounts. Allowing me to only maintain a single repository for all the services and desktops. Not been able to get ms windows to authenticate against it though. But that requires further tools to be properly configured. (Think samba as a DC) Interesting... thanks for the heads up! MS Windows authentication is not necessary, since this AD server is not used for that purpose... Rgds, -- If MS Windows is not necessary, then I can help with the config. I got the following authenticating succesfully: Linux accounts (PAM) Apache Egroupware OpenKM Samba Squirrelmail and gallery authenticate against Apache For these I can help you with the necessary config. For others we'll need to see what to configure where. And backups are really easy with no downtime. (Export to LDIF) -- Joost -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On 02/18/2014 12:14 PM, Canek Peláez Valdés wrote: On Tue, Feb 18, 2014 at 12:07 PM, Andrew Savchenko birc...@gmail.com wrote: On Tue, 18 Feb 2014 11:22:23 -0600 Canek Peláez Valdés wrote: Yet again, I respect ones right to use whatever one wants, but I ask to respect mine as well. That's why I propose a separate systemd profile for those willing to use it. Then write. Just be aware that to write a systemd profile, you need to use systemd. Or to create a non-systemd profile :) That's the best response I've read in, like, many years. That's perfect; I'm 100% behind it. I even volunteer to help (with testing) to anyone going for this. You guys create a systemd-sucks-we-dont-want-it profile, and I promise to give you guys a hand. Make a profile that frees users from using systemd, and I think even several Gentoo developers will get behind that. Now we are talking; this has been my whole point the whole time. Everybody that don't want to use systemd; help this idea, and if there are enough of you, you'll pulled through. Regards. For such a profile to be legitimate, systemd would have to be chosen as the default. Gentoo is one of the last bastions of choice available to GNU/Linux users and it would create a complete shitstorm if systemd were pushed on Gentoo's users. You're just trying to push systemd on one of the few distros that doesn't use it by default. Do you hang out with John Paul Adrian Glaubitz? He's a Debian developer who has a long-running history of pushing systemd as well. There is nothing wrong with systemd as a choice, but to push it as the default is ridiculous. systemd can have its own profile while the rest of the world goes on without it. Everybody wins. For all this talk about technical details, nobody seems to notice the marketing that's going on and frankly it disgusts me.
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On Wed, February 19, 2014 00:06, Alan McKinnon wrote: On 18/02/2014 14:16, J. Roeleveld wrote: On Tue, February 18, 2014 12:17, Alan McKinnon wrote: It's a little more complex than just that. It's an auth service and user are frequently added, removed and modified. The daemon does syntax checking on it's config file at startup or after being HUP'ed but that only finds static errors. It catches things like adding people to a grop instead of to a group, but misses dynamic mistakes like adding users to groups that don't exist. The auth-service gets the current state from a static file that is only read upon service-start? Yes. It's a good design for reasonably static userbases. The user details, priviledge definitions, passwords hashes and such are stored in a single flat file readable only by root and protected by file permissions. Overall protection is provided by restricted shell access to the host. True, then again, I use ldap for the user accounts at home. Allows my wife to change her own password and I can quickly add an account in case someone needs access. We're not talking about ATT's radius servers for dsl users here who sign up on a web form - for that you would use a database backend - this is for the company's network support personnel who log into the backbone and configure the network itself. There's no rush to add new (and unproven...) users so this scheme suits me just fine. Yes, it has quirks but these no longer bother me myself, we get caught out by new sysadmins who have not felt that pain yet Show them a blood-stained (ok, some dark red paint) stick when they start. Then tell them it's used when they kill that service? ;) Despite this all being run out of cron with wrapper scripts to check validity, automated additions and safety checks between all three daemons, plus being fully documented on the internal wiki and in bold blinking red caps in the login motd, people still find ways to do stuff things in an attempt to fix it. (OT: Does the bold blinking red caps work on all terminals? :) ) Um, OK, you got me there. I was exaggerating! Too bad, I could use that on one of my machines :) The daemon also tries to log these errors, by writing to a log file it has no write permissions on. setuid on the group with group-write in the umask not an option? Hmmm, that's worth investigating. I hadn't really considered that as I have an aversion to trying to use umask as a control for anything. Same here, but that could work. Then again, I believe setuid on the folder does the same on some OSs. (Not Linux though) There is nothing I can do about the quality of sysadmins, I have no input into the HR process and damagement think cheaper is always better, including skills. What I can do, is find ways to make the software more resistant to errors than it already is. And only grant access permissions to these rookies once they have proven they understand rule #1: If In Doubt, Call Someone Who Knows! Hah! I fought that good fight for years and fought it well. They don't call me the sysadmin from hell around here without good reason. And I did manage to get a cowboy network under control and instill respect for how much breakage Cisco's products can cause. It's getting harder to grant access based purely on expertise, especially when someone crunched the numbers. It turns out that the cost of fixing mistakes is far less than the cost of leaving new untrained people unutilized and have support tickets pile up... True, unfortunately... Then again, a core of really good people can be the better option. But then you end up becoming overly dependent on that group. But yes, I fully understand the methods of HR and Damagement. It is a financial mistake and risk not to include technical expertise checks in the recruitement fase for technical positions. Interesting story: I once had a good shouting match with a support manager about the quality of his recruits. I demanded to know why he hired so many clueless idiots (my exact words). This manager knows me well so he just smiled and said Alan, you didn't get to see the applicants we rejected. These are the best in the market who applied. *That* was a wake-up call of note :-) Either done during the boom of IT, or wrong recruitment tactics. How much does it cost the company each time this goes wrong and someone like you has to come online to fix the issue? That is what Damagement needs to understand. Surprisingly, it's not too expensive. There's always one of us on duty or standby and outages don't continue unnoticed for long. Longest that I recall is 3 minutes, then the phone starts ringing non-stop. remember, this system is internal, it does not service customers. 3 minutes downtime is acceptable, even for customers. They generally first assume they are making a mistake ;) -- Joost
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On Wed, Feb 19, 2014 at 1:04 AM, Daniel Campbell li...@sporkbox.us wrote: On 02/18/2014 12:14 PM, Canek Peláez Valdés wrote: On Tue, Feb 18, 2014 at 12:07 PM, Andrew Savchenko birc...@gmail.com wrote: On Tue, 18 Feb 2014 11:22:23 -0600 Canek Peláez Valdés wrote: Yet again, I respect ones right to use whatever one wants, but I ask to respect mine as well. That's why I propose a separate systemd profile for those willing to use it. Then write. Just be aware that to write a systemd profile, you need to use systemd. Or to create a non-systemd profile :) That's the best response I've read in, like, many years. That's perfect; I'm 100% behind it. I even volunteer to help (with testing) to anyone going for this. You guys create a systemd-sucks-we-dont-want-it profile, and I promise to give you guys a hand. Make a profile that frees users from using systemd, and I think even several Gentoo developers will get behind that. Now we are talking; this has been my whole point the whole time. Everybody that don't want to use systemd; help this idea, and if there are enough of you, you'll pulled through. Regards. For such a profile to be legitimate, systemd would have to be chosen as the default. Gentoo is one of the last bastions of choice available to GNU/Linux users and it would create a complete shitstorm if systemd were pushed on Gentoo's users. You're just trying to push systemd on one of the few distros that doesn't use it by default. Do you hang out with John Paul Adrian Glaubitz? He's a Debian developer who has a long-running history of pushing systemd as well. There is nothing wrong with systemd as a choice, but to push it as the default is ridiculous. systemd can have its own profile while the rest of the world goes on without it. Everybody wins. For the record, and being completely honest (I've always been), at some point, yeah, I would like for the devs to discuss the idea of systemd as default init system. It does not depends on me though; the devs (and the council they elect) will take such decision, and the discussion (if it happens) will be in a long, long time. But my (previous) push for a systemd-sucks profile was because I sincerely believe that the burden of work should be on the ones proposing *any* profile, and to support a systemd profile you *need* to use systemd, and then it makes no sense that the people that *don't want* systemd need to do the work for a systemd profile. However, after Andreas K. Huettel pointed out (in [1]) how simple and minimal a systemd profile actually is[2], I changed my mind. I now wholeheartedly support a systemd profile, since is so small, that the burden of work is basically negligible, and apparently the same GNOME/systemd Gentoo developers are already doing it. So, I think, everybody agrees now. Lets have a systemd profile. (I mean, the work to have it apparently it's already done, so it does not matter what I, or anyone here, argues about it). For all this talk about technical details, nobody seems to notice the marketing that's going on and frankly it disgusts me. There is no marketing; no one is selling nothing. We are just discussing different technologies and their merits (or demerits), according to what each one of us knows/believe. It's interesting, it's fun, we learn things (I learned about the systemd profile in existence) and it changes absolutely nothing about Linux, Gentoo, or the status of systemd anywhere. To change Linux, Gentoo, or the status of systemd somewhere, people need to contribute code, testing or documentation, not post arguments in mailing lists. But again, it's fun (except for a couple of trolls), so no harm is done. Regards. [1] http://article.gmane.org/gmane.linux.gentoo.user/272668 [2] http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/profiles/targets/systemd/ -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
