Linux Jobs Forecast: Pressing Need for Linux Talent
linuxfoundation.org
linuxfoundation.org
We hackers live in a gated community. I've seen people in shock when they find out someone doesn't run Linux as their main OS. I was flabbergasted to find out none of our IT folks knew how to use the terminal.
tl;dr The double bell curve of tech talent is still in full swing.
I lived through the era of Windows trouncing Unix. A major reason why it happened is because people were familiar with Windows on their desktop and found the gui tools easier to use on their servers. The various Unix vendors did start coming out with graphical administration tools, but many of them were pretty dire.
Using Ubuntu Desktop on the server means they can use it on their desktops and become familiar. And maybe they will eventually graduate to using command lines, but they don't have to for a lot of administration.
On servers? There was no such era! Windows never dominated the server market. Sure, there were some companies that were Windows shops, but most servers were and still are unix/linux.
"A major reason why it happened is because people were familiar with Windows on their desktop and found the gui tools easier to use on their servers."
This might be true for mom & pop shops where the servers were run by desktop users, but on the enterprise level where corporations could afford their own sysadmins, Windows is and always has been a minor player.
Even for the Enterprises you'd find widespread Windows NT adoption. Sure some core backend servers ran Unix but the servers users used were predominantly Windows.
EDIT: By UNIX pro, I personally mean people who are familiar with the typical nix stack, e.g. GNU/Linux, BSD, Darwin. This would encompass sysadmins, programmers, etc.
We do all our development on Linux with one or two developers using Mac. I expressly forbid doing any development on Windows even though everything could run on Windows. This is purely because it takes longer, has more hassles, the tools aren't better (eg valgrind), awful package/dependency management, and it doesn't match deployment environments.
If you are developing for Linux deployment, it doesn't make sense to develop on Windows. This is a no brainer. Likewise if I was to develop for IIS/SQL Server I wouldn't do so using my Linux environment.
Back in the day at BT we even brought all our systems (Dev, Test and Live at the same time so we had identical systems from the same production run from sun.
Obviously making sure your test environment is as close to possible as your production environment is important, but I don't get too bothered about making sure the machine my text editor runs on is identical to the machine I will end up deploying to. But then again, I'm just a hobby programmer.
And the random approach to hardware that clouds use well maybe thats why they have such poor up time when compered to the carrier grade gear a telco uses.
At Amazon most of the teams I worked with developed our entire Java service stack on Windows, and shipped on Linux - because the Windows tooling was just better. To this day Eclipse on Linux needs endless tweaking to fit the same content to the same screen resolution, and the double monitor support back then was hilariously poor.
Some status information is saved in an ini file. On Linux and Mac I make it hidden by having a dot prefix in the filename. To make it hidden on Windows I had to use a Win32 call (SetFileAttributes) and wrap the access in a call to unhide it and then rehide it afterwards.
When the tool finds problems it can open the browser on a local copy of the documentation shipped with the tool. However opening web pages with anchors has the anchor ignored on Windows making things that much more hostile.
Those were just the waste of time on one utility, not to mention all the testing to find them. Multiply by everything else and it just isn't worth it. Some of our stuff does intensive file I/O. This is a lot slower in a VM.
It all adds up to a death by a 1,000 cuts.
Most of this is just "it's different, wah." Maybe it's not so bad to people who are used to it the other way. Maybe to some the dotfiles are the weird thing.
I didn't explain clearly enough. The python script uses an ini style file to remember one value between runs. On Mac/Linux I can hide that file purely by putting a dot in front of the name. On Windows I hide it by changing attributes to hidden, but have to unhide for the portion of the script that access the file. The attrib command isn't relevant in this case. (And yes I've heard of it.)
Just to make things clearer, these are the non-mobile operating systems I've used beyond the superficial as well as doing software development on the vast majority: Prodos, MSDOS (3 through 6), Windows 2, Windows 3 (including real mode), Windows for Workgroups, Windows NT, Terminal Server, 2000, XP, Vista and 7, Pyramid Unix, SunOS, SVR4 (several derivatives and flavours), Linux, and MacOS. I've used several more but deeply enough to make the list (hello GEM, OS/2, AS/400, BeOS, a zillion Unix flavours ...).
Exe4J / Install4J; works everywhere.
Some status information is saved in an ini file...
Don't. Use the registry on Windows, dotfiles on Linux (and plists on Mac? Or is that gone with OsX) ?
...open the browser on a local copy of the documentation...
Don't, use CHM on Windows (although I think this changed AGAIN recently).
Some of our stuff does intensive file I/O. This is a lot slower in a VM
VMWare Workstation?
Software development is death by 1000 cuts. That's the nature of the game. If you get into x-platform dev without thinking too hard about it you'll suffer, but none of the platforms is "right" - just better or worse for something.
> Exe4J / Install4J; works everywhere
So to run a jar that produces command line output and is consumed by the script and is one line to run on Linux/Mac (java -blah -blah -jar foo.jar blah blah) requires me to purchase a 3rd party wrapper/installer app. That there is a hoop to jump. Finding the java binary via the registry worked just fine, didn't require installation or wrapping or anything else.
> Don't. Use the registry on Windows, dotfiles on Linux (and plists on Mac? Or is that gone with OsX) ?
I used the Python configfile module which does ini style files. At the moment I save exactly one value. It is trivial and works really well. Doing more than that is more hoop jumping.
> Don't, use CHM on Windows (although I think this changed AGAIN recently).
So I need to convert perfectly good documentation that works in any browser on any platform into another format just because Windows strips the anchor when opening a URL? More hoops.
Incidentally I do actually generate CHM files for one of my open source projects. I had to give up because the help compiler refuses to install now (I believe the setup program is doing 32 bit arithmetic on free disk space and wrapping around to negative numbers).
> VMWare Workstation
I've yet to use any virtualization solution where guest disk access is at the same performance level as on the host. (I prefer virtualbox.)
> If you get into x-platform dev without thinking too hard about it
I never said I wasn't a x-platform dev. All my open source projects for well over a decade work on all 3 platforms. But that is because I'm diligent and don't want there to be any impediments to others being able to use the software. Windows is usually what causes the highest amount of work for least results, although there are exceptions (eg printing support has always been easiest to add support for on Windows).
But when we do our internal stuff there is no value to being cross platform to Windows. It wouldn't be a big deal if it didn't require so much additional effort. Consider something as trivial as deleting a file. If you just had it open (can't delete open files on Windows, more hoops) then closing it and deleting will often fail. You have to add delay/retry loops because tagalongs like virus scanners and backup agents opened the file after you closed it.
So as a result the only thing we have that runs on all platforms is one script because it is run by outsiders, and that required extra effort for Windows. It could require even more if I did everything "properly" although the people running the script wouldn't know any different which is why I didn't expend even more effort.
Install4J is free-as-in-beer BTW, but you do tend to get what you pay for on Windows, especially with virtualisation software.
Deleting open files is another different-not-better situation - I've seen Linux server apps resurrect entire paths due to open inodes that looked like they were deleted but weren't. That was fun to debug on a production system doing $millions a month.
Have you tried Qt or similar? Perhaps a script isn't the right answer if it needs to Just Work everywhere.
No installation is done - you just run the script. It has an accompanying data file which is actually a zip file and one member is the jar. It is extracted to a temporary directory and run and then deleted afterwards. (Performance is not a problem since this isn't run that often.)
The open deletion isn't relevant to this but is something I've dealt with elsewhere. Note that you can still have problems doing deletions even after you have closed the file due to tagalongs.
In this particular scenario a command line tool that has an exit code and can be automated via make, ides etc is the right solution.
I've done cross platform GUIs before as well as cross platform servers. For one company the latter was done using Qt but there was no gui so it was QThread, QString etc.
For cross platform GUIs there are roughly two approaches. One is where there is some sort of wrapper that uses the native platform widgets and tries to provide the same API on each platform. This often suffers from the lowest common denominator effect across the platforms. The other end is a toolkit that draws everything itself effectively mimicking the platform and provided the same underlying code on all the platforms.
I really don't like the latter approach. There will always be discontinuities between the real platform and the mimc. The mimic will always lag the platform and its developers will have to spend a lot of effort just to stand still.
For the first approach I like to use wxPython/wxWidgets. One neat thing they do is provide their own widgets (composed out of as many platform widgets as possible) when the platform doesn't have the relevant one so you do get a good set to develop on.
That said I do user interfaces in HTML these days where possible so there aren't as many cross platform issues (and I never support IE6 although it often works well enough).
The job of a manager is not to bend the environment to his needs but to aid the people that do the work.
Our situation is the other way around where deployment is to Linux (AWS/AppEngine) and there are several internal tools that work seamlessly on Linux and Mac. Having to add conditionals all over the place for Windows (not to mention the additional testing) is not free. The new developers can adapt to Linux or they aren't very good developers. (Note we make it abundantly clear that we use Linux and Mac for development in our job ads.)
I mean, I just guessed based on how "Linux" is typically used, i.e. GNU's userland. I don't exactly have time to call up "93% of hiring managers" and ask them personally.
When you hear about companies needing Windows Pros, do you think they really mean Windows kernel developers? Why would a Linux Pro mean kernel developer, while UNIX pro would be more generic?
They want someone who knows the Linux ecosystem. There are Linuxisms that have nothing to do with UNIX. That's what they're talking about.
Because Linux is technically the name of just the kernel, not the entire system encompassing userspace as well. There's definitely room for misinterpretation there.
Nice thing about context, it tells you how something is being used.
Stallman isn't putting up want ads.
I occasionally have recruiters contact me believing this means I'm a perl/awk/bash wizard.
Learn to do things that you read about in system admin blogs. Spinning up VMs, clearing log files, and setting up monitoring systems. Learn to roll your own package. Even better yet maintain one for a distro and put that on your resume.
Make a effort to become familiar with several scripting tools. You don't have to master them all, but make sure to pick up enough to be able to read code in bash, perl, python, and maybe even ruby.
The final step to being a Linux admin is learn Windows. Most real world jobs require that you have to deal with both. Even if it is not your primary responsibility, you will need to know how to inter-operate with Active Directory and the services that hang off of it.
I personally think the best way you can get started is by using the command line for everything "work" related. When you're doing your projects for school you should be using vim (or emacs if that's your thing). When you're navigating directories or performing file operations you should just use the terminal. Using the command line effectively is such a critical component of being an admin, and it just takes practice to get good at it.
The fact your doing computer science is a huge leg up, because you'll have a good understanding of the fundamentals of computers. When you work with linux you very often need to know the underlying mechanics of whatever you're working with. This goes hand in hand with being able to troubleshoot - a huge component of being an admin. Let's say you're troubleshooting an i/o issue on a server. When certain operations are performed on a SQL database in high volumes you notice the server starts to chug and i/o is severely bottlenecked. You need to know things like whether the RAID is configured correctly, and what the most optimal settings are for your usage. You need to know to check the i/o scheduler and make sure that's appropriate for what you're doing. Some of this stuff you won't know out of college, but you'll work with all of it eventually and pick it up. What counts is that you don't need somebody to explain the super basic stuff, you will already understand most things at a fairly high level. You should be able to pick things up quicker as a result, and cover significantly more ground than somebody learning Linux whose never really worked with computers seriously.
Anyway, that's longer than I meant to type up but hopefully you get the gist of what I'm saying. I'm slightly inebriated so sorry if my wording/sentence structure is hard to follow!
Most important: Have fun! If you're not enjoying it, get out because there's no point in wasting your life on this.
Learn to touch type: it's one of the most useful skills you can pick up and not just for IT work
Join your local Linux User Group. If your area doesn't have a LUG, start one! Put this on your CV.
Speaking of which, create a CV (resume) but putting down all the experience and skills you'd like to have. Then go and make it so! Get help with this by finding out which companies near you use Linux and asking for their help; which skills they're looking for and what technologies they're using. People are generally very happy to help people achieve things for themselves (and hate when they're really being asked to do the work for someone, so avoid that!).
Learn vi or emacs. It doesn't really matter which, just spend some time using it for all your text editing. Knowing a good text editor well is hugely important.
Distros: Install Gentoo from Stage 1 and run it for a while. Try Linux from Scratch at least once. Otherwise, just install a few different distros just for fun and to get an idea of what the differences are (they're not huge). Also, try out the BSDs at some point.
Learn and use git. It's quite simple to understand exactly how it works, so do this. Use it for day-to-day stuff. Get a github account and try contributing to other projects.
CLI. Use shell scripts for all sorts of things. Use one-line "for" loops for batch resizing images, or generating thumbnails. Forget about the GUI; it'll all have changed in a few years. CLI stuff will still be the same.
Web servers: learning Apache and ngnix. Get yourself something like an Amazon account. Whatever is cheapest. Use the API to create and remove servers and configure them.
Languages: shell scripting, Python and PHP are the ones you will encounter most. I see a bit of Ruby, but not a huge amount.
MySQL is very common. Again, learn the command line stuff, not some particular GUI.
Don't waste money on stupid stuff, aim to save about 65% of your net pay and become financially independent in 10 years.
Neither a borrower nor a lender be, For loan oft loses both itself and friend, And borrowing dulls the edge of husbandry.
....and that's about enough of that!
The 2013 Linux Jobs Report, conducted by Dice, [...] includes insights into why employers are seeking Linux talent now and what the top incentives are for Linux pros, among other important findings. Download the complete report [1]today.
By looking at the infograph, it seems developers, syadmins, and devops are amongst these 'UNIX pros', so not really kernel hackers. I'd assume few companies are in need of 'kernel hacking skills'.
[1]http://www.linuxfoundation.org/publications/linux-foundation...
A short list:
- Systems monitoring and being able to recognize and resolve performance problems
- Being able to fix/compile/modify/package software
- Being somewhat of a polyglot. Knowing shell, a few scripting languages, config languages, regular expressions, etc.
- Being able to identify and fix hardware related issues
A significant chunk of MS's total cost of ownership argument is the wages of Windows admins versus Linux admins. This news only gives that argument more weight at least in the short term.