hfs icon indicating copy to clipboard operation
hfs copied to clipboard

ARM64 support

Open Timtam opened this issue 1 year ago • 15 comments

Hello there,

I recently switched from running an x64 server to an ARM64 server. I'm running hfs inside a docker container here, which worked just fine with the x64 linux build, but obviously doesn't on ARM64. I thus tried to build hfs from source on ARM64, but for some weird reason it cannot find the @mui/icons-material files to be bundled into the admin package. Anyway, I guess it'd be much easier to just distribute a linux-arm64 build with any future release. Is there anything complex which needs to be done for that? Do you know of any reason why that shouldn't be part of hfs? Server infrastructure slowly shifts towards ARM too, so having a production-ready build would IMO be beneficial.

Thanks!

Timtam avatar Jan 29 '24 12:01 Timtam

hey! linux-arm binary may be a good move. I didn't include it yet because you can actually run hfs using these instuctions under "other systems" https://github.com/rejetto/hfs?tab=readme-ov-file#other-systems

Let me know what you think about it. It would be wonderful if someone had the time to write instructions (a page on the wiki?) with instructions on how to run HFS with docker. I'm no docker user.

As a side note, you may be glad to know that I'm working hard with a blind user to improve accessibility. Many news already in 0.51 and more to come.

rejetto avatar Jan 29 '24 13:01 rejetto

i got hfs running on my phone! its possible you need to install nodejs and dependencys then run hfs with npx hfs@beta/latest

W-i-n-7 avatar Jan 29 '24 18:01 W-i-n-7

@rejetto thanks, I must have overlooked this guide. That works just fine. Having a dedicated binary in the future would definitely still be nice to have. Yeah I noticed notes of that popping up in the changelog. That is great news, we're close to setting up a HFS + WebDAV solution for our REAPER Accessibility community stash. Should you ever get to integrate either FTP and/or WebDAV directly into HFS, well... that would be amazing as well, but accessibility is amazing and is one of the main reasons why decided to go with HFS over any of the other solutions out there. Keep up the great work! And let me know should you be in need of accessibility testing or something.

Timtam avatar Jan 29 '24 18:01 Timtam

that's cool, i'll surely need feedback on accessibility. i have no clear plans, but i'm interested in webdav, and i may work on it in the second half of the year. And I love Reaper! Started using it like in 2010 and never left.

rejetto avatar Jan 29 '24 18:01 rejetto

that's cool, i'll surely need feedback on accessibility.

I'm also ready with accessibility testing

pin24 avatar Jul 29 '24 18:07 pin24

I'm also ready with accessibility testing

feel free to report any issue :)

rejetto avatar Jul 30 '24 16:07 rejetto

Hi @Timtam, just wanted to inform you that i released docker images for both x86 and arm architectures on rejetto's registry, let me know if it helps you in any way https://hub.docker.com/r/rejetto/hfs/tags

damienzonly avatar Aug 08 '24 00:08 damienzonly

@damienzonly thats useful, it might be worth looking into an automated workflow pipeline to build docker containers without any further interaction. I didn't find the Dockerfile of this container, let me know if you need help with that by pointing me into the right direction.

Timtam avatar Aug 08 '24 17:08 Timtam

This is the repository with the Dockerfile used @Timtam https://github.com/damienzonly/hfs-docker

damienzonly avatar Aug 09 '24 10:08 damienzonly

Thanks, that looks good. Thanks to the Dockerfile I was able to replace my custom Dockerfile with your one. Two things come to mind that would really be useful now:

  1. Automated builds, or at least a build for every release tag, no matter if its stable or alpha/beta/rc, so that everyone can decide wether they want to run on whichever release channel. I don't know for sure, but it feels like the best place to do that would be inside the HFS repo itself.
  2. Using the same tag for every arch, no matter if its amd64, arm or whatever. Docker will already pick the correct architecture if its available, so why not put all architecture builds under the same tag instead of having one for every architecture? Right now its just two archs, but it might be more in the future. Docker BuildKit can already build cross-platform images, utilizing this with e.g. a github workflow would allow for both, automated builds and multi-arch tags at the same time.

Just some suggestions though, the image we have now is already really helpful.

Timtam avatar Aug 09 '24 15:08 Timtam

nice points actually.

the docker release process is still, let me say, "unsure", meaning that i still need to make some decisions. for the sake of releasing an official 0.53 docker image right after rejetto released the 53 i did some (questionable) decisions. i was already working on a script with buildx but i need to finalize it. i can definitely automate once i have a proper script ready, and yes, there is gonna be a docker tag for each git tag rejetto pushes in the hfs git repo, no matter if it's alpha/beta/stable.

one thing i want to mention is that i already discussed with rejetto about keeping docker stuff in the hfs repo or let me maintain the docker releases, and we ended up choosing the latter. for now I'm gonna take care of manually releasing docker tags for each git tag starting from 0.53.0 (which is the minimum version supported in order for docker build scripts to work). I'll keep you posted

damienzonly avatar Aug 09 '24 17:08 damienzonly