All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Apt, Apache, and Lua
Today I tried upgrading my server which is running Debian unstable. I noticed that apache2 was held back. Here are some notes and a few questions at the end. Any help and comments will be greatly appreciated. Thanks!
Apt and Apache
root@lol ~ # apt-get update
Get:1 http://deb.debian.org/debian unstable InRelease [198 kB]
Get:2 http://deb.debian.org/debian unstable/main Sources [10.6 MB]
Get:3 http://deb.debian.org/debian unstable/main amd64 Packages [9,944 kB]
Get:4 http://deb.debian.org/debian unstable/main Translation-en [7,230 kB]
Fetched 28.0 MB in 2s (16.2 MB/s)
Reading package lists... Done
root@lol ~ # apt-get upgrade
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
The following packages have been kept back:
apache2 apache2-bin apache2-data apache2-utils
0 upgraded, 0 newly installed, 0 to remove and 4 not upgraded.
root@lol ~ #
I wondered why apache2 was held back. I took a quick look at man apt-get and then tried to investigate with the --dry-run flag.
root@lol ~ # man apt-get
root@lol ~ # apt-get full-upgrade --dry-run
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
The following package was automatically installed and is no longer required:
liblua5.3-0
Use 'apt autoremove' to remove it.
The following NEW packages will be installed:
liblua5.4-0
The following packages will be upgraded:
apache2 apache2-bin apache2-data apache2-utils
4 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Inst liblua5.4-0 (5.4.6-3+b1 Debian:unstable [amd64])
Inst apache2 [2.4.59-2] (2.4.60-1 Debian:unstable [amd64]) []
Inst apache2-bin [2.4.59-2] (2.4.60-1 Debian:unstable [amd64]) []
Inst apache2-data [2.4.59-2] (2.4.60-1 Debian:unstable [all]) []
Inst apache2-utils [2.4.59-2] (2.4.60-1 Debian:unstable [amd64])
Conf liblua5.4-0 (5.4.6-3+b1 Debian:unstable [amd64])
Conf apache2 (2.4.60-1 Debian:unstable [amd64])
Conf apache2-bin (2.4.60-1 Debian:unstable [amd64])
Conf apache2-data (2.4.60-1 Debian:unstable [all])
Conf apache2-utils (2.4.60-1 Debian:unstable [amd64])
root@lol ~ #
Lua and Apache
Looks like
- liblua5.3.0 had been installed,
- the apache upgrade wanted liblua5.4.0, and that
- apt was being careful by not auto-removing liblua5.3.0, which might have been in use.
Lua? Why Lua? I didn't remember installing liblua. I had heard that Lua was a computer language, but I didn't know about Lua.
The first result of a Google search for "liblua apache" was a link to an article, Lua for Apache, at admin-magazine.com. The article didn't seem to have a date, which always is a big red flag for me, but I decided to take a quick look. I was surprised that the article seemed well written.
I noticed that the article listing on Admin-magazine's home page had dates. So I searched in their search box for articles containing the word "lua." The second result was the article I wanted, Lua for Apache. The listing contained the date "10.07.2012."
The article explains that Lua is a scripting language developed in 1993 with these prominent features:
- small, fast interpreter,
- C interface,
- imperative and functional,
- "rudimentary" support for object-oriented programming, and
- "minimal syntax."
The article says that the minimal syntax "makes Lua programs more cryptic than their PHP counterparts."
According to the article, there have been several implementations of Lua scripting for Apache. Several implementations are listed in the article. One of these, mod_wombat, by Brian McCallister, in 2006, has become [had become by 2012?] the mod_lua in the Apache mod family along with mod_perl and mod_php.
The article continues with
- how to compile Apache with Lua enabled,
- Apache configuration [again from 2012?] for Lua,
- a Lua Hello world example,
- an example form for first and last name, and
- a discussion of hooks.
Questions
It looks like my Apt and apt-get options include
apt autoremoveand thenapt-get upgrade, andapt-get full-upgrade.
Do I understand right that the former will leave liblua marked as autoinstalled, but that the latter will mark liblua as manually installed?
Does anybody here use Lua? Does anybody here use Lua with Apache? If yes, what particular feature of Lua appeals to you for your project?
New Apt Terminal Colors
By the way, Apt in Debian unstable has cool new terminal output colors! The new Apt colors look really great! It's fun to watch the Apt output!
Wish
Speaking of terminal colors, is anybody here using Wish?
Comments
First off apologies for mostly skimming your post but i think apt holding back the packages is because of increasing versions (a basic upgrade only pulls in patches for the version already installed and doesn't actually update packages to newer versions). Given you are running unstable version updates aren't that uncommon (it seldom happens on stable too but there it's rather the exception that the norm - i.e. packages that have to update to new versions like Firefox ESR when support runs out for example).
The sudden addition of LUA is probably due to the newer version of Apache coming with some kind of LUA module that needs it. As for marking it as manually installed i kind of doubt any kind of upgrade would do that but then i don't really know
full-upgrade. If i want to update to new versions i usedist-upgradebut i wouldn't be surprised iffull-upgradewould just be a newer alias fordist-upgrade. TLDR: As long as you don't explicitly install something and it just gets pulled in by something else it should not be marked as manually installed.On LUA in general: It's an OK scripting language. I'm not a big fan but from my perspective it's still one of the more pleasant options.
No worries! There's a lot in there.
Thanks for these helpful comments! I need to study up more about Apt. I already mentioned it above, but I will say it again, the colored output of the new Apt is really nice!
Nobody here uses Lua? Really?
Cloudflare use Lua pretty heavily!
FYI..also the AntiDDoS solution that I wrote for my college thesis is also written in LUA.
Define 'using'
I've used LUA for game scripting when that was the language of choice and i prefer it over Python any day due to being procedural (there might be some OO extension but i've never noticed it) and overall conservative enough to let me get by with looking stuff up as needed. The JIT engine is also surprisingly fast. I still wouldn't claim to be using LUA.
If TCL wasn't a thing i might be doing more LUA. It's the next best thing for integrated scripting after all but outside of that i'm not sure if i wouldn't just use PHP instead.
@entrailz Thanks for this! I didn't know! I found https://blog.cloudflare.com/more-consistent-luajit-performance which is a really interesting blog post from December 2018 covering Lua performance testing at King's Collge London that was sponsored by Cloudflare. The post doesn't talk about why Cloudflare uses Lua and where Cloudflare uses Lua, but it sure seems clear that Cloudflare had been looking at Lua very carefully as of 2018. Fun to read!
Interesting! May I please have a link? Thanks!
"Using" means it runs on at least one your servers at least every once in a while.
A friend kindly showed me some TCL. Amazing what TCL can do!
The article linked in the OP, Lua for Apache, prominently mentions "small, fast interpreter." Interpreter speed also is what the Clooudflare-sponsored testing focussed upon. Florin used Lua for his DDoS protection, which would need to be fast. And now you also summarize Lua's speed as "surprisingly fast." So I now get it that the fast interpreter might be one (the?) major reason for adoption of Lua. Thanks!
Anybody else here actually using Lua? Thanks!
Their most recent outage mentions their usage of Lua here:
https://blog.cloudflare.com/cloudflare-incident-on-june-20-2024
Garry's Mod put a lot of kids onto Lua:
https://garry.net/posts/lua-the-programming-language
You could make thousands of dollars in high school running a server and selling VIP perks 💀
This morning:
Looks like a couple more updates were added since yesterday.
Afterwards:
Google Gemini wrote a program in response to my request to compare time taken to write "hello world" 10,000 times to /dev/null in C versus in Lua from C versus in Python from C. Here is the program, the compile command, and the result in case anybody might be interested. No claim that the program makes sense and no claim that the result is meaningful.
But it definitely was fun messing with this program! 
Nice. Maybe you could try compiling against LuaJit (https://packages.debian.org/sid/libluajit-5.1-dev) to see how much of a difference it'll make (in theory it should be even faster than default Lua - might not really do much here due to being bound by startup time though)?
LuaJit should be API compatible to standard Lua so all you'll have to change is the library you compile against (
-I/usr/include/luajit-2.1instead of-I/usr/include/lua5.3and-lluajit-5.1instead of-llua5.3- don't ask me why the library is called 5.1 when it's really version 2.1...).@totally_not_banned Thanks for your comment! I will try it, probably tomorrow or the next day. I will post the results here. Thanks again!
I guess this looks okay. In particular, for the present context, I guess there is no problem with the above listed conflict with libluajit2-5.1-dev.
Does anybody see any issues / something I am missing? Thanks!
So does it look right that the compile command should become:
gcc -O hello_world_files hello_world_files.c -I/usr/include/python3.12 -L/usr/lib/python3.12 -lpython3.12 -I/usr/include/luajit-2.1 -lluajit-5.1Thanks!
Made a new luajit directory, copied the C source file, and renamed it to add its version, which is 4. When I try to compile,
gccthrows no error, but seemingly fails to produce output.ldthrows an error. What's up?Oh! Maybe the compile command is wrong. I mixed up optimization level (-O) and output file (-o). Let me try again. . . .
So, I showed these errors to a friend
who suggested a few changes to the C source code. I will go try those changes. . . .
Of course, we now lose the idea of running the identical C code calling lua and luajit.
It might also be related to the order of arguments used with GCC. I'm not 100% sure as i usually build in multiple steps (as in build object files first then link them together with libraries) but at least there order matters when resolving symbols and the fact it also fails to locate Python related symbols (nothing about them changed at all) is suspicious. Maybe try moving the
hello_world_files-4.cargument after-o hello_world_filesand see if this fixes things.Here are a revised version of the program, a revised version of the compile command, and results of one run of the compiled binary.
I am guessing that the changes to the includes in the C code to accommodate LuaJIT are insignificant to the results. Maybe we could add the non-JIT, regular Lua interpreter includes a long with the JIT includes, detect or add an option to specify whether JIT or non-JIT was being used, and thus run the exact same code with both the regular Lua interpreter or LuaJIT.
I saw what seemed to be significant variations of the times in the output of multiple runs of a previous version of the code. So let's not put much faith in the results obtained in any single run. Maybe, if anyone is interested to try multiple runs, and make a guess about the causes of variations, that might be fun.
Interesting. As for making the type of Lua optional, it's a little tricky since both libraries export the same symbols, so building against both of them will not work (at least without some serious voodoo magic and butchering the benchmark code). The most sane way would probably be to not link against the libraries at all but rather use dlopen to load either the default or the Jit version and then use dlsym to get the relevant function addresses. This would obviously need using variable function pointers for all Lua related functions (which are set to the results returned by dlsym).
Shouldn't be that much work overall but might be a little confusing for people not used to the whole pointer thing. If there's some interest in this and there aren't any other takers (it's a nice exercise after all) i guess i could volunteer to do it
@totally_not_banned Below is me prompting Google Gemini:
Here is hello_world_files-6.3.c, the compile command presently used, and the result of running the compiled program.
Can you please make hello_world_files-7.0.c with luajit or regular Lua interpreter a command line option? My friend says: "Both libraries export the same symbols, so building against both of them will not work (at least without some serious voodoo magic and butchering the benchmark code). The most sane way would probably be to not link against the libraries at all but rather use dlopen to load either the default or the Jit version and then use dlsym to get the relevant function addresses. This would obviously need using variable function pointers for all Lua related functions (which are set to the results returned by dlsym)."
Literally two seconds later, Gemini says the following:
Absolutely! You and your friend are correct. It's indeed more flexible to make the choice of Lua interpreter (standard Lua or LuaJIT) a command-line option and use dynamic loading to avoid linking conflicts.
Here's the revised hello_world_files-7.0.c that implements this approach, along with explanations:
Key Changes:
dlopen, dlsym, and dlclose are used to dynamically load the Lua library specified on the command line.
Function pointers (luaL_newstate, luaL_openlibs, etc.) are used to store the addresses of the dynamically loaded Lua functions.
The main function now takes command-line arguments. The first argument (argv[1]) is expected to be either "lua" or "luajit" to specify which Lua implementation to use.
The load_lua_library function loads the appropriate Lua library (liblua5.3.so or libluajit-5.1.so.2) based on the command-line argument.
Lots of errors appear when compiling. Gemini is going through multiple revisions, and, at least, the number of errors is being reduced. . . .
Wow, it's already crazy/scary enough how much it can figure out but if it doesn't succeed in coming up with a working version just ping me. From skimming the code it looks like it messes up giving the function pointers correct type declarations (it uses the lua_CFunction type for all of them when the functions take very different parameters, which obviously won't work - like for example luaL_newstate takes zero parameters while luaL_loadbuffer takes 4). There might be other things too but this sticks out the most during a quick glance.
Gemini and I kept going through many more versions. Finally we mutually decided to give up on the idea of combining Lua Interpreter and LuaJIT in the single program. Gemini wanted to simplify by writing two separate programs, one comparing C, Lua, and Python, and the other comparing C, LuaJIT, and Python. Here is the first of the two programs, the compile command, and the output.
Working on the second program with LuaJIT. . . .
Pretty soon LuaJIT is going to catch up to C! /s
No claim that this code or these results are correct!
Unless somebody has a comment or a question I am going to move on to a new project. Thanks to @totally_not_banned for friendly help and friendly support!
Hehehe, maybe? Who knows? In any case it's impressively fast for such a little scripting language.
Well, at least the result (LuaJit being faster than default Lua) is what would be expected, so chances are that even if it isn't 100% spot on it's pretty close.
Any time. It's kinda cool to see Lua beat Python (which is a way more popular language) by such a big margin