Fun fact!

Xiaomi has a restriction where you're only allowed a bootloader unlock key one week after you've requested it. No, not a week after you've bought the phone. Not a week after you created an account and generated so much usage data that it would be stupid to doubt you're a genuine user.
No, you have to wait one week after installing their fucking desktop app and getting past some arbitrary point in the process.

Seriously, how much shit can this company pull with a straight face? At this point they're just sabotaging me, it's not even for any reason.

I decided to use Docker Compose on a tiny project that essentially consists of an API and a Caddy server that serves static files and proxies to the API, all of this running on an EC2 t1-nano. I made this admittedly odd choice because I wanted to learn Compose and simultaneously forego figuring out why the node-gyp bindings for sqlite3 refuse to build on EC2 even though it builds just fine on my machine.

I am storing secrets in .env which is committed into the private GH repo. Just now I came across a rant that described the same security practice and it sounded pretty bad from an outside perspective so I decided to research alternatives.

Apparently professional methods for storing secrets generally have higher system requirements than a t1-nano. I'm not looking for a complex service orchestration system, I'm not trying to run an enterprise on this poor little cloud-based raspberry pi. I just want to move my secrets out of the Git repo,

Any tips?

I wish all you frontend devs who use the keydown event to hack tab-order a very painful and very quick death.
Especially those who fail to ensure that TAB; Shift+TAB is always identity.

[!dev]
Today I learned that although the frequency unit Hertz is named after a person, the German name for heart - the most human example of a periodic system - is also Herz, pronounced the same.

Checking for root is maintaining a false façade of security. By the definition of root it can always be bypassed and we should be designing workflows to discourage logging in from an untrusted device unless you have 2fa.

Xiaomi's bootloader unlock procedure is So. Fucking. Tedious. I have no words... oh wait, I do. HIDING THE PERMISSION BEHIND A HUNDRED DEVICE-SIDE SWITCHES WON'T MAKE IT ANY SAFER, IT WILL ONLY MAKE MODDERS ANGRY. Why do you need a third switch besides OEM unlock and USB debugging anyway? If I toggled OEM unlock it's obvious what I'm trying to do and every other option should change to comply with that intent. Don't roll your own Android if you know fuckall about UX.

After using Linux every day for 3 years today I learned that listing directories requires the execute permission.

In a misdirected attempt to solve my problems I also learned the basic concepts of SELinux before realising that SELinux is disabled on the host and not present on the guest.

How is it that in the age of 98%+ reliable contraception incest is more stigmatized than a relationship between an authority figure and their subordinate? sex=children hasn't been the case for decades now.

It's probably no news that I love Typescript's versatile and powerful generics. Today I found what is probably the most brilliant use of these tools to solve a real problem. This package exports one generic type which takes one generic argument, reads it like a JSON schema and returns the Typescript type for it:

https://github.com/YuJianrong/...

How the fuck does TypeScript still not have service worker support? Seriously, it's just a typings file. People have written that typings file. They would just have to include it in the lib collection shipped with the compiler. Yeah, it would have DOM calls intermixed with the SW api, but frankly, having the typings for a set of calls you can't use is infinitely better than missing them for a set of calls you can.
The relevant issue is 5 years old btw.

"Failing upwards" is not a thing, you're just denying the damage you caused and therefore lying by implication.

I just released my first NPM package that is actually functional and used in a private project (https://npmjs.com/package/@lbfalvy/...) and I have to say, the quality of debug tooling for Node is abysmal. I spent 4 hours just on Webpack's "Field browser doesn't contain a valid alias configuration" error which simply means "package not found", and then getting Rollup to output a working compiled javascript _and_ a d.ts was its own day-long ordeal.

Tools are made for various audiences. Git is the de-facto standard for version management, so it can be complicated because people will still learn it (they more or less have to). Editors aren't as standard and they are to be used from the minute you start learning, so they have to at least be usable without a course or a handbook. I prefer the first type of tool because to use something really good I don't mind reading a book. Programming languages can fall in either category; Python was meant to be used by laics and is therefore very simple, sacrificing a lot for the sake of simplicity. Rust isn't meant to be used by anyone who isn't trained, and it comes with a great book that explains all the most important gotchas. Haskell doesn't have an official book AFAIK, but it has the best wiki I've ever seen in a programming language.

Thread-based asynchronity is the best because you can run operations in parallel that weren't designed to run in parallel.
Thread-based asynchronity is the worst because you can run operations in parallel that weren't designed to run in parallel.

I love Typescript's challenges. Today I had to make a generic interface that replaces every property in its parameter with either itself, a promise of itself or a different property keyed `obtain${key}` which is a function returning either the value or a promise of it. Not a very difficult challenge, but it was very satisfying to solve.
If anyone has the patience to attempt it I'm very curious what more experienced type theorists than myself come up with.

I've been working with Node and Typescript for a while now, and I wrote a wide array of very general utility functions. Examples include:
- Array.filter but you also get the residue array, it can also leave holes in both arrays if you want to join them later
- Array zipping and unzipping to and from tuples (especially valuable when you're manipulating the prop set with Object.entries() in a HOC
- Array maximum selection, with an optional mapper
- Cancelable promises, lazy promises, a promise that resolves when a given function on an object is called (excellent for DOM events), a timeout promise.
- A typed event with both immediate and microtask listeners depending on whether you need state guarantees (this idea I took from a Github gist and upgraded it)

I want to put them on NPM so I don't have to write them and their tests again, and so that if I ever think of an improvement it's easier to propagate it. Do you think I should release them as tiny individual packages which would be nice from a versioning standpoint, or should I make them into a compilation which would be a lot less work for me (and therefore would probably result in better documentation and more tests)?

One of the weirdest aspects of Docker for me is cross-compiling program installations. One would think that something as complex as a container with several programs that each make unknown decisions based on the environment as part of the installation process can't be cross-compiled.

After using Linux every day for 3 years, today I learned that the first parameter to ln is relative to the second one and not to the current location.

Anybody got any idea WTF is going on?

Has anyone here ever implemented OAuth2.0 for WebRTC? I am reading rfc7635 and its references, but they refer to functions they don't define properly and rely on cryptography jargon by eg. calling values by different names, so I'd appreciate a reference implementation of the function for building tokens to clear up the confusion.

rfc7635 on STUN extension for third-party authentication:
https://datatracker.ietf.org/doc/...

Fucking UI designers finally broke Firefox. Border-radius infects everything.

Containers, specifically Docker and Compose. It's a beautiful model and it solves a ton of real problems, but the list of unforeseen footguns never ends.

It never ceases to amaze me just how big 64 bit memory space is. It's so unrealistically big that on contemporary processors you can't address the middle and the size of that dead spot (the number of high bits that must be the same in a valid address) is barely worth mentioning.

I want to be able to look at a program and immediately know whether it halts. Partly because that would be proof that I cannot be a very elaborate computer program, and partly because it could be used to answer any yes/no question that I understand well enough to write a program for.

How must it feel to build pagination for the partner list in a cookie consent popup? Did the dev realize that they and their company are the primary reason for the GDPR? That they are the ultimate bad guys of online privacy, even worse than accumulators like Google who process their data in-house?

Lessions I learned so far from my first big node/npm project with tons of users:
1) If you didn't build something for a while, expect 3 hours of resolving version conflicts for every two weeks since the last build.
2) Even if the tests pass, run the containers on your own machine and make sure that the app doesn't randomly crash before deploying
3) Even if the app seemed to work on your own machine, run the tests again in an environment mimicking prod at most 15 minutes before replacing the running containers.
4) Even if all else indicates that the app will work, only ever deploy if you expect to be available within the 4 hours following a deployment.
5) Don't use shrinkwrap for anything other than locking every version down completely. A partial shrinkwrap will produce bugs that are dependent on the exact hour you built the app _and_ the shrinkwrap file, and therefore no one will ever have seen them other than you.
6) Avoid gyp, and generally try not to interface too much with anything that doesn't run on node. If parts of your solution use very different toolchains, your problems will be approximately proportional to the amount of code. And you'd be surprised just how much code you're running. (otherwise it's more logarithmic because the more code the less likely a new assumption is unique)
7) Do not update webpack or its plugins or anything they might call unless you absolutely need to
8) Containers are cool but the alpine ones are pretty much useless if you have even just one gyp module.
9) There's always another cache. To save yourself a lot of pain, include the build time in every file or its name that the browser can download, and compare these to a fresh build while debugging to assert that the bug is still present in the code you're reading
+1) Although it may look like it, SQLite is far from a simple solution because the code and the bindings aren't maintained. In fact, it'll probably be more time consuming than using a proper database.

I have an assignment due in 42h and I didn't even start, so probably soon.

MySQL has no outer join. Why isn't this fact all over the internet? Why does EVERY FUCKING TUTORIAL list outer join as if it's just as standard as left join?

Probably a mathematician. I would be a very different person though, because a key element to my current lifestyle is that I never have to use my mathematical insight to the fullest and therefore I can work despite hangovers from nearly any substances. If I had to be sober to get anything done I'd need a level of self control which is very far from me at the moment.

Guess who just spent the entire day before launch debugging why compose doesn't work on an ec2 instance where I DIDN"T INSTALL FUCKING DOCKER

I guess this is the key difference between me and seniors. Seniors know where to look where shit breaks because they have been breaking it for at least 5 years.