Sujet : Re: Python (was Re: I did not inhale)
De : david.brown (at) *nospam* hesbynett.no (David Brown)
Groupes : comp.unix.shell comp.unix.programmer comp.lang.miscDate : 21. Aug 2024, 16:27:04
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <va5108$3tmmd$1@dont-email.me>
References : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
User-Agent : Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0
On 21/08/2024 12:26,
Muttley@dastardlyhq.com wrote:
On Wed, 21 Aug 2024 11:10:53 +0200
David Brown <david.brown@hesbynett.no> boringly babbled:
If you are writing network software for Linux, how is it relevant to
learn about the sound API, or the more advanced filesystem API's ? If
You don't, but the subsystems don't exist in isolation, there's a lot of
overlap. Eg network sockets use a lot of the same API functions as files
(eg: read, write, fcntl, ioctl) so understanding may well help to understand
the other.
Sure.
Of course understanding /some/ of this is essential for a lot of tasks. And understanding a bit more can be /useful/. My argument is against this idea that you need to learn it all.
Let's take an example. In my line of work, I use UARTs a lot - I've probably used UART's on 20-30 different microcontroller families, as well as external UART chips, bit-banging in software, with polling, DMA, interrupts, RTOS abstractions, SDK routines. I've used them a /lot/.
Trying to understand the Linux documentation for UARTs is a nightmare. They are horrendous - the APIs, structs, flag sets, etc., are a vast jumble of crap for handling terminals that haven't been seen outside a museum for 50 years, long before Linux was conceived. Trying to get the right selection of API calls, struct setups, etc., simple raw UART access to send and receive characters can take many days of studying documentation of questionable standard, trial and error, and guesswork. A good "Programming Linux" book /might/ help - but it might be out of date. Snippets from googling, however, /does/ get the job done - you can find examples, try them out and see what works, and in a few hours I had everything running.
Even better, of course, is to ditch C and use Python - "pyserial" does it all, simply and cleanly. (And the same code works on Windows, if that happens to be useful - though Windows picks pseudo-random names for serial ports and has nothing like udev rules.) But for this particular customer, it had to be in C (well, C++, but that's a minor detail).
Would that task have been easier if I'd studied the details of fcntl, ioctl, and other calls that were needed for the task? No, not at all. Would "knowing POSIX" have helped? Would reading some old book on Linux programming have helped? No. (I /have/ read books on Linux programming.)
But a rough idea of some of the concepts of Linux development was useful. Knowing /something/ about the OS is helpful.
you are writing a gui program with QT, why should you be interested in X
APIs or POSIX threading and file handling - you'll be using the QT
libraries and APIs for graphics, threading and file handling.
Not necessarily.
I have not suggested, or even hinted, that all you need is "core C" -
what you need is the knowledge that is relevant to the task at hand,
regardless of the OS, language, or whatever.
Its certainly the impression you gave.
I can't imagine how you got that from my posts.