Another Linux lie: systemd has advantages over whatever

Truth is: it does not. It is a lie.

Did you ever try to run journalctl on a system with history, through ssh? Try it! I will take bets on how long it will take you to curse everything and install rsyslog or syslog-ng.

Genius is as genius does: as a degenerate. Genius degenerates in systemd dev team do not care how their bastard child journalctl performs. Zeal is their driver.

Posted by: LinuxLies at 06:34 PM | No Comments | Add Comment
Post contains 87 words, total size 1 kb.

That bitch jusst mocks the all Linux users and laughs at us from under its rock

Some time around the release of Fedora 19, the inbred piece of garbage who calls himself the developer of xrdp fucked something up in his code, and the package stopped working under all Linux distros.

Google 'xrdp login error', and you will find many questions about how to fix it and very few answers. This crap just does not work anymore, but the waste of skin who develops it does not give a flying fuck.

Decades pass, but Linux users still edit tons of files, fix bugs in them, copy files around, create new files, run scripts, restart services, to no avail.

Why are you silent? Why do you not scream into the bastard's face: You, bitch, must learn to test your software before you release!

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

Logical fallacy of the year: Protonmail bans service registrations

One cannot use Proton mail, to register on sites, because according to Proton mail's notice, they do not want to be banned by those sites in case subscribers try to avoid registering with their "real" emails.

Now, give that a thought! Proton mail cannot be used to register because they are afraid that they may be banned for allowing subscribers to register. So, either way Proton mail cannot be used. Congratulations, dolts! Your hyperactive minds invented something that keeps you occupied but achieves net zero result.

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

Another Linux lie: we have a web browser

Truth is: no, you don't.

Tried to print web pages to PDF from a recent Firefox. They cannot be opened either in Acrobat Reader (file is damaged blah-blah-blah...) or LibreOffice (file is encrypted blah-blah-blah... on Windows or ASCII filter is offered on Linux) or Firefox itself (shows a cute blank tab with modern Acrobat Reader controls up top).

They do not test their software. If only they tested, they would have noticed that files are corrupt/unreadable. Or they did notice it but did not give a fuck. Oh, this wonderful new world of untested releases and inept developers. Soon, this filth will spill into air traffic dispatch and nuclear station control software. Mark my word.

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

Another Linux lie: we have portable C++

Truth is, you don't.

The one-size-fits-all answer to all questions in C++ world is not 42 but 'you do not need it'. The know-it-all types at C++ whatever committee and around it bestow their divine wisdom on anyone who tries to do something. That wisdom is 'do as I say or'.

Enter std::chrono namespace and its steady_clock type that is only suitable for accurate measurement of short time intervals. It is a thing of its own, incompatible with just about anything.

You are not supposed to convert it to any meaningful, reasonable time units "because you do not need to". When you get strange results from your code and want to ensure that it is doing what you want, you will not be able to output any time_points that your code populates along the way. There is no conversion from steady clock time points to any other data types that can be output to console. End of the story. Dead end. You are either allowed to take accurate measurements or you are allowed to output them, never both.

Enter std::thread. There is no way in hell to obtain the current thread's native handle. These fucking idiots do not give a fuck that we have to interact with OS-specific calls. They do not give a damn that we may have to manipulate threads in OS-specific way. They are all portability, and fuck all.

I am beginning to hate std namespace with passion. I wish their authors slow and painful death because they go out of their way to achieve extreme sophistication and in the process make things so unfathomably complex that they throw baby out with water.

Posted by: LinuxLies at 05:55 PM | No Comments | Add Comment
Post contains 290 words, total size 2 kb.

Only Microsoft is allowed to develop performant software. No one else is!

Suppose, you are like me, and you need to write a high-performance application. Its performance has to be as high as your hardware would allow. Naturally, you would write it in C++ instead of .NET languages. Not so fast, sucker!

Microsoft has gone out of their way to make your life as miserable as possible. The tooling of Visual Studio for C++ development is nearly as rudimentary as a text editor.

In .NET projects, you can create copies of files, by Ctrl-dragging them to the same or different folder. In C++ projects, it is "Screw you, Benny!". You cannot drag-n-drop files unless you turn on "Show all files" but to add insult to injury, even then VS won't allow you to drag and mock you with a pop-up dialog that asks whether you want to copy a file onto itself.

Microsoft just won't allow you to develop in C++. You are not allowed.

Did I mention that no refactoring is available to C++ developers beyond basic renaming? Now I did. I tried to extract functions, only to be mocked by error message that told me that VS could not extract due to an unknown error. MS never knows their errors. Who wudda thunk?

