NTARelix

A couple years ago I upgraded my desktop hardware, which meant it was time to upgrade my homelab. I had gone through various operating systems and methods of managing my services: systemd on Ubuntu Server, Docker Compose on CentOS, and Podman on NixOS.

I was learning about Kubernetes at work and it seemed like such a powerful tool, so I had this grand vision of building a little cluster in my laundry room with nodes net booting into Flatcar and running services via k3s. When I started building this, I was horrified by the complexity, so I went the complete opposite direction. I didn't need a cluster, net booting, blue-green deployments, or containers. I landed on NixOS with systemd for everything. Bare git repos over ssh for personal projects. Git server hooks for CI/CD. Email server for phone notifications (upgrade failures, service down, low disk space etc). NixOS nightly upgrades.

I never understood the hate systemd gets, but I also never really took the time to learn it until now, and I really love the simplicity when paired with NixOS. I finally feel like I'm satisfied with the operation and management of my server (aside from a semi frequent kernel panic that I've been struggling to resolve).

I recall in the early or mid 2000s using some cheap earbuds plugged into the microphone port of my family computer as a pair of microphones in lieu of having a real microphone nor the money for one. Then I used Audacity to turn the terrible recording into a passable sound effect for the video games I was making.

Not knowing much about how soundcards work, I imagine it would be feasible to flash some soundcards with custom firmware to use the speaker port for input without the user knowing.

I've also been using it for several years and almost completely agree with your sentiment. The only areas that have given me trouble are in the dev tools. On my machines the debugger is significantly slowed down when opening very large JS files, source maps compound the debugger slow down, and I can't always inspect variables' values when using source maps (possibly a build tool config problem).

My designers take their own snapshot by cloning their work and using versions in the names of things. Older things are not to be modified with few exceptions. It makes for a good linking experience on my end, but I don't know what that kind of maintenance is like for them.

The content of the series describes creating something like the beginnings of a Deno alternative, upon which the reader could fully recreate Deno or Node.js. It seems to me that the core idea presented is "a JavaScript/TypeScript interface to Rust". The thing that most interests me about something like this is not making yet another alternative to Deno or Node.js, but the potential for adding a scripting language to an application or framework written in Rust. I'm thinking like Python scripting of Blender, Lua as a scripting/modding layer for a game engine, scripting of Tiled with JS, an Electron alternative using GTK, your own browser.

I have memories of illegal immigrant workers from longer than 22 years ago and the USA has had immigration laws for much longer than 22 years. Have I misunderstood your statement?

My android phone's apps must ask for permission to use some of this data (location, microphone, filesystem, etc.), and android provides the options "always", "only when using the app", "this time only", and "never"; which seems to help with this problem, though I'm sure it's nowhere near a silver bullet. When I leave my home I only feel (mostly) untracked if I do so without my phone and only buy things with cash, which is almost non-existent behavior for myself and the people I know.

Over the last decade or so I've switched between Kodi (even back when it was XBMC on a literal Xbox [the original]), Plex, Emby, and Jellyfin; currently settled on Jellyfin for maybe a year and a half. I've also had a great experience with Jellyfin and love that it doesn't hide features behind a paywall. I agree that it has caught up with the competitors in terms of necessary features, but it occasionally feels a little buggy or in need of some UX polish. Perhaps one of my free weekends I'll see if I can contribute.

One of the primary features I appreciate that the others have behind a paywall is the ability to download content for offline use. 1 less reason to open up my network's SSH port to the world. The feature is great for trips where connectivity is limited, or just at a friend's house with terribly unreliable wifi.

I run Jellyfin on an Athlon II X4 (12 or 13 years old) with several other self-hosted services. Transcoding anything above 720p causes the entire system to come to a screeching halt, so I've pre-transcoded all of my content with handbrake to allow direct-play 4k content on all my home devices (Firefox, Shield TV, Chromecast, Android client, desktop client).

I haven't used fp-ts directly, but I use an adjacent package that declares fp-ts as a peer dependency: io-ts. I've almost exclusively for easier type management during deserialization. In vanilla TypeScript I would have defined an interface and a user-defined type guard to handle deserialization:

interface ClientMessage { content: string }

function isClientMessage(thing: unknown): thing is ClientMessage { return thing !== null && typeof thing === 'object' && typeof thing.content === 'string' }

expect(isClientMessage('nope')).toBeFalse()

expect(isClientMessage({ content: 'yup' })).toBeTrue()

but user-defined type guards basically duplicate the interface, are prone to error, and can be very verbose. io-ts solves this by creating a run-time schema from which build-time types can be inferred, giving you both an interface and an automatically generated type guard:

import { string, type } from 'io-ts'

const ClientMessage = type({ content: string })

expect(ClientMessage.is('nope')).toBeFalse()

expect(ClientMessage.is({ content: 'yup' })).toBeTrue()

Very nifty for my client/server monorepo using Yarn workspaces where the client and server message types are basically just a union of interfaces (of various complexity) defined in io-ts. Then I can just:

ws.on('message', msg => {

  if (ClientMessage.is(msg)) {

    // fullfill client's request

  } else {

    // handle invalid request

  }

})

Only thing missing is additional validation, which I think can be achieved with more complicated codec definitions in io-ts.

This is correct, but I think the point nickdandakis was trying to make is that useEffect does not directly correlate with componentDidUnmount because useEffect's returned callback could be called in the middle of the component's lifecycle, not only when the component unmounts.

I might be remembering the timeline wrong, but I was perfectly happy using Firefox when I first heard of Chrome. When I switched from Firefox to Chrome I was very impressed with the improvements in design, performance, and greater set of useful features. Definitely some steps in the right direction, but I believe we had already been saved from IE. These days there are many browsers to choose from (though most seem to be built on Chromium, which we wouldn't have without Chrome) and the competition is fun to spectate.

The big improvement for me that Firefox had over IE was tabs, though I'm sure there were many other UX improvements that my young mind didn't recognize or hold onto.