Hacker Newsnew | past | comments | ask | show | jobs | submit | akazantsev's commentslogin

> Would also be trivial for the author to add a warning for users that have that setting enabled. Something like "Heads-up: you have requested reduced motion, and this library disabled animations as per your request"

They already do exactly this. The commenter wants a switch to force animations anyway, so he can check the demo without changing system settings.


At the time that I viewed it yesterday, there was no indication that it respected the "prefers reduced motion" setting, so I was very underwhelmed at first until I remembered I had that turned on.

> I'm always wondering whether or not SDL would be better

SDL supports mobile; GLFW doesn't. Maybe they're unifying codebases between the platforms.

Edit: BTW SDL3 still works even on Android 4.2. I made an app using it and ImGui, without any Java.


Your suspicion is that they're going to discontinue Bedrock and replace the iOS and Android versions with Java? Even though iOS doesn't even allow Java with JIT?

Dunno. Apple makes exceptions for big companies and might do so for something as big as Minecraft. Also, SDL3 supports far more platforms https://wiki.libsdl.org/SDL3/README-platforms Now they can release a Java edition even for PlayStation and Xbox. At least porting to SDL3 opens the door to consoles and mobiles if they want to do so.

If both sides are willing to do that, why didn't they do that the first time instead of creating Minecraft PE?

PE was created in a time where phones were VERY unimpressive when it came to compute

Also, minecraft wasn't nearly as big as it was today. It was noticeable, but it wasn't headed by microsoft. There's no way it would've gotten an exception

It's possible they could AOT compile for iOS, but I think the idea they are unifying to be unlikely.

Highly doubt it. The current mobile version (Minecraft bedrock) is the version that Microsoft wants everyone to use. Java edition only sticks around because they know it's the version most of the community wants.

And the one that Mojang actually uses for development. IIRC any new features are done in Java and ported to bedrock (presumably by a seperate team)

> Gemma isn’t very good at agentic execution

I had no issues with it for C++ development with https://pi.dev. I'm yet to try it with Zed Editor. I don't rely on agents too much. However, I used it on Chromium's codebase to research some functionalities, let's say for searching. Requests like: check my last commit and do the same for SetterA and SetterB; it also ran without any errors.


Google makes Gemma 4 31B QAT; that's not a small lab. It's one of the better models out there for consumer hardware. Allows me to run it on a 7900XTX with 64k context.

A week ago, the Windows AMD drivers auto-updated and stopped working. I had to reinstall them. I am not sure if that counts, because this is not the first time this has happened.

https://www.reddit.com/r/AMDHelp/comments/1udaj4w/new_amd_up...


That's because sandboxing is quite hard. I use `cco`, but even then, the home folder is exposed. You are one prompt away from the agent sending the browser passwords with curl.

To prevent this, you need a fake home and a networking whitelist for the agent to access the provider (llama cpp, OpenAI, etc.)

There is no cross-platform solution that is easy to use for this. And no, a Linux box with Docker won't do. I develop a cross-platform native app and want the agent to compile and fix the platform-specific errors.


Sandboxing is a VERY HARD problem. I've been working on it for months, and finally have something that's mostly there:

- Sandbox on Linux using Docker, Podman, containerd, gVisor, Kata, Firecracker

- Sandbox on Mac using Docker (Docker Desktop or Orbstack), Podman, Apple containers, Seatbelt, Tart (Tart lets you run simulators).

- Network control

- Secrets control (file mounts or credentials broker)

- NO ambient data (ENV is replaced with a minimal and local-to-sandbox one)

- NO access to your homedir. You have to explicitly mount things you want.

- NO direct access to your workdir: Your work dir is never modified until you apply the changes, either standalone or as a git commit. You can also diff before applying. Git runs sandbox side in case the repo has filters.

- gitignored files never get copied in. The agent never sees them.

- Has built-in support for claude, codex, gemini, aider, and opencode, but you can also launch it in "shell" mode and run whatever you want.

- Supports VS code tunnels, so you can remotely access in VS code if you don't want to use the terminal.

- Full lifecycle support: Launch, attach, stop, restart, wait, one-shot, clone, destroy

- MCP passthrough

- Layered API (golang) if you want to sandbox other things

- Self-contained binary. No external requirements other than the backends you want to use. Defaults to a ~/.yoloai dir for config/data, but you can point it anywhere.

- FOSS

https://github.com/kstenerud/yoloai


Sandboxing in a container in Linux isn't hard, if you use lxd/incus which ships with Ubuntu/Debian.

It all seems so simple at first. Just launch a container/vm with a base image of your dev environment, mount whatever you need, do your work, and then tear down. Maybe add some iptables rules for good measure. Easy peasy, something any moderately competent dev could do and even put in a quick shell script.

I started with that assumption, but there are a lot more gotchas and security issues than you'd think.


but this seems quite overkill no?

I currently run pi agent in Lima on a Mac with only the code project folder mounted and an extension that prevents pi agent from reading the contents of .env files directly.

Yeah, there probably are some freak situations where this isn't safe enough, but I don't really see any realistic ways this is going to end up badly. Am I overlooking some obvious security holes?


I designed it to provide a single interface to agent sandboxing, no matter how far up the security tower you want to go.

It eliminates the manual process steps you end up doing with an ad-hoc system (which gets old the 10th time you do it).

Common weak points:

- The agent can access your homedir.

- The agent can access .gitignored files, which can contain secrets (and are gitignored for this reason).

- The agent has r/w access to your workdir.

- The agent could follow your remote mounted dirs.

- The agent can act in your name with whatever credentials it finds (and it will use them when it tries to be helpful, especially with the gh tool).

- Do you even know what's in the diagnose_problem.sh file it just created and asked permission to run?

- Even the .git dir can be weaponized, such as with evil filters.

- The agent can edit its own process, bypassing the harness controls and giving it the same access as you have (amplified by each credential sitting on that machine).

Meanwhile, you're reflex-hitting ENTER without looking because 99% of the permission prompts are mundane.

And that's before you even get to all of the idiosyncrasies in the backends that will eventually trip you up. The list is quite large and continually growing: https://github.com/kstenerud/yoloai/blob/main/docs/contribut...


i have a photon os vmware, agent has root and docker plus a few api keys with minimal credits.

if it messes up: - no sensitive data is there, so it doesn't really work for serious dev but it's secure for play time

- roll back and fix is done in 10s with ram snapshot

- dollar loss is $10 when it leaks the api key


This is exactly what VMs are for.

Heh, good luck with that.

Explain Mr vague.

I've already explained in some sister comments. Sandboxing is one of those things that seems very simple on the surface, and is EXTREMELY complicated once you start actually digging into the implications, gotchas, and security issues. The underlying tools were never designed with this use case in mind, so they need a little help to reach that last mile. And this glue is where all the chaos ensues.

Here's a small sample of the crazy shit you have to deal with: https://github.com/kstenerud/yoloai/blob/main/docs/contribut...

And that's if you're actually following the proper procedures (which are themselves byzantine and tricky to get right).


I use sandbox-here for this reason, it's a wrapper around bubblewrap, which works quite well.

Copy the code and adjust it to your liking:

https://github.com/lionkor/sbh

I have a shell alias for it, and use it like

    sbh --net pi
for example or

    sbh --net codex
and maybe add --docker if I expect it to do docker things.

This kind of wrapper is much easier to handle and maintain than a completely separate tool for sandboxing agents.


> That's because sandboxing is quite hard

colima makes it pretty easy, on macOS and linux at any rate.

https://colima.run


Still wild to name a sandboxing software after one of the most infamous Soviet Gulags in history.

It's wilder to accuse someone of naming the container version of the lima sandboxing software after a gulag.

These type of moral outrage comments take an extreme amount of effort to debunk compared to writing them.

1. There is no gulag called Colima, it doesn't exist.

2. There was a gulag near a river called Kolyma

3. The pronounciation and spelling of Kolyma and Colima are completely different, in fact Colima is an Aztec word

Colima stands for Containers on Lima. Lima stands for Linux Machines (a popular open-source utility used to launch Linux virtual machines on macOS).


> in fact Colima is an Aztec word

I was curious if the adjacent tool name (Lima) had anything to do with the capital of Peru, but I guess not.


Isn't it named after the Mexican state?

Others have covered why that isn't what's being done, but also if it was that would be a _fabulous_ joke.

I’m kind of sad it’s not named after it now, that would’ve been very amusing

Colima is in Mexico.

Kolyma is in Russia.


Use multipass by canonical. Works on macOS, windows, Linux.

If you work on Windows you most likely need Windows as VM

Using VMs to isolate LLM agents isn't hard at all. It is IMHO the only sane option.

> Now why do I have to care about "cloning templates" every time I render some html template?

You do not have to. It's a self-sustained injury by the author. You can compile the templates once and just execute them.

The issue is that author wants to specify page titles in the main templates. If you pass titles as a context, you can split base.tmpl into BASE_BEGIN, BASE_END and use them in the final templates.

Yes, you will have to pass the title depending on the page template during the But his tactics will break anyway when you try to support different languages.


That's not the reason I use Clone() in this pattern. The main reason for the clone operation is convenience. The clone operation is on the already-parsed set of shared templates (base+partials in this example code). It provides the convenience of not having to specify the path to the base template and any paths to the partial templates needed by that page in the call to render().

There may also be a performance benefit too - I suspect that the Clone() operation is cheaper than re-parsing the base and any necessary partial templates in each render() call, but I've never benchmarked it, so I can't assert that with certainty.


Unlikely Linux will become mainstream until people stop saying "install Linux" and not a particular distro. I recently installed Ubuntu on a new laptop: something doesn't work because I need a more recent kernel, so... I installed the second "user-friendly" distro - Fedora. Scrolling is 10x faster in Chromium-based browsers, making it unusable. The fix - install KDE... Then I had to make hardware video acceleration work so that playback wouldn't drain the battery. That was a pain in the ass.

So, Linux won't consume LESS unless you spend your time configuring different stuff.

I can't imagine users want to mess with this instead of buying macs.

https://www.reddit.com/r/brave_browser/comments/1qqyh2z/scro...


