For many users it's just not true. I run a subscription weather forecast service for pilots, with a free trial period. A significant number of users reset their device every week to avoid paying 10 euros a month. These are aircraft owners.
Just because you own an aircraft, doesn't mean you have a budget to pay random EUR 10/month subscriptions.
People save money to buy expensive stuff. Or take out loans. One cannot assume that everyone doesn't care about spending < X dollars, where X is = 1% of the most expensive asset they own (see e.g. $3000 gaming PC vs. $30 software, elsewhere in the thread).
Everyone's poorer than you think, and sometimes the richest seeming people are under a mountain of debt.
> own an aircraft, doesn't mean you have a budget to pay random EUR 10/month subscriptions.
Still, if you can't afford a €10/mo subscription necessary to operate the airplane safely, when hanger fees are well in excess of that, then perhaps you can't actually afford to own an airplane? Airplanes aren't cheap to own, nevermind the aircraft itself.
Put it another way. I like driving BMWs, but, y'know what, I hate having to pay insurance, and I can't afford to pay that after
the monthly BMW lease payment, so I just don't pay it, cause fuck that noise.
I don't think most people's response to someone saying that would be "eh, sounds fine, BMWs are expensive". "So don't drive a BMW." seems like more likely reaction to me.
The reason people will tell you that is because paying for car insurance is rarely something you can just opt not to do, at least not without consequences. The consequence for not paying for a $10/month service is having to perform a minimally inconvenient chore once a week.
Indeed. Where I live, civil liability insurance is mandatory and if you own a car, you have to pay it, even if you don't intend to actively drive. It's not an optional cost.
There will always be some amount of people who are too cheap to pay.
However, that doesn't mean that if you plug all the holes that they will pay. No. They'll just not use your service.
In the long run it's better to keep these types of people around because they at least advertise your service. But getting any money out of them is a pipe dream.
People often frame piracy as "oh 5% pirated instead of paying!" Well... the "instead of" part is doing the heavy lifting there. The options arent pirate or pay. They're pirate, pay, or not use.
In the short term, maybe. I don't think that's the case in the long run. They normalise the behaviour for others, even telling them about how to get around paying. I see strong clustering of the behaviour.
I think op meant the subjective feeling of having a system that runs in a stable manner.
I don't quite follow their reasoning either (maybe the smaller changesets expose compatibility bugs before affecting general ux?), but I agree that arch was a joy for me to use and felt "stable".
If you're trying to deny internet access to a program, beware that landlock only restricts tcp sockets. Programs are free to setup udp or just raw sockets.
It's just incomplete and very early days for landlock.
Landlock requires you to commit upfront to what is "deny-default"ed but they only added a control for TCP socket bind and nothing else. So you can "default-deny" tcp bind but all the other socket paths in the kernel are not guarded by landlock. It tries really hard to have the commit of features be an integral part of the landlock API so that you can have an application able to run on multiple kernel versions that support different parts of the landlock spec. But that means that as they develop the API the older versions of landlock need to be less restrictive than newer versions otherwise programs dont work across kernel versions.
That way, a program that is very restrictive on say kernel 6.30 can also run on kernel 6.1 with less restrictions. The program keeps functioning the same way (never break userspace). The only way to do that is to have the developer tell what parts need to be restricted explicitly and you can't restrict what isn't implemented yet.
There's always a lot of caution and review that goes into a new syscall feature, because once you add a feature, there's no takebacks. All the libraries downstream from landlock rely on the kernel API being good.
There is an ongoing patch series for udp and another one for general socket control.
You can read about it on the linux-security-module mailing list.
Basically UDP is harder to hook into because it's a connectionless protocol. So bind and connect don't really work the same way.
They can be disabled by firewall, iptables can match outgoing sockets by owner uid. I know it's not the same thing as landlock, still can come in handy.
And raw sockets require elevated privileges anyway iirc.
I think it's only "weird" if you don't understand why it is the case... adding UDP/raw socket support is much more difficult, and waiting to get that implemented would have much larger downsides for the project as a whole to gain any traction in the meantime.
Well, NASA tried that originally but didn't have the budget, and in that sense it's better late than never to fund something different.
The reasoning as presented just doesn't reflect reality.
reply