johnjaye: I did link the exact trackball I use: xkeys.com/l-tracbk.html

Title: P.I. Engineering X-keys L-Trac Black Trackball X-keys®

oh i see. the picture shows the person using their fingers to operate it

as opposed to the one where it's on the side of a regular mouse and you still use the thumb

tm512: out of curiosity, did you implement all 3 of those changes at once? or did you try them one at a time?

johnjaye: I think switching to dvorak was like a couple months before getting this particular trackball, but I was also trying stuff like vertical mice and cheaper trackballs beforehand. kinda hated what I had tried

ah ok. i've read studies on dvorak that say it has no benefit over qwerty.

so i'm interested in people with evidence about that

it might have no speed benefit but have a "usability" benefit though if that makes sense

from what I'm aware of, there's no evidence that people type faster on dvorak vs. QWERTY, at least when properly trained

I don't know how much dvorak actually helped ergonomically

but I type like twice as fast now as I did on QWERTY, because I had to learn how to touch type

sure touch typing is a huge benefit. but as far as layouts go the main metrics i would think would be speed and accuracy

if you can't show a change in one of those then there's no real benefit to an alternate layout

but comfort/ergonomic could be a potential 3rd possibility you could measure

johnjaye: well at least with english text, pretty sure dvorak is hands-down *easier* to type on. significantly fewer awkward movements from the home row position (and fewer movements from the home row in general). a bunch of the most common english words can be typed on just the home row

no good evidence that this makes a statistically significant improvement in typing speed (I mean, you can make awkward movements just as quickly). I'm not sure if there's been any kind of study on typing-induced RSI prevalence between QWERTY and dvorak (or colemak) users, though

I can see that Dvorak layout would be better for some things. But it would also mean always needing to reconfigure everything for that use. It's not without a burden.

And then you will need to be bilingual on the keyboard for different layouts. Because you won't always be able to use dvorak and will need to also be able to use standard qwerty layout when not configured.

And all of the normal things like hjkl movement no longer makes sense and so some other compromise must be made.

There is also the newer Colemak layout which is not quite so radically different. That might be a good thing or a bad thing. But more of the lessor used keys such as the punctuation and brackets are moved making it a little more "normal".

I think the biggest benefit that anyone working with the keyboard very much can do is to learn to touch type with all of their fingers. On whatever layout they choose.

rwp: personally, I never liked or used hjkl movement. I only really use them for some vim motions, but for actually navigating I use arrow keys (pretty convenient since I use a 60% keyboard and arrows are fn + ijkl, at a resting position my fingers are already right there)

can be an issue with games that don't allow key remapping, but it's possible to just switch layouts on the fly

I haven't actually made any effort to remain "keyboard bilingual". it is rather annoying to type on QWERTY now, but I can do it if I need to. if you do considerable amounts of typing on machines where you can't change to your preferred layout, I can understand it being a dealbreaker, just isn't really one for me

for me, the worst part of switching was actually making the switch, and being infuriatingly slow at typing for a while. I'll probably never switch keyboard layouts again even though there are some that are arguably more optimized for reducing finger travel (even colemak, iirc)

hi

Title: Mozilla Community Pastebin/SwoL61du (Plain Code)

I'm having disk performance issues, what do you guys read from this? what is syncq_wait ?

Asyncq_wait and syncq_wait are, respectively, the time that data (sync or async) spends waiting to commit to disk in TXGs, and the time sync data spent waiting to commit to the ZIL. Neither of these columns include disk service time.

Title: OpenZFS: Using zpool iostat to monitor pool perfomance and health | The FreeBSD Forums

so it's normal for syncq_wait to be over a minute?

