sxan

sss-vlang v0.0.1

Shamir's Secret Sharing algorithm is a mechanism for splitting a secret S into n shares, of which k are required to recover the secret via a combine function. This library is a translation of sssa-go, which has been externally verified as being a well-designed implementation of the algorithm. This V version improves slightly on the Go version by handling (not ignoring) function errors.

One use case for SSS is to provide N people with keys to allow N-k of them to collaborate to produce a key that can, e.g., decrypt a digital resource. For example, 10 employees might be given keys, with any 5 being required to collude to generate a secret to open a KeePass DB that contains credentials for a server hosting master admin account.

The library has extensive unit tests and good coverage. The project includes two tools: sssc, which is a command line split and combine tool; and sssg, a GUI version.

The algorithm is stable. The library API at this point is mostly stable, and should not change much. sssc is complete, and I expect changes to include only feature additions. sssg is very definitely a WIP, as I figure out the gui package.

Performance of this library is not very good; it runs far slower than the almost Go library it was cloned from; I have not yet tried to optimize it, since performance is irrelevant for the use I have in mind. However, I suspect there is low hanging fruit here, and I'll get to it sooner or later.

cross-posted from: https://feddit.uk/post/33171587

A barn owl mum discovered at a Lincolnshire farm has been described as rare and incredible. Not only is the creature the oldest barn owl ever to have been recorded, the female was found successfully breeding a six-week-old chick.

The bird of prey has left experts amazed after she was discovered at Eastfield Farm in Hough. The incredible creature is 18-years-old - and experts are sure she’s the oldest barn owl ever recorded in Britain or Ireland.

The owl was ringed as a chick, the British Trust for Ornithology (BTO) have confirmed, she had a ring placed around her leg in Nottinghamshire back in 2007, allowing tracking of the bird.

I came across the post about Milk-V Titan, and there was a comment asking about the lack of the V extension would hinder running Ubuntu 25.10 which was targetting a particular RISC-V configuration, and it made me wonder if there were an opportunity for micro kernels to exploit.

Now, up-front: it's been literally decades since I had an OS design class, and my knowledge of OS design is superficial; and while I've always been interested in RISC architectures, the depth of my knowledge of that also dates back to the 90's. In particular (my knowledge of) RISC-V's extension design approach is really, really shallow. It's all at a lower level than I've concerned myself with for years and years. So I'm hoping for an ELI-16 conversation.

What I was thinking was that a challenge of RISC-V's design is that operating systems can't rely on extensions being available, which (in my mind) means either a lot of really specific kernel builds -- like, potentially an exponential number -- or a similar number of code paths in the kernel code, making for more complicated and consequently more buggy kernels (per the McConnell rule). It made me wonder if this is not, then, an opportunity for micro kernels to shine, by exploiting an ability to load extension-specific modules based on a given CPU capability set.

As I see it, the practicality of this depends on whether the extensions would be isolatable to kernel modules, or whether (like the FP extension) it'd just be so intrinsic that even the core kernel would need to vary. Even so, wouldn't having a permutation of core kernel builds be smaller, more manageable, and less bug-prone than permutations of monolithic kernels?

Given the number of different possible RISC-V combinations, would a micro kernel design not have an intrinsic advantage over monolithic kernels, and be able to exploit the more modular nature of their design?

edit clarification

Personally, I love the phrasing, but it seems to me an odd choice for a mainstream media "business" section.

CNN Business' "Fear and Greed Index"

Remember the "I want a white one" video? That's the first video I clearly remember having a text-to-speech voice-over. It was really bad TTS, and it was awesome. Lately, though, I find myself wishing video hosting services like Youtube and Peertube (to a lesser degree) had a filter so that I could filter out any videos with TTS voice overs. Does this bother anyone else?

I'm a little torn about it. There are legitimate reasons for people to use them; I've seen commentary from posters about social anxiety that makes even recording audio difficult, and TTS must be fantastic for ~~mute~~ non-verbal(?) folks. Non-native English speakers may be more comfortable with it. I'm sure the platform doesn't help... how many videos do you have to post where the peanut gallery mocks your verbal mistakes before you give up and just have an engine read your written text? I've also noticed that the use of TTS is far, far worse on Youtube -- I have yet to come across a single video on any Peertub site that uses it, although it must exist.

Like a lot of technology, generated speech is getting abused, and since TTS has valid uses, I put it in the "enshittification" category. It's used on every bulk, low-effort "N greatest/funniest/random-adjective" videos; I hear it in increasingly in those suspiciously AI-smelling, ad-ish "reviews" that just read specs and make an odd comment about how cool it is; and there's so much more low-quality, low-information content that feels AI generated uses it -- or maybe it feels AI generated because it uses it. It's almost always on just awful content.

TTS on video content is a perfect example of "this is why we can't have nice things." I am starting to hate it so much, I abort whatever I'm starting to watch as soon as I hear the absurd cadence and mispronunciations -- I'd rather hear an honest non-native speaker making mistakes than that terrible TTS crap.

Whatever the reason, the use of TTS is a trend I'm putting firmly in the "enshittification" category, but am I overreacting here? Do you have a way of dodging or identifying content that uses TTS, in advance?

I read a news item about how the recent surge of drone aggression is stressing Ukrainians and affecting moral. It wasn't clear whether that was a propaganda piece meant to imply Ukraine is weakening, but I have noticed far fewer Zelenskyy updates in the past couple of months, and the feeling I get from even the pro-Ukrainian media that the invasion is wearing Ukraine down.

