Monthly Archives: July 2019

Radeon RADV Vulkan Driver Adds Navi Wave32 Support For Compute Shaders


RADEON --

Thanks to Valve’s open-source driver developer Samuel Pitoiset, there is now experimental support for using Wave32 support on Navi graphics cards for compute shaders.

Navi/RDNA brings support for single-cycle issue Wave32 execution as an alternative to Wave64 for better efficiency. Just over a week ago the initial patches landed adding Wave32 support to RadeonSI for their OpenGL driver while now Samuel has tackled the initial implementation in the RADV driver.

This Wave32 support is for compute shaders and as of writing isn’t enabled by default. The code is queued into Mesa 19.2-devel Git but requires setting the RADV_PERFTEST=cswave32 environment variable for enabling the support on new Radeon RX 5700 / RX 5700 XT graphics cards. Wave32 currently isn’t hooked in for any other shader types.

Samuel also submitted a number of fixes today for this Navi code in RADV via radv/gfx10.

Mesa 19.2 feature development is ending next week while fixes are still permitted to land. Mesa 19.2.0 should debut as stable in late August or early September while feature development then shifts to Mesa 19.3 for debut at the end of November.


Fedora Has Deferred Its Decision On Stopping Modular/Everything i686 Repositories


FEDORA --

The recent proposal to drop Fedora’s Modular and Everything repositories for the upcoming Fedora 31 release is yet to be decided after it was deferred at this week’s Fedora Engineering and Steering Committee (FESCo) meeting.

The proposal is about ending the i686 Modular and Everything repositories beginning with the Fedora 31 cycle later this year. But this isn’t about ending multi-lib support, so 32-bit packages will continue to work from Fedora x86_64 installations. But as is the trend now, if you are still running pure i686 (32-bit x86) Linux distributions, your days are numbered. Separately, Fedora is already looking to drop their i686 kernels moving forward and they are not the only Linux distribution pushing for the long overdue retirement of x86 32-bit operating system support.

At Monday’s FESCo meeting, the decision whether to approve this change was deferred on the basis of an open question of whether this would cause issues over the process of building modules locally if i686 Modular/Everything composes are not available. That is now being investigated.

There is two weeks to the beta freeze to get this sorted out otherwise the dropping of these i686 repositories would be postponed until Fedora 32 next year. More details via the meeting minutes.


GitHub Blocks Devs in US-Sanctioned Regions | Developers


By Jack M. Germain

Jul 30, 2019 10:37 AM PT

GitHub is blocking users in Crimea, Cuba, Iran, North Korea and Syria from accessing its services to comply with U.S. trade control laws.

GitHub Blocks Devs in US-Sanctioned Regions

The Microsoft-owned company disclosed the action on a
support page as a courtesy, noting that GitHub users ultimately are responsible for ensuring that their use of GitHub’s products and services complies with all applicable laws and regulations.

“GitHub is subject to U.S. trade control laws and is committed to full compliance with applicable law,” a GitHub spokesperson said in comments provided to LinuxInsider by company rep Marie Yrastorza.

GitHub CEO Nat Friedman acknowledged the blocking actions on Twitter over the weekend, asserting that GitHub took the action “because we have to.”

It appears that the blocked access involves developers’ commercial and private files rather than noncommercial and public files stored on GitHub.

“GitHub’s vision is to be the global platform for developer collaboration, no matter where developers reside,” the GitHub spokesperson said.

GitHub takes seriously its responsibility to examine government mandates thoroughly to be certain that users and customers are not impacted beyond what is required by law, the spokesperson noted. “This includes keeping public repositories services, including those for open source projects, available and accessible to support personal communications involving developers in sanctioned regions.”

GitHub had to implement new restrictions on private repos and paid accounts, according to Friedman’s tweet. Public repositories are still available worldwide, and open source repositories are not affected by the move.

Trivial Pursuit

GitHub believes that by offering free services it supports the U.S. foreign policy of encouraging the free flow of information and free speech in targeted markets. Under GitHub’s Terms of Service, users may access and use GitHub.com only in compliance with applicable laws, including U.S. export control and sanctions laws.

The outcry of potential harm to free speech and U.S. citizens is a stretch, according to Cody Swann, CEO of
Gunner Technology.

“Honestly, this is one of those issues where people are making it a bigger issue than it really is,” he told LinuxInsider.

Github currently is blocking only Crimea, Cuba, Iran, North Korea and Syria. This is so that Microsoft will come into compliance with very specific sanctions imposed by the US government, he said.

The blocking does make developing software a bit more difficult for developers who live in those regions. Since GitHub is a distributed version control system, however, those developers simply need someone from an unrestricted region to fork onto another platform that is not being blocked, Swann said.

The Applicable Laws

U.S. trade control laws restrict the GitHub.com services that can be made available to users in certain countries and territories, according to an export overview GitHub provided as part of its blocking explanation.

Users are responsible for ensuring that the content they develop and share on GitHub.com complies with the U.S. export control laws. These include the Export Administration Regulations (EAR) and the U.S. International Traffic in Arms Regulations (ITAR).

The cloud-hosted service at Github.com is not designed to host data subject to the ITAR. Also, it does not yet have the ability to restrict repository access by country. That is available only with GitHub Enterprise Server, GitHub’s on-premises, commercial, mass-market product offering.

Also prohibited from accessing or using GitHub.com are Specially Designated Nationals (SDNs) and other denied or blocked parties under U.S. and other applicable laws. Plus, others may not use GitHub.com on behalf of SDNs or the governments of sanctioned countries.

Citizens and residents in U.S.-sanctioned countries and territories are prohibited from using IP proxies, VPNs or other methods to disguise their location when accessing GitHub.com services. They may use GitHub.com only for noncommercial personal communications.

Blocking is based on IP addresses and payment histories, according to GitHub. Thus, developers could find their accounts restricted for the duration of a visit to one of those countries. Also, developers are not allowed to use VPNs to circumvent the ban.

Unanswered Questions

The remarks provided by GitHub’s Yrastorza did not provide answers to several key questions posed by LinuxInsider, including whether GitHub is blocking developers automatically or on a case-by-case basis.

GitHub also did not explain what led to the blocking or whether the move to block was the result of a direct government mandate or a proactive response to the trade sanctions.

Another unanswered question is how GitHub monitors and enforces the use of workarounds such as VPNs and proxies.

May Set Bad Precedent

The restricted country list is small, but it sets a bad precedent by subjecting international users to U.S. domestic policy, said Arle Lommel, senior analyst at
CSA Research.

“There are plenty of European companies that use Github for work with little or no U.S. activity. They are now having their capabilities dictated by these restrictions,” he told LinuxInsider.

GitHub is displaying a classic example of the problem of regime uncertainty in economics. That is, if you do not know what the future holds, you factor that in as a risk and withdraw, Lommel added.

“So this move by Github will leave enterprises leery of accepting contributions from participants in countries that may yet be subject to sanction,” he pointed out. “This puts companies on notice that even if they are not touching on projects that implicate EAR and ITAR, they should still stay away from those countries.”

Existing Dev Strategies

The restrictions in the short run likely will harm people in the impacted countries. They will lose access to their code, but presumably have local copies of the repositories they can use with a locally hosted repository, noted Steve Friedberg, spokesperson for
Amalgam Insights.

“Major open source projects, such as Linux, are hosted outside those countries so the impact on the projects will be muted,” he told LinuxInsider.

Most developers in the blocked countries will find ways to route around GitHub, either by old-fashioned file transfers that someone else manages and tests, or by moving to alternative services, like
Atlassian, noted CA-Research’s Lommel.

Other devs will engage in a game of cat-and-mouse with GitHub by using VPNs. Many U.S.-based companies already block the addresses of known VPNs, and GitHub does not allow their use to circumvent GitHub’s controls, he added.

Still, “they cannot block all of them, not least because there are perfectly legitimate reasons why companies use them that have nothing to do with evading trade sanctions,” said Lommel.

If Github cracks down too hard in this area, it will hurt its users in other countries. All the company can do is block the obvious ways around the sanctions, he warned, adding that “the kinds of people who have adopted GitHub are in the crowd best-equipped to evade such blocks.”


Jack M. Germain has been an ECT News Network reporter since 2003. His main areas of focus are enterprise IT, Linux and open source technologies. He has written numerous reviews of Linux distros and other open source software.
Email Jack.





Source link

Linux’s KVM Sees Patches For RISC-V Support


VIRTUALIZATION --

In continuation of the article last week how the RISC-V Linux kernel support has been maturing and various missing gaps filled in, another feature just arrived in patch form: support for KVM virtualization.

Western Digital while associated with hard drives has been working big on RISC-V and already contributed Linux patches in the past. One of their engineers is the one to send out the RISC-V KVM support on Monday.

With sixteen KVM patches adding just under four thousand lines of new code, they are able to boot RISC-V 64-bit Linux guests with multiple vCPU support.

Of course, this is just the architecture support and there are user-space patches needed for this RISC-V virtualization support among other steps and hardware requirements.

These initial RISC-V Kernel-based Virtual Machine patches can be found on linux-riscv. With a bit of luck the code could be merged as soon as Linux 5.4 later this year.