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

gotnull said:
IMO probably not, but I like to dream.
Click to expand...
Not deeply enough read, and I'm not a lawer, but VIM license looks alike GPL rather than BSD, so unlikely.
For neovim, licensed under Apache License 2.0, partially unclear to me, especially about patents.
And there are dependency problems, too, with both vim and neovim. So would need to stick with in-base (n)vi.
 
T-Aoki said:
Not deeply enough read, and I'm not a lawer, but VIM license looks alike GPL rather than BSD, so unlikely.
Click to expand...
I am not a license guy, not my thing at all, but as soon as I saw GPL I came to the same conclusion.
T-Aoki said:
And there are dependency problems, too, with both vim and neovim.
Click to expand...
Yep they really need to strip it down, editors/vim-tiny could be nice it has no dependency, not sure people would enjoy it as much as editors/vim though.
Code: 
# pkg install vim
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
All repositories are up to date.
Updating database digests format: 100%
The following 8 package(s) will be affected (of 0 checked):

New packages to be INSTALLED:
        gettext-runtime: 0.23.1
        indexinfo: 0.3.1_1
        libffi: 3.5.1
        mpdecimal: 4.0.1
        python311: 3.11.13
        readline: 8.2.13_2
        vim: 9.1.1401_1
        xxd: 9.1.1401

Number of packages to be installed: 8

The process will require 247 MiB more space.
37 MiB to be downloaded.

Proceed with this action? [y/N]:
# pkg install vim-tiny
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
All repositories are up to date.
The following 1 package(s) will be affected (of 0 checked):

New packages to be INSTALLED:
        vim-tiny: 9.1.1401_1

Number of packages to be installed: 1

The process will require 3 MiB more space.
2 MiB to be downloaded.

Proceed with this action? [y/N]:

sysutils/tmux would be a good candidate, it has ISC license:
Code: 
 # pkg install tmux
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
All repositories are up to date.
The following 2 package(s) will be affected (of 0 checked):

New packages to be INSTALLED:
        libevent: 2.1.12
        tmux: 3.5a_1

Number of packages to be installed: 2

The process will require 3 MiB more space.
802 KiB to be downloaded.

Proceed with this action? [y/N]:
 
Vim uses the vim license. It's closer to BSD's license.
github.com

vim/LICENSE at master · vim/vim

The official Vim repository. Contribute to vim/vim development by creating an account on GitHub.
github.com github.com
GPL compatible means it can be used with GPL. MIT is also GPL compatible. BSD is too, except GPL doesn't like it as much, bc the license disclaimer has to go in it for them to use it. It's inconvenient for them, that they need to do that to absorb it.

Related to editors/neovim
As for Apache 2.0, LLVM is in base, but its toolchain is an exception, bc it's the only or few Apache licensed components in base. It's permissive and it discourages patent trolling infringement on the opensource software itself. OpenBSD doesn't like that license, because they think it restricts freedom, but nothing's wrong with it. OpenBSD thinks it potentially infringes on companies which use it, that their patents will be challenged, but it doesn't. Companies shouldn't be patent trolling. A mishap could happen, but if a company is right, they will win the rights of which they owned, and if they win, they only lose the right to use Apache licensed code, which wasn't authored by them. It's to discourage patent trolling by companies trying to take control of code which they didn't author. The Apache Foundation doesn't have the intention of mis-licensing code like by putting random code under its license to cause issues. It's more responsible than that. Apache's there for stewarding software for the purpose of creation, not for infringing on software created outside their stewardship.

If a company has a patent, which could potentially be challenged for any reason, then they can consider not releasing associated code into the Apache 2.0 or any other opensource license with a retaliatory patent clause. Most code is copyright rather than patented, so there's nothing for them to consider in terms of a patent they don't own. There's extreme patent trolling cases, where a nonprofit couldn't use a fax machine, bc some patent troll claimed that any such device couldn't be used, even though, they didn't patent that.

Vi does need to be replaced in base though, bc it's meant for legacy keyboards, which it functions in an inconvenient way full of hassle on modern keyboards. It can be forked, and improved the way sh (shell) has been improved upon recently. They won't improve the original version of vi itself, bc it's legacy. I use vim-tiny.
 
I'd like to see per-process namespaces ala plan9 (but *unlike* linux). This has many benefits such as setting up the namespace to refer to old libraries for an old program, less heavyweight (than the french tinderbox) package building, etc.
(though not holding my breath)
 
kenrap said:
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
Click to expand...
Thanks for this. I will try this.
 
I see many users asking for improvements in Linuxlator. I wish FreeBSD does not make too many changes to adapt to an increasingly changing Linux, and if they had to do them, think about getting it out of the base system and turning it into something similar to Wine, installable but not on the base. I use FreeBSD and if companies or developers do not want to adapt their applications to the system, OK, I will look for alternatives, but I do not want a compatibility layer towards operating systems that I do not want to use. Also worried about the scenario that is seen in the propietary videogames and Linux, where they work to used Wine ever, not natively for the system. I do not want companies or developers to think that it works through Linuxlator, it already works in FreeBSD, because it is not quite true.
However, and despite what I said, if so many FreeBSD users want Linuxlator to improve, as can be deactivated (in fact it is default) I hope they receive those improvements.
 
I kind-of suspect bun working on Linuxlator is holding up native FreeBSD support (more people likely just install the compat layer and run it quietly vs asking for native support and showing demand publicly): https://github.com/oven-sh/bun/issues/1524

I avoid Linuxlator because I want to do things as-natively to FreeBSD as possible. It also looked more-complex than I cared for to maintain after reinstalls (Wine is just a pkg install; Linuxlator needed mounts, an OS, rc.conf, etc). And I figure if I wanted to run native Linux apps, I can run Linux :p
 
It's never good enough! Err, there's always room for growth, really.
Need plain encryption mode for geli or something like that (`cryptsetup open --type plain` analogue). Really a big deal.
Maybe should add an ability to read BTRFS, so people can at the very least move things to FreeBSD without converting or using a container.
 
I do not want to downplay the work that has been done for Linuxulator, and it is a nice tool, but imho for anything serious it should be avoided. Why should anyone introduce another complex layer one needs to debug when we can just use native Linux, be it in a vm or baremetal.
Furthermore, I still believe Linuxulator is restricted to running one Linux jail at once, but please correct me if this is wrong.
 
oh, and another thing I would like, though this is probably not bound to a FreeBSD version: improved pkg, e.g. something like whenever I installed a package (leaf) I do not want an upgrade to uninstall that package ever, but tell me what updated packages would be done normally but cannot be done due to this constraint.
 
I think Linuxulator doesn't need frequent upgrades (LTS should be preferred), but unfortunately LinuxKPI is strongly wanted to be as up-to-date as possible for device drivers requiring it (not all but such as graphics/drm-*-kmod and in-base iwlwifi). More recent devices (especially GPUs from Intel and AMD) needs newer Linux compatibilities in KPI.

And quite unfortunate is that recent Linux kernel introduced Rust interface for device drivers.
Fortunately, (lacks some components conpared with Linux versions, though) nvidia provides native FreeBSD versions of their drivers, so Nova driver using Rust is not mandatory at least for now.
 
sidetone said:
Vim uses the vim license. It's closer to BSD's license.
github.com

vim/LICENSE at master · vim/vim

The official Vim repository. Contribute to vim/vim development by creating an account on GitHub.
github.com github.com
GPL compatible means it can be used with GPL. MIT is also GPL compatible. BSD is too, except GPL doesn't like it as much, bc the license disclaimer has to go in it for them to use it. It's inconvenient for them, that they need to do that to absorb it.

Related to editors/neovim
As for Apache 2.0, LLVM is in base, but its toolchain is an exception, bc it's the only or few Apache licensed components in base. It's permissive and it discourages patent trolling infringement on the opensource software itself. OpenBSD doesn't like that license, because they think it restricts freedom, but nothing's wrong with it. OpenBSD thinks it potentially infringes on companies which use it, that their patents will be challenged, but it doesn't. Companies shouldn't be patent trolling. A mishap could happen, but if a company is right, they will win the rights of which they owned, and if they win, they only lose the right to use Apache licensed code, which wasn't authored by them. It's to discourage patent trolling by companies trying to take control of code which they didn't author. The Apache Foundation doesn't have the intention of mis-licensing code like by putting random code under its license to cause issues. It's more responsible than that. Apache's there for stewarding software for the purpose of creation, not for infringing on software created outside their stewardship.

If a company has a patent, which could potentially be challenged for any reason, then they can consider not releasing associated code into the Apache 2.0 or any other opensource license with a retaliatory patent clause. Most code is copyright rather than patented, so there's nothing for them to consider in terms of a patent they don't own. There's extreme patent trolling cases, where a nonprofit couldn't use a fax machine, bc some patent troll claimed that any such device couldn't be used, even though, they didn't patent that.

Vi does need to be replaced in base though, bc it's meant for legacy keyboards, which it functions in an inconvenient way full of hassle on modern keyboards. It can be forked, and improved the way sh (shell) has been improved upon recently. They won't improve the original version of vi itself, bc it's legacy. I use vim-tiny.
Click to expand...
Somehow it confirms why I don't wan to mess with licences, even when the question is simple the answer is more than often complex(at least for me).
Thank you for the details and the explanation, it's good to have people around that know this stuff.
 
I’d like to see less change. Fewer things “included”. I’ve said this before. They should be streamlining the OS, not adding more and more cruft. netif blows. pf, pfil, netmap, dummynet, altq; the kernel is a potpourri of bad ideas and murky macros. Clean it up and make things easier to pop in and out with the proper hooks. You make the system more useful with less clutter.
 
For security/doas to go into base system, with option of disabling it. For there to be an option to fall back onto sh(8) through chsh [chpass(1)] if a chosen shell for a user in ports like shells/pdksh, shells/osk or shells/mksh isn't installed from ports, which can temporarily happen during system upgrades or during single user mode.

Depreciate old UHID usb hid framework, perhaps send it to ports for legacy. ugold(4) may be the last piece to be upgraded or replaced to work with USBHID. In the meantime, depreciate all drivers that use UHID like ums and ukbd earlier.

Finish removing remaining GNU parts in base system, replacing toolchain parts with LLVM and BSD components: https://wiki.freebsd.org/GPLinBase. bsddialog is completed for 15 CURRENT. diff3 is being imported from OpenBSD. bwn and gcov are all that's left for GPL in Base, according to that page. bwn is a kernel module for wireless hardware by Broadcom, which if not completed can move to ports in the meantime. gcov is a coverage implementation used with debugging for LLVM. That page may possibly be not up to date, as there's llvm-cov(1).

Consider importing NetBSD's make which is more modern and offers wider compatibility. Even if to ports, which would be a good way to start. There's already devel/mk-configure.

Comparing https://sourceforge.net/p/elftoolchain/wiki/Home/ to LLVM toolchain replacement parts for FreeBSD based on GPLinBase, FreeBSD would seem to lack: isa and elflint. Not sure if isa is covered by as(1) in FreeBSD. There are a few other components which seem to be complete in FreeBSD, while not complete in the main elftoolchain page. FreeBSD has ports-mgmt/portlint.

Attention to importing video drivers from NetBSD used for ARM64 architecture for SBC's (ie Raspberry Pi). https://man.netbsd.org/evbarm/vchiq.4 for VideoCore kernel module. https://man.netbsd.org/evbarm/vcaudio.4 VideoCore audio kernel module. https://pkgsrc.se/misc/raspberrypi-userland userland (PkgSrc) programs which use VideoCore in their base system. VC4 is the 2D driver for VideoCoreIV and VideoCoreVI. VC4 is also the 3D acceleration driver for VideoCoreIV. For 3D, VideoCoreVI uses the V3D driver, which may not yet be ported to NetBSD. https://forums.raspberrypi.com/viewtopic.php?t=317511

Get sponsors for some of these projects, like from Broadcom for VideoCore and bwn. They would in return benefit by being able to sell more, when their graphics and other hardware work on more operating systems.
 
fjdlr said:
zsh: /usr/local/bin/zsh

And why not? /bin/zsh ?
Click to expand...
The possible issue is when /usr/local/ is in separate partition outside /, and somehow failing to mount. And in single user mode, partitions other than / is NOT mounted automatically. So it could matter.

To workaround, I configure my user having /bin/tcsh and have below in my ~/.tcshrc.mine to use zsh as my command line shell.
Code: 
if ( -X zsh && -f ~/.Use_zsh ) exec zsh
This way, if executable zsh is not found in anywhere in path environment variable nor (empty or not) marker file ~/.Use_zsh exists, zsh is not invoked and default tcsh is used instead.
 
Whatever it takes to get Docker support.

A good sound system Linux would steal.

Send two of the three firewalls to ports.
 
I’ve been reading some analyses comparing FreeBSD ULE and Linux’s CFS, and it makes me wonder whether FreeBSD should eventually move toward a new generation of schedulers. ULE is simple and can be very effective under certain workloads, but it also has some weaknesses.

A possible new scheduler could keep the simplicity of today’s ULE while addressing some issues where ULE is not performing well, like ensuring minimum progress for all threads to avoid starvation, being more aware of NUMA, using shorter or adaptive load balancing intervals and introducing selective lightweight preemption to improve responsiveness in interactive and database workloads.

Also, the scheduler should be hyperthreading-aware. At the moment, ULE treats all hardware threads as if they were full CPU cores, which can probably hurt performance. A smarter policy would be to prioritize filling physical cores first.
 
Argentum said:
I’ve been reading some analyses comparing FreeBSD ULE and Linux’s CFS, and it makes me wonder whether FreeBSD should eventually move toward a new generation of schedulers. ULE is simple and can be very effective under certain workloads, but it also has some weaknesses.

A possible new scheduler could keep the simplicity of today’s ULE while addressing some issues where ULE is not performing well, like ensuring minimum progress for all threads to avoid starvation, being more aware of NUMA, using shorter or adaptive load balancing intervals and introducing selective lightweight preemption to improve responsiveness in interactive and database workloads.

Also, the scheduler should be hyperthreading-aware. At the moment, ULE treats all hardware threads as if they were full CPU cores, which can probably hurt performance. A smarter policy would be to prioritize filling physical cores first.
Click to expand...
Me, too, think some kind of NUMA-like approach is needed for scheduler to work better for wider variety of workloads. But to determine the parameters optimum for per-product (of CPU) basis would mandate strong and timely commitments by CPU manufacturers.

We would need to leave the part to them, and receive committable codes contributed with BSD license "just at the moment" they shipped the first non-ES (at worst first retail version) one from their factory (to avoid NDA reasons not to). Otherwise, the performance cannot be optimum.
 
What would bring us there and maybe beyond would be the performance counters. Have a set of guidance modules which direct the scheduler which threads shall have affinity to what core, and provide modules which base these decisions on things like instructions executed, type of instructions, cache misses, ... Modern CPUs count these anyway. So maybe make it have all the cache trashers on one partition of cores and the well-behaved on another, so they don't stomp on each other feet.
 
You must log in or register to reply here.
Back
Top