Re: [9fans] Is the vanilla Plan 9 still alive?
most of these answers don't really answer the question everyone knows op is asking. why do we always play these games? the answer is: no, vanilla plan 9 is not still alive. background: plan 9's creators all left bell labs many years ago, and none of them use plan 9 anymore[0]. bell labs itself has changed hands a couple of times since development of plan 9 came to its ignoble end. yes, some third parties occasionally tinker. richard miller puts out code that can be run on raspberry pi hardware. some other former heavy users occasionally push piecemeal bits of personal projects into the public eye. nobody takes any of it seriously because none of them really use plan 9 to do anything people use computers to do[1]. which is not to say their efforts aren't appreciated. thanks, guys. for some reason, when interested newbs show up on this mailing list asking this same question, which happens from time to time, they're always made to believe there exists a thriving community of devoted plan 9 from bell labs users eager to point them towards resources useful for running plan 9 on a computer manufactured after sbc rebranded itself as at 9front was created in 2011 because by then it had already been apparent for several years that this was a baldfaced lie. failing a massive leak of all the code 9fans will swear to you they are running on their modern computers, your choices include: - 9front (new drivers, modern cryptography, useful new programs) - 9legacy (an attempt to combine patches from all extant personally maintained copies of the plan 9 source tree) don't thank me until you've tried to get straight answers to follow-up questions. sl [0] http://fqa.9front.org/fqa0.html#0.2.3 [1] i'm typing this on a thinkpad x250, over intel wifi/wpa2, running 1920x1080 on the native lcd. it's running plan 9, but is sure ain't vanilla[2]. [2] oh yeah, all the code is available here: http://code.9front.org/hg/plan9front -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tf27e6479d8812712-M638dbd98d3e82c0062f4a8c0 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] supported modern laptops
and it has a vga port. sl
Re: [9fans] supported modern laptops
thinkpad x250 (see related entry in fqa3). everything works. mine is 1920x1080 ips. nothing newer is tested, but when we started, nothing newer than t23 was tested. sl
Re: [9fans] Anyone have a Plan 9 4th Edition Manual Set...
I paid $0.99 for my set on eBay. sl
Re: [9fans] UI design | enhancements.
thinking is hard. there is a sweet spot somewhere between ease of use and knowing what you're trying to accomplish in the first place. once you learn the system, you can get a lot of mileage out of in-built system features, such as shell commands, lists (variables), functions, and pipelines. file interfaces and private namespaces make these simple primitives even more powerful than they are on presumably more familiar unix systems. (it has to be said: unix users already don't seem to get much mileage out of existing unix features.) rio is scriptable, and all of its features are exposed to file interfaces and text commands. that's a huge steering wheel, even if your hands are small. all the cosmetic stuff new users typically complain about can be modified with a minimum of knowledge and skill. this is a benefit of the terse, simple programming style. sometimes, even a deficient program can be better than a featureful one, if the deficient program is simple and easy to modify. just implement whatever it is you actually want to do. some people would say this is ugly: http://plan9.stanleylieber.com/rio/img/20190415.png sl
Re: [9fans] sources down
i think what annoys people is things (experiments, code, entire operating systems) that are intended to be kept private neverthess stil get mentioned. the happiest scenario is the one we just witnessed: after an exchange of several more messages on the list, the bits got published. thanks, david. sl
Re: [9fans] upas : without acme : possible?
I ended up writing a ned-alike that is just a shell script: http://plan9.stanleylieber.com/rc/mother This is what I actually use. sl
Re: [9fans] upas : without acme : possible?
It's not clear why you think the interface provided by upasfs(4) is captive, or why you insist acme needs to be involved at all. I'm writing this message with nedmail/marshal, connected to Plan 9 in a plain SSH terminal session -> OpenBSD -> drawterm -G. No GUI or terminal frills or frippery is involved. sl
Re: [9fans] upas : without acme : possible?
> is that "mail" you mention similar to "mailx" under unix-like systems? > the problem is one of not wanting a captive user-interface to the > mailing sub-system. On Plan 9, 'mail' is a shell script that invokes either nedmail(1) or marshal(1), depending on the flags it consumes. The nedmail program is nearly identical, from a user interface standpoint, to the mail command that shipped with the 8th edition of Research UNIX. It remains part of the same (though evolved) e-mail processing system, upas. Ned is a little different than mailx(1), but it's probably just about what you're looking for. Plan 9's mail system itself (upas) relies heavily upon upasfs(4), filter(1), and simple rc scripts, which make even complex tasks like custom spam filtering and automatic mailbox management trivial. sl
Re: [9fans] plan9port : complete system : kernel : freebsd || linux ?
Re: [9fans] plan9port : complete system : kernel : freebsd || linux ?
what is the point of this exercise? sl
Re: [9fans] Touchpad
> How can I disable the touchpad so only the mouse moves? bios sl
Re: [9fans] 9front VMX
Yes, you get full graphics, but performance is terrible (the frame buffer is emulated entirely in software). You can run any browser, and everything works, but probably not fast enough for regular use. I have used Chromium in a pinch to login to Patreon, PayPal, etc. Gimp also works fine (if very, very slowly). I have used it to make edits to 9front propaganda. sl
Re: [9fans] 9front VMX
vmx(1) documentation in the dash1: http://fqa.9front.org/fqa8.html#8.7.5.1 script i use to run openbsd: http://plan9.stanleylieber.com/rc/openbsd in my setup opensd is the first hard drive and 9front is the second. vmx(1) runs openbsd from the hard drive installation. note: performance is terrible. sl
Re: [9fans] There is no fork
On Feb 14, 2018, at 2:18 AM, Rui Carmo <rui.ca...@gmail.com> wrote: > On 14 Feb 2018, at 00:31, s...@9front.org wrote: > >> 1.) is the wrong approach. Just build inside Plan 9. > > You missed the rest of the thread. I read the entire thread but I didn’t see this point specifically addressed. From the latest posts it is still unclear where you plan to do the compiling. Okay, so let’s stipulate compiling on Plan 9. Unless I missed it, the relationship between your automated tools on the Linux host and the build on the Plan 9 guest (for example, how they will communicate) hasn’t been mentioned at all. That’s why I brought up the 9front fork of drawterm as a possible facilitator. It can handle 9front’s new auth scheme and it can run individual commands. Lacking something like this, how else do you plan to control the build on Plan 9? It also wasn’t clear to me that you’ve spent any significant time actually using Plan 9. It might even be a good idea to use the system for a while, even without all the external automation, to figure out if any of this is even worth your time. A lot of people find they don’t like Plan 9 once they get here. Anyway, good luck with whatever your ultimate goal is. sl
Re: [9fans] There is no fork
>> Rui, please present any issues you had with the step-by-step >> introductions in the fqa to us on the 9front mailinglist in a >> designated thread. > > The main issue for me is putting together a build environment on top > of KVM or Linux, which isn’t covered in the FQA. > > I can’t build 9front on a Pi (well, not in productive amounts of > time), and all the machines i have available with the requisite > horsepower are in the public cloud (except for my iMac and a local KVM > host that is already overburdened with my Windows development VM). > > Since I’m a staunch supporter of CI/CD I’d love to automate the > process from committing code to building a burnable image, and dipping > into 9front from “outside” to run the requisite commands is going to > be a time sink. It sounds like you are saying you want to 1.) build Plan 9 on Linux, using Linux tools, 2.) and test it by running the result in QEMU/KVM/whatever hosted by Linux. 1.) is the wrong approach. Just build inside Plan 9. 2.) is trivial and is covered in FQA3[0] and FQA5[1]. 9front's fork of drawterm[2] can run without graphics, and can be used to execute single commands. If this is really your aim, I think you can accomplish it with minimal stress. sl [0] http://fqa.9front.org/fqa3.html [1] http://fqa.9front.org/fqa5.html [2] http://drawterm.9front.org
Re: [9fans] There is no fork
> On 2/13/18, Rui Carmo <rui.ca...@gmail.com> wrote: > > I get the current website and some of the in-jokes, but a step-by-step guide > > for installing, building and contributing would be great ... > > It's so easy to fall into the trap of elitism, while bemoaning the > shortage of development hands needed to bring Plan 9 (or any one of > its other flavours) into the "mainstream". > > What keeps Plan 9 alive and this list/group thriving is the > conversation, irrespective of the actual pertinence to the "real > world". It is knowing that the world has rejected the Plan 9 "grace" > and are therefore not deserving, blah, blah. Human natures, humoured, > harmlessly. Why not? Plan 9 is elegant, 9front presumably has some > robust features, the other flavours can handle their own niche > objectives. > > I've been absent here for a long spell and came back recently to > discover most of the old hands still at it and some new blood raising, > mutatis mutandis, the same issues we've seen go past since 1995 (for > me). It is as familiar as it is reassuring. > > But the reality is that Plan 9 is too good in too many ways and the > world can only absorb chunks of that at the time (disruptive > technologies, I believe they were labelled, way back) and so it > progresses very little while the few remaining contenders to the prize > of OS of the century or millennium or whatever have the resources to > track the bad engineering decisions they (the OSes) facilitate or even > demand. > > Merging Plan 9 flavours would resolve many otherwise intractable > problems, but it will do nothing to improve the penetration of Plan 9 > in the marketplace and no one has the funds to tackle it, even if they > felt that the result would be worth it. > > But there is something in not following the fashion; I, for one, > really cherish it. Mostly because it is all so simple, once you leave > the baroque world of Windows, Linux and OSX behind. > > Lucio. I think he was looking for http://fqa.9front.org/fqa4.html and http://fqa.9front.org/fqa5.html sl
Re: [9fans] There is no fork
> On 2/10/18, Benjamin Huntsman <bhunts...@mail2.cu-portland.edu> wrote: >> Just curious as to the state of the union. Is 9front pretty much the de >> facto "official" Plan 9 these days, or does anyone still use or maintain any >> of the following: > > I'm with David (legacy), nearly all the way. > > That said, I deem it unfortunate that there isn't a drive to > consolidate the various flavours of Plan 9 into a single offering, or > at least identify and discuss the differences and provide for the > choices from a single source (pun intended). Have you considered providing this service? sl
Re: [9fans] equality sign in Rc
Honestly, the equality sign is never a problem for me. What is the purpose again of making this change? sl
Re: [9fans] Terminal possibliities...
> I believe that it is documented somewhere on Russ Cox’s website or on > plan9port. Sorry, I thought you were referring to the swipe gestures introduced in the link you quoted. sl
Re: [9fans] Terminal possibliities...
> Is there any interest in putting these p9port style keyboard modifiers into > p9bl or 9front? Could you explain exactly what the modifiers are and how they work? sl
Re: [9fans] plan9.bell-labs.com hates AppleWebKit?
> So... Does Alcatel-Lucent have a problem with AppleWebKit > users on principle? Interesting reversal. sl
Re: [9fans] 9front 5492 1919
> #plan9doomport James? sl
Re: [9fans] 9front sam in plan9port.
>> > The plan9port version also has chording if in its samterm/main.c you >> > change #define chording 0 to #define chording 1. >> >> It was also marked as being buggy, which is why it remains disabled by >> default. > > i believe rsc found the reason for this later. the bug was that it caused > protocol lock. > i don't recall what the details of the bug or the fix were. Ah, I wasn't aware of that. The chording in 9front sam is a different implementation. There haven't been many changes; as far as I can remember, only the addition of chording and Ctrl-b to switch focus to the command window. And some minor bugfixes. sl
Re: [9fans] 9front sam in plan9port.
> The plan9port version also has chording if in its samterm/main.c you > change #define chording 0 to #define chording 1. It was also marked as being buggy, which is why it remains disabled by default. sl
Re: [9fans] 9front sam in plan9port.
> Ok, the wording on that site is a bit odd to me. The name plan9port is a > project Russ Cox wrote, so the wording > > A port of 9front's version of sam(1) to unix (plan9port) > > seemed to imply porting 9front's sam(1) to plan9port. That didn't make > sense to me since Russ's plan9port sam goes back many many years earlier > than the 2014 timestamp in that repo you pointed at. Yes, and 9front's sam has some additional features (like chording) that are not found in p9p's sam. If I understand correctly, the author wanted to use those features, which is why he set out to replace the same that was already in p9p with this newer modification. sl
Re: [9fans] /acme/edit commands?
> Unfortunately sam isn't available on Inferno I don't remember where I got this, and I don't know who wrote it, and it definitely seems pretty buggy, but: http://plan9.stanleylieber.com/inferno/src/sam.tgz sl
Re: [9fans] Go on Plan 9?
Skip, isn't the point here that being able to run go binaries in Plan 9 on an arm machine is news to most Plan 9 users? Perhaps even news to those who regularly use go on Plan 9. sl
Re: [9fans] NetSurf (browser) and Duktape (javascript)
> If I'm not mistaken, Russ Cox says somewhere that he was happy working > under Plan9 but that he ported the Plan9 utilities to other systems when > he realized there was no hope that someday Mozilla will run on Plan9... > So he still uses Plan9 utilities, but not under Plan9... https://fqa.9front.org/fqa0.html#0.2.3 sl
Re: [9fans] rc exec error behaviour
> Go 1.5.1 built and is running on 9Front/amd64 I thought, but doesn't on > 9Front/386? Sorry, my report was precisely backwards. This is what I have on my systems: dl; echo $cputype 386 dl; go version go version go1.4.2 plan9/386 dl; fs; echo $cputype amd64 fs; go version go version go1.5 plan9/amd64 fs; #go-plan9 is aware of the details and some investigation was done, but work stalled out. sl
Re: [9fans] rc exec error behaviour
I think when people say "works" they mean that tip builds. The outstanding bugs with the language on Plan 9 are still outstanding (see the open issues), regardless of which Plan 9 you are running. I think it's great if someone's programs work. I use a few go programs (built with go 1.4.2 for both 386 and amd64) daily on 9front without problems. That said, go 1.5.x (the language) fails to build on 9front/amd64, but seems to build and work as well as 1.4.2 on 9front/386. The crucial aspect here is what works and what doesn't work *after* go builds. I think some people keep making cracks because some funfamental things remain broken in all versions (see the open issues). People who didn't notice tip no longer builds on some systems may (like me) have been content running their existing working binaries. Not everyone chases updates unless there is an immediate reason to update. sl
Re: [9fans] Go on Plan 9?
>From http://fqa.9front.org/appendixl.html: # automatically converted ca certs from mozilla.org hget http://curl.haxx.se/ca/cacert.pem >/sys/lib/tls/ca.pem # shell script that emulates git commands hget http://9front.org/extra/rc/git >$home/bin/rc/git chmod 775 $home/bin/rc/git # fetch the repository git clone https://go.googlesource.com/go cd go git checkout go1.4.2 # build go cd src ./make.rc # install documentation go get golang.org/x/tools/cmd/godoc # go! Newer versions of go seem to have problems with Plan 9. sl
Re: [9fans] Go on Plan 9?
loc.go /usr/local/386/go1.5/src/runtime/mbarrier.go /usr/local/386/go1.5/src/runtime/mbitmap.go /usr/local/386/go1.5/src/runtime/mcache.go /usr/local/386/go1.5/src/runtime/mcentral.go /usr/local/386/go1.5/src/runtime/mem_plan9.go /usr/local/386/go1.5/src/runtime/mfinal.go /usr/local/386/go1.5/src/runtime/mfixalloc.go /usr/local/386/go1.5/src/runtime/mgc.go /usr/local/386/go1.5/src/runtime/mgcmark.go /usr/local/386/go1.5/src/runtime/mgcsweep.go /usr/local/386/go1.5/src/runtime/mgcwork.go /usr/local/386/go1.5/src/runtime/mheap.go /usr/local/386/go1.5/src/runtime/mprof.go /usr/local/386/go1.5/src/runtime/msize.go /usr/local/386/go1.5/src/runtime/mstats.go /usr/local/386/go1.5/src/runtime/netpoll_stub.go /usr/local/386/go1.5/src/runtime/os1_plan9.go /usr/local/386/go1.5/src/runtime/os2_plan9.go /usr/local/386/go1.5/src/runtime/os3_plan9.go /usr/local/386/go1.5/src/runtime/os_plan9.go /usr/local/386/go1.5/src/runtime/panic.go /usr/local/386/go1.5/src/runtime/panic1.go /usr/local/386/go1.5/src/runtime/parfor.go /usr/local/386/go1.5/src/runtime/print1.go /usr/local/386/go1.5/src/runtime/print1_write.go /usr/local/386/go1.5/src/runtime/proc.go /usr/local/386/go1.5/src/runtime/proc1.go /usr/local/386/go1.5/src/runtime/race0.go /usr/local/386/go1.5/src/runtime/rdebug.go /usr/local/386/go1.5/src/runtime/rune.go /usr/local/386/go1.5/src/runtime/runtime.go /usr/local/386/go1.5/src/runtime/runtime1.go /usr/local/386/go1.5/src/runtime/runtime2.go /usr/local/386/go1.5/src/runtime/select.go /usr/local/386/go1.5/src/runtime/sema.go /usr/local/386/go1.5/src/runtime/signal_plan9.go /usr/local/386/go1.5/src/r untime/sigqueue_plan9.go /usr/local/386/go1.5/src/runtime/slice.go /usr/local/386/go1.5/src/runtime/softfloat64.go /usr/local/386/go1.5/src/runtime/sqrt.go /usr/local/386/go1.5/src/runtime/stack1.go /usr/local/386/go1.5/src/runtime/stack2.go /usr/local/386/go1.5/src/runtime/string.go /usr/local/386/go1.5/src/runtime/string1.go /usr/local/386/go1.5/src/runtime/stubs.go /usr/local/386/go1.5/src/runtime/stubs32.go /usr/local/386/go1.5/src/runtime/symtab.go /usr/local/386/go1.5/src/runtime/sys_x86.go /usr/local/386/go1.5/src/runtime/time.go /usr/local/386/go1.5/src/runtime/trace.go /usr/local/386/go1.5/src/runtime/traceback.go /usr/local/386/go1.5/src/runtime/type.go /usr/local/386/go1.5/src/runtime/typekind.go /usr/local/386/go1.5/src/runtime/typekind1.go /usr/local/386/go1.5/src/runtime/unaligned1.go /usr/local/386/go1.5/src/runtime/vdso_none.go /usr/local/386/go1.5/src/runtime/vlrt.go /usr/local/386/go1.5/src/runtime/wbfat.go /usr/local/386/go1.5/src/runtime/zgoarch_386.go /usr/local /386/go1.5/src/runtime/zgoos_plan9.go /usr/local/386/go1.5/src/runtime/zversion.go: exit status: 'compile 4056549: 2' I understand Fish and Aram were at least able to build 1.5 on (Bell Labs) 386. I made noise about my failure at the time but I don't think anything has happened in response. I did try bootstrapping with 1.4.2 binaries supplied by Fish (and also a set provided by Aram) but got the same results. Beyond simply building, there are also still outstanding bug reports about basic functionality that affect all versions of Plan 9. I don't think there has been much movement there, either. sl
Re: [9fans] Wireless on the Pi?
> 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. Iogear GWU627 802.11n connect ethernet port to GWU627 HTTP management interface requires Javascript. Managed to program it using Inferno's charon browser, which supports ecmascript 1.0. Vonets VAP11G 802.11g connect ethernet port to VAP11G Requires a proprietary Windows program (ships with the device) to program its settings before using it for the first time. sl
Re: [9fans] off topic - a good Git reference
> My new employer uses svn but is about to migrate to git so I would > be interested in a port, I might even get some cycles to help. I'm no help here, but one of the Harvey guys (pre-Harvey) apparently built git for Plan 9. Unfortunately, only the 386 binaries were made available, no source code. I think this may just be because the repository I found was not the source repository. Anyway: http://marcus.biz.tm/hg/gnubin The git binary seems to run. I'm not sure if it works. sl
Re: [9fans] Replacement for find
http://doc.cat-v.org/unix/find-history sl
Re: [9fans] Pre-ANSI C
> Which reminds me - I should read Plan 9's source. At least the kernel. > > Any pointer about where to start? I tried with the boot code, but it > jumped around a lot and I lost track of it. Francisco Ballestros (nemo) wrote a guide to the 3rd Edition kernel source code: http://plan9.stanleylieber.com/_books/comp/plan9/Notes.On.The.Plan.9.3rd.Edition.Kernel.Source.pdf It's a bit outdated at this point, but is still helpful to understand what's going on. sl
Re: [9fans] u9fs sources
> Hi, anybody knows where the u9fs sources are currently maintained? > > I have just found https://bitbucket.org/plan9-from-bell-labs/u9fs but it's > only linked by an old googlecode repo: I was unable to find any official > link in the bell labs pages. I don't think it is currently maintained, but Plan 9 ships with a copy of it under /sys/src/cmd/unix. I used that as the basis of the OpenBSD port. sl
Re: [9fans] On Linux, what is the rc init file?
Take a look at $PLAN9/rcmain. sl
Re: [9fans] p9p on openbsd/amd64
Hi, I am using p9p for some time now, and I find very difficult to work without it. I have a box with openbsd/amd64 installed and I would like to have p9p on it. Can someone explain to me, in a more or less detailed fashion, what should I do to compile and run p9p on such machine? I wrote many c programs in my life, some of them useful for myself, but I do not know how to port software. Saludos, Plan9port is in the OpenBSD ports tree. You can either install the package or build the port from source. More information here: http://www.openbsd.org sl
Re: [9fans] Wildly off-topic
So my question is, did there ever exist an edition of KR in that colour scheme, or is gcc to blame for the inaccuracy? The old web page for the book had a nice collection of covers from around the world: http://9p.io/cm/cs/cbook/index.html sl
Re: [9fans] inequality testing in shell
TEST(1) TEST(1) NAME test - set status according to condition SYNOPSIS test expr DESCRIPTION Test evaluates the expression expr. If the value is true the exit status is null; otherwise the exit status is non-null. If there are no arguments the exit status is non-null. The following primitives are used to construct expr. -r fileTrue if the file exists (is accessible) and is readable. -w fileTrue if the file exists and is writable. -x fileTrue if the file exists and has execute permis- sion. -e fileTrue if the file exists. -f fileTrue if the file exists and is a plain file. -d fileTrue if the file exists and is a directory. -s fileTrue if the file exists and has a size greater than zero. -t fildes True if the open file whose file descriptor num- ber is fildes (1 by default) is the same file as /dev/cons. -A fileTrue if the file exists and is append-only. -L fileTrue if the file exists and is exclusive-use. -Tfile True if the file exists and is temporary. s1 = s2True if the strings s1 and s2 are identical. s1 != s2 True if the strings s1 and s2 are not identical. s1 True if s1 is not the null string. (Deprecated.) -n s1 True if the length of string s1 is non-zero. -z s1 True if the length of string s1 is zero. n1 -eq n2 True if the integers n1 and n2 are arithmetically equal. Any of the comparisons -ne, -gt, -ge, -lt, or -le may be used in place of -eq. The (nonstandard) construct -l string, meaning the length of string, may be used in place of an integer. a -nt bTrue if file a is newer than (modified after) file b. a -ot bTrue if file a is older than (modified before) file b. f -older t True if file f is older than (modified before) time t. If t is a integer followed by the letters y(years), M(months), d(days), h(hours), m(minutes), or s(seconds), it represents current time minus the specified time. If there is no letter, it represents seconds since epoch. You can also concatenate mixed units. For example, 3d12h means three days and twelve hours ago. These primaries may be combined with the following opera- tors: ! unary negation operator -obinary or operator -abinary and operator; higher precedence than -o ( expr ) parentheses for grouping. The primitives -b, -u, -g, and -s return false; they are recognized for compatibility with POSIX. Notice that all the operators and flags are separate argu- ments to test. Notice also that parentheses and equal signs are meaningful to rc and must be enclosed in quotes. EXAMPLES Test is a dubious way to check for specific character strings: it uses a process to do what an rc(1) match or switch statement can do. The first example is not only inefficient but wrong, because test understands the pur- ported string -c as an option. if (test $1 '=' -c) echo OK # wrong! A better way is if (~ $1 -c) echo OK Test whether `abc' is in the current directory. test -f abc -o -d abc SOURCE /sys/src/cmd/test.c SEE ALSO rc(1) BUGS Won't complain about extraneous arguments since there may be arguments left unprocessed by short-circuit evaluation of -a or -o.
Re: [9fans] Ports tree for Plan 9
this doesn't seem like motiviation to rewrite awk. there must be another reason? I think rewrite is a mischaracterization (nobody is talking about re- implementing the awk interpreter), so arguing against that seems to be beside the point. Probably, port awk to Plan 9 without using APE is more accurate. From memory, the awk is not a native Plan 9 program problem has been discussed a few times on 9fans. Googling, I found the following message, which describes some of the issues raised: https://www.mail-archive.com/9fans@cse.psu.edu/msg17798.html by the way, thinking a bit bigger, what i'd like to see is x, where x is to awk as rc is to the bourne shell. The ssam (stream interface to sam) script from plan9port is heavier than awk by itself, but can be useful for a lot of the same tasks. sl
[9fans] test
test
Re: [9fans] unexpected tabs in man pages after font change
Well, while a bit offtopic... what do you mean by programmatically. Programmatically = using a program. If you arrange your troff sources in a thoughtful way, you can perform changes using scripts or other programs without needing to stare at each line of source individually. (I realize that not all man pages conform to such a style). For example, changing all instances of bold text to italic, without needing to hand-edit each instance manually. This is the opposite of what you see is all you get. And btw, programs don't write man pages... yet. Are you familiar with the conventions that power godoc? sl
Re: [9fans] once more: drawterm osx-x11 on x86-64
On Sat, 28 Feb 2015 09:18:24 +0100 cinap_len...@felloff.net wrote: i ment in the context of rio resize. Presumably he means his carefully laid out rio windows get out of kilter (or alignment) when they all get resized. You need a layout engine to keep them looking nice and proportionate. I think the idea is it's best if the trouble report includes a coherent description of the problem, so strangers don't have to guess. sl
Re: [9fans] wstat and atomic directory change
But why we don't have Tmove for example? http://9front.org/img/9tmove01.png sl
Re: [9fans] Installing Go in Plan 9 on the Raspberry Pi.
In case it wasn't entirely clear, go for arm does not currently work on Plan 9. sl
Re: [9fans] Debian bug 737206 - rc shell uses insecurely /tmp
Aren't they talking about rc when running on their operating system? sl
Re: [9fans] Adding a new user.
I think the doc about adding a new user is outdated (or it's just me that can't make it work properly) so I would be very grateful if someone could describe the steps of adding a new user in terms so that even I can understand. Thanks a lot! Which doc? What steps did you take? What happened when you tried? sl
Re: [9fans] Adding a new user.
The following is 9front-specific but is still generally useful: http://code.google.com/p/plan9front/issues/detail?id=207 sl
Re: [9fans] using plan9 as the only system!
The only development you could possibly do is anything with C...and a few scripting languages ported through APE. It's trivial to import file systems from non-Plan 9 systems and manipulate their files using standard Plan 9 tools. It's trivial to connect to non- Plan9 systems from Plan 9 using SSH and run whatever scripts or compilers are necessary to complete the write-build-test cycle. Do you even use Plan 9? What do you use it for? sl
Re: [9fans] can't install 9front kernels
Try removing the old 9bootfat before copying the new one into place. sl
Re: [9fans] Print Screen?
Is it possible to print the screen in Plan 9? topng /dev/screen screen.png sl
Re: [9fans] Change font in Abaco
I've tried multiple ways to change the font in Abaco but failed. Check out the example file /sys/src/cmd/abaco/abaco.fonts. Copy this to $home/lib and edit it to suit. sl
Re: [9fans] atexit() atexitdont()
How can i send a patch to 9front? You can file an issue and link to your patch here: http://code.google.com/p/plan9front/issues/list Or you can sign up for the 9front mailing list and post there: http://9front.org/lists.html sl
Re: [9fans] Persistent font in Acme.
I like the idea of making a small script but I couldn't make it work. What I want is to get this to execute without to much typing: term%acme -f /lib/font/bit/lucidasans/latin1.10.font and that's it. Any suggestion for a script and how to execute it would be most appreciated. Anything you type into the shell that produces the desired result is a valid shell script. So, you could make a script $home/bin/rc/a: #!/bin/rc acme -f /lib/font/bit/lucidasans/latin1.10.font Do chmod +xr $home/bin/rc/a and then run it by just typing a. sl
Re: [9fans] Persistent font in Acme.
Thanks for your input. I tried something similar and got an error message. I tried your suggestion and got the same error message. It says: rc: /bin/a:3: token EOF:syntax error. So something else must be added. Thanks! Make sure the file ends with a newline. My example works on my system. sl
Re: [9fans] [acme] Edit command -- More than one argument?
Yes you can. That's how I verified this works. Open up the tag to multiple lines (just type newline in the tag). I think this only works in p9p. sl
Re: [9fans] silly question
The wikipedia entry on leap second is quite instructive. It is now. sl
Re: [9fans] Plan9 Server Down
This was the long version. Thanks. I was wondering if you were operating with some greater knowledge of the setup at Bell Labs than is available to the general public, or if your demand to reboot the server was just a generic phrase. I have no inside knowledge, but it's likely the server is more than one machine, and we don't know what or where the problem is. Anyway, thanks for pointing out the website was not working. sl
Re: [9fans] The developers of Plan9 think there was no point in coding in binary code three years ago as they did or make the Riga Technical University and University of Latvia?
i've forwarded your request to SP9SS (i may be missing an S in there somewhere) for their immediate attention. they assure me it will be taken up at the next special session of the central committee. My topic has been moved to another list? If my topic has been moved to another list, please give me the link of my topic that was moved. this was an inside joke. you are not expected to understand this. these aren't the amd64 kernels you're looking for sl
Re: [9fans] Strange VGA thing
A68N-5000 motherboard which I'm using it for vesa mode of1400x1050x16 size.
However, there is /dev/realmodemem, but no /dev/realmode.
My plan9.ini file has monitor=vesa line.
Strange!
Why I can have working screen with 1400x1050x16?
The /rc/bin/termrc script does this:
@{
rfork n
if(~ $monitor vesa)
aux/realemu
aux/vga -l $vgasize
}
so realemu is most likely not running in your namespace.
9front-ow...@ttr.inri.net is working?
The correct way to subscribe to the 9front mailing list is to
send a message with a body that just says subscribe (no quotes)
to 9front-ow...@9front.org. After subscribing, list messages are
sent to and received from 9fr...@9front.org.
sl
Re: [9fans] Strange VGA thing
realmodemem file is provided by the '#P' kernel device. realmode file is provided by aux/realemu. 9/pc/devvesa.c has both of them. My interesting poit is why I have 1400x1050x16 display which should be vesa mide. The workings of realemu are explained in the realemu(8) man page. Basically, the realemu program provides the /dev/realmode synthetic file. sl
Re: [9fans] Welcome to the 9fans mailing list
I learned about plan9 a couple days ago, and I'm impressed. But I do have a couple questions: A lot of information (a links to more) is collected here: http://code.google.com/p/plan9front/wiki/fqa sl
Re: [9fans] booting 9pi terminal for 9front server
If I choose 9front machine as for network file/auth/cpu server (cwfs), and try to boot Richard's 9pi terminal (fossil) but root from the server, can I do it? Yes. sl
Re: [9fans] kbdputc() in devcons.c in 9front?
http://9front.org/img/9kbdfs01.png
Re: [9fans] Two Acme questions
you'd need to backport p9p acme to plan 9. This has been done for 9front. Some additional features were implemented in 9front's copy of Plan 9 acme, but it's not accurate to say p9p acme was backported to 9front. sl
Re: [9fans] simplest disk filesystem
It just seems like creating a fake os (as in, no one even intends to use this os) from scratch in order to explain a real os (as in, the goal is to finally understand or at least use this os) makes things even more difficult to understand. sl
Re: [9fans] Kabini or Raspberry Pi?
https://docs.google.com/document/d/1Drn3lm0g7C2zdzOj5x9hvhgVln13JoSx-zs_z1KEztI Do you have a version of this document that is accessible from Plan 9? sl
Re: [9fans] Kabini or Raspberry Pi?
/n/sources/contrib/forsyth/Plan9ServeronEC2.pdf Thanks! sl
Re: [9fans] For the more esoteric mind...
Feel free to borrow any of the images from here: http://9front.org/propaganda/ sl
Re: [9fans] 2014 hardware overview
http://code.google.com/p/plan9front/wiki/KnownWorkingHardware http://plan9.stanleylieber.com/hardware/ sl
Re: [9fans] long paths in acme tags
If one can define a variable in acme foo=/a/very/very/very/very/very/very/very/very/very/long/path/to/a if the acme tags show $foo/file1 $foo/file2 it would be much nicer. Has anyone considered doing this or is there a better idea? I suppose on plan9 one can use bind for this but on p9p things get considerably clunkier (9p, fuse...) when a variable can do the job more simply. this was done in wily in the mid 90s, complete with an algorithm to find the shortest representation. What was the result? In which distribution is it available? How is it used? sl
Re: [9fans] long paths in acme tags
this was done in wily in the mid 90s, complete with an algorithm to find the shortest representation. What was the result? In which distribution is it available? How is it used? wily was a stand-alone unix program. iirc it relied on the frame library port from plan 9. Sorry, my fault, I somehow missed wily in your original reply. sl
Re: [9fans] glenda at 3200x1800x32
So here is another proof that plan9 can run on recent hardware, including beautiful notebooks :) Is any more specific information available about the manufacturer and model of the laptop? sl
Re: [9fans] What is Plan9 exactly?
http://code.google.com/p/plan9front/wiki/fqa0 sl
Re: [9fans] VirtualBox, Mavericks, and Plan 9
I was under the understanding Plan 9 didn't work under VMWare... http://plan9.stanleylieber.com/vmware/img/fusion.png sl
Re: [9fans] syscall 53
i use a derivative of nemo's patch system. Where is this in the 9atom tree? Did you replace the old patch(1) entirely? sl
Re: [9fans] [GSOC] plan9 which arch code to use?
if everybody does their own thing, perhaps we spend all our collective time doing the same thing, and no progress is made? Most of the duplicated effort never seems to make it out to the public, so for users, the point is often moot. The forks of Plan 9 exist mainly because people want to run Plan 9 on their computers. sl
Re: [9fans] [GSOC] plan9 which arch code to use?
The forks of Plan 9 exist mainly because people want to run Plan 9 on their computers. would be nice to put all the hardware support together. It's all available for anyone to take from the public repositories. I don't think any of the forks have placed additional restrictions on what can be done with their changes. Enjoy. sl
Re: [9fans] [GSOC] plan9 which arch code to use?
you're missing my point. it's not particularly useful as a tinker-toy set. especially when there are 10 wheels and 1 stick. What I know is that I turn on my Thinkpad x230 and everything works. After the boot process finishes I just carry on with my work. sl
Re: [9fans] [GSOC] plan9 which arch code to use?
What I know is that I turn on my Thinkpad x230 and everything works. After the boot process finishes I just carry on with my work. sure that's fine. but if everyone does that, plan 9 will fall into disrepair, because nobody's willing to do the work. What are you talking about? If everyone fixes Plan 9 to work on their computers then Plan 9 will fall into disrepair? What has changed is this: Code is being made available because some people decided to make their code available. Notice the key phrase: make their code available. Anyone can take that code and do with it whatever they want. The major result is that now Plan 9 now runs on more computers. Some bugs got fixed. Some new (useful) programs got written. These things only happened because those people made their changes available. Otherwise, we wouldn't even know it had been done. I have trouble seeing this as a net loss. On the other hand, innuendo about code that may or may not ever be released doesn't help anyone, and at this point serves as little more than the traditional way to end a conversation. By now this tradition is decades old. Feels great! I agree with you that over 9,000 private projects that don't communicate with each other and keep their results secret don't result in progress. You can tell because the definition says that the results are kept secret. The difference between that and what is happening with the forks is that the changes made by the forks (including your own) are available for anyone to read, use, adopt -- or not -- at their own discretion. The important morsel to digest here is that the code is out there for people to evaluate. It's not just a legend. Not just a rumor. You can read it, compile it, run it; then decide what to do with it. Again, I have trouble seeing why this is a problem, or how it makes the situation worse than what we have already lived with since long before the forks came into existence. I hope everyone gets good use out of whatever Plan 9 code they manage to load onto their computers. I enjoy using Plan 9 and I enjoy talking to people who are still working on Plan 9. If you want to keep secrets, keep them. But nothing done by any of the forks is secret. Just take the code and do with it what you will. Why is this controversial? sl
Re: [9fans] [GSOC] plan9 which arch code to use?
Why is this controversial? Because you're missing the point, and arguing against a position nobody holds. The original post (in its way) was asking for advice about an amd64 kernel that is not publicly available. Some people (not knowing the full situation) offered advice about publicly available amd64 kernels and were shot down. Everything else follows from that. I agree, it's a bit muddled at this point, but I've been responding directly to things people have said. The mailing lists for each fork are open to the public. E-mail addresses of principles are all known. The only people who aren't at the party are the ones who haven't bothered to show up. Again, where is the problem? Are we supposed to hire professional coordinators to make the process seem more official? It seems to me the sort-of-articulated complaint is that all of this work is not being conducted under the watchful eye of a centralized authority. Do you mean something like patch(1)? With work being coordinated by staff at Bell Labs? What some folks are suggesting is that some coordination would yield better results; that we can do better than the everyone going off and doing their own thing part of the above scenarios. People working on the forks are in constant contact. How could the situation be improved? My observation was that secret code helps no one. Maybe the code is not really secret, but is instead held up somewhere in the coordination process. For years, and years, and years at a time. sl
Re: [9fans] [GSOC] plan9 which arch code to use?
Dan Brown low blow
Re: [9fans] [GSOC] plan9 which arch code to use?
No, it wasn't. There was some confusion over the point that Plan 9, unlike some other systems, selects the arch based entirely on the running kernel (no 386 binaries running on amd64 machines). Do you recall the reason this guy is even trying to install Plan 9? Kernel hacking. Once he builds the amd64 userland, what does he do with it? What would be the next step in making use of that userland? Obviously, not booting a 386 kernel. My comments followed the context of the conversation from its inception and were relevant to the replies therein. The back-and-forth with Erik (and later, you, Charles, etc.) branched out into other territory, but this whole thread is based on a new guy being given weirdly cryptic responses in reply to very basic confusion that is easy to clear up if we just put together words in an obvious manner and speak clearly. If it's silly to suggest one of the forks, then it's equally silly to pretend an amd64 kernel is on the table at all. The chain was this: prospective kernel hacker asks about amd64 - receives accurate answer - someone says no, no - explanation of building amd64 userland (with non-Labs code) - last minute revelation of relevant facts - someone points out that secrets, by definition, are not generally known - someone denies the obvious, casts aspersions on the forks - weird accusations - denials - arguing - complaints - this message When did anyone plan on telling this guy that an amd64 kernel is not even on the table? Remember: The argument against investigating one of the forks was that he should stick close to the Labs distribution, right? When I said that people weren't aware of the full situation, I was referring to the fact that nobody seemed to be aware this guy had made prior arrangements to do work on Charles' non-Labs code. He asked a common question about amd64 (ignoring for a moment the confusion about the difference between VM host and guest CPU as seen by the guest OS) so people gave him relevant answers. Then we stepped on the apparent land mine. Now it's the fault of forks for existing. All because nobody could just say: Hack on the 386 kernel because nothing else is in the official distribution yet. Why is this stuff always so difficult? sl
Re: [9fans] [GSOC] plan9 which arch code to use?
It's worth remembering that the only reason there was ANY available code for the amd64, and initial kernel code to boot, was because Thank you Charles, and everyone else involved. Because of your contributions I'm able to run cinap's pc64 kernel on my x86_64 machines. I'll say this again just because it seems to keep getting missed: That work was only available to us because you made it available. sl
Re: [9fans] [GSOC] plan9 which arch code to use?
your options are 9atom or 9front. well no, no they aren't. What are the other options? sl
Re: [9fans] (no subject)
1.3
edid mfrdate2010.0
edid size (cm) 28x16
edid gamma 2.20
edid vert (Hz) 0-0
edid horz (Hz) 0-0
edid pclkmax0
edid flags digital standby suspend activeoff
edid 1366x768@60Hz
clock=75.2
shb=1414 ehb=1478 ht=1582
vrs=772 vre=779 vt=792
hsync=+ vsync=-
---
Intel HD Graphics 4000 (not sure of VID/DID)
@{rfork n; aux/realemu; aux/vga -p}
vesa flagUlinear|Hlinear|Fsnarf
vesa sigVESA 3.0
vesa oemIntel(R) Sandybridge/Ivybridge Graphics Chipset Accelerated
VGA BIOS 1.0
vesa vendor Intel Corporation
vesa productIntel(R) Sandybridge/Ivybridge Graphics Controller
vesa revHardware Version 0.0
vesa cap 8-bit-dac
vesa mem67043328
vesa mode 0x105 1024x768x8 m8 packed
vesa mode 0x117 1024x768x16 r5g6b5 direct
vesa mode 0x118 1024x768x32 x8r8g8b8 direct
vesa mode 0x112 640x480x32 x8r8g8b8 direct
vesa mode 0x114 800x600x16 r5g6b5 direct
vesa mode 0x115 800x600x32 x8r8g8b8 direct
vesa mode 0x101 640x480x8 m8 packed
vesa mode 0x103 800x600x8 m8 packed
vesa mode 0x111 640x480x16 r5g6b5 direct
vesa mode 0x17d 1366x768x8 m8 packed
vesa mode 0x17e 1366x768x16 r5g6b5 direct
vesa mode 0x17f 1366x768x32 x8r8g8b8 direct
edid mfrLGD
edid serialstr
edid name
edid product728
edid serial 0
edid version1.3
edid mfrdate2012.0
edid size (cm) 28x16
edid gamma 2.20
edid vert (Hz) 0-0
edid horz (Hz) 0-0
edid pclkmax0
edid flags digital standby suspend activeoff
edid 1366x768@60Hz
clock=75.2
shb=1414 ehb=1478 ht=1582
vrs=772 vre=779 vt=792
hsync=+ vsync=-
---
sl
Re: [9fans] (no subject)
In my experience a VESA BIOS will sometimes report different available modes depending on the detected EDID. I have no problem believing this is true, but I'm also sure there's more to it than that. I agree. One problem is that these things are all different, almost completely undocumented, and implement non-standard modes seemingly at random. Some people involved with various OSX86[0] efforts have developed methods for probing (and in some cases, modifiying) the VESA BIOS on some cards. All kinds of strange behaviors have been observed. I'd be interested in a survey with broader results than just dueling anecdotes I haven't made any attempt to catalogue VESA vs EDID discrepancies, but I do keep a small archive of hardware info here: http://plan9.stanleylieber.com/hardware We try to collect the sysinfo[1] output for as many systems as possible, for later reference. sl [0] http://www.osx86project.org [1] http://man.aiju.de/1/sysinfo
Re: [9fans] [9front] enabling authentication on a cpu server.
I setup a 9front cpu server, and configured a netboot setup so that I can boot into it remotely, but it does not ask for a password for my users, and infact, I can't seem to set one ether. This description is somewhat confusing. Are you attempting to cpu into your cpu server, or are you attempting to boot a machine from it over the network? Do you understand the difference? Just wondering if there was a guide I missed https://code.google.com/p/plan9front/wiki/fqa sl
Re: [9fans] [p9p] restart program on Acme Load
You could put your long command line into a shell script that takes no arguments and run that shell script from acme's tag. sl
Re: [9fans] Adding a new user on 9-Front
The above echo command did nothing to the /adm/users file for me on vanilla 9front. Has anyone verified that he's even running cwfs? sl
Re: [9fans] Adding a new user on 9-Front
There is value in a community. What remains of Plan 9 might be a better example of failing to seek out community in order to preserve the value, which is sometimes not clearly perceived by the interested few who show up at the party. Conversely, UNIX diverged from its original design philosophy and was adopted by progressively larger communities, finally becoming something of a global standard, where it still enjoys great popularity. What remains of UNIX is sometimes difficult to recognize. http://harmful.cat-v.org/cat-v sl
Re: [9fans] Adding a new user on 9-Front
What remains of Plan 9 might be a better example of failing to seek out community in order to preserve the value, which is sometimes not clearly perceived by the interested few who show up at the party. isn't this a false dichotomy? rudeness doesn't preserve value. The TUPE[0] -related material is a valuable reference point in this discussion specifically because it's all thirty years old. This tension between technical and social pressures is nothing new. I'm not specifically advocating rudeness, but it's worth pointing out that more than one book written by former Bell Labs staff specifically accuses our 1127 heroes of indulging in precisely this sort of conceitedness (not my word) and condescension towards outsiders. I bring this up only to illustrate what people choose to focus upon, and what they choose to ignore. The complaints are always the same, whether it is Rob Pike or Theo de Raadt who has made someone cry. The objections, -- no, demands -- are always the same sort of I'm new new guy, treat my bad ideas as if they were good ideas, or I'll tell everyone you're a jerk attempts at social extortion that are familiar to anyone who has ever worked on an open source software project. Worse, now, as community has become the central concern of many such projects. How many times have you seen someone declare that they refuse to use OpenBSD simply because Theo made some crazy remark? This is the level at which the discourse occurs. Meanwhile, there is the code. Which operating system with lots of developers and lots of users is not terrible? Do we posit some connection between the social structure of operating system development (as we've observed it) and the end result? What are the lessons learned? Ken referred to open source as open sewers. Theo runs his project with an iron fist, and if you don't like it, you're free to spend your time somewhere else. Neither of these attitudes are conducive to the type of inclusiveness sought after by those who concern themselves primarily with community. In the case of Bell Labs, their code was not even widely circulated to the general public for much of the period in question. Thought exercise: Try to recall how gladly fools were suffered in the early days of the 9fans mailing list. At some point, you have to stop entertaining the bad ideas and work on the good ones, even if that makes some people unhappy. This is how we got UNIX (and later, Plan 9) in the first place. It is possible this perspective has been expressed more gracefully elsewhere. What remains of UNIX is sometimes difficult to recognize. it's easy to point out past mistakes. do you think these were obvious at the time they were made? The class of mistakes we are dealing with today were not acknowedged in 1983 and are still not acknowledged today. The entire software tools philosophy was rejected, long ago, and as Rob pointed out, perl delivered the elegy. This is rendered obvious when a longtime UNIX user tries out Plan 9 for the first time. Go on, I'm sure you can predict the first several complaints that will be voiced. Was this rejection intentional? Did they (the perpetrators) really disagree with the perspective of the UNIX authors, or were they simply ignorant of the arguments being presented? I certainly was, until the existence of the documents I keep linking to was brought to my attention. In your experience, how well does the average UNIX enthusiast understand these ideas, and how are they received, when explained? Well, there are hordes of these people at the gate, and they are insisting that we honor their demands as a matter of course. All of their bad ideas MUST go into the system. NOW. Or else you're a jerk. What? You think our ideas need more time to develop? That's not a very nice thing to say. I demand that you take us seriously, RIGHT NOW. Gee, you guys think you're so smart! Your privilege is showing! What if we open the gate, just a crack... The whole question of rudeness is based upon the false premise that it makes sense to treat each new airing of a bad idea as if it were the first expression of a potential breakthrough. Limited resources are quickly consumed by public relations. Projects that have produced material of value typically eschew these exercises in favor of doing the real work. sl [0] The UNIX Programming Environment, by Brian W. Kernighan and Rob Pike
Re: [9fans] mk time-check/slice issue
Just a newbie's (with 35 years experience) perception. It sounds like you're saying that you came on the scene around the time UNIX diverged from sanity and devolved into madness. sl
Re: [9fans] Acme: fonts
still a bit pixilated 1 bit fonts are legible. this is a feature. sl
Re: [9fans] Acme: fonts
Those look like mine. Obviously it is highly usable, but the fonts shown are pixilated and not smooth like fonts that come with the Mac, Linux, etc. It's a matter of taste, but I prefer the sharpness of the 1 bit fonts. The gray, fuzzy stuff eventually takes a toll on my eyes. sl
Re: [9fans] Acme: fonts
It's a matter of taste, but I prefer the sharpness of the 1 bit fonts. The gray, fuzzy stuff eventually takes a toll on my eyes. s/taste/eyesight/, perhaps? Perhaps, but I like to think differences of opinion don't necessarily indicate physical disability. sl
Re: [9fans] Acme: fonts
When I began using acme, sam, 9term, I much cared about ttf fonts. But I, too, have come to prefer the sharpness of the 1 bit fonts. A running joke is that prolonged used of Plan 9 damages your eyesight until you no longer care what anything looks like. Presumably, at this point, lucm/unicode.9.font is welcome simply because the runes are large enough to distinguish on screen. Rob planned for the future. sl
