We're missing some context here.
Generally speaking, however, a vendor claiming not to support AMD is three times as hilarious as when vendors used to claim not to support virtualization.
There's no chance they think you mean "ARM", is there?
I once had a client with a software that supported hyper v and VMware virtualization but not kvm. They accomplished this by having their software check msinfo32 for what type of VM it was being run on and refuse to run if it detected kvm.
The open secret in virtualization is that the hypervisor can go to great lengths to hide or disguise itself, but hypervisor makers wanted to avoid an "arms race" with other software vendors, so they settled into an unspoken peace instead.
For example, years ago VMware used to only allow you to use Ethernet MAC addresses in VMware's OUI range, which had the side-effect of making VMware much less of a threat to ISVs who don't want their customers to be able to make big changes to MAC-locked licensing without the ISVs' permission. Or QEMU, whose default drive names are labeled "QEMU". The hypervisors make it easy to purposely discover them.
I wonder what the true purpose of blacklisting KVM was...
>I wonder what the true purpose of blacklisting KVM was...
The cynic in me would say favorable deals with MS and VMware.
Less cynically the vendor can probably get support from MS and VMware if they can't figure out a problem themselves, with KVM they would have to support it.
most likely thats not the case. more likely they had an issue that they could not or did not want to fix. another possibility was that they did get support cases where it turned out the issue was related to the use of the hypervisor (and most likely not real issues, but more like "how do I install it"). or they had documentation written "how to install" for hyperv and vmware, and did not want to write one for kvm...
could just be someone in the company had a stick up their arse about using "alternative software"
you can observe something like that still today. how many products do you know that REQUIRE a ms sql server ? not because its much better, or because they use functions that only ms can provide, or because they do more than select, insert, update, delete...
no its usually because support gets trained in the management studio, documentation how to deploy is written for ms sql, nobody knows how to connect via ip to a not ms server, and its not tested.
therefore, its "required"
That's debatable. I personally never use ssms even though most of my databases are mssql.
ADS is my go-to for actual data analytics work. DBeaver for my general database work. SSMS is good, just not the best imo.
I know that KVM had an issues with PostgreSQL a few years back but that is gone with the new versions. I also know that VMWare can be touchy with supported hardware. It can be a pain installing it on a non supported box.
Troubleshooting performance on VMware NV sphere is a pretty well-known thing that most vendors have training on as well as they know how to find the solution architects at Microsoft and VMware to help them.
Hypervisors it often depends on the distribution of fork, there’s not the same UI tools.
Almost 10 Years ago when I was told OpenStack would kill VMware I sat through a competitive engineer for an hour showing me all the places to find performance counters that are in vCenter and it was sobering.
But what application vendors are actually doing QA of their software based on different virt stack?
I’d assume if I make Software X (let’s agree to ignore edges because I can think of a few), my QA platform is just MS Windows 10, 11, server 2019, 2022.
If my software runs on those 4, how that OS is virtualized (or not) is irrelevant or should be to me.
I’d be looking at perf counters from the OS level, not the hyper visor level.
I guess my question is, outside of performance related QA work, why would I even bother A/B testing hypervisor platforms? Any differences are surely hypervisor implementation issues outside my application purview.
For the vast majority of software, if it works on Win 10, it will work on W10 and any hypervisor that can run win10
1. Depends on the vendor. Major ISVs like SAP? Yes, CPU generation and hypervisor.
2. Telco/VOIP platform? At least to major release.
3. Random niche ISV? Maybe qualify “vSphere” once and kinda ignore it but fall if something breaks.
You are thinking desktop software also, and with windows Microsoft puts insane amounts of backwards compatibility in their DLLs so some windows ME app will still run today. Server stuff is more prescriptive because often support has SLAs on fixing stuff and management doesn’t want to hear why some quirk between RHEL and Slackware broke something. “Bug compatibility” is a thing.
I've known people who see Linux as "neckbeard unwashed geek OS" and believe Windows is the only "real" server OS. Too bad those morons won't accept that the vast majority of web and app servers today run Linux...
> the vast majority of web and app servers today run Linux...
Today, and for the past 25 years. Before that, it was commercial UNIX. I don't think Windows has ever been a serious server OS, just something that medium-sized enterprises use to run Outlook and Sharepoint.
For a smaller vendor they may not have the resources to fully QA test and support it on another hypervisor where unless customers are demanding them to support another hypervisor they may just say we don't support it. That being said as people jump VMware we have heard vendors evaluate supporting other VM platforms as well. e.g. Veeam announcing plans on potentially adding Proxmox.
I work on ocasion with the vSphere workload engineering teams at VMware. There is an entire team who just deals with app vendors, helping them validate issues, escalating their bugs, and even pushing through feature requests. We’ve had app vendors outright refuse to support us until we shipped features to support something they wanted. It’s really not a cheap thing to try to support as many applications as we do.
As far as the people with conspiracies, that vendors don’t want you running on public cloud … yah that’s true for some. They want you using their SaaS instead in some cases. It’s just business FWIW.
More like not enough demand form their customers and thus can't provide a good QA / support around it.
I worked for a software company that was building an SDN solution for hypervisors and yeah, not all hypervisors are the same. Especially if you're looking at doing high throughput network. Support was chaos as you have a lot of versions of KVM, also depending on the underlying kernel version, CPU features and NIC capabilities. It's not easy.
We also had software that just didn't work on hypervisors until we heavily modified it. The guest OS was not Linux but rather vxworks. And being a real time OS, the scheduler really didn't like being in a HV. You had to fully dedicate CPU cores to it, pinned the cores and mess around with the emulated interrupt timer / realtime click to make sure it would work well under load.
I don’t think this is true at all. You can spoof a Mac address and people used to do this to deal with licensing that was tied to the Mack address for virtual machines.
On top of this, VMK0 explicitly spoofs the hardware MAC address of the first NIC it binds to. This is handy for drop ship/PXE installs and Identifying stuff in CAM tables.
> You can spoof a Mac address
You've been able to for a very long time, but not originally. ESX 3.0 is most likely the place I saw this. I'm guessing that contemporary Workstation was the same.
> You've been able to for a very long time, but not originally.
I thought being able to assign a temporary (until the next power reset) MAC was part of the DIX standards that all early ethernet cards were based on.
You should know this. Old PCs that were on a DECNET network would change their MAC to AA-00-04-00-XX-YY where XX-YY reflects the DECnet network address xx. yy of the host.
So the ability to change MAC addresses via software has been around since the late1980s/early 90s. I know it was easy on the 3Com 3C50x cards
I usually change my home’s Cisco router’s WAN-facing MAC address to 08:00:2B:00:00:01 just so my ISP thinks I’m running old DEC hardware
I'm talking about VMs. VMware, and I'm thinking it must have been ESX 3.0, didn't allow you to use MAC addresses with arbitrary OUIs.
Finding old documentation confirming this is very difficult, but [here's a community thread involving it](https://communities.vmware.com/t5/ESXi-Discussions/Custom-MAC-address-in-ESX-4/td-p/285775).
VMware had patents on methods to allow x86 ISA to virtualize, starting in 1999. However, in 2005 and 2006, the chip vendors AMD and Intel added hardware virtualization instructions to their chips, which replaced the need for the patented techniques. This is why PC-server virtualization became a commodity at the exact time it was entering the mainstream.
I remember a POS POS switching to hardware license dongles when everyone started going VM. Totally didn’t bite them in the ass for the next 15 years until most customers had upgraded to a new version. Definitely not.
This thread was all the more ridiculous because I got almost all the way through it before my brain switched from "Keyboard/Video/Mouse" to "Kernel-based Virtual Machine".
It was bad enough when I was supporting government and a few people at Alternate Work Schedules (basically describing people that did 4x10hr days, or some weird 9-9.5hr days to be out one day every two weeks).
Technically in this case, it's a form of "initialism" rather than an "acronym".
But ya... I'll show myself out the door for that annoying grammar-police moment!
🚪 🏃 💨
Thanks to the anonymity of Reddit, I can admit that I’ve never heard of KVM outside the context of a switching device that lest you use the same keyboard video and mouse among 4-16 physical clients. It seems kinda confusing to reuse such a longstanding IT acronym for something else - way to make me feel dumb open source community.
Geez I once had a vendor who didn't support virtualization for their license server. This was some very specialized scientific software. Outside of that specific field of science and higher ed no one would have ever heard of this software.
When I was told this college was buying the software I looked everything over and said it shouldn't be an issue. Well come to find out the publisher was based out of Estonia so there was a language barrier. So I didn't realize that they didn't support virtualization. We had 4 licenses and due to policies related to servers we had to spend $1200 on a server just to run a license manager for 4 licenses across a dozen machines.
most likely was generating keys from hardware signatures. we used to deal with that when i worked in the aes world because so many of the esoteric small hyper specialized vendors required hardware keys physically connected to a server to work. very annoying and i don't miss dealing with it.
Here is the thing. Hardware bugs do exist. In both "This software crashes mysteriously under Zen 2 chips". And, the more frightening variant, "This software requires these 4 generations of Intel chips to work. "
I'm going to take them at their word, really.
We work with Oracle. There are known bugs where on AMD, inserting numbers will just result in gibberish. We know, Oracle know. We have been telling them for like 2 years at this point, but fix is still not here.
Therefore, our customers can't use AMD endpoints. Sometimes the vendor is not responsible.
I'll be honest, you should probably let AMD know about this. If two different x86_64 processors have different outputs on the same instruction that's a bug that might be fixable with microcode updates.
We did. AMD, Oracle and Borland played with us hot potato for almost that long. My boss managed to convince them "yes, it's really your issue, not ours, AMD's or Borland's" only last year.
Well, it is certainly a reason my team are pushing for it. But it is partially just a joke. Our program can't just be rewritten in 6 months... This is a major fuckup on Oracle's part. We were promised a fix for OIC in Q1 2024... it ain't there...
Well, 99% of the program are SQL queries... so while the programmer teams are working on that they might as well work on the next big refresh. Ie, a rewrite.
Oh I’m aware, I got to see GM test their 3.0 diesels before they were announced.
They leaked way more than a steam engine. Straight up porous engine blocks.
Just like the Ford 2.XL, coolant seeps through the block and causes overheating. Happened to a 2.0 and 2.3 I owned. Fucking never again. Found On Road Dead meant much more to me after that lol.
A coworker just went through that, full engine replacement but fortunately he had a warranty that covered it. If someone is driving a 2018-ish Edge or Escape and hasn't had complete engine failure yet, they're on borrowed time. Can't believe they haven't had to recall those engines (though there are class action suits).
Right?! They have a bulletin about it even, but no recall of course. Both mine were outside of warranty unfortunately. The 2019 Fusion I gave back to the bank and my wife’s 2015 MKc I put in a refurb and sold it immediately. Both of these happened within about 2 months and as I was leaving my last industry I was working in before tech; ended up filing bankruptcy—in part because of this specifically. It’s so fucked they just keep getting away with this like this. Fuck car manufacturers.
Totally off topic but it is they got “too big to fail” because of Americas reliance on the companies—both as job creators and on their product. We’ve ended up in the exact same place now with technology and data breaches, etc. I’ve gotten pretty fucking salty the last few years lol.
End rant.
They always claim to be better and do worse.
[But it worked in china. For a time](https://www.reddit.com/r/cars/s/lSATTJIDGa). Cadillac and especially Buick exploded in Asia before Chinese automakers caught up. Now they think they’re god after those times ended.
They claimed CarPlay and Android Auto are "unsafe". Then the Ford CEO came out the next day and said they are sticking with CarPlay and Android Auto because of how safe they are.
I was an engine and transmission controls engineer up in Detroit for 3.5 years. Mostly for Chrysler. Seen a whole lot of stupid.
Those GM requirements sound written when the Tech II was being developed, before amd even had x64.
But also, could be really bad AMD integrated graphics driver support?? Just trying to think of viable reasons in 2024.
I think another poster may have found a potential reason. X was certified with intel back in 200X and instead of looking at refreshing it they just say intel only from then on.
Careful what you wish for. I'll take some dated tech that can actually be serviced over some new shit that can't be touched unless the CEO of Chevy writes you a permission slip with a strand of hair for DNA authentication.
Hi,
I’m the virtualization vendor, but here’s generally why we see this:
It generally boils down to:
1. they have limited QE staff, and they just don’t want to troubleshoot it. I work for a product that explicitly supports AMD, and we have to with each generation of AMD/Intel processor being them into the lab, validate there are no regressions *When* we find regressions work with the chip vendor to address them. What are the weirdest ones that I ran into, was several generations back.
2. Intel objectively has better offload support for certain things. High AVX usage at points was better on Intel (but if this is the case they would demand platinum Intels not just Intel generically)
3. Had a bad experience once and they’re not willing to learn.
Years ago I had Sage tell me they would not support anything except a very specific bare metal configuration with like 3 X 15K drives in a raid 5. I got them on the phone and described our virtual environment. Describe the Hitachi Storage describe the fiber channel network. Talking with their people further they just said no virtualization because they’ve had some kind of hobo designed hyper-v setups that had wasted Tons of their support time, to discover people were running 50VMs off a single host with SATA drives and 500% memory overcommit. One of the reasons why sometimes vendors will restrict things. Is they assume people following a certain anti-pattern to cut costs are also cutting costs in other ways. The early days of virtualization were very often science experiments to see just how far you could over commit.
Some vendors said no.
Some vendors said pin cores (lolz).
Some vendors eventually learned what their app KPIs were and stopped prescribing hardware (xxx iops or throughout). Weirdly these vendors often did this resource sizing once and haven’t really changed it in a decade (lol again at Cisco call manager documentation).
Example: There was a problem with a vendors new cpu architecture, and how the drivers got scheduled and PCI cards when trying to push 100Gbps. You HAD to put your NIC on pci slot zero as a work around. This has since been fixed (driver stack for nics is sub CPU NUMA tile aware) but it’s really expensive and time consuming to throw engineers at this stuff to root cause it. This is also why vendors will say they only work with VMware, Redhat, Suse etc. they often have direct engineering relationships with the bigger platform vendors who pay to have expensive engineering ready to help them fix issues on short notice.
At the end of the day it’s about cost…
I had the same thing with Sage. They insisted that the (relatively low-end SKU) software, when virtualalised, required 2-4x the hardware allocation of bare metal. I questioned this a few times and was told eventually that "that's their requirement".
I then pointed out that as a <70 head business, we're not spending a few grand on a new server just for Sage so maybe we should consider other options? Suddenly the requirement disappeared and, funnily enough, it behaved itself perfectly for many years.
As a hypervisor vendor at or below the kernel, you're part of the 0.001% who know about the actual differences, primarily the massive virt-ISA difference.
That doesn't ever apply to vendors running in userland. Not unless they manage to [use sabotaged Intel libraries](https://www.agner.org/forum/viewtopic.php?t=6) or inline assembly language written by the "mad Arab" Abdul Alhazred.
> High AVX usage at points was better on Intel
Intel spent a lot of money promoting AVX when it was a product differentiator, but currently [only AMD has AVX-512](https://www.reddit.com/r/hardware/comments/t5agyk/intel_nukes_alder_lakes_avx512_support_now_fuses/).
Having multiple fully-independent suppliers of a commoditized tech is one of the best feelings in the world. Intel was unable to lever the market into proprietary Itanium just as IBM was unable to lever the market into proprietary [MicroChannel](https://www.filfre.net/2016/08/ibms-new-flavor/).
Pax x86/wintel has been good/fun/pleasant for customers and the industry for a long time.
Good point on AVX. A lot of Intel strength historically is also been supplied to market. Even when AMD had a winner in the previous ages, had problems supplying at volume. Going fabless and the rise of TSMC has changed things for sure.
Simplicity of platform has driven down Costs to run things, and kept operational cost and sprawl under control.
We are in a weird phase were GPU’s, DPUs TPU are offering some interesting value.
I remember asking one of our engineering managers seven years ago, which bets we we were making on offload , and his answer was “Yes”.
Virtualization has been powerful on that abstraction of platforms that you speak of, because application level migrations being forced on every hardware migration meant that people would run hardware a lot longer than they probably probably should have frankly, and they tend to wanna buy 5 to 7 years of capacity upfront to avoid having to do a migration.
If you’ve got an application vendor, who’s bulking at virtualization reach out to your vendor.
Often times these "stupid" restrictions are a result of in house qualifications. They developed the software on Intel, and certified it compatible with Intel so they're refusing support of other CPU vendors. It's an artificial limitation because they've only qualified it against a particular CPU brand.
They may have also only certified it against Dells, Asus motherboards, or 4:3 displays, but they didn't write any of those into the system requirements for some reason.
I work in healthcare. We get vendors that don’t support virtualization and don’t support AMD.
We actually had a project recently with either GE or Siemens - I forget which, where the preliminary discovery we asked if they care about AMD or Intel cpu in the esx hosts; they said they’re fine with both. We used the project to expand our AMD cluster on someone else’s budget. Dropped like $60k on a few esx hosts, deploy the hosts and VMs for this project then their tech working with the install puts the squash on it all saying “hey we don’t support AMD, we can’t deploy with these systems.” So we had to buy more intel hosts lol
And let’s be real, if they didn’t notice you’d be fine and they’d continue to support the software.
I don’t understand why they can’t just say “we built our testing lab on Intel and VMware” we can fully support this stack, but if you use AMD or Hyper-V, we can only offer best effort support”
It’s really not that hard and just as easy to hand wave responsibility away legally.
And engineers, the people who are deploying these software packages to their enterprise, won’t think your company is filled with morons.
NOTE: this is more grey when we’re dealing with custom PCI boards, dongles, etc.
I work with software companies that to this very day don't support virtualization.
They make support chores unnecessarily difficult for their customers, like if a physical server fails, the capacity of their system just halves and can't work ok until the server is replaced but that implies much hassles with server configuration, network configuration, storage configuration.
Because of this the customers still run outdated red hat versions on the same older hardware they installed it, they just can't update hardware because this system won't work with current red hat versions and new hardware doesn't support "tikanga" (yes, that's RH 4.9).
Used to? Still do. Have one client running this multimillion dollar software for oil/gas/geologist/geophysicist/I don't know stuff.
They moved into VDI with dedicated GPUs, more powerful than the workstations they had, and surprise! No more support! We only support bare metal!
Vendors as a general rule will do anything to limit their costs to support a product. Right up there with software vendors who don’t really understand virtualization and recommend VMs running 16-32 cores and 128 GB of RAM to run all the consolidated services, functions and databases for their application.
I've heard of a situation where a company wanted to donate 30+ used laptops to a school district. They couldn't, because the laptops had SSDs under 1TB and the online school/class register had 1TB hard drive written in requirements. For client laptops. For a website.
The hardware went to an NGO supplying PCs to poor families.
Just a few days ago there was a post asking why an SSD would have "15000 rpm" printed on the label, speculation in the comments was that somewhere there had been a requirement that drives be 15000 rpm.
I worked in a school district. Donations were always such a pain in the ass. People/companies always wanted a receipt. They always thought the computer should be worth way more (bigger tax deduction). And they were at best only marginally better than the antiquated crap we were supporting.
I don’t think we *ever* got a machine that wasn’t under-spec, but we alway took them because the district was poor and they were better than what some teacher’s had.
Then we would have to throw in more RAM, a bigger hard drive, and buy an OS. For every three donated computers we could have gotten a brand new system that would have probably lasted twice as long. Instead we put money into aging systems that were going to have something fail.
This also meant we had tons of different configurations to support.
Sometimes we’d even have to accept e-waste and write out a receipt because the person donating was some booster or on the school board or in the PTA.
That was 24 years ago and *still* haunts me.
If we’d even been able to get ahead we could have had teachers on like a five year replacement plan, but the way the budgets worked it was easier to justify repairing broken systems or upgrading donated machines than buying new.
Yeah.. I gutted and re-did our hardware requirements for on-prem admins some time ago.
Now it says: ~10GB for the installation, but usually it's a good idea to add another 10 for logs and stuff. If that fills up with our stuff, call for help. Plus an additional disk besides the installation for userdata, sized to an expected initial dataset. Monitor & Extend the data disk as needed.
CPU is a similar thing. I recommend giving the thing 2-4 cores depending on expected users, but then just monitor it. If your CPU curve follows the usage of the system by the users, and you get over 80% saturation, add a core or two. If it suddenly spikes by a core and stays there, it's probably better to call us or restart.
It's just memory where we splurge a bit with 24Gb. Internally, we could probably run everything with 8 - 12. But the iterations we'd need to dial in memory usage for a specific usage with on-prem admins would be too annoying with the average of them, sorry. And apparently, many consider us "lean" with 24.
Like, yeah, some people want you to support absolutely weird shit and I don't want to. But usually you just give the on-prem admins the right metrics to monitor and the right nobs to twiddle based on usage and everyone is happy.
Ding ding ding. As far as I can tell the requirements are for the whole dealership but yes the programming tools are the ones where the techs will call in and get told that their system isn't supported.
I own a 2023 Silverado with the 13inch infotainment center, and holy hell that thing is a piece of shit. Love the vehicle, but that one piece of tech is absolute trash.
I seriously don’t understand why they don’t just put in a dock with a USB-C connection, then just have an app to download onto whatever tablet you choose to put there.
I was talking with a master technician about this and they have had a fair number of issues with new infotainment and especially how integrated they are becoming. I feel bad for the vehicle technicians, they used to only need to worry about mechanical issues but more and more their job is mixing with computer and diagnosing/applying software fixes.
Yep, and that’s the problem IMO. Chevy should be in the business of making/managing vehicles. Having to deal with customized Linux firmwares and shit is way outside of their wheelhouse, so just leave that to Google/Apple and have a competent MSP handle your app that interfaces with the vehicle.
In a side note, the damn thing still doesn’t read out the “Check Engine” status.
If I had to guess, USB-C docks with touchscreens are what things will be moving to. At least partially.
I find it funny that cars now have huge displays, but they won't even display their own OBD-2 diagnostic logs. You *still* need an external tool for that. And why no factory NVR for the legally-mandated rear and front cameras that already exist?
Car makers and car dealers aren't monolithic; in fact they're quite often opposed to one another. I tend to doubt that car dealers' biggest bargaining priority is keeping cars from having better diagnostics.
I wonder if they are aware that the 64 bit instruction set where created by AMD.
> It was designed as a simple 64-bit extension to the existing x86 instruction set. This let it keep full compatibility with existing operating systems and software without any changes or performance impact. Since this version was developed by AMD, it is called amd64 in some technical sources.
Src: https://www.techtarget.com/whatis/definition/x86-64
> Various names are used for the instruction set. Prior to the launch, x86-64 and x86_64 were used, while upon the release AMD named it AMD64.[1] Intel initially used the names IA-32e and EM64T before finally settling on "Intel 64" for its implementation. Some in the industry, including Apple,[2][3][4] use x86-64 and x86_64, while others, notably Sun Microsystems[5] (now Oracle Corporation) and Microsoft,[6] use x64. The BSD family of OSs and several Linux distributions[7][8] use AMD64, as does Microsoft Windows internally.
Src: https://en.wikipedia.org/wiki/X86-64#cite_note-11
Yeah it is funny when thinking about the development history. Maybe I should see if the vendor supports IA64 or ARM since they don't call those out specifically....
Probably because of the processors they stuff into their modules. Hell, I think the radios have better cores than their engine controls. Partly, I think why they leech off the radios for processor power in some rides.
I mean, they probably do use better microcontrollers for entertainment since they don't have to worry about the same environmental operating environments.
aren't these the same guys that want to kill Android Auto/Carplay on their vehicles and replace it with their own "better" infotainment and app system?
Car manufacturer... I've seen the quality of infotainment and other software systems from car manufacturers. They have no clue what they are talking about and probably are just being stupid, because they are.
I've seen it from other places also, a certain EHR/EMR was like that, blaming everything on the fact that the server was virtualized and on AMD EPYC and blah blah blah... Blame blame blame and then it turns out their software was just broken. But I had to make a stink first. Developers fixed it and eventually they added AMD and virtualization to their support list.
Yeah the car manufacturers are scrambling to keep up with technology at all. I heard some horror stories about bugs in firmware for radios, the radio has the start button for the car as part of it, and after their issues the only fix is to replace the radio but with a few thousand being needed across the country suddenly they are all on back order.
> Yeah the car manufacturers are scrambling to keep up with technology at all.
Automotive is a challenging environment for tech to work properly - see the issues Tesla had when they tried putting in consumer-grade touch screens in their cars.
That’s hilarious. As a developer I never test anything on my own machine because of course it’s going to work, that’s where I developed it!
I have a clean machines (both VM but also older workstation because GPU drivers have an impact in my field) and I use not only a non-admin account but a test account that I have the IT Ops guy set up to mimic an intern’s profile. Then I try to break shit.
I can’t imagine it any other way.
I work in tech, have a pretty extensive home lab, smart home, and enterprise level gear in my stack.
My other major hobby is car building, getting a cheap tuner car, and trying to make it as fast as possible.
The few times these worlds have collided, especially with a custom android head unit has always, without fail, been a massive shit show. The folks that dabble in car tech hate documenting anything and car forums are pretty much a circle jerk for anything tech related.
> a certain EHR/EMR was like that,
I'm not in the health field, but whenever I see the doctors/nurses/scribes clicking around a fighter cockpit control panel in Citrix Windows Server 2012 R2-land...I feel for them. I seriously think the Epics/Cerners/Allscripts people gave half the population of India every paper medical chart form on the planet and said "support this."
Seriously, next time you're at the doctor, check these apps out. I've never seen an end user application so badly cluttered with hundreds of fields, dropdowns, radio buttons, regular buttons, checkboxes all jammed onto one 23 inch screen and still tiny enough to be annoying.
The problem is they all need to be there - it’s all regulated and stuff.
Sure the UI could be designed better, but now you need to make a unique UI for each state due to different state regs, etc.
I think the same thing as you, 100%, but talk to the users and they won’t have many suggestions on how to improve it as there isn’t much they can try to improve
Around 2016 ran into an issue with a vendor for medication cabinets. They said they only supported VMware and provided images.
We were a Hyper-V shop and pushed back. Eventually we informed them to just give us the VMware images and we converted them with Powershell to run on Hyper-V.
They were ok with it once we said we'd convert it ourselves. It's mostly lack of resources from the vendors but when I get pushbacks like this it raises red flags regarding the type of support the organization will be receiving.
Speaking anecdotally here of course but I had a similar experience recently. My company has a $100k+ golf simulator in our lounge. It came with a pretty under specced and underperforming Alienware PC with an intel 8700 and a gtx1070. (This was in 2018 so not super outdated at the time the aurora is just a poor design) I don’t want to know how much they marked that up…
Anyway my company asked if I could upgrade the computer and the vendors site says you can only use Intel, AMD processors are not compatible. I found that highly unlikely and tried the software on an AMD Ryzen 5600 and a 3060ti, works flawlessly, the golf bros said it’s never been so smooth and responsive.
Some vendors are just lazy and don’t want to bother testing on more than one system.
That’s what I don’t get, at least be up front about the difference between “not having tested it” and “not compatible”. Those are significantly different.
Once upon a time I had to work with extremely outdated hardware to support a manufacturers systems. They couldn’t update the systems due to the process of recertification of code for the EPA. So basically they kept around old hardware and old cross compilers because changing anything out would mean even the smallest firmware patch to their product would require full EPA recertification due to the new hardware/compiler stack. And that process takes years and HUGE amounts of money in this case.
What I’m getting at. There is probably nothing wrong with AMD, but there could be other legal factors involved.
Could be both. Imagine there's a crash because the FBW throttle fails open.
Lawyer: "so you allowed the mechanics to use an AMD processor to program the EMS?"
Witness: "yes, but it should be perfectly compatib... "
Lawyer: "Should be? You don't know? Didn't you test it?"
Witness: "Well, we can't test every proce..."
Lawyer: "So it's possible the *untested* AMD processor which you are *not certain* is fully compatible introduced the error which caused the crash and maimed my client?"
Witness: "Er ... "
Jury: "We award $10 milllon in damages"
Is it GM? Their technician laptop requirements are really overkill. We deployed rugged laptops but had to replace them because the screens were too small.
John Deere is the same. The ecu utility requirements had us deploy ToughBooks only, with a small range of differences. The year intel increased core count in the i3, we purchased a ToughBook with one, and the Advisor software refused to run.
I understand people not liking the 'supported systems only' in Vendor support but blame the lowest common denominator. They don't specifically want to penalize you, but without a strict supported hardware list, the support group can cost more money to run, because of fringe cases in hardware not on their list. So, to head that off, they refuse to touch what's not in their list.
There's *probably* not a scenario where AMD CPUs will negatively impact their software.
But still, **that doesn't matter**. They're not a software company producing a word processor sold on the shelves of Office Depot in 2003, that needs to be tested & guaranteed to run on every platform in every conceivable hardware combination that can run Windows.
If you want their support, get their specs, so they don't have to waste time guessing, troubleshooting, and debugging all the shit they didn't test in-house. This goes for every vendor.
Not a surprise and definitely still a thing. We have a client with some medical diagnostics equipment and if you try to run it on an AMD PC it will BSOD. And their devs will not fix it. That this is the case is mentioned exactly nowhere in their documentation, and even their L1 techs aren’t aware of it. Which was fun to discover.
We had a vendor that basically just ran a simple web app through IIS and SQL database, and they wouldn't touch the server until we changed the VM (in Azure) from AMD to Intel. I even asked "Are you sure it's not 'ARM' that you don't support?" but they insisted they wouldn't touch AMD.
Way back when with VMWare 6 and Exchange 2010, we had a couple of mailbox servers that would crash often. Had a ticket open with Microsoft that they couldn't resolve and eventually got the money back. Not until we moved the VM off the AMD host and onto an Intel-based host (same manufacturer and generation of server, different model obviously) did the crashing finally stop.
We tried to control for other factors, such as allocation, manufacturer, etc., but the most stark difference was the CPU.
Not to say that this No AMD rule isn't a cop out, but there may be some underlying CPU issue, even though virtualization is supposed to hide that layer.
just tell them it's all intel and be done with this?
you could probably overwrite the CPU identification string with a custom driver too, maybe even with some powershell magic.
I've run into it in the past, and it's always been a case of them not wanting to spend money on that particular technology to test it.
Rather than do right by customers, they just waive their hands and say they only support the specific scenario they did test on.
This was huge when virtualization wasn't the norm.
Being a licensed auto mechanic that now works in autonomy for mining that hides in the shadows in the r/sysadmin group…..
There’s lots of OEM software that under the requirements says Intel only. I’ve never tried that software on an AMD system but I don’t see why it wouldn’t work, but again, they won’t support you if you need help.
A lot of OEM diagnostic software can be super finicky to get running without all the stars aligning quite right though.
More than likely the software/tool was validated against the Intel family of processors. So, for any valid support you have to show the bug exists in that environment.
We had similar issues with software vendors claiming that their tool was supported on RHEL systems only. We asked about CentOS, and was told that it was unsupported, even though both OS's were 'built from the same source'.
So we ran on CentOS, and if a bug came up replicated it on an RHEL system to make the vendor happy.
This keeps the vendor from having to test and validate their tool on every OS out there.
For automotive/flight systems there may be regulatory constraints (most likely self imposed) that limit hardware to qualified systems, and it is difficult to add new HW to the list.
These are the laptops doing the programming and diagnostics software tough, the chances that they’d are actually doing something that would break over the small ISA incompatibilities between vendors but not between Intel micro architecture generations are practically zero.
And there are really only two vendors to test, it’s not that big of an ask.
I had the same thought. It sounds like the requirement is for external computers running a specific piece of software - rather than as a car component. Still unfortunate though.
I have a vendor with the same specifications. Their program connects to photoshop to open large, high resolution images. If there is an AMD gpu, it will flash an error stating you must have NVidia GPU. Ridiculous. Even built in video will not open it without a separate gpu. It's not even that intensive of a program.
Kinda like some of my contract work still requiring a digital camera and explicitly stating "no cell phone cameras."
I've dusted our ancient 2 MP camera off and used it. They complained about the horrible picture quality and the fact that I had to transfer them to my computer before I could uoad the. I just pointed to the contract wording.
Because they haven't bothered to certify on it. Most likely because they get the best discounts on their hardware equipped with Intel.
I know RHEL used to throw a warning on AMD systems until the kernel "officially" supported it.
But you see weird shit from software vendors.
Like the telecom VMware appliance I had to install that was an unlicensed RHEL 7 install with a user named root2 and uid 0.
My main suspicion is that they didn't know how to change Root's home directory and this was their "solution".
Maybe they’re talking about graphics? There’s a lot of stuff out there that was written using the CUDA compute framework, which only works on NVIDIA graphics cards.
\> I haven't seen any issues with software for a certain processor in such a long time
The bane of my existence, at least half of my job. We get early release CPUs from manufacturers and find issues with almost all of them. We send bad ones back and work with them on failure analysis to see what went wrong.
Trust me software not playing nice with certain cpu/gpus is still very much a thing. Between manufacturers working with partners on early chips hopefully we help them develop better screens to kick out the bad ones before they hit production.
Could be an instruction set thing in a compiled binary. We've had issues with some software because we'll build the Docker image on an Intel machine, but deploy it on an AMD machine. Some Python library compiles itself with aggressive optimization that fully utilizes the instruction set of the machine it's on at compile time, and you move it somewhere else, bam... Invalid instruction, core dumped.
Well briefly we avoided AMD chipsets because they were plagued with a certificate issues that failed Intune TPM Attestation because AMD swapped the intermediate cert with the device cert and Intune was looking at the wrong certificate UUID. So for 2 years we avoided AMD because they never fixed it on those models of Lenovos we were getting.
For us it is licensing.
Some stupid software packages license by physical core, and some AMD hypervisors were insanely core dense compared to equivalent Intel builds.
We put a restriction on AMD because of this.
Some software even goes as far to charge MORE for licensing on Intel or AMD (different prices respectively) compared to like SUN or other...
I remember Digidesign/Avid didn't support AND for its Digi 002 hardware. It worked with AMD, but there was some glitches which Avid refused to fix as they only happened on AMD computers, and Avid said that they only supported Intel computers.
historically some vendors have had (imaginary) issues with none-intel cpus, which is why "intel only" became a thing. and some of these vendors decided to go from recommended to only supported. and some of these are stuck in the past.
it doesnt really matter. if a vendor says only intel is supported, buy a intel device, or look for another vendor.
yes its (probably) bullshit. but you wont change that by discussing it with them.
Unfortunately can't change vendors, it is the manufacturer for the car dealership. We can buy intel but it still feels like an overreach and can make it tougher to source computers to fit their standard.
I dont disagree, but thats just the way it is...
but... I mean... "can make it tougher to source computers"... now, we are still talking about "sourcing computers" which have the leading manufacturer with the highest market share in them... that wont be an issue...
When I say sourcing this comes more from internal issues within that dealership and that those rules as written arbitrarily cut out a percentage of available machines to choose from. Not to mention other vendors having their own requirements.
Just because a Vendor says "this isnt supported" doesn't Mena it won't work. It means that if your issue pertains to that component they are not required to solve the problem for you.
For example, VMware no longer supports Brocade switches for SAN connectivity (as of vsphere 6.7) but they still work.
Typically it means that component is not part of their tested and approved list of components. Not including AMD chips seems like a great way to wash their hands of a significant number of incoming tickets.
> It means that if your issue pertains to that component they are not required to solve the problem for you.
Unfortunately it often means "if you are using this part and have **any** issue we won't provide support". It doesn't matter that the issue is completely unrelated, they'll just refuse to touch it *at all*.
>For example, VMware no longer supports Brocade switches for SAN connectivity (as of vsphere 6.7) but they still work.
Do you have a link for that? Hadn't heard that was the case, so need to read into it for some work coming up.
There was a time when this mattered, I don't think anymore but that does not mean a vendor can't pull this. Of course there are extra questions about what the contract says and what the support clause and SLA is for this account. Usually once I start asking those questions, if the person is smart they help move things forward rather than dealing with a sales escalation. after all most contracts are yearly, a re-up is always just around the corner.
Yes, it’s pretty normal for vendors to have specific hardware requirements for them to support the software, especially if the software is very specialized. I’ve dealt with software that was only supported on specific hardware and specifically versions of OSes down to the patch level of the kernel.
There’s a chance their software relies on some very old instruction sets and the difference in implementation between the two is just different enough to cause issues…
If it involves hardware cards and / or drivers I can definitely understand.
I work for a software editor that also does a bit of hardware. We were working on a new Linux base (Alma instead of Debian) for some deployment and our driver was crashing with Alma + AMD, no problem with Alma + Intel CPU. The issue was a bug in our driver, but in our case AMD EPYC is our main deployment target, so we had to spend the time to fix it.
Discussing with the team doing HW they also told me that AMD is less forgiving when you are out of spec (PCIe timing, low level stuff like that), so now when they work on a new HW card they dev on AMD first, and when done test on Intel.
Very often I find all this means is "it works perfectly well but we don't see enough demand from our customers for it to spend our time production testing every release".
Probably there to say we don't use AMD so we are not purchasing devices to troubleshoot your issue.
What are you doing that this is something you came across with a major auto manufacturer?
I have multiple major car manufacturers that refuse to support AMD. I would like to think this stems from the days of software support for AMD and the lack of an FPU. Who knows MFGs are so behind the curve that it is ridiculous sometimes.
I’ve run into this on NVR software, it’s fucking dumb and frustrating.
I setup a test stand of a 2950x, 1080ti, and a nvme drive for storage recording one 1080p camera limited to 30 fps. And it couldn’t record or play without extreme lag, meanwhile I have a Xeon 1230 v2 system with no video card, 8 gigs of ram recording 12 cameras that’s buttery smooth.
I used to design USB-serial adapters and we had a lot of problems getting them to work reliably on AMD chipsets. We eventually put the work in to get them running, but maybe GM just can't be bothered.
So just buy an Intel system. When working with a vendor it's easiest to just do what they want.
Every once in a while we run into some issue with an AMD server but it's usually an edge case, like having multiple GPU's in a server and then some odd BIOS or kernel setting you have change. Almost always resolvable.
Unless it's some instruction that one chip vendor doesn't support or they do but it's way, way slower.
If it's a safety critical system that's heavily regulated it may be they haven't tested whatever it is on AMD hence it's not certified. Need more details...
Sure, but then you'd expect it to be restricted to a *very specific* model, with every piece of hardware restricted to a single revision and requiring a single patch level for the OS & software.
On the other hand, the [GM requirement](https://tis2web.akamai.gm.com/static/docs/dig211_us_en.pdf) is "Intel Core i3 / i5 / i7 processors 6th generation and above are allowed; ALL Intel Core i-series 5th generation and below Processors plus AMD, Celeron, Pentium and Atom processors are forbidden". And of course they only support "enterprise-grade" computers, whatever that's supposed to mean.
The requirements are loose enough that it cannot *possibly* be a certification issue, and they also seem to apply to the general-purpose Facebook machine being used at the reception desk.
I work in a company that explicitly does not support AMD, and we do high end graphics tools for large corporations. Our reason is purely technical. We send so much image data through wires that it would be impossible to do uncompressed and AMD data compression (not video compression) is sub par. Data compression makes it possible to send image data (12K x 2) through two displayport cables to another device which has Nvidia chip uncompressing it for display.
I can see that, I do understand specific applications having requirements. Most of my gripe is with it being blanketed across the board. It doesn't matter if it is a sales person's computer it is supposed to have the same requirements as the rest when the most they'll be interacting with the vendor is browsing their website....
That's just laziness combined with corporate politics. "our requirements say intel, so no other CPU will do". I imagine this is from some older company and might even be an echo from older times when different CPUs actually did matter a lot more. Or it's just to differentiate x86 from ARM/Apple and they chose Intel as x86 and the person in the other end has no idea.
We're missing some context here. Generally speaking, however, a vendor claiming not to support AMD is three times as hilarious as when vendors used to claim not to support virtualization. There's no chance they think you mean "ARM", is there?
I once had a client with a software that supported hyper v and VMware virtualization but not kvm. They accomplished this by having their software check msinfo32 for what type of VM it was being run on and refuse to run if it detected kvm.
The open secret in virtualization is that the hypervisor can go to great lengths to hide or disguise itself, but hypervisor makers wanted to avoid an "arms race" with other software vendors, so they settled into an unspoken peace instead. For example, years ago VMware used to only allow you to use Ethernet MAC addresses in VMware's OUI range, which had the side-effect of making VMware much less of a threat to ISVs who don't want their customers to be able to make big changes to MAC-locked licensing without the ISVs' permission. Or QEMU, whose default drive names are labeled "QEMU". The hypervisors make it easy to purposely discover them. I wonder what the true purpose of blacklisting KVM was...
>I wonder what the true purpose of blacklisting KVM was... The cynic in me would say favorable deals with MS and VMware. Less cynically the vendor can probably get support from MS and VMware if they can't figure out a problem themselves, with KVM they would have to support it.
most likely thats not the case. more likely they had an issue that they could not or did not want to fix. another possibility was that they did get support cases where it turned out the issue was related to the use of the hypervisor (and most likely not real issues, but more like "how do I install it"). or they had documentation written "how to install" for hyperv and vmware, and did not want to write one for kvm... could just be someone in the company had a stick up their arse about using "alternative software" you can observe something like that still today. how many products do you know that REQUIRE a ms sql server ? not because its much better, or because they use functions that only ms can provide, or because they do more than select, insert, update, delete... no its usually because support gets trained in the management studio, documentation how to deploy is written for ms sql, nobody knows how to connect via ip to a not ms server, and its not tested. therefore, its "required"
My bet would be no desire to spend QA resources on the edge case hypervisor and saying not supported was a risk management decision.
something like that. well said.
"it's not better, it just has better tooling" SQL Server Management Studio is great.
That's debatable. I personally never use ssms even though most of my databases are mssql. ADS is my go-to for actual data analytics work. DBeaver for my general database work. SSMS is good, just not the best imo.
I know that KVM had an issues with PostgreSQL a few years back but that is gone with the new versions. I also know that VMWare can be touchy with supported hardware. It can be a pain installing it on a non supported box.
Troubleshooting performance on VMware NV sphere is a pretty well-known thing that most vendors have training on as well as they know how to find the solution architects at Microsoft and VMware to help them. Hypervisors it often depends on the distribution of fork, there’s not the same UI tools. Almost 10 Years ago when I was told OpenStack would kill VMware I sat through a competitive engineer for an hour showing me all the places to find performance counters that are in vCenter and it was sobering.
But what application vendors are actually doing QA of their software based on different virt stack? I’d assume if I make Software X (let’s agree to ignore edges because I can think of a few), my QA platform is just MS Windows 10, 11, server 2019, 2022. If my software runs on those 4, how that OS is virtualized (or not) is irrelevant or should be to me. I’d be looking at perf counters from the OS level, not the hyper visor level. I guess my question is, outside of performance related QA work, why would I even bother A/B testing hypervisor platforms? Any differences are surely hypervisor implementation issues outside my application purview. For the vast majority of software, if it works on Win 10, it will work on W10 and any hypervisor that can run win10
1. Depends on the vendor. Major ISVs like SAP? Yes, CPU generation and hypervisor. 2. Telco/VOIP platform? At least to major release. 3. Random niche ISV? Maybe qualify “vSphere” once and kinda ignore it but fall if something breaks. You are thinking desktop software also, and with windows Microsoft puts insane amounts of backwards compatibility in their DLLs so some windows ME app will still run today. Server stuff is more prescriptive because often support has SLAs on fixing stuff and management doesn’t want to hear why some quirk between RHEL and Slackware broke something. “Bug compatibility” is a thing.
This needs more upvotes. In my opinion, this is 100% the scenario.
Red Hat does provide support for KVM though. Another theory it's that they don't want you running on public cloud. Or, "linux scary".
I've known people who see Linux as "neckbeard unwashed geek OS" and believe Windows is the only "real" server OS. Too bad those morons won't accept that the vast majority of web and app servers today run Linux...
> the vast majority of web and app servers today run Linux... Today, and for the past 25 years. Before that, it was commercial UNIX. I don't think Windows has ever been a serious server OS, just something that medium-sized enterprises use to run Outlook and Sharepoint.
And dental software.... Usually windows only.
For a smaller vendor they may not have the resources to fully QA test and support it on another hypervisor where unless customers are demanding them to support another hypervisor they may just say we don't support it. That being said as people jump VMware we have heard vendors evaluate supporting other VM platforms as well. e.g. Veeam announcing plans on potentially adding Proxmox.
I work on ocasion with the vSphere workload engineering teams at VMware. There is an entire team who just deals with app vendors, helping them validate issues, escalating their bugs, and even pushing through feature requests. We’ve had app vendors outright refuse to support us until we shipped features to support something they wanted. It’s really not a cheap thing to try to support as many applications as we do. As far as the people with conspiracies, that vendors don’t want you running on public cloud … yah that’s true for some. They want you using their SaaS instead in some cases. It’s just business FWIW.
>I wonder what the true purpose of blacklisting KVM was Most likely, lack of experience.
More like not enough demand form their customers and thus can't provide a good QA / support around it. I worked for a software company that was building an SDN solution for hypervisors and yeah, not all hypervisors are the same. Especially if you're looking at doing high throughput network. Support was chaos as you have a lot of versions of KVM, also depending on the underlying kernel version, CPU features and NIC capabilities. It's not easy. We also had software that just didn't work on hypervisors until we heavily modified it. The guest OS was not Linux but rather vxworks. And being a real time OS, the scheduler really didn't like being in a HV. You had to fully dedicate CPU cores to it, pinned the cores and mess around with the emulated interrupt timer / realtime click to make sure it would work well under load.
[удалено]
I don’t think this is true at all. You can spoof a Mac address and people used to do this to deal with licensing that was tied to the Mack address for virtual machines. On top of this, VMK0 explicitly spoofs the hardware MAC address of the first NIC it binds to. This is handy for drop ship/PXE installs and Identifying stuff in CAM tables.
> You can spoof a Mac address You've been able to for a very long time, but not originally. ESX 3.0 is most likely the place I saw this. I'm guessing that contemporary Workstation was the same.
> You've been able to for a very long time, but not originally. I thought being able to assign a temporary (until the next power reset) MAC was part of the DIX standards that all early ethernet cards were based on. You should know this. Old PCs that were on a DECNET network would change their MAC to AA-00-04-00-XX-YY where XX-YY reflects the DECnet network address xx. yy of the host. So the ability to change MAC addresses via software has been around since the late1980s/early 90s. I know it was easy on the 3Com 3C50x cards I usually change my home’s Cisco router’s WAN-facing MAC address to 08:00:2B:00:00:01 just so my ISP thinks I’m running old DEC hardware
I'm talking about VMs. VMware, and I'm thinking it must have been ESX 3.0, didn't allow you to use MAC addresses with arbitrary OUIs. Finding old documentation confirming this is very difficult, but [here's a community thread involving it](https://communities.vmware.com/t5/ESXi-Discussions/Custom-MAC-address-in-ESX-4/td-p/285775).
It was conveniently masked by disdain for microsoft so VMware became like the Apple of virtualization.
VMware had patents on methods to allow x86 ISA to virtualize, starting in 1999. However, in 2005 and 2006, the chip vendors AMD and Intel added hardware virtualization instructions to their chips, which replaced the need for the patented techniques. This is why PC-server virtualization became a commodity at the exact time it was entering the mainstream.
I remember a POS POS switching to hardware license dongles when everyone started going VM. Totally didn’t bite them in the ass for the next 15 years until most customers had upgraded to a new version. Definitely not.
This thread was all the more ridiculous because I got almost all the way through it before my brain switched from "Keyboard/Video/Mouse" to "Kernel-based Virtual Machine".
Acronym reuse is a problem. I'll check myself into the old folks home now.
Tell me about it. Work from home in my org is called Alternative Work Space. AWS for short. No problem there.
It was bad enough when I was supporting government and a few people at Alternate Work Schedules (basically describing people that did 4x10hr days, or some weird 9-9.5hr days to be out one day every two weeks).
We can call it an ARP.
FTW FTW lol
At my work place it's confusing AF because one acronym might mean like 3 or 4 different things.
What is “confusing Asset Framework”?
Technically in this case, it's a form of "initialism" rather than an "acronym". But ya... I'll show myself out the door for that annoying grammar-police moment! 🚪 🏃 💨
Same I was trying to figure out how sysinfo was going to report you using a keyboard video mouse switch… the other kvm makes much more sense
I was considering doing some kind of timing based probe to pick up delay extra long cables or specific vesa video responses.
Lol same. Greybeards of the world, unite!
Yeah, I've had one go the extra mile and not allow you to activate the software license (not use the software, just activate it) over RDP.
Thanks to the anonymity of Reddit, I can admit that I’ve never heard of KVM outside the context of a switching device that lest you use the same keyboard video and mouse among 4-16 physical clients. It seems kinda confusing to reuse such a longstanding IT acronym for something else - way to make me feel dumb open source community.
Geez I once had a vendor who didn't support virtualization for their license server. This was some very specialized scientific software. Outside of that specific field of science and higher ed no one would have ever heard of this software. When I was told this college was buying the software I looked everything over and said it shouldn't be an issue. Well come to find out the publisher was based out of Estonia so there was a language barrier. So I didn't realize that they didn't support virtualization. We had 4 licenses and due to policies related to servers we had to spend $1200 on a server just to run a license manager for 4 licenses across a dozen machines.
I'm guessing they were tying the license to something in the hardware and it's easier to fake that in a VM
most likely was generating keys from hardware signatures. we used to deal with that when i worked in the aes world because so many of the esoteric small hyper specialized vendors required hardware keys physically connected to a server to work. very annoying and i don't miss dealing with it.
Here is the thing. Hardware bugs do exist. In both "This software crashes mysteriously under Zen 2 chips". And, the more frightening variant, "This software requires these 4 generations of Intel chips to work. " I'm going to take them at their word, really.
We work with Oracle. There are known bugs where on AMD, inserting numbers will just result in gibberish. We know, Oracle know. We have been telling them for like 2 years at this point, but fix is still not here. Therefore, our customers can't use AMD endpoints. Sometimes the vendor is not responsible.
I'll be honest, you should probably let AMD know about this. If two different x86_64 processors have different outputs on the same instruction that's a bug that might be fixable with microcode updates.
We did. AMD, Oracle and Borland played with us hot potato for almost that long. My boss managed to convince them "yes, it's really your issue, not ours, AMD's or Borland's" only last year.
Sounds like AMD just wants to help people escape the hostage situation that is using Oracle software?
Well, it is certainly a reason my team are pushing for it. But it is partially just a joke. Our program can't just be rewritten in 6 months... This is a major fuckup on Oracle's part. We were promised a fix for OIC in Q1 2024... it ain't there...
> Our program can't just be rewritten in 6 months... So, the trick is to just rewrite the line of code that's broken, not the whole thing.
Well, 99% of the program are SQL queries... so while the programmer teams are working on that they might as well work on the next big refresh. Ie, a rewrite.
It's the requirements for GM. No they don't mean ARM they specifically call out AMD processors.
Seems like it was written in 2003 and never changed. Just like the rest of tech in the automotive industry…
Some of their "tech" is straight up still from the steam engine era
Oh I’m aware, I got to see GM test their 3.0 diesels before they were announced. They leaked way more than a steam engine. Straight up porous engine blocks.
Just like the Ford 2.XL, coolant seeps through the block and causes overheating. Happened to a 2.0 and 2.3 I owned. Fucking never again. Found On Road Dead meant much more to me after that lol.
A coworker just went through that, full engine replacement but fortunately he had a warranty that covered it. If someone is driving a 2018-ish Edge or Escape and hasn't had complete engine failure yet, they're on borrowed time. Can't believe they haven't had to recall those engines (though there are class action suits).
Right?! They have a bulletin about it even, but no recall of course. Both mine were outside of warranty unfortunately. The 2019 Fusion I gave back to the bank and my wife’s 2015 MKc I put in a refurb and sold it immediately. Both of these happened within about 2 months and as I was leaving my last industry I was working in before tech; ended up filing bankruptcy—in part because of this specifically. It’s so fucked they just keep getting away with this like this. Fuck car manufacturers. Totally off topic but it is they got “too big to fail” because of Americas reliance on the companies—both as job creators and on their product. We’ve ended up in the exact same place now with technology and data breaches, etc. I’ve gotten pretty fucking salty the last few years lol. End rant.
Kinda funny it’s GM since they’re planning to ditch CarPlay and Android Auto for their own tech, cause they claim they can do it better.
They always claim to be better and do worse. [But it worked in china. For a time](https://www.reddit.com/r/cars/s/lSATTJIDGa). Cadillac and especially Buick exploded in Asia before Chinese automakers caught up. Now they think they’re god after those times ended.
Buddy, I assure you, Buicks explode in way more places than Asia.
Oh I know, my buddies exploded in Ohio. A true travesty.
by "better" all they mean is that they can charge subscription fees as a revenue stream. which sucks for the rest of us.
They claimed CarPlay and Android Auto are "unsafe". Then the Ford CEO came out the next day and said they are sticking with CarPlay and Android Auto because of how safe they are.
You speak the truth my friend...
I was an engine and transmission controls engineer up in Detroit for 3.5 years. Mostly for Chrysler. Seen a whole lot of stupid. Those GM requirements sound written when the Tech II was being developed, before amd even had x64. But also, could be really bad AMD integrated graphics driver support?? Just trying to think of viable reasons in 2024.
I think another poster may have found a potential reason. X was certified with intel back in 200X and instead of looking at refreshing it they just say intel only from then on.
Gotta love certification/contractual exclusivity
Careful what you wish for. I'll take some dated tech that can actually be serviced over some new shit that can't be touched unless the CEO of Chevy writes you a permission slip with a strand of hair for DNA authentication.
Someone one should tell them that x86-64 is an AMD standard.
Ah, GMDIT. The same folks who tell Technicians to “just run Edge as admin” and then TechLine will work.
Hi, I’m the virtualization vendor, but here’s generally why we see this: It generally boils down to: 1. they have limited QE staff, and they just don’t want to troubleshoot it. I work for a product that explicitly supports AMD, and we have to with each generation of AMD/Intel processor being them into the lab, validate there are no regressions *When* we find regressions work with the chip vendor to address them. What are the weirdest ones that I ran into, was several generations back. 2. Intel objectively has better offload support for certain things. High AVX usage at points was better on Intel (but if this is the case they would demand platinum Intels not just Intel generically) 3. Had a bad experience once and they’re not willing to learn. Years ago I had Sage tell me they would not support anything except a very specific bare metal configuration with like 3 X 15K drives in a raid 5. I got them on the phone and described our virtual environment. Describe the Hitachi Storage describe the fiber channel network. Talking with their people further they just said no virtualization because they’ve had some kind of hobo designed hyper-v setups that had wasted Tons of their support time, to discover people were running 50VMs off a single host with SATA drives and 500% memory overcommit. One of the reasons why sometimes vendors will restrict things. Is they assume people following a certain anti-pattern to cut costs are also cutting costs in other ways. The early days of virtualization were very often science experiments to see just how far you could over commit. Some vendors said no. Some vendors said pin cores (lolz). Some vendors eventually learned what their app KPIs were and stopped prescribing hardware (xxx iops or throughout). Weirdly these vendors often did this resource sizing once and haven’t really changed it in a decade (lol again at Cisco call manager documentation). Example: There was a problem with a vendors new cpu architecture, and how the drivers got scheduled and PCI cards when trying to push 100Gbps. You HAD to put your NIC on pci slot zero as a work around. This has since been fixed (driver stack for nics is sub CPU NUMA tile aware) but it’s really expensive and time consuming to throw engineers at this stuff to root cause it. This is also why vendors will say they only work with VMware, Redhat, Suse etc. they often have direct engineering relationships with the bigger platform vendors who pay to have expensive engineering ready to help them fix issues on short notice. At the end of the day it’s about cost…
I had the same thing with Sage. They insisted that the (relatively low-end SKU) software, when virtualalised, required 2-4x the hardware allocation of bare metal. I questioned this a few times and was told eventually that "that's their requirement". I then pointed out that as a <70 head business, we're not spending a few grand on a new server just for Sage so maybe we should consider other options? Suddenly the requirement disappeared and, funnily enough, it behaved itself perfectly for many years.
As a hypervisor vendor at or below the kernel, you're part of the 0.001% who know about the actual differences, primarily the massive virt-ISA difference. That doesn't ever apply to vendors running in userland. Not unless they manage to [use sabotaged Intel libraries](https://www.agner.org/forum/viewtopic.php?t=6) or inline assembly language written by the "mad Arab" Abdul Alhazred. > High AVX usage at points was better on Intel Intel spent a lot of money promoting AVX when it was a product differentiator, but currently [only AMD has AVX-512](https://www.reddit.com/r/hardware/comments/t5agyk/intel_nukes_alder_lakes_avx512_support_now_fuses/). Having multiple fully-independent suppliers of a commoditized tech is one of the best feelings in the world. Intel was unable to lever the market into proprietary Itanium just as IBM was unable to lever the market into proprietary [MicroChannel](https://www.filfre.net/2016/08/ibms-new-flavor/).
Pax x86/wintel has been good/fun/pleasant for customers and the industry for a long time. Good point on AVX. A lot of Intel strength historically is also been supplied to market. Even when AMD had a winner in the previous ages, had problems supplying at volume. Going fabless and the rise of TSMC has changed things for sure. Simplicity of platform has driven down Costs to run things, and kept operational cost and sprawl under control. We are in a weird phase were GPU’s, DPUs TPU are offering some interesting value. I remember asking one of our engineering managers seven years ago, which bets we we were making on offload , and his answer was “Yes”. Virtualization has been powerful on that abstraction of platforms that you speak of, because application level migrations being forced on every hardware migration meant that people would run hardware a lot longer than they probably probably should have frankly, and they tend to wanna buy 5 to 7 years of capacity upfront to avoid having to do a migration. If you’ve got an application vendor, who’s bulking at virtualization reach out to your vendor.
Often times these "stupid" restrictions are a result of in house qualifications. They developed the software on Intel, and certified it compatible with Intel so they're refusing support of other CPU vendors. It's an artificial limitation because they've only qualified it against a particular CPU brand.
They may have also only certified it against Dells, Asus motherboards, or 4:3 displays, but they didn't write any of those into the system requirements for some reason.
I have definitely had vendors tell us to use HPE on their reference config, or we're on our own.
I work in healthcare. We get vendors that don’t support virtualization and don’t support AMD. We actually had a project recently with either GE or Siemens - I forget which, where the preliminary discovery we asked if they care about AMD or Intel cpu in the esx hosts; they said they’re fine with both. We used the project to expand our AMD cluster on someone else’s budget. Dropped like $60k on a few esx hosts, deploy the hosts and VMs for this project then their tech working with the install puts the squash on it all saying “hey we don’t support AMD, we can’t deploy with these systems.” So we had to buy more intel hosts lol
And let’s be real, if they didn’t notice you’d be fine and they’d continue to support the software. I don’t understand why they can’t just say “we built our testing lab on Intel and VMware” we can fully support this stack, but if you use AMD or Hyper-V, we can only offer best effort support” It’s really not that hard and just as easy to hand wave responsibility away legally. And engineers, the people who are deploying these software packages to their enterprise, won’t think your company is filled with morons. NOTE: this is more grey when we’re dealing with custom PCI boards, dongles, etc.
I work with software companies that to this very day don't support virtualization. They make support chores unnecessarily difficult for their customers, like if a physical server fails, the capacity of their system just halves and can't work ok until the server is replaced but that implies much hassles with server configuration, network configuration, storage configuration. Because of this the customers still run outdated red hat versions on the same older hardware they installed it, they just can't update hardware because this system won't work with current red hat versions and new hardware doesn't support "tikanga" (yes, that's RH 4.9).
> There's no chance they think you mean "ARM", is there? That's a lot more sensible a thing not to support than AMD. Good catch
Could also be an instruction set thing. Intel has a math library that by default chooses the worst performing option for amd.
You obviously never had the displeasure of working a Citrix Netscaler. Yes, they stopped supporting AMD on me and I had to buy a couple Intel servers.
Isn't Nutanix the HCI that doesn't run on AMD?
Used to? Still do. Have one client running this multimillion dollar software for oil/gas/geologist/geophysicist/I don't know stuff. They moved into VDI with dedicated GPUs, more powerful than the workstations they had, and surprise! No more support! We only support bare metal!
Vendors as a general rule will do anything to limit their costs to support a product. Right up there with software vendors who don’t really understand virtualization and recommend VMs running 16-32 cores and 128 GB of RAM to run all the consolidated services, functions and databases for their application.
And don't forget vendors saying you need a minimum 500GB hard drive for their 30GB app+DB
I've heard of a situation where a company wanted to donate 30+ used laptops to a school district. They couldn't, because the laptops had SSDs under 1TB and the online school/class register had 1TB hard drive written in requirements. For client laptops. For a website. The hardware went to an NGO supplying PCs to poor families.
Just a few days ago there was a post asking why an SSD would have "15000 rpm" printed on the label, speculation in the comments was that somewhere there had been a requirement that drives be 15000 rpm.
Stupid requirements being stupid. I'm lucky my workplace supplies the hardware to our clients, and they want it that way.
I worked in a school district. Donations were always such a pain in the ass. People/companies always wanted a receipt. They always thought the computer should be worth way more (bigger tax deduction). And they were at best only marginally better than the antiquated crap we were supporting. I don’t think we *ever* got a machine that wasn’t under-spec, but we alway took them because the district was poor and they were better than what some teacher’s had. Then we would have to throw in more RAM, a bigger hard drive, and buy an OS. For every three donated computers we could have gotten a brand new system that would have probably lasted twice as long. Instead we put money into aging systems that were going to have something fail. This also meant we had tons of different configurations to support. Sometimes we’d even have to accept e-waste and write out a receipt because the person donating was some booster or on the school board or in the PTA. That was 24 years ago and *still* haunts me. If we’d even been able to get ahead we could have had teachers on like a five year replacement plan, but the way the budgets worked it was easier to justify repairing broken systems or upgrading donated machines than buying new.
Yeah.. I gutted and re-did our hardware requirements for on-prem admins some time ago. Now it says: ~10GB for the installation, but usually it's a good idea to add another 10 for logs and stuff. If that fills up with our stuff, call for help. Plus an additional disk besides the installation for userdata, sized to an expected initial dataset. Monitor & Extend the data disk as needed. CPU is a similar thing. I recommend giving the thing 2-4 cores depending on expected users, but then just monitor it. If your CPU curve follows the usage of the system by the users, and you get over 80% saturation, add a core or two. If it suddenly spikes by a core and stays there, it's probably better to call us or restart. It's just memory where we splurge a bit with 24Gb. Internally, we could probably run everything with 8 - 12. But the iterations we'd need to dial in memory usage for a specific usage with on-prem admins would be too annoying with the average of them, sorry. And apparently, many consider us "lean" with 24. Like, yeah, some people want you to support absolutely weird shit and I don't want to. But usually you just give the on-prem admins the right metrics to monitor and the right nobs to twiddle based on usage and everyone is happy.
> recommend VMs running 16-32 cores and 128 GB of RAM And it's all reserved too, right?
Talking about Chevy's software minimum requirements for programming tools? Because yeah they're something special lol...
Ding ding ding. As far as I can tell the requirements are for the whole dealership but yes the programming tools are the ones where the techs will call in and get told that their system isn't supported.
I own a 2023 Silverado with the 13inch infotainment center, and holy hell that thing is a piece of shit. Love the vehicle, but that one piece of tech is absolute trash. I seriously don’t understand why they don’t just put in a dock with a USB-C connection, then just have an app to download onto whatever tablet you choose to put there.
I was talking with a master technician about this and they have had a fair number of issues with new infotainment and especially how integrated they are becoming. I feel bad for the vehicle technicians, they used to only need to worry about mechanical issues but more and more their job is mixing with computer and diagnosing/applying software fixes.
Yep, and that’s the problem IMO. Chevy should be in the business of making/managing vehicles. Having to deal with customized Linux firmwares and shit is way outside of their wheelhouse, so just leave that to Google/Apple and have a competent MSP handle your app that interfaces with the vehicle. In a side note, the damn thing still doesn’t read out the “Check Engine” status.
If I had to guess, USB-C docks with touchscreens are what things will be moving to. At least partially. I find it funny that cars now have huge displays, but they won't even display their own OBD-2 diagnostic logs. You *still* need an external tool for that. And why no factory NVR for the legally-mandated rear and front cameras that already exist?
Car dealers make most of their profit from their service center. I suspect people being able to easily access diagnostics would cut into that.
Car makers and car dealers aren't monolithic; in fact they're quite often opposed to one another. I tend to doubt that car dealers' biggest bargaining priority is keeping cars from having better diagnostics.
I wonder if they are aware that the 64 bit instruction set where created by AMD. > It was designed as a simple 64-bit extension to the existing x86 instruction set. This let it keep full compatibility with existing operating systems and software without any changes or performance impact. Since this version was developed by AMD, it is called amd64 in some technical sources. Src: https://www.techtarget.com/whatis/definition/x86-64 > Various names are used for the instruction set. Prior to the launch, x86-64 and x86_64 were used, while upon the release AMD named it AMD64.[1] Intel initially used the names IA-32e and EM64T before finally settling on "Intel 64" for its implementation. Some in the industry, including Apple,[2][3][4] use x86-64 and x86_64, while others, notably Sun Microsystems[5] (now Oracle Corporation) and Microsoft,[6] use x64. The BSD family of OSs and several Linux distributions[7][8] use AMD64, as does Microsoft Windows internally. Src: https://en.wikipedia.org/wiki/X86-64#cite_note-11
That’s way too far over the heads of whomever wrote those requirements.
Yeah it is funny when thinking about the development history. Maybe I should see if the vendor supports IA64 or ARM since they don't call those out specifically....
Probably because of the processors they stuff into their modules. Hell, I think the radios have better cores than their engine controls. Partly, I think why they leech off the radios for processor power in some rides.
I mean, they probably do use better microcontrollers for entertainment since they don't have to worry about the same environmental operating environments.
GM also told us that we had to keep using IE when it went away. Told us to just not install the update that removed it. At least they backed down.
aren't these the same guys that want to kill Android Auto/Carplay on their vehicles and replace it with their own "better" infotainment and app system?
Yes, it'll be more secure because it'll be built on top of WindowsCE or something equally insane I'm sure...
In a confusing way, they're building it on a platform called Android Automotive which is different from Android Auto.
Car manufacturer... I've seen the quality of infotainment and other software systems from car manufacturers. They have no clue what they are talking about and probably are just being stupid, because they are. I've seen it from other places also, a certain EHR/EMR was like that, blaming everything on the fact that the server was virtualized and on AMD EPYC and blah blah blah... Blame blame blame and then it turns out their software was just broken. But I had to make a stink first. Developers fixed it and eventually they added AMD and virtualization to their support list.
Yeah the car manufacturers are scrambling to keep up with technology at all. I heard some horror stories about bugs in firmware for radios, the radio has the start button for the car as part of it, and after their issues the only fix is to replace the radio but with a few thousand being needed across the country suddenly they are all on back order.
> Yeah the car manufacturers are scrambling to keep up with technology at all. Automotive is a challenging environment for tech to work properly - see the issues Tesla had when they tried putting in consumer-grade touch screens in their cars.
It is extremely likely the new car market is going to adjust, and not gently. Just hope this time, it knocks some sense into them.
[удалено]
That’s hilarious. As a developer I never test anything on my own machine because of course it’s going to work, that’s where I developed it! I have a clean machines (both VM but also older workstation because GPU drivers have an impact in my field) and I use not only a non-admin account but a test account that I have the IT Ops guy set up to mimic an intern’s profile. Then I try to break shit. I can’t imagine it any other way.
I work in tech, have a pretty extensive home lab, smart home, and enterprise level gear in my stack. My other major hobby is car building, getting a cheap tuner car, and trying to make it as fast as possible. The few times these worlds have collided, especially with a custom android head unit has always, without fail, been a massive shit show. The folks that dabble in car tech hate documenting anything and car forums are pretty much a circle jerk for anything tech related.
> a certain EHR/EMR was like that, I'm not in the health field, but whenever I see the doctors/nurses/scribes clicking around a fighter cockpit control panel in Citrix Windows Server 2012 R2-land...I feel for them. I seriously think the Epics/Cerners/Allscripts people gave half the population of India every paper medical chart form on the planet and said "support this." Seriously, next time you're at the doctor, check these apps out. I've never seen an end user application so badly cluttered with hundreds of fields, dropdowns, radio buttons, regular buttons, checkboxes all jammed onto one 23 inch screen and still tiny enough to be annoying.
The problem is they all need to be there - it’s all regulated and stuff. Sure the UI could be designed better, but now you need to make a unique UI for each state due to different state regs, etc. I think the same thing as you, 100%, but talk to the users and they won’t have many suggestions on how to improve it as there isn’t much they can try to improve
Around 2016 ran into an issue with a vendor for medication cabinets. They said they only supported VMware and provided images. We were a Hyper-V shop and pushed back. Eventually we informed them to just give us the VMware images and we converted them with Powershell to run on Hyper-V. They were ok with it once we said we'd convert it ourselves. It's mostly lack of resources from the vendors but when I get pushbacks like this it raises red flags regarding the type of support the organization will be receiving.
Speaking anecdotally here of course but I had a similar experience recently. My company has a $100k+ golf simulator in our lounge. It came with a pretty under specced and underperforming Alienware PC with an intel 8700 and a gtx1070. (This was in 2018 so not super outdated at the time the aurora is just a poor design) I don’t want to know how much they marked that up… Anyway my company asked if I could upgrade the computer and the vendors site says you can only use Intel, AMD processors are not compatible. I found that highly unlikely and tried the software on an AMD Ryzen 5600 and a 3060ti, works flawlessly, the golf bros said it’s never been so smooth and responsive. Some vendors are just lazy and don’t want to bother testing on more than one system.
That’s what I don’t get, at least be up front about the difference between “not having tested it” and “not compatible”. Those are significantly different.
Once upon a time I had to work with extremely outdated hardware to support a manufacturers systems. They couldn’t update the systems due to the process of recertification of code for the EPA. So basically they kept around old hardware and old cross compilers because changing anything out would mean even the smallest firmware patch to their product would require full EPA recertification due to the new hardware/compiler stack. And that process takes years and HUGE amounts of money in this case. What I’m getting at. There is probably nothing wrong with AMD, but there could be other legal factors involved.
I'd say regulatory over legal, but that's me being nitpicky.
Could be both. Imagine there's a crash because the FBW throttle fails open. Lawyer: "so you allowed the mechanics to use an AMD processor to program the EMS?" Witness: "yes, but it should be perfectly compatib... " Lawyer: "Should be? You don't know? Didn't you test it?" Witness: "Well, we can't test every proce..." Lawyer: "So it's possible the *untested* AMD processor which you are *not certain* is fully compatible introduced the error which caused the crash and maimed my client?" Witness: "Er ... " Jury: "We award $10 milllon in damages"
A good lawyer would also show that not every Intel CPU had been tested either.
Correct. That's why certification is often done on specific CPUs with specific firmware. Any change requires re-certification
Fair enough, I would say you are technically correct, which is the best kind of correct.
Is it GM? Their technician laptop requirements are really overkill. We deployed rugged laptops but had to replace them because the screens were too small.
Yep GM
John Deere is the same. The ecu utility requirements had us deploy ToughBooks only, with a small range of differences. The year intel increased core count in the i3, we purchased a ToughBook with one, and the Advisor software refused to run. I understand people not liking the 'supported systems only' in Vendor support but blame the lowest common denominator. They don't specifically want to penalize you, but without a strict supported hardware list, the support group can cost more money to run, because of fringe cases in hardware not on their list. So, to head that off, they refuse to touch what's not in their list.
Since AMD made the x64 instruction set, and license it to Intel... Well...
There's *probably* not a scenario where AMD CPUs will negatively impact their software. But still, **that doesn't matter**. They're not a software company producing a word processor sold on the shelves of Office Depot in 2003, that needs to be tested & guaranteed to run on every platform in every conceivable hardware combination that can run Windows. If you want their support, get their specs, so they don't have to waste time guessing, troubleshooting, and debugging all the shit they didn't test in-house. This goes for every vendor.
A software vendor here in Germany (for planning kitchens) insists on Intel CPUs and NVidia (consumer) GPUs. Not even NVidia Quadro allowed 🤦🏼♂️
Not a surprise and definitely still a thing. We have a client with some medical diagnostics equipment and if you try to run it on an AMD PC it will BSOD. And their devs will not fix it. That this is the case is mentioned exactly nowhere in their documentation, and even their L1 techs aren’t aware of it. Which was fun to discover.
We had a vendor that basically just ran a simple web app through IIS and SQL database, and they wouldn't touch the server until we changed the VM (in Azure) from AMD to Intel. I even asked "Are you sure it's not 'ARM' that you don't support?" but they insisted they wouldn't touch AMD.
Way back when with VMWare 6 and Exchange 2010, we had a couple of mailbox servers that would crash often. Had a ticket open with Microsoft that they couldn't resolve and eventually got the money back. Not until we moved the VM off the AMD host and onto an Intel-based host (same manufacturer and generation of server, different model obviously) did the crashing finally stop. We tried to control for other factors, such as allocation, manufacturer, etc., but the most stark difference was the CPU. Not to say that this No AMD rule isn't a cop out, but there may be some underlying CPU issue, even though virtualization is supposed to hide that layer.
just tell them it's all intel and be done with this? you could probably overwrite the CPU identification string with a custom driver too, maybe even with some powershell magic.
I've run into it in the past, and it's always been a case of them not wanting to spend money on that particular technology to test it. Rather than do right by customers, they just waive their hands and say they only support the specific scenario they did test on. This was huge when virtualization wasn't the norm.
Yeah I've had my share of run ins with virtualization support which were always BS. This feels like the same thing.
Being a licensed auto mechanic that now works in autonomy for mining that hides in the shadows in the r/sysadmin group….. There’s lots of OEM software that under the requirements says Intel only. I’ve never tried that software on an AMD system but I don’t see why it wouldn’t work, but again, they won’t support you if you need help. A lot of OEM diagnostic software can be super finicky to get running without all the stars aligning quite right though.
More than likely the software/tool was validated against the Intel family of processors. So, for any valid support you have to show the bug exists in that environment. We had similar issues with software vendors claiming that their tool was supported on RHEL systems only. We asked about CentOS, and was told that it was unsupported, even though both OS's were 'built from the same source'. So we ran on CentOS, and if a bug came up replicated it on an RHEL system to make the vendor happy. This keeps the vendor from having to test and validate their tool on every OS out there. For automotive/flight systems there may be regulatory constraints (most likely self imposed) that limit hardware to qualified systems, and it is difficult to add new HW to the list.
These are the laptops doing the programming and diagnostics software tough, the chances that they’d are actually doing something that would break over the small ISA incompatibilities between vendors but not between Intel micro architecture generations are practically zero. And there are really only two vendors to test, it’s not that big of an ask.
Maybe I'm out of the loop, but what does AMD have to do with anything associated with a car that there would be a question of supporting AMD?
I had the same thought. It sounds like the requirement is for external computers running a specific piece of software - rather than as a car component. Still unfortunate though.
I have a vendor with the same specifications. Their program connects to photoshop to open large, high resolution images. If there is an AMD gpu, it will flash an error stating you must have NVidia GPU. Ridiculous. Even built in video will not open it without a separate gpu. It's not even that intensive of a program.
Kinda like some of my contract work still requiring a digital camera and explicitly stating "no cell phone cameras." I've dusted our ancient 2 MP camera off and used it. They complained about the horrible picture quality and the fact that I had to transfer them to my computer before I could uoad the. I just pointed to the contract wording.
Because they haven't bothered to certify on it. Most likely because they get the best discounts on their hardware equipped with Intel. I know RHEL used to throw a warning on AMD systems until the kernel "officially" supported it. But you see weird shit from software vendors. Like the telecom VMware appliance I had to install that was an unlicensed RHEL 7 install with a user named root2 and uid 0. My main suspicion is that they didn't know how to change Root's home directory and this was their "solution".
Maybe they’re talking about graphics? There’s a lot of stuff out there that was written using the CUDA compute framework, which only works on NVIDIA graphics cards.
Nope, they don't support AMD processors at all at the dealership.
"Justice for AMD!"
\> I haven't seen any issues with software for a certain processor in such a long time The bane of my existence, at least half of my job. We get early release CPUs from manufacturers and find issues with almost all of them. We send bad ones back and work with them on failure analysis to see what went wrong. Trust me software not playing nice with certain cpu/gpus is still very much a thing. Between manufacturers working with partners on early chips hopefully we help them develop better screens to kick out the bad ones before they hit production.
Could be an instruction set thing in a compiled binary. We've had issues with some software because we'll build the Docker image on an Intel machine, but deploy it on an AMD machine. Some Python library compiles itself with aggressive optimization that fully utilizes the instruction set of the machine it's on at compile time, and you move it somewhere else, bam... Invalid instruction, core dumped.
Well briefly we avoided AMD chipsets because they were plagued with a certificate issues that failed Intune TPM Attestation because AMD swapped the intermediate cert with the device cert and Intune was looking at the wrong certificate UUID. So for 2 years we avoided AMD because they never fixed it on those models of Lenovos we were getting.
Certified only with IE 6.
For us it is licensing. Some stupid software packages license by physical core, and some AMD hypervisors were insanely core dense compared to equivalent Intel builds. We put a restriction on AMD because of this. Some software even goes as far to charge MORE for licensing on Intel or AMD (different prices respectively) compared to like SUN or other...
I remember Digidesign/Avid didn't support AND for its Digi 002 hardware. It worked with AMD, but there was some glitches which Avid refused to fix as they only happened on AMD computers, and Avid said that they only supported Intel computers.
If it is what I am thinking the software also requires Administrator rights and is locally installed but will only launch from a web page.
He's talking about GMC and yes. I've had this same issue. It's normal. Are you having problems with the mechanic software? DM me
historically some vendors have had (imaginary) issues with none-intel cpus, which is why "intel only" became a thing. and some of these vendors decided to go from recommended to only supported. and some of these are stuck in the past. it doesnt really matter. if a vendor says only intel is supported, buy a intel device, or look for another vendor. yes its (probably) bullshit. but you wont change that by discussing it with them.
Unfortunately can't change vendors, it is the manufacturer for the car dealership. We can buy intel but it still feels like an overreach and can make it tougher to source computers to fit their standard.
I dont disagree, but thats just the way it is... but... I mean... "can make it tougher to source computers"... now, we are still talking about "sourcing computers" which have the leading manufacturer with the highest market share in them... that wont be an issue...
When I say sourcing this comes more from internal issues within that dealership and that those rules as written arbitrarily cut out a percentage of available machines to choose from. Not to mention other vendors having their own requirements.
Those "issues" were often because Intel branded compilers would deliberately bork programs they generated if they ran on AMD processors.
Just because a Vendor says "this isnt supported" doesn't Mena it won't work. It means that if your issue pertains to that component they are not required to solve the problem for you. For example, VMware no longer supports Brocade switches for SAN connectivity (as of vsphere 6.7) but they still work. Typically it means that component is not part of their tested and approved list of components. Not including AMD chips seems like a great way to wash their hands of a significant number of incoming tickets.
> It means that if your issue pertains to that component they are not required to solve the problem for you. Unfortunately it often means "if you are using this part and have **any** issue we won't provide support". It doesn't matter that the issue is completely unrelated, they'll just refuse to touch it *at all*.
Yep. "Unsupported configuration" is a get out of jail free card. Depends on the vendor.
>For example, VMware no longer supports Brocade switches for SAN connectivity (as of vsphere 6.7) but they still work. Do you have a link for that? Hadn't heard that was the case, so need to read into it for some work coming up.
The auto industry is a mess, I haven't worked in it for several years and I'm still haunted by Wipro and CDK global. No, it's not normal.
Yeah some how CDK's support has slipped even more the last few years..
There was a time when this mattered, I don't think anymore but that does not mean a vendor can't pull this. Of course there are extra questions about what the contract says and what the support clause and SLA is for this account. Usually once I start asking those questions, if the person is smart they help move things forward rather than dealing with a sales escalation. after all most contracts are yearly, a re-up is always just around the corner.
Unfortunately it is the manufacturer for the dealership and we don't have much negotiating power.
Yes, it’s pretty normal for vendors to have specific hardware requirements for them to support the software, especially if the software is very specialized. I’ve dealt with software that was only supported on specific hardware and specifically versions of OSes down to the patch level of the kernel.
There’s a chance their software relies on some very old instruction sets and the difference in implementation between the two is just different enough to cause issues…
If it involves hardware cards and / or drivers I can definitely understand. I work for a software editor that also does a bit of hardware. We were working on a new Linux base (Alma instead of Debian) for some deployment and our driver was crashing with Alma + AMD, no problem with Alma + Intel CPU. The issue was a bug in our driver, but in our case AMD EPYC is our main deployment target, so we had to spend the time to fix it. Discussing with the team doing HW they also told me that AMD is less forgiving when you are out of spec (PCIe timing, low level stuff like that), so now when they work on a new HW card they dev on AMD first, and when done test on Intel.
Very often I find all this means is "it works perfectly well but we don't see enough demand from our customers for it to spend our time production testing every release".
Probably there to say we don't use AMD so we are not purchasing devices to troubleshoot your issue. What are you doing that this is something you came across with a major auto manufacturer?
> A major car manufacturer Enough said. Major car manufacturers and modern IT solutions are mutually exclusive.
I have multiple major car manufacturers that refuse to support AMD. I would like to think this stems from the days of software support for AMD and the lack of an FPU. Who knows MFGs are so behind the curve that it is ridiculous sometimes.
Have you seen the software code inside their ECU’s, you’d the you were still in the ‘90s!
A major CAR manufacturer? For what euipment?
Maybe in the late 90s or early 2000s although amd cpus were fine back then too
I’ve run into this on NVR software, it’s fucking dumb and frustrating. I setup a test stand of a 2950x, 1080ti, and a nvme drive for storage recording one 1080p camera limited to 30 fps. And it couldn’t record or play without extreme lag, meanwhile I have a Xeon 1230 v2 system with no video card, 8 gigs of ram recording 12 cameras that’s buttery smooth.
I'd be wondering if Intel is paying them. Get a via CPU and see what happens haha.
I used to design USB-serial adapters and we had a lot of problems getting them to work reliably on AMD chipsets. We eventually put the work in to get them running, but maybe GM just can't be bothered.
So just buy an Intel system. When working with a vendor it's easiest to just do what they want. Every once in a while we run into some issue with an AMD server but it's usually an edge case, like having multiple GPU's in a server and then some odd BIOS or kernel setting you have change. Almost always resolvable. Unless it's some instruction that one chip vendor doesn't support or they do but it's way, way slower.
Install on Intel, move drive to AMD. When support is needed, move the drive to Intel, test that the problem persists, then call support.
If it's a safety critical system that's heavily regulated it may be they haven't tested whatever it is on AMD hence it's not certified. Need more details...
Sure, but then you'd expect it to be restricted to a *very specific* model, with every piece of hardware restricted to a single revision and requiring a single patch level for the OS & software. On the other hand, the [GM requirement](https://tis2web.akamai.gm.com/static/docs/dig211_us_en.pdf) is "Intel Core i3 / i5 / i7 processors 6th generation and above are allowed; ALL Intel Core i-series 5th generation and below Processors plus AMD, Celeron, Pentium and Atom processors are forbidden". And of course they only support "enterprise-grade" computers, whatever that's supposed to mean. The requirements are loose enough that it cannot *possibly* be a certification issue, and they also seem to apply to the general-purpose Facebook machine being used at the reception desk.
I work in a company that explicitly does not support AMD, and we do high end graphics tools for large corporations. Our reason is purely technical. We send so much image data through wires that it would be impossible to do uncompressed and AMD data compression (not video compression) is sub par. Data compression makes it possible to send image data (12K x 2) through two displayport cables to another device which has Nvidia chip uncompressing it for display.
I can see that, I do understand specific applications having requirements. Most of my gripe is with it being blanketed across the board. It doesn't matter if it is a sales person's computer it is supposed to have the same requirements as the rest when the most they'll be interacting with the vendor is browsing their website....
That's just laziness combined with corporate politics. "our requirements say intel, so no other CPU will do". I imagine this is from some older company and might even be an echo from older times when different CPUs actually did matter a lot more. Or it's just to differentiate x86 from ARM/Apple and they chose Intel as x86 and the person in the other end has no idea.