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

T-Aoki said:
The problem would be the driver codes are ported from Linux drivers, which are behind Windoze drivers, and if the drivers require additional KPI/KBI level of kernel support, FreeBSD project needs to implement them in LinuxKPI, thus, larger delays.

What is wanted is that GPU vendors directly provide FreeBSD-native drivers under BSD-compatible licenses. Maybe some parts of the drivers would be provided as pre-compiled binaries like nvidia does in those cases.
Click to expand...
As far as I know Windows drivers aren't involved?

Also, I believe the vast majorify of code in the Linux KMS/DRM grahics drivers stack is released under the MIT licence, which is why it's included in the BSD base systems.
 
blackhole said:
As far as I know Windows drivers aren't involved?
Click to expand...
Yes. The structure should be different. But my point is not the codebase itself here, but purely released timing. Windows drivers are usually shipped with the GPU cards (or works with already existing driver). But even Linux drivers aren't provided at the same timing, AFAIK.

The same can be said even for nvidia drivers. FreeBSD, Solaris and Linux versions of their drivers are categorized as "Unix drivers" and provided at the same timing. But Unix drivers are behind Windows version. For example, when 570 series of drivers first appeared as Beta driver for Unix driver, there were already screams about 572 series of drivers within Windows users.

blackhole said:
Also, I believe the vast majorify of code in the Linux KMS/DRM grahics drivers stack is released under the MIT licence, which is why it's included in the BSD base systems.
Click to expand...
AFAIK, yes. But unfortunately, the Linux KMS/DRM graphics drivers relies on Linux kernel functionalities and at least some of them are NOT existing on FreeBSD when the drivers are released. So FreeBSD project is forced to re-implement the GPL'ed codes with clean-room way under BSD license.
The codes are called LinuxKPI and built as linuxkpi.ko, linuxkpi_video.ko and linuxkpi_hdmi.ko.
 
I'd be happy seeing all the stuff from /usr/src/contrib being moved to packages which get installed under /usr/local/sbin by a readily bootstrapped ports-mgmt/pkg. Components are selectable by Bsdinstall and get upgraded by first invocation of pkg.
 
Thunderbolt? I thought would have made for a cool albeit probably-not-so-relevant feature a few years ago. Now it seems it's being melted together with USB4 anyway which will be supported I guess.

More/better support for new SMB versions as others already mentioned. I also would love to see general improvements for Desktop use, but that's not really a question of the development of the OS but rather I'd say it depends on the community, FreeBSD development itself should focus on the core OS.

And I hope bhyve will continue to be upgraded and expanded, I think it's a very useful feature with a lot of potential.
 
Seamles bootup at startup with 0 driver bugs. Seamless WiFi for anyone on the go. Maybe a feature in Linuxulator or bhyve that is similar to WSL2 which is a custom Linux kernel specifically built for Windows but this one for FreeBSD. Cutting edge microprocessor and GPU acceleration
 
pming said:
And I hope bhyve will continue to be upgraded and expanded, I think it's a very useful feature with a lot of potential.
Click to expand...
Years ago I considered virt or GPU passthrough with Linux host and Windows guest for games, but the set-up and PCI address stuff looked more complex than I cared for.

I only saw random posts with configs and used it a tiny bit with wifibox, but I'm thinking command-line spinning up a Windows VM with the passthrough config would be easier to understand (likely even cleaner) on FreeBSD with bhyve. Whenever I get a GPU I'm eager to try :p

I feel FreeBSD host would be good for stuff like PCVR (I have faster compile times/lower latency in general vs Linux, so FreeBSD's lower-footprint or different resource allocations might be better perf in Windows guest)
 
1... prioritizing browser problems [ restoration of palemoon, seamonkey, a legacy version of falkon OR bumping it quicker...]

2... more documentation of
/boot/modules files especially video drivers
[ related to 3a below ]
3... a place where one can put in a video card and get proven methods to
install its drivers AND get Xorg working with it.
3a... I am confused forever with the names. drm? intel? i915? amd?
only nvidia seems clear, but they seem to be duplicated
elsewhere in the ports with -kmod... also numerous version
numbers.
4... some program to find out why a GUI segfaults more capable than
gdb
5... more complete documentation for debootstrap, poudriere, and jails
which walks a novice through to being expert and being continually
revised. [ not enough FreeBSD users, maybe fixable by more close
attention to browser and/or printer availability ]
6... make booting into a working-internet system less of an unknown...
I get 'no carrier' then when logging in the internet has been established.
Usually. back in 2015, I set it up manually each time with a static IP.
OR, setup wifi.
BUT IT WORKS.
 
Replying only partly.

jb_fvwm2 said:
only nvidia seems clear, but they seem to be duplicated
elsewhere in the ports with -kmod... also numerous version
numbers.
Click to expand...
If you're OK with manual (or via x11/nvidia-xconfig) configuration and don't need native Wayland, forget about all of graphics/nvidia-drm*-kmod.

Note that numbers like 510, 515, 61 and 66 in it means with which version of graphics/drm-*-kmod to work. These numbers corresponds with Linux kernel version that DRM/KMS driver (common and Intel/AMD drivers) came from. As Linux changes (meaninglessly, I feel) quickly discarding backward compatibilities, volunteers for documentation would be hard to catch up with it.

x11/nvidia-driver is the key component that other components need.
Always needed if you want nvidia proprietary driver and its derivatives.

x11/linux-nvidia-libs is libraries for Linuxulator to support nvidia GPUs.
It also includes some of libraries that nvidia doesn't providing FreeBSD-native version supporting, for example, CUDA.

Numbers behind these two means they are "Legacy" drivers to support old GPUs that are dropped from newer production branch of drivers.

About x11/nvidia-secondary-driver, I doubt it should be kept or not,
as its pkg-message states that its configurations depend on already-deleted x11/nvidia-hybrid-graphics. Existing users of this could want it, but if the description is correct, fresh-installations shold not work.

x11/nvidia-settings are GUI configuration tool by nvidia.

Others would be (not 100% sure, though) 3rd party softwares.

About documentation about poudriere for newbies, I've provided example for casual usage based on my configuration.
 
homeadm said:
I don't know which branch of Windows your company uses. Windows Server has a NFS server out of the box.
Click to expand...
Yes, I know. It isn't implemented, and I do not have admin level access to enable it. There is no way I could convince our storage team to implement NFS just so I can run FreeBSD instead of Windows or MacOS at work.
 
I have mentioned some already in FreeBSD project ideas I can think of a bunch of features I would like to see in FreeBSD. So, to anyone who feels bored and does not have to work on other things, here is my wishlist:
  • pf improvements regarding UDP and ICMP, loadbalancing
  • improve linuxulator and to be able to run Linux OCI containers stable
  • declarative container environment like Linux docker
  • fuse for unprivileged users in jail
  • bhyve support for spice protocol
  • bhyve migration support similar to OpenBSDs hypervisor
  • bhyve tpm emulation (on the way I think)
  • HAST rewrite to something like Linux/DRBD9
  • bind-mount sockets
  • p9fs client
  • smb3.11 protocol support to mount cifs
  • proper wifi stack and bluetooth
  • veriexec - documentation and enabled - https://reviews.freebsd.org/D8554
  • some ports with more frequent updates

And from an external projects perspective, I would love to see FreeBSD be a among the primary platforms for Rust, Go and Python, oh, and I would love to see pypy again in FreeBSD.
 
rootbert said:
I would love to see FreeBSD be a among the primary platforms for Rust, Go and Python, oh, and I would love to see pypy again in FreeBSD.
Click to expand...
Python and FreeBSD unfortunately are not a dream-team:

peps.python.org

PEP 11 – CPython platform support | peps.python.org

This PEP documents how an operating system (platform) becomes supported in CPython, what platforms are currently supported, and documents past support.
peps.python.org peps.python.org

Mailman 3 Consider adding a Tier 3 to tiered platform support - python-committers - python.org

mail.python.org mail.python.org

That's not very complimentary for FreeBSD. Who is working on that making things better?
 
I see there's a definite need to reiterate that third party software (ports/packages) has very little do to with development of the base OS. This should probably be emphasized more, especially for newcomers (or should I say refugees?) coming from Linux.
 
base OS wouldn't be able to run without third party software - the compiler is not original. But I get it. You can always build your own custom version of FreeBSD - its always an option
 
another thing comes to mind: bhyve direct kernel boot ... something like Linux/firecracker does for a minimal hypervisor overhead.

(Regarding third party tools and software, imho this is equally important. The fact that FreeBSD is only in pythons tier3 drives me off for some of my python development projects, and the rust situation is a show stopper for our whole development team ... sorry for drifting offtopic, I'll shut my keyboard now)
 
Above I advocated for a more strict separation between third party software in /usr/src/contrib and base FreeBSD for a more convenient FreeBSD OS installation/deployment and maintenance by using Pkg. That would mean less security advisories and errata notes for openssh, openssl, ntpd and the like, no need for patching the OS but upgrading well maintained packages instead.
 
These are listed in order for me.

1. union FS support that is updated, and ready for production use. The man page, https://man.freebsd.org/cgi/man.cgi?mount_unionfs, does not instill confidence in me to want to use this. I want to use this so I could boot a machine up to memory and remove the USB thumbdrive, it has some cool applications ...
2. More transparency around missing packages and the build system. For the past month, I have been unable to do a complete rebuild of my systems since some packages are missing. I routinely update my backup drives so that if my system were to die, I would be ready to go with up-to-date software and not need to apply patches ... I don't want to build ports from scratch unless I have a pressing need.
3. lower barrier to entry to update ports. I tried and failed trying to update intellij, the port has been updated, but not yet accepted. Because of this, I am less inclined to attempt to update other ports. Why is it so difficult to update a port?

4. better wifi support - I am happy with wifibox, it works great, but it could be just a little bit better and then allow me to directly SSH into my box without an additional hurdle. I believe this will be addressed this year as I thought I heard there was a big push to update the wireless networking stack this year.
5. better bluetooth support - as much as I don't like earbuds from generally being thrown out once the batteries die, they are really convenient

Wifi and bluetooth are at the bottom of the list for me because I can live without bluetooth, I have wired headphones and the wifi works great with wifibox.
 
You must log in or register to reply here.
Back
Top