There’s operations that treat bits like floats and operations that treat them like various kinds of ints, but the meaning of bits is in the eye of the beholder. There’s even good examples of mixing and matching integer and floating point operations to clever effect, like with the infamous fast inverse square root. I feel like people often think mathematical objects mean something beyond what they are, when often math is kind of just math and it is what it is (if that makes sense… it’s kind of like anthropomorphizing mathematical objects and viewing them through a specific lens, as opposed to just seeing them as the set of axioms that they are). That’s kind of how I feel with this stuff. You can treat the bits however you want and it’s not like integer operations and bitwise operations have no meaning on supposedly floating point values, they do something (and mixing these different types of operations can even do useful things!), it just might not be the normal arithmetic operations you expect when you interpret the number as a float (and enjoy your accidental NaNs or whatever :P).

The difference of static and dynamic typing being when you perform the type checking is partially why I consider it to be a somewhat arbitrary distinction for a language (obviously decidable static type checking is limited, though), and projects like typescript have shown that you can successfully bolt on a static type system onto a dynamic language to provide type checking on specific parts of a program just fine. But obviously this changes what you consider to be a valid program at compile time, though maybe not what you consider to be a valid program overall if you consider programs with dynamic type errors to be invalid too (which there’s certainly precedence for… C programs are arguably only real C programs when they’re well-defined, but detecting UB is undecidable).

I kind of feel like “untyped” is a term that doesn’t really have a proper definition right now. As far as I can tell when people say “untyped” they usually mean it as a synonym for whatever they consider “dynamically typed” to mean (which also seems to vary a bit from person to person, haha). Sometimes people say assembly is untyped exactly for this reason, but you could also consider it to have one type “bits” and all of the operations just do things on bits (although, arguably different sized registers have different types). Similarly, people sometimes consider “dynamically typed languages” to just be “unityped” (maybe monotyped is more easily distinguished from untyped, haha) languages at their core, and if you squint you can just think of the dynamic type checks as a kind of pattern matching on a giant sum type.

In some sense values always have types because you could always classify them into types externally, and you could even consider a value to be a member of multiple types (often programming languages with type systems don’t allow this and force unique types for every value). Because you could always classify values under a type it feels kind of weird to refer to languages as being “untyped”, but it’s also kind of weird to refer to a language as “typed” when there isn’t really any meaningful typing information and there’s no type system checking the “types” of values. Types sort of always exist, but also sort of only exist when you actually make the distinctions and have something that you call a “type system”… In some sense the distinction between static and dynamic typing is sort of an arbitrary implementation detail too (though, of course, it has impacts on the experience of programming, and the language design makes a bit of a difference in terms of what’s decidable :) (and obviously the type system can determine what programs you consider to be “valid”)… But you can absolutely have a mix of static type checking and dynamic typing, for instance… It’s all a little more wishy washy than people tend to think in my opinion).

Running Jellyfin off of a VPS provider seems needlessly expensive. I guess server hardware has an upfront cost, but having real hardware to host it on at home will be far more cost effective long term, especially for storage.

Yeah, that’s my main concern. I believe the Immich developers have said they have no desire to implement it, though… Which is fair enough, it doesn’t work for my desired use case though.

I want all data to be encrypted before it even reaches the server. Yes, I don’t want to trust even my own server for my image backups :), particularly since I would want to use something like Immich to provide photo backups for friends and family and I don’t even want to technically have access to their unencrypted photos unless they explicitly share them. I kind of want the attack surface for my photos to be as small as practical too. It’s almost certainly worse to have them available on my device unencrypted than a dedicated server, but it’s worse to have them unencrypted on both (and I want photos available on device so, thems the breaks).

I get that a lot of people won’t care about this and that they’d rather be able to run the image recognition features of Immich on the server and stuff, but I don’t think it’s entirely unreasonable to want encryption for this. If nothing else I’d love to be able to back up photos for friends and family and legitimately be able to tell them that it’s encrypted and I can’t see any of it. It’d be even sweeter if they could do image recognition on device and sync that metadata (encrypted) to the server as well.

I’m kind of disappointed by the lack of encryption. It sounds great, but I don’t want to trust the server.

Probably, but my exposure to Wayland has just been people complaining about how much X11 sucks and then proceeding to have more problems than everybody else.

