Searching We.Love.Privacy.Club

Twts matching #bugs
Sort by: Newest, Oldest, Most Relevant

MacOS Tahoe 26.0.1 Update Released to Fix Mac Studio Installation Bug
Apple has issued MacOS Tahoe 26.0.1 as a software update for Tahoe users. The update focuses primarly on resolving an issue for Mac Studio owners who were not able to install the initial MacOS Tahoe 26 release onto the M3 Ultra version of the Studio. Apparently other bug fixes and security improvements are included as … [Read More](https://osxdaily.com/2025/09/29/macos-tahoe-26-0-1-update-releas … ⌘ Read more

⤋ Read More

iOS 26.0.1 Update Released to Fix Various iPhone 17 Issues, & Blank Screen Icons
Apple has released the first update for iOS 26.0.1, which includes a handful of bug fixes specifically aimed at the new iPhone 17 lineup, as well as addressing an issue for all devices where Home Screen icons can appear blank after using various Liquid Glass customization settings, and another issue where VoiceOver might disable itself … [Read More](https://osxdaily.com/2 … ⌘ Read more

⤋ Read More

DietPi September 2025 Update Brings Faster Backups and Roon Server Early Access
The September 20th release of DietPi v9.17 introduces smaller and more efficient system images, faster backups with reduced disk usage, and a new toggle for Roon Server’s early access builds. The update also addresses SPI bootloader flashing issues on Rockchip devices, improves Raspberry Pi sound card handling, and includes multiple bug fixes across tools and […] ⌘ Read more

⤋ Read More

Kicking off Cybersecurity Awareness Month 2025: Researcher spotlights and enhanced incentives
For this year’s Cybersecurity Awareness Month, GitHub’s Bug Bounty team is excited to offer some additional incentives to security researchers!

The post [Kicking off Cybersecurity Awareness Month 2025: Researcher spotlights and enhanced incentives](https://github.blog/security/vulnerability-research/kicking-off-cybersecurity-aware … ⌘ Read more

⤋ Read More

Ignite Realtime Blog: Openfire 5.0.2 release!
The IgniteRealtime community is happy to announce a new release of its open source, real-time communications server server Openfire! Version 5.0.2 brings a number of stability improvements and bug fixes.

Notably, it addresses a recently identified security vulnerability, identifies as CVE-2025-59154. The issue allows for potential identity spoofing via unsafe Common Nam … ⌘ Read more

⤋ Read More
In-reply-to » (#z25erwq) @lyse a content warning is kind of like a forum spoiler cut, or like the <details> tag in HTML; it lets you write a sentence or so that someone can then click to expand to see the actual post. it's called a CW because most people use it to warn for potentially triggering/harmful subjects, but you can really use it for anything, like spoilers in a TV show or even for joke punchlines

@kat@yarn.girlonthemoon.xyz Ta. The only good use for <details> is to collapse long logs in bug analysis reports. Other than that, I find it rather annoying to expand sections manually.

As for spoilers, personally, I don’t care at all. Not the slightest bit. If there is something that I don’t wanna read, I just stop reading. ¯_(ツ)_/¯

But I’ve got the feeling that I’ve got an unpopular opinion on that matter. ;-)

⤋ Read More

Mathieu Pasquet: slixmpp v1.11
This new version includes a few new XEP plugins as well as fixes, notably
for some leftover issues in our rust JID code, as well as one for a bug that
caused issues in Home Assistant.

Thanks to everyone who contributed with code, issues, suggestions, and reviews!

CI and build

Nicoco put in a lot of work in order to get all possible wheels built in CI. We now have manylinux and musl builds of everything doable within codeberg,
published to the codeberg pypi repo, and published on pypi. … ⌘ Read more

⤋ Read More
In-reply-to » @itsericwoodward Also just a heads up, GIF(s) aren't supproted as an Avatar type on yarnd (what runs twtxt.net). I'd change this to something that's more supproted like PNG, JPEG, etc.

@eric@itsericwoodward.com Name change is no worries! 😉 Interesting/funnily enough my client yarnd seems to have picked it up automatically which is nice (I’ve historically always had a few bugs to iron out there 🤣)

⤋ Read More
In-reply-to » Twtxt as a network is so neat. Sucks it isn't more widely adopted ): I feel like it'd be way easier to host than say, mastodon or GTS. & would require WAYYYY less resources. Not a diss on GTS, I love GTS , just saying because it's text files, I assume the minimum amount of ram needed to host any of the twtxt server software is very low.

@lyse@lyse.isobeef.org you will have to agree, though, that Yarn has contributed to make it possible to mass adopt (with its many glitches, bugs, and all) because, still, the web is king.

⤋ Read More

Just realized: One of the reasons why I don’t like “flat UIs” is that they look broken to me. Like the program has a bug, missing pixmaps or whatever.

Take this for example:

https://movq.de/v/8822afccf0/a.png

I’m talking about this area specifically:

https://movq.de/v/8822afccf0/a%2Dhigh.png

One UI element ends and the other one begins – no “transition” between them.

The style of old UIs like these two is deeply ingrained into my brain:

https://movq.de/v/8822afccf0/b.png
https://movq.de/v/8822afccf0/c.png

When all these little elements (borders, handles, even just simple lines, …) are no longer present, then the program looks buggy and broken to me. And I’m not sure if I’ll ever be able to un-learn that.

⤋ Read More

Saw this on Mastodon:

https://racingbunny.com/@mookie/114718466149264471

18 rules of Software Engineering

  1. You will regret complexity when on-call
  2. Stop falling in love with your own code
  3. Everything is a trade-off. There’s no “best” 3. Every line of code you write is a liability 4. Document your decisions and designs
  4. Everyone hates code they didn’t write
  5. Don’t use unnecessary dependencies
  6. Coding standards prevent arguments
  7. Write meaningful commit messages
  8. Don’t ever stop learning new things
  9. Code reviews spread knowledge
  10. Always build for maintainability
  11. Ask for help when you’re stuck
  12. Fix root causes, not symptoms
  13. Software is never completed
  14. Estimates are not promises
  15. Ship early, iterate often
  16. Keep. It. Simple.

Solid list, even though 14 is up for debate in my opinion: Software can be completed. You have a use case / problem, you solve that problem, done. Your software is completed now. There might still be bugs and they should be fixed – but this doesn’t “add” to the program. Don’t use “software is never done” as an excuse to keep adding and adding stuff to your code.

⤋ Read More

OpenBSD has the wonderful pledge() and unveil() syscalls:

https://www.youtube.com/watch?v=bXO6nelFt-E

Not only are they super useful (the program itself can drop privileges – like, it can initialize itself, read some files, whatever, and then tell the kernel that it will never do anything like that again; if it does, e.g. by being exploited through a bug, it gets killed by the kernel), but they are also extremely easy to use.

Imagine a server program with a connected socket in file descriptor 0. Before reading any data from the client, the program can do this:

unveil("/var/www/whatever", "r");
unveil(NULL, NULL);
pledge("stdio rpath", NULL);

Done. It’s now limited to reading files from that directory, communicating with the existing socket, stuff like that. But it cannot ever read any other files or exec() into something else.

I can’t wait for the day when we have something like this on Linux. There have been some attempts, but it’s not that easy. And it’s certainly not mainstream, yet.

I need to have a closer look at Linux’s Landlock soon (“soon”), but this is considerably more complicated than pledge()/unveil():

https://landlock.io/

⤋ Read More
In-reply-to » So I was using this function in Rust:

@lyse@lyse.isobeef.org Rust is so different and, at the same time, so complex – it’s not far fetched to assume that I simply don’t understand what’s going on here. The docs appear to be clear, but alas … is it a bugs in the docs? Is it a lack of experience on my part? Who knows.

By the way, looks like there was a bit of a discussion regarding that name:

https://github.com/rust-lang/rust/issues/120048

⤋ Read More

Hmmm 🧐 Not what I thought was going on… No bug…

 time="2025-06-14T15:24:25Z" level=info msg="updating feeds for 8 users"
 time="2025-06-14T15:24:25Z" level=info msg="skipping 0 inactive users"
 time="2025-06-14T15:24:25Z" level=info msg="skipping 0 subscribed feeds"
 time="2025-06-14T15:24:25Z" level=info msg="updating 80 sources (stale feeds)"

⤋ Read More

How can one write blazing fast yet useful compilers (for lazy pure functional languages)?
I’ve decided enough is enough and I want to write my own compiler (seems I caught a bug and lobste.rs is definitely not discouraging it). The language I have in mind is a basic (lazy?) statically-typed pure functional programming language with do notation and records (i.e. mostly Haskell-lite).

I have other ideas I’d like to explore as well, but mainly, I want the compiler to be so fast (w/ optimisations) that … ⌘ Read more

⤋ Read More