21–30 of 60 posts
> I have christened it “flandre”3, which I think is fitting. Youmu Konpaku is best character. Just gotta love the sword-characters in a bullet-game. Although Flandre was an "extra" endgame boss character, never actually playable IIRC. Really good music for her stage though. ---------- Glad to hear everything is working out for your machine. One thing I'm curious about: > Installation was a breeze, it compiles the ker…
I really like these machines. Unfortunately, I'm in Europe, where they seem to be harder (or riskier) to get hold of. I suppose I should also try to think of something reasonable to do with them, given their cost...
Earlier quoted context omitted.
Not a dumb question. https://sourcehut.org should tell you what you need to know. If you have any specific questions, I can answer them.
Hello! I went through that website before posting. That's why I thought it was a Gitlab-like service. I like that it works without JavaScript, and it appears to have a wiki-like integration too. It looks like a neat service.
> However, I refuse to give any company credit for waking up their support team only when a scathing article about them frontpages on Hacker News. I told them I wouldn’t publish a positive follow-up unless they also convinced me that the support experience had been fixed for the typical user as well. You are a gem and I wish more people were like you.
(I think this applies both to hardware and software products.)
Of course, this is easier said than done, but ultimately this is the core function - are your customers happy or not?
As a CTO you need to prepare the company and your investors for this failure mode. You need to be able to explain to them that sometimes making sure that the product actually works and the existing customers are happy is more important than that sexy new feature of the month. It's not always a very easy balance.
In my experience, even semi-technical people with a more sales/marketing kind of focus in the company often get blindsided by this. It's on us to prep them for this.
It seems like this company learned it the hard way. The key thing is that they did learn.
Earlier quoted context omitted.
2m3.673s; default config with loadable modules disabled; make -m 32. This is on a second-last generation 24C/48T Xeon (albeit a slower one) with all of the known speculative execution vulnerabilities mitigated except spec_store_bypass, and SMT still enabled (because htop is prettier with more pretend CPUs).
What's the I/O situation? I did my build from an HDD, WD Blue. Also, kernel config matters a lot - I used yesterday's master branch from Linus, with Alpine Linux 3.10's ppc64le config, plus olddefconfig to catch it up.
> I am quite impressed with it so far. Installation was a breeze, it compiles the kernel on 32 cores from spinning rust in 4m15s Does anyone know how this compares to a recent x86 machine? This seems quite fast for the entire kernel, but I have no idea what typical build times are like.
2m3.673s; default config with loadable modules disabled; make -m 32. This is on a second-last generation 24C/48T Xeon (albeit a slower one) with all of the known speculative execution vulnerabilities mitigated except spec_store_bypass, and SMT still enabled (because htop is prettier with more pretend CPUs).
real 1m55.267s
Run from tmpfs, all protections from Spectre etc. on. Not too bad, really!
> I am quite impressed with it so far. Installation was a breeze, it compiles the kernel on 32 cores from spinning rust in 4m15s Does anyone know how this compares to a recent x86 machine? This seems quite fast for the entire kernel, but I have no idea what typical build times are like.
> I am quite impressed with it so far. Installation was a breeze, it compiles the kernel on 32 cores from spinning rust in 4m15s Does anyone know how this compares to a recent x86 machine? This seems quite fast for the entire kernel, but I have no idea what typical build times are like.
The trick is far fewer modules and compile time options. A fun benchmark would be a Power9 Vs a X86_64 cross compiling the same ARM64 kernel. I wouldn't bet heavily on the Power9...
Slightly OT, but if you limit the playing field to open ISA / fully owner controlled systems, POWER9 is so far out front in terms of performance that it looks like an outlier. ;)
Earlier quoted context omitted.
The trick is far fewer modules and compile time options. A fun benchmark would be a Power9 Vs a X86_64 cross compiling the same ARM64 kernel. I wouldn't bet heavily on the Power9...
I might take that bet core for core, matched node size (i.e. 14nm), run out of tmpfs or NVMe storage, and with both systems protected against Spectre, Meltdown etc. (i.e. no cheating by ignoring the ISA specifications)... Slightly OT, but if you limit the playing field to open ISA / fully owner controlled systems, POWER9 is so far out front in terms of performance that it looks like an outlier. ;)
Earlier quoted context omitted.
I might take that bet core for core, matched node size (i.e. 14nm), run out of tmpfs or NVMe storage, and with both systems protected against Spectre, Meltdown etc. (i.e. no cheating by ignoring the ISA specifications)... Slightly OT, but if you limit the playing field to open ISA / fully owner controlled systems, POWER9 is so far out front in terms of performance that it looks like an outlier. ;)
A race of one is easily won :)
However, yes, by far most of the remaining owner controlled systems are even smaller -- some of the smaller (older) ARM Chromebooks (sans GPU, of course), the BeagleBone black, those kinds of systems.