Use IUP? I know it's C but having used Qt and FLTK before (and looked into other GUIs) it seriously seems like one of the easiest to use out there (at the expense of making it harder to make heavily custom controls, but an emulator shouldn't need that).

I can't speak for byuu, but at least for me the problem is not that the GUI frameworks are hard to use, it's that doing user interfaces is really not much fun. If you talk about implementing a UI (i.e. you already know what you want), it's mostly grunt work. If you also have to design the UI, it's not easy, but at the same time it's also not a fun type of a challenge, at least for me.

It's very funny that you would get that impression of someone that's not anti-free at all? (Of all the regulars here, I'd guess that tepples is the most pro-free.)

In progressive politics, there are center left, hard left, and far left positions.In conservative politics, there are center right, hard right, and far right positions.And in software licensing politics, there are center free, hard free, and far free positions.

Sometimes what's "right" to one person (or to the median person) is "left" to someone else. My father once told me he thought FOX News was liberal, though less liberal than MSNBC and CNN. I may be more pro-free than many users here, but not quite so much as calima, and I think Richard Stallman takes it even further than calima. On the other side, Apple iOS is proprietary but less so than, say, Nintendo.

calima wrote:

I got the impression, because he repeatedly tries to troll me over preferring free software.

Repeatedly? And is it trolling or assessing? Besides, both Wine and FCEUX are free. A 32-bit program with source code available under a free software license is still free software.

On the other hand, Canonical seems about to prove calima right. Recently announced plans imply that Ubuntu is phasing out i686 (Pentium Pro, Pentium II, and newer 32-bit) support. (From ubuntu-devel, via SoylentNews) As I understand the discussion, the consensus is as follows:

Ubuntu 16.10 and later will not have a 32-bit install disc but can be reached through net install or upgrading from Ubuntu 16.04.

Ubuntu 18.10 and later will not have a 32-bit kernel or 32-bit libraries in the repository. All 32-bit applications, including Wine, will have to run in a container, as calima alluded with the "32-bit chroot".

This would leave 18.04, to be released in about two years, as the last version of Ubuntu where Wine is useful. Wine users may have to jump ship to another distro.

of fear that the 32-bit support libraries will take several gigabytes and "hav[ing] better use for that space".

This has to be the biggest oxymoron i've ever seen. No efficient program should take more than 4GB, ever, and as such, 64-bit software is completely commercial bloatware to make tech-wanabes buy it.

Modern software is just written to waste RAM as if there's no tomorrow, and the whole transition to 64-bit thing is about that. A program running in 64-bit mode is going to compile into a program that uses much more RAM, because there's longer instructions, as all pointers and some variables will take more space.

Ubuntu 18.10 and later will not have a 32-bit kernel or 32-bit libraries in the repository. All 32-bit applications, including Wine, will have to run in a container, as calima alluded with the "32-bit chroot".

Eh, Wine already uses a VM to run 16-bit programs. Wine providing a 32-bit VM is not as farfetched as it sounds.

There's a much bigger issue (OK, hypothetical for now, but...). UEFI can parse the filesystem and load the kernel for you, with the CPU already in the correct mode. Once UEFI becomes ubiquitous enough that we can just assume it's always there (and we're only a few years away from that), what are the chances that new x64 processors will just drop the legacy modes, leaving only long mode (64-bit)? I don't know how the boot process would be, but only UEFI would have to care anyway. On the other hand, it'd help simply the CPU cores, which is a big deal given how absurdly complex the architecture is already. There's a good reason to expect 32-bit x86 programs to stop working because CPUs won't support them anymore (short of emulating them).

Bregalad wrote:

This has to be the biggest oxymoron i've ever seen. No efficient program should take more than 4GB, ever, and as such, 64-bit software is completely commercial bloatware to make tech-wanabes buy it.

The data those programs may be fed could potentially blow up to over 4GB though. And don't forget that long mode provides double the amount of registers which makes it much easier to optimize programs, not to mention that because the integer registers now are 64-bit it's a lot more reasonable to do 64-bit calculations (even if you still prefer 32-bit or less for storing most data, calculation is a whole different can of worms if part of an expression can generate large values, as happens with multiplication). Also there are enough XMM registers to fit two whole 4×4 matrices into them (and yes, this matters during matrix multiplication - and no, you aren't going to be doing all of them on the GPU, usually the GPU handles the per-vertex ones but not the per-mesh ones).

Morever, protected mode has lots of bullshit stuff honestly. Long mode is a big clean up, 64-bit support is the lesser of its advantages in practice.

On the other hand, it'd help simply the CPU cores, which is a big deal given how absurdly complex the architecture is already. There's a good reason to expect 32-bit x86 programs to stop working because CPUs won't support them anymore (short of emulating them).

That doesn't feel likely. Intel removed a few things of dubious utility on the transition from 8086 -> 80186 (e.g. POP CS), and a few more things on the transition from x86 to x86_64 (e.g. BOUND), but I don't think the wholesale removal of this functionality is probable.

I mean, on Intel's x86_64 cores you can still switch from 64-bit to 32-bit to a 16-bit vm86. (AMD deprecated the vm86, but Intel still has it)

There are many applications that can benefit from large amounts of RAM.

Sometimes you can use the extra RAM for working with large amounts of media data. There's simply no "efficiency" substitute for it in a lot of situtations. 3D modelling, video and audio editing, and games all can benefit hugely from the extra RAM.

There are whole classes of algorithms, like dynamic programming that allow order of magnitude efficiency speedups, but only if you have enough memory to match the size needs of the problem set. Memory vs speed tradeoffs. Compilers fall into this category, where better optimizations become practical with enough RAM.

A user wants to use an NES debugger on a 64-bit Linux PC but refuses to use any non-free software out of principle and refuses to install any 32-bit free software (such as FCEUX for Windows in Wine) out of fear that the 32-bit support libraries will take several gigabytes and "hav[ing] better use for that space".

I guess sometime you have to make compromises, if not you will miss good software because of principles only. If I did that, I wouldn't use virtualbox because I don't agree how oracle do business or even ubuntu based distributions because I don't like how canonical is getting microsoft like with the amazon items in local search results that occurred in 14.04 if I remember well.

As for dropping 32 bits, I read somewhere there was some confusion on the subject and what they will drop is i386 based platforms since the hardware is hard to find, not i686 which supports 32 bits too. If I refind were I found this information and if it was not a misunderstanding from my part I will post it here.

When they say i386 in that message, they mean "i386 and all binary-compatible extensions thereof", that is, i686 as opposed to amd64 which is not compatible. Canonical wants to entirely relegate 32-bit support in Ubuntu Desktop and Ubuntu Server to containers rather than the main repository within the next few years. Some of the endorsed but not fully Canonical-supported remixes, especially Xubuntu and Lubuntu, may retain 32-bit support longer, as their explicit goal includes repurposing PC hardware that can no longer run modern Windows well. And Xubuntu has never had the shopping lens crap.

what they will drop is i386 based platforms since the hardware is hard to find, not i686 which supports 32 bits too.

I don't see where the 686 name comes from. Intel used 286 then 386, then 486 and then used Pentium, Pentium 2, etc... I don't think anybody ever released an "Intel 686" processor, I could be wrong, though.

Quote:

Sometimes you can use the extra RAM for working with large amounts of media data. There's simply no "efficiency" substitute for it in a lot of situtations. 3D modelling, video and audio editing, and games all can benefit hugely from the extra RAM.

All things that only a nice of people actually do regularly. Theonly thing I do in that list is audio editing, and it's really basic audacity usage and I think it works pretty well with 4GB of RAM or less.

Quote:

There are whole classes of algorithms, like dynamic programming that allow order of magnitude efficiency speedups, but only if you have enough memory to match the size needs of the problem set. Memory vs speed tradeoffs. Compilers fall into this category, where better optimizations become practical with enough RAM.

The extra RAM can then help for speed, but is never a requirement in the 1st place.

For standard office things, emails wrting and internet browsing, using so many RAM and 64-bit is completely overkill. Actually maybe even 32-bit already was overkill in the first place, but they're so used to it - they just want to sell more and more hardware no matter whether it is necessary or now. People are used to changing their computers every 3-4 years because they use Windows and their computer gets slow, but they don't even know they could reinstall the system and make it fresh again without changing any hardware.

You know, stupid question: what is Canonical's idea about what to do with 32-bit programs, wrap them in a VM automatically or expect users to run their own VM? Because I noticed sh happily passes the ball onto Wine whenever it's told to run a Windows executable, so it sounds like the wrapping could just be automatic.

Bregalad wrote:

I don't see where the 686 name comes from. Intel used 286 then 386, then 486 and then used Pentium, Pentium 2, etc... I don't think anybody ever released an "Intel 686" processor, I could be wrong, though.

Internal naming scheme, I don't remember exactly where it comes from (586 was Pentium, 686 was Pentium Pro, numbering was dropped completely after that).

Actually maybe even 32-bit already was overkill in the first place, but they're so used to it

"640KB ought to be enough for everybody"

Now OK protected mode was certainly horribly overengineered (which also made its performance pretty awful), but to say that 16-bit x86 was good enough is stupid. And I already mentioned that the 64-bit address space is the lesser of the advantages from long mode, there's a lot to be gained just by switching to it even if the program uses little memory.

Then again there's the question why modern computers feel as slow as computers from a couple decades ago, but that's a different topic. Programmers getting absurdly sloppier and newer tools encouraging them to do so, in a nutshell.

Now OK protected mode was certainly horribly overengineered (which also made its performance pretty awful), but to say that 16-bit x86 was good enough is stupid. And I already mentioned that the 64-bit address space is the lesser of the advantages from long mode, there's a lot to be gained just by switching to it even if the program uses little memory.

I never programmed any 8086 compatible machine in assembly, so I have absolutely no idea what you're talking about.

Also I am working right now on using an embedded system with a 386 compatible, but I don't think it is 686 compatible.

Who is online

Users browsing this forum: No registered users and 6 guests

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum