I'd love to be using an open source desktop, but sadly Linux Desktop is still a goddamn garbage fire as far as I'm concerned. Not that long ago (months) I would say that 4 out of 5 of my desktop and laptop computers ran Linux, but now that number is 1/5 because I just got sick of dealing with Linux Desktop bullshit on them. My main gaming rig runs nVidia because it is frankly best in class, and nVidia has shit Linux support so that's a no-go. I also have a used Oculus Rift, which again rules out Linux.

There's a reason Windows is still dominant in the Desktop space despite all its problems.

> Not that long ago (months) I would say that 4 out of 5 of my desktop and laptop computers ran Linux, but now that number is 1/5 because I just got sick of dealing with Linux Desktop bullshit on them.

interesting. i put ubuntu 20.04 on this and it's been plain sailing. now usually i'd say i've got a high tolerance for bullshit when it comes to linux, but i'm not exadurating when i say i did not have to touch the terminal to:

1. install it without any extra crap

2. switch from nouveau to the nvidia driver - version 440.64, a very recent driver (which isn't very fair to nouveau, i didn't even give it a try, really)

3. install steam and games and have them work flawlessly from the get-go. games i've played:

* counter-strike global offensive (a lot..)

* the binding of isaac (would be bad if this didn't run!)

* deus ex mankind divided (was _very_ surprised to see this available and working perfectly, to be honest)

* black mesa

a short list, but i've only had the machine for a week.

i know it's stupid to say "hey i didn't have to use the terminal", but really, ubuntu has come a long way. i couldn't have said that last year, i don't think.

> nVidia has shit Linux support so that's a no-go.

eh, i'm gonna respectfully disagree there. linux support from nvidia has been a bit patchy (and the nvidia driver windows isn't exactly a dream at times, too), but i've been using nvidia driver on linux on various installs on various architectures on various hardware for _years_ and i've never had a significant problem. AMD, on the other hand.. i don't miss fglrx.

> I also have a used Oculus Rift, which again rules out Linux.

well i also wont support facebook, so that's not an option for me :)

honestly, it's _really_ disheartening to see the replies to this comment and see how far the normalisation of deviance has come. the _only_ tool we have as end users to stop companies from being shit is to vote with our wallets. and yet the majority of responses is to just give up and accept that that's how it is.

i think we're doomed as a species :)

What kind of linux desktop bullshit? Has it been getting worse?

No, it just isn't getting better. Any time you want to do something even remotely interesting, like install software that is actually up to date and therefore not in the repo, you have to jump through a bunch of hoops. One of my other usecases involved a device with only a 16GB internal disk, so naturally I would like to install applications to an external disk so they actually fit. This is usually trivial on Windows but not possible with any package manager on Linux [0]. I still constantly run into issues with hardware, especially sound and video, that require hours of googling and manually tweaking config files to fix. Oh yeah, and half the time the results from google for any issue applied to the way things were done 5 years ago, which in typical Linux fashion means that there's an entirely new way to do it now that bears no resemblance.

[0] Flatpak can do it if you setup an entirely new installation on that disk, but flatpak has its own issues. Snaps can't do it at all, and while AppImage is really great relatively few projects distribute that way.

what do you mean you wanted to install applications to an external disk?

if you have a separate OS on the external drive, you could chroot in and install it. If you just want that one application to be on the other disk, you could mount it to wherever on the filesystem the program would be installed. However you probably don't wanna do that on an application by application basis. you could mount /usr/bin/ on the external drive for example. or use LVM to share disk space between the disks

Flatpak, Snap, Appimage and other portable format aren't really preferable. they lead to a software ecosystem that amounts to just downloading and running executable binaries off the internet, each with their own overhead.

> what do you mean you wanted to install applications to an external disk?

Kinda illustrates my point about this being a foreign concept to Linux Desktop people. It's pretty simple: I want to put an application on an external disk and run it from there.

> if you have a separate OS on the external drive, you could chroot in and install it.

No thanks. I'd just like to have the application stored on an external disk, and execute it on the OS I have installed.

> If you just want that one application to be on the other disk, you could mount it to wherever on the filesystem the program would be installed.

Not really, because Linux likes to have an application spread its files all over the hierarchy, so in reality I need to either use some form of union-mounting, and/or simlinks. Of course that is only sufficient if there are no library conflicts between what the application wants and what the system uses, in that case I need to use LD_LIBRARY_PATH and other tricks. In some cases I'll need to use a launch script that calls a different ld.so.

That's a lot of hoops compared to how sane operating systems do it.

> LVM to share disk space between the disks

System breaks when disk is removed. No good.

> Flatpak, Snap, Appimage and other portable format aren't really preferable. they lead to a software ecosystem that amounts to just downloading and running executable binaries off the internet, each with their own overhead.

Which is pretty much what I want, because the alternative is dealing with the bullshit I mentioned above whenever you step outside the package manager's sandbox.

NixOS gets you there I think. They deviate from the standard hierarchy to keep each application in its own directory that could be installed on it's own drive if need be, then with symlinks back to the main tree for legacy purposes. Like /bin/sh would be a symlink to /nix/store/s/5rnfzla9kcx4mj5zdc7nlnv8na1najvg-bash-4.3.43/bash but only because there's enough legacy out there that expects /bin/sh to be runnable verbatim.

Now if only I didn't need to learn a new language in addition to all the OS tooling to use NixOS.

This is what AppImage gets that the rest of Linux doesn't seem to: if an application is a single file/folder, you don't need anything more complicated than a file manager to manage it.

P.S.: after a quick glance at some documentation, I don't see any mechanism that would allow me to install nix packages to arbitrary locations anyway.

I'd like to point out that having random programs scatted across external HDDs is an anti-feature to me. I never remember which files are where as it is. And too easy to screw things up by unplugging the drive...

Nevertheless it can be done - if you are dedicated, recompile the program with the prefix changed to the mounted root of your separate drive. Presto, automated installs to your external drive. Now, linking up all the bits can still be a right headache, but this is just a bigger nightmare on Windows (what will you DO if your drive letter changes?? You mean I don't have any system to automatically link up random programs on random drives which may or may not be present. Gosh darn, that package manager sounds like a good idea now...)

If you're using a laptop, you're probably due for an upgrade in HDD capacity, or if you're lucky enough to be on Desktop I'd recommend a board with hotplug capability and using LVM. I think no matter your platform you're going to have a hell of a lot of problems doing things your way. If you can patch the package manager to be able to do this, amazing! I don't think any system exists like this, period.

You mean you want an actual installer, like in DOS or Windows? IMHO, it's crazy.

I had similar problem. I joined two physical disks into one logical using LVM and forgot about problem. :-/

> You mean you want an actual installer, like in DOS or Windows? IMHO, it's crazy.

Well that's still better, in my opinion, than package managers and all their various restrictions. But ideally I want something like AppImage, where an application is a singular entity that can just be moved at will and run from wherever [0]. Most DOS programs and many Windows programs (if you extract them from the installer) will still work like that.

> I had similar problem. I joined two physical disks into one logical using LVM and forgot about problem. :-/

If you unplug the external disk, your system stops working. This is not what I want, as I mentioned already in the post you're replying to.

[0] classic MacOS, RiscOS, and NeXT all had programs that worked like this too. Linux has yet to achieve the flexibility in application management afforded by the OSs of the 1980s.

Hmm, that's fair. I'd encourage you to try something outside of the standard redhat/ubuntu distros. Manjaro is nice and is pretty much always up to date. Also has access to the AUR, so there are packages for pretty much everything. It's a lot easier to do interesting stuff.

LVM can make two disks appear like they're one, but of course if you remove any of them they both fail. Doesn't really solve the underlying "I want to install apps outside of the root partition" problem though.

> I'd encourage you to try something outside of the standard redhat/ubuntu distros.

Generally speaking they have the same problems as the mainstream distros, but with the additional caveat of even less chance of googling solutions and worse or no support at all from non-oss software.

> LVM can make two disks appear like they're one, but of course if you remove any of them they both fail. Doesn't really solve the underlying "I want to install apps outside of the root partition" problem though.

Precisely. The very concept is just so foreign to most of the Linux community that even talking about it gets you strange looks. It is actually possible to do with some significant AUFS-fu, but its a hell of a hoop to jump through for functionality that is pretty natural in every other desktop OS that ever existed.

I've heard GoboLinux [0] does not follow Filesystem Hierarchy Standard.

[0] https://en.wikipedia.org/wiki/GoboLinux

----

What you describe is like installing in $HOME. It's not unusual - python virtualenv, ruby rbenv, node_modules. This comes with trade off - either system knows where to search or one has to define per project. By FHS entire Linux tree is a project. In Windows... configuration is pain.

Flatpak someday.

Now, as I think about it, ruby is not like FHS

    └── gems
        ├── irb-1.2.3
        │   ├── exe
        │   │   └── irb
        │   └── lib
        │       ├── irb
        │       └── irb.rb
        └── rack-2.2.2
            ├── bin
            │   └── rackup
            └── lib
                ├── rack
                └── rack.rb
    

vs

    ├── bin
    │   ├── irb
    │   └── rackup
    └── ruby
        ├── irb
        ├── irb.rb
        ├── rack
        └── rack.rb
    

FHS approach does not support multiple versions, gems approach requires declaring version in code or Gemfile, playing with PATH, considerable slowdown https://github.com/Shopify/bootsnap

I think that sums up my issues with desktop Linux: any user has at least some niche requirements. For mine they are fairly doable on MacOS/Windows, but they require hours of staring at documentation and downloading/compiling source code in Linux.

I still write code in a Linux environment because that's where the ecosystem is, but for my daily driver I've given up on desktop Linux. And I've found that WSL gets me a Linux based development environment side by side with Windows with less pain than dual booting. I've found that when it comes to using Linux smoothly, it's a lot easier to shoehorn myself into the happy paths than to bend my setup into my way of doing things.

As a game developer, for most mid-tier inside titles releasing Linux version costs more than it makes, so, no.

And regarding using Windows: company's behavior is important, but product quality, especially when it's a tool you use every day for work, is more important. Linux is ok for certain types of developers, it's still awful for normal users, abysmal for office work and obviously not a choice if you develop Windows software.

> As a game developer, for most mid-tier inside titles releasing Linux version costs more than it makes, so, no.

What are the main costs of releasing a Linux version of a game when using Unity or Unreal? My limited experience with Unity has been "check the Linux box, click the build button". It even cross-compiles no problem. People I know tell me Unreal is similar.

It's not like they have to do a full run of play-testing for Linux. Just check if it starts, play for 10 minutes and release that. We know we're a minority so we're willing to put up with bugs. Even if there's only 100 people who'd buy it only if it ran on Linux, that should pretty much cover the couple hours of dev time.

I can tell you've never released a popular product on Linux. It's a lottttt more effort than you're implying. To do it well, you need to have Linux as a target from the start of your development, it's not something you can tack on to the end. Linux graphics drivers are very different from Windows (the AMD stack isn't even the same codebase). Linux window managers are... wild. You need to build to an ABI that will be supported across distros, which mostly means the Steam Runtime, which means you need to go learn about and understand that. You can't introduce any platform assumptions ("ehh, I'll just hardcode this path with a backslash... oops"). Once you release, you're talking support for dozens of different distros, different versions of distros, different package managers, different filesystems. I know what you're going to say: "Just support Ubuntu LTS and ignore everyone else". Well, now you've just cut your customer base by at least 75%[1], and your customers on other distros are going to demand support anyway. Do you tell a paying customer to F-off because they're not using a distro with only ~20% of the market?

Supporting Linux is hard. So is supporting Windows, but if Windows makes up 98% of your customer base, it's justified. 2%? Ehhhhh.

(P.S. I love Linux. See my profile. This is the kind of stuff I deal with every single day.)

[1] https://boilingsteam.com/we-dont-game-on-the-same-distros-no...

Yeah, the solution to a platform not making enough money to justify supporting it is... giving away your game for free! The self-centered attitude of your comment is astounding, but all too common in open source communities.

You don't have to give your game away for free. I urge you to look into how prominent open source companies are actually making money and think about how it can be applied to games. It's not an impossible reality.

You claim I am being "self-centered" but the fact is if you don't provide something that the distros can work with and instead try to route around everybody and ship an untestable blob then that's your fault. The reason everyone tells you to just support Ubuntu LTS is because they are the only ones who have the resources to support all these random binary blobs for X amount of years, and that comes with all the pains associated with it, as you are well aware of.

> You claim I am being "self-centered" but the fact is if you don't provide something that the distros can work with

Alternative view: distros don't provide a stable platform that developers can target.

Linux LTS releases are not particularly stable from the perspective of someone who wants to distribute applications as binaries. Its API can change with every release, i.e. every two years. It's incredibly unlikely that a binary compiled for Ubuntu 18.04 will be able to run on Ubuntu 20.04 (as in Python etc.).

To contrast, if you take a Win32 game from 2003 that targets DirectX 9, it probably runs fine on the latest Windows releases. (You might have to enable some compatibility mode.)

"BUT BUT BUT if it's packaged with the distro it's no problem." Remember we're talking about proprietary applications (mostly games) here. Having these packaged with distros for years after the devs moved on to the next project is just a pipe dream.

These prominent open source companies that you're taking about make money from consulting or cloud services. There's no well understood and well rested way to do that as a game company.

It doesn't mean that there's no such way, but it does mean that attempting to find it is very risky. Making games is already a very high-risk, high-reward industry, do adding this amount of risk to the equation is advice that's insane for all but most successful companies.

A multiplayer game is just like any other cloud service in terms of economics. And a game that allows a certain degree of customization is analogous to a consultancy. Find the pain points your business customers/partners are having and then charge for solutions. If you don't have any business customers/partners then get some, not having them is a much bigger risk than choosing any specific development model.

One of the ways these companies can reduce risk is actually by using other proven open source components. If they won't even make an effort to try to expand this, then there will never be a well-understood way.

> A multiplayer game is just like any other cloud service in terms of economics.

No, it's not - this is an absurd statement. Cloud services get most of their income from big and medium companies, billing tens and thousands of dollars in privately negotiated agreements. Digital Ocean and AWS don't live on single developers paying them $5. All their real money is on B2B.

Multiplayer games either get a flat subscription from all their playerbase, or rely on micropayments. Either way, they spend much less on account management where they interact with customers as individuals, and much more on analytics, where they measure and work with their customers in aggregate. These are completely different business models, that completely shape companies that operate on them.

> Find the pain points your business customers/partners are having and then charge for solutions.

Games are not solving any problems - they are entiertainment product. I've seen people who have tried to reason about games in the terms you're using, and it always yelded hillarious (but also sad) results.

Open sourcing doesn't mean you need to provide all the souds/music/3d models/assets/etc. Those can all be copyrighted separately.

> Open source your games. Open source is the only practical way that existing distros are able to test and support the majority of packages that they ship

Which might be one of the reasons Linux Desktop is so awful to develop for.

The "Linux Desktop" is not and has never been a thing beyond a vague marketing term. What you're thinking of is a loose collection of unrelated projects. Pick a single stack and go with it and things get better.

....Which might be one of the reasons Linux Desktop is so awful to develop for.

You wonder why people ignore your platform? Saying it isn't actually a single platform and instead is dozens of different platforms just means each of those platforms is even less relevant. Saying you're not just one platform with 10% market share but actually 20 with 0.5% each doesn't make the case for shipping on Linux Desktop any better.

I'm not making a case for shipping on the "Linux desktop" because that doesn't exist and has never been a real platform. Most smaller distros are not trying to be "relevant" to whatever the gaming community's fad of the day is. They're perfectly fine filling what niche they do. If you want to target those smaller distros as a platform, you can give them some source code to work with, or you can pay all the cost of maintaining things yourself, or you can just ignore those. They will do fine without your game.

So what are you saying? Developers should just choose a major distro and target that, then get all the flack for issues their product has on every distro that isn't supported? Because that's basically what's already happening and developers hate it, which is why they often don't ship on Linux at all.

And many proprietary pieces of software license components from other proprietary pieces of software, so that even if they did want to open their code they'd have to strip pieces out of it anyway which doesn't really help the cause of distros integrating it. And even if it did, then the developers are reliant on the maintainers for their relationship to their customers. Have an issue with the product? Oh, it turns out that's because of this patch made by the maintainer of the package for that distro, who now has to be contacted and convinced to fix it, which they may decide not to for arbitrary reasons. Even open source developers have problems with this!

In general, distro maintaners can't help you with legal conundrums you created for yourself (you signed restrictive NDAs and proprietary license agreements and didn't consider the fine print until it was too late) or with other unrelated market problems (lack of popularity, lack of developer interest in supporting your game).

If you need to strip out some parts and there is enough will in the community to replace those pieces that you stripped out, then it will happen. If you have a product that is anywhere near being popular among the FOSS developer communities then I don't think it makes sense for you to claim that this will doesn't exist, or that distro maintainers will lose interest.

> What are the main costs of releasing a Linux version of a game when using Unity or Unreal? My limited experience with Unity has been "check the Linux box, click the build button". It even cross-compiles no problem. People I know tell me Unreal is similar.

For a simple game that uses the entire UE4 stack, you might be able to get away with that if none of your code is Windows-specific and works exactly the same on the Linux distribution you are targeting. Once you start using your own middleware and libraries from outside of the default engine, you need to make sure every single one works across all the platforms you're targeting. Many won't have a Linux compatible version, and those that do may only work against specific distributions and hardware. Even then: Have they changed the window manager? What have else they customised?

There have been many issues with anti-cheat solutions over the years on Linux.

> It's not like they have to do a full run of play-testing for Linux. Just check if it starts, play for 10 minutes and release that.

For a simple game, you may get away with this. Anything larger will require significantly more testing. I've been a producer on large games, and the QA process starts very early on. You don't 'finish' a game and then QA starts - It's an ongoing process that consists of significantly more than just launching a game.

>We know we're a minority so we're willing to put up with bugs

Some people don't see it that way though. People who have paid for a product have the right for it to work properly. Tickets for Linux support are often higher [1], so the time investment against payback can be problematic.

GPU driver support on Linux can also still be problematic. From feature differences against Windows, to crashes. These all take additional development time. Linux developers are often more difficult to acquire in the game dev world. QA even more so.

Game dev is really hard. Some of it is hidden by engines like UE4 on the surface, but as soon as you start digging down into serious development, it's difficult.

[1] https://twitter.com/bgolus/status/1080213166116597760

Probably the most relevant issue here is the DirectX stack or using some windows specific API (why? DirectX I maybe got at one point, the others speak to some absurd Microsoft-Is-Best-Cause-I-Paid-Money-ism).

> Many won't have a Linux compatible version, and those that do may only work against specific distributions and hardware. Even then: Have they changed the window manager? What have else they customised?

Outside of truly exotic window managers, the biggest issue I've ever seen with ports has to do with dependencies. Flatpack/Snaps solve most if not all of those problems.

> There have been many issues with anti-cheat solutions over the years on Linux.

That's assuming anti-cheat systems are ethical, even. Most games I play I want to be multiplayer, and moddable. Most games I play can do both of those things and work in a cross platform modding language. Not hard. I don't want any anti-cheat systems for a complex game with tons of modding.

The only place anti-cheat systems make sense is with e-sports style games. Of which, the best anti-cheat systems work server side. Anything else is invasive and tantamount to illegal spying. Shame on you, go burn in peeping Tom hell you perverse game dev.

> For a simple game, you may get away with this. Anything larger will require significantly more testing.

I find this incredibly hard to believe. If you are working within the engine the majority of the time, the majority of the game will play wherever the engine works. Which brings us back to one of your first comments:

> For a simple game that uses the entire UE4 stack, you might be able to get away with that

For which games are you not just using the UE4 stack? I.e. what specific problems are game devs normally experiencing causing their code to be non-portable? A bunch of low level assembly code and non standard C++?

> but as soon as you start digging down into serious development

I challenge you to define 'serious' development. That sounds suspiciously like you're wasting your time fighting infrastructure, or just doing things in a non-portable manner. Solving problems is cross platform, so you can't be doing much serious game coding, its probably problem solving for your particular platform (e.g., as I already mentioned, doing a bunch of work in DirectX shaders or something).

Well, I've been working with Unity for 11 years now, but my experience with building for Linux is limited, so I'll go with experience from mobile and console development, and say that with shaders (which never ceases to surprise with platform-specific glitches), filesystem (although Unity is supposed to abstract it out, once you get serious about resource management, this abstraction starts to leak), input (because you want to support gamepad with minimum hassle for the player), and million of unknown unknowns that hopefully will be found by QA, but realistically, by very angry players, I'd budget at least a couple of man-months for this. With sales in hundreds or even tens of thousands, we can expect to get about 2% of audience from Linux, which will account for single-digit thousands, or hundreds of copies sold. With a price tag of $10-20, after Steam cut, taxes, regional prices, sales and refunds, it's about $5-10 of revenue per unit, so in total, about $10k.

If that would just be the money a single developer got for 2-3 months of work, it could still be fine for some regions (not everyone on HN is from US). But with a studio, you also have to spend money on marketing, payroll taxes, rent, and development of future projects, which most likely sell even worse.

So, no, I really don't see how porting to Linux would pay. Most of developers that I talked to who did it admitted that supporting OSX and Linus turned out to be a giant waste.

I think there's merit to the argument of 'big corporations can't get things done efficiently' here. I think as you mentioned, for a small scale dev it can be done. I agree, shading could be better across platforms, graphics card manufacturers, even, but that all pales in comparison to a large inefficient corp making grossly over-complex games with staggeringly little added value per hired developer (oh yay another 1mil triangles added to the 100th remake of the same garbage FPS or NFL game, extreme sarcasm).

But outside EA Games e.g., some of the best games I've ever played were written by solo devs in a cross platform engine you may have heard of called Flash. Yeah, not always smooth sailing on Linux, but it worked, pretty well even.

> Linux is ok for certain types of developers, it's still awful for normal users, abysmal for office work and obviously not a choice if you develop Windows software.

Don't want to get into an OS war here but merely stating your opinion as fact without supportive evidence is not in the spirit of HackerNews.

> it's still awful for normal users, abysmal for office work

For office work a lot of workload has moved to the web browser. Creating documents and working on spreadsheets for instance can now all be done online with Microsoft's Office offering and other competing products like Google Docs.

And why is it awful for normal users? ChromeOS for example is just linux, and that whole platform is targeted towards 'normal users'. I use linux on all of my personal devices and I use these devices to do very 'normal user' activities like watching YT, social media, blogging, etc. There are many communities that consist of 'normal users' like /r/Thinkpads or /r/LinuxOnThinkpad that are currently enjoying linux.

Precisely why do you think it's awful for normal users and office work?

> Don't want to get into an OS war here but merely stating your opinion as fact without supportive evidence is not in the spirit of HackerNews.

These things are pretty much self evident.

> Linux is ok for certain types of developers

Web developers and HP computing. Game developers? Haha, no. Embedded? Too many proprietary toolchains that don't run on Linux. Productivity and business applications? See below section on office work. ML? nVidia [apparently I'm incorrect on this one].

