okanat

> This is also where Free and Open source diverge: Open Source lets someone block others from forking their fork, whereas Free Software requires that forks remain free to be forked themselves.

This is the same tired nonsense hearsay that all the people who got in FOSS as a religion and don't really understand the licensing. The licenses that OSI and FSF approve as FOSS are literally the same and they have to guarantee the same freedoms. OSI is just nicer with industry and have actual professional leadership.

Source available and fair source licenses aren't seen "kosher" by either party.

> Shipping in C:\\Program Files\\Your Name is standard with Windows applications; DLLs aren't shared between different applications like in Linux, so there's no reason to use them.

Win32 and CRT (libc) is shared among programs, .NET framework DLLs are also shared. Industrial software does ship multiple .exes that depend on the same subset of DLLs. Anything that uses registered COM interfaces also use shared pages for the DLLs in memory.

> Additionally, the Windows dynamic loader doesn't squish all DLLs into one global namespace like the Linux one does. Every time you call a function from a DLL there is extra friction, even for the programmer.

This is an advantage of Windows over Linux where those squish into one unified namespace create compatibility problems and force the programmer to compile everything as a one single big universe / distro. It basically makes long-term backwards compat impossible.

Compile-time linked DLLs have no significant overhead compared to Linux after they are loaded and the loader has done its relocation work.

> There's also the libc linking problem. Each DLL may get its own copy for libc, either because they are statically linked or because they are compiled with different versions. If you try to fopen in one DLL and fclose in another, or malloc in one and free in another, it's liable to crash. This might've been solved in the 20 years since I learned about it, though.

This still kinda exists. However, Microsoft hasn't broken their CRT ABI since 2015. It is a feature not a bug IMO. All properly made libraries ship their own allocation and free functions for this very reason. It is not specific to Windows. This does happen with Linux shared libraries when they use their custom allocators. Giving up the ability to link with different libc versions, ability to link with multiple versions of the same library or good backwards compatibility is not a good tradeoff just to have a single global `malloc / free` call.

Win32 is the only stable Linux ABI. You can run Delphi apps under Wine.

See https://news.ycombinator.com/item?id=49275165

TL; DR you're right. We are aware options like Podman and systemd-nspawn (check it out if you don't know). They are just overkill.

No we don't need / shouldn't use Docker. As jasomill guessed the disk size and memory usage that Docker needs is just unnecessary overhead. These devices have only 8 GiB disk space. systemd provides every single thing that we need; one can obtain equivalent isolation just with a systemd unit file.

If you don't need the layers of Docker and server pull-push, it is just overhead. We just fetch a single cryptographically signed squashfs file and execute the program in it with limited FS and separate namespaces.

Windows provides almost 100% of the system-level dependencies you need. You don't need to specify things like "I need gstreamer for video decode" or "openSSL for my network". Those are all part of a standard Windows system and they have stable API/ABIs.

Only thing you ship with your application are the libraries specific to your app. If you use Qt, you ship Qt libraries as bundled DLLs. If you use Havok physics engine, you ship that as a bundled DLL.

MSI can trigger things like installing optional Windows components but it is not a package ecosystem like apt or dnf. It is more like dpkg or rpm.

I think this approach is misguided. Shipping your own DLLs is standard with Windows applications and good workflows using Visual Studio can quite easily can bundle everything you need.

If you need somewhat Linux-like build infrastructure, conan is very helpful to install all your dependencies and to create deployment packages.

At work we maintain embedded-linux computers with a custom distro but the actual graphical interface is a separate artifact developed by another team. Moreover they have to use an SDK that only works on a specific distro (semi-closed source).

Our solution is shipping it with its own glibc and running the executable with the LD inside this separate glibc. Basically the entire userspace. It is almost like a container but the containerization is provided by systemd and there is scoped access to limited system services via mount and network namespaces.

We cannot use static programs. Our systems have limited memory so the GUI load relevant parts of the program as shared library plugins.

This is the only reliable way to distribute closed source / independently packaged Linux software. You ship it with an entire userspace. Docker and Flatpak are just that; an admittance that distributing independent software reliably on Linux is practically impossible.

OS and CPU combination define their ABI as "whatever our most popular / default compiler did in 90s". That's the problem with C-based ABIs. OS ABIs aren't independent of the language. So any new language must include a C compiler within for ABI access.

See https://faultlore.com/blah/c-isnt-a-language/ for more detailed analysis.

> Requiring products to be labelled, and treating mislabelling as fraud, could mostly solve this.

There are too many manufacturers to hunt. Basically USB-IF needs to stop almost all shipments in the world. That's not going to happen.

USB spec is completely open and free to obtain. While it allows people to develop and DIY many things, it also attracts bad manufacturers like flies.

Good certified cables with correct markings exist. There are companies like Cable Matters or Startech who bother to actually certify their cables and get USB-IF TIDs. They do cost you quite a bit money though. Here are some:

https://www.cablematters.com/pc-1532-123-usb-c-20-charging-c...

https://www.cablematters.com/pc-858-123-usb-if-certified-usb...

https://www.startech.com/en-de/cables/1m-40g-usb4-cable

https://www.startech.com/en-de/cables/s2cepr1m-usb-cable

There is actually a law being made called Digital Fairness Act at the moment. However the working group hasn't finalized it yet.

Note that there are competing political groups and MEPs in the EU from far right neo-fascists, to corporate lobbyist right-wingers, to Greens and even digital privacy maximalist Pirates.

Lobbyist right-wingers are now the biggest group and they pass laws like Chat Control because it gives the impression that they do something and it makes corporations money. EU has been founded as a maximally neo-liberal union. The broad human rights are remnants of the Soviet scare and world-war trauma.

A good engineer isn't a godlike entity who knows all. They know when to bring in assembly and when to be satisfied with C / C++ / Rust compilers and steer the compiler.

Assembly has unique advantages like guaranteed execution duration for cryptography or exact optimization of hot-loop computation.

99% of the even performance-sensive code doesn't need assembly and compilers beat good engineers in this category since API surface is big and complicated. For 1% very hot code or very sensitive code due to execution duration / predictability / throughput, humans usually code better than compilers. This is due to specialization and limited DoF problems that can be solved and optimized to hell.

It is more complicated than that. MSYS2 isn't just Cygwin. It has different environments.

MSYS environment is just Cygwin and it uses Itanium IIRC for C and C++ non-Win32 calls since it emulates POSIX. If it links with Windows C runtime they use __cdecl. Win32 API calls always use __stdcall convention / ABI.

However, Mingw environments (Mingw64, UCRT, CLANG etc.) are intended for native Windows development, hence, they use normal MSVC __cdecl ABI for C library calls and internal function calls too. Win32 calls are again __stdcall.

Unlike C, for C++ all MSYS environments use Itanium ABI since they link with GNU libstdc++ or Clang libc++. I think it is possible to use MSVC C++ ABI with Clang but it could be complicated since it requires recompilation of at least libc++.

I think TDF tries to push a wrong narrative here for their lack of engineering and funding.

Competitive products like Google Docs, WPS or Euro Office solve proprietary file format problem very nicely. Microsoft themselves had to solve that exact problem for Lotus 1-2-3.

Proprietary file formats are an industry standard. It is the lowest resistance way to deliver features and you cannot blame your competitor to have more features or hidden features in their formats. ALL strongly competitive software for the desktop workstations have proprietary formats: Autodesk, Altium, Adobe, Corel, Apple. All of them serialize their featureset on their own format since it is the easiest to do. FOSS won't get the marketshare pie by complaining about it.

LibreOffice has to provide feature parity before complaining here and TDF needs to find the funding source to hire the engineers to achieve that. They need to have convincing arguments and consistently delivered features. Otherwise it will not get adopted.

Microsoft hasn't actually selling their product on the premise of proprietary file format support. They sell it with the promise of total platform integration for every single software an office needs. You not only get an office suite but IT Admin tooling integrates with the computers and the office suite, e-mail management, SSO and licensing management software and Cloud storage all in once.

To compete with the Microsoft (or Google Workspace) you need to be selling all of that at a very competitive price. Otherwise all private companies and many government departments will continue to choose Microsoft. If a change is wanted in the government, governments need to start investing Microsoft levels of money in hiring engineers.

Indeed. My primary issue is requiring a Google or Apple blessed phone for the protocol that is supposed to replace the American alternative with the EU one. If they push strongly the American duopoly, I'd rather use the American monopoly that gives me the better ergonomics and less friction. Yes I do get a TOTP request every now and then, but I have options like authenticator apps, SMSes, passkeys with Paypal. With Wero that's more limited.

I simply do not believe that EU banks will actually invest in a truly independent system with its own trust network. Majority of the banks complain and block you in Germany, when you have a unGoogled phone. It is simply not in the culture of Germany to make risky investments, especially banks. They always choose the options that milk normal consumers. Then EU comes and regulates them into submission. We only got guaranteed free instant SEPA transfers in 2025, while it has been possible for decades. So I am more optimistic for ECB's digital Euro as a consumer than Wero.

> In term of implementation, WeRo looks more like a response to mobile payments like WhatApp, WeChat, Alipay, ... than a response a provider like PayPal.

Wero is usually marketed as the alternative to PayPal: https://www.ndr.de/ratgeber/verbraucher/Paypal-Alternative-W... and I didn't know Whatsapp supported payments. I have never seen such an option.

> You can use QRCode (Direct SEPA).

If they fixed the mobile phone problem and provided a way that's functionally equivalent to Paypal usernames, I'm in for person-to-person transfers.

> Supporting merchants flow to pay is different from prioritizing their needs so I'm unsure where you're going from there. It's also completely separated from Person-to-Person payments. PayPal supports Person-To-Merchant and I wouldn't say they are great for merchant.

Indeed. I may have rephrased my sentence there. I don't trust payment providers that significantly prioritize the needs of merchants over persons. Yes Paypal may suck for the merchants, but its buyer protection is one of the significant reasons that I keep using Paypal for online payments. I do buy stuff from independent sellers in Germany and other EU countries and sometimes they behave less than ideal. Paypal keeps things fairer for the consumer. If Wero is targetting this market, they need to be competing with Paypal on equal footing.

I do have quite stringent non-tracking settings enabled in my browsers, and I do get occasional captcha or TOTP request.However, I never got completely denied a login with PayPal.

Many banks are equally employing the same "guessing whether it is you" techniques with their web UIs. Moreover many of them require Google Play Integrity when a phone is the TOTP. Definitely different ergonomics though.

I don't get why you pointed out that, to be honest. I'm not a merchant. I am a consumer.

As a consumer I would like to avoid Master Card / Visa as much as possible and also giving numbers out as much as possible. Paypal allows that and I don't need to use my phone to approve payments. Moreover payment systems that prioritize the needs of merchants usually are horrible for consumers. If Wero becomes such a platform, I will avoid it.

Paying with Paypal is as easy as logging in. With Wero/iDeal you always need a phone or a code. People trust PayPal more too.

> Not because agents are worse at coding that[sic] humans.

And then the whole article shows tangible reasons where the agents are truly worse at code than humans. Code never is just the text. If intelligence you have is not truly general, you cannot expect things like clarifying wider context, hierarchically ordering knowledge based on criteria and producing consistent results despite transfer learning and retraining.

And no, we are not even close to the multimodal capabilities of human brain to hierarchy encode and reproduce knowledge. Otherwise the correct "reasonable" economic action would be genociding all humans, and I'm pretty sure that this is what billionaires effectively want out of AI.

If you're also happy getting paid for it, then the company will just stop paying you. If you rely on such income to have a visa, you'll 100% sure to accept that you're forced into this and you will give up coding, or else.

That's the last thing in the list and the looping phase of catch-22. Without providing the other earlier items, it simply doesn't make sense to make Windows a Linux distro. NT is still the better solution. Unless Linux kernel becomes very friendly to closed source drivers and gets better isolation and stable APIs, no consumer company will ever invest in Linux.

Providing a closed-source friendly ecosystem for both the OS and the application layer is what Google did for early Android and that's why it caught on.

The advantages of Win32 and the filesystem structure on top of NT's technical advantages guarantees Microsoft's monopoly will go unchallenged for consumer devices. Linux has to become more like NT, not NT become Linux for success in consumer space. Linux will never become more like NT, so it will never get a stronghold.

The question for Linux (or any kernel / system layer) is very simple: If an OEM can hire developers who will independently play a mediator role under an NDA, creating stable kernel internal APIs that live more than 5 years, making sure the kernel is ready before launch without leaking any hardware specifics, Linux is a viable platform for mass-scale consumer hardware. If not, it isn't. Linux fails on all stages of that.

Processor's software becomes no different than a switch, a transfer medium in the network when you use the smartcard capabilities of the EU ID card. Digital signatures and cryptography happens purely inside the RFID/smartcard chip of the card.

This is how payments work for chip-and-pin system of EMV and login and signing systems of many businesses in the EU already. There is no need for third party attestation already.

They do with DST.

Some architecture and some implementation details and sometimes purely economic reality:

1. NT is a hybrid kernel. Windows runs many drivers in userspace, if not in a limited kernel environment. This includes network drivers and GPU drivers. It can recover from crashes more gracefully than Linux and BSD kernels. Linux has similar drivers for specific use cases like FUSE, however, they are not as performant as NT.

2. NT has always been designed to drive a GUI-driven OS. So it has better default tunings than a vanilla Linux kernel to operate and stay reactive under memory pressure. When your system is under pressure you'd lose mouse movement on Linux, on NT this is rare. It is not impossible to do this under Linux, however, not many companies (except maybe Android manufacturers and Google/ChromeOS) actually invest in this.

3. NT provides a mostly stable API and ABI for drivers. It is not as strong as Win32 guarantees, however it retained mostly the same driver infrastructure since Vista. Many Win7 or Win8 drivers continue to work under Win11.

4. Bundled drivers for consumer systems in NT are often better quality. This could be the side effect of stable ABI. Unlike Linux, significant refactors changing big parts of the driver APIs are rare. I think this reflects in the quality of drivers like USB Host drivers. I deal with embedded Linux systems (x86, RPi), there is always some "rmmod and modprobe to fix USB" script somewhere in a deployed Linux embedded system. I have never seen anything similar in Windows Kiosk setups (TBH I have seen a lot of reinit of COM drivers but it is often manufacturer's faulty implementation).

5. There is simply more money invested to make consumer drivers work on NT. Linux is often an afterthought for many consumer device manufacturers. There is still not enough buy-in. Mainline Linux kernel team, being inferior marketshare-wise, requests more buy-in and more collaboration from device manufacturers. This works for servers since there is pressure from end customers who want to retain UNIX-like environments. Normal consumers cannot exert the same amount of pressure. Microsoft provides subsystems, APIs and ABIs to write the drivers to OEMs, often consulting the first manufacturers of a certain new device type and making compromises for them. Linux on the other hand, requires competitors to collaborate and create the subsystems and APIs. Competitor players themselves have to agree with the developers of their competitors to create a subsystem. On a capitalist economy competitors do not want to collaborate unless it significantly increases market size for everyone. Consumer electronics have very thin margins. They do not scale well with increased effort required by Linux. Only select few big tech or certain old-school consultancies send the significant system patches.

Macbook Neos are limited by whatever extra A-chips Apple has. They are okay for very simple office tasks. If you need something like Intel Core5 level performance though, PCs are still cheaper than equivalent M-series Apple chips. If they have both style users, it is cheaper to get a bulk discount from Lenovo/Dell/HP than splitting your users into camps. It is easier to administer too.

Businesses with volume licensing agreements and Kiosk manufacturers can get the licenses pretty easy. Then can even negotiate a lower cost per device.

NT is a better kernel for consumer systems compared to Linux unlike first generation Edge which was a worse browser compared to Chrome.

They do still force the volume licensors with their bullshit. However IT admins are used to dealing with Microsoft's bullshit and they can find ways to automate de-enshitification.

TBH many volume licensors do actually want to use Windows as a service and just pay a negotiated fee per license.

Not so good at reading comprehension, are we?

Forget about web development. All profession-specific software except web and app programming still runs best on Windows. Engineering, simulation, city planning, accounting, complex management, supply chain optimization, media production, statistics. If you're getting paid for some output where computers play an extra-boost tool role, simply being a means to the job, the software you'd use will be on Windows.

If a piece of software is specialized enough that people maintain it for decades, if it has nice detailed and complicated GUIs to handle complex tasks, it will be on Windows. It will rely on Windows' stable API. Those software goes back to 80s and 90s. They have organically grown. Linux kernel requires thousands of developers to keep alive. Linux kernel is much simpler than profession-specific software. Windows Stable ABI allows much fewer people (low 100s) to maintain much more complex software than the kernel.

Even without the stable ABI, Linux is hostile to the closed source software unless that software is served via a TCP socket.

Web can challenge this with Web Assembly and some combination of edge / datacenter computing now. Still quite the way out for demanding things like local simulation and CAD/CAM. There should also be strong economic reasons to throw actually trillions (unlike AI and other SV bullshit balloons) worth of software and entire systems out, not just to spite MS.