• 0 Posts
  • 11 Comments
Joined 2 years ago
cake
Cake day: June 19th, 2023

help-circle
  • It depends:

    The traditional DEs (KDE, Gnome and Cinnamon) already have their own screensavers.

    The newer ones have coalesced around an extension to wayland called “ext-session-lock-v1”:

    This protocol allows for a privileged Wayland client to lock the session and display arbitrary graphics while the session is locked.

    You can see support for it here: https://wayland.app/protocols/ext-session-lock-v1#compositor-support

    It’s on basically all the new ones except where it doesn’t make sense, such as:

    • Gamescope (designed to keep a game fullscreen at all times)
    • Cage (for kiosk machines, basically gamescope but for interactive maps in shopping malls)
    • Weston (the reference wayland compositor which should have protocols that everything uses, I’m not sure how useful it would be to add screensaver support to the reference implementation then have it popping up on in-car-displays when you’re trying to follow a map while driving)

    Everyone who needs it has it already.

    There will probably be an ext-session-lock-v2 and get pulled into the traditional DEs at some point, but probably after a whole bunch of getting everyone around the table and in agreement on some security questions: how do we prevent malicious software setting themselves as a screensaver for a screenjacking attack?, what happens when the screensaver crashes?, that kind of stuff…




  • I think some of the downvotes might be annoyance at not knowing what servo is.

    Everyone in the web and rust communities would know that it is the original rust application that the rust language was made to create: a new web browser built with memory safety and safe parallel execution as first concerns.

    Parts of it ended up in Firefox then servo died when Mozilla fired a whole swath of their own devs.

    It was stuck in limbo for a few years but has seen a revival under Igalia who have a history of fixing bugs and supporting/adding features to the existing browsers which the big players don’t have the resources or the will to work on.


    I do think every project needs a non-marketing-speak description of what it does on every major page that a user might visit (e.g. Homepage, project readme, releases/downloads page), but I wouldn’t really call version 0.0.1 a proper release.






  • Gotos being bad falls in the it depends category.

    Bad:

    • When you think you’re going to do something clever (when you should probably be reaching for a different tool that you may or may not know exists)

    Good:

    • When in the form of a jump that’s was written by a sound compiler
    • When learning how assembly works
    • When working on codecs and you’re actually going to spend the many hours to get everything right.
    • Labelled breaks in nested for loops
    • Embedded systems when resources are constrained
    • When writing debuggers
    • When writing anti-cheat systems
    • And finally, when you actually need to because you’re manually managing things (e.g. you’re writing a kernel)


  • I’m more interested in what the Oil shell has been doing, it has a higher potential roof while keeping backwards compatibility rather than the current standard of affairs 10ish year development cycle of a new shell with slight improvements.

    Switching shells can be a massive pain in the ass, so if we’re making a change, it has to be worth it.

    Oil looks like it could be worth it and then some.