<marcan>
I don't know what's going on, but clearly whatever *is* going on isn't healthy
<marcan>
anyway, you all know where our website and twitter account are, so I'm not particularly concerned about contingency plans here; let's wait and watch for a bit, it won't be excessively disruptive to move if we have to
m42uko has quit [Quit: Leaving.]
m42uko has joined #asahi-dev
<Eighth_Doctor>
hey marcan 🙂
<Eighth_Doctor>
I've been following the progress on the Asahi effort with great interest (I'm even an early patron 😉), and I want to say thank you to you and everyone working on the Asahi bringup work :)
<marcan>
thank you! :)
<Eighth_Doctor>
I saw that Linux 5.13 will include the patchset you submitted, and I believe Mesa 22 will include the GPU bits for GL acceleration
<Eighth_Doctor>
what's left for a Linux distribution to be able to bring up M1 mac support?
<marcan>
lots
<marcan>
5.13 only has basic CPU bring-up, no drivers
<marcan>
there is no GPU kernel driver either, nor even a design for its interface
<marcan>
I'm working on those right now :-)
<marcan>
going to start a stream in fact
<Eighth_Doctor>
ah
<Eighth_Doctor>
I'm interested because I'd personally like to integrate these bits and have Fedora be one of the first distributions to ship with fully complete Apple ARM Mac support, just as we were for x86 Macs years ago...
<marcan>
if you're interested in Fedora support and you really want to be in the bleeding edge, I would suggest bringing up and maintaining an RPM repo with our bleeding-edge package forks as they become available. That will get you support sooner than upstream (though hopefully not by much, since we want to keep the upstreaming pipeline going)
<Eighth_Doctor>
I don't really know where to start for integrating these bits into Fedora though, so hence the questions :)
<marcan>
right *now* though there isn't much to do other than perhaps investigate whatever infra that would require on your side
<Eighth_Doctor>
marcan: I'm okay with doing that, I currently lack ARM Mac hardware, but I can help in that way regardless as long as someone is willing to test if I haven't fucked it up :)
<marcan>
well you need to at least build for ARM, which probably would best be done natively on ARM machines, but it could be any ARM64 box
<Eighth_Doctor>
Fedora's infrastructure is capable of producing aarch64 RPMs natively in both official and community infrastructure
<Eighth_Doctor>
so that part is squared away :)
<marcan>
yeah, if you have access to aarch64 infra then that's no problem
<Eighth_Doctor>
there was one thing I had a question about with m1n1
<Eighth_Doctor>
it seems like it compiles in an image blob?
<marcan>
I'll be doing our equivalent for Arch Linux ARM (which is what asahi will be, just Arch with an extra repo and some installer glue)
<Eighth_Doctor>
is there a way to make that separate or something so that it's swappable?
<Eighth_Doctor>
if it's not, that's fine, I'll come up with something, but it'd be nice if it was runtime swappable
<marcan>
not really, because m1n1 doesn't have disk drivers so it can't load anything else
<Eighth_Doctor>
we try to make it easy in Fedora to trivially swap the branding
<marcan>
the thing is, you don't care about m1n1
<Eighth_Doctor>
I don't?
<Eighth_Doctor>
isn't it the bootloader?
<marcan>
yes and no :-)
<marcan>
it's the first stage
<Eighth_Doctor>
so like shim on x86 UEFI?
<marcan>
the second stage will be u-boot, and the third stage will be up to the distro but presumably many will use GRUB
<marcan>
u-boot provides the UEFI environment, and will be embedded into m1n1 as an in-line payload
<Eighth_Doctor>
yeah, we'll definitely be using grub, though I think some adventurous folks will try sd-boot :P
<Eighth_Doctor>
or refind
<Eighth_Doctor>
since Fedora's grub supports bls snippets, you can swap between sd-boot and grub easily
<marcan>
so our goal with our installer is that people who want to install Asahi can pick that, and people who want to use another distro can just install the m1n1+u-boot part and then boot a standard installer from that
<marcan>
so in that sense you could think of m1n1 as a distro-agnostic
<marcan>
*bootloader
<Eighth_Doctor>
I see
<marcan>
it's also worth noting that you cannot, and never will be able to, update m1n1 from Linux itself
<marcan>
so you can never ship it as a package
<marcan>
this is due to the machine's secureboot design
<Eighth_Doctor>
yikes
<marcan>
updating it requires physical attestation
<Eighth_Doctor>
that's... fun
<marcan>
which means booting into 1TR and entering user credentials
<Eighth_Doctor>
so you need macOS to do it, or something else?
<Eighth_Doctor>
oh lovely
<marcan>
you need recovery mode, which is macos, but should be considered part of machine firmware
<marcan>
so this is, in context, like UEFI firmware on a PC
<Eighth_Doctor>
I wonder if Apple would be willing to do a "blessing" for distros that are sufficiently functional to avoid that
<marcan>
no, you really need to think of it as device firmware
<marcan>
the *boot menu* is 1TR
<marcan>
the machines are not fully functional without 1TR
<marcan>
it's like having only the recovery portion of UEFI
<Eighth_Doctor>
well, yes, but you're telling me I can never make it "pop USB stick in and everything goes brrr"
<Eighth_Doctor>
which is kind of sucky :(
<marcan>
same way you can't "pop a USB stick in and everything goes brrr" on Intel Macs
<marcan>
you need to reduce boot security first at least
<Eighth_Doctor>
I didn't for mine?
<marcan>
older ones yes
* Eighth_Doctor
is confused
<marcan>
not the new ones
<Eighth_Doctor>
oh, mine is a 2014 Mac
<marcan>
and unlike PCs, Apple does not ship anything but windows keys
<Eighth_Doctor>
I guess something changed between then and now
<marcan>
but M1s are better; on M1s, m1n1 itself is basically "ad-hoc" signed for a given machine on install
<marcan>
which means *we* can still define a useful secureboot policy rooted there
<marcan>
and have real security
<marcan>
(or not, our choice of course)
<Eighth_Doctor>
so that means we probably want a helper program for macOS to walk someone through configuring for Fedora
<marcan>
it has to be 1TR, not macos
<marcan>
like, this isn't an OS thing
<Eighth_Doctor>
so Apple didn't blend macOS with 1TR?
<marcan>
this is *specifically* a *specific* recovery partition that is a core part of SFR (system firmware and recovery) and represents a trusted state and is triggered via physical button press
<marcan>
like, 1TR is based on macos but it's not normal macos
<marcan>
you can't install m1n1 from normal macos either, or even from a regular macos recovery instance
<Eighth_Doctor>
so then how does this work?
<marcan>
so you really need to think of it as some "UEFI firmware thing" except it's not UEFI and it happens to be based on a macos kernel/gui
<Eighth_Doctor>
yeah, but it's a UEFI-ish thing that is not configurable from the OS side, which is...?
<marcan>
well, for apple it kind of is because they have their own signatures and stuff, which is why they can update macos from macos, but sadly we can't do that
<marcan>
this is their compromise for third-party OSes
<Eighth_Doctor>
I see
<marcan>
they allow it, but they require physical attestation for installation and first-stage updates
<marcan>
I mean, it makes sense
<Eighth_Doctor>
and this is better than UEFI how?
<marcan>
the whole thing is really clever
<marcan>
they do security *per OS*
<marcan>
not *per machine*
<marcan>
you can have a fully Apple-signed, security-enforced macOS installed, which will play Netflix 4K and run iOS apps
<marcan>
and then Linux, in another partition
<marcan>
and one does not taint the other
<marcan>
no other machine does that to my knowledge
<Eighth_Doctor>
I know of a few, but they're not exactly normal systems
<marcan>
on Android once your unlock your bootloader, it's tainted
<Eighth_Doctor>
but it also means removing macOS is not an option
<marcan>
it is
<marcan>
removing *1TR* is not an option
<marcan>
but that's like removing UEFI on a PC is not an option
<marcan>
removing macOS is definitely an option
<Eighth_Doctor>
well, replacing UEFI firmwares on PCs is definitely a thing
<marcan>
not on machines with boot guard and such
<Eighth_Doctor>
replacing 1TR is most definitely not
<marcan>
nor on android, for the same reason
<marcan>
(only after aboot do they let us install stuff if unlocked)
<Emantor>
Can 1TR be updated by Apple via MacOS?
<marcan>
yes
<marcan>
and presumably by us, if we implement the required flow
<marcan>
that's because SFR (including 1TR) is signed
<marcan>
though I wouldn't want to open that can of worms, too much risk of bricking
<marcan>
I'm more interested in adding M1 support to idevicerestore
<marcan>
that's how you restore a "bricked" M1 that lost its 1TR/iSC or similar
<marcan>
currently that can only be done from another macOS machine
<marcan>
but it's just an extension of the existing stuff for iOS, which idevicerestore implements already
<marcan>
so adding the required stuff there should be all that's required to support recovering/resetting M1 macs from another Linux box
<marcan>
which installs 1TR
<Emantor>
Yeah, that would be nice.
<marcan>
(or updates it)
<marcan>
(a long time ago I wrote usbmuxd and worked on libimobiledevices and stuff which idevicerestore builds on...)
<Eighth_Doctor>
so what should I provide for asahi folks on Fedora?
<Eighth_Doctor>
or wanting to do asahi-ish stuff on Fedora?
<marcan>
I think most of the distro-side work, besides whatever you want to do to have bleeding-edge repos, is going to be about drivers
<marcan>
e.g. we have to deal with the Touch Bar
<marcan>
that's going to involve some kind of daemon presumably
<marcan>
there's stuff like thunderbolt, etc
<Eighth_Doctor>
hmm
<Emantor>
Regarding Distro-Installation, I'd point to Asahi Instructions to install m1n1 and have m1n1 implement something like bootloader specification.
<marcan>
I want to take care of the early boot stuff and just present distros with a UEFI boot environment, but all the downstream user experience stuff matters
<marcan>
Eighth_Doctor: also, do you know about the RHEL page size problem?
<Eighth_Doctor>
oh god, please don't remind me about the fact RHEL uses 64K pages for AArch64
<marcan>
and they also require ACPI, which will never ever be a thing here
<marcan>
so I hope you have devicetree kernels with 4K or 16K pages :)
<Eighth_Doctor>
Fedora is 4K instead of 64K
<marcan>
good
<Eighth_Doctor>
64K is a miserable failure outside of limited server workloads
<marcan>
(I'm mostly testing at 16K, curious what breaks at 4K, hope nothing major)
<Eighth_Doctor>
as far as I know, AWS is the only AArch64 server maker that actively recommends 64K page sizes
<marcan>
heh
<Eighth_Doctor>
their Graviton2 CPU is optimized for it
<marcan>
fwiw there are open questions around boot provisioning; right now the install flow does require a macos install to clobber at least, and part of this is blocked on Apple bugs (yes) and further investigation
<marcan>
but unless we hit a major blocker, my idea for our install flow is that we tell users "hold down the power button, go to "Options", open a terminal, and type curl alx.sh | sh"
<Eighth_Doctor>
they provide curl in 1TR?
<marcan>
yes
<Eighth_Doctor>
I'm kind of surprised
<marcan>
it even has perl
<Eighth_Doctor>
but no Python, right?
<marcan>
and as of a few releases ago you can run your own binaries (you used not to be able to due to codesigning)
<marcan>
no python
<marcan>
however they do still have entitlements, so we can't directly interface with boot policy stuff, which is a shame
<marcan>
so we depend on shelling out to Apple tools for that
<Eighth_Doctor>
hmm
<marcan>
which comes with some limitations due to said bugs
<Eighth_Doctor>
is the 1TR environment fully graphical?
<marcan>
yes
<Eighth_Doctor>
or just a graphical terminal?
<marcan>
you could run a graphical app if you wanted to
<marcan>
it has a web browser
<Eighth_Doctor>
oh god
<marcan>
and the graphical disk utility, though that thing is a buggy mess
<Eighth_Doctor>
well, that's been a buggy mess forever
<marcan>
you can also install macos from there
* Eighth_Doctor
stares unamused at Disk Utility
<marcan>
the commandline one is fine, thankfully
<marcan>
so right now we have a chicken and egg problem with credentials
<Eighth_Doctor>
I wonder if Fedora Media Writer could be adapted for 1TR
<marcan>
to downgrade security you need provisioned credentials, and to provision credentials you need to boot (signed) macOS, which means right now the install flow is "install macOS, then replace it with m1n1 and optionally shrink the APFS container and delete most of macOS"
<marcan>
we require some blobs from macOS to provision m1n1, but I have already proved that that works manually; but then I run into the creds issue
<marcan>
the thing that will fix this is when Apple fixes "importing" foreign external macOS installs
<marcan>
which right now is quite broken on these machines
<marcan>
because that means they will have to be able to import credentials from disk into the SEP
<marcan>
and at that point we can just create a macOS credential database and direct users to the Apple flow to make it work
<marcan>
buut right now that's all broken
<marcan>
I'm hoping Apple fixes it this year
<Eighth_Doctor>
do USB drives work in 1TR?
<marcan>
yes
<marcan>
oh, that's another thing;
<Eighth_Doctor>
so in theory, I could from macOS direct the creation of a USB media with a 1TR application for final setup?
<marcan>
"normal" installation of macOS requires phoning home, but it is not mandatory on M1
<marcan>
the installer will prompt you to go to reduced security if that doesn't work
<Eighth_Doctor>
interesting
<marcan>
so I think we can have a flow that never requires that
<marcan>
(this is to avoid e.g. someone installing a vulnerable OS and then compromising a machine that way; they only sign the latest few versions)
<Eighth_Doctor>
no, that makes sense
<marcan>
(but on M1 it is not a hard requirement iff you attest via 1TR as usual, unlike on iOS)
<marcan>
so in principle fully offline installs are possible
<Eighth_Doctor>
right
<marcan>
but again this is all somewhat dependent on finer points, and we might run into issues; I'm hopeful if it comes down to stupid bugs I can get Apple to fix them eventually
<marcan>
the M1 launch was very obviously rushed
<Eighth_Doctor>
well, I didn't say it :P
<marcan>
so there's this whole complex boot system and the tooling is... not quite there yet
<Eighth_Doctor>
(I was thinking it...)
<marcan>
it can *barely* boot from external macos media (which by the way works by copying the kernel/bootloader to internal disk; the low-level bootloader cannot boot from USB/TB)
<marcan>
only sometimes :P
<Eighth_Doctor>
eek
<marcan>
(I know why they did this. All USB stacks are vulnerable messes.)
<marcan>
(iBoot is deliberately *way* smaller than any UEFI)
<marcan>
this is why 1TR is macos
<marcan>
and not built into the bootloader
<marcan>
even the damn boot menu is in 1TR for this reason
<marcan>
(e.g. for dual-boot)
<marcan>
because iBoot can barely show an apple on the screen and an oops message, and doesn't even take keyboard input
<marcan>
just the power button
<marcan>
this is also why I call 1TR part of firmware, you really do need it for basic functionality
<marcan>
so I do not expect anyone to ever remove 1TR (you can if you want to, but you'll be stuck without e.g. boot selection until you recover via DFU mode)
<pipcet[m]>
but the boot chime is in iBoot, right? Good to see they put the important stuff there, rather than a usb stack.
<marcan>
audio is a lot simpler than USB :P
* Eighth_Doctor
is trying to think of the workflow for provisioning Fedora on a Mac
<pipcet[m]>
a real installation, or just a ramfs-based "live system"?
<Eighth_Doctor>
the former
<Eighth_Doctor>
I don't think live systems are possible with this model
<marcan>
Eighth_Doctor: depends on how much control you want to have; e.g. if people put up disk images we can just add to our alx.sh script I certainly would want to give people a list of options in our install script
<marcan>
but if you really want to have a full custom installer from 1TR you could do that
<marcan>
or just let people use m1n1+u-boot to boot a standard USB UEFI installer
<pipcet[m]>
you just have to put a huge payload in the macho :-)
<Eighth_Doctor>
so maybe, a new variant of FMW that writes a USB stick that contains the OS disk image + a 1TR app for installation, reconfigures the firmware to enroll Fedora, writes it to a partition, then reboot?
<Eighth_Doctor>
marcan: I'm okay with as many options :)
<marcan>
my plan is to stream the rootfs straight to disk in 1TR, no need for USB
<Eighth_Doctor>
but I'm trying to think of "newbie interested in Linux on their Mac" case (which was a common case when I was in college a decade ago...)
<marcan>
we don't have ext4 mounting in 1TR of course, but we could use a userspace library or just rely on the disk image being sane; the EFI partition of course will be FAT32. m1n1 itself gets installed on APFS as that is all iBoot supports (along with iBoot2 and device firmwares, that layer we do not control but have to provision)
<marcan>
well, I want to make our installer as newbie-friendly as I can in textmode, and if someone wants to do a graphical version I would certainly welcome that :-)
<Eighth_Doctor>
heh
<Eighth_Doctor>
well, if a TUI exists, maybe a Fedora GSoC project to give it a coat of paint with some GUI goodness could be in the cards
<marcan>
:)
<Eighth_Doctor>
iirc, the original Fedora branding in the Mac UEFI environment work was a GSoC effort years ago too
<marcan>
hah
<Eighth_Doctor>
(Fedora is one of the few distros that natively installs to the HFS+ ESP and will correctly set its branding icon in the OS firmware)
<Eighth_Doctor>
err Mac firmware
<marcan>
fwiw the Asahi stuff is more about the core M1 support project than a distro per se, so an Asahi logo briefly flashing before Fedora takes over at the UEFI stage is not incongruent
<marcan>
like, we'll be maintaining an ALARM package repo, sure, but that's just an example
<marcan>
we're really about "Linux on M1", people can pick their distro
<marcan>
I'm not even sure if we'll brand our ALARM images, maybe optionally?
<marcan>
not like Arch has much branding to begin with
<marcan>
neat :)
<marcan>
that's another thing, "Linux" shows up as macOS on the boot picker right now, but I hope there's a way to change that
<Emantor>
I think Arch Branding consist of optionally installing wallpapers…
<marcan>
I know I can change the version number at least
<marcan>
Emantor: pretty much
<Eighth_Doctor>
if it works like it did on x86, there's an ugly plist file involved :D
<j`ey>
marcan: but it's m1n1.. not Linux??
<marcan>
yeah that's the version thing
<marcan>
j`ey: :)
<j`ey>
so they really wanted us to put Linux on theses..
<marcan>
no I mean Linux is just the partition name
<Eighth_Doctor>
marcan: actually, if the Asahi logo goes to U-Boot as the efi logo thingy, then Fedora can safely dual brand
<marcan>
but under that it says "macOS <someversion>"
<Eighth_Doctor>
which would be sweet
<marcan>
I can control the version but haven't figured out if I can change the macOS part
<marcan>
Eighth_Doctor: not sure how the efi logo thingy works?
<Eighth_Doctor>
gimme a sec, I'll look it up
<Eighth_Doctor>
bgrt
<yrlf>
marcan: "macOS ; compatible, Linux 5.13" :^)
<marcan>
also fwiw, m1n1 does support inline payloads so at least adding support for replacing the logo that way (i.e. easily at m1n1 install time) is trivial
<marcan>
i.e. cat m1n1.macho logo.bin or whatever (not supported right now but easy to add)
<Eighth_Doctor>
oh neat
<marcan>
that's how u-boot is embedded
<marcan>
or you can append a kernel and direct boot that
<Eighth_Doctor>
that'd be quite useful
<marcan>
so while you can't change the logo post install or keep it as a separate file, it's certainly easy to add support for changing the logo at install time easily
<Eighth_Doctor>
that was the change in Fedora 30 implementing it
<Eighth_Doctor>
since there's no ACPI on macs, we'd need another path, but that could be designed into the uboot path
<Eighth_Doctor>
from m1n1
<Eighth_Doctor>
since uboot fakes UEFI anyway, it can do whatever
<marcan>
Eighth_Doctor: oh you mean framebuffer handover? yeah I want to do that as cleanly as possible
<Eighth_Doctor>
yup
<marcan>
(this also ties in with the DRM KMS driver I need to write)
<marcan>
I thought you meant some kind of specific logo thing
<Eighth_Doctor>
well I did until you started talking about this
<Eighth_Doctor>
because I didn't understand the role of m1n1
<marcan>
iBoot initializes the framebuffer, puts an apple there; m1n1 replaces it with the Asahi logo; whatever comes after m1n1 pre-OS will still use the same framebuffer (e.g. u-boot) and hopefully Linux will smoothly take over that
<marcan>
that's definitely my plan anyway
<marcan>
I don't think ACPI has anything to do with this, or does it?
<marcan>
UEFI obviously has the UEFI framebuffer stuff and we can support that I think, for bootloader bits (though these macs use a 10bpc mode, not sure if the UEFI spec supports that, but if we *really* want to m1n1 or u-boot could probably flicker-free downgrade that to 8bpc for compat)
<marcan>
and then as long as the DRM/KMS driver knows how to hand-off (which it will because it's all specific to this hardware anyway) it should just work
<Eighth_Doctor>
but that can be fixed if there's another defined path
<marcan>
ohh, so, like, passing a firmware background explicitly instead of just saying "contents of the framebuffer"?
<marcan>
I would've imagined it worked like the latter, heh
<marcan>
oh wait, it's just a descriptor?
<marcan>
ah no, it goes to a separate memory area presumably
<marcan>
well, I'm sure we can come up with something for this
vimal has joined #asahi-dev
<marcan>
m1n1's job is to build a devicetree for the next stages to use among other things, and currently m1n1 protects itself in memory (it may free some of its memory in the future but some things will require parts of it to stay resident; this is all subject to change as more details are worked out) so it would be fairly simple to establish DT bindings to do the same thing that ACPI table does
<marcan>
if they don't already exist :)
<j`ey>
how big is m1n1?
<j`ey>
(in ram)
<marcan>
500KiB right now, give or take
<marcan>
let me check the actual segments
<j`ey>
bigger than I expected
<marcan>
most of it is bss and such
<pipcet[m]>
much of that is the two 8bpp fonts it includes :-)
<marcan>
ah but that's not in the elf
<marcan>
there's 60KB of fonts in there
<j`ey>
why 2 fonts?
<pipcet[m]>
plus, of course, the logos
<marcan>
j`ey: retina and non-retina
<marcan>
the logos are larger
<marcan>
66KB x1 262KB x2
<marcan>
so yeah most of m1n1 is graphics (all of that could be put in a discardable section to be dropped post-boot)
<j`ey>
that makes sense!
<pipcet[m]>
or we could do without it for "production" installs using another distro, presumably?
<marcan>
I don't really care about .5MB right now, but much further down the line when we know what we need to stay resident this is easy enough to fix
<marcan>
and sure, if we support logos as payloads there's no reason to embed the default logo, we can just make the installer always add it unless overridden
<marcan>
and the payload area is *not* kept after boot already
<marcan>
I already have a deflate implementation, so at this point just supporting PNGs outright wouldn't be a big deal (hopefully with a more minimal implementation than libpng though :P)
<pipcet[m]>
or, you know, we could leave the graphics to the next stages and just boot the damn thing.
<marcan>
well you are certainly free to not add a logo and leave the apple apple there
<marcan>
but hey *I* want the logo thanks :)
<marcan>
another story is that m1n1 itself isn't really configurable, e.g. I'm writing a hypervisor into it. not exactly a lot of code, much less than the graphics, but presumably at some point further down the line we're going to want more build-time configurability
<pipcet[m]>
if it's going to be replaced by the distro anyway there's no reason for the flicker :-)
<marcan>
again, not a big deal, but also not really worth doing right *now*
<marcan>
well it depends on how the distro deals with it :p
<marcan>
co-branding would be cool, come one, give us some credit for the project ;)
<marcan>
I'm certainly not going to force anything on anyone but it would be nice
<Eighth_Doctor>
I personally would like Asahi + Fedora
<marcan>
*come on
<Eighth_Doctor>
as long as it's okay with both projects (which I can't see how it wouldn't be)
<j`ey>
come one, come all
<marcan>
certainly is with us!
<Eighth_Doctor>
if I thought I could sway you, I'd get you to make Asahi Linux as a Fedora Remix, but I don't think I could :)
<marcan>
heck it will probably help clear up some confusion; assuming the ALARM folks don't object I'll probably co-brand our images that way in the documentation/etc
<marcan>
since too many people still think Asahi is strictly Arch or something
<Eighth_Doctor>
yeah, I was confused at first too
<Eighth_Doctor>
it might actually help to have a couple of launch flavors when things are ready
<marcan>
yeah
<marcan>
I want to have a Gentoo overlay too, though I'm going to need an arm64 buildbox if I'm going to be making stages
<marcan>
(I personally use more Gentoo than Arch though I use both, but it would be somewhat silly to offer Gentoo as our default; these things are fast but forcing people to compile KDE is not my idea of user friendly)
<JTL>
agreed
<Eighth_Doctor>
as one of the leaders of the Fedora KDE SIG, I'd be interested in making it top tier for Asahi 😈
<marcan>
:D
<JTL>
just get the hypothetical M2 Mac mini or something down the line, and use that as an ARM64 buildserver
<JTL>
lolol
<marcan>
I'm actually considering getting like 4x M1 Mac Minis and making a cluster
<marcan>
I've been wanting to build an arm64 storage cluster *anyway*
<j`ey>
you have 4 already!
<marcan>
I have 3 M1s but they're all different
<marcan>
:P
<j`ey>
the 4th hasnt arrived yet?
<j`ey>
the imac
<marcan>
that isn't shipping yet
<marcan>
also I need to order a VESA mount arm for it
<marcan>
also do I detect some interest in japanese culture? ;)
<Eighth_Doctor>
you'd be right
Eighth_Doctor is now known as Conan_Kudo
<Conan_Kudo>
after all, this is my primary self :D
<marcan>
hah
<Conan_Kudo>
I've wanted to visit Japan for years, but I've been afraid to
<marcan>
afraid?
<Conan_Kudo>
I've heard that if you don't know Japanese at all, you're kind of screwed
Conan_Kudo is now known as Eighth_Doctor
<marcan>
eh, depends on what you call "screwed"
<svenpeter>
Japan is fun, can recommend as a solo trip even without any Japanese knowledge
<marcan>
^^ this
<marcan>
(but also, learning the basics isn't hard and goes a long way)
<Eighth_Doctor>
I also was "weeb" enough to do fansubbing work years ago :)
<marcan>
I make japanese touhou music rearrangements so...
<Eighth_Doctor>
I picked up on some basic grammar and tone/context stuff and used that to QC Detective Conan fansubs
<Eighth_Doctor>
but that was a long time ago :)
<marcan>
that doesn't sound like "not knowing japanese at all" to me :)
<Eighth_Doctor>
I know basic grammar and stuff, but I can't read it
<svenpeter>
I went to Japan a few years ago on a whim. I didn’t watch anime or anything and couldn’t speak or read a single word. No issues at all there :)
<Eighth_Doctor>
Kanji and Kana escape me
<marcan>
you can learn kana in a few weeks with a flashcard app
<Eighth_Doctor>
I have extremely limited comprehension with romaji, but I wouldn't count it as usable
<marcan>
kanji... that takes years, I'm working on that
<marcan>
but also what svenpeter says
<marcan>
you're definitely not going to be screwed in any way without japanese
<Eighth_Doctor>
well then maybe I'll do it after this pandemic stuff is over
<marcan>
(it just helps of course, but that goes for any country and their language)
<Eighth_Doctor>
I got my second shot on Tuesday and I'm mostly recovered from that :)
<marcan>
heh, yeah, here in japan nothing until july-september...
<Eighth_Doctor>
well, it'd probably be next year anyway
<marcan>
yeah, of course
<Eighth_Doctor>
though I am internally crying about losing my Delta rewards status
<Eighth_Doctor>
they didn't freeze it this year like they did last year
<marcan>
ouch
<Eighth_Doctor>
I used to fly at least 3-4 times a year for the past five years
<marcan>
my status got renewed a few months back, I think I'm good until the end of the year, but I'm not sure if I'll have to do some stuff right then...
<Eighth_Doctor>
last year sucked
<marcan>
same
<marcan>
nothing for me last year
<Eighth_Doctor>
I will probably try to beg Delta to preserve it somehow
<marcan>
oh ugh, this says my status expires in days lol. I sure hope they re-extend
<marcan>
maybe they only extended it 6 months
<marcan>
it'd be really silly if they don't re-extend
<Eighth_Doctor>
yeah, I'm not even supposed to travel until at least October 1
<marcan>
apparently I could purchase enough tier miles for, like, the cost of one flight give or take?
<marcan>
that *might* actually be worth it, as stupid as it sounds
<Eighth_Doctor>
ugh, I might actually consider it too
<marcan>
oh wait, but only half
<marcan>
I'm guessing it doesn't stack
<marcan>
might have to call them
<Eighth_Doctor>
fuck, my status is gone completely
<Eighth_Doctor>
I'm back to being a regular SkyMiles member
<Eighth_Doctor>
😭
<Eighth_Doctor>
that means no more cheap upgrades
<marcan>
ah yeah, they only extended it 6 months for us, not a full year. meh.
<Eighth_Doctor>
blech
<Eighth_Doctor>
well, it seems like the "conciliatory gesture" is that earning the status is supposed to be massively easier in 2021
<Eighth_Doctor>
75% more earned per trip
<j`ey>
when you cant go anywhere for most of the year, if at all, v cool!!
<Eighth_Doctor>
yeah, airlines suck
<marcan>
requalification kind of sucks for me, I'm with Aegean and I got in when it was really easy
<marcan>
but then again I don't fly as much as I used to, even pre-COVID
<marcan>
so I might just stop caring
* Eighth_Doctor
shrugs
<Eighth_Doctor>
I travel twice a year (domestically) just to visit my family
<Eighth_Doctor>
so it's not a huge deal, it's just annoying
<marcan>
yeah, I used to roundtrip to europe ~5x yearly at peak - 4 events I staffed, 1 CCC/xmas for family
<marcan>
I'm down to ~2x events yearly in 2019
<marcan>
(where I still see family, but I dropped xmas)
<marcan>
to be honest, this whole pandemic thing has really boosted remote events
<marcan>
I hope to do more of that and less travel
<marcan>
anyway, let's see if I can get some work done today :)
<Eighth_Doctor>
lol
<j`ey>
5tr34m?
<marcan>
yes
<j`ey>
wow, real hacker knows the lingo :P
<marcan>
have you *seen* the m1n1 data abort sentinel value?
<marcan>
:p
<j`ey>
nope D:
<jannau>
let me fix that
aquijoule_ has quit [Ping timeout: 240 seconds]
richbridger has joined #asahi-dev
odmir_ has joined #asahi-dev
odmir_ has quit [Ping timeout: 268 seconds]
jeffmiw has joined #asahi-dev
jeffmiw has quit [Ping timeout: 246 seconds]
zkrx has quit [Ping timeout: 268 seconds]
zkrx has joined #asahi-dev
jabashque has quit [Quit: Connection closed for inactivity]
VinDuv has quit [Quit: Leaving.]
<modwizcode>
marcan: that's crazy amounts of travel to me wow
odmir has joined #asahi-dev
odmir has quit [Ping timeout: 260 seconds]
VinDuv has joined #asahi-dev
kettenis has quit [Ping timeout: 252 seconds]
kettenis has joined #asahi-dev
zkrx has quit [Ping timeout: 260 seconds]
herbas has joined #asahi-dev
zkrx has joined #asahi-dev
herbas has quit [Quit: herbas]
kettenis has quit [Ping timeout: 252 seconds]
kettenis has joined #asahi-dev
jeffmiw has joined #asahi-dev
jeffmiw has quit [Ping timeout: 240 seconds]
alice[m] has joined #asahi-dev
DarkShadow44 has quit [Ping timeout: 246 seconds]
odmir has joined #asahi-dev
jeffmiw has joined #asahi-dev
VinDuv has quit [Quit: Leaving.]
odmir has quit [Ping timeout: 240 seconds]
DarkShadow44 has joined #asahi-dev
jeffmiw has quit [Remote host closed the connection]
jeffmiw has joined #asahi-dev
DarkShadow44 has quit [Quit: Free ZNC ~ Powered by LunarBNC: https://LunarBNC.net]
kabutten[m] has joined #asahi-dev
taziden has quit [Ping timeout: 250 seconds]
kabutten[m] has left #asahi-dev ["User left"]
taziden has joined #asahi-dev
jeffmiw has quit [Remote host closed the connection]