Hacker Newsnew | past | comments | ask | show | jobs | submit | Chu4eeno's commentslogin

No, they are correct, residential proxies behind a big ISP's CGNAT is much more valuable for miscreants because you can't block the individual who installed a free android flashlight with a residential proxy SDK embedded.

But the overall latency will be longer than expected because you add the latency from the proxy connection as well. If you're able to ping back to the connecting IP in combination with some clientside js to help measure total latency I think you should be able to reliably detect proxy users in general?

> NixOS has a longstanding issue where library loading (and therefore program start, particularly GUI programs that load a lot) is n^2, but programs still all start in ~1 second or less on my n100 minipc. I still found that to be annoying enough to look into why it seemed so slow (and learned about the loading issue). Can't imagine things taking so long that you actually switch to another task. The same minipc can easily handle my 4k 240hz HDR monitor as well, and the whole experience is completely smooth.

KDE actually solved that long time ago with kdeinit (https://web.archive.org/web/20010517071320/www.suse.de/~bast... and follow-up work by Lubos, see e. g. https://conference2005.kde.org/slides/kde-performance/index....), but the new crop of developers didn't notice much difference on their high-end systems with SSDs, so they ripped it out.


It sounds like Wayland.

When you decide to suddenly stuff some of the most complex pieces of software together (the X server and the compositor which sometimes also double as a desktop shell) into giant codebase/process with seemingly no proper plan or roadmap and make up the specification along the way (or just don't, wayland still has no proper XACE replacement, so kiosk tooling etc. is ad-hoc), you get Wayland in its current form.

Rant over; if you want to actually find out what is making stuff stall, maybe try bpftrace, DTrace or SystemTap (depending on what your distro ships and what tooling is more familiar/suited to you)? Or just run `perf top` and see if anything stands out.

For the boot run `sudo systemd-analyze critical-chain` and see what it is waiting on. And be ready for the nightmare that is the systemd "design": https://blog.darknedgy.net/technology/2020/05/02/0/


Fedora 44 removes X11 :)

Arch actually has testing repos (and has had for as long as I can remember), plus other project-specific testing repos like kde-unstable when upstream is taking a very long time to push out a new actually stable release. It also has lts packages for projects that offer those (like the kernel), and sometimes stays on old versions and backports fixes if the upstream definition of stable is too out of whack.

People seem to believe arch is much more yolo than it actually is (though forks of arch have tended to be pretty yolo, and I assume cachyos is a bit yolo as well based on the issues people have).


It has to be a pain, everything depends on them (or rather, should, you still have holdouts like go fucking up things like NSS, holding back posix_spawn etc.).

In their defense the people working on glibc and gcc are pretty intelligent and spend a lot of time thinking about how everything they do affects their users, though they make mistakes like all humans (and LLMs I should say by now).


Last I tried that (because everyone claimed it was magically better at everything) sound just randomly broke (I had no idea why, debugging pipewire is a nightmare), and since I switched back to pulseaudio everything just works again (and seems to use less CPU, but that could be selective memory).

Maybe I'm just old and grumpy, but we spent decades hammering out all the incorrect (for pulseaudio) assumptions in every layer of the stack and papered over impedance mismatches, and then people decide to rewrite from scratch again (though I'll admit I was a vocal pro-dmix anti-pulseaudio hater for a long time).


I have the opposite experience, in particular with bluetooth audio. YMMV

Norway seems like an obvious counter example? If the unions and state grow enough power before resources start to get extracted it seems like they can keep the curse in check.

It has also been protecting politics from capital in various ways; public funding of political parties, strict bans on various forms of political adverts, forced disclosure laws, essentially forcing capital into a single visible chair (NHO), etc.


Norway is more complicated, but yes, they did put their resource wealth into a nice untouchable-by-the-power-of-democracy sovereign wealth fund.

As I understand it, that fund's returns are about 17%-ish of government spending. This is not sufficient for the powerful to no longer need to care about labour.

I think Saudi Arabia is 77%-ish of government income from oil?

Table 1: https://www.elibrary.imf.org/view/journals/001/2008/170/arti...

(I'm saying government spending here rather than GDP because the point is "the powerful" not "the country").

A useful question for this is "on average, how long will a nation remain like Norway, and not elect someone that undermines democracy?"; this is… also complicated. UK elected Thatcher for various reasons, but it would be fair to say these included "removing power from the Trade Unions", yet the UK now has a politically untouchable "triple lock" on pensions that it can't really afford. It's a democracy, "the powerful" are the voters, pensioners vote more than the rest. A nation whose UBI is done by setting the state pension age to birth and keeps the voting age low may manage this… or some upcoming politician may figure out how to use Grok to win an election like social media became influential last decade (they're clearly already trying), and then we have to deal with the mess that this produces.


OWS showed that you don't even need drones and robots.

Try looking at the SVG code for one of those converted from bitmaps, and I think you'll understand why even a massive LLM has trouble generating it on the fly (the pelican SVGs are always one-shot single API calls, so no iterations and verifications).

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: