mpldr

UKI isn't by redhat but by the Kernel devs, iirc. No redhead certs required. If you want to run with secureboot, you can use your own certs, but you can also just skip SB.

Yes, we must lock down everything and make it fully proprietary. Imagine having interoperable systems without vendor lock in!

> makes you more likely to […] have unprotected sex

As someone with ADD, I wish I could agree. Adding to that, ADD can also be reasonably economically productive if the field of work aligns with the requirements of the condition. IT usually happens to be one of them. Productive squirrel chasing, if you like. Just work on a different issue for a bit, learn something new, etc.

> Developers could also do these processes. And they probably do, often. But they usually have their heads so far up their asses that they don't see how inscrutable this onboarding process is even for very technical users.

I would argue that as the one developing a system (frontend or backend) you can not perform something like that. The reason being that you already know all the small little bits, tricks, and band-aids. The only way to get proper feedback, is by putting someone completely fresh in front of the system.

There was a reddit link posted under another thread, which had a very extensive list.

Since this has generated quite some interest, the reasons I dislike Laravel are:

- so. many. godobjects.

- I dislike ORMs. I could not put my finger on it, while using PHP frameworks, because they were omni-present; but after using Python, Go, and C#, I found it to be easier for me to just avoid the overhead of an ORM.

- Terrible structure. Sorting classes by type is something I have experienced to be generally less helpful than sorting by "topic" (not a native speaker, so this might not be the correct word for it. I recently heard it compared to collecting cars, then disassembling them and sorting by tires, steering wheels, seats, and so on)

- Too much magic™. I understand that many like this about it, but I found it harder to understand what exactly the program is doing.

It's not a lot, but after literally years of PHP and having these paper cuts almost weekly, I was at one point fed up. I first switched to CodeIgniter, which I found more pleasant, but still not even comparable to the comfort that cherry-picking components gets you (yes, you can by using composer, but most people I have spoken to discouraged that in favour of Laravel's built-in fun).

Laravel, the framework that made me quit PHP. Not sure the concept of "one framework doing everything" will resonate well with the wider Go community. I will keep an eye on it though.

The cookie law™ clearly lays out that technically required cookies can be set without explicit consent. Performance measurements are not a requirement though.

So if you are not using anything but essential cookies on your site, you don't need a banner.

Please, let me know which one!

At least for me a browser should be an interactive document viewer. Not CAD, not file conversion, not writing OS images to an SD card, not generating GCode. Ingesting HTML, CSS, and JS and turning it into an interactive view of that XML document nothing more, nothing less.

I would be very different if browsers were tools to view documents though. I am not saying that browsers don't have a purpose. I just question that browsers should answer the question about what their scope is with a loud "yes!"