I’m sorry but no. Maybe it’s my ignorance of TM’s, but O(log n) doesn’t read all input by definition. It doesn’t follow that it is therefore _independent_ of the input size.
What makes a/your TM special that this is the case?
I don’t mean to take too much of your time though, maybe I’m too dumb for this.
Edit: I can sort of see how O(log n) is impossible or at least O(n) in a TM, but to reduce it to O(1) makes no sense to me
There is nothing wrong with apt and dpkg. It’s just that Ubuntu infected apt with their poison by making ‘apt install firefox’ install a snap package and they’re poised to do it with more packages (maybe they already have).
I personally can’t think of anything software related that Ubuntu provides over Debian for normal desktop users. Only the Ubuntu 6-month release schedule can be a bit nicer.
It is a good idea to install security updates from unstable since they take extra time to reach testing and the security team only releases updates to unstable
It's a matter of risk that I'm paying for to avoid, not absolute quality. I would not wager my life on a random doctor in Africa even while 90% of doctors there might be more skilled than in London. I'm paying to eliminate the risk of encountering the worst 10%. In that light, yes I would personally expect the doctors in London to be able to avoid the worst outcomes better on average. Whether that's warranted is another discussion.
This goes for loads of stuff. I would wager a $30 meal to be fresher than a $5 meal on average. I'm not saying there aren't any $5 meals that are fresher than some $30 meals, but just that the $30 has a lot lower chance to make me sick.
This is what api's are for. A telemetry service asks each service for the specific data, combines them and outputs the combined metrics. This doesn't really break a barrier, but it does increase overhead.