Re: [gentoo-dev] Re: udev <-> mdev
On Fri, Jul 13, 2012 at 7:13 PM, Walter Dnes wrote: > On Sat, Jul 14, 2012 at 01:49:32AM +0300, Maxim Kammerer wrote >> On Fri, Jul 13, 2012 at 11:12 PM, Richard Yao wrote: >> > mdev would need to switch to the netlink hotplug interface. >> >> I think that's quite unlikely, since mdev is not a daemon. Perhaps by >> the time /proc/sys/kernel/hotplug is gone, mdev advocates will have >> settled on some early udev fork. [1] > > Do you realize this would effectively kill linux in the embedded > device area? Udev, even without the systemd code, is simply to large > for embedded devices. The guys from ProFUSION would disagree with you: http://profusion.mobi/ It is a "a software development company focused on embedded systems", and several of its employees contribute code and ideas for systemd, so they also use udev. For embedded systems. The idea that udev "is simply to large" is simply incorrect, I believe. 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-dev] Re: udev <-> mdev
On Fri, Jul 13, 2012 at 8:28 PM, Michael Mol wrote: > On Fri, Jul 13, 2012 at 9:22 PM, Walter Dnes wrote: >> On Sat, Jul 14, 2012 at 03:41:36AM +0300, Maxim Kammerer wrote >>> On Sat, Jul 14, 2012 at 3:13 AM, Walter Dnes wrote: >>> > Do you realize this would effectively kill linux in the embedded >>> > device area? Udev, even without the systemd code, is simply to large >>> > for embedded devices. >>> >>> What's ?too large?? Udev already looks pretty small to me (116k udevd, >>> 50k libudev, 500k resident memory), and I didn't even try compiling it >>> with all extra features switched off. If that's too large for an >>> embedded device, does that device really need (or can handle) anything >>> more than devtmpfs? >> >> What does "equery depgraph" show for udev? Since I don't have udev >> installed, I can't check it here. [snip] > sys-fs/udev-186: > [ 0] sys-fs/udev-186 > [ 1] dev-libs/glib-2.30.3 > [ 1] dev-libs/gobject-introspection-1.30.0-r2 > [ 1] sys-libs/libselinux-2.1.9-r1 > [ 1] sys-apps/kmod- > [ 1] sys-apps/util-linux-2.20.1-r2 > [ 1] dev-util/gperf-3.0.4 > [ 1] dev-util/intltool-0.50.2 > [ 1] virtual/pkgconfig-0 > [ 1] virtual/os-headers-0 > [ 1] dev-util/gtk-doc-1.18-r1 > [ 1] sys-devel/automake-1.11.1 > [ 1] sys-devel/automake-1.12.1 > [ 1] sys-devel/autoconf-2.68 > [ 1] sys-devel/libtool-2.4-r1 > [ 1] sys-apps/hwids- > [ 1] sys-fs/udev-init-scripts- A lot of that is optional. The only hard dependencies are: >=sys-apps/kmod-5 >=sys-apps/util-linux-2.20 dev-util/gperf >=dev-util/intltool-0.40.0 virtual/pkgconfig virtual/os-headers Everything else is optional. I repeat: the idea that udev is somewhat "bloated" or "fat" is really incorrect. 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-dev] Re: udev <-> mdev
On Fri, Jul 13, 2012 at 9:32 PM, Canek Peláez Valdés wrote: [snip] > A lot of that is optional. The only hard dependencies are: > >>=sys-apps/kmod-5 >>=sys-apps/util-linux-2.20 > dev-util/gperf >>=dev-util/intltool-0.40.0 > virtual/pkgconfig > virtual/os-headers > > Everything else is optional. I repeat: the idea that udev is somewhat > "bloated" or "fat" is really incorrect. Little correction: inherit autotools brings things like automake and libtool, but then again, almost *every* Gentoo installation has those. 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-dev] Re: udev <-> mdev
On Sat, Jul 14, 2012 at 12:35 AM, Sylvain Alain wrote:
> Hi all, about the Mdev stuff, Slashbeast from Funtoo.org started that
> project a while ago.
>
> https://github.com/slashbeast/mdev-like-a-boss
>
> I think that it's actually working pretty good on his box.
>
> Some Coredevs from Funtoo are actually running with that stuff.
I don't think anybody has ever suggested that it's not possible to run
mdev instead of udev: as Walter has proved, it is indeed possible.
The question Olivier and William are making is (if I understand
correctly) if you don't need the features of udev, then why not use
only devtmpfs. I think everyone agrees that mdev doesn't have (and
probably never will nor want) all the features that udev has.
Seeing all the trouble some people have taken to make their systems
work with mdev just to avoid having to use an initramfs, I really
wonder how much effort it would have taken the simple task of learning
one step more when updating kernels and switch to use an initramfs.
Then again, everyone is entitled to work in the features (or
anti-features) they want. It is FLOSS after all.
Just the 0.02 ${CURRENCY} of a happy udev/systemd user (I'm really
happy the merged the two project trees).
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-dev] Re: udev <-> mdev
On Sat, Jul 14, 2012 at 4:02 PM, Peter Stuge wrote: [snip] > Anyone who tries to argue that initramfs would be good for me to > have on my systems should brace themselves for a mouthful of foul > swedish language coming their way! ;) I don't think anyone has argued it's "good" for anyone. An initramfs it's just now the only supported way (by udev and systemd) to have a separated /usr partition. If your /usr is in the same partition as /, then udev and systemd supports your configuration *without* an initramfs. I have it like that in a couple of servers, and actually I only use an initramfs in my laptop and desktop because I like plymouth. If your /usr is in a separate partition as /, and you don't want to use an initramfs, you're free to do so. Only then udev (and systemd, if you use it) will not support your configuration, and any problem you encounter will be ignored in their mailing lists/bugzillas. 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-dev] Opinion against /usr merge
On Wed, Jul 18, 2012 at 8:18 AM, Richard Yao wrote: > On 07/18/2012 04:10 AM, Michał Górny wrote: >> On Tue, 17 Jul 2012 23:54:16 -0400 >> Richard Yao wrote: [snip] >>> The difference is simple. You put stuff into /sbin when you do not >>> want regular users to be able to select it via tab completion by >>> default. >> >> Now put that definition into my cold logic brain. > > That was meant as a joke, although the irony is that it is true. So, you are rationalizing a posteriori an original irrational decision. Understanding the bin, sbin, usr/bin , usr/sbin split: http://lists.busybox.net/pipermail/busybox/2010-December/074114.html "The /bin vs /usr/bin split (and all the others) is an artifact of this, a 1970's implementation detail that got carried forward for decades by bureaucrats who never question _why_ they're doing things. It stopped making any sense before Linux was ever invented, for multiple reasons" I don't mind the merge of /bin, /usr/bin, /sbin and /usr/sbin; moreover, I want an even more radical change: /usr -> /System /home -> /Users /etc -> /Config Why should we care about ancient filesystems that didn't supported long paths, and therefore we got stuck with /usr since we didn't wanted to waste another *single* character to make it /user? Let that silly legacy stuff die. Keep symbolic links to the old directories for compatibility reasons, if you want to (modern software should not need it anyhow), and move on. Remember /usr/X11R6? We kept a /usr/X11R6 -> /usr link for years. Do you miss it? I surely not. 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-dev] Opinion against /usr merge
On Wed, Jul 18, 2012 at 11:13 AM, Hobbit wrote: >> Why should we care about ancient filesystems that didn't supported >> long paths, and therefore we got stuck with /usr since we didn't >> wanted to waste another *single* character to make it /user? > > Because of it's original name: "UNIX System Resources" (usr). As William pointed out, this is just another silly rationalization done after the fact. But, just for argument's sake, lets suppose that "usr" was named like that because it was the acronym for "UNIX System Resources". *Who cares about that now?* It was 43 years ago. My cellphone is thousands of times faster than the PDP-7 Unix was originally developed for, and it has millions of times more storage. The length restrictions imposed on system directories are completely superfluous now. All the arguments for keeping /bin, /sbin, /usr/bin, and /usr/sbin separated are really instances of the Chewbacca defense [1]. They just don't make any sense. If upstream projects want to move everything to one location, Gentoo should follow suit. If enough Gentoo devs (as others had argued) want to waste their efforts in maintaining this artificial and silly division between /bin, /sbin, /usr/bin, and /usr/sbin, it is of course their prerogative. But it must be clear that all the rationale behind said division was invented after the fact, and (as Rob Landley said in his email [2]) maintained "for decades by bureaucrats who never question _why_ they're doing things". Regards. [1] http://en.wikipedia.org/wiki/Chewbacca_defense [2] http://lists.busybox.net/pipermail/busybox/2010-December/074114.html -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-dev] Opinion against /usr merge
On Wed, Jul 18, 2012 at 1:53 PM, Michael Mol wrote: > On Wed, Jul 18, 2012 at 2:47 PM, Alec Warner wrote: [snip] >> Debian uses initramfs-tools... > > AFAIK, neither genkernel nor dracut were expected to get tied to the > Gentoo update process. Has that changed? The kernel you are running (if you update your machine) is not tied to the Gentoo update process. The *source code* gets installed, but the kernel source remains unchanged in /usr/src/whatever. It's the user responsibility to configure, compile, and install the kernel (and then update LILO, grub-legacy or GRUB2). It can be automated with (ta-da) genkernel, but it's not "tied to the Gentoo update process". I really don't see that much difference with needing to also update the initramfs, if needed. Because, besides, if your /usr is not in a different partition, you don't even *need* an initramfs. In that case not using an initramfs is supported by all upstreams. 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-dev] Opinion against /usr merge
On Wed, Jul 18, 2012 at 2:12 PM, Michael Mol wrote: > On Wed, Jul 18, 2012 at 3:03 PM, Canek Peláez Valdés wrote: >> On Wed, Jul 18, 2012 at 1:53 PM, Michael Mol wrote: >>> On Wed, Jul 18, 2012 at 2:47 PM, Alec Warner wrote: >> [snip] >>>> Debian uses initramfs-tools... >>> >>> AFAIK, neither genkernel nor dracut were expected to get tied to the >>> Gentoo update process. Has that changed? >> >> The kernel you are running (if you update your machine) is not tied to >> the Gentoo update process. The *source code* gets installed, but the >> kernel source remains unchanged in /usr/src/whatever. It's the user >> responsibility to configure, compile, and install the kernel (and then >> update LILO, grub-legacy or GRUB2). It can be automated with (ta-da) >> genkernel, but it's not "tied to the Gentoo update process". >> >> I really don't see that much difference with needing to also update >> the initramfs, if needed. > > What if your DNS resolver in your rescue shell has a vulnerability? > What if wget, links or whatever network tools you use during recovery > have a vulnerability? > > These are tools which are commonly placed in initramfs. First of all, none of this has nothing to do with the discussion at hand. Second, I don't know what kind of initramfs you are familiar with, but mine has nothing network related, and I don't see *any* reason to include *anything* network related to an initramfs. >> Because, besides, if your /usr is not in a different partition, you >> don't even *need* an initramfs. In that case not using an initramfs is >> supported by all upstreams. > > And what of /var? /opt? What about them? Again, what it has this anything to do with our current discussion? > The problem with the /usr merge upstream is > that someone didn't think things through when they pushed it, and the > same reasoning used to justify it easily justifies changing the way > /var and /opt are treated. That's pure speculation. Nobody has ever suggested merging /opt nor /var; if I'm mistaken I would love to see even a single link (mail, blog post, IRC discussion) were it was at least mentioned as a good idea to do the same with /opt or /var. I'm pretty sure you don't have any. 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-dev] Opinion against /usr merge
On Wed, Jul 18, 2012 at 2:18 PM, Michael Mol wrote: > On Wed, Jul 18, 2012 at 3:05 PM, Rich Freeman wrote: >> On Wed, Jul 18, 2012 at 2:53 PM, Michael Mol wrote: >>> AFAIK, neither genkernel nor dracut were expected to get tied to the >>> Gentoo update process. Has that changed? >> >> We don't even update kernels as part of the regular update process, >> let alone initramfs systems. >> >> In general you update them together. >> >> The only issue I could see is if problems arise if you have a >> different version of udev in your initramfs than on your system. I >> don't know if that actually causes problems. For the most part after >> the system is booted the initramfs is done its job. > > The most widely touted benefit I've heard for initramfs is its > capability to ease system recovery in case, e.g. a critical filesystem > refuses to mount. With recovery roles come recovery tools, which > quickly extends network-aware tools and a security attack surface. The real benefit is that it allows you to mount any partition, if the tools to mount it live in the same partition. Recovering tools can be put in the initramfs, but I don't think nobody actually thinks that this is the "most widely touted benefit". Again, citation please. > Hence why I tend to feel that if an initramfs is going to become the > go-to solution for bootstrapping userland, it's important to consider > the difficulties of keeping the packed tools up-to-date; it's not just > a bootstrap tool, it's also the first recovery option a sysadmin > faces. If you keep your initramfs synchronized (which is easily done with dracut, for example), that problem goes away. 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-dev] RFC: virtual/libudev
On Thu, Jul 26, 2012 at 4:44 PM, Peter Alfredsen wrote: > On Wed, Jul 11, 2012 at 11:04 PM, Michał Górny wrote: >> On Wed, 11 Jul 2012 15:27:41 -0400 >> Mike Gilbert wrote: >> >>> Personally, I think a consolidated systemd/udev package is the best >>> way to go here. >> >> A consolidated package means that: >> >> - every change made by udev developers would have to be reviewed by >> systemd team to make sure it doesn't break systemd. udev developers >> don't use systemd; >> - every change made by systemd developers would have to be reviewed by >> udev team to make sure it doesn't break openrc. systemd developers >> usually don't run openrc; >> - udev developers will force me to use eclasses they like and force >> their coding style on me; >> - i will force eclasses I like and my coding style on udev developers; >> - new udev wouldn't be able to be stabilized without systemd being >> stabilized at the same time (and I don't really think systemd is in >> any condition to go stable), >> - there will be a few random flags which will either work or not, >> depending on a state of magical switch flag, >> - and after all, the ebuild will be basically one big use-conditional. > > So, since this is blocking up development and people actually solving > things, could we just have virtual/udev and be done with it? Upstream > obviously reneged on their promise to make the component parts > buildable separately, so the virtual seems like the only sane choice > right now. Just to clarify, udev/systemd never promised "to make the component parts buildable separately". They promised: "we will be supporting this for a long time since it is a necessity to make initrds (which lack systemd) work properly. Distributions not wishing to adopt systemd can build udev pretty much the same way as before, however should then use the systemd tarball instead of the udev tarball and package only what is necessary of the resulting build." Where "package only what is necessary" being the important part for Gentoo. http://lwn.net/Articles/490413/ Certainly they don't care about source-based distributions like Gentoo, but they never promised "to make the component parts buildable separately". Anyway, I also support the virtual/udev, since it's the only way for us systemd users to not build udev twice. 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-dev] Re: RFC: virtual/libudev
On Thu, Jul 26, 2012 at 9:37 PM, Duncan <1i5t5.dun...@cox.net> wrote: [ snip ] > 9) Otherwise, at very minimum, they're failing the "build udev pretty > much the same as before" ./configure make make install You fail to see the matter from their POV. They don't care (that much) about building, because the distributions they care about use binary prebuilt packages. In that sense, "build udev pretty much the same as before" is the holly trinity of "./configure; make; make install". Otherwise the part about "package only what is necessary" has not that much sense. Which again leads to the "please, add a virtual/udev" so the people using systemd don't need to built udev twice. 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-dev] Questions about SystemD and OpenRC
On Thu, Aug 9, 2012 at 3:42 AM, Luca Barbato wrote: [snip] > Repeat after me: having your first process require anything more than > libc is stupid and dangerous. No, it's not. You can (and should) depend on whatever libraries helps to achieve the desired goals. If one of the libraries has a bug, guess what? It should be fixed. And then you repeat until all the used libraries are as stable as libc (or more, if possible), and then the statement that "having your first process require anything more than libc is stupid and dangerous" makes no sense at all. (As a side note, I would like to see the bugrate of libpthread, libudev, libpam, libaudit, libcap, libdbus, etc. I'm pretty sure the latest versions are pretty much rock solid). That's in part what I like the approach taken by systemd (and PulseAudio, by the way); it wants to be a proper solution, and if in using something else they detect a bug, they push to get the bug fixed in the external library (or the kernel sometimes). They don't "workaround" real problems. It's the only way to guarantee that the *whole* stack (not only libc, or the kernel) actually works as it should. So yes, PID 1 should use whatever libraries it makes sense to use, and if there are bugs in them *they should get fixed*. Otherwise lets program everything in assembler, because maybe gcc has a bug somewhere. > Once that concept gets accepted then we could discuss about why > reinventing shellscript may not be that sound and other less glaring, > horrid and appalling design choices. The didn't reinvent shellscript; they replaced it with unit files. That's the best design choice about systemd, IMHO: the unit files say *what* a service should do, not *how*. And besides, you can still use shellscript if your daemon is so fucked up that a regular unit file doesn't cover your case. You should fix your daemon, really; but the option to use shellscript is still there. > Most ideas behind systemd are interesting, their current implementation > is sometimes completely wrong and given the experience with pulseaudio > we all know that they won't change even if you provide code for it. Really? I'm subscribed to the systemd ML, and the author accept all kind of contributions. If they don't agree with one in particular they explain why and the discuss a compromise if necessary. Doing the following in my git clone of the project: git log --format='%aN' | sort -u | wc shows a total of 337 contributors to systemd. So I really believe that you are talking nonsense in this particular point. > Obviously it is always fun seeing people first say "accept it or fork > it", then "do not keep your fork you are wasting time" once somebody > starts forking and/or working for an alternative. By all means, fork it. Just allow Gentoo users to use udev/systemd as upstream intended. And while we are at it, don't put OpenRC in the dependency list of baselayout, otherwise it gets pulled in (and sysvinit with it) for all systemd users even if we don't use it at all. I maintain a really small overlay to use systemd exclusively in Gentoo, so I don't need to install OpenRC and sysvinit: https://github.com/canek-pelaez/gentoo-systemd-only/ http://xochitl.matem.unam.mx/~canek/gentoo-systemd-only/ 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-dev] Questions about SystemD and OpenRC
On Thu, Aug 9, 2012 at 1:31 PM, William Hubbs wrote: > On Thu, Aug 09, 2012 at 11:12:46AM -0700, Olivier Crête wrote: >> > Most ideas behind systemd are interesting, their current implementation >> > is sometimes completely wrong and given the experience with pulseaudio >> > we all know that they won't change even if you provide code for it. >> >> This is bullshit, if you have good reasoned arguments, Lennart is a very >> reasonable guy, but if you just say "your ideas are shit, you code is >> terrible", then yes, he'll just ignore you. > > Sorry to call you on this one, but that is not the experience I had. > > I proposed adding configure switches to their build system to accomodate > source base distros, such as gentoo, who at times want to use udev > without systemd. I even went out of the way to make sure that I didn't > change their default settings. > > Look at a thread on their ml called minimal builds along with their wiki > page on minimal builds for Lennart's answer. He even went so far as to > say that our package managers are broken, and there was absolutely no > negotiating this point. We are wrong as far as he is concerned. By the same reasoning, Linus is even a bigger asshole. In the kernel they flatly refuse to merge code from a LOT of people; that's their job in the end. I read the thread where you proposed the changes to systemd's build system. I wish it was accepted, but I also understand why they didn't. As I said in other threads, they really don't care for source based distros; and that sucks for Gentoo (and every other source based distro), but it's their call. And it certainly helps them to keep the build system simple, assuming that it would be used only by packagers for binary distros. That doesn't say anything about the design of systemd, which is why I use it; not because of the build system. 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-dev] Questions about SystemD and OpenRC
On Thu, Aug 9, 2012 at 1:57 PM, Ciaran McCreesh wrote: > On Thu, 9 Aug 2012 13:53:34 -0500 > Canek Peláez Valdés wrote: >> That doesn't say anything about the design of systemd, which is why I >> use it; not because of the build system. > > Actually, it's fairly representative of the design of systemd too: it > forces you into a particular monolithic, vertically integrated, tightly > coupled way of doing things, and if you try to deviate from that way, > then you're stuffed. I agree with Greg Kroah-Hartman: I actually like (and want) a "vertically integrated, tightly coupled way of doing things". And of course people who *don't* want that don't have to use it; just don't expect support from the people writing the code for a "vertically integrated, tightly coupled" OS, and don't complain when they reject your contributions when they go against their goals. Or in other words, if you don't want a vertically integrated, tightly coupled system, then use mdev, or Luca's fork of udev; if enough people really want that, they will thrive. 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-dev] Questions about SystemD and OpenRC
On Thu, Aug 9, 2012 at 2:47 PM, Rich Freeman wrote: > On Thu, Aug 9, 2012 at 3:24 PM, Canek Peláez Valdés wrote: >> >> I agree with Greg Kroah-Hartman: I actually like (and want) a >> "vertically integrated, tightly coupled way of doing things". > > Well, if you completely agreed with him you wouldn't be running Gentoo > (or Debian, or other general-purpose distros). He advocates that > ordinary users should use more purpose-driven distros, where all of > this stuff is less of an issue. > > He does make a valid point - I'd never argue that a linux noob should > start with Gentoo. However, obviously I think Gentoo has its place, > and the world would be poorer without it. I don't understand you. Greg is a Gentoo developer; he would never propose for Gentoo to disappear. I don't consider myself (nor any other Gentoo user) an ordinary user; Gentoo is for power users, I believe. That is orthogonal to get a vertically integrated, tightly coupled system, and the advantages of it are independent of how easy to use is the system. The primary advantage (from my point of view) is that we get a unique, robust stack from kernel to userspace, where we don't need to worry about 20 different implementations of the same functionality. I think that's what Greg was talking about, and I agree with that. 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-dev] Questions about SystemD and OpenRC
On Thu, Aug 9, 2012 at 6:00 PM, Walter Dnes wrote: > On Thu, Aug 09, 2012 at 01:44:25PM -0500, Canek Pel??ez Vald??s wrote >> On Thu, Aug 9, 2012 at 3:42 AM, Luca Barbato wrote: >> >> > Obviously it is always fun seeing people first say "accept it or fork >> > it", then "do not keep your fork you are wasting time" once somebody >> > starts forking and/or working for an alternative. >> >> By all means, fork it. Just allow Gentoo users to use udev/systemd as >> upstream intended. And while we are at it, don't put OpenRC in the >> dependency list of baselayout, otherwise it gets pulled in (and >> sysvinit with it) for all systemd users even if we don't use it at >> all. > > Good idea. While we're at it, please also let's not make > systemd/udevd/dbus/pam mandatory. I agree. Systemd is not mandatory; dbus is not mandatory, and thanks to your efforts udev is not mandatory, right? I don't know about PAM, but I'm not opposed for it to not being mandatory. So lets stop making OpenRC mandatory, and besides in a completely artificial way: nothing really depends on functionalitty provided by OpenRC. So let people make their OpenRC+mdev systems without systemd, and let people make their systemd+udev systems without OpenRC. Everybody wins. 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-dev] Questions about SystemD and OpenRC
On Tue, Aug 14, 2012 at 5:31 AM, Rich Freeman wrote: > On Mon, Aug 13, 2012 at 11:24 PM, Greg KH wrote: >> On Thu, Aug 09, 2012 at 03:47:19PM -0400, Rich Freeman wrote: >>> On Thu, Aug 9, 2012 at 3:24 PM, Canek Peláez Valdés >>> wrote: >>> > >>> > I agree with Greg Kroah-Hartman: I actually like (and want) a >>> > "vertically integrated, tightly coupled way of doing things". >>> >>> Well, if you completely agreed with him you wouldn't be running Gentoo >>> (or Debian, or other general-purpose distros). He advocates that >>> ordinary users should use more purpose-driven distros, where all of >>> this stuff is less of an issue. >> >> That is not what I said, or mean at all. >> >> Given that I'm a Gentoo developer, and have been for a very long time, I >> find it very strange that you would think otherwise. > > I did clarify my post in a reply, linking to your post and of course > stating that you could clarify. Your words were: "I just don't > think it can be done well, sorry, which is why I strongly recommend > tightly-coupled distros for desktops for anyone (like Fedora or > openSUSE or Ubuntu), and Debian or Gentoo only for servers or embedded > systems where you know exactly what you are putting together, and why > you are doing it that way." > > I'm not a big fan of putting words in mouths, so if I misread that > than I apologize. In any case, I can't really argue much with that > statement as-is, although I'd probably carve out an additional > exception for enthusiasts or those who otherwise like to tinker under > the hood. > > If you want strong vertical integration, you probably will never get > as much of it with Gentoo as you might get with a tightly-coupled > distro. You can get as much vertical integration with Gentoo as with any other distro. The problem (and I think this is the point Greg is trying to make) is that it will be harder (not impossible, just harder) if most of Gentoo developers really believe that every single possible combination of hardware, software, init systems, and even OS kernels should be supported. I myself believe that any Gentoo dev should support whatever the hell s/he wants to; I'm just interested in that if some of us want vertical integration, it should be easier to get. Right now every single Gentoo install from the official tree has OpenRC installed, because is pulled in by baselayout, and OpenRC also pulls sysvinit. And I'm not talking about some text files (even if they are executables) in /etc/init.d; I'm talking about executable binaries and libraries in every Gentoo install, even if the user has systemd, and they don't use OpenRC/sysvinit at all. Not to mention that they need to compile both packages if they ever upgrade (which doesn't happen that much, I agree). 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-dev] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)
On Sun, Nov 18, 2012 at 1:25 AM, Matt Turner wrote: > On Sat, Nov 17, 2012 at 11:05 PM, Walter Dnes wrote: >>> As I posted elsewhere, working on a project based on "hate" only lasts >>> so long. I should know, that's the reason I started udev in the first >>> place over 9 years ago. >> >> The Xfree86 people generated a lot of hate, just like Sievers and >> Poettering. Xorg hasn't burned out yet. > > Let's be fair. The Xorg fork was done by a lot of really competent > professional developers who had been developing XFree86 for a long > time. And it was made because it had become almost impossible to work with the main developer of XFree86; not because of hate, but by very clear and valid technical reasons The systemd+udev project instead has code contributed by every major Linux distribution, and many small ones. Even Ubuntu hasn't talked about forking udev, and they keep sending patches, even with their staunch commitment to Upstart. This is what a developer from Arch Linux (which has just made the decision to move to systemd) has to say about it: "... systemd is a cross-distro project: every major and many, many minor distros have had people contributing to systemd. last i heard even two debian devs have commit access to the repo, among many others. systemd upstream is very accommodating of different needs and different use-cases (as long as they are presented on technical grounds) and have been a pleasure to work with so far. We are getting the joint experience of a lot of people/projects who have worked on different init systems for a long time, I think this is one of the most important "features" one could have." https://bbs.archlinux.org/viewtopic.php?pid=1149530#p1149530 Seeing some people comparing udev to XFree86 is one of the more bizarre things coming out from this fork, and that's saying. However, I agree with Doug that anyone should code whatever they want to code. Who knows, maybe something interesting would come off from this fork, and it certainly doesn't affect us happy Gentoo+systemd+udev users. 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-dev] Making systemd more accessible to "normal" users
On Wed, May 8, 2013 at 9:18 PM, Walter Dnes wrote: > On Wed, May 08, 2013 at 10:31:21PM +0530, Arun Raghavan wrote > >> The overhead of the files' presence is trivial, and most users won't >> care. Those who do care have a trivial line to add in make.conf, and >> that is for the small number of people who share your vitriol for the >> systemd project. > > Then howsabout a "units" ebuild that installs all available units > files for systemd users? "The overhead of the files' presence is > trivial, and most systemd users won't care". > > The thread title says it all... normal Gentoo users don't use systemd. For now. 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-dev] Re: Making systemd more accessible to "normal" users
On Sun, May 19, 2013 at 9:34 AM, Peter Stuge wrote: > J. Roeleveld wrote: >> I don't see how this will avoid the issue of a limited amount of >> inodes. >> That is what I usually run out of before the disk is full when >> storing lots of smaller files. > > I guess the number of unit files is on the order of hundreds, Full GNOME as long > as you haven't configured an INSTALL_MASK to avoid installing them. > (Why haven't you?) > > Are you saying that a few hundred inodes more will break many systems? > > It doesn't seem very likely to me. > > > //Peter > -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-dev] Re: Making systemd more accessible to "normal" users
On Sun, May 19, 2013 at 9:34 AM, Peter Stuge wrote: > J. Roeleveld wrote: >> I don't see how this will avoid the issue of a limited amount of >> inodes. >> That is what I usually run out of before the disk is full when >> storing lots of smaller files. > > I guess the number of unit files is on the order of hundreds (Sorry, sent email before it was ready). Laptop running full GNOME: # find /usr/lib/systemd/system -type f | wc 154 1547012 Server running Apache+MySQL+Mailman+Squid+Other services: # find /usr/lib/systemd/system -type f | wc 121 1215560 And as you said, you can always use INSTALL_MASK. If 154 files are going to deplete your inodes, I think your problem lies somewhere else. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: Re: [gentoo-dev] Re: Making systemd more accessible to "normal" users
On Tue, May 21, 2013 at 3:03 AM, Daniel Campbell wrote: > On 05/19/2013 01:05 PM, Canek Peláez Valdés wrote: >> On Sun, May 19, 2013 at 9:34 AM, Peter Stuge wrote: >>> J. Roeleveld wrote: >>>> I don't see how this will avoid the issue of a limited amount of >>>> inodes. >>>> That is what I usually run out of before the disk is full when >>>> storing lots of smaller files. >>> >>> I guess the number of unit files is on the order of hundreds >> >> (Sorry, sent email before it was ready). >> >> Laptop running full GNOME: >> >> # find /usr/lib/systemd/system -type f | wc >> 154 1547012 >> >> Server running Apache+MySQL+Mailman+Squid+Other services: >> >> # find /usr/lib/systemd/system -type f | wc >> 121 1215560 >> >> And as you said, you can always use INSTALL_MASK. If 154 files are >> going to deplete your inodes, I think your problem lies somewhere >> else. >> >> Regards. >> -- >> Canek Peláez Valdés >> Posgrado en Ciencia e Ingeniería de la Computación >> Universidad Nacional Autónoma de México >> > > That's missing the point. If you don't run systemd, having unit files is > pointless. Thankfully there's INSTALL_MASK and whatnot, but that seems > like a hack instead of something more robust. Why include systemd unit > files (by default, with no systemd USE flag, thanks to the council...) > on a system that's not using it? 154 files isn't negligible unless > you're flippant with your system and don't care about bloat. Unused > software sitting around *is* a waste of disk-space. Unit files are not software; they are data. And I believe you are the one missing the point. I don't run OpenRC; I don't need no files in /etc/init.d. But you don't see me (nor any other systemd user) complaining about pointless scripts in /etc/init.d. I just put /etc/init.d in INSTALL_MASK and go on with my life. Non-systemd users should do the same for files under /usr/lib/systemd, if they really are that worried about systemd "infecting" their systems. Complaining about a council-decided policy (and, I believe, backed up by the developers that matter, including the OpenRC maintainers) is just beating on a dead horse. Get over it. > Some people (like myself) came to Gentoo to avoid putting systemd on > their systems and to make use of the great choice that Gentoo allows. > This push to make systemd a "first level citizen" or whatever reeks of > marketing. If Gentoo is about choice, then systemd is one of those choices. And systemd will become a first class citizen inside Gentoo, like it or not. Support for it has been getting better and better, and more and more Gentoo users are running with systemd. If some fundamentalists users don't want even one file in their systems with "systemd" on their paths, they can install eudev/mdev, put the necessary directories in INSTALL_MASK, and do the extra work. If some other fundamentalists users (like myself) don't want even one OpenRC related file on our systems, we can create an overlay to remove the dependency of baselayout on OpenRC, put /etc/init.d in INSTALL_MASK, and do the extra work. Neither case covers the average systemd/OpenRC user, who doesn't care about a few scattered files in /etc/init.d nor /usr/lib/systemd, and just want to run her machine with the init system of her choice. If Gentoo is really about choice. > If there is desire among users for unit files, they can > contact upstream or maintain their own set of unit files. It's not like > they're hard to write. So, Gentoo is about choice, but only for the choices you agree with. Great. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: Re: Re: [gentoo-dev] Re: Making systemd more accessible to "normal" users
On Wed, May 22, 2013 at 9:39 PM, Daniel Campbell wrote: > On 05/20/2013 10:34 PM, Canek Peláez Valdés wrote: >> On Tue, May 21, 2013 at 3:03 AM, Daniel Campbell wrote: >>> On 05/19/2013 01:05 PM, Canek Peláez Valdés wrote: >>>> On Sun, May 19, 2013 at 9:34 AM, Peter Stuge wrote: >>>>> J. Roeleveld wrote: >>>>>> I don't see how this will avoid the issue of a limited amount of >>>>>> inodes. >>>>>> That is what I usually run out of before the disk is full when >>>>>> storing lots of smaller files. >>>>> >>>>> I guess the number of unit files is on the order of hundreds >>>> >>>> (Sorry, sent email before it was ready). >>>> >>>> Laptop running full GNOME: >>>> >>>> # find /usr/lib/systemd/system -type f | wc >>>> 154 1547012 >>>> >>>> Server running Apache+MySQL+Mailman+Squid+Other services: >>>> >>>> # find /usr/lib/systemd/system -type f | wc >>>> 121 1215560 >>>> >>>> And as you said, you can always use INSTALL_MASK. If 154 files are >>>> going to deplete your inodes, I think your problem lies somewhere >>>> else. >>>> >>>> Regards. >>>> -- >>>> Canek Peláez Valdés >>>> Posgrado en Ciencia e Ingeniería de la Computación >>>> Universidad Nacional Autónoma de México >>>> >>> >>> That's missing the point. If you don't run systemd, having unit files is >>> pointless. Thankfully there's INSTALL_MASK and whatnot, but that seems >>> like a hack instead of something more robust. Why include systemd unit >>> files (by default, with no systemd USE flag, thanks to the council...) >>> on a system that's not using it? 154 files isn't negligible unless >>> you're flippant with your system and don't care about bloat. Unused >>> software sitting around *is* a waste of disk-space. >> >> Unit files are not software; they are data. >> >> And I believe you are the one missing the point. I don't run OpenRC; I >> don't need no files in /etc/init.d. But you don't see me (nor any >> other systemd user) complaining about pointless scripts in >> /etc/init.d. I just put /etc/init.d in INSTALL_MASK and go on with my >> life. >> >> Non-systemd users should do the same for files under /usr/lib/systemd, >> if they really are that worried about systemd "infecting" their >> systems. Complaining about a council-decided policy (and, I believe, >> backed up by the developers that matter, including the OpenRC >> maintainers) is just beating on a dead horse. >> >> Get over it. >> >>> Some people (like myself) came to Gentoo to avoid putting systemd on >>> their systems and to make use of the great choice that Gentoo allows. >>> This push to make systemd a "first level citizen" or whatever reeks of >>> marketing. >> >> If Gentoo is about choice, then systemd is one of those choices. And >> systemd will become a first class citizen inside Gentoo, like it or >> not. Support for it has been getting better and better, and more and >> more Gentoo users are running with systemd. >> >> If some fundamentalists users don't want even one file in their >> systems with "systemd" on their paths, they can install eudev/mdev, >> put the necessary directories in INSTALL_MASK, and do the extra work. >> If some other fundamentalists users (like myself) don't want even one >> OpenRC related file on our systems, we can create an overlay to remove >> the dependency of baselayout on OpenRC, put /etc/init.d in >> INSTALL_MASK, and do the extra work. >> >> Neither case covers the average systemd/OpenRC user, who doesn't care >> about a few scattered files in /etc/init.d nor /usr/lib/systemd, and >> just want to run her machine with the init system of her choice. If >> Gentoo is really about choice. >> >>> If there is desire among users for unit files, they can >>> contact upstream or maintain their own set of unit files. It's not like >>> they're hard to write. >> >> So, Gentoo is about choice, but only for the choices you agree with. Great. >> >> Regards. >> -- >> Canek Peláez Valdés >> Posgrado en Ciencia e Ingeniería de la Computación >> Universidad Nacional Autónoma de México >> > > It seems that I've st
Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8
On Fri, Aug 9, 2013 at 7:14 AM, viv...@gmail.com wrote: > On 08/09/13 13:38, Pacho Ramos wrote: >> El vie, 09-08-2013 a las 19:39 +0800, Patrick Lauer escribió: >>> On 08/09/2013 07:26 PM, Tom Wijsman wrote: >>>> On Fri, 09 Aug 2013 19:31:22 +0800 >>>> Patrick Lauer wrote: >>>> >>>>> You just removed the upgrade path for users. >>>> The upgrade path is to install systemd or to implement openrc support. >>>> >>> Invalid upgrade path. >>> >>> "The upgrade path is to install Fedora" is about as reasonable, and also >>> not acceptable. >>> >>> >> The upgrade path is to run systemd, not migrate to fedora. As simply as >> such >> >> > is systemd useful if not run with PID=1 ? Honest question (Answering as a GNOME+systemd user since 2011). AFAIU, systemd is completely useless if it isn't running as PID 1. In particular (and the reason systemd is now a hard requirement for GNOME), logind will not work correctly (if at all) if systemd isn't PID 1. All the cgroups handling (for one) is non existent (or completely different) in OpenRC. 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-dev] Gnome Stabilization 3.6 or 3.8
On Fri, Aug 9, 2013 at 8:54 AM, Michał Górny wrote: > Dnia 2013-08-09, o godz. 14:14:12 > "viv...@gmail.com" napisał(a): > >> On 08/09/13 13:38, Pacho Ramos wrote: >> > El vie, 09-08-2013 a las 19:39 +0800, Patrick Lauer escribió: >> >> On 08/09/2013 07:26 PM, Tom Wijsman wrote: >> >>> On Fri, 09 Aug 2013 19:31:22 +0800 >> >>> Patrick Lauer wrote: >> >>> >> >>>> You just removed the upgrade path for users. >> >>> The upgrade path is to install systemd or to implement openrc support. >> >>> >> >> Invalid upgrade path. >> >> >> >> "The upgrade path is to install Fedora" is about as reasonable, and also >> >> not acceptable. >> >> >> >> >> > The upgrade path is to run systemd, not migrate to fedora. As simply as >> > such >> > >> > >> is systemd useful if not run with PID=1 ? Honest question > > Not a honest question but either honest troll, or you're awfully lazy > and just making noise here. > > So the answer is: yes, it's quite useful when run with PID!=1. It's > called systemd user instance (something OpenRC totally can't handle) > and it can be used to manage user services. I forgot thtat when I answered, but that requires that systemd is also running as PID 1. If I understand the question correctly (and I didn't perceived any "trollism"), it was about if you can install systemd, but run OpenRC as PID 1, and have everything working. In that case, the answer is no. 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-dev] Gnome Stabilization 3.6 or 3.8
On Fri, Aug 9, 2013 at 9:50 AM, Alon Bar-Lev wrote: > On Fri, Aug 9, 2013 at 5:44 PM, Chí-Thanh Christopher Nguyễn > wrote: >> Alon Bar-Lev schrieb: >>> On Fri, Aug 9, 2013 at 3:28 PM, Rich Freeman wrote: >>>> On Fri, Aug 9, 2013 at 7:31 AM, Patrick Lauer wrote: >>>>> You just removed the upgrade path for users. >>>>> >>>> Just install systemd. There really isn't any practical alternative. >>>> Gentoo with systemd is as Gentooish a configuration as Gentoo with >>>> OpenRC, or Gentoo with libav, or Gentoo with emacs. >>> Again, I repeat my-self. >>> >>> Please stop writing these statements! >>> >>> There was no decision to support Gentoo using any other layout than >>> openrc (baselayout). >> >> I think there may be a misunderstanding here. He only said that if you >> want to run Gnome 3.8, then switch to systemd. Because the Gnome team >> will not support any other configuration. >> >> He did not say that everyone should install systemd, nor that you need >> to support such a configuration. > > So users will have gnome working but not any other component? How can > this a good service for users? For the record, everything I use (desktop, laptop, media center, servers, etc.) uses Gentoo with systemd. Several of them doesn't have GNOME (the servers obviously don't even have X). All the "components" in my use cases (which I confess are really standard) work. In my experience, if it works in Gentoo with OpenRC, it will work with systemd (and, IMHO, sometimes better). The other way around is, obviously as per this whole thread, not true. 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-dev] Gnome Stabilization 3.6 or 3.8
On Sat, Aug 10, 2013 at 6:10 PM, Mike Auty wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 10/08/13 23:42, Wulf C. Krueger wrote: >> On 09.08.2013 02:26, Mike Auty wrote: >>> I could be a KDE developer, or a Gentoo documenter, or work on >>> mplayer. All those people are open source contributors and >>> necessary ones, but that doesn't mean that any of them >>> necessarily has the skills or the time to look after udev. Does >>> that invalidate their opinion on the choices of upstream project >>> they rely on? >> >> Yes, it does. > > In that situation then, developers are only developing for themselves? > What's more likely is that they've taken a gamble that most users > will simply accept their changes, which they deem as necessary to move > forward. > > That would be fine if there were alternative options, but as more and > more things are "vertically integrated" the choices made by one > project are knocking over into others. Before I could simply ignore > systemd and choose something else, now I'm having to choose between > using both Gnome and systemd, or neither. > > It is a difficult choice, but just as Gnome has chosen to forsake my > desire for a simplistic init system at the expense of a little boot > speed and some "features" I've never needed in the past, I'm having to > walk away to some other less well developed desktop environment. The > cost of ignoring their users opinions is losing the users themselves. > I don't know how many users they'll have to lose before someone > decides to take the ship in a new direction, but I would like to see > how many they stand to lose, by asking those who care to speak up and > find a way of being heard before the damage is too much to repair... We have been having this discussion since GNOME 3.0 came out, and some would argue that since GNOME 2.0, or even before. The GNOME project will go where the developers of the GNOME project decide to, period. There is MATE if you really want the old GNOME 2, Cinnamon if you only want something similar to the old interface, or KDE/Xfce/E17 if you want to switch. Arguing with the GNOME developers like they don't know what they are doing is pointless at best, and frankly insulting at worst. They thought deeply about the changes that are being made to the desktop, and they discussed it and reached a consensus about what the direction of the project is; you can usually read about in the mailing lists, Planet GNOME, or even watch the videos from the GUADEC presentations. You can of course disagree with that direction: but acting like they, poor things, don't know what they are doing and need that someone go an tell them so they can know "before the damage is much to repair", is quite condescending. People have been predicting the dead of GNOME since before the 1.0 version came out, but right now it has more contributors than ever in the past, and at least half a dozen companies actually pay money to people to work in it, so perhaps they actually know what they are doing. But even if they don't, there are a couple forks you can try or several alternatives you can switch to if "the damage is too much to repair". And at the end of the day, all that code is 100% Free Software, with public repositories with all the history of the components of the project for all the world to see and use. The GNOME developers already made their decision. The GNOME maintainers in Gentoo followed through (like they have been doing in almost every other distro). Now it's up to each user to decide if she keeps using GNOME (and therefore switches, if necessary, to systemd since 3.8), or if she stops using it. Arguing about it is quite useless. Regards from a (very happy, very proudly) GNOME+systemd Gentoo user. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8
On Sun, Aug 11, 2013 at 2:31 AM, Pacho Ramos wrote: > El dom, 11-08-2013 a las 08:41 +0300, Samuli Suominen escribió: >> On 09/08/13 12:51, Pacho Ramos wrote: >> > El vie, 09-08-2013 a las 11:26 +0200, Chí-Thanh Christopher Nguyễn >> > escribió: >> >> Pacho Ramos schrieb: >> >>>> If OpenBSD can do it, then Gentoo can do it, too. So would you accept >> >>>> ebuild >> >>>> patches that make it possible to install Gnome 3.8 without systemd >> >>>> again? >> >>>> Only make it possible, not turn it into a configuration which the Gnome >> >>>> team >> >>>> supports. >> >>> >> >>> We have discussed this some times in the team, the problem is that we >> >>> don't think we should provide "by default" a setup that is not working >> >>> properly: powermanagement, multiseat support and gdm service handling >> >> >> >> I don't say that it should be the default. >> >> >> >>> Also, if that people reports problems, we would >> >>> close them as WONTFIX -> migrate to systemd >> >> >> >> That's what I meant when I wrote not a configuration that Gnome team >> >> supports. >> >> >> >>> - You can ignore the warnings, news and suggestions and, even moving >> >>> from udev to systemd ebuild, keep booting with openRC and using systemd >> >>> as device manager >> >>> - You can put systemd in package.provides to even keep running udev >> >> >> >> The good part about package.provided is that users definitely know that >> >> they >> >> are running an unsupported configuration with it. The bad part is that >> >> putting systemd in package.provided is a bit dangerous, as this can lead >> >> to >> >> udev unmerge on depclean if you are not careful. >> >> >> > >> > This makes me think what is the problem with people moving to systemd as >> > udev provider (even running openrc) :/ >> >> Because sys-apps/systemd is installed in wrong directory structure in /usr >> I still carry systemd in my local overlay instead of using it from >> Portage, just to put it in / as per upstream recommendation :-/ >> We have tried to reach consensus, but there is a disagreement that we >> have left at "We agree that we don't agree." >> >> Pushing that aside, there is also the heavy dependencies of >> sys-apps/systemd in comparison to sys-fs/udev >> > > Maybe the second point could be solved having some kind of "minimal" USE > flag for systemd building it with only the minimum set for running udev > without adding so many dependencies. Regarding the first issue, I have > also seen that will be nearly impossible to reach a consensus because we > are currently in a strange intermediate situation: we don't have a setup > ready to run without /usr but neither /usr merge work :| > > Then, I guess will have to live with this two alternatives more time :/, > but people running Gnome will need to keep /usr mounted and, then, they > won't suffer the first problem of place installation. systemd doesn't support separated /usr without an initramfs, so there is no problem now that GNOME requires it. > Also, the extra > dependencies won't be so "extra" for gnome users, letting them to move > to systemd ebuild easily And there is that. Although the only hard (runtime) dependencies of systemd-206-r3 are: sys-apps/dbus sys-apps/util-linux sys-libs/libcap sys-apps/baselayout sys-apps/hwids Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
[gentoo-dev] Thank you
Hi. TL;DR, this is basically just a THANK YOU to the Gentoo devs, so you can go on your daily business if you don't want to read the rest of it. No biggie. I just want to say THANK YOU to all of our Gentoo developers. I've been using Gentoo since ca. 2002 (damn, that's more than a decade), and I've seen a lot of flamewars and bikeshedding on the -dev mailing list. However, you guys get the job done, and although there are some things that I would like to have sooner (or would have liked to have earlier), in the end the people working keep pushing the necessary changes so the distribution keeps going, and (if so desired) using new and interesting technologies. More importantly, the developers and the bureaucratic structures they have created don't get (too much) in the way of individual or small groups of developers pushing for progress. In general at least; there will be always someone resisting change, but in general Gentoo keeps advancing, and the council and the other bureaucratic structures don't punish people for just wanting to have more new and cool features in the distribution. I've never said Thank You to all our developers in all these years using Gentoo, but after seeing the discussion the Debian CTTE is having related to the default init they should use[1][2][3] (including bureaucratic maneuvers, dilatory tactics, legalese interpretation of their rulings, etc.), I think the time is long overdue for me to do it. Thank you for all the work you guys do and have done. Thank you for not penalize progress. Thank you for not being so rigid. Thank you for keeping the distribution moving and evolving. And finally, just thank you. >From a proud Gentoo+systemd+GNOME 3 user, thank you. Regards. [1] https://lists.debian.org/debian-ctte/2014/01/threads.html [2] https://lists.debian.org/debian-ctte/2014/02/threads.html [3] http://lwn.net/Articles/584227/#Comments -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-dev] systemd + postgresql is non-obvious to me
On Fri, Aug 22, 2014 at 1:07 PM, Rich Freeman wrote:
> On Fri, Aug 22, 2014 at 1:23 PM, Aaron W. Swenson
> wrote:
>> On the whole, I'm displeased with the systemd alternative for
>> controlling PostgreSQL. It's significantly hampered and doesn't allow
>> as much flexibility as the initscript. The major issue being trying to
>> nicely shut down the server instead of jumping straight to murder.
>>
>
> It looks like the package installs a service file provided by
> upstream, so you might want to direct your complaint there unless it
> really is a systemd limitation.
>
> Checking the latest version in portage it calls:
> ExecStop=/usr/@LIBDIR@/postgresql-@SLOT@/bin/pg_ctl stop -D
> ${DATA_DIR} -s -m fast
>
> I'm no postresql expert, but according to the manpage that should
> bring the server to a screeching, but still controlled, halt. Perhaps
> you would prefer setting it to -m smart instead of -m fast.
>
> If so override it in /etc/systemd/system. I generally recommend using
> drop-ins for this, but I'm not sure if doing a drop-in for ExecStop
> will override the existing value, or simply cause systemd to run both
> commands (which means that whichever runs first will control how it
> stops).
It's the same as with ExecStart=; it gets added to a list, and all of
them are executed in the same order as they appear in the unit file.
In a drop-in, you can reset the list like this:
ExecStop=
ExecStop=new_and_only_command_to_be_executed
> Systemd shouldn't begin killing processes without mercy until the
> process invoked in ExecStop terminates, so it should not terminate
> until the process has finished graceful shutdown.
If ExecStop= wasn't specified, systemd would immediaely kill all the
service processes; from [1]: "If this option [ExecStop] is not
specified, the process is terminated immediately when service stop is
requested", which kinda sounds like "jumping straight to murder."
That the upstream unit file is configured otherwise, shows that
PostgreSQL upstream itself thinks that's a bad idea. No fault on
systemd's part.
Regards.
[1] http://www.freedesktop.org/software/systemd/man/systemd.service.html
--
Canek Peláez Valdés
Profesor de asignatura, Facultad de Ciencias
Universidad Nacional Autónoma de México
Re: [gentoo-dev] systemd + postgresql is non-obvious to me
On Mon, Sep 1, 2014 at 10:46 AM, Aaron W. Swenson wrote: > On 2014-08-22 14:07, Rich Freeman wrote: >> On Fri, Aug 22, 2014 at 1:23 PM, Aaron W. Swenson >> wrote: >> > On the whole, I'm displeased with the systemd alternative for >> > controlling PostgreSQL. It's significantly hampered and doesn't allow >> > as much flexibility as the initscript. The major issue being trying to >> > nicely shut down the server instead of jumping straight to murder. >> > >> >> It looks like the package installs a service file provided by >> upstream, so you might want to direct your complaint there unless it >> really is a systemd limitation. > > Delayed response, I've been looking into this as I've been working on > unifying the ebuilds, but I can't find where upstream is providing the > systemd unit. The only one I have is the one we've made. It is included in: http://dev.gentoo.org/~titanofold/postgresql-initscript-2.6.tbz2 It doesn't says who the author is; but he or she was the one deciding to wait five minutes (TimeoutSec=300) for the server to stop (and also to disable the OOM killer: OOMScoreAdjust=-1000). Regards. -- Canek Peláez Valdés Profesor de asignatura, Facultad de Ciencias Universidad Nacional Autónoma de México
[gentoo-dev] Re: [gentoo-dev] Bug №504116, /etc/init.d/functions.sh
On Sat, Dec 20, 2014 at 5:35 AM, Сергей wrote: > There is a bug (https://bugs.gentoo.org/show_bug.cgi?id=504116). > Though it had been reported long time ago, many bugs, which this bug > depends on, are not even confirmed (see my comment: > https://bugs.gentoo.org/show_bug.cgi?id=504116#c3). There is also no > response to my comment, seems like all the activity about this bug has > stopped. Is it so? It hasn't stopped, is just that the devs don't exactly know how to continue. In particular, with glibc and all of the toolchain packages, there is a lot of historical cruft in the ebuilds and associated eclasses. The devs are discussing how to move on forward with this; the issue of /etc/init.d/functions.sh is secondary or even tertiary to this. Check [1] for an example thread of the kind of discussion happening. I've been using my own functions.sh file for years. At its core, is basically a cosmetic issue; functions.sh never provided nothing more than a few shell functions to print pretty messages on the console. Regards. [1] http://thread.gmane.org/gmane.linux.gentoo.devel/93994/ -- Canek Peláez Valdés Profesor de asignatura, Facultad de Ciencias Universidad Nacional Autónoma de México
Re: [gentoo-dev] Installing systemd units with gx86 packages
On Sun, Apr 24, 2011 at 4:35 PM, William Hubbs wrote:
> On Sun, Apr 24, 2011 at 09:36:30AM +0200, Michał Górny wrote:
>> Fellow devs,
>>
>> I've started working on bringing systemd to Gentoo [1] lately,
>> and I think it is important to raise the aspect of systemd unit
>> inclusion in various packages in gx86 ASAP.
>>
>> The number of packages coming with systemd units is growing rapidly
>> recently, and that especially applies to freedesktop packages.
>> One side effect of that is that these packages treat systemd
>> as an automagic dependency, installing systemd units whenever its
>> pkgconfig file is installed. I already opened two bugs on that [2,3]
>> but there would be much more...
>
> I think the better way to handle this will be to patch the build systems
> to not make this an automagic dependency and send those patches
> upstream.
>
> http://www.gentoo.org/proj/en/qa/automagic.xml
>
> I'm not a member of qa, but I agree with this position on automagic
> dependencies.
I'm speaking as a simple user, but I don't think the systemd unit
files qualify as automagic dependencies as described by the QA
document. In the first place, as Michael pointed out, we can disable
them with --without-systemdsystemunitdir, so there is no magic at all.
In the second place, the usual Gentoo way of enabling OpenRC services
is to *add* init.d scripts in the ebuild, and this is completely
orthogonal to a package installing a systemd unit file (the presence
of the later does not matter to OpenRC at all). And finally, the idea
of systemd is to be a completely distro-agnostic init system, without
the multiple failures of SysV, and without the one-company-rule of
Upstart; this seems to be actually working, hence a lot of downstream
packages are willing (and eager) to ship systemd unit files. The init
scripts belong to the packages, they know best how the
service/whatever needs to be run.
I'm using Gentoo+systemd since a couple of months, and it works
incredible well. And I really like the idea of freeing the rather
precious Gentoo-developers time off of writing init scripts.
Just my 0.02 ${CURRENCY/100}.
> William
--
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México
Re: [gentoo-dev] Re: RFC: Do we still want group based permissions for storage and power devices in light of ConsoleKit and Policykit?
On Mon, May 16, 2011 at 8:13 PM, Duncan <1i5t5.dun...@cox.net> wrote:
[...]
> User perspective...
For the sake of having a user with a different point of view, let me
say that I firmly believe the new *kit daemons (along things like
pulseaudio, systemd, GNOME 3, KDE 4) are the future, and Gentoo should
drop support for older technologies as soon as possible. Emphasis in
"as soon as possible", not "today".
The groups model was good, 40 years ago. But it's restrictive (a group
gets all or nothing), inflexible, and it difficults the implementation
of nice GUIs that take care of them. And it's not only my point of
view: the people in the kernel, in freedesktop, and in GNOME and KDE
think similarly, and that's why this pletora of new *kit programs (and
related new technologies) are becoming mandatory to run not only
desktop workstations, but also servers and embeded systems.
And actually that's the most powerful reason for Gentoo to drop
support for the older technologies: The people who actually *writes*
the code are starting to drop support for them.
We should embrace the new technologies. Sure, sometimes a new
technology would turn out to be a mistake (HAL), or it would take a
while to get really good (pulseaudio, ALSA replacing OSS). But when
they finally get "there", it's worth every step of the way.
Of course they can take a while to get "there", and that's why I'm
saying that the support must be dropped "as soon as possible", not
"today". But eventualy said support must be dropped: The maintainers
of the code would not support it, so I don't see a reason to waste the
Gentoo developers time doing it.
I know a lot of people would be 100% against what I'm saying, and they
will be very vocal about it. But I just want to leave note that there
are people like me who actually want to embrace this new technologies,
and that we are willing to do the testing and suffer the pains of
trying the new technologies.
And I say this as a user of Unix since 1996, and writing this email in
my laptop running Gentoo with the systemd and GNOME 3 overlays
installed at the same time, and loving how the shape of the future
looks like.
Just my ${CURRENCY/100}.
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-dev] Suggestion for getting rid of udev
On Wed, Oct 12, 2011 at 6:09 AM, Walter Dnes wrote:
>> Goodbye desktop users then.
>>
>> We recently dropped HAL. Now all the magic that was done by HAL (and
>> required udev anyway) is done through udev directly.
>
> My system worked just fine before HAL was introduced, thank you. I
> always had sys-apps/hal and sys-apps/dbus in /etc/portage/package.mask
> and my system continued to work just fine, thank you.
This is not about *your* system, it's about the general Gentoo
community systems. And in most cases, the functionality that mdev
provides is not even a fraction of what udev can do, like it or not.
I have a pair of bluetooth headphones; I turn them up and set them to
pair with something, and gnome-shell in GNOME 3 right away asks me if
it's OK to pair with them. I say yes, and the headphones are
immediately available in the desktop; thanks to PulseAudio, I can
transfer all my apps (or only some of them) to the headphones, without
even needing to pause the streams.
All of this without a single modification to a config file. It just
works. And that is thanks to udev (among several other pieces of the
stack).
mdev is designed for embedded systems (like busybox). By design it
cannot handle of the cases that udev handles, and so it is not suited
for a general purpose distribution like Gentoo. If you wan to try to
use it, that's your right of course. But don't ask the Gentoo devs to
do the work for you; do it yourself. And be aware that anyway the devs
will choose to stick with udev (like many have already said), because
they have to think about the general case, not an arbitrary particular
case.
Just the .02 ${CURRENCY} from an old Gentoo user happy with systemd,
dracut, udev, dbus, GNOME 3, and other really cool new technologies.
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-dev] Suggestion for getting rid of udev
On Thu, Oct 13, 2011 at 10:02 AM, Mike Frysinger wrote: > On Thursday 13 October 2011 12:30:06 Arun Raghavan wrote: >> While I've seen a lot of whining about this whole issue, I certainly >> haven't been seen any effort to actually solve the problem within the >> existing framework. For example, if someone cares enough, why not >> write a wrapper script to track down the programs and libraries at >> runtime that actually do use /usr so it's easier to say "these >> packages install rules that need / and /usr on the same partition". > > (1) udev has provided a workaround of sorts for this already: udevadm trigger > --type=failed. this is the udev-postmount init.d script. (2) it's fairly > trivial to locate most (all?) the failing rules with a single grep: grep /usr > -R /lib/udev/rules.d/. If this comment is true (haven't looked at the code): https://bugs.gentoo.org/show_bug.cgi?id=375263#c23 that trigger has been removed from udev. 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-dev] Suggestion for getting rid of udev
On Thu, Oct 13, 2011 at 11:55 AM, Canek Peláez Valdés wrote: > On Thu, Oct 13, 2011 at 10:02 AM, Mike Frysinger wrote: >> On Thursday 13 October 2011 12:30:06 Arun Raghavan wrote: >>> While I've seen a lot of whining about this whole issue, I certainly >>> haven't been seen any effort to actually solve the problem within the >>> existing framework. For example, if someone cares enough, why not >>> write a wrapper script to track down the programs and libraries at >>> runtime that actually do use /usr so it's easier to say "these >>> packages install rules that need / and /usr on the same partition". >> >> (1) udev has provided a workaround of sorts for this already: udevadm trigger >> --type=failed. this is the udev-postmount init.d script. (2) it's fairly >> trivial to locate most (all?) the failing rules with a single grep: grep /usr >> -R /lib/udev/rules.d/. > > If this comment is true (haven't looked at the code): > > https://bugs.gentoo.org/show_bug.cgi?id=375263#c23 > > that trigger has been removed from udev. Answering myselef; it is gone: http://git.kernel.org/?p=linux/hotplug/udev.git;a=commit;h=289a1821a4a7636ce42a6c7adc3a9bb49421a5ea commit 289a1821a4a7636ce42a6c7adc3a9bb49421a5ea Author: Kay Sievers Date: Thu Oct 6 00:45:06 2011 +0200 remove 'udevadm trigger --type=failed' and SYSFS, ID, BUS keys 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-dev] Suggestion for getting rid of udev
On Fri, Oct 14, 2011 at 8:37 PM, Walter Dnes wrote: > On Thu, Oct 13, 2011 at 10:12:52AM -0400, Thomas Kahle wrote > >> https://www.xkcd.com/963/ > > Xorg --configure Funny, I haven't used a /etc/X11/Xorg.conf in years: negra ~ # ll /etc/X11/ total 20 drwxr-xr-x 2 root root 4096 Sep 12 17:49 app-defaults -rwxr-xr-x 1 root root 1301 Aug 31 15:54 chooser.sh drwxr-xr-x 2 root root 4096 Sep 30 09:36 Sessions -rwxr-xr-x 1 root root 923 Aug 31 15:54 startDM.sh drwxr-xr-x 3 root root 4096 Aug 31 15:54 xinit negra ~ # It's great; it "just works". And it is thanks (in great part) to udev. 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-dev] Suggestion for getting rid of udev
On Sat, Oct 15, 2011 at 1:57 AM, Wulf C. Krueger wrote: > On 15.10.2011 10:42, Michael Schreckenbauer wrote: >> in what way will exherbo deal wih this mess? Are there any plans? > > We don't support /usr on a separate partition. People can, of course, do > that and I'll point them to dracut for creating an initramfs. > > Or they can do whatever works for them. People using Exherbo are > expected to be able to deal with such stuff. And I believe exherbo recommends systemd as init system. 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-dev] Suggestion for getting rid of udev
On Sat, Oct 15, 2011 at 2:13 AM, Canek Peláez Valdés wrote: > On Sat, Oct 15, 2011 at 1:57 AM, Wulf C. Krueger wrote: >> On 15.10.2011 10:42, Michael Schreckenbauer wrote: >>> in what way will exherbo deal wih this mess? Are there any plans? >> >> We don't support /usr on a separate partition. People can, of course, do >> that and I'll point them to dracut for creating an initramfs. >> >> Or they can do whatever works for them. People using Exherbo are >> expected to be able to deal with such stuff. > > And I believe exherbo recommends systemd as init system. Yes, they do: http://exherbo.org/docs/install-guide.html o Install an init system There’s no init system in our stages. This allows you to choose whatever init system (or none) you’d like to use: - sys-apps/systemd (recommended) - modern, fast init system. Needs kernel >=2.6.36-rc1. - sys-apps/baselayout - Gentoo’s old, crufty Baselayout-1. - sys-apps/upstart - Ubuntu’s init system. We don’t generally supply init scripts for this. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
[gentoo-dev] Remove package from system set in custom profile
Hi; I'm trying to make a custom profile, and I need to remove a package from the system set. Is there a way I can do this without editing /usr/portage/profiles/base/packages? Sorry if this is the wrong place for asking such a question. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
[gentoo-dev] Re: Remove package from system set in custom profile
On Thu, Feb 16, 2012 at 7:26 PM, Canek Peláez Valdés wrote: > Hi; I'm trying to make a custom profile, and I need to remove a > package from the system set. Is there a way I can do this without > editing /usr/portage/profiles/base/packages? I see now that I can copy the whole /usr/portage/profiles dir to my overlay, edit base/packages there, and link /etc/make.profile to the profile in my overlay. This has several drawbacks: 1. I need to keep in syncro the profiles dir in my overlay to the one in the portage tree. 2. I probably don't need a whole copy of /usr/portage/profiles. 3. It sure is ugly as hell. Is there a better way to do it? 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-dev] Re: Remove package from system set in custom profile
On Thu, Feb 16, 2012 at 10:43 PM, Duncan <1i5t5.dun...@cox.net> wrote: > Canek Peláez Valdés posted on Thu, 16 Feb 2012 19:26:22 -0600 as > excerpted: > >> Hi; I'm trying to make a custom profile, and I need to remove a package >> from the system set. Is there a way I can do this without editing >> /usr/portage/profiles/base/packages? >> >> Sorry if this is the wrong place for asking such a question. > > FWIW, gentoo-dev is for development related questions. The right place > would be the gentoo-user list. Not really right but better than the > general gentoo-dev list would be the portage-devel list. I would have that in mind next time. > Never-the-less and not to send you away empty-handed, yes of course > there's a way to override it locally. Gentoo wouldn't be gentoo > otherwise. =:^) > > See the portage (5) manpage, in particular, a search on > "/etc/portage/profile" in that manpage, plus the note under the packages > file description (in the /etc/make.profile/ section) about removing > packages from the system set. > > More specifically, here's my /etc/portage/profile/packages: > > # I don't need these > -*sys-apps/busybox > -*sys-apps/module-init-tools > > If the package is listed as a dependency somewhere as well, you may need > to add an entry to packages.provided in the same dir, as well. For > example, from mine (I build everything I need into the kernel, > no kernel modules so no module-init-tools needed to load them, either): > > sys-apps/module-init-tools- That's exactly what I needed. Thanks. 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-dev] Re: newsitem: unmasking udev-181
On Tue, Mar 13, 2012 at 2:43 AM, Walter Dnes wrote: > On Sat, Mar 10, 2012 at 09:53:25PM -0500, Rich Freeman wrote > >> Perhaps a suggestion for the news item. I'd recommend that anybody >> who needs an initramfs to mount /usr get that working BEFORE they >> upgrade udev. This situation is a heck of a lot easier to figure out >> if the system still can be booted when the initramfs doesn't work. > > Question... does it have to be an initramfs, or can the vast majority > of simple cases be handled by a simple initscript in /bin or /sbin that > mounts /usr, and does whatever else is required, before handing off > control to /sbin/init. > > I've migrated to mdev, so I won't be seeing this problem, but a simple > solution that works for 95% of users might be the way to go. For the > more complex situations, an initramfs will be necessary. The devs are already discussing moving /bin/* to /usr/bin/* (if I understood correctly), so this will not last. And besides, genkernel and dracut are automatized; they *are* the simple (and proper, IMHO) solution. 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-dev] Re: Let's redesign the entire filesystem!
On Wed, Mar 14, 2012 at 7:07 PM, Rich Freeman wrote: > On Wed, Mar 14, 2012 at 7:51 PM, Richard Yao wrote: >> >> I proposed a way that this could work with no effort on the part of the >> Gentoo developers in one of my earlier emails: >> > > Then go ahead and make it happen. If as you say no dev participation > is needed there is nothing Gentoo needs to do to support this. > > On Wed, Mar 14, 2012 at 6:49 PM, Greg KH wrote: >> >> We aren't Debian here people, we don't support "everything" :) >> >> If you want to support both, great, feel free to step up and do the >> work. >> > > Gentoo is about choice, but it is largely about the choices that > people are willing to step up and maintain. > > A few months ago there was a big thread and lots of devs said that > systemd isn't supported on Gentoo. Some devs stepped up and decided > to maintain it and now I'd say systemd is about as supported on Gentoo > as Prefix, FreeBSD, Sparc, or MIPS. That didn't happen because of > mailing list persuasion - it happened because a few people interested > in making it happen wrote a bunch of ebuilds. How do systemd units > end up in various packages? The people interested in seeing them > write good-quality patches and submit bugs, or otherwise work with the > maintainers to commit them. > > For those who don't like the current direction, by all means create an > overlay called udev-root, mdev-boot, noinitramfs, or whatever. You > don't need anybody's permission to do it - just go on github and make > it happen. Write some good code. There are several devs here who > might even help you out with it, and nobody here is going to object to > packages going into the main tree as long as they're maintained in > accordance with Gentoo QA. Create some USE flags where you need > tie-ins to other system packages and as long as everything behaves > nicely and patches are good and maintained, I'm sure the package > maintainers will accept them. In that vein... just to let you guys know that I have set up an overlay that has allowed me to run my Gentoo machines with only systemd: no OpenRC, no baselayout, no sysvinit: http://xochitl.matem.unam.mx/~canek/gentoo-systemd-only/ The changes are rather minimal (less than ten lines (usually a cople) per ebuild changed from the original ebuilds in the tree), and almost all will go away when the following bugs get fixed: https://bugs.gentoo.org/show_bug.cgi?id=366173 https://bugs.gentoo.org/show_bug.cgi?id=373219 https://bugs.gentoo.org/show_bug.cgi?id=373219 https://bugs.gentoo.org/show_bug.cgi?id=373219 https://bugs.gentoo.org/show_bug.cgi?id=399615 https://bugs.gentoo.org/show_bug.cgi?id=399615 https://bugs.gentoo.org/show_bug.cgi?id=399615 https://bugs.gentoo.org/show_bug.cgi?id=405703 https://bugs.gentoo.org/show_bug.cgi?id=408379 Bug 373219 is specially problematic, since several scripts in packages on the tree source /etc/init.d/functions.sh, (which lives in OpenRC), and don't depend on OpenRC explicitly. I wrote a little script that replaces the einfo, ewarn, etc. functions of OpenRC, and it seems to be working. I also wrote alternative versions of the packages on the tree that implicitly depend on OpenRC, so they now explicitly depend on a little package that only installs my script. It seems to be working. If you guys want to try it, I would love to hear some comments about it. (Usual disclaimer; if it breaks, you get to keep all the pieces). Oh, and obviously the only supported setups are those with /usr in the same partition as /; or, if /usr is in a separated partition, systems that use an initramfs to mount it. 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-dev] Re: Let's redesign the entire filesystem!
On Thu, Mar 15, 2012 at 7:17 PM, Canek Peláez Valdés wrote: [...] > https://bugs.gentoo.org/show_bug.cgi?id=366173 > https://bugs.gentoo.org/show_bug.cgi?id=373219 > https://bugs.gentoo.org/show_bug.cgi?id=399615 > https://bugs.gentoo.org/show_bug.cgi?id=405703 > https://bugs.gentoo.org/show_bug.cgi?id=408379 Oops, sorry, fogot to use uniq. 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-dev] Stability of /sys api
On Tue, May 15, 2012 at 1:32 AM, Olivier Crête wrote: > On Tue, 2012-05-15 at 01:05 -0400, Walter Dnes wrote: >> I *DON'T WANT* "a serious framework", I want a lightweight device >> manager... period... end of story. Stick with the unix principle of one >> app doing one thing well. mdev is enough for the vast majority of people. > > For the people who don't want to easily use USB sticks or digital > cameras or gsm dongles or really any modern hardware, I'm sure mdev is > fine. A static /dev is even fine for you probably. I agree. And I don't believe people "who don't want to easily use USB sticks or digital cameras or gsm dongles or really any modern hardware" qualify as "the vast majority of people". 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-dev] usr merge
On Sat, Apr 9, 2016 at 11:09 AM, wrote: > On Sat, Apr 09, 2016 at 07:11:31AM -0400, Rich Freeman wrote > >> It was simply a recognition that we were already in a state where >> booting a system without /usr mounted early can cause problems. > > For certain edge cases... yes. Edge cases? According to whom? > But they were already using initramfs > or merging /usr into /. I'm talking about the 95% who don't really need > it. Do you have *ANY* source for that 95%? > >> I never really got the mentality that using an initramfs is a burden. > > One more piece of software that can go wrong. You have to > maintain+configure it; e.g. sync software and library versions with > what's on the rest of the system. Everything can go wrong; an initramfs is actually a really easy piece of software to automatize and debug if it goes wrong. >> An initramfs is just a secondary bootloader for userspace. I almost >> always use them even if I'm just booting a VM with a single partition >> on it. If something goes wrong you can fall back to a shell in the >> initramfs and it is like having a rescue disk built into your system >> disk. > > There is single-user mode for rescue. Which could fail if, for some reason, you need *something* from /usr and it hasn't been mounted. And *something* is becoming *anything*, whether you like it or not. >> For a more complex setup it is much more robust than relying on >> the kernel to find your root, and it also lets you build with a more >> module-based kernel, which has some benefits as well even if you build >> kernels tailored to each host. > > I have "Production" and "Experimental" entries in my LILO menu. A new > kernel is always set up as the "Experimental" entry. After running > several days without problems, I run a script which copies the data from > the "Experimental" portion to "Production". You use LILO. That means, you don't use UEFI. That means, almost certainly you don't use recent hardware. Walter, *YOU* are the 5% edge case. Many people are running UEFI only hardware, and the number will only increase, since BIOS *is* dead. > The only time my system had problems "finding root" was years ago when > the switch from /dev/hd* to /dev/sd* took place. The "Experimental" > boot with the new kernel died. I booted "Production", read the mailing > list, changed "hd" to "sd" for the "Experimental" entry, and rebooted. > After several days without problems, I made the same change to the > "Production" entry, and copied the "Experimental" portion to > "Production". That was the only time *FOR YOU*. But, as I stated above, you are the 5% edge case; the Gentoo devs need to think about the general case, starting with their own systems so they can do their jobs. I bet most of them are on UEFI. Nobody anywhere is telling you what to do with your systems (nor would they in the future). The Gentoo devs only are saying that if by having separated /usr without an initramfs, you risk screwing your system, and if that happens, you are on you own. Regards. -- Dr. Canek Peláez Valdés Profesor de Carrera Asociado C Departamento de Matemáticas Facultad de Ciencias Universidad Nacional Autónoma de México
Re: [gentoo-dev] Re: usr merge
On Sat, Apr 9, 2016 at 1:34 PM, wrote: > On Sat, Apr 09, 2016 at 12:18:25PM -0500, »Q« wrote >> On Sat, 9 Apr 2016 12:09:38 -0400 >> waltd...@waltdnes.org wrote: >> >> > On Sat, Apr 09, 2016 at 07:11:31AM -0400, Rich Freeman wrote >> > >> > > It was simply a recognition that we were already in a state where >> > > booting a system without /usr mounted early can cause problems. >> > >> > For certain edge cases... yes. But they were already using >> > initramfs or merging /usr into /. I'm talking about the 95% who >> > don't really need it. >> >> Booting without /usr mounted early is something Gentoo already doesn't >> support and can't support, right? > > If you can read this post, you've got a mighty powerful imagination. > Because we all know that Gentoo can't boot, let alone send emails, from > a machine with separate /usr and no initramfs... just like I'm using > right now. Nobody said it was not possible; Q said that it was not supported, and it cannot be because, in the general case (not *YOU* specific case), someone somewhere may require something from /usr to boot. Regards. -- Dr. Canek Peláez Valdés Profesor de Carrera Asociado C Departamento de Matemáticas Facultad de Ciencias Universidad Nacional Autónoma de México
Re: [gentoo-dev] usr merge
On Sat, Apr 9, 2016 at 2:49 PM, Philip Webb wrote: > 160409 Canek Peláez Valdés wrote: >> You use LILO : that means, you don't use UEFI : >> that means, almost certainly, you don't use recent hardware. > > I've always used Lilo, which is simple + reliable : > I never see questions re it here, but there are many re Grub. > I do use recent hardware, a cutting-edge machine I built 6 mth ago . > When setting it up, I suppressed UEFI in the BIOS settings : > isn't that what anyone not running M$ would do ? I just disabled secure boot, although it's possible to use it with Linux. However it would require to manually sign everything from boot loader to kernel modules, since Gentoo has no infrastructure to do that. Maybe a future project. I don't "supress" UEFI, since it's *obviously* so much better than BIOS, and since bootctl (the program formerly known as gummiboot) it's incredible easy to use. You don't even notice it's there. Also, I'm not sure, but I believe there are motherboards where you don't have the option to "supress" UEFI, since they simply don't have BIOS anymore. I could be wrong; but even if that's the case, I'm pretty sure in the future BIOS will get relegated to a niche market, if it doesn't completely disappear. Seriously, UEFI is s much better. Regards. -- Dr. Canek Peláez Valdés Profesor de Carrera Asociado C Departamento de Matemáticas Facultad de Ciencias Universidad Nacional Autónoma de México
Re: [gentoo-dev] [RFC] gtk/gtk2/gtk3 USE flag situation
On Fri, May 27, 2016 at 10:02 AM, Brian Dolbec wrote: [snip] > I'll be really sad when gtk2 is totally abolished in Gentoo. :( > I suppose I'll have to break down and switch to KDE maybe. > > In my opinion the upstream gtk developers have gone somewhat bonkers > with their cartoonish changes to the look, feel and generally > un-intuitive user interface. The new file selector is irritating to use > despite getting all the old behaviour settings I know of set, the lack > of the ability to paste a path into it, forcing you to navigate > directory by directory, and other BS behaviour... What's wrong with Ctrl-L to open the "Enter location or URL" text field and pasting the path there? Regards. -- Dr. Canek Peláez Valdés Profesor de Carrera Asociado C Departamento de Matemáticas Facultad de Ciencias Universidad Nacional Autónoma de México
Re: [gentoo-dev] reproducible builds
On Feb 4, 2018 12:04, "Matt Turner" wrote: On Sun, Feb 4, 2018 at 7:25 AM, Samuel Bernardo wrote: > Hi, > > I send this email to know the opinion of gentoo developers about > registering gentoo profiles in the context of reproducible-builds.org Reproducible builds makes sense when you're distributing binaries to users. That's not typically the case with Gentoo. What would this even mean in the context of a source-based distro? It would mean that we all could reproduce the exact same bugs given the CFLAGS/USE/etc. combination. Many groups are working on this from different fronts; if the results stabilize at some point, Gentoo could use that to at least give the users the option of enabling reproducible builds. Regards.
