/meta/ - Board Meta

[Make a Post]
[X]






Nanonymous No.5701 (A)[D][U][F][S][L][A][C] >>5707 >>5709 >>5710
File: 0a9e2be914e65f309a9d41fcdb87fa03c2651b62360209630d233a3058776dc5.jpg (dl) (9.41 KiB)
What was the point of creating /b/ when this board is already dedicated to random topics? If it's based on thread quality that's a very subjective thing and in my opinion at least half if the threads on here belong to /b/. This just seems like an unnecessary website splitting.

Nanonymous No.5702 [D] >>5703 >>5707
ironically, your thread belongs on /b/

Nanonymous No.5703 [D]
>>5702
Ironically /b/ shouldn't exist nor should my thread.

Nanonymous No.5704 [D] >>5705
It's the difference between random and lounge boards, simple as.

Nanonymous No.5705 [D] >>5708 >>5711
>>5704
What's the difference? Is porn thread a "quality" thread?

Nanonymous No.5706 [D]
fuck you

Nanonymous No.5707 [D] >>5710 >>5711
>>5702
Actually, on /meta/.

>>5701
I believe /l/ topics should be treated as seriously as any narrow-subject boards, like /g/ or /v/, providing discussion close to the topic. /b/ on the other hand, is for shitposting, though not exclusively, because of subjectivity issues and frankly because you can say some smart elaborate stuff even without restrictions of a narrow-subject board.
Maybe calling it "off-topic discussion" isn't quite correct, because this implies a discussion that would go off-topic, while I believe /l/ for a narrow-subject threads that do not have their own board, and maybe never will get one.
Other than that, I think rules enforcing has been rather lax because fuck if I know. I think there is actually no consensus within userbase on how to use the split. Everyone here is used to /b/ being the default board, but IIRC /b/ here was renamed to /l/ and another /b/ was created after a while. I, too, don't think that porn thread is "quality", but I think it's there because administration wants it there, mostly. Antipornfag spooked them too much.

Nanonymous No.5708 [D]
>>5705
While both boards had broad general topics, the distinction was basically throwaway, or "shit" posting.

If you had friends in your lounge you'd be fine with silly behavior and the odd ruse, but guests randomly yelling catch phrases, neologisms and the like would probably not be welcomed.

Nanonymous No.5709 [D]
>>5701
>What was the point of creating /b/ when this board is already dedicated to random topics?
Regardless of the point of splitting /b/, the reason it was split is because hakase was a stupid cocksucker.

Nyanonymous ## Global Volunteer No.5710 [D]
>>5701
>What was the point of creating /b/
Read >>>/meta/3253 to start.
I think hakase had his own motivations to do so, mainly personal stuff and the whole deal with /pol/ becoming /t/.
As for the reasons we kept it that way after the administration change:
First, to have more strict rules(also read >>>/l/10558) to ensure some kind of quality discussion and at the same time still having a place for people to shitpost about whatever they want.
Second, to keep the overboard clean from shitposting threads.
Third, to have a place to put stuff that doesn't deserve to get deleted, but also doesn't deserve to stay on the topic boards or /l/, this will come handy in particular when thread moving will be a thing.

Also as >>5707 seems to understand, the lounge is not really an offtopic board but more like a anytopic board, this is why there is a rule against thread derailing(against offtopic), in theory /l/ should be a place where you can talk about a topic that doesn't have it's own board, you can also do the same on /b/ of course. As you noted it's not really a perfect system, there are some banter threads that doesn't have a specific topic also on /l/, for example >>>/l/12049 and defining a quality thread is difficult.

Nanonymous No.5711 [D]
>>5705
I was indifferent with it, the other mods never deleted it, and no one bothered to report the thread.
>>5707
>Maybe calling it "off-topic discussion" isn't quite correct
I agree, I didn't exactly like the description here when hakase first made /l/ too, but never thought to change it when I became the admin. I don't like the wording I used here at all though

Nanonymous No.5715 [D] >>5723
>deleted post containing asukafag's points on nanochan's downsides compared to picochan

>no index view
Already had a fully working version a month or so ago, I just haven't bothered with figuring out static generation for page 2 and beyond.
>no thread moving
You can talk when you're done with yours (jk, don't come back)
>captchas on recents/stats pages
Mods don't have to solve the captcha for recents, a tool made with only moderators in mind. There's no real need for the captcha in stats either.
>stmt:whatever() all over the place
You pawned off your code and website to the users of your community when you realized how much of a mess it was that you couldn't even get thread moving done easily, and you're calling me out for following the conventions of your shitty code to lessen my confusion my problem. Good one, hakase
I haven't really bothered with rushing tvols out for now because I thought you were gone for good, but I guess getting rid of you won't be that easy huh?

Nanonymous No.5717 [D]
So basically this it sounds like:

/l/ = Serious off-topic discussion only. Each reply should stick to the general subject of the OP.

/g/ = Discussion of or relating to technology only.

/pol/ =
Is: Containment zone for 8chan refugees and /pol/ culture.
Should be: Serious/good-faith News and Politics discussion.

/b/ = Not-so-serious off-topic discussion. Shitposting allowed.

/meta/ = Talking about NanoChan.

/a/ = Anime containment zone.

/v/ = Gaming containment zone.

/ar/ = Old stuff one person cared about.

/k/ = Dead & locked weapons board.

/o/ Dead and locked Automotive board.
See the /o/ thread on /l/ if you wish to have an automotive discussion.

45 LINES Nanonymous No.5719 [D] >>5723
-- 1. Fetch all contents of the thread.
-- 2. For each post of the thread, including the OP:
-- 1. Rewrite references in the post's comment using the old->new lookup table.
-- 2. Repost the post to the new board.
-- 3. Keep a lookup table of the old post number and the new post number.
-- 3. Delete the old thread.
function pico.post.movethread(board, number, newboard, reason)
if not pico.account.current
or pico.account.current["Board"] ~= nil then
return false, "Action not permitted";
elseif not dbb("SELECT TRUE FROM Posts WHERE Board = ? AND Number = ? AND Parent IS NULL", board, number) then
return false, "Post does not exist or is not a thread";
elseif not dbb("SELECT TRUE FROM Boards WHERE Name = ?", newboard) then
return false, "Destination board does not exist";
end

local thread_tbl = pico.post.thread(board, number);
local number_lut = {};
local newthread;

for i = 0, #thread_tbl do
local post_tbl = thread_tbl[i];
post_tbl["Comment"] = post_tbl["Comment"]:gsub(">>([0-9]+)", number_lut);
post_tbl["Parent"] = post_tbl["Parent"] and newthread or nil;

local files_tbl = pico.file.list(post_tbl["Board"], post_tbl["Number"]);
for i = 1, #files_tbl do
files_tbl[i] = files_tbl[i]["Name"];
end

local newnumber = pico.post.create(newboard, post_tbl["Parent"],
post_tbl["Name"], post_tbl["Email"],
post_tbl["Subject"], post_tbl["Comment"],
files_tbl, nil, nil, true);
number_lut[tostring(post_tbl["Number"])] = ">>" .. tostring(newnumber);

if i == 0 then
newthread = newnumber;
end
end

dbq("DELETE FROM Posts WHERE Board = ? AND Number = ?", board, number);
log(false, nil, "Moved thread /%s/%d to /%s/%d for reason: %s", board, number, newboard, newthread, reason);
return true, "Thread moved successfully";
end

Nanonymous No.5721 [D]
>look at all these sites using dynamic generation
These sites are more of a hybrid approach. They uses caches to maintain speed. Caching data is the same thing as static generation.

Nanonymous No.5723 [D]
>>5715
cont.
>A "working version" includes pages
Read faggot, pages are working fine, when I said static generation I meant creating a buffer of duplicate posts between pages such that I don't have to regenerate all the pages every time, or some other solution I haven't came up with yet.
>Leddit uses dynamic generation. 4chan uses dynamic generation. Faceberg and Twatter use dynamic generation.
They either use lazy generation, cloudflare or raw computing power to compensate for this, and they don't have some obsessed basement dweller waiting to spam their server with requests. You still haven't answered the question of whether picochan is still functional to regular users even when under abnormal load.
>100+ lines of code to do thread moving
The issue and difficulty with thread moving only applies to nanochan, because some dumbass decided to store formatted html strings in the database because (ad-lib of what you said in the global meta) "you shouldn't have to modify the contents at that point".
>Why is there a "recent" link in the toolbar if it's only for mods
Because like the post deletion logs, it might be of interest to some anons, and I plan on implementing lazy generation for it soon anyway.
>it's trivial to dos the whole thing just by accessing the stats page
That's your fucking problem hakase, but let's not talk about that. Almost every ib software out there stores the stats data in the db and regenerates them hourly. It's not even nanochan's (aka yours) fault that it's the case.
>You seem to have gone senile and confused me with hapase.
I'm about 97% sure you are hakase. Even if you aren't, it just means hapa women can't code.
>hapase's code was working just fine
Not really. Hakase did pawn it off after all.
>If you don't want to do your job
My >"job" is to maintain the servers of nanochan, not to maintain your crap code. Hakase never mentioned anything about maintaining the code in the >job description, nor was my proficency (which I had close to none) in the lua language ever questioned. I'm only doing this as a hobby, out of obligation/necessity and nothing more.
>>5719
See above. It's not the issue of thread moving but parsing the html code itself. I can't just :gsub away the formatting either because of the </span> tags being used, I might have to add another dependency (probably gumbo) just to parse the html. I might have called myself a hack in the picochan thread to get you riled up writing the thread moving feature just so I could get you to do my >job, but your code here is of barely any use to me. Oh well.

Nanonymous No.5724 [D]
>>5722
>use a huge kermongling of static HTML and pajeetscript to fetch dynamic data
They have nojs versions of their websites where they can't use such a method as well. The APIs are more for AJAX updating than for the initial page load.
>from a cached API
Seems like you've finally admitted that static generation is the way to go.
>No, those sites actually use a huge kermongling of static HTML and pajeetscript to fetch dynamic data from a cached API
Lazy generation with no javascript is easy. You could even get muh relative timestamps with it.
>the current system with one combined backend+frontend+database server
You can't be serious. You can't honestly believe storing certain lua functions in a separate file means your backend and frontend are now separated.

Nanonymous No.5726 [D]
I also forgot to mention that I changed the file hash function from sha256 to sha512 because it's faster for files above 4kb on 64-bit computers, which is the majority of cases these days.
A 4.4MB file takes 160ms with sha256 and only 50ms with sha512. This should have sped up posting times by some factor but I haven't measured yet so I don't know exactly how much.
SHA512 will become my new standard for imageboard file names due to a combination of its wide availability on every system that has sha256, its increased collision resistance, and its increased speed.
The SHA512 hash is twice as long as a SHA256 hash. As such, it has been truncated in the user interface to avoid unwieldy files, but remains in long form in the database and filesystem.

Nanonymous No.5728 [D]
>>5725
>speed wankery
The most expensive page takes upwards of 300ms. That's three requests per second. So when your server is say, under attack, and a user tries to view a thread (not even making a post here), they're blocked by the ridiculous queue of requests to the database that have been piled up by around a dozen haserl processes waiting for the db to be released. This is just a hypothetical, but you haven't shown any proof against it yet.
>people commented that posting felt much faster than on nanochan
Good for you. You seem really proud about that.
>Yeah you can. Why not?
Because </span> can both mean **, ==, <, > and more, and there's no way to do it without some recursive gsub fuckery that'd take more time than just installing an actual parser with luarocks for a one-time job.
>I really want to see your shitcode with getElementById() and selectDescriptor() just like in javascript.
I don't have that kind of autism, so I personally don't mind.
>Why are you not copying my code when I have already provided it to you for free?
Because the logic presented in your function is the exact same as what I already had in mind. The crucial part that's missing is the html parser. As for the other features, I just haven't got around to it yet.
>Many websites like jewtube don't display any content without js enabled
Youtube has a vested interest in spying on you. It used to be operable without js. Sites like facebook and twitter still retain basic functionality without js.
>Static generation is a failed experiment
Yeah. But lazy generation is not.
>How are you going to get relative timestamps?
You compute the timestamps upon page request by modifying the contents of the cached page itself.
>>deleting my posts and then replying to them anyway
My replies are only meant for you to see, so there's no point in leaving your posts up.

