HN user

mattst88

517 karma

https://mattst88.com/

Netflix. ex-Google. ex-Intel. Gentoo Developer.

Posts6
Comments120
View on HN

I think they're super uncommon in the west.

I think they're also super useless, to be honest. Incredibly slow. Linux support continued to degrade the entire time I owned mine. The keyboard and display are far too small to be usable. The graphics chip accelerates basically nothing.

I sold mine [1] on eBay back in October. I hope the new owner enjoys it more than I did :)

[1] https://mattst88.com/computers/yeeloong/

I've loaded the PROM in Ghidra. The ability to decompile to C is great.

I looked at some particular parts of the PROM that took a while to understand to see if I could have understood them quicker with Ghidra. In particular, the part of `sloader` that searches for the `post1` and `firmware` sections and then calls `post1(&firmware)`. Given that I already understand how this works, I can see that this is happening from the decompiled C, but the lack of labels, comments, etc really hampers my ability to understand from the decompiled C alone.

This might all be down to inexperience with the tool.

The ability to iteratively add a label, rerun the decompiler, reread the decompiled assembly, make more inferences was really the key to building an understanding for me.

Another aspect I'm unsure how to handle in Ghidra is that the base address differs between sections of the firmware. E.g. the `firmware` section is copied to RAM and executed from `0x81000000`. It's not clear to me how to configure this in a granular way, rather than a single base address for the whole PROM image.

Burnout is your brain giving up because it doesn’t think the benefit is worth the effort anymore. If you don’t have a purpose for what you are doing all your brain will do is obsess over the negatives. Every job in the world has massive negatives. You have to find a positive purpose for what you are doing to balance the negative.

This is spot on and was exactly my experience at my last job.

The one thing I'll add is that for me it wasn't about not having a purpose, it was about not feeling appreciated for all of the time/effort/energy I'd poured into that purpose.

I am a happy owner of a Tigerlake (Intel 11th Gen) Framework laptop. I've considered upgrading to a 12th or 13th Gen motherboard, and while I have no doubt they'd be great for me as a Gentoo developer with the greatly increased core counts, my hesitation is that the new CPUs have AVX-512 disabled.

Maybe this doesn't matter, almost certainly wouldn't for most people, but I'm compiling the whole system myself so the compiler at least has the freedom to use AVX-512 wherever it pleases. Does anyone know if AVX-512 actually makes a difference in workloads that aren't specifically tuned for it?

My guess is that given news like https://www.phoronix.com/news/GCC-AVX-512-Fully-Masked-Vecto... that compilers basically don't do anything interesting with AVX-512 without hand-written code.

I don't have enough details to debug, but something I discovered just the other day might be helpful if you're building the kernel. For kernel builds, you have to specify CC= after `make`, not before. E.g. `make -jX CC="distcc alpha-unknown-linux-gnu-gcc"`.

Signs a couple of different things: most notably they're signals from the catcher to the pitcher suggesting a pitch for him to throw, but also there can be signs from the dugout to a batter telling him to bunt, or to a runner on base telling him to steal, etc. If the other team is able to decipher any of these, they'll have a significant advantage.

To be clear: stealing signs isn't cheating. It's using electronics to steal signs that's cheating.

For example, a base runner on second can see the catcher's signs to the pitcher and relay them to the batter so he knows what the pitch is. This is not cheating.

In 2017, the Astros used electronics to steal signs. They had an employee somewhere beyond the outfield wall with a camera who watched the catcher and relayed his signs electronically to someone in the Astro's clubhouse (behind the dugout) who then banged on a trash can loud enough for the batter to hear. That was cheating. See https://www.youtube.com/watch?v=FUkJeko0QGE

To prevent that sort of thing from happening in the future, MLB last year allowed pitchers and catchers to switch to an electronic system for relaying signs (the catcher has some buttons/keys and the pitcher has an earpiece).

Reportedly it's not just the CEO...

- No merit salary increases or promotions - No more quarterly bonuses - No more employee recognition programs (e.g. no more $25 gift card for working at Intel for 5 years) - 401k match drops from 5% to 2.5%

and probably worst of all, 5% salary reduction for grades 7-11.

But at least they didn't cut the dividend! What a horrible nightmare that would have been...

Glad I'm no longer working for Intel.

Ouch. Very sorry for those affected. I worked at Intel for >8 years, and I still have a lot of friends there.

I have little faith in Intel's management. They apparently plan to continue increasing their dividend payouts, while cutting back on investment in fabs according to https://semianalysis.substack.com/p/intel-cuts-fab-buildout-...

... and in the context of the recently-passed CHIPS Act...

I wish they'd be more of an engineering-driven bottom-up company. IMO there's a huge company culture to contend with that is primarily top-down. So much scar tissue in the company prevents changing things for the better. So many good people capable of making these sorts of changes get burned out and leave the company. Intel's compensation compared to FAANG certainly helps to push people out of the company.

Intel iAPX 432 4 years ago

bcantrill linked to it separately in the comments: http://dtrace.org/blogs/bmc/2008/07/18/revisiting-the-intel-...

The particular parts I was recalling are:

The upshot of these decisions is that you have more code (because you have no immediates) accessing more memory (because you have no registers) that is dog-slow (because you have no data cache) that itself is not cached (because you have no instruction cache). Yee haw!

Awesome.

Intel iAPX 432 4 years ago

I remember reading an article about the iAPX 432 that went into extensive detail about the compounding effects of the design—I recall it describing how an operation with an small constant operand would be slow because the ISA didn't support immediates, and as a result you'd have to load it from memory, and there was not even a cache to help with that.

Does anyone know this article? I've searched and haven't been able to find it, and it was definitely worth a read.