What would you like to see over the next few FreeBSD versions?

Actually I read on various articles that more and more user are favoring FreeBSD as their new desktop OS.
If it continues like it is, maybe we can get more developers interested into this OS.
Of course, with new developers more tools would also be available.

Now after using FreeBSD for almost half a year, tweaking, porting programs I personally need for this OS, I can say that I would wish to get the same open AMD GPU driver support linux for example has.
I liked Nvidia to some extend, but my next GPU won't be from Nvidia for several reasons.
They broke float 16 math in their Vulkan drivers which I personally need, and they don't want to fix it, although asked several times...
Would the drivers be open-source, it could be fixed by the community.

I wonder whether it could be possible to get for example the new AMD GPUs released recently to run under FreeBSD with minimal patching.
If not the only option for now would be a AMD 7900XTX, I guess....
 
SDK Chan said:
They broke float 16 math in their Vulkan drivers which I personally need, and they don't want to fix it, although asked several times...
Click to expand...
Where did you reported it?
What I could find related both nvidia and vulkan on Bugzilla that are not yet closed is PR 287453 alone. And info outside FreeBSD project's official tools (Bugzilla, Phablicator and official ML) is hard to find.

What we can do on ports side for nvidia drivers are quite limited, but If you have patch to fix, Phablicator could be better (easy to discuss about the patch itself), but if not, the official way is Bugzilla.

If you've reported directly to nvidia, filing PR on Bugzilla, too, would be helpful for anyone struggring with same or related issues.
 
I mean Nvidia broke fp16 (half?) through their official driver since version 510, unless you manually can build nvidias drivers I don't think it can be fixed, but maybe I am wrong.
The information came from a log from the yuzu-emulator.
It was reported back then while yuzu still existed, but it is not limited to yuzu.
Issues with Nvidia GPUs and Vulkan driver past version 512.
Another issue with fp16.

Unlike fp32, fp16 is done on the hardware level.
I don't have any problems with fp32 calculations, but they are slower due to being handled on a software level.
It is hard to find accurate resources as there are a lot of them describing each different problems.
This fp16 problem is not only on FreeBSD.
 
SDK Chan said:
Unlike fp32, fp16 is done on the hardware level.
Click to expand...
fp16, fp32 and fp64 are done on hardware level. The reason fp16 is faster then fp32 is that more operands can be packed into the same amount of memory.

The number of "CUDA Cores" that the nvidia video card specifications mention, in fact, is the number of packed fp32 processors.

SDK Chan said:
I wonder whether it could be possible to get for example the new AMD GPUs released recently to run under FreeBSD with minimal patching.
If not the only option for now would be a AMD 7900XTX, I guess....
Click to expand...
AMD doesn't support FreeBSD, so in order to get AMD video drivers, we use the linux drivers inside FreeBSD's linux compatibility layer. This compatibility layer is maintained and updated as part of the FreeBSD operating system, and tries to offer a linux KBI/ABI as similar as possible to a specific linux kernel version, usually a long term supported one. Assuming the linux compatibility layer works perfectly, we can merge updates committed to the amd drivers of the same linux LTS branch more or less easily. If, however, modifications to the compatibility layer are required, then a new version of the compatibility layer will need to be released as part of the next FreeBSD OS update.
Classically this meant we could merge linux driver updates that depended on modifications of the linux compatibility layer every 2-3 years, as every minor release built package was required to be compatible to any other minor release version of the same major branch, i.e. all FreeBSD-13.x packages had to be compatible to FreeBSD-13.0, however, recent modifications to FreeBSD's pkg repository layout allow kernel modules, i.e. video card drivers, to be built against specific minor releases, too, so we can now technically distribute amd drivers that require code introduced only in FreeBSD-13.4 and was not present or defunctive in FreeBSD-13.0, assuming the system being deployed has 13.4, of cause.

Convincing AMD to deliver native FreeBSD drivers would resolve the issue. Convincing AMD to put more effort into packporting its stuff to linux' LTS branches would offer a feasible solution, and probably would be welcome by the linux distributions, too.
 
xibo said:
Classically this meant we could merge linux driver updates that depended on modifications of the linux compatibility layer every 2-3 years, as every minor release built package was required to be compatible to any other minor release version of the same major branch, i.e. all FreeBSD-13.x packages had to be compatible to FreeBSD-13.0, however, recent modifications to FreeBSD's pkg repository layout allow kernel modules, i.e. video card drivers, to be built against specific minor releases, too, so we can now technically distribute amd drivers that require code introduced only in FreeBSD-13.4 and was not present or defunctive in FreeBSD-13.0, assuming the system being deployed has 13.4, of cause.
Click to expand...

One caveat with the new model, which is great overall: if you install your AMD drivers from binary packages soon after a new minor FreeBSD version is released, the package may still be built against the older FreeBSD version. This did bite me in case of the 14.2 to 14.3 upgrade and AMD Ryzen graphics. The solution is to build graphics/drm-kmod from ports. It would be nice though if the package manager could warn about compatibility issues.
 
