On Tuesday 14 April 2015 03:35:50 Petter Adsen wrote: > On Mon, 13 Apr 2015 16:36:44 -0500 > > David Wright <deb...@lionunicorn.co.uk> wrote: > > Quoting Petter Adsen (pet...@synth.no): > > > On Mon, 13 Apr 2015 20:21:49 +0300 > > > > > > Reco <recovery...@gmail.com> wrote: > > > > Let's see as I didn't have OS design in mind. Something like: > > > > > > > > Exit codes and their value in real life. > > > > Strings handling, memory allocation. > > > > Process control and daemonisation (sp?). > > > > Signal handling. > > > > Inter-process communication (sockets, pipes). > > > > IP protocol use and abuse. > > > > Shared memory. > > > > Threads. > > > > Libraries and their usage. > > > > > > Just to pipe in here, these are among the things that I want an > > > understanding of - especially numbers 3, 4, 5, 6 and 9. With extra > > > focus on 9 and 6b :) Also things like communication between > > > processes and devices, file systems, etc. I want to learn how to > > > find out why things work the way they do, if that makes sense. > > > > If you want to understand the basics, there is any number of > > tutorials on the web. If you want to play with them, then pick a > > language and go to a web page like > > https://docs.python.org/3/library/index.html and write some toy > > programs. Most of these facilities have wrappers that save you > > having to write C code to create, say, a couple of sockets that talk > > to each other. If you try this in C and it doesn't work, it might > > take you half a day to decide whether you've misunderstood the > > socket concept or just made a programming error. > > I can understand that. > > > As Reco said, > > > > > > [...], and for the complex program you'll probably want > > > > something else as by today's standards C has poor result/effort > > > > ratio. > > That I can also accept. I see that a lot of people advice me on going > with something other than C, and I can understand that there are good > reasons for this advice. While I still want to learn C at some point, > I'm beginning to think that it might be wise to consider getting a > good foundation in another language first. > > Would Python be appropriate? I see a lot of software these days that > is written in Python, so it would be helpful in that way. The person I > am most likely to go to for help knows Python, so that's a bonus. And > on the subject of books, what would be a good introduction? > > Petter
If I can interject a bit here, if one has come up thru the ranks of assembly, C is the next logical step above working in that cpu's native language. Its functions are basically a core group of assembly language functions contained in the various libraries one links in to get the job at hand done. For smaller cpu's that is. I do 99% of my coding on a 6809/6309 based machine in assembly. And I am still doing it. My understanding of the quad core phenom in this machine at that assembly level will never happen, so a higher level language that handles all the nitty's and gritty's, the greasy side of getting the job done is required in order to get anything of consequence done. So much as I hate to say it, C is not my first choice to write a background task handler in. Python would appear to be a good choice but I don't understand it well enough to be "productive" in it, so my choice was something a bit more conventional, so I'll plead guilty to having bash scripts doing even obscure background daemon work here. Except for large number (double-double or double-float) math, it is entirely adequate for the jobs I ask it to do. My point, if there is one, is that the language used, needs to be on a scale that allows the job to be done, with few or no "surprises" if one is to be productive in terms of getting the job done. In some senses, the higher level lanuages also limit you, by offering only "canned" functions unless you can add to the libraries as needed. Those languages that do such limits on the coder tend to be 5 year flashes in the pan and the repos are polluted with them. BUT, they do work well for what they do or they would never have gained any traction. Python I believe, has more than amply proved that it CAN do the job regardless of the versatility the coder asks it to do... The name given to that language is completely arbitrary. Python, from the greasy side, may well be the best parts of each mix of languages that start with bash/lisp and going upward until we have the next great thing. Have we a next great thing waiting in the wings? I am reminded of that old saying about beauty being defined in the eye of the beerholder. ;-) Besides there is probably a Python 4 waiting to pounce on any upstarts that are in effect a wash, rinse, and repeat of an old language. ;-) Cheers, Gene Heskett -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Genes Web page <http://geneslinuxbox.net:6309/gene> -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/201504140746.57322.ghesk...@wdtv.com
