Re: [gentoo-user] Does systemd work with mdadm?
On Fri, Nov 28, 2014 at 4:15 PM, Daniel Frey djqf...@gmail.com wrote: OK, I decided I'm going to try systemd to see what all the hubbub is about. I know there are people on here that use it so I'm hoping someone's can alleviate my concerns on it with mdadm. I use an IMSM container (Intel fakeraid) as I dual boot with Windows. This has happily worked for some time now. I've googled around and it seems there could be a bug using mdadm and lvm at the same time, but that's not what I'm doing. Considering when I first set up this dual boot there was some configuration involved, I don't believe I can just install it and pray it works as I've read if systemd goes sideways you can't even log in. Are there people running systemd and mdadm together that can comment? I think I'm going to try anyway, and I have a suspicion that systemd is going to bomb the first time it boots. Dan mdadm works perfectly fine with systemd. I am running a 4-disk RAID-10 configuration and it gets assembled properly by systemd. I have the ARRAY ... definition in /etc/mdadm.conf and the /dev/mdXXX mount point in /etc/fstab and AFAICT that's all you need, the default udev/systemd configuration brings it all up as expected. --Mark
[gentoo-user] Debian forked, because of systemd brouhaha
So, I just found out that some Debian Developers decided to fork Debian, because they can no longer stand this abomination called 'systemd': https://lists.dyne.org/lurker/message/20141127.212941.f55acc3a.en.html What do you think, people? Shouldn't we offer them our eudev project to assist? Rgds, --
Re: [gentoo-user] Debian forked, because of systemd brouhaha
On Sat, 29 Nov 2014 10:11:20 +, Pandu Poluan wrote: So, I just found out that some Debian Developers decided to fork Debian, because they can no longer stand this abomination called 'systemd': https://lists.dyne.org/lurker/message/20141127.212941.f55acc3a.en.html What do you think, people? Shouldn't we offer them our eudev project to assist? I think it's a great example of the power of open source. At last some systemd haters are doing something more pro-active than name-calling. No one needs to offer eudev to them, the code is already out there, but openrc may be more useful. It has a few of the advantages of systemd. -- Neil Bothwick - How many surrealists does it take to change a light bulb? - Two: one to hold the giraffe, the other to fill the bathtub with lots of brightly colored machine tools. pgpoMmCQG19rj.pgp Description: OpenPGP digital signature
[gentoo-user] Re: Gentoo's future directtion ?
On Sat, Nov 29, 2014 at 07:09:07AM +, Martin Vaeth wrote: So for non-developers, downloading with git does not necessarily make sense. That being said, please do not consider this as an argument against a change to git: For developers it has only advantages, and AFAIK, it is not planned to cancel other download methods anyway. Of course. This is not going to be a requirement. Non-developers should stick with rsync. No one meant to replace rsync with Git. It is about replacing CVS with Git. -- Nicolas Sebrecht
Re: [gentoo-user] Debian forked, because of systemd brouhaha
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 29/11/14 13:11, Pandu Poluan wrote: So, I just found out that some Debian Developers decided to fork Debian, because they can no longer stand this abomination called 'systemd': https://lists.dyne.org/lurker/message/20141127.212941.f55acc3a.en.html Thanks for spreading the news. I hope this project will develop and prosper! -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJUebjiAAoJEK64IL1uI2habj0H/0R2u9UImnDod/19S/+YJTul DS1pmb1MSq5Dr1uaaegxPnaEJB/o7KmkNh9U9RmyY+4H/61rosBS6Dp6H38wCZNY MrQW5XO0nnnbsQuSFoODQKISJjJ1W23zkLsK68LhZNx7LgukDuybj5Fcxd9bjvSj aOy9P1JYv8+kSIJ6qs8iLjL4q1Np8fsSTbQ6rHRn2T6zOe0uq+wNJxLRuRPL+M46 C8ToRogNOD7YDeiYMr2BX3tVUmaFUVjU+zr6S9DWO2ZtHoza/YyzoYlAiFd0KPpg NfIpGJQtnW2Q+Rx+3oTzTqRMVxcRA3q1NQI1iVI9sx243KSLQDUdt0gRvj+BNbE= =wj3z -END PGP SIGNATURE-
Re: [gentoo-user] Re: Gentoo's future directtion ?
Hello, everybody. On Sat, Nov 29, 2014 at 07:09:07AM +, Martin Vaeth wrote: hasufell hasuf...@gentoo.org wrote: Martin Vaeth: hasufell hasuf...@gentoo.org wrote: With rsync I believe you can exclude categories: http://www.gentoo-wiki.info/TIP_Exclude_categories_from_emerge_sync That is uninformed. I think he is right. check the --depth option of git. You can even clone specific tags with --depth=1. Every tag will still contain all categories: AFAIK, with git, it is not possible to update everyting but e.g. *access* *kde* *i10n* *gnome* if you know that you will never install an ebuild from these categories. My max DL rate is ~700KiB/s and is the limiting factor. My concern is not the time but the total volume (there are still often limitations involved), and perhaps even more important, the disk usage, especially compared with methods like squashfs(+aufs). It simply is a fact that with git you have to download and store a lot of unnecessary information (if you are not a developer and do not use a heavy system): not only git metadata but also unneeded categories. So for non-developers, downloading with git does not necessarily make sense. That being said, please do not consider this as an argument against a change to git: For developers it has only advantages, and AFAIK, it is not planned to cancel other download methods anyway. Speaking as a developer in a project which has just converted to git, I can assure you that git has tremendous disadvantages, even compared with cvs. Principally, git does not have a high level model of version control concepts, so that using git is somewhat analogous to programming in assembler. Both give you tremendous control and the ability to do practically anything, including shooting yourself in the foot. So that instead of conceptualising a branch (as you would do with Mercurial, Bazaar, Subversion, or even CVS), you need to think about commits reachable from a certain head (excluding commits reachable from some other head). git is very difficult to learn, compared with, say Mercurial. To compare, if you do $ git help branch, you get a man page ~180 lines long dumped on you, and that's taking up the full width of my 240 character wide screen. If you do $ hg help branch, you get a 27 line concise summary, max. ~80 characters wide, which nonetheless is pretty much complete. git has become very popular (much as systemd has), possibly because programmers are frustrated at not being able to write in assembler any more. (At least, that's my theory). Like systemd, it has established a stranglehold on its domain. But severe disadvantages it most definitely has. -- Alan Mackenzie (Nuremberg, Germany).
Re: [gentoo-user] Re: Gentoo's future directtion ?
On Sat, Nov 29, 2014 at 10:28 PM, Alan Mackenzie a...@muc.de wrote: Hello, everybody. Good day. instead of conceptualising a branch (as you would do with Mercurial, Bazaar, Subversion, or even CVS), you need to think about commits reachable from a certain head (excluding commits reachable from some other head). I actually see that as a more flexible approach. git is designed to be distributed and that's what everyone loves about it. For everything: http://stackoverflow.com/questions/802573/difference-between-git-and-cvs http://eclipsesource.com/blogs/2011/06/09/git-lessons-learned/ Cheers, konsolebox
Re: [gentoo-user] Re: Gentoo's future directtion ?
Hello, konsolebox. On Sat, Nov 29, 2014 at 11:18:49PM +0800, konsolebox wrote: On Sat, Nov 29, 2014 at 10:28 PM, Alan Mackenzie a...@muc.de wrote: Hello, everybody. Good day. instead of conceptualising a branch (as you would do with Mercurial, Bazaar, Subversion, or even CVS), you need to think about commits reachable from a certain head (excluding commits reachable from some other head). I actually see that as a more flexible approach. git is designed to be distributed and that's what everyone loves about it. We're in violent agreement, it seems. git is very flexible, just like programming in assembler is. git is certainly a distributed system, just like Mercurial, Bazaar, etc., but seems to be the only one of its kind that imposes this degree of flexibility on its users. Hence the multi-hundred line man pages for each of git's 155 sub-commands. Mercurial has a mere 50 sub-commands (plus, to be fair, a few one's going to need which are classified as extensions), and a single, very readable, man page ~8000 lines long. For everything: http://stackoverflow.com/questions/802573/difference-between-git-and-cvs http://eclipsesource.com/blogs/2011/06/09/git-lessons-learned/ Cheers, konsolebox -- Alan Mackenzie (Nuremberg, Germany).
Re: [gentoo-user] Debian forked, because of systemd brouhaha
Am 29.11.2014 um 11:11 schrieb Pandu Poluan: What do you think, people? Shouldn't we offer them our eudev project to assist? Since Eudev has always been opensource under the GPLv2, like udev too, there's no need to /offer/ it. If they choose to use it, they can use it, no offer/questions necessary. Simple.
Re: [gentoo-user] Re: Gentoo's future directtion ?
On 11/29/2014 09:28 AM, Alan Mackenzie wrote: Speaking as a developer in a project which has just converted to git, I can assure you that git has tremendous disadvantages, even compared with cvs. It depends; they do different things. Depending on what I'm working on, I use either subversion or git; neither is inherently better all the time. Principally, git does not have a high level model of version control concepts, so that using git is somewhat analogous to programming in assembler. Both give you tremendous control and the ability to do practically anything, including shooting yourself in the foot. So that instead of conceptualising a branch (as you would do with Mercurial, Bazaar, Subversion, or even CVS), you need to think about commits reachable from a certain head (excluding commits reachable from some other head). As far as I can tell, git has a very clear concept of branching. Fast branching was one of the biggest design points in git[1], and they did it by merely making branches pointers to avoid unnecessary copying. So yes, a branch is commits reachable from a certain HEAD, but conceptually this is the same as other branching models even though it may not be implemented the same way. git is very difficult to learn, compared with, say Mercurial. To compare, if you do $ git help branch, you get a man page ~180 lines long dumped on you, and that's taking up the full width of my 240 character wide screen. If you do $ hg help branch, you get a 27 line concise summary, max. ~80 characters wide, which nonetheless is pretty much complete. git has become very popular (much as systemd has), possibly because programmers are frustrated at not being able to write in assembler any more. (At least, that's my theory). Like systemd, it has established a stranglehold on its domain. But severe disadvantages it most definitely has. git is extremely popular, which could be a factor in its difficulty; I'm guessing it's had a lot more development hours (and more obscure features) put into it. git is popular because it solved (and still solves) a problem (distributed, parallel development) that at the time was not solved by any other open source DVCS except Mercurial. Both projects started around the same time, and I would imagine that having the Linux kernel team backing git was a compelling reason to choose git over Mercurial. Early on, iirc git was also faster since mercurial uses diffing, not snapshots, and is written in Python. I highly recommend Scott Chacon's Pro Git: http://git-scm.com/book/en/v2 Alec [1] http://git-scm.com/book/en/v2/Getting-Started-A-Short-History-of-Git
Re: [gentoo-user] Re: Gentoo's future directtion ?
Alan Mackenzie: So that instead of conceptualising a branch (as you would do with Mercurial, Bazaar, Subversion, or even CVS), you need to think about commits reachable from a certain head (excluding commits reachable from some other head). [snipping everything that is not technical] How exactly is that a disadvantage? You are just complaining about the way a concept is presented without saying what actual limitations that implies (if any). If you like mercurial better, use that. Speaking about disadvantages however requires a bit more than I like that way better.
[gentoo-user] TPM feature - do I need it?
I'm looking to buy a new PC and while looking at FM2+ MoBos I saw ASUS offers one with a TPM feature. It also sells it as a separate component it seems: http://us.estore.asus.com/index.php?l=product_detailp=5793 I recall reading in this list about it, but I am not sure if it offers any benefits to me as a user, or just adds a layer of complexity without any substantial benefit. Your views and experience with this TPM thingy? -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] TPM feature - do I need it?
On Sat, Nov 29, 2014 at 2:53 PM, Mick michaelkintz...@gmail.com wrote: I'm looking to buy a new PC and while looking at FM2+ MoBos I saw ASUS offers one with a TPM feature. It also sells it as a separate component it seems: I can't get that page to load, but I can't imagine that you could find a motherboard that DIDN'T have a TPM that has been made anytime in the last decade. It doesn't tend to get a lot of use in the Linux world, though the Chromebook would be a BIG exception there. In the corporate windows world it gets very heavy use for full-disk encryption, and I think Win7 supports this out of the box (though big companies tend to use 3rd party software). Main uses for TPM include remote attestation, full-disk encryption (without the need to type a boot password), and secure credential storage only accessible via a trusted code path. The Linux kernel has support for TPM, but if you want to use many of the trusted boot features you need a bootloader that supports TPM. The main downside with TPM with something like Gentoo is that if you aren't careful you can make your keys inaccessible. I'd keep a copy of the keys somewhere safe if you plan to use it for something like full-disk encryption (and/or do regular backups). Otherwise if you incorrectly update grub you might find your drive completely inaccessible (if you're using a trusted boot path then you need to update the TPM when you update your boot path or the chip will no longer trust your grub/kernel/etc). The upside is that if you do it right you retain full control over the encryption and your system will be VERY hard to break into (without inside access - it is quite possible folks like the NSA have a backdoor, but you'll be very safe from more ordinary threats). -- Rich
[gentoo-user] OT somehow: experiences around linode
fellow gentoo-users: Who has rent a virtual server at linode.com and what is your opinion? I find stuff like: http://www.webhostingtalk.com/showthread.php?t=1101752 https://plus.google.com/+DiegoElioPettenò/posts/FbuwyVg79Eh Maybe they have learned since then? Any current opinions? I spent a few euros and run some test-VM there ... performance looks good so far. Stefan
Re: [gentoo-user] Debian forked, because of systemd brouhaha
Am 29.11.2014 um 11:11 schrieb Pandu Poluan: What do you think, people? Shouldn't we offer them our eudev project to assist? After studying their home pages so far I came to the conclusion, that I cannot take Devuan serious. It still feels more like a prank to me than a serious thing. First the name Veteran Unix Admins collective sounds strange. Nobody ever heared of them before, they don't have any kind of information on the web before that announcement of the fork showed up. Second: they are already asking for donations. Third, but most important reason: no names on their f***ing pages. Why? If I would fork a project I would mention popular names right from the beginning to gain a serious momentum! This has not happened here at all. Who are those people? Whose behind this so called fork? That's a thing that's still lurking somewhere in the shadows. Especially the fact, that they don't mention any names at all on their project pages is something that's really strange to say at last. So unless those people behind the shadows are coming out of the dark and going to solidify it's just something many people would like to happen, of course - but without any substance at all. That's why I am skeptical about all of this created buzz around it and seriously doubt if they are going to be able to deliver.
Re: [gentoo-user] TPM feature - do I need it?
On Saturday 29 Nov 2014 20:23:51 Rich Freeman wrote: On Sat, Nov 29, 2014 at 2:53 PM, Mick michaelkintz...@gmail.com wrote: I'm looking to buy a new PC and while looking at FM2+ MoBos I saw ASUS offers one with a TPM feature. It also sells it as a separate component it seems: I can't get that page to load, but I can't imagine that you could find a motherboard that DIDN'T have a TPM that has been made anytime in the last decade. It doesn't tend to get a lot of use in the Linux world, though the Chromebook would be a BIG exception there. In the corporate windows world it gets very heavy use for full-disk encryption, and I think Win7 supports this out of the box (though big companies tend to use 3rd party software). Main uses for TPM include remote attestation, full-disk encryption (without the need to type a boot password), and secure credential storage only accessible via a trusted code path. The Linux kernel has support for TPM, but if you want to use many of the trusted boot features you need a bootloader that supports TPM. The main downside with TPM with something like Gentoo is that if you aren't careful you can make your keys inaccessible. I'd keep a copy of the keys somewhere safe if you plan to use it for something like full-disk encryption (and/or do regular backups). Otherwise if you incorrectly update grub you might find your drive completely inaccessible (if you're using a trusted boot path then you need to update the TPM when you update your boot path or the chip will no longer trust your grub/kernel/etc). The upside is that if you do it right you retain full control over the encryption and your system will be VERY hard to break into (without inside access - it is quite possible folks like the NSA have a backdoor, but you'll be very safe from more ordinary threats). Thanks Rich, it seems not all modern MoBos have it. This doesn't: http://www.asus.com/uk/Motherboards/A88XMA/specifications/ While this does: http://www.asus.com/uk/Motherboards/A88XGAMER/specifications/ Besides the complexity of it all and the risk of errors, it's the remote attestation part that worries me a bit. I mean this is not MSWindows, so the only entity I would expect to attest what I'm running on my machine is me. Well, fair enough, portage checks the hashes of the downloaded source files, but I would not want anyone to remotely check anything on my PC. If I enable this TPM thing, do I automatically open ports at pre/post-boot time giving access to my machine? Or is remote attestation something I have a say over? Also, what happens if the TPM chip, or the whole MoBo blows up? Will I ever be able to access my data using another PC? -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Debian forked, because of systemd brouhaha
On Sat, Nov 29, 2014 at 6:30 PM, Marc Stuermer m...@marc-stuermer.de wrote: That's why I am skeptical about all of this created buzz around it and seriously doubt if they are going to be able to deliver. Systemd = buzz these days. There was a slashdot post about some kernel bug and it seemed like 1/3rd of the posts were talking about whether systemd is to blame. You can't go three days without some kind of flamewar, and I'm sure the slashdot marketing team is milking it for every ad dollar they can get before they go bankrupt... :) -- Rich
Re: [gentoo-user] OT somehow: experiences around linode
Stefan G. Weichinger wrote: Who has rent a virtual server at linode.com and what is your opinion? I have two servers with Linode, one running Gentoo, and Debian on the other. My experience has been great so far. My only contact with support was an ipv6 issue that I ran into a few months ago, and they quickly replied with a reference to a Gentoo bug which included the fix. So here's one vote for Linode. Al
Re: [gentoo-user] OT somehow: experiences around linode
Am 30.11.2014 um 00:57 schrieb Al: My experience has been great so far. My only contact with support was an ipv6 issue that I ran into a few months ago, and they quickly replied with a reference to a Gentoo bug which included the fix. So here's one vote for Linode. good to hear that thanks (compiling there right now)
Re: [gentoo-user] flag details
On Mon, Nov 24, 2014 at 05:09:36PM +, James wrote: So, I use euse to read aobut flags. Sometimes the same flag has slightly, but significantly different meanings depending on the packages it is use on. A tool with perhaps more detail or that parse the ebuild/sources for even greater detail information? I was out of country so couldn't read mail the last few days. My answer to your question: ufed This program seems very little known around the list. It doesn't give you more detail than euse, but it shows you what is available in an easy to view (and edit!) list. -- Gruß | Greetings | Qapla’ Please do not share anything from, with or about me on any social network. I never err! Once I thought I was in error, but I was mistaken. signature.asc Description: Digital signature
Re: [gentoo-user] Does systemd work with mdadm?
On 11/29/2014 12:19 AM, Mark Pariente wrote: mdadm works perfectly fine with systemd. I am running a 4-disk RAID-10 configuration and it gets assembled properly by systemd. I have the ARRAY ... definition in /etc/mdadm.conf and the /dev/mdXXX mount point in /etc/fstab and AFAICT that's all you need, the default udev/systemd configuration brings it all up as expected. --Mark I managed to get it going without too much trouble. I followed a guide on the gentoo wiki but it didn't mention anything about setting up a network, so I didn't. When I rebooted that caused a mess but I was still able to log in. Fixed that and added services that were enabled in openrc (like kdm...) and everything's good to go. So far, it's better than openrc in that there's a bug shutting down an imsm raid that's still not been addressed. It causes the array to do a rebuild next time it starts up and from my testing systemd doesn't have this issue. Dan
Re: [gentoo-user] Debian forked, because of systemd brouhaha
On 30/11/14 07:30, Marc Stuermer wrote: Am 29.11.2014 um 11:11 schrieb Pandu Poluan: What do you think, people? Shouldn't we offer them our eudev project to assist? After studying their home pages so far I came to the conclusion, that I cannot take Devuan serious. It still feels more like a prank to me than a serious thing. First the name Veteran Unix Admins collective sounds strange. Nobody ever heared of them before, they don't have any kind of information on the web before that announcement of the fork showed up. Second: they are already asking for donations. Third, but most important reason: no names on their f***ing pages. Why? If I would fork a project I would mention popular names right from the beginning to gain a serious momentum! This has not happened here at all. Who are those people? Whose behind this so called fork? That's a thing that's still lurking somewhere in the shadows. Especially the fact, that they don't mention any names at all on their project pages is something that's really strange to say at last. So unless those people behind the shadows are coming out of the dark and going to solidify it's just something many people would like to happen, of course - but without any substance at all. That's why I am skeptical about all of this created buzz around it and seriously doubt if they are going to be able to deliver. maybe, maybe not. I read Veteran Unix Admins collective as a category that old style admin types fall into - the background being that systemd is essentially the old guard, do things based on experience and good practice vs the new guard whose use case is throw away vm's that are not expected to hang around, we don't care amateurs. I am a native English speaker, maybe that's why you missed it? They do make the point that they didn't really have a long term plan to fork ... they tried to work within the system but have just now decided that its not going to work so fork. I think its a case of watch this space as they are just getting organised and have a lot to attend to at very short notice. Implications? - will gentoo fork if push comes to shove? - using this example I hope so ... I am already really annoyed that by default systemd and apps designed to work with it leave traces on openrc based systems. BillK
Re: [gentoo-user] TPM feature - do I need it?
On Sat, Nov 29, 2014 at 6:44 PM, Mick michaelkintz...@gmail.com wrote: Thanks Rich, it seems not all modern MoBos have it. This doesn't: Interesting, I had really thought they were ubiquitous. If I enable this TPM thing, do I automatically open ports at pre/post-boot time giving access to my machine? Or is remote attestation something I have a say over? It has to be implemented in software. The only thing the chip does is let software call it and ask it to sign data. The chip can't talk to the network on its own. Remote attestation doesn't actually give anybody access to your machine. Now, it does let you prove to somebody that they actually do have access to your machine, if you installed software that gave them access. Suppose I gave you a piece of software and asked you to install it on your machine so that I could evesdrop on everything you do. If you refuse to do it I'll fire you from your job. Without remote attestation you could install that software in a VM or emulator somewhere and tell me you complied, and it would be impossible for me to tell that you did this if your VM was well-implemented. On the other hand, if my software implemented remote attestation then the best you could do is block it, in which case I brand you as non-compliant and fire you. With remote attestation I could get a list of the boot path from the firmware to my software and see if there is anything in it that could tamper with my software. If I dictate that you have to run TrustedCo Linux v5 then I could see that you're running an unpatched version of it and know that my process is directly talking to the kernel, which I know doesn't let you tamper with it, and that kernel is directly running on the hardware having been loaded by a trusted firmware/bootloader. Also, what happens if the TPM chip, or the whole MoBo blows up? Will I ever be able to access my data using another PC? Only if you encrypted it. A TPM chip doesn't do much more than except store and retrieve data, and digitally sign things. It just tends to be used in a way that greatly limits the ability of arbitrary processes to access the data stored on the chip. With Linux you're basically completely in control. You choose to encrypt your drive and store the key in the TPM, and you instruct the TPM to only hand it over under the conditions you specify, such as a particular bootloader, kernel, and initramfs (or something like that - I've never implemented it myself). If somebody tries to boot your system with some other kernel/bootloader/initramfs then the TPM will not have the valid signature chain and it will refuse to divulge your full-disk encryption key. I imagine that you could generate the key outside the TPM and keep a copy of it somewhere and load it into the TPM, so that if you mess up you can just mount it manually. It is a bit like UEFI - if you use it properly it becomes a tool which allows the device owner to secure his own device against other intruders. The problems only come when people want to treat your device as if it is their device. With Linux you control almost all of it, though I would GREATLY prefer it if TPM chips did not come with vendor-supplied certificates (that is, if there was no way for anybody to determine if the master key inside was externally loaded by the end user or not). If they didn't come pre-loaded with certificates then they would be just as usable for securing your own machine (since you could add your own certificate/etc), but they would be useless for DRM (since no key was ever in the chip at a time when it was in the possession of somebody trusted by the media companies). I also don't have much more than a general interest in this area, so I'm sure there are some fine details above which are inaccurate. The gist of it should be right though. -- Rich
Re: [gentoo-user] Debian forked, because of systemd brouhaha
On Sat, Nov 29, 2014 at 9:01 PM, Bill Kenworthy bi...@iinet.net.au wrote: I am already really annoyed that by default systemd and apps designed to work with it leave traces on openrc based systems. You're getting worked up about text files and filenames. I suppose you'll be really upset that bash completion files are now being installed by default, and packages install logrotate configs and cron scripts even if you don't use logrotate or cron. Sure, we could add a million more layers of conditionals to everything and you might save a few dozen inodes on your 10GB install, at the cost of lots of hassle/bugs/etc. In general Gentoo tends to take the pragmatic approach. If you're a purist of just about any kind you're going to have to hold your nose. However, this cuts both ways - the purists who don't want YOU to be able to make the choices YOU want to make also have to hold their noses. :) -- Rich
Re: [gentoo-user] Does systemd work with mdadm?
On Sat, Nov 29, 2014 at 8:44 PM, Daniel Frey djqf...@gmail.com wrote: So far, it's better than openrc in that there's a bug shutting down an imsm raid that's still not been addressed. It causes the array to do a rebuild next time it starts up and from my testing systemd doesn't have this issue. I can't speak to that particular bug but one of the nice things systemd does if you're using dracut is that during shutdown systemd will pivot back to the original initramfs and cleanly unmount root and so on. This allows a complete shutdown of things like lvm/mdadm/etc if done properly. When I first started using systemd I actually noticed the improvements in shutdown more than startup (parallel openrc is already pretty decent). -- Rich
Re: [gentoo-user] Debian forked, because of systemd brouhaha
On Sat, 29 Nov 2014 22:32:18 -0500 Rich Freeman wrote: On Sat, Nov 29, 2014 at 9:01 PM, Bill Kenworthy bi...@iinet.net.au wrote: I am already really annoyed that by default systemd and apps designed to work with it leave traces on openrc based systems. You're getting worked up about text files and filenames. I suppose you'll be really upset that bash completion files are now being installed by default, and packages install logrotate configs and cron scripts even if you don't use logrotate or cron. We have INSTALL_MASK for such cases. While it should be used with care (as improper use will broke system), INSTALL_MASK=*/systemd/* keeps my systems clean from this filthy abomination. Sure, we could add a million more layers of conditionals to everything and you might save a few dozen inodes on your 10GB install, at the cost of lots of hassle/bugs/etc. In general Gentoo tends to take the pragmatic approach. If you're a purist of just about any kind you're going to have to hold your nose. However, this cuts both ways - the purists who don't want YOU to be able to make the choices YOU want to make also have to hold their noses. :) Best regards, Andrew Savchenko pgpl14gaxAGpX.pgp Description: PGP signature
Re: [gentoo-user] Debian forked, because of systemd brouhaha
On Sat, 29 Nov 2014 17:32:08 +0100 Marc Stürmer wrote: Am 29.11.2014 um 11:11 schrieb Pandu Poluan: What do you think, people? Shouldn't we offer them our eudev project to assist? Since Eudev has always been opensource under the GPLv2, like udev too, there's no need to /offer/ it. If they choose to use it, they can use it, no offer/questions necessary. Simple. As far as I understand, Pandu meant we can recommend them to use, but not some offer in commercial or proprietary terms. Don't forget that most people on the list are not native speakers, so IMHO superfluous verbalism is inappropriate here. Best regards, Andrew Savchenko pgpEVGBDFymZu.pgp Description: PGP signature
