/tech/ - Technology

A thread for posting PDFs related to software, IT, programming, hacking, networking, math, technology, engineering, and science in general.

People love to moan about Electron, but is there any practical alternative to it?

https://github.com/twitter/the-algorithm
What does /tech/ think about it? It's AGPL.

How would I go about making a large database of resources? One that effectively tracks their consumption and production and would allow for the addition of new users easily? Something anyone with an internet connection could connect to.

What’s the legality of this stuff?

china's firewall is not really a firewall or a dns blocker, it's an actually sophisticated machine learning system that WILL fuck your shit up

> I’ve been employed in tech for years, but I’ve almost never worked
https://emaggiori.com/employed-in-tech-for-years-but-almost-never-worked/
Okay bros, which one of you snitched? I thought we all agreed not to let the non-techies find out that we are paid mad money to do nothing.

Why are certifications valued more than degrees, even if they are much easier and cheaper to get? What's the freaking point of wasting years and/or millions in college then?

>Site reliability engineering (SRE) is a set of principles and practices that incorporates aspects of software engineering and applies them to infrastructure and operations problems. The main goals are to create scalable and highly reliable software systems. Site reliability engineering is closely related to DevOps, a set of practices that combine software development and IT operations, and SRE has also been described as a specific implementation of DevOps.

This is a thread for all discussion of Site reliability engineering

SRE is usually used at larger organizations which have multiple applications, services, etc. Where it gets confused with devops is that devops is automation and streamlining of traditional sysadmin tasks related to integration and deployment pipelines, essentially programmatically managing traditionally manual processes like testing and deployment to various environments. Whereas SRE is automating sysadmin tasks related to performance, observability, and reliability, as is in the name. The job devops engineer is replacing is the traditional sysadmin, wheras the job the SRE is replacing is whats known as a production support engineer or creation software engineer, less well known but essentially a SWE who's job it is to support applications. Its not support like helpdesk-install windows or whatever, its support engineering of an application, or set of applications, restarting scheduled jobs, database tasks, debugging java code, if heap utilization is too high or whatever. Essentially providing L2 support for complex enterprise or microservice type applications (L3 handled by the SWE's).

SRE is automating those tasks and building software that automatically monitors ops and programmatically restart services, etc. Essentially automating the job of a traditional production support engineer so that the system self heals and automatically detects and solves common issues by itself. Google invented SRE role so that it could create the outside appearance that the service is always up. The most extreme example is the chaos engineering/chaos monkey approach to SRE invented by netflix which had its reliability engineers invent tools that automatically crash certain servers in production so that they could make sure the system keeps running no matter what.

So both SRE's and DevOps engineers are focusing on automating traditional sysadmin tasks so they ovePost too long. Click here to view the full text.

I'm not a huge fan of go because the language is essentially the fixed gear hipster bicycle of programming language. The whole golang started as essentially another version of the Plan 9 version of C started in the early 1980s. Even the golang mascot is literally a copy of "glenda" the plan 9 mascot:
https://en.wikipedia.org/wiki/Plan_9_from_Bell_Labs
The designers of go essentially decided to eschew every advance in programming language theory from after the 1970s and just recreate another version of C: an imperative, structured language with no FP/OOP features, generics, etc. with a focus on distributed systems. Go also has some significant drawbacks, like the fact that concurrency is pretty difficult and error prone, just as it would be in C. That's fine for some use cases but the idea that this could be a generally applicable programming language is nuts. Golang could probably be used in a lot of places where C, C++, Rust, etc. could be used.

But the idea of writing general purpose back end enterprise/web software in it is pretty unappealing to me. I sincerely hope it doesn't catch on in these spaces.

>When it comes to sharing AI experiences with your friends, there's no place like fbi.gov. Today, we’re introducing new AI experiments, including an AI chatbot named Clyde, AutoMod AI, and Conversation Summaries, and launching an AI Incubator.
It's all so tiresome.