> As I'm Unix user since about 18years...should be ok to learn again
> plan9 OS
It's what you may not be able to unlearn that you need to be afraid of
:-)
I wish you a happy journey.
++L
Unfortunately it coincided with a period during which people with no
apparent previous link to Inferno or Plan 9
were offering to translate to different languages, with a slightly
strange follow-up, and we thought it was another one of those.
I don't think any of the papers let alone the manual pa
> in these releases 9front there are customizations to the system or
> just added firmware and patches?
Some things added, some things removed (e.g. fossil file system),
some things replaced with new versions which aren't able to
interoperate with Plan 9 programs (e.g. usb subsystem).
how can it not interoperate with plan9 programs? the usb subsystem
in 9front just organizes the instantiation of userspace drivers
differently. the kernel hci drivers and interfaces are the same
(biggest difference is that we added buffer delay control for iso
endpoints for usb audio).
instead of
> how can it not interoperate with plan9 programs? the usb subsystem
> in 9front just organizes the instantiation of userspace drivers
> differently. ...
That's what I was referring to. Plan 9 usb device drivers are
user space programs, which use the usb subsystem (including usbd)
as part of the
ah, ok. yes, the drivers would be different. but its not hard
to port. its mostly removing all the refcounting and and plan9 usb
framework activation and just wrap it in a normal plan9 filesystem.
many drivers needed a rewrite anyway (like usb audio) because they
where a total mess.
--
cinap
> many drivers needed a rewrite anyway (like usb audio) because they
> where a total mess.
There are plenty of things in Plan 9 still in need of improvement
or even rewriting. That's why it makes me sad to see our small
community being made even smaller when some of the most skilled
programmers d
> Your fix solves the problem on both the IGEPv2 and Trim-Slice.
Thanks for testing it, I've offered a patch now (armv7-bkpt).
> There are plenty of things in Plan 9 still in need of improvement
> or even rewriting. That's why it makes me sad to see our small
> community being made even smaller when some of the most skilled
> programmers direct their efforts into splintering off their own
> little playgrounds instead of h
Since there are a lot of code flow between 9front and 9atom (even sources,
however that's mostly one directional) I would argue that having the
forks even make things better. Erik and Cinap can experiment more
freely and all the changes are available for everyone. Even breaking
driver compatibility
> There are plenty of things in Plan 9 still in need of improvement
> or even rewriting. That's why it makes me sad to see our small
> community being made even smaller when some of the most skilled
> programmers direct their efforts into splintering off their own
> little playgrounds instead of h
APE's getsockname() returns port with bytes swapped (on 386).
Fix:
/n/dump/2013/0108/sys/src/ape/lib/bsd/_sock_ingetaddr.c:35,41 -
/sys/src/ape/lib/bsd/_sock_ingetaddr.c:35,41
if(p){
*p++ = 0;
ip->sin_family = AF_INET;
- ip->sin_port = atoi(p);
+ ip->sin_port = htons(atoi(p));
ip->sin_addr
i would like a website where i could compare
the labs, distro with 9front and 9atom. something like russ's
plan9 history site. it wouldn't need to show stuff thats the same
just the differences... just at the file level would do for a start.
sadly i don't have the skills but maybe someone
else w
what would you suggest to improve that situation?
for me, 9front is a great motivator and learning exercise and
keeps me from cutting myself because of all that plan9 drama
and stagnation. many bugs where fixed in plan9 as a result
of that work.
--
cinap
i mean, dont worry about us. we'r not intending to be a burden
for the plan9 community. we dont ask for help on anything. we made
a process. we merge in changes from the various forks out there.
we test stuff on our own. we dont get into long pointless debates
about how stuff should be done. we jus
I think you guys should keep doing what you do. Different people have
different reasons and motivations for what they do. These do not always line
up well to form a totally free-from-fragmentation community. That we all still
share 9fans is a good way to keep up with the different efforts too
Hello,
is there a simple way to prevent the mailing chain of p9p from
'checking' sent attachments?
I am getting the following info appended to my mails and attachments
renamed by appending '.suspect':
"The following attachment had content that we can't prove to be harmless..."
I'd rather avoid
On Tue Jan 8 10:12:46 EST 2013, rudolf.syk...@gmail.com wrote:
> Hello,
>
> is there a simple way to prevent the mailing chain of p9p from
> 'checking' sent attachments?
> I am getting the following info appended to my mails and attachments
> renamed by appending '.suspect':
vf is no longer use
> i would like a website where i could compare
> the labs, distro with 9front and 9atom. something like russ's
> plan9 history site. it wouldn't need to show stuff thats the same
> just the differences... just at the file level would do for a start.
good idea. for me it's a matter of time. but
On Tue, 2013-01-08 at 07:48 -0600, s...@9front.org wrote:
> > There are plenty of things in Plan 9 still in need of improvement
> > or even rewriting. That's why it makes me sad to see our small
> > community being made even smaller when some of the most skilled
> > programmers direct their effort
Once thing we could do is try to merge usb stuff so that those are again
compatible in the various 9 flavours out there.
Perhaps the ones to ask about this are Geoff and Cinap (I'm willing to help,
but have not done much on this front since long ago now).
Speaking just for myself, I think the glo
On Tue Jan 8 05:53:23 EST 2013, 9f...@hamnavoe.com wrote:
> > many drivers needed a rewrite anyway (like usb audio) because they
> > where a total mess.
>
> There are plenty of things in Plan 9 still in need of improvement
> or even rewriting. That's why it makes me sad to see our small
> commun
Inside joke.
On Mon, Jan 7, 2013 at 4:31 PM, erik quanstrom wrote:
> On Mon Jan 7 19:30:14 EST 2013, cardifrance...@gmail.com wrote:
> > > Tsk. Those Vita Nuova types are so unreliable...
> >
> > why?
>
> i believe this was an inside joke rather than a serious comment.
>
> - erik
>
>
> At the time, the idea was just to have a single binary (usbd) carrying the usb
> stuff. Because using multiple ones implied that the kernel (usbd was at /boot)
> had multiple copies of the same libraries for each different binary.
When we worry about multiple copies of the same library code, som
On Tuesday, January 08, 2013 19:38:03 Richard Miller wrote:
> > At the time, the idea was just to have a single binary (usbd) carrying
the
> > usb stuff. Because using multiple ones implied that the kernel (usbd
was
> > at /boot) had multiple copies of the same libraries for each different
> > bi
> I don't see how making another usb stack would be a good idea. We
> already have enough.
the current usb stack can't do some things it needs to be able to
do. it's particularly terrible at dealing with devices with scheduling
requirements. and it doesn't handle xhci.
- erik
> the current usb stack can't do some things it needs to be able to
> do. it's particularly terrible at dealing with devices with scheduling
> requirements. and it doesn't handle xhci.
>
> - erik
>
Well can't we just fix the problems with the current one? Most of the work is
already done. I
On Tue Jan 8 08:58:26 EST 2013, yari...@gmail.com wrote:
> APE's getsockname() returns port with bytes swapped (on 386).
> Fix:
>
> /n/dump/2013/0108/sys/src/ape/lib/bsd/_sock_ingetaddr.c:35,41 -
> /sys/src/ape/lib/bsd/_sock_ingetaddr.c:35,41
> if(p){
> *p++ = 0;
> ip->sin_family = AF_INET
I don't think erik was suggesting a rewrite, just improving it…
btw, in case anyone cares, I'm with richard on this.
On Jan 8, 2013, at 5:54 PM, Matthew Veety wrote:
>
>> the current usb stack can't do some things it needs to be able to
>> do. it's particularly terrible at dealing with device
the buffer isn't big enough for SHA1 hashes, which are larger than MD5
hashes.
- erik
; 9diff devtls.c
/n/sources/plan9/sys/src/9/port/devtls.c:732,738 - devtls.c:732,738
{
OneWay *volatile in;
Block *volatile b;
- uchar *p, seq[8], header[RecHdrLen], hmac[MD5dlen];
+
Any 9fans use jira or is it just me?
FWIW I am working on a client.
-Steve
i wanted to announce that it's becoming pretty stable now
under osx 10.8.
http://bitbucket.org/jas/drawterm-cocoa
it also compiles now under linux. and sometimes runs. :-)
especially if you don't resize.
the goal is to eventually have a full set of updated drawterms.
windows and pre-10.8 osx
9atom-nix (as nemo calls it) just replaced the old 9atom image.
you can find the old image @ 0201-9atom.iso.bz2
key additions to sources
- iplpxe (from cinap), a bios based pxe loader
- /sys/src/9/pcpae (from charles), a pentium kernel with pae.
- /sys/src/9/nix, a nix kernel that includes a termi
the lib we'r talking about isnt that big.
term% wc /sys/src/cmd/nusb/lib/*.c
5251635 10760 /sys/src/cmd/nusb/lib/dev.c
176 5193429 /sys/src/cmd/nusb/lib/dump.c
272 8576144 /sys/src/cmd/nusb/lib/parse.c
9733011 20333 total
--
cinap
34 matches
Mail list logo
