It assembles and pivots to own root filesystem. The filesystem mounts dirs and files from your original filesystem, most of them in read-only mode, but does not mount files that expose secrets to the sandbox. The sandbox also mounts own, writable version of your home dir, so secrets, such as .ssh dir are not exposed. The config file allows to configure which files should be exposed from your original home. For example, configs, such as .bashrc, are safe to expose in read-only mode, provided you don't store secrets in them.
and probably this is why there are so many such projects. With agents, a sandbox is an important tool to have, with LLMs it is easy to vibe-code a new project, so we have dozens of sandbox projects. With so much noise, it is hard for these projects to reach a critical mass, so we may continue to see more and more sandboxes. Most will get a couple of stars on GitHub, but will be used mainly by the author. Unfortunately, we may see the same pattern with any other problem domain, dozens of projects, many vibe coded, many of questionable quality, nothing reaching maturity due to too much noise.
I work on a sandbox which has similar isolation level to Podman (rootless Linux user namespaces), but with UX optimized for local development work. Take a look: https://github.com/wrr/drop
Basically, you don't enter a separate container in which you install a new distro, but you run on top of your current distro. You have environment specific home dirs which isolate your original home, but can have some files, such as configs, mounted from your original home (mostly in read-only mode).
Normal vending machine transactions are B2C transactions, so the buyer cannot be a company - cannot pay with company money and cannot deduce the payment as the company cost. I guess, the buyer can take a receipt from a vending machine and ask the vending machine owner to provide a B2B invoice based on the receipt, to make this a proper B2B payment.
Can you treat your remote service access as B2C only? Perhaps yes, but then the companies will not be able to use your service, pay from a company bank account and account this as a company cost, only individuals will be able to legally pay.
Vending machine is also located in a known physical country, so the owner knows what VAT to apply, the VAT of the country the machine is in. With software services the VAT should be applied based on the country where the buyer is located.
With payments the complexity is not only in accepting a payment, but largely in doing so legally. Someone makes a request to my company's paid service, I return 402 and get a stable coin back. Who do I invoice for this revenue? What value added tax do I apply to the invoice? If someone makes 10k paid requests within one month, do I have means of generating one invoice for them for all the usage, or is every request treated separately and results in 10k invoices?
Will CloudFlare handle this for me?
You are right, but if stock repurchase does not increase market cap, dividend payment still decreases it (unless it would be fully reinvested in the same stock, which it is not, it is largely reinvested in largest caps).
Could outperformance of largest cap companies be partially explained by dividends paid by smaller caps? Reasoning behind this:
* Index investing raises in popularity, with index funds that automatically reinvest dividends being often preferred due to their tax efficiency.
* Large caps prefer to repurchase stocks, stock repurchases contribute fully towards a given company share price increase.
* Smaller caps still pay dividends, these dividends are then reinvested by index funds and the reinvestment is weighted by capitalization, so large caps share price benefits more from repurchases done with dividend cash paid by smaller caps. When dividend is paid, share price of a company that paid it is reduced, which further widens the performance gap between large and smaller caps.
I work on a Linux sandbox that makes it easy to hide sensitive files from AI agents while keeping the files they need accessible. Check it out: https://github.com/wrr/drop
one possibility is that some heavily indebted AI infrastructure company will be unable to meet its dept obligations, which will cause banks that become heavily exposed to AI-infrastructure related dept to tumble
This is just an implementation detail, a feature flag can very well be implemented with a Boolean in a database.
To me the main appeal of feature flags is that they allow to work on large features that often require months and many commits to finish in a main branch. This, at least to me, results in a more lightweight and more iterative development process. This contrasts with maintaining a separate branch, with perhaps separate deployment target for a large in-development features.
When I was doing Fast.AI Deep Learning course, I was surprised by the number of Python dependencies machine learning projects bring. Web front-end projects were always considered very third-party dependencies heavy, but to
me, the machine learning ecosystem looks much more entangled. In addition, unlike web development, which is considered security critical and has over the many years accumulated a lot of wisdom and good security-related practices, machine learning development looks much more ad-hoc, with many common software engineering practices not applied.
For example, at that time, one way to distribute machine learning models was via Python pickles. Which are executable objects with no restriction built in. Models in this format could do anything on a computer where the model was imported. Such an early 'wild-west' ecosystem can definitely make security compromises easier and resulting supply chain attacks more common.
An interesting variant of a web phishing attack is to combine the back button hijacking with information that comes from the HTTP referer header. HTTP referer discloses from which website the user is coming from, when the user click the back button, the malicious site can take the user to the site that looks identical (except for the URL), but is attacker controlled.
Recently I was wondering how viable it is to launch a niche, paid tool for Linux. I found that this is a very rare model, most tools are either just free, supported by sponsorship, supported by some paid cloud-based service that accompanies the tool, use an open-core model with paid add-ons.
I wonder if the decision of Little Snitch to make the Linux version free forever was also informed by this "no way to make money selling tools on Linux" wisdom or if there was another motivation. It seems that if any tool has chances of making decent money on Linux, a product like Little Snitch, which is already well established, with working payment infrastructure would be a good candidate.
I'm not a Little Snitch or Open Snitch user, I wonder if these firewalls are able to block requests done with the use of some other, allow-listed program.
Say I run a script `suspicious.py' and I deny this script from making any network requests. I also have firefox which is allowed to make any HTTPS requests. If suspicious.py does something like:
I've co-founded Shapespark: https://www.shapespark.com
I'm also the author and maintainer of an authorization service for Heroku web applications: https://elements.heroku.com/addons/wwwhisper
You can contact me at [email protected]