Happy Linux user here too.
I use Ubuntu or one of its derivatives in the last years. I barely had any problems, and they have been fixed, certainly less than Windows or Mac.
It is faster, more stable, and I prefer the workflow. MIDI and audio devices are also incredible easy for most stuff.
Although I use native devices and Linux native plugins only. You may have to look out if there is compatibility problems with proprietary hardware solutions or other software.
Are you happy being on LINUX for music production?
-
- KVRAF
- 1596 posts since 19 Aug, 2009
-
- KVRist
- 459 posts since 21 Jul, 2001
Pointless discussions. Confusing basic stuff like group policy editors and disk managers on his home OS. Lacking basic knowledge of what is critised makes proper discussion impossible.
Installers were there before Windows 95 got mainstream.
As Linux gained popularity, it became clear that there needed to be a more user-friendly way to manage software installations. This led to the development of package managers, tools designed to automate the process of installing, upgrading, and removing software.
.deb: Introduced by the Debian Project in 1993, .deb packages became the standard format for Debian and its derivatives, such as Ubuntu.
.rpm: Developed by Red Hat in 1995, .rpm was used by Red Hat Linux, Fedora, and CentOS, among others.
People that still think you are forced to do lots of stuff in bash or other terminals should update their knowledge.
Let me correct that for you:While we're correcting things, Linux software is usually distributed as packages, AppImages, Flatpaks or Snaps. The term "installer" is more commonly associated with Windows.
Installers were there before Windows 95 got mainstream.
As Linux gained popularity, it became clear that there needed to be a more user-friendly way to manage software installations. This led to the development of package managers, tools designed to automate the process of installing, upgrading, and removing software.
.deb: Introduced by the Debian Project in 1993, .deb packages became the standard format for Debian and its derivatives, such as Ubuntu.
.rpm: Developed by Red Hat in 1995, .rpm was used by Red Hat Linux, Fedora, and CentOS, among others.
People that still think you are forced to do lots of stuff in bash or other terminals should update their knowledge.
-
- KVRian
- 548 posts since 24 Feb, 2008 from Germany
Good that we have somebody like you who never makes mistakes or wrong claims.
A few corrections to your claims and strawmen:
• Package managers were NOT created for "user-friendliness." They were built to solve dependency hell, automate source compilation, and maintain system integrity. Early Linux required manual ./configure && make && make install builds, which were fragile, non-portable, and impossible to scale. .deb (1993) and .rpm (1995) were engineering responses to that problem, not UX trends.
• Windows installers (exe/msi) do not manage dependencies or track system state. They are isolated payloads that often leave orphaned files behind. That’s precisely why Linux needed a formal packaging system that tracks files, resolves dependencies, and handles rollbacks cleanly.
• GUI software centers didn’t replace package managers. Tools like Ubuntu Software, Discover, or GNOME Software are just front-ends that call the same CLI tools (apt, dnf, pacman, etc.) under the hood. The packaging layer remains CLI-first by design.
• The terminal is still fundamental. Just try to install a Docker without. chmod is another textbook example of why the terminal isn’t obsolete. Or as a developer, Git. While modern desktops offer graphical alternatives, CLI is required for servers, automation, debugging, fine-grained control, and reproducible deployments. GUI and CLI serve different purposes; one does not make the other obsolete.
Package managers were born out of systems engineering necessity, not desktop convenience. If you're interested in the actual history, look into the origins of dependency resolution, the Linux Filesystem Hierarchy Standard, and why CLI remains the backbone of Linux operations.
You're welcome. Let me know if you need further assistance.
A few corrections to your claims and strawmen:
• Package managers were NOT created for "user-friendliness." They were built to solve dependency hell, automate source compilation, and maintain system integrity. Early Linux required manual ./configure && make && make install builds, which were fragile, non-portable, and impossible to scale. .deb (1993) and .rpm (1995) were engineering responses to that problem, not UX trends.
• Windows installers (exe/msi) do not manage dependencies or track system state. They are isolated payloads that often leave orphaned files behind. That’s precisely why Linux needed a formal packaging system that tracks files, resolves dependencies, and handles rollbacks cleanly.
• GUI software centers didn’t replace package managers. Tools like Ubuntu Software, Discover, or GNOME Software are just front-ends that call the same CLI tools (apt, dnf, pacman, etc.) under the hood. The packaging layer remains CLI-first by design.
• The terminal is still fundamental. Just try to install a Docker without. chmod is another textbook example of why the terminal isn’t obsolete. Or as a developer, Git. While modern desktops offer graphical alternatives, CLI is required for servers, automation, debugging, fine-grained control, and reproducible deployments. GUI and CLI serve different purposes; one does not make the other obsolete.
Package managers were born out of systems engineering necessity, not desktop convenience. If you're interested in the actual history, look into the origins of dependency resolution, the Linux Filesystem Hierarchy Standard, and why CLI remains the backbone of Linux operations.
You're welcome. Let me know if you need further assistance.
“The biggest crime of a musician is to play notes instead of making music.”
Isaac Stern
Isaac Stern
-
- KVRist
- 459 posts since 21 Jul, 2001
And stubborn.
Did you know there is a job in Windows IT called packager? Those are the guys that fix the application installers for a living, so you can deploy it at scale on Windows desktops. You are using lots of words to suggest there is a difference. But any stuff that needs to be done to get the right binaries on an OS is basically the same and called the same.
Btw, try to do Windows server at scale nowadays without powershell.
Did you know there is a job in Windows IT called packager? Those are the guys that fix the application installers for a living, so you can deploy it at scale on Windows desktops. You are using lots of words to suggest there is a difference. But any stuff that needs to be done to get the right binaries on an OS is basically the same and called the same.
Btw, try to do Windows server at scale nowadays without powershell.
-
- KVRist
- 480 posts since 18 May, 2020
Tiles, you don't need command line or chmod to change permissions. I do it right in dolphin (file browser) with a right click.
REAPER + Davinci Resolve Pro on Manjaro KDE. Neve 88m. Focusrite 18i20 2nd gen. Neumann NDH30 headphones. Mics: Telefunken TF39, AT4050, Miktek C7e, EV RE-15. VSTs: u-he Hive 2, F'em, Renoise Redux, Apisonic Speedrum 2.
-
- KVRist
- 30 posts since 15 Mar, 2018
I'm very happy with Linux as a music production platform, but then again I am not a professional music producer and I'm very much a believer in Linux and FOSS from an ideological standpoint. I've been using Linux as my main OS since about 2018 and as a side OS since around 2008, so at this point I have a bit of experience in it.
I don't have time right now to read all of the other pages of stuff that people have written here, so I may end up repeat some of the things other people have said, but here are my 2 cents:
Hardware & Drivers
The bad news here is that official corporate support for hardware drivers on Linux is still pretty rare, so it's not a surprise to me when things don't officially work. However, the good news is that a lot of class-compliant devices that rely on existing standards like USB and MIDI will work anyway thanks to solid class-compliant drivers built right into the Linux kernel itself.
The bottom line here is that hardware and drivers are a mixed bag. Some stuff will just work, some stuff will work with caveats and work-arounds, and other stuff will simply not work at all.
Every audio interface and MIDI controller I've ever owned has mostly worked (but sometimes without access to the official configuration software that you might have on other platforms). For an example of one of the drawbacks that I've faced here, I have a Focusrite Scarlett 6i6 2nd Gen audio interface that requires software to control things like switching between instrument/line mode on the preamp inputs, and I have to use a community-made unofficial software to control this because the official software doesn't (to my knowledge) work.
Operating System
Linux itself is a beast. It's fast, it's stable, it comes with a ton of drivers built-in, and its fully capable of working on music with small buffer sizes and low latency. The Linux kernel won't let you down.
On top of the kernel are the audio systems like Pipewire and JACK. Pipewire is newer, very flexible, pretty damn solid and comes pre-installed with many modern distros. I've heard people claim that JACK can theoretically achieve even better latency, but I've never found it to be necessary to try to go down that route because I'm more than happy with Pipewire's realtime performance. No problems here.
DAWs and Applications
As a Bitwig user, I get first-class Linux support. It's part of the reason that I'm a Bitwig user in the first place! Bitwig works perfectly and identically to what you'll get on other platforms.
Outside of Bitwig, there are other DAWs that have some degree of Linux support. I believe Reaper has good official support. There's the open source DAW Ardour. There's the tracker-style DAW Renoise (as well as some great chiptune trackers like Furnace). There's a good DJ software called Mixxx. And some other stuff too!
In short, if you're a Bitwig user you'll have no problem on Linux, and if you want to try out some other stuff there are a few decent options.
It's worth noting that, using WINE, it is possible to delve into other DAWs too, but that's a more advanced and complicated topic.
Plugins
Plugins are where Linux is still lacking and where things start to get pretty messy, pretty fast.
Linux-native VST and CLAP plug-ins exist. U-he makes good stuff. Pianoteq is great. There are a lot of great open source plugins too, like Airwindows, Vital, Dexed, BOYD, etc. All this stuff just works as you'd expect in your plug-in host of choice, so there's no drama here.
But I think it's safe to say that most of us, whether hobbyists or pros, probably have a large collection of plug-ins for Windows that we rely on (perhaps too much, in some cases), and that's where things get a little bit tricky. (A lot of this requires some degree of command line terminal typing in order to get working, so it's a bit more advanced and scary for new/casual users.)
Windows plug-ins can often be made to work to some degree on Linux via tools like WINE and Yabridge. If you're familiar with Valve's Proton layer that allows Windows games to be played on Linux, then you'll understand the basic concept of WINE, as Proton uses WINE under the hood. WINE allows you to run Windows software on Linux by reimplementing many of the software libraries that Windows programs need to function. You can use WINE to run the installer, just like you'd do on Windows, and then you can use WINE to run the program itself, just like on Windows.
Yabridge is a great tool that creates Linux .so libraries for each Windows .dll library, and makes Windows plug-ins running through WINE appear as if they are native Linux plug-ins in your DAW. It's a key part of making your setup feel "native", and I highly recommend it.
Does it work? Well... your mileage may vary.
Sometimes things work damn near perfectly. Other times there are showstopping bugs and things are just broken beyond usability. All of this could be avoided if companies would simply provide better support for Linux themselves (or at least support WINE! Shout outs to AudioModelling who helped getting SWAM working via WINE/Yabridge!), but it is what it is. There are too many different plug-ins to tell you how well this will work for your plug-in library, so I recommend going in with tempered expectations and just trying it.
Most of my Windows plug-ins mostly work, but I do run into problems from time to time and version to version that might be too annoying and stress-inducing for a professional producer with deadlines to deal with long term.
Overall
Overall, I feel that music production on Linux has never been better.
As much as there are still gaps in official support, and remaining issues with community-driven workarounds, music production on Linux is better in every way today than it was just a few years ago. Hardware is more supported, Pipewire and JACK are better than anything on Windows in my opinion, native DAW options are solid, and tools like WINE and Yabridge have improved to the point where Windows plug-ins are viable more often than not.
It still feels a little bit cobbled together and rough around the edges... but then again so were many of the great music studios.
I definitely think now is a good time for people to at least dip their toes in the water and give Linux a try.
I don't have time right now to read all of the other pages of stuff that people have written here, so I may end up repeat some of the things other people have said, but here are my 2 cents:
Hardware & Drivers
The bad news here is that official corporate support for hardware drivers on Linux is still pretty rare, so it's not a surprise to me when things don't officially work. However, the good news is that a lot of class-compliant devices that rely on existing standards like USB and MIDI will work anyway thanks to solid class-compliant drivers built right into the Linux kernel itself.
The bottom line here is that hardware and drivers are a mixed bag. Some stuff will just work, some stuff will work with caveats and work-arounds, and other stuff will simply not work at all.
Every audio interface and MIDI controller I've ever owned has mostly worked (but sometimes without access to the official configuration software that you might have on other platforms). For an example of one of the drawbacks that I've faced here, I have a Focusrite Scarlett 6i6 2nd Gen audio interface that requires software to control things like switching between instrument/line mode on the preamp inputs, and I have to use a community-made unofficial software to control this because the official software doesn't (to my knowledge) work.
Operating System
Linux itself is a beast. It's fast, it's stable, it comes with a ton of drivers built-in, and its fully capable of working on music with small buffer sizes and low latency. The Linux kernel won't let you down.
On top of the kernel are the audio systems like Pipewire and JACK. Pipewire is newer, very flexible, pretty damn solid and comes pre-installed with many modern distros. I've heard people claim that JACK can theoretically achieve even better latency, but I've never found it to be necessary to try to go down that route because I'm more than happy with Pipewire's realtime performance. No problems here.
DAWs and Applications
As a Bitwig user, I get first-class Linux support. It's part of the reason that I'm a Bitwig user in the first place! Bitwig works perfectly and identically to what you'll get on other platforms.
Outside of Bitwig, there are other DAWs that have some degree of Linux support. I believe Reaper has good official support. There's the open source DAW Ardour. There's the tracker-style DAW Renoise (as well as some great chiptune trackers like Furnace). There's a good DJ software called Mixxx. And some other stuff too!
In short, if you're a Bitwig user you'll have no problem on Linux, and if you want to try out some other stuff there are a few decent options.
It's worth noting that, using WINE, it is possible to delve into other DAWs too, but that's a more advanced and complicated topic.
Plugins
Plugins are where Linux is still lacking and where things start to get pretty messy, pretty fast.
Linux-native VST and CLAP plug-ins exist. U-he makes good stuff. Pianoteq is great. There are a lot of great open source plugins too, like Airwindows, Vital, Dexed, BOYD, etc. All this stuff just works as you'd expect in your plug-in host of choice, so there's no drama here.
But I think it's safe to say that most of us, whether hobbyists or pros, probably have a large collection of plug-ins for Windows that we rely on (perhaps too much, in some cases), and that's where things get a little bit tricky. (A lot of this requires some degree of command line terminal typing in order to get working, so it's a bit more advanced and scary for new/casual users.)
Windows plug-ins can often be made to work to some degree on Linux via tools like WINE and Yabridge. If you're familiar with Valve's Proton layer that allows Windows games to be played on Linux, then you'll understand the basic concept of WINE, as Proton uses WINE under the hood. WINE allows you to run Windows software on Linux by reimplementing many of the software libraries that Windows programs need to function. You can use WINE to run the installer, just like you'd do on Windows, and then you can use WINE to run the program itself, just like on Windows.
Yabridge is a great tool that creates Linux .so libraries for each Windows .dll library, and makes Windows plug-ins running through WINE appear as if they are native Linux plug-ins in your DAW. It's a key part of making your setup feel "native", and I highly recommend it.
Does it work? Well... your mileage may vary.
Sometimes things work damn near perfectly. Other times there are showstopping bugs and things are just broken beyond usability. All of this could be avoided if companies would simply provide better support for Linux themselves (or at least support WINE! Shout outs to AudioModelling who helped getting SWAM working via WINE/Yabridge!), but it is what it is. There are too many different plug-ins to tell you how well this will work for your plug-in library, so I recommend going in with tempered expectations and just trying it.
Most of my Windows plug-ins mostly work, but I do run into problems from time to time and version to version that might be too annoying and stress-inducing for a professional producer with deadlines to deal with long term.
Overall
Overall, I feel that music production on Linux has never been better.
As much as there are still gaps in official support, and remaining issues with community-driven workarounds, music production on Linux is better in every way today than it was just a few years ago. Hardware is more supported, Pipewire and JACK are better than anything on Windows in my opinion, native DAW options are solid, and tools like WINE and Yabridge have improved to the point where Windows plug-ins are viable more often than not.
It still feels a little bit cobbled together and rough around the edges... but then again so were many of the great music studios.
I definitely think now is a good time for people to at least dip their toes in the water and give Linux a try.
-
- KVRian
- 548 posts since 24 Feb, 2008 from Germany
That is yet another strawman. We are talking about the Linux desktop, not Windows Server or enterprise infrastructure.drsyncenstein wrote: Sat Jun 20, 2026 7:31 pm And stubborn.
Did you know there is a job in Windows IT called packager? Those are the guys that fix the application installers for a living, so you can deploy it at scale on Windows desktops. You are using lots of words to suggest there is a difference. But any stuff that needs to be done to get the right binaries on an OS is basically the same and called the same.
Btw, try to do Windows server at scale nowadays without powershell.
What is it that you fanatics can never discuss in a civil manner? As a Linux user, I’m cringing yet again. Stop the insults, flaming, and strawman arguments. Else i might need to speak your language because that’s how you’re approaching this. I don’t want to do this. But if you drag me back into the discussion, I’ll answer. It’s really that simple.
As for installing software at Linux ...
Pick your favourite:
1. Cross-distribution app delivery formats
Flatpak
Snap
AppImage
Nix packages (Nix / NixOS style, works cross-distro)
Guix packages (GNU Guix functional package manager)
2. Native binary package formats (distribution-bound)
.deb (Debian, Ubuntu, etc.)
.rpm (Fedora, RHEL, openSUSE, etc.)
.pkg.tar.zst / pacman packages (Arch Linux)
.apk (Alpine Linux)
.txz (Slackware)
.tbz / .tbz2 (Gentoo binary packages, less common)
.ebuild (Gentoo source recipes, not binary but distribution mechanism)
.pisi (Pardus Linux)
.ipk (OpenWrt / embedded Linux systems)
.opkg packages (embedded systems, OpenWrt descendants)
3. Source-based distribution systems
tar.gz / tar.xz source archives
configure / make / make install workflows
CMake-based builds (distribution-neutral build system)
Meson/Ninja builds
Autotools (autoconf/automake ecosystem)
language-specific builds (cargo, pip, npm, go install, etc.)
4. User repository / build recipe systems
AUR (Arch User Repository)
Copr (Fedora community builds)
OBS (Open Build Service used by openSUSE and others)
Gentoo overlays (Portage overlays)
PPAs (Ubuntu Personal Package Archives)
5. Scripted / vendor installers
.sh installers (generic shell installers)
.run installers (self-extracting Linux installers, e.g. NVIDIA drivers)
binary installer bundles (closed-source vendor installers, often wrapped in shell or GUI installer)
install scripts bundled with tarballs
6. Language / ecosystem package managers (often used as app delivery)
pip / wheel (Python)
npm / yarn / pnpm (Node.js)
cargo (Rust)
gem (Ruby)
composer (PHP)
go modules / binaries
dotnet tools (.NET global tools)
conda / mamba (scientific ecosystem, cross-platform)
7. Container / runtime-based distribution
Docker images
OCI images (Open Container Initiative standard)
Podman images
Singularity / Apptainer (HPC environments)
8. Legacy / niche packaging systems
Slackware pkgtools (older variants)
RPM source packages (.src.rpm)
Debian source packages (.dsc)
LSB installer formats (historical Linux Standard Base attempts)
And i am sure i even missed a few
And now make an educational guess what we developers talk about when we talk about the maintenance overhead for Linux.
Windows uses standardized MSI/EXE installers that work consistently across the OS. That’s what “installers” means in a unified sense. That's what was meant before you picked it out of context.
Linux doesn’t have a single installer by any means. It has a fragmented ecosystem of package managers (dpkg, rpm, pacman, flatpak, etc.) with different formats, dependency systems, and update cycles. That fragmentation is real, and it’s exactly why “installers” on Linux don’t function like they do on Windows. And why i personally don't consider this mess as installers at all.
What a wonderful empty phrase.Overall, I feel that music production on Linux has never been better.
Overall, I feel that playing Doom on my frigerator has never been better ...
Jokes aside. I’m not here to dismiss your setup. If it works for you, great. But if we’re just talking about personal preference, there’s nothing to debate.
That said, I seriously doubt Linux audio production is objectively "better" than Windows or macOS, despite what keeps getting repeated here. In practice, it’s not a viable alternative. It’s a step back and a downgrade. I’m not guessing here. The gap is real: fragmented hardware and software support, workflow friction, and the fact that I can’t even launch my main DAW natively. Add that about 99% of my go-to VSTs just don’t run on Linux, and the picture becomes clear.
I’ve been running Linux for years, both in theory and daily practice. I don’t need to be convinced about anything. I know from experience. I deal with these limits every day. My take isn’t about dogma. It’s about what actually works when you need to get real work done. The difference between dreaming and real life.
That works well in theory, but in practice I frequently hit permission changes that GUI file managers simply can't handle. When that happens, I still end up using chmod or chown in the terminal. And I'd rather not play guessing games to see if a GUI will work this time.Tiles, you don't need command line or chmod to change permissions. I do it right in dolphin (file browser) with a right click.
But that was just an example anyways. My real point is that Linux inevitably leads you to the command line. Almost every tutorial, forum post, or troubleshooting guide eventually requires terminal commands, starting with sudo.
No one’s arguing that GUIs can’t handle specific tasks. The point is that long-term Linux usage inevitably involves the command line. It’s not about whether a GUI exists for a given task, but whether you can avoid the terminal altogether. From my experience, you can’t. There’s always a point where the CLI becomes necessary. And that’s by design. This is actually very similar to macOS. Even there, you frequently end up in the terminal once you go beyond basic usage. But here you have a working eco system.
“The biggest crime of a musician is to play notes instead of making music.”
Isaac Stern
Isaac Stern
-
- KVRAF
- 6540 posts since 9 Dec, 2008 from Berlin
You do not have the required permissions to view the files attached to this post.
"Out beyond the ideas of wrongdoing and rightdoing, there is a field. I’ll meet you there." · Rumi
UrbanFlow.art · Instagram · YouTube
UrbanFlow.art · Instagram · YouTube
-
- KVRian
- 548 posts since 24 Feb, 2008 from Germany
Ah no it's more ...
You do not have the required permissions to view the files attached to this post.
“The biggest crime of a musician is to play notes instead of making music.”
Isaac Stern
Isaac Stern
-
- KVRist
- 459 posts since 21 Jul, 2001
You sir have officiallly been accepted into the legion of clowns!Tiles wrote: Sun Jun 21, 2026 6:15 am
Stop the insults, flaming, and strawman arguments. Else i might need to speak your language because that’s how you’re approaching this. I don’t want to do this. But if you drag me back into the discussion, I’ll answer. It’s really that simple.
Congratulations.
If you think this is an error, do a bit of selfsearch instead of whining.
-
- KVRian
- 548 posts since 24 Feb, 2008 from Germany
Thanks for demonstrating my point so efficiently.
“The biggest crime of a musician is to play notes instead of making music.”
Isaac Stern
Isaac Stern
-
- KVRAF
- 7091 posts since 19 Apr, 2002 from Utah
That is exactly a particular person’s goal. I just can’t understand why Ben does nothing.BobDog wrote: Sun Jun 21, 2026 12:08 pm I'm guessing anyone wondering if they should use Linux or not and reading this thread would steer well clear!
Vendor‑Dependent Copy Protection: Customers lose. Pirates win.
(Also: I'm Accused of lying about Linux—it boots, runs my pro audio workflow, stays stable, updates--though yearly dismissed as “niche”. Yet I'm the deluded one.)
(Also: I'm Accused of lying about Linux—it boots, runs my pro audio workflow, stays stable, updates--though yearly dismissed as “niche”. Yet I'm the deluded one.)
-
- KVRian
- 548 posts since 24 Feb, 2008 from Germany
Ah dog-whistling.
Summary of the pattern for anyone observing:
Coded Provocation: Using 'plausible deniability' to insult without triggering bans.
Boundary Inversion: Claiming disengagement while actively seeking reaction.
Narrative Control: Shifting from arguments to personal character attacks.
This is not a debate; it's a systematic attempt to derail discussion through manipulation.
@Ben, in case you are reading this, this is the pattern in a nutshell.
Summary of the pattern for anyone observing:
Coded Provocation: Using 'plausible deniability' to insult without triggering bans.
Boundary Inversion: Claiming disengagement while actively seeking reaction.
Narrative Control: Shifting from arguments to personal character attacks.
This is not a debate; it's a systematic attempt to derail discussion through manipulation.
@Ben, in case you are reading this, this is the pattern in a nutshell.
“The biggest crime of a musician is to play notes instead of making music.”
Isaac Stern
Isaac Stern
-
- KVRist
- 317 posts since 25 May, 2021
What a childish behaviour of some here.....are we really talking about grown ups here? some people makes it here a frustrating place.