Live data from Hacker News

ARM64 Linux Workstation

jasoneckert.github.io

161–170 of 493 posts

Re: ARM64 Linux Workstation

#161
post #142

> In some cases, it is too fast. When I installed K3s, all of the containers in the kube-system namespace kept entering the dreaded CrashLoopBackOff state [..] After some investigation, I found out that the Mac Studio was just too fast for the Kubernetes resource timing I’d like to understand what the issue here is. Sounds counterintuitive to me.

I read that as "the container ran so fast that the orchestration assumed it was failing".

Re: ARM64 Linux Workstation

#162
post #101

Earlier quoted context omitted.

OP is using a Mac Studio, which is not a laptop. I don’t think you can take their claim of it 100% working on their hardware and apply it to a completely different machine. In addition, it’s open source software. Not some corporate organization selling you a product. Nothing is guaranteed.

> OP is using a Mac Studio, which is not a laptop. You're telling me that the Mac Studio has no "power management" or "sleep" functionality at all? Not even in macOS? Nor does it have a 'GPU' for GPU acceleration either. We both know that it isn't exclusive to laptops. Everyone knows Touch ID doesn't work, both the seperate keyboard and on Apple Silicon laptops (and Intel Macs) and you know it. > I don’t think you ca…

I don’t need to admit anything. You can read into anything as disingenuously as you like, and go rant off into corners; but you’d get equally far yelling at a wall.

OP claimed that all of the hardware they tested (with an enumerated list of said hardware) worked as they expected. For you to take that as some guarantee that you should then have a perfect experience on a completely different (or even the exact same) piece of hardware is your issue. It’s an opinion/experience editorial, not a professional expert/authority on the subject.

Re: ARM64 Linux Workstation

#164

> Is there anything that doesn’t work? > To quote Hamlet, Act 3, Scene 3, Line 87: “No.” > Everything works… and works perfectly. That is impressive and really hard to believe! I guess I'll have to find an M1 mac Mini to try myself!

I've got an M2 Air. It is very usable, but its far from everything working perfectly. Builtin speaker support is still a work in progress. It works if you know what you are doing and are not afraid to damage your speakers if you make a mistake. There's been progress on this though, so I expect this to be resolved sooner than later. There's no builtin speakers in the author's mac studio though, so I'll give them a pas…

> There's no builtin speakers in the author's mac studio though, so I'll give them a pass for this one.

Don't all Macs come with a built-in speaker? I.e. the one that plays the start-up chime, and plays "system sounds" like emptying the trash.

On Mac notebooks and AIOs, this is one-and-the-same as the obvious external speaker array used as the default output device; but on desktop Macs (like the Mac Mini — don't know about the Mac Studio), it's a separate little speaker hidden somewhere inside the chassis. (It's like the old concept of a "PC speaker", but this one is hooked up to a DAC and routable as a regular audio device, rather than only being able to play tones from a PIT.)

Re: ARM64 Linux Workstation

#165

Earlier quoted context omitted.

The web version of spotify doesn't work on my m2 air in either chromium or firefox. The Spotify website errors with: "Playback of protected content is not enabled." Slack works just fine from the browser on Asahi though.

You're likely missing the Widevine DRM plugin. IIRC, many distros don't include it, or don't enable it by default.

Where is the publicly available linux/aarch64 build of widevine drm?

The fetch-latest-widevine.sh[0] script says 'Architecture not supported'.

[0]: https://github.com/proprietary/chromium-widevine/blob/master...

Re: ARM64 Linux Workstation

#167

I wasn't planning to switch to ARM anytime soon, but I was looking for a new Linux distro with Ubuntu heading off in it's own 'Canonical' way. Debian seemed to be a natural default but I'm leaning toward an Arch distro so would prepare me if I should switch to ARM down the road.

Pop!OS is worth looking at if you like Ubuntu but don't like where Ubuntu is going. Plain debian is fine though - unless you have a recent laptop and need nvidia drivers. You can make it work, but it's fiddly and the Pop! guys already figured everything out for you. I use debian on an old HP deskside server as a workstation and it's been fantastic.

This was my I first thought before Debian because I've noticed Debian packages don't always work like the Ubuntu repo ones and the latter is used by the large majority and I don't mean desktop things but rather server things. The concern is how much infulence will Canonical have on the repo contents itself. If distros have to override Ubuntu repo packages what's the point? I could wait and see if things go that way or choose different. I like voting with my feet.

Re: ARM64 Linux Workstation

#168

Only thing that would make this better is if the containers were running under Rosetta instead of QEMU. I'm hoping this is possible at some point on macOS.

Docker for Desktop supports this, as well co(lima) apparently. There is also new tool orbstack on the way https://orbstack.dev/

Re: ARM64 Linux Workstation

#169

Are these ARM64 Mac using ECC? P.S: the 3440x1440 screenshot in TFA looks gorgeous on my system. Everything is using subpixel AA (terminals, code editor, browser, except for the URL, for whatever reason) but not the file manager. I wonder why that is.

Current ARM Macs don't have ECC, just like how the Intel iMac/Macbook don't have it. Likely the ARM Mac Pro will have it.
Post reply on HN