 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) |
|
|
|
 bc1qxes3k2wq3uqzr074tkwwjmwfe63z70gwzfu4lx  lnurl1dp68gurn8ghj7ampd3kx2ar0veekzar0wd5xjtnrdakj7tnhv4kxctttdehhwm30d3h82unvwqhhxarpw3jkc7tzw4ex6cfexyfua2nr  86fA3qPTeQtNb2k1vLwEQaAp3XxkvvvXt69gSG5LGunXXikK9koPWZaRQgfFPBPWhMgXjPjccy9LA9xRFchPWQAnPvxh5Le paypal.me/distrowatchweekly • patreon.com/distrowatch |
|
| Extended Lifecycle Support by TuxCare |
|
|
| 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 1099 (2024-12-02): AnduinOS 1.0.1, measuring RAM usage, SUSE continues rebranding efforts, UBports prepares for next major version, Murena offering non-NFC phone |
| • Issue 1098 (2024-11-25): Linux Lite 7.2, backing up specific folders, Murena and Fairphone partner in fair trade deal, Arch installer gets new text interface, Ubuntu security tool patched |
| • Issue 1097 (2024-11-18): Chimera Linux vs Chimera OS, choosing between AlmaLinux and Debian, Fedora elevates KDE spin to an edition, Fedora previews new installer, KDE testing its own distro, Qubes-style isolation coming to FreeBSD |
| • Issue 1096 (2024-11-11): Bazzite 40, Playtron OS Alpha 1, Tucana Linux 3.1, detecting Screen sessions, Redox imports COSMIC software centre, FreeBSD booting on the PinePhone Pro, LXQt supports Wayland window managers |
| • Issue 1095 (2024-11-04): Fedora 41 Kinoite, transferring applications between computers, openSUSE Tumbleweed receives multiple upgrades, Ubuntu testing compiler optimizations, Mint partners with Framework |
| • Issue 1094 (2024-10-28): DebLight OS 1, backing up crontab, AlmaLinux introduces Litten branch, openSUSE unveils refreshed look, Ubuntu turns 20
| | • Issue 1093 (2024-10-21): Kubuntu 24.10, atomic vs immutable distributions, Debian upgrading Perl packages, UBports adding VoLTE support, Android to gain native GNU/Linux application support |
| • Issue 1092 (2024-10-14): FunOS 24.04.1, a home directory inside a file, work starts of openSUSE Leap 16.0, improvements in Haiku, KDE neon upgrades its base |
| • Issue 1091 (2024-10-07): Redox OS 0.9.0, Unified package management vs universal package formats, Redox begins RISC-V port, Mint polishes interface, Qubes certifies new laptop |
| • Issue 1090 (2024-09-30): Rhino Linux 2024.2, commercial distros with alternative desktops, Valve seeks to improve Wayland performance, HardenedBSD parterns with Protectli, Tails merges with Tor Project, Quantum Leap partners with the FreeBSD Foundation |
| • Issue 1089 (2024-09-23): Expirion 6.0, openKylin 2.0, managing configuration files, the future of Linux development, fixing bugs in Haiku, Slackware packages dracut |
| • Issue 1088 (2024-09-16): PorteuX 1.6, migrating from Windows 10 to which Linux distro, making NetBSD immutable, AlmaLinux offers hardware certification, Mint updates old APT tools |
| • Issue 1087 (2024-09-09): COSMIC desktop, running cron jobs at variable times, UBports highlights new apps, HardenedBSD offers work around for FreeBSD change, Debian considers how to cull old packages, systemd ported to musl |
| • Issue 1086 (2024-09-02): Vanilla OS 2, command line tips for simple tasks, FreeBSD receives investment from STF, openSUSE Tumbleweed update can break network connections, Debian refreshes media |
| • Issue 1085 (2024-08-26): Nobara 40, OpenMandriva 24.07 "ROME", distros which include source code, FreeBSD publishes quarterly report, Microsoft updates breaks Linux in dual-boot environments |
| • Issue 1084 (2024-08-19): Liya 2.0, dual boot with encryption, Haiku introduces performance improvements, Gentoo dropping IA-64, Redcore merges major upgrade |
| • Issue 1083 (2024-08-12): TrueNAS 24.04.2 "SCALE", Linux distros for smartphones, Redox OS introduces web server, PipeWire exposes battery drain on Linux, Canonical updates kernel version policy |
| • Issue 1082 (2024-08-05): Linux Mint 22, taking snapshots of UFS on FreeBSD, openSUSE updates Tumbleweed and Aeon, Debian creates Tiny QA Tasks, Manjaro testing immutable images |
| • Issue 1081 (2024-07-29): SysLinuxOS 12.4, OpenBSD gain hardware acceleration, Slackware changes kernel naming, Mint publishes upgrade instructions |
| • Issue 1080 (2024-07-22): Running GNU/Linux on Android with Andronix, protecting network services, Solus dropping AppArmor and Snap, openSUSE Aeon Desktop gaining full disk encryption, SUSE asks openSUSE to change its branding |
| • Issue 1079 (2024-07-15): Ubuntu Core 24, hiding files on Linux, Fedora dropping X11 packages on Workstation, Red Hat phasing out GRUB, new OpenSSH vulnerability, FreeBSD speeds up release cycle, UBports testing new first-run wizard |
| • Issue 1078 (2024-07-08): Changing init software, server machines running desktop environments, OpenSSH vulnerability patched, Peppermint launches new edition, HardenedBSD updates ports |
| • Issue 1077 (2024-07-01): The Unity and Lomiri interfaces, different distros for different tasks, Ubuntu plans to run Wayland on NVIDIA cards, openSUSE updates Leap Micro, Debian releases refreshed media, UBports gaining contact synchronisation, FreeDOS celebrates its 30th anniversary |
| • Issue 1076 (2024-06-24): openSUSE 15.6, what makes Linux unique, SUSE Liberty Linux to support CentOS Linux 7, SLE receives 19 years of support, openSUSE testing Leap Micro edition |
| • Issue 1075 (2024-06-17): Redox OS, X11 and Wayland on the BSDs, AlmaLinux releases Pi build, Canonical announces RISC-V laptop with Ubuntu, key changes in systemd |
| • Issue 1074 (2024-06-10): Endless OS 6.0.0, distros with init diversity, Mint to filter unverified Flatpaks, Debian adds systemd-boot options, Redox adopts COSMIC desktop, OpenSSH gains new security features |
| • Issue 1073 (2024-06-03): LXQt 2.0.0, an overview of Linux desktop environments, Canonical partners with Milk-V, openSUSE introduces new features in Aeon Desktop, Fedora mirrors see rise in traffic, Wayland adds OpenBSD support |
| • Issue 1072 (2024-05-27): Manjaro 24.0, comparing init software, OpenBSD ports Plasma 6, Arch community debates mirror requirements, ThinOS to upgrade its FreeBSD core |
| • Issue 1071 (2024-05-20): Archcraft 2024.04.06, common command line mistakes, ReactOS imports WINE improvements, Haiku makes adjusting themes easier, NetBSD takes a stand against code generated by chatbots |
| • Issue 1070 (2024-05-13): Damn Small Linux 2024, hiding kernel messages during boot, Red Hat offers AI edition, new web browser for UBports, Fedora Asahi Remix 40 released, Qubes extends support for version 4.1 |
| • Issue 1069 (2024-05-06): Ubuntu 24.04, installing packages in alternative locations, systemd creates sudo alternative, Mint encourages XApps collaboration, FreeBSD publishes quarterly update |
| • Issue 1068 (2024-04-29): Fedora 40, transforming one distro into another, Debian elects new Project Leader, Red Hat extends support cycle, Emmabuntus adds accessibility features, Canonical's new security features |
| • Issue 1067 (2024-04-22): LocalSend for transferring files, detecting supported CPU architecure levels, new visual design for APT, Fedora and openSUSE working on reproducible builds, LXQt released, AlmaLinux re-adds hardware support |
| • Issue 1066 (2024-04-15): Fun projects to do with the Raspberry Pi and PinePhone, installing new software on fixed-release distributions, improving GNOME Terminal performance, Mint testing new repository mirrors, Gentoo becomes a Software In the Public Interest project |
| • Issue 1065 (2024-04-08): Dr.Parted Live 24.03, answering questions about the xz exploit, Linux Mint to ship HWE kernel, AlmaLinux patches flaw ahead of upstream Red Hat, Calculate changes release model |
| • Issue 1064 (2024-04-01): NixOS 23.11, the status of Hurd, liblzma compromised upstream, FreeBSD Foundation focuses on improving wireless networking, Ubuntu Pro offers 12 years of support |
| • Issue 1063 (2024-03-25): Redcore Linux 2401, how slowly can a rolling release update, Debian starts new Project Leader election, Red Hat creating new NVIDIA driver, Snap store hit with more malware |
| • Issue 1062 (2024-03-18): KDE neon 20240304, changing file permissions, Canonical turns 20, Pop!_OS creates new software centre, openSUSE packages Plasma 6 |
| • Issue 1061 (2024-03-11): Using a PinePhone as a workstation, restarting background services on a schedule, NixBSD ports Nix to FreeBSD, Fedora packaging COSMIC, postmarketOS to adopt systemd, Linux Mint replacing HexChat |
| • Issue 1060 (2024-03-04): AV Linux MX-23.1, bootstrapping a network connection, key OpenBSD features, Qubes certifies new hardware, LXQt and Plasma migrate to Qt 6 |
| • Issue 1059 (2024-02-26): Warp Terminal, navigating manual pages, malware found in the Snap store, Red Hat considering CPU requirement update, UBports organizes ongoing work |
| • Issue 1058 (2024-02-19): Drauger OS 7.6, how much disk space to allocate, System76 prepares to launch COSMIC desktop, UBports changes its version scheme, TrueNAS to offer faster deduplication |
| • Issue 1057 (2024-02-12): Adelie Linux 1.0 Beta, rolling release vs fixed for a smoother experience, Debian working on 2038 bug, elementary OS to split applications from base system updates, Fedora announces Atomic Desktops |
| • Issue 1056 (2024-02-05): wattOS R13, the various write speeds of ISO writing tools, DSL returns, Mint faces Wayland challenges, HardenedBSD blocks foreign USB devices, Gentoo publishes new repository, Linux distros patch glibc flaw |
| • Issue 1055 (2024-01-29): CNIX OS 231204, distributions patching packages the most, Gentoo team presents ongoing work, UBports introduces connectivity and battery improvements, interview with Haiku developer |
| • Issue 1054 (2024-01-22): Solus 4.5, comparing dd and cp when writing ISO files, openSUSE plans new major Leap version, XeroLinux shutting down, HardenedBSD changes its build schedule |
| • Issue 1053 (2024-01-15): Linux AI voice assistants, some distributions running hotter than others, UBports talks about coming changes, Qubes certifies StarBook laptops, Asahi Linux improves energy savings |
| • Issue 1052 (2024-01-08): OpenMandriva Lx 5.0, keeping shell commands running when theterminal closes, Mint upgrades Edge kernel, Vanilla OS plans big changes, Canonical working to make Snap more cross-platform |
| • Issue 1051 (2024-01-01): Favourite distros of 2023, reloading shell settings, Asahi Linux releases Fedora remix, Gentoo offers binary packages, openSUSE provides full disk encryption |
| • Issue 1050 (2023-12-18): rlxos 2023.11, renaming files and opening terminal windows in specific directories, TrueNAS publishes ZFS fixes, Debian publishes delayed install media, Haiku polishes desktop experience |
| • Issue 1049 (2023-12-11): Lernstick 12, alternatives to WINE, openSUSE updates its branding, Mint unveils new features, Lubuntu team plans for 24.04 |
| • 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 |
| • 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.
|
| Random Distribution | 
Venom Linux
Venom Linux is an independently-developed, rolling-release distribution inspired by CRUX. It targets experienced Linux users. Venom uses SysV init as the main init system and BSD-like ports as software packages which are managed by a custom package management tool called scratchpkg (written in compliance with POSIX standards). The distribution offers a simple graphical desktop built around the Openbox window manager and a text-mode system installer.
Status: Active
|
| 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.
|
|
• 
• 
• 
• 
• 
• 
• 
