abjKT26nO8
Joined 10 years ago
Karma
730
Submissions
262
Member since
Mar 19
Recent submissions
Comment · 6 years ago
No, one cannot. Modern medicine is part of our environment. Failure to make use of it is a failure to adapt to the current environment which lessens the disadvantage of individuals with higher risk of cancer, who may have other advantages letting them thrive in this environment.
Comment · 6 years ago
Jira. My only pet-peeves are:
* it breaks native keyboard shortcuts. After disabling the shortcut overrides in settings, "/" is a NOP (which is weird, since disabling the overrides worked in Confluence)
* the markup is non-standard (but I can live with it)
* sometimes it will log me out when I want to post a comment and all of what I wrote in the comment box gets lost
Comment · 6 years ago
It only does full-exact-word searches. If a word is written in a slightly different form or you write only a part of it, it won't find it.
Comment · 6 years ago
On the other hand, Swift changes so frequently that book authors teaching the language can't keep up with Apple to write up-to-date books. By the time a book comes out covering version N, we're a couple months away from version N+1. In this situation I can't trust I will be able to buy a book, learn the language and become comfortable with it before there is a new version with major changes. It's a very moving ground.
As for performance, it would be cool if every single thing wasn't behind an atomic reference counter, making it slower than even garbage-collected Go: https://media.ccc.de/v/35c3-9670-safe_and_secure_drivers_in_... (the relevant part starts at 33:06).
Comment · 6 years ago
I have terminal bound to "<super>+<enter>". From there I run "cat > title.txt" or "cat >> title.txt" and type whatever I want to save. It's as frictionless as it can be.
Comment · 6 years ago
> Yes, in theory all the people who refuse to reproduce will be gone and are replaced by the children of those who want to reproduce.
Those, who do want to reproduce, will also be replaced by the next generations. Natural selection doesn't select individuals, it selects genes. And your genes are well-represented in the rest of the population.
Comment · 6 years ago
Just because an average user isn't able to quite put a finger on their frustration and its source, doesn't mean it isn't there. Studies show that even though users often won't be able to see that it's the performance of the program that is infuriating, they will be more nervous using it anyway and will prefer to use a faster alternative.
When phones with touch screens entered the market, we'd often put up with the latency of touch interaction, but these were irritating nevertheless. Then the early iPhones showed how low the latency could be and how much more pleasant using it is. iPhones degraded in this regard since then and Android phones didn't catch up even to the current iPhones. And I'll never use an Android, one of the main reasons being exactly this: latency.
Comment · 6 years ago
> the Win10 calculator somehow needs a loading screen
This right here made my day. No further comment on the state of technology today needed.
Comment · 6 years ago
The original Emacs was written for Multics at a time when people outside of Bell Labs were largely unaware of the existence of Unix[1]. It also doesn't follow the Unix philosophy of making small CLI utilities composed with pipes. As I understand it (though I haven't used it), Acme is extended with external programs which communicate through pipes just like the traditional Unix utilities.
Comment · 6 years ago
I mostly agree with you and I'm not going to get even near Snaps and Flatpaks.
However, ignoring the aspect of software distribution, wouldn't you agree that the approach taken by the Linux desktop today is deficient security-wise? For example, I would like to be able to give mbsync (or Thunderbird or whatever) my IMAP password without giving it to any other program. So I don't want to store it in mbsync's config file in plain text. Neither will I use gnome-keyring (or any other keyring) because it doesn't have any kind of "program authorisation". Any program can just spawn a new "secret-tool" process and get my credentials from gnome-keyring.
I've been thinking for a while about implementing a keyring which runs as a daemon with SUID of a dedicated user and checks which program sends requests to it, using /proc/pid/exe, but I'm not sure if it's a secure source of truth: how e.g. namespaces affect what's visible in /proc/pid/exe. I know you've been developing himitsu[1]. Have you thought about this problem in that context?
Comment · 6 years ago
Sounds dystopian.
Comment · 6 years ago
> First, this analysis was done on Arch Linux, a source-based distribution. Since you know at compile time what your environment is, I would expect the benefits to be smaller. And of course, this means you're willing to do a lot of recompiles. I'd like to see analysis done on more traditional (& common) binary distros.
Arch Linux is not Gentoo. And AUR is only a secondary method of installing software. So I'm not sure what you mean.