MurphyA/hacker-news huggingface dataset:
Show HN: HashCodeTools – 17 Free Privacy-Focused Dev Tools
by rsunnythota | 2025-11-16 09:57:30+00:00
Hi HN! I built HashCodeTools, a collection of 17 free, fast, privacy-focused developer utilities that run entirely in the browser — no data ever leaves your device.

As a backend engineer, I constantly found myself Googling things like “json formatter”, “jwt decoder”, “uuid generator”, “base64 encode”, etc. I realized I was using 6–7 different sites, many of which were slow, ad-heavy, or sent data to servers. So I decided to build one clean, unified toolbox.

What it currently includes

JSON Formatter / Validator

JWT Decoder

Base64 Encoder / Decoder

UUID Generator

URL Encoder / Decoder

Epoch ↔ Date Converter

HTML / CSS / JS Formatters

YAML ⇄ JSON Converter

CSV ⇄ JSON Converter

QR Code Generator

Text diff viewer …and more.

Privacy Features

100% client-side

No tracking

No logins

No ads

No backend — everything runs in your browser

This means you can safely paste production JSON, JWTs, or logs without worrying about them being uploaded anywhere.

Why I built this

I wanted:

One tab for all dev utilities

Zero network requests

Instant formatting/decoding

Tools that don't break with large payloads

A simple interface without popups or ads

Tech Stack

TypeScript

Next.js

Monaco Editor

TailwindCSS

Local-only processing (no API calls)

Roadmap

VSCode extension

Chrome extension

More text & data format tools

Open-source versions of each utility

Dark mode improvements

Feedback welcome!

I'm especially looking for feedback on:

Performance on large JSON/JWT payloads

Missing tools developers want

UI/UX improvements

Any privacy/security concerns

Thanks for checking it out! Link: https://hashcodetools.com/
by jmaker | 2025-11-16 10:00:04+00:00
I used to do Go in production for several years, along with Java and TypeScript event-loop backends. It was a breeze of fresh air, especially for new projects, where the Java conventions could be put to rest. But in such an environment, with mostly Java legacy, people did tend to bend Go to the Java idioms rendering the PR reviews very cumbersome.

From what I’ve experienced, if you need any fine-grained control over your data or allocations, precision on the type level, expressing nontrivial algorithms, Go is just too clumsy.

The more I read about how people use Go today and what issues people still have, the more I’m happy I picked Rust for almost everything. I even find it much more productive to write scripts in Rust than in Python or shell script. You just get it right very quickly and you don’t need to care about the idiosyncrasies of ancient tech debt that would otherwise creep into your new projects. And of course the outcome is way more maintainable.

Not saying that Rust hadn’t had its own warts, but most of them are made explicit. This is perhaps what I appreciate the most.

Intuitively, however, I still notice myself creating a new Python or shell script file when I need something quick, but then something doesn’t really work well the moment the logic gets a bit more complex, and I need to backtrack and refactor. With Rust, this hasn’t been an issue in my experience.

And intuitively, I still tend to think in Java terms when designing. It’s funny how it sticks for so long. And when writing some Java, I miss Go’s use-site interfaces and TypeScript’s structural typing, while I miss nominal typing in TypeScript. It’s just maybe that you get used to workarounds and idiosyncrasies in some system and then carry them over to another paradigms.

I do like Go’s value propositions, and lots of its warts have been sorted out, but I’m just not as productive in it for my use cases as I am with Rust. It just checks way more boxes with me.
by roman_soldier | 2025-11-16 10:00:16+00:00
This, most people that try and use these legacy editors spend most of their time configuring it get it to be as good as vs code and usually fail. A lot of wasted time and frustration when one click gives you a perfectly modern fast editor with a smorgasbord of great extensions that just work. I do use vim for quick editing of files in the terminal but never for serious work.
by rdm_blackhole | 2025-11-16 10:01:28+00:00
I think Tim Cook deserves some praises from everything that's happened on the hardware side of things, even regarding the Vision pro.

On the other hand I feel like the software side has been completely forgotten.

Numerous bugs, weird crashes, and the infamous Liquid Glass update are really worrying signs. The fact that Siri is completely useless after 10+ years and can barely be trusted to set a timer correctly is completely unacceptable.

I wish they would take a beat on the software and stop releasing new major OS updates every year but take their time to get things right even if that means that some years go without major updates.

This is the first time since I bought my first MacBook Pro and Iphone that I am planning on holding off on installing the updates and I am even considering skipping MacOS Tahoe entirely.

I just want things to be stable. A phone that works without major bugs, a MacBook that works without having to fiddle the dials or worry about some hidden incompatibilities.

That is what Apple used to stand for. Nowadays not so much.
by AnthonyMouse | 2025-11-16 10:01:29+00:00
> If inflation worked the way you implied, the price of it would have constantly gone up, and never would it have managed to be affordable.

In 1924 a Ford Model T cost $260. Adjusted for inflation to 2025 this is <$5000. The average new car price in 2025 is ~$50,000.
by charcircuit | 2025-11-16 10:03:56+00:00
>But eclipse is gone (I think?) and emacs is still GOATed.

The 2024 stack overflow developer survey [0] puts Eclipse at over double Emac's market share. If Eclipse is gone, then Emacs is double gone. Emacs struggles to attract and retain new users. This advice is not calling existing Emacs users deprived. It's rooted from the bad defaults giving new users a bad impression of Emac's viability because the default is so bad. If emacs built out proper telemtry they could actually track how the defaults they provide affect the new user experience in order for them to optimize it and figure out what users are looking for.

[0] https://survey.stackoverflow.co/2024/technology
by guhidalg | 2025-11-16 10:06:15+00:00
“Work best” is giving Apple the benefit of the doubt here. The point of standards like Bluetooth is to avoid vendor lock-in and promote interoperability. If Apple chooses to leverage the spec to produce a product that has degraded functionality when used with other vendors, that goes against the spirit of the spec and makes it worthless.

You might argue, well why did Apple choose to use Bluetooth at all if they’re not going to participate in the interoperability motive? Because initially (think early iPhones) Apple did not design wireless communication modules and benefits from buying COTS from existing vendors.

So would it be easier to just participate in vendor lock-in? Let me ask you, do you enjoy being able to fill up a car at any gas station, or charge your car at any 120V outlet? Standards usually benefit everyone.
by simonh | 2025-11-16 10:06:32+00:00
They’re not crazy goals, but the way these tariffs are being implemented does not further most of them.

3 and 5 are undermined by the fact that even nations with positive trade surpluses with the US, and countries like Japan with Trump first term negotiated trade treaties (which for Japan included major concessions already) are being hit with these tariffs.

1 and 4 are a problem because many of the inputs into building out US manufacturing capacity come from abroad and are hit by tariffs. Secondly many of the manufacturing inputs into making products in these factories would come from abroad and be tariffed, unless those supplies are bootstrapped domestically first but there is no policy to ensure this. Thirdly as soon as the tariffs go away, these factories would become uneconomical, so they are a gamble on that not happening in the lifetime of the factories.

Finally, who’s going to build and operate this huge new manufacturing sector? Infrastructure construction relies heavily on immigrant labour that’s being driven out, so does actual manufacturing, and there are no hordes of unemployed Americans lining up for manufacturing jobs. It’s addressing a problem that largely doesn’t exist, to build out less efficient more expensive ways to make stuff, in a way that can’t work anyway.

Manufacturing investment surged in the last few years with the introduction of the CHIPS and Inflation Reduction acts. It’s going to be hard to disentangle the continuing effects of that from the effects of the Tariffs, but it’s hard to see how the Tariffs can have a positive effect.
by quails8mydog | 2025-11-16 10:08:06+00:00
Maybe splitting them is helpful, but why would you have to do them sequentially? Many of the things that reduce income inequality also help reduce poverty. Poverty isn't "low-hanging fruit" and it's something people have been trying to eradicate longer than we've been alive.

Saying "let's not even think about B until we've 100% sorted A" is just a way to ensure B never gets done.
by paulfresquet | 2025-11-16 10:08:37+00:00
Thanks! About benchmarks: I don't have formal speed comparisons yet. ByteSync started by using a C# port/rewrite of the classical rsync algorithm, so the delta algorithm and hashing logic are very similar in spirit. The main difference is the surrounding architecture.

Where rsync works as a point-to-point stream tool, ByteSync adds:

- a two-stage inventory (size+timestamp scan + signature computation when needed)

- E2EE on every remote transfer

- orchestration and compression on the fly

- hybrid routing (LAN direct or encrypted relay when remote)

- session-based modeling with DataNodes/DataSources

This means that in remote scenarios, ByteSync avoids many of the round-trips that kill performance when latency is high. It also computes signatures only when needed, not systematically.

So I can’t claim ByteSync is “faster than rsync” — rsync is extremely optimized in its domain — but in hybrid or high-latency setups, ByteSync often behaves better because it avoids unnecessary passes and works with a more structured model of the data.

Benchmarks are something I'd like to add. Perhaps once automation and CLI are ready, because it'll make comparisons much easier to run and publish.
Show HN: TunnelBuddy – Share your internet via HTTPS proxy over WebRTC
by xrmagnum | 2025-11-16 10:09:02+00:00
Hi HN,

I'm Oli, a solo dev. I’ve been working on TunnelBuddy, a small desktop app that lets you expose your home internet as an HTTPS proxy to a trusted buddy over a WebRTC peer-to-peer tunnel.

Typical use cases:

You’re travelling but want banks/admin portals to see your actual home IP.

A friend in another country needs to reach something that only works from your region.

You want to reproduce “this only breaks on my home ISP” bugs without setting up a full VPN mesh.

Business / model

Right now:

The app is free.

There’s a tip/donation flow to help cover signalling + infra.

No ads, no “free in exchange for data”, no tracker SDKs.

I might add a “pro/advanced” tier later (longer sessions, more host controls, linux build and daemon), but I want the basic “buddy-to-buddy proxy” use case to stay straightforward.

Happy to answer technical questions, thanks guys!
by junto | 2025-11-16 10:09:02+00:00
Depending on how locked down your Entra / AD is, you can login to Graph Explorer:

https://developer.microsoft.com/en-us/graph/graph-explorer

Then you can execute the:

GET https://graph.microsoft.com/v1.0/me/memberOf

This will return you all the Entra Groups you are in, this includes the Microsoft Teams groups as well.
by mvdwoord | 2025-11-16 10:12:26+00:00
Sad but true. Many such cases as well not only limited to this field. There is a huge scandal in the Netherlands where it has been shown that Tax officials have repeatedly, and knowingly, did unlawful things which literally drove some people to suicide, and did irreparable damage to lots of people / families. They also repeatedly lied to parliament about this.

We have the proof. We do fuck all about it. And yeah, the Dutroux case (as well as e.g. Rotherham c.s.) hit hard. Too hard for most regular people to even properly come to terms with it.
by pjmlp | 2025-11-16 10:13:01+00:00
There isn't anyone pointing a gun to someone's head forcing them to using 100% of all C++ features in every single project.

There is an endless list of edemic C pitfalls that WG14 has proven not to care to fix.

Auto industy has come up with MISRA, initially for C, exactly because of those issues.

Ideally both languages would be replaced by something better, until it doesn't happen, I stand by my point, the only reason to use C instead of C++, it not having a C++ compiler available, or being prevented to use one, like in most UNIX kernels.

I hold this point of view since 1993, having used C instead of C++ was only when obliged to deliver my work in C, due to delivery requirements where my opinion wasn't worth anything to the decision makers.

So if I was already using C++ within the constraints of a 386 SX, running at 20 Mhz limited to 640 KB ( up to 1 MB) RAM size, under MS-DOS, I certainly will not change it for the 2025 computing world reality.
by rwmj | 2025-11-16 10:18:11+00:00
I'd start by writing a simple Disk Operating System, and forget MS-DOS compatibility (which isn't exactly necessary today).

The basic idea (which I think originated from FLEX[1]?) is that you have something that accepts typed commands, like "DIR A:", splits on spaces, takes the first part and loads the disk program called "DIR" (or "DIR.COM" etc) into memory and runs it, passing the rest of the parameters on the stack.

