OK, just to be clear — I do see your point of view, and I think you'd find a lot of people that agree with you, but I wonder if that's more to do with what people are used to, rather than an objective view of usability?

Consider a launch menu (e.g. K Menu, Windows Start menu, etc...) What's it for? It's an abstraction — it shows a customisable view of the user's applications. It's necessary because the applications themselves are all over the system and can't be moved. The user may launch Firefox, for example, by going to Menu->Internet->Firefox, but that's just a link, not the real thing. Why is that necessary? It adds complexity, confuses the user, and gives the user more to worry about and organise. RISC OS, for instance, never had a system menu, and neither does MacOS X.

Instead, now that we've managed to get programs into logical directories, why not allow the user to organise his applications directly, just as he's used to organising his documents? If he wants to launch Firefox, he can open Konqueror (or Dolphin), go to /Applications/Internet and double-click on Firefox. What's more, he can remove Firefox in the same way, and install programs in the same way. This is especially good for Memorability, because once the user knows how to manipulate files, he can manipulate programs. You don't want to have to open a file manager? Place a link to /Applications in the system bar and set it up so that when you click on it you get a menu representing the /Applications hierarchy. I've done a similar thing in Windows.

OK, so I'm using the GUI as an example, but the CLI is currently suffering even more. All programs are always on the path. There's not even an abstraction layer for the user to organise. I won't go into that now though.

Posted By: shevegenI think what you seem to propose is a system that does not care about where something is installed at (physically), and it will be using logical "classifiers" instead (in your example "Internet" which can be found under "Applications") It reminds me a bit - as idea - about the usage of a database instead of a file system (which would make queries easier because you only have to ask the database and can view this model in any way you want... reminds me of the MVC pattern ;-) )

Yes, I think the idea of using a database is a very good one, (as mentioned in the article I linked to at the top of the thread). It opens up all kinds of possibilities.

However, my main point is that it shouldn't matter if Firefox is in /Applications or /Applications/Internet or /Users/Joe/Downloads; it should still be possible to run it directly from that location, both from the GUI and the command line, and it should be possible to move the latest Firefox from /User/Joe/Downloads into /Applications/Internet once Joe has run it to make sure it works... That kind of thing.

Anyway, this logical abstraction in general is a rather good idea.

Forgive me if you're just using the term losely — I think it would not be a good idea to create a futher abstraction (e.g. "fooling" Konqueror into thinking /Applications/Internet is there when it's not). I think we should make these changes at the lowest, physical level. Forgive me if that's not what you meant; I just wanted to make sure.

Just for clarification though - I detest being forced to *only* double click on something to launch/start it. I am too much in love with konsole these days ... :-)

I agree. Generally when thinking about this, I think first about how things will work from the console, and ideas for the GUI tend to present themselves from there.

However I think you have to untie this idea from the "bundled download" approach because this seems to ask for a lot of extra work, and Gobolinux at times really lacks... manpower :-)

If you look at the mailing lists, and on some other sites, one big concern is the management of the recipes and so on, because it is a lot of work (currently at least)

I think there are ways that this could be fixed. For starters, I think ChrootCompile should be made the primary means to compile a program, and the user should be prompted whether or not he wants to contribute his successful Recipe and Package after a successful compilation.

Posted By: Michael

Posted By: MohjiveThat way you'll only have duplication when downloading.

You say that like it's a good thing.

Well, I don't see any problem with adding a few KB to the download, if that saves one from downloading even bigger dependencies, which one might not be aware of is needed at the time of download.

Posted By: giddieI agree — I think at least in the main store packages should not have dependencies bundled. However, I think it should be possible to package several programs together so that they can de distributed that way if need be. More than that, I think that packaging a program shouldliterallybe a simple as zipping the program directory — no script involved.

What's the difference between bundling some dependency libraries and bundling whole dependency applications? Basic packages would still be created as just a tarball, but one could make extended packages, which bundles some libraries the application is dependent on, with a script.

Posted By: giddieIf he wants to launch Firefox, he can open Konqueror (or Dolphin), go to /Applications/Internet and double-click on Firefox

There are packages with more than one binary. How would that be handled?

Posted By: giddieI think ChrootCompile should be made the primary means to compile a program, and the user should be prompted whether or not he wants to contribute his successful Recipe and Package after a successful compilation.

The problem with only using ChrootCompile is that *only* the features depenent on the applications listed in the Dependencies file will be built. Say that you want to build shadow with PAM support but, as we currently doesn't support PAM, PAM is not listed as a dependency and then you have to edit the Dependencies file to include it. With regular Compile, if you have PAM installed all you have to do is pass the '--configure-options "--with-pam"' to Compile.
As for automatically submitting recipes, I'm working on that.

Yes, useflags (or comparable function) would make ChrootCompile feasable as a default compilation mechanism.

It's not net savings compared to basic packages, but to package bundles. And my idea is just those that have a slow, or no, internet connection. Then you can download the package off-site and still be able to install it even though your system doesn't have the dependencies installed. So only one package is needed, instead of downloading the package for the application you need *and* all the packages for its dependencies (which you might not know which they are) or a package bundle with all this in one tarball.

Posted By: MohjiveWhat's the difference between bundling some dependency libraries and bundling whole dependency applications? Basic packages would still be created as just a tarball, but one could make extended packages, which bundles some libraries the application is dependent on, with a script.

What I'm saying is that I think packages in the main GoboLinux store should contain only one program each, to keep things simple. I think that ideally, the command line tool should create a dependency tree before the package is downloaded, ask the user which ones he wants to download, download them all at once, then install them all. I also think that if someone wants to zip up two applications together, that should be no different to doing it with just one. I don't like the idea of a package having a special format.

If he wants to launch Firefox, he can open Konqueror (or Dolphin), go to /Applications/Internet and double-click on Firefox

There are packages with more than one binary. How would that be handled?

Exactly the same way GoboLinux currently deals with it — have them all on the path. I'm not suggesting anything hugely radical here. This just involves the ability to specify a default binary for an application.

The problem with only using ChrootCompile is that *only* the features depenent on the applications listed in the Dependencies file will be built.

That's a fair point. To be honest, my main concern is that it should be possible for users to compile a program in their home directory and end up with an application, still in their home directory, that they can then do what they want with.

Posted By: Michael

Consider a launch menu (e.g. K Menu, Windows Start menu, etc...) What's it for? It's an abstraction — it shows a customisable view of the user's applications.

Yes. That's a good thing. You can have multiple ways of accessing programs, to go with different ways of thinking about what you're doing at the time, or different locations. Mac OS does have shortcuts now, and also the dock.

Maybe I'm misunderstanding, but it feels as though you didn't read all the way through my paragraph there. Yes, it's very important for users to be able to customise their view of the applications on their system. My argument was that using shortcuts and launchers is a bad way to do it, and that allowing the user to structure the /Applications folder would be a more elegant (and user-friendly) solution. I think the use of shortcuts should be avoided because they're ambiguous, but until we see full-on database filesystems replacing our current hierarchical models, there are always going to be one or two situations in which they're required (e.g. the Dock and a Favourites-type system).

he can open Konqueror (or Dolphin)

And if he wants to open Konqueror, he...

No desktop operating system can operate without a filesystem viewer. As far as I can tell, it will always be a fundamental part of an OS in one way or another. For the CLI, ls and friends will always be on the path, and in the GUI, Konqueror will always reside on the bar. I think you could have guessed my answer to this question though.

Posted By: giddieExactly the same way GoboLinux currently deals with it — have them all on the path. I'm not suggesting anything hugely radical here. This just involves the ability to specify a default binary for an application.

But then how do you access the others? Say, OpenOffice, which has seven, all of which are individually useful.

Posted By: giddieMy argument was that using shortcuts and launchers is a bad way to do it, and that allowing the user to structure the /Applications folder would be a more elegant (and user-friendly) solution.

And mine was the opposite.

Posted by: giddieI think the use of shortcuts should be avoided because they're ambiguous

