LogSeq has other note types; it’s just the default is bullets.

LogSeq is about as future proof as you can get. Notes are stored in a directory tree as markdown files.

Maven and later gradle, groovy and spring boot really made it more fun to use.

There is no better example of “to each their own.”

I started programming Java professionally when it was still called “Oak.” I was working at a University doing distance learning stuff and applets were incredible. They were also the thin end of the wedge, although I didn’t know it at the time.

I watched over the years as a nice, concise, core library of a dozen packages swelled like a bloated corpse. The last core library book I contributed to was larger than War & Peace, a veritable tome just to describe the standard library.

And then tooling like Maven and Gradle came along, and frameworks like Spring Boot became unavoidable, and I found more of my time was spent not programming but trying to detangle some horrible maven build config. In XML. That’s about the time I jumped ship.

My philosophy is: tooling is fine, but if it takes over the project so that it’s impossible to build the project without it it’s not tooling anymore, it’s a framework - a platform - that you’re locked into. You get to spend your time debugging issues with the framework, over which you have no real control, where your best hope is work-arounds and crossing your fingers that upstream fixes their shit before your work-around becomes permanently engraved into the build.

It’s funny to me that what I saw as bloated distraction, a hateful corruption of simplicity onto layers of obfuscation that themselves became platforms needing maintenance and debugging, would have been a pleasant and even fun addition to the ecosystem.

This is the candidate AIPAC bought. Hope they’re happy.

Try it, it’s good. There’s a mobile app, for Android, at least. It’s free; it only takes a little time investment, so low barrier for entry.

LogSeq is nice.

For this who don’t know, it’s well designed, in that it doesn’t add bloat and obfuscation like a DB would; it keeps everything in a filesystem structure in markdown files. What’s really nice is that this makes it something you can use with a plain editor, or with the application, or with the app on mobile; the app(s) add a lot of convenience functionality to the basic storage design.

It’s a well-thought-out system, and I appreciate how clean it is, and how independent of the application the data is. I haven’t looked at the code base, but I have a lot of respect for the developer must based on the design & architecture decisions.

I have a feeling you’re looking for something different, but: mine is a big todo.txt document that I open with fzf. I just add lines to it and tack on @keywords.

If your needs are more hierarchical and structured, I’d still try to stick with a plain-text and fuzzy-search based solution, and split stuff up into different files.

IMHO, you’re starting from a good place (plain text files). Maybe you just need a little tooling for searching and keyword filtering.

Fucking Deloitte!

Ah, so it has a “watch” mode? Cool.

Ditto.

I get angry with SyncThing; don’t get me wrong. I really wish they’d add a per-file-type merge plugin capability, and I get far more sync conflicts than I care for. I get situations where a client on one computer stops (mostly, Android killing it) and it needs to be manually restarted.

What I’ve never had it data corruption. It’s to the point where I implicitly trust that if SyncThing says it’s synced, I know it’s on the destination. It might be a stored as a sync conflict, but it’s there.

How is rclone fire and forget? You have you manually run it every sync, right?

“Crazy petty dictator lambasts other insane petty dictator’s plan to funnel money to cronies.”

This is a good list.

There are three kinds of Linux commands:

• commands I use frequently
• commands I’ve never seen or don’t know about. There’s almost nothing in standard POSIX that falls in this category, and a lot of OSS that does. E.g., I use to always reach for fuser until I realized it’s not a base install on many distros, so I switched to lsof which is is, and is also both more powerful and harder to use.
• commands I’ve seen before but use so infrequently I forget they exist, or what they’re called. This is sadly a larger set than I’d like.

Some of these in this list are the third kind.

Isn’t this more of a case of “driving while not white?”

It could be cultural. Even in the US, OP’s family could be in a cult. But they could be in a country where family is more important than in most Western countries. Or live in an oppressive culture where women are property - like where the US is headed.

I agree with you; I’m just saying it’s not always that easy, and if OP is living with their parents - because it’s a shitty time to be a young adult, impossibly expensive to find places to live, doesn’t have enough income, is going to college, or any number of reasons - they may have little choice.

They don’t mention enshittification - I think Doctorow popularized the term later - but this is a perfect example of a process that contributes to the phenomenon.

I had never thought about it in these terms, but they repeatedly mentioned curation, and it’s so clearly a fundamental topic in today’s online world.

This was an incredible video, thanks for sharing. It gave me a new perspective to consider.

Mine you, this page is clearly targeted at an audience who’ve never opened a shell before; they’re all quite common, and it’s almost impossible to have spent any time in bash, zsh, or any bash-ish shell without encountering or using these. Also, a couple are not going to work at all in non-standard shells like fish, nushell, or even more common shells like ash, BusyBox, or the venerable csh, because they’re bash built-ins. There’s dependency on the GNU toolset, too; some of these commands won’t work on FreeBSD, even when running bash, because the SysV tools have different argument lists.

Someone will probably step up. It sound like the big blocker is governance - there are people willing to contribute, but whomever has control is not doing a good job of administering the project. At least, that’s what I read between the lines.

Someone will probably fork it, get popular, then suddenly the original maintainers will find motivation, try to scramble to regain directional control, and be discarded because everyone lost faith in them.

Or, we’re really about due for a new generation. Snap’s a hot pile of steaming shit, Nix is simply awful for package managers to work with, Flatpak is directionless, Guix is like every other big GNU failed attempt to be an also-ran, and a lot of lessons have been learned from all of these. I expect someone will come out with something cleaner, leaner, and without all of the baggage; maybe with some backwards compatability with Snap, Flatpak, and AppImage packages.

Maybe not, but the situation is ripe for something like that. Just don’t let it be based on god damned Lisp. I respect the hell out of Lisp and Lisp machines, but I absolutely hate having to work with it.

Redhat, for at least a decade, has focused on services, with which I already said I have no issue. I haven’t seen or heard of anyone paying for Redhat just to get a base imagine with no support.

Ironically, it’s been in the news lately because of a talk given at LAS. Here’s a breakdown of the video, for people like myself who hate watching talking heads.

Basically, development on Flatpak core has mostly stalled. And there’s a lot of work yet to be done; efforts to rebase it on OSI, for instance.

Nobody’s claiming it’s dead; it’s popular and widely used by a lot of people - it’s just that nobody is actively maintaining the Flatpak project anymore.

Yeah, especially for text files. Hard no.

Databases have their uses, but the trade off between obfuscating the data and making it harder for users to access has to be far more compelling. LogSeq is a really good example that you can do relatively complex note organization with cross references and tree structure without resorting to a database. Using a DB for something like this is user-hostile, smells of vendor lock-in, and seems lazy.