canvascritic

Most healthcare systems are not using Azure, AWS, or GCP

This may be true for some large players in coastal states but definitely not true in general

Your typical non-coastal state run health system does not have model access outside of people using their own unsanctioned/personal ChatGPT/Claude accounts. In particular even if you have model access, you won't automatically have API access. Maybe you have a request for an API key in security review or in the queue of some committee that will get to it in 6 months. This is the reality for my local health system. Local models have been a massive boon in the way of enabling this kind of powerful automation at a fraction of the cost without having to endure the usual process needed to send data over the wire to a third party

Healthcare organizations that can't (easily) send data over the wire while remaining in compliance

Organizations operating in high stakes environments

Organizations with restrictive IT policies

To name just a few -- well, the first two are special cases of the last one

RE your hallucination concerns: the issue is overly broad ambitions. Local LLMs are not general purpose -- if what you want is local ChatGPT, you will have a bad time. You should have a highly focused use case, like "classify this free text as A or B" or "clean this up to conform to this standard": this is the sweet spot for a local model

SnipVex clipjacking wallets is almost beside the point, the real failure is a printer vendor treating software like a side gig. Printer and hardware companies get a pass on basic infosec hygiene that would be unacceptable for open source maintainers.

until that changes, airgap your weird hardware setups I guess

Also this is a perfect storm for lateral movement. USB-borne worms still work frighteningly well in small biz environments, especially ones with no centralized IT and people plugging printers directly into Windows desktops with admin perms. Here SnipVex is just a cherry on top-a nice, opportunistic payload for the growing class of infostealers targeting crypto wallets

Real question is whether this is just symbolic or if the French state will actually redirect procurement pipelines + vendor mandates around these principles. i'd be more impressed if this came bundled with policy teeth, e.g. requiring all software vendors to deliver open-by-default interfaces or pushing funding toward open infra maintenance. Otherwise it's hardly much more than a manifesto

I'm not a fan of neurophysiology analogies because it veer into pseudoscience, but I'll play along.

Roam implemented static bidirectional links and called it associative memory. in reality, it's closer to mind-mapping software with backlinks. So without mechanisms for reinforcement (surfacing old notes intelligently), pruning (forgetting irrelevant junk), or plasticity (reorganizing in response to use), the system becomes a junkyard of half-formed thoughts.

Brains forget for a reason, roam doesn't

this all makes sense and is honestly the most coherent humanoid startup thesis i've seen outside of figure.ai. You're right that the unit economics of hardware are a trap unless you can commoditize the complements. And humanoid hardware clearly wants to become a commodity, but no one's finished the job yet and it seems brutally difficult (see: the ghost of Willow Garage)

The tesla analogy makes sense to me but with a caveat: they still spend billions on CapEx and own verticals like battery chemistry and drivetrain design. In this case you’re betting that the value collapses upward into software, like the shift from phones to apps, but for that to work, your software has to deliver exponential delta per dollar

With that I think the real risk is that your "clean your house" package is deceptively hard in the long tail, and you will end up with the iRobot Roomba UX. Novelty fades fast when it constantly gets stuck under the couch or whatever the equivalent of that is for humanoids. To be fair iRobot/Roomba is a household name but still "only" a ~$1.5B company, which seems meager compared to ambitions in this space

As an aside I would love to see an RFC-style doc on how you think humanoid software standards should emerge. ROS is still a frankenstein, and someone needs to kill it gently lol

When my grandfather died, the only thing he asked to be buried with was a small pouch of roasted chestnuts. he used to say they reminded him of long cold walks home through wartime forests that smelled like smoke and bark.

Anyway after the funeral, I cracked one open by the fire and it was still sweet. RIP baba

Thanks for the reply

IME the COTS angle cuts both ways. It brings costs down and makes iteration faster, but whats the moat then?

if the value is in integration, that’s fine, but integration is fairly fragile IP. Open source is good reputationally but accelerates the diffusion of your edge unless the play is towards community+ecosystem lock-in or being the canonical reference impl (cf. ROS, HuggingFace)?

This is a clever hack and a cute abuse of SQL joins to brute-force what’s essentially a 2-ply MDP over a finite space.

The core idea btw of using precomputed transition/score tables to simulate and optimize turn-by-turn play is a classical reinforcement learning method

What would be interesting here is to flip it: train a policy network (maybe tiny, 2-layer MLP) to approximate the SQL policy. then you could distill the SQL brute-force policy into something fast and differentiable.

i’d love to see a variant where the optimizer isn’t just maximizing EV, but is tuned to human psychology. e.g., people like getting Yahtzees more than getting 23 in chance. could add a utility function over scores.

Anyway this is a great repo for students to learn expected value optimization with simple mechanics.

Not surprised to see this. Whats interesting to me in all this is the misplaced faith in emergent structure.

Roam bet on the idea that if you link enough atomic notes, structure will self-organize.

Which is such a weird fantasy if you spend a few minutes thinking about it. Try writing code like that or building a company or just about anything else! Why should notetaking and archive development be any different

It's clear you need some sort of editorial hand to create something maintainable and future proof. Like zettelkasten had Luhmann’s obsessive discipline behind it. Evidently roam had um. enthusiasm and javascript?

and yeah, it’s telling that the comparison is to IDEs. Imagine an IDE that dumped every snippet you typed into a graph database and expected you to recompile coherence out of it by browsing links. thats what roam felt like after the honeymoon.

In general most of Roam's target should want to lean harder into opinionated workflows. there’s a reason tools like linear or notion are winning. they’re structured enough to relieve cognitive load, flexible enough to adapt. Roam tried to be emacs, but turns out most users don’t want to configure their own productivity dialect.

also, lol at the idea of "automated taxonomy". The entire knowledge management industry keeps rediscovering ontologies like they’re new. We are probably going to reinvent OWL at some point and give it a name like "neuroschema" or something

Heh. This landing page takes me to somewhere between deepmind circa 2014 and tesla's AI Day press decks.

I mean if you're actually training humanoids in under an hour with sim-to-real transfer that "just works" then congrats, you've solved half of embodied AI

the vertical integration schtick (from "metal to model") echoes early apple, but in the robotics space that usually means either 1) your burn rate is brutal and you're ngmi, or 2) you're hiding how much is really off-the-shelf

Clearly the real play here, assuming it's legit, is the RL infra. K-Sim is def interesting if it's not just another wrapper over Brax/Isaac. Until we see actual benchmarks re say, dexterous manipulation tasks trained zero-shot on physical hardware, it's hard to separate "open-source humanoid stack" from the next pitch that ends in "-scale"

Clearly a labor of love. Props to you

I suppose if one is teaching or evangelizing constructor theory, this could be sort of like an interactive textbook

Needless to say, constructor theory hasn't really earned a stable foothold in mainstream physics, and there's a lot of hype in this space, but that's not a criticism of this particular project, just good to know for anyone not familiar

The quantum gravity + graviton tasks stuff especially. without a falsifiable physical model backing it, this can feel like mathematized cosplay. But that has more to do with constructor theory vs this project

Would love to see someone do a pluggable backend so you could test different "task ontologies" against each other.

Mainly I came here to say that categories can likely be used to great effect here a la Geroch

For instance you can start by modeling tasks as morphisms between substrate states (objects), and then enforce composition explicitly. define constructors as functors that map tasks and substrates while preserving structure.

for quantum or irreversible effects, use monads to encapsulate branching and decoherence. Then one could represent task sequences as categorical diagrams and check for commutativity. Or embed substrates via Yoneda to expose behavior in terms of available tasks

Right: Maya is a "language continuum" in the sense that geographically proximate speakers tend to understand each other well, and intelligibility goes down as you move further away from any given individual on the continuum

I use nearly of these tools with the exception of Perl. I go to great lengths to make sure I have access to them because it's so critical for quality of life. I love them and I understand why people love them.

Here's the reason: these languages/tools are tactically very powerful. Tactics are immediate and decisive. Tactics are effectively tricks in the sense that if you can "spot the trick", you can -- with a tiny amount of work -- reduce a formidable problem to virtually nothing. Having a vast toolkit that facilitates such tricks is incredibly powerful and makes you appear to have superpowers to colleagues who aren't familiar with them.

But tactics are definitionally short-term. You deploy them in the weeds, or at least from the forest, (hopefully) never from the skies. Tactics aren't concerned with the long term, nor how things fit together structurally. They are not concerned with maintainability or architecture.

This is why it isn't actually that important that you can cobble together a 15 line Perl script in an hour to do something that would take any of your colleagues a week. Years from now, when you are gone and someone runs into a similar but slightly different problem, someone will find your Perl script, not understand it, and rewrite it all in Java anyway. Or assume it's too hard and give up. Maybe they will adapt your Perl script, but more likely it'll be seen as a curiosity

It sucks, because there is beauty in that approach of solving problems. As I said in another comment, I wish there were more diversity in tooling and languages. But at the same time, it's important to consider that people are fundamental. All of this is in service to that. And I personally would rather build software that people use over the long term.

It's not learned helplessness et al, just a plea to drop the smug elitism if you want people to take you seriously. I actually want nice things, I hate writing brittle systems in languages that offer no meaningful guardrails, and setting up Rube Goldberg contraptions to get a poor approximation of e.g. basic BEAM runtime functionality.

Any success I have had in getting very boring companies to adopt nice things at all has not come from insulting people's intelligence and acting like I'm the smartest person in the room. I despise this kind of elitism that is rampant in certain technical communities. It turns people off like nothing else and serves no purpose other than to stroke your own ego -- it's pointless meanness.

You are missing my point. For transparency, you are talking to someone who writes Racket in emacs on my Linux desktop, has used Rust macros to clean up awful code in widely used open source packages, and regularly generates code for all manner of purposes in lots of different languages. I know the slam dunk feeling of generating exactly the code that will topple a problem -- and I also know it's not actually that big an edge!

It matters little that you can generate code in an hour that would take your colleague days. It is nice for you and it provides a short lift for your team, but in the limit what matters is maintainability. Peter Hintjens writes fondly of metaprogramming and code generation, but also warns that it makes it difficult for others to work with you, and it's easy to fall into the trap of building abstractions for their own sake. The "edge" in technical work comes from seeing both the forest and the trees, and missing that technical work is in service of humans, first and foremost.

I am glad you enjoy writing Perl, and I like encountering people passionate about it in my work. But I still think there are good reasons why it's in decline, and Perl users should reflect more on that rather than assuming people aren't using it because they are dumb / not technical enough / don't think about problems as creatively or deeply.

I agree with you that it is sad there isn't more diversity in languages and tools, and that generally organizations are using the same terrible slop. We could have such nice things

You lose me with the smugness. Make no mistake, you aren't smarter or better than someone else purely by virtue of your willingness to hack on BEAM languages or smlnj or Racket or whatever languages you like. There are probably people smarter than you working in sales at $bigcorp or writing C# on Windows Server 2008 at your local utility. Novice programmers often have an instinct to rewrite systems from scratch when they should be learning how to read and understand code others have written. Similarly, I associate smugness of this form with low capacity for navigating constraints that tend to arise when solving difficult problems in the real world. The real world isn't ideal, sorry to say

I'll be frank: I think this idea that ${faveLang} is for misunderstood geniuses who truly understand computers where mainstream languages like Python are for dunces who only know how to glue together APIs is a large part of why such languages as Perl are nearing extinction. It turns out that there are people working on challenging problems in domains you've never heard of in Python -- and pretty much every other language. Give it a rest

