iscream26

That's just the UX of most ebook reader application, it's not a limitation of the format itself. The conceptual model of the most popular epub readers are built upon the concept of a personal library, but that's just because, as you said: "most existing epubs are books". There's nothing stopping anyone from creating an epub file that's not a transcription of a book.

Calibre's e-book viewer should cover your use-case just fine, and in KDE is quite easy to set that viewer as the default application for epub files.

"Also known as a 'Slut Drop'."

https://www.youtube.com/watch?v=4og8wG8VQWM&t=74s

That is my intention yes, and I could swear that I did include the specific element on the link. But I guess either it was automatically removed or I somehow copied it wrong?

I got the link from Arch's wiki[1] (it's in the note at the end of the summary), all I did was right-click > Copy Link.

[1] https://wiki.archlinux.org/title/Systemd

Truly the be-all-end-all for Linux audio servers. All the ease-of-use of Pulse without any of its issues.

I wouldn't be that enthusiastic about it. Best I can say is that it is not terrible. In simplified terms, all it does is download exe files from URL addresses that it gets from yaml metadata files, and then silently executes them; which in turn means that it leaves all of the installer's checkboxes unmodified, cluttering your desktop with icons in the process. On top of that, Windows Terminal has been failing to update on my machine as of late. I don't think this should be the standard for a first-party package manager, but I'd say it's par for the course for Microsoft.

It's also worth noting that all of Winget's code was initially taken from AppGet, without much recognition.[1] Apparently Microsoft cared just enough about that detail to mention the project they forked in passing, as part of a list of third-party package manager projects for Windows.[2] This is why, IMO, you should always first consider a copyleft license for an open source project.

[1] https://www.theverge.com/2020/5/28/21272964/microsoft-winget...

[2] https://devblogs.microsoft.com/commandline/windows-package-m...

EDIT: fixed vertical spacing.

> Capitalism repeatedly creates situations where new things are created that make everyone's lives better, and existing things get cheaper and better over time.

> everyone's lives better

> things get cheaper and better over time.

Oh, fuck off with that bullshit. Capitalism may appear to thrive when living in a first-world country, but only does so through exploitation and cutting corners. More to the point, isn't it funny that despite capitalism being pretty much the de facto economic system of the world only a few countries are actually deemed worth living in? No, some abstract 'informed exchange of currency' didn't magically cause things to appear out of thin air. People make things, and they are almost certainly underpaid and overworked. Behind every AI model there are X poorly paid workers around the world that curated the data that it needs to function. Behind every piece of clothing there are Y poorly paid workers in Bangladesh that made it. And behind every rechargeable battery there are Z Congolese kids risking death inside a mine in search for cobalt. We might try to (and often do) look away, pretend that those are the unfortunate results of corporate blunders that seldom happen, but they're not. Invisible exploitation is what makes the kind of lifestyle that is available in first-world countries possible.

Corporations (and the wealthy in general) don't do charity. The tacit objetive of every corporation is and will always be profits über alles. Every time you see a corporation donating money to some cause there's an ulterior motive that ultimately grows their bottom line. The most common motives are: pay less taxes (or none at all), PR move to improve their public image, and, finally, publicity (sometimes because of controversy).

Now, of course, Google's financial relationship with Mozilla is no exception. The stated reason is that they give money to Mozilla in exchange for having Google as the default search engine, but its actual purpose is to mitigate claims about Google having a monopoly on the browser market and thereby avoid anti-trust laws.

If Firefox were to gain the majority of the marketshare Google would no longer have an incentive to give them money. Mozilla wouldn't be happy about that because they'd lose their biggest source of income. And Google wouldn't be happy either because they make money through web ads and harvesting data to sell it to ad companies, and there's no better way to go about doing that than creating their own web browser and a whole ecosystem surrounding it, and then making sure it's the most popular one.

> The reasons for the deficiencies in human-machine interaction are numerous. Some come from the limitations of today's technology. Some come from self-imposed restrictions by the designers, often to hold down cost. But most of the problems come from a complete lack of understanding of the design principles necessary for effective human-machine interaction. Why this deficiency? Because much of the design is done by engineers who are experts in technology but limited in their understanding of people. "We are people ourselves" they think, "so we understand people." But in fact, we humans are amazingly complex. Those who have not studied human behavior often think it is pretty simple. Engineers, moreover, make the mistake of thinking that logical explanation is sufficient: "If only people would read the instructions," they say, "everything would be all right."

> Engineers are trained to think logically. As a result, they come to believe that all people must think this way, and they design their machines accordingly. When people have trouble, the engineers are upset, but often for the wrong reason. "What are these people doing" they will wonder. "Why are they doing that?" The problem with the designs of most engineers is that they are too logical. We have to accept human behavior the way it is, not the way we would wish it to be.

— Don Norman, The Design of Everyday Things

> Snaps

A technology superseded by Flatpaks, yet pushed incessantly by Canonical, a befuddling move that I still don't quite understand. Rough to use in any other distro.

> AppImages

Speaking from experience, these don't run on every distro. So they fail to fulfill their intended purpose. As far as I'm concerned, that makes distributing software as AppImages a no-go.

> Flatpak

Better than any of the technologies previously quoted, but it is not without it's own issues. The chances of a Flatpak working on any particular distro are acceptably high, but they still suffer from the same problem AppImages do. I've had an instance were a an app refused to run on OpenSUSE, even though it was working completely fine on Fedora (I was using Flathub's repo on both distros, I wasn't using Fedora's, just to clarify). I think it was Firefox, though I'm not 100% on that.

Still, I'm yet to see a commercial software being distributed as a Flatpak. My guess is that it's all more of a hassle than it is worth. Which, I guess you could say that about packaging commercial software for Linux in general. So, we're back to square one with the chicken and the egg problem that Linux suffers from. Though nowadays it's less severe what with the existence of SteamOS and all of that, so at least there is a substantial marketshare, small as it is.

EDIT: fixed vertical spacing.

No, but packaging a software package for every Linux distro that exists is unfeasible. Not that I care though, I don't run commercial software. But, you know, devil's advocate and all that. Still, I completely understand why someone might be frustrated by the way software is usually installed in Linux if they were, say, a game developer.

> So, I kind of like the idea of Emacs Lisp providing a GUI toolkit, and then the Emacs interface being implemented, in Emacs Lisp, with that toolkit.

I was just thinking this myself. I was thinking about a small, limited-vocabulary (widgets) GUI toolkit (implemented without web technologies) inside of Emacs that could still be navigated with a keyboard. GUI windows would be differentiated from buffer windows, and so functions that are defined for one of them couldn't be enabled on the other. Packages could implement their functionality in either type of window, or both, depending on their purpose.

> I enjoy using a TUI for certain things, either on low-resource devices, or an actual vintage terminal, and so on. [...] That's something I'd dearly hate to lose.

In the imaginary implementation I described above those would still work, they would be buffer-interface-only packages. They wouldn't have to be re-implemented nor updated to keep working properly.

> You could sort of work around that by defining abstract widgets and providing both GUI and TUI implementations, but that constrains the GUIs a lot [...]

It doesn't have to be that way. If GUIs and buffers are defined as different types of interface paradigms that can be used and modified within Emacs, then GUIs could be completely different from their buffer counterparts and vice versa. Packages that wouldn't make sense having on a terminal wouldn't have to implement a buffer interface for it. And not every package would have to implement its own GUI interface either if there's no need for it; buffers are a very simple data model with a vast amount of tooling for them that can all (in theory) work in tandem, so they would still be an attractive baseline for any developer looking to extend the functionality of their editor.

That line of reasoning would make sense if the have-nots in a liberal society didn't need to work just to survive. But that is not the case, is it?

Liberal society loves to characterise itself as a rigid, well-structured system in which individuals choose to make idealised rational decisions to work towards their own interests. As opposed to emotional reasoning, which is conveniently implied to be the diametrical opposite of rational thought. And I call it "convenient" because as a result can easily paint protests and strikes, as "irrational" and "despicable" actions perpetrated by "unreasonable" individuals.

However, as soon as one considers the fact that the disparity of power between people with private property and people without makes it so that the people without private property cannot afford to make decisions on a "rational vacuum". We quickly find ourselves reverting back to "what are you going to do about it? You don't work, you don't eat."

> Employers setting limits on the conduct of employees on the job is generally not a freedom of speech, or first amendment issue.

In other words: you're allowed to restrict the speech of other people as long as you own private property. Turns out that freedom of speech in a liberal "democracy" is not all it's cracked up to be.

It's just rhetorical hyperbole, you're reading too much into it.

> just remembering how software used to be three whole years ago causes me to shudder

Well, yes. I agree with that statement even though you made it facetiously. Backporting security fixes only for bugs that have made enough noise to warrant it is a horribly janky hack. And, just thinking about all the time that has been, in my opinion, wasted on custom code that Debian maintainers have had to write in order to backport fixes makes me shudder.

It's always been creepy to me that whenever the topic of US foreign policy brought about from the angle of "other nations should impose to the US the same geopolitical policies that it imposes over other nations" some US citizens are quick to talk like bullies threatening to retaliate with their military forces if any of those suggestions were to come to fruition.

However, when that same topic is kicked off with "the people of an enemy state are struggling" they act as if they were nothing but concerned, compassionate humanitarians. The wording of the message changes, but the intent does not. The desired result is still intervention without consequences.