Sir, I estimate the project will be completed in 135 days and 11 hours.

I love that the EU is cracking down on tech, but I also wish the US government could get in on that awesome rake.

I’m not in the market, but I’ve actually had similar thoughts of building a project on top of NixOS that’s focused on self-hosting for homes and small businesses. I recently deployed my own router/server on a BeeLink mini PC and instead of using something like OpenWRT, I used NixOS, systemd-networkd, nftables, etc.

DM me if you want to discuss more. I think the idea has potential and I might be interested in helping if you can get the business model right (even if it just ends up being some FOSS thing).

Sorry if this sounds like a conspiracy theory, but how do we know that BlueSky isn’t padding their stats with internal bots? I could see this being a viable strategy to attract users and overcome the social network bootstrapping problem.

Not exactly. I’m talking specifically about being able to call axum::serve with non-Send futures.

I’m not sure what tokio (or axum) can do to avoid the trait bounds. Would it makes sense to provide a “share nothing” runtime implementation that can be injected at startup? I wonder how the intermediate layers (e.g. axum) would indicate that futures are usable by a more generic runtime which may or may not need Send + 'static.

Without some way to write generic code for either runtime, the whole tokio ecosystem would end up bifurcated by this choice of runtime.

Rate-limiting could also be applied at the federation level, but I’m less sure of what the implementation would look like. Requiring filters on a per-account basis might be resource intensive.

Why resort to an expensive decentralized mechanism when we already have a client-server model? We can just implement rate-limiting on the server.

I think there’s a pretty big overlap of gamers and programmers who use Windows or WSL because they don’t want to have to dual boot.

Yea I agree. Good UX is a lot of work, and I think FOSS projects rarely prioritize it. Even good documentation is hard to come by. When you write software for your own use case, it’s easy to cut UX corners, because you don’t need your hand held.

And good UX for a programmer might be completely different from good UX for someone that only knows how to use GUIs. E.g. NixOS has amazing UX for programmers, but the code-illiterate would be completely lost.

I believe that the solution is “progressive disclosure”, and it requires a lot of effort. You basically need every interface to have both the “handholding GUI” and the underlying “poweruser config,” and there needs to be a seamless transition between the two.

I actually think we could have an amazing Linux distro for both “normies” and powerusers if this type of UX were the primary focus of developers.

It seems irrelevant whether this person is using encrypted channels if they failed to maintain anonymity. If they distributed material and leaked any identifying info (e.g. IP address), then it would be trivial for investigators or CIs to track them down.

Writing poetry => meth + crack???

How Linux Fanboys see Linux:

I think it mostly has to do with how coupled your code modules are. If you have a lot of tightly coupled modules/libraries/apps/etc, then it makes sense to put them in the same repo so that changes that ultimately have a large blast radius can be handled within a single repo instead of spanning many repos.

And that’s just a judgement call based on code organization and team organization.

Apparently it’s hard to get hired in software. Meanwhile, some of the worst software ever made is being written today. Have you tried using literally any software recently? We’re in this “barely good enough to function while being heavily supplemented by tech support” phase. I guess capitalism breeds incompetence as long as it’s still profitable?

But quiche is tasty!

Gleam is cool. I wrote some services with it to see if I wanted to use it for more projects. It seemed like a good option because it would be easy to teach.

Things I like:

• fast build times (I only tested small apps though, under 2000 LOC)
• strong static types
• runs on the BEAM
• easy to learn
• pattern matching
• immutable + structural sharing
• currying (with parameter holes)

Things I don’t like:

• no re-exports
• it’s possible to have name collisions between packages; authors have a gentleman’s agreement to always create a top-level module with the same name as the package
• some standard library APIs seem missing or immature (it’s still pre-1.0)
• it can be hard to get good performance out of idiomatic code for specific tasks (see immutability)
• no format strings; best you can do is "Hello, " <> name. It starts to get cumbersome
• parsing/serialization is all quite manual boilerplate; there’s nothing quite like serde
• no field/argument punning
• no method syntax; you just have to scan the docs to figure out what functions can be used with a given type
• you can’t define the same variant name twice in the same module; I believe this is a limitation in how the types are translated to Erlang records
• you can’t call functions in pattern matching if guards
• you can’t have dependency cycles between modules in the same package
• hard to write FFI correctly; you lose all the comfort of types

I think it would help narrow things down if you described what kind of website you want to build.

They explicitly said they want to build a website. Not that you can’t go far with a Java server + HTML(X) but JS is the de facto standard for interactive websites.

It’s almost like these languages were designed to solve different problems.