Re: [9fans] How to PXE boot with "two" DHCP servers on one network
Marco Feichtinger writes: > How can I pxe boot other machines, without my file server acting as dhcp se= > rver for the whole network? It might be possible, but not worth the effort. And with the blackbox DHCP server in that router, it's likely impossible. If your file server is up all the time, just make it the DHCP server for the network. --lyndon -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T47150b930c3726bd-M66e55b39ec1885bbc552f3f8 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Plan 9 Foundation is a 501(c)(3)
This is great news, but just before I start throwing money your way, it would be nice to know what you're planning to do with it. Other than the announcements about the creation of the foundation itself, and now this, it as been pretty much radio silence about what you're planning to get up to. Also, what's the difference between plan9foundation.org and p9f.org? --lyndon -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T2aea913cd8721bea-M79d4c3156be4c671d81a1951 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] 9p.io down?
Yaroslav K writes: > Do we know what=E2=80=99s up with 9p.io, the current sources host? Pings (v4 and 6) to nearby addresses work, so it looks like the host itself is down. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T1250ef82fbb8d6ed-Mbf332bb9fb0f83f30583f883 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans]
Thaddeus Woskowiak writes: > Has anyone written any code to deal with SCPI, Standard Commands for > Programmable Instruments, on plan 9? I did a couple of years ago, for the same reason: programmable PSUs and to suck data down from an ocsilloscope. It never worked well, and I have since lost the SD card the code was on (I was using an RPi). I would be interested in pursuing this, though, as I have a growing stack of SCPI-aware test gear. --lyndon -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Td89e32ced039912e-M38b28f4cce675b359623c480 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] different users for different system roles
hiro writes: > > should each system role get his own user? > > Like one user for file servers, one for auth, one for venti, and one for = > cpu > > servers. My was has always been to have a file system user and an auth server user that are used ONLY for those roles. As for CPU servers, it really depends on how you use them. The main reason you might want to have different CPU server owners is to control access to physical hardware. E.g. I have machines that are used to control my radios via their serial and USB interfaces. For those, I don't want the "general pupulation" to have access to that hardware, so I run those servers under a userid that is distinct from the "general purpose" CPU server owner. Oh, the Pi I use for bluetooth dev work has its own host owner, for similar reasons. I'm sure there are other cases, but that's the only one where I've personally had a need for multiple host owners. --lyndon -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T690e4304847a34e4-Md4c6b5c3652a1888a1f863c4 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Update on RISC-V port
Waaay back in Nov 2020 Skip sent a note to the list about some preliminary work on a RISC-V port. Now that my VisionFive-2 dev board has arrived I'm itching to try to get Plan9 running on it. Has any progress been made since that last update? https://www.kickstarter.com/projects/starfive/visionfive-2 --lyndon -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tbe8c3c69c87794db-M330021ff354696dd4fe2bbe2 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
[9fans] man.cat-v.org tls cert
Duckduckgo isn't happy with the above site's tls cert. Did it expire? Or is something more nefarious happening ... -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T2e78a247283470f3-Mbf8b7ba6235d7be1557ceb04 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Perhaps someone can give me an advice ...
ibrahim via 9fans writes: > While on wait I'm intending to port the freebsd bluetooth stack (netgraph) = > to plan9. I would be surprised if no one started such a project till now so= > if someone shares this goal I would be interested in a cooperative work.=20 Huh. I'd never thought about looking at that ng code as the basis for a port. I wouldn't have thought it's even close to being a natural port, but my netgraph experience is rather limited ... Bluetooth (and BLE) support woould be *very* nice to have. It would be really slick to get my Moolitpass MiniBLE working with factotum. This has been on my todo list for a while now, using USB to connect. I need to do USB anyway to support the older versions of the authenticator hardware. --lyndon -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tdd262593f40f8018-M632ad53f8b0181d6cbd89e8e Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] 9P in Forth
Alex Musolino writes: > Seems so: https://github.com/iru-/9p4 Oh now that's slick! < 200 lines of code. Thanks for the pointer. --lyndon -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T83ca5eda689bd9be-Mc8db77714169537811f62f52 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] building blocks speaking 9p
A short update on the RS-485 network project ... I ordered up an assortment of RS-485 "hats" and USB serial ports to play with. I also have an Axxon LF1006KB PCIe card that will go into the CPU server as the "gateway" for the 485 network. It should already work with the uartpci driver, but I'll have to extend that to add support for the 485-specific card functions. Fortunately Axxon has been very forthcoming with documentation for the card, so this should be pretty straight forward. I decided to take this week off work so I could free up some cycles to get myself orgainized enough to start on this ;-) I need a week just to dig out from under the mess that my apartment has become during lockdown! Mostly I need to (re-)construct a proper Plan 9 environment to base all of this on, so most of this week is dedicated to building CPU and file servers, etc. But just maybe, by the weekend, I'll have a couple of Plan 9 devices chatting over the RS-485 link. --lyndon -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Ta4e584a373b05553-M6753c1dbc56119369a0cc01a Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
[9fans] 9P in Forth
Just curious if anyone has attempted a 9P implementation in Forth? This could be fun to play around with on things like Atmel AVRs. I've had it to -->here<-- with the Arduino programming environment, so *anything* different would be a joy :-) --lyndon -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T83ca5eda689bd9be-M1239873b63f2d2acc6150554 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
[9fans] Installing 9legacy
I booted 9legacy from a usb image and all is well. But ... how am I supposed to get this installed on the machine's hard drive? I can't find any sign of the installer scripts. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tf6db73ba3285a82d-M6728aa5b39eca33f817a6b04 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] 9legacy under OpenBSD's vmm
When you do the initial install, interrupt the boot sequence and type console=0 as the documentation describes. Install the system as usual, then reboot and log in again using the consoole=0 dance. Once you're logged in you can mount the 9fat partition (9fs 9fat) and then edit /n/9fat/plan9.ini to add the console=0 line. The best way to deal with the vm console interface is to mark the vm as 'disabled' in vm.conf and then start it manually with 'vmctl -c start'. This will get you connected to the bios console early enough for you to interrupt the boot process to type those overrides. Once you have plan9.ini tuned to your satisfaction you can change the vm declaration to 'enabled' and let it autoboot. --lyndon -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Te13afbfe31e87665-M2db8c26d4737e829f7ec39c0 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] building blocks speaking 9p
A few thoughts after chewing on this for a day ... I think the major architecture components break down like this: 1) a simple protocol wrapper to enable streaming of 9p over arbitrary transports (e.g. USB, i2c, spi, rs485). 2) an addressing scheme that plugs into dial() and ndb. 3) authentication proxies. 4) device libraries. I think (4) is out of scope for the current discussion, so I won't talk about it further. (1) is the key to the whole thing. We need a consistent way to expose these 9p streams in the kernel in a mount-friendly way. I think the netif/ether kernel framework provides a good starting point, where netif hides (or at least abstracts) the device-specific quirks of the underlying physical medium (e.g. X-Base-T, wifi). In the current case, the netif replacement layer would hide the transport-specific warts of the physical tranport medium (e.g. USB, spi, serial uart). Where it gets interesting is how we address the individual components. E.g. at the "device" layer we need to address specific end-points, such as USB device endpoints, or an i2c chip addresses (for both the i2c driver chip, and the device on its i2c bus we want to talk to). Then above that we should have a way to address the generic 9p stream. Or maybe not -- implementation experience will show if this is required. This naturally leads into (2). (3) gets tricky. Devices not directly connected to a TCP transport can't speak with the auth service. Two ideas come to mind. The upstream "gateway" host could export a namespace that provides just enough to allow the device to chat with the auth service; I haven't thought about how this would work. Another option would be to have the "gateway" provide an auth server relay service that would be part of the 9p streaming encapsulation layer -- basically a 9p bent-pipe proxy to the auth service, listening at a well known "address" within the encapsulation layer. I've been thinking about doing something like this for ages, specifically, to allow me to control a stack of radio transceivers via a collection of controllers wired up to a multidrop RS485 bus. So last night I bit the bullet and ordered up a stack of RS485 interfaces of various shapes and flavours for my collection of Pies, Arduinos, and PCs, with a couple of USB adapters thrown in for good measure :-) When they get here I'll get to work on implementing the RS485 bus layer, and see where it all goes from there. --lyndon -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T18287f976e8461f3-M89dba67665ed6ae12c21e8b4 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
[9fans] aiju boards
> The 9front /sys/src/9/zynq port is aiju board's kernel. This reminds me to ask ... what did people get up to using their aiju boards for? Sadly, mine has been sitting on the shelf collecting dust for much too long. I did some early fiddling about, mostly to learn the fpga toolchain, but then real life got in the way of playing. When I bought the board I had intended to use it for some SDR receiver applications I was thinking about: AIS, ADS-B, DRM, etc. I really should do something about that. --lyndon -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Taa49c8d083b69cc5-M3bba113188df97d72f1f9820 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] building blocks speaking 9p
da...@boddie.org.uk writes: > I am using 5a/tc/tl to build bare metal code for a STM32F405 MCU thanks > to some hints from Charles Forsyth. Could you post some notes on how you're doing that? This is something I'd like to take for a spin. --lyndon -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Ta4e584a373b05553-Mec6e5bd345ad735a072a6cc7 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] building blocks speaking 9p
Bakul Shah writes: > - make it very easy to create hardware gadgets by > providing a firmware/hardware building block that > talks 9p on the host interface side & interfaces > with device specific hardware. Amen! I've been thinking about something like this for years. My specific use case involves controlling radio transceivers. Right now I do this with assorted Arduino hardware that speaks GPIO and RS232 (mostly) to the radios, and RS232 to the upstream "controller" host. This burns through a lot of serial ports on the controller. What I would prefer is to have all those Arduinos connected to an RS485 multidrop, each exporting a 9p filesystem for the control interface. Shoveling the data around on the RS485 "bus" just needs a simple frame wrapped around the 9p packets that provides device addressing and a CRC. On the Plan9 side this just becomes another network type, with ndb handling the device addressing. As others have mentioned, having a native Atmel C compiler would be a real boon here, but there's no reason why this couldn't be done with an Arduino 9P library. I haven't investigated if such a thing exists, although I'm sure it does. --lyndon -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Ta4e584a373b05553-M7e3fd4de0f3c256df6dbd436 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] 9legacy under OpenBSD's vmm
David du Colombier writes: > If it works with 9front, the issue is definitely on our side. > Our Virtio drivers are very close to 9front's, so I suspect > the issue may be somewhere else. If you think that's the case then I need to build out enough local infrastructure to be able to build 9legacy ISOs. Then I can start printfing in the kernel to see if I can track this down. That might take a while, though, as I'm quite hardware constrained right now (thus the attempt at the vmm-based VM). --lyndom -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Te13afbfe31e87665-M0efd869d756a7a4e1bb8945c Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] 9legacy under OpenBSD's vmm
David du Colombier writes: > I think the issue is elsewhere, since I've tried on QEMU with > both Virtio 1.0 and Virtio legacy and it worked as expected > (386 and amd64 kernels). That could very well be. vmm(4) is still relatively young, so the bug could very well be there. I think at this point we've ruled out the 9legacy kernel as the culprit. --lyndom -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Te13afbfe31e87665-Me20a6318a72ff59e0e01703d Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] 9legacy under OpenBSD's vmm
It gets a bit further -- now it actually panics :-P : lyndon@orthanc:/u/vm; vmctl start -c clare Connected to /dev/ttyp2 (speed 115200) Boot failed: not a bootable disk PBSR... F5CD 00B2 Plan 9 from Bell Labsi8042: kbdinit failed no vga; serial console only disk loader cpu0: 5200MHz GenuineIntel Core i7 (cpuid: AX 0x206A1 DX 0x79BA97F) ELCR: 02E8 497M memory: 497M kernel data, 0M user, 18M swap panic: no disks (in #S) panic: no disks (in #S) dumpstack ktrace /kernel/path 80018529 81004b10
Re: [9fans] 9legacy under OpenBSD's vmm
David du Colombier writes: > I've just imported Virtio 1.0 support to 9legacy. > Lyndon, please try the latest CD image and let me know if it works for you. Hah! You beat me to it ;-) ISO downloading now, stay tuned ... -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Te13afbfe31e87665-M400da8e1482489f6e7c74e9c Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
[9fans] 9legacy under OpenBSD's vmm
Are any of you running 9legacy under the vmm hypervisor on OpenBSD? The kernel boots, but complains that it cannot find any fixed disks and panics. I was able to boot 9front, so it looks like 9legacy's virtio drivers might be lagging a bit? --lyndon -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Te13afbfe31e87665-M70c9221f3a817d77039678ed Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Alternative to fine-grained mouse usage?
Dworkin Muller writes: > I have physical issues with trying to perform fine-grained mouse > operations (uncontrollable small hand tremors). [ ... ] > So, my question is, are there any viable alternatives for use with Joining the conversation late ... sorry. Have you thought about mounting a server on top of the mouse device that reads the raw positioning data and passes up a running average of the last n positions? Basically, interpose a low pass filter to help remove some of the jitter. I have no idea if it will work -- it just leapt to mind as I sit here breadboarding RC audio filters ;-) --lyndon -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T716c5aa0e2aa8a27-Mf23265176eb945efe8e0fc8b Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] SFF 9legacy fileserver hardware
Steve Simon writes: > until last year I still had a dual Atom machine which worked nicely but > is a propper desktop machine even though its a mini ITX. I have at least a half dozen mini-ITX boards lying around that I can fall back on. The problem is I seem to have lost most of the cases and/or power supplies for them. Push comes to shove though and I will use one of them if I have to. There's quite a mix ranging from old i386s to a fairly recent and kick-ass 64 bit board that would make a very nice CPU server. Maybe I should just go on a hunt for replacement cases. The problem last time around was that mini-ITX cases were no longer very "mini" ... --lyndon -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T055ff8c5321ac6a2-M0f04537551518aecfb3633b8 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] SFF 9legacy fileserver hardware
kokam...@hera.eonet.ne.jp writes: > For the usb issue, amd64(9legacy) does not support usb mouse/keyboard, > only ps2 keyboard/mouse. Is there any such machine having PS/2 > interface around? Pretty much everything supports BIOS mapping from USB->PS/2. This is one of the many reasons I was asking for reports only from people who are ACTUALLY RUNNING THE CONFIGURATION THEY ARE TALKING ABOUT. --lyndon -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T055ff8c5321ac6a2-Mf56869e6c40feaac879638b0 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] SFF 9legacy fileserver hardware
hiro writes: > sure you want just one sata disk for a fileserver? or is the worm all on bl= > uray? One disk is fine for now. The blu-ray is for backing up the arenas, and yes, I'll deal with the xhci driver issues myself. (I can use slower USB ports until I get that part running.) --lyndon -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T055ff8c5321ac6a2-Mb3102df67c15f1260cfc5c38 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
[9fans] SFF 9legacy fileserver hardware
Time to build out some proper infrastructure at home, and the first order of business is the file+auth server. I don't need screaming fast performance, just something basic, and I have been looking at some of the current crop of small form factor desktops, along the lines of the Intel NUC. (But I'm in no way married to Intel.) I'm curious in hearing from anybody ACTUALLY RUNNING on that sort of machine. The spec's I'm looking for are pretty minimal: * amd64 arch. * a gig-E port I can saturate. * SATA-II SSD disk (2.5 inch is fine), preferably that will max out the SATA interface. PCIe/m.2/whatever is okay, as long as it works with the 9legacy kernel, but remember this is a file server, so I want to be able to pack a fair number of bytes into it, making $$$ an issue for non-SATA storage. * >= 16GB RAM. * 2 x USB1/2 (for kbd/mouse), USB-3 for external blu-ray writer. * basic bitmap video (VGA/VESA is fine). Thanks for any feedback you can give! --lyndon -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T055ff8c5321ac6a2-M94ac21243973cdb00139f06f Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] APL
tlaronde pointed me at the APL that shipped in the contrib directory in 4.3BSD. In hindsight I suspect that was the version I spun up at Athabasca U way back when (1989ish). I was quite surprised to see that a substantial chunk of it managed to compile 'out of the box' on OpenBSD 6.8 (albeit with a flood of warnings :-)): : lyndon@broken:/u/lyndon/src/apl/4.3/usr/contrib/apl/src; ls *.[co] Llx.ca4.c a8.o ac.o ag.c ak.c ao.o ax.c gamma.c a0.c a5.c a9.c ad.c ag.o al.c aplcvt.c ax.o lex.c a1.c a6.c aa.c ae.c ah.c am.c aq.c ay.c tab.c a2.c a7.c aa.o ae.o ai.c an.c at.c az.c xed.c a3.c a7.o ab.c af.c aj.c an.o at.o az.o y.tab.c a3.o a8.c ac.c af.o aj.o ao.c aw.c cata.c y.tab.o Seems like a viable candidate to base the port on. --lyndon -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T233ff29f045d64a9-Mb2cc2b7e0f346fbbd83e53dd Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] APL
o...@eigenstate.org writes: > git clone --single-branch \ > --branch Research-V4-Snapshot-Development \ I must be blind. I completely glossed over 'single-branch'. But I might have to go back to the SCCS archive on the CDs, anyway, since Spinellis' repo doesn't seem to have preserved the actual SCCS commit messages, just the fact they happened. > On plan 9, hot off the press: > git/clone -b $branch \ I don't have the native git installed yet. This might be enough to prod me into it. Thanks! --lyndon -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T476a1d7b83269775-Mec7fc82154006da06aee1e82 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] APL
Steffen Nurpmeso writes: > It can even be as small as > > #?0|kent:unix-hist$ du -sh . > 179M. > > when not including all the new FreeBSD things (for which i at > least track the FreeBSD git repository directly): Okay, so what's the magic incantation to clone just that subset of branches? git-clone(1) is not helpful ... --lyndon -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T476a1d7b83269775-Mdd3b46b53bcc065bccf7b218 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] APL
tlaro...@polynum.com writes: > There are various versions of an APL interpreter and, amongst these, > a version by Ken Thompson, Ross Harvey, Douglas Lanam. > > Is that this one you are looking for? That sounds like the one. It's entirely possible the version I started with came from one of the BSD tapes (we were source licensed so we had the full set of tapes from V6 onwards). I have the CSRG CD set, but it's in a box in a storage locker right now. Is there any chance you could pull the above APL source files and leave them someplace I could grab them from? (9p.io would work fine.) Thanks! --lyndon -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T476a1d7b83269775-M1bad1e99ac35796f23d98c47 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
[9fans] APL
Long ago and far away I built/ran Thompson's APL (from the V7 source tape IIRC) on one of the VAXen. This was very much pre-ANSI C code, but the Ultrix 1.1 compiler handled it fine. About 15 years ago I dusted off the source and started converting it to ANSI C, but I got distracted and have since lost the source. Has anyone here done anything similar. I would really like to have a native APL (even an ancient one like above). If anyone did get it converted to ANSI, a native port could be bootstrapped through APE. Failing that, does anybody have a copy of the original source kicking around? Since the virus is going to keep me locked up for a few more months yet, porting would help pass the time :-) --lyndon P.S. Yes I know there are a million other APLs out there, as well as J and the assorted follow-ons. It's the V7 code I'm specifically interested in. Maybe it's tucked away in the bitsaver archives ... -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T476a1d7b83269775-Md699c49a884f9c671dd08404 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] authoritative source for u9fs?
Charles Forsyth writes: > it's also on bitbucket not github mainly for historical reasons but I also > can never decide which I dislike more. :-) The nice thing about having it in hg is that mercurial is part of 9front, so there's no need to muck about getting git installed. --lyndon -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tee2220301f2a891c-Mfba96c69e2d6c1b21c1a81d4 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
[9fans] news(1) patch: make -a and -n get along
[ Originally send to 9front-bugs, but this is applicable
across the board ... ]
This patch makes 'news -an' do the right thing.
/n/dump/2021/0122/sys/src/cmd/news.c:44,65 - news.c:44,72
void
main(int argc, char *argv[])
{
- int i;
+ int i, aflag = 0, nflag = 0;
+ int doupdate = 1;
+ int printall = 0;
+ void (*printer)(char*) = print_item;
Binit(, 1, OWRITE);
if(argc == 1) {
- eachitem(print_item, 0, 1);
+ eachitem(print_item, printall, doupdate);
exits(0);
}
ARGBEGIN{
case 'a': /* print all */
- eachitem(print_item, 1, 0);
+ doupdate = 0;
+ printall = 1;
+ // eachitem(print_item, 1, 0);
break;
case 'n': /* names only */
- eachitem(note, 0, 0);
- if(n_items)
- Bputc(, '\n');
+ doupdate = 0;
+ printer = note;
+ // eachitem(note, 0, 0);
+ // if(n_items)
+ // Bputc(, '\n');
break;
default:
/n/dump/2021/0122/sys/src/cmd/news.c:66,73 - news.c:73,87
fprint(2, "news: bad option %c\n", ARGC());
exits("usage");
}ARGEND
- for(i=0; ihttps://9fans.topicbox.com/groups/9fans/Td990983e87321183-M486341df8c5b1a9191d4c728
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
[9fans] Re: [9front] dropped emails
hiro writes: > only found out by accident, Not sure what's going on. I sent a couple of messages to 9front and 9front-bugs yesterday that vanished into a black hole ... --lyndon -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T75f937755279e2c1-Me40aee945910e9d382aed65f Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
[9fans] rfc / internet-draft viewer
I cleaned up my RFC/I-D viewer and mirroring tools and pushed them up to /n/9pio/contrib/lyndon/rfc.tar. They're a bit more functional than the existing /lib/rfc/grabrfc, and interface nicely with the plumber. Note that I have an /rc/bin/aux directory that I 'bind -a' to /bin/aux in my global namespace. If you don't want to do that binding you'll have to fiddle the mkfile a bit. Otherwise, add 'bind -a /rc/bin/aux /bin/aux' to /lib/namespace to make the mirror commands visible. RFC(1) RFC(1) NAME rfc, idmirror, rfcmirror - Display RFCs and Internet Drafts SYNOPSIS rfc [-p] docref rfc [-p] -dIis aux/idmirror [-v] aux/rfcmirror [-v] DESCRIPTION rfc displays IETF RFCs and Internet Drafts. docref is a plain integer in the case of RFCs, or a string of the form draft-* for Internet Drafts. rfc can also display indexes of drafts, RFCs, and STDs by specifying one of the following flags: -d display the Internet Drafts index -I display the index of recent RFCs -i display the unabridged RFC index -s display the list of STDs rfc invokes B to display the document; specifying -p instead prints the document on the standard output. idmirror and rfcmirror maintain the local mirrors of the IETF document repositories. The -v flag makes them print the names of documents added or removed from the local mir- ror. Only the text versions of the documents are mirrored. rfcmirror also puts a copy of the recent-RFCs index into /lib/news/latest_rfcs for use by news(1). Plumbing Adding the following to $home/lib/plumbing (ahead of the include basic line) makes RFC and Internet Draft references plumbable: type is text data matches '[Rr][Ff][Cc][ ]*([0-9]+)(.[Tt][Xx][Tt])?' plumb start rfc $1 type is text data matches '(draft-[a-z0-9-]+-[0-9]+)(.txt)?' plumb start rfc $1 FILES /lib/doc/ietf the local document mirror. BUGS The internet drafts FTP server (ftp.ietf.org) has an absurdly short command channel timeout. If you have a slow network connection this can cause idmirror to fail, report- ing an ftpfs rpc error. The problem is with the IETF's FTP server, not idmirror. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Td6498de610f4eaa9-M47ba54071b9de1bbb3f787fa Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] plan9port: acme remoting
I've always just used aan(8) + cfs(4) for this sort of situation. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T5addc17a0e19cd91-Mb3f8fff0efe927f263afe55f Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Plan9 and Pine
Don't forget 2ed ran on the ipaq (aka bitsy). How much of the UI support survived the 2ed -> 3ed rewrites I don't know. But reading through the 2ed source might be enlightening. --lyndon -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tca918503d5b19459-M84e06c5124325f4f5953a196 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
[9fans] factotum vs. SASL+TLS+applications
The following is all hypothetical. I'm curious about how people think auth(2)/factotum(4) could be adapted to support the use case ... factotum was intended to handle the authentication dance on behalf of network apps. But in the case of things like IMAP, it really just stores the client's login/password, and provides a bit of helper glue for CRAM-MD5. Similarly for ftpfs. I'm curious why upasfs and ftpfs are outliers in only using factotum as a credential store, but leaving the actual authentication protocol dance in the clients/servers. The "Security" paper (/sys/doc/auth) strongly hints that these parts of the application protocols were meant to be outsourced to factotum. Section 2.2 in particular argues that the auth modules should be implemented once in factotum, for consumption by the rest of the system. Beyond the layering issue, how upasfs does IMAP authentication has always bugged me. The "/imaps/..." path handles the "native TLS on port 993" case, but upasfs(4) says "... Authentication is delegated to factotum(4)" which is mostly a lie in the "/imap/..." case. Given a connection to port 143, upasfs will negotiate a simple cleartext login, while blithely ignoring the server's advertised security policy. Specifically, it ignores the LOGINDISABLED and STARTTLS capability advertisments, and there's no way to require STARTTLS, even in the absence of the capability (e.g. work around MITM downgrade attacks). And the supported SASL mechanisms are woefully out of date. Obviously none of this is factotum's fault. But getting this right is a bit tricky, which strongly argues for implementing this, once and correctly, in a single location. I've looked at pushing this into factotum before. The current big fail is the flat 'proto=XXX' part of the factotum key namespace. This doesn't scale with SASL. E.g. for some protocol 'imap' we end up with: proto=imap Plain old IMAP LOGIN (and SASL PLAIN) proto=imap-cram-md5 SASL CRAM-MD5 proto=imap-scram-md5SASL SCRAM-MD5 [...] plus all the '+tls' variants. And yet it's going to be the same passphrase underlying all of these. In theory there should only be one factotum entry for each IMAP server/userid instance; it should not be necessary to update your sectore just because the server's authentication scheme has changed. And there's no reason at all to duplicate factotum records just to handle the '+tls' variants of each of the above. What this really needs is for factotum to gain knowledge of SASL as a general mechanism, apart from any specific application protocol. Then there needs to be a mapping between the application protocol being authenticated and the underlying SASL mechanism drivers. The challenge then becomes how to express this mapping in the factotum records. As an example, let's consider an IMAP (port 143) server. The default policy should be to use TLS if the server advertises it (STARTTLS), and select the strongest compatible SASL mechanism the server supports (based on re-issuing CAPABILITY after STARTTLS, and honouring LOGINDISABLED). This would have a key lookup like: proto=imap user=lyndon server=orthanc.ca !password=notlikely To require a successful STARTTLS even if the capability is not advertised, add "tls=required" to the record. To require a specific SASL mechanism, add "sasl=scram-md5" (using "sasl=*" as a default if you need to fall back for some reason). Of course all of this needs to be glued into auth(2) in a way that doesn't destroy the existing API. But it does need to handle factotum replacing the underlying connection to the client/server with one that has been pushtls()ed by factotum itself. --lyndon -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T8154f8e7b95f1a8c-M10a72106b236119ee526b90a Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
[9fans] fix: plan9port FreeBSD arm64
This gets github.com/9fans/plan9port building under FreeBSD 12.1 on arm64. Dunno if it breaks the other arm64 platforms ... diff --git a/dist/buildmk b/dist/buildmk index 07b223ac..65137556 100755 --- a/dist/buildmk +++ b/dist/buildmk @@ -7,6 +7,7 @@ OBJTYPE=`(uname -m -p 2>/dev/null || uname -m) | sed ' s;.*i86pc.*;386;; s;.*amd64.*;x86_64;; s;.*x86_64.*;x86_64;; + s;.*arm64.*;arm64;; s;.*armv.*;arm;g; s;.*powerpc.*;power;g; s;.*PowerMacintosh.*;power;g; -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T131571e9f91f8dc0-M82e6a808f27686d236210f72 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
[9fans] Forcing display size on Pi4
I have a 2K display that Plan9 forces to 1920x1080 resolution. Poking around 9/bcm/screen.c indicates that setting vgasize=WxHxD should force the size, but adding a suitable entry in cmdline.txt just gives me a blank display. Before I dig deeper, is this expected to work? If it is I'll start adding some kernel prints and try to find out what's not working. --lyndon -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T83b43600a3d592d7-M1247efe1a8bc99c51b34f4b3 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
[9fans] dc(1) exponent limits
While running some silly benchmarks I discovered dc's '^' operator
limits exponents to ''. This seems arbitrary, perhaps a leftover
safety measure to keep things from eating all the CPU for days on
end on a slow machine? I upped the limit to 9 and the test
expression ran fine on a Pi4:
/n/dump/2019/1215.2/sys/src/cmd/dc.c:328,334 - dc.c:328,334
neg++;
chsign(arg1);
}
- if(length(arg1)>=3) {
+ if(length(arg1)>=4) {
error("exp too big\n");
}
savk = sunputc(arg2);
If you're feeling bored and apply the above patch, consider running
this mini-bench and mailing the output directly to me:
echo -n `{cat /dev/cputype}^' ** ' ; echo 652342 52342 '^' 34232342 / p q |
time dc >/dev/null
It will take a while to run (50 minutes on the Pi4).
--lyndon
--
9fans: 9fans
Permalink:
https://9fans.topicbox.com/groups/9fans/Te871fd8fbfd16f42-M7982246eb4b86450cf74cc30
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
[9fans] Ottawa Spring 2020
BSDCan is June 3-6 2020. There's a Postgres conference the week before at the same venue, so I'll be in Ottawa from May 25 to June 12 (taking some vacation time after BSDCan). If anyone wants to do an informal get-together, let's see what we can work out. --lyndon -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T565e07f732f7d831-Mc7adde16399ed323ef7761d6 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Request for (constructive?) comments: Plan 9 : 2020
For BSDCan I say "unofficial" specifically because an "official" BOF as part of BSDCan would require conference registration. An "unofficial" BOF would be off-site (we can just meet at the usual pub) the day after the conference ends. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tec7c18239f2d234f-M4fb1cbc4bc664c7d654faa4f Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Request for (constructive?) comments: Plan 9 : 2020
Lyndon Nerenberg writes: > Maybe an unofficial get together around BSDCan in Montreal next spring? Doh! BSDCan is in Ottawa, not Montreal. The suggestion still stands. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T2e674653159c4ce8-M66c79e8a0bf65c38eea52dba Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Request for (constructive?) comments: Plan 9 : 2020
Chris McGee writes: > I am unlikely to be able to come unless it is north eastern US or Canada, > maybe Toronto or Montreal. I know of at least one other Plan 9 tinkerer in > the area. Maybe an unofficial get together around BSDCan in Montreal next spring? The Saturday after the conference ends? I know a couple of likely conference participants who would be interested. --lyndon -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T2e674653159c4ce8-M18fd808a344931cc4daa2c0e Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Request for (constructive?) comments: Plan 9 : 2020
> In that vein, here's a poll: https://www.surveymonkey.com/r/VJNQYGC The survey seems more cute than useful. E.g. there's a *big* difference between "travel a couple of hours" and "anywhere." And even though it's close by, I wouldn't consider travel to the US (a couple of hours) due to the insanity involved in getting through US immigration, whereas I would consider travel to Europe (~9 hours). Asia would be out, due to travel time and cost. But as a general gauge of initial interest it's certainly useful. Sadly, while I'd love to go, 2020 doesn't look like a year where I'll be doing much travelling :-( But I would be willing to kick in some $$$ to help pay to have the event streamed. --lyndon -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T2e674653159c4ce8-M60892b128dd63cea3a17f1ae Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] go under plan9 on the radpberry pi?
Matthew Veety writes: > Building anything on a raspberry pi is a bit of a chore. I highly=20 > recommend running go on your cpu server and/or local to your filesystem.=20 > The generated binaries seem to work fine. Go does wonderfully when it comes to generating binaries for non-native architectures. I have a few Go-based tools I use at work that I build on any number of archictures (macos, freebsd, openbsd, linux / armX, i386, amd64)) that I need to run on one or many of the above. They all just work. Makes debugging a breeze. But now that they are succumbing to the shared lib/obj doctrine, I'm sure I will soon go back to writing C code, since the advantage of those static go binaries is about to be lost :-(
Re: [9fans] printing from Plan 9
Richard Miller writes: > Before replacing my expiring inkjet printer I thought I'd ask > the list: does anyone still use lp(1) nowadays, and are there > printers currently on the market which work well with Plan 9? As others have mentioned, life is far too short for CUPS. For Plan9 printing I have always just used a laser printer that natively supports Postscript. You pay a bit more for Postscript, but that pays for itself immediately in not having to dick around with CUPS, gs, or gawd knows what else to get the hardware talking to whatever system you've plugged it into. I currently have an HP Laserjet M402dn. It speaks Postscript 3, prints up to 40 PPM, supports duplex printing, and talks lpd or "virtual serial port" on port 9100. CAD$350 from Staples. I've never had any trouble making these consumer HP Postscript printers interface with lp(1). I configure them as an lpd printer, and then point all the other hosts on the network at the Plan9 CPU server as their default 'printer'. This lets me use the lp(1) content conversion filters on all the other hosts -- I find lp's behaviour to be far superior to anything that MacOS and the others provide. If you really need an inkjet (e.g. for colour), I would still recommend finding something that natively supports Postscript. Failing that, you're likely going to have to connect the inkjet to something like a Mac or a Linux host. But as long as you can configure the print host to listen on the lpd port and handle incoming Postscript jobs correctly, you should just be able to configure it as a networked Postscript printer. --lyndon
[9fans] getcallerpc for arm64/FreeBSD (plan9ports)
Does anyone have a getcallerpc-arm64 that works with FreeBSD on a Pi 3?
Re: [9fans] Plan 9 C compiler for Xtensa CPUs
Charles Forsyth writes: > At a glance it looked as though the MMUs for the on-chip stuff were more > suitable for Unix Seventh Edition (no later) than "full" Plan 9. Wouldn't Inferno be a better fit for these sort of devices? In my experience these things are used primarily as I/O devices, with most of the CPU cycles going towards reducing/normalizing/marshalling the data in and out. Nothing I've ever built out of an ESP*, Feather, Teensy, etc., would benefit from a full-on Plan9 kernel. But having a fully-integrated 9P+auth stack would make these microcontrollers a dream to integrate into a Plan9 environment. --lyndon
Re: [9fans] Anyone have a Plan 9 4th Edition Manual Set...
michaelian ennis writes: > I found a second edition set on Abe books last year. They were not > inexpensive. Sadly, Abebooks became utterly useless several years ago, when it was taken over by bots scraping each other listings and adding 5%.
[9fans] tn3270
Just curious if anyone has ported (or written) a tn3270 client? --lyndon
[9fans] supported modern laptops
It's time for a new laptop, one that will dual boot OpenBSD and 9front. Looking through the FQA, the hardware listed there is a wee bit on the dated side. I'm curious to here peoples experiences running on more current gear. My requirements aren't too esoteric. I need something that will take *lots* of RAM (I'll be running several VMs under OpenBSD), has a DVD writer, and has a 9front-supported wifi NIC. 9front audio support would be nice, but lack of it is no big deal. Oh, and lots of USB-A ports, if that's even possible on modern hardware any more :-P Thanks! --lyndon
[9fans] 9front installer misses /lib/news directory
fussy# hg diff sys/lib/sysconfig/proto/distproto diff -r 3839b70da66a sys/lib/sysconfig/proto/distproto --- a/sys/lib/sysconfig/proto/distproto Mon Apr 22 03:05:51 2019 +0200 +++ b/sys/lib/sysconfig/proto/distproto Mon Apr 22 18:11:54 2019 -0700 @@ -32,6 +32,7 @@ ndb d775 * dhcpd775 + news d775 rfc d775 grabrfc sky d775
Re: [9fans] The lost (9front) boot menus ...
> I object to quadrupling the timeout. I am old and my eyesight sucks and > one second is perfectly sane. Shut the refrigerator door! You're running up long distance charges!!!
Re: [9fans] The lost (9front) boot menus ...
cinap_len...@felloff.net writes: > err... thats precisely how it works. the ONLY difference is that the > timeout is hardcoded to ONE second see: /sys/src/boot/pc/sub.c:304 Fine, but a ONE second timeout is insane. And it's NOT at all clearly documented in the 9boot(8) manpage. How about a FOUR second timeout, and some manpage patches?
Re: [9fans] The lost (9front) boot menus ...
> err... thats precisely how it works. the ONLY difference is that the > timeout is hardcoded to ONE second see: /sys/src/boot/pc/sub.c:304 ONE second, eh? I need to become much younger again ;-)
Re: [9fans] The lost (9front) boot menus ...
cinap_len...@felloff.net writes: > the bootloader has a console where you can change any > plan9.ini parameter, including bootfile=. read 9boot(8). I described this badly. Let me try again. Given a working fileserver config, I want something that does 'user=foo; nobootpromt=bar', but with a (say) five second timeout. This is different from the current scheme that provides an escape, but which requires manual intervention. What I'm looking for is a timed-out option from the 'nobootprompt=' config, that lets me override, but only if I'm right there. It's the same as how (e.g. FreeBSD) lets you interrupt the boot process and muck about. But if you don't, it times out and boots the 'default' configuration.
[9fans] The lost (9front) boot menus ...
Something I miss in 9front is the 'boot menu' functionality 9labs had in plan9.ini. Being able to fall back to an alternative config was a godsend when debugging fileserver setups. I'm curious why that was removed from the 9front bootstrap code. --lyndon
[9fans] 9front dhcpd installer buglet
The 9front installer doesn't create the /lib/ndb/dhcp directory. This makes ip/dhcpd silently fail when it tries to hand out dynamic addresses.
Re: [9fans] ssh oddities (9front)
Ignore me. I had stupid firewall rules in place that were breaking things :-P
[9fans] ssh oddities (9front)
Something else I've noticed is that 9front-dick-tracy refuses to ssh to FreeBSD 11 or MacOS 10.14 hosts when trying password authentication. In both cases, 'ssh -d' reports the connection hangs up at 'ssh: global request: hostkeys-000.openssh.com'. I don't know if this worked before. This is my first build-out of 9front infrastructure, so I'm not sure what's expected to work. Especially after the recent updates to the 9front SSH code. --lyndon
Re: [9fans] SMC SYS-5018A-FTN4 lapic weirdness (9front)
cinap_len...@felloff.net writes: > bit 7 is "illegal register access". try to print the pc from the ureg > passed to the first argument in lapicerror() in /sys/src/9/pc/apic.c. A quick printf hack says ureg->pc = 0x801103b3 mostly (>99.9%), but a few other oddballs are: cpu0 0x2400c8 cpu0 0x226df6 cpu0 0x80208b1c cpu0 0x802083f9 etc. During boot I see complaints from cpu1, but once the machine is fully booted only cpu0 spits messages. This is from a generic Dick Tracy amd64 kernel, with a U->pc printf added to lapicerror(). --lyndon
Re: [9fans] SMC SYS-5018A-FTN4 lapic weirdness (9front)
cinap_len...@felloff.net writes: > bit 7 is "illegal register access". try to print the pc from the ureg > passed to the first argument in lapicerror() in /sys/src/9/pc/apic.c. Okay. Likely not 'til the weekend though ...
[9fans] SMC SYS-5018A-FTN4 lapic weirdness (9front)
I have a stack of Supermicro SYS-5018A-FTN4 servers upon which I'm trying to spin up 9front. For the most part they work, but one annoyance is the *endless* stream of cpu0: lapicerror: 0x0080 messages the kernel prints out. Sometimes these originate from cpu1 as well. The hardware has eight CPU cores. I don't think I've seen anything from cpu>1, but in the blizzard of messages, who knows. I poked a wee bit inside the kernel source, but I don't have time right now to chase this. The hardware runs fine, other than refusing to reboot, which I put down to the usual BIOS ACPI table stupidity. For the time being I'm going to put a filter on the kprints, but I'm curious if this sounds familiar to anyone. Note this happens with both the 32- and 64-bit kernels. I don't have a quick way to attach sysinfo(1) to this message, but if somebody can use that I'll figure something out. --lyndon
Re: [9fans] Mirroring plan9 sources
clue...@tonymendoza.us writes: > or and setup a mirror, but finding servers spec'd to run plan9 in > the US seems impossible. I have run 9front on VPSes at ARP Networks. These days 9front should just work out of the box. ARP's support staff have been very helpful tuning the underlying qemu/kvm settings for me when I have needed that, and they don't shy away from helping run "oddball" OSes like Plan 9. --lyndon
Re: [9fans] microsoft's plan 9 distribution
Ethan Gardener writes: > I got excited for a moment, but then I saw, "This server contains > protocols that support Linux metadata, including permissions." It's > going to be 9p2000.L or yet another incompatible fork of the protocol. Is Upspin an alternative? (Not helpful if you're required to talk to specific AFS infrastructure.) --lyndon
Re: [9fans] MH port
Mayuresh Kathe writes: > just so that i know, are you targeting plan9 users for your version > of 'mh'? if yes, will they be interested in migrating away from the > way they are working currently, i.e. with acme and upas? Yes, and no. Yes, in that I intend this MH to fully integrate with the Plan9 environment (upas, plumber, factotum) when run there. That will come with time. The first step is to get the existing code building and running, with a very basic inc(1) interface that pulls from the user's inbox (just like with UNIX). No, in that there will never be a "one true MUA" any more than there is *any* "one true X" for any value of X. On Plan9[1] I am constantly moving back and forth between nedmail, acme Mail, and a basket full of my own programs, depending on the task at hand. The upas filesystem interface makes the latter a breeze to implement. MH is just another nugget in that basket of tools. --lyndon [1] Not just Plan9. On UNIX systems I can't keep count of the number of MUAs, MSAs, and the like I use, and almost always in parallel. Again, which tool I use is dictated by what I'm trying to accomplish at the moment.
[9fans] MH port
Mayuresh Kathe writes: > i was looking for a non-captive user-interface email client like "mh" by > rand corporation. i guess i'll either have to learn to use acme with > upas or write my own "mh" replacement for plan 9. A year-or-so ago I started working on my own version of MH, forked from a then current nmh. One of the goals for the version I'm doing is to have a native (as much as is possible) Plan9 build; one that gets along with upasfs and the plumber as much as possible. So far most of the work has been cleaning up the code base. E.g. ripping out all the GNU auto* build nonsense, and getting the code to compile cleanly in a pure ANSI C environment. Once that's finished it should be relatively straight forward to add basic APE build support. This is a couple of months out yet, based on my current rate of progress :-( --lyndon
Re: [9fans] Plan 9 C compiler for RISC-V by Richard Miller
Brian L. Stuart writes: > Don't laugh. I actually have a VT-220 on my file server. You do a lot of manual code compiling and linking from the serial console of your file server, do you? Then you deserve all the pain that can possibly be inflicted upon you ;-) --lyndon
Re: [9fans] PDP11 (Was: Re: what heavy negativity!)
Digby R.S. Tarvin writes: > Oh yes, I read Eldon Halls book on that quite a few years ago. Meetings > held to discuss competing potential uses for a word of memory that had > become free. > That one would be a challenging Plan9 port.. And yet Plan9 was not there to save the day. Such a pity.
Re: [9fans] zero copy & 9p (was Re: PDP11 (Was: Re: what heavy negativity!)
Another case to ponder ... We're handling the incoming I/Q data stream, but need to fan that out to many downstream consumers. If we already read the data into a page, then flip it to the first consumer, is there a benefit to adding a reference counter to that read-only page and leaving the page live until the counter expires? Hiro clamours for benchmarks. I agree. Some basic searches I've done don't show anyone trying this out with P9 (and publishing their results). Anybody have hints/references to prior work? --lyndon
Re: [9fans] PDP11 (Was: Re: what heavy negativity!)
hiro writes: > don't you need sending ability, too for AIS? No, a receive-only setup is very useful on a small boat. Where I would like to go with this is to take the decoded AIS data as input for "ARPA" style collision plots. I'm interested in the big boats sailing through the straight. They can't turn fast, and rarely change course. If I can derive their intentions, I can plot a path between them that requires the least amount of tacking. The big boats, in turn, have no interest in us little critters. They actively filter out the "class B" (I think that's the term) noise that are AIS transmissions from the small craft. Even if we hit them, we can't sink them, so they don't care about us. Therefore there is no incentive for small boats to transmit AIS. Unless you're trying to locate your buddies for a tie-up somewhere. (That can be a very valid reason for transmitting!) --lyndon
Re: [9fans] PDP11 (Was: Re: what heavy negativity!)
Skip Tavakkolian writes: > I assumed you were using an RTL2832U (rtlsdr library). I'm pretty sure they all do, under the hood.
Re: [9fans] PDP11 (Was: Re: what heavy negativity!)
> I was able to use dump1090 (same author as redis) to get ADSB data reliably > on RPi/Linux a while back. I have a pair of Flightbox ADS-B receivers I am using as references. While mostly reliable, they can and do stutter along with the rest of the alternatives on occasion. --lyndon
Re: [9fans] PDP11 (Was: Re: what heavy negativity!)
hiro writes: > But given the alternatives available back then, even the armv5 in the > kirkwood, which was cheaper even before the rpi became popular, did > the same job more stably, which is why i would never actually > recommend the pi. And there are even more alternatives now. I get that. But the actual hardware driving this conversation isn't particularly relevant,, and devolving to a hardware bikeshed isn't helpful. (Not picking on you specifically.) > Are you doing the AIS demodulation on plan9 on rpi? It would be a > great showcase. Wish I had been given the opportunity to find an > excuse to build something like that on plan9 instead :) Not yet. First I need to prove it can be done with the usual suspects (GNU radio, on the Pi -- the native fft libraries seem fast enought to make this viable). If the pessimized case works, then porting the code from the GNU radio python modules to C is a mechanical process for the most part. This week I am ENOTIME with getting the boat tarped up in preparation for the winter monsoon season :-P. --lyndon
Re: [9fans] PDP11 (Was: Re: what heavy negativity!)
Digby R.S. Tarvin writes: > Agreed, but the PDP11/70 was not constrained to 64KB memory either. > I do recall the MS-DOS small/large/medium etc models that used the > segmentation in various ways to mitigate the limitations of being a 16 bit > computer. Similar techniques were possible on the PDP11, for example Coincidental to this conversation, I'm currently reading "The Apollo Guidance Computer: Architecture and Operation" by _Framk O'Brien_. (ISBN 978-1-4419-0876-6) Very interesting to see what you can do with a 15 bit architecture when sufficiently motivated. --lyndon
Re: [9fans] PDP11 (Was: Re: what heavy negativity!)
> I have been able to copy 1 GiB/s to userspace from an nvme device. I should > think a radio should be no problem. The problem is when you have multiple decoder blocks implemented as individual processes (i.e. the GNU radio model). Once you have everything debugged, you can put it into a single threaded process and eliminate the copy overhead. But it's completely impractical to prototype or debug real applications this way. And it's the prototyping case I'm interested in here. So I'm *curious* to know if page flipping a 'protocol buffer' like object between processes provides an optimization over copying through the kernel. Not so much for the speed aspect, but to free up CPU cycles that can be devoted to actual SDR work. Since when did curiosity become a capital crime? Oh, wait, that was January 20, 2017. My bad. --lyndon
Re: [9fans] PDP11 (Was: Re: what heavy negativity!)
hiro writes: > Does this include demodulation on the pi? Yes. At least to a certain extent. The idea is to get from the high-birate I/Q data so something more amenable to transmission over an RS-422 (or -485) serial drop. One example is for an AIS transceiver on a boat. By putting the radio and decoder at the top of the mast, the backhaul can be a cat-3 twisted pair cable, rather than a much heavier coax run from the antenna at the top of the mast to the receiver below decks. Reducing the weight at the top of the mast reduces the moment arm acting on the boat, significantly enhancing the stability of a sailboat (which is how I got started down this road to begin with). --lyndon
Re: [9fans] PDP11 (Was: Re: what heavy negativity!)
cinap_len...@felloff.net writes: > why? the *HOST CONTROLLER* schedules the data transfers. I *DON'T KNOW*. It's just observed behaviour. > a! we'r talking about some crappy raspi here... probably with all > caches disabled... never mind. Hah. An Rpi tips over with 1200 baud USB serial. I was talking about "real" (Intel :-P) hardware for the other tippy-over behaviour. --lyndon
Re: [9fans] PDP11 (Was: Re: what heavy negativity!)
cinap_len...@felloff.net writes: > > The big one is USB. disk/radio->kernel->user-space-usbd->kernel->applicati > on. > > Four copies. > > that sounds wrong. > > usbd is not involved in the data transfer. You're right, I was wrong about 'usbd'. In the bits of testing I've done with this, 'usbd' is replaces with a user space file server that abstracts the hardware and presents a useful file system interface. (E.g. along the lines of the gps filesystem interface.) To address Hiro's comments, I have no benchmarks on Plan 9, because the SDR code I run does not exist there. But I do have experience with running SDR on Linux and FreeBSD with hardware like the HackRF One. That hardware can easily saturate a USB2 interface/driver on both of those operating systems. Given my experience with USB on Plan 9 to date, it's a safe bet that all the variants would die when presented with that amount of traffic. (I can knock down a Plan9 system with 56 Kb/s USB serial traffic.) I can see about twisting up some code that would read the raw I/Q data from the SDR via USB and see how it stands up. But the real question is what kind of delay, latency, and jitter will there be, getting that raw I/Q data from the USB interface up to the consuming application? Eliminating as much of the copy in/out WRT the kernel cannot but help, especially when you're doing SDR decoding near the radios using low-powered compute hardware (think Pies and the like). --lyndon
Re: [9fans] PDP11 (Was: Re: what heavy negativity!)
hiro writes: > from what i see in linux people have been more than just exploring it, > they've gone absolutely nuts. it makes everything complex, not just > the fast path. And those are the Linux folks doing thier thing. The reading I'm doing right now is related to the pessimizations page flipping throws at the CPU caches. It looks scary ... --lyndon
Re: [9fans] PDP11 (Was: Re: what heavy negativity!)
Bakul Shah writes: And funny you should mention this! > Some of this process/memory management can be delegated to > user code as well. At $DAYJOB we would really like to have application process control over the kernel scheduler, as this seems to be the only realistic way to avoid the (kernel) resource starvation issues we run into. Our back end servers don't go down often. But when they do, it's for reasons entirely out of our control. Because those resource allocation policies have been pushed into the kernel, and beyond our control. --lyndon
Re: [9fans] PDP11 (Was: Re: what heavy negativity!)
hiro writes: > > Dealing with the security issues isn't trivial > what security issues? Passing protocol buffer like objects around user space, that might affect how the kernel talks to hardware. E.g. IPsec offload into hardware. You don't want user-space messing with that sort of context, but you want to tag it with the data buffer as it gets passed up and down through the user/kernel gate. Practical page flipping needs a kernel-read-only context attached to the non-kernel user data part of the page. A quick solution is to pair pages, one half of which the kernel owns, the other being the data payload. But that't just a start. And that's all I'm saying: this might be an approach to a better/faster I/O paradigm, but it needs interested people to explore it ... --lyndon
Re: [9fans] PDP11 (Was: Re: what heavy negativity!)
hiro writes: > Huh? What exactly do you mean? Can you describe the scenario and the > measurements you made? The big one is USB. disk/radio->kernel->user-space-usbd->kernel->application. Four copies. I would like to start playing with software defined radio on Plan 9, but that amount of data copying is going to put a lot of pressure on the kernel to keep up. UNIX/Linux suffers the same copy bloat, and it's having trouble keeping up, too. --lyndon
Re: [9fans] PDP11 (Was: Re: what heavy negativity!)
Bakul Shah writes: > One thing I have mused about is recasting plan9 as a > microkernel and pushing out a lot of its kernel code into user > mode code. It is already half way there -- it is basically a > mux for 9p calls, low level device drivers, VM support & some > process related code. Somewhat related to this ... after reading some papers on TCP-in-user-space implementations, I've been thinking about how an interface that supported fast/secure page flipping between the kernel and process address space would change how we do things. E.g. right now Plan 9 suffers from a *lot* of data copying between the kernel and processes, and between processes themselves. If we could eliminate most of that copying, things would get a lot faster. Dealing with the security issues isn't trivial, but the programmer time going into eeking out the last bit of I/O throughput of the current scheme could be redirected. If it works, this would reduce the kernel back to handling process/memory management, and talking to the hardware. Not a micro-kernel, but just as good from a practical standpoint. And no, this wouldn't get us to running on the 11/70. But by taking advantage of modern large virtual memory spaces by using page flipping, we could cut down on physical memory usage in the kernel. --lyndon
Re: [9fans] APL for Plan 9?
Ethan Gardener writes: > Is there an implementation of APL or a related language for Plan 9? For pure APL, I don't think so. Long ago I ran the Thompson APL interpreter on our Ultrix VAX. It was built from source, but I forget which tape it came from. It would have been one of V7 or 4.2BSD, methinks. I built it in the first place to write code to analyze/report performance stats on our VAXen vs. the swaths of 3B2 and 3B4000 hardware that AT was trying to foist on us at the time :-) Once or twice I have toyed with the idea of getting it running on Plan9. But the C source is very pre-ANSI, and as I recall there are many embedded assumptions about everything being 32-bits wide, pointers and ints are interchangeable, *0 == 0, etc. Still, it would be a fun project, and I would love to have a native APL to play with again. --lyndon
[9fans] booting plan9 under bhyve
Has anyone has managed to boot any of the plan9 variants under FreeBSD's bhyve hypervisor? Just curious to hear about any success/fail experiences. --lyndon
[9fans] fossil+venti vs. cwfs - dealing with backups
What has kept me running fossil+venti is the ease of backing up the file server. Copying the venti arenas offsite is trivial. And Geoff put together glue to write sealed arenas to blu-ray as well. I don't see any simple way to do that with cwfs*. Or hjfs. I am very curious to know how the not-fossil/venti FS servers are backing up. Share? --lyndon
[9fans] SCMs
I struggle to understand how version control is not more actively used. It's not particularly necessary when you have global state with snapshots provided by a shared WORM fs. I always thought that argument was a bit suspect. And with the loss of sources.bell-labs.com, it's apparent why. The only revision history was in the venti. Now that that is lost, so is that history. I know that there are partial mirrors of sources, but none go all the way back to the dawn of the sources venti archive. And on the mirrors, we lose the 'blame' functionality fossil provided by tracking who last updated a file. If this had been hosted in an SCM, it would have been so simple to replicate that full history elsewhere. The other bit that snapshots/dumps miss is context. When everyone working on the code was within shouting distance of the "unix room" that wasn't an issue. But now, that context has been lost. Annotations about the "why" of a commit are as important as the "what." diffy(1) answers the "what," but not the "why." DVCS adds a lot of complexity for questionable gain, in that environment. 9front's adoption of mercurial is a historical accident rather than a desired outcome. But, I understand that most people just want to use the tools they already know. It's much easier than learning a new paradigm. +100 on DVCS and needless complexity. cvs or sccs provides all the functionality I've ever needed in an SCM system. Although I confess I have been seduced by git's ability to instantly create and switch between branches. It makes trying out "what if" scenarios completely painless. But it's not enough to convince me to use git except on very rare occasions. --lyndon
Re: [9fans] ReMarkable!
Maybe it's not impossible that someone would come up with a way to input text using a pen over a screen that's even more efficient and convenient than a keyboard. So far, such technology just doesn't exist. Dust off the handwriting code that was done for the bitsy.
Re: [9fans] There is no fork
Forsyth's Plan-9k had some development in mid 2017. Where did that go? I remember there were some changes there I was quite interested in, but I lost the reference to the repo source before I had a chance to do anything with the updates.
Re: [9fans] RasPi why?
RPi's aren't "the" answer, Exactly. There is no "one" answer. Hardware, peripherals, operating systems ... The "linux is everything" crowd is what's leading to the decimation of technological advancement these days.
Re: [9fans] RasPi why?
Why do people even buy RasPis? 1) Serial port console servers. A Pi2 + StarTech USB 8-port serial is an inexpensive way to talk to console serial ports on routers, switches, firewalls, etc. 2) DHCP/TFTP servers used to remote PXE install the big iron in our data centres. 3) Interconnecting all the NMEA nav/comm gear on the boat. 4) Sensor monitoring on the boat (battery levels, bilge, tank levels) and sending alarms. Etc.
[9fans] SMART: Silly Marketing Acronym, Rebuts Truth
The interesting thing (for me) was that the SMART data from the drive gave it an all clear right to the end. But unlike the SSDs, there was plenty of behavioural warning to remind me to have the backups up to date and a spare at the ready... FWIW, of the three-four dozen or so drives I have actively SMART monitored over the years, of the ones that failed, *not* *one* gave a SMART warning before dying. That includes a spinny disk in one of my Mac Minis. Of anyone, I would expect Apple to be in bed with their HD suppliers enough to have HD firmware that reliably reports SMART errors (since the disk utilities do pay attemtion to it). I spent a month listening to that drive's heads slam back to the home position as it tried to recalibrate itself, before eventually dying. To the bitter end, SMART reported "a-ok boss!" --lyndon
Re: [9fans] RPI faq in words of one syllable?
I wrote up a crib sheet covering exactly this a couple of months ago, but it was on a VPS server whose filesystem I thoroughly trashed and is now pushing up the daisies. I will dig around and see if I stashed a copy on another machine. If not, I can re-create it easily enough, but not for a week or two due to insanity at $WORK. --lyndon
Re: [9fans] R.I.P cs.bell-labs.com
Ouch. I'd hate to think the work I did on that is somehow associated with 9front. Let's leave the pettiness behind.
Re: [9fans] R.I.P cs.bell-labs.com
Yes, when sources was doomed, I enthusiastically set it up, although I think it was bitbucket not github, And the reason I liked the bitbucket repo is because it's accessible using hg, for which we have a Plan9 port that does get some TLC thanks to the 9front folks.
Re: [9fans] R.I.P cs.bell-labs.com
Everyone is naming sites to check out, but which one has the right contents, is being maintained, and will be stable? Didn't Charles Forsyth have a github or similar such repository with a copy of the Labs sources? That was even seeing sporadic updates? I'm sure I browsed it last fall, but I can't find it now.
