steeleduncan

Because minis are very commonly racked in bulk, and its both very irritating for that use case, and entirely unnecessary

Yes, the most concrete issue the article mentions is losing data on Btrfs, but that is well known to be a flaky, semi-experimental file system, the operating system has very little to do with it. The equivalent would be running Debian on ext4

Also, the article mentions Kubernetes a few times, which quite fairly has a reputation for massive complexity, but is again entirely optional, and a piece of software entirely separate from the operating system.

I agree with the basic point of achieving reliability by using the simplest technology available, but the focus on the operating system for me is misguided here, and at best a temporary fix. If BSD were to catch on for that reason, Kubernetes would be ported to BSD, and the same problem would arise there

In the article there is a link to an earlier post with a RISC-V assembler (I think written by the same author), which generates the actual machine code

Maybe I'm missing something, but the only branch in github:nixos/nixpkgs I can see receiving fixes is the 24.05 branch getting fixes backported from unstable. The last commit I can see to the 23.11 branch is about 3 months ago

This would imply only 9 months of security patches before I would need to upgrade the server. That is of course a far less risky process with NixOS, so perhaps that is ok, but it is a lot more work than the 5 years you get (free) with Ubuntu/Debian

https://github.com/NixOS/nixpkgs/branches/active

What is the security update policy with NixOS? I've always had the impression that I would need to upgrade every 6 months to keep getting critical security fixes, which is unappealing compared to e.g. Debian + Nix

I know I can revert easily if there are problems when upgrading, but that doesn't really apply if security fixes only land in the new branch

Thanks for answering and I really hope it works out. A Nix alternative with less friction would be very welcome!

Looks great, Nix-with-Lua that also supports Windows would be amazing. Two questions if I may

- Does this sandbox builds the way flakes do?

- What is MinGW used for on Windows? Does this rely on the MinGW userland, or is it just because it would be painful to write a full bootstrap for a windows compiler while also developing Zb?

Also, its great to see the live-bootstrap in there. I love the purity of how Guix's packages are built, and I like the idea Zb will be that way from the start

Godot has supported C# for a while now. There is no need to use GDScript

MinGW works well (e.g. mingw-w64 in Debian/Ubuntu). It works well with CMake, you just need to pass CMake flags like

  -DCMAKE_CXX_COMPILER=x86_64-w64-mingw32-c++ -DCMAKE_C_COMPILER=x86_64-w64-mingw32-c

Something like SDL or Raylib is useful for cross platform windowing and sound if you are writing games

I think the point is that

- you write some piece of software

- then you add a straightforward configuration language

- then you add variables because you don't want too much copy/paste

- then you add if statements to allow conditional configuration

- then you add loops because you are sick of seeing configuration that consists of unrolled loops

- ...

At some point your configuration system is Turing complete, so could be considered a programming language. However it was never designed as such, so it is not a horrible one

TeX would be a good example of this. Ansible playbooks are (I believe) Turing complete, and YAML itself has such a huge spec, that if it isn't Turning complete and/or self aware already, I can't imagine it'll be long before it is

Nix and Guix have their issues, but it is hard to read something like this and not wonder why you would migrate to them when facing issues like this

There is a learning curve for either Nix or Guix that puts many off. However its not that steep, certainly it is many orders of magnitude easier than maintaining PostgreSQL, and once you are over that you no longer need to do things like keeping a dedicated clean machine just to pack a tarball. Write the derivation and anyone, anywhere, on any machine can generate the exact same tarball with a one liner

The barrier caused by the initial steps of learning Nix/Guix is a shame because once you are over it, it is difficult to see why software is built any other way (the same may apply to bazel, but i have no experience with that).

As does AWS - https://aws.amazon.com/blogs/aws/new-aws-public-ipv4-address...

I dont think there is any advantage when the language lacks syntax level support for Monads. E.g. in Haskell (which does) it would look roughly like:

  getUser :: Maybe User
  getUser = ...

  getFriends :: Maybe [User]
  getFriends = do
    user <- getUser
    let friends = getFriendsForUser user
    return friends

  bestFriends :: Maybe [User]
  bestFriends = do
    friends <- getFriends
    let besties = filter isBestFriend friends
    return besties

  render :: IO ()
  render = do
    let bffs = getBestFriends
    case bffs of
      Just besties -> renderBestFriends besties
      Nothing -> renderNoFriends

