WTF Bites
-
-
@Benjamin-Hall said in WTF Bites:
@hungrier wait, a tire store has lawn products?
In my area it seems to be very common for gas stations to sell landscaping products -- they have bags of mulch and topsoil stacked on pallets. Lots and lots of pallets. Seems really weird, but there it is.
-
Microsoft Active Domain can generate an X509 certificate and distribute it to all the hosts in the domain, so you can use it for signing certificates for intranet servers and they'll be trusted by the company machines, and for signing e-mail. There is a very simple web form (called “Active Directory Certificate Services”) where you can post a signing request, select whether it is for e-mail or server (I think the former is automatic based on logged in user, the later needs admin approval) and get a signed certificate back.
Ok, so I am interacting with the instance in our intranet. And even though my browser normally accepts the certificate, the site is untrusted. So I try
openssl s_client -showcerts -servername dc-123.comp.company.com -connect dc-123.comp.company.com:443 </dev/null CONNECTED(00000003) depth=0 verify error:num=26:unsupported certificate purpose verify return:1 depth=1 DC = com, DC = company, DC = comp, CN = Company-Root-CA verify return:1 depth=0 verify return:1 …
Do I see correctly that it's trying to use the root certificate directly for encrypting the channel? Obviously the CA certificate, being proper CA certificate, does not list server authentication among its purposes…I am just not sure whether this is Microsoft fault or just fault of the admins here who don't seem to understand PKI that well.
-
Do I see correctly that it's trying to use the root certificate directly for encrypting the channel?
Hopefully it's an "Opps, clicked the wrong thing" problem.
-
@Tsaukpaetra said in WTF Bites:
Hopefully it's an "
Opps,OPS clicked the wrong thing" problem.
-
Status: Guess what happens when I pass a null object to a function with the description:
Checks to see if the target variable is empty/null.If you guess "Returns false", congrats! You won!
-
Coin shop is new!
Oh and also we're closing it.
Darn, and just when I finally got enough for a shit game...
-
-
@TimeBandit said in WTF Bites:
@Tsaukpaetra said in WTF Bites:
Darn, and just when I finally got enough for a shit game...
You have almost enough for a almost-maybe-not-shit-but-is-still-shit game.
-
@Tsaukpaetra said in WTF Bites:
You have almost enough for a
almost-maybe-not-shit-but-is-still-shitfree to play game.FTFY
That's what I can currently buy
-
@TimeBandit said in WTF Bites:
@Tsaukpaetra said in WTF Bites:
You have almost enough for a
almost-maybe-not-shit-but-is-still-shitfree to play game.FTFY
That's what I can currently buy
That is all I got too apparently.
Sad, would have thought more would be available. Oh well.
-
@Tsaukpaetra said in WTF Bites:
would have thought more would be available.
More were available on May 29, when the last set of games went up. Then, with the writing on the wall, everyone who was there that day just spent what they had left. Including me.
-
WTF Status: I needed to briefly go somewhere. At 8:50am I paid for a parking ticket for 30 minutes. I look at the ticket and it says parking ends at 9:06, starting time apparently was 8:36.
Are you seriously telling me the clocks on the ticket machines are wrong?!
-
Syncing clocks is hard, let's go fining people!
-
Are you seriously telling me the clocks on the ticket machines are wrong?!
I always thought it was a simple countdown timer, but since I've never been to a place that requires their usage I have no actual experience.
-
@Tsaukpaetra said in WTF Bites:
Are you seriously telling me the clocks on the ticket machines are wrong?!
I always thought it was a simple countdown timer, but since I've never been to a place that requires their usage I have no actual experience.
That would require a meter for every single parking spot.
Over here, you have one or two in the street that print a little paper slip you post behind your wind shield.
-
@topspin
pfff soooo 1990s. around here you buy time through an app, sms or one of those physical things in the street. The paper slip is 100% optional. Parking enforcers drive around on a moped with ANPR cameras on and just slap the cars that are not registered in their system.
-
@Luhmann way too advanced.
-
@dkf Just wanted to add, C++20 now has
std::assume_aligned, though library and compiler support is currently still WIP.
-
@LB_ That'll be implemented as a wrapper around
__builtin_assume_aligned()(because why wouldn't they do it that way?) and it will have all the weirdness thereof. I still think that the Right Thing would be to have it be a property of the type, and not part of the provenance of a particular value. Instead, we're going to have the stupid way of doing things inflicted upon us for decades.The thing that amuses me most of all is that after I was probing around with alignment trying to get something working efficiently using alignment in one part of my code, it happened to utterly save me elsewhere (a different repository, a very different part of the code) a few days later. (Knowing this stuff does seem to cement me as the team's low-level C magician.)
-
@Tsaukpaetra said in WTF Bites:
Status: Guess what happens when I pass a null object to a function with the description:
Checks to see if the target variable is empty/null.If you guess "Returns false", congrats! You won!
Depends. If it returns something other than false for non-null, then the description is accurate, but inverted and therefore non-PoLA. If it returns false for everything, then the description is incomplete. It should be extended to:
Checks to see if the target variable is empty/null, but doesn't tell you what it found out.And yes, before you say it, that is a serious
...
-
@Tsaukpaetra said in WTF Bites:
Are you seriously telling me the clocks on the ticket machines are wrong?!
I always thought it was a simple countdown timer, but since I've never been to a place that requires their usage I have no actual experience.
It varies, both across places and across time. It used to be the case in places I've lived that a parking meter was indeed one-per-spot with a little clockwork countdown timer operated by the coin(s), but these days even in the same place you're likely to find a single ticket-printing machine serving multiple spots in a "pay and display" mode.
-
Dunno if this has been posted already:
Wallpaper crash explained: Here’s how a simple image can soft-brick phones
An Android developer explains the weird wallpaper crush bug that causes endless Samsung and Google devices to become unusable without a factory reset.
-
https://twitter.com/MishaalRahman/status/1267940360967327746 said in WTF Bites:
any exception in SysUI is treated as fatal, leading to an infinite loop of crashes because the image gets processed every time SysUI starts
An essential component like this should show some fault-tolerance.
The correct fix isn't to fix the rounding or clamp it or whatever, the correct fix is to add the damn exception handling around the wallpaper loading and if it fails, set the background to solid black or blue or something that is reliable. That way any background that triggers any other bug will simply get not loaded and the software will continue working. Because the things that needs fixing the most is not loading of this particular background, it is the possibility that attempt to load a background with some unexpected feature will send the phone to a boot loop.
-
@Bulb yes quite, loading the background is not a system critical thing and should not be in the low level system code that gets treated this way.
-
Plus, apparently that bug had been reported to Google two years ago.
-
@bobjanova said in WTF Bites:
@Bulb yes quite, loading the background is not a system critical thing and should not be in the low level system code that gets treated this way.
The background loading is where needs to be, in the application that shows the main UI. It is analogous to window manager in X-windows or explorer (showing the panel and desktop icons) in Windows. It has to be there for the system to be usable, but it is not a low-level code in any sense.
The problem is that it rather does not get treated as system code. If it was, it would catch the exception and skip loading the background, showing solid color or revert to last known good configuration or switch to some very minimal configuration like Windows go into the safe mode… anything but get stuck in a boot loop.
-
Knowing this stuff does seem to cement me as the team's low-level C magician.
I've been writing C for >35 years, and I consider you a low-level C magician.
-
Do you mean low-level-C magician, or low-level C-magician?
-
@Zerosquare He's a high level low level magician!
-
-
I still think that the Right Thing would be to have it be a property of the type, and not part of the provenance of a particular value.
Me too.
I still hate whatever C++ decision made type
alignas()invalid in type aliases / typedefs. You can put it on a custom type, but you can't e.g. typedef an over-aligned float. (You can of course create a franken-float that behaves almost like a float but is a custom type, but that's a bit too much insanity even for my taste.)
-
@cvi might have something to do with typedefs not being strong. Or not, I don’t know.
The problem @dkf is solving is under-aligned types, though, not sure ifalignascan do that at all.
-
@Steve_The_Cynic said in WTF Bites:
@Tsaukpaetra said in WTF Bites:
Status: Guess what happens when I pass a null object to a function with the description:
Checks to see if the target variable is empty/null.If you guess "Returns false", congrats! You won!
Depends. If it returns something other than false for non-null, then the description is accurate, but inverted and therefore non-PoLA. If it returns false for everything, then the description is incomplete. It should be extended to:
Checks to see if the target variable is empty/null, but doesn't tell you what it found out.And yes, before you say it, that is a serious
...It returns false for everything, unless the object is first cast to (one of a set of) a specific type.
I don't even know why you would do something like this.
-
said in WTF Bites:
any exception in SysUI is treated as fatal, leading to an infinite loop of crashes because the image gets processed every time SysUI starts
An essential component like this should show some fault-tolerance.
The correct fix isn't to fix the rounding or clamp it or whatever, the correct fix is to add the damn exception handling around the wallpaper loading and if it fails, set the background to solid black or blue or something that is reliable. That way any background that triggers any other bug will simply get not loaded and the software will continue working. Because the things that needs fixing the most is not loading of this particular background, it is the possibility that attempt to load a background with some unexpected feature will send the phone to a boot loop.
Yeah, I know in my phone if the Live Wallpaper crashes it immediately sets it to the background that came with the ROM.
Which is funny because the only time this happens is when it gets OOM killed.
-
might have something to do with typedefs not being strong. Or not, I don’t know.
Yeah, IIIRC that's the underlying argument. (Strong typedefs would be another nice thing, though.)
The problem @dkf is solving is under-aligned types, though, not sure if alignas can do that at all.
No, I don't think there's any legal standardized way of decreasing alignment (the most portable suggestion tends to be
memcpy()or equivalent, but that sucks if you want any control over the number of writes or similar).
-
@Zerosquare said in WTF Bites:
Do you mean low-level-C magician, or low-level C-magician?
In any case, not a low level-C magician.
-
@Zerosquare said in WTF Bites:
Do you mean low-level-C magician, or low-level C-magician?
I think it's a quantum mechanical thing, and depends on what I'm observed to do. For the most part, I prefer to use the @boomzilla approach of
I'm not the lowest level person on the team, FWIW, but everyone lower level than me either makes hardware or, more scarily, one guy in particular prefers to write assembler because then you can count cycles exactly and poll the hardware at exactly the right rate rather than wasting time on interrupts. And also save memory by using the stack pointer as a general register. He's not particularly good at anything much higher level than that unless it involves intense numerics. I can read his code, but no way will I edit it…
-
the most portable suggestion tends to be
memcpy()or equivalent, but that sucks if you want any control over the number of writes or similarWhen
memcpy()(which is typically implemented with lots of compiler magic) is able to figure out that it has good alignments for destination, source, and length, it will often become really good code. Unfortunately, when that testing fails for some reason, it instead becomes something truly horrible. I still don't know how it is even possible to use close to 300 bytes on a copy routine when a perfectly serviceable version could be done in so much less than that.I probably ought to update our toolchain to spew warnings if memcpy ends up being linked into the final build of our code. (Alas, that involves writing Perl and I think I've done my quota of that for this decade…)
-
When
memcpy()(which is typically implemented with lots of compiler magic) is able to figure out that it has good alignments for destination, source, and length, it will often become really good code. Unfortunately, when that testing fails for some reason, it instead becomes something truly horrible. I still don't know how it is even possible to use close to 300 bytes on a copy routine when a perfectly serviceable version could be done in so much less than that.If you can't intrinsic-inline
memcpy()as four instructions(1) on x86 or x64 (the same - aside from register size - four instructions in both cases, no less), you're doing something very, very wrong.mov esi,[source] mov edi,[dest] mov ecx,[length] rep movsbUse rsi, rdi, rcx on x64.
(1) Not necessarily the fastest possible instructions, but very, very simple, and for shortish blocks, quite possibly faster than anything more "optimised"....
-
@Zerosquare said in WTF Bites:
Do you mean low-level-C magician, or low-level C-magician?
I think it's a quantum mechanical thing, and depends on what I'm observed to do. For the most part, I prefer to use the @boomzilla approach of
I'm not the lowest level person on the team, FWIW, but everyone lower level than me either makes hardware or, more scarily, one guy in particular prefers to write assembler because then you can count cycles exactly and poll the hardware at exactly the right rate rather than wasting time on interrupts. And also save memory by using the stack pointer as a general register. He's not particularly good at anything much higher level than that unless it involves intense numerics. I can read his code, but no way will I edit it…
Wait, Mel hasn't retired yet?
-
@Steve_The_Cynic On the newer/larger ARM processors you can do the same sort of thing. But the older/smaller end of the range is more finicky, and benefits very very much from using the right kind of data movement instructions. But I still can't get from that to the actual size of
memcpy()with any ease (and I'm not including setting up the argument registers in that count).
-
Wait, Mel hasn't retired yet?
The world still has its Mels about. They write firmware for various weird bits of equipment that you probably spend your days ignoring…
-
@Tsaukpaetra said in WTF Bites:
if the Live Wallpaper crashes
This is
in all this. Live Wallpaper? is that about? It's the pretty coloured thing behind all the icons, right? What are you doing there, running Leo Christopherson's Dancing Demon(1) or something?
-
more scarily, one guy in particular prefers to write assembler because then you can count cycles exactly
Yeah, I know enough to understand how to do that, but there's no way I'd go back to actually doing so. Definitely scary stuff, and x86 isn't even vaguely amenable to it ever since the 386 got going. (Hell, these days, you don't even know what order the instructions will happen in, much less how much time they'll take or even how long a cycle is.)
-
@Steve_The_Cynic said in WTF Bites:
When
memcpy()(which is typically implemented with lots of compiler magic) is able to figure out that it has good alignments for destination, source, and length, it will often become really good code. Unfortunately, when that testing fails for some reason, it instead becomes something truly horrible. I still don't know how it is even possible to use close to 300 bytes on a copy routine when a perfectly serviceable version could be done in so much less than that.If you can't intrinsic-inline
memcpy()as four instructions(1) on x86 or x64 (the same - aside from register size - four instructions in both cases, no less), you're doing something very, very wrong.mov esi,[source] mov edi,[dest] mov ecx,[length] rep movsbUse rsi, rdi, rcx on x64.
(1) Not necessarily the fastest possible instructions, but very, very simple, and for shortish blocks, quite possibly faster than anything more "optimised"....
Something I learned from He Who Took Half The Forums With Him is that the legacy string instructions are now legacy-legacy, i.e. good to use again, as they are actually micro-coded to get maximum throughput for large blocks. He used a specific term for this, but I forgot.
Which actually makes a lot of sense IMO, as the semantics of these functions is pretty trivial and there already is a specialized op-code for it (which presumably has always been micro-coded anyway). And the processor designers are in a much better position to know what the perfect sequence of micro-instructions are for a specific chip than the library implementers are to figure out at what block sizes what contortions of using AVX registers or whatever is fastest for a variety of different processors. The only thing I don't get was that, iirc, the code still used something like: trivial version for very short blocks, AVX stuff for medium blocks, rep instructions for long blocks, as the special instruction had a too high warm-up overhead. Why not include that in the micro-code and make the easiest solution always the fastest?
-
@Steve_The_Cynic said in WTF Bites:
@Tsaukpaetra said in WTF Bites:
if the Live Wallpaper crashes
This is
in all this. Live Wallpaper? is that about? It's the pretty coloured thing behind all the icons, right? What are you doing there, running Leo Christopherson's Dancing Demon(1) or something?It's a star field animation.
https://android-apk.org/com.kalicinscy.wallpaper.starfield.paid/
(Apparently they disappeared from the normal Play store).
It's a tiny little app that displays stars streaking across the screen.
Typically if that crashes the phone is so dead it's going to crash itself soon enough.
-
using the stack pointer as a general register
I'm pretty sure there's a special level of Hell reserved for people that "clever." If not, there should be.
-
save memory by using the stack pointer as a general register
What about the instruction pointer?
-
@Steve_The_Cynic said in WTF Bites:
If you can't intrinsic-inline memcpy() as four instructions(1) on x86 or x64 (the same - aside from register size - four instructions in both cases, no less), you're doing something very, very wrong.
I'm trying to find a link to a discussion about the highest performance
memcpy()on x86. It rather depends on the specific CPU, or at least the various flags that it supports. Here is some discussion, though I remember there being a much more exhaustive set of tests.There is an extension in x86 for enhanced rep movsb/stosb support, except that it sucks in terms of perf in a bunch of cases. (Without the extension, it apparently just always sucks.) But the best version also depends on the size of the memory to be copied.
memcpy()is one of those things that's actually worth optimizing a lot. I would guess the rather "fat" memcpy is just selecting the best version at runtime. (Which is why it's neat if the compiler can inline a more specific version.)
