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

[9fans] (no subject)

[Steve Simon]

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

[9fans] (no subject)

[Steve Simon]

Hi,

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

-Steve

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
>

[9fans] (no subject)

[Steve Simon]

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

[9fans] (no subject)

[Steve Simon]

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.

Thanks people,

-Steve

[9fans] (no subject)

[kokamoto]

Subject change to ether Yuk driver for 88E8036

I noticed the 9fans reopen now.
I tried this mail at June 16, 2016, but failed...
I'd like to announce this to all, particulary eric.

I posted a mail to 9fans, but I don't have received that mail,
so retries it to this mailing-list.

I asked the above line for about two weeks ago to 9fans.
Now I got a solution by myself.

The problem was 88E8036(Yukfe) chip has a small amount
of RAM buffer, which eric didn't pay attention.

I tried to may diff file, however, I wrote too many comment lines
on the file, which leads to a fuge sized diff file.
Therefore, I'll write only the differences between the last cdrom
of 9front and myself.
belows are the data:
(please pay attention to ===> lines)
-from here-
1)static Vtab vtab[] = {
0x11ab, 0x4351, 1514,   "88e8036",



2)in buffinit() function:

if(q == Qr || q == Qr + Qportsz){
===>t = end - start;
rrwrite32(c, q + Rpon, t - 8192/8); /* set Rx upper 
threshold, pause on */
===>rrwrite32(c, q + Rpoff, t/4);   /* set Rx lower 
threshold pause off */



3)in phyinit() function:

if((c->feat & Fnewphy) == 0){
u = phyread(c, Phyextctl);
u &= ~0xf70;/* clear downshift counters */
u |= 0x7<<4;/* mac tx clock = 25mhz */
if(c->type == Yukec)
u |= 2*Dnmstr | Dnslv;
else
===>u |= (0<<8 & 3<<8)|(1<<8 & 3<<8);
..
}else{
===>if(c->feat != 0)/* exclude Yukfe */
u |= Ppmdixa >> 1;  /* why the shift? */
if(c->type == Yukfep && c->rev == 0){
}
.
+++ if (c->type == Yukfe){  /* led control */
+++ u = u1 = phyread(c, Phyphy);
+++ u &= ~(0xf <<4);
+++ u |= 0x0b<<4 & 0xf<<4;
+++ phywrite(c, 0x16, u);
+++ u1 |= (1<<8 & 7<<8) <<1;
+++ phywrite(c, 0x18, u1);
+++ }
phywrite(c, Phyintm, Anok | Anerr | Lsc);   /* phy 
interrupt mask */
dprint("phyid %.4ux step %.4ux\n", phyread(c, 2), phyread(c, 3));
}
--- to here -

Kenji

[9fans] (no subject)

[trebol]

Hello everyone.

I'm curious about the behavior of rc concatenating null strings (brakes
execution on error...).  It's a feature, rationally thought-out, or a bug?

If anyone can tell me the story behind, I'll be grateful.

trebol.

[9fans] (no subject)

[kokamoto]

Subkject: A68-N5000 cabini motherboard

I got it functional partially.

This is for energy-saving motherboard with APU (15W TDP)
on it without coolong fan.

I just moved the HDD used on a C2D machine
to this box, where it booted successfully with only
one problem, ether chip.

The ether chip on this board is:
1.0.0: net 02.00.00 10ec/8168 ,
and the error message from the kernel is:
rtl8169: unknown mac 8168 4c00.

No, the ether8169.c file does not have that line.
However ether82598.c file does.  
Then, I checked out the ether8169 line from /sys/src/9/pc/pcf, 
and tried to recompile the kernel, and got a huge sized one:
size 9pcf
  1309468t + 6491264d + 375712b = 8176444.

I think the second size may be too big!

I recompiled the 386 kernel many times and had
no problem like this.
The compilation after the last kernel recompilation are
go(1.3?) and amd64 kernel.

Anyone has an idea what'i going on?

Kenji

[9fans] (no subject)

[kokamoto]

Subjecxt: how to change login user on 9pi?

I tried to change the /n/9fat/cmdline.txt file to

readparts=1 nobootprompt=local user=kokamoto.

Now I can login as kokamoto.  Then I'd like to make ask the
login name at boottime.  How I can change it?

Year!  Now I'm a network user of 9pi.
I got Buffalo's ether-wireless bridge at about 5000円,
which is higher than pi board itself!

Now I can write Japanese email like:
日本語の練習をしましょう

Kenji

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

[9fans] (no subject)

[Steve Simon]

Subject p9p and writable strings

Anyone built p9p recently, how do you cope with modern gcc
which now places all string constants in a readonly section
in the executable, and there is nolonger an option to prevent it.

the two main offenders I have found so far are mktemp() and cleanname().
In several places these are passed string constants.

the obvious alternatives would be to have these two functions return
malloc'ed memory (and remeber to free it later), or to replace
the string constant with an initialised variable.

What has anyone else done? have I missed somthing?

-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

[9fans] (no subject)

[Steve Simon]

Hi,

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?

Thanks,

-Steve

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

[9fans] (no subject)

[Jacob Todd]

On Sun, 16 Mar 2014 10:51:37 -0400, erik quanstrom wrote:
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?

http://h1ro.dyndns.org/drawterm/
http://9fans.net/archive/2012/06/205

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

[9fans] (no subject)

[Steve Simon]

Subject Drawterm windows audio?

Anyone added an audio driver to windows or osx drawterms?

-Steve

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
 

[9fans] (no subject)

[Steve Simon]

Subject i2c and gpio

I need an i2c driver for plan9, anyone implemented
one in the past and have opinions on what they should
look like?

I have to revisit some old code but I wrote a driver for
another OS which implemeted 255 virtual files in /dev/i2c/* 
one for each possible address (well there are some reserved
ones but you get the idea).

I need GPIO pins too. again in OSs passim I just had a file
per pin, no clever magical mapping of bits into integers.

I then allowed a write to reconfigure the port as an output,
or a read to set it as an input; the I/O config being persistent.

This worked well for us but perhaps is naive?

Thoughts anyone?

-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

[9fans] (no subject)

[lucio]

Subject Sheevaplug and NVRAM

Every time I start the Sheevaplug, I have to enter the authentication
details that ought to be written to VNRAM.  This seems unnecessary,
but my attempts to assign a single block of flash to NVRAM have so far
been unsuccessful.

Could somebody mail me an example of a successful allocation of flash
memory for Plan 9 use on a Sheevaplug so I can figure out what I am
doing wrong?

++L

[9fans] (no subject)

[yaroslav]

subect: update:V: in system mkfiles

Many system mkfiles have targets like this:

update:V:
update $UPDATEFLAGS $UPDATE

These're no program named 'update' however — besides pc/update which
doesn't seem to apply here.

Could somebody please advise what these are meant for?  Is it still
relevant?

Thanks.

- yk

Re: [9fans] (no subject)

[Charles Forsyth]

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

[9fans] (no subject)

[陈俊秀]

hi,

I try to mount the local foler in the vm, use the 9p protocol, it mount
success, enter the foler, i can read and write the files already in the
folder ,but can't create new folders and files in it. why and how can i
solve it?

i created the vm use qemu -fsdev
local,id=test_dev,path=/root/shared,security_model=none -device
virtio-9p-pci,fsdev=test_dev,mount_tag=test_mount
the guest vm is redhat with 2.6.32 kernel,  in the guest os terminal: mount
-t 9p -o trans=virtio test_mount /tmp/shared/ -
oversion=9p2000.L,posixacl,cache=loose
and it's no use when i update the kernel to higher .


thanks,
xiu

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

[9fans] (no subject)

[erik quanstrom]

  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

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

[9fans] (no subject)

[Steve Simon]

Subject factotum auth for commodity web browsers?

Hi,

I have a distant memory of somone talking about adding
factotum support to mozilla or firefox, but I can nolonger
fine a reference - did I imagine it?

Is there such a thing for p9p perhaps?

-Steve

[9fans] (no subject)

[Steve Simon]

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

-Steve

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

[9fans] (no subject)

[Stanley Lieber]

 From: Tharaneedharan Vilwanathan vdharani@gma...
 Subject: suggestion for a video card
 Date: Tue, 18 Aug 2009 11:53:58 -0700
 
 hi,
 
 i am looking for a video card for plan9.
 
 here are my requirements:
 
 - should do 1920x1080 at 60Hz so i can connect to my LCD TV via HDMI
 - HDMI connector preferable but if the card does 1920x1080, i can use
 DVI to HDMI adapter
 - would be nice if it can also do 1920x1200
 
 has anyone played with such a card? is it orderable? any suggestions?
 
 any help appreciated.
 
 regards
 dharani

This post didn't garner a response. A couple of years later,
I have the same question. Is anyone running Plan 9 native
at 1920x1080 with an LCD monitor? What video card are you
using? What tweaks were necessary to get it to work?

The Nvidia card I use with OpenBSD crashes Plan 9 when I
attempt xga above 640x480x8. With cinap's realemu I'm able
to run at 800x600x32, but the card's VESA bios doesn't report
any available modes above 800x600. Some other cards I had
sitting around yielded higher resolutions under realemu (VMware
even reports 1920x1080 as a valid mode under VESA), but I
haven't yet hit upon the right combination to drive my LCD
monitor at 1920x1080.

-sl

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

[9fans] (no subject)

[erik quanstrom]

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

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

[9fans] (no subject)

[erik quanstrom]

has anyone using cifs/aquarela had the chance to try
nfactotum with either with the mschap protocol?

(you will need the latest version of nfactotum to have
any hope of success.)

- erik

[9fans] (no subject)

[erik quanstrom]

- 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