07:58:39 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 07:58:45 Or makefiles :) 08:19:38 you are so memory safe now. 08:21:17 will see how oxide.computer does 08:21:34 from the bmc up to full rack 08:28:52 Well our memory needed a security guard to get more confident 08:28:55 https://oxide.computer/blog/hubris-and-humility har har... the hubris! and oh the humanity! 08:30:39 https://maas.io/ vs https://oxide.computer/ 08:32:38 but what about the SSI/nonstop/openssi tidalscale...single system image.. freebsd byhve https://www.tidalscale.com/ 08:33:02 just keeping adding boxes, 0 downtime, no points of failure... 08:33:31 tandem/compaq/hp dead is what seams to have happended 08:36:11 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 08:36:44 oh its sad..if you follow it..opensauce dead at the root...like old ass knoppix cdroms 08:37:28 hp killed it 08:37:38 hpe/hp which ever 08:38:57 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 08:39:27 my v2600 from hp was 128cpu/128GB of ram in late 90's 08:39:36 4 cabinets 32cpu/32GB 08:39:42 1 SSP 08:40:00 for jtag/debug/printf logs 08:40:21 sun didnt have gear like that till s10k/15k/25k 08:40:40 and sgi/sun had to divi up cray tech DoD mandate 08:40:44 crossfire 08:40:46 haha 08:41:49 sgi cray links 08:41:58 yeah and sun crossfire 08:42:13 tboned driving one day 08:47:34 its all the topology foobar torus rings and non local caches 08:47:55 either way focus on amd64/risc-v..f-arm 08:50:41 TCR = multiple disjoint paths between any source and destination pair. 08:50:42 https://en.wikipedia.org/wiki/Torus_interconnect 08:56:49 tuning guide for amd numa ccx 08:56:54 yeah... 08:58:23 SDDC/vswitch/vsan/virtualmachines/viratual-os 08:59:19 unraid/proxmox/vmware/? 09:20:37 should have gone with ada long time ago, mr/misses golang/rust/kotalin 09:20:59 ada/spark get into space like the sparcv8 leon cpu 09:27:39 more worried about the 24year old ping bug/openbsd fuzzing found other day 09:28:28 https://news.ycombinator.com/item?id=33937 09:28:36 https://tlakh.xyz/fuzzing-ping.html 10:56:00 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 10:56:48 When I start in-Smartos screen, I do not get that warning. May be it is pkgsrc bug for screen package? 10:58:07 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 10:59:20 pkgsrc screen uses ncurses whereas the platform screen uses native curses, so it'll just be a difference in behaviour between the two 11:00:05 would be interesting to know exactly what ncurses thinks is lacking 11:01:07 what's your $TERM inside screen? I only get the warning if I switch to something else like rxvt 11:01:27 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. 11:01:55 If anything I can test, you can pvt me jperkin so I can test whatever you would me like to. 11:05:02 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 11:05:25 (I have to use -c as I always ship a .screenrc which explicitly has 'term xterm' in it) 11:07:12 although there is a terminfo entry for it at /opt/tools/share/lib/terminfo/s/screen.xterm-256color 11:11:07 oh, of course, man(1) will be using native curses, and there's no entry for that TERM 11:11:45 so, yeh, just ensure TERM is set to something that works with native 11:11:57 /opt/tools/bin/screen -c /dev/null seems like a workaround for now 11:12:57 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 11:15:13 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. 11:17:32 I de-installed 'screen' package in GZ and re-installed it and now problem is gone in one of VMs. 11:19:00 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 11:21:58 Ah sorry, I forgot to test it with ' man zpool 'Still the same after screen package reinstall. Disregard that. 11:24:38 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 11:26:41 'man zpool' , hit Ctrl+C , Hit Return and get: root@sm2 ~ $ root@sm2 ~ $ root@sm2 ~ $ root@sm2 ~ $ root@sm2 :) 11:26:59 And I think bug is multiplatform :P 11:27:37 Just on Linux/Ubuntu one can't exit 'man' with Ctrl+C :P 11:28:26 seems reasonable, best to avoid ^C if you can, especially when 'q' is quicker ;) 11:28:59 But there is 'nslookup' from where one can exit with Ctrl+C and get no propmpt echo anymore. Sounds like Bash bug or something? 11:29:54 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 11:29:58 And on Smartos nslookup + Ctrl+C does not have a problem :P 11:30:38 ^C should be a last resort, and there should always be an expectation of data loss and/or corruption somewhere 11:40:04 jperkin, depending if one grown up using MS-DOS or not, those ones expect everything to break :P 11:47:34 I grew up on Amiga, the expectation there is everything is amazing until you get a Guru Meditation fault ;) 12:01:14 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. 12:02:17 Of course, Internet was on Linux diskless X-windows strating from 1995/6 12:02:44 Sorry, for offtopic. 12:08:43 Amiga actually had a debugger over serial line in ROM.. for Guru meditation situations.. not that I have been using it ever.. 14:09:43 hi, everyone! how are the things? 18:35:47 this zpool is like an advanced persistent threat i'm having to completely format the drive to get a fresh installation going 18:37:03 for next time, is there an easier way to tell the smartos boot media to ignore a zpool? 18:44:40 try dropping to the bootloader prompt and `set noimport=true` before booting 19:09:07 jbk: thanks added to my notes for next time. 19:11:34 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 19:23:17 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. 19:23:33 Basically sdc-factoryreset does: `zfs set smartdc:factoryreset=yes ${SYS_ZPOOL}/var` 19:30:37 danmcd: also added thanks 19:36:56 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.