How so? Because deleting them doesn't uninstall the program? You're also able to have multiple shortcuts to the same thing if you want, which can be useful (and would be especially useful with things laid out how you're planning). So since you're going to have to have them anyway at the DE level, there's really no reason to move the programs around at all.

Posted by: giddieNo desktop operating system can operate without a filesystem viewer. As far as I can tell, it will always be a fundamental part of an OS in one way or another.

I'm pretty sure I don't have one here, so that's just not true.

Posted By: giddieKonqueror will always reside on the bar.

That seems an odd constraint. I also don't think it's a usability improvement to have to open several windows with active clicks to get to an application. It's exceptionally annoying having to do that on OS X. That part is an interface question, though, so we'll leave it out. It's perfectly possible to map the filesystem to a menu, like you say.

Posted By: giddieOK, for starters, how do you find a small tool for converting graphics files that you know you installed a while back, but you just forgot the name of? Please carefully consider my suggestion here before dismissing it. The problem with the path is that it is pretty much impossible to search, and the human mind is bad at recalling, but good at recognising. If you do `ls /bin`, you'll have a hard time sifting through all of it. GoboLinux has almost solved it, since we can do `ls /Programs`, but that can still get quite hairy to search through. I'm still routing for `ls /Applications/Tools/Graphics` to find that program, or `ls /System/Programs/Tools/Graphics` if it's shared by a lot of programs.

You can organise things that way now (with symlinks, and just as easily as moving them in Konqueror, I think). Or even better, when the program created a categorised menu shortcut for itself. I just don't think this is a useful enough or common enough scenario to be worth any trouble, certainly not the trouble that this would involve. But I can see that this is a case where it would be useful to organise them this way if it came up.

Posted By: giddieFinally, I also wanted to clarify that I'm not suggesting we make directories executable. No more so than they currently are in GoboLinux. What I'm suggesting is a different way to merge them into the system, which apparently is pretty much already on the cards. Beyond that, my ideas involve a few modifications here and there to Scripts for the CLI and KDE for the GUI.

You're going to have to patch the shells to make it work from the command line, or else just ignore it. And you're limiting the use of the system to KDE only, which is not an option. From that perspective this is a no-go from the start. Of course it wouldn't actually be necessary to use it that way, and leaving them all in /Programs would make things function mostly as they do now.

(continued below; comment was 832 characters too long, apparently)

Quite a discussion you have there, ppl :)
I won't go into details - it's far beyond my expertise for now, but I'd rather agree with Michael's arguments on this one.
The way giddie proposes to do it is quite interesting, no denying here, but at the same time it feels strangely alien to me. It's the kind of simplicity that complicates things even further, not to mention extendability. For starters - I think that shortcuts are a good thing and a huge improvement from running binaries directly. This way, the ignorant user is less likely to harm some applications, as they reside hidden to him and he deals with abstractions only. I say this, because I saw this behavior way to often when some secretary accidentally deletes a shortcut for her favorite Zuma-game on a Windows desktop and then runs to me (I was a local admin) screaming for help...
Again, in Windows environment (I still don't know it is handled on Linux, besides the obvious command-line) you can use the shortcut to run a program with specific arguments. I had to use this to run Battlefield 2 with specific resolution that in-game setup didn't allow. To do the same without a configurable shortcut would be much more user-puzzling.
It might be different on Linux desktops, but I still think that shortcuts are there for a reason and should stay that way). Just my 2 cents...

Actually, I tend to be more on giddie's side of things but not so much because of the GUIishness, but moreso because I love the basic "logical" assignment onto it. ;)

But first things first. On IRC, someone said that he liked to have "one app, one dir" (under /Programs). I somewhat myself violate this a bit...
I even have a /Programs/Games folder, and i throw all of Xfce into one dir too...).
I think the "one app, one dir" approach is a lot cleaner than my idea here.
I even started to wonder if I should do /Programs/Editors, but you can easily see where this leads to - way too chaotic to split
them all up physically Thats why i fell in love with /System/Index ideas quickly (although maybe i still dont understand
it completely:)

Anyay, my approach to split up on /Programs would be too complicated.
And what about stuff like Openoffice, or other apps? Emacs isnt only an Editor, its a religion and an
Operating system too (ok ok i am kidding here, but I hope you can see the problem with my approach. Its adding too much
complexity for only a very little gain).

The /Applications approach per se is NOT bad though. I explain soon why I think (even though giddie and I probably dont
share the same opinion) this way

Ultimately, I think the problem is we're looking at this from the perspective of different paradigms. You're very much seeing it from the perspective of a high-level single-user GUI, and I'm not

Although it was meant to giddie, I must point out that this level of abstraction is not tied only to GUI!
Just think of a shell which is aware of this layout. Lets assume we have a shell that can handle this

The user would not necessarily "type" gimp to start gimp or similar. He could "call" on to
something like:
Application.Image

which could launch gimp (depends on if the user has made it the default application)

Ok, I grant you, via a graphical solution this might be a lot easier (just click on it),
and that a user that uses a shell will use "gimp" instead on the shell (which is much
faster too than to type something like Applications Image or similar , even if you
would alias things, its still more typing than just "gimp").

But what I like about the basic idea behind is, is that I do not have to type the
name of the program, but instead specify an action I want to do with it.
Or I kinda tell my computer "computer, I want a fully featured word processor
now" (and openoffice would be started)

