Neil Bothwick writes:
> On Mon, 11 Jan 2016 23:55:27 +0100, lee wrote:
>
>> > Firstly, things like Flash and Skype are not special cases, they are
>> > widely used and many of us have to use them, whether we like it or
>> > not.
>>
>> They are special cases. Flash never really worked, and whe
On Mon, 11 Jan 2016 23:55:27 +0100, lee wrote:
> > Firstly, things like Flash and Skype are not special cases, they are
> > widely used and many of us have to use them, whether we like it or
> > not.
>
> They are special cases. Flash never really worked, and when it does,
> it's pretty much un
Neil Bothwick writes:
> On Mon, 11 Jan 2016 08:25:05 +0100, lee wrote:
>
> [...]
>>
>> That there are a few special cases for which some people still need it
>> doesn't mean that everyone should be forced to use a multilib profile
>> when 100% of the software they're running is 64bit.
>
> First
On Mon, 11 Jan 2016 08:25:05 +0100, lee wrote:
> >> > What about things like flash plugins? Those are often wanted on
> >> > desktops and need multilib.
> >>
> >> Flash sucks, and fortunately, it's dead.
> >
> > It should be, but it's not. There are still many sites that require
> > it.
>
Neil Bothwick writes:
> On Fri, 08 Jan 2016 21:37:55 +0100, lee wrote:
>
>> > What about things like flash plugins? Those are often wanted on
>> > desktops and need multilib.
>>
>> Flash sucks, and fortunately, it's dead.
>
> It should be, but it's not. There are still many sites that require
On Fri, 08 Jan 2016 21:37:55 +0100, lee wrote:
> > What about things like flash plugins? Those are often wanted on
> > desktops and need multilib.
>
> Flash sucks, and fortunately, it's dead.
It should be, but it's not. There are still many sites that require it.
> 64bit should be the defaul
Neil Bothwick writes:
> On Tue, 05 Jan 2016 18:41:25 +0100, lee wrote:
>
>> > Try Neil's suggestion of using a chroot and NFS exporting. I use it
>> > here to good effect.
>>
>> I must be missing his posting?
>
> It's in the "QEMU/distcc combination question" thread, among other places.
Thank
On Tue, 05 Jan 2016 18:41:25 +0100, lee wrote:
> > Try Neil's suggestion of using a chroot and NFS exporting. I use it
> > here to good effect.
>
> I must be missing his posting?
It's in the "QEMU/distcc combination question" thread, among other places.
> Of course, I installed the client no-
Jeremi Piotrowski writes:
> On Tue, Jan 5, 2016 at 12:49 PM, lee wrote:
>> The gui monitor doesn't seem to exist.
>
> Recompile distcc with the gtk use flag.
Oh, I thought that was an extra package ...
Peter Humphrey writes:
> On Tuesday 05 January 2016 14:18:12 lee wrote:
>
>> Is there a way to offload the preprocessing to the server, and can
>> compiling on localhost be avoided as much as possible somehow?
>
> Try Neil's suggestion of using a chroot and NFS exporting. I use it here to
> good
On Tuesday 05 January 2016 14:18:12 lee wrote:
> Is there a way to offload the preprocessing to the server, and can
> compiling on localhost be avoided as much as possible somehow?
Try Neil's suggestion of using a chroot and NFS exporting. I use it here to
good effect.
--
Rgds
Peter
On Tue, Jan 5, 2016 at 12:49 PM, lee wrote:
> The gui monitor doesn't seem to exist.
Recompile distcc with the gtk use flag.
writes:
> wrote:
>
>>
>> I used a pentium 4 laptop as client and two phenom2 quadcore pc as
>> server. I don't remember the settings that I used but I think it
>> was something about -j10 or so.
>
> Sorry, I think it was about -j16 (twice the totally amount of CPUs).
The wiki says to use twic
writes:
> lee wrote:
>
>> writes:
>>
>> > lee wrote:
>> >
>> >> Hi,
>> >>
>> >> what's taking so long when emerging packages despite distcc is
>> >> used?
> [...]
>> Can it be that the client is simply too slow compared to the server to
>> give it any significant load? (The client isn't exa
writes:
> Frank Steinmetzger wrote:
>
>> On Mon, Jan 04, 2016 at 09:48:42PM +0100, waben...@gmail.com wrote:
>>
>> > P.S.: distccmon is a good tool to watch the compilation processes.
>>
>> I never got it to display anything. I just tried it again: synced
>> portage and ran a world update -- 1
Frank Steinmetzger writes:
> On Mon, Jan 04, 2016 at 09:48:42PM +0100, waben...@gmail.com wrote:
>
>> P.S.: distccmon is a good tool to watch the compilation processes.
>
> I never got it to display anything. I just tried it again: synced portage
> and ran a world update -- 16 Packages, among the
Frank Steinmetzger writes:
> On Mon, Jan 04, 2016 at 04:38:56PM -0600, Dale wrote:
>
>> >>> what's taking so long when emerging packages despite distcc is used?
>> >>> […]
>> >>> Some compilations are being run on the remote machine, so distcc does
>> >>> work. The log file on the remote machine
Frank Steinmetzger wrote:
> On Mon, Jan 04, 2016 at 09:48:42PM +0100, waben...@gmail.com wrote:
>
> > P.S.: distccmon is a good tool to watch the compilation processes.
>
> I never got it to display anything. I just tried it again: synced
> portage and ran a world update -- 16 Packages, among t
Frank Steinmetzger wrote:
> On Mon, Jan 04, 2016 at 09:48:42PM +0100, waben...@gmail.com wrote:
>
> > P.S.: distccmon is a good tool to watch the compilation processes.
>
> I never got it to display anything. I just tried it again: synced
> portage and ran a world update -- 16 Packages, among t
On Mon, Jan 04, 2016 at 09:48:42PM +0100, waben...@gmail.com wrote:
> P.S.: distccmon is a good tool to watch the compilation processes.
I never got it to display anything. I just tried it again: synced portage
and ran a world update -- 16 Packages, among them kdevplatform, a lengthy
Qt package (
wrote:
>
> I used a pentium 4 laptop as client and two phenom2 quadcore pc as
> server. I don't remember the settings that I used but I think it
> was something about -j10 or so.
Sorry, I think it was about -j16 (twice the totally amount of CPUs).
--
Regards
wabe
lee wrote:
> writes:
>
> > lee wrote:
> >
> >> Hi,
> >>
> >> what's taking so long when emerging packages despite distcc is
> >> used?
> >>
> >> I have disallowed compiling on the local machine (which is the one
> >> emerge is running on) through distcc settings because the local
> >> machin
On Mon, Jan 04, 2016 at 04:38:56PM -0600, Dale wrote:
> >>> what's taking so long when emerging packages despite distcc is used?
> >>> […]
> >>> Some compilations are being run on the remote machine, so distcc does
> >>> work. The log file on the remote machine shows compilation times of a
> >>>
lee wrote:
> writes:
>
>> lee wrote:
>>
>>> Hi,
>>>
>>> what's taking so long when emerging packages despite distcc is used?
>>>
>>> I have disallowed compiling on the local machine (which is the one
>>> emerge is running on) through distcc settings because the local
>>> machine is relatively slo
writes:
> lee wrote:
>
>> Hi,
>>
>> what's taking so long when emerging packages despite distcc is used?
>>
>> I have disallowed compiling on the local machine (which is the one
>> emerge is running on) through distcc settings because the local
>> machine is relatively slow. Yet I can see som
lee wrote:
> Hi,
>
> what's taking so long when emerging packages despite distcc is used?
>
> I have disallowed compiling on the local machine (which is the one
> emerge is running on) through distcc settings because the local
> machine is relatively slow. Yet I can see some gcc processes runn
lee wrote:
> Hi,
>
> what's taking so long when emerging packages despite distcc is used?
>
> I have disallowed compiling on the local machine (which is the one
> emerge is running on) through distcc settings because the local
> machine is relatively slow. Yet I can see some gcc processes runn
Hi,
what's taking so long when emerging packages despite distcc is used?
I have disallowed compiling on the local machine (which is the one
emerge is running on) through distcc settings because the local machine
is relatively slow. Yet I can see some gcc processes running on the
local machine, a
28 matches
Mail list logo
