Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
News

Is Assembler Still Relevant? 58

Posted by Cliff from the depends-on-the-niche dept.
quarnap asks: "I'm a system administrator running mostly NT boxes. I got into a discussion with a unix admin over whether a knowledge of assembler was of any use in either of our jobs. He insists it is since it provides a fundamental level of understanding of how computers work. I disagree; I say it isn't needed for ANY system administration work since that level of understanding is way below the level at which system administration operates. What do you think?" We've discussed this issue in a general sense in a previous Ask Slashdot, yet when it comes to System Administration it's a toss up. I can see situations where Assembler experience might be a boon to a sysadmin, but not a requirement for the job. What about you?
This discussion has been archived. No new comments can be posted.

Is Assembler Still Relevant? More

Is Assembler Still Relevant?

Comments Filter:

  • Depends on how you look at it I think. (Score:3, Interesting)

    by ScroP ( 536977 ) on Saturday December 29, 2001 @08:53AM (#2762001) Homepage
    Assembler, I think, is very relevant for programming because it really enhances your knowledge about whats really going on. In turn, knowledge of what a program is trying to do while administring a system is also extremely useful. For instance, alot of software might not report errors that mean anything - but if you've had some expirence programming you can makea good guess as to what might be wrong.

    So, does assembler directly impact the degree to which a person might be capable of administring a system?

    Yes and no.

    It may not directly be of use when installing & configuring things, but I think it indirectly is of great value to an administrator who is troubleshooting things; and actually has some knowledge about computers and software that didn't come from a course or book purely on administration.

    Are programmer admins that common though? I've done admin work, but I moved on to whatI wanted to do, programming, quickly.

  • Ironically (Score:3, Insightful)

    by ScroP ( 536977 ) on Saturday December 29, 2001 @08:58AM (#2762004) Homepage
    Ironically, alot of places don't think teahcing assembler is of use to thier CS students anymore. But I disagree with that. Assembler was one of the first things I learned, and I don't think I've have a fraction of the skill I do now if I just learned a high level language and prayed to whatever magic happened when I called some libary function to do whatever needed to be done.

    On the other hand, thats exactly all some people want. I guess it depends on what your goal is - true understanding, or simply getting by.

    • ... we seem to be heading, as a society, towards Black Box mentality. We don't care how it works so long as it works. You see it every day when you look at people using computers. Many (most?) of them have no clue about how the computer works at all. They're doing pretty good if they know how the application (or game) that they want to use works. And when the magic Black Box breaks, they call tech support. And many (most, it seems) tech support people are almost as clueless as the people they're trying to help.

      Now we're taking it up a level and worsening the problem, by saying it's okay if Sys Admins and programmers don't understand the intricacies of the Black Box. They just need to learn how their portion of it works, and they'll be okay.

      Back to the original question: Does a Sys Admin need to learn Assembly? Probably not. But it's a disservice to the profession to only learn what you need to know.
      • This goes along with the territory though. Think of how complex systems are now. It's ridiculous to try to expect everyone to know the internals of everything they use. It's good for a sysadmin to understand as much as possible about the system, but black box is so integral to computer science that to complain against it seems a tad ridiculous. Think of all the protocols that flow through the most basic user's monitor every day...to criticize a sysadmin or anyone else for wanting them to just work is just too hash.
      • We don't care how it works so long as it works.

        But is there anything fundamentally wrong with that? Do you know exactly how a car works? Probably not. I know I don't understand the, say, automatic gearshifting mechanism, but that doesn't mean I can't use a car to go somewhere.

        I do get your point though - the attitude expressed above is inexcusable in a mechanic so I guess that's what you meant. But you must remember that, as with cars, the majority of computer users don't care what's beneath the hood - they just want to look at the pretty pr0n or listen to mp3's. People using computers != people that should know how computers work.

        Happy new year,

        Yan
        • We don't care how it works so long as it works.

          And this tells a lot about how it has come to be that people perceive an architecture with a very limited number of registers, requiring a deep pipelined architecture and a ridiculous clock speed to be superior to an architecture with lots of registers, achieving its operational bandwidth of data+instructions through the cpu at a lower cpu clock rate, lessening the demands on every other component in the system.

          The larger, more complex picture of How Things Work befuddle the limited mental capacities of the masses, leaving them vulnerable to the Madison Avenue attack of the single metric evaluation -- i.e., faster cpu clocks are always better. And explains why John Q Public, when faced with the choice of buying System A, with a 4 GHz system clock and frequent pipeline stalls, vs System B, with a 1 GHz clock but lots of internal parallelism and a much lower amount of cpu wait, will always go for System A.

          The really sad part is that so much of the supposed "technical" community are no better off than John Q Public in evaluating their choices.

  • depends on the system (Score:3, Insightful)

    by DrSkwid ( 118965 ) on Saturday December 29, 2001 @09:13AM (#2762017) Journal
    If you are the sort of admin who get's asked "hi AdminMonkey, my email doesn't work, can you sort it please" or "i need nfs access to foo, sort it"

    then assembler probably isn't much use.

    But if you are the type who get's asked "bar program keeps core dumping on me, could you fix it please" then it most probably is.

    You can close this discussion now.
    • Except for the "close" comment I ACK this.
      Get a good disassembler (I'd recomment looking
      for it at crack/warez sites, there are many
      freeware tools) if you get the "core dump"
      problems (I'd rather say GPF).

    • But if you are the type who get's asked "bar program keeps core dumping on me, could you fix it please" then it most probably is.

      Strictly speaking, I don't think that's system _administration_. I do agree that understanding on fundamentals is important, but just try learning about the Linux VFS just from looking at assembler
      pages and pages of code. Just as the average car mechanic need not be concerned with the smelting methods of various grades of steel to be effective, I'd think the average sysadmin can do without mucking around with ASM. But if we are to insist on fundamentals, we'd all benefit from a few years of understanding electron spin and so on while we're at it.

      Cheers,

      Nwanua.

  • In general,no (Score:2, Offtopic)

    by biglig2 ( 89374 )
    If you're a sys admin and need to learn a language, you're much better with Perl or Python or similar, since they are more useful for actual systems administration work.

    I cna see though if you were the kind of heavy sysadmin who gets into the bowels of the system and also works on bug fixing in-house software, assembler might help, although I tink you'd want to get very up on C first.

  • Paradigm Shift (Score:5, Insightful)

    by Catiline ( 186878 ) <akrumbach@gmail.com> on Saturday December 29, 2001 @09:58AM (#2762071) Homepage Journal
    I'm a system administrator running mostly NT boxes. I got into a discussion with a unix admin [added emphasis mine]
    Look, don't try to talk this over the OS advacacy gulf. In Windows, not knowing how to program at all, even to the extent of never writing .BAT files, is alright. The system will let you cope. (Yes, yes, you will be crippled, but that's aside the point.) This is not true in *NIX land- as any native, immigrant, itenerant or visitor will be able to tell you (if only by their total lack of understanding). *NIX demands that you know why the system works- just to configure it properly- and that requires a knowledge of programming (though I've never encountered needing to know real assembler, knowing the concepts sure helps every once in a while).

    So if you want the answer in simple terms- sure, you're both right, but only in Windows can you get away with no knowledge of programming and still administer a box (yes, yes, poorly, but a MCSE will help. That doesn't teach programming, IIRC).

    • Look, don't try to talk this over the OS advocacy gulf.

      I think it's you that started the OS war again :-)

      I can't speak for NT, but on Unix the "low level" necessary to do real work is C, not assembler... you may even write device drivers in C, at least in part, since the model is sufficiently formal.

      When I was young, I tried to make sense of Sparc assembler, and I could not make heads out of tails. True, my only exposure was to 6502 assembler and a bit of 8086, but this showed me that assembler was no more so relevant. And it was 10 years ago!

      YMMV, of course, especially if you are programming space probes, or real real time games.

      ciao, .mau.

  • Perhaps assembler itself may not be useful to you, but the type of information you would learn by endeavoring to any kind of low-level programming could be very useful.

    If you spend any time trying to choose hardware, fix hardware, optimize performance, resolve application crashes or otherwise go beyond user-level application support and swapping components, you would benefit by a second, more rudimentary view of your system.

    If your job is pretty basic or you never worry about growing past your departmental budget, the extra 10% that a system-level view provides probably isn't worth the work. But it's still fun to know stuff, damnit.

  • Assembly... (Score:2, Informative)

    by mirabilos ( 219607 )
    please don't get me wrong, but actually the
    language is called "assembly" and the compiler
    "assembler".

    Assembly surely is fine, and even today you can
    write native {DOS, Win32, NT native, UN*X}
    applications fully in it - or even sedecimal
    machine language, but no one tends to do it, even
    if one can. The effort isn't worth it.

    But you can, for example, as I do, code important
    parts of you code in (portable !!) assembly, the
    other parts in C. The C files I compile with gcc
    (BSD and Linux) or BC++ (Win32), the assembly
    files with nasm (http://nasm.2y.net/), with a
    %ifdef for the cases ELF, A.OUT/BSD and OMF
    differ (the object formats).
    I can bind those object files to libraries (.a,
    .so, .dll, .lib) or compile them to executables,
    and they yield me funtionality at speed never
    seen.
    I recommend the newsgroup comp.lang.assembler.x86
    for a start, _if_ you really want to code in asm.

    But I do not recommend to do so if you didn't
    understand coding in before, and for a NT sysadmin
    I'd rather recommend php (or perl, but I dislike
    it), or, as another poster told, python which I
    didn't use yet.
    This should give you a first shot.
    On the other hand, these languages, as well as,
    e.g., VBA, do not have typical programming language
    structures such as type checking, so, if you want
    to start "real" programming, download BC++ 5.5
    (http://www.borland.com/) - there's a free download
    edition, command line tools only, and start coding
    in C. Mostly I'd recomment command line code for
    a start, as GUI programming is way more difficult.
    I personally dislike C++, for example because it
    is too complex - noone can hold the whole of the
    language definition in back-mind as I can easily
    do with C or some assembly environment.

    Of course there is also cygwin32, and my programmes
    would compile no differently under it than they
    do under BC++.

    If you still want to do assembly, don't use MASM.
    If you want, use TASM, but if you CAN, use NASM.
    There's a linker (VALX) that can even produce
    Win32 executables at http://members.tripod.com/~ladsoft/
    included in the C compiler package, but here I
    take ilink32 of the BC++ package for stability
    reasons.
    You can even write your own import libraries
    under NASM if the provided packages are too
    complicated (I do).
    Google for "win32 nasm" and you will find some
    more sites, or "win32 assembly".

    Puh, this's a long and partially-OT post, but I
    hope this will help you.
    • I personally dislike C++, for example because it is too complex - noone can hold the whole of the language definition in back-mind as I can easily do with C or some assembly environment.


      I disagree. Assembly language (at least x86) is far harder to hold the whole definition of than C++. Have you checked just how many instructions there are? Enough to fill 467 pages in (one of the volumes of) the Intel Architecture Software Developer's Manual. And that's as of 1997, I'm pretty sure there are more now. C++ has only 13 keywords more than C. I agree that it is sometimes difficult to remember some of the more obscure aspects of C++ classes, but there are many more asm instructions that I have to look up every time I see them.

      Maybe you see the standard libraries as part of C++, hm? That would make it harder to hold, but so would having to know all the BIOS interrupts (if you're in real mode) or even all the peculiarities of each IO port on the x86 (protected mode).
      • I don't talk about "keywords", I'm speaking of
        the language as a whole.
        And yes, this _includes_ the host systems'
        pecularities (is this spelled correctly?) as,
        for example, libc, libstdc++, the interrupts,
        the BSD syscall numbers, etc.

        But the underlying structure of C++ is way
        different than that of C: one is actually
        supposed to do fancy things with classes,
        and tempted to do overloading and this
        template thingies I never really grokked,
        as opposed to C, whose intention is to be as
        simple as possible.

        Assembly language is much complexer than C,
        but it has purity of its own, as - I now
        specifically speak of IA-16 and IA-32 - there
        are no explicit control structures aside from
        jumps (goto in C) and loops (in C coded as
        for(a=max;a=0;--a){}).
        I really like assembly _because_ of the preference
        of the jmp statements. I always look for it in
        higher-level languages, too, as one actually even
        can produce structured code with jmp/goto statements,
        if you're a bit careful. The linux kernel includes
        several occurences of goto, if I may cite this,
        in order to make the code more readable.

        In my opinion the advanced features of C++, but
        more so the advanced spirit of C++, make the
        language less easy to read.

        Ok, let explain me, I got my first computer when
        I was 8.5 years old, and quickly learned DOS,
        then GW-BASIC which I fully grokked at age of 10.
        You may know the handbook, it even includes an
        example of how to include asm code into programmes.
        Mine has a typo and I knew it, though I never
        really learned assembly before the age of 14.
        English is not my native language, and I started
        learning it in school at the age of 12, nearly
        four years after getting a computer (without
        graphical interfaces, btw).
        Then I learned Turbo Pascal 6, including its model
        of object-orientated programming. After I grokked
        it, I started, again, a try to understand C. As
        my English got better and I bought a Linux book
        (with CD), I could start. Now I know bits about it,
        but C++ has so different approaches than C and
        "Object Pascal" that I never got far in, and
        eventually dumped it.
        Perl I also dislike, PHP is much nicer.

        This short excerpt (I'm not even 20 at the moment
        I write this) may explain my opinions to the
        reader (and probably excuse me).
        Yes, you read right, I learned ASM before C. And
        I am still learning.

  • things to know (Score:4, Insightful)

    by spacefem ( 443435 ) on Saturday December 29, 2001 @11:10AM (#2762155) Homepage
    Learn stuff, kids, it won't kill you. It's like differential equations - there are some things that just about everyone should take a class in, it proves they're smart enough to have a university degree and gives them a good general understanding of how something else in the world works.

    Many system administrators work with people who not only know assembly, but think in it. Freaky, I know, but I'm in EE and it's basically how we are, and it's who we want to work with. Deal.
  • For admins? No. But DSP coders still make the BIG bucks.
    • I'm in the middle of a sparetime project based around an Analog Devices DSP. I'm curious why your statement is true, especially since its so easy... anyone who knows algebra can read AD DSP assembly fairly easily. The only tricky part to writing it is sorting out your algorithm to take the most advantage of parallel instruction execution.

      Are other vendors' DSPs (TI comes to mind) more difficult to understand?
    • I left a job that involved doing a simple low-pass IIR filter on an 8051 (hey, it was low frequency, too). It was one of the few remaining things on the project and was already partially done (I had done all the low level multiply/divide routines to implement another filter elsewhere in the code). They passed the work off to a new guy, a "DSP expert" out of college. I explained the filter, and showed him the code. He had never seen any kind of assembly language. It was hiring decisions like this that was one of the major factors that had caused me to look for another job!
  • I think a competent UN*X sysadmin should be a competent C programmer. Since you can't be a competent C programmer without knowing how C translates into asm, a familiarity with asm is a given.

    -Steve

  • Ask your vendor! (Score:2, Insightful)

    by Paranoid ( 12863 )
    Developers obviously have a benefit to knowing assembly, if no reason other than debugging skill. Those who don't know it are reduced to blaming Bill, other components of the system, or the hardware, all of which are counterproductive excuses at best.

    I believe sysadmins have a benefit to knowing it as well, simply because you know whats going on under the hood, so to speak. This kind of knowledge allows you to actually understand the worth of things like 3DNow!, SSE/SSE2/MMX, pipeline length, cache consistency, hyperthreading, and all the other things that vary from processor to processor and from software package to software package. I believe this is important because you aren't reduced to cointosses for whose hype to believe, when deciding what things to buy/download and deploy.

    In addition, if assembly wasn't relevant for administration of a system, why would you include register dumps in bluescreens/Oopses? Rebooting doesn't cut it, that only temporarily alleviates symptoms and doesn't solve the problem. I believe "keeping a system running smoothly" definately counts as a sysadmin's role, therefore a sysadmin should have good debugging skills. Even if you pass the debugging off to someone who would know, wouldn't it be nice to know WHICH hex numbers on that bluescreen would be helpful to him/her in finding the bug?

    If you're constantly answering questions like "I forgot my password", "is the network down?", and "I need a damned good kicking please?", then perhaps assembly wouldn't help you here (unless you're trying to achieve BOFH-style *DUMMY MODE*). However, this means you are either not a sysadmin or are wearing multiple hats - this stuff is commonly called "Tech Support".
  • What is your role in the administration of the network? Shellcode for
    penetration testing is asm (though you can arguably use code written
    by others who do have the knowlege of asm you're lacking). Writing
    any kind of lowlevel tools where speed is critical is asm. Debugging
    any odd behavior of lUserland software is asm. Changing the paper in
    the paper tray or pressing the on/off switch on the fileserver when it
    misbehaves does not. You CAN get by without a knowledge of
    assembler or any programming language at all, but I personally wouldnt
    feel very comfortable with job security unless I was the boss's nephew
    because the person who does know these things you deem as
    unimportant WILL be better qualified and do a much better job that the
    one who doesnt.

    Of course this is just my own opinion based on my own observations,
    take it as you will.
  • ...but only if you're actually expected to fix real problems yourself. A lot of organizations rely on support contracts and begging their vendor to fix problems.

    I've provided post-sales support for a number of proprietary products for a number of years and having an understanding of programming from assembly and bare metal up certainly helps me. It has baffled my (non-programmer) colleagues who wonder how I appear to pull correct diagnoses and solutions out of thin air, though. This sometimes causes problems if they think I'm being unprofessional and guessing.

    At the very least, knowing what strace/truss is telling you, being able to find the executable or binary producing a certain error message (strings) and being able to distinguish between the static and the dynamic parts of error messages (so you can search using Google for the static parts) helps enormously.

    Having said all that, the combination of x86 and C/POSIX is the first platform I've not bothered to learn how to write assembly for... might come in handy for implementing l33t 0-day sploitz though.

    --

    • A lot of organizations rely on support contracts and begging their vendor to fix problems.

      As the person who was once on the other end of the phone in that situation I can tell you programming experience, even limited, helped me vastly.

      I hacked on Pascal in high school and college (showing my age now) and I thought it would never help me in a job until a couple years back when I got a job working with a legacy software package written in, you guessed it, pascal.

      Understanding the environment and being able to intelligently read the code was crucial to learning the app and finding/reporting/repairing bugs.

      On a side note, I just got out of the healthcare industry, and I can tell you that having programmer/admins work on the client's systems would drastically improve the user's enjoyment of the product. In my experience, the customers that were a pleasure to help were the ones who enjoyed taking a moment reproduce the error themselves, write down the message, and try to find their own solution in the documentation.

      Coincidentally, these people all were usually DBAs and/or programmer/analysts. You knew when these people called it was actually a software problem, not a user error.

  • Assembly in principle is important (Score:4, Insightful)

    by foobar104 ( 206452 ) on Saturday December 29, 2001 @02:27PM (#2762712) Journal
    The majority of the opinions here so far seem to say that learning assembly isn't important for non-hardcore-programmer types.

    I agree, if we're talking about any particular assembly. PowerPC assembly, for instance, or MIPS assembly.

    But everybody who programs-- even people who just want to understand programming-- should slog their way through Knuth's TAOCP [stanford.edu]. The abstract stuff in that book is implemented in concrete terms through a really simple fictional assembly language called MIX. When you're reading the first chapter of Volume 1, you'll be so frustrated with it that you'll wanna strangle the first person you see. But by the time you get through it, you won't be an assembly programmer, but you will find yourself saying things like, "I should arrange the loops this way, because then the inner loop will fit entirely in registers and the data fetches will be less than one cache line."

    Saying stuff like that makes you sound really smart, which leads directly to better paying jobs.
  • Asm, while maybe not relevent right at this moment, may be useful sometime in the future. It is true it gives you a greater understanding of exactly what is going on if an error should occur. The other thing you might consider is: Do you really want to be a system admin for the rest of your life? An NT one no less?

    If you're ever interested in progressing your career further you might consider picking up a programming language or three, asm might be a fun choice.

    An admin friend of mine once said something to me that changed my mind about being interested in the admin field:
    "Just wait until they figure out, we're just janitors for thier computers"

  • A basic knowledge of assembly (and basic compiler theory) is absoluely essential to efficient programming in C. If you program in a higher level language (not C++) that knowledge is perhaps less useful.

    Another good use for knowledge of assembly is in analysing certain crash dumps from software that was built optimised. When a highly important customer sends in a crash dump it's nice to be able to at least determine the line in the software that the error occurred, if for no other reason than to use as evidence to pass the buck to someone else.

  • ... you could have learned some of the basics. As a techie you should constantly be trying to learn, both inside and outside of your specific domain. Learn what interests you.

    Sysadmins are probably better off with perl, shell scripts, and WSH first. Then, if you want to push yourself, learn a language like C++.

    Asm should come later, and most people gan get along just being able to read it. Learn about the registers, the stack, and addressing; then learn the most fequently used instructions such as mov, conditional branches, jumps, and call. After that just look up the ones you don't know when you run into them.
  • I mean, put it this way: does a psychologist have to understand the electrical & quantum mechanical properties of the brain in order to do their job? No. In fact, it might even make them *less* effective as a counselor, if only because they're so aware of the low level wiring of the brain that they perhaps aren't as familiar with the high level stuff that they usually need to be focusing on.

    In my opinion, the value of assembler is vastly overstated these days. It makes you work so close to the metal that it become too difficult to keep track of how a large, complex system has to work. It can be useful for optimizing critical components of important systems, and I'm sure it's invaluable in situations like embedded & realtime systems, but for a sysadmin? No way.

    In my opinion, it would be much more valuable to have a good grasp of relatively high level & abstract subjects like networking techniques and protocols, file structures, and most importantly data structures. The last one is particularly important, because knowing how to rewrite a bad algorithm in assembler is sure to be much more painful and much less effective than rethinking the algorithm itself. You're likely to get a better performance gain by implementing systems with optimal algorithms in a "slow", high level language than you are with a naive algorithm in a "fast", low level assembler, and with hardware power increasing as fast as it does, you're better off taking the high road anyway -- *especially* as a sysadmin.

    Knowing how the machine works is important, and I'm not trying to dismiss that. But knowing how to manually push the bits around is just going to be an exercise in tedium & frustration. The machines are designed to abstract away that monotonous stuff for you, and you have to be in a pretty specialized situation for it to be worth second guessing the compiler writers. RTOS/embedded type stuff is one of those situations. Sysadmining, either on NT or *NIX, isn't.

    You'll get much farther by knowing how to bang out a stream of high level utilities in a language like Perl, Python, Shell, DOS, or Visual Basic, than you ever will by slaving away at little functions in assembler that take forever to gel into useful systems...

  • The "fundamentals" fallacy (Score:3, Insightful)

    by fm6 ( 162816 ) on Saturday December 29, 2001 @08:21PM (#2763573) Homepage Journal
    He insists it is since it provides a fundamental level of understanding of how computers work.
    True, except for some careless wording. Assembler code is a more fundamental representation of the computer system than what most users or programmers deal with. But it's not the fundamental description of a a computer system. A architectural description [williamstallings.com] is certainly more fundamental!

    Any computer system consists of layers upon layers of abstractions: machine programming models, procedural programming models, OOP models, message passing models, networking protocols, application frameworks.... Nobody can master all of them. You can't even hope to master all the ones that you (directly or indirectly) use! The best you can hope for is to master the abstractions that are directly relevent to your work, and have a schematic knowledge of those that indirectly affect you.

    That being said, studying low-level programming actually does help you understand how computers work -- provided you study it in context. You need to study it not as a "fundamental" programming model, but as one piece in a very big puzzle. And you need to avoid focusing on one particular processor -- that will only tell you about specific, possibly obsolete, design decisions, not fundamentals of "how computers work".

    • For a sysadmin, knowledge of C programming is beneficial, and for a C programmer, knowledge of assembly is beneficial. P Nevertheless, much of the work of sysadmin takes place at the higher levels: so a knowledge of scripting (e.g. in Perl), information security, knowledge/data management are likely to be the areas which it is much more beneficial to focus on.

      • For a sysadmin, knowledge of C programming is beneficial,
        Why? To recompile GNU apps and Linux kernels? Not all Unix/Linux sysadmins need to do that -- and most probably shouldn't. To say nothing of sysadmins who use only "closed" systems.
        and for a C programmer, knowledge of assembly is beneficial.
        Again, why? It's true that C's programming model is closer to the basic machine than that of other languages. But the C programmer's purposes are served by a schematic understanding of the general C model, not the misleading example of how C works on a particular architecture. Using C as a "high-level assembly language" is a formula for creating obscure, non-maintainable, non-portable code.
  • Without assembly, John Carmack and Michael Abrash wouldn't be putting out cutting-edge gaming engines. There's a lot of money going through them based on the various Quakes and Dooms and the licensing of those engines to other projects. People love those engines based on performance, and good performance means knowing assembly -- otherwise we'd need 2GHz machines to do what Id was able to do on 400MHz (or whatever). So, assembly can still be relevent even if we aren't the one's coding it.

    That said, with the evolving speed of chips it isn't the CPU that's the big bottleneck anymore. So, if you're thinking games at all, you might want to consider looking at chip programming for video cards and leave the rest of it in C/C++.

    As for the rest of us... I don't really know. Being a specialist in a specific chip architecture really lets you flex your geek and might lead to a specialist's salary and sort of lets you in on that whole nebulous zen of programming out there, but it's not really needed (IMO) if you're only working with APIs on small task-based things, and not building or refining high-performance engines (servers, databases, games, whatnot), and arguably even in those cases assembly programming should only be the last stage once the prototype's been worked out. Plus, there's the possibility that we really are on the verge of seeing the death of the desktop machine, in which case all our x86 knowledge might be useless in the next five to ten years...

    Now, those PDAs would probably be fun to get at the guts of. I can imagine that there's a need for performance at that level, given the low amounts resources (RAM, Hz, etc) available. I'm sorry to say I know nothing about these things. Is there chip-level programming available for those? That might be an interesting side discussion.

    Here endeth the offtopicness.
  • Think again. Don't believe me? Then read this [google.com] story. A nice hack to say the least.
  • I code in the highest level language that does what I need to do.

    Sometimes that means Assembly Language. Most of the time it is something else.
    A long time ago it even meant patching machine language (object code) to get things right.

    I have never regretted knowing more than I might need for a particular task. Neither will you.
  • Unless you have other functions as well, your job as sysadmin is to keep the system running as often as possible - this means fixing problems as quickly as possible, and also keeping the system maintainable by other admins. Using any given scripting language - especially on a *nix platform - will let you carry out any standard sysadmin task quickly, efficiently, and in a way that is easy for admins less talented than yourself to understand. So in a non-development shop, you should certainly feel free to learn asm for the joy of learning (I intend to), but don't use it on the job.

    In a software dev house or other highly technical environment, of course, you may actually be called on to do debugging work. In that case, yah, you need assembly. That's actually a pet peeve of mine, though: it seems to me that having a hopefully well-trained individual with experience and skill in system administration do a programmer's job is a waste, just as having a programmer take over sysadmin roles in inefficient a lot of the time. Let your programming gurus do their think, and your admin gurus do theirs, I say.
    • Unless you have other functions as well, your job as sysadmin is to keep the system running as often as possible - this means fixing problems as quickly as possible, and also keeping the system maintainable by other admins. Using any given scripting language - especially on a *nix platform - will let you carry out any standard sysadmin task quickly, efficiently, and in a way that is easy for admins less talented than yourself to understand. So in a non-development shop, you should certainly feel free to learn asm for the joy of learning (I intend to), but don't use it on the job.

      Homework:

      Please do the following with a scripting language of choice:

      Set numlock to high and capslock to low
      send an init string to a modem that reports carrier detect high by default
      do a "warm up" read to a drive

      each require about 10 easy lines of asm code, or some screwing around in scripting languages. I'm not saying that asm is the be all and end all of languages, it's not very portable. But it's nice for little hacks.
      • But those little hacks aren't nearly the bulk of sysadmin work, and they CAN be done in scripting languages - not as quickly, but you do gain the advantage that more people will know the scripting language, and be able to maintain your hack. I don't know about you, but I find other peoples' assembly code a bitch to read.

        If you want to do it quick and dirty, asm is very nice. But I still don't think it's worth the time to learn if you're only using it as a sysadmin.
  • There's no argument that a Visual C++ or even VB programmer is going to be useful or at least informative when Office 97 bombs out with a GPF.

    I've worked with alot of other techs, and they didn't pay attention to alot of Windows internals that I would, because they had no clue about them. Whats a specific DLL do? No clue. They could go to Microsoft's support site, and look up a fix, but you can't beat knowing where the problem lies.

    And to do any kind of UNIX admin you've got to know your way around gcc, make, etc.

    But do you need to know assembly language?

    Probably not....

    Knowledge of general programming is very useful though!
  • Sysadmins probably shouldn't write the equivalent of shell scripts in assembler, but having a firm grounding in it helps to:

    1: Analyze core dumps, blue screens, etc. (regardless of platform)

    2: Understand tricky things like big and little endian, binary, octal, and hex notation, etc.

    4: Have a firm fundamental understanding of what object code is, what linkers and loaders do, why it's important, etc. In a world of DLL hell, at least understand what's going on "behind the scenes"

    5: Have a theoretical framework to hang concepts like processes, threads, priority, scheduling, interrupts, etc. -- it might not be _the_ correct model for a particular platform, but it will give a much better starting frame of reference.

    On the other hand, if by "sysadmin" you mean "village idiot", and the only requirement is to know how to walk people through rebooting their PC and knowing how to call 1-800-dial-a-vendor and sit on hold, then NO, you don't need to learn assembly. In fact, you could probably get away with not knowing math, history, economics, or much of anythig else. Better yet, how about totally untrained sysadmins? I mean, c'mon, NT/2k/XP is virtually self-administering and it's all "point and click", you could entrust all of your corporate systems to a high school dropout for a fraction of the cost of even an incompetent sysadmin!

Slashdot Top Deals

Anyone can make an omelet with eggs. The trick is to make one with none.

Close