Apologies, I have not been involved in this process for a few years, but I saw this topic pass by and thought I would like to comment.
I’m a lecturer in computer science and used C* in a couple of dev classes, some of you may remember we ran a couple of Hackday’s with Datastax. Students would develop projects using C* in order to learn NoSQL databases. Many had to run on their own laptops and usually under windows, which was a pain. I’ve since moved to using C* under Docker on Gcloud for teaching which removes most of the pain, once students get used to using cloud services. My point is, for educational purposes there are plenty of other ways of running small dev clusters that are probably more realistic for most uses cases. I’d be for removing windows support, but I suspect my use case is one of the more minor ones. Andy From: Joshua McKenzie <jmcken...@apache.org> Date: Thursday, 30 July 2020 at 15:56 To: dev@cassandra.apache.org <dev@cassandra.apache.org> Subject: Re: [Discussion] Windows support > > I think that not supporting Windows for local dev environments would make > it harder for developers to get started with Apache Cassandra > I was the one that got Windows fully supported in 2014/2015 for context. I say we pull support out. The way NTFS treats hard links (i.e. inability to delete junctions if someone has a handle open to them even w/the right flags if the file is memory mapped) is just a major headache in terms of the way C*'s file I/O operates. It leads to a large number of edge cases and quirks in the way things operate on Windows that largely manifest as a support burden for the project community when there's a clearly superior dev alternative available in WSL. The "we'll keep a list of files that got locked and delete them on next startup" plus the complete necessary disabling of early open are two major things I'm wary of in terms of doing development work on C* and having faith that the behavioral characteristics will translate cleanly to a linux env. I also would not advise running C* on a production environment on Windows Server at this point; Microsoft's strategic embrace of linux makes the need for that support basically vestigial. I've been on WSL since 1.0 fwiw and 2.0 only improves on that experience. So my point of view: doing dev on Windows w/the plethora of I/O based edge cases today is a worse user experience than having a very smooth "here's how to get started with WSL" on-ramp for users. The former consigns them to a never-ending risk of disruption and disjoint from deployment env, while the latter is one up-front fixed cost to have pain-free development going forward. DataStax Desktop also makes that even easier fwiw, but I'd advocate for us just improving our docs and having a "Developing on Windows? Here's how to set up WSL" w/screenshots and an easy "get started in < 5 minutes" guide. On Wed, Jul 29, 2020 at 11:49 AM João Reis <joao.r.r...@outlook.com> wrote: > Personally I still use CCM on windows pretty often and the C# driver even > has an appveyor job that runs tests with CCM on windows (the drivers smoke > tests job does this as well). Setting up clusters with multiple nodes is > not that easy with Docker and WSL 2 because the nodes run inside a VM. > > In regards to WSL2, Microsoft has been improving the user experience for > these use cases so I'm not sure how easy it is to set up these clusters > with recent windows builds. WSL1 does not run inside a VM so there's no > issues there. > > I think that not supporting Windows for local dev environments would make > it harder for developers to get started with Apache Cassandra but if the > community decides to completely drop Windows support then we should offer > some kind of documentation on how to run Cassandra with WSL / Docker on > Windows (currently there's no documentation for Windows users AFAIK). > > Yuki Morishita <yu...@apache.org> escreveu no dia quarta, 29/07/2020 à(s) > 02:40: > > > Hi, > > > > I'd like to raise my concern about Windows support, as we are getting > > closer to 4.0 release. > > > > Since the support for JDK11 (CASSANDRA-9608), Windows script to start > > Cassandra is broken. > > The fix for the script is posted to > > https://issues.apache.org/jira/projects/CASSANDRA/issues/CASSANDRA-14608 > . > > > > Windows scripts are not maintained recently, and I don't think we have > > any Windows environment in CI for testing. > > I don't think it is a good idea to release Apache Cassandra with > > broken Windows scripts. > > > > With the latest update of Windows 10, even the Windows 10 Home edition > > users can use Docker for Windows if they enable WSL2 in their machine. > > However, the update is not yet available for everyone, and I believe > > many Enterprises hold onto upgrading to the latest version. Even if > > they do so, they can disable WSL2 from using. Some companies may not > > allow installing VirtualBox either. > > > > So, what we can do for 4.0 release: > > > > - Stop supporting Windows. Remove every bat/ps1 scripts from the > > source and distribution. Encourage Windows users to use VM/Docker. > > - Continue supporting Windows. Set up Windows test environment. Test > > every Windows scripts for future releases. > > > > Since I saw enterprises with restricted dev environments (and saw > > people trying to use cassandra on Windows on StackOverflow), I want to > > have Windows scripts ready to be used. > > But I'm also fine if we decide to remove all Windows scripts since I > > use Docker anyway. > > > > Regards, > > Yuki > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > > The University of Dundee is a registered Scottish Charity, No: SC015096
