headers
erik quanstrom | 2 Feb 06:03
Favicon

9atom unicode 6.1 support

steaming 💩 (u+01f4a9) and all.  if you're using plan 9 to
view this (or even most browsers), you probablly see a couple
of screen droppings where the steaming pile should be.
(no laughing, now.)

well, the unicode committee might not have the best taste, but
for better or worse, it's the character set we've got.

yeah! 😑 (u+01f611)

upgrade from 6.0 was trivial since all the tables for is*rune() and
to*rune() are generated, as is /lib/unicode.

- erik

(btw, the font symbolta does display both the wierd codepoints i
used.)
Permalink | Reply | 0 comments |
headers
Akshat Kumar | 2 Feb 12:56

[kenfs] the mercurial repo problem

This is a problem perhaps two of us
have on Plan 9 (hi Erik): mercurial
repositories contain files with long
names and/or spaces.

I realised that `lnfs' is a neat solution
to this problem (though you have to
remember to run it each time you're
in the repo) for the time-being. In
particular, it doesn't hog up ram (the
way ramfs does... :), and it doesn't
rely on the repo .hg dir already being
there (the way hgfs does), which is
what usually contains the long names.
And we can use `unlnfs' to export.

Just for future reference -- I noticed that
this didn't come up when we last discussed
this issue.

As always -

BUGS
          This exists only to shame us into getting a real long name
          file server working.
(Yeah, yeah - fossilheads can SUCK EGGS :-)

Best,
ak
(Continue reading)

Permalink | Reply | 1 comment |
headers
Akshat Kumar | 2 Feb 13:05

Re: [kenfs] the mercurial repo problem

Ah, sorry to double-post, but in order
to get this working, one must:

mkdir repo
hg init repo
cd repo; hg pull -u https://...
echo '[paths]
default = https://...' > .hg/hgrc

Because it is forbidden to directly
clone on a non-empty directory
(an lnfs mounted dir contains a
.longnames index file).

ak

On Thu, Feb 2, 2012 at 3:56 AM, Akshat Kumar
<akumar <at> mail.nanosouffle.net> wrote:
> This is a problem perhaps two of us
> have on Plan 9 (hi Erik): mercurial
> repositories contain files with long
> names and/or spaces.
>
> I realised that `lnfs' is a neat solution
> to this problem (though you have to
> remember to run it each time you're
> in the repo) for the time-being. In
> particular, it doesn't hog up ram (the
> way ramfs does... :), and it doesn't
> rely on the repo .hg dir already being
(Continue reading)

Permalink | Reply | 0 comments |
headers
erik quanstrom | 2 Feb 13:49

Re: [kenfs] the mercurial repo problem

On Thu Feb  2 06:57:40 EST 2012, akumar <at> mail.nanosouffle.net wrote:
> This is a problem perhaps two of us
> have on Plan 9 (hi Erik): mercurial
> repositories contain files with long
> names and/or spaces.

coraid run's ken's file server.  so a fair percentage
of plan 9 users run on that rather than fossil.

- erik
Permalink | Reply | 0 comments |
headers
tlaronde | 2 Feb 14:34

[RFC] How to install without

Since it seems that Iruatã Souza, who had accepted to give a second look
at what I wrote, is as short on time as I am, here is for review an
explanation about "how to do [an install] without". [Still TODO: fix
disk/fdisk.]

       Installing Plan9 without a CD reader or a PXE boot.

                            Abstract

The Plan9 distribution is available for installation by the mean of a
bootable ISO image supposed to be burnt on a CDROM. But this image has
indeed all the pieces needed to realize an installation, without a CD
reader, or without a PXE boot.

What follows is an illustration of "how to do without".

0. What was first? The egg or the goose? Well: the egg, that is some
BIOS.

In the following, the names will match the pc world; but, more or less,
there is a mapping between pc idiosynchrasies and something else
idiosynchrasies.

When a pc starts, it first initializes its hardware before giving the
hand to an user provided program---generally an operating system. But to
be able to hand over to something else, it has to know the rendez-vous
point. This BIOS entry point is a 512 bytes sector, that is a program,
and that is (for disks and like) the very first sector of the device.

On disks, it is called: MBR. It is a program with a signature (for basic
(Continue reading)

Permalink | Reply | 0 comments |
headers
erik quanstrom | 3 Feb 03:33
Favicon

encode(2)

as it turns out, encode(2) inaccurately describes the code.
dec64, enc64, dec16 and enc16 truncate rather than returning
errors.

does anybody have any reasons why truncated encodings should
be allowed?  i think this only allows for interesting attacks based
on truncated encodings, rather than being useful.  but i could
be wrong.

i'm currently testing these changes (there are a few calls to enc/dec64
that need correcting).

- erik
Permalink | Reply | 0 comments |
headers
smiley | 4 Feb 02:27
Favicon

Smiley's plan9port mod 1 ver. 1.1 released (BUGFIX)

smiley <at> icebubble.org writes:

> Hello, 9fans!
>
> :)y's plan9port mod 1 version 1.0 is now out.
>
> <magnet:?dn=sp9pm1v1p0.patch&xl=153045&xt=urn:sha1:DN75FAYWWBS54C3TL2DE7DTFMICT2GFX&xt=urn:md5:8B486B050E4FC7E054156CBB6194348C&xt=urn:crc32:909347387&as=http%3A%2F%2Fplan9.icebubble.org%2Fplan9port%2Fpatches%2Fsp9pm1v1p0.patch>
>
> <http://plan9.icebubble.org/plan9port/patches/sp9pm1v1p0.patch>
>

During beta, some bugs were uncovered in ver. 1.0 that make it, well,
unsuitable for use on Real Data(TM).  They've been remedied in ver 1.1:

<magnet:?dn=sp9pm1v1p1.patch&xl=153760&xt=urn:sha1:OLNETULVWDFJYMNRNTFDM6OUDFIBPXJK&xt=urn:md5:8A56596FB8556C305BE5658AE9458D8C&xt=urn:crc32:706490478&as=http%3A%2F%2Fplan9.icebubble.org%2Fplan9port%2Fpatches%2Fsp9pm1v1p1.patch>

<http://plan9.icebubble.org/plan9port/patches/sp9pm1v1p1.patch>

--

-- 
+---------------------------------------------------------------+
|Smiley       <smiley <at> icebubble.org>    PGP key ID:    BC549F8B |
|Fingerprint: 9329 DB4A 30F5 6EDA D2BA  3489 DAB7 555A BC54 9F8B|
+---------------------------------------------------------------+
Permalink | Reply | 0 comments |
headers
bsder | 5 Feb 19:08

using memory stick

I am trying to figure out whether a memory stick can be used 
in a usb port on an IBM T23 laptop to transfer files to and
from the memory stick, and if so, how to mount the stick
and copy files to and from it.

The Plan 9 installation I have is from November 2009.
/dev/usb shows a ctl file and three directories,
ep1.0, ep2.0, and ep3.0.  
The T23 has only two usb interfaces on the back.

Robert

--

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Permalink | Reply | 1 comment |
headers
Alexander Kapshuk | 5 Feb 19:36
Picon

Re: using memory stick

On 02/05/2012 08:08 PM, bsder <at> urdirect.net wrote:
> I am trying to figure out whether a memory stick can be used
> in a usb port on an IBM T23 laptop to transfer files to and
> from the memory stick, and if so, how to mount the stick
> and copy files to and from it.
>
> The Plan 9 installation I have is from November 2009.
> /dev/usb shows a ctl file and three directories,
> ep1.0, ep2.0, and ep3.0.
> The T23 has only two usb interfaces on the back.
>
> Robert
>
>
>    

you may want to run
usbfat:
the output will be the path to your memory stick, e.g. /n/dev_name
Permalink | Reply | 0 comments |
headers
Rudolf Sykora | 6 Feb 11:17
Picon

refer for plan9port

Hello,

does anybody know about a 'refer' version for plan9port?

(I know there is a version for plan9 in the contrib, but I generally run p9p...)
(Also: I can't directly use the GNU refer, since it stumbles over
unicode characters in my texts.)

Until now I have been using the Heirloom version. But it seems to have
unexpectedly stopped working for some reason.

Thank you!
Ruda
Permalink | Reply | 2 comments |

Gmane