DetroitThrow
DetroitThrow on Hacker News
Are there any recommended alternatives to IronMountain nowadays?
>They can't draw, they can't sculpt, they have no clue about art history. Or color theory, if you want to go that far. Usually golden ratio/Fibonacci is kinda where it ends. One of them is a professor of architecture, no less.
I only have a couple of architect friends, but wow, they actually have exactly these skills and interests. Amazing artists and designers in their own right. They seem to know a lot about how philosophy interacts with architecture too! Interesting to know they might be the exception.
>Still, that's two weeks late.
Agreed! I know this is a bad month, but this is poor form from several vendors that tout "we'll handle XYZ aspect of security for you".
Yes, a huge part of why I bought Macs for my company is for some of this to be automatically handled. Only now are we getting any communication and still no date on when this will stop being rolled back on updates.
Please, Apple, break the process on getting a fix out for this. I want to stop doing a morning check in with my team about certs.
Yeah this reeks of never talking to the customers of these legaltech companies - on top of what you mentioned, it's also external integrations and downstream configurability for how those integrations behave.
If you view Harvey as Claude in a box for legal documents, then the Harvey/Legora competitor that will never have the "killer features" that larger firms receive from running Harvey/Legora.
These biglaw firms also have software engineering teams themselves. If Harvey was easy to remake as doing legal document RAG, why haven't they done it themselves?
This is not open source! Can we get an update to the title?
I ended up doing the opposite! After being on the go with 15, 16, and 17 inch laptops I've finally moved to smaller 13 and 14 inch screens.
It's much, much easier to transport even though I do miss the screen real estate.
Wow, that's amazing to try in casual visual editing workflows. Very great results as well for something free.
Several people found they can use a much simpler exploit chain to continuously DoS the website using the unpatched exploit, than put together one that gives RCE.
There's a lot of smoke being blown by companies with a financial stake in coming off as "security-minded" or something.
There's apparently _some_ exploit usage in the wild before the embargo breaking, but it very much looks like they didn't even achieve RCE, or if they did it was not widespread at all. It doesn't mean it wasn't possible by a group more sophisticated, it just didn't happen thankfully.
After the embargo was broken, RCEs were still not widespread, especially not before a huge number of sites patched themselves.
So, no, the narrative that skids with agents were busting down doors as soon as the embargo was broken is not accurate. But breaking the embargo before a patch was ready only hurt the situation for defenders.
The only reason Php2shell wasn't as bad as it could've been was because basically no malicious actors had exploits that were useful in time.
Whoever broke the embargo is a moron and it could have resulted in much more damage than was done.
This is the CEO of ToB. It makes total sense why he'd not want to share his proof of concept.
>It can often outperform hand-optimized Rust in worst-case parallel workloads (p99), despite Rust having a number of pretty huge advantages...
I will say this comes with the asterisk that it heavily depends on what your concurrent system/problems looks like!
...but more often than not when dealing with web problems and network IO, the shape of concurrency/parallelism I need looks exactly like Goroutines, and even as someone who uses Rust/tokio daily: the Go runtime is an incredibly engineered system that usually beats Rust in my experience for application dev tasks.
Anyways, I love Crystal's syntax around concurrency! I wish we lived in a world where it had tons of Google engineers optimizing the runtime :)
I don't think NCC is 2026 is anything like the NCC of yore. Some of the most incompetent assurance and security researchers I've ever met have come out of there more recently.
Hopefully this hack is a warning for anyone that might use NCC's services in the future.
Yes, not sure what the timeline was where trust was given to this company. Just horrible for the entire secure Internet. They've yet to answer many of the basic questions raised throughout this process too.
only a single tile in an unpopulated area reported a 9, I think is what he meant.
I can run OpenAI on AWS Bedrock and Azure. I cannot run Jev on those cloud providers. For the many companies locked behind cloud providers, we don't have the same options.
Should we compare Ellison to a lawnmower instead, as bcantrill so eloquently did?
I personally think object pascal, or perhaps think c, would be a better choice here.
I will not explain why.
I'm a bit confused why a decision to decrease the maintenance burden of Mold by switching languages makes Rust the wrong tool here? Fearless concurrency sounds like a huge benefit for what they're doing, given the resources they have.
It was never built with an open source community in mind. It was always DOA in a world where Rust existed.
It would be amazing to have big BERTha with per-token pricing on GCP or AWS. There are many times I am reaching for a cheap classifier with the general behavior of an LLM.
I've switched off to runners and event scheduling inside AWS, and am working on moving my company off of GitHub. I know engineers inside GitHub and it doesn't sound like the talk they've been putting out about reliability is actually being addressed with many resources internally; the best people in the company are chasing AI product features (which are apparently quite profitable).
Yes exactly. Automatic model downgrade seems horrible for a lot of production workloads, even if you are deterministically constraining the behavior of your agents.
I don't think the person describing the paper by Buckmaster as the same as the 2023 paper by Córdoba and Martínez-Zoroa is really discussing this in good faith fwiw. There are some massive advancements within it and if the person was participating wasn't just regurgitating something to "win the argument" in their eyes, they wouldn't describe it that way.
>It's unknowable and not possible to prove if any one specific conversation was the key to solving Navier–Stokes.
If the conversation was in the training set, there's a high likelihood that the small set of conversations related to solving Navier-Stokes was used by the model. I get Astra to still quote some of my friends' books or blogposts nearly verbatim on certain niche issues.
Much more importantly, we _can_ determine whether a conversation was used in the training data. And if it was, it gives us a great idea whether that logic was captured in reasoning for a novel problem never yet solved.
Given that you don't see any of this as below the belt according to your other comments, maybe your contribution here is more for yourself than a fair conversation about attribution.
It's unclear if you're suggesting that OpenAI did not train on their input or use their chats as inputs to training on a model that found the solution. Let's not provide an Elizabeth Holmes-esque interview where the question is dodged and words gain new meaning. The question can be answered with "Yes, we trained on their conversations" or "No, we did not train on their conversations".
I'm not coming from a place of distrust here. This should just be definitively answerable given the weight of the claims here. Surely between you, your lawyers, and other members of your team you can just clear this part up.