HN user

detuur

958 karma

Full-er stack engineer.

Currently working at an electronics plant, building test automation HW/SW for carrier-grade networking equipment.

Doing my bit to bring high-end electronics manufacturing back to Europe.

Posts1
Comments187
View on HN

First thing I do at a new job is make friends with IT, if at all possible. I end up being the guy with the new high-dpi screens they're trialling, more RAM in my laptop, and "just DM me in Teams" privileges for tech support. All for not treating these people like tech janitors (and obviously there's nothing wrong with being a janitor).

Cheat code for this: ask them if they need any custom tooling. I spent a few hours at a past job on a userscript for their ticketing interface to fix some annoyances. Brownie points for life.

I can't believe you're the first person I find in this conversation who raises this issue. This is the exact reason why Marcan flipped his lid. Linus publicly championed a very technically complex initiative and then left all those contributors to the wolves when things didn't progress without a hiccup. Especially damning when you consider that at every step, the fief lords in Linux have seemingly done everything in their power to set up the r4l people for failure and Linus hasn't so much as squeaked at them. He personally cut the knot and asserted that Rust is Linux's future, but he constantly allows those below him to relitigate the issue with new contributors (who can't fight back because even though they're contributing by the supposed rules, they don't have enough social buy-in).

I have a few projects that I've abandoned because they only made sense as a FOSS project, and I saw how FOSS maintainers were being treated. I love FOSS, I love the philosophy, and I would love to "give back" one day by making the ecosystem richer, but I've not yet found a project that I love enough to be abused over.

Ah yes, famously one can only be a sysadmin if they're unable to use a different cli verb order.

Come on now. Either present a real argument or accept the fact that tooling isn't forever going to be frozen to what you used in your 20's. Newer tooling uses newer best practices and the improved verb order is part of that.

I don't see how the real mode emulation on the 80386 (VM86) fails to meet the standard of the Popek and Goldberg definition. IA-32, yes, that took a while, but VM86 allowed 8086 (real mode) tasks to run as if they were running authentically in real mode while the 386 was in protected mode, and had all the features P&G describe in their definition. It runs natively, it runs with equivalent performance, and there's a VMM trapping privileged instructions to either emulate or arbitrate system resources. It's the full deal!

I can't believe that this is the closest we have to a compact, stand-alone GPU option. There's nothing like a M.2 format GPU out there. All I want is a stand-alone M.2 GPU with modest performance, something on the level of embedded GPUs like Intel UHD Graphics, AMD Radeon, or Qualcomm's Adreno.

I have an idea for a small embedded product which needs a lot of compute and networking, but only very modest graphical capabilities. The NXP Layerscape LX2160A [1] would be perfect, but I have to pass on it because it doesn't come with an embedded GPU. I just want a small GPU!

[1] https://www.nxp.com/products/processors-and-microcontrollers...

Same. I can't be the only one who feels that Nix is doing the right thing the wrong way. The right thing being reproducible, declarative, composable environments; the wrong thing being its language and tooling. Too often I feel like serious Nix users spend a distressing amount of time manually doing package manager tasks, so the way forward is to stop doing exactly that. Going back to imperative composition is a step backward that will never help people free up time away from package management.

And to contrast, Godot's GDScript has been great for me so far. I've been hacking at a personal project for a couple of days now and I feel right at home in the language, which feels right at home in the engine.

Some years ago, I read a post on HN where someone made a text-mode game(? or something similar?) available through SSH. People could play the game by opening an SSH session and play from their terminals. This was non-trivial, and they explained all the ways they configured sshd to prevent players from running binaries other than the game.

I didn't bookmark that post, and I haven't been able to find it again to my great dismay. If anyone remembers this post and still has it, I'd love to read it again.

It's for a Pi Wars robot. A robot that has to be driven by a Pi chip. AFAIK the ESP32 is made by Espressif, not the Pi Foundation.

Additionally, I've learned that when it comes to part choices, especially microcontrollers, just because another part is "more right" it doesn't make your choice wrong.

It was/is a very well thought-out format that had a lot of industry signalling they were willing or even enthusiastic about supporting it, which happens virtually never for new image formats. All the major browsers were working on support, many image processing pipelines were being updated.

Everyone agreed that it was not just a major improvement, but actually the best option out of all the contenders out there. Even the Chrome team. The only ones who didn't agree were the AVIF team at Google, who had developed a competing standard. Well, whoever was on that team had some pull, because not long after Chrome landed JXL support in stable and everything was about to pick up some serious pace, they suddenly landed a commit that reverted everything to do with JXL support in Chrome, and that was that.

An immense, cross-industry effort undone by internal Google politics. That's what's hostile about this situation. JXL is still limping along, but Google's unilateral reversal hurt everyone's confidence in the project but also the entire process. Apparently it doesn't matter what everyone in the world thinks is the most appropriate format. What matters is Lord Google's favour.

The wild thing about this is that this isn't just a B2B fraud, but regular joes are hit with it as well and regular operators don't care.

My phone got stolen in Naples last year, just as I was about to board my plane. It was 11PM, so when I called my boss from my gf's phone he decided to block the number the next morning as he was in bed already. By the time the SIM was blocked, 10 hours had passed, and thieves had managed to place over 100 hours of very expensive toll calls to numbers in Algeria. It cost the company over 10k, and our operator was not willing to accept any responsibility over it. Admittedly, I turned off the PIN lock because my phone at the time would overheat and restart multiple times a day, but operators really should have lockouts on foreign payphone numbers, especially once they're being placed faster than a human can dial them.