It’s new to me that it’s NFC. I was under the impression I need to buy a reader device to make use of digital auth or signature stuff.

When PRs begin with a headline and checklist the GitHub hover-preview becomes useless. When the PR description begins with the summation of the change, it is very useful.

Most of the time I see headlines and check lists in tickets I create or contributions I create PRs for, I feel stifled and like I have to produce something very inefficient or convoluted.

The worst I have seen is when, at work, I had to create bug tickets for a new system in a service desk to a third party, and they had a very excessive, guided, formalized submission form [for dumb users]. More than once, I wrote the exact same thing three times into three separate text boxes that required input. (Something like “describe what is wrong”, “describe what happens”, “describe how to reproduce”.) Something that I could have described well, concise, fully and correctly in one or two sentences or paragraphs became an excessively spread, formalized mess. I’m certainly not your average end user, but man that annoyed me. And the response of “we found this necessary” was certainly not for my kind of users, maybe not even experience with IT personnel.

At work, I’m glad I have a small and close enough team where I can guide colleagues and new team members into good or at least decent practice.

Checklists can be a good thing, if processes can be formalized, can serve as guidance for the developer, and proof of consideration for the reviewer. At the same time, they can feel inappropriate and like noise in other cases.

I’ve been using horizontal line separators to separate description from test description and aside/scoping/wider context and considerations - maybe I will start adding headlines on those to be more explicit.

Looking at the US in particular right now, I’m not confident it would be used on good conscience. Who knows what they want to prosecute. Justice frameworks can only work with confidence in justice.

This explanation sounds fine. I haven’t seen an actual link to the content of the agreed upon convention across the linked sites.

The Wikipedia article on United Nations Convention against Cybercrime paints a much more concerning picture.

The convention names four types of crimes in particular, which human rights advocates argue are framed too broadly, applicable to any crime committed using an information or communications technology. Many of the crimes it would apply to have only a thin connection to the kind of serious cybercrime, like ransomware and child exploitation, that motivated the convention.

Several organizations highlight the way the convention’s language about human rights protections are largely suggestions left to the discretion of member states, including those with a record of human rights abuses.

Let’s hope it’s a useful framework countries will still make assessments and restrictions on depending on who they’re dealing and working together with. I’m still concerned though.

Why is this community not allowing English language comments when it’s seemingly obviously in English?

That’s a very one-dimensional view of technical debt.

I was about to write something more, but I think if I don’t know what they refer to when they say “knowledge”, then it’s too wishy-washy and I may be talking about something different than they intended.

Contrasting “resolving technical debt” and “investing [improvement] knowledge” we’re moving the reference view point.

I document state and issues as technical debt, and opportunities for change as opportunities. They cross, but are distinct concepts, and do not always cross. Some technical debt may be documented without a documented opportunity. Opportunities may be open improvements that do not tackle technical debt.

In my eyes, technical debt is about burdens that reduce maintainability where better alternatives likely exist.

“Investing knowledge” is something different, and not necessarily about known burdens, but may be improvements unrelated to known burdens.

twiice

gitupl

file-dupl

change-dupl

Worktrees share the data stored in the .git folder. This saves storage (particularly on larger repos, and if you don’t fetch/clone only partial history), and could allow some other workflows or safeguards (backing up just one instead of multiple, centralized local state instead of spread across different workspaces). It also means it could share repo-local git settings - like remotes, local not checked-in ignores, etc. (I assume).

I didn’t add a star at the end for the word search, so at least for that example, the sarcastic ones were all ‘amazingly’ and consequently not counted, and the ‘amazing’ at the end seems literal. I haven’t looked at any other cases, though.

Glad you’re so appreciative and worked through it! I gladly share, discuss, and respond.

I’ll have to read up on palette filters. :) I do semi-regularly use ffmpeg, but palette filters are not something I have heard or used before.

I assume in this case it’s a downsampling into fewer colors, evading the issues of almost-same-colors?

Especially given the last square/check pattern makes me thing of codecs splitting into square blocks and then encoding those. It could make sense that this division leads to different results for one reason or another, which then produces a check pattern without it being there before.

For comparison, “amazing” occurs six times.

Only one of them barely reaching 200. For the size of the Linux kernel I find these numbers surprisingly low.

I don’t see a sharp drop as a sign of corporate oversight at all.

Stuff may be tackled en-batch. Or individuals can care. Or it can be an organic team decision or effort.

1, 2, 4, 5, 6 all look fine resized in the post and full size

3 looks fine full size but has slight visual artifacts resized in the post (check/square pattern)

I can barely see it on my monitor. So on worse monitors it may not even be visible. #272a31 vs #262b31

animated webp may also be an option

The screenshot is from my desktop with wide enough screen on Lemmy web (programming.dev).

The issue is one of scaling.

When I open the image without being resized into the website layout, it has the following visual pattern:

When I zoom out to 50% it looks (almost?) fine

Did you scale the source with ffmpeg? Do you have a visual pattern in your console background? The simplest solution would be to have a solid color as background. The second best to render a small enough size that it does not get resized in the browser.

At 1920x1038, it’s very big right now. I’m surprised the font is big enough to be readable. I assume you scaled it up or have a high dpi display resulting in this.

That visual pattern compression though

I also want locally deleted files to be deleted on the server.

Sometimes I even move files around (I believe in directory structure) and again, git deals with this perfectly. If it weren’t for the lossless-to-lossy caveat.

It would be perfect if my script could recognize that just like git does, instead of deleting and reuploading the same file to a different location.

If you were to use Git, deleted files get deleted in the working copy, but not in history. It’s still there, taking up disk space, although no transmission.

I’d look at existing backup and file sync solutions. They may have what you want.

For an implementation, I would work with an index. If you store paths + file size + content checksum you can match files under different paths. If you compare local index and remote you could identify file moves and do the move on the remote site too.

Your git repo might get very big after some time. Especially if you move files.

Moving files does not noticeably increase git repo size. The files are stored as blob objects. Changing their path does not duplicate them.

Supporting soft subs is a complex topic though. Three formats, font embedding, positioning and animations. It’s a ton of effort, and anything less than “full featureset support” will mean they don’t render how you design them in your full-set editor and local media play. And there will be differences and bugs, at least for a while. I suspect font rendering with various fonts in a media render context will have it’s own set of issues.

I also think it’d be nice, but I can totally see how it may not make sense technically (complexity with its burdens vs need) or economically.

Browsers are already absurdly complex though so… maybe? :P

It doesn’t open with a summary or overview but dives right in to exploration, but I think the point comes across:

The copy and paste key codes, which have no physical keys anymore, are - to a degree - supported in software. Their claim is that those key codes are the tool for universal copy and paste, and then it’s the input interpretations job (key and combination mapping) to offer bindings to those key codes.

GTK added support the copy and paste keyboards in January 2025. QT also added support for copy and paste key codes the same month. I’m not sure of the first released version of the GTK toolkit that will contain the fix. For QT, it will be QT 6.10, scheduled for release in September 2025. Together, this will cover many apps built for Gnome and KDE as well as others that use the same toolkits.

… followed by some more “current state of support for those key codes”.

merge

The HackerOne report that does not even apply has 44 upvotes.

What do upvotes mean on HackerOne?

I guess, at least here, they’re mindless “looks interesting” or “looks well worded” or something?