Shouldn't Jev-like models be built on top of diffusion models ? like GSAI-ML/iLLaDA-8B-Instruct ?
That showed us the best results at least
661 karma · joined October 31, 2014
That showed us the best results at least
It's fun to see someone being able to exit so well without owning any model.
I initially thought the containerization movement of the early 2010s would be the first step toward redefining the OS—a way to finally slim things down. Instead, it just became a more efficient way to pack up the same baggage. We created a "reduction" in deployment complexity, but we haven't seen a continued effort to use those tools to actually change the paradigm.
I expected vertically integrated systems to become the norm by now—where building an executable would be an experience similar to containerization, but resulting in a lean, data-centric unikernel.
Instead, we are burning CAPEX on YAML sidecars in K8s clusters and N-tier abstractions that exist solely due to the large heterogeneity of the deployments that they never should have entered in the first place. We are spending more energy on the friction between layers than on the actual business of computation.
I was hoping for a return to sanity with the DBOS [1] research, looked like an attempt to rethink systems from first principles. But it seems that effort hasn't fully kicked off in the way the industry desperately needs.
After my old homelab laptop died, I decided to over-engineer its replacement.
A question for the homelabbers and infra folks here: Do you actually find value in people open-sourcing their personal infrastructure repositories?
All of my configurations are currently in a private repo because they feel too customized to my specific environment (domain names, specific storage tags, etc.) to be useful to anyone else. Have you ever genuinely learned from or reused someone else's opinionated personal configs?
Happy to open mine up if people find that kind of reference material helpful.
Also happy to answer any questions about the Turing Pi hardware or the Talos experience!
I wrote this post after giving a talk on AI to a non-technical audience. I found that the analogy of baking a cake without a recipe was a powerful way to build intuition for how ML models are trained and, more importantly, the common ways they can fail.
I hope this is a useful mental model, whether you're an expert trying to explain your work or a newcomer to the field.
I'm here to answer any questions.
I'm also curious: what are your favorite analogies for explaining complex technical topics?
It reminds me of https://leptos.dev/ in Rust, although the implementation might be very different
We recently built a platform specifically to navigate the complex intersection of MDR (Medical Device Regulation) and the AI Act, relying on the pressure of hard deadlines. By introducing flexible timelines linked to technical standards, the EU risks signaling that compliance is a secondary concern, potentially stalling the momentum... and at this point patient safety is my biggest concern, not our platform
This introduces chaos rather than relief. Companies do not need lower standards; they need clarity.
We can compete effectively against high standards as long as the rules are clear. EU AI Act was clear. This proposal substitutes the certainty of a high bar with the confusion of a sliding scale, which may hinder the industry more than it helps :/
thanks. this sucks.
If you don't know about FDB; there's an amazing video about how they test it that really got me into learning more:
It’s not just about building their extension but actually making Postgres better for everyone. I would have loved that big corps would have taken this approach, as it opens the doors to others to add features for different use cases and making postgres more of a DBMS framework
I would adventure to use it in a small production environment if you can have user/customer based sharding of sqlites and then have a clickhouse/postgres for multiuser analytics store.
Are you looking for a job with a direct impact on healthcare?
* Problem: Clinical data is messy and makes research slow.
* Mission: To structure clinical data and give unified, standardized access to it.
* Product: Natural language processing models and a unified SQL data access interface for researchers.
* Traction: Validated idea, Validated business model, growing and scaling stage.
* Funding: +2y runout and growing. Backed by national and international VCs.
* Stack: Python, Cython, SQL, Postgres, Kubernetes among others
* Values: Scientific, methodic, transparent, hard workers with a HUGE emphasis on work-life balance.
Want to know more? Ping me at g@iomed.health or check our site for more info https://iomed.health/en
[1]: https://patents.google.com/patent/US20090142275A1/en?q=Infec...
[1]: https://github.com/DataDog/glommio [2]: https://news.ycombinator.com/item?id=24976533
Are you looking for a job with a direct impact on healthcare?
* What we are looking for: An experienced database developer willing to keep pushing forward the boundaries of Postgres.
### About the company
* Problem: Clinical data is messy and makes research slow.
* Mission: To structure clinical data and give unified, standardised access to it.
* Product: Natural language processing models and a unified SQL data access interface for researchers.
* Traction: Validated idea, Validated business model, growing and scaling stage.
* Funding: +3y runout and growing. Backed by national and international VCs.
* Values: Methodic, transparent, hard workers with a HUGE emphasis on work-life balance. Join a multidisciplinary team working hard to make clinical research faster, accessible and ubiquitous.
Also it's a nice excuse to enjoy Barcelona's vibe and nice weather!
Want to know more? Ping her at julia@iomed.health, she's awesome. Check our site for more info https://iomed.health/careers/database-developer/
edit: formatting
Are you looking for a job with a direct impact on healthcare?
* Problem: Clinical data is messy and makes research slow.
* Mission: To structure clinical data and give unified, standardized access to it.
* Product: Natural language processing models and a unified SQL data access interface for researchers.
* Traction: Validated idea, Validated business model, growing and scaling stage.
* Funding: +3y runout and growing. Backed by national and international VCs.
* Stack: React, redux, saga, typescript, REST and GraphQL APIs, Postgres ,Docker, Kubernetes
* Values: Methodic, transparent, hard workers with a HUGE emphasis on work-life balance. Join a multidisciplinary team working hard to make clinical research faster, accessible and ubiquitous. Also it's a nice excuse to enjoy Barcelona's vibe and nice weather!
Want to know more? Ping me at julia@iomed.health Check our site for more info https://iomed.health/en/careers/
It would be interesting to keep an eye on the number of downloads from containers and packaging systems to see if this is the case.
It's a family business, and the software works really well (a medical niche), so the investment to update the stack doesn't make any sense. (And there's no need to bother clinicians neither with things that don't add value) I have a VM for tweaking and working with it. I have multiple ETL scripts that extract the data to a modern ERP.
I don't have access to the source code, but I have tried to reverse engineer it from multiple angles. Essentially it's a 16 Bits client written on Delphi with a database (dBase) that doesn't support multiple readers or writers, shared via a network drive. Clients read files from the shared drive and create locks to avoid multiple clients working in the same data. That's the main source of pain, but the clinicians adapt to it in a week or so.
I haven't seen yet a modern system as complete as this one. There are multiple clinical centers in the area using the same software (25ish) and the 2-3 that moved into newer systems regretted greatly.
The market is too small for any new developments. But the guy who built it in the 90's maintains it and earns enough to live happily.