Re: [9fans] (no subject)

[Digby R.S. Tarvin]

I'd certainly be happy to give it a good home if nobody else has claimed it.

digby...@gmail.com if you want to discuss logistics off the list...

Digby.

On 2 April 2018 at 16:27, Steve Simon  wrote:

> Hi,
>
> I am in the Uk, and moving house.
>
> t have an HP T5325 Thin client which uses the
> same Marvel chipset as the guruplug.
> http://www.parkytowers.me.uk/thin/hp/t5325/index.shtml
>
> Someone got as far as getting one to net boot plan9 but
> didn't (If I remember correctly) get the graphics working.
> http://thread.gmane.org/gmane.os.plan9.general/72588
>
> There is also an SATA interface which can be accessed with
> a little soldering.
> https://habrahabr.ru/post/260631/
>
>
> Free to anyone who wants it - I may ask for a postage
> contribution if you are far from me. Be quick or it goes
> into the skip.
>
> -Steve
>
>

Re: [9fans] (no subject)

[Greg Lewin]

I don't know if this is such common knowledge that nobody has bothered
to mention it (please tell me either way), but much of that is now at

http://9p.io/

http://9p.io/plan9/index.html

and a newer one ?
https://s3-us-west-2.amazonaws.com/belllabs-microsite-plan9/plan9.html



was http://sources.cs.bell-labs.com materially different from these?

Re: [9fans] (no subject)

[Rob Pike]

What's this? https://plan9.io/



On Fri, Jan 5, 2018 at 9:27 AM, Joseph Stewart 
wrote:

> Someone (not me) should make a 9p to S3 service and put all the goodies
> there.
> -joe
>
> On Thu, Jan 4, 2018 at 1:20 PM, Steve Simon  wrote:
>
>> I found the old addresses here:
>>
>> https://dnshistory.org
>>
>> plan9.bell-labs.com was 204.178.31.16
>> and sources.cs.bell-labs.com was 204.178.31.32
>>
>> Both gone too, its not just DNS.
>>
>> I think it has fallen off its perch,
>> it is are pine-ing for the fjords,
>> it is an ex OS research group.
>>
>> -Steve
>>
>>
>

Re: [9fans] (no subject)

[Joseph Stewart]

Someone (not me) should make a 9p to S3 service and put all the goodies
there.
-joe

On Thu, Jan 4, 2018 at 1:20 PM, Steve Simon  wrote:

> I found the old addresses here:
>
> https://dnshistory.org
>
> plan9.bell-labs.com was 204.178.31.16
> and sources.cs.bell-labs.com was 204.178.31.32
>
> Both gone too, its not just DNS.
>
> I think it has fallen off its perch,
> it is are pine-ing for the fjords,
> it is an ex OS research group.
>
> -Steve
>
>

Re: [9fans] (no subject)

[Steve Simon]

I found the old addresses here:

https://dnshistory.org

plan9.bell-labs.com was 204.178.31.16
and sources.cs.bell-labs.com was 204.178.31.32

Both gone too, its not just DNS.

I think it has fallen off its perch,
it is are pine-ing for the fjords,
it is an ex OS research group.

-Steve

Re: [9fans] (no subject)

[Lyndon Nerenberg]

I haven't tried for a few weeks but sources.cs.bell-labs.com
has gone (from DNS), I don't know about the server behind it
as I never kept a record of the IP address.

has the labs server gone for good? (RIP).


The entire cs.bell-labs.com domain is gone.

And given that bell-labs.com has now outsourced their email to 
outlook.com, I think we can safely say the stake has well and truly been 
driven through the heart of this once grand institution.


--lyndon

Re: [9fans] (no subject)

[Steven Stallion]

I've been grateful for the nightly vac jobs I've had going for the
last several years of sources lately, though admittedly it was only
for my tiny corner of contrib.

On Wed, Aug 30, 2017 at 9:12 AM, Steve Simon  wrote:
> Hi,
>
> I haven't looked for a while, but http://plan9.bell-labs.com has gone,
> and http://plan9.bell-labs.com/sources/ is broken -
> /usr/web/plan9/sources.html has disappeared from the web server.
>
> Is there anyone left at the labs who might be able to fix at least the
> web access to sources, it does look rather sad.
>
> https://9p.io/plan9 is still available, thank goodness.
>
> -Steve
>

Re: [9fans] (no subject)

[Bakul Shah]

On Fri, 02 Dec 2016 11:44:52 GMT "Steve Simon"  wrote:
> Hi all,
> 
> Anyone have some small and neat code (in C) to parse ISO8601 date/time
> notation with all its glorious options?
> 
> Its not hard to write, but it would be time consuming to test all the varients
> so if anyone has some code, or knows of some in /sys/src that I have missed,
> please tell me.

May be this will help:
ftp://ftp.ripe.net/test-traffic/ROOT/delayplots/iso8601.C

Re: [9fans] (no subject)

[Steve Simon]

The ones that have bitten me have been ed, du and ls.

I fixed cleanname not to restamp the terminating zero on the string
if its already there which makes cleanname(.) work (for ls).

du's problem is wrapped in String.h issues and I haven't dug any more.

ed is exactly as you say.

I assumed the problem was more extensive, berhaps its a non-problem
with a couple of tiny fixes.

Thanks,

-Steve

Re: [9fans] (no subject)

[cinap_lenrek]

what are the programs passing string constants? only found:

ed.c:160:   tfname = mktemp(/tmp/eX);

all the other programs copy the template in a buffer
before passing it to mktemp(). i think it would be
better to just fix ed no?

--
cinap

Re: [9fans] (no subject)

[Ingo Krabbe]

 In my experience a VESA BIOS will sometimes report
 different available modes depending on the detected
 EDID.

 I have no problem believing this is true, but I'm also sure  there's more 
 to it than that.
 
 I agree. One problem is that these things are all different,
 almost completely undocumented, and implement non-standard
 modes seemingly at random. Some people involved with various
 OSX86[0] efforts have developed methods for probing (and in
 some cases, modifiying) the VESA BIOS on some cards. All
 kinds of strange behaviors have been observed.
 

In qemu the emulated controller seems to support 1920x1200x{16,24,32} as well 
as some other modes

term% aux/vga -m vesa -p
warning: reading edid: VBE error 0x0100
vesa flagUlinear|Hlinear
vesa sigVESA 2.0
vesa oemBochs/Plex86 VBE(C) 2003 
http://savannah.nongnu.org/projects/vgabios/ 0.2
vesa vendor Bochs/Plex86 Developers
vesa productBochs/Plex86 VBE Adapter
vesa rev$Id: vbe.c,v 1.64 2011/07/19 18:25:05 vruppert Exp $
vesa cap 8-bit-dac
vesa mem16777216
[...]
vesa mode   0x187 1920x1200x16 r5g6b5 direct
vesa mode   0x188 1920x1200x24 r8g8b8 direct
vesa mode   0x189 1920x1200x32 x8r8g8b8 direct
vesa mode   0x18a 2560x1600x16 r5g6b5 direct
vesa mode   0x18b 2560x1600x24 r8g8b8 direct
vesa mode   0x18c 2560x1600x32 x8r8g8b8 direct
[...]

you may be able to try these with your monitors as a start.

 I'd be interested in a survey with broader results
 than just dueling anecdotes
 
 I haven't made any attempt to catalogue VESA vs EDID
 discrepancies, but I do keep a small archive of hardware
 info here:
 
 http://plan9.stanleylieber.com/hardware
 
 We try to collect the sysinfo[1] output for as many
 systems as possible, for later reference.
 
 sl
 
 [0] http://www.osx86project.org
 [1] http://man.aiju.de/1/sysinfo

Re: [9fans] (no subject)

[Anthony Sorace]

I'd love to hear about positive results here. Cards with VESA entries for 
non-4:3 modes are rare; I'm not sure I've ever seen one. The Pi, by contrast, 
drives my 16:10 high-res monitor without issues, which is the main reason it's 
my main Plan 9 terminal these days.

Anthony



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [9fans] (no subject)

[erik quanstrom]

 I have got hold of a new 1920x1200 monitor but no card I can find seems
 to support it on plan9 - Even cards that claim this resolution and higher
 don't have the vesa mode entry.
 
 Anyone any thoughts, or suggestions of cards that do
 have the apropriate high resolution VESA modes?

as anthony hints, vesa doesn't define non 4:3 modes
in the standard.  and vesa bioses don't typicall provide
em.

- erik

Re: [9fans] (no subject)

[Aram Hăvărneanu]

On Tue, Apr 15, 2014 at 5:36 PM, Anthony Sorace a...@9srv.net wrote:
 Cards with VESA entries for non-4:3 modes are rare; I'm not sure I've ever 
 seen one.


On Tue, Apr 15, 2014 at 5:50 PM, erik quanstrom quans...@quanstro.net wrote:
 and vesa bioses don't typicall provide em.

Funny, I have 10+ machines that all use vesa, all widescreen. I have
never seen a vesa BIOS that didn't provide widescreen modes. I'm sure
they exist, but they certainly are not rare. I drive 1920x1200x32 with
vesa and Cinap's realemu just fine.

-- 
Aram Hăvărneanu

Re: [9fans] (no subject)

[erik quanstrom]

 Funny, I have 10+ machines that all use vesa, all widescreen. I have
 never seen a vesa BIOS that didn't provide widescreen modes. I'm sure
 they exist, but they certainly are not rare. I drive 1920x1200x32 with
 vesa and Cinap's realemu just fine.

my experience has been similar to anthony's.  i have  10 machines, and
none of them offer a non 4:3 mode from onboard graphics, at least when
attached to a 4:3 monitor.  i suspect that the modes offered may be different
when different montors are attached, but i haven't proved that.

what kind of video cards/onboard video are you using?

- erik

Re: [9fans] (no subject)

[sl]

In my experience a VESA BIOS will sometimes report
different available modes depending on the detected
EDID.

The following cards reported the following modes when
the following EDIDs were detected:

---

1.0.0:  vid  03.00.00 1106/3344  11 0:f008 67108864 1:f400 16777216
VIA Technologies, Inc. VT3314 VIA/S3G UniChrome Pro IGP

@{rfork n; aux/realemu; aux/vga -p}
vesa flagUlinear|Hlinear|Fsnarf
vesa sigVESA 3.0
vesa oemVIA P4N800 PRO
 1.0
vesa vendor 
vesa product
vesa rev
vesa cap 8-bit-dac
vesa mem16777216
vesa mode   0x101 640x480x8 m8 packed
vesa mode   0x111 640x480x16 r5g6b5 direct
vesa mode   0x112 640x480x32 x8r8g8b8 direct
vesa mode   0x171 720x480x8 m8 packed
vesa mode   0x173 720x480x16 r5g6b5 direct
vesa mode   0x175 720x480x32 x8r8g8b8 direct
vesa mode   0x1b9 720x540x8 m8 packed
vesa mode   0x1ba 720x540x16 r5g6b5 direct
vesa mode   0x1bb 720x540x32 x8r8g8b8 direct
vesa mode   0x17c 720x576x8 m8 packed
vesa mode   0x17e 720x576x16 r5g6b5 direct
vesa mode   0x17f 720x576x32 x8r8g8b8 direct
vesa mode   0x22e 800x480x8 m8 packed
vesa mode   0x22f 800x480x16 r5g6b5 direct
vesa mode   0x230 800x480x32 x8r8g8b8 direct
vesa mode   0x103 800x600x8 m8 packed
vesa mode   0x114 800x600x16 r5g6b5 direct
vesa mode   0x115 800x600x32 x8r8g8b8 direct
vesa mode   0x15c 848x480x8 m8 packed
vesa mode   0x15d 848x480x16 r5g6b5 direct
vesa mode   0x15f 848x480x32 x8r8g8b8 direct
vesa mode   0x196 852x480x8 m8 packed
vesa mode   0x197 852x480x16 r5g6b5 direct
vesa mode   0x198 852x480x32 x8r8g8b8 direct
vesa mode   0x222 853x480x8 m8 packed
vesa mode   0x223 853x480x16 r5g6b5 direct
vesa mode   0x224 853x480x32 x8r8g8b8 direct
vesa mode   0x128 960x600x8 m8 packed
vesa mode   0x129 960x600x16 r5g6b5 direct
vesa mode   0x12a 960x600x32 x8r8g8b8 direct
vesa mode   0x193 1024x512x8 m8 packed
vesa mode   0x194 1024x512x16 r5g6b5 direct
vesa mode   0x195 1024x512x32 x8r8g8b8 direct
vesa mode   0x20b 1024x576x8 m8 packed
vesa mode   0x20c 1024x576x16 r5g6b5 direct
vesa mode   0x20d 1024x576x32 x8r8g8b8 direct
vesa mode   0x200 1024x600x8 m8 packed
vesa mode   0x201 1024x600x16 r5g6b5 direct
vesa mode   0x203 1024x600x32 x8r8g8b8 direct
vesa mode   0x204 1024x640x8 m8 packed
vesa mode   0x205 1024x640x16 r5g6b5 direct
vesa mode   0x206 1024x640x32 x8r8g8b8 direct
vesa mode   0x105 1024x768x8 m8 packed
vesa mode   0x117 1024x768x16 r5g6b5 direct
vesa mode   0x118 1024x768x32 x8r8g8b8 direct
vesa mode   0x161 1152x864x8 m8 packed
vesa mode   0x163 1152x864x16 r5g6b5 direct
vesa mode   0x164 1152x864x32 x8r8g8b8 direct
vesa mode   0x125 1280x720x8 m8 packed
vesa mode   0x126 1280x720x16 r5g6b5 direct
vesa mode   0x127 1280x720x32 x8r8g8b8 direct
vesa mode   0x179 1280x768x8 m8 packed
vesa mode   0x17a 1280x768x16 r5g6b5 direct
vesa mode   0x17b 1280x768x32 x8r8g8b8 direct
vesa mode   0x1b6 1280x800x8 m8 packed
vesa mode   0x1b7 1280x800x16 r5g6b5 direct
vesa mode   0x1b8 1280x800x32 x8r8g8b8 direct
vesa mode   0x13f 1280x960x8 m8 packed
vesa mode   0x14f 1280x960x16 r5g6b5 direct
vesa mode   0x16a 1280x960x32 x8r8g8b8 direct
vesa mode   0x107 1280x1024x8 m8 packed
vesa mode   0x11a 1280x1024x16 r5g6b5 direct
vesa mode   0x11b 1280x1024x32 x8r8g8b8 direct
vesa mode   0x16c 1360x768x8 m8 packed
vesa mode   0x16d 1360x768x16 r5g6b5 direct
vesa mode   0x16e 1360x768x32 x8r8g8b8 direct
vesa mode   0x183 1366x768x8 m8 packed
vesa mode   0x184 1366x768x16 r5g6b5 direct
vesa mode   0x185 1366x768x32 x8r8g8b8 direct
vesa mode   0x13b 1400x1050x8 m8 packed
vesa mode   0x13c 1400x1050x16 r5g6b5 direct
vesa mode   0x13e 1400x1050x32 x8r8g8b8 direct
vesa mode   0x211 1440x900x8 m8 packed
vesa mode   0x212 1440x900x16 r5g6b5 direct
vesa mode   0x213 1440x900x32 x8r8g8b8 direct
vesa mode   0x20e 1600x1024x8 m8 packed
vesa mode   0x20f 1600x1024x16 r5g6b5 direct
vesa mode   0x210 1600x1024x32 x8r8g8b8 direct
vesa mode   0x120 1600x1200x8 m8 packed
vesa mode   0x122 1600x1200x16 r5g6b5 direct
vesa mode   0x124 1600x1200x32 x8r8g8b8 direct
vesa mode   0x12b 1680x1050x8 m8 packed
vesa mode   0x12c 1680x1050x16 r5g6b5 direct
vesa mode   0x12d 1680x1050x32 x8r8g8b8 direct
vesa mode   0x166 1920x1080x8 m8 packed
vesa mode   0x167 1920x1080x16 r5g6b5 direct
vesa mode  

Re: [9fans] (no subject)

[erik quanstrom]

thanks for the confirmation!

- erik

Re: [9fans] (no subject)

[arisawa]

Hello,

the result below is on one of my machine with  GA-H61M-USB3H.
the MB is nice with 9front.
maia% @{rfork n; aux/realemu; aux/vga -p}|grep  '^vesa mode' 
vesa mode   0x107 1280x1024x8 m8 packed
vesa mode   0x11a 1280x1024x16 r5g6b5 direct
vesa mode   0x11b 1280x1024x32 x8r8g8b8 direct
vesa mode   0x105 1024x768x8 m8 packed
vesa mode   0x117 1024x768x16 r5g6b5 direct
vesa mode   0x118 1024x768x32 x8r8g8b8 direct
vesa mode   0x112 640x480x32 x8r8g8b8 direct
vesa mode   0x114 800x600x16 r5g6b5 direct
vesa mode   0x115 800x600x32 x8r8g8b8 direct
vesa mode   0x101 640x480x8 m8 packed
vesa mode   0x103 800x600x8 m8 packed
vesa mode   0x111 640x480x16 r5g6b5 direct
vesa mode   0x17d 1920x1080x8 m8 packed
vesa mode   0x17e 1920x1080x16 r5g6b5 direct
vesa mode   0x17f 1920x1080x32 x8r8g8b8 direct
maia% 
and
maia% echo $vgasize
1920x1080x16
maia% 

I have wide screen display with DVI and is quite comfortable.
NOTE that VGA connector cannot live with VESA mode on the MB!
probably MB dependent.

Kenji Arisawa

2014/04/16 7:42、erik quanstrom quans...@quanstro.net のメール：

 thanks for the confirmation!
 
 - erik
 

Re: [9fans] (no subject)

[Anthony Sorace]

 In my experience a VESA BIOS will sometimes report
 different available modes depending on the detected
 EDID.

I have no problem believing this is true, but I'm also sure there's more to it 
than that. The device I'm most frustrated with is a Thinkpad, reporting on the 
built-in display, for example. I've seen the same on at least one other laptop 
with a widescreen display (some HP thing), and at least a pair of desktop 
graphics cards with a 16:10 monitor attached. Very frustrating. I'd be 
interested in a survey with broader results than just dueling anecdotes; I'd be 
happy to know I'd just gotten unlucky.
Anthony



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [9fans] (no subject)

[sl]

 In my experience a VESA BIOS will sometimes report
 different available modes depending on the detected
 EDID.

 I have no problem believing this is true, but I'm also sure  there's more to 
 it than that.

I agree. One problem is that these things are all different,
almost completely undocumented, and implement non-standard
modes seemingly at random. Some people involved with various
OSX86[0] efforts have developed methods for probing (and in
some cases, modifiying) the VESA BIOS on some cards. All
kinds of strange behaviors have been observed.


 I'd be interested in a survey with broader results
 than just dueling anecdotes

I haven't made any attempt to catalogue VESA vs EDID
discrepancies, but I do keep a small archive of hardware
info here:

http://plan9.stanleylieber.com/hardware

We try to collect the sysinfo[1] output for as many
systems as possible, for later reference.

sl

[0] http://www.osx86project.org
[1] http://man.aiju.de/1/sysinfo

Re: [9fans] (no subject)

[erik quanstrom]

On Sat Mar 15 19:27:44 EDT 2014, jaketodd...@gmail.com wrote:

 Audio worked with hiro's drawterm and intel hda in 9front.

since you mention the host's hardware, i'm a little confused.  the host's
hardware doesn't make any difference.  it's drawterm's bridge between
#A and the host's audio device that's the question.  has someone
done this for os-x?  if so, where's the code?

- erik

Re: [9fans] (no subject)

[Jacob Todd]

Audio worked with hiro's drawterm and intel hda in 9front.

Re: [9fans] (no subject)

[Jeff Sickel]

It’s on the back burner for osx.  Well, maybe the storage bin waiting for a 
sifter.

-jas


On Mar 15, 2014, at 6:07 PM, Steve Simon st...@quintile.net wrote:

 Subject Drawterm windows audio?
 
 Anyone added an audio driver to windows or osx drawterms?
 
 -Steve
 

Re: [9fans] (no subject)

[sl]

 what would be helpful, and move the discussion forward, is if someone
 could try to replicate this with unclean shutdowns after various file
 operations.  i suspect that it won't repeat.  but either way, it
 will move the discussion forward.

For what it's worth, unclean shutdowns resulted in lost data for me
under both fossil and hjfs. In my experience unclean shutdowns never
seemed to cause problems for cwfs64x.

In the case of both fossil and hjfs it is sometimes possible to repair
the damage. Other times it is not. Fossil has vocal supporters, while
hjfs is still marked experimental (bugs are actually getting fixed). The
problem for users is that when you boot the system and you can't access
your files, it gets in the way of the reason you booted the system in the
first place. Persistence of this condition is unacceptable.

I ran fossil on both hardware and under different virtual machines and
eventually experienced file corruption on every single install. Once I
found out about cwfs I switched to that and had zero problems, ever.
Okay, I said to myself, this is where I'll stay. Anecdotal? You betcha.
But cwfs never lost data.

We can argue about who misread what messages forever. The fact is
that some of us had problems with fossil and then found ways around
the problems. For some of us that meant patching fossil or changing
the way we used fossil. For others, it meant finding some other
filesystem. Saying there is no problem changes nothing. You can
debate with the Grand Canyon for hours, but when you walk off the
cliff you're still going to plummet to the ground.

http://img.stanleylieber.com/src/15358/img/1370274020.jpg

-sl

Re: [9fans] (no subject)

[Charles Forsyth]

it's a shell script that copies updated files from a Bell Labs system to
sources.

Re: [9fans] (no subject)

[Aram Hăvărneanu]

erik quanstrom wrote:
 for me, the most important questions are
 - how do i set up a raid/hot spares, and
 - can i do this without rebooting.

Of course, and right now I'm doing exactly that using a different
operating system.  Can I do that on Plan 9? I don't know, I'm trying
to find out without much success.

 wikipedia.

I really don't understand why are you sending me to read wikipedia.
Generally, I think of myself as a decent speaker, I know how to make
myself clear.  It's obvious that in this case I failed.  In my
previous job I have worked on a file system that among other things
also implements redundancy.  If I implemented these things I guess I
know about them without having to read wikipedia.

The machine I use today for storage also runs bits of my own software.
 It's very easy to administer, tells me when disks are broken, I can
just add disks for more storage without reboot and I can hot swap
disks.  Can Plan 9 do this?  I don't know, I guess not?  It's fine by
me, I'm willing to sacrifice performance and ease of administration
for an operating system I like better.  I'm willing to implement
myself what I need and doesn't exist yet, though I have a very hard
time understanding what's missing from these very, very vague
discussions.

 there's nothing strange about a sata device or even a raid of
 various devices of any type being presented with an ide programming
 interface.  one could just as easily slap an ahci programming interface
 on, but either requires translation software/hardware.

I agree that's nothing inherently strange, but in practice it's
uncommon, at least in my experience.  But then again, I'm not a
hardware guy, so my experience means nothing.

-- 
Aram Hăvărneanu

Re: [9fans] (no subject)

[Aram Hăvărneanu]

 the motivation behind my question is that it's not clear to me that there is
 such a thing as pure hardware raid.  if someone knows of something that
 implements the entire read/write path without a cpu, even with a degraded
 or rebuilding raid, i'd be very interested in that.

Ahh, I see what you mean.  I agree that probably there is no such
thing as RAID purely implemented in hardware.  I think for most people
the hardware epithet is used to describe a black box where the user
doesn't have access to it's internal gearing, be it hardware or
software.  A microwave is a hardware device for its users because the
users don't need to care if the unit has firmware, discrete
electronics or mechanical gears.

Probably a better term would be to always use the term appliance,
instead of this hardware/softare false dichotomy.

 (see wiki's raid article.)

Plan 9 wiki? It mentions SiL 3112 SATA, 3114 SATA/RAID and VIA 82C686,
VT8237 SATA/RAID, strangely, under IDE section.

I haven't found yet relevant information about the SiL stuff, but the
VIA stuff is what Adaptec calls HostRAID and Linux fakeRAID.

A Happy New Year!

-- 
Aram Hăvărneanu

Re: [9fans] (no subject)

[erik quanstrom]

  (see wiki's raid article.)
 
 Plan 9 wiki? It mentions SiL 3112 SATA, 3114 SATA/RAID and VIA 82C686,
 VT8237 SATA/RAID, strangely, under IDE section.
 
 I haven't found yet relevant information about the SiL stuff, but the
 VIA stuff is what Adaptec calls HostRAID and Linux fakeRAID.

wikipedia.

there's nothing strange about a sata device or even a raid of
various devices of any type being presented with an ide programming
interface.  one could just as easily slap an ahci programming interface
on, but either requires translation software/hardware.

for me, the most important questions are
- how do i set up a raid/hot spares, and
- can i do this without rebooting.

- erik

Re: [9fans] (no subject)

[Jack Norton]

On 12/30/2011 12:08 PM, erik quanstrom wrote:

It might be a bit
much for home use, but if I had a little bit of a budget I'd use Coraid's AoE
stuff as the basis for my storage.


Yeah, it's pretty overkill.  I've previously worked at a storage
company as a file system guy and now I have at home a nice array with
ZFS on top.  It works great, but I want to scale down.  I want less
stuff, not more.  And I want to use Plan9, not Solaris.


aoe doesn't require solaris, or any other operating system.
you can use it directly with a plan 9 file server, as i do.

- erik



I don't think he was implying that one needed the other.  In any case I 
figured I would ask -- are there any plans for a small scale AoE 
appliance from coraid?  Didn't there used to be a single drive AoE kit 
long ago?
What is the list's personal/home usage of AoE like?  Do you guys use 
generic hardware and something like vblade (or those other ones people 
have made for linux like ggblade or whatever it is called)?


-Jack

Re: [9fans] (no subject)

[erik quanstrom]

 I don't think he was implying that one needed the other.  In any case I 
 figured I would ask -- are there any plans for a small scale AoE 
 appliance from coraid?  Didn't there used to be a single drive AoE kit 
 long ago?

there was once a single drive pata unit.

 What is the list's personal/home usage of AoE like?  Do you guys use 
 generic hardware and something like vblade (or those other ones people 
 have made for linux like ggblade or whatever it is called)?

http://www.quanstro.net/plan9/fs.html

i also use vblade(8) on plan 9 for testing.

- erik

Re: [9fans] (no subject)

[Aram Hăvărneanu]

 aoe doesn't require solaris, or any other operating system.
 you can use it directly with a plan 9 file server, as i do.

Of course AoE doesn't require much, my comment was in the context of
Coraid's hardware appliance.

I don't have much use for AoE at home.  At one point I used it to
network boot machines, but I only have laptops now, which have local
disks because I need to use them disconnected from the network
sometimes.

I need a higher level protocol like 9p or venti, and I'd rather have a
single Plan 9 machine with direct attached disks serving everything
than a Plan 9 front end serving 9p and another machine providing AoE
to it.  I have way, way to many machines. Yesterday I've thrown away
5.  I need less machines, not more :-).

Does the Coraid applience implement RAID in hardware or does it use
fs(3) or another software solution?

-- 
Aram Hăvărneanu

Re: [9fans] (no subject)

[Bakul Shah]

My fileserver is running freebsd zfs. Basically one machine for nfs, venti, 
cifs, timemachine + sundry other services. This has worked well since 2005. 
Initially I used h/w raid under zfs. This was a mistake, forcibly corrected 
when my machine died. Now I use raidz. Since then I have replaced disks with 
much bigger disks without taking the machine down, upgraded the os  zpool/zfs 
versions a couple of times (could've done without them but I prefer to run the 
latest stable release). Except for these events it has required hardly any 
maintenance (just checking vital signs like fan speed, any disk errors in 
weekly zpool scrub etc). One issue is FreeBSD install still doesn't install on 
zfs. But you can run a minimal root off a USB disk and manually setup zfs 
(which is pretty easy). I should probably run an AOE server on it as well! When 
I next replace this machine I will see if I can create a USB disk image.

On Dec 30, 2011, at 12:35 PM, Aram Hăvărneanu ara...@mgk.ro wrote:

 aoe doesn't require solaris, or any other operating system.
 you can use it directly with a plan 9 file server, as i do.
 
 Of course AoE doesn't require much, my comment was in the context of
 Coraid's hardware appliance.
 
 I don't have much use for AoE at home.  At one point I used it to
 network boot machines, but I only have laptops now, which have local
 disks because I need to use them disconnected from the network
 sometimes.
 
 I need a higher level protocol like 9p or venti, and I'd rather have a
 single Plan 9 machine with direct attached disks serving everything
 than a Plan 9 front end serving 9p and another machine providing AoE
 to it.  I have way, way to many machines. Yesterday I've thrown away
 5.  I need less machines, not more :-).
 
 Does the Coraid applience implement RAID in hardware or does it use
 fs(3) or another software solution?
 
 -- 
 Aram Hăvărneanu
 

Re: [9fans] (no subject)

[erik quanstrom]

 I don't have much use for AoE at home.  At one point I used it to
 network boot machines, but I only have laptops now, which have local
 disks because I need to use them disconnected from the network
 sometimes.
 
 I need a higher level protocol like 9p or venti, and I'd rather have a
 single Plan 9 machine with direct attached disks serving everything
 than a Plan 9 front end serving 9p and another machine providing AoE
 to it.  I have way, way to many machines. Yesterday I've thrown away
 5.  I need less machines, not more :-).

sure, but you haven't answered the question of how to do redundancy
and recovery.  aoe is a good way to isolate these functions into an appliance.

 Does the Coraid applience implement RAID in hardware or does it use
 fs(3) or another software solution?

if a coraid appliance were pcie-attached rather than ethernet attached,
would you still ask this question?  do you think the block diagram of coraid
hardware looks fundamentally different than the block diagram of a raid
card?

- erik

Re: [9fans] (no subject)

[Charles Forsyth]

Could you do the latter without taking the machine down?

On 30 December 2011 21:28, Bakul Shah ba...@bitblocks.com wrote:

 Since then I have replaced disks with much bigger disks without taking the
 machine down, upgraded the os  zpool/zfs versions a couple of times

Re: [9fans] (no subject)

[Aram Hăvărneanu]

Charles Forsyth wrote:
 Since then I have replaced disks with much bigger disks without taking the
 machine down, upgraded the os  zpool/zfs versions a couple of times

 Could you do the latter without taking the machine down?

Upgrade zpool/zfs version yes, os, no.

-- 
Aram Hăvărneanu

Re: [9fans] (no subject)

[Jack Norton]

On 12/30/2011 3:05 PM, erik quanstrom wrote:

Does the Coraid applience implement RAID in hardware or does it use
fs(3) or another software solution?


if a coraid appliance were pcie-attached rather than ethernet attached,
would you still ask this question?  do you think the block diagram of coraid
hardware looks fundamentally different than the block diagram of a raid
card?

- erik



I think he is trying to get you to divulge details on the software 
running on the coraid appliance itself.  We all know it is plan 9 based 
(right?), so it would be interesting to know how this extra 
functionality of raid was added.  I know these are trade secrets though 
so I've never asked.


I would still ask that question if it were pcie attached.  Curiosity 
will be my undoing though.


-Jack

Re: [9fans] (no subject)

[Bakul Shah]

On Fri, 30 Dec 2011 21:34:39 GMT Charles Forsyth charles.fors...@gmail.com  
wrote:
 
 Could you do the latter without taking the machine down?
 
 On 30 December 2011 21:28, Bakul Shah ba...@bitblocks.com wrote:
 
  Since then I have replaced disks with much bigger disks without taking the
  machine down, upgraded the os  zpool/zfs versions a couple of times

zpool/zfs upgrade? Yes. Don't recall if I had to reboot
afterwards.  Resilvering to replace a disk takes a long time
so not having to take the machine for hours is nice.  A quick
reboot is no big deal.

Re: [9fans] (no subject)

[Aram Hăvărneanu]

 zpool/zfs upgrade? Yes. Don't recall if I had to reboot
 afterwards.

You don't.

-- 
Aram Hăvărneanu

Re: [9fans] (no subject)

[Charles Forsyth]

That's upgrading the stored formats, not the in-kernel(?) software support
for a particular version?

On 30 December 2011 21:56, Aram Hăvărneanu ara...@mgk.ro wrote:

  zpool/zfs upgrade? Yes. Don't recall if I had to reboot
  afterwards.

 You don't.

 --
 Aram Hăvărneanu

Re: [9fans] (no subject)

[Lyndon Nerenberg]

On 2011-12-30, at 14:41 PM, Charles Forsyth wrote:

 That's upgrading the stored formats,

Yes.

signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [9fans] (no subject)

[erik quanstrom]

  if a coraid appliance were pcie-attached rather than ethernet attached,
  would you still ask this question?  do you think the block diagram of coraid
  hardware looks fundamentally different than the block diagram of a raid
  card?
 
 It's just curiosity.  I know the appliance is Plan 9 based.  If it
 uses an off-the-shelf RAID chip I might buy a card with that chip
 since it works in Plan 9.  If it's fs(3) I know fs(3) is good enough
 for my needs.  If it's something else at least I know fs(3) is not
 good enough and I might be tempted to write something myself.  So yes,
 I'd ask even if it was a PCIe card instead of network appliance.

the motivation behind my question is that it's not clear to me that there is
such a thing as pure hardware raid.  if someone knows of something that
implements the entire read/write path without a cpu, even with a degraded
or rebuilding raid, i'd be very interested in that.  but as far as i know, 
there's
always a processor in there on the other side of the bus.  in case of aoe, the
bus is ethernet and for a hardware raid card, it's usually some form
of pci.

