blurker (u/blurker) - Readit News

blurker commented on GrapheneOS is the only Android OS providing full security patches grapheneos.social/@Graphe... · Posted by u/akyuu

drnick1 · 18 days ago

If you have a Pixel -> Graphene, if not -> Lineage.

I personally don't care about "security" all that much, my main reason for using Graphene is freedom to use my hardware in any way I wish. This means unrestricted ability to run any program on the phone from any source. Sideloading restrictions don't apply to Graphene, and it is also impossible for state actors to impose things such as client-side scanning of text messages. It's also immune to unwanted AI anti-features.

I use my own "cloud" infrastructure with my phone and I am not interested in using Google's. My Graphene device is configured to route all traffic through Wireguard tunnel and my DNS server. I also use exclusively use my own email server and "cloud" storage for all non-work related purposes. Graphene makes this easy by not leaking any information to Google.

blurker · 18 days ago

That sounds amazing. I aspire to get a setup like yours. I am on a Pixel with the stock OS and I can't stand the way Google is pushing AI into everything on my phone.

I haven't switched it to Graphene OS yet because I read that there are issues with NFC and a few other things. I assume this new phone won't have those problems so I think that will be my catalyst to do a big overhaul.

blurker commented on In React {Transitions} = F(state) jordaneldredge.com/blog/t... · Posted by u/captbaritone

mvdtnz · 9 months ago

Every time I delve into a large React codebases (and I have worked on some real monsters) I have a laugh to myself at how badly these guys tie themselves up in knots in order to preserve the supposed simplicity of the state -> UI function. When you invent something as insane as the hooks API in order to maintain purity it's time to step back and consider if you're really on the right track.

blurker · 9 months ago

I've seen some pretty good React codebases and I've seen plenty of backend spaghetti code. In all cases it's not the tools, it's the programmers and usually it's layers and layers of people not taking the time to write clean code. Probably because their management doesn't value it or they don't have someone with the experience necessary to guide them towards clean code.

blurker commented on In React {Transitions} = F(state) jordaneldredge.com/blog/t... · Posted by u/captbaritone

jschrf · 9 months ago

The vast majority of state problems in React are a result of nonsense cargo culting around the idea that classes are somehow bad.

blurker · 9 months ago

I disagree. With classes, everything was stateful (because, y'know, classes). People were doing all sorts of crazy thing with the lifecycle methods and it was always a pain to have to remember the "this scope" and bind your event handlers. I saw so many bugs written by people who lost track of what "this" was.

Both paradigms have foot guns but having used both I much prefer the hook version.

blurker commented on Knowing where your engineer salary comes from seangoedecke.com/where-th... · Posted by u/mooreds

datadrivenangel · 9 months ago

The company not being able to run without you doesn't mean you have job security, it just makes the company hurt more when they fire you based on someone's spreadsheet.

blurker · 9 months ago

Tell that to the gatekeeping engineers who think otherwise.

blurker commented on Knowing where your engineer salary comes from seangoedecke.com/where-th... · Posted by u/mooreds

virgilp · 9 months ago

There's a subtle but very important difference between making sure nobody is a "single point of failure" or bottleneck (heck, most great engineers will actively work with management to make sure they're not single points of failure!), and recognizing that engineers are not fungible resources and should not be treated as such.

I do agree that it's simpler for management to pretend that they are, and that's why great management is insanely rare. But great management, like great engineers, can make a huge difference in the success of a company / project.

blurker · 9 months ago

> most great engineers will actively work with management to make sure they're not single points of failure!

Sure, but that is a load bearing "great" for sure. Not every company is staffed with great, selfless engineers.

I'm an engineer and I've worked at companies with engineers who actively resisted making themselves not a single point of failure because it gave them control and job security. I think it's not uncommon to have these types at companies and it really sucks when they have their management Stockholm syndromed because they make it hard for all the other "great" engineers to do their jobs.

blurker commented on Is this fraud? And if so, to what extent am I responsible? workplace.stackexchange.c... · Posted by u/Wowfunhappy

delusional · 2 years ago

I get what your saying, but boy do I not want to live in society created by this worldview. In my opinion, this approach is antisocial. It forces everyone to write massive contracts and build bureaucratic mega processes to validate and specify every single definition in that contract because you can't ever trust your counterparty to abide by the spirit of your request.

blurker · 2 years ago

This comment really nicely captures how I feel about this. There's something to be said about good faith and knowing what the spirit of the agreement is.

There are some comments here saying stuff like "these compliance forms are ridiculous and are often just bureaucratic nonsense" and you see comments advocating for playing dumb and answering in bad faith and there you go.

I see there being a bit of an attitude of "everyone is doing it" to justify also doing it just to compete because you're at a disadvantage if you don't. And that's not entirely wrong but it sucks and I personally will avoid competing in that way. Probably that means not much sales in my career. Or science, but that's another topic...

blurker commented on Browser extensions spy on you, even if its developers don't vitonsky.net/blog/2023/09... · Posted by u/vitonsky

bandergirl · 2 years ago

The title is inflammatory. By allowing random JS or by selling the extension, developers do spy on you. It’s like inviting a tiger into your office and then suggesting that the ensuing damage isn’t your fault.

Browser extensions won’t spy on you, if you use trusted extensions by trusted members of the community.

blurker · 2 years ago

Yeah I came away feeling like this was clickbait. Based on the title I expected to read something about the app stores quietly injecting telemetry in your extension or something like that. Something outside of the developer's control or being done quietly by default as part of the standard packaging and delivery pipeline.

What the author described was very much not that. What they described was developers making a conscious decision to add untrusted code to their extension without properly verifying it or following security best practices.

A more accurate title would be something like "It's hard to trust browser extensions, developers are bombarded with offers of easy money and may negligently add malware/adware"

blurker commented on Gothub: Alternative front-end for GitHub written with Go codeberg.org/gothub/gothu... · Posted by u/popcalc

smarx007 · 2 years ago

This seems to be due to [1], so the project is hardly demoable now.

[1]: https://codeberg.org/gothub/gothub/issues/124

blurker · 2 years ago

Ahh as someone who has built several scraping applications, I feel their pain. It's a constant battle to keep your scraper working.

blurker commented on Farewell EC2-Classic, it’s been swell allthingsdistributed.com/... · Posted by u/alexbilbie

stilwelldotdev · 2 years ago

"Retiring services isn’t something we do at AWS. It’s quite rare."

I read this while I was taking a break from working on an epic to migrate our stuff off of OpsWorks before it gets shut down in May.

blurker · 2 years ago

Bloody shame, OpsWorks was a great service in my experience. I built a few clusters with it before Kubernetes and terraform were a thing.

That said, I heard from folks at AWS that it was not well maintained and a bit of a mess behind the scenes. I can't say I'm surprised it's being shut down given where the technology landscape has shifted since the service was originally offered.

RIP OpsWorks.

blurker commented on Applying SRE Principles to CI/CD buildkite.com/blog/applyi... · Posted by u/mooreds

blurker · 2 years ago

> Back when I was a junior developer, there was a smoke test in our pipeline that never passed. I recall asking, “Why is this test failing?” The Senior Developer I was pairing with answered, “Ohhh, that one, yeah it hardly ever passes.” From that moment on, every time I saw a CI failure, I wondered: “Is this a flaky test, or a genuine failure?”

This is a really key insight. It erodes trust in the entire test suite and will lead to false negatives. If I couldn't get the time budget to fix the test, I'd delete it. I think a flaky test is worse than nothing.