I find interesting that GNOME Screensaver's security depends on it to not crash.
Meanwhile, in KDE the lock screen is managed by KDE Session Management Server which ensures that lock screen cannot be bypassed by simply crashing its process.
The way it works is follows: ksmserver draws a black rectangle over everything and spawns kscreenlocker. If kscreenlocker crashes, the black rectangle is still here, and ksmserver will spawn kscreenlocker again but this time with software rendering (just in case it crashed due to graphics driver issue). If kscreenlocker crashes four times then KDE Session Management Server gives up, stops respawning kscreenlocker and simply draws the following text on the screen.
The screen locker is broken and unlocking is not possible anymore.
In order to unlock switch to a virtual terminal (e.g. Ctrl+Alt+F2),
log in and execute the command:
loginctl unlock-session %1
Afterwards switch back to the running session (Ctrl+Alt+F%2).
If ksmserver itself crashes then the entire session closes.
I'm not sure why GNOME screensaver cannot do something like this. Lock screen crashing seems like something inevitable (especially considering buggy graphic card drivers and so on), and it makes sense to prepare for it so that crashes won't bypass the screen locker.
In Windows it’s also good. The way it works is follows.
The OS support multiple desktops. Similar to files or registry keys, desktops have security descriptors attached (a data structure keeping who’s the owner, and optionally listing users/groups with their respective permissions on the object being controlled).
To do anything on a desktop, like create windows, paint stuff, or interact with windows on that desktop, user doing that is required to pass an access check against the security descriptor of the desktop. If failed, these GUI-related functions gonna return “access denied” status code instead of doing anything.
The login screen is simply rendered on a separate desktop. That desktop has restrictive security descriptor, most users don’t have permissions to interact with them. UAC prompts are also displayed on another desktop, that’s how it’s impossible to automate them from within a program who triggered the UAC prompt.
BTW, about crashing GPU drivers, on modern Windows the condition is recoverable. The symptoms are black screen for a second, then the OS resets the hardware, restarts the driver, and resumes rendering of the desktop. Observed quite a few times working on advanced GPU stuff, especially compute shaders.
> BTW, about crashing GPU drivers, on modern Windows the condition is recoverable. The symptoms are black screen for a second, then the OS resets the hardware, restarts the driver, and resumes rendering of the desktop. Observed quite a few times working on advanced GPU stuff, especially compute shaders.
When I mine cryptocurrency while playing games, I appear to sometimes run out of GPU memory (Both Task Manager and MSI Afterburner let me monitor usage) and I have experienced this reset. It's surprisingly graceful, even when a game is running, though NVIDIA Broadcast often doesn't like it and needs to be restarted, and I will sometimes see lingering graphical glitches in the game until I restart, but it's not game breaking.
You can also trigger a GPU reset manually with CTRL-WIN-SHIFT-B.
>I'm not sure why GNOME screensaver cannot do something like this.
This actually is fixed in upstream GNOME because the screensaver is now built into the shell. The problem here is exclusively with cinnamon-screensaver and other components derived from gnome-screensaver, which is unmaintained and upstream GNOME considers it obsolete.
jwz has a lot to say about complex graphical toolkits/desktop environments and their complex locking mechanisms. It's an interesting series of posts.
If you are not running xscreensaver on Linux, then it is safe to assume that your screen does not lock. Once is happenstance. Twice is coincidence. Three times is enemy action. Four times is Official GNOME Policy.
Also, if you're using a Hacker News app, it won't send a Referer header when opening an article unless the app authors went out of their way to implement that. I would be surprised if any did.
I would recommend not linking to jwz's website. Use web archive or something if you have to. jwz dislikes Hacker News and intentionally shows an NSFW image when Referer header shows Hacker News.
Can he at least update the text? HN was full of entrepreneurs and wantrepreneurs years ago. It is mostly big- and mid tech employees now, tech bureaucrats if you will.
Not to belabor the meta discussion, but your comment sparked a question. If it is how you say, and using a politico-economic lens, I wonder if there has been any discernible shift in commenter attitudes as the demographics have changed. Specifically, if the shift was from entrepreneurs -> skilled wage workers, as you’ve asserted.
The interests of the petit bourgeoisie (entrepreneurs, et al), the professional management class and that of skilled workers sometimes overlap. I think those overlaps would probably translate to some overarching strains of belief, for example, the tendency toward libertarian viewpoints on HN.
Sorry for the tangent, just had to get that out of my head!
This is OT, but I can't resist. I've been around HN since 2011, and tone has definitely shifted in the last 5-6 years. I used to stumble on HN posts that infuriated me relatively often, it was part of the deal (i.e. understanding how the self-appointed entrepreneurial classes actually rationalize certain things). That doesn't really happen anymore.
> those overlaps would probably translate to some overarching strains of belief, for example, the tendency toward libertarian viewpoints
The opposite is actually true, in my experience. Hardcore libertarian views on HN have been largely quashed into irrelevance, they only survive in lore. New commenters who join and expect HN to be a nest of hyper-capitalists are quickly downvoted into oblivion. Which is not a terrible thing in the great scheme of things, from the personal perspective of somebody who would likely dislike their point of view; but it has definitely taken something away from the HN experience, and possibly pushed some people towards worse (more radicalized) forums.
What I miss about the old HN is learning about all the cool new programming tools, libraries, frameworks, etc and participating in the discussions about them. These days, you rarely see posts about programming tools, unless it is one of the big ones like React, Qt, or TypeScript. I used to stumble upon so many great tools on HN, but that has become a rare experience these days.
Is there still somewhere on the web, perhaps on Reddit or another platform, where you can find such posts and discussions?
>Is there still somewhere on the web, perhaps on Reddit or another platform, where you can find such posts and discussions?
If they exist it would be wise not to link it here, or else the same fate would befall the new community. My advice is to search for a small community around a niche topic (say a specific text editor or programming language).
There are some great Reddit subs for niche projects, the trouble is discoverability. Those I’ve found have always been via obscure links or a chance hunt after finding a git repo.
I’ve also been around for donkeys years, and I agree mostly. Certain topics bring the “screw you, got mine” opinions back out of the woodworks at times, but yeah it’s far less prevalent.
> Hardcore libertarian views on HN have been largely quashed into irrelevance
Having seen a few threads recently (notably "Parler off AWS") where those views seemed quite exuberant, I'm not sure they've been quashed; maybe dormant until the right thread comes along?
It has something to do with the 1990's dot-com culture, like the original Netscape was somehow more pure than what came after, and this causes him to view modern inheritors like YC with a jaundiced eye.
It's quite nice of Apple to strip this by default in Safari—didn't even realize it was a thing until I switched over to Chrome to see what you were talking about.
I tested Safari on iOS, iPadOS and macOS and it didn’t strip the “referer” header for any of them. WatchOS did strip it though I’m not sure that counts as Safari.
Anecdotally, I use xidle[0] and xlock[1], and have found both to be very reliable. xidle supports locking the screen by sending it SIGUSR1, which is really useful since you can trigger it from a process that doesn't have DISPLAY set.
The trick on laptops is to block on sending the signal in the script you use to suspend, so that when the laptop resumes the display is already locked.
I actually had this happen around Christmas (using Manjaro). I had no idea what the message really meant or what caused it. The instructions were at least clear enough to get back into the running session, which is far better than, say, most of GNOME's crap.
> Our internal research found that clear error messages confused our users and removed it.
I can't tell if this is sarcasm or if you're serious. If you're serious, please tell me what product you've butchered so I can avoid it like the plague.
Clear error messages only confuse people who shouldn't be using the product in the first place. More importantly: a clear error message at the cost of a few confused users is far more important than an unclear error message that costs even more users hours or days of trouble.
I would far rather have a message that tells me that the software broke because the desktop manager found a crash loop and point me to the crash loop logs even if some other poor unfortunate soul has no idea what a crash log is or can't figure out how to access or understand the crash log.
I've had similar discussions at a previous job with their platform (it was a marketing dashboard). Management wanted developers to suppress error messages because users wouldn't know what to do with them. However, users always contact the help desk when things go wrong. User feedback became much harder for us to understand, so issues would take much longer to resolve. Instead of saying "I did ABC and I saw a message that said 'XYZ'", they would say "I did ABC and it broke"
I'm asking nicely, can we please not do this? Let's not exacerbate the problems of bad communication by using more sarcasm and hyperbole. If there is some particular thing that can be done to improve areas where there are perceived design proclivities, can we focus on that instead?
I agree that sarcasm provides for poor constructive criticism to get a point across, but the intent was mockery, not being helpful.
I certainly do not believe that GNOME would take the advice of an H.N. post, and they are well aware of these criticisms to begin with, as they are commonly levied against them.
I don't mean criticism, we (HN users) all have heard all the criticism a hundred times before. I mean actual actionable feedback that someone is able to work with, e.g. if there are problems with the design then we can bring some concrete data that shows new, reliable information. That means taking honest efforts to establish two-way communication where there is none.
Please don't discount yourself like that, by resigning to the usual HN snark. I think you're smart and capable of much more. If there is new, important and relevant information brought to them, they will listen to that. (This applies to most big projects I've seen, not any one in particular. The smaller niche ones that commit to having their small narrow audience are the ones I've seen that tend to be resistant to new ideas)
Many developers and executives do participate in social media including Hacker News. I have seen plenty of tech-related fixes and features that come directly from Hacker News comments.
In all I think the best feedback I can give you would have been to include a `/s` to indicate sarcasm and jest.
> Many developers and executives do participate in social media including Hacker News. I have seen plenty of tech-related fixes and features that come directly from Hacker News comments.
But the comment wasn't bringing up anything new about GNOME. There is no information someone from GNOME could get from that post, no matter how it was worded. It is not a constructive vs. snark situation.
> In all I think the best feedback I can give you would have been to include a `/s` to indicate sarcasm and jest.
It seems like the same argument would have happened anyway, so eh.
I am sorry if I'm being pushy, it just gets extremely tiring to see all the same type of comments for years on places like here and on /r/linux. You don't have to listen to me if you don't want, it's just my humble plea.
This seems like an obvious response to gnome's poor behavior in the open-source ecosystem, they've been been burning good will among a large group of developers for a long time now. I think the solution to that problem isn't to ask people nicely to stop being pissed off, it's to fix the underlying problems/attitudes.
I am not saying don't be pissed off, I am saying please channel that energy to help to fix the underlying problems/attitudes. I can give suggestions on how to do this, if you're interested to hear it, so we can maybe have a chance to finally get some issues fixed. Beating the same dead horse going on years now is just not going to help this, regardless of what your perceptions of certain developer's attitudes are. If complaining about lost goodwill was ever a substitute for being persuasive and getting things done and taking initiative to restore the goodwill, it would have worked years ago, and we wouldn't be here talking about this now.
And just to be clear, harassing developers who have said "no I don't want to work on feature XYZ" is never acceptable and never has good results. If somebody says no and is just not interested, we leave them alone and we find someone else who does want to work on that feature.
Not having type-ahead, instead using gnome's search, makes GTK apps really annoying for me. Right now I have a solution that involves patching, but presuming that my ultimate goal is just that one concessions, just have a flag buried somewhere that would enable type-ahead instead of search, how do you suggest I get that done?
I think that would go a long way towards demonstrating that gnome can be reasoned with, is worth even approaching or talking to.
Could we hire a developer? Set up crowdfunding? Can someone give me a quote and I can see what resources I can bring to bear on the problem?
I'd be open to other suggestions on how to channel that energy productively, but I really think if they can't compromise on that one feature that's important to a bunch of people then they're probably not going to be worth dealing with. Feel free to send me an email, at gmail.
If you have a working patch for this that makes it a configurable option then just use that. There is no harm in submitting that as a merge request either, worst case it gets rejected again and you're in the same spot you are now. I don't believe a real non-intrusive patch was ever submitted for this, everything out there just seems to be a revert back to some old functionality that breaks other things. (Please don't waste maintainer time submitting patches that are broken or hacky, or patches that were already rejected. When in doubt talk about it with them first before submitting anything, and make sure your patch is actually new and addresses all the concerns that were made in the bug tracker already)
If it does get rejected then you do the same thing you'd do with any other open source project: convince your distro to carry the patch. I think the key here is to just not lose sight of the goal which is to get enough support somewhere to have the patch maintained, if you don't care to become an upstream developer and work closely with them then you can skip that and just do the same process but only with a downstream that is relevant to you.
If the patch still needs a lot of work/money to get it to the point where it's stable and doesn't break other things, well, now you know why upstream doesn't want to do it... so with that I would say a way to help would be to commit to maintaining this for however many years you expect to be using the patch. I can't give you a specific quote (I don't have any interest in working on this, sorry) but based on average developer rates you probably should expect to spend at least a few thousand dollars on this total, over several years of maintenance time, if you are not the one who is going to be writing the code. Of course, you can reduce the burden on yourself by getting a distro to share the cost, which is why I suggested that first :)
>When in doubt talk about it with them first before submitting anything
Normally you'd do that before even working on the patch, and you can see what kind of response that's gotten.
I've got a patched version that suites my needs, as I say. That being said I'm sure raising a few thousand dollars for that feature wouldn't have been hard.
I don't think we have. Like I said, I have not seen any serious offers to work on a non-intrusive patch for this, to put up the time and/or money and to maintain it for the number of years required. That's what you want to look for. And if you want to bring it upstream, you have to sell it to them in a way that shows it will not increase their maintenance burden or break the currently in-place designs. (This is not a GNOME specific thing, this is how basically every open source project operates. You generally can't just dump code on upstream and expect it to go well)
If you want to do fundraising, some trusted person has to put in the time to do it and to manage the money.
>lest people make the mistake of building stuff on top of it.
This is the kind of hyperbole I'm talking about... As with any open source, you don't have to use the parts you don't want. GNOME as a whole is a pretty big project, and like most projects, some of its parts are stable and up-to-date, and some aren't. Lots of other desktops build on pieces of GNOME technologies because they work, and replace the parts they're unhappy with. So I'm sorry if you feel a particular component made a mistake, but it really does not have to be a mistake that affects you, if you handle things the right way.
Can you be more specific about what kind of citation you're looking for?
I don't want to use systemd-logind or the gnome search services. Right now not using either of those requires a whole lot of work. It's actually pretty hard to use GTK apps with only the GTK toolkit and not a bunch of other software daemons. Hell, in a perfect would I'd even get rid of dconf and gnome's weird registry, but I recognize that as pretty integral to the toolkit.
AFAIK the only component that really relies on logind is GDM. If you don't want GDM and are comfortable using another display manager to launch your GNOME session, that should work fine, although I haven't tested this in a while. You may also be able to launch your session manually the old way, without a session manager, although that will probably require you to use setuid X which comes with the usual caveats. It's probably a total no-no if you're using wayland. If you decide you want GDM and wayland then you still don't need systemd-logind for session management, you can use elogind, or you can grab BSD's patches for consolekit support. The real issue there is that GDM requires some kind of session management, if you want to do this without any other daemons whatsoever, then you will have to reimplement parts of logind/consolekit inside GDM.
With the search services, there is a switch for that in settings under "Search."
With dconf, that is not actually integral to the toolkit. The API that applications use is GSettings, which requires a backend to actually store the settings, and dconf is just one of those backends. You can disable the dconf backend and just use the one that writes ini files to your home directory, or use some other backend. Technically apps can try to force the dconf backend but I've never seen one that does this.
Maybe the issue is what you consider a "clear error message"?
A clear error message should not necessarily clearly explain what the issue is - a clear error message should clearly explain how to solve the issue, or at least point the user in the direction of a solution.
At a minimum, a clear error message should include a contact point and what information to include. If error logs are available, they must be available for inspection, annotation, and approval before submission.
I have no idea why GNOME is the default DE for the big distros (Redhat et al, Ubuntu). Technically it's evidently inferior, it had substandard ergonomics and features like accesibility services. I really dont get it.
The Gnome screensaver lock is only a fluffy fake security mechanism. It's not real security.
I've had many instances where my CPU was bogged down and after hitting the keyboard I could use the computer for a good several seconds before the lock screen popped up asking for a password.
> I'm not sure why GNOME screensaver cannot do something like this. Lock screen crashing seems like something inevitable (especially considering buggy graphic card drivers and so on), and it makes sense to prepare for it so that crashes won't bypass the screen locker.
That is an option Linux Mint is considering[0] among other options.
Meanwhile, in KDE the lock screen is managed by KDE Session Management Server which ensures that lock screen cannot be bypassed by simply crashing its process.
The way it works is follows: ksmserver draws a black rectangle over everything and spawns kscreenlocker. If kscreenlocker crashes, the black rectangle is still here, and ksmserver will spawn kscreenlocker again but this time with software rendering (just in case it crashed due to graphics driver issue). If kscreenlocker crashes four times then KDE Session Management Server gives up, stops respawning kscreenlocker and simply draws the following text on the screen.
If ksmserver itself crashes then the entire session closes.I'm not sure why GNOME screensaver cannot do something like this. Lock screen crashing seems like something inevitable (especially considering buggy graphic card drivers and so on), and it makes sense to prepare for it so that crashes won't bypass the screen locker.