This is a similar argument to "Dropbox is a feature, not a product" and it definitely rings true in this instance too. I remember the litany of applications that only supported sync through Dropbox. It had no ecosystem, it's saving grace was that no one yet was operating a service similar at that scale.
All the major AI companies are trying to manufacture their own ecosystems to become less disposable. They'll get away with it for a while, but only insofar as hardware prevents advanced use. Once we get that hardware[1] there will only be two types of AI companies: hardware manufacturers, and labs. Just like sync became trivial and ancillary, so will AI inference.
and alot of software still has only dropbox sync support. As every Cloud Storage Provider facing Consumers just implements their own propriatary bullshit protocoll so there is always only 3 supported Cloud Storages and usualy they are Icloud, Dropbox, Google Drive.
and the differentiating factor on hardware will be the seamlessness of the interface, in software. the combination of voice, eye tracking, swiping, capture of intent, being able to mumble to myself at a volume only my device can hear. The hardware needs to be little more than something that gets out of the way and acts as an input device with a battery.
Am I the only one who thinks Obsidian is perfect without plugins? Half the reason I switched to it from Anytype was that it was rather spartan in its offerings. If they announced tomorrow they would ban plugins, I would not care.
I wouldn't say "perfect", but to me it's clear that adding plugins could only make it worse, even without considering the security issues.
What I want from Obsidian is something that "just works". Adding third-party plugin would break this immediately since the plugins can either be straight up buggy, create conflicts with each other or simply become incompatible with new Obsidian releases.
And what I've seen from the community, with people having dozens of plugins installed, is giving me nightmares.
I can see why some would feel the appeal of plugins, and adding two or three can be fine, as long as you do your due diligence.
Otherwise it's straight shooting you in the foot.
I'm also switching back to Obsidian after a few-year stint on Anytype, and the Notebook Navigator plugin is the only one I have installed. This is (I assume) a UI-only plugin, which shouldn't need access to external network or processes, so a quite good candidate for sandboxed plugins.
That’s basically how I’m using it since I got wary about how the community plugins were being vetted. Core plugins and settings cover a lot. There’s one or two things I miss, but not enough to fork and review them myself so it’s clearly not essential.
I would encourage everyone remotely interested in Zig to have a look at Odin[1]. If like me, you read that article and found yourself muttering "what the hell," then you might appreciate Odin's simplicity and design consistency.
I am definitely in the minority here, but I am not a fan of the kind of meta-programming that Zig and Rust offer, with Rust being especially atrocious. In the two decades I've been programming I can count on one hand the number of times meta-programming was an appropriate solution to a problem I had. Every time I reached for it, I got bit. There's a reason "when in doubt, use brute force" is sage advice, it may not be fast and glamorous, but it'll be a hell of a lot less opaque.
I think the magic is still mostly in raylib in that it's a well designed API with high composability. It feels like playing and building. Odin is special in its own right.
There's no particular feature of Odin that really stands out, but where Odin outclasses every language available is that every single feature has been very thoughtfully considered and designed to have the least amount of issues. Once you work with it for a few months, it becomes obvious very quickly its vision is remarkably consistent, leading to a smooth and outright delightful development experience.
I will caution, if you are the type of developer who likes to pull in lots of packages and dependencies to start a project, it's not for you. There's no package manager, and rightly so[1]. You'll have to build most high-level systems yourself. But when you realise that most frameworks and dependencies are trivial to implement by hand, this won't be a bother.
If you're the kind of developer who loves building systems and doing everything yourself, you'll feel right at home.
Anytype is a well-made product, but its data format is somewhat opaque and like Notion suffers from significant complexity. I switched to Obsidian last year, which while proprietary at least gives me the option to move my data somewhere else if I should need to. Anytype doesn't make it easy to get your data off its platform.
I'm a web developer too, and I would like this to be true, but it really isn't. Words have meaning. "Native" implies that you are *directly* using OS-specific API's. You are not.
You built a Cross-Platform Desktop Application using Web APIs. That's okay. You shouldn't lie about that.
> a constant for every invention is my lifetime is "everyone else is only interested in puerile sex and entertainment, $LATEST_MEDIA is ruining us, 1984"
Every damaging invention in isolation isn't a big deal. The big deal is setting precedent and the accumulation.
> not puerile consumption.
I agree, it's more akin to seeing how much sawdust one can put in a rice crispy before someone notices. No one wants to eat sawdust, nor is there a mindless desire to.
> Package managers are now basically a requirement for language adoption. Doing it manually is not a solution, in an automated world.
Absolute nonsense. What does automated world even mean? Even if one could infer reasonably, it's no justification. Appealing to "the real world" in lieu of any further consideration is exactly the kind of mindlessness that has led to the present state of affairs.
Automation of dependency versions was never something we needed it was always a convenience, and even that's a stretch given that dependency hell is abundant in all of these systems, and now we have supply chain attacks. While everyone is welcome to do as they please, I'm going to stick to vendoring my dependencies, statically compiling, and not blindly trusting code I haven't seen before.
Relax, while mentioning the real world without any criticism for the soundness of the solution is absolute nonsense, some would say idiotic, thinking only in the absolute best solution given your narrow world view is not any better.
While I agree that my view is narrow, the "best solution" in question is what we used to do, and it was fine. There are still many places that manually manage dependencies. Fundamentally automatic software versioning is an under-developed area in need of attention, and technologies like semantic versioning which are ubiquitous are closer to suggestions, and not true indicators of breaking changes. My personal view is that fully automatic dependency version management is an ongoing experiment and should be treated as such.
All the major AI companies are trying to manufacture their own ecosystems to become less disposable. They'll get away with it for a while, but only insofar as hardware prevents advanced use. Once we get that hardware[1] there will only be two types of AI companies: hardware manufacturers, and labs. Just like sync became trivial and ancillary, so will AI inference.
[1] https://taalas.com/the-path-to-ubiquitous-ai/
reply