2,000,733 events, 1,124,505 push events, 1,613,087 commit messages, 100,620,178 characters
hell fucking yeah im done with this shit (not 100% sure doe)
feat: major security improvements around the apps locking/unlocking password
-
Now when you go to create a password the app only stores the sha256 hash of the password on the devices secure enclave (keychain)
-
When you enter your password to unlock the app we get the sha256 hash of the provided password and check it against the hash that is stored on the keychain
-
If the provided hash matches the keychain hash the app unlocks and starts bootstrapping Tor
-
If the provided hash does not match we set a time out between your next attempt to provide a password, the timeout starts at 2 seconds and doubles at every failed attempt
-
FN sets the timeout interval to the keychain itself so that if you close the app and reopen it it will remember your last timeout period
-
Bc the timeout number is stored on the keychain this means it persists even if you delete the app completely and reinstall it. Meaning if a thief had your iPhone and your node credentials and your seed words they would still not be able to access you wallets unless they got your lock password which of course is not even stored on the device at all. This makes brute forcing impossible and means even if the device is jailbroken or hacked in the most extreme way the attacker would have nothing without that password.
-
The app stays bricked and performs zero network requests until the app is unlocked, previously Tor would bootstrap in the background
-
The app will now lock itself if you have a password set whenever the app goes into the background, this prevents a thief from accessing FN when stealing your device while it is unlocked with the app in the background
-
We now annoy the user to add a password if they haven't when they go to do wallet things
-
Password must be at least 8 characters long and not numeric
-
Msig desriptor keys get sorted lexicographically now when imporing/creating msig wallets
Updating: 10/17/2020 6:00:00 AM
- Added: Mr. Rogers was a friend to everyone. But to one sick little girl, he was a life saver (https://www.wusa9.com/article/syndication/heartthreads/mr-rogers-was-a-friend-to-everyone-but-to-one-sick-little-girl-he-was-a-life-saver/65-621562742)
Generation took: 00:05:52.9584450 Maintenance update - cleaning up homepage and feed
STUPID FUCKING FIX FOR WHAT FUCKED UP IN FING DBL STUPID FUCKING DBL AND THEIR NSFW RULE FUCKING STUPID TOOK ME LIKE 60 GODDAMN LINE, THAT WAS IT FUCK
One addition, three changes
So everyone remember the flame thrower? Because I sure didn't. It was a nice, overpowered, pretty, but entirely non-memorable gun that only the most min-maxy of players (myself included) ever used. And even then we only used it until we were able to overpower everything with raw DPS.
So, well, I of course got rid of it for ESS planning on fixing it later because i couldnt balance it.
AND THEN I FORGOT ABOUT IT
But then i was reminded. I looked at this forsaken thing and remember everything that I thought was wrong with it, and set about correcting it
And correct it I did
This weapon now does a stupid amount of slowing damage, has a huge firing arc, causes some small amount of ion damage, and costs a stupid amount of electricity.
I call it: The Ion Rain (No, not that Ion Rain shush.)
I also asked a random member of the ESS discord (hydragyrum) to make a unilateral decision for me. I posed an argument on the utility of the beam laser line, and why I was considering moving it to being a secondary weapon. This member agreed with my argument and told me to do it. I am a sucker for peer pressure, and so now its a series of secondary weapons. This series is awaiting actual icons now, but i will be adding a couple of placeholder icons in the mean time
ML data to predict diabetes
Context This dataset is originally from the National Institute of Diabetes and Digestive and Kidney Diseases. The objective of the dataset is to diagnostically predict whether or not a patient has diabetes, based on certain diagnostic measurements included in the dataset. Several constraints were placed on the selection of these instances from a larger database. In particular, all patients here are females at least 21 years old of Pima Indian heritage.
Content The datasets consist of several medical predictor variables and one target variable, Outcome. Predictor variables includes the number of pregnancies the patient has had, their BMI, insulin level, age, and so on.
Acknowledgements Smith, J.W., Everhart, J.E., Dickson, W.C., Knowler, W.C., & Johannes, R.S. (1988). Using the ADAP learning algorithm to forecast the onset of diabetes mellitus. In Proceedings of the Symposium on Computer Applications and Medical Care (pp. 261--265). IEEE Computer Society Press.
Inspiration Can you build a machine learning model to accurately predict whether or not the patients in the dataset have diabetes or not
The Magician of the Ivory Tower brought his latest invention for the
master programmer to examine. The magician wheeled a large black box into the
master's office while the master waited in silence.
\This is an integrated, distributed, general-purpose workstation,
began the magician, \ergonomically designed with a proprietary operating
system, sixth generation languages, and multiple state of the art user
interfaces. It took my assistants several hundred man years to construct.
Is it not amazing?
The master raised his eyebrows slightly. \It is indeed amazing,\ he
said.
\Corporate Headquarters has commanded,\ continued the magician, \that
everyone use this workstation as a platform for new programs. Do you agree
to this?
\Certainly,\ replied the master, \I will have it transported to the
data center immediately!\ And the magician returned to his tower, well
pleased.
Several days later, a novice wandered into the office of the master
programmer and said, \I cannot find the listing for my new program. Do
you know where it might be?
\Yes,\ replied the master, \the listings are stacked on the platform
in the data center.
-- Geoffrey James, \The Tao of Programming\
Fix integer overflow in collision
DAmn spent so fucking many hours and evening finding why are those cursed podes randomly turns out from the checkpoint with no confidence it is a bug indeed and not just disability of 1-step random search to make a good decision with this type of reward function. Finally noticed that its a checkpoint passment detection that goes wrong and on the second try printing everything in collision function found that got x*x < 0. Really, 1e5 ** 2 is more than int32 can handle.
[WIP] *: separated lock table
The change here is large and will be broken up into multiple PRs after discussion (details below).
The largest and messiest part of this change is the MVCC engine API (Engine/Reader/Writer/Iterator) change. I ended up here after 2 failed attempts. Our current use of the MVCC API is quite indiscriminate. We use it for real MVCC keys, including intents, for inline meta (timeseries), and non-MVCC key space. For the last category we use MakeMVCCMetadataKey to construct an MVCCKey without any timestamps. This PR tries to clean this up in the following manner:
- Adds additional methods to the API to differentiate between these use cases.
- Introduces a StorageKey that is a generalization of an MVCCKey (see below for why). Most callers that are using MVCCKey for the non-versioned key space continue to use MVCCKey, since making them switch to an API with roachpb.Keys would make the refactor even larger.
I initially tried to keep the API change partly as an addition in a separate interface, and make callsites wrap Reader/Writer when they needed the additional interface, but that resulted in changes in even more places, and not being sure if wrapping had been forgotten. Now the Pebble-based implementations of Engine/Reader/Writer/Iterator directly implement these interfaces.
The changes here accomodate the transition from interleaved to separated intents. Various methods in Reader/Writer/Iterator know how to make separated intents appear as interleaved and to make an interleaved intent become separated when rewritten or vice versa. These are used by mvcc.go and friends -- the changes there are relatively straightforward and we are not touching any of the tricky code in mvcc.go.
Another aspect of the change here is the lock table key space and StorageKey. The latter is a generalization of MVCCKey that permits us to stuff a UUID into the suffix of the key (not just hlc.Timestamp), so that prefix iteration can continue to use a bloom filter when searching for a separated intent. I think we cannot afford to lose the performance characteristics of prefix iteration (though we will need to revisit this if we ever introduce replicated span shared locks, since prefix iteration will not be sufficient to find those locks).
The lock table has the following changes:
- It waits on locks found using a storage.Iterator (this does not include the optimization for limited scans which will be part of the real PR).
- finalizedTxnCache is moved into lockTableImpl. When doing ScanAndEnqueue if an unreplicated lock is encountered that is held by a txn in this cache, it is immediately removed. If a replicated lock is encountered a LockUpdate is created and the caller does not wait on that lock. At the end of ScanAndEnqueue if there are no locks to wait on, the caller is given this list of LockUpdates that it must resolve, and lockTableGuard.ShouldWait returns true. The caller will release latches, resolve these locks and then do another scan. Compared to the current batching of resolution that can only batch for a single span, this can batch across all spans of the request.
There are still many TODOs here, some of which I know how to fix and some (especially in the callers of the engine API, since there are so many), I will need some input on.
My current thinking is that this will split into the following PRs. For this review I am looking for a sanity check and any alternative ideas for this MVCC engine API refactor, so I can work on the second bullet below - unfortunately it will touch a very large number of files, including tests (tests were not changed in this WIP PR). The other PRs would be small in comparison.
- add lock table key changes to keys package and StorageKey.
- interface changes to storage package and all integration changes. The interface implementations will behave as if separated intents do not exist. We may not catch integration mistakes in calling the new API, but these will not be real bugs yet since there are no separated locks/intents.
- introduce alternative implementations that can handle separated locks. These can be done in separate PRs for Engine, Reader, Writer, Iterator and will include unit tests of the new behavior (separated, interleaved and mix of both). From an integration perspective, the separated locks will still be turned off.
- turn on separated locks for all CockroachDB tests and fix bugs. Also (somehow) run these tests with mix of interleaved and separated intents. This will happen over multiple PRs (N tests at a time and corresponding fixes).
- Lock table changes to observe separated locks including optimization for limited scans (the former is included in this WIP, but not the latter).
Release note: None
Kinda organizing and I hate myself now stupid module stuff