dpc_01234

I'm a big fan of AGPL + CLAs. It's a perfect balance where Free Software community gets what it wants (actively maintained, quality, free software that humanity at large can benefit from), while propriety community gets what it wants too (pay and get paid).

People who complain about it are naive and entitled thinking that someone can build and maintain something non-trivial for them indefinitely by just pure altruistic sacrifice and just give it away for free.

With AGPL + CLAs you get all the benefits of fully free software, while the copyright holders get something in return for their work: a competitive advantage and being able charge someone other than free software community.

As a developer signing a CLAs it doesn't bother me at all - my work is freely available to everyone with a license that preserves that freedom for everyone, which is what I cared about. The fact that it can make money to the copyright holder doesn't cost me anything, and is a reward for value they shared.

You don't get people bitching nearly as much about MIT, BSD, etc. where ones making most money on it are the usual big tech players in a position to resell it as a service or an appliance. Why does it bother anyone so much that company providing all that FOSS value will be in position to make money?

Capitalism is just distributed optimization protocol. It reacts to its inputs, producing predictable results. Had e.g. environmental externalities were included in the capitalist calculation, capitalists would optimize them for the benefit of all. Unfortunately it's also a tail that is wagging the dog. It is supposed to serve the society, but without control over it it's the society that serves it.

There's really nothing outdated about capitalism. It's the political systems that are outdated, where they can't control the ever-growing capitalistic protocol and give it inputs to produce desired outputs. Or anything else for that matter. Voters are too stupid to understand anything complex, and they elect politicans who have no clue or care for it either. And it's been like that pretty much since forever. It's just that last few centuries the technological progress was so powerful that it was able to overcome even the most radical political attempts at ruining everything.

Unfortunately politics are a hard coordination problem - trying to make robust global system out of pieces who have incomplete information, are flawed, irrational and often actively malicious. Distributed systems are hard even assuming near perfect conditions and trustworthy agents, and with such conditions and requirements - it might be unsolvable problem.

Wat. No.

Who said anything about enemies. I just don't think someone that consciously bought into a exclusionary walled garden deserves any sympathy... because some external software doesn't work for them.

It does? Cgroups. The problem is that Posix doesn't have them, so it's not portable.

Yes. Absolutely.

We are not talking here about people trying to uplift themselves or humanity around them, and get/give access to education, Internet, computing, etc. We're talking about people who dropped 2 grands to buy into an luxurious anti-freedom walled garden.

This is missing the forest for the trees.

There is no one always-right way to get best performance for every program. You can argue about it all you want. Thread-per-core benefits/downside is a typical "it depends" discussion.

The problem is that using `async` in the first place is a premature optimization. 99% of Rust programs are not redis, linkerd and alikes. They are some CLI tools or Web apps that could have been written in Python or Ruby, and they would still be fast enough.

So why as a community we abandoned blocking IO Rust and everything is async now, and developers are just doing `#[tokio::main]` by default on everything?

`nix run nixpkgs#pkgx -- ...` :D ?

I'm using syncthing to keep bare repos of my git dotfiles and alikes. Never any issues.

It's seems like nature is rewriting it in Rust all the time .

In my experience the biggest issue for being IPv6 only in AWS is that github still can't IPv6! Tons of software expects to be able to reach out to github for something.

One can use some public NAT64 services, but that's not very reliable for anything serious. https://nat64.xyz/ . AWS chargers arm and leg for NAT gateways traffic, and I don't think it's possible to configure them so that they only intercept traffic to ipv4-only hosts (please let me know if i'm wrong).

Other than this being IPv6-only in AWS works flawlessly and is cheaper (free egress gateways for private networks). As long as you don't care about IPv4 of course - that's given.

I was using Kakoune for 3-4 years, and switched a year ago to Helix.

Kakoune is OK, but:

Some details of editing are too optimized for counting keystrokes in vim golf, less for thinking-free editing experience.

Configuring and extending text editor with shell scripts is ridiculous.

It's in C++. I want to be able to debug and submit changes to my most used dev tool and I don't want to be touching C++.

Having said that, I still miss the visual-mode-first experience of Kakoune (most moves in Kakoune change/modify selection, while Vim/Helix have visual mode instead).

Otherwise I think Helix already leaped over Kakoune in terms of functionality and polish, because it's just easier to contribute to (in Rust).

