Simplifying `git rebase -i` is a great idea, but unfortunately, that does not match my workflow.

I always keep an history of my branches. For example, when I develop a feature, the first version of the branch is `myfeature.1`, then `myfeature.2`, and so on. This is useful because I can retrieve an old version when something behaves differently in a newer one. (And no, `git reflog` will not help)

This has saved me multiple times. For example, I can determine that a problem was introduced between `myfeature.58` and `myfeature.59`. If the "feature" contains 15 commits, I do:

    git range-diff myfeature.58~15..myfeature.58 myfeature.59~15..myfeature.59

I don't want all the branches containing a commit to be rebased automatically (I already try using tags for old versions instead, but this does not quite fit).

What is unclear to me is why the decision to use a Point instance as a value or as a reference is made in the class definition rather than by the caller.

> Point[] point = new Point[10];

For the same class, I might need an array of values in one place and an array of references elsewhere within the same codebase.

> ABSTRACT

> The received wisdom suggests that Unix’s unusual combination of fork() and exec() for process creation was an inspired design. In this paper, we argue that fork was a clever hack for machines and programs of the 1970s that has long outlived its usefulness and is now a liability. We catalog the ways in which fork is a terrible abstraction for the modern programmer to use, describe how it compromises OS implementations, and propose alternatives.

> As the designers and implementers of operating systems, we should acknowledge that fork’s continued existence as a first-class OS primitive holds back systems research, and deprecate it. As educators, we should teach fork as a historical artifact, and not the first process creation mechanism students encounter.

Manually installing an app via adb must, of course, be permitted. But that is not sufficient.

> Keeping users safe on Android is our top priority.

Google's mandatory verification is not about security, but about control (they want to forbid apps like ReVanced that could reduce their advertising revenue).

When SimpleMobileTools was sold to a shady company (https://news.ycombinator.com/item?id=38505229), the new owner was able to push any user-hostile changes they wanted to all users who had installed the original app through Google Play (that's the very reason why the initial app could be sold in the first place, to exploit a large, preexisting user base that had the initial version installed).

That was not the case on F-Droid, which blocked the new user-hostile version and recommended the open source fork (Fossify Apps). (see also this comment: https://news.ycombinator.com/item?id=45410805)

Comments URL: https://news.ycombinator.com/item?id=45736479

Points: 1516

# Comments: 629

No, it's not.

Comments URL: https://news.ycombinator.com/item?id=45428832

Points: 109

# Comments: 122

Yes, sorry, I did not mention it.

So if you want to use DNS over HTTPS on Android, it is not possible to provide a fallback.

Btw, I really don't understand why it does not accept an IP (1.1.1.1), so you have to give an address (one.one.one.one). It would be more sensible to configure a DNS server from an IP rather than from an address to be resolved by a DNS server :/

By making the Back button larger and more prominent instead, participants would be able to spot the button four times faster. I suggest to reduce the size of the Send button.

Comments URL: https://news.ycombinator.com/item?id=43671036

Points: 7

# Comments: 1

AI is also helpful to parse the story about how AI is helpful.