You really only need dirty_ratio/bytes and dirty_background_ratio/bytes set to something lower than default. It also makes your progress bars show values closer to reality, especially when copying from fast to slow media.
Some distros already do set lower defaults, e.g. pop os:
> You really only need dirty_ratio/bytes and dirty_background_ratio/bytes set to something lower than default.
The vm.swappiness=1 was very necessary for me as well, and made as much difference as the dirties you'd mentioned.
I usually run Linus' master kernels (as I look for regressions in certain subsystems) and I know there's been some recent changes to the MM subsystem so this may explain some of the necessity for me.
> All they would have to do to support this is add a checkout field "VAT number" that shows up on a pdf invoice.
If only it would be that simple :)
In EU you have different procedures for B2C and B2B transactions. For B2B you need to verify the VAT number in VIES system and it’s not responsive like 50% of the time. I swear Germans literally turn off their servers when they go to sleep. If a customer provides a VAT number the flow might take even 12h+ to verify it. If you can do that verification you can use 0% VAT rate but if not you need to use a different VAT rate.
For B2C you need to support several scenarios: if company is outside of EU it needs to register for IOSS, if it’s a EU company that sells to other EU countries it needs to register for OSS or in each EU country for VAT separately but also a mix of both is possible. You can decide to no register to OSS special procedure but then there’s a sales limit before you have to register and you need to track it. Otherwise, you need to maintain special OSS registry with sales records and three pieces of proof that customer is based in the member country. Some EU countries have XML invoices (Italy, Romania, Germany soon) or mandatory invoice APIs (Poland), of course there’s actually no common EU standard so it depends on where the company is based.
Finally you need to choose a VAT rate for that country and they also change occasionally, e.g. Slovakia, Romania and Estonia all changed their highest rate just last year.
This is the bare minimum you need to support. There’s a lot of edge cases, e.g. it matters what country you actually ship from, and if you use e.g. fulfillment there are special procedures for that as well, or if you resell in B2B there are chain transactions which have their own set of spaghetti rules.
Much of that is at least for my company handled by our accounting company. We just print the correct VAT on the invoice, and report the same VAT to the accountant and they take care of the rest. The shop/payment processor etc doesn't need to be integrated to any of it. Though I have to post-process Stripe's reports, as they refuse to include the used VAT rate in there, despite them knowing it. Stripe does try to sell the tax service to us, but I refuse.
You can simplify for your use case (only B2C or you refund VAT afterwards for B2B, you only ship from one location, custom invoicing), but that’s what it takes to implement it correctly on platform level.
Yes, it will be ineffective, so then they will point at all those examples, but will they decide the law is stupid? Of course not.
The computers are not secure and they should only be able to run “verified” operating systems using attestation mechanisms. This was always where this was ultimately going. The idea has been fermenting since the DVD players had copy protections.
It’s the planet destroying asteroid. We know the trajectory, we always knew it was coming for us. But once you can see with the naked eye it’s too late to do anything.
> The EU is working on a type of digital ID that an age-restricted platform would ask for, which only gives the platform the age information and no further PII.
Sure, it might start out that way, but once adoption reaches anything critical the PII will be required to squash free speech as soon as possible. But by then the interaction flow will be familiar, hardly anyone will even notice, never mind care.
The EU has the best frog boiling experts in the world.
> ... will be required to squash free speech as soon as possible.
Maybe pointing the obvious but things happen if enough people care about them or do not care to oppose them.
From my perspective speech became "more free" lately - meaning everybody says all kind of incorrect, wrong things without fear of retribution even if there are laws against some of those, because people just don't care.
So maybe we should also focus on teaching people what is free speech, why is it good for them, why they needed, rather than worry about some hypothetical mechanism that someone will prevent it.
Of course both can be done, but I find it a bit funny that if the focus in mostly on not having mechanisms to prevent free speech, we might still end up in a situation that there are no such mechanisms but on the other hand nobody speaks freely because they don't care or only stare at their tiktok.
By this reasoning we should oppose every law in case it's a foothold to sneak in a different law.
The CA/CO parental controls API law is very reasonable. It only mandates each OS must have a parental controls API, the use of which is up to the parents.
Yep, the digital wallet will become the authoritarian, beating heart of your life. If you don't comply with the EU, you can say bye, bye, to your bank account, any online interaction, they block your right to travel and so on.
The corona passports showed the way to achieve ultimate control of the population, and the EU digital wallet will be a permanent corona passport.
The public sheep, in their ignorance, are cheering this on, without knowing what will await them. It is our responsibility as technologists to fight this, and to educate the sheep.
Go to [Settings] » [Apps] » [Special app access] » [Display over other apps] and check if any preinstalled carrier apps or anything suspicious has this permission granted.
Apparently this is handled by the privileged STK[1] service. It can launch browser which is I think what's happening.
GrapheneOS presently doesn’t do anything different in this case, they pull it from AOSP without modifications. However you can disable it using the frontend app (SIM Toolkit) as someone pointed out, but as far as I can tell this requires the applet on SIM card to cooperate (offer the opt out).
Otherwise you can disable the STK altogether with ADB but that will also block you out of other SIM card interactive functions, which might not be a big deal however.
Edit: "We plan to add the ability to restrict the capabilities of SIM Toolkit as an attack surface reduction measure. (2022)"[2] and open issue[3].
The "fake" user/profile should work like a duress pin with addition of deniability. So as soon as you log in to the second profile all the space becomes free. Just by logging in you would delete the encryption key of the other profile. The actual metadata that show what is free or not were encrypted in the locked profile. Now gone.
Sorry I explained it poorly and emphasized the wrong thing.
The way it would work is not active destruction of data just a different view of data that doesn’t include any metadata that is encrypted in second profile.
Data would get overwritten only if you actually start using the fallback profile and populating the "free" space because to that profile all the data blocks are simply unreserved and look like random data.
The profiles basically overlap on the device. If you would try to use them concurrently that would be catastrophic but that is intended because you know not to use the fallback profile, but that information is only in your head and doesn’t get left on the device to be discovered by forensic analysis.
Your main profile knows to avoid overwriting the fallback profile’s data but not the other way around.
But also the point is you can actually log in to the duress profile and use it normally and it wouldn’t look like destruction of evidence which is what current GrapheneOS’s duress pin does.
The main point is logging in to the fake profile does not do anything different from logging in to the main profile. If you image the whole thing and somehow completely bypass secure enclave (but let's assume you can't actually bruteforce the PIN because it's not feasible) then you enter the distress PIN in controlled environment and you look at what writes/reads it does and to where, even then you would not be able to tell you are in the fake profile. Nothing gets deleted eagerly, just the act of logging in is destructive to overlapping profiles. This is the only different thing in the main profile. It know which data belongs to fallback profile and will not allocate anything in those blocks. However it's possible to set up the device without fallback profile so you don't know if you are in the fallback profile or just on device without one set up.
Hopefully I explained it clearly. I haven't seen this idea anywhere else so I would be curious if someone smarter actually tried something like that already.
What you say makes sense, just like the true/veracrypt volume theory. I can't find the head post to my "that's why you image post" but what concerns me is differing profiles may have different network fingerprints. You may need to keep signal and bitlocker on both, EVERYTIME my desktop boots a cloud provider is contacted -- it's not very sanitary?
It"s a hard problem to properly set up even on the user end let alone the developer/engineer side but thank you.
Both tree and rat took out my fiber so the loops are definitely useful. If your fiber goes through your whole house it's significantly less work to only have to reconnect one end instead of redoing the whole run.
While eCall has some weak privacy protections (it's open to all the standard cellular network surveillance lawful in each country), it also means you cannot disable the vehicle's modem in most (maybe all) EU countries with failing roadworthiness checks and insurance policies.
eCall mustn't be active until an accident occurs. The lawful interception lobby tried hard to turn every car into a free data point they could sell to the government, but their efforts have failed.
Last I heard they've shifted their efforts to making remote activation of on-board cameras part of the 5/6G smart car bullshit (which will of course be part of road safety requirments not long after).
Annex VII only rules out connecting to the PSAP/112 side, not routine network attaches. To detect faults in the “means of communication”, the IVS has to verify that the SIM, baseband and RF path are actually usable, and you can’t test that without a network attach.
In practice that’s what all current eCall implementations do. The modem attaches to the cellular network at each ignition so it can confirm it’s capable of placing an eCall. If you block the modem or antenna, the IVS fails its self-test and the vehicle is no longer roadworthy.
Does that mean the modem used for eCall is the same that is used to transmit telemetry? Because that's a level of shitty I hadn't even considered. That said, it would go against the spirit of the law as I read it.
There are always workarounds, of course, but that does pose an annoying problem to patch.
Yes, unfortunately in all modern calls there's a single Telematics Control Unit with a modem, GPS/GNSS, eCall (where required) and whatever OEM telemetry stack.
Like you say, there are always workarounds, but none that the home-gamer can safely or legally modify without taking eCall out of compliance.
There are standalone eCall units for retrofitting, e.g. [1] and likely soon more since 2G/3G gets phased out. Presumably you could disable the manufacturer’s built-in system and use standalone system instead?
Some distros already do set lower defaults, e.g. pop os:
https://github.com/pop-os/default-settings/blob/master_noble...
Bazzite: https://github.com/ublue-os/bazzite/blob/main/system_files/d...
reply