• 0 Posts
  • 40 Comments
Joined 1 year ago
cake
Cake day: October 17th, 2025

help-circle
  • True, but “waterproof evidence” is not the bar required to change a law. Most voters are against UBI not because of the lack of evidence. I think they don’t even want to check the evidence, they are arguing against the idea.

    (Sorry for the long reply. I got sucked into this topic ~15 years ago and it all wants to come back now ;-)

    You can get quite an emotional reaction from some people to even propose this idea. Even when you propose to implement a tiny, tentative amount, they are still firmly against it.

    My guess is that it de-valuates paid work ever so slightly, in principle, which goes against the current paradigm that puts paid work into the center of everything. (Ignoring those who already have an unconditional passive income today.) My guess is also that people really like the feeling that they have earned by their own personal effort any money they own. The truth of who has earned what is, as you know, a lot more complicated.

    we have no idea how employment will change

    Actually, I think this is the most well-explored point. Every study is trying to measure this. E.g. quoting Wikipedia:

    A 2018 paper found that the Alaska Permanent Fund “dividend had no effect on employment, and increased part-time work by 1.8 percentage points (17 percent)… our results suggest that a universal and permanent cash transfer does not significantly decrease aggregate employment.”[47]

    IIRC most studies have similar findings: employment generally changes only very slightly. Usually it goes slightly down, but nothing dramatic. Given the amount of studies that exist, I think at this point you’d have to argue why those results should not transfer, why at least a comparable (low) amount of UBI should have a large effect on employment elsewhere.

    But as I said, I don’t think the political discussion around UBI is really about the evidence.

    and we have no idea what people will actually use their freedom for.

    This one is more interesting. Some studies ignore this completely. (More time spent in paid work is always better, right?) But some try to find out what why people actually stop working.

    From memory, in one study some of the newly un-employed were actually going back to finish their degree. And I remember an anecdote of one person who finally got out of an abusive job because of the money, only to find a much better one (better paid, too) a few months later. In one study I think they were even able to argue that the reduced health costs, etc. (people out of poverty are less likely to get hostpitalized or get criminal) is paying for the cost of the (low) UBI. (But IIRC it was additional money.)

    You can dismiss this all as anecdotal, or “not real UBI if it was additional money”. But as I said, I don’t think the political reasons why people are against has much to do with the evidence. I think we have enough evidence to say that at least a low UBI is extremely unlikely to hurt the economy, or at least not by more than other policies that focus only on the unemployed already do.


  • I agree we don’t know what exactly would happen if UBI was implemented globally, and what the large-scale effects would be. But saying “there is no evidence” goes too far. There have been UBI experiments, both intentional and by accident.

    We generally know how people react in different contexts to different variants of a low to moderate UBI, what the health and work outcomes are, etc. Sure, a “full” UBI would be different. But it would be silly to expect people to react in a completely different way from what we have already seen, at least for a low UBI.

    If you need a reminder about past experiments, listen to Scott Santens (youtube, 10min, from 2020). He is obviously very biased (UBI advocate) but he knows all the nuances about past UBI experiments.




  • The authenticated encryption of HTTPS similarly protects the CDN-based web clock approach. This avoids situations where an attacker-in-the-middle tampers with insecure NTP responses, messing up your system’s clock.

    Almost… there is this fun thing called a delay attack that works despite encryption! (I’ll admit that it’s probably not a practical concern.)

    Anyway, the article talks about time measurements through an absurd amount of abstraction layers. Please don’t ever call this “simple” or even “cloud-native time” or the like.

    If you start trying to improve this setup you’ll find so many face-palm moments. Like TCP retransmissions (which the article mentions, to be fair). You’d have to use WebRTC to avoid that, which I bet the CDN network doesn’t support. Or the fact that web browser timers have intentionally reduced precision to resist fingerprinting. (Granted, if you are still in the milliseconds range it is not a problem.)


  • matsdis@piefed.socialtoSelfhosted@lemmy.world•Security Scanning
    link
    fedilink
    English
    arrow-up
    4
    ·
    edit-2
    7 months ago

    After I fiddle with the firewall rules (or a system install or major upgrade) I usually only do a quick portscan with nmap from another box. (TCP and UDP; only IPv4 only because I disabled IPv6 completely.) There are online port-scan services too, but you never know if they also invite the bots.

    I agree with others here that vulnerability-scanning your own applications seems overkill. Like with external virus scanners, I always feel they are just as likely the attack vector themselves. The more complexity, the more risk.

    What I do is:

    1. Enable unattended system updates (on Debian stable) and automated reboots. And sometimes check if it actually still works.
    2. Firewall configuration with a whitelist for public ports, and as a second layer:
    3. configure internal services to listen only on localhost, or to filter access by ip/netmask, and
    4. put something in front of services that don’t need general public access. (A wireguard tunnel, or HTTP basic auth in your reverse-proxy.)
    5. if you expose ssh to the public, make there is some extra step that prevents you from exposing a test user you just created. I’m using the AllowUsers user whitelist, but KbdInteractiveAuthentication no should be good enough too. If the failed login attempts by the bots bother you, you could run sshd on a non-standard port.
    6. stop services you no longer use, or at least remove public access.
    7. If you have a complex service that needs to be fully public (say a video conference solution, I wouldn’t worry much about a simple static web server) then isolate it from everything else somehow. Ideally on a separate box, make sure it cannot access the internal network, make sure it cannot access any files it doesn’t need. And install those security patches.

    Something else I always wanted to do (but never got around doing) is to create a simple canary intrusion detection. Like, putting some important-looking “prod” host into ~/.ssh/config and a private ssh key, and configure the target host to send me a SMS instead when this key tries to log in. (Or even shut everything down automatically.) This should prevent me from becoming part of a botnet for months unnoticed, maybe.



  • I have a router with a few cronjobs like this:

    # m h dom mon dow command  
    00 20 12 * * echo "check bank transactions (monthly reminder)"  
    00 19 15-21 * * test $(date +\%u) -eq 6 && echo "Anki learning reminder"  
    

    Cron will by default send an email with the script output. So you “just” need a non-broken email setup that forwards system emails to your main account. (Assuming you don’t self-host email too.)

    This setup is useful because I have a few other cronjobs (backup scripts, and a health check for my own application) that should notify me in case of failure, and I would eventually notice that this is broken by noticing that those “calendar” emails no longer get through.




  • You don’t have to live with the developers. You don’t examine Google or Apple with that kind of scrutiny either, as a user. In fact you can’t, because Google and Apple developers have NDAs and PR to prevent any internal human drama from leaking to the public. Doesn’t mean there is less of it.

    With community-driven open source projects, almost everything happens in public, so you can dig up all that, and drama gets amplified through social media. If you want the illusion of something free of imperfect humans, better stick to the corporate stuff, I guess.




  • but businesses don’t have that luxury. That’s why they use proprietary software

    Wait, that doesn’t match my business experience. Those proprietary solutions are usually a collection of open source libraries and DBs and Elasticserach or Redis and whatever running Linux VMs held together with duct tape and a small amount of proprietary application code (compared to everything else) using five different open source frameworks.

    Or if you buy, say, a Lasercutter, how do you think they convert the images you prepare for engraving? Their own commercial libraries they bought from someone? Because businesses don’t do open source? Nope. How do you think businesses compile the firmware that goes into their CNC machine? Borland C++? Nope.

    When you use the proprietary software, they don’t tell you what went into it. That’s kind of the point - you are buying a solution and only want to know the price. When you host your own instead, you kind of need to know what goes into it, because you didn’t pay someone to do the integration for you.

    Or more fundamentally: with open source, you only get what the developer wanted to build. If you want someone to build what you need, you got to be either lucky that the two things align close enough, or find a way to pay someone to focus on your needs instead of theirs. Or you can hope someone else pays someone to make it and then pays a little bit extra to also publish it open source for everyone else to use. Rarely happens, but it does happen.


  • Maybe my LLM detector needs an update, but only the headline triggered it. The article did the opposite for me.

    Anyway, the author checks out, old github profile etc. Works in high frequency trading, which I despise because I think it is make-do work, moving money around a millisecond before anyone else has a chance, a huge technical effort with zero benefit to society compared to slower trading. I’ll file it together with adtech and bitcoin. But. The article is not about that. And I know that working in high frequency trading sure makes you qualified to talk C++ or FPGAs or anything close-to-the-metal. So, author background checks out. Verdict: not slop.






  • Yes but despite the footguns, C (not C++) is a relatively small language, not too hard to learn. And it’s the glue between kernel, system libraries, and all other languages. You don’t want to write big applications in it any more, but it’s still useful to know when you interface with existing stuff.