It's a MediaTek SoC, so the Linux experience will be Bad to say the least. This thing will be running the oldest kernel possible with all kind of nasty vendor hacks.
It seems like this is grasping for languages to expose recursors[1] or induction principles. These factor out the structure of an inductive type (e.g. trees) and leave the caller to simply plug in the behavior to perform for each possible situation that might arise during traversal.
The Gruen transfer seems to make use of confusion or disorientation upon entering a new physical space. On the other hand, the phenomena described here with data search implementations (e.g. a feed) intentionally returning things that were not asked for does not rely on user confusion. The user already made a perfectly legible request by performing the query (e.g. opening the feed). Ignoring or misconstruing this request is gaslighting. The site tries to pretend that the user asked for something different than they actually did and to sneak this subterfuge past them. It's rampantly unethical. The purported justification I've heard is that fuzzy search can find results in cases when exact matching does not, but taking the control of fuzzy vs. strict search out of the user's hands is unethical because it is motivated by the opportunity to introduce mistakes and pervert intention.
Sites like Etsy implement this dark pattern in ways intentionally intended to make CSS-based blocking of injected sponsored products difficult to block. The arms race between user agents and corporate manipulation continues, and corporate web designers will use every tool available to subject users nonconsensually to their preferred experience. This is why I consider it a net loss for users to add functionality to the "web platform". The corporation is your enemy and they're well-funded.
Personally I've been inspired by nnethercote's logs (https://nnethercote.github.io/) of incremental single-digit percentage performance improvements to rustc over the past several years. The serial portion of compilers is still quite significant and efforts to e.g. parallelize the entire rustc frontend are heroic slogs that have run into subtle semantic problems (deadlocks and races) that have made it very hard to land them. Not to disparage those working on that approach, but it is really difficult! Meanwhile, dozens of small speedups accumulate to really significant performance improvements over time.
I concur. I looked pretty hard into adapting Serf as part of a custom service mesh and it had some bonkers designs such as a big "everything" interface used just to break a cyclic module dependency (perhaps between the CLI and the library? I don't recall exactly), as well as lots of stuff that only made sense if you wanted "something to run Consul on top of" rather than a carefully-designed tool of its own with limited but cohesive scope. It seemed like a lot of brittle "just-so" code, which to some extent is probably due to how Go discourages abstraction, but really rubbed me the wrong way.
Having done some nontrivial Bazel/Starlark hacking, I completely agree that lightweight static types would be a good usability improvement. But I want to point out that Starlark is actually not Turing complete, which is imo one of the more interesting characteristics it has. Recursion is forbidden (https://github.com/bazelbuild/starlark/blob/master/spec.md#f...) and loops must be structural; there is no while loop or other unbounded iteration construct. Starlark is one of the more capable and mainstream non-Turing-complete languages out there, and doesn't resemble the other common ones which mostly show up in theorem provers. On the one hand I think the logic in a build system that needs to reason about incremental builds absolutely should be guaranteed to terminate, but in some particularly painful situations I've had to resort to iteration over smart-contract-style "gas" parameters.
EDIT: as a parting shot, dhall is another non-Turing-complete language in common usage, but its claim to fame is that it gets used in places that arguably shouldn't be doing any computation at all.
These types don't seem to escape the scope of what can be described with algebraic types, but the relationships between them seem like you're looking for a notion of type-level functions: subset ≡ X => 2^X, partial ≡ A×B => (A+1)×partial(B)
One interesting perspective is to view the sequence of lists -> trees -> DAGs -> general graphs as a loosening of restrictions:
- list nodes may have one child
- tree nodes may have multiple
- DAG nodes may have multiple parents though restricted by topological ordering
- graph nodes may have multiple parents from anywhere in the collection
Lists and trees can be fully captured by sum and product types, but extending this representation style to DAGs and graphs doesn't work--you either get inefficiency (for DAGs) and then infinite regress (for cyclic graphs) attempting to continue the "syntactic" style of representation, or you need to adopt an "indirect" representation based on identifiers or indices or hash consing.
There are a few ways to handle this design question ("what happens if something needs to interact with a process while it's blocked in a system call?") more or less sanely, and UNIX chooses the least sane one (making userspace deal with the complexity of system calls possibly doing part or none of the work that was requested). Other operating systems might fully transparently guarantee that the system call completes before the process is notified of said interaction, but this isn't compatible with IPC as "lightweight" (unbuffered and without backpressure) as signals.
The Right Thing is to make system call submission atomic and asynchronous, only waiting on completion by explicit choice, and remove signals entirely in favor of buffered message-passing IPC. This is basically the world we're approaching with io_uring and signalfd, except for ugly interaction with coalescing and signal dispositions (see https://ldpreload.com/blog/signalfd-is-useless), and the fact that many syscalls still can't be performed through io_uring.
If UNIX had a better API for process management, people wouldn't see signals as necessary, but that's its own can of worms with its own Linux-specific partial fix (pidfd) and genre of gripe article (e.g. https://news.ycombinator.com/item?id=35264487).
My experience attempting to contribute to Manjaro (fixes to packages including some without with which packages simply hung when being built interactively, as they depended on stdin being EOF as it is in their CI environment) was met with not just a cold shoulder but active offense and hostility. They don't accept pull requests (in fact, their gitlab configuration doesn't even let one fork), nor is there a mailing list for patches. There simply is no contribution workflow, and this isn't even clearly documented (it's fine to be a "cathedral", but you should be up-front about it).
"LINEAGEOS, UBUNTU TOUCH or ANDROID" is a euphemism for "we did not do the important, hard work of upstreaming drivers".
This phone might be perfectly nice, but it's a "Linux phone" in a marketing sense only; nobody has properly ported Linux to it, and you'll be stuck with an ancient kernel full of proprietary userspace blobs.
I'd love to hear otherwise, but I've seen this pattern repeat a number of times (the Gemini PDA and successors, various "secure" phones, essentially all the Ubuntu Touch devices https://phone.docs.ubuntu.com/en/devices/devices, etc.) and those who do put in the critical driver work are in-touch enough to know it's worth being explicit about upfront.
You're right... what an annoying namespace collision. On the other hand, stylizing software as Initial Caps is much more acceptable than stylizing non-software acronyms that way, so it would still be less misleading to change the capitalization.
Please change the posting title to match the article title and disambiguate between APT (Advanced Persistent Threats, the article subject) and Apt (the package manager).
You're completely right, of course. Seeing the amount of effort put into virtualization, sandboxing, containers, etc. is enough to make one wonder why every enterprise is so shortsighted. Capabilities obviate all of the above, and are neither a new untested idea nor more complicated than what we have--as we clearly see in the repeated attempts to build things that approximate them with ACLs and sandboxes and seccomp rules and so on.
Linux is slowly moving toward capability-centric design with more and more comprehensive namespacing and file-descriptor-based interfaces to things like pidfd and memfd, but there's still a long way to go before we can jettison ambient authority such as the filesystem entirely. Meanwhile, Google's Fuchsia may deploy a capability-based operating system to the masses, but it will likely only be used to sandbox applications written for Android anyway. The real potential of capabilities is to simplify the interface of a power-user operating system by eliminating the race conditions, side channels, privacy leaks, firewalls, virus scanners, and unix-style permissions from developers' and users' day-to-day experience completely.
There will still be memory-safety zero days, of course, until we abandon languages where humans are statistically incapable of writing memory-safe code.
The solution to this situation, as I understand it (on Linux), is TASK_KILLABLE, which effectively supercedes uninterruptible sleep as a concept: https://lwn.net/Articles/288056/
But TASK_KILLABLE is not used in most places it should be. Patching your (least) favorite driver to use TASK_KILLABLE could be a good entry point to contributing to the kernel.
What structure does an algebra require to merit the name? I've been confused by examples such as the "algebra of a monad", which as I understand it arises from adding an "unwrap" operation in addition to monadic "return" and "join". Most of the references to this only ever refer to specific cases such as an algebra over a monad or an algebra over a functor or a division algebra, etc., and I haven't seen anyone be clear about what makes something an algebra.
The point of the Librem 5 is not to make the most popular possible phone, it's to make a better phone than what is currently available.
Markets only matter to capitalists. Real hackers share with each other to make things happen that markets do not comprehend. Whether this project will be a success, only time will tell, but it has nothing to do with the market.