00:19:07 [illumos-gate] 15831 Clean up compiler warnings in sata.c -- Jason King 03:42:53 https://forums.freebsd.org/threads/do-you-think-illumos-is-dead-now.72083/ 03:46:23 How much have things changed now? 03:50:21 I also seldom hear the latest news about Illumos. 03:50:40 Very quiet 08:00:58 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. 08:02:14 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 08:03:48 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?) 08:04:22 we're lagging behind openzfs though, but they seem to be moving very fast and have lost some 08:04:49 of the due diligence illumos has wrt code quality/stability 08:05:13 which i find a big plus to illumos 08:05:44 It's true though that we don't really comunicate about all these things enough 08:13:09 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. 08:40:35 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 08:41:43 I think a lot of technical communities have suffered from the birdsite situation, because nothing's really grown to replace that 08:46:32 People have been telling me the project is dead for at least ten years 08:49:11 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! 08:52:08 more commits:D 08:52:50 this channel does appear to attract a lot more random questions than others 08:53:08 by the name, I guess. 08:53:22 yeh maybe? 08:57:47 Meanwhile, I shall get back to catching up with building stuff on sparc 09:14:46 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 09:15:11 back to more useful discussions, https://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 ? 09:15:12 → CODE REVIEW 2980: 15464 viona should copy tx buffers by default (NEW) | https://www.illumos.org/issues/15464 09:16:09 Yep, just abandon the gerrit review with a message like "Integrated" 09:17:12 OK, will do 13:38:55 sjorge: nice work 13:46:57 Illumos isn't dead? News to me :P 16:24:14 https://medium.com/@norlin.t/by-the-way-planternetes-kubernetes-v1-28-0-for-illumos-freebsd-and-openbsd-5d57026d6a25 18:50:50 papertigers: thanks 19:01:17 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. 19:01:26 s/fugure/future/ 19:38:41 papertigers: What sort of updates? 19:39:09 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 20:11:19 jclulow: that's what I mean. If something has like a config prop for a data directory and I modify that. 20:11:36 pkg will never overwrite my changes? 20:17:57 Yep. See svccfg(8) description of import: For existing services and instances, properties which have 20:17:57 not changed since the last import snapshot was taken are 20:17:57 upgraded to those specified by the manifest. Conflicts 20:17:57 (properties which have been changed both in the repository 20:17:57 and the manifest) are reported on the standard error 20:17:57 stream. svccfg will never upgrade the “general/enabled” 20:17:59 and “general/restarter” properties, since they represent 20:18:01 administrator preference. 20:20:39 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. 20:25:43 sommerfeld: thanks! I will use svcprop instead of svccfg import then 20:26:51 err -- svccfg setprop 20:34:23 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 20:35:07 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... 20:44:31 sommerfeld: in this case I just want to modify "" 20:45:16 does that still hold (not overriding modifications) is a profile is applied? 21:14:54 yep, and that's the sort of thing that should work well via svccfg setprop 21:15:53 sorry, that was a response to papertigers. I haven't dinked around with profiles at all.