TRIM when?

TRIM when?
ZFS when?
Multicore firewall when?
NFSv4 when?

Let's go into those:
TRIM is vital to properly supporting SSDs. Without it, deleting a few pages from the storage would require the deletion of the entire block before putting it all back, creating unnecessary reads and writes and ultimately causing a faster degradation of the SSD.
ZFS, and other filesystems like it, provide numerous features both for better management of your data with subvolumes, as well as better security. The security features include snapshotting, checksumming of all data and metadata, bitrot protection, excellent implementation of software RAID, and so on. Backups should of course always be made, but they can be complimented with a better FS. I can just imagine it now: An OpenBSD admin routinely backing up his system, unaware that data is being silently corrupted. By the time it's a problem, it's too late. Imagine how far back he'd have to roll back to get to a stable state? If only he had a filesystem that wasn't written in the 80s, and actually did something to protect his data. OpenBSD has best security? I think not.
PF, at least on OpenBSD, does not support more than one core of one processor. Linux's netfilter on the other hand, does. Not much else to say.
It's been 18 years since NFSv4 was originally standardized, and OpenBSD has still not gotten around to implementing it. This is quite a deficiency, as NFSv4 now allows you to authenticate connections with Kerberos, and even encrypt the data transfers. Once again, you would think such a security-focused OS would care about such benefits, but alas, no.

Attached: NOpenBSD.png (1000x1000, 168K)

Who pays you?

Attached: 1527477647475.jpg (755x500, 97K)

>he's THAT desperate for an openbsd thread

OpenBSD cares more about supporting obscure architectures

I thought that was NetBSD's thing?

Doesn't even support 32bit mips anymore, and has no riscv, vax, m68k, or sh3

nobody and everybody.

they also just disabled hyperthreading on intel processors because it's insecure too now

but you would know that if you hate openbsd so much that you would make a thread about your hate, wouldn't you?

Intel shill detected.

Not sure how to feel on that one. If the disabling actually did contribute to the security of the system, then good on them. It may be kind of a dick move for those whose workloads really benefited from hyperthreading, but then again I hear that it's just disabled by default and could be turned on again if the performance loss is that severe.
I've got no ties to intel, my dude. With so many vulns, most affecting Intel and some apparently affecting AMD as well, I'm surprised there isn't more of a movement to get off x86 entirely at this point. But of course there's plenty of logistical reasons that would prevent that.

What about advanced power management for a range of laptops that actually does the job well like TLP for Linux?

>If the disabling actually did contribute to the security of the system, then good on them.
You're ok with no hyperthreading because it's insecure but not SSDs if they're insecure. Do you think trim securely deletes?

Attached: Screenshot_20180624-170713.png (1080x1378, 1.22M)

reeeeBSD fag detected.

The problem with moving away from x86 is that there aren't enough high end chips physically available with equivalent performance, let alone superior performance ARM is there for stupidly parallel shit like process-per-request Cloudflare serving or Netflix streaming servers, but for single threaded perf nothing is out there at ALL that even comes close without the crippling security problems of speculative execution. Microsoft of all companies is actually working on porting Windows, Clang/LLVM, and Linux to a new architecture that supposedly tags code blocks at the ISA level and schedules blocks rather than single instructions. That would allow fast, secure execution if done correctly, although they'd either need to have a ton of tiny FPUs(one per internal scheduler thread) or take an enormous hit in floating point perf.

There is a movement to get off x86, that's why shit like RISC-V exists.

Incorrect
*hugs*

I really hope it does well. Still waiting on LowRISC.

>TRIM when?
>ZFS when?
ZoL doesn't even support TRIM.

TRIM should be opt-in with the function of deleting any data flagged to be overwritten by TRIM at the end user's command.

There are two modes of TRIM on Linux: manual like you describe, and adding discard to the mount options, which does it in the background like periodic GC sweeps.

What BSD would you recommend then?

Is there an easily achievable benefit of multicore firewall implementation when network I/O is so sequential?