Re: Fedora 34 Change proposal: Remove and deprecate nscd in favour of sssd and systemd-resolved (Self-Contained Change)
On Sat, 2020-11-14 at 19:11 -0500, Nico Kadel-Garcia wrote: > On Sat, Nov 14, 2020 at 6:02 PM Markus Larsson > wrote: > > > Sounds like a horrible experience. It seems circumventable by not > > caching entire OUs though. They way sssd has been used where I have > > been it has only cached users actually logging in. That's a single > > setting in sssd.conf that makes all the difference. > > Not saying you're wrong though, I've just never seen the issue over > > the years. > > I have seen early sssd take down an AD domain controller do to > > aggressively asking for every user but that was many years ago :) > > Which setting are you referring to? Because a couple of years ago, I > couldn't find a graceful way to prevent it. ignore_group_members is the one. It has other implications which can make a fuzz in certain situations though. Generally what is problematic in my book is that most LDAP directories has a group that contains every user of the directory which promts sssd to pull every user. One could also mask the offending group and in some case that solves the issue. I feel your pain though, I have seen quite a few LDAPs but never a tidy one (not even my freeipa at home is as tidy as I would like it to be). ___ 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 34 Change proposal: Remove and deprecate nscd in favour of sssd and systemd-resolved (Self-Contained Change)
On 14 November 2020 23:35:09 CET, Nico Kadel-Garcia wrote: >On Sat, Nov 14, 2020 at 5:11 PM Markus Larsson wrote: >> >> >> >> On 5 November 2020 13:58:54 CET, Nico Kadel-Garcia wrote: >> > >> >sssd also breaks other LDAP setups, It's extremely broken with larger >> >LDAP setups because it insists on caching *ALL* of the LDAP, barring >> >being able to filter to only a smaller set of the LDAP. But because so >> >many LDAP setups scatter group and user information in so many >> >distinct parts of the LDAP layout, this never works and it *ALWAYS* >> >times out in large, remot4e LDAP setups. It works for a few seconds at >> >start time, then crashes and takes out *all* sssd based services. >> >> I don't share this experience and I run sssd in large environments. Sssd >> will by default lookup the user authenticating, the groups that user belongs >> to and all members of those groups. >> Looking up group members is easily turned off and leads to a much smoother >> experience from what I have seen. >> I still don't think deprecating nscd seems like a reasonable change. Change >> defaults, well ok. Deprecating, I don't really see why tbh. > >Part of the difficulty comes when you only want to see certain LDAP >groups, or permit access only for certain groups. When those groups >are scattered around a poorly organized LDAP layout, it means you need >to cache *all* the relevant OU's. Unless your pipeline to your remote >environment is large, or you have deployed local LDAP servers to >provide a remote mirror, the bulk pre-caching times out and causes all >sssd related daemons to turn off after working for a short period, the >daemons die. This was *nasty* when I observed it a few years ago, I >had to convince the LDAP admins to set up new mirror groups in a much >smaller OU workspace. Sounds like a horrible experience. It seems circumventable by not caching entire OUs though. They way sssd has been used where I have been it has only cached users actually logging in. That's a single setting in sssd.conf that makes all the difference. Not saying you're wrong though, I've just never seen the issue over the years. I have seen early sssd take down an AD domain controller do to aggressively asking for every user but that was many years ago :) ___ 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 34 Change proposal: Remove and deprecate nscd in favour of sssd and systemd-resolved (Self-Contained Change)
On 5 November 2020 13:58:54 CET, Nico Kadel-Garcia wrote: > >sssd also breaks other LDAP setups, It's extremely broken with larger >LDAP setups because it insists on caching *ALL* of the LDAP, barring >being able to filter to only a smaller set of the LDAP. But because so >many LDAP setups scatter group and user information in so many >distinct parts of the LDAP layout, this never works and it *ALWAYS* >times out in large, remot4e LDAP setups. It works for a few seconds at >start time, then crashes and takes out *all* sssd based services. I don't share this experience and I run sssd in large environments. Sssd will by default lookup the user authenticating, the groups that user belongs to and all members of those groups. Looking up group members is easily turned off and leads to a much smoother experience from what I have seen. I still don't think deprecating nscd seems like a reasonable change. Change defaults, well ok. Deprecating, I don't really see why tbh. >___ >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 > ___ 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 33 System-Wide Change proposal: systemd-resolved
On 28 July 2020 17:07:14 CEST, Neal Gompa wrote: >> To prevent brutally overwriting configuration, it would be best not to >> replace >> /etc/resolv.conf with a symlink on upgrade, ignoring user configuration, but >> to do so on all new installs. >> > >We can be smart here and replace the file when we detect that it's >managed by NetworkManager. Otherwise we won't replace it. This sounds like a good way to do it. I very much like the smooth major version upgrades and this would help. Given that some changes DNS servers, for whatever reason, we have to assume that those who have did so because of a reason. Not breaking DNS for them is important. Br M > > > > >-- >真実はいつも一つ！/ Always, there's only one truth! >___ >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 ___ 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: Using "rawhide" for the dist-git branch for Fedora Rawhide
On 7 July 2020 21:20:22 CEST, Matthew Miller wrote: >On Tue, Jul 07, 2020 at 09:03:19PM +0200, Till Maas wrote: >> in https://pagure.io/fesco/issue/2410 I proposed to name the dist-git >> branch for Fedora Rawhide "rawhide" to clarify the purpose of that >> branch. There was also some feedback that Rawhide might not be the best >> name and it could be renamed. In that case, the branch could be named as >> this. This is just the first step to check if there is enough support >> for this to move forward. The next step would be to start a change >> process. > >I'm in favor of this. "Master" is not a good, functional description of the >Rawhide branch. It was just taking the default. Plus, as we're investigating >a new git system _and_ looking at packaging workflow improvements all around >anyway, that seems like the time. > >I don't have any strong opinion on the "Rawhide" name, although it has >always seemed strange to me, because of course fedoras are made of felt, not >rawhide. And I guess the same "hey, while we're changing things" sentiment >applies here. > I thought Rawhide was a reference to the wild west via the tv-show by that name, isn't that the case? As for naming, I have no emotional connection to the name rawhide and doesn't see any problems with changing it. I would suggest that if it changes maybe not Felt or Wool but something more descriptive like Edge, Next or Volatile. M ___ 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 33 System-Wide Change proposal: Make nano the default editor
On 7 July 2020 20:26:52 CEST, Samuel Sieb wrote: >On 7/7/20 7:56 AM, Michal Schorm wrote: >> What I miss is the presence of nano in the default installations and images. >> I strongly believe it was there just a few Fedora releases back, but >> now, it's gone. > >Why do you think it's gone? It's in the "standard" group, so I think it >should be installed on anything other than base minimal. I find that >it's installed on everything. Yeah I make sure via configuration management that nano and Emacs aren't installed on any of my systems. I have 3 kids and don't want them to be led astray. M >___ >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 ___ 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 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants
On 7 July 2020 18:31:32 CEST, Adam Williamson wrote: >On Tue, 2020-07-07 at 06:02 +, Zbigniew Jędrzejewski-Szmek wrote: >> On Mon, Jul 06, 2020 at 08:06:05PM -0600, Chris Murphy wrote: >> > On Mon, Jul 6, 2020 at 4:48 PM Gerald Henriksen wrote: >> > > So if one has a spare partition to play with btrfs, is there an easy >> > > way to install a second copy of Fedora without having the /boot/efi/ >> > > entries overwrite the existing Fedora installation? Or fix it to have >> > > 2 separate entries after the fact? >> > >> > It's possible but has challenges. Separate ESP's you'll need to either >> > (a) use the firmware's built-in boot manager to choose what will >> > probably appear to be identically named Fedora's (b) add new NVRAM >> > entries, and names, and switch between them before reboot by using >> > efibootmgr --bootorder or --bootnext. >> > >> > Another option is shared ESP and /boot but my vague recollection is >> > some things go away. For sure /boot/efi/EFI/fedora is replaced, and >> > then possibly /boot/loader/entries are replaced. But that might be >> > easier to deal with than the above, and more efficient. >> >> This is so sad. Boot Loader Specification was explicitly designed to >> support parallel installations on a single ESP. (The case of different >> systems was the goal, but the general logic works for different >> installations of the same system as well.) BLS entries are stored >> underneath $ESP/, so different Fedora installations which >> have different machine-id numbers simply don't conflict. sd-boot just >> displays the combined list. If two entries happen to be *exactly* the >> same — same os name, same os version, same kernel version — it'll use >> the machine-id in the entry title to disambiguate them to the user (*). >> >> There is really no reason for this not to work. If are considering >> separate ESPs and efibootmgr to switch between them then something >> went rather wrong somewhere. > >I can't speak for Chris, but I was honestly just gaming it out in my >head, trying to think how I'd try it if I was going to do it. I've >never actually tried it myself. The easy way to do it is to keep the same ESP and solve it with a nice little GRUB config. It works well even between distributions. You can of course break it by having one of the distributions overwrite it wrongly but that's easily fixed and prevented. M ___ 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: The future of legacy BIOS support in Fedora.
On 5 July 2020 16:27:07 CEST, Stephen John Smoogen wrote: >On Sat, 4 Jul 2020 at 11:34, Neal Gompa wrote: >> >> On Sat, Jul 4, 2020 at 11:20 AM Lennart Poettering >> wrote: >> > >> > On Mi, 01.07.20 21:06, Neal Gompa (ngomp...@gmail.com) wrote: >> > >> > > The user-interactive portion of sd-boot is *awful*. I know our GRUB >> > > looks ugly by default these days too, but it doesn't have to be, and >> > > most distros actually do make it look semi-decent. >> > >> > BTW, the current look of systemd-boot was proposed by some GNOME >> > designers back in the day. We just implemented what they wanted. >> > >> >> Now I'm even less surprised. It was probably designed with the idea >> that it would never be seen. If any designer people actually wanted to >> make a good boot manager experience, they should take cues from >> Windows, macOS, or even rEFInd. >> >> > >It was probably designed on that idea by people who don't spend as >much time staring at bootloaders as they do operating systems. For the >overwhelming majority of people using computers they are not going to >spend a lot of time making choices in a bootloader or things like >that. For system administrators and operating system developers.. that >is not the case. For most of the computers I manage, I never actually >log onto them UNLESS I am going to be dealing with the boot loader. So >of course the UI is going to be very important to me and I want it to >do a lot of things it probably shouldn't. Mainly because if I have >been called to deal with said computer, something has gone very wrong >and I am going to be trying to make it right. I have no problem with GRUB2 or sd-boot. I have much more problems with refind and their ilk. While things can look pretty, that's fine, as soon as it gets in my way when I try to get things done it stops being fine. > >There is a very different car from what a gear head will design from a >person who wants to enjoy driving their car. A gear head will want an >easy to fix car with very few things hard to get to. The problem is >that usually makes the vehicle noisy, uncomfortable and ugly. The >majority of car drivers want something where all those parts are >nicely hidden because they like a quiet smooth ride. The same is with >computers.. If we want to be able to work on the computers we want a >lot of places we can get into the deep internals and mess around. If >we want to use the computer day to day without needing to spend 10 >years learning how to take it apart and put it together.. We want >something completely different. In the end, the vast majority of >people want things which are hidden away and just do the thing they >are supposed to do.. we computer grease monkeys just need to charge >more to work on them. There's no reason there can't be a glossy front hiding what techs really wants. Just look at the bootsplash. Looks pretty but just push a button and you will get actual useful data instead, everybody wins. That said, I don't think you are wrong per se. I just think there can we can coexist with the help of smart solutions. As I said earlier, I have no problems with sd-boot or the looks of it (it seems that is what we are discussing now). I see no real problems with using it as default for EFI systems. That's just an opinion though. It does what it does and shows what is needed. As for keeping BIOS, yes of course but that seems settled 100 mails ago :) I generally argue that I want Fedora to run on as much different things as possible and devices and motherboards with defective UEFI or no UEFI will be here for a while. M > > ___ 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 33 System-Wide Change proposal: Make nano the default editor
On 3 July 2020 21:54:10 CEST, Adam Williamson wrote: >On Fri, 2020-07-03 at 21:35 +0200, Markus Larsson wrote: >> >> On 3 July 2020 21:30:26 CEST, Adam Williamson >> wrote: >> > On Thu, 2020-06-25 at 13:18 -0400, Ben Cotton wrote: >> > > https://fedoraproject.org/wiki/Changes/UseNanoByDefault >> > > >> > > == Summary == >> > > >> > > Let's make Fedora more approachable, by having a default editor that >> > > doesn't require specialist knowledge to use. >> > > >> > > == Owner == >> > > * Name: [[User:chrismurphy| Chris Murphy]] >> > > * Email: chrismur...@fedoraproject.org >> > >> > Hey, randomly found another thing you'll need to do as part of this >> > change - drop this patch: >> > https://src.fedoraproject.org/rpms/awesome/blob/master/f/awesome-4.0-use-vi-instead-of-nano.patch >> >> Isn't that awesome wm? >> Do we think that new users will even know it exists? >> It also will only use vi if $EDITOR isn't set. >> Am I completely missing the joke here? > >Oh, sorry, meant to send it to Chris only. it was mostly just a fun >note that I found this thing in a completely random package I was >looking at for other reasons... Phew, I was thinking my grasp on reality was slipping and/or you were on drugs :D ___ 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 33 System-Wide Change proposal: Make nano the default editor
On 3 July 2020 21:30:26 CEST, Adam Williamson wrote: >On Thu, 2020-06-25 at 13:18 -0400, Ben Cotton wrote: >> https://fedoraproject.org/wiki/Changes/UseNanoByDefault >> >> == Summary == >> >> Let's make Fedora more approachable, by having a default editor that >> doesn't require specialist knowledge to use. >> >> == Owner == >> * Name: [[User:chrismurphy| Chris Murphy]] >> * Email: chrismur...@fedoraproject.org > >Hey, randomly found another thing you'll need to do as part of this >change - drop this patch: >https://src.fedoraproject.org/rpms/awesome/blob/master/f/awesome-4.0-use-vi-instead-of-nano.patch Isn't that awesome wm? Do we think that new users will even know it exists? It also will only use vi if $EDITOR isn't set. Am I completely missing the joke here? M ___ 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 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants
On 1 July 2020 20:24:37 CEST, Matthew Miller wrote: >On Wed, Jul 01, 2020 at 06:54:02AM +, Zbigniew Jędrzejewski-Szmek wrote: >> Making btrfs opt-in for F33 and (assuming the result go well) opt-out for F34 >> could be good option. I know technically it is already opt-in, but it's not >> very visible or popular. We could make the btrfs option more prominent and >> ask people to pick it if they are ready to handle potential fallout. > >I'm leaning towards recommending this as well. I feel like we don't have >good data to make a decision on -- the work that Red Hat did previously when >making a decision was 1) years ago and 2) server-focused, and the Facebook >production usage is encouraging but also not the same use case. I'm >particularly concerned about metadata corruption fragility as noted in the >Usenix paper. (It'd be nice if we could do something about that!) > >Given the number of Fedora desktop users, even an increase of 0.1% in >now-I-can't-boot situations would be a catastrophe. Is that a risk? I >literally don't know. Maybe it's not -- but we've worked hard to get Fedora >a reputation of being problem-free and something that leads without being >"bleeding edge". It's a tricky balance. > >> Normally we just switch the default or we don't, without half measures. But >> the fs is important enough and complicated enough to be extra careful about >> any transitions. > >Exactly. > >Maybe we could add an "Automatically configure with btrfs (experimental)" >option to the Installation Destination screen, and then feature that in >Fedora Magazine and schedule a number of test days? > >To be clear, I'm not suggesting this as a blocking tactic. The assumption >would be that we'd go ahead with flipping the defaults (as you say above) >for F34 unless the results come back in a way that gives us pause. > This is pretty much exactly how I would like this to happen. It has a schedule so it doesn't just slip while still being as cautious as one should be about fs changes. The only way that would make it even better is a clear definition of what severity of problem is needed to not implement as default in F34 and what happens then. This to avoid the inevitable discussion before F34. With this plan I have no problems. ___ 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: an "old-school *nix defaults" spin [was Re: Fedora 33 System-Wide Change proposal: swap on zram]
On 30 June 2020 16:52:52 CEST, Matthew Miller wrote: >On Tue, Jun 30, 2020 at 08:43:34AM +0200, Markus Larsson wrote: >> I have been using fedora since FC1 and there has been a few shifts. The >> latest shift seems to be a strong desire to be just another Ubuntu. That's >> fine, nothing wrong with that... Do we need more Ubuntus though? > >I don't know what it means to "be another Ubuntu". We're a different project >with a different structure and a different lineage. A distribution which has an aim to streamline the experience in order to cater to new users. Ubuntu is super good at this. > >Would I like the stuff we produce to be as popular as Ubuntu in terms of >user base? No -- I would like it to be more popular. And I think it's very >possible. I would like that too. > >I know change is hard. I used to be a grumpy sysadmin myself and I can >relate to a lot of what you're saying. But I don't think the "alienating >current users vs. attracting new users" dichotomy is a useful one. Many >current users will also benefit from and appreciate the proposed changes. Please don't go "change is hard" on me. That is what management do when they push for unpopular ideas. My problem isn't with change, my problem is with how the change is done and in some cases why the change is done. Change is not only inevitable it's also the only way things can get better. That doesn't mean that all changes are for the better. As for the "old users vs new users" not being useful, well, there's a few reasons why I'm still here. It's mainly that Fedora has good QA, SELinux and very current software. That suits me well for my home environment. What is pretty clear however, is that one can say "hold on how does this affect new users?" but "how does this affect current users?" isn't as interesting. I don't think the FOSS world needs another Ubuntu, Ubuntu already does that. I think Fedora can compete with that without giving up inclusiveness. There can be a Workstation edition that has sane defaults without hiding the fact that things can be configured. > >However, one size definitely does not fit all, and our strategy is designed >*precisely* to address that. Well ofc, but if there is going to be a new spin for every taste then the fragmentation will be a horrible. I'm a proponent of having a set of defaults and then having flexibility since that means people can coexist. But that also means that there needs to be flexibility in the install stage too. I used to be able just grab an ISO of getfedora in case of emergency and get a replacement machine up an running very quickly without much hassle because I could fix most things during the install stage. Now I have instead built kickstarts for the relevant machines and manage them via ansible. It's good sure but having to do it for my home environment is mildly annoying. So well, if I could find another distribution that is current, has good MAC and good QA I would probably use that. Problem is that it doesn't really exist and I like Fedora. I guess I'll just cover my own bases and mark workstation edition as Someone Elses Problem. > > ___ 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: Remove device-mapper-multipath from the Fedora workstation livecd - Fedora 33 System-Wide Change proposal
On 30 June 2020 11:10:03 CEST, Hans de Goede wrote: >With livecd installs the livecd rootfs simply gets rsync-ed over, so >anything which is in the livecd will also end up on the real system. > >There is a post-install configuration phase, so I guess we could >disable things which are only brought in when necessary with netboot >installs in the livecd post-install configuration phase instead of >dropping them from the livecd. > >That same solution would also work for dmraid, so that would be a more >generic solution in general and as such might be better. What do >others think? This sounds like a very reasonable way to do it since the time when diskspace was scarce is long gone. Disabling instead of removing will have the desired effect on boot times while not affecting those that actually need the functionality. I think this would be a good way to go. > >Regards, > >Hans >___ >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 ___ 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: an "old-school *nix defaults" spin [was Re: Fedora 33 System-Wide Change proposal: swap on zram]
On 30 June 2020 02:04:18 CEST, Rahul Sundaram wrote: >Hi > >On Mon, Jun 29, 2020 at 4:40 PM Markus Larsson wrote: > >> >> Thanks, I am well aware. That wasn't really the topic here. >> > >If there is a repeated feeling that anyone has that a particular edition >isn't what they are looking for, figuring out how to make a different set >of choices is and perhaps forming a community around their preferences is >pertinent. This isn't addressed just to you. Having said that, what do >you consider is the topic? > >Rahul The topic at the moment was about how changes are made. It's also about highlighting that when a distribution goes all in on the hunt for new users one has to figure out if one wants to keep the old users. I have been using fedora since FC1 and there has been a few shifts. The latest shift seems to be a strong desire to be just another Ubuntu. That's fine, nothing wrong with that... Do we need more Ubuntus though? Regarding the language in the workstation target audience, well... I think it's narrow and that it shouldn't be. ___ 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 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants
On Mon, 2020-06-29 at 18:51 -0400, James Cassell wrote: > On Mon, Jun 29, 2020, at 6:43 PM, Markus S. wrote: > > Why not Stratis? > > Stratis cannot be used to build the root filesystem. (It's been > answered elsewhere in the thread.) Are we sure? https://github.com/stratis-storage/stratisd/issues/635 While it might not be super there yet it seems it is technically working (I may be wrong I have done 0 tests). But given how new that is and that tolling around it isn't there it pretty far from being a viable default. > > V/r, > James Cassell > ___ > 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 ___ 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: an "old-school *nix defaults" spin [was Re: Fedora 33 System-Wide Change proposal: swap on zram]
On 29 June 2020 22:33:43 CEST, Rahul Sundaram wrote: >Hi > >On Mon, Jun 29, 2020 at 4:30 PM Markus Larsson wrote: > >> >> No that doesn't help at all. It doesn't address what I wrote about many >> seeing a problem for the first time when a change is suggested and that >> this leads to more heated debates than needed. >> I also feel alienated by the target audience of Workstation since it >> pretty much only talks about developers and others. > > >It may very well be the case that workstation isn't what you are looking >for. If you want to create your own remix or spin, one quick way to field >this is to create a package in copr or have an ansible playbook that sets >the defaults and configuration you want and gathering some feedback on >whether others find it useful. > >Rahul Thanks, I am well aware. That wasn't really the topic here. ___ 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: an "old-school *nix defaults" spin [was Re: Fedora 33 System-Wide Change proposal: swap on zram]
On 29 June 2020 21:50:50 CEST, Matthew Miller wrote: >On Mon, Jun 29, 2020 at 07:46:53PM +0200, Markus Larsson wrote: >> I think it would be beneficial to lift up the problems we're trying to >> solve and then work towards possible solutions. I don't think it even >> would take more time. I would probably help people commit to the problem >> and possibly accept the solution. It seems to me that many feel out of the >> loop and thus reacts stronger than needed. > >This is certainly one of the goals for the Editions strategy. Do > >* https://fedoraproject.org/wiki/Workstation/Workstation_PRD#Target_Audience >* https://fedoraproject.org/wiki/CoreOS/PRD#Target_Market_.2F_Audience >* >https://fedoraproject.org/wiki/Server/Product_Requirements_Document#Product_Objectives > >help? > > No that doesn't help at all. It doesn't address what I wrote about many seeing a problem for the first time when a change is suggested and that this leads to more heated debates than needed. I also feel alienated by the target audience of Workstation since it pretty much only talks about developers and others. I guess "you aren't part of the target audience" is a nicer than saying "take a hike neckbeard, this edition isn't even for you". I'm pretty sure that wasn't the intended message though but I can't figure out what the actual intended message was. Please help :) ___ 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: NetworkManager keyfile instead of ifcfg-rh - Fedora 33 System-Wide Change proposal
On 29 June 2020 18:40:23 CEST, Ben Cotton wrote:
>https://fedoraproject.org/wiki/Changes/NetworkManager_keyfile_instead_of_ifcfg_rh
>
>== Summary ==
>Change the default settings plugin of NetworkManager so that new
>profiles will be created in keyfile format instead of ifcfg-rh format.
>
>== Owner ==
>* Name: [[User:Thaller| Thomas Haller]]
>* Email:
>
>== Detailed Description ==
>NetworkManager supports settings plugins to persist connection
>profiles to disk. There is the native ''keyfile'' format and the
>Fedora/RHEL specific ''ifcfg-rh'' format originally from initscripts.
>The keyfile plugin is always enabled in NetworkManager and can handle
>any supported type of profile. It stores profiles under
>`/{etc,usr/lib,run}/NetworkManager/system-connections` and is
>documented in
>[https://developer.gnome.org/NetworkManager/stable/nm-settings-keyfile.html
>nm-settings-keyfile manual]. The ifcfg-rh format is in part compatible
>with the network-scripts package from initscripts, however both
>network-scripts and NetworkManager define their own extensions
>([https://developer.gnome.org/NetworkManager/stable/nm-settings-ifcfg-rh.html
>[1]]). Since network-scripts and NetworkManager are fundamentally
>different, the same ifcfg file is not treated exactly the same by both
>systems. In the past, having the ifcfg-rh format made it easier for
>users familiar with initscripts to migrate to/from NetworkManager.
>
>The settings plugins are configurable in
>[https://developer.gnome.org/NetworkManager/stable/NetworkManager.conf.html
>NetworkManager.conf] via the `"main.plugins"` option. Multiple plugins
>can be configured and on Fedora 32 and older, the compile time default
>for the option is `"ifcfg-rh,keyfile"`. This means, that when
>NetworkManager stores a new profile to disk, it will first try to
>persist it in ifcfg-rh format before falling back to keyfile format,
>if the ifcfg-rh plugin doesn't support the profile type. When reading
>profiles from disk, NetworkManager will read and expose profiles from
>both settings plugins and when modifying an existing profile, it will
>update the existing file and preserve the settings plugin.
>
>This Change is about to change the default for `"main.plugins"` from
>`"ifcfg-rh,keyfile"` to `"keyfile,ifcfg-rh"`.
>
>== Feedback ==
>This was brought up on the NetworkManager mailing list
>([https://mail.gnome.org/archives/networkmanager-list/2020-May/msg2.html
>[1]]]).
>
>Fedora CoreOS doesn't use ifcfg-rh files at all, only keyfile. Also,
>RHEL CoreOS uses the `"main.plugins=ifcfg-rh,keyfile"` configuration
>too. For CoreOS this of course is simpler, because they don't deal
>with existing user configurations and tools that would break during
>upgrade.
>
>== Benefit to Fedora ==
>The long term goal of NetworkManager is to move away from ifcfg-rh
>files. That will be difficult as it affects existing installations and
>will require migration of existing configurations. This change is only
>a first step and affects how NetworkManager by default persists new
>profiles to disk.
>
>The ifcfg-rh format arguably has an uglier syntax and, contrary to
>keyfile, does not support all profile types. Also, keyfile plugin is
>available on every NetworkManager installation because that is the
>only plugin that supports all profiles. Having multiple plugins and
>file formats is confusing. By now, initscripts' `network-script`
>package is deprecated in Fedora and upstream wants to move away from
>that format in the long term. Also maintaining multiple settings
>plugins is a maintainance burden, and in the past there were subtle
>bugs where ifcfg-rh did not implement all settings (e.g.
>[https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2020-10754
>CVE-2020-10754]). On other Linux distributions NetworkManager uses the
>keyfile format by default. It is a general goal that NetworkManager
>works similar on all distributions.
>
>== Scope ==
>
>* Proposal owners: The default settings for `"main.plugins"` can
>already be selected at compile time. This only requires building the
>package with a different default
>([https://src.fedoraproject.org/rpms/NetworkManager/blob/a06b38bcbe8f9a38badab4f37e8c6fae240428b7/f/NetworkManager.spec#_759
>[3]]).
>* Other developers: N/A (not needed for this Change)
>* Policies and guidelines: N/A (not needed for this Change)
>* Trademark approval: N/A (not needed for this Change)
>
>== Upgrade/compatibility impact ==
>This affects most users, unless they explicitly set the option in
>NetworkManager.conf configuration. The biggest effect of this change
>is that new profiles will now preferably be persisted in keyfile
>format. This changes behavior for users who expect NetworkManager to
>write ifcfg-rh files, or who have scripts or tools that expect that.
>What will still work is that existing ifcfg files are loaded after
>upgrade. Users who only use the D-Bus API (via one of the client
>applications like nmcli or the GUI), shouldn't notice the difference.
>
>As before,
Re: an "old-school *nix defaults" spin [was Re: Fedora 33 System-Wide Change proposal: swap on zram]
On 29 June 2020 19:30:53 CEST, Matthew Miller wrote: >On Mon, Jun 29, 2020 at 07:18:00PM +0200, Markus Larsson wrote: >> I think most of these things could be solved in better ways, I don't think >> the "change request"-route is a good way to get the discussion started >> though. It tends to become mudslinging matches where those who proposed >> the changes feel obligated to defend them and others become outraged. > >Yeah, I don't like that pattern either: that's actually why I'm suggesting >this. Rather than say no to other people, say yes to your own thing. I think it would be beneficial to lift up the problems we're trying to solve and then work towards possible solutions. I don't think it even would take more time. I would probably help people commit to the problem and possibly accept the solution. It seems to me that many feel out of the loop and thus reacts stronger than needed. > ___ 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: Heads up: changing the subject format of change proposal announcements
On 29 June 2020 19:27:23 CEST, Samuel Sieb wrote: >On 6/29/20 8:22 AM, Ben Cotton wrote: >> I will replace >> "Fedora Change proposal: " >> >> with >> " - Fedora Change proposal" >> >> As noted by Milan Crha, the existing format can result in threads that >> are hard to distinguish when the subject is truncated by the width of >> the mail client window. Screens are often pretty wide these days, but >> ~40 characters is still a lot to use. > >Thank you! This has definitely been a problem on my laptop and even >more so on my phone. Yes, I approve. Keeping track of subjects on the phone has been a challenge. >___ >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 ___ 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: an "old-school *nix defaults" spin [was Re: Fedora 33 System-Wide Change proposal: swap on zram]
On 29 June 2020 18:44:46 CEST, Matthew Miller wrote: >On Mon, Jun 29, 2020 at 06:30:11PM +0200, Markus Larsson wrote: >> A spin feels like a commitment that involves gathering what other people >> feel and need. While I'm cautious about some changes I tend to welcome >> change in general. I just need to see the benefits and there needs to be >> reason to expect it to be successful. > >That's true, and I'll admit there's a little bit of "show me the money" in >my stance here. The argument for these changes is based on the desire to >provide a better experience for an intended audience. But a number of people >in these threads are putting forth the assertation that there is a >meaningful number of users (including Fedora contributors) who would >actually be better served by a different set of defaults. Well, there are. But the main gripe, for me, is that year for year the defaults keep changing always catering to someone that is not me. Generally not because I'm changing but because things are deemed not welcoming enough. The Workstation installer is a prime example. I'm not saying it's bad just that I feel that a working tool was taken from me and was replaced by something that satisfies my needs to a much lesser extent. I too see the need for being welcoming, I just wish it could be less heavy handed. I also see a bit of arrogance towards new users, that they will break down crying if there things that can be configured (yes hyperbolic but hyperbole is here used to show the pattern, I'm not saying that people are actually arguing that users fall into tears if displayed options). I think most of these things could be solved in better ways, I don't think the "change request"-route is a good way to get the discussion started though. It tends to become mudslinging matches where those who proposed the changes feel obligated to defend them and others become outraged. > >If there enough people who believe that and want to work on it, it should be >easy to find a core group of maintainers, go through the Change process to >propose it, and find an enthusiastic user-base. And I don't mean this in a >snarky way: it seems reasonable enough to me that there's a sustainable >level of interest. If there is, great! If there isn't, well, we also learn >something. This and the btrfs stuff combined with earlier changes at least got me going on finally setting up an auto deployment solution for my home environment. I just wish I didn't have to. > ___ 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 33 System-Wide Change proposal: swap on zram
On 29 June 2020 18:06:10 CEST, Matthew Miller wrote: >On Sat, Jun 27, 2020 at 10:09:08PM +0200, Markus Larsson wrote: >> I was thinking more in the lines of a Remix. >> Mainly to avoid spending time trying to get it blessed in the right >> forums. > >Sure, you could do that too. The process is to submit it as a Change to >FESCo just like this one, and since as I noted Fedora being able to provide >a variety of solutions catering to different users and use-cases is >literally in our mission, I don't think it should be particularly >controversial. People can disagree with what you're choosing for your spin, >but they don't have to use it. Just like you don't have to use nano. :) A spin feels like a commitment that involves gathering what other people feel and need. While I'm cautious about some changes I tend to welcome change in general. I just need to see the benefits and there needs to be reason to expect it to be successful. I have a feeling that a neckbeard purist spin would be to conservative for me and I don't want to invest work to get a spin approved and then land in a userbase of 1. With a remix though I'm totally fine with putting work in for that single person underbase :) > > >> If you think there room for a grumpy old neckbeard spin I'm sure I can >> find some time to contribute. > >I mean... you might want to workshop that name a little bit. :) Was it too honest? > > ___ 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 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants
On 29 June 2020 17:36:15 CEST, Armin Wehrfritz wrote: >> It is not acceptable that there is a range of time that people would >> literally not be able to mount their file systems because the kernel >> module would not build. >I would say that is a rather unlikely scenario to happen given how engaged the >OpenZFS developers are in maintaining Linux kernel support, and also >considering how many kernel developers there are that run Fedora. The time >delay is more with respect to OpenZFS releases rather than having patches >available that make OpenZFS work with the Linux kernel. > >> Fedora does not allow out of tree kernel modules to be packaged for >> the distribution. This has been the case since Fedora 7. >That is a strong argument. But obviously more a political rather than a >technical one. > >> That does not change the fact that OpenZFS is a very *special* out of >> tree kernel module that would put a major crimp in doing a lot of >> things Fedora does now, like testing and validating snapshots of the >> Linux kernel as it is being developed. Fedora is a place where we >> actively work with our upstreams, and we stay close to those projects >> as part of maintaining software for them. Having kzfs in Fedora would >> strain that immensely. >Well, Fedora could become the platform where OpenZFS developers work closely >with kernel developers. :) > >All that said, I very well understand the hesitations of Fedora, and upstream >kernel, developers to accommodate ZFS. I actually agree that in the current >situation with licenses being what they are, and thus ZFS being an out-of-tree >filesystem, it would not be wise to have ZFS as the default root file system >in Fedora. > >I personally have my /home filesystem on ZFS, and keep the root filesystem on >an ext4 partition, as I am confident that I can reinstall Fedora in a >reasonable amount of time, but I care about the data in my home/working >directories and value immensely ZFS features with respect to data integrity >and backups. > >Regarding the current proposal at hand, i.e. making btrfs the default >filesystem, I am actually in favour of that change. The next generation >filesystems (i.e. btrfs and ZFS) have many desirable features ([1] lists a >number of them, and that article is already quite old) and it's about time to >switch also the desktop system to these filesystem IMHO. > >Just my two cents. For me the licensing issues are the big issues with ZFS. Or rather the licensing issue is so big for me that I haven't considered the technical merits of zfs for many years. While, if a way could be found, zfs could be an option I would be opposed to having it as default because of the licensing issues. I understand that not everyone will agree and that this discussion has gone off on a tangent. I just needed to write this for some reason. M > >-Armin > >[1] >https://arstechnica.com/information-technology/2014/01/bitrot-and-atomic-cows-inside-next-gen-filesystems/ >___ >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 ___ 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 33 System-Wide Change proposal: Make nano the default editor
On 29 June 2020 04:51:40 CEST, Matthew Miller wrote: >On Sun, Jun 28, 2020 at 10:32:34AM -0700, John M. Harris Jr wrote: >> > Fine :) https://github.com/gwsw/less/issues/72 >> See Markus Larsson's comment on this above... > >Yeah, but as Michael points out, that doesn't really apply: it takes up >literally zero additional screen space. > Yeah, looks like a slippery slope to me. Yes I'm mostly joking but these things has a tendency to grow. ___ 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: User experience issue on btrfs
On 29 June 2020 08:26:21 CEST, "John M. Harris Jr" wrote: >On Sunday, June 28, 2020 5:37:08 PM MST Chris Adams wrote: >> Once upon a time, John M. Harris Jr said: >> >> > XFS proved to be troublesome, and still is up to the latest of RHEL7. It's >> > not uncommon to have to run xfs_repair on smaller XFS partitions, >> > especially / boot. I'm not sure if btrfs has the same issue there? >> >> >> [citation needed] >> >> I haven't run xfs_repair in probably 15 years (and so never on Fedora or >> RHEL/CentOS). > >I haven't had time to figure out why the RHEL systems I have that are >(mistakenly I assume, though they were created before I was hired) using XFS >run into that issue, after about a month, they report 100% disk space >utilization on /boot, and I've gotta run xfs_repair in order to fix that. In >the unlikely event that I have the time to figure out why, before I just re- >install them (which is already planned), I'd be happy to follow up with a >citation. :) That is very odd. I haven't seen it once in over a decade in an environment with thousands of machines. Very interesting though, I think I will have to try to replicate this. Is there anything special about them like odd partition layout etc? M ___ 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 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants
On Sat, 2020-06-27 at 22:59 +, Stasiek Michalski wrote: > > On 27 June 2020 17:55:09 CEST, Chris Murphy > > > > > The actual data I will never ever be able to share. I have ended my > > time at that > > particular company but even when I was there I was not permitted to > > share such data. Or > > did you mean data from openSUSE and Arch? > > Just have a look at their bug trackers. > > Our bugtracker (openSUSE bugzilla that is) has been curiously silent > about btrfs issues recently. Actually ever since we switched from > btrfs + xfs setup to pure btrfs (with improved subvolume layout) we > have > seen way less complaints about most of the issues the users had > previously. (Hi LCP I hope life is good) That's great to hear, just a few questions. Lately, how would you rate that in number of years? While you seem to have pulled through, would you say the switch btrfs as default has been painful? But to summarize, I'm mainly glad you have fewer issues with btrfs now. /M > > LCP [Stasiek] > https://lcp.world > ___ > 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 ___ 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 33 System-Wide Change proposal: swap on zram
On 27 June 2020 21:34:17 CEST, Matthew Miller wrote: >On Sat, Jun 27, 2020 at 10:25:01AM -0700, John M. Harris Jr wrote: >> Jesus Christ, this actually got approved. It's time to fork Fedora. This is >> really getting out of hand. > > >As mentioned earlier, there's no need to "fork Fedora". It sounds like there >are at least of few of y'all who feel strongly about some of these defaults. >I encourage you to make a spin that caters to that experience. > I was thinking more in the lines of a Remix. Mainly to avoid spending time trying to get it blessed in the right forums. If you think there room for a grumpy old neckbeard spin I'm sure I can find some time to contribute. /M ___ 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 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants
On 27 June 2020 17:55:09 CEST, Chris Murphy wrote: >On Sat, Jun 27, 2020 at 3:12 AM Markus Larsson wrote: > >> There's a difference between "can" and "should". I find this " >> can do this are you less of a man than " tiresome. > >Yes, I also find it tiresome when people make grandiose claims of >having facts on their side, and yet provide none, but inject hyperbole >into the conversation instead. > >> When SLES made the switch they did only recommend it for system data not >> production data because it kept breaking and data loss is painful. >> That was still the case 3 years ago, if they have reconsidered it has been >> done later than that. >> It's very clear from both the openSUSE and the Arch community that btrfs has >> higher failure rates than ext4 and the rate of catastrophic failure is >> non-negligible. > >Excellent! Provide the data. I'm looking forward to seeing this very >clear data. You can provide it, today? The actual data I will never ever be able to share. I have ended my time at that particular company but even when I was there I was not permitted to share such data. Or did you mean data from openSUSE and Arch? Just have a look at their bug trackers. You can dismiss it as anecdotal, that's fine. You could also try to see why someone would get the view that I hold. I have no problem with Fedora supporting btrfs, I have a problem with having it as the default option. This is because my experience tells me that it isn't ready yet. Josef has a different view and that's good, even fine tbh. Disagreement is good, that's how mistakes are avoided. That said, arguing doesn't do much good now, the decision looks like it has already been made. ___ 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 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants
On 27 June 2020 16:17:16 CEST, Solomon Peachy wrote: >On Sat, Jun 27, 2020 at 09:39:36AM -0400, Neal Gompa wrote: >> By that metric, Btrfs qualifies, as it's the default filesystem on >> SUSE Linux Enterprise (and has been since 2014). SUSE has built > >One thing I'd like to see addressed. > >Back in the RHEL7.4 days, btrfs was explicitly deprecated: > >"The Btrfs file system has been in Technology Preview state since the >initial release of Red Hat Enterprise Linux 6. Red Hat will not be >moving Btrfs to a fully supported feature and it will be removed in a >future major release of Red Hat Enterprise Linux. > >"The Btrfs file system did receive numerous updates from the upstream in >Red Hat Enterprise Linux 7.4 and will remain available in the Red Hat >Enterprise Linux 7 series. However, this is the last planned update to >this feature. > >So, why did SuSE consider BTRFS "ready" while RedHat did not, to the >point of removing support for it? And what has changed since then? I don't know how to say this without throwing shade so here goes anyway. Anyone who has worked with both RHEL and SLES systems knows why. My feelings from working with both products in large scale heterogeneous environments is that SLES is many factors less reliable than RHEL. I don't know exactly how and why because SuSE has many many talented people on payroll and do good work in many areas it's just that when it's time to put SLES together it just isn't very reliable. I'm sorry for the harsh words I just don't know how to put it in any other way. /Markus ___ 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 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants
On 27 June 2020 03:21:32 CEST, Chris Murphy wrote: >On Fri, Jun 26, 2020 at 6:17 PM Peter Gordon wrote: >Facebook since 2015. SUSE/openSUSE on the desktop and on servers since >2014, by default. Are you suggesting they can do it and we can't? There's a difference between "can" and "should". I find this " can do this are you less of a man than " tiresome. When SLES made the switch they did only recommend it for system data not production data because it kept breaking and data loss is painful. That was still the case 3 years ago, if they have reconsidered it has been done later than that. It's very clear from both the openSUSE and the Arch community that btrfs has higher failure rates than ext4 and the rate of catastrophic failure is non-negligible. To push for btrfs is doing a disservice to the new users and the not yet competent. ___ 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 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants
On 26 June 2020 21:32:31 CEST, Igor Raits wrote: >-BEGIN PGP SIGNED MESSAGE- >Hash: SHA512 >> >> Josef's server parks is a bit of a different use case than laptops as >> other people has already pointed out. >> If you want data on how it works in a desktop/laptop scenario talk to >> openSUSE users about how many times the "btrfs randomly ate my >> volume"-bug was "fixed". >> >> When I ran an environment of about 4500 SLES and about 5000 RHEL >> servers btrfs failed about 3 times as often as xfs (this from our own >> in-house statistics). That was 3 years ago but filesystems takes long >> to mature and I have been keeping ear near openSUSE to see where it >> goes. >> Is this as big as Josef's environment? No but it is first hand data >> to me (to you it is of course just anecdotal evidence) > >Keep in mind that SLES does backport btrfs patches because they support >it. RHEL does not. And we are talking about Fedora here anyway. We didn't use BTRFS on any RHEL machines only on the SLES ones. > >> BTRFS has the potential to become great, I just think it isn't there >> yet and it'll take 5 years of smooth sailing to convince me. > >Probably you should try it with Fedora's kernel? Oh I will, when BTRFS has had smooth sailing for 5 years. I have no problem with others running btrfs, I just think it should be the default since we seem to be all about not creating problems for new users. That's at least what the recent changes tell me :) > >> > >> > ___ >> > 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 >> ___ >> 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 >- -- >Igor Raits >-BEGIN PGP SIGNATURE- > >iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl72TU8ACgkQEV1auJxc >Hh759w//XHCXloEj6QAUNpVxCEljVwm1WQVl1jfH3p+mex1a5Dan242COXkVaEzy >6zR79EZf7ONg1dTU41fq1mg3gWkFAE/q+OD4cSJ/Jbwyt/L+L40MgD1h7UmNo0/P >uytLZYC3BUIq9ARAH2DlYMHSQUcYZ8TOyrlxWUmkyqPnc99D9CkkqReRjWA/EtYi >mVNOzCQwdMefSJu6+HZlFIhyYeyBbmfu/Q0v5uQE9CQbmN/AuyTHmWG3jRYTINxg >7w8vFPLwjUEmUno+i0Jvkdr4EqSZihV4ljoA0MO8OEADHamjnUOWX8HiFN6E6y+V >cDXPvVTqdf7v+Hz6j6F2cUDbm6PQrbd5fODMeCVibuE5knDB587jRcrqXYfSp+wL >66VRnHXYrOAMHXKlcs+XpPxkqfy5AdgvkP63PUZTWb4yb4wElVVpFNsBf2wk7TXu >kp9cKSf+1CSaIq0oD1uY9YB4Xm9elI3pRJJHuH8TrOKI4RsxnmjXdpXB+pzNf8BH >8PQex0mAwcvefiK0MfaJcl6cP9PgIvvAb75OoWulEsXGG9uPT1ZknYwgXPFN+eDs >T5Wr/7957eiDDgYDtxPXQfliI58AtnCh1ysNcEf5vRLEARs3HLT8Mo+Z+o78ZvpG >ZNYkixPYKGrGrUdLJzwXqlQAy6wlNXDzTIxPtrXy5DHMkuAAAqo= >=2hBc >-END PGP 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 ___ 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 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants
On 26 June 2020 21:04:00 CEST, Michael Catanzaro wrote: >On Fri, Jun 26, 2020 at 8:45 pm, Markus Larsson >wrote: >> I strongly agree. BTRFS has been 5 years from production ready for >> almost a decade now, please don't force this on users that doesn't >> know any better. > >This is hard to square with the fact that it's already being used in >production on millions of systems. It's also hard to square with the >data presented by Josef -- the only hard evidence I've seen on the >topic of filesystem reliability -- which shows btrfs is an order of >magnitude more reliable than xfs (although we don't know how it >compares to ext4). Surely if xfs is good enough for RHEL, and btrfs is >at least 10x more reliable than xfs, that suggests btrfs should >probably be good enough for Fedora? > >Do you have any real evidence for your claim that would be more >convincing than what Josef has presented? Josef's server parks is a bit of a different use case than laptops as other people has already pointed out. If you want data on how it works in a desktop/laptop scenario talk to openSUSE users about how many times the "btrfs randomly ate my volume"-bug was "fixed". When I ran an environment of about 4500 SLES and about 5000 RHEL servers btrfs failed about 3 times as often as xfs (this from our own in-house statistics). That was 3 years ago but filesystems takes long to mature and I have been keeping ear near openSUSE to see where it goes. Is this as big as Josef's environment? No but it is first hand data to me (to you it is of course just anecdotal evidence) BTRFS has the potential to become great, I just think it isn't there yet and it'll take 5 years of smooth sailing to convince me. > >___ >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 ___ 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 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants
On 26 June 2020 16:58:19 CEST, Vitaly Zaitsev via devel wrote: >On 26.06.2020 16:42, Ben Cotton wrote: >> For laptop and workstation installs of Fedora, we want to provide file >> system features to users in a transparent fashion. We want to add new >> features, while reducing the amount of expertise needed to deal with >> situations like [https://pagure.io/fedora-workstation/issue/152 >> running out of disk space.] Btrfs is well adapted to this role by >> design philosophy, let's make it the default. > >I'm strongly against this proposal. BTRFS is the most unstable file >system I ever seen. It can break up even under an ideal conditions and >lead to a complete data loss. There are lots of complaints and bug >reports in Linux kernel bugzilla and Reddit. > >Such changes could affect Fedora reputation among other distributions. > I strongly agree. BTRFS has been 5 years from production ready for almost a decade now, please don't force this on users that doesn't know any better. ___ 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 33 System-Wide Change proposal: Make nano the default editor
On 26 June 2020 20:08:53 CEST, Robert Relyea wrote: >On 6/25/20 12:58 PM, Jonathan Wakely wrote: >> >> >> Anyway, I find it hard to believe that serious developers are >> unable/unwilling to set their own choice of EDITOR. A systemwide >> default EDITOR=nano shouldn't cause them any real difficulty. > > >I second that. I'm the guy who gets annoyed at non-vi editors because I >tend to fill files in them with hjkl's due to muscle memory of 40 years >of vi usage. You'll pull vi out of my cold dead hands. I'm still quite >capable of setting $EDITOR in my own startup files. Pretty much anyone >that has figured out and prefers vi (or emacs or whatever) knows how to >set $EDITOR. That's not really the point. The point is that yet again more or less fictional future users needs comes before the needs of current actual users. As time goes by it seems the list of configuration changes needed to make a system usable (subjectively yes) grows. What was default was changed and since doing it the easy way only annoyed current users the easy way was chosen. I'm getting tired of this but I guess it's time to accept that I'm just one of those grumpy old neckbeard now. Markus >___ >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 ___ 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 33 System-Wide Change proposal: Make nano the default editor
On 26 June 2020 18:11:09 CEST, Adam Williamson wrote: >On Fri, 2020-06-26 at 11:58 -0400, Matthew Miller wrote: >> On Fri, Jun 26, 2020 at 09:24:44AM -0500, Chris Adams wrote: >> > And visudo/sudoedit, systemctl edit, bash ^X^E, mysql \e, virsh edit, >> > less v, mutt, edquota, and a number of bug-report type things like perlbug. >> >> Less already has obscure vi-like keybindings, so that may not be the best >> example. > >quit from less is at least is a single key, which gives you a fighting >chance. I think it only took me about five minutes to figure out how to >quit less, the first time. :P > >I actually hadn't tried most before so I just did - the 'help' bar is a >definitely improvement, but its search behaviour seems awful. > >clearly we need to patch a help bar into less =) Please stop. I know you are joking but people will take you seriously. Fast forward 2 years and there will be a whole little novel taking up screen space when using less. This never fails to happen. ___ 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 33 System-Wide Change proposal: Make nano the default editor
On 26 June 2020 13:39:46 CEST, Sergio Belkin wrote: >El vie., 26 jun. 2020 a las 8:10, Ankur Sinha () >escribió: > >> On Thu, Jun 25, 2020 23:38:13 +0200, Jan Kratochvil wrote: >> > On Thu, 25 Jun 2020 21:21:37 +0200, Chris Adams wrote: >> > > I'm not sure why you think end-users can't use a free OS. >> > >> > First steps of end-users is to install Chrome, Spotify and VirtualBox. >> > So there is left no advantage of a Free OS. >> >> That's anecdotal generalisation at best. I know enough people to >> disprove this statement using my set of anecdotal evidence---and it >> won't get us any where. >> >> We are a FOSS community and we will keep promoting FOSS as much as >> we can. It is our First Foundation: >> https://docs.fedoraproject.org/en-US/project/ >> >> So, let's keep the discussion on topic: about the default editor. >> >> -- >> Thanks, >> Regards, >> Ankur Sinha "FranciscoD" (He / Him / His) | >> https://fedoraproject.org/wiki/User:Ankursinha >> Time zone: Europe/London >> ___ >> 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 >> > >Again, I'm not against the proposal, but I would prefer a better and sane >discussion. >Honestly most end users dislike the CLI. >However I understand that discussion is not about "what is my preferred >editor?". >I understand that discussion is "if by chance an end user has to use CLI, >he/she will not know what/how to do with vim". >In such a case nano is easier (regardless that the argument about how hard >is quitting vim is exaggerated, Ctrl+o is not easier that ZZ). >A better for a newcomer that faces cli would be something like mcedit, but >sadly it is not a standalone editor. >But please, again, most end users prefer to use a gui editor. Is not about >that a newcomer has to know **what** is KWrite/Kate/Gedit/etc, it's about >that choices are of easy access through KDE/GNOME/MATE/XFce/etc graphical >environments. > > I think this is more a discussion about target groups. As far as I understand Fedora is aimed at everyone end users, devs, sysadmins and others alike. While I recognize that helping new users onboard is a good thing it seems that more often than not it is at the inconvenience of the not new. This particular issue is very small but part of a trend, it seems. The workstation installer, gnome and other seems to be arguing in the same way. The needs of new hypothetical users why does not want to learn and/or despises having to use a CLI is more important than the needs of the existing userbase. I think we can find a much better way of being welcoming to new users. One that fits those who just wants to edit some text and those who care about what they use. I like to think that I am part of everyone and I would love if we could deliver smart solutions that doesn't needlessly change default behaviour under the guise "advanced users will know how to configure this". BR Markus ___ 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: [External] Re: Fedora+Lenovo
On 1 May 2020 12:57:04 CEST, Mark Pearson wrote: >Hi Markus, > >> From: Markus Larsson >> Sent: Friday, May 1, 2020 3:24 AM >> >> Hi Mark >> >> I have a question regarding the hardware lineup. The 3 machines mentioned >> are very fine machines but for many usages they are definitely overkill and a >> tad bit pricey. >> Will there be more modest machines supported down the line? >> By modest I mean decent machines with good screen (minimum FHD) in the >> 1000€ to 1500€ price range. >> >Our focus has been on the platforms that business customers want so I agree - >the more modest machines are missing. We do have other platforms that we >support linux on but that aren't part of this initial Fedora program and >hopefully >it becomes a no-brainer to add those as well in the future. > >We have been expanding our Linux portfolio every year - this year we're doing >full configuration on the workstations which is a big step (caveat for >WWAN...). >If the trend continues then logically we should be adding Ideapads - but we're >not >there yet. I think the web sales will be useful for showing there is customer >demand >outside of business use and I'm genuinely fascinated to see how sales go >(fingers >and legs crossed). > >So - I can't give you an answer, because I genuinely don't know myself, but my >hope and expectation is we'll get therewhich is horribly vague. Sorry! > >Mark Well, I'm happy with that answer. I rather have you say where things will go is unclear than have some cookie cutter marketing answer. This answer helps me figure out where this is hopefully going and how much to hope for it to happen. While I'm fine with spending 2500€ of company money on a work machine, I'm rather hesitant to spend that kind of money on laptops for the kids :) Br M ___ 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+Lenovo
On 30 April 2020 23:18:10 CEST, Mark Pearson wrote: >Hi all, > >Adam Williamson suggested I stick a note in the mailing list saying “hi” - so >I’ve achieved that and officially upgraded myself from lurker! He also >suggested I take questions from the community - and I’m very happy to do that. Hi Mark I have a question regarding the hardware lineup. The 3 machines mentioned are very fine machines but for many usages they are definitely overkill and a tad bit pricey. Will there be more modest machines supported down the line? By modest I mean decent machines with good screen (minimum FHD) in the 1000€ to 1500€ price range. Br Markus ___ 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: f32-backgrounds look like crap
On 18 April 2020 07:49:18 CEST, Leigh Scott wrote: >> Well then please don't express your opinion then and keep it to yourself. > >It's a free country with free speech. >If you don't like it don't read it! You do realise that asking someone nicely is not the same as trying to take away their free speech, right? Free speech also doesn't mean free from criticism. M >___ >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 ___ 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: f32-backgrounds look like crap
On 17 April 2020 21:00:55 CEST, "John M. Harris Jr" wrote: >On Friday, April 17, 2020 5:49:48 AM MST Leigh Scott wrote: >> If there any plan to fix them? >> >> https://leigh123linux.fedorapeople.org/pub/screenshots/Screenshot%20from%202 >> 020-04-17%2013-32-22.png > >Wow, that does look pretty shitty. Perhaps one of the old ones could be re- >used? Maybe there's some kind of personal taste involved here. Perhaps instead of saying that something "is shitty" we could maybe opt for saying things like "Wow, I really don't like that" because that is instantly interpreted as opinion no matter what language you're a native of. I didn't realise how important wallpapers seem to be to people, given that it is not even hard work to change it. Not everyone will like everything but we can at least keep a nice tone. Also, John I don't mean to single you out in any way. Br M > ___ 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: f32-backgrounds look like crap
On 17 April 2020 15:17:50 CEST, Leigh Scott wrote: >> On Fri, Apr 17, 2020, at 4:02 PM, Leigh Scott wrote: >> >> Hi Leigh, >> >> Elections for alternative wallpapers are currently open: >> https://apps.fedoraproject.org/nuancier/elections/ >> Please vote for ones that you like. >> >> The submission phase for Fedora 32 has unfortunately already closed. >> Please do make wallpaper submissions for Fedora 33 as well to ensure >> there is a wide choice of excellent candidates. > >Vote done, they are much better than the default. Good that you found something you liked. >___ >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 ___ 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: CPE Git Forge Decision
On 3 April 2020 19:18:57 CEST, Matthew Miller wrote: >On Fri, Apr 03, 2020 at 01:04:33PM -0400, Ben Cotton wrote: >> For what it's worth, when I sent the list I included a reminder that >> FOSS is always our strong preference where viable. It was a mistake to >> not leave that in as a user story. I own that. I did that because of > >Eh, I remember it somewhat differently. I don't think that _it is our strong >preference and very important to our community that this be open source_ is >a _functional_ requirement, and doesn't really fit as a user story. So we >pulled that out and emphasized it separately rather than leaving it as one >among many in the list. > > I would dare to say that going with a proprietary solution not only reflects poorly on Fedora but also on Red Hat since it's basically saying "we needed proper stuff so we couldn't use FOSS". I can see that the team is strained, what I don't understand is why that exact team needs to run all infra. If the team doesn't have the capacity to take care of everything on their plate they either need more resources or a smaller scope. This puts an unnecessary strain on the RH - Fedora relationship. Anyone involved here wants things to work well and everyone is involved because they want to. We have built an odd structure that creates friction and conflict though. There needs to some talks about how the CPE should work and what services they should deliver. The CPE team does great work and works hard to deliver working solutions but often get met with suspicion and even hostility when they push for changes. They play the part of corporate IT in any large corporation. They are staffed to do way less than what they are asked and the users they serve can't really go to someone else if they feel they aren't getting what they need. Sadly that is rather built in to the current model, it's basically a negative feedback loop. I think the lofty goals of the Fedora project can't be realized if we aren't organized to promote them. Sorry for the rant, it's has been brewing for quite a while and I really don't know where to turn with it. Br Markus ___ 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: CPE Git Forge Decision
On 3 April 2020 10:23:58 CEST, Julen Landa Alustiza wrote: > >But there is an initiative to federate git forges, and they plan to >implement it on gitlab. Oh sorry, I meant on pagure :) > >https://forgefed.peers.community/ Oh that is quite the opportunity right there. The CPE team could get an opportunity to do things right, Fedora gets to be at the forefront, it's rather nextlevel instead of being just another boring old gitforge workflow, those who wants to integrate can do so in a ordered fashion. BR M ___ 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: ask.fedoraproject.org - redirects?
On 2 November 2019 10:18:20 CET, Ankur Sinha wrote: >On Sat, Nov 02, 2019 09:23:37 +0100, Markus Larsson wrote: >> Not having this planned for and sorted before the change is sloppy. >> Sadly this kind of attitude towards breakage in a production >> environment seems makes fedora look bad and like we as a community >> can't even keep simple services working. It seems the whole move to >> discourse thing was done without proper planning. > >> Do we not follow any type of change procedures? > >I hate to break your bubble here, but the move took months of planning: >https://pagure.io/fedora-join/Fedora-Join/issues?status=Closed=C%3A+AskFedora >https://pagure.io/fedora-join/Fedora-Join/issue/91 Clearly planning missed since 404 message had to be fixed after the fact. This doesn't mean that everyone is bad etc, please keep issue and person separate. It just means that this wasn't a successful change but rather a learning opportunity. > >was set up at askbeta.fp.o first: >https://communityblog.fedoraproject.org/moving-ask-fedora-to-discourse-phase-2-request-for-beta-testing/ > >and was announced when moved over later: >https://communityblog.fedoraproject.org/askfedora-refresh-weve-moved-to-discourse/ > >Here's a summary: > >- we did not host askbot, and we do not host discourse. This is because > we do not have the manpower to maintain/update/tweak the > infrastructure required to host these. So, we pay them to host the > instances for us. When choosing to use use the same URL as an existing service one plans for trouble. > > This means that we *do not* have access to the servers---no control > over the lower level server configurations. All we can change are > settings from the GUI admin panel that discourse provides. This does > not provide the ability to set up redirects. The plaintext on the 404 > page can be changed, that is all. This is a red herring. Rewriting 404 messages had to be done after the fact since it was missed in the initial change. The 404 messages was only needed because of URL reuse. > >- Even if we did have access to the servers, there is no clean/easy way > of migrating data from askbot to discourse. Resources would have to be > spent on cleaning/anonymisation/user-mapping/badge-karma > mapping/importing. We did not the required man-power to do this. I didn't say data has to be migrated. > >So, what we have now is what could be achieved with the man power that >we obtained from volunteers in the community, and with the technical >limitations that we had to work with. > >We've spent a lot of time explaining this to our users, many of who had >not read the CoC and used similar negative tones to demand that >everything be moved over, or simply state how bad a job we had done. > >https://ask.fedoraproject.org/t/where-have-the-old-posts-gone/655/45 >https://ask.fedoraproject.org/t/hello-everyone-what-do-you-think/138/5 > >With users, even though not enjoyable, it was understandable---they are >not aware of how the community works and its limitations. Such tones on >the -devel list within the community are less easy to digest. > >Maybe assume that we are slightly knowledgable and competent, did the >planning and the thinking (and we certainly did the work), and this is >simply the best that was possible within the given parameters? That is >certainly more in line with "be excellent to each other" than what you >are saying now. If this has made you feel bad I apologize. I mean you no harm in any way. Clearly my tone has been off here since I managed to offend you. > >Even though I will not participate in this again, please feel free to >continue the discussion---if folks want to improve AskFedora, please >host a test discourse instance, see what can be tweaked from the admin >panel, and suggest improvements. We have a specific category for that: >https://ask.fedoraproject.org/c/site-feedback ___ 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: ask.fedoraproject.org - redirects?
On 2 November 2019 09:12:21 CET, "Miro Hrončok" wrote: >On 01. 11. 19 22:58, Tim Jackson wrote: >> I realise this is not exactly news, but when replacing Ask Fedora, >was there a >> reason to break all the links on the entire web to existing >solutions, rather >> than just putting the new system on a different domain? Or, failing >that, at >> least adding (conditional) redirects and/or links to the "old" site? >> >> It seems like finally as Fedora was building up a body of useful >"ask"-type >> content and get traction on search engines (= searching for things >not only >> leading to results about Ubuntu), we wiped the slate clean. >> >> As it is now, whenever I (as a Fedora user) search for something, I >still >> frequently end up at a dead end on a 404 page on >ask.fedoraproject.org. There >> isn't even a *link* to the corresponding page on >askbot.fedoraproject.org - >> surely that, at least, is something we could do? (yes, I realise one >just has to >> add "bot" to the hostname, but that's not the point - not everyone >will either >> realise that, or bother, and it's trivial to do when generating the >error page) > >This is very much needed but apparently, the effort got stalled: > >https://pagure.io/fedora-websites/issue/953 >https://ask.fedoraproject.org/t/updating-the-404-template-to-mention-the-move-to-discourse/407/6 Not having this planned for and sorted before the change is sloppy. Sadly this kind of attitude towards breakage in a production environment seems makes fedora look bad and like we as a community can't even keep simple services working. It seems the whole move to discourse thing was done without proper planning. Do we not follow any type of change procedures? Br M ___ 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: RPM Fusion Bugzilla Bug 5307
On 23 September 2019 22:42:35 CEST, Ty Young wrote: > >On 9/23/19 3:16 PM, Markus Larsson wrote: >> >> >> On 23 September 2019 21:58:02 CEST, Ty Young >> wrote: >> > >> >On 9/23/19 1:53 PM, Markus Larsson wrote: >> >> You already have a solution. Use the solution you have. >> > >> > >> >Not a solution, it's a bandaid to a much larger problem. >> >> You said it works fine in Arch. So use Arch. > > >What if another user uses it on Fedora and then blames me or some other > >developer for it not working? That's BS. > > >If you think I'm upset now, I'll go full tilt if that ever happens. I >refuse to be blamed for some dumb decision Fedora made. I want to >support Fedora, but Fedora doesn't want to support me. I'm more than >doing my part to try to get this fixed. Why do you think anger will solve problems? Just point them towards Fedora and say that you can't do anything about it. > > >> You say that it can be configured easily in Fedora so do that and use > >> Fedora. > > >I never said that. I said the complete opposite of that. Learn to read, > >please. I'm sorry if I was mistaken. > > >> Those are solutions to your problem. > > >No. > > >> >> > >> > >> >> Fedora will not change to cater to this particular need. >> >> Your opinions does not dictate what Fedora should/shouldn't do. >> > >> > >> >Yet Fedora expects other distros/DEs, *including their own spins* to >> >cater to their decisions when those decisions aren't wanted or >> >technically possible to begin with. That's hypocritical. >> >> As a Fedora user I don't expect to be able to demand what defaults >> Void or Arch or Gentoo should have. > > >Fedora doesn't? Then why did Fedora upstream the non root X. Org >feature >then instead of custom patching it every release? Clearly no one cares >or wants it, as evident by the fact that X. Org is running as root(and >by extension, overclocking works) yet Fedora as the maintainers of X. >Org decided to make it the default? How is that not pushing your own >agenda on other distros? If they went out of their way to disable it >then they clearly don't want it. You and everyone else are free to fork if you don't agree with upstream. > > >And Fedora's own spins are impacted by this. It's not even consistent, >reliable behavior in Fedora. You can't even depend on it one way or the > >other. Applications that depend on X. Org. being root will literally >work just fine on a spin of Fedora but not the Gnome version. That's >unnecessary fragmentation in the same ecosystem. This has already been explained yet you act as if it hasn't. If only I could find something to say about reading proficiency to come of as friendly. > > > >> >> > >> > >> >> >> >> Your rants and all caps won't make anything change. Please try to >> >deal >> >> with it and move on from this rather dead thread. >> > >> > >> >My apologies for interrupting your daily mailing list programming of >> >package orphaning/retirement. I know everyone's waiting on their >seats >> >in anticipation of what packages are going orphaned/retired next, >but >> >the current discussion has evolved into something that very much >> >impacts >> >that very issue. >> >> How about not interrupting that with something that was very clearly >> explained to you about 50 mails ago? >> >> > >> > >> >Let me break it down for you: >> > >> > >> >1. More fragmentation means more work to maintain and test >everything. >> > >> > >> >2. More work to maintain and test everything requires more people. >> > >> > >> >3. More people means more roles that have to be filled which require >> >experience. >> > >> > >> >4. Different people have different ideas on approaching problems, >and >> >since they have experience, they use that experience to fragment the >> >desktop even more instead of compromising or working together. This >is >> >*Fedora* >> > >> > >> >5. More fragmentation angers developers who want to support the >> >platform >> >since they can't ensure that their software works remotely >> >consistently. >> >This is *me*. >> > >> > >> >6. Angry developers means less software for Linux. >> > >> > >> >7. Less software for Linux mea
Re: RPM Fusion Bugzilla Bug 5307
On 23 September 2019 21:58:02 CEST, Ty Young wrote: > >On 9/23/19 1:53 PM, Markus Larsson wrote: >> You already have a solution. Use the solution you have. > > >Not a solution, it's a bandaid to a much larger problem. You said it works fine in Arch. So use Arch. You say that it can be configured easily in Fedora so do that and use Fedora. Those are solutions to your problem. > > >> Fedora will not change to cater to this particular need. >> Your opinions does not dictate what Fedora should/shouldn't do. > > >Yet Fedora expects other distros/DEs, *including their own spins* to >cater to their decisions when those decisions aren't wanted or >technically possible to begin with. That's hypocritical. As a Fedora user I don't expect to be able to demand what defaults Void or Arch or Gentoo should have. > > >> >> Your rants and all caps won't make anything change. Please try to >deal >> with it and move on from this rather dead thread. > > >My apologies for interrupting your daily mailing list programming of >package orphaning/retirement. I know everyone's waiting on their seats >in anticipation of what packages are going orphaned/retired next, but >the current discussion has evolved into something that very much >impacts >that very issue. How about not interrupting that with something that was very clearly explained to you about 50 mails ago? > > >Let me break it down for you: > > >1. More fragmentation means more work to maintain and test everything. > > >2. More work to maintain and test everything requires more people. > > >3. More people means more roles that have to be filled which require >experience. > > >4. Different people have different ideas on approaching problems, and >since they have experience, they use that experience to fragment the >desktop even more instead of compromising or working together. This is >*Fedora* > > >5. More fragmentation angers developers who want to support the >platform >since they can't ensure that their software works remotely >consistently. >This is *me*. > > >6. Angry developers means less software for Linux. > > >7. Less software for Linux means less users. > > >8. Less users means a smaller pool of potential people to fill empty >roles. > > >9. Empty roles means things go stale, bugs go unfixed, and no one has >experience. > > >Make any sense? I know it doesn't perfectly loop back at the end but >1-4 >does. No your unrelated 9 step venting does not make any sense unless of course your aim was to be rude in a new and slightly more amusing way. One thing peaked my interest though, what software is it that you wanted to "support the platform" with? > > >> >> Br >> M >> >> On 23 September 2019 20:38:13 CEST, Ty Young >> wrote: >> >> >> On 9/23/19 10:00 AM, Michael Catanzaro wrote: >>> On Mon, Sep 23, 2019 at 9:50 am, Michael Catanzaro >>> wrote: >>>> You're wasting your time. We're not going to run the X server >as >>>> root just so you can overclock your GPU. Not a chance. >>> >> >> It isn't just to overclock my GPU, you're *BREAKING PEOPLE'S >> SOFTWARE, EVEN IF THEY ARE FLATPAK*. The whole point of Flatpak >> for an end user is cross-distro compatibility! >> >> >>> Anyway, while we won't do that Fedora... since you're clearly >>> interested in customizing your system, you can do so for >>> yourself. What you want to do is build gdm using the configure >>> flag --disable-user-display-server. You can host your special >gdm >>> in a copr if you want to make it easier for other Nvidia >>> overclockers to use it. >> >> >> This is entirely unnecessary. You can enable root X. Org via the >> config option. A random user's COPR repo isn't a whole lot safer. >> >> >>> >>> See https://fedoraproject.org/wiki/Changes/XorgWithoutRootRights >>> for why this was changed (over five years ago!). The changes >were >>> made upstream, so there is nothing Fedora-specific here. If you >>> use GNOME on most other distros, you should see the same >behavior. >> >> >> Five years ago and yet no other DE besides Gnome supports it. >Five >> years and many distros that even use Gnome don't even have it >> enabled by default. Five years and Fedora has done nothing to >make >> other DEs support it despite the fact that Fedora is the only one >> that actually wants the change
Re: RPM Fusion Bugzilla Bug 5307
You already have a solution. Use the solution you have. Fedora will not change to cater to this particular need. Your opinions does not dictate what Fedora should/shouldn't do. Your rants and all caps won't make anything change. Please try to deal with it and move on from this rather dead thread. Br M On 23 September 2019 20:38:13 CEST, Ty Young wrote: > >On 9/23/19 10:00 AM, Michael Catanzaro wrote: >> On Mon, Sep 23, 2019 at 9:50 am, Michael Catanzaro >> wrote: >>> You're wasting your time. We're not going to run the X server as >root >>> just so you can overclock your GPU. Not a chance. >> > >It isn't just to overclock my GPU, you're *BREAKING PEOPLE'S SOFTWARE, >EVEN IF THEY ARE FLATPAK*. The whole point of Flatpak for an end user >is >cross-distro compatibility! > > >> Anyway, while we won't do that Fedora... since you're clearly >> interested in customizing your system, you can do so for yourself. >> What you want to do is build gdm using the configure flag >> --disable-user-display-server. You can host your special gdm in a >copr >> if you want to make it easier for other Nvidia overclockers to use >it. > > >This is entirely unnecessary. You can enable root X. Org via the config > >option. A random user's COPR repo isn't a whole lot safer. > > >> >> See https://fedoraproject.org/wiki/Changes/XorgWithoutRootRights for >> why this was changed (over five years ago!). The changes were made >> upstream, so there is nothing Fedora-specific here. If you use GNOME >> on most other distros, you should see the same behavior. > > >Five years ago and yet no other DE besides Gnome supports it. Five >years >and many distros that even use Gnome don't even have it enabled by >default. Five years and Fedora has done nothing to make other DEs >support it despite the fact that Fedora is the only one that actually >wants the change to begin with. > > >Lets *actually read* that link, shall we? > > > >The user experience will be unchanged > > >This is a blatant lie. Breaking people's software absolutely impacts >the >user experience. > > >>Desktop product: gdm, Ray Strode is working on this: ? > >>KDE spin: ? > > >XFCE spin: ? > > >LXDE spin: ? > > >Look at that broad DE support. It's *almost* like no one cares or wants > >this, even after 5 years! There are still open bug reports on multiple >distros/DEs that haven't been worked on or updated in years. > > > >Having the xserver not run as root reduces Fedora's attack surface. > > >...which few other Linux distro cares about and is seemingly just a >boogeyman used to fearmonger since no one can pin point actual >malicious >software that takes advantage of it to begin with. > > >If you're so afraid of the X. Org as root boogeyman then oh boy, allow >me to turn it up a notch by telling you just *some* of the things >possible with basic *user* account permissions. You can: > > >-reboot/shutdown > > >-silently lockup the system by spawning too many threads > > >-hard lock the system by passing allowed but unsupported values > > >-fill up memory, resulting in HDD thrashing and potentially killing >your SSD > > >-create other processes(pop up windows) > > >-kill other processes > > >-upload all your files in your home directory to a personal private >server > > >-delete all your files in your home directory > > >-encrypt all your files in your home directory. > > >...among a whole lot else I'm probably forgetting. > > >Point is, at some point you need to let the security crap go. No one >else cares besides Fedora and Gnome. > > > >> The only distro I know of that uses --disable-user-display-server is >> Endless. >> >> Michael >> >> ___ >> 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 ___ 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: Debates/back and forths
On 28 August 2019 13:34:54 CEST, "Dan Čermák" wrote: >Hi Danni, > >Danny Lee writes: > >> Hi all, >> >> I'm new to the devel list and fedora in general, but i was wondering >if >> these kind of back and forths between a few people is a frequent >> occurrence. I came to Fedora to volunteer what little spare time I >have >> to help the Fedora project in some little ways. I don't feel that >should >> include wading through dozens of emailed back and forths between >> individuals who seem to have strong, immovable opinions, I just don't > >> have time for that. > >Welcome to the club of all the "silent" contributors! > >Usually I try to follow discussions if they appear relevant or >interesting to me, but once they "tip over", I mark that thread as >deleted and mercilessly nuke everything new that comes in. >Yeah, I might miss some important information, but it's unlikely tbh >once you are 20 replies deep into a thread. >On the other hand: I don't want to spend all my free time reading >emails. > >So, if you don't care about a specific topic: just ignore & delete it. This is how I think most do it. Just read the interesting parts. > > >Btw, this list is imho still pretty moderate, only the occasional >controversy causes a huge thread of replies (and people manage to stay >civilized and tend to bring in new arguments). There's other lists >(unnamed to protect the guilty) where the signal to noise ratio is >much, >much worse. The discourse debate and the fw debate are not the norm but the exception. We see a few of those from time to time. Most threads aren't like that though. > >> >> Is there any chance there is a moderated list or discussion group >about >> current project tasks and issues rather than debates about how to do >> things? Or perhaps, a way to turn off certain threads or block >certain >> posters? >> >> Thanks for your time and info you can provide. >> ___ >> 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 ___ 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: No longer supporting mailing lists:
I'm entirely fine with using discourse WHEN it has a functioning mailing list mode. I am not against discourse as such, I am against making changes that forces everyone to consume the information in exactly the same way. Ensure that mailing list mode works in a way that the ones who needs that feature approves of and I will switch sides in an instant. I will not applaud a change where I see no benefit and where it impacts others. Br M On 27 August 2019 17:44:16 CEST, Dan Book wrote: >This conversation is pretty pointless. You are never going to convince >other people to like Discourse more than mailing lists, and they are >never >going to convince you the other direction. > >-Dan > >On Tue, Aug 27, 2019 at 11:35 AM Gerald B. Cox wrote: > >> Here is an interesting discussion on "threaded discussions": >> >https://meta.discourse.org/t/threaded-discussion-is-ultimately-too-complex-to-survive-on-the-public-internet/63172 >> >> I personally don't like them. As the threads increase the discussion >> becomes hard to follow... >> >> On Tue, Aug 27, 2019 at 12:20 PM Louis Lagendijk >wrote: >> >>> On Tue, 2019-08-27 at 12:00 -0300, Gerald B. Cox wrote: >>> >>> Why is it when I say that I don't want to clutter up my email with >mail >>> from mailing lists I'm told it's a misconfiguration. It's not a >>> misconfiguration. I don't want the forum email cluttering up my >mail - and >>> I don't want to use an NNTP gateway, I want to use Discourse. Why >is that >>> so hard to understand? >>> >>> On Tue, Aug 27, 2019 at 11:47 AM John Harris >>> wrote: >>> >>> On Tuesday, August 27, 2019 7:29:28 AM MST Gerald B. Cox wrote: >>> > Using mail, I have to access the archives to read the full >thread. >>> >>> This is just due to your configuration. You could easily either save >the >>> mailing list to your mailbox, or use an NNTP gateway. >>> >>> Different people have different work flows, you like to go to >Discourse, others prefer mail/nntp. For a lot of people (including >myself) the lack of threading is a show stopper for their workflow. >>> >>> >>> The mail interface in Discourse is...lacking a lot of features for a >lot of people. Your comment "why is that so hard to understand" applies >both ways >>> >>> /Louis >>> >>> ___ >>> 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 >>> >> ___ >> 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 >> ___ 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: No longer supporting mailing lists:
On 27 August 2019 16:29:28 CEST, "Gerald B. Cox" wrote: >Thanks for the offer, but no thanks. My point is I don't like using >email >for forum discussions. The only reason I'm using it here is that I'm >being >forced to because "Development Discussions", "KDE Discussions" and >"Packaging Discussions" aren't available on the Discourse Fedora >instance. >As I mentioned before, I don't like the idea of forum discussions >clogging >up my email. I like accessing Fedora Discussions on my phone using the >Discourse client. It's much easier to read threads for me and >understand >prior elements of the discussion on Discourse. Using mail, I have to >access the archives to read the full thread. So everyone should stop doing what works for the because you don't like it? > >Seems to me to be a bit weird that Fedora has some discussions on >Discourse >but refuses to allow other discussions and mandate those be done via a >mailing list - especially when Discourse allows a mailing list option. Please try to understand that the mailing list option isn't an option because it is not good enough. Meanwhile what is left is the webUI. So we should all have to use that UI because that is what works best for you? Is that the central point of your argument? > >I understand there isn't going to be 100% feature parity, but it should >be >good enough - and if it isn't we should be working with the Discourse >people to improve it rather than just using it as an excuse to not >moving >forward. Before moving forward it is prudent to ensure that at least most of the group agree what "forward" is. It seems not everyone agrees that the direction you have chosen is actually forward. ___ 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: No longer supporting mailing lists:
On 27 August 2019 14:23:48 CEST, "Gerald B. Cox" wrote: >I read all the comments and my response is this... >First of all, there is no limit to the amount of emails that discourse >will >send out. That is a site parameter, and whomever supports it for >Fedora >needs to change it: > >https://meta.discourse.org/t/daily-limits-for-outgoing-mails-per-user/41458 > >If the requirement is that discourse completely replicate 100% the >functionality of mailing lists, that is unreasonable and isn't going to >happen. As I mentioned earlier there are several groups working on >this or >have done migration from mailing lists to discourse: > >https://discourse-mediawiki.wmflabs.org/t/lets-try-to-emulate-a-mailing-list/1003 >https://meta.discourse.org/t/discourse-vs-mailing-lists-majordomo-or-otherwise/65769 > >You can find more examples with a web search. > >A key comment was: "Our site is still quite busy, although some people >are >still grumbling about the change, 8 months later. The die-hard email >users >are still able to participate, which came as a bit of a pleasant shock >to >them. I think they were fully expecting that once we moved to a modern >platform, they’d be forced to use a web interface." > >Personally, I don't like my mailbox filled up with mailing list >postings. >I prefer to uses the discourse rss interface to scan for topics and >then go >directly to it to respond. Instead of writing a "me too" email, I can >simply click a like button to show I'm in agreement. It's easier to >see >the full context of a thread. With the current situation I have to go >scan >the archives. I like to use the mobile app to read and reply from my >phone. For every item mentioned about discourse doesn't do A, B, C >with >mailing lists I can counter with an item that email lists cannot do. >The >fact is that for the vast majority of people, the discourse mailing >list >functionality is good enough - and as time goes on it continues to >improve >- but again, it's not reasonable to expect or demand 100%. IMO the >pros >outweigh the cons. > >The top of this email thread is: No longer supporting mailing lists >and my understanding is that Fedora is searching for people to take >over >support. Seems to me that is a good time to consider switching to >discourse. From reading experiences of people who did the migration, >it's >easier to support. But the way to go about a change isn't to start the change and see what happens. The proper way is to look at the alternatives at hand and what the implications of the respective solutions are. That means a wee bit more analysis than linking to a marketing post by one of the providers of solutions. I understand that you like discourse, you have made that clear. ___ 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: No longer supporting mailing lists:
On 26 August 2019 17:28:03 CEST, "Gerald B. Cox" wrote: >> On 26 August 2019 16:04:12 CEST, "Gerald B. Cox" wrote: >> >> The only reason to bring it up when replying to me is that you think >it applies here. So >> while you explicitly did not mention me there's not very many other >ways it can be >> interpreted. >> >> So the best way is to sneak it in? >> That is exactly how one introduces new services if one wants them to >be impossible to back >> away from. This will of course split the community in a way that will >lead to flame war. I >> think that should be avoided. >> >> It's much better to make a dummy thread long enough so that those who >wants can test >> the platform before this list is fragmented. >> >Sounds to me like you're projecting. Relax. No one is talking about >"sneaking" or "flame wars" except you. Allowing people to try it out >in a real environment will allow them to vote with their participation. > Please explain exactly what I am projecting. As for the relax part, I suggest you read my emails in a calmer tone. You will find that how you interpret my messages will be greatly different. BR M ___ 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: No longer supporting mailing lists:
On 26 August 2019 16:04:12 CEST, "Gerald B. Cox" wrote: >> On 26 August 2019 14:27:53 CEST, "Gerald B. Cox" wrote: >> >> Was it a lengthy conversation where you needed context from earlier >posts? >> Was is easily at hand right in your email client? >> >> >> That's exactly my point. The advantages listed are mere stated >opinions. Except >> editing and community moderation which are actual features. >> >> >> Writing this off as me being hostile to change is not only wrong but >also rather snarky. >> Did you intend that? >> >> Every time discourse is brought up it seems that anyone asking what >will be better over >> maillinglists are accused of being hostile to change, this time is >not different. >> > >I didn't mention you, I simply stated that there are people who are >hostile and resistant to change. That is a fact... you only need do a >simple google search every time there is a change and some people >always complain. In fact, the recent changes to Firefox extensions >come to mind. You had people angrily say they would ditch Fx, etc. >etc. etc. Such tactics are IMO not constructive. The only reason to bring it up when replying to me is that you think it applies here. So while you explicitly did not mention me there's not very many other ways it can be interpreted. > >The best way to solve this is to create a duplicate discussion group on >Discourse for Development and monitor it's use. The only way people >are going to be able to decide if it's good for them or not is to try >it. So the best way is to sneak it in? That is exactly how one introduces new services if one wants them to be impossible to back away from. This will of course split the community in a way that will lead to flame war. I think that should be avoided. It's much better to make a dummy thread long enough so that those who wants can test the platform before this list is fragmented. BR M ___ 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: No longer supporting mailing lists:
On 26 August 2019 14:27:53 CEST, "Gerald B. Cox" wrote: >> It seems that the only thing in that link that has merit in regards >to this list is that >> discourse allow editing of messages that has been sent. >> >> As for the other things I disagree with pretty much everything. I >don't think email is >> too hard to use, I don't think large mailinglists are a problem, I >don't see any >> spam here, I don't think linking to things in emails is hard etc. >> >> Discourse has many uses but it pushes people toward a single >interface where as >> mailinglists let's people be much more free to choose their own >interfaces. >> And yes, discourse can email me when things happen, the formatting of >mail does make >> following the conversation much harder than a simple maillinglist. >> >> I also thought this was discussed earlier this year and that the >conclusion was that >> discourse was a bad fit. >> > >I received an email from Fedora Discourse earlier this week and it >looked fine. I was able to reply directly or press a button which >opened up the web interface. Are there differences that I didn't >notice? Probably... would most people notice them... probably not. Was it a lengthy conversation where you needed context from earlier posts? Was is easily at hand right in your email client? > >As far as you not considering the other advantages listed as >meaningful, that's your opinion and you're welcome to it. I simply >disagree. That's exactly my point. The advantages listed are mere stated opinions. Except editing and community moderation which are actual features. > >As far as discourse being a bad fit, I also disagree. Whenever change >happens some people are always resistant... but to make progress change >is required and legacy items are sometimes impacted some examples >are KDE 3 to 4 to 5 - GNOME 2.3 to 3... Python 2.7 to 3... the list >goes on. Writing this off as me being hostile to change is not only wrong but also rather snarky. Did you intend that? Every time discourse is brought up it seems that anyone asking what will be better over maillinglists are accused of being hostile to change, this time is not different. > >___ >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 ___ 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: No longer supporting mailing lists:
It seems that the only thing in that link that has merit in regards to this list is that discourse allow editing of messages that has been sent. As for the other things I disagree with pretty much everything. I don't think email is too hard to use, I don't think large mailinglists are a problem, I don't see any spam here, I don't think linking to things in emails is hard etc. Discourse has many uses but it pushes people toward a single interface where as mailinglists let's people be much more free to choose their own interfaces. And yes, discourse can email me when things happen, the formatting of mail does make following the conversation much harder than a simple maillinglist. I also thought this was discussed earlier this year and that the conclusion was that discourse was a bad fit. BR M On 26 August 2019 13:33:38 CEST, "Gerald B. Cox" wrote: >If you disagree with something that is stated, you need to in detail >explain why, not just claim it is marketing and therefore invalid. > >On Mon, Aug 26, 2019 at 8:30 AM Markus Larsson >wrote: > >> >> >> On 26 August 2019 13:25:52 CEST, "Gerald B. Cox" >wrote: >> >Here you go... >> >https://meta.discourse.org/t/discourse-vs-email-mailing-lists/54298 >> >> Yes, I'm aware of their marketing. What I was after was data from >someone >> that doesn't have a horse in the race. >> ___ >> 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 >> ___ 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: No longer supporting mailing lists:
On 26 August 2019 13:25:52 CEST, "Gerald B. Cox" wrote: >Here you go... >https://meta.discourse.org/t/discourse-vs-email-mailing-lists/54298 Yes, I'm aware of their marketing. What I was after was data from someone that doesn't have a horse in the race. ___ 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: No longer supporting mailing lists:
On 26 August 2019 12:56:42 CEST, "Gerald B. Cox" wrote: What issues are you referring to? I don't believe it is reasonable to believe everything would work exactly the same with Discourse - but close enough should be sufficient. There are also myriad advantages to Discourse. Are these advantages actually documented somewhere? This move to discourse issue seems to pop up ever so often. People always claim that there are a tonne of advantages but there rarely are any mention of actual advantages. BR Markus___ 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
