The QA team had a test they called “the elbow test” where they did exactly this.
Just kind of put their elbow randomly on the keyboard to see if stuff would break.
>The source of the vulnerability is nothing but an integer underflow fault that was introduced with single commit in Grub version 1.98 (December 2009) – b391bdb2f2c5ccf29da66cecdbfb7566656a704d – affecting the grub_password_get() function.
[1] https://thehackernews.com/2015/12/hack-linux-grub-password.h...
No dialogs or confirmations. Just black screen and computer rebooting.
Color me surprised! /s
smashes keys
Unlocks
( see also http://catb.org/~esr/jargon/html/index.html and https://en.wikipedia.org/wiki/Jargon_File )
"Cracker" is the term used commonly - as in "crack the nut"; i.e. gain access to systems / break copy protection etc. Then you have the phone guys, the phreakers, whistling for free calls.
Hmm. Right spirit but not so much "hacking code together" going on at MIT's Tech Model Railroad Club in 1958.
"a project undertaken or a product built not solely to fulfill some constructive goal but with some wild pleasure taken in mere involvement, was called a `hack'".
(Steven Levy, "Hackers").
HACK: 1) something done without constructive end;
2) a project undertaken on bad self-advice;
3) an entropy booster;
4) to produce, or attempt to produce, a hack.
HACKER: one who hacks, or makes them.
----
[1] "An Abridged Dictionary of the TMRC Language", 1959: http://www.gricer.com/tmrc/dictionary1959.html
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).
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.
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.
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.
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.
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.
https://web.archive.org/web/20210117212403/https://www.jwz.o...
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 have no idea what KDE is or does, sorry.
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.
That is an option Linux Mint is considering[0] among other options.
[0]: https://github.com/linuxmint/cinnamon-screensaver/issues/354...
It was 4-5 years ago when he was about 2. I had a 15+ character random password (a generated one including symbols etc) so the chances of him being lucky were rather slim. He was just mashing button on the lock screen for less than a minute when boom, I was suddenly signed in. The first time I thought it was a fluke. Then it happened again after a couple of months. After that I took my phone, sat him behind my computer and started to record him playing with the buttons but it never happened again and my hopes of getting a bug bounty from Apple vanished :(
Wow every new person who joins that thread misses the point more than the previous one. This was painful to read.
2: Use ML to learn how to simulate it.
3: Sell it as a service, labeling it KaaS.
4: Profit, then go to jail because of a misunderstanding.
But seriously, is there such a tool to automate this?
> In 1983, Steve Capps at Apple developed "The Monkey", a tool that would generate random inputs for classic Mac OS applications, such as MacPaint [0]. The figurative "monkey" refers to the infinite monkey theorem which states that a monkey hitting keys at random on a typewriter keyboard for an infinite amount of time will eventually type out the entire works of Shakespeare. In the case of testing, the monkey would write the particular sequence of inputs that will trigger a crash.
Read the story here:
https://www.folklore.org/StoryView.py?story=Monkey_Lives.txt
But this is pretty impressive as well!
1: jwz says if you add accessibility features to a text box, make sure they don't have any bugs that can kill a process, since that will break screen lockers
2: Cinnamon adds a buggy accessibility feature to a text box that lets you crash the screen locker
3: Github user clefebvre says something along the lines of "why is jwz being so negative >:("
Well... you did exactly what he told you not to do. If you're going to add accessibility features to a text box, you need to not screw it up. If you screw it up, then it breaks the screen locker for every user in the world, including the 99% of people who will never use the accessibility features.
If you make an obvious, stupid mistake, people will make fun of you. Complaining that people are making fun of you won't do much. Try, instead, to not make the obvious stupid mistake?
From the issue:
>With that said, I have on message for JWZ. Don't be that guy. It's too easy to just tell people no to cross the street. Work with us on building that safest path.
Huh? What? He wrote xscreensaver 20 years ago. He's supposed to fix buggy code written by other people until he dies?
Why is it his responsibility to fix your code? The distro extended his program, the extension broke. You can either ignore the problem, remove the extension, or fix the extension. None of these things sounds like xscreensaver's problem!
cinnamon-screensaver (the repo this discussion is pertinent to) is written from scratch. The commenter's intent here is to suggest that JWZ has valid criticisms, but he has voiced them before and his latest blog post doesn't add anything to the discussion.
This blog post, which links to the issue, creates additional overhead for the project to deal with. Just like this HN link does.
I think its fair for us to give them a voice in the matter if we're showing the discussion to everyone. It would be nice to assume people read the entire discussion but clearly, that is not a reality.
Pretty rich from someone who starts with "I'll fight him in a cage match"
I also remember figuring out how to share my USB key as a network drive to other users. Many fun middays were had blasting around in Halo or Soldier of Fortune II with like 10 friends, although less fun was had when our school's sysadmin found some lingering cache files that were owned by my id.
The number of emails I got from that was worth the vitriol contained in them, including threatened lawsuits.
Only approved programs software was supposed to run but you could actually run anything as long as the .exe was on the desktop.
7-zip would let you explore the entire network drive, including teachers folders that we didn't have access to.
Unplugging the reconnecting the Ethernet cable wouldn't reconnect you to the teachers monitoring software.
We had a zip filled with games like Starcraft 2, Quake 3, Halo CE that was hidden on the shared network drive that kids around the school would use to play and LAN with each other.
My daughter was 1ish at the time, and I sat her down while I grabbed something from the fridge. Windows 98, locked. When I came back the screensaver was on, the password dialog was still up, but the desktop was fully functional in front of it. I could navigate, open applications, and everything else.
Still no idea how she did it, but that’s not the first or last time she surprised me :)
In general, the way you secured a Windows 9x box was by locking the door to the room it was in.
My daughter managed to buy 24 hours of football pass with NowTV by pressing the same button repeatedly on the remote within about 5 seconds.
So a crash like this doesn't surprise me.
My daughter, whilst roaming in the US from the EU somehow managed to get unlimited data after her initial miserly roaming allowance was used up.. simply by switching airplane mode on and off repeatedly until data worked.
I was stressing getting back home to a huge bill, but kept the "all chargeable services have been stopped" messages just in case.
My final bill was £300+, zeroed.
Phew!
That was probably not a crash, on some that did a partial reset.
For example LLVM's lib fuzzer uses instrumentation to track code coverage and mutates data to find invalid behaviour.
https://llvm.org/docs/LibFuzzer.html
It uses a compiler pass to insert code to branch points functions calls etc. I think it uses genetic algorithms to increase coverage by changing the data.
There are others that work in similar ways one of them is. https://github.com/google/AFL
https://media.ccc.de/v/30C3_-_5499_-_en_-_saal_1_-_201312291...
(For example, I once wrote a hash table implementation where the insertion and resizing procedures had slightly different views on wraparound, causing failures on very specific inputs. Another time, I wrote some code to buffer out-of-order messages, which would only occur due to a race condition. It was wrong. Both times I had thought carefully about the code, and the bugs would have been painful to discover otherwise.)
(I haven't used it myself yet, but it looks interesting.)
And a quick response by the maintainer who shows thank, is focused on a clear outcome, and shows the progress transparently.
I've seen too many bugreports where one, or both actors behave vastly different. This one here should be a reference for anyone involved in 'bugreports' in some way.
If you can describe your program as a state machine, you can ask an SMT solver to find any transitions that break stuff. Unfortunately it's a lot harder to do for software than hardware because of the plasticity people expect from the former, but works it was it's really nice.
Start kiosk mode fullscreen app as a lock screen -> if app exits -> show desktop
The whole desktop architecture is out of date. I wouldn't be surprised if someone argued that screensavers aren't important because it's just your user data exposed, the root account is still safe!
Fool-proof and child-proof software is yet to come.
Hire QA kids.
I see similar behavior with smartphones.
3 y.o. figure it out better than my parents because it seems their mindset is ‘do all the things’ to see what the i/o structure is. Their brain is built that way when they are so young.
Using some a couple lines of VBScript to change a couple registry entries (computers didn't persist storage anyways) you could also give your local admin privileges, to install stuff. That one got me in a touch of trouble, and I lost my account for a couple weeks while they "looked at my files", because I stored it on my network drive folder.
The concept of screen lockers is having a special layer, that can't be bypassed, which a locker creates. The whole security then hinges on the locker not crashing. X11 does have such a layer. Wayland compositors also implement it through such a layer. And for either the situation is, that if the locker crashes, that layer is destroyed by implication and the session exposed.
That's a flawed concept.
What you really want is detachable graphics session. On the text console one can effortlessly use screen or tmux and to "lock" the session simply detach and exit to the regular login getty.
You want exactly the same, but for X11. And there's no obstacle in printiple to implement this. It's just that the Xorg server can't detach. Almost all of the required code is there, fundamentally it'd be the same code that's executed during a VT switch.
In the meantime one can use Xpra with Xvfb to create detachable X11 sessions, which then however lack GPU acceleration.
a) there's no Xserver concept of a lock screen which would be hard to fix, I suspect. How would you signal X to lock/unlock; what would it do if the lock client wasn't connected, etc.
b) there's no atomic way to transfer mouse/keyboard grab to another window, which means you can't have a reliable, crash reduced screen locker that supervises a beautiful password checking program; it has to be the same program. This could probably be fixed with an X extension; yes, an extension is a lot of work, and yes, you'd have to deal with fragmentation, but you could keep the untoolkited password dialog in case the extension isn't present, nobody would see it unless they did something odd, so it's fine.
Another issue is that I think I've seen some linux systems don't launch the screen locker until resume, instead of locking before suspend; that's not ideal, because the screen locker will take time to launch and lock the screen (more so if it's got a fancy initialization routine and is a large binary/many libraries to load).
An option could be running a dedicated screen lock Xserver on a different VT, and (securely) switching to that one somehow. But that would probably involve changes to multiple layers at the same time, which is hard to pull off in Linux. People would complain about the bloat of running a second Xserver, regardless of the actual bloat or imcreased utility.
Its not an X11 problem.
(using bit.ly because he gives a testicle if referrer is HN :P)
They do nothing fancy - paint a window over everything and wait for the password to be typed in. No animation. No graphics. No anything. No enter unlock password dialog. I am sure there could be some edge cases but I'm having a hard time identifying them.
It seems like this whole class of bugs could be fixed pretty easily by having a simple process watchdog run xscreensaver as a child process, and re-launch it if it crashes without first signalling that the desktop has been unlocked.
> 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 c2". Afterwards switch back to the running session.
I think it's a reasonable design.
From the point of view of the display manager, a screensaver/screenlocker crashing is just a simple app crash. There's nothing in the protocol to suggest that this is a security failure.
Might be better to just exit the session or load a minimalistic replacement lock program (like the original xscreensaver) to avoid an infinite crash loop.
Edit: For me stuff
I have been recommending fedora to people for a while because their defaults are far more modern and sane rather than clinging on to python 2 and X11
The thread was linked below (or above, to this same parent), or see: https://web.archive.org/web/20210116101222/https://www.jwz.o...
I don't think I could interact with the screen in any way, but I could certainly take a picture of it, if I had any private information on the screen.
It will go to sleep, then when I wake it up, I get a flash of my desktop before the lock screen shows..
Too fast to write anything down by hand, but you could certainly point a 60fps camera at it and get something I'm sure.
I wasn't too concerned about it since it still blocked all user input, but if you had sensitive info visible it could definitely be an issue.
My guess is that these lock screens are all bolted on afterwards rather than being in the design from the ground up.
Really? I have never seen this in Windows. Don't get me wrong, I've seen plenty of lock screen failures in Windows, usually in the form of it suddenly being unresponsive, just never anything that actually gave me access to the locked session again.
The closest I've seen is when using RDP, if the Window has been minimized or hidden or otherwise has had reason not to update its display, then locked due to timeout, it will briefly show the last image it rendered when reactivated before updating and showing the lock screen.
P.S.: As other users have pointed out, Windows does have some known lock screen bypasses using accessibility and help dialogs, but in regards to merely crashing the lock screen, I haven't seen it behave in an insecure way.
Off-topic, but:
It seems absurd, to me, that such a conclusion could ever be reached. Obviously, from my perspective, the economies of scale, the infrastructure, overhead, and institutional resources available to programmers at a dedicated software development firm would produce an application at better quality per dollar (however you measure it) than a high school teacher in their off-hours. To me it seems that it's certainly not cheaper for us as a society, as a species, and only appears so because you are under-paid. If you were paid your actual worth, the school would say "we don't have the funds to develop this in-house, and had to buy a commercial typing program off-the-shelf, despite its loose fit for our use case."
How can we, as rational members of society, abide this?
Where I work there is a tool that's used in hundreds of our internal services. It was written in-house during one of our hack weeks years ago, and later we open-sourced it. Despite the fact that the org relies so heavily on it, it's completely unfunded; two employees improve and maintain it in our free time. (We do have a few outside contributors, too, which is awesome!)
That's not exactly the same situation, but I think this kind of short-sightedness is pervasive in our culture, in every walk of life.
fff ggg fgf gfg ffgg fggf gffg
jjj hhh jhj hjh jjhh jhhj hjjh
This forces the student to exercise that movement pattern in a way that just telling them to put their fingers on the home row and type English words does not.
So the above sentence you quoted was a an over-simplification for story telling purposes and not the whole story. :)
If you measure it by cost to the district (for which a teacher doing it in their off hours is $0), it's clearly not, even if you only consider the sticker price of the commercial software and not the other costs associated with purchasing in a school.
> If you were paid your actual worth,
The school would fire about half it's teaching staff in order to make budget, and still not have money left over to either develop or purchase the typing program, probably.
On the previous version I believe he managed to unlock the computer as well, just by hammering the keyboard.
https://github.com/linuxmint/cinnamon-screensaver/issues/354...
The commit is at https://github.com/linuxmint/cinnamon-screensaver/commit/38a... where mtwebster writes:
> We'll use the old screensaver auth code instead - this ports gs-auth-pam.c and gs-auth.h from the old screensaver,
Cinnamon tried to re-invent the wheel. They made it very sparkly and shiny and colourful and forgot that it had to be robust, round and capable of rolling.
Jesus wept, you criticise other people for not reading the entire discussion, and yet you somehow missed the part in JWZ's post where he explains that Cinnamon-screensaver was NOT written from scratch. So congratulations, you hypocritically own-goaled yourself there too. Which again, makes me question the charitability of assuming sincerity.
And JWZ is supposed to "work with them" when their code fouls up for the Nth time? No, the idiots should've been writing modules for JWZ's engine, seeing as JWZ's is the one that a) they did indeed steal from and b) still screwed up.
Yes, he's voiced his valid criticisms before. And the damn Cinnamon tards STILL KEEP MAKING THE SAME MISTAKES. This adds to the discussion. It adds useful, educational history that the Cinnamon morons are so stupid that they repeatedly, in the face of history, keep making the same goddamn stupid mistakes.
I get to "the other side of the road" just fine with JWZ's screensaver. I just FIFTEEN MINUTES AGO had to step the housemate through replacing her new Mint install's Cinnamon screensaver with xscreensaver; because what a surprise, it's 2021 and the $hitpile that is Cinnamon screensaver lock would NOT RESPOND to keyboard or mouse and wouldn't let her log in. And either she had to either magic-sysrq, or I had to ssh in to the root account to kill the stupid pile of crap that is cinnamon-screensaver.
And I found this ridiculous comment on this thread, because I was trying to show her a reference as to WHY Cinnamon-screensaver is stupidly broken in its principles and why xscreensaver should be used instead.
Clement Lefebvre has some pretty big balls to have written what he did; and that's good. Because it'll make it easier to repeatedly kick him in them as he deserves for this. And defence of his positions is... not particularly defensible.
I don't wish to be rude to you; but I finally stopped lurking on HN after years and created an account for the purpose of telling you these things. And by years, I mean that my Slashdot ID is in the 500,000s, rather than say the 60-millions.
Mr. Lefebvre said "cinnamon-screensaver is written from scratch" in his GitHub post. I assumed good faith[0], and thought that maybe after nearly 30 years, JWZ was just a bit jaded and assumed the worst. I see that JWZ is probably the right one here, and clefebvre mistaken.
But Jamie has a certain "tone" that I would argue is a tad combative. To be fair, its his style, just like Linus Torvalds. But that lead me to see his comments in the context that he responds like this to every bad thing (TM) he feels lead to comment on, and I combined that with the GitHub response to conclude that JWZ was acting as a peanut gallery member here.
And please don't mistake my reasoning for support. In both my earlier comments, I was advocating for exposure of the response, not endorsement. I feel that is quite clear, and this is shooting the messenger.
> I don't wish to be rude to you; but I finally stopped lurking on HN after years and created an account for the purpose of telling you these things. And by years, I mean that my Slashdot ID is in the 500,000s, rather than say the 60-millions.
Welcome to HN, officially! But maybe chill with the cred dropping. Appeal to authority is no basis for an argument.
[0]: "Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith." https://news.ycombinator.com/newsguidelines.html#comments
After long research, we found correlation with marketing moving their target from only students to 'older people'. Apparently the latter 'doubleclick' on links and buttons in webforms far more often. At least for us they did.
Expressed otherwise: just because someone’s written one piece of bad software for Wayland doesn’t mean Wayland doesn’t allow you to write good software. (Whereas I get the impression from what I’m reading that X makes it impossible to write a good screen locker, if by that you require that it be crash-proof and use the usual platform toolkit for the UI.)
(Remember in this that I’m saying I don’t know. I’d like to hear if Wayland does have a good answer to this, or from anyone with definite knowledge that it doesn’t.)
I'm imagining 2 processes:
1. Process monitor shows a fullscreen black window. Launches xscreensaver --lock or something as a child process
2. Xscreensaver shows the lock screen over the top of the process monitor, with a password prompt
When the correct password is entered, xscreensaver signals to its parent process. Then both processes close gracefully.
If xscreensaver crashes without signalling, the process manager silently restarts xscreensaver.
None of that requires any changes to X. You'd just want to be sure xscreensaver is displayed on top of the process manager's black window.
Argh. That would be the window manager, of course.
There is also xsecurelock [1] by Google.
Also this bug (and probably most other bugs xscreensaver has had over the years) wouldn't result in an infinite crash loop anyway.
To be fair to swaylock, they actually fixed some of those issues, in contrast to kscreenlocker which are just ignoring most edge-case bugs, because it's nearly impossible to fix them.
When I open it again, the desktop is accessible for a few seconds (sometimes long enough to launch programs) before the lock screen activates and I have to input my password. The workaround I use is to manually lock with Win+L before closing the lid.
Sometimes, while at work, I am thinking of leisure. Sometimes, while at leisure, I am thinking of work.
At the end of the day, the school pays their employee. And the rest of society pays them during "off-hours", e.g. in depreciation of common resources if, say, they drive on the road.
My point is that people cost society to keep alive, but some of those people are better equipped for certain tasks than others. The question is only where do those costs come from, and to what particular efforts are the particularly-equipped assigned.
> I don't see the point of pressing the wrong series of key combinations nine or more times in a row constitutes a "Login Window ScreenShot Problem" any more than dropping my MacBook from various heights until it breaks is a reliability problem.
Why do people hold computers to such a lower standard than other complex devices in their life? (Serious question -- I don't understand people very well here.)
Can you imagine a car that wouldn't unlock or start if a passerby without the key plays with the door handles too much? If this has happened and is documented, that alone is a testament to its rarity and people's unwillingness to excuse the behavior.
Unless it happened to early Tesla, because they were held to the lower standard applied to computers and OSs. That doesn't seem to be as true anymore, thankfully.
I've definitely had my Model 3 not unlock when it should, but I've never had it go the other way around.
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!
> 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.
Why, what's the back story?
You can watch this if you have an hour.
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.
[1]: https://trac.transmissionbt.com/ticket/3685#comment:4
[2]: https://web.archive.org/web/20130429182829/http://www.linuxu...
It is entirely sarcastic, mocking some of GNOME's more infamous design proclivities.
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.
All screens lock together etc.
> python 2
In contrast to Wayland that can be installed in parallel to python 3. So the only reason to remove it is if you enjoy breaking working software.
Also:
> In contrast to Wayland
I don't think Wayland is what you think it is.
And really if you're being DDoSed by a small thing like HN comment links you really have to up your game :) Wait till you get featured on reddit (previously called slashdotting when slashdot was still a big thing).
Nor should he, not least because the redirect reliably results in ~90% of comments in any thread where jwz is mentioned being about the testicle in the eggcup rather than anything substantial.
PS: I have no idea what he means by "finance-obsessed"? I think the community at HN is tech-obsessed which is what I like about it. But finance? This is not yahoo finance or wherever all the finance guys hang out.
It sounds more like he had a clash with someone specific on a finance-related issue and bases his view of the HN community on that. The eggcup is a bit of an immature way to deal with this IMO. Especially as he has good points to make about X11 security, and this undermines them.
How do I get the testicle in an egg cup?
Otherwise, this is the image that gets displayed:
NSFW. This is a testicle in an egg cup.
An interesting website and blog, I like it! I wonder what their problem with HN is, although I don't mind being a testicle!
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).
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?
> X11 ... was designed with no security to speak of, and so lockers have to run as normal, unprivileged, user-level applications. ... This mistake of the X11 architecture can never, ever be fixed.
He also claims in the second post that Xscreensaver is actually vulnerable to exactly the same kind of attack:
> The xscreensaver daemon is a critical piece of security software. The reason for this is that, as a screen locker, any bug in the program that causes it to crash will cause the screen to unlock. As soon as xscreensaver is no longer running, the screen is no longer locked. Therefore, great care must be taken to ensure that the daemon never crash.
- https://www.jwz.org/blog/2021/01/i-told-you-so-2021-edition/
- https://www.jwz.org/xscreensaver/toolkits.html
[Edit]: I understand now. My browser doesn't send referrer URLs, and I think that's the real fix instead of using something like bit.ly!
Besides screenlockers, having 2 screens with diffrent resolutions is way worse in KDE than in GNOME. (On X11)
I wonder why someone would setup a "bad result" for specific referrers ...
Just tested in Chrome and it works there as well.
Can't count on everyone having referrer turned off
Which can be found via this thread: https://news.ycombinator.com/item?id=11412081 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=819703#400
> When navigating to a new site, never send a referer header.
JWZ wouldn't know you are visiting from HN if you use Brave.
https://brave.com/privacy-updates-5/
edit: see also: https://www.cookiestatus.com/brave/#referrer
This particular issue is fixed in logind, when you ask it to lock the season/suspend/hibernate it first calls the lock screen, wait it to signal it finishes and them it proceed to suspend/hibernate.
Not saying you need systemd to fix this issue, but it is one of the things that systemd allows you to do correctly without reinventing the wheel.
Why not just require that it is there? Is there even a valid reason for someone to keep the extension out unless it is to give another "this is the reason X sucks" speech?
Also, because of piecemeal releases, and remote X. You might update Xscreensaver, but not your X server or desktop environment. You might have a dedicated X terminal which can't easily have its server component updated, but you run remote sessions that have an updated Xscreensaver. (Btw, if you do this, you're pretty dedicated in 2021)
I like this site a lot, but I have a lot of patience when it comes to deciphering what is being affected by the Software Hub City Reality Distortion Bubble. Some people don't, hence the eggcup testicle, and people that think something like that undermines the technical argument aren't thinking clearly enough to even debate the technical point with anyway.
I don't know what prompted the redirect; it predates my awareness of Hacker News. I could guess, but why bother? The man has a nightclub to run, and I'm sure that's plenty all by itself to fill his days.
Mac OS almost gets this right, except it annoyingly defaults to sharing the remote session with the local console unless someone is already logged in locally.
Maybe using Xdummy instead of Xvfb would work better?
This wiki article makes such an approach look promising: https://xpra.org/trac/wiki/Xdummy
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.
Is this not what “constructive criticism”, as I called it, is?
GNOME is not going to listen to an H.N. comment an change it's ways, and it was never my intent to reach them or otherwise inspire change in them.
My intent was simply to be humorous.
If I had wanted to reach them, I would certainly do wiser to simply send them a feature requæst bug report.
In all I think the best feedback I can give you would have been to include a `/s` to indicate sarcasm and jest.
Citation needed
Gnome deserves whatever bad reputation it's getting, 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.
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.
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.
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 :)
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.
Anyway, thanks!
* Do you use a nvidia GPU * Do you need to screen share from electron or other x11 only applications (MS teams, etc)
Its ready if you said no to both of those.
Log in, open firefox. Minimize the window, and the entire machine freezes. This is on an AMD GPU as well.
Every time I try Wayland, whether it be sway on my laptop or plasma on my desktop, I run into snags that did not exist in X. So back to X I go.
I'll switch to Wayland when it's ready "for real, actually, promise", and not a moment before. Maybe when Debian Stable switches to it by default.
Doesn't XWayland solve this?
