Re: [9fans] file descriptor leak

On 16 February 2016 at 18:01, wrote: > and the parent proc doesnt need the fd to /dev/null, it could as well just > open it in the child like: > > close(0); open("/dev/null", OREAD); > > There's no harm in making and using a more general function, even in a specific way, so that part's ok. The ca

Re: [9fans] file descriptor leak

On 16 February 2016 at 16:42, wrote: > Then, it would be tempting to take the > > dup(fd,0); close(fd); > > out to before the if(pid==0)... > the idea is to have fd (/dev/null in this case) be standard input in the new process, so it needs to follow the pid==0 test. the "outside" comman

Re: [9fans] bug in exportfs

On 15 February 2016 at 15:30, erik quanstrom wrote: > > sadly among its other sins, the plan 9 webserver does use .httplogin but that's just an ordinary name; in fact, it's exactly that name that's hidden, nothing to do with .: httpd.c: * don't show the contents of .httplogin httpd.c: if(strcm

Re: [9fans] bug in exportfs

On 15 February 2016 at 12:44, wrote: > My point was that under the circumstances we are stuck with people who > DO use the leading dot to make files disappear from directory listings > and they won't budge :-) > Not in Plan 9. They do not disappear from directory listings in Plan 9 (or even Plan

Re: [9fans] bug in exportfs

On 15 February 2016 at 10:55, wrote: > > Charles, I think Kenji has a point and you are diverting the > discussion . > Not really: I'm trying to suggest possibilities for "what are you trying to achieve" (by hiding dot files, say), and then alternative mechanisms for that.

Re: [9fans] bug in exportfs

On 15 February 2016 at 10:55, wrote: > > Whereas I agree that the leading-dot convention ought to be buried, in > reality (a) it is not going to just go away and (b) if it was so > readily accepted, it must have fulfilled a need. > There is no "leading dot" convention in Plan 9. That's in BSD-de

Re: [9fans] bug in exportfs

On 15 February 2016 at 01:05, arisawa wrote: > for example, assume we want to exclude all files of name that begins with > “.”, > then it is probably difficult to do so using only nsfile. > Yes, although that convention isn't in Plan 9, and it might be worthwhile reconsidering how and why it is

Re: [9fans] bug in exportfs

On 14 February 2016 at 16:38, wrote: > i could imagine the filtering being usefull when cpu'ing to foreign > machines, > as a server can easily compromize your system when cpu exports your whole > local namespace > You'd still be better off using a custom nsfile to control it, running that cpu i

Re: [9fans] bug in exportfs

On 13 February 2016 at 14:26, Charles Forsyth wrote: > I really wonder about the pattern-matching code being there at all. One interesting thing about the implementation is that it goes so far as to edit the result of directory reads, so excluded names can't be seen in ls.

Re: [9fans] bug in exportfs

On 14 February 2016 at 10:27, hiro <23h...@gmail.com> wrote: > You mean this? No, there was a handful of Plan 9 patents, mainly to do with aspects and applications of computable name spaces and related services.

Re: [9fans] bug in exportfs

On 22 December 2015 at 10:02, arisawa wrote: > > The difficulty is in the pattern matching rule. > If we want to export only /usr/glenda, then the pattern matching filer > must pass > /usr > /usr/glenda > and must not pass > /usr/ > I really wonder about the pattern-matching code being there at

Re: [9fans] FP register usage in Plan9 assembler

On 4 February 2016 at 15:22, erik quanstrom wrote: > MOVQQU or MOVQQA still follow the expected pattern. Originally on amd64 I consistently used O instead of sometimes DQ and sometimes O as Intel did, but in the end I changed them back to the Intel names, since it was hard to look them up, and

Re: [9fans] FP register usage in Plan9 assembler

On 4 February 2016 at 12:24, Brantley Coile wrote: > Which plan 9 assembler uses right to left argument assignments, or compare > argument order For example, the ARM's MCR and MRC instructions are unchanged from the manufacturer's order. Partly that's because the "instructions" are really just

Re: [9fans] FP register usage in Plan9 assembler

On 1 February 2016 at 23:34, Giacomo Tesio wrote: > > Is it correct to say that this means that the Plan9 compiler suite *never* > follows the sysV calling convention documented at section 3.2.3 of AMD64 > ABI http://www.x86-64.org/documentation/abi.pdf and always pushes > parameters to the stack

Re: [9fans] FP register usage in Plan9 assembler

On 1 February 2016 at 22:38, Charles Forsyth wrote: > the syntax name+offset(FP) defines name as the given offset from the > virtual frame pointer. I ought to have added that it's +8 because info is the second parameter, where the parameter space is divided into slots of 8 bytes on

Re: [9fans] FP register usage in Plan9 assembler

On 1 February 2016 at 16:47, Giacomo Tesio wrote: > MOVQinfo+8(FP), BP > MOVLAX, 0(BP) > MOVLBX, 4(BP) > MOVLCX, 8(BP) > MOVLDX, 12(BP) > RET > > What I miss is where "info" comes from. > the syntax name+offset(FP) defines name as the given offset from

Re: [9fans] Go on Plan 9?

On 27 January 2016 at 01:40, Sean Caron wrote: > update process running: > > replica/pull -v /dist/replica/network > Beware that the introduction of the nsec system call can cause trouble if replica updates commands before you're running the new kernel.

Re: [9fans] subtracting pointers on amd64 6c

On 5 January 2016 at 19:01, Devon H. O'Dell wrote: > so given any of the examples in this thread, if you typedef'ed > ptrdiff_t to long, then the compiler technically isn't actually doing > anything wrong. whether it is doing something useful is a different > question. > Well, although I knew th

Re: [9fans] subtracting pointers on amd64 6c

On 5 January 2016 at 10:15, Charles Forsyth wrote: > 2) if a pointer subtraction has to yield a long, why dont we cast *after* >> the division? >> > > that would be certainly be better. > since 6c is more commonly used now, and there's more interest or nee

