GameShell: A game to learn or teach the Unix shell
github.com
github.com
I'd been hoping for a program like 'learn' for modern environments. This looks like it comes close.
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.
Reminds me Terminal Quest:
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 :)
I have not tried installing it on Debian so I don't know how well it works in non-Kano environments.
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.
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'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've definitely heard of some games that teach programming skills getting popular. For example, https://flexboxfroggy.com/ http://www.flexboxdefense.com/ for teaching css layout.
https://www.freecodecamp.org/ isn't marketed as a game, but absolutely feels like one when you are going through the program.
https://www.hackthebox.com/ is another great example.
As to reading books, I used a lot of resources to become a programmer, but books weren't one of them. I'd wager hardly anybody uses books today.
But yeah, just one data point in millions who don't use games.
There are quite a few popular ones. Bitburner encouraged this JS hater (me) to give it a try.
* 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).
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 would sooner forget.
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.
...what stuff?
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.
bwrap --dev /dev --ro-bind /usr/bin /usr/bin --ro-bind /usr/lib /usr/lib --symlink usr/bin /bin --symlink usr/lib /lib64 --unshare-user --uid 256 --gid 512 --bind TP2 /TP2 /usr/bin/bash
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.
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.
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!
> 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.
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 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 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.