My experiences with screen locking on Linux over time, using various machines:
* The screen doesn't lock, and remains on while the lid is closed.
* The screen doesn't lock, but does turn off when the lid is closed.
* The screen locks, but the machine doesn't suspend when the lid is closed.
* The screen doesn't turn on after the lid is opened. Key commands work, though.
* The screen turns on after the lid is opened, but is blank (no unlock requestor).
* The machine doesn't resume from suspend, requiring a hard reset.
* The screen locker gets completely bypassed and you're dumped into the desktop (possibly a fresh desktop because the entire environment crashed and restarted).
Throw remote desktop into the mix and you're in for a world of hurt.
I just disable screen locking, and make suspend a manual operation to keep my sanity intact. The trackpad still stops responding sometimes though...
Oddly enough, I don’t have any of those issues anymore. Screen locking tends to just work these days.
What doesn’t work well anymore is user switching: when I switch virtual consoles to either another user or the gdm screen the keyboard stops registering and the mouse gets slower and slower until it stops completely. Then some time later it starts responding again. The length of time it is unresponsive seems to be proportional to the length of time the virtual console has been suspended. The system continues to be available via SSH. I suspect that the issue has something to do with a huge backlog of invalid events being delivered, but I don’t know for sure. It may also somehow have something to do with the NVIDIA proprietary drivers. I kinda blame dbus/systemd, because it first started happening at the same time as I started using systemd, but I don’t actually know that.
It’s annoying because I’ve grown to rely on fast user switching over the past decade or more.
I use VT switching all the time, on a desktop with an nvidia card and a laptop with intel / nvidia, and I don't have any of your issues. I'm on arch linux so with recent kernels, systemd, etc... if that can help but I don't remember ever having them..
Interesting. The only issue I've encountered regarding screen locking was that in the past the desktop would be visible for a split second after opening the laptop lid and before the screenlock is displayed. Haven't seen that behaviour in couple years, I think. I use latest Ubuntu at home and latest Ubuntu LTS at work. Typically Lenovo and HP laptops, some Asus Zenbooks also in the past.
This is better viewed as a sequencing thing that is easy to get wrong, whatever the operating system. I recall a similar thing on Windows, a couple of decades ago, fixed/reduced to much fanfare if memory serves correctly.
Is it really unrelated? I dunno, maybe my distaste for certain development styles is leading me to see things that aren't there, but I fell like the Linux Desktop hacked-together "it's good enough for me" way of doing things is creeping into paid OSs like Mac and Windows.
"The desktop" is suffering from the same complexity breakdown that AAA gaming suffers from. It's hard -- and getting harder -- to produce a cohesive properly developed and QA'd AAA game because gamers now expect something way beyond the capabilities of a surgical team of 10-50 people. To even ship a AAA title requires a team of hundreds and a budget of tens to hundreds of millions. and when you're dealing with an wndeavor that large, it's difficult to enforce quality and cohesiveness at every level throughout the development process.
Desktop environments are now reaching that threshold because users demand "modernity" and fanciness. They would be fantastically served by a desktop with the capabilities of Windows 9x, MacOS 7.x, or AmigaOS 3.x, but they demand much more than that, and the Windows and MacOS teams (and code bases!) have bloated in size to meet this demand.
These problems showed up much earlier in Linux because in order to release a desktop OS, you need someone exercising strict control over all aspects of the system from the kernel (and even lower than the kernel, like the hardware and firmware) all the way up to the shell, GUI toolkit, and other user-visible features. You need that leadership to define and prioritize work and even prioritize OS concerns. (For example, a desktop OS should handle keyboard/mouse interrupts IMMEDIATELY.) You need to enforce a single set of user concerns on everybody, and fire anyone who doesn't play ball. And with Linux and open source, good luck getting everybody on the independent kernel, libc, X, and GUI projects to cooperate this way.
Me, I've always been content with like fvwm95 (or lately, i3) and whatever independent programs I needed for desktop tasks. And if I have to say 'pm-suspend' at a command prompt to put my computer tk sleep, so be it. I can see the many hands all making the world a slightly better place, and since their work is all loosely coupled, it all sort of hangs together and is very robust. Conventional desktops are brittle to start with, and made even more so under Linux because of those issues I mentioned.
> Desktop environments are now reaching that threshold because users demand "modernity" and fanciness.
Do they? Do they really? Because I struggle to think of a change made in how I or anyone I know's desktop works that we actually think made things better. The last one I can think of was when Windows added start-typing-search to the start menu back in, what, 7?
I'm not dismissing that other people might be demanding some "modern"/"fancy" features, but if so what the heck are they? What I see is GUI redesign for the sake of it, or hiding of options in order to promote more "desired" (by the vendor) options.
I have had this start happening on Windows 10, except instead of a split second, it could be several seconds, during which I could even launch and start using applications, before it finally locks. To get around this risk, I always lock using Win+L now, before closing the lid.
* The lock screen pops up, requests a password, and disappears after you enter it, but you find that your password and enter key also made their way into the foreground text field.
Most of what you describe isn't the screen lock but sounds more like something isn't communicating system events properly. That or bad hardware with poor open source driver vendor support.
Also, this is why I don't use Linux any more. It's grown into a dumpster fire of ad-hoc patches from big corps looking to hammer every last drop of cloud server performance or poorly designed desktops made by people who obviously don't use them.
Plan 9 front is my daily driver with OpenBSD/FreeBSD if I need a Unix. Windows 7 still powers my gaming rig by it most likely will move to Linux because Steam. Probably the only reason I need Linux and Windows 7 still isn't enough of a reason to switch....
Those are orthogonal problems to plan 9. tl;dr all this runs in vmx(3), though it is still in its infancy and slow as molasses but working good enough to scrape by.
Emacs is a poor fit as it already is an OS. plan 9, an operating system which encourages programs to talk to each other, offers no advantages to a monolithic text editing operating system. You're better off learning sam or acme and learn how they interact with the platform which is where their power comes from. That's how you use plan 9, you work with it, harness it. It's a kind of "be one with the os" zen thing.
SBCL I have no experience with but my guess is all the tooling and libraries are built around a 50 year old operating system. Porting languages isn't that big a deal, we have a buch like ocaml, python, Go, pforth, and maybe hugs/haskell among others. The issues are libraries which assume some unholy assortment of unix/posix/linux/whatever bindings and dependencies. plus we have no c++ because few at bell labs thought much of it even though they spawned it. Tells you something.
Firefox. The big one. The modern web browser is a primitive document viewer from the 90's which borrowed ideas put forth some 25+ years earlier by Ted Nelson and others in the 1960's and demonstrated by Doug Englebert in the MOAD. Now it can run computer code while displaying video, audio, text and images on your already existing computer. In plan 9 we would use separate tools to accomplish these tasks. A web browser would at most need to render html, ccs and handle basic javascript. The more complex stuff like pdf, audio and video should be plumbed to external programs which can be removed or swapped out as needed.
I beg to differ. Emacs is an excellent text-based operating environment, simply the best, without peer. I’ve used sam & acme, and they don’t compare.
> SBCL I have no experience with but my guess is all the tooling and libraries are built around a 50 year old operating system.
Some of the hairiest bits of Lisp (e.g. the pathname abstraction) are due to the fact that it doesn’t assume Unix.
Regardless, while I would prefer to boot directly into some sort of 21st-century Lisp OS which takes a lot of great ideas from Plan 9, that doesn’t exist; Plan 9 does. And if I ever get the spare time I intend to port Emacs & SBCL. And hope someone else will port Firefox.
> Windows 7 still powers my gaming rig by it most likely will move to Linux because Steam.
There are some kinks to be worked out. I'm seeing the following scenario:
I have Ori and the Blind Forest installed through Steam on Ubuntu 18.04. Attempting to play it through the steam client causes a crash. Navigating to the install directory in a terminal and running the simple command `wine oriDE.exe` runs the game with zero apparent problems.
Of course Steam isn't using the local wine installation, but... still? The game works flawlessly with the absolute bare minimum of effort. What's Steam doing instead?
(I tried watching the startup process in the Steam console, but it appears to be committed to printing only uninformative messages.)
> or poorly designed desktops made by people who obviously don't use them.
Do you mean the design part or the coding part? From my limited experience desktops are made by contributors and volunteers work on whatever affects them the most or some might work on cool stuff. It is what it is, without someone with money hiring a large dev team and foucssing on user tickets it will never change. As a developer I prefer something customizable like KDE where I can fix a crash in an app if I hit it over a Windows like experience where important apps like the screen magnifier had hard coded shortcuts and you could not customize them.
Both. glibc... No. And without boring you with anecdote I can sum it up by saying: Linux DE's feel like cheap Windows XP or OSX knockoffs. What's worse is every DE and their forks have their own duplicate DE companion programs such as explorer and notepad clones. I liken them to a Potemkin village; well polished but once you start looking behind things...
If your complaint is that you dislike clones of Windows and Mac, then the combination of tiling window manager, shell, tmux, and vim/emacs is usable and provides an experience that is completely different from those other operating systems. That didn't go away on Linux. There is also plan9port too.
No, the problem is that people keep reinventing the wheel over and over again, instead of picking one app and improving it so that their efforts are cumulative.
Being able to recompile from source to change hardcoded values isn't actually any better in my opinion. Especially given how much of a pain it can be to get a build environment set up for many projects.
I know, but for me accessibility tools are a must, if needed I will compile, use wine or write my own because i need them.
But from my experience (with KDE at least) you can customize every keyboard shortcut with a GUI and I could submit patches for issues I found and fixed. If you use a distribution like Debian or ubuntu then installing the required development libraries and rebuilding a package is simple enough in most cases.
I understand why compiling sucks though and this is why I am considering to use Python for a program I want to make and open source despite the fact I dislike it's syntax.
You might want to look at something like GNOME Builder, which is designed to make it easy to contribute to existing projects and will clone the project and setup the build environment for you.
All software has to hardcode something at some point, this is unavoidable. I don't use GNOME either, but they do make it very easy for newcomers to contribute and to change anything they want. It's open source after all, the control is in the hands of the user.
I don't follow. In my experience setting up a build environment and changing a couple lines of code provides a lot more control (and is a lot easier) than rewriting the whole thing from scratch or ditching it entirely for something else. If your distro's package manager supports source builds then you probably don't even need to use tools like GNOME Builder to make quick modifications.
If you find setting up a build environment to change a few lines of code more reasonable than switching to software that wasn't so boneheaded as to hardcode the value in the first place, then good for you I guess. I personally don't have much patience for it.
There is no need to set up a build environment. GNOME Builder does it for you, for GNOME packages. For other packages, on my distro (Debian) the package manager does it for you. It's 4-5 commands to download dependencies, download source, rebuild and reinstall ANY package. Comparatively, the cost of switching can vary wildly depending on the software and available alternatives.
* The screen locks, unlock, but the network card cannot wake up anymore and requires a reboot.
* The screen locks, let you enter things, but doesn't seem to react, then suddenly, replay all the things for 20 seconds in 1 seconds, and displays an error message
* the screen locks, but you can see the unlock screen for a few seconds when you wake the laptop up
I've had the second, and it wasn't related to suspend. For some reason, the GUI decides to do a software bit-blit of the entire screen, which takes tens of seconds, before it lets xscreensaver put up its dialogue box. So don't assume that this is always suspend-related. There are several quite varied possibilities.
Indeed. But since it's so slow that I can see the blit happening, scanline by scanline, it's definitely what is happening, even if it's not apparent why. (I do know that the particular window manager in use decides to move windows back and forth by 2 pixels to work around some sort of bug.)
Not being able to explain why the software does this does not negate the fact that it is doing this, and that it is a quite different possible reason for lengthy pauses in the user interface, one of several, that is nothing to do with suspending the machine; indicating that, as I said, one should not assume that these things are always suspend-related.
* The screen turns on when the lid is opened, the login prompt appears, but the backlight is still off so you cannot see anything (except by using a super strong flashlight).
I'm lucky not to experience such problems on my arch with my current machine, but I've run into these issues on my past machines. However, my graphic designer friend working on Windows (he needs Adobe cs and blender and therefore needs a good gpu in an affordable machine ruling out Macs) keeps on having this problem. Drives him nuts because he'll close the lid, pack the laptop in his backpack to go somewhere only to realise when taking it out that the laptop is close to being to hot to touch. On a 3k msi that's a few months old, it scares him to death ever time it happens, which is quite often. So I guess this is a harder problem than it seems !! I don't remember ever having this problem on my Mac.
Seriously, If these distros still can't come together and get something as simple as screen locking right and consistent on X11, Wayland with a DE like GNOME or KDE, etc then it is difficult to recommend / market any Linux desktop distro to a typical consumer. It really is one of the smallest issues that would turn off a user moving to Linux, just to get work done.
I wouldn't blame them if I see any of them ending up staying on Windows or moving to macOS or outright iPadOS.
Yeah, I tried to get xsecurelock working with LXQt and systemd. What a mess. Eventually I had to just give up on it and switch back to xscreensaver-lock.
I posted a thread asking for advice and did get responses, but I haven't worked up the resolve to go back and try to get it working again. Last I checked, people were just suggesting I try something else, which kind of misses the point of the activity to uses the most secure lock screen that seemed to be available.
I appreciated the help, it just seems like the whole issue should be something provided by a systemd utility that you specify your lock screen for in a config file. I know people hate on it, but systemd really does tend to make it easier if you just kind of want your system fundamentals to stay in the background and just work rather than having to constantly meddle with them.
It's a point of pride to me that I've kept my Linux system going for so long (it's outlived one Windows and two Mac laptops) but it does feel like there's often a very myopic design to a lot of applications. That is, the author often expects you to be willing to context switch out of whatever you were doing for a few hours to learn their software to use it, and doesn't feel like there's any usability problem with the state of affairs. In the case of a lock screen, this was turning into multiple days.
I can only imagine that if things were simpler, it would make it easier to involve more people, bring them on board, and/or just to get stuff done.
I haven't had any of these issues with freebsd and xscreensaver on my thinkpad.
It seems like mostly power management issues rather than the screen lock. If you removed the screen lock program entirely (remember that it is possible to run without one) this would still be a set of bug reports, eg. not suspending when you expect, not coming back from suspend..
My own experience using various laptops (mostly thinkpads, but also a couple of asus and one dell) over the last 10 or so years under Fedora has been pretty consistently good. There was a period between Fedora 28 and 30 when it took 10 seconds to un-suspend (instead of it being instant) but that is fixed again in Fedora 31.
This is one of the reasons I had to stop carrying around a Linux laptop. Had a few times where I'd open up the laptop to find the screen locker randomly bypassed
Yes, it's imperfect and irritating in many ways. Many other actually (BT, Wifi, battery life, they all have their problems).
But your alternative is one totally locked on ecosystem and one provided with embedded spywares.
It's good enough, and since we are not giving millions of dollars to the editors like we do with products disrespecting us, I understand we can't ask for perfection.
I've been using linux for 15 years. It's better in every way.
My mother has been using Ubuntu for 7 years now. It would have been impossible in the early 2000.
It is better. It is productive. It is even a good experience. I'm no a masochist, I buy and use proprietary software. I use Linux because I want to.
I'm not just not blind to it's many shortcommins.
Last week I used Windows with a client. I had to disable Windows update because it was eating all the Ram. Some people are literally buying a new mac because the mechanical keyboard is unusable on some models.
There are systems you complain about. And systems nobody use.
That's true, web standard made OS less critical for an average user, and time let some other native apps improve and polish (things like krita and blender comes to mind)
Funnily enough, my 3-year-old Macbook Pro just died, and times being what they are with your usual build-to-order options being severely backordered, I stepped into a local store and bought a laptop off the shelf -- an LG Gram 17.
It's not even a brand that's well-known for Linux compatibility (like Thinkpads), but all I've had to do to get Lubuntu 18.04 running more or less flawlessly was disable Secure Boot in the BIOS. Wifi, sound, and webcam all worked without needing tinkering. Bluetooth appears to work based on it being detected, but I haven't tried pairing anything yet. The only thing I hear doesn't work is the fingerprint sensor, but I wasn't going to use it, anyway.
Suspend on lid down and wake on lid up hasn't been an issue at all. I'm actually very pleasantly surprised at how well this LTS version from 2018 runs on a 2020 model laptop.
I can't stop hating Microsoft for WSL. Yes, it is a way forward for the company but I still have a feeling they have found a perfect way to make younger generation ignore Linux completely.
These are good suggestions, but it seems that xsecurelock still can't provide a workaround for the bug where the screen doesn't lock if a popup menu happens to be open or the pointer is grabbed in any other way [0]. I couldn't find any good way to fix this and the only suggested workaround seems to be to switch to Wayland. I've switched on all of my machines (for this and for other reasons) but please make sure you know the details of this if you still use Xorg.
There is no way to fix it. Also, X11 has several ways of writing keyloggers to get around input locks. I've written one here https://github.com/magcius/keylog
This mentions writing the screen lock UI in QT. jwz, maintainer of xscreensaver, had a rant about why he avoids the use of a big toolkit. The short version is he wants minimal code size because the consequence of a crash is to unlock the screen. The rant was prompted because of a real life gtk+ bug which made another screen locker crash.
I would find a link and include it but jwz is hostile to links with HN as a referrer.
> the screen content can be exposed. Consider for example the linked screenshot.
That's funny, because the effect there is obviously intended, because, uh, it looks cool.
> For a screen saver of the last millennium this was a suitable solution
It's true that this particular effect was much more impressive in the 90s. Personally I use the 'blank' demo in xscreenaver. Which I guess I could replace with the script in TFA without noticing much.
> Today users also expect the current time, battery state and many more information on the lock screen. We need to provide accessibility features which is not possible in XScreenSaver.
I don't see why this is not possible with Xlib. Yes I have written Xlib code. Seems to be just an "omg xlib is so old" argument, and things being old does not by itself make them incorrect.
I don't have any opinion on those. Regardless of how you or I feel about any extra features, the author does seem to have an answer to the security concern.
That's what I'm also recommending and working more/less reliably in terms of locking.
One thing which I'm also analysing recently is electron shit^H^H^Happs, triggering XSS (X screen saver) idle detection on some internal app events (not user actions!).
Being: if you dont move mouse, nor touch keyboard, plus you're receiving slack messages, XSS considers youre NOT idle, in result not allowing lock to work if relying on xss-idle-detection.
needing it as I'm expermineting with some cool X11 software from 199x. I added XSS support, as original detection engine(*) dont work reliably on modern X11.
It seems more secure as it bypasses X, and you can be sure (can you? I just assume this, I don't really know) your input is not even being passed to X when your screen is locked. In practice I've found it very reliable.
I don't understand why we don't just lock screens by switching to a different virtual terminal running a different X server. If the lock screen doesn't share an X server with the user session, a lot less information can leak. This entirely-separate-session approach is what Windows uses, and it works great there.
It's a separate desktop, but not a separate window-station, let alone a separate session. The clipboard and atom table are not separate, because they belong to the window station; and a session is something rather different on Windows NT.
* The screen doesn't lock, and remains on while the lid is closed.
* The screen doesn't lock, but does turn off when the lid is closed.
* The screen locks, but the machine doesn't suspend when the lid is closed.
* The screen doesn't turn on after the lid is opened. Key commands work, though.
* The screen turns on after the lid is opened, but is blank (no unlock requestor).
* The machine doesn't resume from suspend, requiring a hard reset.
* The screen locker gets completely bypassed and you're dumped into the desktop (possibly a fresh desktop because the entire environment crashed and restarted).
Throw remote desktop into the mix and you're in for a world of hurt.
I just disable screen locking, and make suspend a manual operation to keep my sanity intact. The trackpad still stops responding sometimes though...