Re: [9fans] Plan 9 on Routers?
On Tue, Mar 24, 2009 at 7:20 PM, erik quanstrom quans...@quanstro.net wrote: see ipconfig(8). ip/rip ... I wonder! P.S.: Thanks for all the pointers... -- Rahul Murmuria
[9fans] looking for a project
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 would like to propose Plan9 to my team. But I don't have any good idea =[ I saw the GSoC group and caught something: ethernet on usb. But I don't know much about that either. Can you guys guide me in the right direction? Thanks a lot in advance.
Re: [9fans] Plan 9 on Routers?
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 any packet-switched network (like... the Net) and a certain OS's current lack of facilities, out of the box, to deal with the problem does not automatically mean the problem should be thrown out. Of course, in an essentially sheltered world not having an IDS is as good as having one but, you see, that's the world of a certain OS. Other OSes have to live in the wild. P.S. This is a get-back from the NAT thread. --On Tuesday, March 24, 2009 7:20 PM -0400 erik quanstrom quans...@quanstro.net wrote: It seems that /net/iproute is where I can start. It has a complete interface for editing routes. What we need is a user space script that implements routing, like http://www.openbgp.org/ does on OpenBSD. Except that, it will only have to send add, delete and flush control messages to the iproute file. see ipconfig(8). 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 good thing. that's not strictly true. 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. there is also ipmux (discussed in ip(3)). i don't think ipmux has enough rewriting (or state) to implement something like nat. - erik
Re: [9fans] Plan 9 on Routers?
2009/3/24 Rahul Murmuria rahul.is.a...@gmail.com: @ 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 good thing. This is a flawed argument. If using Plan 9 as an edge router instead of a bridge, it's imperative to have some sort of filtering. This doesn't just apply to NAT situations (and even then, mounting /net isn't really the same thing as NAT). There is ipmux, but as Eric says, it's not fleshed out enough to implement NAT. Eric also says: ``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.'' This is a good idea in theory, but in practice most machines are not Plan 9 and there's almost always a need for a heterogeneous environment. Some would solve this by porting the ability to `import /net' to other operating systems. My feeling has always been that some sort of packet filtration system should exist to make Plan 9 useful in routing in such heterogeneous networks. It's easier to do and would facilitate wider adoption (whether that's a good thing or not is always up for debate). I am not sure where exactly the packet classification idea fits in. I read in the /proc documents that /proc/net provides useful information about the network stack. There is this ip_conntrack which is used to list / track network connections. I wonder what we would need to get packet information and perform filtering. Is it desirable to get that filtering to work if it already does not exist? 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, and without it, there's no way to test Plan 9 in an environment in which it would be useful. You said earlier ``I qualify for GSoC but I was planning not to apply, as from where I see it, that brings in restrictions to the independence of thought. I am open to applying though, if this is a good enough (and small enough) idea for SoC.'' -- I'm not sure why you think that the idea of the SoC project restricts independence of thought -- I've certainly never seen it as such. 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 with OSPF or BGP. It's entirely possible that a 3 month project could consist of analyzing Plan 9's ability to function in this environment and making changes to facilitate the implementation of routing protocols. Or creating a packet filter. In either case, I'd personally be excited to see this suggested as a SoC project if it was well thought out. 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. Thank you all for replying so far! No problem :) --dho -- Rahul Murmuria
Re: [9fans] Plan 9 on Routers?
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, and without it, there's no way to test Plan 9 in an environment in which it would be useful. why not extend the packet filtering capabilities of the existing #I? - erik
Re: [9fans] Plan 9 on Routers?
2009/3/25 erik quanstrom quans...@quanstro.net: 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, and without it, there's no way to test Plan 9 in an environment in which it would be useful. why not extend the packet filtering capabilities of the existing #I? That's what it did, if I recall correctly. --dho - erik
[9fans] gsoc linuxemu project help
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? Thanks. -- Regards, Zhao
Re: [9fans] gsoc linuxemu project help
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 you can catch him to ask.
[9fans] request for more GSoC project suggestions
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 them (or indeed, have shunned them). Based on my experience several years ago, I'd also look for projects that are modular, so that the set of deliverables can be extended or reduced depending how things go. That worked well for the projects I was involved with. The problem with ports of the system or device driver writing, in my experience, is that satisfying though they are, and as necessary as they might be, they are typically quite hard to supervise, and will usually be fairly difficult for relative novices. There is quite a bit to learn for most students just to get started and be productive in the programming environment, although 9vx does make that much easier. Application-level projects are typically easier to supervise because they don't need specialised equipment, and many more people on this list and elsewhere can help with plausible advice, and also help debug when students are stuck. (Advice will sometimes be contradictory, but that's not a bad lesson to learn, too.) It's quite hard to help when special hardware or kernel-level debugging is involved. Because quite a bit in Plan 9 (or Inferno/9vx/p9p etc) is done at user-level that is done at kernel-level in other systems, that shouldn't narrow the scope much. I wrote application-level not just user-level earlier because I thought it would be good to have some interesting applications of the system. Of course, I don't mean to preclude system-level things when students are especially keen on that (as indeed I was during my school and university years). 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.
Re: [9fans] gsoc linuxemu project help
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 to get the simple single-threaded stuff to run like echo and cat. The part point here is TLS. I had a somewhat working plan9 driver for it but never packaged it up because i wanted the whole thing working before submitting a kernel patch. You may later progress to multithreaded apps wich use futex syscall. The way I work on linuxemu is randomly trying stuff out, see where it crashes... try to understand why it crashes... implement/fix syscalls and try again. Sometimes it easy and sometimes you scratch your head for a several months. Its hard to estimate the time needed to get X running because you never know what crazy optimization shit the linux/libc guys come up with next to make you suffer. Here is always a huge risk of failure in linuxemu because all the details are in Ulrich Dreppers head only or encrypted with c-preprocessor-ifdef-encryption in the glibc-code so getting help is very hard and most of the stuff you have to find out yourself (this may cause brain damage over time). I cant (officialy) mentor you as I'm short of time and have no scientific background or something, but I will try to give you all infeormation/code and support I have... Its good to hear that someone starts taking over some work! :) Just drop me an email. I may be in irc from time to time too but dont count on it. -- cinap ---BeginMessage--- 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? Thanks. -- Regards, Zhao---End Message---
Re: [9fans] request for more GSoC project suggestions
2009/3/25 Charles Forsyth fors...@terzarima.net: [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 like to get on there, just mail them to me, or to the plan9-gsoc mailing list and I'll get them plopped up there. I agree with your points, and I think some decent application ideas are in order. --dho
Re: [9fans] Plan 9 on Routers?
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. Maybe there is a filesystem that exposes the kernel routing table to user space for certain routing algorithm scripts to hack upon? My objective is to be able to implement a new routing protocol on a router created using a standard computer with multiple NIC cards, maybe on a model P2P type network? I also would love to see what having /net on a router would enable us to do. I didn't understand IP 'till I read the Plan9 source code. In my opinion, it should replace the RFCs as the standard. If you can't implement your *new* protocol with the existing interfaces, then I suggest you should follow the linux route.
Re: [9fans] Plan 9 on Routers?
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.
Re: [9fans] Plan 9 on Routers?
On Wed, 25 Mar 2009 09:00:58 EDT Devon H. O'Dell devon.od...@gmail.com
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 with OSPF or BGP. It's entirely possible that a 3
month project could consist of analyzing Plan 9's ability to function
in this environment and making changes to facilitate the
implementation of routing protocols. Or creating a packet filter.
Thinking a bit more about it, extending /net/iproute to allow
routing metrics may be what is needed for porting/building
something like openospfd or openbgpd. Basically
/net/{iproute,ipifc} etc need to do more or less what a
routing socket does under *BSD (man 4 route). Of course,
there may be other things missing in the p9 IP stack that may
get in the way but now I think porting something like
openospfd in a summer is doable.
Re: [9fans] Plan 9 on Routers?
2009/3/25 Bakul Shah bakul+pl...@bitblocks.com:
On Wed, 25 Mar 2009 09:00:58 EDT Devon H. O'Dell devon.od...@gmail.com
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 with OSPF or BGP. It's entirely possible that a 3
month project could consist of analyzing Plan 9's ability to function
in this environment and making changes to facilitate the
implementation of routing protocols. Or creating a packet filter.
Thinking a bit more about it, extending /net/iproute to allow
routing metrics may be what is needed for porting/building
something like openospfd or openbgpd. Basically
/net/{iproute,ipifc} etc need to do more or less what a
routing socket does under *BSD (man 4 route). Of course,
there may be other things missing in the p9 IP stack that may
get in the way but now I think porting something like
openospfd in a summer is doable.
Yeah, that's what I meant to imply :) Thanks for clarifying that :)
--dho
Re: [9fans] request for more GSoC project suggestions
2009/3/25 Paul Lalonde plalo...@telus.net: -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. That would give me a reason to get Plan9 up on this scary multi-core part I'm working on. Without C++ support, I can't run the principle application I need :-( Gogo reimplementation of cfront. Paul On Mar 25, 2009, at 8:16 AM, Charles Forsyth wrote: 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 them (or indeed, have shunned them). Based on my experience several years ago, I'd also look for projects that are modular, so that the set of deliverables can be extended or reduced depending how things go. That worked well for the projects I was involved with. The problem with ports of the system or device driver writing, in my experience, is that satisfying though they are, and as necessary as they might be, they are typically quite hard to supervise, and will usually be fairly difficult for relative novices. There is quite a bit to learn for most students just to get started and be productive in the programming environment, although 9vx does make that much easier. Application-level projects are typically easier to supervise because they don't need specialised equipment, and many more people on this list and elsewhere can help with plausible advice, and also help debug when students are stuck. (Advice will sometimes be contradictory, but that's not a bad lesson to learn, too.) It's quite hard to help when special hardware or kernel-level debugging is involved. Because quite a bit in Plan 9 (or Inferno/9vx/p9p etc) is done at user-level that is done at kernel-level in other systems, that shouldn't narrow the scope much. I wrote application-level not just user-level earlier because I thought it would be good to have some interesting applications of the system. Of course, I don't mean to preclude system-level things when students are especially keen on that (as indeed I was during my school and university years). 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. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (Darwin) iD8DBQFJyoybpJeHo/Fbu1wRAoi3AKCTQLsrxzBt7m94P3LsOR+o85KungCfT6Ms o+vaJtOAjx1IxDqCtWskyQY= =FvNd -END PGP SIGNATURE-
Re: [9fans] looking for a project
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
Re: [9fans] request for more GSoC project suggestions
Gogo reimplementation of cfront. i'm pretty sure c++ has advanced to the point where the cfront implementation technique is unworkable. - erik
Re: [9fans] looking for a project
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
Re: [9fans] request for more GSoC project suggestions
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.com -- Chris
Re: [9fans] request for more GSoC project suggestions
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 native GL, I'm not sure if there is any hardware option that has enough documentation to implement a driver. I was considering digging up my old 3dfx card for a miniGL to play with.
Re: [9fans] request for more GSoC project suggestions
-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 plalo...@telus.net: -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. That would give me a reason to get Plan9 up on this scary multi-core part I'm working on. Without C++ support, I can't run the principle application I need :-( Gogo reimplementation of cfront. Paul On Mar 25, 2009, at 8:16 AM, Charles Forsyth wrote: 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 them (or indeed, have shunned them). Based on my experience several years ago, I'd also look for projects that are modular, so that the set of deliverables can be extended or reduced depending how things go. That worked well for the projects I was involved with. The problem with ports of the system or device driver writing, in my experience, is that satisfying though they are, and as necessary as they might be, they are typically quite hard to supervise, and will usually be fairly difficult for relative novices. There is quite a bit to learn for most students just to get started and be productive in the programming environment, although 9vx does make that much easier. Application-level projects are typically easier to supervise because they don't need specialised equipment, and many more people on this list and elsewhere can help with plausible advice, and also help debug when students are stuck. (Advice will sometimes be contradictory, but that's not a bad lesson to learn, too.) It's quite hard to help when special hardware or kernel-level debugging is involved. Because quite a bit in Plan 9 (or Inferno/9vx/p9p etc) is done at user-level that is done at kernel-level in other systems, that shouldn't narrow the scope much. I wrote application-level not just user-level earlier because I thought it would be good to have some interesting applications of the system. Of course, I don't mean to preclude system-level things when students are especially keen on that (as indeed I was during my school and university years). 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. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (Darwin) iD8DBQFJyoybpJeHo/Fbu1wRAoi3AKCTQLsrxzBt7m94P3LsOR+o85KungCfT6Ms o+vaJtOAjx1IxDqCtWskyQY= =FvNd -END PGP SIGNATURE- -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (Darwin) iD8DBQFJypaTpJeHo/Fbu1wRAvhqAKDVGdbVdtqRqT811TJ/cixYcadiPwCgy/E8 /SJh8wFz5YXgVSg570Xmlnw= =pomL -END PGP SIGNATURE-
Re: [9fans] request for more GSoC project suggestions
A modern cfront is nearly impossible. Templates make it hella-hard. really? how is that?
[9fans] GSOC: Drawterm for the iPhone
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 preliminary suggestion how I would proceed with the project. I'd like to ask you to: 1) Discuss if this project is actually wanted. 2) If 1) is positive: Discuss my application. Me and my Motivation: I am 21 and an undergraduate in Philosophy and Cognitive Science at the university of Freiburg. During the course of my studying i've been taking several computer science classes. The reason I am not studying computer science is, because I have the feeling for problem solving an autodidactic method is sufficient for most cases and for which it is not I am taking those specific classes. I have about 8 years experience with programming C and working in unix like environments. I am working on the mac platform for about 5 years now and aquired some ObjC skills. That means I have done Cocoa development. So I am familiar with apple like APIs and also the whole XCode environment. I haven't done any iPhone development yet, but I am pretty confident, that I can acquire those skills with my background in no time. (I have no apple developer license for the iPhone, but I have an iPhone and I am able to test custom applications on it. I would of course apply for a license if I do the project) Unfortunately I can't show you any recent work of mine, because it's all internal university stuff I am doing for the lab, which I am not supposed to post anywhere. I've been following Plan9 shallowly for some while now. But just recently got more into it. I am using it exclusively in a Qemu/ Drawterm fashion. I'd like to explore more of Plan9 in the future. Though I don't feel confident just now messing with kernel sources or other important infrastructure, a drawterm port may just be the best thing to do. My mac experiences will come in handy, too. Why is the port necessary? Well Plan9 is awesome. Being able to drawterm into it with my iPhone would be totally awesome. I don't know how you guys feel about this. Please discuss! How to proceed: Because I might have just failed with the above text, I don't want to go into much detail now. Still a small outline here: I think there are two parts to the question: 1) How does drawterm theoretically transform into an iPhone application. 2) What are the technical things to deal with 1) is much about interface design. Clearly the iPhone doesn't have a keyboard nor a three button mouse. For the keyboard it might be sufficient to provide the standard onscreen keyboard apple provides. For the mouse I haven't yet wraped my mind around the problem. Double tapping and gestures come to my mind though. Another possibility would be to have onscreen virtual mouse buttons, but that might be not the best solution. Also Bladerunner type of zooming gestures might come into handy, with such a tiny screen, which is clearly another limitation of the hardware platform. 2) The drawterm code base is pretty much self contained and C based. The iPhone OS is pretty much a stripped down OSX and should be stable enough for that and doesn't amount to much more than a recompile. So the main part is providing the draw/audio and other devices. Reusing osx code is not possible, because the iPhone doesn't share that particular API the code base is using. Here a new implementation using ObjC and the iPhone API is necessary. Best wishes, André Günther
Re: [9fans] request for more GSoC project suggestions
-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, at 1:40 PM, James Tomaschke wrote: 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 native GL, I'm not sure if there is any hardware option that has enough documentation to implement a driver. I was considering digging up my old 3dfx card for a miniGL to play with. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (Darwin) iD8DBQFJyrSppJeHo/Fbu1wRAup1AJ0QtVGC9qs/SRfKinhWbfJnhubUYwCdHybx cOf6H3838tDouxzXEvWw1PE= =qRNo -END PGP SIGNATURE-
Re: [9fans] request for more GSoC project suggestions
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
Re: [9fans] request for more GSoC project suggestions
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 stupid twice in one day, i have to say i don't see what the payoff would be. doing something with gcc helps with gcc-specific code. what does llvm give us? - erik
Re: [9fans] request for more GSoC project suggestions
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 acme going, but I don't know where that work is, for the latter there is also a port stalled. 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. right now, one can get by running old linux binaries and linuxemu+ equis, so improving linuxemu is also a project I'm interested. just my opinion On Wed, Mar 25, 2009 at 12:16 PM, Charles Forsyth fors...@terzarima.net wrote: 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 them (or indeed, have shunned them). Based on my experience several years ago, I'd also look for projects that are modular, so that the set of deliverables can be extended or reduced depending how things go. That worked well for the projects I was involved with. The problem with ports of the system or device driver writing, in my experience, is that satisfying though they are, and as necessary as they might be, they are typically quite hard to supervise, and will usually be fairly difficult for relative novices. There is quite a bit to learn for most students just to get started and be productive in the programming environment, although 9vx does make that much easier. Application-level projects are typically easier to supervise because they don't need specialised equipment, and many more people on this list and elsewhere can help with plausible advice, and also help debug when students are stuck. (Advice will sometimes be contradictory, but that's not a bad lesson to learn, too.) It's quite hard to help when special hardware or kernel-level debugging is involved. Because quite a bit in Plan 9 (or Inferno/9vx/p9p etc) is done at user-level that is done at kernel-level in other systems, that shouldn't narrow the scope much. I wrote application-level not just user-level earlier because I thought it would be good to have some interesting applications of the system. Of course, I don't mean to preclude system-level things when students are especially keen on that (as indeed I was during my school and university years). 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. -- Federico G. Benavento
Re: [9fans] GSOC: Drawterm for the iPhone
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 andr...@gmx.de wrote: 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 preliminary suggestion how I would proceed with the project. I'd like to ask you to: 1) Discuss if this project is actually wanted. 2) If 1) is positive: Discuss my application. Me and my Motivation: I am 21 and an undergraduate in Philosophy and Cognitive Science at the university of Freiburg. During the course of my studying i've been taking several computer science classes. The reason I am not studying computer science is, because I have the feeling for problem solving an autodidactic method is sufficient for most cases and for which it is not I am taking those specific classes. I have about 8 years experience with programming C and working in unix like environments. I am working on the mac platform for about 5 years now and aquired some ObjC skills. That means I have done Cocoa development. So I am familiar with apple like APIs and also the whole XCode environment. I haven't done any iPhone development yet, but I am pretty confident, that I can acquire those skills with my background in no time. (I have no apple developer license for the iPhone, but I have an iPhone and I am able to test custom applications on it. I would of course apply for a license if I do the project) Unfortunately I can't show you any recent work of mine, because it's all internal university stuff I am doing for the lab, which I am not supposed to post anywhere. I've been following Plan9 shallowly for some while now. But just recently got more into it. I am using it exclusively in a Qemu/Drawterm fashion. I'd like to explore more of Plan9 in the future. Though I don't feel confident just now messing with kernel sources or other important infrastructure, a drawterm port may just be the best thing to do. My mac experiences will come in handy, too. Why is the port necessary? Well Plan9 is awesome. Being able to drawterm into it with my iPhone would be totally awesome. I don't know how you guys feel about this. Please discuss! How to proceed: Because I might have just failed with the above text, I don't want to go into much detail now. Still a small outline here: I think there are two parts to the question: 1) How does drawterm theoretically transform into an iPhone application. 2) What are the technical things to deal with 1) is much about interface design. Clearly the iPhone doesn't have a keyboard nor a three button mouse. For the keyboard it might be sufficient to provide the standard onscreen keyboard apple provides. For the mouse I haven't yet wraped my mind around the problem. Double tapping and gestures come to my mind though. Another possibility would be to have onscreen virtual mouse buttons, but that might be not the best solution. Also Bladerunner type of zooming gestures might come into handy, with such a tiny screen, which is clearly another limitation of the hardware platform. 2) The drawterm code base is pretty much self contained and C based. The iPhone OS is pretty much a stripped down OSX and should be stable enough for that and doesn't amount to much more than a recompile. So the main part is providing the draw/audio and other devices. Reusing osx code is not possible, because the iPhone doesn't share that particular API the code base is using. Here a new implementation using ObjC and the iPhone API is necessary. Best wishes, André Günther -- Federico G. Benavento
Re: [9fans] GSOC: Drawterm for the iPhone
2009/3/25 Federico G. Benavento benave...@gmail.com: 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 resolution. Should find out who put it on the ideas page for GSoC; it wasn't me (so clearly somebody is interested). Besides, look at the DS port. Smaller screens, lower resolution (even combined, I think). Whether it's novelty or not isn't for me to say, but I can see how it would be useful. --dho
Re: [9fans] GSOC: Drawterm for the iPhone
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 server to cpu and 3) that killer app that makes want to drawterm from the iphone. I think writing that killer app, whatever that is makes more sense. On Wed, Mar 25, 2009 at 9:24 PM, Devon H. O'Dell devon.od...@gmail.com wrote: 2009/3/25 Federico G. Benavento benave...@gmail.com: 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 resolution. Should find out who put it on the ideas page for GSoC; it wasn't me (so clearly somebody is interested). Besides, look at the DS port. Smaller screens, lower resolution (even combined, I think). Whether it's novelty or not isn't for me to say, but I can see how it would be useful. --dho -- Federico G. Benavento
Re: [9fans] request for more GSoC project suggestions
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 supposed to be very standards-compliant. [1] http://www.comeaucomputing.com where do they claim this? i see a claim that they accept cfront-isms, but that's a different claim. - erik
Re: [9fans] GSOC: Drawterm for the iPhone
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, 2009 at 7:39 PM, Federico G. Benavento benave...@gmail.com wrote: 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 server to cpu and 3) that killer app that makes want to drawterm from the iphone. I think writing that killer app, whatever that is makes more sense. On Wed, Mar 25, 2009 at 9:24 PM, Devon H. O'Dell devon.od...@gmail.com wrote: 2009/3/25 Federico G. Benavento benave...@gmail.com: 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 resolution. Should find out who put it on the ideas page for GSoC; it wasn't me (so clearly somebody is interested). Besides, look at the DS port. Smaller screens, lower resolution (even combined, I think). Whether it's novelty or not isn't for me to say, but I can see how it would be useful. --dho -- Federico G. Benavento
Re: [9fans] GSOC: Drawterm for the iPhone
one problem with the iPhone is that you can't run third-party apps in the background. that pretty much kills drawterm dead.
Re: [9fans] GSOC: Drawterm for the iPhone
Wait, why? Sent from my iPhone On Mar 25, 2009, at 8:02 PM, andrey mirtchovski mirtchov...@gmail.com wrote: one problem with the iPhone is that you can't run third-party apps in the background. that pretty much kills drawterm dead.
Re: [9fans] request for more GSoC project suggestions
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 they accept cfront-isms, but that's a different claim. Quoting http://comeaucomputing.com/faqs/genfaq.html#ccompiler Input C++ code is translated into internal compiler trees and symbol tables looking nothing like C++ or C. As well, it generates an internal proprietary intermediate form. But instead of using a proprietary back end code generator, Comeau C++ 4.3.3 generates C code as its output. Isn't that what cfront did, more or less? -- Chris
Re: [9fans] GSOC: Drawterm for the iPhone
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 eri...@gmail.com wrote: Wait, why?
Re: [9fans] request for more GSoC project suggestions
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 operated by manipulating C source code. With modern C++ things like inlines, templates and concepts operate at a level of AST. I guess one could use C for an AST representation, but that would be a pretty daring feat. Thanks, Roman.
Re: [9fans] GSOC: Drawterm for the iPhone
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 mirtchovski mirtchov...@gmail.com wrote: 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 eri...@gmail.com wrote: Wait, why?
Re: [9fans] GSOC: Drawterm for the iPhone
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? -eric There's also aan and recover4e, or do I misunderstand the problem? pgprUJZU9yduV.pgp Description: PGP signature
Re: [9fans] request for more GSoC project suggestions
2009/3/25 Federico G. Benavento benave...@gmail.com: [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 projects, there is no reason an application or application suite cannot be duplicated or ported. GSoC isn't entirely about completing a project: the scope of a project may just be laying groundwork or a foundation for a later project which involves the porting. I think a lot of your sentiment about the GSoC program is a bit short sighted (based on emails in 2 threads now). right now, one can get by running old linux binaries and linuxemu+ equis, so improving linuxemu is also a project I'm interested. just my opinion Linux emulation can always use work everywhere, especially since those assholes keep changing it every chance they get. More syscalls for more glibc versions = good. FreeBSD's linux compat works great these days (so it may not be a half bad place to start looking for improvements, though, admittedly, I haven't used linuxemu on Plan 9) --dho
Re: [9fans] request for more GSoC project suggestions
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 Forsyth wrote: A modern cfront is nearly impossible. Templates make it hella-hard. really? how is that?
Re: [9fans] request for more GSoC project suggestions
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 we have on Plan9) has very little tricks up its sleeves that can help with that. The best case scenario is to generate everything into .os and hope that de- duping will be done by the linker. That's how COMDAT works. cfront-ish approach can do exactly the same. Thanks, Roman.
Re: [9fans] GSOC: Drawterm for the iPhone
2009/3/25 andrey mirtchovski mirtchov...@gmail.com: 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 an iPhone (the simulator is only somewhat sufficient). - barrier to entry: the iPhone development kit costs $99 (that's not the SDK, which is free) and puts you through a few too many hoops just to order a development token for your phone, then much more stuff to put it into the AppStore. it's not pretty. i don't want to turn anyone off from the idea: if anyone thinks it's worth it go for it. The only thing barring the student who wrote this proposal from completing it is the iPhone development kit (which I will fund if he's accepted and I have to, $99 really isn't that much) and a bunch of people on this list saying it's a bad idea. I think the 3.0 SDK fixes some of the problems that have been mentioned in this thread, and I think it does raise interesting challenges. He already has an iPhone, ObjC experience, and XCode experience. Also: 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-Plan 9 kernel like everything else out there. The concepts aren't so different. Either way, SSH clients exist for the iPhone. Are those useless because it's hard to type commands on native keyboards and the text is tiny. --dho
Re: [9fans] request for more GSoC project suggestions
I'd like to note again that I was kidding about cfront _ 2009/3/25 Paul Lalonde plalo...@telus.net: 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 Forsyth wrote: A modern cfront is nearly impossible. Templates make it hella-hard. really? how is that?
Re: [9fans] request for more GSoC project suggestions
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 they claim this? i see a claim that they accept cfront-isms, but that's a different claim. Quoting http://comeaucomputing.com/faqs/genfaq.html#ccompiler Input C++ code is translated into internal compiler trees and symbol tables looking nothing like C++ or C. As well, it generates an internal proprietary intermediate form. But instead of using a proprietary back end code generator, Comeau C++ 4.3.3 generates C code as its output. Isn't that what cfront did, more or less? Not really, no. In their case, I believe, C language is treated as an intermediate language. It has no traces of the Cisms of the original C++ code. It is as mangled as an assembler would be if you do g++ -S foo.cc. cfront (well, at least the original one) still preserved most of the original code (as do most of thing like cyclone, cilk, etc.). Thanks, Roman.
Re: [9fans] request for more GSoC project suggestions
2009/3/25 erik quanstrom quans...@coraid.com: 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 stupid twice in one day, i have to say i don't see what the payoff would be. doing something with gcc helps with gcc-specific code. what does llvm give us? OMG STOOPID. Just kidding, of course. 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) - erik --dho
Re: [9fans] GSOC: Drawterm for the iPhone
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 distribution mechanisms other than the App Store. drawterm may be used to gain access to a large repository of optional software (/n/sources/contrib, /n/sources/extra). An ill-informed lawyer may bring this up: 3.3.2 An Application may not itself install or launch other executable code by any means, including without limitation through the use of a plug-in architecture, calling other frameworks, other APIs or otherwise. No interpreted code may be downloaded and used in an Application except for code that is interpreted and run by Apple's Published APIs and built-in interpreter(s). This is a shaky one. While drawterm does not itself run code, it allows you to connect to a computer that runs its own programs. But even if we did overcome all this... We have scribble, and rio is optional, so I don't think input is too much of a problem. A pain, yes, but not a problem. How about determining button 1, 2, 3? Triple-touch? You might get tired too easily.
Re: [9fans] request for more GSoC project suggestions
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 compilers. --dho at the risk of being called stupid twice in one day, i have to say i don't see what the payoff would be. doing something with gcc helps with gcc-specific code. what does llvm give us? llvm is really a lego kit for not only compiler construction, but also (as the name implies) VMs. Theoretically, it can do to Plan9 what dis did to inferno. Only on a much wider set of h/w platforms. Thanks, Roman.
Re: [9fans] GSOC: Drawterm for the iPhone
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 mirtchov...@gmail.com wrote: 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 an iPhone (the simulator is only somewhat sufficient). - barrier to entry: the iPhone development kit costs $99 (that's not the SDK, which is free) and puts you through a few too many hoops just to order a development token for your phone, then much more stuff to put it into the AppStore. it's not pretty. i don't want to turn anyone off from the idea: if anyone thinks it's worth it go for it.
Re: [9fans] GSOC: Drawterm for the iPhone
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 pietr...@mac.com wrote: 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 no t provide, unlock or enable a enable additional features or function ality through distribution mechanisms other than the App Store. drawterm may be used to gain access to a large repository of optional software (/n/sources/contrib, /n/sources/extra). An ill-informed lawyer may bring this up: 3.3.2 An Application may not itself install or launch other executable code by any means, including without limitation through the use of a plug-in architecture, calling other frameworks, other APIs or otherwise. No interpreted code may be downloaded and used in an Application except for code that is interpreted and run by Apple's Published APIs and built-in interpreter(s). This is a shaky one. While drawterm does not itself run code, it allows you to connect to a computer that runs its own programs. But even if we did overcome all this... We have scribble, and rio is optional, so I don't think input is too much of a problem. A pain, yes, but not a problem. How about determining button 1, 2, 3? Triple-touch? You might get tired too easily.
Re: [9fans] GSOC: Drawterm for the iPhone
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 pietr...@mac.com wrote: 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 no t provide, unlock or enable a enable additional features or function ality through distribution mechanisms other than the App Store. drawterm may be used to gain access to a large repository of optional software (/n/sources/contrib, /n/sources/extra). An ill-informed lawyer may bring this up: 3.3.2 An Application may not itself install or launch other executable code by any means, including without limitation through the use of a plug-in architecture, calling other frameworks, other APIs or otherwise. No interpreted code may be downloaded and used in an Application except for code that is interpreted and run by Apple's Published APIs and built-in interpreter(s). This is a shaky one. While drawterm does not itself run code, it allows you to connect to a computer that runs its own programs. But even if we did overcome all this... We have scribble, and rio is optional, so I don't think input is too much of a problem. A pain, yes, but not a problem. How about determining button 1, 2, 3? Triple-touch? You might get tired too easily.
Re: [9fans] GSOC: Drawterm for the iPhone
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'd second eric's suggestion of considering the Omero client using native widgets. you could do this with either (real) OS X or the iPhone, which makes it a bit more accessible. i'm not sure anything other than the inferno interface exists today, and it'd be a neat proof-of-concept, and a useful project using some of the existing skills you're talking about.
Re: [9fans] GSOC: Drawterm for the iPhone
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: Exitdrawterm Commands -- cpu% cat message this is a message cpu% cp message /mnt/term/whatever cpu% cat /mnt/term/whatever/message this is a message cpu% ftpfs -m/n/andlabs andlabs.com /dev/null cpu% cp message /n/andlabs -- (apple keyboard goes here) Hitting the Commands button would yield a menu to the likes of the rio Button 2 menu (cut, paste, snarf, plumb, send).
Re: [9fans] GSOC: Drawterm for the iPhone
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 pietr...@mac.com wrote: 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: Exitdrawterm Commands -- cpu% cat message this is a message cpu% cp message /mnt/term/whatever cpu% cat /mnt/term/whatever/message this is a message cpu% ftpfs -m/n/andlabs andlabs.com /dev/null cpu% cp message /n/andlabs -- (apple keyboard goes here) Hitting the Commands button would yield a menu to the likes of the rio Button 2 menu (cut, paste, snarf, plumb, send).
Re: [9fans] GSOC: Drawterm for the iPhone
On Wed, 25 Mar 2009 21:25:07 CDT Eric Van Hensbergen eri...@gmail.com 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 goes beyond cut-n-paste would go very well with a 3D graphics protocol. 9gl anyone?!
Re: [9fans] GSOC: Drawterm for the iPhone
On Wed, Mar 25, 2009 at 11:14 PM, Eric Van Hensbergen eri...@gmail.com 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 to control it sometime between leaving their work computer and arriving at their home computer. Not having this phone I couldn't care less whether drawterm is ported, but allowing others to make mobile interfaces for their stuff without needing a developer license and without having to learn anything outside the 9 universe doesn't sound like a bad deal. -- Tom Lieber http://AllTom.com/
Re: [9fans] GSOC: Drawterm for the iPhone
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 see more utilities that do similar things but over other transport means (http, sync utilities, etc) I think enabling the iPhone OS with 9p and a cache stored natively would be a significant benefit to future applications. And with the new APIs for copy/paste, a 9p based cache could be a great transport for data synchronization. -jas On Mar 25, 2009, at 10:14 PM, Eric Van Hensbergen wrote: I think rio is probably not useful, but a purely text based environtment isn't interesting either...
Re: [9fans] GSOC: Drawterm for the iPhone
iJuke ;-) On 25-Mar-09, at 8:24 PM, Tom Lieber wrote: On Wed, Mar 25, 2009 at 11:14 PM, Eric Van Hensbergen eri...@gmail.com 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 to control it sometime between leaving their work computer and arriving at their home computer. Not having this phone I couldn't care less whether drawterm is ported, but allowing others to make mobile interfaces for their stuff without needing a developer license and without having to learn anything outside the 9 universe doesn't sound like a bad deal. -- Tom Lieber http://AllTom.com/
Re: [9fans] GSOC: Drawterm for the iPhone
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 like something that very few people will use (the ones that have a cpu server and an iphone) in not that much often, of course it could be interesting to have it, but... I think that gsoc is a good chance to get going stuff that we need and we will really use. think of the openssh port, I did that, not for a gsoc and people use it, some guy even wrote a filesystem which suits lot's of people's needs. On Thu, Mar 26, 2009 at 12:20 AM, Bakul Shah bakul+pl...@bitblocks.com wrote: On Wed, 25 Mar 2009 21:25:07 CDT Eric Van Hensbergen eri...@gmail.com 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 goes beyond cut-n-paste would go very well with a 3D graphics protocol. 9gl anyone?! -- Federico G. Benavento
Re: [9fans] GSOC: Drawterm for the iPhone
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-Plan 9 kernel like everything else out there. The concepts aren't so different. the devices drawterm does provide are not essential parts of the kernel. the fact that drawterm exists is proof. - erik
Re: [9fans] request for more GSoC project suggestions
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 what point does indirection become misdirection? but writing a compiler is a small task in comparison to dealing with the platform. (writing drivers, dealing with memory, etc). how does llvm deal with that? if it doesn't, then inferno is superior by providing a virtual platform. - erik