In the real world, the ability of a lone genius to cobble together a script in an hour is actually not that much of an edge -- it is more important for people to write something that others can understand and maintain. If you can do that in Perl, great, and if writing Perl makes you happy: also great. But beware that smug elitism turns people off, it kills communities and also tends to signal a pathological inversion of priorities. All this should be in service to people, after all

This is awesome! Finding an AGN within the halo of a galaxy, especially one as well-studied as the sombrero galaxy, is a bit like discovering a hidden room in a house you've lived in for years. it reshapes our understanding and invites us to question our observational techniques and tools.

also: barred spiral galaxies like the Iris are super neat. If I'm not mistaken (I'm only casually interested in astronomy, not a professional) bar structure is thought to play a crucial role in galactic evolution, funnelling gas towards the center and potentially feeding the AGN. the discovery of an AGN in such a context could shed light on the interplay between galactic morphology and central activity.

I first learned about the microseasons during my second year in Japan when I was wandering thru Tokyo one day in February, and had an experience that introduced me to the bush warblers singing microseason.

I was looking for this bookshop owned by an older woman named yumi, who supposedly had a collection of ancient poems and stories, many of which encompassed the lore of the 72 kō (I never did end up finding it, sadly I had to leave Tokyo the next day, but would be nice to know if someone here has heard of it / visited).

while weaving through the backstreets of shibuya, i was entranced by a faint, melodious chirping that seemed out of place amidst the city's usual cacophony.

Following the sound, i found myself before this dilapidated, ivy-covered wooden house. A hand-painted sign hung at the entrance. "Oshiro's birds" I think it said

Anyway Oshiro was sitting outside and graciously welcomed me in. His living room was packed with birdcages, borderline horder situation. but everything was in beautiful condition, meticulously cleaned. Each cage was home to a bush warbler. the air was filled with their songs, transporting me miles away from the city, to misty mountains and serene valleys.

Oshiro explained the Japanese microseasons to me, and told me about a centuries-old family tradition that centered one in particular. every year, around the onset of february, when the microseason announced the singing of bush warblers, he would embark on a pilgrimage into the mountains. there, he would sit for hours, sometimes days, listening, absorbing, and sometimes even conversing with these birds through his bamboo flute. It was a ritual passed down through generations in his family.

I spent that afternoon with Oshiro, sipping on aged sake, as he told me about his strange (to me) ritual. He played his flute a bit, its notes intertwining with the bird songs, creating a symphony that felt as old as the mountains themselves. Each chirp, each note, was a story, a memory of ages gone by.

as the sun set, casting a golden hue on the room, i realized i hadn’t just discovered a bird enthusiast. in Oshiro, i had met a guardian of time, a man who, year after year, preserved a slice of japan's essence, ensuring that even in the heart of its busiest city, the song of the bush warbler would never fade away.

It is pretty beautiful how such small, centuries-old traditions seem to abound in Japan, where the condition of the west seems to be a state of persistent impermanence.

A few scattered thoughts:

Firstly, the amalgamation of custom data sources via RAG pipelines sounds enticing on paper, but there are inherent complications. when fusing disparate data silos, considerations around data normalization, entropy reduction, and the potential amplification of noise-to-signal ratio are paramount. simply bolting on data to an LLM doesn't guarantee efficacy.

Then there's the underlying premise of using LLM as a primary UI model. while GPT and its ilk have made waves, a chatbot interface has inherent limitations. there's the conversational depth challenge, context retention gaps, and the non-trivial issue of multi-turn dialogues throwing off the model. Not to mention, the computational overhead of on-the-fly, real-time retrievals needs to be closely monitored to avoid a latency nightmare, especially if the knowledge base grows.

Further, there's a certain laziness in simply bolting on an LLM chatbot interface, which isn't appropriate for all settings, and can present accessibility challenges.

Speaking of the KB, the two-stage process delineated – indexing and querying – while conceptually sound, often buckles under scale. Memory networks and transformer architectures have their limits, and I'm curious about how LlamaIndex circumvents these bottlenecks.

