As long as they're connected to a wall socket. Otherwise, citation needed. Power Management in hard. Who does the myriad of hardware quirks for OpenBSD?
If you are referring to suspend/resume, then OpenBSD has great support[1]. Its one of the very few ACPI stacks not derived from Intel's ACPICA reference code.
Would you like to explain that, and maybe cite some references?
Suspend and resume have been stable for me as long as I've had a computer capable of supporting them.
And I'm not aware of any way to make them fail without doing something obviously intended to disable them.
Reference: Every time I've tried Linux on a laptop, Suspend, Resume, or Both has been broken in whatever $FLAVOR_OF_THE_MONTH distro/package/kernel the community insists is the next big thing.
The BSDs tend to implement these things later but far more reliably.
Never been broken on Arch, Fedora, Debian... or any of the upstream distributions I've used, when I've used them.
Your personal exacerbation of whatever imaginary and nonspecific issues you're talking about is not relevant to a conversation about people other than you.
The world doesn't need your BSD FUD.
"The BSDs" is also absolutely silly as ideas go, there are BSDs which have never supported suspend/resume.
What the world doesn't need is this continuing holy war from a particularly small but sadly vocal minority of the Linux community. You really don't help the cause. I find it particularly irononic of you to accuse someone of spreading "BSD FUD" on a thread about FreeBSD. I'll 'cite' you an example of real 'FUD'; https://news.ycombinator.com/item?id=5839565
Just because a filesystem isn't using all the space available in a partition does not mean that the rest of the space is being used by something else. Imagine I run `newfs -s 2097152 sd1p` where sd1p is actually 4194304 sectors. Now imagine sd1 is a softraid volume with a CRYPTO discipline. There's no way you can prove that the extra 2097152 sectors aren't being used, but there's also no way you can prove that they are.
That's certainly true. But also (from a investigation point of view) more suspicious than a filesystem covering the whole harddisk, but only filled to 20%. That will always be a problem, as long as the "visible" filesystem just maps block 1..N directly onto encrypted blocks 1+k..N+k (with k being a constant offset), as it's currently the case e.g. in linux LUKS (I assume CRYPTO discipline in BSD is similar).
The proper solution most likely would be to integrate a kind of block-mapping into the encryption software which allocates randomly distributed blocks from the encrypted harddisks whenever a filesystem begins to write to the blocks of an volume. This randomization algortithm then will be aware of all currently active "hidden partitions", but due to the randomness, a pattern to draw conclusions about the existence of other partitions would not emerge.
"More suspicious" is meaningless. If you can't prove - with incontrovertible evidence and beyond any reasonable doubt - that there's something there, then there's plausible deniability.
IPTables isn't part of GNU. It was developed by the Netfilter team. Indeed, very few of the networking utilites that are common in Linux distributions are part of the GNU project.
