ChiefOBrien

How about contributing with an example of those groundbreaking Indian metaphysics studies instead of denigrating everyone with insults?

Watch the episode called 15 Million Merits from Black Mirror.

The bright yellow color can be used perfectly if the design style wasn't flat. It's incredible how much more legible UI elements can be if you add some shading, gradients, 3d borders, anything!

Lua

It may sound stupid, but you can't have unhandled exceptions if you don't have exceptions...

panic!() exists in Rust, but that's not how recoverable errors are handled.

This is the worst argument in the whole article, and this is the worst part of the language. Everyone says it's not like exceptions, but in fact it is much worse. Panic is stringly typed and you can catch_unwind it, just like with try/catch in any other language. And the actual worst part of it, you will never know if a panic can occur in any of the underlying functions until it is too late. Developers be damned if they want to choose different behaviour other than crashing the whole program.

Either double down on using the standard error handling everywhere, or put something like "throws panic" in the function signature (ala Java checked exceptions). Many parts of the language has strict checks for everything, why does panic has to be an outlier?

And then you encounter some ancient apps without GNU readline support (oracle sqlplus and mysql, I'm looking at both of you). No history support, cursor keys emit characters on the line, literal hell when trying to quickly fix remote database...

My idea is that a CPU is just a component and it's useless by itself without considering the rest of the computer system. ARM needs to dip more into standardising the rest of the picture, and the RISC-V guys could also start looking into creating an open computer architecture initiative/group to prevent further fragmentation.

ARM's less open platform also comes with some advantages though. It's easier for ARM to prevent ecosystem fragmentation and non-standard instruction set extensions.

It's kind of funny way of looking at the core part of the ARM ecosystem while forgetting how much outside of the CPU is non-standard, undefined. None of the ARM devices share bootloader, device enumeration, and a plethora of things needed for an open, non-fragmented OS/Software ecosystem like how PC does.

Maybe you can run parts of the same ARM machine code on most devices, but it's not terribly portable to be honest, it has to be very generic. For example, Android devices end up in a pile of trash because you can't just upgrade the kernel to the latest version on a 1, 5, 10 year old smartphone without losing functionality or being stuck at step 1 for the lack of tools from broken forum links and shady fileshares. So much for software flexibility...

26 years since the release of Win95 and Linux still cannot make a pixel perfect copy of the GUI with proper alignment and padding.

You should explain what's wrong with the argument instead of being a passive agressive asshole. It was a continuation of why it happens nowadays that people swing to static linking and then posts like this get shamelessly upvoted.

Tell me how much of the system libraries are written in C or C++, and how much of them are being written in newer languages.

C is the default choice because of its ABI, and the tooling around it is made for using shared libraries.

What can you say about modern languages? Each of the languages are designed to work in a silo and not much cooperation for let's say, system plumbing. Their own package manager makes it easy to pull in code, and only make code for that language only. You can't just create a package that works as a shared library for other programs without mushing around C FFI. They make it hard by default, which creates resistance in developers to make a piece of code usable by others other than their own language. This trend is pretty alarming, especially when hidden and manipulative language fanboyism is showing its ugly head everywhere.

Torvalds:

Disk is cheap

I certainly don't want each installed desktop app to have a copy of base gnome/kde runtime and everything down to libc. And the implication is even the graphics would be duplicated, for example the Adwaita icon pack is huge. So if I have a full set of gnome applications (say 50) would I have 50 copies of Adwaita icon set? Suddenly disk space isn't cheap. Shared libs are good and we could do better than flatpaks and containers and static linking.

And just because shared libs are PITA it's not just because of their nature, it's the lack of tooling from supposedly modern languages, lack of guidance, lack of care for versioning and API stability, and distro agnostic convention. Each of these problems can be solved by not sweeping them under the rug.

the amount of parallelism they were able to use, which was impractical in C++

You mean after not using OpenMP, basic multithreading core guidelines, and not doing the refactoring with sanity checkup in TLA+, tools that end up on the frontpage everytime people rediscover them.

Yeah and Webrender, Stylo, and Servo just happen to appear out of thin air.

Who knew using already existing data race analysis tools is much more feasible than shoehoning a huge project into a brand new language. Way to go mozilla!

If you develop with COM in mind, then it doesn't matter whether the object is in-process or somewhere on the network.

It's not just wayland. For every single thing you can do on linux there exists several hundred different implementations/projects with the same goal of do that thing, and it has led to bad cohesion between system components. Even Microsoft couldn't figure out how to drop Win32 and introduce other safer environments without alienating everyone. How can we expect Linux to survive and become better if we treat everything in it with such a garbage attitude.

I'm tired of this pro-Wayland horseshit

You have been trying to reinvent the wheel for a decade and splitting the whole community on petty shit like this, halving development effort on an already non-popular platform, and yet you wonder why people are angry. Instead of evolving X11 and deprecating old features to drop tech debt over time, you went and created your snowflake project and paraded over how much more secure your project is when it doesn't have features to this day, features which are working perfectly on X11. This blog post is the epitome of the whole wayland development group's selfishness. You did this thing for yourselves, for your own comfort and feel-good bullshit, not for the whole community. The Linux ecosystem has suffered too much for no good reason, to the detriment of user experience and market share.

pywebview's About page says:

pywebview is a lightweight cross-platform wrapper around a webview component that allows to display HTML content in its own native GUI window. You may think of as Electron for Python (minus huge executable sizes). It gives you power of web technologies in your desktop application, hiding the fact that GUI is browser based.

It's still as bad as electron and calling it native is a stretch.

It's not the engine's fault for having terrible performance on simple levels. Most indie devs don't bother with LODs, occlusion culling, and turning off unused features. Decades old tricks like turning off unseen/far away actors, merging mesh and material to bring down drawcalls is also alien in the minds of asset flicks. Both engine provides many monitoring tools and utilities to fine-tune performance and settings on each quality level...

Hot take: A great tragedy of the GNU/Linux ecosystem is the fact that ABI+API is still not figured out, and the most common interface between programs is the C ABI, which is embarassingly primitive even by 80's/90's standards. Some people in the FOSS community just want to leave things as-is to hinder propiertary software, and it's the same story with device drivers. You can debate the merits rightfully so, but then there's still companies pushing out binary blobs which break every few kernel updates. As a FOSS developer it's an eternal fight between good and evil with no winner in sight, as a propiertary developer it's pain in the ass to maintain old and new software between all the permutation of Linux distros, and as a user I get to cry because of the lack of popular software and backwards compatibility. Snaps and flatpaks are an ugly hack, literal ductape around this very fundamental problem, and clearly not the solution. GNU/Linux should have adopted COM and/or an adequete proglang with stable ABI a long time ago, and should have tried to control wasted effort put into duplicate software ecosystems (KDE and Gnome).

You shold try out buildroot[1]. It's used for building a complete linux image for embedded systems so the result is quite small, efficient. There are several guides online on how to build for Raspberry Pi, might support cloud as well.

[1] https://buildroot.org/

The stockholm-syndrome of the few users positively recommending something that changes their development workflow slightly when they were bored of doing things the old ways.

I don't like the style this site uses. Ugly color choice, typography and whitespace all over the place, and emoji ridden visual noise. Like why spend all the time picking exotic fonts and optimizing images if the presentation is simply put, awful?

Reminds me of OSGi. Great idea, poor adoption, mostly due to the complexity of the problem domain. Microservices are a lot worse in that regard, yet remain a whole lot more popular, sadly.