[HN Gopher] AsmBB - a lightweight web forum engine written in as...
       ___________________________________________________________________
        
       AsmBB - a lightweight web forum engine written in assembly language
        
       Author : smartmic
       Score  : 125 points
       Date   : 2024-01-13 19:41 UTC (3 hours ago)
        
 (HTM) web link (asmbb.org)
 (TXT) w3m dump (asmbb.org)
        
       | kstrauser wrote:
       | That's insane and impressive. Well done!
        
       | DigiEggz wrote:
       | Really cool concept and execution. I did notice that the live
       | notifications quickly become overwhelming, so there should be
       | some kind of rate limiter on them.
        
         | hombre_fatal wrote:
         | I could see "@User123 has entered the thread" working in the
         | smaller forums I was a part of where I knew everyone.
         | phpBB/vBulletin show a "Users reading this thread: ..." list
         | for that reason, and there were popular plugins for things like
         | "@Foo and @Bar are writing responses to this thread". It helped
         | make the place feel more alive, especially when you were in an
         | intense discussion. It was nice to know the fker was working on
         | his next big quote-by-quote debunk of your post.
         | 
         | But getting a notification when unregistered guests click into
         | a thread doesn't seem useful to anyone.
        
         | ezekielmudd wrote:
         | Tap the Bell icon to disable the live notifications.
        
       | iamdual wrote:
       | I couldn't read the article on mobile due to live notifications.
        
         | CharlesW wrote:
         | Yep, the alerts occlude must/most of the page. This is probably
         | the first time the creator's encountered HN rush hour.
        
           | cristoperb wrote:
           | it's definitely not the first time the project has gotten
           | traction on hn (eg:
           | https://news.ycombinator.com/item?id=37285156)
        
         | ezekielmudd wrote:
         | Tap the Bell icon to disable the live notifications.
        
           | saagarjha wrote:
           | I can't do that either because the notifications pile up and
           | cover the button.
        
         | TOGoS wrote:
         | Dear AsmBB.org admin: Have those be turned off by default.
         | They're annoying even when they don't occlude the entire
         | screen.
        
           | al_borland wrote:
           | Especially for guests viewing the page. No one really needs
           | to know that a random person loaded the page. If there is
           | some kind of friend/follow functionality for logged in users,
           | and they want to enable notifications for them, ok, but
           | that's about as far as it should ever go.
        
       | zxspectrum1982 wrote:
       | It'd be nice to try to build this with Cosmopolitan
       | 
       | https://github.com/jart/cosmopolitan
        
       | giancarlostoro wrote:
       | Reminds me a little of D's official forums, which load faster
       | than you can close your eyes to blink. I love these kind of
       | projects.
        
         | dtx1 wrote:
         | Oh yeah it's immediately noticeable. How did they do it?
         | 
         | https://forum.dlang.org/
        
           | bhauer wrote:
           | Use a fast language and forget some of the old advice from
           | "12 factor apps," some of which are focused on avoiding
           | common challenges when scaling low-performance platforms.
        
             | esafak wrote:
             | Which ones did you have in mind?
        
           | wruza wrote:
           | D isn't "big" (as in "reddit big"), and any web-1.0 forum
           | that I remember from 2000s worked like that on old hardware.
           | If you're curious how a single SQL database can serve so
           | fast, it's caches and invalidation when a thread CrUDs
           | itself. Old boring tech.
           | 
           | Edit: the tone was a little sharp, edited it out, my
           | apologies
        
           | giancarlostoro wrote:
           | Its open source iirc it uses MongoDB and redis for caching,
           | worthy of noting is that you can also browse and download
           | that entire board with a Newsgroups client. It also posts to
           | IRC as well.
        
       | bdcravens wrote:
       | It's not just written in assembly, but it's backed by sqlite.
       | Like many apps, IO is more likely to be the bottleneck than the
       | CPU.
        
         | CharlesW wrote:
         | Using WAL mode with PRAGMA synchronous set to NORMAL, or even
         | in that case? (I'm the furthest from a SQLite expert, just
         | looking at it myself for a project.)
        
           | bdcravens wrote:
           | No idea - just did a quick scan of the source
           | 
           | https://asm32.info/fossil/asmbb/dir
        
         | PaulHoule wrote:
         | RAM is a factor too. I've written some programs for Arduino in
         | C that would be a good match for assembly because the stack and
         | C calling conventions are a complete waste. (e.g. sometimes you
         | have no recursive functions). The thing is portability --- as
         | much as I love AVR-8 if my requirements grow AVR-8 has no
         | nowhere to go except maybe an FPGA soft core. In C I can switch
         | to an ARM microcontroller which I find really uninspiring but
         | just performs better.
         | 
         | That's the one trouble w/ AsmBB that it is specific to some
         | particular architecture.
        
         | Cthulhu_ wrote:
         | That's often the fallacy people have, assuming that the
         | language is a bottleneck instead of the I/O or database design.
         | 
         | Mind you, I understand it given some of the PHP I've seen. But
         | again, that's not the language per se, but how it's used.
        
       | andoando wrote:
       | Man how do you even connect to a db with assembly code? Are there
       | assembly libraries?
       | 
       | In theory I understand it but the monumental amount of effort it
       | would take to write such "simple" things would take so much time
        
         | nneonneo wrote:
         | It says that the DB is SQLite, so I presume they're just
         | linking to the SQLite libraries.
        
         | atdt wrote:
         | It's less complicated than you might think. You call into
         | SQLite C library functions using C calling conventions. Here's
         | the relevant code:
         | https://asm32.info/fossil/asmbb/file?name=source/sqlite3.asm...
        
           | andoando wrote:
           | How about for setting up a server and serving http requests /
           | establishing web sockets?
           | 
           | If it's just a bunch of calling C code then I have to ask
           | which part of this is actually assembly
        
             | wavemode wrote:
             | To be fair, from that perspective every backend web
             | application in every language is really just "calling C
             | code".
        
               | eterm wrote:
               | That's overly simplistic and untrue. If you write a C# /
               | .Net program you're not "just calling C code", you're not
               | calling C at all.
        
             | wruza wrote:
             | You can ask the same about e.g. Pascal, Python and
             | Javascript, because all of them just make a bunch of C
             | calls at the end of the day and can't use NIC ports
             | directly.
        
         | pengaru wrote:
         | C is generally first compiled into assembly anyways.
         | 
         | When you program in assembly you're basically just doing the
         | job of the compiler, and can call all the same library
         | functions C code can. You just have to follow the calling
         | conventions of the architecture. It's cumbersome and tedious,
         | but nowhere near impossible.
         | 
         | x64 made calling functions more annoying by using registers
         | then spilling over into the stack after exhausting those. x32
         | was more pleasant by far, since it _only_ used the stack. x64
         | 's convention produces faster code though, by keeping stuff in
         | registers.
        
           | nineteen999 wrote:
           | > x32 was more pleasant by far, since it only used the stack
           | 
           | Maybe I misunderstand you, but this is completely dependent
           | on compiler, operating system etc, there are multiple calling
           | conventions for x86-32, eg. cdecl, fastcall ...
           | 
           | https://en.wikipedia.org/wiki/X86_calling_conventions
        
           | kristianp wrote:
           | > C is generally first compiled into assembly anyways.
           | 
           | I don't think that's right. C is compiled into an
           | intermediate representation first. It's true that you can ask
           | GCC etc. to generate assembly output, but it's not the
           | default.
        
       | CharlesW wrote:
       | I wonder if this is a practical project to distribute as an APE:
       | https://justine.lol/ape.html
        
       | true_pk wrote:
       | In the header, there's a button to disable live notifications.
       | 
       | On a side note, showing a list of forum users to someone who
       | isn't logged in is probably a bad idea. Is it something
       | configurable?
        
       | jansommer wrote:
       | Processing time is insanely fast according to the footer. But the
       | time it takes to transfer the document to Denmark is 500 -
       | 1000ms. Seems like a CDN is better than performant code in this
       | case... Still an impressive feat.
        
         | Morthor wrote:
         | I'm in the Azores islands, in the middle of the Atlantic Ocean,
         | and it loaded in under 500ms.
        
           | ugjka wrote:
           | Latvia here, 256ms according to FF
        
         | Karrot_Kream wrote:
         | Coming from leading response time initiatives at a Big Tech,
         | ouch. 1s is painful. Obviously transit time is a big part of
         | that but if that's considered "good", well oof.
        
       | pengaru wrote:
       | Despite being someone who wrote x86 assembly for years on DOS in
       | the 90s before learning C (and even continued in at&t syntax on
       | Linux for some time), I find this to be a silly exercise in time
       | wasting beyond its academic and comedic/entertainment value.
        
         | otachack wrote:
         | "silly exercise in time wasting beyond its academic and
         | comedic/entertainment value"
         | 
         | I love this as it expresses how I feel about JavaScript :P
        
       | tasn wrote:
       | This is super cool, though I very much doubt the following
       | statement:
       | 
       | > AsmBB is very secure web application, because of the internal
       | design and the reduced dependencies.
       | 
       | There's a lot of value in using well tested dependencies, and
       | even Chuck Norris will have bugs writing complex software in
       | assembly. Especially when doing string manipulation which this
       | project should be doing a lot of.
        
         | abestic9 wrote:
         | I was rubbed the wrong way with that line too, such claims
         | usually set off red flags, but the OP appears to not write
         | English natively so they might have legitimately missed out
         | some tempering.
         | 
         | e.g. "AsmBB focuses on security in its design and reduced
         | reliance on dependencies."
        
         | mgaunard wrote:
         | I disagree; dependencies are more of a liability than anything
         | else.
        
           | tasn wrote:
           | I can see this maybe being true in a high level language
           | (depending on the dependency), though it's definitely not the
           | case with assembly.
           | 
           | OpenSSL, for example, was hit with quite a few serious bugs
           | over the years, and I'd still choose using it than my own SSL
           | implementation. Especially in assembly.
        
         | layer8 wrote:
         | > even Chuck Norris will have bugs writing complex software in
         | assembly.
         | 
         | Surely you mean CPUs will have bugs executing Chuck Norris'
         | impeccable assembly code.
        
       | ChuckMcM wrote:
       | I like this, and kudos for going for assembly language. It is
       | certainly true that reducing dependencies reduces the attack
       | surface for something, that does not, in and of itself, make it
       | "secure". But yes, in a probabilistic sort of way it reduces the
       | chances of exploits. Of course assembly language has zero memory
       | safety or other guarantees which probabilistically increases
       | risk. I can't say if I think they balance out one way or the
       | other. Still, I love me some assembly language applications. For
       | extra credit transpile it to aarch64 and then you can run it on a
       | Pi-Zero (or Pi-W) in a wall wart :-).
       | 
       | I have been researching, off and on, _distributed_ forums. As
       | forums like the one created here became the  "go to" after Usenet
       | fell out of favor I have thought a replacement would have both
       | the distribution/replication features of Usenet and the user
       | experience of phpBB (the grandparent of most forum software).
       | 
       | Making it distributed, and eventually consistent, is an excellent
       | distributed systems challenge. So it is kind of like relaxing to
       | a puzzle. If you, gentle reader, have written something along
       | those lines I'd love to have a look.
        
         | 10000truths wrote:
         | > Of course assembly language has zero memory safety or other
         | guarantees which probabilistically increases risk. I can't say
         | if I think they balance out one way or the other.
         | 
         | I would posit that assembly + Linux kernel ABI is _safer_ than
         | the traditional C /C++ stack because they are not littered with
         | nearly as much "undefined behavior". Signed arithmetic
         | overflows and underflows as expected. Memory allocation with
         | mmap + MAP_ANONYMOUS initializes it to 0 as expected. Accessing
         | unmapped memory in your address space (including address 0)
         | triggers a SIGSEGV as expected. Your assembler makes much fewer
         | assumptions than your C compiler and doesn't try to be half as
         | clever, so it's more likely to crash and burn on error instead
         | of silently subverting your expectations.
        
           | mgaunard wrote:
           | This isn't a problem in practice because C++ developers are
           | expected to know the rules of their language and respect
           | them.
        
             | 0x0 wrote:
             | I think you meant "in theory" instead of "in practice" :)
        
       | David_FF wrote:
       | This is interesting. The forum looks nice and loads quick for me.
       | Great job
        
       | theturtle32 wrote:
       | Very cool project! The author is Russian and, tragically, seems
       | to have bought into Putin's pro-war propaganda lies hook, line,
       | and sinker. :'(
       | 
       | https://board.asm32.info/hi-johnfound-welcome-back.351/#1624...
        
       | kristianp wrote:
       | 79.7 kB transferred. It's nice to see minimal pages being
       | generated. Have to disable the notifications to see this result
       | though.
        
       | fasterik wrote:
       | You could do something similar in C and forgo the standard
       | library. No dependencies other than syscalls. I don't really see
       | a compelling reason to do it in assembly other than as an
       | intellectual exercise.
        
       ___________________________________________________________________
       (page generated 2024-01-13 23:00 UTC)