Qualcomm just released a server chip, broaching a new market for them. And that chip
is a serious pain in the ass for Intel. Why would they want to be bought by Avago, which itself divested of Broadcom’s Arm server effort earlier (which recently launched as well anyway!)
Incidentally, still the only Cortex-A72 design out there. And for what you get, the A8040 and A7040-based solutions have a ridiculous low max power consumption of like 30-20 Watts.
Also, calling is easy. https://www.phoenicselectronics.com will sell you a Gigabyte MT30-GS2 (Cavium ThunderX 32-core) 1U system for around $2k. If you want to provide your own ATX case - much less.
Hardware is accessible, but there are a lot of big players buying things en masse, and the market isn’t oversaturated. This means long lead times and some price fluctuations. But things have been getting much better with every year (out of Arm servers’s whole 3 years of public availability). Definitely more accessible than anything OpenPower (which sadly will set you back the price of a small used Kia). The recent launch of third-gen Arm servers like the Qualcomm Centriq will lower the price for older kit.
RISC-V may do that tomorrow, but Arm servers are doing that today. You how a wide range of solutions with different CPUs in a variety of formats and compute power, from uCPE and IOT gw boxes all the way to high-density OCP designs with terabytes of RAM and a hundred cores...all compatible at the software and firmware level.
Actually, the Arm server space is solving this problem through standardization. These are the SBSA and SBBR specs. All systems from different vendors will look the same way to the OS and boot thr same way as x86 servers. You will be able to run the same binary OS distribution on any system. Gone are the days of a BSP for every SoC. And these server specs will drive how non-server systems will look, since there will be an inherent cost to do something different (both in hw, sw and firmware).
I thought Itanic was just a really smart diversionary tactic to kill off HP-PA (HP), MIPS (SGI) and Alpha (DEC/Compaq) development. It worked, and it didn't matter that Itanic was itself on borrowed time.
The later is further proof that if you sell to dinosaurs, you won't survive the Big One (in this case, x86 growing up courtesy of AMD and Arm spending 15 years washing the footing underneath both by moving personal computing to mobile devices). This should be a big warning sign to the OpenPower guys. You need to start small and scale/price up, not the other way around.
Intel also utterly failed in the mobile space, IoT things and are setting themselves up for failure in edge computing. What's one more thing to fail at?
In many ways UEFI on x86 resulted in a loss of firmware talent across the board since all OEMs were basically doing is selling Intel reference platforms, with Intel's UEFI drivers for everything on top of a "proprietary" firmware that amounts to Intel's reference (edk2) and maybe some buggy useless customization on top (mouse-driven configuration interfaces and other nonsense).
99% of all UEFI implementations are derived from EDK2/UDK. "official" firmware from companies like Aptio build on top of this code.
Truth is, motherboard vendors don't have the skill set to deliver firmware. You are doing what amounts to new driver development, integration testing for drivers you get from silicon vendors (who are not really software guys either), and chasing weird bugs. When you toss in third-party drivers (eg for BMC), SMM/TZ, safe boot and update...you really need to have someone to own the entire firmware lifecycle. And this is regardless of the kind of firmware - uboot, uefi, coreboot or bios, it doesn't matter.
Of course I make it sound like companies like Award and AMI ship great solutions. No one does, but OEM and silicon vendor-shipped firmware is much, much worse in quality.
Oh, and UEFI and the reference inplementation Tiano Core (edk2) are exactly Intel's own firmware, no more no less. It now has more of a life of its own ever since it became UEFI (from EFI), and even supports ARM platforms, but a) majority of development is still intel b) edk2 would like to be platform agnostic, but the design of some components (of edk2, not uefi spec) like PCI support is very PC-centric and this will be painful until someone rewrites these and contributes back to Tiano.
Yep, this talks about EDK1-based development. These days, you can also build Tiano Core EDK2 on Unix-like systems with GCC, and target Arm and AArch64. Like the EDK, there is still an Nt32 simulation target. Unlike EDK, EDK2 has real buildable firmware for Qemu, KVM and XEN and a simulation envo for Linux and OSX.
Probably should avoid developing under the old EDK, as the libraries and build system jave somewhat changed (yes, there is a compat package for mastodonts, but, just don't).
Like everything that's nice in theory, in practice rebasing is the only way to keep your sanity. It may be used in a quilt-like manner to apply your own changes to a foreign code base. For example, this is useful to develop features before they are ready for upstreaming. With rebase, you are applying your own changes on top of changed code, not the other way around, a much simpler and better scoped (in terms of time) activity, especially when the underlying codebase undergoes radical changes of its own. And whrn you're done and ready for upstreaming - you have a current set of simple changes against upstream, that are easy to review one by one, not a weird mixture of bits due to merges.
Yes, along with the 2nd and now 3rd generation of ARM server solutions from the known players...there's just no excuse
for nVidia to make the TX1/TX2 software system so closed and non-compliant.
When are these things going to become SBBR compliant? I am not even going as far as asking for an XHCI controller that doesn't require a blob to act as an XHCI controller (although this could well be hidden by firmware), but adopting at least UEFI (even without ACPI!) would be a really great start.
your commits don't have to be perfect, but maintaining good commit hygiene (no multiple change contexts in one commit) will work wonders... giving up on source control means having no means to roll back changes to a known good point in case you realize its a bad approach or in case of a mysterious bug you can't chase down... I don't regret having moved on from the daily 'make tar' days.
I wish Supermicro had a similar chassis around the Cavium ThunderX. That would make a lot of sense for network-attached storage, regardless of whether one goes with SATA or drops in a SAS adapter or two. Does anyone know if any of the Cavium accelerators (crypto or compression) can improve ZFS perf?
The border agents themselves were friendly enough to put up with my cranky self and the screaming kid after a 10 hour flight. The rest of that airport is a complete disaster, compared to places like Schiphol. This especially concerns the rest of the menially-paid staff that are supposed to help you through the airport.
Confused. On a planetary scale, it would result in a net loss of diversity. Let's take it to the extreme and claim the Japanese completely die out as an ethnic group. Why would the diversity increase?
Cap'n Obvious here, but immigration by non-Japanese in face of falling Japanese demographics will ultimately result in a country that's not really Japan anymore. That's probably a fact of life, if you consider societies to be living entities, and thus bound by the same constraints...and yet even as a non-Japanese it feels really sad to recognize that Japan as a unique nation, with a unique culture and society might disappear. Not much to do, though, if they don't want to have kids...
Did you tackle dynamic linking? How did you abstract the syscall interface (i.e. how did you choose syscall numbers...take the x64 ones or the new "standard" ones shared by all modern ports?)
Good old days. I remember trying to shoehorn Slackware onto an IBM PS/2 m55 with 2.9mb RAM. Unluckily for me, it was an MCA system with an ESDI disk, with the MCA support very experimental, and I ended using a parport ZIP100 to help with a minimal install. One day I got back from school and some dude from one of the Usenet groups called me on my land line asking for the steps.
Scaling down is hard. Look at OpenPower. They are feeling the heat from Xeons and know they need to scale and price down, and yet the scale-out Power9 SKU won't be out for what, another year? And how long until actual OCP gear ships, which probably will still cost like a decent Hyundai sedan?
Intel had nothing to offer to compete with ARM in mobile space. Largely ignored ARMv8 servers when they were mostly specialized or micro. Now E5-competitive chips are entering the market
from multiple competitors, and even mobile SoCs have grown up into laptop chips...
Yeah, honestly at the time of the Danger purchase, Danger wasn't that dangerous. It was mostly a
manufacurer of really dweeby phones, sorry, hip-tops, that seemed more like a nod to the men's waist packs of the 90s.
It is completely relevant. Basically, you can now replace aging Windows PCs with VDI hosted on ARM clouds, and people won't know or be able to tell a difference. You will now have x86 Win32 apps, arm64 Win32 apps, and UWP running on what's just another SKU of Win10. And since every piece of software for Windows must support 32-bit x86, there is full backwards comaptibilty. You won't need to wait for some mission-critical bit of software to be ported, and in the Windows world, there is plenty of mission-critical abandonware, trust me. Now it gets the AOT/JIT treatment. Microsoft just made enterprise a reality for ARM64 servers by crossing the proverbial rubicon. Suddenly, if you use Windows and Microsoft products, you can still buy into ARM data centers and clouds.