Showing posts with label linux. Show all posts
Showing posts with label linux. Show all posts

Zim Zim Python Python Fix Fix

I recently upgraded to Ubuntu/Kubuntu 10.04 and it comes with some changes. Zim wiki is now completely python and much faster and clearly cleaner and more attractive. Thunderbird 3 is also very nice. Upgrade went easily, but some questions were difficult, like: "The quantum entanglement of multiple simultaneous realities has caused a Gamma Ray Burst, continue, Yes or No".

It seems that the equation references in Zim are slightly different and so I devised this little tidbit to bring harmony back to the universe of Zim, Zimpy, and perhaps python itself. The point of this is to take {{./Dir/equation_xx}} and convert it to {{./equation_xx}}. I could have used grep, sed, awk or C, but python is a clean language and I think it is more understandable when viewed by others.

#!/usr/bin/python
# -*- coding: utf-8 -*-

import os.path
import sys

# If there is more than one reference on a line in the Zim it will require that the script be run once for each level. 
#I could just iterate a few times, but it is easy enough to hit up arrow in terminal and run again
#I am also limiting the location to within media just to make sure it doesn't go awry in my root directory
#This is GPL code if you have any question what that means : 
#         Return to your home planet and never visit Earth again!!
#Use at your own risk, code provided as example only
fileScan=0

def doall(aDir,anExt):
 name=os.listdir(aDir)
 allScan=0
 global fileScan
 for named in name:
  if named.find(anExt) != -1:
   (jbase,jext)= os.path.splitext(named)
   allScan=allScan+fixequations(jbase,aDir) #t or not determines if it really does something
   fileScan=fileScan+1
 return allScan
 
#Just list the files that would be changed
def fixequationst(thebase,adir):
 print "Fixing ",adir," file ",thebase+".txt"
 return 1
 
def fixequations(thebase,adir):
 allScan=0
 thename1=thebase+".txt"
 thename4=thebase+"UNIQUEOLD.txt"
 thename2=thebase+"UNIQUENEW.txt"
 handle=open(adir+"/"+thename1,"r")
 handlew=open(adir+"/"+thename2,"w")
 aline="something"
 while aline:
  aline=handle.readline()
  if aline.find("media") != -1 and aline.find("{{") != -1 and aline.find("}}") != -1 and aline.find("equation") != -1:
   token4s=aline[aline.find('{{/media')+2:aline.find('equation}}')+8]
   if token4s != -1  and  aline.find('{{/media')+2 < aline.find('equation}}')+8 : 
    (jbase,jext)= os.path.splitext(token4s)
    jext2=jext.split("?")
    newr= aline.replace(token4s,"./"+os.path.basename(jbase)+jext2[0][0:]+"?type=equation")
#    print newr,token4s,thebase,adir #This would allow progress monitoring of changes
    handlew.write(newr)
    allScan=allScan+1
   else:
    handlew.write(aline)
  else:
   handlew.write(aline)
 handle.close()
 handlew.close()
 os.rename(adir+"/"+thename1,adir+"/"+thename4)
 os.rename(adir+"/"+thename2,adir+"/"+thename1)
 os.remove(adir+"/"+thename4)
 return allScan
 
def scanDirs(ipath,theExt):
 filesChecked=0
 thisext=theExt
 thisdir=ipath
 filesChecked=filesChecked+doall(thisdir,thisext)
 return filesChecked
 
#------- This is where it does something ------
pathsScanned=0
allScan=0
filesChecked=0
if len(sys.argv) > 2:
 InputDir=sys.argv[1]
 x=os.path.exists(InputDir+"/Home"+sys.argv[2])
 y=os.path.isfile(InputDir+"/Home"+sys.argv[2])
 if x==True and y==True:
  print "Scanning"
  for root, dirs, files in os.walk(InputDir):
   for onedir in dirs:
    path = os.path.join(InputDir,root, onedir)
    filesChecked=filesChecked+scanDirs(path,sys.argv[2])
    pathsScanned=pathsScanned+1
 else:
  if x==False:
   print InputDir+" does not exist and returns "+str(x)+" when checked."
  if y==False:
   print InputDir+"/Home.txt is not a file and thus "+InputDir+" is not a Zim Wiki location. And when checked returns "+str(y)
