I didn’t understand what you meant by Joplin not being “fully FOSS”, so I went looking for the license. Is really quite strange. Basically they’ve used a “personal license” for some parts and the AGPL for the rest. That’s… annoying.

Every now and then I need to make a presentation, and LibreOffice Impress to Microsoft PowerPoint isn’t that good. I resort to Google Slides for now.

It may not be your thing, but personally I’ve had a lot of success with RevealJS. You just write HTML (or even Markdown) and it automatically builds your slides for you such that they run on any browser. You can make it as complicated or as simple as you like (I’ve done some wild stuff with CSS) and everything can be versioned in git and published to anywhere that supports static files.

Here’s a reasonably professional-looking presentation I occasionally give about Kubernetes if you’re interested.

Are you using GNOME? If so, I remember there being an extension for that.

You might like Krita a little more. It’s far more powerful than Paint, but its interface is very familiar.

If the work is a “clean room” reverse engineering job, as in: you didn’t read the original source to produce your version but rather looked at the input and output and wrote new software that had the same behaviour, the this new software is not a derivative work and you can use whatever license you like.

The easy option is public domain, which effectively is a “this belongs to everyone” thing. There’s not much of a practical difference between this or MIT in my understanding.

Another option would be something that preserves the freedoms you attach to the software like the GPL or LGPL if youre feeling less aggressive. These licences compel would-be modifiers to share their changes with everyone else, preventing (for example) companies that want to build their business on top of your work and then charging you for it.

But basically, if you wrote it without referencing the original, it’s your work and you can do as you like. If you were referencing the original source though, then that’s a derivative work and you may be in violation of the copyright holder’s rights.

I would be less concerned about the GPU driver and more about the entire distro. Like most distros, Ubuntu has a release cycle where versions of everything are deprecated over time in favour of newer ones, and to expect that the entire OS will be fully supported in 10 years may be asking a bit much (I’m not sure if even their LTS release goes that far).

On top of that, Ubuntu could go bankrupt or get bought out, or simply enshittify (more than it already has) in that time. Expecting Ubuntu specifically to be supported on your laptop in ten years is anyone’s guess.

However, what you can be reasonably sure of is that Linux will continue to support your system, GPU and all, for a very long time. I heard a kernel developer once say that due to the kernel’s modular design, there’s support in there for stuff just one or two people in the whole world use.

As someone else has already pointed out, FOSS support for hardware generally gets better over time, and a GTX video card is ubiquitous. There’s going to be a hell of a lot of those floating around on laptops, servers, and homelabs for a lot more than ten years.

You just might not be able to stick with Ubuntu. The older the hardware, the more you might have to lean toward the more technical distros that make it easy to customise the kernel or that favour old hardware. I like Gentoo for this job, but even Ubuntu or Debian have paths to do compile your own kernel for example.

I think it looks nice.

Or, https://justuse.org/curl/

Buy two 4tb extern drives. Copy your photos onto both. Leave on at your mom’s house in a closet. Leave the other in a locker at work or a safety deposit box.

No monthly fees, no techbro cloud capitalists.

Honestly, I’d buy 6 external 20tb drives and make 2 copies of your data on it (3 drives each) and then leave them somewhere-safe-but-not-at-home. If you have friends or family able to store them, that’d do, but also a safety deposit box is good.

If you want to make frequent updates to your backups, you could patch them into a Raspberry Pi and put it on Tailscale, then just rsync changes every regularly. Of course means that wherever youre storing the backup needs room for such a setup.

I often wonder why there isn’t a sort of collective backup sharing thing going on amongst self hosters. A sort of “I’ll host your backups if you host mine” sort of thing. Better than paying a cloud provider at any rate.

From a read of that issue, it looks like it never was.

The thing is, none of the suggested alternatives can do what pickle does, and the article focuses on a narrow (albeit ubiquitous) use case: serialisation of untrusted data.

There are still legitimate use cases for pickle, especially when storing, caching, or comparing objects that can’t easily be serialised with say, JSON or TOML. It’s a question of using the right thing for the right job is all, and pretending like JSON is a comparable alternative to pickle doesn’t help anyone.

This might be useful: https://ffmpeg.app/

