[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: sysadmin qualifications (Re: apt-get vs. aptitude)



berenger.morel@neutralite.org wrote:
Le 18.10.2013 04:32, Miles Fidelman a écrit :
berenger.morel@neutralite.org wrote:



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 :)

I'm pretty sure that C was NOT written to build operating systems -
though it's been used for that (notably Unix).

I never said I agreed that C was designed to build OS only. Having to manage memory does not make, in my opinion, a language made to write OSes.

Didn't mean to imply that you did - sorry if I gave that impression. I was commenting on the quoted text "to say that C has been made to build OSs only" - and saying that (I think) we're in agreement that it wasn't (and that we're in agreement with the author or C in this).

I never took a look, but are linux or unix fully written in C? No piece of asm? I would not bet too much on that.

I wouldn't either. Though again, a quote from Kernighan & Ritchie (same source as previously): "C was originally designed for and implemented on the Unix operating system on the DC PDP-11 by Dennis Ritchie. The operating system, the C compiler, and essentially all UNIX applications (including all of the software used to prepare this book) are written in C.

I'll also quote from "The Unix Programming Environment" (Kernighan and Pike, Bell Labs, 1984) - and remember, at the time Bell Labs owned Unix - "In 1973, Ritchie and Thompson rewrote the Unix kernel in C, breaking from the tradition that system software is written in assembly language."

Out of curiousity, I just took a look at
http://www.tldp.org/LDP/khg/HyperNews/get/tour/tour.html (a nice intro the kernel) - and it explicitly mentions assembly code as part of the boot process, but nowhere else

I expect, that outside of the boot loader, you might find some assembly code in various device drivers, and maybe some kernel modules - but probably not anywhere else (except maybe some very performance-critical, low-level modules).



It was simply to argue that, even if it was true, then it does not avoid it to be good to write applications, since, in more than one people's opinion, OSes includes applications.

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.

Sure, but writing bad code is pretty easy too :-)

I actually have less problems to write code that I can maintain when I do not have to use SQL queries and stored procedures. I simply hate their syntax. Of course, I am able to write some simple code for sql-based DBs, but building and maintaining complex ones is not as easy as building a complex C++ module. Or as an asm or C, or even perl. Of course, it is only my own opinion.

Gee... I'd say just the opposite, but that's a matter of personal experience. Personally, I won't touch C - I'm a big fan of high-level and domain-specific languages for most things, and I guess I'd consider SQL a domain-specific language of sorts. (Then again, I haven't written a lot of code in recent years. I generally work at the systems level of things.)


I'd simply make the observation that most SQL queries are generated
on the fly, by code

It is not what I have seen, but I do not have enough experience to consider what I have seen as the truth. But I will anyway allow myself a comment here, if some people wants to create a new language: please, please, please, do not do something like powerbuilder again! This crap can mix pb and sql code in the same source file and recognize their syntax. It will work. But will be horrible to maintain, so please, do not do that! (this language have really hurt me... and not only because of that)

I've seen pretty much the opposite. Pretty much any web app with a query interface is talking to some kind of back-end that translates GUI interactions into SQL that in turn gets run against a database. (Just consider searching for a book on Amazon - there's a lot of SQL being generated on the fly by some piece of code.) Or for that matter, consider Excel's wizard for importing from an SQL database - when you're browsing a table in the GUI, something is generating the SQL that's sent to the database.


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.

The terminology is pretty imprecise to begin with, and probably
varies by country and industry.  The general pecking order, as I've
experienced it is (particularly in the US military and government
systems environments, as well as the telecom. industry):

Systems Engineer:  Essentially chief engineer for a project.
(Alternate term: Systems Architect)
- responsible for the big picture
- translate from requirements to concept-of-operations and systems
architecture
- hardware/software tradeoffs and other major technical decisions

Hardware Engineers (typically Electrical Engineers): Design and build
hardware (including computers, but also comms. networks, interfaces,
etc.)

Software Engineers: Engineers responsible for designing and building
software.  Expected to have a serious engineering degree (sometimes an
EE, often a Computer Science or Computer Engineering degree) and
experience.  Expected to solve hard problems, design algorithms, and
so forth.  Also have specific training in the discipline of software
engineering.  People who's resume says "software engineer" have
typically worked on a range of applications - the discipline is about
problem solving with computers.

Developer:  Vague term, generally applied to people who do the same
kinds of work as software engineers.  But doesn't carry the
connotation of an EE or CS degree.  Tends to be commonly used in
product development environments.  In my experience, a lot of
developers start out writing code in their own field of expertise
(doctors writing medical applications, musicians writing music
software, and so forth).  People with "developer" on their resume
often have specialties associated with the term - e.g., "game
developer" - emphasizing an area of specialization.

Programmer:  A term I've never actually understood.  Basic use seems
to be "someone who knows how to program" or "someone who programs for
living."  But.... I've personally never seen anyone hired purely as a
"programmer."  (I've hired, and seen hired, a lot of developers and
software engineers, but never a pure programmer.)  As far as I can
tell, the term is a carryover from the early days of large systems -
where "systems analysts" figure out what a system was supposed to do
(i.e., did the engineering) and then directed programmers to write
code.  (Akin to the relationship between a hardware engineer giving a
design to a technician, who would then build a prototype.)

Coder (or "code monkey"): A somewhat pejorative term for an unskilled
programmer - someone who might have taken a couple of "introduction to
programming" courses and now thinks he/she can write code.

For what it's worth - my observation is that the demand is for
software engineers and developers (i.e., skilled people who can solve
real problems).  But... computer science curricula, at least in a lot
of schools, seems to be dumbing down -- a lot of places look more like
programming trade schools than serious engineering programs. Not a
good thing at all.

It seem you attach a lot of importance to schools ( that what I understand in "computer science curricula" ) but I wonder: how do you consider people who learned themselves, before even learning a craft at school ( that's what wikipedia says when I start from the French "métier" and then switch on English language. I understand that it seems to be reserved for physical products in English, but, I like that notion: "A craft is a pastime or a profession that requires some particular kind of skilled work." which makes things different from a simple job. ) ?

Would you name them coder, programmer, developer? Something else? Do you consider they are always less efficient that people with high degrees?

Well, yes.... engineering is a professional discipline, lots of knowledge (both from books and practical) - generally, folks who work as software engineers a degree in EE, or CS, or CE, or sometimes math.

Having said that:
- In the early days, say before 1980, that was less so - in those days, practically nobody knew anything about computers; I know quite a few people who dropped out of college and went right to work in the field, and never looked back. (For that matter, Bill Gates comes to mind.) These days, though it's a lot harder to get hired for anything without a bachelor's degree - at least in the US (I know that education works a little differently in Europe.)

- Also, a lot of people doing software development are NOT degreed engineers (though it's pretty hard to get hired for anything in the US without a bachelorate in something). What I'd call them really depends on their level of skill - highly skilled, I'd call a developer. Lower skilled, I'd call an amateur. (I don't really have a lot of use for "programmers" or "coders" - knowing how to program or code is a pretty useless kill unless you also know how to solve real problems with the code.)

My general observation is that you find more specialization in developers than in software engineers - with developers typically coming from some other background. For example, a researcher who writes some code to analyze laboratory results in their field, then goes on to develop commercial analytic software, picking up programming skills along the way. Or a visual artist who goes into video game design. They learn the programming skills they need to solve specific problems, in their specific area of focus - but that doesn't make it possible for them to solve a general computing problem.

It's certainly possible to learn stuff on one's own, but my observation is that true depth and bredth requires some amount of formal education from folks who are already knowledgeable. It's like anything - sure there are self-taught violinists, but most who've achieved a serious level of skill (much less public recognition) started out taking years and years of lessons. Accomplished craftsmen (and women) have typically studied and apprenticed in some form. I sure wouldn't trust a self-taught doctor performing surgery on me - I'd want someone who went to a good medical school, followed by a good internship and residency, and a track record.
Are you saying it's NOT easy to install stuff on Windows?

Compared to other things I know, aka, deb packaging system, yes.
Considering you already have the archive binary, on windows you will have to read lot of screens, or you will destroy your system in less than 1 year, if you often add and removes applications, because when you remove something which installed crap on your computer, it won't remove it.

Sometimes, on Debian, I have to compile stuff myself... but it is the same for windows.

And, finally, to install and configure programming related stuff, like development libraries, on Debian you simply install them. They are installed in correct places so it is automatically detected by tools which needs them.


On Windows, when you will have finally installed it, you will have to take care where you did, because you will need that information later, and all softwares have their own preferences. Not to speak about the fact that they usually install in "c:\program files\<company name>\<software name>\". The company name is sometimes editor's one, or developer's one. Random.

Installing stuff on windows is only easy when you only know windows in modern OSes (this is to discard ms-dos ;) ).

Oh, and I did not mention that, on windows, installing a software which depends on another software will need you to install manually that other one. Which is why softwares often (but not always, I had lot of errors claiming that something was missing) includes most (but not always all) dependencies.

So, yes, generally, installing stuff on Windows is hard, compared to the only other modern system I know: Debian.


Ok, but now we're talking an apples to oranges comparison. Installing developers tools is a pain, no matter what environment. For fancy, non-standard stuff, "apt-get install foo" beats everything out there, and "./configure; make install" is pretty straightforward (assuming you have the pre-requisites installed).

But when it comes to packaging up software for delivery to users/customers; it sure seems like it's easier to install something on Windows or a Mac than anything else. Slip in the installation CD and click start. Not as common on Linux.

Miles

--
In theory, there is no difference between theory and practice.
In practice, there is.   .... Yogi Berra


Reply to: