Re: [9fans] 9n
2018-05-02 19:24 GMT+02:00 Fran. J Ballesteros : > I just learned to love absolute paths. > Actually they kind of emerge from my design by themselves. > IIRC, there was no deadlock caused that you should be aware of. > I'ts been a long time and quite a few protocols since then, I can look for > the source; there must be also some docs in the web. > Well, actually I'm pretty curious about the implementation. I'd like to see how you did isolated the changes, since to me they seem rather huge (but my protocol diverge more from 9P2000 than 9P2000.ix). Also, I welcome any suggestion for further documents to read about the topic. > Also, I'm more in favor of prefix mount tables, that they are very > different from what 9 does and they would lead to a very different system. > Can you elaborate? What differences this approach would produce? I can foresee some (eg bind semantics) but maybe I'm missing some of them. > Good luck and have fun. > Thanks! :-) Giacomo > > > On 2 May 2018, at 19:14, Giacomo Tesio wrote: > > > > 2013-06-17 21:06 GMT+02:00 Nemo : > > You should ask if anyone else did that before doing it, instead of saying > > they are un-spined life forms. > > > > Here I am, finally! :-) > > > > I'm designing yet another file protocol for my toy/research os (whose > kernel is derived from Charles Forsyth's Plan9-9k), and I'd like to give a > look at your prior art. > > > > Some of my design decisions lead to a management of mount tables that is > pretty similar to what you describe in your paper about the integration of > 9P2000.ix. > > > > Given you already walked this path, I'd like to know what you have > learnt and if you faced issues I should be aware. > > For example, the slight difference in bind semantics seems to reduce the > risk of accidental loops in the namespace, but I would expect it would > break related userspace assumptions. > > Also, resolving the dot of each process in the Pgrp each time a mount is > done, seems pretty complex and prone to deadlocks. > > > > > > Don't you have a tricorder? > > > > No... but usually I can get away with my sonic screwdriver... :-) > > > > > > Giacomo > > > >
Re: [9fans] 9n
I just learned to love absolute paths. IIRC, there was no deadlock caused that you should be aware of. I'ts been a long time and quite a few protocols since then, I can look for the source; there must be also some docs in the web. Also, I'm more in favor of prefix mount tables, that they are very different from what 9 does and they would lead to a very different system. Good luck and have fun. > On 2 May 2018, at 19:14, Giacomo Tesio wrote: > > 2013-06-17 21:06 GMT+02:00 Nemo : > You should ask if anyone else did that before doing it, instead of saying > they are un-spined life forms. > > Here I am, finally! :-) > > I'm designing yet another file protocol for my toy/research os (whose kernel > is derived from Charles Forsyth's Plan9-9k), and I'd like to give a look at > your prior art. > > Some of my design decisions lead to a management of mount tables that is > pretty similar to what you describe in your paper about the integration of > 9P2000.ix. > > Given you already walked this path, I'd like to know what you have learnt and > if you faced issues I should be aware. > For example, the slight difference in bind semantics seems to reduce the risk > of accidental loops in the namespace, but I would expect it would break > related userspace assumptions. > Also, resolving the dot of each process in the Pgrp each time a mount is > done, seems pretty complex and prone to deadlocks. > > > Don't you have a tricorder? > > No... but usually I can get away with my sonic screwdriver... :-) > > > Giacomo >
Re: [9fans] 9n
2013-06-17 21:06 GMT+02:00 Nemo : > You should ask if anyone else did that before doing it, instead of saying > they are un-spined life forms. > Here I am, finally! :-) I'm designing yet another file protocol for my toy/research os (whose kernel is derived from Charles Forsyth's Plan9-9k), and I'd like to give a look at your prior art. Some of my design decisions lead to a management of mount tables that is pretty similar to what you describe in your paper about the integration of 9P2000.ix. Given you already walked this path, I'd like to know what you have learnt and if you faced issues I should be aware. For example, the slight difference in bind semantics seems to reduce the risk of accidental loops in the namespace, but I would expect it would break related userspace assumptions. Also, resolving the dot of each process in the Pgrp each time a mount is done, seems pretty complex and prone to deadlocks. > Don't you have a tricorder? > No... but usually I can get away with my sonic screwdriver... :-) Giacomo
Re: [9fans] 9n
On Mon, Jun 17, 2013 at 12:15:54PM -0700, Skip Tavakkolian wrote: > all i see from you are pronouncements. show us your code. > I'm not a programmer; however, we here at 9front Technologies have deeveloped a new development paradigm we call "trust-based egalitarian avocational modular wide-area outscaled refactoring kultur" -- abbreviated T.E.A.M.W.O.R.K. You can see the results of this new methodology at http://code.google.com/p/plan9front/source/list khm
Re: [9fans] 9n
> now we know why this society may exist after all... those who do > something actually get pissed on. why bother even telling the masses > when they know what to expect in return. why bother? because the whining is not important to me, but plan 9 is. so there can be some trollish commentary. i can't think of any group with more than a trivial number of folks, where everyone was equally pleasant, all the time. as a general rule, we do not know everone's constraints, of time legal agreement, one's personal feelings about what is worthy to be released, etc. so it can be presumptious to say one simply lacks "spine" for not releasing code. i do understand the frustration. there are things i would like to have access to. but when i balance this with the idea that there may be good reasons why it is impossible, and the idea that other folks are independent agents, who owe me nothing, i realize i can't reasonably complain. - erik
Re: [9fans] 9n
> all i see from you are pronouncements. show us your code. That's how this all started. -sl
Re: [9fans] 9n
all i see from you are pronouncements. show us your code. On Mon, Jun 17, 2013 at 11:40 AM, Kurt H Maier wrote: > On Mon, Jun 17, 2013 at 08:20:56PM +0200, tlaro...@polynum.com wrote: > > > > There is code that is neither secret nor published. Code that does "the" > > or "some" job for the writer but that the writer does not want to > > maintain (for a public audience). > > > There is no Hague Convention specification that you must maintain code > just because you let other people see it. Don Knuth springs to mind as > someone who is capable of releasing software and not regarding this as > some kind of Hemingwayan Albatross. > > It is annoying to have to replicate work someone else has done merely > because they lack the spine to release it. > > khm > >
Re: [9fans] 9n
You should ask if anyone else did that before doing it, instead of saying they are un-spined life forms. Don't you have a tricorder? On Jun 17, 2013, at 8:40 PM, Kurt H Maier wrote: > It is annoying to have to replicate work someone else has done merely > because they lack the spine to release it.
Re: [9fans] 9n
On Mon, Jun 17, 2013 at 08:20:56PM +0200, tlaro...@polynum.com wrote: > > There is code that is neither secret nor published. Code that does "the" > or "some" job for the writer but that the writer does not want to > maintain (for a public audience). There is no Hague Convention specification that you must maintain code just because you let other people see it. Don Knuth springs to mind as someone who is capable of releasing software and not regarding this as some kind of Hemingwayan Albatross. It is annoying to have to replicate work someone else has done merely because they lack the spine to release it. khm
Re: [9fans] 9n
On Mon, Jun 17, 2013 at 02:01:08PM -0400, erik quanstrom wrote: > On Mon Jun 17 12:55:25 EDT 2013, ara...@mgk.ro wrote: > > > a lot of effort has gone into making code public. > > > > But it would be zero effort if code wouldn't be secret in the first place. There is code that is neither secret nor published. Code that does "the" or "some" job for the writer but that the writer does not want to maintain (for a public audience). I have the example for kerTeX: I use RISK, my own framework, that is not a precious proprietary code with lots of cutting edge and research features, but simply something that does the job for me and that I didn't want to support for others. It went publkic by side effect (and the support will be limited to kerTeX use). -- Thierry Laronde http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] 9n
Thanks for clearing that up. I haven't looked at the code, but the changes in the paper looked interesting. On Mon, Jun 17, 2013 at 10:07 PM, Nemo wrote: > It's a modified stock kernel, no need to ask because I made the changes > directly there. ;) > > Now seriously..., no plan 9 secret society has ever been actually secret and > hiding code, > as far as I know, that is. The only times I saw someone was keeping code > without publishing > it was because the code was not considered to be ready enough for others to > try. > > Don't know if I should add more ":)"s, well... > > hth > > On Jun 17, 2013, at 6:29 PM, Jiten Pathy wrote: > >> I am just wondering, does the "new Plan9 secret society" approve of >> the release of code ? >> >> On Thu, Jun 6, 2013 at 11:19 PM, Francisco J Ballesteros >> wrote: >>> >>> On Jun 6, 2013, at 7:40 PM, Francisco J Ballesteros wrote: >>> concat us >>> >>> Since concat'ing us may be disgusting, I should have written "contact us". >>> sorry. >>> >>> > >
Re: [9fans] 9n
On Mon, Jun 17, 2013 at 11:01 AM, erik quanstrom wrote: > On Mon Jun 17 12:55:25 EDT 2013, ara...@mgk.ro wrote: >> > a lot of effort has gone into making code public. >> >> But it would be zero effort if code wouldn't be secret in the first place. > > and usually one gets pissed on for going to the effort. > now we know why this society may exist after all... those who do something actually get pissed on. why bother even telling the masses when they know what to expect in return.
Re: [9fans] 9n
On Mon Jun 17 12:55:25 EDT 2013, ara...@mgk.ro wrote: > > a lot of effort has gone into making code public. > > But it would be zero effort if code wouldn't be secret in the first place. and usually one gets pissed on for going to the effort. - erik
Re: [9fans] 9n
> a lot of effort has gone into making code public. But it would be zero effort if code wouldn't be secret in the first place. -- Aram Hăvărneanu
Re: [9fans] 9n
On Mon, Jun 17, 2013 at 12:41:27PM -0400, erik quanstrom wrote: > > Now seriously..., no plan 9 secret society has ever been actually secret > > and hiding code, > > as far as I know, that is. The only times I saw someone was keeping code > > without publishing > > it was because the code was not considered to be ready enough for others to > > try. > > a lot of effort has gone into making code public. > > - erik > It works better when a lot of code goes into making code public. khm
Re: [9fans] 9n
That was all I was trying to say, in a single and precise sentence. I should learn english at some point… On Jun 17, 2013, at 6:41 PM, erik quanstrom wrote: > a lot of effort has gone into making code public.
Re: [9fans] 9n
> Now seriously..., no plan 9 secret society has ever been actually secret and > hiding code, > as far as I know, that is. The only times I saw someone was keeping code > without publishing > it was because the code was not considered to be ready enough for others to > try. a lot of effort has gone into making code public. - erik
Re: [9fans] 9n
It's a modified stock kernel, no need to ask because I made the changes directly there. ;) Now seriously..., no plan 9 secret society has ever been actually secret and hiding code, as far as I know, that is. The only times I saw someone was keeping code without publishing it was because the code was not considered to be ready enough for others to try. Don't know if I should add more ":)"s, well... hth On Jun 17, 2013, at 6:29 PM, Jiten Pathy wrote: > I am just wondering, does the "new Plan9 secret society" approve of > the release of code ? > > On Thu, Jun 6, 2013 at 11:19 PM, Francisco J Ballesteros > wrote: >> >> On Jun 6, 2013, at 7:40 PM, Francisco J Ballesteros wrote: >> >>> concat >>> us >> >> Since concat'ing us may be disgusting, I should have written "contact us". >> sorry. >> >>
Re: [9fans] 9n
I am just wondering, does the "new Plan9 secret society" approve of the release of code ? On Thu, Jun 6, 2013 at 11:19 PM, Francisco J Ballesteros wrote: > > On Jun 6, 2013, at 7:40 PM, Francisco J Ballesteros wrote: > >> concat >> us > > Since concat'ing us may be disgusting, I should have written "contact us". > sorry. > >
Re: [9fans] 9n
On Jun 6, 2013, at 7:40 PM, Francisco J Ballesteros wrote: > concat > us Since concat'ing us may be disgusting, I should have written "contact us". sorry.
[9fans] 9n
Hi, I have copied at sources.lsub.org/9n a copy of a modified plan 9 kernel that has a new mount table and mount driver, (everything near namec changed), along with a variant of fossil that speaks 9P2000.ix aka 9pix. See 9n.README for the details. It's experimental, so use with caution. I'm using it at my terminal but it's too young to be reliable. I also copied at 9nbits in the same server a few files that might be needed (the new kernel has a new OBEHIND open flag to enable write behind for files and thus has a new fdflush syscall). At http://lsub.org/export/9pix.pdf you have a TR describing the changes made. We also have a nix mark II that has these and other changes, and it's likely we will make it public at the old lsub nix site, but we are still changing it and fixing bugs there, so don't hold your breath. Besides this, the new nix has a new scheduler and a new memory manager. If anyone gives a try to any of this, and finds out any problem, please, concat us off list and we'll try to help. Our main tree has quite a few changes and it's likely I forgot to copy some bit or made some other mistake :) enjoy.