else:
 print "Input arguments::"
 print sys.argv
 print "This requires base directory containing Home.txt and a limit on file types like: .txt"
 print "It must be invoked with python also as it requires 3 arguments."
 print "Example would be:"
 print "\"python FixZim.py /someplace .txt \""

print "Number of paths scanned is "+str(pathsScanned)+" and references changed is "+str(filesChecked)+" in "+str(fileScan)+" files."

More tangled webs of cameras

This link seems to have good information on video for Linux and the simple program works well, there is some confusion however, and I wonder if the issue is version related. I am going to take the plunge to the new version 9.04, I thnk and see how that works with v4l. Certainly it is operational and it requires some effort to use the appropriate interfaces. It seems that I could write an article that was informative and separated the methods that might be used to operate the devices and the depth of technical operation which extends from the interface to libraries to kernel device driver interface methods through USB.

The implementation of a user interface could be daunting as it involves ioctl and device reads and numerous APIs, but a good example can go a long way to de-mistify the complexity. I think I grasp the overall structure and I can see how it is a WIP, I think I will just keep track and follow the progress of the interface for a while to see where it is headed. For a supported device using the test program, the delay to open the device is essentially zero and the quality and usability is certainly as good as with Wind Dohs! without all the associated BS.

I am still wondering about the name issue and the length of it limited to 31 characters, but if the spec is 31, then the video device is violating the spec, which I would expect to be more likely than the v4l people being wrong as them seem to be very detail oriented.

"I do not see.", said /dev/vide0

I find it very odd that a camera that is supported fails to work and a device that isn't supported at all works almost perfectly. That seems to defy reason. I have browsed through some old trouble reports and I can see that like all people they go to what they think is the source of the problem, however, things are not always what they seem. It is clear there is a disjoint in this management of video , which extends to the kernel level. At some point I may make a bid to straighten out the process. It appears that all the needed structure is there, it is simply not managed in a coherent way. Perhaps this is something that I can help with and be effective.

This is the ongoing and somewhat frustrating view of video. I have to mention that this is not a Linux issue and the complaint that they do not support video well is unfounded. The windows environment is a total nightmare and there is no chance that it will resolve as they do not allow anyone to know what horrible tricks they play to get even one device to work, let alone support thousands, and Linux supports devices often, without any help at all from the manufacturers. In windows, you had better just install one device of one kind and limit the number of peripherals that you mix. There is obviously no cooperation between vendors and they would hardly care that another device made theirs unusable after you had paid.

The key here is that Windows forces you to pay up front for the operating system and then delivers trash to your living room and they could care less if it bothers you that they sold you a pile of smelly refuse (The acronym is "System High Information Technology" or more commonly known as SHIT). They have the money and you have been suckered.

So now to Linux, and I am investigating the structure of how video is used and so I am testing all my video cameras. I am now testing one that is on the supported list which shows up by "lsusb" as:

Bus 001 Device 004: ID 046d:0991 Logitech, Inc.

and there is a fault somewhere in the handling and I am trying to isolate that. I have modified the source for my drivers and this could be the origin of the incompatibility now, but I will make a report when I have it running well, to explain how I achieved that and what steps I took.

This follows on from an earlier thread in the blog HERE.I think it is actually quite absurd of the manufacturers to feign support a standard interface like USB and then play tricks to hide how it is used. I often think that it is to hide how ugly their source code is and avoid the ridicule of real programmers. I can guess from past experience that it is riddled with a higher "F" count than the entire source of the Linux Kernel. I am sure that Daily WTF would find some interesting things there and perhaps the number of places where // "Why does this work?" is found in the code would be very informational. I can hardly trust that the firmware in the device itself has any better design quality control.

More on video internals

I am working through the complexities of the camera device in Linux and so I am starting simple again and here is the framework of a test that times the opening of the video. I thought it was about 6 seconds, but I may have had too much coffee today, as it is 4.260 seconds. This what I want to know, why does it take 5 seconds to connect to the video device and is there any way to shorten the time. Also I want to know what that overhead involves. Clearly it cannot take that long to send a USB query and get a DMA or other ACK, I would assume.

#include <fcntl.h> #include <stdio.h> #include <sys/time.h> suseconds_t time_delta(struct timeval *t0){ struct timeval t; suseconds_t dt; if (t0->tv_sec == 0) gettimeofday(t0, NULL); gettimeofday(&t, NULL); dt = (t.tv_sec - t0->tv_sec)*1000000 + (t.tv_usec - t0->tv_usec); t0->tv_sec = t.tv_sec; t0->tv_usec = t.tv_usec; return dt;} int main( int argc, char * argv[]){ static struct timeval t0 = { 0, 0 }; suseconds_t dt;suseconds_t dt2;int cam_ID; dt = time_delta(&t0); cam_ID = open ("/dev/video0", O_RDWR); dt2 = time_delta(&t0); printf("Camera open ID = %d \ and Open time is %d ms.\n",cam_ID,(dt2-dt)/1000); dt = time_delta(&t0); close (cam_ID); dt2 = time_delta(&t0); printf("Camera close time = %d ms.\n",(dt2-dt)/1000); return 0;}

Bitten by the bytes[32]

I discovered that you have to right click in the area labeled filter to pop up a menu that allows you to do color correction and add other odd filters. If that is not the most unintuitive thing I have seen, it at least ranks, since there is no help about it. This is a screen snap of "camorama", but I played with the title and some other elements while digging through the code.

I have been playing with video, gstreamer, cheese, camorama and other v4l diagnostics and devices. I think that I may be competent, which is scary. I have been wading knee deep in Linux and source for a few years now and I think I have enough information to be dangerous.

I looked into the heart of the kernel darkness and I see many things.


struct video_capability { char name[32]; int type; int channels; /* Num channels */ int audios; /* Num audio devices */ int maxwidth; /* Supported width */ int maxheight; /* And height */ int minwidth; /* Supported width */ int minheight; /* And height */ };

This is from "videodev.h". It seems to me that many things are compiled against this and expect it to be that way. The odd thing is that the name of my video device is longer than that. I am guessing ( or hoping) that they are wise in putting that name there, however , that is to be seen. I suppose I have to go one step beyond and see who populates that structure in the .ko and who expects it to be that way. What really surprises me is that other programs get the full name and this is a riddle within an enigma. I implies a different handling and I guess I will be to the USB trace level soon.

It seems that I have enough information now to look at code and say where people have goofed. It also seems that I could easily write dozens of new device drivers every day. Many people cry about lack of spec from manufacturers, but my past is in the PC compatible business and I never let a lack of information stop me. There are many weirding ways that I have learned.

When considering lack of spec, it seems the biggest problem is that whoever designed life forgot to publish even a readme or man file. I have tried "man life" and I get this:

No manual entry for life

The Eyes of a Gnome, full of cheese

I have no idea what I am doing with this video capture tool and I was running it at the command line and it said that it couldn't get thumbnail views of the video. So I got into the source and did some looking around to find the source of the problem and I am fairly sure that the code is bad in this area. I changed the line marked and it works now to give thumbnails, as can be seen from the screen shot.

I am sure there is more going on in the eye of this Gnome, but it works and I am thinking global scope issues here, and maybe when I am done I will be the new top cheese dev. Or I suppose I could fork it and call it limberger, because I smell something odd about the source.

The change is in cheese-2.22.3 in the file "eog-thumbnail.c" at about line 237. I could send a patch for this, but I will wait and see what happens in the next version, and if their is no new development, I may try to pwn it. I changed some of the messages while I was in there and I think I will add a separate window to control the camera characteristics, just for something to do. There are other warning errors and I suppose I will fix them now too.

An odd thing about Firefox is that I can zoom and unzoom the page with control with plus and minus, but control with zero, does not reset the scaling, however control and shift and zero does. The menu says control and zero, but I think they are spoofing me! Well in a way they are, but if you use the zero at the top of the keyboard it works that way, but you need shift to use the keypad zero to reset, I guess I should have figured that out before I made this bit long post complaining about my own failure to comprehend what should be fairly obvious.


void eog_thumbnail_add_frame (GdkPixbuf **thumbnail) { GdkPixbuf *result_pixbuf; gint source_width, source_height; gint dest_width, dest_height; source_width = gdk_pixbuf_get_width (*thumbnail); source_height = gdk_pixbuf_get_height (*thumbnail); dest_width = source_width + 9; dest_height = source_height + 9; result_pixbuf = eog_thumbnail_stretch_frame_image (*thumbnail, /* changed this from "frame" to "*thumbnail */ 3, 3, 6, 6, dest_width, dest_height, FALSE); gdk_pixbuf_copy_area (*thumbnail, 0, 0, source_width, source_height, result_pixbuf, 3, 3); g_object_unref (*thumbnail); *thumbnail = result_pixbuf; }

Video for Linux 2

This is a snap from the camera and it seems to be a decent quality. As far as the books, they are just there to make people think I am well read and if I could read, I bet they would be good books, cause they sure look pretty.

I decided I would revisit video for Linux and see if there was anything new to learn and perhaps I could get a better feel for the overall methods and provide some reference that would help to reduce the frustration that sometimes is generated by the comlexity of it.

To start I will cover the command line options. a simple "lsusb" will give you output like this:

Bus 001 Device 007: ID 046d:08d7 Logitech, Inc.

Now that you know it is there and you want to see how well it is supported, go here:

uvc devices are listed here.

A good command that will be informative is "locate uvcvideo" and the output should look something like this:

/lib/modules/2.6.24-24-generic/ubuntu/media/usbvideo/uvcvideo.ko

Then to see if it is a device loaded in the kernel "modprobe -l uvcvideo" and it should say the same thing.

Other useful commands are "v4lctl -c /dev/video0 list" and "v4l-info" Some of the output from v4l-info is here, but there is much more. I wanted to add that the source and executable for this is in the "xawtv" package if you are having trouble finding it.

general info VIDIOCGCAP name : "Logitech QuickCam Communicate S" type : 0x1 [CAPTURE] channels : 1 audios : 0 maxwidth : 640 maxheight : 480 minwidth : 160 minheight : 120

The program "cheese" seems to be the best at representing proper colors for my device type, but your mileage may vary. I tried several others including mencoder, which did a good job.

I know that it is not completely correct and has some things that could be implemented better for this specific webcam, and I got the source for them and intend to wander around a bit in the kernel driver, cheese and make a more integrated lower level interface for my ants program. Ontology is going well and the whole thing could be useful in a few more weeks. I have been working on this forever it seems. Always a new side trip and I hope I can stay on a straight path to integrating all this now.

Codecs and quality

Since I have delved into the nature of codecs and such , I will impart what I have learned and it confirms that I am stupid. This is always a good thing to know. Codecs is the encoding ( compression ) and decoding ( expansion ) of anything, but is commonly used for audio and video. I have come to realize that they are just one more way in which somebody is trying to control others. It seems that the free format OGG vorbis is faster and better quality, and yet a proprietary format is more common.

It is sad that you cannot buy anything that somebody has not tried to include some horrible trick to profit from the general lack of suspicion about the motives of those who sell products. I am as stupid as anybody else and it constantly surprises me, even though after all these years I should expect some trick from anybody who offers a product for sale.

I am thinking about creating a new format that is better for a new technology method that I discovered and I hope to start it right, with open unencumbered standards, but even that is difficult, as there are those who will take what is given to humanity and use it for profit. It seems that there is no end to the number of people who will use information as a tool against others.

An interesting thing that has happened recently is the growth of acceptance of nuclear power as an acceptable alternative to fossil fuels. I think that it is perhaps less of a risk and never mentioned the fact that the wheels of that process of acceptance were grinding for many years. I could see the shadows of the hands that control the technology working toward their ends and I think it is the best that can be done for the short term and likely will lead to a safe process in the long term. I know that it is possible to extract the energy from the nucleus without so much thrashing, but first they learn fire and later they learn to control and use it efficiently and safely. Burn in my fireplace, chaos.

Linux kernel understanding

The Ottawa LUG ( Linux Users Group ) created several videos that go into great detail about how the kernel is designed, structured, maintained, and used. It is reasonably informative and isn't too technical that it bogs down. The subjects are very complex and if you get side tracked into SCSI protocol, USB stacks, drivers and specifics of certain machine it can be years worth of information. These are deep enough to be informative and leave the technical detail to be known already or discovered, if needed.

One interesting thing I learned is that the kernel is "Object Flavored" in its implementation. C is not inherently OO ( Object Oriented ) and it is styled to be OO. This is exactly what I do in my code in a slightly different way as I define data sets that might be simple data types or complex structures or even sections of a structure to be "associated" with a method in context. The implementation in kernel and C++ is strictly single context association and I use a method that operates across data sets and then determines if a method is valid in a specific context, or excluded in a specific condition or context.

Another method I use is to funnel all calls through a single point. It distributes those system calls in categories and sections. The advantage of this is debugging , and I use a logging debugger which has a circular buffer to track the code. By placing my own break codes and 'int 3' in the code and the ability to control the level of debug it allows a much faster resolution of complex problems that may depend on what conditions transpired in parallel or previous to the fault. I also track each hardware interrupt on a conditional that is adjustable in the variables page.

Another advantage of centralizing system function calls is that I can essentially throttle the speed of the code to make it slower and slower as it approaches a point which is of interest. This is primarily for user space code that faults and then allows me to switch to debug or forces me to debug on a critical fault. It is not always necessary, however some faults are not immediately obvious, even to a trained programmer.

Another advantage of this debugger is that it will run code as symbolic. I can set up a virtual machine and pretend to do the operations in a symbolic context. I use variables like R10 as register 10 and simply have a distributor table that matches the machine code to a simulation of the code. The most difficult part of that is EA ( Effective Address ). If Virtual Effective Address ( Simulating a process running on a protected mode machine) is included it becomes almost mind numbingly complex. This also allows me to run code without a physical interface or debug virus like code in a safe way that produces list of what it did with which pseudo resources.

IBM also has much documentation on Linux and that is commendable. IBM is another bygone monopoly that has seen the light ( somewhat ). In their 'time of monopoly' they used their position to do some questionable things also.

Google has managed to stay away from the pitfalls of a monopoly and that is commendable. I think it is because they were aware that it is a company killer and it is not really good for people in general. I am not familiar with the founders, but I do hear the phrase "Do no evil." mentioned as a corporate policy.

ADDED: It is very interesting after going through the detail of how the Linux kernel initializes. If I were paranoid, I would think they had my code to use as a template. The truth is that there are not many ways that this can be done and be stable and proper. The order of events is determined by the hardware. Except for the fact that I used assembly right up to the point of the switch to protected mode, the code is the same. I can read the assembly and even the C as easily. Some of the features of GCC are new to me and some of the terminology is different, but the concepts have to be implemented a certain way. I do mutex ( mutual exclusion ) and deadly embrace avoidance, but I never called them semaphores. This highlights the fact that the type of activities that Ms has been involved in are completely inappropriate. Any person has to design the code around certain methods and by patenting or roadblocking a specific method that is required to achieve a goal is the same as poisoning everyone to benefit oneself.

This is one of those cases where BIOS experience, assembly(ATT & Intel), pmode structure, and hardware experience make this almost a walk in the park. I should have my own version of the kernel with a patch file in a couple days. The biggest gain that I see in that is the fact that I have a ram list based debugger that is dead solid and monumental in its capability. It works seamlessly in real and protected mode and that is very tricky. The absolute necessity is to never have a second fault in debug, as it is two strikes and you're out! -- reset ( Double Fault).

Following kernel changes

It is surprising how well all the parts of Linux operate together. I grabbed the kernel source and the most recent patch. I just unpacked it and clicked and kompare brought it up ( gotta love that file 'magic' ) and I could browse through the changes and see what was affected. If you understand the overall structure, it is easy to see what these things do. I am confused though, if this patch '2.6.29.2' and version is 2 patch level is 6 and sub-level is 29, where does extra version .2 fit in that picture and what does it mean? Of course I am being facetious. However, I really am wondering what a 'Temporary Tasmanian Devil' does.

I may do something odd and make a patch so I can take the kernel versions as they are modded and just patch them to my liking as a Kos style implementation.

Link to Linux Commando, command for console and it is ALT and period together to recall the operand from previous commands in order backward with each new press. Nice feature and saves some ambiguity.

Comparing kernel foo

This is some old 32 bit code from Kos in 'Intel ASM' register format and form.

BuildPm32Task: ; Create Physical Pointer To this TSS len 256 Mov Edi,PhysicalBaseTss ; TSS Mov Eax,WhichFault ; Mov Ecx,SizeOfTss ; Mul Ecx ; Index In Tss segment to this TSS add Eax,Edi ; And the Base Mov Ebx,Eax ; Save for Fill function Mov Dx,8900h ; Type and Granularity of size Mov Ebp,WhichFault ; Shl Ebp,3 ; *8 for Idt Call BuildTssInGdt ; Set it in the GDT to Tss link Mov Dx,8500h ; Type and Size Call PutGdtTsInIdt ; Set the link Idt to Gdt to Tss Mov Edi,Ebx ; This TSS Push Edi Call InstallTssDataP32 Call PutPortAccessV86 Pop Edi Ret

This is some code from the Linux kernel which is comparable.

/*H:610 Like the IDT, we never simply use the GDT the Guest gives us. We keep * a GDT for each CPU, and copy across the Guest's entries each time we want to * run the Guest on that CPU. * * This routine is called at boot or modprobe time for each CPU to set up the * constant GDT entries: the ones which are the same no matter what Guest we're * running. */ void setup_default_gdt_entries(struct lguest_ro_state *state) { struct desc_struct *gdt = state->guest_gdt; unsigned long tss = (unsigned long)&state->guest_tss; /* The Switcher segments are full 0-4G segments, privilege level 0 */ gdt[GDT_ENTRY_LGUEST_CS] = FULL_EXEC_SEGMENT; gdt[GDT_ENTRY_LGUEST_DS] = FULL_SEGMENT; /* The TSS segment refers to the TSS entry for this particular CPU. * Forgive the magic flags: the 0x8900 means the entry is Present, it's * privilege level 0 Available 386 TSS system segment, and the 0x67 * means Saturn is eclipsed by Mercury in the twelfth house. */ gdt[GDT_ENTRY_TSS].a = 0x00000067 | (tss << 16); gdt[GDT_ENTRY_TSS].b = 0x00008900 | (tss & 0xFF000000) | ((tss >> 16) & 0x000000FF); }

I am sure this just looks like caca to most everybody else, but I wrote original code in the BIOS for 386 protected mode switch and this shtuff is just second nature to me. When I was young I used to put those odd comments in the code and as time went by I quit doing it because it was funny the first time I reviewed the code and then just got irritating and I removed them all.

As much as I would rather use C , the advantage for a specific processor is nil in my opinion. I often rewrote these core code modules for different processors and I really like RISC big-endian machine code better, but Intel was the most common place to get work. I also use the 'Flat' real mode to play with VM before I switched. I also incorporated a full debugger that was invoked on a fault. That was my first design. It did disassembly and was rock solid before I did any more of the design.

