Penumbra Lynx - LynxChan front-end

Penumbra Lynx is a fork of DuneCoon`s branch of 8TailedLynx.

It has been the favourite LynxChan front-end for most people ever since it`s creation. and now I took it for maintenance.

Currently it supports all engine versions from 1.4 to 1.7.

I have not only fixed bugs and upgraded it to support newer versions of the engine but also organized the code, added version tags to the repository and cleaned the source code.

And some features were added too, like hiding and quick reply.

It`s repository can be found at gitgud.io/LynxChan/PenumbraLynx

Other urls found in this thread:

github.com/nextchan/infinity-next/pulse/monthly
developer.mozilla.org/en-US/docs/Web/API/Document/activeElement
twitter.com/SFWRedditVideos

hey here's a lynxchan frontend that looks just as good while using 999% less ram: /usr/bin/lynx

New board list.

Implemented youtube embedding.

Did you create a new thread because you were too embarassed to post in your old thread when you got called out.
This is a duplicate thread.

...

...

front end for a dead end

No, that thread is about LynxChan.
This one is about Penumbra Lynx.

By your logic, ubuntu threads would be duplicate threads if there was already a thread about linux.

Implemented thread watcher.

That is what I always wanted.
I'm not joking.

not bad

SHOWME WHAT YOUR PS2 LOOKS LIKE FAGGIT

Can you make a notification saying I watched the thread. I didn't even know there was a watch thread feature on Holla Forums until I posted on then /operate/

First, how a notification after you start watching a thread helps you notice the feature exists? You just used said feature, you don`t need to be told it exists.

Second, 8ch has a link with "Watch Thread" written on it, how come you didn`t notice?

Daily reminder this is in PenumbraLynx code, repeated over 100 times:
/
Also, Stephen's templating system just parses the HTML file, adds the relevant shit between tags and recreates an HTML file. This is slower than Infinity Next or, well, any imageboard software because it has to go through the entire page twice. Lynxchan's templating engine also does not have template inheritance and thus causes code duplication and possibly inconsistency across pages.

Not to mention, he hardcoded static file links, thus making any kind of separate media server impossible unless you fuck with the code.

he doesn't know how to benchmark with shared session and couldn't even read the mongodb docs, and the important notice about atomicity, before setting out to store files in it.
of course anything he implements will be subpar.
not to mention, at least Josh could get IP/CIDR addressing right.

and, of course, the sad part is if all the autists put their autistic differences aside and worked on one engine, contributing where their strengths really lie, you'd see something great. but of course this will never happen.

Way to ignore the engine design just so you could nitpick, champ.

Has anybody noticed this same psychopath troll that constantly tries to dismiss lynxchan with the absolute limit of his programming knowledge (read: practically none).

It's bizarre, lynxchan is just a free piece of software that has been given to us all as a gift. You can easily fix any problems in it you see because it's clean well written code with a good design and architecture.

Yet this maniac - who doesn't even understand basic HTML, let alone databases or web app programming - has dedicated months of his time creating extremely weak criticisms of it and trying to force them into becoming memes.

I never looked at the site that much honestly

Nice meme.

You mean the flawed engine using an abstracted filesystem on top of mongodb to serve threads?
It'd probably be faster to template a new mongodb document and version it than do what you're doing. Not even getting into atomicity.

Templating languages have inheritence, much like the C++ meme, dipshit.

lmao

Which is the very thing I didn't want to use.
So we get back at the point you ignore the engine's intended design.

k

lmao?

And it's why you are a fucking moron.
Intended to be slower at its primary function than Infinity Next with proper caching, when request cycle and dynamic templating of PHP are not as much a factor?

Again: lynxchan builds slower than Infinity Next.
As soon as Next is modified to have a URL to a captcha solving endpoint for no-js users, it blows your shit out of the water at templating threads.
This isn't even getting into the fact that Infinity Next was faster than Lynxchan at templating, on the fucking beta.

You are really fucking stupid. Josh was right, the fact that you couldn't get IP addressing storage and bans right was a signal that you are fucking incompetent.

"It's stylistically designed to be that way. You can't undo that." - Stephen "Sergio" Lynx

I find it funny you keep bringing infinity next like it haven't failed time after time after time.
In the meanwhile, none of the sites running lynxchan ever had any issues.

If next is so good, how come you don't run an instance of it?

it's a little but upsetting to me actually that you all are so stupid and ignorant

I wish there was a nice place with intelligent people to have discussions with

That's because the issues are covered up, and further covered up when Jeff exposed your incompetence at thread building.
I'd rather not have my career ruined thanks to child fuckers uploading their shit.
And I do run an instance, locally.

You've admitted that your shitware templates slower than Infinity Next templates and serves. That's all that anyone needs to know.

...

but i didn't say that

you're making up fake quotes

this is exactly the sort of thing i'm talking about

nobody is logical here, nobody is thinking. it's awful

You might as well have said it all.

Translation: It's stylistically designed to be that way and you can't undo that. But we can diminish the effects of it.
Translation: It's stylistically designed to be that way and you can't undo that. But we can diminish the effects of it.
Translation: Lynxchan is a magical collection of javascript slinkies with no blatant flaws, because it's open sauce. that's why you don't know what you're talking about.
Translation: You're just ignorant because you're not jumping on sergio's dick (despite the fact that it's pointed out what's technically wrong with these choices.)

At least you aren't defending his decisions made with IP addressing. No one could, really. Which is why you just wave your hands and declare that everyone else doesn't understand the "stylistic choices" that he made with his bowel movement.

so tell me about yourself? and why is it you are so against lynxchan?

I find it interesting the sheer amount of effort you have put into this over the last few months. I got the impression that you don't know programming, is that true?

Is not stylistic, I don`t want to use a templating language so templates can use pure HTML, making it simpler for FE devs to develop.

Why would I be against software?
I just call it as I see it.

Lynx has particularly annoyed me when he doesn't even know how to benchmark shit. He's shitposted fucking everywhere for a year about how his bowel movement is "faster than Infinity Next" while posting wrk or whatever benchmarks but it's not that simple.

By that measure shitposting on Holla Forums takes a sheer amount of effort.
No, not really. I see the thread, I see some shit talking in it, and I reply in kind.
Making sure everyone knows Lynx is a retard isn't hard.

By the way, this poster


Is not me. In fact, there seems to be several different people calling Lynx out for being a fucking retard.

You override the parent.
Have you ever used a fucking templating language? Any thing with inheritence?

Oh right, you haven't. Because you are fucking stupid.

Can you even read? Because you are talking about something completely unrelated?

Aw I thought it was just one completely insane lynx obsessed detractor.

No, it's exactly what we're talking about.

Well, you would think that if you hang on his dick all day and decide that it's your duty to respond to anybody calling out your brazillian waifu.

Implemented file hiding.

You should implement a better engine, next.

he is criticizing the design and architecture of Lynxchan, if you hadn't noticed.
this post is just an attack on his character rather than refuting his argument. try making an argument that refutes it?


there was an instance until librechan shut down and a bunch of pedos showed up on Nextchan. unfortunately it was on french hosting, which was free for the admin. he is still looking for a new host

What the fuck am I reading? That isn't how this works. You don't get new thread per skin. Nuke this thread


All the features you add to the front end won't matter because no JavaScript users won't get any of this shit.


You can't claim that InfinityNext is faster than Lynx at templating. It's just not even with all the varnish and ESI in the world.

By your logic, you can't make a centos thread if there is an ubuntu thread.


It will matter to all the other 90% of users with js. Since I already did everything I had that was independent of js, I am working on js features now.

Varnish doesn't fucking "template" in that scenario. The templating is cached, and ESI is parsed in the cached template, passed to the backend and passed back.

And yes, it fucking does. Literally, Next was templating faster, WITHOUT ANY DOCUMENT CACHE, than Lynxchan on the beta. It was building pages faster than Lynxchan does. Lynx himself has admitted this. Keep in mind, this was still with insane captcha generation load. Without the bullshit captcha, Next can build 40 pages/s per core. Lynx can only do 7.

