Actually if you read the links in the 'What's new' section, most of them start with the reason why they needed to break the backward fucntionality for this feature.
From my understanding that was due to a long-running design philosophy clash between the systemd people thinking Docker should be using systemd primitives to manage things like unit startup/shutdown/etc., and the docker people wanting to use their in-house implementations so as not to depend on systemd (and thus rejecting PRs trying to change docker behavior to use systemd). I don't think it's fair to use that as an example of toxic behavior on either side, they each had their motivations, and a consensus needed to be reached for both projects to proceed. From what I can tell that debate seems to be old news these days and I haven't seen as much clashing between those teams. I am not a developer on either side though, this is just from the perspective of a user who follows the Github issues.
And what drove my attention to the "I don't accept systemd patches" was the need to run systemd in docker container. Which by digging a litte bit about I found it will be possible in non priviledged mode, but docker didn't want to merge it.
I don't see anything philosiphical with that, it's just plain refusal to cooperate in any way with a potential compentitor.
This was several years ago, now this is not an issue anymore, but it's still telling of the toxic corporate culture Docker had back then.
I think the reasoning was that you shouldn't need systemd in docker because the point is for docker itself to containerize each service unit, and use something like docker-compose to manage multiple units. Personally I think that's an aggressive but valid stance because by allowing systemd in docker they'd get a ton of low quality docker images floating around where they launch multiple services within containers, which is against the "do one thing per container" philosophy.
Now that docker has proliferated and the standard practices are clear and well documented, there's less of a danger allowing people to do messy things in their docker containers.
Sure but what ws their recommended way instead of putting systemd in the image, just use supervisord. Not even comparable.
Anyway , the past is the past. Docker were clearly wrong in their decision to put off systemd inside containers, and was most probably for political reasons because it was very very requested feature.
I disagree that it was clearly wrong, because supervisord is a vastly simpler service manger than systemd. They wanted to put organizational pressure on people to move away from managing multiple units within a single container with an extremely complex octopus of a unit manager like systemd, and they arguably succeeded at that goal. (Even if it caused short-term discomfort for people who wanted to rely on systemd features within containers.)
I don't understand why the bug fuss about M1. After all M1 is 5nm CPU. AMD Renoir is better than Intel for the same reason, it's 7nm while Intel can't get below 10nm yet.
So while M1 is probably a great CPU I expect its advantages will mostly vanish once AMD and Intel move to 5nm also.
Thanks for pointing this out to me, I did not know about it, is it new? I remember a few years ago when I would start "Disks" in Ubuntu it would open the "baobab" tool. Might be just an unfortunate naming colision...
I just tried it and got some crazy high numbers for a VM image mounted on an external USB drive. Something seems off about how it is assessing caching.
ASIC stands for application specific, and since thei IC is application specific - used only in certain hardware along certain software, it's kind of correct to call it ASIC.
> but it still boggles the mind how these enormous companies, used to throwing their weight around in other tech spaces, keep getting video games so wrong.
This sounds naive IMO. It's not that they are getting it wrong. They are simply throwing their weight into changing it into direction that favors them.
I get the code is data thing, but I don't really find it that much useful. And there is a good reason most languages don't allow it - other people :)
The unless example is a good one. So while you can trivially implement 'unless' in lisp, most probably in a large code base, you'll en up with 'unless', 'if-not' and depending on how creative others are probably also 'negat-if'.
You have the same problem in any language when you start scaling up to larger team sizes (or multiple teams). If they don't bother reading the docs or existing libraries, they're likely to reinvent the wheel over and over. The solution is, unfortunately, more social than technical. You have to be deliberate in selecting what goes into the common libraries, and be deliberate in code reviews to make sure junk like that doesn't get created and widely used when an existing solution already exists.
Agreeing, I'd point out that C++ templates are Turing complete (and now they've added constinit and friends). That can certainly result in bad code, but it also enables very good code as well (ex the Eigen library). Python objects can be monkey patched at runtime - a powerful ability, but trivial to misuse.
Certainly the design of a language should facilitate and even actively encourage writing good code. Attempting to solve systemic organizational or educational issues with it is probably counterproductive though.
Since you mentioned the Eigen library: I'm sure it's an extremely elegantly designed library, and I know it's super powerful and efficient. But for someone like me, with fairly limited C++ experience, it was absolutely painful to learn and understand how to use it. Even though it's fairly well documented, I had to really dig through the sources whenever bugs arised. Understanding all these templating abstractions was a huge pain.
'unless vs 'if-not vs 'negat-if is "just" a naming issue, it's the same in any other language wrt functions. IME a bigger issue is jumping between code and data, both for the writer of the macro (viz macros to ensure that a form is evaluated at most once) and the user (is this thing a macro? Is this form going to be evaluated or quoted?).
The benefit is being able to extend the language. Context managers in Lisp are just macros. Clojure's spec and async are macros.
For sure, the joke about blowing your whole leg off (as opposed to just your foot) applies, but it's the same for concurrency, distributed systems, cryptography, etc. The answer isn't to ban it, it's to exercise more care in the construction of these abstractions so that mere mortals can use them safely.
imo this is not only a problem in a singular large code base, but also libraries.
I know not everyone likes Go, but I've noticed that i find it super easy to dig into some open source dependency and navigate it, because in some ways Go is the exact opposite of lisp. In terms of the language not allowing a lot of flexibility at least.
I never found navigating foreign java code bases that easy because this project uses spring for dependency injection, that one does some other class loader magic etc, streams, no streams etc. pp.
That said, I do think LISP is cool, but I think it ends up being a right tool for the job kind of thing. I could imagine LISP being nice for things like game engine scripting etc.
> most probably in a large code base, you'll en up with 'unless', 'if-not' and depending on how creative others are probably also 'negat-if'.
In Clojure, "if-not" is part of clojure.core (the equivalent of java.lang in Java), so a decent programmer would almost certainly be familiar with it; and if not, it would be pointed out at a code review.
People use Lisp for a while, so the obvious simple ideas were probably already noticed and implemented.
With less frequent things, implementing the same thing twice under two different names is a problem that happens regardless of the language.
Thank god you did! I’ve seen too many “make it easier for normal people” projects ruined by trying to appease people that have muscle memory for the old way.
Luckily bit doesn’t do anything that would prevent someone from using git on the same repo. You can co-exist.
I’ll make this prediction based on decades of observations:
1. There will be many projects like this.
2. Eventually one will win out and the others will fade.
3. The winner will be the one that focused on a particular audience AND successfully ignored so-called experts that didn’t see the need for such a project.
4. After one tool wins out, the nay-sayers start to adopt it. Forums like HN get flooded with posts about how “I wish I had tried it sooner”.
But seriously... if you don’t need this kind of tool do the other 98% of the world develop it in peace.
