301–310 of 459 posts
I want the opposite: id like a way to run the windows kernel, drivers and most low level OS stuff by windows, but with a Linux user Interface: Cinammon, apt and all the debian stuff. I run Mint as my main OS, but hardware compatibility is still a headache in Linux for me.
Doesn't WSL do that?
Like just for the audio stack we had: OSS is deprecated so use ALSA actually direct ALSA device access is deprecated use this special ALSA config with a bunch of plugins actually directly calling ALSA is deprecated use aRts actually aRts only works on KDE use ESD actually ESD is deprecated use pulseaudio actually pulseaudio uses too much CPU rewrite everything to use JACK actually JACK is only for audio workstations go back to pulseaudio actually pulseaudio is deprecated switch to pipewire... I am pretty sure in 6 months I will be reading how pipewire is deprecated and the new definitely final form of the Linux audio stack will be emerging (written in a combination of Rust and Emacs Lisp).
In short, Linux binary compatibility is a clownshow and the OS itself isn't engineered for developing graphical desktop applications. We should stop pretending it is and compile everything user-facing for Win32 ABI, with maybe a tiny extension here and there.
Earlier quoted context omitted.
Is it just me or wine needs a bit more polish? Dialogs and menus are rendered with some weird microscopic font. GDI text rendering seemingly doesn't use font fallbacks, so even something like Scintilla or ebook reader don't quite work under wine.
Many commonly used Windows fonts are licensed under proprietary terms, preventing their inclusion with Wine. Winetricks[1] can be used to acquire and install a set of default fonts directly from Microsoft. Furthermore, Windows font fallback differs substantially from that of Linux and similar systems, which generally utilize Fontconfig and FreeType with font relationships defined in configuration files. In contrast,…
Earlier quoted context omitted.
It's extremely efficient: cold starting Word from an old Office suite is much faster than starting Libreoffice. It also uses less RAM. A few years ago I purchased a few shrink-wrapped Office on ebay for each of the versions Wine claimed to support best, tested then with wine32 and wine64, and concluded the "sweet spot" was Office 2010 in wine32 (it may have changed, as wine keep evolving) Yes, it's 15 years old softw…
It is interesting seeing Office suites from the 90s and wondering what really needed improved. Google Docs pioneering “auto saving” in the cloud is the only one I can think of.
Back then, Word's auto-save updated the file that you were working on rather than creating a separate backup file. I liked that better, though there might have been a good reason for changing approaches in later versions of Word.
Earlier quoted context omitted.
> that's not what applications are coded against anymore Not sure I follow. Sure, most modern programs are not using old-school WinAPI with GDI, but the stuff they added later is also rather stable. For example, the Chromium-based browser I’m looking at uses Direct3D 11 for graphics. It implements a few abstraction layers on top (ANGLE, Skia) but these are parts of the browser not the OS. I view all that modern stuff…
These are however the same on Linux - mesa may change, but what the app uses is OpenGL and GLX. A more modern app might use EGL instead of GLX, or have switched to Vulkan, but that doesn't break old code. You can also run an old mesa from the time the app was built if it supports your newer hardware, but I'd rather consider that to be part of the platform the same way you'd consider the DirectX libraries to be part o…
An example from another comment: https://news.ycombinator.com/item?id=43519949
Earlier quoted context omitted.
>Aren't .class and .jar files "binaries"? Not at all. jar is just a zip with a different extension +some metadata in META-INF (including dependencies). class are compiled java files but they do contain all kinds of metadata, including variable names and debug info (if you choose to retain it). they contain all methods and fields with their original names (along with annotations), so the reflection APIs work. Decompil…
Java can be optimized beyond all recognition, into bytecode that can no longer be represented by the Java language. At least that used to be the case in the past. It is not different from other binaries, except the target system is a virtual CPU rather than a real one. Java also deprecated all sorts of things over the years. Not to mention applets being completely killed off. I have Java binaries from 25 years ago th…
I am not sure how that works, Java is all about JIT. Bytecode almost doesn't matter. Personally I can read assembly (and years [decades] back could just read hex). So even obfuscated (not optimizied) Java is quite readable. Still, the class files do retain all method declarations, all constant pool entries and all bytecode (again trivial to decompile). There have been few changes in the class format of course.
> Java binaries from 25 years ago that could no longer run at all with a contemporary run-time already 10-15 years ago.
Need a shorter frame, Java 8 (10y back) could run pretty much anything from java 1.0 (or even 0.9). It's quite more recent - Java 9 (2017) that introduced project jigsaw. Prior that Java was by far the most backward compatible platform. Still is, for most applications. Do note deprecation mean(t) - do not use in new projects, not it has been removed; again those are more recent changes.
>Not to mention much of real-world Java is platform-specific.
Again, that's super rare nowadays. Stuff like zstd might load a library but even then the native code interfaces are the same across pretty much all platforms. If you talk about native UIs you might have some point, of course.
>to properly use the correct path-separator.
Windows with its backslash is notorious, yet - there is no reason to use backslash any longer, for like 25years now. All Windows paths do work with forward slash (aside that the separator is readily available in java.io.File)
Earlier quoted context omitted.
> That makes no sense: shipping all dependencies (e.g. shipping a container image) gives perfect binary compatibility on Linux, which is what flatpak/snap/appimage do. True, but sad. The way to achieve compatibility on Linux is to distribute applications in the form of what are essentially tarballs of entire Linux systems. This is the "fuck it" solution. Of course I suppose it's not unusual for Windows stuff to be st…
You could say the same about container images for server apps. (Packaging is hard.)
They do it by having standards in the OS, partial containerization, and above all: applications are not installed “on” the OS. They are self contained. They are also jailed and interact via APIs that grant them permissions or allow them to do things by proxy. This doesn’t just help with security but also with modularity. There is no such thing as an “installer” really.
The idea of an app being installed at a bunch of locations across a system is something that really must die. It’s a legacy holdover from old PC and/or special snowflake Unix server days when there were just not many machines in the world and every one had its loving admin. Things were also less complex back then. It was easy for an admin or PC owner to stroll around the filesystem and see everything. Now even my Mac laptop has thousands of processes and a gigantic filesystem larger than a huge UNIX server in the 90s.
Earlier quoted context omitted.
At this point nobody is going to learn a new system. People already know how to write and package exes which is the whole point. > but the hacks used to make one app work can break others and vice versa I think a lot of these problems could be avoided with a singular OS with the sole goal to support windows exes.
That exists, it’s called SteamOS.
Java already solved this problem, for the most part. This whole ABI nonsense really grinds my gears. It's essentially just a result of the silly decision to compile software into dubious blobs and ship those to users. You could get rid of an awful lot of malware and massively simplify software distribution if you were to distribute a platform agnostic intermediary representation of source code that preserves enough s…
java classes have "abi". any binary representation of executable code that is supposed to be interacted with by other code necessarily defines an application BINARY interface.
I don't think a new distro is needed. Most commonly used windows apps can be made to work through wine, but the hacks used to make one app work can break others and vice versa. Similarly, everyone needs to play around with settings individually to get things to work. What works on one person's machine might not work on another's, because there's no consistency in, effectively, configuration. The simplest solution, to…
The concept of containers for Windows applications running in WINE is called "bottles." https://support.codeweavers.com/en_US/2-getting-started/2-in... I believe it started with Cedega, but I could be wrong. That's where I first recall encountering it.