Neither Dell nor HPE manufactures switches (the former never has, the latter hasn't for the past few years). So, these are all sourced from an OEM like Edgecore.
And, someone at that OEM ordered a bunch of misspelled stickers. Easy mistake to make, if the latin alphabet is literally foreign to you.
And if you think that sticker is bad? Wait until you see the actual firmware, oh boy... (I had some fun Edgecore LACP bugs take down an pretty sizable network. Things got slightly better once they moved to Linux-based firmware, but never to the point that their kit was, like, entirely reliable...)
Well, for many stickers, they have to be ordered from original vendor / AMI. I guess this is not the case here.
Turns out it is coming from AMI, but AMI Taiwan.
>AMI Taiwan needed to get license stickers for the local market. Instead of using the “American Megatrends” MegaRAC PM sticker template, it decided to make its own that had the misspelling.
edgecore is just a marketing name, the actual company is accton
they're generally a competitor of companies like compal, clevo, quanta. All well known in Taiwan if you're in the business of having 3rd parties manufacture your stuff.
some 15-20 years ago most of the big taiwanese electronics manufacturing companies (top tier x86-64 motherboard makers would be a good example) moved a lot of their factory operations to mainland china, for lower cost labor.
I frequently work with Taiwanese manufacturers in the industrial PC space. Depending on what the client needs, I can specify whether the equipment is made in China (Suzhou) or Taiwan. Having the equipment made in Taiwan costs at least 10 to 15% more.
I think so, but assuming that is the case... what's to stop a shady chipmaker from printing properly-spelled "American Megatrends" stickers? More generally... are there any actual protections offered by genuine stickers?
The article makes this out to be a major supply chain security issue, and that only makes sense if branding stickers are actually reliable for validation purposes. But that seems... nonsensical? Wouldn't stickers be very easy to forge?
But, I don't work in supply chains. Anyone with better expertise in this area able to chime in?
I will admit I skimmed the article, because it is long and overly-detailed for my level of interest, and because it lacks summary sections.
It's not at all that a properly spelled sticker gives assurance that it's not counterfeit... it's just that a misspelled sticker is such an obvious sign of a potential counterfeit that it's basically the #1 thing that any counterfeit/suspect items program teaches people to look for. Most people working on counterfeits don't speak English so it's very easy for these kinds of mistakes to slip through, and on the other hand they're rarely made by the genuine manufacturer which usually has a process to check for this kind of thing even if the engineering work is done in a non-English speaking country (most of all that the logos usually come from off-the-shelf art files from the marketing department, so no one's even typing the name to make a mistake).
Almost any corporate or institutional counterfeit or supply chain security program will explicitly teach you: if anything is misspelled or shows other obvious mistakes, hold the part as a suspected counterfeit. It's a pretty good quality indication.
So of course manufacturers do genuinely make spelling mistakes sometimes, but this context makes it a pretty embarrassing and serious thing to do. It's like your bank misspelling their name in an account notification: sure, in some extremely theoretical sense it doesn't mean anything, but in practice they're giving you exactly the signal that everyone tells you to check for to identify phishing, and it raises questions about their processes that they let it slip through.
1: Access to the data center requires either an access card plus biometric verification (fingerprint in one DC in my case, retina scan in the other), or an ID-verified appointment. Then, you still need to know where my server is, plus the access code for the rack (or, you need to be an average lockpicker, but beware, there's cameras...).
2: Each data center has dual-provider AC feeds, plus generators, and provides A/B feeds to my rack. I've not had a dual-feed outage in the last 20 years or so.
3: No cloud provider that I'm aware of guarantees server security or does automated patching (for servers, not services). So, keeping your server up-to-date seems equally important for both cloud and non-cloud scenarios?
4: At least two weeks, I guess? I have sufficient VM host capacity to accommodate 30% unplanned growth, but 100% would require new hardware. So: ordering two servers, installing these in two data centers. But if the new project also requires significant bandwidth, getting new Internet connections in might take longer.
Look, I'm definitely not denying that "the cloud" makes it easier to scale fast, but scaling fast is not an overriding concern for most businesses. Cost is, and self-hosting, even with a pretty redundant infrastructure, is still much cheaper than AWS.
Yeah, right. As if I'm ever going to allow anything Java-related on anything I manage again.
"This application requires JRE #" -- end-user Googles JRE # and downloads/installs it.
End-user organization gets sued by Oracle lawyers for 10K site licenses for JRE #. Sure, they COULD have downloaded OpenFerretMongrelAsphalt JRE Pi, but yet, here we are...
Yep. It’s safest to classify using Oracle software as a business risk. After a due diligence evaluation it may be an acceptable risk, but you darned well better research it before assuming everything will be fine.
Isn't the recommended way of distributing Java applications nowadays to bundle a custom JRE with it? Wasn't project jigsaw especially created to be able to just bundle libraries and/or classes the application requires instead of the whole JRE?
Yes. The official stance of the OpenJDK organization is that there is no such thing as a "JRE" anymore, and applications are expected to use jlink or similar to bundle a customized Java runtime.
The distributions that matter here are for the JDK, which simply provides the "full" Java runtime along with developer tools such as javac and jlink.
Yup, you go and explain that to, say. Ubiquiti. Their network management software still requires end-users to download JRE v8 (and noothing else: it won't work). And, once end-users do that, they get sued by Oracle. But, serves them right, right?
VirtualBox is GPL2, but the 'extension pack' is under a personal use and evaluation license that doesn't cover commercial use. You're supposed to buy an Enterprise license for that.
The extension pack covers "Support for USB 2.0 and USB 3.0 devices, VirtualBox RDP, disk encryption, NVMe and PXE boot for Intel cards." according to the website.
My understanding of those (thus maybe wrong) is, that they are built on too of third party licensed code and patents. Thus opensourcing is hard and would require reimplementation. Thus choice is this model or nothing. One could also create those modules as open source versions, but there doesn't seem to be enough interest by independent folks ...
I don't care too much about it, but I wonder whether the open sourcing of it and the Enterprise license for commercial use requirement are really orthogonal.
Nothing is forcing Oracle to "routinely check log files for downloads of the VirtualBox Extension Pack from nonresidential IP addresses and contact unlicensed users to enforce compliance" (per https://en.wikipedia.org/wiki/VirtualBox#VirtualBox_Extensio...). They could easily just say "this software is free for commercial and non-commercial use."
It went from Java to OpenJDK, to Eclipse Temurin (formerly OpenJDK from Eclipse Adoptium) or something. If that doesn't seem like a big mess to use I don't know what to tell you
If you follow Java & ecosystem at least a bit you needed to read one or two blog posts from reputable community members to figure out what the situation is and what to use.
To compare I find a licensing situation on mid-size (50+ direct dependencies) or larger project much harder to comprehend - you need to figure out what licenses are used, if they can be used at all due to the requirements and company's policy, if they are compatible with each other and what's required for distribution.
It is confusing from the outside though, trying to decide if you should use Java from your distro, from Oracle, Azul, Amazon Corretto, AdoptOpenJDK, Eclipse Temurin, or Red Hat OpenJDK. Which ones have might have builds for your various platforms, what support they might offer, how closely they track OpenJDK, etc.
One good example is what is meant by "LTS". You get different answers to that question depending on which JDK it is.[1]
I don't remember another language where it was ever this confusing.
The JVM isn't a language. Kotlin, Scala, Clojure, and Java are languages. I'm quite pleased there are an abundance of options when picking a runtime. Yes, Oracle has not been a good steward, so having numerous open and free alternatives is a positive thing.
Oracle bas been and continue to be a good steward. Who finished the open-sourcing of OpenJDK to the point where it is feature-equivalent to their OracleJDK? Who pays for 98%+ of developers actually working on OpenJDK, on which other companies build their tiny modifications to create a “new” runtime? Who finances GraalVM and other top-notch research?
You can hate oracle all you want for some of their other segments, but they are insanely good at managing the Java ecosystem and we should be thankful for that.
This is a very valid counter-argument and perhaps I've been influenced by Oracle's general reputation, as well as not fully understanding who is responsible for the various open-source builds. I agree that the JVM is a fantastic platform and if it's Oracle putting in most of the work and the funding then I take my statement back.
That's true, but a little pedantic. If you look at it from the lens of "I've picked a language (java), now I need to build and run/deploy things", it's a confusing ecosystem. There's good arguments for why things are the way they are. But there's not really a good argument that it's straightforward and simple.
You are not making a coherent argument. Once you have decided you're building your server app in Java, it is MORE difficult to evaluate and decide Ubuntu, Debian, Red Hat, CentOS, etc. than it is to pick a runtime. Whether it has been like that "from day one" to use your term, is irrelevant. Secondly, having choice is GOOD. Yes it adds a bit of confusion but I'd rather have options than not. If you want some overriding authority to make all the decisions for you, go build on iOS.
Lol, you just can't leave this alone. Choosing a JVM is about 99% less confusing than the last 20 years of .NET Framework/Core/Mono mess and all its sub-projects (ASP.NET, Silverlight, WinFX, etc). At least in Java if you target v.11 you know to install JDK 11 (or higher). Meanwhile if you write C# v8 you need .NET Framework 4.8 to run it. Or maybe .NET Core 3 - which is now called .NET 5. Then over in Python land you've got IronPython, Jython, Pypy, plus the need to keep v2 as "python" on most Linux'es and "python3" for running/building new stuff. Don't forget virtual environments so you can pip install one version of a certain package while keeping it separate from a different installed version of that same package elsewhere. Java is super simple by comparison.
Just simply issue pkg-manager install openjdk and that’s it. Most vendors are just repackages of upstream, and you more than likely don’t need n years of support.
Most other languages don't offer long term support.
You can't run an old version of Python and continue to get security and performance backported fixes. Same thing with GO or Ruby or Swift.
I can't remember what Microsoft does for .Net, but I suspect you also need to always be on the newest CLR to get updates.
I think this is one of the major differences with the JVM, in a way, it has more options and vendors which should be a good thing, but it seems to mostly confuse people.
No, they're not. It's a silly idea with a pretty specific target audience. Most shops don't have time to waste on keeping their customers' JVM up to date by re-releasing their applications with new JVMs.
This feature is mostly useful when you want to ship a particularly stripped down version of the JVM for footprint reasons.
Oracle has proven themselves to be a litigious organization. You're not wrong that there are probably safe ways to interact with their organization's products but why bother when there are alternatives from companies that don't have such dirty legal histories?
And, someone at that OEM ordered a bunch of misspelled stickers. Easy mistake to make, if the latin alphabet is literally foreign to you.
And if you think that sticker is bad? Wait until you see the actual firmware, oh boy... (I had some fun Edgecore LACP bugs take down an pretty sizable network. Things got slightly better once they moved to Linux-based firmware, but never to the point that their kit was, like, entirely reliable...)