Re: [Java related] packaging Italian ID card middleware
Hello, I am just following this discussion out of interested and this is kinda off-topic, but I have a question: Why is that? Am 19.07.24 um 11:05 schrieb Marián Konček: Gradle is not a preferred build system in Fedora due to various problems with its distribution. Best Regards Kilian Hanich -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F42 Change Proposal: Enable Drm Panic (system-wide)
Am 16.07.24 um 09:26 schrieb Barry: On 15 Jul 2024, at 18:29, Jocelyn Falempe wrote: I will also check if I can patch VT_CONSOLE, so that it can be disabled on the kernel command line, instead of compile time, to avoid this gap. I'm currently preparing a test kernel, so that you can test on your own, and report if there are other corner cases to fix. Let us know when you have this test kernel to play with. Also would like a way to trigger a panic to test the bsod. Barry Well, to force a a kernel panic one can activate (if not already activated) and send c for system crash into /proc/sysrq-trigger. So as root "echo c > /proc/sysrq-trigger". That's one way of knowing how to force a kernel panic. But if it's useful for this kind of testing, I don't know since kernel panics normally happen when the system is in an (deemed) otherwise unrecoverable state. But I guess it's better than nothing. Regards Kilian Hanich -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Following up on: Three steps we could take to make supply chain attacks a bit harder
Am 27.06.24 um 02:03 schrieb Gordon Messmer: On 2024-06-24 10:34 PM, Alexander Bokovoy wrote: On Пан, 24 чэр 2024, Gordon Messmer wrote: (As a topic for later: the tirpc library exports functions with the same name as functions that appear in libc, so the behavior of erroring on duplicate symbols needs to be rationalized. Maybe an exemption for libtirpc.so? Are there other libraries that do this?) Most of alternative memory allocation libraries provide their own free/malloc replacements to be used with LD_PRELOAD, e.g. jemalloc. Good point. But I'm mostly concerned with the libraries that binaries link directly against, since those are the cases where the got-audit will always see symbol duplication. Well, jemalloc provides a few more function for e.g. fine-tuning which some applications make use of (and as such need to link against jemalloc directly). -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: 2FA policy for provenpackagers is now active
Am 24.06.24 um 17:51 schrieb DJ Delorie: Kilian Hanich via devel writes: One could argue that the "password manager file" is the "something you have" thing. No, one cannot. The three factors in security are: 1. Something you know, which means other people do NOT know it. It exists in your brain and nowhere else. 2. Something you have, which means nobody else can also have it. It can be held in your hand or stolen but there are not two of them. 3. Something you are, like your retina, fingerprints, DNA, weight, etc. Something that another person cannot "be". Putting 2FA on your phone is grudgingly accepted because your phone is "something you have". You don't "have" the app, you "have" the phone. You can't share your phone with someone else, and you'll notice if your phone is stolen. The "password manager file" can be copied, so it can't be "something you have" because someone else could have a copy too. The password for that file might be "something you know" though, and the file might exist on "something you own", but the file itself isn't a security factor. All OTP apps I know of can replicate their stuff to other devices (which can be your Laptop), some of which without deactivating the currently active one (it's often just showing a QR code another phone can scan). That is pretty much just like copying a file around (although I tad bit more annoying, but not by much). So, if we really don't count the password manager file because it can be copied easily, one also cannot count the ones from from apps since they can also be easily replicated. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: 2FA policy for provenpackagers is now active
Am 24.06.24 um 13:53 schrieb Guinevere Larsen: On 6/24/24 5:08 AM, Miroslav Suchý wrote: Dne 24. 06. 24 v 9:48 dop. Mattia Verga via devel napsal(a): IMO, having the token stored in your password manager means going from 2FA to 1FA effectively ;-) if someone gets access to your password manager vault, all accounts will be compromised. Only if you use the same password manager for both: password and OTP. It still makes it 1FA. If all you need to get the OTP is know which password managers the user uses, and what is the password for that passowrd manager, OTP goes from being a "something you have" type of authentication factor, to a "something you know" authentication factor, which is the same factor as the password. Multi factor authentication is not about steps, is about what you need to complete the authentication challenge (something you know, something you have, or something you are). One could argue that the "password manager file" is the "something you have" thing. Kilian -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: 2FA policy for provenpackagers is now active
Am 24.06.24 um 09:48 schrieb Mattia Verga via devel: That said, even if the token is stored in the password manager, it is not cushy to be used with kerberos. I have been using 2FA for over a year now and I get used to, but it's clumsy to use it in Fedora infrastructure. I'd really like if we can move everything related to 2FA to use a yubikey or something like that, so that users could just authenticate by having their key inserted in a USB port. YubiKeys have two disadvantages: 1. You need to buy one (and not loose them). Sure, they aren't overly expensive, but it's also not free. 2. It's either a hazzle of constantly need to plug it in, or you take up a USB port. And on a Laptop that is always kinda awkward (besides the fact that a lot of modern Laptops don't have a lot of ports). YubiKeys have ofc a lot of other advantages, but (as always) it's a tradeoff. Kilian -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
Am 17.04.24 um 23:34 schrieb Kevin Kofler via devel: And in my view, the fact that, in those implementations, there is no Treacherous Computing hardware preventing me from doing what I want with my own private key (e.g., just copying the same key to all my devices, as I can also do with TOTP) is actually a feature, even if it goes against the "security" model. The fact that you can share the keys is actually part of the design and wanted. Apple for exmaple has (or wants to) implement easy sharing of passkeys via AirDrop. Regards Kilian Hanich -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: convert everything to rpmautospec?
Am 08.04.24 um 14:55 schrieb Emmanuel Seyman: Well, you and Kevin see "salami tactics" (whatever that may be), FTR, I have no idea what "salami tactics" is. Since apperently multiple people don't know the term: https://en.wikipedia.org/wiki/Salami_slicing_tactics Regards Kilian -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)
Am 04.04.24 um 03:00 schrieb Gordon Messmer: I think this gets to the heart of the issue. If we set aside subjective arguments about which desktop is better or more popular, only one of these desktops allows Fedora to publish a stable operating system which is a coherent whole, because only one of them has a release cycle that aligns with Fedora's. The other desktop's release cycle does not align, which means that a significant component of the system rebases in the middle of a release, which undermines the fundamental concept of a stable release. About the release cycle: After the initial release of Plasma 6 when dust has mostly settled down (approx. 2 point releases), they want to switch over to a release cycle which would align (which is likely also the reason why F42 was choosen in this proposal). Kilian -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)
Am 04.04.24 um 01:46 schrieb Sam Varshavchik: This is not going to happen. There's going to be someone else, sitting next to them, who will be teaching the new user how to use a computer. And that someone will /also/ be familiar with traditional desktop concepts and paradigms. They, like the new user, will also expect to have a traditional desktop in front of them, that works like a traditional desktop. Sure, but in a lot of cases that other person is a teacher, with a lot of other children needing attention too. That means you have one experience user vs (depending on country) 10 to 50 new users. Kilian -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)
Am 04.04.24 um 01:03 schrieb Kevin Kofler via devel: You make a good point there. The thing is, GNOME tries really hard to design for new users, whom they define as a user who has never before used a computer. Such users are basically on the edge of extinction. A paradigm that works great for someone seeing a computer for the first time in their life does not necessarily work all that great for someone trained to use different paradigms used in the operating system(s) they have used for decades. Most new Desktop users these days have prior experience of using a smartphone or maybe even a tablet. That funnily enough has the side effect that a lot of them try to touch the screen when they use a Desktop for the first time. As you can maybe imagine, these people are very young. Now, some people would argue that Gnome is a good design for a DE for people expecting something like a smartphone UI but made good for a Desktop, some people say the opposite. Personally I think it's a tradeoff. There are equally as many (and strong) arguments for and against it. Regards Kilian Hanich -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)
Am 03.04.24 um 01:48 schrieb Kevin Fenzi: On Tue, Apr 02, 2024 at 04:06:45PM -0400, Steve Cossette wrote: Alright, so a substantial amount of information changed since the original submission of the change proposal. We aren't necessarily thinking of demoting Gnome. The overall spirit of the CP is that we think KDE, and to some extent the other spins too, need a bit more visibility on the website. At the very least, Gnome and KDE should be up front on the frontpage. So, I am far from a web designer, but if you aren't a Linux savvy person and just decided to try out this Fedora thing because you heard it was nice and you go to download it and get: Quite frankly, considering the goals and the philosophy of Fedora (always trying to push for new stuff even if it isn't fully ready yet), I would argue that Fedora isn't for Linux savvy people. Kilian -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
Am 02.04.24 um 10:22 schrieb Florian Weimer: - Can some wrappers be developed to make it both easier and safer? GCC already provides function multi-versioning/target clones as a higher-level interface. Also, upstreams should by default properly mark their stuffs with restrictive visibilities. While we are a few decades to change the defaults, that doesn't mean that one can't choose the better option. So, by default one should choose -fvisibility=hidden and mark the public API with __attribute__((visibility("protected"))) or, if they really want a function to be interpositionable (by e.g. LD_PRELOAD) as __attribute__((visibility("default"))). As a side effect, if you ever want your library be usable on Windows, you need to do that anyway since hidden is the default there and your public API must be marked explicitly. (Also, Windows doesn't support interposition and also doesn't support cyclic library dependencies without complicated hacks. So yeah, Windows kinda has the better defaults here.) Some newer languages do that anyway already, but we obviously can't just change it for C and C++ projects. But depending on the architecture this may not necessarily be possible. So yeah, only upstream can do that, not us. Regards Kilian Hanich -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
Am 31.03.24 um 23:02 schrieb Scott Schmit: On Sun, Mar 31, 2024 at 04:09:36PM -0400, Ben Beasley wrote: On 3/31/24 2:12 PM, Kevin Kofler via devel wrote: But the fact is: What WOULD have stopped this attack: (one or more of:) * Deleting ALL unit tests in %prep (and then of course not trying to run them later). While it’s technically correct that deleting tests would have disrupted this specific attack, a policy of deleting and and never running upstream test code would have prevented me from finding and helping upstreams fix dozens and dozens of bugs due to accidentally faulty assumptions that turned out to be violated on different architectures, in different system environments, or with various allegedly-compatible dependency versions. There are even GCC bugs (miscompilations, not only failures to compile) that were discovered and fixed only because packages I maintain were running upstream unit and integration tests. Frankly, “testing the packages we ship, as built in our distribution, is actually bad” seems like a pretty strange and extreme conclusion to draw from all of this. Deleting the tests makes no sense to me either, but it seems like a mechanism that ensures the test code can't change the build outputs (or a mechanism to detect that it's happened and abort the build) would allow upstream tests to be run without compromising the integrity of the build itself. It would prevent the attack from being hidden in the tests, but not in any other part of the build. Also, I have seen build setups which encode the status of tests in the eventual binary and as such info page or integrated bug report generators. Often because some distros sometimes turned them off or ships software even with failed tests and thus pushing that headache to upstream. Regards Kilian Hanich -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
Am 31.03.24 um 21:19 schrieb Simon de Vlieger: I don't quite agree with you. Two factor authentication whether an actual second factor device or not does prevent credential stuffing which is a common attack method that is easy to perform. It is when people take databases of previously leaked passwords and try them on other accounts that belong to the same person. Since two factors are generally unique per login situation they can't be stuffed in the same way. Of course there are many things two factor does not protect against. 2FA in a lot of cases is just access to a different account (e.g. email or even SMS) and these normally aren't unique. Sure, there are other ways like FIDO2, but these are not necessarily used (or liked, quite frankly I know a lot of people who would loose them on a monthly basis, but still are quite smart about other stuff). This can also lead to a pretty interesting "circle" of 2FA where for example email a is the 2FA address for email b and email b is the 2FA address for email a. If it's the only option it can also lead to a chicken and egg problem for young people who want to create e.g. their first email account. But this paragraph is besides the point. So, sure, 2FA would prevent people from just trying out leaked passwords. But an attack like this would not be a "spray and pray" attack, but it would be a targeted one. This means that the acceptable effort from the attacker would be quite a bit higher. 2FA would prevent script kiddies and "spray and pray"-style attacks from being successful. But more? Doubtful. Regards Kilian Hanich -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
Am 30.03.24 um 20:11 schrieb Kevin Kofler via devel: Or better: Do not execute tests to begin with! rm -rf test in %prep and NEVER run tests during builds. Even when the tests are all legitimate, all it does is slow down the build (e.g., compare glibc build times without and with tests) and every so often break it because the test, not the software, is broken. And a claimed "test file" is what allowed the payload to be snuck in here. Unit tests are something for upstream developers. They should NEVER be run in a distribution build. As a developer I need to say: If your build also runs your tests implicitly even if you just want to make a normal build of your software, your build setup is broken. That should just not happen. But "rm -rf test" or something like that may not be possible. Quite some projects (or just straight up languages) these days have their tests in the same file as the code they test. Kilian Hanich -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
Am 30.03.24 um 15:44 schrieb Zbigniew Jędrzejewski-Szmek: Meson outclasses CMake in functionality, clarity, and brevity. I doesn't make sense to consider switching to CMake at this point. While I do agree on clarity and brevity, I don't on functionality. Meson doesn't allow you do create your own functions. While one should try to avoid them in build systems, there are cases where you need them. I work on a project where they are needed, but it also wouldn't make sense to upstream it because it's too project specific, and creating a loop out of every call like Meson's FAQ recommends (https://mesonbuild.com/FAQ.html#why-doesnt-meson-have-user-defined-functionsmacros) would create one heck of spagetthi code. So yeah, there are edge cases where I would recommend CMake over Meson purely without looking at the rest of the ecosystem. Another is ofc that a quite big chunk of the C and C++ ecosystem uses CMake and integration between build systems kinda sucks (but the CMake developers try to work on making it better by working together with other projects). But I don't think this is the right place to talk about which build system to switch to FOR OTHER PROJECTS. (But if we are at it, ever looked at Zig as a buildsystem for a C or C++ project? I know some companies which do this at this point.) Sincerely Kilian Hanich -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: just to let you know FESCo agreed to a preliminary injunction while we consider this issue
Am 10.02.24 um 09:47 schrieb Neal Gompa: Technically, turning off display sync completely is quite difficult right now since the actual driver stack in Linux underneath everything (both Wayland and X11) uses implicit sync right now (Linux kernel drivers, Mesa drivers, etc.). Interesting considering that I once read (but haven't fact check) that the Vulkan spec explicitly requires explicit sync instead of implicit, even if you for parts of it. That said, there's a move to support explicit sync in Wayland[1], and the first steps of that for KWin have been written up as a merge request[2]. Once there's an agreed upon mechanism for explicit sync, it would be possible to support something like that. [1]:https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/90 [2]:https://invent.kde.org/plasma/kwin/-/merge_requests/4800 Interesting read. I will just hope that this won't be something which ends up in "noone actually still looks at it"-land as some things sometimes end up in because people focused on different things and then forgot about it (well, kind natural for volunteer projects I guess). Kilian Hanich -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: just to let you know FESCo agreed to a preliminary injunction while we consider this issue
Am 09.02.24 um 18:28 schrieb Neal Gompa: On Fri, Feb 9, 2024 at 12:16 PM Roy Bekken wrote: On fredag 9. februar 2024 17:41:33 CET Neal Gompa wrote: On Fri, Feb 9, 2024 at 11:06 AM Roy Bekken wrote: On fredag 9. februar 2024 04:04:04 CET Steve Cossette wrote: I am not gonna reply to all of that because all we are doing at this point is repeating the same thing. But we are NOT stopping you from using x11. You can either build it yourself and put it on a copr (it’s not like neal is using voodoo in his copr), use the copr we provide or … This is extremely hostile towards new people trying linux for the very first time, asking them to add a copr repo if they have problems with wayland to try X11, its unlikely they ever heard this stuff before. Most likely they are trying out Fedora on a live media. And they're not going to get an X11 experience on live media even now. Wayland has been used for all environment modes since Fedora 36. I am aware if this. So you are saying that its perfectly fine that someone new to linux boot into a desktop that microstutters when they move windows around? No, it's not fine. Just like it's not fine to get random tear/corruption snow when moving things around or opening windows on X11. The difference is that we can actually do something about those issues with Plasma Wayland when people report them. *Tons* of these kinds of issues were fixed over the past 3 years, and Plasma 6 brings a huge upgrade around this stuff too. And the whole graphics pipeline is fully under the control of KDE Plasma, so we can do things we've never done before. That's why we can do VRR, HDR, VR, mixed-DPI, fractional scaling, and so much more. We can do things that even other Wayland desktops can't do because our architecture is flexible enough to do it. With Plasma X11, our necks are hanging to the dying albatross that is the X server and our hands are tied behind our backs when we want to actually do something to improve the experience. These are not issues with Plasma Wayland. Because Plasma Wayland... is just KDE Plasma. Quite a bit of topic from my part, but is your pipeline for Wayland flexible enough to turn off any kind of display sync (even in windowed mode) if the user wants that? Sure, it has its downside (e.g. tearing can happen), but I rather have that than the added latency (even if very minimal) of such a sync (and yes, that includes VRR which has a considerable smaller one than normal V-SYNC). -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: just to let you know FESCo agreed to a preliminary injunction while we consider this issue
Am 01.02.24 um 17:44 schrieb Neal Gompa: That is not necessarily true. For your example about window placement, there is this:https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/264 Am 01.02.24 um 17:46 schrieb Neal Gompa: Sorry, I meant to point to this as well: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/247 These two are imo more example which try to prove Falco's point because of: 1. How long this is going on. 2. How many attempts this person made so far. 3. How much some of the maintainers don't want *something* like this (if you go and read through the thread). But yeah, I hope we get something at some point which isn't as stupidly complicated like needing to generate and register transient desktop files to set dynamic window icons (you can't always know them in advance if you have a plugin based application; or when multiple windows should have different ones). I know that there is also a proposal (after multiple failed tries) in discussion, but there are even more maintainers who don't want that. (And I am kinda afraid that if it comes around, it will be a non-flatpak thing, which would be sad considering that I like Flatpak and immutable distros, so I hope that I could at least turn that "protection" off). But well, Let's hope for the best. Kilian Hanich -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue