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.
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.
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.
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.
I wish there was a public database of corporate ASNs and IPs, so we wouldn't have to rely on Cloudflare or any third-party service to detect that an IP is not from a household.
It’s not worth gold, a lot of CRTs are dead or dying, the tubes have limited hours. After that, they just become junk. Most have been disposed, so you’re going to struggle to find a local one.
Shipping them is annoying and expensive, no one wants to lug around heavy ass CRTs and larger ones probably have to ship on pallets.
Small CRTs that are easy to carry will get snatched up quickly, but mostly by retro gamers who have no alternative.
The difficulty of finding CRTs is mostly a logistics problem. Not because they are so valuable that people horde them.
Where are you located? I've been grabbing them whenever I see them (roadside, e-waste, yard sales, etc.) for years and honestly have too many. Some of them, like my 36" Trinitron, have become an albatross.
If you are like me and like to toy around with ancient game engines, for the sake of simply modding or trying things out, I made this tiny clean fork: https://github.com/klaussilveira/clean-quake
The idea is that it builds on 64-bit Linux with a very simple Makefile and SDL2, so you can start from there as your ground truth, and then have fun. It also removes a lot of cruft, like all the DOS and Windows 95 stuff mentioned in the article.
I honestly can't understand why Epic Games refuses to open-source Unreal 1 and UT99. They insist on licensing individual developers, instead of opening up the source so community forks can thrive. Look at the id tech community, with all the Doom and Quake forks, and all the amazing projects that spawned off of them.
The topic of "middleware" often comes up, as an excuse for them not being able to open the source. Well, just remove any third-party libraries and middleware, even EA did it with their C&C open-source releases. The C&C release did not even compile, but that did not stop the community from porting to Linux and other platforms, as well as modernizing the source and creating replacement libraries.
One explanation that was brought up before about this was licensing. A lot of the source code has been touched by other entities like Digital Extremes who may feel differently about releasing the source. That's even more true for UT2k4 which was worked on by many more companies behind the scenes, some of which are now defunct.
I found somebody on Youtube a few years back that remade Nyleve Falls in 3DS Max and all I could think was how cool it would be to reboot Unreal 1 with modern graphics.
That's huge. I wish LuaJIT adopted this, or at least added a compile time flag to enable it.
reply