recluce said:
It would be nice though if the package manager could warn about compatibility issues.
Click to expand...
In my experience you can see if relevant upgrades are available.
Use an enabled FreeBSD-kmods repository* and review the relevant upgrades.

To get a preview, use the commands:
# pkg upgrade -r FreeBSD -n
# pkg upgrade -r FreeBSD-kmods -n

Further info: message #7 - 14.3-RELEASE

Note
This is about getting the right drivers for graphics, wireless, firmware etc. These are tailored to match a certain minor release version. You could still experience graphics problems when your graphics are not yet fully supported, for example when your graphics are very new.

___
* per default enabled on 14.3-RELEASE
 
well i mayhaps turn out to be the most demanding one so bear with me

live update support, boot0 improvements (e.g. supporting multiple OSes on multiple disks), loader tracing with boottrace, some improvments for if_bridge for jails, a working android_ tools port, testdisk port working, cinnamon getting updated, support for usb emulation for bhyve or passthrough for usb storage without msi/msi-x interrupts, maybe even vga emu or 3d accel for windows guests in bhyve without pass through, mseal() equivalent, zram, capsicum improvements so that sandboxong apps becomes easier and possible for apps like firefox
 
Yampress said:
I would like a working yubikey 5 nfc key at the kernel and system level
I would like a working yubikey 5 nfc key at the kernel and system level
I would like a working yubikey 5 nfc key at the kernel and system level
Click to expand...
So does FreeBSD currently not support Yubikey 5 NFC?

I ask because I'm starting to use GhostBSD and have been trying to get Yubikey 5 NFC to work without any success. I tried it with both Firefox and Ungoogled Chromium, and both keep throwing up time out errors etc.

So should I resign myself to having no Yubikey support with FreeBSD for the time being? Thanks.
 
ChapinTokyo said:
So does FreeBSD currently not support Yubikey 5 NFC?
Click to expand...
There is support but you have to DIY it to make it work.

Here is a fleshed out guide covering various uses: https://gist.github.com/daemonhorn/bdd77a7bc0ff5842e5a31d999b96e1f1

Really important to add this to your /boot/loader.conf for YubiKey Manager (along with hidraw and hkbd in your kld_list):

Code: 
hw.usb.usbhid.enable="1"
hw.usb.quirk.0="0x1050 0x0010 0 0xffff UQ_KBD_IGNORE"  # YKS_OTP
hw.usb.quirk.1="0x1050 0x0110 0 0xffff UQ_KBD_IGNORE"  # NEO_OTP
hw.usb.quirk.2="0x1050 0x0111 0 0xffff UQ_KBD_IGNORE"  # NEO_OTP_CCID
hw.usb.quirk.3="0x1050 0x0114 0 0xffff UQ_KBD_IGNORE"  # NEO_OTP_FIDO
hw.usb.quirk.4="0x1050 0x0116 0 0xffff UQ_KBD_IGNORE"  # NEO_OTP_FIDO_CCID
hw.usb.quirk.5="0x1050 0x0401 0 0xffff UQ_KBD_IGNORE"  # YK4_OTP
hw.usb.quirk.6="0x1050 0x0403 0 0xffff UQ_KBD_IGNORE"  # YK4_OTP_FIDO
hw.usb.quirk.7="0x1050 0x0405 0 0xffff UQ_KBD_IGNORE"  # YK4_OTP_CCID
hw.usb.quirk.8="0x1050 0x0407 0 0xffff UQ_KBD_IGNORE"  # YK4_OTP_FIDO_CCID
hw.usb.quirk.9="0x1050 0x0410 0 0xffff UQ_KBD_IGNORE"  # YKP_OTP_FIDO
 
ChapinTokyo said:
So does FreeBSD currently not support Yubikey 5 NFC?

I ask because I'm starting to use GhostBSD and have been trying to get Yubikey 5 NFC to work without any success. I tried it with both Firefox and Ungoogled Chromium, and both keep throwing up time out errors etc.

So should I resign myself to having no Yubikey support with FreeBSD for the time being? Thanks.
Click to expand...
Pretty sure this is more an issue with web browser. At least on Nitrokey, you just need to disable the newer usbhid before inserting the key and it should work.
Other component works with the new usbhid driver, like using ssh key on the devices, using the smartcard, etc...
You can use `fido2-token -L` to list the devices, and more like getting the creds on the key. All of that work with hidraw still enabled and the new usbhid driver.
 
What I'd like to see, is really FreeBSD agnostic for the most part. It would be improvements in the opensource software ecosystem. Moreover, improvements in libraries. It starts with all relevant libraries which allow dynamic linking from at minimum. Making libraries which don't allow dynamic linking from become obsolete.

It's outside of the scope of FreeBSD, but it and other BSD's are ideal OS's to make those improvements from. Redox also would be a good playground using only C and C++ code in its own independent ports tree. Replacing libraries under GPL with different programs under LGPL or other licenses which allow dynamic linking from. If a GPL version doesn't work with a library which allows dynamic linking from, that's an error of the GPL itself. They need to be updated to allow that, and all is well. Nothing wrong with Apache 2.0. End programs have every right to be GPL, with the exception that they need to be able to dynamically link to libraries meant for use by other code. GPL still has every right to not allow dynamic linking from it. That's a choice depending on the purpose of the author or software. When it becomes a library meant for widespread use, that library needs to be replaced. Any program can be used as a library, so when a program can run as an end program, that's an end program rather than a meant for widespread use by other programs library.

Fork programs to run with sh and BSD make. Starting with libraries.

I'd start with replacing XMPP libraries under GPL with different programs which were under LGPL or any other permissive or weak copyleft licensed code. Then, make programs work with that.

It's too much of an overhaul, so I'm dreaming here. Maybe one day, I'll pay others to do it.

Cleaning up Cairo. Cleaning up SVG dependencies. Forking xt to xcbt. Make xaw3dxft and gtk work on that. Make every other basic X program work on one of those. Make Motif a style, based on is old code, and make that dependent on gtk. Make gtk2 and gtk3 styles as well on top of a core gtk. Due to older gtk being dropped due to newer version of Wayland. Gtk and motif both use lgpl. It will also make maintenance simpler. Forking libcanberra for sound. Keep internationalization support for all of these. Make accessibility support modular for there: make it a flavor and parallel as an install, not hard dependencies.

I know I'm going to get criticism for this, because it's too much, but this is the way opensource is supposed to be.
 
Ideas...?
Perhaps, that the Free Foundation should make an effort for the management of the mini-PCs This is a market sector that will take off These mini-PCs (Nipogi, Letzung, etc.) are starting to be deployed in home automation, Perimeter System Surveillance and to replace Office PCs.
 
fjdlr said:
Perhaps, that the Free Foundation should make an effort for the management of the mini-PCs This is a market sector that will take off These mini-PCs (Nipogi, Letzung, etc.) are starting to be deployed in home automation, Perimeter System Surveillance and to replace Office PCs.
Click to expand...
I bet operating systems based on Rust would be perfect for that. There's some Rust based operating systems made specifically for IoT. Maybe even operating systems based on FreeBSD, like XigmaNAS, OPNsense, PFsense and HardenedBSD. So, because of that, FreeBSD would need that. As long as the hardware is supported. MiniPC's use AMD64, right? Then, the focus would be software improvements, including porting from other operating systems.

XigmaNAS, OPNsense, PFsense and HardenedBSD don't have ARM64 installs, which they need. FreeBSD, NetBSD and FreeBSD do. Those are for SBC's. It would be nice to hear more about MiniPC use on the forums. SBC's seem more convenient and adaptable. I've tinkered with what may have been a MiniPC, but the parts weren't interchangeable with other PC parts, which are more standardized.

It would benefit to forums to have a separate MiniPC and SBC subforum. Edit: for embedded or embedded like systems.
 
sidetone said:
It would benefit to forums to have a separate MiniPC and SBC subforum.
Click to expand...

Those are really different topics. Random non-x86 SBCs often require custom booting. x86 should be covered with existing firmware, no matter the size.

What work on mini-x86 is needed?
 
cracauer@ said:
Those are really different topics. Random non-x86 SBCs often require custom booting. x86 should be covered with existing firmware, no matter the size.

What work on mini-x86 is needed?
Click to expand...
From the post I've quoted. Maybe it fits under regular. Though, even if they use the same architecture, it would still be embedded or embedded like. Light systems. It depends on other hardware of those systems. Also, if they are x86 now, they may not necessarily required to be that in the future. It could happen due to cost savings. It may be architecture agnostic to some extent even though, most SBC's use ARM or RISC. Most PCs are x86 both 32 and 64 bit.

The fact that having a separate sub forum for SBC's and one for MiniPC's both under the embedded section would draw more attention and distinction to each. On the other hand, it may be better to have one subforum per architecture type that's not x86, then keep other as is.

One day, all modern typical use computers will be MiniPC's or SBC's. They already do a lot for their size compared to average computers.
 
I would like to see blkid in FreeBSD too for getting dual and multiboot systems configure easier.

BTW. I have tested grub2 in bare FreeBSD and it is working, but grub.cfg must make by hand.
 
nobody said:
I would like to see blkid in FreeBSD too for getting dual and multiboot systems configure easier.

BTW. I have tested grub2 in bare FreeBSD and it is working, but grub.cfg must make by hand.
Click to expand...
There's fstyp(8) for echoing filesystems used by partitions, though this is on the command line, and not within the boot configuration program. Is blkid much different in function?

Also, you can label partitions, so that you don't have to know the written out default device name, as you can use the label instead, which is also a device. A user here wrote how to use labels: http://www.wonkity.com/~wblock/docs/html/
 
You must log in or register to reply here.
Back
Top