Re: [9fans] Transfer of Plan 9 to the Plan 9 Foundation

[Francisco J Ballesteros]

Simply awesome!
Thanks much to all involved.

> On Tue, Mar 23, 2021 at 6:08 AM  wrote:
> We are thrilled to announce that Nokia has transferred the copyright of
> Plan 9 to the Plan 9 Foundation. This transfer applies to all of the
> Plan 9 from Bell Labs code, from the earliest days through their final
> release.
> 

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tf20bce89ef96d4b6-M5bf4a8b58a90eb6c73c12825
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] zero copy & 9p (was Re: PDP11 (Was: Re: what heavy negativity!)

[Francisco J Ballesteros]

Pure "producer/cosumer" stuff, like sending things through a pipe as long as 
the source didn't need to touch the data ever more.
Regarding bugs, I meant "producing bugs" not "fixing bugs", btw.

> On 14 Oct 2018, at 09:34, hiro <23h...@gmail.com> wrote:
> 
> well, finding bugs is always good :)
> but since i got curious could you also tell which things exactly got
> much faster, so that we know what might be possible?
> 
> On 10/14/18, FJ Ballesteros  wrote:
>> yes. bugs, on my side at least.
>> The copy isolates from others.
>> But some experiments in nix and in a thing I wrote for leanxcale show that
>> some things can be much faster.
>> It’s fun either way.
>> 
>>> El 13 oct 2018, a las 23:11, hiro <23h...@gmail.com> escribió:
>>> 
>>> and, did it improve anything noticeably?
>>> 
 On 10/13/18, Charles Forsyth  wrote:
 I did several versions of one part of zero copy, inspired by several
 things
 in x-kernel, replacing Blocks by another structure throughout the
 network
 stacks and kernel, then made messages visible to user level. Nemo did
 another part, on his way to Clive
 
> On Fri, 12 Oct 2018, 07:05 Ori Bernstein,  wrote:
> 
> On Thu, 11 Oct 2018 13:43:00 -0700, Lyndon Nerenberg
> 
> wrote:
> 
>> Another case to ponder ...   We're handling the incoming I/Q data
>> stream, but need to fan that out to many downstream consumers.  If
>> we already read the data into a page, then flip it to the first
>> consumer, is there a benefit to adding a reference counter to that
>> read-only page and leaving the page live until the counter expires?
>> 
>> Hiro clamours for benchmarks.  I agree.  Some basic searches I've
>> done don't show anyone trying this out with P9 (and publishing
>> their results).  Anybody have hints/references to prior work?
>> 
>> --lyndon
>> 
> 
> I don't believe anyone has done the work yet. I'd be interested
> to see what you come up with.
> 
> 
> --
>   Ori Bernstein
> 
> 
 
>>> 
>> 
>> 
>> 
> 

Re: [9fans] Fwd: ubiquitous environment?

[Francisco J Ballesteros]

a mixture of clive macos and plan9ports

> On 9 Mar 2018, at 01:45, Aram Hăvărneanu  wrote:
> 
>> I don't think anyone is running it anymore.
>> At least, I'm not running it.
>> Sorry.
> 
> What do you run?
> 
> -- 
> Aram Hăvărneanu
> 

Re: [9fans] Fwd: ubiquitous environment?

[Francisco J Ballesteros]

Octopus would run on Plan 9, although we used inferno for (hosted) terminals, 
and it used Op as the protocol (a descendant of 9p like everyone else),
Plan B was more a modified Plan 9 system with name spaces replaced and the 
early ideas of the Octopus window system implemented.

No need to apologize, I'm glad you remember the system :-)
Thanks for your comment about it.

> On 3 Mar 2018, at 20:23, Steve Simon  wrote:
> 
> My appologies for misreprisenting your system.
> 
> Would octopus run on plan9 or was the planB boxes or the
> streamlined filesystem api intrinsic to tos implmenetation?
> 
> -Steve
> 

Re: [9fans] Fwd: ubiquitous environment?

[Francisco J Ballesteros]

In octopus you didn't have to "save" the state. The window system was kept 
running at a server, including the layout you were using.
It was nice, and I miss it. II'll have to do something about it when I get some 
time.


> On 3 Mar 2018, at 20:13, Steve Simon  wrote:
> 
> i am pretty sure nemo’s octopus window system in planB had a way to save and 
> restore its state so you could migrate your sessions from one terminal to 
> another.
> 
> also, i would have thought you could build a windows drawterm which also 
> included the code from exportfs so you could use 9fs and aan to get at the 
> files on your windows box.
> 
> one bit that rangboom added was to be able to mount a filesystem  on windows 
> from plan9. the windows IFS subsystem id not simple or friendly.
> 
> personally i think this idea will become more and more important as we get 
> fiber to the home, local storage will become a thing of the past. 
> 
> -Steve
> 
> 
>> On 3 Mar 2018, at 17:41, hiro <23h...@gmail.com> wrote:
>> 
>> I have 9front running on a server at ovh france, my workstation is a
>> windows 7 machine with drawterm in autostart. drawterm itself is run
>> with -p option so that it can make use of AAN, which recovers broken
>> TCP connections e.g. after resuming from sleep in the mornings or
>> during any network state changes (windows frequently resets TCP
>> connections even if it wouldn't be needed).
>> 
>> This way my rio windows always stay open on windows, even though all
>> the windows network shares, vnc sessions, ssh stuff break every time
>> and have to be painstakingly reconnected.
>> If I could make the drawterm files accessible to windows (you rangboom
>> people please step forward), then I could mount the cifs share on
>> 9front, and then mount that on windows via drawterm to have more
>> stable connectivity to my windows shares.
>> I hope the rangboom people will share their technology so we won't
>> have to port cifsd to drawterm instead.
>> 
>> if i am in the train and on my laptop i can log into the same server.
>> i have a little LTE wifi router that maintains a tunnel to france so i
>> can keep on using the same IP when my laptop and phone leave the house
>> (actually AAN wouldn't even be needed for mobility if it wasn't for
>> crappy low NAT timeouts during temporary connection problems and
>> sleep).
>> 
>> Since my laptop is a separate terminal with it's own rio session,
>> sadly the rio windows are not synced. As Russ mentioned though i have
>> access to the same files.
>> You have to be careful with open sam windows in case they have unsaved
>> changes, but the dropbox people have the same merge conflicts. As a
>> windows user I learned to save my files instead. :)
>> 
>> It would be nice to have less local state (i.e. rio windows, devdraw).
>> Multiple approaches could be used quite easily.
>> One of them that is very curious is mycroftiv's ANTS project, which
>> separates the state of rio rc windows from the graphical environment.
>> 
>> acme also has state-saving functionality. it needs to be killed or
>> told to though. in my scenario it wouldn't get killed cause my session
>> survives, and i don't want it to close on one side normally :)
>> 
>> no idea if sam has anything for this, so right now i advocate
>> discipline instead.
> 
> 

Re: [9fans] Reimplementing Plan 9 in Go (Was: Re: [9front] bio io functions)

[Francisco J Ballesteros]

I don’t now if clive or not,

but, I think the world has changed and I’d like to get a plan9 like environment
but considering as the HW all the machines I use, including their OS as the new 
“HW”.

I’ve been trying to do that since the octopus, clive was just another attempt; 
ideas are welcome :-)


> On 5 May 2017, at 21:43, Giacomo Tesio  wrote:
> 
> You might find https://lsub.org/ls/clive.html interesting.
> 
> 
> Giacomo
> 
> 2017-05-05 15:25 GMT+02:00 Dave MacFarlane :
>> On Fri, May 5, 2017 at 6:21 AM, Stanley Lieber  
>> wrote:
>>> 
>>> Plan 9 has not yet been re-implemented in Go.
>>> 
>>> sl
>>> 
>> 
>> I started trying to do that at one point, but never got my kernel much
>> farther than booting just enough to run "Hello, world!" compiled with
>> 6c on a FAT filesystem in ring 0 and then crashing the system before
>> deciding I don't have the time to finish it or get it somewhere
>> useable. If anyone who has the time is interested in picking it up,
>> contact me off-list and I'll send you a link to my (horribly written
>> and designed) code.
>> 
>> I'm more of a userspace kinda guy anyways..
>> 
>> - Dave
> 

[9fans] OT: clive

[Francisco J Ballesteros]

Hi,

we have been working on a new system, named Clive,
it’s written in Go and includes its new weird file protocol, named zx.
I thought that some of you might be interested, so I’m writing this mail.

The http://lsub.org/ls/clive.html page has links to everything, and,
to avoid noise in 9fans, we will make any further announce regarding
clive at the clivezx google group created for that purpose.

We are using some parts of the system already, but, it’s an ongoing
work on a new research system, beware :-).

Also, we are going to make it run on a modified nix kernel,
but that’s not yet done. Although it will make it more related to 9.

regards

[9fans] nix mk iv

[Francisco J Ballesteros]

I have updated the nix page and the sources at sources.lsub.org for nix
to include the mark iv kernel.

The kernel is still work in progress, but now you can take a look and perhaps
borrow bits from it.

btw, the 9n kernel close to the nix directory/tar ball, is a modified 9 kernel 
that
includes some interesting bits from previous incarnations of the mark iv.
The mark iv should work with a std. plan 9, but perhaps for a few bits easy
to spot and change.

it's under the plan 9 license so we don't have to think much regarding how to
distribute the bits without violating any license.

we'll be updating the sources there as soon as we add new features or fix
bugs in there. But don't hold your breath.

hth

[9fans] html5 canvas, go, devdraw

[Francisco J Ballesteros]

Hi,

I'm playing a bit with the html5 canvas, js,  and go servers, and I'm
thinking it would be quite easy to build a devdraw server (an omero like
server would be even easier) so that you only have to run your go program
and it would open a browser as your devdraw device.

Just wondering, anyone playing with such a beast?

cheers

Re: [9fans] html5 canvas, go, devdraw

[Francisco J Ballesteros]

that's nice, thanks.
I was thinking on using a more abstract interface because, for example,
the canvas has everything needed to provide text frames for something like
acme, and you could write it in go and then make it something that could be
interfaced to programs running on 9.