It might scare somebody to drop to a debugger, but it was always my opinion that if any flaw existed that would stop the machine or fail in some bad way, I wanted to be all over that and know why. As the code is designed, I have not had a flaw in two decades now. I suppose it is possible, however I spent hours examining all the critical aspects of task switches, memory, and even timed every instruction of every module.

The silly thing is that I am the only person who ever used this OS.

The extensions to the OS are all written in pseudo code and all higher level functions beyond the main operating loop and memory/task management are purely gospel symbolic code that is executed as single steps. That took me nearly a year to design.

Something strange that I ran into the other day tells me that if I don't look deeply and have full knowledge of the source, it can be twisted, even if it is intended to be for a good purpose, back doors can be a major risk. Specifically I am referring to a self concealing compiling source sequence obfuscation. If you understand the process of bootstrap from the first hexadecimal code, you know who I'm talking about.

pragma poison foo fickle finger fate

#pragma once
I grabbed the synaptic package from the Debian repository and as I wanted to use the install logs to duplicate the installation of dev files that I always use after I do a clean install. "rlogview.cc" gets that information from '/root/.synaptic/log/*' and so all the information is already exported, so to speak, and I just did not know it was done that way. It seems that could not have been deduced without the code as a guide, unless I assumed it was there in that form. Here is a link to 'glib' at gtk.org which is effective to help understand some of the library usage.

I gain a little bit of knowledge each time I look through somebody else's code, as their idea of how to achieve a goal may incorporate a method that is new to me. Doing this package source from 'glade' is a bit quicker for someone who is familiar with the interface and does not make the code inscrutable and incorporates multi-language tools in a convenient way.

Synaptic(KDE4) has a feature that allowed search within search which is nice. As packages become more mature, I notice that new key combos, menu items, and more advanced features show up. It seems that it is an interface that is perfect for somebody who loves to learn new and useful things, but it could be irritating to somebody who wants things to always be the same. The rate at which technology changes would seem to guarantee that if we do not learn new things always, we could be obsolete and ineffective in very short order.

I have KDE4 and version 9 on one of my laptops and though there are still some issues, the interface seems more usable now and perhaps it is just familiarity. I have started spending more and more time at console and less at GUI so really it makes less difference how entertaining or distracting the 'point and click GUI long path' to an answer is.

Linux hacking adventures

I had an interesting after effect of copying my system to a new drive and I am a veteran troubleshooter and I have fixed thousands of problems in all areas of computers. It started as a failure to install an upgrade to hal, which is pretty scary. It had to do with the s bit of the policykit and it was resolved fairly quickly by restoring the file execute permissions and it was an interesting learning experience and gives me one more situation where I can quickly identify the source of a problem and its solution pairing.

In the process I had to mount the origin volume and look at permissions in '/usr/lib/policykit' and compare them to the state of bits in the copied dir. I should have mounted the old drive as part of fstab, but I am lazy and didn't do it. I added it to fstab by UUID so I can solve any other problems I encounter with sticky bits a little easier. I probably will shell script a grep and sed to compare the states of files from old an new if this happens again.

There is no time!

I read an interesting article on kernel developments about 'noatime' and the disk system. Val Henson has a very good article on this at her blog and she has lots of experience with kernel development. HERE

She explains it better than I could so I won't add my opinions except that I have seen some issues. "/etc/fstab" to set your "mount" options if you have forgotten.

Linux fault handling

This is a side trip into the unknown. So I got this bug that I wanted to do fault handling inside my program. I learned a lot of things and the differences between Linux/Unix POSIX and Windows. It is a much better way to handle things, but very difficult to manage for most. Here is a link from Linux Journal ( somewhat dated 2003), but it has a good framework. I had to make some changes, but I managed to get the job done.

They assume certain things about architecture that are not a given and I found a missing include, but these things are not show stoppers for a programmer. A person wouldn't be interested in the code unless they knew C and POSIX and could run gcc and understand "-fexceptions" and stack frames and library naming and many other things.

Great fun and it is rewarding in the fact that I have a new feature for antfarmgl. I always never make mistakes so it will never get used, but it is there for others who might modify code and generate exceptions.

