Not to be a curmudgeon, but why are they spending time on this? As an enthusiastic Raycast user, I would prefer to see them focus on making Raycast better, not finding new ways to jump on the AI bandwagon.
Welp this is what happens when the USA is spending more into this than it did in the space race comparatively. Space race we got to the moon, the AI output has yet to show profit from businesses other than funding the input.
I had the same reaction. They've had Raycast releases paused for some time to focus on large feature improvements, but I wondered if it was partly for this.
This seems a natural evolution of Raycast Extensions (which are an evolution of Script Commands) - given the current landscape (generative everything). I would be surprised if there’s no “Raycast inside” within and around the new toolchain.
I’m torn about what this likely means for iOS; while I do want to do Raycast-y things in my phone, I’m not sure there’s enough of us to make a business out of it.
I think this is less about the projects themselves and more about distribution channels like HN and ProductHunt being dead. When the zone is flooded by vibecoded apps of all kinds, the "build it and they will come" era of getting your thing on a popular website's homepage is over.
But other distribution strategies exist. You just have to be smarter about finding and getting in front of your core audience.
Agent orchestration seems to be the new hot problem to be solved in the ecosystem. See also Steve Yegge's most recent posts [1]. Curious to see what tools emerge as the winners of the Cambrian explosion we're probably about to see.
Totally. Yegge's post was fascinating and there was quite a bit of chatter about it internally at my company . I have this feeling that if I could just figure out how to effectively direct 10-20+ coding agents at once, I could supercharge my productivity and bug squashing skills. In some ways his post introducing a suite of new terminology helps to set the stage for this being a whole new world of being a SW engr.
There won't be a single orchestration winner, orchestration will just become ubiquitous in LoB systems. Slack and Github will probably be the biggest targets but it's pretty simple to create a chat bridge that supports adapters to support discord/telegram/etc and you can already do webhook orchestration easily enough.
This is what we are looking at at one of my clients. A2A clients (Slack, Google Meet, considering email) to A2A Orchestrator server (in-house, might be open-sourced) with specialized subagents for e.g. GitHub issue creation following a specific teams patterns and conventions, hooked up to company-wide MCP gateway with federated OIDC trust for passthrough auth (https://www.gatana.ai)
Works pretty well so far. Biggest issue i foresee for success is user UX for average employee, and actually useful use-cases.
I always liken it to using Uber in ~2012. It was fun to get around major metro areas for dirt cheap. But then prices rose dramatically over the next decade+ as the company was forced to wean itself off of VC subsidies.
Ever notice that even where Uber doesn’t operate most of ride sharing alternatives work pretty much the same way? Go to South Asia, China, Middle East, or South East Asia.
Consumers pick those services because of what Uber pioneered — trust and convenience. You know exactly how much you pay, you pay everything upfront, you know you are dropped off where you need to be. There are of course exceptions, but exceptions they are.
Cost maybe the initial selling point but people stick with Uber and similar services despite higher cost, not because they don’t have other options.
Not everywhere. Here the government fucked Uber etc. big time because it required the companies to pay for taxi licenses if I remember correctly.
That is if they want to deliver a taxi service.
I'd definitely agree with you on that one. Also notice how the company doesn't push monthly subscriptions on people and just lets their program exist out there.
I don't think it's better than org-mode, but org-mode is also post-2000 so doesn't count here. Obsidian isn't open source, isn't plain text enough, and is slow.
Markdown also falls outside the pre-2000 window as well. But, it's closely based on email and news conventions.
What do you mean by "isn't plain text enough"? I haven't used it, but the only thing I imagine would be indexing with a database, but you can just use plain text tools like grep (or rg) to fill the gaps.
In theory, it's significant better than org-mode, because Electron has much more abilities than Emacs. In reality, it's a matter of taste and personal requirements. Obsidian is customizable, so you make it do whatever you want, and there are many addons available; but org-mode has also a very specific focus on the type of addons being available and builtin stuff it has, were Obsidian is more lacking I would say.
> Obsidian isn't open source, isn't plain text enough, and is slow.
It's very fast for what it offers. And "plain text enough" is again a matter of taste. It's all plaintext, but delivering a useful and very powerful interface on top of it. The kind of area where Emacs is lacking.
I am not aware of what abilities Electron offers that is lacking in Emacs. Can you give a couple of examples?
There's little you can't do with Emacs given it's a small C core running a Lisp interpreter and both the Lisp code that make up Emacs features and the compiled core are open source.
Emacs is a text-interface, character-based, there is no pixel-control. So everything graphical or pixel-related is mostly impossible, until it gets special treatment or involves some hacks to allow some very special limited usage. Electron on the other side has webstack and it's full range of abilities for GUI, mouse-interaction, video, fancy font's, even a freeform canvas and some more...
I backup my Obsidian vault weekly by blindly committing the stuff in `.obsidian` and then reviewing the changes to the `.md` files themselves. It's not version control, per se, but at least a backup and record.
Being familiar with both KDB and somewhat so with InfluxDB .. it strikes me as a challenging space. I suspect there just isn't much money in it.
Oddly InfluxDB has raised amounts of VC money approaching KDB parent companies current market cap. I know VC raised and market cap are not directly comparable, but what is the hoped-for enterprise value at exit of NewCo if the IncumbentCo is worth Z?
My take is that orgs with real revenue-generating time series data challenges, budget and dev staff to cook up solutions have long ago bought KDB licenses or rolled their own in-house column store.
Orgs using time series DBs for telemetry/observability/etc type of "back office" problems (where you are willing to downsample/conflate/offload history) either don't want to pay a dime, or want a fully formed SaaS solution with pretty GUI, alerting, etc like a DataDog they will like $10M/year to.
Also K (1993) and A+ (1988) although the former only became public in 1998 or so, and the latter in 2003 - they were only available inside Morgan Stanley in the beginning IIRC.
I was working in K2 in 1999, and it was public then. This is back when it had the built in GUI and dependency graph. I remember the first time somebody showed it to me, and I didn't think it was very impressive. It took about 2-3 months of messing with it before I realized how very wrong I was.
We used a customized version of OpenTSDB at eBay to do monitoring of everything on the platform, including the search infrastructure. This was during the time eBay built a private cloud.
RRDTool was the generalised version of the TSDB that was born for the specific use case, MRTG. It could be used for anything. Hopefully I've remembered that correctly!
I bought this book on this recommendation and I don't agree that it should be called great. It did a good job of enumerating (what I presume to be) every major component of power systems. However, it didn't to a great job of explaining how any of those components work.
One example is capacitor banks, which it spent a few pages on. I'm told that they're more beneficial the closer to an inductive load they're installed, but I was never told why, or given any tools to figure it out why for myself. There's not even a citation.
After reading this book I have a better understanding of how much of the grid I don't understand, but I don't feel like there's any part I understand particularly better.
Highly recommend A History of Modern Computing [1]. Starting with the ENIAC in the '40s through the successive generations of computing technology in the 20th century, it gives a fantastic overview of the field's history.
Sadly, now that I look into it, it looks like it's out of print. There are a few copies available on Amazon, so act now!
I think that the best sections in this book are on the 1950s through the 1970s: the mainframe and minicomputer eras, and the beginnings of the Internet and personal computers. That's all in the first edition.
