[illumos-gate] 15831 Clean up compiler warnings in sata.c -- Jason King <jason.brian.king⊙gc>

How much have things changed now?

I also seldom hear the latest news about Illumos.

Very quiet

It certainly isn't dead, Oxide for example is running their stack on illumos too and IIRC it is also mentioned in their podcast from time to time.

not 100% sure but i think tsoome has the loader mostly in sync with that is in freebsd at this point, we got bhyve which is also close to feature parity with whats in freebsd, which is a great hypervisor

lately there has also been a ton of movement on both nfs and smb servers, I'm not exactly sure on the details but it looks to be work done by nexenta that is now being upstreamed (sponsered by racktop?)

we're lagging behind openzfs though, but they seem to be moving very fast and have lost some

of the due diligence illumos has wrt code quality/stability

which i find a big plus to illumos

It's true though that we don't really comunicate about all these things enough

FreeBSD is running on OpenZFS now and from loader point of view it is zstd compression support. The other larger difference is verified execution, but thats mostly related to some companies which have built their product on top of FreeBSD.

As someone who is reasonably aware of what's going on in the IT world, I could equally conclude that all the BSDs are dead, because you hear essentially nothing about them either

I think a lot of technical communities have suffered from the birdsite situation, because nothing's really grown to replace that

People have been telling me the project is dead for at least ten years

My advice is not to worry too much about an anonymous IRC user whose first question was about a foundation, and second question was about a gossip thread on the forum site of another project!

more commits:D

this channel does appear to attract a lot more random questions than others

by the name, I guess.

yeh maybe?

Meanwhile, I shall get back to catching up with building stuff on sparc

I'm personally not worried about it at all, illumos has served and treated me well in the past and I don't see that changing in the immediate future

back to more useful discussions, code.illumos.org/c/illumos-gate/+/2980 now that this merged should this be marked as such somehow? all I can seem to do myself is mark it abandoned ?

→ CODE REVIEW 2980: 15464 viona should copy tx buffers by default (NEW) | illumos.org/issues/15464

Yep, just abandon the gerrit review with a message like "Integrated"

OK, will do

sjorge: nice work

Illumos isn't dead? News to me :P

papertigers: thanks

Is there a proper way to make local modifications to a smf service that gets installed via pkg? So fugure pkg updates don't overwrite it.

s/fugure/future/

papertigers: What sort of updates?

If you just mean setting a property to something different, if you do that with svccfg I don't think it's going to get overwritten in the future

jclulow: that's what I mean. If something has like a config prop for a data directory and I modify that.

pkg will never overwrite my changes?

Yep. See svccfg(8) description of import: For existing services and instances, properties which have

not changed since the last import snapshot was taken are

upgraded to those specified by the manifest. Conflicts

(properties which have been changed both in the repository

and the manifest) are reported on the standard error

stream. svccfg will never upgrade the “general/enabled”

and “general/restarter” properties, since they represent

administrator preference.

so if you set properties via svccfg setprop, they won't be modified by import. if you set properties by editing the manifest and re-importing, they'll get overwritten when the package is updated when a new manifest is installed and imported.

sommerfeld: thanks! I will use svcprop instead of svccfg import then

err -- svccfg setprop

If you're doing things that modify the manifest you really should be building and packaging your own version of the package, in which case you deal with editing conflicts when you merge/rebase/... to a newer version

and if you need to customize the service in ways that can't be done by setting properties it's likely a case that the thing you want to change should be a property...

sommerfeld: in this case I just want to modify "<propval name='datadir'...../>"

does that still hold (not overriding modifications) is a profile is applied?

yep, and that's the sort of thing that should work well via svccfg setprop

sorry, that was a response to papertigers. I haven't dinked around with profiles at all.