I've known that users are stupid and should keep that in mind when designing a website. But holy shit that's ridiculous!!!

He said that "when something is not on the middle of the screen flashing then we are not seeing it!"

How the fuck would it look like if I will place the fucking menubar on the middle of the screen with flashing red and blue colors for you dumbass to see?? If you are that incompetent to look on the top (not to mention it's fixed) of the layout where 99% of main menus are placed then you shouldn't use a computer in the first place.

Or maybe my design is bad I am getting uncertain.

I think that two criterias are important:

- don't block my productivity
- author should have his userbase in mind

1) Some simple anti examples:

- Windows popping up a big fat blue screen screaming for updates. Like... Go suck some donkey balls you stupid shit that's totally irritating you arsehole.
- Graphical tools having no UI concept. E.g. Adobes PDF reader - which was minimalized in it's UI and it became just unbearable pain. When the concept is to castrate the user in it's abilities and call the concept intuitive, it's not a concept it's shit. Other examples are e.g. GEdit - which was severely massacred in Gnome 3 if I remember correctly (never touched Gnome ever again. I was really put off because their concept just alienated me)
- Having an UI concept but no consistency. Eg. looking at a lot of large web apps, especially Atlassian software.
Too many times I had e.g. a simple HTML form. In menu 1 you could use enter. In menu 2 Enter does not work. in another menu Enter works, but it doesn't submit the form it instead submits the whole page... Which can end in clusterfuck.
Yaaayyyy.
- Keyboard usage not possible at all.
It becomes a sad majority.... Pressing tab, not switching between form fields. Looking for keyboard shortcuts, not finding any. Yes, it's a graphical interface. But the charm of 16 bit interfaces (YES. I'm praising DOS interfaces) was that once you memorized the necessary keyboard strokes... You were faster than lightning. Ever seen e.g. a good pharmacist, receptionist or warehouse clerk... most of the software is completely based on short keyboard strokes, eg. for a receptionist at a doctor for the ICD code / pharmaceutical search et cetera.
- don't poop rainbows. I mean it.
I love colors. When they make sense. but when I use some software, e.g. netdata, I think an epilepsy warning would be fair. Too. Many. Neon. Colors. -.-

2) It should be obvious... But it's become a burden.

E.g. when asked for a release as there were some fixes... Don't point to the install from master script. Maybe you like it rolling release style - but don't enforce it please. It's hard to use SHA256 hash as a version number and shortening the hash might be a bad idea.

Don't start experiments. If it works - don't throw everything over board without good reasons. E.g. my previous example of GEdit: Turning a valuable text editor into a minimalistic unusable piece of crap and calling it a genius idea for the sake of simplicity... Nope. You murdered a successful product.
Gnome 3 felt like a complete experiment and judging from the last years of changes in the news it was an rather unsuccessful one... As they gave up quite a few of their ideas.

When doing design stuff or other big changes make it a community event or at least put a poll up on the github page. Even If it's an small user base, listen to them instead of just randomly fucking them over.
--
One of my favorite projects is a texteditor called Kate from KDE.

It has a ton of features, could even be seen as a small IDE. The reason I love it because one of the original authors still cares for his creation and ... It never failed me. I use Kate since over 20 years now I think... Oo

Another example is the git cli. It's simple and yet powerful. git add -i is e.g. a thing I really really really love. (memorize the keyboard shortcuts and you'll chunk up large commits faster than flash.

Curl. Yes. The (http) download tool. It's author still cares. It's another tool I use since 20 years. And it has given me a deep insight of how HTTP worked, new protocols and again. It never failed me. It is such a fucking versatile thing. TLS debugging / performance measurements / what the frigging fuck is going on here. Take curl. Find it out.

My worst enemies....

Git based clients. I just hate them. Mostly because they fill the niche of explaining things (good) but completely nuke the learning of git (very bad). You can do any git action without understanding what you do and even worse... They encourage bad workflows.
I've seen great devs completely fucking up git and crying because they had really no fucking clue what git actually does. The UI lead them on the worst and darkest path imaginable. :(

Atlassian products. On the one hand... They're not total shit. But the mass of bugs and the complete lack of interest of Atlassian towards their customers and the cloud movement.... Ouch. Just ouch.

I had to deal with a lot of completely borked up instances and could trace it back to a bug tracking entry / atlassian, 2 - 3 years old with the comment: vote for this, we'll work on a Bugfix. Go fuck yourself you pisswads.

Microsoft Office / Windows. Oh boy.
I could fill entire days of monologues.
It's bad, hmkay?

XEN.
This is not bad.
This is more like kill it before it lays eggs.
The deeper I got into XEN, the more I wanted to lay in a bathtub full of acid to scrub of the feelings of shame... How could anyone call this good?!?????

Avoid ACPICA if at all possible. It's one garbage tier cluster fuck of bad design, horrible documentation and downright misleading and wrong code

