search

BOINC / boinc

Open-source software for volunteer computing and grid computing.
https://boinc.berkeley.edu
GNU Lesser General Public License v3.0
2.03k stars 449 forks source link

Port to .NET #1875

Closed adamradocz closed 5 years ago

adamradocz commented 7 years ago

Hi,

What do you think about porting the BOINC to .NET? I know it's a big project and radical change, but it could have a lot of benefits.

The new .NET standard library is very promising in term of cross platform development, and the new .NET standard 2 is even more promising. We could target all the current platforms and more (WinPC, WinPhone, UWP, Android, Mac, Linux) with nearly 100% code sharing.

Plus developing in C# could speed up the development process. Maybe I have a little bias, cause I use C# and the C++ is very farm from me, but I think it's worth to consider. Maybe there would be more developers who participate, because right now, the development cycle is rather slow.

I'm not saying drop the whole project, but start a .NET project in parallel.

Some background info: https://blogs.msdn.microsoft.com/dotnet/2016/09/26/introducing-net-standard/

dotnet-tomorrow

AenBleidd commented 7 years ago

@ChristianBeer Is this Feature Request approved? If yes - then it is connected to #1804 because it will be easier to develop UWP .NET application from scratch rather than implementing #1804 with C++ and wxWidgets.

ChristianBeer commented 7 years ago

Nothing here is approved as there is no approval process. BOINC development is not coordinated right now. I'm assigning labels to issues as I see fit myself.

davidpanderson commented 7 years ago

I'd prefer to avoid proprietary and non-open-source technologies if possible. However, if this is the only practical way to get a UWP app, we should investigate it. (for the GUI; client would remain the same).

I believe that BoincTasks (a 3rd-party Win GUI) is implemented using C#/.NET. Maybe we could use that as a starting point. BoincTasks is a power-user GUI that's far more general than the BOINC Manager (i.e. you can control multiple clients).

adamradocz commented 7 years ago

@davidpanderson The .Net Framework has been open-sourced by Microsoft. You can check it on GitHub https://github.com/dotnet and https://dotnetfoundation.org/ so it's couldn't be problem anymore.

AenBleidd commented 7 years ago

I think at this point some kind of workgroup should be created. Because if we'd decide to create C# application we need to solve many questions (e.g. architecture, priority of features). I'm interested in this because from my POV C# can give us modern UI nad more fast development.

CharlieFenton commented 7 years ago

I think this is a very bad idea for many reasons.

As far as I know, C# is used exclusively, or almost exclusively, by Microsoft Windows developers. But BOINC supports many other operating systems besides MS Windows, including UNIX and Mac OS X. I have long been the primary Mac developer, and I know that I would stop supporting BOINC if it required learning C# and becoming familiar with .NET.

I am also rather skeptical about true cross-platform support from .NET or any other framework. We have been using wxWidgets for the manager. While wxWidgets does a very good job supporting multiple platforms (operating systems), we have always found it necessary to override or fix some problems with each OS. And I believe that wxWidgets does a better job at this than most cross-platform frameworks, partly because it is open source and so benefits from contributions of many developers.

I have been developing software for over 50 years, and I have always found that maintaining parallel development projects for any software is extremely difficult, as they almost always get out of sync and develop differences that can be hard to resolve. And it would dilute the limited development manpower BOINC has by requiring each feature to be developed twice.

MS Windows supports most standard UNIX APIs, so we already have a fine cross-platform framework to use that is not tied to any specific company. Remember also that both UNIX and wxWidgets are open source. Is .NET open source, or would we be dependent on Microsoft to fix bugs? What are the license requirements to use .NET and distribute applications written using it?

davidpanderson commented 7 years ago

I generally agree. We're only talking about the GUI here. We're already supporting (sort of) 3 versions: Android, simple view, advanced view. And none of these is great from the UX/UI viewpoint. At some point we may want to make a new GUI, and it would good to unify as much as possible (i.e. the Android GUI and simple view should be the same code). .NET would be a candidate for this; we'll see what other options there are.

adamradocz commented 7 years ago

@CharlieFenton C# and the .NET standard library is pretty common scenario in mobile cross-platform development, with Xamarin or VS, and since the release of .NET Core also in Linux, Win and Mac. It also uses the platform's native API so it gives a native look and feel, but a unified UX.

As I wrote earlier, the .NET also open source, plus developing in C# would speed up the development cycle. If you don't familiar with the language, of course it won't be faster at the beginning. :)

You may won't support the project, but others might start to support it. And maybe BOINC could run on Windows Mobile as well, which doesn't have a huge market share, but still 1-2% gain in terms of user base.

CharlieFenton commented 7 years ago

We're only talking about the GUI here

From the posts I received by email, I was under the impression that we were talking about only the client, not the GUI. My email was down for a short while and I never received David's post about doing this only for the GUI. The original post only said "porting the BOINC to .NET", which to my mind meant the client.

But knowing how much work has gone into developing and debugging the BOINC Manager, I suspect that rewriting it using a different framework and programming language will be a much larger undertaking than many people may realize.

Ferroin commented 7 years ago

I would like to point out that even if it's just the GUI, that's still going to necessitate having Mono installed on any non-Windows system where the GUI is being built (and even if you choose to just use VS upstream for builds, building with Mono still needs to work because there are people who build the client locally on Linux and OS X, and you can't expect people to install Windows and VS just to build the GUI).

I'm also dubious of the claim that 'developing in C# would speed up development in general'. That very much sounds like a sales pitch and not a well thought out statement. People usually make similar claims when advocating rewriting something from scratch in a new language, but fail to remember that while they may code more efficiently in that language, the project developers probably don't, and therefore it would not improve development efficiency, but instead make development less efficient. In the particular case of C#, it may make certain types of bugs less likely, but that is not the same as speeding up development.

Silic0nS0ldier commented 7 years ago

Just thought I'd jump in and clear some things up, and add some of my thoughts to the mix.

Mono

that's still going to necessitate having Mono installed

False. .Net Standard defines an API set that is common between Xarmin, .NET Framework, and .NET Core. If development is based on .NET Core (with .NET Standard API restrictions enforced), then development can take place on all 3 major platforms by just installing the .Net Core SDK. Compilation would be done via CLI with dotnet build. There is also a cross platform editor that would fully support everything needed for .NET Core development, Visual Studio Code (with the C# extension installed).

For end users, having .NET Core libraries installed would not be required. All that would be required, is building the application to include the library in the executable file. Though it is worth noting, that currently Linux distros must be targeted individually, however this limitation will be removed with .NET Core version 2 (currently in preview).

GUI Issues arise however when we consider the GUI. .Net Core itself doesn't support desktop GUI beyond a console application. If the underlying common client side code were ported to .NET Core (with .Net Standard restrictions enforced), then it would however be possible to simply include a BOINC package (perhaps posted onto NuGET) in the list of dependencies of a cross platform system that supports GUI (like UWP, and Xaramin). Xaramin seems to be the direction that @adamradocz is leaning towards in the original post. Also worth noting there are plenty of true cross platform GUI layers out there, its just that most of the decent ones appear to the closed source.

Practicality By developing with a higher level language like C#, you are effectively further away from the 'metal', and many app store scenarios enforce sandboxing to protect the system. Given that grid computing literally involves remote code execution, some research will need to be done to determine if this is all possible within the sandboxed environments, and that it won't conflict with the policies of the various app stores. Would also need to make sure execution of the various jobs is possible under .NET Standard, it might be childs play to do in reality, but as I couldn't figure out how things are done currently, I've added this just in case.

Faster Development

I'm also dubious of the claim that 'developing in C# would speed up development in general'

@Ferroin You are right to be hesitant on this, as its impossible to be 100% sure until much later in development. However, moving to a high level managed language would substantially reduce the time spent debugging at a minimum, as things like memory leaks become much harder to create, and code being easier to follow (once familiar with the language at least). The 'barrier for entry' is also much lower, as C# is typically a language that is easier to pick up than C/C++.

.NET I suspect that there is some miscommunication regarding .NET. .NET Framework is closed source, and Windows only, it supports the .NET Standard, and has the largest number of APIs. Its still used widely used, and is required by UWP. .NET Core is open source, cross platform, supports .NET Standard, supports less APIs (but is quickly catching up), and has better performance. Through .NET Standard, lots of packages that target .NET Framework, also work with .NET Core (and vice versa).

I personally am interested in having a go at this with everyone else, if only because there is a huge potential here for me to learn (always an ulterior motive 😛). Probably best that such an undertaking take place in a separate repo too.

Ferroin commented 7 years ago

False. .Net Standard defines an API set that is common between Xarmin, .NET Framework, and .NET Core. If development is based on .NET Core (with .NET Standard API restrictions enforced), then development can take place on all 3 major platforms by just installing the .Net Core SDK. Compilation would be done via CLI with dotnet build. There is also a cross platform editor that would fully support everything needed for .NET Core development, Visual Studio Code (with the C# extension installed).

Please go back and re-read my post, I pretty explicitly said that it would need Mono on systems where you are building other than Windows because not everyone wants to use a full graphical IDE to build stuff. Additionally, unless you're building native code, you need Mono or some other runtime to be able to run .NET applications. The general consensus for systems other than Windows is that you build CIL byte-code, not native code, because that simplifies deployment.

For end users, having .NET Core libraries installed would not be required. All that would be required, is building the application to include the library in the executable file. Though it is worth noting, that currently Linux distros must be targeted individually, however this limitation will be removed with .NET Core version 2 (currently in preview).

Unless you are building a completely static executable (which is a Bad Idea for multiple reasons), then you will still need to have at least 3 targeted versions (one for glibc/eglibc, one for uClibc, and one for musl) for each architecture (if you want to remove the need for Mono or some other runtime, you will need to compile to native code, not CIL-bytecode, which means you need a build-per architecture). So, at minimum, 12 builds just for Linux, plus 2 (probably 3 or 4 in the near future) for macOS, and 4 for Windows (assuming that you don't do builds that can be manually installed without using the store).

Also, where exactly are you seeing anything about 'not needing to target specific distros in version 2'? That sounds like it should be a big enough deal that it would be listed somewhere prominent, yet I'm not seeing anything about it in any searches. Even if that is the case though, that still doesn't take into account that BOINC itself may need to care in some cases about differences between distros (init system for example).

On a third note, this has the potential to effectively kill PPC and SPARC support (.NET Core does not support them, and likely never will without significant community effort, which I don't think is all that likely to be forthcoming (adding a new distribution is pretty easy, adding a new architecture is not)), and the same may also go for specific Linux distros and other platforms (only a few Linux distros are supported (this probably doesn't matter much though), BSD support is currently non-functional, no Android support, no visible iOS support, no other platforms except Tizen (but I doubt anyone using BOINC cares about Tizen)).

You are right to be hesitant on this, as its impossible to be 100% sure until much later in development. However, moving to a high level managed language would substantially reduce the time spent debugging at a minimum, as things like memory leaks become much harder to create, and code being easier to follow (once familiar with the language at least). The 'barrier for entry' is also much lower, as C# is typically a language that is easier to pick up than C/C++.

The same arguments can be made for switching to almost anything, including such ridiculous options as Perl and Java (except possibly the easier to pick up aspect). I'll reiterate the standard counter-argument: Increased safety means decreased efficiency. With limited exceptions, the more you do to protect against bugs at the linguistic level, the less efficient your code will be, and therefore the more time you have to spend optimizing it to get the same degree of efficiency. BOINC is a distributed computing client, which means it should ideally be as efficient as reasonably possible. The more time you spend in a language's runtime, the less time you can actually run computations (and the more impact you have on the rest of the client system).

Silic0nS0ldier commented 7 years ago

Please go back and re-read my post, I pretty explicitly said that it would need Mono on systems where you are building other than Windows because not everyone wants to use a full graphical IDE to build stuff. Additionally, unless you're building native code, you need Mono or some other runtime to be able to run .NET applications. The general consensus for systems other than Windows is that you build CIL byte-code, not native code, because that simplifies deployment.

.Net Core is fully cross platform. Development via CLI is fully supported. Mono was built to provide a cross platform version of the .Net Framework, of which .Net Core is not. It is independent. A .Net Core application can use the .Net Framework (which would make it locked to Windows/Mono), but it is not a requirement.

Regarding quote 2, android is supported (supported runtimes), it does not compile down to native (execution is done up first starting .Net Core, which then executes the CIL), the 'Linux as a build target' news came from here ("You can build apps that target Linux as a single operating system."), and in terms of iOS support (and for that matter, Android), while not directly executable, it can be used via Xaramin.

Obviously, there are platforms that don't support it in any form, but for the most part .Net Core has a large spread in terms of devices it can reach. Ideally, the more platforms that can be targeted, the more devices that would likely be contributing, the more processing power can be donated. Will it outweigh the current C++ optimised spread, I don't know. That would require statistics, and polling (which in itself would be biased, as most participants likely wouldn't have even known about this projects existence, to be frank).

Obviously there are pros and cons. I'm not saying .Net Core is fundamentally better, I'm saying its more portable.

Wait... Don't the jobs run independent of the BOINC client?

AenBleidd commented 6 years ago

Re implementing any part of BOINC application from scratch requires big effort. There is no reason to do it now or in near future because both current client and Manager are available for all platforms that could run BOINC (WinPhones are dead, iPhones/iPads have OS limitations that prevent running COU-intensive applications in background). Closing for now

adamradocz commented 5 years ago

I started to reimplement the BOINC Manager in .NET Core. I'd say it's 75% production ready after 2 weeks of development. It shows all the information from the Client and can interact with it, but the settings are not implemented. I used the MVVM framework, so the future ports for other platforms will be very fast. I'd like to move the code to the BOINC repo, so others can contribute too. It doesn't have to be in the main repository, because there aren't any dependency on it, so the main BOINC repo could be more modular.

Extra feature:

CharlieFenton commented 5 years ago

For developers who are not MS Windows programmers, what is the advantage of this? Although I have heard that Microsoft has provided .NET support for Macintosh (and perhaps for Linux and the other platforms we support), I am skeptical that there won't be issues that need to be worked around.

Building applications on the Mac without using Apple's development environment would be challenging, if not impossible. That alone makes the cross-platform claims for .NET highly questionable. Even using C++ throughout most of the Manager, there are a number of things I've had to implement using Cocoa in order to get the Manager working on Macintosh. C# is not supported by Xcode.

Note that the current Mac port of WxWidgets is written to make the Manager appear to Mac OS X as a Cocoa application. Cocoa / Objective-C code integrates seamlessly with C++; from a cursory web search calling native Mac (Cocoa) code from .NET is difficult at best and may not even be possible without something called MonoMac or similar.

I'm sorry, but I have little patience for the idea that Microsoft's approach to software should be considered a universal standard. (Nor do I feel that Apple's approach should be, or any other company's proprietary "standard", for that matter.)

adamradocz commented 5 years ago

@CharlieFenton Currently the .NET Core supports native GUI for Windows, Android, and iOS. There is a 3rd party opensource cross-platform UI framework called Avalonia for Mac, Linux, and Windows too.

At the moment the Android development is a nightmare, and this could be a solution for that too.

Ferroin commented 5 years ago

I would like to point out again that a shift to C#, even for just the manager, is going to be a pain in the arse for anyone who is building locally. You can trivially build all of BOINC right now with the standard development environment on any of the platforms it supports, typically with exactly zero other software needing to be installed. That will cease to be the case for everything but Windows if part of it gets re-written in C#.

.NET Core just makes that even worse, given that it:

AenBleidd commented 5 years ago

@Ferroin, it still can be hosted in a different repo. So it will not affect anyone. And even if it will be added to this particular repo it could be disabled by default. So there are many options to make most of the people a little bit more happier ;)

CharlieFenton commented 5 years ago

Thank you @adamradocz, but you have not answered my questions or concerns.

For developers who are not MS Windows programmers, what is the advantage of this?

Few developers who don't write Windows code know the C# language or the .NET APIs, just as few non-Macintosh developers know Objective-C or the Cocoa APIs. While we already have a number of developers supporting BOINC on Windows and Linux, I am still the only one supporting Macintosh, and I wish to wind down my participation. I want to recruit new Mac developers so I don't leave BOINC unsupported on the Mac, and am prepared to offer them help to get up to speed.

If we are totally switching the Manager's language and API set, I won't be able to do that, and I am certainly not willing to learn either C# or .NET. If we require Mac developers to learn the C# language, it will make it even harder to recruit any.

http://avaloniaui.net says they are currently in a beta phase, so it sounds like a high risk platform. It currently supports onlyVisual Studio 2017 and .NET core, not Xcode or GNU compilers. Also, it says:

Avalonia uses a XAML dialect that should feel immediately familiar to anyone coming from WPF, UWP and Xamarin Forms.

None of those are familiar to me nor, I suspect, to most Mac or Linux developers.

Nor have you responded to my concern that C# is not supported by Apple's Xcode development system.

At the moment the Android development is a nightmare, and this could be a solution for that too.

Using the same GUI design for small screen devices like phones as for desktop computers does not seem practical to me.

adamradocz commented 5 years ago

Nor have you responded to my concern that C# is not supported by Apple's Xcode development system.

I don't know anything about Apple's Xcode, but I assume it doesn't support c#. You have to use the Visual Studio Code, which is the cross-platform version of the Visual Studio.

Using the same GUI design for small screen devices like phones as for desktop computers does not seem practical to me.

I'm not saying to use the same UI. In MVVM the model part can be a separate dll, so only the UI have to be rewriten. Currently the Android project is completely separated from everything else.

If we are totally switching the Manager's language and API set, I won't be able to do that, and I am certainly not willing to learn either C# or .NET. If we require Mac developers to learn the C# language, it will make it even harder to recruit any.

I'm not suying it's the perfect solution, but as you pointed out there's no Mac developer anyway. BTW no Android developer either, and new features barely impemented. The multi-host feature request is 2 years old (#1759) and doesn't seem to be implemented in the near future. In c# I could implemented it fairly quickly. I get your concerns, and you're right about it. I just want to move forward thing, that are stuck now.

Ferroin commented 5 years ago

I'm not suying it's the perfect solution, but as you pointed out there's no Mac developer anyway. BTW no Android developer either, and new features barely impemented. The multi-host feature request is 2 years old (#1759) and doesn't seem to be implemented in the near future. In c# I could implemented it fairly quickly. I get your concerns, and you're right about it. I just want to move forward thing, that are stuck now.

Not trying to be a jerk, but had you considered trying to learn C++ instead of forcing everyone else to learn C#? That would avoid all the issues with converting to C# as well as not risking alienating the other developers.

Or even just creating your own third-party GUI possibly?

Again, pretty much all of the arguments being made in favor of this show no particular requirement for the language to be C#. Yes, you may be able to implement features quickly if it were rewritten in C#. So could I if it were rewritten as a standalone serverless web app (and that would solve the issues of the disjoint Android code base without forcing other platforms to be dropped), but you don't see me proposing that here, because it also has the same core issue that it makes life difficult for the people who are already developing the existing code base (and I actually am planning on writing a web-app to do this in the near future, all the existing ones are defunct and/or a pain to set up).

adamradocz commented 5 years ago

@Ferroin I'm not forcing anything, I'm giving the possibility to others to join to develop it. I'm not saying we have to switch now. Plus, you don't consider the possibility that the C++ could alienate other people too.

Or even just creating your own third-party GUI possibly?

At the moment this is it, and it looks like it will be.

I actually am planning on writing a web-app

Me too. If you wish you can join me.

ststeiger commented 5 years ago

I haven't seen the BOINC client, but may I suggest: