steventhedev

Google calendar and an hour each morning to move actions related to long-term goals into your short term todo list (notebook in your case).

However, bear in mind that plans are rarely followed to execution perfectly. You may meet someone who wants you to stay, or you may get a really good offer. You might experience financial hardship and need to settle down for a while.

When I go on a hike, I spend a good hour or two studying maps (topographical, orthophoto, etc) before picking a trail. It means that I can decide on a whim to follow another trail halfway through if conditions call for it (mud, rain, wild animals, etc). Planning is about mapping out all possible outcomes, and not so much about following one plan to the letter.

A simple approach that gives 13 correct answers minimum is to have him walk out after X seconds, where X is the number of true answers. Answer true for everything if X is greater than 12. Otherwise answer false for everything.

This uses only 6 bits of information, and you should be able to pack some extra info rather easily into the remaining 7.

Thinking about alternative approaches leads me to think that the only cases that you should focus on to solve this are those where the number of true/false is almost equal. Figure out how to pack them together, layer a few solutions together, and you should be able to answer the exam to within some N guaranteed.

EDIT: 12 correct answers. not 13. And you can easily pack this into 1 bit. Leaving my wrong answer for posterity.

I managed to wipe mine by creating a directory called "~" in a REPL and then trying to clean up a few days later by running rm -rf ~. Hit Ctrl-C, but it still managed to chew through most of the dotfiles, and was halfway through a few checkouts of AOSP before I stopped it.

Previous discussion: https://news.ycombinator.com/item?id=12582534

tl;dr - WoSign/StartCom are no longer trusted as a CA (at least by Firefox)

Are those dosages a fair comparison (ibuprofen 600x3, celecoxib 100x2, and naproxen 375x2 daily)? Do they each provide the same level of pain reduction?

If not, there is literally no way to compensate for that level of statistical bias. Stomach/kidney/heart damage is not linear, and there's no mention of when people gave up taking the medications.

For someone who actually wants to read the study, here's the link: http://www.nejm.org/doi/full/10.1056/NEJMoa1611593#t=article

tl;dr - they admit that taking more than 200mg of celecoxib does some damage, and 800mg doses (they apparently were limited by regulations to 200mg/day) showed the same heart damage they expected to see. Time magazine is a horrible source

Seems like this would benefit from not using standard TCP (which assumes that a dropped packet is always due to congestion), and maybe use one of the WiFi retransmission protocols (the names are slipping my mind at the moment).

Might increase that bandwidth from 7kbps to something more comfortable.

This confused me until I remembered that Google is recycling the term Daydream. Search for Android Daydream and you'll find a few results for the old lockscreen API (after all the VR hype).

Can we get a VR added in parentheses to disambiguate the title?

It depends heavily on your threat model. Just about any key is an improvement over using passwords to authenticate. If you want protection from state-level actors, you need to be really careful and consistent.

Regarding key types:

- DSA keys (ssh-dss) suffer from several issues (fewer bits, bad RNGs in Debian, other issues), and modern versions of OpenSSH deprecate it.

- RSA is pretty standard, and generally speaking is fairly secure for key lengths >=2048. RSA-2048 is the default for ssh-keygen, and is compatible with just about everything.

- ECDSA is largely considered compromised because the constants NIST chose for the cryptosystem weren't well documented how they got them, and the assumption is that the NSA chose them to provide a "backdoor" (so it would provide the same security for a general attacker, but significantly easier for them). This was confirmed as being theoretically possible, and there is of course concern that the NSA could potentially leak those constants, instantly breaking the security of this cryptosystem.

- ED25519 is more or less the same as ECDSA, but was put together by DJB. The big advantage here is speed. EC crypto is much faster to sign, slightly slower to verify, and equivalent security can be achieved with fewer key bits.

- Notes for the future: both RSA and ED25519 become insecure against quantum computing (integer factorization and discrete log are both in BQP).

Generally, use RSA if you work with older servers that only support it, or ED25519 if you like shiny things. Otherwise it's a bit of a tossup.

Regarding using separate keys:

- I follow the philosophy that a private key should never leave the host it was generated on. If you aren't sharing keys between machines, you remove the risk that you'll accidentally share it publicly.

