On 2024-10-18 06:11:50, o1bigtenor via Dng wrote:
> On Thu, Oct 17, 2024 at 5:21 PM onefang <onefang_devuan@???> wrote:
> >
> > On 2024-10-17 06:44:13, o1bigtenor via Dng wrote:
> > > On Thu, Oct 17, 2024 at 3:04 AM onefang <onefang_devuan@???> wrote:
> > > >
> > > > On 2024-09-28 21:20:50, o1bigtenor via Dng wrote:
> > > > > On Sat, Sep 28, 2024 at 8:15 PM nick <[1]nick@???> wrote:
> > > > >
> > > > > It's definitely a dream system. I would still suspect it though. My
> > > > > reasoning would be somewhat like this:
> > > > > 1. Random lockups are not normal and shouldn't be happening.
> > > > > 2. The cause has gotta be either hardware or software.
> > > > > 3. If it's hardware it's gotta be one (or more) specific component that
> > > > > is failing, defined by if I replaced that component with an identical
> > > > > unit (of the same manufacturer and model) the problem would go away.
> > > > > 4. If it's software it's gotta be a subtle bug or driver
> > > > > incompatibility, sometimes latent bugs can be triggered by unusual
> > > > > combinations eg. Let us say the driver for your AMD graphics card fails
> > > > > when there is 64 GB or more of RAM, just for the sake of example.
> > > > > 5. It could also be a matter of settings or configuration eg if your
> > > > > BIOS has configured the RAM for a higher clock than it is specced for,
> > > > > although in this era of autoconfiguration this would probably count as a
> > > > > driver bug.
> > > > > What I would do as a starting point would be to pull out the GPU and
> > > > > half the RAM and use it for a few weeks to see if problem goes away.
> > > > > Does it have internal graphics or do you have an older GPU to use
> > > > > temporarily? If problem recurs swap the RAM for the other half and
> > > > > re-test. You can also try the GPU or RAM in another system to see if
> > > > > problem moves with it. If it turns out to be the GPU then it could be
> > > > > driver issue as drivers are very complex these days. You could try
> > > > > earlier driver or earlier kernel (as you are already doing) but such
> > > > > approach is fraught. Once you narrow down the issue to a specific part
> > > > > or driver its better to take it out of service until a new part or fix
> > > > > is available.
> > > > > In principle you can use the same approach to diagnose CPU or mobo
> > > > > issue, but you would need identical spares which could get costly. If
> > > > > buying spares for testing I would highly recommend to get a PSU first. I
> > > > > haven't been into system building for many years but I have heard that
> > > > > PSU is responsible for a large proportion of faults with modern rigs
> > > > > given how demanding they are on the PSU.
> > > > > I am sure you can solve this. The nightmare is when it happens on a
> > > > > laptop where you really have no option but to try earlier kernels or
> > > > > removing drivers or take the laptop out of service (has happened to me).
> > > > > On a PC it is much easier. Oh yeah another thought: you might try
> > > > > running the dreaded Windows on it for a while. If it still locks up you
> > > > > have eliminated software except possibly for common code in AMD display
> > > > > drivers.
> > > > >
> > > > > Given that when I had all four browsers loaded the uptime shrank horribly
> > > > > and my peripheral knowledge of the
> > > > > desire of far too many companies to use javascript to do things and report
> > > > > back to them what they want to know
> > > > > I am far more likely to suspect software than hardware.
> > > > > Just like right now - - I am still stuck at the dredded mz googly's email
> > > > > system and right now ublock origin is
> > > > > telling me that the are some 115 domains linked in. (Now up to 120
> > > > > domains. Now up to 137!!!!)
> > > > > This kind of garbage is likely at the bottom of my issues - - - not that
> > > > > hardware can't be an issue but
> > > > > when hardware is manipulated by unscrupulous companies - - - well the
> > > > > results are issues for users.
> > > > > Sorry - - - I have no spare GPU and I don't know another currently
> > > > > available one that has 5 outputs
> > > > > so that's a doa issue already.
> > > > > I guess what I'm looking for - - - well maybe I need to setup that shared
> > > > > hosting setup that I have been thinking
> > > > > about and get mz googly off my neck. Then if I can find a way to jail any
> > > > > and all browsers then I think my
> > > > > hardware issues would like shrink mightily.
> > > > > Any suggestions on how I can jail any browser?
> > > >
> > > > Hardcore way - run them in a VM.
> > > >
> > > I tried lxd some time ago and as a result am quite gun shy to even the idea of
> > > using VMs.
> > >
> > > What particular form of VM are you espousing?
> >
> > While there are less hardcore ways, I have spent a lot of time with qemu
> > VMs for various purposes. So that's my go to for such things.
>
> So what happens if a VM is discombobulated?
Same thing as happens with a real OS, you boot into something else and
try to repair things. In the case of VMs, the host can just shut the VM
down and mount it's storage. One of my use cases is developing my own
Devuan installer scripts, so I tend to do that a lot.
> > On the other hand, I'm considering eventually creating something along
> > the lines of Qubes, but Devuan based. A less hardcare solution, but
> > that's coz all the hard work is done already. That'll have to wait
> > though, got other things to get done before I can start on it.
>
> Sounds interesting - - - do let the rest of us know how things go when you're
> working on that.
I intend to. This sort of thing has my own use cases, but I see Qubes is
popular enough that others have use cases where my solution would work.
> >
> > Search for apt packages with jail in the name, there's a few I think. Or
> > containers.
> >
> Will do!
>
> Thanks a muchly for your input!!
--
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.