Learn just enough Linux to get things done
alexpetralia.com
alexpetralia.com
I think the real (and even stronger) reason is that Linus Torvalds specifically built Git to serve as the VCS for the Linux codebase.
Mercurial was built for exactly the same reason (VCS for Linux), at the same time. Yet it has always been cross-platform.
Linus wrote it for Linux because he didn't care about whether it would work in Windows. No other reason.
Git for Windows and Cygwin Git have some issues (I use them daily at work), but many of these can be entirely attributed to the limitations of Windows: CRLF, case-insensitivity in filesystems, problems with long pathnames, slow process forking, etc.
The first Windows-compatible release was msysgit, which was effectively a mingw/msys Linux emulation layer for Windows. Not quite native, but it worked. Kind of. Not really very well at first.
The current Windows download - "Git for Windows" - is still msys-based, just with a lot of compatibility/package-management/ux-polish changes.
All that and the fact that recent Windows includes Windows Subsystem for Linux make the differentiation somewhat moot, but, essentially, Git is a *nix app.
"What resulted was an expansive suite of programs and utilities (collectively, software) that were written in Linux, for Linux - much of which was never ported to Windows. One example of this is the popular version control system (VCS) called git. Developers could have written this software to work on Windows, but they didn't. "
It's just wrong.
Now typically, when you install MinGW it also installs some tools that let you operate within Windows a little bit more like you're working under Linux, such as by installing a more sane terminal emulator and Windows-compatible ports of some popular programs e.g. grep. But all those tools and such are ports of Linux programs running on Windows, not standard Linux programs running atop a compatibility layer to allow them to work on Windows.
I mention the above because this was an unclear distinction to me originally. Additionally, this was based on my experience with MinGW some five years ago, and I don't know if everything I've described is still true. Hopefully this slight aside clarifies things for someone.
That's where you get it wrong. MinGW is a compatibility layer that helps port unix apps to windows. Yeah, it comes with GCC, but it also comes with support for POSIX, including a unix shell and other standard components.
Claiming that MinGW was just GCC would imply that to run Git on windows would be just a matter of recompiling the source code. But it isn't.
There is no advantage to writing another interface to git that is directly compatible with cmd or powershell.
This is not a surprise - the Windows ecosystem simply wasn't designed with software development in mind.
This article is so bad, I'm really getting mad over here. Stop publishing such crap, you feed a lot of people's resentment against all those hipster developers who don't want to learn by RTFM, but want to have handled everything.
Articles like this are a real hurdle on the way towards making Linux and programming in general more approachable to non-techies. Just stop, please.
Linux was designed to emulate Unix and run the pre-existing Unix-like userspace from GNU.
And absolutely yes, Unix was "designed" for software development. That's exactly what it was in its early days: a hacker playground for the geeks at Bell Labs to try new ways of doing things.
And windows wasn't. Early windows development (for years after it became popular) was done at a DOS command line. Eventually Visual C++ because the dominant product, and certainly you can't say it wasn't innovative. But it remained a separate product. "Windows" wasn't for development. And we still suffer from this in, say, the way windows basics (like the standard C runtime!) typically need to be shipped per-app and are only vaguely compatible across OS and toolchain changes.
I could just as easily flip this and claim that Linux development is all backwards because it's still done on the command line.
Given Microsoft's commitment to tooling, backwards compatibility and extensive documentation I think it's pretty lame to try and paint windows as not targeted towards developers. The difference is that windows has actual users, as opposed to the eternal horizon of "the year of linux on the desktop".
The point I was making was that they're just different systems and approach things in different ways. Trying to say one is more "developer focused" than the other is a useless metric(which we'll take forever trying to define what "developer focused" even means).
One could make similar arguments about the Alto not having a command line, yet Smalltalk was incredibly powerful and focused at giving a top-tier development environment that still hasn't been match in some ways to this day.
UNIX and thus Linux are all about pure user power. The shell is great and there are lots of tools available by default like Awk, Perl, Python, TCL, Sed, GCC, Vim, Emacs...etc. The entire OS isn't perfect, but is designed for people who know what they're doing. Compare that with CMD & Batch and it is Linux is like an SUV that can also fly and shoot lasers while Windows is like a moped. Of course I'm exaggerating a good bit, but even Powershell has a lot of issues and doesn't allow you to easily do what you can in Linux. In Linux everything is text and it's easy to pipe things around. In Windows it's all objects and frustration. I agree that Smalltalk on the Alto is pretty cool, but Windows is nothing like that besides having some OO stuff. Something I do all the time on Linux is "locate filename" and pipe that to "grep" to be more specific. On Windows, open up the search Window and pray you can narrow it down or wait a very long time.
I use Windows and Linux at work. On Linux I feel like everything is designed to increase my productivity as are the tools at my disposal. On Windows, I'm always fighting the lack of good tools. Sure Visual Studio + .NET is pretty good if that is your thing, but I personally don't like having to open an IDE that uses that kind of resources if I essentially need to write a simple script. I've spent quite a bit of time with Powershell, but it simply isn't as productive as Linux due to the increased complexity. Sorry for the rant, but as i spend a lot of time with both OS, I have strong feelings on this.
Except that it is isn't an equivalent comparison for that point. OTOH if you made the point about GNOME etc being developed on the command line...
You also has the MSDN subscription that did cover a lot about the development.
Are we talking about Windows 1.0 and 2.0 here?
I was using Turbo Pascal and Turbo C++ quite nice IDEs on Windows 3.x.
Windows has always been a popular development environment for the demoscene, and games developers.
The only alternatives being Mac and Amiga, none of them UNIX friendly.
In fact, as pointed out, Microsoft's own development environment (and the one used to create windows itself and most of MS's windows apps) until 1993 was a DOS command line compiler and separate editor.
No one is saying you couldn't develop "on windows" (obviously you could), but that's a rather different point than saying that windows was designed with developers' needs in mind (it wasn't).
It was the way that commercial UNIX vendors started selling their SDKs, with Sun being the first one, that made people actually contribute to gcc.
Not sure if that adds much to the conversation, it is a v. common shorthand to use linux for gnu + linux.
Other professions buy their tools.
In any case, most MS-DOS applications were written in Assembly and one could use debug for creating COM executables.
GW-Basic + debug was already a big step forward from using monitor applications with hexdumps on ZX Spectrum and C64.
The true essence of delightful and plain right software development must be over in OpenBSD land, where they run the one and only gcc 4.2.1
Clang actually.
If it was only an exercise in self-flagellation, sure whatever, but no, their tears flow upstream when stuff 99% of the population uses on Linux inevitably breaks with their bastardized gcc.
(This is very obvious if you consider that no, they don't have an LLVM backend for the alpha)
Not wanting to fall into a debate about Microsoft/Linux/Apple I've tended to find that Microsoft with all its problems do have very helpful and useful technical support when you run into a major door stop when shipping a product. What they do for backwards compatibility is amazing and still something I would like in the Linux world.
Here I go again....
One of my pet peves with Linux/Unix world is `Still` after all these years their asynchronous IO is still crap compared to Free BSD. Something that after all these years its still amazing that it still isn't fixed. The whole container/virtual machine is required in the Linux world because `Some` essential tool you need is no longer works with your specific version of Linux. To make matters worse I've seen 2-3 virtual machines in enterprise environments that are just simply there to run old software that it vital for the business.
I know Oracle licenses we had to have a dedicated machine because they charge per core/thread.
How many GB of pure crap are you forced to install on any windows system to be able to tweak, let alone develop, any software project developed with C#?
Even you acknowledged that you need to install a full blown IDE, such as the monstrocity that is MS Visual Studio, to do any software development in Windows.
In unix-like OSs, such as any linux distribution, all you have to do is pop open a basic text editor and compile/run the program.
Otherwise, decent little primer.
Because if you had, I don't know how you could not know that strace existed. Maybe you wouldn't know how to use it, but I don't see how you could be unaware of its existence if you are familiar at all with linux dev tools.
It could be mentioned early in the article.
However for its target audience (I assume) that would be far less useful.
("This looks great but seems to be about Unix and I know this is a Linux thing.")
And you can get quite a bit done on Linux without knowing any of it.
I use them frequently as an "rsync"-ish into the archive file, which I can then use to take point-in-time snapshot/backups.
It works over ssh connections (ssh -C for compression) and is a good training of tar syntax.
For such moves rsync works much better.
You can think of Tar arguments as either subcommands or options. The dashes are optional
The "subcommands" are x (extract), c (create), t (list), among others.
The "options" are f (read from named file rather than stdin), v (verbose mode), and z (run gzip on the archive before processing).
The fact that these options can be written without leading dashes, and all smashed together in a single argument, is legacy silliness for saving a few keystrokes. Don't confuse yourself with it, and don't confuse other people by teaching it to them, instead of teaching them how to actually use the command (which is really not hard at all).
So when I write Tar commands, I like to think along these lines. Instead of "tar zcvf foo.tar.gz", I write "tar -c -zv -f foo.tar.gz". After doing that about 3 times, it all sank in. Nowadays I'm much more intimidated by Git than Tar.
In the version of tar on the machine I'm posting from (GNU tar 1.27.1), this structure is obvious from right there in the man page:
SYNOPSIS
Traditional usage
tar {A|c|d|r|t|u|x}[GnSkUWOmpsMBiajJzZhPlRvwo] [ARG...]
UNIX-style usage
tar -A [OPTIONS] ARCHIVE ARCHIVE
tar -c [-f ARCHIVE] [OPTIONS] [FILE...]
tar -d [-f ARCHIVE] [OPTIONS] [FILE...]
tar -t [-f ARCHIVE] [OPTIONS] [MEMBER...]
tar -r [-f ARCHIVE] [OPTIONS] [FILE...]
tar -u [-f ARCHIVE] [OPTIONS] [FILE...]
tar -x [-f ARCHIVE] [OPTIONS] [MEMBER...]Why do people have such a difficult time with tar? The only tar commands I've ever needed (or seen other people need) are `tar cf ...` or `tar xf ...` (occasionally I'll need to chuck a z in there if the file is/needs to be gzipped), are other people just using far more complex tar commands than I am?
tar cvf somedir filename.tar create an archive from somedir and store it in filename.tar
tar xvpf filename.tar extract the contents of filename.tar and scatter them around your home directory
Instead of getting examples that I might use, when I visit a man page, I get a wall of text 926 lines long, describing every possible option, including GNU option styles, or some truncated mess telling me to read the info pages.
Of course, it's appropriate that all this information is included somewhere in the manual. I just think the common use cases should be first. Does anyone need a man page for 'ls' that starts off describing how to list inode numbers and SELinux labels?
The justification I usually hear is that SO is for learning to solve one case, while man pages are for learning how the tool works. There's some merit to that, but if a tool has some hidden gotcha or unusual use, SO tends to make that much clearer than the actual documentation.
I suppose comprehensiveness was a higher priority when there wasn't an online discussion of every imaginable case, but it still feels like a lot could be done to convey the same amount of information more gracefully.
Section 3.3.3 "Old Option Styles" covers exactly the situation you describe.
> This old way of writing 'tar' options can surprise even experienced users. For example, the two commands:
> tar cfz archive.tar.gz file
> tar -cfz archive.tar.gz file
> are quite different. The first example uses 'archive.tar.gz' as the value for option 'f' and recognizes the option 'z'. The second example, however, uses 'z' as the value for option 'f' -- probably not what was intended.
> Old options are kept for compatibility with old versions of 'tar'.
> This second example could be corrected in many ways, among which the following are equivalent:
> tar -czf archive.tar.gz file
> tar -cf archive.tar.gz -z file
> tar cf archive.tar.gz -z file
It sounds like this project moved in the right direction and made the man page more efficient than googling, but many others haven't.
ssh -n -C -x ${DELIVERY_USERNAME}@${DELIVERY_HOSTNAME} tar ch
-C ~${DELIVERY_USERNAME}/${VERSION_PATH}/Escape/AIR_Delivery/PWP_Delivery
Configuration_Files Executables Libraries Scripts
| tar x -C ${install_appli} --transform 's,^Executables,bin,;s,^Configuration_Files,config,;s,^Scripts,config,;s,^Libraries/PWP_Configuration_Application.jar,config/PWP_Configuration_Application.jar,;s,^Libraries,lib,'Its like find. I try to remember the stupid syntax and just give up and use locate instead.
Because tar means "tape archiver", and back when it was created, most of the time, you only needed one option: c, t or x (create, test, extract). You didn't need to pass f (file) because you actually piped tar to something that would append to a tape device (or read from it). And back then, compression (z, j, J, a) wasn't common place for tapes.
It originates from BSD, but it's also part of util-linux, so it should be available on most Linux distros.
Historically that wasn't true, but Stack Overflow has made it vastly easier to answer simple questions ("Which 'ls' flag shows permissions? How about hidden files?") without ever using a man page. You can go a long time without ever touching that and not have problems, while jumping to man pages without experience tends to be an overwhelming jumble of flags and conditions.
Which isn't to say it's low value! Learning Linux well beyond "good enough" is still an enormously worthwhile project. But I do think it's correct to say it's no longer an entry-level step.
Surprised to see this on the front page. I agree with most of the feedback and criticism here.
Hopefully some readers found it helpful regardless.
1. I've never heard of tabview and it's not on MacOS or Fedora.
2. Add ctrl-D to your possible exits. It's actually more common than ctrl-C.
3. Some of those commands are not installed by default on many systems; e.g. htop or dstat. And they require sdvanced knowledge to properly interpret. But they can be very useful. I'd suggest standard `top` and things like iostat instead.
Learning to do a thing and learning to do a thing well enough to create a production quality result that isn't a liability to the company are very different. That said, improving Linux knowledge among those who had little/none before is a net win in the long term IMO.
Hey, that's me!
I personally believe this is why Macs have been so popular since OSX, it’s really the only machine out there that comes with Unix but doesn’t require any sysadmin knowledge to use productively.
As soon as Linux truly reaches that same point where users can install and maintain it without needing sysadmin Linux, I think it could take over Mac’s position. And I wish it would, OSX seems to stuck in old version limbo.
I'm not sure that's true. You can buy a few computers (including from Dell) with Linux pre-installed, and maintenance doesn't take a lot more than clicking on the upgrade button with the daily update-manager prompt.
I _do_ have sysadmin knowledge and find the shell more efficient than the GUI in 99% of everyday-use cases (I can't remember the last time I opened a file browser). So it's entirely possible that there's some day-to-day work required that I'm not even thinking about.
But my dad is running a Linux Mint system and I switched him to it (about ~10 years ago) because it required so much _less_ maintenance than running a Windows machine did. The number of phone calls for tech support I got from him plummeted from twice a week to zero when I switched him from Windows: I did so because I got tired of fielding constant questions about antivirus software, defragmentation, startup programs littering his systray, possible viruses installed, etc etc etc etc. It's really beyond me why anybody thinks that Windows is an appropriate OS for a non-technical user (er, or for a technical user, or really anyone who doesn't need specialty software).
Surprisingly, he actually does. This is in large part because this is WAY easier in Linux than anywhere else, because they've been following the "curated marketplace" model (like iOS and Android) for like, a decade (without the restrictions on other modes of install, obviously: Linux systems have an incentive to be user-friendly, but not anti-user the way Apple does). He was in the menu and found the "Software Hub" or whatever Mint calls it, and spends time randomly looking around at stuff. On Windows, he would oscillate between being too paranoid about viruses to go around installing random .exes to being _not paranoid enough and actually installing a virus_ haha.
Is it really that good these days?
I can definitely appreciate the constancy of Linux, it feels like Windows/Chrome/etc stacks move under my feet constantly. But my experience with Linux is still that when problems do arise, I have to escalate to shell commands and arcane sysadmin-ry for all but the simplest problems. Windows and OS X still offer a lot more hope of an accessible fix via the GUI or even an automated troubleshooting tool.
It's totally possible I'm dealing with the wrong distros, or am resorting to Linux for weirder tasks and therefore seeing harder problems. But I don't have the sense that Linux is more painless, only that it's less chaotic.
Honestly, I constantly doubt myself on this because other people keep claiming you need to be some sort of tech-savvy god in order to use Linux: but I've had various Linux systems as my primary and only OS since 2007 and I pretty much haven't had any problems to speak of since like, 2012.
To the extent that I can take myself out of my own head and try to model someone not that tech-savvy, I find Windows _much_ harder to use on a day-to-day basis. This is further validated by the experience of my dad: I went from 1-2 tech support calls a week to maybe once a YEAR.
> But my experience with Linux is still that when problems do arise, I have to escalate to shell commands and arcane sysadmin-ry for all but the simplest problems.
I actually prefer the command line for pretty much everything (I haven't opened a GUI file browser in years), so I'm leaning primarily on the experience of a few friends/family who switched to Linux when they saw how awesome my system in college was (where awesome = not plagued with the ridiculous problems that every Windows user has to rationalize out of existence). I've tried to evangelize the command line to most of them and they remain pretty firmly uninterested. And yet none of them ever really _have_ any problems with their system[1] to speak of: clicking "install now" on the Update Manager pop-up is the only interaction they have to have with their system beyond usage. They usually tend to be on something like Linux Mint, which has all the GUI-heavy config tools pre-installed already. When they feel like dipping a toe in the water of customization, they can do so to the precise extent that they're comfortable and think that the trade-off is worth it (e.g. re-arranging their panel).
AFAICT, all the work in Linux is upfront and pretty quick: make sure that you buy hardware that supports Linux well (an easy Google search) and either buy pre-installed or spend 20 minutes installing it.
[1] These include my best friends and girlfriend, people I've talked to almost literally every day for the last decade.
Having just walked through some basic steps with a novice, I can concur, modern linux is impossible without "recipes".
Just setting up a hello world web app can involve: ssh login to running instance, using curl to download the gcloud sdk, tar to unpack, sudo to install, systemctl to start local processes, useradd dedicated www, chmod and chroot to allow access, rsync to tranfer files, netcat to manage ports, etc.
For beginners, without a trusted hand to guide them, its beyond intimidating. These systems must become more accessible to the average human.
I disagree. Firstly, all the commands you mentioned are pretty simple to understand given that they have a manpage and lots of help available online.
Secondly, not everything needs to dumbed down for the average user. A large part of the power comes from all the tools and flags available and the combination possibilities. Dumbed down tools are limiting and frustrating.
I’d expect any software engineer worth their salt to not be an “average user” and grasp a few simple commands the same way they approach a new project or programming language, i.e. they should be able to pick up the basics even if it’s a complex system. That’s a prerequisite for programming and understanding a project’s code well anyways.
Yes, I do use them but I guess most Linux users learned most of what they use from colleagues and Internet, not the official documentation.
I cringe at thinking about what a newbie has to go through.
Install the right version of php/python etc on your platform
Install a virtual environment
Install a package manager
Install a framework
Install a databaseSetting up novices to start their work with an arcane and difficult step is unfortunate even if it is unavoidable.
It's no wonder MySpace and then Facebook became popular. This was the dumbed down web presence people wanted but didn't want to have to manage.
ssh login to running instance
using curl to download the gcloud sdk
tar to unpack
sudo to install
systemctl to start local processes
useradd dedicated www
chmod and chroot to allow access
rsync to tranfer files
People who cannot even handle those tasks should not use a root server for their project. There are alternatives to a full system, if running a single app with a database is your use case. Be it Heroku or Lambda, there are solutions that do not need administrator knowledge to run an application.
To add to this, servers that are lousily configured because some developer did not know what platform to use damages the infrastructure as a whole. They are broken in, used for spam or data theft if the application has some user base. If you know someone who does not know how to handle a system, please advice them to either coop with an admin or to not use a full system for their project.
My concern would mostly be that the list above is unacceptable for learning, not for usability. That's ~8 different tools to learn from scratch, totally independent of the underlying project.
And sure, most devs will eventually know all of those tools (or equivalents) without much conscious effort. But there's a lot to be said for scripted introductions to complex systems.
They are not meant for beginners or average people. We have Windows and MacOS for that, once you get to a point where you are thinking about linux you shoudln't be soon 'green'. Just because we have an OS doesn't mean it's meant for everybody.
This seems backwards. Going to the command line for these things is a horrible workflow. It’s not necessary in Linuxes either ...
Quitting is ctrl+d
Ctrl+c is for interrupting the current job.
Some repl like the mysql cli does not rrspect that and it is a PITA