TODO

TODO

[Kurt H Maier]

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

Re: [9front] TODO

[Stanley Lieber]

On Feb 24, 2018, at 2:53 PM, Kurt H Maier <khm@sciops.net> wrote:
> 
> 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?

yes

sl

Re: TODO

[ron minnich]

As long as it is a fork, which it is, why not remove contrib as a
separate entity? Pu all in /usr/src?

ron

Re: TODO

[Iruatã Souza]

http://code.google.com/p/plan9front/wiki/TODO

Re: TODO

[Uriel]

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?
>

Re: TODO

[Jacob Todd]

[-- 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 --]

Re: TODO

[Julius Schmidt]

> * 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?

TODO

[Uriel]

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

Re: todo

[Ethan Grammatikidis]

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.

Re: todo

[aiju]

> 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 ...

Re: todo

[Ethan Grammatikidis]

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.

Re: todo

[Uriel]

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

Re: todo

[Uriel]

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?

Re: todo

[Julius Schmidt]

> 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)

Re: todo

[Ethan Grammatikidis]

[-- 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 --]

Re: todo

[cinap_lenrek]

[-- 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
>>
>

Re: todo

[Uriel]

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
>>
>

Re: todo

[cinap_lenrek]

[-- 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
>

Re: todo

[Uriel]

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
>

Re: todo

[cinap_lenrek]

[-- 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

Re: todo

[cinap_lenrek]

[-- 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.
>

Re: todo

[Uriel]

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

Re: todo

[Taru Karttunen]

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

Re: todo

[aiju]

> 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.

Re: todo

[Ethan Grammatikidis]

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?

Re: todo

[Uriel]

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.
>

Re: todo

[Jacob Todd]

[-- 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 --]

Re: todo

[Ethan Grammatikidis]

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.

Re: todo

[Stanley Lieber]

>> - 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

Re: todo

[cinap_lenrek]

> - 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

Re: todo

[uriel]

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

Re: todo

[Stanley Lieber]

> 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