Ivory tower dwellers are incapable of appreciating real-world challenges

One of consequences of Internet age with the advent of extremely genius FOSS developers is that they exist in imaginary world where everyone eats from their hands and walks on tiptoes around them because they are so awesome.

Whenever someone tries to bring them down to Earth and explain how the striving for utmost sophistication by the former are not always appreciated by us, unwashed mere mortals, it angers those geniuses, and they lash out at us for that.

The only way to steer humankind's IT industry back to serving humankind instead of leeching its resources and providing precious little in return is that which I refer to as ANSI purge. Google 'Ansei purge' if you never heard of it. It is informative reading.

We need to purge 80% of con artists that pretend to be IT professionals, especially those who strive in the FOSS domain. Until their bones are washed white by rains, Earth's population will continue to suffer and pay for it, through their collective nose.

Posted by: LinuxLies at 03:57 PM | No Comments | Add Comment
Post contains 186 words, total size 1 kb.

Another Linux lie: we are not fucktards

Truth: you are.

A distribution like Debian that installs the ugly, putrid monstrosity of Gnome by default but does not install net-tools package that contains absolutely basic tools like netstat is loud and clear evidence that its maintainers are fucktards.

Posted by: LinuxLies at 01:15 PM | No Comments | Add Comment
Post contains 54 words, total size 1 kb.

C++ authors are just as misguided or crooked as majority of IT staff is

For several decades now, the team around C++ keeps itself busy with developing nested layers of crutches around the whining and moaning points that C++ developers keep raising due to their jobs being too hard. C++ team develops some poorly explained and scarsly documented std:: crap, developers try it, realize how prohibitively hard it is, whine, moan, and their whining and moaning reaches ears of the C++ team members who dwell in their ivory tower.

Having heard the perpetual whining and moaning, the C++ team writes more std:: crutches, to wrap their previous crap and to alleviate the suffering of the C++ developers. Since that happens practically every year, said developers have to unlearn their previous habits and learn new, poorly documented crap, and so the wheel of suffering keeps turning.

As all IT professionals except for a tiny handful of exceptionally bright (not genius!) stars, C++ developers are perfectly content with having to perpetually retrain themselves from scratch in order to barely stay up to date with the bleeding edge. They keep silent about it because it helps them stay afloat and leech hard-earned $$ from the rest of the industries. Spice must flow!

Instead of focusing on the significant: exception handling, C++ team keeps reinventing the wheel with crutches as spokes. Same old, same old.

Posted by: LinuxLies at 09:53 AM | No Comments | Add Comment
Post contains 245 words, total size 2 kb.

If you thought that Microsoft only impedes your development efforts, then you were wrong

Truth is, they actively, militantly sabotage you. MS symbol servers do not contain VC Redistributable C++ symbols. That means that when an uncatchable exception occurs within the bowels of VCRedist you are SOL as in royally fucked. MS knows about the problem. They lied about having fixed it. They ignored rebuttals. That makes them IT terrorists. We not only tolerate a terrorist organization amidst our ranks, we entrust it with our entire IT infrastructure by way of using its cloud and other services and allowing it to spy on 100% of our source code by way of leeching it through telemetry. Stupid is as stupid does.

Posted by: LinuxLies at 08:14 AM | No Comments | Add Comment
Post contains 134 words, total size 1 kb.

WPF XAML tooling in VS is appalling

Was it too expensive/difficult/demeaning for MS dev team to extend Intellisense to XAML? They did so partially. Why not go all the way and implement 100% of it? Did you rush releases? No one, I repeat: no one expects you to pump out a new version of Visual Studio, every 3 years. Take your time if you do not make it to the deadline. But do not roll out half-baked, half-assed solutions.

Posted by: LinuxLies at 09:05 AM | No Comments | Add Comment
Post contains 86 words, total size 1 kb.

Debounce, assholes!

Of late, Microsoft Corporation comes across as a bunch of unsupervised yahoos. They make bizarre decisions that should have never been allowed to be made.

Especially this is blatantly, glaringly obvious in the slippery architecture of the most recent versions of Visual Studio that is so slow that at times I can see 'Loading...' balloon when I have to wait for its IntelliSense suggestions to pop-up.

They are supposed to already be in memory because I have used them like 1000 times by then. But no, they are still loading. Why can't you, assholes, keep stuff in RAM? Does your religion forbid it?

