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.
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.
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.
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.
"The Browser" has turned out to be a pretty terrible application API, IMO. First, which browser? They are all (and have been) slightly different in infuriating ways going all the way back to IE6 and prior. Also, a lot of compromises were made while organically evolving what was supposed to be "a system for displaying and linking between text pages" into a cross-platform application and system API. The web's HTML/CSS roots are a heavy ball and chain for applications to carry around.
It would have been great if browsers remained lightweight html/image/hyperlink displayers, and something separate emerged as an actual cross-platform API, but history is what it is.
It didn't win. It just survived long enough. The web is a terrible platform. I haven't ever shipped a line of "web code" for money and I plan to keep it that way until I retire. What a miserable way to make a living.
Perhaps you're taking the npm/react/vercel world to be the entire web? I agree that that stuff is a scourge. But you can still just write html and Javascript and serve it from a static site, I wrote an outline in https://incoherency.co.uk/blog/stories/web-programs.html which I frequently link to coding agents when they are going astray.
When I was a kid I was running websites with active forums and a real domain name, and I did it with vBulletin and my brain. Someone bought the domain name and website off of me, haven't touched web tech since. I did use Wt at an old job once, but the "website" was local to 1 machine and there were no security concerns.
I envy your pure soul. I am one of many who has had, at times, been coerced through financial strain to write some front end code. All I ask for is, when the time comes, you try to remember me for who I was and not the thing I became.
Look at caniuse, if you see green boxes on all the current version browsers. Than you are good to go. If not, wait until the feature is more widely supported.
I see a lot of this sentiment amongst developer friends but I never could relate. Its not that I'm against it or something but it just doesn't move me personally.
Most things I create in my free time are for my and my family's consumption and typically benefit immensely from the write once run everywhere nature of the web.
You can launch a small toy app on your intranet and run it from everywhere instantly. And typically these things are also much easier to interconnect.
Are you talking about the "engineer talked to a customer and now both are mad at each other" trope?
While I have seen this happening it usually has nothing to do with engineers and more with that fact that talking to customers and identifying requirements is a task that requires respect and practice to become good at. Procentually I've seen more junior MBAs alienate customers than I have engineers seen do it.
The French Revolution didn't just happen spontaneously from individuals acting individually. You need leadership and coordinated action to change things. A small number of individuals acting individually, yet pushing in the same direction, will never move a needle.
Exactly my point. All that (and all the other things needed) did not just materialize out of thin air. It took decades and dozens of failed protests to get to that point.
Isnt that a bit dangerous in its own? If the merge process can complete without conflicts being resolved, doesnt it just push the Problem down the road? All of a sudden you have to deal with failing CI or ghost features that involve multiple people where actually you just should has solved you conflict locally at merge time.
The conflict is no longer an ephemeral part of the merge that only ever lives as markup in the source files and is stomped by the resolution that's picked, but instead a part of history.
I think it is also not true that there's only one correct answer, although I don't know how valuable this is.
For committing let's say yes, only one correct answer. Say the tool doesn't let you commit after you've merged without resolving conflicts.
But continuing to work locally you may want to put off resolving the conflict temporarily. Like person A changed the support email to [email protected] and person B changed it to [email protected] - obviously some wires go crossed and I will have to talk to A or B before committing the merge and pushing, but I can also go ahead and test the rest of the merge just fine.
And heck, maybe even committing after merging is fine but pushing requires resolving. Then I can continue working and committing locally on whatever else I was working on, and I'll only resolve it if I need to push. Which may mean I never need to resolve it, because A or B resolve it and push first.
> The conflict is no longer an ephemeral part of the merge that only ever lives as markup in the source files and is stomped by the resolution that's picked, but instead a part of history.
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.
reply