Shell Secrets of FreeBSD

C

canihazsekooriti

I have a relatively recent Galaxy S flagship smartphone running Android 13. Stock Android 13 gave me 3.5 hour battery life. After some relatively major tinkering as root I am getting now about 7.5-8 hours battery life (all on an old battery). More than double. The phone runs cold, snappy, and stable for weeks and months without reboot.

Is there something `secret`, like I found with Android, that we can do with a FreeBSD installation that make it work super smooth, at its top capability and super secure? Or if FreeBSD is the ultimate OS out of the box - what are some `secret` things everyone knows about that anyone should NEVER do on FreeBSD? I don't know, maybe things like "Never use wine" or "Never skip loopback interface in pf firewall and manage its ports" etc.
 
I've read the original post about 5 times and I'm still not sure what is being asked.
I'm saying this as a FreeBSD daily driver user of a very long time.
The only true "secret" is know your workload, know your system, make changes and take the time to actually evaluate the effect of those changes.
Examples:
Window Manager vs Desktop Environment. Resource tradeoff, you choose what matters to you.
Service enabled by default. Evaluate what is enabled, what you actually need, turn off/on stuff you don't need/need.

There are no secrets, there is only knowledge. You need to evaluate, understand everything about your system (starts at the typical workload).

Actually, there is a primary secret. I'm probably going to get whacked by ninja space killer clowns for revealing it, but here it is:

Do not blindly apply things from the internet.
 
mer said:
There are no secrets, there is only knowledge. You need to evaluate, understand everything about your system (starts at the typical workload).
Click to expand...
Is there any impetus toward things like HardenedBSD? Does that mean FreeBSD is not hardened by default and lacks something that must be manually hardened, for example?
 
HardenedBSD has specific goals, as SirDice says lots have been backported/"upstreamed" to FreeBSD. That gives folks a place to try out things, if they are worthwhile, upstream and everyone benefits.
canihazsekooriti said:
Does that mean FreeBSD is not hardened by default and lacks something that must be manually hardened, for example?
Click to expand...
Define "hardened".
I'd start at
man securelevel
Lots of good info there, you need to decide on what matters to you.

My opinion, hardening/security is always a tradeoff between conveinence/usablity and security. The most secure system is a standalone system with no external devices. No network connection, no usb drives. I'd wager even Win95 would be pretty secure in that condition, but the question now is "How useful is it?".
When you see a security advisory (you are subscribed to that email list, yes?) read it, understand it, understand the mitigation, make a decision on how important it is to you.
Something that relates to Apache and malformed input? If you don't run Apache, especially on an external facing interface, one can say "who cares?" and it drops in importance.
 
canihazsekooriti said:
Well, Android is open source as well and yet....
Click to expand...
Base android, yes. OneUI (Samsung's interface) isn't. And much of the additional bells and whistles on a modern smartphone aren't either.

mer said:
as @SirDice says lots have been backported/"upstreamed" to FreeBSD. That gives folks a place to try out things, if they are worthwhile, upstream and everyone benefits.
Click to expand...
There's a lot of "cross-pollination" between the three "major" BSDs, FreeBSD, NetBSD and OpenBSD too.

That said, you can have the most secure operating system in the world, but if you install and run something stupid and get yourself hacked, there's only thing to blame. And it's not the OS.
 
SirDice said:
Psst, here's a 'secret' 😁 FreeBSD won't stop you from shooting yourself in the foot. And you're going to end up doing exactly that. A lot. Especially at first.
Click to expand...
I thought the "allow foot shooting" flag is OFF by default.
0x10 (allow foot shooting)
Allow writing to Rank 1 providers. This would, for example,
allow the super-user to overwrite the MBR on the root disk or
write random sectors elsewhere to a mounted disk. The implica-
tions are obvious.
kern.geom.debugflags
 
canihazsekooriti said:
I thought the "allow foot shooting" flag is OFF by default.
0x10 (allow foot shooting)
Allow writing to Rank 1 providers. This would, for example,
allow the super-user to overwrite the MBR on the root disk or
write random sectors elsewhere to a mounted disk. The implica-
tions are obvious.
kern.geom.debugflags
Click to expand...
It won't stop a rm -rf / for example. Or doing other stupid things to files. There are an infinite number of ways to shoot oneself in the foot ;)
 
canihazsekooriti said:
After some relatively major tinkering as root I am getting now about 7.5-8 hours battery life (all on an old battery).
Click to expand...
I'd be interested to know what this "relatively majoring tinkering" was exactly.

And maybe someone can give a better answer if you were more specific with your questions.

I for one, since I want to get a new laptop soon, would be interested to get it running smooth, cool and for a long time on battery power using FreeBSD and from what I've read so far there isn't a whole lot you can do on the OS side except for example using only integrated graphics instead of dGPU. This is what I would consider a "major" configuration change. (Yes I know there are wiki articles on tuning power consumption and you can disable any and all services and programs you don't need which will give a few, 10, probably 25 percentage points on battery life. In any case the definite answer on this topic seems to have been that FreeBSD has/is "power to serve, and not power to spare" which is usually what we want on a workstation or server and I'm okay with it)
 
pming said:
I'd be interested to know what this "relatively majoring tinkering" was exactly.
Click to expand...
All sorts of permissions, ownerships, capabilities are wrong. All sorts of things are on that should not and are not needed to be on. It's just a big mess. I'd say Android out of the box is a rootkit, but hey. Funny enough, Facebook's Whtasapp requires this one rootkit-like network capability to be on to work at all, whereas Telegram works great without it on. Just an example of weird stuff you discover tightening Android.
 
I've noticed FreeBSD is less "snappy" in desktop usage than Linux, especially KDE.
I have a CPU that scores high (green area) on the UserBenchmark site for desktop and workstation performance.

When I say snappy I mean GUI responsiveness. Resizing this Firefox window is not fluid on KDE5/FreeBSD14. The latest KDE6 packages aren't snappier either.

On a laptop CPU that scores in similar range as desktop CPU this percieved performance of KDE is more akin to what I get in virtualized Debian12/X11/KDE than on a native installation such as Rocky Linux, which is quite fluid.

Considering that roughly same software is running on both sides, NVidia, X.Org, KDE, could it be the system scheduler preferring long running tasks as opposed to desktop stuff, and not being specialized/configured to group desktop processes together?
 
Zare said:
Considering that roughly same software is running on both sides, NVidia, X.Org, KDE, could it be the system scheduler preferring long running tasks as opposed to desktop stuff, and not being specialized/configured to group desktop processes together?
Click to expand...
There are so called login classes that can define resource limits, for example in the default login.conf it says X users need more resources. Maybe this has an influence? I have yet to understand how those work and if I am supposed to configure / change them. Maybe a more seasoned user can give input on this. If this is all wrong please correct me or ignore.
 
drhowarddrfine

There is no measurement, it's a subjective experience. Take a rich application such as Firefox or any bigger Qt/KDE framework and start resizing the window, hold the handle and move it around, observe the fluidity of redrawing and responsiveness of the application to redraw itself.

Currently if I start resizing this window the performance depends on the active tab.

- in a Dolphin window the window manager is modifying the target area close to refresh rate (60), and Dolphin itself is redrawing without much latency. It's fluid
- in this Firefox tab, it's way less fluid, let's roughly ballpark it at 30 fps so still not choppy, and Firefox itself has a certain small lag to redraw the forum page in the new area
- in Youtube tab, it starts getting choppy, less than or about 20 fps

Moving/shaking window around has no effect or lag because it's a compositor operation.
 
You must log in or register to reply here.
Back
Top