07:56:26 danmcd i pass thru my X722’s and even in freebsd they are a bit flaky 07:56:47 I just added a X520-DA2, at least that is a solid part 07:59:51 :) 08:02:13 I've been playing with rsts/e all day, now I'm hoping the campaign for memory safety reduces the number of new C programmers so that in 6 years old unix hacks will be as valuable as COBOL programmers suddenly were in 1995, the Epochalypse is upon us 08:03:13 (cobol suddenly paid pretty well around 1995 when y2k panic hit) 08:15:59 sorry, it's early and I'm silly, once had to write a full page on why my 15 line shell script was immune from y2k problems as 1) it didn't deal with time itself 2) the underlying time system wouldn't break for another 40 years. fun times. 09:00:17 jbk: Thanks for the information. Are there NICs that fully support RDMA in illumos? 16:05:43 dangergrrl: RSTS/E? Now that is a name I haven't heard in a long time... 16:06:52 dangergrrl: the notion that rust is the programming lasguage for the next 6 years (why 6?) let alone the next 50 is not well-evidenced 16:08:18 It has momentum and community (that matters, it's a lot of work and seems to be paying off), but also elements of tech fads like all those JVM languages, blockchain, golang 17:21:14 sommerfeld, I like old computers, I started high school in 1980 and our school had a PDP 11/34 running RSTS/E 7.07. (special school for engineering geeks). Some of my early jobs were with RSX-11 but never RSTS/E. Kinda nice to have my own high end PDP-11 even if it's a software fabrication. I'm actually think of semi-publicly running some retrocomputer instances usimg dyndns, I'm on 940mbps fiber but the same fiber with even a single static 17:21:15 IP is a business service so 5* the money. Still, I'd likely never notice even 10 people using instances of old DEC and Prime minicomputers on one of my underutilized computers. 17:41:17 duncan, I like golang better and who knows if the US Govt will reverse now that there's an admin change but at the end of last year issued a strong position that only type-safe languages should be used for like *anything* from now on in new products. 18:05:31 [illumos-gate] 16647 bhyve should keep guest CPUID updated when using explicit CPUID settings -- Greg Colombo 18:23:09 dangergrrl: I don't think we will know in 6 years (IDK why 6) whether that passes the 'so what' test 18:24:30 6 years is when companies will start to take y2038 seriously if it's anything like y2k 18:25:53 just an approximation based on what happened in the 1990s, y2k hiring startin being widely publicized around 1994ish 18:26:00 starded 18:26:04 blegh 18:26:08 started 18:35:16 on this channel I think within the past week I saw y2038 mentioned with the comment "we still have 13 years to fix". In the end I'm sure all the work will get done and very few things will actually break but it's being put off by some 18:38:01 people who are ok with doing the same work repetitively will likely have plenty of contract work. 19:02:52 Don't forget all the sliding-window "fixes" that were implemented for Y2K, instead of actually fixing the problem. They're already coming home to roost in some instances and I expect that to get much worse over the next decade. 19:03:25 And what's worse about them is there was no set "this is the slidepoint" decision, so every program is its own distinct and unique timebomb. 19:10:47 I'm taking a look at illumos 17134 (fenix) - somebody is running gnulib tests on OmniOS and fixing things upstream there, which is great, and this is something else they spotted. 19:10:48 BUG 17134: strerrorname_np is missing some values (New) 19:10:48 ↳ https://www.illumos.org/issues/17134 19:11:15 The fix is trivial enough, but it does change _sys_errs and _sys_index, which gives me a small reason to pause since 19:11:59 a) rmustacc deliberately chose to not change these as part of 16452 (add strerrordesc_np) 19:12:29 b) richlowe added a size check to the mapfile for _sys_errs 19:12:50 I don't think it will actually be a problem, but am I missing something? 19:19:48 andyf: I added assertions of the size of any public global data 19:20:01 if you're changing the size of public global data it must, at the very least, never get smaller 19:20:23 if that data is potentially subject to a copy relocation, it's easier to throw up your hands and scream at the sky 19:45:31 Oh, fun. I need to go and read up on copy relocations then. 19:51:53 I'm upgrading that "Oh fun" to "Oh joy". Similar, but more sarcasm. 19:52:05 Thanks for the pointer richlowe. 20:14:41 andyf: That data is in a copy relocation, so yes, unfortunately. 20:15:57 So we'll need to look carefully. 20:16:46 I think the way forward here is to generally say unfortunately those constants are fixed in time and things inside libc are allowed to get more info most likely.