But a raw 9p devdraw looks cool.
I will take a look. 
thanks again.

On Sep 7, 2013, at 6:05 PM, Nick Owens misch...@9.offblast.org wrote:

 On Sat, Sep 07, 2013 at 05:48:18PM +0200, Francisco J Ballesteros wrote:
 there has been some work on this here. unfortunately not all devdraw
 messages are implemented, so graphics does not fully work.
 
 https://github.com/aiju/jsdrawterm
 
 i run a copy on http://9.offblast.org/
 
 nick
 
 Hi,
 
 I'm playing a bit with the html5 canvas, js,  and go servers, and I'm
 thinking it would be quite easy to build a devdraw server (an omero like
 server would be even easier) so that you only have to run your go program
 and it would open a browser as your devdraw device.
 
 Just wondering, anyone playing with such a beast?
 
 cheers
 
 

Re: [9fans] html5 canvas, go, devdraw

[Francisco J Ballesteros]

I will, thanks to all of you for your replies.

Yes, I think that provided what canvas can do, doing something like
an omero viewer should be both fast to write and efficient when running.

Now that I see that drawterms are around the corner, perhaps here already,
I will play with more omero like interfaces.

On Sep 7, 2013, at 6:24 PM, Anthony Sorace a...@9srv.net wrote:

 You may be interested in what David Hoskin is doing for one of our
 GSoC projects:
https://bitbucket.org/dhoskin/9webdraw
 He's been producing weekly status updates, which you can follow
 along with over on the plan9-gsoc google group:
 http://groups.google.com/group/plan9-gsoc
 It's not done, but he's gotten promising results and is still working on
 it. Check it out.
 
 It'd be interesting to see how simply something for Omero could be
 done, bypassing draw entirely. I really like the model you came up
 with there, and wish there was more diversity in implementations.
 
 Anthony
 

Re: [9fans] Closed nix development is an insult

[Francisco J Ballesteros]

On Sep 6, 2013, at 10:49 AM, Richard Miller 9f...@hamnavoe.com wrote:

 tl;dr: as far as i know, there is no private nix development going on,
 
 Aha, the fact that you don't know proves that it's private. ☺

As are most the files I open in my editor, until at some point I do a Put and
others can access them. But in that interval, development is secretly confined
to my terminal. Yes. That does not mean I'll keep the file for me forever.

Also, yes, I'm usually the one who can better judge when doing a Put in my
editor is a good idea. Sorry about that.

Re: [9fans] Closed nix development is an insult

[Francisco J Ballesteros]

I think its almost ready at least to
try and take a look, I will try to
put out a copy next week,
unless other authors ask me not to. 

any useful bit for production usage
will be shared, anyway, we have always done it 
that way. 

In short, I agree 100% with Steve. 

On Sep 6, 2013, at 10:27 AM, Steve Simon st...@quintile.net wrote:

 Aram's point, obviously, is not that working on nix is insulting.   
 Pretending you are a better judge than the whole world on whether  
 something is 'ready to be shared' is insulting.  Unless you have  
 lawyers pointing metaophorical guns at your job, in which case just  
 say that.
 
 Good grief, I write lots of code for plan9, only some of which I decide
 is successfull and well written enough to release. This is my choice
 and only mine, I created it I do what I want with it.
 
 I don't believe any different rules apply to nemo.
 
 If somone where to priviately, politely ask him off-line asking
 for a copy of the work in progress he might be willing to share,
 though he might not, I don't know what state this code is in or how
 he feels about what has been written.
 
 Fundamentally I don't understand how people beleive they can complain
 when they don't have access to other peoples private work.
 
 Don't get me wrong, I am all for sharing code but its to authors right
 to decide not to share if they wish.
 
 -Steve

Re: [9fans] Closed nix development is an insult

[Francisco J Ballesteros]

the mark I nix was, thanks to erik, made public and got stuff like graphics.
Im sure you know where to find it.

We have another version which is still experimental and unreleased, 
but we were distracted by other things. Hopefully we will publish it in the
near future. But, we do what we can.


The files you refer to are very old files from before it was copied to erik
distribution, unless Im mistaken. They are still left there as a reference.

As an aside, you already got some stuff that came from the nix effort,
for example, the change to long runes was a joint effort with others from
the labs.

So, it's far from dead. 
Sorry to hear that working on it is insulting.
But we will continue to share everything we do when we think it is ready
to be shared.

On Sep 6, 2013, at 12:13 AM, Aram Hăvărneanu ara...@mgk.ro wrote:

 Is nix closed source, dead, or vaporware?
 
 The daily generated nix.tgz is either not daily generated or the
 tree which it is archiving is dead. Most files are from 2012, most
 recent file (nix/sys/log/nixdistr) is from Feb 8 2013, the kernel
 is from Jul 10 2012.
 
 The variant posted on sources is even older. Perhaps the 9P service
 at sources.lsub.org is newer? Nope, same thing:
 
  --rw-rw-r-- M 0 nemo sys 1964 Jul 10  2012 k8cpu
 
 This blog mentions a lot of new development happening:
 http://syssoftware.blogspot.com. Unfortunately, all that development
 either is vaporware or under closed doors. The author mentions in
 many places that the source will be published soon. Unfortunately
 this has not happened.
 
 Interestingly, the nix source published in 9atom contains newer
 files, May 20th to be exact. It's not just new drivers ported from
 9atom, the newest non-driver, k10-specific file is stamped May 16th.
 I don't know if the timestamps are simply wrong or some priviledged
 people do get access to the source.
 
 Considering how little interest is in Plan 9 these days, locking
 Plan 9 under closed doors is a disgrace to this community.
 
 -- 
 Aram Hăvărneanu

Re: [9fans] text database Kirara

[Francisco J Ballesteros]

nice. btw I think I have another tag tool at contrib. not sure, but it was 
called tags, and the search tool was called F. 

I say this because it used file and per file type tag listing (ms2txt, etc) to 
index other file types. It might be an idea to add to your nice tool. 

On Aug 6, 2013, at 3:14 AM, arisawa aris...@ar.aichi-u.ac.jp wrote:

 Hello 9fans,
 
 I have written a text database named Kirara.
 The following is a brief introduction to Kirara.
 If you are interested in, get Kirara from:
  http://plan9.aichi-u.ac.jp/netlib/kirara/
 
 Kenji Arisawa
 
 -
 
 Kirara
 
 -
 
 Kirara is a text indexing/retrieval tool for Plan 9.
 
 Personal use: index/retrieve local files.
 
 Kirara is based on the idea similar to Glimpse.
 
 (1) indexing + grep
 (2) multi-level indexing
 
 (a) small space for indexing
 (b) small update time
 (c) quick search
 
 Note that:
 small indexing   -quick search
 Kirara makes more index - quick search
 Glimpse is single-level indexing.
 
 -
 
 Query
 
 Kirara does not support phrase search.
 The database is index of words,
 
 supporting:
 QE mode (query expression mode)
'', '|', '*'
 The example:
'snoopyhtml'
'snoop*htm*'
 
 RE mode (regular expression mode)
'', RE
 where RE denotes regular expression.
 The example:
'sn.*yh.+l'
 
 RE mode is a bit slow. (a few second.)
 
 -
 
 Words
 
 Two or more runes.
 All words are converted to lower case.
 In English, words is composed of alphabets.
 The number of runes is configurable
 
 Assumption:
 Text is composed of space-separated words
 popular in English and many European Languages,
 but not in Japanese.
 
 -
 
 The user's interface
 
 Best match with Rio
term% kfind snoop
G snoop /sys/src/9/ip/
G snoop /sys/src/cmd/spell/
G snoop /sys/src/9/kw/
...
term% G snoop /sys/src/9/ip
devip.c:34:Qsnoop,
devip.c:95:case Qsnoop:
devip.c:98:devdir(c, q, snoop, qlen(cv-sq), cv-owner, 0400, 
 dp);
