[illumos-gate] 16992 Memory leaks in dlstat -- Alexey Romanov <a.romanov⊙at>

Has anyone used another *nix system to serve IPS packages? Not sure if it's even possible, but I came across something saying that IPS is cross platform

it was cross-platform for a brief time around 15 years ago, but I don't think anyone has maintained ports for non-Solaris/illumos platforms since then

Thank you. Info on its ports is about non-existent, at least per what I've come across. Is there is place online where the old ports might remain?

I'm not aware of any since the shutdown of opensolaris.org over a decade ago

Unfoetunately no, but reporting it is not that hard. The only dependency that is illumoa specific is libbe and that only depends on Zfs. Porting that to Openzfs should not be a big problem for a seasoned C Developer.

just doing the server side should be even easier, as you shouldn't have to deal with libbe there

Thanks for the tips. I'll keep them in mind

You will have to play with the buildsystem to get only the server parts compiled but that will work on any unix as its a flask REST API. Reverse engineering that API is also not that hard. The documentation is good enough to build your own with only the query parameters really missing. I got a server in golang feature complete enough to handle basic fetch requests on existing filesystem repos.

See depotd subdirectory

I stopped using go since though

This is good to know, thanks. This is along the lines of what I'm after. Ideally, I'd like to host IPS pkg repos on other *nix systems

Happy to help spread IPS usage

A lot of the files that make up an IPS repo can just be served directly by nginx - probably almost all of them if you don't need to support search or other package operations like publication.

(Other web servers are available)

[illumos-gate] 17190 mdb should do better with anonymous structs and unions -- Robert Mustacchi <rm⊙fo>

andyf: A very long time ago I managed to get it to work with none of the pkg(7) software: sysmgr.org/blog/2010/10/17/open_indiana_automated_install_server

cc Guest7 I guess!

nginx proxy cache works for the files endpoint. We had a script for laying out the files in a directory for apache in OI. But it also nver got over the finish line.

I don't think there should be anything (other than the search facility) that needs dynamic content

yep, and that can be turned of by sending the right versions file

I'm having a look now, thanks

so... are we ready for y2038 yet? :)

That would be IPD 14 github.com/illumos/ipd/blob/master/ipd/0014/README.md

→ IPD 14: illumos and Y2038 (predraft)

sorry, my bff just sent me a y2k meme and it reminded me that 2038 is less than 13 years now

no, we are not ready for it.

in fact i sent him that sticker image because he just sent me the y2k version of the same sticker! :)

if you have a pure 64bit system, things aren't as broken as you'd perhaps expect, but aren't great.

Fortunately there is still time! :D

It feels like "now() + 10 years" is a commonly represented amount of time though so getting there before 2027 would be ideal

there will most likely be some space hardware that will fail that beyond it's predicted life already

that is rather

now() + 10 years will be over way too soon. 10 years ago we got loader integrated in illumos, and that was like yesterday....

:P

I try not to think about it :P

if there's one thing I learned from music, it's that it's wrong to bet on space hardware

:D

hey both Voyagers are amazingly still talking

truly a testament to long term maintenance

and fortunately we can only guess about amount of work done to have them talking;)

tsoome_, thankfully it's not my job. i have a friend who works peripherally to that but thankfully for him not for voyager, he does some space radio things for NASA though

hot patching 1970s software running on 1970s hardware probably using actual core memory a gazillion miles away doesn't sound like too much fun

like sure I play with VMS and RSTS/e for fun but it's very low risk by comparison, if i break it i don't permanently brick a device that is utterly unreachable

btw, i might actually bother to learn BLISS, there are source tapes floating around for RSTS/e and much of the code is BLISS

i should look into some really small tcp/ip stacks, microchip has one for 8 bit MCUs afaik. maybe it could fit into one of the rsts/e runtimes

simh provides tcp ports for dz11 rs232 lines and that's about it for tcp/ip on rsts/e

that IPD is missing a few other places that 32-bit time_t is embedded in structures regardless of whether the application is 32-bit or 64-bit, like utmpx, wtmpx, & lastlog, or in the bufmod structs that snoop sees

that's largely because I haven't remembered/been able to update it based on further research

uniqtime32 as well

which mostly I've comiserated with danmcd about

I will PR something in a moment

Yes! PRs encouraged! :)

oh right, timezones, easy fix, just make everyone use UTC all the time

sure thing wesolows

funny, almost the same sticker from the IPD is in: imgur.com/gallery/you-gotta-fight-r…ight-to-view-nostalgia-dump-sXhQ1IP

Holy shit how many JS dependencies does this page have?!?

Anyway (after opening the URL in a Safari private window...), Yeah I literally found that Best Buy sticker and edited it to be Y2038-indicative. :)

sorry, imgur does that

I block most of them still

I actually started using noscript in response to seeing meltdown/spectre exploit demos in javascript

oh, it's an edited version of the same sticker, marvelous!

there was an article this week i think in the register about foss being dominated by greybeards that i related to

that's PR #28 on illumos-ipd dan

my beard is _salt and pepper_

alan's was untouched by snow, last I saw a picture!

must be an old picture then - it's more white than not these days

I always thought the term referred to age rather than the actual presence of said beard

Thank you richlowe.

@dangergrrl this article, right? theregister.com/2025/02/14/youngsters_in_foss

And I've tried (once successfully) to get techie-minded HS students from where my own kids went to HS to contribute.

Commit 41a4986b48d4a0e9ed138c952a9bad5124a924a6 (and he contributed twice, but the once-successful was the engagement-barrier).

He's at Syracuse now, and did a summer in deep-numeric-computing-land last I checked.

My daughter graduates with her engineering degree this year and she apparently uses at least some FOSS, they have a senior project that involves at least a pi4 and some sort of SDR hat, she's graduating a bit old at 30, she's a retired navy nuclear engineer before uni

Never too late, and good for her!

she was telling me about some lazy classmate who was also a senior who couldn't figure out how to do the raspberry pi imager... I suggested that perhaps engineering was the wrong field for this person and how the fsck is he a senior?

danmcd: my problem now is I'm pretty sure there were some times-in-ints-that-are-hard-to-grep that I have forgotten

time in time_t is a friend, time in time32_t is annoying. time in int though

time to int is :vomit: ==> if we're lucky these are 32-bit binaries and a `-m64` conversion MIGHT catch some of these, but probably not enough.

it doesn't

or maybe gcc has an option for narrowing assignments that doesn't get turned on?

you know the 32 bit userspace should probably go unless there are really good reasons :)

See IPD 14, it's proposed up-front as a possible component.

fenix ipd 14

IPD 14: illumos and Y2038 (predraft)

↳ github.com/illumos/ipd/tree/master/ipd/0014/README.md

the items are added are things that need to be fixed _even with_ a 64bit userland. So does time_t->int because LP64

ok, I'll finish reading it shortly, finishing release nots for tcp/ip for vms 6.2 rn :)

the items I listed to the IPD are broken even with a 64bit userland. So is time_t stored in int, because its LP64

a 32bit userland needs _at least_ time64_t and all of that before it can work enough to find the other broken things

because stat(2) will fail

I'm working on/playing with simh and there are warnings for the build on dragonfly that I haven't fixed that look like 32/64 bit issues

my simulators seem to work so the problem mustn't be critical! :) rofl, yeah right

i have kernel projects for dragonfly and figured I should actually use it before i go breaking kernel space, i like old computers and i figured simh would be a good project to learn some things about dragonfly. so far it's working

there's some interesting stuff going on wrt the networking with simh, trying to get decnet to work between sims as efficiently as plausible

lol, this documentation is awesome, it wants to send out RIP updates everytime a dialup user connects!

. o O ( More appropriate to send R.I.P. notifications when the user disconnects. )

lol, that would happen as well

vms telnet supports multiple sessions in the same client, too bad I was done mudding by 1995 when this release came out :)

woot! I have a license to x64 openvms! much less interesting than classic vms on emulated dec hardware

I presume virtualbox on oi should run it acceptably