> I used this project as an opportunity to learn about Rust and FUSE file systems. I also think it's hilarious.
> Visitors interested in the code should note that this is
an irredeemably messy codebase—it's full of hacks, unidiomatic code, and wildly poor design decisions.
> However, visitors should also
note that that's okay. The
best way to learn something
new is to try it out for
yourself—and creating a mess
is a vital part of that
process.
I absolutely love this sentiment. Why do this? Because it’s fun. And messy. And sometimes, that’s okay. Not everything needs to be a product… sometimes it’s enough to do something because you can… or want to… or because $RANDOM reason. I’m very grateful to the author and whoever decided to submit it today.
As a college student trying to figure out where I wanted to go next (industry vs academia) I had an epiphany that there was intrinsic value in doing things. Even things that were neither novel (academia), profitable (industry), nor impactful (nonprofits).
While my career has found a balance between impact and financial sustainability, I have a special place in my heart for projects that are otherwise unnecessary but happen just because it brings the creator joy.
Even if it makes just you happy, it's impactful. You are the person others have to put up with. Making yourself happy improves the world for those around you.
>Even things that were neither novel (academia), profitable (industry), nor impactful (nonprofits).
You classifications are good but it's a bit simplistic. Generally across the spectrum people is looking for breakthrough (e.g. deep learning) and/or game changing (e.g. transformer) contributions regardless if you're in academia, industry, non-profit, government labs, etc. But for pure joy, it can be from any simple creative projects as you've mentioned or it can be giving up seats for the elderly in a crowded metro trains.
But there is no greater pleasure than to finish something, deliver it, get users in front of it, and get feedback you never expected from either grumpy or happy users. I think it's way more rewarding to try to work for profit, because while money is nice, profit also means it's so useful someone is ready to give you credit for future work (money) for what you did.
Not a universal experience. I receive little joy in money, beyond the basic needs it relieves. Shutting down a business that cleared $800M profit annul. was the best decision I ever made.
Profit doesn't inherently mean you've made the median experience of individual humans better, and is just as often to effect significant degradation. My biz was slightly on the positive, but I could have pegged an extra zero in profit if I had forgone scruples.
Aw, that's not what I hoped it would be. An actual file-based calendar UI is a neat idea, where you can (for instance) echo into a file to create a calendar event on the command line.
I don't have more than 10 entries per week. Partly because I prefer real work over meetings, so I work at a place that does not have a lot of meetings. And once you don't have many, it's easier to remember other appointments, no need to use a calendar for everything. So even if this had been a useful mapping of calendar entries into a directory tree, I would not have felt an urge to use it.
Could one use the txtai python libe to be told to train on the temporal relationships between events that pass through it as an fastAPI endpoint to a calender... then as the events head to whatever is holding them in the calendar - txtai is training and indexing, first on temporal notes, then on context. so you ould easly as it to give you a
"Show all the social events that happen on wednesdays with a dress code"
(but it learns the nature of certain events, when they occur and social clues around what /who /wheres are typically occuring...
"This venue typically holds events on W F S and the clientelle is typicalaly this, attendance that, rsvps x, cost ~$$"
the most amazing feature of the Google calendar web UI that has since been dropped was a way to schedule events with a human message - "30 meeting with Bob next Tuesday at 10", rather than clicking a bunch of buttons in a UI.
I remember that! I think they have just collapsed to handling what most people try, evidently '[time] description'.
A couple of weeks ago I was surprised and annoyed that adding an event with description "10:30-11:00 Pointless Meeting" no longer scheduled my Pointless Meeting. Tried again very carefully. Wasn't working. Worked again the next day. Did anyone else experience this?
I can't wait for them to feed my description to an LLM to generate the event. "Schedule drinks at 7 at the bar behind the office next Tuesday. Invite my favourite colleagues and their teammates. Make them curious but not suspicious."
Well in a CLI you're not writing full English sentences. You don't say "make a directory called xyz in the current directory," you're saying "mkdir xyz". I'd rather just use a GUI than type out a full natural-language sentence.
With Google Assistant you can still do this, but you need to speak it, with the prefix "Add calendar event..."(well, Google Assistant on the phone also accepts keyboard input). I find it much faster than the button clicking.
Similarly in iOS there's some surprising: "Move my 3pm meeting from today to tomorrow 10am", and a clutch tip: "Hey Siri, Delete All My Alarms", b/c there's no UI to delete and confirm the 100 alarms that accrue of "7:00am, 7:05am, 7:07am, 7:15am, ...etc..." ;-)
Not this exactly, but I used to keep a calendar as a text file, where each day was a single line containing the date, week day and possibly some events.
Something like:
4h sun: 1500 dentist's appointment, 1800 dinner with friends
Where a=jan, b=feb, c=marc, ... l=dec.
The initial file was autogenerated with a 10-line Python script.
You can have variations on this, like allowing multiple rows per day, one row per event.
I also used to keep an unstructured "journal.txt" file, where notes were separated by two blank lines, and you could reference topics (like #toRead) and dates (like #4h24) with #, like social media hashtags.
I was thinking about this and came to the conclusion that I'd want to define some events per date, like you illustrated (`"12:30 dentist" > /cal/2024/08/04`), but others I'd like to define per event, like `2024-08-23 12:30 > /cal/massage`, which seemed messy. I didn't really resolve this question for myself.
I wasn't considering making it a virtual filesystem. My main goal was something that's editable with any text editor and syncable with SyncThing. I guess denormalization doesn't necessarily mean that these requirements are not met.
The point of such fake filesystems (like /proc or /sys) is that everyone immediately understands them. Yes, you could have a syscall for /proc, but it is more complicated.
That reminds me of a just for fun plugin I wrote for my (long dead) Dropbox-like file sync solution Syncany that would store the shared files as PNG images on Flickr.
At the time, Flickr and Google Picasa (now Photos) gave you like 1T of image storage for free, so I thought it'd be a dope backend. It worked really really well actually... And it was nice to see your data as images. Though since the files were packed and encrypted, it just looked like static.
It stores file data as calendar events, sort of like that YouTube FS from a while back
This is probably considered abuse under the ToS since you're using more storage than any typical user, and they can't use it for whatever they normally sell customer data for
I seriously doubt this kind of stuff has ever messed with their bottom line. I think they just really resent users trying to do more with their service than they intended.
I think this is a ridiculous sentiment, but I understand why it's so common. Proactively trying to head-off any and all possible problems before they cause measurable impact is not a great way to manage a product.
Maybe they did see impact, but I still would have rewarded non-abusive loyal customers for using the product—maybe restrict access based on resource-usage rather than hitting people with TOS violations. Instead this attitude (plus their generally very poor track record at supporting and improving their own products) has caused me to abandon all google products outside of work.
I appreciate that they made the calender system pluggable. Don't want to get locked into a single calendar vendor with something as important as your file system!
In exploration terms I suggest considering typical serious desktop users file taxonomy, most after at certain amount of time choose a timeline taxonomy of some kind simply there is no much easy way with files and folder to collect and access data, even with {sym,hard}links.
Essentially time passing is a common thing for anything, all of the rest quickly became dirty or at least have some dirty dump of information here and there. Long story short it's a nice potential continuation of the experiment start taking notes in timeline, storing files in timeline and figure out how to make "dynamic hierarchies" that works well in this model.
I've done something myself with Emacs/org-mode/org-roam notes, with kind-of daily notes and file attachments, it's not perfect nor general but scale a bit. A filesystem approach it's uncharted but seems to be equally possible.
This is unhinged and I love every part of it! Apart from the repo having an attitude I often miss from the modern internet I also learnt something reading the code on how FUSE works!
Sometimes I wish someone would write a FUSE driver for IMAP/Exchange (and yeah I know Exchange is especially unlikely to happen). All attempts I could find on the Web seem abandoned, unfinished, or both.
lol I thought this was a calendar in the file system like files/folders for days/months, but it is in fact the opposite, thank you for the goofy surprise, you got me
> I used this project as an opportunity to learn about Rust and FUSE file systems. I also think it's hilarious.
> Visitors interested in the code should note that this is an irredeemably messy codebase—it's full of hacks, unidiomatic code, and wildly poor design decisions.
> However, visitors should also note that that's okay. The best way to learn something new is to try it out for yourself—and creating a mess is a vital part of that process.
I absolutely love this sentiment. Why do this? Because it’s fun. And messy. And sometimes, that’s okay. Not everything needs to be a product… sometimes it’s enough to do something because you can… or want to… or because $RANDOM reason. I’m very grateful to the author and whoever decided to submit it today.