okanat

That's what is going on with images taken. iPhone and other cameras now have a per device cryptographic signature. https://c2pa.org/

Soon images taken without this signature will be unpresentable to the court.

Having two Mesa installations at once is how you summon dragons to fight. The FOSS Linux ecosystem doesn't really play well with multiple versions of libraries.

Though only with commercial distros. If you're using a fixed version of RedHat, SUSE or Ubuntu (which Canonical offers a commercial version), you're fine. Just hope that their support is long enough and NEVER EVER change kernel versions except patches!

If your GPU is older than 5 years, then you're in danger zone and you should have completely replaced your hardware 3 years ago and bought new Nvidia equipment now 10x more expensive!

It is the same people who say Git is unseasonably hard to learn. It isn't. Git and its command line is ugly and hard to remember. Understanding what those commands do at a commit and a branch level isn't really difficult. Even the internal object model is only moderately difficult.

I say this as a person who strongly dislikes many many aspects of Unix and Linux due to bad design and terrible UX. Git has a better design than any Unix program you get.

Submodules work okay. It is just Git LFS but for Git repos. Get over it.

I need git-filter-repo to rewrite entire documentation and also resurrect and rehire earlier employees to repeat their GPG signatures.

Hah! One would wish so but they do. `/usr/local` usually has preference over `/usr` and libraries that use a plugin architecture often break when you update but forget to recompile plugins.

And once you go into FFI for interpreted or JIT compiled languages it turns into hell. Both Python and Java creates huge headaches when you have multiple versions of the same libraries in various /usr subdirs.

I often helped lab students who read a simple `make; make install` tutorial for OpenCV and permanently messed up their Python installs.

That has to be the host kernel not the guest kernel. Old Nvidia systems without supported kernel drivers often lack IOMMU to forward PCIe memory, too. I wouldn't recommend using an outdated host kernel with 2026 AI-powered vulnerability scanners.

Windows (10 LTSC or 11 with dTPM) actually works better for old Nvidia systems with WSL. You even get CUDA libraries within WSL and security updates for the next 5 years.

Not license, it is the codebase and tooling. Waterfox and LibreWolf exist. However FF code base is a bit a mess compared to Chromium. Chromium has a better build system using Starlark. Starlark is quite resilient against exploding complexity and easier to keep C++ codebases sane. Mozilla's build system is a soup of multiple tools. Firefox used to use Mercury and only lately switched to Git.

The origins of Chromium come from KHTML which was designed to be embeddable and quite modular. Both Webkit and Blink forks retained that feature and improved it.

Chromium has V8 which is the faster JS engine (so it accommodates crappy bloated webpages better). It achieved HW acceleration early on, it is quite important for video decode. Many webdevs only optimize for Chrome for viewing.

Just like [^1] says:

> After spending years doing those FFI dances in both directions, I’ve reached the conclusion that the only good boundary with Go is a network boundary.

It looks like this extends into the package manager too. The only good boundary with Go programs is a socket. The only good boundary with the Go package manager (? if we can say it is one) is a domain and a DNS server (your own or somebody else's in the case of gopkg.in).

[^1]: https://fasterthanli.me/articles/lies-we-tell-ourselves-to-k...

LLMs cannot do math. They can generate tool calls as text that allow them to drive programs and proof agents. Compare and contrast this against human brains who can do math in the same context without needing external tools. We don't need to bring a calculator to count the letters in a sentence. It is a different neural machinery.

How so? Firefox isn't a small, raggedy development project. Mozilla developers are well-paid and Mozilla has offices in a premium location and it can afford paying millions to their CEO, despite losing significant marketshare.

> Oh, its good at doing desktop applications these days? Which GUI libraries are good these days? Some native win32 binding? Are there good equivalents for Qt?

If your goal is "delivering applications to only well-sighted people who can handle non-native and buggy UI", yes iced, EGUI, gpui exist. But as you can guess they are years behind Qt where you have quite the professional toolkit and properly implemented accessibility features (with a lot of bugs and horrible API because Qt).

The only foolproof way of having truly professional software is still the same: have N different, very-well integrated UI implementations (like Adobe does, $$$ in developer or agent fees) or use a Web browser aka Electron.

With Rust you can use Win32 or WinUI3. Both are provided by Microsoft-developed crate windows-rs.

I'm using LineageOS so I have the AOSP Phone app. If Graphene uses the same, then you can actually determine the exact time of call, but you need to jump through a couple of hoops: Go to "Call History" from the three dots then click on the call of interest. You'll see a button called "Call Details". Then you can see the exact time.

Rust's async can be very lightweight depending on the runtime implementation. tokio and embassy are both runtimes but former is a throughput-optimized heavily multi-threaded while latter is a simple cooperative multitasking for embedded. We use both at my day job. Even 64k flash and 16k ram is enough for embassy.

EU isn't a single identity. Usually overt displays of nationalism is frowned upon in Europe, especially in Germany. Moreover I have a strong guess that if there would be a flag, it would be the Bavarian one for a company called "Isar".

Yeah let's start on a specific version that they overhauled the API since computers are getting new hardware features, god forbid a different DPI. And use that as a leverage point against a library that kept their API quite stable for the last 20 years!

Especially when comparing Qt against a library who couldn't keep its shit together for 5 years and is infamous for breaking all sorts of API and removing features.

True RTOS scheduling is equally possible on Rust. RTIC does it already.

There are more layers, if you'd like to look into it.

- Web developers don't support older browsers because they lack the skill and economic motivation for it.

- The managers of web developers will not support them, because there is no money to be made in supporting older browsers. Nor are there career benefits in maintenance projects. No developer or manager will get promotions for it.

- The actual management of the companies will not promote or compensate engineering managers or developers for maintenance projects since it doesn't contribute to "line goes up"-economics.

If 99.9999% is on WWW, nobody will move to Gemini. There is no business to build on Gemini, no publicly accessible, culturally broad community exists on it and none will exist. You'll only find programmers on Gemini. No authors, philosophers, non-IT engineers/makers with their projects. WWW has organically grown. Gemini has to be equally or more capable and more user and business friendly to have a significant contributor base.

For a browser, that's not really possible without a significant team of over-the-average and paid developers. There are a lot of complexities in a browser. It has to have its own GPU driver, JIT compiler, optimized scheduler to pull page components, another scheduler to run JS, a cross-platform rendering abstraction, hacks for 30+ years of WWW. All of that should be fast. Because everything else is extremely slow and wasteful on Web.

People who can handle this complexity are extremely mobile in the industry. They can always find employment in a much better paying place than Mozilla. And a competitive browser has to have such developers on generous payroll.

One of the issues with Firefox is its codebase. Some parts of it are slowly rotting and it has its own fair share of 20-year-old bugs. Mozilla is slowly failing to keep up with the ever changing landscape and dealing with the age of their codebase. There is a reason why Electron could be developed with Chromium but not Firefox. Mozilla really tried this as well, it just didn't work.

If you're forking, Chromium or Safari are a better start point than Firefox.

There is, if said USB-C ports are both Thunderbolt 3+ or USB4. Thunderbolt will create a ad-hoc 10G network device between two hosts.

What prevents people from obtaining or buying such devices and automating them? Using TVs as proxies is just one example of that. People will be willing to give their ID cards away too, if you pay them or beat them enough.

European grid is linked together. That's one of the significant points of single market. Netherlands can use French electricity.

No. Maybe web UIs do. However professional GUI libraries like WinForms, WPF, Qt come with a lot of well defined interfaces for activating menu bar, Alt+<key> combos, tab ordering. Just like TUIs, the developer should take time to program them. It is not a lot of work though. Most of the time it is a simple XML config change.

> GUI SDKs generally require the developer to pick a solution. And it's easier to default to the simpler solution where you have one instance, one data model, one window.

I don't know which GUIs you have programmed but for Windows and GNU/Linux this isn't the simplest option. It requires quite the effort to actually enforce single instance.

I don't know much about macOS. I only used other people's stuff and navigating it is really hard for me.

You're wrong about GTK, Qt, WinUI and Electron though. They default to "do nothing" which eliminates the ability to even know that another instance exists. You have to manually program that.

Yeah. This is Unix nerd bs and toxic behavior and silly belief that only terminals deliver complex behavior.

I was visiting a radio test lab in last February for our new product. They use a professional software which was written in WPF. The assistant there was flying with the keyboard shortcuts.

I recommend every self-describing Unix or terminal fan to watch videos of photo or video editors / VFX people on YouTube. They are hella fast.

KDE has a framework based on Qt's QML that works on Android. It is called Kirigami. They have written apps and even a complete Plasma Mobile using it. The apps work both on Android and Linux.

Mobile has significant paradigm changes that makes using both terminals and traditional GUIs harder anyway though. I do expect the need for completely different cross-platform libraries for mobile UIs.

No. When the communication side is actually done thoughtfully, GUIs deliver superior experiences even in remote environments.

VSCode SSH extension is one of the most widely developer-used proof against this. Windows' RDP is the other one where many engineers and POS personnel have experince using them. Many electrical and mechanical engineers still use Windows RDP at my work to run simulations. The connection is responsive enough to survive their home-to-office VPN connection. I set up complex chemical simulation software that is accessed by clients of a HPC cluster over 1000s of kms away.

VScode has a really efficient protocol that communicates only that's required, Windows RDP can declaratively send UI component changes as long as one uses Win32 or WPF. It can also reasonably compress the data to even survive dial-up levels of bad data.

We use multi-attendant video conferencing day to day with whiteboarding extensions. If there is will, efficient and amazing remote-GUIs are easy.

THERE IS NO STANDARD, AGREED ON, RFC'd or EVEN BEHAVIORALLY DOCUMENTED ABI FOR MUSL TO FOLLOW!

It's not Musl's fault that Glibc has an undocumented, badly designed, tightly coupled implementation. It's not Musl's fault when they decide to not follow Glibc's design which they have to reverse engineer and rewrite from scratch. Then Glibc can break it in a future version anyway. They give 0 guarantees and have a track record of breaking things.

Sorry but I feel like you're trying to excuse Glibc out of their terrible design. Glibc didn't ask anybody for standardization. Glibc didn't document their behavior. Musl doesn't need to follow any undocumented behavior. Musl has its own implementation of thread_local variable and it works only for Musl dynamic binaries (which you cannot load with Glibc's ld-linux.so either). You need to tell your compiler to generate code that Musl prefers not Glibc. So effectively we have two ABIs.

There is no standard and any design that tightly couples the system binary loader to the C standard library is just extremely terrible design. Both Musl and Glibc do it. Both of them are terrible. Glibc was first and it set the horrible, binary hostile behavior "have no standards, trust Glibc, and recompile your programs again" as the "standard".

The entire Linux userspace depends on Glibc's terrible design. Due to Hyrum's Law, the exact needs of the complex and emergent behavior can only be surfaced via making a better designed, completely independent system loader and a completely independent libc and then fixing the entire tens of thousands of userspace libraries in the upcoming decades. It is just Sisyphean work to fix Linux userspace.

There is no simple "let libc-X obey the standard S" solution. There is no standard. Linux Standard Base project tried to set a standard. It failed.

I'll won't further discuss this with you. Maybe you have good intentions, maybe you're playing dumb. I'm not sure anymore. If you're the former, I'm not going to deliver every single bit of information. I provided enough resources and you can learn.