Okok, a simple click on a menu is a lot easier yeah. And before I walk
further on all the problems on it, let me say that I still like the logical
separation of it, even if in practice it is not so good. (maybe) :)

It's the kind of simplicity that complicates things even further, not to mention extendability.

I think if i could tell a shell to do something like
"Image my_image.png to_greyscale"
and it would just convert this image to greyscale, this would be really nice.
Or if i could do something like
"Video foobar.vob to_avi"
and it would convert it to an .avi file without me specifying anything
else (default could be to certain settings which an "average" user would want,
and could be overriden somewhere too)

Where in these situations, I wouldnt need to know which application does
this job. I could stay "dumb" and just want my OS/apps to deal
with this, and work with the net result...

Or

"Play all mp3"

I guess you see what I mean :)

Yes, this is probably not what giddie meant, but this is somewhat
what I would like to see... but anyway, I think while this all
might look neat, it probably means quite some work, and
I just want rc2 ... :D

"because I saw this behavior way to often when some secretary accidentally
deletes a shortcut for her favorite Zuma-game on a Windows desktop and then
runs to me (I was a local admin) screaming for help..."

Agreed fully there!
There is always a little trade off... GUI help a lot except if you do something
which you dont know how to resolve... maybe windows should keep central
"undo" actions for its GUI :D


By the way, In Konqueror, you can extend Konqueror with servlets. They are quite
cool too, but I think if you add too many options to it, then it can be complicated to
find the option you want to have or apply (i have 8 servlets so far, and
they can be a little bit annoying if i havent used them in a long time) ...

Aso, just try a right click on konqueror, or on windows, its not that good a
solution IMHO. (On windows i dont even know how to
disable the stuff i never use in those context menus... )
Not to forget mentioning that this image conversions could lead
to even more long context-menu lists (or maybe it would encourage
a user to play around with it? I dont know...)

hmm, why not toss the idea of apps out the window?

remove the k menu from the bar, and have people operate on a files and actions basis?

and then create a install system that can install stuff based on what file types and actions a person wants to perform?

kinda like how in konqueror right now one can rightclick on a file or dir and select actions from the menu, but extend this to the n-th degree?

Posted By: vazubI think that shortcuts are a good thing and a huge improvement from running binaries directly. This way, the ignorant user is less likely to harm some applications, as they reside hidden to him and he deals with abstractions only. I say this, because I saw this behavior way to often when some secretary accidentally deletes a shortcut for her favorite Zuma-game on a Windows desktop and then runs to me (I was a local admin) screaming for help...

I can see that this could be a problem, but consider the system I suggested — if the game was installed in /Applications/Games, she wouldn't have write access, so she couldn't delete it accidentally. If she'd downloaded it and was running it from her home directory, she would know where it came from, how it got there, and probably be a little more careful not to delete it. Shortcuts are without a doubt useful in hierarchical filesystems, but I maintain that they are dangerous, because they promote disorganisation and confusion to the average user. Also, try to introduce the concept of a shortcut to a computer illiterate person. It's a weird idea unless you're used to it, and that's a bad sign.

