technically, yes
brezelradar
joined 1 year ago
I loaned a colleague's son my copy of a very introductory Unity book for a school project. Instead of a 2D game (most of the book), they ended up making a 3D version. Now he has an apprenticeship with a game company where they use Unreal.
Unity has other pros: With a decompiler you can check some of the Unity games you already own and add features you missed. Only for yourself, or in case your friends are curious, maybe release them as mods.
wipe or fake SMART data
My guess would be that it's stored in some kind of non-volatile memory, i.e. EEPROM. Not sure if anyone ever tried that, but with the dedication of some hardware hackers that seems at least feasible. Reverse engineering / overriding the HDD's firmware would be another approach to return fake or manipulated values.
I haven't seen something like that in the wild so far. What I have seen are manipulated USB sticks though: advertising the wrong size (could be tested with h2testw) or worse.
they recently decided to defederate
Hadn't thought of this one, but yeah, that explains it.
Seems like most of the answers are on another instance and my client does not show them here. For those having the same problem: check here.
Federation is fun and all, but having “the same” sub on multiple instances does not make it easier atm.
4-5 times now. When confronted with more than a hundred commits between latest known working version and the one you’ve observed the bug (which was not catched by any of the unit tests) it can save some time to find the fishy commit.
In such a case I create a testcase on top to reproduce the bug. Then bisect and for each stage add the testcase, build, run tests. FYI: this only works if all (or at least most) of the commits in the chain are compilable - if you’ve done a big messy refactoring with several commits breaking the build, bisect can get you only so far.
4-5 times now. When confronted with more than a hundred commits between latest known working version and the one you've observed the bug (which was not catched by any of the unit tests) it can save some time to find the fishy commit.
In such a case I create a testcase on top to reproduce the bug. Then bisect and for each stage add the testcase, build, run tests. FYI: this only works if all (or at least most) of the commits in the chain are compilable - if you've done a big messy refactoring with several commits breaking the build, bisect can get you only so far.
First thing to do is check SMART data to see if there are any fails. Then looking at usage hours, spin ups, pre-fails / old-age to get a general idea how worn the drive is and for how long you could make use of it depending on risk acceptance.
If there are already several clusters relocated and multiple spin up fails, I'd probably return the drive.
Apart from all the reliability stuff: I'd check the content of the drive (with a safe machine) - if it wasn't wiped you might want to notify the previous owner, so she can change her passwords or notify customers about the leak (in compliance to local regulations) etc. - even if you don't exploit that data, the merchants/dealers in the chain might already have.
some free Azure credits
That's probably not enough for a 3 node AKS (it used to be though) but even with one or two nodes having a familiar API is a plus. If you're already experience with k8s or already have an AKS for other dev/fiddle stuff, that would be the obvious solution.
I haven't even decided if I'll run lemmy or kbin. Jerry Bell is currently running both.
It's ::1, but also fe80::d00f:foo5
yup, Peopleware is from 1987