travisby

https://travisby.dev/

thanks for taking this on!

Coming to the site from an aggregator (and needing to be convinced to use Ash, rather than coming there directly and already knowing I want to use ash) I found the book a little weird to be so front and center.

I would have really hoped for a small code snippet or screenshot showing how powerful the framework was. And a book a little further down from that would be nice. But "pay to learn" before "here's a quick snippet on why ash is neat" would have made me more excited for this thing I hadn't heard of before, and who's website I was visiting to learn about.

---

Seeing a book first gave me a different impression -- like one of the old snooty languages/tools from twenty years ago that was really enterprise-only.

I can tell that's not the vibe Ash is aiming for, but it's what I picked up!

(Somehow, I also couldn't find the documentation link on the first two tries. But that's also my eyes being weird and missing the sticky header where it clearly says Documentation!)

I'm really enjoying the discussion on how shuffle means different things to different people (I personally prefer random, but implementing `shuffle` specifically sounds fun with all of this)

You insert each item into a random position among the remaining items

Thinking about shuffle + adding, I would have thought "even if it's added to a past position", e.g.

`5 4 6 21 3` as valid.

What do folks expect out of shuffle when it reaches the end? A new shuffle, or repeat with the same permutation?

The airports I fly at (student rotary pilot) have all had the same traffic for rotary/fixed wing, but the FAA talks about [flying _opposite_ planes at a different altitude](https://www.faa.gov/air_traffic/publications/atpubs/aim_html...) as a potential practice.

My understanding of why (and also why we're cleared _direct_ a lot of times) is that we move a lot slower than planes, and that ends up being dangerous in its own right in a pattern shared with planes!

For hardware failure, replication is the bees knees and indeed means you'll lose less (no? depending on your replication settings) data.

But, backups will help if you replicated _bad data_, or more accurately _data changes_.

You can restore from backup if you accidentally ran `DELETE FROM foo;`, where replication will not help!

(Insert cryptolocker type viruses, bugs, human query mistakes, etc).

Your bet is correct! These are considered `reports`. The default `task` view is called `next` (what are my next tasks), but there's plenty of others, plenty customization (sort order, filters, columns), for those built-in reports, and custom reports as well [1]

[1] https://taskwarrior.org/docs/report/

I used a stacking review system at two other roles (gerrit and phabriactor). At the time I found it annoying and missed the pretty Github UI and the ability to bunch commits together.

Now that I'm using Github full time, I miss the stack. I found stacks allowed me to easily commit for a few problems at once without bogging down a reviewer.

It sounds like you're already a fan of PRs being small, and that probably means _doing one thing_.

What about a spelling mistake in a nearby but unrelated comment? That probably should be a separate PR. In the stack-world, I was happy to make a second commit, create a second review artifact, and be OK with it shipping eventually when the other features of my commit ship (especially if they're close enough to cause a merge conflict!)

Today, I have to: * Stash/commit -m temp my current work * Checkout a new branch, make the fix, push it up, make a PR, etc. * Check back out my old work, potentially rebase on top of it if it's going to cause a merge conflict * get back to work on the real issue * Create a PR for the real issue... and hopefully not have it reviewed until the doc fix is already merged, because it's going to show up as an unrelated change here anyway!

There's also merge-into-other-branches that might help with this workflow, but I haven't found anything graceful yet.

In practice, I avoid the documentation fix to avoid the change in flow, when I'd have been happy to just have it as a different commit in the stack.

--

that covers more generically why I like stacks, I'm not sure graphite would solve my problems after reading the OP though.

I thought that was a really interesting stat (I believed you, I don't mean I went to fact-check you but that's what ended up happening!) and wanted to read more about it -- it sounds like dryer fires aren't _overall_ that destructive, but in the "washer & dryer" category (~16k fires out of ~350k per year) they are 92% of that category.

Figured you'd want to know, since I found it interesting!

That being said, the dryer fires are certainly preventable and if any technology aids in reducing that, it's well worth it!

I have my amd framework hooked up to a Lenovo 27" monitor over USB c and that daisy chained to another of the same monitor type over display link and it works like a champ: USB, video, Ethernet, and power all through the one cable.

Though it did NOT work out of the box to a display link USB A dock. I think it needs display link kernel module and I didn't want to bother.

I think a good example for your hypothetical would be the sinking of a nuclear plant propelled ship. If country B invades the territorial waters of country A with a nuclear destroyer and country A destroys it, the fallout (morally and chemically) would still be on the aggressor for creating the situation where it's reasonable to expect their harmful payload would be destroyed.

Based on https://go-review.googlesource.com/c/go/+/3012?tab=comments , it sounds like they were originally focusing on _clearer_.

(I interpret that) rsc considers the native binary operators to be clearer than a function with the name `Compare`. Honestly, I'd expect people to use `==` as well over `strings.Compare`.

`==` _does_ work for strings, but I believe `[]byte` would try comparing memory addresses which is why the `bytes.Compare` version exists and is optimized (some assembly version, probably costly to maintain per arch?).

I'm a huge chromebook fan actually -- but my current one is looking a tad unsupported (pixel slate)

I've been considering a framework as a replacement actually!

One of the things I really care about is battery life + sleep performance.

The article mentions:

.* At the same time, the Framework Laptop Chromebook Edition is our most power efficient product yet with optimizations from Google and Intel that allow for long-lasting battery life.

Can you provide some numbers around the battery life improvements? Sounds exciting! (And are these going to be backported to the normal 12th gen boards, or is it a feature of the unique mainboard/not firmware?)

Can you speak to the OS image as well? Is there any non-upstream drivers that are relied on? I notice lots of chromebooks have drivers that aren't in the regular upstream kernel, but just in the chromiumos source. I'm hoping that I could eventually swap OS' if needed w/o getting a new mainboard, and want to see how viable that is.

Thanks for the hard work, and in advance for the questions!

(P.S. like everyone else, AMD would be exciting if you don't know that :p)

[edit] one of my biggest disappointments in my slate is that it never received vm-in-vm support with the newer kernel. Is /dev/kvm available in the linux container? I _think_ that goes hand in hand with the steam supuport, but not sure

Do you use the ironsponge on stainless steel? I assume you mean something like steel wool?

My biggest "pro" for cast iron is that it's incredibly easy to clean without worrying about ruining the pan. Our stainless steel pan gets scratched if I look at it wrong, even using the rough side of the sponge. Not sure if we just have the wrong pan, or worry about scratches more than we should?

For our cast iron I use chainmail if there's every anything stuck on hard. For the stainless steel I feel a lot more out of luck! Metal utensils, soap, rough side of the sponge, I'm never worried about it!

The standby performance was what kept me from buying a previous gen frame.work despite loving the mission and wanting to support y'all. I was holding my time until either the efficiency cores came along (if that has any improvement in standby? I'm not even sure) or if you ended up making AMD where I believe S3 sleep states still exist.

Very exciting to hear there's an improvement in this generation. Is that improvement due to intel changes, or due to frame.work changes? Can you quantify the standby improvement for linux in watts or battery % / 24h?

Does battery life significantly change between processor models?

Congrats on the refresh launch!

and not 100s, like I have with PGP+U2F

I'm really interested to hear what you're doing that gives you 100s of signatures a day (or decrypts?)

I have been searching for an openpgp card replacement but I use one with a hardware pinpad, I can't imagine entering my pin 100s of times a day!

I'm really excited to see this post! I've actually tried doing something similar -- I want to use/create a smartcard reader on the web that works with gpg.

The goal was to port pcsclite or scdaemon to use webusb instead of libusb.

It's been a while; I forget exactly where (very early) I left off/felt defeated. I definitely didn't consider making an additional backend for libusb!

Very cool -- I can't wait to see part 2 ;).

It might also be worth comparing to the stdlib's `container/ring` implementation of a non-generic ring buffer, to see how your code might differ between `RingBuffer[string]` and how the `interface{}` version of container/ring works!

https://pkg.go.dev/container/ring#example-Ring.Do

The casting back and forth from T and `interface{}` is expensive, boilerplatey/extracode, and panic-prone.

so throwing a Hail Mary and simply resizing the partitions back to their exact original sizes

I've made similar mistakes (well, the same effect, but for different reasons. I thought I was over a remote session when I was local and made an entire new partition layout).

`testdisk` was able to introspect what partition boundaries _were_ and rebuild the partition table.

If you're ever in a similar situation and either don't remember the exact boundaries or don't trust yourself to recreate them, check it out!

This has been referred to as [Lacros](https://chromium.googlesource.com/chromium/src.git/+/refs/he...)

[aboutchromebooks](https://www.aboutchromebooks.com/news/lacros-vs-chrome-and-c...) has a nice explanation as well.

The reasoning I've read behind it is this will allow updates to continue for the browser much longer (probably more important!) than the cycle of the OS which has a much more finite support window.

FWIW, the announcement said "text-only messages for <> concerns". <> was abuse or something similar.

I didn't vote in this poll, but it's always been important to me.

It's an easy proxy to see that your team mesh well together (if my "best friends" at work are also my team members, chances are we'll work well together). Plus we'll end up discussing work problems we all have and that lunch time can turn into solutions.

keybase uses your gpg key more as a _bootstrap_ to prove your identity, and to then sign your _keybase key_ (which isn't gpg as far as I could tell from the spec).

e.g. you can see I used my GPG key to sign all of my proofs (proving identity), and to also sign my keybase keys which then have signed other keybase keys:

https://keybase.io/travisby/graph

We can view yours at https://keybase.io/simias/graph .

Your device still has worked-key on it which is decrypting secret.txt for you.

If it's a $400 fountain pen and not a 144mBTC fountain pen, then I think you are thinking about the current price of bitcoin ;)

I'm assuming you're placing your ad in USD and converting to BTC for the transaction, instead of listing a BTC price.

Unfortunately it's not _fully_ open source. They don't say it anywhere on their webpage, but they use an [OpenPGP Smart Card](https://www.g10code.com/p-card.html) internally, where some of the implementation by ZeitControl isn't open source. g10 has a reference implementation that is fully open source, but there's some additional (timing?) attacks that Zeitcontrol has implemented and cannot release.

Note the NitroKey start is a gnuk implementation and is fully open source. The tamper-resistant models are using the BasicCard with Zeitcontrol software.

I'm definitely with you, and don't advocate for 2048 bit keys anymore. That being said...

The older versions of the card only supported 2048bit keys. The 2.0 version and above support 4096 :)

I personally generated my RSA4096bit key on the card!

After going back and forth on whether I wanted a Yubikey, I finally decided I didn't want to support them due to the closed sourceness.

I bought an Open PGP Card instead! https://www.g10code.com/p-card.html

You still have to buy your own card reader, and any card readers on the market aren't as small as the Yubikey... but it's a fantastic device and I love mine to death.

Note: the yubikey actually uses the open pgp card inside of it (which the actual implementation from the chip supplier is hardware-closed-source, although the reference architecture is open). The nitrokey too. They technically all have closed source with the BasicCard that runs inside them! With that in mind the secret-sauce of the yubikey is also closed source, where there's no secret sauce around your OpenPGP Card to be closed source.

In 99% of cases, no, but longer answer:

Depends on the type and number of bits in the key.

If you create an ssh key that is already broken (say you managed to generate a... 512 byte RSA key), then an attacker would know what key he needs to generate before he attempts to authenticate with your server (or github).

But in practice public keys are meant to be public... very public. Like GPG keys! Here's a debian signing key https://ftp-master.debian.org/keys/archive-key-7.0.asc .

We can even verify that it's an RSA key with 4096... exactly what you could (should?) use to generate SSH keys. Effectively posting your public ssh key in the wild is as safe as debian posting their public signing key :)

``` pub rsa4096/0x8B48AD6246925553 2012-04-27 [SC] [expires: 2020-04-25] Key fingerprint = A1BD 8E9D 78F7 FE5C 3E65 D8AF 8B48 AD62 4692 5553 uid [ unknown] Debian Archive Automatic Signing Key (7.0/wheezy) <ftpmaster@debian.org> sub rsa4096/0x85215E51ADD6B7E2 2012-04-27 [E] [revoked: 2014-03-17] ```

tl;dr: Yes! There's some caching mechanism, _providing_ the user has already logged into the host. Also there seems to be some replication that could help.

in my homelab I'm running RedHat IdM (which is their downstream version of _freeipa_). It's some value-add on top of LDAP on the server side, and sssd on the client side. My IdM runs in a VM on a server that isn't always powered on, and I'm still able to login thanks to sssd being configured to cache.. something. Clearly I haven't played with it as much as I should :).

The engineering work was already done, and doesn't change based on the number of instances that are making the cert request. It certainly isn't labor.

And what pays for that engineering work? The money you make from having the feature.

For... various interpretations of mentally incapacitated. Like not running your own finances?