> "draft" clearly implies a human will will double-check.
The wording does imply this, but since the whole point was to free the human from reading all the details and relevant context about the case, how would this double-checking actually happen in reality?
> the whole point was to free the human from reading all the details and relevant context about the case
That's your assumption.
My read of that comment is that it's much easier to verify and approve (or modify) the message than it is to write it from scratch. The second sentence does confirm a person then modifies it in half the cases, so there is some manual work remaining.
The “double checking” is a step to make sure there’s someone low-level to blame. Everyone knows the “double-checking” in most of these systems will be cursory at best, for most double-checkers. It’s a miserable job to do much of, and with AI, it’s a lot of what a person would be doing. It’ll be half-assed. People will go batshit crazy otherwise.
On the off chance it’s not for that reason, productivity requirements will be increased until you must half-ass it.
> with the rise of [...] microservices, apps were becoming [...] too complex for any individual to fully understand.
But wasn't the idea of microservices that these services would be developed and deployed independently and owned by different teams? Building a single app out of multiple microservices and expecting a single individual to debug it sounds like holding it wrong, which then requires this distributed tracing solution to fix it.
> There are many race conditions that must be dealt with in input and window management because of the asynchronous nature of event handling. [...] However, not all race conditions have acceptable solutions within the current X design. For a general solution it must be possible for the manager to synchronize operations explicitly with event processing in the server. For example, a manager might specify that, at the press of a button, event processing in the server should cease until an explicit acknowledgment is received from the manager.
I went and checked, and it was an SPE article from 1990[1]: “Why X is not our ideal window system” by Gajewska, Manasse, and McCormack. Section 3 has extensive diagrams of various races, including ones between clients and the window manager. Was even discussed here at one point[2], it turns out. Where I came across it I’m not sure (on X.org[3] possibly?).
And those new APIs (at least the context menu API) apparently require a "package identity", which requires a signed MSIX installer, which requires paying for a code-signing certificate, unless I'm missing something in the docs.
That is because of what people claiming UWP is dead, haven't gotten the whole picture.
UWP as separate subsystem, yes it is deprecated, and no one should be using it, although Microsoft was forced to introduce .NET 9 support on UWP, because many refuse to move away from UWP into WinUI 3.0, given the lack of feature parity.
Now, when WinRT was made to also work on Win32 side, it also brought with it the concept of package identity, which forms a part of the whole app isolation from UWP similar to Android, now on Win32 as well, hence the MSIX.
The survey asks whether people care about the headphone jack, though – it asks whether it's in the top three features they care about.
I care plenty about the headphone jack but still reluctantly bought a phone without one (which I regret) because I have more than three requirements to balance. I expect that the users who did include the headphone jack in their top three features still care that e.g. the screen, battery and radio are all in working order as well, despite not being in their top three.
2. apt repositories are cryptographically signed, centrally controlled, and legally accountable.
3. apt search is understood to be approximate, distro-scoped, and slow-moving. Results change slowly and rarely break scripts. PyPI search rankings change frequently by necessity
4. Turning PyPI search into an apt-like experience would require distributing a signed, periodically refreshed global metadata corpus to every client. At PyPI’s scale, that is nontrivial in bandwidth, storage, and governance terms
5. apt search works because the repository is curated, finite, and opinionated
The install side is basically Merkle-friendly (immutable artifacts, append-only metadata, hashes, mirrors).
Search isn’t. Search results are derived, subjective, and frequently rewritten (ranking tweaks, spam/malware takedowns, popularity signals). That’s more like constantly rebasing than appending commits.
You can Merklize “what files exist”; you can’t realistically Merklize “what should rank for this query today” without freezing semantics and turning CLI search into a hard API contract.
There's not a single mention of pollution or clean energy or the environment in the entire article. Presumably the regulatory requirements for these generators are less stringent than for proper power plants, so the costs are pushed onto the rest of society (having to deal with the environmental impact) while Microsoft et al. keep the profits?
I don't think it's necessarily a misconception but rather people having different conceptions of what the term "F-Droid" refers to. It could refer to the client, the server tools, a specific server instance, the project, the collection of applications, or possibly other things.
Some people might use "F-Droid" in the same sense as the main page [1] does, to mean "an installable catalogue of FOSS (Free and Open Source Software) applications" but others in the sense the about page [2] uses it, referring to the "non-profit volunteer project", which is consistent with the project statues [3]:
> F-Droid is the name of a not-for-profit technical, scientific and creative community effort serving the public benefit.
The documentation start page [4] makes it a bit more clear:
> F-Droid is both a repository of verified free software Android apps as well as a whole “app store kit”, providing all the tools needed to setup and run an app store. It is a community-run free software project developed by a wide range of contributors. It also includes complete build and release tools for managing the process of turning app source code into published builds.
The wording does imply this, but since the whole point was to free the human from reading all the details and relevant context about the case, how would this double-checking actually happen in reality?
reply