The Maybe monad itself contains the equivalent of runSafely from the article, and the syntax propagates the failure case transparently from getUser down to the choice of render function used. All without either the hassle of handling null cases, or the danger that you might forget to handle them and the code crash. Without syntax level support, its not obviously an improvement to me

This hasn't been true for a while now. Many games have Linux builds, and for those that don't, Steam Proton works incredibly smoothly, and is integrated with the most popular game launcher, Steam. For the most part all you have to do to play games on linux now is click the checkbox to opt into Proton, and then click play.

The biggest remaining issue is anticheats for some competitive games

I don't know about nostr, but I find it is a lot less active than Mastodon. In general the tech accounts I am interested in have moved to Mastodon rather than bluesky. I imagine this would depend on whose activity you are interested in, and where they have chosen to migrate to

There was a point in the history of aviation where anyone who could fly a plane was also capable of constructing and designing one. I wonder if there were similar concerns at that time about a future where someone could be in a cockpit of a plane without truly understanding how the machine works from first principles?

Today that type of concern would seem absurd, and we've gotten used to the idea that flying a plane and building it are separate skillsets and jobs. After all, we are comfortable with aviation engineers designing the aircraft without knowing how to mine the bauxite, smelt it to aluminium, and machine it into aircraft parts.

As comforting as it is to have an overview of how to trace a complete path from logic gate to web request, it isn't necessary. The decrease in the number of engineers with that overview isn't a cause for alarm, or a problem to be solved. It is just a sign that "tech" has matured, and it is stratifying into a set of interlocking disciplines. The same happened with every other subject in human history, and we've been just fine...

Given that the vast majority of CI runs on linux without any equivalent of SIP, I'd have thought it were a complete non-issue

java, .net, apple ecosystem (i.e. swift/objc),...

Yes, in some interview he mentioned that Qud at the time was running as if it were a console app inside Unity. I don't know if that is still true after their UI overhaul, but if so it always seemed odd not to port it to MonoGame instead and save paying the fees.

This repo seems to have virtually no tests. Is that just the way it is? or do you charge for access to your test suite similar to what SQLite does?

There appear to be some go tests as well, but again the ratio is not great

While AI companies are buying high end GPUs by the truckload to run on their Linux fleets this is unlikely to be a problem

I'm not familiar with the details of such things, but would it be possible to "port" the Intel's open source Linux GPU driver to Windows? That would make for a working driver without this junk

Intel provides open source drivers GPU drivers for GNU/Linux. As long as that remains true it is unlikely they'd try to collect telemetry through those drivers. If they do, it would get stripped out long before it reaches the kernel.

Thanks for the explanation!

Thanks for all the great work. I hadn't realised Proton was developed by CodeWeavers. Out of curiosity, what is the relationship between Proton and your own product Crossover?

> Start with writing new code in Lua (faster to prototype) and then see if you need REALLY to move this code (or parts of it) to C++.

This is the only part of the article I disagree with. I've found that the biggest problem with using Lua in a C++ game is writing code in the "wrong" language, and the mess that can cause. The boundary between Lua and C++ needs solid validation to keep bugs out, and this makes it neither performant nor convenient, so minimising the boundary is important. As soon as code ends up in the wrong language, you generally need to add a large amount of unnecessary boundary code.

An important part of designing a Lua/C++ game for me is having a good mental model of what the "right" language to write any piece of code in is, and only deviating from that when performance mandates.

When cross compiling pure Go you set an environment variable, build, and you have a binary ready to run, it is trivial.

When cross compiling with cgo you need a C cross compiling toolchain for the target platform installed with the right libc, etc. It is not impossible and that is how C/C++ is always cross compiled, but it is much more hassle than compiling pure Go.

> since C++11 there is no reason for not using smart pointers

There are many reasons for not using smart pointers, first amongst them for me being performance.

Smart pointers do allow you to remove a large class of memory bugs from your code (albeit not memory leaks) in the same way that Rust's safe references do. However C++ smart pointers impose a run time performance penalty on your code, whereas in Rust the checks happen at compile time leading to better runtime performance.

> With a startup you can always try to pivot

You can do this in gamedev as well.

A high budget example would be Fortnite which pivoted to a Battle Royale version of the original, vastly less successful, game. A lower budget example would be Proteus, originally a failed attempt to write an RPG that pivoted into something quite different.

Discord is an example of a game company pivoting from a failed MOBA to a more traditional tech company.