> Above a certain complexity, there is basically no 100% open-source hardware out there.
>
> Like none of the Pinephone, Librem, Framework laptops are "open-source" to the bone.
As an aside, GNU Librephone aims to rectify that by reverse-engineering those blobs and develop their own firmware for baseband chips etc. But I am carefully optimistic about the success since it is a relatively new project and quite a moonshot, even though I would personally stand first in line to buy one if it would materialize.
One of the points made in that paper is that you can't even trust the compiler, even if you write the code yourself. I think this is one of the stronger points as it shows you it is unfeasible to require everybody to audit all source code before running it. Be pragmatic, know your threat model, decide who you trust and move on with more important things in your life.
Additionally, a lot of jungle music were produced on Amiga using the same tracker software as many demosceners (OctaMED, ProTracker, etc). Makes me curious of how many junglists were also active sceners :-)
> Since there are many questions about the way the TIOBE index is assembled, a special page is devoted to its definition. Basically the calculation comes down to counting hits for the search query
>
> +"<language> programming"
I don't think the popularity of a programming language could be measured by how many hits it has on search engines. For example, it may well be that 50% of those hits are forum posts from people being frustrated because the language sucks. In addition, the fact that a language is in use in a lot of existing systems says little about when that code were written, and which options were available at that time.
While I appreciate the flashbacks you just gave me, I don't think the enshittifaction of GUI:s is orthogonal to the evolution in not having to deal with hardware issues any more.
Even approved and trusted admins can be a liability (disgruntled employee, social engineering). Like OP said, mandatory access control (MAC) implementations like SELinux can be used to even further restrict what an administrator (or process running with admin privileges) is allowed to do.
> Interesting, I might need to do some reading,
> Does macOS have any form of MAC yet, or do they just rely on sandboxing?
Kind of. There is a set of permissions an application can request in order to access protected services and areas of the filesystem, but maybe that's what you meant with sandboxing?
> No, you create one account. The root account doesn't have to be created. It's automatically there, built into the system. On Windows, you have to explicitly create two separate accounts, one with Administrator privileges and one without.
Correct, but you're missing the point. There's practically no difference between Linux and Windows when you need to escalate privileges, except having to enter credentials for another (privileged) user than your current (unprivileged) user. The security boundary is there and the user experience is basically the same. Everything else is just nitpicking.
This could probably be fixed by tracking whether the mousedown event was started inside or outside the dialog, and only close the dialog if the mousedown started outside it.
SQL in itself is not the weak point in this case (or any of the other cases of a successful SQLi attack). The problem is the treatment of user-controllable input data and using that data as part of a SQL query without properly sanitising/escaping special characters first.
As an aside, GNU Librephone aims to rectify that by reverse-engineering those blobs and develop their own firmware for baseband chips etc. But I am carefully optimistic about the success since it is a relatively new project and quite a moonshot, even though I would personally stand first in line to buy one if it would materialize.