Hacker Newsnew | past | comments | ask | show | jobs | submit | hosh's commentslogin

If people are happy with Actions API, that sounds great.

I’m not happy with the Actions API. I think Gitlab’s cicd design is much better, and I’m not fighting it all the time when I use it.


i'll echo this sentiment. historically there's been a lot more flexibility with GL CI yaml syntax, including real yaml anchors https://frenck.dev/github-actions-yaml-anchors-aliases-merge...

sys-admin-ing gitlab can be a bit of a maze of web menus tho.


I find this recommendation funny, because I completely agree from a sysadmin perspective.

I used to use Gitlab at work, and small teams would run into so many footguns with CI that we had to throw up guardrails to prevent mistakes. Far too many links to gitlab issues that were not fixed even after >8+ years of being open ended up biting us. With GHA I haven't had that experience, and same for all of my self hosted Forgejo instances. I used to hate using GHA from about ~2018 to 2021, but they've fixed a lot of things I disliked since then.


What do you need real anchors for? Sharing of pipelines?

Maybe I’ve been burned too much by pipeline maintenance (because we didn’t have yaml anchors?) but I rather have builds defined in make /bazel/etc than in yaml. So the only thing the pipeline does is optionally restoring caches, kicking off the build system, uploading PR validation results, and saving cache. Pushing artifact etc is all done from inside the build system.

There is no “setup” like installing packages because we make the build image seperately.


Smalltalk also had extensibility for one. But it largely missed the explosion of collaboration when open source code became shareable and people can work on it together.

People also shared Hypercard apps.

I think it is less about client/server and more about how ideas can be shared. Sometimes, data might be shared.


I think as we see more AI participation in code, github stars are going to matter less.


Maybe they got sucked into the cool tech?

I remember my first pass reading of Stephenson’s Snow Crash and Diamond Age, I was bedazzled by some of the tech … it was later readings that the comments like “biomass” (the recent echo in AI “meat proxy”), or how the Primer was ultimately a failure sank in later readings.


Not to mention language communities with constant supply chain attacks because its standard library story is poor, and everyone keeps reinventing new, often half-baked solutions?

Or even that, the very same ecosystem congratulates themselves on the typing system but still relies on linters because the language and runtime themselves allow whole categories of dumb ideas to be written?


This looks a lot less annoying than Typescript, particularly how dynamic() is a lot more useful than any()

I also wonder if this works well with Ruby’s duck-typing and monkeypatching.


In my twenties, I came across an idea from one of Ken Wilbur’s books that helped settle a conundrum for me. What happens when one wants to honor all life? Are they all equal?

He made a distinction between intrinsic value and extrinsic value. Plankton is not as complex of a lifeform as whales, yet whales cannot live without plankton. One has more intrinsic value and the other has more extrinsic value. There is an interrelationship that does not have to flatten value for everything and everyone.

LLMs are trained from the language corpus of our collective consciousness. It reflects our collective, all the wonderful, beautiful, and horrific things we can dream of and put into words.


What people are finding now when building agenic AI orchestrators is that they are reinventing some of the ideas behind BEAM and OTP. The big one being queues (mailboxes), but also fault isolation.

Async runtimes can’t really do preemptive scheduling so those end up using other methods that, while getting low latency, may not improve reliability or reduce variance in latency.

Orchestrating tasks across a number of different services that are not in your control becomes a distributed system where not everything is reliable.


How are resource management distinct from scheduling in Mesos?


Mesos handles resource reservation like a broker. Frameworks like Marathon or applications like Apache Spark make requests to Mesos for resources and then ask Nesos to launch specific processes on those resources. You can have multiple frameworks on a given Mesos cluster.


Is it fair to say that Mesos is more top-down while Kubernetes is more bottom-up in scheduling approach?


I think people are putting together pi clusters for their homelab these days.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: