I think I will stick to my book "learning python the hardway" for now.
I recommend looking at mechanisms that the underlying system does already offer. There is lots to learn about file descriptors and their power. Then there is the whole topic of IPC. As soon as you know how to effectively stick together things like fork(), mkfifo(), pipes and such, you'll naturally split things into small processes communicating with each other. This is part of the Unix philosophy and makes things a little more maintainable.
Apart from that, if you're into maintaining applications, I recommend reading man-pages about the most important syscalls (read(), write() and open() are a great thing to start at) and strace a few small things like cat file to see what exactly happens on the system. This enables you a whole new world of understanding how the stack below works and what to avoid in your application (e.g. not putting vital assets in a distributed filesystem). If you're done with that, you can hopefully work effectively with servers in an ops way.
One example would be: oh, the system is kinda down, what happened, while there's an rm -rf running on a large deeply nested cache directory. The not-so obvious first step would be SIGSTOP-ing the rm so you buy yourself some time. Then you could e.g. just mv the directory somewhere else and at the other place delete files slowly (25 files per second is usually not noticable).
If you, after that, write an application, you might want to get some broad overview of tech that's out there that you can just plug in between your components to get much more performance.
Examples include: Varnish, nginx for TLS offloading, *SQL replication and reading from slaves, Maxscale to enhance the read-thing.…
Career change decided program love and hate it. Can be frustrating. Learning python the hard way by Zed Shaw. Wonder if I'll ever get a job or be good enough for one. Yeah of course I am :)
Firstly, can you read minds. I was going to ask about config and ini files. As when ever I go on git hub I see .py and all this other stuff and frankly don't have any idea what to do with it.
Ok, firstly Thank you, I really appreciate that you took the time to respond. Secondly, that scenario sounded pretty cool =). Can you imagine it what it will be like working with the new AI chip... Anyway, I am getting off topic. Ok, I'll go from the top and get to it. By underlying system mechanism as in how software works with hardware? I learnt somewhere that RAM is an array and cache holds the last used memory pointer (I think) to the RAM. Hmmm...think I'll start here bottomupcs.com/file_descriptors.xhtml
Career change decided program love and hate it. Can be frustrating. Learning python the hard way by Zed Shaw. Wonder if I'll ever get a job or be good enough for one. Yeah of course I am :)
Career change decided program love and hate it. Can be frustrating. Learning python the hard way by Zed Shaw. Wonder if I'll ever get a job or be good enough for one. Yeah of course I am :)
I recommend looking at mechanisms that the underlying system does already offer. There is lots to learn about file descriptors and their power. Then there is the whole topic of IPC. As soon as you know how to effectively stick together things like
fork(),mkfifo(), pipes and such, you'll naturally split things into small processes communicating with each other. This is part of the Unix philosophy and makes things a little more maintainable.Apart from that, if you're into maintaining applications, I recommend reading man-pages about the most important syscalls (
read(),write()andopen()are a great thing to start at) andstracea few small things likecat fileto see what exactly happens on the system. This enables you a whole new world of understanding how the stack below works and what to avoid in your application (e.g. not putting vital assets in a distributed filesystem). If you're done with that, you can hopefully work effectively with servers in an ops way.One example would be: oh, the system is kinda down, what happened, while there's an
rm -rfrunning on a large deeply nested cache directory. The not-so obvious first step would beSIGSTOP-ing thermso you buy yourself some time. Then you could e.g. justmvthe directory somewhere else and at the other place delete files slowly (25 files per second is usually not noticable).If you, after that, write an application, you might want to get some broad overview of tech that's out there that you can just plug in between your components to get much more performance.
Examples include: Varnish, nginx for TLS offloading, *SQL replication and reading from slaves, Maxscale to enhance the read-thing.…
Firstly, can you read minds. I was going to ask about config and ini files. As when ever I go on git hub I see .py and all this other stuff and frankly don't have any idea what to do with it.
Ok, firstly Thank you, I really appreciate that you took the time to respond. Secondly, that scenario sounded pretty cool =). Can you imagine it what it will be like working with the new AI chip... Anyway, I am getting off topic. Ok, I'll go from the top and get to it. By underlying system mechanism as in how software works with hardware? I learnt somewhere that RAM is an array and cache holds the last used memory pointer (I think) to the RAM. Hmmm...think I'll start here bottomupcs.com/file_descriptors.xhtml
Btw,Do you have any good reference books or web pages for learning?
tldp.org/LDP/lpg/node18.html found this. Which I think will be useful. I'll also check out man pages