Wine Developers Concerned With Ubuntu Dropping 32-bit Support With Ubuntu 19.10 (linuxuprising.com) 209
An anonymous reader shares a report: The news that Ubuntu will drop support for the 32-bit x86 architecture was discussed recently by the Wine developers, on the Wine-devel mailing list. The Wine developers are concerned with this news because many 64-bit Windows applications still use a 32-bit installer, or some 32-bit components. "In practice, the only cases where 64-bit only wine will be useful are when 64-bit applications are packaged some other way (such as a .zip, Steam Play, or packaging specifically for Wine) or for running Wine builtins like msidb." Ubuntu's solution for using Wine on 32-bit going forward, which is to publish applications as snaps, or use an Ubuntu 18.04 LTS based LXD container that has full access to multiarch 32-bit WINE and related libraries, was also discussed by the Wine developers, with Vincent Povirk of CodeWeavers saying that there's no point putting much effort into this temporary solution. The maintainer of the Wine OBS repository also mentioned that he has no interest in maintaining so many libraries.
Start Looking for Another Distribution (Score:1)
If this flows down to Mint, etc., start planning your migration.
Glad I got out of Ubuntu when they tried to shove Unity down my throat.
Re: (Score:2, Informative)
I also model my embedded systems and conduct unit tests on the Linux build machines as part of my validation/test strategy. Th
Re: (Score:2)
Re: (Score:2)
I think the OP is referring to proprietary toolchains that support a variety of embedded systems these days. I'm sure these vendors could easily produce 64-bit binaries of their cross compilers, though.
Re: (Score:2)
You've probably never worked with embedded systems.
One of our clients is using a TI chip that requires a custom TI compiler, provided by TI. It doesn't even do C99. It sort of does "Embedded C++" but that standard died in 2002.
Nobody's going to update this toolchain.
Re: (Score:2, Insightful)
Because...
1> People are actually using it.
2> Nobody is rewriting the software they use so they're stuck.
3> Newer isn't always a good thing when something just works.
4> Costs of migrating.
If it's bad enough the dropping of 32 bit from Ubuntu will result in Ubuntu getting dropped and losing people to other distros who pick up the slack and then move in Ubuntu's other areas pushing them out of business eventually.
Re: (Score:2)
Then use Debian. All Ubuntu is, at the end of the day, is a set of repositories. There's not much to stop anyone from building a Debian system and throwing in the packages they want. Honestly, I haven't used Ubuntu in at least six or seven years, and just went to using straight Debian installs. I haven't quite sorted out why anyone would still use Ubuntu.
Re: (Score:1)
If your preferred desktop wasn't GNOME 2 then there was quite a gap between when Canonical dropped GNOME 2 and when MATE packages appeared. I'm glad your preferred desktop was supported but for a while, the default install was Unity vs crippled GNOME 3.
Just to clarify... (Score:5, Informative)
This isn't about dropping support for 32 bit kernel, and 32 bit packages, it's dropping support for any 32 bit compatibility libraries. Dropping the 32 bit install and kernel makes sense. Personally I don't have any 32 bit only computers anymore, and haven't for at least 10 years.
Dropping support for 32 bit compatibility libraries is a little odd, especially since Debian, from which Ubuntu is derived is still supporting 32 bit.
Re: (Score:1)
Then some other distribution will pick up the slack from Ubuntu.
Re: (Score:2)
> pick up the slack from Ubuntu.
I see what you did there. I think...
Re: (Score:2)
There IS a real cost to Canonical doing that. It requires resources to keep it building, to maintain it, to test it, to figure out what went wrong when something inevitably does. It's not "free" and that time and effort comes out of support for modern 64 bit architectures which are what almost everybody is using now.
Well shit there is a cost to every course of action and inaction. Unless you are willing to characterize actual costs and contrast it with actual benefits no objective information is being conveyed by your statements.
TL;DR (Score:3)
So let's see... (Score:1)
Right. So the OS devs should just support 32 bit and relieve you of the need to do it? What's wrong with virtualization/containerization of a 32-bit compatible release if you really really need a Windows XP era app to run under Wine?
The user story that the Wine devs are wringing their hands over has to be a tiny and rapidly shrinking target. Most people I have known over the years that run setu
Re:So let's see... (Score:5, Informative)
You could you know, read at least the summary.. Even modern Windows games released tomorrow and most applications still have 32bit installers.. So you need 32-bit support to run pretty much ALL windows application regardless of whether they otherwise have 64-bit binaries.
Also It is easier for the distro to still build the 32bit packages. They also need them to still support steam, many of my gog games, and anything else ever distributed in binary form on Linux..
Or you know they can SUCK
Which we are warning them they will.
Re: (Score:1)
These companies had a decade to fix the problem. Fuck em if they can't get with the times.
Re:So let's see... (Score:4, Interesting)
These companies had a decade to fix the problem. Fuck em if they can't get with the times.
What companies, what problem?? The only problem here is Ubuntu breaking support for existing binaries.. Binaries, being binary are not somthing that magically changes, no matter how much you believe in magically fairies fixing things.
Re: (Score:2)
A decade to find a 64 bit installer executable. Most of those installers are sold by third parties anyhow.
Re: (Score:2)
And the problem is where? The driver is where? Up until today there hasn't been the slightest talk of any OS dropping support for executing 32bit binaries. Up until *today* there hasn't been a problem that needed solving.
Re: (Score:2)
A decade to find a 64 bit installer executable. Most of those installers are sold by third parties anyhow.
That would at most fix it for new games... What about stuff we already own?
Re: (Score:2)
A decade to find a 64 bit installer executable. Most of those installers are sold by third parties anyhow.
And why would they do that? Where did you see that Microsoft is planning to drop 32 bit support in Windows?
Re: (Score:2)
These companies had a decade to fix the problem. Fuck em if they can't get with the times.
Some of these companies are gone and they're not fixing anything, but we still want to run the binaries. It's not a Linux problem, it's an Ubuntu problem, and if they want to be a problem then the easiest way to solve the problem is to use a different Debian derivative.
Comment removed (Score:4, Insightful)
Re:So let's see... (Score:4, Informative)
On a different note, a question for Slashdot, not you necessarily (seeing as I don't think you read the summary), how practical would it be for Wine to statically link the 32 bit GNU/Linux libraries it needs for 32 bit components of the system, or are there too many executables in the 32 bit Wine chain for that to work?
The main issue with that is the task would fall on the distros package maintainer to do.
The same maintainers that have no interest in keeping the 32 bit library packages in the first place.
If they did nothing, no exerting effort, so far as leaving the library packages for wine to use, there wouldn't be a problem.
They are exerting effort to go about removing those libraries so they aren't available.
I would take that as a sign they would also not want to statically include them either, since they would still "exist" which is counter to their goals.
Even if they did, we all know why it's not a great idea to do. You end up with a bunch of library versions you can't easily upgrade, exposed to windows executables :P
I also learned something recently that's related somewhat.
A statically compiled executable built on a 32 bit system, will run fine on a pure 64 bit system, so long as that 64 bit kernel has the CONFIG_IA32_EMULATION option enabled.
I don't know if Ubuntu plans to do that or not with their stock kernel moving forward.
Now that said, the libs I used were really simple ones: libc, libz, and libm
I have no idea how that will fall apart once you start using more complex things with their own dependencies.
Wine sounds to me like it would go quite deep down that rabbit hole.
Would the X11 libs need statically linked too? That sounds utterly terrifying!
Re: (Score:2)
Last time I checked Wine cannot be linked statically.
You cannot statically link NVIDIA Open GL libraries.
You don't want to statically build anything at all, 'cause it will be a nightmare to maintain, distribute and update.
Re:So let's see... (Score:5, Insightful)
As long as Windows continues to support 32-bit apps, WINE needs to support them. It's not trivial to port WIN32 code to WIN64 (perhaps not that hard, but not trivial), and chicken-and-egg considerations mean a lot of code isn't going to get ported until Microsoft drops 32-bit support. So why should Ubuntu drop it arbitrarily when the market still needs it? That doesn't mean the 32-bit libraries need to be installed by default (they aren't now). But continuing to maintain them doesn't hurt - the hard work of dealing with multiple sets of libraries has already been done. Seriously, this reeks of a Jobs-like 'we're so great, we can force you to upgrade stuff you didn't think you needed to' hubris. Ubuntu is no Apple - it doesn't have a dedicated fan base with no alternatives. Get over it.
And Snap is a lousy solution. I don't know why Canonical continues to stress it. Snaps add bogus filesystems to your system - for what? Sure, it makes it easy for 3rd parties to support multiple distros. But for open source code that can be built by the distros and included in their repositories, recommending Snaps is idiotic. Ubuntu already has a bunch of packages available in both formats - which is both confusing and counterproductive.
Ironically, WINE has helped make WIN32 the most portable binary format around. Sure, it's a stopgap for most Ubuntu users, but as far as checking the 'you can continue to use that odd Windows-only app you rely on' box, it's vital. Canonical could do a lot worse than to contribute to the efforts of the WINE developers and work to make WIN32 apps integrate even better into the Ubuntu desktop. I use a few, and they work pretty well. Only issues are minor ones with fonts, occasional problems with Alt-Tab leaving WINE thinking the Alt key is stuck on, and of course themeing support, which is still pretty dreadful. But if you need the app, you need the app...
Re: (Score:2)
Sure, it makes it easy for 3rd parties to support multiple distros. But for open source code that can be built by the distros and included in their repositories, recommending Snaps is idiotic.
So it makes it easier for 3rd parties to support multiple distros but it would be idiotic to do so?
Snap wasn't created in a vacuum, and also wasn't the only container created for that matter. It solved a very real distribution problem that exists in Linux, not the least of which is problems with the maintainer managed, developer bypassed distribution model.
Re: (Score:2)
I said it's fine for 3rd party apps. It's the open source stuff that Canonical provides in its native repos as well as in snaps that makes no sense to me. Snaps are a clumsy way to get around the need to compile natively for a specific distro - but if the distro is already compiling an app natively, then surely that's preferrable to using a snap-distributed version, no?
Re: (Score:2)
Huh? I'm running 32 bit apps on a default Windows 10 install, and I don't recall ever having a dialog box pop up demanding I install 32-bit support. Now it may come to pass if Windows ever makes any significant penetration in non-x86/x64 architecture that we'll face having to manually install compatibility layers, and MS, so far as I understand it, has that plan in place. In the long run, x86 processors will face, leaving x64, ARM and whatever else comes along, so there will be a sunset for 32 bit support o
Re: (Score:2)
The GP was confused. Running 16bit packages requires manual support in Windows 10. That support is installing NTVDM which installs 32bit libraries that include 16bit support.
Re: (Score:2)
32-bit support requires manual intervention on Windows 10
No it doesn't. *16-bit support* requires manual intervention on Windows 10.
Re: (Score:2)
But I do wish they'd finished supporting MSWin95 before losing interest in it. As it is many programs that I wanted to use are basically unusable. (I never bought anything for those later versions.)
This is why Microsoft gets away with Windows 10 (Score:4, Insightful)
That's odd to think about it that way (Score:2, Informative)
Because Linux works on much older and more varied hardware, with those variations being actively maintained and supported. There are also LTS variants of Linux.
On the other hand Windows has changed driver models dropping support for tons of hardware multiple times, they dropped Win16 support, DOS support is horrible under Windows, we use tons of third party tools and shims to get old programs and games to work...
What was your point again?
Re: (Score:2)
Win16 works just fine - on Windows 10 it loads up NTVDM and runs under that. Of course, it only works on the 32-bit version of Windows 10, because of the way x64 works. When you run in x86 mode, you can run in 16 or 32 bit mode (x86 was always a 16-bit pro
Four words (Score:5, Insightful)
Microsoft is there for you as long as your money spends. Currently they're killing IE and replacing it with Chrome because it's no longer worthwhile to dominate the browser market. There's more money in their own web apps then there is stopping other's from doing it.
Re: (Score:1)
Dude we are literally talking about an example of this right here. The developers are dropping 32 bit support because they see no personal benefit from it and it makes their lives twice as easy.
Microsoft provides long term support for customers because they are paying for it.
Some random hardware maker from China, no they are not going to support the Windows drivers after they are no longer making money from the product. That seems to be what you're talking about.
Re: (Score:3)
Is ReactOS the one that is still in alpha after TWENTY TWO YEARS OF DEVELOPMENT? Just checking.
Re: (Score:2)
Is ReactOS the one that is still in alpha after TWENTY TWO YEARS OF DEVELOPMENT? Just checking.
Yeah, I had the same thought.
It started in 1996 or 2002 depending upon what you mean by "start", and it's as useless today as it was then. Oh sure, you can some stuff, but I doubt there's a single person on the planet actually using it.
ReactOS looks interesting, but whether or not it'll ever see the light of day in any meaningful way is dubious. The pace of development is glacial at best and even that's being generous.
I've been watching the ReactOS 'project' for over 15+ years and haven't seen a damn thing
Re: (Score:2)
Security issue in loading saved game (Score:2)
Many games let the player save the state of a campaign from one play session to the next. If a game's parser for its saved campaign files has a defect, loading a specially crafted malformed file can cause the game to execute code controlled by the author of the malformed file.
Re: (Score:2)
Did DOS ever really support 8 bit apps? Early versions did offer limited support for CP/M (I don't think DOS ever ran CP/M apps out of the box). It was always a 16-bit platform. That was the big selling point. You could buy PCs in the early 1980s that had 128k or more of RAM, whereas buying 8 bit machines of that era that supported more than 64k meant having a bank switching scheme (and yes, I know, 8086/88 had some pretty peculiar address modes, the legacy of which lasted a very long time until OS9 and Win
Re: (Score:2)
The IBM PC and the clones were the key transition point between the 8 bit era and the 16 bit era. They could could access more memory without funky bank switching logic
Not the actual IBM PC (5150)... it only had 64kB of RAM onboard. I believe you could double that by piggybacking, but my 5150 had an 8-bit AST card with 384kB and a RTC on it.
Re: (Score:2)
Those funky addressing modes would let the CPU run in 8-bit mode, backwards compatibility with the 8008 and all, but that's the CPU not DOS.
Are you sure it's compatible with the 8008? The references I've found suggest that it was not bytecode compatible, only source compatible. Are we counting that?
https://retrocomputing.stackexchange.com/questions/859/can-x86-processors-run-8-bit-applications
https://www.extremetech.com/computing/270926-happy-40th-anniversary-to-the-original-8086-and-the-x86-architecture
Who cares? (Score:2)
64 bit or bust.
No need to hold the rest of the world back over their BS.
Re: (Score:3)
Whose BS? No this wouldn't be holding back the rest of the world. And bust it could well be. This need to drag everyone kicking and screaming into the new, modern age (without a lot of tangible benefit), is a bit strange. As if 64-bit pure has some kind of magical properties.
Wine is probably one of the most important Linux projects, in terms of making Linux useful to the mainstream user. The fact that Ubuntu is removing all 32-bit multi-arch packages from the distro is a real dilemma. There are plenty
Re: (Score:2)
As if 64-bit pure has some kind of magical properties.
It doesn't, but it does have mundane properties which are beneficial, like not having to build or provide or support the 32-bit packages. On the other hand, I want to be able to run Wine without having to run a VM, so I find it objectionable. On the gripping hand, I already left Ubuntu, so this won't affect me.
Re: (Score:3)
Windows developers use 32-bit installers because they just work everywhere.
Windows will continue to support 32-bit packages.
If Ubuntu drops it then Windows developers aren't going to care. That's not their target market anyway. The only result is Linux users suffer.
Re: (Score:2)
64 bit or bust.
No need to hold the rest of the world back over their BS.
How does shipping the existing 32 bit support hold anything back?
Will 32bt VMs still work? (Score:2)
Question is arising for me on macOS, and seems like it might arise for me on Linux soon as well.
Re: (Score:2)
Re: (Score:2)
wine needs to do something (Score:2)
Re: (Score:1)
Why is this WINE's problem? WINE is just the most common issue for needing 32 bit compatibility. As an end user, of course I want 32 bit compatibility on my box. Every other distro doesn't seem to view this as a bugbear. Debian, which Ubuntu pulls from, doesn't have this problem. Fedora doesn't have this problem. This is an Ubuntu-specific issue.
Re: (Score:2)
The whole point is that 32 bit is decidedly not dead. Sure, nobody needs a 32-bit kernel, but as long as Linux wants to check the 'you can run those last few Windows apps you depend on' box (and, seriously, do you think Canonical can afford not to?), it needs WINE. I don't know if it's possilbe to build a 64 bit WINE capable of running Win32 binaries, but at least you seem to get that it's still necessary to support Win32 binaries somehow. So, given that, if Canonical wants to go 64-bit only, they ought
Re: (Score:2)
No, it is the goddamn distros problem. I have games I have bought for Linux, that are Linux native, but just happens to be 32bit. I expect them to run, why wouldn't they, x64 is fucking backwards compatible... A distro that breaks existing stuff for no fucking reason, can FUCK the FUCK off.
Re: (Score:2)
Re: (Score:2)
It's far more complicated than just cranking out a 64-bit binary with GCC. Wine implements a 32-bit Windows EXE loader that implements the 32-bit kernel and win32 api layers. Wine essentially passes API calls through think translation layers to Linux equivalents. Again the kernel is not the problem. 32-bit Wine already runs on 64-bit distros just fine, because of the multi-arch 32-bit libraries that are shipped on those distros.
Like I said before I would like to know more about the techical issues surro
Re: (Score:2)
It's far more complicated than just cranking out a 64-bit binary with GCC. Wine implements a 32-bit Windows EXE loader that implements the 32-bit kernel and win32 api layers. Wine essentially passes API calls through think translation layers to Linux equivalents. Again the kernel is not the problem. 32-bit Wine already runs on 64-bit distros just fine, because of the multi-arch 32-bit libraries that are shipped on those distros.
Like I said before I would like to know more about the techical issues surrounding Wind loading and running 32-bit code on 64-bit environments. What are precise the obstacles to having Wine load and run 32-bit EXEs on a 64-bit clean system? Could the translation thunk dlls be made to link to 64-bit Linux shared libraries?
I'm not likely to find the answer here. I will go check out the wine mailing list.
No. The application is either in x86 or x64 mode. You can't switch between the modes when calling to libraries, and there is no point in translating when calling the kernel as it can understand both. Wine would need to write the all wine 32bit APIs without using any libaries, not even the C library, to be able to run on a distro refusing to provide i686 basic libraries.
Re: (Score:2)
A distro that breaks existing stuff for no fucking reason, can FUCK the FUCK off.
Correct. So why are you mad?
There's no need to be upset. Just use a different distro-- it's not like you even paid any money since it's all free in the first place.
Worried the idea might be spreading, so we need to demonstrate our anger, and leave with the door slaming to discourage other distros from doing the same.
Red Hat 7 (Score:1)
Red Hat did this with RH7, and it was a cluster fuck. If not for the community run repos (which RH now controlls too), they'd have even less marketshare then they do because there is a _lot_ that depends on 32 bit.
It is of course an uphill battle you can't win with the kids running these projects no matter how hard you try. The idea for example that such applications are very real, mean nothing to them. Essentially they will deflect the arguments, calling them "legacy", or "insecure". I'm not talking
Re: (Score:2)
If you're talking about RHEL 7 (and its free clone CentOS 7), then they dropped the 32-bit version of the OS, but for the 64-bit OS kept the 32-bit multilib packages to allow 32-bit binaries to run. I have 64-bit CentOS 7 installed and run the 32-bit Steam client fine, along with 32-bit Windows/Linux games under Steam. The Ubuntu change will be massively different because they will not include the 32-bit multilib packages.
And that's not forgetting that RHEL is an enterprise distro where the number of users
Windows-like App Distribution (Score:2)
It's interesting that application distribution on Linux keeps getting more Windows-like.
Whether it's extracting an archive in /opt or one of those fancy "installer" systems like Snap or AppImage or even Docker images, the tendency of developers to ship all their required libraries and not rely on the libraries in the distribution's package manager is interesting. It's a bit like when Microsoft said that all of a program's libraries should be installed in "C:\Program Files" instead of dumped in "C:\WINDOWS"
Wow64 (Score:2)
Does this mean Wine now needs its own WOW64? Windows On Windows 64 is the mechanism of how 64-bit Windows runs 32-bit Windows programs.
Emulate ia32? (Score:2)
Are there substantive differences between ia32 and ia64 ISA's such that a 32-bit "MOV A, B" can't work in 64-bit registers, even with zero-padding?
I thought amd64 was mostly backwards-compatible with ISA, stack, and encodings. Somebody enlighten me on what's the big deal as I have been out of the assembly game for too long.
I do know it's really annoying to have to pull in and update a huge amount of ia32 arch to run a couple of tiny Windows apps. I can't imaging how many TB of data Debian handles just for
Next step... (Score:2)
Re: (Score:2)
Re:Fuck them (Score:5, Insightful)
Not supporting multiarch means users with older binaries are going to have to run then in a VM... or run something directly Debian-based. Either way, it's not a good look for Ubuntu, which is supposed to be the simple and easy Linux from the users' standpoint. If it hasn't got that, then it hasn't got any reason to exist.
Farewell, Ubuntu. Your time has come and gone.
Re: Fuck them (Score:4, Insightful)
sudo remount rw (Score:5, Informative)
You would have to be a moron to use live optical media in 2019.
Except for, say, dumping audio CDs for private use (in the USA and other countries that allow it).
Live USB images already mount their partitions read only.
There is no physical mechanism preventing a program running as the superuser from remounting the partition read-write. Nor am I aware of a mechanism preventing an unprivileged program from calling sudo to become the superuser: "In the liveDVD no password is required for authentication." [ubuntuforums.org]
In addition, a blank DVD is less expensive than a blank USB drive at stores I've visited. Am I visiting the wrong stores?
Re: (Score:2)
In addition, a blank DVD is less expensive than a blank USB drive at stores I've visited. Am I visiting the wrong stores?
Your security comment is right, your cost comment is way off. It doesn't make financial sense to use a DVD over a USB in terms of re-use. A DVD-RW closes that gap somewhat but at over $1 each they almost cost as much as a 4GB USB stick if you by the sticks in packs of 10.
Slow dial-up, ISDN, DSL; capped cell, sat (Score:2)
It doesn't make financial sense to use a DVD over a USB in terms of re-use.
Sometimes the author of a live OS mass-produces copies to distribute to the public. In the early days of Knoppix and the like, this was done because dial-up, ISDN, and 256-512K DSL were far too slow to send a gigabyte or two faster than the Postal Service. It continued for a few more years because of the anemic caps that satellite and cellular ISPs imposed on subscribers in areas outside the service footprint of fiber or cable. In this use case, re-use is not as much of a factor. This means the OS could be
Predefined password in live OS (Score:3)
No such switch has existed since floppy disks, get over it. They won't even give us one for the system firmware's EEPROM chip....
The mutability posed by lack of such a switch is a security issue. What means is there to "get over it" in light of the following?
There is one, it's called sudo. It asks for a password prior to granting privileges
The password of the user of a widely used live OS is predefined. This means a downloaded program running on a live OS can automatically provide this password to sudo.
and by default only users in a specific group are allowed to use it.
The user of a live OS is a member of that group. This means any downloaded program launched by the user of a live OS runs as a member of that group.
Re: (Score:2)
USB sticks have a history of losing data when left powered off for a few years. That's not a good substitute for a DVD for my usage...I'd do (well, actually I do, subjunctive is inappropriate) better to use a USB hard drive, though that's hardly cheaper.
Re: (Score:2)
If you say so, let me rephrase it.
*I* have had experience with USB sticks (flash drive) not being readable when I tried to read them again, after having been readable at one time. I have extremely rarely had that experience with CDs over a period of decades, and never had that experience with a much smaller sample of DVDs (though still larger than my sample of flash drives).
Also, others have reported on slashdot having similar experiences, though it's also true that at the same time some people have denied
Re: (Score:2)
You don't back up your install disks? Sorry, but I usually do. If something happens I want to be able to properly reinstall the same system. A couple of times I've totally borked the install, once by installing steam32 on a 64 bit system...I *should* have worked, according the what was said, but I needed to reinstall the system partition and forget about steam. (I haven't felt like trying it again. Perhaps I'm supposed to have some driver that I don't have, but it's not worth fighting through it.) Aft
Re: Fuck them (Score:4, Informative)
Re: (Score:2)
Sure. By all means. Absolutely. Linux distros should hamstring themselves (i.e: double testing & bug wrangling) to be backward compatible with Windows 2K & XP era Windows installer programs running in a Windows emulator. Brilliant.
Sure by all means. The primary concern should naturally be how much work distros have to do.
What I continually find myself amused by is fact many distros are packaging ancient versions of software they haven't bothered to pull current code for in years. Why doesn't this work... mailing lists the world over are full of "this was fixed years ago".
Re:Fuck them (Score:4, Informative)
That's technically true, but not practically true. Most software gains very little (more entropy in ASLR) from moving to using 64-bit pointers. Most software gains a lot from moving from x86-32 to x86-64 as the ISA. In particular, it gains a lot more registers (and, importantly, loses the restrictions on which instructions it can use). It gains cheap PC-relative addressing (i.e. shared libraries are a lot faster). It gains SSE2 as a baseline, so floating point operations and calling conventions are cheaper.
There's a good argument to be made for using the x32 ABI, but generally speaking x86-64 code with the 64-bit ABI will still be faster than x86-32 code using any ABI.
Re: (Score:2)
Faster, but more memory hungry.
Re: (Score:2, Insightful)
The people actually responsible (glibc, gcc/clang, wine, Debian packaging) do maintain these paths. Ubuntu barely has to do anything. Their not supplying the necessary libraries is just gratuitous, hurting users for.. vanity points?
x86-64 rocks (Score:2)
And it's not just the wider registers and bigger pointers. There are additional registers and new ways to access old registers. And the architecture change has allowed for a clean slate on calling conventions (ABI) and minimal level of supported instructions. (other than the stupid SYSCALL vs SYSENTER feud that Intel and AMD have)
Re: (Score:2)
It also actually has GPRs, unlike x86, where you have to use specific registers with most ops. Register renaming largely took care of the performance penalty, but then you just wound up with a CPU which actually has enough registers, but no way to address them directly even if you had a good reason to do so.
Re:Does anyone (Score:4, Insightful)
Everything.exe
I use it continuously to the near-total exclusion of file browsers for accessing files I'm working on. I've yet to find a similarly powerful native Linux search program, though suggestions are most welcome.
Key features:
> Lists all (account-accessible) files and folders on your computer at launch. A million files on your computer? Not a problem, they're all listed and sortable by any of the usual file properties (name, dates, size, path, etc.)
> Filters list to only those whose name contains the character sequences you type, as you type. That's essential since it lets you decide when to stop by the fact that you've found your file, rather than trying to guess as to how much information is necessary before you hit "search"
> No perceptible lag - starts up instantly, and filters the list just as fast as you type (sorting can take a few moments on huge lists, but I rarely actually do that). Hit a key, the list updates instantly, no "updating" delay as is so ubiquitous in every other search tool I've used.
That combination means that it's almost always substantially faster to launch, type a few key letter clusters until the list shrinks enough to quickly spot the file I want, and then open it (or its containing folder, depending on what I'm doing) than it would be to even select one of my most frequently used folders from a pop-up menu and then find the file in it by hand. Combined with getting in the habit of using descriptive file names, and I can find that file I worked on last year and saved in an obscure place just as fast and easily as the one I was working on this morning.
It's slightly clunkier on Linux than Windows, since it has to scan the file system in the background to find file system changes rather than being able to monitor the NTFS journal, but really that just means it has a bit more overhead and the list won't reflect the creation or deletion of files until the next scan, which is rarely a problem.
Re: (Score:2)
Thats one of the first things I install on any windows box.
Re: (Score:2)
I had not heard of it, and it does look extremely promising, thank you.
One question - all the screenshots I've seen show either single-word searches or more complicated regular expression ones. But does it handle multiple letter clusters well? E.g. if I type "svg ref tri" will it find "Trigonometry reference.svg"?
Re: (Score:1)
Games. In fact, some people use wine to make old games work better on Windows (ddraw "hacks": using wine's directdraw instead of Windows').
FCEUX for Windows (Score:2)
I use FCEUX, a debugging NES emulator, in my job making NES games. Two editions are provided: the Win32 edition, which has a debugger, and an SDL edition, which lacks a debugger. If I don't (think I) need the debugger for a particular run, I'll use the SDL edition, which starts faster. But if I do need the debugger, I will run the Win32 edition in Wine.
Other Windows programs installed on my PC that see fairly regular use FamiTracker (chiptune music sequencer), OpenMPT (sample music sequencer), and bgb (debu
Re: (Score:2)
in my job making NES games.
Interesting. Can you share what's your job? I didn't know you could live of programming for obsolete consoles.
Re: (Score:2)
I am credited as lead programmer for Haunted: Halloween '85 and Haunted: Halloween '86 (The Curse of Possum Hollow) by Retrotainment Games [retrotainmentgames.com], a unit of Cash-In Culture. I have also built the menu system for the Action 53 series of homebrew game anthologies and the companion cartridge for the VGBS podcast season 1.
Re: (Score:3, Insightful)
Consumer level 64 bit CPUs have been a thing since 2003 (and for much longer than that in the workstation sphere). That's 16 years now.
IPv6 has been a thing since 1998 (and for much longer than that counting RFC 1883). That's 21 years now.
It's time to let 32 bit go. If Windows is still clinging to 32 bit software, that's Windows' problem, but everything else moved over a long long time ago.
It's time to let IPv4 go.
Eventually the burden of maintaining old things becomes too large, especially for volunteers.
Can't even imagine what Linux kernel would be like without Linus to enforce some discipline.
It's about burdens instead of meeting requirements of end users? It's a hobby after all so we'll do as we please. Compiling a handful of user land libraries twice for Windows compatibility... PFFT ... who would ever want that? Who the hell uses Windows on the desktop? .. its so damn old
Re: (Score:2, Troll)
So your argument is that since IPv6 isn't being implemented, therefor Win32 should be maintained?
Not even close. Merely pointing out the absurdity of the underlying argument with an equally absurd counter example.
Also, if the WINE project isn't commercial and it is supported by contributions of time from programmers, then the programmers who want to maintain the Win32 libraries should step up and volunteer their time.
You don't seem to have a grasp of the underlying fundamentals. This isn't about win32 libraries it's about 32-bit user land Linux support libraries needed for 32-bit Linux applications to execute on the Linux platform. These libraries exist... most of the heavy lifting WRT 32-bit compatibility is actually implemented in the kernel. The problem is literally a refusal by a distro to package e
Re: (Score:2)
How many 8- and 16-bit games do you have? If more than zero, what do you use to run those, and what would be the analogous means to run 32-bit games?
Re: (Score:2)
How many 8bit and 16bit games require a 1GHz CPU or better?
A 16-bit Super Nintendo Entertainment System has a 3.58 MHz main CPU, a 1.02 MHz audio sub CPU, and a pair of PPUs that run at effectively 10.74 MHz. A few dozen games include an additional CPU, clocked at up to 21.47 MHz. Emulating this whole lot bug-for-bug may require 3 GHz, as explained in a story about bsnes [slashdot.org].
So, Windows 10 on ARM will be better at running 32bit x86 programs than Ubuntu on x86 will.
But how do end users obtain a license for Windows 10 on ARM to run it on, say, a Raspberry Pi or Pinebook computer? Or will it be sold only as part of a bundle with an "Always Connected PC", that i
Re: (Score:2)
Linux is a joke? It dominates the enterprise, runs on the majority of smart devices out there, a helluva lot of embedded hardware. You must also be the guy that swears up and down Java is dead so be sure to code in C#.
The joke here is to ignore the millions of devices that Linux, either as a kernel or as the kernel and GNU toolbox (or some fraction thereof), and declare that Linux is just for hobbyests. For fuck's sake, the beast dominates academia and industry.
Re: (Score:2)
Who really gives a crap about the desktop anymore? Not MS, Windows 10 is a bizarre clusterfuck that you end up having to run command line utilities to maybe fix if Cortana or the Start menu go haywire. I had to work on a couple of Win10 machines that, when they were joined to a new domain, wouldn't produce any results in the search bar/Cortana, and seemed to just sit there doing nothing for minutes at a time. I finally figured out that, for whatever reason, the indexer was trying to get in to an Admin profi
Which such emulator? (Score:2)
Let it be like 8 bit software: you can run it in an emulator if you insist
To run an 8-bit game on Ubuntu, I can install the fceux package, which contains an NES emulator, and then double-click any .nes executable in the file manager. To run a 32-bit game, I can currently install the wine32 package. However, this package is being dropped. The question raised by the featured article is what package replaces wine32.
Re: (Score:3)
Naw, I don't jump through hoops, I just type "wine LTspiceNNN.exe" and it runs.
Re: (Score:2)
From the summary it sounds like the problem is not getting a 32-bit WINE running, but rather the programs that are used with it. They are talking about things like program installers, etc.
Re: (Score:2)
But they don't ensure that anyone else's software will continue to run. So unless you only use MS software, be prepared to have your software break. (Actually, MS doesn't even always ensure that their own software continues to work...or at least some times it hasn't.)
That said, I've refused to have any dealings with MS for over a decade now (or Apple, either) so this is not an assertion about current policies. And I actually stopped using them over EULA changes rather than over their breaking software.