You're conflating git with git forges. Most popular forges use a centralized model. Git was built as distributed from the start and it's original mode of collaboration was through a federated protocol.
Yeah, like asking for trouble. Even when building a basic image upload system in my project I was considering using some AI model to make sure content is at least somewhat moderated.
If you buy a painting, yes, you own the canvas. You can put it wherever you like, rent it out to others, destroy it, dismantle it and cut up the pieces to make your own collage artwork, whatever you like.
The copyright in the work belongs to the artist though. Your physical ownership of the painting doesn’t stop the artist making another work just like it or licensing the right to do so to someone else.
Museums and galleries sometimes claim copyright on images of works they possess, but that’s generally claiming a copyright over that particular photograph of the work, not the work itself. In order to do things like sell prints they will have to license the work from the artist or the current rights holder (for distributing prints of that work in that territory, which might not be the same as the rights holder for other uses).
Ownership of ‘what the painting represents’ isn’t really something the law takes much of a position on.
What's the primary reason you set out to build this? I like the look and feel of the language but I'm on the fence whether the drawbacks of using something different than bash are outweighed by the benefits of elvish.
I believe shells have the potential to be much more than what they are today, and traditional shells are held back by their rather weak languages.
Re the cost of switching: on the one hand, I'd say that "switching" is really the wrong mentality, because you can always still use bash! You can "switch" to Elvish as your interactive shell and still use bash for scripting. Or you can "switch" to Elvish for some new scripts and still use bash as your interactive shell (and your existing scripts). If you want to give Elvish a try, you can just do it without giving up everything you do with bash today, and reap the incremental benefits of using a better shell.
On the other hand, the mental barrier of adopting "a new thing" is definitely real, even after you overcome the more irrational fears. We only want so much software in our lives anyway. To that I'd say Elvish needs to be more compelling than what it is today. Elvish today, with its nice interactive features and a real programming language, is perhaps 2x to 4x better than traditional shells on its own (if we ignore the whole ecosystem issue), but it needs to be more than that to stand out to people as something radically better. I'm still trying to figure out how to do that, but two ideas I'm exploring are:
- Make it super easy to build TUIs in Elvish - we've had a "renaissance" of TUI tools in recently years, but if you want to build a TUI from scratch it's still surprisingly complicated. Much simpler than building GUIs, but still much more complex than just building a CLI. I feel Elvish as a shell language is a really good place to have a nice TUI framework in.
- Make it super easy to manage a simple homelab or build farm in Elvish - this is traditionally a strength of shells and people still cobble together shell scripts for this purpose, but traditional shell languages are clumsy and you can't easily expose a nice UI from shell scripts. It would be very nice if you can compose some Elvish scripts together and have a nice TUI or a web UI for management at a very low extra cost.
I personally don’t find the TUI idea compelling. I’d rather use a general purpose language like Rust or Python. Many powerful and mature frameworks are already available to build TUIs there. You want to optimise the average one-off hacked-up script writing experience. Most scripts are written in a hurry to accomplish some boring task or automation.
I would spend time building a top notch LSP for Elvish. Shell scripting languages tend to be highly untyped and flexible so building a good LSP will be tough here. But if you were able to build one that works really well you would have another really compelling reason to use Elvish.
P.S. I am aware that Elvish has a built in LSP. It’s somewhat basic though IIRC.
> I personally don’t find the TUI idea compelling. I’d rather use a general purpose language like Rust or Python. Many powerful and mature frameworks are already available to build TUIs there. You want to optimise the average one-off hacked-up script writing experience. Most scripts are written in a hurry to accomplish some boring task or automation.
That's interesting, because I have the same starting point as you (optimise hacked-up script experience) but a lot of the time as my script grows I really wish there's a nice little TUI for it. For example, rather than finding my invocation of the script from my command history and edit the CLI arguments, can I just have a little "pop-up menu" for my workflows, where I can probably add some string argument? Or allow me to see the outputs of the script in a slightly more fancy way than a stream of text - like a Miller column view, which Elvish already has implemented in its file manager? Ideally, these should be "ready-made" UI components that you can take advantage of from your hacked-up script with just one or two lines of code.
I'm also coming from the viewpoint of implementation - I've built Elvish's TUI using some very generic building blocks but they are only used for very specialized builtin features of Elvish, so I'm really keen on exposing the capability for shell scripts to use.
I guess we're thinking of different things when we say "TUI" - perhaps you are thinking of full blown TUI applications, like an editor? I'd agree that a more [1] general-purpose language is more suitable and Elvish is not in the business of being a good language to implement the next TUI editor :) Maybe I should coin a new term for what I have in mind, which should be something you can hack up as easily as a CLI. "TUIlet" maybe?
> I would spend time building a top notch LSP for Elvish. Shell scripting languages tend to be highly untyped and flexible so building a good LSP will be tough here. But if you were able to build one that works really well you would have another really compelling reason to use Elvish.
Definitely! It's not what I'm working on in the immediate future, but good editor integration is a must to make the experience of writing scripts much better than more traditional shells.
1. Emphasis on "more", because Elvish is a general-purpose language itself, just not the most general-purpose :)
Bash reigns supreme indeed. If you’re writing software for yourself or a small team the benefits of Elvish are higher productivity. Try it out — I was really satisfied at the power and cleanliness of the scripting language.
Bash will be dethroned some day. As general purpose languages like Rust, Julia, Python etc have risen, Fortran, pascal etc have declined. And so that will eventually happen with bash. Not “if” but “when” !
I've been using it for weeks, but recently it was so gutted that it barely understands TypeScript. I do my own coding again because sifting through all the possible bugs is more work than just writing it yourself. A true shame, because before it got "faster" it was capable of creating entire apps.
It's designed to be somewhere in view of the person using it. People with ADHD (myself included) struggle with time blindness and just starting tasks in general, so this helps with that (I hope) by:
a) making the start of your tasks just a simple press of a button
b) keeping your progress of time and your deadline right in front of you.
It's just another one of pomodoro apps that I made specifically for myself and wanted to share in case someone wants to use it as well :)
> It's designed to be somewhere in view of the person using it.
Then it really shouldn't be a browser app, it needs to be a local app that runs in the taskbar.
I've made two of these in the past:
V1, browser based: the browser simply wasn't viable because there's no taskbar timer.
V2, Bash+zenity script to run locally, pops up a uncloseable, uncoverable and omnipresent (across all workspaces) window, with a progress bar showing the time as it elapses[1], and properly sends desktop notifications. A much more functional experience than V1 which was invisible while I was working, stuck on a single workspace (I have nine in a 3x3 grid) and frequently didn't send notifications.
V3, Next iteration, local application without a window but with taskbar integration for timer display. Might just decide to hack zenity to provide a 'taskbar' widget.
Arguably a case for ambient electronics. We need to start making physical devices with smarts.
And for easily distracted people, you might want a physical timer that also synchronizes with your devices. Set a timer for the stove, then forget you're baking and try to leave the house, your watch or phone needs to get the alert.
Sometimes too gently. And with watches that last 24 hours between charges, trying to do something in the early evening that takes hours could run you into a dead battery.
Really is better if you have multiple devices to remind you. Right now if I set a timer on one iOS device it tends to go off on the one I'm using. Give me more of that, including ambient devices.
> the browser simply wasn't viable because there's no taskbar timer.
Chrome supports badges on chrome extensions. E.g. I've built a chrome extension that shows an "On" badge when it's activated in the current tab. Via the same mechanism you could display the number of minutes remaining.
I think most popular browsers support badges in standard mode (no extension or webapp mode needed). A fallback would be to change the favicon and/or the window title and tab color.
> Then it really shouldn't be a browser app, it needs to be a local app that runs in the taskbar.
Counter use case - browser apps are superior unless you can invest in building strong cross-platform capabilities (like Obsidian.md)
I'm constantly jumping between machines and operating systems. I've often been on Linux, Windows, and Mac in a single day. Or moved from desktops to laptops.
> I'm constantly jumping between machines and operating systems. I've often been on Linux, Windows, and Mac in a single day. Or moved from desktops to laptops.
Hence why I want to make a V3 that is a local app (some sort of hacked up zenity won't work, though).
For this particular use-case, functionality beats portability.
A suggestion I have (as a time-blind ADHD person): try to hijack the browsers’ Picture in Picture mode, or display a timer icon in the window bar or tab favicon.
Unless you keep your browser tab open, you can’t see it. A “gauge” icon in the browser bar would be enough to actually be in view without being distracting. Repackaging as a plug-in would give you a tab-free icon.
Screen-level overlays work nicely if you can take the native route (or use sth like Tauri). I have a goat showing up on the screen at random intervals and telling the to slow the fuck down when I speak:
I would package this as a local nativefier app and have it running as a dedicated app/window for it to make sense for me.. This as a browser tab would just get lost. Is there source code for this?
For me it would make more sense as a (native) desktop app, personally I like the idea of attention / flow timers but not if they're another browser tab (or electron app.
One idea to explore, is using analog-looking timers instead of the digital-looking ones. I’ve heard this recommended by a number of “time blind” folks.
