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.
958 karma · joined April 8, 2017
Doing my bit to bring high-end electronics manufacturing back to Europe.
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.
Which is a fanciful way of saying that I don't understand the relevance of your comment at all to the topic at hand, which is an interactive frontend.
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.
> one.one.one.one:443:64:ff9b::1.1.1.1
Is this a typo or a weird curl-specific address format I've never heard of?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...
I found this[1] one while looking around, the thread has some additional interesting remarks, including an LD_PRELOAD attack vector.
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.
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.
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.
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.
For me the site just went offline, it shows a 500. I'm betting it's hosted on a smal colo. They should consider cloudflare or another cdn/accelerator.
For those who are curious. I have to admit, this is never something I'd have done myself, but I struggle to justify a more complex approach.