Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

ARM64 Linux Workstation

jasoneckert.github.io

Post reply on HN
Print view View original

401–410 of 493 posts

Re: ARM64 Linux Workstation

#401

Post by mgkimsal »

torgoguys wrote: post #362
notpushkin wrote: post #353

Earlier quoted context omitted.

I like the idea behind trackpoint, but I just can't get used to it. Any tips?

Force yourself to use it exclusively for a while, no cheating. For better (it's great) AND worse (you have fewer options for laptops), there's no going back after that. I love it and even use Trackpoint with my desktop computer.

I used a couple variations for about 2 years - Thinkpads with a red trackpoint thingy. never liked them. Continually felt unnatural and clunky. Mac trackpad was a game changer for me.

Glad you found something that works for you.

Re: ARM64 Linux Workstation

#402

Post by vinceguidry »

jlokier wrote: post #198
apatheticonion wrote: post #152

I cannot wait for Linux to be fully usable on my Apple Silicon MBP. That is going to be such a killer environment to develop on. Crazy fast hardware, great high refresh screen, insane battery life, fantastic touchpad, gestures and keyboard. There is the potential that Windows games could run on it with some combination of x86 translation and Proton. Using MacOS on it feels like I have a ferrari with square wheels. Wa…

On my x86 MBP, I run GNU/Linux in VMWare Fusion, full screen. That gives me a combination of both worlds, which I can easily switch between with 4-finger swipe. I did battery life tests running the same Linux distro natively vs in a VM on MacOS. What I found surprised me: battery life was better with the VM than native, so I stayed with the VM. When a VM is used, driver issues are effectively absent as Apple drivers…

I also run Linux in VWWare Fusion and it's mostly great. But mics just don't pass through well. I have to switch to OSX to run Teams at all, and also to Slack if I need to huddle.

Re: ARM64 Linux Workstation

#403

Post by jodrellblank »

wkat4242 wrote: post #210
noloblo wrote: post #207

Earlier quoted context omitted.

also No need to use flash usb drive just enter in terminal curl https://alx.sh | sh to install asahi linux Dual boot on m1 or m2 MacBook apple silicon

Great idea piping a website straight into a shell.

Installing gigabytes of Linux and applications from people you have no contract with, who have no obligation towards you, is a good idea but running a script to install it, that’s too far?

Re: ARM64 Linux Workstation

#404

Post by bogwog »

c_o_n_v_e_x wrote: post #268
bogwog wrote: post #84

Earlier quoted context omitted.

Nope, that's the cost of a monopoly. However fast or special Apple's RAM is, it doesn't cost them 10x the price of the competition, it costs us that because we can't around shop for another supplier.

To be fair, what you're getting is a hardware configuration that "just works." By controlling the hardware configuration, the manufacturer is controlling the user experience. Yes, components like storage and memory are built to standards but interoperability problems do come up. By controlling components/configs, they (Apple) doesn't have to field angry tech support calls and go down rabbit holes as to why a random R…

Have you ever bought a non-Apple computer? When hardware fails it’s not because the configuration “just dont work”, it’s because crappy OEMs ship garbage quality components that die, and when you buy one of those machines it’s really a race to see what fails first: an internal component or one of the poorly designed external components made of shitty plastic.

But that’s only for the cheap computers (a market Apple doesn’t serve). Most machines in the $800+ range offer excellent value and reliability (except Dell).

> By controlling components/configs, they (Apple) doesn't have to field angry tech support calls and go down rabbit holes as to why a random RAM manufacturer's DIMMs don't work with my machine.

I think you severely overestimate the number of people who install aftermarket parts into their computers. Furthermore, Apple offsetting the cost of tech support by overcharging customers for hardware is really shitty. Maybe if you’re a shareholder then that’s a positive statement, but this thread about pricing is obviously from a consumer perspective.

ALSO, it’s ignoring the fact that Apple’s answer to any tech support question is “buy a new one”. So whatever they’re doing with that extra money, it’s not going into tech support.

Why should I pay 10x RAM prices? Because nobody else can sell RAM for Apple’s latest computers, and nobody else can compete directly with those computers yet, and Apple is taking full advantage of that.

If a competitor starts offering comparable hardware, they’ll be able to significantly undercut Apple simply by offering RAM (and storage) at reasonable prices. Until then, Apple will be emptying wallets.

Re: ARM64 Linux Workstation

#405

Post by OmarAssadi »

apatheticonion wrote: post #328
AnthonyMouse wrote: post #273

Earlier quoted context omitted.

Benchmarketing. It has hardware support for video codecs so it can play video efficiently in particular even though people traditionally think of that as something processor intensive. The question is, what's the battery life when you're doing kernel compiles or GPGPU.

According to "Garry explains" on YouTube, the M1 MBP gets 3 hours of battery life looping kernel (I think) compilations until the laptop dies.

That feels about right to me too. I don't know if I'm usually just doing more computationally intensive stuff than most with my 16" M1 Pro, but I think the only way I could get anywhere near the advertised numbers is if I basically just had Safari open and the display on half brightness.

And not to beat the already long dead horse any more, but toss in some electron apps running in the background, I probably average somewhere around ~7 hours or so. I'm not convinced the 10+ hour lifetime is possible if you've got stuff like Discord/Slack/VS Code open.

But in terms of when I am doing truly evil things to it, I am surprised it lasts as long as it does, be it max CPU compiling or all of this morning when I was toying around with stable diffusion, it gets around ~4 hours or so.

Re: ARM64 Linux Workstation

#406

Post by jasoneckert »

moondev wrote: post #195
rkunde wrote: 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.

Same here, OP can you share the limits you added? Or is it on namespace level

No problem. In the end, I had to actually set CPU limits on the pod level for traefik, svclb-traefik, metrics-server, coredns, and the local-path-provisioner.

I initially chose a limit of "500m" for all of them except coredns (which seemed to be fine), but there were still some occasional issues with the metrics-server and traefik, so I increased those to "750m" and that solved those issues, but it caused coredns to CrashLoopBackOff. After setting a "500m" limit on coredns, everything ran smoothly.

So, essentially, I set a "500m" on all of the pods in the kube-system namespace except for traefik and metrics-server (they got "750m"), and of course I didn't need to set limits on the helm-install-* pods.

I didn't modify the default memory limits at all.

Re: ARM64 Linux Workstation

#407

Post by NegativeK »

zahllos wrote: post #341
dijit wrote: post #326

Earlier quoted context omitted.

Not sure, but anecdotally I have a machine running linux that was $6,000 and definitely feels slower than my M2 macbook air. Mostly its a question of latency I would imagine. My machine: Archlinux “Zen” (lower latency kernel). Threadripper 3970x 256G DDR4 2666MHz 3x4TiB NVMe (PCIe Gen3) in RAID0 Radeon VII GFX card (more than enough for 2D render of terminals).

I attended a talk by a PhD student who specializes in CPU/architectural research, on the M1 as an architecture. There are some key differences in design, such as unified memory etc, but what accounts for a large part of the performance gap with x86 is the fact Apple's compilers can target their specific microarchitecture and optimize for that, because they know its performance characteristics well. We know the perfor…

I've a friend in the industrial and academic chip development space.

They basically agreed with what you said. ARM isn't some magical compute/watt wand that Apple waved; it's their incredibly tight software and hardware integration that allowed them optimize.

Re: ARM64 Linux Workstation

#408

Post by _448 »

apatheticonion wrote: post #152

I cannot wait for Linux to be fully usable on my Apple Silicon MBP. That is going to be such a killer environment to develop on. Crazy fast hardware, great high refresh screen, insane battery life, fantastic touchpad, gestures and keyboard. There is the potential that Windows games could run on it with some combination of x86 translation and Proton. Using MacOS on it feels like I have a ferrari with square wheels. Wa…

> insane battery life

Is it just hardware that helps extend battery life or is it the combination of hardware and software? One advantage for Apple is that they are both the hardware and software designer hence they can optimise both to take advantage of each other.

Re: ARM64 Linux Workstation

#409

Post by OmarAssadi »

ar_lan wrote: post #179
apatheticonion wrote: post #152

I cannot wait for Linux to be fully usable on my Apple Silicon MBP. That is going to be such a killer environment to develop on. Crazy fast hardware, great high refresh screen, insane battery life, fantastic touchpad, gestures and keyboard. There is the potential that Windows games could run on it with some combination of x86 translation and Proton. Using MacOS on it feels like I have a ferrari with square wheels. Wa…

I would consider myself quite the power user and use both macOS and Linux daily… I don’t really understand, from the developer perspective, your concerns about macOS? While I prefer the feel of Linux, macOS is more than sufficient for almost any development I do (which also involves a lot of container/VM development and I’ve never felt this was slow).

For me, it's less of a macOS inherent issue and more so that many, many things just assume Linux by default. Anything you find on GitHub that relies on some sort of native module is really hit or miss in terms of "will this just work, or will I need to go waste a couple of hours or resort to a VM?"

For example, I've run into a couple of occasions where I've needed to build some third-party thing that happens to also need something like QEMU, but the build scripts only run on Linux. Annoying, but whatever, setup a Linux VM/"container" and good to go, right? ... except there is no nested virtualization support on the M1 macs.

Outside of those sort of issues and other ARM-specific problems, while it doesn't usually impact my workflow too much, I wish I had more control over the system. I wish, for example, it could boot off of something other than APFS, etc. I don't want to have to deal with Time Machine when I've already got snapshots everywhere else, etc.

Everything is relatively minor, but there is always some new thing that makes me annoyed every week or two.

Re: ARM64 Linux Workstation

#410

Post by coldtea »

AnthonyMouse wrote: post #284
coldtea wrote: post #208

Earlier quoted context omitted.

Because it's a random third party filesystem adaptor module. Why would it be "included by default"?

Most of the Unix utilities that are included were written by third parties. They're "included by default" because they're useful and take up a negligible amount of space.

They're included by default because they are standard UNIX userland.

FUSE is nowhere near that.

Post reply on HN