also, leaning heavily on Streamlit could be a double-edged sword. Can anyone speak to its adaptability in production environments, especially under high concurrency?

anyway, I think it's important to bear in mind that chatbots and LLMs are tools, not magic wands or universal hammers

The real challenge with AutoML isn't just the pipeline creation, but ensuring that the models generalize well to unseen data and real-world scenarios. Your project here is neat and I appreciate that it includes support for preprocessing and model explanations as these are often overlooked.

I wonder though about the robustness and reliability of the models it generates. automl, in its essence, risks overfitting or underfitting if not carefully managed, and introduces a layer of indirection that can make debugging far more difficult. how does this project avoid those pitfalls?

It would be interesting to see how your tool performs in diverse datasets and how resilient the models are against drift over time. nevertheless, it's always good to see new takes on AutoML. keep probing the space and refining your approach

back when we were scaling a saas offering in the late 2000s, we were told by some sales 'engineer' at a certain company well known in those days with lots of hype marketing (that died explosively a year later, big shock), that ML would solve all our engagement problems. It was hyped up, just like AGI is now. the reality? it has made a difference, no doubt, mainly in the form of incremental improvements at best. this feels eerily similar.

I've sat in countless pitches and meetings with bright-eyed founders touting the imminent rise of AGI. There's a palpable excitement around the topic, but from a purely business perspective, there's an equally strong air of naiveté.

I often wonder if proponents of AGI have truly considered its commercial implications. let's indulge the idea for a moment and say that it becomes a reality. how do you price it? how do you convince industries to adopt and trust something that mirrors human cognition, with all its opacity, when we still grapple with the biases and imperfections of simpler AI models?

add to this the astronomical R&D costs. the sheer capex required is a massive barrier. even with vc backing, the path to profitability seems tenuous at best. and in our current startup landscape and inflation reality, such ventures are money holes.

to me, AGI feels like childish pursuit of the shadows of sci-fi dreams. there's merit in pushing the boundaries of technology, but mistaking theoretical marvels for immediate commercial viability is a classic pitfall. for now, I'll reserve my enthusiasm until someone can convincingly bridge the chasm between agi's promise and its pragmatic business value.

A mentor once said to me something to the effect of "don't optimize for the noise - optimize for signal"

These guidelines, in many ways, embody that sentiment. While some might complain they are restrictive and harsh (I think, for example, of new commenters being met with a swift downvote to oblivion when they comment "me too!" or "cool!" on a thread), I view them as a way to elevate discourse, prioritizing the depth and quality of conversation over fleeting internet trends, a beacon of light in this sorry internet that mostly devalues thoughtful discourse and inquiry.

Understanding the dynamics of a community and its shared norms can be as important, if not more so, than the actual content. in nurturing a thoughtful environment, in particular an environment that nurtures curiosity and civil discourse, we're not just preserving the present, but serving as role models for tomorrow's communities. personally I'm glad that HN emphasizes intellectual curiosity and mutual respect. this is truly a special place

Early in my career, essentially a lifetime ago, we were launching a new line of eco-friendly kitchenware. My team was divided on two messaging approaches. One camp believed in the emotional appeal: serene images of pristine forests, juxtaposed with families using the product, essentially proposing that using our product was akin to saving the environment. The tagline was something pithy to the effect of "embrace nature, one meal at a time."

The other approach was more socio-culturally driven. In particular, it focused on communities that had traditions rooted in nature conservation. the advertisements showcased local figures, elders if you will, using our kitchenware while sharing age-old wisdom about respecting the environment. the tagline was (something like) "honoring traditions, preserving tomorrow."

We ran both campaigns in a split test across multiple regions. to our surprise, the socio-cultural campaign outperformed the emotional one by a substantial margin, especially in regions with strong cultural ties to nature, like certain areas in the Pacific Northwest and parts of New England. Follow-up interviews revealed that people felt a deep, personal connection to the community-focused ads. They felt that the product wasn't just another item but a bridge to their roots.

