In Fedora 34 the default editor was nano, for Workstation and also for Server. In my latest default F35 Server installation I noticed vim-default-editor was installed.
Did some good soul take pity and bring vim back to us or did something go wrong with my installation?
Best Peter
On Sun, Nov 07, 2021 at 12:16:30PM +0100, Peter Boy wrote:
In Fedora 34 the default editor was nano, for Workstation and also for Server. In my latest default F35 Server installation I noticed vim-default-editor was installed. Did some good soul take pity and bring vim back to us or did something go wrong with my installation?
Hmmm, interesting. I don't see anything in the repo with requires or recommends that package....
Am 07.11.2021 um 21:11 schrieb Matthew Miller mattdm@fedoraproject.org:
On Sun, Nov 07, 2021 at 12:16:30PM +0100, Peter Boy wrote:
In Fedora 34 the default editor was nano, for Workstation and also for Server. In my latest default F35 Server installation I noticed vim-default-editor was installed. Did some good soul take pity and bring vim back to us or did something go wrong with my installation?
Hmmm, interesting. I don't see anything in the repo with requires or recommends that package....
-- Matthew Miller mattdm@fedoraproject.org Fedora Project Leader
Just for fun I double checked and did fresh install
[root@gaia ~]# cat /etc/system-release Fedora release 34 (Thirty Four)
[root@gaia ~]# rpm -qa | grep nano nano-5.8-3.fc34.x86_64 nano-default-editor-5.8-3.fc34.noarch
[root@gaia ~]# rpm -qa | grep default-editor nano-default-editor-5.8-3.fc34.noarch default-editor-5.8-3.fc34.noarch
[root@gaia ~]# dnf info default-editor-5.8-3.fc34.noarch Description : The package acts as a placeholder in DNF group 'Standard', which will : install nano-default-editor on fresh installs and it will not block users : who don't have nano as a default editor during upgrade.
[pb@zbox ~]$ cat /etc/system-release Fedora release 35 (Thirty Five)
[pb@zbox ~]$ rpm -qa | grep nano [pb@zbox ~]$
[pb@zbox ~]$ rpm -qa | grep default-editor vim-default-editor-8.2.3404-1.fc35.noarch default-editor-5.8-4.fc35.noarch
[pb@zbox ~]$ dnf info default-editor-5.8-4.fc35.noarch Description : The package acts as a placeholder in DNF group 'Standard', which will : install nano-default-editor on fresh installs and it will not block users : who don't have nano as a default editor during upgrade.
So, in F34 there was a default-nano-editor.
In F35 no default-nano-editor at all, instead a default-vim-editor that was not present in F34.
I don’t want to complain, in contrary, I appreciate that.
There must be a good soul in the Fedora universe who takes pity on server administrators.
On Mon, Nov 8, 2021 at 5:45 PM Peter Boy pboy@uni-bremen.de wrote:
Am 07.11.2021 um 21:11 schrieb Matthew Miller mattdm@fedoraproject.org:
On Sun, Nov 07, 2021 at 12:16:30PM +0100, Peter Boy wrote:
In Fedora 34 the default editor was nano, for Workstation and also for Server. In my latest default F35 Server installation I noticed vim-default-editor was installed. Did some good soul take pity and bring vim back to us or did something go wrong with my installation?
Hmmm, interesting. I don't see anything in the repo with requires or recommends that package....
-- Matthew Miller mattdm@fedoraproject.org Fedora Project Leader
Just for fun I double checked and did fresh install
[root@gaia ~]# cat /etc/system-release Fedora release 34 (Thirty Four)
[root@gaia ~]# rpm -qa | grep nano nano-5.8-3.fc34.x86_64 nano-default-editor-5.8-3.fc34.noarch
[root@gaia ~]# rpm -qa | grep default-editor nano-default-editor-5.8-3.fc34.noarch default-editor-5.8-3.fc34.noarch
[root@gaia ~]# dnf info default-editor-5.8-3.fc34.noarch Description : The package acts as a placeholder in DNF group 'Standard', which will : install nano-default-editor on fresh installs and it will not block users : who don't have nano as a default editor during upgrade.
[pb@zbox ~]$ cat /etc/system-release Fedora release 35 (Thirty Five)
[pb@zbox ~]$ rpm -qa | grep nano [pb@zbox ~]$
[pb@zbox ~]$ rpm -qa | grep default-editor vim-default-editor-8.2.3404-1.fc35.noarch default-editor-5.8-4.fc35.noarch
[pb@zbox ~]$ dnf info default-editor-5.8-4.fc35.noarch Description : The package acts as a placeholder in DNF group 'Standard', which will : install nano-default-editor on fresh installs and it will not block users : who don't have nano as a default editor during upgrade.
So, in F34 there was a default-nano-editor.
In F35 no default-nano-editor at all, instead a default-vim-editor that was not present in F34.
I don’t want to complain, in contrary, I appreciate that.
There must be a good soul in the Fedora universe who takes pity on server administrators.
Hardly. This is definitely a bug that should be fixed. Having an unfriendly editor by default is a terrible thing.
Am 08.11.2021 um 23:51 schrieb Neal Gompa ngompa13@gmail.com:
On Mon, Nov 8, 2021 at 5:45 PM Peter Boy pboy@uni-bremen.de wrote:
Am 07.11.2021 um 21:11 schrieb Matthew Miller mattdm@fedoraproject.org:
On Sun, Nov 07, 2021 at 12:16:30PM +0100, Peter Boy wrote:
In Fedora 34 the default editor was nano, for Workstation and also for Server. In my latest default F35 Server installation I noticed vim-default-editor was installed. Did some good soul take pity and bring vim back to us or did something go wrong with my installation?
Hmmm, interesting. I don't see anything in the repo with requires or recommends that package....
-- Matthew Miller mattdm@fedoraproject.org Fedora Project Leader
Just for fun I double checked and did fresh install
…
So, in F34 there was a default-nano-editor.
In F35 no default-nano-editor at all, instead a default-vim-editor that was not present in F34.
I don’t want to complain, in contrary, I appreciate that.
There must be a good soul in the Fedora universe who takes pity on server administrators.
Hardly. This is definitely a bug that should be fixed. Having an unfriendly editor by default is a terrible thing.
It’s definitely not a bug nor an unfriendly editor for Server admins and there is no need to fix it. The vim package contains so many useful things like vimdiff to easily compare config files after update, as an example. It was a bug to change it for Server, too.
For Workstation people nano may be the better choice, indeed.
On Mon, Nov 8, 2021 at 6:11 PM Peter Boy pboy@uni-bremen.de wrote:
Am 08.11.2021 um 23:51 schrieb Neal Gompa ngompa13@gmail.com:
On Mon, Nov 8, 2021 at 5:45 PM Peter Boy pboy@uni-bremen.de wrote:
Am 07.11.2021 um 21:11 schrieb Matthew Miller mattdm@fedoraproject.org:
On Sun, Nov 07, 2021 at 12:16:30PM +0100, Peter Boy wrote:
In Fedora 34 the default editor was nano, for Workstation and also for Server. In my latest default F35 Server installation I noticed vim-default-editor was installed. Did some good soul take pity and bring vim back to us or did something go wrong with my installation?
Hmmm, interesting. I don't see anything in the repo with requires or recommends that package....
-- Matthew Miller mattdm@fedoraproject.org Fedora Project Leader
Just for fun I double checked and did fresh install
…
So, in F34 there was a default-nano-editor.
In F35 no default-nano-editor at all, instead a default-vim-editor that was not present in F34.
I don’t want to complain, in contrary, I appreciate that.
There must be a good soul in the Fedora universe who takes pity on server administrators.
Hardly. This is definitely a bug that should be fixed. Having an unfriendly editor by default is a terrible thing.
It’s definitely not a bug nor an unfriendly editor for Server admins and there is no need to fix it. The vim package contains so many useful things like vimdiff to easily compare config files after update, as an example. It was a bug to change it for Server, too.
For Workstation people nano may be the better choice, indeed.
Shipping nano as the default editor isn't the same as not shipping vim on servers. And you're making a dangerous assumption that everyone using Fedora Server knows how to work with Vim. I assure you, that is far from true. Note that *the most popular server distribution* (Ubuntu) uses nano as the default editor as well, for *precisely* this reason.
Hi!
This seems to be a side effect of fixing that default-editor-package - the initial nano-default-editor package broke system upgrades. [1]
The current accepted solution seems to let the dnf resolver decide, which seems to prefer nano-default-editor, if nano is installed.
This was only ever explicitely added in workstation-product, security-lab and "standard", which is pulled in by some desktop releases and also fedora server. Some of the desktops seem to explicitely tilt the decision towards vim, possibly on purpose.
If you keep your installation as close as possible to "minimal", you'll also end up without any default-editor. (I do choose that method explicitely, as it triggers the least amount of problems for me.)
Personal opinion: If this should be hardcoded for fedora server this should stay vi. Forcing it to nano annoyed a lot of people, especially so as the initial solution also forced nano on existing installations.
The changes that made dnf choose vim over nano seems to mostly have gone unnoticed or was seen as good change - also because of that I'd prefer to keep vi for server.
I do install vim-enhanced on most of my systems, but this is a personal preference - vi does suffice for a basic server installation, everything above that is see as user choice.
All the best, Astra
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1955884
On Tue, Nov 09, 2021 at 12:11:13AM +0100, Peter Boy wrote:
Am 08.11.2021 um 23:51 schrieb Neal Gompa ngompa13@gmail.com:
On Mon, Nov 8, 2021 at 5:45 PM Peter Boy pboy@uni-bremen.de wrote:
Am 07.11.2021 um 21:11 schrieb Matthew Miller mattdm@fedoraproject.org:
On Sun, Nov 07, 2021 at 12:16:30PM +0100, Peter Boy wrote:
In Fedora 34 the default editor was nano, for Workstation and also for Server. In my latest default F35 Server installation I noticed vim-default-editor was installed. Did some good soul take pity and bring vim back to us or did something go wrong with my installation?
Hmmm, interesting. I don't see anything in the repo with requires or recommends that package....
-- Matthew Miller mattdm@fedoraproject.org Fedora Project Leader
Just for fun I double checked and did fresh install
…
So, in F34 there was a default-nano-editor.
In F35 no default-nano-editor at all, instead a default-vim-editor that was not present in F34.
I don’t want to complain, in contrary, I appreciate that.
There must be a good soul in the Fedora universe who takes pity on server administrators.
Hardly. This is definitely a bug that should be fixed. Having an unfriendly editor by default is a terrible thing.
It’s definitely not a bug nor an unfriendly editor for Server admins and there is no need to fix it. The vim package contains so many useful things like vimdiff to easily compare config files after update, as an example. It was a bug to change it for Server, too.
For Workstation people nano may be the better choice, indeed. _______________________________________________ server mailing list -- server@lists.fedoraproject.org To unsubscribe send an email to server-leave@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/server@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
The current accepted solution seems to let the dnf resolver decide, which seems to prefer nano-default-editor, if nano is installed.
The current solution depends on weak dependency system in DNF - default-editor requires system-default-editor which both - vim-default-editor and nano-default-editor - provides (*-default-editors conflicts with system-default-editor as well to prevent both being installed at the same time). Then if weak-deps are enabled - DNF sees 'Recommends:' in default-editor and brings in nano-default-editor if there isn't any other *-default-editor already installed. If there is, the transaction is not done, but it doesn't fail the whole transaction -> upgrade-path is okay.
Dang, forgot to add the bottom line :)
The bottom line is it doesn't matter whether nano is installed or not. If weak-deps work and vim-default-editor isn't installed, DNF should bring in nano anyway (since nano-default-editor requires it).
Am 11.11.2021 um 10:01 schrieb Zdenek Dohnal zdohnal@fedoraproject.org:
Dang, forgot to add the bottom line :)
The bottom line is it doesn't matter whether nano is installed or not. If weak-deps work and vim-default-editor isn't installed, DNF should bring in nano anyway (since nano-default-editor requires it).
Thank you very much for your detailed analysis (including the previous mail), so that we now know exactly what the effect is due to.
Finally, it works as intended and is not a bug itself, but „just" another side effect of an issue we know about for about 6 months now. I conclude that we have to work on the solution of our "issue #32" (in short: different handling of recommended packages in dvd-installation and net-installation) and then the editor problem gets resolved by itself.
On Mon, Nov 8, 2021 at 6:11 PM Peter Boy pboy@uni-bremen.de wrote:
It’s definitely not a bug nor an unfriendly editor for Server admins and there is no need to fix it. The vim package contains so many useful things like vimdiff to easily compare config files after update, as an example. It was a bug to change it for Server, too.
I think this is obnoxious. I'm a sysadmin, I used vim for ages. The reality is that vim is user hostile, and nano is the default Fedora wide. Making it the default went through the Fedora change process. Referring to the conclusion of that process as a bug is self-evidently nonsense. The assertion it's a bug is an attempt to start another bunfight over nano being the default.
Yeah, let's please not revisit the fight? This was a system-wide change approved by FESCo. I do support Fedora Editions (and, for that matter, really, non-Editions) making their own choices for their intended audience, and I can _definitely_ see that certainly vi and probably vim is a reasonable thing to have installed on Fedora Server, but if you want to deviate from the recently-approved change, that should go back to FESCo.
I know the degree of autonomy here is a little vague.... but that's _why_ we have FESCo, and the Editions working groups technically defined as under FESCo. That's the place to hash it out.
Although, really, in this case, I hope we don't re-hash. If the Server WG _does_ have a decided desire to make this different, it'd be helpful for the case to come with data, and fit clearly into the story told by the refreshed PRD. And, also, please weigh the cost to documentation and support in having a different expectation for editor defaults.
Hi all,
from am mere software developer, operator and/or user perspective I consider this a bug, too. The design clearly describes, that nano is the default editor for „standard“.
https://www.fedoraproject.org/wiki/Changes/UseNanoByDefault
Even if one wants to discuss this, that must be done somewhere else. For now, getting this fixed to align with design decisions should be prioritized.
This shouldn’t be a matter of „tmux vs screen“, „vi vs nano“ or „bash vs *sh“, but a matter of consistent Fedora Linux experience.
Best regards, Daniel
---
### Contact dschier@while-true-do.io while-true-do.io
### Code code.while-true-do.io github.com/daniel-wtd/ github.com/while-true-do/
### Social dschier @libera.chat
### Disclaimer If not stated otherwise all of my work is licensed under a Creative Commons Attribution 4.0 International License (creativecommons.org/licenses/by/4.0/).
On 9. Nov 2021, at 04:54, Matthew Miller mattdm@fedoraproject.org wrote:
Yeah, let's please not revisit the fight? This was a system-wide change approved by FESCo. I do support Fedora Editions (and, for that matter, really, non-Editions) making their own choices for their intended audience, and I can _definitely_ see that certainly vi and probably vim is a reasonable thing to have installed on Fedora Server, but if you want to deviate from the recently-approved change, that should go back to FESCo.
I know the degree of autonomy here is a little vague.... but that's _why_ we have FESCo, and the Editions working groups technically defined as under FESCo. That's the place to hash it out.
Although, really, in this case, I hope we don't re-hash. If the Server WG _does_ have a decided desire to make this different, it'd be helpful for the case to come with data, and fit clearly into the story told by the refreshed PRD. And, also, please weigh the cost to documentation and support in having a different expectation for editor defaults.
-- Matthew Miller mattdm@fedoraproject.org Fedora Project Leader _______________________________________________ server mailing list -- server@lists.fedoraproject.org To unsubscribe send an email to server-leave@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/server@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
This topic is certainly of rather low relevance and we have more important things to do on Fedora Server. And I did my research more "just for fun“ and out of curiosity.
Nevertheless, two remarks.
(a) I would like some of those who insist on "bug" and "need to fix" with vehemence here to work with equal vehemence on the bug regarding the difference between net-install and dvd-install (issue #32 / #48, meeting & action https://meetbot.fedoraproject.org/teams/fedora-server/fedora-server.2021-04-...). It has not been possible to solve this far more significant problem for a good six months now. And with all our releases, we don't know whether we haven't caught another problem like we did with Cockpit back then.
(b) I'm a big fan of consistency in the user interface. But the "user experience" of a server system administrator at a text console and a desktop user in a GUI is quite different, to put it mildly. There is not much leeway for "consistency". And it makes absolutely no sense, to want to treat such different things the same. @Daniel: Are you really doing development on a Server text console using nano? That's what I would call 'hardcore development'. But you can do that even with vim as default editor. 'Default' determines the editor that system administration tools as crontab etc. use implicitly.
So, let’s keep vim as it currently is and focus on the important subjects.
Best Peter
Am 09.11.2021 um 07:30 schrieb Daniel Schier dschier@while-true-do.io:
Hi all,
from am mere software developer, operator and/or user perspective I consider this a bug, too. The design clearly describes, that nano is the default editor for „standard“.
https://www.fedoraproject.org/wiki/Changes/UseNanoByDefault
Even if one wants to discuss this, that must be done somewhere else. For now, getting this fixed to align with design decisions should be prioritized.
This shouldn’t be a matter of „tmux vs screen“, „vi vs nano“ or „bash vs *sh“, but a matter of consistent Fedora Linux experience.
Best regards, Daniel
### Contact dschier@while-true-do.io while-true-do.io
### Code code.while-true-do.io github.com/daniel-wtd/ github.com/while-true-do/
### Social dschier @libera.chat
### Disclaimer If not stated otherwise all of my work is licensed under a Creative Commons Attribution 4.0 International License (creativecommons.org/licenses/by/4.0/).
On 9. Nov 2021, at 04:54, Matthew Miller mattdm@fedoraproject.org wrote:
Yeah, let's please not revisit the fight? This was a system-wide change approved by FESCo. I do support Fedora Editions (and, for that matter, really, non-Editions) making their own choices for their intended audience, and I can _definitely_ see that certainly vi and probably vim is a reasonable thing to have installed on Fedora Server, but if you want to deviate from the recently-approved change, that should go back to FESCo.
I know the degree of autonomy here is a little vague.... but that's _why_ we have FESCo, and the Editions working groups technically defined as under FESCo. That's the place to hash it out.
Although, really, in this case, I hope we don't re-hash. If the Server WG _does_ have a decided desire to make this different, it'd be helpful for the case to come with data, and fit clearly into the story told by the refreshed PRD. And, also, please weigh the cost to documentation and support in having a different expectation for editor defaults.
-- Matthew Miller mattdm@fedoraproject.org Fedora Project Leader _______________________________________________ server mailing list -- server@lists.fedoraproject.org To unsubscribe send an email to server-leave@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/server@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
server mailing list -- server@lists.fedoraproject.org To unsubscribe send an email to server-leave@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/server@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On Di, Nov 9 2021 at 23:11:26 +0100, Peter Boy pboy@uni-bremen.de wrote:
@Daniel: Are you really doing development on a Server text console using nano? That's what I would call 'hardcore development'. But you can do that even with vim as default editor. 'Default' determines the editor that system administration tools as crontab etc. use implicit
I am not aware, that I stated at any point, that I do development with nano or on the console ^^ What I intended to say is:
---- As a software developer, I always consider the user perspective. If the default editor on a given system is defined and designed to be vim, it should be vim. If it is designed and defined to be nano, it should be nano. If this definition is changing, I am absolutely ok with it. But as long as this is not given, we should stick to the design decision made by FESCO. ---
But I am not 1% invested in this. This is just my very personal opinion as a mere Fedora Linux user. If you (the server wg) decides something else, I will be 100% ok with it, too. There are far more important things, than the default editor, that I don't use anyway. :)
Best regards, Daniel ---
### Contact
dschier@while-true-do.io while-true-do.io code.while-true-do.io
### Social
dschier @libera.chat twitter.com/daniel_wtd reddit.com/u/daniel-wtd linkedin.com/u/dschier
### Projects
style-cheat.io github.com/while-true-do/ github.com/kudos-txt/ github.com/daniel-wtd/
### Disclaimer
If not stated otherwise all of my work is licensed under a Creative Commons Attribution 4.0 International License (https://creativecommons.org/licenses/by/4.0/).
On Di, Nov 9 2021 at 23:11:26 +0100, Peter Boy pboy@uni-bremen.de wrote:
This topic is certainly of rather low relevance and we have more important things to do on Fedora Server. And I did my research more "just for fun“ and out of curiosity.
Nevertheless, two remarks.
(a) I would like some of those who insist on "bug" and "need to fix" with vehemence here to work with equal vehemence on the bug regarding the difference between net-install and dvd-install (issue #32 / #48, meeting & action https://meetbot.fedoraproject.org/teams/fedora-server/fedora-server.2021-04-28-17.00.html). It has not been possible to solve this far more significant problem for a good six months now. And with all our releases, we don't know whether we haven't caught another problem like we did with Cockpit back then.
(b) I'm a big fan of consistency in the user interface. But the "user experience" of a server system administrator at a text console and a desktop user in a GUI is quite different, to put it mildly. There is not much leeway for "consistency". And it makes absolutely no sense, to want to treat such different things the same. @Daniel: Are you really doing development on a Server text console using nano? That's what I would call 'hardcore development'. But you can do that even with vim as default editor. 'Default' determines the editor that system administration tools as crontab etc. use implicitly.
So, let’s keep vim as it currently is and focus on the important subjects.
Best Peter
Am 09.11.2021 um 07:30 schrieb Daniel Schier <dschier@while-true-do.io mailto:dschier@while-true-do.io>:
Hi all,
from am mere software developer, operator and/or user perspective I consider this a bug, too. The design clearly describes, that nano is the default editor for „standard“.
https://www.fedoraproject.org/wiki/Changes/UseNanoByDefault
Even if one wants to discuss this, that must be done somewhere else. For now, getting this fixed to align with design decisions should be prioritized.
This shouldn’t be a matter of „tmux vs screen“, „vi vs nano“ or „bash vs *sh“, but a matter of consistent Fedora Linux experience.
Best regards, Daniel
### Contact dschier@while-true-do.io mailto:dschier@while-true-do.io while-true-do.io
### Code code.while-true-do.io github.com/daniel-wtd/ github.com/while-true-do/
### Social dschier @libera.chat
### Disclaimer If not stated otherwise all of my work is licensed under a Creative Commons Attribution 4.0 International License (creativecommons.org/licenses/by/4.0/).
On 9. Nov 2021, at 04:54, Matthew Miller <mattdm@fedoraproject.org mailto:mattdm@fedoraproject.org> wrote:
Yeah, let's please not revisit the fight? This was a system-wide change approved by FESCo. I do support Fedora Editions (and, for that matter, really, non-Editions) making their own choices for their intended audience, and I can _definitely_ see that certainly vi and probably vim is a reasonable thing to have installed on Fedora Server, but if you want to deviate from the recently-approved change, that should go back to FESCo.
I know the degree of autonomy here is a little vague.... but that's _why_ we have FESCo, and the Editions working groups technically defined as under FESCo. That's the place to hash it out.
Although, really, in this case, I hope we don't re-hash. If the Server WG _does_ have a decided desire to make this different, it'd be helpful for the case to come with data, and fit clearly into the story told by the refreshed PRD. And, also, please weigh the cost to documentation and support in having a different expectation for editor defaults.
-- Matthew Miller <mattdm@fedoraproject.org mailto:mattdm@fedoraproject.org> Fedora Project Leader _______________________________________________ server mailing list -- server@lists.fedoraproject.org mailto:server@lists.fedoraproject.org To unsubscribe send an email to server-leave@lists.fedoraproject.org mailto:server-leave@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/server@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
server mailing list -- server@lists.fedoraproject.org mailto:server@lists.fedoraproject.org To unsubscribe send an email to server-leave@lists.fedoraproject.org mailto:server-leave@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/server@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
server mailing list -- server@lists.fedoraproject.org mailto:server@lists.fedoraproject.org To unsubscribe send an email to server-leave@lists.fedoraproject.org mailto:server-leave@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/server@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Hi Daniel
Am 09.11.2021 um 23:32 schrieb Daniel Schier dschier@while-true-do.io:
On Di, Nov 9 2021 at 23:11:26 +0100, Peter Boy pboy@uni-bremen.de wrote:
@Daniel: Are you really doing development on a Server text console using nano? That's what I would call 'hardcore development'. But you can do that even with vim as default editor. 'Default' determines the editor that system administration tools as crontab etc. use implicit
I am not aware, that I stated at any point, that I do development with nano or on the console
That was (meant as) rhetorical hyperbole to put the factual relevance into perspective. Sorry if I couldn't get that across clearly enough. No harm intended.
Best Peter
New clean install of Fedora-Server-dvd-x86_64-35-1.2.iso
$ rpm -qa | grep editor vim-default-editor-8.2.3404-1.fc35.noarch default-editor-5.8-4.fc35.noarch $ rpm -qa | grep nano $
So nano is not even installed, let alone as the default editor.
Fedora-Server-netinst-x86_64-35-1.2.iso - nano-default-editor-5.8-4.fc35.noarch default-editor-5.8-4.fc35.noarch default-5.8-4.fc35.noarch
But with netinstaller, it's correct. But how the heck is it different? Ostensibly a netinstall and dvd install should be the same thing, just that the netinstaller will get newer packages?
Does this commit explain the problem at all? I'm not sure it's a complete explanation anyway... https://pagure.io/fedora-comps/c/3496ed634cf452da38cc2796c6710e1de6cbc23a?br...
-- Chris Murphy
Chris,
Am 10.11.2021 um 02:42 schrieb Chris Murphy lists@colorremedies.com:
New clean install of Fedora-Server-dvd-x86_64-35-1.2.iso
...
So nano is not even installed, let alone as the default editor.
...
But with netinstaller, it's correct. But how the heck is it different?
That is exactly what our issue #32 / #48 is about. See my previous post for details.
So let’s focus on resolving that (really important) issue and the nano thingee is also solved.
Best Peter
On Wed, Nov 10, 2021 at 07:30:34AM +0100, Peter Boy wrote:
But with netinstaller, it's correct. But how the heck is it different?
That is exactly what our issue #32 / #48 is about. See my previous post for details.
So let’s focus on resolving that (really important) issue and the nano thingee is also solved.
For what it's worth, I may have "fixed" this incidentally in Rawhide, because I changed "Recommends: vim-minimal" to "Recommends: nano". (I also changed the editor default from `/bin/vi` to searching through nano, vim, and vi in that order.
Am 13.11.2021 um 23:23 schrieb Matthew Miller mattdm@fedoraproject.org:
On Wed, Nov 10, 2021 at 07:30:34AM +0100, Peter Boy wrote:
But with netinstaller, it's correct. But how the heck is it different?
That is exactly what our issue #32 / #48 is about. See my previous post for details.
So let’s focus on resolving that (really important) issue and the nano thingee is also solved.
For what it's worth, I may have "fixed" this incidentally in Rawhide, because I changed "Recommends: vim-minimal" to "Recommends: nano". (I also changed the editor default from `/bin/vi` to searching through nano, vim, and vi in that order.
For sure, this does not fix the core problem, but only adds another patchwork of quick and dirty fixes. Those are known to generate their own problems and in particular getting in the way of solving the core problem and create additional work.
And I think it would be fatal to make single changes without consulting the WG and especially without an explicit review by those of us who have worked out the perfect functioning of the server distribution so far and take responsibility for it.
And who will do the work when problems by such single actions do indeed unexpectedly arise?
Unfortunately, we have no shortage of people who propagate alleged improvements, but fade away when it comes to action.
On Sat, Nov 13, 2021 at 7:12 PM Peter Boy pboy@uni-bremen.de wrote:
Am 13.11.2021 um 23:23 schrieb Matthew Miller mattdm@fedoraproject.org:
On Wed, Nov 10, 2021 at 07:30:34AM +0100, Peter Boy wrote:
But with netinstaller, it's correct. But how the heck is it different?
That is exactly what our issue #32 / #48 is about. See my previous post for details.
So let’s focus on resolving that (really important) issue and the nano thingee is also solved.
For what it's worth, I may have "fixed" this incidentally in Rawhide, because I changed "Recommends: vim-minimal" to "Recommends: nano". (I also changed the editor default from `/bin/vi` to searching through nano, vim, and vi in that order.
For sure, this does not fix the core problem, but only adds another patchwork of quick and dirty fixes. Those are known to generate their own problems and in particular getting in the way of solving the core problem and create additional work.
What is the core problem?
And I think it would be fatal to make single changes without consulting the WG and especially without an explicit review by those of us who have worked out the perfect functioning of the server distribution so far and take responsibility for it.
And who will do the work when problems by such single actions do indeed unexpectedly arise?
Unfortunately, we have no shortage of people who propagate alleged improvements, but fade away when it comes to action.
Well, Fedora-Server-dvd-x86_64-Rawhide-20211113.n.0.iso still doesn't have nano. Seeing as the Server WG still doesn't have an explanation for that, it seems weird to criticize attempts to fix it.
Am 14.11.2021 um 03:33 schrieb Chris Murphy lists@colorremedies.com:
On Sat, Nov 13, 2021 at 7:12 PM Peter Boy pboy@uni-bremen.de wrote:
Am 13.11.2021 um 23:23 schrieb Matthew Miller mattdm@fedoraproject.org:
On Wed, Nov 10, 2021 at 07:30:34AM +0100, Peter Boy wrote:
But with netinstaller, it's correct. But how the heck is it different?
That is exactly what our issue #32 / #48 is about. See my previous post for details.
So let’s focus on resolving that (really important) issue and the nano thingee is also solved.
For what it's worth, I may have "fixed" this incidentally in Rawhide, because I changed "Recommends: vim-minimal" to "Recommends: nano". (I also changed the editor default from `/bin/vi` to searching through nano, vim, and vi in that order.
For sure, this does not fix the core problem, but only adds another patchwork of quick and dirty fixes. Those are known to generate their own problems and in particular getting in the way of solving the core problem and create additional work.
What is the core problem?
Sorry if I'm a tad annoyed. "Those who can read have a clear advantage“. Please, just some 10 lines up, should not be so complicated and burdensome, and read with some sense! And follow the references.
And I think it would be fatal to make single changes without consulting the WG and especially without an explicit review by those of us who have worked out the perfect functioning of the server distribution so far and take responsibility for it.
And who will do the work when problems by such single actions do indeed unexpectedly arise?
Unfortunately, we have no shortage of people who propagate alleged improvements, but fade away when it comes to action.
Well, Fedora-Server-dvd-x86_64-Rawhide-20211113.n.0.iso still doesn't have nano. Seeing as the Server WG still doesn't have an explanation for that, it seems weird to criticize attempts to fix it.
Sorry, to put it bluntly, you are wasting other people's valuable time. Before you make unsubstantiated claims here, please do make yourself knowledgeable. You've been around a long time enough to know this principle. Server WG knows since April exactly what the cause is. This has been discussed repeatedly in all openness and for all to read. And there is a plan how to correct it. And as I said in my previous email, unfortunately, too many are great on talking, but disappear when it comes to implementation and thus work. At this, already the 1st step of the plan was delayed. And I just started a process to systematically restart the work on the plan.
What you refer to as a fix is not a fix, but in fact the introduction of a potential new bug - albeit certainly with the best of intentions.
Sorry, no offense intended, but we desperately need a more careful and considerate approach.
On Sun, Nov 14, 2021 at 1:57 AM Peter Boy pboy@uni-bremen.de wrote:
Am 14.11.2021 um 03:33 schrieb Chris Murphy lists@colorremedies.com:
On Sat, Nov 13, 2021 at 7:12 PM Peter Boy pboy@uni-bremen.de wrote:
Am 13.11.2021 um 23:23 schrieb Matthew Miller mattdm@fedoraproject.org:
On Wed, Nov 10, 2021 at 07:30:34AM +0100, Peter Boy wrote:
But with netinstaller, it's correct. But how the heck is it different?
That is exactly what our issue #32 / #48 is about. See my previous post for details.
So let’s focus on resolving that (really important) issue and the nano thingee is also solved.
For what it's worth, I may have "fixed" this incidentally in Rawhide, because I changed "Recommends: vim-minimal" to "Recommends: nano". (I also changed the editor default from `/bin/vi` to searching through nano, vim, and vi in that order.
For sure, this does not fix the core problem, but only adds another patchwork of quick and dirty fixes. Those are known to generate their own problems and in particular getting in the way of solving the core problem and create additional work.
What is the core problem?
Sorry if I'm a tad annoyed. "Those who can read have a clear advantage“. Please, just some 10 lines up, should not be so complicated and burdensome, and read with some sense! And follow the references.
How about you copy paste it?
And I think it would be fatal to make single changes without consulting the WG and especially without an explicit review by those of us who have worked out the perfect functioning of the server distribution so far and take responsibility for it.
And who will do the work when problems by such single actions do indeed unexpectedly arise?
Unfortunately, we have no shortage of people who propagate alleged improvements, but fade away when it comes to action.
Well, Fedora-Server-dvd-x86_64-Rawhide-20211113.n.0.iso still doesn't have nano. Seeing as the Server WG still doesn't have an explanation for that, it seems weird to criticize attempts to fix it.
Sorry, to put it bluntly, you are wasting other people's valuable time. Before you make unsubstantiated claims here, please do make yourself knowledgeable. You've been around a long time enough to know this principle. Server WG knows since April exactly what the cause is. This has been discussed repeatedly in all openness and for all to read. And there is a plan how to correct it. And as I said in my previous email, unfortunately, too many are great on talking, but disappear when it comes to implementation and thus work. At this, already the 1st step of the plan was delayed. And I just started a process to systematically restart the work on the plan.
What you refer to as a fix is not a fix, but in fact the introduction of a potential new bug - albeit certainly with the best of intentions.
Sorry, no offense intended, but we desperately need a more careful and considerate approach.
How is the nano problem related to issue #32? The nano problem happened just for Fedora 35. Issue 32 is about a 9 month old problem. I think if you're even more careful about it, you're at risk of the problem continuing for another 9 months. My opinion is that escalation is needed.
Am 15.11.2021 um 03:21 schrieb Chris Murphy lists@colorremedies.com:
How is the nano problem related to issue #32? The nano problem happened just for Fedora 35. Issue 32 is about a 9 month old problem. I think if you're even more careful about it, you're at risk of the problem continuing for another 9 months. My opinion is that escalation is needed.
OK, I try to explain it again and I hope I succeed better than the various times before.
You wrote: "The nano problem happened just for Fedora 35. Issue 32 is about a 9 month old..“
The „nano problem“ was *detected* some weeks ago and long after issue #32. That says nothing about when it *happend* and it says nothing about the technical reason, *why* it happened. It was discovered by chance, not by systematic, theory-based testing. Overall, the timing is simply "spurious information" from a scientific point of view.
We know from #32 that we have a systematic, technically based issue. Our net-install and dvd-install deliveries result in non-identical OS Installations. And we know the systematic technical reason for that, it is a different handling of "recommended packages“. This did result in a faulty cockpit installation.
As you found out yourself, nano installs correctly with net-install, but not with dvd-install. The known difference between both is that different handling of „recommended“.
A systematic, theory-based (or engineering based - I hope engineering is the right term for German ingenieurwissenschaftlich), a engineering based search for the cause of the error would start with this difference as the first hypothesis. Accordingly, the "nano problem" would simply be another incarnation of the same technical cause as the "cockpit problem“, although not discovered until later.
Kindly, Zdenek Dohnal provided a detailed reconstruction of the technical processes that strongly supported this hypothesis and proved it to be highly probable „true" (verification is logically impossible from a scientific-theoretical point of view).
For this reason, a systematic-scientific i.e. engineering-led correction starts at exactly this point. At the same time, this opens up the lowest probability of side effects and so does not reduce the quality of the product.
For the same reason, Matthew's intervention is simply „mindless", since it intervenes at a more or less random point without consideration of the overall technical design. From a systematic point of view, this entails a high risk of degraded quality of the product, i.d. Fedora Server Edition.
And again for the same reason, contrary to Matthew's action Stephen Gallaghers last minute quick fix of the Cockpit issue was „mindful“ as hi knows the engineering details and was able to intervene precisely at a specific point.
And again for the same reasoning, it is mindless to simply shuffle in one quick fix after another, accepting that at any time another error will be discovered (not occur, that is done beforehand) due to the same cause. This is also a process of degrading quality.
You wrote "My opinion is that escalation is needed“ of the nano issue.
We don’t need escalation. We need to work as planned. Basically we trusted a person to get things done who faded away silently when it got more complicated and elaborate.
I hope it helps.
Best Peter
Hi,
just freshly installed F37 Server... Can confirm it's still not there. But if I read all the replies here, it SHOULD be there.
Your truly, Ariaan
Yes, thanks for the reminder. Issue #55 (https://pagure.io/fedora-server/issue/55) and #32 (https://pagure.io/fedora-server/issue/32) are still open, unfortunately. I hope to be able to resolve it "soon". Sorry, unfortunately, I can't narrow it down anymore.
server@lists.fedoraproject.org
-
Ariaan Bruinsma -
Chris Murphy -
Daniel Schier -
David Kaufmann -
Matthew Miller -
Neal Gompa -
Peter Boy -
Zdenek Dohnal