[9fans] The CW font with Lucidasans
Mixing \f(CW with '.FP lucidasans' results in text that is wildly out of proportion. To my eye, the CW font needs to be scaled down by about 1.5 points to visually match the surrounding text (at the -ms default point size). I'm curious if this has annoyed anyone else enough that they've come up with a work-around. --lyndon
[9fans] dformat
Anybody have a copy of dformat online? For the 4th time I've lost mine, and I don't relish typing it in yet again from the Labs TR ... --lyndon
Re: [9fans] dformat
Sweet -- thanks! (That wasn't there the last three times ...) --- Begin Message --- > Anybody have a copy of dformat online? http://www.troff.org/source.html -Steve --- End Message ---
Re: [9fans] The CW font with Lucidasans
> And then use .EX and .EE around code examples (concept > lifted from the man macros). For offset code CW seems fine. My problem involves imbedding CW inline. E.g. .TS tab(#); l0w(.1i) l0w(.1i) lw(.1i) l . \&...#/##Message store root. #/1##A message in the root folder. #/2##\f2Ibid.\fP #/stuff#/#Subfolder \f(CW\s-1stuff\s0\fP under the root folder. #/stuff#/!index#The metadata cache for the subfolder \f(CW\s-1stuff\s0\fP. #/stuff#/29#A message in subfolder \f(CW\s-1stuff\s0\fP. #/stuff#/42#\0\0\0... and another. #/stuff#/more/...#Subfolder \f(CW\s-1stuff/more\s0\fP. .TE Without the \s-1 CW is way out of whack proportionally, due to its large x-height. Shrinking by a point (as above) still looks out of whack, but it's less likely to make me barf. Fractional point size changes would be nice, but what I really want here is the ability to add a global scaling factor to a specific font (position). --lyndon
Re: [9fans] new sources
> Please try it out and see if it looks like sources from your > perspective. You may want to change your authdom declaration for > outside.plan9.bell-labs.com in /lib/ndb to Geoff, I did a walk of /n/sources/contrib and /n/haggis/contrib, and the latter is missing quite a few files: 48257 48260 2624325 contrib 41701 41704 2260692 haggis 89958 89964 4885017 total Which could be because you haven't synced the current contrib tree. I don't see any difference in performance between the two (from roughly 92 milliseconds away on the net). --lyndon
Re: [9fans] new sources
> Please mail reports, good or bad, to me, not 9fans; > there's no need to add to the volume of traffic on 9fans for this. How about we convince the mailing list software to stop inserting Reply-To headers.
Re: [9fans] nice quote
> is this english++? i just can't parse it. If we all ignore him he might go away ...
Re: [9fans] nice quote
> relax If I want platitudes I have the whole rest of the internet to gorge on. Here we try to do actual content.
Re: [9fans] Authoritative Name Server
You don't need to do anything special for BIND to slave from your Plan9 master. I have a BIND slaving from a Plan 9 master without any issues. On the Plan 9 master, start ndb/dns with the -n flag, and add dnsslave entries to /lib/ndb/local for each of your slave hosts. Here are the relevant entries from my /lib/ndb/local. Gandalf is the Plan 9 DNS master, legolas is the BIND slave. dom=yyc.orthanc.ca soa= refresh=3600 ttl=14400 ns=gandalf.yyc.orthanc.ca ns=legolas.yyc.orthanc.ca mbox=lyn...@orthanc.ca dnsslave=legolas.yyc.orthanc.ca dom=0.168.192.in-addr.arpa soa= refresh=3600 ttl=3600 ns=gandalf.yyc.orthanc.ca ns=legolas.yyc.orthanc.ca mbox=lyn...@orthanc.ca dnsslave=legolas.yyc.orthanc.ca Also, make sure /rc/bin/service/tcp53 is enabled on the DNS master host and that the slave can get a connection to it; the slave needs a TCP connection to the master to do the zone transfer. --lyndon
Re: [9fans] Authoritative Name Server
> linux$ dig @ns1.nanosouffle.net _jabber._tcp.mail.nanosouffle.net srv > ;; Warning: Message parser reports malformed message packet. Is ns1 the Plan9 master? What do the zone files on the BIND slave look like? I.e. did the SRV entries transfer correctly?
Re: [9fans] awk help; not plan9 matter
> The trouble with this is that the same string can appear more than > once (before, after the field, ...), so the simple substitution isn't > enough. It's sounding like awk is the wrong tool. It should be trivial to code up a short piece of C to do the job.
[9fans] Standalone Hyper-V
Has anyone taken a crack at running a current Plan 9 under Microsoft's standalone Hyper-V distribution? It's been a year and a month since this last came up on the list, and a lot has happened since then ... --lyndon
Re: [9fans] 9vx as a perfect proto environment
> such as the beagleboard, which > are good enough to be a desktop Ethernet? My kingdom for Ethernet on one of those! Is USB Ethernet really viable? It would be nice to hear from anyone actually doing it (with performance numbers). --lyndon
Re: [9fans] HTTP forwarding with aux/trampoline
> is t possible that the path mtu is < 1500 bytes? if > so, trampoline isn't going to forward icmp messages. Trampoline just copies the sequence of data bytes. It doesn't know anything about IP or ICMP datagrams.
Re: [9fans] /sys/include/ip.h 5c(1)
> Varian Data, General Automation, SDS/XDS, DEC, Data General, Honeywell, CDC, > GE I don't think DEC deserves this branding. In my experience they were one of the most open hardware companies around. Back when they were still DEC, of course. --lyndon
[9fans] vga support for Via Unichrome
Is anyone working on Unichrome vga support?
Re: [9fans] vga support for Via Unichrome
> Besides Unichrome, which CPU, RAM, MB & ~bridge chips are you trying to use > it with? > > ISTR having it up on a VIA C3 ~ 700 MHz, 1 GB SDRAM with embedded Unichrome > onboard about 2+ years ago.. It's a 1GHz C7 EPIA mini-ITX board, CN400 chipset (I *think* -- I can't get at it right this second to spot the model number). But I'm interested in Unichrome generically. VESA works fine, but I only want enough native support to make the vncv mouse turds go away. I'm just curious to know if anyone else is working on this and wants to share code/doc/whatever. I'm a couple of weeks away from starting (the hardware is currently occupied doing other things). --lyndon
Re: [9fans] Barrelfish
> I'm not familiar with the berkeley work. Me either. Any chance of some references to this?
Re: [9fans] Parallelism is over a barrel(fish)?
>From last week's ACM Technews ... Why Desktop Multiprocessing Has Speed Limits Computerworld (10/05/09) Vol. 43, No. 30, P. 24; Wood, Lamont Despite the mainstreaming of multicore processors for desktops, not every desktop application can be rewritten for multicore frameworks, which means some bottlenecks will persist. "If you have a task that cannot be parallelized and you are currently on a plateau of performance in a single-processor environment, you will not see that task getting significantly faster in the future," says analyst Tom Halfhill. Adobe Systems' Russell Williams points out that performance does not scale linearly even with parallelization on account of memory bandwidth issues and delays dictated by interprocessor communications. Analyst Jim Turley says that, overall, consumer operating systems "don't do anything smart" with multicore architecture. "We have to reinvent computing, and get away from the fundamental premises we inherited from von Neumann," says Microsoft technical fellow Burton Smith. "He assumed one instruction would be executed at a time, and we are no longer even maintaining the appearance of one instruction at a time." Analyst Rob Enderle notes that most applications will operate on only a single core, which means that the benefits of a multicore architecture only come when multiple applications are run. "What we'd all like is a magic compiler that takes yesterday's source code and spreads it across multiple cores, and that is just not happening," says Turley. Despite the performance issues, vendors prefer multicore processors because they can facilitate a higher level of power efficiency. "Using multiple cores will let us get more performance while staying within the power envelope," says Acer's Glenn Jystad. http://www.computerworld.com/s/article/342870/The_Desktop_Traffic_Jam?intsrc=print_latest
Re: [9fans] automatic page sharing
> contrast /386/bin/sleep, a non-trivial
> executable, at 4422 bytes on my system — 100x smaller.
#include
#include
int main(void){exits(nil);}
is 3317 bytes on my atom box.
[9fans] bio(2) and ORDWR
bio(2) doesn't support files opened for read+write; Looking at the implementation I don't see why it couldn't. Was this excluded for a particular reason? --lyndon
Re: [9fans] rows to cols?
> Is there an easy way to transpose the text so that rows become > columns, and vice versa? Delimiter is space. Perhaps in AWK? If Richard's trick won't work, grab contrib/lyndon/transpose.c. It's dog slow (actually, avl(2) is), but its effectively unbounded for the input dataset size. --lyndon P.S. Never underestimate the power of C.
Re: [9fans] rows to cols?
> i haven't found avl to be slow, so i was interested in > this. It was slow in relation to other methods available. That code wasn't written to be fast. It came out of a long ago Sunday afternoon discussion I had with someone about data structures, from which we ended up cobbling together a few different versions of transpose to get some timings. That was the only version that seems to have survived, so that's the one you got ;-)
Re: [9fans] Where can i get teh code of the Paln 9
> I'll put up a youtube movie in the next while, but there is a video of > iwp9 I think on the subject. And for those of us using only Plan9 to troll the Interweeb, isn't there a one paragraph text summary someplace?
Re: [9fans] 9p resource sharing [was: Scanners]
> linux is actually quite easy and has been for about 12 years or more > ... not sure of the others. I was running diskless Windows in 1995; it wasn't pretty, but it could be done. These days you can run XP+ diskless if you have the right Windows Server and installation tools fu.
[9fans] Nan() is hooped?
The following code results in:
8.out 15340: suicide: sys: fp: invalid operation fppc=0x108f
status=0x8081 pc=0x1028
#include
#include
void main(int, char *) {
double foo;
foo = NaN();
exits(0);
}
[9fans] 10ed f77 manpage
Anybody have a 10th Edition f77 manpage they could email me?
Re: [9fans] What do you use plan 9 for?
* Mail client and server (SMTP, IMAP, running mailing lists). * Net infrastructure (DNS, DHCP, FTP, file server). * Long term file storage archive (36GB of iTunes mirror, repository of ISO images for software distributions, documentation archive, and some day soon a copy of my DVD collection). * Document preperation and typesetting. * Data collection, reduction, and presentation from various NMEA devices (GPS, Loran, depth/speed sensors, VHF, engine) on my boat. * Navigation/autopilot system for the boat (the never-ending project). * Software-defined radios (something like GNUradio or whatever it's called). * Human language processing (crypto analysis tools, spell checkers). * Playing Zork. * Experimenting with graphics programming. * Weather data collection and analysis. * General programming and hacking. * OS research.
Re: [9fans] grap problem
> (I want the data outside the limits to be ignored...) > What am I doing wrong? Not filtering your input data? grap's only intent is to typeset the data you feed it. 'coord' sets the ranges for the graph scales. It doesn't filter the data -- that's your job. (As a typesetting design device I might want to plot data points outside the graph axis limits -- grap rightly doesn't prevent me from doing that.)
Re: [9fans] du and find
> du -a | awk '-F\t' '{print $2}' -
All this nonsense because the dogmatists refuse to accept
/n/sources/contrib/cross/walk.c into the distribution.
Re: [9fans] du and find
> what seems more important to me is a way to unlimit the size > of argv. otherwise we'll need to go down the hideous xargs path. How often have you run up against the current limit? I've yet to hit it in anything other than contrived tests. And even those took work. > find and walk are about the same program. There are a few versions about. Dan's has the exactly right lack of options to meet my needs. Others might too, but his is the version I found first. --lyndon
[9fans] Broken Hardware List
The Wiki's supported hardware list is getting quite moldy. I've created a new page for known broken hardware, working on the theory that people pissed off are more likely to document breakage than the blissful are their success. It's linked from the supported hardware page. --lyndon
Re: [9fans] Broken Hardware List
> i believe that richard miller has the intel D945GCLF2 > working via some careful hacking. (i.e. a hand-coded > mp table.) It was easier to buy something that actually worked. As for that Intel piece of shit, I'm going to blend it during the transition to 2010. --lyndon
Re: [9fans] Broken Hardware List
> i think it would be more valuable to explain exactly what's > not working and point to some of the workarounds, if they exist. What's not working is the ACPI component of the BIOS. The P9 boot fails very early on (right after E820 I think). FreeBSD runs, but something in the ACPI code wakes up every couple of seconds and leaps into the ACPI BIOS code. While it's in there it locks out all hardware interrupts for 2-5 seconds, which makes the box pretty much unusable for anything close to interactive work. As to workarounds, I worked around to the computer store and bought a non-Intel motherboard that actually implements Intel's ACPI spec somewhat correctly. I'm not going to spend time I could be billing out to try to fix a completely braindead motherboard that I can replace for what I earn in an hour or two. Shitty hardware like this deserves to die, not get fixed. --lyndon
Re: [9fans] parallels
> Do you think you'd recommend Parallels over VirtualBox? I've not tried plan > 9 on VirtualBox as I usually opt to run it on real hardware where I can, and > 9vx or drawterm to connect. Forget about VirtualBox. It's nowhere near ready for prime time on MacOS or Solaris. The only thing I've ever succeeded in getting it to run is XP/SP2 (on either platform). (The same applies to xVM on Solaris.) --lyndon
Re: [9fans] Ken Fileserver problem
> From the inspections of Cinap and I, albeit a while back, > Erik's FS does not take NVR from floppy. So is it worth it to try to nail down a driver that can talk to at least some of the on-motherboard NVRAM present on today's crop of x86/amd64 motherboards? There is anecdotal evidence of past individual success. Even an experimental collection of these driver bits would be interesting to play with. --lyndon
[9fans] IWP9 Acid Trips Video
I finally got around to watching Russ' Acid talk, but the video I have end about 26 minutes in -- just into the discussion about kernel debugging. I'm not sure if this was a problem with the source video, or just my copy, which looks like: lyn...@frodo% ls -l IWP*; sha1sum IWP* --rw-r--r-- M 51 lyndon lyndon 148049360 Jul 17 2009 IWP9-Acid_Trips.mov 104355563b8bcc6fc1540086232f018f7d2a4ae8IWP9-Acid_Trips.mov I tried grabbing another copy from 9grid.net but the web server is currently broken. Is there a version out there that includes the complete talk? --lyndon
[9fans] Detecting EOF vs. Interrupt across 9P
Given a foofs which serves the writable file /mnt/foo, is there any reliable way to distinguish between % cat > /mnt/foo type some text and quit ^D % and % cat > /mnt/foo type some text, then change your mind and hit % at the server end? I know I read something about this, somewhere, but I can't find it now. It could very well have been buried in some source I was reading (about Tflush vs. 0 length Twrites or some such?). --lyndon
Re: [9fans] Detecting EOF vs. Interrupt across 9P
Russ says: > i don't believe these two cases can be distinguished. > in particular i think you'd only see the Tflush if the first > Twrite was still in flight when you typed DEL. assuming > the first write had completed before DEL, the two scenarios > are indistinguishable other than the different values being > written. And after more digging through the docs and kernel this seems to be the case. (And it describes the behaviour I'm seeing.) --lyndon
Re: [9fans] In case anyone worries about block hash collision in
> You shouldn't be worried about > an accidental collision. You should be worried about > an intentional collision. Seems to me you should be worried about both.
Re: [9fans] In case anyone worries about block hash collision in
>> Seems to me you should be worried about both. > > let's not get carried away. the odds of accidental > collision are 1 2^80. And being worried about both leads to the choice of SHA-1 as a suitable algorithm. If we weren't worried about it I'm sure some bright light would have picked ROT-13 for performance reasons.
Re: [9fans] NaN, +Inf, and -Inf, constants?
> i suspect the rationale was that, finally, C provided a way
> outside the preprocessor to give symbolic names to constants.
> why restrict that to int?
Because enum's have been int's since their inception?
I'm sympathetic to the underlying need, but making a fundamental
type of the language suddenly become variable does not seem to
be the right way of going about this.
E.g., what is the type of:
enum {
a = 1,
b = 2.4400618549L,
c = 2.44F,
d = "this is weird",
e = 1LL<<62,
} foo;
How on earth do you switch() on it? And what's its sizeof()?
--lyndon
Re: [9fans] NaN, +Inf, and -Inf, constants?
> why does being able to switch on any enum trump > the ability to define constants without #define? Because enum's legacy is that of a 'first class' int-like object, which can be subject to the usual set of int-like operations. switch() is one of those. #define isn't. > if you try, sizeof(foo)==4, but you'll need to remove > 'd' since you can't have a string. you can't switch on > a vlong or float. would be nice, though. Why not a string? If you can extend an enum to include floats, why not an integer representation of a pointer? And yes, I also think switching on vlongs would be useful. > the plan 9 style is never to typedef or name enums. It may not be the style for the Labs, but that's not the case for everyone. The compile time type checking named enums provide isn't something I'd want to lose. > if it were an error to name or typedef an enum > containing non-int members, there would be no > problem. This could work. But I have to agree with Bakul: 'static const' is a much better fit for the language. --lyndon
[9fans] acid tools for tracking leaking fd's
Has anyone cooked up some acid to track leaking file descriptors (ala leak for memory)? --lyndon
Re: [9fans] porting Heirloom troff to plan9
> Has anyone considered / tried to port the Heiroom version of troff? > Has anyone any comment about why doing so would be a bad idea? No sense tossing the baby overboard. But it's worth examining the changes the Heirloom folks have made to see what would make sense to backport. They've certainly done some good work that deserves a look at least. --lyndon
Re: [9fans] acid tools for tracking leaking fd's
> cat /proc/$pid/fd I already know the bloody thing is open :-P I just wondered if someone had come up with some glue to intercept open()/close()/dup()/etc and track the fd's in an acid list, or something similar.
Re: [9fans] Binary format
> Okay, but then (as an admin) you have to know which apps have > to be recompiled. For a small system this might be okay, but > that doesnt scale well ;-o Plan 9 _is_ a small system.
Re: [9fans] What operating systems are the google guys using?
> I think mostly Macs with p9p. The Go(ogle) announcement video combined with running platforms indicate MacOS.
Re: [9fans] exec permission on plan9
> well, you can make it explicit.. path=(/bin) Which really should be the default, or at least path=(/bin .). Putting '.' at the front means that wherever you're cd'ed into a remote directory, every command you run is 9Peeing off to the remote host looking for a command that's most likely not going to be there. When your RTTs get into the 100ms+ range, things quickly get very painful. Fixing path= in /rc/lib/rcmain will make your life a lot happier if you work with a lot of remote 9P mounts. --lyndon
Re: [9fans] seq with hex, octal formats
> using awk is still faster For the curious and lazy ... why is that?
Re: [9fans] Contrib indexes
> Just goes to show why I'm asking for some consolidation :-) Mines better!!! :-)
[9fans] ports duplication
I really think this idea that duplication of things in contrib is bad, is bad (or just a red herring). For ports of big applications (python, say), the amount of work involved is going to self-limit the number of ports right up front. And the ones that do make it will self-select based on the quality of the port. As for the smaller things, I would prefer to see ten different bits of code that achieve the same end vs. just one. Diversity is good, and a broader selection of code gives a bigger field to mine for ideas and concepts. --lyndon
[9fans] ndb and ipv6=
While we're talking about ndb ... what's the status of the ipv6= tag? Last week I was setting up IPv6 on a network and was adding ipv6=2001:... entries in ndb as per the manpages. I lost the better part of a day trying to figure out why the records weren't being propagated to the DNS slaves. I finally figured out that ip= now handles both v4 and v6 syntax, but after reading through the ndb/dns sources it's not clear to me if ipv6= is still being used by anything. Is ipv6= truly dead? If it is I will eradicate it from the code and manpages and send in a patch. If it isn't, the manpages still need an update to make clear what it is -- and isn't -- for. --lyndon
Re: [9fans] ndb and ipv6=
> It's still undecided how to best cope with a mixed v4 and v6 > world. I don't expect the ipv6 attribute to go away. I like the new (to me, anyway) ip= behaviour. parseip() and isv4() provide everything that's needed at the C level to distinguish the two. ndb/dns already does this right thing wrt A vs. . Are you thinking of it as an analog to proto=il, perhaps? Back to my original question: what currently uses the ipv6= tag? We need to update the man pages at least. --lyndon
Re: [9fans] (no subject)
> And there just aren't > enough Plan 9 developers to produce alternatives. Then there cannot possibly be enough to port the auto* abortion.
Re: [9fans] (no subject)
> But there ought to be a sane > alternative and it should not be anywhere as complex. There is: it's called POSIX.
Re: [9fans] (no subject)
> surely your joking, mr. nerenberg! Nope. Over the past 10 years I can only think of one or two projects I did that required platform-specific optimizations outside of POSIX.
Re: [9fans] DNS dynamic update
> (because it supplies the correct info for non-Plan 9 hosts). What info did your hosts need that Plan 9's dhcpd didn't supply?
Re: [9fans] native install
I have three native machines: Supermicro 5015A-H w/500GB IDE: fossil/venti/auth/dhcpd/tftpd Supermicro 5015A-H (diskless): CPU server Via EPIA-EK (1GHz C3 Eden-N processor) (diskless): terminal When I move back onto the boat I will be adding another CPU server with a whack of serial ports that will talk to all the comm and nav gear. For this I'm leaning towards a PC/104+ system; they're small, very low power, and have oodles of I/O expansion capability (like ADCs that can hook up to the engine sensors for things like water/oil pressure and temperature, tank levels, etc.). --lyndon
Re: [9fans] quote o' the day
> You should also add: > http://code.google.com/p/unix-jun72/source/browse/trunk/src/cmd/cat.s Which returns 1062 lines of HTML+Javascript, completely unreadable in Abaco. The irony is stunning. --lyndon
Re: [9fans] quote o' the day
> not to spoil the irony, but that works here. And now it works here, too. Before I was getting a blank window, or one line of "link ref=..." verbiage. Now that I think of it, I was seeing similar behaviour last week from other sites. I wonder if webfs is having problems ...
Re: [9fans] Man pages for add-ons
You're making this way more complicated than it needs to be. For 3rd party stuff, I put the source tree in /usr/lyndon/src/, adjust the mkfiles to install in /usr/lyndon/bin/$objtype, and say 'mk install'. I keep a shadow man tree under /usr/lyndon/lib/man, and then bind it all on top of the system directories: bind -a $home/bin/rc/bin bind -a $home/bin/rcaux /bin/aux bind -a $home/bin/$cputype /bin bind -a $home/lib/man/1 /sys/man/1 bind -a $home/lib/man/2 /sys/man/2 bind -a $home/lib/man/3 /sys/man/3 bind -a $home/lib/man/4 /sys/man/4 bind -a $home/lib/man/5 /sys/man/5 bind -a $home/lib/man/6 /sys/man/6 bind -a $home/lib/man/7 /sys/man/7 bind -a $home/lib/man/8 /sys/man/8 (I use this for contrib packages as well, after getting burned a few times with contrib stuff breaking builds in /sys/src. Rather than use the package tool I copy the sources into $home/src and build as above. The extra work is minimal.) If you need to distinguish between your own and site-wide 3rd-party bits, create a new user to own the public 3rd party code, mirror the above structure, and do the appropriate binds in the system-wide namespace files. The only time I contemplate using a /bin/ subdirectory is when there are significant command name collisions. Over the last 10+ years it's only happened to me once. It's almost always easier to just rename the conflicting file. To use Plan 9 properly you must understand what namespaces provide, and how to manipulate them. --lyndon
Re: [9fans] Man pages for add-ons
> also this method is unwieldy with a many user > system. It is? Why? If a user wants personal source and binaries, they set it up. It doesn't impact me one way or the other. For system-wide stuff I still keep the code in /usr/lyndon/src, but adjust the mkfiles to install directly into the system directories (which is usually the default, anyway). > even on a single user system, doesn't it > suck when you can find a few programs that > are in your own bin? Sorry, I can't parse that this early in the morning.
Re: [9fans] Man pages for add-ons
>> > even on a single user system, doesn't it >> > suck when you can find a few programs that >> > are in your own bin? >> >> Sorry, I can't parse that this early in the morning. > > sorry. forgot "when you're running as the hostowner". I still don't get it. Why would finding things I put in my own bin suck?
Re: [9fans] Man pages for add-ons
> you would not find them. the hostowner, unless that's you, > would be unwise to bind your bin into /bin. They're *personal* binaries. The hostowner doesn't need them.
Re: [9fans] Man pages for add-ons
> in the end everything is easy for those who know > how to do it. And god forbid people actually learn anything.
Re: [9fans] Man pages for add-ons
> multiply by several levels of bindings and it will become > a large mental burden to remember what's available where. Practice says otherwise. The only change to the binds since I set it up (years ago) was adding $home/bin/rcaux->/bin/aux last fall.
Re: [9fans] Man pages for add-ons
> why do you presume i haven't tried this? Because you claim it doesn't work. I have evidence it does work. Arm wrestle at 5? :-)
Re: [9fans] Man pages for add-ons
> Oh, yeah, lets all learn about namespaces and the counterintuitive > things they do and don't do, and compiling and everything to do when > it goes wrong, and a billion other things JUST to save devs having to > work out a good solution! Look, if you're too damned lazy (or stupid) to give yourself a handjob, there are people who will do it for you, for a fee.
Re: [9fans] Man pages for add-ons
> if you want to > find how the modifications to /386/lib/libc.a, you know where that > is. if you bind 100 packages on top of /386/lib, it becomes necessary > to deconstruct namespaces continually. the abstraction of namespace > starts to break down. Dump deals with 'physical' paths; you have to think of history and friends in that light. This is why you can't, e.g., 'history /bin/rc'. This doesn't mean history is broken. Dumps and snapshots are tied directly to fossil/venti/kenfs et al, and work in that context.
Re: [9fans] Man pages for add-ons
> you've got to be able to get at the history to begin > with. *that's* the problem. lyndon's right, history > doesn't work even on the usual union directories. > compounding the problem doesn't seem like the > right way to go. Should history work on /env, too? Dump is tool for a specific type of file server. There's nothing broken here, move along ...
Re: [9fans] Man pages for add-ons
> what's the fileserver behind /bin? Whatever you want it to be. That's the beauty of Plan 9. But if you can't remember how you organized your shit, George Carlin has a number of self-help records ;-)
[9fans] resizing desktops uncer vmware vs. parallels
For ages I've run diskless terminals under Parallels, and aux/vga would quite cheerfully resize the Parallels window to match anything I told it. Recently I had to migrate from Parallels to Fusion. Resizing doesn't work any more. Furthermore, I'm buggered if I can programmatically figure out what combinations of screen size+depth will work in Fusion without making the terminal instance panic. The list archives and the wiki are absent of advice.
[9fans] resizing desktops under vmware vs. parallels
[ Let me try again, this time hitting Post vs |fmt :-) ] For ages I've run diskless terminals under Parallels, and aux/vga would quite cheerfully resize the Parallels window to match anything I told it. Recently I had to migrate from Parallels to Fusion. Resizing doesn't work any more. Furthermore, I'm buggered if I can programmatically figure out what combinations of screen size+depth will work in Fusion without making the terminal instance panic. The list archives and the wiki are absent of advice. Looking at the aux/vga output I also can't parse a set of likely screen dimension values. Has anyone else successfully wrestled with this?
Re: [9fans] Non-VESA video card
> /n/sources/contrib/cinap_lenrek/draw.c Works great -- thanks.
Re: [9fans] opposite of bloom filter
> The purpose is allowing an spooling (store+forward) mail relay > to learn which addresses are not accepted by the actual maildrop > (which is connected by an uucp-link, so no direct smtp chat), > to get rid of the thousands silly error bounces from brute force > attacks on email addresses. Very(!) interesting approach to this. I still transfer large chunks of my mail over UUCP, so this is a problem I face daily. I'd appreciate being kept in the loop for anything you find out. (And collaborating on a solution.) --lyndon
Re: [9fans] opposite of bloom filter
> This requires the remote uucp site to give you a Bloom > filter with all the valid addresses inserted, but that seems > unavoidable. I don't know how the opposite-of-Bloom-filter > approach would work anyway. One problem with this is handling wildcarded addresses. How do you indicate (say) lyndon+* is allowable in a bloom filter, where the '+' is an arbitrary (to the upstream) symbol. One idea I've been looking at is exporting a representation of a trie that can be interpreted by the upstream. --lyndon
Re: [9fans] opposite of bloom filter
> i think the idea of spooling email is largely discredited. It's not a spam avoidance trick. It's how I get around arbitrary blockage of SMTP/submission port injection when I'm not sitting at home. If you read your mail on a laptop, it's the easiest way around all the ISP/Hotel/Public-WIFI filtering nonsense that goes on.
Re: [9fans] opposite of bloom filter
> Tell the accepting site to strip +* from all the email addresses > before checking. There aren't that many cases like that. There aren't many, but at least one that I care about exists. The case is one-off throw away addresses. When I send a message, I generate an address crypto-based on the recipient and the time-frame I expect a response. I don't want mail coming back outside the specified response period. A bloom filter can't do this†. A state machine driven trie can. The acceptance criteria are not relevant. If they can be expressed as part of the restriction list, they are valid. And there are several that I'm not going to get into arguments with people about over their validity. --lyndon
Re: [9fans] opposite of bloom filter
> okay, there must be more to the story. why do you need crypto > secure burner email addresses to avoid spam? If I could tell you that, I wouldn't need them.
[9fans] DMEXCL vs. QTEXCL
Given the overlap between (DM|QT)EXCL, it's not clear to me which of these is considered the authority for indicating exclusive access. devusb.c plays with DMEXCL, devcons.c with QTEXCL. I'm assumed the DMEXCL bit was magically getting propagated down to QTEXCL in qid.type, but I'll be damned if I can find anything in the kernel that actually does anything with either of these bits. WTF am I missing? This should be stunningly obvious. Someone please stun me more than I am :-P My interest is in the context of `Chan's. --lyndon
Re: [9fans] Streaming 9P is out
> thinking about it... why not just let stream() fail and let the program > decide if it makes sense to continue without it? Exactly what I was thinking. If the program requires the semantics of stream(), it should be able to reliably discover when they aren't available.
Re: [9fans] plan9 compatible notebook
> I mean with support for say its every hardware part? You can't even do that with UNIX these days :-p
[9fans] 9doom
Does anyone have a copy of the 9doom code they could put up on contrib?
Re: [9fans] how to make hardware work?
> The documentation is on the wiki, such as it is, and in the 9fans > archives. And /sys/doc/*. Read *everything* under that directory.
Re: [9fans] how to make hardware work?
>> What exactly do you mean, PPP over USB? > Google "PPP over USB". I've googled, red 9fans archive, > wiki and docs before posting here. In theory, your 3G data stick should export a serial device interface, and therefore usb/serial should map it to /dev/eiaUx/eiaUx (where x is a small integer). (See usb(4)). You would then run, e.g., 'ip/ppp -p /dev/eiaU0/eiaU0 ...' (see ppp(8)). --lyndon
Re: [9fans] ARM based terminal?
> There are some newish fanless intel mini-itx motherboards about, anyone > had one of these boot plan9? I had poor results from the previous generation > due to unhelpful BIOS. Try to get your hands on a C3-based board. They tend to predate much of the ACPI crap that has infested the BIOS space these days. I'm typing this on a PXE-booted EPIA-EK system with a 1GHz C3 CPU. While this particular system has a fan on the CPU heatsink, it *never* turns on. My display runs at 1920x1080x16 (VESA mode). --lyndon
Re: [9fans] Modern development language for Plan 9,
> I think it is worth looking at a successor protocol instead > of just minimally fixing up 9p (a clean slate approach frees > up your mind. You can then merge the two later). 9p is fine for what it is. If you want to talk to Mars, a new metaphor is required, not the rape and bastardization of 9p. Mars seems to be any place beyond 100ms reach of 'here'. --lyndon
Re: [9fans] tech writer humor
> apic ids can be found in the madt table, from acpi, iirc. Heh. You assume a correct ACPI BIOS implementation. The worst offenders I've seen have been Intel-designed motherboards :-P
Re: [9fans] tech writer humor
> the madt table or the mp tables reflect a snaphot of *all* > the i/o apics and lapics in the system at the time when bios handed > control over to the operating system (sic.). No it doesn't. That's the bug in the BIOS -- it screws up building the table. I have an Intel mini-ITX board sitting in a box because it's unuseable due to this bug.
Re: [9fans] tech writer humor
> by definition, a bug in your bios doesn't change the specification, True. But a "specification" that doesn't run the same way on any two models of motherboard isn't much of one.
[9fans] git port
Someone in the past few days alluded to a git port. I'll be buggered if I can find the message in the list archives. Does this exist? Where?
Re: [9fans] drawterm dies when my mac book sleeps by 9p design?
> He would get pretty exercised about keep-alives. Felt that it was not > the business of TCP to make these kinds of decisions. I can't remember > if he actually called them an abomination, but at the same time, one > was left with the feeling that he might have. I'm sure he's called them worse than that over the years. And he could not be more right. We have been inflicted with keepalives as a workaround to the only worse abomination on the planet: shitty shitty shitty home NAT routers that have a ten minute attention span. --lyndon
Re: [9fans] troff macros for typesetting books/longer texts
> Just now I am reading "Unix Text Processing" by Dale Dougherty and Tim > O'Reilly, a freely available book (pmartin proposes it as well). There > are several chapters on the topic, so perhaps I'll get what I want in > the end. I was going to mention that one, but I figured it was so long out of print as to be unobtainable. I should know better, though. abebooks.com has found me a wealth of long out-of-print UNIX material. My moment of truly understanding troff was when I stopped thinking of it as a typesetting program, and instead recognized it as a programming language. After that little epiphany, much of the smoke cleared. If you re-read the troff paper in that light, a syntax that initially appears to be line noise magically transforms itself into a concise and elegantly consistent language. There's no denying it's cryptic, though. But once you recognize the consistency of the syntax, it's a marvel to behold. There's no denying it has its warts. Number registers that are strings still offends my sensibilities, but as with irregular verbs, pretty soon you just learn to accept them and carry. But the one bit of troff black magic I still can't get my head around, even after 25 years, is how the hell .wh page-bottom traps are supposed to work :-P As for indexes, the me macro package provides macros for generating index entries: .(x and .)x. You can look in /sys/lib/tmac/tmac.e to see how they are defined. Plan 9 doesn't seem to provide any documentation for the me macros, though. I'm pretty sure Stevens talked about index creation on his web site, and you might want to check Brian Kernighan's web pages as well. --lyndon
Re: [9fans] troff macros for typesetting books/longer texts
> I have only hesitated over the way (as described in my original, 1st, > post) how references that *depend on physical placement* of certain > text are to be coped with. (As with my page headings; or---probably > even harder so that at least 2-runs of troff are > inevitable---references to page numbers where sth is mentioned. But I > really need just the headings now.) For page headers and footers, the tutorial section in the Troff paper should have enough to get you going (/sys/doc/troff.ps, pages 34 on). For section and index cross-references to page numbers, you pretty much have to do two passes, writing the xref data to an external file that gets read in the table of contents or index sections as appropriate. (You read and write the xref data file from inside troff itself using .so and .tm.) For what it's worth, spending a couple of days studying the ms macro package source code should give you a lot of ideas. And a headache ;-) --lyndon
Re: [9fans] info bashing
> My theory is that GNU tools were so bloated by design that they > realized that they couldn't write a decent man page for their tools > so they invented the info pages and the --help flag. In fairness to info, you have to consider its history. The want was to be able to present an online edition of some large documents (the emacs documentation), with cross-references, search capabilities, index lookups, etc. This was long before the web was even a glimmer in anyone's eye. In that regard, it was a spectacular success. Being able to jump around a 400+page document in real time on a VT100 plugged into a Sun 3/50 workstation is a testament to that. The standalone implementation suffers from being keystroke compatible with the emacs lisp implementation. Those of us who grep up on emacs can find our way around. For anyone else, I can't imagine how they manage to use it. But as others have said, treating info as a replacement for man pages is arrogance beyond any rational description. Then again, the quality of documentation for most GNU software matches that of the code. --lyndon
Re: [9fans] info bashing
> i take this as another strike against info. the fact that one > sees that the editor's docs are 400+ pages, and there's no easy > way to cut that down to a man page, and yet they proceeded to > build bloatware to accomidate bloatware. That's like blaming Mozilla because you choose to read Sarah Palin's missives with Firefox. --lyndon
Re: [9fans] mark shaney again...
> This is not new. "Politicians" are socialbots generating sentences from > a limited set of "politically correct" chunks (this means: that don't > make sense) and have, still, millions of followers... and cause millions > of deaths too... Listen, just because we called an election today ... wait! Where's my research grant?!?
[9fans] dst shift is shifty
Am I the only person still an hour behind the PST->PDT shift? I recall this happening last year, too ...
Re: [9fans] dst shift is shifty
> did you not copy the new US_Pacific to /adm/timezone/local? Being in Canada_Pacific, no. I see an update is required.
