Is it real: UE5 or Godot4, blender3D, Starcaft 2 and Quake Champions on MSI laptop?

[hardworkingnewbie]

Hello FreeBSD community. Finally! )
I'm sorry for my English, I have not much practice.

Sorry, but what is exactly your game? Why are you here?

You've been asking questions in your initial post, and have received many well rounded responses to it, yet you still do keep repeating many of the initial misconceptions, e.g. about UFS/ZFS, like a parrot as if you just don't care.

Which makes me doubt your sincerity somewhat.

ANYWAY:

UFS is a stable and trustworthy FS.
ZFS is an enterprise FS originally designed by senior software architects from SUN who knew what they were doing, and it shows still today. Probably the best COW file system designed in this century yet.
Btrfs is a bad ZFS copy cat which just eats your data and will never be good, so don't even think about using it.

And update your knowledge about the impact of a power loss on hardware. It doesn't matter which file system you are using, if you don't have an UPS what's still just in RAM and not writting to your HDD/SSD is being lost. This is simple physics.

Also: Steam on Linux does only work perfect with ext4. Some games are known to have issues when using another Linux file system, like XFS.

 

[jbo@]

It doesn't matter which file system you are using, if you don't have an UPS what's still just in RAM and not writting to your HDD/SSD is being lost. This is simple physics.

Just to extend on this for future readers: It's not only about the primary memory of your system (eg. what's commonly referred to as "RAM"). There are other volatile memory components inbetween. Most notably, each disk (no matter whether SSD or HDD) has an on-board cache as well (which is also volatile). So even if your system wrote data through the disk interface "to the disk", it might still not be in non-volatile memory when a power loss occurs.
This is why enterprise grade storage media (notably SSDs) come with on-board energy storage capacity (usually in form of capacitors) to ensure that on a power loss event data from the disk's cache can still be written to the disk's non-volatile memory. This is something that (almost?) all consumer grade storage devices lack.
The reason why this is more prominent on SSDs than HDDs is because the energy required to keep an HDD operational without external power is orders of magnitudes higher than with SSDs. Power-loss prevention on HDDs is therefore usually economically & physically impractical.

One might argue that technically speaking hardworkingnewbie 's statement also covers this because these on-disk caches are still RAM but often/sometimes that's actually not the case. They can be volatile memory that is not RAM.
So my annoying nit-pickyness here is most because for most "computer users" or computer engineers/scientists the term "RAM" is usually used to refer to the system's primary memory and for the rest because these on-disk caches are not always RAM.

I'll shut up now.

 

[kpedersen]

• Cgroups, network namespace features? No it's not about chroot!

Jails

 

[pr0f]

Sorry, but what is exactly your game? Why are you here?

It's ok. Just a game. We are trying to figure out something about OS here.
Why people come here? Read the post. May be not for You or even us at the end, but for others it can be helpful. Too many questions I hear about FreeBSD. So we came to uncover some details and share with others by giving the link.

parrot

Try to read the thread before parroting.

UFS is a stable and trustworthy
if you don't have an UPS what's still just in RAM
SUN who knew what they were doing
Btrfs is a bad ZFS copy
This is simple physics

It really helps! Thank You!

Also: Steam on Linux does only work perfect with ext4

It's not "also", it's the only interesting thing you have said.

Jails

Thank You for the info! So, it's a reduced version of cgroups and net-ns.

 

[SirDice]

So, it's a reduced version of cgroups and net-ns.

Why do you think that?

 

[pr0f]

Why do you think that?

Yes, you are right. Perhaps I really was overly critical. May be some patches for cpu and memory limits "Not fully working" and some minor nuances. But it's almost equal.

 

[malavon]

I have a feeling this got a little more heated than it should be but there is some great information here as well. It's a habit on this forum to direct people to the right information rather than copying it in a post. Make sure to read up on the documentation given to you. It's part of - opinion incoming - the mindset of FreeBSD: help people understand the system that they're using. No one could ever post as much (correct) information about component X as the documentation out there contains.
Just to reiterate. ZFS is great, completely different from btrfs and so much better - truly, I too underestimated it before I got to know it (I'm a bit of a sceptic). It does however like to have a bit of RAM. But frankly, any modern system can cope with that. Anything you can run Unreal Engine on can certainly handle a bit of RAM going to the filesystem's in-memory information and cache.
And when it comes to protection of data it offers even more than ext4. It certainly won't lose data more easily. And that's just on a single disk, if you have multiples then it becomes even better.

Now, as said before there are some things that are more difficult in FreeBSD than they are in Linux. It's not because FreeBSD lacks something, it's because commercial support from companies out there isn't the same as it is for Linux. However I dare say that this has been changing a bit, at least when it comes to Desktop use.
Just yesterday I noticed how FreeBSD has appeared as one of six "major" operating systems on NVIDIA's new driver website. I don't know if it sounds insignificant to you but it certainly didn't to me. But still, I don't see Valve officially supporting FreeBSD tomorrow. I might be wrong and I'd love to be but it's just the truth.

It's important to understand that any game running through Linux emulation or through wine can be a hit or miss. There are many AA(A) games that work, but like I said before there's no official support. If gaming is important to you, keep a dual or even triple boot. I can't imagine you can play every game there is on Linux either, right?
If anything I'd like you to come away with this recommendation. Dual or triple boot. That way you can have FreeBSD, Linux and Windows (heavens forbid) to run everything you want. It's also incredibly useful to test if code runs well on every platform you intend to support. Don't try out in VM's, it'll never give you the real feel of an OS. Stay barebones for all your operating systems.

However...and I'm going to give you some advice that I think is still sane in the current gaming reality and thus also economic reality. When it comes to (PC) games you're going to have to focus on Windows first. Whether that means you also develop under Windows or not is up to you, but a lot of time will be spend on creating and testing Windows builds. A Linux or FreeBSD version of your game is more than a nice to have but these alone won't get you far financially. As much as I would love to see someone release a FreeBSD game, I also want to make sure that company thrives so that we can keep getting new games in the future

I don't know if you still have questions regarding FreeBSD, it's been a bit difficult to read through all the posts. Feel free to ask but friendly advice, don't get worked up when someone points you to the manual or other official documentation. It's one of the great things about FreeBSD, there's a lot of good documentation available (in many languages!).

 

[jbo@]

May be some patches for cpu and memory limits "Not fully working" and some minor nuances. But it's almost equal.

Have a look at RACCT / rctl(8).

EDIT: Just saw malavon's post above: I did not mean to point to docs to be a bitch - As stated above that is just where the information lives

 

[malavon]

Have a look at RACCT/RCTL: https://www.freebsd.org/cgi/man.cgi?query=rctl&sektion=8

I just learned something new, never needed any limits or anything but this might actually come in handy in the not-so-distant future. Thx!

 

[pr0f]

official documentation. It's one of the great things about FreeBSD, there's a lot of good documentation available (in many languages!).

I feel comfortable reading docs. No problem. But You know.. where is my KDE or Fluxbox I just want to press the button. Sometimes it wins )

Make sure to read up on the documentation given to you

Already sitting with it )
Great docs I can say. Not like a bunch of scratches in linux all over the internet.

I can't imagine you can play every game there is on Linux either, right

Of course not. Many games has unsupported anticheats, but from month to moth we can play more games. May be You alredy heard about easy-antichit and battleye. Finally, they turned their faces to linux. So we play Squad sometimes. These games we can play freely. I just need sometimes to remove old to install new one, but this screen can show we have almost everything from game industry.
Funny, but Linux boom was only about games. Not developers or tech specialists, but games )

I don't see Valve officially supporting FreeBSD tomorrow. I might be wrong and I'd love to be but it's just the truth.

I think they will some day. Thay will, if they will see Your community really wants it. They came in linux because of that: we started to help wine developers, we started to make games which can at least run under the wine (even working in UE4) and so on. We code and ask our director/manager/producer to add linux support )) linuxator or some "wine4bsd" (right now I don't how it works for You) - is the right way!

Dual or triple boot.

Honestly it's a pain. You want to take a rest for 15-20 minutes from work and realize you need to reboot ))

Don't try out in VM's, it'll never give you the real feel of an OS

Reading the handbook. Got FreeBSD-13.0-RELEASE-amd64-dvd1.iso. I think we should start with full KDE install to just start for the first time. But no, I will install it in virtualbox. For me it's much easier. A long time ago I did it from windows, then I started to see all my work already there and it's time to move on )

 

[pr0f]

Have a look at RACCT / rctl(8).

EDIT: Just saw malavon's post above: I did not mean to point to docs to be a bitch - As stated above that is just where the information lives

It's ok ) Trying to keep up with every link and read it carefully. Sometimes I get it.

in the current gaming reality and thus also economic reality

I don't know will I stay or go back to linux. But will try to stay. And if godot will be fresh, we will try to port the game to make it native. At lest because of interest. Ow you will burn under our questions here)
And no, we still have some very important questions. But now I know FreeBSD handbook is the answer to almost all of them.
So, You have all man pages and handbook in one place? It's so.. amazing )

 

[kpedersen]

• SELinux/Apparmor system?

We have Capsicum but I have little experience with it personally. I just jail things like Web browsers instead.

And if godot will be fresh, we will try to port the game to make it native.

Godot is relatively basic. I am quite certain most developers in the area of game development could port it to FreeBSD directly from the latest upstream sources. A couple of years ago I even had an undergraduate 19 year old BSc student make a port of it.

 

[jbo@]

I feel comfortable reading docs. No problem. But You know.. where is my KDE or Fluxbox I just want to press the button. Sometimes it wins )

As far as I know FreeBSD is a first-class citizen for the KDE team. They have a separate FreeBSD team. They even have an entire sub-domain for that: https://freebsd.kde.org/
I'm not using it myself but there are plenty of FreeBSD people successfully using KDE. Everything (?) is available from ports.

I allow myself to borrow picture here (curtesy of grahamperrin - borrowed from here):

If you like fancy desktops (and there's nothing wrong with that) there are plenty more pictures where that one came from: https://forums.freebsd.org/threads/freebsd-screen-shots.8877/page-76
(Intentionally linking to the last page as the thread started back in 2009).

There are also plenty of other desktop environments, window managers and so on available for FreeBSD as also shown in that thread.

And if godot will be fresh, we will try to port the game to make it native. At lest because of interest.

Please do let us know if that ever happens!

 

[pr0f]

most developers in the area of game development could port it to FreeBSD directly from the latest upstream sources

Sounds good! Thank You for details!

As far as I know FreeBSD is a first-class citizen for the KDE team. They have a separate FreeBSD team. They even have an entire sub-domain for that: https://freebsd.kde.org/

Wow. It's a real news for me! Surprisingly. I was using KDE for around a 5 years I think. Sometimes.. come on, pretty often in Arch KDE updates come broken. Then they're trying to fix it for next 2 days. Story of our life )
Now I'm using fluxbox, but I think KDE is the best choice to live really comfortably.

Please do let us know if that ever happens!

I hope it will happen this summer. We will save this bookmark )

Updated the post.

 

[jbo@]

Wow. It's a real news for me! Surprisingly. I was using KDE for around a 5 years I think. Sometimes.. come on, pretty often in Arch KDE updates come broken. Then they're trying to fix it for next 2 days. Story of our life )

I don´t mean to be bashing Linux at all - just a personal opinion based on my own experiences: What you're describint -> that is just the world of Linux. There are many people (also on this forum) that switched from Linux to FreeBSD exactly because of problems like that. Myself included.
Of course, that is not to say that nothing ever goes wrong in the world of FreeBSD. But the philosophy is different. It's not fragmented, it's a coherent system where you get a kernel and a complete OS which are also developed as such. But after many, many years of using Linux and many, many years of using FreeBSD (both server & desktop) I can safely say that FreeBSD is a much more stable, reliable & sustainable solution.

btw. Fluxbox is also available for FreeBSD: x11-wm/fluxbox
You can just continue using that if you like. Or use KDE. Or something else you like.

I hope it will happen this summer. We will save this bookmark

So do I

 

[pr0f]

Dual or triple boot.

May be.. it's real like for linux, ability to bring your video card and cpu into VM. It can change everything without need for support from valve/wine/etc. Ultra move with 5-10% fps loss!
And it can be done even on some types of laptops.

 

[jbo@]

May be.. it's real like for linux, ability to bring your video card and cpu into VM.

Bhyve (the "native" FreeBSD hypervisor) supports PCI pass-through. You can read about it here: https://wiki.freebsd.org/bhyve/pci_passthru

Technically, this allows you to create a Windows (or Linux) VM on FreeBSD and pass through your GPU. While that wiki article clearly states that GPU pass-through is currently not supported, people appear to have that working but I have never done it myself. I don´t know about the caveats there. There are certainly patches available which you can find easily.
If I understand GPU pass-through correctly, your host system will have to give up control of the device so you can´t use that GPU as your video output for the host anymore (which makes sense). So you´d need a second GPU.
Bhyve PCI pass-through with other devices such as USB controllers certainly works (out of the box).

Dual booting might be much easier to start if this is the only thing holding you back. I'm certainly doing that on my gaming machines very successfully. But I do get your previous note of hating to reboot into a different OS just to have a quick session of fun.

 

[pr0f]

So you´d need a second GPU

It depends on how video cards operating inside your system, at least in linux (according to the docs it has the same technology in both OS). Laptops has variants (muxless, etc.), about PC You are right - there should be a second card. So no chance, sad. Thank You for the info!

 

[malavon]

Wow. It's a real news for me! Surprisingly. I was using KDE for around a 5 years I think. Sometimes.. come on, pretty often in Arch KDE updates come broken. Then they're trying to fix it for next 2 days. Story of our life )
Now I'm using fluxbox, but I think KDE is the best choice to live really comfortably.

Well, I've been using KDE 3, 4 and now Plasma almost as long as I've been using FreeBSD and I can tell you that I haven't had many breakages. Would have been a pain too since I only use KDE/Plasma.
Back in the days I remember having had some breakages, sometimes my own fault because I build my own ports/packages with custom options. And I'm sure not everything works perfectly, there is bound to be something that hasn't been ported but nothing that stands out to me.

 

[kpedersen]

May be.. it's real like for linux, ability to bring your video card and cpu into VM. It can change everything without need for support from valve/wine/etc. Ultra move with 5-10% fps loss!
And it can be done even on some types of laptops.

Are you talking about GPU passthrough of virtualization software like VMware and VirtualBox?

We have that on FreeBSD too via our VirtualBox port. This is probably also easier for beginners than FreeBSD's Bhyve and Linux's KVM.

Sounds good! Thank You for details!

If you are completely lost and need *even more* details, you can probably just start off from the existing port here. The FreeBSD ports collection makes it easier to port software. Actually Arch Linux and Gentoo's ports collections started out by copying it.

 

[Cath O'Deray]

… Plasma … not everything works perfectly, …

True. As an example of the type of bug that I don't bother to report (someone else might have):



– you can attempt to use System Settings to use a time server, but the attempt will silently fail.

Not a Plasma issue, but it's worth mentioning since SDDM is so often used for Plasma:

ConsoleKit, SDDM, switch user

Abbreviated: … ReuseSession=true … I added the line to /usr/local/etc/sddm.conf.d/kde_settings.conf (you might find the file already present), however it's not effective. We're probably bitten by something like the bugs below (ignoring the systemd aspect)...

forums.freebsd.org

 

[malavon]

And if godot will be fresh,

Out of curiosity I just checked, Godot is at 4.2.2 while the latest is 4.2.4, just a bunch of bugfixes. The FreeBSD maintainer is keeping a nice upgrade pace but probably didn't get to updating just yet.