They’re on Mastodon too if you’re looking for a fedi-friendly link: https://mastodon.social/@warandpeas

I keep seeing Zulip tossed around as an alternative, but I don’t know what’s up with their licencing. There’s also Framateam, but I think that might just be Mattermost as a service.

Matrix would be great if it wasnt so user-hostile, but it is :-(

Hooray! I actually bought a legit CD on eBay and couldn’t get it to work some years ago. I shall try again with Heroic. Thanks!

Hooray!

Has anyone managed to play “Black & White” this way? Ive tried so many ways I’m not sure I have it in me to do it again.

I’ll have a look once I’ve had a little sleep! I generally like GIS projects and am pretty solid on the Python front so maybe I can be useful.

That’s both rude and inaccurate:

“Only release every two weeks.”

No. Nowhere did I say that. In fact, the team I wrote this about worked on a 1 week sprint. And as I said, I generally prefer kanban these days, but note the date on the post: this was essentially before continuous deployment was in common use, so sprints were very common and deploys were often a manual process that had to be greenlit by management. Many companies still do something similar. It is far from “insane”.

“This includes bugfixes”

This is true. It’s is primarily because deviating from the commitment you made with the company to have x jobs done by the end of the sprint necessarily means being unable to meet that commitment. If the bug is catastrophic, you obviously have to fix it right away (this isn’t religion, use your brain), but doing so busts the sprint and that has a real cost so yes, bug fixes should be delayed when possible. What I said was to show discipline in keeping “can you just fix this?” out of the sprint because it can introduce unexpected behaviour (new bugs!) and undermine your relationship with the client and sow frustration and discontent with the team as they’re driven to context switch.

It’s much easier to say:

“We found this bug on Thursday, and a fix in the works to have it patched for the next sprint due out next week”

…than it is to say:

“We failed to have bugfix/feature/whatever done by the end of the sprint as promised because our developers were taken off-task, catering to the latest freak out session by the COO”.

“Emergencies can be dealt with immediately, but any root cause analysis or deeper work on underlying issues must wait for the next sprint.”

Absolutely. Are we here to get work done, or throw everything out the window to sit around and talk through a 6-person meeting whenever something goes wrong? You can, for example schedule a post-mortem for the next sprint when something breaks, but (a) more often than not, this can be handled in retro, and (b) if you need something bigger, then there’s no way you know everything right away anyway.

“If it can’t be done in 4 hours, it can’t be done at all.”

That’s a gross misrepresentation. What I said was that a job must be limited to roughly 4 hours of work. If that job is going to be more, then you should break it up to allow the work to be spread around.

“Don’t document things.”

I didn’t say that. What I said was that much of the time, people waste time/energy on writing documentation that is shortly out of date. What I didn’t say however is that I meant “commenting your code” here rather than “documentation”. I will die on the hill that most code comments are a waste at best, and a dangerous lie at worst, while obviously user documentation is very different and obviously important. It should however be listed as a ticketed job and therefore added to the sprint.

“Don’t write bad code. (Also: You must use classes and methods, and variable names must be words.)”

Yeah I stand by this.

“Rigid adherence to the “agile process” is required”

Yes. That’s the whole point. You be as rigid as possible (within reason, again, use your brain). Rigidity provides structure and manages expectations on both sides. Being flexible leads to a mess. I know this because I’ve been doing this for 27 years and it has been my experience everywhere.

“The job of a software developer is to crank out code and nothing else, especially not design, testing, or documentation”

It should not be a surprise that one would expect software developers to develop software. If you want design, you hire a designer. Testing is part of the process though, and I never said otherwise. Don’t be shitty. I’ve noted documentation above.

“Don’t even think about ethics.”

FUCK THIS. Don’t you dare suggest to me that I wouldn’t demand ethics of everyone I work with. You know nothing about me, or my career, or what I’ve sacrificed to stay on the right side of the moral line. Engineers have a responsibility to do right by the world they live in, and nothing I’ve mentioned in that post would suggest otherwise. This was a post about building an efficient team capable of building great things quickly and well, while keeping the client happy with the progress. Of course you should refuse to do evil on the job. That should go without saying. Your decision to pretend that I care nothing about ethics says more about you than it does me.