From that you can see you'll need a very basic filesystem (to load the command from), and a few system calls (eg. print a character, input a character, open a file, list the directory). The earlier DOSes like CP/M didn't have subdirectories, and only had a handful of system calls, so it was all very simple - by necessity because the hardware was limited.

You can expand on the idea endlessly, eg. writing lots of utilities, your own compiler and assembler, editor, etc.

Presto, you've got your own Disk Operating System!

There's a guy on YouTube you runs all these early proto-DOSes[2] on original hardware so you can get a sense of the extreme limitations of these early home computers.

[1] https://en.wikipedia.org/wiki/FLEX_(operating_system)

[2] https://www.youtube.com/user/deramp5113/videos
by pjmlp | 2025-11-16 10:21:15+00:00
Nope, and this is really the last comment.

First of all the quote there is indirectly about C with UNIX's adoption starting out of Bell Labs, C++ would only become known to the world in 1989, with the release of CFront 2.0.

Second, while you certainly can code C in C++, just like one can code JavaScript in TypeScript, the tools are there on the type system for anyone that cares, tools that WG 14 has proven not to care in 50 years of history.

Third, all C compilers worth using in professional scenarios are nowadays written in C++.

As last point, while C++ has the heads up over C in type system improvements, it is by no means the final answer in systems programming, ideally both programming languages should be replaced by better, safer ones, which there are a few already to chose from.

Unfortunely as long as LLVM and GCC are around, industry standards based on C and C++, there is little hope that those improved languages fully take over.

Thus when it comes to C vs C++, in such world where else gets to replace them in all scenarios, C++ is the only answer to that duality of choice, unless one wants to keep re-inventing solutions (badly) for answers C++ is providing since 1989.
by ksec | 2025-11-16 10:21:56+00:00
>Instead I see most of the bad faith criticisms of Rust coming from aficionados of other languages....

>They whine because they think Zig or Nim should take the place of Rust.

How about because Rust Evangelism Strikeforce go after other language first? Every time a language in the same space comes they get asked if they are memory safe?

Things have died down now, doesn't mean it didn't happen.
by 9rx | 2025-11-16 10:22:22+00:00
If you don't care, why take time out of your day to formulate a message?

But, regardless, it is quite delusional to think that I would write for anyone but myself. Nobody is paying me to be here. It can only ever be for myself. As I care, that is more than satisfactory. It makes absolutely no difference what other people have to say about it. It was never for them.
by veqq | 2025-11-16 10:22:52+00:00
> First, overall, the US has increased manufacturing output over the last couple decades. 2019 was the highest year ever, covid interupted a bit, but levels are back there again.

No, supposed quality adjustments hide lower production volumes: https://www.palladiummag.com/2025/10/03/how-gdp-hides-indust...

> Motor vehicles, bodies and trailers, and parts: actual light vehicles produced down 11%, real gross output of vehicles up 39%, real value-added up 125%. Inputs as a percent of gross output rose from 74% to 77%.

> Steel mills & manufacturing from purchased steel: in raw tonnage, steel shipped is down 18%, real gross output is up 5%, real value-added is up 125%. Inputs as a percentage of gross output rose from 73% to 74%.

> If the quality adjustment is 32%, the value-added increase becomes 652%!

> Another “quirk” of real value-added is that inflation adjustments and quality adjustments get applied retroactively, which creates wild inflections from small changes. In simplified terms, let’s say that, in 1997, car sales were $100 billion, and were still $100 billion twenty years later in 2017, with no changes due to inflation or input costs. Input costs in both years were $75 billion, meaning $25 billion in value-added in both years. The only thing that changed, let’s say, was that the “quality” of cars got 10% higher thanks to software innovations like Apple CarPlay and design improvements like crumple zones for safety—neither of which add to recurring production input costs. So, let’s say, our economists would adjust the 2017 figure to be $110 billion in “real” terms and show a small 10% increase, right?

>

