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.

0
0

EDIT 4: We rolled back to VIm 9.1.0, no more AI slop. We kept our EVi changes too!!!

EDIT 3: This is really bad, we've found AI slop from before the AI commits we knew of. Please see codeberg.org/NerdNextDoor/evi/. We're currently discussing the best way to proceed over IRC.

EDIT 2: I forgot to update this, the project is called EVi now.

hard-forked vim at release 9.1.0 (Jan 2024)

codeberg.org/NerdNextDoor/vim

maybe we can get a group of people behind this??

Fuck AI.

0
19
0
0
0
0
0
0
0

검찰이 정치적 중립을 안 지키고 행정부-법무부 소속인 검사가 사법부 전체와 대등한 필요이상의 권위를 갖게 되는걸 박살내기로 한건데 대법원하고 대공소청을 기존과 같은 방식으로 연결해? 국민을 전부 바보 멍청이로 아나.

RE: https://bsky.app/profile/did:plc:a6qvfkbrohedqy3dt6k5mdv6/post/3mgmyvdpx4c2q

0
0
0

Ever wondered how macOS blur effects really work under the hood? This fascinating reverse engineering journey challenges assumptions about 𝑁𝑆𝑉𝑖𝑠𝑢𝑎𝑙𝐸𝑓𝑓𝑒𝑐𝑡𝑉𝑖𝑒𝑤, explores alternatives, and shares great discoveries along the way.

🔗: oskargroth.com/blog/reverse-en by Oskar Groth (@oskargrothOskar)

0
0
0
0
0
0
0
0
0
0
0
0
24
0

RE: mastodon.social/@bagder/116200

💯 I gave them quite a bit of feedback while I was on the Python Software Foundation board. While a few typo-level fixes were implemented, all/most concerns were completely ignored.

This is why I struggle to take these orgs seriously.

cc @bagderdaniel:// stenberg://

0
0
0
0
0
0
0

I stumbled on an interesting white paper, "Unlocking Python's Cores: Hardware Usage and Energy Implications of Removing the GIL."

Python's energy impact isn't as high on my bingo card, but I thought it was worth sharing because it's relevant to many of you.

arxiv.org/abs/2603.04782

arXiv logo

Unlocking Python's Cores: Hardware Usage and Energy Implications of Removing the GIL

Python's Global Interpreter Lock prevents execution on more than one CPU core at the same time, even when multiple threads are used. However, starting with Python 3.13 an experimental build allows disabling the GIL. While prior work has examined speedup implications of this disabling, the effects on energy consumption and hardware utilization have received less attention. This study measures execution time, CPU utilization, memory usage, and energy consumption using four workload categories: NumPy-based, sequential kernels, threaded numerical workloads, and threaded object workloads, comparing GIL and free-threaded builds of Python 3.14.2. The results highlight a trade-off. For parallelizable workloads operating on independent data, the free-threaded build reduces execution time by up to 4 times, with a proportional reduction in energy consumption, and effective multi-core utilization, at the cost of an increase in memory usage. In contrast, sequential workloads do not benefit from removing the GIL and instead show a 13-43% increase in energy consumption. Similarly, workloads where threads frequently access and modify the same objects show reduced improvements or even degradation due to lock contention. Across all workloads, energy consumption is proportional to execution time, indicating that disabling the GIL does not significantly affect power consumption, even when CPU utilization increases. When it comes to memory, the no-GIL build shows a general increase, more visible in virtual memory than in physical memory. This increase is primarily attributed to per-object locking, additional thread-safety mechanisms in the runtime, and the adoption of a new memory allocator. These findings suggest that Python's no-GIL build is not a universal improvement. Developers should evaluate whether their workload can effectively benefit from parallel execution before adoption.

arxiv.org · arXiv.org

0
0
0

Read below 👇 why you should start using LibreSpeed from now on for internet speed tests

"Speedtest and Downdetector were just sold to Accenture for $1.2 billion. (...) Ookla, the parent company of both tools, has been acquired by the global IT consulting giant Accenture (...).

The open source alternative: LibreSpeed. No tracking scripts, no GPS harvesting, no profile building, no ads and no data sold to anyone."

librespeed.org/

reddit.com/r/xprivo/comments/1

0
27
0
0

“When you create a law, you have to think about what a future government could do with those powers."

Ministers would have unilateral powers to lock what they see as 'harmful' behind digital ID checks.

This could end up being used on LGBTQ+ and reproductive health content.

🗣️ ORG's James Baker.

politico.eu/article/uk-eyes-sw

0
12
0
0
7
0
1

Every day I’m more convinced that the Fediverse’s slow mainstream adoption isn’t really about usability.

People say it’s because it’s hard to join, the terms are confusing, or the apps aren’t polished enough. Maybe a little. But honestly… look at the platforms people already use.

Finding anything on LinkedIn is painful.
Trying to locate the original video on TikTok is a scavenger hunt.
Facebook is still full of weird bugs and odd UI choices.
Instagram hides posts behind algorithms.
Twitter/X constantly changes the rules of engagement.

None of these platforms are exactly “easy.”

People stay because their friends are there. Because the big creators are there. Because that’s where the conversation already lives.

And, if we’re honest, because these platforms are engineered around a very effective reward loop: notifications, likes, infinite scroll. A dopamine machine. You learn the confusing terms and awkward interfaces because there’s a constant reward for doing so.

So yes, making the Fediverse easier to join absolutely helps.

But what would help even more is something simpler:
more mainstream, recognizable, official accounts showing up here.

That’s how networks grow.
People follow people not platforms.

0
5
0
1
0
1
1
0
0
0

I've seen people claiming - with a straight face - that mechanical refactoring is a good use-case for LLM-based tools. Well, sed was developed in 1974 and - according to Wikipedia - first shipped in UNIX version 7 in 1979. On modern machines it can process files at speeds of several GB/s and will not randomly introduce errors while processing them. It doesn't cost billions, a subscription or internet access. It's there on your machine, fully documented. What are we even talking about?

0
10
0
0

프사 때문인가 뭔가 몽실몽실한 캐릭터가 만들어졌네요🤓 오랜만에 캐 만들어서 즐거웠어요🔥 <키워드> 솜사탕 구름, 중단발의 캐주얼룩 소녀, 파스텔톤에 몽실몽실한 구름이 주변에 떠다니고 하늘핑크 그라데이션 단발머리, 천사, 아기 고양이

RE: https://bsky.app/profile/did:plc:snre5ed2ksh7ufyvafjbffzr/post/3losorjenpk2z

0
0
0