Yup, that's the way it has to be. And thanks to the autocomplete on steroids we call Ai nowadays it actually has become way easyier to do such a thing.
Kinda like how once chemistry gets complicated enough we call it biology, LLMs have become complicated/versatile enough that it's no longer useful to call them autocomplete.
Didn't he just say that fork turns out to be comparatively faster to the non-fork samples we get? Ie Linux spawns processes faster than Microsoft's kernels?
Didn't I just say that "the problem with fork isn't really that it's slow"? It's all the other OS design choices it forces on you if you want it to be fast.
We don't have any broadly used non-fork samples. Windows, macOS, and Linux all have fork. So the presence of fork can't be the reason for the performance difference.
If you pass null for the section handle, it shares pages with the calling process, thus implementing a forking model. Or at least the parts of a forking model that some people erroneously believe are responsible for performance differences.
I've stumbled upon that too! Funnily I see it having two forms:
1. Some bad idea gets embedded into the context that you just can't argue away
2. Some important idea gets lost in compression and the ai wheres off into funland without recourse.
In both cases if is often better to start over or just do it yourself. I sometimes find myself asking for a summary, editing it and then using the edited one to seed a new session.
Mostly with you, though in recent years I have wondered whether those people are part of what caused the latest boom of political populism. If there is no one there to debate the problematic ideas, problematic ideas will become the rhetoric after all.
I don't know whether Github is in trouble as an organization or whether there is a crowd just waiting for it to go down in flames and I don't care about that.
What I can attest to is that Github has been uncharacteristically flaky this past year. At least for large clients in the EU. Its not that there is outright downtime but if you have an Actions or PR invested team you probably have felt the uptick in troubleshooting these two features in the past 12 months.
And again, its not that these features go completely down, mostly its just "why is this status not being reported" or, "where is the run for this event?" And similar things. Its not that the roof fell off, its just that it is leaky and it rains and this distracts you from actually doing important things.
I'm totally onboard with k3s/k8s being better in a lot of cases.
But docker compose can actually be very sufficient for what many projects actually need.
Granted I am a guy pushing for compose based localdevs and such but going further you often just cannot beat the simplicity of doing update QA or other CI/CD workloads in compose based projects. I have had dozens of projects where we replaced flaky slow and maintenance heavy pipelines with just docker compose up --build --wait in the past years. How come you say health checks are still broken?
I do use compose for some things, smaller one off type setups, and I’ve done the compose up --build CI/CD approach before. I’m generally not a fan of building on the production node outside of very small deployments. It can work, I just think it tends to blur the line between build and runtime more than I’m comfortable with.
Some of my concerns with compose aren’t purely technical. It makes it easier to lean on local state like volumes, bind mounts, and large .env files. Similar mechanisms exist in kubernetes, but the additional setup tends to force a bit more thought about whether they’re actually needed or just a shortcut.
On the health check side, they exist, but compose doesn’t fully act on them, that's the part that is missing. There’s no built in remediation or orchestration behavior tied to health status, which is why things like
https://github.com/willfarrell/docker-autoheal exist. It’s something that was never fully carried through in Docker itself.
Of course it is. What should a button on a screen look like, after all, it has absolutely nothing to do with a large mechanical button from the 80s the old designs tried to emulate. In fact, such buttons are becoming rare even in the physical world, the younger generation is more and more accustomed to touch buttons for operating all kinds of machinery around them. So "like a button" is very much an age thing
Nah, one of the things I found in Discord's accessibility settings is an ability to turn off or reduce animations and other visual effects by default, which is wonderful no matter your ability.
Possibly a factor, but I also think these issues are becoming much more widespread, leaving us less able to tolerate them than when they were less common.
These things are like a sidewalk having a ramp that was originally made for wheelchairs but then suddenly everyone uses it because it’s just a nicer experience with less chance of tripping and falling flat on your face.
I can see the alure of having a very secure mobile device and can understand why you personally wouldn't see a reason to use anything else.
But Graphene requires too much fidling to get spouse approval.
/e/ might not be as secure as GrapheneOS but it is at least as secure as everything else. Plus it actively helps you preserve your privacy and use self hosted services.
At the end of the cycle of a Pixel model, they are heavily discounted. So much that it's probably close to hardware + development cost. Google probably expects to make a profit from Google One subscriptions, Play purchases, and ads.
By installing GrapheneOS, you are giving them nothing.
they're working on it. GrapheneOS has serious plans to get a phone made for them. even more serious now that Google has become openly hostile to their project by no longer publishing the Pixel device tree when new releases come out.
You get a device that still runs proprietary Google blobs in privileged processes (for Play Integrity), talks a lot with Google, gives certain Google applications (like Google Maps) higher privileges than normal Android apps (you can find the signing keys of apps that get elevated privileges in the source code of the /e/OS microG fork), uploads your speech to OpenAI for speech to text, uses a shady middleman (which they do not want to reveal the owner of) for installing F-Droid apps [1], and is hopelessly behind on Linux kernel versions, firmware blobs, and Android security patches (remember that Android Security Bulletins only have backports of high/critical patches).
I wouldn't recommend anyone to use /e/OS. Either they are very incompetent or they are very shady.
That link you shared in your other comment actually counters your "runs google blobs" argument.
Speech to text is afaik completely anonymized and if you care that much, it actually is possible to just not use it, rip it out or even replace it with something that runs locally in your home.
> hopelessly behind on Linux kernel versions
Can you substantiate that? Given that many OEMs still run linux 4 and 5 in their Flagship ROMs today, I'd like to see how open source does so much worse.
If there's one thing I've learned about the custom Android community (and to a lesser extent, the Android community) it's that "it actually works" isn't really important or convincing to them.
How much user interaction is needed in the phone to make this happen nowadays? I havent used libimobiledevice in ages but I can remember that nm the past in order to get everything your phone would need to request an icloud backup (as most data lived there and not on the device back then) and often the process would just stall if the phone fell asleep.
The lack of selfhosting support on iPhones is the main reason why I'm on android.
reply