#tallship — Public Fediverse posts on home.social

tallship @[email protected] · 2026-09-09 · 01:23 UTC

That was a great video. Thanks @Tube🍂Time! I found myself continually unforgivably, dismissively muttering, "So what? So what? So what?" (Recalling that I still have 3 tube testing machines) until you got to the ESD and especially EMP - one might wonder why much of our defense industries settled entirely on LSI, then VLSI, etc., etc., instead of backup primary systems incorporating this "In between" manufacturing technology that you pointed out, which would certainly have benefited from advances in microminiaturization just the same - mostly, anyway.

But then there's that dialog that for some reason just came to me from "White Squall" where the Captain of the Cuban warship smashes the binnacle compass with his rifle butt and Jeff Bridges exclaims in Spanish, "Real sailors need only the stars overhead to navigate".

That was a really kewl project you built. How do you source the parts nowadays for things like nuvistors? There's very few Electronics surplus/liquidator type stores out there anymore.

I'm still trying to suss out whether Chister the Molister in the pic below is a villainous deer in the headlights of having his superspy cover blown, or if he's the inspiration for that other cartoon character of scandalous nature.

#tallship #nuvistor

tallship @[email protected] · 2026-09-08 · 03:33 UTC

16.0 Alpha 1 has arrived...

People ask me how come I often don't know these things... It's simple really. I'm on kernel-generic-7.2.4-x86_64-1 running #Slackware -current and don't actually bother to look up from the work I'm doing cause 16 is just a distro's version number, but 7.2.4 is a kernel. Officially, Slackware 16.0 Alpha is available w/the Linux huge 6.18.x kernel while 7.2.4 is in /testing.

Me, I'm just rolling along in production as I have been for close to 30 years now w/ Slackware - current looking back on the next upcoming release like it's something from yesterday lolz.

I do the same thing on #Debian (14/Testing/Forky) I just upgraded my kernel to 7.1.12+deb14-amd64 - so I'm not running that far behind the ultra-bleeding edge of Slackware, or what Arch and Gentoo users are either.

Anyway, you're going to hear more about the upcoming Slackware 16 release as the weeks go on and if there's one thing I can advise you of it's don't get caught up in the guessing game bullshit - Patrick will release it matter-of-factly w/o any fanfare and pretty much all bets will be wrong. The most you can do is to ask, "Is it soup yet?".

So here's the thread, and Patrick's response to the OP (who's running 7.3-RC1)

#tallship #FOSS #Linux #distros
⛵

#foss #linux #tallship #debian #slackware #distros

tallship @[email protected] · 2024-04-11 · 18:06 UTC

@danie10 @snikket_im

I personally feel that this is the optimal delivery and update methodology for future software distribution.

I've written about this at length in several articles, and more and more service daemons and client software are taking advantage of this form of direct from the developers method of delivery - not just Android apps.

#FairEmail is one such app that even states in the docs that this is the preferred method, although they do support a total of four methods:

- Google PlayStore - crippleware due to google funding source restrictions. In all cases, this is by far the worst distribution point for software, if not with respect for the product that the developers want to deliver, but also with regards for the privacy of the users who are tracked, mined, and themselves repackaged as a quantifiable inventory item.
- F-Droid custom Dev's repo - 2nd best option, because this is built with the developer's keys when the developer decides to push the product, and contain all feature sets that the developer chooses to include.
- F-Droid repo - 3rd best option, since it is signed with F-Droid's keys and typically lags by some measure of time with respect to release dates, considering that F-Droid staff pushes these out on a best effort basis, according to the time they have available to do so.
- Direct from the developers Git repo - This is the best method. They push a release and the next time you open the app you're notified of an update.

This is part of the magic of Slackware's philosophy too - Patrick and team don't church it up like most distro's do (Debian and AlmaLinux quite often, quite heavily wrt customizations, use Apache or Nginx HTTP servers as examples). Slackware tries to package up software as close to how the upstream intends it to be.

In earlier articles I've published on the topic, I've focused at times on a solution to a theme proffered by #Moxie_Marlinspike, who denigrates the open source model somewhat, for being at a great disadvantage when compared to that of proprietary solutions that can update and evolve protocols, APIs, etc., on a whim, because they're centrally managed and controlled by a single dictatorial source. Microsoft is one such classic example. You simply have NO CHOICE as to when you must allow your software to be EOLed, evolve, or update itself.

Using this model, however, where a central repo, or a distributed, CDN type of repo mirroring is deployed at the origin by the development team itself, FOSS has no problem upgrading even things like protocols as they evolve. Of course, it is ultimately up to the operators of the software to allow updates and the prerogative of the developers to establish the level of nags that users of the software will experience until they permit the updates to occur, but that's beyond the scope of the basis of advocating for this type of delivery model.

Okay I think I'm bordering on hijacking this thread, so I'll make a comment about these types of shennigans by Google, and how one one hand it's certainly a huge frustration, if not an impediment to being found and adopted by users, but moreover, a predatory practice by one of the most egregious violators of personal choice in the free market of consumerism and commerce.

It may hurt being pulled like that, but IMO, I don't think there's anything preventing the good folks behind #Snikket from pushing out the kind of crippleware that google wants them to, while at the same time pushing banner splashes in the app that explain just how fricken' useless it is under the terms necessary to distribute it via that medium, and encouraging users to install it instead by following the instructions at the #git_repo for a fully featured, #e2ee secure messaging platform.

IOW, there's always a silver lining - wear this dejection as a badge of honor and as the evidence to support the fact that you're on the right track!

#tallship #FOSS #privacy #crippleware

⛵

.

#foss #privacy #tallship #e2ee #moxie_marlinspike #git_repo

tallship @[email protected] · 2024-01-23 · 23:29 UTC

Don't trust those "little buddy heaters" and their cousins of having CO2 sensors and low #Oxygen cutoffs that their marketing indicates you can bank your life on.

You can fucking die.

I used a few of these for several years, when I lived completely off-grid, in the mountain wilderness far from the nearest humans.

They're really convenient and quick to heat a small area, or anything close to them, in just a few minutes, and you can pick them up at any Target, Walmart, Big 5, Tractor Supply, Etc., for $40 - $50.

Basically, you warm your environment, sitting on your cot and warming up your feet and toes before turning it off and burrowing into your subarctic bedding. You can leave the pilot going all night so all you need to do is twist and click it on on the morning, but seriously, why bother?

Sharp (and more importantly, observant) girl in the video - although there's no way to be sure, she just may have saved the lives of everyone in that fricken' tent.

https://invidious.fdn.fr/shorts/kaSwF2jru3A?si=u8a0HRKlqPxb_A8T&local=true

#tallship #asphyxiation #camping_safety #CO #Carbon_dioxide

⛵

.

#co #carbon_dioxide #oxygen #asphyxiation #camping_safety #tallship