I got Mint back in 2022 for my desktop built in 2014. Everything worked fine and I was even able to customize my install (though I regret some choices). It used considerably fewer resources than Win10 (never mind Win11, which I don't think would even install on this machine) out of box. I'm talking 40% less RAM use at the desktop before opening programs; and that's for Cinnamon (Xfce would be leaner still). And grindy I/O that touches a lot of small files is about three times the speed. No fancy configuration necessary. I did a simple install for a relative on even older hardware, again no problems.

If I needed to change a kernel version, it's literally as easy as selecting it from a menu in a pre-installed GUI "update manager", letting it do its thing and rebooting. I can get up to the bleeding edge (although I have no good reason to).


Yeah, everyone always misses the little things when it comes to the masses moving to Linux.

Linux is not an operating system (as people know it). Ubuntu is, Fedora is, etc. Like you said, "install Linux" is meaningless and leads you down a rabbit hole of "what distro." Just say "Install Fedora KDE" or whatever.

But even saying "Install Fedora KDE" is going to alienate an enormous group of the general population. We can manage it, gamers can largely manage it, and someone relatively tech-adjacent can handle it. The completely non-technical person that does most of their computing on an iPhone? Not a chance in hell you're going to get them to download an ISO, flash a USB drive, and boot from it. Queue up the questions "Wtf is an ISO? I haven't had a USB drive in 10 years...what is an operating system?"

Remember that OEDC study? About 80% of the global adult population is functionally computer illiterate when it comes to solving problems or doing tasks that aren't completely on rails. 24% of adults cannot use a computer at all. An additional 14% can only do one-step, highly guided tasks like click a single link, or delete a single email. Another 29% can use a web browser or email basically but struggle with any task that requires navigation or multiple steps.

Being in tech and in tech communities its easy to assume some basic level of competency, but that level does not exist. I've experienced it first hand throughout my career in IT. Most people where I work struggle with the concept of basic file management, let alone anything more advanced than sending an email or finding a file.

Year of the Linux Desktop will never happen without mass market preinstalls as the default choice.


The flip side is that the pot is now boiling. Windows and macOS are both replete with advertisements and service upsell, which is something that nontechnical and technical users both pick up on. It's been expanding the discussion of alternatives, and gave Linux a piece of the spotlight in the PC gaming world. Normies that watch LTT, Gamers Nexus or Jayztwocents have been exposed to Linux already. Many of them bought a Steam Deck and switch to the desktop, getting their first "preinstalled" Linux desktop experience.

The Year of the Linux Desktop won't be when everyone switches to Linux. You can't save everyone, there will always be iPads and gaming laptops that will never see proper Linux support. OP's point seems to be that higher device prices will push people to get more mileage out of depreciated Intel Macbooks and Windows 10 desktops. Price increases will outright prevent some customers from engaging in the upgrade cycle altogether, which is why a lot of enthusiasts and gamers have already switched to Linux distros for extended support.

If this squeeze continues, more and more low-income computer users will defect from the upgrade/service treadmill. It won't be a firehose of defectors, but it's already enough to make an impact.


Fair point, but I'd say

> Normies that watch LTT, Gamers Nexus or Jayztwocents have been exposed to Linux already.

Aren't normies at all. The 80% that are functionally computer illiterate aren't watching LTT. Someone with enough interest to follow gaming/tech youtube channels can probably already handle installing Linux with a little handholding.

I agree on your other point though, you can't save everyone. We'll just bifurcate. That 80% just won't own a general purpose computer at all outside of what is provided by their employer. They'll use their smartphone, and maybe an iPad. The desktop/general purpose market will shrink, but Linux definitely is ripe to take nearly that entire market as it is now effectively becoming an enthusiast only market.


> Lol I feel like no one has any attention span here. Tech shit is expensive in the beginning when it's new. It gets cheaper with time.

The funniest comment here. Have you seen the prices of the technical shit for the past two years? Dang, GPUs are not getting any cheaper, but more expensive with each year.


That's an artificially inflated market. OpenAI and xAI bought everything for like two years into the future, partly to inflate the AI bubble, partly to lock-in a monopoly on the kinds of compute you need for AI, and partly to scale up actual operations. They can't realistically keep buying all the RAM in the world forever, the money has to run out eventually (though the market can remain irrational for quite a long time and can keep giving OpenAI and Apartheid Clyde money well past the point of reason).


It’s a massive supply crunch. More production will come online.


Probably not, at least for DRAM. The demand has historically been very variable, and building production capacity takes multiple years. Also, spare capacity is really expensive. Thus the memory manufacturers don't want to expand, betting on it being yet another temporary bubble.

Also, DRAM fabs are not really usable to make compute (CPU, GPU, etc in this context) silicon. The production lines and tech have diverged some decades ago. So unlike TSMC which can relatively easily retool for another customer, no such luck for the big DRAM manufacturers.


How did Apple figure this out? Isn't the solution to this to sort of evolve to a unified memory architecture, which wins in speed and cost anyway?


I haven't looked at apple specifically, but generally the approach taken with HBM on GPUs etc is to make multiple chiplets and connect them together very close and with very high bandwidth. The chiplets are made with different processes, optimised for each specific use case.

There are a few different variation, such as having a carrier chip below (as an interconnect), having a small PCB that everything is mounted to, or even vertically stacking chips (AMD's 3D v-cache does this on some of their CPU models).


brother its been 1 year since claude code released. how fast are you expecting these things to happen? the physical world and hardware are still constraints. someone has to dig shit out of the ground to build these things.


Is it? Learning is one thing. But owning a large codebase, you see for the first time, is a completely different level.


When I started working on a large legacy C++ code base in the early 2010s, I learnt. It took probably close to a year until I was proficient enough that I didn't regularly need to ask where to fins things. This is a skill we used to have (and some of us still have).

Though if your code base is all a vibe coded mess and you don't have a senior human colleague to ask... Good luck?


Yeah giving up is totally a viable choice, but it isn't the only option.


Consider applying for YC's Fall 2026 batch! Applications are open till July 27.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: