Smithx10: I did but I switched fully to rust now. I do some UI tthings in Typescript and HTML but thats just some glue around HTML and rust. All my non UI code these days is rust when possible

Or makefiles :)

you are so memory safe now.

will see how oxide.computer does

from the bmc up to full rack

Well our memory needed a security guard to get more confident

oxide.computer/blog/hubris-and-humility har har... the hubris! and oh the humanity!

maas.io vs oxide.computer

but what about the SSI/nonstop/openssi tidalscale...single system image.. freebsd byhve tidalscale.com

just keeping adding boxes, 0 downtime, no points of failure...

tandem/compaq/hp dead is what seams to have happended

rennj: I was about to say. Seems it ended up as dead. I have not seen good SSI tech outside of HPC for a long time and even there Multisystem images are common now

oh its sad..if you follow it..opensauce dead at the root...like old ass knoppix cdroms

hp killed it

hpe/hp which ever

i mean hardware failover...is totally diff..big iron..hot swap boards and stuff, real electric i/o no this sr-iov/iommu foo now

my v2600 from hp was 128cpu/128GB of ram in late 90's

4 cabinets 32cpu/32GB

1 SSP

for jtag/debug/printf logs

sun didnt have gear like that till s10k/15k/25k

and sgi/sun had to divi up cray tech DoD mandate

crossfire

haha

sgi cray links

yeah and sun crossfire

tboned driving one day

its all the topology foobar torus rings and non local caches

either way focus on amd64/risc-v..f-arm

TCR = multiple disjoint paths between any source and destination pair.

tuning guide for amd numa ccx

yeah...

SDDC/vswitch/vsan/virtualmachines/viratual-os

unraid/proxmox/vmware/?

should have gone with ada long time ago, mr/misses golang/rust/kotalin

ada/spark get into space like the sparcv8 leon cpu

more worried about the 24year old ping bug/openbsd fuzzing found other day

Hello. I am on Smartos GZ 20221201T010802Z and when I use 'screen' from pkgsrc tools in GZ and start it from /opt/tools/bin/screen , and do ' man zpool ' I get the message: WARNING: terminal is not fully functional Press RETURN to continue

When I start in-Smartos screen, I do not get that warning. May be it is pkgsrc bug for screen package?

Otherwise, I am ssh-ed into VirtualBox VM and I don't get that message with on-hardware machine GZ when doing the same. Maybe I need to remove and re-install pkgsrc tools in GZ on that VM

pkgsrc screen uses ncurses whereas the platform screen uses native curses, so it'll just be a difference in behaviour between the two

would be interesting to know exactly what ncurses thinks is lacking

what's your $TERM inside screen? I only get the warning if I switch to something else like rxvt

I think I re-installed pkgsrc tools on both hardware machines and in GZ they do not behave like that. And in both VMs where is Smartos in GZ they do. I hope it would not need to be fixed.

If anything I can test, you can pvt me jperkin so I can test whatever you would me like to.

so if I run '/usr/bin/screen -c /dev/null' and /opt/tools/bin/screen -c /dev/null', the platform screen defaults to TERM=screen which works fine, but the tools screen 'screen.xterm-256color', which is, uh, not something I've ever seen before

(I have to use -c as I always ship a .screenrc which explicitly has 'term xterm' in it)

although there is a terminfo entry for it at /opt/tools/share/lib/terminfo/s/screen.xterm-256color

oh, of course, man(1) will be using native curses, and there's no entry for that TERM

so, yeh, just ensure TERM is set to something that works with native

/opt/tools/bin/screen -c /dev/null seems like a workaround for now

no, that should exhibit the same bad behaviour, what you want to do is e.g. put 'term xterm' in ~/.screenrc and then restart screen

oh, thanks. so it is a better workaround. And out of box behaviour does seems not to express that because it does not complain on recent pkgin GZ installs.. So maybe does not need fixing? It would behave like that only on old tools installs of pkgsrc in GZ.

I de-installed 'screen' package in GZ and re-installed it and now problem is gone in one of VMs.

an alternative is to run 'screen -a', that avoids the codepath that tries to set TERM to screen.* and just uses 'screen' which works fine with native curses

Ah sorry, I forgot to test it with ' man zpool 'Still the same after screen package reinstall. Disregard that.

jperkin, and that bug in Smartos GZ (and I think I have see that also on other places, different OSes in bash) , where simple 'man zpool' and Ctrl+C exiting, doe snot give a new line on Return key after exit anymore :P

'man zpool' , hit Ctrl+C , Hit Return and get: root@sm2 ~ $ root@sm2 ~ $ root@sm2 ~ $ root@sm2 ~ $ root@sm2 :)

And I think bug is multiplatform :P

Just on Linux/Ubuntu one can't exit 'man' with Ctrl+C :P

seems reasonable, best to avoid ^C if you can, especially when 'q' is quicker ;)

But there is 'nslookup' from where one can exit with Ctrl+C and get no propmpt echo anymore. Sounds like Bash bug or something?

if the program you're forcibly quitting from is doing funky stuff with the terminal and doesn't have interrupt cleanup routines then it's reasonable for stuff to not work correctly afterwards

And on Smartos nslookup + Ctrl+C does not have a problem :P

^C should be a last resort, and there should always be an expectation of data loss and/or corruption somewhere

jperkin, depending if one grown up using MS-DOS or not, those ones expect everything to break :P

I grew up on Amiga, the expectation there is everything is amazing until you get a Guru Meditation fault ;)

jperkin, :)) Lucky you, they won't buy me an Amiga over presumption that 'computers are just for games' . I build my own PC late, in 2000. I actually grew on Sharp MZ-700 staring at BASIC apps in hex monitor.

Of course, Internet was on Linux diskless X-windows strating from 1995/6

Sorry, for offtopic.

Amiga actually had a debugger over serial line in ROM.. for Guru meditation situations.. not that I have been using it ever..

hi, everyone! how are the things?

this zpool is like an advanced persistent threat i'm having to completely format the drive to get a fresh installation going

for next time, is there an easier way to tell the smartos boot media to ignore a zpool?

try dropping to the bootloader prompt and `set noimport=true` before booting

jbk: thanks added to my notes for next time.

though unless it's changed recently, you should be able to drop to a shell during the installer, export the zpool, and manually create the desired pool

b-rex: If it's a zones pool, make sure you've uttered `sdc-factoryreset` on it. That indicates (via ZFS property) the zones pool should be ignored by smartos boot.

Basically sdc-factoryreset does: `zfs set smartdc:factoryreset=yes ${SYS_ZPOOL}/var`

danmcd: also added thanks

The official way to do this is to use sdc-factoryreset, FTR. But you can do the zfs property set if you're Having Problems.