point taken.Come on Kent. VT102 at least please.... What was that circa 1983 DEC?

point taken.Come on Kent. VT102 at least please.... What was that circa 1983 DEC?
IMO probably not, but I like to dream.Is VIM license suitable for Base?
Not deeply enough read, and I'm not a lawer, but VIM license looks alike GPL rather than BSD, so unlikely.IMO probably not, but I like to dream.
I am not a license guy, not my thing at all, but as soon as I saw GPL I came to the same conclusion.Not deeply enough read, and I'm not a lawer, but VIM license looks alike GPL rather than BSD, so unlikely.
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.And there are dependency problems, too, with both vim and neovim.
# 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]:
# 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]:
Thanks for this. I will try this.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
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/1524Somehow 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).Vim uses the vim license. It's closer to BSD's license.
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.![]()
vim/LICENSE at master · vim/vim
The official Vim repository. Contribute to vim/vim development by creating an account on GitHub.github.com
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.
The best way to understand that is probably https://docs.freebsd.org/en/books/handbook/x11/#x-graphic-card-drivers .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.
Simply: backlog. We have gotten closer to steady-state on the number of ports PRs in Bugzilla, but around 20 come in per day.3. [...] Why is it so difficult to update a port?
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.zsh: /usr/local/bin/zsh
And why not? /bin/zsh ?
if ( -X zsh && -f ~/.Use_zsh ) exec zsh
If they only would... But it will be like zfs and btrfs. They will decide to do it better, and the Bazar will make sure it speaks every tongue under the sun, be compatible to gpl4 and will work every February 30th.A good sound system Linux would steal
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.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.