BTW. The difference between Vim and Kakoune/Helix is not that big. For basic Vim modes in shells and other tools, I don't really notice it. `hjkl` works all the same.

I wanna know, please send links senpai.

Edit: Couple of YT videos told me everything I need to know, I guess? A bit sad it seems mostly used for "Agile".

Even relatively small, immature, niche CLI text editors start with LSP + tree-sitter support, so I'm not convinced that it would be too much for a mature OS like emacs.

Wait, what? Tagging system? What is it? 2015? Doesn't emacs have a good LSP support by now?

Nowadays with the popularity of treesitter and LSP even small-community command line text editors can have most of what IDEs do built-in.

Yes, yes. You're right. Though it does sometimes feel like it.

I might need a lot of stuff in my software. Eventually. I might need distributed database, or to to scale it out to run on multiple machines, and then maybe Raft, or reactive architecture, zero-copy IO, or incremental updates or ... or ... the list goes on and on.

Thinking too much and in particularly going with over complicated solutions from the very start because "might" is just bad engineering.

Also, even if I do need async in a certain place, doesn't mean I need to endure the limitations and complexity of async Rust everywhere in my codebase. I can just spawn a single executor and pass around messages over channels to do what requires async in async runtime, and what doesn't in normal and simpler (and better) blocking IO Rust.

You need async IO? Great. I also need it sometimes. But that doesn't explain the fact that every single thing in Rust ecosystem nowadays is async-only, or at best blocking wrapper over async-only. Because "async is web-scale, and blocking is not web-scale".

Edit: Also the "just use smol" comically misses the problem. Yeah, smol might be simpler to use than tokio (it is, I like it better personally), but most stuff is based on tokio. It's an uphill battle for the same reasons using blocking IO Rust is becoming an uphill battle. Only thing better than using async when you don't want to is having to use 3 flavors (executors) of async, when you didn't want to use any in the first place.

Everything would be perfect and no one would complain about async all the time if the community defaulted to blocking, interoperable Rust, and then projects would pull in async in that few places that do actually need async. But nobody wants to write a library that isn't "web-scale" anymore, so tough luck.

Are flake schemas in any way compatible/conflict with Nickel contracts?

Making it primarily a privacy/reproducibility issue is stretching it. It's not a rocket science to build in a docker/vm/nix and get similar results.

Since there's going to be a lot of tiling WM users looking: what's the best way to get tiling WM and all the convenience of a "full blown WM like Gnome": things like Network Manager applet, bluetooth control, audio etc. all just few clicks away.

Yes, but since Rust ecosystem went all in on async http, you'll have to use some niche http framework, and dumb CRUD code is not going to suffer too bad from async's limitations.

I really wish there was a popular and community embraced blocking http framework in Rust, to tip the scales here a bit.

Async is and probably will always be less usable than blocking Rust. It is a very, very useful mode of operating when you really need two of its biggest benefits: lightweight cooperative concurrency and task cancellation, but it comes at a big usability cost.

Rust software should use async tactically - in places where it is needed. Unfortunately handling http, which is a large part of many applications is actually a place where async has benefits. But if you plan to run your http behind nginx anyway (for TLS termination) even there using blocking http server might be a good idea.

> If you write regular synchronous Rust code, unless you have a really good reason, you don't just start with a thread-pool. You write single-threaded code until you find a place where threads can help you, and then you parallelize it,

I disagree with this one. When you work on a software project you should have the basic architecture figured out already, and main part of that is breaking your software into structurally parallel parts that can work independently. Adding ad-hoc parallelism after the fact works only for small scale things and will lead to rather accidental concurrency architecture.

Then for each part (groups of threads), figure out if it *needs* async. Between each part you'd communicate via channels or some shared data structures that rather easily can be made to work with both async/blocking code.

