Source? I guess you're thinking of long tap → Airdrop, but that essentially shares a link to the Appstore via Airdrop. You're not transfering the app itself.
While this is interesting and impressive, I kinda relate more to OP's link of more "normal" trees. Going through the list gives me a feeling how many cool trees there are all over the place.
Mostly the latter, but a lot of tools are so slow the former actually becomes a problem, too. Valgrind is a great example. For realtime applications, Valgrind and friends are pretty much a non-starter.
To your point about profile results, any profiler that adds more than a couple percentage points at runtime basically destroys the profile results (less than one percent is the acceptable margin, for me). Adding 50% is just laughable, and at the time I looked that was the best available option.
At the time, I was trying to profile ML models and some tooling surrounding them. There are several reasons you want your profiler to be low overhead:
1. If the profiler does a ton of useless shit (read: is slow), it has many deleterious effects on the program being profiled. It can evict entries from the CPUs ICache, DCache, and TLB entries to name a few, all of which can cause huge stalls and make something (such as a scan over tensor memory, for example) many times slower than it would be otherwise. You become unable to reason about if something is taking a long time because it's doing something stupid, or if the profiler is just screwing up your day. Introducing this kind of noise to your profile makes it nearly impossible to do a good job at analysis, let alone optimizing anything.
2. Somewhat unrelated to performance, but, you really want to know more than "this function take up a lot of time", which is basically all sampling profilers tell you. If you look at a flame graph and it says "fooFunc()" takes up 80% of the time, you have no idea if that's because one call to "fooFunc()" took 79% and the rest were negligible, or if they're all slow, or just a handful. That is key information and, in my mind, basically makes sampling profilers unsuitable for anything but 'approxamizing'. Which can be useful, and is often good enough, but if you need to optimize something for real, a sampling profiler exhausts it's usefulness pretty quick.
Anyways .. there are some random thoughts for you :)
It's correct in English. [1] The family of Thomas Mann were representatives of German bourgeoisie. From [2] (machine translated): "Thomas Mann and Heinrich Mann, as well as members of the following generation, became writers; in their numerous, often autobiographically influenced literary works, they explored themes such as the history of the German bourgeoisie and educated middle class, as well as its decadence. Through this, the family itself came to be seen by the public as a symbol and late representative of that very social stratum."
In German it is called "Bürger", yes. Burgher is some weird English spelling of the original french one, and I don't think it applies in any reasonable way to Thomas Mann. In German it really just means "Citizen".
It meant an upper middle class urban citizen, while "Kleinbürger" was their lower middle class counterpart. Buddenbrooks was all about Bürgers, their history and lifestyle. Mann was a member of that class or even of its upper crust, the patricians.
This isn’t hard to understand. “Burgher” is a perfectly legitimate translation of “Bürger” as in “bürgerlicher Mittagstisch”, “Der Bürger duldet nichts Unverständliches im Haus”. “Citizen” is a perfectly legitimate translation of “Bürger” when it comes to “Bürgeramt” or “Weltbürger”.
Have to disagree, "technically" yes, both are interpreted languages, but the ergonomics and mental overhead of doing certain things are wildly different:
In python, doing math or complex string or collection operations is usually a simple oneliner, but calling shell commands or other OS processes requires fiddling with the subprocess module, writing ad-hoc streaming loops, etc - don't even start with piping several commands together.
Bash is the opposite: As long as your task can be structured as a series of shell commands, it absolutely shines - but as soon as you require custom data manipulation in any form, you'll run into awkward edge cases and arbitrary restrictions - even for things that are absolutely basic in other languages.
> In python, ..., calling shell commands or other OS processes requires fiddling with the subprocess module, writing ad-hoc streaming loops, etc - don't even start with piping several commands together.
The subprocess module is horrendous but even if it was great bash is simpler. I just think about trying to create a pipe of processes in python without the danger of blocking.
So far updates work fine. It may change eventually, but as I noted in another comment, it's been 4 years, and none of the updates have required a TPM yet.
That requires the remote machine to be configured to SSH into your local machine. In the scenario where OP's project is useful (SSH to foreign machines) I might not want that.
On the other hand, if the remote machine is mine, it will have my config anyway.
There should be some way to mount a local directory onto a remote system without requiring the remote system to log in to the local system. SSH provides a secure bidirectional communication channel between the two systems. While we normally use sshfs to mount a remote directory to the local system, why should the reverse be impossible? Besides, you could also use NFS over SSH or TLS.
reply