Re: Fedora 33 System-Wide Change proposal: Make nano the default editor
Makes sense to me. Many people do not know how to use vi/vim and don't want to spend time learning arcane commands just to edit a bit of text. This would also put Fedora in line with other distros such as Ubuntu. Those of us who actually *want* to use a different editor can also easily change this setting via the $EDITOR environment variable. On 6/25/2020 1:18 PM, 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 > > > == Detailed Description == > > Users are exposed to the default editor when they use commands that > call it. The main example here is something like git > commit. > > Fedora does not currently have a default terminal text editor, because > the $EDITOR environment variable is unset by default. But a common > scenario where users wind up in a terminal text editor is when using > 'git commit'. By default, git picks vi. You need to spend time > learning how to use it, for even basic editing tasks. This increases > the barrier to entry for those who are switching to Fedora and don't > know how to use vi. It also makes things hard for those who don't > particularly want to learn how to use vi. (These arguments would apply > just as well if git picked Vim. vi is like hard mode for Vim, with > fewer features, missing syntax highlighting, and no indication of what > mode you are in. Even Vim users may feel lost and bewildered when > using vi.) > > In contrast, Nano offers the kind of graphical text editing experience > that people are used to, and therefore doesn't require specialist > knowledge to use. It is already installed across most Fedora Editions > and Spins. This proposal will make Nano the default editor, while > continuing to install vim-minimal (which provides vi, but > not Vim). People will still be able to call vi if they > want to edit a file. It will also obviously be possible to change the > default editor to vi or Vim, for those who want it. > > Why make Nano default and vi optional, rather than the other way > round? Because Nano is the option that everyone can use. > > == Feedback == > > Pending ... > > == Benefit to Fedora == > > * Makes the default editor across all of Fedora more approachable. > * Nano is also mostly self-documenting, by displaying common keyboard > shortcuts on-screen. > * More in line with the default editor of other distributions. > > == Scope == > * Proposal owners: > ** Modify comps to include nano Fedora wide. > ** Create a new subpackage of nano, called > nano-editor. > ** nano-editor to include > /usr/lib/environment.d/10-nano.conf, which sets > $EDITOR to nano. > > With this approach, if nano is uninstalled, the > configuration will be removed with it. At the same time, installing > nano on its own won't install the conf. > > * Other developers: N/A > > * Release engineering: [https://pagure.io/releng/issue/9522 #9522] > > * Policies and guidelines: N/A > > * Trademark approval: N/A > > == Upgrade/compatibility impact == > > Will not apply to upgrades. > > == How To Test == > > Run export EDITOR="/usr/bin/nano". > > == User Experience == > > Users running git commit will be able to just type their > commit message, rather than having to learn about insert mode, and > they'll be able to cut and paste without having to learn special > shortcuts. > > == Dependencies == > > No additional dependencies are required. > > == Contingency Plan == > The contingency plan is to revert the change by removing the > nano-editor package. > > * Contingency deadline: probably the beta? It's an easy change to revert. > * Blocks release? If the change breaks the redirection to an editor, > it should block the release. However, this is unlikely. > * Blocks product? Potentially all. > > == Documentation == > As part of this change, it would be good to add instructions for > changing the default editor to the > [https://docs.fedoraproject.org/en-US/quick-docs/ quick docs]. > > ___ 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
It should really be no more effort than running your puppet agent or an ansible job. Those are minor configuration changes and are easily automated. Also, stopdisablingselinux.com ;) On 6/25/2020 2:50 PM, Jan Kratochvil wrote: > With each such > step it takes more and more effort to make a new Fedora installation usable by > a developer (setenforce 0, dnf remove bash-completion, remove rhgb quiet > etc.). ___ 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
Why not zfs? On 6/26/2020 10:42 AM, Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/BtrfsByDefault > > == Summary == > > 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. > > == Owners == > > * Names: [[User:Chrismurphy|Chris Murphy]], [[User:Ngompa|Neal > Gompa]], [[User:Josef|Josef Bacik]], [[User:Salimma|Michel Alexandre > Salim]], [[User:Dcavalca|Davide Cavalca]], [[User:eeickmeyer|Erich > Eickmeyer]], [[User:ignatenkobrain|Igor Raits]], > [[User:Raveit65|Wolfgang Ulbrich]], [[User:Zsun|Zamir SUN]], > [[User:rdieter|Rex Dieter]], [[User:grinnz|Dan Book]], > [[User:nonamedotc|Mukundan Ragavan]] > * Emails: chrismur...@fedoraproject.org, ngomp...@gmail.com, > jo...@toxicpanda.com, mic...@michel-slm.name, dcava...@fb.com, > er...@ericheickmeyer.com, ignatenkobr...@fedoraproject.org, > fed...@raveit.de, z...@fedoraproject.org, rdie...@gmail.com, > gri...@gmail.com, nonamed...@gmail.com > > * Products: All desktop editions, spins, and labs > * Responsible WGs: Workstation Working Group, KDE Special Interest Group > > > == Detailed Description == > > Fedora desktop edition/spin variants will switch to using Btrfs as the > filesystem by default for new installs. Labs derived from these > variants inherit this change, and other editions may opt into this > change. > > The change is based on the installer's custom partitioning Btrfs > preset. It's been well tested for 7 years. > > 'Current partitioning' > vg/root LV mounted at style="color: tomato">/ and a vg/home LV mounted at /home. These are separate file system volumes, with > separate free/used space. > > 'Proposed partitioning' > root subvolume mounted at style="color: tomato">/ and home subvolume mounted at /home. Subvolumes don't have size, they act mostly like > directories, space is shared. > > 'Unchanged' > /boot will be a small ext4 volume. > A separate boot is needed to boot dm-crypt sysroot installations; it's > less complicated to keep the layout the same, regardless of whether > sysroot is encrypted. There will be no automatic snapshots/rollbacks. > > If you select to encrypt your data, LUKS (dm-crypt) will be still used > as it is today (with the small difference that Btrfs is used instead > of LVM+Ext4). There is upstream work on getting native encryption for > Btrfs that will be considered once ready and is subject of a different > change proposal in a future Fedora release. > > === Optimizations (Optional) === > > The detailed description above is the proposal. It's intended to be a > minimalist and transparent switch. It's also the same as was > [[Features/F16BtrfsDefaultFs|proposed]] (and > [https://lwn.net/Articles/446925/ accepted]) for Fedora 16. The > following optimizations improve on the proposal, but are not critical. > They are also transparent to most users. The general idea is agree to > the base proposal first, and then consider these as enhancements. > > Boot on Btrfs > > * Instead of a 1G ext4 boot, create a 1G Btrfs boot. > * Advantage: Makes it possible to include in a snapshot and rollback > regime. GRUB has stable support for Btrfs for 10+ years. > * Scope: Contingent on bootloader and installer team review and > approval. blivet should use mkfs.btrfs --mixed. > > Compression > > * Enable transparent compression using zstd on select directories: > /usr/var/lib/flatpak~/.local/share/flatpak > * Advantage: Saves space and significantly increase the lifespan of > flash-based media by reducing write amplification. It may improve > performance in some instances. > * Scope: Contingent on installer team review and approval to enhance > anaconda to perform the installation using mount -o > compress=zstd, then set the proper XATTR for each directory. > The XATTR can't be set until after the directories are created via: > rsync, rpm, or unsquashfs based installation. > > Additional subvolumes > > * /var/log//var/lib/libvirt/images and ~/.local/share/gnome-boxes/images/ will use separate > subvolumes. > * Advantage: Makes it easier to excluded them from snapshots, > rollbacks, and send/receive. (Btrfs snapshotting is not recursive, it > stops at a nested subvolume.) > * Scope: Anaconda knows how to do this already, just change the > kickstart to add additional subvolumes (minus the subvolume in style="color: tomato">~/. GNOME Boxes will need enhancement to > detect that the user home is on Btrfs and create ~/.local/share/gnome-boxes/images/ as a subvolume. > > == Feedback == > > Red Hat doesn't support Btrfs? Can Fedora do this? > > Red Hat supports Fedora well, in many ways. But Fedora already works >
Re: nfs-utils-2.1.1 Changes Everything!
Ideally the package should have an upgrade script included to translate any values set in /etc/sysconfig/nfs into /etc/nfs.conf. I also believe it would be best to hold off any breaking changes until Fedora 26. On 1/16/17 5:24 PM, Steve Dickson wrote: > I can't agree with this more... How does one migrate from one configuration > model to another? This is exactly why I'm bring this up to the community. > > I will be more than willing to work with any project to make this transition > be as smooth as possible. > > steved. > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
dnf system-upgrade fails
I have a server running Fedora 24 which I am attempting to upgrade to Fedora 25. I've followed the instructions located at https://fedoraproject.org/wiki/DNF_system_upgrade however the upgrade process fails after the system is rebooted to run the initial upgrade. Here are the log entries from my dnf.log file which show some errors. Jan 16 10:40:16 DEBUG --> Starting dependency resolution Jan 16 10:40:16 DEBUG --> Finished dependency resolution Jan 16 10:40:16 DDEBUG timer: depsolve: 166 ms Jan 16 10:40:16 SUBDEBUG Traceback (most recent call last): File "/usr/lib/python3.5/site-packages/dnf/cli/main.py", line 120, in _main ret = resolving(cli, base) File "/usr/lib/python3.5/site-packages/dnf/cli/main.py", line 139, in resolving base.resolve(cli.demands.allow_erasing) File "/usr/lib/python3.5/site-packages/dnf/base.py", line 541, in resolve raise exc dnf.exceptions.DepsolveError: nothing provides kmod-libs(x86-64) = 23-1.fc25 needed by kmod-23-1.fc25.x86_64. nothing provides iptables-libs(x86-64) = 1.6.0-2.fc25 needed by iptables-1.6.0-2.fc25.x86_64. nothing provides adwaita-gtk2-theme = 3.22.2-1.fc25 needed by gnome-themes-standard-3.22.2-1.fc25.x86_64. nothing provides fipscheck-lib(x86-64) = 1.4.1-11.fc25 needed by fipscheck-1.4.1-11.fc25.x86_64. nothing provides system-release(25) needed by fedora-repos-25-1.noarch. nothing provides python3-dnf-plugins-core = 0.1.21-4.fc25 needed by dnf-plugins-core-0.1.21-4.fc25.noarch. package cockpit-shell-120-1.fc25.noarch is not installable. nothing provides python2-future needed by python2-stomper-0.4.0-2.fc25.noarch. nothing provides python-click needed by python2-flask-1:0.11.1-3.fc25.noarch. package cronie-anacron-1.5.1-2.fc24.x86_64 requires cronie = 1.5.1-2.fc24, but none of the providers can be installed. package cryptsetup-1.7.2-1.fc24.x86_64 requires cryptsetup-libs = 1.7.2-1.fc24, but none of the providers can be installed. package dhcp-client-12:4.3.4-3.fc24.x86_64 requires dhcp-common = 12:4.3.4-3.fc24, but none of the providers can be installed. package file-5.25-6.fc24.x86_64 requires file-libs = 5.25-6.fc24, but none of the providers can be installed. package ipset-6.27-2.fc24.x86_64 requires ipset-libs(x86-64) = 6.27-2.fc24, but none of the providers can be installed. nothing provides iptables-libs(x86-64) = 1.6.0-2.fc25 needed by iptables-1.6.0-2.fc25.x86_64 Jan 16 10:40:16 CRITICAL Error: nothing provides kmod-libs(x86-64) = 23-1.fc25 needed by kmod-23-1.fc25.x86_64. nothing provides iptables-libs(x86-64) = 1.6.0-2.fc25 needed by iptables-1.6.0-2.fc25.x86_64. nothing provides adwaita-gtk2-theme = 3.22.2-1.fc25 needed by gnome-themes-standard-3.22.2-1.fc25.x86_64. nothing provides fipscheck-lib(x86-64) = 1.4.1-11.fc25 needed by fipscheck-1.4.1-11.fc25.x86_64. nothing provides system-release(25) needed by fedora-repos-25-1.noarch. nothing provides python3-dnf-plugins-core = 0.1.21-4.fc25 needed by dnf-plugins-core-0.1.21-4.fc25.noarch. package cockpit-shell-120-1.fc25.noarch is not installable. nothing provides python2-future needed by python2-stomper-0.4.0-2.fc25.noarch. nothing provides python-click needed by python2-flask-1:0.11.1-3.fc25.noarch. package cronie-anacron-1.5.1-2.fc24.x86_64 requires cronie = 1.5.1-2.fc24, but none of the providers can be installed. package cryptsetup-1.7.2-1.fc24.x86_64 requires cryptsetup-libs = 1.7.2-1.fc24, but none of the providers can be installed. package dhcp-client-12:4.3.4-3.fc24.x86_64 requires dhcp-common = 12:4.3.4-3.fc24, but none of the providers can be installed. package file-5.25-6.fc24.x86_64 requires file-libs = 5.25-6.fc24, but none of the providers can be installed. package ipset-6.27-2.fc24.x86_64 requires ipset-libs(x86-64) = 6.27-2.fc24, but none of the providers can be installed. nothing provides iptables-libs(x86-64) = 1.6.0-2.fc25 needed by iptables-1.6.0-2.fc25.x86_64 Jan 16 10:40:16 INFO (try to add '--allowerasing' to command line to replace conflicting packages) Jan 16 10:40:16 DDEBUG Cleaning up. Is there a way to resolve this? I tried adding the --allowerasing option which resulted in dnf attempting to remove the dnf and systemd packages. Jan 16 11:29:41 SUBDEBUG Traceback (most recent call last): File "/usr/lib/python3.5/site-packages/dnf/cli/main.py", line 60, in main return _main(base, args) File "/usr/lib/python3.5/site-packages/dnf/cli/main.py", line 120, in _main ret = resolving(cli, base) File "/usr/lib/python3.5/site-packages/dnf/cli/main.py", line 142, in resolving base._plugins.run_resolved() File "/usr/lib/python3.5/site-packages/dnf/plugin.py", line 82, in fn dnf.util.mapall(operator.methodcaller(method), self.plugins) File "/usr/lib/python3.5/site-packages/dnf/util.py", line 183, in mapall return list(map(fn, *seq)) File "/usr/lib/python3.5/site-packages/dnf-plugins/protected_packages.py", line 76, in resolved raise dnf.exceptions.Error(THREATENED_MSG % ', '.join(threatened)) dnf.exceptions.Error: The operation wo
Re: dnf system-upgrade fails
It looks like there's an old facter package installed which is a dependency pulled in by puppet. The interesting thing here is that the package references *f23* which has never been installed on this VM. Here are the packages returned by the rpm command. [root@git ~]# rpm -qa|grep -vE '\.fc2[456]|gpg-pubkey|debuginfo' fedora-repos-24-3.noarch facter-2.4.3-1.fc23.x86_64 rpmfusion-free-release-24-3.noarch fedora-package-config-apt-16.00-8.noarch fedora-release-24-2.noarch fedora-release-server-24-2.noarch rpmfusion-nonfree-release-24-3.noarch On 01/16/2017 10:56 PM, Zbigniew Jędrzejewski-Szmek wrote: > On Mon, Jan 16, 2017 at 10:05:38PM -0500, Michael Watters wrote: >> package cronie-anacron-1.5.1-2.fc24.x86_64 requires cronie = >> 1.5.1-2.fc24, but none of the providers can be installed. >> package cryptsetup-1.7.2-1.fc24.x86_64 requires cryptsetup-libs = >> 1.7.2-1.fc24, but none of the providers can be installed. >> package dhcp-client-12:4.3.4-3.fc24.x86_64 requires dhcp-common = >> 12:4.3.4-3.fc24, but none of the providers can be installed. >> package file-5.25-6.fc24.x86_64 requires file-libs = 5.25-6.fc24, but >> none of the providers can be installed. >> package ipset-6.27-2.fc24.x86_64 requires ipset-libs(x86-64) = >> 6.27-2.fc24, but none of the providers can be installed. > It looks like something is holding back the upgrade. Normally this > should get detected in the 'dnf system-upgrade --download' phase, > and not after reboot, but let's ignore that for now. > > Do you have some very old packages that don't have an upgrade > and are not obsoleted by anything? I'd guess that one of them is > holding back either cryptsetup-libs or file-libs or ipset-libs... > Try rpm -qa|grep -vE '\.fc2[456]|gpg-pubkey|debuginfo' > > Zbyszek > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Let's talk about Fedora in the '20s!
It would be in RedHat's own best interest to promote the Fedora project more though. Isn't Fedora supposed to be the upstream/testing grounds for RHEL releases? What's the best way to learn and get familiar with a RedHat based environment? It's Fedora, although I do know RHEL offers free developer licenses and CentOS is always there as well. On 1/7/20 12:39 PM, Adam Williamson wrote: > On Tue, 2020-01-07 at 11:37 -0600, Joe Doss wrote: >> On 1/7/20 11:33 AM, Adam Williamson wrote: >>> If anyone has a handy generous multi-millionaire up their sleeve, >>> please call Matt. :) >> *coughs* Red Hat... > I *did* say "generous" ___ 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: Git Forge Requirements: Please see the Community Blog
On 1/21/20 4:31 PM, Michael Catanzaro wrote: > On Tue, Jan 21, 2020 at 4:04 pm, Neal Gompa wrote: >> And any discussion of GitHub isn't going to involve self-hosted, it's >> going to involve GitHub.com, which means we're talking about losing >> more of our independence as a project. This is one of those things >> that I'm not sure is a wise move. > > Well since we have a request for requirements: I propose requirements > #1 and #2 are to be self-hosted and open source. I'm suspect the > Fedora community would be outraged if we fail to meet either requirement. I second this. FOSS is what's allowed RedHat to succeed and it would really suck to see Fedora switch to a closed source platform that's owned by Microsoft... Also, as somebody who runs a self hosted pagure server I would really hate to see pagure go away. I understand Pingou may not have the time to work on the project as in the past but the torch should definitely be passed to somebody else or the community to continue work on the project. ___ 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: Git Forge Requirements: Please see the Community Blog
On 1/21/20 4:59 PM, Felix Schwarz wrote: > (Though > I somehow got used to pagure and getting the gitlab integration to the same > level as pagure currently will be a lot of work for sure.) Maybe I'm just a grumpy old system admin but it sounds like a lot of work for little, if any, gain. ___ 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: Git Forge Requirements: Please see the Community Blog
On 1/22/20 1:56 AM, Michal Konecny wrote: > If we go this way, in a few years we will end up in the same situation > as with Pagure today. We will have many custom patches (which we need > to take care of) and we will not have manpower to compete with the > features of other major git forges. Which just begs the question, do you *need* to compete with other git forges. Seems like pagure fills a niche that the others don't. ___ 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: CoC
This is one reason I vastly prefer decentralized platforms such as mailing lists and Usenet. You can't unsend an email. On 3/19/2020 4:20 PM, Ty Young wrote: > Oh, and when called out about the censorship on places like Medium & > Reddit, people who apparently have the ability to uncensor threads(AKA > higher ups) here attempted to weaponize it by threats as if it was > somehow damning and later only uncensored parts of the whole thread. ___ 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: Can we maybe reduce the set of packages we install by default a bit?
You mean like systemd? ;) On 4/10/19 7:10 AM, Brian (bex) Exelbierd wrote: > Adding software the user doesn't want > to have it as assumed for other users is always a trade-off. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we maybe reduce the set of packages we install by default a bit?
I'd say that backward compatibility is important and as a Fedora workstation and server user I expect crond to work OOTB. Yes, users can install and enable the service if needed but cron is such an essential part of every system that I see no reason to exclude it. On 4/11/19 6:30 AM, Brian (bex) Exelbierd wrote: > My interest, and the way I read the OP was not about minimal size, > directly. In this case, it sounds like we have adopted a tool, > systemd, that replaces another tool, cron. We can debate the > completeness of the replacement, etc, but it is also valid to question > why we ship both as default installed. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: F28 System Wide Change: Reduce Initial Setup Redundancy
On 12/4/17 7:03 PM, Michael Catanzaro wrote: > On 12/04/2017 03:11 PM, Chris Murphy wrote: >> Also, for any kind of early boot troubleshooting even once a user is >> created, systemd emergency and rescue targets only accept root user >> login. If root user is disabled, it's impossible to do such early boot >> troubleshooting. So I think systemd needs a way to accept an admin >> user (wheel group) as an alternative login rather than only root. > > Yes, good point. This is a longstanding problem. Hopefully making > disabled root the default behavior for Fedora Workstation might nudge > the systemd developers into fixing it. > > Of course, Ubuntu has managed to survive the past year and a half with > the same nonfuctional rescue prompt, so I don't think it should block > this change. > > Michael > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org Just because Ubuntu likes to shoot themselves in the foot doesn't mean that Fedora should do the same thing. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Hiding the grub menu by default on single OS installs
What about users that don't use a graphical login manager? Personally I *like* seeing boot messages so that I know what is going on. Having the menu available is also quite useful for booting into rescue mode or selecting a different kernel. On 05/31/2018 06:23 AM, Hans de Goede wrote: > Hi All, > > I'm working on improving the Fedora boot experience, with the > end goal being a user pressing the on button and then going > to the graphical login manager without him seeing any > text messages / menus filled with technical jargon. > > IIRC we used to hide the grub-menu by default on single > OS installs, but we seemed to have stopped doing that, > for new Fedora 29 installs I would like us to start > hiding the menu by default on single OS installs again, > see: > > https://fedoraproject.org/wiki/Changes/HiddenGrubMenu > > The goal if this email is to: > 1) Give people an advance warning about the plan to change > this so we can discuss this early on > > 2) See if anyone knows why we stopped doing this, I think > we may simply have stopped doing this to simplify to bootconfig > code in anaconda and because we did not always identify the > single OS case correctly, but I wonder if there were other > reasons? > > 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://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/ILRC44ESGWKWZ6DNOCTK4KPQGVIQY5AM/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/EB7R5RYWJR3PUUKRJ26YYQRTGMBTPGC4/
Re: Hiding the grub menu by default on single OS installs
Well said. Seems like Fedora is slowly turning into Fisher Price My First Linux instead of being a distro that actually respects its users. IME people that run Fedora usually know what they're doing and trying to obfuscate and hide things simply makes the distro *harder* to use. On 06/01/2018 12:52 AM, Kyle Marek wrote: > I think going through this effort to shave a few seconds off of the boot > time is just going to make everything harder *especially* when the shit > hits the fan... I don't think it's worth perpetuating the > Windows-ification of Fedora, either. > > Regards, > > Kyle > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/CZ2QOYTYAVBYWGRU5Q2WWFD54VNIHVEJ/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/DGHN5MGVVJLXLJVUWQELFFZBYNZJP54C/
Re: F29 System Wide Change: Strong crypto settings: phase 2
Not just web sites. Changes in Firefox and Chrome have already made working with embedded devices such as DRAC and storage servers nearly impossible. IMO there needs to be a fallback option to still allow access to "insecure" sites that still use TLS 1.0 or older certificates that still use SHA-1. On 06/02/2018 05:57 AM, Christian Stadelmann wrote: >> On Fri, Jun 01, 2018 at 01:40:58PM +0200, Jan Kurik wrote: >> What is the availibility of TLS 1.2 vs 1.1/1.0 on the internet ? >> ie how likely is this to break the ability of users to access websites >> they care about ? > There is quite a lot, sadly. I'd say about 0.1…1% of all internet sites of my > personal browsing behavior. Fedora's infrastructure works fine with TLS 1.0 > and 1.1 disabled. Essential parts of the eclipse.org infrastructure is still > on historic crypto levels, including its wiki, git server and marketplace. > This DEFAULT policy probably will break the eclipse marketplace client in > Fedora. > > I haven't found perfect data but SSLLabs' "SSL Pulse" [1] gives some hints. > Applying their current metric, any server without TLS 1.2 support will be > rewarded with grade C or worse. See [2] for an example. Assuming that > grade-F-sites are broken beyond any repair, there's still 7.7% grade C and a > few grade D pages resulting in up to 7.8% of all websites still using TLS < > 1.2. Without good data on this I highly recommend not disabling TLS <1.2 by > default on F29. > > [1] https://www.ssllabs.com/ssl-pulse/ > [2] https://www.ssllabs.com/ssltest/analyze.html?d=marketplace.eclipse.org > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/Z6RXR5W6KH4NODRINVJFEBIBQRX4I6HP/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/BPNMA54WJ5B7QMBTEMPDVDGOHCIHQDHN/
