* Re: todo [not found] <405d44d0ddf24c71ff94c72804f03bec@gmx.de> @ 2011-03-30 20:57 ` Stanley Lieber 2011-03-30 22:39 ` todo cinap_lenrek 2011-03-30 22:04 ` todo uriel 2011-04-01 0:30 ` todo Ethan Grammatikidis 2 siblings, 1 reply; 31+ messages in thread From: Stanley Lieber @ 2011-03-30 20:57 UTC (permalink / raw) To: 9front > any more ideas? - Whatever the new boot mechanism is, it should allow setting the same sort of variables that go into plan9.ini, but from an early prompt. This would aid in getting more hardware up and running without the need to create custom boot images. - bichued/hg: Mercurial 1.0.2 is not able to push to BitBucket, Google Code, etc. - fgb/openssh is not able to scp reliably. - realemu as default graphics mode, or enabled/disabled in plan9.ini. xga fails on many vm installs, which at this point may be the most common point of entry. - page(1)/gs(1) cannot render some PDF files. -sl ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: todo 2011-03-30 20:57 ` todo Stanley Lieber @ 2011-03-30 22:39 ` cinap_lenrek 2011-03-30 22:46 ` todo Stanley Lieber 0 siblings, 1 reply; 31+ messages in thread From: cinap_lenrek @ 2011-03-30 22:39 UTC (permalink / raw) To: 9front > - Whatever the new boot mechanism is, it should allow setting the > same sort of variables that go into plan9.ini, but from an early prompt. > This would aid in getting more hardware up and running without the > need to create custom boot images. this was a more blue sky idea... all you do in realmode from the loader can also be done in userspace with dossrv and a rc script... but with one set of drivers... but have to finish the work first on that making this point low priority. > - bichued/hg: Mercurial 1.0.2 is not able to push to BitBucket, Google > Code, etc. found a work arround... working on getpass.py to properly handle plan9 /dev/cons instead of misdetecting us as windows nt :) > - fgb/openssh is not able to scp reliably. hm... maybe we should take a look and fix it once and for all... > - realemu as default graphics mode, or enabled/disabled in plan9.ini. > xga fails on many vm installs, which at this point may be the most > common point of entry. i would argue that it is more reliable than /dev/realmode... the delay when setting mode is not that important in my opinion... and its better than crashing/freezing the whole machine without any way to debug the problem. making it optional with a plan9.ini key sounds fine. > - page(1)/gs(1) cannot render some PDF files. that sounds like a old bug in page... whats the exact error? do you have an example pdf that doesnt work? -- cinap ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: todo 2011-03-30 22:39 ` todo cinap_lenrek @ 2011-03-30 22:46 ` Stanley Lieber 0 siblings, 0 replies; 31+ messages in thread From: Stanley Lieber @ 2011-03-30 22:46 UTC (permalink / raw) To: 9front >> - page(1)/gs(1) cannot render some PDF files. > that sounds like a old bug in page... whats the exact error? > do you have an example pdf that doesnt work? I believe it is the same old bug. . I will try to reproduce the problem again and capture the errors. -sl ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: todo [not found] <405d44d0ddf24c71ff94c72804f03bec@gmx.de> 2011-03-30 20:57 ` todo Stanley Lieber @ 2011-03-30 22:04 ` uriel 2011-04-01 0:30 ` todo Ethan Grammatikidis 2 siblings, 0 replies; 31+ messages in thread From: uriel @ 2011-03-30 22:04 UTC (permalink / raw) To: 9front On Mar 30, 1:02 pm, cinap_len...@gmx.de wrote: > - replace ssh1 with fgbs ssh2 client > - remove and replace fossil > - replace 9load > - add linuxemu kernel support > - add Tmove to 9p and fileservers This is a good start, I keep a list somewhere of all the things a Plan 9 fork should do, I think it is currently lost in some forest of Sweden, but will take a look to see if I can find it. uriel > any more ideas? > > -- > cinap ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: todo [not found] <405d44d0ddf24c71ff94c72804f03bec@gmx.de> 2011-03-30 20:57 ` todo Stanley Lieber 2011-03-30 22:04 ` todo uriel @ 2011-04-01 0:30 ` Ethan Grammatikidis 2011-04-01 0:47 ` todo Jacob Todd ` (2 more replies) 2 siblings, 3 replies; 31+ messages in thread From: Ethan Grammatikidis @ 2011-04-01 0:30 UTC (permalink / raw) To: 9front On 30 Mar 2011, at 9:02 pm, cinap_lenrek@gmx.de wrote: > - add Tmove to 9p and fileservers I'd rather 'consider adding Tmove', it may turn out to suck after all. > - remove and replace fossil I've always wanted to write a filesystem. No seriously, I have. Am I qualified to? That's another matter. :D Actually what does this one mean? It reads like we want to take fossil out & put it back in. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: todo 2011-04-01 0:30 ` todo Ethan Grammatikidis @ 2011-04-01 0:47 ` Jacob Todd 2011-04-01 0:59 ` todo Uriel 2011-04-01 6:14 ` todo Taru Karttunen 2 siblings, 0 replies; 31+ messages in thread From: Jacob Todd @ 2011-04-01 0:47 UTC (permalink / raw) To: 9front [-- Attachment #1: Type: text/plain, Size: 532 bytes --] Take out fossil and put back in ken's fs. On Mar 31, 2011 8:30 PM, "Ethan Grammatikidis" <eekee57@fastmail.fm> wrote: > > On 30 Mar 2011, at 9:02 pm, cinap_lenrek@gmx.de wrote: >> - add Tmove to 9p and fileservers > > I'd rather 'consider adding Tmove', it may turn out to suck after all. > >> - remove and replace fossil > > I've always wanted to write a filesystem. No seriously, I have. Am I > qualified to? That's another matter. :D Actually what does this one > mean? It reads like we want to take fossil out & put it back in. [-- Attachment #2: Type: text/html, Size: 805 bytes --] ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: todo 2011-04-01 0:30 ` todo Ethan Grammatikidis 2011-04-01 0:47 ` todo Jacob Todd @ 2011-04-01 0:59 ` Uriel 2011-04-01 1:12 ` todo Ethan Grammatikidis ` (2 more replies) 2011-04-01 6:14 ` todo Taru Karttunen 2 siblings, 3 replies; 31+ messages in thread From: Uriel @ 2011-04-01 0:59 UTC (permalink / raw) To: 9front On Thu, Mar 31, 2011 at 5:30 PM, Ethan Grammatikidis <eekee57@fastmail.fm> wrote: > > On 30 Mar 2011, at 9:02 pm, cinap_lenrek@gmx.de wrote: >> >> - add Tmove to 9p and fileservers This is plain gratuitous idiotic protocol breaking, you can do the same thing simply by providing an alternative attach name with ctl file(s) for fancy things like moving stuff around. uriel > > I'd rather 'consider adding Tmove', it may turn out to suck after all. > >> - remove and replace fossil > > I've always wanted to write a filesystem. No seriously, I have. Am I > qualified to? That's another matter. :D Actually what does this one mean? It > reads like we want to take fossil out & put it back in. > ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: todo 2011-04-01 0:59 ` todo Uriel @ 2011-04-01 1:12 ` Ethan Grammatikidis 2011-04-01 4:40 ` todo aiju 2011-04-01 7:09 ` todo cinap_lenrek 2 siblings, 0 replies; 31+ messages in thread From: Ethan Grammatikidis @ 2011-04-01 1:12 UTC (permalink / raw) To: 9front On 1 Apr 2011, at 1:59 am, Uriel wrote: > On Thu, Mar 31, 2011 at 5:30 PM, Ethan Grammatikidis > <eekee57@fastmail.fm> wrote: >> >> On 30 Mar 2011, at 9:02 pm, cinap_lenrek@gmx.de wrote: >>> >>> - add Tmove to 9p and fileservers > > This is plain gratuitous idiotic protocol breaking, you can do the > same thing simply by providing an alternative attach name with ctl > file(s) for fancy things like moving stuff around. I always remember an example of network filesharing from the Labs: you have foo's files under /n/foo and foo has bar's files under /n/ bar so you can access bar's files via /n/foo/n/bar without having to set up permissions or whatever to directly access bar, and the example carried on to show 4 or 5 levels. I think the example was in V6 or V7 Unix's docs, maybe V8's or something. In such a setup and given an alternative attach point you'd have to double the work of every mount - or more like double the number of things which could be forgotten, no? ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: todo 2011-04-01 0:59 ` todo Uriel 2011-04-01 1:12 ` todo Ethan Grammatikidis @ 2011-04-01 4:40 ` aiju 2011-04-01 7:04 ` todo Uriel 2011-04-01 7:09 ` todo cinap_lenrek 2 siblings, 1 reply; 31+ messages in thread From: aiju @ 2011-04-01 4:40 UTC (permalink / raw) To: 9front > This is plain gratuitous idiotic protocol breaking, you can do the > same thing simply by providing an alternative attach name with ctl > file(s) for fancy things like moving stuff around. It doesn't break the protocol at all: Clients which don't need it don't have to know about it and if the server doesn't have it the client can emulate it. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: todo 2011-04-01 4:40 ` todo aiju @ 2011-04-01 7:04 ` Uriel 2011-04-01 7:13 ` todo cinap_lenrek 0 siblings, 1 reply; 31+ messages in thread From: Uriel @ 2011-04-01 7:04 UTC (permalink / raw) To: 9front On Thu, Mar 31, 2011 at 9:40 PM, aiju <aiju@phicode.de> wrote: > >> This is plain gratuitous idiotic protocol breaking, you can do the >> same thing simply by providing an alternative attach name with ctl >> file(s) for fancy things like moving stuff around. > > It doesn't break the protocol at all: Clients which don't need it > don't have to know about it and if the server doesn't have it the > client can emulate it. But then the client has to negotiate with the server to find out if it supports the Tmove extension, it is totally idiotic and retarded, adding it via an alternative attach name is trivial and doesn't break any shit. uriel ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: todo 2011-04-01 7:04 ` todo Uriel @ 2011-04-01 7:13 ` cinap_lenrek 2011-04-01 9:30 ` todo Uriel 0 siblings, 1 reply; 31+ messages in thread From: cinap_lenrek @ 2011-04-01 7:13 UTC (permalink / raw) To: 9front [-- Attachment #1: Type: text/plain, Size: 116 bytes --] why? can't we just fire and forget? server that dont know the command will just reply with an error no? -- cinap [-- Attachment #2: Type: message/rfc822, Size: 5454 bytes --] From: Uriel <uriel@berlinblue.org> To: 9front@googlegroups.com Subject: Re: todo Date: Fri, 1 Apr 2011 00:04:18 -0700 Message-ID: <AANLkTi=x_WhkmQbxD9Fd6a8p3REieek_J7tcv_n8um2J@mail.gmail.com> On Thu, Mar 31, 2011 at 9:40 PM, aiju <aiju@phicode.de> wrote: > >> This is plain gratuitous idiotic protocol breaking, you can do the >> same thing simply by providing an alternative attach name with ctl >> file(s) for fancy things like moving stuff around. > > It doesn't break the protocol at all: Clients which don't need it > don't have to know about it and if the server doesn't have it the > client can emulate it. But then the client has to negotiate with the server to find out if it supports the Tmove extension, it is totally idiotic and retarded, adding it via an alternative attach name is trivial and doesn't break any shit. uriel ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: todo 2011-04-01 7:13 ` todo cinap_lenrek @ 2011-04-01 9:30 ` Uriel 2011-04-01 10:18 ` todo cinap_lenrek 0 siblings, 1 reply; 31+ messages in thread From: Uriel @ 2011-04-01 9:30 UTC (permalink / raw) To: 9front On Fri, Apr 1, 2011 at 12:13 AM, <cinap_lenrek@gmx.de> wrote: > why? can't we just fire and forget? server that dont know the > command will just reply with an error no? We could just as well 9p2010 and be done with it. Changing the protocol for this is just stupid, next you will find a trillion equally good reasons to add other extensions. uriel > -- > cinap > > > ---------- Forwarded message ---------- > From: Uriel <uriel@berlinblue.org> > To: 9front@googlegroups.com > Date: Fri, 1 Apr 2011 00:04:18 -0700 > Subject: Re: todo > On Thu, Mar 31, 2011 at 9:40 PM, aiju <aiju@phicode.de> wrote: >> >>> This is plain gratuitous idiotic protocol breaking, you can do the >>> same thing simply by providing an alternative attach name with ctl >>> file(s) for fancy things like moving stuff around. >> >> It doesn't break the protocol at all: Clients which don't need it >> don't have to know about it and if the server doesn't have it the >> client can emulate it. > > But then the client has to negotiate with the server to find out if it > supports the Tmove extension, > it is totally idiotic and retarded, adding it via an alternative > attach name is trivial and doesn't break any shit. > > uriel > ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: todo 2011-04-01 9:30 ` todo Uriel @ 2011-04-01 10:18 ` cinap_lenrek 2011-04-01 10:24 ` todo Uriel 0 siblings, 1 reply; 31+ messages in thread From: cinap_lenrek @ 2011-04-01 10:18 UTC (permalink / raw) To: 9front [-- Attachment #1: Type: text/plain, Size: 918 bytes --] as i read the manpage to Tversion, the client first sends something like 9P2000[.extension] and the server responds with something like 9Pnnnn. so if we add the extension to like kfs or cwfs, we can respond with 9P2010 or something and the mnt driver will use the Tmove rpc. but looking at the implementations... we are in trouble... cwfs: /* * Should check the '.' stuff here. */ if(strcmp(f->version, VERSION9P) == 0){ r->version = VERSION9P; chan->protocol = serve9p2; chan->msize = r->msize; } else r->version = "unknown"; lib9p: respond(...): switch(r->ifcall.type){ default: assert(0); so, just using "P92000" and send blind Tmoves to lib9p based server will crash them... using anything other than "9P2000" will most likely result in the Tversion to fail with old servers. so uriel has a point here... negotiation my ass... but this attach name hack sucks big time... -- cinap [-- Attachment #2: Type: message/rfc822, Size: 6014 bytes --] From: Uriel <uriel@berlinblue.org> To: 9front@googlegroups.com Subject: Re: todo Date: Fri, 1 Apr 2011 02:30:02 -0700 Message-ID: <AANLkTin6CW4x8tJpYUSDcFSEUywRfwhYQ8b3+Uv+eJ3t@mail.gmail.com> On Fri, Apr 1, 2011 at 12:13 AM, <cinap_lenrek@gmx.de> wrote: > why? can't we just fire and forget? server that dont know the > command will just reply with an error no? We could just as well 9p2010 and be done with it. Changing the protocol for this is just stupid, next you will find a trillion equally good reasons to add other extensions. uriel > -- > cinap > > > ---------- Forwarded message ---------- > From: Uriel <uriel@berlinblue.org> > To: 9front@googlegroups.com > Date: Fri, 1 Apr 2011 00:04:18 -0700 > Subject: Re: todo > On Thu, Mar 31, 2011 at 9:40 PM, aiju <aiju@phicode.de> wrote: >> >>> This is plain gratuitous idiotic protocol breaking, you can do the >>> same thing simply by providing an alternative attach name with ctl >>> file(s) for fancy things like moving stuff around. >> >> It doesn't break the protocol at all: Clients which don't need it >> don't have to know about it and if the server doesn't have it the >> client can emulate it. > > But then the client has to negotiate with the server to find out if it > supports the Tmove extension, > it is totally idiotic and retarded, adding it via an alternative > attach name is trivial and doesn't break any shit. > > uriel > ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: todo 2011-04-01 10:18 ` todo cinap_lenrek @ 2011-04-01 10:24 ` Uriel 2011-04-01 11:38 ` todo cinap_lenrek 0 siblings, 1 reply; 31+ messages in thread From: Uriel @ 2011-04-01 10:24 UTC (permalink / raw) To: 9front We already went down the path of new Tmessages and new Tversions with .u, and it was a huge fucking nightmare. I don't see what is so bad about an alternative attach name for this kinds of operations, somebody did something like that for file change notification and other things, it was really neat. uriel On Fri, Apr 1, 2011 at 3:18 AM, <cinap_lenrek@gmx.de> wrote: > as i read the manpage to Tversion, the client first sends something > like 9P2000[.extension] and the server responds with something like > 9Pnnnn. so if we add the extension to like kfs or cwfs, we can > respond with 9P2010 or something and the mnt driver will use the > Tmove rpc. > > but looking at the implementations... we are in trouble... > > cwfs: > /* > * Should check the '.' stuff here. > */ > if(strcmp(f->version, VERSION9P) == 0){ > r->version = VERSION9P; > chan->protocol = serve9p2; > chan->msize = r->msize; > } else > r->version = "unknown"; > > lib9p: > respond(...): > switch(r->ifcall.type){ > default: > assert(0); > > so, just using "P92000" and send blind Tmoves to lib9p based > server will crash them... > > using anything other than "9P2000" will most likely result in > the Tversion to fail with old servers. > > so uriel has a point here... negotiation my ass... but this attach > name hack sucks big time... > > -- > cinap > > > ---------- Forwarded message ---------- > From: Uriel <uriel@berlinblue.org> > To: 9front@googlegroups.com > Date: Fri, 1 Apr 2011 02:30:02 -0700 > Subject: Re: todo > On Fri, Apr 1, 2011 at 12:13 AM, <cinap_lenrek@gmx.de> wrote: >> why? can't we just fire and forget? server that dont know the >> command will just reply with an error no? > > We could just as well 9p2010 and be done with it. > > Changing the protocol for this is just stupid, next you will find a > trillion equally good reasons to add other extensions. > > uriel > >> -- >> cinap >> >> >> ---------- Forwarded message ---------- >> From: Uriel <uriel@berlinblue.org> >> To: 9front@googlegroups.com >> Date: Fri, 1 Apr 2011 00:04:18 -0700 >> Subject: Re: todo >> On Thu, Mar 31, 2011 at 9:40 PM, aiju <aiju@phicode.de> wrote: >>> >>>> This is plain gratuitous idiotic protocol breaking, you can do the >>>> same thing simply by providing an alternative attach name with ctl >>>> file(s) for fancy things like moving stuff around. >>> >>> It doesn't break the protocol at all: Clients which don't need it >>> don't have to know about it and if the server doesn't have it the >>> client can emulate it. >> >> But then the client has to negotiate with the server to find out if it >> supports the Tmove extension, >> it is totally idiotic and retarded, adding it via an alternative >> attach name is trivial and doesn't break any shit. >> >> uriel >> > ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: todo 2011-04-01 10:24 ` todo Uriel @ 2011-04-01 11:38 ` cinap_lenrek 2011-04-01 13:36 ` todo Ethan Grammatikidis 0 siblings, 1 reply; 31+ messages in thread From: cinap_lenrek @ 2011-04-01 11:38 UTC (permalink / raw) To: 9front [-- Attachment #1: Type: text/plain, Size: 1022 bytes --] alternative attach names are a great idea for administating a fileserver... you can kick of dumps or halt the filesystem with a ctl file... way better than a ctl pipe and also provides a back channel with proper perm checking... i see no problem in providing filsystem command for renaming/moving files between directories there too... it is just impossible to make use of this from mv because of the mount/bind indirections/multiple filesystems per server ect. you cant figure out if the ctl file you have really belongs to that file system of the file you are refering to or figure out the attach name of the filesystem of any random file... there might be a exportfs in between ect... the only proper way to implement inter directory renames accessible from mv command is with a 9p protocol change. maybe we can live with a special fscmd and let the user figure out the right filsys name and path? we can make the command format and naming compatible so it works consistently with kfs, cwfs and kenfs. -- cinap [-- Attachment #2: Type: message/rfc822, Size: 8206 bytes --] From: Uriel <uriel@berlinblue.org> To: 9front@googlegroups.com Subject: Re: todo Date: Fri, 1 Apr 2011 03:24:16 -0700 Message-ID: <AANLkTi=gN9j_BQM3ya0KiP6r-xcHRMgZuNCPde-hGkkc@mail.gmail.com> We already went down the path of new Tmessages and new Tversions with .u, and it was a huge fucking nightmare. I don't see what is so bad about an alternative attach name for this kinds of operations, somebody did something like that for file change notification and other things, it was really neat. uriel On Fri, Apr 1, 2011 at 3:18 AM, <cinap_lenrek@gmx.de> wrote: > as i read the manpage to Tversion, the client first sends something > like 9P2000[.extension] and the server responds with something like > 9Pnnnn. so if we add the extension to like kfs or cwfs, we can > respond with 9P2010 or something and the mnt driver will use the > Tmove rpc. > > but looking at the implementations... we are in trouble... > > cwfs: > /* > * Should check the '.' stuff here. > */ > if(strcmp(f->version, VERSION9P) == 0){ > r->version = VERSION9P; > chan->protocol = serve9p2; > chan->msize = r->msize; > } else > r->version = "unknown"; > > lib9p: > respond(...): > switch(r->ifcall.type){ > default: > assert(0); > > so, just using "P92000" and send blind Tmoves to lib9p based > server will crash them... > > using anything other than "9P2000" will most likely result in > the Tversion to fail with old servers. > > so uriel has a point here... negotiation my ass... but this attach > name hack sucks big time... > > -- > cinap > > > ---------- Forwarded message ---------- > From: Uriel <uriel@berlinblue.org> > To: 9front@googlegroups.com > Date: Fri, 1 Apr 2011 02:30:02 -0700 > Subject: Re: todo > On Fri, Apr 1, 2011 at 12:13 AM, <cinap_lenrek@gmx.de> wrote: >> why? can't we just fire and forget? server that dont know the >> command will just reply with an error no? > > We could just as well 9p2010 and be done with it. > > Changing the protocol for this is just stupid, next you will find a > trillion equally good reasons to add other extensions. > > uriel > >> -- >> cinap >> >> >> ---------- Forwarded message ---------- >> From: Uriel <uriel@berlinblue.org> >> To: 9front@googlegroups.com >> Date: Fri, 1 Apr 2011 00:04:18 -0700 >> Subject: Re: todo >> On Thu, Mar 31, 2011 at 9:40 PM, aiju <aiju@phicode.de> wrote: >>> >>>> This is plain gratuitous idiotic protocol breaking, you can do the >>>> same thing simply by providing an alternative attach name with ctl >>>> file(s) for fancy things like moving stuff around. >>> >>> It doesn't break the protocol at all: Clients which don't need it >>> don't have to know about it and if the server doesn't have it the >>> client can emulate it. >> >> But then the client has to negotiate with the server to find out if it >> supports the Tmove extension, >> it is totally idiotic and retarded, adding it via an alternative >> attach name is trivial and doesn't break any shit. >> >> uriel >> > ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: todo 2011-04-01 11:38 ` todo cinap_lenrek @ 2011-04-01 13:36 ` Ethan Grammatikidis 2011-04-01 13:54 ` todo Julius Schmidt 2011-04-01 17:38 ` todo Uriel 0 siblings, 2 replies; 31+ messages in thread From: Ethan Grammatikidis @ 2011-04-01 13:36 UTC (permalink / raw) To: 9front [-- Attachment #1: Type: text/plain, Size: 1867 bytes --] On 1 Apr 2011, at 12:38 pm, cinap_lenrek@gmx.de wrote: > > maybe we can live with a special fscmd and let the user figure out > the right filsys name and path? we can make the command format > and naming compatible so it works consistently with kfs, cwfs and > kenfs. This sounds like it could be a bitch if it's 2 in the morning and you just want to move those few videos you just downloaded to their proper place before going to sleep. >> From: Uriel <uriel@berlinblue.org> >> >> Changing the protocol for this is just stupid, next you will find a >> trillion equally good reasons to add other extensions. Ah, the time-honoured argument against change. :] Move is not just any extension. It doesn't exist for some flaky transient piece of bullshit software that will be forgotten in 5 years time. It exists because storage space has grown faster than storage speed. Not just space, storage use has grown faster than the speed. Then there's the idea of a unified interface to your files. A special extra file to do a special operation (which move really ought not to be) breaks unity and consistency. mv is one of the fundamental file operations, and I for one REALLY don't want it trying to find some 3rd file to send messages to... That's got to be flakey at best, hasn't it? Also it kinda reeks of .git / .hg. If you're working in a subdir of a git repo, git very graciously looks up the tree until it finds .git, but if you try to include one git repo inside another it breaks. There's another thing: How _hard_ will Tmove break anything? How much trouble will it be to fix everything to fail gracefully, either for any bad message or just for Tmove (whichever is easier)? Granted, "old software" isn't necessarily included in "everything" but how much work will it be to find and look into every server in /sys/src/cmd? [-- Attachment #2: Type: text/html, Size: 3296 bytes --] ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: todo 2011-04-01 13:36 ` todo Ethan Grammatikidis @ 2011-04-01 13:54 ` Julius Schmidt 2011-04-01 17:41 ` todo Uriel 2011-04-01 17:38 ` todo Uriel 1 sibling, 1 reply; 31+ messages in thread From: Julius Schmidt @ 2011-04-01 13:54 UTC (permalink / raw) To: 9front > There's another thing: How _hard_ will Tmove break anything? How much trouble will it be to fix everything to fail gracefully, either for any bad message or just for > Tmove (whichever is easier)? Granted, "old software" isn't necessarily included in "everything" but how much work will it be to find and look into every server in > /sys/src/cmd? Clients should do it like this: - send TMove - get RError back if invalid, then do old style copy and delete, or move was successful One possible problem would be servers crashing on invalid messages. That would mean they are *really* fucked up and would make it impossible to use that method. I would not want our code crash remote servers and a special flag on all clients to fix that. (We simply can't fix all the servers out there) ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: todo 2011-04-01 13:54 ` todo Julius Schmidt @ 2011-04-01 17:41 ` Uriel 2011-04-01 19:02 ` todo Ethan Grammatikidis 2011-04-02 14:22 ` todo aiju 0 siblings, 2 replies; 31+ messages in thread From: Uriel @ 2011-04-01 17:41 UTC (permalink / raw) To: 9front On Fri, Apr 1, 2011 at 6:54 AM, Julius Schmidt <aiju@phicode.de> wrote: >> There's another thing: How _hard_ will Tmove break anything? How much >> trouble will it be to fix everything to fail gracefully, either for any bad >> message or just for >> Tmove (whichever is easier)? Granted, "old software" isn't necessarily >> included in "everything" but how much work will it be to find and look into >> every server in >> /sys/src/cmd? > > Clients should do it like this: > - send TMove > - get RError back if invalid, then do old style copy and delete, or > move was successful > > One possible problem would be servers crashing on invalid messages. That > would mean they are *really* fucked up and would make it impossible to > use that method. > I would not want our code crash remote servers and a special flag on all > clients to fix that. > (We simply can't fix all the servers out there). No, any sane server will simply kick out and disconnect any client that sends an *invalid* message, Tmove is not part of 9P and is invalid. 9P is not HTTP or some other asstard protocol that is supposed to deal with any magic crap you dump on it, and that is one of the reasons 9P has remained sane and implementing HTTP properly has become an impossible task. The "be liberal with what you accept and conservative with what you send" dogma is the bullshit the web is built on. uriel ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: todo 2011-04-01 17:41 ` todo Uriel @ 2011-04-01 19:02 ` Ethan Grammatikidis 2011-04-02 14:22 ` todo aiju 1 sibling, 0 replies; 31+ messages in thread From: Ethan Grammatikidis @ 2011-04-01 19:02 UTC (permalink / raw) To: 9front On 1 Apr 2011, at 6:41 pm, Uriel wrote: > > No, any sane server will simply kick out and disconnect any client > that sends an *invalid* message, Tmove is not part of 9P and is > invalid. ... Ah! Yeah, that won't help. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: todo 2011-04-01 17:41 ` todo Uriel 2011-04-01 19:02 ` todo Ethan Grammatikidis @ 2011-04-02 14:22 ` aiju 2011-04-02 14:52 ` todo Ethan Grammatikidis 1 sibling, 1 reply; 31+ messages in thread From: aiju @ 2011-04-02 14:22 UTC (permalink / raw) To: 9front > No, any sane server will simply kick out and disconnect any client > that sends an *invalid* message, Tmove is not part of 9P and is > invalid. 9P is not HTTP or some other asstard protocol that is > supposed to deal with any magic crap you dump on it, and that is one > of the reasons 9P has remained sane and implementing HTTP properly has > become an impossible task. > > The "be liberal with what you accept and conservative with what you > send" dogma is the bullshit the web is built on. Thinking about it, uriel is indeed right ... now we just need to figure which file system a given file is on ... ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: todo 2011-04-02 14:22 ` todo aiju @ 2011-04-02 14:52 ` Ethan Grammatikidis 0 siblings, 0 replies; 31+ messages in thread From: Ethan Grammatikidis @ 2011-04-02 14:52 UTC (permalink / raw) To: 9front On 2 Apr 2011, at 3:22 pm, aiju wrote: > > Thinking about it, uriel is indeed right ... now we just need to > figure which file system a given file is on ... Search up the tree for a file with a special name? Thwack me if I'm being dumb. Or (and this I prefer): a separate tree where all such attaches are mounted so if you're working in /foo/bar/baz/ and bar is a mount, / mvctl/foo/bar/ctl is the file you use to move files in bar. Obviously "/mvctl" is just for example purposes. Then again what if baz is a mount too? Bad idea to send the move request to bar as you might move a file with the same name 'underneath' what you can see in baz. Have to parse your ns first to be sure. Same applies to simply searching up the tree. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: todo 2011-04-01 13:36 ` todo Ethan Grammatikidis 2011-04-01 13:54 ` todo Julius Schmidt @ 2011-04-01 17:38 ` Uriel 1 sibling, 0 replies; 31+ messages in thread From: Uriel @ 2011-04-01 17:38 UTC (permalink / raw) To: 9front I don't really have time for this bullshit discussion, but: > A special extra file to do a special operation (which move really ought not to be) breaks unity and consistency. This is a load of total crap, precisely using an alternative attach name *preserves* the unity and consistency of the current protocol, because instead of having an extra special magic protocol message, you just use read() and write(), Tmove does not apply to most file systems and there are very good reasons it was not part of the protocol already. Crap like Tmove is stuck in the 'files are just for storage' mindset, instead of the 'the file system is the universal API'. Also, any 'flakery' that applies to an alternative attach name applies to Tmove, because you still need to make the right interpretation of the target path, etc. And changing the protocol will break fucking *everything* (and a few more things), we went over this shit with .u, it was a disgrace that split the 9P world in two and further damaged the 'consistency' and 'unity' of the 9P world. In short: stop this fucking madness already. uriel On Fri, Apr 1, 2011 at 6:36 AM, Ethan Grammatikidis <eekee57@fastmail.fm> wrote: > > On 1 Apr 2011, at 12:38 pm, cinap_lenrek@gmx.de wrote: > > maybe we can live with a special fscmd and let the user figure out > the right filsys name and path? we can make the command format > and naming compatible so it works consistently with kfs, cwfs and > kenfs. > > This sounds like it could be a bitch if it's 2 in the morning and you just > want to move those few videos you just downloaded to their proper place > before going to sleep. > > From: Uriel <uriel@berlinblue.org> > > Changing the protocol for this is just stupid, next you will find a > trillion equally good reasons to add other extensions. > > Ah, the time-honoured argument against change. :] Move is not just any > extension. It doesn't exist for some flaky transient piece of bullshit > software that will be forgotten in 5 years time. It exists because storage > space has grown faster than storage speed. Not just space, storage use has > grown faster than the speed. > Then there's the idea of a unified interface to your files. A special extra > file to do a special operation (which move really ought not to be) breaks > unity and consistency. mv is one of the fundamental file operations, and I > for one REALLY don't want it trying to find some 3rd file to send messages > to... That's got to be flakey at best, hasn't it? Also it kinda reeks of > .git / .hg. If you're working in a subdir of a git repo, git very graciously > looks up the tree until it finds .git, but if you try to include one git > repo inside another it breaks. > There's another thing: How _hard_ will Tmove break anything? How much > trouble will it be to fix everything to fail gracefully, either for any bad > message or just for Tmove (whichever is easier)? Granted, "old software" > isn't necessarily included in "everything" but how much work will it be to > find and look into every server in /sys/src/cmd? ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: todo 2011-04-01 0:59 ` todo Uriel 2011-04-01 1:12 ` todo Ethan Grammatikidis 2011-04-01 4:40 ` todo aiju @ 2011-04-01 7:09 ` cinap_lenrek 2 siblings, 0 replies; 31+ messages in thread From: cinap_lenrek @ 2011-04-01 7:09 UTC (permalink / raw) To: 9front [-- Attachment #1: Type: text/plain, Size: 735 bytes --] i dont see where this breaks... if a server doesnt support/implement it, we get just back a Rerror from the server. and mv will do the same thing it did before... copying the file... mv is probably the only program that will make use of the new syscall... there are cases where Tmove can not work like when the source and target are on different file systems... the kernel can figure this out and just let the move syscall fail in that case... maybe Tmove is a bad name... it is really means inter directory rename... we are not really short of p9 opcodes... and the implementation will be in the expected places... 9p is not smb where all kinds of extensions are crammed into complicated sub protocol transactions... -- cinap [-- Attachment #2: Type: message/rfc822, Size: 5360 bytes --] From: Uriel <uriel@berlinblue.org> To: 9front@googlegroups.com Subject: Re: todo Date: Thu, 31 Mar 2011 17:59:57 -0700 Message-ID: <AANLkTikvqCyMdbnn2F9v0+k6HxzLXzMEedSeMDY1uZBc@mail.gmail.com> On Thu, Mar 31, 2011 at 5:30 PM, Ethan Grammatikidis <eekee57@fastmail.fm> wrote: > > On 30 Mar 2011, at 9:02 pm, cinap_lenrek@gmx.de wrote: >> >> - add Tmove to 9p and fileservers This is plain gratuitous idiotic protocol breaking, you can do the same thing simply by providing an alternative attach name with ctl file(s) for fancy things like moving stuff around. uriel > > I'd rather 'consider adding Tmove', it may turn out to suck after all. > >> - remove and replace fossil > > I've always wanted to write a filesystem. No seriously, I have. Am I > qualified to? That's another matter. :D Actually what does this one mean? It > reads like we want to take fossil out & put it back in. > ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: todo 2011-04-01 0:30 ` todo Ethan Grammatikidis 2011-04-01 0:47 ` todo Jacob Todd 2011-04-01 0:59 ` todo Uriel @ 2011-04-01 6:14 ` Taru Karttunen 2 siblings, 0 replies; 31+ messages in thread From: Taru Karttunen @ 2011-04-01 6:14 UTC (permalink / raw) To: Ethan Grammatikidis, 9front On Fri, 1 Apr 2011 01:30:40 +0100, Ethan Grammatikidis <eekee57@fastmail.fm> wrote: > > - remove and replace fossil > > I've always wanted to write a filesystem. No seriously, I have. Am I > qualified to? That's another matter. :D Actually what does this one > mean? It reads like we want to take fossil out & put it back in. I think the plan was cwfs for the start. - Taru Karttunen ^ permalink raw reply [flat|nested] 31+ messages in thread
* TODO @ 2011-05-02 7:30 Uriel 2011-05-02 13:25 ` TODO Julius Schmidt 2011-05-02 13:45 ` TODO Jacob Todd 0 siblings, 2 replies; 31+ messages in thread From: Uriel @ 2011-05-02 7:30 UTC (permalink / raw) To: 9front More items from an ancient TODO, some probably obsolete, others controversial, so I didn't add any of them to the issue tracker, but anyone that thinks any of them is a good idea feel free to add them. * g " "" * dan cross' walk and sor * /contrib/andrey/cmd/lsof.c * newuser script * inferno * make snarf work by default * pegasus? * mpeg player * nupas * graphviz * synaptic (can't remember what this was about, maybe check 9fans archives?) * freetype: http://mirtchovski.com/p9/freetype/ * http://ninetimes.cat-v.org/news/2008-11-20-1_Cpu_temperature_info * drivers * broadcom * ac'97 * radeon? * usb keyboard * linuxemu * equis * python * perl ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: TODO 2011-05-02 7:30 TODO Uriel @ 2011-05-02 13:25 ` Julius Schmidt 2011-05-02 17:03 ` TODO Uriel 2011-05-02 13:45 ` TODO Jacob Todd 1 sibling, 1 reply; 31+ messages in thread From: Julius Schmidt @ 2011-05-02 13:25 UTC (permalink / raw) To: 9front > * newuser script > * nupas > * graphviz > * freetype: http://mirtchovski.com/p9/freetype/ ack > * /contrib/andrey/cmd/lsof.c grep file /proc/*/fd probably a good idea nevertheless > * inferno include the whole inferno tree? > * mpeg player hahaha have fun writing > * http://ninetimes.cat-v.org/news/2008-11-20-1_Cpu_temperature_info better to have it in userspace there are over 9000 interfaces to CPU temp etc > * drivers > * broadcom we got that one now :) (and erik is fixing and 64 bitting it) > * ac'97 i got one somewhere, i should commit it > * radeon? > * usb keyboard don't we have these already? > * linuxemu include a whole Debian tree or what? > * equis horses are always good > * synaptic (can't remember what this was about, maybe check 9fans archives?) > * python > * perl jesus christ what the fuck? ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: TODO 2011-05-02 13:25 ` TODO Julius Schmidt @ 2011-05-02 17:03 ` Uriel 2011-05-02 18:24 ` TODO Iruatã Souza 0 siblings, 1 reply; 31+ messages in thread From: Uriel @ 2011-05-02 17:03 UTC (permalink / raw) To: 9front On Mon, May 2, 2011 at 3:25 PM, Julius Schmidt <aiju@phicode.de> wrote: >> * newuser script >> * nupas >> * graphviz >> * freetype: http://mirtchovski.com/p9/freetype/ > > ack > >> * /contrib/andrey/cmd/lsof.c > > grep file /proc/*/fd > probably a good idea nevertheless > >> * inferno > > include the whole inferno tree? Yea, why not? Or at least the Plan 9 hosted bits. >> * mpeg player > > hahaha > have fun writing I think I was thinking of the player fgb ported, it is in contrib. >> >> * http://ninetimes.cat-v.org/news/2008-11-20-1_Cpu_temperature_info > > better to have it in userspace > there are over 9000 interfaces to CPU temp etc >> >> * drivers >> * broadcom > > we got that one now :) > (and erik is fixing and 64 bitting it) There are multiple broadcom chips, I know some people were passing a driver around years ago, but as usual was never publicly released as far as I know. >> >> * ac'97 > > i got one somewhere, i should commit it There are at least two, sometimes one works, sometimes the other works... >> * radeon? >> * usb keyboard > > don't we have these already? No idea, I stopped paying attention a while ago, have there been any news on either front? (I think nemo had a usb kb driver, did that get merged?) >> * linuxemu > > include a whole Debian tree or what? >> >> * equis > > horses are always good >> >> * synaptic (can't remember what this was about, maybe check 9fans >> archives?) >> * python >> * perl > > jesus christ what the fuck? > ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: TODO 2011-05-02 17:03 ` TODO Uriel @ 2011-05-02 18:24 ` Iruatã Souza 2011-05-02 19:33 ` TODO ron minnich 0 siblings, 1 reply; 31+ messages in thread From: Iruatã Souza @ 2011-05-02 18:24 UTC (permalink / raw) To: 9front http://code.google.com/p/plan9front/wiki/TODO ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: TODO 2011-05-02 18:24 ` TODO Iruatã Souza @ 2011-05-02 19:33 ` ron minnich 0 siblings, 0 replies; 31+ messages in thread From: ron minnich @ 2011-05-02 19:33 UTC (permalink / raw) To: 9front As long as it is a fork, which it is, why not remove contrib as a separate entity? Pu all in /usr/src? ron ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: TODO 2011-05-02 7:30 TODO Uriel 2011-05-02 13:25 ` TODO Julius Schmidt @ 2011-05-02 13:45 ` Jacob Todd 1 sibling, 0 replies; 31+ messages in thread From: Jacob Todd @ 2011-05-02 13:45 UTC (permalink / raw) To: 9front [-- Attachment #1: Type: text/plain, Size: 107 bytes --] All things 'synaptic' (double tap for clicking and whatnot) have workes on my dell inspiron 1000 for ages. [-- Attachment #2: Type: text/html, Size: 122 bytes --] ^ permalink raw reply [flat|nested] 31+ messages in thread
* TODO @ 2018-02-24 19:53 Kurt H Maier 0 siblings, 0 replies; 31+ messages in thread From: Kurt H Maier @ 2018-02-24 19:53 UTC (permalink / raw) To: 9front Hello: http://wiki.9front.org/todo is horribly out of date and has too much whimsy. I propose moving the actual to-do items to a file /lib/TODO and just including it with 9front. This might make it easier to keep the list up to date. Maybe we can even add a line to the top telling Ausl�nder to email this list if they have suggestions. What do you think? khm ^ permalink raw reply [flat|nested] 31+ messages in thread
end of thread, other threads:[~2018-02-24 19:53 UTC | newest] Thread overview: 31+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <405d44d0ddf24c71ff94c72804f03bec@gmx.de> 2011-03-30 20:57 ` todo Stanley Lieber 2011-03-30 22:39 ` todo cinap_lenrek 2011-03-30 22:46 ` todo Stanley Lieber 2011-03-30 22:04 ` todo uriel 2011-04-01 0:30 ` todo Ethan Grammatikidis 2011-04-01 0:47 ` todo Jacob Todd 2011-04-01 0:59 ` todo Uriel 2011-04-01 1:12 ` todo Ethan Grammatikidis 2011-04-01 4:40 ` todo aiju 2011-04-01 7:04 ` todo Uriel 2011-04-01 7:13 ` todo cinap_lenrek 2011-04-01 9:30 ` todo Uriel 2011-04-01 10:18 ` todo cinap_lenrek 2011-04-01 10:24 ` todo Uriel 2011-04-01 11:38 ` todo cinap_lenrek 2011-04-01 13:36 ` todo Ethan Grammatikidis 2011-04-01 13:54 ` todo Julius Schmidt 2011-04-01 17:41 ` todo Uriel 2011-04-01 19:02 ` todo Ethan Grammatikidis 2011-04-02 14:22 ` todo aiju 2011-04-02 14:52 ` todo Ethan Grammatikidis 2011-04-01 17:38 ` todo Uriel 2011-04-01 7:09 ` todo cinap_lenrek 2011-04-01 6:14 ` todo Taru Karttunen 2011-05-02 7:30 TODO Uriel 2011-05-02 13:25 ` TODO Julius Schmidt 2011-05-02 17:03 ` TODO Uriel 2011-05-02 18:24 ` TODO Iruatã Souza 2011-05-02 19:33 ` TODO ron minnich 2011-05-02 13:45 ` TODO Jacob Todd 2018-02-24 19:53 TODO Kurt H Maier
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).