What is Hackers' Pub?

Hackers' Pub is a place for software engineers to share their knowledge and experience with each other. It's also an ActivityPub-enabled social network, so you can follow your favorite hackers in the fediverse and get their latest posts in your feed.

We’re proud to share that Deb Goodkin, Executive Director of the FreeBSD Foundation, will be speaking at Open-Source Summit North America, hosted by the Linux Foundation.

📍 Tuesday, May 19, 2026, | 11:00am – 11:40am CDT | Room 101H

If you’re attending Open-Source Summit North America, we encourage you to join the session and connect with us.

Deb's talk: osselcna2026.sched.com/event/2

We look forward to seeing you there.

0
0
0
7
0
0
0
0

Formalizing the classical isoperimetric inequality in the two-dimensional case. ~ Miraj Samarakkody. arxiv.org/abs/2603.14663v1

arXiv logo

Formalizing the Classical Isoperimetric Inequality in the Two-Dimensional Case

We present a formal verification of the classical isoperimetric inequality in the plane using the Lean 4 proof assistant and its mathematical library Mathlib. We follow Adolf Hurwitz's analytic approach to establish the inequality $L^2 \ge 4πA$, which states that among all simple closed curves of a given perimeter $L$, the circle uniquely maximizes the enclosed area $A$. The formalization proceeds in two phases. In the first phase, we establish the Fourier-analytic foundations required by Hurwitz's approach: we formalize orthogonality relations for trigonometric functions over $[-π,π]$, Parseval's theorem for classical Fourier series, uniform convergence of Fourier partial sums via the Weierstrass M-test, term-by-term differentiability, and Wirtinger's inequality. In the second phase, we carry out Hurwitz's proof itself: working with simple closed $C^1$ curves given in arc-length parametrization, we reparametrize over $[0,2π]$, establish the shoelace area formula, apply integration by parts, invoke the AM--GM inequality, apply Wirtinger's inequality, and use the arc-length constraint to derive the bound $A \le L^2/(4π)$. We discuss the key formalization challenges encountered, including the interchange of infinite sums and integrals, term-by-term differentiation, and the coordination of different indexing conventions within Mathlib. The complete formalization is available at https://github.com/mirajcs/IsoperimetricInequality

arxiv.org · arXiv.org

0

A few of the things I've learned in the run up to taping out our first chip that working with FPGAs had not prepared me for (fortunately, the folks driving the tape out had done this before and were not surprised):

  • There's a lot of analogue stuff on a chip. Voltage regulators, PLLs, and so on all need to be custom designed for each process. They are expensive to license because they're difficult to design and there are only a handful of companies buying them. The really big companies will design their own in house, but everyone else needs to buy them. The problem is that 'everyone else' is not actually many people.
  • Design verification (DV) is a massive part of the total cost. This needs people who think about the corner cases in designs. The industry rule of thumb is that you need 2-3 DV engineers per RTL engineer to make sure that the thing that you tape out is probably correct. In an FPGA, you can just fix a bug and roll a new bitfile, but with custom chip you have a long turnaround to fix a bug and a lot of costs. This applies at the block level and at the system level. Things like ISA test suites are a tiny part of this because they're not adversarial. To verify a core, you need to understand the microarchitecture-specific corner cases where things might go wrong and then make sure testing covers them. We aren't using CVA6, but I was talking to someone working on it recently and they had a fun case that DV had missed: If a jump target spanned a page boundary, and one of those pages was not mapped, rather than raising a page fault the core would just fill in 16 random bits and execute a random instruction. ISA tests typically won't cover this, a good DV team would know that anything spanning pages in all possible configurations of permission and presence (and at all points in speculative execution) is essential for functional coverage.
  • Most of the tools for the backend are proprietary (and expensive, and with per-seat, per-year licenses). This includes tools for formal verification. There are open-source tools for the formal verification, the proprietary ones are mostly better in their error reporting (if the checks pass, they're fine. If they don't, debugging them is much harder).
  • A lot of the vendors with bits of IP that you need are really paranoid about it leaking. If you're lucky, you'll end up with things that you can access only from a tightly locked-down chamber system. If not, you'll get a simulator and a basic floorplan and the integration happens later.
  • The back-end layout takes a long time. For FPGAs, you write RTL and you're done. The thing you send to the fab is basically a 3D drawing of what to etch on the chip. The flow from the RTL to the 3D picture is complex and time consuming.
  • On newer processes, you end up with a load of places where you need to make tradeoffs. SRAM isn't just SRAM, there are a bunch of different options with different performance, different leakage current, and so on. These aren't small differences. On 22fdx, the ultra-low-leakage SRAM has 10% of the idle power of the normal one, but is bigger and slower. And this is entirely process dependent and will change if you move to a new one.
  • A load of things (especially various kinds of non-volatile memory) use additional layers. For small volumes, you put your chip on a wafer with other people's chips. This is nice, but it means that not every kind of layer happens on every run, which restricts your availability.
  • I already knew this from previous projects, but it's worth repeating: The core is the easy bit. There are loads of other places where you can gain or lose 10% performance depending on design decisions (and these add up really quickly), or where you can accidentally undermine security. The jump from 'we have RTL for a core' to 'we have a working SoC taped out' is smaller than going to that point from a standing start, but it's not much smaller. But don't think 'yay, we have open-source RTL for a RISC-V core!' means 'we can make RISC-V chips easily!'.
  • I really, really, really disapprove of physics. It's just not a good building block for stuff. Digital logic is so much nicer.
0
6
0
0
27
0
0
0
0
0
0
0
0
30
0
0
0
1
0
1
0
1
0
0
0
0

조성진이나 손열음을 대회에서 만나고 좌절했다는 이야기를 농담처럼 하고 웃는 것은 그것대로 재밌긴 하다. 하지만 한 걸음 뒤로 물러서서 보면... 어린, 혹은 이제 막 예술을 배우기 시작한 학생을 '능력주의'에 푹 담구어 버리는 것 같은 작금의 예술계의 행태가 예술 그 자체를 얼마나 빈곤하게 만드는지 생각해보아야 한다. 어느 한 시점에서 작다면 작고 크다면 큰 어떤 기술적 차이가 이제 막 길에 들어선 학생에게 그 길을 포기할만한 좌절을 안겨준다면 예술가를 키우는 방식 자체가 잘못된 것이고 그것은 더이상 예술이 아니다.

1
0

Improve your online privacy posture with the @privacyguides Privacy Activist Toolbox: privacyguides.org/en/activism/

The battle for online privacy continues to be an uphill one in 2026, with Big Tech relentlessly trying to sink its claws ever deeper into our economic, social, and political lives in new and creative ways, in order to both enrich themselves and provide data to law enforcement. But it didn't have to be this way, and there are still steps you can take to work toward a better tomorrow.

0
0
0
1
2
0
0
0
0
2
0
0
0
0
0
0
0
0
0
0
0

while I have a level of sympathy for the california/colorado style of age-verification law, and I think many reactions against it are overheated, at the end of the day we still have to oppose stuff like this because society's ideas of what ought to be age-gated are just wrong on the merits. the goal is to ban access to perfectly normal healthy things like queer communities and still allow kids access to fucked-up dangerous adults-only stuff like catholicism and the president of the united states

0

Hi . We need to talk about something.

While talking to a colleague about how I recently learned most people have never meowed it came up that she has never waffed. Like, not even once during childhood.

Another colleague admitted they also have never waffed.

My hypothesis is that most people have at one point in their life waffed.

:neofox_floof:​ ​:neofox_boop:​​:neofox_pat_floof:

Have you ever waffed?

Please boost for scientific accuracy.

0
0
0
1
0