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!
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]
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.
(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?
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!
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!
> 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!
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.
thanks for taking this on!