From zrscott at uchicago.edu Mon Oct 14 08:13:42 2002 From: zrscott at uchicago.edu (Ziba Scott) Date: Thu May 18 12:41:34 2006 Subject: [Cs22800] Proposal: e17 taskbar framework Message-ID: <3DAAC306.8040809@uchicago.edu> Proposal: Enlightenment 0.17 taskbar framework. The 0.17 version of Enlightenment marks its transition from being a window manager to a desktop manager. Two essential components of a desktop manager that are absent from "e16" are the iconbar and the taskbar. E17 has a functional iconbar, but no taskbar. A search of the developers' mailing list shows that a taskbar is a desired component but any implementation has not been discussed since march of this year. E16 is clearly an underdog in the world of linux desktops, however, it has retained popularity because of its extreme versatility and speed due to its relative simplicity. Not only does e17 plan greater functionality, but it has an impressive canvas engine called evas. Evas is a layer of abstraction between applications and X11 that enables speed and visual effects that can rival any desktop on any system. In addition Evas can take advantage of hardware rendering devices. Much of the speed and flexabiliy of e17 is derived from its layers of abstraction for dealing with text and images, therefore we propose to make a layer of abstraction which will make the creation of any number of different taskbars very simple. To test our layer we will create a sample taskbar. The gnome and kde taskbars can serve as examples, but not neccesarily finished models of what our layer will be capable of. Ideally, our layer would enable the creation of a taskbar that could possess every feature used in any taskbar in use and beyond. The challenges we forsee at this stage are choosing a point in the e17 project where this code should be encoded, utilizing existing abstraction layers efficiently, and ensuring modularity. For example, we will have to use the "Ecore" layer for window tracking, the "Etox" layer to handle text, and the "Ebits" layer for decoration. Ziba Scott Stephen Dranger From odonnell at cs.uchicago.edu Sun Oct 20 14:26:02 2002 From: odonnell at cs.uchicago.edu (Mike O'Donnell) Date: Thu May 18 12:41:34 2006 Subject: [Cs22800] Robustness of BSD Sebek port, methods for covert transmission Message-ID: <20021020192607.8B4BD8080A1@surya.cs.uchicago.edu> For Ben's project porting Sebek to BSD, I find the proposal nice and clear and sensible, and the Web presentation very helpful. I encourage you others to work on nice presentations, and in particular to think about running your own project diary. Robustness of BSD Sebek port ---------------------------- Regarding the port, I hope we can get into one more layer of detail soon. In particular, I wonder how robust the port can be w.r.t. further changes to Sebek. Will Ben, or his successor, need to do additional configuration work for each such change? Or, can we provide patches to the core Sebek group so that they can produce a distribution that compiles automatically to BSD as well as Linux. The answer depends to some degree on how the core Sebek project is organized. Have they used the autoconf/automake/libtool types of tools, and if so, how well? I've done a bit of this, and it seems like a horrible black art. The individual pieces of documentation for make, autoconf, automake, libtool are hard to integrate into an understanding of the whole task. Somewhere in the Gnome project's Web space I found a pretty good how-to for the whole thing, at least in one reasonably workable style. I expect that, no matter how well autoconfiscated the package is, from time to time the Sebek core will exercise some new aspect of the Linux kernel that has to be translated to BSD form. But the number of such incidents could probably be cut by a factor of 5 or so with good organization. Covert transmission ------------------- This isn't Ben's chosen topic, but we might as well think about the whole Sebek project a bit. In the note from Ed that Ben posted on 28 September, there's a lot of influence on the problem of dumping Sebek's data to another host across a LAN without arousing the intruder's suspicions. That sounds inherently difficult to me. Is it feasible, instead, to use a separate network connection for dumping Sebek data? This could be a separate ethernet, or just a parallel port or a serial port, or maybe a USB. It looks to me like the big question is how well can you hide such a port and its activity from the intruder. In principle, it sounds very feasible. Take the device driver code, and hide it in a file somewhere, and invoke it directly instead of using the usual /dev interface. If this works, in principle you might even write to a covert disk, or better a write-once device. But there might be snags in the details. And the attempt to have a covert peripheral device might run afoul of attempts to make device detection and configuration automatic---maybe a modern BIOS will even interfere. Anybody know any more about the reasons for sticking to the regular network connection, which the intruder can easily sniff? Or perhaps somebody can find this in the Sebek mailing list archives. Mike O'D. From odonnell at cs.uchicago.edu Sun Oct 20 14:34:54 2002 From: odonnell at cs.uchicago.edu (Mike O'Donnell) Date: Thu May 18 12:41:34 2006 Subject: [Cs22800] Next level of detail on Enlightenment's abstraction barriers? Message-ID: <20021020193459.5CDAF8080A1@surya.cs.uchicago.edu> For Ziba's and Stephen's Enlightenment taskbar project, I think that a next strategic step could be to give us one more layer of detail about the Ecore and Etox and Ebits abstractions, so we can think about how efficiently they can support the needs of a taskbar. Presumably they are supporting application windows pretty well already. It seems likely that a taskbar's graphical presentation needs are similar enough. But how about its needs to get information about other applications and about the windowing/desktop environment as a whole? These might not arise in most applications, but perhaps a file manager has already dealt with some of them. Also, please add some sort of time scale to each project writeup. First priority: make it clear whether you want to finish something creditable during fall quarter, or whether you'll take credit in a later quarter. Then, try to break out a few milestones along the way so we can tell when things are getting late and need to be revised. Mike O'D. From odonnell at cs.uchicago.edu Sun Oct 20 14:39:00 2002 From: odonnell at cs.uchicago.edu (Mike O'Donnell) Date: Thu May 18 12:41:34 2006 Subject: [Cs22800] Next layer of detail on "warning squelching" Message-ID: <20021020193906.161088080A1@surya.cs.uchicago.edu> Wesley, Can you plug in the next layer of detail on "warning squelching." Is this something that is now supported, but not totally satisfactorily? If so, how is it done now, and what are the shortcomings. If not, how about a brief definition of the problem, and an indication of where a solution is most likely to fit (I'm thinking this goes into the macropreprocessor, but I'm not sure). Why not post the statement from the GCC task list for starters? Mike O'D. From bsjohnso at midway.uchicago.edu Sun Oct 20 18:32:42 2002 From: bsjohnso at midway.uchicago.edu (Benjamin Johnson) Date: Thu May 18 12:41:34 2006 Subject: [Cs22800] The Web Message-ID: <1035156764.896.8.camel@razorbsd.razor.net> All, Sorry about my late reply but my DSL connection has been down for a while today. Anyways, I'm going to add the e-mail addresses of everyone to the list. Also, I find it nice to make a webpage for the project with all the details. Obviously its not required thus far, but I think professor o'donnell would prefer to have each of us setup a page with notes of our progress readily available. I will speak about my project tomorrow. It will be more background then real technical stuff but I'll let you know about where I'm at, what problems / difficulties I ran into today and about where I'm going with it. As for my project: Currently I am just porting over the kernel module. It is not real easy since enough things are different to make it more time consuming than just changing a few simple system call numbers. The one beacon of light I have is that I was sent adorebsd by one of the honeynet members. Sebek, the linux version, is based upon adore for linux. Therefore me having adorebsd is a wonderful thing. However, the way some of the kernel programming is will require me to learn a lot about freebsd and bsd kernel stuff...it shouldn't be very bad, I just have to do some research and read some header files. Since writing a device driver adds complexity, right now I am simply trying to capture keystrokes, timestamp them and print them out. Once this has been accomplished (hopefully soon) I can work on the device driver...and at the same time contemplate whether or not there is an easier / better way to do the covert driver stuff. Since sebek is supposed to be for anyone wanting to setup a honeynet / honeypot, it may not be the best to have serial or parallel links because that may add some configuration issues depending on their hardware...maybe not though. As for the other parts of Sebek, they seem to be easier to port since its straight user applications...I believe I just need to change a few header files around. I'm still working on this for a while tonight, so maybe I'll make some progress. I'll update you guys tomorrow. See ya, Ben From stdrange at uchicago.edu Sun Oct 20 23:00:04 2002 From: stdrange at uchicago.edu (Stephen Dranger) Date: Thu May 18 12:41:34 2006 Subject: [Cs22800] E17 correspondence digest Message-ID: <3DB37BC4.9080303@uchicago.edu> Here's a digest of our correspondence with various people involved in the project: --------------------- Our first e-mail to Rasterman (e17 project founder) and his response: Carsten Haitzler (The Rasterman) wrote: Greetings, > > I am a 4th-year student at the University of Chicago and am > participating in a class called "Free Software Practicum." The goal of > this course is to work on a project related to free software and have it > become a part of the community. It is being supervised by Michael > O'Donnell (odonnell@cs.uchicago.edu), a faculty here in the Computer > Science division. Ziba Scott (zrscott@uchicago.edu) and myself are > currently looking for a project to work on for this course, and > Enlightenment looks very interesting. We are looking for a project > dealing with visual elements: openGL, GUI, etc., and both are quite > interested in working on Enlightenment. We have the resources of the CS > department available as well as the other students in the course. The > course lasts for 10 weeks, although if necessary we can extend the > project beyond this quarter. Could you give us information on projects > for Enlightenment that might be suitable for this project? Ok (funny - I find myself in chicago airport at the moment...). Been busy. Had project deadline October 4 for work then I was in Tokyo for a week of business meetings, and I barely can come back and catch up and now find myself in Illinois speaking @ Reflections | Projections in Champaign. Anyway. I'm catching up on my mail now. Well starting. You may have noticed E17's source itself hasn't advanced much for many months. That's because all the work is going into: 1. separating out core functionality that may be useful elsewhere and turning it into libraries. 2. working on these libraries so they are fully fledged, clean and complete. and so no work is being done on E 0.17 itself. I have earmarked a bunch of things to be done, but that will likely see very little in terms of visible and usable results in a WM, BUT will build the basis for making it very easy to do so. 1. Evas. I'm talking about this today @ Reflections | Projections. I've been busy rewriting the internals and cleaning up the API. It's almost all complete now, just minus documentation. 2. Ecore. This needs a cleanup. Primarily API-related. It's not really a consistent API and misses some features. But it is useful and saves a lot of work by wrapping X calls and making them simpler to use. 3. Ebits. This needs a rewrite. I've written a library specifically to help do this: Eet. This lib is basically complete for our needs. Ebits needs a complete overhaul and rewrite and re-think. I've termed this Ebits2. 4. Eet. This library handles: File reading/writing for multiple data elements in one file. Compression of data elements in a file Saving and loading of image data to and from these eet files. Serialising and de-serialising of data structures for saving and loading and for transferring across the wire. 5. EWL. The E widget layer. This after recent discussion seems to be maybe merging with Ebits2 and might both be spun off on their own project together. 6. Efsd. The E filing system daemon. This is basically complete and does its job, but could do with using DNOTIFY in linux 2.4 and up instead of requiring FAM. This will be the basis for file management under E 0.17 and beyond. 7. E itself. This has been split too: E the WM. The window manager for window management and the central point of communication. E the desktop. This is the desktop manager and handles your desktop(s) background and any activity on it on each virtual desktop. Epplets. This would be small applications that live on the desktop or in small windows around the screen to do useful things. E taskbars/panel. This would do... what it says. Nothing has been done on design etc. here yet. The problem with a lot of work on E itself is that it would be better to fix the base subsystems and libraries first, and perhaps turn a lot of even E itself into shared libraries - for example put into ecore so apps can set hints/properties the same way through easy to use API calls etc. Anyway. give you any ideas? --------------------------------- Our post to E 17 developer's list: From: Ziba Scott * e17 taskbar framework* 2002-10-17 13:48 Hello, Stephen Dranger and I (Ziba Scott) are fourth-year undergrads taking part in a Computer Science class at the University of Chicago. The goal of the class is to develop free software for the Linux community. We would like very much to contribute to the development of e17. A survey of the HEAD and SPLIT cvs code, as well as of the developers list has lead us to believe that a taskbar is both desirable and not actively being worked on. Discussions from last March seemed to be mired in stylistic debate. In an earlier posting, Rasterman informed a hopeful taskbar creator that "e17 doesn't make it easy" and "ecore has the nuts and bolts - but right now e17 doesn't advertise info to make it easy for you." Therefore, we would like to begin work NOT primarily on a taskbar, but on preparing e17 so that the creation of any number of stylistically varied taskbars would be almost trivial. In otherwords, to see that e17 DOES make it easy for hopeful taskbar creators by using the modularity that e17 provides. We would be vary grateful for responses to our proposed project concerning its value to e17 or other general suggestions. Apologies to any e17 developers whose toes we may be unwittingly stepping on. Ziba Scott zrscott@uc... Stephen Dranger stdrange@uc... ----------------------------- A response from Ibukun Olumuyiwa [ahem] Do we really want a taskbar for E17 at all? I don't have any ideas at the moment, but I'm thinking there might be more creative alternatives that do not take up valuable screen estate (we already have the iconbar). -- | /*\ Ibukun Olumuyiwa | \ / Join the ASCII Ribbon Campaign http://www.xcomputerman.com | X against HTML mail today! | / \ ------------------------- From bsjohnso at midway.uchicago.edu Sun Oct 20 23:36:56 2002 From: bsjohnso at midway.uchicago.edu (Benjamin Johnson) Date: Thu May 18 12:41:34 2006 Subject: [Cs22800] Update Message-ID: <1035175017.420.5.camel@razorbsd.razor.net> I'm having a bit of trouble trying to get tty hijacking working in freebsd. In other words, I am a little stumped on how to intercept write system calls, determine that they're going to the tty (such as for keystrokes) and then save a copy of them in some kernel buffer (or eventually send it to a driver). I have successfully written a driver called /dev/echo...here's a sample of it: razorbsd# printf "Hello cs228\n" > /dev/echo razorbsd# cat /dev/echo Hello cs228 razorbsd# So you can see that once I get the module working, I can easily set up /dev/sebek for reading from a helper application... I actually didn't do much work on the device module, I just spent a while browsing through sample code and what not. The most coding I am doing is for the tty hijacking...unfortunately any segfault or problem you would get in a user-space program results in a machine REBOOT when working in the kernel...and then it must recheck the disks...so I have to be careful...I'm working on setting up VMware in FreeBSD but it is a little more complicated since it was written for Windows & Linux only... See ya tomorrow... Ben