The server sidebar has an uptime stat. Could also have a simple monthly costs covered percent stat.

hard to compete against sunshine

I’m using Sunshine and Moonlight to stream my PC to my TV too

German-based SUSE just extended long-term support for Linux Enterprise 15 until July 2037. […] 13 years from now […] that’s […] 19 years after 2018, which is when Linux Enterprise 15 was first released.

pretty good

Time to migrate to Funnertoo

I haven’t seen information on that. Only speculations in comments here on Lemmy. I didn’t and don’t follow SUSE or this news closely though.

A commenter mentioned how SUSE has core business in hosting and business environment, while OpenSUSE userbase is more desktop and [non-paying?] end-user.

There wasn’t (to me anyway) strong arguments for why they do. Maybe they just want to get rid of the investment, and don’t see enough gain in the good publicity and it as an entry point to them anymore.

After years of support and collaboration, SUSE asked OpenSUSE to drop “SUSE” - their [SUSE] branding - from their [OpneSUSE] name.

a sus linux? count me in!

its goal is to be more user-accessible than NixOS

How does it attempt to do that? I assume it doesn’t change Nix. Does it hide the configuration behind GUIs?

I see you’re using your wife as a test user for yourself. Smart.

“We value your privacy”

yeah, no, very obviously you don’t

I promise I won’t go more into the tech bits meant for developers 😅

Checks if they’re still on/coming from programming.dev

This is not a supply chain attack, it is sudden extreme enshitification. according to the article, the attacker also bought the GitHub repo

I don’t see how buying the GitHub repo as well makes it not a supply chain attack but enshitification.

They bought into the supply chain. It’s a supply chain attack.

When something hits you in the face you turn blue. This essentially hits you in the face, and matches that color.

I don’t have multi-user library maintenance experience in particular, but

I think a library with multiple users has to have a particular consideration for them.

1. Make changes in a well-documented and obvious way
   1. Each release has a list of categorized changes (and if the lib has multiple concerns or sections, preferably sectioned by them too)
   2. Each release follows semantic versioning - break existing APIs (specifically obsoletion) only on major
   3. Preferably mark obsoletion one feature or major release before a removal release
   4. Consider timing of feature / major version releases so there’s plannable time frames for users
2. For internal company use, I would consider users close and small-number enough to think about direct feedback channels of needs and concerns and upgrade support (and maybe even pushing for them [at times])

I think “keeping all users in sync” is a hard ask that will likely cause conflict and frustration (on both sides). I don’t know your company or project landscape though. Just as a general, most common expectation.

So between your two alternatives, I guess it’s more of point 1? I don’t think it should be “rapidly develop” though. I’m more thinking doing mindful “isolated” lib development with feedback channels, somewhat predictable planning, and documented release/upgrade changes.

If you’re not doing mindful thorough release management, the “saved” effort will likely land elsewhere, and may very well be much higher.

Ubuntu LTS.

It has the option for PPAs when the distro doesn’t offer packages or recent package updates but the upstream project does.

It’s a well-established and stable distro.

costumer

of holding the hammer?

When you copy a file onto the Void, does it disappear?

https://nobaraproject.org/

The Nobara Project, to put it simply, is a modified version of Fedora Linux with user-friendly fixes added to it. Fedora is a very good workstation OS, however, anything involving any kind of 3rd party or proprietary packages is usually absent from a fresh install. A typical point and click user can often struggle with how to get a lot of things working beyond the basic browser and office documents that come with the OS without having to take extra time to search documentation. Some of the important things that are missing from Fedora, especially with regards to gaming include WINE dependencies, obs-studio, 3rd party codec packages such as those for gstreamer, 3rd party drivers such as NVIDIA drivers, and even small package fixes here and there.

Depends on what I want or need to “understand”.

I’ve worked for many years on a project (it’s a whole project ecosystem tbh with multiple projects; desktop winforms app, server app, SQL server, asp.net MVC app, asp.net blazor app, mobile wpf app, sync service app). On the main project (client + server) I haven’t visited one major area, and another I confidently know that it’s not understandable to me without specific deep effort.

I recently had to work on the latter. I take a localized approach. Explore what I have to do, without opening the full scoped understanding that’d lead me to architecture refacs. I write out the method call stacks to get an overview of who calls what when. To then know what I have to inspect and analyze further.

I take notes where necessary, or improve and comment code where appropriate for better understanding and obviousness.

I create documentation - about concepts and architecture as appropriate and necessary.

Code should be obvious and intuitive. Concept docs should document the broader concepts.

When those concept docs exist, those are what you look at to understand app intention and behavior. And it should give you an introduction to architecture. From there, exploring the code should be self-explanatory (but may require specific, repeated, and iterative analysis). And I take notes about what’s relevant and I need for understanding or task.

Afterwards, those notes should have, or should then integrate into the code base or docs, or be determined irrelevant for that. If I had to write them out and down, it’s more likely they should be part of something than not.