Language Selection

English French German Italian Portuguese Spanish

A Look At The Windows 10 October 2018 Update Performance With WSL

Filed under

As the first of our Linux vs. Windows benchmarks coming around Microsoft's Windows 10 October 2018 Update, today we are exploring the Windows Subsystem for Linux (WSL) performance to see if they have finally managed to improve the I/O performance for this Linux binary compatibility layer and how the WSL performs compared to Ubuntu and Clear Linux.

For those that have missed my previous rounds of Windows Subsystem for Linux (WSL) benchmarking, this Linux binary compatibility layer for Windows is surprisingly performant for most workloads... Microsoft all around has done a surprisingly good job on WSL with its support and performance. The big exception to the strong WSL performance though has been for I/O workloads struggling a great deal due to WSL needing to track the various meta-data separately, backing the I/O by their long-standing NTFS file-system, and other complications between Linux/Windows I/O handling. But they continue to express they are working on improving the I/O performance and as such I was anxious to see if there are any improvements with this October 2018 Update.

Read more

More in Tux Machines

Watchdog: IRS botched Linux migration

Poor IT governance prevented the IRS from making progress on a long-term effort to migrate 141 legacy applications from proprietary vendor software to open source Linux operating systems, according to an audit by the Treasury Inspector General for Tax Administration. Under a migration plan developed in 2014, two-thirds of targeted applications and databases were supposed to have been successfully migrated by December 2016. However, only eight of the 141 applications targeted have successfully transitioned to Linux as of February 2018. More than one third have not even started. Read more

Graphics: Wayland's Weston, AMD, GitLab, NVIDIA

  • Wayland's Weston Switching Over To The Meson Build System
    Complementing the Meson build system support for Wayland itself, the Weston reference compositor now has been Meson-ized. Pekka Paalanen and Daniel Stone, both of Collabora, have landed the Meson build system support for the Weston compositor. At this stage the new build system should be fully working and correct.
  • AMDGPU DC Gets Polaris Corruption Fix, Some Code Refactoring
    AMD has published their latest batch of "DC" Display Core patches for the AMDGPU Linux kernel driver. This batch of 45 patches against this display code for the AMDGPU Direct Rendering Manager driver has some code cleanups and refactoring, changes some error messages to just warnings, and has a display corruption fix affecting some Polaris hardware.
  • Investigating GitLab
    The Direct Rendering Manager (DRM) kernel subsystem is a fairly small part of the kernel, he said. It is also a fairly small part of the open-source graphics stack, which is under the X.Org umbrella. DRM sits in the middle between the two, so the project has learned development tools and workflows from both of the larger projects. The kernel brought DRM into the Git world in 2006, which was just a year after Git came about; it was a "rough ride" back then, Vetter said. With Git came "proper commit messages". Prior to that, the commit messages might just be a single, unhelpful line; now those messages explain why the change is being made and what it does. The idea of iterating on a patch series on the mailing list came from the kernel side as did the "benevolent dictator" model of maintainership. DRM, the X server, Wayland, and others all followed that model along the way. From the X.Org side came things like the committer model; in Mesa, every contributor had commit rights. That model has swept through the graphics community, so now DRM, the X server, and Wayland are all run using that scheme. Testing and continuous integration (CI) is something that DRM has adopted from X.Org; the kernel also does this, but DRM has adopted the X.Org approach, tooling, and test suites. For historical reasons, "almost everything" is under the MIT license, which comes from X.Org projects as well. There has been a lot of movement of tools and development strategies in both directions via the DRM subsystem. He thinks that using GitLab may be "the next big wave of changes" coming from the user-space side to kernel graphics, and maybe to the kernel itself eventually. This won't happen this year or next year, Vetter predicted, but over the next few years we will see GitLab being used more extensively.
  • AMDGPU For Linux 4.20 Gets The Final Radeon RX 590 Fix, Adds The New Vega PCI IDs
    With just over one week to go until the expected Linux 4.20 kernel release, Alex Deucher of AMD today sent in the latest batch of fixes to the DRM tree for landing at the end of this cycle. Notable about this latest set of "fixes" for the AMDGPU kernel graphics driver are: - The final Radeon RX 590 fix so this newer Polaris GPU no longer hangs under load. So once this Linux 4.20 material is merged to mainline, this month-old Polaris graphics card should now be happily running on Linux -- assuming you also have the latest Polaris firmware files and a recent version of Mesa. See our Radeon RX 590 benchmarks article for more details.
  • AMDVLK 2018.Q4.4 Driver Update Brings Performance Improvements, New Vulkan Bits
    AMD developers today outed their latest "AMDVLK" open-source Vulkan driver code drop dubbed AMDVLK 2018.Q4.4.
  • NVIDIA 415.23 Driver Fixes Build Issues Against Linux 4.20 Kernel
    The NVIDIA 415.23 driver was issued just to fix a build issue against the near-final Linux 4.20 kernels. In particular, there has been a build failure around the vm_insert_pfn function that is now worked around when building the NVIDIA proprietary driver's shim against the Linux 4.20 release candidates.
  • NVIDIA Now Shipping The Jetson AGX Xavier Module
    NVIDIA has been shipping the Jetson AGX Xavier Developer Kit the past few months while now they are beginning to ship the AGX Xavier Module intended for use in next-generation autonomous machines.

OpenSUSE/SUSE: 2018-2019 Elections Underway, SUSE Linux Enterprise 12 Service Pack 4, and 'Making the Selection' (Storage)

  • 2018-2019 Elections Underway with Calls for Candidates and New Members
    Earlier this week, on Tuesday, Dec. 11, 2018, the Elections Committee posted the Schedule for the 2018-2019 openSUSE Board Elections, along with the announcement of a Membership Drive and a call for nominations and applications for Candidates to fill three vacant seats on the openSUSE Board. The annual Board Elections are normally expected to run in November and December, with ballots cast and results published in time for the newly-elected Board Members to take their seats on the Board at the beginning of January. However, some additional work needed to be completed for this election, and the elections were delayed in part to accommodate the additional work.
  • SUSE Linux Enterprise 12 Service Pack 4 is Generally Available
    SUSE Linux Enterprise 12 Service Pack 4 is now generally available. Service Pack 4 marks the fourth generation of SUSE Linux Enterprise Server 12, a major code stream and product foundation with a lifecycle from 2014 to 2024 plus Long Term Support (10+3 years). This release consolidates all fixes and updates introduced since SUSE Linux Enterprise 12 Service Pack 3.
  • Making the Selection
    You’ve likely read or heard a lot about today’s data explosion and how it’s affecting enterprises. After combing through all the overexcited rhetoric about how quickly data is multiplying or how many petabytes you’ll soon have to handle, one thing remains clear: You need to find a new way to store and manage your data or you’ll get left behind. While that mandate puts pressure on your organization to act quickly, it’s also the catalyst to a whole new world of exciting opportunities. More data can mean deeper, more accurate insights into your operations and customer needs, which empowers you to streamline processes and personalize experiences like never before. More data can also lead to greater innovation and new sources of revenue.

Programming/Development: mental illness, newt, and more

  • One developer's road: Programming and mental illness
    The next year, I went to college and learned about SUSE Linux 6.1 and the Java SE 1.2 programming language. Another student introduced me to free software and the GNU GPL License and helped me install SuSE 7.1 on my new Compaq Evo N160c notebook. There was no more Microsoft software on my computer. The GNU/Linux operating system was exactly what I wanted, offering editors, compilers, and a command line that did auto-completion. Six months later, I installed Debian GNU/Linux. Since YaST2 was just a front end to configuration files, I had to use Debian Potato. My bootloader of choice was LILO, and the Second Extended File System was reliable—not buggy, like ReiserFS. In spring 2002, I read a book about the C programming language. I wanted to learn to do UIs like javax.swing, and a friend recommended Gtk+ 2.0, which was about to be released. At this point, I stopped using the KDE Desktop Environment. Gnome 2 was different and provided anti-aliased fonts with hinting. I used it to play Chromium B.S.U., and KNOPPIX did the magic.
  • newt
    I've been helping teach robotics programming to students in grades 5 and 6 for a number of years. The class uses Lego models for the mechanical bits, and a variety of development environments, including Robolab and Lego Logo on both Apple ][ and older Macintosh systems. Those environments are quite good, but when the Apple ][ equipment died, I decided to try exposing the students to an Arduino environment so that they could get another view of programming languages. The Arduino environment has produced mixed results. The general nature of a full C++ compiler and the standard Arduino libraries means that building even simple robots requires a considerable typing, including a lot of punctuation and upper case letters. Further, the edit/compile/test process is quite long making fixing errors slow. On the positive side, many of the students have gone on to use Arduinos in science research projects for middle and upper school (grades 7-12). In other environments, I've seen Python used as an effective teaching language; the direct interactive nature invites exploration and provides rapid feedback for the students. It seems like a pretty good language to consider for early education -- "real" enough to be useful in other projects, but simpler than C++/Arduino has been. However, I haven't found a version of Python that seems suitable for the smaller microcontrollers I'm comfortable building hardware with.
  • Preventing "Revenge of the Ancillaries" in DevOps
  • Wing Python IDE Version 7 Early Access
  • What's the future of the pandas library?