Raspberry pi 4 has 4gb of ram. Fopnu is able to run on such a configuration?

Fopnu's RAM usage, in my experience, is dependent on the size of your library. And that's the item count, not the file size usage.

As a guide - albeit from a Windows machine - I have 226,000 items in my library and Fopnu uses nearly 3 GB of RAM.

good idea but there is currently no ARM port of fopnu...

the ethernet connection of a raspi is also part of the USB bus limiting its bandwidth (its a 10/100 connection but it never actually reaches anywhere near 100) so you might find a huge bottleneck in trying to share from NAS (file hashing in and of itself would take forever)

it would only be feasible to share from a beefy thumb drive or, maybe if you had enough of a power source, external usb hard-drive.

dont forget the aftermarket heatsinks... hashing will make the cpu throttle way back if its not cool enough...




all in all if you want to run fopnu from something portable it would be better (and about the same price once you get all you would need to run the raspi) to get a modern netbook with x86/64 cpu..

Good point about the ARM support. I hadn't thought of that. Though I believe the RPi4 has a far faster bus now, which was a limitation for the 3 and prior.

I would love a raspberry version. A little chat and some downloads would be neat!

I know we all love Fopnu but when the platform changes virtually the whole codebase is rendered redundant overnight, also as only the Fopnu dev team know the code to the program this means they have the long job of porting it over and where does that end ?

I like the idea of a stand alone Fopnu chat feature perhaps that can be used on the PI but whole program re-construction to support a niche market is just going to be a distraction from the main supported building program.

Thats my thoughts on this topic, I love the level of decent discussion on this site btw guys.

If you can find a way to build for Linux on x86 and x64, then you can probably build your code for ARM as well. Unless your program depends on specific features of the CPU that only exist on x86 or you use some rare language that has compilers that only target x86. I do not see why that would be the case though, isn't Fopnu written in C/C++?. I hope some dev can chime in. The primary reason for porting Fopnu and Tixati to raspberry is that many people run media centers on raspberries so it would be nice to have Fopnu on them.

Hi Leocold, I am the poster from directly above your post. I am not a Fopnu developer but I do write code myself, that said I feel happy to respond to your post.

It is possible to create something that will run on nearly any platform but as I stated above the the reasons for not doing so are compelling, each platform change requires a lot of time and effort to acheive and in some cases leaves the user with a sub-par product that pleases no one, from the developer side of the fence its not simply possible to "Port" all of the codebase over to a new platform without substantial rewriting and reworking to accomodate missing functions and features found in specific processor offerings, this was the reason behind my response and no other.

I was also mindful of the developers time and how its taken some years and a lot of hard work and effort to faciltate the multitude of its current platform offerings, its not trivial to undertake and support an entirely differing processor architechture and thats the key point i was trying to make, it is possible for sure but it likely wont be pleasing to the eye or the developer I personally feel.

Sorry, when I said "you" above I didn't want to imply that I was referring to you as being the developer Fopnu. I meant in general "you", anyone.

My point is that porting to a different CPU is not the same as porting to a different platform. Having something running on Windows and porting it to Linux would indeed be a ton of work. But having something running on x86 and porting it to run on ARM is not that big of a task, because the compiler takes care of it and the same Linux libraries are already build on for both ARM and x86.

As for CPU specific features that may be unavailable on ARM, what could Fopnu be using? It doesn't use OpenGL (I checked lsof) (which is not fully supported on the raspberry yet) and Raspbian is pretty standard Debian otherwise.

I am not saying it is necessarily trivial to compile it for ARM, there may be some quirks. But I would like to hear from the devs at least which libs give them problems and what kind of problems because, usually, building standard GUI apps for Linux either on x86 or ARM makes no difference as long as you use well defined types (e.g. int32_t instead of int) which you already have to do if you are touching network code and are building for both x64 and x86 (and Fopnu does all that already).

I think your minimising the effort it would require but definitely it would be great to hear from the Fopnu developers to indicate the central issues they might find important on this topic.

they are... even arm cpus arent the same across the variants (manufacturers only licence what part of arm they need for their application) so it would have to be compiled specifically for the pi... and if it relies on any special instructions *cough*SSE2*cough* there may not be an equivalent, so even in a high level language it would require quite a rewrite...

I did think that was the case Guest, as I stated to the other guest such things appear trivial when viewed without the benefit of fine detailed knowledge but the deeper you dig into the actual implementation of the task the clearer the uphill scope of the effort becomes.

It would be fantastic to see a Pi implementation but I still believe such tasks deflect the developers focus from the platforms the majority of us use.

I really doubt it would need "quite a rewrite". Unless the developer went and wrote parts of the application in assembly and used SSE there, any other C(++) code that currently compiles to SSE instructions can be recompiled for ARM just fine without SSE.

If you have any examples of high level code that cannot compile in ARM without changing them, I'd like to know about them. Other than cases where you use a library that doesn't exist in the target system (like full OpenGL).