No, it is because people in the Linux community are usually a bit more tech-savvy than average and are aware that OpenAI/Microsoft is very likely breaking the law in how they collect data for training their AI.

We have seen that companies like OpenAI completely disregard the rights of the people who created this data that they use in their for-profit LLMs (like what they did to Scarlett Johansson), their rights to control whether the code/documentation/artwork is used in for-profit ventures, especially when stealing Creative Commons “Share Alike” licensed documentation, or GPL licensed code which can only be used if the code that reuses it is made public, which OpenAI and Microsoft does not do.

So OpenAI has deliberately conflated LLM technology with general intelligence (AGI) in order to hype their products, and so now their possibly illegal actions are also being associated with all AI. The anger toward AI is not directed at the technology itself, it is directed at companies like OpenAI who have tried to make their shitty brand synonymous with the technology.

And I haven’t even yet mentioned:

• how people are getting fired by companies who are replacing them with AI
• or how it has been used to target civilians in war zones
• or how deep fakes are being used to scam vulnerable people.

The technology could be used for good, especially in the Linux community, but lately there has been a surge of unethical (and sometimes outright criminal) uses of AI by some of the worlds wealthiest companies.

Thanks! I just tried it out, it looks nice! I’ll stick with it for a bit.

Emacs is a religion, or an OS

Philosophy is a subset of religion, and there is a definitely an Emacs philosophy about making absolutely all software hackable, and controlling the computer using text.

App platforms are a subset of operating systems. People confuse the two because most app platforms are inseparable from the operating system on which they run. But some software, like the Web, or Java, or to some extent .NET/Mono, are app platforms that run the same apps across multiple operating systems. Emacs is an app platform.

How do you think one should get started with Emacs? Should they start start with regular GNU Emacs or should they install one of the “distros”?

I always recommend using the default setup for any software. The same goes for learning GIMP, Krita, Blender, FreeCAD, or whatever else, even though you can customize them all to your liking.

It is usually a good idea to try and learn the workflow that was intended by the people who developed this software, you could learn something from trying to use the computer in the same way that the professionals do. Same for Emacs: professional software developers have used it for almost 50 years, the default keyboard shortcuts are set the way they are partially for random historical reasons, but partially because they often make a lot of sense.

If you are interested, please check out my blog series on getting started with Emacs, called Emacs for Professionals

Of course people who pull the power plug to exit Vi would be the type of people to confuse app platforms with operating systems.

Emacs.

Emacs is an app platform in and of itself, and the vanilla installation comes with dozens of its own apps pre-installed. Like how web apps are all programmed in JavaScript, Emacs apps are all programmed in Lisp. All Emacs apps are scriptable and composable in Lisp. Unlike on the web, Emacs encourages you to script your apps to automate things yourself.

Emacs apps are all text based, so they all work equally well in both the GUI and the terminal.

Emacs comes with the following apps pre-installed:

• a text editor for both prose and computer code
• note taking and organizer called Org-mode (sort of like Obsidian, or Logseq)
• a file browser and batch file renamer called Dired
• a CLI console and terminal emulator
• a terminal multiplexer (sort-of like “Tmux”)
• a process manager (sort-of like “Htop”)
• a simple HTML-only web browser
• man-page and info page browser
• a wrapper around the Grep and Find CLI tools
• a wrapper around SSH called “Tramp”
• e-mail client
• IRC client
• revion control system, including a Git porcelain called “Magit”
• a “diff” tool
• ASCII art drawing program
• keystroke recorder and playback

Some apps that I install into Emacs include:

• “Mastodon.el” Mastodon client
• “Elfeed” RSS feed reader
• “consult” app launcher (sort-of like “Dmenu”)

I wrote a few articles on my blog for people in your situation, who are mostly only familiar with Windows and/or Mac and want to learn Linux more in depth.

“Advice for people who want to learn linux” – This article is kind of an overview of the Linux learning process. The point of this article is to teach you what it is you need to learn about so that you set your own curriculum. Once you understand what a few of the basic things are, you can look up your own tutorials on how to learn each thing.

“How to pick a Linux distro” – This article is for people who are overwhelmed by the number of choices for Linux distro. The bottom line is: don’t over-think it, just pick a mainstream distro like Mint, Ubuntu, or Fedora. There is like a 99.99% chance that each of these will just work as soon as you install it, no weird issues with audio, graphics, WiFi, BlueTooth, security updates, or anything else. Also, a lot of the “choices” you see among all those distros are only skin deep – differences in the default theming (i.e. the default “desktop environment”, a concept explained in the “advice” article above). But really they are all using the same basic software packages so there very little substantive difference between any of them except in their app stores, and the mechanism they each use install software.

If you have any questions, feel free to ask me here. I can clarify here, and also update my blog posts if you think anything is confusing.

As many here have said, but I will emphasize: learn the Bash programming language. Linux Survival is a very good start, and you can just start experimenting right away in your own terminal on your own computer.

To go more in depth, you can read through the manual on your computer by typing “info bash”. The Info documentation browser is a command line app. You may need to install it using your package manager (“apt-get” or “pacman” or “dnf”).

In the “info” app, you can navigate with the arrow keys, pressing enter on hyperlinks, typing l (lowercase “L”) works like the “back” button in a web browser, typing r (lowercase “R”) works like the “forward” button. Info also lets you search the index by pressing i (lowercase “I”) then entering your search in the prompt, or search the full text by pressing s and entering your search in the prompt. And q quits back to the command line prompt. “Ctrl-Z” pauses the “Info” app and drops you back into the command line, and you can resume your “info” session using the “%” (percent sign) command.

Another thing that can help is to learn about the GNU “Coreutils”, this is a suite of commands usually installed into /usr/bin or /bin which provides helpful command line utilities. These are commands like cat, wc, sort, cut, ls, du, cp, ln, chmod and many others. Read through the Coreutils Info manual by typing “info coreutils”.

And I will also reiterate recommendations from others: learn how to use Vim and/or Emacs. Vim has the more difficult learning curve but is extremely useful for writing scripts. Emacs is better though because it lets you split-screen with manual pages, and copy-paste commands between Man pages, “Infodoc” documents, the shell, and/or a text file, all using only keyboard commands. I think it makes it much easier to learn since everything is integrated together. Ask the Emacs community how to get started if you are interested.

It’s a i3-6006U with just 4.0GiB of RAM.

Emacs is considerably more lightweight than a modern Web browser, or any app based on Electron.js (e.g. VSCode) so a computer with those specs is more than powerful enough to run Emacs. If you use version 29.1 or later, Emacs comes with “libgccgit” which will spend a little time pre-compiling Emacs code to very fast native code.

Emacs used to have a reputation for being slow back in the early 1990s when 32 bit personal computers were just beginning to gain popularity. But nowadays when everyone downloads FlatPak and AppImage and Snap apps which install many hundreds of megabytes of code, Emacs is relatively small and light.

Also, Guile Emacs and Guilemacs are two different projects, right? Because I also happen to come across this, and I’ve been interested in this project as well.

The whole history of Guile and Emacs is here on the Emacs Wiki.

So there are a few projects related to Guile and Emacs. The link you provided me by Ken Raeburn is a fork of older versions of both Guile and Emacs, it seems it has not been worked on in about 20 years, unfortunately.

The project by Robin Templeton is also a little bit out of date, but still somewhat actively developed. You must build it from source from a patched version of (I think?) Emacs 26 or 27, I am not sure which it was. It works by loading libguile (the Guile interpreter/compiler) into Emacs so you can run Scheme code, and it also provides Scheme “foreign function” wrappers to the Emacs C APIs so you can do everything Emacs Lisp does in Scheme by importing the elisp-functions Scheme module. (There is an example of how to use it on the Emacs Wiki.)

I did hear Robin say in a recent Spritely chat that it could be made to work on Emacs 29 with not too much effort, they just haven’t had time to do it.

If you are interested in Scheme, you might also want to check out the Edwin text editor which is built-in to the MIT/GNU Scheme compiler, you launch it from the Scheme REPL with the (edit) function. It is a clone of Emacs 19 (a very old Emacs) written entirely in Scheme, but unfortunately it is a little too old to be useful nowadays, in my opinion. Still, you could learn something by reading the Edwin source code.

Finally there is TeXmacs, which is a full WYSIWYG application with a built-in LaTeX rendering engine designed for writing scientific papers, and it includes the Guile Scheme compiler for writing extensions, although I would not call TeXmacs a general purpose programming text editor the way Emacs is.

Steps are being made toward Guile Emacs integration. The work is mostly being done by Robin Templeton, who (last I heard) works at the Spritely Institute. And as I understand, there are other people pushing on the Guile in Emacs front as well, so you may not have to wait long.

Have you considered trying to setup Kakoune bindings in Emacs? For example like this: https://github.com/jmorag/kakoune.el

That looks like artwork from The Lispy Gopher Show. I love it!

EDIT: yep, artwork by Tomas Prahou a.k.a. @[email protected] .

I have been using both professionally for at least 15 years and IMO without a doubt Qt is so much easier to use, read and work with it’s not even a comparison.

I also use Qt professionally, and it is indeed an excellent GUI library. I have absolutely no complaints with how well it is designed and how easy it is to use, and I am consistently amazed by how beautiful the results are, especially with desktop environments like KDE Plasma.

My complaint, which is really a deal-breaker for me, is that Qt effectively forces you into using C++ and Python and/or QML+Quick. For the non-professional software I develop, I want my apps to be scriptable by end users, and I do NOT want to force them to choose between only Python or Quick as their scripting language. For building scriptable, truly cross-platform GUI apps, Gtk is the only game in town.

Gtk is much harder to use only if you are coding in C, because it depends so heavily on the C preprocessor to hack together the infrastructure that C++ has built-in. But because it is so easy to bind scripting languages to Gtk, you only need to program a few very core features in C, the rest you can program in any scripting language of your choice. This very important feature I think is a worthwhile trade-off for making it harder to code in C, especially if you are able to code the larger portion of your application (which is almost always the case) in a scripting language like Lua or Scheme. (Although I admit, most Gtk scripting is done in Python, just as it is with Qt.)

Plus in comparison to Qt there are almost no commercial outfits using Gtk professionally and selling products based on it.

Perhaps, but I would point out that both Canonical and RedHat (now IBM) are both heavily invested into developing Gnome, and I believe most of the paid Gtk development has been funded by these two companies.>

As someone who is trying to develop my own Linux destkop apps, I can tell you that the day that I switch to Qt is the day Qt provides a feature that works as well as GObject Introspection (GI) does for Gtk. GI creates a cross-platform database of objects, properties, and signals, for auto-generating language bindings, so you can customize your Gtk programs with scripting languages (Python, Lua, Vala, JavaScript, Scheme). It is a relatively simple task to bind any programming language to GObjects thanks to GI.

Qt does have a QMetaObject system which is similar, but C++ is a difficult language to bind to on most operating systems because of how native language functions are labeled in the library code – names are “mangled”, a hack to work around the miss-match between object libraries features (.so or .dll files), which do not provide the ability to “overload” functions, and C++ libraries features, which do provide this ability. The function/method overloading feature is used quite often in any C++ program. But decoding mangled names for language bindings can be very error-prone without the sort of automation that GI provides.

As it is now, really the best way to develop Qt apps is to use C++, with Python for scripting, because these languages are the most well-supported by Qt (C++ natively, Python being the most stable and well-maintained “foreign” language for Qt). And I like neither of these two language. Gtk gives you a much larger selection of scripting language choices, even though it is programmed in C, and this is thanks to how well GObject Introspection works.

Came here to say this. I once cut open a 9-volt battery and discovered it was really just 6 AAAA batteries wired in series.

Awk is a programming language designed for reading files line by line. It finds lines by a pattern and then runs an action on that line if the pattern matches. You can easily write a 1-line program on the command line and ask Awk to run that 1-line program on a file. Here is a program to count the number of “comment” lines in a script:

awk 'BEGIN{comment_count=0;} /^[[:space:]]*[#]/{comment_count++;} END{print(comment_count);}' file.sh

It is a good way to inspect the content of files, espcially log files or CSV files. But Awk can do some fairly complex file editing operations as well, like collating multiple files. It is a complete programming language.

Sed works similar to Awk, but it is much simplified, and designed mostly around CLI usage. The pattern language is similar to Awk, but the commands are usually just one or two letters representing actions like “print the line” or “copy the line to the in-memory buffer” or “dump the in-memory buffer to output.”

Whenever I open the symlink, does the software (player) understand «oh this file seems like a symlink, I should go and open the original file», or it’s a filesystem level stuff and software (player) basically has no idea if a file I’m opening is a symlink or the original movie.mp4?

Others have answered well already, I just will say that symlinks work at the filesystem level, but the operating system is specially programmed to work with them. When a program asks the operating system to open a file at a given path, the OS will automatically “reference” the link, meaning it will detect a symlink and jump to the place where the symlink is pointing.

A program may choose to inspect whether a file is a symlink or not. By default, when a program opens a file, it simply allows the operating system to reference the file path for it.

But some apps that work on directories and files together (like “find”, “tar”, “zip”, or “git”) do need to worry about symlinks, and will check if a path is a symlink before deciding whether to reference it. For example, you can ask the “find” command to list only symlinks without referencing them: find -type l

They do! /bin has the executables, and /usr/share has everything else.

Apps and executables are similar but separate things. An app is concept used in GUI desktop environments. They are a user-friendly front end to one or more executable in /usr/bin that is presented by the desktop environment (or app launcher) as a single thing. On Linux these apps are usually defined in a .desktop file. The apps installed by the Linux distribution’s package manager are typically in /usr/share/applications, and each one points to one of the executables in /usr/bin or /usr/libexec. You could even have two different “apps” launch a single executable, but each one using different CLI arguments to give the appearance of different apps.

The desktop environment you use might be reconfigured to display apps from multiple sources. You might also install apps from FlatHub, Lutris, Nix, Guix, or any of several other package managers. This is analogous to how in the CLI you need to set the “PATH” environment variable. If everything is configured properly (and that is not always the case), your desktop environment will show apps from all of these sources collected in the app launcher. Sometimes you have the same app installed by multiple sources, and you might wonder “why does Gnome shell show me OpenTTD twice?”

For end users who install apps from multiple other sources besides the default app store, there is no easy solution, no one agreed-upon algorithm to keep things easy. Windows, Mac OS, and Android all have the same problem. But I have always felt that Linux (especially Guix OS) has the best solution, which is automated package management.

I don’t understand this guy’s argument at all. First of all, he isn’t using any shell that I know about, he seems to have invented his own, and the command line arguments he uses are specific to his own shell. He doesn’t explain how these command line arguments work in terms of POSIX system calls, so I can’t follow along with what he is actually doing. As far as I can tell, these are security issues with his own software, not with Unix or Linux.

If you are worried about file mutability, you can use ZFS or BTrFS or BCacheFS. All of these filesystems have a snapshot function, so if any changes (e.g. file encryption by ransomware attackers) are made you can reboot and roll back the changes, unless the attackers figure out a way to get root access and delete your snapshots. But if an attacker has gained root access to your computer, that is a much more serious issue and not really in the scope of filesystem security or file mutability.

The snapshot and rollback feature also exists in NixOS and GuixOS, where your operating system kernel and all software installed is part of a snapshot that can be rolled back, if the system becomes unbootable, you can rollback from within the GRUB boot loader. Again, all software installation is managed by a service that runs for you at root level so you never need sudo to install software, and the software you install never effects any other user or the operating system. So the only way to hack this is to gain root access and alter the content of the Guix or Nix “store” database with malicious code, but again, root access is a much bigger issue than what we are talking about.

So yeah, the argument stated in this video makes no sense to me.

That might work if I re-bound the split-window function to launch a new Emacs client, because this is the function that most other Emacs functions use to split the frame into windows.

But I think a better approach would be to just add a single rule function into the display-buffer-alist that always asks for a new frame no matter what the input is.

Mickey Peterson wrote an article on how Emacs manages its own windows, and the Elisp Manual on Windows is pretty good too.

Yes! Emacs has already taken over most of my desktop environment apps with the exception of the web browser and a few apps like Blender and Gimp. I haven’t gone as far as you, getting each Emacs buffer to display in its own frame in is own WM-level window, but that would make for a more immersive experience. Also, your color scheme is similar to the one I use now. I love it.

I can’t wait for the day when software written in Lisp takes over my window manager, then my panel, then my session manager, then my whole operating system kernel.