3:34 a.m.
Wiki - https://fedoraproject.org/wiki/Changes/Anaconda_As_Native_Wayland_Applica...
Discussion Thread -
https://discussion.fedoraproject.org/t/f41-change-proposal-anaconda-as-na...
This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.
== Summary ==
Currently, Anaconda is still an X11 application, which we would like
to fix and make Anaconda Wayland native application to allow us drop
of the X11 dependencies from installation ISO images. However, this
change is not just a simple switch and we need to do some adjustments
during the path which will impact user experience.
== Owner ==
* Name: Anaconda team ([[User:jkonecny| Jiří Konečný]])
* Email: jkonecny(a)redhat.com
== Detailed Description ==
Anaconda is required to migrate to Wayland native application to drop
dependencies from the installation ISO images which are deprecated.
Package owners want to drop libXklavier from Fedora (see
https://bugzilla.redhat.com/show_bug.cgi?id=1955025 ) but also Xorg
server from CentOS Stream and RHEL. However, this change won’t be just
simple switching from X11 to Wayland, we also need to change a few
things in Anaconda to be able to remove the X11 dependencies. This
will have two main visible impacts listed below.
=== VNC switch to RDP for remote GUI installations ===
Anaconda has to remove ‘TigerVNC' which is used for VNC connection to
be able to install your machine remotely with graphical UI. Reason is
that TigerVNC is built from the Xorg server sources, so we would still
depend on the Xorg server with this project. As replacement, we follow
the recommendation of the Fedora Workstation to switch to Gnome Remote
Desktop (grd) with a better protocol Remote Desktop Protocol (RDP)
which gives users better performance and security.
This will have an impact on current vnc kickstart commands and kernel
boot options of Anaconda. This will impact only the Anaconda
installation environment (boot.iso).
=== Consistent keyboard control ===
Currently, Anaconda experiences difficulties in handling keyboard
layouts in the installation environment, particularly on Wayland.
Formerly, libXklavier was utilized by Anaconda to manage keyboard
layout configuration, however, it proved unstable on Wayland. As a
result, Anaconda has disabled keyboard handling during Wayland Live
media installations due to unexpected behavior (refer to
https://bugzilla.redhat.com/show_bug.cgi?id=2016613 ). This approach
may lead to situations when users encountering issues while unlocking
LUKS devices or using user passwords in the installed system because
installation was done with a different keyboard layout.
To exacerbate the situation, there is no universally applicable
solution for keyboard handling on Wayland systems, as Wayland lacks a
unified API for keyboard management. It means that each Fedora Desktop
Environment developed their own API. Unfortunately, the Anaconda team
is not able to maintain a custom solution for each Fedora spin. Some
Desktop environments started to use '''systemd-localed''' DBus API
to
address this issue and similar issues. The systemd-localed API seems
to be the best approach currently, so we want to promote it as a
shared solution for all Fedora spins.
The plan is:
* All Fedora spins and Anaconda listen on
'''org.freedesktop.locale1''' and reflect configuration on the
currently running system (might be only for Live media if desired)
* All Fedora spins and Anaconda reflect their configuration to
org.freedesktop.locale1
* In case Fedora spin will not support
'''org.freedesktop.locale1''',
the keyboard configuration of Anaconda won’t be reflected in the
current system and the situation will be similar to the current Live
Wayland experience
All the spin owners were notified about this request:
* https://pagure.io/fedora-workstation/issue/430
* https://pagure.io/fedora-kde/SIG/issue/504
* https://gitlab.com/fedora/sigs/sway/SIG/-/issues/36
* https://bugzilla.redhat.com/show_bug.cgi?id=2278655
* https://bugzilla.redhat.com/show_bug.cgi?id=2278658
* https://bugzilla.redhat.com/show_bug.cgi?id=2278656
* https://bugzilla.redhat.com/show_bug.cgi?id=2278864
* https://bugzilla.redhat.com/show_bug.cgi?id=2278866
* https://bugzilla.redhat.com/show_bug.cgi?id=2278869
* https://bugzilla.redhat.com/show_bug.cgi?id=2278874
* https://pagure.io/fedora-cosmic/SIG/issue/1
* https://pagure.io/fedora-budgie/project/issue/4
* https://pagure.io/fedora-lxqt/SIG/issue/4
* https://pagure.io/i3-sig/Fedora-i3-Spin/issue/70
== Feedback ==
We have some feedback from the SIG owners for the keyboard handling
(see the links above).
We don’t have feedback for the VNC to RDP switch yet.
== Benefit to Fedora ==
* This change will enable removal of X11 dependencies from the
Anaconda which may result in reduction of installed software to the
system when installing from Live ISO where ISO content is copied to
the installed system (depends on the spin dependencies).
* Switching from VNC to RDP allow users to use remote graphical
installations which are more secure and have better performance .
== Scope ==
* Proposal owners: The Anaconda team will implement changes required
in the Anaconda project. More specifically:
** Switch Anaconda code to start Wayland environment on boot.iso instead of X11
** Change keyboard switching logic to use systemd-localed DBus instead
of libXklavier
** Switch remote graphical installations from VNC (TigerVNC) to RDP (GRD)
* Other developers: Fedora SIG owners needs to add support for their
environment to listen and use systemd-localed DBus API to reflect
current state of the DE/WM or they won’t have support of keyboard
layout switching in Anaconda.
* Release engineering: [https://pagure.io/releng/issue/12138 #12138]
* Policies and guidelines: Yes should be done after the implementation
(https://docs.fedoraproject.org/en-US/fedora-server/installation/interacti...
should switch to RDP)
* Trademark approval: N/A (not needed for this Change)
* Alignment with the Fedora Strategy:
== Upgrade/compatibility impact ==
This will impact only Fedora installations so no compatibility or
upgrade issues.
== Early Testing (Optional) ==
We will reach Fedora QE to coordinate testing approach.
== How To Test ==
# Download any installation media
# Run the installation
# Look for breakages during the installation
Testing should be especially focused on:
* Changing resolution with ''inst.resolution'' kernel boot option
* Test new RDP solution (API will be clarified)
** Password can be set to the RDP
** Username can be set to the RDP
* Test keyboard layout switching works correctly
** On Live media, Anaconda should react on keyboard layout change in
the DE and set that to the installed system
** On Live media, Anaconda should be able to set the keyboard layout
changes to the live environment
** In the network installation (boot.iso) Anaconda should correctly
reflect keyboard layouts changes so text in the Anaconda is written by
the correct layout
** Check if specific keyboard layouts are configured and installed as expected
== User Experience ==
The only visible change to a user should be:
* Remote graphical installations will use RDP instead of VNC.
* Anaconda will be able to control keyboard layouts in the Wayland
environment on Live ISOs. This will improve user experience when
installing Fedora Workstation, Fedora KDE, Fedora Sway and other
Wayland based environments.
== Dependencies ==
No dependencies of this package related to this change.
== Contingency Plan ==
* Contingency mechanism: Postpone this change to the next Fedora
release. Revert landed changes in Anaconda if required.
* Contingency deadline: 100% code completion deadline
* Blocks release? No
== Documentation ==
No documentation yet. However, there are a few PRs ready for merge for
CentOS Stream 10:
* https://github.com/rhinstaller/anaconda/pull/5463
* https://github.com/rhinstaller/anaconda/pull/5470
* https://github.com/rhinstaller/anaconda/pull/5485
* https://github.com/rhinstaller/anaconda/pull/5498
== Release Notes ==
TBD
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
--
_______________________________________________
devel-announce mailing list -- devel-announce(a)lists.fedoraproject.org
To unsubscribe send an email to devel-announce-leave(a)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-announce@lists.fedora...
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
6:36 a.m.
New subject: F41 Change Proposal: Anaconda as native Wayland application
(System Wide)
To my knowledge it shouldn't be. Fedora Workstation is already running
on Wayland by default for quite some time and even Live ISO is already
Wayland. To my knowledge Wayland don't have issues with graphics cards
in general.
The only exception to my knowledge is Sway, where this is an upstream
project issue they are trying to resolve. However, Sway is Wayland only
so again no impact from this change.
But maybe someone who has more knowledge about compositors and GPU
drivers would answer this better than me.
Best Regards,
Jirka
On 31. 05. 24 10:58, Barry wrote:
> On 31 May 2024, at 09:36, Aoife Moloney <amoloney(a)redhat.com> wrote:
>
> Anaconda is required to migrate to Wayland native application to drop
> dependencies from the installation ISO images which are deprecated.
Do you expect this to be an issue for users with nvidia GPUs?
Barry
--
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
10:04 a.m.
New subject: F41 Change Proposal: Anaconda as native Wayland application
(System Wide)
On Fri, 2024-05-31 at 13:36 +0200, Jiri Konecny wrote:
To my knowledge it shouldn't be. Fedora Workstation is already
running
on Wayland by default for quite some time and even Live ISO is already
Wayland. To my knowledge Wayland don't have issues with graphics cards
in general.
GNOME has a fallback mechanism where it automatically runs the X.org
session if the Wayland session doesn't work. I believe that is active
on the live image. Of course, as telemetry is evil, we have absolutely
no idea how many Fedora users actually hit this mechanism.
--
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @adamw(a)fosstodon.org
https://www.happyassassin.net
10:07 a.m.
New subject: F41 Change Proposal: Anaconda as native Wayland application
(System Wide)
Sounds good!
Leslie Satenstein
On Friday, May 31, 2024 at 11:05:14 a.m. EDT, Adam Williamson
<adamwill(a)fedoraproject.org> wrote:
On Fri, 2024-05-31 at 13:36 +0200, Jiri Konecny wrote:
To my knowledge it shouldn't be. Fedora Workstation is already
running
on Wayland by default for quite some time and even Live ISO is already
Wayland. To my knowledge Wayland don't have issues with graphics cards
in general.
GNOME has a fallback mechanism where it automatically runs the X.org
session if the Wayland session doesn't work. I believe that is active
on the live image. Of course, as telemetry is evil, we have absolutely
no idea how many Fedora users actually hit this mechanism.
--
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @adamw(a)fosstodon.org
https://www.happyassassin.net
--
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
10:39 p.m.
New subject: F41 Change Proposal: Anaconda as native Wayland application
(System Wide)
On 6/1/24 1:04 AM, Adam Williamson wrote:
On Fri, 2024-05-31 at 13:36 +0200, Jiri Konecny wrote:
> To my knowledge it shouldn't be. Fedora Workstation is already running
> on Wayland by default for quite some time and even Live ISO is already
> Wayland. To my knowledge Wayland don't have issues with graphics cards
> in general.
GNOME has a fallback mechanism where it automatically runs the X.org
session if the Wayland session doesn't work. I believe that is active
on the live image. Of course, as telemetry is evil, we have absolutely
no idea how many Fedora users actually hit this mechanism.
One comment I would make is that VirtualBox doesn't *properly* support
Wayland [yet] requiring GNOME to be run as an Xorg session (of course
not an issue for Xfce etc).
If Anaconda is to be Wayland, my concern is that it may make all DEs
uninstallable, even ones like Xfce far removed from Wayland.
--
Ian Laurie
FAS: nixuser | IRC: nixuser
TZ: Australia/Sydney
1:21 a.m.
New subject: F41 Change Proposal: Anaconda as native Wayland application
(System Wide)
On Tue, 2024-06-04 at 13:39 +1000, Ian Laurie via devel wrote:
On 6/1/24 1:04 AM, Adam Williamson wrote:
> On Fri, 2024-05-31 at 13:36 +0200, Jiri Konecny wrote:
> > To my knowledge it shouldn't be. Fedora Workstation is already running
> > on Wayland by default for quite some time and even Live ISO is already
> > Wayland. To my knowledge Wayland don't have issues with graphics cards
> > in general.
>
> GNOME has a fallback mechanism where it automatically runs the X.org
> session if the Wayland session doesn't work. I believe that is active
> on the live image. Of course, as telemetry is evil, we have absolutely
> no idea how many Fedora users actually hit this mechanism.
One comment I would make is that VirtualBox doesn't *properly* support
Wayland [yet] requiring GNOME to be run as an Xorg session (of course
not an issue for Xfce etc).
If Anaconda is to be Wayland, my concern is that it may make all DEs
uninstallable, even ones like Xfce far removed from Wayland.
Looking at the change, it's not totally clear to me, but it looks like
this is actually mainly about how anaconda is run in the installer
environment - netinst, server DVD, and ostree installer images. It's
not about live images.
I *think* anaconda would continue to run as an X app if launched from a
live desktop running on X. But it would be nice to have that clarified
in the Change scope, and any changes to how it would behave in such an
environment.
--
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @adamw(a)fosstodon.org
https://www.happyassassin.net
7:23 a.m.
New subject: F41 Change Proposal: Anaconda as native Wayland application
(System Wide)
On 04. 06. 24 8:21, Adam Williamson wrote:
On Tue, 2024-06-04 at 13:39 +1000, Ian Laurie via devel wrote:
> On 6/1/24 1:04 AM, Adam Williamson wrote:
>> On Fri, 2024-05-31 at 13:36 +0200, Jiri Konecny wrote:
>>> To my knowledge it shouldn't be. Fedora Workstation is already running
>>> on Wayland by default for quite some time and even Live ISO is already
>>> Wayland. To my knowledge Wayland don't have issues with graphics cards
>>> in general.
>> GNOME has a fallback mechanism where it automatically runs the X.org
>> session if the Wayland session doesn't work. I believe that is active
>> on the live image. Of course, as telemetry is evil, we have absolutely
>> no idea how many Fedora users actually hit this mechanism.
> One comment I would make is that VirtualBox doesn't *properly* support
> Wayland [yet] requiring GNOME to be run as an Xorg session (of course
> not an issue for Xfce etc).
>
> If Anaconda is to be Wayland, my concern is that it may make all DEs
> uninstallable, even ones like Xfce far removed from Wayland.
Looking at the change, it's not totally clear to me, but it looks like
this is actually mainly about how anaconda is run in the installer
environment - netinst, server DVD, and ostree installer images. It's
not about live images.
I *think* anaconda would continue to run as an X app if launched from a
live desktop running on X. But it would be nice to have that clarified
in the Change scope, and any changes to how it would behave in such an
environment.
Is it better now? I tried to extend the Scope section of the change.
Best Regards,
Jirka
1:03 p.m.
New subject: F41 Change Proposal: Anaconda as native Wayland application
(System Wide)
On Tue, 2024-06-04 at 14:23 +0200, Jiri Konecny wrote:
On 04. 06. 24 8:21, Adam Williamson wrote:
> On Tue, 2024-06-04 at 13:39 +1000, Ian Laurie via devel wrote:
> > On 6/1/24 1:04 AM, Adam Williamson wrote:
> > > On Fri, 2024-05-31 at 13:36 +0200, Jiri Konecny wrote:
> > > > To my knowledge it shouldn't be. Fedora Workstation is already
running
> > > > on Wayland by default for quite some time and even Live ISO is
already
> > > > Wayland. To my knowledge Wayland don't have issues with graphics
cards
> > > > in general.
> > > GNOME has a fallback mechanism where it automatically runs the X.org
> > > session if the Wayland session doesn't work. I believe that is active
> > > on the live image. Of course, as telemetry is evil, we have absolutely
> > > no idea how many Fedora users actually hit this mechanism.
> > One comment I would make is that VirtualBox doesn't *properly* support
> > Wayland [yet] requiring GNOME to be run as an Xorg session (of course
> > not an issue for Xfce etc).
> >
> > If Anaconda is to be Wayland, my concern is that it may make all DEs
> > uninstallable, even ones like Xfce far removed from Wayland.
> Looking at the change, it's not totally clear to me, but it looks like
> this is actually mainly about how anaconda is run in the installer
> environment - netinst, server DVD, and ostree installer images. It's
> not about live images.
>
> I *think* anaconda would continue to run as an X app if launched from a
> live desktop running on X. But it would be nice to have that clarified
> in the Change scope, and any changes to how it would behave in such an
> environment.
Is it better now? I tried to extend the Scope section of the change.
Yes, that does look clearer. Thanks.
--
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @adamw(a)fosstodon.org
https://www.happyassassin.net
3:34 a.m.
New subject: F41 Change Proposal: Anaconda as native Wayland application
(System Wide)
Hi Ian,
On 6/4/24 5:39 AM, Ian Laurie via devel wrote:
On 6/1/24 1:04 AM, Adam Williamson wrote:
> On Fri, 2024-05-31 at 13:36 +0200, Jiri Konecny wrote:
>> To my knowledge it shouldn't be. Fedora Workstation is already running
>> on Wayland by default for quite some time and even Live ISO is already
>> Wayland. To my knowledge Wayland don't have issues with graphics cards
>> in general.
>
> GNOME has a fallback mechanism where it automatically runs the X.org
> session if the Wayland session doesn't work. I believe that is active
> on the live image. Of course, as telemetry is evil, we have absolutely
> no idea how many Fedora users actually hit this mechanism.
One comment I would make is that VirtualBox doesn't *properly* support
Wayland [yet] requiring GNOME to be run as an Xorg session (of course
not an issue for Xfce etc).
I'm a bit surprised by this. I use VirtualBox both as host under a GNOME
wayland session and the guests inside that VirtualBox host also use
Wayland.
The only feature which I'm aware of which does not work is the mode
where only the guest windows are shown. Everything else works fine.
What exactly is not working for you when you run a GNOME Wayland
session inside a VirtualBox guest ?
Regards,
Hans
3:56 a.m.
New subject: F41 Change Proposal: Anaconda as native Wayland application
(System Wide)
On Tue, Jun 4, 2024 at 4:34 AM Hans de Goede <hdegoede(a)redhat.com> wrote:
Hi Ian,
On 6/4/24 5:39 AM, Ian Laurie via devel wrote:
> On 6/1/24 1:04 AM, Adam Williamson wrote:
>> On Fri, 2024-05-31 at 13:36 +0200, Jiri Konecny wrote:
>>> To my knowledge it shouldn't be. Fedora Workstation is already running
>>> on Wayland by default for quite some time and even Live ISO is already
>>> Wayland. To my knowledge Wayland don't have issues with graphics cards
>>> in general.
>>
>> GNOME has a fallback mechanism where it automatically runs the X.org
>> session if the Wayland session doesn't work. I believe that is active
>> on the live image. Of course, as telemetry is evil, we have absolutely
>> no idea how many Fedora users actually hit this mechanism.
>
> One comment I would make is that VirtualBox doesn't *properly* support
> Wayland [yet] requiring GNOME to be run as an Xorg session (of course
> not an issue for Xfce etc).
I'm a bit surprised by this. I use VirtualBox both as host under a GNOME
wayland session and the guests inside that VirtualBox host also use
Wayland.
The only feature which I'm aware of which does not work is the mode
where only the guest windows are shown. Everything else works fine.
What exactly is not working for you when you run a GNOME Wayland
session inside a VirtualBox guest ?
There have been significant issues with GNOME and KDE Plasma on
VirtualBox over the past few years. Honestly, we need to start
regularly testing it, because the guest integration is brittle and
nobody notices until it's too late. I personally do testing on VMware
for KDE Plasma because otherwise it'd never get tested and issues
would never get fixed.
The most recent issue is that it's unbearably slow and sometimes
suffers serious graphics corruption unless 3D acceleration is turned
on.
--
真実はいつも一つ！/ Always, there's only one truth!
6:52 p.m.
New subject: F41 Change Proposal: Anaconda as native Wayland application
(System Wide)
On 6/4/24 6:56 PM, Neal Gompa wrote:
The most recent issue is that it's unbearably slow and sometimes
suffers serious graphics corruption unless 3D acceleration is turned
on.
Current best practice appears to be that 3D must be turned off. With it
on, nothing works, not even an Xorg session. However, it is fickle,
depending on the GNOME stack, there have been times when 3D on was
better. With 3D off, and GNOME in an Xorg session, it almost works.
--
Ian Laurie
FAS: nixuser | IRC: nixuser
TZ: Australia/Sydney
6:47 p.m.
New subject: F41 Change Proposal: Anaconda as native Wayland application
(System Wide)
On 6/4/24 6:34 PM, Hans de Goede wrote:
What exactly is not working for you when you run a GNOME Wayland
session inside a VirtualBox guest ?
Hi Hans,
Sadly in my case I suffer the full range of problems, blocky massive
empty cursor, Old TV style loss of horizontal sync (video buffer overlap
problem apparently).... basically I have all the issues outlined below
with screen shots shown, topics posted relate to Ubuntu but I have the
issue on Fedora (in my case, host is Fedora-Xfce-40 and guest is
Fedora-GNOME-40):
https://forums.virtualbox.org/viewtopic.php?t=110882
https://forums.virtualbox.org/viewtopic.php?t=110982
https://www.virtualbox.org/ticket/21955
The above links have many other links, but see comment 22 on the ticket.
On my recent failed attempt for a GNOME VM under VirtualBox, I converted
the VM to QEMU/KVM via a raw image (not a difficult procedure). Under
QEMU/KVM the exact same VM install works flawlessly. So it wasn't that
my installation went wrong.
--
Ian Laurie
FAS: nixuser | IRC: nixuser
TZ: Australia/Sydney
1:57 a.m.
Ian Laurie via devel venit, vidit, dixit 2024-06-05 01:47:47:
On 6/4/24 6:34 PM, Hans de Goede wrote:
> What exactly is not working for you when you run a GNOME Wayland
> session inside a VirtualBox guest ?
Hi Hans,
Sadly in my case I suffer the full range of problems, blocky massive
empty cursor, Old TV style loss of horizontal sync (video buffer overlap
problem apparently).... basically I have all the issues outlined below
with screen shots shown, topics posted relate to Ubuntu but I have the
issue on Fedora (in my case, host is Fedora-Xfce-40 and guest is
Fedora-GNOME-40):
https://forums.virtualbox.org/viewtopic.php?t=110882
https://forums.virtualbox.org/viewtopic.php?t=110982
https://www.virtualbox.org/ticket/21955
The above links have many other links, but see comment 22 on the ticket.
On my recent failed attempt for a GNOME VM under VirtualBox, I converted
the VM to QEMU/KVM via a raw image (not a difficult procedure). Under
QEMU/KVM the exact same VM install works flawlessly. So it wasn't that
my installation went wrong.
Doesn't this prove that it's really a VirtualBox problem, not a Fedora
problem?
I mean, we still want Fedora to run "everywhere", but the previous
discussion indicated a "Fedora problem", and your observations put
things into perspective.
Michael
5:24 p.m.
New subject: F41 Change Proposal: Anaconda as native Wayland application
(System Wide)
On 6/5/24 4:57 PM, Michael J Gruber wrote:
> Doesn't this prove that it's really a VirtualBox problem,
not a Fedora
> problem?
>
> I mean, we still want Fedora to run "everywhere", but the previous
> discussion indicated a "Fedora problem", and your observations put
> things into perspective.
Virtual machines have to sneak out of their virtual existence and
interact with the real world now and then, or they would be pointless,
so virtualization is ultimately a fudge. The graphics side of it being
the most complex part of the fudge.
I agree it is the task of the virtualization engine to keep up with
guests developments and keep the fudge working, but Xorg works, and
Wayland doesn't, and as a user I don't really care who is at fault.
If there were a little more give and take there could be fewer
problems. As I understand things, the rush to run Anaconda in Wayland
is going to break workflows because many folks DL the
Everything-Netinstall ISOs and use it to install anything. Since the
move to Wayland is unnecessary, it seems like it could be delayed until
Wayland is better supported by the wider ecosystem.
Of all things, the installation mechanism should be chosen to be as
broadly compatible with as much as possible, and frankly Wayland is
currently not that.
That said, if my whole life was Linux, I would move to a QEMU/KVM only
workflow, but I still have one pesky Win box in my life that I can't get
rid of (at work) so VirtualBox for me still makes sense.
--
Ian Laurie
FAS: nixuser | IRC: nixuser
TZ: Australia/Sydney
7:26 a.m.
New subject: F41 Change Proposal: Anaconda as native Wayland application
(System Wide)
On 04. 06. 24 5:39, Ian Laurie via devel wrote:
On 6/1/24 1:04 AM, Adam Williamson wrote:
> On Fri, 2024-05-31 at 13:36 +0200, Jiri Konecny wrote:
>> To my knowledge it shouldn't be. Fedora Workstation is already running
>> on Wayland by default for quite some time and even Live ISO is already
>> Wayland. To my knowledge Wayland don't have issues with graphics cards
>> in general.
>
> GNOME has a fallback mechanism where it automatically runs the X.org
> session if the Wayland session doesn't work. I believe that is active
> on the live image. Of course, as telemetry is evil, we have absolutely
> no idea how many Fedora users actually hit this mechanism.
One comment I would make is that VirtualBox doesn't *properly* support
Wayland [yet] requiring GNOME to be run as an Xorg session (of course
not an issue for Xfce etc).
If Anaconda is to be Wayland, my concern is that it may make all DEs
uninstallable, even ones like Xfce far removed from Wayland.
You should be able to install from Live ISO which we are not modifying
(depends on environment set by SIG owners). However, we won't support
X11 together with Wayland on boot.iso. That would be hard to achieve
given to the big amount of changes we are required to do now to support
Wayland.
Jirka
--
Ian Laurie
FAS: nixuser | IRC: nixuser
TZ: Australia/Sydney
--
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
7:52 a.m.
New subject: F41 Change Proposal: Anaconda as native Wayland application
(System Wide)
On Tue, 2024-06-04 at 14:26 +0200, Jiri Konecny wrote:
On 04. 06. 24 5:39, Ian Laurie via devel wrote:
> On 6/1/24 1:04 AM, Adam Williamson wrote:
> > On Fri, 2024-05-31 at 13:36 +0200, Jiri Konecny wrote:
> > > To my knowledge it shouldn't be. Fedora Workstation is already
> > > running
> > > on Wayland by default for quite some time and even Live ISO is
> > > already
> > > Wayland. To my knowledge Wayland don't have issues with
> > > graphics cards
> > > in general.
> >
> > GNOME has a fallback mechanism where it automatically runs the
> > X.org
> > session if the Wayland session doesn't work. I believe that is
> > active
> > on the live image. Of course, as telemetry is evil, we have
> > absolutely
> > no idea how many Fedora users actually hit this mechanism.
>
> One comment I would make is that VirtualBox doesn't *properly*
> support
> Wayland [yet] requiring GNOME to be run as an Xorg session (of
> course
> not an issue for Xfce etc).
>
> If Anaconda is to be Wayland, my concern is that it may make all
> DEs
> uninstallable, even ones like Xfce far removed from Wayland.
>
You should be able to install from Live ISO which we are not
modifying
(depends on environment set by SIG owners). However, we won't support
X11 together with Wayland on boot.iso. That would be hard to achieve
given to the big amount of changes we are required to do now to
support
Wayland.
If you can't support X11 together with Wayland on boot.iso , why you
want move to Wayland ? it is stupid break Linux user experience just
because Wayland is fancy , what we get with Wayland that we don't get
with X11 ? if you need remove X11 to add Wayland, don't do it ! . Don't
break the other Linux user systems . Is difficult understand that you
should not remove components without agreement of everyone ?
Linux should support all kind of hardware, if Wayland don't, you should
provide at least fall backs , and not just ignore the others .
The removal of X11 from KDE , just because KDE SIG decide without
consent of many members of Fedora which contribute to Fedora KDE ,
should not be acceptable .
Waste my energy discussing things that should be obvious , make me
think if I still should contribute to this project .
Like Linus says "DON'T BREAK THE USER SPACE"
Best regards,
Jirka
> --
> Ian Laurie
> FAS: nixuser | IRC: nixuser
> TZ: Australia/Sydney
> --
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines:
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
--
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
--
Sérgio M. B.
8:26 a.m.
New subject: F41 Change Proposal: Anaconda as native Wayland application
(System Wide)
Am 11.06.24 um 14:52 schrieb Sérgio Basto:
On Tue, 2024-06-04 at 14:26 +0200, Jiri Konecny wrote:
> On 04. 06. 24 5:39, Ian Laurie via devel wrote:
>> On 6/1/24 1:04 AM, Adam Williamson wrote:
>>> On Fri, 2024-05-31 at 13:36 +0200, Jiri Konecny wrote:
>>>> To my knowledge it shouldn't be. Fedora Workstation is already
>>>> running
>>>> on Wayland by default for quite some time and even Live ISO is
>>>> already
>>>> Wayland. To my knowledge Wayland don't have issues with
>>>> graphics cards
>>>> in general.
>>>
>>> GNOME has a fallback mechanism where it automatically runs the
>>> X.org
>>> session if the Wayland session doesn't work. I believe that is
>>> active
>>> on the live image. Of course, as telemetry is evil, we have
>>> absolutely
>>> no idea how many Fedora users actually hit this mechanism.
>>
>> One comment I would make is that VirtualBox doesn't *properly*
>> support
>> Wayland [yet] requiring GNOME to be run as an Xorg session (of
>> course
>> not an issue for Xfce etc).
>>
>> If Anaconda is to be Wayland, my concern is that it may make all
>> DEs
>> uninstallable, even ones like Xfce far removed from Wayland.
>>
> You should be able to install from Live ISO which we are not
> modifying
> (depends on environment set by SIG owners). However, we won't support
> X11 together with Wayland on boot.iso. That would be hard to achieve
> given to the big amount of changes we are required to do now to
> support
> Wayland.
If you can't support X11 together with Wayland on boot.iso , why you
want move to Wayland ? it is stupid break Linux user experience just
because Wayland is fancy , what we get with Wayland that we don't get
with X11 ?
Security! Maintained ...
if you need remove X11 to add Wayland, don't do it ! . Don't
break the other Linux user systems . Is difficult understand that you
should not remove components without agreement of everyone ?
Linux should support all kind of hardware, if Wayland don't, you should
provide at least fall backs , and not just ignore the others .
+1, the user base is diverse, so should the solutions.
The removal of X11 from KDE , just because KDE SIG decide without
consent of many members of Fedora which contribute to Fedora KDE ,
should not be acceptable .
Waste my energy discussing things that should be obvious , make me
think if I still should contribute to this project.
You should - this issue is only a tiny part of the whole project.
Its a great project with great people.
Like Linus says "DON'T BREAK THE USER SPACE"
Its easy to say that when walking only in kernel space.
--
Leon
12:48 p.m.
On Tuesday 11 June 2024 14:52:19 CEST Sérgio Basto wrote:
I had enough with you an your attitude. You have been abusing the good will
and temperament of many Fedora contributors for too long. Somebody must put a
stop to your comments and behavior.
If you can't support X11 together with Wayland on boot.iso , why
you
want move to Wayland ?
The explanation to this is very clearly explained in the == Detailed
Description === section
it is stupid break Linux user experience just
because Wayland is fancy ,
Refrain from calling our actions or (implicitly) our contributors _stupid_
That is just not acceptable. Period.
Not to mention that nobody is breaking any user experience. Your mind is so
distorted that whenever you see "Wayland" you get immediately triggered and
you fight whatever is going on in the discussion.
what we get with Wayland that we don't get
with X11 ?
This has been explained so many times that the fact that you keep asking this
over and over and over is just making you look like somebody one cannot have a
conversation with.
if you need remove X11 to add Wayland, don't do it ! .
Again, the reasoning has been explained in the == Detailed Description ==
section
Don't
break the other Linux user systems .
Nobody is breaking anything. Stop spreading FUD.
Is difficult understand that you
should not remove components without agreement of everyone ?
yes, sure, like absolutely everything in our society needs to be agreed by
100% of the people. Of course.
Do you realize how non nonsensical that sounds?
Linux should support all kind of hardware, if Wayland don't, you
should
provide at least fall backs , and not just ignore the others .
That is only *your* view. Please explain me why I cannot install Fedora in my
AMD K6-2 or my Pentium 200 MMX (because I cannot, it is not supported
anymore).
Linux should support all kind of hardware, right?
¯\_(ツ)_/¯
The removal of X11 from KDE , just because KDE SIG decide without
consent of many members of Fedora which contribute to Fedora KDE ,
should not be acceptable .
Why on earth would you bring this here? I am not sure you can understand how
childish you look by doing this sort of thing.
Waste my energy discussing things that should be obvious , make me
think if I still should contribute to this project .
If you ask me? Please don't. I personally do not want to deal with
contributors with the attitude that you have.
Like Linus says "DON'T BREAK THE USER SPACE"
Is that supposed to mean anything? Just because the kernel maintainer says
something it doesn't mean that is a rule written by the Heavens and The All
Mighty and we must follow it.
(for the record, the linux kernel *has* broken userspace in the past. Just
saying).
Best regards,
Marc Deop
4:36 p.m.
New subject: F41 Change Proposal: Anaconda as native Wayland application
(System Wide)
On Tue, 2024-06-11 at 19:48 +0200, Marc Deop i Argemí wrote:
On Tuesday 11 June 2024 14:52:19 CEST Sérgio Basto wrote:
I had enough with you an your attitude. You have been abusing the
good will
and temperament of many Fedora contributors for too long. Somebody
must put a
stop to your comments and behavior.
> If you can't support X11 together with Wayland on boot.iso , why
> you
> want move to Wayland ?
The explanation to this is very clearly explained in the == Detailed
Description === section
> it is stupid break Linux user experience just
> because Wayland is fancy ,
Refrain from calling our actions or (implicitly) our contributors
_stupid_
I don't want that you deduce that.
OK I 'll try be more inclusive BTW I confused you with user moceap.
yeah I think try removing X11 is not right path that is my opinion.
And you don't have the right of remove X11 software from Fedora .
You aren't adding software, you are trying removing X11 and impose
Wayland because, I think, you want that people test wayland, you think
if people test more, the things will be fixed by them self but I don't
think that is true, see the case of btrfs , still missing core
functionalities, hopefully nobody tried to remove ext4.
Moreover I won't test wayland, wayland simple is not ready for me. I
don't use wayland and I want maintain X11
About benefit to Fedora
https://fedoraproject.org/wiki/Changes/Anaconda_As_Native_Wayland_Applica...
- RDP is more secure that VNC ? this is not an argument, and typically
is not an honest argument. VNC works over ssh, is more light, is more
quick and is better in all aspect that I can think of. So RDP is not a
benefit is an escape to VNC problem .
- This change will enable removal of X11 dependencies from the Anaconda
which may result in reduction of installed software ? you don't even
know if reduce the installed software , so in my conclusion also is not
an argument .
So zero benefits to Fedora, on other hand any old computer with a
graphic where drives don't support wayland will have problems .
So is the same problem of kde-X11 and is not just me, several people
already state the same.
And I'd like discuss this
That is just not acceptable. Period.
What for me is not acceptable disable kwin-x11, just because yes , and
give a bunch of work to the others , everywhere forum, discourse ,
chat , email bugzilla, we have to explain what happened , with X11 ,
how reinstall X11 , so is just not me .
Not to mention that nobody is breaking any user experience. Your
mind
is so
distorted that whenever you see "Wayland" you get immediately
triggered and
you fight whatever is going on in the discussion.
The problem is not Wayland , the problem is remove X11, and the x11
experience . If you enable wayland but keep X11 as fallback I hadn't
any problem .
> what we get with Wayland that we don't get
> with X11 ?
This has been explained so many times that the fact that you keep
asking this
over and over and over is just making you look like somebody one
cannot have a
conversation with.
> if you need remove X11 to add Wayland, don't do it ! .
Again, the reasoning has been explained in the == Detailed
Description ==
section
> Don't
> break the other Linux user systems .
Nobody is breaking anything. Stop spreading FUD.
No, is not FUD, because we got this experience in Fedora 40, _all_ old
nvidia drives simple don't support wayland .
> Is difficult understand that you
> should not remove components without agreement of everyone ?
>
yes, sure, like absolutely everything in our society needs to be
agreed by
100% of the people. Of course.
Do you realize how non nonsensical that sounds
Until a few weeks ago, there was always agreement and consensus among
everyone, here in Fedora, in 20 years I don't remember any discussion
like these one.
> Linux should support all kind of hardware, if Wayland don't,
you
> should
> provide at least fall backs , and not just ignore the others .
That is only *your* view. Please explain me why I cannot install
Fedora in my
AMD K6-2 or my Pentium 200 MMX (because I cannot, it is not supported
anymore).
Linux should support all kind of hardware, right?
¯\_(ツ)_/¯
:thumbs up:
>
> The removal of X11 from KDE , just because KDE SIG decide without
> consent of many members of Fedora which contribute to Fedora KDE ,
> should not be acceptable .
Why on earth would you bring this here? I am not sure you can
understand how
childish you look by doing this sort of thing.
no, that is the main problem is the removal of X11 .
>
> Waste my energy discussing things that should be obvious , make me
> think if I still should contribute to this project .
If you ask me? Please don't. I personally do not want to deal with
contributors with the attitude that you have.
me too , please stop your contributions to Fedora and attempts of
remove X11 , you make me miss the previous maintainers a lot .
>
> Like Linus says "DON'T BREAK THE USER SPACE"
Is that supposed to mean anything? Just because the kernel maintainer
says
something it doesn't mean that is a rule written by the Heavens and
The All
Mighty and we must follow it.
(for the record, the linux kernel *has* broken userspace in the past.
Just
saying).
This is a principle that means that you should avoid break things and
should provide fallback
(I don't have more time)
Best regards,
--
Sérgio M. B.
5:45 a.m.
New subject: F41 Change Proposal: Anaconda as native Wayland application
(System Wide)
On Tue, Jun 11, 2024 at 01:52:19PM +0100, Sérgio Basto wrote:
On Tue, 2024-06-04 at 14:26 +0200, Jiri Konecny wrote:
> You should be able to install from Live ISO which we are not
> modifying
> (depends on environment set by SIG owners). However, we won't support
> X11 together with Wayland on boot.iso. That would be hard to achieve
> given to the big amount of changes we are required to do now to
> support
> Wayland.
If you can't support X11 together with Wayland on boot.iso , why you
want move to Wayland ? it is stupid break Linux user experience just
because Wayland is fancy , what we get with Wayland that we don't get
with X11 ? if you need remove X11 to add Wayland, don't do it ! . Don't
break the other Linux user systems . Is difficult understand that you
should not remove components without agreement of everyone ?
Linux should support all kind of hardware, if Wayland don't, you should
provide at least fall backs , and not just ignore the others .
Open Source software in general supports a wide variety of use cases and
hardware. The role of most Linux distros, however, is NOT to provide a
solution for every conceivable scenario or hardware or user.
Instead a Linux distro exists to pull together a curated set of software
that best solves the set of goals their distro has. Each Linux distro
will have their own priorities, and make different tradeoffs in choosing
what software to provide & how to configure & use stuff they do provide.
What we're seeing here is that in Fedora, the distro priorities & goals
are taking us down a path of prioritizing Wayland, over X11. This is a
valid decision & direction for Fedora to choose, because it aligns with
our distro mission statement, part of which is to focus on innovation.
At times some users will be left without support for things that previously
worked, and thus be unhappy with the result. That is an unfortunate, but at
the same time, acceptable outcome. Fedora is not trying to cater to every
possible user feature demand, it is trying to optimize for its mission.
The beauty of open source is that users have a choice to distros, and can
select whichever has a mission & deliverables that best satisfy the user's
needs. There will be distros around that aim to support X11 with a higher
priority.
With regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
7:04 a.m.
New subject: F41 Change Proposal: Anaconda as native Wayland application
(System Wide)
On Fri, 2024-05-31 at 08:04 -0700, Adam Williamson wrote:
On Fri, 2024-05-31 at 13:36 +0200, Jiri Konecny wrote:
> To my knowledge it shouldn't be. Fedora Workstation is already
> running
> on Wayland by default for quite some time and even Live ISO is
> already
> Wayland. To my knowledge Wayland don't have issues with graphics
> cards
> in general.
GNOME has a fallback mechanism where it automatically runs the X.org
session if the Wayland session doesn't work. I believe that is active
on the live image. Of course, as telemetry is evil, we have
absolutely
no idea how many Fedora users actually hit this mechanism.
TL;DR; if you may fallback to X11 , I don't have problems.
If we don't have way to use X11 , is just break Linux for many users
--
Sérgio M. B.
12:16 p.m.
On 31 May 2024, at 12:36, Jiri Konecny <jkonecny(a)redhat.com>
wrote:
To my knowledge Wayland don't have issues with graphics cards in general.
Isn’t the nouveau driver known to have wayland support issues with
some nvidia chip set generations? Sorry I am not across the detail
of which chips set maybe a problem.
Lots of users end up using the rpmfusion nvidia drivers to get a working DE.
See the almost daily nvidia support we handle on fedora discuss.
Barry
5:24 a.m.
New subject: F41 Change Proposal: Anaconda as native Wayland application
(System Wide)
I'm not able to tell, I'm not involved into Wayland enough.
Hi Ray, Jose do you know something about what is written below?
Jirka
On 31. 05. 24 19:16, Barry wrote:
> On 31 May 2024, at 12:36, Jiri Konecny <jkonecny(a)redhat.com> wrote:
>
> To my knowledge Wayland don't have issues with graphics cards in general.
Isn’t the nouveau driver known to have wayland support issues with
some nvidia chip set generations? Sorry I am not across the detail
of which chips set maybe a problem.
Lots of users end up using the rpmfusion nvidia drivers to get a working DE.
See the almost daily nvidia support we handle on fedora discuss.
Barry
2:57 p.m.
New subject: F41 Change Proposal: Anaconda as native Wayland application
(System Wide)
>>>> Aoife Moloney <amoloney(a)redhat.com> writes:
=== VNC switch to RDP for remote GUI installations ===
I'm curious how my usual install workflow will be affected by this
change. I use the kickstart "vnc --connect" option extensively in my
workflow; I may have a bunch of installs running in parallel, and they
just connect and display when they are ready. I use vinagre as the vnc
client.
It's not a huge thing; I could come up with another workflow but that's
the one I've used since before Fedora existed. The installs are fully
automated and the display connection is only used so that I can see the
progress and potentially interact with a machine if it encounters a
problem. I guess in the worst case I could just do the install blind
and ssh in if something takes too long.
- J<
7:22 a.m.
New subject: F41 Change Proposal: Anaconda as native Wayland application
(System Wide)
On 03. 06. 24 21:57, Jason L Tibbitts III wrote:
>>>>> Aoife Moloney <amoloney(a)redhat.com>
writes:
> === VNC switch to RDP for remote GUI installations ===
I'm curious how my usual install workflow will be affected by this
change. I use the kickstart "vnc --connect" option extensively in my
workflow; I may have a bunch of installs running in parallel, and they
just connect and display when they are ready. I use vinagre as the vnc
client.
It's not a huge thing; I could come up with another workflow but that's
the one I've used since before Fedora existed. The installs are fully
automated and the display connection is only used so that I can see the
progress and potentially interact with a machine if it encounters a
problem. I guess in the worst case I could just do the install blind
and ssh in if something takes too long.
Hi, the only change should be that you will
change "vnc --connect" with
the new API we will provide and also use RDP as your client instead of VNC.
Best Regards,
Jirka
- J<
--
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
7:27 a.m.
New subject: F41 Change Proposal: Anaconda as native Wayland application
(System Wide)
On Tue, Jun 4, 2024 at 8:23 AM Jiri Konecny <jkonecny(a)redhat.com> wrote:
On 03. 06. 24 21:57, Jason L Tibbitts III wrote:
>>>>>> Aoife Moloney <amoloney(a)redhat.com> writes:
>> === VNC switch to RDP for remote GUI installations ===
> I'm curious how my usual install workflow will be affected by this
> change. I use the kickstart "vnc --connect" option extensively in my
> workflow; I may have a bunch of installs running in parallel, and they
> just connect and display when they are ready. I use vinagre as the vnc
> client.
>
> It's not a huge thing; I could come up with another workflow but that's
> the one I've used since before Fedora existed. The installs are fully
> automated and the display connection is only used so that I can see the
> progress and potentially interact with a machine if it encounters a
> problem. I guess in the worst case I could just do the install blind
> and ssh in if something takes too long.
Hi, the only change should be that you will change "vnc --connect" with
the new API we will provide and also use RDP as your client instead of VNC.
Given that gnome-remote-desktop supports both VNC and RDP, can't VNC
support still be wired up?
--
真実はいつも一つ！/ Always, there's only one truth!
3:41 a.m.
New subject: F41 Change Proposal: Anaconda as native Wayland application
(System Wide)
On 04. 06. 24 14:27, Neal Gompa wrote:
On Tue, Jun 4, 2024 at 8:23 AM Jiri Konecny
<jkonecny(a)redhat.com> wrote:
>
>
> On 03. 06. 24 21:57, Jason L Tibbitts III wrote:
>>>>>>> Aoife Moloney <amoloney(a)redhat.com> writes:
>>> === VNC switch to RDP for remote GUI installations ===
>> I'm curious how my usual install workflow will be affected by this
>> change. I use the kickstart "vnc --connect" option extensively in my
>> workflow; I may have a bunch of installs running in parallel, and they
>> just connect and display when they are ready. I use vinagre as the vnc
>> client.
>>
>> It's not a huge thing; I could come up with another workflow but that's
>> the one I've used since before Fedora existed. The installs are fully
>> automated and the display connection is only used so that I can see the
>> progress and potentially interact with a machine if it encounters a
>> problem. I guess in the worst case I could just do the install blind
>> and ssh in if something takes too long.
> Hi, the only change should be that you will change "vnc --connect" with
> the new API we will provide and also use RDP as your client instead of VNC.
>
Given that gnome-remote-desktop supports both VNC and RDP, can't VNC
support still be wired up?
Hi, it is theoretically possible but we are not planning to do that
until there will be a reason for that. AFAIK it's not that simple change
to do that.
Jirka
4:53 a.m.
New subject: F41 Change Proposal: Anaconda as native Wayland application
(System Wide)
On Tue, Jun 11, 2024 at 10:41 AM Jiri Konecny <jkonecny(a)redhat.com> wrote:
On 04. 06. 24 14:27, Neal Gompa wrote:
> On Tue, Jun 4, 2024 at 8:23 AM Jiri Konecny <jkonecny(a)redhat.com> wrote:
>>
>>
>> On 03. 06. 24 21:57, Jason L Tibbitts III wrote:
>>>>>>>> Aoife Moloney <amoloney(a)redhat.com> writes:
>>>> === VNC switch to RDP for remote GUI installations ===
>>> I'm curious how my usual install workflow will be affected by this
>>> change. I use the kickstart "vnc --connect" option extensively in
my
>>> workflow; I may have a bunch of installs running in parallel, and they
>>> just connect and display when they are ready. I use vinagre as the vnc
>>> client.
>>>
>>> It's not a huge thing; I could come up with another workflow but
that's
>>> the one I've used since before Fedora existed. The installs are fully
>>> automated and the display connection is only used so that I can see the
>>> progress and potentially interact with a machine if it encounters a
>>> problem. I guess in the worst case I could just do the install blind
>>> and ssh in if something takes too long.
>> Hi, the only change should be that you will change "vnc --connect"
with
>> the new API we will provide and also use RDP as your client instead of VNC.
>>
> Given that gnome-remote-desktop supports both VNC and RDP, can't VNC
> support still be wired up?
>
Hi, it is theoretically possible but we are not planning to do that
until there will be a reason for that. AFAIK it's not that simple change
to do that.
I think the reason is pretty obvious: there are many more high quality
VNC clients than there are RDP ones. And even ignoring that, the
existing Anaconda workflows for remote GUI expect VNC. There is no
technical limitation preventing us from having VNC support through
grd. In fact, one of the original reasons I wrote the Weston backend
for Anaconda was so that I could have VNC for Linux and web clients,
because the RDP clients are not very good in my experience.
--
真実はいつも一つ！/ Always, there's only one truth!
9:22 a.m.
New subject: F41 Change Proposal: Anaconda as native Wayland application
(System Wide)
On 11. 06. 24 11:53, Neal Gompa wrote:
On Tue, Jun 11, 2024 at 10:41 AM Jiri
Konecny<jkonecny(a)redhat.com> wrote:
> On 04. 06. 24 14:27, Neal Gompa wrote:
>> On Tue, Jun 4, 2024 at 8:23 AM Jiri Konecny<jkonecny(a)redhat.com> wrote:
>>>
>>> On 03. 06. 24 21:57, Jason L Tibbitts III wrote:
>>>>>>>>> Aoife Moloney<amoloney(a)redhat.com> writes:
>>>>> === VNC switch to RDP for remote GUI installations ===
>>>> I'm curious how my usual install workflow will be affected by this
>>>> change. I use the kickstart "vnc --connect" option extensively
in my
>>>> workflow; I may have a bunch of installs running in parallel, and they
>>>> just connect and display when they are ready. I use vinagre as the vnc
>>>> client.
>>>>
>>>> It's not a huge thing; I could come up with another workflow but
that's
>>>> the one I've used since before Fedora existed. The installs are
fully
>>>> automated and the display connection is only used so that I can see the
>>>> progress and potentially interact with a machine if it encounters a
>>>> problem. I guess in the worst case I could just do the install blind
>>>> and ssh in if something takes too long.
>>> Hi, the only change should be that you will change "vnc --connect"
with
>>> the new API we will provide and also use RDP as your client instead of VNC.
>>>
>> Given that gnome-remote-desktop supports both VNC and RDP, can't VNC
>> support still be wired up?
>>
> Hi, it is theoretically possible but we are not planning to do that
> until there will be a reason for that. AFAIK it's not that simple change
> to do that.
>
I think the reason is pretty obvious: there are many more high quality
VNC clients than there are RDP ones. And even ignoring that, the
existing Anaconda workflows for remote GUI expect VNC. There is no
technical limitation preventing us from having VNC support through
grd. In fact, one of the original reasons I wrote the Weston backend
for Anaconda was so that I could have VNC for Linux and web clients,
because the RDP clients are not very good in my experience.
In any case, I would see this more like a future improvement if we agree
to go this way. I would like to simplify things for now, it's already a
big change.
Anyway, Jonas, could you please share your recommendation here as owner
of grd? Do you think that VNC should be enabled in grd?
Best Regards,
Jirka
10:02 a.m.
New subject: F41 Change Proposal: Anaconda as native Wayland application
(System Wide)
On Tue, Jun 11, 2024 at 4:22 PM Jiri Konecny <jkonecny(a)redhat.com> wrote:
On 11. 06. 24 11:53, Neal Gompa wrote:
On Tue, Jun 11, 2024 at 10:41 AM Jiri Konecny <jkonecny(a)redhat.com> wrote:
On 04. 06. 24 14:27, Neal Gompa wrote:
On Tue, Jun 4, 2024 at 8:23 AM Jiri Konecny <jkonecny(a)redhat.com> wrote:
On 03. 06. 24 21:57, Jason L Tibbitts III wrote:
Aoife Moloney <amoloney(a)redhat.com> writes:
=== VNC switch to RDP for remote GUI installations ===
I'm curious how my usual install workflow will be affected by this
change. I use the kickstart "vnc --connect" option extensively in my
workflow; I may have a bunch of installs running in parallel, and they
just connect and display when they are ready. I use vinagre as the vnc
client.
It's not a huge thing; I could come up with another workflow but that's
the one I've used since before Fedora existed. The installs are fully
automated and the display connection is only used so that I can see the
progress and potentially interact with a machine if it encounters a
problem. I guess in the worst case I could just do the install blind
and ssh in if something takes too long.
Hi, the only change should be that you will change "vnc --connect" with
the new API we will provide and also use RDP as your client instead of VNC.
Given that gnome-remote-desktop supports both VNC and RDP, can't VNC
support still be wired up?
Hi, it is theoretically possible but we are not planning to do that
until there will be a reason for that. AFAIK it's not that simple change
to do that.
I think the reason is pretty obvious: there are many more high quality
VNC clients than there are RDP ones. And even ignoring that, the
existing Anaconda workflows for remote GUI expect VNC. There is no
technical limitation preventing us from having VNC support through
grd. In fact, one of the original reasons I wrote the Weston backend
for Anaconda was so that I could have VNC for Linux and web clients,
because the RDP clients are not very good in my experience.
In any case, I would see this more like a future improvement if we agree to go this way.
I would like to simplify things for now, it's already a big change.
As long as the mechanism to wire things up for inst.vnc to work isn't
deleted, then I think that's fine. It can be added after-the-fact and
maybe even still land for F41.
--
真実はいつも一つ！/ Always, there's only one truth!
3:06 a.m.
New subject: F41 Change Proposal: Anaconda as native Wayland application
(System Wide)
On Tue, Jun 11, 2024 at 04:22:24PM +0200, Jiri Konecny wrote:
On 11. 06. 24 11:53, Neal Gompa wrote:
> On Tue, Jun 11, 2024 at 10:41 AM Jiri Konecny<jkonecny(a)redhat.com> wrote:
> > On 04. 06. 24 14:27, Neal Gompa wrote:
> > > On Tue, Jun 4, 2024 at 8:23 AM Jiri Konecny<jkonecny(a)redhat.com>
wrote:
> > > >
> > > > On 03. 06. 24 21:57, Jason L Tibbitts III wrote:
> > > > > > > > > > Aoife
Moloney<amoloney(a)redhat.com> writes:
> > > > > > === VNC switch to RDP for remote GUI installations ===
> > > > > I'm curious how my usual install workflow will be affected
by this
> > > > > change. I use the kickstart "vnc --connect" option
extensively in my
> > > > > workflow; I may have a bunch of installs running in parallel,
and they
> > > > > just connect and display when they are ready. I use vinagre as
the vnc
> > > > > client.
> > > > >
> > > > > It's not a huge thing; I could come up with another workflow
but that's
> > > > > the one I've used since before Fedora existed. The installs
are fully
> > > > > automated and the display connection is only used so that I can
see the
> > > > > progress and potentially interact with a machine if it
encounters a
> > > > > problem. I guess in the worst case I could just do the install
blind
> > > > > and ssh in if something takes too long.
> > > > Hi, the only change should be that you will change "vnc
--connect" with
> > > > the new API we will provide and also use RDP as your client instead
of VNC.
> > > >
> > > Given that gnome-remote-desktop supports both VNC and RDP, can't VNC
> > > support still be wired up?
> > >
> > Hi, it is theoretically possible but we are not planning to do that
> > until there will be a reason for that. AFAIK it's not that simple change
> > to do that.
> >
> I think the reason is pretty obvious: there are many more high quality
> VNC clients than there are RDP ones. And even ignoring that, the
> existing Anaconda workflows for remote GUI expect VNC. There is no
> technical limitation preventing us from having VNC support through
> grd. In fact, one of the original reasons I wrote the Weston backend
> for Anaconda was so that I could have VNC for Linux and web clients,
> because the RDP clients are not very good in my experience.
>
In any case, I would see this more like a future improvement if we agree to
go this way. I would like to simplify things for now, it's already a big
change.
Anyway, Jonas, could you please share your recommendation here as owner of
grd? Do you think that VNC should be enabled in grd?
Currently in upstream grd VNC support is implemented using LibVNCServer,
and completely lacks any way of encryption. Other than that, there are
awkward limitations of password lengths that may be present, depending
on various factors. All in all, it's awful for security.
There are three things that would make me comfortable recommending making
VNC an option:
* Changing implementation to use neatvnc instead of LibVNCServer. The
impression I have is that this VNC implementation has a bit higher
code quality compared to LibVNCServer.
* Implement TLS key/cert based encryption and require that by default,
while dropping the anontls support we have downstream in Fedora.
* Remove the "prompt" authorization method from grd.
Other than that, a probably unenforcable thing would be to not allow it
being exposed to the wider Internet.
Jonas
Best Regards,
Jirka
12:08 p.m.
New subject: F41 Change Proposal: Anaconda as native Wayland application
(System Wide)
>>>> Jiri Konecny <jkonecny(a)redhat.com> writes:
Hi, the only change should be that you will change "vnc
--connect"
with the new API we will provide and also use RDP as your client
instead of VNC.
Thanks. I don't particularly care about VNC itself; I just wanted to
make sure that it was known that someone does use "--connect" to do a
"client-initiated" display connection.
Off topic, I know, but what I really wish existed was some kind of
deployment console. Early in the kickstart process, the machine being
installed would contact a server, pass hardware info and wait. The
server would pass back the rest of the kickstart file (after potentially
getting admin input) and the installation would continue. Output would
be logged in a way that the server can present to the admin, and
potentially the graphical (or perhaps the text) UI could be passed
through.
Years ago I had hacked something implementing a little of this which
just worked in %pre but it ended up being less useful than the system I
use now. And really, I don't think that deployments like mine (maybe a
couple hundred machines) are very common so there's probably no point.
But it's an interesting problem to think about.
- J<
3:05 a.m.
New subject: F41 Change Proposal: Anaconda as native Wayland application
(System Wide)
On Tue, Jun 04, 2024 at 12:08:45PM -0500, Jason L Tibbitts III wrote:
>>>>> Jiri Konecny <jkonecny(a)redhat.com>
writes:
> Hi, the only change should be that you will change "vnc --connect"
> with the new API we will provide and also use RDP as your client
> instead of VNC.
Thanks. I don't particularly care about VNC itself; I just wanted to
make sure that it was known that someone does use "--connect" to do a
"client-initiated" display connection.
Off topic, I know, but what I really wish existed was some kind of
deployment console. Early in the kickstart process, the machine being
installed would contact a server, pass hardware info and wait. The
server would pass back the rest of the kickstart file (after potentially
getting admin input) and the installation would continue. Output would
be logged in a way that the server can present to the admin, and
potentially the graphical (or perhaps the text) UI could be passed
through.
This is similar to what The Foreman does I think?
https://www.theforeman.org/introduction.html
There are various other things in the same world such as:
https://docs.openstack.org/ironic/latest/
Rich.
Years ago I had hacked something implementing a little of this which
just worked in %pre but it ended up being less useful than the system I
use now. And really, I don't think that deployments like mine (maybe a
couple hundred machines) are very common so there's probably no point.
But it's an interesting problem to think about.
- J<
--
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
4:20 a.m.
New subject: F41 Change Proposal: Anaconda as native Wayland application
(System Wide)
On 05. 06. 24 10:05, Richard W.M. Jones wrote:
On Tue, Jun 04, 2024 at 12:08:45PM -0500, Jason L Tibbitts III
wrote:
>>>>>> Jiri Konecny <jkonecny(a)redhat.com> writes:
>> Hi, the only change should be that you will change "vnc --connect"
>> with the new API we will provide and also use RDP as your client
>> instead of VNC.
> Thanks. I don't particularly care about VNC itself; I just wanted to
> make sure that it was known that someone does use "--connect" to do a
> "client-initiated" display connection.
>
> Off topic, I know, but what I really wish existed was some kind of
> deployment console. Early in the kickstart process, the machine being
> installed would contact a server, pass hardware info and wait. The
> server would pass back the rest of the kickstart file (after potentially
> getting admin input) and the installation would continue. Output would
> be logged in a way that the server can present to the admin, and
> potentially the graphical (or perhaps the text) UI could be passed
> through.
This is similar to what The Foreman does I think?
https://www.theforeman.org/introduction.html
There are various other things in the same world such as:
https://docs.openstack.org/ironic/latest/
Rich.
IIRC Foreman is doing this by not optimal way currently and they asked
us some time ago about using %pre section as you said. Not sure what
happened then.
Anyway, the pre section should be fine to use for this in Anaconda.
Also a question, is kickstart command for RDP requirement for you? Or is
inst.rdp (replacement of inst.vnc) enough to work with?
We are trying to find out if we can drop the kickstart command.
Best Regards,
Jirka
> Years ago I had hacked something implementing a little of this which
> just worked in %pre but it ended up being less useful than the system I
> use now. And really, I don't think that deployments like mine (maybe a
> couple hundred machines) are very common so there's probably no point.
> But it's an interesting problem to think about.
>
> - J<
> --
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
12:21 p.m.
New subject: F41 Change Proposal: Anaconda as native Wayland application
(System Wide)
>>>> Jiri Konecny <jkonecny(a)redhat.com> writes:
Also a question, is kickstart command for RDP requirement for you?
Or
is inst.rdp (replacement of inst.vnc) enough to work with? We are
trying to find out if we can drop the kickstart command.
I don't particularly care about how the functionality gets activated; in
my case it's not something that would need to come in though the
kickstart file. However, I could see situations where it would be
useful to have that specified in the kickstart file, such as a
hypothetical deployment system. It might, for example, want to direct
anaconda to send the display to an appropriate place that could be
proxied or recorded. That location might be complicated or variable and
not necessarily something that could be baked into the boot media or
typed in at boot time.
- J<
6:25 a.m.
New subject: F41 Change Proposal: Anaconda as native Wayland application
(System Wide)
On Tue, 2024-06-04 at 12:08 -0500, Jason L Tibbitts III wrote:
> > > > > Jiri Konecny <jkonecny(a)redhat.com>
writes:
> Hi, the only change should be that you will change "vnc --connect"
> with the new API we will provide and also use RDP as your client
> instead of VNC.
Thanks. I don't particularly care about VNC itself; I just wanted to
make sure that it was known that someone does use "--connect" to do a
"client-initiated" display connection.
Off topic, I know, but what I really wish existed was some kind of
deployment console. Early in the kickstart process, the machine
being
installed would contact a server, pass hardware info and wait.
I think we already
send some (configurable) identifier when talking to
DHCP [0], which could be used to forward a matching kickstart to the
machine. I'm not sure but we might even do something similar in the
call trying to fetch the kickstart over network ?
[0] https://anaconda-installer.readthedocs.io/en/latest/boot-options.html#inst-dhcpclass
Not the same thing you suggest, but close. And of course I guess one
could generate specific images with Image Builder with the right
kickstart baked in.
The
server would pass back the rest of the kickstart file (after
potentially
getting admin input) and the installation would continue. Output
would
be logged in a way that the server can present to the admin, and
potentially the graphical (or perhaps the text) UI could be passed
through.
Years ago I had hacked something implementing a little of this which
just worked in %pre but it ended up being less useful than the system
I
use now. And really, I don't think that deployments like mine (maybe
a
couple hundred machines) are very common so there's probably no
point.
But it's an interesting problem to think about.
- J<
--
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
1:02 p.m.
New subject: F41 Change Proposal: Anaconda as native Wayland application
(System Wide)
On Tue, 2024-06-04 at 14:22 +0200, Jiri Konecny wrote:
On 03. 06. 24 21:57, Jason L Tibbitts III wrote:
> > > > > > Aoife Moloney <amoloney(a)redhat.com> writes:
> > === VNC switch to RDP for remote GUI installations ===
> I'm curious how my usual install workflow will be affected by this
> change. I use the kickstart "vnc --connect" option extensively in my
> workflow; I may have a bunch of installs running in parallel, and they
> just connect and display when they are ready. I use vinagre as the vnc
> client.
>
> It's not a huge thing; I could come up with another workflow but that's
> the one I've used since before Fedora existed. The installs are fully
> automated and the display connection is only used so that I can see the
> progress and potentially interact with a machine if it encounters a
> problem. I guess in the worst case I could just do the install blind
> and ssh in if something takes too long.
Hi, the only change should be that you will change "vnc
--connect" with
the new API we will provide and also use RDP as your client instead of VNC.
Does RDP support this kind of "reverse connection" mode that VNC has?
https://serverfault.com/questions/1100655/is-it-possible-to-make-a-revers...
says not, which seems like a significant loss of functionality.
The point of the `vnc --connect` mechanism anaconda currently has is to
allow remote installs to a heavily-firewalled system, by having that
system connect *out* to a server running on the system from which you
will run the install, instead of the other way around.
--
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @adamw(a)fosstodon.org
https://www.happyassassin.net
6:19 a.m.
New subject: F41 Change Proposal: Anaconda as native Wayland application
(System Wide)
On Tue, 2024-06-04 at 11:02 -0700, Adam Williamson wrote:
On Tue, 2024-06-04 at 14:22 +0200, Jiri Konecny wrote:
>
> On 03. 06. 24 21:57, Jason L Tibbitts III wrote:
> > > > > > > Aoife Moloney <amoloney(a)redhat.com> writes:
> > > === VNC switch to RDP for remote GUI installations ===
> > I'm curious how my usual install workflow will be affected by
> > this
> > change. I use the kickstart "vnc --connect" option extensively
> > in my
> > workflow; I may have a bunch of installs running in parallel, and
> > they
> > just connect and display when they are ready. I use vinagre as
> > the vnc
> > client.
> >
> > It's not a huge thing; I could come up with another workflow but
> > that's
> > the one I've used since before Fedora existed. The installs are
> > fully
> > automated and the display connection is only used so that I can
> > see the
> > progress and potentially interact with a machine if it encounters
> > a
> > problem. I guess in the worst case I could just do the install
> > blind
> > and ssh in if something takes too long.
> Hi, the only change should be that you will change "vnc --connect"
> with
> the new API we will provide and also use RDP as your client instead
> of VNC.
Does RDP support this kind of "reverse connection" mode that VNC has?
https://serverfault.com/questions/1100655/is-it-possible-to-make-a-revers...
says not, which seems like a significant loss of functionality.
Yeah, I don't
think this is really a thing in the RDP world as far as I
can tell.
Also, we are using GNOME remote desktop to provide the RDP access & its
remote desktop control tool (grdctl) does not seem to provide a way to
configure something like that:
https://www.mankier.com/1/grdctl
For the record, it does not seem to support the VNC connect mode as as
well.
I'm also not sure how well is VNC actually supported in GNOME remote
desktop, as IIRC it is not even exposed as an option in modern Fedora
Workstation options page - only RDP can be configured from there.
The point of the `vnc --connect` mechanism anaconda currently has is
to
allow remote installs to a heavily-firewalled system, by having that
system connect *out* to a server running on the system from which you
will run the install, instead of the other way around.
--
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @adamw(a)fosstodon.org
https://www.happyassassin.net
--
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
10:31 a.m.
New subject: F41 Change Proposal: Anaconda as native Wayland application
(System Wide)
On Fri, 2024-06-07 at 13:19 +0200, mkolman(a)redhat.com wrote:
>
> Does RDP support this kind of "reverse connection" mode that VNC has?
>
https://serverfault.com/questions/1100655/is-it-possible-to-make-a-revers...
> says not, which seems like a significant loss of functionality.
Yeah, I don't think this is really a thing in the RDP world as far as I
can tell.
Also, we are using GNOME remote desktop to provide the RDP access & its
remote desktop control tool (grdctl) does not seem to provide a way to
configure something like that:
https://www.mankier.com/1/grdctl
For the record, it does not seem to support the VNC connect mode as as
well.
I'm also not sure how well is VNC actually supported in GNOME remote
desktop, as IIRC it is not even exposed as an option in modern Fedora
Workstation options page - only RDP can be configured from there.
Well, all you need is any VNC app, and there are lots of those. For the
openQA tests we use vinagre for the regular client test and tigervnc
for the reverse connection test. GNOME Connections supports regular
VNC, I just didn't get around to changing that test to use it yet.
--
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @adamw(a)fosstodon.org
https://www.happyassassin.net
3:05 p.m.
New subject: F41 Change Proposal: Anaconda as native Wayland application
(System Wide)
On Fri, Jun 7, 2024 at 8:32 AM Adam Williamson
<adamwill(a)fedoraproject.org> wrote:
On Fri, 2024-06-07 at 13:19 +0200, mkolman(a)redhat.com wrote:
> >
> > Does RDP support this kind of "reverse connection" mode that VNC
has?
> >
https://serverfault.com/questions/1100655/is-it-possible-to-make-a-revers...
> > says not, which seems like a significant loss of functionality.
> Yeah, I don't think this is really a thing in the RDP world as far as I
> can tell.
>
> Also, we are using GNOME remote desktop to provide the RDP access & its
> remote desktop control tool (grdctl) does not seem to provide a way to
> configure something like that:
>
> https://www.mankier.com/1/grdctl
>
> For the record, it does not seem to support the VNC connect mode as as
> well.
>
> I'm also not sure how well is VNC actually supported in GNOME remote
> desktop, as IIRC it is not even exposed as an option in modern Fedora
> Workstation options page - only RDP can be configured from there.
Well, all you need is any VNC app, and there are lots of those. For the
openQA tests we use vinagre for the regular client test and tigervnc
for the reverse connection test. GNOME Connections supports regular
VNC, I just didn't get around to changing that test to use it yet.
Note that gnome-remote-desktop supports VNC. It can be configured
using the grdctl commandline tool.
--
真実はいつも一つ！/ Always, there's only one truth!
10
days inactive
24
days old
40 comments
17 participants
participants (17)
-
Adam Williamson -
Aoife Moloney -
Barry -
Daniel P. Berrangé -
Hans de Goede -
Ian Laurie -
Jason L Tibbitts III -
Jiri Konecny -
Jonas Ådahl -
Leon Fauster -
Leslie Satenstein -
Marc Deop i Argemí -
Michael J Gruber -
mkolman＠redhat.com -
Neal Gompa -
Richard W.M. Jones -
Sérgio Basto