We run the entire stack (browser, frontend, backend, database, etc) in a Linux VM, so latency between each of the pieces is as tiny as can be. This is quite different from "standard" E2E tests I've seen where the test browsers uses something like a persistent staging environment.

The real key is that we can fork that entire Linux VM to take different paths down our testing scenarios, and can run multiple of them in parallel. Tests may look something like:

  new user signs up:
  |- creates a todo
     |- ...
     |- ...
  |- creates a list

What does it matter what I say? You already showed bad faith in equating skepticism towards LLM as a path to "AGI" to refusing to acknowledge severe weather warnings. You're trying to drag this into some contest of egos.

It is still a matter of a novel technology that has some uses, is being feared as well as hyped as the harbinger of some computer genie, and the fact that I don't think it is and you do has no solution.

I mean. What is your point? Besides throwing mud at me, what would you have me do about it if you think that there it amounts to stupidity to doubt that LLMs can somehow become anything more than a statistical model of text that can be used to put out mediocre software, corporate copy, and expose the fact that bloated web apps built on dynamically typed languages can be cracked open by Kali linux boxes and simulated script kiddies?

Ironic really because that was the original idea behind Git - to build a tree of trusted developers for the Linux kernel. Linus has those immediately below him that he trusts will push good quality code, and those folks do the same with their group of contributors.

> Invite-only registration helps us

If this is invite-only, then what you're doing is emulating the original strategy of Linus: only certain folks have commit rights. Extend that out to only certain folks have PR-creation rights and you're done. Maintainers select those that can contribute, these folks in-turn, select those that can contribute to the project, rinse and repeat.

Let everyone create issues and implicitly ignore these because any issue that doesn't make it passed the "acceptance level of a maintainer" will naturally be ignored and disappear. As is the case over at GH - issues naturally suffocate because no maintainer gives them air.

Perhaps have a special category "untrusted/toxic PRs" for contributors who don't belong in the tree of trust. These PRs are handled in a toxic-proof containment environment, i.e., they get particular vetting attentions by maintainers. Obviously this would be a path into the "tree of trust" for a project.

Then each project can also implicitly define what is "low quality" for their project - it's how they handle the "toxic PRs".

EDIT:

That's also why branching and forking is so cheap in Git: each sub-maintainer can maintain their own fork with it's branches before pushing up changes to the main fork. (Compare branching using RCS/CVS or Subversion to Git to get a feeling of "cheap" ;))

This can be done over at GH if a fork would be actively maintained by a sub-maintainer and every X days/weeks/months they would push the entire changes of the fork to the main repository. That would be closer to the Linux development strategy - as I understand it.

Remote: Yes

Willing to relocate: Yes

Technologies: Rust, C, Linux, Proxmox, QEMU, ZFS, Bash, Lua, Nix, asm

Résumé/CV: https://www.linkedin.com/in/charles-konde-55a6a2281/

Email: ckonde9513@gmail.com

Self-taught Linux systems developer. I maintain niche Rust software packaged in multiple distributions. Looking for Linux support engineering, packaging, or build/release work.

Remote: Remote/Hybrid/Onsite

Willing to relocate: Yes (with visa sponsorship)

Technologies: Rust, C++, Python, TypeScript, JavaScript, FastAPI/Node/Axum/Actix, React/Next, PostgreSQL, MongoDB, Redis, Git, GitHub, Linux, Docker

Résumé/CV: https://dhruvkjain.vercel.app

GitHub: https://github.com/dhruvkjain

LinkedIn: https://www.linkedin.com/in/dhruvkjain05/

Email: dkjain2005co[at]gmail[dot]com

Experience,

- Software Developer Intern at an HFT this summer: wrote kernel-bypass networking modules in C++ (TCP and UDP), both in production; created microservices in FastAPI backend.

- Maintainer of kornia (open-source geometric computer-vision library) ship features, review PRs, mentor contributors.

Looking for: full-stack / backend / systems / low-latency / trading-infra roles.

Graduating 2027 open to internships now and full-time from 2027.

Reminds me of the move from on prem to cloud. Linux sysadmins were killed and replaced by aws focused devops.

Fairphones have 1-2 months of delay for partial security backports to older releases from the beginning and much longer delays for full updates. Android 17 is required for full Android security updates. Only a subset of patches are backported to older versions and that subset is decreasing.

Android 17 is also required for the latest and greatest privacy/security protections which are not backported. There have been massive privacy and security improvements in each yearly Android release.

There is a $150 edition: https://pine64.com/product/pinephone-beta-edition-linux-smar...

It is forever in beta, because the company develops no software at all, only provides the hardware. All software is developed by the volunteers.

> Your first link, I had found myself, but it doesn't say a lot.

What does it not say? It also links to this: https://pine64.org/documentation/PinePhone/_full/

Imagine you wanted to make a native desktop app that runs on Windows (going back to Windows 95), and OSX, and Linux, and have it use the end users choice of native components, QT, or GTK. It also has to load fast, be accessible, and work on desktop, laptop, and phones. Also, you're only allowed to ship a single binary but you can load in assets based on the device when it runs.

The app could be anything from a single page that renders one image up to a complete 3D game. Users want 60FPS regardless of what it is.

I reckon you'd end up with a relatively complicated build pipeline.

That's what webdev is today.

And outside open source there has been a staggering amount of creative work at all quality levels done for commercial purposes under the protection of copyright. Is there a convincing argument that the last century of software and music and books and etc would have been just as staggering without copyright?

I would love to hear such an argument. In my youth I thought copyright was blatantly stupid and should be abolished. I still sorta think that but I don't have a convincing argument in the face of the absolutely massive amount of good work that has been produced under it.

Remote: Yes

Willing to relocate: No

Technologies: TypeScript, JavaScript, React, Vue, Svelte, Golang, Node, Python, FastAPI, Django, PHP, PostgreSQL, MongoDB, Claude, AWS, Terraform, Docker, CI/CD, Git, HTML, CSS, Tailwind, Jest, Mapbox, ArcGIS, Bash, Linux

Résumé/CV: https://ryanisler.com/resume

Email: islerryan@gmail.com

Portfolio: https://github.com/ryanIs

Senior Full Stack Developer with a background in weather forecast mapping, API/CMS development, and product database tooling. Currently back and forth between a few endeavors: building a Scryfall-inspired Magic the Gathering assistant built in React and Django; a text-based video editing assistant with Vue and FastAPI; and having a blast improving my workflow with Neovim and Agentic Engineering (Andrej Karpathy style)!

I am searching for remote full-time, or contract opportunities.

I ended up creating multiple logins on a Linux system. I used my developer account to clone git repos and then create local bare repos in a read only dir. The new linux user accounts can clone from these bare repos but not push. This way, each coding agent (installed per linux account) can only work within the file system for that user on the repo assigned to that user.

Each of these user has no github permissions (cannot clone from github, cannot create pull requests, etc.). They can run tools (that I have installed) but cannot generally install software or push changes (no sudo access, no github credentials). So I can ask each coding agent to make local changes, and when they are done they create a pull request branch and wait for it to be accepted.

Then my single authorized user can take that pull request branch and merge it and push it (or create a pull request). This prevents any agent from working on a repo other than the one it has access to.

Doing this allows me to run several agents at once, one per repo, and not interfere with each other. Before I did this the agents would overreach and start modifying other repos while the correct agent was also making changes. Now, each agent creates a document requesting changes from other agents in their respective repo.

So these low privilege users have no credentials (other than to use a coding agent). This setup works for me.

Fairphone chose to use T2Mobile as their ODM designing and making their devices. They chose to use the SoC platforms they did. They chose to focus very little on providing updates to the point that the Fairphone 5 and earlier have an end-of-life Linux kernel without security support. Fairphone 5 is still presented as supported with many years to come but it's not getting a large portion of the high importance security patches anymore.

Android Security Bulletins do not cover the vast majority of Linux kernel security patches. They only cover an extremely small subset tied to Android. The Linux kernel has a massive tsunami of security patches on an ongoing basis. Fairphone 5 and earlier have an end-of-life Linux kernel without security support. They're close to not updating the kernel at all anymore. Their more recent devices will end up in the same situation.

The Linux kernel is not the only component ending up unmaintained while the devices are still presented as supported.

If I had a way to send a message to my younger self, it would've been: "drop whatever you're doing, start grokking Linux, learn Emacs, and maybe Vim...". I never had any regrets about my career choices of the past, yet "fuck Microsoft!" I spent years digging dotnet, sqlserver, etc. I invested heavily into WPF and Silverlight, I believed their propaganda. I don't feel even a half-pint of value from the experiences I gained, it all turned out to be useless crap - none of it squeezed even a drop for becoming a hacker out of me. Learning FP, Lisp and Emacs brought me closer to that goal.

Most people expect to have decent encryption without a strong passphrase, at least 5 years of security updates and a lot more. Fairphone says they provide updates far longer than they do for many components, and those come with substantial delays. Fairphone 5 and earlier have end-of-life kernels without security support. That's a very bad situation and is widely ignored. The more recent devices are headed to the same situation for the Linux kernel and other components.