Actually, I used ALSA without anything else for a long time until recently. I only needed to install pulseaudio because Microsoft Teams didn't work without it and I needed it for work.
I guess modern apps were developed against those APIs that they've become a necessity now?
If you want to keep using alsa with applications that otherwise only work with pulseaudio, you can try apulse[1].
When I used to use it, it worked nicely, but I started using pulseaudio around the time of its most recent release, when I got frustrated by having to tweak asoundrc to use a USB microphone, and being unable to figure out how to bump up its sample rate.
The man who designed git advises against rebasing as a default merge strategy, but the comment section is filled with comments promoting rebasing and coming up with wildly elaborate schemes to deal with its problems without addressing any of the points raised by Torvalds.
Git workflows imposed by those that don't understand git well enough is one of the most annoying things.
The people that develop git also implemented rebase and especially interactive rebase. And added options to make rebase the default for pulls. Perhaps it is you that doesn't understand Linus' points and what they do and do not apply to?
Adding an option to make something default isn't the same as making something the default. If they wanted it as the default, they'd have made it the default.
I understand rebase vs merge invokes strong feelings (including in myself), which is exactly why imposing them on others is extremely annoying. Perhaps we just do as we like, but don't presume to know better than everyone else?
Why is tail recursion better generally? I'm not familiar with FP very much, but it feels like loops more closely resemble the way computers execute them than tail recursion.
Very fair question. It may seem surprising, but loops (especially `for` loops) don't really reflect the underlying machine code very well. There is no distinct loop concept in machine code; instead, there are ordinary instructions followed by conditional jumps (if {predicate} go to {memory address} and keep on executing from there), which may or may not return to an earlier point, and will thereby conditionally repeat. Tail recursion, provided it's done in a compiler that understands tail recursion optimisation, will in some ways mirror this better than a `for` loop. (Though an old school, C-style 'do {code} while {predicate}' - note the order, and lack of any loop state variables being created or modified - is closest to the machine code).
Loops, while not bad per se, do have a lot of foot-guns. Loops tend to be used to make all sorts of non-trivial changes to outside state (it's all still in scope), and it can be nightmarish to debug errors that this may produce. Let's say you're looping over chickens in your upcoming Hen Simulator 2024, and you call a function from inside your chicken loop to update the henhouse temperature, which has a check to see if the temperature has gotten too high, which might result in a chicken overheating and passing on into the great farm in the sky, which changes the amount of chickens remaining, but wait, isn't that what you're looping over? Uh oh, your innocuous temperature update has caused a buffer overflow and hard crash. In a rare and possibly hard to reproduce case. Have fun debugging!
Generally, functional programming prefers encapsulated solutions - arguments go in, results come out, nothing else happens - which makes it easier to reason about your code. The most common replacement for loops is something like map, which just applies a lambda to each member of a list. This should make it somewhat harder to achieve the mess above (the other chickens shouldn't be in scope at all, so your temperature update function should complain at compile time).
With tail recursion, you could make a function that takes a list of chickens to update. You pop the first chicken, update it, and recur on a list of the remainder of the chickens. Because this needs to be a function (so you can recur), you have control of the arguments, and can determine what exactly is passed to the next iteration. You can't overflow the buffer, because you're passing a new 'remaining' list every time. This is also where you can get a little clever - you can safely change the list at will. You can remove upcoming chickens, you can reorder them, you can push a new chicken into the list, etc. If a hen lays an egg mid-loop, it can be updated as part of the same loop. Plus you have the same scope safety as you do with map - you can't do anything too messy to the outside state, unless you specifically bring it in as an argument to the function (which is a red flag and your warning that you're doing something messy with state).
I'm not sure LISP (which I learned while working (at Boeing Computer Services (which no longer exists))) is a good candidate (for a programming language (that would work like human languages (at least the ones I know))).
This is a good idea. This would also show someone's ability to read and contribute to existing code which is a large part of our day to day tasks. There are some that can only solve problems their way, which often means them trying to rewrite everything.
My only qualm with ESP32 is the toolchain doesn't really work with openbsd - probably not with any Unix that isn't Linux. Other than that, it's a pleasure to work with them.
I am using IDF with ESP32-C3 on FreeBSD with this unofficial port https://github.com/trombik/xtensa-esp32-elf
Zig works without external toolchain (only OpenOCD from link above).
I agree, they are pleasure to work with (documentation, code examples, JTAG+USB already on chip die) especially in comparison with Bouffalo offerings
I'm not sure how it was before 10 years ago, but in the past ~5 years my banking app has become far worse and less secure objectively. Specifically, since they moved from a hardware auth token to a digital token on a mobile app. Consumers lost Millions of dollars past year alone. The situation was so bad that this year govt passed a new law holding banks partially responsible for such scams. The attackers succeeded in emptying entire bank accounts despite multi-factor authentication (all of which depended on the mobile phone), transfer limits, etc,. "Technologists", of course, blamed the consumers for downloading untrusted apps. They also went as far as to say that Android is less secure than iOS because it's open source.
I don't know how many different ways you have tried to communicate with your bank, but in my personal experience a bank will transfer money any way you want if you send your request by fax. The fact that one platform has 2FA doesn't seems to solve a real systematic problem. And of course there's the whole ACH system on which the level of authentication is "none".
The protection against tracking Linux users have is that the software we use is opensource. We have mutt, thunderbird, claws and we know they don't track us.
We do not need Android, iOS, Mac "protections" here. We don't need overlords to protect us.
OpenBSD Xenocara