Re: [gentoo-user] Re: Fwd:How about the gentoo server or cluster in production environment?
On Thu, 20 Feb 2014 22:59:59 +0200 Alan McKinnon wrote: On 20/02/2014 22:41, Nicolas Sebrecht wrote: On Thu, Feb 20, 2014 at 08:52:07PM +0400, Andrew Savchenko wrote: And this point is one of the highest security benefits in real world: one have non-standard binaries, not available in the wild. Most exploits will fail on such binaries even if vulnerability is still there. While excluding few security issues by compiling less code is possible, believing that non-standard binaries (in the sense of compiled for with local compilation flags) gives more security is a dangerous dream. +1 non-standard binaries is really just a special form of security by obscurity. Or alternatively a special form of no-one will eva figure out my l33t skillz! Mwahahaha! Exactly. This is security trough obscurity. I never claimed this is an ultimate or a sufficient way to protect a system. But this is just a single of many multiple layers which can be used to provide acceptable security level. Which is a very poor stance to take. The total amount of code not compiled by setting some USE flags off is on the whole not likely to be very much, and hoping with finger crossed that the next weakness in a package will just happen to fall within a code path that got left out by USE flags is a fools dream. You mare compare binary sizes for e.g. openldap (and all its libraries) with minimal and full (USE=-minimal *) setup. Quite impressive, not to count all external so libraries involved. I'm glad you mentioned this Andrew, because the internets are full of stupid advice like this non-standard binary nonsense. Are you considering Bruce Schneier's advice as a stupid nonsense? In his Applied cryptography he recommended one of the ways to straighten a system: to use not so frequently used algorithms instead of selected standards because less frequently used algorithms has no better math but are less targeted, have less specialized hardware built to crack them and so on. Yes, the arguments at face value are difficult to refute with hard facts, but those that do not known it is stupid are easily led into a sense of false security, doesn't matter how many disclaimers are tagged on the end. I reckon it's the duty of all knowledgeable sysadmins to stamp out this crap HARD every time it raises it's head. To the user who brought it up - this might seem overly harsh but I've yet to find a better method that actually works and gets through to people. I never talked about a sense of security just because system has non-standard binaries. I talked about high variance which brings a _bit_ more security. And I'm talking not from some theorizing, but from practical experience on both ends (data protection and legitimate system forensics). Have you ever considered how systems became broken in the wild? The most common way (in numbers of hosts, not significance) are automated robots and botnets. They just scan the net, try to bruteforce any login service they found and try to apply any exploit appropriate from their database. If one have a widely used and improperly configured (or not timely updated) setup, it will be hacked this way. The key point of any attack is *cost*, is *money* one needs to spend for an attack. Automated attacks are cheap and such _simple and cheap_ measures as obscured binaries and non-standard (e.g. ssh) ports will stop most of these attacks. This way it will cost _more_ for the attacker to break into protected system and with raise of an attack cost system protection level also rises. Of course, obfuscation is _not_ sufficient for system protection. This is just one small step forward. I don't want to discuss full scope of server protection issues, because this is far out of the topic of this discussion and because measures needed are task- dependent. However I want to notice one critical security issue quite common for production servers: an old software. It doesn't matter how many protection layers system have, how skilled person configured it was. When software is old it is quite trivial to look up for CVEs and break the system. Quite practical encounter from my own experience: I was asked to legitimately obtain root on the box (admin forgot password, reboot (with init=/bin/bash) was not an option and root access was needed for reconfiguration); a box was a year old RHEL with SELinux enforced. Third kernel exploit worked perfectly (I just found them on the net, not bothered to code myself). Such trivia with Gentoo and its custom binaries is not possible. And Gentoo is quite good with recent software updates (RH sometimes is too slow with critical kernel/libc issues). Old software is evil. It doesn't matter how good and tested it _was_. Variety and diversity are quite important for real word systems protection. Of course, it is possible to break _any_ box on the Earth, the only question is how high the cost will be. My point is that Gentoo provides native
Re: [gentoo-user] Fwd: How about the gentoo server or cluster in production environment?
Hi, On Thu, 20 Feb 2014 07:40:59 +0800 Franklin Wang wrote: I'm not familiar with gentoo server and cluster. So could you tell me the experience about them? Thanks. We have successful experience with Gentoo on both production servers (someone call this area enterprise, though I dislike such name) and HPC setups. In short, Procs: - fine-tuned setups; - really large choice of components; - high-performance setups (especially rocks for HPC); - reduced attack surface; - nontrivial attack surface; - large system updates easy (comparted to e.g. RHEL4 - RHEL5 migration); - easier to add and maintain out-of-tree software. Cons: - much longer time for initial setup; - harder to apply routine updates; - poorly suitable for tasks like: create me this new service ASAP (for which you don't have prepared images), preferably yesterday. Other notes: - requires more qualified personnel to maintain. Best regards, Andrew Savchenko pgpkbel_Wkp06.pgp Description: PGP signature
Re: [gentoo-user] Re: Fwd:How about the gentoo server or cluster in production environment?
On Thu, 20 Feb 2014 11:29:52 +0100 Nicolas Sebrecht wrote: The 20/02/14, Nilesh Govindrajan wrote: Gentoo makes the best server os because it's a custom built os where the admin knows each and every aspect of the os. Security wise, there are no unwanted or unused stuff, so lesser bugs to deal with. While I agree with the less code is less bug argument, I disagree with your point. Tuning softwares mean that the binaries compiled on a machine are less used in the wild (other Gentoo systems have other hardware, enabled use flags, etc). Hence, the binaries executed on you local server are likely much less tested by others. And this point is one of the highest security benefits in real world: one have non-standard binaries, not available in the wild. Most exploits will fail on such binaries even if vulnerability is still there. This will cut-off most off automatic botnet attacks even without additional security measures like hardened setup, PaX or GRSecurity (yeah, I never trusted SELinux because of its main author: sane agency will never release a security tool which can be a hinder to this agency). Of course, if system is specifically targeted by qualified professionals, this will only hinder their approach, but binary based distributions will not provide any advantage here either. Best regards, Andrew Savchenko pgpdyWR4NlZ8L.pgp Description: PGP signature
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On Fri, 21 Feb 2014 11:36:15 +0800 Mark David Dumlao wrote: [...] So, please, don't take it as an insult. In fact you have done a very good job of patiently spelling out the advantages of systemd, to the point I'm no longer afraid of it taking over and devouring the linux world. If systemd truly is, as you say taking over and devouring the linux world such that the majority of distro maintainers are individually choosing to use a feature or two from it, then yes, it definitely is the job of people who want to opt out of it to do the work. If Gnome wants systemd, and you don't, but you want to continue using Gnome, it's _your_ job to look for a method or patch or package or script that makes it work. 1. I do _not_ want to use Gnome (and never used it) as DE. 2. Someone called Lennart was a long-time Gnome contributor before Gnome required systemd without alternative. Coincidence? I don't believe in them. I trust probabilities and statistics. If udev wants systemd, and you don't, but you want to continue using udev, it's _your_ job to look for a method or patch or package or script that makes it work. We have eudev fork which is clean from systemd crapware and works perfectly on production setutps. If foo wants systemd, and you don't, but you want to continue using foo, it's _your_ job to look for a method or patch or package or script that makes it work. If everybody else wants to use systemd but you, it's your job to keep your system working the way you want to. Nobody else requires systemd mandatory now as to my knowledge. Nobody's going to go out of their way to specifically and targettedly break your system, because you don't like their way. However, you can co-opt some package maintainer's way and say he's obligated to make a pure and systemd uncorrupted system for you. Because he's not. Bottom line: since Gentoo's default and primary init system is (and hopefully will be for a very long time) OpenRC, it is on the systemd folks to do the work to get systemd fully supported. systemd IS supported and working. The problem arises when there are people that want to push for a system with no systemd whatsoever and act like it's the systemd maintainer's job to make that happen. OpenRC is default in Gentoo now, and it is my best hope it will be. Thus anyone willing to use something else should do an appropriate job. Best regards, Andrew Savchenko pgpiEf5yXsVgJ.pgp Description: PGP signature
Re: [gentoo-user] Re: Debian just voted in systemd for default init system in jessie
On Thu, 20 Feb 2014 18:08:43 -0600 Daniel Campbell wrote: It's marginally clever, but so clearly obvious at the same time. It's sad (to me) that the community didn't see it coming. Those who did have been written off as conspiracy theorists or FUDders. Time will reveal all. Indeed time reveals everything and part of this foiled plot revealed itself two days ago. It was said earlier in the list by systemd supporters, that this project is modular, fine split to binaries and thus critical issues in the pid 1 are not that likely. And just look at systemd-209 release notes: http://lists.freedesktop.org/archives/systemd-devel/2014-February/017146.html [quote] We merged libsystemd-journal.so, libsystemd-id128.so, libsystemd-login and libsystemd-daemon into a a single libsystemd.so to reduce code duplication and avoid cyclic dependencies (see below). [/quote] So all talks about systemd being modular are nothing more than nonsense. Guess what will happen on segfault in libsystemd.so? Segfaults in pid 1 are so nice to bear... And Canek please talk no more about how talented systemd programmers are or even about how professional they are, because they're no longer. They failed a trivial textbook example: what should one do when libraries A and B have some common code and cyclic deps? Push common code to library C. That's the Unix way and secure way. Creating single bloated library will help in neither fencing nor debugging, nor code audit. It looks like to me that ultimate goal of systemd is to consume as much system and user tools and interfaces as possible. Perhaps, in the ideal systemd world there will be nothing but linux-systemd kernel and systemd-stuff userspace. Shell communication will extinct, all major application and daemons will be converted to systemd modules. Of course this goal will be never achieved as-is, but one may consider it as an asymptote of their actions. Best regards, Andrew Savchenko pgpef2uhhHI0s.pgp Description: PGP signature
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On Wed, 19 Feb 2014 10:19:43 + thegeezer wrote: [...] For all this talk about technical details, nobody seems to notice the marketing A few people including myself have noted it earlier. that's going on and frankly it disgusts me. And me too. I have to confess that it does feel very evangelistic the approach from folks pushing systemd. perhaps it is just because for some it has been four years of looking at new ways of doing things, whilst others are just realising now how different it is. I saw an interesting blog post [1] that basically tried to convince directly gentoo devs. it was interesting because of this comment: snip *Simon* September 26, 2013 at 2:58 am https://blogs.gnome.org/ovitters/2013/09/25/gnome-and-logindsystemd-thoughts/comment-page-1/#comment-756 Yes, I think you’re dead on, there. It’s not that Gnome depends on systemd – but it’s increasingly dependent on features that are only provided by systemd. The example of OpenRC not behaving according to GDM’s assumptions is a perfect illustration of that. It’s dependent not on systemd, but on something that for practical purposes is indistinguishable from systemd /snip It looks like systemd PR agents put it quite simple: my way or the highway. And it looks like Gentoo is the last major shelter for freedom we have. the difficulty is that without knowing what features are required but assumed to be there it becomes very difficult to build something the has the API that logind or others might be requiring.an update of gnome might require a new feature that is hot off the presses, and until it breaks an openrc-logind system no one is aware of that requirement. the API does seem to be online [2], albeit updated 30days ago; i can't comment if this is up to date enough or not. I think the argument on the blog page is a bit disingenuous too - essentially implying that if you want gnome then you must have logind, and if you want logind you must supply the features supplied by systemd: but to get a list of the features required is _your_ problem: go through the gnome source code to find out. these kinds of things are what folks are taking umbrage against. I'm also a little confused over the socket matrix feature. I think it's very clever to be negotiating and buffering socket and mounts to services that need them, but I haven't seen a good technical argument as to why this is required. From my perspective i see it as xinet.d for unix sockets and well, is anyone using xinet.d on a production server? Hopefuly someone can enlighten me? also what happens if the socket arbitrator dies ? 1. We never use xinetd on either production systems or desktops/laptops. The only legitimate setup with xinetd I can recall is CVS server. Though the very CVS technology is obsolete this days (yes, I know portage tree is still using it and I'm looking forward for git migration). Socket activation feature is dubious at least. It looks like nobody from its developers cared to assume that services may start not as fast as they expect (e.g. network issues with cisco switches being too slow to answer dhcp which may take up to several minutes). That's why socket activation is extremely dangerous: it may cause services to fail _on_ start. Some may just crash and will be restarted (though not all services may be restarted after crash without manual interaction, e.g. some DB setups may fail badly), while other may loose some functionality and continue to work. Best regards, Andrew Savchenko pgpgPnRlfgeDk.pgp Description: PGP signature
Re: [gentoo-user] Why WordPress is masked?
Hi, On Wed, 19 Feb 2014 16:54:12 +0200 Gevisz wrote: After emerge --search wordpress, I have found that this package is currently masked (at least for amd64 architecture). The same says https://wiki.gentoo.org/wiki/WordPress Earlier, in this mailing list, I was told that I can see the reasons for masking a package in .../profile/package.mask file. However, looking into it, I have not found there the wordpress package at all. Does anybody know, why wordpress package is currently masked and how dangerous it is to unmask it as the wikipage above advises. Wordpress is not masked on my ~x86 and ~amd64 boxes. Probably you have stable amd64 setup. Unmasking is generally safe in such cases, though if you'll mix stable and unstable packages too much you may have unforeseen consequences. Best regards, Andrew Savchenko pgpdKbIpCtX_5.pgp Description: PGP signature
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 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] 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
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] 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] Debian just voted in systemd for default init system in jessie
and able to produce a compatible replacement: logind works with a dbus API, so it's (in theory) *easy* to duplicate its functionality. Ubuntu has been working in a replacement, but (AFAIU) is not finished. And logind hardly depends on systemd . That's why Gnome depends on systemd. The real reason is money: systemd is a Red Hat project (despite being formally open for everyone) and is their tool^Wweapon to fight with Canonical for a sales market. It the last years RH was pushed near even in a server market and now they are fighting back. Nice conspiracy theory you have going on. You may call facts as like as you want to. This will not change them. They were lucky enough to acquire Poettiring guy and create from a simple and sound sysvinit (which is an important but not dictating peace of software) a key component where they can dictate their own line, where they can lead all Linux community in a way they need. And it gets better. Citation needed? Any hard proof? Citation for what? You're free to analyze fact and trends yourself. That the real reason I despise systemd: in replaces the freedom of choice by a dictatorship of a small bunch of managers of a single corporation (yes, managers, not developers). And all this is under the veil of GPL and technical merits. This is the poison in the well of FOSS. I don't work for RedHat; I teach in a University. Nobody pays me for using systemd; I just choose to because I think is a technical sound solution for the chaos that was the plumbing layer in Linux. This chaos is called freedom, freedom of choice, which leads to diversity, evolution and security. With every system unified in its core component we'll have a nice single and easily targeted point of failure. With systemd on most Linux distributions viruses (in terms of self-spreading windows malware) are just a matter of time. If this folly will not be stopped before it's spread you may recall my words in about five years. The technical merits and advantages of systemd are there in the open for anyone willing to study a little about it. *After* you carefully read the code, the documentation, and test the software in real life, you *may* still think you don't like the software or its design. Believe me or not, but I tested it, I read its docs and I studied its code. I vomited. There are two major types of failures: design failure and implementation failure. I'm tolerant to implementation issues, anyone have them after all. But monolithic deeply integrated approach is flawed by design. Even this issue can be tolerated as long as project is supposed to be compatible and replaceable with other solutions (remember, everyone has right to shoot oneself in the leg). But if project is being aggressively enforced, this is no way to go. Best regards, Andrew Savchenko pgpOjpSt4fW_y.pgp Description: PGP signature
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 Sun, 16 Feb 2014 15:16:36 -0600 Canek Peláez Valdés wrote: On Sun, Feb 16, 2014 at 2:58 PM, Volker Armin Hemmann volkerar...@googlemail.com wrote: Am 16.02.2014 21:08, schrieb Canek Peláez Valdés: On Sun, Feb 16, 2014 at 12:59 PM, Volker Armin Hemmann volkerar...@googlemail.com wrote: [ snip ] or it is an idiotic decision. Because features means complexity. Yeah, like the kernel. Complexity means bugs. Bugs get reported, bugs get fixes. Life goes on. You didn't answered this, did you? Bugs are different. Bugs in the critical system components are critical to the whole system. 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. That's why critical components should be as simple and clean as possible. SysVinit code size is about 10 000 lines of code, OpenRC contains about 13 000 lines, systemd — about 200 000 lines. Even assuming systemd code is as mature as sysvinit or openrc (though I doubt this) you can calculate probabilities of segfaults yourself easily. 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. The whole kdbus technology is very questionable itself (and was forcefully pushed by RH devs), anyway it is possible to disable this stuff in kernel and guess what will be done on my systems. 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. And all that science was ignored during systemd architecture process if there was any at all. Best regards, Andrew Savchenko pgpPqKWNVnvHI.pgp Description: PGP signature
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On Mon, 17 Feb 2014 11:13:39 -0600 Canek Peláez Valdés wrote: It simply doesn't matter if systemd boils down to one monolithic binary, or 600, if they are tied together in such a way that they can not *individually* be replaced *easily and simply* (ie, without having to rewrite the whole of systemd). You are setting a group of conditions that preemptively wants to stop adoption of anything that is tightly integrated. That is a losing strategy (different projects actually *want* tight integration), and besides the burden of work should not fall on the people wanting to use a tightly integrated stack. You want individual modules that are easily and simply replaced? Then WROTE THEM. Don't expect the systemd authors (or any other) to do it for you. And here we have a small problem: for modules to be replaceable the core system should be designed to support replaceable modules, but systemd is not. The whole deep integration approach and lack of inter-module boundaries doesn't allow one to write replaceable blocks without crazy hacking. 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 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. 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. 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. In fact, it seems to me that, since (from what I've read) the primary reason that systemd was written in the first place was to provide extremely fast boots *in virtualized environments*, You are wrong; systemd was created because Upstart had the silly CLA from Canonical[1], and because its authors wanted a novel init system for Linux (and Linux only) that used all the cool technologies the kernel provides, and that it could solve problems like: how to easily and consistently start daemons with well defined semantics for its dependencies; how to easily and consistently apply resource quotas to them; how to deal with modern computers where hardware comes and goes (including CPUs) all the time, etc. [2]. Excuse me please, but what you wrote above is very naive. All that reasons are just an excuse. The real reason is money: systemd is a Red Hat project (despite being formally open for everyone) and is their tool^Wweapon to fight with Canonical for a sales market. It the last years RH was pushed near even in a server market and now they are fighting back. They were lucky enough to acquire Poettiring guy and create from a simple and sound sysvinit (which is an important but not dictating peace of software) a key component where they can dictate their own line, where they can lead all Linux community in a way they need. That the real reason I despise systemd: in replaces the freedom of choice by a dictatorship of a small bunch of managers of a single corporation (yes, managers, not developers). And all this is under the veil of GPL and technical merits. This is the poison in the well of FOSS. Best regards, Andrew Savchenko pgpNXWRgUgRgH.pgp Description: PGP signature
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On Mon, 17 Feb 2014 14:52:33 -0500 Tanstaafl wrote: On 2014-02-17 12:52 PM, Andrew Savchenko birc...@gmail.com wrote: 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. The whole kdbus technology is very questionable itself (and was forcefully pushed by RH devs), anyway it is possible to disable this stuff in kernel and guess what will be done on my systems. Forcefully? Are you saying that *anyone* can *force* Linus to put something into the kernel? OK, my choice of words was not appropriate. I mean that not every kernel dev is happy that kdbus is in the kernel now. I'd also really, *really* like to hear a *recent* opinion from Linus on systemd... Judging from his previous opinions this one is unlikely to be systemd- friendly. Best regards, Andrew Savchenko pgpoH_OQWnQcJ.pgp Description: PGP signature
Re: [gentoo-user] blocking -systemd
Hi, On Thu, 6 Feb 2014 11:49:41 -0700 Joseph wrote: I have in make.conf USE: ... -systemd But gnome-base/gnome-settings-daemon wants to pull in systemd-208 so I need to emerge sys-apps/systemd-208-r2 and I have installed udev which conflicts with systemd. Do I need to unmerge udev and emerge systemd. I'm not planning on switching to systemd after recent experience. So I was planning on avoiding it but I don't know if I can. You can add openrc-force US flag to your make.conf. This way you will drop systemd dependency, though you may loose some run-time functionality of gnome. Other alternative is to add sys-apps/systemd to package.provided, though the effect will be the same as above. And you may switch to some other DE/WM of course. Best regards, Andrew Savchenko pgpc2mNVuTez1.pgp Description: PGP signature
Re: [gentoo-user] Re: Portage performance dropped considerably
On Sat, 01 Feb 2014 00:12:58 +0200 Alan McKinnon wrote: and to use this library via some python binding from portage. But I suppose algorithm itself should be reviewed first. ^this is where the speedups will lie 4 minutes on this here i7 monster and 40 on your Atom is ridiculous considering the problem that is being solved. Portage is probably searching and re-searching dead paths in the tree or something equally silly. The algorithm should be analysed and dead paths optimized away. Not a language problem. Another challenge is to make dependency resolution parallel — result should be awesome on modern multi-core CPUs. And I'm sure this is a doable task (on a first glance analyse subtrees first then join), but this issue requires further and deeper investigation. Best regards, Andrew Savchenko pgpzv2pb2yd7N.pgp Description: PGP signature
Re: [gentoo-user] Portage performance dropped considerably
On Sun, 26 Jan 2014 16:53:33 +0100 Mariusz Ceier wrote: No, it's not just you, running emerge -uNDvp world takes slightly over 18 minutes on my laptop (i5 M 430 @ 2.27GHz) - and when there was lot to update I had to wait over 1hr to just get the list of packages. I wonder if there's some profiling tool for portage. Also: time FEATURES=-xattr emerge owncloud -v real6m31.202s user2m42.057s sys 2m1.541s time FEATURES=xattr emerge owncloud -v real30m15.632s user22m44.369s sys 5m30.129s 5 times longer - for something that's essentially copying files. Slow xattr is a known problem, see bugs 482290, 465000: https://bugs.gentoo.org/show_bug.cgi?id=482290 https://bugs.gentoo.org/show_bug.cgi?id=465000 But xattr bug shows itself during install phase and has nothing to do with dependency calculation time mentioned in the original mail. Best regards, Andrew Savchenko pgpZwwW6J9EA7.pgp Description: PGP signature
Re: [gentoo-user] Re: Portage performance dropped considerably
On Sun, 26 Jan 2014 20:30:19 +0200 Alan McKinnon wrote: It comes from watching what happens at the end of running emerge, don't read any more into it than that. Especially not optimism, I think you might be projecting your own frustrations. A couple of years ago I used to have to manually resolve blockers about one world update in two. It started becoming a huge PITA especially as the deps are usually easy to solve - if I can look at the screen for a few seconds and figure it out, then software can do the same in milliseconds. Recent portages now do this properly when viewed from a results-only perspective. On my machines, that is what I see happening. That is the ONLY set of FACTS I have to work on; you may have more. I'm willing to give up 4 minutes while emerge runs so I don't have to spend many more minutes right afterwards doing manually the very shit that software is very good at. Whether portage is a complete pile of dogshit software or not is beside the point. Even if it is, my 4 minutes still buys me lots shrug 4 minutes are expendable but... on Atom N270 (my laptop) emerge -DNuav world takes 40 (yes, forty) minutes to build dependency tree with sqlite cache enabled and 60 minutes without sqlite. System was pretty old (not updated aside from GLSA updates for a year). And this 40 minutes repeated many times since USE flag clashes and dependency resolution failures. So I spent may day, damn whole day(!) for the sake to just start compiling (distcc is my friend here). Best regards, Andrew Savchenko pgpnG9flBECe4.pgp Description: PGP signature
Re: [gentoo-user] Re: Portage performance dropped considerably
On Fri, 31 Jan 2014 19:13:21 + Mick wrote: On Friday 31 Jan 2014 19:03:05 Andrew Savchenko wrote: On Sun, 26 Jan 2014 20:30:19 +0200 Alan McKinnon wrote: [...] I'm willing to give up 4 minutes while emerge runs so I don't have to spend many more minutes right afterwards doing manually the very shit that software is very good at. Whether portage is a complete pile of dogshit software or not is beside the point. Even if it is, my 4 minutes still buys me lots shrug 4 minutes are expendable but... on Atom N270 (my laptop) emerge -DNuav world takes 40 (yes, forty) minutes to build dependency tree with sqlite cache enabled and 60 minutes without sqlite. System was pretty old (not updated aside from GLSA updates for a year). And this 40 minutes repeated many times since USE flag clashes and dependency resolution failures. So I spent may day, damn whole day(!) for the sake to just start compiling (distcc is my friend here). Out of interest what fs are you running portage on? I changed an old box from reiserfs to ext4 and couldn't believe the speed up I got. I use ext4. In my case the problem is in CPU usage and Atom N270 is pretty weak these days. On this box HDD is fast and NCQ capable, memory is enough (2GB for 32bit setup). During dependencies calculation all 100% of time is spent in the python process. CPU is slightly overclocked (as much as SHE allows). There is nothing more that I can do here as an admin of this host. (Gentoo setup itself is complicated with 2200 packages.) IMO the only way to improve this issue (without throwing good working hardware in the window) is to rewrite dependency resolution code in some highly optimized pure C library (probably with some asm code) and to use this library via some python binding from portage. But I suppose algorithm itself should be reviewed first. Best regards, Andrew Savchenko pgp9TEWZL3PYu.pgp Description: PGP signature
Re: [gentoo-user] to nest commands
On Tue, 26 Nov 2013 09:58:24 -0500 Randy Barlow wrote: On Tue, 26 Nov 2013 11:52:10 +0100 Hinnerk van Bruinehsen h.v.bruineh...@fu-berlin.de wrote: There are some other options of nesting as well. You can use backticks ` or $(...) to run a command inside another. An example would be emerge `qlist -CI x11-drivers` (or the equivalent emerge $(qlist -CI x11-drivers) ) . This would run qlist -CI x11-drivers (lists installed packages of the category x11-drivers) and use this output for emerge (which will effectively result in reinstalling every package from the x11-drivers category). As I understand it, the $(...) syntax is the preferred way of nesting, as opposed to backticks. I think this may be due to backticks requiring some special escaping that the $(...) syntax does not require. I attempted a brief search for supporting information, but didn't find a definitive source to back up my claims :) The reason for $(...) being preferred is simple: you can nest $($($(...))), but you can't nest `...`. Deep nesting is quite useful indeed. Best regards, Andrew Savchenko pgpv4whI_T8sT.pgp Description: PGP signature
