Re: NetBSD and ECC RAM?

[Michael van Elst]

michael.chepo...@gmail.com (Michael Cheponis) writes:

>I've been running ECC in the Windows box for years, it seems like a 'no
>brainer' for servers. Servers usually run for years, and Stuff Happens over
>the years [1].
>But I'd prefer a reliable, unhackable, trustable compute fabric.  ECC is
>part of the 'reliable' part.

I agree, but the "box" will run with ECC, even when the OS doesn't
know about it. OS support is needed to get information about errors
and for better fault tolerance.


>I would also like to see per /dev entry ACLs.  I would like to see better
>security than owner-group-everbody permissions.

I have rarely seen ACLs being used for "better security". Even when that
was possible, the complexity usually outweighed any gain in control.

Systems that implied access control through simple rules worked much
better. It's still not a feature that you had to enable or a switch
you toggled, it requires constant effort, in particular on systems
that don't just perform a fixed set of functions.

Re: NetBSD and ECC RAM?

[Michael Cheponis]

I've been running ECC in the Windows box for years, it seems like a 'no
brainer' for servers. Servers usually run for years, and Stuff Happens over
the years [1].

Most of the computing industry has been hell-bent on performance, yielding
impressive gains (albeit with occasional setbacks:
https://cachewarpattack.com/ )

But I'd prefer a reliable, unhackable, trustable compute fabric.  ECC is
part of the 'reliable' part.

I would also like to see per /dev entry ACLs.  I would like to see better
security than owner-group-everbody permissions.  I would like to see almost
no normal system operations requiring root privs - and I would like to see
root privs made much more narrow and fine-grained in scope - only large
enough to do the specific job (e.g. change file permission, with a separate
capability to change file ownership; etc).

I'm certainly no computer security guru, or have any valid opinions except
as a luser.

Still --- I would like to see some performance gains "wasted" in order to
gain better reliable, unhackable, trustable systems.


Thanks for tolerating my mini-soapbox.
-Mike

[1] I recently had a NetBSD server's computer start to have random crashes
until I tried to boot it one more time, and it wouldn't come up at all.
 Then after cleaning everything, making sure disks were OK, and trying
again with no luck did I stare at the MB and saw  the electrolytic
caps' tops bulging out!   My rule: Never trust HW completely.  It will
fail.  Eventually.


On Fri, Feb 16, 2024 at 7:09 AM Hauke Fath (SPG) 
wrote:

> On 2024-02-16 01:14, Michael van Elst wrote:
> > We should have EDAC drivers that should at least report events,
> > but so far there is nothing...
>
> Sounds like a SoC project?
>
> Cheerio,
> Hauke
>
>
> (FreeBSD appears to be no better off:
> <
> https://forums.freebsd.org/threads/how-to-find-out-if-ecc-is-enabled.72839/
> >)
>
> --
>   The ASCII Ribbon CampaignHauke Fath
> () No HTML/RTF in email Institut für Nachrichtentechnik
> /\ No Word docs in email TU Darmstadt
>   Respect for open standards  Ruf +49-6151-16-21344
>

Re: Bug in the guide, npf exaple of gatewayapp

[adr]

On Sun, 4 Feb 2024, adr wrote:

Hi, in the example 24.8, $localnet is set to 192.168.0.1/24, the
host identifier should be 0.

Should I send a bug report, or could someone quickly make this
no-brainer fix?


Just to be clear, this is not bikeshedding. Apart of been incorrect
by using a host address instead of a network address, the example
won't work.

adr