[PLUG] Determining if a newer version of a Slackpkg is available

Thomas Groman tgrom.automail at nuegia.net
Thu Mar 14 18:37:05 UTC 2019


On Wed, 27 Feb 2019 07:42:39 -0800
Ben Koenig <techkoenig at gmail.com> wrote:

> On 2/26/19 10:13 PM, Tom wrote:
> > On Tue, 26 Feb 2019 18:33:14 -0800
> > Ben Koenig <techkoenig at gmail.com> wrote:
> >  
> >> On 2/26/19 7:48 AM, King Beowulf wrote:  
> >>> On 2/25/19 9:52 PM, Ben Koenig wrote:  
> >>>> Considering how long it's taken nvidia to fix, I think you are
> >>>> allowed to be cranky.
> >>>>
> >>>> I see a bunch of new downloads on their website, did they finally
> >>>> fix it?
> >>>>
> >>>> Or do I need to place an order for a Vega 56?
> >>>>
> >>>>
> >>>>  
> >>> You are gainfully employed now. go for ot!
> >>>
> >>> I haven't tested the Nvidia updates yet for the new Slackware
> >>> kernels. In progress.
> >>>
> >>> -Ed
> >>>  
> >> Bought a core3D sound card instead. Vega will have to wait.
> >>
> >>
> >> Nvidia + Ryzen has been resulting in some lock ups for people. My
> >> uptime has been capped at 4 days with nvidia-418.30 :(
> >>
> >> I'll know by Saturday if 418.43 fixed anything. FWIW my laptop
> >> (ryzen 2700U) has been up for 22 days. I even left it in suspend
> >> for a solid week and it came back up like a champ.
> >>
> >>
> >> This is on -current, but if my system is still running at the end
> >> of the week I'm gonna call the driver "stable".
> >>
> >> -Ben
> >>
> >> _______________________________________________
> >> PLUG mailing list
> >> PLUG at pdxlinux.org
> >> http://lists.pdxlinux.org/mailman/listinfo/plug  
> > I have heard that even some time after the initial launch of AMD
> > Ryzen that suspending didn't even work on Linux. If such a trivial
> > feature such as power management for Linux can be overlooked at a
> > CPU launch date I can only assume that CPU still has quite a few
> > bugs to knit out.
> >
> > Regarding Nvidia,
> > https://invidio.us/watch?v=IVpOyKCNZYw  
> 
> 
> Careful with that video on public lists. The systemd community might
> try to have you banned in accordance with their rigid CoC.
> 
> It also might behoove you to understand the difference between a
> driver bug, and a hardware flaw.
> 
> 
> AMD is trying to prove that the software stack DOES have an affect on 
> the functionality of the overall product. This affect can be observed
> at both the OS and application levels. We've spent decades assuming
> that a "faster Intel CPU" will "make your computer faster". This is
> not true, and IMO the best way to dispel such fallacies is through
> proof of concept.
> 
> Behold:
> 
> 1) CPU runs like shit
> 
> 2) Software is updated
> 
> 3) CPU runs great
> 
> 4) STUNNING CONCLUSION:
> 
> CPU was not shit.
> 
> Software was shit.
> 
> 
> AMD is a hardware company. They make great hardware, and this has
> always resulted in driver headaches. The reason I look the other way
> is because AMD is a hardware company, so I don't actually give a shit
> if their software sucks.
> 
> Application of Intel power management algorithms to an AMD processor 
> caused problems? Really?!
> 
> <sarcasm>I HAD NO IDEA THAT WAS A THING</sarcasm>
> 
> _______________________________________________
> PLUG mailing list
> PLUG at pdxlinux.org
> http://lists.pdxlinux.org/mailman/listinfo/plug

It's _IS_ a driver issue if the machine can't enter certain power
states. And there is nothing 'Intel' about S power states either. S1,
S2, S3, S4 etc. I wasn't talking about software (at least not
userspace) but AMD's lack of driver support in Linux for their own
flagship CPUs.



More information about the PLUG mailing list