FreeBSD 13 annoyances?

Another minor irritation about FBSD13 (and again ZFS related) is that the zfs startup script* now seems to mount things in an arbitrary order: it used to be alphabetical which made it easier to find stuff in a df listing as I use quite a lot of datasets. Yes I know I could just use df on the dataset or directory in question but that's why it's "mildly irritating" rather than "actually dysfunctional"!

In the meantime I've just put my ZFS stuff in fstab and I guess that also works well enough as a long-term solution too if it needs to be... even if it is mildly irritating!

* Edit: more correctly the line that says zfs mount -a, so it's not actually the script's fault as I inadvertently implied.
 
Installing qtile through pkg starts with a black screen. When tried to compile using ports fails due to conflict between python 7 and python 8

Downloaded the latest code from GitHub, same issue. Fails to install python8 due to conflict with python7. I have installed release 13 a fresh install using pkg. No port compilation except for the above.
 
Installing qtile through pkg starts with a black screen. When tried to compile using ports fails due to conflict between python 7 and python 8

Downloaded the latest code from GitHub, same issue. Fails to install python8 due to conflict with python7. I have installed release 13 a fresh install using pkg. No port compilation except for the above.
I have done lang/python37 and lang/python38 side-by-side, no conflicts. I guess the diff is having those things installed first... Semantic difference between prerequisite and a dependency seems to have finally reared its ugly head.
 
… qtile …

On compilation, it tries to install cairo python package from 3.8 when 3.7 is already installed.

Which repository do you use for packages? Run:

grep url /etc/pkg/FreeBSD.conf

See <https://www.freshports.org/graphics/py-cairo/>

Following a build using poudriere:

Code:
% pkg rquery -r poudriere '%o %v' qtile py37-cairo py38-cairo
x11-wm/qtile 0.14.2
graphics/py-cairo 1.18.1_1,1
% pkg rquery -r poudriere '%o %v' py37-cairo
%
 
VM related:
- broken evdev support - if enabled in firefox scrolling up works as "Go back one page button" - only solution is to re-compile kernel with evdev disabled. Outstanding issue since evdev introduction
- broken virtualbox support for file sharing. Outstanding issue since 12.0 (or earlier)
- broken terminal switching: switching between GUI and any terminal and - back renders GUI unresponsive. Outstanding issue since 11.4
general:
broken software - audacious, libreoffice (tentative - maybe I am missing something)
broken kernel options TERMINAL_KERN_ATTR and TERMINAL_NORM_ATTR
 
Not the only solution. I use xmodmap. See here: https://forums.freebsd.org/threads/gnome3-weird-scroll-wheel-behaviour.78532/#post-491139

I have no problem with terminal switching (I mean under VirtualBox).
your evdev solution works. thank you. However as I am always building custom kernel, I will just disable evdev in the kernel as before.
Nevertheless this is a bug

terminal switching works with 3D acceleration disabled. When 3D acceleration is enabled terminal switching fails.
So this a bug also
 
I can add a couple of annoyances:
  • The /etc/motd has changed and now has this slightly over-engineered "template" approach. There is probably a reason for this. Perhaps in the future they plan to add # packages installed, cpu utilization, etc. This is a feature of Ubuntu that I remember being a little tacky. I prefer my logins to be deterministic so if anything changes, I can spot it quickly.

  • (This came in a little before 13 if I recall). By default the skel .profile runs fortune so I get some random message from i.e Dru Lavigne. Again, I prefer deterministic logins so it is easier to spot if there are problems. Also, does anyone else find any of these "tips" useful? It is surely just clutter.
Luckily pretty minor but I guess the real question is, why do people want so much noise when they log into an ssh server?
 
By default the skel .profile runs fortune so I get some random message from i.e Dru Lavigne. Again, I prefer deterministic logins so it is easier to spot if there are problems. Also, does anyone else find any of these "tips" useful? It is surely just clutter.
Go back about 40 years, late 70s and early 80s. This is the time the first Unix machines hit the wider public, come out of being in a small handful of research labs. On one hand, you have serious computers, made for example by IBM (and the seven dwarves) and Digital (and it's dwarves: Data General, Prime, ...). Those are used by serious business people and engineers. The machines are very expensive, it would be wasteful to use them for something merely amusing. The people who use them typically wear white lab coats, are controlled by people who wear suit and tie, or (on the engineering side for minicomputers) have pocket protectors and slide rules.

Now contrast that with Bell Labs and Berkeley. Look at the pictures of Dennis and Ken and check their hair style. Just saying "Berkeley" is enough to make it counter-culture land. People here have a biting sense of humor, and love amusements. Spending precious engineering effort and disk space + CPU time on implementing "fortune" is exactly a symbol of that. Symbols matter: it demonstrates that Unix is not MVS or VMS.

Now fast forward 40 years. The counter-culture movement has won. You can't go work in suit and tie any more in a computer or engineering job, unless you do so ironically. We run most of the computers in the world (Linux has >90% market share among servers) using an OS designed by a drunk college student (yes, I've gone to "99 bottles of beer" with Linus, he does get drunk, at least he did back then). Today, running "fortune" is only a deep bow of to two cultures, which both stopped being relevant decades ago, but they are still part of our history.
 
Today, running "fortune" is only a deep bow of to two cultures, which both stopped being relevant decades ago, but they are still part of our history.
Heh, I do kind of get that and suppose I can see this "trinket" in a different kind of light. Though I still wonder why just as recently as FreeBSD 12.x was it suddenly decided to be added to the default .profile script?

Do you really think it was added there as a culture symbol? Something like "No kids, you can't have Docker, you get fortune instead. Be happy!".
 
With the fortune stuff not enabled by default (correct me if I'm wrong), I never thought of it as clutter.

Some content is outdated, but overall: it has helped me enormously.
 
Last edited:
With the fortune stuff not enabled by default (correct me if I'm wrong), I never thought of it as clutter.
Yes, it does seem to be enabled by default now (since FreeBSD 12.x). Of course when it was just a couple of kb program in /usr/bin doing nothing, it wasn't annoying, I was happy to let it be. Now I just have to remember to comment it out from dotfiles in /usr/share/skel.

Obviously not a critical issue but I guess I am more intrigued about why it was suddenly added to the default .profile so recently. Just seems like an odd choice. It also seemed like FreeBSD was moving away from that kind of stuff.
 
Enabled for new users but not for root. 2015:


… keep fortune, factor, morse, number, primes, and random, since there is evidence that those are still being used. …

<https://cgit.freebsd.org/src/diff/share/skel/dot.login?id=11d9aa670723f508821f2bf6980a555360783a80>

<https://cgit.freebsd.org/src/diff/share/skel/dot.profile?id=11d9aa670723f508821f2bf6980a555360783a80>
 
Last edited:
It was made part of the standard base in 2015 (rather than in the games dist) which is what that link is detailing. And this I absolutely agree with, it was odd having a games package which was almost less than 1MB.

However I can't seem to find why it was decided it would improve FreeBSD by adding it to run in the default .profile. So likely someone thought "oh, goody, its in base now!, lets overly consume it and add it to the profile scripts just because we can!". This is disappointing that this idea got through review. Developers just can't help themselves it seems.

I do like the program, it is actually very useful when intentionally controlled and run with custom tips (i.e to tell staff / students how to utilize site specific services). Just weird that it has been pushed on us in such an arbitrary way.

However, perhaps this is almost a good demonstration of why we don't want graphical GUI tools to be added to base, because they will probably also end up bizarrely in startup scripts and clutter up the experience more. I am also fairly convinced that when we get this new pkg base in, people will have all kinds of crazy ideas about pulling in even more random trinkets. Perhaps they will start adding vim into the default install because "it is a package just like nvi now, so why not? Has more features right?"
 
I am also fairly convinced that when we get this new pkg base in, people will have all kinds of crazy ideas about pulling in even more random trinkets.
Frankly, I expect the opposite. "pkg base" is already integrated (you'll find it in the Makefiles, for example), it just isn't the way how base is distributed. It's unclear to me when this will come (or whether it will come at all) – but if this is some day the way to distribute base, it will change two things for users:
  • You need pkg in any case and
  • You can decide which parts of base to install without building it yourself
For developers, this means the decision of what should be part of base will (slightly) change. The only remaining consideration will be: Does it make sense to have this in our tree, maintain it ourselves, support it with our release cycle and release engineering? I expect, with only this question to be answered, quite a few things might be removed from base.
 
Yeah, thats fair. I will just need to wait and see (I will reserve my incessant whining for then ;)

quite a few things might be removed from base.
Agreed, I think at this point they might have a big rethink on all the programs. I am in two minds on this, in some ways I like simplicity and minimalism. But in other ways I don't find a completely sterile DIY environment like many Linux distributions provide very productive.
For me, I hope they adhere strictly to POSIX, SUS and don't do weird things like Debian did like removing ed.

At the same time, I find nc very useful and yet it is in neither POSIX or SUS. So in theory that would be a candidate for removal.
 
See the two links that I added to the foot of my previous post.
Ah I missed that. It makes sense. So FreeBSD's default profile (and login) *always* used to run fortune if it existed. Now because it has been moved into base (rather than the optional games dist that I generally would skip) it is always installed (and thus run).

OK, that does explain it. Mystery solved. Thanks! :)
 
your evdev solution works. thank you. However as I am always building custom kernel, I will just disable evdev in the kernel as before.
Nevertheless this is a bug

terminal switching works with 3D acceleration disabled. When 3D acceleration is enabled terminal switching fails.
So this a bug also
I have never seen the purpose to enable 3D acceleration in a VM. But I have done it this time to test.
In VirtualBox, to do so, you are obliged to use VMSVGA as graphic adapter.
Running glxgears under 13.0-RELEASE, this increases the FPS from about 800 to 1100. Well...

That being said, I have yet no problem to switch between terminals. So, if it is a bug, it's more specific than you believe.
 
I have never seen the purpose to enable 3D acceleration in a VM. But I have done it this time to test.
In VirtualBox, to do so, you are obliged to use VMSVGA as graphic adapter.
Running glxgears under 13.0-RELEASE, this increases the FPS from about 800 to 1100. Well...

That being said, I have yet no problem to switch between terminals. So, if it is a bug, it's more specific than you believe.
no, you are not obliged to run VMSVGA to get 3D working (I am getting black screen with VMSVGA/Slim/xfce4 so this is not an option for me).
VboxSVGA runs fine with 3D and 258MG Video RAM (if you want this).
I see:
6009 frames in 5.0 seconds = 1201.728 FPS
 

Attachments

  • Virtual Manager and 3D.png
    Virtual Manager and 3D.png
    161.6 KB · Views: 127
I forgot to say it was under virtualbox-ose-additions-legacy. Because nothing works otherwise.
My virtualBox run under Windows 7, it's the last version: 6.1.22. I assure you, 3d enabled = VMSVGA. Maximum video ram = 128 Mio. Your VMs are under Linux?
 
I forgot to say it was under virtualbox-ose-additions-legacy. Because nothing works otherwise.
My virtualBox run under Windows 7, it's the last version: 6.1.22. I assure you, 3d enabled = VMSVGA. Maximum video ram = 128 Mio. Your VMs are under Linux?
yes, I use Slackware.
These options should be available irrelevant of the host OS, they just are hidden:
1) setup VMSVGA with 3D acceleration (important, otherwise you will not get 3D acceleration)
2) go to the screen as in my screenshot
3) click on Video memory value (e.g. 128MB) and move slider to the right
4) click on Graphic controler value (VMSVGA) change to VboxSVGA
5) you should se benign error/exclamation mark stating "Invalid settings detected" when editing settings. Don't worry about this.
6) remember that you will have to set VboxSVGA/3D acceleration each time you edit settings (memory settings are fine).

that is all.
 
As you said, "should". There is no means to have 3d acceleration without VMSGA in my case. You can select VBoxSVGA but when you reopen the settings of the VM, it has returned to VMSVGA.
 
Back
Top