Not just flatpaks, same with .deb and .rpm, bloat files. Actually, all packaged binaries suck too, they’re unoptimized. The only decent solution is to compile every binary yourself. Actually, that’s a waste and sucks because what if the developer didn’t code with the oversight of god himself? So we should write the software ourselves in C, because Rust is bloat. But wait, then we’re using a premade compiler, so we just need to write raw x86 machine code (only a bad dev needs 64 bit registers).

Actually, x86 has too many instructions that are pointless which complicates the architecture of the CPU. Do we even need a CPU? What’s the point of half of this system anyway? I don’t need a computer to do the math. I can do it myself. I don’t need programs.

Wait, but even just myself has bloat. You’re telling me that 15-20% of my body is just wasted energy, never to be used? Need to get that down to 0℅. What’s the point of 2 lungs when I can function with 1? Two kidneys? Eyes? Ears? Why do we have duplicates when one works just fine? What’s the point of an appendix or a gallbladder?

Well, it seems that even the human body alone isn’t a bloat free native replacement. So it’s time to ascend beyond the mortal flesh. But even then, we’re confined to 3 dimensions. Stupid sandbox, what’s the point?

Unfortunately I can’t think of any further solutions so it looks like for now I’m gonna be stuck with the oh so terrible flat pack

I put closer to what I actually changed in each patch note now, I used to pick and choose a lot

Well the IPv4 spec only allows 4 octets, so having 5 or more is impossible. We could fix it by changing the protocol, but at that point it’s more worth it to just migrate to IPv6.

As in a regex or …?

An ipv4 parser would also be sorta difficult.

you have to account for the fact that all the octets can be added to decimal: http://2130706433 (valid 127.0.0.1)

or the fact that octets can be in different formats: http://0x7F.0x0.0x0.0x1 (127.0.0.1)

or the fact that you can mix octet formats: http://0xC0.0250.0.1 (192.168.0.1)

I looked at threativore’s REST API, and it raised a question about how the flairs should be displayed.

Were user flairs intended to be displayed inline in a comment section next to their username? Or if you specifically visit their profile? I ask this because there’s only an API endpoint to get details regarding a single user, which would require dozens of API calls for a single comment section or post feed.

I generally try to make photon depend as little as possible on external APIs, especially specific ones.

However, I was thinking of a system to let instance admins choose for themselves if they want their hosting of photon to have it, perhaps through a “plugin” system. I could add a threativore/fediseer plugin that you could specify configuration to.

I probably wouldn’t add it on my phtn.app, but I can add “plugins” so that you could use it on lemmy.dbzer0.com.

I’m still updating this daily, I’ll get that in there soon. I only made the “stable” 2.0 release now because I wanted to get all the instances using the ancient v1.34 up to date

I’m really sorry about that, I used a different script to generate the translation reports for this release note than the credits page in the app. The first one only took the top 1 translator, and then I filled what I thought I missed.

I edited the post. Translation is a great dedication of time and I apologize for not recognizing the time you put.

Just change the image version. It should work as normal:

image: ghcr.io/xyphyn/photon:v2.0.0 # preferably use latest

or from the shell

docker run ghcr.io/xyphyn/photon:v2.0.0

I prefer details since it’s easier for me to scan visually, with my eyes only having to go straight down, to find either a name, date, or size. Sorting I also find more intuitive. However, I prefer icon view for my pictures and videos folders

I changed it to just use your browser background now.

deleted by creator

The current version of Photon uses the inline reply style, so this is fixed

deleted by creator

deleted by creator

distinguished

deleted by creator

deleted by creator

deleted by creator