d3Xt3r @ d3Xt3r @beehaw.org

Posts

15

Comments

146

Joined

2 yr. ago

I have the first Boox Nova (color) and while it's true that the colors aren't vivid, it actually makes for a great comic book (and manga) reader. The color pallete in comics is generally limited anyways, plus the grainy low-DPI image reminds me of how comics used to look like back in the day. So ironically the limited display actually makes it a great fit for comics.

But of course, it's not ideal if you have want to read full-color high-res content like magazines and modern webcomics (you can, but the performance isn't really that great).

For me though, as a manga/comic reader, instead of the display, the most limiting thing I found was actually the RAM - after a long comic reading session it would run out of RAM, bringing the OS to a crawl, and forcing me to restart my apps. But it's not a huge issue, or maybe there's a memory leak in Tachiyomi. Regardless, I feel 3GB isn't enough for any large device these days.

Still, right now, this is the best "open" ereader that you can actually buy, that doesn't lock you into any subscription (like the reMarkable tablets) or proprietary apps.

Not possible. At least, not yet. Two main reasons for this:

1 There is no standardized BIOS/UEFI equivalent in ARM, as a result, the boot process in every ARM system differs in general. The only "standardized" boot process you'd see would be for that particular type of system from a single vendor, eg the way most Android devices boot is generally the same - although even in Android, some manufacturers make their own changes, for instance Samsung introduces their KNOX into the picture, some devices use the A/B partition system but some dont, etc.

The lack of a standard boot/initialisation process, and the lack of a hardware auto-detect feature, means you can't just mix and match components like you'd do in a PC - the bootloader wouldn't know how to initialize those hardware bits, heck, it wouldn't even know the hardware existed unless you manually defined it somewhere - this is done using something called a Device Tree, which, although is a standardized format, still needs to be manually created, and also, the bootloader used needs to support this in the first place (like UBoot, but not all ARM systems use this).

2 The other reason is lack of standardized hardware. In the x86 world, PCs have a rich ecosystem of standardized components, from motherboards to graphics cards, which have evolved over decades, and standards were developed organically over time - and agreed upon by other manufacturers. Sometimes these standards were made or guided by special interest groups / consortiums / other regulatory boards etc. ARM lacks this.

But it wasn't always like this in the PC world, back in the early days of personal computing, you had different types of PCs and hardware that were basically incompatible with each other, similar to the ARM systems of today. It was mainly due to the popularity of IBM PC, that things began to change. Unlike many other computers of its time, the IBM PC had an open architecture. This meant that its specifications and designs were made publicly available, allowing third-party manufacturers to produce compatible components and peripherals. One of the key features of the IBM PC was the Industry Standard Architecture (ISA) bus (the precursor to the PCI bus), which allowed for the addition of third-party cards. This established a standard for expansion that was widely adopted and emulated.

As IBM PCs gained in popularity, other manufacturers started producing "IBM compatibles" or "PC clones." These machines were designed to be hardware and software compatible with the IBM PC. Companies like Compaq successfully reverse-engineered the BIOS, allowing them to create systems that could run software designed for IBM PCs. Also, IBM's choice of using Microsoft's MS-DOS as the operating system was crucial. As DOS became the de facto OS for PCs, software developers focused their efforts on creating software for this platform. This drove further hardware standardization as manufacturers aimed to produce hardware compatible with MS-DOS and its applications. As the industry grew, this lead to the creation of more standards, some of them competing, some losing out due to lack of popularity etc. The result is the PC world that you see today.

ARM lacks all of this rich history. Where ARM is at right now is where PCs were at before the introduction of the IBM PC. We need to go thru all those motions again to be able to build your own PC. But I don't see this happening any time soon, in fact it's doubtful if it'll ever happen, since the trend these days is for vendors to build closed, unrepairable, unserviceable systems - so that you get locked into their ecosystems, so that you're forced to upgrade your entire device just to get say, more RAM or whatever. And unfortunately, even PC manufacturers are picking up on this trend, as we're seeing with laptops.

So unless something changes drastically, like some big manufacturer stepping forward to create an open ARM PC and ecosystem, being able to build your own ARM PC will remain a pipe dream.

https://github.com/orgs/unifiedremote/

The main difference is that Box86 does not support 64-bit binaries. There is Box64, but it can't run 32-bit. FEX does not have that limitation, which is handy if you want to run Windows games (which are mostly 32-bit) on Apple Silicon (64-bit).

There's also a performance difference. A benchmark from last year showed box86 outperforming FEX considerably in CPU-only workloads (50% faster), but the difference in OpenGL performance wasn't much. There have been several improvements to FEX since, then so I'd expect it would've closed the gap by now.

This is encouraging news for folks on Apple Silicon looking to run x86 programs on Asahi Linux, or folks on Android looking to play PC games via the upcoming Cassia emulator.

Sauce?

Playing PS1 games on your 65" OLED will probably hurt your eyes. It’s one of those things that you want to do because of nostalgia, but isn’t really great when it comes to it.

That really depends on the game and upscaling methods used. Duckstation for instance does a pretty amazing job of making most of those old games look good. Check out this video of Crash Bandicoot running at 4K for instance.

Still playing Star Wars: Galactic Battlegrounds and 0 A.D. See this comment for details.

