So? Why would not you just download the source-code and compile it yourself?
Because you would have to put a Chromebook into developer mode to install an unofficial kernel. A security feature in the Chromebook firmware allows anybody who turns on a Chromebook in developer mode to powerwash it by turning it on, pressing Space as prompted, and pressing Enter as prompted. This causes you to lose the day's work that you haven't yet been able to back up remotely and lose the use of the modified Chrome OS until you have a chance to reinstall it. (See "Chromebook Developer Mode Warning".)
If your hypervisor can translate between USB on the host and whatever Windows 95 expects on the guest, there shouldn't be a problem with using USB peripherals with Windows 95. It could present keyboard and mouse as PS/2 and present USB mass storage as a network drive.
(Yes, I'm aware hypervisors didn't exist back then, but they do now.)
Linux itself can load only static ELF (and static a.out, which is obsolete). An executable in PE format is not "native compiled" in the sense that it has to be loaded into RAM by the userspace program wine. Likewise, an executable in dynamically linked ELF format is not "native compiled" in the sense that has to be loaded into RAM by the userspace program ld-linux.so.2. But once the program is loaded, there is no interpretation or dynamic translation of x86 or x86-64 instructions, just library calls.
We appear to disagree on definitions. In order to help me (and other readers) understand the definitions that you are implicitly assuming, please answer me this: If a program is shipped as a dynamically linked ELF that uses Winelib, would you consider it "native compiled"? Why or why not?
How the hell does a student pay tens of thousands of dollars a semester to learn how to computer, yet never get taught the basics?
By attending a school that doesn't provide a remote repository host for its software engineering students to use. Though Git can work purely locally, backing up a repository to a zipfile on a FAT32-formatted USB flash drive isn't the most convenient way of planning for possibility of media failure.
How much of that is because the application side of it was written in a language that has neither a 64-bit integer type nor an unsigned 32-bit integer type? PHP, for example, has no 64-bit integers unless it's running on a 64-bit architecture, and last I checked, a lot of virtual private servers were 32-bit in order to fit more pointer-heavy data sets in RAM without having to expand to the next larger size (and next larger price) VM. Has this changed recently, to where even 512 MB to 1 GB VPSes are 64-bit?
You're comparing a set of libraries that (GTK/QT) that you install on a BSD/linux/whatever system
Wine is a set of libraries too: sudo apt install wine-development
which a natively compiled
Wine is also natively compiled for x86 and x86-64 architectures.
intended to be there
If it weren't "intended to be there", I don't see why it would be in the default repositories of major desktop X11/Linux distributions, ready for the administrator to install.
with an entire emulation layer that emulates / translates everything from a network stack
You're correct that paravirtualization, which modifies the kernel to accept a simplified machine model presented by the VMM, blurs these lines. But historically, publishers of proprietary operating systems have been hostile toward production use thereof as a guest under paravirtualization.
The other big differences:
1. Wine is $119.99 cheaper than Windows in a VM. It'd be technically possible to automatically provision a VM on the user's machine on demand, but I doubt that Valve would want the legal hassle associated with becoming a reseller of Windows licenses on Steam. 2. Valve and application developers can debug deeper into Wine than they can into Windows.
Ideally, you'll be using one frozen version of one browser to view the few sites that use Flash Player and a different browser to view the vast majority of sites that use HTML. Would this be an acceptable use paradigm for most people who need to work regularly with legacy Flash sites?
The rights of one party act as restrictions on others.
In DRM, the majority of people act as the restricted party, not the party with rights. Therefore, DRM is "digital restrictions management" for more parties than it is "digital rights management".
If I have the right to life, you are prohibited from killing me. If I control copyright on a work, you are prohibited from copying it without permission.
The prohibition of murder isn't quite the best example. In the case of copyright, far more parties are affected by the restrictions than enjoy meaningful exercise of the rights. This imbalance does not apply to the prohibition of murder.
If an app's developer or distributor explicitly supports use of the app in Wine, you can add "installing a Wine app" to that list. The featured article is about a distributor adding such support.
Not only am I fairly sure that's now how the software stack looks so the latter may not exist/disappear and the software can still function
The EULA is the only way you have any rights to the software *at all*.
Without a EULA, the software would be subject to the statutory rules of software copyright. In the United States, these rules carve out exceptions for the owner of a lawfully made copy to do the following:
- resell that copy (17 USC 109); - copy the software into RAM to execute it (17 USC 117(a)(1)); and - make private backup copies, but not distribute those copies to others (17 USC 117(a)(2)).
GTK+ is also "a translation layer" that takes GTK+ calls and maps them onto Xlib. It also has some "quite complex logic", such as the GIO sitting on top of the Linux file system and network interfaces. And just as Wine maps Windows threads onto POSIX threads, GLib provides GLib threads that map onto POSIX threads (under Linux) or Windows threads (under Windows).
It would be like if you took that Xlib API, but instead talking to the Xlib library it self, you talk to a separate layer that takes in Xlib API and translates it into something that is displayed using openGL, running on SDL
Or shorter: "an X server that uses SDL for output," like the "XServer XSDL" app for Android. That and the "GNURoot Debian" app are necessary in order to get existing applications running on some popular Linux-based distributions, as they come with Linux proper (a kernel) but not GNU or X.
the developer ships Win32 binaries tested on both Windows and Wine.
The difference is an app directly targets GTK and if xlib changes GTK wraps that.
The situation I tried to pose is one where an app directly targets Wine alongside Windows. Then if Xlib changes, Wine wraps that. How could I have got that across better?
That depends to an extent on whether you saw a tailor or bought off the rack.
They don't hide your shape or size
With exceptions. For the past several decades, a lot of money in the fashion industry has gone toward hiding the overweight brought on by the modern American diet. The loose clothing commonly associated with the Middle East hides the shape of the body for two reasons: as a side effect of "chimney effect" convective cooling design for hot weather and (allegedly) to distract the brain from sexual desire. The loose ankle-length vestments worn by Catholic clergy have a similar distractive effect. The hoop skirts popular in the 16th century and the 1860s made a woman's hips look bigger, and a reenactor told me that men preferred large hips in a wife because large hips are correlated with less risk of CPD and other complications that would interfere with birth of the pair's children.
Likewise, libraries such as Xlib and PulseAudio hide the fact that a machine has only one video output and only one stereo audio output by dividing up the video and mixing the audio from multiple applications.
An giraffe costume isn't a natural fit for you
That depends on whether you bought an off-the-shelf fursuit or commissioned a custom one.
Qt apps never link to GTK+ libraries. Both Qt and GTK+ sit on top of a window manager, to which they link, in addition to many other low level libraries such as Xlib.
Likewise, Wine sits on top of a window manager, to which it links, in addition to many other low level libraries such as Xlib. In my mind, this makes Wine a widget set, little different from Qt or GNUstep.
Different people have different opinions on the philosophical question of what an operating system comprises. As long as defining "operating system" is hard, defining "native" will also be hard. These questions should help determine where one might draw the line:
Is an executable loader part of "the operating system"? In Linux, executable loaders are not part of the kernel except in the special case of a statically linked ELF. Everything else, such as Wine's PE format or an ELF that uses a shared library, goes through userspace. Dynamic ELF goes through ld-linux.so.2, whereas PE goes through the kernel's "binfmt_misc" mechanism, which launches Wine once that is configured.
Is Winelib "native"? Would Wine be native if executables shipped in ELF format linked to Winelib, as opposed to relying on binary compatibility with Windows PE format? And does the answer differ any for GNUstep?
One, AFAIK Qt apps aren't "on" a GTK+ system, so I'm not sure on what you're trying to drive at here.
I have used the name "GTK+ apps on a Qt system" to describe the result of the following steps:
1. Install Kubuntu or any other KDE Plasma distribution on a PC. 2. Discover that Krita doesn't do indexed color and install GIMP through the distribution's package manager.
I have used the name "Qt apps on a GTK+ system" to describe the result of the following steps:
1. Install Ubuntu, Xubuntu, Linux Mint, or any other GNOME 3, Xfce, or Cinnamon distribution on a PC. 2. Discover that GIMP doesn't do adjustment layers and install Krita through the distribution's package manager.
I personally would draw one line between Wine ("Wine is not an emulator") and a same-architecture VMM such as VirtualBox and another line between a same-architecture VMM and an actual emulator.
Also, is this some kind of secret advertisement for Qt?
No. I'm just stating the view that Wine is a UI toolkit with a PE loader. Just as LessTif reimplements Motif API and GNUstep reimplements Cocoa API, Wine reimplements Win32 API. This makes it in theory no less native than any other UI toolkit that your desktop environment happens not to use.
- If you run a KDE Plasma desktop environment, apps using GTK+, Motif, or GNUstep are just as non-native as apps using Wine. - If you run GNOME, MATE, Cinnamon, Xfce, or LXDE, apps using Qt, Motif, or GNUstep are just as non-native as apps using Wine.
Qt is commercial product, unlike GTK+ which has LGPL licence.
Slashdot Mirror
So? Why would not you just download the source-code and compile it yourself?
Because you would have to put a Chromebook into developer mode to install an unofficial kernel. A security feature in the Chromebook firmware allows anybody who turns on a Chromebook in developer mode to powerwash it by turning it on, pressing Space as prompted, and pressing Enter as prompted. This causes you to lose the day's work that you haven't yet been able to back up remotely and lose the use of the modified Chrome OS until you have a chance to reinstall it. (See "Chromebook Developer Mode Warning".)
If your hypervisor can translate between USB on the host and whatever Windows 95 expects on the guest, there shouldn't be a problem with using USB peripherals with Windows 95. It could present keyboard and mouse as PS/2 and present USB mass storage as a network drive.
(Yes, I'm aware hypervisors didn't exist back then, but they do now.)
Last I checked, Python still supported any web server that could speak CGI or WSGI. Apache can speak both.
I would expect a simple update guide with breaking changes and simple resolutions.
Expected it, got it. Google Search for php 7.0 breaking changes returned this section of the official migration guide as the first result.
Linux itself can load only static ELF (and static a.out, which is obsolete). An executable in PE format is not "native compiled" in the sense that it has to be loaded into RAM by the userspace program wine. Likewise, an executable in dynamically linked ELF format is not "native compiled" in the sense that has to be loaded into RAM by the userspace program ld-linux.so.2. But once the program is loaded, there is no interpretation or dynamic translation of x86 or x86-64 instructions, just library calls.
We appear to disagree on definitions. In order to help me (and other readers) understand the definitions that you are implicitly assuming, please answer me this: If a program is shipped as a dynamically linked ELF that uses Winelib, would you consider it "native compiled"? Why or why not?
A Windows 10 Home license for a home-built PC costs $119.99.
How the hell does a student pay tens of thousands of dollars a semester to learn how to computer, yet never get taught the basics?
By attending a school that doesn't provide a remote repository host for its software engineering students to use. Though Git can work purely locally, backing up a repository to a zipfile on a FAT32-formatted USB flash drive isn't the most convenient way of planning for possibility of media failure.
How much of that is because the application side of it was written in a language that has neither a 64-bit integer type nor an unsigned 32-bit integer type? PHP, for example, has no 64-bit integers unless it's running on a 64-bit architecture, and last I checked, a lot of virtual private servers were 32-bit in order to fit more pointer-heavy data sets in RAM without having to expand to the next larger size (and next larger price) VM. Has this changed recently, to where even 512 MB to 1 GB VPSes are 64-bit?
You're comparing a set of libraries that (GTK/QT) that you install on a BSD/linux/whatever system
Wine is a set of libraries too: sudo apt install wine-development
which a natively compiled
Wine is also natively compiled for x86 and x86-64 architectures.
intended to be there
If it weren't "intended to be there", I don't see why it would be in the default repositories of major desktop X11/Linux distributions, ready for the administrator to install.
with an entire emulation layer that emulates / translates everything from a network stack
glib-networking
mouse/[...]/keyboard
GTK+ event handling
modem
NetworkManager
video
GDK, Cairo, GtkGLArea
and the list goes on
I'll gallop with you further if you want.
You're correct that paravirtualization, which modifies the kernel to accept a simplified machine model presented by the VMM, blurs these lines. But historically, publishers of proprietary operating systems have been hostile toward production use thereof as a guest under paravirtualization.
The other big differences:
1. Wine is $119.99 cheaper than Windows in a VM. It'd be technically possible to automatically provision a VM on the user's machine on demand, but I doubt that Valve would want the legal hassle associated with becoming a reseller of Windows licenses on Steam.
2. Valve and application developers can debug deeper into Wine than they can into Windows.
So guess what I'll be changing? The browser.
Ideally, you'll be using one frozen version of one browser to view the few sites that use Flash Player and a different browser to view the vast majority of sites that use HTML. Would this be an acceptable use paradigm for most people who need to work regularly with legacy Flash sites?
The rights of one party act as restrictions on others.
In DRM, the majority of people act as the restricted party, not the party with rights. Therefore, DRM is "digital restrictions management" for more parties than it is "digital rights management".
If I have the right to life, you are prohibited from killing me. If I control copyright on a work, you are prohibited from copying it without permission.
The prohibition of murder isn't quite the best example. In the case of copyright, far more parties are affected by the restrictions than enjoy meaningful exercise of the rights. This imbalance does not apply to the prohibition of murder.
Installing a GTK+ app or installing a Qt app.
If an app's developer or distributor explicitly supports use of the app in Wine, you can add "installing a Wine app" to that list. The featured article is about a distributor adding such support.
Not only am I fairly sure that's now how the software stack looks so the latter may not exist/disappear and the software can still function
Likewise, Wine's GDI is flexible enough to be adapted to Wayland or other non-X graphics stacks.
The EULA is the only way you have any rights to the software *at all*.
Without a EULA, the software would be subject to the statutory rules of software copyright. In the United States, these rules carve out exceptions for the owner of a lawfully made copy to do the following:
- resell that copy (17 USC 109);
- copy the software into RAM to execute it (17 USC 117(a)(1)); and
- make private backup copies, but not distribute those copies to others (17 USC 117(a)(2)).
GTK+ is also "a translation layer" that takes GTK+ calls and maps them onto Xlib. It also has some "quite complex logic", such as the GIO sitting on top of the Linux file system and network interfaces. And just as Wine maps Windows threads onto POSIX threads, GLib provides GLib threads that map onto POSIX threads (under Linux) or Windows threads (under Windows).
It would be like if you took that Xlib API, but instead talking to the Xlib library it self, you talk to a separate layer that takes in Xlib API and translates it into something that is displayed using openGL, running on SDL
Or shorter: "an X server that uses SDL for output," like the "XServer XSDL" app for Android. That and the "GNURoot Debian" app are necessary in order to get existing applications running on some popular Linux-based distributions, as they come with Linux proper (a kernel) but not GNU or X.
the developer ships Win32 binaries tested on both Windows and Wine.
The difference is an app directly targets GTK and if xlib changes GTK wraps that.
The situation I tried to pose is one where an app directly targets Wine alongside Windows. Then if Xlib changes, Wine wraps that. How could I have got that across better?
Your clothes are made to fit you.
That depends to an extent on whether you saw a tailor or bought off the rack.
They don't hide your shape or size
With exceptions. For the past several decades, a lot of money in the fashion industry has gone toward hiding the overweight brought on by the modern American diet. The loose clothing commonly associated with the Middle East hides the shape of the body for two reasons: as a side effect of "chimney effect" convective cooling design for hot weather and (allegedly) to distract the brain from sexual desire. The loose ankle-length vestments worn by Catholic clergy have a similar distractive effect. The hoop skirts popular in the 16th century and the 1860s made a woman's hips look bigger, and a reenactor told me that men preferred large hips in a wife because large hips are correlated with less risk of CPD and other complications that would interfere with birth of the pair's children.
Likewise, libraries such as Xlib and PulseAudio hide the fact that a machine has only one video output and only one stereo audio output by dividing up the video and mixing the audio from multiple applications.
An giraffe costume isn't a natural fit for you
That depends on whether you bought an off-the-shelf fursuit or commissioned a custom one.
So is Wine for the furry fandom? ;-)
Qt apps never link to GTK+ libraries. Both Qt and GTK+ sit on top of a window manager, to which they link, in addition to many other low level libraries such as Xlib.
Likewise, Wine sits on top of a window manager, to which it links, in addition to many other low level libraries such as Xlib. In my mind, this makes Wine a widget set, little different from Qt or GNUstep.
Different people have different opinions on the philosophical question of what an operating system comprises. As long as defining "operating system" is hard, defining "native" will also be hard. These questions should help determine where one might draw the line:
Is an executable loader part of "the operating system"? In Linux, executable loaders are not part of the kernel except in the special case of a statically linked ELF. Everything else, such as Wine's PE format or an ELF that uses a shared library, goes through userspace. Dynamic ELF goes through ld-linux.so.2, whereas PE goes through the kernel's "binfmt_misc" mechanism, which launches Wine once that is configured.
Is Winelib "native"? Would Wine be native if executables shipped in ELF format linked to Winelib, as opposed to relying on binary compatibility with Windows PE format? And does the answer differ any for GNUstep?
One, AFAIK Qt apps aren't "on" a GTK+ system, so I'm not sure on what you're trying to drive at here.
I have used the name "GTK+ apps on a Qt system" to describe the result of the following steps:
1. Install Kubuntu or any other KDE Plasma distribution on a PC.
2. Discover that Krita doesn't do indexed color and install GIMP through the distribution's package manager.
I have used the name "Qt apps on a GTK+ system" to describe the result of the following steps:
1. Install Ubuntu, Xubuntu, Linux Mint, or any other GNOME 3, Xfce, or Cinnamon distribution on a PC.
2. Discover that GIMP doesn't do adjustment layers and install Krita through the distribution's package manager.
What would be better names for these situations?
Ultimately, I guess what is native then?
I personally would draw one line between Wine ("Wine is not an emulator") and a same-architecture VMM such as VirtualBox and another line between a same-architecture VMM and an actual emulator.
Cocoa is the new name for OpenStep. What you're saying is as if macOS were substantially different from OS X.
Yes. It involves a $5 deck of cards and $800 worth of airfare to get you in the same room as your opponents.
Also, is this some kind of secret advertisement for Qt?
No. I'm just stating the view that Wine is a UI toolkit with a PE loader. Just as LessTif reimplements Motif API and GNUstep reimplements Cocoa API, Wine reimplements Win32 API. This makes it in theory no less native than any other UI toolkit that your desktop environment happens not to use.
- If you run a KDE Plasma desktop environment, apps using GTK+, Motif, or GNUstep are just as non-native as apps using Wine.
- If you run GNOME, MATE, Cinnamon, Xfce, or LXDE, apps using Qt, Motif, or GNUstep are just as non-native as apps using Wine.
Qt is commercial product, unlike GTK+ which has LGPL licence.
Qt has been LGPL since 2009 (source).