Closed ghost closed 4 years ago
ghost
commented
5 years ago If someone wanted to convert Fuzzball into a genuinely portable C program, that'd be fine with me. But it being a portable Unix program with an intrusive Windows port tacked on is unsavory.
ghost
commented
5 years ago There's no benefit to having this port either, because WSL exists, and this port doesn't genuinely make Fuzzball more portable.
ghost
commented
5 years ago There'd also be nothing stopping a downstream project from making a native Windows build, either, so it wouldn't be the end of the world for them.
tanabi
commented
5 years ago I think we should continue to build a windows binary. If that windows binary only runs on Windows 10 with WSL or whatever, I'm cool with that. However, I do not have Windows 10 so this isn't something I can help with. Since I'm the only person who's stepped up to help with Windows (just have been working on documentation first) eliminating my ability to work on it probably isn't great :D
Now, you have argued that Windows lusers should step up if they want to be supported, and contribute. Or they should just run Linux in some capacity or another, i.e. via VM or on the cloud for $5/mo or what-have-you.
Well, you gotta understand, there's a barrier to entry here.
Why is it in fuzzball's interest to support them? Because the whole point of a MUCK is to communicate and create. And if you want to learn MUF, or you want to learn to build, or you want to make your own place, you have to start somewhere. And if I'm a windows user that is passionate about MUCKing but really don't know where to start, if I see the mountain I've gotta climb to do this thing, then I may just flip the table and go play Second Life. :)
We want MUCKs to be attainable to anybody who wants to attain them. There was an incredible effort to support windows, and it would be an incredible effort to remove that support, just to make it harder for people to use. Why would we do that?
Besides, MUCKs can be a gateway to wanting to learn Linux. You start on your windows PC, you realize you need a proper server to run your dream MUCK, maybe you learn Linux. I've actually known this to happen at least once. Pretty cool I think.
Anyway -- when we are able to support Windows 10 I am happy to look into WSL, but unless someone who has Windows 10 can experiment and make sure it works, I think we should keep it how it is.
wyld-sw
commented
5 years ago I've had success with compiling the UNIX binary in WSL, and connecting. DIdn't try anything fancy, or connecting from outside the network, though.
If this is an acceptable alternative to a separate Windows build, I'd be happy to participate in testing.
tanabi
commented
5 years ago I've had success with compiling the UNIX binary in WSL, and connecting. DIdn't try anything fancy, or connecting from outside the network, though.
If this is an acceptable alternative to a separate Windows build, I'd be happy to participate in testing.
Is there anything special you had to do to get it to work? Is there a way to build and package it? Barrier to entry! :)
wyld-sw
commented
5 years ago I may have needed to apt-get the dev tools - but other than that, I don't remember any major hurdles.
If I get time, I can put together a document on what steps I took.
tanabi
commented
5 years ago I may have needed to apt-get the dev tools - but other than that, I don't remember any major hurdles.
If I get time, I can put together a document on what steps I took.
Yeah ... if this is something we can just provide somehow or another and make it relatively easy, I'm all for it.
ghost
commented
5 years ago I think we should continue to build a windows binary. If that windows binary only runs on Windows 10 with WSL or whatever, I'm cool with that. However, I do not have Windows 10 so this isn't something I can help with. Since I'm the only person who's stepped up to help with Windows (just have been working on documentation first) eliminating my ability to work on it probably isn't great :D
If that windows binary only runs on Windows 10 with WSL or whatever, I'm cool with that Great. This means all we need to do is get Fuzzball packaged in Debian. Then it'll inherently be packaged in the default WSL distro, Ubuntu, and thus, available as a binary on Windows. eliminating my ability to work on it probably isn't great True, however, since WSL is supposed to work identically with real GNU/Linux, it means as long as you can still work on Fuzzball on GNU/Linux, your ability to work on it isn't eliminated.
Now, you have argued that Windows lusers should step up if they want to be supported, and contribute. Or they should just run Linux in some capacity or another, i.e. via VM or on the cloud for $5/mo or what-have-you.
Well, you gotta understand, there's a barrier to entry here.
- Not everybody knows UNIX
- Not everybody is technical enough to learn it, or willing to do so just to run a MUCK.
- Windows users, on average, are not highly technical nor are they accustomed to contributing to software.
- Because they are not technical, even if they wanted to contribute, they may not be able to without expending more effort than is honestly reasonable -- it is really easy for us to throw C code around and say 'oh just compile it, its easy!' but we're the exception, not the rule.
- Windows users, on average, are already terrified near to the point of paralysis if they wind up on a GITHUB page.
I agree with all this.
- Despite all that, it is in Fuzzball's interest to continue to support them.
Yet I don't agree with this. (my next sentence says why)
Why is it in fuzzball's interest to support them? Because the whole point of a MUCK is to communicate and create. And if you want to learn MUF, or you want to learn to build, or you want to make your own place, you have to start somewhere. And if I'm a windows user that is passionate about MUCKing but really don't know where to start, if I see the mountain I've gotta climb to do this thing, then I may just flip the table and go play Second Life. :)
Wellllll, the thing is, they can still connect to MUCKs running on Unix servers, with their Windows MUCK clients. Even if there's no native Windows binary, they can still build, they can still MPI, they can still MUF, all on the servers they already connect to. (And servers they run, with WSL!) The only thing affected would be the ability for people to run servers on Windows installations that for some reason lack WSL.
We want MUCKs to be attainable to anybody who wants to attain them. There was an incredible effort to support windows, and it would be an incredible effort to remove that support, just to make it harder for people to use. Why would we do that?
I don't think it becomes harder to use. I also think measuring things from effort put in isn't good. Quality > effort put in. (Work smart, not hard. sunken cost fallacy. etc) I do agree though, MUCKing should be attainable for everyone... It's such a beautiful thing, a beautiful technology and experience. I just don't think Windows installs without WSL need to be catered to, for the purpose of installing and running a MUCK.
Besides, MUCKs can be a gateway to wanting to learn Linux. You start on your windows PC, you realize you need a proper server to run your dream MUCK, maybe you learn Linux. I've actually known this to happen at least once. Pretty cool I think.
*nod*!
Anyway -- when we are able to support Windows 10 I am happy to look into WSL, but unless someone who has Windows 10 can experiment and make sure it works, I think we should keep it how it is.
I have Windows 10, but I no longer use it as anything but a vidyagaemconsole. I'd be willing to install WSL again if necessary to prove WSL runs Fuzzball just like Ubuntu does.
If this is an acceptable alternative to a separate Windows build, I'd be happy to participate in testing.
I think it is. :D WSL is gratis with every currently-up-to-date Windows install! Only very old Windows installs don't have it.
Yeah ... if this is something we can just provide somehow or another and make it relatively easy, I'm all for it.
Making a Debian package! :D Then they'd only have to apt install fbmuck I should probably make an issue about packaging, itself. Lemme check if I've maybe already done that, since I know it's been a big thing me and @wyld-sw hope for.
wyld-sw
commented
5 years ago Thanks, @nyanster. Let me know if you're waiting for me for any package-related things.
tanabi
commented
5 years ago If we can make it an 'install WSL, type apt-get install fuzzball' or whatever kind of thing, I'm all for removing the windows specific stuff
ghost
commented
5 years ago Thanks, @nyanster. Let me know if you're waiting for me for any package-related things.
I'm mostly waiting on myself to JUST DO IT~ Since it's on my mind, tonight I'll see what includes I can remove from config.h, and see what I can move from config.h to fbmuck.h: this is a good step towards autoconf removal, which is optional but beneficial for packaging. Technically, we could package Fuzzball today. It's something that can happen whenever we want.
If we can make it an 'install WSL, type apt-get install fuzzball' or whatever kind of thing, I'm all for removing the windows specific stuff
This is exactly what I aim for, and it is possible and attainable!
ghost
commented
5 years ago Packaging Fuzzball on Debian is now a TODO before removing native Windows support. https://github.com/fuzzball-muck/fuzzball/issues/381
wyld-sw
commented
5 years ago I just spun up a Windows 10 VM and enabled the WSL feature.
After installing Debian from the Windows Store, I apt installed the packages libpcre3-dev, libssl-dev, git, and make.
I successfully cloned the repository, configured, built, copied starter databases into place, and restarted - all as you would expect.
I could connect (with and without TLS) from both Debian and the hosted Windows. I did not try connecting from the outside - though "localhost" did get me there both times, which is a good sign.
tanabi
commented
5 years ago Action items for removing windows specific stuff:
foxbird
commented
5 years ago FWIW, a lot of this depends on what your goal is running FuzzBall on windows. If you're doing it to develop or play around, then WSL is fine for working with as it supports this need. However, WSL specifically says it's not for running services, for doing anything long term, production, or otherwise a reliable fixture. It's primary and really only goal is to enable the use of various unix tools for developers to be able work with the given toolchains and open source applications. As such, I don't think it's a suitable long-term replacement for a native binary build.
You could also argue that no one who wants to run a MUCK would ever run a windows box for a host, but again, it depends on your goals and what you have available to you.
I forked fuzzball into WinFuzz a long time ago and kept up with the major releases by building a binary for each and releasing. The desire by a lot of people was to bring it back into the fold, so we worked to do that. Apparently the pendulum swings the other way now. If so, I'll be happy to keep doing what I did before. Provided this project ever gets to actually doing regular releases.
wyld-sw
commented
4 years ago Closing for inactivity.
I'd like a serious discussion on continuing or ending support for Windows. I think it's baggage that burdens all the current developers, despite none of the current developers using Windows. No-one who uses Windows is stepping up to solve the Windows-related technical debt, and I don't think that burden should be shifted onto me, wyld, tanabi, or anyone else. Windows Subsystem for Linux exists, Cygwin exists, MinGW exists. The Windows port is intrusive and puts code and ifdefs all over the place. It extends far beyond the reach of the win32/ folder, by affecting the src/ and include/ folders too. It affects the way we code the entire program. Anyone who wants to run it on Windows can just install WSL with no additional cost. Removing the Windows port would heavily simplify everything and eliminate the associated mental/effort/time burden.