The #BSDCafe #Billboard instance has been updated to #NodeBB v4.10.2.

#BSDCafe #BSDCafeUpdates #BSDCafeAnnouncements

If a toot in Mastodon is a response to a federated post from NodeBB: does the response appear in NodeBB?

Et cetera.

Test 123 æøå ÆØÅ

The Foundation's announcement:

• https://freebsdfoundation.org/blog/call-for-testing-introducing-the-laptop-integration-testing-project/

Thanks to u/anh0516:

• https://www.reddit.com/r/freebsd/comments/1seej1t/call_for_testing_introducing_the_laptop/
• https://www.reddit.com/r/linux/comments/1seei3y/freebsd_call_for_testing_introducing_the_laptop/

In The FreeBSD Forums, maybe not open to discussion:

• https://forums.freebsd.org/threads/102265/

https://mastodon.bsd.cafe/@grahamperrin/116360952509659346 a few minutes ago did address a category here in NodeBB, but has not yet appeared in the category:

https://billboard.bsd.cafe/category/6/freebsd

It is visible as a post at https://billboard.bsd.cafe/user/grahamperrin@mastodon.bsd.cafe/posts.

A post, not a topic. Might this explain why it is not a topic in the category?

Officially, Tribblix follows the "when I feel like it" release model. I make a release (as in a new version that requires a full upgrade) when I feel it's about time for one, rather than calendar-based or feature-based.

This tends to mean that releases come every few months - with the range being 2-6 months.

Should releases be on a more consistent timetable?

Should releases be more frequent?

Or should I just bumble along with the current model?

For a beginner C programmer, what would be a good roadmap for getting to the OpenBSD Driver Development level?, I reckon there are books about developing on FreeBSD and other books, but the more specific for OpenBSD, the better.

So far, I learned about the flags in order to set more debug output, and debugged a specific issue I had with the msk(4) driver, now, if I were to add another device in another place, for example, uaudio(4) as a side project, I can understand its flow, from pci, to uhub, and so on. So from there I should be able to understand by reading the code on it.

I can recompile the kernel, debug and well, read the code, now, I wonder if there are other specifics that I can have regarding how the code is organized and written in OpenBSD. There is a good presentation about driver development, now it talks about specifics when you are already in that world, it doesn't specify the work process, or even, a video of how a driver was made with good standards. Given that OpenBSD is well written and structured, any programmer should be able to understand and be able to add support of something simple, like a microphone.

PD. Microphone with issues on uhub is AKG lyra, which I will debug later... I have to recompile my kernel of course.

And I don't plan to stop anytime soon (or ever?)

I couldn't have asked for a more correct, well-documented, and secure system. I took my hardened /etc/* files and added them to VCS for reproducing new environments quickly.

I first began following OpenBSD 6.5 and first deployed OpenBSD 7.5 for my side projects, and as of 7.8 I am using OpenBSD in production.

I've been using Linux as my daily driver for 10+ years. I'll probably stick with Linux on desktop but OpenBSD has virtually replaced all of my hosting. I recently spun up a new Linux VM only to power it down shortly after attempting to configure systemd... It just can't compare to rc(8).

I'll end this rant now. Some useful links/people that got me through the last couple years:

• https://www.openbsdhandbook.com/
• https://undeadly.org/
• https://docs.vultr.com/category/bsd-guides
• anything by kristaps and bcallah@
• r/OpenBSD

My liferaft has a name: Pickle. If you recognise the name, you might already know
a little about
me.

People's
hidden
histories

… please tell me yours.

#SilentSunday so here,
today
I'll say
no more.

Snippets, instead,
weeks and months ahead.

Peace

@fuzzy@beige.party @grahamperrin

https://billboard.bsd.cafe/post/150 posted one hour ago, viewed in beige.party Mastodon:

– not visible on the timeline at https://mastodon.bsd.cafe/tags/silentsunday. I'm not bothered, just curious.

It is strongly recommended to reboot after each system update, therefore the low number:

root@omnios:~# uname -a
SunOS omnios 5.11 omnios-r151056-1acbca4f5bd i86pc i386 i86pc
root@omnios:~# uptime
05:54:48    up 14 day(s), 13:50,  1 user,  load average: 0,23, 0,23, 0,22
root@omnios:~#

Dear Café,

In the nice bar mood setting, I thought I would share my impressions when pondering changing from Linux-originated container technology to FreeBSD jails. Please treat what I say here as you would treat some fellow meandering about his stories about his great errands - with a bit of interest, and a bit of reservation. In the end, you can never know how much of it is true or accurate, and how much of it is just made up or self-believed misconception.

Reading up forums and hearing people, Container vs Jails seems to be about technical merits or security stance. Won't comment on those (I believe in the wake of modern discoveries these would need a lot deeper and nuanced analysis, than could be hand-waved away as easily done), but highlight a more selfish divide: portability and reproducibility of configuration.

You see, I worked at places, and often heard "cattle not pets". Means you should not grow to like and treat a given system with utmost devotion (like you would a pet), but rather treat it as dispensable, replaceable (like... ok.. maybe the anglophone metaphor breaks down a bit, since you would still not be that crude to cattle, but anyway). In retrospect, one driving force behind this might be the many kinds of Linux systems - each shipping a different version of (spare me for uttering the name) systemd, having slightly different conventions of location or structuring of configuration files, naming and packaging utilities up slightly differently etc. So you incline not to grow too attached with a flavor of Linux, and try to abstract.

(Truth be told, the luxury of abstraction is more the privilege of the application developers.. the more you are an infra developer or sysadmin kind, the less you can distance yourself from the pits of configuration and system specifics)

Thus, Containers (packaging up a userland into a neat layered tarball) are used not because we (app developers with some sysadmin blood flowing in the veins too) couldn't configure a system to run some service directly. It is because we don't want to, because the next day on an other distro it would work and break very slightly differently. We don't want to care, we want uniformity.

So we package the userland, and expose some minimal surface to configure (ah, the diversification there too.. ENV vars, command-line flags... or, if you really need it, mounting some specific config files into the running container), and thus run our little services.

Jails... a very interesting topic. Giving you all the isolation you want, yet not sparing from the usual burdens of configuring. But, this is where the uniformity of FreeBSD might be a savior. If you get those etc files right once, you can keep reusing them forever (hey, anyway, I said mounting some config files into a container every now and then fine, so setting up some config files to a jail must fly as well).

(Just between us, there's still a gap between "can run this service with passing some flags to the container config" and "need to create jail, install some packages inside, copy some config files inside". For a linux app dev, the former sounds reproducible/minimal. The latter gives an Ansible vibe, which is tolerable, but never raises fond memories. Aside, with Podman coming to FreeBSD, maybe this gap would close as well)

Then there's the lingering self-doubt. If it is a jail, will I be able to resist to apply a one-off fix inside, that I forget to record in whatever manual or automation if I want to set a jail up the next time? The userland of running containers is immutable - well there's the mutable overlay, but when you kill and restart the service, you expect it to just run with only the immutable layers reconstructed.

An other factor might be backups. Don't think it is standard expectation that in event of failure, there would be meaningful backups of the running system state. Not of the system you treat as cattle, anyway. So your best bet is to have all these minimal specifications of what containers you run with what parameters, and better they work if you need to spin them up on a quickly provisioned new node!

But, if you have a great backup culture, and can restore jail contents quickly and at will (and can bridge that time over somehow for your service), then maaaaybe you don't need to have all cattle. Maybe you can have pets. Maybe it is ok to fix things in-jail, since you have an immutable historic backup record you can compare against.

The promise of FreeBSD with jails is that we can again be the sysadmins and small kings of our own kingdoms. The reality of running services as Containers is the demanding expectation to herd a cattle without mercy. And here we are, torn between words.

Thank you for your attention, now let's get an other beer.

https://mastodon.neilzone.co.uk/@neil/116347316093906602 @neil@mastodon.neilzone.co.uk can't be quoted, so here's the link.

Seven hours left. Happy voting!

Sandpit here.

Things that I post, might disappear.

Expect an unstructured mix, a mash. Not tidiness

@rl_dane

This is where the BSD Cafe staff shares news, updates, service changes, and important notices about our community and infrastructure.

If you want to stay in the loop about what's happening behind the counter, you're in the right place.

Keep an eye on this category - we'll post here whenever something changes, breaks, gets fixed, or gets launched.

Discussion is welcome: if you have questions about an announcement, just reply here. For general chat, head over to the BSD Cafe Lounge.

Intro fields

• I'm Radio_Azureus on many fediverse servers

• I play with (important) OpenSource operating systems ever since I discovered them

• I've spawned in this lifecycle long enough ago to

• work on tube electronics which high voltages

• I love 5 1/4" FDD's

• I know what BBS networks are

• I still know hayes commands 'ATX3DT ATA'

• I like what UseNet has been

• I know how much fun listserv has been

• I love vim by Bram Molenaar

• I have C64 / C128 IBM S34/S36 A500 A4000T A1200 x86 x8664 experience

• I'm a electrical technician

• autodidact (NL)

• cyclist

• sound engineer

• musician (bass instruments, synths, piano, brass)

• acoustics engineer

• network engineer

^Z

EOF

This is the sandbox. Post, reply, format, break things - nobody will judge you here.

Use this category to test federation, try out formatting, see how your Fediverse account interacts with the Billboard, or just press buttons to see what happens.

Nothing here is permanent, nothing here is serious, and if something catches fire, that's kind of the point.

Have fun. Just don't test in production.

Grab a drink, take a seat, and relax.

This is the off-topic corner of the BSD Cafe Billboard.

Introductions, random thoughts, tech tangents, music recommendations, photography, mechanical keyboards, or whatever else is on your mind - it all belongs here.

The only rule: be kind to each other.
We're pro, not against. Supporters, not haters. Builders, not destroyers.

The Lounge is meant to feel like the best part of a conference - the hallway track, the dinner after the talks, the conversation that starts with "so what do you actually run at home?"

Say hi. We'd love to know who's sitting at the table.