On 11/23/2017 12:47 AM, R0b0t1 wrote:
I think the information I outlined is a pretty good argument for assuming the ME
can not be disabled.
Even if true, there's not much to be done about it anyway
Yeah it certainly can't be disabled (I argue this point on a regular
basis to no avail), as in n
On Wed, Nov 22, 2017 at 10:36 PM, taii...@gmx.com wrote:
> On 11/22/2017 11:16 PM, R0b0t1 wrote:
>
>> Does anyone have more information on this? Has anything been
>> published? I'm interested in exploiting my own computers so I can
>> control the ME.
>
> It seems that it is the same people who fig
On 11/22/2017 11:16 PM, R0b0t1 wrote:
Does anyone have more information on this? Has anything been
published? I'm interested in exploiting my own computers so I can
control the ME.
It seems that it is the same people who figured out HAP mode but they
haven't made a blog update I would ask on th
On Wed, Nov 22, 2017 at 6:03 PM, taii...@gmx.com wrote:
> Using ME cleaner would also solve the issue and you wouldn't need any more
> firmware updates when the next "bug" comes around.
>
Intel ME has been found to remain active after being disabled, and
some motherboards that do not ship as "vPr
On Tue, Nov 21, 2017 at 11:42 PM, Adam Carter wrote:
> I notice that an update for sys-firmware/intel-microcode just come through
> on ~amd64, does that address the ME issues?
>
No. As a sidenote, microcode updates can only remove or patch out
functionality. They can't modify functionality in com
I don't know if this has been suggested yet, but I run cron on UTC,
which doesn't do daylight saving time. It's an option in cronie to set
the TZ for crontab. I just have to transcode times from local to UTC
when setting up the job.
On 11/22/2017 12:42 AM, Adam Carter wrote:
I notice that an update for sys-firmware/intel-microcode just come through
on ~amd64, does that address the ME issues?
http://www.zdnet.com/article/intel-weve-found-severe-bugs-in-secretive-management-engine-affecting-millions/
Or will my NUC need a f
On Wed, 22 Nov 2017 09:57:29 +0100, David Haller wrote:
> Hm. What's this EMERGE_DEFAULT_OPTS though? ;)) And
> how can I override them if not wanted? .oO( gotta read up on that )Oo.
man make.conf
man emerge
emerge --ignore-default-opts
--
Neil Bothwick
The trouble with life is that you are h
On Wednesday, November 22, 2017 3:34:56 PM CET Wols Lists wrote:
> On 22/11/17 14:11, Tsukasa Mcp_Reznor wrote:
> > You won't get build failures or dependency problems, portage is built to
> > handle emerging multiple packages that do not depend on each other
> > simultaneously.
> > it will not eve
On 22/11/17 14:11, Tsukasa Mcp_Reznor wrote:
>
> You won't get build failures or dependency problems, portage is built to
> handle emerging multiple packages that do not depend on each other
> simultaneously.
> it will not ever build a dependency and the main program at the same time.
Are you sur
From: Raffaele Belardi
Sent: Wednesday, November 22, 2017 8:12 AM
To: gentoo-user@lists.gentoo.org
Subject: Re: [gentoo-user] is multi-core really worth it?
Jeremi Piotrowski wrote:
> That being said: if you do a world rebuild you will have lots of packages
> that spend ~40 seconds doing their a
On Wednesday, November 22, 2017 2:12:31 PM CET Raffaele Belardi wrote:
> Jeremi Piotrowski wrote:
> > That being said: if you do a world rebuild you will have lots of packages
> > that spend ~40 seconds doing their autoconf run, only to build 2-3 sources
> > files. On an 8-core machine at work, I g
Jeremi Piotrowski wrote:
> That being said: if you do a world rebuild you will have lots of packages
> that spend ~40 seconds doing their autoconf run, only to build 2-3 sources
> files. On an 8-core machine at work, I get good results using parallel
> emerge jobs (emerge -jX). For your 6-core AMD
On Wednesday, 22 November 2017 08:57:29 GMT David Haller wrote:
> Hello,
>
> On Wed, 22 Nov 2017, J. Roeleveld wrote:
> >On Wednesday, November 22, 2017 8:48:08 AM CET David Haller wrote:
> >> So, your emerge is mostly IO and "emerge"-threads bound. Solution:
> >> adjust your build-threads[1], and
Hello,
On Wed, 22 Nov 2017, Martin Vaeth wrote:
>David Haller wrote:
>> autotools is _by far_the best both from a users and a packagers view.
>
>I do not agree. Its main advantage is that it is compatible with
>most existing unix systems (but I am already not so sure whether
>this also holds if y
Hello,
On Wed, 22 Nov 2017, J. Roeleveld wrote:
>On Wednesday, November 22, 2017 8:48:08 AM CET David Haller wrote:
>> So, your emerge is mostly IO and "emerge"-threads bound. Solution:
>> adjust your build-threads[1], and then adjust your emerge jobs! See
>> '--jobs' in 'man emerge'. Can't find w
David Haller wrote:
> autotools is _by far_the best both from a users and a packagers view.
I do not agree. Its main advantage is that it is compatible with
most existing unix systems (but I am already not so sure whether
this also holds if you also want to compile for windows, powerpc,
etc.)
>
Hello,
On Wed, 22 Nov 2017, Jeremi Piotrowski wrote:
>That being said: if you do a world rebuild you will have lots of packages
that (even without the fetch) spend 40 seconds setting up the emerge
(unpack, prepare (plus eautoreconf))...
>that spend ~40 seconds doing their autoconf run, only to b
On Wednesday, November 22, 2017 8:48:08 AM CET David Haller wrote:
> Hello,
>
> On Wed, 22 Nov 2017, Raffaele Belardi wrote:
> >rebuilding system and world with gcc-7.2.0 on a 6-core AMD CPU I have
> >the impression that most of the ebuilds limit parallel builds to 1, 2
> >or 3 threads.
>
> Most
On Wed, 22 Nov 2017 08:26:01 +0100, Jeremi Piotrowski wrote:
> That being said: if you do a world rebuild you will have lots of
> packages that spend ~40 seconds doing their autoconf run, only to build
> 2-3 sources files. On an 8-core machine at work, I get good results
> using parallel emerge jo
20 matches
Mail list logo