00:43:46 richlowe: various SGS* variables in src/tools/Makefile don't seem to be set anywhere? or am i missing something here 02:07:16 you're not missing anything, I think they're a survivor from an earlier version. Sorry 02:07:36 there's a mess in there trying to share makefiles, etc, with cmd/ and it's gone wrong, and probably just needs to come out and be done verbosely 02:08:19 (and sgs should be in UNSHIPPED_SUBDIRS, if that actually means something) 02:09:02 yep, sgs takes care of building it, i was just wondering why SGS* are there 02:10:45 oversight trying to get it all together, I think there used to be stuff like that in Makefile.var that we were re-pointing 02:10:50 and it slipped through 02:11:05 but as above, there's other problems in sgs that are worse, and that I keep making worse still 02:11:19 so at some point I'll probably give up trying to share Makefile.com and make it better. 02:11:29 or you can, if you're doing something related! 02:13:59 the various include-y makefiles don't override eachother cleanly enough to do what I hoped, and it's only getting worse 02:18:20 do any of you, except gordon who I'm already bothering, use gdb a lot? 02:28:46 hi all. I'm just now learning about illumos and am intrigued. I was wondering if someone could explain to me a little more about the development philosophy of the project. I found this talk from 2011 (https://invidious.weblibre.org/watch?v=-zRN7XLCRhc&t=59m01s) .. the "innovation over democracy" and "code over discussion" principles concerned me a little, as this tends to be how corporate products are developed. I see similar 02:28:47 anti-user control structures emerging from projects like GNOME, which everyone is currently running away from. can you say anything to ease these concerns? 02:31:05 it is an old talk so maybe things have changed a bit? 02:59:49 advanced: I don't think we're anti-user, more that we try not to get paralysed in mailing list threads that go on literally forever 03:00:39 We're very keen on backwards compatibility for example, which is definitely pro-user 03:01:51 But we're also a small community, so we have jettisoned stuff (after a long time) like SPARC support or support for 32-bit x86 kernels, because though there were a handful of users nobody ever really showed up to help maintain it 03:02:20 And eventually you have to have someone working on a thing or you have to toss it out unfortunately 03:03:41 I hear ya, and definitely understand that. One instance of concern I could point to (using GNOME as an example) is when it was determined that GNOME Tracker would be some fancy new feature that exposes all sorts of user data over dbus, sold to the user as a handy tagging feature, but creating potential for abusive spyware 03:04:48 I can't really think of an example like that 03:04:50 I could see that being justified as "innovative" but ignoring users concerns. I see similar potential with the cited philosophy of illumos so I just thought I would ask about this 03:05:13 I think there are also as many philosophies as there are community members tbh 03:07:19 If someone had a concern like that I would certainly want to hear about it and we'd figure out what to do 03:08:02 I guess it just rests on trusting the principles of each individual developer, with some input from other developers, if there's not much in the way of community involvement 03:08:18 I appreciate the discussion 03:09:04 People who aren't in the core team are definitely encouraged to review code, help test changes, put up their own changes, and write design/discussion documents or whatever 03:09:38 We have a lightweight discussion doc process up at https://github.com/illumos/ipd for example 03:10:08 oh nice 03:10:46 I'm glad you shared that, that makes me feel a bit better actually 03:10:56 And some other information on how to contribute software changes at https://illumos.org/docs/contributing/ 03:11:52 There are definitely lots of contributions from people paid to work on the software but I think that's pretty normal -- we all have to eat etc 03:12:01 It's not one company though but a handful of them 03:12:10 understandable 03:14:16 As some historical context, in 2011 we were all still smarting a little from the unfortunate trainwreck of open source governance that Sun had whacked together for OpenSolaris 03:14:39 It had some serious challenges and definitely focused a lot on voting and boards and less on just being something you can fork on GitHub and build 03:15:59 I think people have very different expectations for open source in 2022 03:18:34 I see. I'm just now learning that Sun OS descendents are still flourishing, so this is all new to me.. I wasn't much aware of the opensol debacle :) 03:19:13 I need to watch the entirety of that video I linked above.. I believe he explained a lot about that, but I skimmed through 03:21:20 I don't like the direction Linux as a whole has been heading as of late, so I'm just seeing what else is out there to play around with. I may give this a try, but need to examine hardware compat more. how up-to-date (or not) is the HCL? 03:21:47 Not much AMD hardware on the current list 03:29:44 the only hcl I know of is generated from the driver packaging, and so doesn't mention stuff that doesn't get a driver (like cpus, etc, etc.) 03:40:04 oh ok. I noticed a note at the top of the page (https://illumos.org/hcl/) that it was a work in progress and some supported devices might not be listed 03:48:16 We definitely have a lot of modern AMD systems working 03:48:42 Desktop support is spotty or absent though, until someone finds time to work on our DRM/KMS situation 03:57:07 I was most worried about my graphics chip... it's not a common one. Radeon Vega Mobile (1002:15dd) 04:05:31 Graphics card support is one of those areas where we have enough people asking for things, just nobody who wants to do the work the give it to them 04:05:49 *to give 04:06:08 I wouldn't want to either, tbh lol 04:09:02 Well that's why we don't have it haha 04:10:17 Anything related to graphics makes me feel inadequate and stupid.. hats off to anyone who deals with that 04:12:51 I think it's going to be less about drawing per se and more about PCI devices and memory allocation and ioctls and mapping memory and so on 04:13:39 The DRM code exists for Linux already and is appropriately licenced for inclusion in other OSes like the BSDs, who maintain ports of it like we do (though ours is considerably less current) 04:14:10 Ultimately updating this would give you new graphics card support 05:27:50 That's still over my head (I might need to change my nickname), but in time maybe I can learn more and someday contribute. Heading off for the night -- thanks a lot for spending so much time answering questions and being friendly and welcoming. Good first impression with the project. I'm definitely going to spend some more time poking around with it 05:47:22 Cool! Let us know how you get on 17:23:21 I want to run something by folks here. I've enjoyed using unix-like operating systems for a number of years now, and though it is not something that affects me personally, I often think about people with disabilities and how "unfriendly" the command line must be to people who can't see or use a keyboard. I've been thinking about starting some kind of brainstorming group to identify propblems and come up with solutions to make 17:23:21 unix systems more accessible to these users. For example, piping logs to a TTS reader in understandable language.. creating a standard for an --accessible option to simplify application outputs and provide easier navigation in TUIs like ncurses. Is this an unattainable pipe dream or do you think such an effort would be feasible? 17:28:15 there are a lot of great programmers out there who are blind, which to me is incredible by itself. I'm sure there would be interest in something like this by those with interested in technology and systems but are being held back by lack of accessibility support 17:31:46 when I said "can't use a keyboard" I meant in the usual way (e.g. using a joystick to type). obviously keyboard input is essential