Re: [9fans] subtracting pointers on amd64 6c

On 5 January 2016 at 07:53, wrote: > rsc has fixed this in the go 6c compiler. so far most code > seems to compile and work fine. the most fallout is with > long x = p - q; T *y = p+x; really there needs to be a new typedef for the difference type.

Re: [9fans] subtracting pointers on amd64 6c

On 5 January 2016 at 06:36, wrote: > 1) why do we cast to long? > because that's the type all existing code expected, and there wasn't much application for > 4gb in single arrays at the time (as opposed to having big memory in big address spaces) > 2) if a pointer subtraction has to yield a lo

Re: [9fans] any updates on go for plan9/arm?

On 31 December 2015 at 11:57, Richard Miller <9f...@hamnavoe.com> wrote: > Raspberry Pi 2, but has an elusive "one last bug" which I suspect has to > do with cache or page table coherency. > It's still got the explicit cache management code from the old bcm, which isn't right. There might be more

Re: [9fans] bug or feature ? --- ip/ping -6

On 30 December 2015 at 12:48, arisawa wrote: > code is simplified. It works better, but it's smaller? With luck, you might start a trend!

Re: [9fans] using tls-psk cipher suits vs roll our own handshake

On 29 December 2015 at 18:34, Charles Forsyth wrote: > extension of the protocol to the occasional new protocol. Sorry, that second "protocol" was supposed to be algorithm or technique.

Re: [9fans] using tls-psk cipher suits vs roll our own handshake

On 25 December 2015 at 03:03, wrote: > > the functionality that is desired is to be able to "negotiate" the > cipher suits and record layer protocol versions. I could never work up much enthusiasm for TLS because it is needlessly big and complex, but still got important things wrong. I never sa

Re: [9fans] Administrators and moderators of 9fans list, please erase all the messages that I not should have posted here in 9fans list!

On 10 December 2015 at 14:50, françai s wrote: > I decided prevent substantial harm to important relationships that > probably I will have in future with other developers. “The Earle of Oxford, making his low obeisance to Queen Elizabeth, happened to let a Fart, at which he was so abashed and

Re: [9fans] Peter Bosch's TV software

On 2 December 2015 at 19:14, hiro <23h...@gmail.com> wrote: > > > Go personal to Peter Bosch at Lucent. That would be Cisco.

Re: [9fans] unmount

On 1 December 2015 at 03:24, arisawa wrote: > current kernel allows unmount even if after rfork m. > this feature makes sandboxing difficult. > can anyone explain this feature is necessary? > For some applications, similar to ftp or http, I've built a name space somewhere and then bound that to

Re: [9fans] Undefined Behaviour in C

On 26 November 2015 at 23:14, Steve Simon wrote: > I don't know about the PDP but the VAX allowed access to address zero. Not in my port.

Re: [9fans] Compiling ken-cc on Linux

On 26 November 2015 at 23:08, Ryan Gonzalez wrote: > Holy crap, that's crazy. I built it in debug mode on Linux, but I don't > think it used that much. I only have 6 GB right now! You have to remember that a C compiler is one of the largest, most complex software components that human beings ha

Re: [9fans] Compiling ken-cc on Linux

On 26 November 2015 at 22:02, Ryan Gonzalez wrote: > I remember the time I was trying to build LLVM+Clang on Windows in debug > mode. Because...MinGW...I actually surpassed the file size limit when > linking Clang, so I had to rebuild EVERYTHING. Stupid thing took about an > hour each time. Ah.

Re: [9fans] Compiling ken-cc on Linux

On 26 November 2015 at 21:51, Charles Forsyth wrote: > On 26 November 2015 at 21:49, Ryan Gonzalez wrote: > >> All that is bad...but glibc is worse. The issue is that you kinda *have* >> to use it, > > > true, very true. i remember glibc being my first instance of h

Re: [9fans] Compiling ken-cc on Linux

On 26 November 2015 at 21:49, Ryan Gonzalez wrote: > All that is bad...but glibc is worse. The issue is that you kinda *have* > to use it, true, very true.

Re: [9fans] Compiling ken-cc on Linux

On 26 November 2015 at 18:15, Ryan Gonzalez wrote: > the only library on earth that makes me want to bang my head on the floor. There must be others, surely. What about graphics libraries with APIs designed for FORTRAN (no data structures)? What about ostensible crypto libraries that get their

Re: [9fans] Undefined Behaviour in C

On 26 November 2015 at 16:42, Brantley Coile wrote: > I’m still kind of dubious that there are any structures where one would > not catch a null pointer. > I don't think there are any. In practice, ome other value lower down will be accessed first. Unless the compiler introduces its own invisibl

Re: [9fans] Compiling ken-cc on Linux

On 25 November 2015 at 17:10, Vasudev Kamath wrote: > In file included from > /home/vasudev/Documents/C_programming/compilers/9-cc/Linux/386/include/lib9.h:9:0, > from 9obj.c:5: > /usr/include/features.h:148:3: warning: #warning "_BSD_SOURCE and > _SVID_SOURCE are deprecated, use

Re: [9fans] Compiling ken-cc on Linux

That copy of the compilers was changed quite a bit by someone else, and I only belatedly realised that. I'll try to resurrect that one, since it would help me keep the Plan 9 and Inferno compilers in sync, as well. On 25 November 2015 at 17:24, Vasudev Kamath wrote: > Ryan Gonzalez writes: > >

Re: [9fans] Undefined Behaviour in C

On 26 November 2015 at 11:37, wrote: > Plus, in C, 0 is used as a truth value for false... > That doesn't say how a 0 value for a pointer is represented; it's just how it's written in the program text. The compiler knows the types and can convert (same as double = 0). In practice, you can't cha

Re: [9fans] Undefined Behaviour in C

The link to the lwn.net article explains that using mmap the naughty application mapped a page to virtual 0, which was then available in kernel mode in that process, and all they'd need to do is put their own "socket" structure at 0 + offsetof(struct tun_struct, sk). On 25 November 2015 at 10:43,

Re: [9fans] Undefined Behaviour in C