So e.g. an async http server, benefits from lightweight async concurrency, makes rpc-like channel-based calls to blocking IO / CPU/bussiness-logic intense workers (that don't benefit from async) where it makes sense. Each part is written in the best "type of Rust for its use-case".

Or if you need ability to cancel certain computations inside the larger framework (e.g. simulating agents etc.) you might want to nest async executor inside a blocking code.

Note: there's a lot of types of program archetypes out there (CRUD, ETL, data-intensive, embedded, frontent SPA, native mobile app) and I've noticed that many people are boxed in the type they happen to work on. CRUD applications (which are very common) are often 90% http handling-based and it might make sense to write them whole in async Rust.

It's a marketing post, but since you and me are here already:

Replace YAML with proper "general purpose" featureful configuration language like Nix (or a typed version of it: Nickel). You could do Dhall or Jsonnet, but IMO, Nix is the way to go and keeps gaining traction.

Abandon Dockerfiles, and let the containers be described in the same general purpose language (see https://nixos.wiki/wiki/NixOS_Containers ), that the cluster can build and handle the same way.

Have the cluster itself be described in the same configuration language.

Wrap it all the proper document library APIs, so the most common use-cases, are a handful of code, with ability to expand to lower level details once it needed. Hey, did I mention that we have a general purpose configuration language that makes it possible?

At the end it should be possible to `git init .`, write 10 lines of Nix code (import stdlib, import 1 node standard cluster, run a servive with hello-world application), call `deploy-this` with your cloud access key and get a k8s cluster with a hello world application behind a TLS.

Then when you decide you need more nodes, more services, you just add new lines, or rewrite existing high level ones into more detailed calls.

All of this currently required gluing tons of things together (Docker, Terraform, kops, Helm, Kustomize, ArgoCD and what not) all using different programming languages, xmls, jsons, yamls, HCLs, Dockerfiles and so and so.

I'm using Nix Flakes to support a active and medium-sized Open Source development team working on a decently-sized Rust project which includes cross-compilation for mobile devices, CI with larger integration tests, and so on. I had to find solutions to some of the same aspects as described here.

> This nix-alienation bifurcated our build environment: the CI servers built the code with nix-build, and developers built the code by entering the nix-shell and invoking cargo.

I don't anything wrong with this. Why would you throw the ability to simply use the Rust toolchain and all other tools directly?

It might be the fault of `nix-shell` which was a confusing and worked in some contrived ways. Nix Flakes have `nix develop` with an explicit "nix dev shell" construct which starts a shell that simply puts all the tools neccessary to build the project in the PATH (and possibly other relevant envs).

In our project developers simply need to install Nix and run `nix develop` (or use direnv) and from there on they mostly don't need to remember about Nix during their local work. Only when they need to touch something build/CI related they need to touch nix files, which is maybe 5% of the work, and then they can just ask for help.

The higher level tests do require a bit of thought so they reuse Nix building system, instead of fighting against it.

> Our security team chose Ubuntu as the deployment target and insisted that production binaries link against the regularly updated system libraries (libc, libc++, openssl, etc.) the deployment platform provides.

> Furthermore, the infrastructure team got a few new members unfamiliar with nix and decided to switch to a more familiar technology, Docker containers. The team implemented a new build system that runs cargo builds inside a docker container with the versions of dynamic libraries identical to those in the production environment.

I think at this point it was game over for using Nix.

Nix has a great support for building OCI (aka Docker) containers. It's great to be able to write 10 lines of Nix and just import all the required derivations from existing Nix build system and get a quick to build, nicely cacheable container that has only 35M.

But if you're not going to use it, then you turn a benefit into an extra work.

Using Nix to build inside Dockerfile is a terrible combination, eliminating lots of benefits of each done properly in separation.

> The idea of migrating the build system came from a few engineers (read Xooglers) who were tired of fighting with long build times and poor tooling.

It seems to me that it comes down to this. People didn't want to learn Nix, so they constructed bunch of incompatible ways of doing things.

Eventually there were already bunch of people familiar with Bazel so that's what they used. Had you have few engineers familiar with Nix, they would restructure things and make them work with Nix.

Some final tactical advice for people that would want to solve these problems with Rust. Use Nix Flakes, they are soo much better than old style Nix. Use `crane` for Rust - IMO the best compromise between "not rebuilding everything" and "simple wrapper over cargo". Use cachix or some shared Nix caching. Let developers work in `nix develop` shell and do their thing without thinking too much about Nix. Whenever they need part of codebase running reproducibly (fixtures for tests etc.) tactically invoke `nix build` and `nix run` . For normal Linux distros, provide OCI containers built natively with Nix. If you need raw binaries in order of preference: cross-compile to Musl (can't be done for C++), patchelf (a bit risky with C++ as OP mentioned), maintain a parallel build procedure via Dockerfile, but don't use Nix in it, and use it only to build the artifacts and nothing else.