ARM64 support

[Timtam]

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!

[rejetto]

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.

[W-i-n-7]

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

[Timtam]

@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.

[rejetto]

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.

[pin24]

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

I'm also ready with accessibility testing

[rejetto]

I'm also ready with accessibility testing

feel free to report any issue :)

[damienzonly]

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

[Timtam]

@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.

[damienzonly]

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

[Timtam]

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.

[damienzonly]

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]

@Timtam @W-i-n-7 @pin24 Hi guys, i wanted to tell you that official hfs (multiplatform) images for docker are out, check it out https://hub.docker.com/r/rejetto/hfs and let me know in my repository if you encounter any issue https://github.com/damienzonly/hfs-docker/issues

[W-i-n-7]

@Timtam @W-i-n-7 @pin24 Hi guys, i wanted to tell you that official hfs (multiplatform) images for docker are out, check it out https://hub.docker.com/r/rejetto/hfs and let me know in my repository if you encounter any issue https://github.com/damienzonly/hfs-docker/issues

yoo sick
also you should add it to CasaOS its a webgui ontop of linux with easy to install and manage docker containers

[caicaicai]

from arm64v8/node

ENTRYPOINT ["npx", "-y", "hfs@latest"]

[damienzonly]

from arm64v8/node



ENTRYPOINT ["npx", "-y", "hfs@latest"]

ho @caicaicai, nice suggestion, in fact that was the way i implemented hfs docker at the beginning, then i decided to compile from sources and provide prebuilt official images since the sources build is a little bit harder than npx and some people might need that