29 Sep 2002 (updated 29 Sep 2002 at 05:48 UTC) »
most of the benefits (security, modularity, simplicity) of a microkernel can be achieved by other means without making the performance tradeoffs. the degree to which a microkernel achieves those things itself is questionable: once you add the performance hacks much of the original benefits are gone.
i've found spin (extensible kernel) and exokernel to be more interesting conceptually than microkernels [1]. i think this is mostly because of how they approach the application with respect to the end-to-end argument.
spin takes the viewpoint that application specific code should downloadable into the kernel to provide mechanisms which more closely match the needs of an application [2]. exokernel takes the opposite approach and just provides hooks for hardware resource manipulation. the application (perhaps another os like UNIX) can then control many facilities normally associated with the os. everything else is done in userspace (avoiding context switch overhead) and system services are provided through user space libraries[3]. (it also has facilities for downloading code into kernel space as well, which kind of deviates form the spirit of the system, but is good for things that want to run at interrupt level).
other amusing things are that spin used modula3, and exokernel has neat runtime code generation (create optimal code for the specific case you need).
[1]. i've seen both of these referred to as microkernels, but i don't know that they qualify: they don't use out-of-address-space system servers to provide services, they therefore don't rely as heavily on IPC, and they differ on their choice of the tradeoff they make between running code in kernel space and in userspace.
[2]. that sounds scary from a security standpoint, but it's basically like loadable kernel modules that most os's have. in fact, it probably has a better security system than do current examples (like linux), in that a trusted compiler must sign the module after compiling locally and determining the code doesn't do anything nasty.
[3]. this is fuzzy for me, i'd like to see how this would actually be done.
here are some papers that might be fun to read on the subject:
it might be fun to play around with these ideas at some point, since most of the code is out there to make this not too time consuming of a task (for example vmware, mol, flux oskit, bsd's, linux, etc). one more fun thing to do. hooray!
16 Sep 2002 (updated 28 Nov 2002 at 10:34 UTC) »
[Note: mmeeks tells me i am on crack. BonoboObjects are only used on the server side (although one must realise that a program can be both a client and a server at the same time). i had wanted to treat bonoboobjects as location independent, but that isn't really the intention. they just add a layer on top of the corba C bindings to make it a bit more understandable and convienent. which is a good thing]
i think i figured out my problem in making bonobo objects.
here's the source for the example object i've been working on (and a tarball of the same).
so here is what i learned:
the actual issues might be somewhere else (this maybe should happen automagically, and i'm just not doing it right), but at least i can get it to work now.
hopefully now voltron can get back to work on his project.
hooray!
One idea i think about on occasion is whether something is lost when one componentizes or modularizes software. We are taught abstraction as religion, mostly for the benefit of the human mind--as a compromise with our finite brain power (globbing and the whole 6-8 things at once thing). Because people make fewer mistakes when the cognitive load of a task is decreased, abstraction leads to better software.
But i think it also leads to more limited software (from the developer's perspective). Limited not with respect to computation, but with respect to malleability and ease of adaptation. Basically, this is the same lesson that the end-to-end argument and worse is better convey.
The larger and more granular an interface is and the larger the policy which it enforces, the more brittle it will become.
But large policies encode complex semantics and with them power, at least, iff that policy is the exact one for the case at hand.
Certainly, we cannot abandon abstraction as long as people write software (and it is likely to continue to be written by people for awhile, especially when creativity is required). I have a number of ideas as i'm sure quite a few people do.
(recently, i was writing a medium sized software framework which had so far been quite nice and modular and did everything i needed it to do. but suddenly i wanted one small piece of information in a place where it was not available due to the particular set of abstractions that were chosen. so in order to fix this, i'm going to have to cruelly hack up things to get that bit of information from the internal place it is, to the other part. the brittleness invited cruft.
this is certainly fixable, the problem is more that it's a giant pain in the ass. it is also preventable, had i known that i'd need to prevent it. unfortunately to always prevent these situations, you need infinite look ahead. since this isn't likely, there needs to be a better mechanism. the world is dynamic and software requirements change. what is perfect for today may be dead wrong tomorrow.
(maybe adaptive intefaces would be good). (we need to get to the point where we can say the Word and the universe will work out the implementation details and test the implementation.) )
12 Sep 2002 (updated 16 Sep 2002 at 08:07 UTC) »
been trying to figure out the architecture of Bonobo stuff lately.
here's an example i got working recently.
there are some interesting things to note here. BonoboObjects confused me for awhile while reading through the source code (libbonobo/bonobo/bonobo-object.c). they are an abstraction for the both the server and the client at the same time. (and both the client and server functions tend to be implemented in the same file adding to the confusion). so the object has both the virtual table necessary for rpc dispatch to the skeletons, but also the client side functionality--ie routines which make remote calls to the server.
another interesting thing occurs when you try to query object interfaces. it appears that an interface derived through inheritance has a reference which is (or can be) separate from the child of that interface. so if you try to query the interface of the wrong object ref you get a different set of aggregates...which can be really confusing.
i think maybe this behaviour is a bug. but there is a strong possibility that i mishandled some of the references and probably missed a step where i was supposed to fix something up to correct for this.
another thing is that g_object_ref/unref isn't virtual. bonobo creates a set of functions specifically because it needs to do reference counting with the remote object. but since you can't override g_object_ref, you just have to remember to use the right one...or else.
next i need to start perusing the source of libbonboui. i'd also like to write up some more notes, so that other folks wll have something to go on.
after that i would like to explore automagically creating the bindings whenever you create a widget.
i have ideas...about things.
hooray!
Life feels very confusing lately. I've pretty much ceased contact with Megan, who never even seemed to recognize the fact that I had an interest in her (despite my constant efforts). My friend Steph was pretty good at helping me through this. Mentally, I know that Megan isn't right for me, but I still have feelings, which is tough. So, I've avoided her, or at least tried to, but today she was in my Japanese class. She and her friend started writing little notes back and forth (I couldn't read them). Then they would look at me and giggle and smile. I have absolutely no idea what they were talking about, but it didn't make me too comfortable...and
...Megan's schedule aren't too compatible, I'll be taking the 9:00 bus so I can spend an hour with her. I just wish something could happen here, but it can't. She doesn't want that, I can tell... Just friends. Sigh... Just as long as she's happy.
just ask her out, none of this "i can tell" bullshit, none of this martyring crap. if she says, "no", fine, then you can decide to be or not to be just friends without that little doubt in the back of your mind that maybe, just maybe something will happen. if something will happen later after you are just friends, it will happen later.
you're only screwing yourself over by trying to get her to lead you on and missing out on other relationships (either as just a friend to her, etc). and you're not doing anything good for her either, so don't dress it up like that.
*cough* not that i'd know.
I mean, look at Linux. Linux started because Linus didn't think Minix was the best system for the job. So he worked on it and came out with a superior product of his own. He didn't, at least not to my knowledge, flame the guy that wrote Minix all day long.
ironically enough,
linus did flame the guy who wrote minix.
but it was a mutual thing
i find it kind of funny that C sometimes forces one to make a tradeoff between code flexibility/readability/maintainability and performance. for example often times in a framework, you would like to have a nice somewhat general, somewhat extensible, somewhat modular API to use and in order to do that you partition a problem in ways which do not always lend themselves to maximum performance.
i think this is a good reason to create small, non-general purpose languages. (which i sort of argued for before). often times you know what you want ahead of time (at compile time), but C just makes it a tad awkward to express with it's (lack of) macros.
as a slightly trivial example, a small language can support flexible table driven data processing which can be extended at compile time without resorting to the usual pointer indirection that the obvious implementation entails. (where you know statically what the datatype is...ie. when your table driven stuff is mostly for the purposes of making the API pretty and easy to use, rather than to allow for runtime dynamic behaviour changes).
another example (which i think i saw in a usenix paper at somepoint) is image processing algorithms. for clarity they tend to be implemented in seperate stages but logically they can be computed and applied at the same time (within the same loop). so instead of making the tradeoff of reducing performance for the sake of making the programmers' task easier, (or inventing a super intelligent AI to do general code optimization), you can create a language which explicitly does the dirty work you know you want done for you and which allows you to remain oblivious to it in most cases.
you want a specific small language because you know exactly what you want to happen ahead of time and figuring out when to do it in the general case (as an optimization phase in a general purpose language) is very hard.
or (how to write a title that sounds good, but is only marginally related the content).
or random thought of the day:
here's the summary: kids should be integrated into a well-functioning (good luck) community, instead of rounding all the kids up and shipping them off to a special place as we do in primary schools now.
i was idly thinking about education and the school system today. as well as why we (US...possibly the West) have such a difficult time bringing our youth through adolescence where in some other cultures there is no such huge shock for their children moving into adulthood.
(of course i'm generalizing from my own experience in reasonably affluent districts of US public schools. hopefully i will avoid looking through rose colored glasses at the 'other cultures' and avoid simply saying that public schools in the US suck).
the ideas that were sort of floating around my head were:
this to an extent follows from the balkanization of our society among various age, income, racial factors. here we just consider age. we cart grandma to the old folks home to die, we cart the kids to school to be babysat, and we cart the rest to work. and to a large extent their cultures do not overlap: each one is its own microcosm of values and norms. the younger generation finds the older's values to be silly and vice versa. our society basically provides little room for interaction between these groups.
moreover, the interaction it does provide is largely insufficient. a small group of administrators and teachers (often poorly paid, and poorly trained) trying to police a much larger group of children. they attempt to enforce the adults society, but being so few, and being foreigners with respect to the student's society, they aren't role models, and they aren't effective policemen. the children's culture thrives and is only occasionally impinged on by the adults. (to the extent that it can become a lord-of-the-flies scenerio).
it seems analogous to what happens on the internet (newsgroups, chatrooms), where people can act however they like with impunity. they are insulated from law, but more importantly they are insulated from the glare and simple condemnation of normal society around them.
people, being social animals, are designed to look for cues in indivuduals around them to figure out how they are supposed to act. some people (consider gandhi) have advanced far enought ethically and socially to codify a set of values for themselves so that they need to depend on outside judgement less often, and in general as we mature we depend on outside judgement less and more on our internal values and beliefs.
basically though it seems we abandon people growing up when they most need to be integrated into society and given role models and mentors showing them 'this is one way to successfully live a happy life in our society'. when they leave their cloistered society and move into adulthood, they find themselves without the social cues, without a good example of how to be happy and productive. at this point, they either have to very painfully learn to tread water, or die.
a way of mitigating this specific problem then is clear; (whether it is an answer to larger societal issues is doubtful). basically, you outnumber the young folk by the old folks; and hopefully it will lead to a more gentle introduction of children into society. at the same time it will allow us to buffer the people who need it from bullies etc. i suspect that if their is constant reenforcement from everyone around them people will figure out faster what is acceptable behaviour. (what if the adults are also bullies? method of due process?)
of course doing this is not easy. and i kind of hand-waived my way through the last part. i'm not going to try to give you a good argument here, because at this point i don't think you can: there is a lot of research and stuff to be done. from intuition and experience, it feels like a good thing. you surround impressionable children with good people and hope they are impressed. (don't try to beat them into the society, simply immerse them in it (instead of having them create their own alternative society without benefit of the larger society) and let nature takes its course).
to start off with you could begin to increase the number of teachers in a single classroom (not just a better ratio, but have more than one teacher physically present among any closed group). using trained volunteers could to mitigate the cost could be useful (retirees?) (although "more teachers" == "yeah right, good luck getting the money").
of course we must examine the negative consequences of the idea. my misgivings are basically along the lines of 'what do you want the '50s?', and the question of whether it is just a new way to more effectively crush the child's soul and spirit. what if society is wrong?
(N.B. the royal we is used below, but i don't mean to ascribe any beliefs to anyone but myself...and maybe not even myself).
my intuition on these is something like 'you can teach anyone how to paint, but you would have had to teach michealangelo or da vinci how *not* to.' you and i are products of this culture. i consider myself to be becoming a really *good* person after all these years of struggle. i think some of you are also becoming great people, people with wisdom and intelligence and compassion. we are becoming the people we are becoming both because of and in spite of our society. in all society's no matter how backward, stupid, and repressive have had great people (and even extraordinary ones). basically, in spite of the way we demonize our societies and the lemming like people who inhabit it, some of the basic core is both necessary and good (and in the case of society unavoidable). we are not as different or separate from our societies as much as we may like to think we are anarchic, counter-culture whatevers. like any other complex thing we must be very careful about understanding the good and bad points before throwing it away (cf. religion and human nature) because of our bitterness and bad experiences with their negative aspects (religious wars, racism, catholic guilt trips, gender inequality, ..., ...).
misc: it also may be helpful to look at japanese culture. most people are familar with the extremes of portrayal of the culture: being one with strong familial and societal ties and being one which turns out uncreative clones as the raw material for corporations. i don't know enough about the actual issues to comment...i think this example reinforces the ideas above in several cases. there are lots of other cases and points to understand especially wrt generalizing with other groups and individuals experiences. also note cultural differences wrt the emphasis on the values of being a member of the society vs being an individual). also in some agrian societies there is no strong delineation between childhood and adulthood: they don't have this larval pupa stage.
tromey: i don't think depending on some language is particulary troublesome. if worse comes to worse you can always bundle and statically compile the build tool (if you move to python as the implementation and tool language, you could see it as reducing the dependencies...granted you're requiring a less common one...). you also have a known entity instead of having to pander to the lowest common denominator.
(in this respect it might be to your advantage to explicitly say on the front end 'our build tool uses python and takes advantage of these features: <exact-list>. if you are building a python work-alike for the purposes of running our tool it must support at least this subset to be successful.' this approach lets you take an open-format approach in which you aren't requiring any specific implementation of a language, only a set of features and syntax.
you end up pretty much with a language spec for python-lite, but it allows you, if need be, to go off and code your own implementation of it without worrying about doing all of python for it to work. just saying you need language X doesn't give you enough information; it would be like saying 'this program requires a computer.' on the other hand if you tell people you need computer A, with processor B, OS C, libc D, etc, and spec the whole thing out, people will have no misunderstandings about whether or not what they have will be successful in running the program.
as tedious as specifying exactly what subset of functionaly you use is and then specifying exactly what that functionality means, i think it might save some issues in the long run as python might mean something else in a few years. ).
the particular issues i can think of have to do with the language being out of one's control. what happens if python 3 turns into something you no longer want to use? do you fork it? another issue is that i feel that gmake, m4, and sh are more or less stable (could be wrong here) from the standpoint of the end-user. that is, there isn't going to be some new feature added that breaks your existing stuff.
no matter what you'll get a lot of whining. everyone will be annoyed with something...because they liked auto*, LANG=(python|perl|lisp|arc|scheme) is too wierd and they can't understand it, you're depending on $LANG (nevermind the duct tape we already depend on), etc, etc. i suggest you let these people sod off.
are you aiming to replace just automake, all of auto*? or auto*, and its little make(1) too?
FOAF updates: Trust rankings are now exported, making the data available to other users and websites. An external FOAF URI has been added, allowing users to link to an additional FOAF file.
Keep up with the latest Advogato features by reading the Advogato status blog.
If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!