mirror of
https://github.com/LCTT/TranslateProject.git
synced 2025-03-09 01:30:10 +08:00
清除过期
This commit is contained in:
Xingyu Wang
parent
d10dcae1bf
commit
e1b5cae4e8
@ -1,142 +0,0 @@
|
||||
[#]: subject: "Wayland Core Protocol is Tailored Only for GNOME and That’s Not a Good Thing [Opinion]"
|
||||
[#]: via: "https://news.itsfoss.com/wayland-core-protocol-issue/"
|
||||
[#]: author: "Community https://news.itsfoss.com/author/team/"
|
||||
[#]: collector: "lujun9972"
|
||||
[#]: translator: " "
|
||||
[#]: reviewer: " "
|
||||
[#]: publisher: " "
|
||||
[#]: url: " "
|
||||
|
||||
Wayland Core Protocol is Tailored Only for GNOME and That’s Not a Good Thing [Opinion]
|
||||
======
|
||||
|
||||
Wayland is a display server system based on the idea of [protocols][1]. That means that there is no Wayland display server that clients need to talk to. Instead, Wayland defines a protocol for creating display servers. Any client application that is programmed to use this protocol can work on any display server(or compositor) that fully supports this protocol. It’s like the [world wide web protocols][2], where any website can work on any browser as long as the browser is completely supporting the web protocols. So you don’t create websites for specific browsers.
|
||||
|
||||
That also means that the functions defined in the protocol decide what applications (aka clients) can do & what they can’t do. Returning to the example of the website, if the protocol doesn’t define necessary functions, it will limit the web developers. Take CSS as an example; if it wasn’t available in the web protocols, all websites would have looked the same and boring. So the protocol must include all necessary basics in a way that doesn’t limit developers to a few cases and uses.
|
||||
|
||||
When Wayland developers started defining the protocol, they had to decide what functionalities to include in the protocol. Their decision was to make the protocol as minimal as possible, and compositors shall create new protocols for their specific use cases if they desire to offer more functionality not included in the main protocol. The main protocol was called [Wayland Core protocol][3], and other protocols are called [protocol extensions][4]. All compositors are expected to support the core protocol, and they may not support other protocol extensions. That means that applications that depend on certain functionality defined in one of the protocol extensions will not work on all compositors.
|
||||
|
||||
All of the above is what Wayland developers intended for the Wayland world to be. Now let’s delve into more detail. How much is Wayland core protocol minimal? In other words, what determines what shall be in the core protocol and what shall not be? In this article, I’m going to give you an answer to this question based on my opinion, which is in turn based on a group of simple facts.
|
||||
|
||||
_**My opinion is that Wayland’s Core protocol is tailored only for GNOME needs.**_
|
||||
|
||||
I mean that the functionalities which exist in Wayland’s core protocol are the bare minimum required for GNOME desktop and apps to work on Wayland.
|
||||
|
||||
That’s bad (still in my opinion) because it’s simply not enough for other desktop environments and apps other than GNOME desktop and apps, as I will show you in this article.
|
||||
|
||||
### 1\. The core protocol requires that desktop visual components be drawn by the compositor
|
||||
|
||||
First, let’s explain something. In most desktop environments, desktop components (like dock, panel, wallpaper, desktop icons, etc.) are regular clients. For those components to work, they need certain functions to be implemented by the compositor; those functions include:
|
||||
|
||||
* Ability to move the window
|
||||
* Ability to tell the compositor to not draw decorations around said windows.
|
||||
* Ability to keep it above all windows(in case of the panel) or keep it below all windows (in case of the background).
|
||||
* In addition to some other functionalities.
|
||||
|
||||
|
||||
|
||||
On X11, those were defined in the ICCCM specification, which allows X11 clients to tell the compositor to do any of the above. On Wayland, there is not anything in the core protocol that allows that. This means that desktop environment creators have to draw all these in the compositor.
|
||||
|
||||
GNOME is the only desktop that does that, while many other desktops (KDE, XFCE, Lxqt, etc.) draw their components outside the compositor (an exception to that is Cinnamon because it started as a fork of GNOME 3). The situation is even worse. Apps like [plank dock][5], [latte dock][6] and other independent desktop components can’t exist in Wayland. There are protocol extensions that fix that, and I will discuss them later.
|
||||
|
||||
In summary, the situation is:
|
||||
|
||||
* Desktop environments have to draw everything in the compositor.
|
||||
* It’s impossible to create cross-desktop desktop components like Plank and Latte dock
|
||||
|
||||
|
||||
|
||||
### 2\. CSD is implementable, although clients can’t move their window
|
||||
|
||||
We have known before that the core protocol doesn’t define a way for clients to move their windows. So how is CSD implemented? Well, there is a [function in the protocol][7] that tells the compositor to start dragging the window. So instead of having a function for moving the window, which would had been useful in many cases, they resorted to having a function only helpful in implementing CSD.
|
||||
|
||||
### 3\. CSD is a must in Wayland core protocol
|
||||
|
||||
On X11, the situation was that apps expect to get decorated by the compositor (which is SSD) and if they wish to decorate themselves (by CSD) they tell the compositor to not draw its decorations. On Wayland, compositors are free to draw their decorations if they wish.
|
||||
|
||||
The problem is that there is no way (inside the core protocol) for apps to know whether they are being decorated or not. In other words, clients can’t tell the compositor whether they prefer CSD or SSD, which is problematic for both CSD and SSD (in theory). But in practice, GNOME decided not to decorate clients at all. So apps have to assume that they are not decorated due to GNOME’s decision, so they must go for CSD. Again, there is a protocol extension that fixes that; more on that later.
|
||||
|
||||
### To summarize
|
||||
|
||||
The above three facts regarding the core protocol in summary are:
|
||||
|
||||
1. Desktop components need to be drawn by the compositor
|
||||
2. CSD is a must.
|
||||
3. CSD is implementable, although clients can’t move their windows.
|
||||
|
||||
|
||||
|
||||
According to these 3 facts, I’ve concluded my opinion that Wayland’s core protocol is tailored only for GNOME needs.
|
||||
|
||||
What if you wanted some functionalities not available in the core protocol. Wayland or GNOME developers’ answer to this is Wayland’s protocol extensions. That simply means that compositors can offer extra functionality by creating new protocols. The problem with this approach is that means that some apps may work on some compositors and may not work on the rest of the compositors (that’s if it needs some of the protocol extensions). That may have resulted in severe fragmentation in theory, but the reality is less than worse thanks to the efforts of [wlroots project][8] and KDE.
|
||||
|
||||
### Wlroots has mostly saved the situation
|
||||
|
||||
[Wlroots][8] is a library created by [Sway compositor][9] developers. It enables developers to create Wayland/X11 compositors easily. Their main focus is Wayland. There are already many compositors available based on wlroots. What is interesting though is the protocol extensions that wlroots implement.
|
||||
|
||||
Wlroots has many protocol extensions, including:
|
||||
|
||||
* [LayerShell][10] protocol
|
||||
* [xdg-decoration][11] protocol
|
||||
|
||||
|
||||
|
||||
The LayerShell protocol enables desktop components to be drawn outside the compositor. Which also makes it possible to create independent cross-desktop desktop components. Many projects utilize this protocol that you can explore in the following repositories:
|
||||
|
||||
* [nwg-shell][12]
|
||||
* [wf-shell][13]
|
||||
* [awesome-wayland][14]
|
||||
|
||||
|
||||
|
||||
Also, have a look at [GtkLayerShell library][15]. Which is a library for writing Gtk apps with LayerShell protocol.
|
||||
Because LayerShell protocol is not a part of the core protocol apps using it work on wlroots based compositors and KDE, it’s not supported only on GNOME.
|
||||
|
||||
The second protocol is xdg-decoration protocol. Made by wlroots and KDE, it enables apps to choose between CSD and SSD.
|
||||
|
||||
These protocols work on wlroots compositor and KDE. The only obstacle preventing the unification of Linux desktop is GNOME. They have decided not to implement any of these protocol extensions. Which put all apps that use SSD in a situation where they have to use SSD in supporting environments and CSD in gnome. The people actually feeling the pain are toolkits developers. To give you more context, have a look at the “CSD initiative” started by Tobias Bernard from GNOME, and this blog post from Martin’s blog (kwin’s developer). Also, have a look at this issue. The situation is mostly solved by now, that Qt and Gtk draw CSD always on GNOME and utilize the xdg-decoration on other environments. However, in my opinion, that is not good because it makes the platform less standardized/unified for no good reason. After all, in the future, toolkits developers may decide to just go for CSD to avoid the pain.
|
||||
|
||||
### The root of all these problems
|
||||
|
||||
The root of all these is GNOME or Wayland developers’ decision to have the core as minimum as possible and require the creation of protocol extensions.
|
||||
|
||||
Imagine if the web worked in a similar way. That means that websites would not be able to target the standardized (minimal) protocols because they are not enough and will rely on protocols created by certain browsers. So websites would target specific browsers, not the core protocol. That would had been a nightmare, right? Well, that’s the current Wayland situation.
|
||||
|
||||
### What is the solution?
|
||||
|
||||
The solution, in my opinion, is to put all these protocol extensions in the core protocol, or that might not be necessary if GNOME implements the above protocols (Which is not likely to happen anytime soon.)
|
||||
In simple words, GNOME is the root cause of the problem, and it can solve the problem if it decides to do so.
|
||||
|
||||
Author Info: This article has been contributed by It’s FOSS reader Hamza Algohary. Hamza is a computer engineering student and a Linux and open source enthusiast. He also develops apps for Linux desktop. You can find his work on [his GitHub profile][16].
|
||||
|
||||
_The views and opinions expressed are those of the authors and do not necessarily reflect the official policy or position of It’s FOSS._
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://news.itsfoss.com/wayland-core-protocol-issue/
|
||||
|
||||
作者：[Community][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://news.itsfoss.com/author/team/
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://wayland.freedesktop.org/docs/html/ch04.html
|
||||
[2]: https://www.w3.org/standards/
|
||||
[3]: https://wayland.app/protocols/wayland
|
||||
[4]: https://wayland.app/protocols/
|
||||
[5]: https://github.com/ricotz/plank
|
||||
[6]: https://github.com/KDE/latte-dock
|
||||
[7]: https://wayland-book.com/xdg-shell-in-depth/interactive.html
|
||||
[8]: https://gitlab.freedesktop.org/wlroots/wlroots
|
||||
[9]: https://swaywm.org/
|
||||
[10]: https://wayland.app/protocols/wlr-layer-shell-unstable-v1
|
||||
[11]: https://wayland.app/protocols/xdg-decoration-unstable-v1
|
||||
[12]: https://github.com/nwg-piotr/nwg-shell
|
||||
[13]: https://github.com/WayfireWM/wf-shell
|
||||
[14]: https://github.com/natpen/awesome-wayland
|
||||
[15]: https://github.com/wmww/gtk-layer-shell
|
||||
[16]: https://github.com/hamza-Algohary
|
||||
@ -1,42 +0,0 @@
|
||||
[#]: subject: "In light Of The Log4j Incident, Google Supports Calls For Better Open Source Security"
|
||||
[#]: via: "https://www.opensourceforu.com/2022/07/in-light-of-the-log4j-incident-google-supports-calls-for-better-open-source-security/"
|
||||
[#]: author: "Laveesh Kocher https://www.opensourceforu.com/author/laveesh-kocher/"
|
||||
[#]: collector: "lkxed"
|
||||
[#]: translator: " "
|
||||
[#]: reviewer: " "
|
||||
[#]: publisher: " "
|
||||
[#]: url: " "
|
||||
|
||||
In light Of The Log4j Incident, Google Supports Calls For Better Open Source Security
|
||||
======
|
||||
![google][1]
|
||||
|
||||
In response to recent recommendations from the US government to take action against risks connected to the Log4j vulnerability, Google said it supports the advisories and detailed its own defence strategy. In a recent assessment on the Log4j vulnerability, the U.S. Department of Homeland Security (DHS) asked the entire sector to band together and strengthen cybersecurity precautions, warning that it might remain undetected on unpatched endpoints for up to 10 years.
|
||||
|
||||
“We welcome the U.S. Government’s work to improve the nation’s cybersecurity, including through establishment of the CSRB to review incidents like log4j,” Google said in a [blog post][2].
|
||||
|
||||
The report, among other things, provided three recommendations for the industry’s future actions: promoting the adoption of best practises; improving the software ecosystem; and making long-term investments in digital security. Google stated that it will continue to make security a “cornerstone of our product strategy” and that it will share its internal frameworks and best practises with others in order to advance current security hygiene best practises.
|
||||
|
||||
In an effort to spur industry-wide discussion and advancement on the security and sustainability of the open-source ecosystem, the company stated “We partner closely with industry stakeholders to identify and address vulnerabilities in the ecosystem, and share best practises on how to address the latest security threats”.
|
||||
|
||||
When it comes to creating a better software environment, Google sees itself as a market leader, claiming that it promotes, instigates, and funds initiatives and programmes that allow everyone to participate in and contribute to the global open source ecosystem.
|
||||
|
||||
And lastly, Google has significant investment intentions for the future. It promised a $10 billion investment in cybersecurity last year that will span five years and include a $100 million investment in outside organisations like OpenSSF.
|
||||
|
||||
“We welcome the chance to participate in future review board processes, and look forward to working alongside others to continue to protect the nation’s software supply chain ecosystem,” the announcement concludes. “It’s clear that public and private sector stakeholders learned a great deal from log4j and the report provides an in-depth review of shared challenges and potential solutions. Now, we must act on those learnings to improve the security of the entire ecosystem.”
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://www.opensourceforu.com/2022/07/in-light-of-the-log4j-incident-google-supports-calls-for-better-open-source-security/
|
||||
|
||||
作者：[Laveesh Kocher][a]
|
||||
选题：[lkxed][b]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://www.opensourceforu.com/author/laveesh-kocher/
|
||||
[b]: https://github.com/lkxed
|
||||
[1]: https://www.opensourceforu.com/wp-content/uploads/2022/07/google-e1658741796206.jpg
|
||||
[2]: https://cloud.google.com/blog/products/identity-security/google-supports-csrb-call-improve-open-source-security
|
||||
@ -1,124 +0,0 @@
|
||||
[#]: subject: "Linus Torvalds Uses Apple MacBook Hardware to Release Linux Kernel 5.19"
|
||||
[#]: via: "https://news.itsfoss.com/linux-kernel-5-19-release/"
|
||||
[#]: author: "Jacob Crume https://news.itsfoss.com/author/jacob/"
|
||||
[#]: collector: "lkxed"
|
||||
[#]: translator: " "
|
||||
[#]: reviewer: " "
|
||||
[#]: publisher: " "
|
||||
[#]: url: " "
|
||||
|
||||
Linus Torvalds Uses Apple MacBook Hardware to Release Linux Kernel 5.19
|
||||
======
|
||||
Linux Kernel 5.19 is introducing support for a new CPU architecture, along with improvements for next-gen components from Intel and AMD.
|
||||
|
||||
![linux kernel][1]
|
||||
|
||||
Three months after the [last kernel release][2], Linux Kernel 5.19 is finally here. This exciting release brings plenty of improvements to every aspect of the kernel and opens up opportunities with new hardware.
|
||||
|
||||
The most interesting part is that the Linux creator Linus Torvalds used an Apple MacBook, the Arm version, to announce this release.
|
||||
|
||||
Don’t get your pitchfork out just yet. Torvalds used [Asahi Linux][3], a project dedicated to adding Linux support to Apple’s Arm-based Silicon Macbooks.
|
||||
|
||||
> On a personal note, the most interesting part here is that I did the release (and am writing this) on an arm64 laptop. It’s something I’ve been waiting for for a *loong* time, and it’s finally reality, thanks to the Asahi team. We’ve had arm64 hardware around running Linux for a long time, but none of it has really been usable as a development platform until now.
|
||||
|
||||
That’s interesting. And this is the [third time][4] Torvalds used Apple hardware for Linux development.
|
||||
|
||||
### Linux Kernel 5.19: What’s New?
|
||||
|
||||
As with all previous releases, Linux Kernel 5.19 has a lot of technical changes. However, there are only a few major ones that will have a direct impact on users, so we will focus on those here.
|
||||
|
||||
If you are interested in all the low-level code changes, you can refer to the official changelog.
|
||||
|
||||
#### LoongArch CPU Architecture Support
|
||||
|
||||
Over the past few years, it has been interesting to see Chinese chip manufacturers attempt to catch up to Intel and AMD. One way they have tried to do this is by creating their architectures, which are generally compatible with existing architectures.
|
||||
|
||||
One of the more successful of these companies is **Loongson**. However, due to their new architecture, the software support for these CPUs was pretty limited.
|
||||
|
||||
Starting with this release, these CPUs have initial support (it won’t work for booting) and will likely soon have packages ported to them.
|
||||
|
||||
We should see more progress on this with Linux Kernel 5.20.
|
||||
|
||||
#### 32-bit RISC-V Apps on 64-bit RISC-V
|
||||
|
||||
As has been the case for the recent releases, Linux Kernel 5.19 greatly improves support for the open-source RISC-V architecture. This time, this comes in the form of allowing 32-bit RISC-V apps to run on 64-bit RISC-V systems.
|
||||
|
||||
Very few 32-bit RISC-V CPUs can run Linux, meaning very few Linux packages are designed for them. And those packages already have 64-bit counterparts.
|
||||
|
||||
Even if its usefulness is limited, it is good to see RISC-V being treated as a first-class architecture and getting more improvements to bring it closer to mainstream feasibility.
|
||||
|
||||
#### Improved Arc Alchemist Support
|
||||
|
||||
It’s no surprise that Intel’s initial Arc Alchemist GPU launch is a disaster so far, Linux Kernel 5.19 is the first release where you could assume these GPUs are usable on Linux.
|
||||
|
||||
This release finally brings compute support to the Linux kernel. It is somewhat surprising this code was not merged earlier, but at least the support exists now.
|
||||
|
||||
The other major Arc improvement is significantly better power management. This comes in the form of a small tweak in Linux’s PCIe subsystem that treats the Arc GPUs as unlimited, enabling PCI Express Active State Power Management in far more configurations.
|
||||
|
||||
In essence, this change means that the GPU can now be put into an extremely low power mode when not in use, yielding some significant power savings.
|
||||
|
||||
#### Improved ARM SoC Support
|
||||
|
||||
This release brings support to several new ARM SoCs. This time around, 7 new SoCs have been added to the list, specifically:
|
||||
|
||||
* Renesas RZ/G2UL (R9A07G043)
|
||||
* Renesas RZ/V2M (R9A09G011)
|
||||
* Renesas R-Car V4H (R8A779G0)
|
||||
* Broadcom BCM47622
|
||||
* Corstone1000
|
||||
* Mediatek MT8195 (Kompanio 1200)
|
||||
* NXP i.MXRT1050
|
||||
|
||||
In addition, Apple’s M1 chip also gained some improved support. This comes from a new driver for the on-chip NVMe controller. Now, users wanting to be able of NVMe storage on their Apple Silicon Macs are able to do so, thanks to the contribution by the Asahi Linux project.
|
||||
|
||||
#### Significantly Reduced Boot Times For Azure VMs
|
||||
|
||||
Azure users, you are in for a good improvement. Thanks to a contribution by Microsoft, Azure VMs using multiple GPUs can have as many as 3 minutes shaved off their boot times!
|
||||
|
||||
To achieve this, Microsoft changed their PCI Hyper-V driver to avoid setting “PCI_COMMAND_MEMORY”, which stops the driver sending/receiving heaps of unnecessary data from each GPU, saving around 14 seconds of boot time per GPU.
|
||||
|
||||
### Other Changes
|
||||
|
||||
In addition to the ones I mentioned above, Linux Kernel 5.19 also includes
|
||||
|
||||
* Raspberry Pi Sense Hat joystick driver
|
||||
* Various BTRFS improvements
|
||||
* New Intel IFS driver
|
||||
* Intel Raptor Lake P graphics support.
|
||||
* Alder lake improvements.
|
||||
* Initial support for AMD RDNA3 graphics.
|
||||
* Performance optimizations as reported by [Phoronix][5].
|
||||
|
||||
Overall, these changes make up for a pretty decent release. Although there aren’t any major changes, Linux Kernel 5.19 continues to build on the great work of the past few Linux releases.
|
||||
|
||||
### How to Install Linux Kernel 5.19?
|
||||
|
||||
If you are using Arch Linux or Fedora, you can easily upgrade shortly. But, if you are using other Linux distributions (Pop!_OS can be an exception to some extent), you may not receive an upgrade.
|
||||
|
||||
So, if you are feeling adventurous (and know what you are doing), you can find the newer kernel listed on [Linux Kernel Archives][6]. You can download the [tarball][7] to test it out.
|
||||
|
||||
However, we recommend waiting for your Linux distribution to push an update if you do not want to take any chances. It is best to stick to what’s being offered for your Linux distribution by default.
|
||||
|
||||
[Linux Kernel Archives][8]
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://news.itsfoss.com/linux-kernel-5-19-release/
|
||||
|
||||
作者：[Jacob Crume][a]
|
||||
选题：[lkxed][b]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://news.itsfoss.com/author/jacob/
|
||||
[b]: https://github.com/lkxed
|
||||
[1]: https://news.itsfoss.com/wp-content/uploads/2022/07/linux-kernel-5-19-released.jpg
|
||||
[2]: https://news.itsfoss.com/linux-kernel-5-18-release/
|
||||
[3]: https://news.itsfoss.com/asahi-linux-alpha/
|
||||
[4]: https://lore.kernel.org/lkml/CAHk-=wgrz5BBk=rCz7W28Fj_o02s0Xi0OEQ3H1uQgOdFvHgx0w@mail.gmail.com/T/#u
|
||||
[5]: https://www.phoronix.com/news/Linux-5.19-Features
|
||||
[6]: https://www.kernel.org/
|
||||
[7]: https://git.kernel.org/torvalds/t/linux-5.19.tar.gz
|
||||
[8]: https://www.kernel.org/
|
||||
Loading…
Reference in New Issue
Block a user