Re: sysadmin qualifications (Re: apt-get vs. aptitude)
Le 17.10.2013 21:57, Miles Fidelman a écrit :
berenger.morel@neutralite.org wrote:
Le 16.10.2013 17:51, Jerry Stuckle a écrit :
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).
Depends on the smart pointer. shared_ptr indeed have a runtime cost,
since it maintains additional data, but unique_ptr does not, afaik, it
is made from pure templates, so only compilation-time cost.
You guys should love LISP - it's pointers all the way down. :-)
I do not really like pointers anymore, and this is why I like smart
pointers ;)
So, what you name an OS is only drivers+kernel? If so, then ok. But
some people consider that it includes various other tools which does
not require hardware accesses. I spoke about graphical applications,
and you disagree. Matter of opinion, or maybe I did not used the good
ones, I do not know.
So, what about dpkg in debian? Is it a part of the OS? Is not it a
ring 3 program? As for tar or shell?
Boy do you like to raise issues that go into semantic grey areas :-)
Not specially, but, to say that C has been made to build OSes only, you
then have to determine what is an OS to make the previous statement
useful. For that, I simply searched 3 different sources on the web, and
all of them said that simple applications are part of the OS.
Applications like file browsers and terminal emulators.
Without using the same words for the same concepts, we can never
understand the other :)
No, but I do understand why comparing text is slower than integers
on x86 computers. Because I know that an int can be stored into one
word, which can be compared with only one instruction, while the text
will imply to compare more than one word, which is indeed slower. And
it can even become worse when the text is not an ascii one.
So I can use that understanding to know why I often avoid to use
text as keys. But it happens that sometimes the more problematic cost
is not the speed but the memory, and so sometimes I'll use text as
keys anyway.
Knowing what is the word's size of the SQL server is not needed to
make things work, but it is helps to make it working faster. Instead
of requiring to buy more hardware.
On the other hand, I could say that building SQL requests is not my
job, and to left it to specialists which will be experts of the
specific hardware + specific SQL engine used to build better requests.
They will indeed build better than I can actually, but it have a time
overhead and require to hire specialists, so higher price which may or
may not be possible.
Seems to me that you're more right on with your first statement. How
can one not consider building SQL requests as part of a programmer's
repertoire, in this day and age?
I agree, it is part of programmer's job. But building a bad SQL request
is easy, and it can make an application unusable in real conditions when
it worked fine while programming and testing.
Do you know how
the network works? Do you even know if you're using wired or
wireless
networks.
I said, basic knowledge is used. Knowing what is a packet, that
depending on the protocol you'll use, they'll have more or less space
available, to send as few packets as possible and so, to improve
performances.
Indeed, it would not avoid things to work if you send 3 packets
where you could have sent only 2, but it will cost less, and so I
think it would be a better program.
Probably even more than that. For a lot of applications, there's a
choice of protocols available;
Ah, did not thought about that point, too. Technology choice, which is,
imo, part of programmer's job requires understanding of their strong and
weak points.
For now, I should say that knowing the basics of internals allow to
build more efficient softwares, but:
Floating numbers are another problem where understanding basics can
help understanding things. They are not precise (and, no, I do not
know exactly how they work. I have only basics), and this can give you
some bugs, if you do not know that their values should not be
considered as reliable than integer's one. (I only spoke about
floating numbers, not about fixed real numbers or whatever is the
name).
But, again, it is not *needed*: you can always have someone who says
to do something and do it without understanding why. You'll probably
make the error anew, or use that trick he told you to use in a less
effective way the next time, but it will work.
And here, we are not in the simple efficiency, but to something
which can make an application completely unusable, with "random"
errors.
As in the case when Intel shipped a few million chips that
mis-performed arithmatic operations under some very odd cases.
No need for a problem in the chip. Simply doing things like "0.1f ==
1.0f/10.0f" in a moment you do not take care can cause problems. I think
that compilers warn about that however.
But now, are most programmers paid by societies with hundreds of
programmers?
(and whether you actually mean "developer" vs. "programmer")
I do not see the difference between those words. Could you give me the
nuances please? I still have a lot to learn to understand English for
precise terms.
And, again, just a guess, but I'm guessing the huge percentage of
programmers these days are writing .NET code on vanilla Windows
machines (not that I like it, but it does seem to be a fact of life).
A lot of people also seem to be writing stored SQL procedures to run
on MS SQL.
Windows actually provides a stable environment, very good programming
tools ( visual studio is a really good IDE ), and when you write for it,
you know that most computers will be able to run your program.
Arguably, it is also easy to install stuff on windows.
I strongly disagree with that for most current linux-based OS, but I
remember my first installs of Debian. I was used to consoles, but I had
no knowledge of what tools I had to do anything, and no graphical
interface to learn basics from the Internet. Debian without Internet was
not usable for beginners at that time (installer provided woody/potato
at that time IIRC. I had my first successful use of Debian with Etch...
or was it Lenny? I only know that I know all those version names for a
reason or another, don't remember completely). So, that linux-based
reputation is not stolen, and since it is not used a lot, it has not
been reduced unlike the windows' one to be unstable and full of security
holes. And when people asks me what I am running with, I have to reply
it is a Debian, and insist on the fact I have heavily customized it to
avoid frightening them.
Those are probably the reasons why people programs with Microsoft's
"closed" technologies. But now, MS can argue that .NET is available on
linux too, and that SQL is standard ( but not procedures which are an
important part, of course ).
We can just hope that windows usage will continue to very, very slowly
regress to have more portable softwares.
I expect that there are NOT a lot of people writing production code
to run on Debian, expect for use on internal servers. When it comes
to writing Unix code for Government or Corporate environments, or for
products that run on Unix, the target is usually either Solaris, AIX
(maybe), and Red Hat.
Of course. Things were you can have someone to force to fix something
with contracts. For Debian, I doubt that any contract to earn money is
made, so... but I would be really happy to have an opportunity to work
in programming outside of windows world. Sweet dream.
Reply to: