Fedora as compo Linux distribution?
category: general [glöplog]
I'm a compo organizer and a user of Debian-style distros, so I'm not really fond of that Fedora thing ;) (But I wouldn't mind much if this is what we're settling on either.)
That shouldn't make any difference for running demos though :)
That's nice, but installing the two libSDL versions isn't an issue on Ubuntu either, and has been the standard for Linux compos for quite a while already. Also, many recent Linux entries just use Gtk to set up their window anyway.
From my own painful experience, I can confirm that installing Ubuntu onto a USB stick, while possible, is dangerous as f*ck. (Essentially, it'll fry your host system's bootloader.)
This. The compo orga prescribes some recent distro you can test your entry on, but it's a safe bet that if you compile your entry on another distro that's about as new or slightly older, library versions etc. should just work out.
A story from the trenches: At Deadline 2021, we had a really hard time getting Oionos to work, but if I recall it correctly, none of the issues were due to the compo machine using Ubuntu and the devs using Arch. (AMD vs. nVidia, though, made a huge difference...)
That's the least of all worries, as this is one of the reasons why you usually have multiple compo PCs. Again, speaking from Deadline experience, we never used the secondary compo PC for anything critical (and only ever rebooted the primary one when I hit the inconveniently placed reset button right next to the USB port). Running Linux entries from there would finally give it a real purpose other than being a "hot spare".
Also, keep in mind that Linux isn't the only offender here: Lately, the DOS sizecoding scene releases an increasing number of intros that need to run on "bare metal" instead of DOSBox. That's actually even worse than Linux, because you can't even boot DOS on many modern machines any longer, as newer UEFI firmwares tend to ship without a CSM ("Legacy" BIOS emulation).
Indeed, WSLg is something worth looking at (if the scene switches to Windows 11 or MS backports the feature to Windows 10, that is). This would be the most hassle-free way to run Linux entries ... if they run at all.
Quote:
It comes with a vanilla gnome instead of this weird purple ubuntu variant ;)
That shouldn't make any difference for running demos though :)
Quote:
It has SDL2 installed as a default package, which is handy for intros
That's nice, but installing the two libSDL versions isn't an issue on Ubuntu either, and has been the standard for Linux compos for quite a while already. Also, many recent Linux entries just use Gtk to set up their window anyway.
Quote:
You can install it (no live system, actual install) to a big enough USB Stick and switch that from one PC to another without a problem (Last time i tried, this was a big problem with ubuntu)
From my own painful experience, I can confirm that installing Ubuntu onto a USB stick, while possible, is dangerous as f*ck. (Essentially, it'll fry your host system's bootloader.)
Quote:
I would not care whether the target system was Fedora or Ubuntu.
This. The compo orga prescribes some recent distro you can test your entry on, but it's a safe bet that if you compile your entry on another distro that's about as new or slightly older, library versions etc. should just work out.
A story from the trenches: At Deadline 2021, we had a really hard time getting Oionos to work, but if I recall it correctly, none of the issues were due to the compo machine using Ubuntu and the devs using Arch. (AMD vs. nVidia, though, made a huge difference...)
Quote:
the fact that you have to boot it in the first place throws a huge spanner into the compo works.
That's the least of all worries, as this is one of the reasons why you usually have multiple compo PCs. Again, speaking from Deadline experience, we never used the secondary compo PC for anything critical (and only ever rebooted the primary one when I hit the inconveniently placed reset button right next to the USB port). Running Linux entries from there would finally give it a real purpose other than being a "hot spare".
Also, keep in mind that Linux isn't the only offender here: Lately, the DOS sizecoding scene releases an increasing number of intros that need to run on "bare metal" instead of DOSBox. That's actually even worse than Linux, because you can't even boot DOS on many modern machines any longer, as newer UEFI firmwares tend to ship without a CSM ("Legacy" BIOS emulation).
Quote:
So, if there were a way to run Linux prods seamlessly under Windows (without compromising performance of course) using some kind of virtualization tech that would be more helpful to orgas than any distro choice.
Indeed, WSLg is something worth looking at (if the scene switches to Windows 11 or MS backports the feature to Windows 10, that is). This would be the most hassle-free way to run Linux entries ... if they run at all.
My stance has usually been Ubuntu + proprietary drivers enabled.
If SDL is required then that's fine. I consider it as an "essential" in the same category as D3D runtimes.
But anything beyond the usual scope and I will give the author ~15min to figure out their issue or to at least get some backtrace for their own use. Depending on time, if 1-2 attempts aren't enough to get things fixed then I ask them to provide a capture or some times just use their own machine, It's highly unlikely that the machine will exceed compo machine specs. So far I've never had to disqualify stuff because of this.
These all can be clarified in the rules/info, however I do think that it's not a bad idea to inform/agree on a typical "What is expected" list of things between parties. But the above generally is all that's needed.
For any compo stuff you'll generally want to do a fresh install as you want to make sure that there isn't any useless junk or outdated/extra things laying around from who knows what previous party. This pretty much makes "linux-on-go" a bit redundant. Live booting is especially useful if it's possible for any one-off entry that might not require a full install.
As for distro itself, Ubuntu has been a reliable default since getting things to a working state with "real" drivers for nvidia is a quick process and rather trouble free. It's just overall all around a solution that simply works for this purpose. Multiple methods of installation and widespread quick mirrors have allowed things to run smoothly even when it's been to last minute installs.
When things fail, finding solutions quickly matters. I at least like to group Ubuntu as a very consumer/entry level distro where users do throw a bunch of more modern/gaming hardware against it and you'll likely find that eventual thread for things like when your gaming monitor all of a sudden go blank due to some weird screenmodes or other incompatibilities.
Probably the better question is why change?
(Aside from perhaps the desktop, but all you really need is a file manager + terminal before you uninstall it again, which are both very accessible)
If SDL is required then that's fine. I consider it as an "essential" in the same category as D3D runtimes.
But anything beyond the usual scope and I will give the author ~15min to figure out their issue or to at least get some backtrace for their own use. Depending on time, if 1-2 attempts aren't enough to get things fixed then I ask them to provide a capture or some times just use their own machine, It's highly unlikely that the machine will exceed compo machine specs. So far I've never had to disqualify stuff because of this.
These all can be clarified in the rules/info, however I do think that it's not a bad idea to inform/agree on a typical "What is expected" list of things between parties. But the above generally is all that's needed.
For any compo stuff you'll generally want to do a fresh install as you want to make sure that there isn't any useless junk or outdated/extra things laying around from who knows what previous party. This pretty much makes "linux-on-go" a bit redundant. Live booting is especially useful if it's possible for any one-off entry that might not require a full install.
As for distro itself, Ubuntu has been a reliable default since getting things to a working state with "real" drivers for nvidia is a quick process and rather trouble free. It's just overall all around a solution that simply works for this purpose. Multiple methods of installation and widespread quick mirrors have allowed things to run smoothly even when it's been to last minute installs.
When things fail, finding solutions quickly matters. I at least like to group Ubuntu as a very consumer/entry level distro where users do throw a bunch of more modern/gaming hardware against it and you'll likely find that eventual thread for things like when your gaming monitor all of a sudden go blank due to some weird screenmodes or other incompatibilities.
Probably the better question is why change?
(Aside from perhaps the desktop, but all you really need is a file manager + terminal before you uninstall it again, which are both very accessible)
Quote:
If SDL is required then that's fine. I consider it as an "essential" in the same category as D3D runtimes.
Why is it essential? Shouldn't Linux prods use Xlib or whatever the equivalent to the Windows API is? It doesn't make much sense to allow e.g. 4k intros to use SDL on Linux, but not on Windows.
I personally like the idea of using WSL2, if this simplifies things for the organisers. There are however a few caveats.
First, WSL2 has its own graphics driver if I understand correctly. This means the authors have to take care that the entry still runs on a "real" version of the distribution used.
Second, it would be really nice if there was some sort of defined compo Linux in the sense that all parties use the same distribution (which seems to be nearly the case) but also settles the question, which libraries are considered default as is the case with D3D on windows. This is more like a nice-to-have in my opinion to achieve a more consistent platform for someone who wishes to run a demo/intro on his or her machine.
The uniform choice of distribution is important. While it is correct that the versions of libraries do not differ much, the paths sadly do. (which really sucks)
Using Windows instead is however not an option. There is some fun and diversity in having Linux around, too! ;)
First, WSL2 has its own graphics driver if I understand correctly. This means the authors have to take care that the entry still runs on a "real" version of the distribution used.
Second, it would be really nice if there was some sort of defined compo Linux in the sense that all parties use the same distribution (which seems to be nearly the case) but also settles the question, which libraries are considered default as is the case with D3D on windows. This is more like a nice-to-have in my opinion to achieve a more consistent platform for someone who wishes to run a demo/intro on his or her machine.
Quote:
This. The compo orga prescribes some recent distro you can test your entry on, but it's a safe bet that if you compile your entry on another distro that's about as new or slightly older, library versions etc. should just work out.
The uniform choice of distribution is important. While it is correct that the versions of libraries do not differ much, the paths sadly do. (which really sucks)
Using Windows instead is however not an option. There is some fun and diversity in having Linux around, too! ;)
absence: Even most DX runtimes weren't shipped as part of windows and had to be installed manually, this has changed a bit in the recent times. For 4k/etc.. you HAD to have these installed or most prods simply wouldn't run.
If your rules state that SDL is allowed then use that. It allows a sort of similar suite to what DX API allows from windows side from what I have understood.
As with the Fedora mention earlier, some already bundle these by default.
Yes, this is an argument that can go "Oh, so why not ship X Y Z as well" but I would argue that it's reasonable to expect SDL to be available on a typical Linux machine that's not strictly server use or bare workstation stuff. Perhaps quotation marks around essential can be a bit misleading but more like it's so everyday that it's hard to argue against it.
Plus stuff like this is what you should mention on the beamslide in the end.
As for Xlib, I do now know enough to comment on that.
If I'm mistaken here then feel free to correct.
If your rules state that SDL is allowed then use that. It allows a sort of similar suite to what DX API allows from windows side from what I have understood.
As with the Fedora mention earlier, some already bundle these by default.
Yes, this is an argument that can go "Oh, so why not ship X Y Z as well" but I would argue that it's reasonable to expect SDL to be available on a typical Linux machine that's not strictly server use or bare workstation stuff. Perhaps quotation marks around essential can be a bit misleading but more like it's so everyday that it's hard to argue against it.
Plus stuff like this is what you should mention on the beamslide in the end.
As for Xlib, I do now know enough to comment on that.
If I'm mistaken here then feel free to correct.
Quote:
Why is (SDL) essential? Shouldn't Linux prods use Xlib or whatever the equivalent to the Windows API is?
Technically you're right, but then again, it's always been the case in intro compo rules that helper libraries like D3DX are accepted, and that's more or less exactly what SDL is, give or take.
Quote:
First, WSL2 has its own graphics driver if I understand correctly.
That's one of the potential issues with WSL2/WSLg, yes. The graphics driver is based on Mesa, so the critical parts (specifically the shader compiler) should work pretty much identical to native systems with AMD or Intel graphics (and, thus, unlike native nVidia systems), but there's more stuff where I'm not sure whether it'll work or not. My main concern in this regard would be graphics mode switching.
Quote:
Technically you're right, but then again, it's always been the case in intro compo rules that helper libraries like D3DX are accepted, and that's more or less exactly what SDL is, give or take.
D3DX is not accepted for a couple of years now at revision - it's deprecated. Furthermore, fortunately no one is really using that anymore. The revision Windows PC setup boils down to "Vanilla install with latest graphics drivers".
As of now, I do not really see any reason why libSDL* should be installed, given that it's seemingly not so hard to get away without it. How much time it takes to set stuff up without having to modify random config files plays an important role.
Quote:
I have looked it up and if i got it correctly, WSL2 provides gui support with OpenGL 4.2 support for Windows 11 with allegedly little performance overhead, so maybe that could be worth a try if one doesn't want to reboot from Windows.
That OpenGL support (and upcoming Vulkan support) is in part my work. While it's useful for compatibility and works well, I would not recommend using it for running Linux compo-entries. It's fairly recent software, and squishing all minor rendering issues in an OpenGL takes time. There's a good chance that something misrenders, and as a compo-organizer you might not have a good way of knowing.
As for the suggestion: I don't think Fedora is a bad choice, but let's take a step back here:
What do we want in a Linux distro for a compo-machine:
That's the core of it, really. Both Ubuntu Desktop and Fedora Workstation fits that description well. Things that clearly doesn't fit is:
In addition, it's nice if the distro isn't diverging too far from the mainstream, in a few ways:
Neither Ubuntu Desktop or Fedora Workstation is doing particularly better than the other here. I think either are reasonable choices.
The rest becomes opinions in my book, and I think that can be discussed until the end of time without reaching consensus. I wouldn't be surprised to see either being chosen by any compo organizer, TBH.
But since this started as a fairly opinionated list of reasons to differentiate them, let's look at them:
I don't see how this is a noteworthy benefit here. Ubuntu is Debian-based, which also has huge industry support. I'm a Linux professional myself, and I much more often encounter Debian based systems than RHEL based systems.
That's a bit too anecdotal to be addressed, I think...
I don't think this is a huge plus either, very few popular distros ship vanilla GNOME, so you might even consider "vanilla GNOME" to be the "Fedora vendor look" ;)
I would have agreed a bit with you back when Ubuntu did their Unity thing, but since they dropped that, I think the purple accent color is fine. And besides, in the recently released Ubuntu 22.04 release, you can easily change the accent color to something neutral.
Compo organizers probably has access to large USB sticks or external SSDs. I don't think this matters much either.
I personally disagree that SDL should be a default package in the first place. If intros are supposed to be a feat in size-coding, they shouldn't depend on getting the window system and audio sink served to them on a silver platter either.
All in all, I would probably pick Ubuntu Desktop if I were to arrange a compo with Linux support, exactly the same decision we made for the Evoke 2019 compos. Simply because Ubuntu is more popular, and it's easier to ask developers to test on it.
That being said, we're in 2022 now. I would hope Linux developers has the sense to use either Flatpak or Appimage for non-size restricted demos. I even published my latest demo on Flathub recently!
What do we want in a Linux distro for a compo-machine:
- A reliable, yet reasonably up-to-date system
- A reasonable definition of what comes pre-installed
That's the core of it, really. Both Ubuntu Desktop and Fedora Workstation fits that description well. Things that clearly doesn't fit is:
- Rolling-release distros: What versions of packages are used would be unknown, which could break things unexpectedly. It's unlikely, but still not great.
- LTS based distros: These tend to be out-of-date in many ways fairly quickly, meaning you can often forget to get access to stuff like recent Vulkan features.
- "Minimal" or overly configurable distros, like Debian and Arch Linux. These lack a reasonable definition of what to pre-install, so there's no up-front agreement of what the platform even is.
In addition, it's nice if the distro isn't diverging too far from the mainstream, in a few ways:
- It should probably be fairly easy to configure and use, using common tools. So probably something using system-d and either GNOME (3+) or KDE Plasma (without too many customization).
- It should probably be fairly easy to install proprietary drivers, in the case the compo machine uses an NVIDIA GPU.
Neither Ubuntu Desktop or Fedora Workstation is doing particularly better than the other here. I think either are reasonable choices.
The rest becomes opinions in my book, and I think that can be discussed until the end of time without reaching consensus. I wouldn't be surprised to see either being chosen by any compo organizer, TBH.
But since this started as a fairly opinionated list of reasons to differentiate them, let's look at them:
Quote:
It's the community version of Red Hat Enterprise Linux, which is quite big in the professional world and therefore has a solid backing
I don't see how this is a noteworthy benefit here. Ubuntu is Debian-based, which also has huge industry support. I'm a Linux professional myself, and I much more often encounter Debian based systems than RHEL based systems.
Quote:
It generally seems to cause a bit less trouble than ubuntu from my experience
That's a bit too anecdotal to be addressed, I think...
Quote:
It comes with a vanilla gnome instead of this weird purple ubuntu variant ;)
I don't think this is a huge plus either, very few popular distros ship vanilla GNOME, so you might even consider "vanilla GNOME" to be the "Fedora vendor look" ;)
I would have agreed a bit with you back when Ubuntu did their Unity thing, but since they dropped that, I think the purple accent color is fine. And besides, in the recently released Ubuntu 22.04 release, you can easily change the accent color to something neutral.
Quote:
You can install it (no live system, actual install) to a big enough USB Stick and switch that from one PC to another without a problem (Last time i tried, this was a big problem with ubuntu)
Compo organizers probably has access to large USB sticks or external SSDs. I don't think this matters much either.
Quote:
It has SDL2 installed as a default package, which is handy for intros
I personally disagree that SDL should be a default package in the first place. If intros are supposed to be a feat in size-coding, they shouldn't depend on getting the window system and audio sink served to them on a silver platter either.
All in all, I would probably pick Ubuntu Desktop if I were to arrange a compo with Linux support, exactly the same decision we made for the Evoke 2019 compos. Simply because Ubuntu is more popular, and it's easier to ask developers to test on it.
That being said, we're in 2022 now. I would hope Linux developers has the sense to use either Flatpak or Appimage for non-size restricted demos. I even published my latest demo on Flathub recently!
For the record: The blue vs purple color argument was a joke.
While i do prefer blue, it clearly doesn't matter ^^
Well, i think it all boils down to SDL2 yay or nay.
There seems not to be a consensus between organizers wheter
SDL2 dependence is allowed or only default packages are installed.
I regard using Fedora as a compromise.
I think it would be an unsatisfying situation if you could see from an entry if SDL2 was allowed or not on that party, because theres just some difference in detail that could fit into the size.
I think there is a difference between SDL2 under Windows and under Linux, it is much more of a system component for Linux, as can be seen by the fact that Fedora is having it installed by default.
The two applications (indirectly) depending on it are "Gnome Boxes" and "Gnome Photos".
I would agree that in a sizecoding effort you should'nt get everything on a silver plate, but Fedora is not some weird distribution nobody uses, it has 1.2 Million users and it depends on SDL2, which makes it a system component for this distribution at least.
wikipedia says.
While i do prefer blue, it clearly doesn't matter ^^
Well, i think it all boils down to SDL2 yay or nay.
There seems not to be a consensus between organizers wheter
SDL2 dependence is allowed or only default packages are installed.
I regard using Fedora as a compromise.
I think it would be an unsatisfying situation if you could see from an entry if SDL2 was allowed or not on that party, because theres just some difference in detail that could fit into the size.
I think there is a difference between SDL2 under Windows and under Linux, it is much more of a system component for Linux, as can be seen by the fact that Fedora is having it installed by default.
The two applications (indirectly) depending on it are "Gnome Boxes" and "Gnome Photos".
I would agree that in a sizecoding effort you should'nt get everything on a silver plate, but Fedora is not some weird distribution nobody uses, it has 1.2 Million users and it depends on SDL2, which makes it a system component for this distribution at least.
wikipedia says.
And none of this is of any consequence because in the end some let's say some Revision organizer, one point something weeks ago, installs the distro most people recommended (Ubuntu Desktop), does the necessary configuration dance, everything kinda works, but the video that goes out over HDMI to the rest of the equipment has a prominent yellowish tint that won't go away, whatever you do....
... until we installed Linux Mint instead. That "fixed" it. (I think embedded HDMI audio was still broken but you can work around that with a good old analog cable, yayyyyy)
Yes, I'm aware that it was probably some issue with the BlackMagic recorder at the other end of the HDMI cable wanting YUV, and some EDID or simply bug related quirk resulted in a wrong conversion matrix for the output, but, point is: We're in 2022 now, and just installing the most well known distro on a pretty standard 2021 desktop machine and then doing stuff with it _still_ doesn't work as expected. And the solution we found was purely a shot in the dark.
Sorry for the rant. I'd love to have more alternatives to Windows (or MacOS) esp with MS currently dropping the ball on so many fronts at the same time. But there's still no solution that "just works" as well as the other OSes do, or is as easy to maintain if something goes wrong.
I mean, at least it gets better.
... until we installed Linux Mint instead. That "fixed" it. (I think embedded HDMI audio was still broken but you can work around that with a good old analog cable, yayyyyy)
Yes, I'm aware that it was probably some issue with the BlackMagic recorder at the other end of the HDMI cable wanting YUV, and some EDID or simply bug related quirk resulted in a wrong conversion matrix for the output, but, point is: We're in 2022 now, and just installing the most well known distro on a pretty standard 2021 desktop machine and then doing stuff with it _still_ doesn't work as expected. And the solution we found was purely a shot in the dark.
Sorry for the rant. I'd love to have more alternatives to Windows (or MacOS) esp with MS currently dropping the ball on so many fronts at the same time. But there's still no solution that "just works" as well as the other OSes do, or is as easy to maintain if something goes wrong.
I mean, at least it gets better.
Quote:
Well, i think it all boils down to SDL2 yay or nay.
There seems not to be a consensus between organizers wheter
SDL2 dependence is allowed or only default packages are installed.
I regard using Fedora as a compromise.
Even if people agree to allow SDL2, it's trivial to install on Ubuntu Desktop. So I don't think this is a reasonable argument to use Fedora over Ubuntu.
Quote:
I think there is a difference between SDL2 under Windows and under Linux, it is much more of a system component for Linux, as can be seen by the fact that Fedora is having it installed by default.
Nope, still just a wrapper over other stuff. SDL is a convenience library, it doesn't provide any functionality in itself. For demos, GTK + ALSA / pulseaudio / pipewire is the graphics and audio sinks (yeah, OK... audio is still a mess on Linux).
I don't think it makes sense to argue over whether some library really
does something meaningful or is just designed for convenience. Clutter and cogl are definitely convenience libraries, yet are shipped per default with Ubuntu currently and are therefore allowed to use with the "only default package" policy. The only difference is whether it is installed by default or not,
and the set of default packages differs from distro to distro.
Also, while gtk does implement a lot, what is needed for intros makes
it more of a convenience library also.
does something meaningful or is just designed for convenience. Clutter and cogl are definitely convenience libraries, yet are shipped per default with Ubuntu currently and are therefore allowed to use with the "only default package" policy. The only difference is whether it is installed by default or not,
and the set of default packages differs from distro to distro.
Also, while gtk does implement a lot, what is needed for intros makes
it more of a convenience library also.
@kb:
I don't think you can say that the most popular distribution is the one that
is easiest to use.
In my total personal opinion, experience it is totally unexplainable that debian
based distros are still used so widely.
The only reasons i can think of are social and historic reasons.
However, Linux Mint is not only debian based but Ubuntu based, so the
problem you described is more likely to be related to gnome than to the
underlying distribution.
My guess would be Nightlight, but whatever.
I don't think you can say that the most popular distribution is the one that
is easiest to use.
In my total personal opinion, experience it is totally unexplainable that debian
based distros are still used so widely.
The only reasons i can think of are social and historic reasons.
However, Linux Mint is not only debian based but Ubuntu based, so the
problem you described is more likely to be related to gnome than to the
underlying distribution.
My guess would be Nightlight, but whatever.
Quote:
I don't think it makes sense to argue over whether some library really
does something meaningful or is just designed for convenience. Clutter and cogl are definitely convenience libraries, yet are shipped per default with Ubuntu currently and are therefore allowed to use with the "only default package" policy. The only difference is whether it is installed by default or not,
and the set of default packages differs from distro to distro.
...You're the one who brought up the subject. You can't just say this is a benefit, and then refuse to debate the details when someone disagrees. That's just silly.
Quote:
Also, while gtk does implement a lot, what is needed for intros makes
it more of a convenience library also.
Uh, no. Intros aren't about doing thing in convenient ways, it's about cramming a lot of stuff into little space.
So, i'm not a diehard "We need SDL2" proponent.
I just think it's a bad situation when some parties allow SDL2 and others do not.
So, i see three solutions for this situation:
1. Agree to allow SDL2
2. Agree not to allow SDL2
3. Use a distro where SDL2 is a default package
I favor variant 3, as it is the most clean way and
(like Variant 2) allows running intros
from a live system (if you have an AMD Card). It naturally aligns
the two policies i have seen.
I would'nt mind the other solutions, though.
I just think it's a bad situation when some parties allow SDL2 and others do not.
So, i see three solutions for this situation:
1. Agree to allow SDL2
2. Agree not to allow SDL2
3. Use a distro where SDL2 is a default package
I favor variant 3, as it is the most clean way and
(like Variant 2) allows running intros
from a live system (if you have an AMD Card). It naturally aligns
the two policies i have seen.
I would'nt mind the other solutions, though.
Or 4. don't use SDL, and go for Gtk + ALSA instead. Not at all a problem when not sizecoding, but I can understand that having one less .so to load means a welcome few "free" bytes for intros.
I am willing to discuss about the details of what different libraries
have what effect and stuff like that, i just don't think this can bring up a useful policy.
I don't think it brings us any further to argue about every single library there
is out there and decide if it is cool or not.
This is why i do like the "only default package" policy, it is quite
unambigous.
However, this definitely brings up the question of which linux distribution
to use, which is why i wanted to discuss that.
have what effect and stuff like that, i just don't think this can bring up a useful policy.
I don't think it brings us any further to argue about every single library there
is out there and decide if it is cool or not.
This is why i do like the "only default package" policy, it is quite
unambigous.
However, this definitely brings up the question of which linux distribution
to use, which is why i wanted to discuss that.
@keyj: gtk is consisting of more than one .so ^^
Using gtk + alsa would be the result of policy 2 i think.
Using gtk + alsa would be the result of policy 2 i think.
I think 3 is a pretty bad option, because SDL2 isn't a defined guarantee of the distro. It's residue of some other applications, as you pointed out. Once Fedora pulls those in via Flatpaks (which is something they are working on), SDL2 will go away by default.
The only way usnig SDL2 is going to be "clean", is if the compo rules states it's OK. If not, it's a hack. I'm not against hacks, but it's better to white-list it entirely.
And just to be clear, I'm not the gatekeeper of dependencies here, and I have run several Linux compos without disqualifying entries because they require some SDL version. But it's something I personally thing intros should avoid, and I get annoyed whenever I need to hack around some old intro's broken imports.
And we don't *need* a policy for people to have common sense and not using SDL. Some of us do the right thing because we care about our productions.
The only way usnig SDL2 is going to be "clean", is if the compo rules states it's OK. If not, it's a hack. I'm not against hacks, but it's better to white-list it entirely.
And just to be clear, I'm not the gatekeeper of dependencies here, and I have run several Linux compos without disqualifying entries because they require some SDL version. But it's something I personally thing intros should avoid, and I get annoyed whenever I need to hack around some old intro's broken imports.
And we don't *need* a policy for people to have common sense and not using SDL. Some of us do the right thing because we care about our productions.
IMO just let the party decide what's reasonable/provided.
Rules + beamslide mention goes a long way.
Rules + beamslide mention goes a long way.
Slackware or bust
Slack 98, preferably.
how about QEMU VFIO GPU Passthrough? Then you can use linux to start another linux of your own choosing! Works for me even with a single gpu
Re: SDL or no: I don't really have an opinion on this, as getting graphics onscreen will work anyway. Gtk is a bit larger due to the different GTK/GDK/Gobject library splits and requiring a callback subroutine or two, but it's not disastrous. smol and oneKpaq can make the difference quite small :p
For audio, this probably matters even less, because if you want to use a 'classical' 4k synth (like 4klang or clinkster or oidos), you'll have to include a 32-bit "sub-executables" as those synths only have 32-bit runtimes anyway. So spinning up aplay and piping to it is often the way to go, wanting to use SDL_Audio in this case only makes things more complicated.
(This raises another fun issue, though: allowing people to use full 32-bit demos on Linux would probably have a bigger impact on size and convenience than SDL vs GTK. And people still can do this on Windows, but default Linux installations don't ship with 32-bit versions of all the libraries you need, including OpenGL itself. For me as a tool maker, that's a challenge instead of a problem, though :p )
As for saying that using SDL is a "hack abusing other installed-by-default's programs", well, several recent intros have used libopus, ghostscript/libspectre, librsvg, libfftw, cogl and clutter, Python, and so on. I don't quite find this "cheating", I find it an interesting new space to explore as for what can be done with Linux intros. Windows has gm.dls anyway, so why can't we have something fun?
For audio, this probably matters even less, because if you want to use a 'classical' 4k synth (like 4klang or clinkster or oidos), you'll have to include a 32-bit "sub-executables" as those synths only have 32-bit runtimes anyway. So spinning up aplay and piping to it is often the way to go, wanting to use SDL_Audio in this case only makes things more complicated.
(This raises another fun issue, though: allowing people to use full 32-bit demos on Linux would probably have a bigger impact on size and convenience than SDL vs GTK. And people still can do this on Windows, but default Linux installations don't ship with 32-bit versions of all the libraries you need, including OpenGL itself. For me as a tool maker, that's a challenge instead of a problem, though :p )
As for saying that using SDL is a "hack abusing other installed-by-default's programs", well, several recent intros have used libopus, ghostscript/libspectre, librsvg, libfftw, cogl and clutter, Python, and so on. I don't quite find this "cheating", I find it an interesting new space to explore as for what can be done with Linux intros. Windows has gm.dls anyway, so why can't we have something fun?
