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.
I don’t want pagination for reference documents, for one thing – I want fast seamless scrolling.
Not sure if that’s still the case, but on macOS, it used to be hard to open more than one ePub file at a time using Calibre too – also an essential feature for research.
Finally, Calibre viewer edits each opened ePub by inserting a “last reading location” metadata file by default! It’s possible to deactivate in the settings, but I need to remember to do it for every new installation. It’s an absolute no-go as a default for a document viewer.
I wouldn't assume that any application doesn't edit documents, especially metadata. My PDF application remembers the last location and zoom level viewed, though I don't know how.
Not just KDE, any Linux desktop should be able to do this. It certainly works perfectly well in Linux Mint Cinnamon and Xfce. It's a long time since I used Windows but I think it works there too.
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.
The page provides a "canonical" link in its markup, and HN takes that and replaces what you submitted. I believe you can change it back, for a certain amount of time?
That pipe wire can often meet or beat pro-audio JACK for latency is so elegant & nice. Defeating that compromise of PulseAudio seems like the crowning achievement to me; there's not a lot of other faults or defects I felt with PulseAudio, and I say this as someone who has had sound servers with half a dozen audio cards (mostly USB) I've run off a system, as someone who has streamed PulseAudio from one system to another.
The technical sophistication of PipeWire is almost purely made possible by Linux improving, by the availability of DMA-BUFs for shared memory inter-process work. This wasn't possible when PulseAudio (nee Polyp) was being created; the kernel couldn't do that then.
On top of this modern base, pipewire has done a fantastic job generalizing it's architecture. It's also designed to pipe video. It could conceivably be used to pipe input events, or other arbitrary streams too. This is a cool upgrade that I hope we see more leaning into over time; I hope PipeWire someday becomes so pervasively used for so many reasons that it is even more known, tapped, used, & loved that dbus, the current inter-process nexus of FreeDesktop.
> The technical sophistication of PipeWire is almost purely made possible by Linux improving
I'm not sure about that. I guess improvements in ALSA have contributed. But PipeWire was created by none other than the guy who rearchitected GStreamer's foundations after GStreamer had been brittle and prone to crashing for years. I don't think that there was a better person in the Linux ecosystem to do it. It's the second system effect without featuritis, like when some of the Unix people created Plan 9.
Personally, I was not happy with PulseAudio, and I'm very happy with PipeWire. Great, great stuff.
I say that as both a user and somebody who created a prototype for a sound system for an embedded platform on top of PulseAudio that was, AFAICT, abandoned because it just couldn't deliver some things. PipeWire was on the radar at the time but too much in its infancy to use back then. That stopped being the case years ago.
I love this paean, and I am delighted to assimilate this gleeful happy memetics into my own. But I think the hate sucks & can get lost. Maybe it's not hate, but I'm just so done, so fed up with intolerance and/or nattering against Lennart Poettering, and it all comes off as ridiculous to me. Whatever the qualms: Pulseaudio and systemd have been such vast giant leaps over where we were before. Most of the voices are just against. That is, they don't saying what else we ought have done, they dont speculate constructively. They're winges (thank you Ben Collins for re-introducing me to that word). It would be such a bleaker worse world without pulseaudio and without systemd. (I'm sorry to hear your product ran into such difficulty though!)
I absolutely am happy to hand a massive trophy to Wim Taymans for building a truly elegant API architecture. But I repeat again: the core of PipeWire would not have been possible without the better Linux we have today. PipeWire competes with JACK because of https://docs.pipewire.org/page_dma_buf.html . That's basically a fact.
Pipewire is a refinement of the idea, many of these lessons are hard won by pulseaudio itself, being used for years.
Linux audio before pulseaudio was just a lot worse, for many people pulseaudio meant not having to think about how audio worked any more.
Pulseaudio saved my bacon just the other day with virtualization - since the server runs on OSX I could pipe all the audio devices from an OSX host to a Linux guest.
I’ve had nothing but issues with PulseAudio, leading me to disable it and use plain ALSA (with dmix) on basically every Linux system I’ve used. I’m excited that it’s being replaced, but I no longer use desktop Linux very often.
I hope the pro audio side gets a bit more love. I've installed PW for the first time on my Ubuntu 22.04 (through https://pipewire-debian.github.io/pipewire-debian/) and so far have been experiencing high CPU usage on Bitwig Studio v5.0.11 when trying to send audio from and to my Native Instruments Komplete Audio 6, and I have no idea what the culprit might be.
I'm going to try a bunch of stuff and hopefully be able to take advantage of this wonderful technology (that has already come _so_ far!)
I should probably document my troubleshooting ventures. Does anyone know a nice hosted blog that supports Markdown / CommonMark and RSS syndication? Is Substack a good option?
I'm running Arch (not that it should matter) with the newest Bitwig without problems. I'm using a Behringer interface though. Additionally I have a Roland synth acting as another sound card. This also works with Pipewire/Bitwig at the same time as the main interface. I couldn't get it running with JACK before.
I'd start with checking all sinks/sources to make sure you're not resampling by accident. But even that shouldn't be causing high CPU by itself. There's pw-top/pw-profiler to help you.
Thanks for the pw-profiler recommendation, wasn't aware of that one.
I believe the Pro Audio profile [0] (which I'm using) doesn't resample by default.
Using pw-top, I noticed that something was causing xruns [1] (see ERR column) though I was unsure what that was. Since the Pro Audio profile uses the IRQ mechanism, I looked at interrupts [2] but couldn't spot anything unusual. There is however irq/16-mmc0 process which is at times causing significant (>50%) CPU usage, so I think I need to unload the sdcard module and see if that fixes anything.
First however I think I'll try a newer kernel (linux-lowlatency-hwe-22.04, which according to apt search is on 6.2.0.1017.17~22.04.14 as opposed to the current 5.15.0-89-lowlatency that ships with Ubuntu 22.04)
When reading posts like these, I sometimes I feel very lucky having a MacOS M1 setup that does what it's supposed to and which works almost seamlessly with external hardware. Best of luck to your venture.
I think that's skipping some context though. Don't know about the previous poster, but I'm using pipewire for things that MacOS just can't do, at latencies which MacOS can't pull off, with codecs that MacOS can't support. So although I spent an hour or so on the setup / resolving issues, that's still 100% better.
Yeah, the basic things just work on MacOS. But try to do fancy audio routing, low latency processing and other things and you're left with spending hundreds of dollars on apps that give you half a hacky solution.
I'm sure PipeWire is technically more advanced, but as someone that just wants to make music using a DAW by tracking external synthesizers, a _bit_ higher latency doesn't kill, especially if the DAW can compensate for said latencies.
It's nice to hear that PipeWire supports more codecs, but here WAV, FLAC and MP3 are more than sufficient for my needs (and the needs of 99% of producers out there)
At the end of the day when I'm inspired I simply want to make music instead of mucking around with config and troubleshooting. It might be that the Linux audio landscape will offer this at some point, but I don't see that happening any time soon.
> Yeah, the basic things just work on MacOS. But try to do fancy audio routing, low latency processing and other things and you're left with spending hundreds of dollars on apps that give you half a hacky solution.
This; and that also includes running macOS version a release, two or three behind, because the newer ones break your setup.
> This; and that also includes running macOS version a release, two or three behind, because the newer ones break your setup.
That's true, and it's a widely known wisdom, but in my case my Mac isn't even connected to the network: I'm using it just as an appliance solely dedicated for audio / video editing and production.
I also hope the "pro" audio side gets more love. I'm not an audio pro, but I do play music.
Long story short, I tried pipewire for a year, it was a wasted year. Realtime audio never worked, it was a mess of configurations that didn't fix anything. Went back to Jack, everything worked.
Was sad that I could have spent more time making music instead of messing with "the newest, greatest, and best" in the Linux world.
I ran into a bunch of issues with it on a headless userless system. Unfortunately, like pulse, it's deeply integrated with dbus/policykit/xdg stuff. Wireplumber was looking for XDG_HOME_DIR and breaking when it couldn't find one, dbus issues when doing things from root services, Jack clients couldn't connect, etc.
I'm prepared to like it better than pulse, and alsa has its warts, but I'm not 100% convinced yet.
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.
> 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.
Is there no exploitation in communist nations? I should actually phrase that the other way around: is there, or has there ever been, a communist nation that did not exploit people to the max, even killing them if that was the most convenient option?
As for cutting corners, check out some videos on tofu dreg projects, it will enlighten you on corner cutting in a communist system.
> Capitalism may appear to thrive when living in a first-world country, but only does so through exploitation and cutting corners
I think this is a common and really fundamental misunderstanding. It works through signalling demand through pricing, rather than through bureaucrats guessing, giving anyone the chance to take a risk and keep the reward (mostly) if they manage to create value for other people, rather than how much they toe the party line. It definitely doesn't only work "through exploitation and cutting corners". Those things happen everywhere.
Just look at the monumental change in China due to the controlled (too controlled[0]) introduction of capitalism. If you let people create value for each other and get out of their way, you get stupendous results compared to thinking a centralised bureaucracy, slave-owner, monarch, or lord making the decisions.
> No, some abstract 'informed exchange of currency' didn't magically cause things to appear out of thin air
No one would say it did.
> 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.
This isn't a capitalism thing. This is a poverty thing. It's lifted unequally globally, but it is lifted. The problem isn't capitalism; the problem is that doing these jobs is currently their best option. Similar or worse conditions were found in Britain under 100 years ago[1]. That's a very short timeframe for capitalism to have lifted the entire world out of poverty; too silly to take seriously as a criticism of an economic process.
> 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.
No, not just that. If we replaced those miners with robots we'd still have the lifestyle. Framing everything as exploitation is a dead end.
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.
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.
99% of software packed for Debian will just work with any of the derivatives. No idea how it looks like on the RPM side, but as long as your distro is new enough, 3rd party software packaged for Ubuntu usually works on Debian and 3rd party software packaged for Debian near-always works on derivatives.
Yes, packaging a software package for every Linux distro _is_ unfeasible, but have you ever used Linux? There are snaps, flatpaks, and AppImages, which can all run in any distro, and are generally more secure than "native" packages (for lack of a better word).
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.
How do you define "commercial software"? Spotify, Zoom, Steam, Discord, Postman, IDEA Ultimate, and lots of other end-user software that is built by companies and where people pay for things (i.e. commercial software?) is available through Flathub.
Most commercial software in general can be downloaded as a free demo version and then activated with a license key or account, and that model works really well with Flatpak and even Flathub.
> 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.
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.