Tittle basically says it all. I'm personally an extreme novice at C, but I already feel as though it has helped my understanding of Linux and how its commands actually work behind the scenes. I'm a person which loves to learn how things really work, I can't really accept that "that's just how it works" so C has been pretty fun in terms of that aspect as well. What I love about C is the same thing that I love about maths, there's very little wiggle room for vague answers as to how stuff functions. Going from Bash to C has been like going from driving an automatic to driving a manual. Well to make a better analogy it's like going from driving an automatic to building a car from scratch.
Some decades ago I studied the Kernighan/Ritchie "The C programming language"
I cannot say I fell in love with C; it was rather a hacking, often a mistake produced a segmentation fault.
On the other hand I was excited how close it is to the machine's architecture, making it blazing fast and the preferred language when writing a kernel.
As a side effect, I got to love the Unix philosophy: keep things simple and universal.
This philosophy is sometimes neglected in Linux (and Opensource) development; things became too specialized and have too many dependencies.
1 Like
Hello,
An interesting question ! In my case, perhaps surprisingly, I never formally learned C, or C++. When I started University, the Computing Science department in question had just changed that year from teaching Pascal to 1st and 2nd year students and C++ from 3rd year onwards, to starting with Ada for the first two years, and then finishing up with Java in the final years. So C and C++ were never covered, and in my career I never had the need to actually learn them, as I went into systems administration rather than software development.
Of course, as part of sysadmin work you inevitably from time to time will have to deal with issues that involve reading or modifying source code. In my own spare time I have periodically leafed through K&R, and have picked up enough C to be able to tweak the occasional bit of source code here and there when I had to change the behaviour of something, or fix a local bug. But I wouldn't describe myself as a programmer - my C experience has purely been with fixing issues with existing code, rather than writing things from scratch myself.
So in my own career as a UNIX (and then later Linux) sysadmin, neither C nor C++ has featured particularly heavily. It's cropped up every now and then, but the main skills for me have been mastering the operating systems I've worked with, learning how to use the shell and write shell scripts, and also putting a lot of time into the so-called "soft skills" - being able to work well and communicate effectively with others and think critically goes a very long way in any field of work.
In summary then, if you're finding learning C or C++ helpful, then that's great, and you should absolutely carry on with that - it will definitely help your understanding of how things work under the hood. But equally if you find yourself drifting instead towards other things or becoming less interested in these languages over time, that's not by any means going to be an impediment towards a career in systems administration.
1 Like
To what degree would you say that learning C/C++ has helped you in terms of understanding Linux?
The answer to this question totally depends on what you want to "understand" about Linux.
Are you going to write kernel patches? Develop Linux device drivers? Develop code using system calls? Then of course C is basic and essential.
Are you going to use Linux as a system admin? Application management? Web developer? If so, there are better ways to spend your time (if limited) versus learning C programming.
FWIW,
I started my unix career on HP-UX for Motorola in Schaumburg, Illinois. At that time, I was tasked to write code for the Motorola radio assembly line to manage all aspects of automated testing and storing all the results in a (Progress) database. For that first task, I had to learn:
- KSH
- HPIB and Rocky Mountain Basic (RMB)
- C and HPUX system calls including interprocess communications (IPCs) all in
C - Progress database system calls, also in
C.
It was a very stressful time! That's a lot to learn OJT with no prior unix experience on an assembly line where a day of downtime costs millions of dollars!
I would have never done that "just for the sake of learning".... haha. That's too much stress to learn OJT and the only engineer (and only coder) on the project.
Yes, all that knowledge has been very helpful over the years, especially creating my own client-server applications between the test gear code and the database. You learn a lot about networking writing your own client-server code.
In another contract assignment in those days, I had to write a user front-end for security reasons in front of a real-time, production global oil trading platform in a super secure data center (secure like a bank). I had to learn C even more as I wrote all the UI code in MOTIF at the time.
I have done even more interesting C programming projects as a contractor, and even at that time, I was never a good C programmer; I simply managed to make it work, using my skills to learn new things quickly as needed OJT.
To what degree would you say that learning C/C++ has helped you in terms of understanding Linux?
After a short time walking down memory lane on small number of projects in the 1980s, I can say that using C OJT was really helpful in all aspects of my future career, both as systems engineer, cybersecurity person, systems admin and as a software developer.
Nothing is better for learning ( in my view) than being tossed into a battle, OJT, working on real projects. Just learning "for the sake of it" is not nearly as useful as OJT projects under real deadlines, stress (and getting paid for it).
That's my 2 cents. Hope that helps.
2 Likes
I for one found that having 3 things helped me solve problems.
Maths - good for almost any problem
C - reading C code inside any project or problem helps so much
General knowledge - that you acquire over time
I have worked on so many systems and over so many years that I
should write a book.
I read manuals cover to cover.
Read a manual on tape drive - learned about other things such as
The tape drive has 3 heads - erase , read/write, and CHECKSUM.
It pumps out a magnetic field of say 7,000 Oersted.
Usually, magnetic field strength is defined by the unit of Oe・A/m ( Oersted・Ampere/meter ).
And when it is defined by flux density, the units of G (Gauss) or T (Tesla) are used.
eg.
IBM staffer in the Computer room working on a problem
Tapes are written and they read back fine but a couple of weeks later they spit the dummy
(you cannot rely upon them for backups). The technician was working on this problem for
days. I spoke to him and identified a possible solution. They had been using a new batch
of tapes. I checked and they were specified as 10,000 Oersted. Bingo.
The tape drive max was 7000 but the new tapes were only reliable when written by 10,000.
So get to know a lot about a lot of things -
read the stories about problems
and how they were solved.
QUORA should have more stories entitled PROBLEMS and FIXES.
My advice is to look for the best of the best , tools and applications.
I think I know a lot of stuff - mainly because I do a lot of reading
both opinions and trying things out for myself.
I have used Charon because I had to find a better way (& maybe the only way)
to run VAX/VMS software on PC level hardware.
I have used my knowledge and C to solve (write or modify/fix) problems
that have been (not a problem - until ....).
I ported C software to various systems - including VAX/VMS - for a Financial
software company. Porting is not easy but it is not beyond the scope of
many people who are prepared to read about Knuth's work.
So the simple answer is -
what do you like doing.
what crops up that you have to fix.
what administration tasks can you avoid - if you are critical in some other role.
what experiences do you have that would make you a good team-leader.
I have worked with various DATABASES - each one was interesting and
critical to the owner.
Which DB's do I like - or - some times it is, which ones are hard to work with.
As a followup note, C versus C++, my experience is that learning object-oriented programming languages, both compiled and interpreted, is the "way to go".
Compiled
CC#
Interpreted OO Recommedations
-
Javascript, and -
Python, or -
Ruby(fully OO)
This post is just a tiny, quick glimpse into my off-hand idea regarding "learning C/C++". Generally, (today) I program only in OO and mostly in Ruby because of the well know "great powers" of OO programming.
If I had to start learning today, I recommend C++ over C because of the OO nature of C++.
Read: