Re: sysadmin qualifications (Re: apt-get vs. aptitude)
On 10/16/2013 8:19 AM, berenger.morel@neutralite.org wrote:
Le 16.10.2013 03:25, Jerry Stuckle a écrit :
Ah, but you are more than a "simple user".
I guess so. I am not even a TV user anymore in fact, but that's not the
question.
The point is that I can hardly consider a programmer to be a simple user
of a computer, because when you write a program, you will probably have
to know how to install it, and so know the system you target. Because
it's the programmer who knows what the program needs. Root access maybe?
Or will it listen on a port? Which configuration files will it needs?
Which installed lib?
Those are not the work of the admin, even if the admins can be able to
understand about what the programmer is talking, so that they can then
know when there is a problem how to fix it.
The programmer may require specific privileges (in Linux they would be
root privileges), but it is the admin who grants those privileges.
There is no way a programmer should be allowed to define privileges on
another system. Hackers would have a heyday.
Just like I
don't program in assembler (for Intel or Motorola MPUs or IBM
mainframes), although I could do any of them still.
I do not do it either. But by being able to do so, I can understood why
some instructions will slow down programs more than others. Of course,
early optimization is root of evil, but I know that if I have to
divide/multiply integers by a power of 2, I can use the << and >>
operators. It also helps me when I need to debug programs, even if I do
not have the source code.
Pointers have nothing to do with assembler.
Pointers are memory addresses, which are very important in asm. So, yes,
knowing asm helped me a lot to understand C pointers. I understood them
without any problem, unlike my classmates. And those guys were, as me,
coming from electronic studies, so they were supposed to know basics
about processors.
Yes, my C/C++ students sometimes had initial problems with pointers,
but some real-world (non-programming) examples got the point across
quickly and they grew to at least accept them, if they didn't like
them. :)
I only know few people who actually likes them :)
I liked them too, at a time, but since I can now use standard smart
pointers in C++, I tend to avoid them. I had so much troubles with them,
so now I only use them for polymorphism and sometimes RTTI.
I hope that someday references will become usable in standard
containers... (I think they are not because of technical problems, but I
do not know a lot about that. C++ is easy to learn, but hard to master.)
Good design and code structure eliminates most pointer problems; proper
testing will get the rest. Smart pointers are nice, but in real time
processing they are an additional overhead (and an unknown one at that
since you don't know the underlying libraries).
C is not the only
language with pointers
Of course. They all need to use them if they offer dynamic stuff, but
they try to hide them. Is it the good solution or not? I do not know,
but if yes, I wonder why most games are written in C or C++? I think
that guys who write them knows what is memory, and how it works. I hope
for them at least.
C was never meant to be an applications language - K&R designed it
for creating OS's (specifically Unix). But because of that design, a
good programmer can write code that is smaller and faster than with
other languages (except assembler, of course).
Yep. It is designed to be an efficient language, allowing to give people
full control on their tool, in a portable way. This is risky, because
you can shoot your feet, but taking that risk is needed to have
efficient softwares.
Plus, in an OS, there are applications. Kernels, drivers, and applications.
Take windows, and say honestly that it does not contains applications?
explorer, mspaint, calc, msconfig, notepad, etc. Those are applications,
nothing more, nothing less, and they are part of the OS. They simply
have to manage with the OS's API, as you will with any other
applications. Of course, you can use more and more layers between your
application the the OS's API, to stay in a pure windows environment,
there are (or were) for example MFC and .NET. To be more general, Qt,
wxWidgets, gtk are other tools.
mspaint, calc, notepad, etc. have nothing to do with the OS. They are
just applications shipped with the OS. They run as user applications,
with no special privileges; they use standard application interfaces to
the OS, and are not required for any other application to run. And the
fact they are written in C is immaterial.
For Debian, in it's standard installation (I insist on the standard
installation, the one I never do), it will come with the gnome DE. I do
not know the tools it provides, but they are probably applications, too.
And it is part of the Debian OS.
Maybe your "standard installation" comes with Gnome DE. But none of my
servers do. And even some of my local systems don't have Gnome. It is
not required for any Debian installation.
I know, OSes have evolved since the first UNIX. But languages and the
libs available in them too. C was invented 40 years ago. I have seen
some of the codes which were valid at that time, and it really had great
enhancements (imo).
Yes, it has matured quite a bit; a good thing.
But all of this have nothing related to the need of understanding basics
of what you use when doing a program. Not understanding how a resources
you acquired works in its big lines, imply that you will not be able to
manage it correctly by yourself. It is valid for RAM memory, but also
for CPU, network sockets, etc.
Do you know how the SQL database you're using works? Do you know how
the network works? Do you even know if you're using wired or wireless
networks.
Good programmers can write programs which are independent of the hardware.
A bigger advantage is
the code is machine-independent.
Which is why C and his little brother C++ are probably the reason of my
switch to linux. See, if those languages were never used to write
applications, there would not be so many portable and efficient one, and
so I would have probably stayed to windows (and not annoying people on
that list :p), instead of changing my tools one after one until I was
able to change the OS itself without changing any tool.
I don't have any portability problems with any of the C programs I write
for Unix. They run on PC's and ARM devices (completely different
instruction sets) with no change, for instance.
And my Java programs run unchanged not only on those, but on non-Linux
systems such as Windows and Mac.
But I do not think that this one is the biggest advantage of C. other
ones compete a lot: efficiency, lot of good libraries and ISO standard.
I strongly doubt that C were chosen for portability to write winAPI.
I never said it was. But you can write portable C code which has
graphical interfaces and is cross-platform also, using GTK+.
But it doesn't require knowledge of underlying memory
access to use pointers.
I've taught many C and C++ classes over the
years (I used to do corporate programmer training), and never once did
we get into how memory works.
I wonder how you taught how to use them, so. Just saying that they are
variables which indicates where in memory are located other variables?
And people just accept that?
Nope, real-world examples unrelated to programming.
The classic one with the street, maybe. It is a good one to explain how
memory works, too.
I use several, depending on the students. Sometimes I even use more
than one in the same class. But how memory works is immaterial, beyond
the fact every byte has an address.
Do you worry, for instance, how malloc() works? I do, because I've had
to write specialized versions of it. But to a programmer it's
immaterial how it works; all that's important is they make a request and
get an address or NULL back.
Those who never programmed in languages
with pointers, i.e. COBOL, had a little trouble getting used to them,
Yes. It is what I said. General culture helps to learn new things
faster. Not needed, but helps.
Actually, in this case, new programmers pick it up faster than
experienced programmers. The same is basically true with OO
programming techniques - the longer someone has been using functional
programming, the harder it is for him/her to make the jump.
I did not noticed the same thing in the lessons I had.
Well, I can not really say that I was an experienced programmer at that
time, but when I learn C, and so pointers, I had QBasic and asm x86
knowledge, and never had any problem with pointers. To be exact, I was
already using them (but not with memory allocation at that time) in my
first language, qbasic, to access graphical memory in mode 13h.
When I came to C, I learned in the same time asm x86, and really had no
problem with pointers.
But when I reached universities-like studies (3 years after my first
steps), I have seen that those guys, with for most of them electronic
knowledge, had a lot of troubles with pointers. Except the few which
already had programming knowledge.
About OOP... well, I had real problems understanding it. And I was one
in the less bad of the entire class in programming.
The only thing which made me understanding it were real programming and
reading on the web. But I have to say that it was 2-years only studies,
so maybe it is the reason.
And I can remember what exactly allowed me to understand the basics of
OOP. If was certainly not the translated book "C++ for dummies" that I
bought (I recommend to never buy it, except maybe if you are from USA.
It is full of references to USA's stuff, and the translation is dirty)
but the tutorial I have found on the web which explained how to
implement OOP stuff in C. And I would never say that this allowed me to
fully understand OOP, since I am still learning a lot in that domain. I
doubt that I'll end learning about that.
I've found I can teach the basics of OO and C++ in a week. But it takes
up to a year of constant use for people to really start thinking in OO
terms. Once they do, however, they do much better in many programs (OO
is not for everything).
What gets me are people who read a little about OO but don't really
understand it. However, since they read a bit, they are "experts".
There seem to be a lot of those on the internet.
Plus, here, we are not discussing about programming, but about
networking, so I think minimal knowledge of network stuff and some
electric basis can be useful ;)
Not really. When you're troubleshooting network problems in low
level code, it is important. Otherwise it's no more important than
knowing how everything in your TV works.
So, you are able to do right choices when you buy hardware without
knowing how it works? Interesting, but I doubt it.
By right choices, I do not mean "buying the one with the highest perfs",
I mean "buying the one which fit your exact needs".
Buying hardware is different from programming. There are millions of
programmers in the world who never bought a bit of the hardware they
are working on.
They are not even able to choose their tools? They do not know what can
be the interest of multi-core CPU for programming?
It seems really strange to me.
Not at all. When you work for a company, especially larger ones, you
use what you are given. And many of those programmers are working on
mainframes. Have you priced a mainframe lately? :)
Even those who are working on PC's use what they are given. It is the
responsibility of the IT department to know what they require, and
supply accordingly.
If you have no understanding about what the hell is a parasite, you will
always buy armored cables, even if you only need a small piece of cable
far from any parasite generator. Waste of money.
Do you mean a parasite generator, or a parasitic generator?
Excuse my bad English, I meant parasitic generator I guess, if it is the
one which means a hardware generate parasites.
Never seen hardware generate parasites. I have seen a lot of
transmitters generate parasitics, though.
Jerry
Reply to: