From my personal testing, running various agentic tasks with a bunch of tool calls on an M4 Max 128GB, I've found that running quantized versions of larger models to produce the best results which this site completely ignores.
Currently, Nemotron 3 Super using Unsloth's UD Q4_K_XL quant is running nearly everything I do locally (replacing Qwen3.5 122b)
As someone who has spent a good time of time working on trusted compute (in the crypto domain) I'll say this is generally pretty well thought out, doesn't get us to an entirely 0-trust e2e solution, but is still very good.
Inevitably, the TEE hardware vendor must be trusted. I don't think this is a bad assumption in today's world, but this is still a fairly new domain and longer term it becomes increasingly likely TEE compromises like design flaws, microcode bugs, key compromises, etc. are discovered (if they haven't already been!) Then we'd need to consider how Confer would handle these and what sort of "break glass" protocols are in place.
This also requires a non-trivial amount of client side coordination and guards against any supply chain attacks. Setting aside the details of how this is done, even with a transparency log, the client must trust something about “who is allowed to publish acceptable releases”. If the client trusts “anything in the log,” an attacker could publish their own signed artifacts, So the client must effectively trust a specific publisher identity/key, plus the log’s append-only/auditable property to prevent silent targeted swaps.
The net result is a need to trust Confer's identity and published releases, at least in the short term as 3rd party auditors could flag any issues in reproducible builds. As I see it, the game theory would suggest Confer remains honest, Moxie's reputation plays are fairly large role in this.
I found the reddit ManyBaggers recently and there is a cottage industry of high-end bags that seem incredibly made for the price that are in no way luxury products.
To contrast, in my early days of options trading with Interactive Brokers, they had closed a spread ~10 minutes before expiry at a loss, which turned profitable 8 minutes later.
Contacted support, and they responded within 2 minutes explaining exactly why this had been done (risk profile at the time, and insufficient margin to cover). They answered all my questions and even explained what I should do to mitigate this issue going forward.
Used to have IB: that broker is no joke. I would see ads on TV of $7 a trade while I was paying their crazy .001 cents per share or whatever their price was. Great paper trading account, and a Java/C++ API for everything. Plus level-2 data.
But essentially if you are using their “pro” service, which charges commissions then no. If you are using their “lite” service with zero-commission then maybe.
> Electron 9 stable will target Chromium M83 and be released on May 19, 2020, in response to Chromium's announcement of skipping the M82 stable date and adjusting the M83 stable date.
This is turning out to be a bad decision because there's been 5 major version bumps in the past year, yet the functionality in Electron hasn't materially changed very much, mostly bug fixes and minor changes.
Interested in why you think this was a bad decision. For a multitude of reasons surrounding security, performance and wanting the Latest And Greatest JS features we want to stay as close to upstream Chromium as possible. Curious what you feel the negative impact of major-versioning is?
The Electron version numbers are essentially meaningless now. I have no idea what even changed between Electron 4 and 8, the changelogs are all just bug fixes that didn't necessitate so many major version releases.
Also there are some NPM packages that have to create builds for specific versions of Electron, and those builds come out after Electron does, so I'm always 1 or 2 versions behind on Electron which leads into dependency hell situations.
We use JIRA to track our product development with a fairly large team (including 17 engineers) and while JIRA has its pain points, it does have integrations with development workflow.
In our setup, after a PR is merged in Github, the ticket automatically moves to the next “step”, in our case “Ready for QA”.
Beyond that there are automation workflows that accomplish much of what you are asking for here, the issue is that these are complex tools/flows that require a lot of up-front work and continuous maintenance which might not be worthwhile for all teams.
So internally, we're calling it the "task lifecycle". It's going to be a big feature, and the idea is to figure out the true development workflow (that works for 80% of users) and have statuses that update automatically based on Git. We're working on figuring out how to do this well enough, where the user doesn't have to go through complex configuration.
reply