steinuil

Exactly. The previous install of the system had no swap at all so enabling zram is an improvement.

> If i'm reading this correctly, can run Immich from a Raspberry Pi 4? That's pretty cool.

Yes! It runs completely fine on a Pi, except for the machine learning service. The good news is that you can run that service on a separate computer with a GPU and point Immich to it. Immich will use it when it's available and I think you can configure it to run all the queued ML jobs at a certain time when you expect the computer running the ML service to be on.

Yeah that's more or less my goal for the setup in the post... I didn't have much time to investigate what else I could move off of the SD card but I suspect there's a few other things I could do. NixOS makes it super easy too.

Glad you enjoyed it :)

I have taken a (short) look at KOReader and saw that there's an instructions page on its wiki on how to install it on the rM2; it still uses rm2fb but it suggests using timower's version, which works on newer versions of the OS. What I should've made more clear in the post was that there are options, they're just less convenient to use because Toltec doesn't work.

Hey buddy I think you got the wrong door, the rock shelter's two blocks down.

Bluesky lets you select the language your post is written in before posting it and it is attached as metadata to the skeet. I guess the backend for this only searches posts in English, but it's possible the dataset is not 100% accurate due to some users forgetting to switch language before posting.

Portuguese too. Most words related to christianity (and a few others too, like カボチャ or ボタン) were introduced in the 15th century by portuguese jesuits.

https://en.m.wikipedia.org/wiki/List_of_Japanese_words_of_Po...

Later the AI claims it can't run unit tests without overwriting the production database. This whole thread is hilarious.

https://x.com/jasonlk/status/1946641193644798118

Turns out I managed to use almost all of these during a refactor of a project at work, even metaclasses... (Metaclass usage is justified in my case: we have a sort of language evaluator and using a metaclass lets us define function arguments with their types and validators in a very coincise and obvious way similar to Pydantic.)

I think this list should also include descriptors[0]: it's another metaprogramming feature that allows running code when accessing or setting class attributes similar to @property but more powerful. (edit: nvm, I saw that they are covered in the proxy properties section!)

I think the type system is quite good actually, even if you end up having to sidestep it when doing this kind of meta-programming. The errors I do get are generally the library's fault (old versions of SQLAlchemy make it impossible to assign types anywhere...) and there's a few gotchas (like mutable collections being invariant, so if you take a list as an argument you may have to type it as `Sequence[]` or you'll get type errors) but it's functional and makes the language usable for me.

I stopped using Ruby because upstream would not commit on type checking (yes I know you have a few choices if you want typing, but they're a bit too much overhead for what I usually use Ruby for, which is writing scripts), and I'm glad Python is committing here.

[0]: https://docs.python.org/3/howto/descriptor.html

Some points about the introduction, but otherwise this seems like an interesting collection of (slightly deranged?) patterns in C.

> The truth is that any reasonably complicated software system created by humans will have bugs, regardless of what technology was used to create it.

"Drivers wearing seatbelts still die in car accidents and in some cases seatbelts prevent drivers from getting out of the wreckage so we're better off without them." This is cope.

> Using a stricter language helps with reducing some classes of bugs, at the cost of reduced flexibility in expressing a solution and increased effort creating the software.

...and a much smaller effort debugging the software. A logic error is much easier to reason about than memory corruption or race condition on shared memory. The time you spend designing your system and handling the errors upfront pays dividends later when you get the inevitable errors.

I'm not saying that all software should be rewritten in memory-safe languages, but I'd rather those who choose to use the only language where this kind of errors regularly happens be honest about it.

I spent a good while looking at the image on my phone trying to spot what the author was talking about, but ironically the comparison image itself is compressed (not using a NN ;) ) and that obscures the artifacts you're supposed to be looking at.

If you're looking for examples of ringing and hallucinated details, they're really obvious in the framed picture on the right on respectively the character's shirt and the frame.

Sounds like you'd enjoy using JJ! It looks to me that you have this workflow to work around git's poor tooling for manipulating local commits before pushing. JJ makes that very easy!

Forgot to add something to a previous commit? Run "jj squash -i" to move the lines you select to whatever commit you want. Or you can run "jj edit" to check out that commit and edit it directly.

Want to split a commit into two separate commits? Run "jj split".

Need to reorder commits? Run "jj rebase", and if you have a conflict you can "jj edit" the commits that are marked as conflicted to fix it later, unlike Git where you have to run through a lengthy process of fixing conflicts on commits you don't remember and then review the changes later to see whether they still make sense.

If you want to have a messy working copy of your repo that's very easy to do. The workflow would mostly involve:

- Develop the feature

- "jj split" to pick out the stuff you need into a separate commit, which will appear between master and the working copy commit

- "jj describe" to add a commit message

- "jj bookmark set feature-branch" on the commit containing the stuff you want to push

- "jj git push" to push it

- "jj edit" to return to the commit containing the working copy.

You'd end up with a tree that looks kind of like this:

    @  ptswumyk 2025-02-12 13:16:36 de46f8c1
    │  messy working copy
    ○  slwozrlr 2025-02-12 13:16:22 feature-branch@origin d3d246a1
    │  feature implementation
    ◆  tssssuzr 2025-02-12 12:34:28 master* 8a9bab0f
    │  generate flake registry from inputs
    ~

So it's not that I really need more features to git, just a better UX, which is what JJ provides.

> but to have a good GitHub alternative.

JJ doesn't currently have a "native" repository format (or rather, it's in development and not ready for general usage), so right now a JJ forge wouldn't look too different from your usual Git forges.

