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.
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.
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.
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.
Also IANAL, but its my understanding (at least under common law here in Canada) that the doctrine of privity of contract should apply here. Since the ticket purchaser only has a contract with Ticketmaster/Live Nation they should not be able to sue the 3rd party event provider, and rather are only left with the option to sue Live Nation.
Had no idea they also owned Newton. Going to use this as yet another reminder not to invest in new email clients, they all seem to get shut down within a few years of launch.
d1g1t is a digital wealth management platform powered by advanced analytics and risk management tools that offers transparent portfolio management services to professional advisers and their individual investors. Our goal is to empower wealth management firms to transition into a new business model that is driven by technology and analytics, and provides a richer experience for their clients.
We are looking for an experienced JavaScript (Typescript) developer who is proficient with React.
On the front-end our tech stack on the front-end includes React, Typescript, Redux+Sagas, Swift (iOS) and Kotlin (Android)
We are a team that is passionate about our work, and we strive to maintain the highest standards for code quality. If you are looking to work on genuinely difficult engineering problems in the front-end space in an engineering focused organization, this is the job for you.
I've been neglecting the maintenance of the package "react-stripe-checkout" for a while and though this would be a good time to finally bring it up to date, but it appears the new version of checkout was created with a very different use case in mind. Single page, JS rendered apps don't really fit the model, and should probably use legacy Checkout or Stripe Elements.
d1g1t is a new digital wealth management platform powered by advanced analytics and risk management tools that offers transparent portfolio management services to professional advisers and their individual investors. Our goal is to empower wealth management firms to transition into a new business model that is driven by technology and analytics, and provides a richer experience for their clients.
We are looking for an experienced JavaScript (Typescript) developer who is proficient with React.
On the front-end our tech stack includes React, Typescript, Redux+Sagas
We are a team that is passionate about our work, and we strive to maintain the highest standards for code quality.
We've had to implement an internal table library with all of these features using React (and react-virtualized for scrolling). It's interesting and impressive to see such a large piece of UI code written without any library.