Re: [gentoo-dev] Re: udev and /usr
On Mon, Sep 26, 2011 at 7:57 AM, Zac Medico wrote: > On 09/25/2011 06:57 PM, Nirbheek Chauhan wrote: >> But neither portage, nor the portage tree, nor any of our branding are >> shipped with ChromeOS. Hence it's as much a Gentoo install as $company >> that uses portage to build $image for their embedded device, but >> doesn't leave any trace of Gentoo behind. > > So what? I work on Gentoo for the benefit of myself and others > (including Chrome OS devs), not because I want people to see Gentoo > branding, or have more people identify themselves as "Gentoo users." > I never meant to say that it's NOT beneficial to Gentoo. I've stated publicly, numerous times since the very beginning in emails, on IRC, twitter, etc. that the fact that ChromeOS uses Portage is and will be quite beneficial to us in many ways. If you recall my recent email to gentoo-core, I specifically talked about this. Please don't take my pedantic definition-wrangling as anything but pedantry. All I've been saying is that it's *misleading* to users for us to say that Google uses Gentoo on its Chrome Books. Google uses Gentoo's portage tools to build ChromeOS, which is hence arguably a *derivative* of Gentoo, but not really Gentoo. This is precisely what Mike said in his last email, and resolved his initial statement for me, which was ambiguous from my PoV. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] Re: udev and /usr
On Sunday, September 25, 2011 21:57:27 Nirbheek Chauhan wrote: > But neither portage, nor the portage tree, nor any of our branding are > shipped with ChromeOS. Hence it's as much a Gentoo install as $company > that uses portage to build $image for their embedded device, but > doesn't leave any trace of Gentoo behind. you don't need a portage tree. binpkgs work just fine. all the metadata is pulled down as you go. i'm not saying it is Gentoo, but it is clearly a derivative that relies on quite a bit of the tree to build. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: udev and /usr
On 09/25/2011 06:57 PM, Nirbheek Chauhan wrote: > On Mon, Sep 26, 2011 at 7:02 AM, Mike Frysinger wrote: >> On Sunday, September 25, 2011 05:53:18 Nirbheek Chauhan wrote: >>> "Gentoo" is defined by portage and the portage tree. If we remove >>> that, the end result is no different than compiling stuff manually in >>> Slackware or by hand. Sure, the average Chrome OS end user may not know the difference. However, it makes a difference to the Gentoo community to have our tools and tree used by Chrome OS developers, and have them contribute back fixes and enhancements. >> which is how Chrome OS is built. >> ROOT=/some/place emerge >> > > Yes, I'm well aware of how ChromeOS is built. :) > > But neither portage, nor the portage tree, nor any of our branding are > shipped with ChromeOS. Hence it's as much a Gentoo install as $company > that uses portage to build $image for their embedded device, but > doesn't leave any trace of Gentoo behind. So what? I work on Gentoo for the benefit of myself and others (including Chrome OS devs), not because I want people to see Gentoo branding, or have more people identify themselves as "Gentoo users." -- Thanks, Zac
Re: [gentoo-dev] Re: udev and /usr
On Mon, Sep 26, 2011 at 7:02 AM, Mike Frysinger wrote: > On Sunday, September 25, 2011 05:53:18 Nirbheek Chauhan wrote: >> "Gentoo" is defined by portage and the portage tree. If we remove >> that, the end result is no different than compiling stuff manually in >> Slackware or by hand. > > which is how Chrome OS is built. > ROOT=/some/place emerge > Yes, I'm well aware of how ChromeOS is built. :) But neither portage, nor the portage tree, nor any of our branding are shipped with ChromeOS. Hence it's as much a Gentoo install as $company that uses portage to build $image for their embedded device, but doesn't leave any trace of Gentoo behind. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] Re: udev and /usr
On Sunday, September 25, 2011 08:53:08 Rich Freeman wrote: > However, I can't seem to find a chromeos-meta package in portage, and > the fact that my chromeos laptop has some feature does me little good > in getting my Gentoo desktop to do the same. At best ChromeOS is a > fork of Gentoo, and the work that is done to highly integrate it > doesn't really trickle back upstream. To be honest, I'm not sure it > would be easy for them to do so. Chrome OS uses the Gentoo tree of ebuilds and an overlay of custom packages. there are also a number of patches to packages that are in our tree, but those are in the process of merging back into Gentoo mainline. i wouldn't really clasify this as a fork ... it's more a derivative. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: udev and /usr
On Sunday, September 25, 2011 05:53:18 Nirbheek Chauhan wrote: > On Sun, Sep 25, 2011 at 12:05 PM, Mike Frysinger wrote: > > On Fri, Sep 16, 2011 at 09:59, Rich Freeman wrote: > >> I'm a bit concerned that the future of linux on the desktop is going to > >> be one where your choices are things like Android, ChromeOS, Ubuntu, > >> Gnome OS, or a "KDE OS." Each one would have its own package managers, > >> repositories, distros, APIs, etc. Clearly there is some benefit from > >> the vertical integration (Android and ChromeOS have a very high level > >> of polish, and Ubuntu is approaching this often by just writing their > >> own stuff). Instead of working to influence other projects (which can > >> be frustrating), big distros are looking to just eliminate dependencies > >> outside of themselves. This will be a big challenge for a smaller > >> distro like Gentoo. Obviously we can't just go write our own Wayland > >> replacement, even if we did essentially make our own "systemd" of > >> sorts. > > > > you're aware the ChromeOS is built on top of / with Gentoo right ? > > "Gentoo" is defined by portage and the portage tree. If we remove > that, the end result is no different than compiling stuff manually in > Slackware or by hand. which is how Chrome OS is built. ROOT=/some/place emerge -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: udev and /usr
On 9/25/11 5:53 AM, Rich Freeman wrote: > Repeat this 100 times and you end up with a chromium tarball > that consists of 90% redistributed 3rd-party libraries with subtle > tweaks. However, can you really argue with Google's success with this > approach. At least in Gentoo we remove _most_ of the bundled libraries. Currently the biggest culprits are probably ffmpeg (Chromium upstream breaks it so often that I gave up trying to use the system version) and mesa (yeah, Chromium bundles it and it seems it's patched). I'm slowly convincing the upstream to have a more distro-friendly bundling strategy (i.e. staying close to upstream and making it possible to use system versions). This takes time, and I often need to do the unbundling work myself. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: udev and /usr
On Sun, Sep 25, 2011 at 2:35 AM, Mike Frysinger wrote: > On Fri, Sep 16, 2011 at 09:59, Rich Freeman wrote: >> This will be a big challenge for a smaller distro like Gentoo. Obviously we >> can't just go write our own Wayland replacement, even if we did essentially >> make our own "systemd" of sorts. > > you're aware the ChromeOS is built on top of / with Gentoo right ? Sure - I'm typing this on my CR-48. :) However, I can't seem to find a chromeos-meta package in portage, and the fact that my chromeos laptop has some feature does me little good in getting my Gentoo desktop to do the same. At best ChromeOS is a fork of Gentoo, and the work that is done to highly integrate it doesn't really trickle back upstream. To be honest, I'm not sure it would be easy for them to do so. I think that the issue is that big companies are moving away from The-Unix-Way(TM), to some extent. Rather than having a bunch of modular components that you can mix and match, everybody is looking to vertically integrate. That often starts with existing components but then leads to various changes such that the components are no longer replaceable. Suppose you're a big integrator like Canonical. You employ 1000 linux devs, all paid to work 40 hours per week and who regularly meet and are competently managed/etc (let's assume for the sake of argument that this makes them more productive). You want to add feature X to your product. However, to accomplish this you need to get module A and module B to talk to each other in some way not allowed by their APIs. Module A is maintained by 3 volunteers, and module B is maintained by 100 people but they have a huge NIH chip on their shoulder and half of them work for competitors and they don't take module A seriously. You can spend hundreds of hours getting them to try them to play nicely with each other, or you can just fork A and B and patch them to do what you want them to do. Sure, that is a long-term maintenance burden, but your 1000 devs can surely handle that. Repeat this 100 times and you end up with a chromium tarball that consists of 90% redistributed 3rd-party libraries with subtle tweaks. However, can you really argue with Google's success with this approach. The FOSS world tends to be messy - lots of strong personalities and nobody really has a financial interest in doing much of anything that doesn't scratch a personal itch. There are alliances of convenience. Big companies are finding it less expensive to just do an end-run around the whole thing. I think there will be a balance, since fundamentally there are advantages to compatibility. However, I fear that the future will look more and more like a world where you pick one ecosystem and end up with first-rate apps that work nicely and 3rd-rate apps that don't. If you pick KDE, then you had better like amarok or whatever else comes with it, or be prepared to quit and restart the app anytime your laptop switches from your car's bluetooth stereo to internal speakers. Rich
Re: [gentoo-dev] Re: udev and /usr
On Sun, Sep 25, 2011 at 12:05 PM, Mike Frysinger wrote: > On Fri, Sep 16, 2011 at 09:59, Rich Freeman wrote: >> I'm a bit concerned that the future of linux on the desktop is going to be >> one where your choices are things like Android, ChromeOS, Ubuntu, Gnome OS, >> or a "KDE OS." Each one would have its own package managers, repositories, >> distros, APIs, etc. Clearly there is some benefit from the vertical >> integration (Android and ChromeOS have a very high level of polish, and >> Ubuntu is approaching this often by just writing their own stuff). Instead >> of working to influence other projects (which can be frustrating), big >> distros are looking to just eliminate dependencies outside of themselves. >> This will be a big challenge for a smaller distro like Gentoo. Obviously we >> can't just go write our own Wayland replacement, even if we did essentially >> make our own "systemd" of sorts. > > you're aware the ChromeOS is built on top of / with Gentoo right ? "Gentoo" is defined by portage and the portage tree. If we remove that, the end result is no different than compiling stuff manually in Slackware or by hand. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] Re: udev and /usr
On Fri, Sep 16, 2011 at 09:59, Rich Freeman wrote: > I'm a bit concerned that the future of linux on the desktop is going to be > one where your choices are things like Android, ChromeOS, Ubuntu, Gnome OS, > or a "KDE OS." Each one would have its own package managers, repositories, > distros, APIs, etc. Clearly there is some benefit from the vertical > integration (Android and ChromeOS have a very high level of polish, and > Ubuntu is approaching this often by just writing their own stuff). Instead > of working to influence other projects (which can be frustrating), big > distros are looking to just eliminate dependencies outside of themselves. > This will be a big challenge for a smaller distro like Gentoo. Obviously we > can't just go write our own Wayland replacement, even if we did essentially > make our own "systemd" of sorts. you're aware the ChromeOS is built on top of / with Gentoo right ? -mike
Re: [gentoo-dev] Re: udev and /usr
On 09/16/2011 14:06, Duncan wrote: > > Careful with the "extreme". As you no doubt realize by now, the udev > folks apparently consider anyone wanting a separate /usr but not an initr* > "extreme". That'd certainly apply double if said admin (since no simple > "user" cares about such stuff, in this view) had /usr on lvm. I'd say the udev folks need their coffee/tea checked. If this logic stems from some requirement for a window manager/desktop environment on some other distro, then we need to make sure that becomes a configurable item in Gento or not support that package. This is the exact setup I use, and it's worked great since 2003. No, it's not the setup for everyone, so I don't think it should be mandatory for everyone, either. I expect the same for other approaches to have a use for some segment of users, but not to code it in as a hard-set default. Gentoo's about choice. Why else do we have more USE flags than the entirety of the IPv6 address space? (okay, I'm stretching that last a sentence a fair bit ...) -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org 4096R/D25D95E3 2011-03-28 "The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between." --Emperor Turhan, Centauri Republic signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: udev and /usr
The 18/09/11, Duncan wrote: > > I don't see any added benefit from using DBUS on my servers. Insterstingly, Duncan just answered your question... > Interesting question. I hadn't seen the suggestion until this thread, > either, and it bothered me too. >From here: > With a moment's thought, I decided I could probably return to a semi- > static dev setup reasonably easily. I'd potentially turn on the early-dev > option in the kernel that I still have off, ATM, which presumably would > mount a tmpfs on dev and populate it with the earliest devices. After > that, if necessary, I'd copy the existing udev-created nodes out to a > persistent state dir, and copy them back in with a little init-time > script of my own. As long as the device ordering remains stable, this > could include by-label, etc, symlinks, or I could simply kill the by- > label, by-uid stuff in fstab, and go back to traditional devices there, > too. > > Either that, or simply go back to a static /dev entirely. > > People with dynamic ordered devices may have to devise their own scripts, > tho, or perhaps more likely, fork off udev from the pre-union state. ...to here. > But it's also possible that's far enough in the future that we can't > really answer the question now, since technology will have changed enough > to make an answer now look senseless, then. Consider trying to answer > the question in terms of the kernel devfs back before udev. The tech > simply changed and those answers wouldn't really work, today. Upstream changes the init process is done. So, you're free to either: stick to upstream (with best long term support); or fork off upstream (requires knowledges, manpower and time); or go back to 1960 with a full/partial static /dev (asking to manually maintain the crap). See the benenfit, now? -- Nicolas Sebrecht
Re: [gentoo-dev] Re: udev and /usr
On Sun, Sep 18, 2011 at 2:14 PM, Duncan <1i5t5.dun...@cox.net> wrote: > Joost Roeleveld posted on Sun, 18 Sep 2011 17:22:42 +0200 as excerpted: > > I don't see any added benefit from using DBUS on my servers. > > Interesting question. I hadn't seen the suggestion until this thread, > either, and it bothered me too. > > Well, I can't really speak about the specific issue as I'm not sure what the maintainers of dbus, systemd, and udev are thinking. However, I can imagine that the goals of parties like Canonical and RedHat are to cut down on the number of configurations. If the server image is vastly different from the desktop image you start having to divide your resources to maintain both. If the only difference is that you install a little less stuff (or just different stuff) by default then it isn't such a big deal. Gentoo is not immune to these pressures either. If upstream moves in one direction then it will take consistent effort just to stay still. Anytime we have six months without a dev we'll just inevitably get pulled along with upstream anyway. If people have concerns with the direction upstream is going, then they need to try to influence the upstream projects to change direction. Simply posting on this list isn't going to change udev's long-term strategy. Personally I feel that Gentoo is all about choice and we should continue to give our users as many choices as are practical. However, we don't have the resources of Canonical and we can't just fork upstream and take it an entirely different direction as a result. Rich
[gentoo-dev] Re: udev and /usr
Joost Roeleveld posted on Sun, 18 Sep 2011 17:22:42 +0200 as excerpted: > On Saturday, September 17, 2011 06:40:03 PM Robin H. Johnson wrote: >> On Fri, Sep 16, 2011 at 10:36:27AM +0200, Joost Roeleveld wrote: >> (The other reason I think systemd and udev might merge at some point, >> or at least have good IPC between them, because there is a potential >> for speed gains there). > > If udev and systemd merge, what will happen with people not using > systemd? > > I don't see any added benefit from using DBUS on my servers. Interesting question. I hadn't seen the suggestion until this thread, either, and it bothered me too. With a moment's thought, I decided I could probably return to a semi- static dev setup reasonably easily. I'd potentially turn on the early-dev option in the kernel that I still have off, ATM, which presumably would mount a tmpfs on dev and populate it with the earliest devices. After that, if necessary, I'd copy the existing udev-created nodes out to a persistent state dir, and copy them back in with a little init-time script of my own. As long as the device ordering remains stable, this could include by-label, etc, symlinks, or I could simply kill the by- label, by-uid stuff in fstab, and go back to traditional devices there, too. Either that, or simply go back to a static /dev entirely. People with dynamic ordered devices may have to devise their own scripts, tho, or perhaps more likely, fork off udev from the pre-union state. But it's also possible that's far enough in the future that we can't really answer the question now, since technology will have changed enough to make an answer now look senseless, then. Consider trying to answer the question in terms of the kernel devfs back before udev. The tech simply changed and those answers wouldn't really work, today. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
Re: [gentoo-dev] Re: udev and /usr
On Sat, Sep 17, 2011 at 2:16 AM, Joost Roeleveld wrote: > > Except that Redhat and Centos use LVM by default. Which will also mean that > "simple users" also end up using LVM. > Then again, they also end up with an initr* and a generic kernel for > everything under the sun. > I haven't properly looked at the kernel-configs from redhat lately, but I > don't think they include all the possible hardware options be default? > > > The typical mainstream binary distro approach is to: 1. Build every module under the sun that won't cause more support headaches than benefits. 2. Build a really smart initramfs that can find root whether it is on raid, lvm, luks, or on a SAN behind luks and a VPN (ok, I'm stretching it a little). 3. Deploy that on everything. With an initramfs you can essentially build a completely modular kernel, since the kernel can rely on any module it wishes right from the start. However, once the initramfs is done the kernel is still a minimal size since unused modules don't occupy space (the initramfs wipes itself out of ram as its last step, unless in a debug mode). Sure, the fancy initramfs takes work, but since the install image is one-size-fits-all it is less maintenance in the long haul. Plus you can replace your motherboard and still boot the same drive image. The downside is that it might take an extra second or two to boot, but dracut is pretty fast. Honestly, if I were running a server setup I'd probably consider using an intiramfs. They're a lot less susceptible to being messed up if for whatever reason the drives get re-ordered in the BIOS (root=UUID, or with LVM the device names can usually be trusted). I once booted off of a rescue CD that for whatever reason changed the major numbers assigned to my raid devices and for a while I could never predict what /dev/md# my root would end up with. That is what started my quest to get dracut working, which I'll continue whenever git.kernel.org is back up... Rich
Re: [gentoo-dev] Re: udev and /usr
On Friday, September 16, 2011 06:06:35 PM Duncan wrote: > Joost Roeleveld posted on Fri, 16 Sep 2011 10:36:27 +0200 as excerpted: > > I agree, I just used this example to explain that it shouldn't be > > necessary to force an initramfs on all users just because there is a > > small group who wants to have an extreme setup. > > Careful with the "extreme". As you no doubt realize by now, the udev > folks apparently consider anyone wanting a separate /usr but not an initr* > "extreme". That'd certainly apply double if said admin (since no simple > "user" cares about such stuff, in this view) had /usr on lvm. Yes, I've noticed that. Except that Redhat and Centos use LVM by default. Which will also mean that "simple users" also end up using LVM. Then again, they also end up with an initr* and a generic kernel for everything under the sun. I haven't properly looked at the kernel-configs from redhat lately, but I don't think they include all the possible hardware options be default? -- Joost
[gentoo-dev] Re: udev and /usr
Joost Roeleveld posted on Fri, 16 Sep 2011 10:36:27 +0200 as excerpted: > I agree, I just used this example to explain that it shouldn't be > necessary to force an initramfs on all users just because there is a > small group who wants to have an extreme setup. Careful with the "extreme". As you no doubt realize by now, the udev folks apparently consider anyone wanting a separate /usr but not an initr* "extreme". That'd certainly apply double if said admin (since no simple "user" cares about such stuff, in this view) had /usr on lvm. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
Re: [gentoo-dev] Re: udev and /usr
On Fri, Sep 16, 2011 at 12:03 AM, Duncan <1i5t5.dun...@cox.net> wrote: > It may be that this is already sorted on the gnome side, or that all this > talk of gnome-os is simply hot-air, but like I said, I'm a kde user, so I > wouldn't know, tho I'm concerned about its implications for the rest of > us (including kde, since it might well end up with similar > requirements). And I've not yet seen it mentioned in the gentoo > implications context, so I'm compelled to ask. > > I too am a bit concerned with some of the trends here. I recently installed Ubuntu to see how it handles suspend-to-disk and compare Gentoo's support (believe it or not it worked more reliably on my Gentoo install!). However, what struck me is messages like my VM didn't meet the requirements for unity so it was falling back to classic gnome, and that got me thinking. I'm seeing a bit of a trend in the linux world towards major distros and desktop environments building these huge highly integrated platforms. Instead of having core modules that everybody shares and clear interfaces, everybody wants to build their own SysVInit replacement, their own audio system, their own window managers, their own web browsers, and so on. With Wayland on the horizon we're talking about having multiple X11 implementations/replacements possibly. Granted, KDE/Gnome have been doing this sort of thing for a while with arts/etc. However, if arts wasn't working right it didn't really keep you from getting stuff done (unless you are mixing audio for a living). I'm a bit concerned that the future of linux on the desktop is going to be one where your choices are things like Android, ChromeOS, Ubuntu, Gnome OS, or a "KDE OS." Each one would have its own package managers, repositories, distros, APIs, etc. Clearly there is some benefit from the vertical integration (Android and ChromeOS have a very high level of polish, and Ubuntu is approaching this often by just writing their own stuff). Instead of working to influence other projects (which can be frustrating), big distros are looking to just eliminate dependencies outside of themselves. This will be a big challenge for a smaller distro like Gentoo. Obviously we can't just go write our own Wayland replacement, even if we did essentially make our own "systemd" of sorts. Rich
[gentoo-dev] Re: udev and /usr
Joost Roeleveld posted on Thu, 15 Sep 2011 22:33:18 +0200 as excerpted: > On Thursday, September 15, 2011 09:31:45 PM Luca Barbato wrote: >> On 15/09/2011 16:33, Joost Roeleveld wrote: >> > >> > Not sure if you are aware of the discussions on the gentoo-user list >> > about the upcoming change where systemd and udev require /usr to be >> > available prior to starting of udev. >> >> systemd seems more and more just a support burden for no gain... > > Myself and a lot of others on the gentoo-user list agree with this. > Especially as there are plenty of installations where udev works without > /usr mounted. As a kde user[1] I tend to agree, but I'm increasingly seeing talk on the gnome side of the "Gnome OS", to include pulse-audio, systemd, policykit, udev/u* (thus forcing lvm as well, at least lvm installation tho nothing forces one to use it... yet, since lvm is required for udisks), etc. Legitimate question, primarily for the gentoo/gnome folks I guess. I simply don't know how it's to work but am honestly rather fearful for the traditional Gentoo policy of letting the local sysadmin decide such things: How serious is this talk, how integrated are they actually talking, and what are the implications for Gentoo's Gnome users? Is gnome 3.5 or 4.0 or whatever going to require pulse-audio and systemd, on ANY distribution, even Gentoo? If not, how much hacking is going to be required by the gentoo/gnome folks to keep those sorts of choices for Gentoo users? Will gentoo simply drop gnome as an option if it forces the issue, or ??? It may be that this is already sorted on the gnome side, or that all this talk of gnome-os is simply hot-air, but like I said, I'm a kde user, so I wouldn't know, tho I'm concerned about its implications for the rest of us (including kde, since it might well end up with similar requirements). And I've not yet seen it mentioned in the gentoo implications context, so I'm compelled to ask. --- [1] Tho the kde side seems headed the same direction, but at a somewhat slower pace and with a bit more of a reputation for at least /some/ respect of user choice, so I expect the issue to come up first and worst with gnome, and gentoo/kde to be able to follow the precedent, to some degree. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
