Re: [9fans] Moving files to a USB thumb drive.
On Sat, Aug 03, 2024 at 03:49:36PM -0700, Lyndon Nerenberg (VE7TFX/VE6BBM) wrote: > jas.smoke via 9fans writes: > > > I want to copy text files from a Windows PC to a Plan 9 computer using a US= > > B thumb drive.=C2=A0 > > Format the thumb drive as a FAT32 filesystem and stick the files > there. On the plan9 side, see dossrv(4) and examine /bin/c: for > an example of what to do. You'll need to adjust the device path > to match the usb device location. > > https://plan9.io/magic/man2html/4/dossrv I think most systems have a script called usbfat: that looks for a FAT partition on a USB storage device and mounts it on /n/usb. BLS -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T4f67493d8e7306fc-Mf8ed0ba770e56ea9b66fde12 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] cmdline.txt for RPi 4 with QHD screen
I wouldn't call it obvious. :) It looks like there's at least a difference in where the firmware blobs are kept. I don't really know how much difference there is in the driver code, but I would expect that there would be a file in /sys/src/9/bcm that is analogous to ether4330.c. But I'll have to leave it to others who are more knoledgable about the 9front internals to follow up with more details. In the absence of a more definitive direction, I'd grep the source files in /sys/src/9/bcm for the string 4345. As a hex number, that is the chip ID for the 802.11 interface on the 4s. The revision number on the original 4s was 6, but the revision on my 400 is 9. In the 9legacy version that I use, the different IDs are listed in an array of structures: struct { int chipid; int chiprev; char *fwfile; char *cfgfile; char *regufile; } firmware[] = { { 0x4330, 3, "fw_bcm40183b1.bin", config40183, 0 }, { 0x4330, 4, "fw_bcm40183b2.bin", config40183, 0 }, { 43362, 0, "fw_bcm40181a0.bin", config40181, 0 }, { 43362, 1, "fw_bcm40181a2.bin", config40181, 0 }, { 43430, 1, "brcmfmac43430-sdio.bin", "brcmfmac43430-sdio.txt", 0 }, { 43430, 2, "brcmfmac43436-sdio.bin", "brcmfmac43436-sdio.txt", "brcmfmac43436-sdio.clm_blob" }, { 0x4345, 6, "brcmfmac43455-sdio.bin", "brcmfmac43455-sdio.txt", "brcmfmac43455-sdio.clm_blob" }, { 0x4345, 9, "brcmfmac43456-sdio.bin", "brcmfmac43456-sdio.txt", "brcmfmac43456-sdio.clm_blob" }, }; The code then runs through the array comparing the ID and rev read from the controller. When it finds a match, it sends over the various blobs. The code that looks for the blobs in the 9legacy driver is: if(!waserror()){ snprint(nbuf, sizeof nbuf, "/boot/%s", file); c = namec(nbuf, Aopen, OREAD, 0); poperror(); }else if(!waserror()){ snprint(nbuf, sizeof nbuf, "/sys/lib/firmware/%s", file); c = namec(nbuf, Aopen, OREAD, 0); poperror(); If it's the same in 9front, then the blobs you have might be /boot which would be necessary if you were going to take the root from a file server over wifi. I don't ever run mine that way, so it's more convenient for me to put them in /sys/lib/firmware. As before, I'll need to leave it to a 9front expert to point out any of my suppositions that are wrong. Sorry for the delay. I took a couple of hours out to take advantage of a break in the clouds here to test my setup for the eclipse on Monday. And btw, the computer I'll have there will be my 400 running Plan 9 with the file system I'll be talking about at IWP9 next weekend. BLS On Saturday, April 6, 2024 at 07:15:16 AM UTC, taylor.ga...@gmail.com wrote: Hi Brian, Thanks for your help, does it make a difference that I'm using 9front? I don't even seem to have a /sys/lib/firmware directory, and I'm not sure I have a ether4330.c either. I'm sure it's obvious, but I'm a newcomer to Plan 9 and I apologise in advance if I'm missing obvious things. Thanks Garry9fans / 9fans / seediscussions +participants +delivery optionsPermalink -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T42a55b55ffb81417-M21bff740cfc3be6ecf936bdb Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] cmdline.txt for RPi 4 with QHD screen
I haven't had any trouble with wifi on the 4, with one caveat. The 400 (and maybe some of the later 4s) have an updated version of the radio. It just takes a new entry in ether4330.c and new blobs in /sys/lib/firmware. The entry I've got in my ether4330.c is: { 0x4345, 9, "brcmfmac43456-sdio.bin", "brcmfmac43456-sdio.txt", "brcmfmac43456-sdio.clm_blob" }, and the files named there are the ones I added to /sys/lib/firmware. BLS On Saturday, April 6, 2024 at 01:33:46 AM UTC, wrote: That's great, now I just need to get wifi to work... I can't get a definitive answer on RPi 4 wifi is even supported.9fans / 9fans / seediscussions +participants +delivery optionsPermalink -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T42a55b55ffb81417-M5332574c9fdef8908ac6b551 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
[9fans] IWP9 Update
Some of you may have noticed that the original deadline for the camera-readycopy of papers and the WiP reports is today. The committee has decidedto extend that deadline by one week. So anyone for whom the edits haveslid to the back burner, you've got a reprieve. After the new deadline onthe 20th, we'll work on putting the online proceedings together. Thanks,BLS -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T6f56828c4f9d22bd-Mfea55b6d44f429aff88ba6b0 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
[9fans] IWP9 Hotels
A week ago I sent out a request for interest in a hotel room block at $200/night. I got exactly one response saying that's what AirBNB is for. Unless I hear differently by sometime tomorrow, I'll interpret the lack of response as indicating that everyone has or is planning to make their own arrangements and that I should tell them to cancel the request and release the rooms. Thanks, BLS -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tdb8ab372e27e1518-M4a796a93e9171e0a318c24e6 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
[9fans] IWP9 Housing
The housing situation for IWP9 this year in Philadelphia is not ideal. It seems there's a big volleyball tournament in town at the same time, so many hotels have little availability and they're able to charge high rates. However, we have had one that has said they can reserve a block of rooms for us at $200/night. That is the Club Quarters hotel. While it's not super close to campus, it's close enough to the subway that you won't need to plan on lots of Uber. As is commonly the case, we'll have to guarantee at least 80% of the number of rooms we have them reserve to be occupied. We also need to get the block reserved pretty soon as I don't know how long they'll be able to hold some openings for us. So I'd like to get a headcount of how many rooms we're likely to use. Send me a reply and let me know if you are likely to reserve a room in the block at Club Quarters at the $200 rate. Thanks, BLS -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T1e48f24607670833-M8fbb2ba70c0e032152275f60 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
[9fans] IWP9 10th Edition
The Plan 9 Foundation and the Workshop Program Committee are pleased to invite participation in the 10th International Workshop on Plan 9. This event will take place April 12-14, 2024 on the campus of Drexel University in Philadelphia. We invite submission of papers, works in progress (WiPs), and workshop proposals. Everyone interested in Plan 9 and related technologies is encouraged to attend. To assist in your planning, a few key dates include: January 30, 2024: Submission Deadline March 10, 2024: Preferred Registration Deadline (later registrations will be accepted) April 12-14, 2024: The Workshop We will be following up with details on hotels. For complete details, see the Call for Papers at: https://www.cs.drexel.edu/~bls96/iwp9_2024_cfp.pdf A special note on scheduling: the workshop falls on the weekend following the upcoming total solar eclipse on April 8, 2024. Although we will not have totality in Philadelphia, the path of totality is reachable from Philadelphia in less than a day's driving time. So take advantage of the scheduling to experience both one of nature's most amazing events and discussions of computing's most amazing operating system. Brian L. Stuart IWP9 Program Committee -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tfe83e4e703ab52ec-M6f703d0608c259fe194a198d Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Re: Fun with sshsession
On Thu, Dec 08, 2022 at 06:06:21PM -0600, Steven Stallion wrote: > > I found another interesting wrinkle. It appears this issue seems to > > only affect diskless CPU servers. I'm able to SSH successfully to my > > auth and file servers. > > Mystery solved! It turns out this was the same issue Cinap fixed in > auth/as last year. sshsession was inheriting the host owner factotum > after capuse, which was leading to breakage on hosts other than the > file server. Steve, I'm glad to hear you got it sorted out. Now that our fall term is over, I can come up for air. But I didn't have much to add to your search anyway. About the only thing I've done with it since Geoff's clean-up was recently adding some new key exchange algorithms since OpenSSH no longer supports the original required KEX algorithms out of the box. The server side of things was always a little goofy. It does carry the fingerprints of being developed to allow customers to ssh into appliances that didn't share an auth server. I never got around to doing much aimed at making it natural for non-Plan 9 clients to log into a full Plan 9 environment with ssh. There never seemed to be a lot of motivation because drawterm seemed to provide a better interface. The main exception would be using sam -r from a non-Plan 9 system. In the end, it ended up being a perfect example of an implementation influenced by lots of "here's something cool that could be done with it" ideas. But then pretty much none of the cool capabilities ever got used. I do still use the client functionality a lot from a Pi 400 running a slightly enhanced copy of Richard's Pi image in the classroom talking to my BSD laptop and the department's Linux cluster. Not that any of that is relevant to the issue you ran into, but it might help provide a little context to anyone wondering how and why that implementation works the way it does. BLS -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Ta343100f1654631e-Md53baf982ecb1d9255d61ee1 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Raspberry Pi400 Ethernet
On Friday, May 28, 2021, 3:12:26 PM EDT, Steve Simon wrote: > sadly i have had problems with usb3 which is on > my todo list - usb2 devices work fine as do usb3 > devices in usb2 sockets. I'll definitely keep that in mind. I haven't been trying to use any USB3 devices, but who know what'll happen. BLS -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T8d2c30e280421e20-M3246d8de0bd9d31f1c12bbac Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Raspberry Pi400 Ethernet
I'll check on that. Though in this case, I was booting from the SD card and then running ipconfig by hand to get an address. BLS On Friday, May 28, 2021, 4:11:04 PM EDT, Skip Tavakkolian wrote: might be this (from the diffs gist i posted earlier): case ODtftpserver: /* RPi4s request it for no-SD netbooting without hardcoding TFTP_IP in EEPROM */ On Fri, May 28, 2021 at 12:13 PM Brian L. Stuart wrote: > > On Friday, May 28, 2021, 2:52:35 PM EDT, Richard Miller <9f...@hamnavoe.com> > wrote: > >> The really odd part is I just moved the SD card over > >> from a pi3 that was booting fine with dhcp. > > > > Does the MAC address in the dhcp request look right? > > It does. I'm at a loss to explain it, but I ended up rebooting > my auth/dhcp server and now everything is working. > > False alarm, I guess. > > Thanks, > BLS -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T8d2c30e280421e20-M59de3a6995dc4de76608d14f Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Raspberry Pi400 Ethernet
On Friday, May 28, 2021, 2:52:35 PM EDT, Richard Miller <9f...@hamnavoe.com> wrote: >> The really odd part is I just moved the SD card over >> from a pi3 that was booting fine with dhcp. > > Does the MAC address in the dhcp request look right? It does. I'm at a loss to explain it, but I ended up rebooting my auth/dhcp server and now everything is working. False alarm, I guess. Thanks, BLS -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T8d2c30e280421e20-M0975e43cb2c172ae2a9dc63c Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Raspberry Pi400 Ethernet
I'm inclined to think you're on the right track with a dhcp problem. It seems to be working fine if I set the address manually on the command line. The really odd part is I just moved the SD card over from a pi3 that was booting fine with dhcp. I'll keep digging. BLS On Friday, May 28, 2021, 2:28:16 PM EDT, Richard Miller <9f...@hamnavoe.com> wrote: I have no personal experience of the pi400 but I believe the ethernet hardware is identical to the pi4. Could it be a configuration problem? Can you run snoopy or equivalent on the network segment and see if the dhcp requests are being transmitted? And check the dhcp server log to see if there's a reason for non-response? Also you can try using ipconfig to set a specific ip address and gateway without using dhcp, to see if it's a dhcp problem or a more fundamental ethernet problem. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T8d2c30e280421e20-M9351afac61fe9f7850128c94 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
[9fans] Raspberry Pi400 Ethernet
So I picked up a pi400 and everything seems happy except the Ethernet. I'm using Richard's latest 9pi.img from 9p.io. At least, I'm pretty sure it's the latest; it does include the /dev/serial driver. The network switch is showing the hardware to be happy and I'm using a cable that has been working with a Pi3, but ipconf times out with a "no success with DHCP" error. Anyone have any wisdom that I'm overlooking? Also, Richard, I'm going to send you a bug fix for devspi soon. I discovered that attempting to acces spictl is broken. BLS -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T8d2c30e280421e20-M1cdfe9038b2b15321b2eff4d Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Jim McKie
I never got to know Jim, but I always respected his contributions. He will be sorely missed. RIP On Wednesday, June 24, 2020, 08:37:21 PM EDT, Charles Forsyth wrote: I am sorry to say that Jim McKie (jmk) died suddenly on 16 June. https://www.ippolitofuneralhomes.com/obituaries/James-B-McKie?obId=15111702&fbclid=IwAR3d7aHZXEOhYz-ciOrQPh-W1eMw-_8MHiCUdeKOxzLBEI6VGHsSn4aTjdk9fans / 9fans / seediscussions +participants +delivery optionsPermalink -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Td73b359f9dc68c15-Mbcf37e5c21c11335f5777929 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Plan9 on virtual machine in Mac os
On Wednesday, March 25, 2020, 02:02:40 PM EDT, Ethan Gardener wrote: > i still miss 9vx. it was so convenient when it > worked. fun too; i had it full-screened in a little > ... Was? I still use it everyday. It's my primary terminal. I have it take the root from my file server when I'm on my home network, and off a little local mini root when I'm not. BLS -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Ta7f245368d4d10b8-M0e5d29d3ab8739b0823f305b Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Raspberry Pi 2 GPIO
On Thursday, September 12, 2019, 5:43:13 AM EDT, Richard Miller <9f...@hamnavoe.com> wrote: > > Do you also need the man pages for i2c and > > spi, or did I send those the first time around? > > If you sent them, they must have gone astray ... if you can > supply a new copy, I'll add them to the image too. Thanks! Okay. I've appened at the end here both of them, i2c first. I think they're up to date, but it's been a while since I did much with them, and I can't vouch for how well my memory works as the years go by. BLS .TH I2C 3 .SH NAME i2c \- basic I2C interface .SH SYNOPSIS .B bind -a .BI #J n .B /dev .PP .BI /dev/i2c. n .ctl . br .BI /dev/i2c. n .data .fi .SH DESCRIPTION .I I2c serves a one-level directory with two files that give access to the target device with address .I n (given in hexadecimal) on the system's I2C bus. .I N is usually determined by the I2C device manufacturer. I2C gives address 0 special meaning as the `general call' address. See an I2C specification for details. .PP The control file .BI i2c. n .ctl accepts commands to set the valid address range and subaddressing mode for the corresponding data file. The following control messages can be written to it: .TP .B a10 Force 10-bit addressing instead of 7-bit addressing. Otherwise 10-bit addressing is used only if the device address .I n is bigger than 255. .TP .BI size " nbytes" .br Set the logical size of the target device to .IR nbytes . (By default when opened, it is 256 bytes, enough for most small I2C devices.) IO requests will be kept within this limit. This value is also returned by .B Sys->stat as the length of the data file. .TP .BI subaddress " \fR[\fP n \fR]\fP" .br Cause subsequent reads and writes on the data file to use I2C subaddressing with .I n byte subaddresses (default: 1 byte). .I N must be no larger than 4. The target device must support subaddressing. By default, the device is not subaddressed. Setting .I n to zero switches off subaddressing. .PP When read, the control file displays the current settings. .PP The data file .BI i2c. n .data can be read or written to exchange data with the slave device with address .I n (where .I n is given in hexadecimal). Each write request transmits the given data to the device. Each read request sends a receive request to the device and returns the resulting data. If the I2C target is subaddressed, the current file offset is used as the subaddress; otherwise the file offset is ignored, and the device typically starts at 0 for each transfer request. Read and write requests are trimmed to the declared size of the device. .SH SOURCE .B /sys/src/9/bcm/devi2c.c .br .B /sys/src/9/bcm/i2c.c .TH SPI 3 .SH NAME spi \- access to the main Raspberry Pi SPI interface .SH SYNOPSIS .B bind -a #π /dev .PP .B /dev/spictl .br .B /dev/spi0 .br .B /dev/spi1 .SH DESCRIPTION The Broadcom SoC on the Raspberry Pi has three SPI interfaces: the main SPI interface, designated SPI0, and two auxiliary SPI interfaces, designated SPI1 and SPI2. On the first generation Pis, only SPI0 was brought out to the header on the board. For the B+ and Pi2 models, SPI0 and SPI1 are available. The driver described in this man page only supports SPI0. .PP Reads and writes to the files .B spi0 and .B spi1 transfer data over the SPI bus. Accesses to .B spi0 cause the transfers to take place with the CE0\_0 line asserted low. Similarly, transfers to .B spi1 are carried out with CE1\_0 asserted low. .PP The .B spictl file is used to set various control parameters. It accepts the following commands: .TP .BI clock " freq" Set the frequency of the SPI clock. The clock from which the SPI clock is derived runs at 250MHz, and the Broadcom documentation specifies that the divisor must be a power of 2. The driver sets the divisor to the highest power of 2 that results in a clock rate that is less than or equal to the .I freq parameter in MHz. .TP .BI mode " n" Treats .I n as a two-bit number specifying the settings for the clock phase and clock polarity. The default value of 0 matches the polarity and phase requirements of most peripheral devices. .TP .B lossi Enable a bidirectional mode where the MOSI line is used for both reads and writes. .SH SOURCE .B /sys/src/9/bcm/devspi.c .br .B /sys/src/9/bcm/spi.c .SH BUGS The various SPI modes are untested and the LoSSI support is unimplemented.
Re: [9fans] Raspberry Pi 2 GPIO
On Tuesday, September 10, 2019, 12:21:32 PM EDT, Richard Miller <9f...@hamnavoe.com> wrote: > Thanks Brian, I'll add your man page to the 9pi image for the > next update. You're welcome. Do you also need the man pages for i2c and spi, or did I send those the first time around? Thanks, BLS
Re: [9fans] Raspberry Pi 2 GPIO
On Tuesday, September 10, 2019, 10:27:08 AM EDT, Олег Бахарев wrote: > Need man page for this. My bad. I thought I had sent man pages along with the code. I've included the man page for it at the bottom of this message. > Can you get some example for reading/writing GPIO ? I've also included a short example that uses both the GPIO and the SPI interface to talk to a little Nokia LCD screen. BLS .TH GPIO 3 .SH NAME gpio \- access to Raspberry Pi GPIO pins .SH SYNOPSIS .B bind -a #G /dev .PP .B /dev/gpio .fi .SH DESCRIPTION .I Gpio serves a single file that provides access to the GPIO pins on the Raspberry Pi. Reads from the file receive a 16-character hexadecimal string representing a .B vlong giving the values of up to 64 GPIO lines. (The processor on both the first and second generation Pis provides 54 actual GPIO lines.) The proper method for sampling GPIO 27 is as follows: .IP .B read(gfd, buf, 16); .br .B buf[16] = 0; .br .B gvals = strtoull(buf, nil, 16); .br .B "pin27 = gvals & (1 << 27);" .PP Writes to .B gpio control the characteristics and output values of GPIO lines. The exact operation is specified by one of the following commands: .TP .BI function " pin f" Set the function of GPIO .I pin to .I f. The valid values for .I f are: .BR in , .BR out , .BR alt0 , .BR alt1 , .BR alt2 , .BR alt3 , .BR alt4 , .BR atl5 , and .BR pulse . The functions .B in and .B out set the specified GPIO line to be a general purpose input and output, respectively. The various .BI alt n functions are as specified in the Broadcom documentation and differ on a per-pin basis. The .B pulse function is somewhat specialized. It causes the pin to be set to an output for 2μS and then to be set to a input. With the value of the line set to 0 and a pullup resistor on the line, this operation provides a short low pulse suitable for bit-banging a 1-wire interface. .TP .BI pullup " pin" Enables the internal pullup resistor for the specified GPIO pin. .TP .BI pulldown " pin" Enables the internal pulldown resistor for the specified GPIO pin. .TP .BI float " pin" Disables both internal pullup and pulldown resistors for the specified GPIO pin. .TP .BI set " pin value" For GPIO pins set to the output function, this command sets the output value for the pin. The .I value should be either 0 or 1. .SH NOTES All pin number references are according to the SoC documentation. These GPIO signal numbers do .I not match the pin numbers on the header on the Pi board. Reads sample the external signal values. As a result, the values read for output pins might not match the value written to them if externally they are driven harder than the SoC drives them. .SH SOURCE .B /sys/src/9/bcm/devgpio.c .br .B /sys/src/9/bcm/gpio.c #include #include void main() { int gfd, sfd, i, j; uchar buf[256]; gfd = open("/dev/gpio", ORDWR); sfd = open("/dev/spi0", ORDWR); if(gfd < 0 || sfd < 0) print("open error: %r\n"); fprint(gfd, "function 22 out"); fprint(gfd, "set 22 0"); sleep(1); fprint(gfd, "set 22 1"); fprint(gfd, "function 27 out"); fprint(gfd, "function 26 out"); fprint(gfd, "set 26 1"); sleep(10); fprint(gfd, "set 26 0"); fprint(gfd, "set 27 0"); sleep(1); buf[0] = 0x21; pwrite(sfd, buf, 1, 0); sleep(1); buf[0] = 0x14; pwrite(sfd, buf, 1, 0); sleep(1); buf[0] = 0xc0; pwrite(sfd, buf, 1, 0); sleep(1); buf[0] = 0x20; if(pwrite(sfd, buf, 1, 0) < 0) print("write error: %r\n"); sleep(1); buf[1] = 0x0c; if(pwrite(sfd, buf+1, 1, 0) < 0) print("write error: %r\n"); sleep(1); buf[2] = 0x40; if(pwrite(sfd, buf+2, 1, 0) < 0) print("write error: %r\n"); sleep(1); buf[3] = 0x80; if(pwrite(sfd, buf+3, 1, 0) < 0) print("write error: %r\n"); // pwrite(sfd, buf, 4, 0); fprint(gfd, "set 27 1"); for(j = 0; j < 256; ++j) { for(i = 0; i < 16; ++i) buf[i] = j ^ i; sleep(1); for(i = 0; i < 6 * 84 / 16; ++i) pwrite(sfd, buf, 16, 0); sleep(100); } fprint(gfd, "set 26 1"); }
Re: [9fans] Are there disadvantages to walk?
On Mon, 4/1/19, Ethan Gardener wrote: > I remember hearing of some disadvantage to > walking directories, but can't remember what it was. > Could someone remind me, please? Perhaps there was > more than one, of course. Perhaps a performance trick > couldn't be employed? The only complaint I've had about walk was the expectation in the protocol that servers produce the list of Qids all the way down. That got in the way when experimenting with a server that used a hash table of full path names to speed the walk process. BLS
Re: [9fans] Plan 9 C compiler for RISC-V by Richard Miller
On Tue, 10/30/18, Richard Miller <9f...@hamnavoe.com> wrote: > > Is there a technical reason (beside fonts that do not cover them) not > > to use a Unicode values for the first letter? > > They're a bit harder to produce on the keyboard. Especially if you're at a VT-220 on the console and can't run rio. Don't laugh. I actually have a VT-220 on my file server. BLS
Re: [9fans] what heavy negativity!
Fri, Oct 5, 2018 at 12:11 AM Mayuresh Kathe wrote: > man, i experienced such heavy negativity towards my efforts to build ... > > the idea was to have a 64-bit linux kernel with the advantages of > plan9port (small and elegantly designed+developed tools). Mayuresh, To echo what others have said, don't let the negativity itself affect your work. Consider only the technical points that have been raised. To the extent that you evaluate them and consider them relevant to your objectives, factor them into your work. It really doesn't matter if anyone else ever cares about or uses your work. If you learn from it, get intellectual satisfaction from it, and it's useful to you, then it's worth doing. If others can benefit too, great, but lack of interest on the part of others is not a good reason for lack of initiative on your part. As far as I can tell, I'm the only one using a file system I developed. Sure, in some ways I would like if everyone thought it was as great as I do, but just because they don't doesn't stop me from benefitting from it. As for the specifics of your project, I personally don't think I'd be all that interested in the results. As much as I like the elegance and simplicty of the implementation of the Plan 9 user-land, much of the beauty of the system comes from the simplicity and elegance of the kernel. So if I were using the Plan 9 user-land on top of the LInux kernel, I wouldn't feel the same sense of beauty, intellectual satisfaction, and connection to the original developers as I do running the same user-land on the Plan 9 kernel. But just because I wouldn't be interested is no reason to stop your research. Just be sure to study the similar efforts that have come before and that have been mentioned here. What did they accomplish? Did they go wrong somewhere? Can you get to that goal avoiding those mistakes? If nothing else, the whole experience will almost certainly give you a greater appreciation for the Plan 9 kernel. Just a couple of thoughts from an old-timer who misses the days of working on PDP-11s. BLS
Re: [9fans] 9P or better file services for multiple platforms
On Sat, 9/1/18, Lucio De Re wrote: > I'm trying to arrive at the most elegant solution to the following > problem that does not sacrifice a great deal of efficiency. And, maybe > I need to state this, the final result must be as robust or more > robust than what I have in place currently, which has yet to let me > > My system mixes up Plan 9 and Linux platforms, none of them > > My hope is to provide a central file server that fulfills reliable > file services to both Plan 9 and Linux as seamlessly as possible. I am I'm not going to make any guarantees about the reliability, but I do have a file system running on Plan 9, that natively provides NFS service as well as 9P. I also run it with a snapshot device under it and get the type of history we expect in a Plan 9 world. To make the *nix side happy, it does support symbolic links. (Reading a symlink in Plan 9 just results in the path name string that the link points to.) And to make things really fun, it also serves AOE. I've been running it now on my home system for several years. I honestly don't use the NFS capability all that often, but I did test it a fair amount back at Coraid. Recently, I added a little feature to the snapshot device to allow me to easily migrate to a larger disk. As a matter of fact, I read your e-mail in acme on a 9vx which was taking its root from this file system. I'm sure there are plenty of nits that people could pick with it and the details of its design, but it was an interesting approach to experiment with and it's been serving me well for about 4 or 5 years. The file system itself runs in user space on vanilla Plan 9, and the snapshot device can be added to the kernel very easily. Although there is a version of both the snapshot device and the file system on contrib, if anyone's interested, I can get you the most recent code to play with. BLS
Re: [9fans] What are you using Plan 9 for?
On Wed, 6/20/18, Ethan A. Gardener wrote: > but on the back burner is a > Forth-based project; a sort of operating system where the > primary interface to all tasks is a Forth interpreter. So > far, I've written the basics of a text editor. It's > *very* little code! I love seeing this idea coming back around. Way back in college, one of my senior projects was a little OS on the PDP-11 that was done exactly this way. The app language and the command language were a Forth implementation I had done out of curiosity in my freshman year. About a year and half ago, I got it running again, first in simh, then on a little LSI-11 in those cute little BA11-VA boxes. It was wild seeing that running again after over 30 years, and I found and fixed a concurrency bug. :) One of my students did (mostly just started on) a project his past term that's gotten me to thinking a little about reimplementing the whole thing on a Pi. BLS
Re: [9fans] What are you using Plan 9 for?
On Fri, 6/15/18, Mark van Atten wrote: > On Fri, Jun 15, 2018 at 6:44 PM, Brian L. Stuart > wrote: > > Can't say for LInux, but I run it all the time under 64-bit FreeBSD. > > As of 11.0, FreeBSD has its own fdclose() with conflicting types. > https://github.com/0intro/vx32/issues/3 > > Did you patch it, or are you running an earlier FreeBSD? As I recall, I'm still running a binary I built on FreeBSD 10. It looks like it's dated Jun 2016. So I hadn't noticed the conflict. BLS
Re: [9fans] What are you using Plan 9 for?
On Fri, 6/15/18, Lucio De Re wrote: > Great news. I've upgraded my Linux Mint to 64-buit ad I've been > reluctant to experiment with 9vx, which I really like a lot. Can you > confirm thatit runs OK under 64-bit Linux? Do I need to add any > special bits, different from p9p, to get it to compile? Can't say for LInux, but I run it all the time under 64-bit FreeBSD. BLS
[9fans] Plan9 on Pi 3B+
Has anyone tried Plan 9 on the new Pi 3B+? I've run into something that confuses me a bit. First, it seems you need the new version of start_cd.elf to bring up the 3B+. However, with that, the kernel throws a lock loop error. In tracking down the loop, it happens in startcpus() in archbcm2.c. The code here looks like: for(i = 0; i < ncpu; i++) lock(&startlock[i]); cachedwbse(startlock, sizeof startlock); for(i = 1; i < ncpu; i++) { if(startcpu(i) < 0) return i; lock(&startlock[i]); unlock(&startlock[i]); } So we grab a lock on all the CPUs, then drop into a second loop where we start CPUs 1 to n. But in that loop we grab the lock again and then immediately unlock it. This is where the lock loop happens. Everything seems to continue to be happy on both a 2 and a 3B+ if I comment out the lock in the second loop. But what is the rationale for the lock in the second loop? Was there a reason for putting it there, or was it an oversight that wasn't exposed until the new boot code? Thanks, BLS
Re: [9fans] Inferno on Plan9
Alexander Kapshuk wrote: > On Thu, Dec 28, 2017 at 9:54 PM, Brian L. Stuart > wrote: >> Which version of FreeBSD did you use, and did you use the >> Inferno on bitbucket? I'm finding it a long way from building >> out of the box there these days. > > While not a FreeBSD user, the bitbucket repository is: > grep bitbucket ~/inferno-os/.hg/hgrc > default = https://bitbucket.org/inferno-os/inferno-os > > Care to elaborate a bit more on what sort of trouble you're having > building Inferno on your system? I'm using FreeBSD 11.1. Things have changed a little since they switched from gcc to clang. I'm also running on an am64 install. First, I had to rebuild mk. The supplied binary expected the libc shared library to be named libc.6.so, but the one present on the system is just libc.so. In doing that, I found there was no setfcr-FreeBSD-386 source file. Copying the Linux one made it possible to build lib9. Now I'm fighting with the floating point stuff. None of the FP constants are found. I seem to remember running into the same thing last year and did eventually sort it out. The other problem then was that a couple of the X libraries weren't part of the 32-bit support and I could only build emu-g. BLS
Re: [9fans] Inferno on microcontrollers
On Sun, 12/31/17, Bakul Shah wrote: > I don't think we can assume a more popular plan9 would have > met the fate of Linux. What bothers (some of) us is not that > Linux is mainstream but that it is far too complicated and > kitchensinky. I'd like to think that there can be widespread use without the bloat and absurdities. However, I suspect that overly complicated and kitchensinky is necessary for mainstream. From what I've observed over the last 40 years, even among those who are technically educated, the subset who will choose well-designed over packed-with-unused-features is sadly small. Seeing how many "modern" programmers immediately reach for the obscene JavaScript "frameworks" for everything they do is enough to drive one to drink. I will admit that the cause and effect might also work in the other direction. There does seem to be a very real case to be made that as a system becomes more popular, it attracts more people who lack the judgement and the good taste to say 'no' to features that don't fit well. Personally, I think that popularity and bloat form a positive feedback loop that stalls out once the complexity budget is exhausted. From then on, all future releases merely rearrange the bugs. Certainly, I'd love to be proved wrong. But I can't think of any examples where the mainstream user and developer communities were able to resist the latest "ooh shiny." Just look how long it's taken for the community to realize that flash was a bad idea. BLS
Re: [9fans] Inferno on Plan9
On Sat, 12/30/17, Andre Wingor wrote: > And also ready-made live distributions for launching from USB and > installing on a desktop with simple copying > without admins privileges. I haven't thought about anything along those lines with the hosted versions, but a while back I did start putting together a bootable live CD running natively. Graphics were limited to standard VGA (640x480x16 IIRC) and I ran out of momentum when messing around with Ethernet drivers on older laptops. For a hosted version, as long as you only targeted various Unices, you could probably have a shell script that figured out which emu to run based on the output of uname. BLS
Re: [9fans] Inferno on microcontrollers
On Sun, 12/31/17, Rui Carmo wrote: > I honestly don’t think Plan9 or Inferno will become > “general use” without (at the very least) a modern > browser, For which we can all be grateful. "General use" is not a good thing to be desired. One of the biggest reasons I moved away from Linux was that it was becoming too mainstream for me. > Inferno, dis and 9p seem like a good fit for > embedded devices, Very true. > So I’d like to know if anyone here knows about > recent efforts to run Inferno on other tiny > machines... Not particularly recent, but several years ago I ported Inferno to the SunSPOT device. As I recall, the version I was using had 1MB of RAM and 4MB of flash. It took some squeezing (like severely reducing the size of the ARP tables), but I did get it running including IPv6 over the 802.15.4 radio in it. BLS
Re: [9fans] Inferno on Plan9
On Fri, 12/29/17, Bakul Shah wrote: > On Fri, 29 Dec 2017 19:11:22 +0000 "Brian L. Stuart" > wrote: >> I'm at the same point I usually am when getting ready to teach my winter >> term OS >> course. > > Why teach about Inferno? Just curious. It works out to be the sweet spot where a lot of considerations come together. First, I like to teach OS from an internals point of view. I feel that one should understand how one's tools work before using them. Second, like a lot of people of my generation, the way I really learned about operating systems was from Lions commentary on 6th Edition. For years, I had been thinking about writing an OS text, but had been teaching from Tanenbaum using MINIX. It was getting somewhat problematic in the days when no one was running VMs for everything and students were getting to where they didn't know how to partition drives and run other OSs. Then when Vita Nuova released the Inferno source, it was like all the pieces fell into place. It's well-written and carries a lot of the same ideas as Plan 9. Students don't have to allocate any extra hardware or even configure a VM. It's small and simple enough that we can cover all the major elements of it as well as the general principles in one term. But they're able to get some exposure to the internals of a real system and not just something created for illustrative purposes. With the ubiquity of VMs these days, a good argument could be made for using Plan 9 in a VM for the course. Maybe someday I'll look at adding Plan 9 chapters to the book, but at least for now, I'm finding Inferno works quite well. BLS
Re: [9fans] Inferno on Plan9
On Fri, 12/29/17, G B wrote: > I used Inferno from bitbucket.org but wasn't able to build > on FreeBSD 11.x/amd64 so I just reverted back to FreeBSD > 9.3/i386. But I may try to build using 11.1/i386 with > gcc. I'll have to use KVM on OpenIndiana to try it > though since I don't have a spare physical machine at > the moment. Don't go to any trouble on my account. I'm at the same point I usually am when getting ready to teach my winter term OS course. I've got it built, but without the X11 support on my FreeBSD machine. It does build and run on our Linux cluster with the X11 support though, so I can at least demonstrate it to the students there. And for the record, the fix to the missing FPxxx constants was to copy over the defines from the MacOSX version of the lib9.h file. I had given some thought to adding amd64 support in at least the hosted versions, but as usual the round tuits have been in short supply. BLS
Re: [9fans] Inferno on Plan9
On Sat, Dec 23, 2017 at 7:13 PM, G B wrote: > I've installed Inferno on FreeBSD but how do you build it for Plan 9? The > makemk.sh file and without looking, I think the mkconfig file too, reference > gcc. And the makemk.sh has /bin/sh. Do I have to install a Bourne or Korn > shell plus gcc from contrib to compile? Which version of FreeBSD did you use, and did you use the Inferno on bitbucket? I'm finding it a long way from building out of the box there these days. BLS
Re: [9fans] The Case for Bind
On Fri, 9/15/17, Marshall Conover wrote: > I'll start digging in to see what I can do. I think I jumped the > gun by trying to contribute a feature, ... On this point, I'd suggest a slight shift of perspective. This is something that I've tried to convey both to collegues when in industry and to students when teaching. Don't think in terms of implementing features. Think instead of implementing mechanisms. The mindset where every feature is implemented with its own mechanisms is the reason so much software is so poorly engineered. Witness the browsers mentioned earlier. Good engineering involves designing and selecting a good set of simple mechanisms that when used in various combinations provide a rich set of features. If a mechanism doesn't fit, don't include it. Remember that perfection is achieved not when there's nothing left to add, but when there's nothing left to remove. Bringing this back to bind, I wouldn't think of bind itself as a feature. However, when the bind mechanism is used in conjunction with the union directory mechanism and the architecture environment variable, the feature of sane multi-architecture binary handling emerges. No where in the source of the shell or the kernel or anywhere else is there code specifically designated to make it possible to run the correct binary based on the architecture. Of course, there are other ways of accomplishing this feature, such as a path variable, but the beauty of this approach is that all of the mechanisms involved also find application in other features. For example, bind and per- process name spaces make possible the elegance of rio which in turn provides the feature of recursively running rio inside a rio window, something that takes a lot of special effort in X. Likewise, when bind is used with import, you can get a particularly elegant form of network gatewaying. So I suggest not thinking of bind as a feature, but as a very general tool for building features. One objective when implementing a mechanism is that is reduces the amount of code in other places by more lines than it takes to implement the mechanism. There are two major reasons why it's important to keep the number of lines of code down. First, every line is a potential bug. To a first approximation, the fewer lines of code the fewer places where you might have bugs. Second, every individual and organization has a maximum level of complexity that it can manage. Once that point is hit, all new releases merely rearrange the bugs. They don't really make the product any better. A well designed set of mechanisms is like a set of basis vectors and each point in the vector space is a potential feature. If your set of features isn't larger and richer than the set of mechanisms, then you should go back and rethink the set of mechanisms. So when adding a mechanism, you want to make sure you're adding a new dimension to your feature space. BLS
Re: [9fans] Terminal possibliities...
On Sat, 10/1/16, James A. Robinson wrote: > Honestly I had been assuming one of those usb battery packs would work. :) They work pretty well. One I tested with a B+ and a 3.5" LCD screen lasted about 4 hours before it crashed. I should time it with a 3 and one of the DSI interface 7" LCD screens. BLS
Re: [9fans] Is 9Fans dead or alive
On Tue, 8/23/16, Brantley Coile wrote: > We haven’t stopped using it, but then again, we don’t talk much on the > list. I can say this particular 9 fan isn't dead...just aging. My main file server here at home runs Plan9, but with my own file system, rather than Ken's. My auth server is a Raspberry Pi B running Richard's port. I run 9vx as a terminal taking its root from my file server daily, and run it with a local root at the office. There's another older Pi B running stand-alone at the office. I tought a course last fall using Plan9 on Raspberry Pis, and I still use Inferno internals to teach my undergrad OS class. Plus one of my students did an independent study last year starting a port to the Banana Pi. So at least in my little world, Plan9 is very much alive and being used. BLS P.S. On the other hand, the last six months my little world has included a lot of activity related to the ENIAC. So YMMV.
Re: [9fans] More about /dev/draw
I'll try to answer several questions here together. > I see an image at bell labs for the raspberry pi. > http://plan9.bell-labs.com/sources/contrib/miller/9pi.img.gz > > I see that there are Raspberry Pi 2 Model Bs and Raspberry Pi 3 Model Bs > for sale. Will either one work with that image? I might be mistaken, but I don't thnk that image has the few little changes necessary for the Pi3. The kernel file contrib/miller/9pi2 might have the update, but the sources in contrib/miller/9/bcm are the most current. > Do you suppose Pi 3 may have fixed the 'sub driver' bugs? What's a 'sub > driver'? not 'usb driver', or is it? The audio out is broken, but it's > your fault? How is that? Feel free to correct me, Steve, if I get anything wrong here. I think it was a typo referring to USB. I'm not sure if it's the same one that's causing problems with serial adapters, but I've run into one that I keep intending to track down when I've tried to use USB 802.11 adapters. As for the audio, I'm pretty sure it's the same position many of us are in. We intend to do some work on supporting it, but in the words of the late Prince, this thing we call life gets in the way. > Actually, looking at the back of the monitor, it has an analog vga > plug-in and a similar sized digital plug-in, but no HDMI. Can I still > use it with Raspberry Pi Plan 9? As trebol said, if it's a DVI interface, then a simple adapter from HDMI to DVI will work. That's the way I run one of my Pis as the office every day. A typical DVI connector on a monitor looks like this: http://www.publicdomainpictures.net/view-image.php?image=12589 > On another tack ... I have installed plan 9 from user space on my debian > machine, and sam and acme seem to open and work ok. But when I type rio, > I get ... > > $ rio > rio: it looks like there's already a window manager running; rio not > started > > So, rio under plan 9 from user space (p9port?) wants the the whole > display? > > I cannot run xfce and have rio in a window? Correct. The design of the Plan 9 windowing system is such that the ability to run another instance of the windowing system in a window falls out very elegantly. The same is not true of X. There, each display has a single window manager. As Erik noted, there's xnest that allows a display to be nested in a window of another display, though I've never really played with it. I got scared enough the last time I looked at the internals of a regular X server. I'm not sure my old brain could handle xnest. BLS
Re: [9fans] Pi Hats and i2c
On Wed, 3/9/16, Vasudev Kamath wrote: >> The second talks to the MMA8451 3-axis accelerometer: >> >> http://cs.drexel.edu/~bls96/plan9/mma8451sa.c > > This link gives Forbidden message (403) Oops. I had the mode set wrong. Try it now and see if works better for you. BLS
Re: [9fans] Pi Hats and i2c
On Wed, 3/9/16, Anthony Sorace wrote: > Anyone have any example code using the i2c interface on the pi > I can look at? I'm playing around with several of these, and am not > getting the results I expect (data getting out, but the hats aren't behaving > like they're getting the same bits I think I'm sending). > > More generally, anyone got any of these hats going? I'm > starting off with the Sense Hat, since it exposes everything > on it via the i2c. I haven't done anything with the hats, but I do have a few bits of I2C code that go along with the driver modifications I posted a little while back. The first does a little lightshow on a square LED array from Adafruit: http://cs.drexel.edu/~bls96/plan9/lightshow.c The second talks to the MMA8451 3-axis accelerometer: http://cs.drexel.edu/~bls96/plan9/mma8451sa.c This latter one illustrates the subaddressing features. BLS
Re: [9fans] Wireless on the Pi?
On Sat, 1/9/16, Anthony Sorace wrote: > Anyone got anything? USB dongle we can drive, or an ethernet bridge > folks have had good results with? WiFi with WPA2 is ideal, but the only > hard requirement for my use case is power: it needs to either draw directly > or be able to draw power via USB. Not yet. I've taken a look at a couple of devices, but I've only had time to get far enough to find that usbd seems to have trouble reading the ID information out of both of the units I've tried. I don't see any time coming up soon when I'll be able to spend on it. BLS
Re: [9fans] rpi emmc
On Sat, 1/2/16, David du Colombier <0in...@gmail.com> wrote: > > in diffing bls' version and sources, i see some significant > > differences, but it's not clear which one is more up-to-date. > > Brian Stuart's version is more up-to-date. > > Brian Stuart based his changes on the latest changes from Richard > Miller, available in /n/sources/contrib/miller/9/bcm. I'm pretty sure that file is unchanged from Richard's latest version on contrib. BLS
Re: [9fans] Pi updates
On Fri, 1/1/16, erik quanstrom wrote: > i'm looking @ the gpio interface, and i wonder what the recommended > technique for sampling a pin might be from a shell script? I haven't really used it in shell scripts, but if I were going to do so, I'd probably write up a little utility to take a hex string and a bit number and do the 'and' on it. Then feed that with the result of dd to get exactly one sample from devgpio. On the other hand, if one of the usual suspects (e.g. hoc, bc, dc, awk) have some bit-wise operators I'm forgetting, use that. BLS
Re: [9fans] Pi updates
On Wed, 12/30/15, Skip Tavakkolian <9...@9netics.com> wrote: > > - Enhancements for I2C and SPI > > is there an updated devrtc3231.c, or a conventional user space > fs, that uses the new i2c? Yes, there's a devi2c userland interface ported over from Inferno. That's what's being used to drive the robot in the video clip. BLS
Re: [9fans] Pi updates
On Mon, 12/28/15, Anthony Sorace wrote: > And yes, I’d be interested in seeing your > slides, although you’ve already given me > enough to keep my busy for a bit. Anthony, I've put the slides up in the directory at: http://cs.drexel.edu/~bls96/plan9/ The class met one night a week and we have 10 week quarters. So there are only 9 sets of slides. There's not a lot of textual meat in them. I tend to have a lot of figures I talk over with some outline-level textual material. BLS
Re: [9fans] Pi updates
> Excellent. I had suspected that statement was too restrictive, but hadn't > seen the errata or gotten around to checking on a scope. I'll update that > today. New versions posted. spiclock() now rounds the divisor up to the smallest even number that results is a clock rate less than or equal to that requested. Let me know if you run into anything else that needs attention. BLS
Re: [9fans] Pi updates
> but http://raspberrypi.org/documentation/hardware/raspberrypi/spi/README.md > has an erratum suggesting "power of 2" should be "multiple of 2". I have > been using a default divisor of 250 for a 1MHz clock, and that's the frequency > I see on my oscilloscope. Excellent. I had suspected that statement was too restrictive, but hadn't seen the errata or gotten around to checking on a scope. I'll update that today. Thanks, BLS
[9fans] Pi updates
A few months ago I brought up the question of small platforms suitable for a course on small/embedded computing. If you recall the conversation, with input from the collective wisdom, I decided to use the Pi. At that time several people asked if I could share any results from the course that I'm able to. I've finally finished putting some of it together in a form that's useful. In /n/sources/contrib/blstuart/pi/ ... http://cs.drexel.edu/~bls96/plan9/pi/ ... are a collection of changes with all the changes collected into a tarball: /n/sources/contrib/blstuart/pi.tgz http://cs.drexel.edu/~bls96/plan9/pi.tgz The changes include: - Richard's post 9pi.img changes on contrib - I2C and SPI contributions from Steve Simon with the I2C support ported from Inferno - Enhancements for I2C and SPI - Devgpio driver - Man pages for I2C, SPI, and GPIO - Support for a 320x480 SPI TFT display - Enhancements to the USB keyboard support to handle the Rii k12 keyboard/trackpad combination I've also posted a little video (apologies in advance for the quality, or lack thereof) of a Pi with the TFT screen and k12 keyboard controlling a PiBog vehicle my wife gave me for Christmas: http://cs.drexel.edu/~bls96/plan9/robot9.mp4 I'll look into making the slides I used in the lecture available if there's interest. There are some rough edges, but hopefully it might be useful to some. BLS
Re: [9fans] Small Plan 9 Platforms
On Fri, 8/14/15, Brian L. Stuart wrote: > The fundamental issue ... hwdraw(). Tonight's update: Forget what I said last night about hwdraw() and the difficulty of connecting into the devdraw/memdraw/screen stack. I had one of those embarrassing "how did it ever work" bugs. Now hooking into hwdraw() and flushmemscreen() works pretty well. With an environment variable in cmdline.txt, it boots either expecting an HDMI monitor, or the little LCD screen. A little more playing around attempting improvement and then I might take a crack at supporting the touch screen. BLS
Re: [9fans] Small Plan 9 Platforms
On Sat, 8/15/15, Joseph Stewart wrote: > Brian, does your uni let you publish your curriculum or course notes? > Is this something you've ever considered? I should be able to do at least something along those lines. There are corners of the university that get twitchy about making available for free what online students pay for. But most of us take the more traditional academic view that the whole point of the exercise is to spread knowledge as widely as possible. Of course, whether there ends up being anything worth making available remains to be seen :) BLS
Re: [9fans] Small Plan 9 Platforms
On Sat, 8/15/15, hiro <23h...@gmail.com> wrote: > cute, you should ship with fresnel lenses, then the reference is complete: > http://www.wikinoticia.com/images2//s2.alt1040.com/files/2011/11/Brazil2-800x528.jpg rotfl... I hadn't made the association until you mentioned it. I may have to mention the Brazil branch of development and show them the picture in class. > On the other hand you shouldn't underestimate the usefulness of a > thinkpad (e.g. x61) for students. They are cheap these days if you get > them used, and this could get your university a badge for ecological > behavior. At least it would be in the same price league as rpi + LCD > + keyboard + mouse + case. True. The focus is more aimed at understanding embedded systems, microcontrollers, and SoCs more than Plan 9 per se, and I expect most students will use an existing HDMI or VGA monitor. Part of my motivation for this is as a less expensive alternative for any who don't have access to a spare monitor. Of course, they're not going to get the full embedded experience. There's just not enough time to develop a custom piece of hardware and get them comfortable with bare metal programming. (Hence why I"m calling the course Computing in the Small rather than Embedded Systems.) BLS
Re: [9fans] Small Plan 9 Platforms
On Sat, 8/15/15, Steve Simon wrote: > Vncserv must do something similar, maybe that is worth looking at. > I went down a similar route but am planning to just address > the display as a different type of device, rather than as a plan9 display. Good point. Hadn't thought about that. I'll take a look and see if it has anything that might help. > Your progress is very impressive, my project stalled - I must get back to it. The other option I've been thinking about since late yesterday is to create a variant of devdraw (or add hooks into the existing devdraw) that allows it to shoot off a request to another device for every screen update. My ideal for this scenario is to have a single kernel image that will simultaneously display on both the HDMI port and the SPI display. Then add some bits to boot.rc so that at boot-time, the user can indicate whether they've got the SPI display installed and whether to set the geometry and fonts accordingly. Some of that may end up being a potential project for students in the class to do :) BLS
Re: [9fans] Small Plan 9 Platforms
> I have tried to email BLS but fear I am being spam filtered... you there? I did get one message from you, and replied earlier today. Hopefully it got through. A little more update on recent pi playing. I've been working on a little toy the last few days, namely one of those small SPI driven LCD panels: http://www.adafruit.com/products/2441 As of this evening, I've gotten it sort of running alongside the HDMI display showing the upper left corner. Here are a few pics of it in operation: The Pi with the display connected to a keyboard and mouse: http://cs.drexel.edu/~bls96/9pitft1-s.jpg and a couple of pics of the display showing acme running: http://cs.drexel.edu/~bls96/9pitft2-s.jpg http://cs.drexel.edu/~bls96/9pitft3-s.jpg It's a long way from being usable though. The fundamental issue is that there appears to be a very deeply embedded assumption that a screen must be memory mapped. I tried hooking into the hwdraw() routine in screen.c, but it seems that not every change to the screen memory space gets reflected in a call to hwdraw(). For the pics, I've got a version that periodically copies the whole of the appropriate area of the Memimage to the LCD panel over the SPI port. Obviously, that's too slow and too resource-hungry to be practical. Hopefully, I'm missing something and there's an elegant way to graft a non-memory mapped display into the devdraw/memdraw/screen infrastructure. BLS
Re: [9fans] Small Plan 9 Platforms
On Wed, 8/12/15, Skip Tavakkolian <9...@9netics.com> wrote: > the gpio pins don't seem accessible through a filesystem api > like i see in plan9-bcm (unless i've missed something). I'm pretty sure it's not there. > it would be great to merge that capability in. I've made a start on that this afternoon. I took the devbcm from plan9-bcm and stripped it down to just the gpio parts and renamed it devgpio. I've now got a B+ running with Richard's latest code that includes I2C and SPI and a first cut revision of devgpio. I'm watching an LED I wired up to it blinking driven by a program in user space as I type this. BLS
Re: [9fans] Small Plan 9 Platforms
On Wed, 8/12/15, David du Colombier <0in...@gmail.com> wrote: > > Is all that on sources somewhere or accessible otherwise? > > Richard's latest Raspberry Pi repository is available here: > > /n/sources/contrib/miller/9/bcm Cool. Somehow I missed that. I'll pull it and play with it. Using the github plan9-bcm devbcm, I've gotten as far as blinking an LED, but if there's already working I2C and SPI code, I've got devices that need to talk that. Thanks, BLS
Re: [9fans] Small Plan 9 Platforms
> Richard has an i2c and spi driver for the pi. I grafted the inferno > i2c file system interface on top of Richards driver, though > the sub addressed reads are awaiting my return from > holiday. Steve, Is all that on sources somewhere or accessible otherwise? Last night, I pulled devbcm from plan9-bcm on github and folded it into the latest pi image Richard posted on sources, but I haven't done anything other than compile and boot a kernel with it yet. I've ordered a few toys to play with including a little 3.5" LCD with touch screen that talks SPI. So I'm going to try to get that up and running soon. > I would love a > similar machine with Gbit ether and 2 or 3 sata 3s to > replace my ageing file server. Same here. In fact, I've ordered a Banana Pi to see just how close it does come to being compatible. I'll let everyone know if it does boot the rpi images. As an update to the whole thing, I've decided to go ahead and use the Raspberry Pi at least this term. Given the time available, I suspect I'd get too caught up in getting a stable port running on anything else and not do what I need getting classes prepared. If I teach this again sometime, maybe I'll get a chance to do more. I will say I very much like the documentation that TI has for the SoC in the BBB, especially compared to what passes for Broadcom documentation. The reference manual for the AM335X processor is nearly 5000 pages. And there are several other things I like about the BBB over the pi, but who knows when my supply of round tuits will allow me to spend much time working on it. My thanks to everyone who has given me suggestions. There are definitely some new machines I hadn't seen before that I'll be checking out. BLS
Re: [9fans] Small Plan 9 Platforms
On Thu, 8/6/15, lu...@proxima.alt.za wrote: > Olimex in Bulgaria manufacture and market worldwide a very wide > range of AVR and ARM based boards and peripherals. They target > the DIY market. Pay their site (olimex.com works for me) a visit. They do look interesting, and I like their intention to keep things more open than Broadcom does. Unfortunately, especially with their vacation, I fear that the time between now and the start of the term is too short for me to get one, familiarize myself enough with it to teach it, get something more interesting than Linux running on it and work out how to get them into the hands of the students. But if I ever do run a similar course again in the future, I'll definitely look at them far enough ahead of time to consider using them. BLS
Re: [9fans] Small Plan 9 Platforms
On Wed, 8/5/15, Skip Tavakkolian wrote: > RPI's running something like plan9-bcm (check github) where gpio > is exposed should work. I'm going to try plan9-bcm this weekend; > i'll keep you posted. Thanks for the pointer. I'll definitely check that out. I'm hoping to expose them to a little bit of working in the kernel anyway, but don't want to take so much of the quarter's time as to get them to the point where they can write their own drivers. So depending on where plan9-bcm stands, it might be just right. > I like ODROID hardware, but obviously there > isn't a Plan 9 port for it. True. Though in looking into some stuff on the Banana Pi, I've seen indications that it supposedly can run at least one ODROID image and it claims to be basically RPi compatible. If all that's true (and things work out ideally) the Plan9 RPi port might not be all that far away from running on it. > Arduino Yún (MIPS+AVR) could make a cool device for Plan 9, > but the MIPS part of the hardware is closed. I've had a pretty similar reaction to that one. > On the smaller end of the scale, I've just started porting lib9p > to esp8266. I'm using ESP01; it is a cheap yet very capable > device. Very cool. I'd not seen these before. Keep us posted on your progress on it. that would be a lot of fun to play with. BLS
Re: [9fans] Small Plan 9 Platforms
On Wed, 8/5/15, Charles Forsyth wrote: > I think the big advantage of the Rpi or Rpi2 (for speed, > memory and cores)is that there's a wealth of published > projects for them, including hardware ones, and other stuff, > and they aren't likely to go away. It's true that lacking SATA > and Gb Ether makes it harderto use them for certain applications > (except as demos, alhough there's a Kickstarter project for > mSATA),but if you're doing Computing in the Small both SATA > and Gb are perhaps optional. I am kind of leaning toward the RPi at the moment for reasons very much along those lines. Though I'm probably going to order at least a Banana Pi for my own playing around. If I read their propaganda correctly, it should run the OS images that the RPi does. If so, I'm really curious to see how close Richard's Plan9 image comes to running on it. And I do still need to do some playing with the BBB I recently got. In terms of the RPi though, as of yesterday, my auth server is now running on an RPi, replacing a nearly 20 year old NEC laptop. > I'm glad you asked, though, because I hadn't seen the APC Paper. It is a really cute little machine. I'm tempted to get one of those to play with too. Too many toys, too little time... BLS
[9fans] Small Plan 9 Platforms
I'm teaching a special topics course this fall I'm calling Computing in the Small. Right now, I'm leaning toward conducting it on a platform that runs Plan 9. I'm looking for something based on ARM or MIPS and that has some useful connection to the external world in the form of GPIOs. SPI, I2C, and analog I/O would be nice to have too. Obviously, the Raspberry Pi is a candidate. What are some others? I've seen some code in the source tree for the BBB. Has anyone tried it out to see what is and isn't there? How about the Banana Pi? The SATA port on it is quite appealing. Some of the other options I've been looking at include the VIA APC Rock and Paper, the Phytec Cosmic, the CubieBoard, the Odroid, the Riotboard, and the Wandboard. Has anyone done anything on porting Plan 9 to any of them? Are there others I'm missing that would be good targets for such a class? Thanks in advance, BLS
Re: [9fans] ssh handshake failed
> trying to connect from 9atom via ssh (v2) to my linux machine I get: > > ssh: dial: handshake failed > > What should I check that might have gone wrong? > (The machine is otherwise accessible from other systems via > ssh.) The first thing to check is whether the Linux box is configured to do password auth or just "keyboard interactive" auth. It seems that OpenSSH these days defaults to having real password auth turned off, but keyboard interactive turned on. It's usually implemented so that it looks the same to the end user, but the protocol is different. The SSHv2 implementation does not currently support keyboard interactive. Having said that, I seem to remember that the handshake failed error actually occurs before you get to the auth stage. It's very early in the negotiation when the two sides exchange identities and supported versions. It's possible to run the tunnel with debugging turned on and see what is being exchanged and what is being complained about. Similarly, you might look at logs on the Linux side to see if there's something it's complaining about. BLS
Re: [9fans] Raspberry Pi 2 Model B
> Apparently you can crash one with a light bulb: I once read that a similar thing happened when the IBM 701 was first unveiled to the press. IBM had put the CRT-based storage devices behind smoked plexiglass, and one could see the memory visually. Naturally, the photographers took flash pictures of the machine which caused the memory to fail, crashing the machine. Wastson's reaction was to decree that the plexiglass be replaced with a steel plate. BLS
Re: [9fans] ssh2 (at least the legacy version) seems incompatible with
> ok, i found some more diagnostic messages in /sys/log/sshdebug: > ... > The problem might be that `dh.c` has an empty implementation of `dh_client142` > ... Ingo, I must admit to being the guilty party for the SSHv2 implementation. Though Geoff gets credit for cleaning up what was some of my uglier code. It's been over a year since I looked at any of it and probably closer to 3 years since touching the crypto part. However, I'll take a look and see if I can get an implementation of the group 14 stuff in place, or at least not have it advertise something it doesn't do. BLS
Re: [9fans] DNS/DHCP/AUTH with Raspberry Pi?
> I'm new to Plan9, using acme/p9p for a couple of months, and > I want to add plan9 machines to my network. I'm thinking > that a DNS/DHCP/AUTH server will be an easy step. If this > machine could have the role of an Internet > firewall/nat-router it will be even better. > > Do you think plan9+raspi can handle this? While I haven't set one up like this myself, I'm tempted to do so. I expect the Pi would make a very nice little auth/dhcp/etc server. However, to my knowledge, there aren't any NAT implementations available on Plan 9. I know it's been worked on by several people at different times, but I don't think anyone has a currently packaged implementation. > What is the recommended size for the SD card for this role? The databases used for these functions are pretty small, so I'd be surprised if you filled a 1G card. BLS
Re: [9fans] [Solved] Anonymous function formal parameter
> int > trans(int c, char *) > { > > That parameter seems not to be used inside. That may answer > the question... Yes, that is the answer. By alowing a parameter name to be omitted, the compiler can warn you about unused parameters without having to add clutter that explicitly says, "I'm ignoring this parameter." BLS
Re: [9fans] The Third Button
> Would it be possible to create the option of merging these two buttons > for machines not blessed with the traditional rodent? If you hold down the right shift key while pressing the right button, it interpretes that as a middle button press. I'm not completely certain, but I seem to remember it has to be the right shift key and not the left. The one machine where I use that is a laptop and I've gotten into the habit of holding the shift key with my pinky and hitting the right button below the touchpad with my thumb. Still not as nice as a real middle button, but it serves in a pinch. BLS
Re: [9fans] Plan9 Sources Repository
> My whole argument goes about the following hypotheses: > 1. increasing the amount of contributions may not scale in > the current model. > 2. submitting trivial contributions is not trivial for the contributor. Both of these points seem to come from a mental model that just doesn't apply to Plan 9. In earlier messages, you used the word team to describe the set of people contributing to Plan 9. However, in reality, there isn't a Plan 9 team, per se. Essentially, Plan 9 is a research system. It's a platform and a vehicle for doing systems research. It is true that it has been very useful as the basis of products, as infrastructure, and as a daily-use OS. However, rather than being its raison d'etre, Plan 9's utility is a tribute to and the acid test of the research work done on it. After all, I'm hardly going to suggest that a file system I develop is worthy of study or use if I'm not willing to put my own data on it. (So yes, my main file server is running on thetafs, and has been for months.) Given that the primary function of Plan 9 is to be a research system, neither increasing numbers of contributions nor trivial contributions are to be expected. In fact, it's not clear they would be particularly desirable. The flip side of all this is that because it has been very useful, many of us use it heavily enough that we'd be loathe to return to a world where we'd have to do without it. So there is valid motivation to expand the set of supported hardware, fix bugs, make it easier to install and use, etc. While, I'm not in a position to speak for the principals involved, from my perspective, both 9atom and 9front are laregely so motivated. I don't think I'm speaking out of turn when I say that the maintainers of both of those systems would be more than happy to accept contributions to them. If, in the course of making such contributions, you reach a point where the contribution channel could be improved, then contributing an improved contribution mechanism would be just as welcome, I suspect. In other words, welcome to the Plan 9 community. We'll be glad to help you however we can. We encourage and look forward to seeing any contributions you make that emerge from what captures your interest. BLS
Re: [9fans] Plan9 Sources Repository
> - having an SSH2 server (there is one in 9atom, but I didn't > see it in the stock Plan9). Geoff included the same ssh implementation as 9atom has in /sys/src/cmd/ssh2 but with some code clean-up. So the server code is there. I've been meaning to go back an reconcile the two different versions, including some bug fixes in the 9atom version, but my supply of round tuits is small. > Are you sure it doesn't have the Heartbleed? For a number of reasons, yes, I am. The Plan 9 ssh v2 implementation is completely new and doesn't share any code with either OpenSSH or OpenSSL. That decision was made for a lot of reasons, one of which was to make the system less susceptible to the script kiddies. While I certainly don't have the hubris to suggest it is without flaws, I'm pretty sure its flaws are different than those of the mainstream implementations. So one is unlikely to get very far using a mainstream exploit. Having said all that, I would not recommend running an SSH server on Plan 9, unless you have a really compelling reason. With all due respect to those who developed the protocol, its authentication model is not, in my opinion, as solid as that of Plan 9. If you want to remotely "log into" a Plan 9 system from a foreign system, use drawterm, or cpu from a virtualized Plan 9 terminal. BLS
Re: [9fans] Plan9 Sources Repository
>> you may edit the wiki yourself to correct these issues. > > The Wiki seems to be frozen (i.e., not editable anymore): > - no "Edit" button on > http://www.plan9.bell-labs.com/wiki/plan9/software_for_Plan_9/ It was changed some time back to allow edits only using the acme wiki interface, rather than a web browser. BLS
Re: [9fans] simplest disk filesystem
> I’m trying to make a tutorial explaining the code of > a not too large kernel (9), but there are too many > things to explain so I have to cut things. So having > a simple fs which does not require to explain 9p, the > rpc, the mount device, etc would be great. In that case, I'd suggest using devroot since it's useful to know how things get bootstrapped and having a small set of files in the kernel image is a handy technique for embedded applications. Although it doesn't talk to any disk devices, you can point to the next tutorial and explain that most file systems run as user applications and communicate with the disks by way of 9p. BLS
Re: [9fans] simplest disk filesystem
> I’m looking for a very simple in-kernel filesystem. What's motivating the desire for to be in-kernel? Nearly, every file system in Plan 9 runs in user space. All the ones that have been mentioned do. The only in-kernel file system in the labs' distribution is devroot which is read-only and intended only to provide enough bits to get the system up and running. 9atom also includes a devtinyfs that you could take a look at. BLS
Re: [9fans] Question about fossil
> With the trick I am talking about, there is nothing to stop > you from connecting to N different remote ventis. In effect > your local (by that I mean under your control, not necessarily > on the same machine) venti can be treated as just a buffer! I took a look at some things along those lines a few years back in the context of file systems aimed at laptops where the buffer allowed for operation when disconnected from the main server. It wasn't strictly tied to venti as a back-end. There's a paper on it in the proceedings from IWP9 '09. http://4e.iwp9.org/papers/lapfs.pdf It would be interesting to build the same sort of thing in the fossil-venti connection rather than in the 9P path. BLS
Re: [9fans] Mistake in Plan9 Mercual port?
> ssh2 doesn't work with passwords (at > least not without changing server > settings), you need to use keys. It does work with real password auth, but current OpenSSH distros default to not allowing real password auth. They use keyboard-interactive instead, and it's set up to look to the user just like password. But it's totally antithetical to factotum. I've thought about doing something to make factotum fake it for the usual case of keyboard-interactive looking like password, but it'll be later this summer before I could possible even look at it. Of course, anyone else who would like to do it would gain undying gratitude. :) As it stands at the moment, the two options are to change the server config to allow real password instead of fake password, or use the public key auth. BLS
Re: [9fans] dual boot
> BTW, I recently got hold of your OS book. Very nice book, especially > the inferno parts, which was my primary interest when I bought the > book. Thanks, Ram. I'm glad you're enjoying it. In the midst of moving and preparing to return to the classroom this summer, I plan to get the copyright back from the publisher. There are some parts that I definitely think I can explain better. I'd also like to incorporate some material focused on the issues releated to large numbers of cores. But it'll probably be at least the end of the summer before I have any more news on it. Thanks again, BLS
Re: [9fans] dual boot
> It now > booted but the username "ram" didn't have > any of the rc init files. There's a script in /sys/lib/newuser that sets up an initial set of scripts and directories for a newly created user. The newuser(8) man page give more detail. BLS
Re: [9fans] growing/shrinking venti arena files -OR- arena file format
> I'm wondering if anyone can shed some light on growing > and/or shrinking arena files (i.e., disk partitions). > With the growing popularity of logical volume management, > vitrualization, etc., resizing partitions is becoming > more and more common, and many file systems already > have "resize" tools or options to grow/shrink file > system structures according to changes in the size of > the underlying device. I'm wondering what capacities > (if any) venti has for dealing with inceases or > decresases in the size of its arena files. To make sure I understand the question I'll attempt to rephrase it. If I have a logical volume containing an arena partition and I resize that volume to a larger size, is there a way to make venti aware of the larger partition and format the additional space as arenas in the same partition? If I have understood the question correctly, I don't think any of the existing utilities will do that. In principle, it should be possible, assuming that you don't add so much that the arena map won't fit into the fixed 512K map that fmtarenas creates. Fmtarenas just writes a partition header and then loops through all the arenas calling newarena. You could probably update the partition header and call newarena for each arena in the new space. There are probably some gotchas that I'm overlooking at the moment, but that would be the place I'd start. > Yes, I know that the canonical way to add more storage to a > venti server is to format and add an ADDITIONAL arena file > with venti/fmtindex -a. I'd be inclined to think this is easier and safer than munging around with an existing arena partition. > Is there a TECHNICAL SPECIFICATION for the arena file > format? The source code would the be most accurate spec on the format. I'd suggest starting with src/venti/srv/dat.h and move on to look at fmtarenas.c. Calls in it will lead you to the other files that will be interesting. > For that matter, any formal specifications for 9P2000 Section 5 of the man pages is the best reference for this. > venti protocol would be very helpful, too (for other > purposes). The sources are the best place to look for this one too. BLS
Re: [9fans] iwp9
> Americans aren't really creative with their city > names. They should learn from the welsh. :) Yeah, we probably do need more where half of the consonants are silent :) On the other hand, I always thought Bucksnort, Tennessee was pretty creative... Well, maybe creative is too strong a word---unusual, at least. BLS
Re: [9fans] off-topic: why linux lost the desktop
>>The question is rather: What killed the Plan 9 desktop? >> >> 1) Lack of modern GUI and GUI development kit >> 2) Lack of Object Oriented GUI configuration tools >> 3) Lack of a decent web0browser >> 4) Lack of a decent communication/messaging client >> 5) Lack of an Office Applications suite >> ... >> ... >> ... >> z) Last, but not the least, hate towards C++ and love for the Go > >But that's the list of benefits, isn't? :) Precisely. The correlation between what makes something good and what makes something popular is small but negative. One of the primary reasons I stopped using Linux was that it was becoming too mainstream and just like all the commercial junk out there. In general, I don't have any objection to reinventing the wheel. If no one ever did, we wouldn't have the pneumatic tire. But just fiddling about the edges and deciding what color it should be is the worst of R&D sins. It's BORING. If you ever watch the TV shows that are competitions of creative work, the most damning thing a judge can say is that it's boring. The same is true of software development and engineering. Besides, it it becomes unfun very quickly if you can't start something new with a clean sheet of paper at least every few months. BLS
Re: [9fans] how up to date are the PDF doc files onplan9.bell-labs.com?
> I just activated my Kindle. I mailed myself the PDF of > gawk.1 (of course). > At fit-to-screen it's too small, but rotated and increased > size it's better. > > As an emergency place to keep the Plan 9 manuals, it sure > beats lugging > around all that paper. :-) I'll be experimenting some > more. I've done some fiddling with the ms macros to add Kindle support. What I have is: . \" Override page/font parameters for Kindle .if '\nK'1' \{\ .nr PS 7 .nr VS 8 .nr LL 3i .nr TL 3i .nr PD 0 .nr PI 3n .nr PO 0.1i .po 0.1i .nr HM 0.1i .nr FM 0.1i .ds LH .ds CH .ds RH .ds LF .ds CF .ds RF .pl 4i .tl \} .el \{\ .po 1.25i .nr PO 1.25i \} You activate Kindle formatting by setting the K register to 1. The biggest issue I've run into are tables and figures that need the space of a larger page. As for man pages, There's already a register (s) you can set to 1 to get it format for 9" pages. That does improve things a bit in portrait orientation scaled to fit the screen. Those might at least give you a good starting point. BLS
Re: [9fans] SSHv2
> It seems to be failing only when factotum is already > populated with > keys (I should point out: keys unrelated to the hosts I'm > trying to > login to with the new ssh): > > term% sshtun -d > > term% ssh2 openbsd > Verifying server signature > In rsa_verify for connection: 0 > got error in factotum: unknown role verify > Key verification dialog failed > Shutting down connection 0 While it is possible to get it confused with keys already stored in factotum (the reason the -z option is there), in this particular case, the "unknown role verify" from factotum seems to suggest it's talking to the old factotum. BLS
Re: [9fans] SSHv2
> After rebuilding nfactotum and > starting it in a fresh window, > I'm able to login to all of the previously tried remote > hosts. For the reference of future search engines I have a guess on what you might have been seeing. If in the original window, you had attempted to run ssh with an instance of the older factotum bound to /mnt/factotum, then the tunnel that got started would be running with that one. Because the tunnel is persistent, running a new factotum wouldn't have affected the existing tunnel. Opening a new window created a new name space where the tunnel wasn't bound to /net, so ssh started a new one, and this time the new factotum was bound to /mnt/factotum so the tunnel is using it. BLS
Re: [9fans] SSHv2
> > The client side logs will be in > /sys/log/ssh > > This was not created on my system. My bad. He only uses syslog when he's in the role of server, not client. BLS
Re: [9fans] SSHv2
> Add this key? (yes, no, session) yes > ssh2: dial: handshake failed One other thing that might be instructive is to look at the logs. The client side logs will be in /sys/log/ssh and the server's are often in something like /var/log. They might have something that will help us pinpoint where it's getting unhappy. BLS
Re: [9fans] SSHv2
> After patching ndb/cs and running > nfactotum, I'm still having > some trouble getting the new ssh to successfully login to a > remote system: > > term% ssh2 openbsd > The following key has been offered by the server: > ek=10001 > ... > > Add this key? (yes, no, session) yes > ssh2: dial: handshake failed Unfortunately, the handshake failed error is something of a catch-all when something fails in the early negotiation to set up the connection. To narrow in on what's happening, could you first kill all instances of sshtun that are running. Then run a fresh instance of auth/factotum and don't load anything from secstore. Then try ssh again. If it still doesn't work, kill sshtun again, and run it manually with a -d option, then run ssh. You should get quite a lot of output to stderr and that will hopefully give us some clue as to what's happening. BLS
Re: [9fans] GSoC application & ideas page
> >> I'd suggest to complete native SSH2 implementation. > > > > ... > > Let's not take this one completely off the table yet. SSHv2 > would be extremely useful in helping open up communication > with external systems again. As Erik said, there is a substantial effort here, probably more than we could expect of a student during a summer. However, I can now say that the effort has been made, and something more of an announcement will be forthcoming. It'll probably be at least a few days, but a native SSHv2 implementation does exist. > I use to find sshnet extremely > viable in a mixed network where now I'm just using sshv2 to > tunnel in overly complicated startup scripts. There's not a direct replacement for sshnet per se in this implementation, but here ssh becomes a protocol sitting in /net. So it should be pretty easy to tunnel just about anything, and I suspect that the changes needed to sshnet would be relatively minor and would cut out all the SSH protocol bits. BLS
Re: [9fans] copying over 9P using plan9port
> I can then cd and explore the bell labs sources via > plan9port, so that > works just fine. > > When I then try something like > > cp -ar sources/plan9/sys/src/ape ape > > I get an error stating: > unexpected open flags 050cp: can not open > ”sources/plan9/sys/src/ape/9src/mkfile” for reading: > Access denied Give it a shot without the -a. I've had a lot of issues with the strange attribute flags in "modern" Unices. The issues have usually been when writing via 9p, but it's worth a try to see if that has anything to do with it. Any idea what the 050 flags indicate on your system? BLS
Re: [9fans] Announcing Inferno for Android phones
> >> The Wank E5 was AU$50. > > Why is it that I can't quite summon up the courage to do a > google search for "wank phone"? Because it will cost you $4.99 a minute?
Re: [9fans] MetaPost added to kerTeX!
> I will rest on my laurels for the remaining of the week... You've earned it. Congrats and thanks BLS
Re: [9fans] 9vx Binary for Mac OS X
> > it should be as simple as 'make 9vx/9vx' issued in > vx32/src. > > knowing the right make target was the stumbling block for > me too, a few months ago. I'm thinking it should be > documented. the ADVENTURE file gives wrong instructions (cd > src; make; make install) That's what makes it an ADVENTURE? :) BLS
Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames
Ron wrote: > andrey mirtchovski > > wrote: > >> This is great! > > > > it is, isn't it? 6 seconds kernel compile, 15 seconds > turnaround time > > when developing anything in the kernel (with PXE > boot). beat that, > > modern operating systems :) > > yes, I had to help config and build a linux kernel > yesterday; every > time I see it I just want to claw my eyes out. And it gets > worse every > month ... Life is too short to configure and compile Linux and GNU software. BLS
Re: [9fans] troff macros for typesetting books/longer texts
> Note, that neither plainTex nor troff handle > cross-references, > automatic equation numbering, footnote numbering, table of > contents, > etc. Nonetheless, mainly these listed features are often so > needed. > ... What I am > trying to get > is something like eplain, but for troff. And I wanted to > have a look > at how some things are to be done. And to not invent a > wheel, I asked > for some *simple* macros, which must have been used e.g. in > the > mentioned books in my 1st contribution. I'd suggest digging around for macro sets people created for various schools' thesis and dissertation formats. I expect several of us have done that and have included auto numbering of chapters, sections, equations, tables, figures, etc. If I look hard enough, I might even be able to find the ones I did 20 some-odd years ago for my master's thesis, but I'm pretty sure I won't get able to get to it until at least this weekend. BLS
Re: [9fans] Plan9 topology
> I see! I mis-understood what you meant by "Plan 9 > terminal". I thought > that the Plan 9 Live CD gave you a choice of either > installing the > Plan 9 server or a Plan 9 client/terminal. I now see that > that there > are terminals available on various OSes to connect to a > Plan 9 > server. It has become a little confusing over the last 20 years. In a way too brief way, here are the basic incarnations of Plan9: - Natively running the current Plan9 kernel - Stand-alone terminal with its own fs - Terminal (possibly diskless) talking to an external fs - CPU, auth, or file server (or some combination) All of these are running Plan9 as their "bare metal" OS - Same as above but in a virtual machine, such as virtualbox, vmware, qemu, etc. - Ken's FS: a file server that runs on bare hardware - 9vx: a port of the Plan9 kernel to vx32 that allows a full Plan9 system to run as a user-level application on another system, including Linux, FreeBSD, Mac OSX - drawterm: an earlier port of a limited Plan9 kernel that's similar to a terminal connecting to a remote CPU server - P9P (aka Plan9 ports, Plan9 from user space): a port of the Plan9 user apps to POSIX-like systems And just for fun these can all play together. At the moment, I'm using a MacOS machine that has one file system mounted using the P9P 9pfuse program. It's also running an instance of virtualbox that's net booted a Plan9 terminal. There's also an instance of 9vx running which is accessing the file system mounted via P9P. All of these pieces are talking to a Plan9 CPU server which in turn uses a Ken FS file server. > I did see that `wily', an > Linux ACME > clone is available. Guess what I did? :) I remember playing with wily quite a lot a while back. With Russ's P9P port of acme, though, you can run the real acme as a Linux app too. > I just checked - it's a 166Mhz P-I with 98M RAM and 4.5G > HDD. Made a > good dedicated mail server. May not have enough gonads for > a Plan 9 > server though. I wouldn't dismiss it entirely. My old Plan9 CPU/auth/file server at home had a very similar configuration. BLS
Re: [9fans] Plan9 topology
> I could run a headless box as a Plan9 auth/cpu, fs server. > Then, if I > want to this Plan9 server, is there a minimum Plan9 install > that I > could put on the spare partition that I have? With this setup available, there are several ways you can go. As a lot of people have suggested, you can install a cpu/auth/fs server on the headless machine and use drawterm to be a terminal talking to him. An even more Plan9-like way of doing it is to net-boot a Plan9 terminal from your cpu/auth/fs machine. If you want to boot your main box that way, you can without installing anything on it. >From within Linux, you can do the same thing in virtualbox. In fact, I have a virtualbox terminal running right now on my machine. It's net booted, taking its Plan9 kernel from a Plan9 machine that provides DHCP service and it mounts its root from a Ken FS machine. At home, I use 9vx taking its root from a Plan9 fossil/venti file server. > for a long time: a 486DX running FreeBSD as a mailserver; > another > running as a webserver; another couple running primary and > slave > nameservers; and one dual-homed FreeBSD box routing and > doing > firewall/natd. The only problem you'd run into there is that Plan9 doesn't currently have a NAT implementation. > The above sounds like a job for Plan9 :) But my point is - > is that I > don't need to set up a LAN to enjoy Linux or FreeBSD. Can I > use Plan9 > standalone in a dedicated partition? Yes, the default install from the CD sets up a stand-alone machine. And for most of us, that's the starting point from which we configure any specialized machines such as cpu, auth, or file servers. And you can get a pretty good feel for what Plan9 is about with a stand-alone machine. However, some parts of the system make a lot more sense when you experience them in a networked environment. Auth is a good example of this. But whichever path(s) you take, I hope you'll find Plan9 is a great system, just as we do. BLS
Re: [9fans] Plan9 development
> to a single underlying (OS) platform, but failed (in a > suprisingly ugly > way) to cater for different target object formats, even > though there were > efforts to do so. In my opinion - and this is all I > hold against Plan > 9 - by shoehorning various target object formats in the > linker/loader > as options, they spoiled the consistency of the system. I always had the impression that the object formats used by the various ?l are more for kernels and the various formats expected by loaders than for userland apps. For userland, I would think the intent is for there to be a single consistent object format (at least for a given architecture). BLS
Re: [9fans] sheevaplug port available
> I'll check the permissions on /tmp, and I bet you're right > there. There's a good chance your /tmp issue is not permissions, but a lack of /tmp being mounted. If your hostowner doesn't have a lib/profile or its lib/profile doesn't mount /tmp, then you won't be able to write anything to it. As has been mentioned, ramfs provides a file system that lives in memory and defaults to mounting it on /tmp. So running it will give you a /tmp even without fossil being there. BLS
Re: [9fans] sheevaplug port available
> Wasn't that what we found just last week regarding the > /dev/sd00/nvram thing? This is > on native Plan 9, (er, under VMware), not 9vx or anything > like that. The filesystem is > fossil, not kfs. The file servers that maintain on-disk file systems like kfs, fossil, kenfs, etc. all do use groups in the expected way. Part of the reason they can easily do so is that they have the file that lists the groups. The in-kernel file servers and many of the user space file servers that don't provide persistent data storage do not fully handle groups. This isn't too surprising since they might well be running without a persistent disk-based file system present. So the fossil file system does use groups, but the server that provides /dev/sd00 does not. BLS
Re: [9fans] So, why Plan 9?
> Oh, and most of the Plan 9 tools were first made > available to use outside the Plan 9 OS through > Russ Cox's plan9 in user space effort > (http://swtch.com/plan9port/). And there's the > virtualisation project vx32 that includes Plan 9 > as an example. Not sure how they fit into a > holistic view. They're more like pragmatic > ways forward when you can't (or don't want > to) run a stand alone OS. I'm probably not the best person to try to present the holistic view, but I will anyway. To understand where Plan 9 came from, we first have to understand how UNIX developed. In the late '80s, UNIX was about 20 years old and had not aged too gracefully. In particular, as Sun said, the network had become the computer, and UNIX networking was kind of bolted onto the side of the system. Similarly, graphical interaction had become ubiquitous well after UNIX had originally been designed. The way I like to describe it is that the Bell Labs guys at this time decided to take 20 years of UNIX experience and start over again and do it right, applying that experience. The result was Plan 9. There are 5 main approaches to having the Plan 9 experience. First, the "real" Plan 9 experience requires a network of machines including file servers, CPU servers, and terminals. Of course, the original Plan 9 systems ran natively on bare hardware, and it still happily runs on a lot of hardware. The biggest problem with just grabbing a bunch of random hardware and running Plan 9 on it is the problem of drivers for random PC hardware. But a lot of us do run Plan 9 on bare hardware and it's a refreshing experience after years of UNIces. I should also point out that Plan 9 has from the very beginning been built around running on a variety of hardware and today runs on everything from tiny gumstix machines to Blue Gene/P. The second major approach is running Plan 9 on simulators and virtual machines. Most of us have had varying degrees of success running Plan 9 "networks" on instances of qemu or vmware or xen or... This is a pretty good way to mitigate the hardware support issues. It's also a nice way to set up and test distributed things while sitting with a single laptop in a hotel room. If you have a real Plan 9 cpu server, but don't have a Plan 9 terminal for accessing it, you can use the application drawterm. It is an interesting modification of the Plan 9 kernel running as an X11 application. Unlike a real terminal, it doesn't run any Plan 9 applications locally on the terminal, but it does give you an interface to a real Plan 9 system. Over time, many people who at one time used Plan 9 as their main systems, were pulled away and found themselves back on UNIX-like systems. For a period of time, there were several projects that implemented Plan 9 inspired tools for UNIX and X11. This is where P9P (aka Plan 9 from User Space) comes in. Russ Cox ported the bulk of the Plan 9 application set to UNIX-based systems. With these, you can have a user environment that looks a lot like Plan 9, complete acme and sam. Later, Russ also developed the vx32 virtualization and the implementation of Plan 9 on it. This is 9vx which allows you to run an instance of Plan 9 as user application. 9vx is essentially a port of the Plan 9 kernel to the vx32 platform. It's great as it allows you to run a "real" Plan 9 terminal as an application on a more traditional system. You can run it stand-alone with the root taken from your host system, or you can run it as a terminal that takes its root from a Plan 9 file server. As I sit here at IWP9, I am typing this in acme in 9vx running on FreeBSD, using the rio port in P9P for my window manager. Because I'm away from my home network, I'm running 9vx with the the root on my local machine. When I'm at home, I use 9vx booting with its root taken from a real Plan 9 file server. I also run it on qemu fairly often. The bottom line is that there are quite a variety of ways to work with Plan 9 and they are all useful in their own ways. I've been too long-winded as it is, so I'll stop now. Hopefully, I haven't said anything that's too far off base. BLS
Re: [9fans] native lbl, long text in troff, bold italics in eqn
> 2) I heard and read that the 'ms' troff macros are not > suitable for > longer documents (I want to write my PhD thesis), as > opposed > supposedly to the 'me' macros (which, however are not in > plan9, I > believe). Can anybody give me their opinion? There should be some macro packages out there that fit particular universities' requirements. If you can't find one that's close to your needs, I think I can find the one I did at Notre Dame, but you may have to change things like chapter headings if you have stricter requirements than ND had. (I did have stricter requirements at Purdue, but I used LaTeX there). Be forewarned though, this macro package was written 25 years ago on troff running on 4BSD. No guarantees that it'll work out of the box with current troff on Plan 9. BLS
Re: [9fans] writing to ctl using fprint and write
> > Thanks Erik, Sape, and > Skip. That was such a STUPID error, and I thank > > you all for the extra eyes. I think it is time > for a break and a bowl of > > tea... > > relax. not stupid, subtle. it takes vigilance > to keep > sizeof, nelem, strlen, and the number of characters > straight. This is part of why I often recommend (and generally do myself) that sizeof only be used on types, not variables: Foo bar; use sizeof(Foo) rather than sizeof(bar). It does require slightly more work for arrays: Foo bar[NFOO]; requires NFOO * sizeof(Foo) rather than sizeof(bar), but I personally think it's worth it to keep the distinction between sizeof and strlen straight. BLS
Re: [9fans] Announcement: Fifth IWP9 - Oct 11-13 2010, Seattle WA
> > AWESOME! I will try to round up some friends who may > never have even seen > > Plan 9 before as well. > > Dave > > If we're going to have newbies then maybe an evening > installfest would be fun. > > ron Good idea. It might also be worthwhile to introduce that with an overview of the roles and differences among: Plan9, P9P, 9vx, drawterm, and Inferno, along with some examples of how they all get used. And some mention of the various virtualization options might be good to. BLS
Re: [9fans] crashing 9vx
> you may be right, but it seems too easy to blame gcc. > a better fit for the facts so far would seem to me that > 9vx' locking is broken. the optimization may just > put > more pressure on broken locking. I would certainly agree that the variability of the crashes feels like a mutual exclusion problem. The wide variety of effects of changing optimization seems to by trying really hard to tell us something. Of course, after two days of house-hunting I could probably convince myself that the phase of the moon is involved. BLS