Slashdot Mirror
More Unix Tools Coming To Windows 10 (neowin.net)
Long-time Slashdot reader Billly Gates brings news about beta 4 of Redstone (the Spring version of Windows 10's Creators Update for 2018):
- Beta 4 of Redstone aka Build 17063 includes BSD utilities bsdtar and curl from the command prompt and Unix sockets (AF_Unix). These are also rumored to be part of a future version of Windows Server.
- WSL will now run background tasks and will continue to run them even after the command prompt window is closed...
- A previous story mentioned a discovered OpenSSH for Windows... OpenSSH and VPN can now be accessed via PowerShell in remote connections via the PSRemote commandlet. With the extra background support added you can for example keep a Secure Shell session open on a server/client and reconnect later.
- Also a tool is available called WSLPath to convert Linux to Windows path options
There will also be some graphical Windows Shell improvements with Microsoft's design language, and "Timeline," a new way to resume past activities...
- WSL will now run background tasks and will continue to run them even after the command prompt window is closed...
- A previous story mentioned a discovered OpenSSH for Windows... OpenSSH and VPN can now be accessed via PowerShell in remote connections via the PSRemote commandlet. With the extra background support added you can for example keep a Secure Shell session open on a server/client and reconnect later.
- Also a tool is available called WSLPath to convert Linux to Windows path options
There will also be some graphical Windows Shell improvements with Microsoft's design language, and "Timeline," a new way to resume past activities...
Nobody is being forced to install the Linux subsystem for Windows. Only people who want it. For me it makes Windows a lot more tolerable, and it means I don't have to give up my familiar tools when I boot into that environment.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
Will 2018 be the year of Windows on the command line?
"Those who do not understand Unix are condemned to reinvent it, poorly."
If you're a zombie and you know it, bite your friend!
The first advantage is that you can ssh into a machine on the opposite side of the building (or the country, or the world) and run a graphical program on your own machine. If that program is written using proper X techniques (essentially vector graphics), then the bandwidth requirements and latency are lower and the quality is higher than if you are using VNC that has to render the window completely on the server end, compress it, send it over, and decompress it to display on your end.
./foobar and have the program display on the other machine without any intervention on that other machine. This is more of a niche use, but it is very useful for remote information displays and control rooms. It's a good alternative to the Windows paradigm of adding another graphics card and manually starting a full screen display program and hoping it ends up on the correct remote display.
./graphical_program, the same way as you would redirect it to any other display. This works because the X protocol is shared by both.
The second advantage is that you don't need to remote in. On a high-speed network that you might have in the office, you can say DISPLAY=otherbox:0
The third advantage is that programs written thirty years ago will display correctly and do not need to be recompiled or rewritten to play with the latest and greatest fad. Wayland, Unity, what else is there? SystemD is bound to have a display server pop up at some point.
The fourth advantage is that it works out of the box without requiring (or inviting) a bunch of third-party garbage that's only compatible with itself, costs money, and is fragile by virtue of existing to establish vendor lock-in rather than accomplishing a task.
The fifth advantage is that you can turn graphical applications into background processes by using Xvfb, which you can start as a user process and use via DISPLAY=localhost:NN
The sixth advantage is the big one: it works. It isn't broken. What do you gain by replacing it?
Unless Microsoft starts pumping out MS Unix with a Windows front end, none of the reasons for using Linux, BSD, or another Unix go away. This just seems like it would be cosmetic stuff for geeks who are used to being able to awk grep and sed their way out of most problems.
3 things:
1. MS is scared of competition. Their biggest nightmare has come true not from Linux, but from Mobile. If they do not stay relevent people won't buy win32 based apps or Windows
2. Visual Studio was in trouble as the cool kids use node.js, android and IOS development tools there is less demand for Visual Sudio and win32 desktop development. Good Android Studio, IntelJ, and even xcode are all knocking on Microsoft's doorstep
3. Virtual Machines are a pain for non I.T. professionals to configure and consume lots of resources
So Ubuntu and now Suse for Windows gives you the Linux command set. You can even use Debian tools like 'tasksel' to configure a whole LAMP stack and apt-get install npm from bash.exe and have a whole development environment FAST. If you mess something up just uninstall and reinstall Ubuntu/Suse from the appstore or add/remove features and start over.
These updates make it easier to cut and paste SMB and Linux paths and are nice when SSH into servers.
Visual Studio also has Android emulators that use Hyper-V underneath and include CLANG and other compilers if you go into options to help OpenSource and mobile developers. No you did not misread that!
What it shows is in 2017 that MS realized they are no longer IBM anymore. Times change and they want to remain relevant.
Ms also wants to host Linux and FreeBSD servers in Azure as well. I guess this is reason 3.5. As long as they get paid they do not give a shit what OS you use as to MS the platform is not Windows anymore. It is Azure and Windows or Linux are just one of it's layers that run on top. But that is semi unrelated to WSL but explains why VS is warming up to Linux as well.
Competition is good and as MS is very unpopular here, I have to say Apple scared me worse when Jobs was in charge when they started getting powerful. Just think what would happen if MacOS won the 1980s OS wars instead of Windows?
http://saveie6.com/
Another few:
- Remote X works with your window manager. You can choose which windows overlap others, not entire displays. You can minimize them as other window. You can move individual windows between different screens. Dock them.
- Remote X works with your X clipboard. I can mark and paste into or from a remote X window.
- Moving windows around isn't laggy. The graphics primitives are cached (especially with lbx) and do not have to be re-sent as you move a window.
- You don't get blurry text when the subpixel rendering differs between different machines. Because the text is rendered in your own display.
- You don't get flyspeck when the remote side is a much higher DPI than the local side. Or obnoxiously large text when it's the other way around. Because the X server is on your local machine, you are in control.
X11 is a vector protocol unlike VNC. If you use GLX over the X11 protocol, an app can send 3D OpenGL commands over the X connection over a network, this allows you to run apps on a different computer and display them to another computer and do it with a faster speed than a raster protocol. So X protocol isnt just for 2D, and its not outdated therefore, it has been able to do full 3D graphics for a very long time.
Once upon a time the fonts were rendered on the X server, the X client could just send the text and the server would render it. For whatever reason, they decided to change this. This was around the time the Render extension happened. This caused clients to switch to sending font bitmaps to the server and then composite the bitmaps together on the server for alpha transparency support. Alpha transparency could have been implemented on the server side font model, but they chose not to do this. There are some applications for the Render extension for fonts which are used inside a web page and for sending images to the X server and being able to reuse fonts and images on composite operations on the server without having to upload rasterized images everytime the applications window content layout changes, this could actually save resources for network transparency.
One thing that could have been done is to allow uploading of PNGs, JPGs and TTFs to the X server and have the X server rasterize them, this would make things work better over network connections, and allow the client to choose to use server side font rasteration with alpha transparency if the server has the font it needs. As others have mentioned, there was an X Font Server as well which the X server could download remote fonts from.
One of the things we hear from Wayland proponents is X11 hasnt been network transparent. This is not true, even Render should be useable over a network connection since you can upload your images to the server and composite them together on the server, GLX is certainly network transparent. Clients are supposed to be written so they fall back to sending any image data over the socket if shared memory is used. So shared memory while not useable for network transparency does not conflict with it since the client just falls back to sending image data over the wire.
X11 is more flexible than VNC since you can export single applications between different desktop sessions. There are even tools to move an X program from one X server to another so you can switch which computer or display an X program is displayed too. There are X based remote desktop tools. There were even programs like XMX that allowed you to multiplex an X application to multiple X servers simultaneously.
The legacy support in X does not consume a significant amount of resources, its very insignificant, so thats a false canard that should be soundly refuted. The core X protocol graphics primitives are simple and few in number so it takes little code to implement them. Increasingly, as well, there is a move to transition the X servers backend to use OpenGL mesa drivers so the X server will use the same drivers as the DRI programs, so these X 2D primatives will be rendered by the OpenGL driver code, which will avoid driver duplication and means the X 2D primatives and the 3D be rendered by the same code and drivers anyway, so the legacy X protocol support really does not use a significant amount of resources.