Did I mention that C++ unit test projects are a gimmick? Now I did. They essentially do not work in a sense that it is not enough to #include your .h or .hpp files. You have to include .cpp files as well!

How did they manage to make .NET projects work? By project references. The reason being that every .NET assembly, no matter whether .exe or .dll, is an assembly. It does not matter the format. But unmanaged .exe does not expose functions, so you have to re-include all sources into your test project. MS did nothing, nada, zilch to alleviate our pain. Essentially, unit tests for C++ do not exist, i.e. a gimmick.

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

Instant messaging sounds like freemason handshake

Did you too notice strange similarity among all instant messaging FOSS projects out there, without exception: they are secretive as fuck?

Whenever issues occur, it is futile to ask for help: none will be provided. They will ask you all sorts of intrusive questions and demand that you post their software's logs to which they dump plain-text passwords, IP addresses, domain names, user names, logins, contact details, yada, yada, yada.

When you challenge them as to the reasons for such prying practices they will circle wagons, push back, and resort to all kinds of social engineering techniques designed to discredit you as a user and your competencies as IT professional.

I've seen this with quite a few: Jitsi, Gajim, Pidgin, Jabberd, OpenFire, Spark, Asterix, Kamaillo and others that I can no longer remember. Never ever I got any resolution to issues with those softwares, no matter how blatantly obvious it was that it was their fault.

Jitsi team, for example, was totally uninterested in their 'thing' freezing solid when keyboard layout was switched as if there was only one language in the universe. Did I mention that they blamed Java? Yes, Emil Ivov had audacity to tell me that Java had a bug with switching layouts even though that nothing written in Java at all on Earth had any issues switching keyboards.

The reason for that is likely that IM projects do not act in good faith. Their goal is to be malwares. Once I mentioned that my IM infrastructure was behind a firewall, and they told me it was the reason it did not work as expected. I lied: there was no firewall. I baited them, and they bought it.

Careful with FOSS: many of them are neither F or OS.

Posted by: LinuxLies at 12:34 PM | No Comments | Add Comment
Post contains 304 words, total size 2 kb.

Genius is as genius does (usually as degenerate)

Gitlab is great, isn't it? It is awesome. Its developers are also awesome and genius. So genius that they dump plain-text SMTP and transactional email service provider passwords to logs and then they ask to see the logs when someone comes to their site for troubleshooting.

What is with this world that insists that software development be done by genius degenerates, preferably in China

Gitlab devs in particular and Rubi devs in general are so exceedingly genius that they need layers and layers and layers of sophisticated shit like this in order to achieve trivial things like sending an email.

Listen to them! You need to run a Ruby console (whatever the fuck that is) and ensure that the method is the same as in gitlab.rb... Why do you keep one thing in two places? Too genius for the universe?

They are so exceedingly genius that their log format is the opposite of human-readable: it has timestamps at the end of the line and only on some lines. Good luck investigating WTH is going on!

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

Microsoft: "I don't give a fuck!"

For decades now, cohorts of .NET developers try to code their applications to play the default system beep and fail. This simple line of C# code just does not work, no matter what:

SystemSounds.Beep.Play();

Search online, and you will find questions with no answer. Questions from way back, from the earliest days of .NET and up to the present time. Solutions? A plethora! But nothing that works in 100% cases.

People of Earth! We have to become concerned because even a multi-trillion-dollar global monopoly that makes the OS, framework, compiler and WAV files involved is not able nor willing to address this problem. They instead blow their budgets on redrawing their products' icons, almost every year.

If they are such inconsiderate, careless, rude, brazen jerks, then why are we supposed to be nice to anyone? Answer me!

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

MS: When you document something, try to make your documentation accurate

After all, Microsoft is a multi-trillion $$$ global monopoly that apparently has enough $$$ to blow on the annual redrawing of icons and reshuffling the GUI.

If you are like me and going nuts because you are trying to serialize a collection of POCOs w/o those fucking namespaces being added to the collection element, and you are using DataContractSerializer and its supposedly but not-so-helpful attribute [CollectionDataContract(Namespace = "")] but still getting shit like

xmlns:i="http://www.w3.org/2001/XMLSchema-instance"

on your collection element, then do not try to find any wisdom in Microsoft's documentation: it's not there.

Documentation says that the attribute's Namespace property "Gets or sets the namespace for the data contract. That is not true. That is misleading and inaccurate. In reality it setts an ADDITIONAL namespace on top of the above piece of shit. You are SOL unless you massage the generated XML, which is lame.

That is why you may get the feeling that [CollectionDataContract(Namespace = "")] is being ignored. It is not! It works exactly like Microsoft's developers Hu and Wen designed it. It is just that Microsoft's technical writer Wei neglected to mention its true function. Or maybe they are developers Abishek and Kumar and the tech writer Rajendra. All the same shit.

Having written the above post, I went googling to see what other unfortunate souls tried, and I found this lament that does not have an answer to the day. The genius degenerate Frère Chloé suggested a custom serializer. She gets the Wasteful employee of the year award.

Someone commented how insane is the complexity of getting correct XML out of MS' classes. Yes: insane is as insane does. Wink, wink.

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

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.

The definition of 'dumb cun#'

For anyone who reads my blog it is not a secret that Wordpress developers in general and plugin developers in particular are dumb cunt#s. Here is the clear, telltale definition that explains why they are that and how I know it: read this article.

How To Resend WordPress Activation Email to a New User

It is structured as a typical 'howto' article on the web: it begins with the explanations of what Wordpress, email, and activation are (as if we did not know it when we googled for 'resend email activation' and clicked on that link).

In typical know-it-all superiority complex afflicted arrogance of FOSS developers they bestow upon thee the sacred knowledge of those concepts... for the total of a dozen of pages... only to direct you to a link hidden deep within the bowels of WP Mail SMTP plugin. Yes, I am serious: it is the bullet #5 on their list of blatantly obvious 'Wordpress 101 for dummies'-styled essay.

Seriously, dumb cun#s? You could not put a 'Resend activation email' link on a user entry in the user list? Who are dumb then, you or we?

Icing on the cake: did you know that 'Email log' is a paid feature in WP Mail SMTP? Extortion anyone? 'It is a nice site you have here. We do not want anything to happen to it.' Sounds familiar? So, WP fails to send activation emails to new users, and we cannot resend them. It would probably cost less for the WP user base worldwide to hire a hitman for WP development team than to buy paid subscriptions to WP Mail SMTP. Think about it.

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

If I did not know Microsoft as well as I do

I would have asked: Why does WPF need to be so fucked up?

But I know them all too well: they are genocidal monsters, same as their boss Gates.

WPF is FUBAR. No sorted controls! Models have to be sorted manually, by writing boilerplate code for converters that do the sorting. IsLiveSorting exists only on CollectionView which is not used everywhere, as a rule. Want your controls sorted? You are in for a lot of pain.

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

Never before did I write so much unnecessary boilerplate code as with WPF

This is what blind, fanatical following of a dogma puts you through: tedious workarounds.

Enter TreeView control. Microsoft sabotaged it by replacing SelectedItem with SelectedValue whenever the control is databound (which is like 100% of the cases). As a result, we ourselves are forced to implement parent-child relationships in our hierarchical models.

Enter Newtonsoft JSON package that is used in like 100% cases of serialization these days. It throws:

Newtonsoft.Json.JsonSerializationException:
'Self referencing loop detected for property 'Parent'
with type 'Models.S'. Path '[0].T[0]'.'

whenever it is asked to serialize such parent-child hierarchy.

We are SOL, and Microsoft laughs all the way to the bank while we are hard at work on workarounds, writing boilerplate code that would have been unnecessary, had they only kept `SelectedItem` being `SelectedItem`.

Allow me to ask an important question: why do we remain silent?

Why does no one, literally no one, condemn Microsoft for releasing a half-baked, half-assed, tortorously painful to use framework that has absolutely zero support in terms of bugfixing and feature improvement?

They buggered TreeView, threw away NumericUpDown, neglected to add comprehensive InteliSense to XAML editor, neglected XAML designer that is simply impossible to operate with a mouse or to comprehend, and everybody silently jumped on WPF like a fat kid on a twinkie. Dockable toolbars anyone? Aren't they what WPF was advertised for? We were promised a framework that would allow us to simply and easily create MSOffice-like apps, no? NO! You will be writing tons of boilerplate code if you want that. Screw you, Benny!

What's wrong with you, developers? Are you petrified by the fear of Microsoft? Does each of you cherish a hope to work for Microsoft one day and that is why you keep your mouths shut? Okay, I can probably understand the developers but why are business administrators and owners silent about the huge waste of time and $$$ that WPF requires?

What's wrong with you, people?

Posted by: LinuxLies at 12:13 PM | No Comments | Add Comment
Post contains 346 words, total size 2 kb.

Here's how Microsoft owns everybody, every time

Step by step instruction:

1. Create something horrible like WPF.

2. Sound fanfares and announce that it is the next big thing.

3. Once everybody realizes what a horrid mess it is come up with libraries that fix its bugs but by different vendors.

4. Bank the cash.

They do it every time, and the gullible 8 billion hamsters around the world buy it every time.

Get it? TreeView.SelectedValue is the actual collection item bound to the tree. So far so good. But TreeView.SelectedItem is also that very same object whereas it has to be a TreeViewItem! That makes it impossible to find the selected item's parent (or any item's parent for that matter) w/o resorting to 3d party libraries that override the default behavior of tree views.

And Microsoft's stooge companies that delivery hacks and patches that fix its bugs laugh at us all the way to the bank.

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

We are Microsoft, and we will steal your IP

I will not be the first one to observe that MS steals things rather routinely. Not even the 2nd. Not even the 3d.

Enter WPF, the MS's new, glorious replacement for the boring, obsolete WinForms. WPF is a marriage between XML and C#/VB etc. Its windows and user controls are designed in XAML, the extension of XML for GUI.

Data binding is the King in XAML, and it is a perfect match for the MVVM pattern toutes as the 'next best thing' for software development and the natural pattern for WPF.

So, we embark on the binding process for some control, only to find out that the XAML editor in Visual Studio does not see your classes. Why?

After a long and tiresome investigation you find out that in order to be visible to XAML data binding, your classes have to be public. Huh? Why can they not be internal with InternalsVisibleTo element set to the public key of the assembly that contains the XAML? I will tell you why.

Microsoft did it so that once all your code runs in their Azure cloud they have access to the classes, properties and methods in your assemblies. Under DMCA they may get into legal trouble for un-signing and disassembling your assemblies in order to snoop on your code. So, they force you to make your classes public in order to see them w/o violating DMCA.

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

How Goebbelsian lies twist our lives

I live long enough to remember a vivid discussion, in the late 90s-early 2000s, about security risks introduced by Java applets. The common concern was that unrestricted execution of applets in browsers may compromise users' systems. Fast forward late 2010s-early 2020s.

Today, Java applets are history. They have been. They expired. As are Silverlight applications, for the most part. All of those pesky security risks are replaced by... a mad herd of JavaScript frameworks. Somehow this

is much safer than a scary Java applet. Is it? Let's review.

A Java applet typically required an explicit permission from the user to load, in their browser. It loaded entirely from the well-known and controlled environment of its owner. Browsers of the day provided required isolation mechanism that locked the applet in the JVM and barred it from accessing local resources. Compare that with the screenshot above and keep in mind that this is only a very moderate, tame, docile example. There are sites that load 3-5x more JavaScripts from HELL KNOWS WHERE.

Yes, that is exactly what we have grown accustomed with! We do not even bother to know what JavaScripts the web site loads or from where. And that is absolutely not a security risk, not at all [sarcasm off].

JavaScript can do anything on a web page. It can log keypresses. It can scrub canvas. It can intercept requests and responses. It can spy on the unsuspecting user and alter data that they exchange with the main web site. Nothing to see here, move along.

So, who shat on Java applets, 20+ years ago? Aren't they the same people who now replaced them with JS frameworks, silently, without raising any fuss about it? Follow the money!

Java and its applets were a brain child of a small, struggling but ethical company, Sun Microsystems. JavaScript frameworks are brain children of filthy-rich, brazen, into-your-face global monopolies: Google, Facebook, Twitter, Microsoft. There are absolutely no security risks with their solutions [sarcasm off].

Why am I raving about that? Because JavaScript sucks balls, and the sound of sucking is deafening. It is a huge waste of resources (processing power and electric energy). It nourishes poor coding skills, breeds duplication and boilerplate code, has compatibility problems, and many more issues that are impossible to resolve. But we love it, don't we? Always remember: JavaScript is an INTERPRETED language. It does not compile into binary executable format. It remains plain-text, in the memory space of the browser. Whole JS frameworks load into memory because there is no linking step that weeds out unused functions. This leads to elevated memory requirements on the client device, and that translates into obscene profits of semiconductor industry.

Most IT professionals are raving, flaming green types. They are also hypocrites because they ignore damage to Earth's environment that their obsession with JavaScript causes. Hypocrites them all!

Posted by: LinuxLies at 01:47 PM | No Comments | Add Comment
Post contains 485 words, total size 3 kb.