WTF Bites
-
@Applied-Mediocrity said in WTF Bites:
: Oh you're from {Country}! {City} is so beautiful!
And I'm tempted to go with -
: I've seen it. It's rubbish.Often the tourism areas are okay. It's vanishingly rare that the rest of the city is good, too.
-
In what world would "normal" mean a double Whopper?
Where "small" means single?
-
@anonymous234 said in WTF Bites:
@pie_flavor said in WTF Bites:
@topspin And Starbucks with their sizing.
Where the sizes are
large, larger, largest and ventishort, tall, large, twenty, and thirty.FTFE
-
The only thing not to like is that the icons are different.
How else are you supposed to tell which one you are opening?
-
@djls45 Different, as in different from the normal versions. You wouldn't have both Facebook and Facebook Lite installed.
Normal:
Lite:
-
@brie The Facebook app on iOS has a different coloured icon. It's more like the colours of the Messenger icon. Consistency!
-
@anonymous234 said in WTF Bites:
@pie_flavor said in WTF Bites:
@topspin And Starbucks with their sizing.
Where the sizes are
large, larger, largest and ventishort, tall, large, twenty, and thirty.FTFE
TIL the last one is a thing. And I only know about the venti thing (or anything starbucks related) because of Paul Rudd's inspired rant about it in "Role Models".
-
the last one is a thing.
And I only know about the venti thing (or anything starbucks related) because of Paul Rudd's inspired rant about it in "Role Models".
Likewise.
edit: for anyone who's not seen it. Also Elizabeth Banks
-
-
@Zerosquare
We once mailed out a few 100 pay slips that where incorrectly dubble sided. Luckily they where send through the hrm department where the problem was noticed by a hrm drone fishing out his own paperwork before handing it out.
We have also sent out bills for customer A in envelopes with the logo of customer B.
-
So now that I've re-enabled NoScript…
click "Yes"
click "Yes"
click "Yes"
click "Yes"
click "Yes"
click "Yes"
…
Huh, zooming out shrinks Firefox's screenshot thing too.
-
-
The top apps in the entire store right now.
Notice anything out of place?
-
@pie_flavor said in WTF Bites:
The top apps in the entire store right now.
Strange. My list is different...
-
Thanks to screenshotting this breakage (and restarting Firefox) I lost an amazing Transformer story where the urban legend of the arcade game Polybius dated back to the Trojan war.
I hope Nvidia are happy about this, as I blame their shitty driver for this.
-
From the TDEMSYR department:
Ask Slashdot: Could We Fight Ransomware With 'Unencryptable' Folders? - Slashdot
CaptainDork writes: I'm a retired IT guy and ransomware was not a huge thing 3-5 years ago (at least few victims were self-reporting) and I'm very curious about protection schemes. In my, now ancient, world we did not encrypt anything -- anywhere. Seems to me the trick would be to mark certain...
-
@topspin This wouldn't even be needed if software would deal with the Evil Bit properly.
-
I lost an amazing Transformer story where the urban legend of the arcade game Polybius dated back to the Trojan war
One of those sentences where each word makes sense but the combination could be a Markov chain for all I know
-
Does anybody have a clue which application is
orange ballfive-pointed purple rectangle with yellow polka dots?
-
-
You know, like the eight-pointed black star that used to be a white diagonal cross, but sillier.
Filed under: don't explain the joke
-
Reason ULONG_MAX why
systemdis a steaming dog-turd:
RDRAND on AMD CPUs does not work · Issue #11810 · systemd/systemd
After suspending the system once can't suspend again. Shutdown gives unmount failed errors and can't shutdown too. System info System: Host: Capsparrow Kernel: 4.20.10-1-MANJARO x86_64 bits...
tldr: They re-implimented randomness themselves and broke it
-
@Cursorkeys said in WTF Bites:
tldr: They re-implimented randomness themselves and broke it
No, they didn't. They just used a slightly different syscall invocation to get random data from the system that should work just as well or even better than the previous one. The problem is that AMD fucked up the built-in RNG in their cheaper lines of processors, resulting in deterministic results, which causes filename(?) collisions somewhere and prevents suspend from working.
Don't blame them for things that they haven't done; you just make yourself look silly and make the systemd folks less willing to listen to criticism. Blame them for things they've actually done. For example - it looks like systemd relies on a random function always returning a different result in each invocation in its suspend subroutine.
-
@Cursorkeys said in WTF Bites:
tldr: They re-implimented randomness themselves and broke it
Where they is AMD, the CPU maker.
Newer CPUs have an instruction to generate random number, RDRAND. However on some AMD chips it stops working after suspend and resume. The reasons systemd had for trying to call the instruction directly are valid as far as compatibility concerns cause madness no matter what you do.
-
@Cursorkeys said in WTF Bites:
tldr: They re-implimented randomness themselves and broke it
No, they didn't. They just used a slightly different syscall invocation to get random data from the system that should work just as well or even better than the previous one. The problem is that AMD fucked up the built-in RNG in their cheaper lines of processors, resulting in deterministic results, which causes filename(?) collisions somewhere and prevents suspend from working.
Don't blame them for things that they haven't done; you just make yourself look silly and make the systemd folks less willing to listen to criticism. Blame them for things they've actually done. For example - it looks like systemd relies on a random function always returning a different result in each invocation in its suspend subroutine.
It is their fault they are using a non-standard way of getting randomness. Why not use getrandom() like everyone else? Their argument against getrandom() doesn't hold any water either, it's never going to have less entropy than RDRAND. If it's the blocking behaviour that's a genuine problem then they can call it as non-blocking.
Where they is AMD, the CPU maker.
Newer CPUs have an instruction to generate random number, RDRAND. However on some AMD chips it stops working after suspend and resume. The reasons systemd had for trying to call the instruction directly are valid as far as compatibility concerns cause madness no matter what you do.Sure, compatibility is a constant pain. But I don't agree with their reasons. This is wheel-reinventing biting them in the ass again.
-
@Cursorkeys said in WTF Bites:
@Cursorkeys said in WTF Bites:
tldr: They re-implimented randomness themselves and broke it
No, they didn't. They just used a slightly different syscall invocation to get random data from the system that should work just as well or even better than the previous one. The problem is that AMD fucked up the built-in RNG in their cheaper lines of processors, resulting in deterministic results, which causes filename(?) collisions somewhere and prevents suspend from working.
Don't blame them for things that they haven't done; you just make yourself look silly and make the systemd folks less willing to listen to criticism. Blame them for things they've actually done. For example - it looks like systemd relies on a random function always returning a different result in each invocation in its suspend subroutine.
No, it is 100% their fault they are using a non-standard way of getting randomness. Why not use getrandom() like everyone else? Their argument against getrandom() doesn't hold any water either, it's never going to have less entropy than RDRAND.
But it's going to pollute system logs with warnings, from what I understood.
And anyway, the real problem isn't how they're getting random numbers - it's that they're getting random numbers.
-
@Cursorkeys said in WTF Bites:
@Cursorkeys said in WTF Bites:
tldr: They re-implimented randomness themselves and broke it
No, they didn't. They just used a slightly different syscall invocation to get random data from the system that should work just as well or even better than the previous one. The problem is that AMD fucked up the built-in RNG in their cheaper lines of processors, resulting in deterministic results, which causes filename(?) collisions somewhere and prevents suspend from working.
Don't blame them for things that they haven't done; you just make yourself look silly and make the systemd folks less willing to listen to criticism. Blame them for things they've actually done. For example - it looks like systemd relies on a random function always returning a different result in each invocation in its suspend subroutine.
It is their fault they are using a non-standard way of getting randomness. Why not use getrandom() like everyone else?
Because, as they state, getrandom() may not have been properly seeded yet at that point.
-
Because, as they state, getrandom() may not have been properly seeded yet at that point.
If that's genuinely a problem then you ask getrandom() to be non-blocking, check the response and then seed urandom yourself from random. I've done this on an embedded device where urandom took bloody ages sometimes. I'm not sure if they need crypto-hard randomness, I can't quite work out what they're doing with the random number.
-
@Tsaukpaetra said in WTF Bites:
@pie_flavor said in WTF Bites:
The top apps in the entire store right now.
Strange. My list is different...
Because yours has even numbered entries as well. And #5.
@pie_flavor said in WTF Bites:
The top apps in the entire store right now.
-
Newer CPUs have an instruction to generate random number, RDRAND. However on some AMD chips it stops working after suspend and resume.
-
@Cursorkeys said in WTF Bites:
I'm not sure if they need crypto-hard randomness, I can't quite work out what they're doing with the random number.
They're doing random stuff.
Some of which is issuing nonces for low-level networking operations which need to be resistant to network-level attack, and so yes, do need to be crypto-hard.
-
@Cursorkeys said in WTF Bites:
Because, as they state, getrandom() may not have been properly seeded yet at that point.
If that's genuinely a problem then you ask getrandom() to be non-blocking, check the response and then seed urandom yourself from random. I've done this on an embedded device where urandom took bloody ages sometimes. I'm not sure if they need crypto-hard randomness, I can't quite work out what they're doing with the random number.
You've got it badly mixed up. It is random that can take ages, not urandom. Urandom is the one that does not block and gives you pseudo-random data.
-
@Cursorkeys said in WTF Bites:
Because, as they state, getrandom() may not have been properly seeded yet at that point.
If that's genuinely a problem then you ask getrandom() to be non-blocking, check the response and then seed urandom yourself from random. I've done this on an embedded device where urandom took bloody ages sometimes. I'm not sure if they need crypto-hard randomness, I can't quite work out what they're doing with the random number.
You've got it badly mixed up. It is random that can take ages, not urandom. Urandom is the one that does not block and gives you pseudo-random data.
Oops, yes that's what I meant.
-
@Cursorkeys … and systemd uses urandom as well, but it does so through the getrandom function, which, unlike the device, waits for the pool to be at least initialized.
The “correct” solution here is to simply rely on the kernel to initialize it using the
RDRANDinstruction very early or on first call if possible and leave all dealing with CPU bugs to that one place. That's when compatibility comes into the picture—apparently they didn't want to rely on the kernel being new enough and being built with appropriate flag. Which unfortunately makes sense, because updating systemd on some special-purpose distributions is much easier than updating kernel there (usually these things have some customized drivers and the vendor-provided patches are unlikely to work for too many versions).
-
and systemd uses urandom as well, but it does so through the getrandom function, which, unlike the device, waits for the pool to be at least initialized.
TIL, I assumed as it can block unless you give it a flag it used random not urandom. I guess it must work out what it thinks the current entropy is or something similar, I'll have to look that up.
The “correct” solution here is to simply rely on the kernel to initialize it using the RDRAND instruction very early or on first call if possible and leave all dealing with CPU bugs to that one place. That's when compatibility comes into the picture—apparently they didn't want to rely on the kernel being new enough and being built with appropriate flag. Which unfortunately makes sense, because updating systemd on some special-purpose distributions is much easier than updating kernel there (usually these things have some customized drivers and the vendor-provided patches are unlikely to work for too many versions).
So getrandom with the non-blocking flag, and then just drop to straight /dev/urandom if you get EAGAIN would be suitable for the vast majority of uses I guess.
If you need cryptographic randomness then getrandom isn't suitable anyway, as the entropy could have dropped too low even after the pool is initialised?
-
@Cursorkeys said in WTF Bites:
If you need cryptographic randomness then getrandom isn't suitable anyway as the entropy could have dropped too low even after the pool is initialised?
You use the system random source to initialise your own RNG (mersenne twister or something like that) with decent properties. You can take a bit of time over that.
-
@Cursorkeys said in WTF Bites:
So getrandom with the non-blocking flag, and then just drop to straight /dev/urandom if you get EAGAIN would be suitable for the vast majority of uses I guess.
getrandomis, according to the documentation, equivalent to reading from either/dev/randomor/dev/urandomdepending on whether you give it theGRND_RANDOMflag, except it will wait for the pool to be initialized during boot, which reading from/dev/urandomwon't. However if the pool is not yet initialized,/dev/urandomwill give you zeroes or something like that, so you do want to wait for the initialization and using theRDRANDinstruction is the only useful alternative early during boot—if it wasn't broken on AMD.
-
-
@Cursorkeys said in WTF Bites:
If you need cryptographic randomness then getrandom isn't suitable anyway as the entropy could have dropped too low even after the pool is initialised?
You use the system random source to initialise your own RNG (mersenne twister or something like that) with decent properties. You can take a bit of time over that.
The system is already running a CSPRNG, so there is no need. The documentation says urandom is good enough for session keys and generally most use-cases and it will never block once the generator was initially seeded.
Update: there is one exception mentioned in the documentation. If you want to be sure you have enough randomness for RSA or DH private key, you should draw a sufficient number of bits for the effective key size from random and extend it to the actual key size with your own CSPRNG, because with the system one in urandom you can't specify minimum entropy and getting entropy for all the length of RSA key is overkill.
-
The system is already running a CSPRNG, so there is no need.
The heart of the problem is that some hardware is just broken, yet the kernel is assumed to not be helpful in interfacing with the hardware, and the time when this needs to occur is sufficiently early in system operation that the usual fallbacks are mostly inoperative. The right thing to do is to make the system hang on that hardware; it's a hardware/kernel bug. The owners of the hardware can then take appropriate steps (such as upgrading the kernel to a version with appropriate mitigations).
-
@dkf Yes, it should be left to kernel to learn to use the instruction where possible and deal with any hardware-specific breakage. It's kernel's job to keep track of which hardware is broken.
… just another case of road to hell paved with good intentions. They had a completely well-intended idea to improve the start-up time in some cases, and got themselves bogged down in hardware bugs.
-
@Bulb Yeah. I find it hard to blame them in this instance. You can't really write code assuming that certain instructions won't do what they should do.
In this case, the CPU even has to advertise that it supports the
RDRANDinstruction. At that point, it seems quite sensible to assume that it indeed does so. So, if their claims are correct, this WTF seems to be on AMD.
-
One of our clients has a HR person that uses shitty software to design shitty things to hang up or hand out, etc. Cricut design software. Which is a website, that has an installed component that it works with on the client machine, that updates constantly and needs admin credentials to do so. Since she is not the type of person we would ever consider giving local admin to, this means she submits a ticket to update the shitty software almost weekly.
Over the weekend we received a ticket to update the software.
"once again it is asking for a user name and password to update and allow me to use my device. Is there anyway you can set it so it always allows updates from this site? I need to work on stuff for my daughter's graduation this weekend and this has me at a stand still.So my guys did exactly what they should have done, they ignored it. It was not work related, it was the weekend where the rate is higher, so they kicked the can until Monday.
So she makes a slight fuss about it. Copied me on the email she sent to the owner, claiming she needed it to get work stuff done over the weekend.
Side note: I have no idea why she does this sort of stuff. He is a good friend of mine, we were actually trap shooting on Saturday when the ticket came in. I showed him and he already knew about it.
So I replied all, inserted a screen shot of the ticket where she said she needed it for personal stuff. That was two hours ago and still nothing. I assume we can close this ticket.
Get everything you can in writing, cover your ass, because there is always someone out there ready to throw you under the bus and sometimes for no real reason.
-
You can't really write code assuming that certain instructions won't do what they should do.
But you totally can assume that random number generator, no matter how random, WILL generate duplicates from time to time. That they're even using random numbers in any way in the suspend procedure - and even worse, break on repeated random numbers - is inexcusable.
-
So either he's never posted outside the garage, or NodeBB is too stupid to filter before paginating
The page count and page size could be cross referenced with the number of results shown to determine how many posts a user has made in areas that I don't have access to.
Step 3 is profit.
-
But you totally can assume that random number generator, no matter how random, WILL generate duplicates from time to time. That they're even using random numbers in any way in the suspend procedure - and even worse, break on repeated random numbers - is inexcusable.
First off: I don't particularly disagree. But ... from what I understood, they were using the random numbers to generate a GUID. I didn't look at the code or anything, so I don't particularly feel like I can judge whether or not using GUIDs is a WTF (though I agree with your argument on that part to some degree). As for breaking on duplicate GUIDs ... if nothing else, they are probably in good company with a lot of software out there. The basic premise of GUIDs is pretty much that the chance of generating duplicates is negligible.
-
from what I understood, they were using the random numbers to generate a GUID.
You can generate GUIDs without randomness. Moreover - generating them without randomness actually guarantees that they'll always be unique.
As for breaking on duplicate GUIDs ... if nothing else, they are probably in good company with a lot of software out there.
Yes, I realize almost entirety of our industry sucks hard. But that's a shitty excuse.
-
@Cursorkeys said in WTF Bites:
@Cursorkeys said in WTF Bites:
tldr: They re-implimented randomness themselves and broke it
No, they didn't. They just used a slightly different syscall invocation to get random data from the system that should work just as well or even better than the previous one. The problem is that AMD fucked up the built-in RNG in their cheaper lines of processors, resulting in deterministic results, which causes filename(?) collisions somewhere and prevents suspend from working.
Don't blame them for things that they haven't done; you just make yourself look silly and make the systemd folks less willing to listen to criticism. Blame them for things they've actually done. For example - it looks like systemd relies on a random function always returning a different result in each invocation in its suspend subroutine.
No, it is 100% their fault they are using a non-standard way of getting randomness. Why not use getrandom() like everyone else? Their argument against getrandom() doesn't hold any water either, it's never going to have less entropy than RDRAND.
But it's going to pollute system logs with warnings, from what I understood.
And anyway, the real problem isn't how they're getting random numbers - it's that they're getting random numbers.
If you've ever asked yourself why anything related to hardware (and suspending, in this case) only works some of the time, I guess that's the answer.
-
@Tsaukpaetra said in WTF Bites:
@pie_flavor said in WTF Bites:
The top apps in the entire store right now.
Strange. My list is different...
Because yours has even numbered entries as well. And #5.
@pie_flavor said in WTF Bites:
The top apps in the entire store right now.
You mean... The numbers actually mean something??!? I thought it was just for show!
-
As for breaking on duplicate GUIDs ... if nothing else, they are probably in good company with a lot of software out there.
The thing that makes it worse is that it's THE INIT SYSTEM
Double-sided printing data ballsup leaves insurance giant Chubb with egg on its face
