- steeleduncan parentNone of this actually matters. If you want to keep your data private, host it on your own hardware. Countries, company policies, etc are all essentially irrelevant
- Sorry if I missed this in the docs, but how robust is the persistence? ie is it the disk that comes with a standard AWS VM? or is it a share backed by e.g. Ceph with multiple redundant copies?
- The other conclusion to draw is "Git is a fantastic choice of database for starting your package manager, almost all popular package managers began that way."
- It doesn't seem to be their focus, but this could be amazing for macOS build machines, and servers. There have been a number of changes in recent years focussed on improving the security of macOS when used as a Desktop OS. These work well for their intended purpose, but they have made macOS harder and harder to deploy headlessly, and use as a server.
I hope to see this become an open source OS that runs the full xcode command line suite, deploys easily to headless machines, and inherits FreeBSD's server hardware compatibility.
- Generally development tools run fine under wine, so I'd guess it would be fine. Running a windows binary within wine within WSL on windows does seem a little insane tho!
- Yes, especially as you can do things like
There is no need to keep anything around, or roll your own nix equivalent, you can just look up the output by commit.nix run github:user/repo/commit - > you need Consul for service discovery
Kubernetes uses etcd for service discovery. It isn't that Nomad does things differently or less simply, it is just that they are more explicit about it.
The real difference is that Kubernetes has a wide array of cloud hosts that hide the complexity from users, whereas Nomad can realistically be self hosted
- This seems like an ad hominem attack, are his numbers incorrect?
- Do you know why people stopped? It would seem to be a potentially useful middle ground between docker containers and KVM VMs
- > SQLite could be recoded in Go
Sqlite has been recoded (automatically) in Go a while ago [1], and it is widely deployed
> would probably introduce far more bugs than would be fixed
It runs against the same test suite with no issues
> and it may also result in slower code
It is quite a lot slower, but it is still widely used as it turns out that the convenience of a native port outweighs the performance penalty in most cases.
I don't think SQLite should be rewritten in Go, Rust, Zig, Nim, Swift ... but ANSI C is a subset of the feature set of most modern programming languages. Projects such as this could be written and maintained in C indefinitely, and be automatically translated to other languages for the convenience of users in those languages
- An incredibly generous free tier offering for CI/CD
- > I guess AI pays better
I suspect the problem is that the previous model didn't pay at all. I've used it a lot to try out code snippets, but no one pays for that. It was one of those services that a product would outgrow well before you could imagine spending serious money on it.
It is a shame they didn't find traction with the learn to code without all the hassle angle they once had.
- Are the new scores available anywhere?
- > Even though the song is very odd in many ways
I suspect it is precisely because the song is very odd in many ways that it is so interesting
- > Google could replace Linux kernel with something else and no one would notice, other than OEMs and people rooting their devices.
This would be better phrased If Google could replace Linux kernel with something else noone would notice,
Google have spent a decade trying to replace the Linux with something else (Fuschia), and don't seem to have gotten anywhere
- True, but it only works on Apple systems, which makes Swift far less appealing on non-Apple systems. This adds weight to the point the GP comment makes about Swift being held back by its association with Apple
- > ... do they publish any change information publicly?
This is utter FUD, of course they do, it is an open source distribution. Everything can be found from packages.debian.org
- > I actually prefer the RHEL policy of leaving packages the way upstream packaged them
I don't think RHEL is the right choice if this is your criteria. Arch is probably what you are looking for
- It isn't very clear on that, but I think it is a way of automatically downloading binaries from Github releases. If so, that wouuld work well in some cases, and poorly in others
- I don't know what the licence is, or the legality of using it, but the download urls for the fonts on the linked site are
- I don't remotely want to use Windows 2000 again, but it is interesting to see a version of Windows where the UI was consistent. Currently it is a mishmash of four generations of GUI toolkits, some UI is in one style, some UI is another, etc, etc
- systemd is the init process, the Linux kernel non-optionally runs the init process as root
- > Running individual services that would have been RPMs?
Essentially this. Rather than adding anything on top of systemd (which is almost certainly running anyway) quadlets are a way of turning containers into systemd units, and directing systemd to run them
I think it is the lightest weight, but still convenient, way of running a container as a daemon, with all the pros and cons that implies
- Podman seems to have lower memory overhead than Docker. I assume that is a consequence of your point 1
- I use Nix extensively, but the Nix daemon doesn't do much of use that can't be achieved by building your code from a fixed OCI container with internet turned off. The latter is certainly more standard across the industry, and sadly a lot easier too. Nix is not a revolutionary containerisation technology, nor honestly a very good one.
The value in Nix comes from the package set, nixpkgs. What is revolutionary is how nixpgks builds a Linux distribution declaratively, and reproducibly, from source through purely functional expressions. However, nixpkgs is almost an entire universe unto itself, and it is generally incompatible with the way any other distribution would handle things, so it would be no use to Fedora, Debian, and others
- > Complicated stuff = high probably of failure
This is a myth. The 787 has about 60 million miles of wiring in it. It is vastly more complicated than an airliner from the 1940s, and it also much, much safer. Poorly engineered technology fails, not necessarily complex technology
> secondary problem is the stacking of abstraction layers docker / kubersomething
Then don't use Kubernetes or Docker? They aren't mandatory
- > Write as much CI logic as possible in your own code
Nix really helps with this. Its not just that you do everything via a single script invocation, local or ci, you do it in an identical environment, local or ci. You are not trying to debug the difference between Ubuntu as setup in GHA or Arch as it is on your laptop.
Setting up a nix build cache also means that any artefact built by your CI is instantly available locally which can speed up some workflows a lot.
- From a developer point of view GOG has the most hoops to jump through of all PC platforms, for very few users, so it wouldn't make a lot of sense
Itch.io would be more reasonable. It doesn't have a lot of users, but it is trivial to setup, and doesn't require a launcher
- Ah, interesting, I was unaware of user.js
It seems https://github.com/arkenfox/user.js is a comprehensive set of settings for that
- Is this Firefox rebranded with anything privacy breaking removed?
Personally that is what I want. A minimal set of diffs on top of Firefox that turns off anything obnoxious Mozilla might (or might not) add, but is close enough to the original codebase that it can be updated with security fixes right away