Ah yeah LibrePCB is the only one I haven't tried actually. I guess I was put off by the name - I've found that projects that focus on geeky freedom tend to not care at all about UX, but it sounds like that isn't the case here so I'll definitely give it a shot, thanks!
Have they ever fixed the usability issues? I tried it like 5 years ago and it was pretty terrible. Not as bad as gEDA or Eagle but still, worse than DesignSpark PCB for example, and the people that wrote that thought warping your mouse was a reasonable thing to do.
Eventually I found Horizon EDA which is basically the Kicad engine with a mostly fixed UX (it still has some quirks). But that's pretty much a one man project so it would be nice if Kicad actually improved.
Ah I didn't know about this. I've been fighting chrono (and the concept of time in general) trying to parse an iCal file to show a week of events... which you'd think would be easy, but it's super complicated. Maybe this will make it a little easier.
Yes, but be warned, formal software verification is proper hardcore. Complicated computer science theories, scant documentations - much of which assumes you have a PhD in the field, and in my experience it's quite a leaky abstraction. You'll end up needing to know a lot about the actual implementation of Lean to figure out why some things work and others don't, in a way that you don't need to in "normal" languages.
It's quite satisfying when it works though. Like a puzzle.
You can transform any recursive algorithm into iterative pretty easily though; just create a manual stack.
The rule definitely makes sense in the context of C code running in space. Unbounded recursion always risks stack overflow, and they probably don't have any tooling to prove stack depth bounds (you totally can do that, but presumably these standards were written in the 1500s).
The most reliable way to distribute software on Linux is still to make a statically linked binary (linking with a very old glibc is fine) and use curl | bash. But that isn't always possible depending on the language used and the app.
Seems like OBS Studio is C++/Qt, so it shouldn't be too difficult though. I've done it before in the distant past. But looking at their releases they only provide .deb for Linux, so I can understand why people would want something else.
Yeah it's probably impossible to get a perfect diff in every case, but that's irrelevant in the same way that the halting problem is true yet formal verification still exists. We don't need perfect, we need "good most of the time".
For example the "slider" problem has existed in Git forever, and apparently there are algorithms that mostly solve it (indent-new), yet Git still doesn't use them. That repo is 9 years old. I can't remember what led me to that but I think it was one of the new VCS's saying they do well on that benchmark (can't find any reference to it now though).
Pijul should also give better diffs in theory because it actually tracks lines as objects, so it has more information to work with. In the first example in diff-slider-tools it would know the difference between /* and /*. I haven't actually tried it though.
There are also a few semantic diffing tools that understand syntax that could be integrated - notably Difftastic and Diffsitter.
Yeah even though it definitely has flaws (awful CLI, dumb diff/conflict algorithms) and half-arsed parts (submodules, LFS), it really is pretty great software.
Still, I'm hopeful for the next generation VCS's - Pijul, Sapling and Jujutsu.
I feel like they could ask way more interesting questions. Probably the only really interesting thing here is people's top complaints about Rust, which is to be fair a really great list.
I would really love to see something similar for other languages. Imagine if you could see ranked pros and cons for every language!
I assume he meant Linux on x86 laptops, where I can confirm battery life is atrocious and support for random display things is also pretty bad. My laptop still wont do more than 30 Hz over HDMI (works fine with DisplayPort though).
The classic "I had it hard so you should too" mentality. I think it fundamentally comes from an animal desire for fairness - it isn't fair that these old geezers had to put up with C shooting them in the feet at the drop of a bracket, while the new kids on the block get friendly (usually) compiler errors instead.
But I think if you don't recognise that instinct in yourself and overcome it then you have failed as a human.
I'll always remember the pushback to making xfree86 easier to configure (yes I'm old). Back in the day you had to edit a stupid text file to tell X that your screen could display 1024x768 and your mouse had three buttons. Then some upstarts came along and make it automatically detect that. The absolute cheek! Our ancestors have been practicing xfree86config since before you were a wee bebe! Etc. etc.
I would consider it still horribly broken if you have to use a special hotkey to get sane behaviour.