> it's still awful for normal users

Alright, this is a bit subjective, but is supported by the stats that show Linux Desktop still in a distant and well deserved third place. You list a few tasks that you seem to believe are "normal user" tasks, I submit to you that you drastically underestimate the things a normal desktop computer user does with their computer, since most of the tasks you listed are now things that people do on phones and tablets.

> abysmal for office work

In most offices, Microsoft Office is an indispensable productivity tool (which many HNers, having little experience with real office work, will underestimate severely) and it is only supported on Windows (No, the web version is not the same).

> Embedded? Too many proprietary toolchains that don't run on Linux.

It's funny/surprising that you'd say that, given that Linux is the single most dominant OS in the embedded device space. What toolchains are you referring to? Here are some well known ones.

https://www.yoctoproject.org/ https://www.ptxdist.org/ https://openwrt.org/

> ML? nVidia [apparently I'm incorrect on this one].

Not only are you wrong about CUDA, but Google's custom built chip designed for ML runs soley on Linux: https://en.wikipedia.org/wiki/Tensor_processing_unit

ML almost exclusively runs on Linux.

> and it is only supported on Windows

Office also runs on macOS. You can also run Office in Linux using WINE.

> Alright, this is a bit subjective, but is supported by the stats that show Linux Desktop still in a distant and well deserved third place. You list a few tasks that you seem to believe are "normal user" tasks, I submit to you that you drastically underestimate the things a normal desktop computer user does with their computer, since most of the tasks you listed are now things that people do on phones and tablets.

It's really easy to say anything without providing any supportive evidence to substantiate your claims. Pray tell what tasks you are referring to that "normal users" partake that supposedly can't be done in desktop linux.

>It's funny/surprising that you'd say that, given that Linux is the single most dominant OS in the embedded device space. What toolchains are you referring to? Here are some well known ones.

No, and no.

The parent was referring to embedded development toolchains - compilers, IDEs, endless small utilities, debuggers, analyzers, etc. etc. Commercial tooling is almost all Windows-exclusive, even if it's using a smattering of open-source bits underneath.

Also no. The "embedded device space" is v a s t. New projects for phones and similar hardware profiles might choose an Android or other flavor of embedded linux, for sure. Even within sexytech consumer products you're more likely targeting something like VxWorks or QNX as not. The physical world, the domain of embedded devices, is not smartphones and SaaS. Unless you're talking about a very specific product category it's laughable to call Linux dominant here.

> The parent was referring to embedded development toolchains - compilers, IDEs, endless small utilities, debuggers, analyzers, etc. etc.

I know what the parent was referring to.

> Commercial tooling is almost all Windows-exclusive, even if it's using a smattering of open-source bits underneath.

No it's not. Literally both of the embedded OS' you mentioned (VxWorks/QNX) support Linux as first class hosts.

https://blackberry.qnx.com/en/software-solutions/embedded-so...

https://www.windriver.com/support/site_configuration/docs/wr...

What Windows exclusive tooling are you talking about?

And you are understimating the prevalence of Linux as the embedded OS for embedded devices.

ML is actually mostly done on linux. CUDA works absolutely great with nvidia binary drivers. Display performance is irrelevant.

Because when I open a 300-page, media-heavy game design document in Google docs on my i7, 32gb computer it still lags when I scroll it. And the last time I tried to use OpenOffice (or whatever was the fork called, I mix them up), I couldn't shake the feeling that UX was created by developers who just wanted to check the boxes in the list of features, without any field testing whatsoever.

> not a choice if you develop Windows software

A minor nitpick, but cross platform development is usually a painful work regardless of which platform you use.

I, for one, like to use my computer. I do not have time for my computer to be some battleground of political OSS zealotry.

seriously, the problem is apps wanting unfettered, opaque access to your system and data. If the default Steam install can r/w everywhere, anti-cheat needs kernel modules and a game can install a Trojan (like recently exploited with Source) - I say: no thanks to that, have a VM for gaming and all proprietary stuff and say a big fucking NO to the shshow the "games" ecosystem as a whole is...