I wanted to share this with you and if you point me in the right
direction under what section
to add something like this in the wiki I will do so!
After running my system a while it continued to slow down and at some point
it was so extreme that a simple copy operation would render the mouse unmovable.
Note that this is an i7, 8G Ram, SSD etc.
Changing to BFQ schedule, tune BFQ parameters, disabling swapping,
compiling the kernel with the Muqss scheduler, nothing did help. It is
not a hardware issue!
It seems by default fstrim is disabled from systemd and by default
nothing formats it with discard option.
Running fstrim / && fstrim /home && systemctl enable fstrim.service
changed the performance a dozen fold.
See below for the minutes from yesterday's Fedora Workstation Working
Fedora Workstation Working Group: Meeting Minutes
- Present: Allan, Chris, Jens, Matthias, Neal (arrived late)
- Regrets: Christian, Langdon, Kalev, Owen
- Missing: Michael
F32 planning (#115)
- Allan: is the WG the right place to do feature planning? Matthias:
we can potentially get assistance from the desktop team if we identify
- Chris: would like to see us close down issues that are in progress.
- #116 - Broadcom wireless - it's relatively self-contained.
- #101 - Impossible to see disk usage - perhaps a limited fix for
this one. Outstanding disk partitioning questions are relevant here
(#54 and #82):
- Chris is reluctant to make big changes around disk
partitioning, from a QA perspective
- Matthias: isn't sure what the options are - might be hard to
move away from LVM
- Allan: it would be good to focus on the disk partitioning and
encryption questions for F32, since these are somewhat foundational
questions which impact other areas. When we do this, it would be good
to get consensus over key questions (LVM or no LVM) and a sense of the
direction of travel.
- Matthias: with systemd-homed coming up and promising real
change, making short-term changes might not be worthwhile.
- Allan: seems like we have two potential themes coming out - one is
trying to smooth out the more obvious pain points, the other is trying
to resolve more wider architectural decisions.
- Matthias: what is happening outside the workstation for F32?
- Memory monitoring was happening - #98
- Chris: is low-memory monitor ready for F32? Matthias: the
plumbing is getting into place for F32 (in glib and portals).
- There would need to be an effort to get apps and to adopt the
low memory monitor.
- This could be a useful initiative for the WG to track and push for F32.
- Christian Hergert has been doing some interesting work that we
could draw on for this, too.
- Neal raises the question of F31 being perceived to be slower than
F30. General discussion about performance but no concrete takeaways.
- Neal raises #117 - drop optical media criterion
- General view in the discussion is that Fedora should distribute
USB sticks rather than optical disks (for marketing)
- Concern that the desktop experience isn't good on a DVD
- Sounds like the WG should come back to this, with more data
about the various hardware and use-cases, in order to state a position
on the issue
- WG stewardship of the F32 release
- Testing and test days - it would be good to revisit the schedule
and see if there's anything the WG can do to improve things or engage
- Release notes and marketing that we can push
- It's fine to talk about what's included from GNOME. But what else?
- The features we've talked about are potentially release notes
worthy - we ought to have a list of target features that the WG can
deliver for F32.
- Another thing to do for F32: review the apps that are included
for the release. Some of them might not be up to scratch. Our apps
should work, serve a purpose, look good. We should schedule an app
review as part of the release process, maybe just after beta. We
should put this on our own calendar.
Next meeting will be 6 January 2020.
See below for the minutes from today's Workstation WG meeting.
Switch from Pagure to Taiga - https://pagure.io/fedora-workstation/issue/112
- Neal likes the kanban board. The discussions on Taiga aren't great
- Neal: there's a Pagure/Taiga extension, so you can have a board in Taiga
and still have discussions in Pagure.
- Matthias is not in favour of syncing between two tools
- Langdon - issue trackers aren't really intended for discussion. He has
struggled with discussion on Taiga in the past. Considers Pagure being good
at issue handling to be a "trap," prefers discussion in meetings.
- Neal thinks having Pagure to allow reporting issues to the working group
is nice. Doesn't want to host discussions on Taiga.
- Langdon suggests using both tools, Taiga for kanban and Pagure for
external parties to report issues, and not syncing them. Taiga better for
assigning issues as work.
- Allan thinks Pagure is not nice for discussions, either.
- Neal: GitLab's kanban is not good. Pagure is a better external reporting
tool. Taiga is better for internal organization.
- Chris: no strong opinion.
- Kalev: most of Fedora uses Pagure, switching to something else will
cause difficulty for other Fedora members used to Pagure.
- Allan: but aren't other teams migrating to Taiga?
- Langdon: Council wants to surface to the public what activity is
occuring in different projects. Taiga makes this easy. But Pagure works
better for FESCo, which is not a working body, it just approves issues.
Hence it doesn't need the kanban. This is why some Fedora teams are slowly
moving to Taiga but others are not. Workstation WG should pick whichever
tool works better for it; there is no mass migration in progress.
- Allan senses hesitation to move away from Pagure. Proposes vote. Option
one is complete migration to Taiga. Option two is to enable Taiga extension
- Michael suggests enabling Pagure's Taiga extension would be low-cost;
people who don't like Taiga don't need to look at it.
- Matthias: whether this works depends on whether the chair we select
likes to use it.
- Langdon: we can do a pilot/trial
- VOTE 1: try Taiga for a while in addition to Pagure.
- +1 Allan, +1 Michael +1 Neal, +1 Chris, +1 Jens, -1 Matthias, -1 Kalev,
Abstain: Langdon, Result: (+5,1,-2)
- VOTE 2: pilot Taiga for a while, without Pagure.
- +1 Allan, -1 Michael -1 Neal, +1 Matthias, -1 Kalev, -1 Jens, -1 Chris,
Abstain: Langon, Result: (+2,1,-5)
- Approved: try Taiga alongside Pagure
- Action: Langdon to find out how to set up Taiga
- Done: https://teams.fedoraproject.org/project/workstation-wg/timeline
Appoint a permanent chair(s) -
- Discussion: should we have a chair and vice-chair, or two equal
- Chris likes co-chair model. Also suggests having individual chair and
vice-chair assigned to WG subgroups, like the encryption subgroup.
- Michael and Neal also support separate chair and vice-chair.
- Discussion: should we have appointed positions, or a rotation?
- Langdon just doesn't want the same person in charge for a long time,
but doesn't think a rotation system is necessary for that.
- Consensus: appointed (elected) chair and vice-chair, terms coinciding
with Fedora release cycle.
- Suggestion: collect volunteers this week and appoint in the next meeting
I would like to propose a RFE for Fedora Workstation. I think what Fedora
Workstation, or GNOME in general, really misses is some support for tray
icons. There are many applications that do not work properly when having no
tray icon. Nowadays, tray icons are mostly implemented using an
AppIndicator standard made by Canonical and supported in GNOME using the
"KStatusNotifierItem/AppIndicator Support" Shell Extension also made by
Canonical and packaged in Fedora as gnome-shell-extension-appindicator.
This extension is preinstalled out-of-box in Ubuntu. In KDE, AppIndicators
are supported out-of-box.
Is there a place I could send a RFE to add the
gnome-shell-extension-appindicator package to base Fedora Workstation
installation or is this e-mail sufficient? No out-of-box support for tray
icons is a big minus for Fedora in my opinion.
Gist is tpm2-abrmd expects to find a TPM2, since it doesn't, it fails
ungracefully and restarts every 5s, thus spamming the journal.
How can I find out how this package ended up in the default package
set? When I try to remove it, it takes nothing else with it, so I
don't know why it's on the install media.
The confusion begins with Fedora-Workstation-Live-x86_64-31-1.9.iso,