Re: [gentoo-dev] busybox[sep-usr] support for mounting /usr w/out hassle

Re: [gentoo-dev] busybox[sep-usr] support for mounting /usr w/out hassle

[Tony "Chainsaw" Vroon]

On 30/04/12 05:31, William Hubbs wrote:
> Correction here; as far as I know the council did not mandate
> separate /usr without initramfs. They just said that separate /usr
> is a supported configuration.

Separate /usr is a supported configuration, which blocks the armwaving
about "oh just use an initramfs then" as a solution. As apparently
lessons about filesystem layout have been unlearned:
Binaries that are essential for system boot, and must be available in
single user mode go in /bin and /sbin, with their libraries in /lib.
This allows for /usr to be:
1) marked read-only for NFS mounts, which some of us rely on
2) inside of an LVM2 container, allowing for / to be (very) small
3) on a squashfs filesystem, in order to save space

My deployment relies on option 2, other sysadmins rely on option 1.
Some of our users are very happy with option 3.

Trying to second-guess my motivation, and trying to undo unanimous
council votes simply because your opinion is different, really has to
stop.

I feel a lot better about vapier's pragmatic approach then I do about
udev/systemd upstream's ability and motivation to support current
systems. If you had any doubts about whether udev was part of the
problem, consider what tarball you will have to extract it from in future.

Regards,
-- 
Tony Vroon
Server systems manager
London Internet Exchange Ltd, Trinity Court, Trinity Street,
Peterborough, PE1 1DA
Registered in England number 3137929
E-Mail: tony@linx.net

Re: [gentoo-dev] busybox[sep-usr] support for mounting /usr w/out hassle

[Rich Freeman]

On Mon, Apr 30, 2012 at 4:05 AM, Tony "Chainsaw" Vroon
<chainsaw@gentoo.org> wrote:
> Binaries that are essential for system boot, and must be available in
> single user mode go in /bin and /sbin, with their libraries in /lib.
> This allows for /usr to be:
> 1) marked read-only for NFS mounts, which some of us rely on
> 2) inside of an LVM2 container, allowing for / to be (very) small
> 3) on a squashfs filesystem, in order to save space

These are all things easily supported with an initramfs.  In fact,
initramfs-based solutions allow the same sorts of things to be done
with all the other filesystems and not just /usr.

> Trying to second-guess my motivation, and trying to undo unanimous
> council votes simply because your opinion is different, really has to
> stop.

I don't think anybody is trying to undo council votes - people are
just speculating as to what they voted on.  The easiest solution is
for somebody to say "I'm John Smith, and I am speaking officially for
the council, and we agree that what was decided upon is X."

It seems pretty clear that everybody wants to support a separate /usr.
 We even have multiple supported solutions, including an initramfs, a
use flag on busybox, and I believe somebody posted a script that can
be run during early boot to mount /usr.  It sounds like the only thing
that isn't supported is "doing nothing" - but with Gentoo if you "do
nothing" you don't get an installed system that works on any
configuration.

>
> I feel a lot better about vapier's pragmatic approach then I do about
> udev/systemd upstream's ability and motivation to support current
> systems. If you had any doubts about whether udev was part of the
> problem, consider what tarball you will have to extract it from in future.

Well, if others feel differently about the direction udev is taking,
they can of course just fork it.

I can't say I'm terribly excited about the amount of vertical
integration going on.  I don't run Gnome, and I don't run Unity.  I
really do prefer the unix way.

However, I don't contribute much to those upstream projects, and I
don't see much value in telling a bunch of people who do that they are
doing it wrong.  I don't like how Google develops Android in the dark,
or that they bundle 1GB of third-party stuff in their Chromium source
and distribute a favored binary-only derivative.  However, I do like
that they're giving me all of that stuff essentially for free, and so
beyond the odd blog post I try not to give them too hard a time.

In the same way I think we need to give the maintainers of these
projects in Gentoo some slack, or join those projects and help them to
address your needs.  It is a lot easier to tell others what to do than
to help make it happen, but a volunteer-based project like Gentoo
needs the latter more than the former.

Rich

[gentoo-dev] Chromium bundled code

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 466 bytes --]

On Monday 30 April 2012 12:00:59 Rich Freeman wrote:
> doing it wrong.  I don't like how Google develops Android in the dark,
> or that they bundle 1GB of third-party stuff in their Chromium source
> and distribute a favored binary-only derivative.

err, they distribute a Chromium source tarball, and their build system 
includes flags to use the system versions of those bundled libs if you so 
choose.  i think this is a perfectly fine compromise.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] Chromium bundled code

[Rich Freeman]

On Mon, Apr 30, 2012 at 12:11 PM, Mike Frysinger <vapier@gentoo.org> wrote:
> On Monday 30 April 2012 12:00:59 Rich Freeman wrote:
>> doing it wrong.  I don't like how Google develops Android in the dark,
>> or that they bundle 1GB of third-party stuff in their Chromium source
>> and distribute a favored binary-only derivative.
>
> err, they distribute a Chromium source tarball, and their build system
> includes flags to use the system versions of those bundled libs if you so
> choose.  i think this is a perfectly fine compromise.

Must be a fairly new compromise - but glad to hear that they've come
along a bit.

Maybe their future Google Earth install package for Linux won't bundle wine.  :)

In any case, I think this really just gets to my point - people who
develop FOSS aren't doing it with the express goal of making your life
difficult - they just don't always have the same itches.  If you help
them out or ask NICELY sometimes they'll even help scratch yours.

Rich

Re: [gentoo-dev] Chromium bundled code

[Matt Turner]

On Mon, Apr 30, 2012 at 12:11 PM, Mike Frysinger <vapier@gentoo.org> wrote:
> On Monday 30 April 2012 12:00:59 Rich Freeman wrote:
>> doing it wrong.  I don't like how Google develops Android in the dark,
>> or that they bundle 1GB of third-party stuff in their Chromium source
>> and distribute a favored binary-only derivative.
>
> err, they distribute a Chromium source tarball, and their build system
> includes flags to use the system versions of those bundled libs if you so
> choose.  i think this is a perfectly fine compromise.
> -mike

It looks like chromium-20.0.1115.1.ebuild removes 45 bundled
libraries, and still has TODOs in place to use the system's ffmpeg,
hunspell, (Open?)SSL, SQLite, and libvpx.

Re: [gentoo-dev] Chromium bundled code

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 952 bytes --]

