It is more of a “For typical cards, expect very competitive options from AMD. If you want top performance, buy Nvidia.”
In theory it allows them to focus more on the cards that actually get bought, and thus they could make those cards better products.
As the great operation begins.
It is a hardware failure. Screens are complex and sensitive parts that are exposed to a lot of (ab)use. What is cryptic about that?
I agree, it looks nice in my opinion. It doesn’t look like the house itself is crooked. It’s just asymmetrical furniture, which I find fun to look at!
we think you’d be best with a bigger team with a better support network
Sounds like they think you’re not independent enough for the position. If it is a small team, they might need someone who can immediately start being productive, while they think you will need more coaching to get up to speed.
No need to drag any disabilities into this.
Well, if
Then we can be quite confident that your connection is indeed encrypted!
And of course, you’re welcome!
If the timestamps line up, maybe Wireshark just doesn’t manage to understand the entire exchange. What could happen is that Wireshark sees the SSH handshake, and after that it might become just encrypted gibberish due to the encryption. In that case the SSH traffic could just show up as “some kind of TCP”.
Do you see an SSH handshake, followed by random crap on the same ports?
(I’m not a Wireshark expert, just an IT guy trying to help!)
TCP is on a lower level than SSH, usually SSH uses TCP as its underlying transport layer. TCP as such is not encrypted, but it can of course be used to transport encrypted data.
Are those packages not part of the same SSH connection according to Wireshark?
Any liquid is drinkable, some even more than once!
Am I missing something? I thought the outage was caused by CrowdStrike and had nothing to do with Microsoft or Windows?
That’s really useful to know. Thank you for sharing!
They say there are 16 screens inside, each with a 16k resolution. Such a screen would have 16x as many pixels as a 4k screen. The GPUs power those as well.
For the number of GPUs it appears to make sense. 150 GPUs for the equivalent of about 256 4k screens means each GPU handles ±2 4k screens. That doesn’t sound like a lot, but it could make sense.
The power draw of 28 MW still seems ridiculous to me though. They claim about 45 kW for the GPUs, which leaves 27955 kW for everything else. Even if we assume the screens are stupid and use 1 kw per 4k segment, that only accounts for 256 kW, leaving 27699 kW. Where the fuck does all that energy go?! Am I missing something?
Does life suck, or not?
Is it bad that I kinda do want to get high and have my fridge come over to me to fulfill the munchies without ever having to get up?
Well there is this thing called a speed limit, that is a very clear hard limit. If you go over, it is at the very least financially unsafe.
It would also be very hard to compete with products that are this mature. Linux, Windows, and macOS have been under development for a long time, with a lot of people. If you create a new OS, people will inevitably compare your new immature product with those mature products. If you had the same resources and time, then maybe your new OS would beat them, but you don’t. So at launch you will have less optimizations, features, security audits, compatibility, etc., and few people would actually consider using your OS.
That is true, but from a human perspective it can still seem non-deterministic! The behaviour of the program as a whole will be deterministic, if all inputs are always the same, in the same order, and without multithreading. On the other hand, a specific function call that is executed multiple times with the same input may occasionally give a different result.
Most programs also have input that changes between executions. Hence you may get the same input record, but at a different place in the execution. Thus you can get a different result for the same record as well.
That exact version will end up making “true” false any time it appears on a line number that is divisible by 10.
During the compilation, “true” would be replaced by that statement and within the statement, “__LINE__” would be replaced by the line number of the current line. So at runtime, you end up witb the line number modulo 10 (%10). In C, something is true if its value is not 0. So for e.g., lines 4, 17, 116, 39, it ends up being true. For line numbers that can be divided by 10, the result is zero, and thus false.
In reality the compiler would optimise that modulo operation away and pre-calculate the result during compilation.
The original version constantly behaves differently at runtime, this version would always give the same result… Unless you change any line and recompile.
The original version is also super likely to be actually true. This version would be false very often. You could reduce the likelihood by increasing the 10, but you can’t make it too high or it will never be triggered.
One downside compared to the original version is that the value of “true” can be 10 different things (anything between 0 and 9), so you would get a lot more weird behaviour since “1 == true” would not always be true.
A slightly more consistent version would be
((__LINE__ % 10) > 0)
That is what I remember too.