UFS was fine for its day, but a filesystem based on the rotational latency of a spinning disk and heads attached to a moveable arm doesn't make a lot of sense when what you're writing to is solid state storage with no moving parts.

unfortunately we do not have anything for solid state storage either.

ZFS works fine. My point is just that the context that UFS was designed for is essentially irrelevant these days. No one's running RA81s on a VAX 750 anymore, outside of a museum.

I guess the rotational speed etc other physical assumptions are long gone, but assumptions about file sizes, blocks, fragments are still not that bad. especially considering the use cases and improvements done in BSD world.

[illumos-gate] 17245 Manual formatting includes extra trailing text -- Peter Tribble <peter.tribble⊙gc>

Sure. But the fundamental engineering constraints that drove so much of their design are gone. The big win of UFS (then called FFS) was that it changed the write path so that blocks and fragments were laid out in such a way that they got could much more of the bandwidth of the disk than the 7th Ed filesystem.

On a system where you've got ZFS as a fully supported option, I don't see many benefits to using UFS for most use cases.

Has anyone tried out a bootable ZFS USB key? /me has been too distracted to spend cycles on it, but I'd be curious...

I used to do that with SmartOS a long time ago. I wonder if I still have notes.

danmcd: blog.shalman.org/smartos-zfs-boot-media perhaps?

Oh I'm so sorry for forgetting about that!!!

apology never needed. That page is nearly 10 years old!

it's so old is uses grub though I think.

so it would need to be updated for loader... And I don't know how that would go with EFI...

So probably not actually useful any more the more I think about it.

But in principle, whatever we're doing to create the bootable zones pool should probably be doable on a USB stick with a different name.

we can put zfs on usb stick, that is no big deal, but I have big concerns about the usability

like, I have this stupid USB-A to USB-C connector cable, but USB-A side is not holding well and the connection is lost for a moment if this setup gets moving a bit....

I'm mostly thinking "for the installer", but that's not a this-channel discussion.

btw, I have stuck bhyve vm, apparently some zfs test messed things up (surprise) and there is non-responding pool, so I need to force dump... can I send a nmi for it or something?

tsoome: on SmartOS it should be `vmadm sysrq <uuid> nmi`

am. this one is on omnios.

`zadm nmi <zone>` if it's running in a zone and you have zadm installed, otherwise bhyvectl --vm=<vm> --inject-nmi

thanks!

andyf: same as on OI as of today :)

can someone showme how to reconfigure the default sound card from audiohd#0 to audiohd#1?

[illumos-gate] 17241 stdc_bit_width manuals should be shipped -- Robert Mustacchi <rm⊙fo>

toasterson - Oh, nice :)

[illumos-gate] 17236 Update JEDEC vendors to JEP106BK -- Robert Mustacchi <rm⊙fo>

as a matter of style, for new code (new files), do we still want to use CTASSERT(), or go with _Static_Assert() or static_assert() ?

danmcd: The biggest challenge with ZFS on USB is that /devices paths depend on where you plug things in

Secondary challenges include the fact that sometimes USB devices aren't immediately available the first time we go to look for them, etc

jbk: I think CTASSERT() for now

If we decide to change that, we would want to change all the other uses at once

(which doesn't seem immediately valuable etc)

ditching CTASSERT is valuable because of the line-number thing

oh, wait, that got fixed?

or am I an idiot? there was something weird with CTASSERT

richlowe: That was the old implementation.

jbk: I wouldn't use _Static_Assert(). C23 has moved away from the define a macro to the leading underscore variant.

richlowe: To clarify, CTASSERT is now implemented in terms of _Static_Assert().

rmustacc: I see, I just remembered the original way having issues. I didn't notice it had been fixde

or didn't remember

rmustacc: I didn't understand your reply to jbk though,

IIUC, pre-c23 it was _Static_Assert(), but I believe with C23 it's not just static_assert()

but then we have our pre-pre CTASSERT().. why I was asking for the preferred way

pre-c23 the header is required to #define static_assert() to _Static_Assert(). I don't believe it's subject to NDEBUG, but in general we recommend to use CTASSERT.

Or at least, that's what I'd use.

If you're outside of illumos, use static_assert().

I remember wanting to use not-CTASSERT to control the message

but, now I know the line-number thing is fixed, that's been my only thing

OK, well, something we can look at fixing too, I'm sure.

It's not subject to NDEBUG I think, so it may be more reasonable to move towards the standard thing over time.

But NDEBUG makes normal assert pretty dangerous.

oh right, in illumos terms I always want CTVERIFY()

never CTASSERT()

alanc: hey, you seem to keep with with the C standards. I want specified and predictable enum sizes :)

since it turns out I think every time I wanted static assertions lately that was why

richlowe: That's in C23!

You can do enum foo : <type> { ...

hooray!

That's pretty fancy

I guess I need to get back to work on stdlib stuff and POSIX.

Though really also need gcc15 for a valid value of -std=gnu23.

Actually really nice... some enums really only need to be uint8_t, e.g.

yeah, the biggest part is that you can't technically _know_ how big an enum will be, without it

(hence the asserting the things don't change size by surprise)

erlang, I believe, is what you want for that

presumably ericsson and telephony heritage

I stole some of their syntax for a command line tool I use, and that's literally all I remember

I work with RabbitMQ which is written in that language. I know nothing more either.

hello joe!

Hi. I have installed vaultwarden into a pkgsrc zone, but I have no idea how to start it. Can you give me some hints?

szilard, I just installed vaultwarden yesterday using the ips package in the GZ

szilard in Omnios, but the steps should be the same. svcadm enable vaultwarden, but first check the configuration to setup certs before starting the service

tsoome: we are missing want to sign us up?

I could do some distro specific mentoring

Or userland if somebody wants to send in installer things or IPs metadata tasks

toasterson I know nothing about the procedures there etc, it also may be the train is gone for this year. But is it one option to make us visible.

summer of code is something we have done, and largely failed at

it requires mentors who have _time_

quite obviously.

I mean, right, but we don't have that, so what would we do?

usually it depends on priorities.

or at least so they say.

well, yeah, but everyone who does it for a job's priority is probably "keep my job" :)

unless you can sell someone corporate on it

that'd be cool and different

Something I have noticed when attempting to mentor and guide folks in our community is that the folks who are most successful are already using the software for something, and they want to improve something pretty directly related to what they're doing.

e.g., you're hitting a bug in a specific program, or want to add a particular feature you personally need.