10-08-2019, 12:18 PM | #1 |
Human being with feelings
Join Date: Mar 2008
Location: Planet Earth
Posts: 9,098
|
Is Linux a viable platform for REAPER?
I think it is. I tried out the Harrison mastering EQ on this.
https://soundclick.com/share.cfm?id=13930912 |
10-08-2019, 02:32 PM | #2 |
Human being with feelings
Join Date: Mar 2017
Posts: 861
|
I remember using Reaper 2.06 in wine for ages, it was stable,
a pleasure to use, and had more capabilities than I had hopes of ever learning. All still true today, as I enjoy the enlightened stroll to V6. More to the linux viability, if someone only uses linux, no win/mac, I don't think having only one linux is particularly viable. Eggs all in one basket will make for a runny omelette at some point... Last edited by 4duhwinnn; 10-08-2019 at 02:38 PM. |
10-08-2019, 02:47 PM | #3 |
Human being with feelings
Join Date: Jul 2016
Location: Los Angeles, CA
Posts: 1,701
|
Not only is Linux a viable platform/OS for Reaper, I actually get better CPU performance than on Windows. The bigger issue is the lack of support by plugin developers. Once you start running windows plugins in Wine, it cancels out most of the gains.
If Reaper can ever manage a native windows VST bridge, I think people will be able to do some serious damage. |
10-08-2019, 04:11 PM | #4 | |
Human being with feelings
Join Date: Mar 2008
Location: Planet Earth
Posts: 9,098
|
Quote:
My machine is dual boot, and I can bring it up Windows 7 with no network to do stuff in REAPER, but for me using it in Windows is no better or worse than using it in Linux, and since I prefer Linux, I'm just doing everything there now, and Windows is only a fallback that I never use. |
|
10-08-2019, 04:23 PM | #5 | |
Human being with feelings
Join Date: Mar 2008
Location: Planet Earth
Posts: 9,098
|
Quote:
As for plugins, I've retired all my Windows audio plugins and am using 100% native Linux audio VST plugins now. Mostly paid, but some free ones too. VSTi instrument plugins is another story though, and in fact I am using a monstrous virtual guitar instrument I constructed using Kontakt with a clean electric guitar sample going into a Guitar Rig virtual Fender Twin. It's the guitar panned center through the Leslie. The real 12-String is panned hard left and mandolin panned hard right. Also the Vox Continental organ is Native Instruments B4 Organ with the Vox tonewheels set. I'm having no problems at all working exactly like I did in Windows. The virtual instruments I use don't tax the system much, even though they are bridged Windows plugins, and with all native Linux VSTs for audio, it feels as tight as I was used to in Windows. |
|
10-08-2019, 11:22 PM | #6 | |
Human being with feelings
Join Date: Jun 2013
Location: Krefeld, Germany
Posts: 14,789
|
Quote:
As Klangfarben says, Reaper/linux providing this in a "native" (i.e. automatic, user friendly, transparent) way, this would be a great step ahead (but supposedly a huge task for the devs). -Michael |
|
10-09-2019, 01:27 AM | #7 |
Human being with feelings
Join Date: Aug 2011
Location: Near a big lake
Posts: 3,943
|
The devs haven't said a single thing about this. It's only people such as myself saying "don't expect it to happen". You know why: then the devs would be perpetually responsible for making all Windows plugins work in Reaper for Linux, maintaining that compatibility through changes in plugin programming, changes in Reaper, and changes in operating systems (Linux distros mostly). That's an additional layer of potential complexity. Plus there are already third-party solutions for this which are free, which perform about as well as can be expected.
These are plugins from a different operating system. Does any DAW you know of bridge plugins from a different operating system? You'd be expecting Reaper to be the first to do this. Also you figure if someone is willing to use Linux, maybe they should also be willing to do some of the work making their system be capable of doing something like this. If the devs choose to do this, that's great. I just don't see it happening. As a programmer yourself, you should also understand this. |
10-09-2019, 01:57 AM | #8 |
Human being with feelings
Join Date: Jun 2013
Location: Krefeld, Germany
Posts: 14,789
|
Yep ! By "task" I also meant the effort of perpetually maintaining the product.
Of course I do understand this, and I do understand the consequence, that Reaper for Linux will not be a ubiquitous "success" (but I don't know if this is a viable goal for whomever...) -Michael |
10-09-2019, 02:06 AM | #9 | |
Human being with feelings
Join Date: Aug 2011
Location: Near a big lake
Posts: 3,943
|
Quote:
I doubt the devs care about "ubiquitous success" of Reaper for Linux, or of Reaper at all. They're picking their battles, and they've already gone well beyond what most expect for a Linux DAW. Reaper is easily the most powerful and flexible DAW for Linux. |
|
10-09-2019, 06:57 AM | #10 | ||
Human being with feelings
Join Date: Mar 2008
Location: Planet Earth
Posts: 9,098
|
Quote:
Quote:
|
||
10-09-2019, 07:12 AM | #11 | |
Human being with feelings
Join Date: Sep 2008
Location: Calgary, AB, Canada
Posts: 6,551
|
Quote:
Cockos implementing that is about as practical as Cockos implementing native support for OMF and AAF when tools like AATranslator and Vordio are already out there with dedicated people working on them.
__________________
I'm no longer using Reaper or working on scripts for it. Sorry. :( Default 5.0 Nitpicky Edition / GUI library for Lua scripts / Theory Helper / Radial Menu / Donate |
|
10-09-2019, 07:26 AM | #12 | |
Human being with feelings
Join Date: Mar 2008
Location: Planet Earth
Posts: 9,098
|
Quote:
|
|
10-09-2019, 08:32 AM | #13 | |
Human being with feelings
Join Date: Jul 2016
Location: Los Angeles, CA
Posts: 1,701
|
Quote:
|
|
10-09-2019, 08:33 AM | #14 |
Human being with feelings
Join Date: Sep 2008
Location: Calgary, AB, Canada
Posts: 6,551
|
You run the program, choose a .dll, and it spits out a .so. How is that not user-friendly?
__________________
I'm no longer using Reaper or working on scripts for it. Sorry. :( Default 5.0 Nitpicky Edition / GUI library for Lua scripts / Theory Helper / Radial Menu / Donate |
10-09-2019, 08:46 AM | #15 | |
Human being with feelings
Join Date: Mar 2008
Location: Planet Earth
Posts: 9,098
|
Quote:
Then you are still using LinVST, but you can launch the converter part of it from within REAPER so it appears to be embedded. Not really needed though IMHO. I ran the converter module way back when I first started using REAPER for Linux, and have not had to screw with it since. All the Windows plugins I own and want to use in Linux work and I don't even think about the fact that they are bridged. |
|
10-09-2019, 09:18 AM | #16 | |
Human being with feelings
Join Date: Jul 2016
Location: Los Angeles, CA
Posts: 1,701
|
Quote:
Apparently you've been lucky enough to only wrap plugins that work with no issues. |
|
10-09-2019, 09:24 AM | #17 | |
Human being with feelings
Join Date: Sep 2008
Location: Calgary, AB, Canada
Posts: 6,551
|
Quote:
There's enough variation in how VSTs are built that covering even 90% would require an impossible amount of work for Cockos' two developers on top of maintaining the rest of Reaper. I think the only way to do it would be for someone else to release a dedicated and VST-focused fork of Wine, but good luck with that. :/ Also: - In some cases like Waves, half of the trouble is because they don't implement the VST spec correctly so that they can do their own stuff like ILok and Waves' hub... plugin... thing... (I've never used their stuff). - Samplers like EZDrummer are designed with the Windows file system and user folders in mind, so of course it's going to require some amount of fiddling around with Wine and symlinks to make the samples accessible.
__________________
I'm no longer using Reaper or working on scripts for it. Sorry. :( Default 5.0 Nitpicky Edition / GUI library for Lua scripts / Theory Helper / Radial Menu / Donate Last edited by Lokasenna; 10-09-2019 at 09:39 AM. |
|
10-09-2019, 09:50 AM | #18 | |
Human being with feelings
Join Date: Jul 2016
Location: Los Angeles, CA
Posts: 1,701
|
Quote:
https://forum.cockos.com/showthread.php?t=193761 Yes, user-friendly doesn't automatically mean everything is going to work perfectly. But, the minute something doesn't, it gets ugly. Fast. And I don't disagree that Cockos trying to support Windows VSTs in Linux could turn into a giant can of worms. I'm not even saying they should. I'm just saying if they were able to pull it off and make the process more invisible - even to the point of just saying, hey, sorry these specific plugins won't work so deal with it or hey sorry we only support this version of Wine - it would bring more users into the fold. |
|
10-09-2019, 11:04 AM | #19 | ||
Human being with feelings
Join Date: Aug 2011
Location: Near a big lake
Posts: 3,943
|
Quote:
Quote:
I think anyone discussing this needs to remember: Linux isn't meant to run Windows software. The fact it can is impressive. Expecting a DAW to hold your hand in that regard...ok well think of it this way: would you expect Reaper for Mac to run Windows plugins with no problems. Or do you expect to run Windows plugins in a DAW on your Android device. No one is talking about this for any other DAW, period. If you want to use Linux, you should be expecting to be responsible for doing whatever "hacks" are required to force the OS to do what you want. And this is a "hack" and a half. Talking about "bringing more users into the fold" and "it would make it easier for new Linux users" yeah I get it, of course it would. But what about everything else lol. Linux still isn't Windows or OSX. Not even Ubuntu or Kubuntu for that matter are. Linux is still "the wild west of OSes" in some ways. You'll need more patience to use it no matter what. I think Reaper for Linux's continuing "beta" status is more a case of "they haven't gotten around to changing the status on the site so it's not beta anymore". |
||
10-09-2019, 11:38 AM | #20 | |||
Human being with feelings
Join Date: Mar 2008
Location: Planet Earth
Posts: 9,098
|
Quote:
Quote:
Quote:
Here's a thought. Can't you run REAPER FX remotely over a network? Just put all your Windows plugins on a dedicated Windows REAPER FX server and access them over the LAN from your REAPER for Linux box. Hardly get your hands dirty with the nuts and bolts of Linux if that would work. |
|||
10-09-2019, 12:18 PM | #21 | |
Human being with feelings
Join Date: Jun 2013
Location: Krefeld, Germany
Posts: 14,789
|
Quote:
Are there any serous issues with reaper/Linux (when using just native Linux plugins, and decently supported hardware) ? -Michael |
|
10-09-2019, 12:20 PM | #22 | |||
Human being with feelings
Join Date: Aug 2011
Location: Near a big lake
Posts: 3,943
|
A fair point. It's one I thought of when I realized there was a Reaper for Linux, that it wasn't just people using Reaper with Wine. Then I noticed there was an ARM build too. So clearly the development of Reaper isn't solely based on what makes the most money for the devs. I just wouldn't expect they'd want to go far off track effectively promising continual support for plugins to run in an OS they were never meant to, through changes to kernels and various not-totally-VST-compliant things that Windows VST devs do, and so on.
Quote:
Yeah having LV2 support would be nice but I can live without it too. JSFX covers so much ground it's crazy. Speaking of which, have you tried the latest version of ReEQ? Quote:
Quote:
On that note Glen, I've tried the following distros so far (I might be missing one in this list):
Last edited by JamesPeters; 10-09-2019 at 12:29 PM. |
|||
10-09-2019, 12:24 PM | #23 | |
Human being with feelings
Join Date: Jun 2013
Location: Krefeld, Germany
Posts: 14,789
|
Quote:
-Michael |
|
10-09-2019, 12:51 PM | #24 | |
Human being with feelings
Join Date: Mar 2008
Location: Planet Earth
Posts: 9,098
|
Quote:
That would put REAPER in the Linux supported column which may or may not have an effect on VST/VSTi developers to add Linux if they don't support it currently. Developers who use JUCE can supposedly make minor adjustments to get their wares to run on Linux, so if there were an official Linux DAW selling, it might prompt them to make those minor adjustments. |
|
10-09-2019, 01:10 PM | #25 |
Human being with feelings
Join Date: Aug 2011
Location: Near a big lake
Posts: 3,943
|
I noticed someone posted about using a distro which has the latest Gnome, and is having issues. I guess something that new having an issue with Reaper wouldn't surprise me.
I also wonder if plugin developers will take Reaper for Linux into account when considering making Linux VST versions of their plugins. I would hope so, anyway. |
10-09-2019, 01:21 PM | #26 | ||||
Human being with feelings
Join Date: Mar 2008
Location: Planet Earth
Posts: 9,098
|
Quote:
Quote:
Quote:
Quote:
|
||||
10-09-2019, 02:52 PM | #27 | ||||
Human being with feelings
Join Date: Aug 2011
Location: Near a big lake
Posts: 3,943
|
Quote:
Quote:
Quote:
Quote:
My takeaway about distros: Xfwm4 and compton combined is my favorite. It has lots of ways you can customize it but it doesn't seem to affect performance of the system to any significant degree (so I can push the CPU hard in Reaper and it's stable). Plus video plays smoothly, and there's no screen tear anywhere. So I went with Xubuntu since it's the most up-to-date distro I know of which has Xfwm4 by default (then customized it from there). Last edited by JamesPeters; 10-09-2019 at 09:17 PM. |
||||
10-09-2019, 08:06 PM | #28 | ||
Human being with feelings
Join Date: Mar 2008
Location: Planet Earth
Posts: 9,098
|
Quote:
Quote:
|
||
10-09-2019, 09:34 PM | #29 |
Human being with feelings
Join Date: Aug 2011
Location: Near a big lake
Posts: 3,943
|
Well just don't put Ubuntu on those, because if you do it's likely you won't be able to notice a difference from Windows 8's default look. Having 9 application icons in the menu take up an entire 1080p screen is insane, especially with no handy way of changing the menu to be more reasonable. I get that they're trying to make it a "modern OS" and also have the same OS be used on desktops as tablets, but come on.
Kubuntu was nice on the surface, since all the settings were in a very well thought out settings manager thing with a tree, search capability and so on. Unfortunately it lacked some customization options I'd grown accustomed to with Xfce distros, which surprised me. Plus its performance wasn't as good with those test Reaper projects I have, when I push the CPU to its limits. I think Kubuntu would be the most comfortable Linux distro for most current Windows/Mac users to transition to, even if it's not the leanest. Mint Cinnamon was a bit odd. It seems it's trying to be like Kubuntu but with even fewer customization options. I kept thinking I was missing something since "there's no way they'd bother making this WM but have it be lacking so many customization options", as I thought. I was wrong. A friend who's been using that for a while ranted about it once I explained how I was testing it. Mint Mate left me thinking "ok...what's better about this compared to Xfce?" I just don't see the point. It looks basically the same but just has less. And it's not more efficient than Xfce from what I can tell. Maybe there's something I'm not getting about it, but it was easy to move on from that quickly. So after using those, and previously having used distros with Xfce, I read a bit about the history of the different WMs/compositors to get an idea how they came about and why there were forks here and there. I'm left thinking Xfce is probably the best choice for someone who wants the system to run audio/video software and be capable of being stable while being pushed to its limits. Then choose whatever compositor makes sense (probably Compton, as I've discovered from using the various compositors of those Xfce distros with Nvidia and AMD cards). |
10-09-2019, 09:56 PM | #30 |
Human being with feelings
Join Date: Mar 2008
Location: Planet Earth
Posts: 9,098
|
It was Mythbuntu that made me aware of Xubuntu. Mythbuntu was a distro that had MythTV pre-configured for easy setup and capable of running well on older hardware. When the guys behind Mythbuntu decided to walk away from the project, they suggest Xubuntu and install MythTV yourself for similar performance.
When I switched my DAW over to Linux, I tried four or five other distros, but I just liked the way Xubuntu worked, and it felt like less CPU was being burned on flashy UI stuff that I didn't care about, so it could be used on DAW performance instead. I did try Ubuntu and it only lived on my machine for about thirty minutes before I became quite agitated and nuked it. |
10-10-2019, 12:18 AM | #31 | |
Human being with feelings
Join Date: Aug 2011
Location: Near a big lake
Posts: 3,943
|
Quote:
On the other hand, Kubuntu has a slick modern DE, it's well organized, and you can tell a lot of thought went into it. As for whether KDE Plasma "takes up more RAM" than other DEs, I don't care about that and it might only be an extra 150-200 MB anyway. It doesn't even seem like it's taking up more CPU either, but then when "the pedal hits the metal" in Reaper with the CPU pegged, it just didn't perform as well. There's a possibility I could've found a configuration which did work as well, but I'm at the limit of my understanding of tweaking distros and I didn't want to take guesses at it. I did the usual RT audio stuff that I do to any distro (which we've talked about on the forums), so that wasn't it. The video drivers seemed fine, nothing was acting weird. It just didn't have all the stability at low latency and really high CPU use. Then if I'm being pickier yet, it lacked some customization that I want. Just turning off system sounds (I hate hearing a noise when deleting a file etc.!) was something that was "hidden" for instance. A few things like that got on my nerves. I wouldn't even be surprised at the next release of Kubuntu, that it works every bit as good for audio/video production as Xubuntu; it could be something really minor that just isn't quite perfect. But anyway that's when I thought I'd settle back into Xfce, take the most up-to-date and common distro with it, then configure it the way I want. Any distro is going to take a handful of steps for me to configure, so although Xubuntu isn't quite as "ready to go" with apps/settings as Mint Xfce, it didn't matter much. Mint isn't as up-to-date as Xubuntu, so that made the difference for me. |
|
10-10-2019, 07:30 AM | #32 |
Human being with feelings
Join Date: Mar 2008
Location: Planet Earth
Posts: 9,098
|
I ran a dedicated MythTV server for a year and a half using Mythbuntu but then in 2016 they discontinued Mythbuntu and suggested that everyone install Xubuntu so they would continue to get updates and security patches. That was my real first encounter setting up Linux from scratch as Mythbuntu did a lot of the configuration for you. I set it up and never messed with it again since it worked flawlessly in aiding my cutting of the expensive cable cord.
Then last year I decided to switch all my Windows 7 machines to Linux before January of 2020 when Win7 hits the wall, so I set my DAW up first, and that was when I tried a bunch of different distros. Before REAPER was available as a native Linux app, I had settled into Xubuntu on the DAW and was using it as my daily driver, but then only a month or two later, REAPER for Linux popped. I set it up dual boot thinking I would use Win7 offline for REAPER, but it turned out that I don't need no steenking Windows after all. Since then I've one by one switched the other Windows 7 machines over, and the one that proved to me that Xubuntu was a good choice was while my wife was at work, I switched her computer over with no dual boot option. I expected a lot of flack, but never heard one complaint. Last edited by Glennbo; 10-16-2019 at 08:40 AM. |
10-10-2019, 10:03 AM | #33 |
Human being with feelings
Join Date: Aug 2011
Location: Near a big lake
Posts: 3,943
|
I had considered an icon like that. I just didn't want any Windows references on my computer though. Not even to be spiteful, just that "I'd moved on".
It's so weird how my "Windows journey" was over the years. Windows 95 had some fairly serious bugs, Windows 98 was ok (basically a more stable Windows 95), XP was a bit better than 98 and then Windows 7 "finally got it right" overall. By the time I settled into using Windows 7 (since I didn't adopt it early), Windows 8 was about to be released. That turned a corner for me. Windows 10 further added things I didn't like to the point it seemed a bit hostile to me. Forced updates, dialogs which when you click the "X" might just take that as "ok" if MS really wants you to do something, using your computer to seed updates, Cortana, then how MS was trying to force Windows 7 users to accept Windows 10 on their machines (multiple times)...no thanks, that's enough Windows for me. I knew I could work around those things in Windows 10 since I'd worked around things in previous Windows versions (including registry hacks and so on), but I figured by this point Linux was probably viable for my needs and if I were going to switch to a new OS that I'd have to manage in some way, I'd rather manage the OS more in terms of customization and less "mitigation of things the OS is trying to force me to do". Of course I'd also tried OSX in the meantime on a used Macbook I got. It was fine. If OSX were available to run on a non-Mac computer (without having to build a "hackintosh"), I may have switched to it. I wasn't about to buy a Mac for the sake of using it though. |
10-10-2019, 11:25 AM | #34 |
Human being with feelings
Join Date: Mar 2008
Location: Planet Earth
Posts: 9,098
|
I've never had an opportunity to play much with OSX, but before Windows 3.1 came out I was using Amigas which ran a true preemptive multi-tasking OS based on Unix.
My first encounter with Windows 3.1 was at a friend's house and I asked him if it was multi-tasking. He said it was so I said, format two floppies at the same time to satisfy my curiosity. He did and they did NOT format at the same time like I was used to seeing on my Amiga. On his Windows 3.1 machine it would hit drive A: then switch to drive B: and so on, but never both at once. It was task switching at best. I used to go to Amiga enthusiasts groups where they would daisy chain 15 floppy drives up and format disks and copy files en mass for everybody. It was Windows 95 that finally was true multi-tasking, but Windows was still not in the same league as Amigas. At that point in time I had a hardware card for the Amiga that had an SX386 Intel and some RAM where I was running Windows 95 as a task on the Amiga and at full pop speed as if it were on a dedicated machine instead of in a window on my Amiga. By Windows 7 Microsoft had finally eclipsed the Amiga, but Commodore had been out of business for a good while by then. Now that I am running Linux, it feels like a continuation of the experience I had when I was on my Amiga and my friends were all running Windows 3.1. |
10-10-2019, 12:15 PM | #35 | |
Human being with feelings
Join Date: Aug 2011
Location: Near a big lake
Posts: 3,943
|
Quote:
I just read about the Amiga series. Since I couldn't afford a PC at the time, I was out of the loop. It must've been weird seeing Windows PCs take over, if you were using an Amiga. Lol well I did notice a roughly 30%+ improvement in CPU use when switching from Windows 7 to Linux, so in that regard I can relate. And that was a carefully managed Windows 7 with whatever changes necessary to facilitate the DAW. Of course if I'd have switched to Kubuntu as my first distro I wouldn't have noticed as big an improvement. I'm glad I tried MX Linux first with Xfce and also apparently a low latency kernel by default (from what I gathered later). I'd have been willing to accept worse performance in Linux than Windows, but it was the opposite by a large margin. |
|
10-10-2019, 01:14 PM | #36 | ||
Human being with feelings
Join Date: Mar 2008
Location: Planet Earth
Posts: 9,098
|
LMAO! I had to go look that one up. One fun thing me and another friend who also had an Amiga did was to re-write all the most common Amiga error messages with our own text so instead of it saying something like "Read Error On Disk" on a bad floppy it would instead say something like "Disk Fucked Try Again".
Quote:
Another Amiga dood I knew wrote a module that made it so we could do photo icons on our Amigas which no OS had at the time. We had to use greyscale to do it, but it was pretty cool back then. I can still fire up virtual instances of all my old Amiga HDs using the FS_UAE Amiga emulator in Linux. Quote:
Last edited by Glennbo; 12-10-2019 at 09:05 AM. |
||
10-10-2019, 01:59 PM | #37 | |
Human being with feelings
Join Date: Aug 2011
Location: Near a big lake
Posts: 3,943
|
Quote:
My performance gain from Windows to Linux may have been limited to that one computer for a reason of which I'm unaware. Still it's nice to know I'm not sacrificing performance or stability by using Linux. |
|
10-10-2019, 04:58 PM | #38 | |
Human being with feelings
Join Date: Mar 2008
Location: Planet Earth
Posts: 9,098
|
Quote:
Shortly after I decided to do it right, I should have a real PC that only ran MSDOS so I built my first one from parts I bought locally. Once I realized how easy it was to build a machine, I kept upgrading more than once a year, plus my boss had me building all the PCs for our offices, and now I've built 30 or 40 machines over the years. I kind of stopped once PCs were no longer getting to be dogs with the tasks I was throwing at them, and the only reason I'm going to build an AMD 3700X soon is because every one of my Intels has this shit . . . l1tf:Mitigation: PTE Inversion; VMX: conditional cache flushes, SMT disabled mds:Vulnerable: Clear CPU buffers attempted, no microcode; SMT disabled meltdown:Mitigation: PTI spec_store_bypass:Mitigation: Speculative Store Bypass disabled via prctl and seccomp spectre_v1:Mitigation: usercopy/swapgs barriers and __user pointer sanitization spectre_v2:Mitigation: Full generic retpoline, IBPB: conditional, IBRS_FW, STIBP: disabled, RSB filling VS the one AMD in the house which reads like this. l1tf:Not affected mds:Not affected meltdown:Not affected spec_store_bypass:Not affected spectre_v1:Mitigation: usercopy/swapgs barriers and __user pointer sanitization spectre_v2:Mitigation: Full AMD retpoline, STIBP: disabled, RSB filling Four "Not affected" items with an AMD vs four exclusively Intel only "Affected" entries. |
|
10-10-2019, 06:31 PM | #39 |
Human being with feelings
Join Date: Aug 2011
Location: Near a big lake
Posts: 3,943
|
I bought a new computer approximately once every 3 years since that one, and it was always something I built from parts. So I guess that's around 8 or 9 computers that I built for myself. They all blur together since I don't think about them much after I set them up, unless I'm doing a major change to them (such as now, since I'm using Linux, and also using AMD for the CPU again since I haven't done that since that first computer in 1996 which was a 5x86). Then of course there were the computer systems I built or maintained for work, friends, etc.
Yeah I ran spectre-meltdown-checker recently. Here's the output: Code:
Spectre and Meltdown mitigation detection tool v0.42 Checking for vulnerabilities on current system Kernel is Linux 5.0.0-31-lowlatency #33-Ubuntu SMP PREEMPT Mon Sep 30 19:30:45 UTC 2019 x86_64 CPU is AMD Ryzen 7 3700X 8-Core Processor Hardware check * Hardware support (CPU microcode) for mitigation techniques * Indirect Branch Restricted Speculation (IBRS) * SPEC_CTRL MSR is available: YES * CPU indicates IBRS capability: NO * CPU indicates preferring IBRS always-on: NO * CPU indicates preferring IBRS over retpoline: YES * Indirect Branch Prediction Barrier (IBPB) * PRED_CMD MSR is available: YES * CPU indicates IBPB capability: YES (IBPB_SUPPORT feature bit) * Single Thread Indirect Branch Predictors (STIBP) * SPEC_CTRL MSR is available: YES * CPU indicates STIBP capability: YES (AMD STIBP feature bit) * CPU indicates preferring STIBP always-on: YES * Speculative Store Bypass Disable (SSBD) * CPU indicates SSBD capability: YES (AMD SSBD in SPEC_CTRL) * L1 data cache invalidation * FLUSH_CMD MSR is available: NO * CPU indicates L1D flush capability: NO * CPU supports Software Guard Extensions (SGX): NO * CPU microcode is known to cause stability problems: NO (model 0x71 family 0x17 stepping 0x0 ucode 0x8701013 cpuid 0x870f10) * CPU microcode is the latest known available version: YES (latest version is 0x8701011 dated 2019/04/15 according to builtin MCExtractor DB v112 - 2019/05/22) * CPU vulnerability to the speculative execution attack variants * Vulnerable to CVE-2017-5753 (Spectre Variant 1, bounds check bypass): YES * Vulnerable to CVE-2017-5715 (Spectre Variant 2, branch target injection): YES * Vulnerable to CVE-2017-5754 (Variant 3, Meltdown, rogue data cache load): NO * Vulnerable to CVE-2018-3640 (Variant 3a, rogue system register read): NO * Vulnerable to CVE-2018-3639 (Variant 4, speculative store bypass): YES * Vulnerable to CVE-2018-3615 (Foreshadow (SGX), L1 terminal fault): NO * Vulnerable to CVE-2018-3620 (Foreshadow-NG (OS), L1 terminal fault): NO * Vulnerable to CVE-2018-3646 (Foreshadow-NG (VMM), L1 terminal fault): NO * Vulnerable to CVE-2018-12126 (Fallout, microarchitectural store buffer data sampling (MSBDS)): NO * Vulnerable to CVE-2018-12130 (ZombieLoad, microarchitectural fill buffer data sampling (MFBDS)): NO * Vulnerable to CVE-2018-12127 (RIDL, microarchitectural load port data sampling (MLPDS)): NO * Vulnerable to CVE-2019-11091 (RIDL, microarchitectural data sampling uncacheable memory (MDSUM)): NO CVE-2017-5753 aka 'Spectre Variant 1, bounds check bypass' * Mitigated according to the /sys interface: YES (Mitigation: usercopy/swapgs barriers and __user pointer sanitization) * Kernel has array_index_mask_nospec: YES (1 occurrence(s) found of x86 64 bits array_index_mask_nospec()) * Kernel has the Red Hat/Ubuntu patch: NO * Kernel has mask_nospec64 (arm64): NO > STATUS: NOT VULNERABLE (Mitigation: usercopy/swapgs barriers and __user pointer sanitization) CVE-2017-5715 aka 'Spectre Variant 2, branch target injection' * Mitigated according to the /sys interface: YES (Mitigation: Full AMD retpoline, IBPB: conditional, STIBP: always-on, RSB filling) * Mitigation 1 * Kernel is compiled with IBRS support: YES * IBRS enabled and active: NO * Kernel is compiled with IBPB support: YES * IBPB enabled and active: YES * Mitigation 2 * Kernel has branch predictor hardening (arm): NO * Kernel compiled with retpoline option: YES * Kernel compiled with a retpoline-aware compiler: YES (kernel reports full retpoline compilation) > STATUS: NOT VULNERABLE (Full retpoline + IBPB are mitigating the vulnerability) CVE-2017-5754 aka 'Variant 3, Meltdown, rogue data cache load' * Mitigated according to the /sys interface: YES (Not affected) * Kernel supports Page Table Isolation (PTI): YES * PTI enabled and active: NO * Reduced performance impact of PTI: NO (PCID/INVPCID not supported, performance impact of PTI will be significant) * Running as a Xen PV DomU: NO > STATUS: NOT VULNERABLE (your CPU vendor reported your CPU model as not vulnerable) CVE-2018-3640 aka 'Variant 3a, rogue system register read' * CPU microcode mitigates the vulnerability: YES > STATUS: NOT VULNERABLE (your CPU vendor reported your CPU model as not vulnerable) CVE-2018-3639 aka 'Variant 4, speculative store bypass' * Mitigated according to the /sys interface: YES (Mitigation: Speculative Store Bypass disabled via prctl and seccomp) * Kernel supports disabling speculative store bypass (SSB): YES (found in /proc/self/status) * SSB mitigation is enabled and active: YES (per-thread through prctl) * SSB mitigation currently active for selected processes: YES (firefox irqbalance ModemManager systemd-journald systemd-logind systemd-resolved systemd-timesyncd systemd-udevd upowerd) > STATUS: NOT VULNERABLE (Mitigation: Speculative Store Bypass disabled via prctl and seccomp) CVE-2018-3615 aka 'Foreshadow (SGX), L1 terminal fault' * CPU microcode mitigates the vulnerability: N/A > STATUS: NOT VULNERABLE (your CPU vendor reported your CPU model as not vulnerable) CVE-2018-3620 aka 'Foreshadow-NG (OS), L1 terminal fault' * Mitigated according to the /sys interface: YES (Not affected) * Kernel supports PTE inversion: YES (found in kernel image) * PTE inversion enabled and active: NO > STATUS: NOT VULNERABLE (your CPU vendor reported your CPU model as not vulnerable) CVE-2018-3646 aka 'Foreshadow-NG (VMM), L1 terminal fault' * Information from the /sys interface: Not affected * This system is a host running a hypervisor: NO * Mitigation 1 (KVM) * EPT is disabled: N/A (the kvm_intel module is not loaded) * Mitigation 2 * L1D flush is supported by kernel: YES (found flush_l1d in kernel image) * L1D flush enabled: NO * Hardware-backed L1D flush supported: NO (flush will be done in software, this is slower) * Hyper-Threading (SMT) is enabled: YES > STATUS: NOT VULNERABLE (your CPU vendor reported your CPU model as not vulnerable) CVE-2018-12126 aka 'Fallout, microarchitectural store buffer data sampling (MSBDS)' * Mitigated according to the /sys interface: YES (Not affected) * Kernel supports using MD_CLEAR mitigation: YES (found md_clear implementation evidence in kernel image) * Kernel mitigation is enabled and active: NO * SMT is either mitigated or disabled: NO > STATUS: NOT VULNERABLE (your CPU vendor reported your CPU model as not vulnerable) CVE-2018-12130 aka 'ZombieLoad, microarchitectural fill buffer data sampling (MFBDS)' * Mitigated according to the /sys interface: YES (Not affected) * Kernel supports using MD_CLEAR mitigation: YES (found md_clear implementation evidence in kernel image) * Kernel mitigation is enabled and active: NO * SMT is either mitigated or disabled: NO > STATUS: NOT VULNERABLE (your CPU vendor reported your CPU model as not vulnerable) CVE-2018-12127 aka 'RIDL, microarchitectural load port data sampling (MLPDS)' * Mitigated according to the /sys interface: YES (Not affected) * Kernel supports using MD_CLEAR mitigation: YES (found md_clear implementation evidence in kernel image) * Kernel mitigation is enabled and active: NO * SMT is either mitigated or disabled: NO > STATUS: NOT VULNERABLE (your CPU vendor reported your CPU model as not vulnerable) CVE-2019-11091 aka 'RIDL, microarchitectural data sampling uncacheable memory (MDSUM)' * Mitigated according to the /sys interface: YES (Not affected) * Kernel supports using MD_CLEAR mitigation: YES (found md_clear implementation evidence in kernel image) * Kernel mitigation is enabled and active: NO * SMT is either mitigated or disabled: NO > STATUS: NOT VULNERABLE (your CPU vendor reported your CPU model as not vulnerable) > SUMMARY: CVE-2017-5753:OK CVE-2017-5715:OK CVE-2017-5754:OK CVE-2018-3640:OK CVE-2018-3639:OK CVE-2018-3615:OK CVE-2018-3620:OK CVE-2018-3646:OK CVE-2018-12126:OK CVE-2018-12130:OK CVE-2018-12127:OK CVE-2019-11091:OK My system with the i3-6300 has every vulnerability, all 12. They're all mitigated by Linux (and the system's BIOS), but still. Last edited by JamesPeters; 10-10-2019 at 06:46 PM. |
10-10-2019, 11:30 PM | #40 |
Human being with feelings
Join Date: Mar 2008
Location: Planet Earth
Posts: 9,098
|
Hehe, I built two 5x86 AMD machines around the same time because I was given one CPU by an IT friend who had replaced it on a machine he worked on, which turned out to have a different problem. Then a customer offered me another one so I took i too.
I hadn't run spectre-meltdown-checker, but I like it's output. It just really irks me how many Intel exclusive security flaws there are that AMD doesn't have. Once the B550 chipset starts appearing on some Asus mobos, I'll get serious about building a new DAW. |
Thread Tools | |
Display Modes | |
|
|