On Monday 30 April 2012 12:32:35 Matt Turner wrote:
> On Mon, Apr 30, 2012 at 12:11 PM, Mike Frysinger wrote:
> > On Monday 30 April 2012 12:00:59 Rich Freeman wrote:
> >> doing it wrong.  I don't like how Google develops Android in the dark,
> >> or that they bundle 1GB of third-party stuff in their Chromium source
> >> and distribute a favored binary-only derivative.
> > 
> > err, they distribute a Chromium source tarball, and their build system
> > includes flags to use the system versions of those bundled libs if you so
> > choose.  i think this is a perfectly fine compromise.
> 
> It looks like chromium-20.0.1115.1.ebuild removes 45 bundled
> libraries

to be sure the system ones get used

> and still has TODOs in place to use the system's ffmpeg,
> hunspell, (Open?)SSL, SQLite, and libvpx.

it's on going work :).  ffmpeg/libvpx are a bit harder as Chromium syncs faster 
than they make releases i believe.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] Chromium bundled code

[Mike Gilbert]

On Mon, Apr 30, 2012 at 1:30 PM, Mike Frysinger <vapier@gentoo.org> wrote:
> On Monday 30 April 2012 12:32:35 Matt Turner wrote:
>> On Mon, Apr 30, 2012 at 12:11 PM, Mike Frysinger wrote:
>> > On Monday 30 April 2012 12:00:59 Rich Freeman wrote:
>> >> doing it wrong.  I don't like how Google develops Android in the dark,
>> >> or that they bundle 1GB of third-party stuff in their Chromium source
>> >> and distribute a favored binary-only derivative.
>> >
>> > err, they distribute a Chromium source tarball, and their build system
>> > includes flags to use the system versions of those bundled libs if you so
>> > choose.  i think this is a perfectly fine compromise.
>>
>> It looks like chromium-20.0.1115.1.ebuild removes 45 bundled
>> libraries
>
> to be sure the system ones get used
>
>> and still has TODOs in place to use the system's ffmpeg,
>> hunspell, (Open?)SSL, SQLite, and libvpx.
>
> it's on going work :).  ffmpeg/libvpx are a bit harder as Chromium syncs faster
> than they make releases i believe.
> -mike

Right. Generally, the bundled ffmpeg does not correspond to an
official upstream release.

ffmpeg upstream is not afraid of making API changes, so it has proven
quite difficult to make chromium work with all versions on ffmpeg in
portage, plus the bundled snapshot. When we were using the system lib,
it would break nearly every time a new major version of chromium was
forked.

Re: [gentoo-dev] Chromium bundled code

["Paweł Hajdan, Jr."]

[-- Attachment #1: Type: text/plain, Size: 706 bytes --]

On 4/30/12 7:42 PM, Mike Gilbert wrote:
> ffmpeg upstream is not afraid of making API changes, so it has proven
> quite difficult to make chromium work with all versions on ffmpeg in
> portage, plus the bundled snapshot. When we were using the system lib,
> it would break nearly every time a new major version of chromium was
> forked.

Right. Eventually I'd like to create an ffmpeg compatibility layer in
Chromium, so that all Chromium-specific code would talk to it, and the
layer would know how to handle (at compile time) different versions of
ffmpeg.

Also, the browser binary should really just link directly to ffmpeg
libraries instead of using dlopen. I also plan to change that.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 203 bytes --]

Re: [gentoo-dev] Chromium bundled code

["Paweł Hajdan, Jr."]

[-- Attachment #1: Type: text/plain, Size: 1619 bytes --]

On 4/30/12 6:32 PM, Matt Turner wrote:
> On Mon, Apr 30, 2012 at 12:11 PM, Mike Frysinger <vapier@gentoo.org> wrote:
>> On Monday 30 April 2012 12:00:59 Rich Freeman wrote:
>>> doing it wrong.  I don't like how Google develops Android in the dark,
>>> or that they bundle 1GB of third-party stuff in their Chromium source
>>> and distribute a favored binary-only derivative.
>>
>> err, they distribute a Chromium source tarball, and their build system
>> includes flags to use the system versions of those bundled libs if you so
>> choose.  i think this is a perfectly fine compromise.

Right, and the source tarball is ~175 MB. It's not perfect, but it's
also far from 1 GB. The bundled libraries are included in the tarball.

> It looks like chromium-20.0.1115.1.ebuild removes 45 bundled
> libraries.

Note that the list in the ebuild is about _excluding_ bundled libraries,
i.e. the directories listed are removed and everything else is removed.

I'm generally co-operating with upstream (also as part of that upstream,
but with limited resources at least for now) so that there are options
to use system libraries, and what's left is non-trivial to unbundle
(e.g. mesa) but it should be unbundled at some point.

> and still has TODOs in place to use the system's ffmpeg,
> hunspell, (Open?)SSL, SQLite, and libvpx.

Yes, the TODOs can definitely tell you what's left there. The list is
not comprehensive though.

Ah, and help is always welcome - with unbundling libraries, gcc-4.7
porting, and other things. Feel free to send your thoughts/questions to
chromium@g.o.

Paweł


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 203 bytes --]

Re: [gentoo-dev] Chromium bundled code

[Rich Freeman]

On Thu, May 3, 2012 at 5:34 AM, "Paweł Hajdan, Jr."
<phajdan.jr@gentoo.org> wrote:
>
> Right, and the source tarball is ~175 MB. It's not perfect, but it's
> also far from 1 GB. The bundled libraries are included in the tarball.

I was thinking about the unpacked size - which is 1001M according to
du for chromium-18.0.1025.168.tar.bz2.  That's a lot of source code...

However, my whole point wasn't to throw stones at the chromium team -
I think that they've been doing a great job of fixing this problem,
and will continue to do so.  I just was pointing out that Google's
practice of bundling dependencies wasn't to my liking, but that I
wasn't going to give them too much of a hard time precisely because
I'm not being part of the solution.

Rich

Re: [gentoo-dev] Chromium bundled code

[Walter Dnes]

On Thu, May 03, 2012 at 11:28:49AM -0400, Rich Freeman wrote

> However, my whole point wasn't to throw stones at the chromium team -
> I think that they've been doing a great job of fixing this problem,
> and will continue to do so.  I just was pointing out that Google's
> practice of bundling dependencies wasn't to my liking, but that I
> wasn't going to give them too much of a hard time precisely because
> I'm not being part of the solution.

  I think Chromium's problem is that it's based on Chrome.  And Google
is "pulling an AOL" by trying to turn Chrome into an OS for its
Chromebooks.  To paraphrase the old emacs joke... Chrom(e/ium) is a
mediocre OS that lacks a lightweight web browser.  I just did a
"pretend" build for Chromium.  I fail to understand why a *WEB BROWSER*
needs elfutils and dbus and udev as hard-coded dependancies.  The udev
dependancy is a show stopper for me, as I've migrated over to mdev.  See
https://wiki.gentoo.org/wiki/Mdev  That page is now mostly other
people's contributions.  I was the rabble-rouser who started it.

-- 
Walter Dnes <waltdnes@waltdnes.org>

Re: [gentoo-dev] Chromium bundled code

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 967 bytes --]

On Thursday 03 May 2012 17:39:30 Walter Dnes wrote:
>   I think Chromium's problem is that it's based on Chrome.

you've got that wrong.  Chrome is based on Chromium.

> And Google is "pulling an AOL" by trying to turn Chrome into an OS for its
> Chromebooks.

ChromeOS and Chrome are run as semi-separate projects.  the former uses Gentoo 
to provide a slim/secure Linux base in which you run Chrome.

> I fail to understand why a *WEB BROWSER* needs elfutils and dbus and udev as
> hard-coded dependancies.

you need to think bigger.  Chromium supports joystick inputs (which come and 
go) for playing games in the browser, so udev makes sense.  it also supports 
looking up your location, detecting when the network comes up/down, and 
kde/gnome password stores, all of which require dbus.  and with nacl, you're 
loading ELF objects, so libelf makes sense.

really though, if you don't like Chrome, then don't use it.  many people do.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] Chromium bundled code

[Luca Barbato]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/05/12 16:18, Mike Frysinger wrote:
> On Thursday 03 May 2012 17:39:30 Walter Dnes wrote:
>>   I think Chromium's problem is that it's based on Chrome.
> 
> you've got that wrong.  Chrome is based on Chromium.
> 
>> And Google is "pulling an AOL" by trying to turn Chrome into an OS for its
>> Chromebooks.
> 
> ChromeOS and Chrome are run as semi-separate projects.  the former uses Gentoo 
> to provide a slim/secure Linux base in which you run Chrome.
> 
>> I fail to understand why a *WEB BROWSER* needs elfutils and dbus and udev as
>> hard-coded dependancies.
> 
> you need to think bigger.  Chromium supports joystick inputs (which come and 
> go) for playing games in the browser, so udev makes sense.

So is it using libudev to get that information? I guess would be
possible to patch it out, probably dbus would cover that base as well.

(As soon I have some time I might dabble with a dbus integration for mdev)

lu

- -- 

Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+jJ5UACgkQ6Ex4woTpDjQOtQCZAYnPNGSZ/qlukltSyLL+zACm
vuYAoJp6uvjatUzQrJRK53Hl9kQD9IiN
=onw7
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Chromium bundled code

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 1035 bytes --]

On Thursday 03 May 2012 20:49:25 Luca Barbato wrote:
> On 03/05/12 16:18, Mike Frysinger wrote:
> > On Thursday 03 May 2012 17:39:30 Walter Dnes wrote:
> >> I fail to understand why a *WEB BROWSER* needs elfutils and dbus and
> >> udev as hard-coded dependancies.
> > 
> > you need to think bigger.  Chromium supports joystick inputs (which come
> > and go) for playing games in the browser, so udev makes sense.
> 
> So is it using libudev to get that information? I guess would be
> possible to patch it out, probably dbus would cover that base as well.

i'm not sure that info is broadcasted over dbus.  at any rate, if it is, i'm 
not sure that would gain traction upstream unless it was an improvement.  and 
if it's not going upstream, i don't Paweł is keen on maintaining it locally.

> (As soon I have some time I might dabble with a dbus integration for mdev)

we would have to make mdev available as a sep package then ... don't want 
busybox itself linking against anything beyond the C library.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] Chromium bundled code

[Luca Barbato]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/05/12 18:22, Mike Frysinger wrote:
>> (As soon I have some time I might dabble with a dbus integration for mdev)
> 
> we would have to make mdev available as a sep package then ... don't want 
> busybox itself linking against anything beyond the C library.

The integration would be mdev -> shell -> dbus or mdev -> socket ->
dbus. I consider dbus still not reliable for core services.

> -mike


- -- 

Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+kGZkACgkQ6Ex4woTpDjSAhgCeLCi65aZru86eamoOEVQzqXrH
mwgAoOX538fSV09WkUYApNL33+3uf4RX
=nnLz
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Chromium bundled code

["Paweł Hajdan, Jr."]

[-- Attachment #1: Type: text/plain, Size: 203 bytes --]

On 5/4/12 8:02 PM, Luca Barbato wrote:
> I consider dbus still not reliable for core services.

Just curious - why? I just have no idea about how dbus works or what are
possible problems with it.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 203 bytes --]

Re: [gentoo-dev] Chromium bundled code

[Luca Barbato]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 04/05/12 11:35, "Paweł Hajdan, Jr." wrote:
> On 5/4/12 8:02 PM, Luca Barbato wrote:
>> I consider dbus still not reliable for core services.
> 
> Just curious - why? I just have no idea about how dbus works or what are
> possible problems with it.

About all the integrations I know of crash if the daemon crashes and the
daemon itself tended to be frail. I hadn't checked lately if it improved
since all my usage for it is limited.

Anyway for core services I'm sold to the principle of the least
complexity and maximum separation, so that replacing/updating dbus won't
force me to reboot my system.

lu


- -- 

Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+kK4MACgkQ6Ex4woTpDjQKkACfWepG+ppIl/uapi9JjMlsF0fh
8IAAoIvzZ1kq0dJNo8q+kyXVayEZRTNM
=LST6
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Chromium bundled code

[Greg KH]

On Fri, May 04, 2012 at 11:02:01AM -0700, Luca Barbato wrote:
> On 03/05/12 18:22, Mike Frysinger wrote:
> >> (As soon I have some time I might dabble with a dbus integration for mdev)
> > 
> > we would have to make mdev available as a sep package then ... don't want 
> > busybox itself linking against anything beyond the C library.
> 
> The integration would be mdev -> shell -> dbus or mdev -> socket ->
> dbus. I consider dbus still not reliable for core services.

When was the last time dbus crashed on you?

And what would you consider "reliable" enough for "core services"?  dbus
has proven itself over _many_ years to handle all of the issues that
something like this requires very well.  It's a non-trivial thing to
implement and the authors of it have done a very good job, after
learning how to do it from other failed attempts at the same thing.

And what are you going to do when dbus moves into the kernel itself
(hint, it will be there soon)?  How are you going to not use it then?

greg k-h

Re: [gentoo-dev] Chromium bundled code

[Dale]

Greg KH wrote:
> On Fri, May 04, 2012 at 11:02:01AM -0700, Luca Barbato wrote:
>> On 03/05/12 18:22, Mike Frysinger wrote:
>>>> (As soon I have some time I might dabble with a dbus integration for mdev)
>>>
>>> we would have to make mdev available as a sep package then ... don't want 
>>> busybox itself linking against anything beyond the C library.
>>
>> The integration would be mdev -> shell -> dbus or mdev -> socket ->
>> dbus. I consider dbus still not reliable for core services.
> 
> When was the last time dbus crashed on you?
> 
> And what would you consider "reliable" enough for "core services"?  dbus
> has proven itself over _many_ years to handle all of the issues that
> something like this requires very well.  It's a non-trivial thing to
> implement and the authors of it have done a very good job, after
> learning how to do it from other failed attempts at the same thing.
> 
> And what are you going to do when dbus moves into the kernel itself
> (hint, it will be there soon)?  How are you going to not use it then?
> 
> greg k-h
> 
> 


This question is not directed at me but I'll give a response to my
experience a few months ago.  I woke up to my system fans blowing like
crazy.  Trust me, if you can hear noise on a HAF-932, they are spinning
pretty good.  It was mostly air I was hearing but anyway.  I use KDE and
have Konsole open at all times.  I switched to the desktop with it,
after noticing on Gkrellm that my CPU was maxed out and that almost all
my ram was in use and some swap too.  I don't mean cached or anything
either, I mean actively in use.

At any rate, when it finally switched to the desktop with Konsole on it,
which took a bit, I ran top.  At the top for both CPU and memory usage
was dbus.  I tried to restart the dbus service, thinking it would kill
it and restart without all the ram and CPU usage.  I could then logout
and back in, maybe.  I never got my prompt back and it never showed dbus
as stopped either.

I then switched to a console.  I did a 'rc boot' and it was slowly
switching to it and did but it couldn't stop the dbus service.  I just
typed in reboot and let it restart from scratch.

Was it dbus itself, I dunno for sure.  I am sure it was dbus that was
maxing out my CPU and ram.  I did recompile dbus after the reboot and it
has not done it since.  If I could reproduce it or had more info, I
would have mentioned it when it happened.  I'm thinking rays from Mars
or something.  ;-)    It wasn't hardware either.  This system has been
running fine ever since.

By the way, I have 16Gbs of ram.  If I recall correctly, dbus was using
over 14Gbs of ram and something was using swap.  Keep in mind, I had KDE
running with Seamonkey, Konsole, Konqueror and a couple other apps open.
 I use about 1.5Gbs when my desktop is in normal use.  Swappiness is set
to 20.  In other words, only use swap when it is getting deep.  It was
using half my swap so it must have been pretty deep.

So, even dbus can have a bad day at times.  Sure wish I knew what caused
it tho.

Dale

:-)  :-)

-- 
I am only responsible for what I said ... Not for what you understood or
how you interpreted my words!

Miss the compile output?  Hint:
EMERGE_DEFAULT_OPTS="--quiet-build=n"

Re: [gentoo-dev] Chromium bundled code

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 258 bytes --]

On Fri, 4 May 2012 18:02:05 -0700
Greg KH <gregkh@gentoo.org> wrote:
> And what are you going to do when dbus moves into the kernel itself
> (hint, it will be there soon)?

Why stop at dbus? Why isn't libxml2 in the kernel yet?

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Chromium bundled code

[Greg KH]

On Sat, May 05, 2012 at 05:35:22PM +0100, Ciaran McCreesh wrote:
> On Fri, 4 May 2012 18:02:05 -0700
> Greg KH <gregkh@gentoo.org> wrote:
> > And what are you going to do when dbus moves into the kernel itself
> > (hint, it will be there soon)?
> 
> Why stop at dbus? Why isn't libxml2 in the kernel yet?

Because kernel developers are merely crazy, not insane.

Re: [gentoo-dev] Chromium bundled code

[Luca Barbato]

On 04/05/12 18:02, Greg KH wrote:

> When was the last time dbus crashed on you?

Last time I used with bluez? I think about few months ago, I hadn't time
to debug the issue and I tend not to use stuff I known broken.

I know that's a chicken egg issue =|

I'm not sure if connman hanging randomly is related to dbus or connman
itself, again I hadn't had time to check what's exactly wrong.

> And what would you consider "reliable" enough for "core services"?

No dependency beside libc.

> dbus
> has proven itself over _many_ years to handle all of the issues that
> something like this requires very well.  It's a non-trivial thing to
> implement and the authors of it have done a very good job, after
> learning how to do it from other failed attempts at the same thing.

Yet it crashes in some situations. My fault for not helping debugging
them I guess. Again, I had something more interesting to do.

> And what are you going to do when dbus moves into the kernel itself
> (hint, it will be there soon)?

Disabling it if I don't need it, as everybody in the world does disable
the posix message queues?

> How are you going to not use it then?

I guess freebsd is still a supported platform for enlightenment and all
the programs I use.

lu

-- 

Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero

Re: [gentoo-dev] Chromium bundled code

[Walter Dnes]

On Thu, May 03, 2012 at 09:22:11PM -0400, Mike Frysinger wrote

> we would have to make mdev available as a sep package then ... don't
> want busybox itself linking against anything beyond the C library.

  Busybox, including its mdev functionality, is targetted at small and
embedded systems.  I don't think that'll change, at least I hope it
doesn't.  What could work is a shim or compatability layer that gets
called, and pre-processes requests and forwards them to mdev.

-- 
Walter Dnes <waltdnes@waltdnes.org>

Re: [gentoo-dev] Chromium bundled code

[Luca Barbato]

On 04/05/12 14:35, Walter Dnes wrote:
>  What could work is a shim or compatability layer that gets
> called, and pre-processes requests and forwards them to mdev.

That's my idea =)

lu

-- 

Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero

Re: [gentoo-dev] Chromium bundled code

[Greg KH]

On Fri, May 04, 2012 at 02:52:33PM -0700, Luca Barbato wrote:
> On 04/05/12 14:35, Walter Dnes wrote:
> >  What could work is a shim or compatability layer that gets
> > called, and pre-processes requests and forwards them to mdev.
> 
> That's my idea =)

and then, look, you have reimplemented udev.

{sigh}

Re: [gentoo-dev] Chromium bundled code

[Walter Dnes]

On Fri, May 04, 2012 at 05:59:45PM -0700, Greg KH wrote
> On Fri, May 04, 2012 at 02:52:33PM -0700, Luca Barbato wrote:
> > On 04/05/12 14:35, Walter Dnes wrote:
> > >  What could work is a shim or compatability layer that gets
> > > called, and pre-processes requests and forwards them to mdev.
> > 
> > That's my idea =)
> 
> and then, look, you have reimplemented udev.
> 
> {sigh}

  Actually, more like what udev *USED TO BE*, namely a simple devicei
manager.

-- 
Walter Dnes <waltdnes@waltdnes.org>

Re: [gentoo-dev] Chromium bundled code

[Olivier Crête]

[-- Attachment #1: Type: text/plain, Size: 724 bytes --]

On Mon, 2012-05-07 at 18:23 -0400, Walter Dnes wrote:
> On Fri, May 04, 2012 at 05:59:45PM -0700, Greg KH wrote
> > On Fri, May 04, 2012 at 02:52:33PM -0700, Luca Barbato wrote:
> > > On 04/05/12 14:35, Walter Dnes wrote:
> > > >  What could work is a shim or compatability layer that gets
> > > > called, and pre-processes requests and forwards them to mdev.
> > > 
> > > That's my idea =)
> > 
> > and then, look, you have reimplemented udev.
> > 
> > {sigh}
> 
>   Actually, more like what udev *USED TO BE*, namely a simple devicei
> manager.

Maybe Greg understands how udev was and how it should be better than you
do, since he wrote it.


-- 
Olivier Crête
tester@gentoo.org
Gentoo Developer

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Chromium bundled code

[Patrick Lauer]

On 05/08/12 07:16, Olivier Crête wrote:
> On Mon, 2012-05-07 at 18:23 -0400, Walter Dnes wrote:
>> On Fri, May 04, 2012 at 05:59:45PM -0700, Greg KH wrote
>>> On Fri, May 04, 2012 at 02:52:33PM -0700, Luca Barbato wrote:
>>>> On 04/05/12 14:35, Walter Dnes wrote:
>>>>>  What could work is a shim or compatability layer that gets
>>>>> called, and pre-processes requests and forwards them to mdev.
>>>> That's my idea =)
>>> and then, look, you have reimplemented udev.
>>>
>>> {sigh}
>>   Actually, more like what udev *USED TO BE*, namely a simple devicei
>> manager.
> Maybe Greg understands how udev was 
... and of course the horrors that were called "devfs" and such - we
remember :)
> and how it should be better than you
> do,
err, that's bad. Maybe I know my needs better than other people? Maybe
my needs don't completely overlap with those of other people. Maybe
their vision of a tightly coupled everything doesn't even cover my
usecases nicely ...
>  since he wrote it.
>
>
Classical argumentum ad verecundiam, you win a cookie.

Re: [gentoo-dev] Chromium bundled code

[Luca Barbato]

On 04/05/12 17:59, Greg KH wrote:
> On Fri, May 04, 2012 at 02:52:33PM -0700, Luca Barbato wrote:
>> On 04/05/12 14:35, Walter Dnes wrote:
>>>  What could work is a shim or compatability layer that gets
>>> called, and pre-processes requests and forwards them to mdev.
>>
>> That's my idea =)
> 
> and then, look, you have reimplemented udev.
> 

I think that's the whole point of the exercise.


lu


-- 

Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero

Re: [gentoo-dev] Chromium bundled code

[David Leverton]

Luca Barbato wrote:
> On 03/05/12 16:18, Mike Frysinger wrote:
>> you need to think bigger.  Chromium supports joystick inputs (which come and
>> go) for playing games in the browser, so udev makes sense.
>
> So is it using libudev to get that information? I guess would be
> possible to patch it out, probably dbus would cover that base as well.
>
> (As soon I have some time I might dabble with a dbus integration for mdev)

If it really is just for joysticks etc it might be worth seeing if it 
can be made to use XInput instead.  Maybe upstream had a specific reason 
not do it that way in the first place, but in general, X apps really 
shouldn't be touching the input devices directly.

Re: [gentoo-dev] Chromium bundled code

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 821 bytes --]

On Friday 04 May 2012 15:25:58 David Leverton wrote:
> Luca Barbato wrote:
> > On 03/05/12 16:18, Mike Frysinger wrote:
> >> you need to think bigger.  Chromium supports joystick inputs (which come
> >> and go) for playing games in the browser, so udev makes sense.
> > 
> > So is it using libudev to get that information? I guess would be
> > possible to patch it out, probably dbus would cover that base as well.
> > 
> > (As soon I have some time I might dabble with a dbus integration for
> > mdev)
> 
> If it really is just for joysticks etc it might be worth seeing if it
> can be made to use XInput instead.  Maybe upstream had a specific reason
> not do it that way in the first place, but in general, X apps really
> shouldn't be touching the input devices directly.

why require X ? :)
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] Chromium bundled code

[David Leverton]

Mike Frysinger wrote:
> On Friday 04 May 2012 15:25:58 David Leverton wrote:
>> If it really is just for joysticks etc it might be worth seeing if it
>> can be made to use XInput instead.  Maybe upstream had a specific reason
>> not do it that way in the first place, but in general, X apps really
>> shouldn't be touching the input devices directly.
>
> why require X ? :)
> -mike

I wasn't aware that Chromium on Linux supported anything else (and at 
least the current ebuild has hard deps on X libraries), but when it is 
running on X it ought to follow X conventions, even if it does something 
else in other circumstances.

Re: [gentoo-dev] Chromium bundled code

[Alec Warner]

On Thu, May 3, 2012 at 11:39 PM, Walter Dnes <waltdnes@waltdnes.org> wrote:
> On Thu, May 03, 2012 at 11:28:49AM -0400, Rich Freeman wrote
>
>> However, my whole point wasn't to throw stones at the chromium team -
>> I think that they've been doing a great job of fixing this problem,
>> and will continue to do so.  I just was pointing out that Google's
>> practice of bundling dependencies wasn't to my liking, but that I
>> wasn't going to give them too much of a hard time precisely because
>> I'm not being part of the solution.
>
>  I think Chromium's problem is that it's based on Chrome.  And Google
> is "pulling an AOL" by trying to turn Chrome into an OS for its
> Chromebooks.  To paraphrase the old emacs joke... Chrom(e/ium) is a
> mediocre OS that lacks a lightweight web browser.  I just did a
> "pretend" build for Chromium.  I fail to understand why a *WEB BROWSER*

I would argue that the Chrome Team's idea of what a 'WEB BROWSER' is
and your idea of what a 'WEB BROWSER' is are vastly divergent. That is
totally OK and you are free to use whatever software you prefer. I
somehow doubt Chrom{e,ium} is losing tons of users due to their udev /
dbus / etc requirements.

Disclaimer, I work at Google (but not on any Chrom{e,ium}(OS) related projects.)

-A

> needs elfutils and dbus and udev as hard-coded dependancies.  The udev
> dependancy is a show stopper for me, as I've migrated over to mdev.  See
> https://wiki.gentoo.org/wiki/Mdev  That page is now mostly other
> people's contributions.  I was the rabble-rouser who started it.
>
> --
> Walter Dnes <waltdnes@waltdnes.org>
>

Re: [gentoo-dev] Chromium bundled code

[Luca Barbato]

On 04/05/12 01:37, Alec Warner wrote:
> I would argue that the Chrome Team's idea of what a 'WEB BROWSER' is
> and your idea of what a 'WEB BROWSER' is are vastly divergent. That is
> totally OK and you are free to use whatever software you prefer. I
> somehow doubt Chrom{e,ium} is losing tons of users due to their udev /
> dbus / etc requirements.

If dbus and libudev are just for fringe features might be nice disable
them. I wonder if there isn't already a setting for it. chrome for
android won't use them anyway.



-- 

Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero

Re: [gentoo-dev] Chromium bundled code

[Mike Gilbert]

On Fri, May 4, 2012 at 2:03 PM, Luca Barbato <lu_zero@gentoo.org> wrote:
> On 04/05/12 01:37, Alec Warner wrote:
>> I would argue that the Chrome Team's idea of what a 'WEB BROWSER' is
>> and your idea of what a 'WEB BROWSER' is are vastly divergent. That is
>> totally OK and you are free to use whatever software you prefer. I
>> somehow doubt Chrom{e,ium} is losing tons of users due to their udev /
>> dbus / etc requirements.
>
> If dbus and libudev are just for fringe features might be nice disable
> them. I wonder if there isn't already a setting for it. chrome for
> android won't use them anyway.
>

I don't see a user-controllable setting for dbus or udev. Rather, it
checks for OS == "Linux".

My 2 cents: The Chromium project really doesn't have any motivation to
make it optional since their end product is Google Chrome and they
target a given version of Ubuntu. I think a patch to make them
optional might be accepted, but it probably isn't going to happen
otherwise.

Re: [gentoo-dev] Chromium bundled code

["Paweł Hajdan, Jr."]

[-- Attachment #1: Type: text/plain, Size: 535 bytes --]

On 5/4/12 8:21 PM, Mike Gilbert wrote:
> My 2 cents: The Chromium project really doesn't have any motivation to
> make it optional since their end product is Google Chrome and they
> target a given version of Ubuntu. I think a patch to make them
> optional might be accepted, but it probably isn't going to happen
> otherwise.

Another point is that too many USE flags for such a big and complex
package as www-client/chromium would make testing much much harder, and
create many configurations upstream would not support.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 203 bytes --]

Re: [gentoo-dev] Chromium bundled code

[Luca Barbato]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 04/05/12 11:37, "Paweł Hajdan, Jr." wrote:
> On 5/4/12 8:21 PM, Mike Gilbert wrote:
>> My 2 cents: The Chromium project really doesn't have any motivation to
>> make it optional since their end product is Google Chrome and they
>> target a given version of Ubuntu. I think a patch to make them
>> optional might be accepted, but it probably isn't going to happen
>> otherwise.
> 
> Another point is that too many USE flags for such a big and complex
> package as www-client/chromium would make testing much much harder, and
> create many configurations upstream would not support.

I'll check with upstream if that would be a huge problem for them, we
have 6 useflags and we'd bump them to 8. Firefox has twice of them.

If nobody else wants to I could have a look and see how hard is to make
that nicer for our non-udev/non-dbus users on linux.

lu

- -- 

Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+kMHwACgkQ6Ex4woTpDjTTAgCfXtMJFJjB5ZH08u0Nb7yKmkqv
/GwAoNejWgUcHaMWnD6e8Bgr/+V/cYDA
=CCQe
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Chromium bundled code

[Greg KH]

On Fri, May 04, 2012 at 12:39:40PM -0700, Luca Barbato wrote:
> On 04/05/12 11:37, "Paweł Hajdan, Jr." wrote:
> > On 5/4/12 8:21 PM, Mike Gilbert wrote:
> >> My 2 cents: The Chromium project really doesn't have any motivation to
> >> make it optional since their end product is Google Chrome and they
> >> target a given version of Ubuntu. I think a patch to make them
> >> optional might be accepted, but it probably isn't going to happen
> >> otherwise.
> > 
> > Another point is that too many USE flags for such a big and complex
> > package as www-client/chromium would make testing much much harder, and
> > create many configurations upstream would not support.
> 
> I'll check with upstream if that would be a huge problem for them, we
> have 6 useflags and we'd bump them to 8. Firefox has twice of them.
> 
> If nobody else wants to I could have a look and see how hard is to make
> that nicer for our non-udev/non-dbus users on linux.

Why do we really care about non-udev and non-dbus users?  It's only
going to get worse and worse if people don't want to use these core,
base libaries of the Linux "stack".

Yes, you can create a system without them, but in this day and age, why
would you want to?  Are you saving memory? (nope), time? (nope),
complexity? (not really).

Remember, you are passing the complexity of insisting that you do not
want these things to the people managing the packages and trying to
support the system in so many different combinations.  Why someone would
want to run Chromium on a system without udev or dbus is just looney...

greg k-h

Re: [gentoo-dev] Chromium bundled code

[Greg KH]

On Fri, May 04, 2012 at 05:58:24PM -0700, Greg KH wrote:
> On Fri, May 04, 2012 at 12:39:40PM -0700, Luca Barbato wrote:
> > On 04/05/12 11:37, "Paweł Hajdan, Jr." wrote:
> > > On 5/4/12 8:21 PM, Mike Gilbert wrote:
> > >> My 2 cents: The Chromium project really doesn't have any motivation to
> > >> make it optional since their end product is Google Chrome and they
> > >> target a given version of Ubuntu. I think a patch to make them
> > >> optional might be accepted, but it probably isn't going to happen
> > >> otherwise.
> > > 
> > > Another point is that too many USE flags for such a big and complex
> > > package as www-client/chromium would make testing much much harder, and
> > > create many configurations upstream would not support.
> > 
> > I'll check with upstream if that would be a huge problem for them, we
> > have 6 useflags and we'd bump them to 8. Firefox has twice of them.
> > 
> > If nobody else wants to I could have a look and see how hard is to make
> > that nicer for our non-udev/non-dbus users on linux.
> 
> Why do we really care about non-udev and non-dbus users?  It's only
> going to get worse and worse if people don't want to use these core,
> base libaries of the Linux "stack".
> 
> Yes, you can create a system without them, but in this day and age, why
> would you want to?  Are you saving memory? (nope), time? (nope),
> complexity? (not really).
> 
> Remember, you are passing the complexity of insisting that you do not
> want these things to the people managing the packages and trying to
> support the system in so many different combinations.  Why someone would
> want to run Chromium on a system without udev or dbus is just looney...

s/Chromium/Chrome/

Re: [gentoo-dev] Chromium bundled code

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 491 bytes --]

On Friday 04 May 2012 21:06:52 Greg KH wrote:
> On Fri, May 04, 2012 at 05:58:24PM -0700, Greg KH wrote:
> > Remember, you are passing the complexity of insisting that you do not
> > want these things to the people managing the packages and trying to
> > support the system in so many different combinations.  Why someone would
> > want to run Chromium on a system without udev or dbus is just looney...
> 
> s/Chromium/Chrome/

for the purposes of your point, either works
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] Chromium bundled code

[Walter Dnes]

On Fri, May 04, 2012 at 06:06:52PM -0700, Greg KH wrote
> > Remember, you are passing the complexity of insisting that you do not
> > want these things to the people managing the packages and trying to
> > support the system in so many different combinations.  Why someone would
> > want to run Chromium on a system without udev or dbus is just looney...
> 
> s/Chromium/Chrome/

  Ahem...

=====================================================================
waltdnes@d531 ~ $ USE="icu" emerge -pv chromium

These are the packages that would be merged, in order:

Calculating dependencies... done!

!!! All ebuilds that could satisfy "sys-fs/udev" have been masked.
!!! One of the following masked packages is required to complete your request:
- sys-fs/udev-9999::gentoo (masked by: package.mask, missing keyword)
/etc/portage/package.mask:

- sys-fs/udev-182-r3::gentoo (masked by: package.mask, ~x86 keyword)
- sys-fs/udev-182-r2::gentoo (masked by: package.mask, ~x86 keyword)
- sys-fs/udev-171-r5::gentoo (masked by: package.mask)
- sys-fs/udev-164-r2::gentoo (masked by: package.mask)
- sys-fs/udev-151-r4::gentoo (masked by: package.mask)
- sys-fs/udev-149::gentoo (masked by: package.mask)
- sys-fs/udev-146-r1::gentoo (masked by: package.mask)
- sys-fs/udev-141-r1::gentoo (masked by: package.mask, ~x86 keyword)
- sys-fs/udev-141::gentoo (masked by: package.mask)
- sys-fs/udev-124-r2::gentoo (masked by: package.mask)
- sys-fs/udev-124-r1::gentoo (masked by: package.mask)
- sys-fs/udev-119::gentoo (masked by: package.mask)
- sys-fs/udev-115-r1::gentoo (masked by: package.mask)
- sys-fs/udev-114::gentoo (masked by: package.mask)

(dependency required by "www-client/chromium-18.0.1025.151" [ebuild])
(dependency required by "chromium" [argument])
For more information, see the MASKED PACKAGES section in the emerge
man page or refer to the Gentoo Handbook.
=====================================================================

  OK, I temporarily unmask udev...

=====================================================================
waltdnes@d531 ~ $ USE="icu" emerge -pv chromium

These are the packages that would be merged, in order:

Calculating dependencies... done!

!!! All ebuilds that could satisfy ">=sys-apps/dbus-1.4.16" have been masked.
!!! One of the following masked packages is required to complete your request:
- sys-apps/dbus-1.4.20::gentoo (masked by: package.mask)
/etc/portage/package.mask:

- sys-apps/dbus-1.4.18::gentoo (masked by: package.mask)
- sys-apps/dbus-1.4.16-r2::gentoo (masked by: package.mask, ~x86
  keyword)
- sys-apps/dbus-1.4.16::gentoo (masked by: package.mask)

(dependency required by "dev-libs/dbus-glib-0.98" [ebuild])
(dependency required by "www-client/chromium-18.0.1025.151" [ebuild])
(dependency required by "chromium" [argument])
For more information, see the MASKED PACKAGES section in the emerge
man page or refer to the Gentoo Handbook.
=====================================================================

  QED.

-- 
Walter Dnes <waltdnes@waltdnes.org>

Re: [gentoo-dev] Chromium bundled code

[Richard Yao]

[-- Attachment #1: Type: text/plain, Size: 412 bytes --]

On 05/04/12 20:58, Greg KH wrote:
> Why do we really care about non-udev and non-dbus users?  It's only
> going to get worse and worse if people don't want to use these core,
> base libaries of the Linux "stack".

I was under the impression that in order for there to be a Linux stack,
the Linux tree would need to include a userland in addition to a kernel.
Does the Linux Foundation plan to do this?


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]

Re: [gentoo-dev] Chromium bundled code

[Greg KH]

On Fri, May 04, 2012 at 09:27:05PM -0400, Richard Yao wrote:
> On 05/04/12 20:58, Greg KH wrote:
> > Why do we really care about non-udev and non-dbus users?  It's only
> > going to get worse and worse if people don't want to use these core,
> > base libaries of the Linux "stack".
> 
> I was under the impression that in order for there to be a Linux stack,
> the Linux tree would need to include a userland in addition to a kernel.

Huh?  Don't you consider the kernel + glibc + xorg today a good "Linux
stack"?  Isn't the "Android stack" another example of a good "Linux
stack"?

> Does the Linux Foundation plan to do this?

Not at all, the Linux Foundation is not doing any of this.  The Linux
Foundation is a vendor-netural orginization that provides a "safe" place
for companies and the community to come together and collaborate on a
number of different projects.  It also provides a place that sponsors a
few people to work in a vendor-netural way on projects they wish to work
on, with no say by the LF or anyone else on what they do with their
time.  And it supports the kernel.org orginization in various ways as
well (financial and legal and administration.)

Hope this helps,

gre k-h

Re: [gentoo-dev] Chromium bundled code

[Chí-Thanh Christopher Nguyễn]

Greg KH schrieb:
> On Fri, May 04, 2012 at 09:27:05PM -0400, Richard Yao wrote:
>> On 05/04/12 20:58, Greg KH wrote:
>>> Why do we really care about non-udev and non-dbus users?  It's only
>>> going to get worse and worse if people don't want to use these core,
>>> base libaries of the Linux "stack".
>>
>> I was under the impression that in order for there to be a Linux stack,
>> the Linux tree would need to include a userland in addition to a kernel.
> 
> Huh?  Don't you consider the kernel + glibc + xorg today a good "Linux
> stack"?  Isn't the "Android stack" another example of a good "Linux
> stack"?

I'd say that Android is an operating system based on Linux. It is not
'the Linux "stack"'.
I think he was wondering whether the lock-in between dbus, udev and the
Linux kernel will reach proportions where they will be distributed in
one source tree.


Best regards,
Chí-Thanh Christopher Nguyễn

Re: [gentoo-dev] Chromium bundled code

[Rich Freeman]

On Fri, May 4, 2012 at 9:50 PM, Chí-Thanh Christopher Nguyễn
<chithanh@gentoo.org> wrote:
> I'd say that Android is an operating system based on Linux. It is not
> 'the Linux "stack"'.
> I think he was wondering whether the lock-in between dbus, udev and the
> Linux kernel will reach proportions where they will be distributed in
> one source tree.

Well, I think that all of this is at the heart of the debate.  I don't
see whether the source trees are merged as being terribly important -
the issue is whether the level of integration makes them difficult to
peel apart.

This is just the vertical integration debate all over again.  If you
want to use gnome, thou shalt use systemd.  If you want to use
Chromium, thou shalt use udev, and so on.  I can't wait until we hit
the point where if you want to use your favorite browser you have to
install the maintainer's favorite DE, sysvinit, etc.

The only solution I see to getting back to the "unix way" is to agree
upon standard APIs, but I think that is many years off.  Most of these
technologies are very new, and rapidly evolving.  Google themselves
have shown with platforms like Android that compatibility is not of
terrible importance to them beyond the application API (how many times
have they broken the camera driver binary interface?), and of course
Linux is famous for breaking driver-level binary interfaces, though
this is mitigated by the fact that outside of Android almost everybody
makes their drivers open-source, or they actually support their
drivers for more than six months.

The next year or two will be an interesting experiment for the Linux
community.  Will the "unix way" prevail, or does the future lie in
highly integrated tools, that generally do not interoperate, but which
provide much greater functionality?

Rich

Re: [gentoo-dev] Chromium bundled code

[Richard Yao]

[-- Attachment #1: Type: text/plain, Size: 2187 bytes --]

On 05/04/12 21:33, Greg KH wrote:
> On Fri, May 04, 2012 at 09:27:05PM -0400, Richard Yao wrote:
>> On 05/04/12 20:58, Greg KH wrote:
>>> Why do we really care about non-udev and non-dbus users?  It's only
>>> going to get worse and worse if people don't want to use these core,
>>> base libaries of the Linux "stack".
>>
>> I was under the impression that in order for there to be a Linux stack,
>> the Linux tree would need to include a userland in addition to a kernel.
> 
> Huh?  Don't you consider the kernel + glibc + xorg today a good "Linux
> stack"?  Isn't the "Android stack" another example of a good "Linux
> stack"?

glibc and xorg can run on top of Linux, but I would not call them a
Linux stack. glibc is the C standard library for the GNU operating
system while xorg is a windowing system intended for UNIX operating
systems. People have them working on top of Linux, but people have them
working on top of other kernels too. The Debian developers have both
components working on top of FreeBSD's kernel as well as HURD, which is
glibc's native kernel.

As for the Android stack, it is currently used on Linux, but nothing
prevents it from being used on other kernels. In specific, both Solaris
and FreeBSD the ability to run software built against the Linux kernel
ABI. If one were sufficiently motivated, it should be possible to run
the Android stack on either of them.

My understanding of a stack is that it generally includes a kernel, a
libc, a C compiler, an assembler, a linker, a bootloader, an init
system, a getty implementation, a command shell, a text editor and some
basic UNIX commands (e.g. cp, mv, rm). There is some userland software
in the Linux tree in ./usr and ./tools, but aside from the kernel, I
cannot find anything that constitutes a stack, or even a stack minus a
few components.

Plenty of regressions stem from using other projects' stacks on Linux.
The following regression was particularly painful:

https://bugzilla.redhat.com/show_bug.cgi?id=638477

I would love to use the Linux stack on my Linux systems to avoid such
regressions, but I cannot find one. If one exists, please let me know.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]

Re: [gentoo-dev] busybox[sep-usr] support for mounting /usr w/out hassle

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 3963 bytes --]

On Mon, Apr 30, 2012 at 12:00:59PM -0400, Rich Freeman wrote:
> On Mon, Apr 30, 2012 at 4:05 AM, Tony "Chainsaw" Vroon
> <chainsaw@gentoo.org> wrote:
> > Binaries that are essential for system boot, and must be available in
> > single user mode go in /bin and /sbin, with their libraries in /lib.
> > This allows for /usr to be:
> > 1) marked read-only for NFS mounts, which some of us rely on
> > 2) inside of an LVM2 container, allowing for / to be (very) small
> > 3) on a squashfs filesystem, in order to save space
> 
> These are all things easily supported with an initramfs.  In fact,
> initramfs-based solutions allow the same sorts of things to be done
> with all the other filesystems and not just /usr.

This is correct.

> > Trying to second-guess my motivation, and trying to undo unanimous
> > council votes simply because your opinion is different, really has to
> > stop.
> 
> I don't think anybody is trying to undo council votes - people are
> just speculating as to what they voted on.  The easiest solution is
> for somebody to say "I'm John Smith, and I am speaking officially for
> the council, and we agree that what was decided upon is X."

Yes, this is correct. I read the log over several times and it isn't
clear what the council actually voted on. Tony, it seems clear that you want to
mandate that gentoo in its default configuration will support separate
/usr without an initramfs. The thing that isn't clear is whether the
rest of the council wants to do that. In reading the log, there was
definite uncertainty about whether the vote was just to continue
supporting /usr as a separate configuration or to mandate how
separate /usr was going to be supported in the default configuration.

> It seems pretty clear that everybody wants to support a separate /usr.
>  We even have multiple supported solutions, including an initramfs, a
> use flag on busybox, and I believe somebody posted a script that can
> be run during early boot to mount /usr.  It sounds like the only thing
> that isn't supported is "doing nothing" - but with Gentoo if you "do
> nothing" you don't get an installed system that works on any
> configuration.
 
Rich, you are absolutely right. There is not an argument anywhere about
whether separate /usr is supported.

> > I feel a lot better about vapier's pragmatic approach then I do about
> > udev/systemd upstream's ability and motivation to support current
> > systems. If you had any doubts about whether udev was part of the
> > problem, consider what tarball you will have to extract it from in future.
> 
> Well, if others feel differently about the direction udev is taking,
> they can of course just fork it.
> 
> I can't say I'm terribly excited about the amount of vertical
> integration going on.  I don't run Gnome, and I don't run Unity.  I
> really do prefer the unix way.
 
 I'm not excited about parts of the vertical integration either. Newer
 versions of gnome are going to start requiring systemd from what I've
 heard, and I disagree with that level of integration.

> However, I don't contribute much to those upstream projects, and I
> don't see much value in telling a bunch of people who do that they are
> doing it wrong.  I don't like how Google develops Android in the dark,
> or that they bundle 1GB of third-party stuff in their Chromium source
> and distribute a favored binary-only derivative.  However, I do like
> that they're giving me all of that stuff essentially for free, and so
> beyond the odd blog post I try not to give them too hard a time.
> 
> In the same way I think we need to give the maintainers of these
> projects in Gentoo some slack, or join those projects and help them to
> address your needs.  It is a lot easier to tell others what to do than
> to help make it happen, but a volunteer-based project like Gentoo
> needs the latter more than the former.

Agreed.

William


[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]