41–50 of 91 posts
I'm getting by mostly by `xss-lock -- /usr/bin/slock` https://github.com/kaihendry/dotfiles/blob/master/.xinitrc#L... But yeah, one of those things that's surprisingly tricky to get right.
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, b…
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.
Earlier quoted context omitted.
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.
> It's good enough I've been hearing that for between 15 and 20 years now. I believe this mentality is part of the reason it never seems to get any better.
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.
Earlier quoted context omitted.
+1. I'll add: * 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
The first 2 sound more related to suspend rather than screen locking.
It's worth reading this article as well, "Why screen lockers on X11 cannot be secure". I'm not sure how xsecurelock bypasses all of these issues. https://blog.martin-graesslin.com/blog/2015/01/why-screen-lo...
I would find a link and include it but jwz is hostile to links with HN as a referrer.
It's worth reading this article as well, "Why screen lockers on X11 cannot be secure". I'm not sure how xsecurelock bypasses all of these issues. https://blog.martin-graesslin.com/blog/2015/01/why-screen-lo...
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 refe…
It's worth reading this article as well, "Why screen lockers on X11 cannot be secure". I'm not sure how xsecurelock bypasses all of these issues. https://blog.martin-graesslin.com/blog/2015/01/why-screen-lo...
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 refe…
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, b…
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..
Earlier quoted context omitted.
Interestingly this has started happening on my mac, as of a few years ago. Obviously unrelated to Linux.
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.
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.
I'm getting by mostly by `xss-lock -- /usr/bin/slock` https://github.com/kaihendry/dotfiles/blob/master/.xinitrc#L... But yeah, one of those things that's surprisingly tricky to get right.
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.
Anyone?