- Beyond that, I'd recommend at a minimum having separate work/personal keys. Keeping separate keys for each user/host you want to log into is a tad excessive, but can be useful for key revocation/rotation.

Regarding passphrases on keys:

- Yes. FDE is sometimes trivial to bypass, and you want to be protected in case someone sets your ~/.ssh folder to be synced to dropbox/samba/etc. You can use an agent to keep the decrypted keys in memory, but I'd avoid using agent forwarding.

Regarding bastion hosts:

- You didn't ask about this, but it is essential for a "best practice" setup.

- Bastion hosts are small VPS hosts that basically run sshd and have a static IP. You disallow any ssh traffic except from your bastion hosts to your servers.

- You'll want to have at least 2 bastion hosts with different hosting services, in case one isn't available.

- Run sshd on your bastion host on a port other than 22. Not for security, but for reducing log volume.

- Run fail2ban on your bastion host, even if you've disabled password authn. Again, not for security, but for reducing log volume.

- Set up fail2ban to alert when a new IP successfully logs in.

Other stuff:

- SSH can use certificates for authentication, and this can make the key distribution problem much easier to solve. I have a script that makes this easier.

- Push for everyone in your organization to use SSH keys, and only SSH keys.

- Defense in depth. All it takes is skipping one step and you expose yourself. Assume that something that was exposed has been compromised. An attacker only needs to succeed once.

tl;dr - the defaults are fine and password protect your keys.

3-5 years under ideal conditions. Stick a battery in a phone/laptop that regularly gets used in the heat and it will give up the ghost within a year. It's not even so much the ultimate lifetime that matters so much as the longer 95% capacity life, which is much shorter now. I wouldn't be surprised if this also has some major catch, like manufacturing cost, heat degradation, or instability under mechanical stress. So while it could be an really important discovery, I'll remain skeptic until I have a laptop battery that lasts for longer than 12 hours after a year of heavy use in a hot, humid climate.

You're absolutely right about being able to compress the material into a much shorter amount of time. However, schools play a huge role in social development, and I doubt we'd be willing as a society to give up on that, even if it is potentially viable.

Dayjob - server with intermittent memory issues and no budget to replace. Hosts our primary code base, and corrupts the occasional packfile. I'm in the process of writing a git-surgery script that automatically diagnoses fsck issues and traverses remotes to copy back corrupted/missing objects.

side project - some stuff to import customer data dumps into the db quickly. Not quite self-service yet, but getting there.

The :target pseudoclass is used, along with anchors. It means that it also pollutes the browser history, which is somewhat appropriate for modals, but probably not what you want.

Still neat though.

At which point they'd find out how to manipulate specific capacitors on the board to emit noise. Did you ever hold a cheap backlit wristwatch up to your ear as a kid? That sound.

Perhaps a cheaper way to solve this is to hide the physical case inside a locked cabinet, with a ventilation fan? Most users of secure systems don't need physical access to the case, and the ventilator should drown out any signal noise from such malware.

Really awesome app! My only advice would be to move the sidebar to the top when possible because horizontal real estate is important, especially if you have lots of long term events.

Other thing I'd love to see in a calendar app is prompting me to track the exact amount of time I spend on each thing in my calendar. Having contextual reminders and a split (planned/reality) view would be really interesting. It would help spot those people who are habitually late.

not necessary, and yet very common. And setting your DNS server to 8.8.8.8 doesn't help when they reply with their internal gateway for all DNS requests.

FYI - android fires a request to http://clients3.google.com/generate_204, I'm fairly confident windows/ios/mac/ubuntu all do something similar.

It's not about leaking your private keys (although courts very much do work like that....think of it as keeping separate keys to each room in your house, as opposed to a single master key).

The real goal is privacy, given that your public key is available on github and sent via plaintext when authenticating.

There are some added benefits to managing separate ssh keys for each server: it forces you to use tools to manage your keys, which make it easier to mitigate disaster when the time comes to rotate your keys due to compromise.

How does this play out with wifi networks that resolve dns requests for say, "google.com" with their "click to accept the terms of your municipal free wifi" page?

It's easy to validate that the syntax is correct. The problem lies in what you're trying to do with those addresses. If you're importing a mailing list archive, chances are a syntactical check is the only one you can do, because half the domains for older lists don't exist anymore, and most of the mailboxes won't.

If you want to send email to that address, you're probably going to want something that can suggest gmail as a replacement for gmial. You can also check that the domain exists and has a MX record. If you run your own mail server you can probably even check that the mailbox exists...

If you want emails to be unique, you'll need to apply per-site logic like gmails optional .'s and strip the + segments. That's important if you're combining multiple lists of emails, or importing an existing mailing list for a user.

The gist is the real world is complicated, but you can pretty easily set up something that handles 90% of it.

It doesn't. But neither do passphrases. The key has to be in process memory at some point, and if you're running a compromised process under your user, you've already lost.

The only threat a passphrase protects against that an encrypted home doesn't is someone walking up to my unlocked laptop (it locks automatically after 5 minutes, and I make a point of locking it when I'm leaving). If you run ssh-agent, you're exposed to this threat anyways.

EDIT: After some thought, passphrases can protect against a poorly executed attack, where just files are copied wholesale, or an accidental leak. So while theoretically you're not protected, it may be sufficient for some practical security. I'll be looking into using ssh-agent in the near future.

I've configured ssh to use a different key for each server [0]. I don't bother with passphrases on each key, instead relying on a encrypted home folder. Also, I have a script [1] for rotating keys, so rotating all my credentials is a single command.

[0]: https://github.com/stevenkaras/bashfiles/blob/master/.ssh/co...

[1]: https://github.com/stevenkaras/bashfiles/blob/master/.ssh/

A password wallet that syncs over Dropbox, Google Drive, Syncthing, even rsync.

https://github.com/stevenkaras/kasefet

Got fed up with Dropbox creating conflicted copies of my keepass database, and decided there must be a better way. I expect the base KV store will be easy to use for other apps in the future as well.

I'd love to have something like this for day to day work emails. They aren't beautiful prose, and they shouldn't be.

That said, I think there's a better way to approach this. Rather than linting based on a list of rules, I'd prefer a more technical approach that highlighted actual issues, such as garden path sentences, ambiguous pronouns, doubled words, etc.

I wrote something similar, but in bash (and it uses the old key to rotate the new key).

I'm half-surprised no one else had written something like this before. It's a common enough problem.

[0] https://github.com/stevenkaras/bashfiles/tree/master/.ssh

aside from the ELK stack, you can also send views/events from your server to GA (this is what I do). Staccato[0] is my go to gem for this

[0]: https://github.com/tpitale/staccato

This is why I use server side analytics almost exclusively. You just can't rely on every browser running all your javascript.

Ummm...just a warning to everyone that you should NEVER upload a raw dump of your app's memory.

Filter out your API keys and database secrets/passwords first. Then upload.

Multidimensional in this case refers to OLAP cubes. In other words, it's a relational database with a star schema.

The formulas in this case are built in the "metadata editor". The expectation is that a data scientist would build the tables, and then pass it off as an analysis tool to the MBA types. It can be really unintuitive if you've never seen these types of dashboards before.

It looks like your access control is table level. Have you considered what it will take to provide row/column level controls?

Also, the report builder looks like it doesn't allow you to set up complex reports (range queries). Can you add an abstract WHERE clause constructor? That would let you do things like collect all orders in the last week that were over 20 dollars, late on their delivery, or fulfilled by the new guy. You might want to look at BI tools like Pentaho or Microstrategy to see if you can build something similar on the analysis end.

Finally, do you offer change tracking and backups? No one wants to lose a LOB database because someone ragequit.

I've found that cards get better exchange rates than converting cash. Sometimes several dozen percentage points better. However, if you pull the local currency out of an ATM, you get the card network's exchange rate, and at worst an ATM fee (if any).

A few things: keystrokes is only part of the data collection. I wouldn't be surprised if they're also looking at mouse movement, or the actual keystroke pattern (backspaces and such).

But it does raise an interesting idea: build a fuzzer that you can use to change "profiles". Rather than making yourself mechanical, put on a different face.

Also, I'd like to see a concept website that used keystroke data to authenticate a user instead of a password. Basically, give them a "passphrase" or somesuch that is presented in cleartext with the instructions: "type this phrase".