After suggesting a developer drop Linux support, Vivox have released a statement | Hacker News Reader

After suggesting a developer drop Linux support, Vivox have released a statement

gamingonlinux.com

75 pointsdejaime97 comments

At least for high performance C++, the Linux toolchain improves code quality by so much. Between valgrind/cachegrind, asan, efence, always having the latest clang and clang_analyzer, and Dockerfiles for continuous integration environments, programming on Windows feels like I have a hand tied behind my back.

Even something basic like replacing malloc with your own instrumentation to track errant allocations is basically impossible since every DLL in Windows loads its own allocator.

I know Windows has similar tools but wrangling Visual Studio, especially remotely or across multiple developers, is significantly more painful in my experience.

Even if you don't ship on Linux, programming on Linux is worth it imo. I mean, Carmack wrote Quake on a NeXT and shipped on Windows, so if he was doing it back in the day, how wrong can it be?

Really? I regularly manage to get most of the linux toolchain to bork, and have particular "fun" getting the profiling tools to work properly.

And never mind getting a nice IDE environment like Visual Studio up and running.

So it may just be a matter of familiarity and/or the particulars of the projects you work on.

Here getting a nice IDE installed is just a single "zypper install qt-creator".

You need a license for qt-creator if you want to work on commercial software (or that was the case last time we checked about a year or two ago). There might be exceptions for your case, do check, because it is a nice product. Other paid IDE alternatives are CLion, which I hear is excellent, as well as SlickEdit, which is closer to an editor than a full IDE, but does offer building, debugging, completion.

Free alternatives would be Visual Studio Code, which is pretty ok even for C++, or KDevelop, which almost kind of works, or SpaceVim / SpacEmacs and about a week of learning how to use it. I'm in the final camp, since basically every serious C/C++ dev on Linux has a Vim or Emacs setup they've built themselves that does about 90% of what Visual Studio gives you out of the box, with some things better and others worse. It can work pretty well, but you have to understand it's not VS and it works in its own way.

If you have the money, you can buy a good IDE for Linux. Otherwise, learning to make your own out of high-level building blocks is also a useful skill, but takes a little bit of time. Personally the first time I had to write C for Linux out of college it did take me about a week before I was up to speed with it (but I was already sort of familiar with vim as a pure editor).

Could you provide a reference to why you think you require a commercial license for QtCreator to work on commercial software? The core application is licensed under (L)GPL. The commercial version adds a few specific features. I have been using QtCreator for a long time and as far as I know there's never been any sort of "cannot be used for commercial software" clause.

I think they're mistaking Qt Creator with Qt itself. Certainly if you're using Qt in your application, you need a license or release as L?GPL. The IDE/editor has nothing to do with it.

LGPL (and not GPL) specifically means that you do not need to release your application under an open license.

Small parts of Qt for specialized applications are under GPL, and abiding LGPL in embedded hardware is hard, but for normal desktop software it's not a problem.

If you statically link to QT, that’s a derivative work so you need to release as GPL or buy a proprietary license.

That's why approximately nobody links Qt statically on desktop systems. (technically you can also share compiled, proprietarily licensed object files a customer can re-link themselves, but I suspect that's even rarer) I should maybe have clarified that above what obligations the LGPL does bring, but that case basically matters only on mobile and embedded.

Based off of Qt's comparison between their commercial and open source licenses, you would only absolutely need the commercial license if you were making modifications to Qt itself instead of linking to the shared libraries. Even in that case you could simply publish your Qt modifications as GPL seperetly.

https://www.qt.io/download

This is like saying all software written with Emacs needs to be GPL.

I mean... that's a valid analogy - but still, RMS would be absolutely for this.

> You need a license for qt-creator if you want to work on commercial software

No, you do not need a commercial license for creator, neither did you at other points in the past few years.

VS code is more of a text editor, not an ide.

Those lines have become increasingly blurred.

I.e. a browser.

You can use the IDE without problems. It's like Gimp, for an example. It is GPL, but you are not incorporating the software itself.

Even though I would argue QtCreator is only bearable when working with Qt.

"And never mind getting a nice IDE environment like Visual Studio up and running."

I guess I'll just have to settle with using Visual Studio Code for linux.

So what? I don't agree with you at all but it's irrelevant, the important thing is that the tools are there and they make your code more robust.

If you're willing to sacrifice the stability and performance of your output for a saccharine IDE and its installer then that really speaks more to your priorities as an engineer.

They are serious tools for professionals and you have to learn how to use them. I don't know why people think they should be able to use things without training these days. Once you know what you're doing, the toolchains are solid as a rock.

Just a teensy bit condescending there?

You mean like

- gdb randomly sucking up 16G of ram - gdb crashing with internal errors - clang/gcc miscompiling my code - perf refusing to record stacks - perf refusing to symbolise stacks because it's having a disagreement with the compiler people about debug data formats.

- locking up X11 and having to SSH in to fix it (because, you know, X11 doesn't have per-application input queues, unlike WindowsNT3.5)

- and a ton of other minor little annoyances with hardware support that Mac/Windows ironed out years ago

I like Linux a lot, the tools are great, but let us not pretend they are all that, they still have a way to go.

You say "ironed out" but what I think you mean is "layered on top of each other and ironed together; impossibly thin."

I feel like developing on Windows is more difficult because of all it's abstraction layers. WMI, DCOM, the registry, overlapping snap-in functionality, ect.

To me programming on Windows feels like you've got to peel apart all these layers to understand what's between them. Linux is one layer and you can already see right through it.

> - and a ton of other minor little annoyances with hardware support that Mac/Windows ironed out years ago

Uhh, did you just say that Mac has ironed out harware support? For what? They only support their own hardware. The hackintosh community will be the first ones to tell you that Apple purposely doesn't iron out hardware... ANYTHING unless it already says "Apple" on it.

For the first half of that, I was pretty sure you were still talking about Visual Studio. That's...pretty much what I'm looking at with VS on my computer right now.

I do most of my C++ dev on Linux and I prefer it that way, for the reasons you mentioned.

However, Windows has great tools too. And by that, I mean Visual Studio. In particular, I really miss its debugger when I am on Linux.

It is just a different philosophy with its pros and cons. On one side, you have a lot of small, loosely coupled tools, text files and command lines. On the other you have a well integrated monolith and GUI.

Yes, but these days Carmack swears by -- wait for it -- Visual Studio. Microsoft developer tooling has a reputation for being absolutely top notch. The integrated debugger alone makes Visual Studio well worth it; nothing even remotely comparable exists under Linux.

I'll dispute this because I find the jetbrains IDE on Linux to be comparable. If you're talking specifically about C development then I'm not sure because I haven't written C in a long time, but for Java, Python, JS the jetbrains products work as well as VS for me.

I was referring specifically to C and C++ development, for which JetBrains CLion is supposed to be pretty good, but still nowhere near as comprehensive as Visual Studio, particularly when it comes to debugging. In fact, concerning gaming specifically, one of the reasons why DirectX won the API wars is because Microsoft included a GPU debugger for DirectX with Visual Studio. I think Vulkan might have comparable tooling, but OpenGL emphatically did not.

NeXT wasn't Linux. My understanding is that it was a completely proprietary POSIX based operating system. That being said there is something to be said for POSIX based (unix, linux, os x), terminal based development tools. It's where most of the innovation happens in the developer community.

There is also something easy about GUI based development and debugging on Windows. A runtime environment that is fairly standard for gaming is also a big plus.

NeXT wasn't Linux, but the point being made was that it would have been easy to dismiss NeXT as a "fringe" platform at the time. It is an argument for developing with platforms [and porting to them] when they may not be a priority for your end users.

It wasn't Linux but was based on mach Unix iirc. And they weren't cheap.. but they were cheaper than a similar horsepowered SGI workstation at the time, iiarc. But probably 10x the cost of a Windows machine.

Actually it was Doom that was developed on NeXT. A big advantage of doing development on NeXT vs DOS was that dereferencing an errant pointer couldn't take down the whole machine.

https://en.wikipedia.org/wiki/Development_of_Doom#Programmin...

>NeXT wasn't Linux. My understanding is that it was a completely proprietary POSIX based operating system.

NeXT was BSD with a Mach kernel.

It was, in most significant ways, proto-MacOS.

> Carmack wrote Quake on a NeXT and shipped on Windows, so if he was doing it back in the day, how wrong can it be?

This claim has mutated so grossly over the years it's comical. I clearly recall reading back in the day, probably in Dr. Dobbs Journal or Game Developer Magazine, that the NeXT Cube was largely used just for tools like the level editor, and they were generally seeking uses for the novel machine.

It was not the primary development environment. They only had one of these expensive machines after all, and the photos I saw from the era were of designer Tom Hall using it [1].

Do you really think John Carmack and Tom were sharing a computer while they hurried to create Doom?

From the caption for the NeXT Cube photo in the linked gallery showing Tom Hall, it's clearly his machine:

  This picture was taken during DOOM development in 1993.
  Tom's busy working on a map in my map editor, DoomEd,
  but don't worry - you won't be able to make out anything on
  the screen! Tom started many of the original DOOM maps and
  after he left, Sandy Petersen finished them -- some of the
  maps had very little work done to them, in fact.
 
  On Tom's monitor is a little printout that says, "Quality".
  He always has notes stuck to his monitor to keep him
  reminded of .... things. That orange thing could very well
  be the very first keyboard wrist pad -- made by a friend of
  his back before you saw them in stores. The speaker at the
  far right is one of the first Altec Lansing clamshell
  models. The microphone in front of Tom was there for
  NeXTSTEP's awesome email feature - built-in voice emails! We
  always sent them back and forth... I think I might have some
  of them lying around here...

[1] https://romero.smugmug.com/Video-Games/The-Archives/i-T8gzwx...

Edit:

It's possible they all moved onto NeXT machines after the success of Doom, but I am not aware of it. The NeXT tooling was not mature at the time and targeting x86 Windows/Dos from NeXT would have been a real nuisance. That's why it made sense for tools, since they could develop and run them on the NeXT machine.

Actually, I stand corrected, if Romero's account here is honest they appear to have done it all on NeXT. This is entirely inconsistent with what I read at the time:

https://web.archive.org/web/20070305165006/http://rome.ro/20...

Mobile friendly quote:

> This picture was taken during DOOM development in 1993. Tom's busy working on a map in my map editor, DoomEd, but don't worry - you won't be able to make out anything on the screen! Tom started many of the original DOOM maps and after he left, Sandy Petersen finished them -- some of the maps had very little work done to them, in fact.

> On Tom's monitor is a little printout that says, "Quality". He always has notes stuck to his monitor to keep him reminded of .... things. That orange thing could very well be the very first keyboard wrist pad -- made by a friend of his back before you saw them in stores. The speaker at the far right is one of the first Altec Lansing clamshell models. The microphone in front of Tom was there for NeXTSTEP's awesome email feature - built-in voice emails! We always sent them back and forth... I think I might have some of them lying around here...

Kudos for looking into it, and offering a correction. If you don't trust Romero's account for some reason, you can find this corroborated by Carmack (his only answer on Quora [1]).

[1] https://www.quora.com/profile/John-Carmack

I don't see the big deal. They don't think Linux support is worth it. So a developer chasing Linux support won't use them. Salesman says what he needs to trying to close the deal. Kind of a dumb thing to say, but... Us Linux users are used to being second class citizens in the consumer software world. Vivox just won't get our money either. Eh.

That's because the developer's OS support is outside of Vivox's prerogative. They tried to change the developer's plans because they couldn't fit in them. If their reply had been something along the lines of "We don't support Linux and can't help you with that" I'm certain most people would be fine with it.

Their original reply makes me think of a hotel that can't accommodate a family of four so they suggest you leave the kids to the grandparents and go on vacation alone. It solves their problem, not yours.

>> They tried to change the developer's plans

They suggested the developer change plans. I agree it was a bit of a dick move to suggest that and I think an apology and training is in order, but... I'm surprised there's a need to "issue a statement".

I saw the post on Reddit, and I was a little shocked. When I switched to Linux on my primary computer, it was like Steam automatically filtered out the games I didn't like. I immediately spent some money on other games with Linux support.

So, there's a market, and it seems to be getting larger over time. What's troubling to me is that the Vivox employee seemed to think the developer just didn't know that Linux was a smaller market, or hadn't bothered to make a rational decision.

Then again, I also play things like Adventure, and the odd round of Lemmings.

Proton on Steam makes so many windows games work on Linux. For now, its THE main reason I will not leave Steam. No other platform has given as much love for linux.

I think that Valve/Steam has given more love, earlier and more consistently for Gaming period than anyone else. Yes, they make money. They also work with larger communities to improve the experience for users and gamers. I'm not really a gamer though. I play for a few hours here and there a handful of times a year.

Serious question, as I haven't looked... Does proton work on MacOS? In any case, planning on switching my desktop to Linux in a few months when I put together my next desktop (Yay, Zen 2).

Proton really does take Wine to the next level. Even a behemoth like Witcher 3 runs smooth as butter (better than on Windows according to some).

I wonder if the increasing popularity of Proton will mean more developers will simply stop targetting or porting to Linux. Games like Tomb Raider and Hitman got proper Linux releases that run great. Will we see a drop in quality with Proton? Or will Proton simply mean that targetting Linux becomes cheaper? That is, there is still a need to perform proper QA of course, but only a minimal amount of coding (mostly fixing bugs found during QA).

Middleware company is right. Supporting the platform is not worth the trouble. Data shows again and again that Linux gamers will be a fraction of a percent of your customers but generate an outsized amount of support tickets. Most of these support tickets will require holding their hand through basic Linux box administration.

> Most of these support tickets will require holding their hand through basic Linux box administration.

Yeah, customers can be so dumb.

https://github.com/valvesoftware/steam-for-linux/issues/3671

rm -rf "$STEAMROOT/"*

Now, don't get me wrong. I have a dedicated win10 partition for gaming. I gave up that fight a long time ago.

You're not helping your case by pointing out the platform's standard practice for installers is to use a language from the '70s that makes it trivial to write "rm -rf /", and (as that ticket indicates) the command will carefully work its way through all connected devices, including external drives.

You are not helping your case either by pointing out a dev's inability to handle a well documented language with known pitfalls that has been in use since the 70's.

If they can't write bash scripts there are a lot of options to install, update and remove software with built-in fail-safes.

That language also makes it trivial to make a safe wrapper function for "rm" which validates the arguments and prevents accidents.

I game mainly on Linux (since most games interesting to me happen to be on Linux).

Valve has been and is doing a lot of work to expand Linux support. I wonder where Linux gaming would be today without them.

I thought for sure SteamOS and the various Steam Machine “consoles” would create a critical mass, but it seems to just be going considerably slower than I would have predicted. I’m hopeful, but I don’t see the economics adding up right now

Critical mass starts with you. If you want to play video games on Linux, support developers and games that you can plan on Linux.

Developers should be quite right then ditching that middleware company and finding something professional instead, that works on Linux.

Most common closed gaming middleware works on Linux today (Wwise, Umbra3D and so on). And that's besides open source options of course. So the above is very unprofessional view.

Wwise only works on ALSA, it doesn't work on OSS or JACK or ESD or whatever some user's preferred sound daemon is. Or at least didn't when we had users complain about it. Fragmentation is a serious issue, and Linux users demand that developers implement one solution because they believe it to be technically superior.

You can use ALSA apps on pulseaudio systems. Pulseaudio and ALSA covers really big percentage of Linux installs.

Doesn't it work with PulseAudio? Using raw ALSA doesn't sound common. And there are plugins for such cases.

Linux as a whole is moving towards Pipewire anyway: https://pipewire.org

That will take time still.

Now yet ANOTHER way to do audio on Linux? Oi vey...

https://www.xkcd.com/927/

It's a good evolution over Pulse and Jack. Partially driven by Wayland security model too. So I see no problem in doing the right thing here.

And I don't like that xkcd in general because it's missing the point. Its basic idea boils down to "don't improve anything because it's another new thing" which is outright wrong. Not every design can be improved incrementally.

It's still possible for a new interface to provide a compatibility or translation API for prior software.

Sure, and it's already done for Pulse / ALSA for example. Pipewire can do the same if it's possible.

Pipewire can also route video, silencing once and for all the "muh network transparency" whiners who are dragging their feet on switching to Wayland.

I've always felt that choosing Linux implies some sort of technical proficiency, or at least willingness to learn. Are those days over?

Linux implies a level of user arrogance and heavily implied it's the developer's fault and inability to understand how things the way they are. We can only test on so many configurations, and users will complain when their distro, or sound server, or preferred desktop environment isn't supported. If you don't think that last one matters, what happens when a certain obscure floating WM doesn't focus the window in an ICCCM-compliant way (WM_TAKE_FOCUS) and as a result, no keystrokes are delivered to the window. I had to fix that, for one user who was very loud on Twitter about how we clearly don't care about Linux. The total number of Linux sales was less than 0.1%, but cost us way too many support tickets and weeks of developer time.

That's pretty silly. If you have enough technical knowledge to use a non-default window manager, I feel like you should have enough self-awareness to know that you shouldn't necessarily be catered to by devs. I primarily use Linux on servers, though. Maybe I don't get the mentality of a Linux Desktop user.

Sounds silly, yes.

OTOH I've never met one of those users, so unless more devs chime in to tell me this is fact ir someone can point to a number of mailing list post, issues or other verifiable artifacts I'll be tempted to assume it is a strawman.

Sounds more like an anecdote than a strawman.

Linux works best for people who just install it and use it, -and for people who are willing to learn how to fix it if they break it, AKA "grandparents and/or techies".

About 10 years has passed since I concluded that Ubuntu was more userfriendly than Windows. I had "installed"[0] Windows on someones computer and it took 4 hours to get it finished from pressing the power button the first time until bthe last nagware antivirus was gone and the computer was ready for use[1].

By comparison an Ubuntu installation at the time was 20-45 IIRC minutes depending on disk speed.

Ubuntu would the be ready to write a document, create a spreadsheet and browse the Internet, everything the typical user would wish.

There's only a few things Windows would do better at that time, most notably running Windows-only software and look familiar to Windows-only users.

[0]: or configured, it was supposed to be preinstalled so no idea why it used two hours just to get me to a login screen.

[1]: I've been a sysadmin so I'm well aware that Windows can be slipstreamed etc, but my experience here is what an end user would see.

I've seen this sentiment quite a bit; it's an oddly romantic view of systems administration.

Most of the time you're hunting through documentation to find the correct settings. It's nothing new in general, it's not some kind of exciting math that's new to you, and you're rarely actually learning how the thing works. It's mostly trying a series of things until you figure out that some strings go in a place.

I appreciate it more when I'm writing software, but largely because I can actually invest the time to really solve the problem, that it fucking stays fixed, and that people will get back hours of their life that would otherwise be spent getting frustrated and searching aimlessly.

Linux on the desktop is very nice and easy to use, once installed & configured.

However most people dont know how to install or configure Linux, Windows (or any other OS) on their devices.

This also happens to be the reason why Linux is not popular on the desktop; it lacks the strong relationship with the OEMs that gets an operating system pre-installed.

The original response was of course stupid. Developers should just use Mumble instead anyway. It's open source and not locked into any specific platform.

While I as much as anyone else would love to promote Mumble, the project is certainly languishing nowadays. Last stable release was two years ago and its not like they have nothing to improve on - the stable release is still Qt4 based and the Qt5 version has been in git for over a year now.

I'm positive if you polled developers today Mumble would be missing critical features or performance characteristics that Teamspeak / Vivox are working on to improve while Mumble is stalled out because the money isn't there to keep up healthy maintainership in the long run.

Yes, that can be a problem. But if developers who need it would invest money in Mumble instead of all these blob middlewares, it could progress faster.

This is a very whistleblow-y article. Sensible commenters here correctly point out that a 3rd party vendor shouldn't be sending messages like that, it was unprofessional and ultimately pointless. But the point of the article and subsequent community backlash is the same old self-servicing trope that linux gamers seem to love: "We're here, we're important, we spend money, you are stupid to ignore us!"

It's the same thing every time and it's getting old.

Alternative title: "Company release PR statement saying the same thing less antagonistically without actually changing their mind".

That's not at all what the article shows.

I read the article and it seems like a fair summary. I mean they even added the onus to bring more games to Linux first and then we will get moving on our part. I’m a Linux user, really a small private company making a business decision doesn’t bother me and people getting pissy about the first message was silly imho. But the only thing that changed here was the pr.

It's exactly what it shows.

A zealous Tuxist, slighted by the insolence toward their beliefs but bitterly satisfied by the backpeddling was quoted as saying,

>Basically yea, but it's nice to know they'll keep their opinions to themselves from now on.

I use Arch (Manjaro cough) btw. I practically use Linux exclusively. But stuff like this is kind of funny. We live in a strange (dark?) time with respect to the OS ecosystem. This is an artifact of it.

The main OS is a bloated, closed, insecure, arguably hostile one, while the open, free one enjoys a kind of ethereal salience (both pragmatic and ideological) in the hearts, minds, and practice of technologists. That gives the open one a political protection completely disproportionate with its tiny consumer base and economic relevance to consumer-facing capitalists (who drive the entire technology sector).

I don't think the real problem is about Windows tools not working on Linux, but about Linux tools not working on Unix. Stuff like Systemd and Wayland don't even care about anything besides Linux.

That affects Second Life, too.

The best solution is to drop Vivox, which is kind of dated and crashes and restarts frequently.

Considering the huge push from Valve to improve gaming on linux, which includes improving Wine etc... The fact that Google's new platform is entirely Linux backed, and AFAIK Sony's next gen is probably Linux as well. It is inevitable that Linux will become a huge platform for gaming.

Unlikely, Valve has been trying to push SteamOS/Linux for years. So far without much success.

The recent uptick in Linux and Wine support may counter that... it feels like there's been more effort in the last 8-12 months than in the 2 years prior to that.

Just the uptick on Gaming on Linux youtube content from previously windows-centric sources would indicate demand is climbing.

Sony used BSD for PS4, it would be interesting to see if they moved to Linux for PS5 and what would lead to that decision.

Sorry, *nix... didn't necessarily mean to imply that it's only Linux and conflated Unix and Unix-like platforms since a lot of the libraries and tooling will overlap.

I don't understand how you can develop some voice chat middleware that doesn't work on almost anything that has a C compiler.

Dropping Linux support is a perfectly sensible thing to suggest. When it comes to computer gaming, all of the tooling, ecosystem, and cash is on Windows.

Even in light of the work of Steam/Valve on Proton and general Linux support. The fact that Google's gaming platform is entirely linux, and a lot of other toolchains for gaming platforms are linux based?

That's a pretty short sighted point of view.

Not really, especially when there are dozens of alternatives to vivox. But it is definitely the only thing they could suggest without saying "yeah, you should use Mumble, is objectively better".

This should surprise no one. Linux gamers are a very vocal minority, but also a very tiny portion of the market.

I gave up on the linux gaming years ago, after suffering with WINE.

Why would companies pour hundreds of thousands in resources to support a platform that has almost no serious gamers?

Why do people care about Linux gaming? Is it that hard to just boot into Windows? Or even, a VM with a pass-through graphics card? It's hard enough to make games as it is. It seems unfair to complain about something when it's clearly not in the developer's interest to waste a bunch of time on something nobody will use.

I can tell you why I personally care about it. I recently upgraded my gaming PC and I wanted to reinstall Windows on my new SDD. Only I forgot where I put my Windows 7 product key all those years ago and could not for the life of me pull it off of the existing Windows 10 install I had. I spent hours tracking down my key and did eventually find it, which luckily saved me from buying another expensive Windows license. All for what? I don't want Windows, I just want to play the games I've already paid for. If my games and hardware worked reliably on Linux I wouldn't even have to think about it, just download a fresh .iso and I'm off.

Video games being locked into Windows is a huge drag.

The thing is, it was clearly in the interest of the developer. Vivox tried to use the "drop it, it's so insignificant" card, but, even compared to the number of Linux gamers, the insignificant market would actually be the "vivox users" market.

Because some of us want to game on Linux. I can both dual-boot or fire up a VM but typically won't for games because it's a hassle, especially when I can get most of the games I want to run without resorting to that. Granted, it's a small market that many game devs aren't interested in. That's fine, we'll support the ones who are. But it's far from a platform that 'nobody will use' for games.

Reply on news.ycombinator.com