https://doc.rust-lang.org/rust-by-example/scope/lifetime/sta... says:
> As a reference lifetime 'static indicates that the data pointed to by the reference lives for the remaining lifetime of the running program.
563 karma · joined February 19, 2014
> As a reference lifetime 'static indicates that the data pointed to by the reference lives for the remaining lifetime of the running program.
[0]: https://github.com/lichess-org/fishnet [1]: https://lichess.org/
It sounds like the broken window fallacy.
Now consider F'. F' is like F but we limit N to a fixed constant -- for example we say that N must be ≤ 2³². In this case, _for every input_ F' returns the result after at most (2³²)² = 2⁶⁴ instructions. Its time complexity is O(1). Note that O(2⁶⁴) = O(2⁶⁴ * 1) = O(1).
---
Technically, all implementable-on-real-machines algorithms either return after O(1) instructions, or loop after O(1) instructions. But being O(1) doesn't imply being fast in practice.
You might be also interested in reading about galactic algorithms: https://en.wikipedia.org/wiki/Galactic_algorithm.
I crafted a oneliner that `tail -f`'d the logs and played a note for each response. I believe there were different notes for different HTTP status codes but it was years ago so the details flee me.
What are they?
[0]: https://github.com/lichess-org/fishnet [1]: https://lichess.org/
In my case it's `"cpuManagerPolicy": "none"` and I suppose you're using `"static"` policy.
Well, TIL. Thanks!
FWIW, `taskset` uses the same syscall as `nproc` (according to `strace`).
What I tried: I created a "Burstable" Pod and run `nproc` [0] on it. It returned N CPUs (N > 1).
Then I created a "Guaranteed QoS" Pod with both requests and limit set to 1 CPU. `nproc` returned N CPUs on it.
I went back to the "Burstable" Pod. It returned N.
I created a fresh "Burstable" Pod and run `nproc` on it, got N again. Please note that the "Guaranteed QoS" Pod is still running.
> Pods with Guaranteed QoS will have exactly the number of CPUs they asked for, no more or less
Well, in my case I asked for 1 CPU and got more, i.e. N CPUs.
Also, please note that Pods might ask for fractional CPUs.
[0]: coreutils `nproc` program uses `sched_getaffinity` syscall under the hood, at least on my system. I've just checked it with `strace` to be sure.
This is new to me. What is this… behavior? What keywords should I use to find any details about it?
The only thing that rings a bell is requests/limit parameters of a pod but you can't change them on an existing pod AFAIK.
What your parent described is a type of trusted timestamping and one doesn't need blockchain to implement it.
It is great for a cheat sheet to be on a single page. It makes ctrl+f searching useful and quick.
That's not true.
> This makes it difficult for commercial use.
Yeah, too bad it's so difficult for companies to use Linux commercially. /s
Data can be lost.
I put a few files on IPFS some time ago. That files are no longer accessible because I stopped hosting them.
> Site will never go down
As long as there is a node hosting the data you're looking for. So it can go down.
Or can one install an arbitrary CA and limit it to `*.example.com`?
I can imagine that a good platform for making "home-cooked apps" would be beneficial both to Apple and to buyers of their products.
I believe Shortcuts was a move in the right direction.
> With respect to the server software available under the Bitwarden License, production use requires a separate commercial agreement with Bitwarden
> The right to use the software in a production environment, or environments directly supporting production, requires a paid Bitwarden subscription
> The Bitwarden License does not qualify as an open source license under the OSI definition
[0]: https://github.com/bitwarden/server/blob/master/LICENSE_FAQ.... (permalink → https://github.com/bitwarden/server/blob/f848eb247767fbba8a4...)
Let's say a company's app has a security vulnerability. Let's consider 2 scenarios: (A) using Angular vs (B) using an internal framework.
From engineering perspective it doesn't matter if it's (A) or (B). It's not like the internal framework will be perfect and bug-free.
In both cases it is company's responsibility to patch their app. In case (A) they can fix it in their internal fork of Angular; or fix it upstream; or update Angular to an unaffected version. In case (B) they have to fix their framework.
You stated that:
> When a company decides to use Angular (for example), they're also deciding to jump on the rat-wheel that is constant upgrades to the next version.
> Meanwhile, that vanilla app will just keep working in perpetuity.
and I disagree with it.
If a company doesn't care about security, they can have Angular "working in perpetuity" as well as their vanilla app.
If they do care about security, their vanilla app will not (securely) "work in perpetuity" since it will need a fix sooner or later.