Pika

yea but it’s still a valid key! the opsec part of me is dying atm.

out of all the censored things, they didn’t think to censor a product key before declassifying it. I wish I could say I was surprised.

most software shouldn’t require admin to install tbh, like I install all my stuff to ~/.local/opt and ~/.local/bin and it works fine generally as long as it doesn’t need root for something. I do agree flatpak is nice for things that might need an isolated environment though, but for most of my stuff a local user based install works fine

mmm yes, I too like duplicated dependancies in the push for a unified distro.

Realistically that’s my only complaint about flatpak. I have 7 or 8 flatpaks installed on my system, and I think 4 seperate gnome environments installed as dependancies to them. It’s so bloaty

Makes sense, since the go to for github issues is opening an issue, using a non-standard way needs communication visible for people who try to do it the standard way. This allows for them to click issues, see the pinned issue of “Why users can’t create issues” and move to discussions.

this seems to be an easy solution for them tbh. Change focus away from banning or providing alternatives, and focus more on dissuasion. allow the service but have a carbon tax placed on those types of heat systems. People find alternative when services are expensive to operate. Could even avoid having it phrased as a customer tax by giving it to the company, and then when it’s passed down its a “well it’s a buisness tax that they passed down, complain to the company”

Like it sounds like the main issue in this at the moment is utility companies saying that you need to have customers want those type of services, You need to make it so customers no longer want those type of services, which generally means increase the price for those services. Focus on removing existing infrastructure when demand for said services are no longer present. You can try having alternatives installed as well, but a straight out ban, like what seem to be talking about there, I don’t think should be done.

I’ve never rebuilt a container, but I also don’t have any containers that are deprecated status either. I swap off to alternatives when a project hits deprecation or abandonware status.

My only deprecated container I currently have is filebrowser, I’m still seeking alternatives and have been for awhile now but strangely enough it doesn’t seem there are many web UI file management containers.

As such though ever since I learned that the project was abandoned on life support(the maintainer has said they are doing security patches only, and that while they are doing more on the project currently, that could change), the container remains off, only activating it when i need to use it.

oh for sure, it made sense that they wanted to make sure was fixed. Just was super alarming the speed it was advertised that the relay was there!

reminds me of my first mail server, accidentally set up an open relay and got a lot of abuse reports from mail providers saying they blocked my server due to it. Took forever to get fixed again.

I’m in this picture and I don’t like it.

I think i have about 6 side projects I have “on hold” because something more new came up and I never got back to them. I even had a full on chat site that had a functional design, even had a domain for it, then I got bored and moved onto something else.

fully agree, mine isnt accessible to the outside world either but, you never know if something gets missed or somehow a path gets made. would rather not open up that risk

Sadly no recommendations, I still use portainer myself

while docker does have a non-root installer, the default installer for docker is docker as root, containers as non-root, but since in order to manage docker as a whole it would need access to the socket, if docker has root the container by extension has root.

Even so, if docker was installed in a root-less environment then a compromised manager container would still compromise everything on that docker system, as a core requirement for these types of containers are access to the docker socket which still isn’t great but is still better than full root access.

To answer the question: No it doesn’t require it to function, but the default configuration is root, and even in rootless environment a compromise of the management container that is meant to control other containers will result in full compromise of the docker environment.

man, arcane looks amazing, I ended up deciding off it though as their pull requests look like they use copilot for a lot of code for new features. Not that I personally have an issue with this but, I’ve seen enough issues where copilot or various AI agents add security vulnerabilities by mistake and they aren’t caught, so I would rather stray away from those types of projects at least until that issue becomes less common/frequent.

For something as detrimental as a management console to a program that runs as root on most systems, and would provide access to potentially high secure locations, I would not want such a program having security vulnerabilities.

Not only that, theres also an increasing number of anticheat’s that supports linux, however they have it intentionally disabled so when you run the game it either blocks you or in worse case bans your account as a whole

you arent the only one. I had suck a painful onboarding process with next cloud from the docker setup to the speed of it to the UI that I just gave up and decided to use a combination of immich and syncthing instead.

honestly this seems to be a reoccurring trait.

1. X endorses or sets a climate goal
2. X teeters around kind of focusing towards it
3. X slowly starts rescinding commitments or statements
4. X decides goal is not a feasible goal and pushes it back another 5-10 years

this entire thing has made me really rethink whether I want to swap to the new repo or not.

Why was there no communication about it. The gplay repo maintainer wasn’t informed of anything, no public notice to anyone was given, just a transfer of the repo and a status issue here explaining it.

Obviously the act is genuine as they were able to keep the original keys but like, this entire system seemed really sketchy.

I’m also not happy with the fact that it seems the first thing they added was removing checksums, but that might be a temp thing.

I also just noticed that it looks like they removed the entire public key for it, which if they had the original private keys using the existing public keys shouldn’t be an issue right?

One of my drives crippled itself a few days back, not sure what caused it. Wasn’t able to be resolved without a host restart which was unfortunate. SMART isn’t failing and has been working fine, so I’m chalking it down to a weird Proxmox bug or something.

For sure expected I was going to need to do a rollback on an entire drive after that restart though. Still may have to if it reoccurs.

I have Proxmox Backup Server backing up to an external drive nightly, and then about every 2 or 3 weeks also backup to a cold storage which I store offsite. (this is bad practice I know but I have enough redundancies in place of personal data that I’m ok with it).

For critical info like my personal data I have a sync-thing that is syncing to 3 devices, so for personal info I have roughly 4 copies(across different devices) + the PBS + potentially dated offsite.