Quoting: fagnerlnI tried to install on virtual box before any big change on my hdd, and the installation was a little weird, taking a lot of time and installing and removing just after some packages. The VM have enough RAM, storage and all cores enabled.

Maybe I will try to install it again.

If you create a new VM with virtual box standard settings in the wizard you will get a dynamically sized disk up to the limit you specify.
The initial size is much smaller and used all up after a new OS install, doing upgrades and installing new programs will be very slow right after as the disk is growing bigger, especially on a hdd.
That is my experience and sounds what happened to you.
After a while the actual used disk size will be big enough and you get a much better performance from the filesystem.

View this comment - View article - View full comments

Quoting: silmethcities saved in the original must behave exactly the same in Julius.

Putting it like that makes sense.

I played some of the followups a lot back in the day like Zeus, Children of the Nile and Emperor. I just looked through my old boxes and no Caesar there, so maybe I get the gog version.

View this comment - View article - View full comments

Quoting: Alm888

Quoting: Phlebiac

Quoting: Alm888Here at Fedora we do not call 3rd-party repositories like "RPM Fusion" some fancy names

Well, we do have "Cool Other Package Repo"
https://fedoraproject.org/wiki/Category:Copr [External Link]

Nah. That's server-side infrastructure for creating/maintaining repositories. From user's perspective it is still enabled via ordinary "/etc/yum.repos.d/*.repo" config files.

Same as PPAs are config files under /etc/apt/sources.list.d on Ubuntu, and a key added just like with Copr. Does it bother you that there are graphical and commandline frontends for it so that users do not have to know about the config files?

Reading through https://fedoraproject.org/wiki/Category:Copr [External Link] and https://help.launchpad.net/Packaging/PPA?action=show&redirect=PPA [External Link] it is really the same concept just implemented differently off course.

View this comment - View article - View full comments

Quoting: Alm888Nope. nVidia updates its drivers frequently enough.
The fact that Canonical thinks it is OK to not provide adequate drivers to 60% of the userbase has nothing to do with nVidia. Besides, there is always "Linux Mint", fixing this little issue. :)

Mint does get its nvidia drivers straight from Ubuntu, from a Mint VM I have:
[ apt policy nvidia-driver-435
nvidia-driver-435:
  Installed: (none)
  Candidate: 435.21-0ubuntu0.18.04.2
  Version table:
     435.21-0ubuntu0.18.04.2 500
        500 http://archive.ubuntu.com/ubuntu bionic-updates/restricted amd64 Packages
Ubuntu, and thus also mint has currently ,besides some legacy drivers like 390 and older, 430 and 435, and 440 is in proposed now coming into normal updates in a couple of days if the testing goes ok.

So most users do not need a PPA for nvidia drivers, unless they have a very recent GPU or want some new features straight away.

Quoting: Alm888Hm, it seems that is true. So, at least Mesa is not completely stuck. This leaves the question about frequency of updates, however.

Check the changelog I provided.

Quoting: Alm888Here at Fedora we do not call 3rd-party repositories like "RPM Fusion" some fancy names (and I believe, SUSE branch don't do it either). Even "Debian GNU/Linux" doesn't do that! So "PPA" is strictly Ubuntu-specific.

So PPA is a fancy name and RPM Fusion is not :wink:
Yes PPA is a Ubuntu and derivates specific term, which also was mentioned in the wiki page I linked.

View this comment - View article - View full comments

If the Mesa overlay is independent of the graphics driver then it probably could be built as a stand-alone package for the various distributions, to not conflict but work with whatever Mesa or Nvidia driver are installed. I still think it is a good idea to have competition if they have different goals and ways to implement them.

View this comment - View article - View full comments

Quoting: Guest

Quoting: Alm888

Quoting: ShmerlHow much drag is there?

/usr/lib/x86_64-linux-gnu/libvulkan_intel.so
/usr/lib/x86_64-linux-gnu/libvulkan_radeon.so
/usr/share/bug/mesa-vulkan-drivers
/usr/share/bug/mesa-vulkan-drivers/control
/usr/share/bug/mesa-vulkan-drivers/script
/usr/share/doc/mesa-vulkan-drivers
/usr/share/doc/mesa-vulkan-drivers/changelog.Debian.gz
/usr/share/doc/mesa-vulkan-drivers/copyright
/usr/share/lintian/overrides/mesa-vulkan-drivers
/usr/share/vulkan/icd.d/intel_icd.x86_64.json
/usr/share/vulkan/icd.d/radeon_icd.x86_64.json

That is for starters. And then the package dependency hell kicks in and this all goes downhill. Fast.

Remember, before libGLVND we could not even have two OpenGL implementations installed at once, so installing Mesa was not an option.

IMO, the less dependencies a project has the better. And Mesa here is clearly redundant. Of course, I think it would be better if the original "Mesa Vulkan Overlay" project was untied from the Mesa in the first place.

Offtopic: There are lots of problems with Mesa. It being critical system component and thus "frozen in stone" in the Ubuntu LTS releases for two years for many people is the most prominent. And in order to not be stuck with hugely outdated software Ubuntu users resort to hacks like untested unstable repositories (due to NIH syndrome Canonical® calls them "PPA"s) thus throwing the whole idea of stable supported system out the window. :)

I may be mistaken, but i think binary blobs are not officially part of ubuntu, so the blame's on nvidia.

Quoting: Guest

Quoting: Alm888

Quoting: ShmerlHow much drag is there?

/usr/lib/x86_64-linux-gnu/libvulkan_intel.so
/usr/lib/x86_64-linux-gnu/libvulkan_radeon.so
/usr/share/bug/mesa-vulkan-drivers
/usr/share/bug/mesa-vulkan-drivers/control
/usr/share/bug/mesa-vulkan-drivers/script
/usr/share/doc/mesa-vulkan-drivers
/usr/share/doc/mesa-vulkan-drivers/changelog.Debian.gz
/usr/share/doc/mesa-vulkan-drivers/copyright
/usr/share/lintian/overrides/mesa-vulkan-drivers
/usr/share/vulkan/icd.d/intel_icd.x86_64.json
/usr/share/vulkan/icd.d/radeon_icd.x86_64.json

That is for starters. And then the package dependency hell kicks in and this all goes downhill. Fast.

Remember, before libGLVND we could not even have two OpenGL implementations installed at once, so installing Mesa was not an option.

IMO, the less dependencies a project has the better. And Mesa here is clearly redundant. Of course, I think it would be better if the original "Mesa Vulkan Overlay" project was untied from the Mesa in the first place.

Offtopic: There are lots of problems with Mesa. It being critical system component and thus "frozen in stone" in the Ubuntu LTS releases for two years for many people is the most prominent. And in order to not be stuck with hugely outdated software Ubuntu users resort to hacks like untested unstable repositories (due to NIH syndrome Canonical® calls them "PPA"s) thus throwing the whole idea of stable supported system out the window. :)

I may be mistaken, but i think binary blobs are not officially part of ubuntu, so the blame's on nvidia.

That comment was about Mesa not nvidia. Ubuntu distributes nvidia drivers via their restricted archive, so it is an optin, but I would say it can be said to be an optional part of the distribution, they warn they can not properly support due to the closed source.

And just as for Mesa, just only since last summer, newer versions also coem as SRU now, just with a few months delay. 18.04 has 430 and 435 now with 440 just uploaded to proposed, so in normal updates in a few days.https://bugs.launchpad.net/ubuntu/bionic/+source/nvidia-graphics-drivers-340/+bug/1854485 It is not the new version released yesterday, but 440.44 which was released a while ago.

View this comment - View article - View full comments

Quoting: Alm888

Quoting: ShmerlHow much drag is there?

/usr/lib/x86_64-linux-gnu/libvulkan_intel.so
/usr/lib/x86_64-linux-gnu/libvulkan_radeon.so
/usr/share/bug/mesa-vulkan-drivers
/usr/share/bug/mesa-vulkan-drivers/control
/usr/share/bug/mesa-vulkan-drivers/script
/usr/share/doc/mesa-vulkan-drivers
/usr/share/doc/mesa-vulkan-drivers/changelog.Debian.gz
/usr/share/doc/mesa-vulkan-drivers/copyright
/usr/share/lintian/overrides/mesa-vulkan-drivers
/usr/share/vulkan/icd.d/intel_icd.x86_64.json
/usr/share/vulkan/icd.d/radeon_icd.x86_64.json

That is for starters. And then the package dependency hell kicks in and this all goes downhill. Fast.

Remember, before libGLVND we could not even have two OpenGL implementations installed at once, so installing Mesa was not an option.

IMO, the less dependencies a project has the better. And Mesa here is clearly redundant. Of course, I think it would be better if the original "Mesa Vulkan Overlay" project was untied from the Mesa in the first place.

Offtopic: There are lots of problems with Mesa. It being critical system component and thus "frozen in stone" in the Ubuntu LTS releases for two years for many people is the most prominent. And in order to not be stuck with hugely outdated software Ubuntu users resort to hacks like untested unstable repositories (due to NIH syndrome Canonical® calls them "PPA"s) thus throwing the whole idea of stable supported system out the window. :)

Mesa is not "frozen in stone" for the current LTS release, it gets SRU (Stable Release Updates, see https://wiki.ubuntu.com/StableReleaseUpdates) [External Link] 18.04 and 19.10 have now Mesa 19.2.8 released in December 2019 https://packages.ubuntu.com/source/bionic-updates/mesa [External Link] and https://changelogs.ubuntu.com/changelogs/pool/main/m/mesa/mesa_19.2.8-0ubuntu0~18.04.1/changelog [External Link]

PPA is short for Personal Package Archive https://en.wikipedia.org/wiki/Ubuntu#Package_Archives [External Link]
What is NIH about having a mechanism to "Using a Personal Package Archive (PPA), you can distribute software and updates directly to Ubuntu users. Create your source package, upload it and Launchpad will build binaries and then host them in your own apt repository. " from https://help.launchpad.net/Packaging/PPA?action=show&redirect=PPA [External Link]

Restricting users to only get offcial packages would be more like "NIH"

View this comment - View article - View full comments

Quoting: RunningTuxI'll buy it too, for sure.
And as additional support to Feral, I would be tempted to buy a copy for my teens, too.
But they use Windows.
Do you know if a Feral game will work on Windows OS ?

Yes, they sell Steam codes, so since there is a Windows version for this game too they can just install it on Windows. And if you buy the codes from Feral directly then they get the money also then.

View this comment - View article - View full comments

Quoting: slaapliedjeIt is similar because they wanted to ditch 32 bit outright until everyone threatened to stop using it

That is not true, do not believe online trolls or blog posts based on those. Granted the communication from Canonical could have been a lot better, but much of the controversy was based on misunderstandings or outright lies.

From the original announcement at https://discourse.ubuntu.com/t/intel-32bit-packages-on-ubuntu-from-19-10-onwards/11263/2 [External Link]

Q. Doesn’t Steam use 32 bit libraries? How can I play my games?

Steam itself bundles a runtime containing necessary 32-bit libraries required to run the Steam client. In addition each game installed via Steam may ship 32-bit libraries they require. We’re in discussions with Valve about the best way to provide support from 19.10 onwards.

It may be possible to run 32 bit only games inside a lxd container running a 32 bit version of 18.04 LTS. You can pass through the graphics card to the container and run your games from that 32bit environment.

Q. How can I run 32-bit Windows applications if 32-bit WINE isn’t available in the archive?

Try 64-bit WINE first. Many applications will “just work”. If not use similar strategies as for 32 bit games. That is use an 18.04 LTS based Virtual Machine or LXD container that has full access to multiarch 32-bit WINE and related libraries.

Q. I have a legacy proprietary 32-bit Linux application on my 64-bit installation. How can I continue running it.

Run an older release of Ubuntu which supports i386, such as 16.04 LTS or, preferably 18.04 LTS in a Virtual Machine or LXD container as above.

And if that is not enough look what Valve wrote: https://steamcommunity.com/app/221410/discussions/0/1640915206447625383/ [External Link]

There's a lot more to the technical and non-technical reasons behind our concerns, but the bottom line is that we would have had to drop what we're doing and scramble to support the new scheme in time for 19.10. We weren't confident we could do that without passing some of the churn to our users, and it would not solve the problems for third-party software outside of Steam upon which many of our users rely.

So they did not like that, and I and many other did not either, but it still would have been possible to run steam and other 32bit programs.

View this comment - View article - View full comments

Quoting: ShmerlWhy do you need containers then, if libraries there will be recent? Multiarch already works fine for that. Containers make sense for frozen case, when there are no more upstream updates coming.

Mixed cases, some libraries do not always stay backward compatible, while the kernel tries to never break userspace.

So the games might work with current graphics drivers but not with some network library or whatever.

Did you never encounter games or other programs that have problems with newer libraries?

I am not convinced that this is the way forward to run old games, but it is better than virtual machines since containers can get access to the all parts of the system you want.

And containers where the original plan, for now until at least 20.04 Ubuntu will built all requested packages for 32 bit, and who knows for the next distribution after that maybe too, but I understand they do not want to commit to that now. 20.04 will be supported until April 2025 that is already a long time they will stick to this new scheme for that release at least.

View this comment - View article - View full comments