Also checked out SWTOR but I couldn't get past the clunky controls and camera, so considering dropping it. Also checking out Star Trek Online for the first time, and it's looking promising. The combat is a bit weird, but I like the controls better than SWTOR.

Have you checked out Unified Remote? It's been the gold standard for Android-PC remote control for several years now, before KDE Connect was even a thing. It's open-source and is also on the Play Store.

As for your Bluetooth woes, I'm unsure, in my experience Bluetooth has always been a bit iffy, and it's succeptible to interference as it uses the 2.4GHz band. Better to stick to WiFi I reckon, it's faster and you don't get any interference issues (if you're using 5/6GHz bands).

There's some info here on the immutability: https://nxos.org/tutorial/filesystem-security-privacy-and-anonymization-features-in-nitrux/#xfs-features-and-root-immutability-in-nitrux

No, that only deletes the leftover dependencies, it doesn't delete any app data/config left over.

The first movie was indeed about the Voyager satellite, but my comment was referring to the Voyager TV series, where the starship Voyager (presumably named after the satellite) is lost in deep space and too far away from earth for any comms to go thru.

Technically speaking, OpenRC doesn't really have any benefits in the real world, some people may claim faster boot times, but that's debatable on modern hardware. In fact objectively, it's inferior to systemd in many ways.

The real advantage though is that it's pretty simple and easy to use, understand and maintain. It follows the Unix philosophy of "do one thing, and do it right". People who like to have full understanding and fine control over their systems would prefer using OpenRC or similar init systems (with a mix-and-match of other utilities and daemons as per their need), instead of relying on a giant monolothic package like systemd which keeps getting bloated with more and more "unnecessary" features with each release.

Basically, you can say that it's a difference of ideology.

Technically speaking, OpenRC doesn't really have any benefits in the real world, some people may claim faster boot times, but that's debatable on modern hardware. In fact objectively, it's inferior to systemd in many ways.

The real advantage though is that it's pretty simple and easy to use, understand and maintain. It follows the Unix philosophy of "do one thing, and do it right". People who like to have full understanding and fine control over their systems would prefer using OpenRC or similar init systems (with a mix-and-match of other utilities and daemons as per their need), instead of relying on a giant monolothic package like systemd which keeps getting bloated with more and more "unnecessary" features with each release.

Basically, you can say that it's a difference of ideology.

This reminds me of that Episode in Star Trek when Earth managed to reestablish communications with the starship Voyager, which was also far away from home.

I've never had an actual meat burger so I can't really say how this compares, but you can have pretty tasty meat-free burgers with plant based ingredients. For instance, a potato based patty, corn fritters, mushrooms all make for tasty meat-patty replacements. What I personally dislike though is those fake meat burgers, like the "Impossible Beef" one. A burger joint here recently got rid of their portobello mushroom burger and replaced it with an Impossible Beef one, so I gave it a try - and it was disgusting. The portobello mushroom one used to be absolutely delish, and I couldn't believe they replaced something so tasty, with fake beef. In saying that, my meat eating buddy tried the patty and he said it tasted just fine, almost identical to real beef. So it was my vego taste buds that rejected it, and there was nothing wrong with the fake beef apparently...

Anyways, I digress, I guess what I'm trying to say is, you can definitely have a tasty burger with plant based ingredients.

Garlic chilly powder. An Indian mate of mine introduced it to me recently, and I reckon anyone who loves spicy food should have this in their pantry. You could use it as a spice in your stir-fries and curries, or sprinkle it on your fries/roasted veggies/pizza/pasta, add it to your favorite sauce or salsa, or just add some to whatever dish your making to give it a spicy garlicy boost. You can find this ingredient in Indian stores, if not, it's simple enough to make it at home.

Also, in Japanese shows, I have no idea why they kept making the actors who can't speak English, speak English.

This is a common trope in anime, and it kills the immersion. Like, some girl (typically named "Elizabeth" or "Claudia"), who is British, but is now attending a school in Japan due to some foreign exchange program or something, speaks fluent Japanese but super broken English, but everyone is impressed regardless.. Or even worse, when they're supposed to be an English language teacher but still speak very broken English with a thick Japanese accent.

BTW, here's a pretty cool video everyone in this thread should check out: How English Sounds to Japanese People

You should also check out Droid-ify if you like F-Droid. Has more sources, notably those apps on Github which aren't on F-Droid. Since it can grab apps from Github directly, it gets updates much faster than F-Droid.

I'm curious what "basic settings" require you to touch the command line. My elderly mum and dad - who aren't very tech savvy btw - have been running Linux for nearly a decade now (Xubuntu previously, now Zorin) and haven't had any major issues in all this time. Admittedly their requirements are pretty basic, but they do all your tasks a typical basic PC user would - surf the web, check emails, work on documents, print and scan stuff, backup files from their phones/USB drives, video chat etc. In fact, the entire reason why I got them onto Linux in the first place was because Windows wasn't really stable for them - I got tired of having to troubleshoot or reinstall Windows for them all the time. They'd complain about how an update broke something, or how the system was becoming slower etc. But no such issues with Linux. Occasionally I might get a call asking "how do I do this", but after a few years, these support calls have all but vanished. Linux "just works" for them, it's rock solid, the GUI is intuitive (at least for Xububtu/Zorin) and they never had to touch the command line.