Oh No! Parent Control · GNOME comparison
Oh No! vs GNOME Parental Controls
Choose Oh No! for broader Linux app rules, versioned AppImage matching, and combined homework/game approvals. Its additional native enforcement and running-app handling go beyond the reviewed official GNOME GUI.
Comparison based on malcontent-control 0.14.0 and the published Oh No! Parent Control release sources.
Reviewed GNOME controls · Reviewed Oh No! release
| Capability | GNOME Parental Controls app | Oh No! Parent Control |
|---|---|---|
| Individual app catalogue | Flatpak and explicitly opted-in applications in the upstream selector. | Broader supported native, Snap, Flatpak and AppImage catalogue, discovered for the selected child. |
| AppImage filename-pattern editor | Not provided by the reviewed official GUI. | Suggested, editable same-folder filename patterns for supported AppImages; reset to default. |
| App access states | Binary application restriction. | Always Allowed, Soft Blocked and Hard Blocked. |
| Approve time and conditional app access together | Extra screen time is available; no combined soft-app choice in the reviewed official GUI. | Approve homework-only time or include all soft-blocked apps, while retaining hard launch blocks. |
| Additional native execution enforcement | The reviewed frontend uses the standard desktop filtering integrations; it provides no equivalent added fapolicyd policy. | Per-child fapolicyd policy for supported native targets, including usual file-manager and command launch routes. |
| Close matching running apps on relevant changes | No equivalent control provided by the reviewed official GUI. | Relevant restrictive changes close matching apps across the selected child’s sessions; other users’ apps stay open. |
| Revoke approved time and app access | No equivalent combined revocation control provided by the reviewed official GUI. | Revoke the one-time grant and temporary app access; unused daily time remains. |
| Dedicated request station before sign-in | No equivalent request-only product session provided by the reviewed official GUI. | Restricted request station before sign-in or after lockout, alongside child-panel requests. |
| Zero daily minutes / approval-only mode | The reviewed daily-limit editor has a one-minute minimum. | Explicit zero-minute allowance: computer access requires an active approval. |
| Daily limits and extra-time extension | Available, including screen locking at the limit. | Available, with a panel countdown and combined app-access choices. |
| Bedtime, usage history, OARS suitability and installation controls | Available in the official app. | No equivalent controls exposed in the current Parent App. |
| Website filtering controls | Not provided by the GNOME 50 frontend; its release notes describe that user interface as future work. | Website content filtering is not provided. |
When Oh No! is the stronger choice
For a family on Linux that needs Lunar Client / AppImage rules, supported native app enforcement, homework-only approvals, optional game access, and revocation, Oh No! offers a substantially richer set of app controls than the reviewed official GUI. Its strength is the combination: match the app, choose its access rule, and approve time with the right app access.
The official GUI also offers bedtime, usage history, age suitability, and installation controls that Oh No!’s Parent App does not expose. Choose according to the controls your family needs. Local accounts, offline operation, and system authentication are shared foundations rather than exclusive Oh No! advantages.
Install Instructions →Shared GNOME foundation, additional desktop enforcement
Oh No! uses AccountsService and Malcontent for account policy and time infrastructure, GNOME Shell for desktop controls, PAM for sign-in/unlock checks, and Polkit for parent authentication. It adds its broker, native fapolicyd rules, running-app handling, and restricted request station. GNOME’s Settings link and software-store filtering are separate forms of integration; they do not establish stronger execution enforcement.
Malcontent’s installed-app blocklist and OARS suitability filter are different policies. The statement that already-installed apps are unaffected applies to the OARS installation-rating filter, not the installed-app blocklist. malcontent-client is part of the shared backend ecosystem, not a GUI-exclusive feature or a documented Oh No!-specific scripting interface.
Coverage and timing limits
- App Limits controls access and target matching, not per-app time budgets. A soft-app-inclusive approval allows all soft-blocked apps, not one selected game.
- AppImage patterns use * and ? in the filename within the same canonical directory. A folder move, renamed copy, shared-interpreter script, unsupported wrapper, or ambiguous updater needs its own coverage decision. A suggested pattern can reappear for some apps despite a saved precise choice; check the match shown after reopening App Limits.
- Native execution rules cover supported targets. If a rule cannot be represented, the app reports the affected rule; an omitted rule can leave that app or updated version unrestricted. Compilation and reload notification alone do not prove every active policy or every launch route.
- New blocks, soft-to-hard changes, homework-only approvals, and revocation have relevant running-app effects. Approving soft-app access keeps hard launch blocks but does not close an already-open hard-blocked app.
- If daily time remains, natural grant expiry alone does not immediately restore soft-app blocks. Session-entry reconciliation or another restoring action applies them. Zero usable time locks the screen; locking does not pause games or save work.
- Usable time is the larger of daily time remaining and grant time remaining. Grants count elapsed time and do not pause while locked or away. No website filtering, remote cloud dashboard, or other-device control is provided.