The OP replies to it in such a way that discredits them, ending with "Very professional of you guys." They could have replied with an equal or more negative sentiment in such a way that wasn't counter-productive, and not have lost much credibility with me.
"does not matter if this is an isolated edge case. Data loss for 15 months with poor support isn't something that can be waved off as 'edge case'. The fact I had to go to Reddit to get someone's attention for this is insane. By the way, I tried reaching out to various 'senior management' personnel via LinkedIn last year and no-one replied. Escalation requests via the Support thread ignored and declined. Very professional of you guys."
and that seems pretty damn reasonable of a reply. the fact they had to go to reddit is insane. a sarcastic "very professional of you guys" is pretty tame, given the situation, and not discrediting at all.
Pretty mild when getting a reply that puts more energy into downplaying the problem than acknowledging that they've had an ongoing data loss issue for over a year and their support has been useless.
You did a commendable job of ignoring all the op's (from Reddit) explanations and context to come to this weird output.
OP even actually responded to a similar comment in this reddit thread - look it up and tell me he wasn't reasonable. 15 months of fobbing him off, and once the case has been raised publicly the very senior guy _suddenly_ sees it as a priority despite it being just an edge case.
> 15 months of fobbing him off, and once the case has been raised publicly the very senior guy _suddenly_ sees it as a priority despite it being just an edge case.
That's basically how this whole industry works? How would you justify the outrageous cost of product management layers otherwise?
Not saying that this is the right way. But it's not a very surprising story, no matter which company (be it Google, Microsoft, OVH...).
It's a perfectly understandable response to what is essentially just corporate damage control. I'd be pissed too if I was in their position.
They've been ignoring the issue for over a year, yet it somehow took them only 4 hours after the reddit post was made to determine that it's "an isolated edge case", even though there's at least one other user reporting the same problem. The comment was clearly written with a focus on saving face rather than properly apologizing for the terrible support.
I'm not sure if it would support inheriting from a custom store very well. It might get tricky with the templating. But the author of this seems to have done a good job of not ignoring inheritance.
Personally this library isn't to my taste - but I successfully use classes (without inheritance) along with reactivity primitives to create beautiful, tiny and high performance React applications
I went through the code, and it is roughly equivalent to doing it without classes. The nesting level in the example isn't deep - everything seems to be beneath a SnapStore or a SnapFormStore, without inheriting from user defined classes. I think the use of classes is fine, and the way that it's introduced in the blog post is good, it says "plain TypeScript classes". It is used as a means for ergonomically writing and understanding the code more than it is for setting up invariants or complex polymorphism.
It's hard to tell what this is or how it compares to other things that are out there, but what I latched onto is this:
> Freestyle is the only sandbox provider with built-in multi-tenant git hosting — create thousands of repos via API and pair them directly with sandboxes for seamless code management. On top of that, Freestyle VMs are full Linux virtual machines with nested virtualization, systemd, and a complete networking stack, not containers.
Edit: I realize the Loom is a way to look at it. Loom interrupted me twice and I almost skipped it. However it gave me a better idea of what it does, it "invents" snapshotting and restoring of VMs in a way that appears faster. That actually makes sense and I know it isn't that hard to do with how VMs work and that it greatly benefits from having only part of the VM writable and having little memory used (maybe it has read-only memory too?).
So the snapshotting tech is actually 100% independent of Git.
Git is useful for branching vs forking (IE you can't merge two VM forks back together), but all the tech I showed in the Loom exists independently from Git.
The hard part of it was making the VM large and powerful while making snapshotting/forking instant, which required a lot of custom VMM work.
> The hard part of it was making the VM large and powerful while making snapshotting/forking instant, which required a lot of custom VMM work.
I don't find "large and powerful" in reference to a VM to sound compelling. What should be large? The memory? The root disk? As I alluded to in my comment, I'm more curious about what can be made small.
Also I'm skeptical that if I forked a vm running a busy Gas Town that it would be very light or fast in how it forks. A well behaved sqlite I could see, but then I'd wonder why not just fork the storage volume containing the database...
So thats what we did. We've made forking a whole gas town performant in 100s of milliseconds. Try it — you can definitely see it working on free tier.
In respect to large and powerful RAM + Size is important but I was more-so referring to full Linux power. The ability to run nested virtualization, ebpf, fuse, and the powerful features of a normal Linux machine instead of a container.
Well that does sound pretty impressive then. And as a champion of open source it wouldn't make me feel like I was getting locked in because the regular speeds I could live with (on a server with KVM or a nested virtalization setup).
Before any of these Copilots, there was Project Aardvark. It was a summer project by Joel Spolsky's company Fog Creek Software in which they created a remote desktop product called Copilot. They made a documentary about it: https://youtu.be/YbrkZ07LKbk?si=LAYznsR6Zd1YdGkb
A big issue with WordPress is the GPL. There hasn't been much clarity about it and the interpretations I've heard from Automattic in regard to which code is and is not covered by the GPL come from Automattic, not from the GPL. https://redsweater.com/blog/825/getting-pretty-lonely
A little larger, a lot of the time, though I like a small initial commit better. Though just a little larger. Not so large that it is too large to show on a GitHub page. That means not using version control properly.
Usually when someone decides to share code with the world, they don't want to publish the actual development history. They publish the first version that is ready to go public as the first commit. With enough functionality etc.
> Not so large that it is too large to show on a GitHub page.
Maybe not applicable in this case, but Github has a ridiculously low threshold for when it starts hiding diffs. Probably a limitation of their new React frontend.
reply