If you need to provide tools that cross security boundaries then […] a small web app is better [than sudo].
A web app? Effin really!!? 🤨
If you need to provide tools that cross security boundaries then […] a small web app is better [than sudo].
A web app? Effin really!!? 🤨
Thanks.
It is one of the most private implementations of AI that I’ve seen though.
Based on what information/criteria?
It turns out that “Women Who Code Closing - Women Who Code” actually isn’t about Women that code a software called “Closing”, and Women that code in general.
In fact, what they meant to write was:
The End of an Era: “Women Who Code” Closing – Women Who Code.
I know I’m gonna get downvoted for this, but punctuation matters, and sadly, it has to be said. So here I go.
This is the way. And I might add, Unix desktop. Let’s not start bikeshedding between FOSS Unix distributions out of dogmatic reasons (I’m sure you didn’t mean to specifically single out “Linux” here, but I wish we would stop opposing “Linux” and other Unixes like BSD, Illumos, etc).
The point is, voting with your data for software that is defending your interests, and respecting your rights.
But use the widows version and the proton layer. The Linux version is horribly coded.
Yeah, it is one of the least bad uses for it.
But then again, using literal tera-watts-hours of compute power to save on the easiest actually recyclable material known to man (cardboard), maybe that’s just me, maybe I’m too jaded, but it sounds like a pretty bad overall outcome.
It isn’t a bad deal for Amazon, tho, who is likely to save on costs, that way, since energy is still orders of magnitude cheaper than it should be[1], and cardboard is getting pricier.
if we were to account for the available supply, the demand, and the future (think sooner than later) need for transition towards new energy sources… Some that simply do not have the same potential. ↩︎
I would not call that a “privacy proxy”, it is very disingenuous. It is a normal proxy, which replaces the technical metadata from your connection, so that automated tracking is harder. But it will not replace or remove any of your input. And you can easily be tracked that way too.
Yeah, I find the puzzle sliding JavaScript captchas the best as a user. Cognitively better than “training neural networks to recognise protestors”, and still fast enough that it doesn’t feel like a forced ad. Reliability might however vary a lot between implementations.
Plus, that way, you have a trail of invites. If something goes wrong, you can prune entire branches and mitigate most abuse.
Note: this comment is long, because it is important and the idea that “systemd is always better, no matter the situation” is absolutely dangerous for the entire FOSS ecosystem: both diversity and rationality are essential.
Systemd can get more efficient than running hundreds of poorly integrated scripts
In theory yes. In practice, systemd is a huge monolithic single-point-of-failure system, with several bottlenecks and reinventing-the-wheel galore. And openrc is a far cry from “hundreds of poorly integrated scripts”.
I think it is crucial we stop having dogmatic “arguments” with argumentum ad populum or arguments of authority, or we will end up recreating a Microsoft-like environment in free software.
Let’s stop trying to shoehorn popular solutions into ill suited use cases, just because they are used elsewhere with different limitations.
Systemd might make sense for most people on desktop targets (CPUs with several cores, and several GB of RAM), because convenience and comfort (which systemd excels at, let’s be honest) but as we approach “embedded” targets, simpler and smaller is always better.
And no matter how much optimisation you cram into the bigger software, it will just not perform like the simpler software, especially with limited resources.
Now, I take OpenRC as an example here, because it is AFAIR the default in devuan, but it also supports runit, sinit, s6 and shepherd.
And using s6, you just can’t say “systemd is flat out better in all cases”, that would be simply stupid.
Thank you very much for this post. I’m glad someone did the effort of getting some of those and presenting them from the PoV of a first time experience. I was curious.
However, I’m not sure what you meant with:
BUT when I shared it with others, people in body reported less effectiveness due to thickness of skin and under-dermal stuff, so it’s better to test it if you aren’t skinny as a skeleton.
At first it sounds like you say that overweight people have trouble using them (which is logical, the device needs to touch the bones), but then you go on saying that it doesn’t work for underweight people? I’m confused. Could you please elaborate a little? Thanks 🙂
The essence of that article can be summarised in:
Honestly, if the makefile is well written, I will take that any day. Good makefiles are 😙👌.
They are extremely rare, tho…
I guess the solution would be a declarative language that compiles to makefiles. So that people don’t have to know the nitty gritty of writing good makefiles, and can just maintain a file of their dependencies and settings…
Yes, I get that point, but I also think that it’s tempting for the privacy-minded novice to think “the less information I provide, the better!”, while in actuality, it is better to provide “more” information: the most common UA, even if it means lying about your featureset. In this case, truly, more is less.
Oh gee, I wasn’t aware there was more to it than the UA. Thanks for opening my eyes.
Edit: I checked your link, most of the parameters on the test require client side execution. That (client side tracking) is absolutely unrelated to what (server side tracking) I was talking about, and is something you can control (by not allowing JavaScript, for example). Please do not confuse the two. There is literally nothing you can do against server side tracking.
Yeah, make your user agent absolutely unique. Too much entropy will surely confuse the shit out server side HTTP Header tracking. 😬
If you can’t count to 3, that’s a you problem, dude…
Hi! Great post, good research with sources, great initiative, thank you. 🙏