I already knew about try/catch in C++,java,Python etal, but I wanted to look directly into the face of the sun for my own understanding of architecture.

You should be warned that a knowledge of one of the dark arts may be required to understand this and if you are not familiar with the dark side assembly ways you might want to pass on the link.

Linus, we thank you

Linus has posted this on his blog and I thank him for the work he has done on Linux and it is a wonderful achievement. As far as his opinions on Gnome, RMS, politics, and anything other that Linux and GPL3, I could give a rat's rear fsck what he thinks.

On the specific subject that Linux is not anti-Microsoft, I agree, but he has not had to use Microsoft products in a profession for 20 years as I did. You learn to hate the principles and the restrictions that are placed on developing a good product that can be torpedoed by a change in the OS that you are obligated to use. I am sure that Microsoft sees Linux as a threat to their way of doing business, even if Linux does not act purposely to undermine their monopolistic practices.

I see the open source community as more of a strangely intelligent explosion. It really is a collection of many things that take wildly divergent paths, but the overall affect produces a powerful result for positive change.

Linus has a BLOG!

This is just too weird. Torvalds is blogging and using blogspot. I think it is great. Here is the link to Linus.

The spooky night of Device Drivers

I bought a book that looked like this with a horse on the cover and I designed a new cover for me with GIMP, mainly because I am insane and also because I wanted to modify it further and use it as the desktop icon to the Device Driver Dev I am doing.



I will probably create a section in my own reference book catalogs and work through an entire device driver tonight to install it and control it. I have a NanoScope I Scanning Tunneling Microscope that I have modified and that will be the end interface point through an 82f51/8048 type flash microcontroller and another laptop that will be the intermediate device.


I also have a full tube of 1M flash bios chips that I use through a parallel interface that I designed to be similar to a nearCAM ( Content Addressable Memory ). I read the book when I first got it to get the general idea of device drivers and I have let it sink in a bit in context of Kernel hacking. I have made my own kernel several times and I think I have a fairly good general knowledge of all the tools ( GDB, emacs, vi, shell, built-ins, libraries, PERL, Python, 'c', gcc, make, cMake, jam, svn, SSH, TCP/IP, USB, ATT/Intel x86_64 assembly language, DDD, debian packaging, wiki, PHP, Apache, lisp, ada, config, ifup/down, serial RS232, CSMA, and bongo bingo (that is a ringer to see if you are paying attention ).

If you want to use the book on line here is the current link. I paid 39.95 +tax for the book and I think it is free to read on line, but I am not sure. Perhaps not, I think I got the free 45 day online with the book and signed up, then forgot when I started working on something else. So it is probably not free. It is a good book and seems to be well structured. I bet they know Zool.

Linux DNA device interface

I am working toward device drivers that do several things. One is a DNA device that allows cat, grep, sed, and other manipulations to take place on a strand of DNA in the device that houses it ( I.E. cat /dev/Dna/ant/Chromosome3 | grep GTCGTACA ). Another is the 3D and interface that guides the ants by producing a sound of a trapped ant in a 3D position of a matrix, thus directing the ant to produce a specific path through a material. It is very much like the X-windows interface that uses a stream to control a virtual 3D device, but in this case it is a real 3D matrix which eventually gets filled with liquid transistor material to make a neural array ( this is the same model as the ant brain mod, which alters the nerve paths of an ant). Another device is the virtual 3D space of a nano / micro / milli world. That is not a virtual world, but a real physical world that exists at a small scale.

This is why I need device drivers for the interface and I have written device drivers for winedow$ before and I assume the process is much easier, more open, and better documented than W$.dlls. I have investigated it a bit already and I have the general idea and I will try implementing one through a USB to one of my simple flashable micro-controllers.

It is an essential part of the entire system which is intended to be completely self replicating and automated from the level of the logic to the interface to Linux.

KDE 3D desktop demo which is interesting (Loud too)

Contributors

Automated Intelligence

Automated Intelligence
Auftrag der unendlichen LOL katzen