> Instead, the way it works is that a recent “base year” is taken, in this case 2017, and the base year is never adjusted. So rather than adjusting from $100 billion to $110 billion, the “real” output of 1997 is retroactively adjusted to be lower, in this case $91 billion, to get the same 10% increase. But then, our value-added in 1997 has fallen to $16 billion, and the increase in “real value-added manufacturing” has jumped from 10% to around 50%! We have created a 50% increase in car manufacturing not by actually producing 50% more cars or “objectively” making cars 50% better, but just by playing around with statistics and definitions.
by klelatti | 2025-11-16 10:23:27+00:00
Cook’s greatest achievement - Apple’s supply chain - has, as set out in the ‘Apple in China’ book [1], turned into Apple’s biggest risk and weakness. The next CEO won’t be worrying about Siri or Vision Pro; they’ll be trying to deal with Apple’s reliance on China.

[1] https://open.substack.com/pub/thechipletter/p/apple-in-china
by dSebastien | 2025-11-16 10:23:51+00:00
I never claimed this was fully original work. My project indeed started as a fork of Handy. I've discussed this here: https://github.com/DeveloPassion/knowii-voice-ai-docs/issues... and https://www.knowii.net/c/announcements/knowii-voice-ai. I also mentioned it in the user documentation (FAQ page) and About page within the app.

I am trying to approach this will full transparency, honesty and respect for what the creator of Handy did. I'm not a grifter.

Please consider that my project is still very young. I didn't include the third-party licenses in my first few releases (I honestly didn't know this about the MIT license, my bad!), but will fix this asap with the next release (hopefully coming out in a few days), and I'll pull the previous releases to avoid distributing versions that don't include the licenses. I'll also add information about the other production dependencies that I'm using.

If you look at my announcement, you'll see that I'm being fully transparent about this and am not interested in cloning Handy at all. My code is already very distant from the initial version I started with and I'm exploring and building features that will probably never be included in Handy. For instance, my app's UI has been created from scratch (with a lot of inspiration from Handy), it is fully responsive and now works on Omarchy (Hyprland/Wayland), which Handy doesn't support at the moment. I have added various features for my own needs and for my first customers (e.g., . In the roadmap of the product, you can see some of the ideas I intend to develop.

I also intend to contribute back to Handy over time. I already have and will continue to do so.
by apeters | 2025-11-16 10:24:02+00:00
A few years ago I used to help my father replace wheels in his car shop.

The lift was rather small and you couldn't get out of the car easily when you placed the car in the correct position for the lift's arms. We placed the car about a meter from the correct position, got out, pushed it forward and placed the arms.

For this to work you need to make sure the parking brakes are not engaged.
by nneonneo | 2025-11-16 10:24:45+00:00
What a fun problem to think about.

My first instinct, knowing less about this domain than maybe I should, would be to abuse the return address predictor. I believe CPUs will generally predict the target of a “ret” instruction using an internal stack of return addresses; some ARM flavours even make this explicit (https://developer.arm.com/documentation/den0042/0100/Unified...).

The way to abuse this would be to put send() on the normal return path and call abandon() by rewriting the return address. In code:

void resolve(Transaction *t) { predict(t); send(t); } void predict(Transaction *t) { if (!should_send(t)) *(void **)__builtin_return_address(0) = &abandon; }

This isn’t exactly correct because it ignores control flow integrity (which you’d have to bypass), doesn’t work like this on every architecture, and abandon() would need to be written partly in assembly to deal with the fact that the stack is in a weird state post-return, but hopefully it conveys the idea anyway.

The if in predict() is implementable as a branchless conditional move. The return address predictor should guess that predict() will return to send(), but in most cases you’ll smash the return address to point at abandon() instead.
by Aeolun | 2025-11-16 10:26:04+00:00
You don’t get to work if your car or truck breaks. Now knowing that, what are your best options if it does?

You can spend time finding solutions, or spend time worrying, or writing blog posts saying that people don’t know what it’s like to be poor. I do plenty of spiraling myself, but I try to recognize that it’s not very productive.

Worrying or complaining about the fact that you won’t have any food tomorrow is not going to fill your belly.
by yvdriess | 2025-11-16 10:26:27+00:00
It is fairly common for emacs users to bind Ctrl or Meta to caps lock for improved ergonomics. There's also a bunch of RSI sufferers that are using foot pedals, which actually makes a lot of sense.

I personally switched to emacs for more than just Lisp when I started developing early signs for RSI. Switching to a purely KB driven interface has saved my wrists.