Really amazed about the fast boot speed of the new Ubuntu release, under 10 seconds on older 2.6 Ghz Pentium. I assume that some heavy work was done to start boot scripts in parallel…
Standards in IT are like the promises in the bible, that your next life will be in heaven. Most people believe that they exist, as they do not go beyond some basic system call names like write/open, etc., and they continue to believe in life in heaven. I am already sick with all these preaches about standards that always failed. In case of linux things are even worst. As most of other unices are dying out, linux is practically the main reference point. Linux took it however in an even worst direction. They say they would keep compatibility blah blah. The same time is lot of chaos, but the more the chaos is growing the less chance is given for new ideas.
What is my problem at the moment. Well, I wanted to use already for longer in different situations the power of MMU to do different tricks. Finally I had to draw the conclusion that it is impossible on Linux. It is simply impossible, as Linux obscures part of the pattern. Today I was thinking to write a very little program to test different random memory layouts inside a linux process in different contexts, based on different sequences of mmap and brk calls. The idea was to “scan” the memory by trying to write to it. You set up a signal handler to sigsegv, and then if you try to write to an inexistent page, then the MMU will trigger an interrupt, the kernel will try to recover the page from swap, if it is the case, and then calls a signal handler. What went wrong in my experiment? After the signal handler did it’s job, the kernel is restoring the stack and the state of the registers, and will continue the process where it was stopped before the “bad” instruction was executed. The problem is that the instruction pointer does not advance so again the same sick instruction is called.
So, what is missing? Well, simply a piece of glue that the kernel should call after it has restored the state of the stack and registers, so that the “victim” process can safely jump over the “bad” instruction and handle it in some way.
Well, my little experiment is impossible, unless I will try to unwind the stack, find the position of the wrong instruction, and help it to run, run..
Well, how is this related this to my frustration? Simply, if something like “post signal handler” would would be proposed to the key linux kernel developers it would be rejected as many many (other
) brilliant ideas I saw being lost… As the motto is industry ueber alles! In a better world, system calls would be able to cope with some primitive userspace closures, etc. etc. Well… nonsense to waste time to develop the idea
Would you like have a frenglish lesson? Read the pour lisaac documentation. So briefly, I have two problems with lisaac:
- the language
- the language
It seems that the author and people around would like to initiate a new wave of latinization of English. Documentation is very poor, just hype hype, we are the best, we do what other did not, even more, “we are going to write the French operating system”. There are 2 pdf files as documentation. Obviously the quickstart is in French, so the quick way of doing it was not designed for you this time. Do not know if it has something to do with a french law, that if you use any english word in any published text, you might end in the jail :). They claim that lisaac would have only 19 keywoards compared with C that has 63. Had a first insight into the grammar, I think the 19 should renamed at least into 20, as one of the worst mistakes in the this lisaac is that your are condemned to name all types with uppercase. Another weakness is that there is no reference to namespaces. Size, hm the size… french like size… For a 624 lines (15745 bytes) of lisaac code a 43320 lines (593669) of C code is generated, and the compiled and stripped executable is 582208 plus the dependencies on libc.
There are however few good points in this story:
- trying to create a compiled prototype language
- there was a little effort to create a syntax that is more intuitive for object oriented thinking.
So thanks guys for your effort, but not for the moment…
addition: the bastard lisaac installation overwrote my .vimrc file!!! luckily I have stuff saved in .git…
Henry Kroll III mentioned on the tcc mailing list a little tool he wrote that would save some time in writing C code by skipping some apparently redundant “grammar markers”. He proposes practically to write C code with a syntax a bit closer to python, and his tool would decorate it, resulting in a C code. I really liked the idea to write less, and let the computer do some completion, but I do not see how something like that could be integrated into a development process. The only way I can find use for his idea is to write some vim script (or similar macros for other editors), that would do on the fly the completion based on the proposed syntax.