4 ms·

It doesn't seem like the author is aware of the irony of talking about minimizing bloat while advocating for running things in virtual machines instead of nativ

It doesn't seem like the author is aware of the irony of talking about minimizing bloat while advocating for running things in virtual machines instead of natively on a single OS. I know there's still a point to minimizing bloat when VMs do* makes sense in business/institutional environments but it's still funny in most use cases.

bongodongobob 3y ago
Yeah nothing like having databases running on the print server. Gotta avoid that bloat. I smash all my applications into one server, it's so much leaner. Seriously though, I have no idea what your point is.
- djangogitit 3y ago
  [dead]
yjftsjthsd-h 3y ago
I'm reading this as using the VM for software compatibility (Linux software on Plan 9). You absolutely can do that without a VM (see: WSL1, FreeBSD/NetBSD/illumos Linux ABI compat layers, WINE, darling, vx9, ...) but it's hard - there's a reason MS eventually created WSL2. Using a VM doesn't have very much overhead these days and gives you ~perfect compatibility with minimal effort.
throwaway11460 3y ago
What's your recommendation for secure workload separation?
lproven 3y ago
Hi. I'm the author. It seems to me that you are unaware that this is part 4 of a series adapted from my 2024 main programme talk at the FOSDEM conference. https://fosdem.org/2024/schedule/event/fosdem-2024-3095-one-way-forward-finding-a-path-to-what-comes-after-unix/ https://fosdem.org/2024/schedule/event/fosdem-2024-3095-one-... This article is just the epilogue and you are misunderstanding it because you lack its context. I turned the talk into 4 articles. This one states the problem: https://www.theregister.com/2024/02/12/drowning_in_code/ https://www.theregister.com/2024/02/12/drowning_in_code/ This one tries to explain the history: https://www.theregister.com/2024/02/16/what_is_unix/ https://www.theregister.com/2024/02/16/what_is_unix/ This one offers a path forwards: https://www.theregister.com/2024/02/21/successor_to_unix_plan_9/ https://www.theregister.com/2024/02/21/successor_to_unix_pla... You just read the epilogue which suggested some ways that people who weren't kernel developers -- as I am not myself -- could help.
- superkuh 3y ago
  > There is an urgent need for smaller, simpler software. When something is too big to understand, then you can't take it apart and make something smaller out of it. And the first step is stopping the practice of adding 6 extra layers of container/vm/etc abstraction on top of everything making it infeasible to debug or understand.
  - lproven 3y ago
    I completely agree. Which is why I propose 9front as an alternative point to start from. But it has few apps, and is too different to readily port to. So, I'm suggesting a way to efficiently run Linux apps on 9front without emulating Linux. So we can use existing tools while working on replacements.

bongodongobob 3y ago

Yeah nothing like having databases running on the print server. Gotta avoid that bloat. I smash all my applications into one server, it's so much leaner. Seriously though, I have no idea what your point is.

djangogitit 3y ago
[dead]

yjftsjthsd-h 3y ago

I'm reading this as using the VM for software compatibility (Linux software on Plan 9). You absolutely can do that without a VM (see: WSL1, FreeBSD/NetBSD/illumos Linux ABI compat layers, WINE, darling, vx9, ...) but it's hard - there's a reason MS eventually created WSL2. Using a VM doesn't have very much overhead these days and gives you ~perfect compatibility with minimal effort.

throwaway11460 3y ago

What's your recommendation for secure workload separation?

lproven 3y ago

Hi. I'm the author. It seems to me that you are unaware that this is part 4 of a series adapted from my 2024 main programme talk at the FOSDEM conference. https://fosdem.org/2024/schedule/event/fosdem-2024-3095-one-way-forward-finding-a-path-to-what-comes-after-unix/ https://fosdem.org/2024/schedule/event/fosdem-2024-3095-one-... This article is just the epilogue and you are misunderstanding it because you lack its context. I turned the talk into 4 articles. This one states the problem: https://www.theregister.com/2024/02/12/drowning_in_code/ https://www.theregister.com/2024/02/12/drowning_in_code/ This one tries to explain the history: https://www.theregister.com/2024/02/16/what_is_unix/ https://www.theregister.com/2024/02/16/what_is_unix/ This one offers a path forwards: https://www.theregister.com/2024/02/21/successor_to_unix_plan_9/ https://www.theregister.com/2024/02/21/successor_to_unix_pla... You just read the epilogue which suggested some ways that people who weren't kernel developers -- as I am not myself -- could help.

superkuh 3y ago
> There is an urgent need for smaller, simpler software. When something is too big to understand, then you can't take it apart and make something smaller out of it. And the first step is stopping the practice of adding 6 extra layers of container/vm/etc abstraction on top of everything making it infeasible to debug or understand.
- lproven 3y ago
  I completely agree. Which is why I propose 9front as an alternative point to start from. But it has few apps, and is too different to readily port to. So, I'm suggesting a way to efficiently run Linux apps on 9front without emulating Linux. So we can use existing tools while working on replacements.