danmcd i pass thru my X722’s and even in freebsd they are a bit flaky

I just added a X520-DA2, at least that is a solid part

:)

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

(cobol suddenly paid pretty well around 1995 when y2k panic hit)

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.

jbk: Thanks for the information. Are there NICs that fully support RDMA in illumos?

dangergrrl: RSTS/E? Now that is a name I haven't heard in a long time...

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

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

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

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.

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.

[illumos-gate] 16647 bhyve should keep guest CPUID updated when using explicit CPUID settings -- Greg Colombo <greg⊙oc>

dangergrrl: I don't think we will know in 6 years (IDK why 6) whether that passes the 'so what' test

6 years is when companies will start to take y2038 seriously if it's anything like y2k

just an approximation based on what happened in the 1990s, y2k hiring startin being widely publicized around 1994ish

starded

blegh

started

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

people who are ok with doing the same work repetitively will likely have plenty of contract work.

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.

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.

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.

BUG 17134: strerrorname_np is missing some values (New)

↳ illumos.org/issues/17134

The fix is trivial enough, but it does change _sys_errs and _sys_index, which gives me a small reason to pause since

a) rmustacc deliberately chose to not change these as part of 16452 (add strerrordesc_np)

b) richlowe added a size check to the mapfile for _sys_errs

I don't think it will actually be a problem, but am I missing something?

andyf: I added assertions of the size of any public global data

if you're changing the size of public global data it must, at the very least, never get smaller

if that data is potentially subject to a copy relocation, it's easier to throw up your hands and scream at the sky

Oh, fun. I need to go and read up on copy relocations then.

I'm upgrading that "Oh fun" to "Oh joy". Similar, but more sarcasm.

Thanks for the pointer richlowe.

andyf: That data is in a copy relocation, so yes, unfortunately.

So we'll need to look carefully.

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.