(see wiki's raid article.)

- erik

Re: [9fans] (no subject)

[erik quanstrom]

On Tue Aug  9 08:41:44 EDT 2011, st...@quintile.net wrote:
 Subject rfork N
 
 I want to construct a new namespace for an app, including a new root dir.
 I was hoping to do this with a few lines of script starting with rfork N,
 however this seems to be a dead end.
 
 I can still access kernel devices directly using the # escape in filenames,
 which includes '#s/fossil' for my file server. However I cannot get access
 to mount(1) so I can never access any files in that fossil.
 
 is rfork N in rc useless, and do I get a prize for noticing?
 
 (or is it a lack of vision on my behalf as usual?)

don't you just want rfork Nm?

- erik

Re: [9fans] (no subject)

[Steve Simon]

 don't you just want rfork Nm?

I don't think so, that is worse, this would really mean
I couldn't mount anything.

I don't mind the new app adding mounts if it wants to, but
I want it to start with a new root dir and children, so
I need to flush out the old namespace.

the problem is as soon as I do that I lost contact with the
mount command and as its not a shell builtin this means I
can never get back the namespace I have lost.

I am stuck in no-mans-land.

its easy enough to experiment:
open a window
type rfork N
try to get ls to work.

I can pass an open file descriptor across
the rfork N boundry, but I still cannot mount it.

The only solution I can see is to write some C code, but
I was hoping somone might see a trick I missed.

-Steve

Re: [9fans] (no subject)

[Steve Simon]

I don't manage 1920x1080 but I do get 1600x1200x16 from my 
NVidia GeForce2 MX-200. This card is old but its what is in the
machine and its works.

I must say lots of pixels makes a very nice interface.

-Steve

Re: [9fans] (no subject)

[erik quanstrom]

On Mon Apr 25 03:43:36 EDT 2011, st...@quintile.net wrote:
 I don't manage 1920x1080 but I do get 1600x1200x16 from my 
 NVidia GeForce2 MX-200. This card is old but its what is in the
 machine and its works.
 
 I must say lots of pixels makes a very nice interface.

i thought i responded to this.  i run the same resolution in
vesa mode on this

; pci 1002/9714
1002/9714
ATI Technologies Inc RS880 [Radeon HD 4290]

this sucker supports
vesa mode   0x1e5 1920x1440x16 r5g6b5 direct
vesa mode   0x1e6 1920x1440x32 r8g8b8 direct

but my monitor isn't that good.  i also run with intel
integrated graphics on an atom motherboard.

- erik

Re: [9fans] (no subject)

[cinap_lenrek]

so the front fell off?

--
cinap
---BeginMessage---
On Mon Mar 28 08:07:44 EDT 2011, st...@quintile.net wrote:
 looks like your web server (quanstro.net) is down.
 

yes, we had a big thunderstorm come by and knock
out power for 4 hrs.  we had a strike close enough to
the house to blow up lightbulbs and shoot flames out
of sockets shortly after power came back on, so i lost
some ethernet interfaces, including the web/auth/ftp
server's.  both my lines are down, too.

note to self: stop buying crappy consumer motherboards.

hopefully i'll get it all replaced or patched up this afternoon.  and
with luck, the phone company will have things fixed
as well.

- erik
---End Message---

Re: [9fans] (no subject)

[ron minnich]

Erik, sounds like you need a motor generator ... flames from outlets
... wow ... maybe some opto isolators with a 2 meter air gap too :-)

ron

Re: [9fans] (no subject)

[erik quanstrom]

On Mon Mar 28 11:20:39 EDT 2011, rminn...@gmail.com wrote:
 Erik, sounds like you need a motor generator ... flames from outlets
 ... wow ... maybe some opto isolators with a 2 meter air gap too :-)

evidently the strike was closer to the neighbors.  they lost
all their major appliances, and a heat pump.  (i thought you
couldn't kill them.)

fire breathing refrigerator!

- erik

Re: [9fans] (no subject)

[Patrick Kelly]

POSIX is a standard in which hardly anyone actually adheres too. AIX POSIX
is not Solaris POSIX is not Linux POSIX etc. What good is a standard that
isn't truthfully standardised. Alas I will say that POSIX does add quite a
bit more cross platfom conformity than some other... things... but there a
better solutions.

While Plan 9 has some similiaritys to UNIX, it is not. Porting UNIX tools to
something that is not is just not a good idea. You don't port a lawnmower
engine to a Ferrari. You don't port horse tranquilizer to a rat.

Should the few of you continue on this path, I would also ask you to port
the ReactOS framework over to Plan9, and the Haiku kits, and AROS's
librarys, and... and...

A big reason for the creation of Plan 9 was to get away from the complexity,
from the everything but the kitchen sink mentality. I would strongly
suggest reading the articles on http://plan9.bell-labs.com/sys/doc/ before
you continue your massochistic crusade.
On Tue, Mar 9, 2010 at 12:50 AM, Lyndon Nerenberg (VE6BBM/VE7TFX) 
lyn...@orthanc.ca wrote:

  surely your joking, mr. nerenberg!

 Nope.  Over the past 10 years I can only think of one or two projects
 I did that required platform-specific optimizations outside of POSIX.

Re: [9fans] (no subject)

[lucio]

 Thing is, It's autoconf that needs careful
 redesign
 
 s/redesign/annihilation/

Yes, but even if everybody were to switch to Linux/386 as the only
available platform, there would remain a niche for something like
autoconf, programmers just don't change habits very quickly.  The
trick is to make sure the next instance isn't as monstrous, knowing
that normally the next generation is more monstrous than the previous
one.

Nice thing is, annihilation does not have to be careful :-)

++L

Re: [9fans] (no subject)

[Patrick Kelly]

 -Original Message-
 From: 9fans-boun...@9fans.net [mailto:9fans-boun...@9fans.net] On Behalf Of 
 lu...@proxima.alt.za
 Sent: Sunday, March 07, 2010 11:58 PM
 To: 9fans@9fans.net
 Subject: Re: [9fans] (no subject)
 
  Agreed wholeheartedly.  Thing is, It's autoconf that needs careful
  redesign:
 
  I don't see any need for autoconf. As one wise person put it to me,
  things like configure and autoconf just mean you don't know how to
  write portable code.
 
 Again, agreed, but reality out there suggests many others are still 
 believers, no matter how misguided.  We were discussing making
 available Open Source ports...

What your discussing is adding massive complexity. I would prefer to not have 
the tools and programs, and retain simplicity, rather than add outlandish 
complexity.

 
  I still like to point people at plan 9 ports as an example of a
  complex system that gets by without this *conf* nonsense.
 
 It falls over just enough to be attacked.  Otherwise, p9p source would have 
 been ported back to Plan 9 in its entirety.  It's a shame,
 really, and with some work it could be fixed, but some of that work is design 
 work.
 
 ++L
 
 PS: I realise that I'm proposing two nearly orthogonal objectives, sorry that 
 I didn't clarify that sooner.

Re: [9fans] (no subject)

[Francisco J Ballesteros]

At lsub we are doing a bit of work on a db for linux.
To make a long story short, autoconf/automake/xmkmf/whatelse?
made the code so non portable that a particular version of suse is
now necessary to run the thing.

Isn't that the opposite of what auto* was trying to achieve?

I'd just say: say no.

On Mon, Mar 8, 2010 at 4:13 PM, Patrick Kelly kameo76...@gmail.com wrote:


 -Original Message-
 From: 9fans-boun...@9fans.net [mailto:9fans-boun...@9fans.net] On Behalf Of 
 lu...@proxima.alt.za
 Sent: Sunday, March 07, 2010 11:58 PM
 To: 9fans@9fans.net
 Subject: Re: [9fans] (no subject)

  Agreed wholeheartedly.  Thing is, It's autoconf that needs careful
  redesign:
 
  I don't see any need for autoconf. As one wise person put it to me,
  things like configure and autoconf just mean you don't know how to
  write portable code.
 
 Again, agreed, but reality out there suggests many others are still 
 believers, no matter how misguided.  We were discussing making
 available Open Source ports...

 What your discussing is adding massive complexity. I would prefer to not have 
 the tools and programs, and retain simplicity, rather than add outlandish 
 complexity.


  I still like to point people at plan 9 ports as an example of a
  complex system that gets by without this *conf* nonsense.

 It falls over just enough to be attacked.  Otherwise, p9p source would have 
 been ported back to Plan 9 in its entirety.  It's a shame,
 really, and with some work it could be fixed, but some of that work is 
 design work.

 ++L

 PS: I realise that I'm proposing two nearly orthogonal objectives, sorry 
 that I didn't clarify that sooner.

Re: [9fans] (no subject)

[Sascha Retzki]

 Thing is, It's autoconf that needs careful
 redesign: 

The question is, why should I care about that all? I have mk(1) and I really 
don't need more to build software on Plan9 (rc, awk/sed, etc. come in handy).

You seem to insist on alien software, why is porting software from lunix a 
prefered solution? Most of the solutions are a.) either to problems we don't 
even have or b.) so awkward in interfacing you just end up writing a native 
fork anyway.

Another interesting quesiton is: Should we have the ability to port alien 
software to Plan9, from an ethical point of view? I personally would feel 
better if APE was in extra/ (and has it's own mailinglist and contrib/).

 even though contrib/replica is not as comprehensive as a
 revision control even when backed by venti, it is unmatched for Plan 9
 purposes.

parse error. What are unmatched Plan9 purposes? And what has autoconf to do 
with contrib and replica?

Re: [9fans] (no subject)

[lucio]

 You seem to insist on alien software, why is porting software from
 lunix a prefered solution?  Most of the solutions are a.) either to
 problems we don't even have or b.) so awkward in interfacing you just
 end up writing a native fork anyway.

That's simple pragmatism.  Using Plan 9 without some of the Open
Source stuff is hard at least for some of us.  And there just aren't
enough Plan 9 developers to produce alternatives.  Considering the
number of useful (if poorly implemented) Open Source tools out there,
I'm sure I'm not being absurd.

++L

Re: [9fans] (no subject)

[Lyndon Nerenberg (VE6BBM/VE7TFX)]

 And there just aren't
 enough Plan 9 developers to produce alternatives.

Then there cannot possibly be enough to port the auto* abortion.

Re: [9fans] (no subject)

[erik quanstrom]

On Mon Mar  8 13:04:41 EST 2010, lu...@proxima.alt.za wrote:
  You seem to insist on alien software, why is porting software from
  lunix a prefered solution?  Most of the solutions are a.) either to
  problems we don't even have or b.) so awkward in interfacing you just
  end up writing a native fork anyway.
 
 That's simple pragmatism.  Using Plan 9 without some of the Open
 Source stuff is hard at least for some of us.  And there just aren't
 enough Plan 9 developers to produce alternatives.  Considering the
 number of useful (if poorly implemented) Open Source tools out there,
 I'm sure I'm not being absurd.

regardless, this thread is turning into a trollfest.
minds are made up.  no one is being swayed by
the arguments.  (and all the arguments have already
made the rounds.)  i think the only way to redeem it
is write some code.  failing that, let's at least give this
thread a proper burial.

- erik

Re: [9fans] (no subject)

[James Tomaschke]

lu...@proxima.alt.za wrote:
 That's simple pragmatism.  Using Plan 9 without some of the Open
 Source stuff is hard at least for some of us.  And there just aren't
 enough Plan 9 developers to produce alternatives.  Considering the
 number of useful (if poorly implemented) Open Source tools out there,
 I'm sure I'm not being absurd.

What tools do you have in mind?

This can be true for useful projects but it is not the case with
Autotools, because it is properly implemented as a useless tool.

If they wrote their own Makefile.in you can use that or Makefile.am to
create a mkfile fairly quickly.

There's no need to worry about path searching because of Plan 9
filespace unions.

Testing for missing headers/libraries is also pointless as compiling
will tell you this.

Autotools will not generate portable code, it can only inject code that
the author wrote a condition for.

effort  reward ergo GNU Not Useful

Re: [9fans] (no subject)

[lucio]

 Then there cannot possibly be enough to port the auto* abortion.

I hope so too, that would be insane.  But there ought to be a sane
alternative and it should not be anywhere as complex.  I'm sorry I put
the NetBSD package system in the same basket as the autoconf stuff,
their relationship is merely that the package system is geared towards
autoconf, but that is only a fraction of its functionality and I'm
sure can be replaced.  In fact, thinking about it, I've often wished
the configuration stuff would move out of the individual packages so
that duplication could be eliminated.  So maybe that's what _I'm_
looking for.

But enough said.  I have a much better idea of what the vocal Plan 9
community would (not) like.

++L

Re: [9fans] (no subject)

[lucio]

 What tools do you have in mind?
 
 This can be true for useful projects but it is not the case with
 Autotools, because it is properly implemented as a useless tool.

No, I do not have the autotools in mind, I share the prevalent dislike
for them.

Just to clarify, I use dot, fgb has ported both OpenSSH and OpenSSL
with good cause.

Your comments about generating a mkfile from Makefile.am are the most
constructive I have seen so far.

++L

Re: [9fans] (no subject)

[Lyndon Nerenberg (VE6BBM/VE7TFX)]

 But there ought to be a sane
 alternative and it should not be anywhere as complex.

There is: it's called POSIX.

Re: [9fans] (no subject)

[erik quanstrom]

On Tue Mar  9 00:27:59 EST 2010, lyn...@orthanc.ca wrote:
  But there ought to be a sane
  alternative and it should not be anywhere as complex.
 
 There is: it's called POSIX.

surely your joking, mr. nerenberg!

- erik

Re: [9fans] (no subject)

[Lyndon Nerenberg (VE6BBM/VE7TFX)]

 surely your joking, mr. nerenberg!

Nope.  Over the past 10 years I can only think of one or two projects
I did that required platform-specific optimizations outside of POSIX.

Re: [9fans] (no subject)

[Skip Tavakkolian]

 My gripe here is that it is hard to track what has been ported and
 what hasn't and repetition isn't helpful.

grep something /n/sources/lsr ?

Re: [9fans] (no subject)

[lucio]

 My gripe here is that it is hard to track what has been ported and
 what hasn't and repetition isn't helpful.
 
 grep something /n/sources/lsr ?

I wasn't aware of an lsr, but I don't think that's it, really.  One
needs more than a file name in many instances.  If I had infinite free
resources at my disposal, I'd use the NetBSD packages DESCR files in
some guise or other.

Of course, one would then be tempted (as I have been) to look more
seriously at porting the NetBSD package system to Plan 9.  That's not
out of the question, in fact it's probably not too difficult, but the
residual pain of autoconf for each individual package has already
frightened people with a stronger stomach than mine away.  That is why
I cannot suggest we catch up, but it may be nice to be ready when
eventually the autoconf edifice falls down and something mildly
intelligent takes its place!

Ironically, Plan 9 may be the platform on which a replacement for
autoconf could be designed and implemented.  But that's too close to a
pipedream to be given serious consideration.

++L

Re: [9fans] (no subject)

[Anthony Sorace]

We have fgb's contrib, and before that just the INDEX files in / 
contrib on sources. Neither is a perfect solution, but I don't think  
the problem here would be addressed by the Labs providing some new  
resource. Between the above and the wiki, there's plenty of  
opportunity for folks to make ports known.

Re: [9fans] (no subject)

[ron minnich]

On Sat, Mar 6, 2010 at 9:05 PM, Anthony Sorace a...@9srv.net wrote:
 We have fgb's contrib, and before that just the INDEX files in /contrib on
 sources.

we've got fgb's wonderful program and I think we're crazy if we don't
build on that.

Or we're CADT.

ron

Re: [9fans] (no subject)

[erik quanstrom]

 we've got fgb's wonderful program and I think we're crazy if we don't
 build on that.
 
 Or we're CADT.

haven't you heard?  we're not allowed to do anything
for ourselves anymore.  the mythical (and god like)
Library Writers do this for us.  our job is to glue things
together and port:

http://developers.slashdot.org/story/10/03/07/0043215/Whatever-Happened-To-Programming?art_pos=8art_pos=9art_pos=9

if we were to write our own, we would be guilty of
Wasting Resources.  this is a capital offense.

therefore we must port what the Library Writers have
given us.

... or maybe not.  i think contrib is pretty nice.  why
do we need blessed packages, away?  if you're installing
all unix-plan 9 ports, perhaps you would be happer
running unix in the first place.

- erik

Re: [9fans] (no subject)

[lucio]

 We have fgb's contrib, and before that just the INDEX files in / 
 contrib on sources. Neither is a perfect solution, but I don't think  
 the problem here would be addressed by the Labs providing some new  
 resource. Between the above and the wiki, there's plenty of  
 opportunity for folks to make ports known.

I'm merely suggesting a grouping function and I certainly am not in a
position to prescribe how it should be implemented.  As I mentioned, I
like the way NetBSD's package does it, but the price is very steep.
Fgb's contrib sounds very good, I have not had occasion to try it but
I presume it retains the scattered nature of the contrib directory.
My choice would be to add a directory wherein to store both modified
sources and binaries for Open Source projects once they have been
validated.  Of necessity, one would have the version clearly indicated
and where possible duplications as occur frequently with popular
packages such a zlib would be removed.  But there seems to me to be a
need to keep them together, although that may be just that I'm looking
at the problem from the single perspective of how it's done in NetBSD.

++L

Re: [9fans] (no subject)

[erik quanstrom]

 Fgb's contrib sounds very good, I have not had occasion to try it but
 I presume it retains the scattered nature of the contrib directory.
[...]
 I'm looking at the problem from the single perspective of how it's
 done in NetBSD.

really?  you haven't even tried it and your trying
to fit it into a whatever-netbsd-does shoebox?

- erik

Re: [9fans] (no subject)

[lucio]

 really?  you haven't even tried it and your trying
 to fit it into a whatever-netbsd-does shoebox?

Well, I do have some idea on how fgb's contrib is meant to work and,
yes, I do look at it from a biased perspective :-) Surely you don't
think that is implicitly flawed logic?

After all, how familiar are you with the NetBSD package system?  Fgb's
contrib is not too different, although it is certainly more relaxed,
in my opinion out of historical necessity.  Again in my opinion the
additional flexibility makes it harder to categorise packages and such
categorisation would be of greater benefit.  But it is just an opinion.

++L

Re: [9fans] (no subject)

[lucio]

 we've got fgb's wonderful program and I think we're crazy if we don't
 build on that.

A deserved compliment, certainly.  Now to figure how to provide the
grouping I believe is required in addition to the means for
replication.  And, if I'm not being stupid, some facility to make sure
that the final product has at least some chance of working according
to expectations.  Can't expect fgb to deal with that :-)

++L

Re: [9fans] (no subject)

[lucio]

 if you're installing
 all unix-plan 9 ports, perhaps you would be happer
 running unix in the first place.