Nanonymous No.5747 [D] >>5748
>>5729
Cores aren't the limiting factor here,
>That "most expensive page" is a situation one would not encounter IRL.
Someone looking to dos your server wouldn't care about being realistic, they'd attack from the weakest point. One where a single request can do the most damage.
>Whenever I do something, I do it properly or I don't do it at all
Not sure if you've noticed, but most of my "features" are made either as bugfixes, moderator qol improvements, or dos prevention measures. Not vanity features, but tools out of necessity.
>I don't see any evidence that you're starting to speed up nanochan at all
That's because I haven't. Read, retard
>Sounds like a shitload of complex and buggy string processing and file handling code.
Not really, the file doesn't necessarily have to be in html, you know.
>is that you never implement your ideas
You're right, I'm just an ideas guy that likes spitballing. But you'll have the right to talk when your hapachan goes live and gets thoroughly tested by the same regimen nanochan underwent.
I'll fix the formatting later

Nanonymous No.5748 [D]
>>5747
>Cores aren't the limiting factor here
Actually ignore this, I have no idea how picochan actually works so I can't comment on that. But we're going in circles with dynamic generation and there's absolutely no reason for me to debate you on this, so whatever.

Nanonymous No.5750 [D] >>5754
Catalog and overboard generation times have now been slashed by a further 40% to around 90ms for catalog and 50ms for overboard. Index view is sitting at around 25ms which is mostly just lua/haserl overhead lol.
This is with a 75,000 post database this time. Number of posts in the database doesn't seem to affect much due to the use of indices and a proper schema.
I still have to optimize that pesky thumbnail displaying code, because a thread with 5000 images takes 400ms which is unacceptable for me.

Nanonymous No.5754 [D] >>5757
>>5750
>Catalog and overboard generation times have now been slashed by a further 40%
Diffcult to believe if you don't even say what you changed.
>inb4 do a diff look at the source
Got better stuff to do.

Nanonymous No.5757 [D] >>5758 >>5773
>>5754
Finding out the number of replies to a thread takes a relatively large amount of time. That replycounter in the catalog is displayed many times, and also once in the thread view. It is also used multiple times in index view to determine how many posts aren't in the window. On top of all that, it's used to determine whether some database triggers (the ones relating to cyclical threads and the bump limit) activate, so posting speed increases a little bit as well.
I simply stored that replycounter as a ReplyCount column in the Posts table, updating it when posts are added and deleted.
Hey, this modification is so simple that even YOU fucking wiggers are smart enough to do it. I bet you won't though. Lazy pigskin cumface.

Nanonymous No.5758 [D]
>>5757
I am also working on moving the entire codebase to LuaJIT, which should give another 10-20% speed gains especially where the html rendering code is used. Compilation overhead can be eliminated by precompiling source files in production, shaving off a constant 10-20ms from every page.
The roadmap past that point is a bit blurry but I want to rework the permissions system for mod actions into a form less prone to programmer error and security bugs. That should also remove 10-20 lines of duplicated code from the final product, which is good.
Then I want to get rid of haserl as a dependency, because haserl is very annoying to compile. Perhaps I will find an alternative, or switch to FastCGI + openbsd httpd. Or maybe I will just rewrite haserl in lua.
Picochan's future is bright, just like the hapa race :^)

Nanonymous No.5773 [D]
>>5757
I actually tried caching the replycount, but it barely improved the situation and just adds extra complexity. You're basically doing some form of caching here, and if you're going to do so, it should be done as part of a larger and more explicit caching initiative.
>moving the entire codebase to LuaJIT
Could theoretically be done with the github gist I posted and require53, but keep in mind the older haserl version needed for this is missing some "critical security patches" as mentioned in the changelog. I'm planning to use cgilua (fastcgi) or something else if I ever get to rewriting nanochan myself.