Show HN: Tarit – a hypervisor which is 2x faster than firecracker
7 by mkagenius | 2 comments on Hacker News.
Hack Nux
Watch the number of websites being hacked today, one by one on a page, increasing in real time.
New ask Hacker News story: Ask HN: Is AI sycophancy a way to reduce compute rather than make users happier?
Ask HN: Is AI sycophancy a way to reduce compute rather than make users happier?
2 by amichail | 1 comments on Hacker News.
Of course you would like the AI to be more critical about your ideas but to be usefully critical requires more compute, right? Current AI feels like talking to a human expert who answers quickly without really thinking about the matter much.
2 by amichail | 1 comments on Hacker News.
Of course you would like the AI to be more critical about your ideas but to be usefully critical requires more compute, right? Current AI feels like talking to a human expert who answers quickly without really thinking about the matter much.
New ask Hacker News story: Thanks HN for 15 years of support and helping me find my life's work
Thanks HN for 15 years of support and helping me find my life's work
53 by nicholasjbs | 2 comments on Hacker News.
Tomorrow is the 15th anniversary of the first day of the Recurse Center ( https://ift.tt/eltSZfk ) My cofounders and I did YC all the way back in the Summer of 2010, with the initial idea of building "OkCupid for jobs." That idea quickly fizzled, and we spent the better part of a year pivoting between other ideas that also failed. Finally, we made something that we wanted ourselves: a self-directed programming retreat, where people built fun projects, contributed to open source, and helped each other become better programmers. After running two small batches, we launched on HN[1] and got an incredible reception. That post on HN helped us reach beyond our personal networks and meet programmers from around the world, many of whom have since become friends. HN brought us the majority of people who came to our next few batches, and in the years since, HN has remained our #2 source of applicants (after word of mouth). Alas, pg's comment[2] on HN when we launched turned out to be prescient: Running free programming retreats isn't a billion-dollar business, but it's still a worthwhile thing to do, and has positively impacted over 3,000 people so far. And 15 years on I still wake up every day excited to keep working on it. So, thanks HN, for helping make the Recurse Center possible, and for helping me find my life's work. [1] https://ift.tt/OLVYUXN [2] "This sounds like a crazy plan for a startup, I realize, but this is the right sort of crazy. In fact, the way the Hackruiters think about Hacker School is a lot like the way we initially thought about YC: if it doesn't make money, it will at least have been a benevolent thing to do."
53 by nicholasjbs | 2 comments on Hacker News.
Tomorrow is the 15th anniversary of the first day of the Recurse Center ( https://ift.tt/eltSZfk ) My cofounders and I did YC all the way back in the Summer of 2010, with the initial idea of building "OkCupid for jobs." That idea quickly fizzled, and we spent the better part of a year pivoting between other ideas that also failed. Finally, we made something that we wanted ourselves: a self-directed programming retreat, where people built fun projects, contributed to open source, and helped each other become better programmers. After running two small batches, we launched on HN[1] and got an incredible reception. That post on HN helped us reach beyond our personal networks and meet programmers from around the world, many of whom have since become friends. HN brought us the majority of people who came to our next few batches, and in the years since, HN has remained our #2 source of applicants (after word of mouth). Alas, pg's comment[2] on HN when we launched turned out to be prescient: Running free programming retreats isn't a billion-dollar business, but it's still a worthwhile thing to do, and has positively impacted over 3,000 people so far. And 15 years on I still wake up every day excited to keep working on it. So, thanks HN, for helping make the Recurse Center possible, and for helping me find my life's work. [1] https://ift.tt/OLVYUXN [2] "This sounds like a crazy plan for a startup, I realize, but this is the right sort of crazy. In fact, the way the Hackruiters think about Hacker School is a lot like the way we initially thought about YC: if it doesn't make money, it will at least have been a benevolent thing to do."
New Show Hacker News story: Show HN: BambooGrid – Open-source web UI for power grid modeling and power flow
Show HN: BambooGrid – Open-source web UI for power grid modeling and power flow
9 by soaringmonchi | 2 comments on Hacker News.
Hi HN, I am co-founder of Kickstage, a software company specializing in solutions for the electrical industry and lately grid operators. We are hiring engineers from different backgrounds, a lot of them software developers with limited experience in the sectors. Deep domain knowledge is key in our industry however, so we are constantly teaching the basics of power flow analysis, active vs reactive power, transmission line properties etc. With Jupyter notebooks and the Python console only, that's a tedious task and hardly ever led to a deep understanding of the topics. So we built BambooGrid: a web-based editor on top of pandapower, a popular simulation library in our industry. You drag elements like buses, lines, loads generators and transformers onto a canvas, wire them up, set parameters and run power flow. It will print results directly on the canvas, color buses according to their voltages, even allows you to see an interactive admittance matrix. You can try it out without installing anything on https://ift.tt/5vqF9Om (thanks to our friends at Hostzero who sponsored hosting). Start with one of the included samples or draw your own. Just don't forget to add a slack element. Built on a Python backend (driven by the choice of pandapower mainly) and a React frontend. Fully MIT licensed, so feel free to use and modify to your liking. Even better: Give us feedback - we're extremely open to suggestions how to improve the tool and are glad about every user who learns a bit more about power systems through it. Šime, who built most of this, is also in the thread. We are both happy to answer anything about the implementation or power systems in general.
9 by soaringmonchi | 2 comments on Hacker News.
Hi HN, I am co-founder of Kickstage, a software company specializing in solutions for the electrical industry and lately grid operators. We are hiring engineers from different backgrounds, a lot of them software developers with limited experience in the sectors. Deep domain knowledge is key in our industry however, so we are constantly teaching the basics of power flow analysis, active vs reactive power, transmission line properties etc. With Jupyter notebooks and the Python console only, that's a tedious task and hardly ever led to a deep understanding of the topics. So we built BambooGrid: a web-based editor on top of pandapower, a popular simulation library in our industry. You drag elements like buses, lines, loads generators and transformers onto a canvas, wire them up, set parameters and run power flow. It will print results directly on the canvas, color buses according to their voltages, even allows you to see an interactive admittance matrix. You can try it out without installing anything on https://ift.tt/5vqF9Om (thanks to our friends at Hostzero who sponsored hosting). Start with one of the included samples or draw your own. Just don't forget to add a slack element. Built on a Python backend (driven by the choice of pandapower mainly) and a React frontend. Fully MIT licensed, so feel free to use and modify to your liking. Even better: Give us feedback - we're extremely open to suggestions how to improve the tool and are glad about every user who learns a bit more about power systems through it. Šime, who built most of this, is also in the thread. We are both happy to answer anything about the implementation or power systems in general.
New ask Hacker News story: Why people chasing after useless token saving plugins and ignoring real solution
Why people chasing after useless token saving plugins and ignoring real solution
2 by yohji1984 | 0 comments on Hacker News.
I wrote a blog yesterday on how useless RTK and Ponytail are on real coding tasks. And published my agent harness long-horizon task benchmarks on 80% real token saving. I just want to know why people just ignore the fact those pulgins are useless and don't care about the real savings? full reports are on my repo: https://ift.tt/2KxZ731 Arm n Harness score Total tokens Modeled cost Rounds Duration No plugin 2 78.85% 6.660M $5.281946 62.5 895s Ponytail 2 80.77% -7.56% -8.87% -9.60% +13.51% RTK 2 76.92% +13.20% +7.18% +44.00% +40.69% Configuration Passes Pass rate Observed tokens Rounds Estimated cost Tura Balanced High 48/60 80.0% 229,695,477 2,017 $221.138 Tura Direct High 39/60 65.0% 75,108,167 969 $99.620 Codex CLI Medium 38/60 63.3% 333,538,349 3,140 $257.173 Codex CLI High 36/60 60.0% 455,742,296 6,074 $327.483
2 by yohji1984 | 0 comments on Hacker News.
I wrote a blog yesterday on how useless RTK and Ponytail are on real coding tasks. And published my agent harness long-horizon task benchmarks on 80% real token saving. I just want to know why people just ignore the fact those pulgins are useless and don't care about the real savings? full reports are on my repo: https://ift.tt/2KxZ731 Arm n Harness score Total tokens Modeled cost Rounds Duration No plugin 2 78.85% 6.660M $5.281946 62.5 895s Ponytail 2 80.77% -7.56% -8.87% -9.60% +13.51% RTK 2 76.92% +13.20% +7.18% +44.00% +40.69% Configuration Passes Pass rate Observed tokens Rounds Estimated cost Tura Balanced High 48/60 80.0% 229,695,477 2,017 $221.138 Tura Direct High 39/60 65.0% 75,108,167 969 $99.620 Codex CLI Medium 38/60 63.3% 333,538,349 3,140 $257.173 Codex CLI High 36/60 60.0% 455,742,296 6,074 $327.483
New Show Hacker News story: Show HN: SirixDB 1.0 Beta – Git-Like Versioning, Diffs, Time-Travel Queries
Show HN: SirixDB 1.0 Beta – Git-Like Versioning, Diffs, Time-Travel Queries
9 by lichtenberger | 0 comments on Hacker News.
Hi HN! I've posted SirixDB here before, back in 2019 ( https://ift.tt/vWX1UQo ) and again in 2023 ( https://ift.tt/4CufLzr ). The core idea behind SirixDB is, that history is a first-class citizen. Every commit stores a lightweight, queryable revision. You can query any point in time, even individual nodes (for instance JSON values), diff arbitrary revisions, and efficiently track how data evolved without replaying events. Unlike traditional event stores, historical states do not need to be reconstructed by replaying events nor do we have to think about projections. Revisions are directly queryable. A simple example: Jan 1: Record "Price = $100, valid from Jan 1". Stored on Jan 1 (transaction time). Jan 20: Discover price was actually $95 on Jan 1. Commit correction. After correction, you can ask across both axes: - "What did we THINK the price was on Jan 16?" -> $100 (Transaction time) - "What WAS the price on Jan 1?" -> $95 (Valid time) I've worked on this in my spare time since 2013, following its academic precursor (Idefix/Treetank) at the University of Konstanz. The architecture relies on an append-only physical log and a persistent copy-on-write page trie. A high level view of the architecture: Physical Log (append-only, sequential writes) ┌────────────────────────────────────────────────────────────────────────┐ │ [R1:Root] [R1:P1] [R1:P2] [R2:Root] [R2:P1'] [R3:Root] [R3:P2'] ... │ └────────────────────────────────────────────────────────────────────────┘ t=0 t=1 t=2 t=3 t=4 t=5 t=6 → time Each revision is indexed, and unchanged pages are shared: [Rev 1] [Rev 2] [Rev 3] │ │ │ ▼ ▼ ▼ [Root₁] [Root₂] [Root₃] │ │ │ │ │ │ │ └─────────┐ │ └────────┐ │ └─────────┐ ▼ ▼ ▼ ▼ ▼ ▼ ┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐ │ P1 │ │ P2 │ │ P1' │ │ P2' │ └──────┘ └──────┘ └──────┘ └──────┘ Rev 1 Rev 1+2 Rev 2+3 Rev 3 (shared) (shared) Beneath the root pages sit node and secondary indexes, using a novel sliding-snapshot algorithm to balance read/write performance. Everything is queryable using JSONiq via the Brackit compiler. Back in 2019, and even in 2023, SirixDB was very slow due to GC pressure. Unlike most other document stores, SirixDB stores fine-grained nodes, and I came to realize that an on-heap (JVM) representation made up of lots of small objects simply didn't make sense. I measured it with async-profiler — with some help from Andrei Pangin himself — and the result was that the poor throughput was due to the sheer amount of allocations which scaled almost linearly with the number of open transactions. Working a full-time software engineering job, I lacked the energy for a massive spare-time rewrite. About a year ago, I started experimenting with AI. It turned out to be ideal for automating the tedious, repetitive parts of migrating the storage layer to Java's Foreign Function & Memory API, storing pages completely off-heap. Looking further ahead, the append-only, immutable-page design maps naturally onto object storage like S3 and distributed logs like Kafka for a cloud version, and initial prototypes already exist. Maybe that becomes a commercial service one day, but for now, I'm just thrilled to see these core design principles finally proven out.There's an interactive demo, documentation, and the code is on GitHub. I'd love feedback and am happy to answer questions! kind regards Johannes [1] https://sirix.io | https://ift.tt/YLQuBWH [2] https://ift.tt/914Ovsq [3] https://demo.sirix.io [4] https://sirix.io/docs/ [5] http://brackit.io
9 by lichtenberger | 0 comments on Hacker News.
Hi HN! I've posted SirixDB here before, back in 2019 ( https://ift.tt/vWX1UQo ) and again in 2023 ( https://ift.tt/4CufLzr ). The core idea behind SirixDB is, that history is a first-class citizen. Every commit stores a lightweight, queryable revision. You can query any point in time, even individual nodes (for instance JSON values), diff arbitrary revisions, and efficiently track how data evolved without replaying events. Unlike traditional event stores, historical states do not need to be reconstructed by replaying events nor do we have to think about projections. Revisions are directly queryable. A simple example: Jan 1: Record "Price = $100, valid from Jan 1". Stored on Jan 1 (transaction time). Jan 20: Discover price was actually $95 on Jan 1. Commit correction. After correction, you can ask across both axes: - "What did we THINK the price was on Jan 16?" -> $100 (Transaction time) - "What WAS the price on Jan 1?" -> $95 (Valid time) I've worked on this in my spare time since 2013, following its academic precursor (Idefix/Treetank) at the University of Konstanz. The architecture relies on an append-only physical log and a persistent copy-on-write page trie. A high level view of the architecture: Physical Log (append-only, sequential writes) ┌────────────────────────────────────────────────────────────────────────┐ │ [R1:Root] [R1:P1] [R1:P2] [R2:Root] [R2:P1'] [R3:Root] [R3:P2'] ... │ └────────────────────────────────────────────────────────────────────────┘ t=0 t=1 t=2 t=3 t=4 t=5 t=6 → time Each revision is indexed, and unchanged pages are shared: [Rev 1] [Rev 2] [Rev 3] │ │ │ ▼ ▼ ▼ [Root₁] [Root₂] [Root₃] │ │ │ │ │ │ │ └─────────┐ │ └────────┐ │ └─────────┐ ▼ ▼ ▼ ▼ ▼ ▼ ┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐ │ P1 │ │ P2 │ │ P1' │ │ P2' │ └──────┘ └──────┘ └──────┘ └──────┘ Rev 1 Rev 1+2 Rev 2+3 Rev 3 (shared) (shared) Beneath the root pages sit node and secondary indexes, using a novel sliding-snapshot algorithm to balance read/write performance. Everything is queryable using JSONiq via the Brackit compiler. Back in 2019, and even in 2023, SirixDB was very slow due to GC pressure. Unlike most other document stores, SirixDB stores fine-grained nodes, and I came to realize that an on-heap (JVM) representation made up of lots of small objects simply didn't make sense. I measured it with async-profiler — with some help from Andrei Pangin himself — and the result was that the poor throughput was due to the sheer amount of allocations which scaled almost linearly with the number of open transactions. Working a full-time software engineering job, I lacked the energy for a massive spare-time rewrite. About a year ago, I started experimenting with AI. It turned out to be ideal for automating the tedious, repetitive parts of migrating the storage layer to Java's Foreign Function & Memory API, storing pages completely off-heap. Looking further ahead, the append-only, immutable-page design maps naturally onto object storage like S3 and distributed logs like Kafka for a cloud version, and initial prototypes already exist. Maybe that becomes a commercial service one day, but for now, I'm just thrilled to see these core design principles finally proven out.There's an interactive demo, documentation, and the code is on GitHub. I'd love feedback and am happy to answer questions! kind regards Johannes [1] https://sirix.io | https://ift.tt/YLQuBWH [2] https://ift.tt/914Ovsq [3] https://demo.sirix.io [4] https://sirix.io/docs/ [5] http://brackit.io