the one does actually sound worse because... it's actually worse. it clarifies that the companies themselves were playing games with people's livelihoods because of the potential for profit.
whereas "AI" is intuitively an external force; it's much harder to assign blame to company leadership.
I'd read the first as adjusting to market demand, not playing with people's lives. If if were construed as playing with lives, that could apply to basically any investment.
They used to do that back when the iPhone first came out. I don’t think anybody liked that better, and having people hang around on older iOS versions was (and still is) bad for security.
iPhones never had paid iOS upgrades. iPod touch did, but that's because Apple was worried free updates would violate an accounting rule. Specifically, the iPhone was considered subscription revenue while the iPod touch was considered purchase revenue. And after an accounting scandal[0] GAAP had been changed so that you couldn't say you sold, say, a bunch of stuff that hadn't actually been finished yet, and then finish it later with, say, a software update.
This is, of course, how basically every tech company works nowadays[1], because Apple lobbied to have that accounting rule removed.
None of this has anything to do with "App Store pays for iOS". That's an excuse Apple came up with after Epic Games sued them, there's no point in time I can point to where iOS is just the bundled OS vs. "paid for with app sales". The reality is, everything pays for everything, because Apple only sells fully bundled experiences. Their opposition to sideloading or third-party iOS app stores is only somewhat related to security[2], and more related to the fact that they don't want anyone dictating to them how the customer experience is, even if those changes improve the experience.
Well, that, and the fact that they make bank off App Store apps.
yeah, this just feels like one of those things that's begging for a lazy (on first use) initialization. if you can't share or transfer the socket between threads in the first place, then your code will definitionally not be planning to use the object in the main thread.
Why? We need to better quantify the damages, I suppose, to balance the risks and rewards. Like, my data was probably leaked here. If I didn’t peruse HN, that would probably never affect me.
I had missed the fact that Dagger is apparently trying to... replace? Docker for container definitions. That's a pretty big vision.
I really like the ambition here; it's very hard for me to translate this into belief that I could start using this now and actually replace some of my existing tooling.
At the same time, I kind of hate that they went for bash-compatible. I know everybody thinks bash is unbeatable, but at some point _surely_ we're going to move past its awful syntax and footguns (and SQL, and can I have a pony?)...
In theory you could replace much of Docker's low-level tooling with Dagger. In practice, that's not what we're trying to do. There's a lot of inertia to ripping out existing tools, and even if the replacement is better, it may still not be worth the effort.
What we're focusing on is green field application of container tech. Things that should be containerized, but aren't. For example:
- Cross-platform builds
- Complex integration testing environments
- Data processing pipelines
- AI agent workflows (where you give a LLM the ability to perform tasks in a controlled environment)
In those kinds of workflows, there is no dominant tool to replace - Docker or otherwise. Everyone builds their own unique snowflake of a monolith, by gluing together a dozen tools. Dagger aims to replace that glue with a modular, composable system.
How does that work? Are you building special adaptors that understand how package manager metadata files work? A deb package's postinstall is basically just a blob of bash running as root with access to the whole filesystem. If I tell dagger to install three packages in three different steps, those are not trivially reorderable operations. Nor are they reproducible at all, without Dagger having additional insight into the state of the local apt cache and what is offered by the remote apt repo at the moment of execution.
Yes, Dagger provides the core system API that allows creating and combining filesystem layers in any order you want. However it doesn't provide compatibility with existing package managers: that's something that you, or someone else in the Dagger community, would implement. You can extend the Dagger API with your own types and functions, then share them as reusable modules.
For example, here's a Dagger module for building Alpine Linux containers in an order-independent way. Under the hood it's derived from the 'apko' build tool created by the folks at Chainguard. https://daggerverse.dev/mod/github.com/dagger/dagger/modules...
And here's a Dagger Shell command for building a container using that module:
You mentioned deb packages. Your intuition is correct, Dagger doesn't magically make .deb or .rpm packages reorderable, since those packaging systems are designed in a way that makes it difficult. But it does provide the primitives, and a cross-language programming environment for creating the "adaptors" you described in a way that maximizes reuse. If someone does for deb what Chainguard did for apk, you can trivially integrate that into a Dagger module.
Neat! Okay, yes, I can definitely see the value here, particularly if all or most of an image is otherwise able to be expressed in terms of things that are deterministic, such as language ecosystem package managers with lockfiles.
It seems like you're cutting an interesting track on providing a better way than Dockerfiles with their imperative layers, but pragmatic enough to not insist on taking over the whole world like Bazel or Nix.
The Bash compatible syntax is just one representation of an underlying cross-language API. You can also write code in your preferred language, provided there's an SDK for it. (Currently: Python, TypeScript, Go, PHP, Java, Elixir, Rust, .NET)
But if you're talking specifically about shell or a "native" REPL in a safer language - I also want to scratch that itch. Some day I'll dust off https://github.com/vito/dash :)
I worked with the Dagger team on that. It was super hard to marry two DAG engines that work in opposite directions. The team eventually heard from users they wanted to write in the language of their choice, so there are now a bunch of SDKs.
I think one could wrap the Go SDK with CUE, and have oft considered doing it, but the work has not migrated from the backlog yet. I've been toying with a CUE powered monorepo DX CLI that is more akin to BuildPacks, using Dagger as the containerization layer.
I feel this is much more powershell like than bash. The container thing looks much more than a typed object than a plain character device/pipe. Also what is the bourne again part?
It’s def closer to powershell in all the best ways IMO. But the key point is that the container thing is actually a typed object. So is every other primitive in there including once you make yourself.
Is it? Docker is quite long in the tooth and this point and is a long way from perfect. Docker's design is rife with poor choices and unaddressed flaws. One I've been tracking for years: there is no straightforward way to undo several things that get inherited by derived images, such as VOLUME and EXPOSE, and Docker Inc. doesn't care no matter how long the github threads get.
I see this more as a complement. I wouldn’t stop using Dockerfile for standalone definitions, but for shell+docker+shell sandwiches (the second shell being inside the container), this looks very handy.
i want to move away from GitHub Actions and I also want to move away from some bespoke monorepo tooling for something that's a better overall orchestrator of 'things'. Dagger scratches some of those itches, or seems to, so I've had my eye on it for a while. Knowing that they're trying to also help me define and use containerized environments - I sort of assumed I'd have to bring those myself.
I'm using Dagger in a monorepo setup (actually several). For the main one, I've gone the route of wrapping the Dagger Go SDK with a custom Go CLI (plus CUE as another centerpiece). For sure, I've been making the team aware of the challenges and rough edges. (of course there are a lot of ways people organize monorepos, we are polyglot with one go.mod but multiple package.json...)
I'm largely replacing Dockerfiles and Makefiles with a custom CLI that wraps Dagger. Being able to use a proper language, functions, packages, imports is so much better by comparison. (ymmv)
Dagger looks nifty, but it's too bad that it's still basically an imperative "start from thing, do stuff to it, publish" kind of model, rather than just expressing a desired end state and letting an underlying engine find its way there.
Dagger is fully declarative. It's just built on a dynamic declarative API, instead of a static declarative DSL.
So, if you took Nix, and replaced the static scheme-like DSL with a proper API, and then built SDKs in 5 languages for that API; and then built a bash-like shell also for easy scripting; then you would start to have something that approximates Dagger.
Thanks for giving it another chance! We need to get better at explaining all this, it's a lot to unpack, although prior experience with declarative systems like Nix or Bazel does help a lot :)
We have a very active discord, feel free to come by and ask all the tough questions!
i'd read several state Ag agencies that have known this. It's why you keep watering newly planted trees even after their leaves fall, until the ground freezes. The roots will keep growing.
_thank you_. this is the comment i came here desperately hoping somebody had already made.
It's not that names are bad - it's that when you use intermediate variables, my brain has to check whether any of the variables are used more than once - i.e., is the flow here completely linear, or is there a hidden branching structure?
the chain of methods approach makes it _completely_ clear that there is no 'tree' in the code.
If you want names (and that's a fine thing to want!) then _either_ comments or defining separate _functions_, e.g `function messageRecipient`, `function friends`, `function visibleToScroll`) is the way to go. Although with many languages that don't have a built-in pipe operator, it becomes harder to express the nice linear flow in a top-to-bottom arrangement if you take the function route. A good reason for languages to keep converging toward syntax for pipes!
For my money, you only define those functions if you want to reuse them later - additional indirection is not usually helpful - so comments would be my choice if there were no other uses of these selectors.
I agree that commenting appropriately is desirable (I do more that I used to.) I also like the idea of const being the default, and for syntax highlighting that clearly distinguishes mutables.
I'm equal parts amused and bewildered that this author with so many interesting thoughts has managed not to see what pretty much every other serious reader of Lord of the Rings has pointed out over decades - the entire story is about a weak and almost completely unknown set of people who were "chosen" only by the most inexplicable series of events anyone could imagine - who through no inherent power of their own manage to save the world by nothing more or less than the choice to be kind to a pitiful (though clearly treacherous) creature... and who then go right back home where they belong, dismissing any notion of chosenness beyond the ordinary sort where everyone is chosen to do what is good for their neighbors.
the Hobbits pursued not greatness or destiny, but took the only path toward life available to them and then returned to let the rest of the world get on with living.
No. Good took the ring all the way to Mount Doom, resisting its Evil all the way up until the end, and then once more the Good person failed to destroy the Ring. Frodo stood at the precipice and took the Ring for himself.
The only way the Ring was destroyed was by accident when Gollum attacked Frodo to claim the Ring. The Evil that the ring stoked in the hearts of those it touched is what ended up destroying it in the end, not the Good people who took it to Mount Doom.
Gollum took back the ring after Frodo - possessed by the spirit of the ring and in its voice - cursed him with death if he should ever break his oath. Gollum did so the ring did, bringing about his downfall.
If you read Tolkien’s other works, you’ll find that evil cannot be destroyed as Melkor/Morgoth corrupted the very nature of the world and that evil will remain until the end of the world.
You have to go deeper than that, though. Eru Ilúvatar said this to Melkor:
> No theme may be played that hath not its uttermost source in me, nor can any alter the music in my despite. For he that attempteth this shall prove but mine instrument in the devising of things more wonderful, which he himself hath not imagined.
The idea being that the evil that Melkor commits ultimately just builds towards the creators greater and secret purpose. It's kind of an attempt to deal with the "problem of evil".
Aragorn can't defeat Sauron, though, and he knows it. His role in the final victory is to distract Sauron, who assumes that the ring will be used against him by a "somebody" like Aragorn, rather than destroyed by nobodies.
Their point seems to be strengthened by these facts. The story is about these people without any inherently powerful qualities performing a duty and going home without aggrandizing themselves. The fact that this happens in a world which has a “true King of Gondor” and these angel-wizards drives home how mundane and down-to-Middle-Earth Hobbits are.
I mean, yes, the hobbits go back home where Sam becomes the mayor of the Shire for 50 years, and Gimli and Legolas sail off together into the sunset.
But it's also unambiguous that Aragorn, who was previously a nobody raised by elves, turns out to be the long-lost king and definitely does not just go back to whatever he was doing previously.
> does not just go back to whatever he was doing previously.
He absolutely does. Being the future king was a core part of his character, everything in his life was preparing him for it. The book version of Aragorn doesn't have the hesitance to accept his duty that the films portray, he doesn't have to be prodded into it: his whole life has revolved around his future kingship.
In a lot of ways the book Aragorn is just as superhuman as Gandalf is. He's an archetype, not a perspective character. The hobbits are the only normal humans.
Aragorn begins Fellowship as the reigning monarch of "the rangers," actually a dispersed nation. They call him Chief to outsiders but his people know who he is and what he hopes to become. I reread the books pretty recently and this was one of the most surprising things that I forgot/got overwritten by movie characterization. He was never a nobody, by the time we meet him he is 40 years into the project of preparing himself for a great trial and then kingship.
> And Gandalf, who is not a man, but rather an angelic being (Maiar) sent to Middle Earth to sort out Sauron
But that’s just what all wizards are and always have been. It’s the only way to be a wizard. It isn’t, like, a hidden fact or anything. Wizard is a race not a profession. Like elf or dwarf or hobbit.
It really is, in-universe. Almost noone knows this save other maiar. The wizards are perceived as men by most people, them being maiar is far from common knowledge.
>the entire story is about a weak and almost completely unknown set of people who were "chosen" only by the most inexplicable series of events anyone could imagine.
The entire LOTR trilogy is meant to be “unapologetically Christian”. The intended point was basically the concept of having a cross to bear, as well as the importance of apost— er, friends.
There's a whole lot more going on in the story than just the hobbits.
And I think movie-LOTR-fans in particular are there at least as much for the Great Big Hero Chosen People Of Destiny aspects and battles as for the hobbits.
In terms of the positions of the characters in the narrative, yes, you're right. but in terms of the worldview you take home with you after reading... (or well rather a worldview that tech bros alledgedly leech themselves onto, if you will, because i don't necessarily agree that LOTR is all that bad)
Anyway. my take of tfa: in discworld, the whole system is designed for pluralism and messy progress. in middle earth, the entire universe is designed for epic quests and magical solutions from wise old wizards.
frodo might be a humble hobbit, but he's still caught in a deterministic prophecy machine where the fate of the world depends on ONE RING and ONE QUEST
And all this gentle falk bent before the chosen king and sang his praises, and some of them went to live in the immortal land of the god's chosen people beyond the curve of the world. Let's be honest, there are both heroes of might and humble hobbits in the book, but if Tolkin published only the Frodo chapters from books 2 and 3, Lotr wouldn't be the legend it is today.
reply