Thanks! That was helpful!

The specs say it’s Marvell 6281 1.2GHz… not sure what that is but the search leads to some deeper specs for a RISC CPU that is both 32bit and 16bit. The info is dicey because “6281” does not appear in those docs. In any case, I suspect you’re right, that it’s not 64 bit.

well, I can just choose something that suits my tastes instead from the internet?

I have no Internet, because the war on cash means there is tolerance for ISPs to effectively (and unlawfully) refuse to serve unbanked people. Being offline makes other info sources much more important. Unbanked people can get Internet but it’s a much higher price because only prepaid GSM providers are willing to take cash.

(In practice, I would rather that we had more resilient mobile infrastructure, as more and more people have phones and can receive SMSs in an emergency; and more people getting into CB due to the possibility for bi-directional communication)

Is that possible? SMS is notoriously unreliable. Sometimes I receive an SMS a full day after it was sent. Sometimes I never receive an SMS that someone is absolutely certain they sent. The tech seems to be inherently unreliable. Radio pagers from the 1980s are reliable. So it was foolish to ditch radio pagers, IMO. I wish I could buy a radio pager and subscribe. Some emergency response operations (firefighting and ambulance services) were smart enough to continue using radio pagers, but this service is not offered to the general public.

Is there a technical requirement for the 3+ seconds of decoding before sound output? Or is this a matter of simply waiting for buffers to be filled before outputting?

It’s a limitation of physics. No computer takes zero time to execute instructions. I don’t know to what extent buffering contributes to that, but it does not matter. You can’t really have a situation where all receivers are in sync with their decoding times. The only possibility would be to choose an easily achievable timespan, then mandate that all players add a delay. But this is borderline crazy talk. WRT point #1: given no legal interference, it would be possible for a radio to have several tuners so when someone is channel surfing, it could theoretically anticipate the need to give them the next signal in chronological sequence, to give an FM-like tuning experience.

Your points about 1 and 7 really seem like a product issue more than a technology issue

They are solvable issues, apart from point 4 (and realistically point 6 as well). That does not excuse a nationwide oppressive mandate to cut off FM transmissions and render all FM radio receivers as needless e-waste.

Point 6 is not really the fault of DAB but instead of how the infrastructure is setup. FM transmitters could be source their data from the cloud too, and would be vulnerable to the same things.

I would like to see the physical size difference between a vacuum tubes FM tuner and a DAB tuner. I doubt anyone will be making tubes DAB radios, but if they did there is a heck of a lot more complexity due to the AAC digital compression which must be replicated in analog circuits.

At the national levels. Western nations are independently making the same decision to nix it. Denmark kills FM this year. France in 2033 IIRC. Belgium also has plans to kill FM.

AM also on the chopping block.

Graphene is Android. Why would a bank’s app not work? @TheHobbyist@lemmy.zip suggests that some banks proactively detect and block Graphene, while other banks’ apps simply accidentally fail on Graphene. Is accidental incompatibility really a notable issue on Graphene?

I have not tried much of anything yet. I just got a cheap laptop with a BD which came with Windows and VLC. I popped in a blu-ray disc from the library and it could not handle it… something about not having a aacs decoder or something like that. I didn’t spend any time on it yet but ultimately in principle I would install debian and try to liberate the drive to read BDs.

thanks!

Though I should mention my original motivation with makemkv was to rip blu-ray discs, which has complications that go beyond DVD. But the DVD guide will still be quite useful.

Two possible issues w/that w.r.t my use case:

• not in official Debian repos – not a show stopper but definately points against it for installation and maintenance burdons across migrations
• apparently read-only access for users. This is fine in simple cases where I would just be sharing with others, but a complete solution enables users to share with others on the same server by uploading. Otherwise everyone with a file to share must run rejetto hfs.

Nonetheless, I appreciate the suggestion. It could be handy in some situations.

I use filezilla but AFAIK it’s just a client not a server.

Indeed i noticed openssh-sftp-server was automatically installed with Debian 12. Guess I’ll look into that first. Might be interesting if ppl could choose between FTP or mounting with SSHFS.

(edit) found this guide

Well it’s still the same problem. I mean, it’s likely piracy to copy the public lib’s disc to begin with, even if just for a moment. From there, if I want to share it w/others I still need to be able to exit the library with the data before they close. So it’d still be a matter of transcoding as a distinctly separate step.

What’s the point of spending a day compressing something that I only need to watch once?

If I pop into the public library and start a ripping process using Handbrake, the library will close for the day before the job is complete for a single title. I could check-out the media, but there are trade-offs:

• no one else can access the disc while you have it out
• some libraries charge a fee for media check-outs
• privacy (I avoid netflix & the like to prevent making a record in a DB of everything I do; checking out a movie still gets into a DB)
• libraries tend to have limits on the number of media discs you can have out at a given moment
• checking out a dozen DVDs will take a dozen days to transcode, which becomes a race condition with the due date
• probably a notable cost in electricity, at least on my old hardware

Wow, thanks for the research and effort! I will be taking your approach for sure.

I’ll have a brief look but I doubt ffmpeg would know about DVD CSS encryption.

Also worth noting Brother uses that trick where empty cartridges are detected by a laser which is exactly not positioned as low on the cartridge as it could be, forcing people to toss not-so-empty cartridges.

BTW, regarding the trackers dots I’ll drop a link here for anyone who wants to verify Brother’s role in it:

https://www.eff.org/pages/list-printers-which-do-or-do-not-display-tracking-dots

Another reason to use inkjets: GHG footprint. Inkjets use far less energy than lasers. It’s a shame we have to choose between ecocide and tricks and traps.

The only no-compromise path I see is to pull an inkjet from the dumpster, fix it, and refill the cartridges with homemade “ink” from spent coffee grounds and tea.