[-] thesmokingman@programming.dev 8 points 2 months ago

I pay for YouTube Family. I consume a lot of YouTube and I want to support the creators I watch. At its current price point, YouTube Family is reasonable. Several households in my family get ad-free YouTube for what is a reasonably low price point for each household.

If the price goes up much (eg if I were paying the single price of $11 per household), the creators I really enjoy continue to get pushed out or change content because of shitty ad rules, or they pull the whole “must be in the same household” bullshit I would drop it in a heartbeat just like I’ve dropped most streaming providers. Streaming has become cable and YouTube has been shooting itself in the foot by forcibly changing content for advertisers. I come to the platform for content, not advertisers.

[-] thesmokingman@programming.dev 8 points 3 months ago

Speaking from 10+ YoE developing metrics, dashboards, uptime, all that shit and another 5+ on top of that at an exec level managing all that, this is bullshit. There is a disconnect between the automated systems that tell us something is down and the people that want to tell the outside world something is down. If you are a small company, there’s a decent chance you’ve launched your product without proper alerting and monitoring so you have to manually manage outages. If you are GitHub or AWS size, you know exactly when shit hits the fan because you have contracts that depend on that and you’re going to need some justification for downtime. Assuming a healthy environment, you’re doing a blameless postmortem but you’ve done millions of those at that scale and part of resolving them is ensuring you know before it happens again. Internally you know when there is an outage; exposing that externally is always about making yourself look good not customer experience.

What you’re describing is the incident management process. That also doesn’t require management input because you’re not going to wait for some fucking suit to respond to a Slack message. Your alarms have severities that give you agency. Again, small businesses sure you might not, but at large scale, especially with anyone holding anything like a SOC2, you have procedures in place and you’re stopping the bleeding. You will have some level of leadership that steps in and translates what the individual contributors are doing to business speak; that doesn’t prevent you from telling your customers shit is fucked up.

The only time a company actually needs to properly evaluate what’s going on before announcing is a security incident. There’s a huge difference between “my honeypot blew up” and “the database in this region is fucked so customers can’t write anything to it; they probably can’t use our product.” My honeypot blowing up might be an indication I’m fucked or that the attackers blew up the honeypot instead of anything else. Can’t send traffic to a region? Literally no reason the customer would be able to so why am I not telling them?

I read your response as either someone who knows nothing about the field or someone on the business side who doesn’t actually understand how single panes of glass work. If that’s not the case, I apologize. This is a huge pet peeve for basically anyone in the SRE/DevOps space who consumes these shitty status pages.

[-] thesmokingman@programming.dev 8 points 3 months ago

You’ve done a great job summarizing the bad things they’re doing!

[-] thesmokingman@programming.dev 8 points 5 months ago

Did man write grants to show how said fire had military applications? If so, how dare they! If not your straw man is kinda lacking.

[-] thesmokingman@programming.dev 8 points 7 months ago

This is the house that Jack Welch built, not Thomas Edison. Welch tore down anything that came before and threw up some particle board facades to convince the market there was a skyscraper there.

[-] thesmokingman@programming.dev 8 points 9 months ago

Which of these is an example of bootlicking?

[-] thesmokingman@programming.dev 8 points 10 months ago* (last edited 10 months ago)

@Aboel3z@programming.dev are you ever going to interact with the community or are you just pushing your blog?

Also how did you solve this problem in 2010 if you only learned how to code in 2019?

[-] thesmokingman@programming.dev 8 points 10 months ago

What evidence did you find to support Substack’s claims? They didn’t share any.

You can quickly and easily find good evidence for things like Reddit quarantining and the banning of folks like Alex Jones and Milo Yiannopoulos.

Which claims are empirical again?

[-] thesmokingman@programming.dev 8 points 11 months ago

If the board is beginning from the premise that it is ethical to waste the time and resources of everyday citizens who did not explicitly opt into getting spammed, their ethics are already compromised. VC funding already captured the regulatory body that should have prevented this massive waste of resources. No one high-minded would use tech like this.

[-] thesmokingman@programming.dev 8 points 1 year ago

But it’s not public. It’s a private blockchain. The immutable ledger aspect only matters if everyone can see the ledger. Otherwise we take at face value all of the things you said. Assume they run one node and that one node is compromised by a malicious actor. The system fails. Extend it to a limited number of nodes all controlled by SREs and assume an SRE is compromised (this kind of spearphishing is very common). The system fails again.

Sure, you can creatively figure out a way to manage the risks I’ve mentioned and others I haven’t thought of. The core issue, that it’s not public, still remains. If I’m supposed to trust Proton telling me the person I’m emailing is not the NSA pretending to be that person (as the Proton CEO suggested), I need to trust their verification system.

[-] thesmokingman@programming.dev 8 points 1 year ago* (last edited 1 year ago)

This is how I read digitally ¯\_(ツ)_/¯

[-] thesmokingman@programming.dev 8 points 1 year ago

Spend a little bit of time writing out pros and cons when this happens. The important thing is to actually write it down; don’t just leave it in your head. If this is a regular conversation you have, keep that list handy and keep it updated. Make sure you’re taking into account time and resource considerations (eg running your own Mastodon instance requires money or time and effort) as well as soft considerations like social impact (eg you gotta convince all your friends to join Signal). Make sure to keep moving things around.

For me, the time and effort involving in running certain things just isn’t worth it to me. I have limited time available and I don’t often want to spend it fucking with servers. Convenience also plays into some of my comms choice because it’s just easier to use certain things to do the kinds of things I need to do.

I cannot stress enough that you should write this down. Getting stuff like this out of your head and onto paper has a lot of helpful benefits. You move the problem from your working memory and onto paper which helps reduce cognitive load (see Programmer’s Brain and sources). You have a discrete problem you can update without having to constantly rebuild the whole thing in your head (see How to Take Smart Notes and sources for the idea of the zettelkasten). And eventually you’ll be able to tell yourself why you do one or the other.

view more: ‹ prev next ›

thesmokingman

joined 1 year ago