I'll have to ask for some evidence to back up that claim.

Also, I bet if we took out all of the dynamic bits, like the "check if authenticated" that's presumably done in each post in the templates for moderators, and built a seperate moderation endpoint that inherits from the templates, and checked for further templating bottlenecks, it would completely wipe the floor with the brazillian's dogshit.

That's doable, and probably ""better"" from a document caching standpoint. And not much duplicated code because it'd inherit from the regular thread templates.
You'd still want to have ESI or bypass the cache when a user is logged in for any features like "passes" or what not.


Odili and Josh benchmarked it. You know, Odilitime, owner of Endchan. The exact benchmarks are lost in time at this point, but it's distinctly ~40 requests/second/core. So that's conservative, really, because it includes the request cycle.

nextchan was doing 8/core on the beta, if you count the 2007 HT "cores" as real cores, and this included captcha generations. so yeah, it has always built pages at a greater throughput than lynxchan.

and this isn't surprising, considering lynx does it the slowest way possible.
see

maybe you shouldn't hang on the word of a cripple who wanted to steal the copyright of another developer's work so he and his employer could close it up, despite promises made during the crowdfunding.
next always just had a few implementation details to hammer out, like the captcha.
just because jim didn't want to pay his pajeet-tier third world islanders to work on it unless he owned it outright, doesn't mean it was bad software.

If you ask me, it was 16chan shitting the bed and josh giving up on it that means next was bad software.

16chan shitting the bed probably due to
1) being hosted on a small cockli vps
2) captcha still not fixed, generating heavy load in response to traffic burst or simply someone crawling the site that didn't support cookies with their crawler (captcha load.)
3) no media caching
3) no document caching
it has nothing to do with the software being "bad" as a whole. there are good decisions, half-baked decisions, poor decisions and solutions not yet implemented.
take a look at lynxchan, if it was dynamically templated for everyone it'd be slower than next. instead, it uses document caching (in a retarded manner) but it's not even accurate to compare the two without careful measurements and comparing the exact same thing.

anyways, jim was willing to pay Josh a great salary if he'd give over rights to the software and close it up. and he wouldn't have his other employees work on it unless he owned it outright.

the cripple was trying to embarass josh into surrendering his copyright and closing the codebase up, and fucking all the crowdfunders over at a last-ditch "hail mary" attempt due to jim's stubbornness.

then jim's company goes and commits copyfraud months later with Everychan, by claiming that they held sole copyright after changing android namespaces+5 lines of real, copyrightable code.
definitely a shitty third-world outsourcing firm. this isn't even getting into the incompetence that led to everyone's details being leaked on 2channel.

k, josh

nice refutation of absolutely zero points in addition to pulling out a boogeyman

I have no interest in refuting autistic wall of text.

maybe you should've graduated high school , it's one paragraph and 3 bullet points at best.

It's a bunch of autism in the form of ramblings and excuses for a lying pedo thief.

I haven't made any excuses, I said that the software is not finished, and that in an attempt to finish the software hotwheels and jim decided it'd have to be closed source, while going and committing copyfraud months later.

I haven't seen any evidence that's not from the typical /cow/ autists that he's a pedo, and in fact has holocausted them and told them to fuck off on multiple occasions.
and he's not a thief, because he did the work until the money ran out. we're left with an AGPLv3 licensed imageboard that needs finished, which would've been closed up had josh decided to actually steal from donors and take back promises made during crowdfunding, by taking a salary from Jim.

k, josh

in fact, he probably did more work than what people paid him for.
he went above and beyond by fixing laravel's binary querying for Postgres, spent almost a month fixing all of that, just so Jim's autistic gook employee could use postgres for when the cripple died despite the fact that Jim hadn't paid a cent. meanwhile, Holla Forums still stuck on mysql.
did a few months worth of work on 16chan, too.
to say that he stole anything, when in fact the cripple and jim were the one attempting to steal, is just laughable.

FRIENDLY REMINDER:
Lynxchan has MORE instances then INFINITELY FAILED

friendly reminder that all of the criticism of lynxchan in this thread points to lynx being an incompetent hue.
can't even get IP addressing or templating correct.

I know it makes you feel good to completely ignore the fact that a developer was railroaded and had a two-faced imp attempt to embarass him into surrendering copyright, while fucking over donators in the process.

but whatever you say, stephen "seven page builds per second" lynx

That's cool and shit, but it doesn't change the fact next is dead and buried.

it was actively being worked on until the pedophiles killed an instance by reporting it to the provider after spamming it with hardcore CP, and will continue to be worked on.

Care to tell me why would they need a working instance to work on the engine?

github.com/nextchan/infinity-next/pulse/monthly

doesn't need to be, but it's nice to have a community to work for.

So you think fucking over No-JS users is acceptable?
NODEJS PRO

when most serious features/alternate queries require building yet another page because of your disasterous static page infrastructure you kind of have to rely on javascript.

i.e. expose all the information in a json api that you build and cache statically, along with rss and all of the other endpoints, and then refine the information via the json api.
kinda like this shithole.

whereas with dynamic you can have the best of both worlds when you need it, without rebuilding the page each and every recache, thanks to querystrings.

You guys are the cutest retards I ever seen.

Imageboard developer here. Anyone care to explain what are the advantages of generating static HTML/JSON on each update over dynamically constructing it on request + caching? I see almost every chan doing only the former.

Efficiency.
Serving the same page for multiple users multiple times is much faster than generating and serving the page for each user.

Also, its easier to apply caching this way, since you only have to deal with the document timestamp for it's last modification, instead of checking for the actual content shown on the page.

What I meant by on request + caching is:
1) Update happens. There are no requests, so nothing is generated.
2) User requests page
3) Server checks an increment-only counter (post number, rounded timestamp, etc.) to see, if a cached copy already exists
a) If yes, serve cached copy
b) If no, generate page, serve it to user and cache the page + counter

Additionally you can lock a mutex while generating a page, so a flood of requests to the same resource does not produce duplicate work.

As opposed to the fucking retard that has to build a new static page for alternate queries due to his terrible infrastructure?

Having the build the same page on each re-cache/action despite the fact that no one might be using it
lmao

so you admitted that you can only do 7 page builds per second per core, right?
at the conservative number of 5 posts per second across the site, your queue will start choking using anything that's not a fucking xeon.

because you're building all of the endpoints and index pages each and every time. your retarded build queue doesn't help if you have more than one popular board.

Yeah, that is exactly why I asked. Was wondering, if I was missing something or he was in fact retarded.

I have pages that may be updating 5-20 times per second under traffic, so opportunities to optimise are welcome.

Lynx' retarded solution to this is 'discard triggers'.
Basically, he uses a build queue and doesn't bother performing duplicate work for an arbitrary period of time, even though his build queue is going to choke because he can't even build pages fast enough.

That sounds terrible. Why do people still use static page generators for imageboards? I'd understand this for blogs and such, but not an active discussion medium.

Because they believe that an almost two decades old PHP script (Futaba) written by nips is the be-all and end-all to strive towards. Nevermind that no one does that sort of caching anymore, and it has very obvious drawbacks.

i think the big tragedy of lynxchan is that he could've taken *event loop meme* and made a great dynamic imageboard out of it. events dispatched to handlers which send notifications to clients (SSE) and dynamic building of pages/endpoints.
probably the one good nodejs imageboard is meguca but it doesn't even attempt to accomodate no-js.

I am the meguca dev. We switched to Go quite some time ago.

Concerning the no-JS userbase, I can technically render some HTML server-side, but what will you get? A bunch of finished posts and a bunch of half-finished posts, that you need to spam F5 to update. I could also introduce a fallback atomic post creation form, but it would be very jarring on a realtime imageboard for entire posts to suddenly appear, no? All in all, you simply can not have realtime posting with server-side rendering, just like you can not talk to the journalist about his article, by reading a news paper. It's a different medium entirely.

text/event-stream

i.e. use text/event-stream for real time, template and render posts server side that have reached a "committed state."

Obviously there's a point where you can't go back and edit/add to posts in real time, right? That's your committed state.

JS users would see the uncommitted posts, with real-time posting, no-js would recieve a templated page with only "committed" posts.

Yes, good. Now how do I consume text/event-stream without JS in most common browsers? Google gives me nothing.


The problem with that is committed state has a hard timeout of 30 minutes. Thread progression is asynchronous in regard to individual posts. This will introduce huge inconsistencies between people with JS and without. Now imagine how this will unfold with an active discussion, where some people don't see all the posts. It can be done, but it will not lead to anything usable.

And on another note, why do people in this day and age still disable Javascript?

You can't.

Ah, I see.
You could also reach a committed state in the UI itself when the post form itself has been unfocused, and after an arbitrary period of time.

That might lead to confusion for users who are used to how it previously worked, though, and may lead to unfinished posts when the window itself is unfocused?

That would cripple the ability to write long posts over a period of time. It is not uncommon to defocus the tab to, for example, grab that Youtube link you wanted to post. In either way, "committed state" implies that beyond some exceptions the post will not change anymore. To avoid confusing behavior this committed state should only be reached by explicit user interaction or exceptional circumstances, such as the post not closing for 30 minutes, which almost always means the user is no longer editing that post.

People disable javascript because it's a shit VM.
A lot of people are of the opinion here that if it can be done (within reason) without javascript, do it without javascript.
Pages should instead be "progressively enhanced."
Basic features like post backlinks, colored IDs, SFW/NSFW front page/board list, these can all be done server-side.

As for why people disable javascript, perhaps they just don't want to run a shitty sandbox.

Well, no. Apparently, (and I don't know JS) you can use activeElement.
Which is distinctly different from blurred/focused.
developer.mozilla.org/en-US/docs/Web/API/Document/activeElement

And, again, I don't mean to say the way you implemented your imageboard is shit:
I like meguca. I also like preserving user experience (or at least, a subset of it) when it comes to browsers or robots without javascript.

I see your point. Still there is an increasing number of web applications that can not be implemented without JavaScript. I guess they choose not to use them at all then.


It does not change that you can not read user intention through a property or an event. There is no sure way to tell "this post is done" aside from being closed by the user.

I never took that as you saying the implementation is shit.

And most of them have absolutely no need to do so, and can arguably be progressively enhanced. But instead they take shortcuts.
Yours arguably does, or it at least has some caveats in the way you want posting to work that make accomodating no-js a chore.


Yes, it's tricky. What I'd do is make it clear with a countdown (arbitrary period of time, 30 seconds or minutes) that the post would be "committed" after the text form is no longer the active element.

But it's different from how it was before.

Just some brainstorming.

I meant applications that have insurmountable technical limitations to being implemented without JS. Good look progressively enhancing something like agar.io.

That still does not change the fact that thread progress is asynchronous and a snapshot that does not update itself is useless and confusing from the user perspective. I've mused over this a lot. In the end you simply can not have both JS and non-JS users posting at the same time.

Well yeah, realistically they'd be replying to posts from 30 minutes or whatever the the arbitrary period of time the hard commit is.
I just think of it as a cache with a high TTL. It's not exactly ideal, but it does preserve some functionality.

So you mean not displaying any posts that are younger than 30 minutes?

jim's actions here were reasonable.

it was actually a pretty good deal for Josh.

Fucking the community over is not "a reasonable deal", especially when the community paid $12,000 in exchange for having access to the source code.

Pretty much, yeah. Whatever the commit time is. I'd set a boolean on each post that is committed instead of something like that, though.

Also, honestly, this was just brainstorming how you'd do progressive enhancement.
I wouldn't actually do this though, the choices you've made probably made your site unattractive to CP spam robots. wew.

bump for lynx' incompetence :^)

Long polling has existed for 2 decades without this, you tard

Long polling would be a clusterfuck, if it's even possible at all, in the case of multiple users typing up different posts on the page at the same time.

Okay, how do you consume a long polling stream without JS then?

bump