A few friends and me use bedrock in a similar manner to push the rules on a faction PvP (player-vs-player) server 10 years ago: Basically a faction was a group of players working together on their base. You could claim land and a base on it was then protected from modification by outside players as long as players from your faction didn't die too often. We didn't really participate in PvP (we sucked :-} ), basically never died but did other interesting redstone stuff like vending machines, etc. But other factions did and they were always at risk of becoming raidable as a result of dying too often. Once a base was raidable is was almost always immediately completely destroyed and stripped of anything remotely valuable.
So we figured we might host one of those faction within our claimed land. As long as they store all valuable within our secure base, the fact that their claimed land becomes raidable doesn't really matter. Claimed land had to be at least one block apart from each other. So we had to find a bedrock tunnel: On their claimed land there needed to be free space within the bedrock level to get down to z=-63. Then on the single unclaimable block between our bases we needed bedrock on z=-61 and bedrock on -62/-63 on both sides. Then on our claimed land we again needed a way to get up from z=-63. Basically a single block long fully bedrock-enclosed tunnel. Took a while to find that, but we managed to set it up and caused quite a stir with other players and the server admins once our hosted faction got raidable without consequences :-)
Yep. A Pi 1 can almost play 1080p60 with a proper zero-copy decoding setup. Pi 2 and beyond have no issue with that. As you said: The Pi5 has enough CPU power, so even the H264 decoding itself now uses software as it no longer has a hardware decoder. Oh well.
bubblewrap is a lot more flexible: You can freely piece together the sandboxed filesystem environment from existing directories, tmpfs, files or data provided via a file descriptor. landrun, from what I understand only restricts what already exists. What is neat with landrun is the TCP port restrictions. This isn't possible with bubblewrap at the moment, although nothing really prevents bubblewrap from adding landlock support for those cases.
Not true. It's getting a constant stream of bugfixes. It's also not "stuck" on Lua 5.1, but is deliberately not following Lua's path, except for some backports. There's also a recent post about how a LuaJIT 3 might work.
OK, then I got some wrong info. If it's stuck at it deliberately, then it's worse. May be someone should fork it and bring it up to date with recent Lua versions. Why is this split needed?
My understanding is that there was a language fork after 5.1. One thing was a complete reworking of how math works. It used to be just floating point for everything but the new idea was to make it like Python 3. So most operations are float/integer with some weird exceptions.
As with any language fork there will be some who stay and others who switch to the new thing. Often a fork will drive people away from a particular language as in my case.
Lua's nature as a primarily embedded language means backwards compatibility is not guaranteed between any version. If 5.2 was a language fork then so was 5.3, 5.4, 5.5, etc. (5.2 did have some more significant changes though)
For that reason luajit staying at ~5.1 actually works in its favor. Rather than trying to follow the moving target of the newest version, it gives a robust focal point for the lua ecosystem, while modern versions can be developed and continue to serve their purpose in embedded systems and whatnot where appropriate.
I don't see a reason not to update LuaJIT still. Changes in Lua aren't just version numbers, it should be improving something, meaning that would be missing in LuaJIT.
Isn't it a bit naive to declare that, just because Lua created a new minor version, it should be somehow better? The author of LuaJIT has often written his arguments, including why he disagrees with the changes to the language, why they should have been implemented as libraries instead, that in his view LuaJIT is still more performant and more widely used than PUC Lua, and more.
As for forking, you can try, but I would warn you that one does not simply fork LuaJIT. Required is deep expertise in tracing JIT compilers, in assembly and in many different computer architectures. Nobody was really up to the task when Mike Pall announced that he was searching for a maintainer, before his eventual return.
LuaJIT does have some backported features from newer versions. But Mike Pall -- the mad genius behind LuaJIT -- has made it clear he doesn't agree with many of the changes made in newer versions, hence why it's staying where it's at.
In RHEL I would never touch system python at all, and would install what every version I needed in a venv and configure any software I installed to use what ever version I needed. I learned the hard way to never mess with system python.
I strenuously disagree. Not every language needs to chase trends and pile on unnecessary complexity because developers want the latest shiny language toys to play with. It's good to have a simple, stable language that works and that you can depend on to remain sane for the forseeable future.
C is a language like that but I fear the feature creep is coming (auto? AUTO??.) JS is a lost cause.
Languages are products as well, either they evolve to cater to new audiences, or they slowly die as the userbase shrinks away with the passing of each developer generation.
The language is different. The changes to environments in particular are a non-starter. Sandboxing is incredibly clunky in 5.2+, and we lost a lot of metaprogramming power and dynamic behavior.
That seems like an implementation detail, not a fundamental design decision as it should be easy to change how packfiles are implemented. I'm not sure it would be an improvement though: it already only stores deltas for similar objects.
Would be surprised if that’s not how basically all tools behave, as I expect them all to seek to the central directory and to the referenced offset of individual files when extracting. Doesn’t really make a difference if that’s across a network file system or a local disc.
So we figured we might host one of those faction within our claimed land. As long as they store all valuable within our secure base, the fact that their claimed land becomes raidable doesn't really matter. Claimed land had to be at least one block apart from each other. So we had to find a bedrock tunnel: On their claimed land there needed to be free space within the bedrock level to get down to z=-63. Then on the single unclaimable block between our bases we needed bedrock on z=-61 and bedrock on -62/-63 on both sides. Then on our claimed land we again needed a way to get up from z=-63. Basically a single block long fully bedrock-enclosed tunnel. Took a while to find that, but we managed to set it up and caused quite a stir with other players and the server admins once our hosted faction got raidable without consequences :-)
reply