Element X is in some cases still a downgrade from Element. For instance there doesn't seem to be a way to create local key backups anymore. Also, that calls between Element and Element X are incompatible means both apps need to be installed in order to receive calls from all contacts.
Still, I love Matrix and hope that these issues will be resolved in time.
I had to deal with Intel Quark SoC X1000 on a Galileo board years ago, where the LOCK prefix instruction caused segfaults. Since the SoC is single threaded, the lock prefix could just be patched out from resulting binaries, before the compiler/build system was patched.
> The problem being discussed is that the user of the script needs to validate it. It's great if it's validated by the author, but that's already the situation we're in.
The user is free to use a LLM to 'validate' the `install.sh` file. Just asking it if the script does anything 'bad'. That should be similarly successful as the LLM generating the script based on a description. Maybe even more successful.
Well... Maybe just have a BIOS on your system that fetches a markdown, pushes it to a LLM to generate a new and exciting operating system for you on every boot.
It is much easier to use LLMs to generate code, validate that code as a developer, fix it, if necessary, and check it into the repo, then if every user has to send prompts to LLMs in order to get the code they can actually execute.
While hoping it doesn't break their system and does what they wanted from it.
Also... that just doesn't scale. How much power would we need, if everyday computing starts with a BIOS sending prompts to LLMs in order to generate a operating system it can use.
Even if it is just about installing stuff... We have CI runners, that constantly install software often on every build. How would they scale if they need LLMs to generate install instructions every time?
Even bringing down the "theory" to paper in prosa will be lossy.
And natural languages are open to interpretation and a lot of context will remain unmentioned. While programming languages, together with their tested environment, contain the whole context.
Instrumenting LLMs will also mean, doing a lot of prompt engineering, which on one hand might make the instructions clearer (for the human reader as well), but on the other will likely not transfer as much theory behind why each decision was made. Instead, it will likely focus on copy&pasta guides, that don't require much understanding on why something is done.
So... What you are saying is that we don't need 'install.md'. Because a developer can just use a LLM to generate a 'install.sh', validate that, and put it into the repo?
Good idea. That seems sensible.
Bonus: LLM is only used once, not every time anyone wants to install some software. With some risks of having to regenerate, because the output was nonsensical.
TBH. I never read prose that couldn't be in some way misinterpreted or misunderstood. Because much of it is context sensitive.
That is why we have programming languages, they, coupled with a specific interpreter/compiler, are pretty clear on what they do. If someone misunderstands some specific code segment, they can just test their assumptions easily.
You cannot do that with just written prose, you would need to ask the writer of that prose to clarify.
And with programming languages, the context is contained, and clearly stated, otherwise it couldn't be executed. Even undefined behavior is part of that, if you use the same interpreter/compiler.
Also humans often just read something wrong, or skip important parts. That is why we have computers.
Now, I wouldn't trust a LLM to execute prose any better then I trust a random human of reading some how-to guide and doing that.
The whole idea that we now add more documentation to our source code projects, so that dumb AI can make sense of it, is interesting... Maybe generally useful for humans as well... But I would instead target humans, not LLMs. If the LLMs finds it useful as well, great. But I wouldn't try to 'optimize' my instructions so that every LLM doesn't just fall flat on its face. That seems like a futile effort.
It really depends on the order of priorities. If the overall goal is to allow digital archeologist to make sense of some file they found, it would be prudent to give them some instructions on how it is decoded.
I just hope that people will not just execute that code in an unconfined environment.
I also tried Kakoune, coming from pretty vanilla vim as well.
I liked its concepts, but I could not make kak auto line wrap C block comments correctly. Kakoune apparently relies on external tools like `par` to do, at lease for me, pretty essential stuff, which vim does of of the box.
I will take a look at helix, but I hope it comes with basic text wrapping features included.
Well we are talking about using Linux on a desktop machine exclusively, only then a demand for a non-cloud version of MS Office would make sense, I think. This subset of people are probably more likely to care about control of their data that just some people that dual-boot or use linux on their android phone.
That depends. If they are a Linux user because Linux runs on their server, router, mobile phone or what not. Then you are probably right.
People that go through the trouble of installing Linux on a Desktop Machine, where Windows or MacOS was probably pre-installed, will either dual boot or use Linux exclusively. If they dual-boot, they will probably just use Office on the non-Linux System and not care.
But if they use Linux exclusively they will very probably care about the freedom and control Linux brings.
Offering a cloud service to a linux user is like tempting a vegetarian with meat.
Linux users often choose Linux because they want to be in control of their data and devices, cloud services are about giving control of that away to companies.
I use syncthing for file syncronization between laptop, desktop, nas and mobile phone.
And scripts that 'index' the books and create a directory structure of the metadata (like tags, series, publication date etc.) containing symlinks to the real books.
I am not against an index or library in addition to the file hierarchy, but I am against a library or index replacing a directory listing.
Both perspectives are very valuable!
Also a full text search (grep) or (more or less simple) file search (find) are useful in addition to a library.
To reiterate, for me it seems that itunes and ebook reader generation of devices and applications don't seem to value custom directory organization.
> Those applications exist. Calibre even comes with one out of the box. Not their fault if you just start the library and not the reader.
While the library part of calibre is very good, the reader part is not so great, but that just might be because a library application is much more difficult to implement than the reader, so bad UI can be looked over there, but not in the reader. Otherwise I agree that this the application of choice for reading ebooks on Linux desktop.