[HN Gopher] Coming Soon: Fedora for Apple Silicon Macs
___________________________________________________________________
Coming Soon: Fedora for Apple Silicon Macs
Author : TangerineDream
Score : 177 points
Date : 2023-08-02 16:40 UTC (6 hours ago)
(HTM) web link (fedoramagazine.org)
(TXT) w3m dump (fedoramagazine.org)
| WaffleIronMaker wrote:
| This is so exciting! The Asahi team has done some really
| impressive work. I can't wait for it to start to make its way
| into mainstream distributions.
| AdmiralAsshat wrote:
| Battery life would be the big thing, I think. There's not a
| single person I know who wouldn't like having Linux on their
| M1/M2 Macbooks--they're beautiful devices--but if you're not
| getting something approaching MacOS's battery life, then there's
| not that much separating it from another similarly-specced
| ultrabook.
| maccard wrote:
| I'm perfectly content not having Linux on my M1 MacBook.
|
| That said, I don't want that to stop someone else from having
| it!
| SxC97 wrote:
| >There's not a single person I know who wouldn't like having
| Linux on their M1/M2 Macbooks
|
| Well... OP probably doesn't know you... /s
| AdmiralAsshat wrote:
| I should probably have clarified, there's not a single person
| I know _who uses Linux as their daily driver_ that wouldn 't
| want the option of having it run on an M1 MacBook. I'll grant
| that the vast majority of _Apple_ users probably don 't care
| about running Linux on it.
| starfallg wrote:
| Yeah, all I want for Christmas is just Linux on hardware
| with good battery life.
| dangus wrote:
| Even if Linux kills 50% of battery life compared to macOS
| you're still looking at a system that's in the top tier of
| longevity compared to x86 Ultrabooks.
| aaomidi wrote:
| Why would battery life be impacted?
|
| The main reason for bad battery life is hardware acceleration
| for certain tasks. Once that's settled, the computer shouldn't
| start producing more heat out of the blue.
| jtietema wrote:
| Because the linux drivers might not support all the power
| saving states for all the hardware in the device.
|
| For example: I bought a Dell XPS 9 months ago. With the
| earlier Fedora 37 kernels, it didn't put the Nvidia card into
| power saving mode, causing battery life to be less than an
| hour. Now it seems to work correctly and battery life is 3-4
| hours for me.
| dev_tty01 wrote:
| >The main reason for bad battery life is hardware
| acceleration for certain tasks.
|
| I guess this was a typo. MacOS/Apple Silicon (and other CPU
| architectures) save a lot of power via hardware acceleration.
| For instance, there are dedicated hardware video decoding
| blocks that use much less power than implementing video
| decoding with software.
|
| The MacOS kernel takes advantage of all of these hardware
| specifics. MacOS also uses a number of other techniques like
| process wakeup coalescing, dedicated hardware for memory
| compression, process specific efficiency/performance core
| choices, ...
|
| Apple is getting a lot of power improvements via codesign of
| the processor and the OS.
|
| To do the same set of tasks with a similar power profile,
| Asahi will have to include system hooks that take advantage
| of all the dedicated lower power hardware functions and do a
| similar set of optimizations. They have done great work so
| far and will likely continue, but it isn't the simple
| tradeoff you are suggesting.
| callalex wrote:
| Hardware acceleration is not some binary state these days,
| there are a ton of specialized bits of hardware under the
| Apple M chip umbrella.
| CharlesW wrote:
| Additionally, Apple's always1 been insanely great at power
| management even pre-Apple Silicon by virtue of (1)
| prioritizing it more highly than other vendors, and (2)
| implementing it in a way that takes advantage of the
| complete hardware and software stack.
|
| 1 https://blog.codinghorror.com/why-does-windows-have-
| terrible...
| brundolf wrote:
| From anecdotes I've heard, battery life on Asahi Linux is
| already great
| input_sh wrote:
| Annecdotaly, it'll last you through an entire work day, but
| probably not into double digits.
| pleb_nz wrote:
| My m1 pro has never has into double digits. 6 to 8 hours is
| all I get. So if be happy if it stays that with Linux.
| malermeister wrote:
| I'd love to see some benchmarks! I have an M1 device and
| don't really love macOS, but the battery life is just sooo
| good.
|
| I'd be super happy if I could just run Arch on this thing
| instead.
| a1o wrote:
| I imagine a repurposed MacMini M1 will also be like raspberry
| pi on steroids.
| NovaDudely wrote:
| I doubt there would ever be parity but it could be good enough.
|
| Have to hand it Apple OS team, they know how to squeeze a lot
| out of there hardware.
|
| A while back I was trying to get an old G5 running and looking
| at the various OS options, many said just go with MacOS 10.4 -
| it was the most optimized OS for the system even today. When
| software and hardware work together, it can be pretty cool.
| xp84 wrote:
| I mean, for a kind of museum piece, to get the true
| experience of using the computer I'd agree for sure just use
| original OS. But if one wanted to be able to use it for most
| functional purposes, it's sad how the complete lack of
| backcompat in MacOS makes using an old MacOS tough -- which
| is sad because new Linux often can work surprisingly fine on
| the same hardware. Like, current Debian on a 2008 Core 2 Duo
| is a fine computer that you can browse the Web and do basic
| office tasks on. It was shocking to me!
| IntelMiner wrote:
| As a Quad G5 owner, might I recommend OS X "Sorbet" It's an
| unofficial merging of OS X 10.5 with PowerPC builds of 10.6
| components. Even on ancient G3's it out-performs both 10.4
| _and_ 10.5 in benchmarks
| hollandheese wrote:
| Wait... how'd you get it working on G3 machines? As far as
| I know, 10.4 was the last release for G3s.
| psanford wrote:
| I've been running Asahi for a full year on my m2 air. The
| battery life is quite good. Yes, I think macOS has batter
| battery optimizations than linux, but compared to other laptops
| running linux it really is quite good.
| beebeepka wrote:
| Talk with numbers. My cheap 6800H 14 inch laptop can do 12
| hours.
| kccqzy wrote:
| They achieved 23 hours. https://social.treehouse.systems/@A
| sahiLinux/110548137464042...
| paddim8 wrote:
| It's good, but not amazing. With these laptops, you expect
| amazing.
| psanford wrote:
| Its better than any Dell or HP laptop that I've owned.
| fredski42 wrote:
| Would something like KVM work?
| wmf wrote:
| Yes, KVM works (but only to run ARM VMs).
| Octabrain wrote:
| After the painful experience I've had with the last ThinkPad I
| purchased (and before that, a Dell XPS, if Linux reaches a point
| where widely used distros are able to run on Mac M*
| flawlessly...personally I'm not gonna think it twice.
| based_gigachad2 wrote:
| I wonder when we'll have fully functional HDR and neural engine
| so that the creative professionals could try using Linux on their
| Apple silicon Macs (software support is another story, though
| Davinci Resolve is already there)
| dmvdoug wrote:
| This is awesome news. I have been trying to tinker with getting
| Ubuntu working on both an older Intel Mac and my M1, but it's an
| almighty pain in the ass hardware-wise. And I ran across more
| than one person who felt it necessary to point out that me buying
| an Apple computer was what the problem was. Like, really? That's
| a real effective way to win people over.
| defer wrote:
| Well, it's understandable. If you talk about it with other
| linux-on-MacBook tinkerers I'm sure they'll be more sensible to
| your cause.
|
| But generally, if you pointed that out to me I'd say the same,
| picking that hardware puts you in a harder path. Also, I'm not
| sure if Linux users in general have any interest in winning
| people over.
| dmvdoug wrote:
| I'm not talking about Linux users in general. I'm talking
| about the subset who hang around forums and other online
| spaces and purport to help newbies with problems.
|
| Ironically enough, then, I figured out on my own that the
| biggest obstacle I was encountering with my Intel MPB was
| Ubuntu's distribution of firmware, where they officially
| pretend not to know about certain non-free device drivers,
| even though they vaguely gesture at the process of acquiring
| them in their respective official docs. Whereas Debian
| straight-up distributes them in their ISOs.
|
| Can't say I'm a big fan of Ubuntu's wink-wink, nudge-nudge
| approach to "standing up for free software," where they get
| you started down a path then steadfastly refuse to help
| because VIRTUE! Debian's approach is saner. And so I'll be
| tinkering with Debian, I guess.
| alphanullmeric wrote:
| I used to hate on Macs until I was given one by my employer. Then
| I realized that despite how awful macOS is, the laptop itself is
| completely unrivalled. There is no
| Lenovo/xps/framework/tuxbook/tongfang/clevo/whatever that comes
| close to the overall package of a MacBook. It has the stiffest
| body, the quietest fans, the biggest battery, the best screen and
| trackpad, etc. Even worse is the fact that a framework 16 is more
| than an M2 pro with an education discount. And now, the biggest
| flaw of a MacBook (macos) is fixed.
| totallywrong wrote:
| Still rocking a 2015 MBP with Fedora here. Screen, body,
| keyboard, and trackpad are so good. This news make me consider
| buying Apple silicon, which I'd never do if I had to use MacOS.
| unethical_ban wrote:
| Does the trackpad function mac-like? Is it still overall
| better than a Lenovo, for example, or does the software bring
| it down?
| totallywrong wrote:
| It's better than a Lenovo (I've used many) because the
| trackpad itself is better, the software doesn't have an
| impact. It's just the usual synaptics driver so you could
| configure it the way you like.
| mdasen wrote:
| Part of it is that Apple has the margins that they can spend a
| little more on parts. They know they don't have to compete on
| price as much as PCs do. People aren't going to ditch the Mac
| over $25 or $50. However, people do regularly compare prices on
| PC laptops looking to save small amounts of money. That means
| that Apple can spend a little more designing and ordering a fan
| that's quieter with a better design and more premium parts.
|
| Also, because there are so many PC laptops, it's really hard to
| get a good review of a PC laptop. There are so many
| configurations and PC makers often make small (but meaningful)
| changes to designs during a product's lifecycle. All of a
| sudden, the one you bought has a less bright display or the
| cooling system isn't as good or whatever. It makes it hard to
| reward companies for creating good products. There are premium
| PC laptops, but they still suffer from some of these decisions
| and they often cost about the same.
|
| I've looked for alternatives to the Mac, but at this point I've
| stopped. I'm sick of doing research on junk to try and save a
| few bucks, I'm sick of trackpads that are unusable, and with
| the new M-series processors I simply never want to go back to a
| high-wattage processor.
|
| I actually like macOS, but I'm really glad happy to see Linux
| advancing on Apple hardware. The Asahi Linux developers are
| amazing and I love reading their write-ups.
| lotsofpulp wrote:
| >Part of it is that Apple has the margins that they can spend
| a little more on parts.
|
| This part is duplicated by the business or professional
| branded products of Dell/HP/Lenovo/etc.
|
| I think the part that cannot be duplicated (without very
| significant time and money) is the tight integration between
| software and hardware. Even if the other companies spend a
| little more for the premium components, they are not able to
| squeeze out the same performance.
| andrekandre wrote:
| > how awful macOS is
|
| just curious, but what parts are awful? customization? or just
| generally bugs?
| AbacusAvenger wrote:
| Personally I have two major issues with macOS: CPU usage and
| bugs.
|
| There are a ton of background services that periodically spin
| up for no obvious reason, consuming a ton of CPU for a few
| minutes at a time, then go back to idle. I don't know what
| they're doing or why. Luckily since they're background
| services, they're bound to the efficiency cores on Apple
| Silicon, so they don't hurt battery life or thermals too much
| most of the time.
|
| And as far as bugs go, the worst part is that bug reports
| through the Feedback app go largely ignored and bugs seem to
| keep accumulating. Even for bugs with clear and well-
| documented repro cases, Apple doesn't seem to pay any
| attention.
|
| I'm a game developer, so the majority of my bug reports come
| from issues I've experienced with the graphics drivers or
| with Xcode. Here's a few examples:
|
| - On macOS devices with > 60Hz displays, there is some awful
| stuttering with Metal apps in full screen mode. For some
| reason, CAMetalLayer nextDrawable sometimes just takes a very
| long time whenever it uses direct-to-display mode for
| presentation. That mode is implicitly enabled for full screen
| Metal apps, in order to bypass the display compositor and
| theoretically reduce latency. This bug also applies to
| MacBooks with the built in "ProMotion" (120Hz) displays. I'd
| be perfectly happy if there was just some flag to say "don't
| use direct-to-display", but if there is one, it's not
| documented anywhere. I haven't found a workaround yet. I
| originally reported this in August 2022. Apple replied once
| in October 2022 to say "we can't reproduce this, please
| provide a demo app". I provided the app that reliably
| reproduces the problem within an hour of their reply, but
| they've been silent since.
|
| - Metal and OpenGL (the latter is emulated via Metal on Apple
| Silicon Macs) both exhibit a bug with triangle merging that
| causes partial derivatives to go very wrong along primitive
| edges. There's a usable workaround for this on the Metal side
| (just enable a [[sample_mask]] even if you're not doing
| multisampling). There's no such workaround for the OpenGL
| side, unfortunately. I was able to work with Asahi Lina to
| fix this for Mesa on Asahi Linux, and the fix itself was
| actually really trivial and didn't require a sample mask hack
| (it took a lot of debugging to figure out, though -- but
| that's how reverse engineering goes). To solve it, Apple
| would simply need to set a particular bit to disable triangle
| merging whenever the fragment shader uses derivatives. I
| reported this issue in December 2022, and Apple hasn't
| replied.
|
| - This one is not as egregious as some of the bugs I've
| reported, and the Xcode team has responded reliably in the
| past. This is the first Xcode bug report I've had where they
| didn't acknowledge the report within ~14 days or so. In the
| current Xcode beta, using the graphics debugger will suspend
| the app but hitting "resume" leaves the app stuck suspended.
| The normal application debugger path does not do this, just
| the graphics debugger. I reported this in mid-June 2023, but
| haven't heard anything yet.
| alphanullmeric wrote:
| The window management and workspaces are horrible compared to
| gnome. nothing you expect to work actually works. Basic
| things like putting more than 2 windows in the same workspace
| are impossible. The animations are also worse than gnome,
| which is very surprising considering how macOS is known for
| its animations.
| tristan957 wrote:
| No window snapping.
| aidos wrote:
| Is...that it? There are apps that let you do that. If you
| were feeling sadistic you could write some AppleScript to
| do it for you.
| red2awn wrote:
| Just use the Rectangle app, problem solved. It would be
| nice to have it built in, but it is not a big deal.
| throwawayai2 wrote:
| There are multiple apps for this. I've had window
| management on my macs for a decade+.
| binkHN wrote:
| > It has ... the quietest fans...
|
| Part of this is related to having one of the most power
| efficient CPUs.
| omgmajk wrote:
| Hell yeah, might finally buy a mac if I can run native linux on
| it. I like the hardware but am allergic to MacOS.
___________________________________________________________________
(page generated 2023-08-02 23:00 UTC)