I just want Ukrainians to know that you're not forgotten. Even if you feel as if American attention has shifted to other concerns (we have our own crises and fascists now to occupy us), many of us are still staunchly supportive of the Ukrainian cause, and think about you, and donate to causes which we hope help.

Russia seems like a vast, unending well of cannon fodder. Your allies are fickle, at best. You just want to go back to normal lives, regular prosperity; you want your children back. I can't have any idea what you're going through is really like. For what it's worth, know that you have people around the world who sympathize and grieve with you, who are rooting for you, and most of all, who admire what you've achieved: David resisting a brutish and imperialistic Goliath for years, showing the world just how much how a strong and innovative people can accomplish.

I look forward to seeing what a peaceful, prosperous Ukraine makes of itself after the invaders have been defeated and pushed out. This invasion started with prognostications that Ukraine wouldn't last weeks; three years later, and you continue to defy the invaders. I do not doubt that you can persevere; I just want you to know that, despite the media attention on other struggles, you're not forgotten: we stand with Ukraine.

Slava Ukraini. Heroiam slava.

Something like this? The heavy stagger is great, 42 keys is almost perfect, but the thumb placement is -- for me -- horrible. Having to move my thumb to practically under my palm is just terrible ergonomics.

This thumb layout reminds me more of the ErgoDox variants, and is far better placement. Is there a layout close to this?

tjot is a terminal djot renderer.

Features

• Covers 100% of the Djot spec
• Reasonably fast:
  • pandoc -f djot -t ansi: 10 runs, milliseconds per run: [266, σ 270, 274]
  • tjot: 105 runs, milliseconds per run: [24, σ 26, 28]
• ANSI glyphs & escape codes for nice tables, task lists, and coloring
• Renders images, including SVGs
• Detects the terminal size (usually) for accurate wrapping
• Langage-sensitive highlighting for code blocks, and language detection

tjot is alpha; this is the first version that is useful. That said, it's fairly complete.

What is this?

djot is a markup language related to Markdown created by John MacFarlane, the author of pandoc. For a detailed explanation of why he invented djot, see this essay, but my interpretative summary is that he was unsatisfied with the complexity and size of CommonMark -- a result of trying to maintain compatability with Markdown -- and thought they could do better from scratch. djot was the result.

I've been using djot since late 2022, but as there (until recently) was no terminal pager for djot, I finally decided to write one.

To render djot documents on the command line, install tjot and call it with the path to a file, or pipe the file into tjot on stdin. Pipe the output to a pager such as less.

If the document references images via URL, those will be downloaded and rendered.

Limitations

• There are known bugs; see the end of the CHANGELOG for a complete list
• Ultimately, I want a pager. The current version only renders output; paging has to be provided by an external program
• Customization is non-existent
• While images are supported, rendering is via asci; there's no sixel, kitty, or other high-res rendering. SVG rendering, in particular, is of particularly questionable quality.

As usual, feedback is welcome, as are any reports of failures. Although this is an early release, the nature of the project is such that getting exposure to a wide variety and complexity of documents will help me improve it.

What with lemmy.ee closing.

Ĉar lemm.ee fermigos sin, translokiĝos !esperanto ie?

It's a tad surprising he's survived all this time. While I had him, i

• Went through a term of active duty in the army
• went through college
• lived oversees for a few years
• lived in 4 different states, and twice as many apartments and houses

He's one of the few possessions I've managed to keep ahold of despite a fairly nomadic life, but now he's pampered.

Anyway, with the recent cartoon about merch, I'm wondering what other people have. I never got a t-shirt, and it wouldn't have survived until today if I had.

Rook provides a secret service a-la secret-tool, keyring, or pass/gopass, except backed by a Keepass kdbx file.

The problem Rook solves is mainly in script automation, where you have aerc, offlineimap, isync, vdirsyncer, msmtp, restic, or any other cron jobs that need passwords and which are often configured to fetch these passwords from a secret service with a CLI tool. Unlike existing solutions, Rook is headless, and does not have a bespoke secrets database full of passwords that must be manually synchronized with Keepass; instead, it uses a Keepass db directly.

Rook is in AUR and in Alpine community (a MR has been submitted for the new version); binaries are available from the project page.

There have been several releases since my last announcement for v0.2.0, 7 months ago. The major thing is that I've added built-in support for the Linux keyring, which makes it much easier to use; since it improves security, I'm hoping this will encourage users to use the feature.

Here are the rest of the changes, collapsed for brevity:

Added

• built-in support for the kernel keyring on Linux.
• Go 1.24 landed in Alpine, so off we go!

Changed

• autotype and getAttr now detect if keyctl is available and in use, and automatically uses it to get the pin. (which should be superceded by ---keyring)
• the kernel keychain instructions are now independent of external environment variable management, such as herbstluftwm
• Use Go 1.24's go tool for manpage generation, via go:generate.

Fixed

• --keyring may not be used with open; this is now prevented, and documented. It never worked, but it would be seen by the server as on open failure.
• --detach and -P didn't play nicely; now they do
• URLs in the README (thank, mlc-man!)
• getPassword() was prompting on STDOUT, which is bad for piping the pin
• --detach never worked
• logging was going to stdout
• some log messages were not being logged, but just printed out
• PIN authorization had a lot of bugs
• build assets now contain man pages & other documentation, and arch image CI is fixed