thanks for taking this on!
323 karma · joined December 19, 2012
https://travisby.dev/
thanks for taking this on!
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!)
> 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?
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!
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).
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.
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!
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 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'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
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!
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!
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!
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 ;).
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.
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!
[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.
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.
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.
I'm assuming you're placing your ad in USD and converting to BTC for the transaction, instead of listing a BTC price.
Note the NitroKey start is a gnuk implementation and is fully open source. The tamper-resistant models are using the BasicCard with Zeitcontrol software.
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!
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.
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] ```
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 :).
And what pays for that engineering work? The money you make from having the feature.