It's meant to consist of an ASL compiler, disassembler, debugger, dumper, various user space utitilies and a kernel resident OSPM implementation *if* you can figure out what belongs to what. Even just compiling this pile of trash is a mystery in itself. Think you need the source files in source/common? EEEEH, wrong. Well, at least partially since most of them seem to be for the user space stuff..? Other ones *are* needed on the other hand. At least the disassembler and/or debugger and/or dumper components seem to reference them. Not that I could figure out how to compile those anyways. The real path to your goal seems to be to ignore a seemingly arbitrary subset of source and header files until your linker stops complaining

There's also a bunch of configuration defines, some of which *you* define, some defined *for* you, based on again others. Of course most of them do stupid shit. Enabling the debugger automatically enables debug logging. Enabling the disassembler force enables debug allocation tracking... What?

The code itself isn't of much help either. Looking in "os_specific/service_layers" you find what looks to be reference implementations of acpica functions in certain os' like windows and unix. Of course I had a look because AcpiOsReadMemory is supposed to read physical memory and I don't know how I would even implement that. But hey, osunixxf.c (xf for interface... of course) should tell me. I'll let you see for yourself in the attached image. Apparently it does fuck all and just returns AE_OK. No error, no logging, no nothing. Just ok. As you can imagine, AcpiOsWriteMemory doesn't do much more either.
...okay so maybe physical memory accesses aren't actually used and these functions are some sort of relic from past times? Nope! They are absolutely necessary for doing low level device interaction. WTF. So finally I went to the linux source and checked how *they* implemented them, and just as I thought, these functions are anything but no-ops...
...So for what fucking reason do these stupid interface implementations even exist but to purposefully mislead you?? They aren't used for fucking anything! As far as I know Windows doesn't even *use* ACPICA and Linux have their own fork with working implementations... They just sit there, just to tell you how to NOT do it

So that's some of my thoughts about ACPICA. Note that I haven't even used it as a library yet, I just got it to compile and link and it already fucked with me this much.
There's also so much more I didn't mention like that you *have* to modify the acpica source in order to get your own platform header working (else #error) eventhough the docs explicitely instruct you not too but you get the point

Don't use ACPICA if you don't have to. Save your sanity for something that's worth it

Disclaimer: This is all theoretical. Neither me nor my friend (with whom I discussed this) are stupid enough to even try to pursue this, but as an idea, i believe it might generate cool/new ideas/ways for handling secure communications across social groups.

Let's do some role play. Let's design a delivery app for drug dealers, think Seamless or Uber Eats, but for drugs. Not for big deliveries, like kilograms of coke, but smaller stuff. Maybe a few grams of it or something. The clients could rate dealers, and vide-versa. This would build a level of trust within the system. There would be no names, just anonymous reviews, ratings, and prices. Only the info you'd need to know.

The biggest (only?) problem we found (besides legality) was that, how would you prove that you're a client and not a snitch (or cop). This would have to somehow be handled both on signup, as well as when ordering (let's imagine that all who are clients are pure and won't ever snitch).

One of the ways we found to combat this was to have the app invite-only. This would, in theory, do away with the problem of having snitches signing up. However, what if the phone got stolen/breached by a snitch, and they also got full access to the account. One way we thought we could combat this would be with a "dispose number" or something similar. Basically, you call a number, or send a text, or message a Signal bot etc, which would lead to the account's instant termination, no traces of that user left. Hence, a dispose number.

The flow of the app would be as follows:
A client wants some amount of heroin. He opens the app, searches for a dealer, sends the him the desired amount, and in return gets back a price from the dealer. If both parties agree on the amount and price, the deal would start.

The app would then select a random time (taken from the client's selected timeframe and the dealer's "open" time) and a location (within a certain radius of both them, somewhere in between them both for convenience). If both of them accept the time and place, they'll have to meet up at said time and place.

The actual delivery could also be done using two dead drops - the client drops the money at one of them, the dealer drops the goods at the other one. Yes, this might be subject to abuse, but it wouldn't be that bad. I doubt that clients would make huge orders to unknown/badly rated dealers, as well as dealers accepting offers from badly rated clients. My idea is that they would start small, just so if they do lose their money/goods, the actual loss wouldn't be as big for them, but for the other party, having bad ratings would mean less clients willing to buy or dealers willing to sell.

A third way would be to use crypto, but the reason I left this as the last one is because it's not that wide-spread yet, at least not in local drug dealing. With this method, the client would initiate the order, the crypto would be sent to either the dealer or an escrow account, the dealer would then drop the goods at a random place and let the client know where to go to get them. After the client has gotten the goods, they could both review/rate the quality as well as the overall experience with that dealer, which would either make or break the dealer's upcoming deals. This would be pretty much like other DNM's, but on a local scale, making deliveries faster.

So far, this would seem like something that would work. Are there any ideas that might improve this? Anything that might make things more secure/anonymous?

My reason for this post is to spark a conversation about security and anonymity, not to endorse drugs or other illegal stuff.

Cheers!

PS. Really loving the new PC design of devRant