Posted by: LinuxLies at 03:59 PM | No Comments | Add Comment
Post contains 107 words, total size 1 kb.

Can't find its ass with both hands

Your guess is right: it's about Microsoft.

So what are you up for? To scan or not to scan? That is the question!

Make up your fucking mind, once in a lifetime: to bother the user with your useless, meaningless, BS popups, or not to bother?

Posted by: LinuxLies at 01:05 PM | No Comments | Add Comment
Post contains 60 words, total size 1 kb.

Ideas welcome

When Microsoft pushes down an update to Windows 10 that totally kills the performance, and it imposes a 10-day limit on its rollback, they should be given a wake-up call.

Your ideas: how do we send a wake-up call to such monstrous global monopoly that:

1. Violates firewall rules that block its update servers.
2. Subverts C:\windows\system32\drivers\etc\hosts file that blocks its update servers.
3. Starts disabled update and BITS services.

We are expected to fear for our security and to install updates out fear, but the real virus, the real malware is Windows. Its behavior outlined above is viral, malicious.

Someone has to be held accountable for wasted resources and aggravation from our systems becoming slow as fuck after their updates.

As in heavy smack on the head or something. They need to feel the same pain that we do. Ideas?

Posted by: LinuxLies at 08:06 AM | No Comments | Add Comment
Post contains 142 words, total size 1 kb.

I just knew it! I knew it! Firefox past v. 100 something is fucked

The last version of Firefox that worked kind of all right was 100 something. I d/l v.120 and it freezes. In their perpetual, insatiable striving for utmost sophistication, that altruistic Mozilla foundation fucked up and broke something, and now we have freezes for several seconds that look and feel like crashes but without the window disappearing from screen.

Thank you kindly, assholes! A freezing browser was exactly what we needed.

Posted by: LinuxLies at 05:37 PM | No Comments | Add Comment
Post contains 98 words, total size 1 kb.

Another Linux lie: we are user-friendly

Truth: you are not.

Here is the best example of how linuxoids invent bullshit where none is needed: How to change lock screen background in MATE

One even went as far as to offer commands to install new background as an alternative. Dimwit.

But it does not occur to any of those genius degenerates that one may want NO picture whatsoever. No as in 'solid color'. In their perpetual striving for utmost sophistication, that simple alternative does not occur to them. They are excited and enthusiastic about circulating in the Linux world. Mere mortals' aspirations do not bother them.

So, what does a simpleton like me does? Delete the fucking background image. rm -rf, motherfucker! No sophisticated commands to run, no files to edit: none of their BS. Now, sue me!

Posted by: LinuxLies at 05:33 PM | No Comments | Add Comment
Post contains 143 words, total size 1 kb.

Another Linux lie: we follow standards. Or is it the same old one?

As recently as... yesterday I wrote about Linux distro developers playing leap-frog and outdoing themselves to be different. Today we continue our regular column.

File formats... In /etc everything must be uniform between distributions because... TADA! there is no reason to be different. But insatiable urge to boast makes them to invent differences where none are needed.

Let me ask you, genius degenerates, how do you write scripts that work with different distros? Your fucking diversity bloats them with nested conditionals. You waste our civilization's time, money, MWt of energy, and other resources. You squander them on your spinning wheels. And they you blabber about the environment. Liars you all.

Posted by: LinuxLies at 08:57 AM | No Comments | Add Comment
Post contains 136 words, total size 1 kb.

Another Linux lie: we follow standards

Truth: no, you do not.

Enter openSUSE or SLES, an oddball Linux that behaves more like FreeBSD. Try to run who in SUSE, and you will get the oh, so fashionable "partial dates" in the Since column. Example: Mar 25 12:00.

Now, good luck parsing that date! You will get gray hair and pull it out, in the process.

So much for standards that other Linuxae follow (yyyy-MM-dd hh:mm). Standards are for assholes, and SUSE does not want to be one, apparently.

Posted by: LinuxLies at 03:55 PM | No Comments | Add Comment
Post contains 94 words, total size 1 kb.

Why are you silent?

My solution that I currently work with, in VS 2022 builds for, let's say, 15 seconds. But for the first 3-4 minutes at the very least since I open that solution or any solution for that matter, VS fucks my brains with 100% CPU load on all cores. What is it doing then? It is kicking about my solution, with 100% CPU load, for a good 40 minutes now. WTF is it doing? Multiple rebuilds in the mean time have not helped it come to its sense. WTF is it doing? WTF are you doing, MS? Are you mining cryptocurrencies on our machines? Is that how Satya-the-Insatiable earns his riches?

And to add insult to injury, once it has pinned CPU for extended periods of time, allegedly to compile the solution in the background, it gets stuck on false-positive errors that it creates during the typing of code. Huh? You are supposed to clear them once the code is free of errors, isn't you, a multi-trillion global monopoly on everything? Not enough $$$ for you to do your job properly?

If the project builds 30x times quicker, then what is it doing? It wastes everybody's time. It wastes electric power that all of you are so paranoid about. But why are you silent?

Microsoft Corporation fucks all of you up but you remain silent. Silence of the sheep. That's what you deserve.

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

Another Linux lie: we have source control

Truth is, you kind of, sort of, do.

When you install git in Windows, you get that demented, half-assed editor/merge tool based on vim, from the 1980s. That absurd, diabolical, savage UI in which you have to memorize 2-3 letter commands for every action. I will help you stop that savage torture, by issuing a few commands.

First of all, download and install WinMerge. Once it is there, you can either add its installation directory to your system PATH variable or use full paths below.

Next, set it up in git (assuming that you are 64-bit, not ancient x86):

git config --global merge.tool winmerge
git config --replace --global mergetool.winmerge.cmd "\"C:\Program Files\WinMerge\WinMergeU.exe\"
git config --global mergetool.prompt false
git config --global mergetool.keepBackup false
git config mergetool.winmerge.trustExitCode true

The last 3 commands are technically optional but they will make your life much more enjoyable. They eliminate the following annoyances courtesy of genius degenerate Linus Torvalds:

1. Remove the prompt for the tool selection.
2. Disable .ORIG files
3. Remove the 'was the merge successful?' prompt.

Enjoy! And remember to spit on a genius degenerate today.

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

Microsoft drops the ball. Each time. Every time.

Yes, we have been saying it, ad nauseam, that Microsoft is hell-bent on redrawing icons and changing visual layouts (usually to the worse) in favor of fixing bugs or introducing valuable functionality. That has been proven beyond reasonable doubt.

One such glaring example is the total absence of refactoring in Visual Studio WPF XAML editor. It is a tedious process to create styles for control by extracting repeated attributes and moving them to styles. MS could have offered us a refactoring action for that but no, that is too much to ask. They had over 15 years for that but no soup for us.

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

No, Microsoft does not test their products

Or they are so spoiled, smug, and condescending that they do not give a fuck about bugs. That might explain why they prefer to spend their time on redrawing icons and other cosmetic crap.

Had they tested or cared for the quality of their products, the corruption of the dialogs in .NET 6 would have been noticed and fixed. After all, .NET 6 is 2 years old by now.

Did no one notice that the file name in a freshly opened dialog is 1/2 way outside of the text box? I can't believe that! If I notice it, then QA should have noticed it too. There was no QA.

Posted by: LinuxLies at 12:03 PM | No Comments | Add Comment
Post contains 123 words, total size 1 kb.

For the sake of fairness and balance

I sound very negative and angry, most of the time, and some might form impression that I do not like anything in IT industry. That is not true.

As far as WPF is concerned, it makes it very easy to change the GUI form controls layout. It is much easier to edit XAML to add another control than to fiddle with a WinForms form. This part is great. The rest is crap.

Even having said it, since every container/panel in WPF is essentially a <div>, most often controls end up in a grid, and inserting a row or column into a grid sucks, and the sound of sucking is deafening because all subsequent rows/columns have to be renumbered. Since XAML designer UI also sucks, we are SOL.

Posted by: LinuxLies at 04:10 PM | No Comments | Add Comment
Post contains 141 words, total size 1 kb.

Genius degenerates rule our world

Like, those developers of Visual Studio who put 'Collapse all descendants' on a popup menu in Solution Explorer but forget to put 'Expand all descendants'.

Thank you kindly, Microsoft, and personally Satya Nadella! Thank you for being the idiots that you are. I know that you do not test your products, so I suggest: try to expand a tree with hundreds of sub-levels and items. Oh, you do not want to? You want only us to suffer? A-ha!

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

Another Linux lie: we have database engines!

Yes, it's another lie. Truth is, you don't. You have miserable wannabe fidget-spinner projects that pretend to be database engines! Enter PostgreSQL:

My guess is that the "other providers" where this works is SqlClient with MARS (Multiple Active Result Sets), which is precisely this feature. Npgsql doesn't support MARS (and for good reason), the right solution here is either to materialize the list as suggested, or if it's too big for that, use two contexts (although that brings in its own problems). –
Shay Rojansky
Apr 6, 2020 at 21:40

Above, "we fucked up" is passed for "for good reason". You suck, dudes! Multiple active resultsets is a GREAT feature, a life savior in the fuzzy, mushy world of .NET with its lazy loading and async behavior. We developers absolutely need it, but you, Shay Shmojansky, force us to commit entire resultsets into collections in order to iterate them later and run other commands from their data. Boo hoo!

To give you an idea of how competent those genius degenerates are NOT, I'll show you this screenshot:

Those fucktards used a VARCHAR(3) column, to store YES/NO for an identity! Genius is as genius does.

Posted by: LinuxLies at 09:29 AM | No Comments | Add Comment
Post contains 208 words, total size 1 kb.

The loudest and most glaring condemnation of async is Visual Studio

Async breaks up methods into several, and no amount of < tt>ConfigureAwait(false) can fix that. It's N times more stack allocation/deallocation, N times more overhead, N times more complexity. As a result, all code that awaits async is N times slower than synchronous code. That's the sacrifice the humankind pays for subscribing to Microsoft's dogma.

Visual Studio has become slow as fuck. From 2005-2008 that were FAST we arrived at mediocre 2015, bad 2017, horrible 2019 and disastrous 2022 that can't find its ass with both hands. Along the way, they gradually became more and more asynchronous, porous, gooey, and slimy. I am somewhat even baffled by its slowness because, having been developing in async WPF MVVM under orders from my superiors, I am still able to deliver reasonably fast desktop GUI products. The slowness of Visual Studio 2022 is mind-boggling! It's abysmal. They do something so horridly wrong that it takes considerable time to do any operation, and this is on a very fast machine that runs any other software impressively fast.

When the owner of the OS, framework, development tool, and the final product so utterly fails to deliver performance, it should serve as a wakeup call: something is fundamentally wrong with them.

Posted by: LinuxLies at 08:33 AM | No Comments | Add Comment
Post contains 226 words, total size 1 kb.

I figured Microsoft out just now

By releasing WPF the way it is: bugged, limited, counterintuitive and outright inconsiderate, they damage their competition by wasting their resources on writing boilerplate code. There can be no other explanation. Ask how I realized it?

Enter DataGrid. It does not set the current item of the underlying data collection if it is the one most suitable for sorting and filtering: ListCollectionView. Its CurrentItem is read-only, and the solution is to introduce an extra property on the viewmodel, to store the selected row. It would have been a huge help to 'development community' had they allowed CurrentItem to be set by the view but no, that would have been too nice.

As the world wastes their time and resources and spins their wheels writing boilerplate code, Microsoft is laughing all the way to the bank because they essentially have the monopoly on software.

It is no surprise why we witness exodus from .NET technologies to bastard languages like Python, Rust, Ruby, Go, Lua and other shit. This is out of desperation because .NET is crap and Java suddenly stopped being free.

Fly, you fools!

Posted by: LinuxLies at 09:05 PM | No Comments | Add Comment
Post contains 196 words, total size 1 kb.

Not only WPF lacks important classes and methods. It is BUGGED.

Any company that dared to release such a half-assed, half-baked library as is WPF would have been savagely, cruelly ridiculed by the 'development community'. Any but Microsoft. They are above critique.

Enter Calendar. Not only it is absurd because it violates MVVM by not allowing BlackoutDates collection to be databound, but it is also severely bugged.

When the user selects a date in the previous month that is visible from the current month, the calendar jumps 2 moths, highlights the date that is situated in the same row and column as the clicked date, and selects the correct date. Now, to see the selected date, the user has to switch to the next month (that is the previous month from the starting point).

Is it possible that Microsoft did not know that before they released WPF? No. That means that they did not test.

No company would have gotten away with such sloppy test process but Microsoft. They are getting away with sloppy testing of Visual Studio.

WHY IS EVERYBODY SILENT? WHY DO YOU NOT CONDEMN THEM FOR THEIR SLOPPY WORK AND DISRESPECTFUL ATTITUDE? WHY ARE YOU SILENT?

Posted by: LinuxLies at 01:20 PM | No Comments | Add Comment
Post contains 210 words, total size 1 kb.

WHY IS EVERYBODY SILENT? SCREAM!

I will post a link to a question on StackOverflow and a linked article. Both illustrate the madness introduced and promoted by Microsoft, with the silent approval of the IT industry sector.

Is it wrong to invoke an async method from a property setter?

Async programming patters for asynchronous MVVM applications data binding

Both prove my point: the only reason why the so-called 'development community' got hooked up on and swallowed WPF, MVVM, and async is that Microsoft was able to blow ginormous amounts of money on PR. They used armies of trolls on StackOverflow, to indoctrinate beginner developers in firm belief that the above 3 concepts are the best things since sliced bread. Truth is that they are not. Truth is that Microsoft dropped the ball on everything since early days of .NET. Those same armies of trolls downvote every question that has to do with the shortcomings of the said concepts, to silence every possibility of criticizing MS for its transgressions.

Async is called plague or cancer for a reason: if you want to call something asynchronous, then you have to await it, and you can only await in a method that is async. So, your entire hierarchy of methods has to become async, or you face hard-to-track, hard-to-find, and hard-to-debug problems such as deadlocks.

Well, MS trolls tell you to use async bottom-up.

That'd be nice! But they forget that we deal with millions of lines of legacy code that no one pays to rewrite. We deal with already-synchronous applications that suddenly have to use async libraries. And the world pays the price equal to billions of $$$ for rewriting code that would have had to be touched had not Microsoft released their cancer into the world.

Get that: WPF MVVM dictates that views must be databound to the viewmodels. That is done through property getters and setters. But the getters and setters cannot be async!!! How do you call async methods from them?

In the linked articles above, MS trolls hammer home the point that setters must not call long-lasting async methods. But that is a lie! async and long-lasting are not equal. Something may take a fraction of a second but still be code as async. They are apples and oranges, but the 'do as I say' attitude of Microsoft is above all.

Read the linked articles to realize how much more boilerplate code each developer now has to write, to comply with the shortcomings of the half-baked, half-assed async paradigm and WPF MVVM pattern, courtesy Microsoft.

The world is paying for not breaking Microsoft up into several companies, many years ago, when it was still possible. It still is not too late. Break them up now!

Posted by: LinuxLies at 04:38 PM | No Comments | Add Comment
Post contains 462 words, total size 3 kb.

WPF insanity must be stopped

The sooner the world realizes or admits that WPF is insane the higher will be our chances for survival as a civilization. It is really that bad! WPF is insane, mad, clinically proven lunacy.

Do you know that you cannot style a column in a grid? Seriously! A column is of a type that cannot be styled. You have to jump through hoops, to style all cells in a column the same way.

This is in 2024 for crying out loud. This is not the early 1980s when we desperately lacked computational capacity and developer resources, and development tools were limited. No, this is the 2nd decade of the 21st century, when hundreds of millions work in IT. Yet we make an insanely giant leap backwards and revert all the way to manually writing XML in order to build highly complex UIs.

We used to have C developers. That apparently sucked.

Next, we got Visual C++ developers. And that royally sucked too.

Next we had PowerBuilder and Delphi developers. The sound of sucking became deafening.

Then MS bought out Delphi development team, and we got Visual Studio for .NET with WinForms. Finally, some improvement!

That was not too good, so we got WPF. Finally, nirvana!

Did you ever see exception stack trace from WPF code? It is like 50+ call levels deep. I kid you not. Do you expect performance from that? Fooled you! It takes time just for a menu to drop down, just for a file open/save dialog to show up. Can you imagine how much longer it takes for a WPF application to do some real work? I'll tell you: 10x longer than WinForms or Delphi Win32 apps.

The IT industry lead by fucking geniuses in Microsoft was supposed to help the humankind achieve perfection. It does the opposite: leads us in reverse direction from progress to retardation. The sooner we realize and admit it, the higher is our chance of averting catastrophe that awaits us.

On one hand, Microsoft codes into Visual Studio suggestions to write code a certain way, a so-called "Style Cop". On the other, it generates code that contradicts the former and breeds warnings. This is diabolical, but we love it, don't we?

Posted by: LinuxLies at 04:22 PM | No Comments | Add Comment
Post contains 380 words, total size 2 kb.