I went deep into to the PKMS rabbit hole a year and a half ago, benchmarked Obsidian and many many others, and settled with Trilium¹ which I can only highly recommend. It addresses all the hosting/deployment requirements of OP² without the quirky workarounds mentioned here (syncthing & al), and makes the kind of "lifestyle scripting" this article about very simple and straightforward.
In my mind and experience, Trilium has a very unique and extensible model that lends itself to "growing with your PKMS": notes is the atom of information, attributes can be used to manage notes as structured and relational data, templates and inheritance provide structure and consistency at scale.
Trilium may not look like much on the surface, but it is incredibly capable while being approachable. Give it a serious try.
²: you can use Trilium local-first/only, or cloud-only, or hybrid. It has its own sync protocol, you just point your instance to a server to sync with, and now you have a master-master replication. All my notes are available offline so I can keep working in-flight, notes shared with others are available via web whether I'm online or not, and I can edit my notes on the web where I don't need offline persistence. All of that is built-in/native to Trilium.
Marginalia needs to solve problem #1 (OCR), which is luckily getting commoditized by the day thanks to models like Gemini Flash. I've now seen multiple companies replace their OCR pipelines with Flash for a fraction of the cost of previous solutions, it's really quite remarkable.
Problems #2 and #3 are much more tricky. There's still a large gap for businesses in going from raw OCR outputs —> document pipelines deployed in prod for mission-critical use cases. LLMs and VLMs aren't magic, and anyone who goes in expecting 100% automation is in for a surprise.
You still need to build and label datasets, orchestrate pipelines (classify -> split -> extract), detect uncertainty and correct with human-in-the-loop, fine-tune, and a lot more. You can certainly get close to full automation over time, but it's going to take time and effort. The future is definitely moving in this direction though.
Disclaimer: I started a LLM doc processing company to help companies solve problems in this space (https://extend.ai)
I’ve had success twice using targeted social media outreach — specifically by joining relevant subreddit discussions and commenting on YouTube videos where my target audience was already active.
Instead of simply promoting your service right away (it often feels spammy), I recommend genuinely engaging in conversations until the right opportunity comes up.
This is exactly the problem. Hyper efficient (or at least trying to be) businesses have no room for craftsmanship. If you take the time to make quality software, you’ll be left behind by someone who doesn’t. Unfortunately the market doesn’t care, and therefore efficient businesses don’t either.
The only solution I know of is to have a business that’s small enough and controlled by internal forces (e.g. a founder who cares) to pay attention to craftsmanship.
Having the chats in Obsidian lets me save them to reference them later in my notes. When I first started using it in VSCode when programming in Python it felt like a lot of noise at first. It kept generating a lot of useless recommendations, but recently it has been super helpful.
I think my only gripe is I sometimes forget to turn off my ollama systemd unit and I get some noticeable video lag when playing games on my workstation. I think for my next video card upgrade, I am going to build a new home server that can fit my current NVIDIA RTX 3090 Ti and use that as a dedicated server for running ollama.
A vice president once asked me how I was able to get effective change in large organizations when no amount of exhortation on the part of senior management had been successful. I pointed out to him that the people who resist the change the hardest are the ones who cannot see what their job would be post change. As a result the change is perceived as an existential risk to their own job and they will go to great lengths to sabotage the change because of that. This is the Shirky Principle embodied in individuals, and small groups some times too.
I'm the author of the osxphotos[0] tool mentioned in the article. For photos in an Apple Photos library, osxphotos gives you access to a rich set of metadata beyond what's in the actual EXIF/IPTC/XMP of the image. Apple performs object classification and other AI techniques on your images but generally doesn't expose this to the user. For example, photos are categorized as to object in them (dog, cat, breed of dog, etc.), rich reverse geolocation info (neighborhood, landmarks, etc.) and an interesting set of scores such as "overall aesthetic", "pleasant camera tilt", "harmonious colors", etc. These can be queried using osxphotos, either from the command line, or in your own python code. (Ref API docs[1])
For example, to find your "best" photos based on overall aesthetic score and add them to the album "Best Photos" you could run:
To find good photos with trees in them you could try something like:
osxphotos query --query-eval "photo.score.overall > 0.5" --label Tree --add-to-album "Good Tree Photos"
There's quite a bit of other interesting data in Photos that you can explore with osxphotos. Run `osxphotos inspect` and it will show you all the metadata for whichever photo is currently selected in the Photos app.
One of the best things I ever did was get strong through a basic barbell training program called Starting Strength.
Squat, deadlift, overhead press, bench press, chinups, eat, sleep. It really is that easy.
Highly recommend it for anyone interested.
1. Any back pain I had disappeared completely.
2. When I have to lift something awkward (eg, furniture), I don't injure myself. If you can deadlift 200KG, awkwardly leaning over your lawn mower to grab a 20KG bag of concrete is pretty easy.
3. It is really really handy being able to move heavy things.
4. Basically everything else improves. Going for a tough hike uphill? Your legs will be a lot less sore if you can squat 150KG. Need to hold your screaming baby for 40 minutes? Easy!
The problem with these kind of pixel-perfect, inspectable design tools, is that there's no distinction between important details and unimportant details.
For example, if our app uses a letter-spacing of 1.2 for all the body text, and your Figma design uses a letter-spacing of 1.25, is that important? Or is that a mistake?
In something like Figma, being consistent is difficult for designers. But in code, being consistent is the default — exceptions are hard for developers!
There's a fundamental mismatch that just ends up being painful all around.
"The map is not the territory." Trying to get a design doc to 100% accuracy is often a waste of time. Design tools need a way to specify which details are important, and which are not.
The Art of Electronics is a wonderful book and you can certainly learn from it. I don't think it's useful as a reference, but it is a little opaque to someone new.
But, now there is https://learningtheartofelectronics.com/ Learning the Art of Electronics, which is a practical course with labs to complete, etc. It is very, very good. I am using subsets of it (with scaffolding/additional practice) to teach smart middle schoolers to design transistor circuits implementing amplifiers, oscillators, and logic gates.
TLDR- the founder quit, a bunch of suits took over, they gutted the dev team and put the app on life support for years. Bugs piled up and nobody could fix them so they outsourced to a new offshore team who rewrote the whole thing in Electron... which of course was waaay too little, way too late.
Ooh, I’ve been doing nothing but this for 30 years. There’s other good advice in this thread, but my main advice is to pay close attention to people. UX is just applied psychology. If you understand humans well enough then you can create good solutions for them. It’s not surprising — you won’t create a good cat toy if you don’t understand cats.
1. Keep learning how humans use software. This is rooted in our physiology, psychology, and culture. It’s remarkably sticky across different contexts, and it’s learnable. Watch people using software; get them to talk about what they’re doing. You can do this in a lightweight way with coworkers — “Will you show me how you do X?” Then pay close attention and ask questions.
2. Prioritize task context and workflow. For the most part, UI design is not nearly as important as workflow. How does a user get from where they are to a solution? Whatever solution you design must meet the user where they are, where they have the problem. So be very sensitive to user context — as you watch people use software, pay attention to where they start, and what expectations they bring with them.
3. Document and maintain concrete goals for all design work. Before you design, write down a small list of goals in the user’s own language. “User stories,” we often call these. As you work, keep going back to that list to make sure that you’re staying focused on what users really need, rather than what you think is cool. As you use new software, try to reverse engineer this list of goals — “What were the designers thinking? What did they expect me to do here?”
4. Check your ego, and learn to love being wrong. Put unfinished work in front of people. Cheerfully accept all feedback without explaining or defending. Always expect that your design solutions are not good enough, and can only be improved by testing them with real humans. You are not your user; you must position yourself to be surprised by them, and to react well to that surprise.
> she used the Yamaha CS-80 as her main composition instrument. She seemed to favour it particularly for its touch-sensitivity, and it was one of the few synths that offered the feature at the time.
This undersells the CS-80. It had polyphonic aftertouch, which most synths don't have today.
Most have velocity sensitivity, meaning each note transmits how much initial force you applied. And most have aftertouch, meaning they transmit how much force you continue to apply after hitting bottom. But for most it's just channel aftertouch, meaning it transmits the aftertouch of the key you're pressing the hardest.
The CS-80 transmitted aftertouch of each individual key, and had nice controls to to adjust how it used that information. A lot of synths can use polyphonic aftertouch but only a few new ones actually have poly-AT keyboards. The ones I know of are the Hydrasynth (out for a couple years now), the Behringer UB-Xa, and the Iridium keyboard (both introduced this year).
Vangelis was also a huge CS-80 fan and used it on the Blade Runner soundtrack. Incidentally, a boutique synth that replicates the CS-80 pretty well (without keyboard) is the Deckard's Dream. It's $4000 but that's way less than a vintage CS-80.
I have started doing something completely different than using bookmarks. I set up yacy[1] on a personal, internal server at my home, which I can access from all my devices, since they are always on my wireguard vpn.
Yacy is actually a distributed search engine, but I run in 'Robinson mode' as a private peer, to keep it isolated, as I just want a personal search of only sites I have indexed.
Anytime I come across something of interest, I index it with yacy, using a a depth of 0 (since I only want to index that one page, not the whole site). This way, I can just go to my search site, and search for something, and anything related that I've indexed before pops up. I found this works way better than trying to manage bookmarks with descriptions and tags.
Also, yacy will keep a cache of the content which is great if the site ever goes offline or changes.
If I need to browse, I can go use yacy's admin tools to see all the urls I have indexed.
I have been using this for several months and I am using this way more than I ever used my bookmarks.
My take as a TPM and certified in Scrum: the better and more skilled the team members, the less you need Scrum and other frameworks. Scrum is great for teams composed of new developers who don't yet know how to work together, or teams at companies with poor culture. But the best teams are self-organized and don't necessarily need the guidance of Scrum. As Gergely mentioned, team autonomy is a big factor in job satisfaction (and performance).
But, it can still be worth doing in high performance environments if specific things are needed. Part of being Agile is adapting processes to teams, and some Scrum processes can be useful (relative estimation for example) even when not doing Scrum itself.
As an aside, Gergely has a newsletter[1] (of which this is one of the free articles) that is absolutely fantastic. It's $100/yr IIRC and well worth it. Gergely deep dives into topics around tech including hiring, structure, comp, etc.
Gergely also has a book[2] that helped me get hired in SF when I moved here a couple of years ago.
People are commenting this post and saying it is speculation, and until someone who directly was involved in these discussions shows up to comment, I suppose it is.
I have been in design meetings with Jony, and Scott Forstall, and many others whose decisions were micromanaged by Steve at every step. You can argue that a lot of Steve's design decisions were questionable; rich Corinthian leather skeumorphism, lickable Aqua widgets, brushed aluminum window title bars, but he owned them.
Steve and Jony would sit for hours outside of Caffe Macs going over designs. Steve would spend even more time inside the industrial design area going over prototypes. He would spend a couple of hours every week meeting with every software team that had user facing features. He had input on almost every pixel on the screen and every button/port/display/etc on hardware.
Once he was gone, the drift began. It was inevitable that focus would shift. Scott no longer had protection by Steve. Jony fixated on the new campus and things like watch bands. No one had Steve to rein in whatever impulse they had. Sure, people would ask "What would Steve do?" but we also had Tim Cook pushing to optimize production, lower cost of goods and increase margins.
Apple still has Steve DNA, but it continues to be diluted. You may disagree with Steve's vision and opinions, but it was strongly held and enforced. I feel almost everything about the last generation of MacBook Pros went against what Steve would have wanted and I am glad I wasn't there when those decisions were made.
Super tangential and subjective, but I found the writing in the Mass Effect games subpar. I know a lot of people think the opposite. I've spent a fair amount of time looking for games with writing I like, but it seems to be an uphill battle. Someone suggested to not play for writing, which somewhat makes sense and has led me to do more reading, which I've been thoroughly enjoying. I replaced looking for games with looking for books and find it more rewarding. That said, for the purposes of a survey, if nothing more, what game stories did you enjoy?
To start it off, Kingdom Come: Deliverance was a big deal for me (though not sure if I especially liked the story or just that it didn't get in the way), and Planescape: Torment is a favorite too (still remember the wonder with which I explored it the first time).
All of this said, I've recently found Foam hard to beat. Awesome markdown "thought web" experience built right into VSCode. Refreshing approach after years of mediocre Electron apps
FWIW, I just took a look at our HFT trading system. We specialize in colocated low latency market making in an equity market in a mid-sized country. The following line counts are only for the C++ code directly used in the production system. Doesn't count research, model fitting, ETL pipelines, build systems, etc.
75 kloc - Total line count
10 kloc - Common libraries, utilities, data structures, etc.
10 kloc - Reconstitutes the limit order book from the data feed
10 kloc - General framework (order management, margin tracking, logging, runtime control hooks, etc.)
13k - Adapter for the exchange's datafeed protocol
5k - Adapter for the exchange's order gateway protocol
3k - System for correlating our orders within the datafeed
10k - Signals/alphas
8k - Trading logic
Not claiming that other people's systems will necessarily look anything like ours, but my experience jibes with this too. Trading code is only about 10% of the total codebase for a production-ready trading system. Overall strategy-specific code (signals and trading logic) only make up 25% of the codebase, with the rest being all general-purpose "plumbing".
Even a tiny inconsequential function that most people never think about- reliably identifying which orders in the data feed belong to us- takes nearly half the amount of code as nearly all the trading logic put together.
For general household stuff, my go to store is manufactum.com
They only offer very few things, but the things they have are very high quality. If you buy something from Manufactum, you know it'll last for the rest of your life.
The stuff there is of course outrageously expensive compared to the plastic crap from Amazon, but for me that means I really think about the purchase. Do we really need two of those metal baskets for the shower that hold your shampoo bottles? Not if it costs 100€.
For tools, there's dictum.com, which follows a similar philosophy. They don't offer a million choices; they make a very deliberate choice which products they sell, so you don't have to make the choice. You can rely that something you order from them is a good choice.
In my mind and experience, Trilium has a very unique and extensible model that lends itself to "growing with your PKMS": notes is the atom of information, attributes can be used to manage notes as structured and relational data, templates and inheritance provide structure and consistency at scale.
Trilium may not look like much on the surface, but it is incredibly capable while being approachable. Give it a serious try.
¹: https://github.com/TriliumNext/Notes/
²: you can use Trilium local-first/only, or cloud-only, or hybrid. It has its own sync protocol, you just point your instance to a server to sync with, and now you have a master-master replication. All my notes are available offline so I can keep working in-flight, notes shared with others are available via web whether I'm online or not, and I can edit my notes on the web where I don't need offline persistence. All of that is built-in/native to Trilium.