On 23 November 2015 at 10:20, Ramakrishnan Muthukrishnan wrote: > Had been reading the SOSP paper: > > As an example of how tricky it can be, one of their examples is const uint8_t *data = /* buffer head */; const uint8_t *data_end = /* buffe

Re: [9fans] Undefined Behaviour in C

On 23 November 2015 at 12:17, Brantley Coile wrote: > I've lived with the old definition so long that I didn't notice Plan 9's > definition, which is not a problem on today's architectures because there > are two equally efficient instructions to choose from. There are a few things in C's defin

Re: [9fans] Undefined Behaviour in C

On 23 November 2015 at 11:50, Brantley Coile wrote: > These bloated compilers can never be idiot proof because idiots are so > ingenious. One thing that struck me about that earlier gcc example, where the test for "tun" is eliminated because of bad compiler reasoning, is that the same compiler

Re: [9fans] Undefined Behaviour in C

On 23 November 2015 at 11:50, Brantley Coile wrote: > It is undefined in C whether or not it sign extends or not. Some machines > do it one way, some another. To force the language to one behavior requires > more code on some architectures. > Ironically for its use as an example, that's another

Re: [9fans] Undefined Behaviour in C

On 23 November 2015 at 11:32, Charles Forsyth wrote: > The Plan 9 C compiler is firmly in that historical tradition In short: http://www.terzarima.net/images/careful-now.jpg

Re: [9fans] Undefined Behaviour in C

There is quite a bit there to work through, but I was struck by one of the responses to a gcc bug report: "you're leading to undefined behaviour - do you understand this simple fact? in such cases compiler can do *anything* with your code." I've seen similar comments before (about #pragma,

Re: [9fans] About IL

On 20 October 2015 at 17:14, Adriano Verardo wrote: > Could IL be actually more effective than TCP/IP in a closed net ? > I think about a robotic application using very small cpus. > What about Styx -- ore something similar - over IL ? > Styx is (now) the same as 9P, and it was always similar: n

Re: [9fans] RUDP and/or others

On 19 October 2015 at 20:31, Aleksandar Kuktin wrote: > I seem to remember IL being more complex than just a UDP with counters > and ACK, which is what I'm - sort of - looking for. > I think you might find Plan 9's rudp is essentially that. Conversations are determined by a generation number; pa

Re: [9fans] RUDP and/or others

On 18 October 2015 at 23:43, Aleksandar Kuktin wrote: > BAM! I run straight into RUDP. "Designed at Bell Labs for the Plan 9 > operating system". I just skimmed through the (expired) IETF draft from > 1999 and I honestly think the design might be too much. It looks like > it's almost completely l

Re: [9fans] Web Gardens

On 14 October 2015 at 09:32, Charles Forsyth wrote: > No, it's https://www.youtube.com/watch?v=zIV4poUZAQo > As usual, the official reference was short on the implementation detail. Try https://www.youtube.com/watch?v=QTQfGd3G6dg

Re: [9fans] Web Gardens

On 14 October 2015 at 04:29, Lyndon Nerenberg wrote: > The reference implementation: > > https://www.youtube.com/watch?v=ifmRgQX82O4 > No, it's https://www.youtube.com/watch?v=zIV4poUZAQo

Re: [9fans] Web Gardens

On 12 October 2015 at 23:43, Aleksandar Kuktin wrote: > but it could also be a "Walled Garden".. with shrubbery to hide data from outsiders and, for defence in depth, another shrubbery slightly higher for a two-level effect, with a little path for authorised users

Re: [9fans] off topic - a good Git reference

On 12 October 2015 at 17:49, Álvaro Jurado wrote: > what ensures sha key is in fs. The reason many of us are a little sceptical about it being fsync as such preventing the data appearing is that if the git function that writes the key does a write or pwrite, the key will be in the file system o

Re: [9fans] off topic - a good Git reference

On 10 October 2015 at 19:25, Álvaro Jurado wrote: > While checking out it looses in any moment some sha key and then fatal. > Other times not. Why do you think that was fsync, and not something else?

Re: [9fans] Web Gardens

No, that's a web allotment On 12 October 2015 at 10:49, Staven wrote: > I thought a web garden was a hobbyist version of a server farm. > > >

Re: [9fans] off topic - a good Git reference

On 7 October 2015 at 16:17, Álvaro Jurado wrote: > because it has an strong dependency of fsync to freeze sha keys in fs > during fetching. And that is just a dummy in Plan 9 ape fsync causes any operating system buffers in the "buffer cache" to be flushed to "disk" (not user-space buffers), so

Re: [9fans] Frogs?

On 5 October 2015 at 17:42, Kare Nuorteva wrote: > Could someone please explain what is a frog in a filename? It's many decades old, and not restricted to file names. It originally referred to an unexpected non-ASCII character in a text file: "There's a frog in my file!" It was sometimes put th

Re: [9fans] off topic - a good Git reference

On 1 October 2015 at 18:31, Jeff Sickel wrote: > > On Sep 30, 2015, at 2:59 AM, Charles Forsyth > wrote: > > > > Here's a small but representative example. > > That’s just an example of a C file. I was really just writing about the difficulty of current C

Re: [9fans] copy of 9.txt.gz?

On 1 October 2015 at 15:48, Brantley Coile wrote: > I think he meant the Plan 9 Lion’s commentary, not the Sixth Edition one. Yes, and that was in the text I quoted in my reply!

Re: [9fans] copy of 9.txt.gz?

On 1 October 2015 at 14:43, Charles Forsyth wrote: > On 1 October 2015 at 13:06, Mark Bucciarelli wrote: > >> By the way, is there any version of the John Lyons >> notes on Plan 9 from 1989? They Lyons books says >> circulation was restricted to distribution Bell Labs

Re: [9fans] copy of 9.txt.gz?

On 1 October 2015 at 13:06, Mark Bucciarelli wrote: > By the way, is there any version of the John Lyons > notes on Plan 9 from 1989? They Lyons books says > circulation was restricted to distribution Bell Labs. > There are two books mentioned: > It's on Amazon: http://www.amazon.co.uk/Lions-Co

Re: [9fans] Replacement for find

On 30 September 2015 at 09:01, Wolfgang Helbig wrote: > But I consider it ugly, to ask for the disk usage if you just want to > recursively list all files. > It probably is not ideal, even when the circumlocution is hidden in a script. Perhaps find's syntax and conventions could be improved, tho

Re: [9fans] off topic - a good Git reference

On 30 September 2015 at 08:47, Charles Forsyth wrote: > I was being sarcastic about the portability of so much contemporary C code. Here's a small but representative example. #if HAVE_SYS_TIME_H #include #endif #if HAVE_SYS_CLOCK_GETTIME time_t time_now(void) { struct

Re: [9fans] off topic - a good Git reference

On 30 September 2015 at 08:36, hiro <23h...@gmail.com> wrote: > Why do you say C programs aren't portable, we have a C compiler already? I was being sarcastic about the portability of so much contemporary C code. You can't just compile it, even in an an ANSI/POSIX environment.

Re: [9fans] off topic - a good Git reference

On 30 September 2015 at 04:11, erik quanstrom wrote: > > > is there someone else interested in write a git tool for plan 9 ? it would be useful, to access git repositories directly. unfortunately, git is a C program, so it's not very portable.

Re: [9fans] manual qer(8)

On 26 September 2015 at 06:29, arisawa wrote: > I think “runq” should be replaced by “upas/runq” mine has /bin/upas/runq -a /mail/queue /mail/lib/remotemail

Re: [9fans] Out of pseudo mount points

On 24 September 2015 at 20:55, Adriano Verardo wrote: > B->A woks, A->B doesnt. > Probably there is something wrong on A, not in exportfs. > You need /mnt/exportfs with a set of numbered directories in it, which might be missing on A: % ls /mnt/exportfs /mnt/exportfs/0 /mnt/exportfs/1 /mnt/expo

Re: [9fans] kenc vlong double

On 14 September 2015 at 14:18, Charles Forsyth wrote: > 8c is a little more > involved because of the 387's architecture. there probably won't be much > code, > but it's fiddly. > in fact it was easy. i'll collect the changes shortly.

Re: [9fans] kenc vlong double

On 14 September 2015 at 13:59, wrote: > is there any reason to handle the as single operations instead > of breaking it down into separate and operations? that is, > is (a = b) always equivalent to (a = a b)? > you then have to fuss whether the evaluation of a has side-effects, and if so, ad

Re: [9fans] kenc vlong double

On 13 September 2015 at 19:55, Charles Forsyth wrote: > On 13 September 2015 at 19:46, wrote: > >> so we really want to have n->type == double/float > > > no, it happens to be wrong for ordinary integers too: > > > int > x(int a, double d) > { > a += (

Re: [9fans] kenc vlong double

On 13 September 2015 at 19:46, wrote: > so we really want to have n->type == double/float no, it happens to be wrong for ordinary integers too: int x(int a, double d) { a += (a += d); return a; } should have the outer += done as int using the result of a += d as stored back into `a' and read

Re: [9fans] kenc vlong double

On 13 September 2015 at 19:01, wrote: > just assigning t to n->type fixes the type, but why did it > call arith() in the first place? > for P += I, P -= I, and other more straightforward cases of mixed-modes, you need "the usual arithmetic conversions" first.

Re: [9fans] kenc vlong double

On 13 September 2015 at 19:21, erik quanstrom wrote: > isn't the && !mixedasop() added to the condition the problem: > the cast should not be elided if it's a float/double. t > the test is correct, because in mixed-mode assignment, you want to do the calculation in float/double, then convert it

Re: [9fans] kenc vlong double

On 13 September 2015 at 15:23, wrote: > the problem is v += d propagates the whole expression > to double. so we somehow need to convert v to double, > do the then convert back but return the double > result. > the type of E1 op=E2 is the same as the type of E1 = E1 op E2, since the expressions

Re: [9fans] kenc vlong double

On 13 September 2015 at 15:23, wrote: > > lets see what charles thinks about this. I thought at first that one had been fixed some time ago, but it was probably just the version with compiled code (eg, amd64). i'll have a look at it.

Re: [9fans] Privalloc(2) and rfork(RFPROC|RFMEM) (was: a pair nec bugs)

In any case, an implementation along the lines of tprivalloc seems ok, and passes my naive test program. #include #include static Lock privlock; static int privinit; static u32int privmap; extern void **_privates; extern int _nprivates; void ** privalloc(void) { void **p; int i; lock(&priv

Re: [9fans] Privalloc(2) and rfork(RFPROC|RFMEM) (was: a pair nec bugs)

On 7 September 2015 at 01:30, erik quanstrom wrote: > unless by name an entry in a table shared by the set of memory sharing > processes is what is meant the table isn't shared. the address of the table is the same, but the underlying memory is private, and indeed can't be shared (there isn't a

Re: [9fans] Privalloc(2) and rfork(RFPROC|RFMEM) (was: a pair nec bugs)

On 6 September 2015 at 19:21, wrote: > manpage, might just get rid of privfree() itself. globally allocate > the slots one after another. > it's useful to be able to reset some or all of the state in a supervisory process after a failure and restart. the tprivalloc/tprivfree [+bug fix] approach

Re: [9fans] Privalloc(2) and rfork(RFPROC|RFMEM) (was: a pair nec bugs)

On 6 September 2015 at 16:02, erik quanstrom wrote: > a slot of local interest? doesn't malloc serve that purpose well enough? It doesn't create a name for a per-process global.

Re: [9fans] Privalloc(2) and rfork(RFPROC|RFMEM) (was: a pair nec bugs)

On 6 September 2015 at 00:38, wrote: > is privfree() broken? it appears it chains the slots together, > but only the calling process will get a correct chain. > The only way it works is to have a main process allocate and free slots for use by all participants, which is a workable scheme in many

Re: [9fans] Privalloc(2) and rfork(RFPROC|RFMEM) (was: a pair nec bugs)

On 5 September 2015 at 15:03, Giacomo Tesio wrote: > For extra safety I added an assert(*p == nil) just after rfork, and after > a few (apparently?) successful spawns, the assert fails. The stack is a logical copy of the parent process's stack at rfork, even with RFMEM, since the stack's not sh

Re: [9fans] On Linux, what is the rc init file?

On 30 August 2015 at 19:25, Teodoro Santoni wrote: > I don't see any real difference between adding modified versions of my > .bashrc > things to rcmain or putting them to $home/lib/profile > rcmain is shared. the profile is per-user

Re: [9fans] read9pmsg usage

On 12 August 2015 at 10:18, Giacomo Tesio wrote: > So, seem that ignoring zeros is simply wrong. A residual from the past... There doesn't seem to be any justification for it now, whatever the original problem. Even if there were something, I'd fix that instead of ignoring the convention.

Re: [9fans] read9pmsg usage

On 10 August 2015 at 15:11, Giacomo Tesio wrote: > /* > * reading from a pipe or a network device > * will give an error after a few eof reads. > * however, we cannot tell the difference > * between a zero-length read and an interrupt > * on the processes writing to us, > * so we wait for t

Re: [9fans] read9pmsg usage

On 10 August 2015 at 21:17, Giacomo Tesio wrote: > Zero can either mean EOF or "I'm alive but boring". > > I can't see how a reliable communication (a cpu connection for example) can > survive this mismatch. > I'm probably missing something. > A specialised reader and writer can always agree tha

Re: [9fans] read9pmsg usage

As a further historical note, originally 9P required a stream that preseved record boundaries, and the reliable datagram protocol IL/IP and pipes did that. Once TCP/IP was used, there was some fussing needed to work out where the records were, so the revision 9P2000 added a size and the stream didn

Re: [9fans] read9pmsg usage

Zero conventionally means end-of-file, but record boundaries are preserved on capable streams, so if a writer writes zero, the reader reads zero. Having said that, I think the comment is wrong, and read9pmsg returning zero should be interpreted as the end of the (9p) stream. In most cases, the wri

Re: [9fans] Small Plan 9 Platforms

On 7 August 2015 at 18:13, Brian L. Stuart wrote: > So depending > on where plan9-bcm stands, it might be just right. > That seems to be an old version of /sys/src/9/bcm (perhaps with modifications) so Richard Miller's version in contrib will be more up-to-date, I think.

Re: [9fans] Small Plan 9 Platforms

On 5 August 2015 at 21:39, Brian L. Stuart wrote: > Obviously, the Raspberry Pi is a candidate. I think the big advantage of the Rpi or Rpi2 (for speed, memory and cores) is that there's a wealth of published projects for them, including hardware ones, and other stuff, and they aren't likely to

Re: [9fans] Harvey OS: A new OS inspired heavily by Plan 9

On 27 July 2015 at 15:19, Anthony Sorace wrote: > (for many, it’s pretty > much just a browser) > One of the reasons mere POSIX isn't enough is that there are many non-POSIX tendrils that have worked their way throughout the system, notably d-bus and now systemd, but there are many others, and t

Re: [9fans] Harvey OS: A new OS inspired heavily by Plan 9

On 27 July 2015 at 14:44, Charles Forsyth wrote: > It is slow. But it doesn't matter anyway if your aim is to compile a ton of stuff that only gcc can compile.

Re: [9fans] Harvey OS: A new OS inspired heavily by Plan 9

On 27 July 2015 at 13:08, Aram Hăvărneanu wrote: > 'd expect GCC compiling Plan 9 at a speed reasonably comparable to kencc. I used gcc for one of my own OS projects years ago, without all the #include crud. It is slow. For one thing, it still(!) produces textual assembly code (because the PDP-

Re: [9fans] Harvey OS: A new OS inspired heavily by Plan 9

On 26 July 2015 at 18:58, Charles Forsyth wrote: > an environment that was compatible with all the existing software although that's rapidly becoming incompatible with itself. for instance, in an unrelated forum, someone observes: "clang provides __attribute__((overloadable)), wh

Re: [9fans] Harvey OS: A new OS inspired heavily by Plan 9

On 26 July 2015 at 18:33, erik quanstrom wrote: > if "fast compilation" is a feature over plan 9, I'd like to see some > numbers. That wasn't the point, I think. The mention of speed was rather that on fast enough hardware the speed with gcc isn't that bad, so you can use that. (That misses ano

Re: [9fans] Has Linux jumped the shark?

On 24 July 2015 at 20:20, Devon H. O'Dell wrote: > > But POSIX remembers and indeed insists on minutiae from 40 years ago! > > If only we could all be more like POSIX. I didn't mean it as a good thing.

Re: [9fans] Has Linux jumped the shark?

On 24 July 2015 at 18:08, Devon H. O'Dell wrote: > doesn't remember given > that this would have been over 40 years ago. > But POSIX remembers and indeed insists on minutiae from 40 years ago!

Re: [9fans] Has Linux jumped the shark?

On 24 July 2015 at 04:54, Prof Brucee wrote: > has Linux with the release of 4.0 finally jumped the shark. Since it's called "Hurr Durr I'ma Sheep", I thought I'd ask a celebrity what he thought of it. The response was much as I'd expected: http://goo.gl/ZefDFV Others simply said that "it was b

Re: [9fans] Gawk in 9front-ports

On 7 July 2015 at 16:25, Jens Staal wrote: > most likely not since the whole system is static... The loaders support creating a module, with the -u and -x options, with import and export tables, which are type-checked, to be dynamically loaded. If the program you're working with won't compile a

Re: [9fans] replace p9sk1 with something better(9front)

On 2 July 2015 at 17:44, Skip Tavakkolian wrote: > isn't it settled that keeping of secrets and exchange thereof are the > domain of factotum? I hope so.

Re: [9fans] replace p9sk1 with something better(9front)

are responsible for mutual authentication and key exchange. Wanted: more ciphers, support for user certificates, support for certificate verification. ECDSA! ECDHE!" I think that I'd avoid putting the negotiation and certificate stuff (as such) in the kernel device. On 2 July 2015 at

Re: [9fans] replace p9sk1 with something better(9front)

On 2 July 2015 at 13:30, Anthony Sorace wrote: > The p9sk1 *model* is great, and it'd be a real shame to drop it. There always seems to be trouble setting it up, which suggests that the documentation people typically first see might need revising (or better pointers if it exists but people don'

<    1   2   3   4   5   6   7   8   9   10   >