Hacker News new | past | comments | ask | show | jobs | submit login

Could somebody explain in very simple terms how I might get my M1 Mac Pro to dual boot between MacOS & Linux? Is there a guide or HowTo? Or am I a few months early re mainstream Linux rollout.



Run "curl https://alx.sh | sh" , ???, profit.

This will download and execute the Asahi Linux installer. If you want to check the source ahead of time, it's on the Asahi Linux GitHub.

While functionality improves rapidly every day, it is still decently rough around the edges. However, the installer is very streamlined and it's easy to get set up and try it out.


Just pointing out anyone can purchase a domain and redirect it to the official website while also serving a malicious script.


1. Someone asks how to do something

2. Someone tells him

3. Third person chimes in “you know, it’s technically possible that they’re lying!” despite no evidence of that being the case.

Tough crowd…

(Btw, you can easily verify that the alx.sh installation method is recommended by official sources, for example here: https://asahilinux.org/2022/03/asahi-linux-alpha-release/)


In this case however the official site provides the same guidance. Still, don’t pipe scripts to shells. At least read the script first.


Sure, but I didn’t know that from reading the comment


Right. I don’t trust the comment but I do trust the official site.


>Still, don’t pipe scripts to shells

Why not? Without looking, I assume that the script is downloading a binary and running it. What could it be doing that is more dangerous than that?


It can be doing anything your shell is privileged to do. You’re effectively giving password-less ssh to the Internet.


I think the point that sebzim4500 was making is that the script is downloading an arbitrary binary and running it and that this isn't any less dangerous than running an arbitrary script, so you're screwer either way.

If someone wanted to do `rm -rf /` on your system, they wouldn't put it in the setup script you're piping to sh: they'd put it into the binary, making your inspection of the setup script effectively useless.


If an installation script is downloading an arbitrary binary then I’m not running that script unless that binary also comes from a trusted source. We have PKI to prove that sites are who they claim to be. I only run binaries from trusted sources.


But then if you trust that source and its binaries, why would you inspect their scripts? What extra protection does that give you? None, imo.


How is that different from downloading a binary from the internet and running it?


Knowledge and trust of the source.


For the record, I think this is a totally reasonable comment, and I don't see why it's being downvoted. Often, the same people who spread FUD about shell script installers will download a binary from GitHub releases, npm, etc. without a second thought.

There are a few things that make shell script installers particularly dangerous, though. I don't think any are meaningful with the way people normally use computers, but they could be meaningful in the future if we improve our collective security posture:

* Shell script installers aren't digitally signed. Most OSes have pretty weak code signature schemes anyway. They're littered with root-of-trust issues that prevent a lot of OSS from being signed to begin with, and in turn, the vast majority of users (especially power users) ignore code signing warnings. But, as these problems are addressed, shell scripts will become weaker and weaker in comparison to binary packages.

* Shell script based sites can fingerprint the client and serve different content to a browser and to the "curl" command, confusing users who attempt to audit what's going to run before it's passed into the shell script command. This is a fine argument and a real problem with the "pipe to sh" approach. However, unless the user is also independently checksumming or disassembling every binary application they download, it's also a bit of a straw man.


> Often, the same people who spread FUD about shell script installers will download a binary from GitHub releases, npm, etc. without a second thought.

Nice straw man. Completely unfalsifiable. I didn’t bother reading the rest.


You can detect whether a script is being piped to shell or just downloaded, and serve different content. At least pipe it to a file, then execute that file.


There aren't many things more dangerous than that.


You’re a bit early but it’s fairly easy. I just did it on my M2 MacBook Air. It’s basically a bash script you run, answer a few question, pick a size for the new partition and it shuts down your computer. You then hold the power button while it starts up, you then pick the Asahi partition and follow a few more steps to finish the installation.


How easy/hard is it to set up a 3 part scheme where your personal files live on their own partition that can be accessed from macOS or Linux?


You don't want to do that. MacOS support for any modern filesystem (i.e. not crappy exFAT) that is not its blessed proprietary format, is likely to be bad or non-existent - at which point you have to install some shaky extension from a third party... The chances for anything to go Very Wrong are high. It's even worse than with Windows.

The best way to share files with a proprietary system is to go through some sort of network, i.e. NAS, smb, etc.


That's just bad advice. You can mount HFS+ from Linux just fine.


It's APFS by default for the last few versions of macOS, though, right?


Yes, but HFS+ is fully supported read/write for a mount.


Correct, it is APFS since 10.12 or 10.13 (so, 6 or 7 macOS versions/years).


This is completely wrong. ZFS works very well via O3X [0]. I ran my home folder off of ZFS on various Mac Pros for ~11 years. ZFS works well in Linux and FreeBSD as well.

----

0: https://openzfsonosx.org/


It should be fairly easy. Just pick a filesystem that both macOS and Linux can read/write to and format a partition accordingly (the Asahi installer won't make this third partition for you, but it should be pretty easy to figure out).

If I was going to go that route, on my MacBook which is 1TB, I would probably do something like 200GB for macOS, 200GB for Linux and then a shared partition of the rest (~600GB). I'd probably make the shared partition ExFAT, or possibly un-journaled HSF+.

I think the easiest way would be to install Asahi first, pick the size you want for it (200GB in my example), then once you have that sorted, figure out how to create another partition that you will format as ExFAT/HSF+/Whatever you want. I'm sure this is possible/easiest from the macOS side of things, although I have never partitioned a drive in macOS. The Asahi installer does it from the command line in macOS, so I'm sure Disk Utility has the ability to resize and create partitions, too.


The Asahi Linux installer sets everything up and you end up with dual boot. Check this post: https://asahilinux.org/2022/03/asahi-linux-alpha-release/


My experience with dual boot 25 years ago is that it is so inconvenient to reboot that you literally end up using only one OS, the one you prefer the most.

Just forget about dual booting nobody really does that.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: