There's less gray area with driving wss the point. Legal or illegal, efficient or inefficient. And whatever gray area remains is generally "good enough" compared to human drivers on the road.
It's easy evaluate if there's no victims. Stats say there's more than 6000 injuries per day and more than 16000 deaths per year on the road.
If you choose between hitting a pedestrian and swerving potentially injuring the driver and totaling the car, what would you like the car to pick? Or any given trolley problem variation, etc
Based on the comments here and the content of the post... I sort of agree. But maybe less so directly with their gatekeeping. But maybe we should formalize closer to "real professions".
And if we think college degrees don't matter, there's plenty of professions that require time on the job, rotations, flying low/no passenger planes, and so on.
We require people get a license to own a firearm (or ostensibly should...). And AI can be an extremely powerful weapon.
I see a gatekeeping argument. I don't agree with their requirements. I'd rather see that regulation than banning models.
It also has the side effect of preventing AI from taking jobs as aggressively, keeping it at bay in schools, and getting people to maybe respect(?) / acknowledge the dangers involved here.
What you are saying is impractical, we cannot uninvent AI or force all countries to abandon it, a simple laptop is sufficient compute to run it. Licensing to access AI cannot be implemented. Why stop at AI, maybe we should license people to use the internet as well? Own computers? Electricity could also be a powerful weapon, should we only trust some people to have electricity?
Hey Ryan, just want to congratulate you on this. I've _loved_ solid since well before it's v1 release, and use it in all my side projects.
If anyone hasn't tried it I highly recommend it. Simply put: Solid makes the "dumb and naive code" the optimal code. It takes all the pain of React away.
I agree with your sentiment that we've pushed web frontend performance as far as we should bother. I think optimizing calls is the next frontier. On that end, I like the approach for async, but maybe I have a suggestion?
Solid needs a tightly coupled request library that emits signals/resources directly. That "server-side" data binding layer would be the missing glue. I think server actions sort of get at that, but I've never really been satisfied with them. Just my 2c.
Step one of all my projects is always wrap a bunch of fetch calls into whichever correct incantation of solid primitives. Plus, the solid compiler should be able to early load those requests via static analysis and improve real life FCP / LCP times without the developer needing to do gymnastics.
"Everyone's doing it" presented with no evidence is just you trying to make yourself feel better for:
- using from
- driving a Tesla
- voting for Trump
It's a really, really easy line to draw in the sand: don't support openly corrupt individuals.
It's absolutely true there's money in politics. To call all money in politics equally corrupt because Bernie got a dollar to have dinner with someone vs Elon effectively directly buying votes....
A complete lack of nuance here. And I wouldn't be surprised if corporations / super rich WANT you to think like that. The more defeatist the mentality becomes the more we just accept whatever they do next.
Not a bad concept, but there's an unwritten rule in most puzzles that the clue and answer can't overlap. Really messed with me for shark tank.
Meanwhile, and I say this as someone who plays a lot of puzzles, this feels distinctly unfair? Too many valid positions for each answer, which makes it more sodoku like but without the ability to validate against concrete rules. Forces a full mental layout of every possible position to find the one(?) Valid layout.
Thank you for the feedback. I’m no puzzle making pro, but yes the decoy clues were my idea. Scores are based on time and number of errors, with preference given to fewer errors. So I liked that it adds a layer of strategy as to going fast vs. checking possibilities.
The current system in healthcare hurts consumers. We certainly do not want the same system in AI.
Frontier AI is a business to be “the smartest guy in the room”. It will always be hyper competitive just because of that.
The fate of any individual frontier company is irrelevant. What matters is AI consumers, and broad accessibility of AI to those consumers. If one of the AI “frontiers” bites the dust, the next one will step right in.
> The government regulates the drug industry to give companies an exclusive period to recoup the costs before generics can jump in.
Sorry, no bailouts. Whatever drug companies negotiate, they do it in advance, it's called a deal. The purpose of regulation cannot be "recouping the costs" of everyone who's just figured out that they can't make it the way they've promised. If it was, everyone and their dog would ask for recouping the costs of dog poop management.
> AI lacks that regulation which means frontiers are guaranteed to just bleed to death.
The lack of such regulation actually means that frontiers should slow down spending money they don't have in order to avoid bleeding themselves to death... what a novel idea, ha?
Lot of kubernetes hate here, which is surprising. I run a little 3 node cluster and besides the hardware issues I had (long story), it has been rock solid and dead easy to setup.
Talos + longhorn + fluxcd (optional), is super nice. And everything beyond that is additive and just works within the ecosystem.
If anything, it helped keep my stuff alive during all the hardware issues a lot longer.
I think like 5-6 years ago, kubernetes on baremetal was pretty painful. People should really give it another try, an LLM can probably set it up for you and fire off the docker compose to manifests in one shot. Or just follow the docs yourself, maybe a dozen commands to get a cluster running?
All the enterprisey stuff makes it feel a lot more complex than it really is.
That would not match their reason for preferring to move off k8:
> I built a system that I didn't actually know how to maintain without the time or energy necessary to dig myself out of trouble.
If you want a system that you can understand all at once in your own head then making it with your own head is a better way to go IMO, for a small system at least.
When you are only used to the Kubernetes at work I can understand how people dislike it. If you set it up yourself and start with minimal feature and not lots of annotations the config files become very simple and not more complicated than a docker compose file.
It quickly realized that after just using the managed Kubernetes from Digital Ocean and deploying a side project there.
Oh running stuff on k8s is great, but running k8s itself is just adding a lot of code to your stack and might be not so trivial to debug when something goes wrong.
Agreed, personally I'd only do it through a hosted provider or maybe consider https://k3s.io for a bit simpler setup. I'd also only do it if Kubernetes is something I'm already familiar with.
> All the enterprisey stuff makes it feel a lot more complex than it really is.
Kubernetes is not PaaS. It is a low level container orchestrator. But people start by thinking of it as a ready-made PaaS and then keep on trying to make it closer to that vision by continually slapping random plugins on it.
In corporate environments, incompetence is the norm. Every kubernetes deployment in such places ends up relying on rando docker images, helm charts and "operators" written by script kiddies and webshits which break every night and are hardly better than coding the same functionality yourself.
You need a strong instinct to say "No" and taste to keep the system complexity under reasonable limits. Sometimes this involves actually architecting your "platform" code around the barebones orchestration provided by kubernetes instead of slapping on latest webshit shown on CNCF dot org. That sort of judgement and taste is impossible to find in corporate environments in the age of resume driven development. That is how most people get Kubernetes scars.
If you are used to docker compose and don't care about redundancy or authoring your own stuff. Just setup storage and then use helm install. It feels like an app store at that level.
That's, in my opinion, a pretty vanilla starter stack. Could probably argue that you don't need replicated storage, and that ArgoCD is nicer to look at, but Talos in particular simplifies a lot of the deployment because there's not much of an OS to configure or keep updated.
Sure! That's the setup I was running before all of this. My problems are likely entirely my own making, tbh, as described in the article.
IME K8s in general and longhorn especially behaved poorly in the face of heterogeneous hardware where the largest node is flaky and has more cores and memory than the rest of the nodes combined.
My point is that, for me, in my setup, with my own idiosyncratic constrains, trying to keep up with Talos + longhorn + fluxcd expended way too many spoons in any given month.
> Lot of kubernetes hate here, which is surprising
It's easier when you think of it using cats. A person wants a cat. They want a big one to deal with their rodent problem. They've heard that tigers are really big cats and extremely efficient in dealing with unwanted biomass around them.
Said person gets a tiger. They get an impromptu expedition to hell and barely make it back. Person hates cats, buys a poodle and advocates for mouse traps.
Kubernetes was designed for large organizations with massive applications that are usually micro services. It allowed the applications to be load balanced and easily updated with no downtime. Also, these organizations paid top dollar to highly technical and competent employees.
Now, all organizations feel like they need kubernetes because it's the next logical step in the never ending IT progression. So, they force all their apps to be containerized and run on an multi-tenant cluster.
However, these apps worked just fine on a server, and now the devs have to refactor them and get them to work on kubernetes. All the System Admins and Engineers also need to learn kubernetes. But most of these people don't want to constantly learn and use kubernetes, so no one ever really knows how it all works.
This inevitably led to companies whose sole purpose is to help places get off of kubernetes because it is too hard to maintain. I've seen it play out at several organizations.
I got introduced to UNIX with Xenix, have used plenty of flavours including containers in HP-UX and Solaris before they became a thing in Linux, I have zero need to use Kubernetes at home.
In fact, I also have zero needs for it at work directly, as I have become an advocate for serverless and managed runtimes, unless there is really a business need to control the whole infrastructure, including the Kubernetes cluster directly.
If it makes you feel any better, the Markdown part is optional (and has no semantics). Somehow it feels about right that the Markdown file can actually just be a YAML file with the wrong extension.
(Actually, to be more specific, a YAML file with no directives, explicitly-signalled start-of-document-content, and followed by a second null document. I will note that frontmatter syntax is not specified; the non-normative Appendix B is the only place that suggests it means prefix and suffix --- lines. And no, frontmatter is not part of Markdown, or CommonMark, and is in fact incompatible with both. And it’s invalid YAML too, the end-of-frontmatter line should be ... to indicate end of document without starting a new document.)
> sure, but structured text like markdown is even more useful, since humans can parse and understand it as easily as skills can
And there are a number of nice viewers / editors either already installed or easily installable on most operating systems to view / edit Markdown in a "beautified" fully rendered form, on both CLI and GUI interfaces; and since most (all these days?) LLMs also "understand" Markdown formatting pretty-much natively, you can easily emphasize certain points to add "weight" to them in the LLMs' "mind" / "thinking" (calculation of statistical token probabilities) process. Plaintext without Markdown is just ... well ... plain. :)
it is until we define real consistent deterministic gates and protocols. It really is a symptom of the lack of concerted effort. Everyone has a personal preference on how to shove the context and most of them are just "here's some good text I've found to work in my context"
> define real consistent deterministic gates and protocols
I've been experimenting with doing kinda exactly that with the "routing layer" / "harness" level of things, before the "main" LLM itself ever receives the user's input, by getting "user intent" (as a little JSON packet) really quickly from an ultra-lightweight model first and deciding from there in deterministic code what "context" to inject into the user message template, which system prompt to use, and which model to route the assembled context "packet" to for the final response. These LLMs really are fun to play with once you get a feel for which ones do what well, and where each falls short so you can use them each around their individual strengths. :)
reply