> constraining to invert is not sufficient in my opinion
Eh. Doing green/red text color with default background, maybe inverted works amazing for me. In fact, I'd say that every sensible colour scheme for a terminal should have as the default foreground/background colours something that is more or less contrasting against every other explicitly named colour, including black and white (I personally have #212121 on #EEEEEE).
Regular expressions as we basically now them today were made for ed. In that context, '$' absolutely had to match the terminating newline or it would've been completely useless.
Well, if you're fine with using 3-year old versions of those libraries packaged by severely overworked maintainers who at one point seriously considered blindly converting everything into Flatpaks and shipping those simply because they can't muster enough of manpower, sure.
"But you can use 3rd party repositories!" Yeah, and I also can just download the library from its author's site. I mean, if I trust them enough to run their library, why do I need opinionated middle-men?
This was a pre-emptive rebuttal to the non-answer "well, you're not limited to the official repositories, so apt/yum/etc. is absolutely fine, use only it" I always get unless I include this very rebuttal.
> then you can pitch in with distro packaging. Volunteers are always welcome.
Or I can just do something more useful and less straining?
You're saying it's _rare_ for developers to want to advance a dependency past the ancient version contained in <whatever the oldest release they want to support> is?
Speaking for the robotics and ML space, that is simply the opposite of a true statement where I work.
Also doesn't your philosophy require me to figure out the packaging story for every separate distro, too? Do you just maintain multiple entirely separate dependency graphs, one for each distro? And then say to hell with Windows and Mac? I've never practiced this "just use the system package manager" mindset so I don't understand how this actually works in practice for cross-platform development.
Like, seriously. It's impossible to run Erlang/OTP 21.0 on a modern Ubuntu/Debian because of libssl/glibc shenanigans so your best bet is to take a container with the userspace of Ubuntu 16 (which somehow works just fine on modern kernel, what a miracle! Why can't Linux's userspace do something like that?) and install it in there. Or just listen to "JuST doN'T rUN ouTdaTED SoftWAre" advices. Yeah, thanks a lot.
Honestly, sometimes I just want to mark all files on a Linux system as executable and see what would even break and why. Seriously, why is there a whole bit for something that's essentially an 'read permission, but you can also directly execute it from the shell'?
No you can't. If a user can read something, it can execute it. The only thing where it matters is setuid applications where the setuid bit allows the user to run an application as someone else. But it's already a separate permission bit, and frankly, the whole setuid idea turned out to be quite a high-maintenance design in the end, with lots of additional features heaped on top of it to help mitigate the worst vulnerabilities.
It's small, but not unnoticeable... depending on the exact size of the workload and the amount of computation per element. In fact, for huge arrays it may be beneficial to have structs packed if that leads to less memory traffic.
Do I understand it correctly that the logic is that if timestamp B is above timestamp A, but the difference is more than half of the unsigned range, B is considered to happen before A?
Yes. When the timestamps wrap it's fundamentally ambiguous, but this will be correct unless the timestamps are very far apart (and the failure mode is more benign: a really long time difference being considered shorter is better than all time differences being considered zero after the timestamp wraps).
reply