Spent an hour and a half debugging why binders are not working on my Asp.Net project to end up finding out that my controller was missing:
[Route("[controller]")]
attribute at the beginning

Life is wonderful :)

Just a short "dafuq?" about VS Code.

I have a MacBook Pro from last year, so it's a capable machine. And there I was today, sitting on the train, coding some Python in VS Code.

Suddenly it got all laggy. Like, one second behind my typing, dropping keystrokes, stuttery scrolling... the whole deal. The system itself was perfectly responsive and the activity manager showed the CPU at 30%. After a minute or so, it magically recovered and worked as if nothing ever happened.

What the actual fuck was VS Code doing? I mean, it's a fucking text editor. In 2019 this should be a bloody solved problem! There's absolutely no reason to use around 30% CPU in the first place, and use that much and still *lag*. Holy crap, and people ask with a straight face "what's wrong with reinventing everything based on web technologies?" Fuck everything Electron-based. Make it ElectrOFF already.

*takes deep breath*

So, editor suggestions are welcome. I used Sublime Text 3 before VS Code, I'll likely return to that.

Bullshittery continues. This time around, absolutely innocent, clamav is root cause. For once not incompetent idiot, but piece of software. IDK if that makes me happy or upset.

So our email server that I configured and took care of died. RIP. Damn, better put it back together ASAP. So Im under pressure, while still pissed at everything that I ranted before (actually my last 2 rants were throttled, and in total all of that happened past 60 minutes but devrant rate limiting) I start auditing logs. You imagine, we kindda need it NOW, and it's second time last month clamav is pulling stunts and MTA refuses (properly) to work without antivirus. So pressurized, I look at logs, what the fuck went wrong.

clamav deamonize() failed - cannot allocate memory

Hmm. Intresting, but sounds like bullshit. I know server is quite micro becouse they wanted to save on costs as much as possible, but it has well over half a gig free ram just before it crashes (like 800MB) with that message. Is it allocating almost gig in one call or what? Looked carefully at trusty htop while it was starting, and indeed, suddenly it just dies with quite a bit of ram free, almost as much as it weights already. And I remember booting it up when I was configuring it, and it had fair bit of headroom.

Google, help me friend... Okay, great, so apparently at some point clamav loads virus DB into ram (dafuq?), and than forks, which causes spike of 2x the ram usage, and than immidietely frees it up.

Great, that sounds like great design decision... At least I know, I can just slap on SWAP file, restart it and call it a day.

It worked, swap file is almost empty (used 15megs, 900 megs free ram, whatever).

That leaves me wandering, who figured out to load DB to ram? That means pretty much that clamav will eat a little bit more ram each vir db update, and that milisecond "double ram" spike will confuse innocent people who just wanted to run clamav and it worked last *long period of time* and now crashes without warning without any changes to configuration.

Maybe there is logical explanation, I want to know it.