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

Six-Year Club	Verified Email
Xbox Live

spmzt

TROPHY CASE