mikevin's comments

Any idea where to find the source? Wondering how it's set up.

Would certificate pinning also remove the first option? I wonder if we are moving to a system where inspecting your own traffic isn't a viable option anymore, am I missing a workaround?

I mean that's something you need to do every time a DB is involved. Not really an argument against ETAGS.

Of course there's a conflict of interest. It's their right to promote their solution but I would never take their word for it.

Sometimes I wish I had the kind of education that allows you to interpret Terms of Use, Privacy Notices and other legal mumbojumbo in a way that answers my questions. It's great practice if you like cryptic crosswords though.

Is that the correct video for CPS?

Do you have a writeup of the technical details? How does this exploit (without reading the code and reverse engineering it)?

I'm curious what the compressed text looks like. Anyone have an example?

I really like "archive" and "tag" overviews. I don't want to scroll through every post in full as a way of finding an entry that interests me. Not really a blog but Hackaday on mobile is really bad at this. It's kind of hard to filter for interesting stuff without having something specific to search for.

Do you have a repo for your Guile solutions to AoC? Would love to see it.

Can you expand on why you prefer that approach?

> What do you mean by threaded here?

Here's a good explanation.

https://www.bradrodriguez.com/papers/moving1.htm

Why does the ISA spec define the starting adress of the text segment anyway? Struggling to find a good reason.

This might be a bit extreme but if you really want to learn bottom-up I would suggest nand2tetris https://www.nand2tetris.org/ It's not about networking but it's a good way to understand the picture from electrons wiggling to a basic computer. It involves all the layers below Linux basically and a little bit of overlap. I'm not sure how much it will help in your network programming goals but it's not that hard to do and helped me a lot with fundamentals and knowing which parts of a system are responsible for what.

For more direct help I believe Beej's guide to network programming is greatly recommended https://beej.us/guide/bgnet/

Does you know of a good resource to learn this kind of research/fact checking. I don't have an academic background but recently got interested in improving my ability to identify "fake news" and assess the validity of some paper.

Where does one even start? Even finding the original paper seems a challenge, news articles mention one and then just to another news article. If I search the web for the title and author it feels like most websites are just rehosting the content, like with manuals/datasheets. Not sure how to get started here but your comment makes me think you might know some resources.

'Proof of Authority' sounds an awful lot like the regular banking system.

Theoretically automatically popping up that dialog could result in you authenticating without being aware you did so. It would require you resting your finger on the right spot but it might be the reason for this behaviour.

This might come across a but harsh but I don't know how else to put it without resorting to my native language but I feel kind of sad for you. You sound like someone's who's lost hope in (at least part of) humanity.

Your anecdote suggests this is a truth about all engineers and while I cannot disprove that I might as well counter with my personal anecdote.

In my experience, engineers tend to be very sensitive to the environment they work in. When unsatisfied with the workplace environment, they might go off on side quests but trying to "fix" that with tightly controlled process is fighting symptoms, not causes and will generally result in an even more unsatisfied engineer who appears more valuable because they've learned how to hide the unproductiveness. I've seen this happen and it definitely didn't add any value for the business.

The real solution is to try and create an environment where people have trust in each other and are committed to a common goal. I've been lucky enough to experience these kind of jobs where it's just professionals committed to a product they believe in. We're all adults so if someone disappears on a side quest that's hurting the team we talk about it. Maybe someone just got distracted and needs someone to point it out, a simple mistake which is ok every once in a while. Maybe someone is having a bad time and needs to take a vacation, understandable and also ok since we're humans first, engineers second.

But most importantly: if someone is regularly hurting the team's goals and isn't willing to improve the situation or acknowledge it then it's simply not a good engineer/colleague/asset to the company. No amount of process is going to change that and even if it does you're probably losing productivity from the rest of the team because they were productive in the old approach. A flat tire doesn't mean cars are a bad mode of transportation and switching to a horse is not going to get you to your destination any faster. Why not replace the defective tire instead?

If the situation I described above sounds unrealistic to you maybe the companies you've worked for need to review their hiring process. If you don't trust the engineers you've hired with the process you'd be doing yourself a disfavor by trusting them to do the job they were hired to do.

A ticket supposedly represents some worthwhile task that's worth specifying. If it takes just 30 seconds to create it can't possibly concern a task that's worth the cost of involving ceremony/process.

I don't think it is. We're all professionals, if I'm doing something they need to know about then I'll inform them.

A ticket that takes 2 minutes to create is just distracting from tickets that provide real value to my colleagues. We're here to work together and improve something, not to babysit each other's schedules.

"Visibility into what I'm doing" as a reason to create a ticket is relevant for micromanagement, not for a team of professionals that trust each other's commitment to the job.