Everybody who's using it right now uses it on Git repos on Git forges. I've been using it for months on my own and at work and I didn't make any changes to the infrastructure outside of my own command line usage.

It would be interesting to see what a JJ-native forge would even look like in the future, but I don't think anybody knows exactly what that would be right now! JJ is in development (but stable enough to work with) and people have only just started using it, so it's still in the phase of discovering what workflows are possible.

> Plus a good IDE support.

Now that's something I would love to see. Git tooling works mostly fine but due to how JJ's git backend works, it always thinks it's in a "detached HEAD" state.

The usual arguments against systemd border on religious drivel. I've seen the talk and while I very much value the work that the speaker has done I did not appreciate that the reasons for doing this are the usual vitriolic cat-v talking points.

systemd is very good because it makes many things that the Linux kernel can do very easy. I would like to know how the people who swear against it implement features that I regularly use in systemd like socket/mount/dbus activation, services that dynamically create a user and group on activation and keep their service and temp directories private from other services, syscall filtering, user session services that start when I log into a graphical session (very useful when you have issues with your system tray's config, for example), network mounts that get mounted asynchronously only when you're using them, actual service management and restarting a service when it fails and service dependencies (which some init systems still don't do!), and so on and so forth...

Yes you could do all of these things by composing other programs, but there is lots of value in having them all bundled together and only having to consult one resource for documentation on them, and the fact that these are all designed to work together reduces the friction that you would get by composing other "general-purpose" tools.

On the other hand, systemd is bad because the implementation is messy, when it does fail it tends to do so in odd and obscure ways, it comes bundled with tons of components that most people won't need, and yes the fact that it's essentially the only option you're given and that it's not portable to BSDs is not very nice.

I would encourage people to read dinit's comparison page and Chimera Linux's FAQ section on systemd for good arguments that are not fueled by religious belief as to both why systemd is valuable and in which ways it is bad.

https://github.com/davmac314/dinit/blob/master/doc/COMPARISO...

http://chimera-linux.org/docs/faq#what-is-the-projects-take-...

> The leaf functions come first, and the global interface functions are last.

To me that is backwards. I prefer code written in a topological order for a number of reasons:

- It mirrors how you write code within a function.

- It's obvious where you should put that function in the module.

- Most importantly, it makes circular dependencies between pieces of code in a module really obvious.

I'm generally not a fan of circular dependencies, because they make codebases much more entangled and prevent you from being able to understand a module as a contained unit. In Python they can even lead to problems you won't see until you run the code[0], but circular imports are probably so common that current type checkers disable that diagnostic by default[1].

I think languages that don't support forward references (C, but also OCaml and SML) let me apply the "principle of least surprise" to circular dependencies. OCaml even disallows recursive dependencies between functions unless you declare the functions with "let rec fn1 = .. and fn2 = ..", which may be a bit annoying while you're writing the code but it's important information when you're reading it.

[0]: https://gist.github.com/Mark24Code/2073470277437f2241033c200...

[1]: https://microsoft.github.io/pyright/#/configuration?id=type-... (see reportImportCycles)

Breaking: Web3 devs reach sentience before AI.

I was expecting the post to go into using the JRuby API to run the scripts rather than shelling out to a binary and was left a little disappointed. Still, it looks like a nice way to get everything running quickly.

I don't understand which part of this requires the team to "sacrifice the ‘L’ and ‘B’ from Work-Life-Balance". If you want to encourage your team to re-evaluate their decisions and tackle big problems maybe you should build a culture around that rather than forcing everyone to be in emergency mode?

I think that's what this post is saying, but all the posturing about forcing people to working harder to build "grit" is making it hard to read it as genuine. Clearly this is not a management issue, it's the team's fault for not having enough grit to work hard all the time!

I know, I've used jsdoc type hints and I don't like them very much. They're verbose, types and names are the wrong way around, there's about two or three different syntaxes for defining any one thing, you don't get any autoformatting (AFAIK)... I'm not a fan.

Python actually has a good typed ecosystem these days, and unlike JS -> TS you don't have to add a compilation step to benefit from it: you just have to enable type checking in your IDE.

JS is in a different spot where to benefit from type checking you have to add a build step or reconfigure your build tool, switch files to another extension, add some "type stubs" dependencies, and make significant changes to the codebase to benefit from type checking.

I think if Node and the browsers started allowing type hints in their parsers you'd see much less resistance to TypeScript.

Other scripting languages are probably not popular enough to matter as much as JS does.

Types give you much more than just getting an error early when you call the wrong method on an object or pass a string where you needed a number.

Once you have written down the shape of the data flowing through your program in a way that a compiler can check you'll be able to reason about the whole program better and you might find issues much faster.

I think that types can directly help a lot with logic errors as well: one of the things people say most often when discussing typed programming language is that you can make illegal states unrepresentable, which means that you can encode logic into the type system itself.

FYI, you can turn this off by adding "Defaults lecture = never" to /etc/sudoers. In Nix:

    {
      security.sudo.extraConfig = ''
        Defaults lecture = never
      '';
    }

Or you could also set it to "always" to annoy your users :^)

I've written a lot of OCaml and I always thought `let .. and .. in` indicated that the definitions were mutually recursive and that you could refer to y in x, like in `let rec .. and` or `type .. and`! That's surprising.

The engineers who wrote the High C compiler must have been able to read and write english well enough to have read documentation and source code for existing compilers, and I would imagine that this book was written by the creators of the language.

To be fair, you can barely view any post while unauthenticated these days. Sometimes I click on a link to a tweet on my work laptop (where I'm not authenticated) and I get immediately assaulted by several pop-ups and cookie bars and redirected to the landing page when try to dismiss them.

I don't think this is that critical; if you stay there long enough and regularly go to refill your drink or come back the next day and make a beeline for the drink machine I think the staff would notice something's off.

I know, but sadly I did not have enough time to stay there for more than an hour and try it out.

I like to scan the "specialized" bar/QR codes I come across in my daily life in case they're not just URLs. Sometimes I find some interesting stuff and possibly some opportunities for mild exploits.

The other day I was at burger king. They allow you to refill your drink as many times as you like within 60 minutes of purchasing it, and the way this restriction is implemented is by having you scan a QR code they print on your receipt at the drink machine. I scanned the QR code with Binary Eye (android app that reads all sorts of barcodes, highly recommended). It contained some numbers I couldn't immediately recognize as interesting, a timestamp in a format similar to 202409231049, and a UUID.

Now, the UUID is probably the ID of the order in their internal system, so the question is: does the drink machine only read the timestamp or does it also use the UUID to query the internal system to re-validate it? Can you craft a QR code with the same data but change the timestamp to achieve for infinite refills?

I switched my gaming PC to NixOS a few months ago, I couldn't be happier. Other than a few games that also had issues on Windows and VR, everything I run through Proton just works.

I also own a Steam Deck, which is a wonderful little device and it proved to me that I could safely go through with this switch and not lose access to much.

Congrats to both the Proton and hardware team at Valve, and the people who contributed to Wine; the Year of the Linux Desktop has come, as far as I'm concerned.