Mordikan

I’ve been looking for a new book server and discovered Booklore/Grimmory as well. Here is the history I can find on it as some of what people are saying is not 100% correct.

1. It was not vibe-coded. The original project predates genAI, so that wouldn’t have been since. I think some of the newer code might be, but the core seems unchanged.

2. The security issue mentioned is an API authentication bypass whereby book files were exposed if the endpoint was reachable (CVE-2025-62614). This has an 8.7 rating on severity, but realistically the end result is your books could be copied.

3. Licensing. This is the real skullduggery in my opinion. The maintainer had plans to switch from AGPL-3.0 to BSL. That might not be legal and it cuts out any contributors and sets the project up for monetization.

My concern with Grimmory is that it is too embedded with the flaws of Booklore. In testing it was really sluggish on mobile. I still need to do more testing, but aside from being graphically nice, it didn’t feel that stable. I was hoping to move away from Calibre-Web due to auto-importing not being supported, but in the end, I’ll likely just write something to support this on my end.

The problem with religious texts is they are so badly written that essentially anything you want to do is permissible. Look at a comment you made:

The basics argument is taking anything from anyone without their consent is morally wrong and haram.

Who did take from? You couldn’t have taken a game from a developer/publisher if its pirated. You took it from a bittorrent seeder. Did they provide consent? Yes, they were seeding it to you.

If I tell you a joke that I heard from someone who heard it from someone, etc. did I steal the joke? At what iteration of copying something does it stop being theft? Is it theft to begin with to make a copy?

This is the definition of a zero effort post.

You don’t want to put forth the effort to bug hunt, you want an AI agent to bug hunt for you. You don’t want to learn to even setup the agent, you want other people to explain step by step how to do that for you.

I’m assuming you aren’t even going to review before it submits. Honestly though, how would you review it given you don’t know anything about the topic its submitting on.

No, that’s not how the new EU legislation works. The new laws build off existing Digital Services Act (DSA) and legacy E-Commerce Directive (2000/31/EC) requirements. The DSA states again that you would have to lock down access to the material (once you become aware) and then inform authorities.

All site operators maintain safe harbor with EU authorities unless those two points are broken. In both US and EU pending legislation, no requirement to scan all STLs is required, so you do not have to automatically check all files like you mentioned.

I wouldn’t let that be a deterrent to starting an instance. Just make sure you understand the obligations you have as site owner when it comes to misuse. Maintain good logging and follow legal requirements (which in the US is locking down and preserving evidence and reporting to law enforcement hotlines - depending on the nature of the misuse).

Its the Chilling Effect. Fear of breaking a law (even if that law ends up not being applicable to you) is enough to scare people into complying with it. I’ve seen companies worry about GDPR that have no presence in the EU. Yes, the EU could still fine them, but they wouldn’t have to actually pay or even acknowledge it.

And how exactly would that be breaking the law?

Systemd isn’t an operating system provider and has no legal obligation to make any change.

I’ve used Arch for about 16yrs now. The documentation is probably the absolute best you’ll find. It covers everything and I’ve never had a need to ask any question in their forums.

Arch forums are basically radicalized linux users who before answering will give you a post-graduate level dissertation on why you suck as a human being.

But yeah! One of the best distros out there!

NOTE: I would avoid anything that’s “stable” in linux for beginners. A lot of the OS is learned through repetition. Having things break is how we learn to fix them. Nothing wrong with completely borking a system and having to reload it. When you get to things like NixOS, you get practically indestructible OSes that you can just set and forget. Aside from the different way NixOS approaches configuration, if you don’t already know it, you aren’t going to learn it.

I think the supply chain issue is probably the most pressing out of all of them. The other points people have are either non-issues or a result of dropping usage hogs into existing electrical infrastructure. Infrastructure can be updated, though.

Supply chain is different. There isn’t a supply shortage of chips, its that profitability dictates you should sell them to datacenters or adjacent industry. Unlike infrastructure where you can just build out more, adding more supply for chips just means you have more to sell to datacenters. Since the demand is there, end of day profits will always win.

Saw it was already commented about CO2, so I thought I’d counter-point your environment claim regarding water usage (since that is something I’ve seen a lot of too).

The ISSA had a call to action due to the AI water use “crisis”: https://www.issa.com/industry-news/ai-data-center-water-consumption-is-creating-an-unprecedented-crisis-in-the-united-states/

68 billion gallons of water by 2028! That’s a lot…right? Well, what I found is that this is somewhat of a bad faith argument. 68 billion gallons annually is a lot for one town, but those are numbers from a national level and it isn’t compared to usage from anything else. So, lets look at US agriculture (that’s something that’s tracked very well by the USDA): https://www.nass.usda.gov/Publications/Highlights/2024/Census22_HL_Irrigation_4.pdf

That’s 26.4 trillion gallons of water annually. So, AI datacenter represents 0.26% of agriculture consumption. If AI datacenter consumption is a crisis, why is agriculture consumption not a crisis? You could argue that agriculture produces “something useful”, but usefulness doesn’t factor into the scarcity of a resource. So, either its not a crisis, or you are cherry picking something that has no meaningful outcome to solving the problem.

We aren’t talking about publishing side groups like Youtube, FB, etc. We’re talking about advertisers like DV360 or Tradedesk (the largest ad firms). COPPA has vastly decreased value on the demand side. And user data isn’t stored for 20+ years expecting to capitalize on it. After several weeks that data becomes stale and useless. In the 11 years I’ve worked in adtech engineering, I can confirm that how you think this works vs how this actually works is not the same thing.

And what you are talking about for responsibility is part of the Section 230 amendments being made to force liability on hosts for the “sake of the children”. These amendments have nothing to do with children though. They have to do with opening hosts up to liability in defamation suits raised against them to force silence of political critics (this has been WELL documented).

I totally get what you are saying, and I don’t think we are really in disagreement about anything here. This is just my personal point of contention.

Its opening a can of worms for xdg-desktop-portal and systemd for something that they don’t need to or shouldn’t need to act on. If they make this change then: If the Afghani govt issues a request for gender, they should include that in userDB as well then. If Colorado’s new law requires age data to be held differently or different format, they will need to include that as well then. COPPA already exists, so do they need to further change how they store this data? If a new federal law is passed for age verification, they will need to support that on top of the existing state laws. Should it be jurisdiction specific? EU laws might state you can’t arbitrarily store this data, so now you need to check operating geo. Which jurisdictions do you honor? Which do you ignore?

Its optional until made so convoluted that its required. I think what’s so interesting to me is how this all goes back to a 30+ year old debate on the UNIX philosophy.

Collecting data on kids is extremely valuable to these companies, because kids grow up to be consumers.

This is not true. From an adtech perspective, child user data is virtually worthless. Because COPPA exists, most demand platforms (including those outside COPPA jurisdiction) simply will not issue any bid for that type of traffic. To try to bypass this, sketchy publisher groups will try to issue a regs.coppa=0 in their bid requests with the justification of “we couldn’t determine that info”. COPPA is largely self-reporting based if you didn’t know.

Outside of that, what you are describing is called the Chilling Effect. It is were legitimate activities on a site are restricted out of fear that they may break a vaguely worded law. This is a genuine concern and one that federated services had when Lemmy first started to take off. Instance owners were faced with the possibility that without CSAM detection processes in place that they could be held liable for that material being present on their instance.

I think the issue outside of capitulation is the matter of systemd’s obligation or lack thereof to make this change. Systemd by law isn’t required to do anything. xdg-desktop-portal more so is, but that raises a bigger question: Why is a jurisdiction specific requirement being rolled into this? Do all jurisdiction specific requirements need to be loaded for optional use? Why is this being shunted to xdg-desktop-portal to handle the brunt of this?

Ultimately the PR was closed and for this very reason:

That amounts to a short-sighted decision to tune the specification to one state’s law, without taking into account that other states and countries can define different age brackets, and without the ability for an application to know which age bracket classification (California, Japan if/when they mandate it, etc.) applies.

Expanding on that, the outright shortsightedness of the request is made more clear further into that discussion: https://github.com/systemd/systemd/issues/40974#issuecomment-4018655808

>Gender plays a role on whether you could use a computer and what sites you can access?

In Afghanistan, all forms of higher education are not permitted for women. Furthermore, the Taliban have a reputation as gentlemen who are not used to repeating themselves.

Define “location data”.

Systemd stores location data for unit files, it does not store geo lookup data. Again, why does systemd need to store user age?

I think the point people are making here is why does systemd need to store an age for the user.

An equally valid question is why does a glorified scheduling service want to act as my UEFI boot manager?

bchunk can do conversion to build these all out as .iso files. I think cdemu, given your mention of Daemon Tools, is a better option though as its effectively doing the same thing DT did. It would load the image to /dev/sr0 (the CD/DVD device) which you would then just run the previous mount command to bring up: sudo mount /dev/sr0 /mnt/cd

I think you mean MDF/MDS instead of MKV (I haven’t seen those in like 20 years - but I think that’s what you mean). That was the old Alcohol 120% proprietary format. I don’t think any tools directly work with that extension, you’d have to convert those .iso first.

If the .img file does not contain partition table info, it should just be a matter of mounting:

sudo mkdir -p /mnt/img
sudo mount -o loop path/to/file.img /mnt/img

The only time that becomes a problem normally is if its like a partitioned SD card (had a netbook I booted from SD card before and that happened).

Turkish DNS is really an interesting thing. Awhile back, the govt hijacked Google’s DNS service via bogus BGP routes so they could block/censor traffic. They then also started directing DNS queries away from the EU and pushing those to APAC.

Not sure what the sites are or what they resolve to on your end, but you might try using openssl to see if its a bad cipher or outdated cert maybe: openssl s_client -connect domain.com:443 -ciphersuites TLS_AES_128_GCM_SHA256 -tls1_3