Ask HN: How can a intermediate-beginner learn Unix/Linux and programming?
113 comments
I disagree with lots of advice here.
My strategy to solidify my linux skills was simple: commit to linux desktop. We spend most of our time on our desktop, may as well let that time earn you skill points. I picked ubuntu and use the same on servers. You naturally learn a bit every day through daily use. This really adds up over time without extra effort of using a side system. Getting good at windows or osx is a waste of your time unless you are specifically into those platforms.
As for a language, pick one that is (1) easy to start with (2) covers advanced use cases, (3) sound in its design, (4) general purpose, (5) concise. That rules out C (due to 1), JS (due to 3 and 4), php (2,3,4) and most things really.
For me that left me with ubuntu and python, I never looked back. (Yes I know many other things but that is my home base.)
My strategy to solidify my linux skills was simple: commit to linux desktop. We spend most of our time on our desktop, may as well let that time earn you skill points. I picked ubuntu and use the same on servers. You naturally learn a bit every day through daily use. This really adds up over time without extra effort of using a side system. Getting good at windows or osx is a waste of your time unless you are specifically into those platforms.
As for a language, pick one that is (1) easy to start with (2) covers advanced use cases, (3) sound in its design, (4) general purpose, (5) concise. That rules out C (due to 1), JS (due to 3 and 4), php (2,3,4) and most things really.
For me that left me with ubuntu and python, I never looked back. (Yes I know many other things but that is my home base.)
It is trendy to hate C now, but if you want to understand a Unix-like OS I think it is mandatory and they go hand in hand. Otherwise, you will have no idea what kind of interface your higher level language is abstracting.
It's ok to not like it, but don't let that dislike be due to lack of understanding.
It's ok to not like it, but don't let that dislike be due to lack of understanding.
Sure, drop into C sometimes.
But telling beginners to start there is mean.
I spent a lot of time in assembler too, and yes it has benefits for learning. Im also not recommending a high level toy like Logo.
I spent a lot of time in assembler too, and yes it has benefits for learning. Im also not recommending a high level toy like Logo.
I don't know if I understand that. Everyone was also a beginner at some point. I was a beginner at both C and Unix when I learned them together. I wrote a lot of bad C code before I got good at it.
I also say hand-in-hand as a bidirectional thing. I wouldn't suggest learning C without learning about Unix too. And I say that as someone who has worked extensively outside of Unix-like platforms.
I also say hand-in-hand as a bidirectional thing. I wouldn't suggest learning C without learning about Unix too. And I say that as someone who has worked extensively outside of Unix-like platforms.
Indeed. All the foundational common ground between all languages in Unix is made for C. I'm talking about the system call interface. All general purpose languages will have a wrapper for this interface, but the main documentation is made for C.
Besides that, libraries tend to be made in C as well. That's because if it's in C, it's easy to make it available for other languages. Most general purpose languages will have some type of "foreign function interface" to call on C code. That means that the main documentation for these libraries will be for C as well.
Besides that, libraries tend to be made in C as well. That's because if it's in C, it's easy to make it available for other languages. Most general purpose languages will have some type of "foreign function interface" to call on C code. That means that the main documentation for these libraries will be for C as well.
[deleted]
JS and php are perfectly suitable general purpose programming languages these days. And given they're both turing complete, they implicitly cover advanced use cases too.
So that leave us with "sound in its design" and I'd argue the absolute unmitigated disaster of python 2 vs 3, the numerous competing competing package managers, and the abundance of really bad code examples due to the influx of the mathematics world (just look at R), I fully disagree that python is a good choice.
But then again, that's just my opinion, but setting people off on an unnecessarily biased path with the assumption that there's only one way to do things definitely sounds like a pythonic behavioral trait.
So that leave us with "sound in its design" and I'd argue the absolute unmitigated disaster of python 2 vs 3, the numerous competing competing package managers, and the abundance of really bad code examples due to the influx of the mathematics world (just look at R), I fully disagree that python is a good choice.
But then again, that's just my opinion, but setting people off on an unnecessarily biased path with the assumption that there's only one way to do things definitely sounds like a pythonic behavioral trait.
I agree, and in addition, at early stages things like "sound design" don't even matter. You're busy understanding loops, try to interact with the file system, fetch stuff from the web, you're inevitably googling and copying a lot of bad code. Python 2 vs 3 doesn't matter at that point. PHP might even be the best choice here since you don't need to remember to import stuff, just start off with your code, all the functions are there.
Once you reach a point where you want to do more advanced stuff or just try out other languages you can still learn about include, import etc. and start to structure your code better by splitting it into compilation units, classes, modules, what not.
Once you reach a point where you want to do more advanced stuff or just try out other languages you can still learn about include, import etc. and start to structure your code better by splitting it into compilation units, classes, modules, what not.
Commit to using, breaking and fixing a Linux desktop to learn quickly. I learned a lot running Debian Unstable back back when men were men and unstable was really unstable; so the 2010s.
If minor things are constantly going wrong and getting fixed then the only way that can happen is the user building up a good mental model of how the system works.
An update that breaks X11 will teach you a world of information about terminals. "How do I use a messaging client in a terminal?", "What text editors work in a terminal?", "How do I browse the web from a terminal?", "What games are there for terminals", "How do I watch a movie in the terminal" (ascii).
Get forced to live like that for a week and you also learn how to fix X11 (eg, learning about the difference between 2D and 3D graphics drivers, OSS vs non-OSS drivers, kernel vs userspace). Valuable life skills. Godspeed to the Wayland devs.
If minor things are constantly going wrong and getting fixed then the only way that can happen is the user building up a good mental model of how the system works.
An update that breaks X11 will teach you a world of information about terminals. "How do I use a messaging client in a terminal?", "What text editors work in a terminal?", "How do I browse the web from a terminal?", "What games are there for terminals", "How do I watch a movie in the terminal" (ascii).
Get forced to live like that for a week and you also learn how to fix X11 (eg, learning about the difference between 2D and 3D graphics drivers, OSS vs non-OSS drivers, kernel vs userspace). Valuable life skills. Godspeed to the Wayland devs.
I would agree with this, but this is underspecified. A couple of examples:
When I was in college, a kid came to our * Nix User Group having fscked up his Ubuntu install by, I kid you not, `cd /; sudo rm -rf * `. He wanted help fixing it.
Another kid who was quite a bit smarter learned about fork bombs and ran one on a shared CS Linux server. It was offline for a few days. When it came back, `who` informed us that the sysadmin spent quite a bit of time running `man limits.conf`. (After graduating, I learned I was able to still login to that server using my SSH key, despite my account being deactivated in LDAP.)
It's a bit like Murphy's Law: anything that can be done on a * Nix machine will be done by a learner given sufficient time.
When I was in college, a kid came to our * Nix User Group having fscked up his Ubuntu install by, I kid you not, `cd /; sudo rm -rf * `. He wanted help fixing it.
Another kid who was quite a bit smarter learned about fork bombs and ran one on a shared CS Linux server. It was offline for a few days. When it came back, `who` informed us that the sysadmin spent quite a bit of time running `man limits.conf`. (After graduating, I learned I was able to still login to that server using my SSH key, despite my account being deactivated in LDAP.)
It's a bit like Murphy's Law: anything that can be done on a * Nix machine will be done by a learner given sufficient time.
For context, this was ~2008. I got my first personal laptop in middle school the only way I could manage: buy a two and a half year old hand me down Toshiba from my uncle for $200. It was too slow to be updated to a new Windows OS and I couldn’t afford the license anyway. My neighbor, a govt. systems programmer, told me about Linux. I looked it up and found Ubuntu. I installed it and encountered all of the problems the parent comment described. I learned a _lot_ for a 13 year old thanks to a great deal of very patient people on IRC. I spent most of my time alternating between debugging audio drivers so I could listen to music and trying to get wine to work so I could play games. When things were really running well, I’d mess with fancy window managers. This resulted in a lot of broken 3D drivers. Although I’ll admit I was interested in the naughty stuff, I either wasn’t motivated enough or wasn’t dumb enough to try it. Without a doubt, I screwed things up weekly. But 99% of my problems came from sudo apt-get upgrade rather than some other source. On some level, it blows me away to hear stories of people intentionally borking things like this. Perhaps I did stuff like this, quietly fixed it, and then forgot about it. Alternatively,when people taught me dangerous commands, I guess they just did a good job of explaining why and how they were dangerous.
Regardless, even if most will eventually do the worst, isn’t it worth it? Perhaps not in the case of the server, but arguably even then one could (perhaps facetiously) just say that the sysadmin learned as much as the student. For me, one thing is certain. It made a huge impact on my future.
Regardless, even if most will eventually do the worst, isn’t it worth it? Perhaps not in the case of the server, but arguably even then one could (perhaps facetiously) just say that the sysadmin learned as much as the student. For me, one thing is certain. It made a huge impact on my future.
> Commit to using, breaking and fixing a Linux desktop to learn quickly. I learned a lot running Debian Unstable back back when men were men and unstable was really unstable; so the 2010s.
Disagree. There's nothing worse than needing to use a machine, but you can't since it's broken because some package maintainer pushed a bad release upstream.
There will be plenty to fix and tweak on any standard desktop or laptop when you install Linux, especially Macs. Might as well use a distro and release channel that let's you get your work done.
IMO, the hours that I wasted learning how to fix XFree86 went to waste.
Disagree. There's nothing worse than needing to use a machine, but you can't since it's broken because some package maintainer pushed a bad release upstream.
There will be plenty to fix and tweak on any standard desktop or laptop when you install Linux, especially Macs. Might as well use a distro and release channel that let's you get your work done.
IMO, the hours that I wasted learning how to fix XFree86 went to waste.
My machine being broken in various ways pushed me to find workarounds.
I would've never gotten as comfortable in emacs or shell without breaking X11 and my login manager so many times
Some people are harshing on you for recommending Python because C is the unavoidable end-game in Unix. But I agree with the advice that Python is a great place to start.
Learn to write good Python. After that, learning to write good C will be much faster and easier and far less frustrating. Ultimately, on Unix you end up at C for at least some things (Python is implemented it C, after all). But these days, you can kick the can pretty darn far down the road before needing C.
Learn to write good Python. After that, learning to write good C will be much faster and easier and far less frustrating. Ultimately, on Unix you end up at C for at least some things (Python is implemented it C, after all). But these days, you can kick the can pretty darn far down the road before needing C.
Counterpoint: I’ve been a Linux sysadmin and developer for close to 10 years at this point and I’ve never used Linux as a desktop. I’ve only used MacBooks.
The skills you need to run Linux on the laptop aren’t particularly close to what you’d need to run Linux as a server, IMO, particularly Linux as a VM.
The skills you need to run Linux on the laptop aren’t particularly close to what you’d need to run Linux as a server, IMO, particularly Linux as a VM.
I remember I used Ubuntu Desktop in 2008 for a year or two. But Ubuntu is point and click and anyone can use it. I did not learn much about Linux using it.
I felt that I really started understanding how things work when I switched to something requiring more reading - Archlinux.
To get a running desktop it not only required doing all kinds of things I did not understand back then, it also provided great Wiki to get there. I still sometimes end up in that Wiki to quickly get up to speed about some tools or concepts.
And the fact that it is rolling release distro and was always running the latest upstream software version meant that frequently at least the UI part broke down, and that forced me to learn even more things. :)
That was only the beginning but now it feels like it opened many possibilities and career paths for me. It probably was a bit frustrating at the beginning but it is worth it.
I felt that I really started understanding how things work when I switched to something requiring more reading - Archlinux.
To get a running desktop it not only required doing all kinds of things I did not understand back then, it also provided great Wiki to get there. I still sometimes end up in that Wiki to quickly get up to speed about some tools or concepts.
And the fact that it is rolling release distro and was always running the latest upstream software version meant that frequently at least the UI part broke down, and that forced me to learn even more things. :)
That was only the beginning but now it feels like it opened many possibilities and career paths for me. It probably was a bit frustrating at the beginning but it is worth it.
Exactly the same experience can be had by installing Ubuntu server as your base and going from there.
Ubuntu server is the same distro as Ubuntu Desktop, just with some differences in preinstalled packages.
On Ubuntu Server it will still automatically install bootloader, configure initram, full disk encryption, etc. And after installing desktop environment packages it will configure, enable and start all of the services automatically.
While it is easier and the result looks the same, you are less involved in the process and thus potentially learn and understand less.
Just try setting up Gentoo or Archlinux and then tell me that it was the same experience as Ubuntu Server. ;)
On Ubuntu Server it will still automatically install bootloader, configure initram, full disk encryption, etc. And after installing desktop environment packages it will configure, enable and start all of the services automatically.
While it is easier and the result looks the same, you are less involved in the process and thus potentially learn and understand less.
Just try setting up Gentoo or Archlinux and then tell me that it was the same experience as Ubuntu Server. ;)
OS X exposes you to a decent amount of Unix stuff anyway. It’s quite a good compromise imo.
> , (5) concise. That rules out C (due to 1)
That's interesting, most people I've started on C have found it easier to start out in that than say, Java, which has been on a hell of a lot of introductory courses for a decade now
That's interesting, most people I've started on C have found it easier to start out in that than say, Java, which has been on a hell of a lot of introductory courses for a decade now
C is way more concise than Java. It's one of core 5 in any journeymans toolbelt.
[deleted]
My high school went from drawing flow charts to C and I find it very accessible to beginners to be honest.
Based on personal experience, I can totally echo this comment. I am a business undergrad (senior year), but I am a JavaScript developer for a local start-up. On my Windows laptop, my workflow included applications from MS Office, as well as PowerShell and Vim. At the beginning of this semester, my laptop broke (screen) and I couldn't afford a repair, so I dug up an old ThinkPad T430 that I installed Ubuntu on a couple years back. It was an old machine (2012?) that I bought used, after some searching done on my phone, I upgraded the OS and got to work.
Based on my experience with the switch, I've learned miles more about Linux and how computers work than I would've before. I might even say I like the experience more than I did before. On top of that, as the parent comment says, I've learned more about Linux, shell script, the directory tree, regular expressions, etc., than I think I would've otherwise by self-teaching. It might (read: "definitely will") be uncomfortable at first, but the Linux community is big and helpful and there's plenty of great open-source software that can replace your old workflows.
As far as picking a language goes, I started with Python for the reasons above, but really, starting anywhere is better than being stuck deciding. Common starting points are Python, Java, JavaScript, C#, but really, just pick any language with a large community to help you out. When you think you know enough, consider ideas for a personal project, which is where you'll likely learn the most. After that, keep learning and if you think you want to learn something else, you'll realize how much easier it will be with one language under your belt already.
Based on my experience with the switch, I've learned miles more about Linux and how computers work than I would've before. I might even say I like the experience more than I did before. On top of that, as the parent comment says, I've learned more about Linux, shell script, the directory tree, regular expressions, etc., than I think I would've otherwise by self-teaching. It might (read: "definitely will") be uncomfortable at first, but the Linux community is big and helpful and there's plenty of great open-source software that can replace your old workflows.
As far as picking a language goes, I started with Python for the reasons above, but really, starting anywhere is better than being stuck deciding. Common starting points are Python, Java, JavaScript, C#, but really, just pick any language with a large community to help you out. When you think you know enough, consider ideas for a personal project, which is where you'll likely learn the most. After that, keep learning and if you think you want to learn something else, you'll realize how much easier it will be with one language under your belt already.
And FYI I’m pretty sure you can run Hackintosh in that computer
100% agree with the 'just use it' part. I've been using Linux machines since the mid 2000's and the knowledge compounds over many years.
For programming language, I'd say Python is decent for a beginner. I've used Python as a language to teach some people programming, and the fact that they can do a wide variety of things (even games with Pygame) helps them stay engaged.
I would always recommend exploring other options as well though, to see what else is out there.
For programming language, I'd say Python is decent for a beginner. I've used Python as a language to teach some people programming, and the fact that they can do a wide variety of things (even games with Pygame) helps them stay engaged.
I would always recommend exploring other options as well though, to see what else is out there.
There's no such thing as Linux programming without C. You will have to deal with it eventually regardless of how many wrappers Python etc. puts on top of it.
Just because a C programming experience is possibly going to happen far off in the future doesn’t mean that beginners should commit to having a traumatizing ‘70s computing flashback as their first real programming experience.
I second this, yes you will make mistakes, yes you will break things but that's the way of learning (btw always have a live ISO of your distribution of choice in hand), additionally there's also linuxjourney.com which was an invaluable resource for me (I did the complete journey two or three times).
You can use a Linux desktop today without being exposed to the important stuff.
What is the lifecycle of a process and their states? What is a signal? What is a file descriptor, a socket? etc...
Can you say you know about Linux without being able to answer these questions?
What is the lifecycle of a process and their states? What is a signal? What is a file descriptor, a socket? etc...
Can you say you know about Linux without being able to answer these questions?
That's how I learned; on a good ol'fashion gentoo box.
learned so much about os stuff and kernel drivers, etc...
It was like diving in the deep end of a pool though.
learned so much about os stuff and kernel drivers, etc...
It was like diving in the deep end of a pool though.
Gentoo was the best Linux class until their Wiki nuked itself(can’t remember what happened exactly). I started with Ubuntu around 2007, got tired and moved to Gentoo right away. My Pentium 4 was heating up my whole room compiling things all night. Good times.
That's how I learned as well. I started using Ubuntu Linux on my laptop and was forced to use the command line to install programs.
Yes. Run a Linux desktop and only stay in it.
[deleted]
Completely agree with everything you said - great advice.
I agree with this recommendation, but Ubuntu is a PITA for a desktop IMO. Manjaro is much more stable, easier to setup and maintain and the default UI (XFCE) is simpler and very similar to Windows.
Ubuntu is good for a server. Using 2 different distros would be good to learn how not all Unixes/Linuxes are the same and how they might differ.
I would also add: Whatever programming language you learn, you're probably going to want to learn some auxiliary languages as well. Don't get stuck thinking you can do everything with one language. Learn JavaScript, SQL, HTML and CSS as well.
Ubuntu is good for a server. Using 2 different distros would be good to learn how not all Unixes/Linuxes are the same and how they might differ.
I would also add: Whatever programming language you learn, you're probably going to want to learn some auxiliary languages as well. Don't get stuck thinking you can do everything with one language. Learn JavaScript, SQL, HTML and CSS as well.
I agree you need to use it daily but disagree that an Ubuntu desktop provides any real insight.
Here's some BASIC questions an ubuntu user might never encounter:
Which processes are currently hogging the CPU?
Which ports are currently open?
How do you setup a remote git repo and/or add a user for limited ssh?
How do you increase an existing swap part without locking the CPU during write at peak loads?
How do you exclude/include packages from being autoupdated on apt update?
How do you ensure opaque crontabs aren't silently failing?
My advice: Setup a Linux server on aws or whatever for a paying customer with medium load. Only the stress of respondong to actual downtime will teach you anything useful.
Here's some BASIC questions an ubuntu user might never encounter:
Which processes are currently hogging the CPU?
Which ports are currently open?
How do you setup a remote git repo and/or add a user for limited ssh?
How do you increase an existing swap part without locking the CPU during write at peak loads?
How do you exclude/include packages from being autoupdated on apt update?
How do you ensure opaque crontabs aren't silently failing?
My advice: Setup a Linux server on aws or whatever for a paying customer with medium load. Only the stress of respondong to actual downtime will teach you anything useful.
I do not think my beginner advice would include "find someone who will pay you to do the thing you can't yet do"
I disagree. That's the way all business works. In the beginning.
The Missing Semester of Your CS Education [1] is a set of tutorials from MIT that gets you to speed with using the CLI, using a text editor (Vim), version controlling (using Git), basic debugging, etc.
Some tutorials aren't perfect (e.g., an earlier version had things like `for f in $(ls)` [3]), but at least they link to good tools and resources.
There's also Software Carpentry [2], which has similar goals.
You might also want to check out The Bash Guide [4,5], which is hands down the best Bash tutorial written.
[1]: https://missing.csail.mit.edu/
[2]: https://software-carpentry.org/lessons/index.html
[3]: https://mywiki.wooledge.org/ParsingLs
[4]: https://mywiki.wooledge.org/BashGuide
[5]: https://guide.bash.academy/
[1]: https://missing.csail.mit.edu/
[2]: https://software-carpentry.org/lessons/index.html
[3]: https://mywiki.wooledge.org/ParsingLs
[4]: https://mywiki.wooledge.org/BashGuide
[5]: https://guide.bash.academy/
I wonder if introducing newbies to makefiles and vim is super empowering, or ends up gatekeeping by making it look "as complicated as you feared it would be."
I feel like before any of that:
1. Do practical stuff with Python
2. Learn the semantics behind the Linux directory tree
3. CLI, piping stuff together, a little bit of bash.
I feel like before any of that:
1. Do practical stuff with Python
2. Learn the semantics behind the Linux directory tree
3. CLI, piping stuff together, a little bit of bash.
> I wonder if introducing newbies to makefiles and vim is super empowering, or ends up gatekeeping by making it look "as complicated as you feared it would be."
This tutorial introduces Vim only after introducing shell and pipes. I was wrong about makefiles -- this tutorial doesn't include makefiles (I was thinking about Software Carpentry [1], which has similar goals). In any case, learning Vim isn't hard as people make it out to be, and one can easily skip that part of the tutorial to come back to at a later point without breaking the continuity.
[1]: https://software-carpentry.org/lessons/index.html
This tutorial introduces Vim only after introducing shell and pipes. I was wrong about makefiles -- this tutorial doesn't include makefiles (I was thinking about Software Carpentry [1], which has similar goals). In any case, learning Vim isn't hard as people make it out to be, and one can easily skip that part of the tutorial to come back to at a later point without breaking the continuity.
[1]: https://software-carpentry.org/lessons/index.html
But at some point isn’t it helpful to know that some things are as difficult as you fear, and you just have to power through? I picked up vim early in my programming career and I think it was one of the best decisions I’ve made; I use it every day. Yeah, there’s a time and place for learning “easier” things, but there’s also a time to buckle down, get serious, and dig in.
i am a student and even using nano makes me feel less efficient and productive.
is there something I am missing out by not using vim?
is there something I am missing out by not using vim?
> is there something I am missing out by not using vim?
Being able to use vi is a very handy skill if you're a sysadmin or SSH into other computers/clusters very frequently. Since vi is part of the POSIX specification, all Unix systems would have some implementation of vi. Of course, Vim is much more powerful than a text editor like nano, but also requires more investment to learn. It won't make you a better programmer, but it might make you a faster programmer.
Being able to use vi is a very handy skill if you're a sysadmin or SSH into other computers/clusters very frequently. Since vi is part of the POSIX specification, all Unix systems would have some implementation of vi. Of course, Vim is much more powerful than a text editor like nano, but also requires more investment to learn. It won't make you a better programmer, but it might make you a faster programmer.
Learning vim at the level of vimtutor is helpful not only because it's a nearly ubiquitous editor with powerful capabilities, but also because the basic navigation is used as the default navigation method in a lot of unix command line utilities like 'less', 'diff', and the man pages.
(Oddly enough, the default navigation used for the info pages is that of emacs.)
Someone's reading this itching to type that you can simply switch the default navigation for those yourself, which is true, but it's still helpful to know these if you have to hop on someone else's machine or ssh into a remote server.
Try one of these editors for at least a month after doing the basic built-in tutorial (e.g., vimtutor) and go through the tutorial every Sunday or so as needed to refresh your memory.
Or you could also use Anki to remember the shortcuts as you learn about them and use them.
(Oddly enough, the default navigation used for the info pages is that of emacs.)
Someone's reading this itching to type that you can simply switch the default navigation for those yourself, which is true, but it's still helpful to know these if you have to hop on someone else's machine or ssh into a remote server.
Try one of these editors for at least a month after doing the basic built-in tutorial (e.g., vimtutor) and go through the tutorial every Sunday or so as needed to refresh your memory.
Or you could also use Anki to remember the shortcuts as you learn about them and use them.
It’s hard to look like a true haxxor.
My advice is to start working on a project you care about and then learn everything required to make it happen. If you already know JavaScript, maybe build and deploy a static website. Once you've done that then perhaps make it interact with an API.
This. Having something to actually accomplish is much more important than finding the ultimate book or online course.
There are lots of those.
Pick one and move on to defining a realistic project that seems interesting and achievable.
Most important of all, finish it, and write what you did down somewhere. It took me 20 years to realize how important this is.
Pick one and move on to defining a realistic project that seems interesting and achievable.
Most important of all, finish it, and write what you did down somewhere. It took me 20 years to realize how important this is.
If you are on Windows I recommend setting up Windows Subsystem for Linux. With VScode. You now have a Linux server with remote code editing. I note you have an Raspberry pi, what follows will work with the pi as well with whatever remote machine. Complete these tasks
1) install the language of your choice and start a simple web site using the languages webserver. View the website in your browser on Windows. A Python Flask 'hello world' or a Node one?
2) Set up an SSH server and remote in from the Windows machine. Learn how to set it up to use keys only instead of passwords. Find out why that is a good idea
3) learn Git. Github has some nice tutorials.
4) set up NGinx to run your website above.
5) set up Nginx for https
6) set up LetsEncrypt.
7) set up a free AWS account, start a server and put your website on it using SSH and git.
8) look through the ssh log files to see login attempts, and the Nginx logs. Imagine there were millions of rows, how would you find a certain one, or the last few? (head, tail, grep, cat).
That should get you somewhere.!
1) install the language of your choice and start a simple web site using the languages webserver. View the website in your browser on Windows. A Python Flask 'hello world' or a Node one?
2) Set up an SSH server and remote in from the Windows machine. Learn how to set it up to use keys only instead of passwords. Find out why that is a good idea
3) learn Git. Github has some nice tutorials.
4) set up NGinx to run your website above.
5) set up Nginx for https
6) set up LetsEncrypt.
7) set up a free AWS account, start a server and put your website on it using SSH and git.
8) look through the ssh log files to see login attempts, and the Nginx logs. Imagine there were millions of rows, how would you find a certain one, or the last few? (head, tail, grep, cat).
That should get you somewhere.!
Thanks this is helpful to get started.
Some resources I've found helpful to learn some command-line:
- https://cmdchallenge.com/. This set of increasing-in-difficulty challenges should help with structure in terms of learning a bit more.
- https://explainshell.com/ can be helpful as well.
- Don't forget the man pages! `man <command>` can be quite helpful! For a different approach on teaching some, bropages.org could be helpful.
- I haven't used it personally, but there is a lot of info at http://www.opsschool.org/
As for learning to program, I suggest a very good starter language is Python, and its built-in, first-party language reference/tutorial I found helpful when I learned it: https://docs.python.org/3.8/tutorial/index.html
As for "what" to program after that, I don't have any great resources for what constitutes some good initial programs. Off the top of my head, here are some ideas about places to start which are doable with only inputting and outputting text:
- FizzBuzz
- Play Rock Paper Scissors with the computer
- Play Tic Tac Toe with the Computer
- Sieve of Eratosthenes
- Conway's Game of Life
- Given a piece of text, count how many occurrences of each word there are and display the top ten.
- https://cmdchallenge.com/. This set of increasing-in-difficulty challenges should help with structure in terms of learning a bit more.
- https://explainshell.com/ can be helpful as well.
- Don't forget the man pages! `man <command>` can be quite helpful! For a different approach on teaching some, bropages.org could be helpful.
- I haven't used it personally, but there is a lot of info at http://www.opsschool.org/
As for learning to program, I suggest a very good starter language is Python, and its built-in, first-party language reference/tutorial I found helpful when I learned it: https://docs.python.org/3.8/tutorial/index.html
As for "what" to program after that, I don't have any great resources for what constitutes some good initial programs. Off the top of my head, here are some ideas about places to start which are doable with only inputting and outputting text:
- FizzBuzz
- Play Rock Paper Scissors with the computer
- Play Tic Tac Toe with the Computer
- Sieve of Eratosthenes
- Conway's Game of Life
- Given a piece of text, count how many occurrences of each word there are and display the top ten.
My approach to teaching Linux and programming leans heavily on using existing resources and ensuring students get a wide base of knowledge before beginning the "exploratory" stage of learning.
Start with installing a distro of your choice in a virtualization tool, I always recommend Ubuntu on VMWarePlayer because it was what I started with. Distro/Virtualization Software doesn't matter, what matters is that you use it.
Then I have students work through Linux Journey [1] one module at a time, while being available to answer questions as they go.
Once a student has finished the LJ modules I have them play the Bandit Over the Wire [2] game up to challenge 15.
After that I usually teach Hardware and Operating Systems, but if you are just looking for general ability to do things, skip to the CyberAces Linux modules. [3]
Once you have finished those, do the CyberAces Bash Scripting module and the CodeAcademy Python [4] course and you'll have enough scripting ability to be dangerous.
From there, just keep using Linux as your daily driver and you will continue to improve, especially if you take on programming projects.
All of this can be done by yourself, but I teach a free online course on Computing Fundamentals and Security if you are interested in it being more of a guided experience. [5]
[1] https://linuxjourney.com/ [2] http://overthewire.org/wargames/bandit/ [3] https://tutorials.cyberaces.org/tutorials.html [4] https://www.codecademy.com/learn/learn-python [5] https://www.hoppersroppers.org/course.html
Start with installing a distro of your choice in a virtualization tool, I always recommend Ubuntu on VMWarePlayer because it was what I started with. Distro/Virtualization Software doesn't matter, what matters is that you use it.
Then I have students work through Linux Journey [1] one module at a time, while being available to answer questions as they go.
Once a student has finished the LJ modules I have them play the Bandit Over the Wire [2] game up to challenge 15.
After that I usually teach Hardware and Operating Systems, but if you are just looking for general ability to do things, skip to the CyberAces Linux modules. [3]
Once you have finished those, do the CyberAces Bash Scripting module and the CodeAcademy Python [4] course and you'll have enough scripting ability to be dangerous.
From there, just keep using Linux as your daily driver and you will continue to improve, especially if you take on programming projects.
All of this can be done by yourself, but I teach a free online course on Computing Fundamentals and Security if you are interested in it being more of a guided experience. [5]
[1] https://linuxjourney.com/ [2] http://overthewire.org/wargames/bandit/ [3] https://tutorials.cyberaces.org/tutorials.html [4] https://www.codecademy.com/learn/learn-python [5] https://www.hoppersroppers.org/course.html
a really good book is Richard Stevens Advanced Programming in the UNIX environment[1]. (sounds daunting but it's not too bad when you combine it with another introductory text on C). If you stick with C you'll eventually know UNIX/Linux a lot deeper than anyone. It takes time though so go easy on yourself.
Also check github for a bunch of repos that contain biolerplate code that is used in most deamons illustrating signal handling, forking, etc.[2]
Also I suggest taking some open source projects from Daniel Bernstein (DJB) as examples on how to write secure code. qmail, djbdns, daemontools ... there are lots of great ideas there[3]
Write a couple of simple programs that utilize your code and expand from there, learn the plumbing, e.g. write a Makefile, learn autotools/autoconf, how to write tests, how to use gdb, how to create shared libs and link a program LD_LIBRARY_PATH/ldconfig, etc ...
Most important think about something that you like to write and go from there. Back in the late 90ies I studied RFC's (MIME, SMTP, etc) and then implemented things that I could actually use myself. Here is a recent project I did some weeks ago (an extreme edge-case for security maximalists which will never be used by anyone other then myself, ... but I really enjoyed writing this and learned a bunch of new stuff while doing so)[4]
if you need ideas or help with looking at your code, don't hesitate and send me a mail.
[1] https://en.wikipedia.org/wiki/Advanced_Programming_in_the_Un...
[2] https://github.com/jirihnidek/daemon
[3] https://cr.yp.to/djb.html
[4] https://github.com/DyslexicAtheist/nfq/
Also check github for a bunch of repos that contain biolerplate code that is used in most deamons illustrating signal handling, forking, etc.[2]
Also I suggest taking some open source projects from Daniel Bernstein (DJB) as examples on how to write secure code. qmail, djbdns, daemontools ... there are lots of great ideas there[3]
Write a couple of simple programs that utilize your code and expand from there, learn the plumbing, e.g. write a Makefile, learn autotools/autoconf, how to write tests, how to use gdb, how to create shared libs and link a program LD_LIBRARY_PATH/ldconfig, etc ...
Most important think about something that you like to write and go from there. Back in the late 90ies I studied RFC's (MIME, SMTP, etc) and then implemented things that I could actually use myself. Here is a recent project I did some weeks ago (an extreme edge-case for security maximalists which will never be used by anyone other then myself, ... but I really enjoyed writing this and learned a bunch of new stuff while doing so)[4]
if you need ideas or help with looking at your code, don't hesitate and send me a mail.
[1] https://en.wikipedia.org/wiki/Advanced_Programming_in_the_Un...
[2] https://github.com/jirihnidek/daemon
[3] https://cr.yp.to/djb.html
[4] https://github.com/DyslexicAtheist/nfq/
> Also check github for a bunch of repos that contain biolerplate code that is used in most deamons illustrating signal handling, forking, etc.[2]
docker-systemctl-replacement is a (partial) reimplementation of systemd as one python script that can be run as the init process of a container that's helpful for understanding how systemd handles processes: https://github.com/gdraheim/docker-systemctl-replacement/blo...
systemd is written in C: https://github.com/systemd/systemd
> examples of how to write secure code
awesome-safety-critical > Coding Guidelines https://github.com/stanislaw/awesome-safety-critical/blob/ma...
docker-systemctl-replacement is a (partial) reimplementation of systemd as one python script that can be run as the init process of a container that's helpful for understanding how systemd handles processes: https://github.com/gdraheim/docker-systemctl-replacement/blo...
systemd is written in C: https://github.com/systemd/systemd
> examples of how to write secure code
awesome-safety-critical > Coding Guidelines https://github.com/stanislaw/awesome-safety-critical/blob/ma...
Download Ubuntu and run it as a virtual machine inside your current machine (use Google for instructions - it's fairly straightforward with a piece of software called virtualbox). That should stop you from running into hardware related compatibility issues.
Get familiar with the interface and the concept of a "terminal".
Then try do some simple stuff. Maybe set up nginx (or Apache) to run a web server that you can access via your host machine.
Thereafter try doing some Linux admin tasks, like creating users, switching users. Maybe even set up SSH and try accessing the virtual machine from your host machine via PuTTY.
After, maybe try spinning up a simple node web app on the virtual machine and access it from a browser on your host machine.
By this time, you'll probably get a sense of what you want to explore next! And remember, Google it's your friend for all of the above!
All the best :)
Get familiar with the interface and the concept of a "terminal".
Then try do some simple stuff. Maybe set up nginx (or Apache) to run a web server that you can access via your host machine.
Thereafter try doing some Linux admin tasks, like creating users, switching users. Maybe even set up SSH and try accessing the virtual machine from your host machine via PuTTY.
After, maybe try spinning up a simple node web app on the virtual machine and access it from a browser on your host machine.
By this time, you'll probably get a sense of what you want to explore next! And remember, Google it's your friend for all of the above!
All the best :)
I’ll probably use my raspberry pi instead of installing a VM.
You should check out Harvard's CS50x on edx.
It's probably the best introduction to CS and programming online and teaches you the basics of the command line and C along the way.
Depending on the CS program, it's roughly equivalent of the first 1-3 semesters at a more average university, but the quality of the pedagogy is so high that it's very doable for anyone willing to put in the work.
It's probably the best introduction to CS and programming online and teaches you the basics of the command line and C along the way.
Depending on the CS program, it's roughly equivalent of the first 1-3 semesters at a more average university, but the quality of the pedagogy is so high that it's very doable for anyone willing to put in the work.
Sure - the only benefit of a VM is that you can mess up the VM's filesystem without worrying about it too much.
Making terrible mistakes on real machines teaches you much more though (by sheer necessity if nothing else).
It might, but I'm not going to suggest that to someone trying to learn the ropes!
Jump in on the deep end. Install Arch, a tiling wm of some sort, and make it yours. Soon enough you realise this isn't the deep end anymore. You get a lot for free by just using linux every day and dealing with whatever problems might pop up.
Keep the terminal open, if it can be done in a terminal it may turn out you prefer it when you get used to it. Torrents, IRC, playing music, email, file explorer, whatever makes you stay in there. It makes you comfortable navigating the system and you get to see what a GUI hides from you.
Programming? You're not gonna benefit from diving into any deep ends there, continue with JS if that's what you like. Learn databases and web servers, here your new linux skills comes in use. Try some stuff and see what you like.
Keep the terminal open, if it can be done in a terminal it may turn out you prefer it when you get used to it. Torrents, IRC, playing music, email, file explorer, whatever makes you stay in there. It makes you comfortable navigating the system and you get to see what a GUI hides from you.
Programming? You're not gonna benefit from diving into any deep ends there, continue with JS if that's what you like. Learn databases and web servers, here your new linux skills comes in use. Try some stuff and see what you like.
I would recommend learning Linux the way I did 15 or so years ago: get rid of other operating systems and use a more 'advanced' distribution (such as Arch or Gentoo). In my case, I fucked up my Windows install on a new laptop when I was 12. At that point, I was stuck and just decided to stick with Linux. It's remarkable how quickly you learn when you absolutely need to in order to use the computer.
My second piece of advice would be to learn C from this book: https://en.wikipedia.org/wiki/The_C_Programming_Language
After finishing it and completing all the exercises, you should be ready to go learn anything else you want to.
My second piece of advice would be to learn C from this book: https://en.wikipedia.org/wiki/The_C_Programming_Language
After finishing it and completing all the exercises, you should be ready to go learn anything else you want to.
Better is the way I learned it 25 years ago. Burn up your 386sx CPU while doing a kernel build, then get a loan for a nicer computer. It should have at least 4 MB of ram. Spend about 200x minimum houry wage on a nice monitor, then be very careful with manual modeline settings in your xfree86 config so that you don't destroy the monitor.
Get yourself a bulldog clip to hold that send book open to the page you are repeated referring to. When you graduate to Stephens' UNIX Systems Programming, the bulldog clip won't be needed.
If your monitor doesn't stand tall enough, 4 reams of copy paper are much cheaper than the same thickness of X programming manuals.
Get yourself a bulldog clip to hold that send book open to the page you are repeated referring to. When you graduate to Stephens' UNIX Systems Programming, the bulldog clip won't be needed.
If your monitor doesn't stand tall enough, 4 reams of copy paper are much cheaper than the same thickness of X programming manuals.
For programming, start by having a project. Think about something you’d like to build and focus on one thing at a time. This will guide your research.
For Unix, install linux on your computer and use it daily. You’ll be forced to learn.
For Unix, install linux on your computer and use it daily. You’ll be forced to learn.
>For Unix, install linux on your computer and use it daily. You’ll be forced to learn.
I tried this years ago and it didn't end well. With how complicated current-gen distros are, you need to understand what's going on under the hood before you can effectively mess with it. In my experience you'll just end up with one screen that's only at 720p and a crashed pulseaudio that you never fix because you just want to watch netflix right now, and for some reason that still works as long as you use bluethooth. Even though you didn't want to use your bluetooth headphones, it's easier than fixing the problem with your sound driver or whatever so you'll just end up using them anyway.
It might be easier to start with server management because you don't have to figure out much human IO stuff... Linux is really good at talking to Linux. VPSs are cheap and give you root access. Plus if you mess up, it's generally pretty easy to just format the VPS and start over. You can't easily do the same on a desktop. Also it forces you to learn about Linux and not whatever software your distro uses (for example, learning how to use apt is a lot more important than the ubuntu app store)
I tried this years ago and it didn't end well. With how complicated current-gen distros are, you need to understand what's going on under the hood before you can effectively mess with it. In my experience you'll just end up with one screen that's only at 720p and a crashed pulseaudio that you never fix because you just want to watch netflix right now, and for some reason that still works as long as you use bluethooth. Even though you didn't want to use your bluetooth headphones, it's easier than fixing the problem with your sound driver or whatever so you'll just end up using them anyway.
It might be easier to start with server management because you don't have to figure out much human IO stuff... Linux is really good at talking to Linux. VPSs are cheap and give you root access. Plus if you mess up, it's generally pretty easy to just format the VPS and start over. You can't easily do the same on a desktop. Also it forces you to learn about Linux and not whatever software your distro uses (for example, learning how to use apt is a lot more important than the ubuntu app store)
I don’t know how long ago you’ve tried it, but that was pretty much my experience as well. However, in my case we are talking late 90’s. Things have changed a lot since then.
About 3-4 years ago. I disagree with most poeple that say it's just as easy as using w10 now, it takes way more work to make it as stable as windows (which takes none). It's just a lot more powerful and easy to modify when you want it to be.
BTW if the OP (or anyone else) is wondering, now I run w10 and minimal Ubuntu with i3. The knowledge transferred basically 1:1 from server management (except for window manager stuff, but that was easy to research)
BTW if the OP (or anyone else) is wondering, now I run w10 and minimal Ubuntu with i3. The knowledge transferred basically 1:1 from server management (except for window manager stuff, but that was easy to research)
Here's a couple of tutorials on various tools that might be useful for a beginner:
https://missing.csail.mit.edu/
Raspberry Pi and free trials to O'Reilly Online (which I currently now subscribe and don't need credit card to sign up for). They've been giving 50% off Black Friday Special, so keep eye out for that.
Here are some of my favorite books:
https://learning.oreilly.com/library/view/ubuntu-server-cook... - really good one for learning real uses of linux
https://learning.oreilly.com/library/view/raspberry-pi-cookb...
https://learning.oreilly.com/library/view/raspberry-pi-netwo...
https://learning.oreilly.com/library/view/exploring-raspberr...
https://learning.oreilly.com/library/view/raspberry-pi-hacks...
Here are some of my favorite books:
https://learning.oreilly.com/library/view/ubuntu-server-cook... - really good one for learning real uses of linux
https://learning.oreilly.com/library/view/raspberry-pi-cookb...
https://learning.oreilly.com/library/view/raspberry-pi-netwo...
https://learning.oreilly.com/library/view/exploring-raspberr...
https://learning.oreilly.com/library/view/raspberry-pi-hacks...
Its very easy to get good with unix. I usually use the tee rule for this (look up tee on google ;) )
1) Get a good linux, you can start with ubuntu. After getting comfy with ubuntu try another os, debian,And eventually to the hardcore ones like Arch, Artix and others. Try to do your usual thing with commandline. For example, How to copy using terminal,How to open a file with terminal, How to get lots of terminals inside terminal. Stuffs like this (trick is simply go ahead and add "How to do it in terminal" ;) ) Google them up. (www.giyf.com) Try to rice your system. It teaches crucial aspects about the appearance,usability etc.
2) Get a good book. No starch press has some good ones, even O reilly gets you into shape. The trick to good book is simple: Get a book, read it. If you love it finish it. There are open source notes as well. Awesome cli github is similar.
3) Try to create your own tools using 1,2 this will allow you to bend your brain. Stuffs like How can I get hackernews comments in my terminal, How can I create a shell script to remind me that 20mins have passed (pomodoro) and stuffs like that.
I have some starred repositories and Some simple tools of my own (Aeres-u99 @github) to check for some example.
I think with this (depending how extensively you do them) you can be decent
1) Get a good linux, you can start with ubuntu. After getting comfy with ubuntu try another os, debian,And eventually to the hardcore ones like Arch, Artix and others. Try to do your usual thing with commandline. For example, How to copy using terminal,How to open a file with terminal, How to get lots of terminals inside terminal. Stuffs like this (trick is simply go ahead and add "How to do it in terminal" ;) ) Google them up. (www.giyf.com) Try to rice your system. It teaches crucial aspects about the appearance,usability etc.
2) Get a good book. No starch press has some good ones, even O reilly gets you into shape. The trick to good book is simple: Get a book, read it. If you love it finish it. There are open source notes as well. Awesome cli github is similar.
3) Try to create your own tools using 1,2 this will allow you to bend your brain. Stuffs like How can I get hackernews comments in my terminal, How can I create a shell script to remind me that 20mins have passed (pomodoro) and stuffs like that.
I have some starred repositories and Some simple tools of my own (Aeres-u99 @github) to check for some example.
I think with this (depending how extensively you do them) you can be decent
There are many ways, but here is one:
Read and lightly work through The C Programming Language (K&R). Code along with the book, don’t feel you have to really deep-dive anything.
You don’t have to learn C well at this point. Just learn from it.
Then start reading The Art Of Unix Programming. Do this casually. Read a bit, code a bit. Between K&R and TAOUP, you’ll be inspired by to write at least two small projects.
To supplement K&R and TAOUP, begin reading Unix Network Programming.
If you have access to a Mac or a Linux machine, explore the man pages.
If you’re on a Mac, explore the man pages __and__ the code that lives on your system.
One way to do this is to use something like vscode’s intellisense to “Go to Definition.” E.g., when you’re coding an example from K&R, right click on one of the included headers, and click “Go to definition.” It will take you to the header file. Look through the code. Then you could look at the code from FreeBSD or OpenBSD on GitHub.
Edit: Just wanted to add, by doing the above you’ll get exposure to your system in new ways. Moreover, you’ll find yourself learning Unix out of necessity, for fun, and by accident. You can practice the art of Unix programming in almost any language at this point. C is unix-y, but so is Rust.
Read and lightly work through The C Programming Language (K&R). Code along with the book, don’t feel you have to really deep-dive anything.
You don’t have to learn C well at this point. Just learn from it.
Then start reading The Art Of Unix Programming. Do this casually. Read a bit, code a bit. Between K&R and TAOUP, you’ll be inspired by to write at least two small projects.
To supplement K&R and TAOUP, begin reading Unix Network Programming.
If you have access to a Mac or a Linux machine, explore the man pages.
If you’re on a Mac, explore the man pages __and__ the code that lives on your system.
One way to do this is to use something like vscode’s intellisense to “Go to Definition.” E.g., when you’re coding an example from K&R, right click on one of the included headers, and click “Go to definition.” It will take you to the header file. Look through the code. Then you could look at the code from FreeBSD or OpenBSD on GitHub.
Edit: Just wanted to add, by doing the above you’ll get exposure to your system in new ways. Moreover, you’ll find yourself learning Unix out of necessity, for fun, and by accident. You can practice the art of Unix programming in almost any language at this point. C is unix-y, but so is Rust.
Not sure about TAOUP. THere's a lot of verbiage there.
Use Slackware, do these exercises:
- Customize your bash prompt, create aliases for some common commans (ls, df are good)
- Build a LAMP stack, compile everything from source tarballs. Get it working so that you're able to browse your webserver from your phone.
- Update a sound or video driver
- After you're comfortable, recompile the kernel
- Through these, do as much in the command line as you can. Get comfortable with mv rm chmod chown and so on.
Any time you have edit a text file, use vim, nothing else.
- Customize your bash prompt, create aliases for some common commans (ls, df are good)
- Build a LAMP stack, compile everything from source tarballs. Get it working so that you're able to browse your webserver from your phone.
- Update a sound or video driver
- After you're comfortable, recompile the kernel
- Through these, do as much in the command line as you can. Get comfortable with mv rm chmod chown and so on.
Any time you have edit a text file, use vim, nothing else.
I strongly recommend Rochkind - Advanced Unix Programming.
Despite the title, it's not that advanced; the "advanced" here refers to system-level programming, not application.
Note, for this you probably need to learn C.
K&R ed2 remains an excellent book for this.
Honorary mention - Kernighan and Pike - Unix Programming Environment. But it's a little dated.
Above all, do. Get a Ubuntu or Centos image, install developer tools (gcc), manpages, and write some code.
Despite the title, it's not that advanced; the "advanced" here refers to system-level programming, not application.
Note, for this you probably need to learn C.
K&R ed2 remains an excellent book for this.
Honorary mention - Kernighan and Pike - Unix Programming Environment. But it's a little dated.
Above all, do. Get a Ubuntu or Centos image, install developer tools (gcc), manpages, and write some code.
Hm, in my case, I followed a very boring/the right way of doing things,
For example : try getting the book "the Linux programming interface" it s very handy and explains pretty much everything u de want to know about anything in a Linux operation system, it lists and explains the POSIX interface made for you to use in you C code , with example, which surprisingly, u get to find similar interfaces/system calls/library functions that you can use in python to do the same thing.
For regular expressions, watching a small video which explains how they work is definitely more productive, but if you could find some time to spare , try checking how compilers are made, / what constitutes a language (language theory), and automata, it definitely has some math in it , but it s worth it, it gives you an extra mental image , which helps you get a better understanding of where you stand and what you can do. Since apparently regex is also a language, which helps you describe chunks of an other languages and it also has some limitations to be aware of.
For regular expressions, watching a small video which explains how they work is definitely more productive, but if you could find some time to spare , try checking how compilers are made, / what constitutes a language (language theory), and automata, it definitely has some math in it , but it s worth it, it gives you an extra mental image , which helps you get a better understanding of where you stand and what you can do. Since apparently regex is also a language, which helps you describe chunks of an other languages and it also has some limitations to be aware of.
I’m primarily a windows user and am programming to create products.
Since I don’t work a programmer job, my learning is unstructured. Is bash the main benefit of learning something like Ubuntu?
I have delayed making the switch because I have lot of things to learn (currently relearning math, testing out different deep learning architectures, and learning JavaScript (second language after Python)) and not sure if should prioritize learning it.
I still need to get better with GitHub which is something I clearly see the benefits of. Also need to get better with a text editor , using Visual Studio Code , mainly just for text completion in Python and JavaScript, so need to learn the additional benefits. Also want to test sublime text.
I see recommendations for vim, but I wonder if that will make me too twitchy and will start to type before thinking.
So due to the amount of things I am trying to learn, I have delayed learning Ubuntu.
I know Windows 10 now has built-in bash capabilities but I wonder if there are other benefits I am missing with Linux and worth learning.
I have delayed making the switch because I have lot of things to learn (currently relearning math, testing out different deep learning architectures, and learning JavaScript (second language after Python)) and not sure if should prioritize learning it.
I still need to get better with GitHub which is something I clearly see the benefits of. Also need to get better with a text editor , using Visual Studio Code , mainly just for text completion in Python and JavaScript, so need to learn the additional benefits. Also want to test sublime text.
I see recommendations for vim, but I wonder if that will make me too twitchy and will start to type before thinking.
So due to the amount of things I am trying to learn, I have delayed learning Ubuntu.
I know Windows 10 now has built-in bash capabilities but I wonder if there are other benefits I am missing with Linux and worth learning.
> I’m primarily a windows user and am programming to create products. Since I don’t work a programmer job, my learning is unstructured. Is bash the main benefit of learning something like Ubuntu?
That's one advantage. The big advantage is that most enterprise web sites and webservices run either on a rented Linux server or on a Linux instance that's "serverless" (meaning it can run processes and access databases, but can't save stuff permanently to the filesystem). If you have familiarity with Linux, then that lends itself well to the work of troubleshooting the complications that come with that setup.
That's one advantage. The big advantage is that most enterprise web sites and webservices run either on a rented Linux server or on a Linux instance that's "serverless" (meaning it can run processes and access databases, but can't save stuff permanently to the filesystem). If you have familiarity with Linux, then that lends itself well to the work of troubleshooting the complications that come with that setup.
It's just easier to get going with programming stuff on linux (other than .net)
Need python? Ruby? docker? A different compiler or a specific library? They're just an apt-get install away. It just feels more natural and integrated.
Windows has always been an odd duck for programming on.
Need python? Ruby? docker? A different compiler or a specific library? They're just an apt-get install away. It just feels more natural and integrated.
Windows has always been an odd duck for programming on.
I learned SunOS (and later Linux and HP-UX) by full immersion with a non-root account on a multiuser server. It was non-graphical, though I was able to tunnel X over SSH across the Internet and actually have an almost usable desktop.
I was learning C programming at the time, so beyond dealing with bizarre things like my program crashing due to "segmentation fault"s, I was trying to understand what was going on. The first time I opened vi, I couldn't figure out how to get out. Once I did, I used `:sav %` followed by `:q` for longer than I care to admit.
If I had to recommend anything to someone just learning, I'd recommend learning these commands:
cd ls touch rm # but be careful! ps head tail nano who whoami man apropos # this is technically man less
These will help you do a lot of what you need to do on Linux about as well as you can do similar things on Windows. Once you've mastered those commands, learn about piping `|`, grouping `{ foo; bar; }` and sub-shells `$(foo)`. Learning about variables `$foo`
Then read up on:
grep sed cut find awk # really just `awk '{ print $2 }'` xargs env export test # [ foo ] source # . foo crontab top # or even better `htop` shell control flow
When you're done with that, learn
vim # `vimtutor` can help emacs
After that, there's tons of other tools you'll pick up as needed:
dd df du fsck and a bunch of other system-related tools
You'll learn a ton as you move along.
Just remember that for the most part, each tool solves approximately one problem, and the complex behavior comes from chaining tools together. Chaining mostly involves `|`. Once you see that at work, you probably won't want to go back to the crutch of point-click-drag.
Best of luck!
I was learning C programming at the time, so beyond dealing with bizarre things like my program crashing due to "segmentation fault"s, I was trying to understand what was going on. The first time I opened vi, I couldn't figure out how to get out. Once I did, I used `:sav %` followed by `:q` for longer than I care to admit.
If I had to recommend anything to someone just learning, I'd recommend learning these commands:
cd ls touch rm # but be careful! ps head tail nano who whoami man apropos # this is technically man less
These will help you do a lot of what you need to do on Linux about as well as you can do similar things on Windows. Once you've mastered those commands, learn about piping `|`, grouping `{ foo; bar; }` and sub-shells `$(foo)`. Learning about variables `$foo`
Then read up on:
grep sed cut find awk # really just `awk '{ print $2 }'` xargs env export test # [ foo ] source # . foo crontab top # or even better `htop` shell control flow
When you're done with that, learn
vim # `vimtutor` can help emacs
After that, there's tons of other tools you'll pick up as needed:
dd df du fsck and a bunch of other system-related tools
You'll learn a ton as you move along.
Just remember that for the most part, each tool solves approximately one problem, and the complex behavior comes from chaining tools together. Chaining mostly involves `|`. Once you see that at work, you probably won't want to go back to the crutch of point-click-drag.
Best of luck!
Learning is always easy when you can scratch your own itch with spare time.
Since computing was my escape from a pretty unhealthy environment at home (alcoholics, TV) and computer games/hardware were prohibitively expensive beyond Quake 2, routine saved the day: go to high school, come home and zone into computer for 4 years. A couple years in I started getting small gigs, then a lot of them, then got on the FTE track and hit $200k/yr by 30.
As an adult, I’ve had 6 years of fitness starting with forcing myself to spend 45min/day with no plan in the gym until it felt weird to not go, and now I could easily get on track to become a trainer if I wanted. I got 50lbs overweight over a few years from being so steeped in building software and networking with beer and pizza. I’m mistaken for early 20’s at age 35 universally.
You have to intrinsically enjoy it, and then make time for it.
Since computing was my escape from a pretty unhealthy environment at home (alcoholics, TV) and computer games/hardware were prohibitively expensive beyond Quake 2, routine saved the day: go to high school, come home and zone into computer for 4 years. A couple years in I started getting small gigs, then a lot of them, then got on the FTE track and hit $200k/yr by 30.
As an adult, I’ve had 6 years of fitness starting with forcing myself to spend 45min/day with no plan in the gym until it felt weird to not go, and now I could easily get on track to become a trainer if I wanted. I got 50lbs overweight over a few years from being so steeped in building software and networking with beer and pizza. I’m mistaken for early 20’s at age 35 universally.
You have to intrinsically enjoy it, and then make time for it.
Buy this book: https://nostarch.com/tlpi
Some may argue that you can get the information in this book for free, by consulting man pages and such. Sure you can, but it will just take you much longer. This book will save you time.
Some may argue that you can get the information in this book for free, by consulting man pages and such. Sure you can, but it will just take you much longer. This book will save you time.
[deleted]
You can either reach out to some influencers and ask them to help them in their projects for free in exchange for receiving knowledge or you can head to some websites regarding the language you are planning to run.
My personal suggestion would be to do both. Follow Scott Berkun - his blog, Twitter, he knows his stuff.
You also need to some sites and courses to guide you throughout your journey. This article (https://blog.codegiant.io/5-best-websites-for-learning-progr...) has some cool sites for learning programming.
All in all, the best way to excel is to find a mentor.
My personal suggestion would be to do both. Follow Scott Berkun - his blog, Twitter, he knows his stuff.
You also need to some sites and courses to guide you throughout your journey. This article (https://blog.codegiant.io/5-best-websites-for-learning-progr...) has some cool sites for learning programming.
All in all, the best way to excel is to find a mentor.
If you are interested in a course to get comfortable with the shell in unix I highly recommend this course. I'm taking it now and it's quite well done.
https://www.edx.org/course/unix-tools-data-software-and-prod...
More info about week 1: https://www.reddit.com/r/linux/comments/flmr8o/enjoying_the_...
https://www.edx.org/course/unix-tools-data-software-and-prod...
More info about week 1: https://www.reddit.com/r/linux/comments/flmr8o/enjoying_the_...
Learning to use the command line is a requirement for all serious programmers and its great you want to start.
It can be pretty overwhelming to use the terminal so you may have to some reading to get yourself really comfortable.
I usually go to books/(book pdfs) to help me start out because they have conceptual explanations about the syntax which really helps my understanding.
Maybe this one would be good? The Linux Command Line, 2nd Edition: A Complete Introduction
Once I'm comfortable based on the book, using StackOverflow and other websites becomes much, MUCH easier.
In the process, you'll learn BASH which is used for scripting.
It can be pretty overwhelming to use the terminal so you may have to some reading to get yourself really comfortable.
I usually go to books/(book pdfs) to help me start out because they have conceptual explanations about the syntax which really helps my understanding.
Maybe this one would be good? The Linux Command Line, 2nd Edition: A Complete Introduction
Once I'm comfortable based on the book, using StackOverflow and other websites becomes much, MUCH easier.
In the process, you'll learn BASH which is used for scripting.
> Maybe this one would be good? The Linux Command Line, 2nd Edition: A Complete Introduction
Free PDF in the author's (William Shotts) homepage: http://www.linuxcommand.org/tlcl.php/
Free PDF in the author's (William Shotts) homepage: http://www.linuxcommand.org/tlcl.php/
There are lotss of responses here advising Ubuntu to teach Linux skills. I'd like to put in a vote for Manjaro instead:
The automatic driver detection when you install it can be handy, the Arch repositories are easier to use and include the same software you would find on any other machine, and the Arch wiki still applies, allowing you to find information on any part of the system you have questions about.
In addition, I think Arch derivatives in general encourage a healthy reliance on the command-line, which is actually what you want to learn how to use.
The automatic driver detection when you install it can be handy, the Arch repositories are easier to use and include the same software you would find on any other machine, and the Arch wiki still applies, allowing you to find information on any part of the system you have questions about.
In addition, I think Arch derivatives in general encourage a healthy reliance on the command-line, which is actually what you want to learn how to use.
Keep hacking your raspberry pi. Customize your shell with a profile; maybe alias LS so it always uses color? Find some packages to install. Cowsay, and SL are great, udderly useless ;) programs. Check em out.
Keep projects small, just patch together open source code for fun, and read the open stuff you do use.
You could also switch the GUI environment of your raspberry pi. Install headless raspbian and install he GUI from the CLI. Just hack!
My koan is video poker, I’ve rewritten a whole game about 3 times. I also like writing prime number finders in new languages.
Keep projects small, just patch together open source code for fun, and read the open stuff you do use.
You could also switch the GUI environment of your raspberry pi. Install headless raspbian and install he GUI from the CLI. Just hack!
My koan is video poker, I’ve rewritten a whole game about 3 times. I also like writing prime number finders in new languages.
Start by downloading Ubuntu and using it everyday. It's actually super easy to use, IMO easier than Windows or macOS. Then download the language of your choice and start using. When you build something, at some point you'll have to compile and package it, or start a webserver and deploy it, etc..., all good learning experiences. But just using Linux everyday is a good start (and don't go for one of the hardcore distros, use Ubuntu or Fedora).
I became much more comfortable with the Unix environment by completing the Bandit game [0]. It teaches you various Unix tools and forces you to learn the command line. There are about 30 parts, each can be completed in a timespan ranging from a couple of minutes to an hour. It is mighty fun and I highly recommend it.
[0] https://overthewire.org/wargames/bandit/
[0] https://overthewire.org/wargames/bandit/
I regularly recommend installing VirtualBox, obtaining a Linux distro, e.g. fro. OSBoxes.org, and using it to do a
http://linuxfromscratch.org/
project.
LFS is well-document and maintained, and levels you up in a jiffy on the practical basics.
It's not about programming per se, but covers quite a few concepts you're expected to "just know".
Plenty of pointers to more advanced concepts, too.
LFS is well-document and maintained, and levels you up in a jiffy on the practical basics.
It's not about programming per se, but covers quite a few concepts you're expected to "just know".
Plenty of pointers to more advanced concepts, too.
My pointers:
1) Do all day to day tasks with the CLI. It will force you to challenge yourself.
2) Learn line editing with GNU Readline. What is this? E.g., when you have a bash shell open and you hit Alt+B, your cursor moves back a word. This will make your time in the shell a lot more pleasant. Similarly, the basics of VIM, which will make text editing a lot more pleasant. Less friction means everything comes quicker, and you get tighter learning iteration loops. Don't go overboard on this: it's mostly about navigating around and editing text, not installing plugins or anything beyond an hour or two of study.
3) Don't waste time purposefully memorizing userland tools. You'll forget them in a week, and most of the time they're pointless clutter in your head. There is zero value in memorizing all the options for `tar`. Memory will come naturally with use.
4) Do not waste time building the perfect set of dot files (e.g. `.bashrc`, `.vimrc`). Know where they are, but futzing with them should be <1% of the time you spend learning.
5) Do not waste time building a Linux desktop, configuring a window manager, etc. Linux is, first and foremost, an operating system for servers, and the skills needed to get a polished Linux desktop user experience are entirely separate from (and usually dependent on) the skills needed to get a solid Linux server environment up and running.
6) Man pages are your friend. Before Googling how to do `something`, try `man something`. If you don't even know the man page you're looking for, try `man -k something`. If it's totally new, read the whole man page. If you're just looking for an obscure `tar` option, just skip to that section.
7) Cert book for RHCSA. Honestly pretty much every non-junior developer should have the skill level of a RHCSA. It teaches you how an entire system fits together. Note you don't have to pony up some obscene fee to RedHat to actually take the test and get the cert (though, as far as certs go, it's one of the better ones); the point is the content. And actually do all the labs/exercises in whatever book you get.
8) Advanced Programming in the Unix Environment (APUE). This is less critical and only relevant once you are vaguely at the RHCSA level (and know how to program), but it can give lots of valuable knowledge about the programming system interface.
1) Do all day to day tasks with the CLI. It will force you to challenge yourself.
2) Learn line editing with GNU Readline. What is this? E.g., when you have a bash shell open and you hit Alt+B, your cursor moves back a word. This will make your time in the shell a lot more pleasant. Similarly, the basics of VIM, which will make text editing a lot more pleasant. Less friction means everything comes quicker, and you get tighter learning iteration loops. Don't go overboard on this: it's mostly about navigating around and editing text, not installing plugins or anything beyond an hour or two of study.
3) Don't waste time purposefully memorizing userland tools. You'll forget them in a week, and most of the time they're pointless clutter in your head. There is zero value in memorizing all the options for `tar`. Memory will come naturally with use.
4) Do not waste time building the perfect set of dot files (e.g. `.bashrc`, `.vimrc`). Know where they are, but futzing with them should be <1% of the time you spend learning.
5) Do not waste time building a Linux desktop, configuring a window manager, etc. Linux is, first and foremost, an operating system for servers, and the skills needed to get a polished Linux desktop user experience are entirely separate from (and usually dependent on) the skills needed to get a solid Linux server environment up and running.
6) Man pages are your friend. Before Googling how to do `something`, try `man something`. If you don't even know the man page you're looking for, try `man -k something`. If it's totally new, read the whole man page. If you're just looking for an obscure `tar` option, just skip to that section.
7) Cert book for RHCSA. Honestly pretty much every non-junior developer should have the skill level of a RHCSA. It teaches you how an entire system fits together. Note you don't have to pony up some obscene fee to RedHat to actually take the test and get the cert (though, as far as certs go, it's one of the better ones); the point is the content. And actually do all the labs/exercises in whatever book you get.
8) Advanced Programming in the Unix Environment (APUE). This is less critical and only relevant once you are vaguely at the RHCSA level (and know how to program), but it can give lots of valuable knowledge about the programming system interface.
Install from zero an advanced linux distribution (CentOS, Debian), make it work properly.
This will give you enough things to do to learn and also decide if you like it.
Write an application on server side stack, for ex Nodejs.
Learn how to set it on a server.
Connect your app to a database you setup.
Deploy all of this on a cloud.
Good luck!
Shoehorn Linux into your life, even when there are other solutions that you're familiar with that already solve your problems.
1. Decide your goal, probably get hired? (Web, Devops, Embedded...)
2. Learn the stack that follows from 1, just barely, not too much theory. You want to start as k with 3.
3. Build something using the stack you learned. Start even if you are clueless of how to do it, and google every question you encounter. Stackoverflow will become your friend.
Repeat 2 and 3 for the rest of your life.
2. Learn the stack that follows from 1, just barely, not too much theory. You want to start as k with 3.
3. Build something using the stack you learned. Start even if you are clueless of how to do it, and google every question you encounter. Stackoverflow will become your friend.
Repeat 2 and 3 for the rest of your life.
I strongly recommend "A Practical Guide to Linux Commands, Editors, and Shell Programming". It's a great overview of many things linux & command line. Very approachable for beginners and more than good enough to make them dangerous.
These days it's more about the code than the books. I don't think there are any books up-to-date. It's all in the source code (and man pages).
https://git.kernel.org/
https://git.kernel.org/
Pick up a Linux cert book like rhcsa or something. You don't need the cert or the test, the knowledge shoukd be beginner admin tasks. Along with that dual boot it or switch completely and use it often, try to use the cli when you can.
I wrote a free book for getting started with the command line that may interest you: https://seankross.com/the-unix-workbench/
Try this recent HN submission:
Text Processing in the Shell
https://news.ycombinator.com/item?id=22590824
I agree to use it on the desktop.
Next, get a book on bash or other shell. You’ll learn the most important parts quickly. Then do the same for Python.
If you make it that far, read the art of Unix programming to approach greybeard status.
Next, get a book on bash or other shell. You’ll learn the most important parts quickly. Then do the same for Python.
If you make it that far, read the art of Unix programming to approach greybeard status.
Try lfs(Linux from scratch). Start building your own distros, configure them how you like. You will run into a lot of problems that you will learn how to solve.
Grab The Linux Programming Interface and a good C textbook. Rely less on the textbook and more on the readings and exercises in TLPI.
Nothing beats a mentor.
Find someone experienced and ask them to mentor you. (Online of course, but use screen sharing and audio.)
Find someone experienced and ask them to mentor you. (Online of course, but use screen sharing and audio.)
If you want to learn programming, from my point of view, learn C.
Install it on your main workstation and don’t dual boot.
Honestly? When I was in high school I was fortunate enough to find a copy of The Unix Programming Environment[0], which is a marvelously accessible tutorial introduction to incrementally building UNIX® programs using nothing more than the pipe operator, which means you can start writing 'programs' that work on the output of other programs, until your program snowballs into a longer pipeline. The book was published in 1984 and works verbatim on any Linux system today.
Once you grasp how powerful this closed system of incrementally processing text is, you are sort of unstoppable at the command in a *nix system.
Pay careful attention to regular expressions, which are a universal tool in Unix for processing text. Along with Unix' treatment of files as a stream of newline terminated strings, this how Unix gets away with working with unstructured files instead of something like XML or S-expressions): that is, most Unix tools expect you to work with a file (or file descriptor, which is a pointer to any file-like thing in memory), and to process it one line at a time, and to use regular expressions to parse those lines into fields.
Working with lines using regular expressions is how the original editor, /bin/ed, was conceived, before the existence of visual editors like Vim and Emacs: you can find, print, and also edit lines in the file using regular expression syntax in ed, and this knowledge, btw, translates to fluent use of regular expressions in both sed ("stream editor", or basically a non-interactive version of /bin/ed, which essentially executes your editor commands and then exits), and egrep (which searches for lines matching your regular expression).
In fact, once you start to see these pieces come together, look for examples in Kernighan and Pike[0] which demonstrate the use of awk. Awk is an extremely powerful but also extremely simple tool for processing data in Unix, using all the concepts I just described, and not much else. It has a few extra features, like variables and loops, which you'd expect in a programming language, but you are expected to use Awk exactly like you'd use things like grep, ed, and the shell. It's just that now you've got this very compact, powerful notation for splitting records (lines) into fields (regular expression matches), and then doing arbitrary things with them to spit text back out. You could even write your own database using something like Awk, and you can read about how to do database-like tasks in the classic and accessible book on Awk by the original authors of the tool (Aho, Weinberger, and Kernighan, whose last initials together form the name AWK)[1].
Then, much later in life, when you find yourself doing some fancy stuff in Haskell and creating a DSL to do things like process pipelines, you realize that Awk was actually way ahead of its time.
[0] https://en.wikipedia.org/wiki/The_Unix_Programming_Environme...
[1] https://en.wikipedia.org/wiki/The_AWK_Programming_Language
Once you grasp how powerful this closed system of incrementally processing text is, you are sort of unstoppable at the command in a *nix system.
Pay careful attention to regular expressions, which are a universal tool in Unix for processing text. Along with Unix' treatment of files as a stream of newline terminated strings, this how Unix gets away with working with unstructured files instead of something like XML or S-expressions): that is, most Unix tools expect you to work with a file (or file descriptor, which is a pointer to any file-like thing in memory), and to process it one line at a time, and to use regular expressions to parse those lines into fields.
Working with lines using regular expressions is how the original editor, /bin/ed, was conceived, before the existence of visual editors like Vim and Emacs: you can find, print, and also edit lines in the file using regular expression syntax in ed, and this knowledge, btw, translates to fluent use of regular expressions in both sed ("stream editor", or basically a non-interactive version of /bin/ed, which essentially executes your editor commands and then exits), and egrep (which searches for lines matching your regular expression).
In fact, once you start to see these pieces come together, look for examples in Kernighan and Pike[0] which demonstrate the use of awk. Awk is an extremely powerful but also extremely simple tool for processing data in Unix, using all the concepts I just described, and not much else. It has a few extra features, like variables and loops, which you'd expect in a programming language, but you are expected to use Awk exactly like you'd use things like grep, ed, and the shell. It's just that now you've got this very compact, powerful notation for splitting records (lines) into fields (regular expression matches), and then doing arbitrary things with them to spit text back out. You could even write your own database using something like Awk, and you can read about how to do database-like tasks in the classic and accessible book on Awk by the original authors of the tool (Aho, Weinberger, and Kernighan, whose last initials together form the name AWK)[1].
Then, much later in life, when you find yourself doing some fancy stuff in Haskell and creating a DSL to do things like process pipelines, you realize that Awk was actually way ahead of its time.
[0] https://en.wikipedia.org/wiki/The_Unix_Programming_Environme...
[1] https://en.wikipedia.org/wiki/The_AWK_Programming_Language
The problem is, I know so little that I can’t actually do anything with this knowledge. I suppose I’m looking for a tutorial that will teach me to be comfortable with the command line and a Unix environment, while also teaching me to code a language. Where should I start?