On 01/12/2018 04:14 PM, Nikos Chantziaras wrote:
> echo "$VULKAN_SDK/lib" > /etc/ld.so.conf.d/vulkan-loader.conf
Found out what was giving me an extra slash in the output "...x86_64//lib"
The $VULKAN_SDK PATH had a slash at the end.
Works now. Thank you.
Corbin
> They're new in general - they first appeared last week and they're
> being treated as if they're related to Spectre. I've yet to see any
> kind of official release of them, but that seems to be par for the
> course for AMD the more I hunt around for documentation. It seems
> like Suse first rel
>
> If somebody actually sees anything official from AMD clearly giving a
> checklist for Spectre remediation I'm all ears. To its credit, Intel
> at least published one of those (even if it amounts to "pound sand"
> for older CPUs).
>
AMD have revised their guidance on Variant 2 from "near zero
On 12/01/18 18:31, Corbin Bird wrote:
On 01/11/2018 08:29 AM, Nikos Chantziaras wrote:
On 11/01/18 15:28, Corbin Bird wrote:
Why are you setting LD_LIBRARY_PATH system-wide to begin with? Don't
do that.
Unfortunately, I had to ( and didn't realize the implications. )
In .bashrc :
export LD_L
On Fri, 12 Jan 2018 16:42:25 +, Wols Lists wrote:
> Dunno quite how it works, but you could automate everything through
> udev. When I stick something in, KDE offers to mount it for me, in
> /run/media/$USER/abcd-efgh.
>
> I think that last bit is unique to the media, and the same every time,
On 01/12/2018 02:06 PM, Rich Freeman wrote:
It shouldn't be. I'm not sure if Ryzen has anything equivalent to the
Intel Management Engine.
It does, it is called AMD PSP.
Like ME it is closed source and it can't be disabled - no matter what
people might claim.
On Fri, Jan 12, 2018 at 2:58 PM, Corbin Bird wrote:
>
> The Fam16h and Fam17h microcode updates were new to Gentoo?
> I don't recall ever seeing them before.
>
They're new in general - they first appeared last week and they're
being treated as if they're related to Spectre. I've yet to see any
k
On 01/12/2018 12:42 PM, Mick wrote:
> On Friday, 12 January 2018 17:47:46 GMT Rich Freeman wrote:
>> On Fri, Jan 12, 2018 at 11:23 AM, Corbin Bird
> wrote:
>>> On 01/11/2018 05:02 PM, Rich Freeman wrote:
IMO Spectre is going to drive some microcode updates for relatively
recent CPUs,
On Fri, Jan 12, 2018 at 1:42 PM, Mick wrote:
> On Friday, 12 January 2018 17:47:46 GMT Rich Freeman wrote:
>
>> The other odd thing is that a firmware update was released for my
>> motherboard (ASRock AB350 Pro4) on the 10th, and if I flash it grub
>> will no longer boot the linux kernel, and it i
On Friday, 12 January 2018 17:47:46 GMT Rich Freeman wrote:
> On Fri, Jan 12, 2018 at 11:23 AM, Corbin Bird
wrote:
> > On 01/11/2018 05:02 PM, Rich Freeman wrote:
> >> IMO Spectre is going to drive some microcode updates for relatively
> >> recent CPUs, compiler improvements, and some hand-tuning
On Fri, Jan 12, 2018 at 11:23 AM, Corbin Bird wrote:
>
> On 01/11/2018 05:02 PM, Rich Freeman wrote:
>>
>> IMO Spectre is going to drive some microcode updates for relatively
>> recent CPUs, compiler improvements, and some hand-tuning of
>> particularly critical code.
>>
>
> The microcode updates
AMD says they are releasing microcode updates for their previous
generation CPU's (Opteron, FX, etc) next week.
So much better than intel throwing older CPU owners to the wolves.
In terms of what CPU to get - I would get either an AMD G34/C32 Opteron
(pre-PSP) with a compatible libre firmware b
On 2018-01-12, Wols Lists wrote:
> On 12/01/18 15:39, Grant Edwards wrote:
I usually also include a check to ensure that some file/directory
exists which I expect to be on the drive, which prevents the
backup script from dumping a full backup into your mountpoint if
it isn't m
On 12/01/18 15:39, Grant Edwards wrote:
>> I usually also include a check to ensure that some file/directory
>> > exists which I expect to be on the drive, which prevents the backup
>> > script from dumping a full backup into your mountpoint if it isn't
>> > mounted (possibly on a filesystem with i
On 01/11/2018 08:29 AM, Nikos Chantziaras wrote:
> On 11/01/18 15:28, Corbin Bird wrote:
>>> Why are you setting LD_LIBRARY_PATH system-wide to begin with? Don't
>>> do that.
>>
>> Unfortunately, I had to ( and didn't realize the implications. )
>> In .bashrc :
>>> export LD_LIBRARY_PATH=$VULKAN_
On 01/11/2018 05:02 PM, Rich Freeman wrote:
> On Thu, Jan 11, 2018 at 5:41 PM, Mick wrote:
>> Most vendors only sell Intel in their laptops. I could build a desktop I
>> guess, but Ryzen is also affected by Spectre. With Intel's burning platform
>> I
>> want to jump off, but I'm not sure if s
On 01/11/18 14:41, Mick wrote:
Are any of you planning to replace your Intel PCs and what are you considering
as a replacement at present?
I was planning to replace two of my PCs with Ryzen, but that plan was in
place before Meltdown happened. At least then I'll be able to get
microcode/fir
On Friday, 12 January 2018 13:28:39 GMT Rich Freeman wrote:
> There is no need to run eject on a USB drive - just pull the thing and
> udev will clean up the device nodes.
One other small point: I've found that running eject on a USB drive on, say,
/dev/sda marks /dev/sda unavailable for further
On 2018-01-12, Rich Freeman wrote:
> On Fri, Jan 12, 2018 at 6:39 AM, Mick wrote:
>> On Friday, 12 January 2018 09:58:17 GMT Adam Carter wrote:
>>>
>>> Pretty sure you'd risk filesystem corruption by not umounting
>>> before you remove the device.
That's why I don't do that.
> This is all somew
On January 12, 2018 10:58:17 AM GMT+01:00, Adam Carter
wrote:
>>
>> I replaced it with a USB3 drive, so I needed to update the udev rules
>> that automatically mount it and then "umount" it when it's removed.
>>
>
>Pretty sure you'd risk filesystem corruption by not umounting before
>you
>remov
On Fri, Jan 12, 2018 at 6:39 AM, Mick wrote:
> On Friday, 12 January 2018 09:58:17 GMT Adam Carter wrote:
>>
>> Pretty sure you'd risk filesystem corruption by not umounting before you
>> remove the device. Did it used for force an fsck on each mount because the
>> filesystem was "dirty"? If not,
On Friday, 12 January 2018 09:58:17 GMT Adam Carter wrote:
> > I replaced it with a USB3 drive, so I needed to update the udev rules
> > that automatically mount it and then "umount" it when it's removed.
>
> Pretty sure you'd risk filesystem corruption by not umounting before you
> remove the dev
>
> I replaced it with a USB3 drive, so I needed to update the udev rules
> that automatically mount it and then "umount" it when it's removed.
>
Pretty sure you'd risk filesystem corruption by not umounting before you
remove the device. Did it used for force an fsck on each mount because the
file
23 matches
Mail list logo
