How is it not lights-out? You could remotely power on/off the servers (XServe only). Other Macs could not do this, as they did not have the separate LOM network interfaces, etc.
I managed a bunch of XServes for a while, they were incredibly good hardware. The Mac Server software kinda sucked (not the LOM stuff, it was as good as any of the LOM from Dell, which is to say, not amazing, but workable).
I managed a large enterprise CF account from 2018-2023. Hundreds of load balancers. The UI changed out from under us 3 times, with some big problems being fixed, but introducing new ones. I gave bold feedback directly to the leaders responsible for this, with helpful suggestions on how to make it better.
I was really glad when they fixed the old one that had a big "X" that would delete your load balancer without a warning dialog. But I was not happy that the load balancers got increasingly complex, with settings hidden at multiple layers that you had to independently configure.
Load balancing IS complex, but this is their core business, and in many other places such as DNS, Cloudflare put a lot more thought into making it simple and intuitive to use.
Getting this stuff right takes lots of strong leadership and long-term decision making with determination and wisdom to provide the best experience for customers. Unfortunately I am not confident that is how the business is operating, especially with strong talent being let go or leaving due to lack of fostering of a healthy working environment.
I am not a power user for Dendron, I mostly just use it for journaling, keeping track of who is who and what is what, and organizing architecture / ideas before they find a home somewhere else. Mostly a journal.
I do like that it’s in VS Code and I can leverage those tools and now, AI, to help.
The main functionality I use is the new daily journal from template feature. Do you use more surface area from it? What is the most useful features for you?
Sure, but I would say you are an outlier in paying for those things. Most people use what's immediately available, others might search for something better that's free, and very few will go pay for something.
That last category of people are also now likely to go create something themselves with AI, but don't really want to or can't start a business from it, so they may add it to the pile of free software others can use.
Not everyone HAS to profit from their work, though I do think those who make it their passion might benefit from finding a way to do that.
How many text editors have you paid for, versus how many have you used for free?
I do think there is room for a few good paid text editors in the world, but most people won't pay directly for them, though they might use them if they are bundled ala Google Docs / O365 Word.
Simple utility stuff I believe should fit in this category. Things like a text editor.
The profit comes from elsewhere, larger more complex systems.
Of course someone can TRY to profit off a text editor, but unless it solves complex enough problems (like a full blown IDE, but even then...).
The issue is there is intense demand for it, and ALSO easy supply. If someone attempts a profit driving rugpull, another will pop up in it's place.
I am still using Dendron because it meets my needs, but I'm always half tempted to replace it, and I'm fairly confident I could come up with something that meets my own needs in a day or two, and it would likely also be valuable to countless others. I just keep assuming that someone else will spend that day or two, and my pain points with Dendron are not that bad for me to spend the time.
Hah, I think about this all the time. I think we subtly desire LLMs to be more and more deterministic and efficient. This is why one of the main uses of LLMs is building tools to make their job easier.
I made my own project, with one of the goals being discounting tokens, but found that the real goal was just ensuring quality and making things more programmatic.
Basically ends up being agents.md in a schema driven yaml file. Thinking about extending it to also generate or replace skill.md.
I think the proliferation of markdown is cool, and lowers the barrier for entry, but it’s also very unpredictable and loose. I think over time we will drive these to be more like config files instead of free text.
Love TypeSpec, agree it makes writing OpenAPI really easy.
But I’ve moved to using https://aep.dev style APIs as much as possible (sometimes written with TypeSpec), because the consistency allows you to use prebaked aepcli or very easily write your own since everything behaves like know “resources” with a consistent pattern.
Also Terraform works out of the box, with no needing to write a provider.
It mostly does, if you write it well, but it’s less efficient than XML, you have to write it by hand, and there’s no way to “validate” that it’s any good.
This is basically a structured, efficient version of claude.md.
Every time you launch a new Claude Code session it will need context for the codebase. Rather than letting it spend a bunch of tokens looking around and discovering it, why not provide it with a compact, high quality version?
Ktext has two parts: a CONTEXT.yaml which adheres to a JSON Schema, and the ktext CLI that helps create, validate, and export it.
Was going to launch later this week, and the site needs some tweaks, but the tool is ready.
I started building one of these myself, and got something working decently but decided it was too complicated and didm’t really provide value. I then saw GitLab Knowledge Graph. It does this, but even Claude says it’s not very efficient or helpful for the large code bases I pointed it at.
I pivoted and created something way simpler, but solving a different problem. Making the basic context really efficient and high quality.
Out of curiosity, why did you reject Floci? It lacked some feature I needed, so I just went ahead and added them. My needs were not that complex and it has patterns to test that implementations match AWS. I agree it’s lacking things, but the bones aren’t that bad.
- It is too machine like in its definition and requirements and misses the spirit of the ask.
- It very much waterfalls it, without asking for feedback midway, or revisiting the original goals after things have been built. You have such an opportunity to adjust and learn as you go, especially if you keep revisiting your goals and values and re-evaluating your original requirements which may have been flawed.
Just like with human development, it's rare that your spec is well thought out at the beginning, and impossible that it was comprehensive enough to define a working system.
I think having goals, vision, and hard requirements make sense, with some guiding principles along the way, but it's very much a journey that requires constant feedback loops and adjustments along the way.
I managed a bunch of XServes for a while, they were incredibly good hardware. The Mac Server software kinda sucked (not the LOM stuff, it was as good as any of the LOM from Dell, which is to say, not amazing, but workable).