Slashdot Mirror

← Back to Stories (view on slashdot.org)

More Unix Tools Coming To Windows 10 (neowin.net)

Posted by EditorDavid on from the ho-ho-ho dept.

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...

9 of 123 comments (clear)

  1. Re:The very last thing I want is more bloat and mo by Soylent+Beige · · Score: 3, Informative

    Qubes Hardware Compatibility List (HCL)
    https://www.qubes-os.org/hcl/

    --
    Everyone hates me because I'm paranoid.
  2. cygwin by thinkwaitfast · · Score: 3, Informative

    https://www.cygwin.com/

    1. Re:cygwin by Anonymous Coward · · Score: 1, Informative

      You're joking, right? They don't even ship an uninstaller with that POS. Cygwin is useless trash that should be taken out back and shot. It might have been useful ten years ago but it's just trash now.

    2. Re:cygwin by squiggleslash · · Score: 3, Informative

      Works fine for me. It's actually more integrated with Windows than UFW is - you can do things like "cmd /c start ." from a bash prompt and Windows will open an Explorer window to view whatever directory you're in. Have it run OpenSSH and you can do things like remotely ssh in and shutdown or reboot the PC.

      Cygwin's only major flaw is the lack of a proper package management system (you have to run a GUI tool outside of the Cygwin environment which only half works, and there are no automatic updates.)

      UFW is more Unixy, but the price for that is a lack of good integration with the Windows side of the computer it's running under.

      --
      You are not alone. This is not normal. None of this is normal.
    3. Re:cygwin by Anonymous Coward · · Score: 2, Informative

      % uname -a
      CYGWIN_NT-10.0 hp15t 2.9.0(0.318/5/3) 2017-09-12 10:18 x86_64 Cygwin

      Seems to have been last updated 12 September 2017. And Cygwin has a package manager, download it from https://www.cygwin.com/setup-x86_64.exe and it see section 2.3 of https://www.cygwin.com/faq/faq.html#faq.setup.cli for running it on the command line.

      Cygwin compiles GAMESS (https://www.msg.chem.iastate.edu/gamess/), Dalton (http://daltonprogram.org/), Octopus (http://octopus-code.org/wiki/Main_Page), babel (http://www.ccl.net/cca/software/UNIX/babel/index.shtml), OpenBLAS (http://www.openblas.net/), and xv (http://www.sonic.net/~roelofs/greg_xv.html) just fine, and of course gnuplot 4.6 patchlevel 6 (which I maintain to avoid an annoying bug in later versions) compiles and works as well. Perfect for people who publish results, not just make bash scripts only a few people ever see.

      Compiling gcc version 7.2.0 was painless. Throw "set t_ti= t_te= syntax=none" in ~/.vimrc and
      set ignoreeof noclobber filec history=500 prompt="hp \!% "
      set cdpath=(. ~)
      along with a few other things in ~/.login and you're set for life.

  3. Re:35 year later... by arth1 · · Score: 3, Informative

    Give them a few more decades and they might finally support remote displays.

    Hah. The new generation of Linux programmers do their utmost to destroy that in Linux, with "hot corners", no lbx or X fontserver. In fact, I think you'll have a hard time with many of the "modern" Linux flavors of running anything except a video streaming application like a VNC client. At which point you might as well use Windows.

  4. Re:35 year later... by RightwingNutjob · · Score: 4, Informative

    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.

    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 ./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.

    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 ./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 sixth advantage is the big one: it works. It isn't broken. What do you gain by replacing it?

  5. Re:35 year later... by arth1 · · Score: 5, Informative

    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.

  6. Re:35 year later... by Eravnrekaree · · Score: 4, Informative

    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.