 DistroWatch Weekly |
| Tip Jar |
If you've enjoyed this week's issue of DistroWatch Weekly, please consider sending us a tip.
(Tips this week: 0, value: US$0.00) |
|
|
|
 bc1qtede6f7adcce4kjpgx0e5j68wwgtdxrek2qvc4  lnurl1dp68gurn8ghj7ampd3kx2ar0veekzar0wd5xjtnrdakj7tnhv4kxctttdehhwm30d3h82unvwqhhxarpw3jkc7tzw4ex6cfexyfua2nr  86fA3qPTeQtNb2k1vLwEQaAp3XxkvvvXt69gSG5LGunXXikK9koPWZaRQgfFPBPWhMgXjPjccy9LA9xRFchPWQAnPvxh5Le paypal.me/distrowatchweekly • patreon.com/distrowatch |
|
| Linux Foundation Training |
|
| Reader Comments • Jump to last comment |
1 • Command line (by brad on 2022-01-17 02:09:18 GMT from United States)
Actually, I learned UNIX commands from a book, but I can't remember which one.
One of the things that helped me when I was first introduced to Linux, was to pull out that book, and see which commands were the same, and which were different (not many, it turned out).
Just before I started using Linux, I inherited an Apple iBook G4 laptop from my wife, and I was aware that the Mach kernel was derived from BSD, so I took that opportunity as well, to re-acquaint myself with the command line.
2 • Learning the command line (by Ivan on 2022-01-17 02:21:36 GMT from Italy)
I have been using Linux since 2009, but for less than a year I have been seriously studying the command line and writing scripts to automate all my operations. I was so amazed that I signed up to github to contribute to some open source projects and write my own (see link), and all by reading examples from the Internet and reading manuals (man command). On the internet just write what you need, using multiple search engines, and you will find everything you need.
3 • Re learning the command line (by Curious on 2022-01-17 02:35:03 GMT from Canada)
Aside from the standard man and info pages, there's tons of online help available.
For those of us who prefer paper, 2 books I would recommend are:
- Linux Command Instant Reference by Bryan Pfaffenberger on Sybex
- UNIX Visual Quickstart Guide by Deborah S. Ray & Eric J. Ray on Peachpit Press.
(Think there may now be a Linux Visual Quickstart in the series by now as well).
Just about any system administration book will cover the commandline.
Some like the Rute Tutorial are available for free download from freetechbooks.com
I just happened to find the 2 above well laid out and useful, and am willing to pay to have a proper paper reference at hand.
4 • Command line (by DaveW on 2022-01-17 02:39:20 GMT from United States)
This poll definitely needs multiple choices. I have used books, man pages, and on-line examples and videos.
5 • Learning command line (by AG on 2022-01-17 02:57:03 GMT from Australia)
I too learned the command line from multiple sources. But an important one was Bash Guide for Beginners by Machtelt Garrels: https://tldp.org/LDP/Bash-Beginners-Guide
6 • command line (by Andy Prough on 2022-01-17 02:57:10 GMT from United States)
I've learned quite a bit from all of those options except the one called "fortune" - I don't know what that refers to. In the 90s and early 2000s I read more books, and in the 2000s-2010s I took several college classes that touched on the command line. I've learned a lot over the years from man pages, Arch wiki, stackoverflow, etc. Recently the most enjoyable way of I've found of learning is from some of the better Linux content creators on youtube and odysee.
Not sure how to answer the poll. I guess I'll just put "video", since it's my current favorite way of learning.
7 • GNU's Not Unix! (by Oko on 2022-01-17 02:57:26 GMT from United States)
Linux is just a kernel and original userland was and still is to the very big degree just a patchwork of various GNU tools. Considering that GNU's Not Unix I found surprising how useful was my familiarity with UNIX classics the first time I used Linux. Mandatory first reading for anyone serious about using UNIX like OSs would be Unix Programming Environment by Brian W. Kernighan and Rob Pike. That includes not just BSDs guys but OS X and Linux guys as well.
8 • Command lne (by x on 2022-01-17 02:58:41 GMT from United States)
Command line on a modern system is a a vast improvment over punch cards and paper tape, i learned on both of these. A dropped box or torn paper tape involved attention to detail in order to make the media work properly. Disc drives prevented a lot of frustration, but, introduced new ones.
My first experence with a unix syyle command line was on an AT&T telepype,that printed both input and output on a paper rroll. There was no video display. Honestly I do not rememberwhen I learned the Linux command line.
People today do not realize how easy it is, however, there are compromises involved with frameworks and GUI's. Command line and compilers, without the use of optimations, gives you more control of the machine and more disasterious results if you make a major mistake.
Even if you rarely use 'command line' it is worthwile learning, as you will have a better understanding of your system.
9 • Command what? (by Friar Tux on 2022-01-17 03:08:53 GMT from Canada)
I guess I'm at the other end of this spectrum. I refuse to use or learn anything "command line". We are in the 21st century. Mouse and keyboard are just as quick or quicker than the terminal. And God forbid if you make a spelling mistake or have "fat-finger-syndrome". Especially after typing out some long involved command. (Yes, in the past, I HAVE used command line, that's how I know to stay away.)
Having said all that, I'm looking forward to the day when we all just tell our laptops/desktops/tablets/etc. what we want done. (No, Mycroft and the like don't yet work too well.)
10 • Learning Linux (by John on 2022-01-17 03:23:18 GMT from United States)
I learned UNIX from the manuals that came with an 16bit 8086 proprietary system at work years ago. When Linux became available, I went to Linux and all I had to figure out the differences, which was not that bad.
I would recommend books along with a system to practice on, plus you need to be very clear on your goal and put the time in.
For me, I learned because I needed to convert a mini-computer business program to c and I decided to use the 16bit UNIX system as a development environment. This forced me to learn both c and UNIX at the same time.
11 • Command Line (by dcedilotte on 2022-01-17 03:46:29 GMT from Canada)
I started using linux in the 90s, when it was first released. Back then, to get your CD-ROM or Soundblaster card to work, you had to recompile the kernel, so learning how to use command line tools was a necessity. Most of what I learned, came from BBSes, IRC linux channels and Gopher sites (look it up.)
12 • Linux commands (by cor on 2022-01-17 03:50:42 GMT from United States)
When I first started working with computers it was all CLI on terminals, no graphics. Having used Unix, Data General AOS/VS, DOS, and OS/2 learning Linux was fun and easy. There are still many commands and programs and scripts I use on a regular basis. Getting help is a breeze either through MAN pages or via the internet.
13 • learning command line commands.... (by tom joad on 2022-01-17 03:53:54 GMT from Austria)
The response should allow for multipe answers.
Anyway I checked online. But I have used books, too, and the Man pages. Books are fine for general usage. But I found the online resources to be easier to use, more detailed and readily available at a computer. Best of all, over time one just stores away a lot of comands in ones head. Such that with those tucked away and using the man pages 'to sculpt' the command, one can do exactly what needs to be done.
That said I came over from Windows so I was very famaliar with the concept of commands and dos boxes ( read CLI ).
The command line in Linux is where the action is. A GUI is nice and pretty but a CLI has the power. And Root is god.
14 • Command-line (by Wedge009 on 2022-01-17 04:21:16 GMT from Australia)
Another multiple answer responder:
* Prior experience with DOS
* Uni courses (which probably included book references)
* Man pages
* Following existing examples
I understand the reticence to use the command-line by some in this graphical age. I admit I prefer GUIs for many things where it makes sense to do so but there are times when it's quicker/simpler/easier just to use the command line instead. Whatever one is most comfortable with to get the job done, I suppose.
15 • Command-line blurring (by Wedge009 on 2022-01-17 04:22:27 GMT from Australia)
PS I knew I was spending too much time switching between DOS/Windows-based systems and *NIX-based systems when I kept typing 'ls' in the former and 'dir' in the latter...
16 • The shell (command line) (by Andy Figueroa on 2022-01-17 05:04:52 GMT from United States)
I answered "Other", but maybe I could have selected "Books." In 1985, I was embarked on a major data project that required collection and database analysis of massive amounts of data. I had a login on networked Pyramid running AT&T Unix. A system administrator was assigned to help me with things. After some flailing about, the system administrator suggested I get a copy of "Unix Primer Plus." Almost everything I learned from the books was directly transferable to Linux, and it's an easy read. I highly recommend getting this book, used, either 2nd or 3rd edition. The 2nd edition can be read at The Internet Archive: https://archive.org/details/unixprimerplus00wait/mode/2up I initially bought the original, but purchased the 2nd edition when it became available. I still use it as a reference.
17 • My fav Linux (cli) book: Linux Administration: A Beginner's Guide (8th ed) (by anon on 2022-01-17 05:55:37 GMT from United States)
I like that it actually has LOTS of advanced info. Amazon has "Look Inside" https://www.amazon.com/Linux-Administration-Beginners-Guide-Eighth/dp/1260441709
https://u1lib.org/book/17547545/e5af19
18 • Command line (by David Milovanović on 2022-01-17 06:16:54 GMT from Serbia)
I don't really use command line that much, but I wanted to learn some basics and I did it with "Linux command line" book by William Shots. It's a great book for beginners and a great place to start from. Nowadays, if I need help with command line, I look for it on the web.
19 • Command-line (by Antonie on 2022-01-17 06:19:01 GMT from Netherlands)
I choose books, as I was system-administrator for a Unix system in 1992/93 and had to learn it from a book: 'Essential system administration' Had some previous experience with DOS, PDP11 and Minix
20 • CLI and GUI (by Any on 2022-01-17 06:53:54 GMT from Spain)
@9 Look at GUI and CLI as complementary things. You can use graphical interface AND command line, not graphical interface OR command line.
We are in the 21st century, but you do not watch the TV while driving, don't you? But you can listen to the radio while driving.
You can pull out and stop to watch the weather forecast but you do not do that, you simply switch the radio on.
21 • work (by Dave on 2022-01-17 06:56:42 GMT from Australia)
I got started at work, mainly with FreeBSD but many of the tools and commands are the same. I find the only way to learn for me is if you NEED to use it for something.
22 • Command line (by eee on 2022-01-17 07:00:04 GMT from Poland)
"The Linux Command Line" by William Shotts - best book about "linux command line" ;-) I've ever read. Free pdf version available here: http://linuxcommand.org/tlcl.php
23 • Learning the Command Line (by ls650v on 2022-01-17 07:43:00 GMT from United States)
I second what eee @22 claims. "The Linux Command Line" by William Shotts was my starting point. I also use the man pages and on-line examples.
24 • CommandLine (by AlwaysGUI on 2022-01-17 08:00:40 GMT from Spain)
I began using Linux more than 10 years ago (nearly 15) and I don't know anything about command lines. They are unnecessary to know for modern Linux systems. The two or three times they were useful for me, I looked for them in the web, copied/pasted them, and problems fixed. Today command lines in Linux are as superfluous as in Windows for a regular user.
25 • Command Line (by Dan on 2022-01-17 08:52:38 GMT from United States)
Since I rarely install anything, I only need the command line for are updates and upgrades.
26 • Command Line (by Donald on 2022-01-17 08:58:20 GMT from United States)
@25, that's all I use it for as well. The only thing I install is htop if it isn't included, and I hardly even look at that.
27 • CLI (by Someguy on 2022-01-17 09:56:27 GMT from United Kingdom)
Been trying to use the Command Line for decades. Have the 2nd Edn Linux Complete, now largely superseded. Best advice is to use Jesse's weekly advisories! Indeed , surprising he hasn't collected his wisdom into a published volume. Or, one could cut-and-paste his best bits from the last decade of DWW offerings? That might cover the majority of eventualities?
28 • command line (by Feng Lengshun on 2022-01-17 10:14:34 GMT from Indonesia)
For command line, I found that I got a LOT more comfortable with them as I install and run more stuff via command line, and use more newbie-friendly alternatives such as fish, exa, httpie, bat, and others.
Fish in particular was such a game changer for me. I still need to be POSIX-compliant when using conda, though, which is why I just use a "fish-ified" zsh, but regardless fish really helped in making me feel comfortable with CLI on top of making it feel genuinely more convenient than using GUI sometimes.
29 • Don't be afraid of the CLI (by Woodstock69 on 2022-01-17 10:58:34 GMT from Australia)
I had 10 years of magazine PDFs in a directory. I wanted to sort them in year of publication directories.
I could have just clicked New, Folder x10 and then cut and pasted each PDF into the correct directory. How long would that have taken in GUI? Don't know. But it only took 4 literal seconds and one line of code to accomplish the task in the CLI.
Some tasks are better done with GUI. Some tasks are better done in CLI. It's not one over the other.
30 • command line (by James on 2022-01-17 11:41:28 GMT from United States)
i have not learned the command line, and have no plans to do so. Not a power user, and I have a command cheat sheet. Also even if I learned the command line I doubt I would be successful, as I am a lousy typist. I do use apt-get update and upgrade.
31 • command-line start with youtube-dl (by always-curious-about-foss on 2022-01-17 12:08:05 GMT from Germany)
My start of using the bash was using youtube-dl and there was no GUI. I read about it on the website www.ubuntuusers.de ( a very good tuturingsite in german ).
After that i got more familiar with the command-line time by time.
In the time of the stay at home order I read a book about using the bash and shell-scripting.
32 • @9 Command line (by Ostro on 2022-01-17 12:22:13 GMT from Poland)
Even in Windows we use the command line... :)
33 • Command Line (by DachshundMan on 2022-01-17 12:25:38 GMT from United Kingdom)
I started to learn the *ix command line (CL) when I attended a course for HP-UX back in the 90's. In those days the firm I worked for used HP-UX and VMS, I could never get on with the latter.
When I got into Linux in the naughties I found that the Unix stuff was mainly still useful but I also got a couple of free books for my Kindle and I still sometimes refer to "introduction to the Command Line" by Nicholas Marsh. However, I try to avoid the command line and mainly use GUI software as I find it generally allows me to do all I need, makes errors more difficult to make, and avoids me having to check the exact syntax of commands. If "Man" was more friendly then maybe I would use the CL more but probably not as my work computers have all been Windows based for the last 30 years or so and I have mainly got out of the CL habit.
On this forum we have often had then discussion about how to make Linux the mainstream computing environment, IMHO expecting people to use the command line is not moving towards that goal.
34 • command line learning (by Paul W on 2022-01-17 12:45:34 GMT from United States)
I developed a love for the command line and scripting back in the DOS and batch file days. When I left the dark side of the force, I quickly discovered man pages and --help.
One early habit I developed on Linux was to boot a Live distro into RAM while I removed the hard drive. That was easy for me as I used slide out trays to hold the hard drives. That way I could try various commands without risk of getting something wrong.
Read about the history command. ;)
35 • In the beginning was the command line... (by far2fish on 2022-01-17 13:10:39 GMT from Denmark)
It's been so long time ago that I am not 100% sure how I learned the command line. In 2000 I am certain I read a book that boosted my knowledge about the command line, but it might have been as early as 1995-96 that I learned some of it at university in a class about Sun Solaris.
36 • Command Line (by bittermann on 2022-01-17 13:20:29 GMT from United States)
I learned the basics of cli over the years. I know enough to get by or be dangerous depending on how you look at it. :-)
37 • More desktop environments (by Chris on 2022-01-17 13:25:57 GMT from United States)
It seems like every day some distro or another is creating its own home grown desktop environment. We already have a large number of DEs to choose from. It seems like a colossal waste of time and resources for developers to keep re-inventing the wheel over and over again while ignoring other more innovative developments.
38 • @9 an example (by always-curious-about-foss on 2022-01-17 14:02:14 GMT from Germany)
creating a directory tree - book1 (58 subdirectories named chapter 1 to chapter 58),
If you are using for that job the grafical window of your file browser you forced to open this creating window for 59 times and type in the names (!) and of cource there much more clicks with your ( fast? ) mouse.
Let try the comand line:
mkdir -p /home/username/projekt/book1/'chapter '{1..58}
39 • Command line is a comfortable old hat (by Bob McConnell on 2022-01-17 14:03:55 GMT from United States)
I learned how to use the command line on a NorthStar computer using articles in "BYTE" and then graduated to CP/M 2.2 on repurposed NCR terminals that had been designed to do data entry for Kresge. Moving up to PC/MS-DOS was a simple step, with a little Eunice (NCR Unix) on the side to add a little confusion. I also got to play with CCPM and CPM86 for a little while. Then Minix.came along, with more variations, before I found Soft Landing Systems Linux. After SLS folded their tents, I switched to Slackware. So it has been a gradual evolution through the years. I still mostly use man pages, with an occasional look at tutorials on the web. I currently run XFCE, but a lot of work is done in terminal windows. I don't bother to install X at all on servers. Since WordStar was my first word processor (ED doesn't really qualify), I am very comfortable with Joe for editing.
40 • Command line (by Jesse on 2022-01-17 14:13:41 GMT from Canada)
@9: "I refuse to use or learn anything "command line". We are in the 21st century. Mouse and keyboard are just as quick or quicker than the terminal. "
While I use and appreciate graphical desktops (and applications) for how easy they are to discover and navigate, the idea that using a GUI is typically faster than the command line is not an argument I can agree with. The command line is almost always faster than the equivalent GUI approach. It may not be easier or as friendly, but it's almost certainly going to be faster.
For example, if you received a ZIP file containing a bunch of files you wanted to unpack, and then you had to remove all the special characters from the files, what does that look like? In a GUI you'd need to open the file manager, browse to the ZIP file, probably double-click on it to open it in the FM or in an archive manager, select the extract feature. Then open another tool to do bulk renaming, put in the pattern you want to deal with, go through a few tabs, hit the execute button. From the command line I could do that in the same amount of time it took to open the archive manager by running: "cd ~/Downloads ; unzip Project.zip ; detox -r *"
Syncing files for backups is faster on the command line. On the GUI I'd need to open a tool like Grsync or FileZilla. Browse to the directory I want, select or type in the name of the server to use, select the files I want to transfer, then drag them over. On the command line I can just type "rsync -av ~/Documents/Work/ server:Backups/Work/". Takes maybe five seconds with Tab completion. About the amount of time it takes me to just launch the GUI tool.
Here's another real world example I stumbled into just yesterday. My partner likes to play Wordle. Yesterday I was watching over her shoulder as she was trying to come up with five letter words which matched the criteria of: having an r, a, s, o. With the "r" not in the first position and the a not in the second or third places, no s in the last position. While she was puzzling it out, I took a few seconds and used the command line to find the answer. "grep "^.....$" /usr/share/dict/words | grep r | grep o | grep a | grep s | grep -v "^..a..$" | grep -v "^.a....$" | grep -v "^r....$" | grep -v "^....s$"
Yes, the above looks ugly, but it only uses one command (grep) and it took about 20 seconds to type. How would you do that faster from a GUI? Do you even have a GUI tool that would do this?
41 • Learning the Command Line (by Adam Drake on 2022-01-17 14:39:51 GMT from United States)
My dad brought home an old TI dos PC in the mid 80s and taught me just enough DOS commands to make me a little bit dangerous. I played around with it as a child, but never for anything productive. The knowledge came in handy in vocational school when running AutoCAD on DOS in the mid to late 90s.
As a PC support technician and VB developer in the early 2000s, I only used the Windows Command Line when I had to. Usually the basic stuff (not a pun).
They had us developing Java using VI on a remote Linux server during my undergrad studies. They taught us just enough to get our code compiling, print the results, and save everything to floppy disks (and eventually my gigantic 128 MB USB stick).
A prerequisite for my Masters program was a course on Unix. The book for the course was Harley Hahn's Student Guide to Unix. I enjoyed that book greatly and finished reading the entire thing before the first week of the course was even finished.
Command line experience came in very handy as an architect leading a team of DevOps engineers over the past several years. Especially when it comes to using Git Bash locally and remoting into VMs and Docker container pods.
Personally, I still use the command line on my Debian box when I need to. Anything to do with my BTRFS RAID 10 setup is done in the terminal. Also, it's much smoother running sudo apt update and upgrade than using the Gnome Software tool for updates.
I do use Grsync for my backups. It allows you to select and save multiple configurations including the addition of command line options. I also use the command line for connecting to NordVPN, installing the one-off deb package with dpkg, and monitoring disk I/O with nmon.
Also, nano is 1000X better than vi. :)
42 • Command line usage (by Mike S on 2022-01-17 14:45:43 GMT from United Kingdom)
I began using computers before GUI existed so learnt the basics of using a command line from literally using BASIC. I cut my teeth on an AMSTRAD CPC6128 but also to a certain extent Acorn/BBC Micro in school too.
Then MS-DOS 5 and 6.22 followed by starting to use Linux from PC Magazine cover media. The first Linux distribution I used was actually SuSE Personal and upgraded via an offer in the magazine to the Pro version which came with 6 CDs and a very chunky 500 page manual.
If you know your way around DOS, then any linux/UNIX/BSD command prompt isn't that different, a few commands vary but the essentials are similar. If I get stuck I either use man or search the web for the command I need these days. Arch wiki regardless of which distribution I am using tends to be my go to as it is the best laid out and written source of information I had ever come across and remains so well over a decade later.
43 • Command line learning (by zhymm on 2022-01-17 14:47:20 GMT from United States)
As others have posted, I too learned how to use the CLI through various sources - books, online, man pages, --help, etc. Two books I have at hand at my desk are the "Linux Phrasebook" by Scott Granneman and Mark Sobell's "A Practical Guide to Linux Commands, Editors and Shell Programming".
44 • CLI (by Friar Tux on 2022-01-17 14:48:58 GMT from Canada)
@40 (Jesse) I understand the examples you're providing. How often, though, will I be using them in "real life"? (That last one can be a monster if you even get one character wrong.)
I base my "just as quick or quicker" on having raced a friend who is quite proficient in CLI many times. We have had this discussion quite often, to the point, where I call his CLI-man and he calls me gooey-man.
(By the way, rsync has never worked for me. I just use the Copy To in the right click menu. Works beautifully. I don't even use backup software as it fails more often than it works.)
45 • Learning the bash shell (by Kingneutron on 2022-01-17 15:05:12 GMT from United States)
I've been running Linux since 1997 and reading this book cover to cover (and highlighting, taking notes and dog-earing pages) really helped:
https://www.amazon.com/Learning-bash-Shell-Programming-Nutshell-ebook/dp/B0043GXMSY
^ Learning the bash Shell: Unix Shell Programming (In a Nutshell (O'Reilly)) 3rd Edition
Also:
https://www.amazon.com/bash-Cookbook-Solutions-Examples-Users-ebook/dp/B076TZTYMR
^ bash Cookbook: Solutions and Examples for bash Users 2nd Edition
46 • . (by Tad Strange on 2022-01-17 15:07:38 GMT from Canada)
Not a whole lot of news this week. I mean, when you need to report on such things as bundled web browsers, you know it's slow.
I use the terminal for software and update management and that's about it. So many of the "but see how much quicker yadda yadda is to do" examples that I see begin with the assumption that all of the bowling pins have been set and the balls are at the ready ie: most of the core work is done already.
I've been using Free File Sync for backups. I like that I can save the job file to the media that I'm backing up to, rather than having some folder somewhere in my home folder of backup scripts.
I still use robocopy scripts on Windows, but FFS will eventually replace those, I expect.
I too have never managed to get rsync, the "robocopy for Linux" to work. My eyes just start bleeding part way through the documentation.
47 • Command Line (by marcos on 2022-01-17 15:08:17 GMT from Brazil)
Since 1975 thru 2007 in various IBM environments
and since 2004 in various Linux Distributions at home...
Books
Man Pages
On-line written examples
and trying to make Bash scripts...
A endless fun!
---
Videos only "serve &enerve" to learn things not so smart like phones.
48 • Where did I learn "the command line"? (by Tim on 2022-01-17 15:11:52 GMT from United States)
I learned by doing. I started using UNIX as a system administrator in the early 80s on some of the earliest production Bell Labs systems. I started out using manuals they had provided to operate the systems, using the manuals something like a cookbook: do this, then do this, then ...
Sometimes, a "guru" would come in from New Jersey. While he was working on the systems, he would show me new things and explain things I didn't completely understand.
49 • rsync and backup software (by Jesse on 2022-01-17 15:11:39 GMT from Canada)
@44: "By the way, rsync has never worked for me. I just use the Copy To in the right click menu. Works beautifully. I don't even use backup software as it fails more often than it works.)"
That is a pretty big claim - that rsync and other backup software don't work for you. That suggests to me that you either haven't actually used them or haven't used them properly since tools like rsync and Deja Dup are commonly deployed and used successfully across literally millions of computers.
I'm also a bit suspicious of your claim that you race your friend to test GUI vs CLI speed without mentioning which tests you use to compare. Unless it's something that requires a web browser or drawing/positioning in a document, chances are CLI will be faster.
I gave three examples before and can come up with dozens of more I use on a daily basis which I typically perform from the command line because it's the faster option. Many daily tasks I perform can be done on the command line faster than it takes to locate and open the proper GUI tool.
50 • cmd line (by wally on 2022-01-17 15:19:34 GMT from United States)
In the beginning was only the cmd line.
There wasn't a choice, you might say I'm older.
Although I presently work from a graphical Desktop (Mate), I currently have 20 active terminals open. I am grateful that I have access to both worlds, they both have very definite uses.
I would recommend learning the cmd line to anyone, check out 'man apropos' from the CL, then search for something you would like to attempt from the CL and just play with it.
It really just depends on what you want to do, whether the CL works for you or not.
As with anything, there is a learning curve, but the payback can be excellent.
51 • @20, 32, 38, 40: (by dragonmouth on 2022-01-17 15:31:09 GMT from United States)
I'm with FriarTux. I will use GUI unless I am forced by circumstances to use CLI. Why self-abuse with CLI when a GUI is available?
CLI vs GUI is like manual vs automatic transmission. There are certain circumstances when a manual transmission will outperform an automatic hands down. At all other times, an automatic is superior.
52 • Backups (by Friar Tux on 2022-01-17 15:49:32 GMT from Canada)
@49 (Jesse) "That is a pretty big claim - that rsync and other backup software don't work for you. That suggests to me that you either haven't actually used them or haven't used them properly since tools like rsync and Deja Dup are commonly deployed and used successfully across literally millions of computers."
Tried almost all of them. Each one, according to my many notes, backed up/sync'ed only part of my stuff and gave me some error message and a reason for failing. This happened so many times over there years, I gave up on backup/sync software since, as I mentioned above, the Copy To in the system menu works beautifully and has not failed yet. (I do a backup just about every Friday depending on how many files I've changed during the week. Even Timeshift isn't that good as, if the system goes belly up, it's easier to just reinstall the OS, grab your backups and you're good to go. (So far, the longest it's taken me WITH issues is one hour, using Copy To.)
53 • Lux OS ???? Xubuntu with brave-browser??? (by always-curious-about-foss on 2022-01-17 15:58:13 GMT from Germany)
If you are using Xubuntu then you can install the brave browser by the snap store with the grafical tool. If you are using Xubuntu and don't want to use the snap store, then you are also able to do the commandline given on the webpage of the brave-browser.
I am using xubuntu and the webbrowser.
I took a look on the website. Less informations but a lot of clickable buttons with always the same link to the regestration of this filehostingsite.
The preinstalled brave-browser seems to be the only different to the common Xubuntu. The snapshots shows the the same design.
In my opinion this whole matter is a charme to get people to register to this filehostingsite.
54 • learning the command line (by Jay on 2022-01-17 16:05:30 GMT from Romania)
I went from DOS to Linux (kernel v1.0.1) and adapted quickly (because they both used command lines), but I did buy a 1200+ page book called "Linux (1) | Linux Users Reference Manual" (put out by "Just Computers!"*) in '95.
It was a reference work (user commands, system calls, library functions, etc) and it saw a fair bit of use at the beginning.
* Useless arcana: whois says their domain (justcomp.com, now parked) has been around since 1993-06-21.
55 • How did I learn the command line? (by Otis on 2022-01-17 16:32:49 GMT from United States)
lmao .. I google each time.. unless it's something about pacman (-Syu etc) which I have mostly memorized.
56 • Learning command line (by Robert on 2022-01-17 16:53:06 GMT from United States)
I learned DOS when I was 10 by just typing things and figuring out how it worked. No internet, books, or other help.
The Linux terminal I learned initially from LFS, which I guess could be either 'book' or 'online example.' Then I expanded that knowledge with man pages and Google.
57 • CLI or GUI … or get shifty? (by Somewhat Reticent on 2022-01-17 16:55:39 GMT from United States)
Each approach has its appropriate usee.
GUI lowers the bar for entry, and can provide for visual metaphor and partial safety-net.
CLI provides fine-grained access and the widest system access.
And then there's what some call "getting shifty" - using many shift-keys and keystrokes to provide a much larger control vocabulary, which enables expert performance.
Once the initial dust-up settles, consider programming - code, CLI, & macros.
After all, it's all about automation, right? ;-)
58 • CLI (by Luke on 2022-01-17 17:19:20 GMT from United States)
I learned from a variety of sources. I followed tutorials to follow various CLI-oriented install procedures for distros like Gentoo and Arch, we had some Linux servers at university that we occasionally used in classes, I broke things and looked up how to fix them, I've used books to learn different things, etc. I chose "online written examples" because I definitely learned the most that way. I'm not surprised videos was so low; one of the biggest draws to learning the command line is the fact that you don't have to go through the "first click on this, then click on this" nonsense to do things. It's so much less error-prone for a tutorial to just say "copy and paste this command."
59 • CLI (by zephyr on 2022-01-17 17:47:29 GMT from United States)
Think it is a matter of choice, and hopefully Linux never gets away from the CLI experience. I use a very stripped down distro that I build. Using CLI apps are super lightweight and can replace many GUI applications. Less bloat is the way to go. Everything from file managers to multimedia players, quite honestly, most feel or seem superior to the GUI alternative.
60 • Learning the command line (by keyboardguy on 2022-01-17 17:48:09 GMT from United States)
I don't think this will be a very representative poll. Everyone will have learned from multiple sources and will take a different approach as to which choice they'll pick. Some will go with what they think they learned the most from, some with what they enjoyed learning from the most, some with what they feel is most "cool" (books, online, university, depending on background).
I picked man/info pages but then realized that something taught me how to use the man/info pages. Was it a book, or was it an online tutorial? It must have been a book, since I started before online tutorials (or much of anything online) existed.
So maybe I should have gone with books?
OTOH, I didn't really master it until later in life, and a lot of that has been from googling for answers. So maybe I should have gone with "online written examples."
Bah! Too much mental energy.
61 • How did you learn the Linux command line? (by mircea on 2022-01-17 17:59:05 GMT from Moldova)
I think that there should be an option for "by Googling", because a lot of people learned linux commands by googling: "how to do x in Linux" and finding answers on "Ask Ubuntu" and similar sites.
I am sure that "Other" + "On-line written examples" equals to "by Googling" for answers
62 • fortune (by keyboardguy on 2022-01-17 18:07:22 GMT from United States)
This appears to be distro-specific. The post got me interested in setting this up, but I'm on Fedora, and there doesn't appear to be a set of tips included with it.
I installed fortune-mod and took a look at some of the files in "/usr/share/games/fortune/". It seems they're all humor-based.
Maybe I'll poach the tips flie from the Arch package mentioned in the article.
63 • Learning command line (by buckyogi on 2022-01-17 18:48:22 GMT from United States)
My first experience with a command line was...DOS! I've never been much of a gui guy which is what got me into Linux. Since then I've used multiple teaching aides: manpages, Google, and a few books, the best of which is "From Bash to Z Shell" after I started using zsh.
64 • Command Line (by penguinx86 on 2022-01-17 18:52:39 GMT from United States)
I learned the command line on a dumb terminal connected to a mainframe running BSD. There was no graphical interface back then. I used the man pages and asked my coworkers lots of question. I also learned the vi editor using a tutorial on the dumb terminal. There was no Google back then either.
65 • CLI & Backup (by marcos on 2022-01-17 20:43:49 GMT from Brazil)
@52 - I do a backup just about every weekday depending ONLY in /etc/crontab (not user crontab) AND
my own scripts, receiving only local email (not google etc.) telling me how was everything on that backup, including details about duration of execution & sizes of backups generated.
CLI - Fun & Power
But, YQMMV - Y quality of MMV...
66 • Command line (by bison on 2022-01-17 21:54:47 GMT from United States)
College course. The textbook was called "Unix for the impatient."
67 • Bash Scripting Guide (by Sebastien on 2022-01-17 22:10:03 GMT from France)
@5: Right. I have always kept a shortcut to https://tldp.org/LDP/abs/html/ so I can easily grab the right way to write when I cannot recall
online examples + online bash scripting guide is a good support when you want to get the most out of your Linux (ether desktop or server)
68 • Command Line (by Steve on 2022-01-17 22:50:51 GMT from United States)
I answered other because the more correct answer for me was missing and would have been all (or actually most) of the above.
I live on the command line. When I first started with UNIX in the early 90's I found the best feature of a GUI was that I could have multiple command lines (in separate terminal windows) at the same time which allowed me to log into multiple servers from a single desktop.
And when I build servers I NEVER install a GUI, it's command line only to manage a server (for me anyway).
I absolutely hate wasting CPU power on a graphical interface for a server that I'm most likely going to be maintaining over a secure shell connection most of the time.
69 • Command Line (by Bill Nace on 2022-01-17 23:35:04 GMT from United States)
The advice to focus on the tasks at hand is best. I started learning the command line in the 90s when I worked as a Navy contractor on an Oracle project that ran on Unix servers. A coworker taught me a few basic commands. I only ran queries, since I was an data analyst. When I started on Linux several years later, it was easy to build on the Unix I knew. I've always just added more knowledge based on what tasks came up. There are tons of Linux help resources, and the majority include command line work, so if you're busy, you should never want for material to work with.
70 • Learning the UNIX/Linux CLI (by Bruce F. on 2022-01-18 01:23:26 GMT from United States)
I learned the UNIX command line as one of a group of programmers pranking each other at Bell Labs in the early 1970's. Messed up my login did you, TAKE THAT! Good natured fun and very educational. And the guys who *invented* UNIX were right down the hall...
71 • CMD LINE (by Jay on 2022-01-18 01:51:34 GMT from United States)
Learned Linux command line being akin to MS-DOS. A Telugu friend brought us to computer lab, where they had strange UNIX boxes, so he can show off. We though it was a practical joke, when we had "connection closed by foreign host". I was like "what country?" LOL Later explained "foreign" didn't mean out of the country but out of the computer...but same lab. After that, well its was new, something different...
72 • CMD LINE cont'd (by Jay on 2022-01-18 02:01:15 GMT from United States)
How could I forget most important part? Everyone was fingering each other like some sort of annoying game.
73 • Learning the Linux command line (by Donald Sebastian Leung on 2022-01-18 02:18:04 GMT from Hong Kong)
I started learning about the Linux command line (and Linux in general) since around mid-2020, through the LFS101x, LFS201 and LFS211 online courses offered by The Linux Foundation, which provide plenty of command line examples (along with explanations of the concepts involved).
Nowadays, I mostly just Google what I need, along with skimming through the help info or man page if necessary.
74 • Another really good book for CLI beginners (by Scott Dowdle on 2022-01-18 03:31:02 GMT from United States)
The Linux Command Line (printer version available but here's a PDF served up from sourceforge):
https://phoenixnap.dl.sourceforge.net/project/linuxcommand/TLCL/19.01/TLCL-19.01.pdf
75 • command line (by tbs on 2022-01-18 07:06:37 GMT from Turkey)
I dont know so many things about command line, i use gui to update os, work on images, work on videos etc. Still i need to use cli sometimes, like installing some softwares, i just copy paste what they say at guide :)
Other than these i want to suggest a software as file manager for cli, "ranger". With it i can move over folders easy on cli, and there are two commands i use mostly while using it= touch(to create a file like:touch test.txt) and mkdir(to create a folder like:mkdir new-folder) other than these i learned ranger's shortcuts to delete, move, select files.
I guess cli shines when we need to do smilar things over and over again like 100 or 100000 times. Example: in a folder there are many types of files inside many folders, i just want to take pdf files but at different folders inside there are pdf files with same names, so how do i extrach those to a folder other than going inside 200 folder and change 1000 files' name in 10000 files ? that is where i need to use cli :/
Even thought i can do some tasks with some softwares to a degree, there is still not a software for everything cli does as free i guess...
76 • Shell vs GUI (by Simon on 2022-01-18 08:02:55 GMT from New Zealand)
Unless it's in relation to specific tasks, it's a pointless argument... obviously different tools suit different jobs and anyone who claims one or another tool is always better ("a knife is never as useful as a hammer") is being foolish. I love the shell and do most of my basic file management there... but like anything you get better with practice and eventually tend to prefer what you already know, for that reason. I see people claiming that the shell is slower or whatever: these are people who've spent years using GUI tools and then after poking around for a few days with shell commands they think they can compare the two. Many seasoned shell users, due to muscle memory, are typing our instructions at over 100wpm and making good use of shell history and so on: our experience of the shell is not the same. Still, obviously there are tasks like image editing that are perfect for GUI tools: nobody is claiming you should type an instruction to add pixels at position X Y of a file rather than painting them with a mouse pointer... some tasks just suit some tools better. The people dismissing shell commands either aren't aware of the tasks it does well, or haven't used the shell enough to discover how much better it is at them.
77 • Learning the Command Line (by luvr on 2022-01-18 10:24:44 GMT from Belgium)
My first encounter with Linux was an early Slackware release, way back in 1995.
I couldn't get the graphical user interface running. No matter what I tried, the computer simply locked up hard whenever I attempted to start the X Window System.
I was, consequently, limited to the command-line interface.
The Slackware CD collection in these days came with a booklet that documented various features of the system, including an introduction to the Linux file system and the command line. There was even an introduction to the 'vi' text editor included.
Very instructive. That's how I got started with the Linux command line.
78 • instantOS (by penguinx86 on 2022-01-18 12:14:15 GMT from United States)
I like the idea of instantOS, an unbloated innovative OS with some fresh ideas. It's not just another Ubuntu 'me too' copycat distro. But instantOS is still a work in progress. It might work ok in a VM. But like many other distros (including Ubuntu) it doesn't support the wifi adapter in my laptop. No wifi? No deal!
79 • CLI for those you don't like command line (by Paul W on 2022-01-18 12:36:15 GMT from Luxembourg)
Perhaps one reason more people don't seem to like the command line is that they don't think they have a good reason.
If you start out with a task or project you will find the command line useful to get information to display in Conky (and parse the CL result to make suitable) or to configure some aspect of your system that may change.
Before you completely dismiss the command line, look into kdialog, yad, or zenity.
80 • Magazines (by AdamB on 2022-01-18 14:33:33 GMT from Australia)
I voted "other" because I originally gained most of my learning about the Linux command line from computer magazines. A good source has been the UK magazine 'Linux Format', to which I have been subscribing for many years - and that was not the first magazine to which I subscribed.
I started out using CP/M and DOS, so the idea of using the command line was not foreign to me.
The 'man' command is an essential source of knowledge, but first you need to know what commands are available, and which command to use for a particular purpose.
Particularly in recent years, I have used multiple sources, mainly on-line text sources - videos are my least favourite source.
Early on, I bought some books, but they were too RedHat-centric.
81 • command line proficiency (by Trihexagonal on 2022-01-18 18:24:30 GMT from United States)
I started learning the command line on the first computer I ever used. I became proficient at it when I started using vanilla FreeBSD 10 years ago.
It's so much a part of using a computer for me and use it so often during the day I have a terminal emulator open at boot with the Window Manager that stays open at the top and shaded when not in use till I issue the shutdown -r now command.
When working as root through that terminal I sometimes open another instance to keep at the bottom of the screen to work from the usr account while the other one is busy..
If you've never used the command line but would like to learn how, I have a Beginners Tutorial on my site about Building A FreeBSD Desktop From Scratch with a target audience of someone who has never used the command line that takes you step-by-step in excruciating detail from installation of the Base System, teaches you how to use portmaster to compile third party programs from ports to booting into a fully functional Fluxbox Window Manager desktop.
The Narns Willing...
I also give instructions and examples for editing essential System and Security files after you hit the desktop along with a powerful pf firewall ruleset appropriate for use with your new general purpose desktop.
If you don't know how to use it and are adamantly against learning how, good luck with that!
82 • cli (by dave on 2022-01-18 21:19:46 GMT from United States)
I have used Linux since 2004, but I have never become truly proficient with the *nix command line. I can navigate around the system, perform basic tasks, use the package manager, etc, but anything 'complicated' and I usually end up doing a web search. Often, it's just to remind myself how to do something, but I will occasionally copy and paste instructions in very specific situations.
Back when I used Wine a lot more, I would use the command line to run windows programs when something was broken and I needed more output to determine the problem. Nowadays the most frequent reason I use the command line is when I'm trying to compile software that isn't in a repository. I will also occasionally use programs that simply don't have graphical interfaces.
I grew up using DOS and still play a MUD to this day, so I'm not scared of a text prompt.
83 • Command line and useful tips (by suomynona on 2022-01-19 09:10:19 GMT from Australia)
@81 I can vouch for your tutorial - used it last year to help me set up a FreeBSD system (though I swapped out Fluxbox for WindowMaker and a couple of other things). Thank you for the resource and I recommend it to anyone looking to get started with FreeBSD, written for the layperson and from there you can go on and get a lot of advice from the FreeBSD forum or other resources on the internet (Vermaden is another great one). I like FreeBSD and openSUSE Leap as systems that just make a lot of sense especially to the non computer-literate like me.
As regards the command line, I've learnt most of my stuff from reading Jesse's tips and a few other trustworthy sources on the internet. Mainly these days I use it for package management (I find it useful to have a record of what I've done in bash history), rsync to back up my home folder to external USB hard drives (love rsync for its speed and also the easy ability to customise by way of a text file directories you don't want backed up). Also as some others here have said, to run programs from a terminal when they're not working to see what has gone wrong - often these are GUI programs that just seem to silently fail and it is the only way I know to get a quick look at what the problem might be. I also can't get a decent file converter (music files) as soundconverter fails on this system so I have a script stored away to do that for me - just needs me to go back through the bash history to find it and it's done as quick as that.
As a computer-illiterate person who is learning little by little in my older age, I find the command line invaluable - it might seem t go against the accepted grain, especially to you young and computer-savvy people, but those of us who are new to this stuff (especially if we're older) value diagnostic tools in all walks of life, and it is the best I know of for a computer.
84 • Command line (by Jerry on 2022-01-19 10:01:40 GMT from United States)
I remember learning commands on DOS and the Commodore 64. I also remember how happy I was to (mostly) not need the command line anymore when I got Windows 3.1. The excessive dependence on the command line ensures that Linux will never be more than an Enterprise tech tool and a hobby toy for geeks. One shouldn't need to touch a keyboard unless typing a password, an email, a comment, etc. or playing a game. The entire purpose of a GUI is to eliminate the need to type commands. If the Linux developer community would finally realize that and code accordingly they might FINALLY make some inroads into the consumer market and take some of it away from the Spyware from Redmond,WA.
85 • CLI vs GUI (by future Linux on 2022-01-19 10:27:59 GMT from France)
well, sci-fi productions often predict the future - and they rarely use the command line. It's all a wave of the hands to bring up the weapons, select "fire", and the enemy is toast. If you had to type in commands you'd be dead before you could finish. And do you think ppl are gonna be typing commands into superfast quantum computers? It's more likely that GUIs by then will also be fast & responsive - so not much need for commands. bring on the future !
86 • To cli or not to cli (by Angel on 2022-01-19 16:41:00 GMT from Philippines)
I think GUI exclusive fans forget that when they point and click, they are issuing a command which was made possible by one or more geeks coding away on a keyboard. The GUi is another layer of translation from the ones and zeros, and it doesn't have the "vocabulary" to issue complex commands unless they have been pre-programmed. No cli=no GUI. Microsoft knows that, so they have put Linux cli on Windows, because Linux is preferred by developers.
ON the other hand, cli devotees forget that the greatest share of coding work goes to create something graphic, whether is be desktops, phones, ATMs, et al. I was the GUI that made computers ubiquitous, and without it there would be a lot less programming going on at all levels. Some one mentioned Windows 3.0. I would say that it was Windows 95 that opened the floodgates. And over the years, both Microsoft and Apple have shown that most computer users can get along fine without ever using the command line. I'd say if you mention the cli to most computer users they'll ask: What the hell is that?
Command line proponents say the cli is more powerful. But power to what end? I started with computers back in the punch card days, went on to other things and came back to work with DOS. Worked on Windows computers for many years. (Yes, there is a command line in Windows.) Linux I started using in the mid 2000s. Became familiar with the command line over time. I'm not a programmer, but I did get into the guts of things. These days I use I don't use the cli very much. I have old eyes, not great typing, and am a bit dyslexic. Still, I can use my PCs to my satisfaction.
Yes, sometimes even trivial things can be done faster and easier from the command line, as in Jesse's example about Wordle. Although it may take more than just knowing the command line. One needs to be able to wonder how to go about solving a problem and be capable of doing it.
87 • Cmd Line use (by DTB on 2022-01-19 16:56:05 GMT from United Kingdom)
I completely agree with @82. My Linux experience is essentially in two parts. The first was command line based (around the time Slackware3.* was a thing) where I spent time customising and compiling a kernel to get all my peripherals to work and typing startx to get an xfce desktop up. I never really got much further.
Modern installations are such a huge advance in terms of installation, GUIs,software and support.
However there do seem to be areas where the command line is still useful. As examples I prefer using APT to update my various debian installs. Fast and trouble free. And after a new Manjaro setup I have to run a series of cmd line sequences to get my (HP) printer installed. I even have a script for that because the GUI alternative always fails.
The command line is incredibly powerful and I suspect you could spend a lifetime before knowing it all - USL - unix a s a second language anyobody?
88 • @86 Angel: (by dragonmouth on 2022-01-19 18:34:35 GMT from United States)
"The GUi is another layer of translation from the ones and zeros"
So is CLI. No machine language=no computers. But that does not mean that every computer user should rush out and learn machine language.
Those that have earned their computers chops on UNIX and early Linux seem to be of the opinion that one cannot be REAL computer user unless one is proficient in CLI. CLI may be 1337 and put hair on your chest but, just like machine language and assembler, it is a niche knowledge, limited to and required of relatively few users. Just like knowing carpentry, masonry, plumbing and/or electricity is useful, but not necessary knowledge, when one owns a house, neither is CLI when one owns and uses a computer.
There are hundreds of millions of successful and productive Windows user who do not know or care that Windows has a CLI. One can spend their entire life using Windows and/or Linux and never, ever need CLI.
89 • CLI (by Risto A on 2022-01-19 19:55:54 GMT from Finland)
As a Windows refugee, I have never learned to use CLI. I have copy-pasted some "magic spells" from the forums in a console window. With a good GUI desktop, why would I return to the 80's when MS-DOS was CLI only?
90 • Punch cards (by Friar Tux on 2022-01-19 20:33:40 GMT from Canada)
@86 (Angel) Ahhh, punch cards. I remember my Dad bringing homes boxes of punch cards and a manual, to spend the evening "programming" a computer. That was my very first intro to computers. He would then bring the "programmed" cards back to work in the morning to run in the reader. (Happy to say he never made a mistake.) I was allowed to go with him once or twice. The computer was a unit about 6 feet tall and 8 feet wide (not sure how deep). Fun times. I don't remember what the thing actually did, though I think it ran some "computerized" machinery. (That was about 62 years ago - I turned 70, today.)
91 • CLI (by Ahmad on 2022-01-20 08:34:19 GMT from Yemen)
Once I read that as a child you start learning via hearing and watching.. Once your mentality and skills getting developed, you use writing for the rest of your life.
So, mouse and GUI for babies. CLI for adults ;)
Cheers.
92 • instantOS Beta (by Ahmad on 2022-01-20 08:36:18 GMT from Yemen)
I tested it and really amazed.
Number of Comments: 92
Display mode: DWW Only • Comments Only • Both DWW and Comments
| | |
| TUXEDO |
TUXEDO Computers - Linux Hardware in a tailor made suite
Choose from a wide range of laptops and PCs in various sizes and shapes at TUXEDOComputers.com. Every machine comes pre-installed and ready-to-run with Linux. Full 24 months of warranty and lifetime support included!
Learn more about our full service package and all benefits from buying at TUXEDO.
|
| Archives |
| • Issue 1048 (2023-12-04): openSUSE MicroOS, the transition from X11 to Wayland, Red Hat phasing out X11 packages, UBports making mobile development easier |
| • Issue 1047 (2023-11-27): GhostBSD 23.10.1, Why Linux uses swap when memory is free, Ubuntu Budgie may benefit from Wayland work in Xfce, early issues with FreeBSD 14.0 |
| • Issue 1046 (2023-11-20): Slackel 7.7 "Openbox", restricting CPU usage, Haiku improves font handling and software centre performance, Canonical launches MicroCloud |
| • Issue 1045 (2023-11-13): Fedora 39, how to trust software packages, ReactOS booting with UEFI, elementary OS plans to default to Wayland, Mir gaining ability to split work across video cards |
| • Issue 1044 (2023-11-06): Porteus 5.01, disabling IPv6, applications unique to a Linux distro, Linux merges bcachefs, OpenELA makes source packages available |
| • Issue 1043 (2023-10-30): Murena Two with privacy switches, where old files go when packages are updated, UBports on Volla phones, Mint testing Cinnamon on Wayland, Peppermint releases ARM build |
| • Issue 1042 (2023-10-23): Ubuntu Cinnamon compared with Linux Mint, extending battery life on Linux, Debian resumes /usr merge, Canonical publishes fixed install media |
| • Issue 1041 (2023-10-16): FydeOS 17.0, Dr.Parted 23.09, changing UIDs, Fedora partners with Slimbook, GNOME phasing out X11 sessions, Ubuntu revokes 23.10 install media |
| • Issue 1040 (2023-10-09): CROWZ 5.0, changing the location of default directories, Linux Mint updates its Edge edition, Murena crowdfunding new privacy phone, Debian publishes new install media |
| • Issue 1039 (2023-10-02): Zenwalk Current, finding the duration of media files, Peppermint OS tries out new edition, COSMIC gains new features, Canonical reports on security incident in Snap store |
| • Issue 1038 (2023-09-25): Mageia 9, trouble-shooting launchers, running desktop Linux in the cloud, New documentation for Nix, Linux phasing out ReiserFS, GNU celebrates 40 years |
| • Issue 1037 (2023-09-18): Bodhi Linux 7.0.0, finding specific distros and unified package managemnt, Zevenet replaced by two new forks, openSUSE introduces Slowroll branch, Fedora considering dropping Plasma X11 session |
| • Issue 1036 (2023-09-11): SDesk 2023.08.12, hiding command line passwords, openSUSE shares contributor survery results, Ubuntu plans seamless disk encryption, GNOME 45 to break extension compatibility |
| • Issue 1035 (2023-09-04): Debian GNU/Hurd 2023, PCLinuxOS 2023.07, do home users need a firewall, AlmaLinux introduces new repositories, Rocky Linux commits to RHEL compatibility, NetBSD machine runs unattended for nine years, Armbian runs wallpaper contest |
| • Issue 1034 (2023-08-28): Void 20230628, types of memory usage, FreeBSD receives port of Linux NVIDIA driver, Fedora plans improved theme handling for Qt applications, Canonical's plans for Ubuntu |
| • Issue 1033 (2023-08-21): MiniOS 20230606, system user accounts, how Red Hat clones are moving forward, Haiku improves WINE performance, Debian turns 30 |
| • Issue 1032 (2023-08-14): MX Linux 23, positioning new windows on the desktop, Linux Containers adopts LXD fork, Oracle, SUSE, and CIQ form OpenELA |
| • Issue 1031 (2023-08-07): Peppermint OS 2023-07-01, preventing a file from being changed, Asahi Linux partners with Fedora, Linux Mint plans new releases |
| • Issue 1030 (2023-07-31): Solus 4.4, Linux Mint 21.2, Debian introduces RISC-V support, Ubuntu patches custom kernel bugs, FreeBSD imports OpenSSL 3 |
| • Issue 1029 (2023-07-24): Running Murena on the Fairphone 4, Flatpak vs Snap sandboxing technologies, Redox OS plans to borrow Linux drivers to expand hardware support, Debian updates Bookworm media |
| • Issue 1028 (2023-07-17): KDE Connect; Oracle, SUSE, and AlmaLinux repsond to Red Hat's source code policy change, KaOS issues media fix, Slackware turns 30; security and immutable distributions |
| • Issue 1027 (2023-07-10): Crystal Linux 2023-03-16, StartOS (embassyOS 0.3.4.2), changing options on a mounted filesystem, Murena launches Fairphone 4 in North America, Fedora debates telemetry for desktop team |
| • Issue 1026 (2023-07-03): Kumander Linux 1.0, Red Hat changing its approach to sharing source code, TrueNAS offers SMB Multichannel, Zorin OS introduces upgrade utility |
| • Issue 1025 (2023-06-26): KaOS with Plasma 6, information which can leak from desktop environments, Red Hat closes door on sharing RHEL source code, SUSE introduces new security features |
| • Issue 1024 (2023-06-19): Debian 12, a safer way to use dd, Debian releases GNU/Hurd 2023, Ubuntu 22.10 nears its end of life, FreeBSD turns 30 |
| • Issue 1023 (2023-06-12): openSUSE 15.5 Leap, the differences between independent distributions, openSUSE lengthens Leap life, Murena offers new phone for North America |
| • Issue 1022 (2023-06-05): GetFreeOS 2023.05.01, Slint 15.0-3, Liya N4Si, cleaning up crowded directories, Ubuntu plans Snap-based variant, Red Hat dropping LireOffice RPM packages |
| • Issue 1021 (2023-05-29): rlxos GNU/Linux, colours in command line output, an overview of Void's unique features, how to use awk, Microsoft publishes a Linux distro |
| • Issue 1020 (2023-05-22): UBports 20.04, finding another machine's IP address, finding distros with a specific kernel, Debian prepares for Bookworm |
| • Issue 1019 (2023-05-15): Rhino Linux (Beta), checking which applications reply on a package, NethServer reborn, System76 improving application responsiveness |
| • Issue 1018 (2023-05-08): Fedora 38, finding relevant manual pages, merging audio files, Fedora plans new immutable edition, Mint works to fix Secure Boot issues |
| • Issue 1017 (2023-05-01): Xubuntu 23.04, Debian elects Project Leaders and updates media, systemd to speed up restarts, Guix System offering ground-up source builds, where package managers install files |
| • Issue 1016 (2023-04-24): Qubes OS 4.1.2, tracking bandwidth usage, Solus resuming development, FreeBSD publishes status report, KaOS offers preview of Plasma 6 |
| • Issue 1015 (2023-04-17): Manjaro Linux 22.0, Trisquel GNU/Linux 11.0, Arch Linux powering PINE64 tablets, Ubuntu offering live patching on HWE kernels, gaining compression on ex4 |
| • Issue 1014 (2023-04-10): Quick looks at carbonOS, LibreELEC, and Kodi, Mint polishes themes, Fedora rolls out more encryption plans, elementary OS improves sideloading experience |
| • Issue 1013 (2023-04-03): Alpine Linux 3.17.2, printing manual pages, Ubuntu Cinnamon becomes official flavour, Endeavour OS plans for new installer, HardenedBSD plans for outage |
| • Issue 1012 (2023-03-27): siduction 22.1.1, protecting privacy from proprietary applications, GNOME team shares new features, Canonical updates Ubuntu 20.04, politics and the Linux kernel |
| • Issue 1011 (2023-03-20): Serpent OS, Security Onion 2.3, Gentoo Live, replacing the scp utility, openSUSE sees surge in downloads, Debian runs elction with one candidate |
| • Issue 1010 (2023-03-13): blendOS 2023.01.26, keeping track of which files a package installs, improved network widget coming to elementary OS, Vanilla OS changes its base distro |
| • Issue 1009 (2023-03-06): Nemo Mobile and the PinePhone, matching the performance of one distro on another, Linux Mint adds performance boosts and security, custom Ubuntu and Debian builds through Cubic |
| • Issue 1008 (2023-02-27): elementary OS 7.0, the benefits of boot environments, Purism offers lapdock for Librem 5, Ubuntu community flavours directed to drop Flatpak support for Snap |
| • Issue 1007 (2023-02-20): helloSystem 0.8.0, underrated distributions, Solus team working to repair their website, SUSE testing Micro edition, Canonical publishes real-time edition of Ubuntu 22.04 |
| • Issue 1006 (2023-02-13): Playing music with UBports on a PinePhone, quick command line and shell scripting questions, Fedora expands third-party software support, Vanilla OS adds Nix package support |
| • Issue 1005 (2023-02-06): NuTyX 22.12.0 running CDE, user identification numbers, Pop!_OS shares COSMIC progress, Mint makes keyboard and mouse options more accessible |
| • Issue 1004 (2023-01-30): OpenMandriva ROME, checking the health of a disk, Debian adopting OpenSnitch, FreeBSD publishes status report |
| • Issue 1003 (2023-01-23): risiOS 37, mixing package types, Fedora seeks installer feedback, Sparky offers easier persistence with USB writer |
| • Issue 1002 (2023-01-16): Vanilla OS 22.10, Nobara Project 37, verifying torrent downloads, Haiku improvements, HAMMER2 being ports to NetBSD |
| • Issue 1001 (2023-01-09): Arch Linux, Ubuntu tests new system installer, porting KDE software to OpenBSD, verifying files copied properly |
| • Issue 1000 (2023-01-02): Our favourite projects of all time, Fedora trying out unified kernel images and trying to speed up shutdowns, Slackware tests new kernel, detecting what is taking up disk space |
| • Issue 999 (2022-12-19): Favourite distributions of 2022, Fedora plans Budgie spin, UBports releasing security patches for 16.04, Haiku working on new ports |
| • Issue 998 (2022-12-12): OpenBSD 7.2, Asahi Linux enages video hardware acceleration on Apple ARM computers, Manjaro drops proprietary codecs from Mesa package |
| • Issue 997 (2022-12-05): CachyOS 221023 and AgarimOS, working with filenames which contain special characters, elementary OS team fixes delta updates, new features coming to Xfce |
| • Issue 996 (2022-11-28): Void 20221001, remotely shutting down a machine, complex aliases, Fedora tests new web-based installer, Refox OS running on real hardware |
| • Issue 995 (2022-11-21): Fedora 37, swap files vs swap partitions, Unity running on Arch, UBports seeks testers, Murena adds support for more devices |
| • Issue 994 (2022-11-14): Redcore Linux 2201, changing the terminal font size, Fedora plans Phosh spin, openSUSE publishes on-line manual pages, disabling Snap auto-updates |
| • Full list of all issues |
| Star Labs |
Star Labs - Laptops built for Linux.
View our range including the highly anticipated StarFighter. Available with coreboot open-source firmware and a choice of Ubuntu, elementary, Manjaro and more. Visit Star Labs for information, to buy and get support.
|
| Shells.com |
Your own personal Linux computer in the cloud, available on any device. Supported operating systems include Android, Debian, Fedora, KDE neon, Kubuntu, Linux Mint, Manjaro and Ubuntu, ready in minutes.
Starting at US$4.95 per month, 7-day money-back guarantee
|
| Random Distribution | 
OliveBSD
OliveBSD was a live CD based on OpenBSD with graphical environment (IceWM) and various software packages.
Status: Discontinued
|
| TUXEDO |
TUXEDO Computers - Linux Hardware in a tailor made suite
Choose from a wide range of laptops and PCs in various sizes and shapes at TUXEDOComputers.com. Every machine comes pre-installed and ready-to-run with Linux. Full 24 months of warranty and lifetime support included!
Learn more about our full service package and all benefits from buying at TUXEDO.
|
| Star Labs |
Star Labs - Laptops built for Linux.
View our range including the highly anticipated StarFighter. Available with coreboot open-source firmware and a choice of Ubuntu, elementary, Manjaro and more. Visit Star Labs for information, to buy and get support.
|
|
• 
• 
• 
• 
• 
• 
• 
