|
Xarn posted:Good thing you use CI and the commit never made it anywhere important. when interviewing for a team, make sure "we use CI" doesn't have an asterix (e.g. "we use CI for the BUILD process itself, but we wrote our own bespoke installer for the product using thousands of lines of powershell which doesn't use CI because it takes TOO LONG to create the installer for it to use CI")
|
#
?
May 3, 2021 13:58
|
|
|
|
| # ? May 25, 2024 08:10 |
|
|
LOOK I AM A TURTLE posted:Functioning link: https://engineering.virginia.edu/news/2021/04/defenseless-uva-engineering-computer-scientists-discover-vulnerability-affecting i'd prefer the government just put something in the water to make people too stupid to use this vulnerability properly rather than have another round of spectre "patches" which are really "let's just make current generation cpus perform worse to mitigate attacks that sound cool but haven't really exploited in the wild even to this day."
|
|
#
?
May 3, 2021 14:02
|
|
|
Obfuscation posted:I've always thought that git commit messages should be like mini-branches in themselves, so you could push changes to old commit messages if a need arises Silly me for assuming all these years that max was just an alias for the largest number you can use in the column spec
|
|
#
?
May 3, 2021 19:29
|
|
|
xtal posted:It seems plainly intuitive that you can't have speculative execution that's worth anything without also leaking data on side channels
|
|
#
?
May 3, 2021 21:11
|
|
|
Are you that confident that nobody can build a timing oracle based on whether or not speculatively-executed code is competing for the memory bus at all?
|
|
#
?
May 4, 2021 05:33
|
|
|
Jabor posted:Are you that confident that nobody can build a timing oracle based on whether or not speculatively-executed code is competing for the memory bus at all? The simplest answer is that you could block speculative code from touching memory at all, and it would still be much better than not speculating. I briefly considered memory contention earlier but mostly categorized it as a problem that'll exist even without speculation. Maybe that was too hasty. I could also see some timing trick with execution ports but having the right scheduling priorities can make each new speculation invisible to previous code.
|
|
#
?
May 4, 2021 09:56
|
|
|
The NASDAQ broke because Berkshire Hathaway stock got too expensive to fit in a 32 bit integer https://markets.businessinsider.com/news/stocks/warren-buffett-berkshire-hathaway-stock-price-near-maximum-allowed-nasdaq-2021-5-1030397626 
repiv fucked around with this message at 22:44 on May 6, 2021 |
|
#
?
May 6, 2021 22:41
|
|
|
|
|
#
?
May 7, 2021 03:29
|
|
|
sorry warren, 2000 is what it says on the screen
|
|
#
?
May 7, 2021 07:08
|
|
|
I remember reading stories about Warren Buffet never wanting to split the Berkshire Hathaway stock, I would never have guessed this is what he had in mind.
|
|
#
?
May 7, 2021 07:59
|
|
|
I would blow Dane Cook posted:I remember reading stories about Warren Buffet never wanting to split the Berkshire Hathaway stock, I would never have guessed this is what he had in mind. Some people just want to watch the world burn
|
|
#
?
May 7, 2021 11:02
|
|
|
I wonder how long before it happened the people at Nasdaq realised this was going to be a problem Cause that article says it's about to happen. So it was clearly anticipated by some people before it actually happened. But if they'd anticipated it in good time they wouldn't actually be bumping up against the limit and crunching to get a fix out. I wonder who sent an email saying "uh, do you realise..." and when
|
|
#
?
May 7, 2021 11:26
|
|
|
I have no idea what the NASDAQ runs on but I imagine it's bespoke, ancient and involves a mainframe of some kind. Probably a pain in the arse to fix this one.
|
|
#
?
May 7, 2021 16:20
|
|
|
I wonder if they're pleading with Buffet to just split the drat stock so they don't have to do a massive system overhaul just for the sake of his company
|
|
#
?
May 7, 2021 16:27
|
|
|
Buffet overflow.
|
|
#
?
May 7, 2021 16:43
|
|
|
Ola posted:Buffet overflow. 
|
|
#
?
May 7, 2021 17:19
|
|
|
I would blow Dane Cook posted:I have no idea what the NASDAQ runs on but I imagine it's bespoke, ancient and involves a mainframe of some kind. Probably a pain in the arse to fix this one. It's also about the protocols used by all the connected trading systems, like the margin traders who optimize for CPU cycles to beat out competitors in buying and selling.
|
|
#
?
May 7, 2021 17:21
|
|
|
I would blow Dane Cook posted:I have no idea what the NASDAQ runs on but I imagine it's bespoke, ancient and involves a mainframe of some kind. Probably a pain in the arse to fix this one. They use 32-bit integers and not like 8-digit decimals or something so it can't be anything too strange?
|
|
#
?
May 7, 2021 18:49
|
|
|
OddObserver posted:They use 32-bit integers and not like 8-digit decimals or something so it can't be anything too strange? That doesn't mean it would be easy to change. No telling how many places in that codebase just assume price is always a uint32.
|
|
#
?
May 7, 2021 18:54
|
|
|
We also get to see who's still on a system that can't handle the 2k38 bug.
|
|
#
?
May 7, 2021 21:15
|
|
|
They are *definitely* doing something horrible like packing stock ID, price, timestamp, and flags into four 32-bit words for maximum performance. All the data you "need" in sixteen bytes on the wire, which is conveniently also an even fraction of an x86 cache line.
|
|
#
?
May 7, 2021 21:27
|
|
|
Gotta go fast. It'd be absolutely hilarious if this ends up wrecking high frequency traders, but given that NYSE isn't reported to have a similar issue, I'd be surprised if it does.
|
|
#
?
May 7, 2021 22:21
|
|
|
Knocking 4 bytes off a 16 byte message that you’re going to transmit a few billion times a second is pretty good, actually. The wire format should handle larger numbers gracefully, just like it presumably handles irregular messages like new/halted/removed listings, but it’s weird to act like this is some crazy optimization.
|
|
#
?
May 8, 2021 00:24
|
|
|
even if the wire format is specced to handle larger numbers in some way, if this is the first time it's come up there's a good chance a lot of the actual implementations won't do it correctly
|
|
#
?
May 8, 2021 00:25
|
|
|
I think we're on our second "uh oh, gonna run out of ints in the database " problem at work, I can't remember if this time we're running out of negative ints because the "fix" the first time was to use those.
|
|
#
?
May 8, 2021 00:28
|
|
|
The real answer is that this hasn't been required in the past and technical debt isn't covered by any particular business unit/team so why would anyone have used their budget to bankroll it's development.
|
|
#
?
May 8, 2021 00:30
|
|
|
also it's only a problem because warren buffett is stubborn, as far as i can tell no other stock is even remotely close to the limit maybe their plan was to hope buffett died before it became a problem
|
|
#
?
May 8, 2021 00:32
|
|
|
It's entirely reasonable for NASDAQ to have a well defined minimum, maximum, and resolution for prices in their system. Requiring arbitrary precision math everywhere would probably not have made a more reliable system. Making prices be a count of # of $0.0001 so that the expressible price range is $0 to $429,496.73 seems like a defensible choice for a practical system. If I were in charge of NASDAQ, I would be tempted to just say "We're not going to allow a contract on our exchange with a higher per-share price. Split to make your price cheaper or accept a price limit". Like they already don't allow a pricing things in $0.00005 increments.
|
|
#
?
May 8, 2021 01:41
|
|
|
Foxfire_ posted:If I were in charge of NASDAQ, I would be tempted to just say "We're not going to allow a contract on our exchange with a higher per-share price. Split to make your price cheaper or accept a price limit". Like they already don't allow a pricing things in $0.00005 increments. but that would make one rich person feel bad
|
|
#
?
May 8, 2021 07:02
|
|
|
rjmccall posted:Knocking 4 bytes off a 16 byte message that you’re going to transmit a few billion times a second is pretty good, actually. So I learned something recently. File attachments in e-mails are just base-64 encoded since e-mails were originally specced to just send texts, and can't deal with non-printable ASCII characters. Apparently early pdf came up with a base-85 or something encoding for pdf attachments in mail. That works, there's plenty of printable ASCII characters to deal with that. Conversion is rather annoying because you got 6-and-a-fraction bits per character but you can make it work. And it reduces the final e-mail size. Until it turned out that these additional ASCII characters got hosed up if the e-mail went through any EBCDIC system along the way and the entire pdf got corrupted. When that was realized, e-mail client coders decided to base-64 encode the base-85 encoded pdf which means you lose all benefits and worse. That's when Adobe decided to get rid of the base-85 encoding scheme.
|
|
#
?
May 8, 2021 07:45
|
|
|
Carbon dioxide posted:So I learned something recently. I guess it's a matter of perspective, because I'd say that base85 is easier to convert. It does 4 bytes at a time and uses a contiguous block of 85 characters. To me, that more than makes up for having to multiply and divide instead of shift left and right.
|
|
#
?
May 8, 2021 11:16
|
|
|
Dylan16807 posted:I guess it's a matter of perspective, because I'd say that base85 is easier to convert. It does 4 bytes at a time and uses a contiguous block of 85 characters. To me, that more than makes up for having to multiply and divide instead of shift left and right. Ah yes, that works. I hadn't looked up those specifics.
|
|
#
?
May 8, 2021 12:08
|
|
|
redleader posted:but that would make one rich person feel bad If they extend the system to support prices higher than the current maximum but introduce a bug which fucks everything up, that could lead to many rich people feeling bad. So even if their sole objective is to keep the rich people happy, they might be better off telling Warren Buffet no.
|
|
#
?
May 8, 2021 12:48
|
|
|
not allowed to link to third party files or upload a file? no problem! 
|
|
#
?
May 8, 2021 15:26
|
|
|
Biowarfare posted:not allowed to link to third party files or upload a file? no problem! That's brilliant. And I even use the data scheme sometimes in the address bar to test some little html thing, so I have no excuse for not thinking of using it in a script element!
|
|
#
?
May 8, 2021 16:52
|
|
|
Biowarfare posted:not allowed to link to third party files or upload a file? no problem! Walk me through this like I'm a little baby (because I am in this context, I don't do web dev).
|
|
#
?
May 8, 2021 17:48
|
|
|
Absurd Alhazred posted:Walk me through this like I'm a little baby (because I am in this context, I don't do web dev). Somebody needed to add a bit of javascript to a web page for click tracking or something. The classic way to do this, dating back to Netscape Navigator, is to just throw some JS on the page wrapped up in script tags. But, that's frequently blacklisted with content security policies these days, because writing script tags to the page is the source of most cross-site scripting vulnerabilities. So, normally, what you'd do there is just put in a script tag that refers to an external file hosted in a CDN somewhere, and whitelist your approved script sources in the content security policy*. But, the dev here is not allowed to modify the main source bundle for the page or upload any new files to the approved script-storage-place. They're just allowed to edit the HTML or whatever template generates it, I guess. So, no good way to add the script they need. But! They can define a URL for whatever external source they want. And, there's a way to specify a URL with the "data" schema that basically tells the client "actually, this isn't a network resource, here's the data for the response right here." It's pretty common for things like loading up some 32x32 pixel PNG, where it's more performant to just include a base64-encoded version of the file than it is to run a whole new network request. And, although you'd normally see something like base64 in that data schema, you can totally also pass in a javascript file. So - put a script tag on the page, tell it that it's coming from an external source, but then have that "external source" be a URL that just wraps the embedded source you needed to use in the first place. *something which was not done here - they just blacklisted on-page script tags, I think
|
|
#
?
May 8, 2021 18:09
|
|
|
Space Gopher posted:Somebody needed to add a bit of javascript to a web page for click tracking or something. Oh, wow! That's interesting. Thanks!
|
|
#
?
May 8, 2021 18:24
|
|
|
pokeyman posted:That's brilliant.
|
|
#
?
May 8, 2021 18:31
|
|
|
|
| # ? May 25, 2024 08:10 |
|
|
Why can't you just inline the script like normal?
|
|
#
?
May 8, 2021 21:53
|
|
