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

271–280 of 493 posts

Re: ARM64 Linux Workstation

#271

Post by astrange »

josephcsible wrote: post #95
Gigachad wrote: post #28

Earlier quoted context omitted.

Screen brightness works on the beta kernel. Speakers work but are disabled by default because there is a risk it could blow up the hardware

> Speakers work but are disabled by default because there is a risk it could blow up the hardware Wait, what? This sounds like a pretty egregious design flaw on Apple's part.

Speakers are just things that move when you send electricity to them. It's not hard to blow up something like that if you try, especially if they heat up over time.

Re: ARM64 Linux Workstation

#272

Post by jorvi »

somethoughts wrote: post #214
mardifoufs wrote: post #173

Earlier quoted context omitted.

I'm wondering if an M1 MacBook would actually have such a good battery life on linux. The processor is very power efficient, but I'd (naively) assume that MacOS's power management probably has a big influence too. In the same way that Linux laptops usually have a bad battery life compared to the same hardware on Windows. How good is Asahi when running similar workloads? And is it possible that it could reach parity w…

I think the key difference (hopefully) will be that there are a limited number of hardware configurations for Mac. Still a lot (i.e. 100+ SKUs) but not nearly the number of x86 hardware configurations (i.e 10000+) Also presumably if Apple wants this to happen, they as a single vendor can provide a single definitive answer on what they are doing for each configuration. Eventually... In the x86 world, there is Intel, A…

It’s been a while since I’be owned a MacBook, but the speakers sounded significantly worse on Linux (and if you own a MacBook you know they can sound pretty decent) because they are EQ’d in macOS, not the speaker firmware.

Never has there been any effort taken within Linux to apply a generalstic ‘small speaker EQ’ to anything with detected internal speakers.

Similarly, the Linux kernel by default is optimized for server style workloads (throughput) instead of smoothness. It would be so easy to check for an internal battery and if true apply a few kernel parameters so your laptop stays smooth under load.

Linux as a desktop (well, laptop) OS is terrible not because it is incapable of being great at it, but because people don’t seem to care for the death-by-a-thousand-cuts issues.

Re: ARM64 Linux Workstation

#273

Post by AnthonyMouse »

mardifoufs wrote: post #253
ILMostro7 wrote: post #246

Earlier quoted context omitted.

18 hours battery life is mostly marketing. Not even sure how to test that, maybe on 20% display brightness with no programs running, other than the OS...assuming it doesn't take screenlock/display off into account?

I remember reviews on youtube that showed the macbook air/pro M1 playing video (streaming?) for that long. Actually, it kept going for 20h. https://youtu.be/KE-hrWTgDjk?t=645

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.

Re: ARM64 Linux Workstation

#274

Post by abudabi123 »

spwhitton wrote: post #143
jlarocco wrote: post #125

It's cool that Arm64 chips are catching up in speed, but the software support has been there for a long time. When I bought my Raspberry Pi several years back, I was able to comfortably develop using Emacs, gcc, and SBCL Common Lisp - the same software I use on my AMD desktop. Everything I needed "just worked"; compiling just wasn't very fast.

Ha, Emacs, sbcl and gcc are exactly what I've been using for development for the past few months on my Raspberry Pi 4 desktop replacement.

If you have two raspi, 4GB and 8Gb models, you can use tmux, btop to check your memory and cpu levels.

Re: ARM64 Linux Workstation

#275

Post by jnsaff2 »

jorvi wrote: post #272
somethoughts wrote: post #214

Earlier quoted context omitted.

I think the key difference (hopefully) will be that there are a limited number of hardware configurations for Mac. Still a lot (i.e. 100+ SKUs) but not nearly the number of x86 hardware configurations (i.e 10000+) Also presumably if Apple wants this to happen, they as a single vendor can provide a single definitive answer on what they are doing for each configuration. Eventually... In the x86 world, there is Intel, A…

It’s been a while since I’be owned a MacBook, but the speakers sounded significantly worse on Linux (and if you own a MacBook you know they can sound pretty decent) because they are EQ’d in macOS, not the speaker firmware. Never has there been any effort taken within Linux to apply a generalstic ‘small speaker EQ’ to anything with detected internal speakers. Similarly, the Linux kernel by default is optimized for ser…

There was even an article[0] about the sound of macbook speakers quite recently.

[0] https://news.ycombinator.com/item?id=34935483

Re: ARM64 Linux Workstation

#276

Post by kerneis »

jorvi wrote: post #272
somethoughts wrote: post #214

Earlier quoted context omitted.

I think the key difference (hopefully) will be that there are a limited number of hardware configurations for Mac. Still a lot (i.e. 100+ SKUs) but not nearly the number of x86 hardware configurations (i.e 10000+) Also presumably if Apple wants this to happen, they as a single vendor can provide a single definitive answer on what they are doing for each configuration. Eventually... In the x86 world, there is Intel, A…

It’s been a while since I’be owned a MacBook, but the speakers sounded significantly worse on Linux (and if you own a MacBook you know they can sound pretty decent) because they are EQ’d in macOS, not the speaker firmware. Never has there been any effort taken within Linux to apply a generalstic ‘small speaker EQ’ to anything with detected internal speakers. Similarly, the Linux kernel by default is optimized for ser…

The asahi project is working on improving speaker support: https://social.treehouse.systems/@marcan/109914949041457536 https://social.treehouse.systems/@marcan/109917995005981968

Re: ARM64 Linux Workstation

#277

Post by AnthonyMouse »

somethoughts wrote: post #214
mardifoufs wrote: post #173

Earlier quoted context omitted.

I'm wondering if an M1 MacBook would actually have such a good battery life on linux. The processor is very power efficient, but I'd (naively) assume that MacOS's power management probably has a big influence too. In the same way that Linux laptops usually have a bad battery life compared to the same hardware on Windows. How good is Asahi when running similar workloads? And is it possible that it could reach parity w…

I think the key difference (hopefully) will be that there are a limited number of hardware configurations for Mac. Still a lot (i.e. 100+ SKUs) but not nearly the number of x86 hardware configurations (i.e 10000+) Also presumably if Apple wants this to happen, they as a single vendor can provide a single definitive answer on what they are doing for each configuration. Eventually... In the x86 world, there is Intel, A…

The permutations don't really matter. If one machine has Broadcom wireless and Intel graphics and another has Qualcomm wireless and AMD graphics and they're both supported and then you come across one that has Broadcom wireless and AMD graphics, you already have the drivers for it.

The real trouble is that you get some wireless chip which isn't popular enough for anybody to reverse engineer it but the manufacturer didn't provide any documentation, so the driver for it sucks or doesn't exist.

There is plenty of well-supported hardware so the solution is, don't buy the bad one. But some poor sucker who already did and now they want to run Linux on it may have a bad time.

Re: ARM64 Linux Workstation

#279

Post by matheusmoreira »

wkat4242 wrote: post #218

> Asahi is a Linux distribution that can run natively on Apple Silicon-based Macs due to some slick reverse engineering provided by members of the open source community. Moreover, running Asahi is perfectly legal because Apple formally allows booting non-macOS operating systems on their Apple Silicon platform. Umm how would it ever be not legal? Even if Apple doesn't formally allow it, you're free too so with your ow…

The DMCA made it illegal to circumvent software locks.

Re: ARM64 Linux Workstation

#280

Post by chaxor »

jeswin wrote: post #235
coldtea wrote: post #206

Earlier quoted context omitted.

> I'm wondering if an M1 MacBook would actually have such a good battery life on linux. Not 100% the same, but the Asahi members reported something like 8 hours on a M1 Macbook, so that's better than most/all x86 laptops with Linux

> 8 hours on a M1 Macbook, so that's better than most/all x86 laptops with Linux It is makes no sense to compare an $1k/$2k M1 Macbook with random laptops. Those laptops exist because people want to run MS Word or Excel for $400. That's the feature. Various System76 laptops, Thinkpads (among many other laptops recommended by Linux users) give you battery life comparable to macOS on the M1.

System76 systems absolutely do not have good battery life. The systems the make tailored only to battery life try to be comparable in battery (~14h system76 to ~25h on m2 pro) but obviously x86 vs arm makes this attempt exceedingly difficult. You're going to remove a massive amount of computational power from an x86 system to improve it's battery life like that. However, of course if you're interested in increasing a laptop battery life, it helps to have control over the system if you have the time to put forth on optimizing it. I would imagine an asahi linux (archlinuxARM) system could be made to last much longer than macOS. However, this would require 1) not running any wm, or perhaps a simple one like awesomewm, 2)drastically reducing screen brightness, 3) removing any processes that run in the background continually (you could take this rabbit hole far - perhaps even to NTP requests and such), etc. MacOS doesn't have as much configurability like this, so it's variance in battery life is much less - probably a range of 10h-37h if you really push it. Linux could probably take that to 20min-8days if you tried.
Post reply on HN