News for hackers. Stuff that matters.

agolliver

Re:Verizon is About to Break our Watches on Saturday July 04, 2026 @06:45PM (#48789779)
The money transfer app? Works perfectly fine.
Re:Boot Naked Linux on Monday June 15, 2026 @06:25PM (#48547853)
I wrote a batch script that that opened the entire Creative Suite in parallel and couldn't believe how much faster it was than just launching just Flash would have been on the old drive.
Edges are a separate table
Re:Cloudflare 1.1.1.1 Incident on July 14, 2025 on Wednesday July 16, 2025 @11:34AM (#44583438)
There are no good private DNS configurations, but if you don't trust the big caching recursive resolvers then I'd consider just running your own at home. Unbound is easy to set up and you'll probably never notice a speed difference.
Editors & style guides don't tend to give you that choice.
The New Yorker is one of the few places you'll see this regularly

https://www.newyorker.com/culture/culture-desk/the-curse-of-...

quite common in America too
Re:End of Support for Firefox Lockwise on Tuesday November 23, 2021 @06:04PM (#29324675)
I'd also say it's integration with Firefox on Android is just a broken, miserable experience. (I mostly blame FF for this, because it used to be great)

https://github.com/mozilla-mobile/fenix/issues/9773

Re:Watching Age-Restricted Videos on Friday November 19, 2021 @04:08AM (#29275238)
I just created a new Google account in the US without providing any personal details whatsoever.
About a decade ago, as an intern helping research this, I developed an app to manually tag processes as "big core only" or "little core only" etc. This was for the QuickIA[0], which had a Xeon in one socket and an Atom in the other. It was fun to kick off a gigantic compression task and watch the "expected time to completion" progress bar change dramatically when you migrated the process between sockets.

You all would probably find the "QuickIA Software Support" section interesting, they go through a few issues you run into when you have incompatible micro architectures running in a single system. It also might help illuminate where Intel's head was at during the early research phase of creating a heterogeneous processor.

[0] https://www.neotextus.net/hpca12.pdf

Re:How does apt render its fancy progress bar? on Wednesday October 13, 2021 @12:22PM (#28854175)
PowerShell does have progress bars, but rendering them is (was?) on the critical path. I once had a script that was downloading a large file and took ages to finish, you could speed it up by well over 10x disabling the progress bar.

https://github.com/PowerShell/PowerShell/issues/2138

From reading this it sounds like support should land soon in Fedora 35

https://lwn.net/Articles/869561/

Re:Facebook to target harmful coordination by real accounts on Thursday September 16, 2021 @02:36PM (#28555425)
At 2 am last night a bot impersonating a family member added every one of their friends on facebook & sent them messages. I reported it as a fake account, a ticket which was instantly closed.

Facebook sent a notification later to them that the account was not impersonating anyone, no action would be taken, and there was no way to appeal.

Interestingly, messenger did splat a bunch of pretty good warnings on top of the DM they sent me: https://i.imgur.com/gigUA7G.png

Re:Java 17 / JDK 17: General Availability on Tuesday September 14, 2021 @12:26PM (#28527133)
Looks like it's only true for pointer types which cannot be null (so they can reuse null as the None tag)

https://doc.rust-lang.org/std/option/

They need their custom CA on your box for your machine to accept the traffic by default, otherwise you'll get a big ugly untrusted cert error on every https/ssl connection, but some apps will let you ignore those (eg: curl --insecure)

I worked at a company that did this and it was a massive headache, every time I wanted to set up a new VM things would fail until I remembered I had to install their CA. I was an intern at the time, and they gave me some work that required an app that I couldn't configure to use their CA for the life of me. After a lot of failed troubleshooting I and ended up just running a SSH server on my home PC and creating a SOCKS proxy through that.

Re:Understanding Rust futures by going way too deep on Monday July 26, 2021 @04:43PM (#27965200)
I have found this comment on liburing[0] which clarifies some things for me. So is it because something like getaddrinfo is not just a simple operation, but a hodgepodge of stuff like "first try nscd, then read resolv.conf, then make a bunch of requests using one of many different protocols"?

I think I have a lot more to learn about DNS...

[0] https://github.com/axboe/liburing/issues/26#issuecomment-738...

> [re: implementing getaddrinfo] It's not planned because it's not a single operation but a complex beast reading files, exchanging messages, etc. IMHO, as it's not a single operation it fundamentally doesn't fit liburing, but implementing under some framework on-top would be more viable.

Re:Understanding Rust futures by going way too deep on Monday July 26, 2021 @04:17PM (#27964872)
There is a difference between blocking and non-blocking, which is what I am asking about. Language runtimes apparently cannot provide non-blocking DNS (as evidenced by this article, and the other one I linked which was on HN a week or so ago).

DNS seems like it perfectly fits the model of "give me a buffer (to hold the resolved IP), and I will wake you up when it's filled". Maybe io_uring (/ IOCP?) already can support this, and these articles are just mistaken about the current (or soon-to-be) state-of-the-art? Or is there some fundamental reason about DNS that make writing a non-blocking resolver very very difficult?

It's just very odd to me that userspace apps are creating their own blocking thread pools just to run DNS stuff, when they can do seemingly everything else with just a single thread if they wanted to.

(edited a few times, sorry if I caught someone who was mid-reply)

Re:Understanding Rust futures by going way too deep on Monday July 26, 2021 @03:41PM (#27964384)
Not sure a better place to ask this, but we're getting to the point in most OSs where basically anything you want can finally be done truly async (non-blocking).

Except that DNS apparently still blocks[0], so usually things farm DNS requests off to their own blocking thread pools (the author ends up disabling DNS just so they can "prove" everything works with just a single thread)

What's so fundamentally difficult about writing an async/non-blocking DNS resolver? Is it just a lack of a real need for it?

[0] (quote: People have been trying to build asynchronous DNS resolvers for decades without success. Can it be done? Yes. Has it been done? No. ) https://gist.github.com/djspiewak/46b543800958cf61af6efa8e07...