[HN Gopher] Show HN: Ell - A command-line interface for LLMs wri...
___________________________________________________________________
Show HN: Ell - A command-line interface for LLMs written in Bash
Hi HN! I've created a CLI tool called "ell" that allows you to
interact with LLMs directly from your terminal. Designed with the
Unix philosophy in mind, ell is simple, modular, and extensible.
You can easily pipe input and output to integrate with other tools.
Its templates and hook-based plugins enable you to customize and
extend its functionality to suit any needs. Check out the README
for usage instructions and examples. I developed this tool because
existing solutions often felt too heavy, with many dependencies, or
they weren't friendly to piping and customization. I, on the
contrary, wrote in almost pure Bash with least dependencies.
Additionally, I found a lack of tools that could read past terminal
output as context. Imagine encountering an issue in your terminal
and being able to directly ask an LLM for help with a simple
command--this is now possible with ell (see the demo video). Known
limitations: - To maintain simplicity and efficiency, jq is used
for JSON parsing. - Cannot avoid curl to sending HTTPS requests.
If only there were SSL / TLS support in `/dev/tcp/`! - Perl is
used to handle terminal escape sequences because regex in Bash does
not support looking around. - Markdown syntax highlighting is not
perfect due to the need for streaming output. It relies on a simple
state machine instead of a full parser, which may produce falsy
results. - Other known issues are listed in Github Issues. Please
help add more! I welcome any criticism and suggestions, whether
it's about the idea or code!
Author : simonmysun
Score : 202 points
Date : 2024-08-02 11:55 UTC (1 days ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| mherrmann wrote:
| Cool. The link to "Risks" in the README is broken.
|
| What I would love: `ell -r` automatically, and an alias `fix`
| that proposes a fix, including making changes to a file. For
| example, say I have a typo in main.cc and do `gcc main.cc`. When
| I run `fix`, I want ell to propose a fix in the file with a diff.
| If I accept, it should make that change. Then it should propose
| running `gcc` again - and run it for me if I accept.
| Zambyte wrote:
| Regarding running ell -r automatically, you can just add it to
| your .bashrc
| mherrmann wrote:
| Yup. But the rest of the functionality is missing, I think.
| simonmysun wrote:
| > The link to "Risks" in the README is broken.
|
| Fixed. Thanks for pointing out!
|
| > `ell -r` automatically, and an alias `fix` that proposes a
| fix, including making changes to a file.
|
| Good idea! `ell -r` can be added to `.bashrc`, but I'm not sure
| if it will conflict users' original configurations or there
| will be other issues. Except confirming a patch, I think it is
| feasible with template and plugins, but making actuall changes
| is challenging for me, both techinology wise and user interface
| design wise. I will try to figure out what can be possible
| hacker-l wrote:
| Hi, they're also trying to do something similar with shell. I'm
| not sure who's better. [demo](https://x-cmd.com/mod/gemini)
| [source code](https://github.com/x-cmd/x-cmd/blob/main/mod/gemini
| /lib/main)
| simonmysun wrote:
| Cool! This is looks a lot fancier.
|
| EDIT: I was wrong. Ignore the next paragraph.
|
| ~~I haven't looked into details but it looks reading from
| somewhere like `.bash_history`. That's a good idea to get user
| input from. But as far as I learned, it cannot use the terminal
| ouput as context. I might be wrong. I should read more about
| its implementation.~~
|
| It turns out it cannot make use of terminal output. But I like
| it that it use awk to process the response. I might also be
| able to use awk to get rid of the dependencies of jq and perl.
| Thank you for letting me know this.
|
| I will add it in the related projects chapter in README
| curry798 wrote:
| It looks beautiful and has many features, why are there so few
| star?
| simonmysun wrote:
| I also wonder. It didn't appear in my search because, I
| guess, it has too many features and the feature I want to
| search has a relatively low weight. I also searched x-cmd on
| HN but there aren't many positive comments... I would expect
| it's more popular on HN because it's written in POSIX shell
| and awk.
| mvavassori wrote:
| I don't know why i keep getting the error:
|
| "FATAL Template not found: ~/.ellrc.d/templates/default-
| openai.json"
|
| after having cloned the repo in my home directory and created the
| configuration file in .ellrc in my home directory. Don't know,
| probably i'm doing something wrong... I'm new to bash projects,
| why does it search for the templates in .ellrc.d? what's the .d
| part? I don't understand.
| simonmysun wrote:
| Oh sorry that's my bad. The target clone path did not match the
| default value of template path.
|
| Please make sure you either clone the repo to `~/.ellrc.d` or
| set ELL_TEMPLATE_PATH to where you store your templates (with
| `/` at the end) .
| mvavassori wrote:
| Thank you, i always assume there's some magic part that goes
| on behind the scenes which i don't understand, especially in
| things i'm not familiar with... In fact it was just a path
| mismatch as the error suggested.
| simonmysun wrote:
| You are welcome. Please feel free to fire any issues you
| may encounter.
| llimllib wrote:
| I wrote a similar tool I'm no longer maintaining:
| https://github.com/llimllib/gpt-bash-cli/ . Here are my
| suggestions:
|
| - save the conversations in a sqlite db. ~everyone has sqlite
| available and it allows the user to do things with the data more
| easily than a text file
|
| - use XDG directories instead of suggesting ~/.ellrcd
| (https://wiki.archlinux.org/title/XDG_Base_Directory)
|
| - I prefer using system secret stores to environment variables; I
| don't want to give every program I run access to my API keys. You
| can see how I did that in my program
| simonmysun wrote:
| Thanks for the suggestions! I read your code and the support of
| images is awesome.
|
| I would not assume everyone has sqlite but this can be done
| optionally with a plugin. Will consider writing a demo for
| this.
|
| Using XDG directories and system secrets sounds a lot better
| than what I did. I will learn how to use them and try to
| integrate them with my code!
| ComputerGuru wrote:
| Shameless plug: we maintain a cross-platform/cross-language
| secrets store (with cli tooling available) to portably read
| and wrire secrets (but it doesn't use the OS facilities for
| encryption).
|
| Linking to the rust implementation because it's the fastest
| and most easily portable:
| https://github.com/neosmart/securestore-rs
| e12e wrote:
| > I would not assume everyone has sqlite but this can be done
| optionally with a plugin. Will consider writing a demo for
| this.
|
| Used to be everyone used BerkleyDB or some similar key-value
| store - for a great many usecases SQLite is just
| pragmatically better.
|
| And it's arguably less exotic than perl.
|
| You should of course do what want - but "just use SQLite" is
| pretty solid advice when dealing with structured data - and
| almost certainly better than "smart" text file.
| simonmysun wrote:
| I can't deny the benefits. But in my mind, this is not what
| ell should take care of. It doesn't intend to store
| anything whether in a text file or any other format. It
| should however provide the posibilities for users to store
| them in any way they like.
| e12e wrote:
| Fair enough. I seem to recall a project for keeping
| infinite bash history that did leverage SQLite -
| interfacing with such a project might be more
| interesting.
|
| I was more thinking from gp comment that the project
| might store context or history in its own files - and
| then SQLite might be a good fit.
| ducktective wrote:
| >I prefer using system secret stores to environment variables
|
| What is the recommended way to store secrets in a Linux dev
| machine? The requirement is random scripts and programs should
| be able to load their secrets like API keys at runtime with
| minimum hassle. And the secrets shouldn't be stored on disk in
| plain-text.
|
| I see you recommended keyring [1]. Is this "the GNU/linux way"?
| I see another possibility being storing them in an encrypted
| filesystem (whether FUSE-based or not)
|
| [1]: https://github.com/llimllib/gpt-bash-
| cli/blob/841682affe2d0e...
| llimllib wrote:
| I did a fair amount of looking to try and support a Linux
| secret store! My conclusion was that I was too confused and
| so I punted to keyring which seemed to paper over a few
| different stores.
|
| It seems like a classic story of unfortunate Linux
| fragmentation
| amelius wrote:
| I don't have sqlite, and I wouldn't know how to use it.
|
| I would much prefer text files.
|
| Thank you.
| fragmede wrote:
| you can visit the website https://www.sqlite.org/ where you
| can find copies of the program, along with instructions on
| how to use it. I would prefer to use a more advanced file
| format to hold records. Standing on the shoulders of giants,
| instead of their toes, as it were. Hopefully we can advance
| technology beyond the 1980's. Thank you for your
| understanding.
| callamdelaney wrote:
| On the contrary please don't use the keyring, its annoying and
| some systems don't have it. Your llm key is not that critical,
| and you should trust what runs on your system.
|
| Poetry demands access to my keyring and I don't use poetry
| (open bug for years, it doesnt even need access).
| simonmysun wrote:
| I know that it's contraversial. It would be an option or even
| a customized way of using ell mentioned in document. I
| wouldn't force users to adopt any unmatured or uncommon
| standard.
| trescenzi wrote:
| Huge fan of Charmbracelet's mods. I've been using it for months
| now and it works great. Very customizable and the output is
| clean.
|
| https://github.com/charmbracelet/mods
| simonmysun wrote:
| Thank you for letting me know!
|
| It does well with conversation but on the contrary, ell itself
| is stateless (on the aspect of user input and generate
| contents). Conversational use of ell depends on `script` to
| record the terminal output. Though, I can support managing
| historical dialogs via a plugin with side effects. I need to
| consider whether this suits the idea and philosophy of ell.
|
| Well, either I'm not good at googling ro google is not good at
| searching.. I did searched similar projects and never find
| these powerful tools in practice posted by HN users
| yanis_t wrote:
| Very cool!
|
| I wrote a similar tool (in Node.js, though), but was trying to
| make it extensible with plugins.
|
| https://github.com/hiquest/nicechat
| simonmysun wrote:
| (Reading your comment and code reminds me that I might have
| confused user with the terms of the plugin I proposed and the
| plugin in popular LLM backends. I will make it clear in ell
| documents)
|
| What kind of plugins are you going to integrate? I implemented
| the hook system but actually don't have many ideas to add.
| Currently I only added paginator and syntax highlight plugins
| and both of them are applied after getting response from LLM
| backends.
| mFixman wrote:
| The program seems to assume you'll clone it in your home
| directory, and has paths hardcoded to `~/.ellrc.d/`.
|
| This is just bad.
| simonmysun wrote:
| I wouldn't say these paths are hardcoded. They are just default
| values. You can set the variables manually.
|
| What is hard coded is that it indeed looks for configurations
| from `$HOME/.ellrc` and `$PWD/.ellrc`, with lowest precedence.
| Environment variables and command line arguments will overwrite
| them.
| SoftTalker wrote:
| Convention over configuration isn't bad per se, as the
| alternatives tend to devolve to bikeshedding.
| piyushtechsavy wrote:
| Sounds cool.
| simonmysun wrote:
| Thx!
| danenania wrote:
| This is cool! Using pure bash and unix tools is an interesting
| approach. I built Plandex[1] which has some similar goals (no
| dependencies, terminal-based, supports piping into context) but
| it takes quite a different route to get there--I'm using Go and
| compiling static binaries. It's also 'higher level' and
| specifically focused on coding, whereas ell seems like a very
| lightweight and general purpose LLM tool. It reminds me a lot of
| Simon Willinson's `llm` tool[2]. Are you familiar with it?
|
| The recording feature also reminds me of savvy[3].
|
| 1 - https://github.com/plandex-ai/plandex
|
| 2 - https://github.com/simonw/llm
|
| 3 - https://github.com/getsavvyinc/savvy-cli
| simonmysun wrote:
| Thanks! Plandex is also nice! I never thought of such workflow.
|
| Unfortunately, I did not know Simon Willinson's `llm` tool. I
| would imagine he must have written such softwares. It has
| support for more in-depth manipulating of LLMs. ell lacks these
| functionalities and only make use of the most commonly-used and
| also most basic interfaces but has more user experience
| improvements like pagination or syntax highlighting while
| keeping as lightweight as possible. I should mention
| `simonw/llm` in README and channel the user with demand of more
| LLM manipulations there.
| threecheese wrote:
| That's quite an honest and emotionally mature response, and I
| am always glad to find Real People(tm) around the internet.
| Rare these days. Your product looks great btw! Consider me
| another Stargazer, and keep building it.
| simonmysun wrote:
| Thank you!
| skruzel wrote:
| I also have a similar tool called https://autocomplete.sh
| https://github.com/closedloop-technologies/autocomplete-sh
|
| I really just wanted the feeling of tab-based auto-complete to
| just work in the terminal.
|
| It turns out that getting the LLM responses to 'play nice' with
| the expected format for bash_completion was a bit of a challenge,
| but once that worked, I could wrap all the LLMS (OpenAI, grok,
| Claude, local ones like Ollama)
|
| I also put some additional info in the context window to make it
| smarter: a password-sanitized recent history, which environmental
| variables are set, and data from `--help` of relevant commands.
|
| I've just started to promote it around the Boston area and people
| seem to enjoy it.
| stared wrote:
| Looks interesting!
|
| Does it work with the Fish shell? And, in case, how do I update
| or uninstall it?
| skruzel wrote:
| `autocomplete remove` will delete it. I haven't tested it in
| fish / zsh shells.
|
| Now that I have some Mac iOS dev work to do I'll probably
| build and test it
| simonmysun wrote:
| Wow that's very useful! I have also thought of completion but
| my idea was more like copilot. The user experience of your
| script should be better. I'm glad I didn't start to write that.
|
| Regarding history in context, I suggest adding a record mode
| like ell. This really helps.
|
| Password sanitizer is great. I will also add it as a plugin.
| Thank you for the idea!
| skruzel wrote:
| Thanks for checking it out and the record mode is a great
| idea. I've been playing around with ways to get the terminal
| outputs but so far I haven't loved the UX of my solutions.
| Your co-pilot approach that can explain the commands and
| iterate is really valuable.
|
| If you're open to joining, I have a small AI engineer/ open
| source dev Slack community in Boston. Id love to have you
| (https://smaht.ai)
| simonmysun wrote:
| I am open to join any community. As long as you don't mind
| the fact that I'm not in Bosten, why not? I have just
| submitted on your google form. Thanks for inviting!
| rancar2 wrote:
| The demo video is epic. Nicely done!
| https://youtu.be/IAgkjerCvz8
| skruzel wrote:
| Thank you! It was so much fun to make. And for once my son
| waking me up at 2am had a positive result!
| bitdribble wrote:
| I've watched autocomplete-sh in action at the AI Tinkerers
| meetup in Cambridge, MA. Was impressed. It is very well
| integrated with the shell. The idea of writing it directly in
| bash - bold! But an effective idea to keep it portable.
| alkh wrote:
| Looks great! I work on a number of different machines, so having
| something lightweight(like written in shell) is always desired.
|
| Out of curiosity, can someone explain to me why certain commands
| start with a colon? Like : "${ELL_LOG_LEVEL:=2}";[1] I thought it
| was useful only as a no-op? [1]:
| https://github.com/simonmysun/ell/blob/main/ell.sh#L19C1-L19...
| simonmysun wrote:
| Thanks!
|
| The colon is here to make sure the result is not executed. I
| learned that from here:
| https://stackoverflow.com/a/28085062/2485717
| pseufaux wrote:
| The : basically just tells bash to do nothing with the result
| of the line. So `: "${ELL_LOG_LEVEL:=2}";` would initialize
| `ELL_LOG_LEVEL` to 2 if it's not already set without producing
| any output.
| teamspirit wrote:
| Will check it out. Personally been using aichat[0] for this.
|
| It's interesting you say there's no need for a more complex
| language than bash something like this. Doesn't the need for
| jq/curl/perl argue the opposite?
|
| [0] https://github.com/sigoden/aichat
| simonmysun wrote:
| Indeed. That's why I list them as limitations. My original idea
| was to get everything done with Bash. This is however not
| feasible as the reasons listed. Maybe I can get rid of jq and
| perl using awk, but that would sacrifice a lot of simplicity
| and readablity of the code.
|
| I think implementing the syntax highlighter is the bottom line
| of my insist. I would prefer not to write anything more complex
| than that with Bash. They will be either not supported, or
| supported via external plugins.
| joshi4 wrote:
| Ell is really cool!
|
| I'm building a similar product called
| Savvy(https://github.com/getsavvyinc/savvy-cli) and considered an
| approach similar to yours (writing in pure bash) but ultimately
| decided to use Go for a few reasons:
|
| - charmbracelet makes it super easy to build rich TUI - Go
| produces a single binary that's compatible across many platforms
| and keeps installation simple - It's simpler to support multiple
| shells.
| simonmysun wrote:
| Thanks!
|
| Another user[1] also mentioned Savvy but I misunderstood its
| purpose. Now I understand it does have a similar functionality
| of analyzing a record of terminal! Your approach allows more
| chances to let LLM explain what happens, while in my case,
| asking ell will immediately destroy the original context (the
| user may have to rerun the falsy command again and cause more
| damage). However, exiting and reentering recording mode also
| feels tedious. I must find a better way to interact.
|
| https://news.ycombinator.com/item?id=41139040
| joshi4 wrote:
| You're right, to counteract the friction I also allow users
| to create runbooks from their shell history.
|
| Here's the source code: https://github.com/getsavvyinc/savvy-
| cli/blob/8c6a834c5a140b...
| threecheese wrote:
| Just checked out Savvy; is the runbook-generating code ('savvy
| record') also in that repository? The one hosted at
| api.getsavvy.
|
| Very interesting idea! Your terminal screenshots are excellent
| as well, very compelling imagery. Love the font.
| joshi4 wrote:
| Here's the code for savvy record:
| https://github.com/getsavvyinc/savvy-
| cli/blob/8c6a834c5a140b...
|
| Lot of users typically find that they realize they should
| have recorded something after they've done it. That's why
| savvy also allows you to select commands from your shell
| history with savvy record history
|
| The API source code is in a different repo.
|
| Thanks! All credit to the dracula theme for tmux and Kitty
| terminal emulator.
|
| If you have any questions or feedback feel free to email me
| at shantanu@getsavvy.so
| raajg wrote:
| Been using the LLM cli by simonw and love it.
|
| https://github.com/simonw/llm
|
| https://llm.datasette.io/en/stable/
|
| Pro tip: Use $pbpaste to inject clipboard contents in a prompt
| simonmysun wrote:
| I don't have pbcopy and pbpaste on my machine but injecting
| clipboard sounds interesting.
| simonw wrote:
| Does ell have the ability to pipe things INTO the tool?
|
| I use that with my https://llm.datasette.io/ tool all the time -
| things like this: cat somecode.py | llm -m
| claude-3.5-sonnet "Explain this code"
|
| Or you can separate the instructions from the piped content by
| putting them in a system prompt instead like this:
| cat somecode.py | llm -m claude-3.5-sonnet --system "Explain this
| code"
|
| Being able to pipe content like this INTO an LLM is really fun,
| it lets you do things like scrape a web page and use it to answer
| questions: https://simonwillison.net/2024/Jun/17/cli-language-
| models/#f...
| simonmysun wrote:
| Definitely! For example, cat somecode.py | ell
| -f -
|
| If you prefer adding another piece of prompt instantly instead
| of adding it in the template: (cat somecode.py;
| echo "Explain this code") | ell -f -
|
| I should've added this into README.
|
| I really love your "llm" and the blog posts but somehow I
| missed them before. I believe I would be a lot less motivated
| to write ell if I had read your post first.
| behnamoh wrote:
| > I really love your "llm" and the blog posts but somehow I
| missed them before. I believe I would be a lot less motivated
| to write ell if I had read your post first.
|
| I mean, doing a simple search like "CLI interface for LLMs"
| shows multiple tools made by people over the years. Not to
| bash your work (pun intended), but I don't see the point of
| creating yet another CLI interface for LLMs at this point.
| edmundsauto wrote:
| To the creator, ignore this person. Thank you for sharing!
|
| To the parent: prefer that you hold opinions like this to
| yourself.
| respondo2134 wrote:
| >> To the parent: prefer that you hold opinions like this
| to yourself.
|
| it seems weirdly inconsistent that you expect people to
| hear your voice as you try and shut down another
| expressing a viewpoint with which you don't agree. You
| would have been better off with just the first half of
| your post.
| simonmysun wrote:
| Well, either I'm not good at googling or google is not good
| at searching. I did searched similar products and I have
| listed them in the README. Perhaps I just didn't pick the
| correct keyword. I'm sorry that many wonderful similar
| products are not listed, but I currently don't find any of
| them completely cover the features of ell.
| kqr wrote:
| I have been an LLM skeptic for a long time, but the llm CLI and
| your review of Claude 3 Opus (and subsequently discovering how
| comparatively cheap 3.5 Sonnet is) has started to turn LLMs
| into something I use daily.
|
| Exactly that piping comes into handy all the time. I use it to
| estimate reading time of things on the web, through
| curl <url> | llm -m claude-3.5-sonnet -s 'How long does the
| main content of this article take to read? First count words,
| then convert using a slow and fast common reading speed.'
|
| It gets the word count wrong a little too often for my taste,
| but it's usually within the right order of magnitude which is
| good enough for me.
|
| One of my most used shell scripts recently is one I named just
| `q` which contains #!/bin/sh llm
| -s "Answer in as few words as possible. Use a brief style with
| short replies." -m claude-3.5-sonnet "$*"
|
| This lets me write stupid questions in whatever terminal I'm in
| and not be judged for it, like [kqr@free-t590
| tagnostic]$ q How do I run Docker with a different entrypoint
| to that in the container?
|
| What's nice about it is that it stays in context. It's also
| possible to ask longer questions with heredocs, like
| [kqr@free-t590 tagnostic]$ q <<'EOF' > I have the
| following Perl code > > @content[sort {
| $dists[$a] <=> $dists[$b] } 0..$#content]; > >
| What does it do? > EOF
|
| I have meant to write about this ever since I started a few
| weeks ago but I would like my thoughts to mature a bit first...
| simonw wrote:
| I love that 'q' script, definitely going to try that myself.
| kqr wrote:
| I did turn it into an article with some more examples, if
| you're curious: https://two-wrongs.com/q.html
| heyrikin wrote:
| This is really cool.
| simonmysun wrote:
| Thx!
| koinedad wrote:
| I love the idea of piping my error messages into an LLM to help
| me debug. Would also love a solid local only LLM and have this
| basically in offline mode as well
| simonmysun wrote:
| Please stay tuned. Support for more providers are on the way!
| woolion wrote:
| So, last weekend I wanted to use an LLM to review some documents,
| and the problem I had was not so much the interface but that it's
| necessary to have some workflow management to re-run failed jobs
| and run the aggregate job once its dependencies are done. I ended
| up writing my own to do it, but I wondered if there are off-the-
| shelf solutions that already provide these kinds of work.
| simonmysun wrote:
| I don't have a solution yet but it's also a problem I am trying
| to address. The output of LLM is not stable and robust and
| currently we can only adjust the prompt to improve it.
| Fundamental tools like piping in the shells cannot easily
| handle this. You must either rerun the whole pipeline or start
| to write more complex script which includes validating and
| parsing the output.
|
| I checked your solution and it looks promising. Will you make
| it a general purpose LLM workflow scheduler?
| e12e wrote:
| Interesting - unfortunately displays typical llm issues in the
| demo video:
|
| > It's important to note that using `1<>` can lead to unexpected
| behavior if the file already exists, as it will be overwritten.
|
| > To avoid this, you can use the `-a` option to append to the
| file instead of overwriting it. For example:
|
| > `bash ls 1<> output.txt
|
| > This will append the output of the `ls command the file
| `output.txt` if it already exists, or create the file if it
| doesn't.
|
| Note that the example is wrong and not in line with the
| explanation.
|
| Ed: AFAIK the closest thing that works would be:
| ls >> output.txt
|
| Not sure if there are any invocations using "1<> output.txt" that
| would make sense in this context? Maybe binding to a custom
| description like 3, and using "tee --append"?
| simonmysun wrote:
| You are right. I will replace the video. Actually the last time
| I record it wasn't this bad. And the script was kept and I
| didn't make much change when recording it again.
|
| Here's the first video I recorded for an earlier version:
| https://github.com/simonmysun/ell/blob/d4fc5468157fa6adc8f9f...
|
| Unfortunately, LLMs are not stable.
|
| For reference, here's the link to the video with mistake:
|
| https://github.com/user-attachments/assets/1355ad08-6fbf-4c0...
| https://github.com/simonmysun/ell/blob/553d38f60ad104893b2a3...
| fallingfrog wrote:
| I love how a few years ago everyone was fretting over how to keep
| an AGI in a leakproof box,
| http://cecs.louisville.edu/ry/LeakproofingtheSingularity.pdf
|
| And now, a few years later we just give it a bash shell and full
| access to the internet. So much for the box! I can't believe how
| naive we were to think that the people who developed an ai would
| prioritize _anything_ over profit and how fast the genie would
| escape- it's not even AGI yet but at the point where it becomes
| AGI, with this kind of precedent set it's laughable to think that
| we will put any sort of guardrails on it.
|
| All this time we thought it was a technical or philosophical
| problem but the real problem was capitalism and the glacial pace
| that the general public picks up on what is going on. It would
| take decades to get the people at large to agree that the threat
| is even real and decades more to get to the point where public
| opinion was decisive enough to counteract all that money, and
| _only then_ do you get to even _try_ to keep it contained.
|
| The project itself is very well executed though
| simonmysun wrote:
| That truly is a visionary article; thank you for sharing it. We
| still cannot afford to be complacent, but I believe it is the
| responsibility of the users to ensure safe and ethical usage.
___________________________________________________________________
(page generated 2024-08-03 23:01 UTC)