Agree. For clarity, the circuits that show the low-voltage status are much less hungry for current than the circuits that measure weight. So no, having enough battery to report low voltage does not imply that there is enough to make an accurate weight measurement.

When you come across some Python code for something written 5 years ago and they used four contributed packages that the programmers have changed the API on three times since then, you want to set up a virtual environment that contains those specific versions so you can at least see how it worked at that time. A small part of this headache comes from Python itself mutating, but the bulk of the problem is the imported user-contributed packages that multiply the functionality of Python.

To be sure, it would be nice if those programmers were all dedicated to updating their code, but with hundreds of thousands of packages that could be imported written by volunteers, you can’t afford to expect all of them them to stop innovating or even to continue maintaining past projects for your benefit.

If you have the itch to fix something old so it works in the latest versions of everything, you have that option… but it is really hard to do that if you cannot see it working as it was designed to work when it was built.

I would say you are lucky. I lived in my college town for 20years and it started out chock full of co-ops in the 80s and by the time I moved away they were all hardly recognizable or gone. Food co-ops, housing co-ops, internet co-ops… all mutated away from shared labor or were replaced by sole ownerships.

My wife works for an employee-owned engineering company, but they are anything but FOSS in their culture.

I hope these intermediate management structures that combine expertise and collective ownership grow more. But it still isn’t a slam-dunk that should be assumed to be the stupidly-obvious approach unless such organizations compete with the grifters… and then their success won’t be due to the fact that they are using FOSS but that they present a track record of success as an organization.

… and there are a gazillion examples where no community forms and the founder burns out. Cheers where it works, but some projects aren’t sexy enough to attract a self-sustaining community, and when you don’t preselect success stories but choose according to external needs that hit-and-miss experience starts to look less obvious and more like the thing only “smart” people can succeed at.

My objection is to the idea that FOSS is easy… it does require some smarts to succeed with.

Don’t get me wrong… I am all for FOSS and I avoid walled gardens, but people have a hard time remembering to take the trash out to the street on the right day. Spending time driving garbage trucks monthly in the local waste management Co-op is not going to fly well. That problem gets solved using money… homeowners are taxed and the local government either hires garbagepeoples directly, or more often they hire a company that takes care of the problem.

Upshot there is money rather than co-op ownership, and frequently for-profit contractors win the day over government ownership. Contractors supply GaaS, we just have to get the bin to the street. So the equivalency here is the need for the public institution known as city government to retain ownership of the waste management system. Not quite “the people”, since getting co-op volunteers is, well, erratic at best. And there are a ridiculous number of people out there who are vehemently against government management of actual organizations like this. I am for it, but over and over I see “privatization” win elections.

So I am not seeing how pitching this as “stupidly obvious” will win when “obvious” means hiring a contractor nearly every time.

Yes, this was an appropriate response. I hate people who wave guns around like they are toys.

Using sudo when it isn’t necessary, and the real cannon: sudo su… Adding sudo to your command lines indiscriminately causes files you create to be owned by root even though they are in your home directory, and then you end up using sudo to make changes to the files… and then the filesystem permissions cannot prevent you from successfully running an accidental “sudo rm -rf /” command.

Seriously… sudo is not a “habit” to develop in order to avoid dealing with filesystem permissions problems.

Noob question?

You do seem confused though… Debian is both a distribution and a packaging system… the Debian Stable distribution takes a very conservative approach to updating packages, while Debian Sid (unstable) is more up-to-date while being more likely to break. While individual packages may be more stable when fully-updated, other packages that depend on them generally lag and “break” as they need updating to be able to adapt to underlying changes.

But the whole reason debian-based distros exist is because some people think they can strike a better balance between newness and stability. But it turns out that there is no optimal balance that satifies everyone.

Mint is a fine distro… but if you don’t like it, that is fine for you too. The only objection I have to your objection is that you seem to be throwing the baby out with the bathwater… the debian packaging system is very robust and is not intrinsically unlikely to be updated.

While I can understand you wanting autosave on in your situation, I much prefer autosave off because I often open files to see what is in them and do not want to automatically modify them just because I accidentally hit a key and delete it. Automatically changing stuff is a choice you should have to make, not a feature that I have to race to disable.

… which is why you also need to join the samba group.

Samba is a pipe of sorts… those settings only apply to files created using that pipe.

SSH is a different pipe, with different configuration. I think you need to modify the umask of the user connecting via ssh and/or add them to a samba group.

Did you check ownership and permissions for .profile?