Again, in Windows environment (I still don't know it is handled on Linux, besides the obvious command-line) you can use the shortcut to run a program with specific arguments.

That's a very valid argument. I do this every day for work. I think I'd personally prefer to introduce the concept of a "launcher" (basically a script), rather than calling that functionality a "shortcut" or "link". Alternatively, we could have a "launch with special options" selection in the filer. For the latter, it may be possible to create some standard file in the program directory, so that a widget could be shown with a few of the most useful available command-line switches in graphical form.

The CLI already has a good way of dealing with this (program --help). I find it quite interesting that the CLI is currently easier to use than the GUI for this task.

Posted By: tsohmm, why not toss the idea of apps out the window?
remove the k menu from the bar, and have people operate on a files and actions basis?
and then create a install system that can install stuff based on what file types and actions a person wants to perform?
kinda like how in konqueror right now one can rightclick on a file or dir and select actions from the menu, but extend this to the n-th degree?

That's an interesting idea, and I particularly agree about removing the K menu. I don't think you can completely get rid of the idea of applications (if that's what you mean), because at the end of the day, you have to be able to install and remove software when you want to. MacOS X does what I think you mean. An application in MacOS X will not be unloaded when its last window is closed. It remains in memory until the system decides to close it. (You can see this visually because of an indicator on the Dock.) That's because MacOS X is not Application-centric like Linux or Windows. It's Document-centric. That is, you're encouraged to think about applying actions to files using applications, rather than using files to store your application's progress. You don't get full-screen applications like in Windows or Linux for this reason.

Posted By: giddie

Posted By: MichaelBut then how do you access the others? Say, OpenOffice, which has seven, all of which are individually useful.

Now that's quite a constructive question. I guess we can have a file in the program folder, like the Dependencies file, listing some actions that can be performed with the application. That can be mapped onto a menu in the GUI, or listed on the CLI.

I'm shuddering on the inside here. I think the only way to make it work reasonably would be to mandate that programs contain exactly one executable, and have separate OpenOffice.org Writer, Calc, ... programs. That's perfectly doable, of course.

Posted By: giddieHow do you organise files? Maybe we have a different idea of a filesystem viewer here. I would considerls,cp,mvand friends a filesystem viewer. Is that what you're talking about? If we're still talking about GUIs, there's no way you're going to do anything useful without a view of your files...

You're right, I wasn't thinking of them as filesystem viewers, because they're not in the same sense that Konqueror is (they don't include the "activate" action). But no, I don't have a GUI filesystem viewer on my home computer.

Posted By: giddieThe way I look at it, making applications relocatable promotes system modularity, which makes a multi-user system easier to manage.

I think it makes things a mess. There are also some performance issues, yes, but they're not compulsory so it doesn't bother me that much.

I would actually be on board with a system like I described earlier, with a set of Programs directories that were union-mounted together. That serves a good purpose (splitting /Programs across filesystems, and having user-specific /Programs), and as a side effect it would let you do (most of) your crazy scheme here. It will also be possible in the future to create environments containing only a specified set of programs, and other items (it's perfectly possible now, actually, but it will be more possible and easier). It probably won't be possible to create one after the fact, but creating one and running a program in it would be.

Posted By: giddieWhat's wrong with the metaphor here?

$ cp Firefox.tar.bz2 /Applications
$ MergeApp /Applications/Firefox.tar.bz2
$ firefox

That's a pretty horrible interface, to begin with. Why do I have to take two steps to run something? And remember some godawful pathname? I don't think that's good usability. It's a good situation to have magic behaviour, really; "Run Firefox" and it finds the program, merges it, and runs the single binary it contains. But the metaphorical problem is in treating a file as multiple things at once, as well as the "copy" operation. From a drag-and-drop perspective it works perfectly; I'm really not sure why it doesn't gel at this level. From the CLI an "install" operation or similar seems to make more sense, maybe because at that level you're more aware of it as a file?

Posted By: giddieThermquestion is a good one, which I was aware of. I'm hoping that it can be solved with FUSE. The superuser considerations are also valid. I'll be honest here and say that I haven't thought far enough ahead to have a solution to this. I'm sure there must be one though.

The rm one probably can't (you can't detect a directory's being deleted until after its contents have been), but it might be possible to work around it with suitable guesswork (find all the links/references/etc that point there once it's been deleted and remove them). Actually, what happens if you delete a program that's been merged into another chrooted environment? It seems like that would cause problems.

I don't have any ideas on how to work around the superuser part.

Posted By: giddieThe problem is that the PATH namespace is getting large. Unless we introduce some modularity, we'll end up with name clashes. What happens if someone ignorantly decides to create some random app called Dolphin? You can't have two executables named "dolphin" on the path.

Ok, I can see the theoretical problem there. I'm not sure it's really such a practical one (the only case I can think of where that's happened is mkpasswd). But it is a good point all the same; wanting to use multiple versions of the same program causes the same issue. It certainly will be possible to run an application in a restricted environment if you want to, probably including your DE (but you'd be stuck with what you started with then, I think).

Posted By: MohjiveFor launcher/desktop/files/environment I have only one reply: Rox Desktop already does this afaik.

Yes, but it really only deals with a few GUI issues. I think the ROX system kind of breaks down when you move to the CLI doesn't it? Maybe I'm wrong.

Posted By: Michael

But then how do you access the others? Say, OpenOffice, which has seven, all of which are individually useful.

Now that's quite a constructive question. I guess we can have a file in the program folder, like the Dependencies file, listing some actions that can be performed with the application. That can be mapped onto a menu in the GUI, or listed on the CLI.

I'm shuddering on the inside here. I think the only way to make it work reasonably would be to mandate that programs contain exactly one executable, and have separate OpenOffice.org Writer, Calc, ... programs. That's perfectly doable, of course.

Why? I'm sorry, I simply don't see how you came to that conclusion from what I said. I guess I must have been unclear. I'm not suggesting anything different from what GoboLinux already does — all the executables are in the program folder. The only new idea I'm suggesting here is an extra file in Resources that lists the executables so that there's the option of presenting the user with a choice. It just means that the user has the choice of /Applications/OpenOffice/bin/swriter and RunApp /Applications/OpenOffice. The latter will present the user with a list of options and ask him which he wants to run. The GUI would use the file to present the user with the same options when he double-clicks on the application directory.

The way I look at it, making applications relocatable promotes system modularity, which makes a multi-user system easier to manage.

I think it makes things a mess. There are also some performance issues, yes, but they're not compulsory so it doesn't bother me that much.

I needed to install Firefox 3 on a Mac earlier today, to test an extension I had built on a Windows machine. Installing Firefox 3 on the Mac involved downloading the dmg file and double-clicking on Minefield. The application was still in its compressed image, sitting on my desktop. I tried out my extension, quit Firefox, and deleted the dmg file. Job done. Not only is that incredibly easy, but I never had to install Firefox 3 globally, which is also cleaner from a multi-user point of view. If I was going to keep Firefox 3, I'd put it in my home directory or the /Applications folder (if I had access). How is that messy? It provides a simple, clean way for the user to take control of his system and organise it. It won't break when he changes something and it doesn't force him to organise everything the way the system's developers wanted to. The user is free.

Posted By: giddieWhy? I'm sorry, I simply don't see how you came to that conclusion from what I said. I guess I must have been unclear. I'm not suggesting anything different from what GoboLinux already does — all the executables are in the program folder. The only new idea I'm suggesting here is an extra file in Resources that lists the executables so that there's the option of presenting the user with a choice. It just means that the user has the choice of/Applications/OpenOffice/bin/swriterandRunApp /Applications/OpenOffice. The latter will present the user with a list of options and ask him which he wants to run. The GUI would use the file to present the user with the same options when he double-clicks on the application directory.

I know what you're suggesting, I was just shuddering at the idea of having to access them that way. Packaging them up as OpenOffice-{Writer, Calc, Base, Impress, ...} would be preferable to adding yet another interface to access them.

Being realistic here, none of this is going to happen, except the parts Mohjive and I have already mentioned and what's in the linked list message. Freely relocatable applications might be doable with appropriate magic within the other areas (rewriting config files when you move programs). The rest of it won't; the "make everything an AppDir" idea has come up before,

Btw look at this here:

http://ubuntu-unleashed.blogspot.com/2007/09/125-nautilus-scripts-to-simplify.html

125 of these scripts hmmmmm

Being realistic here, none of this is going to happen

Depends! You never know which idea will turn out to be successful.
Realistic != pessimistic :>
Just look at SLAX, aside from Gobolinux its one of my favourite
ideas in the Linux world, and Slax 6 really took very long...

Sometimes you just have to combine some existing ideas, refine them a
bit and have something great ... (okokok... a lot of work involved
anyway ...)

I'm quite disappointed that there have been very few positive comments about the idea

Well if YOU know the idea is good, go on anyway!

One example... you all know OOP (i hope so ;> that thing where most things are an object, and
messages are passed to tell the object what to do).
You probably also know AOP (aspect oriented programming,
where aspects and cross-cutting concerns are "described" instead of "behaviour" in the first place).

But I think not many of you know "cell oriented programming". These cells can "behave"
like cells in the living organism ;-) means you could isolate them and "transfer" them to
another PC and they all have their dataset before they "moved". The cells can
"organize themselves" to form higher nodes of cross cutting concerns (read this
as in: organs ... like a heart ;) )

The cell responds to signal transmitter/second messengers/hormones (read:
messages passed to the cell....)

Each cell behaves like an individual object without having a strict dataset (means
every cell can be altered very freely, so its more like a prototype-based system
than a traditional OOP system where a cell would be created from a class Foobar )

That cell can also clone itself and give rise to new cells (at best to new cells which *may*
have slightly new behaviour, which is then slightly combined with "artificial intelligence"...
I use a lot of "" because these are mostly ideas, and you know.... without practical
applications these are so far all only ideas.... and although Systems Biology is
shaping up slowly, these smaller things just take a lot of time)

Especially the network aspect is interesting. BORG network! :P

I'm sure I must be missing something.

Hopefully Giddie can reply, I am a little bit lost too :)