The collarbones, and the way the skin gets sucked in between.

In a vacuum, it was middling in all aspects and with some terrible technical and artistic issues, but it was okay. But it didn’t exist in a vacuum. It didn’t live up to the relative success of Inquisition, and was an unworthy successor of the Shepard trilogy.

Damn, I wonder why people are becoming averse to online accounts…

Inevitably there would be some incels who claim that speaking to women like normal human beings is an attempt by the matrix to emasculate men.

deleted by creator

Fuck me, if my choice is between five flavours of Javascript, I’d rather use PHP. I’m developing a QML application and having to work around that abomination that the clinically insane want to call “arrays” in Javascript makes me want to fucking die. There’s also a QList type implemented by QML. It doesn’t help. Array.isArray(qlist) returns false.

A year ago? People called it eight years ago with the Anthem disaster that Dragon Age 4 would be the studio’s last chance. BioWare was already dead, this is just the merciful last bullet.

Honestly, this is one where I can’t put all of the blame on EA. Bioware has been in a decline since My Face Is Tired, and a complete freefall since Anthem. Veilguard was their last chance and they blew it. The Bioware we’re nostallgic for (Baldur’s Gate, KOTOR, DA:O) hasn’t existed for years, and “Bioware magic” turned out to be a fart in the wind.

(edit) And let’s be real, Anthem wasn’t EA’s doing. Most of the game’s failures were Bioware’s fault, mostly incompetent management. https://kotaku.com/how-biowares-anthem-went-wrong-1833731964

Yes… but no. You probably saw a rendering error.

The private keys in question were only eight bits in length (decimal values 0 to 255). A proper key for the specific encryption should have been 384 bits, or about 116 decimal digits. If a string format function expects a 384 bit number, but only receives 8, it might fill out the missing places with zeroes.

Four… Fucking… Pixels?

The working hypothesis is that this was some sort of debug or test key that was never meant to be used in production, being used in production.

The encryption that SSL/TLS provides (that puts the “secure” in HTTPS) uses a public–private key pair and a specific mathematical function. Generating the key pair requires a cryptographically secure random number that is impossible or very difficult to guess, which must be kept secret at all times. If this random number is leaked or guessed by a malicious actor, the private key can be reconstructed and used to impersonate a website or break the encryption.

The security of the encryption comes from the fact that the function is easy to calculate one way, but difficult to calculate its inverse. To demonstrate: multiplying the prime numbers 88117 and 44543 is easy, but the inverse, factorizing the semiprime 3924995531, is extremely lengthy in comparison.

One of the factors that determine the security of the key is the size of the number, i.e. the number of digits. In this case, a proper key should’ve had a length of 384 bits (or 116 decimal digits). In reality, the keys that eMudhra used had eight bits, which can only represent 256 possible values, and can be easily guessed even by brute force. The specific private keys were the numbers 4, 56, 66, 115, 155, 156, 230, and 237.

Currently having a very fun day at work.

Fortunately our own certificates are unaffected, but it’s the autumn break and most of the staff are absent and incommunicado.

I have no experience with MAUI, I only heard that it was cross-platform.

Then what other toolkit has stable .NET bindings on both Linux and Windows? This might become relevant to me professionally in the near future.

Adding dependencies, adding complexity, adding points of failure… not to mention that the first sentence in the readme literally says it’s an experimental project. Not something that a production software should ever be built upon.

“Quoting a vaguely applicable utterance from a famous person isn’t the slam dunk you think it is.” – rtxn

I used McDonald’s to make a cheeseburger in less than 30 minutes.

The cheemsborgir is based on the well-known hamburger, but with a slice of cheese added. I used the McD’s on the corner to cook the meat patty and deploy it into a takeout box. There were a few ingredients I’ve had to remove due to personal preference, but I almost found it easier to just ask the waiter to do it rather than pick them out while eating.

Except Mono implements the Windows-only .NET Framework, but PDN targets .NET 9. I have no idea how those two could be used at the same time for different parts of the app, what kinds of issues may arise from it, or if it can be done at all. Again, it sounds simple, but it never is.

compiling it for .NET on Linux

It always sounds so simple for the layperson. Just looking through the list of DLLs in the portable ZIP, PDN uses Windows Forms (System.Windows.Forms namespace), which, as far as I understand, isn’t included in the cross-platform releases of .NET. They’d have to rebuild the entire UI with .NET MAUI or some other cross-platform toolkit. Then there are lots of other bundled libraries that may or may not work in a .NET-on-Linux environment.

Releasing and then supporting a second platform is never as easy as just compiling the executable. Figuring out the quirks and differences of various systems, especially one as heterogenous as the Linux ecosystem, is a drain on resources that small development studios often can’t afford. Raiguard (hallowed be his name), one of the developers of Factorio, and the person who is single-handedly maintaining the Linux-native build, wrote a blog post about its challenges.