hello all,
I'm interested in working on a simple project for one of my class
(operating system). But we are required to turn in our project by the
end of the semester (may), so basically nothing big.
I have always been interested in Plan9 and have been able to run it on
my Windows XP machine. I w
as long as you restrict your network to plan 9 machines, it is possible
to import /net from a gateway machine and avoid sticky things like packet
filtering.
Back to the future yet? May I suggest that the "sticky" packet filtering,
more generally packet manipulation, has crucial applications in
2009/3/24 Rahul Murmuria :
> @ Devon:
> About Packet Classification. I read that iptables is not needed on
> Plan 9 because its "mount /net over the network" concept achieved
> anonymity or transparency -- something along those lines. "There are
> no logs about who is sending what, and that is a go
> I believe I have a rudimentary and probably non-working (at this
> point) packet filter in /n/sources/contrib/dho somewhere (it was
> written at least 4 years ago). I think it's called ``nfil.'' I
> believe it is desirable. Others disagree. Its usefulness is related
> directly to its application
2009/3/25 erik quanstrom :
>> I believe I have a rudimentary and probably non-working (at this
>> point) packet filter in /n/sources/contrib/dho somewhere (it was
>> written at least 4 years ago). I think it's called ``nfil.'' I
>> believe it is desirable. Others disagree. Its usefulness is relate
Hi all,
I am interested in the GSoc project: Linuxemu improvement.
But the project description seems too general. I don't know from
which aspect can we make improvement. There is a TODO file in
the linuxemu3 source directory and I find TLS, futex, VDSO listed.
Can these TODOs make a gsoc project?
it seems like a reasonable start to me, at least, but i don't know as
much as i could about the internals of linuxemu (i haven't really
looked inside since russ's initial version). the current maintainer is
frequently found in #plan9 on irc.freenode.net; i'd encourage you to
pop in there and see if
There are GSoC project suggestions at http://gsoc.cat-v.org/ideas/
but I think more are needed, and that it would be especially good
to have a further set of useful but simpler and smaller projects.
Projects need to be non-trivial for GSoC, but shouldn't
be hard enough that many of us would shun t
Does creative masoshism count as GSoC project? I dont know :)
Hm... These points all belong to the big topic, getting modern linux
distro binaries (NTPL stuff) to work. This would be a good thing
because I'm stuck on some old debian sarge that was just moved to the
archives.
Step one would be
2009/3/25 Charles Forsyth :
[snip]
> I don't know where the best place to suggest or discuss them would be,
> but I thought this list would reach nearly everyone interested.
I've sort of volunteered myself to webmaster the gsoc.cat-v.org page
for this year's SoC, so if you have any ideas you'd lik
On Mar 25, 6:14 am, rahul.is.a...@gmail.com (Rahul Murmuria) wrote:
> I was poking around for what it would take to get there. I found
> this[1]. I am basically looking to have a way to do routing using Plan
> 9. You can already do that on any standard Linux using Quagga[2] based
> on GNU Zebra.
>
> I didn't understand IP 'till I read the Plan9 source code.
one can replace "IP" in that sentence with so many other things... i'm
really glad plan9 exists.
On Wed, 25 Mar 2009 09:00:58 EDT "Devon H. O'Dell"
wrote:
> While creating an
> entire routing suite (such as Zebra/Quagga) is probably outside of the
> scope of a 3 month project, I think a diligent student could probably
> do something useful wi
2009/3/25 Bakul Shah :
> On Wed, 25 Mar 2009 09:00:58 EDT "Devon H. O'Dell"
> wrote:
>> While creating an
>> entire routing suite (such as Zebra/Quagga) is probably outside of the
>> scope of a 3 month project, I think a diligent student could pro
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I'd like to see a 3D graphics protocol. Then I could run the host on
some linux or window or mac box to do the display, and run the
graphics app in Plan9, or inferno, or ...
And (heresy aside) I've love a way to compile C++ programs for
plan9
2009/3/25 Paul Lalonde :
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> I'd like to see a 3D graphics protocol. Then I could run the host on some
> linux or window or mac box to do the display, and run the graphics app in
> Plan9, or inferno, or ...
>
> And (heresy aside) I've love a way to
hola,
> I saw the GSoC group and caught something: ethernet on usb. But I
> don't know much about that either.
>
cinap, already got usb over ethernet
http://plan9.bell-labs.com/sources/contrib/cinap_lenrek/usbether/
--
Federico G. Benavento
> Gogo reimplementation of cfront.
i'm pretty sure c++ has "advanced" to the point where
the cfront implementation technique is unworkable.
- erik
If you're interested in participating in the GSoC program, or for
ideas on open projects, take a look at http://gsoc.cat-v.org/ideas/
--dho
2009/3/25 erik quanstrom :
>> Gogo reimplementation of cfront.
>
> i'm pretty sure c++ has "advanced" to the point where
> the cfront implementation technique is unworkable.
So when I say something absolutely absurd on the list, people take it
seriously? I've got to work on my sense of humor here.
> > Gogo reimplementation of cfront.
>
> i'm pretty sure c++ has "advanced" to the point where
> the cfront implementation technique is unworkable.
The Comeau C++ compiler [1] uses the cfront technique, doesn't it? It is
supposed to be very standards-compliant.
[1] http://www.comeaucomputing.co
Paul Lalonde wrote:
I'd like to see a 3D graphics protocol. Then I could run the host on
some linux or window or mac box to do the display, and run the graphics
app in Plan9, or inferno, or ...
A port of vmgl to Plan9 would be nice for this.
http://www.cs.toronto.edu/~andreslc/xen-gl/
As for
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
A modern cfront is nearly impossible. Templates make it hella-hard.
And generics might actually be C++'s best feature, at least in
performance-code land.
Paul
On Mar 25, 2009, at 1:12 PM, Devon H. O'Dell wrote:
2009/3/25 Paul Lalonde :
--
>A modern cfront is nearly impossible. Templates make it hella-hard.
really? how is that?
Hi dear Plan9 fellows,
my Name is André Günther. I'd like to participate in the gsoc with an
implementation of a drawterm on the iPhone platform.
In this Mail I'd like to do the following 2 things:
1) Say some words about me and motivation of this project.
2) Present prelimin
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I wouldn't even consider a native GL port; it's device driver hell
for an API that I'm hoping will be extinct in the next couple of years.
VMGL looks like it might be a good base. I would like to see it
speak 9p though :-)
Paul
On Mar 25, 2009
Another student I spoke to on IRC spoke of the possibility of
bootstrapping LLVM for Plan 9 on Linux and getting it to run natively.
That would give us a whole bunch of different compilers.
--dho
On Wed Mar 25 19:22:23 EDT 2009, devon.od...@gmail.com wrote:
> Another student I spoke to on IRC spoke of the possibility of
> bootstrapping LLVM for Plan 9 on Linux and getting it to run natively.
> That would give us a whole bunch of different compilers.
>
> --dho
at the risk of being called s
hola,
I think we usually ask for drivers because that's what keeps some
of us away of using Plan 9 natively or in new hardware, but I
also get Charles point, soo..
I'd really like to see p9p for windows and/or 9vx for windows as well.
for the first, I heard somewhere that a german fellow even got
do we need drawterm for the iphone? is anyone going to use it?
I mean, it's a tiny screen, typing on handhelds sucks, plus is not
that there is killer app Plan 9 has that you _must_ run.
am I forgetting something obvious?
On Wed, Mar 25, 2009 at 5:57 PM, André Günther wrote:
>
> Hi dear Plan9
2009/3/25 Federico G. Benavento :
> do we need drawterm for the iphone? is anyone going to use it?
>
> I mean, it's a tiny screen, typing on handhelds sucks, plus is not
> that there is killer app Plan 9 has that you _must_ run.
>
> am I forgetting something obvious?
Tiny screen, but reasonable r
ok, you can't compare porting inferno to the ds with drawterm for the iphone
drawterm is an app to get to a Plan 9 server, inferno is a self contained
operating system where you can get the advantage of writing your
own apps for it.
for this port to be useful you need 1) an iphone; 2) a cpu serve
On Wed Mar 25 16:39:16 EDT 2009, cmbran...@cox.net wrote:
> > > Gogo reimplementation of cfront.
> >
> > i'm pretty sure c++ has "advanced" to the point where
> > the cfront implementation technique is unworkable.
>
> The Comeau C++ compiler [1] uses the cfront technique, doesn't it? It is
> sup
One nice thing about drawterm is it lets you export the iphone's
interfaces to Plan 9 -- that could lead to much more interesting
possibilities beyond typing at the shell. Probably a better approach
would be to look at providing an octopus client for iPhone though...
-eric
On Wed, Mar 25,
one problem with the iPhone is that you can't run third-party apps in
the background. that pretty much kills drawterm dead.
Wait, why?
Sent from my iPhone
On Mar 25, 2009, at 8:02 PM, andrey mirtchovski
wrote:
one problem with the iPhone is that you can't run third-party apps in
the background. that pretty much kills drawterm dead.
Erik Quanstrom wrote:
> On Wed Mar 25 16:39:16 EDT 2009, cmbran...@cox.net wrote:
> > The Comeau C++ compiler [1] uses the cfront technique, doesn't it? It is
> > supposed to be very standards-compliant.
> >
> > [1] http://www.comeaucomputing.com
>
> where do they claim this? i see a claim that
dropping the connection to the plan9 host every time you do something
else not a showstopper?
On Wed, Mar 25, 2009 at 7:07 PM, Eric Van Hensbergen wrote:
> Wait, why?
On 03/25/09 02:12 PM, Charles Forsyth wrote:
A modern cfront is nearly impossible. Templates make it hella-hard.
really? how is that?
Everything is possible. It is software, after all. But it is not
practical. The
original cfront was, to some extent, a cpp(1) on steroids. AFAIR, it
Guess it depends on how you are using it. Wonder if you could save
enough state to recover -- probably just Vnc at that point though.
Would octopus have the same problem or would Op help solve the state
problem?
-eric
Sent from my iPhone
On Mar 25, 2009, at 8:11 PM, andrey mirtchovs
there are a couple of other problems that I see with dt on the iPhone:
- platform: google may be much more interested in seeing apps for the
G-phone than they are for the rival (but then, a g-phone version may
be much easier to do, and not worth a gsoc)
- barrier to entry: the student should have
On Wed, Mar 25, 2009 at 08:21:12PM -0500, Eric Van Hensbergen wrote:
> Guess it depends on how you are using it. Wonder if you could save
> enough state to recover -- probably just Vnc at that point though.
>
> Would octopus have the same problem or would Op help solve the state
> problem?
>
>
2009/3/25 Federico G. Benavento :
[snip]
> As for applications for Plan 9, the ones we need (read to cope with
> the rest of the world) are too big for a soc project, so even if I don't
> like gcc, a port would help on this matter.
Yes and no. As long as there are reasonable expectations for the
p
A cfront-ish approach to templates leads to hellish duplication of
template-generated code in each module, and thence to even worse code
bloat. Of course, my understanding of what's possible in a cfront
translation is perhaps (probably) naive.
Paul
On 25-Mar-09, at 2:12 PM, Charles Forsyt
On Mar 25, 2009, at 6:51 PM, Paul Lalonde wrote:
A cfront-ish approach to templates leads to hellish duplication of
template-generated code in each module, and thence to even worse
code bloat.
That's not the case, really. The compiler (well, at least the
conventional one, not the one like
2009/3/25 andrey mirtchovski :
> there are a couple of other problems that I see with dt on the iPhone:
>
> - platform: google may be much more interested in seeing apps for the
> G-phone than they are for the rival (but then, a g-phone version may
> be much easier to do, and not worth a gsoc)
>
>
I'd like to note again that I was kidding about cfront <_<
2009/3/25 Paul Lalonde :
> A cfront-ish approach to templates leads to hellish duplication of
> template-generated code in each module, and thence to even worse code bloat.
> Of course, my understanding of what's possible in a cfront tran
On Mar 25, 2009, at 6:10 PM, Chris Brannon wrote:
Erik Quanstrom wrote:
On Wed Mar 25 16:39:16 EDT 2009, cmbran...@cox.net wrote:
The Comeau C++ compiler [1] uses the cfront technique, doesn't
it? It is
supposed to be very standards-compliant.
[1] http://www.comeaucomputing.com
where do t
2009/3/25 erik quanstrom :
> On Wed Mar 25 19:22:23 EDT 2009, devon.od...@gmail.com wrote:
>> Another student I spoke to on IRC spoke of the possibility of
>> bootstrapping LLVM for Plan 9 on Linux and getting it to run natively.
>> That would give us a whole bunch of different compilers.
>>
>> --d
Killed. From the license agreement for iPhone developers (which
requires a free Apple Developer Connection account to view; sorry):
"3.3.3 Without Apple’s prior written approval, an Application may not
provide, unlock or enable a enable additional features or
functionality through distribut
On Mar 25, 2009, at 4:26 PM, erik quanstrom wrote:
On Wed Mar 25 19:22:23 EDT 2009, devon.od...@gmail.com wrote:
Another student I spoke to on IRC spoke of the possibility of
bootstrapping LLVM for Plan 9 on Linux and getting it to run
natively.
That would give us a whole bunch of different c
2009/3/25 Pietro Gagliardi :
> Killed. From the license agreement for iPhone developers (which requires a
> free Apple Developer Connection account to view; sorry):
>
> "3.3.3 Without Apple’s prior written approval, an Application may not
> provide, unlock or enable a enable additional features or
I have the developer kit, I'd be willing to submit the resulting app
for free distro. That's at least one less barrier.
-eric
Sent from my iPhone
On Mar 25, 2009, at 8:31 PM, andrey mirtchovski
wrote:
there are a couple of other problems that I see with dt on the iPhone:
- platform
If this were true there would be no vnc for iPhone, and there is. If
vnc is okay, drawterm or octopus would be too.
-eric
Sent from my iPhone
On Mar 25, 2009, at 9:03 PM, Pietro Gagliardi wrote:
Killed. From the license agreement for iPhone developers (which
requires a free Apple Dev
Also, figuring out how multitouch works with plan 9 would be valuable
in itself -- although admitadly could be done without an iPhone.
-eric
Sent from my iPhone
On Mar 25, 2009, at 9:03 PM, Pietro Gagliardi wrote:
Killed. From the license agreement for iPhone developers (which
require
i think the drawterm port would be interesting, but how to deal with
the mismatch between the touch and 3-button-mouse interfaces seems
like a big issue. i don't yet have an iPhone or iPod Touch, but for
me, drawterm would push me over for the later.
for André (or anyone with similar interests), i
Also, we obviously cannot use rio, unless we greatly restrict the
user's visibility. Unless we provide zooming?
Maybe a text-based environment that runs exclusively off rc, sam,
acme, etc. with the standard keyboard at the bottom:
--
cpu%
Theory and practice are different. As previous posters have noted, VNC
apps in the app store give us carte blanche on drawterm as long as we
don't run anything dynamically on the phone itself.
On Thu, Mar 26, 2009 at 11:53 AM, Pietro Gagliardi wrote:
> Also, we obviously cannot use rio, unless we
I think rio is probably not useful, but a purely text based
environtment isn't interesting either...
-eric
Sent from my iPhone
On Mar 25, 2009, at 9:53 PM, Pietro Gagliardi wrote:
Also, we obviously cannot use rio, unless we greatly restrict the
user's visibility. Unless we provide
On Wed, 25 Mar 2009 21:25:07 CDT Eric Van Hensbergen wrote:
> Also, figuring out how multitouch works with plan 9 would be valuable
> in itself -- although admitadly could be done without an iPhone.
Exactly what I was thinking while reading this thread! An
intuitive multitouch interface that go
On Wed, Mar 25, 2009 at 11:14 PM, Eric Van Hensbergen wrote:
> I think rio is probably not useful, but a purely text based environtment
> isn't interesting either...
The only thing I could see anyone using this for is if they wrote an
iPhone-tailored UI for controlling... something... and needed
A text based environment isn't that interesting, but a 9p transport
that allows the end user to cache and store files on the device to be
reviewed through currently provided renderers/decoders (pdf, jpeg,
tiff, myriad of audio formats, html/xml) would be ideal. Given that
we're starting to
iJuke ;-)
On 25-Mar-09, at 8:24 PM, Tom Lieber wrote:
On Wed, Mar 25, 2009 at 11:14 PM, Eric Van Hensbergen > wrote:
I think rio is probably not useful, but a purely text based
environtment
isn't interesting either...
The only thing I could see anyone using this for is if they wrote an
iPh
my questions were more about the real usage of iphone's dt
my short sighted vision of the gsoc is this, I didn't use any
of the stuff that gsoc 2007 got us, though I recognize the
inferno ds port.
but for the rest, it might be interesting, but is someone
using that stuff?
iphone's drawterm sounds
> > ok, you can't compare porting inferno to the ds with drawterm for the iphone
> > drawterm is an app to get to a Plan 9 server, inferno is a self contained
> > operating system where you can get the advantage of writing your
> > own apps for it.
>
> Except that drawterm ends up being a mini-Pla
> I've wanted to work with somebody
> on Plan 9 as a routing device in networks for some time, at least in
> the field of packet classification.
I'll be happy to help, too, if so desired, I have been playing with
IPFilters in a pretty serious way for many years (and ipfw before
that) and may well
> I think the gist behind LLVM is that compilers can target it as a
> machine type, and it is able to create native binaries for its own
> supported machine type for anything that can run on it. So any
> compiler that can target LLVM would be able to target Plan 9. (Which
> is several of them)
at
67 matches
Mail list logo
