When I first started learning Unix -- way before Linux (I'm that old) -- there was a program called 'learn' that came with the OS. 'learn' taught you how to use the shell in a series of distinct lessons, each of which was capped off by an exercise in which you were dropped into a fake shell environment and instructed to achieve some task. Only by successfully completing the task (the program checked the state of the fake file system against the desired state) could you proceed to the next lesson.
I'd been hoping for a program like 'learn' for modern environments. This looks like it comes close.
Sure. I just couldn't think of a way to convince google to find the right answer. Anything like "on unix learn tool" or "unix learn command" wouldn't bring me it. What search did you use to find it on google?
I really liked https://overthewire.org/wargames/bandit/ when I was starting out! Basically 30 levels of capture the flag, starting with `ls -lrth`, then going up to scanning ports etc
Back in the 90's I remember my family got a new Compaq (I think) PC. On it it came preloaded with this great dos tutorial that was essentially a fake terminal that would walk the user through DOS commands letting them try various things in a safe environment and let them see the effects.
It was definitely effective in teaching my young self the basics of DOS and was a big step on my path to becoming proficient with a computer.
I was hoping this would be a quick and easy way to help other people (students) get started.
I got as far as:
"Terminal Quest
[...]
linux-story is installed by default on Kano OS, and is provided as a debian package in our repositories. As it has a lot of dependencies from other packages in Kano OS, it is recommended you run it on Kano OS."
I guess the use-case here is that an experienced person installs it for a newbie?
I think I'm disappointed because I was hoping for something in a web page. Oh well :)
Also, lists and lists, in terms of learning something via a text game. (cant check the actual link atm because work firewall) http://eblong.com/zarf/ftp/lists.tar.Z
I learned about C with a book called "Head First C" about two years ago and it was amazing. It was kind of like a game, written in order to be fun. I learned so much in that book, about system calls, signals, file descriptors, processes, pipes etc.. it was amazing.
I also used the AWK Programming Language about a year ago and it was amazing too.
It was definitely a challenge to keep reading the book because i think I've become so used to instant gratification but books require multiple reading sessions... I have pretty strong ADHD so i actually feel really accomplished just by finishing and working through a (seemingly simple) book. :)
Ha, I never heard of any textbooks gain significant popularity either. I guess reading textbooks attracts audience with low motivation.
In seriousness though why do you think any educational game would ever gain popularity anywhere close to popular video games.And what the popularity of the material even have to do with the motivation of its consumers???
There are (used to be?) widely recommended books for certain topics, such as K&R's "The C Programming Language". I don't think any programming games are anywhere near the popularity of these books.
I think CodeCombat is pretty widely recommended specifically for teaching coding to kids. Not sure if it counts -- it's more coding lessons that are gamified in overall structure, and also the lessons themselves have gaming aesthetics (e.g. "Write code to move your hero to kill these orcs and open treasure chests").
There's a ton of resources for this area now though, I'm not sure I can point to any one thing as a standard.
> I guess "play games instead of reading books" idea attracts audience with low motivation?
This seems a little uncharitable in its premise to me. I've never had all that much success learning from programming books, and the success I've had seemed to happen mostly when I would take the examples and run them and pull them apart and break them and fix them (etc, etc, etc).
From the other side, well designed games are remarkable in their ability to teach concepts to a player (even if, in the general case, they're not concepts with applicability outside the game).
It seems obvious to me that some kind of interactivity is really helpful in learning. Not too much of a stretch from there to guess that the best form of programming education might be some kind of game/book hybrid.
Games which present you with a text box and ask you to write in a language to solve a problem feel too much like being tricked into eating your vegetables. That's not saying that programming games can't work, but thinking about it as programming can get in the way. Dijkstra's famous quote is that computer science is no more about computers than astronomy is about telescopes, and games are proof of that.
Factorio is often given as an example of managing complexity, as another response said. TIS-100 has the aesthetics of assembly programming but the substance is actually a game that teaches hardware parallelism. Even something as simple as having students act out the 'dining philosophers' problem can be thought of as a game.
I suppose that depends on what you mean by popularity.
* CodeCombat is gamified programming lessons and seems to be reasonably popular with kids.
* Human Resource Machine teaches assembly language programming and was popular -- it even got a sequel, Seven Billion Humans.
* Robot Turtles was a kickstarted code-teaching board game that became popular enough to become a ThinkFun staple (you can tell because of how cheap it is).
If you dont like running foreign code on your machine, you can run docker and then run foreign code on your machine.
Did anyone else catch this in the article? Doesn't it seem like this makes it even more likely to get infected? No one understands Docker in entirety let alone this random game. It seems like all this stuff should just be automatically done behind the scenes and yet it's not.
Whatever Docker is doing that your browser/OS/hardware isn't.
But that's the point. I have no idea what any of this stuff is actually doing. I'm just crossing my fingers that what I run isn't detrimental to my system. There's no actual understanding behind any of it anymore.
Ah, ok. In any case I was TA with Pierre teaching that class at Chambéry this semester, to run the gamesaves from the student without being too worried about my files i just ran the thing inside a bubblewrap bash session:
Does no one think this is a problem? When even software engineers can't keep up with all these things, and your average citizen is completely clueless about how even the most basic of computer things work, do we not realize we are like the boiling frog in the pot?
Maybe before starting to teach others, you should teach yourself how to cleanly package your software into OS packages, instead of peddling around MS-DOS style shell scripts with a .sh extension. Didn't anybody teach you that UNIX-like operating systems purposely do not use extensions, in order to abstract the implementation language of the executable from the user?
How the hell are you going to properly teach others, if you have such knowledge gaps yourselves?
It's blind leading the blind again; boy does this make me mad.
I (25 years working with GNU/Linux) usually name my bash scripts `something.sh`.
I think it's debatable wether it's always good or bad, and when specifically it can be a good idea to leave out the `.sh`.
Also, it doesn't look like you looked into the game and came out with some conclusions. It looks more like you superficially had a look, you had a thougt and rushed to comment here about what you believe is a deadly sin. I personally never enjoy this kind of comment, as there's not much thought behind them.
I tried it (before recommending to a teammate) and I also noticed some things that could be improved. But it never crossed my mind to post a judgement on the project after trying it out for just five minutes.
> Be kind. Don't be snarky. Have curious conversation; don't cross-examine. Please don't fulminate. Please don't sneer, including at the rest of the community.
It does not benefit me: you mistake niceness for kindness. There is little I can learn from you and your guideliness when you yourself cannot tell which is which.
I'm glad you're mad, but based on this comment and the rest of your comments in this thread it seems that's just your normal operating state. Your argument seems to be that unless someone uses a computer exactly as you do, and has your exact selection of knowledge in their brain, then they're incapable of sharing any knowledge at all. Furthermore, there aren't many Unix/Linux users that operate in a vacuum, and often you'll be using files with extensions that come from other OSes that use extensions; and additionally, file extensions are a useful fast way of knowing exactly what kind of data the file contains. You're a mega idiot who deserves to be constantly seething
Thank goodness that all the many people I've learned from over my life didn't have to meet some arbitrary gold standard of knowledge before they were allowed to teach me! Hardly anyone could have ever taught me anything by this standard.
Similarly, thank goodness I've had the opportunity to expand and solidify my own knowledge by teaching people things I knew, even if I wasn't sure of all the details. I can't count the number of times I've had to stop mid-explanation and say "wait a second, that thing I just said doesn't really make sense. Let's take a deeper look and figure it out together."
I'm confused as to why you're choosing this hill to die on.
I also use ".sh" at the end of bash script files for usability: at a glance it's obvious how run "build.sh" and exactly what it does without the person building it having to read a readme or an email that you authoritatively sent months ago regarding the optional build processes.
You are not supposed to "identify" anything on UNIX-like operating systems; that is what the file(1) command is for, specifically, especially so since the entire concept of UNIX is that everything is a stream of bytes.
Attempting to manually manage files in this way defeats the purpose of the OS abstracting it away for the user; and the users of your executable should not have to care what your executable is written in because you grew up on a PC-bucket whose operating system stems from CP/M -> MS-DOS!
As someone who did grow up on Windows and still uses it regularly alongside Linux, I want to respond to this comment just to play the Devil's advocate (i.e. infuriate you).
> especially so since the entire concept of UNIX is that everything is a stream of bytes.
I consider this an archaic, anachronistic, ancient, outdated, primitive (they all mean the same thing; I just used a thesaurus to really drive home my point) file model. While it made sense for the limited computers of the early 1970s, it is extremely hobbling today and the fact that no one really complains about it is... quite astounding. If every file is merely a bag of bytes, then every native program shall have its own file-parsing/byte-parsing routine. What a waste of effort, writing and rewriting parsers over and over again.
The fact that one has to write a shell script that is interpreted, and itself calls not one, but three other binaries (cat, grep, awk) with arcane, not-easily-remembered flags just to extract out certain words in the last several lines of a file is... ridiculous. That you have to call 'file' instead of directly querying the OS or shell for file attributes is farcical. Consider PowerShell or Python as alternatives to shell scripting. In the former, the entire .NET library is available; in the latter, the default libraries may be imported as one sees fit, and additional libraries are available online.
> defeats the purpose of the OS abstracting it away for the user
The UNIX philosophy does a poor job of 'abstracting it away from the user'. For well-abstracted OSes, see any smartphone today (especially iPhones).
Furthermore, not every UNIX/Linux user interacts with their computer solely over the command line; I use KDE Plasma, for instance. In general, when I see a file on Linux with no extension, I expect it to be a binary; I am surprised when it is, in fact, a shell script.
This is a fantastic response, honestly. I'll add that your last point about how different users interact with their systems differently is especially relevant for the longevity of open operating systems. General users coming over to Linux who do not have extensive knowledge with computers beyond Windows will primarily be using graphical interfaces on their desktop, and making that process confusing for them by not accommodating that will quickly make them give up on the whole thing. If we wish to keep the software alive with a userbas then it's actually extremely important to allow and support things like this that are more intuitive.
I'm not sure that I can add much beyond what's already been said in reply, but I do want to say:
If something this (arguably) trivial does, truly, make you mad, I would encourage you to reflect on _why_ and perhaps talk it over with a friend or colleague.
I'd been hoping for a program like 'learn' for modern environments. This looks like it comes close.