well, before that and for generations, banks printing money was an acceptable way of governments to make rich people richer and all others poorer, so i can fully accept that stealing was learned from govs and the richies there. change how “the successfull” accomplish their successes and you can teach the kids how to live without stealing, keep abuse by gov and richies as is and all the theft is done exactly as ordered by govs and richies, no matter the age.

i would try printing the filter part as a flat surface (without retractions) directly on the printer bed (only 3 layers maybe) and bend it later to become a tube ( like a “C”) i am not sure about petg, i did this bending with pla. hot water comes in handy and maybe a glas bottle. also prepare something to tighten where the ends of the C connect, a border without the small filter holes but some larger holes for something like cable ties or even a printed part for connecting the C edges.

they get even more revenue from other peoples contributions.

thats the whole point not more, not less.

so there is no point for “you” to pay them anything.

did you as a “premium customer” thought to be “the customer”? really? remember how little you personally pay for the service. it is mainly the ad companies who are youtubes “customers”. when you pay them for something, you only increase yt’s revenue, not more, not less, but you are not “the customer”, you are the product ;-)

i’ld like this summary the most:

Musk now says it’s ‘pointless’ to build a Tesla

😁

but maybe only for emails from outside, not for emails from within protonmail? haven’t read any specs of protonmail yet…

well for e2ee you obviously have to let one e encrypt the data for the other e. (good luck with newsletters then) for usual services kindly asking them to support either s/mime or gpg for outgoing emails, that would at least make them know the wish, but good luck there too.

i think the already mentioned solution with encrypting incoming messages on your side just before mda to your inbox should be the closest possible to what op wants. one would need to check if the message is already encrypted and skip encryption for those.

if you only want the admin of that email (imap) server to not be able to read all emails, maybe placing a separate encrypting server (smtp+encrypt+forward) inbetween outside world and your email imap server could be a solution.

one should have a look into the logfiles too as some mailers might log message subjects and of course sender/recipients along with ip adresses of incoming/outgoing servers which the op might not want to be readable as well (i dont know protonmail that much)

also gpg IMHO allows for sign-then-encrypt hiding the signature within the encrypted data which could be wanted. also one might want to look exactly what parts of the messages contents and its headers are encrypted or plaintext on the server before feeling safe from the threat one wants to be protected from.

but then the admin can still read the mail while it arrives ;-)

yes, maybe they just lived in a too poor country and should have seen the signs and move to a civilized one way ahead instead.

well there is plenty of what is possible to try. but unless one had looked at the real cause i’ld suspect one of apples hardware backdoors to cause the crashes like if the backdoor doesn’t work, crash the kernel, so we never loose control over the sheeapple thing. or more realistic if you want:

First maybe just crappy hardware:

There is a reason why i suspect apple’s hardware, cause my shitty macbook at work should(!) go to something like hibernate, sleep, or its spyveillance-only mode when closing the lid, and it should also lock the screen when doing so, the actual results seem pure randomly choosen, sometimes the sleep mode survives the weekend with lots of accu left, sometimes its completely depleted and i even have to charge it for a while before it has enough power to show the charging logo. for security reasons i have to manually lock my screen, verify it and then close the lid, which is pure annoy. this could just be buggy hardware, a sensor so broken that reading its inputs directly could crash any OS that assumes i.e. no division by zero, pointers to nonexisting ram or whatever, and maybe apple just knows what faulty measurements mean what (but cannot make that stable too, only no crash occurs)

secondly with a hardware backdoor:

https://www.kaspersky.com/about/press-releases/2023_kaspersky-discloses-iphone-hardware-feature-vital-in-operation-triangulation-case

“The discovered vulnerability is a hardware feature, possibly based on the principle of “security through obscurity,” and may have been intended for testing or debugging. Following the initial 0-click iMessage attack and subsequent privilege escalation, the attackers leveraged this hardware feature to bypass hardware-based security protections and manipulate the contents of protected memory regions.”

which is that (some/all?) iphones have at least one memory page where one only has to accidently or intentionally write something into it, that could trigger the backdoor feature to let you choose which memory address to overwrite with what bytes, bypassing every(!) security mechanism in hardware AND of course those made of software too. that is how i understood documentation and presentations about it. now apple said they “fixed” it in software, from what i remember that fix was just a “os preventing apps from writing to that memory backdoor page” thus not a fix but only a mitigation, while “fix” is more a lie than only misleading words to just pretend it wasn’t permanent and unfixable. let us assume that linux does not include hardware backdoor mitigations for apple devices AND that apple placed the very same backdoor memory page into macbooks as well but maybe at (an)other physical address(es). now the code that runs on closing the lid “might” just reside at or write to the very same memory page on every boot for a given exact same kernel, which might be a memory page that acts the same or similar like that iphone hardware backdoor, overwriting some other memory page depending on what is actually written to the backdoor page which immediately crashes the kernel. if that’s whats happening there, t2linux is not broken, but macbooks are just insecure costly (loss of money, time, security, trust, work performance, patents, stability, a.s.o. …) waste.

how to find out? (maybe)

• get the kernel code.
• deactivate every driver not needed to boot and run the lidclose stuff like i.e. the sensor, compile the kernel anew and try booting from it.

changin the kernel a lot by removing everything(!) not needed should in theory/hopefully also change the pages that would be affected when closing the lid. same effect: likely no backdoor. no effect: maybe something you deactivated, maybe yet another backdoor discovery.

it might also be solveable by sth like acpi settings or such, probably switchable from kernel boot cmdline , maybe change settings for hibernate / suspend to ram (does apple hardware even support such? i mean without the buggy behaviour i experience?)l