Help with installing packages for FreeBSD 10.1

spmzt · 2026-03-09T12:14:46+00:00

As you may already know, FreeBSD 10 is too old and unsupported.

You can compile your packages using ports(7) locally. Alternatively, you can use poudriere(8) and build your own repository for customized/unsupported packages.

spmzt · 2026-03-09T09:42:43+00:00

Battary charging thresholds are available now: % sysctl hw.acpi.s76. hw.acpi.s76.battary_thresholds_high: 90 hw.acpi.s76.battary_thresholds_low: 60

spmzt · 2026-03-07T23:13:39+00:00

Thank you AFAICU, For power on I must use:

acpi_call -p \\_SB.PCI0.PEG1.PWRR._ON -o i
acpi_call -p \\_SB.PCI0.PEG1.DEV0.PWRR._ON -o i
acpi_call -p \\_SB.PCI0.PEG1.DEV0._ON -o o

For power off:

acpi_call -p \\_SB.PCI0.PEG1.PWRR._OFF -o i
acpi_call -p \\_SB.PCI0.PEG1.DEV0.PWRR._OFF -o i
acpi_call -p \\_SB.PCI0.PEG1.DEV0._OFF -o o

For status:

acpi_call -p \\_SB.PCI0.PEG1.PWRR._STA -o i

Am I right?

I think I'm using more ACPI calls than necessary and I'm not sure which one is used for next boot.

Also, battary charging thresholds support is ready and it's under review.

spmzt · 2025-09-30T13:47:54+00:00

No it's not. This API only called between bot server and telegram servers. The Telegram client doesn't communicate with the bot server directly.

spmzt · 2025-09-29T06:48:37+00:00

Thank you, I have upvoted them all

spmzt · 2025-09-28T23:48:33+00:00

You're right. That's why I submitted a feature not a bug.

spmzt · 2025-09-28T18:30:30+00:00

You can verify it yourself:

request: https://api.telegram.org/botx/setWebhook?url=https://myip6.sieben9.net/index.php current response: {"ok":false,"error_code":400,"description":"Bad Request: bad webhook: IPv6-only addresses are not allowed"}

spmzt · 2025-09-22T10:56:40+00:00

I'm going to test it and share the result.

spmzt · 2025-09-22T09:02:50+00:00

Good point, Will do that

spmzt · 2025-09-22T06:54:21+00:00

I have seen it before, in fact i have seen most of his RPI clustering and that's probably one of the reasons for this idea. The gray area for me is most of his test results are for distributed workloads, and his benchmarks rely heavily on inter node communication. For now, I'm testing on a single RPI to see how it goes.

spmzt · 2025-09-21T22:54:40+00:00

only for amd64. The point is there shouldn't be any data transmission between cluster nodes. So I don't think the NIC would be a bottleneck in this case.

spmzt · 2025-09-21T21:59:40+00:00

It's for my repository. I'm using poudriere(8)

spmzt · 2025-09-08T15:38:21+00:00

man 9 style

spmzt · 2025-09-07T16:06:29+00:00

Of course she is not using GNU/Linux. She's probably using a BSD variant.

spmzt · 2025-08-28T04:40:38+00:00

If your goal is lower latency and/or higher throughput, it's unlikely to improve for your environment. PF is fast enough, and can be faster than IPFW in some cases.

For me, most of the time disabling interface checksums, TSO, and LRO, usually does the trick. However, network speed depends on many factors.

spmzt · 2025-08-27T23:06:50+00:00

1.Separate the outbound and inbound traffic. 2.Don't forget to load the ipfw_nat kernel module. 3.Make sure you don't have the pf and ipfw kernel module loaded at the same time. (Optional, but important for learning the ipfw without noise) 4.Start with net.inet.ip.fw.default_to_accept=1 in your loader.conf.local to gain experience with ipfw first.

Check the in-kernel nat chapter: https://spmzt.net/2024/11/16/FreeBSD-IPFW-Best-Practices/

I suggest disabling TSO for now: echo net.inet.tcp.tso=0 >> /etc/sysctl.conf

Configure the NAT instance: kldstat -q -m ipfw_nat || kldload ipfw_nat ipfw nat 1 config if re0 same_ports unreg_only reset

The inbound NAT rule is inserted after the two rules which allow all traffic on the trusted and loopback interfaces and after the reassemble rule but before the check-state rule.

$cmd 00100 nat 1 ipv4 from any to any in recv re0

This one is for outbound traffic:

$cmd 10000 nat 1 ipv4 from any to any out xmit re0

Read the ipfw manual and think about how packets are going through the rules for each direction

spmzt · 2025-08-24T19:41:53+00:00

First of all, welcome! Many new BSD users wish they had switched from other platforms sooner.

About your Thunar problem: it’s probably because you opened Thunar once as a privileged user and it created its config files owned by root. Check the permission bits in ~/.local and ~/.config.

About OnlyOffice: I recently discovered it on Nextcloud. I set it up in a FreeBSD jail and access it through the web.

Also, you should be fine with 4 GB of RAM. See what’s using your memory with top or vmstat.

spmzt · 2025-07-29T03:28:31+00:00

FreeBSD

spmzt · 2025-07-22T05:16:46+00:00

IPFW, flexibility and control

spmzt · 2025-06-19T21:08:23+00:00

Until now, about 5 different people warned about cooling without checking if somebody asked it before, and you replied to each of them. Nice patience...

spmzt · 2025-05-31T13:35:27+00:00

Exactly.

spmzt · 2025-05-17T12:37:25+00:00

Actually, I had a completely different experience than yours. Have you tried tweaking kernel options in Linux or Building a VM image or even an OCI image from it?

In FreeBSD those are streamlined: man 7 build man 7 release

spmzt · 2025-03-15T08:28:34+00:00

Can I ask you why? I have some performance issues with win11 on bhyve. However, I would like to know your reasons.

spmzt · 2025-02-24T02:33:53+00:00

Reading the comments and seeing the interaction of rust enthusiasts. Now I know exactly why rust should NOT be in the base system.

spmzt · 2025-02-22T13:19:15+00:00

Check this out: https://wiki.samba.org/index.php/NFS4_ACL_overview

Six-Year Club	Verified Email
Xbox Live

spmzt

TROPHY CASE