Do not, I repeat - do not ever develop against ffmpeg!!!

Ffmpeg "development team" is hell bent on breaking compatibility with old code. Whenever their superior intelligence detects what they consider broken code, even if it works perfectly well for applications, they will

1. Rename the method
2. Remove the old one

Posted by: LinuxLies at 02:18 PM | No Comments | Add Comment
Post contains 172 words, total size 1 kb.

What's wrong with you, Linux developers?

You are, for the most part, university students or graduates, but you write code which is worse than troll's snot. I mean, 30-40% CPU load when copying a file to another machine across the network. Are you for real? On a Windows machine with an antivirus it only takes around 10% CPU to copy the same file. And mind you, that Windows host runs on a 2 core CPU, while the Linux host has 4 cores, so its figure has to be cut in half for an honest comparison. Windows 7 outperforms Linux Fedora 26 by 6-8x times. These are physical cores, so do not even dare to bring up the topic of HT.

What's wrong with you? Ever heard of DMA? Or are you still using CPU to read, write and move around byte arrays? Or maybe you are copying byte by byte because you never heard of MMX, SSL and 3DNow? FFS, this is becoming absurd, if in 2018 I need 30-40% of a 4-core 3 GHz CPU to send a file across a 1 Gbit network at 60-80 MB/s sustained rate.

It suddenly dawned on me during this experiment that I am reading from an encrypted partition in Linux, so I stopped and attached another hard disk, formatted it to ext4 without encryption, created another test file on it and re-run the test. This is where I got 30-40%, as when it was from an encrypted partition I was getting 40-60% CPU load.

Linux is a fucking joke if in 2018 one file transfer can choke almost 2 cores out of 4 by just copying a file. This is so bad, that I will not even rant about how file transfers still choke Linux by allocating all free RAM to cache and never freeing it if other apps need more RAM. This travesty is going on for 10+ years and I blogged about this long time ago. Not going anymore. The funnyiest part is that copying a file onto a Windows CIFS share never succeeds: there is always an error at the end. Can you, super-intelligent knowing it all Linux developers, who close all my bug reports without resolution and without anyone even looking into them several years later due to "end of life", get anything right?

Posted by: LinuxLies at 10:40 AM | No Comments | Add Comment
Post contains 392 words, total size 2 kb.

RedHat is outodoing itself in trolling - the new firewall UI for Mate

This is a piece of software which is kind of important to make intuitive, you would think. But RedHat knows better. They designed the firewall managing applet so that I, an IT professional with over 20 years (yeah, this is my 20th anniversary of using Linux) experience, cannot understand what the hell I am looking at.

Anyhow, what are these rules supposed to mean? We have a bunch of zones, including "block", "trusted", which sort of speak for themselves, but what is the meaning of the rest, such as "public" or "work" - are these allow rules, or block rules? And when do they activate? Not a word of help on that.

The reload menu item does nothing. You'd think it should act similarly to 'systemctl restart firewalld' but no, it does not do anything. Not a permission issue, as firewall UI authorizes as root when it opens.

Posted by: LinuxLies at 10:25 AM | No Comments | Add Comment
Post contains 174 words, total size 1 kb.