[9fans] Fonts

[Devon H. O';Dell]

I have very little idea about these fuckers. I know there are
baselines and ideas about m's and n's and kerning and whatnot.

But how do you make them? I played with some TTF font generators about
10 years ago that I'm sure I illegally obtained somehow, but I realize
that I have zero idea of how fonts are designed and packaged. Does
anybody know anything about how fonts are created and packaged (info
on subfonts would be great, info on TTF would be interesting).

--dho

Re: [9fans] Google finally announces their lightweight OS

[Devon H. O';Dell]

2009/7/8 erik quanstrom :
>> But don't underestimate the value of the interesting ideas in the
>> linux kernel that get the performance, e.g. RCU. I don't think there
>> are any OSes that have scaled to 4096 CPUs at this point besides
>> Linux.
>
> i thought that massively parallel harvard-arch machines had
> generally fallen out of favor in favor of blue gene-style hardware.
>
> is this incorrect?

I think it depends on the application. I have a friend who studies
fluid dynamics for scramjets and he was mentioning how doing some of
those calculations requires ultra-low latency. The algorithms they
need to use require multiple passes, and each calculation is affected
by surrounding `blocks.' With infiniband and whatnot, this might be
moot (he's doing his stuff on 32-core systems right now, so it's not
even to that degree), but perhaps there are still applications that
still significantly benefit from that architecture. They are quite the
opposite of `embarrassingly parallel' problems (a la distributed.net /
SETI / Folding).

That said, I have no idea what the performance / latency
characteristics are of a system with 32 cores and 32 CPUs connected
with infiniband / some other proprietary high speed interconnect, or
what that would look like performance-wise if it was scaled to 4096
cores versus quad-CPU boards with interconnects.

> - erik

-dho

Re: [9fans] Google finally announces their lightweight OS

[Devon H. O';Dell]

2009/7/8 erik quanstrom :
>> I'd love to do this, but I don't think anybody's going to
>> match my salary to port drivers, do ACPI, add amd64 support for
>> workstations, etc.
>
> i told myself this for years.  it turns out to be a mistaken
> idea.  now that i know, i regret the years i spent doing
> other things.

I certainly don't know anybody who is hiring people to do this sort of
work in Plan 9.

> - erik

--me

Re: [9fans] Google finally announces their lightweight OS

[Devon H. O';Dell]

2009/7/8 Uriel :
> On Wed, Jul 8, 2009 at 6:56 PM, Devon H. O'Dell wrote:
>> I don't think so. We already have IPv6 support and it's not that bad.
>> Having more drivers and supported commodity architectures would be a
>> good thing. I'd love to do this, but I don't think anybody's going to
>> match my salary to port drivers, do ACPI, add amd64 support for
>> workstations, etc.
>
> ACPI will never, ever, ever happen, so people better get over it (and
> if anyone is naive enough to waste their time trying, it will end up
> as a useless atrocious mess that wont boot even in a 100th of the
> systems out there, much less suspend or do anything useful).

ACPI support doesn't need to suspend or do thermal zones. It just
needs to be able to read the ADT and get MP / interrupt routing table
information. This is doable. Have you ever read any of the ACPI spec?
I have.

> As for amd64, it is already done, we are just not worthy to have access to it.

Without this getting into a holy war, what Geoff told me was that the
amd64 work was for headless CPU servers, which is only mildly useful
to me anyway.

> uriel
>
>

Re: [9fans] Google finally announces their lightweight OS

[Devon H. O';Dell]

2009/7/8 Uriel :
> On Wed, Jul 8, 2009 at 9:56 PM, Devon H. O'Dell wrote:
>> ACPI support doesn't need to suspend or do thermal zones. It just
>> needs to be able to read the ADT and get MP / interrupt routing table
>> information. This is doable. Have you ever read any of the ACPI spec?
>> I have.
>
> The spec doesn't matter much, given that most BIOS out there totally ignore 
> it.

I think you're unfamiliar with the spec as it relates to what I mentioned.

--dho

Re: [9fans] Google finally announces their lightweight OS

[Devon H. O';Dell]

2009/7/8 Benjamin Huntsman :
>>> Without this getting into a holy war, what Geoff told me was that the
>>> amd64 work was for headless CPU servers, which is only mildly useful
>>> to me anyway.
>>
>>If it was released perhaps somebody would add the missing drivers, who 
>>knows...
>>
>>As things stand, we will never know.
>
> Speaking of the amd64 port, I had thought that Bell Labs was planning on 
> releasing it at some point in the future, but that it currently wasn't quite 
> perfect and they didn't want to have to field complaints...  I can't say that 
> I blame them...

My understanding from Geoff was exactly this. But I don't want to
speak for him or introduce this as fact. I'm unaware of the exact
status at this particular time.

> But, it would be nice to see eventually.  Are there plans to let the amd64 
> port out of the labs at some point in the future?

Agreed.

> Many thanks!
>
> -Ben

Before my signature, I'd really like to reiterate that I did not bring
up amd64 to open a can of worms.

-dho

Re: [9fans] Google finally announces their lightweight OS

[Devon H. O';Dell]

2009/7/8 Francisco J Ballesteros :
>>
>> ACPI will never, ever, ever happen, so people better get over it (and
>> if anyone is naive enough to waste their time trying, it will end up
>> as a useless atrocious mess that wont boot even in a 100th of the
>> systems out there, much less suspend or do anything useful).
>>
>
> I've been  wasting time on acpi, and will do waste more time soon.

Another person in Plan 9 has been working on an AML interpreter that
presents the ADT in a filesystem (at least, that was what I envisioned
and explained to him). I believe he has also contacted you regarding
some USB ethernet device, so perhaps you two will want to work
together to some point? If I can be of any use as well, let me know.
I've got a small bit of experience with ACPI (fixing some issues in
FreeBSD's acpica support for Intel Blades).

> ISNT __IT _FUN?
>
> sorry, this is just a case convention I've recently seen
> and I love it.

It's certainly fun from a WTF were they thinking perspective. Hardware
engineers are rarely amazing programmers.

> BTW, useless, who knows; but atrocious?, the interpreter is pretty.
> but what could I say about it?

--dho

Re: [9fans] Google finally announces their lightweight OS

[Devon H. O';Dell]

We all know that Uriel periodically `whines' on this list. Let's
please not exacerbate the situation?

[9fans] Plan 9 Jobs

[Devon H. O';Dell]

In light of Erik's response ``maybe you just don't know about them.'' I looked.

http://sfbay.craigslist.org/pen/sof/1243139762.html

Recent (posted 6/27). Looks like it's Plan 9 (probably Inferno) on a
smartphone. Thought it would be useful to post here in case anybody
else is looking for that kind of thing. That said, I couldn't find
anything about Coraid openings, so I suspect Erik wasn't tooting his
own horn :)

I've always thought it would be cool to see what Plan 9-based phones
could do on a cellular network.

Would be nice to see any / all of these sorts of things appear on this
list. We get more people on it every year.

I also recall Ron posting some stuff years ago when I was in Holland
that I was potentially interested in, however, I don't have a degree
and the gov't work he does wouldn't be able to hire me to do anything
useful based on my skillset due to their policy. I dunno if Sandia's
the same way, but I'd suspect so.

--dho

Re: [9fans] Google finally announces their lightweight OS

[Devon H. O';Dell]

2009/7/9 Micah Stetson :
>> Why would it take a book?  DMR made the point succinctly in his
>> critique of Knuth's literate program, showing how a few command-line
>> utilities do the work of the Don's elaborately constructed tries.
>
> Do you have a URL for this?

I looked this up yesterday, and there is some discussion on
literateprogramming.com -- the discussion actually illustrates how to
take the shell script and make *it* literate programming instead. It
actually wasn't DMR, it was McIlroy.

> Micah

--dho

Re: [9fans] Plan9 as an everyday OS

[Devon H. O';Dell]

2009/7/10 J.R. Mauro :
> On Fri, Jul 10, 2009 at 1:46 PM,  wrote:
>>
>> I'm tired of the perpetual September, after several years of being
>> polite and pointing people to the wiki and the archives.
>
> You could filter instead of bitching and contributing to the noise.

Spoken like a true hypocrite ;)

--dho

Re: [9fans] ide fix?

[Devon H. O';Dell]

2009/7/13 erik quanstrom :
> after a week of fighting with an atom with ich7r sata in
> ide mode, i finally found the secret sauce that keeps it
> from "hanging."  i pushed out a changed
> quanstro/9load-e820 and quanstro/sd which boot on my
> atom machine in ide mode without causing interrupt storms.
> other changes were included work around ahci power quirks
> for this chipset, if your bios supports it, i would recommend
> ahci mode.  i also pushed out a version of ether8169 as
> quanstro/8169 that supports the particular 8169 macs that
> are in my atom machine (and jumbo frames).
>
> i have a feeling that these changes may be helpful in
> correcting other intel ich-based ide problems.  i've got
> an intel ich6-based machine that has exhibited similar
> symptoms at work that i hope to test tomorrow.
>
> i'll be interested to hear if these changes work for
> other people.
>
> - erik

This sounds promising for that ICH laptop with the 320G drive that
magically doesn't work (though the 120GB one that was in it was fine).
How do I get this on a disc to try it out?

--dho

Re: [9fans] ide fix?

[Devon H. O';Dell]

2009/7/13 erik quanstrom :
>> This sounds promising for that ICH laptop with the 320G drive that
>> magically doesn't work (though the 120GB one that was in it was fine).
>> How do I get this on a disc to try it out?
>
> can you pxe?

Not easily. The issue was a few bits in PCI register space that we
weren't entirely sure what they were for but you suspected that they
needed to be set up differently for some AHCI power management bits or
something like that.

--dho

> - erik
>
>

Re: [9fans] v9fs question

[Devon H. O';Dell]

I believe Priyanka has some significant work on getting private
per-process namespaces in Glendix for this year's GSoC.

--dho

Re: [9fans] Plan9 as an everyday OS

[Devon H. O';Dell]

2009/7/14 erik quanstrom :
> On Tue Jul 14 02:41:02 EDT 2009, sqw...@gmail.com wrote:
>>  I suspect the main inhibitor there is that (as I recall) it stomps
>> all over the existing soundblaster code. These days AC97 is probably
>> more desirable, but it would be nice to have them coexist.
>
> that's going to require thinking out how ac97 can provide a strict
> superset of sb.  as a first step, it would make sense for ac97 to
> bring it's own implementation of #A to the party.
>
> there are other sound models, it would be nice to design ac97's
> interface in such a way that it can work with other sound models.

Particularly Intel HDA (which supercedes AC97 and is what all new
machines are being shipped with now, essentially) and the various
chipset codecs on top of that. Plenty of BSDLed code on them and
plenty of documentation too.

--dho

> - erik
>
>

Re: [9fans] Plan9 as an everyday OS

[Devon H. O';Dell]

2009/7/14 Tim Newsham :
>> However, I still think this is worthwhile just to provide (a) a
>> standard interface for audio devices (e.g., /dev/audioctl always
>> accepts the same messages to set volume, input levels, etc), and (b)
>> to have a single kernel support more than one type of audio device
>> (imagine a network where you actually have an SB16 plus a bunch of
>> AC97 devices and some of these HCI things that Devon mentioned-one 9pc
>> should be able to support them all).
>
> I was looking at audio interfaces a little lately and
> I noticed that inferno's audio device uses different
> conventions and seems to be more complete.  It might
> be worthwhile to shoot for an interface like that.

Several years ago, Kris and I were working on a mixerfs. Neither of us
were terribly familiar with digital audio at the time, and it never
ended up working entirely properly (read: multiple channels got
choppy), but if anybody is interested in the code, I still have it.

--dho

>>       - Dan C.
>
> Tim Newsham
> http://www.thenewsh.com/~newsham/
>
>

Re: [9fans] Why does Acme only show text?

[Devon H. O';Dell]

2009/7/15 erik quanstrom :
>> It's
>> a lot easier to see (and not have in the first place) incorrect scope
>> and continuation with whitespace than with braces or parentheses.
>
> do you have a reference for this claim?

Without turning this into a holy war, I really always see these issues
as a matter of personal preference. This is why editors are so bloated
and languages have weird conventions.

On that note, my personal experience has found it to be a lot easier
to find and correct scope issues in Python than it has to find missing
braces or semicolons in other languages, sometimes even with matching
enabled. This usually is the case for awful spaghetti-ish code.

But I digress.

--dho

Re: [9fans] Race condition in /sys/src/9/pc/trap.c?

[Devon H. O';Dell]

2009/7/31 erik quanstrom :
>> process1:
>>       still in kernel:
>>               memmove(buf, ...)
>>               *fault*
>>               trap()
>>                       fault386()
>>                               fault() => -1
>>                               if(!user){
>>                                       panic()
>>                                       *panic*
>>                               }
>>                               ...
>>                               postnote()
>
> could you be more specific.  what is your test program,
> where is it crashing (if you know), and what is the panic
> message, if any?  i must be dense, but i'm confused by
> your process diagram.

He posted it earlier in this thread

--dho

> - erik
>
>

Re: [9fans] Race condition in /sys/src/9/pc/trap.c?

[Devon H. O';Dell]

2009/7/31 erik quanstrom :
>> > could you be more specific.  what is your test program,
>> > where is it crashing (if you know), and what is the panic
>> > message, if any?  i must be dense, but i'm confused by
>> > your process diagram.
>>
>> He posted it earlier in this thread
>>
>> --dho
>
> please post a reference.  i do not see either the crash
> code or the panic message on 9fans.net/archive/2009/07.
> i don't recall it in the originals, either.
>
> - erik

Was received as an attachment. Inline:

#include 
#include 

void
main(int argc, char **argv)
{
char *buf;
int fd;

if((fd = open("/dev/zero", OREAD)) < 0)
sysfatal("open");

buf = (char*)0x60;
segattach(0, "memory", buf, 2*4096);

switch(rfork(RFPROC|RFMEM)){
case -1:
sysfatal("fork");
break;
case 0:
for(;;){
read(fd, buf+4096, 4096);
}
}
sleep(1000);
segbrk(buf, buf+4096);
}

--dho

Re: [9fans] just an idea (Splashtop like)

[Devon H. O';Dell]

2009/8/2 erik quanstrom :
> http://www.pcworld.com/article/143558/laptop_flash_drives_hit_by_high_failure_rates.html
>
> surprising, no?  there are still plenty of reasons to want an
> ssd.  it just seems that reliablity isn't one of those reasons yet.

The big one for me has always been that I tend to drop the sort of
machines while they're running. Does a lot to the MTBF for standard
drives... not so much for SSD.

--dho

> - erik
>
>

Re: [9fans] audio standards -- too many to choose from

[Devon H. O';Dell]

2009/8/13 erik quanstrom :
> On Thu Aug 13 02:43:54 EDT 2009, 9...@9netics.com wrote:
>> > I'm not sure either latency or RT is proper terminology here. But
>> > I believe what I meant was clear: when you need overall latency
>> > to be around 5ms you start to notice 9P.
>
> when you need the overall latency to be around 5ms,
> aren't you need a suitable network?  (or none at all)

When you're doing audio work, latency is an issue on playback when
you're playing with a recording. 5ms is acceptable, but getting much
higher is not. However, one of the other key points is that a
consistent latency is important. 50ms might be fine for playback with
video if it's a constant 50ms, but if you start drifting +- 10ms,
things can get wonky pretty quickly. This is easily demonstrable with
rhythm games (such as Rock Band or Guitar Hero) where latency induced
by a home audio system (mine at home is about 15ms induced by my
receiver and 5ms using the Xbox digital output) can have a very
significant negative impact on gameplay when one plays primarily by
sound. (Sound cues are easier to keep beat by than visual).

--dho

Re: [9fans] audio standards -- too many to choose from

[Devon H. O';Dell]

2009/8/13 Anthony Sorace :
> Devon H. O'Dell wrote:
> // This is easily demonstrable with rhythm games (such as Rock
> // Band or Guitar Hero) where latency induced by a home audio
> // system (mine at home is about 15ms induced by my receiver
> // and 5ms using the Xbox digital output) can have a very
> // significant negative impact on gameplay when one plays
> // primarily by sound.
>
> It's worth noting that the differences injected by typical home
> components are significant enough that, at least in all the
> versions of these games I've played, the designers have built in
> a way for you to calibrate the audio against the video.

Indeed. Early versions of the game only allowed you to do audio lag
calibration and made no video compensation (see: Guitar Hero 1 and 2;
Guitar Hero 3; Rock Band was the first to introduce both). This ended
up making the game even harder, because the gameplay is really a
combination of audio and video cues.

> // (Sound cues are easier to keep beat by than visual).
>
> The Rock and Roll Hall of Fame has a Guitar Hero set up in the
> lobby, but you need to bring your own headphones. I didn't have
> any on me, so tried playing by sight only. It went really poorly.

Even though I'm fairly adept at these games (probably top 100ish on
drums and I used to be top 50 on guitar; I'm much worse at that now),
playing on mute is noticeably more difficult. A good friend of mine
who was #1 on guitar for quite some time was able to do it almost
effortlessly, though. If you can keep time well, it's easy. However,
that assumes no video latency. If there is video latency, it sucks.

--dho

Re: [9fans] Plan 9 hg with private repositories

[Devon H. O';Dell]

2009/8/13 David Leimbach :
> On Thu, Aug 13, 2009 at 2:47 AM, Ethan Grammatikidis 
> wrote:
>>
>> On Thu, 13 Aug 2009 11:13:58 +0200
>> Bela Valek  wrote:
>>
>> > Correct me if I am wrong, but an sshv2 server is also providing sshv1
>> > too.
>>
>> I vaguely remember reading that some ssh software would refuse to work
>> with ssh v1 by default because v1 is so insecure.
>
> Many times you must turn v1 on, but it's available.  It's off by default due
> to it being insecure.

If I"m recalling correctly, SSHv1 is insecure only if the remote server is
untrusted. Or am I not recalling correctly?

--dho

>> --
>> Ethan Grammatikidis
>>
>> Those who are slower at parsing information must
>> necessarily be faster at problem-solving.
>>
>
>

Re: [9fans] audio standards -- too many to choose from

[Devon H. O';Dell]

2009/8/12 Tim Newsham :
 - What software exists for each of these formats?
>>
>> If you are asking about non Plan9 software I'd start with
>> ffmpeg.
>>
 - Which format is the most "popular"?
>>
>> I don't think I understand the question.
>
> Sorry, let me rephrase:
>  - Of the different audio driver interface designs
>    (audio(3), usb(4) and inferno usb(3)) which software
>    (p9 and limbo) uses each?
>  - Which of these interfaces is used the most?

I don't know which is used the most, but I don't think the Plan 9 ones
of them make particularly good sense to support multiple input formats
to multiple output formats. sox was mentioned here recently, and is a
great utility for doing the conversion. If we want a generic, reusable
audio layer, to *me* the Inferno one is best with:

audio
audioctl

It doesn't make sense to export files for volumes, codes, channels,
and other settings to me. This is because (at least with HDA cards)
you would end up with 5 bajillion files for controlling volume on each
individual channel. You'd end up with another file for reading/writing
codec settings. You'd end up with a file saying whether you preferred
digital output or analog output.

OSS relies heavily on ioctls for setting these things, but for good
reason. In our case, a standardized set of strings for the ctl file
seems best to me. If I want to change master volume, echo master
255.255 > /dev/audioctl. If I want to set digital out, echo output
channel digital > /dev/audioctl. etc. A more spread out filesystem
would make the ctl handler smaller, but would not reduce the amount of
code needed to support mixers / codecs / channels / whatnot (In fact,
you'd just have more code because you'd have to have functions for
reading/writing those files). Also, then you just need to come up with
strings -- you're just bit frobbing these things, and more complicated
filesystem hierarchy doesn't help explain it any better. echo 255 >
/dev/audio/mixer/channel/master/right; echo 255 >
/dev/audio/mixer/channel/master/left; just seems obtuse, and, as I
said, it's just adding more redundant code anyway.

To then play sound, you would probably have a sox-like converter
sitting on top of that (maybe even on top of /dev/audio?) that takes
input of a certain format and does either minimal conversion (i.e. a
card that supports XA ADPCM taking input from a playstation 2 sound
file not having any conversion at all, WAV going to the proper
byte-order PCM with the header stripped off, etc), or highest
resolution audio available (e.g. 5.1 flac getting converted to
whatever codec supports 5.1 audio).

Thoughts?

--dho

Re: [9fans] audio standards -- too many to choose from

[Devon H. O';Dell]

2009/8/13 James Tomaschke :
> erik quanstrom wrote:
>
>>> I don't see the complexity, the interface merely needs to allow device
>>> drivers to provide the information such as "I support x y z", the
>>> application can query a "features" file, select a format and write back
>>> through the interface configuring the hardware.  The interface need not
>>> have any predetermined knowledge of available formats.  The only issue
>>> would be for each device driver to agree to call the same format by the
>>> same name, "s8 s16le s24be".
>>
>> i think you're ignoring the complexity.  suppose we wish to
>> support 10 formats.  suppose that i have devices that support
>> all 10 formats.  then there are 90 different conversions to do
>> to fill in the gaps.  now suppose that we pick a format.  then
>> we need to write 10 conversions.  also each driver potentially
>> needs 1 conversion.  if we want to write things like audio
>> mixers or whatnot in software, we only need to support 1 input
>> and 1 output format.
> It's a matter of kernelspace vs userspace and freedom.
>
> Nothing I have proposed prevents you from using a single format.
> Nothing I have proposed requires you to implement N formats or
> conversions.  This is because I allow for your freedom to do so in
> userspace.
>
> Rather, your suggestion of forcing a single format, prevents my
> applications from using other formats, and it requires I implement
> conversions.  This is because you limit freedom by placing a simple
> interface into kernelspace.

This is the silliest thing I've seen posted in this thread. No offense
intended, but if you choose the highest available sample size and bit
rate available to the card, you are not limiting anybody: the
limitation becomes the hardware. If that's an issue, get really
ridiculously high quality analog devices, and stop being so anal about
your perfect ears.

--dho

Re: [9fans] audio standards -- too many to choose from

[Devon H. O';Dell]

2009/8/13 Devon H. O'Dell :
> 2009/8/13 James Tomaschke :
>> Rather, your suggestion of forcing a single format, prevents my
>> applications from using other formats, and it requires I implement
>> conversions.  This is because you limit freedom by placing a simple
>> interface into kernelspace.
>
> This is the silliest thing I've seen posted in this thread. No offense
> intended, but if you choose the highest available sample size and bit
> rate available to the card, you are not limiting anybody: the
> limitation becomes the hardware. If that's an issue, get really
> ridiculously high quality analog devices, and stop being so anal about
> your perfect ears.

And if this is a problem for the processor, resample to the highest
input or output format provided. If that's an issue, don't mix so much
at once, or get newer hardware or buy a mixer :)

--dho

Re: [9fans] audio standards -- too many to choose from

[Devon H. O';Dell]

2009/8/13 James Tomaschke :
> Devon H. O'Dell wrote:
>> 2009/8/13 James Tomaschke :
>>> Rather, your suggestion of forcing a single format, prevents my
>>> applications from using other formats, and it requires I implement
>>> conversions.  This is because you limit freedom by placing a simple
>>> interface into kernelspace.
>>
>> This is the silliest thing I've seen posted in this thread. No offense
>> intended, but if you choose the highest available sample size and bit
>> rate available to the card, you are not limiting anybody: the
>> limitation becomes the hardware. If that's an issue, get really
>> ridiculously high quality analog devices, and stop being so anal about
>> your perfect ears.
>
> How can an application select a higher sample size if the interface to
> the driver only supports signed 16-bit samples?

You're distorting what I'm saying. You choose the highest sample size
local to the card. If you have a 2...@96khz file, and your card only
supports playback at 1...@44.1, you resample to 1...@44.1. If your card
supports 2...@96, and you're playing 1...@44.1, you don't resample at all,
because it makes no sense. I don't see what's so difficult about this.

> "the limitation becomes the hardware"
> Music App 24...@192khz -> #audio 16bit -> Hardware 24...@192khz.

I think you misunderstand.

#A bit/sample limited by hardware

If hardware is 2...@192, #A is 2...@192, unless what you're playing is
lower than that, in which case upconverting makes no sense.

I really don't understand why this isn't obvious. We're all smart
here, why would you think we would suggest something that dumb?

--dho

Re: [9fans] audio standards -- too many to choose from

[Devon H. O';Dell]

This is starting to remind me of two things:

1) The case where this guy did a review of two different audio
processors, and labeled the DAC of one as inferior to the other. He
posted audio files of the resulting output from one and the other.
Except he posted the exact same link for both of them. People
commented about how right he was, after allegedly listening to both
files. They were the same file. I'm an audiophile, but I know when to
quit.

2) A la Tim Newsham and Federico Benavento, less talk more code. I
have a mixerfs implementation from several years ago that Kris and I
worked on. I'll fix it up once I get AC'97 on my laptop to demonstrate
what I mean mixer-wise. Tim said he was working on an interface that
resembles what I've discussed publicly here.

This leads to:

3) James, if you don't like it, make your own, and kick our asses.

--dho

Re: [9fans] audio standards -- too many to choose from

[Devon H. O';Dell]

2009/8/14 James Tomaschke :
> Devon H. O'Dell wrote:
>> If hardware is 2...@192, #A is 2...@192
>
> I am not aware that #A allows for 24bit samples, I only see an option
> "speed" to set sampling rates.  The man page says: "Each sample is a 16
> bit little-endian two's complement integer".
>
> I was only going by what the manpage said, perhaps it's out of date.

Aha, this is where the misunderstanding comes in. We are talking about
a theoretical new interface to #A that can be created, not what exists
currently. I think we are all in agreement that #A needs changing to
move forward with modern hardware.

--dho

Re: [9fans] vga and vmware

[Devon H. O';Dell]

2009/8/16 Tim Newsham :
> When booting plan9 in vmware the graphics seem to work fine up
> to 1024x768x8, but higher resolutions cause a panic trying to
> write to a non-existant address.  (Didnt map enough memory for
> the screen maybe?)  It seems to put the card in the right mode
> and even print out the stack trace onto the highres screen.
> Anyone know whats going on here?

For what it's worth, I'm getting essentially the same in ESXi with
anything over 640x480x8

--dho

[9fans] Issues with 2 networks, fs server, and namespaces

[Devon H. O';Dell]

Hello all,

I'm trying to set up a group of servers (these are running on VMWare
ESXi, and working great -- CPU server running with two APs, though
adding more causes it to fault with a divide by zero?). Auth server's
got its own 1GB fossil, boots with the 9pcauth kernel. CPU server
boots from a small fossil. Both Auth and CPU are on the public
internet via ether0 so that they are cpu/drawtermable. They do not
boot from the file server because I didn't want to set up a DHCP
server that was connected to the Internet (ISP getting mad and
whatnot). While I've configured the internal network to be on it's own
vswitch (managed through vmware, no real network connectivity), I've
been struggling with the prior configuration enough that I don't want
to just `give up' on it.

The FS, however, sits on a private network. CPU and Auth are connected
to this network via ether1. However, I'm having the following issues:

#1) Using two networks on two different interfaces is a pain in the
ass. I've got:
bind '#l1' /net.alt
bind '#I1' /net.alt

in my /cfg/cpu/namespace. If I simply have them here, ip/ipconfig -N
-x ether1 ether /net.alt/ether1 complains in cpurc about no ip being
attached to /net.alt. So I have to put that in /cfg/cpu/cpurc also. I
don't quite understand why everything's architected to have a single
ip stack on a single ethernet; in this case, it really isn't
convenient that it doesn't determine the correct interface via routing
tables or somesuch. Is there something basic that I'm missing here?

#2) Drawterm is taking forever and a day to connect and log in. It's
either an auth issue or a DNS issue. Best guesses as to what this
could be and how I should go about diagnosing it?

#3) Trying to mount the fileserver globally is elusive. I want to
mount /n/fs/usr over /usr and /n/fs/mail over /mail. Perfectly happy
with that. However:

 o Doing that in cpurc doesn't put it in the global namespace
 o Doing it in /cfg/cpu/namespace doesn't have an ip yet so I can't
run srv /net.alt/tcp!10.0.0.3!9fs in the first place
 o Doing it in /rc/bin/service/tcp17010 causes me to get `cpu:
negotiating authentication method: [public auth server ip]: cs gave
empty translation list'

Mounting it from /n/fs after booting works fine (but it makes me auth,
which is kind of weird -- I guess I need to set up a secstore? -- I
figured that eve would be able to connect without auth, given that
everything's tied to the same auth server, no matter which network
it's on, and that a user drawterming in would be able to connect by
virtue of having authed when connecting in the first place.)

I know the `preferred way' is to boot the CPU server from the
fileserver. While I could feasibly reconfigure my setup to do this,
I'd prefer to figure it out this way first, given the amount of time
I've been banging my head against the wall on it :)

--dho

Re: [9fans] Issues with 2 networks, fs server, and namespaces

[Devon H. O';Dell]

2009/8/21 Devon H. O'Dell :
> 2009/8/21 Christopher Nielsen :
>> You don't need a second IP stack. You can run both interfaces on the
>> same IP stack and routing will just work. That's how I did it when I
>> had a similar setup.

Wait, I misread your explanation. Would you care to explain more about
that? Is that just binding '#l1' into /net?

--dho

Re: [9fans] Issues with 2 networks, fs server, and namespaces

[Devon H. O';Dell]

2009/8/21 Christopher Nielsen :
> You don't need a second IP stack. You can run both interfaces on the
> same IP stack and routing will just work. That's how I did it when I
> had a similar setup.

I do need a second IP stack because the other network is on another
switch on the other interface, and I do not particularly want to run a
private network over the vswitch hooked to the public internet.

--dho

> -Chris
>
> On Fri, Aug 21, 2009 at 14:07, Devon H. O'Dell wrote:
>> Hello all,
>>
>> I'm trying to set up a group of servers (these are running on VMWare
>> ESXi, and working great -- CPU server running with two APs, though
>> adding more causes it to fault with a divide by zero?). Auth server's
>> got its own 1GB fossil, boots with the 9pcauth kernel. CPU server
>> boots from a small fossil. Both Auth and CPU are on the public
>> internet via ether0 so that they are cpu/drawtermable. They do not
>> boot from the file server because I didn't want to set up a DHCP
>> server that was connected to the Internet (ISP getting mad and
>> whatnot). While I've configured the internal network to be on it's own
>> vswitch (managed through vmware, no real network connectivity), I've
>> been struggling with the prior configuration enough that I don't want
>> to just `give up' on it.
>>
>> The FS, however, sits on a private network. CPU and Auth are connected
>> to this network via ether1. However, I'm having the following issues:
>>
>> #1) Using two networks on two different interfaces is a pain in the
>> ass. I've got:
>> bind '#l1' /net.alt
>> bind '#I1' /net.alt
>>
>> in my /cfg/cpu/namespace. If I simply have them here, ip/ipconfig -N
>> -x ether1 ether /net.alt/ether1 complains in cpurc about no ip being
>> attached to /net.alt. So I have to put that in /cfg/cpu/cpurc also. I
>> don't quite understand why everything's architected to have a single
>> ip stack on a single ethernet; in this case, it really isn't
>> convenient that it doesn't determine the correct interface via routing
>> tables or somesuch. Is there something basic that I'm missing here?
>>
>> #2) Drawterm is taking forever and a day to connect and log in. It's
>> either an auth issue or a DNS issue. Best guesses as to what this
>> could be and how I should go about diagnosing it?
>>
>> #3) Trying to mount the fileserver globally is elusive. I want to
>> mount /n/fs/usr over /usr and /n/fs/mail over /mail. Perfectly happy
>> with that. However:
>>
>>  o Doing that in cpurc doesn't put it in the global namespace
>>  o Doing it in /cfg/cpu/namespace doesn't have an ip yet so I can't
>> run srv /net.alt/tcp!10.0.0.3!9fs in the first place
>>  o Doing it in /rc/bin/service/tcp17010 causes me to get `cpu:
>> negotiating authentication method: [public auth server ip]: cs gave
>> empty translation list'
>>
>> Mounting it from /n/fs after booting works fine (but it makes me auth,
>> which is kind of weird -- I guess I need to set up a secstore? -- I
>> figured that eve would be able to connect without auth, given that
>> everything's tied to the same auth server, no matter which network
>> it's on, and that a user drawterming in would be able to connect by
>> virtue of having authed when connecting in the first place.)
>>
>> I know the `preferred way' is to boot the CPU server from the
>> fileserver. While I could feasibly reconfigure my setup to do this,
>> I'd prefer to figure it out this way first, given the amount of time
>> I've been banging my head against the wall on it :)
>>
>> --dho
>>
>>
>
>
>
> --
> Christopher Nielsen
> "They who can give up essential liberty for temporary
> safety, deserve neither liberty nor safety." --Benjamin Franklin
>
>

Re: [9fans] Issues with 2 networks, fs server, and namespaces

[Devon H. O';Dell]

2009/8/21 Noah Evans :
> Hey Devon,
>
> 1. Others know more about that than I do. Wait a bit, that problem
> might get solved.

I think I brought that up because if anybody has ideas about fixing
them or making them better, I would like to do that.

> 2. drawterm tends to hang on secstore for me. Try a bogus -s option or
> use a p9p secstore/factotum and see what happens.

I'm not sure I have secstore set up. Perhaps that's it?

> 3. what's stopping you from setting up your external network as the
> one on /net.alt and using dhcp internally? Or booting tcp off the file
> server without dhcp? e.g. baking it into plan9.ini, or entering it
> manually at boot time? I've tried similar tricks to yours using
> inferno and getting cute and breaking the convention of /net.alt for
> external networks has always ended in a world of pain.

Tried to explain that. I just don't want to due to the number of hours
I've spent trying to configure it this way :). I think Christopher's
suggestion is what I'll do next; I totally forgot that was possible.

--dho

> Noah
>
> On Fri, Aug 21, 2009 at 11:07 PM, Devon H. O'Dell 
> wrote:
>> Hello all,
>>
>> I'm trying to set up a group of servers (these are running on VMWare
>> ESXi, and working great -- CPU server running with two APs, though
>> adding more causes it to fault with a divide by zero?). Auth server's
>> got its own 1GB fossil, boots with the 9pcauth kernel. CPU server
>> boots from a small fossil. Both Auth and CPU are on the public
>> internet via ether0 so that they are cpu/drawtermable. They do not
>> boot from the file server because I didn't want to set up a DHCP
>> server that was connected to the Internet (ISP getting mad and
>> whatnot). While I've configured the internal network to be on it's own
>> vswitch (managed through vmware, no real network connectivity), I've
>> been struggling with the prior configuration enough that I don't want
>> to just `give up' on it.
>>
>> The FS, however, sits on a private network. CPU and Auth are connected
>> to this network via ether1. However, I'm having the following issues:
>>
>> #1) Using two networks on two different interfaces is a pain in the
>> ass. I've got:
>> bind '#l1' /net.alt
>> bind '#I1' /net.alt
>>
>> in my /cfg/cpu/namespace. If I simply have them here, ip/ipconfig -N
>> -x ether1 ether /net.alt/ether1 complains in cpurc about no ip being
>> attached to /net.alt. So I have to put that in /cfg/cpu/cpurc also. I
>> don't quite understand why everything's architected to have a single
>> ip stack on a single ethernet; in this case, it really isn't
>> convenient that it doesn't determine the correct interface via routing
>> tables or somesuch. Is there something basic that I'm missing here?
>>
>> #2) Drawterm is taking forever and a day to connect and log in. It's
>> either an auth issue or a DNS issue. Best guesses as to what this
>> could be and how I should go about diagnosing it?
>>
>> #3) Trying to mount the fileserver globally is elusive. I want to
>> mount /n/fs/usr over /usr and /n/fs/mail over /mail. Perfectly happy
>> with that. However:
>>
>>  o Doing that in cpurc doesn't put it in the global namespace
>>  o Doing it in /cfg/cpu/namespace doesn't have an ip yet so I can't
>> run srv /net.alt/tcp!10.0.0.3!9fs in the first place
>>  o Doing it in /rc/bin/service/tcp17010 causes me to get `cpu:
>> negotiating authentication method: [public auth server ip]: cs gave
>> empty translation list'
>>
>> Mounting it from /n/fs after booting works fine (but it makes me auth,
>> which is kind of weird -- I guess I need to set up a secstore? -- I
>> figured that eve would be able to connect without auth, given that
>> everything's tied to the same auth server, no matter which network
>> it's on, and that a user drawterming in would be able to connect by
>> virtue of having authed when connecting in the first place.)
>>
>> I know the `preferred way' is to boot the CPU server from the
>> fileserver. While I could feasibly reconfigure my setup to do this,
>> I'd prefer to figure it out this way first, given the amount of time
>> I've been banging my head against the wall on it :)
>>
>> --dho
>>
>>
>
>

Re: [9fans] Issues with 2 networks, fs server, and namespaces

[Devon H. O';Dell]

Well, we're getting somewhere. Using /cfg/cpu/namespace still seems to
do nothing to get ether1 into /net. Putting it into cpurc does the
trick though, go figure.

However, I've got a new issue. When I go to mount the file server, I'm
getting this:

mount: auth_proxy: auth_proxy rpc write: p9...@int.9vx.org: no key
matches  proto=p9sk1 dom=int.9vx.org role=client user? !password?
mount: mount /n/fs: fossil authCheck: auth protocol not finished

I mentioned I wasn't sure that I'd set up secstore. I think I really
mean, ``I haven't set up secstore, and I'm not sure how" :)

Tips?

--dho

Re: [9fans] Issues with 2 networks, fs server, and namespaces

[Devon H. O';Dell]

And that's taken care of. Didn't have an authdom configured in
/lib/ndb/local, and for some reason, I forgot to set up keyfs on the
auth server. Thought I had that taken care of.

Of course, I'm now faced with another new issue. auth/debug looks like
it just tries to debug factotum keys. This machine has an interface on
9vx.org and another on int.9vx.org. However, auth/debug only tries to
debug 9vx.org, leading me to believe that factotum has no key for
int.9vx.org. Still getting that auth protocol not finished for
int.9vx.org, but I'm sure if I could get it to put that key in place,
everything would be great.

Ideas?

--dho

Re: [9fans] Issues with 2 networks, fs server, and namespaces

[Devon H. O';Dell]

2009/8/21 erik quanstrom :
> On Fri Aug 21 19:55:55 EDT 2009, devon.od...@gmail.com wrote:
>> Well, we're getting somewhere. Using /cfg/cpu/namespace still seems to
>> do nothing to get ether1 into /net. Putting it into cpurc does the
>> trick though, go figure.
>
> you need it in both places, as namespace doesn't apply to the console.

Aha. Ok.

It's working now. Turned out the fs had its authdom in nvram set to
the wrong domain. Oops.

Thanks all!

--dho

> - erik
>
>

[9fans] ndb/dns as a slave

[Devon H. O';Dell]

How do I designate ndb/dns to accept zone transfers from another one?
I have dnsslave set to the other machine in the `master zone file'
(for lack of a better term). The secondary server doesn't seem to
accept updates. (Or maybe the master isn't pushing them? Dunno.)

--dho

Re: [9fans] ndb/dns as a slave

[Devon H. O';Dell]

2009/8/22 Steve Simon :
> I assume your master DNS is served from bind, then you
> can use the zonefresh program in my contrib to build an
> ndb compatible ndb file for your local dns to serve.

Actually, I'm using ndb/dns for both. I seem to recall reading that
ndb supports zone transfers by looking for large packets in udp53 (or
something). I suppose if this isn't possible, periodically pulling
/lib/ndb/local from the other machine and sending refresh to /net/dns
could work. (Just kind of wondering what the standard procedure is :))

--dho

> -Steve
>
>

Re: [9fans] ndb/dns as a slave

[Devon H. O';Dell]

Also, I must be missing something about cname. The manpage suggests
that I simply add a line similar to:

cname=cname.fqdn.dom dom=other.fqdn.dom

However, doing this doesn't yield any responses for cname.fqdn.dom,
even though I have e.g.

ip=a.b.c.d dom=host.fqdn.dom
cname=www.fqdn.dom dom=host.fqdn.dom

When I then look up www.fqdn.dom, I get no response.

--dho

Re: [9fans] ndb/dns as a slave

[Devon H. O';Dell]

2009/8/22  :
>> cname=cname.fqdn.dom dom=other.fqdn.dom
>
> Nopes:
>
> dom=nickname.dqdn.dom
>        cname=propername.fqdn.dom

Aha. The manpage shows this the other way around. I'll send a patch later today.

--dho

> works for me.
>
> ++L
>
>
>

Re: [9fans] ndb/dns as a slave

[Devon H. O';Dell]

2009/8/22 erik quanstrom :
> On Sat Aug 22 09:35:03 EDT 2009, devon.od...@gmail.com wrote:
>> 2009/8/22 Steve Simon :
>> > I assume your master DNS is served from bind, then you
>> > can use the zonefresh program in my contrib to build an
>> > ndb compatible ndb file for your local dns to serve.
>>
>> Actually, I'm using ndb/dns for both. I seem to recall reading that
>> ndb supports zone transfers by looking for large packets in udp53 (or
>> something). I suppose if this isn't possible, periodically pulling
>> /lib/ndb/local from the other machine and sending refresh to /net/dns
>> could work. (Just kind of wondering what the standard procedure is :))
>
> in that case, why wouldn't you use plan 9 methods, rather
> than rely on goofy dns stuff?

Because I rarely actually use Plan 9 and I'm not sure what the
proposed methodology for doing this is.

> - erik
>
>

Re: [9fans] iwp9 deadline extension

[Devon H. O';Dell]

2009/8/28 Eric Van Hensbergen :
> Satelite conference locations in Antwerp and Oz may be be a bad idea
> assuming folks can accomodate crazy time differences.

Not a bad idea, does anyone on the else pc have A/V equipment? I do,
but it's not great stuff (just webcam quality), so it'd be like last
resort stuff. I could get a DV cam if necessary.

--dho

> Sent from my iPhone
>
> On Aug 28, 2009, at 2:21 PM, erik quanstrom  wrote:
>
>> On Fri Aug 28 15:09:25 EDT 2009, noah.ev...@gmail.com wrote:
>>>
>>> We don't have any travel budget now does coraid have any sponsors
>>> willing to fund travel?
>>>
>>
>> that's a tough one.  my currency thus far has largely been
>> tom sawyering and cajolerie.  coraid and uga have helped
>> with facilities, but there is no money for travel.
>>
>> the gsoc group had talked about using some of the google
>> money for such things.
>>
>> in case this is not evident, it is okay to submit a paper
>> if you can't attend.
>>
>> - erik
>>
>
>

Re: [9fans] iwp9 deadline extension

[Devon H. O';Dell]

2009/8/28 Eric Van Hensbergen :
> I've got dvcam and lapel mikejust need bamdwidth.

If we've got 320kbps we can easily do the presentation via justin.tv
or something similar. Alternatively, if we just want to set up e.g. an
mpeg stream, I have machines that can proxy that. Though Erik will
have to confirm / deny the existence of any amount of bandwidth in the
first place.

> Sent from my iPhone
>
> On Aug 28, 2009, at 3:11 PM, "Devon H. O'Dell" 
> wrote:
>
>> 2009/8/28 Eric Van Hensbergen :
>>>
>>> Satelite conference locations in Antwerp and Oz may be be a bad idea
>>> assuming folks can accomodate crazy time differences.
>>
>> Not a bad idea, does anyone on the else pc have A/V equipment? I do,
>> but it's not great stuff (just webcam quality), so it'd be like last
>> resort stuff. I could get a DV cam if necessary.
>>
>> --dho
>>
>>> Sent from my iPhone
>>>
>>> On Aug 28, 2009, at 2:21 PM, erik quanstrom 
>>> wrote:
>>>
>>>> On Fri Aug 28 15:09:25 EDT 2009, noah.ev...@gmail.com wrote:
>>>>>
>>>>> We don't have any travel budget now does coraid have any sponsors
>>>>> willing to fund travel?
>>>>>
>>>>
>>>> that's a tough one.  my currency thus far has largely been
>>>> tom sawyering and cajolerie.  coraid and uga have helped
>>>> with facilities, but there is no money for travel.
>>>>
>>>> the gsoc group had talked about using some of the google
>>>> money for such things.
>>>>
>>>> in case this is not evident, it is okay to submit a paper
>>>> if you can't attend.
>>>>
>>>> - erik
>>>>
>>>
>>>
>>
>
>

Re: [9fans] iwp9 deadline extension

[Devon H. O';Dell]

2009/8/28 Don Bailey :
> Is there an IWP9 website for this year that provides information about dates
> and locations?

http://iwp9.org

> Thanks,
> D
>
> On Fri, Aug 28, 2009 at 1:11 PM, Devon H. O'Dell 
> wrote:
>>
>> 2009/8/28 Eric Van Hensbergen :
>> > Satelite conference locations in Antwerp and Oz may be be a bad idea
>> > assuming folks can accomodate crazy time differences.
>>
>> Not a bad idea, does anyone on the else pc have A/V equipment? I do,
>> but it's not great stuff (just webcam quality), so it'd be like last
>> resort stuff. I could get a DV cam if necessary.
>>
>> --dho
>>
>> > Sent from my iPhone
>> >
>> > On Aug 28, 2009, at 2:21 PM, erik quanstrom 
>> > wrote:
>> >
>> >> On Fri Aug 28 15:09:25 EDT 2009, noah.ev...@gmail.com wrote:
>> >>>
>> >>> We don't have any travel budget now does coraid have any sponsors
>> >>> willing to fund travel?
>> >>>
>> >>
>> >> that's a tough one.  my currency thus far has largely been
>> >> tom sawyering and cajolerie.  coraid and uga have helped
>> >> with facilities, but there is no money for travel.
>> >>
>> >> the gsoc group had talked about using some of the google
>> >> money for such things.
>> >>
>> >> in case this is not evident, it is okay to submit a paper
>> >> if you can't attend.
>> >>
>> >> - erik
>> >>
>> >
>> >
>>
>
>

Re: [9fans] Interested in improving networking in Plan 9

[Devon H. O';Dell]

2009/8/31 Vinu Rajashekhar :
> "You can implement a NAT by mounting a /net from a perimeter machine
> with a public IP, while connecting to it from an internal network of private
> IP addresses, using the Plan 9 protocol 9P in the internal network."
>
> This is from the wikipedia page on Plan 9 OS.
>
> Is something like iptables like in linux needed to be implemented for
> Plan 9 ?

My student's summer of code project, which was quite unfortunately not
completed, was to implement support for NAT in Plan 9, and to
implement a firewalling infrastructure. I think it would be good to
implement something like this, and several people thought that
implementing NAT, if done correctly, would be quite useful for people
running Plan 9. I'm still interested in providing guidance and info
about this if it's something you're interested in pursuing -- I have
quite a few ideas on how it should work.

Kind regards,

Devon H. O'Dell

Re: [9fans] Interested in improving networking in Plan 9

[Devon H. O';Dell]

2009/8/31 erik quanstrom :
>> 2009/8/31 Bakul Shah :
>> > But this is nasty!
>> > % cat ndb/dom/'' # same as ndbquery dom ''
>>
>> No, the nasty part is really that the file should be called `.' and
>> the filesystem reserves dot as the reference to the current directory.
>> You could probably call the file `dot' or `root' (cat ndb/dom/dot or
>> cat ndb/dom/root) as something that shouldn't ever conflict with
>> anything else -- but the root of DNS is not an empty string.
>
> aren't you being a little bit pedantic?  quoting is a fact
> of life.  we don't say that it's evil to need to quote or
> transform things in rc or smtp to deal with local requirements.
> why would it be evil to quote '.'?  and why would be calling
> '.' 'root' or 'dot' rather than '' be any less evil?

It's (in my opinion) slightly less evil because if(!strlen(name))
seems like a pretty poor way to determine that you're looking at the
root zone. It's also more intuitive and easier to document that you're
looking at the root than saying `to find root, look for a file named
as an empty string'. So: less evil because it makes code more
intuitive and it makes documentation easier.

Also, I think I should state that I really don't care about
implementation as long as it's documented, and that the root is not an
empty string. I don't particularly care about quoting at all, and I
don't consider that any reason for one method to be more obtuse than
another.

--dho

> - erik
>
>

Re: [9fans] Interested in improving networking in Plan 9

[Devon H. O';Dell]

2009/8/31 Bakul Shah :
> But this is nasty!
> % cat ndb/dom/'' # same as ndbquery dom ''

No, the nasty part is really that the file should be called `.' and
the filesystem reserves dot as the reference to the current directory.
You could probably call the file `dot' or `root' (cat ndb/dom/dot or
cat ndb/dom/root) as something that shouldn't ever conflict with
anything else -- but the root of DNS is not an empty string.

--dho

> dom= ns=A.ROOT-SERVERS.NET ns=B.ROOT-SERVERS.NET ns=C.ROOT-SERVERS.NET 
> ns=D.ROOT-SERVERS.NET ns=E.ROOT-SERVERS.NET ns=F.ROOT-SERVERS.NET 
> ns=G.ROOT-SERVERS.NET ns=H.ROOT-SERVERS.NET ns=I.ROOT-SERVERS.NET 
> ns=J.ROOT-SERVERS.NET ns=K.ROOT-SERVERS.NET ns=L.ROOT-SERVERS.NET 
> ns=M.ROOT-SERVERS.NET
>
> And it is not clear how you would map
> % ndbquery attr value rattr ...
>
> Another alternative is to map each tuple to a directory:
> % ls ndb/dom/A.ROOT-SERVERS.NET # just show the attributes!
> dom ip
>
> % grep '' ndb/dom/A.ROOT-SERVERS.NET/*
> dom:A.ROOT-SERVERS.NET
> ip:198.41.0.4
>
> An intriguing idea that can point toward a synth fs interface
> to a dbms or search results  But I don't think this would
> be a lightweight interface.
>
>

Re: [9fans] lowest valid stack address

[Devon H. O';Dell]

2009/9/1 Russ Cox :
>> aside: from the overcommit vm discussion.
>> in http://9fans.net/archive/2000/06/634 rob
>> says that plan 9 doesn't overcommit vm.
>> what's the history here?
>
> i think plan 9 does overcommit vm and did then too.

It very much so does.

--dho

> russ
>
>

Re: [9fans] lowest valid stack address

[Devon H. O';Dell]

2009/9/2 Andrés Domínguez :
> 2009/9/2 erik quanstrom :
>>
>> aside: from the overcommit vm discussion.
>> in http://9fans.net/archive/2000/06/634 rob
>> says that plan 9 doesn't overcommit vm.
>> what's the history here?
>
> Exactly two years ago you started a thread about
> memory overcommit. If I remember correctly, plan9
> overcommits vm. Few weeks later the Go program
> from gorka crashed while allocating the stack, maybe
> an overcommiting check was added, probably gorka
> knows.

No checks have been added. I started a rather active thread about this
a few months ago in attempt to figure out a way to `protect' from this
behavior starving the kernel of memory and thus panicking. I'll leave
it up to Elly to find some way to actually exploit this :). The
problem ended up being that I'd have to rework a lot of the slab
allocator, or do checks on every memory allocation, and I didn't want
to do that. More detailed info for those who care:

Lemma: In order to avoid overcommitting, we must impose limits on how
much memory may, in fact, be allocated. To make the implementation
provable, you must be able to assert that memory always comes from the
same spot, and you thus have a single path to follow into allocation.

Memory limits must be enforced based on real hardware in the system.
The issue here is that some slabs will always fill up
disproportionately to others. Thus, whichever limit you impose, slabs
must be growable. Thus:
 - Systemic limits require you to be able to migrate pages between zones.
 - Per-zone memory limits are silly because you have to be able to
migrate pages between zones,
 - Per-process and per-user memory limits are silly, though easier to
implement, because they add too much overhead to allocations and
frees.

Basically, it boils down to: If you want to implement this
effectively, the slab allocator needs to be reworked so that memory
zones can `steal' pages from other zones. If this is a real issue, I'm
happy to go take another stab at it: I stopped working on it last time
because it seemed most people found it a non-issue.

--dho

> Andrés
>
>

Re: [9fans] lowest valid stack address

[Devon H. O';Dell]

2009/9/2 erik quanstrom :
>> problem ended up being that I'd have to rework a lot of the slab
>> allocator, or do checks on every memory allocation, and I didn't want
>> to do that. More detailed info for those who care:
>
> could you use plan 9 terminology?

Probably not. Plan 9 uses a slab allocator to allocate memory in both
kernel and userland. The only fault I see in my previous email is
saying `zone' instead of `pool', but they're synonymous enough. If you
cite a specific ambiguity, I'm more than happy to clarify.

>>
>> Lemma: In order to avoid overcommitting, we must impose limits on how
>> much memory may, in fact, be allocated. To make the implementation
>> provable, you must be able to assert that memory always comes from the
>> same spot, and you thus have a single path to follow into allocation.
>
> "from the same spot" could mean from the same point in the code or
> from the same physical address.  either way, i don't buy this assertion.
> counter example: ssd drive remapping algorithms.

That was a rather poor choice of words. Restatement: To prove the
safety of the implementation, you must be able to assert that any
memory allocation triggers a check on the availability of the
requested memory. This revised statement doesn't require that a single
code path be followed into allocation, but since malloc() obtains
memory from the slab allocator, it makes sense to build the protection
into the slab allocator: it's centralized, and all allocations are
guaranteed to go through there anyway. The safety of such an
implementation is much easier to prove.

I hope that clarifies what I meant.

Example for what I did not mean: the FreeBSD jail system `virtualizes'
kernel resources by partitioning them to certain jail IDs. This
requires any resources wishing to be shared to be jail-aware, with the
side-effect that proving a jail only has access to what it needs is
much more difficult, because you have to prove that every resource is
`protected' anywhere that it is potentially used in the kernel. The
analogue to this sort of thing for our discussion would be introducing
an additional API to be used in conjunction with malloc(), requiring
it to be used every time. Clearly, it is more difficult to prove that
all mallocs() are safe with such an API, and it is *impossible* to
prove that future calls will be protected, as it is impossible to
prove that future additions to the kernel are properly handled with
respect to jails.

It's a somewhat silly comparison (as no one in their right mind would
implement this as an API to be used alongside malloc), but it
illustrates my point well. And it was easier to come up with that than
coming up with some other theoretical non-centralized (from a code
point of view) solution to this problem.

--dho

> - erik
>
>

Re: [9fans] "Blocks" in C

[Devon H. O';Dell]

2009/9/2 Uriel :
> On Wed, Sep 2, 2009 at 10:04 AM, Anant Narayanan wrote:
>> Mac OS 10.6 introduced a new C compiler frontend (clang), which added
>> support for "blocks" in C [1]. Blocks basically add closures and anonymous
>> functions to C (and it's derivatives). Full details with examples are in the
>> linked article. I think the feature is quite elegant and might be useful in
>> cases where you want map/reduce like functionality in C.
>
> Er., I might be more dumb than usual, but why on earth would you
> need/want this garbage to get map/reduce functionality in C?
>
> To me it seems the typical "lets come up with some cute 'feature' and
> then we will figure out how to hype ourselves all the way to hell".

I don't see why you'd particularly need / want this in C, but the
argument here seems silly given that you've stressed your affinity to
other languages that implement closures / anonymous functions.

In any case, implementing closures in C isn't too difficult, and if
you want to return a function, just return a pointer to it.

--dho

Re: [9fans] plan9 on vmware esx

[Devon H. O';Dell]

Plan 9 does not work with either of the SCSI controllers in ESX(i) 3.5
or less. Plan 9 does run on IDE drives just fine in ESX(i) 4. Plan 9
panicks if you give it more than 2 CPUs on any of them. If you have
any questions about getting Plan 9 to run in ESX(i) 4, let me know;
I've done it. But you won't get it running in <4 without moar drivers.

--dho

Re: [9fans] Anyone familiar with glomation?

[Devon H. O';Dell]

2009/10/6 ron minnich :
> http://www.glomationinc.com/
>
> 49 bucks!
>
> It's an arm 9 -- anybody know what variety?

I pasted them here about 6 or so months ago. It's 49 bucks at
quantity. For a single system, it goes up to $85. The processor is an
Atmel.

> ron
>
>

Re: [9fans] dtrace for plan 9

[Devon H. O';Dell]

2009/10/27 ron minnich :
> I realize it is early but a neat GSOC project would be to take the
> mods I made to 8l and friends and use these as a way to build dtrace
> for plan 9.

Getting CTF working in Plan 9 would be difficult since it's not ELF.
It was annoying enough to get working in FreeBSD. As that's a sort of
first requirement, what would you suggest for starting that?

> Had a fun talk with someone from Sun today and for at least part of
> dtrace functionality the 8l mods get us part of the way there.
>
> What they can do with dtrace is pretty impressive.

Yes, it is.

(In before this thread degenerates into how DTrace is bigger than Plan
9 and how retarded it is)

> ron

--dho

Re: [9fans] dtrace for plan 9

[Devon H. O';Dell]

Also, D is not compiled in kernel. The dtrace utility compiles the D
script, and the script goes through some sanity checking in the D
compiler. The bytecode is sent to the kernel to execute. There are
some in-kernel safety guarantees -- for instance, a D script causing a
nil ptr deref in kernel obviously shouldn't (and does not) cause the
system to panic.

--dho

[9fans] ZFS Dedup

[Devon H. O';Dell]

ZFS now does deduplication: http://blogs.sun.com/bonwick/entry/zfs_dedup

--dho

Re: [9fans] dtrace for plan 9

[Devon H. O';Dell]

2009/11/9 erik quanstrom :
>> > I keep hearing this brought up, but (while I am not an expert) AFAICT, the
>> > runtime for each D hook should be strictly bounded by the number of
>> > instructions lobbed in, since D does not (without root override, perhaps?)
>> > support backwards jumps.  Am I mistaken in my understanding of DTrace?
>>
>> You are right. I don't think runtime is unbounded. At the same time,
>> I'm still trying to locate example scripts to get an idea of how
>> complex it is. I'm talking to people at sun to get a handle on the
>> question.

D doesn't do loops or conditionals. You can't branch. But you can get
around that with some tricks, like aggregations and predicates. For
what you'd typically use it for, it should be ok. That said, my
knowledge of DTrace internals greatly surpasses my knowledge of how to
actually use it, so I'll let Roman help out on that front :)

> before we go all crazy, has anyone else tried ron's
> great tracing?

It's good, I read the paper and played around with it while I was
doing some 9vx work. But it's not really the same. Devtrace implements
a subset of DTrace's functionality.

DTrace does more than syscalls, and a lot of the talk on this thread
seems to be focused around that, so please let me clarify a bit. This
is partially due to compiling binaries with CTF (Compact C Type Format
-- when I asked the guys about this, they laughed and said it was so
compact that they cut off a C from the acronym). CTF stores type /
name / size information about symbols in a program, but is not as
heavy as DWARF: no line information is stored, no file references,
etc. The data is stored in an extended ELF header, compressed with
zlib.

DTrace by itself is pretty lame. It needs providers to be interesting.
By itself, it's a very limited interpreter that supports BEGIN and
END, and a couple other tiny things (ERROR, maybe?). Devtrace would be
analogous to the syscall provider for DTrace, from my understanding.

Because of CTF, DTrace also has providers to do function boundary
tracing (function entries / exits) on any executable (including a live
kernel) that has been compiled with CTF symbols. The fasttrap (or PID)
provider allows for instruction level tracing by inserting a
breakpoint at a given location, catching it, executing what was
previously at the breakpoint, executing the relevant D code (which may
in turn be traced by DTrace up to a finite amount of recursion), until
it comes back up the stack. The USDT providers allow userland
applications -- languages such as Perl, PHP, or Python for instance --
to register DTrace hooks. Once a userland app has done this, you can
follow e.g. a Python function call from the script, through Python,
through libc, through a syscall, all the way to a device driver... and
back up again.

It's also fairly easy to do this. I was at a party with the Sun guys
at OSCon in 2005. Wez Furlong wrote a DTrace provider for PHP in about
30 minutes with Bryan Cantrill, who then rather excitedly ran to me
explaining how I needed to come look (this is a gross understatement
for brevity). It was pretty cool, and the code needed for the DTrace
hooking was smaller than the PHP module skeleton code.

While extending it may be done relatively easy, it is quite big. When
I was working on porting it to FreeBSD (before jb@ essentially usurped
the project, anyway), I spent 3 weeks getting CTF and the base DTrace
provider ported over. Granted, I was much less experienced than now,
but it is a significant amount of work to reproduce all the
functionality. I'd estimate a finished version to be about the size of
the Plan 9 kernel.

--me

Re: [9fans] dtrace for plan 9

[Devon H. O';Dell]

2009/11/9 erik quanstrom :
>> DTrace by itself is pretty lame. It needs providers to be interesting.
>> By itself, it's a very limited interpreter that supports BEGIN and
>> END, and a couple other tiny things (ERROR, maybe?). Devtrace would be
>> analogous to the syscall provider for DTrace, from my understanding.
>
> i may be misunderstanding you, but devtrace can trace any
> call site or return in the kernel.  not just system calls. and
> not just entire functions; one could enable tracing on just
> one return, for example.
>
> you just give it a range of addresses and it loops through finding
> the magic left by the linker.  enabling a trace atomicly modifies
> each site to turn on tracing.

Ok, I didn't realize the scope.

>> I'd estimate a finished version to be about the size of
>> the Plan 9 kernel.
>
> minooka; wc -l /sys/src/9/*/*trace*.[chs] /sys/src/libc/386/trace.s
>    118 /sys/src/9/pc/archtrace.c
>     18 /sys/src/9/pc/archtrace.h
>    578 /sys/src/9/port/devtrace.c
>     33 /sys/src/libc/386/trace.s
>    747 total
>
> this stuff's ready to take off.  (har har har.)

Sure, but it's still not the entire functionality :)

--dho

> - erik
>
>

Re: [9fans] Go

[Devon H. O';Dell]

2009/11/12 Roman Shaposhnik :
> On Wed, Nov 11, 2009 at 8:31 PM, Nick LaForge  wrote:
>> On Wed, Sep 2, 2009 at 7:20 AM, Roman V Shaposhnik  wrote:
>>
>>> Personally I think you'd be better off exploring a connection that a
>>> language called Lua has to C. In the immortal words of Casablanca it
>>> just could be "the begging of a beautiful friendship".
>>
>> Well, it was nice while it lasted.
>
> Huh? I'll agree with you when Go grows a VM. And even then things like
> ... and multi-values (which, of course, are only possible in a dynamically
> typed language) will keep me interested.
>
> Speaking of VMs (and Limbo) -- I'm wondering if Go is eventually going
> to have it anyway. Any reason not to?

It can be perceived as a competitor to C if it has a runtime, but not
if it has a VM. So I don't think it would grow one.

--dho

> Thanks,
> Roman.
>
>

Re: [9fans] Go

[Devon H. O';Dell]

2009/11/12 erik quanstrom :
>> > Speaking of VMs (and Limbo) -- I'm wondering if Go is eventually going
>> > to have it anyway. Any reason not to?
>>
>> It can be perceived as a competitor to C if it has a runtime, but not
>> if it has a VM. So I don't think it would grow one.
>
> why do you think the goal is to be
> perceived as a competitor to c?
>
> i don't see that here:
> http://golang.org/doc/go_faq.html#What_is_the_purpose_of_the_project

Because it is constantly compared with C, C++, Java, and scripting
languages. Its packages are sold as better than C header files, which
is demonstrated in Russ' compile time video. It is a compiled language.
Its syntax is not horribly divergent from C.

I'm not saying that C is its main competition, but it clearly does compete
in the field of general purpose languages, of which C is a large player.
In this regard, it also aims to compete with C++, Java, Python, Ruby,
and Perl.

It is billed as a good general purpose language for modern systems. It
is just that, and therefore, I drew that conclusion.

> one thing that's not clear to me from
> the faq (perhaps it's clarified in robs talk?)
> and i haven't worked out for myself yet, is if
> one could write operating system code in
> go.  and if so, what would the language
> restrictions be.

It has support for pointers, so I guess so. I'd guess it's somewhat
easier than C++, where you have to have an implementation for new
before you can do much of anything else very C++-like. That said,
it does have a language runtime like C++, so I suspect it does need
some setup before some features (such as threads) can be used.

> - erik

--dho

Re: [9fans] 9P libraries for Go

[Devon H. O';Dell]

2009/11/25 Latchesar Ionkov :
> I added a Makefile in the repository that builds the packages outside
> of the go tree.

Any plans for filing a CL to add those to Go's src/pkg repo? I'm sure
it would be welcomed.

--dho

> Thanks,
>    Lucho
>
> On Mon, Nov 23, 2009 at 7:04 PM, Roman Shaposhnik  
> wrote:
>> On Sun, Nov 22, 2009 at 8:38 PM, Latchesar Ionkov  wrote:
>>> Hi,
>>>
>>> Andrey Mirtchovski and I wrote 9P server and client libraries/packages for 
>>> Go.
>>
>> Perfect
>>
>>> The hg repository with the code is available at 
>>> http://bitbucket.org/f2f/go9p/.
>>>
>>> Once downloaded the code should be moved to $GOROOT/src/pkg and
>>> $GOROOT/src/pkg/Makefile should be modified so DIRS includes plan9/p,
>>> plan9/p/clnt and plan9/p/srv directories. These directories should
>>> also be added to the NOTEST variable.
>>
>> Could this be added to README, or better yet automated somehow?
>>
>> Thanks,
>> Roman.
>>
>>
>
>

Re: [9fans] GO/Plan 9 toolchain

[Devon H. O';Dell]

2010/1/10 erik quanstrom :
>> I believe that Bell Labs are actively involved in the port of GO to
>> Plan 9, I'm not sure how much my efforts are likely to contribute to
>> that particular project.
>
> could anyone confirm this?

Sape mentioned either on go-nuts on on 9fans at some point in the past
3 months that he was working on a port.

--dho

> - erik
>
>

Re: [9fans] recreational programming of an evening

[Devon H. O';Dell]

2010/3/21 Bakul Shah :
[snip]
> What's really missing is a whole book on hands on OS hacking
> along the lines of the Art of Electronics or SICP (Structure
> and Interpretation of Computer Programs).  And with a kit of
> h/w & i/o devices so that you can build some widgets and
> give'em a real OS!
>
>

I've wanted to do something like this for a while, but it's hard to
find a publisher for such a thing.

Re: [9fans] ken-cc, 64 bits machine, and 32 bits integers

[Devon H. O';Dell]

vlong

2010/3/30 EBo :
>
>> with kenc, long === 32 bits even on 64 bit machines; there is no
>> difference in storage size between long and int.
>
> out of curiosity, does kenc implement long long's?
>
>
>

Re: [9fans] missing machs unearthed

[Devon H. O';Dell]

2010/4/5 ron minnich :
> On Mon, Apr 5, 2010 at 2:20 AM, Richard Miller <9f...@hamnavoe.com> wrote:
>>> i've had a core i7 machine for some time with 4c/8t.
>>> unfortunately, the mp table has only 4 processor entries.
>>
>> My impression is that mp tables are getting worse and worse on new
>> hardware because vendors assume everyone is running an acpi-aware OS.
>>
>
> that's precisely the problem. We've seen cases where vendors too
> bioses from an old machine to a new machine. If you are not acpi aware
> you are pretty much 5 years out of date.

It's not just that. The other part is that you can put OS-specific
information into the AML, which is nice in theory, until you consider
that most vendors consider Windows to be the only operating system in
existence. (This is why FreeBSD allows you to override the tables --
you can rewrite those sections to apply to FreeBSD, and most of the
time, that works just fine).

That said, things have settled down a good bit in ACPI land and
Intel's ACPICA reference implementation is fairly complete (but
unfortunately not something we can use).

Nemo, I wonder if you have any way to allow others to collaborate on
that code? Seems like there's certainly interest, and the ACPI spec
*is* open...

--dho

Re: [9fans] 9vx patch to read environment var PLAN9

[Devon H. O';Dell]

2010/4/11 erik quanstrom :
> recommend using a different environment variable
> other than PLAN9, since that is taken by p9p to mean
> something else.

Agreed. PLAN9ROOT seems good.

--dho

> - erik
>
>

Re: [9fans] 9vx patch to read environment var PLAN9

[Devon H. O';Dell]

2010/4/11 EBo :
> I thought p9p uses it for the root of the Plan 9 tree?  At least that is what
> the ebuilds imply.  Maybe I am using the wrong term for what PLAN9 points to.

That's true, but in the case of 9vx, the tree it points to contains
actual plan 9 binaries, whereas p9p binaries are compiled for the host
system. Since it is very feasible that someone may run p9p and 9vx on
the same machine (I do, for instance), it would be a good idea to not
overload the env var.

--dho

>  EBo --
>
>
> erik quanstrom  said:
>
>> recommend using a different environment variable
>> other than PLAN9, since that is taken by p9p to mean
>> something else.
>>
>> - erik
>>
>
>
>
> --
>
>
>
>
>

Re: [9fans] 9vx patch to read environment var PLAN9

[Devon H. O';Dell]

2010/4/11 erik quanstrom :
>> Agreed. PLAN9ROOT seems good.
>
> suggest 9vxroot instead.  there are enough plan9y
> things floating around that it makes sense to me
> to specify which plan9y root you're talking about.

I was going to suggest that, but you can't start env. var. names with
numbers in many shells.

--dho

> and there's no reason to shout.  :-)
>
> - erik
>
>

Re: [9fans] /sys/lib/newuser patch

[Devon H. O';Dell]

2010/4/12 hiro <23h...@googlemail.com>:
> I have not the slightest idea about the complexity involved; And I
> think I misunderstand how much of plan9 is actually running in a
> sandbox. But what if we wanted to have a working security system for
> multiple users in 9vx. Would it be - or is it - possible?

Yes, it is possible, but it probably requires writing something to use
PAM (or whatever authentication mechanism is set up) on the host
system. I have a few ideas for this.

--dho

> On 4/12/10, erik quanstrom  wrote:
>>> Can't we then fix 9vx?
>>> (Stepping in to the tradition of concern of reception: This is not a
>>> rhetoric question)
>>
>> it's not 9vx, but #Z.  and no, #Z is going to be limited by
>> the underlying system.
>>
>> - erik
>>
>>
>
>

Re: [9fans] /sys/lib/newuser patch

[Devon H. O';Dell]

2010/4/12 erik quanstrom :
>> 2010/4/12 hiro <23h...@googlemail.com>:
>> > I have not the slightest idea about the complexity involved; And I
>> > think I misunderstand how much of plan9 is actually running in a
>> > sandbox. But what if we wanted to have a working security system for
>> > multiple users in 9vx. Would it be - or is it - possible?
>>
>> Yes, it is possible, but it probably requires writing something to use
>> PAM (or whatever authentication mechanism is set up) on the host
>> system. I have a few ideas for this.
>
> iirc, 9vx doesn't have devcap.

It does not. (Yet).

> the problem you're addressing can't be addressed well through #Z.
> unix systems act differently than plan 9 ones do. there are a host
> of locking, etc. questions that #Z doesn't handle either.   it would be easier
> to use a plan 9 fs (ken fs, cwfs, fossil).  then you wouldn't need to
> deal with unix authentication.

Probably true. However, I'm confident that there are ways to address
it -- and still, one of the cool things about 9vx is the local FS
access. When I was doing my 9vx autoprovisioner, the instances would
start in a chrooted sandbox, which was the best way I could figure to
deal with the permissioning issues at that point in time (without lots
o hacking).

--dho

> - erik
>
>

Re: [9fans] 9vx patch to read environment var PLAN9

[Devon H. O';Dell]

2010/4/15 EBo :
>
>> Define reasonable. For me, that’s just 1 single spot. But it seems
>> the Linux people are very insistent on Freedom meaning do what you
>> want, even if it's against the build suggestions.
>> I say stick to one hardcoded path, and make everyone else stop doing
>> it their own way, and stick to one simple, consistent solution.
>
> Two possible guides are:
>
> Linux Standard Base 
> 
>
> and
>
> Filesystem Hierarchy Standard 

But the world isn't Linux.
http://www.freebsd.org/cgi/man.cgi?query=hier&sektion=7

--dho

Re: [9fans] three sets of windows

[Devon H. O';Dell]

2010/4/28 John Floren :
> On Tue, Apr 27, 2010 at 6:54 PM, Tim Newsham  wrote:
>>> I'm curious about the 3-button mouse... (haven't seen one for a long
>>> while, but seems like it might be worth getting one.)
>>
>> you might have seen one and not even known it.  Many mice
>> with a scroll wheel support pressing the scroll wheel as a 3rd
>> button.  its not nearly as pleasant as a real button, but it "works".
>>
>
> Using a clickable scroll wheel nearly cripples my fingers; have any
> 9fans tried this mouse?
> http://www.amazon.com/3-Button-Optical-USB-Mouse-black/dp/B000FLUSEM/ref=cm_cr_pr_product_top
>
> My netbook's trackpad is unacceptable for Plan 9 use, and since it
> doesn't have a PS/2 port I can't plug in one of my old Logitechs.

I've been using http://www.thehumansolution.com/evoluent.html
recently, and I do love it.

--dho

> John
>
>

Re: [9fans] three sets of windows

[Devon H. O';Dell]

2010/4/28 Patrick Kelly :
>> > My netbook's trackpad is unacceptable for Plan 9 use, and since it
>> > doesn't have a PS/2 port I can't plug in one of my old Logitechs.
>>
>> I've been using http://www.thehumansolution.com/evoluent.html
>> recently, and I do love it.
>
> How the hell is a shape patentable?

Things come in various shapes, and things can be patented, so there
you go. It's part of the patent.

In any case, it's not horribly expensive (compared to many other
ergonomic and other sorts of mice), has adjustable DPI, has 5 buttons
(7 if you count scroll up / down), and is very comfortable.

--dho

Re: [9fans] tun/tap support for 9vx

[Devon H. O';Dell]

2010/5/7 Tully Gray :
> Hi,
>
> I have modified Erik Quanstrom's raw socket ethernet driver
> for 9vx so that it uses the Linux kernel's "tap" device.
> It seems to work just fine. I create the tap device first
> using "tunctl" which comes with the Usermode Linux toolkit
> but I don't think this is necessary.

Thanks for this. My summer of code student will be working on wrapping
up some of this so that it's a bit nicer and more portable, and this
is a good start.

--Devon

> Tully Gray.
>
> ps: I am shadowdaemon on IRC.
>

Re: [9fans] tun/tap support for 9vx

[Devon H. O';Dell]

2010/5/7 erik quanstrom :
>> interesting.  what's the advantage of the tap device?
>> is the code available online?
>
> duh.  sorry.  missed the attachment.  having peeked
> at the code, do you think that the tap devices is a
> complete replacement for the raw socket?

Yes. The tap(4) interface allows you to clone an existing ethernet
device on the system, and it's what most virtualization platforms use.
I had an ethertap.c in there, but never finished it up. It'll be
something that gets done for GSoC this year anyway.

--dho

> - erik
>
>

Re: [9fans] 3-button mouse

[Devon H. O';Dell]

2010/5/6 Mathieu Lonjaret :
> Hello,
>
> Just one comment about the vertical Evoluent mouse (I bought one a few
> months ago since Russ recommended them).

I also recommended it in another recent thread on mice.

> It can be pretty hard to get used to it. I had to force myself to try
> it several times before I could stand using it. I think the main
> reason is because you apply horizontal pressure when clicking and that
> can make the pointer move unvoluntarily on your part. That gets pretty
> annoying when it makes you fail at your chordings and you have some
> code to produce.

I didn't really have this problem so much, but I run at a really low
DPI. I do notice that to avoid it, I put additional pressure on my
wrist, which is probably not a really great thing.

> Now I'm starting to really like it; I'd say one gets past the
> annoyance if you manage to keep using it for a full day without
> throwing it away for another mouse. In fact I'd recommend trying it
> and starting to use it on day when it's not so important to be
> efficient and you can afford to loose a bit of time to it. Sounds like
> common sense now, but I think it's particularly true with that mouse.

I do love this mouse.

--dho

> Cheers,
> Mathieu
>
>

Re: [9fans] system call trace version of 9vx available.

[Devon H. O';Dell]

2010/5/19 ron minnich :
> On Wed, May 19, 2010 at 3:02 PM, Bakul Shah  wrote:
>
>>> It gives you the option of not restarting the system call until later.
>>> There could be more complex usage scenarios.
>>
>> I don't understand this.
>
> You read the "start of the system call" message. The process is
> stopped. It has not run the system call.
>
> You have a lot of options at that point. You could, programatically,
> drop the person into acid (the debugger, not the liquid) and, when
> they exit, resume the process. You really do have lots of control.

But there's nothing more fun than watching someone scream in a HCl
bath of high molarity, especially after they've made a dumb
programming error! (Sorry for the noise, I had to.)

--dho

Re: [9fans] Inducing artificial latency

[Devon H. O';Dell]

2010/6/15 John Floren :
> I'm going to be doing some work with 9P and high-latency links this
> summer and fall. I need to be able to test things over a high-latency
> network, but since I may be modifying the kernel, running stuff on
> e.g. mordor is not the best option. I have enough systems here to do
> the tests, I just need to artificially add latency between them.
>
> I've come up with a basic idea, but before I go diving in I want to
> run it by 9fans and get opinions. What I'm thinking is writing a
> synthetic file system that will collect writes to /net; to simulate a
> high-latency file copy, you would run this synthetic fs, then do "9fs
> remote; cp /n/remote/somefile .". If it's a control message, that gets
> sent to the file immediately, but if it's a data write, that data
> actually gets held in a queue until some amount of time (say 50ms) has
> passed, to simulate network lag. After that time is up, the fs writes
> to the underlying file, the data goes out, etc.
>
> I have not really done any networking stuff or filesystems work on
> Plan 9; thus far, I've confined myself to kernel work. I could be
> completely mistaken about how 9P and networking behave, so I'm asking
> for opinions and suggestions. For my part, I'm trying to find good
> example filesystems to read (I've been looking at gpsfs, for
> instance).

This seems reasonable, but remember that you're only going to be able
to simulate latency in one direction as far as the machine is
concerned. So you'll want to have the same configuration on both
machines, otherwise things will probably look weird. I'd recommend
doing this at a lower level, perhaps introducing a short sleep in IP
output so that the latency is consistent across all requests. And of
course both machines would need to have this configuration. You could
have the stack export another file that you can tune if you want to
maintain a file-system approach. But I think a synthetic FS for this
is overkill.

If you're on a local network, this should do the trick, otherwise you
may need to do some adaptive latency.

--dho

>
> John
> --
> "With MPI, familiarity breeds contempt. Contempt and nausea. Contempt,
> nausea, and fear. Contempt, nausea, fear, and .." -- Ron Minnich
>
>

Re: [9fans] Inducing artificial latency

[Devon H. O';Dell]

2010/6/15 John Floren :
> On Tue, Jun 15, 2010 at 5:45 PM, Devon H. O'Dell  
> wrote:
>> 2010/6/15 John Floren :
>>> I'm going to be doing some work with 9P and high-latency links this
>>> summer and fall. I need to be able to test things over a high-latency
>>> network, but since I may be modifying the kernel, running stuff on
>>> e.g. mordor is not the best option. I have enough systems here to do
>>> the tests, I just need to artificially add latency between them.
>>>
>>> I've come up with a basic idea, but before I go diving in I want to
>>> run it by 9fans and get opinions. What I'm thinking is writing a
>>> synthetic file system that will collect writes to /net; to simulate a
>>> high-latency file copy, you would run this synthetic fs, then do "9fs
>>> remote; cp /n/remote/somefile .". If it's a control message, that gets
>>> sent to the file immediately, but if it's a data write, that data
>>> actually gets held in a queue until some amount of time (say 50ms) has
>>> passed, to simulate network lag. After that time is up, the fs writes
>>> to the underlying file, the data goes out, etc.
>>>
>>> I have not really done any networking stuff or filesystems work on
>>> Plan 9; thus far, I've confined myself to kernel work. I could be
>>> completely mistaken about how 9P and networking behave, so I'm asking
>>> for opinions and suggestions. For my part, I'm trying to find good
>>> example filesystems to read (I've been looking at gpsfs, for
>>> instance).
>>
>> This seems reasonable, but remember that you're only going to be able
>> to simulate latency in one direction as far as the machine is
>> concerned. So you'll want to have the same configuration on both
>> machines, otherwise things will probably look weird. I'd recommend
>> doing this at a lower level, perhaps introducing a short sleep in IP
>> output so that the latency is consistent across all requests. And of
>> course both machines would need to have this configuration. You could
>> have the stack export another file that you can tune if you want to
>> maintain a file-system approach. But I think a synthetic FS for this
>> is overkill.
>>
>
> My plan was to have each side running the fs. I had thought about
> sticking a sleep in the kernel's ip code right before it writes to the
> device, but since I planned on netbooting the test systems (so much
> easier to bring in a new kernel), I thought it might be advantageous
> to only slow down for one process. I suppose I could make it sleep
> conditionally, like make the process write to a ctl file if it wants
> latency, then sleep only for that pid and its children.

It is actually possible to get to the process sending the packet in
the IP stack.

--dho

>
> John
> --
> "With MPI, familiarity breeds contempt. Contempt and nausea. Contempt,
> nausea, and fear. Contempt, nausea, fear, and .." -- Ron Minnich
>
>

Re: [9fans] P9SSS communiqué

[Devon H. O';Dell]

2010/6/18 EBo :
> On Fri, 18 Jun 2010 12:03:45 -0700, ron minnich 
> wrote:
>> Quick, somebody, snag a BOF slot! They're going to start to go fast.
> maybe
>
> BOF?

Birds of a Feather.

Re: [9fans] offered without comment or judgement

[Devon H. O';Dell]

2010/6/29 Wes Kussmaul :
> Stanley Lieber wrote:
>>
>> Anywhere legitimate identification is used, legitimate identification can
>> be purchased.
>
> There are imperfect but very good ways to protect against that
> vulnerability. They vary with the needs (and budgets) of relying parties.

I'm pretty sure you can't solve the problem. At the end of the day, it
boils down to client-side security and what a person is willing to
defend with their life. It's perfectly feasible to assume that
identity information in a PKI world can be coerced and stolen as
easily as physical identity information such as drivers licenses and
social security cards. The security always breaks down at the personal
level, and most private individuals aren't willing to die to protect
this information.

But you can do at least as good as these forms of ID. PKI requires
knowledge of some sort of passkey. (I just worry about identification
for people who are not smart enough to pick a good key. Which,
unfortunately, is also most people.

--dho

Re: [9fans] Go/Inferno toolchain (Was: comment and newline in

[Devon H. O';Dell]

2010/6/29 Rob Pike :
> On Mon, Jun 28, 2010 at 3:03 PM, Eric Van Hensbergen  wrote:
>> On Sat, Jun 26, 2010 at 4:26 AM,   wrote:
 but I can dig
 them up, clean them up, and share them,
>>>
>>> My particular concern is to encourage convergence towards a single
>>> source distribution rather than divergence as seems to have been the
>>> case so far with Plan 9 native, Inferno, p9p and now Go. What I have
>>> chosen to do, ill-advised as it may be, is to set up a mercurial
>>> repository to re-distribute hacked Go sources that mostly contain
>>> harmless changes that make it possible to compile the Go sources and
>>> specifically the development toolchain with the Plan 9 toolchain.  I'm
>>> presently trying to bring the work I did last year into this
>>> repository and at the same time keep track of the Go release.
>>>
>>
>> I've had a composite repo of previous attempts (well, Sape's previous
>> attempt) at doing this (for some time) at:
>> http://code.google.com/p/go-plan9/
>>
>> I'm happy to add anyone to the committer/admin list, although my
>> preference is to keep the main branch in sync with go and have folks
>> attempts at conversion in sub-branches.  You are of course welcome to
>> maintain your own repo with your own effort, I just figured if
>> everyone had a common place to see what approaches people were using
>> we might get there faster
>>
>>       -eric
>
> Is the porting process active?

I haven't had time, but have made promises. I'll start tonight.

--dho

> -rob
>
>

Re: [9fans] offered without comment or judgement

[Devon H. O';Dell]

2010/6/29 Steve Simon :
>> But you can do at least as good as these forms of ID. PKI requires
>> knowledge of some sort of passkey. (I just worry about identification
>> for people who are not smart enough to pick a good key. Which,
>> unfortunately, is also most people.
>
> My understanding is a passkey just needs sufficent entropy in order to be 
> strong.

Sure. But you can still brute-force a 4-character passkey in a
reasonably short time.

> This can be a few characters drawn from a larger characterset - your password 
> must
> be no more than 16 chars and must contain upper and lower case numbers and 
> punctuation.
>
> Alternatively it could be a long string made up of a restricted character set 
> - your
> pass phrase can consist of any text characters but must not contain long 
> repitations
> and be of at least 200 characters long (say).

This works, but tends to be easy to get out of people or figure out
about people if you know a bit about them.

> Thus a passphrase may be a quote from your favorite movie, a lyric or the 
> like. This
> can then be hashed into a higher entropy string (is this statement true?) 
> used for
> authentication.
>
> I don't understand why modern security systems have an upper limit on 
> passphrase length.

Because people can't remember passwords, and companies don't like
employing full-time password changers.

--dho

> (waits for people who know better to tell him he is dumb).
>
> -Steve
>
>

Re: [9fans] offered without comment or judgement

[Devon H. O';Dell]

2010/6/29 erik quanstrom :
>> > I don't understand why modern security systems have an upper limit on 
>> > passphrase length.
>>
>> Because people can't remember passwords, and companies don't like
>> employing full-time password changers.
>
> i don't understand this comment.  the length of a password
> is only vaguely related to memorability.  long english phrases
> are easy to remember.  unfortunately, they are also easy to
> harvest automaticly, so "four score and seven years ago" might
> be a bad password.

The problem is two-fold:

a) Lay-people are told by all their "computer guru" friends to choose
a password that is difficult to guess. Add numbers, capital letters,
punctuation. Most people don't think in this sort of context, and it
is difficult to remember.

b) People don't regard the idea as particularly important. I know many
people who routinely forget 6-8 character passwords.

The length of the phrase is actually in fact tied explicitly to
memory. The longer a string of characters, the more difficult it is to
remember. That's just fact. You have to practice to recite a
monologue; most people can't just read it once and commit it to
memory. In a similar fashion, most people must either write down a
password (which is dumb) or recite it for a fairly lengthy period of
time to remember it. Noting that places having an upper bound on
password length usually also have other password policies (like "must
contain at least one of each: capital letter, lowercase letter, and
number"). This either means things like initials and important dates
(birthdays, anniversaries, etc) or random gibberish. People are told
not to use something that can be socially engineered, so random
gibberish it is. And people at large just don't get it. It's easily
forgettable.

When talking about symmetric cryptography, "four score and seven years
ago" would probably be a great key. There is no convenient rainbow
table upon which to do a hash lookup. It's sufficiently expensive to
brute-force. The only thing that would give you any sort of advantage
is knowing it was an english phrase and trying all of them.
Misspellings, punctuation, capitalization, and the like can all throw
this off. So picking something directly out of song lyrics, quotes, or
a book of idioms is likely to be useless. Adding in a single period,
comma, or some creative capitalization is fantastic.

But we all know about passwords here.

--dho

> - erik
>
>

Re: [9fans] offered without comment or judgement

[Devon H. O';Dell]

2010/6/29 erik quanstrom :
>> The length of the phrase is actually in fact tied explicitly to
>> memory. The longer a string of characters, the more difficult it is to
>> remember. That's just fact
>
> repeating this doesn't make it true, but it does make
> the phrase easier to remember.  so i think your argument
> is its own defeat.  the gettysburg address is fairly easy for
> me to remember.  but i don't think i'd have such an easy
> time on a randomly-choosen 285-word phrase.
>
> clearly something this long is not necessary.  i'm sure you
> have made-up phrases with non-words you tell our dog.
> that should be easy to remember, not on the internet, and
> have the added bonus that you get to smile while typing your
> password.

You're taking this slightly out of context. I said that this is
coupled with the fact that peers encourage the use of randomness in a
password, and companies enforce password policies that corroborate
this need. I'm not suggesting there's a set length at which point
people have difficulty remembering something, but there is certainly a
correlation: you certainly aren't going to argue the chances of
remembering "fsd&e" are much greater than remembering
"amsdagk3881((@!3ll1..dags8" are you? Similarly, you wouldn't argue
that at some point you spent time learning the Gettysburg Address --
it's not simply something you read once and recalled. (If so, this is
impressive, and you shouldn't argue this as "normal".) Length of the
phrase is certainly tied to the ability to commit it to memory. Yes,
I'm repeating this using empirical evidence as I'm slightly too lazy
to go look up any of the several articles I've read about how we
memorize things and how "brain storage" actually works. There are ways
to bypass this to some degree: adding music or tune, creating rhyme,
setting to iambic pentameter (or any "rhythmization" for that matter).

As computing systems continue to get stronger, the necessity of longer
passphrases will increase -- or slower secure algorithms will need to
be developed. (Or possibly more fitting algorithms, given the
possibility of quantum computing, which may intrinsically provide
solutions to some implementation issues following PKI).

>> When talking about symmetric cryptography, "four score and seven years
>> ago" would probably be a great key. There is no convenient rainbow
>> table upon which to do a hash lookup. It's sufficiently expensive to
>> brute-force.
>
> i'm not convinced of this.  here's why.  i was reading yesterday
> about a research-project that built a machine that could try 1 billion
> rsa keys/sec.  now consider such a machine in the possession of bad
> guys.  for them it would make sense to harvest nearly every phrase
> you can find on the internet and try it.  the hard part would be
> crawling the net.

I certainly have several nonsensical words / names for my cats. None
of them contain numbers or punctuation or anything associated with a
strong passphrase. The longest of these is probably about 12
characters. And a system that can try a billion RSA keys per second is
going to quickly exhaust the relatively short combination of these,
even brute forcing. And you're right -- as I also alluded above, the
continued computing and mathematical advancements made by society at
large will continue to obsolete any statements about what a "good pass
phrase" is.

Right now, it's length and perceived randomness.

People have enough difficulty remembering short passwords. Or creating
"good" passwords in the first place. Upper bounds along with enforcing
permutations are placed to reduce peoples' likelihood of forgetting
them while still providing some level of security. It's not the best
approach, but until people start treating passwords like an ATM card
with a PIN, it's not going to matter much anyway. (Ignoring that PINs
for most cards are only have 9990 or fewer permutations.)

--dho

> - erik
>
>

Re: [9fans] Go/Inferno toolchain (Was: comment and newline in

[Devon H. O';Dell]

2010/6/29 erik quanstrom :
> On Tue Jun 29 16:46:40 EDT 2010, eri...@gmail.com wrote:
>> erik's attempt is now in the go-plan9 repo under its own branch for
>> those that wish to take a look.
>> Hopefully I merged it properly.
>
> it compiles and links, but obviously doesn't run
> since there really is no runtime.

Or syscall implementation or net / fd / etc implementation.
pkg/runtime should be easy. I'll do it tonight.

--dho

> - erik
>
>

Re: [9fans] megamouse?

[Devon H. O';Dell]

See also http://cyborggaming.com/ for complicated mice :)

2010/6/29 David Leimbach :
> http://warmouse.com/pr062810.html
> Looks complicated.
>
>

Re: [9fans] offered without comment or judgement

[Devon H. O';Dell]

2010/6/30 erik quanstrom :
>> I certainly have several nonsensical words / names for my cats. None
>> of them contain numbers or punctuation or anything associated with a
>> strong passphrase. The longest of these is probably about 12
>> characters. And a system that can try a billion RSA keys per second is
>> going to quickly exhaust the relatively short combination of these,
>> even brute forcing. And you're right -- as I also alluded above, the
>
> assuming the attackers have a dictionary of only 50 words that
> contains your nonsense words and assuming unicase and no spaces
> or other punctuation you get 18.9 bits/word.  for a neat 3 word phrase,
> that's 56.8 bits.
>
> for a login, that's plenty since there should be some protection
> against password guessers.  general slowness or just a slow connection
> should be enough to prevent 1e9 guesses/sec.

As networks get faster, it becomes more of an issue. Luckily, most
places that have information about you / your money will lock your
account after N invalid login attempts within a certain time period.
The places that don't probably don't matter. But usually there are
easier ways to get that information anyway.

>> People have enough difficulty remembering short passwords. Or creating
>> "good" passwords in the first place. Upper bounds along with enforcing
>> permutations are placed to reduce peoples' likelihood of forgetting
>> them while still providing some level of security. It's not the best
>> approach, but until people start treating passwords like an ATM card
>> with a PIN, it's not going to matter much anyway. (Ignoring that PINs
>> for most cards are only have 9990 or fewer permutations.)
>
> people will learn.  real computer passwords have not
> been common for very long.
>
> also, an atm card is a 2-factor authentication scheme.  and
> you get 3 guesses.  assuming you can steal the card your chances
> of success are about 3/1.  (wiki says 6/1 due to unused
> numbers http://en.wikipedia.org/wiki/Pin_number#PIN_security)
>
> a better attack might be to shoulder surf and then socially
> engineer the bank into sending you a card.  say by stealing
> it out of the mailbox.

What people do these days is put magnetic readers on the outside of
the reader you're putting your card through. They store information
about N cards, and then write their own cards based on that
information. There's little guesswork involved; there are plenty of
online shops that don't check CVV or shipping address, especially
internationally.

Then you also have keyloggers and screen scrapers. Lots of ways to get
all that information, very, very easily. Social engineering, indeed,
works charms.

> - erik
>
>

Re: [9fans] Auth-ed mount of sources from 9?

[Devon H. O';Dell]

Take a look at 9fs. It's just a wrapper script, but per default passes
a flag to not auth (so that anybody can mount sources without needing
to read manpages, I guess).

--dho

2010/8/2 Venkatesh Srinivas :
> Hi,
>
> How do you mount sources auth-ed from 9?
>
> I must confess I've never done this with 9 by itself, I've always used
> Inferno's "mount -9" (even on plan9)...
>
> -- vs
>

Re: [9fans] source header question

[Devon H. O';Dell]

2010/8/20 EBo :
>
>
>> i guess you answered that yourself. does p9p run on Plan 9?
>
> There a plenty of programs which are made to run under both p9p and plan9.
> So, no the question is still open, but I will rephrase it.
>
> Should any program which can run under p9p and plan9 ever be compiled with
> g++ or another c++ compilers?  Otherwise is it necessary to check for
> __cplusplus?

I think it may be for Sun compilers.

--dho

>   EBo --
>
>
>

Re: [9fans] source header question

[Devon H. O';Dell]

I meant my understanding was that Sun's compiler is a C++ compiler. As
Lyndon points out, C is a subset. I may be wrong, but it can't possibly hurt
to leave it in. Any c++ compiler should be able to compile it.

On Aug 20, 2010 6:00 PM, "Lyndon Nerenberg"  wrote:
>>> Should any program which can run under p9p and plan9 ever be compiled
with
>>> g++ or another c++ compilers? Otherwise is it necessary to check for
>>> __cplusplus?
>
> C is a subset of C++, so a C++ program can validly include native C code.
>

Re: [9fans] plan 9 virtual hosting?

[Devon H. O';Dell]

I at one point had a VPS "solution" using 9vx. Jesus Galan expanded
on that in his summer of code project using server written in Go. If
there is sufficient interest, I'd be happy to start that up again.

--dho

2010/9/7 John Osborne :
> I've been looking around for virtual hosting for plan 9, and I was
> wondering if anyone knew of anything besides what's available at
> freeshell/sdf?
>
> Thanks!
>
> --
> John Osborne
> osbor...@gmail.com/j...@freeshell.org
>
>

Re: [9fans] 9VX failure

[Devon H. O';Dell]

pcap is for the virtual ethernet driver to use the native ip stack.
there's another one that uses TAP that yiyus finalized from someone
else's efforts (I'm not giving due credit here, sorry). If you don't
have pcap just don't build etherve.c.

--dho

2010/9/11 Lucio De Re :
> On Sat, Sep 11, 2010 at 10:24:05AM -0700, ron minnich wrote:
>> >>
>> > Is that included in rminnich/vx32, where default compilation fails with
>> > a missing "pcap.h"?
>>
>> the pcap.h thing is unrelated and I think I'm going to change it so
>> that it builds default with no pcap support, since I'm not the only
>> person seeing this build error.
>>
>> no, I have to get his patch included. I had a question in to his
>> customer support people about the patch first before i went with the
>> patch :-)
>>
> That means that there are two patches required here: Charles' adjustment
> (why have I not seen it, I wonder) and the pcap.h thing.  Can you post
> them here in the interim?  I'm not sure I want to know why pcap.h is
> being included and not found...
>
> ++L
>
>

Re: [9fans] ape sockets and plan9

[Devon H. O';Dell]

2010/12/28 erik quanstrom :
>> On Sun, Dec 26, 2010 at 3:41 AM, Bakul Shah  
>> wrote:
>> > On Sat, 25 Dec 2010 17:04:01 GMT "Steve Simon"   wrote:
>> >> I think this is an artifact of 9vx (not 100% sure though),
>> >
>> > Indeed. Programs under 9vx can make outgoing connections but
>> > can't accept incoming ones because it doesn't really create a
>> > virtual machine -- 9vx makes the connections on behalf of the
>
> that's wrong.  9vx can accept connections.
>
>> > program. IIRC there was some additional code to add a proper
>> > ethernet device (via tap or pcap filtering) but I've never
>> > played with it.  This program works under p9/qemu because
>
> devon o'dell and i did this.  this gives 9vx a full networking
> stack, but it generally requires running as root.

yiyus extended this functionality as part of his SoC project last year
and it's working quite nicely and cross-platform. I'm pretty sure the
code is available in both his and Ron's hg repos of 9vx.

--dho

> - erik
>
>

Re: [9fans] plan9 go output faults on 9vx but ok on cpu

[Devon H. O';Dell]

2011/1/11 erik quanstrom :
> On Tue Jan 11 02:55:42 EST 2011, skip.tavakkol...@gmail.com wrote:
>> hell-o.go is like hello.go but uses println. 8.hell-o works properly
>> on a plan9 cpu. but it faults when running on 9vx. i built vx32 --
>> including 9vx -- on a linux/x86-64 from sources in the last couple of
>> days.
>>
>> % 8.hell-o
>> 8.hell-o 270: suicide: sys: trap: page fault pc=0x10bc
>>
>> /dev/kprint reports:
>> 270 8.hell-o: unhandled fault va=dfffefc0 [218f7fc0] eip=10bc
>> cpu0: registers for 8.hell-o 270
>> FLAGS=0 TRAP=0 ECODE=0 PC=10BC USP=F00
>>   AX 00018D60  BX 0F8C  CX 00018DF8  DX 0001C608
>>   SI 0FA8  DI FFF8  BP 
>
> i'm a little confused.  i thought that 9vx had to be compiled
> 32-bit because it relies on the ancient segment registers.
> whence the 64-bit va?  is it using pae?

64-bit works on linux with some ldt emulation using tls, I believe. It
doesn't work on os x or freebsd.

--dho


> - erik
>
>

Re: [9fans] maintaining p9p

[Devon H. O';Dell]

2011/1/22 Rudolf Sykora :
> Hello,
>
> seems I really don't understand much presently.
>
> The p9p install(1) says:
> 
> Once the system is built for the first time, it can be maintained and
> rebuilt using mk(1). To rebuild individual commands or libraries, run
> mk install and mk clean in the appropriate source directory (see
> src(1)).
> 
>
> I use hg. So from time to time I do 'hg pull -u'. Now, it seems to be
> always safe to run ./INSTALL from the top directory. This, however,
> seems to build everything over again, probably unnecessarily. I
> thought I'd call sth like 'mk install' from the top directory to build
> only new/changed stuff. However there is no mkfile there. How should I
> understand the cited?

I think the implication it is making is essentially that *you* need to
know what you want to rebuild. (Also worth noting that a full rebuild
is usually quite fast.)

Hope that clarifies things,

--dho

> Thanks!
> Ruda
>
>

Re: [9fans] plan9 go output faults on 9vx with rfork

[Devon H. O';Dell]

2011/1/23 Charles Forsyth :
> in the plan 9 world, a 64-bit kernel runs 64-bit applications,
> and 32-bit applications run on a 32-bit kernel.
> a 64-bit 9vx would run programs produced by 6[acl]
> (well, in principle: it would need to be derived from the 64-bit kernel)

It would, but vx32 still just "emulates" an i386. So even if 9vx is
built to run on amd64, the underlying Plan 9 environment still uses
8*.

--dho

Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely

[Devon H. O';Dell]

2011/2/2 erik quanstrom :
>> There was some mention that, during the history of Plan 9, developers
>> had difficulty maintaining two different languages on the system.  I
>> wonder how much of that difficulty would still apply today.  Although
>> the kernel could concievably be translated to a modern compiled
>> language, I doubt it could be written in Go.  If Go were used, then,
>> there would still have to be two languages/compilers/development
>> environments on the system.
>
> although the proof is in the putting, i don't see why a kernel
> in principle, can't be written in go, or a slightly restricted subset
> of go.

There existed part of the tree called "pchw," renamed "tiny" and then
removed due to lack of maintenance that used the xv6 bootloader and
implemented a tiny "Hello, World" kernel. It's clear that some changes
would have to be made for a serious kernel (ensuring not blocking in
an interrupt handler for instance), but it's certainly possible -- and
has been done -- with the language as-is.

--dho

> - erik
>
>

Re: [9fans] 9vx on OpenBSD

[Devon H. O';Dell]

He mentioned it being i386
On Feb 15, 2011 8:19 PM, "ron minnich"  wrote:
> hey is this 64 or 32 bit system?
> uname -a?
> If you told me that already, sorry, I missed it.
>
> ron
>