I Made This Site

I have lost interest in the Kagi search engine. I was very positive about it earlier, and I expressed my enthusiasm for it in my post called Giving My Experience of the Web a Makeover.

However, I have become disillusioned with their ongoing development. If you take a look at Kagi’s changelog blog, you’ll notice a strong focus on their LLMs. The blog post by Lori, titled Why I Lost Faith in Kagi, explains this matter further.

As an alternative, I am currently using DuckDuckGo, which I can’t say I enjoy all that much. But it is the lesser of several evils.

I have also moved my blog from uberspace. The reason was that I could not work without root privileges¹ or an up-to-date version of glibc².

Another service I said goodbye to was feedbin.com. Feedbin is a good service with a solid track record. However, if you’re not in the Apple ecosystem, you’ll have a second-rate experience. I am not part of that ecosystem, so after enjoying a year of using Feedbin, I replaced it with a self-hosted Miniflux and various third-party clients. I still recommend Feedbin to anyone who cannot (or would prefer not to) host their own Miniflux or who is in the Apple ecosystem. Feedbin is a really solid choice.

May I remind you that the XZ incident ¹ was discovered because it was open-source (FOSS) by an open-source contributor employed at Microsoft, while the CrowdStrike ², a Microsoft Windows’ bug, was discovered when millions of people woke up to a fucking BSOD? It is as if there is something about FLOSS that prevents this kind of fuckup.

I hate this stupid doing the right thing ideological bullshit that superhero movies are pushing.

Oh, you have a trolley problem? The trolley will just suddenly fly, or a third track will just appear out of fucking thin air!

Just fucking grow up and take responsibility for the consequences of your actions. Will you?

Ever since this morning, I have been bothered by the thought: gRPC added nothing but endless overhead to our product. Using it was an absolute mistake.

The greatest pitfall comes from the fact that the generated libraries are almost always useless directly, so you would need to define two different mappers, one from the Protocol Buffer-generated struct and one to Protocol Buffer-generated struct, manually. That mapping also takes away any performance, or ergonomic benefits gRPC may have had.

If you need streaming, gRPC is very good. But I would only use it in those specific circumstances, and every other endpoint would be JSON and HTTP ¹, and message brokers ².

And the compiler is also weird, the tooling is unsatisfactory.

The promised language agnosticism doesn’t pay off in small teams, since the generated library is usually so massive that reading it would take more time than just messaging your colleagues and asking for the fields in the JSON request body. In retrospect, we had much less trouble with end-points that did not incorporate gRPC.

When I was growing up, I viewed adults aversion to the new thing as a result of laziness.

Then I grew up. And I am noticing that many of the problems we are facing on a daily-basis, have shitty new solutions. When I look into before my time, I often find out there is a well tested, mature, and efficient solution, with its only fault being "not as shiny".

I become less and less contempt with what I get with "new" stuff. The old stuff is also new to me. But they are not new to the world.

I think there is conflict with people that confuse simplicity of a programming language with simplicity of writing, reading and maintaining a program written in a language.

Iterators increase the complexity of the language, but at least for me, decrease the complexity and extensibility of my codes significantly.

Honestly, the primary challenge I encountered with complex codebases originated from adhering to SOLID principles. Surprisingly, they appeared to turn the straightforward task of making any changes into a Herculean feat. Introducing numerous cumbersome abstractions also took a toll on performance.

Talk about actual premature optimizations!

I much prefer something like CUPID principles. More information on CUPID

I’m entertaining with the idea of making a personal webserver that uses git instead of a database. Yet i don’t have any idea how well such a thing would work. More importantly, I’m not sure about the API. Perhaps instead of using the standard REST, I could use Telegram or Matrix instead of creating a whole front end.

For Rust developers, the passion stems from a combination of 10% performance, safety, and tooling. The remaining 90% is the bliss of holidays free from on-call disruptions.

Honestly, I cannot say that diversity quotas are radical feminism; or in any terms extreme. Especially since they are implemented in societies that have endured thousands of years of cultural, institutional, and governmental oppression of women and minorities, which, we have yet to witness significant progress in achieving true equality for these oppressed groups.

Equal opportunity does not entail placing the food on top of the trees and then asserting that the whale just didn’t take it while the chimp did.

The problems surrounding Python programs on NixOS seem never-ending. I often have to refrain from installing most Python programs. On each update, another one of them breaks during installation – either their tests don’t pass, or their dependencies fail in some way.

And to be honest, I give the benefit of the doubt to NixOS, seeing its result with other languages, and knowing what I know about pip.

The true test of 10x developer is that you put two of them together, each debugging each others code, then you if they kept their 10x status, they are the true 10x developer. My guess would be that their population will reduce to less than that of unicorns’.

Please think twice before saying, usage restriction is good because you might want to prevent someone from using your tool for war, crime, etc. Like, you know that a poorly enforced license won’t deter a person in that situation from using your software, right?

There are probably better arguments for including usage restrictions in a software license; this one is a terrible one.

I find the situation around GitHub centralization distressing. And this extreme relience on GitHub is worrying. Maybe in time things change. But the moment I find a job and thus don’t need to keep my repos on GitHub anymore, I would like to move to a more federated forge.

Codeberg seems like the closest option. I will just simply mirror my commits to GitHub for the time being, slowly retiring them when I’m sure that codeberg remotes have the necessary configurations and flows that are needed. I don’t think i can retire my account though.

Every place I worked or want to work, are using GitHub. I cannot but worry about the same amount of enshitification that twitter and reddit has taken, to also come for GitHub.

It is very illuminating to see that using older style technologies, may lead to better experience. This just goes to show that many of the features and complexity and progress are not for people, but for profit of a few. That, of course, is a wild speculation of the highest order.

There is a retired burned out offended wild life photographer out there responsible for the O’Reilly’s book covers, after they were told “Your a photographer, that’s the same thing as graphic designer, give us 500 book covers, here is $1.”

I think when you are proposing a fast prototyping phase in programming, you should he able to answer these questions:

1. What don’t we know that we hope to find out with this prototype?
2. Why is this the best approach for finding the answer to that question.
3. When is the prototype going to be deleted?

If you cannot answer to these questions, what you are proposing is not a prototype, it is prototype quality end product. A knock off, if you will. A bad practice distilled.

I think the best way to characterize Rust’s productivity, is to put it on a quality axis. If you want low quality code (prototyping, etc) Rust is much less productive than the alternative. For medium level of quality, Rust is similar to others. For high quality code, Rust is much more productive than any alternatives. Quality is intentionally vague, to encapsulate performance, leanness, documentation, and security.

While the skills learned in Rust, like working with the borrow checker, may seem limited to Rust itself, the claim of their intransferability is somewhat overstated. Understanding the borrow checker is specific to languages using it, but the approaches it encourages are typically advanced and valued by experienced engineers. And often, it is evidenced by the patterns that are simplest to implement. The obvious exception to that is unwrap() and expect(). Even though the ? operator is an step towards simplifying that process, it is undeniable that the hassel of creating and managing errors is not simpler than the extra 8 characters introduced by the .unwrap()

Dynamic linking for the reason of security is the wrong solution, only propagating the problem of language and application developers to the downstream package distrobuters.

It is basically saying, yeah, I wrote this package with this language and dependencies, but you will be the one paying for my choice of technology.

Of course, down stream people also shouldn’t have accommodated these softwares. Except they did and now, there are multitudes of ecosystems operating this way.

I absolutely hate Jira. It is when you spend hours of valuable time, prioritizing tasks that take less time doing than setting them on Jira.

ADHD is not real. It is just unmotivated kids needing more structure. – Some lady today

Therefore:

Cancer is not real. It is just overly horny cells needing to chill the fuck down. – Probably the same lady, assuming no double standards

There is a blog post missing in the Rust sphere: How to not obssess over performance gain and improve changeability of Rust applications.

In other words, imagin that you want move a function used in one file to another. How would you do that in under ten minutes?