marcan changed the topic of #asahi to: Asahi Linux: porting Linux to Apple Silicon macs | General project discussion | GitHub: https://alx.sh/g | Wiki: https://alx.sh/w | Topics: #asahi-dev #asahi-re #asahi-gpu #asahi-stream #asahi-offtopic | Keep things on topic | Logs: https://alx.sh/l/asahi
bgb has joined #asahi
bgb_ has quit [Ping timeout: 480 seconds]
g0d0h0 has joined #asahi
<g0d0h0>
weird link.. a guy used a 400$ scanner to scan his body for radio frequencies and found bio technology in a human being https://www.youtube.com/watch?v=E1ZqRhe4lZE
g0d0h0 has left #asahi [#asahi]
bgb_ has joined #asahi
bgb has quit [Ping timeout: 480 seconds]
chadmed has joined #asahi
darkapex1 has joined #asahi
darkapex has quit [Ping timeout: 480 seconds]
yuyichao has quit [Ping timeout: 480 seconds]
chadmed has quit [Quit: Konversation terminated!]
<kode54>
cool, first time I've seen bot spam here
yuyichao has joined #asahi
PhilippvK has joined #asahi
chadmed has joined #asahi
phiologe has quit [Ping timeout: 480 seconds]
kov has quit [Quit: Coyote finally caught me]
kov has joined #asahi
phiologe has joined #asahi
PhilippvK has quit [Ping timeout: 480 seconds]
marvin24 has joined #asahi
marvin24_ has quit [Ping timeout: 480 seconds]
darkapex1 is now known as darkapex
artemist has quit [Quit: artemist]
chamomile has quit [Ping timeout: 480 seconds]
artemist has joined #asahi
chadmed has quit [Remote host closed the connection]
chamomile has joined #asahi
sailorek1234 has joined #asahi
d0p1__ has quit [Ping timeout: 480 seconds]
VinDuv has quit [Quit: ZNC 1.8.2+deb2+b1 - https://znc.in]
VinDuv has joined #asahi
hspak has joined #asahi
bgb has joined #asahi
bgb_ has quit [Ping timeout: 480 seconds]
bgb has quit [Remote host closed the connection]
bgb has joined #asahi
tertu2 has joined #asahi
chamomile has quit [Ping timeout: 480 seconds]
tertu has quit [Ping timeout: 480 seconds]
bgb_ has joined #asahi
bgb has quit [Ping timeout: 480 seconds]
bgb_ has quit [Ping timeout: 480 seconds]
<mps>
kettenis: latest apple-m1-m1n1-nvme works on machine where macos 12.0 is installed, booted it with efi prepared usb stick and grub-efi
<mps>
I have to test later if it can boot using simple config with extlinux.conf
<mps>
not sure should be the dtb from kernel or from u-boot used when creating u-boot.macho
<mps>
in first try I user one from u-boot
<mps>
used*
<mps>
but with it and booted from usb stick I don't see nvme detected by kernel
ar has quit [Ping timeout: 480 seconds]
chamomile has joined #asahi
as400 has joined #asahi
<as400>
mps: I'm also trying to compile u-boot but I get errors. Which gcc version are you using ?
<as400>
Does it also include that unfortunate corellium code that marcan insisted not to test ?
<as400>
I mean pkgbuild is very handy for me.
<mps>
I think it does, keyboard part
<sven>
Hrm, was maintaining that thing with individual patches too annoying?
<marcan>
honestly with all the rebasing and DT conflicts going on, patches seems painful right now
<as400>
So maybe this pkgbuild should be pointed to asahi branch - so people test things that are useful to you guys ?
<kettenis>
the hard reality is that it probably isn't very useful to test something that deviates significantly from that branch
darkapex1 has joined #asahi
darkapex has quit [Ping timeout: 480 seconds]
<jannau>
handling 76 or so patches became annoying. the single patch is not strictly a single patch but a mbox created by `git format-patch --stdout`
<Dcow_>
marcan: regarding the installer: I think it is no reason to change from python at least right now. Once it will be closer to "production ready" state, I may work on wrapper or the machine readable CLI to make a calls from GUI.
<Dcow_>
what are the requirements to run under 1TR?
<marcan>
good question :-)
<marcan>
there are fewer tools/frameworks available, but obviously they have quite a bit
<marcan>
you just need to test it I guess
<Dcow_>
what do you want from the installer UI?
<Dcow_>
disk partition tool, selection the macos source to copy the fw, what else ?
<marcan>
the FW isn't copied from an existing macos, it's downloaded from Apple so it would be choosing a version from those we support / are usable on this machine
<marcan>
also choosing what distro/image to install (optionally)
<Dcow_>
what about FW that forged into MacOS drivers?
<Dcow_>
like AVD or the second usb's for m1 iMAC
yuyichao has quit [Ping timeout: 480 seconds]
<marcan>
that comes from the kernelcache that's already being downloaded
<marcan>
all the firmwares will come from the chosen IPSW, we do not mix and match with the running system
<Dcow_>
I see thanks
<Dcow_>
is there anyone who can work on some-kind of UI mockups?
<landscape15[m]>
Dcow_: Which GUI framework do you want to use?
yuyichao has joined #asahi
Gaspare has joined #asahi
<Dcow_>
Not sure yet. Might Be Qt or Flutter
<Dcow_>
of those won't work on 1TR then gonna learn some swift ui
<marcan>
Qt would be nice, since it has nice Python bindings and can make it easier to test on Linux, though it might be a bit heavy to ship
<marcan>
but then again we're already downloading 1GB for the installs anyway
robher_ has quit []
robher has joined #asahi
<Dcow_>
Flutter on linux also work good. Personally I prefer it over Qt. But we need to decide what suit better.
<Dcow_>
p.s. Canonical working on Flutter installer for Ubunty
<Dcow_>
ubuntu
the_lanetly_052 has joined #asahi
aleasto has joined #asahi
<landscape15[m]>
Dcow_: I think any type of UI doesn’t work good in 1TR. It is very limited.
<matthewayers[m]>
Sorry, what is 1TR?
<landscape15[m]>
matthewayers: One True Recovery. It’s the APFS container for the macOS recovery.
<marcan>
they run Safari in there, they obviously have all the core stuff
<matthewayers[m]>
Are those sites limited to basic HTML/CSS/JS/TS functionality?
<jn>
hm, a web UI viewed in Safari would be an interesting solution for the installer
<matthewayers[m]>
I know that some companies use a web UI for setting up iPads on-device, so it’s definitely possible
<matthewayers[m]>
I also just remembered that my work MacBook Pro literally requires me to sign into Microsoft in order to log in
<wouter>
marcan: didn't see your brain dump last night until now :-)
<wouter>
marcan: Debian has traditionally had a "this is everything you need" download on their site
<wouter>
marcan: I think we want to keep things that way (yes, "we", I'm wouter@debian.org ;-)
<wouter>
marcan: we've also had a "w32installer" thing which downloads the netinstall under Windows and then modifies the boot system to include "Install Debian" in the Windows boot menu
<wouter>
I could imagine something similar to be written for M1 macs
<wouter>
anyway, all that are just wild thoughts
jkm has quit []
<marcan>
wouter: well, the process involves at least two mandatory reboots, and to make it as user friendly as possible you need to do streaming partial ZIP file fetches from Apple's CDN, firmware cutting and filename munging, manually creating a macOS stub partition with all the Preboot directory structure (which involves parsing and understanding Apple's manifest plists), also you need to race to kill ...
<marcan>
... Apple's boot picker before it reboots because we don't have proper tools to do that programmatically yet, etc
<marcan>
if you *really* want to re-implement all that for Debian, I won't stop you... but I imagine most distros will be perfectly happy telling people to `curl alx.sh | sh` from recovery mode, follow the prompts, then plug in some EFI USB install media :-)
<marcan>
fwiw the current installer does not have an offline option, but it's trivial to implement with the caveat that you need to tell people to download the entire ipsw from Apple, and that means 14+GB instead of the ~1GB of partial contents the installer will normally download
<marcan>
(and it means you need to figure out *what* ipsw they need ahead of time using documentation instead of having the installer magically work it out)
<wouter>
marcan: that, or ship it as part of the install media?
<wouter>
marcan: I'm sure you can do "sh /Volumes/debian/alx.sh" or some such, too
<marcan>
you can't ship Apple's IPSWs, they are not redistributable
<marcan>
so that part is either online or tell people to download it on another machine and copy it to the install media, or similar
<wouter>
no, but we can ship your script I would hope? ;-)
<marcan>
of course
<wouter>
that's what I meant
<marcan>
yeah, you can ship the installer and I'm also happy to make it more modular than it already is (it's python fwiw) in case people want to wrap it in their own UI or whatever
<wouter>
ah, heh
<wouter>
d-i doesn't ship with python, and adding that is going to be complicated I would guess
<marcan>
this runs under macos
<marcan>
we ship python with the installer
<wouter>
oh right
the_lanetly_052 has quit [Ping timeout: 480 seconds]
<wouter>
of course it would be awesome if apple just added their firmware to LVDS... but meh, I guess that's not going to happen
<marcan>
it's not just that
<wouter>
I realize that
<wouter>
but if it was there, then there are tools already written
<marcan>
the way this works is that the OS demarcation point is *not* the unsigned code demarcation point
<marcan>
that means that any third-party OS needs to first install the signed boot components from Apple, *then* install itself as the next stage, all within its own OS container
<wouter>
so that could make it easier to extend installers to download the necessary firmware? or something
<marcan>
and because they don't keep firmware ABIs stable, all that comes as one bundle including signed firmwares loaded by the prior components that expose an unstable ABI to the OS
<marcan>
so part of this whole dance is picking macOS versions to bless as "Linux is compatible with these ABIs"
<wouter>
anyway, again just wild thoughts and I can't say I have a lot of knowledge on the subject, other than you, so feel free to ignore if I sound stupid ;-)
<marcan>
getting the firmware bits that Linux itself needs is easy, you can re-do that if you really want to using some other script; the hairy bit is setting up what is essentially a macOS install minus the root filesystem
<marcan>
where we then replace the XNU kernel with our bootloader that bridges into U-Boot and EFI services
<wouter>
and yes, obviously not-stable ABIs makes things more complicated... I remember similar things from way back when I had a powerbook running Linux as my primary laptop
<marcan>
effectively the Asahi Linux installer is... a macOS installer, for all practical purposes
<marcan>
it just doesn't do the "copy out the rootfs bit"
<wouter>
right
<marcan>
you could literally just... do that instead of running step2.sh as it tells you, and end up with a functional macOS install (ish, there's the signed system volume thing to deal with, but you get the idea)
<wouter>
do you think it is likely you'll be able to reduce the dependency on unstable firmware stuff at some undefined point in the future, or do you think this is how things will have to be for the foreseeable future of apple silicon ARM chips?
<marcan>
matthewayers[m]: those are kernel functions, we can't run kernel code
<marcan>
wouter: this is their design, I don't see them changing it. however, as long as we can pick a macOS version to pin to, we don't have to support all possible ABIs
<marcan>
so we only need to upgrade when there are important bugs fixed or new machine support
<wouter>
right
<marcan>
this does *not* limit what macOS versions the user can have installed, it's just what "macOS" our partition is based on
<marcan>
(as long as system firmware is equal or newer)
<wouter>
oh, right
<marcan>
(I still haven't figured out how to do upgrades, fwiw; I think that would involve another couple reboots and re-provisioning our bootloader, but I need to run some tests)
<marcan>
this is relatively cumbersome in part because Apple's secureboot requires users to assert physical presence (via long pressing power) before they can install a third-party bootloader, and *that* action, since 12.x, has to happen in a paired recoveryOS for the OS you're trying to mess with, which means it has to happen *after* you've already installed the boot components
<marcan>
so right now the installer does its thing, then drops a .sh file and tells users to boot holding down power, go to options, pull up the terminal, then run it and follow the last few prompts
<marcan>
and that will finally install m1n1 as the "macOS" kernel
sailorek1234 has quit []
<marcan>
I should also do an offline install test (truly offline, i.e. no phoning home by Apple's stuff); I think that won't work right now but I know how to make it work
<wouter>
do I understand correctly that it won't be possible to upgrade apple firmware for Linux, then? Or is that something that might theoretically be possible but you just haven't gotten around to it yet?
<marcan>
I'm not sure, actually; it's uncharted territory.
<wouter>
fair enough
<wouter>
you've got plenty of other stuff to do, I guess :)
<marcan>
in principle once we figure out SEP, we could access the services that make this possible, but we wouldn't be able to provision a new m1n1 because that only works from recovery mode; however, I don't know if we'd be able to update the boot policy with a new NSIH (the hash of the apple boot stuff) while preserving the existing m1n1
<marcan>
that's a long way out though, and would also involve re-inventing more of Apple's process
Gaspare has quit [Quit: Gaspare]
<marcan>
right now the installer uses a hybrid approach where we copy all the "raw" files from the installation image, which Apple's magic bootability code (which runs when the user selects the volume to boot, or if we use bputil) then copies and personalizes into the actual boot directory that the first-stage bootloader will use
<Retr0id>
RE: possibly using safari as an installer UI: I just tested, you can visit a locally-running httpd from 1TR's safari, although I couldn't get it to actually visit localhost for some reason - I had to use a public domain that resolves to 127.0.0.1
<marcan>
I mostly know how all that works, but haven't attempted to do it myself
<wouter>
right
<wouter>
okay, thanks for the info
<marcan>
Retr0id: I wasn't actually thinking about that, but... that might not actually be a bad idea, bottle.py and some HTML/CSS/JS is a lot lighter weight than any UI framework we might choose
<wouter>
I was thinking of doing the minimal bits necessary to make debian-installer work on an m1 mac, but I guess it's just too early for that ATM...
<wouter>
besides, I'm way too busy with other projects already anyway, so I really shouldn't be taking on yet another project :-D
<marcan>
yeah, I'd recommend lurking for a bit as we put together something end-user-approachable for the installer :)
<marcan>
I plan on doing an Arch Linux ARM remix as a reference, which will also give an idea of what bits and pieces have to change
<marcan>
mostly the firmware copying stuff and such
<wouter>
yeah, I think I'll do that for the time being
<wouter>
(well, I am already doing that on twitter, but hey)
<marcan>
I'm also going to write a spec for the prebuilt distro images as part of that, in case you're interested in shipping like that too (i.e. as an option in our installer, bypassing d-i and just dumping out a rootfs, more like the typical cloud imaging stuff)
<marcan>
:)
<wouter>
the downside of that is that it makes certain configuration options inside d-i unavailable
<marcan>
yes, of course, it's limited
<wouter>
e.g., do you want full-disk encryption, LVM, some other device-mapper stuff, etc
<marcan>
yup
<wouter>
so while that can work initially, eventually you'll want to be able to boot d-i at some point
<marcan>
for people who want that they'd want to run a proper installetr
<wouter>
right
<wouter>
but it could be a way to get things working intially, sure
<marcan>
yeah
<marcan>
though as I said I would expect most EFI-compatible installers to work out of the box, modulo kernel, as far as the general flow is concerned
<marcan>
we could also give users the option of "installing" the installer as a netinstall ramdisk or whatever, and then have that run on first boot and install the real distro
<wouter>
well, yes
<wouter>
but I think the advantage of having a "this is everything you need to download" on a distribution's site is not to be underestimated
<wouter>
you don't want to confuse users with "yes you can install Debian, but you need to also download this other thing from this other site here"
<wouter>
integrating things into one package is what distributions *do*
<marcan>
well, the way I see it is that our curl|sh makes your Mac into something Linux capable, then you can just boot whatever installer you want from USB :-)
<kettenis>
exactly; it is more like a BIOS update ;)
<wouter>
right
<wouter>
the way I see it is, Debian ships a USB image, which comes with the curl|sh thing that you run from macOS, then you reboot into d-i and get going
<marcan>
but you can certainly ship our script, it just needs a bit of coordination since I want to avoid significant divergence (especially since people will want to be able to upgrade with the curl|sh method or some other download... we don't want to end up with divergent installers somehow getting confused by each other's output)
<wouter>
(except it won't be "curl|sh", just "sh" of course)
<marcan>
also one advantage of the curl|sh method is that when Apple ships new machines we can support with just DT changes, we do that on our end and magically all distros work already, no re-building install images ;)
<eta>
I wonder whether you could even have the debian USB do the fancy macOS thing where the disk opens with a background image that tells you what to do
<eta>
(like disk images on macOS do with the "drag this into the applications folder" imagery)
<marcan>
I'm not sure if that works from recoveryOS
<wouter>
eta: that's actually very easy, it just ships with a hidden file in the directory that finder sees
* wouter
<- does that for work
<wouter>
marcan: well, probably not, but it would still be useful if you had it for the initial "install this" USB thing
<marcan>
you *can* run the installer from macOS but it comes with one caveat: that way requires phoning home to Apple and Apple can (and probably will) cut off old macOS versions from this method at some point, for security reasons
<marcan>
so at least for our normal docs I'll tell people to boot and run our installer from 1TR, since it eliminates that variable
<wouter>
sure
<marcan>
(and either way you still need to do a reboot into the new 1TR recoveryOS and run step2.sh, regardless of what initial environment you chose)
<wouter>
my point is, the "background image" that eta talks about is easy to add to an "install image", and that image can then just give you instructions to reboot into 1TR and then run the script
<marcan>
oh sure, that works
<wouter>
anyway, time to go home now
<wouter>
later
<marcan>
and I should sleep :)
<wouter>
heh :)
<wouter>
good luck with that then :)
chamomile has joined #asahi
jkm has joined #asahi
chamomile has quit [Ping timeout: 480 seconds]
<matthewayers[m]>
I agree that Safari should be used as a UI if possible because it would make for a much more elegant solution than trying to load some other UI instead.
aleasto has quit [Quit: Konversation terminated!]
aleasto has joined #asahi
as400 has left #asahi [#asahi]
<Retr0id>
I'm currently trying to figure out how to launch safari with a localhost url, programatically (among other things, `open` does not exist in 1TR)
___nick___ has joined #asahi
___nick___ has quit []
___nick___ has joined #asahi
<matthewayers[m]>
Would it be possible to bundle a command similar to “open” with the installer?
<matthewayers[m]>
…such as asahi-open?
<matthewayers[m]>
* Retr0id: Would it
<Retr0id>
I suppose. I will do some research into how `open` actually functions
<matthewayers[m]>
I might decompile it in Ghidra to see what it relies on. I honestly wouldn’t be surprised if it’s basically a wrapper around a system command
<Retr0id>
invoking the Safari binary directly, with a local file path "works", but it spawns a file picker dialogue asking you to confirm your choice, which is a bit janky
<Retr0id>
(the local .html file can then redirect to localhost)
<matthewayers[m]>
I had trouble finding `open` so I'm terrorizing my computer instead...
<marcan>
`which` is your friend
<marcan>
also it's like 300kB and calls into a pile of frameworks... also I'm pretty sure whatever API it uses is documented
<matthewayers[m]>
Noted. `grep` just finished running.. haha
<matthewayers[m]>
marcan: Thanks for the suggestion! I found it in my output but it truncated to ./bin/open instead of /usr/bin/open, so `which` saved me a lot of headache there
chamomile has joined #asahi
chamomile has quit [Remote host closed the connection]
<NightRaven[m]>
Like is there a way i can boot asahilinux on my mac i dont really care about the gpu acceleration yet since i won't be playing games. Just running it on bare metal
<j_ey>
NightRaven[m]: yes the wiki has some steps, although its maybe a bit out of date
<marcan>
Retr0id: the file picker is because of the sandbox
<Retr0id>
ah - is there a sandbox-friendly path I can drop an html file in?
<marcan>
if you drop the HTML file in /var/root/Library/Containers/com.apple.Safari/Data/foo.html and open it as Safari foo.html it works
<marcan>
no picker or anything weird
<Retr0id>
nice
<matthewayers[m]>
marcan: I decompiled using Binary Ninja and I'm seeing what you're referring to for `open`. Do you think we could bundle something similar to this to the installer to launch the web UI in Safari?
<marcan>
^^ just use an HTML file
<marcan>
only annoying issue is it spawns behind the terminal
<NightRaven[m]>
j_ey: oh ok thx : )
qw4q has joined #asahi
<matthewayers[m]>
marcan: I wonder if there's some way we can get around that.. some sort of manipulation of the window manager?
<Retr0id>
can confirm that an html file with a meta redirect to localhost works as expected
<matthewayers[m]>
Retr0id: Does that launch in front of or behind the terminal?
<marcan>
matthewayers[m]: probably, but at that point it would involve writing a helper tool most likely
<Retr0id>
behind terminal still
<Retr0id>
could kill the terminal I suppose
<marcan>
osascript can do that in macos, we could just invoke the relevant APIs ourselves
<marcan>
killing the terminal is probably a bad idea, because it'd bring back the recovery menu
<Retr0id>
ah
d0p1__ has joined #asahi
<matthewayers[m]>
What about hiding the terminal, similar to what CMD+H does? Does that even exist in recovery mode?
<marcan>
that should also be able to launch safari with a URL properly without hacks
<qw4q>
hi guys, sorry for the basic question, I've been googling this for days: Does Asahi linux work well inside VMs on an M1, since I'm guessing that there does not need to be M1 specific kernel support when run inside a VM?
<qw4q>
or is there huge work ahead to get lots of packages compiled on arm64
<j_ey>
qw4q: no m1 support needed inside a VM on m1
<eta>
qw4q: you don't need Asahi Linux for that
<qw4q>
i need to be running a distro compiled for arm64 though right?
<qw4q>
or is qemu x64 emulation good?
<j_ey>
qw4q: are you talking about on macos or?
<qw4q>
i'm just wondering how hard it'd be to get a VM set up with chrome browsing on an M1, which had good enough gpu acceleration support to be snappy
<qw4q>
j_ey yes macos on an M1
<qw4q>
i noticed, for example, that ubuntu don't have an arm64 desktop edition, and instead you need to install the arm64 server edition and then install the desktop package
<qw4q>
so i'm wondering that's because it's all a bit broken
<j_ey>
no that should work fine
<qw4q>
s/wondering/wondering if
<qw4q>
j_ey oh wow, you're blowing my mind, thanks. So I won't have the constant pain of an arm64 package not being available? As far as I can see, there is no x64 emulation or plans for x64 emulation to run non-arm64 packages
Gaspare has joined #asahi
<psykose>
games aside arm64 should have pretty much everything
Gaspare has quit []
<qw4q>
psykose ok great, thank you
<Retr0id>
I have an ubuntu "server" VM (with ubuntu-desktop installed) running in UTM nicely
<qw4q>
Retr0id is it nice and snappy?
<qw4q>
i've had problems in the past simply trying to scroll through web pages in VMs if there wasn't proper GPU acceleration
Gaspare has joined #asahi
<Retr0id>
its fine even with software rendering
<Retr0id>
there's even experimental gl acceleration passthru stuff working, although I haven't tried that yet
<qw4q>
Retr0id ok thanks, that's great. I currently have Ubuntu running inside a Parallels VM, and performance really isn't very good, even on my i9 MBP
<qw4q>
and that is GPU accelerated as far as i know
crabbedhaloablut has joined #asahi
loki_val has quit [Ping timeout: 480 seconds]
crabbedhaloablut has quit [Ping timeout: 480 seconds]
crabbedhaloablut has joined #asahi
<mps>
qw4q: I'm running arm64 distro inside qemu VM on M1, works fine
<mps>
though I had to build qemu from git repo to get HVF accelation
<mps>
acceleration*
<j_ey>
at least it has been merged now :)
<mps>
yes, it is, but not yet released stable
<mps>
about year ago had to hunt patches around
<qw4q>
mps thanks
<qw4q>
actually what a great coincidence, AWS just announced M1 instances to rent
<qw4q>
so i can test things
<qw4q>
although of course, that probably won't give me a good idea of e.g. scrolling responsiveness when i remote desktop into a VM inside an M1
<mps>
yes
<matthewayers[m]>
Ooh that could be really useful, but I also need to keep my AWS bill under $30/month (thanks, college)
<qw4q>
looks like scaleway rent them by the hour too
<mini>
the aws pricing is pretty extortionate last I checked
<matthewayers[m]>
Something like $15 per day?
<mini>
$1.083 an hour for the intel one, with a 24hr minimum
<matthewayers[m]>
Yuck.
<mini>
the M1 ones are $0.6498/hr while in preview with a 24 hour minimum
<sven>
iirc the 24h minimum comes from apple's eula
<matthewayers[m]>
Interesting...
<qw4q>
oh scaleway are much cheaper then
<mini>
yeah, it does. but that's up to $483/mo
<qw4q>
and looks like i have to sign up for the m1 aws preview and request access
<mini>
in two months you could just buy a mac mini
<mini>
(744hrs is the most in a calendar month, afaik?)
<mini>
scaleway's 0.1 EUR an hour is considerably cheaper, but I think they're struggling for stock
<qw4q>
yeah resale prices on M1 minis are so incredible that if you just buy and sell on ebay, "rental" is just postage and only a few percent in depreciation
<mini>
or you can buy direct from apple and return it inside 14 days if you don't like it
<mini>
or at the moment, you actually get until jan 8th in some countries
<qw4q>
ooh
<Retr0id>
just wrote a tiny swift program to open an URL, works nicely in 1TR
<qw4q>
although there aren't discounts on the m1 mini direct from the apple store
<mini>
there are not, no
<qw4q>
whereas there are from most retailers
cth451_desktop has quit [Remote host closed the connection]
<matthewayers[m]>
The biggest discounts are education and for veterans/military
<mini>
most retailers don't have the 16GB model though, afaik
cth451_desktop has joined #asahi
<Retr0id>
actually I spoke too soon, it opened safari but not to the correct url...
<matthewayers[m]>
What did it open to then?
<sven>
looks like you get also rent a m1 at hetzner for ~60eur/month
<sven>
*you can
<Retr0id>
it opened to the default homepage
gig has quit [Remote host closed the connection]
<matthewayers[m]>
Is there some way to change the default homepage to localhost or that redirect .html file?
<Retr0id>
I'm trying to do things cleanly
<matthewayers[m]>
Yeah, unfortunately Apple isn't giving you much to work with. If it is possible to change the default homepage, however, that could make a clean Safari launch possible..
<matthewayers[m]>
s/.././
<Retr0id>
at least it works to foreground safari
<matthewayers[m]>
Yeah, that's at least a plus. It just isn't as elegant. I might go in and play around with it later to see if I can figure anything out.