I don’t really have much of an opinion about Wayland but it’s still funny to me whenever somebody using Wayland shits on X11 and then tries to share their screen on Zoom or something. If Wayland ends up being great I’ll be happy, but for now X11 just kind of works, so I don’t understand why people are so eager to switch? This isn’t to say I don’t understand the desire to build something better and more secure than X11, I’m just not sure what the end user gets out of Wayland right now. I don’t have VRR monitors and stuff, though, so maybe I’m not running into problems I would be if I wanted fancier features. Plus, I use xmonad and some other stuff right now that won’t work on Wayland, so I don’t have much incentive to try it. Hopefully everything gets Wayland updates eventually.

Oh good, you wrote basically the exact response I was going to give!

The only other thing I would mention is… if you don’t know what a command is, you can and should look it up! You can use the internet, but you can also try “man sudo” or “info sudo” and do a bit of reading. It might not make sense at first, but you’ll start building up a vocabulary really quickly.

I can totally understand why the terminal seems confusing and scary right now, but it’s actually awesome for this kind of stuff because you can just copy and paste commands to do pretty much anything to your computer. Using a GUI often means having a bunch of screenshots that you have to follow manually to do something that a single command can do. Once you’re used to the terminal for these kinds of things GUIs can seem barbaric. Of course it seems scary before you know much about it because it seems like the fucking matrix, and you should only run commands from sources you trust (because they can do anything)… But it’s worth giving a chance, I think.

For this particular instance… often you can just download an application on Linux from a website and run it, but this is almost never the preferred way of doing things. Usually you install applications from your package manager, which is kind of like an App Store (but free), and the advantage of this is that 1) you don’t have to hunt down sketchy executables on the internet, you have a vetted source of safe packages from your distribution, and 2) you can easily update all of your packages. Having a one stop shop for all of your applications (or at least most) is really great, but it can be a little annoying when something you want isn’t in the official repos (like this), though it’s usually a fairly rare occurrence.

The abysmal adoption of DNSSEC is just embarrassing, and I haven’t heard any good arguments for why we shouldn’t do it. There’s one blog post that gets passed around as justification for not adopting DNSSEC, but it doesn’t really go into any technical detail and is mostly just the author saying “I’m scared of governments and TLDs”… which is maybe fair, but you still have to trust them for regular CA certs and everything, so why not make thr base secure?

Honestly, I might care slightly more about DNSSEC than IPv6 adoption… IPv4 exhaustion and NATing everywhere sucks, but the fact that you can’t trust DNS is like… insane.

DNS setups can get fairly complicated with enterprise VPNs and stuff, but the main thing is probably just that DNS is built entirely around caching, so when something does go wrong or you’re trying to update something it’s easy for there to be a stale value somewhere. It’s also really fundamental, so when it breaks it can break anything.

Overall, though, DNS isn’t terribly complex. It’s mostly just a key-value store with some caching. Running your own nameservers is pretty cool and will give you a much better understanding of how it all fits together and scales.

But it all happens at compile time. That’s the difference.

No, when you have a library like SDL you will have functions that wrap lower level libraries for interacting with the screen and devices. At SDL’s compile time you may have preprocessor macros or whatever which select the implementation of these functions based on the platform, but at run time you still have the extra overhead of these SDL function calls when using the library. The definitions won’t be inlined, and there will be extra overhead to provide a consistent higher level interface, as it won’t exactly match the lower level APIs. It doesn’t matter if it’s compiled, there’s still overhead.

C is just a language, it’s not native. Native means the binary that will execute on hardware is decided at compile time, in other words, it’s not jitted for the platform it’s running on.

Wine doesn’t really involve any jitting, though, it’s just an implementation of the Windows APIs in the Linux userspace… So, arguably it’s as native as anything else. The main place where JIT will occur is for shader compilation in DXVK, where the results will be cached, and there is still JIT going on on the “native windows” side anyway.

If you don’t consider C code compiled to native assembly to be native, then this is all moot, and pretty much nothing is native! I agree that C is just a language so it’s not necessarily compiled down to native assembly, but if you don’t consider it native code when it is… Then what does it mean to be native?

the binary that will execute on hardware is decided at compile time

This is true for interpreted languages. The interpreter is a fixed binary that executes on hardware, and you can even bake in the program being interpreted into an executable! You could argue that control flow is determined dynamically by data stored in memory, so maybe that’s what makes it “non-native”, but this is technically true for any natively compiled binary program too :). There’s a sense in which every program that manipulates data is really just an interpreter, so why consider one to be native and not the other? Even native assembly code isn’t really what’s running on the processor due to things like microcode, and arguably speculative execution is a fancy kind of JIT that happens in hardware which essentially dynamically performs optimizations like loop unrolling… It’s more of a grey area than you might think, and nailing down a precise mathematical definition of “native code” is tricky!

I assume you’re not talking about a compiler that generates C code here, right? If it’s outputting C, then no, it’s not native code yet.

