[9fans] spaces in filenames

[9fans] spaces in filenames

[smiley]

Hi,

>From time to time, the issue of having spaces in file names seems to
come up on this list, mostly in the context of discussions on find, du,
Acme, and trfs(4).  All the discussions I've found suggest that file
names with whitespace in them are *legal* on fossil.  I'm running a
9atom 9pcf kernel copied verbatim from the 9atom .iso, on an otherwise
stock Plan 9 4e fossil+venti install.  However, I can't seem to create
files with with spaces in their names.  The resulting error string
reports invalid characters in the file name.  Why doesn't this work?
Has the ability to have spaces in file names been removed from fossil?
If so, then how is it possible that there are files such as
'/n/sources/contrib/steve/file with spaces' hanging around?

While I'm perfectly happy using underscores in lieu of spaces in *my*
file names, there are a number of APE packages (i.e., fgb/lcms)
containing files with spaces in their names.  Since those are the names
used in replica(1), I'm unable to contrib/install(1) any of these
packages.  Are there any known fixes or workarounds for this problem?
(I doubt trfs(4) would help, because the ape would still be naming the
file with spaces, unless specifically modified to match the trfs(4)
translation.)

What's the theory behind excluding whitespace from filenames?  Was it
causing too much discussion on the list?  ;) Since Plan 9 was a total
re-think of Unix, I have to wonder why this problem wasn't fixed.  If
Plan 9 used 0x00 (NUL) as the record separator (instead of newline),
many of these types of problems could be averted.  Why don't we?

Also, if anyone knows where I can find 9fans archives prior to March
2008, please let me know.  The archives I was able to find only go back
that far.

Also, quanstro, would you whitelist me?  I can't seem to get mail to you
off-list.  Thanks!

--
+---------------------------------------------------------------+
|E-Mail: smiley@zenzebra.mv.com             PGP key ID: BC549F8B|
|Fingerprint: 9329 DB4A 30F5 6EDA D2BA  3489 DAB7 555A BC54 9F8B|
+---------------------------------------------------------------+

Re: [9fans] spaces in filenames

[Rob Pike]

Sometime around, maybe, 2000, I flipped the bit in the frogs table so
spaces were legal in file names, for two reasons: we were seeing
spaces in file names from remote systems and seemed simpler to accept
them than to remap them, and I wanted to know how it would affect
things.

Not all software has caught up, I suspect.  It's only been a decade.

-rob

Re: [9fans] spaces in filenames

[erik quanstrom]

>
> Not all software has caught up, I suspect.  It's only been a decade.
>

my software hasn't.  i'm just a philistine.

- erik

Re: [9fans] spaces in filenames

[dexen deVries]

On Tuesday 26 of April 2011 20:42:49 Rob Pike wrote:
> Sometime around, maybe, 2000, I flipped the bit in the frogs table so
> spaces were legal in file names, for two reasons: we were seeing
> spaces in file names from remote systems and seemed simpler to accept
> them than to remap them, and I wanted to know how it would affect
> things.
>
> Not all software has caught up, I suspect.  It's only been a decade.


on the topic, is acme still your favorite editor, Rob?
asking, cause it is mine, and about the only thing i miss in it is sensible
support for whitespace in pathnames. i'm using the p9p version, btw.


--
dexen deVries

``One can't proceed from the informal to the formal by formal means.''

Re: [9fans] spaces in filenames

[Rob Pike]

I still use acme.  My solution for spaces in file names is to avoid
them.  That might not work for everyone.

-rob

Re: [9fans] spaces in filenames

[Paul Lalonde]