All that said, even with that and other similar experiences over the course of my career, I'm bearish about completely sidelining the more automatic responses ingrained in us. While cultural imprinting and rational processes play significant roles in decision-making, it's probably a mistake to entirely dismiss our primal instincts and inherent biases. They've evolved over millennia and shape much of our intuitive reactions, long before conscious thought even enters the equation.

I appreciate the author's attempt to contextualize web components, but I have a few bones to pick, having seen web components used to a pathological extent in various projects

First, the idea that one of web components' strengths is bypassing serverside rendering is a bit misleading. SSR has been foundational to reducing time to first meaningful paint, ensuring accessibility, and improving seo. to argue that bypassing it is an advantage seems antithetical to best practices, even when using client-side tech like web components.

Second, the transition example from react to svelte highlights the use of web components as a bridge, but I fear it oversimplifies the reality of such transitions. Its true that web components might provide a superficial level of interoperability, underneath, the application architecture, state management, and data flow can differ vastly between frameworks. Simply plopping an old component with a new one doesn’t mean they’ll play nice without substantial architectural considerations.

Finally, the mention of "no bundler, no transpiler" as an advantage is curious. in practice, the modern web development ecosystem has moved towards using tools like bundlers and transpilers to optimize delivery, reduce overhead, and facilitate modular development. this isn't about complexity, but rather about efficiency and best practices.

Web components certainly have their place and, used judiciously, can certainly add value. It's just essential to approach them with a nuanced understanding and not as a silver bullet.

Appreciate your insights. A few comments/responses

1. Agree on the introspection point, but it's worth noting that the future of LLMs might involve self-awareness capabilities, which could provide an introspective mechanism similar to SQL's transparency. the aim would be to build upon this middle layer, not blindly supplant it. 2. While 3NF, BCNF, and other normalization forms have served us well, they are essentially tools to manage imperfections in our storage and retrieval systems. LLMs can be trained to understand these nuances intrinsically. additionally, database theories have evolved, with advancements like distributed databases, graph-based models, and nosql. so, it's not entirely outside the realm of possibility that we can pivot and adapt to new paradigms. 3. The "translational losses" referred to the semantic disconnect between natural language queries and their SQL representations. while SQL is unambiguous, the leap from a user's intent to the SQL formulation often introduces errors or inefficiencies. LLMs can be trained to improve over time, constantly refining based on feedback loops.

not arguing that SQL or databases as we know them are obsolete today, just advocating for a more imaginative exploration about where the tech is headed.

Stumbled upon norvig's pytudes years ago during a leetcode grind. His elegant approach to problems always had this touch of clarity that only few possess. Python, with its expressive syntax, combined with norvig's penchant for crafting illuminating examples, has definitely provided me with numerous 'aha' moments. I recall, early in my career when learning about bayesian probabilities, that it was peter's "how to write a spell checker" that made the abstract concrete for me. it's really heartening to see such a legend continuously contributing to and enriching the programming community.

SQL makes the most sense if humans are going to be programming deterministically, but if we're talking about natural language input I can't help but think that compiling natural language to SQL feels a little shortsighted as a long term strategy.

Surely it makes sense for a MVP, but I'm curious about how much we're potentially forfeiting in terms of innovation by anchoring so deeply to it with all the possibilities afforded by generative AI. In holding onto SQL, might we be forestalling the development or adoption of a more evolved language? With Dataherald's proposition, how do you envision maintaining that cutting edge, ensuring you're not just prolonging the lifespan of a fading tech, but genuinely pushing the envelope forward?

I suppose one intriguing possibility in my mind is that Dataherald could serve as a bridge or runtime. As you continue to develop and refine the tool, do you see a future where it might support more abstract querying languages or even emerging data interaction paradigms? This could potentially mitigate some transition pains when the tech ecosystem eventually shifts.