hi, I am starting to play with bhyve (via cbsd) on old hardware ( Intel(R) Pentium(R) CPU G645 @ 2.90GHz with 4GB RAM ) and created 3 guests (FreeBSD /UFS/, OpenBSD, Debian). All with only 512m RAM. I have tried iperf to guests and surprisingly FreeBSD guest is slowest with 600MBits/s, OpenBSD 750MBIts/s and Linux 2.4Gbits/s. Do you have any idea why is FreeBSD slowest?

pvalenta: which virtual NIC are you using?

Any ideas why bhyve keeps getting killed like this? paste.mozilla.org/2nD9DfxX

Title: Mozilla Community Pastebin/2nD9DfxX (Plain Code)

it doesn't matter how much memory i wire to bhyve, i have 16gb ram and tried wiring 4gb, same thing happens.

tykling, FreeBSD vtnet, OpenBSD vio, Debian has virtio_net virtio1 enp0s6

tykling, all of them virtio_net

So. . . I have a box running 13.2-RELEASE-p9.. it's been upgraded from source several times, but in the most recent upgrade there were some change that weren't exactly mergemaster-friendly, but I did my best.

Mar 19 09:00:00 vincent syslogd: /var/log/daemon.log: No such file or directory

I'm getting events like that lost. . . and indeed, there is no such file.

It is referenced in syslog.conf, however: syslog.conf:daemon.info /var/log/daemon.log

Is that a log that went away?

that it is, yes

I see no reference to it in src/UPDATING

for that particular file, you can just touch it and i think syslogd would be happy

yeah i have no idea why that would come up during an upgrade

i have... *stares up into the distance*... yeah. i have never done a source upgrade

should logs be 600 or?

i think many of them are often 644

doesn't that still allow world read which can be bad for sec?

I'm leaning more towards removing it from syslog.conf, since there's no reference to it in /etc/newsyslog.conf

Depends on the log.

alepzi, yes. and some logs are 600

You shouldn't always have to become root to look at every log.

Pro Tip: /etc/newsyslog.conf shows the preferred pemissions for the logs.

^ good point

ah nice

You can tighten them up. . . but it may cause uncessary work for yourself.

uh, my /etc/newsyslog.conf says /var/log/daemon.log 644 5 1000 @0101T JC

jaredj, your OS version?

14.0-RELEASE

p-something

mine too, 644 for daemon.log. 13.2

yeah, I'm not sure I could get used to a trackball that isn't thumb-operated

I do love my trackball, though

I think I saw where the mergemaster went sideways.

kevans, i tried a fingers trackball once. it made my rsi worse

CrtxReavr: i'm not sure if mergemaster is supported anymore. it was replaced by etcupdate

I had newsyslog.conf entries for /var/log/named.log & dhcpd.log right after weekly where this new daemon.log is supposed to go.

dstolfa, in 13.x?

CrtxReavr: i... think so? i'm not 100% sure about 13.x

AUTHORS This manual page and the script itself were written by Douglas Barton <dougb⊙Fo>.

etcupdate is on my 13.2 system.

Though mergemaster is still there too.

it's probably there because people still use it, but i'm not too sure it's actively tested

BTW, dougb is an awesome shell scripter and mentor.

Learned a lot from him.

He wrote the service(8) util, mergemaster. . . bunch of other stuff.

Before service(8), in the FreeBSD world, you had to ``/etc/rc.d/whatevs restart``

Or /usr/local/etc/rc.d/ depending on what you were dealing with.

would you make a webserver log 644 or 600?

alepzi-: i'd make it 644. what value would it have to other users who can log into the system? if it would help them find information about security measures (e.g. /var/log/auth.log), or show them what to attack in order to elevate access (e.g. /var/log/cron), that's why i'd make it 600. the web server *error* log i might make 600.

course, if it's just a web server, i wouldn't expect non-admins to be logging onto it all the time either

Is mergemaster still present on 14.x?

yes

but its being deprecated

anything replacing it?

alepzi-: etcupdate

ahh

root@videotron:/usr/local/www/apache24/data/videotron/freebsd # pkg search libc++

pkg: sqlite error while executing iterator in file pkgdb_iterator.c:1090: Invalid regex

the error I am getting

because libc++ is an invalid regex

¯\_(ツ)_/¯

try with --glob or --exact

or just escape +

anyone serving http3 over port 80 too or everyone just doing 443?

why would anyone do that ?

do what

babz:

https on port 80

i said http3

as in quic

it's udp

is it a syntax error to make a udp pf rule that has "flags any" because that doesn't apply to udp rules?

does quic support a plaintext mode ?

alepzi-: default port for the https:// scheme is still 443

but with alt-svc and https/svcb dns records it could be anything I guess :D tough time to be filtering outbound

I upgraded my desktop to 13.3-RELEASE and the radeonkms driver now will not load without a kernel panic. I ensured a full pkg upgrade -f of everything. No joy. Is anyone else seeing radeonkms driver problems with 13.3R?

I reverted to the previous Boot Environment because I must do work today. I won't be able to debug further today but will need to debug it at some point.

rwp: you need to compile the module from ports. The package is built for 13.2.

cracauer, Ah! So probably if I wait a few days the autobuilders will have caught up to it with a new build against 13.3R?

No. That will only be fixed when 13.2 is out of service.

Hmm... Me thinking through the ramifications...

Does that mean that 13.3R is not really supported by the precompiled pkgs binaries? Because the packages are not compatible with the 13.3R kernel?

Honestly I have been waiting for 14.1R before I upgrade to it. I think I noticed that 13.2-RELEASE-P10 just released today too. If I stay on 13.2R then I would upgrade to -p10.

the underlying problem is to have kernel modules in the port tree