[-- Attachment #1: Type: text/plain, Size: 523 bytes --]

I mostly run acme from inferno (acme-SAC), and live with trfs to take care
of my windows and mac paths.  My linux paths are much better behaved, and so
I run from p9p there.

Paul

On Tue, Apr 26, 2011 at 12:31 PM, Rob Pike <robpike@gmail.com> wrote:

> I still use acme.  My solution for spaces in file names is to avoid
> them.  That might not work for everyone.
>
> -rob
>
>


--
I'm migrating my email.  plalonde@telus.net will soon be disconnected.
 Please use paul.a.lalonde@gmail.com from now on.

[-- Attachment #2: Type: text/html, Size: 982 bytes --]

Re: [9fans] spaces in filenames

[Digby Tarvin]

I was always happy with the traditional Unix approach - Kernel allows
anything unless there is a good reason not to (ie no NULL or '/').
Anything else is an application problem that usually required
some ingenuity if you really wanted to break convention.

But then, I have never been a big fan of spaces in filenames so
varying levels of support in userland was not a big concern.

I can remember amusing myself once as an undergraduate, deleting and
creating files till I got the right inode numbers to allow a judicious
choice of binary file names to result in a directory that was a
valid executable a.out image.

DigbyT
--
Digby R. S. Tarvin                                          digbyt(at)digbyt.com
http://www.digbyt.com

Re: [9fans] spaces in filenames

[erik quanstrom]

On Wed Apr 27 09:12:15 EDT 2011, digbyt@acm.org wrote:
> I was always happy with the traditional Unix approach - Kernel allows
> anything unless there is a good reason not to (ie no NULL or '/').
> Anything else is an application problem that usually required
> some ingenuity if you really wanted to break convention.

port/chan.c:/^char isfrog

- erik

Re: [9fans] spaces in filenames

[Steve Simon]

> I can remember amusing myself once as an undergraduate, deleting and
> creating files till I got the right inode numbers to allow a judicious
> choice of binary file names to result in a directory that was a
> valid executable a.out image.

Wonderful!

This made me laugh loud enough to make everyone in the office turn round.

-Steve

Re: [9fans] spaces in filenames

[Peter A. Cejchan]

[-- Attachment #1: Type: text/plain, Size: 89 bytes --]

spaces in filenames.. does not it break the rules?? Who actually needs
them??

++pac

[-- Attachment #2: Type: text/html, Size: 100 bytes --]

Re: [9fans] spaces in filenames (and filesystems...)

[Digby Tarvin]

On Thu, Apr 28, 2011 at 11:58:01AM +0200, Peter A. Cejchan wrote:
> spaces in filenames.. does not it break the rules?? Who actually needs
> them??
>
> ++pac

Mostly people who have grown up with graphical user interfaces and
have no appreciation of the command line parsing complexity it
adds I think. And of course others that have to interract with
such people, such as sharing filesystems with them.

On a slightly related topics, one of my constant headaches lately
is the problem of deciding what filesystem to put on large capacity
removeable storage to give me maximum interoperability...

What I really want is somthing that I can copy files to and from
from any of my OSs without losing meta-data.

NTFS seems to be reasonably capable, but pervesely designed to be
difficult to write to other than from Windows. FAT32 has limitations
such as with the metadata it can represent, and anything else is
problematic with certain commonly used proprietary OSs.

If there was one clear winner, then I suppose filesystem drivers could
be (maybe are) made available for the proprietary systems. Perhaps
this is what UFS was designed for if it is not overly optimised
for optical media.

Anyone have any ideas here?

Regards,
DigbyT
--
Digby R. S. Tarvin                                          digbyt(at)digbyt.com
http://www.digbyt.com

Re: [9fans] portable filesystem (was: spaces in filenames (and filesystems...))

[dexen deVries]

On Thursday 28 of April 2011 14:11:27 Digby Tarvin wrote:
> On a slightly related topics, one of my constant headaches lately
> is the problem of deciding what filesystem to put on large capacity
> removeable storage to give me maximum interoperability...
> 
> What I really want is somthing that I can copy files to and from
> from any of my OSs without losing meta-data.

ext2/ext3 seems to work between windows and linux for free [1], and macos x 
with some payment [2] or perhaps for free via FUSE.
surprisingly, you can even use LUKS [3] with it and it still works r/w between 
windows and linux.

no idea about p9, sorry, but there used to be a r/o ext2 driver.

you can freely convert filesystem between ext2 and ext3 mode on linux.


at some point i had that crazy idea to have a pendrive formatted in ext3 or 
nilfs2, with small auxiliary partition with a virtual machine -- and use the 
virtual machine as a filesystem server when on hostile OS.


personally, i'd love to have nilfs2 [4] ported to p9 and windows; but i guess 
it's matter of future.


[1] http://www.ext2fsd.com/
[2] (lost the link, sorry)
[3] http://www.freeotfe.org/ on windows, cryptsetup on linux
[4] http://www.nilfs.org/

-- 
dexen deVries

[[[↓][→]]]

``In other news, STFU and hack.''
mahmud, in response to Erann Gat's ``How I lost my faith in Lisp''
http://news.ycombinator.com/item?id=2308816

Re: [9fans] portable filesystem (was: spaces in filenames (and

[Richard Miller]

> no idea about p9, sorry, but there used to be a r/o ext2 driver.

not just r/o - ext2srv(4)

Re: [9fans] portable filesystem (was: spaces in filenames (and filesystems...))

[Digby Tarvin]

On Thu, Apr 28, 2011 at 02:35:56PM +0200, dexen deVries wrote:
> On Thursday 28 of April 2011 14:11:27 Digby Tarvin wrote:
> > On a slightly related topics, one of my constant headaches lately
> > is the problem of deciding what filesystem to put on large capacity
> > removeable storage to give me maximum interoperability...
> >
> > What I really want is somthing that I can copy files to and from
> > from any of my OSs without losing meta-data.
>
> ext2/ext3 seems to work between windows and linux for free [1], and macos x
> with some payment [2] or perhaps for free via FUSE.
> surprisingly, you can even use LUKS [3] with it and it still works r/w between
> windows and linux.
>
> no idea about p9, sorry, but there used to be a r/o ext2 driver.
>
> you can freely convert filesystem between ext2 and ext3 mode on linux.

Thanks. I did experiment with a couple of Windows based ext2/ext3 options
a while ago, with limited success. I dont remember the details, but the
filesystem I wanted to read was rejected with an obscure error message.
I think the fac suggested re-formatting my filesystem might help, and
that put me off.

But as I said, that was quite a while ago, so maybe it is worth revisiting.
Ext2fsd looks promising.

However I do wish that at least the Unix world would settle on a common
filesystem format to support (in addition whatever is native) other than
FAT32 or NTFS. I dont currently use MACOS X, but I do use BSD on some
servers. If I go Ext2/Ext3 then I am probably reducing my interoperability
with more esoteric operating systems, which might be livable but is
unfortunate.

> at some point i had that crazy idea to have a pendrive formatted in ext3 or
> nilfs2, with small auxiliary partition with a virtual machine -- and use the
> virtual machine as a filesystem server when on hostile OS.

Not a bad idea, but you probably want an intelligent device able to
run the virtual machine itself (in which case it isnt really virtual),
otherwise you are limited to hostile os's with virtual machine support.

Perhaps a file server on a wireless or usb equipped smart phone...
I have a small wireless hotspot that also can serve files from an
optional MicroSD.

But I am thinking more of the 2TB or more USB drives that are now
quite affordable, but more useful if not tied to a single OS.

> personally, i'd love to have nilfs2 [4] ported to p9 and windows; but i guess
> it's matter of future.

Nice. I hadnt come across that one.

But What I think is really needed for this sort of application is a
filesystem with:
	Minimal restrictions of file size (64 bit addresses)
	Maximum versatility in FS topology (hard link support etc)
	Minimal restriction on file names (character set, length)
	Maximum support for all conceiveable meta-data.

My off the top of the head solution would be a filesystem were each file
has two open ended data forks. One for conventional file content, and the
other used for tagged meta-data. Each OS supporting the filesystem would
be able to define meta-data fields such that all meta data meaningful to the
original filesystem could be retained in files copied to the removeable
system, and mapped to ANSI equivalent standards meta data fields where
appropriate. File accesses would interpret native metadata with fallback
to the ANSI as required. I suppose it should even be able to suport slashes
and nulls in file names, although that would make such fules hard to
deal with from Unix.

At least it would be usable as a universal backup and file transfer medium.

Failing that, a simple and universally adopted filesystem - like FAT, but
without the stupid limitations, would be a step forward.

Regards,
DigbyT
--
Digby R. S. Tarvin                                          digbyt(at)digbyt.com
http://www.digbyt.com

Re: [9fans] portable filesystem (was: spaces in filenames (and filesystems...))

[dexen deVries]

On Thursday 28 of April 2011 16:00:53 Digby Tarvin wrote:
> > at some point i had that crazy idea to have a pendrive formatted in ext3
> > or nilfs2, with small auxiliary partition with a virtual machine -- and
> > use the virtual machine as a filesystem server when on hostile OS.
> 
> Not a bad idea, but you probably want an intelligent device able to
> run the virtual machine itself (in which case it isnt really virtual),
> otherwise you are limited to hostile os's with virtual machine support.
> 
> Perhaps a file server on a wireless or usb equipped smart phone...
> I have a small wireless hotspot that also can serve files from an
> optional MicroSD.

funny thing, my current pendrive (which really is nokia n900 phone) has 
abundance of powerful hardware -- cpu, ram and 32GB + microSD block storage. 
you got me fantasizing.

9p served over usb (either directly, as mentioned recently in somebody's post 
about registering usb ids), or over tcp/ip over usb would be cool. if only 
various OSes interfaced with that easily.

another silly, but perhaps doable, approach could be to make the phone serve 
either ext2/ext3 or fat, translated on-the-fly from whatever's the underlying 
fs. as in, the (say) fat would not reside literally on the device, but 
relevant parts would be generated on-demand by the phone in its ram and 
presented as a blockdevice over usb mass storage proto.

in a way, a reverse of typical p9 fileserver -- read files, serve filesystem 
image.


um, how crazy is that?


-- 
dexen deVries

[[[↓][→]]]

``In other news, STFU and hack.''
mahmud, in response to Erann Gat's ``How I lost my faith in Lisp''
http://news.ycombinator.com/item?id=2308816

Re: [9fans] portable filesystem

[smiley]

dexen deVries <dexen.devries@gmail.com> writes:

tar?  webdav?

> in a way, a reverse of typical p9 fileserver -- read files, serve filesystem
> image.

I was thinking of that.  An embedded Linux or Plan 9 device as USB
client, presenting an MSD interface.  It could present a number of
partitions, each with an partition/fs type liked by different OSes.
Whichever partition ends up getting read by the OS selects the fs that
the device serves.

If the device presented a USB network interface, various network servers
could be used... webdav, FTP, etc.  Think NAS-in-your-pocket.

--
+---------------------------------------------------------------+
|E-Mail: smiley@zenzebra.mv.com             PGP key ID: BC549F8B|
|Fingerprint: 9329 DB4A 30F5 6EDA D2BA  3489 DAB7 555A BC54 9F8B|
+---------------------------------------------------------------+

Re: [9fans] portable filesystem (was: spaces in filenames (and filesystems...))

[Digby Tarvin]

On Thu, Apr 28, 2011 at 04:13:17PM +0200, dexen deVries wrote:
>
> funny thing, my current pendrive (which really is nokia n900 phone) has
> abundance of powerful hardware -- cpu, ram and 32GB + microSD block storage.
> you got me fantasizing.
>
> 9p served over usb (either directly, as mentioned recently in somebody's post
> about registering usb ids), or over tcp/ip over usb would be cool. if only
> various OSes interfaced with that easily.
>
> another silly, but perhaps doable, approach could be to make the phone serve
> either ext2/ext3 or fat, translated on-the-fly from whatever's the underlying
> fs. as in, the (say) fat would not reside literally on the device, but
> relevant parts would be generated on-demand by the phone in its ram and
> presented as a blockdevice over usb mass storage proto.
>
> in a way, a reverse of typical p9 fileserver -- read files, serve filesystem
> image.
>
>
> um, how crazy is that?
>
Well, if you are going to serve in a format that is distinct from what
is actually used on the physical media, why not just provide servers for
multiple formants - 9p, nfs, smb etc..

I think there are some network enabled external drives that already
do that (maybe not the 9p yet)..

Of course if you are backing up filesystems, then you still really need
a the media and served formats to be capable of preserving all relevent
metadata.

I encountered this most recently on a project where I was developing
an embedded Linux application for a client whose development environment
was exclusively Windows cross development based. I developed on my Linux
laptop, but they wanted the kernel source tree checked into their surround SCM.
I tried using samba to copy the tree to windows (which hosted the surround
client) but of course it failed after about half an hour due to some
incompatible file names. Trying to check in a complete vmware image
exceeded the maximum file size, and in any case would have defeated
the revision management capabilities. Any renaming of files would have
broken who knows how many parts of the convoluted set of makefiles
and scripts.

If you only care about the contents of a modest number of files,
interoperability isnt such a big problem. If you want to be able
to make accurate backups of entire filesystems then it gets hard
if the target is not a natice filesystem format.

Regards,
DigbyT
--
Digby R. S. Tarvin                                          digbyt(at)digbyt.com
http://www.digbyt.com

Re: [9fans] portable filesystem (was: spaces in filenames (and filesystems...))

[dexen deVries]

On Thursday 28 of April 2011 16:00:53 Digby Tarvin wrote:
> But What I think is really needed for this sort of application is a
> filesystem with:
> 	Minimal restrictions of file size (64 bit addresses)
> 	Maximum versatility in FS topology (hard link support etc)
> 	Minimal restriction on file names (character set, length)
> 	Maximum support for all conceiveable meta-data.
> 
> My off the top of the head solution would be a filesystem were each file
> has two open ended data forks. One for conventional file content, and the
> other used for tagged meta-data. Each OS supporting the filesystem would
> be able to define meta-data fields such that all meta data meaningful to
> the original filesystem could be retained in files copied to the
> removeable system, and mapped to ANSI equivalent standards meta data
> fields where appropriate. File accesses would interpret native metadata
> with fallback to the ANSI as required. I suppose it should even be able to
> suport slashes and nulls in file names, although that would make such
> fules hard to deal with from Unix.
> 
> At least it would be usable as a universal backup and file transfer medium.
> 
> Failing that, a simple and universally adopted filesystem - like FAT, but
> without the stupid limitations, would be a step forward.


long time ago, iso9660 was supplanted/extended in-line by jolliet and/or ufs. 
the new filesystem was interleaved with the iso9660. control structures were 
mostly separate, partly shared; bulk data was just shared.

perhaps something along those lines could be doable with `smart' pendrives 
(like my nokia n900 phone), that would keep all two/three fses in sync.

or, just have two or three filesystems residing at separate addresses 
(partitions?) of block device, but having shared de-duplicating backend like 
venti. so the bulk data doesn't occupy more blocks than needed.


meta: terribly sorry for spamming with those very hairy ideas.


-- 
dexen deVries

[[[↓][→]]]

``In other news, STFU and hack.''
mahmud, in response to Erann Gat's ``How I lost my faith in Lisp''
http://news.ycombinator.com/item?id=2308816

Re: [9fans] spaces in filenames (and filesystems...)

[Ethan Grammatikidis]

On 28 Apr 2011, at 1:11 pm, Digby Tarvin wrote:

> On Thu, Apr 28, 2011 at 11:58:01AM +0200, Peter A. Cejchan wrote:
>> spaces in filenames.. does not it break the rules?? Who actually
>> needs
>> them??

Well, for one thing it's much more natural to type a space than a
hyphen or an underscore. For another, I for one am not likely to go
through my system renaming the kajillion files I have with spaces in
their names, particularly because I'm not sure what would break if I
did.

>>
>> ++pac
>
> Mostly people who have grown up with graphical user interfaces and
> have no appreciation of the command line parsing complexity it
> adds I think. And of course others that have to interract with
> such people, such as sharing filesystems with them.

I'm surprised nobody's noted that rc handles spaces in filenames with
far less complexity than Bourne shell. Bourne shell makes things
complex by getting all paranoid-obsessive over word-splitting: it
must do it at every possible opportunity unless explicitly commanded
otherwise using a quoting method which also has other effects.

rc is much more sensible, handling spaces transparently in my typical
usage: I pick a unique bit out of the middle of the filename and
surround that with asterisks. rc does not attempt to split the
resultant word whatever you do with it. Perhaps the eval builtin will
split it but not much else will.

Parsing the output of programs which return filenames is the only
common case where I see any complexity from spaces, and then the
complexity only consists of setting and reverting $ifs. Granted that
could be smoother still, especially where you want a big file list in
for().

> On a slightly related topics, one of my constant headaches lately
> is the problem of deciding what filesystem to put on large capacity
> removeable storage to give me maximum interoperability...

Please don't run one topic into another, and please don't use reply
to start a new topic. Some of us rely on threaded view, and some mail
readers organise threads by a hidden In-Reply-To header.

Re: [9fans] spaces in filenames (and filesystems...)

[erik quanstrom]

> Parsing the output of programs which return filenames is the only
> common case where I see any complexity from spaces, and then the
> complexity only consists of setting and reverting $ifs. Granted that
> could be smoother still, especially where you want a big file list in
> for().

be careful.  setting ifs is global, and changes ifs for the whole
command, and doesn't change the behavior of external programs.
so it is both less and more than you want.

- erik

Re: [9fans] spaces in filenames (and filesystems...)

[Ethan Grammatikidis]

On 29 Apr 2011, at 3:00 pm, erik quanstrom wrote:

>> Parsing the output of programs which return filenames is the only
>> common case where I see any complexity from spaces, and then the
>> complexity only consists of setting and reverting $ifs. Granted that
>> could be smoother still, especially where you want a big file list in
>> for().
>
> be careful.  setting ifs is global, and changes ifs for the whole
> command, and doesn't change the behavior of external programs.
> so it is both less and more than you want.

I always change it back immediately; a nuisance in for() as it has to
be set before and re-set inside. I'm considering whether a new shell
builtin would be desirable, similar to ` but always splitting on
newlines and only newlines, regardless of $ifs.

Re: [9fans] spaces in filenames (and filesystems...)

[erik quanstrom]

> I always change it back immediately; a nuisance in for() as it has to
> be set before and re-set inside.  I'm considering whether a new shell
> builtin would be desirable, similar to ` but always splitting on
> newlines and only newlines, regardless of $ifs.

this is one thing that byron understood in his version of rc.
he had
	x=``ifs {cmd}
the `` was required since `singleton was allowed in his version.
i think that one could just extend the grammar to allow
	x=`ifs {cmd}
and i think it would be even better if it were
	x=`splitchars {cmd}
so ifs is never set.

- erik

Re: [9fans] spaces in filenames (and filesystems...)

[Ethan Grammatikidis]

On Fri, 29 Apr 2011 11:17 -0400, "erik quanstrom"
<quanstro@labs.coraid.com> wrote:
> > I always change it back immediately; a nuisance in for() as it has to
> > be set before and re-set inside.  I'm considering whether a new shell
> > builtin would be desirable, similar to ` but always splitting on
> > newlines and only newlines, regardless of $ifs.
>
> this is one thing that byron understood in his version of rc.
> he had
> 	x=``ifs {cmd}
> the `` was required since `singleton was allowed in his version.
> i think that one could just extend the grammar to allow
> 	x=`ifs {cmd}
> and i think it would be even better if it were
> 	x=`splitchars {cmd}
> so ifs is never set.

I don't quite understand the first two examples. Do they set ifs only
within the {} ? I guess that risks breaking any scripts you might want
to run as cmd, so yeah, the 3rd looks good.

Re: [9fans] spaces in filenames (and filesystems...)

[erik quanstrom]

> > this is one thing that byron understood in his version of rc.
> > he had
> > 	x=``ifs {cmd}
> > the `` was required since `singleton was allowed in his version.
> > i think that one could just extend the grammar to allow
> > 	x=`ifs {cmd}
> > and i think it would be even better if it were
> > 	x=`splitchars {cmd}
> > so ifs is never set.
>
> I don't quite understand the first two examples. Do they set ifs only
> within the {} ? I guess that risks breaking any scripts you might want
> to run as cmd, so yeah, the 3rd looks good.

i implemented the 3d this evening in a compatable way with
Traditional Rc.  there's an argument that it's not completely
necessary, but it's so easy to make a mistake and type this

	ifs=$something x=`{something}

leaving ifs set rather than the intended

	ifs=$something {x=`{something}}

i also don't see a argument against making the splitting string
local to the backq.  i don't believe i've ever written a script that
uses the fact that ifs can be set once and reused with it's nonstandard
value.

- erik

----

; 8.out
broken! x=`{echo a b c d}
broken! whatis x
x=(a b c d)
broken! x=`/$nl {pwd}
broken! whatis x
x=(usr quanstro src rc)
broken! ifs=/$nl {x=`{pwd}}
broken! whatis x
x=(usr quanstro src rc)

broken! diffy -c *.[chy]
diff -c /n/dump/2011/0429/usr/quanstro/src/rc/code.c code.c
/n/dump/2011/0429/usr/quanstro/src/rc/code.c:145,158 - code.c:145,167
  		emitf(Xconc);
  		break;
  	case '`':
+ 		emitf(Xmark);
+ 		if(c0==0){
+ 			emitf(Xword);
+ 			emits(strdup("ifs"));
+ 			emitf(Xdol);
+ 		}else{
+ 			outcode(c0, 0, brkaddr);
+ 			emitf(Xglob);
+ 		}
  		emitf(Xbackq);
  		if(havefork){
  			p = emiti(0);
- 			outcode(c0, 0, brkaddr);
+ 			outcode(c1, 0, brkaddr);
  			emitf(Xexit);
  			stuffdot(p);
  		} else
- 			emits(fnstr(c0));
+ 			emits(fnstr(c1));
  		break;
  	case ANDAND:
  		outcode(c0, 0, brkaddr);
diff -c /n/dump/2011/0429/usr/quanstro/src/rc/havefork.c havefork.c
/n/dump/2011/0429/usr/quanstro/src/rc/havefork.c:83,93 - havefork.c:83,92
  	int pfd[2];
  	char *s, *wd, *ewd, *stop;
  	struct io *f;
- 	var *ifs = vlook("ifs");
  	word *v, *nextv;
  	Rune r;

- 	stop = ifs->val? ifs->val->word: "";
+ 	stop = runq->argv->words->word;
  	if(pipe(pfd)<0){
  		Xerror("can't make pipe");
  		return;
/n/dump/2011/0429/usr/quanstro/src/rc/havefork.c:140,145 - havefork.c:139,145
  			efree(wd);
  		closeio(f);
  		Waitfor(pid, 0);
+ 		popword();	/* ditch split in "stop" */
  		/* v points to reversed arglist -- reverse it onto argv */
  		while(v){
  			nextv = v->next;
/n/dump/2011/0429/usr/quanstro/src/rc/pcmd.c:32,38 - pcmd.c:32,38
  	break;
  	case '^':	pfmt(f, "%t^%t", c0, c1);
  	break;
- 	case '`':	pfmt(f, "`%t", c0);
+ 	case '`':	pfmt(f, "`%t%t", c0, c1);
  	break;
  	case ANDAND:	pfmt(f, "%t && %t", c0, c1);
  	break;
diff -c /n/dump/2011/0429/usr/quanstro/src/rc/syn.y syn.y
/n/dump/2011/0429/usr/quanstro/src/rc/syn.y:96,102 - syn.y:96,103
  |	'"' word		{$$=tree1('"', $2);}
  |	COUNT word		{$$=tree1(COUNT, $2);}
  |	WORD
- |	'`' brace		{$$=tree1('`', $2);}
+ |	'`' brace		{$$=tree2('`', nil, $2);}
+ |	'`' word brace		{$$=tree2('`', $2, $3);}
  |	'(' wordsnl nl ')'		{$$=tree1(PAREN, $2);}
  |	REDIR brace		{$$=mung1($1, $2); $$->type=PIPEFD;}
  keyword: FOR|IN|WHILE|IF|NOT|TWIDDLE|BANG|SUBSHELL|SWITCH|FN|BREAK

Re: [9fans] spaces in filenames (and filesystems...)

[smiley]

erik quanstrom <quanstro@quanstro.net> writes:

>> within the {} ? I guess that risks breaking any scripts you might want
>> to run as cmd, so yeah, the 3rd looks good.
>
> i implemented the 3d this evening in a compatable way with
> Traditional Rc.  there's an argument that it's not completely

Did you include an ability to split on the null string, to divide the
data into individual characters/runes?

/me crosses his fingers...

--
+---------------------------------------------------------------+
|E-Mail: smiley@zenzebra.mv.com             PGP key ID: BC549F8B|
|Fingerprint: 9329 DB4A 30F5 6EDA D2BA  3489 DAB7 555A BC54 9F8B|
+---------------------------------------------------------------+

Re: [9fans] spaces in filenames (and filesystems...)

[andrey mirtchovski]

> Did you include an ability to split on the null string, to divide the
> data into individual characters/runes?
>
> /me crosses his fingers...

| sed 's/(.)/\1 /g'

Re: [9fans] spaces in filenames

[erik quanstrom]

>  From time to time, the issue of having spaces in file names seems to
> come up on this list, mostly in the context of discussions on find,
> du, Acme, and trfs(4).  All the discussions I've found suggest that
> file names with whitespace in them are *legal* on fossil.  I'm running
> a 9atom 9pcf kernel copied verbatim from the 9atom .iso, on an
> otherwise stock Plan 9 4e fossil+venti install.  However, I can't seem
> to create files with with spaces in their names.  The resulting error
> string reports invalid characters in the file name.  Why doesn't this
> work?  Has the ability to have spaces in file names been removed from
> fossil?  If so, then how is it possible that there are files such as
> '/n/sources/contrib/steve/file with spaces' hanging around?

this is all my fault.

ken fs doesn't allow spaces in file names, and neither does kfs.
since many scripts tend to do the wrong thing with such file names,
i thought it would be a lot easier to just disallow them, and deal
with any problems that come up at file creation time, instead of
when you're running a script that's mysteriously failing.

the sources version of fossil does allow spaces in filenames.

> While I'm perfectly happy using underscores in lieu of spaces in *my*
> file names, there are a number of APE packages (i.e., fgb/lcms)
> containing files with spaces in their names.  Since those are the
> names used in replica(1), I'm unable to contrib/install(1) any of
> these packages.  Are there any known fixes or workarounds for this
> problem?  (I doubt trfs(4) would help, because the ape would still be
> naming the file with spaces, unless specifically modified to match the
> trfs(4) translation.)

i have never run into this.  my preferred solution would be to fix
the contrib packages, but that's not my call.

sorry for the inconvienece.

> Also, if anyone knows where I can find 9fans archives prior to March
> 2008, please let me know.  The archives I was able to find only go
> back that far.

http://9fans.net/archive

> Also, quanstro, would you whitelist me?  I can't seem to get mail to
> you off-list.  Thanks!

done.

- erik

Re: [9fans] spaces in filenames

[smiley]

erik quanstrom <quanstro@quanstro.net> writes:

> the sources version of fossil does allow spaces in filenames.

I'm hypothesizing that my version of fossil isn't allowing spaces in
file names because the version compiled into the '#//boot/boot/fossil'
in the 9atom 9pcf kernel from the 9atom .iso doesn't allow spaces.
Would that hypothesis be correct?  (Which would bring me to my next
question: how to recompile the 9atom kernel, with _tracein and _traceout
undefined in the final link and all, but that's a topic for a different
thread.)

> i have never run into this.  my preferred solution would be to fix
> the contrib packages, but that's not my call.

:( It's not mine, either.

> http://9fans.net/archive

Yes, I found that.  However, if there's an API for downloading them,
it's not obvious.  Short of spidering 9fans.net, is there a place to get
them?

--
+---------------------------------------------------------------+
|E-Mail: smiley@zenzebra.mv.com             PGP key ID: BC549F8B|
|Fingerprint: 9329 DB4A 30F5 6EDA D2BA  3489 DAB7 555A BC54 9F8B|
+---------------------------------------------------------------+

Re: [9fans] spaces in filenames

[erik quanstrom]

On Tue Apr 26 22:34:26 EDT 2011, smiley@zenzebra.mv.com wrote:
> erik quanstrom <quanstro@quanstro.net> writes:
>
> > the sources version of fossil does allow spaces in filenames.
>
> I'm hypothesizing that my version of fossil isn't allowing spaces in
> file names because the version compiled into the '#//boot/boot/fossil'
> in the 9atom 9pcf kernel from the 9atom .iso doesn't allow spaces.
> Would that hypothesis be correct?  (Which would bring me to my next
> question: how to recompile the 9atom kernel, with _tracein and _traceout
> undefined in the final link and all, but that's a topic for a different
> thread.)

i hope to clean all this junk up in my infinite spare time.  sorry.

rebuild libc after adding this, or remove the flags section from your
/sys/src/9/pc/9pcf*.

; cat /sys/src/libc//386/trace.s
TEXT _tracein(SB), 1, $0
	CMPL	traceactive(SB), $0
	JEQ	inotready
	MOVL	16(SP),AX
	PUSHL	AX
	MOVL	16(SP),AX
	PUSHL	AX
	MOVL	16(SP),AX
	PUSHL	AX
	MOVL	16(SP),AX
	PUSHL	AX
	MOVL	16(SP),AX
	PUSHL	AX
	CALL	tracein(SB)
	POPL	AX
	POPL	AX
	POPL	AX
	POPL	AX
	POPL	AX
inotready:
	RET

TEXT _traceout(SB), 1, $0
	CMPL	traceactive(SB), $0
	JEQ	notready
	PUSHL	AX
	MOVL	4(SP),AX
	PUSHL	AX
	CALL	traceout(SB)
	POPL	AX
	POPL	AX
notready:
	RET

- erik

[9fans] Compiling 9atom kernel WAS: Re: spaces in filenames

[smiley]

OK,

So I'm trying to compile the pcf kernel from quanstro's 9atom.iso.bz2.
There seems to be an undocumented dependency on the quanstro/fis
contrib(1).  (Without it, 8c complains that it can't find an include
file named fis.h or some such.)  I now have that.

I've also added the two assembly routines (_tracein and _traceout) to
/sys/src/libc/386/trace.s, as specified, and rebuilt and reinstalled
libc.

Nevertheless, when running mk 'CONF=pcf', the build fails with the
following error:

    8l -p -e -o 9pcf -T0xF0100020 -l l.8 plan9l.8 [...]
    size 9pcf
    _strayintrx: _tracein/_traceout not defined 5 5
    _strayintrx: _tracein: not defined
    _strayintrx: _traceout: not defined
    mk: 8c -FTVw '-DKERNDATE='`{date ...  : exit status=rc 5800: 8l 5804: error

The only source file which seems to reference '_strayintrx' is l.s.

--
+---------------------------------------------------------------+
|E-Mail: smiley@zenzebra.mv.com             PGP key ID: BC549F8B|
|Fingerprint: 9329 DB4A 30F5 6EDA D2BA  3489 DAB7 555A BC54 9F8B|
+---------------------------------------------------------------+

Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames

[erik quanstrom]

> So I'm trying to compile the pcf kernel from quanstro's 9atom.iso.bz2.
> There seems to be an undocumented dependency on the quanstro/fis
> contrib(1).  (Without it, 8c complains that it can't find an include
> file named fis.h or some such.)  I now have that.
>
> I've also added the two assembly routines (_tracein and _traceout) to
> /sys/src/libc/386/trace.s, as specified, and rebuilt and reinstalled
> libc.
>
> Nevertheless, when running mk 'CONF=pcf', the build fails with the
> following error:
>
>     8l -p -e -o 9pcf -T0xF0100020 -l l.8 plan9l.8 [...]
>     size 9pcf
>     _strayintrx: _tracein/_traceout not defined 5 5
>     _strayintrx: _tracein: not defined
>     _strayintrx: _traceout: not defined
>     mk: 8c -FTVw '-DKERNDATE='`{date ...  : exit status=rc 5800: 8l 5804: error

_straintrx is a red herring.  have you recompiled libc?

- erik

Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames

[smiley]

erik quanstrom <quanstro@labs.coraid.com> writes:


>>     size 9pcf
>>     _strayintrx: _tracein/_traceout not defined 5 5
>>     _strayintrx: _tracein: not defined
>>     _strayintrx: _traceout: not defined
>>     mk: 8c -FTVw '-DKERNDATE='`{date ...  : exit status=rc 5800: 8l 5804: error
>
> _straintrx is a red herring.  have you recompiled libc?

Yes, I'm sure.  :) In typical paranoid newbie fashion, I made sure to do
an 'ls -l /386/lib' before trying to build the kernel... oh, wait.  Let
me try a 'mk clean' first... nope.  Same error.

Remember, I'm running your 9atom 9pcf.gz, with quanstro/fis, on an
otherwise stock P9 4e fossil+venti system.

Hm.  The /386/lib/libc.a and the one on /n/dump have the same exact
size.  But they have different contents (cmp differ @ char 26).  It sure
looks like I recompiled and installed libc.

--
+---------------------------------------------------------------+
|E-Mail: smiley@zenzebra.mv.com             PGP key ID: BC549F8B|
|Fingerprint: 9329 DB4A 30F5 6EDA D2BA  3489 DAB7 555A BC54 9F8B|
+---------------------------------------------------------------+

Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames

[erik quanstrom]

> Yes, I'm sure.  :) In typical paranoid newbie fashion, I made sure to do
> an 'ls -l /386/lib' before trying to build the kernel... oh, wait.  Let
> me try a 'mk clean' first... nope.  Same error.

how about

	cd /sys/src/libc; mk && mk clean

- erik

Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames

[smiley]

erik quanstrom <quanstro@labs.coraid.com> writes:

Wow, you know, as a Gentoo user, I'm amazed AMAZED amazed amazed AMAZED
amazed how fast Plan 9 can compile a kernel or libc.  Compiling glibc
(on Linux) usually takes over half a day.  Compiling a kernel generally
takes a couple of hours.  This is great!

> how about
>
> 	cd /sys/src/libc; mk && mk clean

Just tried it.  Same error.

Is there perhaps some other source dependency we're not thinking of?  In
case it's relevant, I have the source in /sys/src/9atom instead of
/sys/src/9, but I doubt that would break anything.

--
+---------------------------------------------------------------+
|E-Mail: smiley@zenzebra.mv.com             PGP key ID: BC549F8B|
|Fingerprint: 9329 DB4A 30F5 6EDA D2BA  3489 DAB7 555A BC54 9F8B|
+---------------------------------------------------------------+

Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames

[andrey mirtchovski]

> This is great!

it is, isn't it? 6 seconds kernel compile, 15 seconds turnaround time
when developing anything in the kernel (with PXE boot). beat that,
modern operating systems :)

Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames

[ron minnich]

On Thu, Apr 28, 2011 at 10:35 AM, andrey mirtchovski
<mirtchovski@gmail.com> wrote:
>> This is great!
>
> it is, isn't it? 6 seconds kernel compile, 15 seconds turnaround time
> when developing anything in the kernel (with PXE boot). beat that,
> modern operating systems :)

yes, I had to help config and build a linux kernel yesterday; every
time I see it I just want to claw my eyes out. And it gets worse every
month ...

ron

Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames

[Brian L. Stuart]

Ron wrote:
> andrey mirtchovski
> <mirtchovski@gmail.com>
> wrote:
> >> This is great!
> >
> > it is, isn't it? 6 seconds kernel compile, 15 seconds
> turnaround time
> > when developing anything in the kernel (with PXE
> boot). beat that,
> > modern operating systems :)
>
> yes, I had to help config and build a linux kernel
> yesterday; every
> time I see it I just want to claw my eyes out. And it gets
> worse every
> month ...

Life is too short to configure and compile Linux and
GNU software.

BLS

Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames

[Jeff Sickel]

On Apr 28, 2011, at 1:50 PM, Brian L. Stuart wrote:

> Life is too short to configure and compile Linux and
> GNU software.
>
> BLS

another nomination for the fortunes file

Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames

[dexen deVries]

On Thursday 28 of April 2011 20:50:14 Brian L. Stuart wrote:
> Life is too short to configure and compile Linux and
> GNU software.

or spending days on choosing a computer with all the hardware supported. oh
wait.


to the wit: the current hacker-unfriendlines of linux (a.k.a. `user
friendlines') is the price paid for vide driver support.

--
dexen deVries

``One can't proceed from the informal to the formal by formal means.''

Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames

[erik quanstrom]

On Thu Apr 28 15:30:38 EDT 2011, dexen.devries@gmail.com wrote:
> On Thursday 28 of April 2011 20:50:14 Brian L. Stuart wrote: > Life is
> too short to configure and compile Linux and > GNU software.
>
> or spending days on choosing a computer with all the hardware
> supported.  oh wait.

that's not how you do it.  you spend about the normal amount
of time checking, and then when you get the machine you fix
what's left.  :-)

i've just configured an new xeon 1155, which has had a nic
that wasn't quite supported (pch2 lan + 82579 phy), and a
wierd lapic/ioapic configuration.

all told, it was only about a day to get it working.

now i could have spend that amount of time with an os that might
have supported everything out-of-the-box, but it's doubtful that i'd
have it even configured yet.

- erik

Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames

[errno]

On Thursday, April 28, 2011 12:39:07 PM erik quanstrom wrote:
> On Thu Apr 28 15:30:38 EDT 2011, dexen.devries@gmail.com wrote:
> > On Thursday 28 of April 2011 20:50:14 Brian L. Stuart wrote: > Life is
> > too short to configure and compile Linux and > GNU software.
> >
> > or spending days on choosing a computer with all the hardware
> > supported.  oh wait.
>
> that's not how you do it.  you spend about the normal amount
> of time checking, and then when you get the machine you fix
> what's left.  :-)
>
> i've just configured an new xeon 1155, which has had a nic
> that wasn't quite supported (pch2 lan + 82579 phy), and a
> wierd lapic/ioapic configuration.
>
> all told, it was only about a day to get it working.
>
> now i could have spend that amount of time with an os that might
> have supported everything out-of-the-box, but it's doubtful that i'd
> have it even configured yet.
>

I'd be more excited about quick compile times on plan 9 when
I can use plan 9 to check my bank account, watch youtube
videos, and order movie tickets or pizza over the web.  But I
still need a loonix box to do those things, so I still need to
suffer the horrors of glibc[1] and ~760M kernel sources - which
is unfortunate.

I understand why plan 9 avoids posix and unix and gtk+ and
the gnu toolchain - or flash, or firefox, etc., etc. - but it would
be nice if it had fuller, more complete support for "the web".

I wish AWE would manifest.  APE - "a posix environment" vs.
AWE - "a web(kit) environment".  Alas, if wishes were fishes...
(we'd all be rich fishermen).

Though I don't understand why folks around here complain about
"linux" so often and so vehemently, when the only reason why you're
complaining is because you _need_ linux... to furnish all the things
you can't do with plan 9 - either personally, or within your organization.


[1] For those gnashing teeth over glibc - might want to check out
musl libc.  It's no plan 9 libc, but it's definitely "less worse" than glibc.

Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames

[erik quanstrom]

> Though I don't understand why folks around here complain about
> "linux" so often and so vehemently, when the only reason why you're
> complaining is because you _need_ linux... to furnish all the things
> you can't do with plan 9 - either personally, or within your organization.

people who care about Doing Things Right are easy to upset.

- erik

Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames

[errno]

On Thursday, April 28, 2011 08:03:23 PM erik quanstrom wrote:
> > Though I don't understand why folks around here complain about
> > "linux" so often and so vehemently, when the only reason why you're
> > complaining is because you _need_ linux... to furnish all the things
> > you can't do with plan 9 - either personally, or within your
> > organization.
>
> people who care about Doing Things Right are easy to upset.
>

Bloat... can't live with it, can't live without it.

... I hope that something better comes along.

http://www.youtube.com/watch?v=_yaP_kc3y9w


On Thursday, April 28, 2011 08:11:49 PM andrey mirtchovski wrote:
> errno, you sound like you may be trespassing on our collective 9fans
> lawn. i wave a cane in your general direction.
>

Plan 9 rules and linux drools - I get it - but, wake me up when there's a
Grand Unified Solution for implementing a perfectly clean, multi-purpose,
general-use operating platform for an ad-hoc, rapidly (d)evolving, messy
industry/market/society - that isn't itself intrinsically, hopelessly bloated
in order to fulfill said purpose.

Until then, complaining about de-facto linux bloat is a lot like complaining
about death and taxes. Boring and disingenuous.

IMHO, at least.

(I'm just glad the collective plan 9 lawn expands far beyond the pointless
linux-hate gazebo.)

Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames

[andrey mirtchovski]

> clean, multi-purpose, general-use operating platform for an ad-hoc, rapidly
> (d)evolving, messy industry/market/society

here: http://mirtchovski.com/p9/canthave.png

Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames

[Charles Forsyth]

> complaining is because you _need_ linux... to furnish all the things
> you can't do with plan 9 - either personally, or within your organization.

it's true, but at least i haven't got to run either Windows or MacOS.
the underlying problem is that the things we might simply import (mainly browser)
can't simply be imported. it's not just us: you might have noticed that Google's Picasaweb
runs under Linux by including a copy of Wine as part of its iceberg.
also google in any alternative-os list you like for a discussion of the
hopelessness of ./configure

Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames

[dexen deVries]

On Friday 29 of April 2011 11:18:26 Charles Forsyth wrote:
> > complaining is because you _need_ linux... to furnish all the things
> > you can't do with plan 9 - either personally, or within your
> > organization.
> 
> it's true, but at least i haven't got to run either Windows or MacOS.
> the underlying problem is that the things we might simply import (mainly
> browser) can't simply be imported. it's not just us: you might have
> noticed that Google's Picasaweb runs under Linux by including a copy of
> Wine as part of its iceberg. also google in any alternative-os list you
> like for a discussion of the hopelessness of ./configure

qmake (Qt's makefile generator) is mostly reasonable IMHO. consists of one 
program (the qmake) which reads a rather simple project description 
(<<myapp>>.pro) plus a bunch of platform description files 
(/usr/lib{,64}/qt/mkspec/<<platform>>/qmake.conf + whatever it includes) and 
outputs reasonable makefiles.

at any rate, the supposed replacements for autoconf/automake aren't shining 
examples of engineering either -- usually big & complex. i guess it's more 
about mindset (``let's check every itty-gritty detail and let's abstract away 
differences between platforms'') than the problem space, thou.

-- 
dexen deVries

[[[↓][→]]]

``In other news, STFU and hack.''
mahmud, in response to Erann Gat's ``How I lost my faith in Lisp''
http://news.ycombinator.com/item?id=2308816

Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames

[Charles Forsyth]

>let's abstract away differences between platforms

but they don't `abstract away': they enumerate them.

Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames

[tlaronde]

On Fri, Apr 29, 2011 at 11:12:55AM +0200, dexen deVries wrote:
>
> qmake (Qt's makefile generator) is mostly reasonable IMHO. consists of one
> program (the qmake) which reads a rather simple project description
> (<<myapp>>.pro) plus a bunch of platform description files
> (/usr/lib{,64}/qt/mkspec/<<platform>>/qmake.conf + whatever it includes) and
> outputs reasonable makefiles.
>
> at any rate, the supposed replacements for autoconf/automake aren't shining
> examples of engineering either -- usually big & complex. i guess it's more
> about mindset (``let's check every itty-gritty detail and let's abstract away
> differences between platforms'') than the problem space, thou.

The problem is not in the tool per se---R.I.S.K., used for KerGIS and
kerTeX (and others with no public version), is an example---but with the
programmers.

If programmers knew what they are using (C89 or C99 and that's all; or
POSIX etc.), the problem would be easily solved---these are the
cases "solved" by R.I.S.K.: programmer must know.

If the tool must "guess" what the program is using; furthermore if
for viral purpose and by "educational" repeating the wannabee
programmers are told to not care about standards, because GNU's
Not Unix and POSIX is bad, but use every chunk blessed by the GPL...

I don't know if there are black holes in the nature. But for sure mob
programming has managed to create computer ones; projects so bloated
that they are absorbing all the resources around with an emitted service
dimming more and more.

I'm finishing the integration of MetaPost in kerTeX (one auxiliary
program to fix and I can start testing), and I will have spent less time
from a very scarce free time redoing everything (distribution side) than
people trying to make TeX Live compiling for their plateform. (The
source code is the Medusa: you look at it and you are awed. That was
the aim.)

I claim this is a kind of lesson. (Same goes for GRASS -> KerGIS even if
nobody cared when I did it.)
--
        Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
                      http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames

[dexen deVries]

On Friday 29 of April 2011 11:44:31 tlaronde@polynum.com wrote:
> I don't know if there are black holes in the nature. But for sure mob
> programming has managed to create computer ones; projects so bloated
> that they are absorbing all the resources around with an emitted service
> dimming more and more.

curiously enough, both black holes are understood to undergo evaporation (due 
to quantum tunneling) and communities undergo the so-called `evaporative 
cooling' -- where influx of `cold' (barely talented) members causes evaporation 
of the the `hot' (most talented) members.

at any rate, `code removed is code debugged' is very true, but that's not 
something easily put on CV or boasted to friends.


> (...) mob programming (...)

there's a lot of substarnce to offend certain projects with, no need to merely 
use style.

-- 
dexen deVries

[[[↓][→]]]

``In other news, STFU and hack.''
mahmud, in response to Erann Gat's ``How I lost my faith in Lisp''
http://news.ycombinator.com/item?id=2308816

Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames

[Jeff Sickel]

On Apr 29, 2011, at 4:54 AM, dexen deVries <dexen.devries@gmail.com> wrote:

> at any rate, `code removed is code debugged' is very true, but that's not 
> something easily put on CV or boasted to friends.

An alternative version, `deleted code is debugged code', has been used very successfully by myself and other colleagues. I first heard the term on a very large VAX/VMS project in 1992 where it succeed in making its way into frequent use.

Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames

[Greg Comeau]

In article <129E2E01-3583-4E27-B520-252A956F59FC@corpus-callosum.com>,
Jeff Sickel <jas@corpus-callosum.com> wrote:
>On Apr 29, 2011, at 4:54 AM, dexen deVries <dexen.devries@gmail.com> wrote:
>> at any rate, `code removed is code debugged' is very true, but that's not
>> something easily put on CV or boasted to friends.
>
>An alternative version, `deleted code is debugged code', has been used very s=
>uccessfully by myself and other colleagues. I first heard the term on a very=
> large VAX/VMS project in 1992 where it succeed in making its way into frequ=
>ent use.

Some more food for thought:

"Debugging is twice as hard as writing the code in the first place.
 Therefore, if you write the code as cleverly as possible, you are,
  definition, not smart enough to debug it." --Brian Kernighan

"We observe simply that a program usually has to be read several times
 in the process of getting it debugged. The harder it is for people to
 grasp the intent of any given section, the longer it will be before
 the program becomes operational." --  Kernighan and Plauger
--
Greg Comeau / 4.3.10.1 with C++0xisms now in beta!
Comeau C/C++ ONLINE ==>     http://www.comeaucomputing.com/tryitout
World Class Compilers:  Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames

[tlaronde]

On Thu, May 05, 2011 at 09:54:28AM +0000, Greg Comeau wrote:
> 
> Some more food for thought:
> 
> "Debugging is twice as hard as writing the code in the first place.
>  Therefore, if you write the code as cleverly as possible, you are,
>   definition, not smart enough to debug it." --Brian Kernighan
> 

With a caveat: when one is really clever, one finds "the shortest path
to the truth" i.e. the simplicity; this means that really clever guys
make programs easy to debug because these are the simplest ones doing
the job.

In Brian Kernighan's sentence, s/cleverly/sophisticatedly/ (this is
probably a barbarism, but in french "sophistiqué" is pejorative:
obfuscation, convoluted etc.).
-- 
        Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
                      http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames

[Mathieu Lonjaret]

> In Brian Kernighan's sentence, s/cleverly/sophisticatedly/ (this is
> probably a barbarism, but in french "sophistiqué" is pejorative:
> obfuscation, convoluted etc.).

Sorry, but it's not. it just means complex, and is not usually
employed to make any value judgment.
Just look it up in any dictionary.

Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames

[tlaronde]

On Sun, May 08, 2011 at 10:51:07PM +0200, Mathieu Lonjaret wrote:
> > In Brian Kernighan's sentence, s/cleverly/sophisticatedly/ (this is
> > probably a barbarism, but in french "sophistiqué" is pejorative:
> > obfuscation, convoluted etc.).
> 
> Sorry, but it's not. it just means complex, and is not usually
> employed to make any value judgment.
> Just look it up in any dictionary.

Just look for the origin: the verb is "sophistiquer"... The usage and
the dictionnaries are inconsistant, since "sophistiqué" (now used non
pejoratively) is the past participle of "sophistiquer" that is
definitively pejorative. (Look for "sophistiquement" too; all this comes
from philosophy where sophiste is not to be taken in good part)...
-- 
        Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
                      http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames

[Wes Kussmaul]

[-- Attachment #1: Type: text/plain, Size: 814 bytes --]

On Mon, 2011-05-09 at 18:54 +0200, tlaronde@polynum.com wrote:


> Just look for the origin: the verb is "sophistiquer"... The usage and
> the dictionnaries are inconsistant, since "sophistiqué" (now used non
> pejoratively) is the past participle of "sophistiquer" that is
> definitively pejorative. (Look for "sophistiquement" too; all this comes
> from philosophy where sophiste is not to be taken in good part)...


This is where semantics encounters the "everybody's somebody's fool"
principle. I hang out with people who pay $20+++ for a liter of spoiled
grape juice. The more they pay the more their peers regard them as being
sophisticated. People outside that culture would see that very same use
of the term "sophisticated" as a pejorative. Sophistication is in the
eye of the beholder.

[-- Attachment #2: Type: text/html, Size: 1163 bytes --]

Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames

[hiro]

20$ for a juice? I thought the dollar was already pretty high these
days? Seldom do I say this phrase but what the fuck!

On 5/9/11, Wes Kussmaul <wes@authentrus.com> wrote:
> On Mon, 2011-05-09 at 18:54 +0200, tlaronde@polynum.com wrote:
>
>
>> Just look for the origin: the verb is "sophistiquer"... The usage and
>> the dictionnaries are inconsistant, since "sophistiqué" (now used non
>> pejoratively) is the past participle of "sophistiquer" that is
>> definitively pejorative. (Look for "sophistiquement" too; all this comes
>> from philosophy where sophiste is not to be taken in good part)...
>
>
> This is where semantics encounters the "everybody's somebody's fool"
> principle. I hang out with people who pay $20+++ for a liter of spoiled
> grape juice. The more they pay the more their peers regard them as being
> sophisticated. People outside that culture would see that very same use
> of the term "sophisticated" as a pejorative. Sophistication is in the
> eye of the beholder.
>

Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames

[andrey mirtchovski]

> 20$ for a juice?

most likely fermented.

Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames

[Akshat Kumar]

http://www.schubart.net/archives/2004/01/31/worlds-most-expensive-apple-juice

Go a tad less and you can get
the unfermented kind - though
not grape.

On Tue, May 10, 2011 at 5:27 AM, andrey mirtchovski
<mirtchovski@gmail.com> wrote:
>> 20$ for a juice?
>
> most likely fermented.
>
>

Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames

[hiro]

Yeah, that's what I was thinking about :D

Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames

[Wes Kussmaul]

[-- Attachment #1: Type: text/plain, Size: 425 bytes --]

I'm really sorry I started this.


On Fri, 2011-05-13 at 01:40 -0700, Akshat Kumar wrote:

> http://www.schubart.net/archives/2004/01/31/worlds-most-expensive-apple-juice
>
> Go a tad less and you can get
> the unfermented kind - though
> not grape.
>
> On Tue, May 10, 2011 at 5:27 AM, andrey mirtchovski
> <mirtchovski@gmail.com> wrote:
> >> 20$ for a juice?
> >
> > most likely fermented.
> >
> >
>



[-- Attachment #2: Type: text/html, Size: 863 bytes --]

Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames

[Daniel Lyons]

On May 10, 2011, at 2:34 AM, hiro wrote:

> 20$ for a juice? I thought the dollar was already pretty high these
> days? Seldom do I say this phrase but what the fuck!

He's talking about wine.

— 
Daniel Lyons

Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames

[Wes Kussmaul]

[-- Attachment #1: Type: text/plain, Size: 366 bytes --]

I tried to clarify that but my reply never appeared. 

On Tue, 2011-05-10 at 07:47 -0600, Daniel Lyons wrote:

> On May 10, 2011, at 2:34 AM, hiro wrote:
> 
> > 20$ for a juice? I thought the dollar was already pretty high these
> > days? Seldom do I say this phrase but what the fuck!
> 
> He's talking about wine.
> 
> — 
> Daniel Lyons
> 
> 



[-- Attachment #2: Type: text/html, Size: 653 bytes --]

Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames

[Wes Kussmaul]

[-- Attachment #1: Type: text/plain, Size: 1473 bytes --]

On Tue, 2011-05-10 at 10:34 +0200, hiro wrote:

> 20$ for a juice? I thought the dollar was already pretty high these
> days? Seldom do I say this phrase but what the fuck!


It's very special juice - made special by the way it's allowed to
spoil. 

You know, fine old oak barrels watched over by a dude who knows how to
utter the word "tannins" with just the right nasality and who knows how
to deflect questions about blind tasting without seeming evasive. There
is much skill in that; such skill is not cheap.



> 
> On 5/9/11, Wes Kussmaul <wes@authentrus.com> wrote:
> > On Mon, 2011-05-09 at 18:54 +0200, tlaronde@polynum.com wrote:
> >
> >
> >> Just look for the origin: the verb is "sophistiquer"... The usage and
> >> the dictionnaries are inconsistant, since "sophistiqué" (now used non
> >> pejoratively) is the past participle of "sophistiquer" that is
> >> definitively pejorative. (Look for "sophistiquement" too; all this comes
> >> from philosophy where sophiste is not to be taken in good part)...
> >
> >
> > This is where semantics encounters the "everybody's somebody's fool"
> > principle. I hang out with people who pay $20+++ for a liter of spoiled
> > grape juice. The more they pay the more their peers regard them as being
> > sophisticated. People outside that culture would see that very same use
> > of the term "sophisticated" as a pejorative. Sophistication is in the
> > eye of the beholder.
> >
> 



[-- Attachment #2: Type: text/html, Size: 2019 bytes --]

Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames

[hiro]

Heh, I should have noticed. My thoughts were a lot more scary:)

Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames

[John Floren]

He's talking about wine (spoiled grape juice), in a discussion which
continues to go further afield with each passing message :)

John

On Tue, May 10, 2011 at 1:34 AM, hiro <23hiro@googlemail.com> wrote:
> 20$ for a juice? I thought the dollar was already pretty high these
> days? Seldom do I say this phrase but what the fuck!
>
> On 5/9/11, Wes Kussmaul <wes@authentrus.com> wrote:
>> On Mon, 2011-05-09 at 18:54 +0200, tlaronde@polynum.com wrote:
>>
>>
>>> Just look for the origin: the verb is "sophistiquer"... The usage and
>>> the dictionnaries are inconsistant, since "sophistiqué" (now used non
>>> pejoratively) is the past participle of "sophistiquer" that is
>>> definitively pejorative. (Look for "sophistiquement" too; all this comes
>>> from philosophy where sophiste is not to be taken in good part)...
>>
>>
>> This is where semantics encounters the "everybody's somebody's fool"
>> principle. I hang out with people who pay $20+++ for a liter of spoiled
>> grape juice. The more they pay the more their peers regard them as being
>> sophisticated. People outside that culture would see that very same use
>> of the term "sophisticated" as a pejorative. Sophistication is in the
>> eye of the beholder.
>>
>
>

Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames

[Comeau At9Fans]

[-- Attachment #1: Type: text/plain, Size: 2024 bytes --]

On Sun, May 8, 2011 at 2:27 PM, <tlaronde@polynum.com> wrote:

> On Thu, May 05, 2011 at 09:54:28AM +0000, Greg Comeau wrote:
> >
> > Some more food for thought:
> >
> > "Debugging is twice as hard as writing the code in the first place.
> >  Therefore, if you write the code as cleverly as possible, you are,
> >   definition, not smart enough to debug it." --Brian Kernighan
> >
>
> With a caveat: when one is really clever, one finds "the shortest path
> to the truth" i.e. the simplicity; this means that really clever guys
> make programs easy to debug because these are the simplest ones doing
> the job.
>
> In Brian Kernighan's sentence, s/cleverly/sophisticatedly/ (this is
> probably a barbarism, but in french "sophistiqué" is pejorative:
> obfuscation, convoluted etc.).


I think one can usually read things into such phrases, sometimes validly
sometime invalidly.  I also think it is often easy to disprove such phrases,
and so to instead to often just try to find the spirit of the phrase even if
it is found to be problematic.  For instance, easy to debug could mean the
program is so riddled with problems just opening to a random part of it will
yield a problem with little effort it could also mean to the contrary that
it was written so well that any bugs could be easy to find, but equally on
the contrary the program could be such a bleeping mess that even though bug
riddled getting through the logic etc could be tormenting at best while at
the same time a clean program with few bugs can sometimes make finding "the
long bug" harder because it is the lone last one.   In the end there is
often no pure bug cause or pure bug resolution mechanism but something in
the middle that is contextual.  All IMO.

-- 
Greg Comeau / 4.3.10.1 with C++0xisms now in beta!
Comeau C/C++ ONLINE ==>     http://www.comeaucomputing.com/tryitout
World Class Compilers:  Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

[-- Attachment #2: Type: text/html, Size: 2493 bytes --]

Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames

[Lucio De Re]

On Sun, May 08, 2011 at 08:27:53PM +0200, tlaronde@polynum.com wrote:
> 
> (this is
> probably a barbarism, but in french "sophistiqué" is pejorative:
> obfuscation, convoluted etc.).

In Italian in 1969, "sofisticato" meant "adulterated".  I'm not sure if
that is still the case.  I think I see what you mean.

But as for "clever", there are shades of meaning there, there's a
clever beyond clever that is what you suggest would discover simplicity.
Arguing around subtleties in different languages is sophistic at best.

++L

Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames

[andrey mirtchovski]

errno, you sound like you may be trespassing on our collective 9fans
lawn. i wave a cane in your general direction.

Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames

[ron minnich]

On Thu, Apr 28, 2011 at 7:00 PM, errno <errno@cox.net> wrote:

> [1] For those gnashing teeth over glibc - might want to check out
> musl libc.  It's no plan 9 libc, but it's definitely "less worse" than glibc.

Once I get my teeth back in I will gnash them even more.

ron

Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames

[Charles Forsyth]

> [1] For those gnashing teeth over glibc - might want to check out
> musl libc.  It's no plan 9 libc, but it's definitely "less worse" than glibc.

``News: As of version 0.7.7, musl has been successfully bootstrapped by a third-party system integrator.''

hmm. they had to do more than just compile it?
a library has to be `bootstrapped'?
i blame the parents.

Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames

[errno]

On Friday, April 29, 2011 02:04:26 AM Charles Forsyth wrote:
> > [1] For those gnashing teeth over glibc - might want to check out
> > musl libc.  It's no plan 9 libc, but it's definitely "less worse" than
> > glibc.
>
> ``News: As of version 0.7.7, musl has been successfully bootstrapped by a
> third-party system integrator.''
>
> hmm. they had to do more than just compile it?
> a library has to be `bootstrapped'?
> i blame the parents.

Really?

I think it's fair enough to say that your standard library has been
"bootstrapped" upon the first instance of it being baked into a
new platform as the native libc.

https://github.com/chneukirchen/sabotage


On Friday, April 29, 2011 02:18:26 AM Charles Forsyth wrote:
> > complaining is because you _need_ linux... to furnish all the things
> > you can't do with plan 9 - either personally, or within your
> > organization.
>
> it's true, but at least i haven't got to run either Windows or MacOS.
> the underlying problem is that the things we might simply import (mainly
> browser) can't simply be imported. it's not just us: you might have
> noticed that Google's Picasaweb runs under Linux by including a copy of
> Wine as part of its iceberg. also google in any alternative-os list you
> like for a discussion of the hopelessness of ./configure
>

Icebergs are justified when used as a temporary stop-gap until a native
solution is devised and implemented.  Thus, a webkit environment ("AWE")
seems like a pretty decent compromise until Plan 9 is finally able to treat
the wild wild web like a first-class citizen.

I have no clue how difficult it would be to port webkit to Plan 9 though,
but I imagine it would be easier than writing a pure Plan 9 web browser
engine (html, css, dom & ecmascript) from scratch.

(I just do basic backend web programming and linux systems administration -
so I'm just speculating.)

But then again, why would anyone want a fully functional web experience
on Plan 9 - what would be the purpose?  Apparently nobody does, otherwise
it'd be implemented already.

Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames

[Jacob Todd]

[-- Attachment #1: Type: text/plain, Size: 2665 bytes --]

On Apr 29, 2011 6:21 AM, "errno" <errno@cox.net> wrote:
>
> On Friday, April 29, 2011 02:04:26 AM Charles Forsyth wrote:
> > > [1] For those gnashing teeth over glibc - might want to check out
> > > musl libc.  It's no plan 9 libc, but it's definitely "less worse" than
> > > glibc.
> >
> > ``News: As of version 0.7.7, musl has been successfully bootstrapped by
a
> > third-party system integrator.''
> >
> > hmm. they had to do more than just compile it?
> > a library has to be `bootstrapped'?
> > i blame the parents.
>
> Really?
>
> I think it's fair enough to say that your standard library has been
> "bootstrapped" upon the first instance of it being baked into a
> new platform as the native libc.
>
> https://github.com/chneukirchen/sabotage
>
>
> On Friday, April 29, 2011 02:18:26 AM Charles Forsyth wrote:
> > > complaining is because you _need_ linux... to furnish all the things
> > > you can't do with plan 9 - either personally, or within your
> > > organization.
> >
> > it's true, but at least i haven't got to run either Windows or MacOS.
> > the underlying problem is that the things we might simply import (mainly
> > browser) can't simply be imported. it's not just us: you might have
> > noticed that Google's Picasaweb runs under Linux by including a copy of
> > Wine as part of its iceberg. also google in any alternative-os list you
> > like for a discussion of the hopelessness of ./configure
> >
>
Afaik, google has been distributing picasa with wine for years, it doesn't
act like an intermediate solution, it seems told be their solution.

> Icebergs are justified when used as a temporary stop-gap until a native
> solution is devised and implemented.  Thus, a webkit environment ("AWE")
> seems like a pretty decent compromise until Plan 9 is finally able to
treat
> the wild wild web like a first-class citizen.
>
Seeing that plan 9 doesn't have a c++ compiler, i doubt it will ever be
ported. Cinap runs opera 9, flash 7, even blender under linuxemu, though.
You might want to take a look at it. 9hal.ath.cx. you can also use vnc on
plan 9 if you 'need' to use the web.

> I have no clue how difficult it would be to port webkit to Plan 9 though,
> but I imagine it would be easier than writing a pure Plan 9 web browser
> engine (html, css, dom & ecmascript) from scratch.
>
> (I just do basic backend web programming and linux systems administration
-
> so I'm just speculating.)
>
> But then again, why would anyone want a fully functional web experience
> on Plan 9 - what would be the purpose?  Apparently nobody does, otherwise
> it'd be implemented already.
>

[-- Attachment #2: Type: text/html, Size: 3375 bytes --]

Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames

[errno]

On Friday, April 29, 2011 05:21:12 AM Jacob Todd wrote:
> Seeing that plan 9 doesn't have a c++ compiler, i doubt it will ever be
> ported.
>

But APE has c++  (old version of gcc though).  I expect that a webkit
(or gecko) port would need to rely on APE, right?

I guess I'd have to start with the build dependencies first, some of
them might already be on contrib somewhere.


> Cinap runs opera 9, flash 7, even blender under linuxemu, though.
> You might want to take a look at it. 9hal.ath.cx.
>

Thanks for the heads-up, I'll check it out.


> you can also use vnc on
> plan 9 if you 'need' to use the web.
>

Yep, I'm aware of the vnc workaround... but, it's just the same as
a native, or near-native approach.

If the goal was to build a plan 9 network in my house for my friends
and family to use, for the purpose of easy administration, according
to plan 9 distributed practices - then needing to have linux/bsd boxen
completely defeats the purpose, and is counter-productive.


On Friday, April 29, 2011 05:32:09 AM erik quanstrom wrote:
> i don't mind a good lively discussion, but these comments seem
> a bit trollish to me.
>

I have/had no intent, no interest, and no benefit in trolling; please don't
accuse me of being antisocial. I apologize if "disingenuous" was the wrong
term.


>  why don't we get back on track?
>

Ok:

On Friday, April 29, 2011 05:32:09 AM erik quanstrom wrote:
> On Friday, April 29, 2011 03:19:23 AM errno wrote:
>> But then again, why would anyone want a fully functional web
>> experience on Plan 9 - what would be the purpose?  Apparently
>> nobody does, otherwise it'd be implemented already.
>
> that's not logical.
>

I operated on the understanding that Plan 9 gets developed according
to peoples' desire to scratch particular itches. I was also operating
under the impression that the clean and well-designed nature of plan 9's
abstractions and architecture would facilitate making hard problems easier.

Rather than offering speculation, from which to be knocked down and/or
insulted for, I figure maybe I should just ask:

If it is accepted that people do in fact want a fully functional native (or
"native-ish") web experience on Plan 9, what is the logical explanation for it
still not existing after so many years?

(by "web experience", I'm not talking about porting firefox and flash to Plan 9
- I'm talking about native or ported libraries for what wikipedia refers to as
a "web browser engine" or "layout engine"; and by "fully functional", I'm
talking about something that can score at least an 80% or so on the acid2
test.)

Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames

[errno]

On Friday, April 29, 2011 09:05:39 PM errno wrote:
> Yep, I'm aware of the vnc workaround... but, it's just the same as
> a native, or near-native approach.
>

I meant:  "[...] but, it's just _not_ the same as a native approach."

Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames

[Anthony Sorace]

[-- Attachment #1.1: Type: text/plain, Size: 1992 bytes --]

On Apr 30, 2011, at 12:05 AM, errno wrote:

> But APE has c++  (old version of gcc though).

APE has no c++. there is a very old version of gcc floating around on
sources that can, with some effort, sometimes be made to compile things.

> I expect that a webkit (or gecko) port would need to rely on APE, right?

it'd need to rely on whatever provided the c++ compiler and libraries. getting
some useful set of those is itself a sizable effort.

> I guess I'd have to start with the build dependencies first, some of
> them might already be on contrib somewhere.

if you really want to do it, start with the c++ compiler. then look at webkit's
own dependencies (about half of which we have APE versions for, although
i'm skeptical of mixing that and g++-compiled code).

> I operated on the understanding that Plan 9 gets developed according
> to peoples' desire to scratch particular itches. I was also operating 
> under the impression that the clean and well-designed nature of plan 9's
> abstractions and architecture would facilitate making hard problems easier.

i think those are valid assumptions. however:

> If it is accepted that people do in fact want a fully functional native (or
> "native-ish") web experience on Plan 9, what is the logical explanation for it
> still not existing after so many years?

because it's a huge amount of work. there's a whole pile of standards and
pseudo-standards to deal with, the set is ever-growing, the components are
ever-growing, and there isn't really a good definition of "correct". think about
the hours that've gone into making webkit (or worse, gecko) what it is. and
all that work is ongoing.

making an infinitely difficult problem significantly easier still yields an
infinitely difficult problem.

it's all just a hideous mess. it'd be nice to have a good, plan9-ish solution, but
it's awful tempting to just run opera under linuxemu or go buy a tablet to
treat as a web browser in hardware.

[-- Attachment #1.2: Type: text/html, Size: 2801 bytes --]

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 210 bytes --]

Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames

[errno]

On Friday, April 29, 2011 11:26:03 PM Anthony Sorace wrote:
> On Apr 30, 2011, at 12:05 AM, errno wrote:
> > But APE has c++  (old version of gcc though).
>
> APE has no c++. there is a very old version of gcc floating around on
> sources that can, with some effort, sometimes be made to compile things.
>

Ah, ok - thanks for the correction.

And thanks for the friendly response in general, appreciated.

So, shaking this out just a bit further:

(anyone reading, please just ignore this if you find it too long,
and/or too annoying, and/or too naive - or whatever - I'd rather
hear crickets chirping than hecklers carping - thanks)


Starting Goal:  a modern, standards compliant web engine library for Plan 9


Options:

* write from scratch

* port existing codebase


Option Considerations:

* writing from scratch is simply too momentous a task:

"because it's a huge amount of work. there's a whole pile of standards and
pseudo-standards to deal with, the set is ever-growing, the components are
ever-growing, and there isn't really a good definition of 'correct'.  it's all
just a hideous mess."

+ thus, porting from an existing codebase is likely the more realistic option


Porting Options:

* gecko

* webkit


Porting Option Considerations:

* of the port options, gecko and webkit are the most well-developed,
active, complete candidates.

+ the choice between gecko or webkit might be arguable, but webkit
may be a more desirable choice as it has a more modular design with
better separation of concerns and a cleaner api, thus webkit will be
targeted.


New Goal:  in accordance to the above enumerated considerations,
the goal is to port webkit to plan 9, for the purpose of facilitating a
modern, standards compliant web framework library for Plan 9


WebKit Considerations:

* webkit is built primarily with c++

* webkit has a moderate number of build dependencies and app
dependencies

* plan 9 currently lacks a reliably functional, modern, native c++
compiler, so the goal cannot be accomplished without some means
of c++ support in plan 9


C++ Compiler Options:

* gcc

* llvm/clang


C++ Compiler Considerations:

* somewhat similar to the gecko vs. webkit decision, the choice between
gcc or clang may also be arguable


New Prerequisite Goal:  port a c++ compiler and std libs to plan 9



Ok, so really - in order to have any real chance of seeing a satisfactory,
native/near-native web experience on plan 9, an existing codebase must
be ported - and that codebase is written in c++, so:

For the purpose of satisfying stated goal, a c++ compiler must first be
ported to plan 9.

Regardless, it is predicted that porting a c++ compiler to plan 9, _then_
porting webkit to plan 9, is _still_ less work than writing a brand new,
complete, standards-compliant web browser engine from scratch.

The question then becomes:  which c++ compiler should be targeted,
gcc or llvm/clang?

On an entirely subjective/relative scale of 1 to 5, how difficult is it to port
gcc or clang to plan 9?  Is this effectively impossible without a dedicated
and focused team of developers? Is anyone already doing this?


Due to the requirements, it appears that incorporating the web as a
1st-class-platform in plan 9 is effectively unapproachable:

Porting a c++ toolchain isn't likely going to happen, and the skillsets and
resources necessary to build a solution from scratch presents far too high
a bar too manage.


Anyhow, thanks for letting me walk myself through the scenario. It's hard
to spend any time working with and reading about plan 9 without thinking
in terms of how much better a great many things would be if said things
had a native plan 9 implementation.

The Web on Plan 9 seems like Web++ to me.

But, I'm also coming from the simple-minded perspective of a basic admin
and consumer-grade enduser - someone who likes the idea of setting up a
distributed plan 9 network in my house for guests, friends and family. A plan
9 terminal would be useless to such people at the current time though - which
kinda deflates my balloon a bit, ah well... so it goes.

Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames

[Steve Simon]

First I assume you have used abaco - it is incomplete but its the best plan9 has at
present - without using linuxemu.

There is cfront c++ but this is so old it would probably not be worth getting it to work - templates never worked in AT&T cfront. The exception to this the HP cfront implementation
which they might release if hassled.

If you are saying that you are willing to take this on (getting a modern native plan9
web browser running) I may be able to help in some areas (NDAs annotingly prevent me
discussing it here).

One idea I was considering for several years was trying to get Dillo running as a fairly
compliant browser, initially under an X11 server but later you might be able to merge the
framebuffer backend to dillo (via a library I cannot remember) and replace it with a
library which talks /dev/draw rather than linux framebuffer.

just some random thoughts.

-Steve

Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames

[errno]

On Saturday, April 30, 2011 01:25:53 AM Steve Simon wrote:
> First I assume you have used abaco - it is incomplete but its the best
> plan9 has at present - without using linuxemu.
>

I appreciate abaco for what it is, but unfortunately it's not something I
can expect to satisfy most users' activities on the web.

I still haven't tried a browser through linuxemu though... maybe that'll
end up being sufficient.

> If you are saying that you are willing to take this on (getting a modern
> native plan9 web browser running) I may be able to help in some areas
>

Excellent - I'm definitely willing to see how far I can get.

My little 9 network is currently in the midst of being re-deployed (was
going to play around with 9front); when I get it back online (so I have
an instance to work from), I'll send you an email - I could definitely use
the advice/pointers of someone more experienced. Thanks!

> One idea I was considering for several years was trying to get Dillo
> running as a fairly compliant browser, initially under an X11 server but
> later you might be able to merge the framebuffer backend to dillo (via a
> library I cannot remember) and replace it with a library which talks
> /dev/draw rather than linux framebuffer.
>

Interesting...  I did spend some time seeking out other, possible more
simple, alternatives, dillo for instance - but I came to the spoiled-minded
conclusion that to do it right - so that it's not just another "kind-of
basically working for a limited subset of use-cases" situation - that it
really should use a current and active engine such as webkit (preferable)
or gecko.

> just some random thoughts.
>

Thankyou!


Cheers

Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames

[Greg Comeau]

In article <9ad5871bf83f37b7e7ed19169d389f6d@quintile.net>,
Steve Simon <steve@quintile.net> wrote:
>There is cfront c++ but this is so old it would probably not be
>worth getting it to work - templates never worked in AT&T cfront.

And not modern C++ in any event at this point even if so...

>The exception to this the HP cfront implementation
>which they might release if hassled.

As I recall, HP cfront was one in the same (adding the implementation
of exception handling to cfront mostly).  They did do further
work on (modern) templates but it was to an inhouse compiler.
--
Greg Comeau / 4.3.10.1 with C++0xisms now in beta!
Comeau C/C++ ONLINE ==>     http://www.comeaucomputing.com/tryitout
World Class Compilers:  Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames

[Ethan Grammatikidis]

On 30 Apr 2011, at 9:16 am, errno wrote:
>
> So, shaking this out just a bit further:
>
> (anyone reading, please just ignore this if you find it too long,
> and/or too annoying, and/or too naive - or whatever - I'd rather
> hear crickets chirping than hecklers carping - thanks)

I hope you won't find this post heckling, although I will admit I
find the temptation to troll almost irresistible when web
"technology" is involved.

> Porting Options:
>
> * gecko

Gecko had a reputation for really bad code some years ago. I don't
think this has improved, I think it's got worse considering the devs
would rather write long blog posts whining about exactly how hard it
is to integrate about:blank into Firefox 4 when they could have it
store a zero-length (or a blank html) page internally and display
that with the standard renderer.

Also, if it's any guide to gecko performance, Firefox is !%@%#@ slow!
Firefox 3 manages to make my dual-core 1.8GHz 2GB netbook seem
horribly outdated where Opera runs just fine. I'm not even thinking
about touching Firefox 4.

> * webkit

I don't know what the current status is, but it seems to go through
phases of being very unstable. That said, I'm actually half-wishing I
had a stable webkit browser in Linux. Still, it's C++ and I can only
add to what you've heard regarding the difficulties of porting a C++
development environment. ;)

Possibly another option:
* netsurf

I'm reliably informed this is making very good progress. It also
_may_ be possible to build it with a compiler other than gcc. They
recommend gcc now, but not too long ago they supported a range of
compilers. It certainly builds and runs on a much wider range of
systems than either Gecko or Webkit, both of which are tied to one
toolkit.

I think I'd better stop now, before I go into a rant about that "one
toolkit."

Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames

[smiley]

errno <errno@cox.net> writes:

> Due to the requirements, it appears that incorporating the web as a
> 1st-class-platform in plan 9 is effectively unapproachable:

You forgot to backtrack to your webkit/gecko choicepoint and follow down
the gecko goal tree.

--
+---------------------------------------------------------------+
|E-Mail: smiley@zenzebra.mv.com             PGP key ID: BC549F8B|
|Fingerprint: 9329 DB4A 30F5 6EDA D2BA  3489 DAB7 555A BC54 9F8B|
+---------------------------------------------------------------+

Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames

[errno]

On Saturday, April 30, 2011 03:21:09 PM smiley@zenzebra.mv.com wrote:
> errno <errno@cox.net> writes:
> > Due to the requirements, it appears that incorporating the web as a
> > 1st-class-platform in plan 9 is effectively unapproachable:
>
> You forgot to backtrack to your webkit/gecko choicepoint and follow
> down the gecko goal tree.
>

Gecko is also written primarily in c++, which means porting a c++
compiler to plan 9 would still remain a prerequisite for that path also.

(I haven't done a valid evaluation of gecko vs. webkit; I've built and
poked around webkit, but haven't done the same for gecko. My c skills
are rather humble, but my c++ skills are entirely non-existant... so I'm
unable to perform a valid evaluation of the two anyhow)

On Saturday, April 30, 2011 05:18:03 AM Ethan Grammatikidis wrote:
> Possibly another option:
> * netsurf
>

Very cool, that's another potential port candidate that I wasn't aware
of - and it's written in c, which lowers the bar quite a bit.  I'll definitely
take a closer look at netsurf next weekend, maybe it's a more realistic
target.  Thanks!

Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames

[Lyndon Nerenberg]

> Gecko is also written primarily in c++, which means porting a c++
> compiler to plan 9 would still remain a prerequisite for that path also.

No, it's written in a combination of g++-<version_of_the_week> and
whatever Visual Studio calls C++ for its current release.

You cannot port that shit. Nor should you.

--lyndon

Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames

[errno]

On Saturday, April 30, 2011 04:33:23 PM Lyndon Nerenberg wrote:
> > Gecko is also written primarily in c++, which means porting a c++
> > compiler to plan 9 would still remain a prerequisite for that path also.
>
> No, it's written in a combination of g++-<version_of_the_week> and
> whatever Visual Studio calls C++ for its current release.
>
> You cannot port that shit. Nor should you.
>

Warning heeded, and understood.  That's not the first time I've
heard less than stellar accounts regarding gecko.

One thing with webkit is at least the option is there to use a different
compiler (llvm/clang).  And it looks like they're in the initial stages of
unifying the build system to gyp (written in python, which Plan 9
already supports) - which is far better  than autotools IMHO.

Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames

[Lyndon Nerenberg]

> One thing with webkit is at least the option is there to use a different
> compiler (llvm/clang).  And it looks like they're in the initial stages of
> unifying the build system to gyp (written in python, which Plan 9
> already supports) - which is far better  than autotools IMHO.

For the last year I've been supporting build bits @flock.com.

You cannot build this shit without the gxx of the week.

Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames

[blstuart]

> Starting Goal:  a modern, standards compliant web engine library for Plan 9

As others have pointed out that's pretty hard to define, but in
the current web world, you can cover a surprisingly large fraction
of sites if you have good JavaScript and CSS support.  Running
Java in the browser isn't as trendy as it once was, so the big
missing piece would be Flash, which of course, is the root of
all evil.

> Options:
>
> * write from scratch
>
> * port existing codebase

There's one other possibility that I've thought about.  Inferno's
browser charon is more capable than it might appear.  It has
some degree of JavaScript support.  The main thing I've noticed
when trying to use it for some day-to-day browsing is that
it lacks CSS and could use some work on performance.  I suspect
that adding CSS to charon and doing some performance work
on it would be easier than either of those two options.

BLS

Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames

[erik quanstrom]

> There's one other possibility that I've thought about.  Inferno's
> browser charon is more capable than it might appear.  It has
> some degree of JavaScript support.  The main thing I've noticed
> when trying to use it for some day-to-day browsing is that
> it lacks CSS and could use some work on performance.  I suspect
> that adding CSS to charon and doing some performance work
> on it would be easier than either of those two options.

in the little i've looked at css, the programming model seemed
relatively clean and straightforward.  unfortuntely, most all css seems
to be written as part of a global obfuscated css programming contest.
clearly there are no winners.

- erik

Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames

[errno]

On Sunday, May 01, 2011 04:56:40 PM blstuart@bellsouth.net wrote:
> > Starting Goal:  a modern, standards compliant web engine library
> > for Plan 9
>
> As others have pointed out that's pretty hard to define,
>

Agreed, I did try to make an attempt at a modicum of a definition to
work from, but it was in an earlier post:

(by "web experience", I'm not talking about porting firefox and flash to
Plan 9 - I'm talking about native or ported libraries for what wikipedia
refers to as a "web browser engine" or "layout engine"; and by "fully
functional", I'm talking about something that can score at least an
80% or so on the acid2 test.)

web browser engine (html, css, dom & ecmascript)


> but in the current web world, you can cover a surprisingly large
> fraction of sites if you have good JavaScript and CSS support.
>

Definitely:  css 2.1 (or 3), ecmascript 3rd (or 5th) w/ dom support,
html 4.1 (or 5)

That's the entire client side of "the web". (well, ssl is pretty crucial...)


Digression:
---
With regards to "web browsers" - the over-generalized kitchen-sync
applications that supply the cookie management and password
storing, and bookmarks, and cert management, and home pages,
and back/forward  buttons and all that shtuff - a decent web engine
library would facilitate any number and any manner of unique and
specialized front-ends. The engine is the important part, the
actual front-ends are expected to just... materialize.

Interesting-ish web browsers:

luakit: http://luakit.org/projects/luakit/
vimprobable: http://vimprobable.org/

Personally though, I'm tired of the "web browser" and would like to see
more of a "web shell". A "web shell" would look like a command shell,
have zero interface or control widgets, and would consist entirely of the
html canvas. Ctrl-c exits the html canvas and throws you back into the
web command shell. Type a url, hit enter - the command shell is replaced
with the html canvas again. No back/forward/home buttons, no menus or
url bars, or search bars, etc., no config screens - just like an rc shell.
---

> Running Java in the browser isn't as trendy as it once was, so the
> big missing piece would be Flash, which of course, is the root of
> all evil.
>

In my mind, for whatever little that's worth, I think flash (and java)
could both be reasonably ditched entirely. Under the naive hope
that "the web" has already moved away from embedding java, and
flash is next to go (once html 5 is generally ubiquitous).


> > Options:
> >
> > * write from scratch
> >
> > * port existing codebase
>
> There's one other possibility that I've thought about.  Inferno's
> browser charon is more capable than it might appear.  It has
> some degree of JavaScript support.  The main thing I've noticed
> when trying to use it for some day-to-day browsing is that
> it lacks CSS and could use some work on performance.  I suspect
> that adding CSS to charon and doing some performance work
> on it would be easier than either of those two options.
>

I suspect netsurf might actually be better to work from than charon,
if only because netsurf is already written c rather than limbo, and
has already been ported to many platforms.

Another idea, is rather than port an entire existing web engine
stack (webkit) - is to just cherry pick some of the separate pieces -
spidermonkey and libcss (both written in c), for instance - port them
over individually then bake them into abaco or a "webfs-ng" or
something.

Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames

[erik quanstrom]

> I suspect netsurf might actually be better to work from than charon,
> if only because netsurf is already written c rather than limbo, and
> has already been ported to many platforms.

unless i've completely misunderstood, brian is suggesting to run charon
in plan 9-hosted inferno.

- erik

Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames

[errno]

On Sunday, May 01, 2011 06:44:42 PM erik quanstrom wrote:
> > I suspect netsurf might actually be better to work from than charon,
> > if only because netsurf is already written c rather than limbo, and
> > has already been ported to many platforms.
>
> unless i've completely misunderstood, brian is suggesting to run charon
> in plan 9-hosted inferno.
>

Ah, I believe you're right; thanks for the correction.

I'll risk venturing an opinion on that approach:

Running a plan 9 hosted inferno is essentially another take on the vnc or
linuxemu workarounds. It won't provide the same freedoms and benefits
of a native library/engine/framework.

Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames

[erik quanstrom]

> I'll risk venturing an opinion on that approach:
>
> Running a plan 9 hosted inferno is essentially another take on the vnc or
> linuxemu workarounds. It won't provide the same freedoms and benefits
> of a native library/engine/framework.

what freedoms are those?

- erik

Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames

[errno]

On Sunday, May 01, 2011 07:38:43 PM erik quanstrom wrote:
> > I'll risk venturing an opinion on that approach:
> >
> > Running a plan 9 hosted inferno is essentially another take on the vnc or
> > linuxemu workarounds. It won't provide the same freedoms and benefits
> > of a native library/engine/framework.
>
> what freedoms are those?
>

The freedom _from_ an extra, extraneous, alien environment. [1]

The freedom _for_ building a variety of native front-ends.

The freedom _for_ integrating with existing native libraries.


Perhaps "freedoms" and "benefits" are synonymous in this context, and
thus redundant.


[1] yes - I think it's strictly accurate to consider inferno as being alien
and extraneous to plan 9.

Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames

[erik quanstrom]

> The freedom _from_ an extra, extraneous, alien environment. [1]

but it's a web browser.  it's already an alien environment.  :-)

> The freedom _for_ building a variety of native front-ends.
>
> The freedom _for_ integrating with existing native libraries.

what's the advantage here?  i don't want to build a front-end to
a web browser, and i don't really care if it links against libc or whatever.
hosted inferno is a very good simulation of running directly on the
host os.

- erik

Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames

[errno]

On Sunday, May 01, 2011 08:15:12 PM erik quanstrom wrote:
> > The freedom _from_ an extra, extraneous, alien environment. [1]
>
> but it's a web browser.  it's already an alien environment.  :-)
>

Man I had hunch you would say that.   :)

Inferno is an alien environment too, but you don't run linuxemu
to run linux-hosted inferno - you run a native inferno directly on
plan 9.

I'd like to run a "more native web" directly on plan 9.

The idea is to remove the "middle-man".  That's the 'extra'
part of the "extra, extraneous, alien" I had referred to.

(and, forget about the "browser" part of the "web" for now - I think
web _browsers_ suck worse than the web itself - I'm just concerned
with the web _engine_ for now)

> > The freedom _for_ building a variety of native front-ends.
> >
> > The freedom _for_ integrating with existing native libraries.
>
> what's the advantage here?
>

The same basic advantages you'd get for running native plan 9 inferno
rather than running inferno for linux under linuxemu (if that's even
possible).

Or largely the same reasons I prefer to run the vim ported from ape,
than a vim running in a vnc window or under linuxemu (again, if that's
even possible - I haven't yet played w/ linuxemu), but a purely native
vim would be even better; even though vim may be considered alien.

> i don't want to build a front-end to
> a web browser,
>

I imagine there's a large host of things on crontrib that you yourself
have no personal interest in developing with or using.

> and i don't really care if it links against libc or whatever.
>

And I don't really care to learn and write limbo for inferno. Thus,
for me, linking against libc on plan 9 is considered more optimal.

On Sunday, May 01, 2011 08:39:02 PM ron minnich wrote:
> On Sun, May 1, 2011 at 8:11 PM, errno <errno@cox.net> wrote:
> > etc.
>
> Just wondering if you have looked at webfs.
>

I've browsed the source, a few months ago; when I first felt the lack
of a more current-standards-conforming web experience. (I keep
saying "web experience" so as not to tie myself to "web browser".)

Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames

[ron minnich]

On Sun, May 1, 2011 at 8:11 PM, errno <errno@cox.net> wrote:
> etc.


Just wondering if you have looked at webfs.

ron

Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames

[Steve Simon]

Just to add some more confusion to the mix, there was a port of an early charon
release from limbo to c, called 'i' - the single letter.

This worked to the point of working like a buggy abaco (perhaps I am unfair but
that is what it feels like), Its on sources (in contrib/extra I think).

I'am not suggesting it should be used as a starting point but its an interesting
example to look at.

-Steve

Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames

[Salman Aljammaz]

why is everyone on about native web?  what does that even mean?

http://diveintomark.org/archives/2011/04/15/nativity-scene

(sorry, couldn't resist!)

salman

On Mon, May 2, 2011 at 3:29 AM, errno <errno@cox.net> wrote:
> Running a plan 9 hosted inferno is essentially another take on the vnc or
> linuxemu workarounds. It won't provide the same freedoms and benefits
> of a native library/engine/framework.

Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames

[errno]

On Monday, May 02, 2011 03:38:53 AM Salman Aljammaz wrote:
> why is everyone on about native web?  what does that even mean?
>
> http://diveintomark.org/archives/2011/04/15/nativity-scene
>
> (sorry, couldn't resist!)
>

(:

It occurs to me that the existence of webfs and abaco, etc. are indicators
that the idea of a "native" web engine/library isn't entirely without merit.

Either that... or the people involved in those other attempts finally
realized that firefox over vnc or linuxemu, and charon over inferno,
are far superior solutions in every conceivable way.

(:

"Web sites and HTML5 run best when they run natively, on a browser
optimized for the operating system on your device."

A more generalized form of the above statement would not be devoid
of fact.

Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames

[Charles Forsyth]

>>"Web sites and HTML5 run best when they run natively, on a browser
>>optimized for the operating system on your device."

>A more generalized form of the above statement would not be devoid
>of fact.

it actually misses the point: once the processor has waded through a vast array of code
that implements a long and growing list of poorly specified `standards'
(which must be implemented in quite specific ways for websites to work)
the operating system has little relevance and influence, for this particular task.
it's hard to see how a fast Javascript implementation, for example, is especially
dependent on the operating system on which it runs, at least for any conventional system.
the discussion from which the original statement was taken was certainly a little
short on examples where the choice of underlying system made a big difference to
either the ease or structure of implementation, or the speed of the result.

Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames

[dexen deVries]

On Monday 02 of May 2011 18:29:13 Charles Forsyth wrote:
it's hard to see how a fast Javascript implementation,
> (...) it's hard to see how a fast Javascript implementation,
> for example, is especially dependent on the operating system
> on which it runs (...)

<![PESSIMISTIC VIEW[

that used to be the case, but much not anymore. some popular websites are JS-
heavy, and the browser has to do heavy lifting. various speedups were
implemented by popular browsers -- and are practically necessary for use of
those sites. one popular speedup is compilation of JS to native code. this
depends to a good deal on paging for protection (and perhaps GC, not sure).
this requires some co-operation with the OS.


another point of dependence (read: infinite surface of dependence) is the
interaction of JS and DOM with OS-specific input model. today not only
hyperlinks and comboboxes are widgets, but a lot of seemingly plain areas are
made active, both on click and on mere hover, (for good reasons and with good
use).


also the output model: (re-)drawing screen content. both good old 2D APIs and
(for IE, at least, but will in near future for others) interacting with GPU
for access to accelerated drawing primitives, working neatly with composition
and avoiding costly cascades of copying image data around system memory and to
video memory.


yet another point, probably best illustrated with FF: some plugins contribute
functionality via JS code. supporting such plugins also should have some
platform-specific dependencies.


something having little to do with JS itself, but important for website
rendering: font support. the second worst problem in computing, IMHO. some
websites require pixel- or even sub(!)-pixel accuracy, lest they end up
looking all messy and/or end up with overlapping widgets. yes, it runs kinda
contrary to the purpose of HTML and CSS. another fine technical decision by
technically unqualified managerial personnel, sigh.


last but not least, google's NaCl (a.k.a. Native Client) which uses certain
properties & aspects of memory protection for secure execution of binary code
from foreign sources (yeah, i know we've been there; but this one oughta work,
as it depends on silicon, not digital signatures from one gatekeeper company).
it again depends on the OS to a degree for running the code. i believe this is
an interesting thing, and possibly a viable alternative to including explicit
support for countless alternative scripting languages directly into browsers.


to wrap it up: i don't believe in high-performance cross-platform browsers.
they either need helluva lots of maintenance & chasing the evolving platforms,
or not perform all that well.

]]>

--
dexen deVries

``One can't proceed from the informal to the formal by formal means.''

Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames

[Charles Forsyth]

>why is everyone on about native web?  what does that even mean?

good questions. i liked that reference, which i hadn't seen before.

Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames

[Jack Norton]

errno wrote:
>
> Starting Goal:  a modern, standards compliant web engine library for Plan 9


No!

Has anyone tried out Gwene?  Basically you "sign up" an RSS feed and it
presents it as an NNTP news feed that you can access via news.gwene.org.

Now, this is what I like.  Take some core sites and resources ("all
useful features" port of the web) and use the sites API, write a
"translator" to present the content as news, or plain text (files served
via a fs) where applicable.

If I had time and the stomach to deal with website "API's" and content
formating, I would do just that.

I'd claim that most sites these days lend well to being translated as
NNTP news feeds.  Most sites are people 'posting' crap and thoughts on
said crap at regular intervals.

Some useful staples like wikipedia could get their own fs (wikipediafs?
-- that's a mouthful...).

Fun but frivolous stuff like reddit could be presented as NNTP as well.
  If done right, there could be one NNTP server like Gwene that we could
all use -- or you could roll your own for at home.  And of course it
doesn't need to be nntp.  I just figured it could be used by people on
OS's they get stuck with at work that don't speak 9p :)

For newly discovered sites that you'd like to visit when curiosity gets
the best of you -- you've got abaco or something under linuxemu.

I say modify the web for plan9, not plan9 for the web.

Frankly I'd be more interested in a video player (just a few common
codecs that's all) than a modern web browser.

-Jack

Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames

[Anthony Sorace]

[-- Attachment #1: Type: text/plain, Size: 625 bytes --]

On May 2, 2011, at 9:54 AM, Jack Norton wrote:

> I'd claim that most sites these days lend well to being translated
> as NNTP news feeds.  Most sites are people 'posting' crap and
> thoughts on said crap at regular intervals.

maybe by number, but that's not really a useful metric. this model
would do nothing to help me deal with any of the financial institutions
i have to deal with, for example. moreover, i'd say that the sites that
are most amenable to this sort of representation are the ones already
reasonably handled by abaco or charon.

someone remind me what this has to do with the 9atom kernel?


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 210 bytes --]

Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames

[Charles Forsyth]

>Frankly I'd be more interested in a video player (just a few common
>codecs that's all) than a modern web browser.

that's possibly feasible.

Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames

[Greg Comeau]

errno, you seem to have an interesting logic flow on some of
the pros and cons you'd be up against.  I have two probably
naive questions (for anybody):

* Assuming errno gets his wish, is Plan 9 as a system up to the task?
  (Please no flames.)
* I don't know much about it, but I know a number of people
  who still use dumb terminals and such and swear by lynx.
  I know this is not what errno is seeking, and it could even
  end up being a distraction to such a goal, but don't know
  what can be built atop it, so this could equally be an insane
  suggestion to look into it.
--
Greg Comeau / 4.3.10.1 with C++0xisms now in beta!
Comeau C/C++ ONLINE ==>     http://www.comeaucomputing.com/tryitout
World Class Compilers:  Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames

[erik quanstrom]

> * I don't know much about it, but I know a number of people
>   who still use dumb terminals and such and swear by lynx.
>   I know this is not what errno is seeking, and it could even
>   end up being a distraction to such a goal, but don't know
>   what can be built atop it, so this could equally be an insane
>   suggestion to look into it.

/n/sources/contrib/fgb/tar/lynx2-8-7.tgz

- erik

Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames

[Lucio De Re]

On Thu, May 05, 2011 at 12:33:47PM +0000, Greg Comeau wrote:
> * I don't know much about it, but I know a number of people
>   who still use dumb terminals and such and swear by lynx.

Links was ported to Plan 9 (I'm sure copies of it can be found).
The problem here would be tracking developments, considering the frequency
of changes and bug fixes, given the much smaller pool of developers that
Plan 9 has access to.

++L

Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames

[ron minnich]

The reason I asked if errno had looked at webfs was that he can do the
standard thing (port some C++/Python Library From Hell to Plan 9) or
do a much more interesting thing, which is look at stuff like abaco
and webfs, and learn some lessons, and build something that is faster,
better, and cheaper. This is a research OS, not a Windows replacement.
There's a reason to use it. You want a great desktop experience that
is familiar, get an ipad.

Just compare ratrace to strace some time. Sometimes, if you get some
initial structure right, you can see 100:1 code shrinkage *and* a
pretty good result.

I've never heard anyone say too forcefully that they think the various
web clients have got the structure right. It's hard to believe it's
right given their size, complexity, and bugginess.

ron

Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames

[errno]

On Thursday, May 05, 2011 09:35:15 PM ron minnich wrote:
> The reason I asked if errno had looked at webfs was that he can do the
> standard thing (port some C++/Python Library From Hell to Plan 9)
>

The above described standard thing is more in line with my capabilities.

Porting clang is well beyond me though, even at my most optimistic; so
I've decided to dedicate time toward looking more closely into porting
the netsurf libs for css, html and dom; and mozilla's spidermonkey - as
they are further along than webfs/abaco ("further along", meaning
seemingly more active and current), and I can focus simply on a port,
rather than green-field design and development from scratch.

In other words, I think I can manage to eventually port small ad-hoc
stuff; and then slowly "bake" it closer and closer to something that
is more and more "9'ish".

Although I think I understand that the prevailing custom here on 9fans
is to scorn most software written by and for the unwashed masses - or
for the general consumer industry - I'm not so convinced that a reasonable
compromise can't exist to fulfill the needs of a class of user who exist a
little higher up the stack than, say, low-level systems programmers working
on specialist projects within industrial or academic research and development
facilities.

> or do a much more interesting thing, which is look at stuff like abaco
> and webfs, and learn some lessons, and build something that is faster,
> better, and cheaper.
>

It's more interesting, yes - but I fear also far, far less likely for me to
pull off; no one else has managed to pull it off yet, there's no way I can.

(Like I said before: I write backend business logic for web-based applications
in java/groovy and perl and shell, along w/ some db and network administration
etc. on linux; my skills are humble, but serviceable for what I do for a
living .... not to give you my life story or anything... heheh)

In other words, I'm fully cognizant of the fact that I do not have the
necessary pre-requisite experience to build a better mouse trap.

> This is a research OS, not a Windows replacement.
> There's a reason to use it. You want a great desktop experience that
> is familiar, get an ipad.
>

Aww... man.

Do you not think it's possible or worthwhile to have a great(er) desktop
(or consumer-oriented embedded device) experience built atop Plan 9?

After a few months of reading and learning and actual hands-on
experience, I've found that rio and acme and mk and 8c ,etc., are
far less interesting than union directories, per-process namespaces,
9p and intrinsic, ubiquitous distributed computing - that's where I
personally think the action is at.

I don't care what editor or compiler someone uses; but the idea of cpu'ing
from a smartphone to run heavy-weight processes (for just one example)
gets the geek in me pretty excited with possibility.

Or the idea of a home network where I have one cpu/auth server, one file
server and a number of super cheap thin-clients providing a modern
web interface and shared data for friends, guests and family.

I'm tired of maintaining everyone's computers in my house on an ad-hoc
basis; and I think I could deploy a higher performing, more maintainable,
but overall cheaper network with Plan 9. But I can hardly expect visitors
and family to run acme and abaco.


Cheers

Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames

[ron minnich]

On Fri, May 6, 2011 at 8:45 AM, errno <errno@cox.net> wrote:

> The above described standard thing is more in line with my capabilities.

yes, but that is not the issue, or should not be. The issue should be
"what's the way to get to goal <x> in an esthetic manner".

There's plenty of systems you can take what you know and get something
going. If you're not here to learn, then what's the point?


> In other words, I think I can manage to eventually port small ad-hoc
> stuff; and then slowly "bake" it closer and closer to something that
> is more and more "9'ish".

I don't agree. Put it this way: if your something doesn't start with
webfs then it's probably impossible
to make 9-ish.


> After a few months of reading and learning and actual hands-on
> experience, I've found that rio and acme and mk and 8c ,etc., are
> far less interesting than union directories, per-process namespaces,
> 9p and intrinsic, ubiquitous distributed computing - that's where I
> personally think the action is at.

The I humbly submit that you may have Missed The Point.

>
> I don't care what editor or compiler someone uses; but the idea of cpu'ing
> from a smartphone to run heavy-weight processes (for just one example)
> gets the geek in me pretty excited with possibility.

well, maybe you haven't :-)

ron

Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames

[errno]

On Friday, May 06, 2011 12:08:08 AM ron minnich wrote:
> > After a few months of reading and learning and actual hands-on
> > experience, I've found that rio and acme and mk and 8c ,etc., are
> > far less interesting than union directories, per-process namespaces,
> > 9p and intrinsic, ubiquitous distributed computing - that's where I
> > personally think the action is at.
>
> The I humbly submit that you may have Missed The Point.
>

I'm sorry if I'm being obtuse - what is The Point that you're referring?

> > I don't care what editor or compiler someone uses; but the idea of
> > cpu'ing from a smartphone to run heavy-weight processes (for just one
> > example) gets the geek in me pretty excited with possibility.
>
> well, maybe you haven't :-)
>

Now I'm really confused.

Speak not in riddles, friend - explain what you mean!  (:

Please.   (:

Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames

[Bakul Shah]

[-- Attachment #1: Type: text/plain, Size: 1545 bytes --]

On May 6, 2011, at 12:08 AM, ron minnich <rminnich@gmail.com> wrote:

> On Fri, May 6, 2011 at 8:45 AM, errno <errno@cox.net> wrote:
>
>> After a few months of reading and learning and actual hands-on
>> experience, I've found that rio and acme and mk and 8c ,etc., are
>> far less interesting than union directories, per-process namespaces,
>> 9p and intrinsic, ubiquitous distributed computing - that's where I
>> personally think the action is at.
>
> The I humbly submit that you may have Missed The Point.

The things errmo finds more interesting are indeed where there has
been far more experimentation. Acme is great as a programmer's editor
but I tend to think that it has reached an evolutionary dead end
(how's that as flamebait?:-). Its model of type anywhere doesn't buy
you much where the primary mode is reading (as opposed to writing or
editing). Not everything requiring a UI fits comfortably in the acme/
rio model. Designing a good UI is just very hard and the challenges
there IMHO don't benefit much from plan9's strong points.

Well designed documents that use multiple fonts, graphical elements,
white space, colors, pictures are far easier on one's eyes. It would
be great if such pages can be viewed, and even better, created on
plan9. HTML isn't just for browsers anymore! On the Mac there are some
great apps for journal or blog writing etc that use the webkit (not
everyone uses MS word or pages). In a way a good webkit can *vitalize*
plan9. So more power to errno if he wants to do this!

[-- Attachment #2: Type: text/html, Size: 2419 bytes --]

Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames

[John Floren]

On Fri, May 6, 2011 at 8:45 AM, Bakul Shah <bakul@bitblocks.com> wrote:
> Well designed documents that use multiple fonts, graphical elements, white
> space, colors, pictures are far easier on one's eyes.

Yes, and then on the other hand, you have web pages. Oh, wait, you
weren't talking about postscript documents? :-)

> It would be great if
> such pages can be viewed, and even better, created on plan9. HTML isn't just
> for browsers anymore! On the Mac there are some great apps for journal or
> blog writing etc that use the webkit (not everyone uses MS word or pages).
> In a way a good webkit can *vitalize* plan9. So more power to errno if he
> wants to do this!

Of course you can create documents using multiple fonts, graphical
elements, white space, colors, pictures on Plan 9. I do it in troff
from time to time. I also do it by writing HTML in a text editor (like
Acme), which is also how pretty much all the real web developers (as
opposed to dabblers in FrontPage) do it too (except they also use CSS
and real programming language backends). The idea that you need a
special application built around WEBKIT of all things (I just vomited
in my shoes a little) just to write a blog is utterly ridiculous.

Now, I'd love to see webkit ported, because I'd love to have a
fully-featured web browser on Plan 9. However, call me cynical, but
I'm a little concerned that we're seeing yet another repetition of
that familiar pattern: New guy comes in, wants to be Plan 9 messiah by
porting [gcc/web browser] or writing drivers, makes grandiose plans,
everyone points out the flaws in said plans which came about from not
understanding Plan 9 yet, new guy disappears.


John

Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames

[Bakul Shah]

On May 6, 2011, at 8:59 AM, John Floren <john@jfloren.net> wrote:

> On Fri, May 6, 2011 at 8:45 AM, Bakul Shah <bakul@bitblocks.com>
> wrote:
>> Well designed documents that use multiple fonts, graphical
>> elements, white
>> space, colors, pictures are far easier on one's eyes.
>
> Yes, and then on the other hand, you have web pages. Oh, wait, you
> weren't talking about postscript documents? :-)
>
>> It would be great if
>> such pages can be viewed, and even better, created on plan9. HTML
>> isn't just
>> for browsers anymore! On the Mac there are some great apps for
>> journal or
>> blog writing etc that use the webkit (not everyone uses MS word or
>> pages).
>> In a way a good webkit can *vitalize* plan9. So more power to errno
>> if he
>> wants to do this!
>
> Of course you can create documents using multiple fonts, graphical
> elements, white space, colors, pictures on Plan 9. I do it in troff
> from time to time. I also do it by writing HTML in a text editor (like
> Acme), which is also how pretty much all the real web developers (as
> opposed to dabblers in FrontPage) do it too (except they also use CSS
> and real programming language backends). The idea that you need a
> special application built around WEBKIT of all things (I just vomited
> in my shoes a little) just to write a blog is utterly ridiculous.

Postscript is fine for viewing but if you want editable pages it
doesn't cut it. If you want to collaborate with non techies on other
platform, troff, raw HTML or TeX is quite limiting. Apps such as
journler could be created by one person because of the webkit. They
are very easy to use and you don't have to be a  "real web developer"
to write. I don't particularly like HTML/XML but it has become
ubiquitous as a portable format. At least with a good app I don't have
to look at raw HTML (just as programming in a HLL means you don't have
to look at the bletcherous x86 code 99.99% of time).

> Now, I'd love to see webkit ported, because I'd love to have a
> fully-featured web browser on Plan 9. However, call me cynical, but
> I'm a little concerned that we're seeing yet another repetition of
> that familiar pattern: New guy comes in, wants to be Plan 9 messiah by
> porting [gcc/web browser] or writing drivers, makes grandiose plans,
> everyone points out the flaws in said plans which came about from not
> understanding Plan 9 yet, new guy disappears.

There is that danger. 9 out of 10 (or may be even 99 out of 100) will
disappear. It can get tiring but so what. We don't have to point out
the flaws! Let them discover on their own & learn the hard way (the
only way people learn). I prefer to encourage new people even knowing
most of the time we won't benefit.

Not to say you are wrong or I am right; just a different point of view
to consider!

Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames

[tlaronde]

On Fri, May 06, 2011 at 08:45:24AM -0700, Bakul Shah wrote:
>[...]
> Well designed documents that use multiple fonts, graphical elements,
> white space, colors, pictures are far easier on one's eyes. It would
> be great if such pages can be viewed, and even better, created on
> plan9. HTML isn't just for browsers anymore! On the Mac there are some
> great apps for journal or blog writing etc that use the webkit (not
> everyone uses MS word or pages). In a way a good webkit can *vitalize*
> plan9. So more power to errno if he wants to do this!
>

Well, there is a layout engine already. Able to combine texte and
mathematical writing. It is called TeX...

I sometimes wonder what could be obtain using this engine to produce a
formatted text to insert/place as boxes on a representation mean: hard
copy is one, soft copy (screen) is just another.

All in all, that's what MetaPost does for the labels in drawing (can use
troff(1) too).
--
        Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
                      http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames

[Lucio De Re]

On Thu, May 05, 2011 at 11:45:27PM -0700, errno wrote:
>
> I'm tired of maintaining everyone's computers in my house on an ad-hoc
> basis; and I think I could deploy a higher performing, more maintainable,
> but overall cheaper network with Plan 9. But I can hardly expect visitors
> and family to run acme and abaco.
>
To cut a long story short, you want your cake and eat it.  Unfortunately,
99% of the population prefer to eat a pre-made cake and give up the
ownership part.  It is hardly Plan 9's fault that those who write poor
software for the wrong environment can't be evangelised; as you point out,
it doesn't even make sense.

But you're stuck, aren't you?  As soon as, say, a browser is developed for
Plan 9 (assuming that someone could afford the resources), the standards
will change and the browser will need major surgery.  Who's going to
invest in that?  Basically, the mover and shakers are precisely the
people who don't want Plan 9 (or anything like it) to be a success story.
They are winning.

++L

[9fans] freedom (was Re: Compiling 9atom kernel)

[errno]

I'm aware that 9fans doesn't usually take kindly to speculative fiction,
conjecture, or speculation.  Please forgive me, I'm writing with honest
intentions.

On Friday, May 06, 2011 05:07:21 AM Lucio De Re wrote:
> On Thu, May 05, 2011 at 11:45:27PM -0700, errno wrote:
> > I'm tired of maintaining everyone's computers in my house on an ad-hoc
> > basis; and I think I could deploy a higher performing, more maintainable,
> > but overall cheaper network with Plan 9. But I can hardly expect visitors
> > and family to run acme and abaco.
> 
> To cut a long story short, you want your cake and eat it.  Unfortunately,
> 99% of the population prefer to eat a pre-made cake and give up the
> ownership part.  It is hardly Plan 9's fault that those who write poor
> software for the wrong environment can't be evangelised; as you point out,
> it doesn't even make sense.
> 
> But you're stuck, aren't you?  As soon as, say, a browser is developed for
> Plan 9 (assuming that someone could afford the resources), the standards
> will change and the browser will need major surgery.  Who's going to
> invest in that?  Basically, the mover and shakers are precisely the
> people who don't want Plan 9 (or anything like it) to be a success story.
> They are winning.

I concur, and I think this is a generally sound summary of the situation. And
highly astute, with regards to your comment concerning certain movers and
shakers.  Plan 9 has mind-numbing potential of being a bonafide "disruptive
technology", if the cat ever got outta the bag. I'm convinced that the web is
the key. 

html + css + javascript over http through ssl is able to adequately satisfy
~80% of the general public's computing needs and wants. (I pulled that 
"80%" figure out of my ass, but I doubt I'm all too far from the mark)

So, what to do?

The Web:

Reject it? (aka "go buy a tablet" )

Reproduce it? (aka "have you looked at webfs?" )

Reuse it? (aka "port webkit")


There's no possible way that I'm the only one who has envisioned 
some rendition of the following science-fiction:

* a Plan 9-based platform targeted at the general consumer market

* this platform offers html + css + javascript (aka "the web") as the
primary front-end ui

* said platform is purchased via a "turnkey" hardware package:  a single
preconfigured plan 9 cpu/auth/file server using commodity hardware, in
the $2000-$4000 price range

* said unit can comfortably support ~10 simultaneous users, each using
super-cheap thin-clients at ~$200 dollars per unit

* the idea is the consumer purchases the cpu/auth/file server unit and
one or more thin client units; this is all any typical household needs

* with purchase of said unit, customer receives option to pay $19.99
a month for a hosted Plan 9 VPS - customer's household cpu/auth/file
server stays synchronized with this VPS, thereby facilitating ever-present
remote access to personal computing environment

* said platform is easily scaleable (obviously - it's plan 9) to support
larger more demanding environments - such as businesses and 
organizations - decouple the auth/cpu/file server and/or purchase
higher-end servers 

(monetary values pulled out of my ass - just throwing ballpark 
guestimates to get the point across)

I don't want google and facebook and flicker et. al. owning my data; I
don't want to make intel and dell rich with their overpowered machines
and processors so I can run ever-bloating os and software; I don't want to
maintain a collection of various ad-hoc essentially autistic (please excuse
the term) computers in my household. I want to be able to access my
private, personal computing environment from anywhere with an internet
connection via my portable thin client. I want to be able to easily share
my data and resources within a trusted circle. I want all communications
to innately and transparently run over an ssl encrypted channel at all
times.

A radically distributed internet where power and control is put back into 
the hands of individuals. I'm tired of centralized gilded cages and
hierarchical client server models formed and shaped mostly for the benefit 
of a few monolithic companies and an ever-encroaching federal government,
and the ever-insidious "Intellectual Property" gestapo.

From where I stand, this is where Plan 9 belongs. This is what it ought to be
doing, and where it ought to be going.

I hope I have not offended anyone, please do not be too harsh on me if
you disagree.

Re: [9fans] freedom (was Re: Compiling 9atom kernel)

[Jack Norton]

errno wrote:
> So, what to do?
>
> The Web:
>
> Reject it? (aka "go buy a tablet" )
>
> Reproduce it? (aka "have you looked at webfs?" )
>
> Reuse it? (aka "port webkit")
>
>
> There's no possible way that I'm the only one who has envisioned
> some rendition of the following science-fiction:
>
> * a Plan 9-based platform targeted at the general consumer market
>
> ...   * Stuff * ....
> I don't want google and facebook and flicker et. al. owning my data; I
> don't want to make intel and dell rich with their overpowered machines
> and processors so I can run ever-bloating os and software; I don't want to
> maintain a collection of various ad-hoc essentially autistic (please excuse
> the term) computers in my household. I want to be able to access my
> private, personal computing environment from anywhere with an internet
> connection via my portable thin client. I want to be able to easily share
> my data and resources within a trusted circle. I want all communications
> to innately and transparently run over an ssl encrypted channel at all
> times.
>
> A radically distributed internet where power and control is put back into
> the hands of individuals. I'm tired of centralized gilded cages and
> hierarchical client server models formed and shaped mostly for the benefit
> of a few monolithic companies and an ever-encroaching federal government,
> and the ever-insidious "Intellectual Property" gestapo.
>
> From where I stand, this is where Plan 9 belongs. This is what it ought to be
> doing, and where it ought to be going.
>
> I hope I have not offended anyone, please do not be too harsh on me if
> you disagree.
>
>
>
>

You've got some misplaced idealism.  Plan 9 isn't needed for any of
this.  In fact you could probably leverage some existing
frameworks/api's and whatnot on a linux machine to do this in a matter
of days for cheaper (hours even?).  All you'd need is a dash of
pragmatism.

Remember your comment on how Acme/rio et al don't really interest you
but 9p/per-process ns et al did?  You can kinda do that in linux.  If
you want to create a product on that scale yourself, linux, for all its
faults, will get you a time-to-market that isn't a pipe dream.  You just
have to leverage many unsightly 'technologies'.

Plan 9 to me is a playground to have something clean and unencumbered by
the world. There is a certain zen to saying "well I don't really think
that is necessary" and to forgo a "hop on the bandwagon" or "me too!"
existence.

In the end though, the list will eventually say it: start hammering out
some code and we'll see what you come up with.  Proof in the pudding.

Good luck,
Jack

Re: [9fans] freedom (was Re: Compiling 9atom kernel)

[errno]

On Friday, May 06, 2011 09:29:33 AM Jack Norton wrote:
> You've got some misplaced idealism.
>

Yeah you're probably right.

> In the end though, the list will eventually say it: start hammering out
> some code and we'll see what you come up with.  Proof in the pudding.
>

Truth.

> errno wrote:
> > From where I stand, this is where Plan 9 belongs. This is what it ought
> > to be doing, and where it ought to be going.
>

And that comment was particularly lame - I'm in no position to
assert what plan 9 "ought" to be doing.

Sorry for that, got carried away.

Re: [9fans] freedom (was Re: Compiling 9atom kernel)

[errno]

On Friday, May 06, 2011 09:07:07 AM errno wrote:
> * said unit can comfortably support ~10 simultaneous users, each using
> super-cheap thin-clients at ~$200 dollars per unit
>

Make that ~$25 dollars per unit:

On Friday, May 06, 2011 03:15:46 PM Gorka Guardiola wrote:
> http://www.raspberrypi.org/

Well, it seems to lack ethernet/wifi; so, maybe more like ~$55.

:)

Re: [9fans] freedom (was Re: Compiling 9atom kernel)

[Lucio De Re]

On Fri, May 06, 2011 at 09:07:07AM -0700, errno wrote:
> > But you're stuck, aren't you?  As soon as, say, a browser is developed for
> > Plan 9 (assuming that someone could afford the resources), the standards
> > will change and the browser will need major surgery.  Who's going to
> > invest in that?  Basically, the mover and shakers are precisely the
> > people who don't want Plan 9 (or anything like it) to be a success story.
> > They are winning.
>
> I concur, and I think this is a generally sound summary of the situation. And
> highly astute, with regards to your comment concerning certain movers and
> shakers.  Plan 9 has mind-numbing potential of being a bonafide "disruptive
> technology", if the cat ever got outta the bag. I'm convinced that the web is
> the key.
>
Thank you for the complement and, for that matter, giving me the
opportunity to think that possibility through in the first place.
Not that I think it's a conspiracy theory thing, as much as the "movers
and shakers" know what they want and make sure that the public looks
nowhere else.  I long ago decided that Microsoft Windows was a religious
institution, if not a religion and I think more players (Steve Jobs and
my friend Mark Shuttleworth, plus a few hardware suppliers) have also,
intentionally or unwittingly, gotten into the game.

> html + css + javascript over http through ssl is able to adequately satisfy
> ~80% of the general public's computing needs and wants. (I pulled that
> "80%" figure out of my ass, but I doubt I'm all too far from the mark)
>
> So, what to do?
>
Look outside the box?  Preach a different Gospel?  Wait for the Chinese to
provide a new perspective?  More than anything else, we need to eradicate
the belief that a single device needs to be the tool of choice for all
possible uses.  We use mobile phones as cameras, computers as hi-fi
systems, heaven only knows how soon we'll be using the microwave oven
doors as visual panels to monitor the house heating arrangements.

> The Web:
>
> Reject it? (aka "go buy a tablet" )
>
I would think that a hardware device like the tablets (has anybody
conclusively established why something MS could not successfully market
has found such a ready audience when supplied by Apple?  Is it the UI
as one might conclude from an earlier post?).

> Reproduce it? (aka "have you looked at webfs?" )
>
I think the web is overrated, and that it requires the type of re-analysis
that Plan 9 would force upon it: treat it as a Unix directory hierarchy
(in other words, redesign HTTP as a 9P "application"), separate HTML
rendering from the transport and the Hypertext character of the documents
(they are orthogonal and accidentally, incorrectly, tightly coupled),
use ASN.1 rather than XML as the data representation and scrap the
inanity of CSS or at minimum come up with a useful standard that does
not include the (fake) ability of users to edit it as text (this results
in damage instead of repairs).

> Reuse it? (aka "port webkit")
>
No, it is broken beyond repair, it will infect Plan 9.

>
> There's no possible way that I'm the only one who has envisioned
> some rendition of the following science-fiction:
>
> * a Plan 9-based platform targeted at the general consumer market
>
Build a hardware device, make it just a web renderer.  Build it in
huge quantities and make sure everyone has one: in each car seat, in
aeroplanes, in the microwave door, in the outside door to the house,
in the garage door, at each bus stop, at traffic lights, you name it...

Freeze the standard or slow down its cancerous growth to a practical,
human manageable speed.

> * this platform offers html + css + javascript (aka "the web") as the
> primary front-end ui
>
And a keyboard or better.

I need some time to address the rest of your posting.

++L

Re: [9fans] freedom (was Re: Compiling 9atom kernel)

[Daniel Lyons]

On May 6, 2011, at 11:01 PM, Lucio De Re wrote:

> has anybody
> conclusively established why something MS could not successfully market
> has found such a ready audience when supplied by Apple?  Is it the UI
> as one might conclude from an earlier post?


The stylus, maybe? http://www.tuaw.com/files/stevesings.mp3

My pet theory is that it's the same reason people don't buy paper tablets that weigh 5+ lbs and have with built-in typewriters. Of course, you can't discount the possibility that there's a difference between a car and a horseless carriage.

— 
Daniel Lyons

Re: [9fans] freedom (was Re: Compiling 9atom kernel)

[Steve Simon]

Plan9 is my primary desktop and has been for years.

I use vnc onto a windows box to browse the web, it annoys me
but I live with it.

I think I have said this before but in case I missed anyone my preferred
solution wold be to build firefox / or dillo or the like on linux, with a backend
library for plany /dev/draw /dev/mouse /dev/kbd access. 

This library is built on linux, compiled under gcc, it just happens to access
devices that only exist when it is run under linuxemu.

This would mean we get the advantage of not having to maintain a port of firefox,
we just use the latest linux binary but run it with a plan9-specific backend
shared library.

This would also have the advantage thet firefox would work as a first class citizen
on plan9, saving files would save them to directories on plan9, we could even support
some small tweeks like $home/lib/firefox/ rather than $home/.firefox/.

Over time we could even replace some bits of glibc, e.g. gethostbyname() to use
/net/dns rather than implementing its own resolver etc; This is bits of the APE
library compiled on linux.

Wy 2¢ worth, and no I don't have the time, I'm just dreaming

-Steve

Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames

[errno]

On Thursday, May 05, 2011 09:35:15 PM ron minnich wrote:
> The reason I asked if errno had looked at webfs was that he can do the
> standard thing (port some C++/Python Library From Hell to Plan 9)
>

The above described standard thing is more in line with my capabilities.

Porting clang is well beyond me though, even at my most optimistic; so
I've decided to dedicate time toward looking more closely into porting
the netsurf libs for css, html and dom; and mozilla's spidermonkey - as
they are further along than webfs/abaco ("further along", meaning
seemingly more active and current), and I can focus simply on a port,
rather than green-field design and development from scratch.

In other words, I think I can manage to eventually port small ad-hoc
stuff; and then slowly "bake" it closer and closer to something that
is more and more "9'ish".

Although I think I understand that the prevailing custom here on 9fans
is to scorn most software written by and for the unwashed masses - or
for the general consumer industry - I'm not so convinced that a reasonable
compromise can't exist to fulfill the needs of a class of user who exist a
little higher up the stack than, say, low-level systems programmers working
on specialist projects within industrial or academic research and development
facilities.

> or do a much more interesting thing, which is look at stuff like abaco
> and webfs, and learn some lessons, and build something that is faster,
> better, and cheaper.
>

It's more interesting, yes - but I fear also far, far less likely for me to
pull off; no one else has managed to pull it off yet, there's no way I can.

(Like I said before: I write backend business logic for web-based applications
in java/groovy and perl and shell, along w/ some db and network administration
etc. on linux; my skills are humble, but serviceable for what I do for a
living .... not to give you my life story or anything... heheh)

In other words, I'm fully cognizant of the fact that I do not have the
necessary pre-requisite experience to build a better mouse trap.

> This is a research OS, not a Windows replacement.
> There's a reason to use it. You want a great desktop experience that
> is familiar, get an ipad.
>

Aww... man.

Do you not think it's possible or worthwhile to have a great(er) desktop
(or consumer-oriented embedded device) experience built atop Plan 9?

After a few months of reading and learning and actual hands-on
experience, I've found that rio and acme and mk and 8c ,etc., are
far less interesting than union directories, per-process namespaces,
9p and intrinsic, ubiquitous distributed computing - that's where I
personally think the action is at.

I don't care what editor or compiler someone uses; but the idea of cpu'ing
from a smartphone to run heavy-weight processes (for just one example)
gets the geek in me pretty excited with possibility.

Or the idea of a home network where I have one cpu/auth server, one file
server and a number of super cheap thin-clients providing a modern
web interface and shared data for friends, guests and family.

I'm tired of maintaining everyone's computers in my house on an ad-hoc
basis; and I think I could deploy a higher performing, more maintainable,
but overall cheaper network with Plan 9. But I can hardly expect visitors
and family to run acme and abaco.


Cheers

Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames

[ron minnich]

Look at the 2d tiling of "tabs" in abaco and tell me it's not pretty neat :-)

In fact I way prefer abaco layout to every other browser I've used.

ron

Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames

[erik quanstrom]

> In other words, I think I can manage to eventually port small ad-hoc
> stuff; and then slowly "bake" it closer and closer to something that
> is more and more "9'ish".

i hope that works for you.  unfortunately, i think that process
will be a lot like making a pig into a supermodel by starting with
the lipstick.

> > This is a research OS, not a Windows replacement.
> > There's a reason to use it. You want a great desktop experience that
> > is familiar, get an ipad.
> >
>
> Aww... man.
>
> Do you not think it's possible or worthwhile to have a great(er) desktop
> (or consumer-oriented embedded device) experience built atop Plan 9?

i'm not 100% sure what the op ment.  but one way one could
read it is that plan 9 is for research, it doesn't need to be usable.
i don't think that was the point, and i wouldn't sign up for that
intpretation.

the way i would read that is that since we value clean ideas and
orthogonal design more than polish, you get a clean and malleable
os, but you don't get this for free.  it's not that easy to port stuff
to plan 9, and it's hard to get folks interested in certain boil-the-
oceans projects like building a full html 5 web browser.

- erik

Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames

[errno]

On Friday, May 06, 2011 05:59:25 AM erik quanstrom wrote:
> > In other words, I think I can manage to eventually port small ad-hoc
> > stuff; and then slowly "bake" it closer and closer to something that
> > is more and more "9'ish".
>
> i hope that works for you.  unfortunately, i think that process
> will be a lot like making a pig into a supermodel by starting with
> the lipstick.
>

I'm certain you're right.  But it's a concrete and approachable starting
place for me, that corresponds well to my _current_ level of experience
and ability with plan 9. I expect that after a certain point, I would ditch it
and start fresh with the new insights and wisdom gained from the initial
attempt.

You may disagree with such an approach, but based from what I know
of my own self, it's the approach that is most likely to eventually produce
some measure of something-more-than-nothing.

> > > This is a research OS, not a Windows replacement.
> > > There's a reason to use it. You want a great desktop experience that
> > > is familiar, get an ipad.
> >
<snip>
> the way i would read that is that since we value clean ideas and
> orthogonal design more than polish, you get a clean and malleable
> os, but you don't get this for free.  it's not that easy to port stuff
> to plan 9, and it's hard to get folks interested in certain boil-the-
> oceans projects like building a full html 5 web browser.
>

Acknowledged, and understood.

Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames

[erik quanstrom]

> I'm certain you're right.  But it's a concrete and approachable starting
> place for me, that corresponds well to my _current_ level of experience
> and ability with plan 9. I expect that after a certain point, I would ditch it
> and start fresh with the new insights and wisdom gained from the initial
> attempt.
>
> You may disagree with such an approach, but based from what I know
> of my own self, it's the approach that is most likely to eventually produce
> some measure of something-more-than-nothing.

i don't disagree with that approach, i was just pointing out one its
fundamental properties.

- erik

Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames

[Comeau At9Fans]

[-- Attachment #1: Type: text/plain, Size: 1695 bytes --]

On Fri, May 6, 2011 at 8:59 AM, erik quanstrom <quanstro@quanstro.net>
 wrote:

> > Do you not think it's possible or worthwhile to have a great(er) desktop
> > (or consumer-oriented embedded device) experience built atop Plan 9?
>
> i'm not 100% sure what the op ment.  but one way one could
> read it is that plan 9 is for research, it doesn't need to be usable.
> i don't think that was the point, and i wouldn't sign up for that
> intpretation.
>
> the way i would read that is that since we value clean ideas and
> orthogonal design more than polish, you get a clean and malleable
> os, but you don't get this for free.  it's not that easy to port stuff
> to plan 9, and it's hard to get folks interested in certain boil-the-
> oceans projects like building a full html 5 web browser.
>

Let's say for argument's sake that errno pulls this off.  Let's say he
manages to get something like FireFox working on Plan 9.  Let's say that the
executable is fully functional (don't know if that's possible but let's
assume it is).  How does this change things literally, conceptually and
philosophically?   Consider this question across the board, for instance,
can Plan 9 handle it (whatever that means)?  How does it change Plan 9's
future?  What I'm getting at is that I'm hearing things about it being a
research OS, so what would it mean for a research OS to have a full fledged
browser available for it?

--
Greg Comeau / 4.3.10.1 with C++0xisms now in beta!
Comeau C/C++ ONLINE ==>     http://www.comeaucomputing.com/tryitout
World Class Compilers:  Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

[-- Attachment #2: Type: text/html, Size: 2298 bytes --]

Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames

[andrey mirtchovski]

> How does this change things literally, conceptually and
> philosophically?

If I can have plan9 as my daily desktop machine I'll be using a lot
more of it, which means there'll be a few things that will annoy me
and a few things that I can fix. I'll be able to dedicate more of my
'free time' towards plan9 and maybe write more programs for it,
especially with an easier-to-write language like Go available. With
more code written in plan9 I'd have more reason to have a server or
two running it in the data centre, which may enable me to share some
resources with other people running plan9.

All of the above isn't wishful thinking, it actually happened several
times in the past decade at different locations. plan9.ucalgary.ca was
a great place to share resources for canadians and at one point ran
the biggest plan9 cpu server (8-single-core cpus in 2003). Lots of
people had free accounts on it to "try out stuff". Elsewhere, a server
in Japan had amassed the largest collection of 9fans, similarly, other
9grid machines popped up in many places in Europe and the US.

Unfortunately there are never enough people sticking with plan9 long
enough. Eventually i couldn't stick with it either. I stopped actively
coding for plan9 when it stopped being my default desktop in 2006-7.
Now if I need something done in Plan9 there are quite a few capable
replacements like 9vx and p9p, but I would go back to running native
plan9 if I could because it's a much calmer place to work.

Ironically, I wish to go back to plan9 because the internet is too
distracting, yet I can't do it because there's no proper web browser
for it :)

cheers: andrey

Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames

[errno]

Quick attempt at damage control, hope it's not too late:

On Friday, May 06, 2011 03:32:26 PM Comeau At9Fans wrote:
> [...] errno pulls this off. [...] something like FireFox working on Plan 9.
> Let's say that the executable is fully functional
>

People may take it you literally mean: Firefox-on-Plan-9.  nonono I tried
real hard to avoid that misunderstanding.

And, "fully functional" :=

css 2.1/3, ecmascript 3rd/5th (w/ dom), html 4.1/5, ssl/tls

On Sunday, May 01, 2011 09:09:06 PM errno wrote:
> (and, forget about the "browser" part of the "web" for now - I think
> web _browsers_ suck worse than the web itself - I'm just concerned
> with the web _engine_ for now)

On Sunday, May 01, 2011 06:42:12 PM errno wrote:
> With regards to "web browsers" - the over-generalized kitchen-sync
> applications that supply the cookie management and password
> storing, and bookmarks, and cert management, and home pages,
> and back/forward  buttons and all that shtuff - a decent web engine
> library would facilitate any number and any manner of unique and
> specialized front-ends. The engine is the important part, the
> actual front-ends are expected to just... materialize.

On Friday, April 29, 2011 09:05:39 PM errno wrote:
> (by "web experience", I'm not talking about porting firefox and flash to
> Plan 9 - I'm talking about native or ported libraries for what wikipedia
> refers to as a "web browser engine" or "layout engine"; and by "fully
> functional", I'm talking about something that can score at least an 80%
> or so on the acid2 test.)

Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames

[Comeau At9Fans]

[-- Attachment #1: Type: text/plain, Size: 837 bytes --]

On Fri, May 6, 2011 at 7:18 PM, errno <errno@cox.net> wrote:

>
> Quick attempt at damage control, hope it's not too late:
>
> On Friday, May 06, 2011 03:32:26 PM Comeau At9Fans wrote:
> > [...] errno pulls this off. [...] something like FireFox working on Plan
> 9.
> > Let's say that the executable is fully functional
> >
>
> People may take it you literally mean: Firefox-on-Plan-9.  nonono I tried
> real hard to avoid that misunderstanding.
>

Yes, sorry about that.   I did not mean to imply it literally, just took it
to the next step so to speak....

--
Greg Comeau / 4.3.10.1 with C++0xisms now in beta!
Comeau C/C++ ONLINE ==>     http://www.comeaucomputing.com/tryitout
World Class Compilers:  Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

[-- Attachment #2: Type: text/html, Size: 1253 bytes --]

Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames

[errno]

On Friday, May 06, 2011 03:32:26 PM Comeau At9Fans wrote:
> How does this change things literally, conceptually and philosophically?
> Consider this question across the board, for instance, can Plan 9 handle
> it (whatever that means)?  How does it change Plan 9's future?  What I'm
> getting at is that I'm hearing things about it being a research OS, so what
> would it mean for a research OS to have a full fledged browser available
> for it?
>

A veneer of html + css + javascript over the intrinsically distributed
foundations of Plan 9, would provide the bridge for an entire class of
use-cases currently out of reach:

When friends and family can comfortably use it, for activities other than
data-archival, then I can deploy it for uses beyond my own limited, personal
learning projects. The benefit I intend to receive for this is the freedom to
enjoy Plan 9 more often, while reducing linux dependency, and reducing
overall costs: both in hardware requirements, and in maintenance time/effort.


On Sunday, May 01, 2011 09:09:06 PM errno wrote:
> The idea is to remove the "middle-man".

On Friday, May 06, 2011 12:08:04 AM errno wrote:
> Do you not think it's possible or worthwhile to have a great(er) desktop
> (or consumer-oriented embedded device) experience built atop Plan 9?
>
> Or the idea of a home network where I have one cpu/auth server, one file
> server and a number of super cheap thin-clients providing a modern
> web interface and shared data for friends, guests and family.
>
> I'm tired of maintaining everyone's computers in my house on an ad-hoc
> basis; and I think I could deploy a higher performing, more maintainable,
> but overall cheaper network with Plan 9. But I can hardly expect visitors
> and family to run acme and abaco.

Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames

[Comeau At9Fans]

[-- Attachment #1: Type: text/plain, Size: 1533 bytes --]

On Fri, May 6, 2011 at 7:47 PM, errno <errno@cox.net> wrote:

> On Friday, May 06, 2011 03:32:26 PM Comeau At9Fans wrote:
> > How does this change things literally, conceptually and philosophically?
> > Consider this question across the board, for instance, can Plan 9 handle
> > it (whatever that means)?  How does it change Plan 9's future?  What I'm
> > getting at is that I'm hearing things about it being a research OS, so
> what
> > would it mean for a research OS to have a full fledged browser available
> > for it?
> >
>
> A veneer of html + css + javascript over the intrinsically distributed
> foundations of Plan 9, would provide the bridge for an entire class of
> use-cases currently out of reach:
>
> When friends and family can comfortably use it, for activities other than
> data-archival, then I can deploy it for uses beyond my own limited,
> personal
> learning projects. The benefit I intend to receive for this is the freedom
> to
> enjoy Plan 9 more often, while reducing linux dependency, and reducing
> overall costs: both in hardware requirements, and in maintenance
> time/effort.
> ...
>

How and/or why do you feel it would reduce the hardware requirements of
friends and family?   And especially so versus linux?

--
Greg Comeau / 4.3.10.1 with C++0xisms now in beta!
Comeau C/C++ ONLINE ==>     http://www.comeaucomputing.com/tryitout
World Class Compilers:  Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

[-- Attachment #2: Type: text/html, Size: 2025 bytes --]

Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames

[errno]

On Friday, May 06, 2011 04:56:26 PM Comeau At9Fans wrote:
> On Fri, May 6, 2011 at 7:47 PM, errno <errno@cox.net> wrote:
> > When friends and family can comfortably use it, for activities other
> > than data-archival, then I can deploy it for uses beyond my own limited,
> > personal learning projects. The benefit I intend to receive for this is the
> > freedom to enjoy Plan 9 more often, while reducing linux dependency,
> > and reducing overall costs: both in hardware requirements, and in
> > maintenance time/effort.
>
> How and/or why do you feel it would reduce the hardware requirements of
> friends and family?   And especially so versus linux?
>

The same way a linux terminal server w/ linux thin-clients would reduce
hardware requirements.

"So why not just use a linux terminal server then?"

Because linux lacks the inherent distributed qualities of Plan 9.

Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames

[Lyndon Nerenberg]

> A veneer of html + css + javascript over the intrinsically distributed
> foundations of Plan 9, would provide the bridge for an entire class of
> use-cases currently out of reach:

Speaking in platitudes doesn't make a case. How specifically would
this tie in to 9p? How specifically does it fit into namespaces? Show
us some code fragments. Write some simple file servers to stub out
this veneer you describe.

In the process of doing this you will learn a lot about plan 9. And as
a side effect, you will come to understand why nobody else has gone
down this road.

Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames

[errno]

On Friday, May 06, 2011 05:12:02 PM Lyndon Nerenberg wrote:
> > A veneer of html + css + javascript over the intrinsically distributed
> > foundations of Plan 9, would provide the bridge for an entire class of
>
> > use-cases currently out of reach:
> Speaking in platitudes doesn't make a case. How specifically would
> this tie in to 9p? How specifically does it fit into namespaces?
>

Huh?  ... the same way webfs does?

9p and namespaces is exactly what allows me to transparently access
the cpu/auth/file server from my thin client from which to springboard
my operating environment from any location, and how I'm able to
the processor on the cpu server, and how I'm able to arrange multiple
discrete environments from ad-hoc resources. That shit's intrinsic and
seamless to the plan 9 experience; I don't understand how it's not
immediately obvious how 9p and namespaces tie in and fit into the
whole idea.

Right?  I hope I'm not still missing The Point, 'cuz that would be really
embarrassing by this juncture.  :)

> Show us some code fragments. Write some simple file servers to stub out
> this veneer you describe.
>
> In the process of doing this you will learn a lot about plan 9. And as
> a side effect, you will come to understand why nobody else has gone
> down this road.
>

I have no disagreement.

I don't mind responding as long as people are directing comments
and questions at me though; should I announce that I hereby
extract myself from any further discussion? I don't mind doing
that either, if it means reducing annoyance levels from the list
members. I don't want make a continued annoyance of myself;
it's true that I've got plenty to cognate and work on.

Thankyou

Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames

[erik quanstrom]

> Just compare ratrace to strace some time. Sometimes, if you get some
> initial structure right, you can see 100:1 code shrinkage *and* a
> pretty good result.

phrasing!

- erik

Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames

[smiley]

Anthony Sorace <a@9srv.net> writes:

> because it's a huge amount of work. there's a whole pile of standards and
> pseudo-standards to deal with, the set is ever-growing, the components are
> ever-growing, and there isn't really a good definition of "correct".

Perhaps there's a "Plan 9" way to approach the problem which might
involve a "less-huge" amount of work.

Suppose the functionality of each component of the web browser
architecture were specified with a domain-specific language (DSL).
Take, for example, CSS.  Translate the English human-readable CSS
standards into a CSS DSL.  Then, write a compiler to compile the
constraints specified in the CSS DSL into C code that can be compiled
with 8c.  Then, when the standard is updated, when a special case needs
to be added, or when a bug is found, that info would be added to the CSS
specification written in the CSS DSL.  Recompile to C, compile to
binary, and you're up to date.  That way, the whole specification
doesn't need to be implemented directly in $language, and
updates/modifications don't require additional, tedious, coding.

This approach would require a DSL to be created for each of the
components of the architecture: HTML, CSS, script, DOM; and a compiler
would need to be written to convert each DSL into C.

Now, here's the question: Would an apprach using specifications in
domain-specific languages be easier or harder than porting an existing
engine to 9?

--
+---------------------------------------------------------------+
|E-Mail: smiley@zenzebra.mv.com             PGP key ID: BC549F8B|
|Fingerprint: 9329 DB4A 30F5 6EDA D2BA  3489 DAB7 555A BC54 9F8B|
+---------------------------------------------------------------+

Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames

[Lyndon Nerenberg]

> Perhaps there's a "Plan 9" way to approach the problem which might
> involve a "less-huge" amount of work.

There is nothing "Plan 9" about this.  When a piece of code gets so large
as to be impossible to understand, it's time to throw it out and start
over.

Where we as "engineers" fail is in not making the case that it is cheaper
for the corporate behemoth to re-write rather than extend, embrace, and
bloat.

I can't get started on this right now ...

Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames

[dexen deVries]

On Sunday 01 of May 2011 00:45:48 Lyndon Nerenberg wrote:
> > Perhaps there's a "Plan 9" way to approach the problem which might
> > involve a "less-huge" amount of work.
>
> There is nothing "Plan 9" about this.  When a piece of code gets so large
> as to be impossible to understand, it's time to throw it out and start
> over.
>
> Where we as "engineers" fail is in not making the case that it is cheaper
> for the corporate behemoth to re-write rather than extend, embrace, and
> bloat.
>
> I can't get started on this right now ...


dare we say, ``Greenspun's Tenth Rule''? :D


--
dexen deVries

``One can't proceed from the informal to the formal by formal means.''

Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames

[Greg Comeau]

In article <86y62r9xno.fsf@cmarib.ramside>,  <smiley@zenzebra.mv.com> wrote:
>Anthony Sorace <a@9srv.net> writes:
>> because it's a huge amount of work. there's a whole pile of standards and
>> pseudo-standards to deal with, the set is ever-growing, the components are
>> ever-growing, and there isn't really a good definition of "correct".
>
>Perhaps there's a "Plan 9" way to approach the problem which might
>involve a "less-huge" amount of work.
>
>Suppose the functionality of each component of the web browser
>architecture were specified with a domain-specific language (DSL).
>Take, for example, CSS.  Translate the English human-readable CSS
>standards into a CSS DSL.  Then, write a compiler to compile the
>constraints specified in the CSS DSL into C code that can be compiled
>with 8c.  Then, when the standard is updated, when a special case needs
>to be added, or when a bug is found, that info would be added to the CSS
>specification written in the CSS DSL.  Recompile to C, compile to
>binary, and you're up to date.  That way, the whole specification
>doesn't need to be implemented directly in $language, and
>updates/modifications don't require additional, tedious, coding.
>
>This approach would require a DSL to be created for each of the
>components of the architecture: HTML, CSS, script, DOM; and a compiler
>would need to be written to convert each DSL into C.
>
>Now, here's the question: Would an apprach using specifications in
>domain-specific languages be easier or harder than porting an existing
>engine to 9?

I think the "less huge" characterization probably leaves this as
an unknown with both being enough of a chore that either will no
doubt challenging and challenging in their own rights.  Personally
I don't know know enough about the web to assess it myself though
I do have observations I'll leave at a cursory level that there
does not seem to be a simple solution.

BTW, why is the above a "Plan 9" specific approach?
--
Greg Comeau / 4.3.10.1 with C++0xisms now in beta!
Comeau C/C++ ONLINE ==>     http://www.comeaucomputing.com/tryitout
World Class Compilers:  Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames

[andrey mirtchovski]

perhaps we should revisit the links port. i see they have a 2.3pre2
version released couple of weeks ago so it's not stale:

http://links.twibright.com/download/

that would be minimal effort compared to everything else.

Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames

[Gorka Guardiola]

[-- Attachment #1: Type: text/plain, Size: 1297 bytes --]

On Thu, May 5, 2011 at 2:54 PM, andrey mirtchovski <mirtchovski@gmail.com>wrote:

> perhaps we should revisit the links port. i see they have a 2.3pre2
> version released couple of weeks ago so it's not stale:
>
> http://links.twibright.com/download/
>
> that would be minimal effort compared to everything else.
>
>
abaco is much more functional and stable than the (actual) links port
never was, we used it for a while, but abaco has completely replaced
links now. The binary is much smaller too and
it supports https with factotum, uses webfs, etc.

I think it only really needs CSS and javascript to be functional enough (and
plugins, but
that is another matter).

Any browser anyone writes/ports needs javascript and
that is (mostly) independant of anything else and needed, so putting some
effort there is probably good whatever the path taken. Spidermonkey
javascript implementation is in C and highly doable though very very boring.

With that, CSS and
some small work (like chaging the fonts for input forms)
abaco could be made into a simple, powerful well
integrated (pre html 5, but that is another different level of complexity)
browser for Plan 9. This are my two cents,
but I don't have time for that and probably won't, so I´ll shut up now :-).

G.

[-- Attachment #2: Type: text/html, Size: 1705 bytes --]

Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames

[Iruatã Souza]

On Thu, May 5, 2011 at 5:30 PM, Gorka Guardiola <paurea@gmail.com> wrote:
> Any browser anyone writes/ports needs javascript and
> that is (mostly) independant of anything else and needed, so putting some
> effort there is probably good whatever the path taken. Spidermonkey
> javascript implementation is in C and highly doable though very very boring.

I remember there was a Spidermonkey port somewhere in contrib.

iru

Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames

[Skip Tavakkolian]

it is (or was) in fgb's contrib. he ported it over back in 2006.

cpue% js
js> help()
JavaScript-C 1.5 pre-release 6a 2004-06-09

-Skip

On Thu, May 5, 2011 at 2:22 PM, Iruatã Souza <iru.muzgo@gmail.com> wrote:
> On Thu, May 5, 2011 at 5:30 PM, Gorka Guardiola <paurea@gmail.com> wrote:
>> Any browser anyone writes/ports needs javascript and
>> that is (mostly) independant of anything else and needed, so putting some
>> effort there is probably good whatever the path taken. Spidermonkey
>> javascript implementation is in C and highly doable though very very boring.
>
> I remember there was a Spidermonkey port somewhere in contrib.
>
> iru
>
>

Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames

[Gorka Guardiola]

[-- Attachment #1: Type: text/plain, Size: 287 bytes --]

On Fri, May 6, 2011 at 7:20 AM, Skip Tavakkolian <skip.tavakkolian@gmail.com
> wrote:

> it is (or was) in fgb's contrib. he ported it over back in 2006.
>
> cpue% js
> js> help()
> JavaScript-C 1.5 pre-release 6a 2004-06-09
>

So it is even better, than I thought :-).

G.

[-- Attachment #2: Type: text/html, Size: 595 bytes --]

Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames

[errno]

On Thursday, May 05, 2011 10:20:47 PM Skip Tavakkolian wrote:
> it is (or was) in fgb's contrib. he ported it over back in 2006.
>
> cpue% js
> js> help()
> JavaScript-C 1.5 pre-release 6a 2004-06-09
>

Right on.

One step closer to web domination from a plan 9 platform.

(:


Thankyou kindly for the heads-up.

Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames

[Greg Comeau]

In article <201104292105.39780.errno@cox.net>, errno <errno@cox.net> wrote:
>On Friday, April 29, 2011 05:21:12 AM Jacob Todd wrote:
>> Seeing that plan 9 doesn't have a c++ compiler, i doubt it will ever be
>> ported.
>
>But APE has c++  (old version of gcc though).

That is incorrect, it was attempted but ran into issues.
--
Greg Comeau / 4.3.10.1 with C++0xisms now in beta!
Comeau C/C++ ONLINE ==>     http://www.comeaucomputing.com/tryitout
World Class Compilers:  Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames

[Greg Comeau]

In article <BANLkTinVErOPxQtOB3ObJHYWtngu1XQ0-A@mail.gmail.com>,
Jacob Todd <jaketodd422@gmail.com> wrote:
>On Apr 29, 2011 6:21 AM, "errno" <errno@cox.net> wrote:
>> On Friday, April 29, 2011 02:18:26 AM Charles Forsyth wrote:
>> > > complaining is because you _need_ linux... to furnish all the things
>> > > you can't do with plan 9 - either personally, or within your
>> > > organization.
>> >
>> > it's true, but at least i haven't got to run either Windows or MacOS.
>> > the underlying problem is that the things we might simply import (mainly
>> > browser) can't simply be imported. it's not just us: you might have
>> > noticed that Google's Picasaweb runs under Linux by including a copy of
>> > Wine as part of its iceberg. also google in any alternative-os list you
>> > like for a discussion of the hopelessness of ./configure
>>
>Afaik, google has been distributing picasa with wine for years, it doesn't
>act like an intermediate solution, it seems told be their solution.
>
>> Icebergs are justified when used as a temporary stop-gap until a native
>> solution is devised and implemented.  Thus, a webkit environment ("AWE")
>> seems like a pretty decent compromise until Plan 9 is finally able to
>> treat the wild wild web like a first-class citizen.
>
>Seeing that plan 9 doesn't have a c++ compiler, i doubt it will ever be
>ported.

Let's assume that's so and will always be so.  Here, we're always
"switching" between mostly MacOS and Windows (used to be LINUX
and Windows).  It's annoying, and yes it often means icebergs,
but we find we'd rather have/take them than nothing, even in the face
of it "being imperfect" or less optimal compromises.  And often,
it's even the thing that makes sense, since, it might just mean
morphing an iceberg (or whatever it is) to another iceberg
(or whatever it is).
--
Greg Comeau / 4.3.10.1 with C++0xisms now in beta!
Comeau C/C++ ONLINE ==>     http://www.comeaucomputing.com/tryitout
World Class Compilers:  Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames

[erik quanstrom]

> But then again, why would anyone want a fully functional web experience
> on Plan 9 - what would be the purpose?  Apparently nobody does, otherwise
> it'd be implemented already.

that's not logical.

and from another post

> Until then, complaining about de-facto linux bloat is a lot like complaining
> about death and taxes. Boring and disingenuous.

this is also illogical.  i see nothing intellectually dishonest about
a complaining about x being too y, and using z whenever possible.
why can't x="motor vehicles", y="use too much gas", z="a bicycle".
clearly one can't cycle to the west coast for a business trip.  that doesn't
mean you don't want to, and there's nothing dishonest about that
desire.

i don't mind a good lively discussion, but these comments seem
a bit trollish to me.  why don't we get back on track?

- erik

Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames

[Iruatã Souza]

On Fri, Apr 29, 2011 at 7:19 AM, errno <errno@cox.net> wrote:
> so I'm just speculating.)
>

really? no one has noticed.

Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames

[Bakul Shah]

On Thu, 28 Apr 2011 19:00:49 PDT errno <errno@cox.net>  wrote:
>
> Though I don't understand why folks around here complain about
> "linux" so often and so vehemently, when the only reason why you're
> complaining is because you _need_ linux... to furnish all the things
> you can't do with plan 9 - either personally, or within your organization.

Nobody *needs* linux. That is like saying people need
McDonald's. What people need is to *eat*.  Not the same thing.
If they are forced to eat at McDonald's when they know better
alternatives exist, they are going to complain. Bitterly.

Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames

[Anthony Sorace]

[-- Attachment #1: Type: text/plain, Size: 392 bytes --]

On Apr 28, 2011, at 3:29 PM, dexen deVries wrote:

> the current hacker-unfriendlines of linux (a.k.a. `user
> friendlines') is the price paid for vide driver support.

perhaps in some vague philosophical terms, but certainly
that isn't any sort of actual engineering trade-off. you also
seem to be positing that linux scores highly on "user
friendly" measures, which seems wrong.


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 210 bytes --]

Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames

[Balwinder S Dheeman]

On 04/29/11 00:21, Brian L. Stuart wrote:
> Ron wrote:
>> andrey mirtchovski
>> <mirtchovski@gmail.com>
>> wrote:
>>>> This is great!
>>>
>>> it is, isn't it? 6 seconds kernel compile, 15 seconds
>> turnaround time
>>> when developing anything in the kernel (with PXE
>> boot). beat that,
>>> modern operating systems :)
>>
>> yes, I had to help config and build a linux kernel
>> yesterday; every
>> time I see it I just want to claw my eyes out. And it gets
>> worse every
>> month ...
>
> Life is too short to configure and compile Linux and
> GNU software.

And they people (the developers, distributions as well as users),
however, are doing it since 1991 :P

--
Balwinder S "bdheeman" Dheeman
(http://werc.homelinux.net/contact/)

Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames

[erik quanstrom]

> > Life is too short to configure and compile Linux and
> > GNU software.
>
> And they people (the developers, distributions as well as users),
> however, are doing it since 1991 :P

so in conclusion, perhaps one of the following is true
- linux has gotten slowly worse over the years,
- some people don't value their time,
- not everyone appreciates that there are alternatives.

- erik

Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames

[erik quanstrom]

On Thu Apr 28 13:25:13 EDT 2011, smiley@zenzebra.mv.com wrote:
> erik quanstrom <quanstro@labs.coraid.com> writes:
>
> Wow, you know, as a Gentoo user, I'm amazed AMAZED amazed amazed AMAZED
> amazed how fast Plan 9 can compile a kernel or libc.  Compiling glibc
> (on Linux) usually takes over half a day.  Compiling a kernel generally
> takes a couple of hours.  This is great!

i pity andrey for his poor setup.  usually a kernel compile
takes < 2s here, and with /dev/reboot, i can be starting a
new kernel within 100ms.

>
> > how about
> >
> > 	cd /sys/src/libc; mk && mk clean
>
> Just tried it.  Same error.
>

; 9diff mkfile
/n/sources/plan9//sys/src/libc/386/mkfile:23,28 - mkfile:23,29
  	strcpy.s\
  	strlen.s\
  	tas.s\
+ 	trace.s\
  	vlop.s\


- erik

Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames

[smiley]

erik quanstrom <quanstro@labs.coraid.com> writes:

> ; 9diff mkfile
> /n/sources/plan9//sys/src/libc/386/mkfile:23,28 - mkfile:23,29
>   	strcpy.s\
>   	strlen.s\
>   	tas.s\
> + 	trace.s\
>   	vlop.s\

Oh, of course!  If it isn't assembled, the loader will never find the
symbols.  :) That addition enabled libc to compile successfully.  The
subsequent kernel compile succeeded as well.  After a reboot, my file
system is now able to store files with spaces in their names.  Yeay!

Much thanks!

(Interestingly, the 9pcf.gz produced was about 7KB smaller than the one
you gave me.  I'm guessing that there's some additional stuff in your
9pcf that's not in mine, but it seems to be working fine.)

--
+---------------------------------------------------------------+
|E-Mail: smiley@zenzebra.mv.com             PGP key ID: BC549F8B|
|Fingerprint: 9329 DB4A 30F5 6EDA D2BA  3489 DAB7 555A BC54 9F8B|
+---------------------------------------------------------------+

Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames

[erik quanstrom]

> (Interestingly, the 9pcf.gz produced was about 7KB smaller than the one
> you gave me.  I'm guessing that there's some additional stuff in your
> 9pcf that's not in mine, but it seems to be working fine.)

you're using 16-bit runes, and the standard pre-unicode 3.0 tables,
which are smaller.

- erik

Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames

[Charles Forsyth]

>Compiling glibc (on Linux) usually takes over half a day.

you're not counting iterations where something goes wrong, as it always does for me.

Re: [9fans] spaces in filenames

[presotto]

[-- Attachment #1: Type: text/plain, Size: 155 bytes --]

YOu can't read and write from user level a file descriptor that has
already been mounted.  Otherwise, you could side step authentication
to file servers.

[-- Attachment #2: Type: message/rfc822, Size: 2809 bytes --]

From: Axel Belinfante <Axel.Belinfante@cs.utwente.nl>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] spaces in filenames
Date: Mon, 03 Jun 2002 12:06:35 +0200
Message-ID: <200206031006.g53A6ZI15198@zamenhof.cs.utwente.nl>

> > I can bypass the kernel easily enough:
>
> man 9pcon

cpu% aux/9pcon /srv/dns
read9pmsg from server: inappropriate use of fd
cpu%

What does that error message mean?
Did I invoke 9pcon in the wrong way?

Axel.

Re: [9fans] spaces in filenames

[Russ Cox]

> I can bypass the kernel easily enough:

man 9pcon

Re: [9fans] spaces in filenames

[William Josephson]

On Sat, Jun 01, 2002 at 06:17:09PM -0400, Russ Cox wrote:
> > I can bypass the kernel easily enough:
>
> man 9pcon

I'm aware of it, but last I checked it didn't
compile on FreeBSD :-p

Re: [9fans] spaces in filenames

[Axel Belinfante]

> > I can bypass the kernel easily enough:
>
> man 9pcon

cpu% aux/9pcon /srv/dns
read9pmsg from server: inappropriate use of fd
cpu%

What does that error message mean?
Did I invoke 9pcon in the wrong way?

Axel.

Re: [9fans] spaces in filenames

[Russ Cox]

> Sorry, I should have said: this was on a 3rd edition kfs.

The bug is still there in the 4e kfs binary I am running.
I am just very confused as to why.

Russ

Re: [9fans] spaces in filenames

[Richard Miller]

[-- Attachment #1: Type: text/plain, Size: 217 bytes --]

> Anyhow, you didn't misunderstand the syntax.
> That should have worked.  That's how the
> install moves your old file system into /3e.

Sorry, I should have said: this was on a 3rd edition kfs.

-- Richard


[-- Attachment #2: Type: message/rfc822, Size: 2183 bytes --]

From: "Russ Cox" <rsc@plan9.bell-labs.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] spaces in filenames
Date: Sat, 1 Jun 2002 10:01:43 -0400
Message-ID: <ecb4d092e6486a09039ef6b51f86ee42@plan9.bell-labs.com>

> I got myself into trouble recently by misunderstanding the syntax
> of the kfs 'rename' command.  If you do something like
>
>   disk/kfscmd 'rename /tmp/xxx /tmp/yyy'
>
> you end up with a file in /tmp with slashes in its name.  Exercise
> for the reader: how do you get rid of it?

That's one of the first Plan 9 mistakes I ever made.
I killed off the partition and started afresh.  (Not the right answer.)

Anyhow, you didn't misunderstand the syntax.
That should have worked.  That's how the
install moves your old file system into /3e.
The case where src and dst are in same
directory must use the wrong name.

Russ

Re: [9fans] spaces in filenames

[Russ Cox]

> Anyhow, you didn't misunderstand the syntax.
> That should have worked.  That's how the
> install moves your old file system into /3e.
> The case where src and dst are in same
> directory must use the wrong name.

I have no idea why this doesn't work.  I'm staring
at the rename code and it really should work.
Unless I misunderstand what nextelem does.

You'll note that

	disk/kfscmd 'rename /tmp/yyy a/b/c/d'

correctly diagnoses the fact that there are slashes
in the new name.  Destinations beginning with /
are supposed to do what you expect.

I'm leaving for a trip soon, but will be online
with reasonable frequency.  If someone else
wants to add the appropriate print, figure out
what's wrong, and send me a fix, I'd be happy to
put it in.

Russ

Re: [9fans] spaces in filenames

[Russ Cox]

> hmm ... disk/kfscmd 'rename /tmp/\/tmp\/yyy yyy'?

you expect far too much from kfs.

Re: [9fans] spaces in filenames

[Russ Cox]

> You should be able to rename it again; maybe you'll need to rename
> it in to another directory if there is a bug.

BZZT!  How do you rename it?  When you pass
the path to kfs or the kernel, it will tokenize
it into

	'tmp' 'xxx' 'tmp' 'yyy'

instead of

	'tmp' 'xxx' '/tmp/yyy'

as is necessary.

Re: [9fans] spaces in filenames

[William Josephson]

On Sat, Jun 01, 2002 at 10:10:18AM -0400, Russ Cox wrote:
> > You should be able to rename it again; maybe you'll need to rename
> > it in to another directory if there is a bug.
>
> BZZT!  How do you rename it?  When you pass
> the path to kfs or the kernel, it will tokenize

Forgot that kfs will parse the path, too.
I can bypass the kernel easily enough: I
wrote a stupid 9p shell after I broke some
names on the fileserver by untarring
something on a 9p2k terminal.  Guess it is
time to do some hacking...

Re: [9fans] spaces in filenames

[Russ Cox]

> I got myself into trouble recently by misunderstanding the syntax
> of the kfs 'rename' command.  If you do something like
>
>   disk/kfscmd 'rename /tmp/xxx /tmp/yyy'
>
> you end up with a file in /tmp with slashes in its name.  Exercise
> for the reader: how do you get rid of it?

That's one of the first Plan 9 mistakes I ever made.
I killed off the partition and started afresh.  (Not the right answer.)

Anyhow, you didn't misunderstand the syntax.
That should have worked.  That's how the
install moves your old file system into /3e.
The case where src and dst are in same
directory must use the wrong name.

Russ

Re: [9fans] spaces in filenames

[Richard Miller]

I got myself into trouble recently by misunderstanding the syntax
of the kfs 'rename' command.  If you do something like

  disk/kfscmd 'rename /tmp/xxx /tmp/yyy'

you end up with a file in /tmp with slashes in its name.  Exercise
for the reader: how do you get rid of it?

-- Richard

Re: [9fans] spaces in filenames

[William Josephson]

On Sat, Jun 01, 2002 at 02:55:47PM +0000, Richard Miller wrote:
> I got myself into trouble recently by misunderstanding the syntax
> of the kfs 'rename' command.  If you do something like
>
>   disk/kfscmd 'rename /tmp/xxx /tmp/yyy'
>
> you end up with a file in /tmp with slashes in its name.  Exercise
> for the reader: how do you get rid of it?

You should be able to rename it again; maybe you'll need to rename
it in to another directory if there is a bug.

Re: [9fans] spaces in filenames

[Sam]

> On Sat, Jun 01, 2002 at 02:55:47PM +0000, Richard Miller wrote:
> I got myself into trouble recently by misunderstanding the syntax
> of the kfs 'rename' command.  If you do something like
>
>   disk/kfscmd 'rename /tmp/xxx /tmp/yyy'
>
> you end up with a file in /tmp with slashes in its name.  Exercise
> for the reader: how do you get rid of it?
>

hmm ... disk/kfscmd 'rename /tmp/\/tmp\/yyy yyy'?

Re: [9fans] spaces in filenames

[Russ Cox]

looks like you pulled in a big one, geoff.
where do you get such great lures?

Re: [9fans] spaces in filenames

[Geoff Collyer]

Okay, you're a communist.  ☺

On Unix, part of the problem is scripts that use $* when they should
use "$@", but the need to quote file names containing spaces
interactively is an on-going nuisance.

If you're going to allow spaces, then why not allow tabs?  They have
traditionally been considered equivalent whitespace, with a few
exceptions (e.g., make, tbl).  I don't see a compelling reason to
allow spaces but not tabs.  And if you allow spaces and tabs, why not
newline, it's whitespace too.  And as long as we're allowing any old
character in file names, why not allow slashes in file name
components?  Sure, we'll have to introduce some ugly hack like having
the kernel understand /this\/is\/all\/one\/component, but by now we're
not afraid of a little quoting, right?  And why discriminate against
NUL?  Shouldn't one be able to have a file name like 'This is a
history of the \0, \\ and \/ characters in computing, © 2002 <a
href="http:\/\/pedant.com\/peter.jpg">Peter Pedant<\/a>', where \0
represents a NUL byte?

We could also adopt another Mac OS tradition, case-insensitive file
names.  Pretty soon our file names will be as ungodly a stew as
anything ever parsed by MVS or VMS.

Re: [9fans] spaces in filenames

[Michael Baldwin]

> On Unix, part of the problem is scripts that use $* when they should
> use "$@"

yeah, so fix them, if it's so easy.  are there lots of these around?  i
haven't noticed.

> but the need to quote file names containing spaces interactively is an
> on-going nuisance.

i guess if you think 'quoting' is a nuisance.  yes, you have to quote
spaces in shell args.  i also have to quote '=' in rc args, and i have
to quote ( ) { } * ? and a bunch of other characters.  so what?

> If you're going to allow spaces, then why not allow tabs? ... why not
> newline ... why discriminate against NUL ...

because filenames are supposed to be printable "labels" for things.
tabs are control characters to adjust the "carriage", like CR and NL
are.  NUL is a control character.  space is just a space, and is thought
of as printable.  putting spaces in labels is not a radical idea.  ever
label a paper folder "Mom's recipes"?  i don't feel obligated to put an
underscore in there instead.  and let me tell you, her stuffed peppers
are to die for.

and i've already said it is very useful to have characters that are
guaranteed to be useful as separators.  slashes are used for pathname
element separation, and for the same reason, it seems a good idea to
have a character that always works as an element separator.

so stop confusing the issue.  i'm talking about space.  JUST SPACE.  not
tab, newline, nul, or slash.  i have ALREADY given my reasons for not
allowing those (they are non-printable, and it is good to have reliable
separators).  this is about SPACE ONLY.  the only reason you've given to
hate spaces is shell sloppiness.  we even have the nice new quoted
string functions if you want to use them.

> We could also adopt another Mac OS tradition, case-insensitive file
> names.

this is more questionable.  but in the case of inferno, which has to
live on top of these other systems (windoze does this too), one cannot
simply ignore it.  "mv A a" on inferno used to delete your poor file "A"
instead of move it.  oops.  and i notice that the shell(s) in mac os x
are case-sensitive when using glob matching.

> Pretty soon our file names will be as ungodly a stew as anything ever
> parsed by MVS or VMS.

oh please.  allowing the use of space somehow makes filenames a stew?
give me a break.

[9fans] spaces in filenames

[Michael Baldwin]

really, what is the big deal with spaces in filenames?  yeah, there are
some file formats here and there, and some shell files that maybe aren't
so careful, so it's not a cakewalk, but it isn't some Big Huge Problem.
using shells like rc that manage lists of string works quite well; if
you need a list of files use "ls" not "echo"; if you really want to use
the output of a command with backquote, set ifs to \t\n.

geoff talks about how maddening it is to use filenames with spaces on
mac os x.  i use mac os x too, and have lots of files with spaces, and i
use quotes on the occasion that i refer to them in the shell.  i haven't
noticed any "problem" that would cause me to go mad, and everything
works just fine from the shell and the gui for me.  i send spacey
filenames to web sites, attach/detach them from mail messages, move them
about, and things work.  what am i missing?  now that i can use spaces,
i kinda like using space instead of _ in names -- easier to type and
easier to read.  why banish the poor lowly space character?  so call me
a communist for my radical views.

the only problem i've had with spaces is getting to spacey files on
windows and unix from plan 9 and inferno.  i took out the space
restriction in inferno and things work swimmingly.  yeah, i know there
are gotchas here and there, but they really haven't been an issue.  i
much prefer the ability to manipulate files to the odd gotcha.

oh, the non-printable range also includes 7F, so it's really 00-1F and
7F-9F that are restricted.  it does seem to be a Good Thing that \t and
\n are not allowed, leaving them usable as delimiters.  unix lets you
create such files, but they definitely seem rare, and it is a bit harder
to do from a gui.  who cares if they don't work right.  but leave poor
space alone.

Re: [9fans] spaces in filenames

[Digby Tarvin]

I always rather liked the old Unix approach of the Kernel allowing
anything for which there was no compelling technical reason to forbid.

For file names, that used to be (in the old Bell Labs days) any sequence
of up to 14 bytes, excluding '/' and the NULL used as terminator (both in
the directory entry and the strings passed in system calls).
The subsequent relaxation of the length restriction was certainly a good
thing, but  otherwise I was quite happy with the status quo.

As to to desirability of actually using file names with non-printable
characters - that is certainly questionable. I would prefer
to have a conservative file nameing scheme used in the 'standard'
distribution, refraining from unnecessary use of unprintable
ascii in file names. But I would no more have the operating system enforce
it than I would have the system dictate what bytes appear in a text file.

Most objections to flexible file nameing seem to be the result of syntactic
limitations of the shell which make it difficult to remove or rename
strangely named files when created accidentaly. It was never difficult to
to get rid of them by writing a one line C program.
As I recall, Unix 6th edition came with a 'dsw' (Delete from SWitches) command
to help remove files with funny names. Perhaps something similar is needed.

I do recall once amusing myself as a student arranging to be allocated
inode '0407' for a directory so that with appropriate choice of file
name I could create a directory which would also be an executable
program.

The most compelling reason I can think of for disliking artificial
restrictions on file names (and also case insensitive file names) is
that it is so inconvenient when importing file systems from, or
sharing filesystems with, less restrictive operating systems.

Admittedly you are stuck either way with differences in file name
case sensitivity, but I would rather have the problem of not finding
a file because of a case mis-match than over-writing a file due to
case insensitivity. Although I could probably come up with a scheme
whereby files were stored in a case insensitive way, but directories
could be searched with a 'case insensitive' option which would return
the first match - as a form of wildcarding. It would then be an
application issue weather you were protected from accidentally creating
multiple files differing only in case.

If your file system was case insensitive, a workaround to simulate
case sensitivity would be much more difficult.

One final comment - on the OS-9 operating system (not to be confused
with with MAC OS-9, which it predates by about 20 years...) there is
quite a convenient facility which allows file nameing restrictions to
be varied dynamically. The default disallows, for instance, spaces in
file names. But as a super user, if I want to unpack a tar file which
contains such names, I can temporarily redefine the file name validation
parameters, unpack the archive, and then revert to normal conventions.
This gives the flexibility without the danger of accidental creation
of funny files. Perhaps if this facility were available on a per user
basis, then those that know what they are doing could relax restrictions
when there was a good reason, and others would be protected from mistakes.

Regards,
DigbyT
> really, what is the big deal with spaces in filenames?  yeah, there are
> some file formats here and there, and some shell files that maybe aren't
> so careful, so it's not a cakewalk, but it isn't some Big Huge Problem.
> using shells like rc that manage lists of string works quite well; if
> you need a list of files use "ls" not "echo"; if you really want to use
> the output of a command with backquote, set ifs to \t\n.
>
> geoff talks about how maddening it is to use filenames with spaces on
> mac os x.  i use mac os x too, and have lots of files with spaces, and i
> use quotes on the occasion that i refer to them in the shell.  i haven't
> noticed any "problem" that would cause me to go mad, and everything
> works just fine from the shell and the gui for me.  i send spacey
> filenames to web sites, attach/detach them from mail messages, move them
> about, and things work.  what am i missing?  now that i can use spaces,
> i kinda like using space instead of _ in names -- easier to type and
> easier to read.  why banish the poor lowly space character?  so call me
> a communist for my radical views.
>
> the only problem i've had with spaces is getting to spacey files on
> windows and unix from plan 9 and inferno.  i took out the space
> restriction in inferno and things work swimmingly.  yeah, i know there
> are gotchas here and there, but they really haven't been an issue.  i
> much prefer the ability to manipulate files to the odd gotcha.
>
> oh, the non-printable range also includes 7F, so it's really 00-1F and
> 7F-9F that are restricted.  it does seem to be a Good Thing that \t and
> \n are not allowed, leaving them usable as delimiters.  unix lets you
> create such files, but they definitely seem rare, and it is a bit harder
> to do from a gui.  who cares if they don't work right.  but leave poor
> space alone.
>
--
Digby R. S. Tarvin                                              digbyt@acm.org
http://www.cthulhu.dircon.co.uk