Please, stop pluralizing "BSD's", every BSD it's different and OpenBSD only reuses Linux drivers for KMS/DRM; FreeBSD has special layers and tons of drivers ported and NetBSD it's closer to philosophy in design.
So GNU/Linux now it's in the same group as FreeBSD as it has ZFS? Because neither NetBSD nor OpenBSD have it.
OpenBSD doesn't 'rely' on Linux drivers, thanks. Just a shim against KMS/DRM, everything else it's either homegroup or sometimes adapted (back and forth) from NetBSD but OFC patched for correctness and security. There's no ALSA. Pulse it's totally optional. There's no wpa_supplicant except for Eduroam or simlar niche crap under OpenBSD.
OpenBSD has OSS and sndiod. There's Xenocara, an X11 fork.
Again, not Linux, X11, MESA and Gallium are damn generic. Show me the rest of ported Linux drivers into OpenBSD, please.
Nope. The best we could do was to create a separate service that creates Docker tokens (using "docker login") and exposes a secure API.
Obviously, GitHub needs to just fix this nonsense. But I interviewed a couple of "senior" engineers from GitHub, and I have zero hope of that happening soon.
Bandwidth is problematic for mesh. A remote assistance situation would involve at least 4 high definition camera streams, and ideally with minimal latency. It's challenging to put that much data onto public spectrum even if you wanted to make a custom radio.
I was thinking more for communicating the “mass disruption in progress” message - or even just distributing the manually verified “traffic lights down” data between vehicles.
> When you run Get-Mailbox -Identity <MailboxIdentity> | Format-List AuditEnabled, the AuditEnabled property always displays as True. This hardcoded display value doesn't reflect the actual mailbox-level audit configuration.
> To verify the actual mailbox audit status, use the Filter parameter in the following command:
PowerShell
> If the command returns the mailbox object, mailbox-level auditing is enabled. If the command returns an error stating the object couldn't be found, mailbox-level auditing is disabled.
It's interesting they ever exposed it at all really! I don't think you can use Google's Spanner-based etcd replacement for a self-managed Kubernetes cluster, for example.
Easier said than done in this case. Actually effective crosschecks preventing this issue from occurring would entail rather massive I/O and CPU amplification in common operations.
we could have run with https://www.postgresql.org/docs/current/app-pgchecksums.html turned on, but it slows things down a bunch - and turning it on in retrospect would have taken days. Also not clear that it would have caught whatever the underlying corruption was here…
reply