Whenever I try to use grub-mkrescue with cygwin(I have built everything needed before, but grub was a 50/50 would be nice to get the correct files for that), and whenever I try to use it it says it doesn't exist

Is there any reason to believe that they will support it long term? One person's reasoning and the reasoning of the directors and marketing department of corporation like Microsoft can differ significantly. They barely sustain their own platform commitments long term. I understand that they have dubbed WSL "for developers", which can be an indication that it is commercially irrelevant for them and thus fair game.

Cygwin currently provides necessary batch processing tools that are lacking in the Windows environment. To do the same with a VM, you have to setup Samba or something similar over a virtual bridge, which is slow and painful. Unless some of the VMs provides some kind of paravirtualized FS driver by now. I agree that WSL is the better technological principle, but if Cygwin loses traction because of it, and gets outdated/unreliable, and then Microsoft discontinues WSL, the situation will be very uncomfortable. GnuWin32 is another alternative, but the same applies to them as well.

Sure, Cygwin might eventually get abandoned but I wouldn't cry too much over it. There won't be a crisis for people relying on it because there is always the option of simply running Linux either natively or in a VM (the VM tools are actually a lot better than you suggest)*. I tend to do that anyway because Cygwin doesn't support Valgrind---I am not sure whether it works with WSL but I really hope that it does. As far as the usual UNIX tools go, they were always part of the SFU/SUA deal but usually lagged behind in terms of package versions.

* If there is even a tiny lesson in all this potential switching around, it's that it's a good idea not to use implementation-specific features unless you really need them. If your shell scripts, makefiles, etc. are portable, you never have to be too afraid that things will break when changing tools.

_________________"Computers in the future may weigh no more than 1.5 tons.", Popular Mechanics (1949)[ Project UDI ]

Sure, Cygwin might eventually get abandoned but I wouldn't cry too much over it. There won't be a crisis for people relying on it because there is always the option of simply running Linux either natively or in a VM (the VM tools are actually a lot better than you suggest)*. I tend to do that anyway because Cygwin doesn't support Valgrind---I am not sure whether it works with WSL but I really hope that it does.

There is no substitute for a proper linux install when it comes to development for the linux platform. I can't argue there. Also, VS is practically necessary for professional windows work, whereas the mingw gcc build covers casual windows development. What I meant is that cygwin provides the ability to use linux scripting on windows filesystems. If WSL and cygwin both disappear, as far as I am concerned, there will be no comparable environment for batch text and file processing on windows anymore. Anyway, time will tell.

Is there any reason to believe that they will support it long term? One person's reasoning and the reasoning of the directors and marketing department of corporation like Microsoft can differ significantly. They barely sustain their own platform commitments long term. I understand that they have dubbed WSL "for developers", which can be an indication that it is commercially irrelevant for them and thus fair game.

Cygwin currently provides necessary batch processing tools that are lacking in the Windows environment. To do the same with a VM, you have to setup Samba or something similar over a virtual bridge, which is slow and painful. Unless some of the VMs provides some kind of paravirtualized FS driver by now. I agree that WSL is the better technological principle, but if Cygwin loses traction because of it, and gets outdated/unreliable, and then Microsoft discontinues WSL, the situation will be very uncomfortable. GnuWin32 is another alternative, but the same applies to them as well.

They re-engineered an entire section of their kernel solely to support the microcontainer platform it runs on. And I know there are people in the Windows team who use it in their day to day.

They re-engineered an entire section of their kernel solely to support the microcontainer platform it runs on.

According to wikipedia they had plans to create Android middleware for Windows Mobile, which probably started the kernel reorganization already. From which WSL remained as a byproduct.

Kazinsal wrote:

And I know there are people in the Windows team who use it in their day to day.

All right, but you yourself stated that Linux VMs offer viable (if not better) alternative for most tasks. WSL and similar environments address specific needs that are probably not considered high priority for the Windows market. And the Windows teams have lived and worked without the technology for a long time, so it must not have been such a vital necessity. In that sense, I doubt that the company would go out of its way to support it. Besides, if the idea proves unproductive for MS's marketing goals, they can discontinue WSL or leave the public with outdated variant and still maintain it internally, for example.

Kazinsal wrote:

I suspect it'll be around for a very long time.

May be. Who knows. Mind you, I don't dislike the company nearly as much as some folk. I favor their OS's design in some ways (and not in others). But as I said, I don't trust their consistency.

The option to install the feature is still marked as "beta", but the whole system works extremely well for me. The cross-compiler tutorial works perfectly on it.

The only "catch" I can see is that if you are using an IDE in windows, there are problems with files in the Linux filesystem not being marked as updated. The very simple solution for me has been to "ln" somewhere in /mnt/c to somewhere in ~/. This means that Windows and WSL see the same files.

Yes, that is an important thing to know about LXSS/WSL: do not modify the LXSS filesystem in AppData with Win32 apps. This fails to keep the NTFS extended attributes applied to the files themselves, and fails to update the ones on the containing folder, meaning that WSL doesn't actually get informed that the files are even there. It's like you're writing data to the disk, and you're telling the block tree that you're using that data, but you're not actually adding any of the metadata.

Do what AJ said and symlink your working directory in NTFS/ReFS/whatever your Win32 space is formatted as to a point in your home directory.

Who is online

Users browsing this forum: No registered users and 1 guest

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum