ELI5: Guys, I have a few questions about programming and FreeBSD

1- What would be the best way to learn posix with focus on BSD's, shell and Perl?
2- Is there another language for sysadmins besides shell and Perl?
3- What is the best way to navigate the FreeBSD source code?
4- What are the languages most used in FreeBSD development?
PS.: I'm not a developer or a programmer, just a script kiddie trying to discover new toys ;-)
 
1- What would be the best way to learn posix with focus on BSD's, shell and Perl?
2- Is there another language for sysadmins besides shell and Perl?
3- What is the best way to navigate the FreeBSD source code?
4- What are the languages most used in FreeBSD development?
PS.: I'm not a developer or a programmer, just a script kiddie trying to discover new toys ;-)
1. I'd think that a good approach to that would be to learn about BSD's, with a focus on POSIX compliance. Yeah, a bit different with how it was phrased in the OP... What I mean by that is, learn about a BSD feature, and ask if the implementation is POSIX-compliant. As in, figure out which parts of the POSIX standards apply to that BSD feature, and how they apply.
2. Straight C comes to my mind. Also, Python, sed, and awk.
3. Start in /usr/src. If you installed kernel sources (source.txz in the installer), that's where the FreeBSD source code lives. Well, it will be the code of whatever you installed. If you read the Handbook, it will provde more detail.
4. Offhand, I'd say C - most of the files I looked at in FreeBSD's cgit kernel repo are definitely in C.

Try compiling the kernel and to time that, maybe?
 
1- What would be the best way to learn posix with focus on BSD's, shell and Perl?
I know that "books" (paper with printing on it, bound on one edge) is getting old fashioned. But about 20-25 years ago, O'Reilly had a really good set of manuals about Posix standards. I had the ones for the C library, real-time (threads + async IO Posix.4, book is by Bill Gallmeister) library at home, and used them as reference manuals when programming. If you only read documentation that's tuned to Posix instead of BSD- and Linux-specific man pages, you will likely end up with Posix-compliant code.

There are also Posix standards for the shell, including standard utilities such as sed and grep (don't remember about awk).

2- Is there another language for sysadmins besides shell and Perl?
Actually, the primary language is shell, because it is always there (on any machine, even in single user mode). It is also what a lot of the system's infrastructure is coded in. A good programmer and good sys admin has to be quite conversant in shell (and preferably not tcsh or bash, but real sh).

I would describe Perl more as a rapid development, interpreted programming language, not a scripting language. Today, a lot of that function is also taken by Python and Ruby.

Most sys admins do not program in C.

3- What is the best way to navigate the FreeBSD source code?
The kernel source code? Start by reading the "black daemon book": Design and Implementation of the FreeBSD, by Kirk McKusick et al. Only after reading the book, and understanding the structure, does it make sense to go into the source.

But the code itself is not very enlightening. You don't see the design principles and overall architecture by looking at lines of code, at least not right away.

4- What are the languages most used in FreeBSD development?
For the kernel itself, most utilities (sed/grep/...), and a significant fraction of packages: C. But as said above, also significant amount of sh.
 
Giving my answer to all these points, there will probably be some repetition, sorry ;)
1- What would be the best way to learn posix with focus on BSD's, shell and Perl?
"Learn POSIX" is a bit difficult to define, because POSIX is a standard for operating systems, including all sorts of things like standard APIs for e.g. files, sockets, IPC, threads, a standard set of tools with defined options and behavior, a standard for the shell, etc. Note that perl is not part of POSIX (read: you can't expect perl to be available on any POSIX-compliant system), but offers a module to access POSIX APIs.

So, given that, I'd say starting to better learn the shell (standard POSIX/bourne shell, NOT extensions like e.g. bash and certainly not completely different shells like e.g. csh) is probably a good way to "learn POSIX". If you want to go deeper, write C programs using the POSIX APIs (they're defined in terms of C).

2- Is there another language for sysadmins besides shell and Perl?
Use whatever does the job. A sysadmin normally writes scripts specific to his scenario, so there's no need for portability, it only needs to work on that one machine. Of course, if you want portability to other POSIX systems, the shell (/bin/sh) is your primary choice. You can't use perl (as explained above), you may use awk which is also specified by POSIX.

3- What is the best way to navigate the FreeBSD source code?
I don't really understand that question. What's the purpose of "navigating" here? You can for example just browse the source tree on cgit: https://cgit.freebsd.org/src/tree/

4- What are the languages most used in FreeBSD development?
Clearly C. Both the kernel and FreeBSD's own userland tools are written in C. If you add third-party software that's integrated in base (e.g. llvm), you will also find C++.

Second place (with quite some distance) is most likely shell. E.g. all the init-scripts are written in shell.
 
...
3- What is the best way to navigate the FreeBSD source code?
...
As for the purely technical aspects of looking at C code, you can run exctags at the root of the local source tree:
exctags -R --langmap=c:.c.h .
, then run gvim and navigate through the functions with Ctrl-] , Ctrl-T
 
There is some nice shell code to look at in /usr/share/bsdconfig and /usr/local/share/poudriere.

I use 'findgrep' to search for stuff in files. It's a wrapper to the command find $dir -type f -name $name -exec grep $opt '$pattern' {} \;
 
2- Is there another language for sysadmins besides shell and Perl?
Ruby. Ruby is the AFAIK only script language that is truly OO.
Perl, python etc had OO only grafted upon at a later time - and that's how it feels when using it. I once had to write Perl OO, and it was ugly. With Ruby I learned how OO is supposed to work, and why (and when) it makes sense.

In some way Ruby is similar to FreeBSD: there is beauty in the philosophy right from the beginning. Usually when scripting something, you do the 20% to put the idea into code, and then you do (or sometimes do not) the other 80% to handle the corner cases. And in that phase the code tends to grow significantly. With Ruby the code often rather shrinks at that point, because the language itself promotes elegance.

Ruby is japanese, and there is some similarity to japanese lifestyle, where many things are done as an act of meditation, with much care for the details. This is not so much a language for fast time-to-market production and "just make things work". And as You seem to be not foreign to the arts of the mind, You might give it a try.
 
1. I'd think that a good approach to that would be to learn about BSD's, with a focus on POSIX complian
I think POSIX is over-rated.
Berkeley was long before POSIX. POSIX was then an attempt to tame the uncontrolled growth when everybody designed just what they thought cool - but a lot of POSIX is descriptions of how BSD works. POSIX did never do development, they're just a standardization shop..

That doesn't mean you shouldn't adhere to POSIX. You just shouldn't consider it the supreme wisdom
 
I think POSIX is over-rated.
I don't think so. I have some code using strictly only POSIX (which includes e.g. select() for I/O multiplexing, which of course has scalability issues, but typically works fine for up to 1000 concurrent clients), and the great thing about that is: It just works on any POSIX-compliant system, no need to "port" anything.
Berkeley was long before POSIX. POSIX was then an attempt to tame the uncontrolled growth when everybody designed just what they thought cool - but a lot of POSIX is descriptions of how BSD works.
A lot, sure, but BSD wasn't the only source...
they're just a standardization shop..
As is the ISO regarding C (and C++). This is valuable. Standards can be relied on. I've read for decades how "C is dead", and still, it isn't.
 
from sh(1)

DESCRIPTION
The sh utility is the standard command interpreter for the system. The current version of sh is
close to the IEEE Std 1003.1 (“POSIX.1”) specification for the shell. It only supports features
designated by POSIX, plus a few Berkeley extensions. This man page is not intended to be a tutorial
nor a complete specification of the shell.

Who knows what these "few Berkeley extensions" are?
 
Who knows what these "few Berkeley extensions" are?
Well, there are some features for interactive use like e.g. a nice command history. But TBH, I don't know whether there are any extensions to the scripting language. When attempting to write portable POSIX shell scripts, you should always have a look at the POSIX specs when in doubt...

At least, it's no comparison to the tons of "extensions" provided by bash ;)
 
Large-scale operations these days are mostly about Terrible (Terraform + Ansible), if not Kybernetes. A useful language for that is Golang. Python's limitations really opened a gap for Go.
 
As is the ISO regarding C (and C++). This is valuable.
For a developer, yes, maybe. For a sysadmin I doubt it.

And then, it is "valuable" in a different sense, too: the standardization shops take the material others have invented, melds it into a standard, only to then tell those who have originally created the ideas that they are "compliant" - but only if they pay for that.
 
For a developer, yes, maybe. For a sysadmin I doubt it.
Everyone will profit from software that "just works" on any system. The main problem with POSIX is that it doesn't "catch up" quickly enough, see my example above: If you want to scale to a huge number of concurrent clients, the APIs specified by POSIX are not an option, instead you must use whatever your platform provides (kqueue on FreeBSD, epoll on Linux, IO-completion-ports on Windows, etc ....). That's exactly the kind of situation POSIX wanted to avoid :(
And then, it is "valuable" in a different sense, too: the standardization shops take the material others have invented, melds it into a standard, only to then tell those who have originally created the ideas that they are "compliant" - but only if they pay for that.
The standard is freely available, aiming for compliance doesn't cost you anything. If you want to have your compliance certified, then you pay. I see no problem with that...
 
The standard is freely available, aiming for compliance doesn't cost you anything. If you want to have your compliance certified, then you pay. I see no problem with that...
That's basically what I said.
The problem it's mainly the same as with the church: everybody is free to follow the commandments, but if you want salvation, you have to pay.
I don't like such schemes in general, because they tend to produce authorities which are then believed without questioning.
 
No need to escalate this further. I don't know when exactly this started, but nowadays, many people "feel" disagreement as a personal insult, if not even "violence". It's enough to state how this doesn't make any sense. On the specific topic: Noone would ever force POSIX (or any other open standard) upon you, let alone using violence. You're free to do whatever you want. You may benefit from standards if you adhere to them. And that's all about it :rolleyes:
 
Bringing religion to the table, well, I won't discuss about "feelings".
Why limit yourself? ;)

I'm in favor of systems theory. Systems theory has tools to understand e.g. a software product. Or a computer. But one can also analyse a shop or a business, and do management consulting - with the very same tools (I did that for a living). One can also analyze a biospehere, or even an entire planet - with the very same tools. One can analyze a society, an ideology or a religion - with the very same tools.
These things are not so different from each other as one might suppose.
 
Large-scale operations these days are mostly about Terrible (Terraform + Ansible), if not Kybernetes. A useful language for that is Golang. Python's limitations really opened a gap for Go.
? Didn't think that Terrible could be expanded like THAT... I see it being the butt of many more jokes about large-scale operations...
 
Back
Top