283 karma · joined August 16, 2015
I already had a whole home amplifier and wanted to use some of my AVRs also. Truplay with in ceiling speakers is amazing!
I run five monitors at 4k 60Hz every day with my max spec mbp. Four are portrait and two are landscape. (One portrait is DisplayLink usb) I actually have six monitors. One is split with an active HDMI splitter.
I definitely have trouble sometimes but the M1 is actually a lot better than the intel mbp because changes to settings are near instant.
Most of the time it just works.
Tricks I’ve learned:
1. Always plug the monitors in the same ports.
2. Lock the screen, then unplug monitors to keep your windows arranged.
3. I use SwitchResX to save and restore my monitor positions. Its not 100% reliable but it gets things mostly arranged and a few rotation tweaks in settings gets everything fixed.
4. It helps to have monitors of distinct models. When I have multiple of the same model and those are the ones that have problems getting rotation swapped.
Padding only works if you know everywhere your component might be used or don't mind remaking spacing decisions every time you use it. In my experience minimizing code needed for each use of a component leads to more coherently styled interfaces, particularly on larger or faster moving teams.
Check the temperature of your working environment. Cold joints can be the cause of or exacerbate various issues. Wearing gloves may help if you can’t control the climate. A personal heater can be another good option, but make sure the heat is indirect (pointed at a wall for example) to avoid other issues from prolonged exposure.
I use a keyboard arm with negative incline positioned at a height so that my elbows are at 90° and my wrists point slightly downward. (Height of the keys relative to the wrist rest should be as close to equal as possible.) This is the opposite of what most people do with the terrible kickstands that come with keyboards. I find that the more negative incline I can get the better. My current setup allows for 20-30° Of downward wrist incline. A typical keyboard tray or palm rest will not do this, as the height from the desktop must be adjustable and it must hold the keyboard in place. Mine grips the keyboard to hold it in place.
I personally find that a trackpad is good at preventing some rsi because you can use it in a variety of positions and it forces you to stretch all of your fingers when it is below the keyboard. For my keyboard arm I designed and 3d printed a mount for an apple magic trackpd that holds it below the keyboard making it much like a laptop. This had the added benefit of keeping my fingers on home row which is more efficient.
Remapping modifiers on the keyboard is extremely helpful for reducing strain on some fingers. Things like spacemacs or ergodox which use thumbs are great. Vim keybindings help a lot too and I have almost everything vimified.
Having a large (40”+ for 4k) monitor prevents you from leaning in to read small text or “hunching over” the keyboard. (poor elbow and back alignment) The same can be done by using a larger font or lower resolution at the cost of more keystrokes for navigating long files or between apps.
Taking breaks and changing positions frequently helps of corse. (Use a sit stand desk, try kneeling on a soft mat occasionally if your desk goes low enough.)
Drink a lot of water. Hydration helps almost any bodily issue to some extent and I find that my productivity is significantly impacted by dehydration and greatly increased when I drink a lot. Soda is fine but offset the dehydration from it with extra water. This has the added benefit of forcing you to take breaks.
Update 2: Apparently anything captured along with the device handshake can be decrypted after the fact if the attacker learns the password used at that time. (Source: https://www.google.com/amp/s/mrncciew.com/2014/08/16/decrypt...) So to decrypt all traffic an attacker would only need to compromise any machine which has the password saved. (Assuming they see the handshake for the device connection.) This indicates that regularly rotating the password (To something unpredictable) has some limited value.
If an attacker had recorded encrypted WiFi traffic in the past and then performed one of these attacks could they see the traffic? (I know TLS is used for a lot of traffic, but in time that will be broken too.)
It seems to me that a patient attacker could gain a lot of sensitive info given enough time. Is this assumption flawed? I would love to hear why/why not. (Nonces make decryption of large amounts of TLS traffic impractical?) What about the impact of just knowing DNS lookups? (Real world info on DNS caching? Does DNSSEC stop this? Is it widely implemented?) What if a data broker recorded a lot of encrypted WiFi traffic at a public place like a mall? (Could they learn MAC addresses? mDNS device names? DNS lookups? I bet a lot of tracking cookies and other advertiser tokens don’t bother with TLS which could get them emails and more.)
Someone recording encrypted WiFi traffic from a sensitive network may have enough motive to do something this long-term and the attack would be (electronically) undetectable. Most people rarely change their passwords and at a minimum this would give an attacker knowledge of the internal network, intranet sites, and services used by targets.
As others have mentioned having an expiration policy is a good idea. Also you can mitigate charges from malicious activity by using rate limits on the signing endpoint. (API gateway supports this.) Using infrequent access or reduced redundancy storage might also be a good idea if you expect a lot of traffic. It's also good to limit the CORS policy on the bucket to the needed domains and headers.
Signed metadata headers are very useful when combined with S3 event handlers (SQS or straight to Lambda.) using a HEAD request on the uploaded objects. This is a great technique for post processing an upload without requiring client trust or an external data store. (With a separate falliable request which could lead to consistency issues.)
Edit: It is also critically important to have some randomness in each key path so it is ungessable. Otherwise user files would be overwriteable by an attacker. (Many file names are easily guessable and an attacker with many tries could eventually stuff malware in for example.) I used guids for this because they are both URL and S3 key safe. If keeping the original file name is needed I put it in a metadata value and rename the file on download using a Content-Disposition header. Making the S3 headers work with symbols in file names can be tricky but encoding it as a JSON string works around most issues.
In order to overcome the 30 second request limit in API gateway for longer post processing while still offering realtime client feedback you can set up an S3 event handler to trigger the post processing lambda which then updates a DynamoDB record with the S3 key as it's id. A status endpoint lambda is then polled by the client with the S3 key for status events.
For more complex post processing and client side workflows I have used key prefixes (folders) each with seaprate event handlers or CORS configurations. IAM polices with conditions including S3 key prefixes are used to restrict access. Using the S3 API copy command can move large objects quickly between workflow steps.
Also enabling server side encryption is a must imo. Be sure to specify AWS signature version 4 in the S3 constructor so that all parts of the request are signed. (Otherwise some older regions may not sign metadata headers.)
Also the S3 API copy command has an interesting append feature which can be used to build objects iteratively. I once toyed with the idea of using it to create large zip files of many S3 objects efficiently but ended up not needing it. Someday I would like to try that because it could be great for a lot of web apps where users can select a random list of files to download.
Also I (re)implemented most of the above this week using CloudFormation and the newer AWS Serverless Template (not the serverless.com project but the actual AWS feature.) which allows for really easy deployment.