Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Gentoo: Dev

Chromium bundled code

 

 

First page Previous page 1 2 Next page Last page  View All Gentoo dev RSS feed   Index | Next | Previous | View Threaded


gregkh at gentoo

May 4, 2012, 5:58 PM

Post #26 of 44 (702 views)
Permalink
Re: Chromium bundled code [In reply to]

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


gregkh at gentoo

May 4, 2012, 5:59 PM

Post #27 of 44 (699 views)
Permalink
Re: Chromium bundled code [In reply to]

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}


gregkh at gentoo

May 4, 2012, 6:02 PM

Post #28 of 44 (702 views)
Permalink
Re: Chromium bundled code [In reply to]

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


gregkh at gentoo

May 4, 2012, 6:06 PM

Post #29 of 44 (701 views)
Permalink
Re: Chromium bundled code [In reply to]

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/


ryao at cs

May 4, 2012, 6:27 PM

Post #30 of 44 (708 views)
Permalink
Re: Chromium bundled code [In reply to]

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?
Attachments: signature.asc (0.88 KB)


gregkh at gentoo

May 4, 2012, 6:33 PM

Post #31 of 44 (698 views)
Permalink
Re: Chromium bundled code [In reply to]

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


chithanh at gentoo

May 4, 2012, 6:50 PM

Post #32 of 44 (703 views)
Permalink
Re: Chromium bundled code [In reply to]

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


vapier at gentoo

May 4, 2012, 7:00 PM

Post #33 of 44 (693 views)
Permalink
Re: Chromium bundled code [In reply to]

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
Attachments: signature.asc (0.82 KB)


rich0 at gentoo

May 4, 2012, 7:06 PM

Post #34 of 44 (689 views)
Permalink
Re: Chromium bundled code [In reply to]

On Fri, May 4, 2012 at 9:50 PM, Chí-Thanh Christopher Nguyễn
<chithanh [at] gentoo> 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


rdalek1967 at gmail

May 4, 2012, 7:11 PM

Post #35 of 44 (696 views)
Permalink
Re: Chromium bundled code [In reply to]

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"


ryao at cs

May 5, 2012, 9:32 AM

Post #36 of 44 (706 views)
Permalink
Re: Chromium bundled code [In reply to]

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.
Attachments: signature.asc (0.88 KB)


ciaran.mccreesh at googlemail

May 5, 2012, 9:35 AM

Post #37 of 44 (701 views)
Permalink
Re: Chromium bundled code [In reply to]

On Fri, 4 May 2012 18:02:05 -0700
Greg KH <gregkh [at] gentoo> 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
Attachments: signature.asc (0.19 KB)


gregkh at gentoo

May 5, 2012, 10:53 AM

Post #38 of 44 (690 views)
Permalink
Re: Chromium bundled code [In reply to]

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 [at] gentoo> 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.


waltdnes at waltdnes

May 7, 2012, 3:23 PM

Post #39 of 44 (672 views)
Permalink
Re: Chromium bundled code [In reply to]

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 [at] waltdnes>


waltdnes at waltdnes

May 7, 2012, 3:32 PM

Post #40 of 44 (771 views)
Permalink
Re: Chromium bundled code [In reply to]

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 [at] d53 ~ $ 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 [at] d53 ~ $ 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 [at] waltdnes>


tester at gentoo

May 7, 2012, 4:16 PM

Post #41 of 44 (683 views)
Permalink
Re: Chromium bundled code [In reply to]

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 [at] gentoo
Gentoo Developer
Attachments: signature.asc (0.19 KB)


patrick at gentoo

May 7, 2012, 5:46 PM

Post #42 of 44 (680 views)
Permalink
Re: Chromium bundled code [In reply to]

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.


lu_zero at gentoo

May 7, 2012, 7:54 PM

Post #43 of 44 (682 views)
Permalink
Re: Chromium bundled code [In reply to]

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


lu_zero at gentoo

May 7, 2012, 8:57 PM

Post #44 of 44 (673 views)
Permalink
Re: Chromium bundled code [In reply to]

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

First page Previous page 1 2 Next page Last page  View All Gentoo dev RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.