That does seem to make for a more complicated dependency problem. :-(

I'll also be honest and admit that I did not read the 13.3-RELEASE Release Notes ahead of time. Of course I should always do that. But I feel comfortable that I can always use Boot Environments to reverse out of any problems like this that might occur.

Now that I have read the Release Notes I don't feel bad I did not since it did not say anything about kernel ABI/API changes breaking pkg binary drivers. (shrug) :-}

It looks like 13.2R EOL is 13.3R + 3 months. 13.3R released March 5, 2024. So 13.2R EOL on the schedule is June 2024. Sometime after then the autobuilders will rotate forward to building against 13.3R and the pkg binary packages with the radeonkms driver will then be built and supported on 13.3R. And there is security errata support through that time. I think. Which is a fine timeline for me. No problem.

Maybe between now and then I will be motivated to set up my own poudriere pkg autobuilder and sidestep the problem. Who knows?

rwp, u can just build locally

Right. But I am task saturated with other things at the present time. And there is no reason 13.2R isn't doing well for me. Easier if I just stick with it for the moment.

I haven't yet set up poudriere for me yet. I want to do that. Just life and time keeping everything from happening all at once.

To be clear I really appreciate the help understanding exactly what is happening. Now that I do I understand it and it is making perfect sense. And I am up and running okay and all is good with the world for me. I really appreciate the help today when I didn't quite understand the problem.

Unfortunately I need to get back to work. Ugh. Oh well!

rwp: i've had a similar problem building locally, where 'poudriere -b latest' fetches an older version of drm-kmod that's not compatible with my system. i had to set it up to force building certain packages from source.

i feel like there should be a better solution for this, like a way to make minor-version-specific kmods in ports

(of course it's easy to say that, no doubt harder to actually implement :-)

wonder what this means: pkg: Package database is busy while closing!

A contributing problem to this is when the kernel changes abi/api between point releases causing an invalidation of compatible drivers.

It's the type of thing where one might ask, Was it really required to do that in a minor point release? Or should it have waited for a major version release?

it's because "the kernel ABI" is defined entirely in terms of __FreeBSD_version and that has to change for *any* internal kernel ABI chance

Through upgrades of all of the 12.x and 13.x using this same radeonkms driver so far this is the first time I have hit the problem.

for example, because NFS is a kernel module, any change between how the kernel and nfsd communicate requires a __FreeBSD_version bump

this is not a great situation generally and it might be nice if there were a separate ABI (+ ABI version) for external modules

I am only saying that most point releases (all through 12 and up until now in 13) none have triggered this pitfall of a pkg driver being incompatible with the kernel.

And having now read the release notes I didn't see anything in them for 13.3R that indicated I should expect this issue either.

So maybe the problem is that actually the change was inadvertent and perhaps not expected at some level of things or it would have been avoided.

i do not think that's the case, it's expected that __FreeBSD_version can change between minor releases

(i don't know why you didn't encounter this before, though)

rwp: list of __FreeBSD_version bumps in 13-STABLE: cgit.freebsd.org/src/log/sys/sys/param.h?h=stable/13

I'm thinking of installing beadm, but I have some questions. Is it possible to configure beadm so that I can ssh into the FreeBSD server and unlock a ZFS-encrypted root pool?

(i.e., so that it works like ZFSBootMenu for Linux.)

andreas303, Note that beadm is in ports, and the original tool to look like the original Sun era zfs tool. But bectl is in base, so that in base we have a tool that does not require a port install. Meaning that you don't require to have beadm installed in order to have full benefit of Boot Environments. The bectl in base is sufficient.

but bectl doesn't allow unlocking an encrypted pool prior to booting

It's okay to have both installed. And either may be used. The feature set of the two of them is not exactly the same.

Right. It does not. That's going to be either GELI or ZFS native encryption. Probably GELI at this time.

bit of a long shot, but has any tried running FreeBSD on an Opengear terminal server?

rwp & lw: OK, so, as I understand it, neither beadm or bectl support unlock of ZFS-native encrypted root, and none of them support login to beadm/bectl via ssh?

andreas303: bectl does not support that. i have no idea about what beadm supports since i've never used it.

lw: OK.

When you ask if beadm/bectl supports this it is like asking if "cat" supports it. Because as I understand things both of those tools set up the file system and neither has anything to do with encryption directly. Instead the question would better be if any of the boot managers support ssh logins and encryption.

Title: Chapter 15. The FreeBSD Booting Process | FreeBSD Documentation Portal

As far as I know none of them support ssh at the boot loader phase of booting.

But I don't know much so possibly there is such a thing.

rwp & VimDiesel: Ah, OK.

rwp: andreas303: yes, we would need something more like an initrd that would be configured to do something like that

You can boot unencrypted storage and have sshd running there, then ssh in and supply the key, then reroot.

I have at least one system configured exaclty like that, for use as a remote backup destination for important stuff.

rwp: Have you seen forums.freebsd.org/threads/outerbas…le-geli-encrypted-root-on-zfs.80078 ?

Title: outerbase: install script for remote-unlockable geli-encrypted root-on-zfs | The FreeBSD Forums

From the URI, that's more or less basically what I'm doing.

bectl is kind-of the wrong tool to achieve what you're trying to do, too.

mason, I have not seen that posting before. But it looks quite clever! I am saving that one off and am definitely going to try it. (I am familiar with reboot -r and I also find that capability extremely clever too. Such as this use of reboot -r people.freebsd.org/~lidl/blog/re-root.html)

I don't know exactly what andreas303 was wanting but for me on servers I would want it to be able to fetch the encryption key from the network and retry until the network was available. At that point I have lots of possible ways to provide good security of the key for the event of the server being stolen or the underlying encrypted data exfiltrated.

This article you cited looks like this might be possible using that method. So very cool! :-)

oh cool, so apparently 14-STABLE got support for drm-61-kmod. I'll have to see if these page faults still occur on that version

little bit frustrating that I don't have any real method to trigger the page faults, they just occur at random within like a few hours of using the machine, and when I'm at home like I am now, I'd generally prefer using my PC, not this laptop