The submission itself talks about creating & loading snapshots, which is sort of a Checkpoint Restore In Userspace (CRIU), allowing one to create a new context with a lot of existing libraries already loaded very very quickly.
There's hundreds of programs that can be scripted with embedded Lua. For example, nginx web server, or neovim editor or awesomewm window manager. Having an embedded scripting language gives these systems enormous flexibility & utility.
This series is effectively about doing the same, but embedded Deno instead of Lua. It's showing how to launch Deno runtime, and how to seed those runtime with various hooks to access & manipulate the program it's embedded in.
There's ~60 different things we run. It would be tempting to try to make some kind of a group scheduler. But on the other hand, we get some nice load levelling/load-averaging from having mixed processes. Ultimately there's not really any reason for us to have static linking, but it's just "how it's done" now and it's unquestioned and there aren't as many well established alternatives as there ought to be.
We run hundreds of processes on big nodes at work & we absolutely would save hella hella memory & have way better cache utilization if we could share the massive massive massive reams of code each process duplicates for itself.
Static linking is basically like running Electron. You take a wonderful multi-machine capable environment then use it to run a single thing, exacerbating the size of what should be minor overhead.
As a Linux user, there's like 30 dependencies used by basically half of what I run. If you click in to the article & look at the first chart, it shows this clearly: it tapers down quickly yes but so what? What actually matters? There are a good solid chunk of core libraries used en volume. You dont save much disk space, yes. But many libraries are used by many-hundreds of consumers. Thats where the pain is, that's the loss, that's where you are burning memory space again and again and again with every process you load, and worse, is the cache you are contesting for no reason. You could share that. You should. Giving it up is only because someone has decided it's too hard & too difficult to try,.. and sometimes they are right. But most Linux distros have been working through & managing it & doing ok for years.
Dynamic linking is the shit! It's so undersold. Static linking has been convenient & simple, but it gives up so much awesomeness.
On consumer systems, memory pressure is real, and being able to have quarter your program be effectively free is enormously helpful. Cache hits also go way up, which can be even more vital.
Server side, it depends. If you just run a db server and a monolith, it indeed doesnt matter. But if I look at the hosts we run at my work, if you look at many clusters, they're big nodes and they're running hundreds of processes. If we could get back decent double digit percent of memory that would be great. If caches would get more effective that'd be super. We're leaving a ton on the table because nothing is shared.
There's similar works to win back basic obvious performance happening in a number of places. Composefs has shown up on HN a couple times, trying to let containers effectively share files & page-cache.
Will I deny that dynamic linming has brought pain? No. But I think it's important to recognize that this is a fallback position. If we were better about not breaking conpatibility, not introducing changes, this would be less of an issue. If we had better software testing that could help us detect & see incompatibility faults as they arise, if we could canary test a new software Bill-of-Materials & have some early indicators, we might have, a decade ago, not collectively decided to give up & give in to "binaries just work".
"Why is the JavaScript ecosystem like this?" is a very similar complaint, where containers are again the dead-easy obvious answer (to almost everything, Mysql vs MariaDB difficulty remains).
Making stuff work together isnt always easy. Having a predictable easy to manage unit can be really nice, offload the particular ecosystem concerns & get folks to "just use it" places.
Also recently submitted & on the same topic of effective innovation driving & organizational wayfinding, "Andy Grove on dynamic dialectic"[1], which nicely laid out some of the core top-down vs bottom-up struggles. It pegged bottom-up as "chaotic but smart".
Grove talks about something mentioned very early on in Alex's webpage[2] (right under the top link, to a genericized/not-Google-specific Slime Mold presentation), leadership of the gardening style (although specifically Komoroske is talking about gardening platforms). Making sure those with potential & good ideas are enabled, might be how I'd describe it.
On a personal note to me, it's amazing how much we assume - have left individual isolated groups/teams connected upwards & sometimes side-ways as the organizational structure. Leaving only higher up levels of the org structure to mediate & suss out truth, not having workers also put in their bid for how other projects should execute or where priority should be is the practice. Im fascinated by the potential of trying a more connected & aware org, where we try to spend more effort internally communicating & sharing bids for where we think we ought be placing our efforts, where we ought be redirecting or reshaping efforts.
> There is one main reason I can think of. GNOME is the most used desktop environment, therefore it is the most susceptible to gain demands and pressure from users and companies.
Being the biggest isn't cause enough for this perception.
GNOME, in the past decade, put itself in a remarkable position of prioritizing a perpetual-neophyte persona, who did not & didn't want to understand computers, and rebuilt the product around that persona. For a corporate desktop, where random people are handed GNOME & told they have to use 1 app or maybe 2 or 3 on a computer, this is perhaps reasonably well calibrated. Look at many who fund GNOME Project, and this vision makes sense. But GNOME is a Linux desktop environment, and they have Linux users, and it turns out this chosen persona GNOME Project fixated on doesn't only not line up very well, it actively rejects the premise of supporting the explorer, the tinkerer, the hobbyist, the learner. GNOME Project is quite literally the most visible open-source project on the planet, yet it has the most actively anti-open behavioralism & targeting of probably any open-source project. It's chosen a bounded mission, a narrow one, with incredibly bounded behaviors, and that runs counter to the open-source spirit of possibility & exploration.
> If you dislike the GNOME Project’s philosophy, then the solution is to simply not use GNOME.
In case you missed it the first time the author said it, the author comes back to re-confirm: GNOME is "my way or the highyway."
GNOME is uniquely unflexible in almost all open source software in being so narrowly focused. Unlike most open source software, where adding features & options is usually acceptable in some form or another, given compromise, GNOME believes in their one and only one persona, in the overarching vision of an extremely limited capabilities user. I can think of no other project that makes anti-flexibility such a priority, except maybe suckless, and frankly their extreme conservatism & excess of attitude & loudless is quite a turn off as well.
I've painted a pretty grim picture of what I think of GNOME Project, and I'm sorry to shove them under the bus like this because I think there are noble ideas mixed in with the totalitarianism. But I think their objectives are delusional & off-base, and need re-assessing dearly, not just because many users don't fit their model, but because their model of what a user is is actively bad & harmful & condescending & makes things worse.
To give a nod to GNOME though, the author's other article on the GNOME libadwaita controversy[1] is fairly good in many ways, & talks through some of the pain & complexity & how difficult it is being such a highly visible project that other folks push-the-boundaries on. Freedom leads to "mis-use," what GNOME Project seemingly lives in mortal fear of. The article isn't perfect; I think their KDE examples are 98% horseshit justification (the first qt5ct example feels like strong support that themes work to me, not that they are bad, and most of the rest of the examples are of bad hardcoding that apps should fix, not systematic issues. And the net positive of not needing fractional scaling & being able to adjust your theme seems enormous.). But the support burden experienced by GNOME seems legitemate & real: flexibility has problems. Being an absolutist project that believes in yourself & picks a way & tells everyone else to hit the highway, we don't want to do it is indeed a powerful technique to maintain quality & reduce support burden.
This all circles back to a topic I mention time and time again: the Cathedral and the Bazaar. The "Bazaar" model of software development is complex & hard & there's always unpolished things happening at the edge & sometimes pieces of it stop making sense. There's a alluring temptation to centralize, to pull in, to stop exploring, to obstruct users from going off the careful paths you've built for them, to marshal control. Many people in the world cry out that we must give up the Bazaar and instead build "Cathedrals." GNOME Project decided at some point to become Cathedral builders. And that means telling a lot of people to hit the highway. And alas, it often seems like a Cathedral built primarily corporate users, not actual living flesh & blood humans.
Postscript: as with most do-we-or-don't-we software discussions, I highly recommend "Notes from the Mystery Machine Bus"[2] for more framing, that talks about stances of acceptance vs control. It's helpful to think of GNOME in this framing & it's helpful to think of your own & others around you's approach to code. Recommend.
Social media is distinct in that it's not one thing, one experience.
It's many different experiences, that users are cut between, exposed to. Where-as calling a friend every hour doesnt make sense & would get repetitive, one can just drop into the feed of experiences whenever they want.
Your point remains, certainly. But I do think there's a kind of unbridled access to novelty & other-peoples-creativeness that is indeed remarkably blunting when compared to most personal lives & options we'd have.
Oh man the book both glorifies but also does a good job to me of making it all look crazy, not held together, just barely going, politically isolated.
That there was a cause, a mission was do much a product of the early times, when we just didn't know as much yet, weren't nearly as professional or well set yet. That's a little less apparent.
Small detail, but interesting to see varlink capabilities added.
systemd-resolvd gains "monitor" capabilities via the lightweight json rpc system varlink.
definitely useful just for monitoring dns broadly, seeing whats happening on the system. there's probably some more specific creative uses folks could hack together here.
Specifying embedded ML systems specifically is an interesting specialization:
> Our team in Google Research has set out to solve this problem by building a provably secure platform that's optimized for embedded devices that run ML applications.
Watching Google leading the transition, of the web from a hypertextual, common, extension-able user-agency-embue-ing medium, into an unmalleable, hard, pushing-pixels-in-our-faces application is one of the most evil malignant acts I can imagine being perpetrated against good upstanding tech society has. This is such a huge step into the dark, out of the sun, for the world wide web.
Since there's no other such comments, I'm just going to chime in & say I'm extremely sympathetic.
This is a classic case of confusion, of two things being mixed together & fused, in terminology, when they are distinct areas. Our languages are, as many commenters point out, flexible & changing. But when that flexibility leads to the distinct & clear becoming mixed & hazy, that is usually a loss.
I want to present another way of looking at this, & identifying it as a brilliant move. This is just one lens, not representative of what I really believe, but I think it's an important lens to pick up & assess by.
Facebook makes a ton of cash, and wants to be a place where sharp, bright, talented engineers want to come work. But the family of apps are all semi-done products; they're late industrial creations, heavily refined, and there's just not a lot of open possibility space to do good things with them.
Meta is a break. It's a way to create new grounds, explore new ideas. Whether the ideas are good or bad almost doesn't matter, compared to re-creating a company with some real will, drive, & possibility in front of it. Unchaining yourself from the town-planner stage of maturity that you've been whiling away at for almost a decade & creating permissions to try interesting things, to make new space where you're not always stepping on legacy concerns: I almost can't imagine not doing this.
And Meta has a fairly catchy, nebulous set of ideas behind it. It's difficult to imagine how Facebook/Meta can really make anywhere near as much impact, make a clear win here. But I'm at a loss to think of other bits of terrain that are both not-yet-settled/won, and simultaneously as compelling & interesting to a potential employee-base. If I ran a hugely successful company that had more-or-less established itself & wasn't in existential peril & falling position, I'd be asking myself the same question: what would be fun for us to do? What would keep my us well engaged & might possibly yield some epic shit? Meta is a not bad answer.
The world wide web used to have a host of proprietary servers for it, but those for the most part got eaten by Apache (which latter renamed to Apache Http Server). And then a host of new open-source http servers and libraries.
Sometimes what's good for markets & the world doesn't have to be owned & commercial. Sometimes the availability of resources such as info-resources like httpd can beget enormous commercial success while themselves not having much commercial success.
A Tim O'Reilly saying comes to mind: create more value than you capture. In some cases, without setting free the core idea & letting people run wild, you'll never stand a chance of capturing any value what-so-ever.
You have some values stated for these lessons, but I have a hard time imagining a teacher finding ways to bridge the gap with a student or the class & make seen these somewhat adult perspectives.
This last is way off in the weeds, but formenting insurrection is often a noble & virtuous thing, change often is direly necessary or more worsely overdue. There is a huge amount of fumbling & failing that often prevents good execution, that ruins follow through, & we see in history so many pendulums of society swinging & counter-swinging wildly around one another: this is purely my personal opinion, but I for one don't de-rate the attempts just because it keeps being really really hard (& often woefully mis-done!!). I think the effort to try is gloriously humanistic, challenges be damned. No, hungry for the challenge, the chance to improve. An agency of last & too often necessary resort.
What I would judge might-be insurrectionists on though is their cause. It's easy for groups to be riled up, to let one's group escalate itself rapidly towards inssurectionist climax, to mantle oneselves with cause. Whether you search for some objectively worthy (legible) truth or cause is important. Having a strong epistemic basis is important.
I liked almost nothing about what has recently happened & I think we probably agree a lot about how history isn't/might-not-be useless, & that modern times have shown some real grade-A fuck ups vis-a-vie that all. But still, it feels important to me to not condemn insurrection so widely. As a communist, it certainly seems like insurrection remains necessary. Outcomes haven't been good but the revolutionary spirit dwells in all our hearts, amid the beautiful, high-agency/highest-agency better-possible selves we might have had in us.
It's also why I think the web is unlike almost everything else in computing: it's a high agency environment. Applications afford you certain options, but the web has historically offered great agency to the user. Extensions and user-scripts allow for quite a wide range of alterations to be done! I use the DarkReader extension for example, which makes almost all sites I visit "dark mode". There are ad-blockers, form history control programs, word count programs I make use of on a regular basis. Someone a couple hours ago was complaining about certain sources on HN and asked for them to be banned, and it took me less than 5 minutes to scratch together a userscript they could use to filter their experience in a way they desired[1]!
Thinking of the computing medium we are given as just a start, a launching point, that we inject our agency & prowess into: that constructivist, can do mentality is everything to me. It's completely unmatched, incomparable to everything else I've seen in computing. Having a core medium, and the viewing system decoupled from it, ready to help us do better, has made all the difference.
There's a lot of not-so-great modern web sites, that make things rough. I tried to help someone recently who was asking about scripting a React site[2]. Most of the times I can eventually wrestle the vdom into shape, to make it do what I want, but here the poor user was facing draft.js, a nightmare hell-mode take-over of the browsing experience by a large pile of software that thinks it can do better. Poor user was never going to win. There's all sorts of anti-user potentials to the modern web. I disagreed hard with a refusenik reactionary "the web browser I'm dreaming of" yesterday, but agreed[3] a) that the user should have choice/agency about what they want enabled and b) that certain technologies are an existential threat to agency, chiefly WebAssembly, which further heightens the impossibly of user-agency on the web. I've been quite a jerk to Flutter's CanvasKit a number of times, because it turns the web into a giant television tube that blasts pixels in our face, destroys the hypermedia basis that web engagement has been built around. Threats to user agency, to a modifiable web are everywhere, and plenty of folks simply tell me I'm full of shit, that I'm delusional for thinking the web experience is user programmable. They're not so far off the truth, especially in the days of virtual-dom & react, but I think that's an industrial convenience we've been taking advantage of, and that ultimately we'll see pressures to use the medium more respectfully, to use Custom Elements & other technologies that return some primacy to the DOM, rather than floating off into the virtual forever & treating this medium like an end-target to be made to dance as the large overgrown industrial toolkit + application so desire. There has not been a lot of progress in that direction, and weirdly: that gives me hope. It makes me think we are rife for disruption, that when good folk start trying to understand how not to do harm in their web-application-development, there will be leaps & bounds, huge strides. Meanwhile React &c are definitely mature technologies at this point, excitement has winnowed away, advancement comes in little tiny pinprick bursts. A more hyper-textual medium is possible, this ascent of code over medium doesn't require a total rewrite: we can make the DOM powerful again, make a pro-user, pro-manipulable, pro-rich media experience again. JS will be with us, but woven through the media, rather than hijacking & parasite-ing off it. I look forward to rich internet hypermedia becoming a powerful, expressive, user-manipulable system again, as the web once so powerfully was for users. This would be such a sign of progress and respect: for the web to put the user first again, to make the medium something shapeable by user-agency. I believe those days come.
Computing was always, to me, so compelling because it enabled the limitless virtual, because we could go anywhere, do anything, go wherever we might think. But I see few other places in computing where the frontiers continue to open, where we ennoble & enable the agency within each of us. The web remains one of the rarest finest gems of computing, where agency remains vastly possible & expanding. So much of the rest of computing feels settling & shrinking, receding ever further within the firewall.