That's flawed logic: I may need dot, while you need curses.  It's nice
if both have been blessed.

++L

Re: [9fans] (no subject)

[John Floren]

On Sun, Mar 7, 2010 at 1:09 PM,  lu...@proxima.alt.za wrote:
 we've got fgb's wonderful program and I think we're crazy if we don't
 build on that.

 A deserved compliment, certainly.  Now to figure how to provide the
 grouping I believe is required in addition to the means for
 replication.  And, if I'm not being stupid, some facility to make sure
 that the final product has at least some chance of working according
 to expectations.  Can't expect fgb to deal with that :-)

 ++L


Wouldn't grouping be a matter of placing a category file in the
package? I'm reading grouping as the kind of divisions you get in
Ports, i.e. net, editor, util, language, etc.

John
-- 
Object-oriented design is the roman numerals of computing -- Rob Pike

Re: [9fans] (no subject)

[Iruata Souza]

On Sun, Mar 7, 2010 at 2:42 PM,  lu...@proxima.alt.za wrote:
 We have fgb's contrib, and before that just the INDEX files in /
 contrib on sources. Neither is a perfect solution, but I don't think
 the problem here would be addressed by the Labs providing some new
 resource. Between the above and the wiki, there's plenty of
 opportunity for folks to make ports known.

 I'm merely suggesting a grouping function and I certainly am not in a
 position to prescribe how it should be implemented.  As I mentioned, I
 like the way NetBSD's package does it, but the price is very steep.
 Fgb's contrib sounds very good, I have not had occasion to try it but
 I presume it retains the scattered nature of the contrib directory.
 My choice would be to add a directory wherein to store both modified
 sources and binaries for Open Source projects once they have been
 validated.

who's gonna validate the beasts?

 Of necessity, one would have the version clearly indicated
 and where possible duplications as occur frequently with popular
 packages such a zlib would be removed.  But there seems to me to be a
 need to keep them together, although that may be just that I'm looking
 at the problem from the single perspective of how it's done in NetBSD.

please take 10 minutes to try fgb/contrib.
while at it, run contrib/gui. when a package is duplicated, it should
be clear from the package list on the left.

iru

Re: [9fans] (no subject)

[lucio]

 Wouldn't grouping be a matter of placing a category file in the
 package? I'm reading grouping as the kind of divisions you get in
 Ports, i.e. net, editor, util, language, etc.

Thing is, the port hierarchy (hereto I used NetBSD package system
for the same concept) provides both the hierarchical structure I
believe is needed to minimise duplication and a description file to
search for concepts rather than file names.  So, yes, I agree with a
portion of your suggestion, but not your suggested implementation.  In
practice, all I'm proposing is replacing directories owned by
individual contributors with a hierarchy that undergoes a useful
amount of validation.

I'm sure that fgb's contrib, possibly with manageable alterations,
will successfully deal with my proposal, with the reservation that we
probably want a selection mechanism that reduces the magnitude of
updates/replications to manageable proportions.  The NetBSD packages
hierarchy skeleton is gargantuan, I think we ought to provide tools to
trim down any new implementation of it, but I have not thought to any
extent how we'd do that.

++L

Re: [9fans] (no subject)

[cinap_lenrek]

 That's flawed logic: I may need dot, while you need curses.  It's nice
 if both have been blessed.

bless a curse! jehova!

--
cinap

Re: [9fans] (no subject)

[lucio]

 while at it, run contrib/gui. when a package is duplicated, it should
 be clear from the package list on the left.

Suppression of duplication is incidental.  What I believe is missing
from sources is a simple mechanism to see if something I'm already
somewhat familiar with has been ported successfully.  If not, then it
would be useful if there was a simple mechanism to add a successful
port to the global availability, with some moderation to discourage
malicious additions.  As for the moderation itself, the simplest form
I can think of is simply that a score be kept of successful use, reset
to zero when a new version is released.  Other options may prove more
practical.

I suspect that all the resistance I encounter is more knee-jerk
reaction to a request for a little bit of additional discipline than
real objection to the concept.  And the usual 9fans culture of wanting
code rather than discussion.  Unfortunately, this is one piece of code
that ought to be planned rather than hacked together: it's hard to
reverse the implementation if it turns out badly.

++L

Re: [9fans] (no subject)

[ron minnich]

code-code is better than talk-talk :-) (absolutely no offense
intended, I just enjoyed the phrase!)

i.e. I think a proof of concept will get your further than discussion.
It seems to me you could
even make a copy of the sources tree, set up your idea, and put it out
there for people to try.

I only strongly suggest that you put the contrib gui at the heart of
what the user sees.

thanks

ron

Re: [9fans] (no subject)

[erik quanstrom]

 Thing is, the port hierarchy (hereto I used NetBSD package system
 for the same concept) provides both the hierarchical structure I
 believe is needed to minimise duplication and a description file to
 search for concepts rather than file names.  So, yes, I agree with a
 portion of your suggestion, but not your suggested implementation.  In
 practice, all I'm proposing is replacing directories owned by
 individual contributors with a hierarchy that undergoes a useful
 amount of validation.

this is exactly the reason you need to try contrib.

if you want to make an überpackage, just make your
überpackage depend on everything else.  it doesn't
need to have any files of its own.  i've verified this.
it would be a trivial extension (like 2 lines) to have
contrib/install recursively install dependencies.

- erik

Re: [9fans] (no subject)

[lucio]

 I only strongly suggest that you put the contrib gui at the heart of
 what the user sees.

Agreed wholeheartedly.  Thing is, It's autoconf that needs careful
redesign: even though contrib/replica is not as comprehensive as a
revision control even when backed by venti, it is unmatched for Plan 9
purposes.  But that leaves one still at the mercy of autoconf and it
seems to me that the trigger for change ought to come  from Plan 9.
And in case I haven't yet made it clear, I don't have a good enough
picture in my head to suggest a replacement.

In fact, Steve Simon and fgb both have done great work to help there,
but I feel the real answer is still at large.

And if anyone should find this bait irresistible, keep in mind that
the final product needs to be portable across at least a few OS
platforms as well as hardware architectures and that it should
probably be targetting the Plan 9 toolchain rather than GCC (G++ is a
problem, of course, but Go may help there as at least with the NetBSD
packages, the number of C++ offerings is limited.).

++L

Re: [9fans] (no subject)

[lucio]

 if you want to make an überpackage, just make your
 überpackage depend on everything else.

Is this what I wanted to know all along?

++L

Re: [9fans] (no subject)

[erik quanstrom]

On Fri Jul 24 13:20:17 EDT 2009, quans...@quanstro.net wrote:
 - 9fans.

sorry.  i don't know what marshal did to me.

- erik

Re: [9fans] (no subject)

[Steve Simon]

 Give or take that all the executables fail, I have enough MINGW
 binutils from the NetBSD package to convince me that MINGW can be
 built and no doubt some debugging will soon take care of the stumbling
 blocks.
 
 It is true that debugging is going to be hard without symbol
 information (one more good reason to go the ELF route for my GCC
 model, in my opinion) and that I need a real implementation of the
 SEEK syscall before I start on the debugging, but these are
 surmountable obstacles.  I guess you need to keep holding thumbs.
 

Sorry, this went completely over my head. It sounds like you
have achieved somthing impressive but I'am afraid I don't understand.

-Steve

Re: [9fans] (no subject)

[lucio]

  1) build mingw for plan9
 
 Give or take that all the executables fail, I have enough MINGW
 binutils from the NetBSD package to convince me that MINGW can be
 built and no doubt some debugging will soon take care of the stumbling
 blocks.

My apologies, this was meant to be private mail to Steve Simon.

++L

Re: [9fans] (no subject)

[lucio]

   1) build mingw for plan9

Give or take that all the executables fail, I have enough MINGW
binutils from the NetBSD package to convince me that MINGW can be
built and no doubt some debugging will soon take care of the stumbling
blocks.

It is true that debugging is going to be hard without symbol
information (one more good reason to go the ELF route for my GCC
model, in my opinion) and that I need a real implementation of the
SEEK syscall before I start on the debugging, but these are
surmountable obstacles.  I guess you need to keep holding thumbs.

++L

PS: Oh, and Linuxemu may have to become BSDemu in due course, too.
But I have too much to learn before I can treat that as an option.

Re: [9fans] (no subject)

[Charles Forsyth]

lcc is nothing like as hard to compile as gcc (which has got worse, much worse, 
over the years).
funnily enough, my gcc bootstrap compilation is still going (on a multi-core 
linux machine).
it started over an hour ago.  bizarre.

Re: [9fans] (no subject)

[Devon H. O'Dell]

2009/4/23 Charles Forsyth fors...@terzarima.net:
 lcc is nothing like as hard to compile as gcc (which has got worse, much 
 worse, over the years).
 funnily enough, my gcc bootstrap compilation is still going (on a multi-core 
 linux machine).
 it started over an hour ago.  bizarre.

(my apologies for diverging the topic from both Plan 9 and the
original question)

What languages are you compiling? on my 3-core amd processor, it takes
10 minutes to compile c and c++.

Steve: I know there are some really good resources about PE online, as
well as several on MSDN that might contain more information about what
Windows will actually do with a PE. I don't believe they are required
to be relocatable, as even Windows 7 will still run Win9x binaries,
and I'm fairly sure that there wasn't the ability to relocate
executables back then.

--dho

Re: [9fans] (no subject)

[lucio]

 lcc is nothing like as hard to compile as gcc (which has got worse, much 
 worse, over the years).
 funnily enough, my gcc bootstrap compilation is still going (on a multi-core 
 linux machine).
 it started over an hour ago.  bizarre.

...  and when I eventually completed it under NetBSD, a few months
back, the GAS pass failed with a segmentation violation.  I wonder if
it's been fixed since...

++L

Re: [9fans] (no subject)

[erik quanstrom]

 back, the GAS pass failed with a segmentation violation.

unfortunate!  that's gotta hurt.  ☺

- erik

Re: [9fans] (no subject)

[David Leimbach]

On Thu, Apr 23, 2009 at 10:17 AM, erik quanstrom quans...@quanstro.netwrote:

  back, the GAS pass failed with a segmentation violation.

 unfortunate!  that's gotta hurt.  ☺

 - erik

 Seems like you'd have to change your pants after a GAS pass segmentation
violation.

Re: [9fans] (no subject)

[lucio]

 anyone know of any other (simpler) options?

Inferno utils?  The binaries for NT?

++L

Re: [9fans] (no subject)

[ron minnich]

On Mon, Feb 23, 2009 at 4:29 PM,  mattmob...@proweb.co.uk wrote:
 oops I forgot carriage returns get converted in email
 imagine # is a ^m


 pu% /n/sources/contrib/maht/rc/til
 abc¯def#123#
 emit
 abc def
 123
 : emit4 emit emit emit emit
 # 1 2 3 emit4
 321
 1 # swp 3 2 swp dup dup drop emit4 emit
 3321

 does this make sense / of interest to anyone :)


sure but what's the point? Couldn't you grab one of the forth interpreters?

ron

Re: [9fans] (no subject)

[Jeff Sickel]

On Feb 23, 2009, at 6:48 PM, ron minnich rminn...@gmail.com wrote:






sure but what's the point? Couldn't you grab one of the forth  
interpreters?


Forth on Plan 9?  That would be great.  Then I'd have a bit more  
leverage in getting a new PIC based board to talk with Plan 9.   
(brucee's recent 9p example's notwithstanding)


-jas

Re: [9fans] (no subject)

[sixforty]

Jeff Sickel wrote:


On Feb 23, 2009, at 6:48 PM, ron minnich rminn...@gmail.com wrote:






sure but what's the point? Couldn't you grab one of the forth 
interpreters?


Forth on Plan 9? That would be great. Then I'd have a bit more 
leverage in getting a new PIC based board to talk with Plan 9. 
(brucee's recent 9p example's notwithstanding)


-jas




Someone in freenode #forth said they'd just ported 4tH to Plan 9. I 
don't log IRC, wish I'd payed more attention. Maybe they've shared it by 
now. I don't doubt them, as 4tH's source comes with instructions on how 
to build with no libs and only 2 syscalls (1 is 'printf' replacement).


sixforty

Re: [9fans] (no subject)

[Anthony Sorace]

fgb has ported 4th; it's in his contrib dir, both as a tar file and a
contrib package. i thought i remembered seeing another, but it's not
on the contrib index page.

Re: [9fans] (no subject) [troff / man bug]

[erik quanstrom]

 Suject: scuzz(8) man bug
 
 man -P, man or the magicman html versions
 all have a similar bug.  the .IR macro appends a
 a spurious .}f.
 
  SEE ALSO
   sd(3)
   Small Computer System Interface - 2 (X3T9.2/86-109), .}f
 
 shortening the italic portion by 4 characters makes the problem
 go away.

does anybody know what's wrong here?

- erik

Re: [9fans] (no subject)

[Roman Shaposhnik]

On Dec 6, 2008, at 11:28 AM, Dave Eckhardt wrote:

More globally, if the high adoption rate of NFS is an argument
in favor of its architecture,


It is most definitely not. At least in my opinion. However, adoption
is the only thing that I know of that can potentially justify excessive
*engineering* complexity. Personally I'd call any system that is overly
complex *and* has a low adoption rate (for whatever reason) after
at least 5 years of having been exposed to the market place, a
theoretical artifact of computer science. The usefulness of which
is commonly measured by the number of good CS papers dedicated
to studying it.

I do understand that for you AFS also has a huge redeeming factor
of being useful in solving a particular problem. It is hard to say  
whether
it is the best tool for the job, or the only one (it would be  
interesting if
you answered to Erik's question on this list). But perhaps the  
difference

of opinion here stems from the fact that to *you* it does feel like
an enterprise grade to me (as an outside observer) the enterprise
grade must be vetted by the market place. Hence my interest in
the adoption rate.

and the low adoption rate of AFS is an argument against its  
architecture,

why are you reading a Plan 9 mailing list...?


This one is easy: Plan 9 (and 9P in particular) doesn't have to have
the redeeming quality of high adoption rate in order to justify
an excessive engineering complexity. It is not complex at all.
It is small and elegant. Whether that compactness and elegance
sometimes prevents it from being considered enterprise grade
is an open question (at least for me it is). The experience of
Coraid suggests that it might actually be a nice tool even for those
kinds of problems.


To some extent, the popularity of NFS (is there any NAS box that
talks AFS?) and Linux is one big testament to the power of good
enough or worse is better.

Designing enterprise grade things is very hard work.
Implementing them is even harder. The good news is that it
pays well. The bad news is that you have to be really brave to
withstand the fear of being obsolete by changing requirements.


I don't get this.  I don't follow the NFS protocol development
carefully,


Just to clarify: this thread is really not about me defending NFS.
I can't call it elegant. But I can certainly call it good enough.
So at least it succeeds as a lowest common denominator for
data sharing. Well, so far at least.


That is, I think the requirements are *not* changing, but rather
that NFS is slowly realizing that those things *are* requirements.


Agreed. And I believe both FSs do miss the point. NFS4 especially
so. The question is really not about the most efficient implementation
of POSIX filesystem semantics over the network, but rather whether
POSIX expectations are reasonable in the first place. Plan 9 was
bold enough to simply discount some of those expectations and
the resulting system proved to be much better than what a typical
UNIX provides these days.

Now, what would be really interesting is to see is how the kinds
of requirements that pNFS has can be satisfied with Plan9/9P
approach.

Thanks,
Roman.

Re: [9fans] (no subject)

[erik quanstrom]

 This one is easy: Plan 9 (and 9P in particular) doesn't have to have
 the redeeming quality of high adoption rate in order to justify
 an excessive engineering complexity. It is not complex at all.
 It is small and elegant. Whether that compactness and elegance
 sometimes prevents it from being considered enterprise grade
 is an open question (at least for me it is). The experience of
 Coraid suggests that it might actually be a nice tool even for those
 kinds of problems.

i believe the term of art is enterpriseiness.

- erik

Re: [9fans] (no subject)

[Kenji Arisawa]

Hello,

If such an attack continues for some minutes and the server does not  
reject the connections
the server will create thousands of smtpd processes and might be hung  
up.


Kenji Arisawa

On 2008/11/22, at 3:28, erik quanstrom wrote:


Subjet: email attacks

since our friends in sweeden helped out our spammer friends
get back on line, i've seen a lot more attacks.  today i've been
getting ~10 connections/sec.  fortunately its from a small
number of machines, so this trick helps alot:

/n/dump/2008/1121/sys/src/cmd/upas/smtp/smtpd.c:348,353 - smtpd.c: 
348,355

if(!qflag)
syslog(0, smtpd, Hung up on %s; 
claimed to be %s, nci-rsys, 
him);
+   if(Dflag)
+   sleep(delaysecs()*1000);
reply(554 5.7.0 Liar!\r\n);
exits(client pretended to be us);
return;

oddly, i've found that adding a few of the hosts as -k flags stops  
the attack

entirely.

- erik

Re: [9fans] (no subject)

[erik quanstrom]

 Hello,
 
 If such an attack continues for some minutes and the server does not  
 reject the connections
 the server will create thousands of smtpd processes and might be hung  
 up.
 
 Kenji Arisawa
 

but that's not what happens.  waiting for 15 seconds decreases the
load to near zero.  it's not a ddos attack.  in fact, most of the trouble
came from a single zombie.

if it were, i would need to see more than 10 connections/second
before i would have a significant backlog.  i can easily afford 150
smtpds sleeping.

- erik