Re: Can we please stop enforcing Signed-off-by commits?
On 1/17/19 12:59 PM, Randy Barlow wrote: > On Thu, 2019-01-17 at 11:13 +0100, Miro Hrončok wrote: >> Why do Fedora upstreams enforce this? > > I enforce the DCO in Bodhi. I started doing it after attended a talk by > Richard Fontana where he suggested it as a way to be explicit about the > license of contributions (i.e., not just the license of the project). > My memory is now a bit hazy, but I think there was some discussion > about how many projects work under the assumption that the license of > contributions is equal to the license of the project (sometimes stated > as "license in, license out", but that most do not make this explicit. > The DCO explicitly states that the contribution itself is granted to > the project under the same license that the project uses. Just adding a link to the talk: https://www.youtube.com/watch?v=F3OxXSirek4 -- Signed Sheogorath signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora Lifecycles: imagine longer-term possibilities
On 11/14/18 12:36 AM, Matthew Miller wrote: > > So, what would this look like? I have some ideas, but, really, there > are many possibilities. That's what this thread is for. Let's figure it > out. How would we structure repositories? How would we make sure we're > not overworked? How would we balance this with getting people new stuff > fast as well? > I know that 13 month for hardware vendors is quite short. Some of them have processes for approving minor updates that take 6 month or longer. We don't talk about a new kernel update here, we really talk about a simple update of a client application in the IoT world. So good so far, it makes sense that they are quite unhappy with Fedora 13 month release cycles. At the same time, one of the main reasons I use fedora is because updates are so smooth in the recent releases. I think that's something we can bring to IoT devices as well. With ostree and the newer ways of upgrading systems it's definitely possible to upgrade software quite fail safe. I would go for one more release cycle that is supported (18-19 months) instead of going for full LTS. Since LTS is really something I think CentOS and RHEL should do. 10 years is LTS. 36 month is only half way, and when we want IoT devices to become more secure in the long term, I think we should work on making them safer and easier to update instead of setting up an LTS which then causes ugly breaking during upgrades which we see on Ubuntu and other places. At least that's my experience and why I would like to avoid an LTS life cycle. And 36 or 48 months are quite short for IoT (think about the toaster you bought. How old is it?) but quite long in the world of software. And for Vendors of notebooks and desktops, I think the upgrade process is ready to work for end users. Especially on defaults. When we look here to Windows, with Windows 10 they do exactly that. Providing a Release that lasts 6 month (+ something for business) and then is updated. We do this for 15 years now and quite smooth, so why change? 13 months are completely fine for a desktop. Finally people. We have resource, but not an infinite number of them. We have so many projects we are working on and right now automatic various of our existing projects already takes so much work time that adding more release cycles would only make it harder. Especially with back porting all the fixes to the then LTS. And besides that I guess most people who want an LTS outside of the IoT world, would go for CentOS anyway. So may let's see if we can bring CentOS and RHEL towards IoT instead of bringing CentOS and RHEL to Fedora. I hope/guess the way for the latter is way shorter. -- Signed Sheogorath signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Automating package maintainers responsivity check
On 11/17/18 11:14 AM, Mattia Verga wrote: > I would propose some sort of automatic check of maintainer responsivity. > Maybe a tool that checks a packager activity in the last 6 months and if > there is no activity then sends an email asking the maintainer to > confirm they're still involved in Fedora. In case there's no reply, > either automatically orphan their packages or notify someone > (devel-list) to try to reach them. > > What do you think? > So basically a heartbeat for developers? Maybe make it even more automatic. When people are not active, they get an email about the branching. when they don't react their package is not branched to the new release. This will cause broken builds, yes. But that's actually the point since people will ask the maintainer to branch it **now**. When people don't react it's time to get a new maintainer. And the people who are maybe interested in being this new maintainer: The people who need the package. Maybe I'm a bit to easy with taking packages away from unresponsive maintainers, but I think this would be a quite easy way to take care of those things. -- Signed Sheogorath signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Proposal: Faster composes by eliminating deltarpms and using zchunked rpms instead
On 11/18/18 7:19 PM, Stephen John Smoogen wrote: > On Sun, 18 Nov 2018 at 12:49, Neal Gompa wrote: >> >> On Sun, Nov 18, 2018 at 11:54 AM Jonathan Dieter wrote: >>> >>> On Sat, 2018-11-17 at 22:30 +0100, Kevin Kofler wrote: >>>> Jonathan Dieter wrote: >>>>> My proposal would be to make zchunk the rpm compression format for >>>>> Fedora. >>>> >>>> Given that: >>>> 1. zchunk is based on zstd, which is typically less efficient in terms of >>>>compression ratio than xz, depending on settings >>>>(see, e.g., https://github.com/inikep/lzbench), and >>>> 2. zchunk can by design only compress chunks individually and not benefit >>>>from the space savings of a solid archive with a global dictionary, >>>> I fear that this is going to significantly increase the size of the RPMs, >>>> which matters: >>>> * for the initial downloads, >>>> * for storage (e.g., keepcache=1, local mirrors, etc.), and >>>> * for the people not using deltas for whatever reason. >>>> >>>> I think zchunk makes a lot of sense for the metadata, but I am not >>>> convinced >>>> that it is the right choice for the RPMs themselves. >>> >>> I suspect the first is true, but zchunk does actually allow for a >>> global (per-file) dictionary that can be used to compress each chunk. >>> The difficulty is that the dictionary has to stay the same between file >>> versions, or the chunk checksums won't match. There would have to be >>> some thought put into how to generate and store the dictionaries. >>> >>> As for how much bigger a zchunked rpm will be compared to an xz rpm, at >>> the moment it's a bit hand-wavy. Based on zchunked repodata work I've >>> done, I think we might be looking at a size that's slightly smaller >>> than a gzipped rpm. I won't know for sure until I put together a >>> proof-of-concept, but I want to make sure that there aren't any gaping >>> holes in the proposal before I do that. >>> >> >> I did some work several months ago to evaluate zstd compression for >> RPMs for Fedora, because of the lower memory and CPU usage for >> (de)compression. However, the average size increase from xz was pretty >> large (~20% or more on average, and nothing ever was either the same >> or smaller), even with heavier compression settings. That might have >> changed a bit with newer zstd releases that offer some more tunables, >> but I think it'll remain a tough sell on disk space. > > So there are at least 4 legs here: > CPU usage (in both uncompression install and deltarpm) > Memory usage per transaction > Network amount > Disk amount > > I expect that the best we are going to get in any 'improvement' is > going to be 3 out of the 4. The xz compression and delta-rpm has a > cpu/memory tradeoff for disk and network in comparison to gzip but it > is mostly acceptable if you have fairly modern desktops. However for > older hardware or lower power systems that tradeoff may not be good. > Good point. Given that we start to have Fedora IoT we have to look at those creatures. IoT devices hate heavy RAM usage, hate disk usage are half way okay with CPU usage (but keep in mind it may take an hour to decompress) and depending on the upstream, either use mobile data for networking or when you're lucky some WiFi/Bluetooth/… thing. Means: CPU usage: Getting worse here, doesn't hurt too much Memory usage: Don't! Get! Worse! Network amount: Well, people wouldn't be happy when it gets worse, but mobile data gets cheaper every day. Disk amount: People won't be happy with an increase here, but as long as it stays somewhere within 10% it's fine, more than 20% would already hurt a lot. So when we want to revisit RPM, we should keep our new fellows in mind. Maybe we get some OSTree magic going? There we already see deltas between versions and we get chunks. -- Signed Sheogorath signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Status of OwnCloud/NextCloud
On 05/02/2018 07:18 PM, Tomasz Torcz wrote: > On Wed, May 02, 2018 at 04:04:11PM +0100, Naheem Zaffar wrote: >> Looking at Nextcloud releases, it seems that they do a major release once a >> year. >> >> It should be possible to catch up with the upstream even if there is a >> single update per Fedora release. >> >> Update to Nextcloud 11 in Fedora 27, 12 in current Fedora 28 and then in >> Fedora 29 cath up with upstream. > > > What about updates (security fixes)? I don't know Nextcloud policy, > but each Fedora version is supported for about 13 months. Is > it likely to receive security fixes for not-the-latest Nextcloud > version? > According to their web page[1] they support the last two versions of Nextcloud. So with ~1 release per year and Fedora with 13 month of support, we are covered here. [1]: https://nextcloud.com/security/ -- Signed Sheogorath signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Hiding the grub menu by default on single OS installs
On 05/31/2018 12:23 PM, Hans de Goede wrote: > The goal if this email is to: > 1) Give people an advance warning about the plan to change > this so we can discuss this early on Actually I'm not a fan of this change. While it was easy to explain end users they can boot to an older, usually working version by just selecting the other entry, this makes it more complicated. Especially with the latest change to easily allow people to install external repositories for NVIDIA graphic drivers which are known to cause trouble with latest kernels. If we want to boot faster, lowering the timeout to 1 second sounds fine. -- Signed Sheogorath signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/5EK73FJMTL2Q6LX4LALZ7VA5ADUV4ESN/
Re: CPE Git Forge Decision
On Tue, 2020-03-31 at 13:08 -0400, Matthew Miller wrote: > On Tue, Mar 31, 2020 at 10:48:55AM -0500, Michael Catanzaro wrote: > > Some failure of process or communication must have occurred > > somewhere along the lines, because open source should have been the > > first and most important requirement. A proprietary software > > solution is incompatible with the ethos and purpose of the Fedora > > project. I ask CPE to revise its requirements list to include open > > source as the first and most important requirement from the Fedora > > community. If that's incompatible with CentOS's need for merge > > request approvals or whatever else, then we need to accept that > > sharing the same forge is simply not going to work. > > Obviously open source is one of our key foundations. And it is part > of who > we are even before those foundations were drafted. Nonetheless, I > want to > gently discuss this a little bit. We make an entirely open source and > free > software operating system. We support and promote and advocate for > open > source and free content. But we can't do everything, and at some > point, this > becomes "this is why we can't have nice things". I see that you've > made > contributions to other open source projects on GitHub and (hosted) > GitLab > this month. Lots of Fedora contributors have and will continue to do > so. > Many use that as their main hosting. It's not ideal, but it's not the > end of > the world. I don't see Fedora making use of non-open hosted services > as the > end of the world either, if that is what is best for us. > > We did communicate as the very top line of our gathered requirements > that > open source is essential to our community and central to our > feedback. I'm > not trying to be soft on that. Let's just not do purity-test level > assessments and instead focus on our goals. > I actually have just one question about this decision, because so far, and I read a lot, but not all mails regarding this, haven't answered that: Let's say the scenario is that we run GitLab EE for Fedora. Can we make sure that at least all customization and modifications that are done by Fedora contributors or in the name of Fedora executed by the Gitlab team, will end up in GitLab-foss i.e. open source? And what really makes me wonder in the whole process: According to various mails from the CPE the deal that will come out, like features, price, … is not yet figured out. Not even the plan what GitLab version CPE is about to go for. But the decision to go for GitLab is already made? How does that work and isn't that basically torpedoing every price negotiation? Hope we can figure those questions out. -- Signed Sheogorath OpenPGP: https://shivering-isles.com/openpgp/0xFCB98C2A3EC6F601.txt signature.asc Description: This is a digitally signed message part ___ 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
Re: Encrypted DNS in Fedora
On Thu, 2019-11-07 at 07:47 -0700, stan via devel wrote: > On Thu, 7 Nov 2019 12:20:50 +0100 > David Sommerseth wrote: > > > Please just watch the talk by Paul Vixie (who is one of the really > > big DNS gurus these days, even ISC BIND maintainer for quite some > > years). And you will see that DoH is pointless when you have DoT. > > But DoT can also go much further than DoH will, when you consider > > the > > bigger part of the DNS query chain. > > Thank you for pointing to that talk. I found it very informative, as > a > mostly ignorant user of DNS. I run knot-resolver as a local caching > DNS > server, pulling from, ironically, 1.1.1.1 via the router, and > bypassing > my ISP's DNS servers. Really opened my eyes. > The talk is right on many points, but I think it dismisses the most essential point DoH does right: DNS is a decision of the device owner. When you are the real owner of the device, you can configure the device to use whatever DoH server you want. This includes company DoH servers. We have to stop to make security products that rely on the same mechanisms as an attacker would use. For corporate environments use Puppet, Ansible, GPOs, MDM, whatever your company device management you have to use at scale anyway, to configure your preferred DoH server, which then can apply all the measures he is talking about to protect things. For private setups: Take the 10 minutes it takes to configure devices properly instead of relying on easy to break network attacker-based solutions. And when you give a device to your kids, then it will probably just take them one internet search to learn how to use the /etc/hosts file in order to access evilpage.com. I agree that DoH and DoT doesn't bring so much more privacy, but it provides integrity to DNS that unencrypted DNS even with DNSSec is lagging as an attack can always opt to not answer for a specific domain name. And whenever or not applications of the system should implement it, is probably decided by how fast the system side will decide to deploy encrypted DNS effectively. -- Signed Sheogorath OpenPGP: https://shivering-isles.com/openpgp/0xFCB98C2A3EC6F601.txt signature.asc Description: This is a digitally signed message part ___ 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
Re: Encrypted DNS in Fedora
On Thu, 2019-11-07 at 21:25 +0100, Nicolas Mailhot via devel wrote: > Le jeudi 07 novembre 2019 à 18:32 +0100, Sheogorath via devel a écrit > : > > The talk is right on many points, but I think it dismisses the most > > essential point DoH does right: DNS is a decision of the device > > owner. > > And the owner should be able to delegate this decision to the network > manager. > Then let's talk on how we properly implement this delegation process instead of asking ourselves whenever we want DoH or DoT or not. Let's find a DHCP/RA option that indicates a DoT or DoH service is available or something similar. Simply stating "encrypted DNS is pointless" is nothing I consider a valid solution. > Suggesting static config is good enough outside the enterprise is a > joke. Count the number of networked things in the modern home, it > grows > every years. A lot of those roam, either because they are designed to > roam (smartphones) or because people vacation, because they like to > share their stuff with friends and families, because they like to > show > of. A lot of those are cheap-ass gadgets that will revert (reset) to > factory settings at the slightest problem (sometimes, just because > the > battery is dead, the juice was cut, and settings are kept in memory). > And how are those devices related to Fedora? I mean, our goal here should be to do things right or at least better. When we take those IoT devices as our standards, then we can throw away SELinux, run stone-age kernels and we can also ignore the existence of updates for our systems. We are Fedora, we want to lead tech towards a better standards, not stay around in the status quo where everyone else already is. > Ansible or puppet are not designed to solve such generic situations. > > Network management is no longer an enterprise-only concern. > > Treating it as a sysadmin problem does not work. > > The network happened. And not only internet side. > I really hope for more IPv6 to happen (properly), so pretty much everything becomes the internet. It makes so many things a lot easier and a lot less security through obscurity. -- Signed Sheogorath OpenPGP: https://shivering-isles.com/openpgp/0xFCB98C2A3EC6F601.txt signature.asc Description: This is a digitally signed message part ___ 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
Re: Fedora Workstation and disabled by default firewall
On 8/27/19 3:25 AM, John Harris wrote: > On Monday, August 26, 2019 7:25:27 AM MST Iñaki Ucar wrote: >> On Mon, 26 Aug 2019 at 15:25, Robert Marcano >> wrote: >>> >>> >>> On 8/26/19 9:07 AM, mcatanz...@gnome.org wrote: >>> >>>> >>>> >>>> Well the thing is, blocknig ports tends to break applications that want >>>> to use those ports. We're not going to do that, period. It also doesn't >>>> really accomplish anything: either your app or service needs network >>>> access and you have whitelisted it (in which case the firewall provides >>>> no security), or it needs network access and you have not whitelisted >>>> it >>>> (in which case your firewall breaks your app/service). In no case does >>>> it increase your security without breaking your app, right? Unless you >>>> have malware installed (in which case, you have bigger problems than >>>> the >>>> firewall). Or unless you have a vulnerable network service installed >>>> that you don't want (in which case, uninstall it). >>> >>> >>> >>> This is a reasonable point of view, until you notice Linux desktops >>> evironments don't provide applications with a method to detect if they >>> are running on a private network or not (See Windows Home, Office, >>> Internet network settings). >> >> >> That's a very good point. When Windows connects to a new network, it >> asks whether it's a home connection (and then you want to share >> resources in the network) or it's a public connection (and everything >> should stay private). And I think that, if the user simply ignores the >> notification, the default is to consider it a public network (not 100% >> sure though). That's a good policy I think, and it would be great if >> NetworkManager could do that. >> >> I understand mcatanzaro's point of view, but it's quite narrow, >> because laptops not only connect to home networks to share resources, >> but also to many insecure public WiFis. I don't think we should rely >> on chasing upstream developers to behave in a *possibly* insecure >> environment. The system should abstract this for them and set proper >> firewall rules. > > Keep in mind that even Windows doesn't address the use case where you set it > to Home or Business, or whatever the private setting is, and then plug in a > connection to a public network. It thinks it's still the same. > I had something back in mind that tickled, when I read this. Because I remember that Windows 7 did something with the default Gateway mac address, so I did some digging. https://web.archive.org/web/20170405202217/https://blogs.technet.microsoft.com/networking/2010/09/08/network-location-awareness-nla-and-how-it-relates-to-windows-firewall-profiles/ There is quite some documentation about how Windows determines/determined when it was connected to a different network (being it by wire or WiFi). Even when this information is might outdated when looking at Windows 10. Hope that helps to provide some inspiration towards solving this problem and create better Firewall rule sets :) (But in general it sounds like something that should go into NetworkManager and could be useful for easier network profiles) -- Signed Sheogorath signature.asc Description: OpenPGP digital signature ___ 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
Re: Fedora Workstation and disabled by default firewall
On 8/28/19 1:01 AM, Adam Williamson wrote: > On Tue, 2019-08-27 at 15:06 +0200, Jiri Eischmann wrote: >> mcatanz...@gnome.org píše v Út 27. 08. 2019 v 15:07 +0300: >>> On Tue, Aug 27, 2019 at 4:22 AM, John Harris >>> wrote: >>>> No, that is not how this works, at all. First, let's go ahead and >>>> address the >>>> idea that "if the firewall blocks it, the app breaks, so it's the >>>> firewall's >>>> fault": It's not. If the firewall has not been opened, that just >>>> means it >>>> can't be accessed by remote systems until you EXPLICITLY open that >>>> port, with >>>> the correct protocol, on your firewall. That's FINE. That's how >>>> it's designed >>>> to work. There's nothing wrong with that. >>>> >>>> This means that the system administrator (or owner, if this is >>>> some >>>> individual's personal system) must allow the port to be accessed >>>> remotely, >>>> before the app can be reached remotely, increasing the security of >>>> the system. >>> >>> You've already lost me here. Sorry, but we do not and will not >>> install a firewall GUI that exposes complex technical details like >>> port numbers. Expecting users to edit firewall rules to use their >>> apps is ridiculous and I'm not really interested in debating it. >> >> Yeah, when you ask users questions they're not qualified to answer, >> you're just creating bad design. >> I always imagine my mom (who BTW has been a Fedora user for years) how >> she'd deal with that and I can't really imagine her opening/closing >> firewall ports. She'd be puzzled even by "Do you trust this network?" >> and would probably just click "Yes" to make it go away. No additional >> security, just annoying UX. > > However, Fedora Workstation is an edition. Which means it has a > *policy-defined* target audience. That target audience is defined here: > https://fedoraproject.org/wiki/Workstation/Workstation_PRD#Target_Audience > > Case 1: "Engineering/CS student" > Case 2: "Independent Developer" > Case 3: "Small Company Developer" > Case 4: "Developer in a Large Organization" > > Are those people we believe do not understand the concepts associated > with firewalls? > Let's get real. It doesn't matter if you understand firewalls or not. Reality is that developers run applications they are working on in development configurations on their local system. With some luck they are properly configured but as far as I know most dev setups, they are not considered secure or "production-ready" and that for good reasons. But what do we do after a long day? We take our notebook and close the lid at the end of a long day or when we head over to this annoying meeting with the new customer. We probably don't close and shut down all services we are developing/testing in background. Then we head over there, open the notebook and of course need some kind of presentation/picture/data we stored on the cloud storage provider of our trust. We connect to the public/unknown WiFi and *boom* suddenly we have unexpected open ports on a public network we didn't to expose them to. This is not something that people do on purpose but it simply happens. It's how we use devices nowadays. So I guess it would already improve the situation when we would only open the ports on install, which by far isn't a perfect solution but would already prevent the scenario mentioned above. Which appears no matter if someone is aware of firewall concepts or not. Let's work on solving this problem for everyone, because it's a general problem. -- Signed Sheogorath signature.asc Description: OpenPGP digital signature ___ 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
Re: Fedora in GNOME Online Accountes
On 9/18/19 11:18 AM, Felipe Borges wrote: > Hi! > > On Wed, Sep 18, 2019 at 11:07 AM wrote: >> >> Hello, I don't know if this is the right place to ask this question. >> Btw, on Fedora 31, in the Online Accounts list there is a "Fedora" >> voice alongside "Google", "Nextcloud" and so on. What is its purpose? > > The "Fedora" account is just a branded Kerberos account. By adding a > Fedora account in GNOME Online Accounts you would get automatically > signed on whenever you'd need to enter your FAS credentials. This > means while accessing Pagure, participating in discussions in > discussion.fedoraproject.org, and also while using Bodhi, Koji, and > all. > Just out of curiosity, is this done by a patch or with a separate package? -- Signed Sheogorath OpenPGP: https://shivering-isles.com/openpgp/0xFCB98C2A3EC6F601.txt signature.asc Description: OpenPGP digital signature ___ 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
Re: Fedora 32 System-Wide Change proposal (late): Enable EarlyOOM
On Sat, 2020-01-04 at 12:17 -0600, Michael Catanzaro wrote: > On Sat, Jan 4, 2020 at 11:38 am, Zbigniew Jędrzejewski-Szmek > wrote: > > What about using the memory controller for user units to allocate > > memory resources between the processes in the user session? Thanks > > to > > recent developments, the gnome session uses separate systemd units > > (and thus separate cgroups) for various services. We could set > > attributes > > like memory.low for "the basic components of the user session", > > and on the other hand, memory.swap.max for "the payload", i.e. > > various > > user processes on top. > > This looks interesting. I'd love to see more serious discussion of > this > proposal. Carving out dedicated memory for essential desktop > processes > seems like something we should be able to do in 2020. > And it seems like it is: In the issue about this whole topic some implemented solutions where mentioned: https://github.com/Nefelim4ag/Ananicy But not further commented at least on pagure. https://pagure.io/fedora-workstation/issue/98#comment-615424 Which I think is quite sad as those seem to be the way better way to handle those things. Having a daemon that assigns cgroups to processes seems to let the kernel do its thing and keep us all sane and keeps the system reasonable responsive. I guess the important question here is: Does it really prevent hanging and what's the origin of hanging? Is it that the kernel starts to swap and therefore eats up all CPU time or is it the programs in foreground that suddenly all try to get their piece of memory back that forces kswapd onto the CPU? My guess would be the latter, but I'm sure the group who did the research on this topic has a better insight into this. -- Signed Sheogorath OpenPGP: https://shivering-isles.com/openpgp/0xFCB98C2A3EC6F601.txt signature.asc Description: This is a digitally signed message part ___ 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
