The archaic model where every tool gets full access to your home directory was never designed for the scenario where a single npm install will install and execute 100s of packages written by various authors.
I also believe sandboxing will get more and more important. There might be some trade-off on user experience or convenience, but given the security enhancement and (LLM agent's) freedom I think it will be well worth it.
Yes I highly suggest working in a container or setting up selinux. Selinux is especially powerful for this kind of thing but also requires a lot of advanced knowledge and skills to setup and maintain sadly.
Sorry, I meant that’s not desirable behavior that the user might expect. I understand that coding agent tools tend to play fast and loose with access because it’s not their own privacy/security at stake.
> It's Ram, not Rama, it's yog, not yoga'... And they have no idea what schwa deletion is.
It is neither.
The fundamental issue is that there is no way to represent the schwa sound in English[1].
All of a,e,i,o,u have been used to communicate the schwa (or schwa-like) sound in English.
- The `a` in about
- The `e` in taken
- The `i` in cousin
- The `o` in button
- The `u` in upon
I wouldn't say 'neither', because by your own example, 'a' in English can represent ⟨ə⟩. That every other vowel letter also can is English's low level of phoneticism with respect to the script it uses. Many other languages using the Latin script (German, Italian, Finnish) don't have this problem, what you see is what get.
Oddly enough amongst the Indic languages, Tamil has precisely the same problem: க, ப, ட may be voiced or voiceless plosives depending on context. Sanskrit loanwords in Tamil are typically pronounced very differently compared to their original in Sanskrit, or even in Telugu.
Personally when transliterating any Indic language I tend to use ISO-15919, and in that scheme, it is Rāma, and 'a' represents the schwa. Or Rāmaḥ, Rāmam, Rāmē, or Rāmasya, whichever grammatical attachment is appropriate.
Wikipedia has an interesting page on "Brahmin Tamil" which is the Tamil dialect spoken by Brahmins in Tamil Nadu and consists of Classical Tamil with a lot of Sanskrit influence - https://en.wikipedia.org/wiki/Brahmin_Tamil
> That every other vowel letter also can is English's low level of phoneticism
The level of phoneticism between English language and its latin script is not evenly spread.
For example, the letter "c" might mean /s/ or /k/ sound.
However, the letter "k" almost certainly means /k/ sound.
In some ways, the schwa sound in English the worst as there is no symbol which is committed even partially towards it.
> it is Rāma, and 'a' represents the schwa.
Sure, but if my name is Rāma, I have to choose either "Ram" or "Rama" or "Raama" for my passport name.
Or legal name in most places, non-alphabetic symbols do not work with all modern systems.
> Many other languages using the Latin script (German, Italian, Finnish) don't have this problem, what you see is what get.
English imports spellings from other cultures and adds its own layer of pronunciations.
Other languages probably don't do it as often.
> In some ways, the schwa sound in English the worst as there is no symbol which is committed even partially towards it.
> English imports spellings from other cultures and adds its own layer of pronunciations. Other languages probably don't do it as often.
English is almost unique in how inconsistent its orthography is especially with respect to vowel sounds, and loanwords are only the latest manifestation of this problem. Even consonants aren't spared. Consider the digraph 'th'. This can be a voiced or voiceless dental fricatives. English used to have letters for each: ð and þ. 'ough' has nine pronunciations—plough, though, through, thorough, cough, rough, bought, lough, hiccough.
English has experienced contact with such a wide variety of unrelated foreign languages to an extent few others ever have.
> Sanskrit was widely spoken and understood just like Latin or Avestan, in its heyday. Otherwise it wouldn’t be part of the liturgical traditions of Buddhism, Jainism and Nastika traditions.
I think, and it is just my speculation, that for most of Indian History, Sanskrit was the link language.
Just like "Latin" in the USA and Europe of the early 17th and 18th centuries, when all academic instructions were carried out in Latin!
So, nobody used Sanskrit as the primary language, but everyone could or knew someone who could convert Sanskrit to the local dialect.
It is almost like how Chinese and Colombian traders might sign a contract for coffee purchase in English. Neither might use English in most of their daily operations.
> I think, and it is just my speculation, that for most of Indian History, Sanskrit was the link language.
> Just like "Latin" in the USA and Europe of the early 17th and 18th centuries, when all academic instructions were carried out in Latin!
You're suggesting that Sanskrit became a scholarly language, which no one was disputing. You're even using as a metaphor Latin, which started out as a vulgate tongue - which is the argument you are doubting.
Edit: It also applies to your English comparison. English IS spoken by millions, just not by the people you are referring to. Are you actually claiming English isn't a mother tongue to anyone?
> Are you actually claiming English isn't a mother tongue to anyone?
I gave a specific example where neither the coffee wholesaler nor the buyer probably operates day to day in English. But they would still use English for the official agreement.
That does not take away from other benefits of English like being spoken by millions as a primary language and probably billions as a second language
Yes this makes a lot of sense, if I recall correctly the first grammar of Telegu was written in Sanskrit, and many South India languages use a lot of Sanskrit words, but of course they are not intelligible if you don't know the grammar.
Not sure why you are speculating or what your background would be to do so, when the info is easy to find. Yes it was a link language given its prominence, but also
> Sanskrit was a spoken language in the educated and the elite classes, but it was also a language that must have been understood in a wider circle of society because the widely popular folk epics and stories such as the Ramayana, the Mahabharata, the Bhagavata Purana, the Panchatantra and many other texts are all in the Sanskrit language, while many Sanskrit dramas indicate that the language coexisted with the vernacular Prakrits.[115] Thus, Classical Sanskrit with its exacting grammar was the language of the Indian scholars and the educated classes, while others communicated with approximate or ungrammatical variants along with other natural Indian languages,[114] with the cities of Varanasi, Paithan, Pune and Kanchipuram being centres of Sanskrit learning and debate until the arrival of the colonial era
Comparing Sanskrit to the status of Latin in 17th CE is bit disingenuous and a sign of presentism.
Sanskrit enjoyed scholarship since 6th BCE and it was prevalent and commonly used for more than a millennia after that.
The various inscriptions found across the subcontinent, and meant for common people are in Sanskrit which disproves this idea that it was not widely used.
There is no official "Prakrit", by definition of the term itself.
"Prakrit" just means "natural" and the way I understand it, was the term for all colloquial dialects/languages across India.
Keeping it to the most mainstream, Java is a mighty fine choice as well, with even better options for third-party packages, tooling, integrations, and telemetry than most of the above.
Forgetting the JVM when it provides absurdly good performance and more packages than pretty much all three of these languages combined is certainly a choice. Even Java and all its verbosity gets fixed by not having to write it manually. Kotlin is also a very viable option. Scala if you're a bit crazy.
Most of the people I've encountered that use Java are working on enterprise codebases that are a couple decades old at this point. And I'm totally unfamiliar, but I thought Kotlin was vaguely "Java for Android" - other than existing packages, are there other reasons to choose languages focused on the JVM?
Modern Java is definitely pretty good. But indeed, Java has solidified a lot around "old" style code: making your 50 years old CTO start using collectors and typing `var` instead of MyObject object = new MyObject(); can be a difficult thing. Modern Java is truly quite pleasant.
Kotlin is a fully JVM compatible language. Java is catching up to it in some points (Project Loom has made multithreading in Java almost as pleasant as coroutines in Kotlin), but the experience in writing DSLs, code with lambdas, the brevity afforded by Kotlin makes it more pleasant than java. It's also the default recommended language for Spring/Spring Boot now, that is probably the largest JVM API backend project that ends up being used by default.
The benefits you get are:
* Probably the most stable platform you're ever going to get: the JVM is rock solid and does not require tuning honestly, unless you're trying to get a free few percents of performance. Your shitty SaaS startup doesn't need to do that.
* Probably the most performant JIT in the world. Python isn't nearly close, and Go is, well, not jitted, but offers similar-ish performance. Except that you get a good GC with the JVM. Or rather multiple GCs depending on what you really want: throughput/low pauses/etc.
* The packages are truly a massive thing. The APIs aren't always perfect, but behind python & js, it's probably the most fully fledged option.
* Publishing modules doesn't suck.
* Having to carry a jar around does suck a bit, but fat jars solve the problem, and if you're serious in your work, you can just GraalVM it and you have an AOT compiled executable that works great.
Negatives:
* It's java, man. It's still the same verbose beast. Doing low allocation work is a bit hard. Kotlin makes it better. Kotlin also has kotlin multiplatform with a large and growing API surface, and is probably one of the most pleasant multiplatform options, allowing you to delegate to any platform code you want.
* You're never getting a tiny 5MB executable. If startup time is an issue, work hard on GraalVM.
What’s described here isn’t connected to the agentic/AI nature of the software at all. Every single program you run as a regular user could potentially do this.
But in this particular case isn't the problem that it's sending everything in the sandbox? Rather than what it might do in an otherwise un-sandboxed system?
The readme is confusing. You say it has bubblewrap, but you also have an FAQ saying why not to use bubblewrap? Another FAQ says why not to use sandbox-exec for mac, yet the link for mac goes to sandbox-exec?
LLMs made it way worse https://ashishb.net/tech/react-native/
reply