sxan

I was thinking about this before the Tholian wave, but it's apropos.

It unscientifically appears to me that TOS had a far higher incidence on non-humanoid aliens than later series. Tholiens, Horta, the flying neural parasites on Deneva; while there were many bipedal aliens sometimes differing only by skins color, many were non-bipeds or were bipedal but radically different from humans, like the Gorn and the salt vampire. In later series, it seems nearly all aliens were reduced to bumpy head species.

TOS ran for only three seasons, and truly different aliens are expensive; I understand the economics of going the prosthetic forehead route. And it's difficult to have recurring truly alien biology in a series.

My question is whether anyone's done a statistical analysis covering the originality of aliens, per series, based on divergence from the humanoid base. Does it only seem like TOS had more different types of aliens (intelligent and non) because it was so short, or was the universe really more diverse in TOS?

Edit 2024-10-01

Another person posted about a similar need, and I decided to create a matrix document to track it, in the hope that those of us looking for this specific use case could come up with the best solution. The idea here is that, while many OSS social media projects are capable of being used like a Fcbook wall, they don't all necessarily provide an ideal user experience. Feature set is not equivalent to being designed for a specific use case, and the desired workflow should be the primary means of interacting with the service. The (for now) open document tracking this is here.

I'm a little surprised I can't find any posts asking this question, and that there doesn't seem to be a FAQ about it. Maybe "Facebook" covers too many use cases for one clean answer.

Up front, I think the answer for my case is going to be "Friendica," but I'm interested in hearing if there are any other, better options. I'm sure Mastodon and Lemmy aren't it, but there's Pixelfed and a dozen other options with which I'm less familiar with.

This mostly centers around my 3-y/o niece and a geographically distributed family, and the desire for Facebook-like image sharing with a timeline feed, comments, likes (positive feedback), that sort of thing. Critical, in our case, is a good iOS experience for capturing and sharing short videos and pictures; a process where the parents have to take pictures, log into a web site, create a post, attach an image from the gallery is simply too fussy, especially for the non-technical and mostly overwhelmed parents. Less important is the extended family experience, although alerts would be nice. Privacy is critical; the parents are very concerned about limiting access to the media of their daughter that is shared, so the ability to restrict viewing to logged-in members of the family is important.

FUTO Circles was almost perfect. There was some initial confusion about the difference between circles and groups, but in the end the app experience was great and it accomplished all of the goals -- until it didn't. At some point, half of the already shared media disappeared from the feeds of all of the iOS family members (although the Android user could still see all of the posts). It was a thoroughly discouraging experience, and resulted in a complete lack of faith in the ecosystem. While I believe it might be possible to self-host, by the time we decided that everyone liked it and I was about to look into self-hosting our own family server (and remove the storage restrictions, which hadn't yet been reached when it all fell apart), the iOS app bugs had cropped up and we abandoned the platform.

So there's the requirements we're looking for:

• The ability to create private, invite-only groups/communities
• A convenient mobile capture+share experience, which means an app
• Reactions (emojis) & comment threads
• Both iOS and Android support, in addition to whatever web interface is available for desktop use

and, given this community, obviously self-hostable.

I have never personally used Facebook, but my understanding is that it's a little different in that communities are really more like individual blogs with some post-level feedback mechanisms; in this way, it's more like Mastodon, where you follow individuals and can respond to their posts, albeit with a loosely-enforced character limit. And as opposed to Lemmy, which while moderated, doesn't really have a main "owner" model. I can imagine setting up a Lemmy instance and creating a community per person, but I feel as if that'd be trying to wedge a square peg into a round hole.

Pixelfed might be the answer, but from my brief encounter with it, it feels more like a photo-oriented Mastodon, then a Facebook wall-style experience (it's Facebook that has "walls", right?).

So back to where I started: in my personal experience, it seems like Friendica might be the best fit, except that I don't use an iPhone and don't know if there are any decent Friendica apps that would satisfy the user experience we're looking for; honestly, I haven't particularly liked any of the Android apps, so I don't hold out much hope for iOS.

Most of the options speak ActivityPub, so maybe I should just focus on finding the right AP-based mobile client? Although, so far the best experience (until it broke) has been Circles, which is based on Matrix.

It's challenging to install and evaluate all of the options, especially when -- in my case -- to properly evaluate the software requires getting several people on each platform to try and see how they like it. I value the community's experience and opinions.

I vastly prefer to support community artisans over mass-produced material when I can. Is anyone in the community making Moopsies?

It is not my intention to ignite an EMACS/vim war; I will say that I find it baffling that Lower Decks is ending while Strange New Worlds is being continued. I like Strange New Worlds, despite disagreeing with some of the artistic licenses being taken. But if I had to choose between the two shows, it'd be no contest. Not only as a viewer do I prefer LD, but it has to be the cheaper show to produce. The fact that next season is the last (both by design, it only being contracted for 5 years; and announcement) is sad and incomprehensible in the same way the cancelation of Firefly was - except LD is popular and successful, whereas Firefly merely had a fanatical (🖐️) fan base.

I don't understand it. Yes, you want to end on a high note. Maybe the writers are running out of plot ideas. Perhaps, given an initial life span of 5 years, the actors have all made other arrangements and aren't available. But I just can't believe the One Big Plot Arc that's been building would necessitate ending the series by its resolution.

LD is a strong show. It's lighthearted. It's a breath of fresh air after the more decidedly darker, ethically challenging, and emotionally straining runs of TNG, Voyager, DS9. And Strange New Worlds... the Gorn are basically Xenomorphs from the Alien franchise.Who, despite being the existential threat of the show, somehow get entirely forgotten about by the time in TOS.

But I digress. I'm going to miss Lower Decks, badly. How can this happen? And why?

Rook is a lightweight, stand-alone, headless secret service tool backed by a Keepass v2 database. It provides client and server modes in a single executable, built from a reasonably small (auditable) code base with a small and shallow dependency tree - it should not be challenging to verify that it is not doing anything sketchy with your secrets.

Reasonable auditability, the desire to use KeePass files, and to do so through a headless tool that doesn't spawn off the better part of a DE through otherwise unused services, were the main motivations for Rook.

You might be interested in Rook if one or more of these are true:

• you use KeePass v2-compatible tools to store secrets already
• you are not running a DE like KDE or Gnome (although Rook may still be interesting because of secret consolidation)
• you prefer to minimize background GUI applications (KeePassXC is excellent and provides a secret service, but doesn't run headless)
• you run background applications such as vdirsyncer, mbsync (isync), offlineimap, or restic, or applications such as aerc that can be configured to fetch credentials from a secret service rather than hard-coded in a config file.

Pre-built binaries for limited OS/archs are built by the CI, and Rook if available in AUR. There's an nfpm config in the repos that will build RPMs and Debs, among others. I consider Rook to be essentially free of any major bugs and fit-for-purpose, although I welcome hearing otherwise.

Utility scripts in zsh and bash are available for providing autotyping and entry/attribute selection using xdotool, rofi, xprop, and so on; these are YMMV-quality.

Changes from v0.1.1 are:

Added

• one-time pin soft locking
• installation instructions for distributions that have rook in a repository
• more of the special autotype {} commands are supported (backspace, space, esc)

Changed

• getAttr adds a little delay before typing, allowing initiator tools (like rofi) to close windows before text is output
• cleans up code per golint/gochk

Fixed

• an autotype bug in outputting literals

cross-posted from: https://midwest.social/post/9890016

Rook, a secret service backed by Keepass 4.x kdbx

Howdy Lemmy,

I'm announcing Rook v0.0.9, software that provides a secret service a-la secret-tool, keyring, or pass/gopass, except backed by a Keepass 4.x 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.

While the readme goes into more detail, I will say the motivation for Rook evolved from a desire to use a Keepass db in a GUI-less environment and finding no existing solutions. KeepassXC provides a secret service, but is not headless; it also provides a CLI tool, but this requires the db credentials on every call. kpmenu exists, but is designed specifically to require human interaction and is unsuitable for cron environment scripting. Every other solution maintains its own DB back end, incompatible with Keepass.

Rook also benefits from minimal external dependencies, and at 1kloc is auditable by developers - I believe even by ones who do not know Go (the language of implementation). Being able to verify for yourself that there's no malicious code is a critical trait for a tool with which you're trusting secrets.

Rook is fit for purpose, and signed binaries are provided as well as build-from-source instructions (for auditors).

The project contains work in progress: credentials are limited to simple password-locked kdbx, and so doesn't yet support key files. Bash scripts that provide autotyping and attribute/secret selection via rofi, fzf, and xdotool are provided, for GUI environments; these have known bugs. Rook has not been tested on BSD, Darwin, or any other system than Linux, but may well work; the main sticking point is the use of a local file socket for client/server communication, so POSIX systems should be fine, but still, YMMV.

As a final caveat: up until v0.0.9 I've been compressing with brotli, which is very nice yet somewhat obscure. With the next release, everything will be gzipped. Also included in the next release will be packages for various distributions.

Howdy Lemmy,

I'm announcing Rook v0.0.9, software that provides a secret service a-la secret-tool, keyring, or pass/gopass, except backed by a Keepass 4.x 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.

While the readme goes into more detail, I will say the motivation for Rook evolved from a desire to use a Keepass db in a GUI-less environment and finding no existing solutions. KeepassXC provides a secret service, but is not headless; it also provides a CLI tool, but this requires the db credentials on every call. kpmenu exists, but is designed specifically to require human interaction and is unsuitable for cron environment scripting. Every other solution maintains its own DB back end, incompatible with Keepass.

Rook also benefits from minimal external dependencies, and at 1kloc is auditable by developers - I believe even by ones who do not know Go (the language of implementation). Being able to verify for yourself that there's no malicious code is a critical trait for a tool with which you're trusting secrets.

Rook is fit for purpose, and signed binaries are provided as well as build-from-source instructions (for auditors).

The project contains work in progress: credentials are limited to simple password-locked kdbx, and so doesn't yet support key files. Bash scripts that provide autotyping and attribute/secret selection via rofi, fzf, and xdotool are provided, for GUI environments; these have known bugs. Rook has not been tested on BSD, Darwin, or any other system than Linux, but may well work; the main sticking point is the use of a local file socket for client/server communication, so POSIX systems should be fine, but still, YMMV.

As a final caveat: up until v0.0.9 I've been compressing with brotli, which is very nice yet somewhat obscure. With the next release, everything will be gzipped. Also included in the next release will be packages for various distributions.

I got tired of pinentry popping up and interrupting whatever I was doing; I didn't find a solution elsewhere, so I wrote a little bash script to address this. This is designed for (poly|i3|way|...)bar users. The blog entry (no ads, no tracking) linked has the script verbatim, plus some rambling about the why and wherefore.

It's 22 lines of does-stuff; the rest is whitespace, comments, and instructions -- including a little blob example of using it with polybar.

A known issue is that it does occasionally pop up pinentry twice in a row when unlocking. I'm not surprised, and it has happened to me only once since I've been using it -- not enough for me to need to bother trying to address it. But I wanted to call it out.

It's not rocket science, but it took a bit of time to make sure it functioned correctly (enough), and hopefully it'll help someone else.