https://wiki.archlinux.org/title/Arch_compared_to_other_dist... exists, but probably does not answer your question.

For Arch users of KDE Plasma and applications, are essential packages ever missing? <https://wiki.archlinux.org/title/KDE#Installation>

From https://gist.github.com/grahamperrin/307b8cdef5d4dcd30f5fdc4... for FreeBSD:

> It's not unusual for a Tier 1 platform to have no package for a wanted desktop environment. Two platforms are at this tier: …

For example, kde for FreeBSD 15.0-CURRENT was recently missing for a few days for AMD64; is still missing for aarch64 (64-bit ARMv8).

This is not to criticise the maintainers of packages or repos. I do understand the constraints.

The absence of an essential meta package is, inescapably, an impedance when aiming to test installers and upgrades, especially with pkgbase.

That's a tad dramatic, Daphne.

LSU context: the completeness is out of scope.

Current aims include enhancement of the installer for FreeBSD; KDE Plasma and applications as an option.

Yep, the coherence is a strong point.

Unfortunately, we now have a few people complaining about predictable, consistent behaviour with packaging that is coherent. The base system, FreeBSD, packaged.

The complaints are about the effect of wilful force.

Maybe I'm old-fashioned.

When I force something with my eyes shut (ignoring warnings), I do expect the unexpected as a result of my ignorance ;-)

>Maybe I'm old-fashioned.

No your not, even in the Sun-Solaris time they asked themself why rm should be able to delete /.

>The complaints are about the effect of wilful force.

Don't make a function no one uses (because it has no function) but is able destroy the system.

Compare it to a aircraft, shutdown your fuel has probably a emergency function, make a button to instantly destroy your aircraft has no real function nor will it ever be used (aka pkg remove -af).

>Unfortunately, we now have a few people complaining about predictable, consistent behaviour with packaging that is coherent.

That's not predictable but stupidity, try to remove all pkg/Application/Apps from MacOS, Windows, OpenBSD, NetBSD or Android...will the system boot or not? All those operating-systems make a clear distinction from the base-system to "apps" and the system should ALWAYS boot to a state where you can interact with it and so should FreeBSD.

There is not a single system (no OS and no living being) in this world wheres there is a function to destroy itself would not be called a error (the worst possible one)

But hey lets tell Linus (from Linus tech-tips, a Linux beginner) it's your fault because you forgot to read 100 lines, what a wannabe elitist think, there are ZERO point's, that a system should be able to make itself not booting anymore.

https://www.youtube.com/watch?v=V4L8Oci_2Bs

I took it to mean, a relatively short period of time after funding became available. Bear in mind, it's a report from the Foundation.

Thanks for helping people to lose their preconceptions. New truths are good …

Side note: I wasn't aware that the title here was truncated. Sorry. It should have been:

Laptop Support and Usability (LSU): July 2025 report from the FreeBSD Foundation

Which version of FreeBSD, exactly?

freebsd-version -kru ; uname -aKU

pkg repos -el | sort -f

pkg repos -e | grep url

I'm not familiar with the meaning of T14, sorry.

Does the Wi-Fi hardware use iwlwifi(4)?

A kernel panic when waking from sleep might relate to the graphics driver.

  ~ freebsd-version -kru
  14.3-RELEASE
  14.3-RELEASE
  14.3-RELEASE-p1

  ~ uname -aKU
  FreeBSD t14 14.3-RELEASE FreeBSD 14.3-RELEASE releng/14.3-n271432-8c9ce319fef7 GENERIC   amd64 1403000 1403000

  ~ pkg repos -el | sort -f
  FreeBSD
  FreeBSD-kmods

  ~ pkg repos -e | grep url
      url             : "pkg+https://pkg.FreeBSD.org/FreeBSD:14:amd64/quarterly",
      url             : "pkg+https://pkg.FreeBSD.org/FreeBSD:14:amd64/kmods_quarterly_3",

  ~ sysctl net.wlan.devices
  net.wlan.devices: iwlwifi0

  ~ pciconf -vl | grep -B4 VGA
  vgapci0@pci0:0:2:0: class=0x030000 rev=0x0c hdr=0x00 vendor=0x8086 device=0x46a6 subvendor=0x17aa subdevice=0x22e8
      vendor     = 'Intel Corporation'
      device     = 'Alder Lake-P GT2 [Iris Xe Graphics]'
      class      = display
      subclass   = VGA

  ~ kldstat | grep i915
  15    1 0xffffffff838f1000   1e0228 i915kms.ko

Sorry I wasn't clearer before, the laptop is a Lenovo Thinkpad T14 gen3 with an Intel CPU. I poked around in logs a bit but I haven't found anything indicating an error yet.

EDIT: just started reading Ch. 10 on Kernel Debugging[1], will try some things and see if I can extract any useful information. The handbook is so great.

[1] https://docs.freebsd.org/en/books/developers-handbook/kernel...

Thanks.

I have a vague sense that kernel panics with iwlwifi should have been resolved before 14.3-RELEASE. Bugzilla should be fairly close to definitive, expect info to be copious but well-organised.

Alder Lake-P GT2 [Iris Xe Graphics], it's harder to find information.

I spent around a year trying to pinpoint the cause(s) of apparently random failures with different (older) hardware. After switching to Kubuntu on the same hardware, I suspect that the issue with FreeBSD was ACPI-related.

If you have crash files from kernel panics: it should be possible to identify, but not necessarily solve, a problem.

Yeah to your point earlier a graphics driver issue seems a likely suspect, still haven't found any evidence yet though. Will keep looking.

> I'm not familiar with the meaning of T14, sorry.

They probably are telling you the model of laptop; ThinkPad T14

Kubuntu 25.04 here, root on OpenZFS thanks to the installer for Ubuntu.

How is OpenZFS second class on Linux?

<https://github.com/openzfs/zfs/> is not perceptibly FreeBSD-first.

Cool, one of the best features of ZFS on FreeBSD is to boot into a snapshot. ZFS boot environments are really cool.

You can get that with ZFS Boot Menu on Linux too. It was inspired by the FreeBSD boot loader.

Root on ZFS is not a problem.

While You can spend some hours installing Linux with ZFSBootMenu and LUKS encrypted Root on ZFS - there are ZERO Linux distributions that allow ZFS Boot Environments out of the box.

That is the reason 'why' Linux is not the first class ZFS citizen.

LUKS-encrypted root on ZFS does not take hours. I chose encryption when I installed the OS.

When You make research how to make it for the first time - it can - if you want to check at least several different guides ... but that covers only the encryption part.

There is also the ZFSBootMenu part ...

If you have done this at least once - noted the commands, etc. - it will take shorter - but never shorter then FreeBSD 'Auto (ZFS)' option in the bsdinstall(8) installer where you just select the disk on which it needs to happen and hit [ENTER] key.

> … if you want to check at least several different guides ... but that covers only the encryption part. …

Reminder: I neither want, nor need, to check several different guides that cover only the encryption part.

I was talking about the ZFSBootMenu part - the encryption part is easy.

OK, that's clearer.

In any case, I'll take additional advice; it's impossible to trust apparently authoritative statements from you.

Funny because the only person they do not work for is you ... you seem to be very special.

I have not yet needed a ZFS boot environment.

I'm considering alternatives. Not ZFSBootMenu in isolation. I'm in no rush.

>I'm in no rush.

Ahh now i get the point why you have no problems destroy your system with a simple pkg command ;)