giovannibajo1's comments

> Version history. For projects using SemVer, frequently changing major version numbers is an obvious red flag. Note that many old, stable projects don’t use SemVer.

This matches my experience. Obviously it's impossible to generalize without making mistakes, but I started to notice that projects that loudly talk about their use of SemVer often break compatibility. In other words, it seems like they think SemVer is a way to liberate them in breaking APIs because now they have a way to tell the world about it explicitly, and so nothing can go wrong.

Ecosystems that have adopted SemVer massively do not value backward compatibility (npm comes to mind), and their package managers often have to provide solvers for complex dependencies; users can get to a corner where they must upgrade something but they can't because it depends on something else that bumped the major version and now the interfacing code has to be rewritten.

Go is an ecosystem that values backward compatibility a lot. They are using SemVer as well now but on the other hand they say that modules shouldn't really bump major version that often, if at all (which in turns makes me question whether adopting SemVer has been a good idea, or a compromise that they had to take to concede something to the community subset that was pushing for a more standard package management solution).

I think Qt is a project that uses SemVer (before it was named so!) in the right way. They break major version every 8-10 years, and they struggle a lot to make sure not to do that often. In C++, it's not even easy because of include files and ABI, but they manage to keep the ABI stable across all minor version upgrades, so that you can upgrade a minor of Qt without even recompiling your software using it.

Because in the standard lock screen you see notifications. iOS switches from the lock screen to the numpad when it detects a facemask, or after a timeout from the unlock gesture (swipe up).

> I think, that instead of vendoring, Debian should instead adopt a different packaging policy, which would allow them to package whole dependency trees into a single package.

I'm not sure how this is different from what I call vendoring, and I think this is indeed the solution.

In Go, there's "go mod vendor" which automatically creates a tree called "vendor" with a copy of all the sources needed to build the application, and from that moment on, building the application transparently uses the vendored copy of all dependencies.

In my ideal world, Debian would run "go mod vendor" and bundle the resulting tree a source DEB package (notice that the binary DEB package would still be "vendored" because go embraces static linking anyway).

If the Debian maintainer of that application wants to "beat upstream" at releasing security fixes, they will have a monitor on those dependencies' security updates, and then whenever they want, update the required dependencies, revendor and ship the security update.

What I totally disagree with is having "go-crc16" as a Debian package. I'm not even sure who would benefit from that, surely not Go developers that will install packages through the go package manager and decide and test their own dependencies without even knowing what Debian is shipping.

No they won’t, if not in very basic cases that can’t be generalized as a rule of thumb solution. Your suggestion bargains correctness with performance.

If you know you are reading aligned memory and you need to do it with a single word memory access, then you need to use intNN_t* and use htonl or similar functions to byteswap. There’s no way around it.

That’s fine, GCC on sparc will generate the sequence to do an unaligned read with the right endianess. If that means reading bytes and shifting them, so be it.

> and there’s really good man page documentation now

Well, my pet peeve has always been git-tag. When I discuss about technical documentation, I actually use man git-tag as a reference of what NOT to do.

The summary (called NAME in manpages):

       git-tag - Create, list, delete or verify a tag object signed with GPG

... which might make sense but is already confusing to a beginner because of its reference to GPG (are all tags signed with GPG?).

But DESCRIPTION is actually the best:

       Add a tag reference in refs/tags/, unless -d/-l/-v is given to delete, list or verify tags.

       Unless -f is given, the named tag must not yet exist.

       If one of -a, -s, or -u <keyid> is passed, the command creates a tag object, and requires a tag message.
       Unless -m <msg> or -F <file> is given, an editor is started for the user to type in the tag message.

       If -m <msg> or -F <file> is given and -a, -s, and -u <keyid> are absent, -a is implied.

       Otherwise, a tag reference that points directly at the given object (i.e., a lightweight tag) is created.

       A GnuPG signed tag object will be created when -s or -u <keyid> is used. When -u <keyid> is not used, the
       committer identity for the current user is used to find the GnuPG key for signing. The configuration
       variable gpg.program is used to specify custom GnuPG binary.

       [... spoiler: it doesn't get any better]

So this should be a description that makes beginners understand git-tag.

Instead, it is a sequence of unrelated sentences that merely describes functionalities in response to command line arguments, in a very convoluted way (I think "If -m <msg> or -F <file> is given and -a, -s, and -u <keyid> are absent, -a is implied" is a little gem).

This is how I would write it:

       Create, view, and delete tags.

       By default, it creates a new “lightweight” tag, which is simple a reference to the current commit (eg: “git tag v1.2”). If you specify “-a”, a “annotated” tag is created instead; an annotated tag is still a reference to the current commit, but also remembers the date in which it was created, who created it, and optionally saves a message associated to the tag (like a “commit” message for the tag).

       Annotated tags can also be cryptographically signed with GnuPG, using “-s” instead of “-a”.

       You can also tag a commit which is not the current head by simply specifying it on the command line (eg: “git tag v1.2 abcde1234”).

       Use “git tag -l” to view the list of all tags.

       Use “git tag -d” to delete a tag.

So I think git still has a long way to go with documentation.

It’s true that 30% cut is AFTER VAT is paid. It’s also true that Apple handles VAT for the developer, and that’s a real mess. So in the list of things that the 30% pays for, VAT handling (and all invoicing in general) should be remembered.

It’s not ridicolous to call it impossible to do in 30 days. In fact, my startup with 10000 users wouldn’t be able to do it in 30 days!

That’s a tech-centric view. For most people a browser is defined by its features like tab handling, account syncing, preferences, extensions, etc. Nobody cares about the HTML engine, only developers. The fact that it’s possible to change the default browser is an important user-level feature.

The point is that people would follow YouTube videos that promise CRACKED SPOTIFY to change that choice so that they can download a copy of a cracked version of Spotify filled with malware. That in turns reflects badly with Apple because it would be assumed that the platform is not secured and cannot be trusted with private / sensitive data (both in B2C and B2B settings). If anything, I think we should at least agree that it’s Apple’s choice whether run this risk or not on their own product.

They have proved that, already. They could have reverted the direct payment system, kept only Apple IAP, and then sued even for damage recovery of 30% since the beginning of the lawsuit (or even the beginning of Fortnite on iOS). Apple has clearly written even in legal documents of the lawsuit that reverting the direct payment change would have been enough to keep operating Fortnite on iOS fully featured.

I think they just went through applying the agreement, which says that the account will be terminated in the specific case of willingful infringement/circumvention. If they had not tried to apply it, it would have been hard to prove to the judge that they always apply the agreement to the letter, which is an important part of this lawsuit (they need to prove that the rules are clear and equally enforced — something that they know it’s not always happened).

Since Epic has 2 different accounts, Apple could have terminated only one of them, leaving Unreal Engine intact. But Schiller’s declaration says that in these cases they have always terminated all accounts that are owned by the same company / conglomerate (I can easily see this is useful in some cases). So again I feel they were in a corner: they had to follow what they have always done, so that other companies couldn’t prove a ad-hoc enforcement of rules (termination rules, in this case).

I’ve more experience working with iOS Reviews. Anecdotally, I was able to discuss with a real person, get at least some insights, and I even went through an appeal and won it.

It really sounds like Google is refusing to provide information, and just point to a specific rule which is too generic to really understand what it’s going on. That’s a pity. I hope you get some traction on HN to solve this

Yes but Apple has stated that it’s a special program for video subscriptions that other developers can and has joined even before Apple (eg: Canal+). The terms are not public but it looks like they’re made available as an option to developers that have apps in that market. It looks like the discount is available if your app implements all features in the Apple video ecosystem (AirPlay2, Apple TV native app, etc.)

Thanks for the article, it provides very good insights.

In the article, there are a couple of passes that mention “benchmarks” where Firefox was faster than Chrome. It sounds like those benchmarks, albeit I assume they were correct, were actually providing a distorted reality of what “fast” actually means, because I distinctly remember people (including myself) switching to Chrome in early days because it was simply objectively faster. It sounds like the existence of those benchmarks have had a net negative on Firefox: it provided a false confidence that the browser was “fast”, and possibly delayed the refactorings that eventually managed to really speed up Firefox again.

You mention that Chrome used “UX tricks” but I assume what this means is that Chrome developers were actually driven by more correct benchmarks: the ones that actually translate to a better experience for the end user.

Since I’m always intrigued by the topic of false benchmarking and how complex it is to do correct benchmarks that don’t fall into traps, I’d love to hear what those benchmarks you mention were measuring, and if you agree that they gave a false assurance to the Firefox team.

I’ve been using Tucows for many years. They resell Comodo code-signing certificates for ~75$ / yr (less if you buy multiple years)

I think this is more typical in public administration. Employees just follow the existing rules/laws because it’s not their job challenging them, and decision makers are mostly concerned on shifting away blame from them. Nobody wants to be that guy that ordered to stop searching for a bomb, the day that a new bomb will be placed. The only reason why one should stop doing it is to gain efficiency (= be more productive but doing less useless things), but the efficiency metric is non existent in public administrations.

I’d start from allowing multiple mutable references. Second would probably be something about relaxing lifetimes but I can’t properly articulate it right now.