Quote:
Originally Posted by PeterT
Well when I look at the makefile at KoboLabs in the busybox directory I see version 1 patch level 22 extraversion kobo which would appear to match the eye catcher from the run you did of busybox.
I do wonder what issues you hope to fix seeing I expect most issues are in the non open source portions of the device ie the main application nickel?
|
Cool! So the Makefile does have a reference to the version! and this busybox is more likely the one used by the KoboGlo, and AuraHD, after all, then. Thanks!
The makefile in Gnu software is usually created by a configure / confiugre.in script, and the M4 macro system ; so I didn't think about checking the makefile contents... it often doesn't have a readable version number in it. I guess in busybox, it does!
As to bug fixes, all kinds of them.... some of which affect the native kobo apps, some of which don't. ( Most of the things which affect native kobo apps are bugs in the linux kernel and drivers, or just failing to use the hardware that is available in the lowest power mode possible... )
For a few examples of things that irritate me because I'm trying to do maintenance and develop some Kobo apps, eg: the first thing I would like to work RIGHT in busybox -- is the basic unix shell, eg: ash.
Ash should be able to receive 'control C' from the USBpty, and interrupt a program that is being run over telnet; but for some reason the default setting when I log in is that control C is disabled. So when I work on the kobo, I can't break a running process without logging into another telnet session and running 'kill' remotely. I figured out that I can run "stty sane" to enable control C -- if I forget to do that -- then it's a pain... and startup scripts don't appear to be read if I don't login as superuser.
eg: There should be a telnet or ssh server that allows me to login to ASH as non superuser, and still works.
Another example, I have written a very small vt52u (unicode) terminal emulator that runs on an e-paper display. It knows about update ioctls, and can efficiently queue terminal screen updates so as to not have the user forced to wait for redrawing, and supports type-ahead and power conservation. (I'm working on figuring out the KOBO's dynamic clocking system, because I want to reduce power usage even more -- but that's tricky.. ) The terminal is fully supported by ncurses, plays nice with vim, readline, and even has a basic stroke recognition input software that lets me emulate a keyboard with the touch-screen via. gestures, so that I don't need a graphics keyboard that has to be redrawn for each button press, or mode change, and which isn't missing a lot of key combinations that I can normally enter (like control C) on a real keyboard.
The terminal emulator was originally for my sony reader, prs-600, and allows me to do text editing for well over 12 hours continuously; and with a very little effort could run for days on a Kobo once I figure out the power conservation modes of the Kobo.
It would be nice to make an app out of the vt52u terminal so that it can run as a 'beta' feature for the kobo under nickel; eg: a system terminal not requiring X11; but even if nickel is too broken to let me develop my terminal as an app, I would still like to be able to use it stand alone to be able to take notes and edit files, and run python from the command line. ( Python, and frobtads, are apps I really like to use, and share with my kids, along with either pygame which has to be modified to run on a framebuffer ; or pyQT -- which could be interfaced to QTanywhere library already on the KOBO. ).
But, several of the tools in busybox are not compiled to play nicely with terminals in general. The "ls" command, for example, is hardwired to use ANSI escape sequences which are not supported by several kinds of terminals; and does not accept termcap definitions. There should be a way to configure ASH by a startup script to never use color; but that's also broken in various ways. eg: busybox assumes a color linux vt-102 terminal by default even though an e-paper display is presently, by definition, only black and white, so that the default doesn't make sense.
Oh, and there was one other thing I already know about -- though I forget exactly which expressions were broken -- but the built in grep does not parse all regular expressions correctly. Certain pattern combinations cause incorrect results in the output.
These kinds of bugs aren't serious because they can be worked around, but they do exist and I'm sure there are many more I simply haven't found -- but I think as a user of open software, that I should verify that I actually have the tools necessary to fix bugs and that they are ready to be used.