With the intention to make a low power portable device, purchased this item. After another earlier disappointment about AOC monitor that runs only under windows, I had to accept the compromise that this little computer will have windows 7 main OS and will run linux from virtual machine. After wasting precious hours to try to install windows 7 found on the Gigabyte site that windows 7 64 bit is supported by the bios update. Unfortunately the mainboard does not have QFlash, so only way to update Bios is freedos. Unfortunately the msdos stick could not be booted for whatsoever strange reason. Wasted further time to try to trick with EFI boot loaders and and and… Nothing really worked. Installed freedos on a virtual machine on another host. Booted from freedos, but the bios updater downloaded from Gigabyte site just does not want to work with insane error message.
Conclusion: stay away !
I found the following comparison:
This makes having doubts about the performance of cairo on babelview…
Babelview’s goal is to provide a simple, no-bloat phone framework. Yes, it is 2010, and I think that bloat is not the answer for usability and feature. The principle of babelview is the more you want, the more you have to pay for it in terms of responsiveness, start-up time of applications. The goal is to boot a linux based phone on the reference platform “openmoko freerunner” in less than 10 seconds. I mean “boot”, to have the phone in a state where it is possible to make phone calls, or start applications.
The highlights of the “should be state” of the minimal babelview stack:
- simple widget kit that focuses on full screen applications
- full screen transparent keyboard for simple application manipulation
- simple and consistent gest recognision system
- own rendering engine (draw (line, circle, etc.), draw string
- jpeg viewer with basic transformations
- pdf viewer for document viewing
- ebook reader
- navit navigation, map viewing software
- web browser
- powerful and fast text editor (the new viq) engine
So far it is already working
- own rendering engine (draw (line, circle, etc.), draw string
- jpeg viewer (libjpeg)
- pdf viewer (mupdf)
- first basic widgets (label, list)
Nice to have
- cairo, and cairo based applications. It seem that cairo 1.9.7 will add support for 16bpp. This would probably make cairo rendering faster.
- qt, etc.
If you think you are interested in the project, please contact me through the blog
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.
Discovered already months ago radare, same learning curve as with vim… for sure would not recommend to the 90% of the people working in It, but only for the 10%. If you hate vi, you will hate radare, if you love vi, you will even love more radare.
Did you ever think to print only text from a binary….
hexdump -v -e ‘80/1 “%_p” “\n”‘ /bin/ls.
or to see text in the physical memory (need admin rights, take care!)
hexdump -v -e ‘80/1 “%_p” “\n”‘ /dev/mem
read here: http://lwn.net/Articles/147901. It is about /dev/kmem . Something that was on my linux systems for ages… And I wanted to have a look inside it… and the big disappointment came… And the I found the article.. And found all that bunch of incompetents, who argue about writing any piece of software is crazy as rootkits and other mall-wares might exploit it. …
Well not anymore… I spent a little time to add new labels, and move stuff around. Who did not find an umbrella, was sent to archive. Now everything is fast. After doing that I realised that what was probably making my gmail interface slow were the “Multiple inboxes” on top. (You may activate them under settings). When opening the inbox, the “Multiple inboxes” boxes are doing a search based on the criteria in the definition. Anyway, they are still searching in the archive, but now my mailbox is responsive like before…