But it will be native code :). Pretty much all compilers go through several translation steps between intermediate languages, and it’s not uncommon for compilers to use C as an intermediate language, Vala does this for instance, and even compilers for languages like Haskell have done this in the past. C is a less common target these days, as many compiler front ends will spit out LLVM instead, but it’s still around. Plus, there’s often more restricted C-like languages in the middle. Haskell’s GHC still uses Cmm which is a C-like language for compilation, for example.

Well first off, games don’t ship with their HLSL (unlike OGL where older games DID have to ship with GLSL), they ship with DXBC/DXIL, which is the DX analog to spir-v (or, more accurately, vice versa).

Sure, and arguably it’s a little different to ship a lower level representation, but there will still be a compilation step for this, so you’re arguably not really introducing a new compilation step anyway, just a different one for a different backend. If you consider a binary that you get from a C compiler to be native code, why shouldn’t we consider this to be native code :)? It might not be as optimized as it could have been otherwise, but there’s plenty of native programs where that’s the case anyway, so why consider this to be any different?

Ultimately the native vs. non-native distinction doesn’t really matter, and arguably this distinction doesn’t even really exist — it’s not really easy to settle on a formal definition for this distinction that’s satisfying. The only thing that matters is performance, and people often use these things such as “it’s a compiled language” and “it has to go through fewer translation layers / layers of indirection” as a rule of thumb to guess whether something is less efficient than it could be, but it doesn’t always hold up and it doesn’t always matter. Arguably this is a case where it doesn’t really matter. There’s some overhead with wine and DXVK, but it clearly performs really well (and supposedly better in some cases), and it’s hard to truly compare because the platforms are so different in the first place, so maybe it’s all close enough anyway :).

Also to be clear, it’s not that I don’t see your points, and in a sense you’re correct! But I don’t believe these distinctions are as mathematically precise as you do, which is my main point :). Anyway, I hope you have a happy holidays!

You’re explaining yourself fine, I just don’t necessarily agree with the distinction. It’s like when people say a language is “a compiled language” when that doesn’t really have much to do with the language, it’s more of an implementation detail. It’s a mostly arbitrary distinction that makes sense to talk about sometimes in practice, but it’s not necessarily meaningful philosophically.

That said, SDL isn’t really any different. It’s not translating languages, but you still have additional function calls and overhead wrapping lower level libraries, just the same as wine. DXVK has an additional problem where shaders will have to be converted to SPIR-V or something which arguable makes it “more non-native” but I think that’s not as obvious of a distinction to make too. You probably wouldn’t wouldn’t consider C code non-native, even though it’s translated to several different languages before you get native code, and usually you consider compilers that use C as a backend to be native code compilers too, so why would you consider HLSL -> SPIR-V to be any different? There’s reasons why you might make these distinctions, but my point is just that it’s more arbitrary than you might think.

You’re not wrong, and the translation layers definitely do make a difference for performance. Still, it’s not all that different from a slightly slow slightly odd “native” implementation of the APIs. It’s a more obvious division when it’s something like Rosetta that’s translating between entirely different ISAs.

My understanding is that DXVK implements the Direct3D API using vulkan behind the scenes. So, sure, there might be a bit of overhead versus a more direct implementation. Frankly this doesn’t feel all that different from something like SDL to me. Shaders will have to be compiled into shaders that Vulcan understands, but you could just think of this as part of the front end for shader compilation.

I do agree that it feels less native to me too (particularly over the rest of wine), but it’s sort of an arbitrary distinction.

I think anything that CodeWeavers helped port. I think Bioshock Infinite is one such game. I’m not sure if you’d see wine binaries, though, could all be statically linked in.

There’s a few Linux “native” releases on steam that use compatibility layers based on wine behind the scenes, which I think is probably what they mean.

Also, this feels wrong, but… Is wine native? It’s mostly just the windows api implemented as Linux libraries. What’s the distinction that makes it “non-native” compared to other libraries? Is SDL non-native too?

I think it’s totally fair that people would want to stick with what they know and would find a new operating system intimidating. But, I think some of this push back is kind of warranted since people act like you can’t play any games on Linux or that the Steam Deck is stupid because it has Linux and isn’t compatible with absolutely every game, and I think that’s sort of misguided. An astonishing amount of stuff just works these days, and while I wouldn’t say a Windows user should switch to Linux unless they have a good reason to, I think some people might be doing themselves a disservice if they’re avoiding the Steam Deck because they think it won’t play their games (with caveats about anti-cheat and multiplayer of course!)

You leave NixOS alone!!