...
 Note that: two steps
 1. find directories
 2. find files and the contents
 Step 2 is actually 'grep'. we can use RE.
 
 Two-steps search is not a weekness, but a desirable feature.
 Because we have so many files that are hit by the query.
 
 -
 
 The organization
 
 My example
 
 /n/other/kirara/sysdb
 target: (/lib /sys/lib /sys/src /sys/man /sys/include /sys/doc /rc)
 
 /n/other/kirara/usrdb
 target: $home/^(bin/rc lib netlib doc adm issues srclib src sources)
 
 Indexing target is fully configurable.
 
 -
 
 Multi-Level Indexing
 
 (1) Indexing (top level)
 word to directory mapping
 
 sysdb/index# main index# used for RE mode
 sysdb/mindex# meta index (alphabetic index)# used for QE mode
 sysdb/dind/*# rough index of each directory
 sysdb/QTDir# map table (QID, mtime, path-to-dir)
 
 index# word to dir QID
aa00014f0a
aa0001a1e0
aa0001a26e
 
 mindex# word to range in index
aa 0 126669
ab 126669 491569
ac 491569 1258566
ad 1258566 1852467
...
 dind/*# `*' is a directory QID
00014f05
00014f0a
0001a1ce
 
 usrdb is same.
 
 (2) Indexing (directory level)# optional
 word to file mapping
 
 sysdb/find/*/ind.gz# fine index of the directory (gzipped)
 sysdb/find/*/qtn# map table (QID, mtime, name)
 where `*' is a directory QID
 
 usrdb is same as sysdb.
 
 -
 
 Experiment
 
 (a) hardware
 GA-H61M-USB3-B3
 Intel Pentium G860 (3GHz)
 DDR3 PC3 4GB
 
 (b) software
 9front
 cwfs64x
 
 -
 
 The performance (compression ratio)
 
 target target num_of_dirs  indexing
 sysdb:   556 MB   1790 dirs 49 MB
 usrdb:6620 MB   8948 dirs150 MB
 
 compression ratio: 49/556 (sysdb)
 note: usrdb includes many non-text file.
 
 -
 
 The performance (retrieval time)
 system dependent
 
 RQ search# kfind foo
 
 0.1 seconds.
 
 It is not important to make this time smaller.
 (sufficiently small)
 
 RE search# kfind -r foo
 
 a few seconds
 
 
 -
 
 The performance (construction/update)
 
 (a) Construction time
 system dependent
 
 Initial construction
 need
10 minutes for sysdb
30 minutes for usrdb
 
 (b) Updating time
 two commands for update
 
 mkdb
20 seconds to a few minutes for usrdb
depends largely on state of cache
 
 mkdb1 (currently only for usrdb)
5 to 15 seconds for usrdb
mkdb1 needs event log
 
 -
 
 Scalability
 
 Main factors
 
 (a) retrieval time
 QE search: proportional to number of dirs that include the query
 RE search: proportional to size of index
 
 (b) initial construction time
 proportional to total data
 
 (c) update time
 mkdb:proportional to number of dirs and the changes
 mkdb1:proportional to changes and size of index
 
 -
 
 Used Tools
 
 (1) rc
 
 

[9fans] nix stuff

[Francisco J Ballesteros]

Hi,

we updated our paper page at lsub with a few TRs describing the last work
being done on research nix (mark IV this time).

In particular, as shown in http://syssoftware.blogspot.com.es
about all allocations of a few data structures under the new allocator are
now satisfied fully locally (per process, without synchronization with other 
processes
or cores), without wasting many resources on local pools, which is the nice 
point.

Although we have not yet copied this code out for everyone (but will do),
I though it might be of interest for other 9ers.

hth

[9fans] 9n

[Francisco J Ballesteros]

Hi,

I have copied at sources.lsub.org/9n a copy of a modified plan 9 kernel
that has a new mount table and mount driver, (everything near namec changed),
along with a variant of fossil that speaks 9P2000.ix aka 9pix.

See 9n.README for the details.

It's experimental, so use with caution. I'm using it at my terminal but
it's too young to be reliable.

I also copied at 9nbits in the same server a few files that might be needed
(the new kernel has a new OBEHIND open flag to enable write behind for
files and thus has a new fdflush syscall). 

At http://lsub.org/export/9pix.pdf you have a TR describing the changes made.

We also have a nix mark II that has these and other changes, and it's likely we
will make it public at the old lsub nix site, but we are still changing it and 
fixing
bugs there, so don't hold your breath. Besides this, the new nix has a new
scheduler and a new memory manager.

If anyone gives a try to any of this, and finds out any problem, please, concat
us off list and we'll try to help.
Our main tree has quite a few changes and it's likely I forgot to copy some bit
or made some other mistake :)

enjoy.

Re: [9fans] 9n

[Francisco J Ballesteros]

On Jun 6, 2013, at 7:40 PM, Francisco J Ballesteros n...@lsub.org wrote:

  concat
 us

Since concat'ing us may be disgusting, I should have written contact us.
sorry.

Re: [9fans] broken floating point exceptions and fpregs

[Francisco J Ballesteros]

my terminal runs a plan 9 also with 
those bits. dont worry. 

On May 26, 2013, at 8:00 AM, lu...@proxima.alt.za wrote:

 give us a bit more time and we will put 
 the new bits somewhere.
 
 You are back-porting this to the Bell Labs distribution, I hope?
 grin
 
 ++L
 

Re: [9fans] broken floating point exceptions and fpregs

[Francisco J Ballesteros]

did not publish it yet, but we have what 
could be called a nix mark II, comes
with a new mount table and a fossil
speaking 9pix, plus a new scheduler. 

It does not have al the stuff like graphics in the modified mark I nix 
you have, but, the new stuff should be
easy to use on it. 

give us a bit more time and we will put 
the new bits somewhere. 

hth

On May 25, 2013, at 5:02 PM, erik quanstrom quans...@quanstro.net wrote:

 On Sat May 25 09:59:39 EDT 2013, kh...@intma.in wrote:
 On Sat, May 25, 2013 at 09:47:05AM -0400, erik quanstrom wrote:
 
 why don't we just let the 386 kernel rest in peace and use
 64-bit for sse?
 
 Let's all go buy new computers instead of using the ones we have?
 
 x86_64 has been around since 2003, and on nearly every x86 machine for
 the last 8 years.  sse2 has been around since 2001.  there is not a large
 percentage of currently-running x86 machines that have sse2 but do not have
 x64-bit extensions, and this percentage is generally decreasing.
 
 i put sse2 in the 386 kernel a few years ago, before the compilers supported
 it.  this was to support a linuxemu project.  the linux tools needed sse.
 
 however, when it came to putting sse2 into a general kernel—and that
 includes answering questions cinap is posing, like how do we deal with
 different abis in the debugger, etc.—it seemed more disruption than it
 was worth.  now that the 64-bit kernel is real, and supports even low-end
 hardware like atom, i would rather concentrate on making
 the 64-bit kernel better.
 
 - erik

[9fans] 9pi and upas/send question

[Francisco J Ballesteros]

To anyone with a pi out there,

can you try to do an upas send on the pi (just send a mail)
and let me know if it worked fine there?

thanks

[9fans] upas locking

[Francisco J Ballesteros]

Hi,

we found recently that we had a problem with /mail/tmp/L.mbox
used by upasfs to lock.

Looking into, we found that in upas/common/libsys.c the
function generating the lock file name returns always L.mbox
but not .../L.mbox file name as it seems it should.

Also, the function doing the actual lock hides the error string.

I copied our changed file to /n/sources/contrib/nemo/libsys.c

Didn't create a patch yet because I'm not sure it's the right
change for this problem.

Re: [9fans] upas locking

[Francisco J Ballesteros]

Yes, I noticed the comment, but I thought it was wrong.

The problem was that we had quite a number of upas/fs's and scanmails
running and it was because one of them had a problem and kept a
/mail/tmp/L.mbox file locked. All other ones kept waiting for that
(although all of them were using different mboxes created by the
piped script at /mail/tmp/$pid.blah.blah 

Making this change made problems go away, and I didn't notice any
problem in imap so far. I guess I'll have to reread the imap source to see
if it really requires one lock per dir instead of one per mbox, but even so,
I think imap should use a different lock for that, it's upas/fs the one I'm
talking about.

thanks for the hint

On Apr 18, 2013, at 4:04 PM, erik quanstrom quans...@quanstro.net wrote:

 i think the comment above the function is important
 we use one lock per directory.  it's been a long time since
 i worked on nupas, so i don't recall all the details, but
 iirc, imap4d relies on having one lock per directory.

Re: [9fans] upas locking

[Francisco J Ballesteros]

yes, except that the whole thing
got worse because one of our servers
had a lot of memory used due to
those and we put back the bind for 
tmp. 

On Apr 18, 2013, at 5:33 PM, Charles Forsyth charles.fors...@gmail.com wrote:

 
 On 18 April 2013 15:51, Fco. J. Ballesteros n...@lsub.org wrote:
 if one has one problem, it can lock everyone else using /mail/tmp.
 
 I use a private ramfs, which is also faster.

Re: [9fans] International Ispell in Plan9

[Francisco J Ballesteros]

look under /acme for examples. 

On Apr 12, 2013, at 2:21 PM, trebol trebol55...@yahoo.es wrote:

 On Thu, Apr 11, 2013 at 07:57:13PM +0200, Nemo wrote:
 you could put it in sources, if not yet there.
 
 
 I want to put order in this mess before put it in sources.
 
 I change the for loop to work in the output of ispell instead, and now
 ispell works only one time in terse mode. The script is now much faster
 thanks to the good design of awk and grep.
 
 #!/bin/rc
 
 rm -f /tmp/$pid^'.'aispell*
 
 args=()
 spellflags=()
 for(x){
switch($x){
case -d*
spellflags=($spellflags $x)
case -p*
spellflags=($spellflags $x)
case -T*
spellflags=($spellflags $x)
case *
args = ($args $x)
}
 }
 
 dir = /mnt/wsys
 if(! test -f $dir/cons)
dir = /mnt/term/$dir
 id=`{cat $dir/new/ctl}
 id=$id(1)
 
 if(~ $#args 1  ~ $args /*){
adir = `{basename -d $args}
args = `{basename $args}
echo 'name '^$adir^/-spell  $dir/$id/ctl
cd $adir
 }
 if not {
echo 'name '^`{pwd}^/-spell  $dir/$id/ctl
 }
 
 {
echo noscroll
if(~ $#args 0){
cat  /tmp/$pid^'.'aispell0; i = /tmp/$pid^'.'aispell0; winname = 
 `{cat /mnt/acme/$winid/tag | awk '{print $1}'}; for(j in `{cat $i | 
 $home/local/bin/ispell -a $spellflags | awk '/^[#]/{gsub(/ /,_); 
 print}'}){$home/local/bin/acme/spout $i | grep `{echo $j | awk -F_ '{print 
 $2}'} | awk -F: '{OFS=:;$1 = '$winname'; print}'  /tmp/$pid^'.'aispell 
 } ; sort -u /tmp/$pid^'.'aispell  $dir/$id/body; rm -f /tmp/$pid^'.'aispell*
}
if not for(i in $args){
for(j in `{cat $i | $home/local/bin/ispell -a $spellflags | awk 
 '/^[#]/{gsub(/ /,_); print}'}){$home/local/bin/acme/spout $i | grep `{echo 
 $j | awk -F_ '{print $2}'}  /tmp/$pid^'.'aispell } ; sort -u 
 /tmp/$pid^'.'aispell  $dir/$id/body; rm -f /tmp/$pid^'.'aispell
}
echo clean
 } $dir/$id/ctl
 
 
 Now you can use it in the tag line to spell check the dot, and the
 output begins with the name of the window, so if you select all the
 window's body, you can spell check it without save it with the same
 commodity. Of course the addresses of the misspelled words don't works
 with a common selection.
 
 To make this work, I need to know how to get the dot address within
 the script.  Also the functions don't work in acme, but a similar script
 works. Why?
 
 fn aispellen {$home/local/bin/acme/aispell -p$home/lib/pdict_en -damerican $*}
 
 Any help?

Re: [9fans] gcc not an option for Plan9

[Francisco J Ballesteros]

andrey, I agreed the language is nice
and that's why I also use it. 
I just pointed out that binaries are one
order of magnitude larger, as 
you just proved. 

perhaps I shouldn't have raised this. 
I didn't want to bother anyone. 

El Mar 24, 2013, a las 12:45 AM, andrey mirtchovski mirtchov...@gmail.com 
escribió:

 If you want real programs which are bigger that I (we) actually use that will
 be (much) bigger in go:
 
 ls, cp rm mv cat acid, I can go on.
 
 Small programs are useful and important.
 
 here's a representative set. the programs are identical in behaviour
 and arguments to the Plan 9 set. the size is as reported by du, in
 kilobytes:
 
 1456 ./date/date
 1460 ./cat/cat
 1564 ./cleanname/cleanname
 1564 ./tee/tee
 1736 ./echo/echo
 1764 ./cp/cp
 1772 ./uniq/uniq
 1780 ./cmp/cmp
 1780 ./freq/freq
 1780 ./wc/wc
 1792 ./comm/comm
 
 binaries are bigger and for example replacing the minimal sets of commands of
 the system, this can make the
 minimal system at least 5 times bigger easy.
 
 if that was a real issue you were trying to solve there are things you
 can do to help yourself. most notably sticking everything in a single
 binary and invoking the right function based on your argv0. it took me
 less than 15 minutes to convert the above code to work as a single
 binary and most of that was in handling clashing flags (it would've
 been a non-issue if I had used flagsets when writing the original
 programs). size at the very end:
 
 $ date  test.txt
 $ ln -s $GOPATH/bin/all cat
 $ ln -s $GOPATH/bin/all wc
 $ ./cat test.txt
 Sat Mar 23 17:32:42 MDT 2013
 $ ./wc test.txt
  1   6  29 test.txt
 $ du -k $GOPATH/bin/all
 1888 /Users/andrey/bin/all
 
 the size of the original binaries on plan9 is 588k. what was a factor
 of 30 is now a factor of 3. all tests still pass and it took less time
 to complete than writing this email.
 
 there's an even better solution, but it won't work on plan9 because
 the go tool is slow there :)

Re: [9fans] gcc not an option for Plan9

[Francisco J Ballesteros]

go runs already on 9.

Binaries are one order of magnitude larger and the go tool  part of the 
runtime code are, well….

but it's already there.

On Mar 23, 2013, at 12:40 PM, Peter A. Cejchan tyap...@gmail.com wrote:

  I still hope that some clone of plan9/nix/nxm will merge with Go

Re: [9fans] gcc not an option for Plan9

[Francisco J Ballesteros]

Than plan 9's C ones.

On Mar 23, 2013, at 5:09 PM, erik quanstrom quans...@quanstro.net wrote:

 Binaries are one order of magnitude larger and the go tool  part of the 
 runtime code are, well….
 
 sorry to be dense.  larger than what?
 
 - erik

Re: [9fans] gcc not an option for Plan9

[Francisco J Ballesteros]

Although, in general, I agree. I think that having the resources doesn't mean
we have to consume them (although we might if that pays off, of course).

For example, looking at what go install does wrt what a few mkfiles would
do for the same go source is illustrative of what I'm trying to say.

On Mar 23, 2013, at 6:15 PM, Rob Pike robp...@gmail.com wrote:

 Much of which is symbols. Plus, a a simple computer has gigs of memory.
 
 Yes, it's remarkable how much bigger programs are now than they were
 20 years ago, but 20 years ago the same things were being said. I
 understand your objection - I really do - but it's time to face the
 future. The smart phone in your pocket is roughly 100 times faster
 than the machine Plan 9 was developed on and has 1000 times the RAM.
 Computers are incredibly powerful now, and the technologies of today
 can use that power well (as I claim Go does) or poorly (as some others
 do), or ignore it at the risk of obsolescence.
 
 -rob

Re: [9fans] gcc not an option for Plan9

[Francisco J Ballesteros]

I have a few programs written, including fs sync tools and a few other things.
I guess the largest one might be 10k lines.
The language is nice, although binaries are still large. I mentioned hello 
world 
because that was the trivial example. I saw the same effect with other real
world programs.

I admit it might be necessary, but I wouldnt say sizes are comparable.


Also, I was reading the discussion andrey mentioned by the time it happened.
I guess it didnt reach this list until now because go didnt run on plan 9 until
recently.

On Mar 23, 2013, at 8:17 PM, Rob Pike robp...@gmail.com wrote:

 It's pointless to complain about the size of hello world. It's not a
 real program. In Go's case it's larger than a C binary because the
 libraries (and the presence of a runtime) are capable of much more
 under the covers, but by the time you write a real program in Go
 you'll find the ratio of Go binary to C binary isn't nearly so large;
 the incremental cost to the binary of a Go source file compared to a C
 Go file is negligible.
 
 A house is much heavier than a tent, but it also has a much stronger 
 foundation.
 
 -rob

Re: [9fans] gcc not an option for Plan9

[Francisco J Ballesteros]

On Mar 23, 2013, at 8:33 PM, Rob Pike robp...@gmail.com wrote:

 Why use mk when the source code has all the
 information you need to build the program

speed. 
You have a fast and nice compiler.
I only copy a std mkfile to each dir with go source. I dont write them.

Re: [9fans] gcc not an option for Plan9

[Francisco J Ballesteros]

might be, but I was also thinking on macos x, not just 9.

On Mar 23, 2013, at 8:37 PM, Rob Pike robp...@gmail.com wrote:

 If go install is slow on Plan 9, it's because Plan 9's file system is
 slow (which it is and always has been), and because go install does
 transitive dependencies correctly, which mk does not.
 
 -rob

Re: [9fans] gcc not an option for Plan9

[Francisco J Ballesteros]

I used noweb, and web before that, long before go was conceived.
In fact, I was a huge fan of that. Knuth literate programming was fun.
it was tiny compared with godoc tool. Although the go tool is tiny compared
with eclipse or even the old code warrior.

I like the language, and worked to get it running on our systems.
Its nice how the go tool does some of the things it does, although there are
other things it does that I prefer to do with other tools.

I was just mentioning some facts about it I dont like.

On Mar 23, 2013, at 8:58 PM, andrey mirtchovski mirtchov...@gmail.com wrote:

 with mkfiles you can never have something like http://godoc.org. in
 fact, it would be very difficult to make something like godoc for any
 other language without major support from the authors or volunteers.
 
 what godoc.org does is amazing -- when you type in a query for
 something that looks like a go package it will attempt to download it
 and generate the package documentation from the source code on the
 fly. no interaction from the author or website maintainer need to
 happen, all is done by the go tool, usually with enough speed that not
 much waiting is involved. all the package needs to do is abide by a
 few rules in naming imports.
 
 try it for yourself (these packages will surely not be in the index):
 
 http://godoc.org/code.google.com/p/goxscr/qcs
 http://godoc.org/code.google.com/p/goxscr/deco
 http://godoc.org/code.google.com/p/goxscr/palette
 http://godoc.org/code.google.com/p/goxscr/rorschach
 http://godoc.org/code.google.com/p/goxscr/spirograph
 
 the stuff that falls out of such a tool is even more impressive.
 here's an import graph for one of the xscr programs:
 http://godoc.org/code.google.com/p/goxscr/moire?view=import-graph
 
 here's the one for godoc:
 http://godoc.org/code.google.com/p/go/src/cmd/godoc?view=import-graph

Re: [9fans] Go on Plan9/Arm

[Francisco J Ballesteros]

yes, checked and runs on 386, amd64, and arm.
with the 9 tree from sources.

iirc, I had to do some changes for amd64 and gorka had to port to arm.

hth

On Mar 21, 2013, at 6:23 PM, Francisco J Ballesteros n...@lsub.org wrote:

 I think Gorka has it running. 
 At least, it runs in our rpi's.
 
 On Mar 21, 2013, at 5:54 PM, Jeremy Jackins jeremyjack...@gmail.com wrote:
 
 Sorry to dredge up an old thread, but did you get any further with
 this Lucio? I'm getting a similar error building current Go tip.

Re: [9fans] new fork?

[Francisco J Ballesteros]

yes, octopus was a better plan.
both should be still avail from our web site.

On Feb 27, 2013, at 11:39 PM, David Leimbach leim...@gmail.com wrote:

 There is/was a Plan B.  Some of the ideas went into Octopus I think...
 
 
 On Wed, Feb 27, 2013 at 1:45 PM, Devon H. O'Dell devon.od...@gmail.com 
 wrote:
 2013/2/27 David Leimbach leim...@gmail.com:
  I'd have called it Plan A.
 
 [Insert horrific Plan B joke here.]
 
  On Wed, Feb 27, 2013 at 1:36 PM, hiro 23h...@gmail.com wrote:
 
  http://plan10.tumblr.com/
 
 
 
 

Re: [9fans] new fork?

[Francisco J Ballesteros]

until a few weeks ago. it has been retired now.
we are working on the next one, but it will take time.

On Feb 28, 2013, at 12:05 AM, Matthew Veety mve...@gmail.com wrote:

 Do you guys still use it at lsub?
 
 On Feb 27, 2013, at 17:54, Francisco J Ballesteros n...@lsub.org wrote:
 
 yes, octopus was a better plan.
 both should be still avail from our web site.
 
 On Feb 27, 2013, at 11:39 PM, David Leimbach leim...@gmail.com wrote:
 
 There is/was a Plan B.  Some of the ideas went into Octopus I think...
 
 
 On Wed, Feb 27, 2013 at 1:45 PM, Devon H. O'Dell devon.od...@gmail.com 
 wrote:
 2013/2/27 David Leimbach leim...@gmail.com:
  I'd have called it Plan A.
 
 [Insert horrific Plan B joke here.]
 
  On Wed, Feb 27, 2013 at 1:36 PM, hiro 23h...@gmail.com wrote:
 
  http://plan10.tumblr.com/
 
 
 
 

[9fans] two questions about go in Plan 9

[Francisco J Ballesteros]

Hi,

I've been using go for a few things in Plan 9, and noticed a couple of things.
I'd just like to know if it's me or if this also happens to others:

- diagnostics issued by log.Print et al. don't show up unless I call log.Fail
- closing a tcp connection which is still open by a nearby reader proc does not 
report EOF to the other end
of the connection.

It might be something I made or something I didn't understand, but just in case 
these are known I thought I might ask here.

thanks 

Re: [9fans] two questions about go in Plan 9

[Francisco J Ballesteros]

Forgive me, 

Somehow I removed the -v from the call to go test. That makes the log print 
only for failed tests.

Regarding TCP, forsyth reminded me that it's what I'd get with the std. Plan 9 
system calls, which
is so.

I guess my question is… how can I interrupt a reader in that case? In C I'd be 
able to interrupt it.
Now, in go on Plan 9, I can't interrupt it and I can't make the stream hangup. 

What do you do in that case? Or, more likely, what am I doing wrong?

thanks


On Feb 18, 2013, at 4:07 PM, n...@lsub.org wrote:

 Hi,
 
 I've been using go for a few things in Plan 9, and noticed a couple of things.
 I'd just like to know if it's me or if this also happens to others:
 
 - diagnostics issued by log.Print et al. don't show up unless I call log.Fail
 - closing a tcp connection which is still open by a nearby reader proc does 
 not report EOF to the other end
 of the connection.
 
 It might be something I made or something I didn't understand, but just in 
 case 
 these are known I thought I might ask here.
 
 thanks 
 
 
 [/mail/box/nemo/msgs/201302/876]

Re: [9fans] two questions about go in Plan 9

[Francisco J Ballesteros]

I know, but, what's the std way to do that in go in plan 9?

On Feb 18, 2013, at 7:07 PM, cinap_len...@gmx.de wrote:

 network connections on plan9 can be hanged up by writing hangup into
 the corresponding ctl file.
 
 --
 cinap
 
 [/mail/box/nemo/msgs/201302/897]

Re: [9fans] ppxeload nix

[Francisco J Ballesteros]

Nevertheless, if someone wants a 64bit kernel that could be used as a terminal, 
I'd say
Erik's copy would be fine for that.


On Feb 7, 2013, at 11:42 PM, David du Colombier 0in...@gmail.com wrote:

 Erik's 9atom which distributes basically the same source as you can
 find on lsub.org (because he wrote a lot of the patches for the lsub
 fork)
 
 Erik's NIX is quite different from the current code at Lsub
 and there are a number of additions, mostly related to terminals.
 
 In particular, as Erik said earlier (and I just confirmed it),
 the e820 change made it incompatible with the current 9boot
 from Bell Labs as is (which works fine with googlecode/lsub code).
 
 -- 
 David du Colombier

Re: [9fans] ppxeload nix

[Francisco J Ballesteros]

Just to let others know, Erik has everything the lsub nix had. If you want a 
terminal, you
might just pick that one.

We are in the process of removing features from the nix at lsub to make it 
become a more
researchy kernel; and we will focus on servers, not terminals. 
for terminals, there are nother nixies out there. Once we found nice things
to do to the kernel, we'll make the code available for others to import, as 
usual. 

btw, the stock distribution may include an amd64 kernel in the future. I'd also 
keep an eye
on that. I'm sure that would be a lot cleaner than what we now have.

hth

Re: [9fans] I found this discussion pretty funny

[Francisco J Ballesteros]

did you notice the discussion was from this century?
surprising!

On Oct 17, 2012, at 8:28 PM, cinap_len...@gmx.de wrote:

 yeah, like mount... its files all the way down :)
 
 linux is like windows... everything is a HANDL^Wfiledescriptor
 
 --
 cinap

Re: [9fans] Uriel

[Francisco J Ballesteros]

sad news.
he was quite young, also. :(
r.i.p.

On Oct 14, 2012, at 10:17 PM, Devon H. O'Dell devon.od...@gmail.com wrote:

 He was certainly a lively and unique character in person and on the
 various lists / channels he frequented. RIP.
 
 --dho
 
 2012/10/14 Calvin Morrison mutanttur...@gmail.com:
 On 14 October 2012 15:55, Sergey Zhilkin szhil...@gmail.com wrote:
 Oh  F*ck...
 R.I.P
 
 Bad news.
 
 воскресенье, 14 октября 2012 г. пользователь Julius Schmidt писал:
 
 I am very sorry to inform you that uriel has passed away recently.
 
 He will be missed.
 
 
 
 --
 Sent from Gmail Mobile
 
 I'm speechless.
 

Re: [9fans] Kmouse?

[Francisco J Ballesteros]

those were added to let use keys in the laptop as mouse keyboards.
they are configured using /dev/kbmap

I have a couple of kbmaps using those.

On Aug 21, 2012, at 12:46 AM, erik quanstrom wrote:

 in pc/kbd.c, there are the scan codes Kmouse|button.  where button in {1, .., 
 5}.
 i am not sure where it is documented how these scan codes could get generated.
 does anyone remember?
 
 - erik

Re: [9fans] Heresy alert, Zerox - Clone

[Francisco J Ballesteros]

Yes.
Also, if anyone wants a different behavior, it´s easy to change
to source so it fits your preferences. 

On May 31, 2012, at 8:05 PM, steve wrote:

 Aww, leave sam alone, he served us well for (so) many
 years,  zerox is part of his baroque charm.
 
 if where to change any text, which i wouldn't, it would
 be snarf, which always draws comments from the uninitiated.
 
 the one real change that i think would be worthwhile
 would be a warp-to-location on undo or redo. i occasionally
 want to undo a little of the changes i have made, but if these
 are not in the current view its not easy to judge how many steps to undo.
 
 -Steve
 

Re: [9fans] Heresy alert, Zerox - Clone

[Francisco J Ballesteros]

I'd prefer clown, because it reminds me of clone. ;)
couldn't resist.

On May 30, 2012, at 6:20 PM, Richard Miller 9f...@hamnavoe.com wrote:

 copy?
 
 That surely won't be confused with the Snarf functionality at all
 
 And on second thought, maybe Dup is a bit too much like Dump ...
 

Re: [9fans] The creepy WORM. (was: Re: Thinkpad T61 Installation Experience)

[Francisco J Ballesteros]

On May 20, 2012, at 5:13 AM, Bakul Shah ba...@bitblocks.com wrote:

 
 How often would you flush to disk? You still need to worry about the order
 of writing metadata.
 

that's the nice thing. it's so simple I don't have to worry about order. you 
write new
blocks and, once all of them reached the disk without errors, you write a new 
super with
the address of a new root. if you fail before the super is written, you have 
the old tree,
otherwise, you get the new one. the super has two copies of its data, in case 
you fail
in the middle of writing it, if they don't match, you use the oldest one.

The tmr proc writes new versions of the tree on a periodic basis and also if the
number of dirty (of memory addressed, actually) blocks exceeds some value.


 You do have to keep track of free disk blocks. On disk. So a linked list
 would require you visit every freed block.
 


There's no linked list either :)
There's a mark per block, an epoch number, so you have one block with marks
for each block group. all blocks given addresses on disk use the current value 
for the
mark or epoch. when you want to collect more free blocks, you traverse the tree 
and update
the mark for blocks. After that, you increment the value for the mark that is 
used to recognize
free blocks.

Of course you could fail at any time, and, again, if you do that before writing 
the new
super the only thing that happens is that you'll have to mark again the blocks 
(you
prune the mark process when you find that the block visited already has the 
correct mark
value).

This was actually the code I had in place to double check that the previous 
implementation
for free block management was correct, but I noticed that it was both doing the 
job, and 
not disturbing normal operation in the file system, so I removed the management 
code and
declared this debug check the actual algorithm.


 I think an incore FS the easy case but you will have to face
 the issues of corner/boundary cases, various error conditions
 and efficiency when dealing with real disks. These things are
 what introduce complexity and bugs. Soft updates in FFS took
 quite a while shake out bugs.  zfs took a long time.  Hammer
 fs of DragonFly took a while. Pretty much every FS design has
 taken a while to be rock solid.  Far longer than the original
 estimates of the designers I think.
 


Yes, that's why I improved it mostly by removing features and simplifying 
algorithms
instead of using clever ones. It was not easy to do that, it had like three or 
four rewrites.
Funny it was a lot easier to write the first, much more complex, version of it.

There are no soft
updates now, because the log makes that unneeded. And the complex part of
log management, which is reclaiming unused blocks, is also gone because of the
naive, yet effective, algorithm used now.

But you are right. I spent most of the time fixing problems with disks that 
were full or
had faults injected at the worst times. The operation in non boundary cases was 
always
fine, even with the fancier implementation I used before.

Regarding memory and processors, the code is aggressive and tries to use 
everything
because the machine will be devoted just to serve files.

Re: [9fans] Governance question???

[Francisco J Ballesteros]

Where no-one is aka Nemo.

On May 16, 2012, at 9:07 AM, Gorka Guardiola wrote:

 It means (loosely translated) no-one provokes me without punishment.

Re: [9fans] Governance question???

[Francisco J Ballesteros]

On May 16, 2012, at 4:03 PM, hiro wrote:

 There are towns without restaurants and pubs in America?

More than there are in Spain.

Re: [9fans] Governance question???

[Francisco J Ballesteros]

damn, I'll have now to seek for another uid

it's all in the open.

On May 15, 2012, at 8:54 PM, Charles Forsyth charles.fors...@gmail.com wrote:

 Yes, I see you've realised that Nemo has nothing to do with that nautical 
 fellow,
 but refers to the Latin motto Nemo me impune lacessit!
 
 On 15 May 2012 13:42, Christoph Lohmann 2...@r-36.net wrote:
 I can’t imagine 9fronters to work under the iron  fist  of  the  quality
 rulers  in  Nix.
 

Re: [9fans] Governance question???

[Francisco J Ballesteros]

On May 14, 2012, at 12:14 PM, IainWS wrote:

 Would
 I be wrong in saying there are four dictators?

Yes, there's just good taste :)

Re: [9fans] Octopus viewer?

[Francisco J Ballesteros]

Oh! Good catch!

Sorry I couldn't be of more help.

On May 10, 2012, at 9:58 AM, kokam...@hera.eonet.ne.jp wrote:

 For what you say I think that your plumber might not be configured or
 that something happen with the configuration file after view tried to plumb 
 it.
 
 In the worst case I can just send you my configuration files :)
 
 It's not configuration problem, but, maybe, different version of
 inferno.  I versioned up my inferno to run it on my Ubuntu 11.10.
 
 In the funtion of viewcmd() of /usr/octopus/port/lib/view.b, the line
 r := os-filename(file);
 gives the r=/usr/octopus/tmp/view.2.DSCN1549.jpg,
 even the file=/tmp/view.2.DSCN1549.jpg is given.
 Then, I changed the lines:
 Plan9 or PlanB =
   cmd=sprint(plumb %s, r);
 to
 Plan9 or PlanB =
   cmd=sprint(plumb %s, file);
 
 That's all.
 Now I'm viewing the jpg image by !cp DSCN1549.jpg /mnt/view
 
 Kenji
 

Re: [9fans] Octopus viewer?

[Francisco J Ballesteros]

Sorry, I missed the previous mail.
To avoid noise for 9fans, can you let me know off-list which OS are you using 
on the PC
and on the terminal and I'll try to help?

For what you say I think that your plumber might not be configured or
that something happen with the configuration file after view tried to plumb it.

In the worst case I can just send you my configuration files :)

On May 8, 2012, at 8:23 AM, kokam...@hera.eonet.ne.jp wrote:

 I might have been not so specific.
 I'll try once more.
 
 I dispatched the command on the terminal's olive window:
 !cp DSCN1549.jpg /mnt/view
 Nothing happens.
 Hoever, on the terminal's local window where octopus command
 was dispatched, I see tow lines of messages of:
 sh: plumbing write error: no matching plumb rule
 view: cmd plumb /usr/octopus/tmp/view.2.DSCN1549.jpg   
 
 Then, I hided the olive window, and inferno's shell window raised,
 and examined ls -l /tmp on the inferno's sh window.
 Here, I can find the file of view.2.DSCN1549.jpg.
 
 However, lc /usr/octopus/tmp shows nothing but error.
 /usr/okamoto/tmp, neither.
 Then I think the arrorwd line above shows that the program tryed 
 to do plumb the file on a wrong place, because of confusion of
 namespaces.
 
 Kenji
 
 /mnt/view is used for that. 
 open in olive will use it when in a
 terminal. 
 
 I tried this, but fails.
 

Re: [9fans] Summary of acme chords

[Francisco J Ballesteros]

plus I think the man page describes it quite well. IIRC.

--
using ipad keyboard. excuse any typos.


On Apr 25, 2012, at 9:19 PM, hiro 23h...@googlemail.com wrote:

 How did you learn this information -- from a stupid textual
 list?
 
 No, from a youtube vid. There were these nice mouse button graphics
 accompaning the screencast like later in the thread.

Re: [9fans] Octopus viewer?

[Francisco J Ballesteros]

 
 1) In a directory panel, is it difficult to make distinguish directory
 and files like acme?

yes, names are listed. that's all

 2) Is it difficult to reflect the change, say create a file etc, the
 content of directory panel?

You have to reopen the dir. 
Button 3 click on the name, then move right.

 3) Where is viewer application for sau, pdf files?
 (I've not try distributed system, say the PC and terminal, so far.
 I'm trying only the PC)
 

that's /mnt/view
it's a fs that wraps the viewer at your terminal.
if the terminal is plan9, you could plumb what you copy there.


 Kenji
 

Re: [9fans] Octopus viewer?

[Francisco J Ballesteros]

On Apr 22, 2012, at 9:55 AM, kokam...@hera.eonet.ne.jp wrote:

 4) Why I cannot run inferno applications, such as charon
 during o/mero and o/live is running.  I got 
 wmlib: no draw context error.
 
 Kenji
 

You can run emu apps, but there is no graphics context.
So you can't run inferno graphic apps.
Apps should use /mnt/ui instead.

Re: [9fans] nix at lsub

[Francisco J Ballesteros]

Sure. I'm using it (and nix/plan9) to develop nix.
Drop me a line off-list if you want help, but you should have
everything you need in the web site, including the distribution of the system.


On Apr 18, 2012, at 2:26 AM, kokam...@hera.eonet.ne.jp wrote:

 I was thinking along the lines of http://lsub.org/ls/octopus.html, myself,
 using a child of Inferno.
 
 Yeah, sound like interesting.
 Can I try this octopus on some of the PC still now?
 because I didn't do it, and have no idea of this.
 
 Whe I tried inferno, I god bad feeling of its gui (sorry all).
 
 Kenji
 

Re: [9fans] nix at lsub

[Francisco J Ballesteros]

To make it explicit, the plan I have is to
throw away o/live and o/mero and write something native for
macos, linux, and perhaps ios such that the UI widgets are abstract
and handled in a similar way they are handled in o/live.

Only that they'd be native widgets with the look of the native system
(that's not to say you can't implement an editable text-pannel with
the mouse language we all love).

Also, as Forsyth points out, the set of widgets has to be rethought, e.g.,
there should be a web widget.

Then it's a matter of using those files from inferno, and remote systems.

But, as I said, I don't have a single line of code yet for all of this.

On Apr 18, 2012, at 2:27 PM, Charles Forsyth wrote:

 I should add that along the lines of Octopus meant that,
 as often happens, many of the details might change to account
 for experience and second thoughts, and for changed technology.
 Obvious candidates for the latter would be the increased availability of 3D,
 and vastly greater browser capabilities (for good or ill).
 

Re: [9fans] nix at lsub

[Francisco J Ballesteros]

Is it exported as files?

I thought I knew Qt, but, if it provides a file interface, I missed that.

On Apr 18, 2012, at 5:45 PM, arn...@skeeve.com wrote:

 Hi.
 
 To make it explicit, the plan I have is to
 throw away o/live and o/mero and write something native for
 macos, linux, and perhaps ios such that the UI widgets are abstract
 and handled in a similar way they are handled in o/live.
 
 Only that they'd be native widgets with the look of the native system
 (that's not to say you can't implement an editable text-pannel with
 the mouse language we all love).
 
 Qt already provides this (and much more). It means working in C++ (which is
 either a bug or a feature, depending upon how you look at it).
 
 I have used Qt and find it well designed and pleasant to use, but many
 9fans might find such a thougt to be heretical.
 
 Also, as Forsyth points out, the set of widgets has to be rethought, e.g.,
 there should be a web widget.
 
 I think Qt even has that.
 
 Then it's a matter of using those files from inferno, and remote systems.
 
 But, as I said, I don't have a single line of code yet for all of this.
 
 It sounds like interesting work!  Good luck!
 
 Arnold

Re: [9fans] nix at lsub

[Francisco J Ballesteros]

If you consider a set of abstract widgets, reasonable enough, you could map them
to native implementations in

-a browser
-cocoa
-gnome
-add your one here.

then, there could be a portable shared component speaking to those and 
gatewaying
to your favorite protocol (9p, ix), and you could have a clean interface and
reasonable bindings for it.

cocoa was going to be my first move here, btw.
didn't even start, though.

--
using ipad keyboard. excuse any typos.


On Apr 18, 2012, at 6:28 PM, Charles Forsyth charles.fors...@gmail.com wrote:

 i thought the easiest way to begin and be cross-platform would be to talk to 
 a component running in a browser,
 similar in principle to a viewer in Octopus.
 a browser client will be needed anyway, and there is a browser on many things 
 (often only a browser); thus
 your first step won't be your last, but it would cover a big distance.
 it might also make it quicker to experiment.
 

Re: [9fans] nix at lsub

[Francisco J Ballesteros]

On Apr 17, 2012, at 10:41 AM, kokam...@hera.eonet.ne.jp wrote:
 
 Your intension is to develope two ways, one for
 server (nix), and one for terminal (like drawterm?)
 

Just to let you use your server(s) but assume that
your terminals might be running macos, linux, ios, ...
as their native systems. You could say it´s a drawterm
revisited, but I won´t be just that :)

Of course that´s just one way, and it does not strictly have
to do with nix because nix is mostly a kernel for manycore systems.

Re: [9fans] nix at lsub

[Francisco J Ballesteros]

Just to say that we moved the development mailing list.
Sorry about that.

it's nix at lsub.org
and you can subscribe by a mail to nix-request at lsub.org,
should you want to do so.

Sorry again.

On Apr 14, 2012, at 11:02 PM, Nemo wrote:

 Hi,
 
 just FYI,
 
 http://lsub.org/ls/nix.html
 
 has links and pointers for anyone to get the
 distribution and updates and/or send changes.
 
 hth
 
 

[9fans] octopus paper

[Francisco J Ballesteros]

Given the lag in publication, this system is no longer under development
(though we are still using it), but here's a paper about the Octopus.
http://www.sciencedirect.com/science/article/pii/S016412121200043X

I post it here because it's related to Plan 9.

Re: [9fans] octopus paper

[Francisco J Ballesteros]

WoW! I hate them.
It seems my university is subscribed and I could browse it freely…
I'll talk to you off list.

On Mar 2, 2012, at 11:24 AM, Aram Hăvărneanu wrote:

 Given the lag in publication, this system is no longer under development
 (though we are still using it), but here's a paper about the Octopus.
 http://www.sciencedirect.com/science/article/pii/S016412121200043X
 
 It asks me for $31.50 to download the paper.
 
 -- 
 Aram Hăvărneanu

Re: [9fans] usb flash drive with ext2

[Francisco J Ballesteros]

you can enable debug diagnostics for devices by using the usbd ctl file.
I don´t remember which ones are the strings (see the man, probably) but
I remember you can enable debug flags without restarting it.

You could try to locate them and enable debug for that, plug the disk
again, disable
debug for that.

IIRC, that is.

On Thu, Jan 12, 2012 at 12:25 PM, Richard Miller 9f...@hamnavoe.com wrote:
 /dev/usb/ep4.0 lun 0: inquiry Generic Flash Disk      8.07 geometry 8007680 
 512

 ... so I'd think this is ok ...

 My next step would be to get more diagnostic output from usb/disk.
 This is no longer easy with the new monolithic usb driver
 architecture.  You can't just start 'usb/disk -d' because the usb/disk
 embedded into usb/usbd will have started automatically and seized
 control of the device when you plugged it in.

 I think you will need to generate a new usbd with the disk driver
 configured out (see /sys/src/cmd/usb/usbd/usbdb), then kill the usbd
 which is embedded into the kernel and start your new one, before
 running usb/disk.

Re: [9fans] Building Go on Plan 9

[Francisco J Ballesteros]

Well, that's actually the approach Ron would choose for nix.
IIRC, there were a bunch of mkfiles added to the std. go tree
to make it compile, but I may be mistaken.
Ron knows better.


On Fri, Dec 2, 2011 at 7:42 AM, Lucio De Re lu...@proxima.alt.za wrote:
 I would be interested
 in the approach Nemo might choose for nix.

Re: [9fans] Building Go on Plan 9

[Francisco J Ballesteros]

+1 for using parallel mkfiles.
If they are few, we don't need to import gmake and we could
still build just by adding them to the std tree.


On Fri, Dec 2, 2011 at 6:55 PM, Lyndon Nerenberg lyn...@orthanc.ca wrote:
 modify ape/make.


 I was just waiting for this :-P

 Please do NOT fuck with ape/make.  As the paper says, APE has become more of
 a tool to write conforming ANSI / POSIX code vs. porting the stuff to Plan
 9.  Please don't take apes' virginity.

 If people insist on inflicting gmake upon us, fine. I guess.  But please
 (please?) don't screw the ape: deposit it in /$cputype/bin/gmake instead.

 And now that the camel is firmly in the tent, we might as well
 create a foo/camel hierarchy to parallel foo/ape, for all the camel
 cruft (i.e. /$cputype/camel/make vs. /$cputype/bin/gmake).

 Then, people who want to ride camels through the desert can run bsh(1) to
 obtain a suitably inhospitable environment.  (bsh as in baking-hot shell,
 although bs(1) seems like a reasonable alternative.)

Re: [9fans] troff book

[Francisco J Ballesteros]

I have written books both in latex and in troff.
It's a nightmare, no matter in what, to get things like
indexes and tocs right.

Doing it in troff required me to write a few scripts to
generate some of the tables.

Doing it in latex required me to write a few scripts to
fix up things not handled well by latex (I'm sorry, but don't
remember which ones were the actual problems, it was long ago).

Re: [9fans] troff book

[Francisco J Ballesteros]

Could be worse, they might require using IE on Windows 7 to submit them.
Or perhaps they already do?

On Fri, Dec 2, 2011 at 7:16 PM, ron minnich rminn...@gmail.com wrote:
 Irony alert! The Bell Labs journal now requires submissions in *word*.

Re: [9fans] 9vx instability

[Francisco J Ballesteros]

You mean -1, don't you?

On Thu, Nov 24, 2011 at 5:40 PM, Yaroslav yari...@gmail.com wrote:
 2011/11/22 Skip Tavakkolian skip.tavakkol...@gmail.com:
 because 9fans not only agree to disagree, they also disagree to agree :)

 +1

Re: [9fans] 9vx instability

[Francisco J Ballesteros]

I'm impressed by the work Geoff, and others do on Plan9, and I'm not
talking about 9front at all.
Jim, Charles, and others made an excellent port for amd64,
which is cleaner that any other system I've seen. We used that
as a starting point for nix.

I think is childish to fork a system because the code sent to maintainers
is either not desired or good enough or whatever. most of us have our
own set of changes and exchange them at will.

The good think in plan 9 has always been the quality of the system
and the quality of its code, and I'd like it to stay that way and thank
Geoff for keeping it that way.

Just look at files that change in sources.  it's impressive the
amount of work still ongoing in plan 9.

As said before in this list, if you want Linux, you know where to
find it. I'm sure the standard there is not that high.

On Thursday, November 24, 2011, erik quanstrom quans...@quanstro.net
wrote:
 This, to be honest, doesn't say much.
 However, recently I stumbled over this:
 http://www.sptechweb.com/content/article.aspx?ArticleID=35742print=true

 geoff did cwfs, and has done more to maintain the system
 than the rest of us put together.  he has my respect for that.

 thanks, geoff.

 - erik



-- 
ipad kbd. excuse typos.

Re: [9fans] 9vx instability

[Francisco J Ballesteros]

neither am I.
I was saying it would have been much better to see which
one was the problem with patches and address it.
have fun.

On Thursday, November 24, 2011, ron minnich rminn...@gmail.com wrote:
 Um, cinap, just FYI, I was not aiming at you or anyone else in
 particular. Sorry if it sounded that way.

 It's a holiday here, and not many other places, but still ... happy
 -day everyone!

 ron



-- 
ipad kbd. excuse typos.

Re: [9fans] Forks of Plan 9 (Was: 9vx instability)

[Francisco J Ballesteros]

I'd like to say here that I'm sorry if my mail in this thread
did hurt any feelings. That was not my aim, again.

I know all of us keep a local copy in one way or another,
but I'd like to suggest that all of us keep on sending patches and
code to bell labs; that's the least we can do, considering the
excellent code base those guys gave us in the first place.

Regarding the codereview suggestion, nix is already under
code review, and we intend it to be not just a research system, but
also a kernel that could be used as a 64bits plan 9 system. All of you
are more than welcome to send CLs there.

Also, we are trying to make our changes in a way that they could
help the stock distribution, which is, again, what I said would be
better than doing them in incompatible ways.

cheers

Re: [9fans] Returning to Plan 9: Virtualization, Distributions

[Francisco J Ballesteros]

But, if you want more than one core, be sure you
install the CL I sent (which has not yet been applied).

I'll commit it later today so you could get SMP without
applying any CL by hand.


 I use it as follows:
 hg clone http://googlecode.com/p/nix-os nix-os
 cd nix-os
 ./9vx.OSX10.6 -r . -u rminnich
 (get on the machine)
 objtype=386
 cd /sys/src/ape/lib
 mk install
 cd /sys/src
 objtype=amd64
 mk install
 cd /sys/src/nix/k10
 mk install

 You are then good to go, unless I missed a step. You need some 386
 bits from ape to build the 64-bit code.

 We've set up nix-os root file system to play nice with 9vx, which is
 why we include a 9vx for osx in the file system.

 so to repeat: nix-os is a mercurial image of a root file system for
 32-bit nodes, and it is intended to make it easy for you to boot
 64-bit nodes. We assumed that you had at least one 32-bit and one
 64-bit system.

 I hope this helps a little.

 ron

Re: [9fans] 9vx instability

[Francisco J Ballesteros]

funny, it's working like a rock here. just fine.
maybe I've been lucky.

On Mon, Nov 21, 2011 at 7:39 PM, ron minnich rminn...@gmail.com wrote:
 just normal usage, mk install and such in the nix release, and there
 are times that memory corruption happens. There's been a race in there
 forever, and sometimes you hit it, and things start to go south.

 ron

[9fans] iwp9

[Francisco J Ballesteros]

The proceedings can be found in the web page,
iwp9.org

Re: [9fans] thanks iwp9 organizers

[Francisco J Ballesteros]

I don't understand.
You were also organizing it :)


On Mon, Oct 24, 2011 at 5:05 PM, erik quanstrom
quans...@labs.coraid.com wrote:
 i just wanted to say thanks to the organizers for putting in all the work to
 make the conference a big success.

 - erik

[9fans] iwp9 WIP

[Francisco J Ballesteros]

Dear all,

the dealine for IWP9 WIP is here, but we encourage
everyone with WIP to submit to IWP9. We will still wait
a few days for WIP submissions.

hth

Re: [9fans] OT: how do 9fans backup their Mac(book)?

[Francisco J Ballesteros]

What I do is to consider the macs as volatile.
Very much like firmware.
All the stuff I care about is in our main file server.
I might either use my files using the octopus or just cache them in the local
disk of the mac when I need that.

To recover such firmware, yes, I use an external disk and time machine,
which is what the mac seems to like.


On Fri, Sep 30, 2011 at 5:19 PM, Axel Belinfante
axel.belinfa...@cs.utwente.nl wrote:
 Just curious what 9fans use, for home and/or work, to backup their macs.

 time machine?
 to a local (usb,firewire) disk?
 or remote (time capsule, nas (not officially sanctioned by apple))?

 or eat our own dog food and use eg. venti?
 or tra?

 or no backup necessary because everything important is already elsewhere?
 (in the cloud, or in a version management system)

 or?


 context: we are reconsidering how to do this at work,
 and prefer not to reinvent the wheel.

 (at home I just backup my mac to a readynas box using time machine).


 Sorry for the off-topic nature of this post, but the fact
 that 9fans will be aware of less-common solutions like venti -
 not to mention the presence of coraid people here -
 made me look for experience/expertise here.

 Regards,
 Axel.

[9fans] iwp9 camera ready deadline: oct 13rd.

[Francisco J Ballesteros]

Dear all,

this is to announce that, due to local logistics, the
camera ready deadline for iwp9 is now set to
October, 13rd. (That is, Thursday).

It was previously set to 14th, so it's one day before.

thanks

Re: [9fans] iwp9 2011 program

[Francisco J Ballesteros]

Don´t know by now.

On Fri, Sep 23, 2011 at 11:28 AM, Alexander Clouter a...@digriz.org.uk wrote:
 Francisco J Ballesteros n...@lsub.org wrote:

 This is the provisional program for IWP9 2011.
 It will be updated in the web site soon, but in the
 mean time, this is how it looks like.

 Possibly a silly question, but on the website I cannot see any reference
 to such.  Is this event going to be streamed online?

 Cheers

 --
 Alexander Clouter
 .sigmonster says: Baby On Board.

[9fans] iwp9 2011 program

[Francisco J Ballesteros]

Dear all,

This is the provisional program for IWP9 2011.
It will be updated in the web site soon, but in the
mean time, this is how it looks like.

Best regards

October 20th

11:00   Registration (and coffee)
11:50   Welcome + keynote
12:00   panel: news from new systems: osprey, inferno-ports, and nix
13:00   Lunch
14:00   tutorial: Sape Mullender: measuring performance
15:00   talk: From natural hazards to the outer space and to Plan 9
15:45   talk: Gostor: Storage beyond POSIX
16:30   coffee break
17:00   talk: Revisiting User-Level Networking
17:45   talk: Acid your ARM
18:30

October 21st

9:00   talk: FTP-like Streams for the 9P File Protocol
9:45   talk: To Stream Or Not To Stream
10:30   coffee break
11:00   WIP
13:00   lunch
14:00   hellaphone workshop
15:00   concluding remarks
16:00   coffee and goodbye

Re: [9fans] iwp9 2011 program

[Francisco J Ballesteros]

I'm sorry. A jtag workshop (also included in iwp9 2011) was
missing from the program I sent. This is the correct one.
The one in the web will be updated soon.

11:00   Registration (and coffee)
11:50   Welcome + keynote
12:00   panel: news from new systems: osprey, inferno-ports, and nix
13:00   Lunch
14:00   tutorial: Sape Mullender: measuring performance
15:00   talk: From natural hazards to the outer space and to Plan 9
15:45   talk: Gostor: Storage beyond POSIX
16:30   coffee break
17:00   talk: Revisiting User-Level Networking
17:45   talk: Acid your ARM
18:30

9:00   talk: FTP-like Streams for the 9P File Protocol
9:45   talk: To Stream Or Not To Stream
10:30   coffee break
11:00   WIP
13:00   lunch
14:00   hellaphone workshop
15:00   jtag workshop
16:00   coffee break
16:30   concluding remarks

Apologies for the mistake.

[9fans] C beautifier

[Francisco J Ballesteros]

Hi,

anyone is using a C beautifier in Plan 9?
I mean, other than gnu indent, which I tried and does not
work quite right for me.

thanks

Re: [9fans] C beautifier

[Francisco J Ballesteros]

I'll have to learn to search and read man pages :)

thanks!

On Sun, Sep 18, 2011 at 8:15 PM, andrey mirtchovski
mirtchov...@gmail.com wrote:
 /386/bin/cb?

Re: [9fans] C beautifier

[Francisco J Ballesteros]

I was looking for something capable of unifying say

if(...){
}else{
}

and

if(...)
{
}
else
{
}

into a single style.
But it might do. thanks again.

On Sun, Sep 18, 2011 at 8:11 PM, erik quanstrom quans...@quanstro.net wrote:
 On Sun Sep 18 14:10:06 EDT 2011, n...@lsub.org wrote:
 Hi,

 anyone is using a C beautifier in Plan 9?
 I mean, other than gnu indent, which I tried and does not
 work quite right for me.

 cb has worked for me, even on windows code.

 - erik

Re: [9fans] C beautifier

[Francisco J Ballesteros]

As I said, I should learn to read man pages.
cb -s
was exactly what I was looking for.
thanks again.


On Sun, Sep 18, 2011 at 8:23 PM, Francisco J Ballesteros n...@lsub.org wrote:
 I was looking for something capable of unifying say

 if(...){
 }else{
 }

 and

 if(...)
 {
 }
 else
 {
 }

 into a single style.
 But it might do. thanks again.

 On Sun, Sep 18, 2011 at 8:11 PM, erik quanstrom quans...@quanstro.net wrote:
 On Sun Sep 18 14:10:06 EDT 2011, n...@lsub.org wrote:
 Hi,

 anyone is using a C beautifier in Plan 9?
 I mean, other than gnu indent, which I tried and does not
 work quite right for me.

 cb has worked for me, even on windows code.

 - erik

Re: [9fans] C beautifier

[Francisco J Ballesteros]

Somehow indent has indented wrong some ifs
(the code in the body is at the same tab level than the if).
Perhaps I made a mistake. I'm not saying it doesn't work
(I'm sorry if I did).

but cb was just fine.



On Sun, Sep 18, 2011 at 10:01 PM, Steve Simon st...@quintile.net wrote:
 I have an indent port in my contrib (though you say you don't like it),
 and plan9 has cb(1).

 what don't you like about indent?

 I use it with erik's bcmt which replaces c++ style comments with C ones,
 a carfully tailored proto file, and this: sed 's/\) {/){/
 .

 This gives me pretty much plan9-style code (assuming nix-style is plan9-style
 and has not evolved).

 -Steve

Re: [9fans] gar nix!

[Francisco J Ballesteros]

I agree, but I think it's ok if we use them only if we have them, and rely on
just 2M otherwise.

On Fri, Sep 16, 2011 at 5:28 PM, ron minnich rminn...@gmail.com wrote:
 On Fri, Sep 16, 2011 at 7:57 AM, erik quanstrom
 quans...@labs.coraid.com wrote:

 please don't make it required.  there's already array of page sizes per mach.

 sorry, but time moves forward. We need the 1G pages for user mode
 anyway -- so the fact that you can run on older machines is a happy
 coincidence but it will die the first time you run a process that uses
 more than 1G. Reducing PTE count by 512 is a not insignificant cost. I
 expect to put the 1G pages for the kernel map back in in the next
 while.

 ron

Re: [9fans] gar nix!

[Francisco J Ballesteros]

What's the problem if you let the kernel work with 2m/1G
entries when you have them, and with just 2M entries with it doesnt?

Or perhaps your reply was not to my mail... or I'm confused :)

On Fri, Sep 16, 2011 at 5:33 PM, erik quanstrom
quans...@labs.coraid.com wrote:

 i would hate to have dogmatic rules like this limit cooperation.  i'm really
 excited about nix.  please don't kill the buzz off so quickly.

Re: [9fans] gar nix!

[Francisco J Ballesteros]

It's already there.
We can discuss this off-list

On Fri, Sep 16, 2011 at 5:44 PM, ron minnich rminn...@gmail.com wrote:
 OK, ok, I'm being unreasonable.

 If somebody will please write the cpuid function that returns 1 if GiB
 pages are supported and 0 if not, I'll do the rest next week.

 ron

Re: [9fans] gar nix!

[Francisco J Ballesteros]

That's what 1G pages are for.

On Fri, Sep 16, 2011 at 8:32 PM, erik quanstrom
quans...@labs.coraid.com wrote:
 On Fri Sep 16 14:26:53 EDT 2011, rminn...@gmail.com wrote:
 On Thu, Sep 15, 2011 at 11:46 PM, erik quanstrom quans...@quanstro.net 
 wrote:
 
 
  (can't one just preemptively map the whole text on first-fault?)

 we actually do if it's 2M pages :-)

 ghostscript, too?

 :-)

 - erik

Re: [9fans] NIX 64-bit kernel is available

[Francisco J Ballesteros]

Ok. If you check out the release tag from nix-os.googlecode.com it
should be ok and compile and work fine. I just checked.

We are sorry we didn't tell before.
From now on we'll tag as release the last release we are happy with.

hth

Re: [9fans] NIX 64-bit kernel is available

[Francisco J Ballesteros]

Perhaps you checked out an old version?
I just checked and there's a $nixroot/BUILDING_AMD64 file,
provided you did the check out at $nixroot.

This is what the file has:
cd /sys/src
objtype=386
mk libs
cd ape/lib
mk install
cd /sys/src
objtype=amd64
mk install


BTW, for building the nix kernel just go to /sys/src/nix
and mk. It will require amd64 binaries and libraries at /amd64.

hth

Re: [9fans] NIX 64-bit kernel is available

[Francisco J Ballesteros]

Let's make a deal.
Anyone who writes something can give it a name. :)

Re: [9fans] NIX 64-bit kernel is available

[Francisco J Ballesteros]

I could run old binaries. Perhaps profiling no longer works for them,
didn't even try.
Either way, we had no choice. We had to put some stuff in there.

Re: [9fans] NIX 64-bit kernel is available

[Francisco J Ballesteros]

In the experiments I made I was sending all results through shared memory
(a pointer to the reply).
But I don't think that code is in the main rep.

On Thu, Sep 15, 2011 at 4:13 PM, erik quanstrom
quans...@labs.coraid.com wrote:
 On Thu Sep 15 10:04:54 EDT 2011, n...@lsub.org wrote:
 I could run old binaries. Perhaps profiling no longer works for them,
 didn't even try.
 Either way, we had no choice. We had to put some stuff in there.

 i wasn't complaining.  i just wanted to make sure.  also, for the
 nixcalls, where does the error string memory go?

 - erik

Re: [9fans] NIX 64-bit kernel is available

[Francisco J Ballesteros]

futexes do not promise to behave like actual semaphores the last
time I checked them out.

These ones do. But the main difference is not that. They come with
a semalt() op that tries to do a down at the same time on a set of semaphores.

So, if you model tubes (nix channels) as a regular producer-consumer with
two semaphores (one for holes one for messages), you can alt them by
relying on semalt. If you are lucky, you don´t enter the kernel. If you are not,
you do, but at least you get the semantics you´d expect for a semaphore.

On Wed, Sep 14, 2011 at 7:32 PM, David Leimbach leim...@gmail.com wrote:


 - Optimistic semaphores, a new type of semaphore which lives half in
 and half out of the kernel, and which in many cases will never run in
 kernel

 How is this both like and not like a futex?

Re: [9fans] NIX 64-bit kernel is available

[Francisco J Ballesteros]

On Wed, Sep 14, 2011 at 9:22 PM, Bakul Shah ba...@bitblocks.com wrote:
 So you use both 2MB and 1GB PTEs?

Yes.

 - Tubes, a new IPC mechanism like pipes that uses the optimistic semaphores

 Tubes in memory of Sen Ted Stevens?

No. In the memory of regular standard tubes. But yes,
there's a comment about that in the source.

 You'll need a 9vx setup to start.
 Checkout the tree, and run 9vx with the tree as your root. You'll find a file
 called BUILDING_AMD64 with further instructions in the root.

 No such file.

I'll leave that to ron :)

Re: [9fans] NIX 64-bit kernel is available

[Francisco J Ballesteros]

Yes, IX was already taken for a file system protocol.

On Wed, Sep 14, 2011 at 10:38 PM, s s leonardne...@gmail.com wrote:
 Are you sure you want to call it NIX, though?