[ art / civ / cult / cyb / diy / drg / feels / layer / lit / λ / q / r / sci / sec / tech / w / zzz ] archive provided by lainchan.jp

lainchan archive - /λ/ - 18076



File: 1471637670861.png (927.68 KB, 300x188, serial-experiments-lain-reelgood.jpg)

No.18076

Hey lainons
I hopped onto the mumble server last night and jawed for a while with kalyx and some of the other admins, he seems like a pretty cool guy who doesn't afraid of anything

With all these changes to the board vichan is kinda fucking him over when it comes to moving the threads, some of them just aren't moving, which illuminates an important issue

This site's backend is absolute garbage

Which doesn't make a whole lot of sense when you think about it, we've got a programming board populated by a lot of really smart people, so knock off the soykaf and pitch in, you can do this.

I've cloned the lainchan repos already and I'm trying to learn php, I'm a really inexperienced programmer and I know nothing about web development, but this place is probably the best on the internet right now and I'll be damned if I won't support it somehow (because lord knows I don't have the money)

Stay awesome lambda, and I hope we see some more pull requests rolling in

>pic related is my reaction to the board software, it's bad, like really bad

  No.18078

>>18076
vichan is honestly unfixable.
There are a couple of replacement backends being developed, I think someone said rustchan is the closest to completion? You might want to just contribute to that one instead.

https://github.com/installgen2/rustchan

  No.18079

The people in #lainchan-dev on freenode are trying to fix bugs or do simple changes in the meantime. It's fairly uphill work but it's not bad for beginners particularly those looking to work as programmers. You don't have to worry that your code isn't good enough and being able to find your way around bad code will be useful if you're working in business.

  No.18080

>>18078
>vichan is honestly unfixable
Sad part is you might be right, but given that the replacement implementations are still quite a ways off we need some band-aid fixes so that the admins can at the least move threads without running into these really strange bugs

This is going to be fixed, the guys over in lainchan-dev are working on it right now, but we need more eyes

  No.18081

To help out anyone looking to pitch in, you'll need a webserver running on your machine so you can test out changes before trying to push them to lainchan propper, I can post a guide to get it running on different distros if anyone's interested

  No.18083

>>18081
General big-picture here, most webservers run on the LAMP application stack, which stands for
Linux
Apache
MySQL (or MariaDB these days)
PHP

So you have Linux, which runs Apache (the actual server part of the server) which runs MariaDB, (it's a database software like mysql)
and finally PHP, which is a weird one, to put it in layman's terms it's an extension to HTML that allows for really dynamic content, it interacts with the database to do things like store groups of text and pictures in threads, when you load the HTML for a thread like this one, it sends calls to the database in php, which tell it what goes in each of these boxes of text here

You get all of those up and running (it takes like ten minutes) and you can clone the lainchan board control software of of github, then just load it into the server and you have your own personal lainchan running on your computer, then you can edit the board software and actually help us fix some of this shit, vichan is terrible but we don't have a replacement yet, so sitting around waiting for rustchan to be finished just isn't gonna cut it I'm sorry to say

  No.18086

File: 1471653156648-0.png (260.91 KB, 200x113, Screenshot from 2016-08-19 19-31-43.png)

File: 1471653156648-1.png (118.88 KB, 200x113, Screenshot from 2016-08-19 19-31-51.png)

I can't get this to work lainons
Somebody wanna help a brother out?

  No.18087

>>18078
>redis as the persistent database
>installgen2
no surprise that a literal 14 year old would do this

  No.18093

File: 1471675957889.png (155.1 KB, 200x113, Screenshot from 2016-08-20 01-43-52.png)

In order to test changes you're gonna need a working implementation of lainchan setup on your machine, this took me hours because the installer is fucking broken

You're supposed to get LAMP up and running, then clone the files for lainchan into a directory within the server, in my case /var/www/html/ because Fedora

Then you open install.php in your web-browser which is directed toward localhost

Simple right?

WRONG MOTHERFUCKER

functions.php tries to load data from a file that is expected to exist, but if you're installing, doesn't, inc/instance-config.php which is an individual configuration file for your lainchan server which is ignored by github, so people can customize without fear of breaking everyone else's setup. if this file doesn't exist the installer will crash, and it doesn't exist because IT'S NOT IN THE GITHUB REPOSITORY, it can't be, or else github couldn't ignore it

So I changed the install script so that it checks for the existence of the file, and creates it if it's not there, avoiding the crash, if for some reason it can't create the file it prints a helpfull message and kills the install script, so as to not fuck anything up

Thank you to jove, could not have done this without his generosity and patience, he's the real mvp here

Anyway get LAMP, run install.php after my request gets approved and you will have a functioning install of lainchan to shitpost with all you want

I owe you guys, you made me a better programmer, and when I try to repay my debts, you go and make me an EVEN BETTER programmer, I really am privileged to be a part of this community and I hope you guys keep the fun rolling for years to come.

anyways get to patching lainons, lainchan, rustchan whatever, just make this board better, I'll see all you lovely darlings in the morning.

  No.18152

>>18083
Relevant info even for noobs even if you aren't on Arch.
https://wiki.archlinux.org/index.php/Apache_HTTP_Server

  No.18174

I tried a couple months back to get lainchan working in a docker container but it was too much of a pain to get it set up, so I gave up.

  No.18178

Long time lurker/memer.

Why doesn't lainchan use lynxchan? It just Works and is adaptable by a addon API and is split into Frontend and Backend.
The only downside is its Node based and uses mongo for its DB.

Sites that use it:
http://endchan.xyz
http://lynxhub.com
http://spacechan.xyz

  No.18181

>>18178
There are three staff members working on their own imageboard implementation.

It's considered best to use something that a staff member is intimately familiar with. Why move from vichan, which works just barely well enough, to something else that may have several issues, with less support?

  No.18182

>>18178
MongoDB seems a really odd choice for an imageboard database, given that there is an obvious relational schema for the data.

  No.18184

>>18182
Eh, its the devs choice. I prefer mysql but eh.

>>18181
Rolling your own isn't always a good solution and will leave holes open. At the top of my head there's like 3 complete chan engines in existance.

* Lynxchan (Customiseable as fuck)
* Infinitynext (Created as Infinity replacement)
* Vichan (a shit heap with no scaling)

I would go with Lynxchan since all he will have to do is write a frontend.

  No.18186

>>18181
>There are three staff members working on their own imageboard implementation.

Are they working on it in the open, if so where can I see the repo?

  No.18187

>>18178
hiya space ;)

  No.18191

>>18186
>Are they working on it in the open, if so where can I see the repo?
No.

  No.18234

Honest question here guys
I've heard the worst things about PHPHP, like, horror stories that keep me awake at night. Why do people keep using it?
I mean, it's not like javascript, where browsers support nothing but it and there's no choice. For what I know, CGI can be done with just about any language: perl, python, even C. And then there is also Rails.
Yet I see new projects surface every week made in PHP.
Now, is it true that PHP is such a bad language? if so, why do people keep using it for *new* stuff? Availability and popularity shouldn't be a reason when there are many other choices out there.
I honestly don't know shit about PHP, never tried it, only once I saw a sample and it looks a bit like perl... do people hate it for this then? Is it people's inability to adapt to slightly different syntax?
I'm really curious

  No.18235

>>18191
I believe he's talking about Rustchan
https://github.com/installgen2/rustchan
installgen2/shitbag/mika (all the same person) are working on that

I'm not sure what else we're working on

Me I'm maintaining lainchan, figure we should stick with what barely works like
>>18181
said

  No.18241

>>18235
I believe I saw someone else mention writing one in common lisp, I was just wondering if there were more.

  No.18242

>>18083
fyi lainchan runs on Linux, Nginx, MySQL, PHP and Docker. They also used to have it running on FreeBSD.

  No.18243

>>18178
the dev of lynxchan hates kalyx and also hates lainchan.

  No.18245


  No.18246

>>18241
Yes. I am.

Yuuko is working on an imageboard implementation in Go, as well.

I don't believe he's using a public repository.

  No.18247

File: 1472282333655.png (175.57 KB, 200x113, 20140729212823686.png)

>>18246
> Yuuko
> he
BTW, I know someone are writing board software though I don't know anything about it.
https://meguca.org/g/1756664

  No.18255

>>18243
Nah he doesn't.


>>18246
>Go
Does he also go by the name Zeke Roa? Because he's writing a chan called "Go chan".

  No.18278

If you search on github for imageboard software you'll find hundreds of "experimental" imageboards that people wrote and subsequently abandoned. There's probably twice as many that never even made it on the internet.
Writing an imageboard is really easy, but writing a good one that can handle a low/medium traffic community such as lainchan is another matter entirely.
The rustchan readme says:
>I like abstractions, they make things cool and better and stuff, I really don't know anything about programming let alone program design.
This imageboard's not going anywhere. You're never gonna use rustchan, nor any of your own personal imageboards that you aren't yet running on your server or whose source code you haven't yet released because they're not "ready for primetime".
You're still gonna use vichan because, despite being a huge hunk of shit, it's still the one that works the best and has the most features, and switching to another >PHP monolith such as lynxchan is too much of a pain and not worth the effort.
I'd like to see lainchan running on better software that I can actually contribute to as much as anybody else here, but I don't think it's gonna happen.

  No.18279

>>18278
Errata corrige:
lynxchan runs on node.js, not PHP, which makes its adoption even less likely.

  No.18282

>>18278
>I'd like to see lainchan running on better software that I can actually contribute to as much as anybody else here, but I don't think it's gonna happen.
It's probably happening, but it's not high priority, really.

  No.18285

>>18278
I agree, basic image/text boards are really easy to implement, heck I took an online class and one of the assignments was to create a text board in python. It will a lot of effort and time to have a replacement with enough features.

  No.18287

Have we considered 1 Chan?

It doesn't seem to be too bad.

https://github.com/jlbyrey/1chan

  No.18293

>>18287
All the documentation is in Russian.

  No.18294

>>18293

Google Translate?

I could translate the code as well if there are any russian parts...

  No.18296

>>18086
did you enable PHP in apache?

  No.18297

>>18234
>slightly different syntax
PHP does not have consistent function names.
Some will be Create_img() and another will be createImg() and they'll do roughly the same thing, but not quite. this can be really frustating.
Someone made an html preprocessor and they just kept adding shit to it. It is not a well-designed, engineered language. It's more an organic thing.

  No.18324

I can definitely make an image board using Python/Django. The only problem is I have so little time with my new job. I can definitely get the project started and write the main structure, but I would definitely need some help if we wanted to get it out this year.

  No.18325

>>18324
I'm learning python atm, and while I don't know enough yet to contribute in any significant way I'd love to look on. If you're going to be working on it in the open that is. I'd appreciate if you'd post the projects github. I'd love learn while watching the project develop, and help in any small way I can.

  No.18326

>>18325
Well, it's not started as of right now, but it wouldn't be difficult to get off the ground. I think I would make it completely FOSS. As in do whatever with it, don't even give me credit, I don't give a shit. I'm willing to start on it next week. Though, I feel like most people would hate on it because it's Python.

  No.18327

>>18234
PHP got immensely popular because it's easy. It's extremely easy to get a slightly dynamic web page up and running. People always like using something that is easy.
However, it is not easiness through simplicity and elegance, like Unix etc., it's easiness through hackiness, slopiness and ignorance. There are entire classes of errors and vulnerabilites that don't have to exist but they do because of PHP or other "easy" shortcuts in web APIs.
I refuse to contribute to any PHP projects no matter how much "better PHP is now"
I would be glad to make an imageboard but unfortunately I don't have time to invest myself into creating an imageboard and learning a dozen web frameworks. I'm starting college in less than a week.
I do think that it would be really neat if the lainchan community wrote its own chan software. That would really make this chan stick out, and if the programmers were good enough, I'm sure it would be a lot more maintainable than whatever software is currently being used.

  No.18328

I was wondering why the source isn't hosted on https://gitla.in Seems to be a much better place to host than github.

  No.18329

>>18326
I think Python is alright.

Personally I would prefer something like Haskell or a Lisp (at some placed called "meme languages") but I like Python, too. I think more important than the language used is the general architecture. Unfortunately I've got too little experience with web development. Therefore I may only help with the implementation.

Besides: http://www.wtfpl.net/ might be a nice license for you.

  No.18330

>>18329
I do web dev with python for a living, so I would have no problems with the project.
That license is awesome. I think I may use it. I don't really care if people use my work when it comes to things like this. If I build something that is extremely profitable, it may be a different story.

  No.18335

>>18327
>No PHP
I second that.
On the other hand it is reasonably easy to create an image board in $Lang if you ignore the front end and only concentrate on what algorithms and datastructures you will use to work with the posts and threads.
Once you are done it is trivially easy (if a bit tedious) to write a $Lang2Html interpreter or bridge that takes your software and maps it to its html/js/php whatever equivalent.

>>18329
CL would be sweet.
Imagine a chan package that can be patched and developed live through the repl. Add a nice test-then-autocomit tool and you could get 10 new microversions a day. Hell you could probably work with multiple developers on it at the same time.

>>18330
Careful with licenses. You might end up having to pay to be allowed to use your own project if you are unlucky. This is why I am such a fan of the GPLv3.

  No.18336

>>18335
>Careful with licenses. You might end up having to pay to be allowed to use your own project if you are unlucky. This is why I am such a fan of the GPLv3.

Hmm. If I license as completely FOSS, how could someone make me pay for using my own software? Maybe I license as FOSS and specify that any derivatives must also be FOSS?

  No.18337

>>18336
>If I license as completely FOSS

what do you mean by that?

  No.18338

>>18278
Which is precisely why I and so many other lainons are dedicated to fixing lainchan

  No.18341

>>18338
That's admirable, but my point is that vichan is such a mess that many potential contributors (such as myself) are turned off by its complexity and some things (such as the terrible html it emits) will never be fixed.

  No.18342

For a Python chan, there is the one floens did, µchan.

It's still in development but the basis is done and it works already. From how it's done it should scale pretty easily.

Link to hub: https://github.com/Floens/uchan
Link to demo: https://uchan.plebco.de/

  No.18343

How about Ur/Web? You have to be familiar with OCaml/SML and a bit of Haskell to get anything working, but it's amazingly fast and has some very cool features that make it safe.
Common Lisp would also be cool, and probably more feasible because of the amount of libraries and programmers available.
As for the license, how about public domain? The WTFPL is fun but it lacks the liability clause.
http://unlicense.org

  No.18344

I think the best license would be AGPL if you want it to always stay open.

  No.18345

Python/Django guy here. I'm ready to start writing code for this right now. Let's talk structure:

- Do we want nested posts(i.e. replies)?

- Do we keep js to a minimum or go full on async/ajax everything?

- Do we want to offer a public api?

- How does everyone feel about PostgreSQL?

- Do we care about having a few dependencies or do we want to roll everything from scratch?

Also, we should probably compile a list of wanted features.

  No.18346

>>18337
100% (F)ree (O)pen (S)ource (S)oftware.

  No.18349

>>18336
>Any derivatives must also be FOSS
Yeah that is basically GPL3 in a nutshell.
There used to be problems with companies taking FOSS code, doing cosmetic reworks, switching to a more restrictive license and then demanding licensing fees from other developers for infringing their IP.

This is why GPL3 was created.

>>18345
PostgreSQL sounds much better than the usual MySQL, the ammount of features Postres has is staggering.

  No.18354

>>18349
>Yeah that is basically GPL3 in a nutshell.
I'll have to take a close look at it.

>PostgreSQL sounds much better than the usual MySQL, the ammount of features Postres has is staggering.

I know. I've been using it for the new startup I'm working for. It's fast as hell in reads and does a good job mitigating race conditions. Also, starting with 9.4 you can use a json field which allows you to store a json document in a column! Who needs non-relational DBs when you when you have a relational DB with a non relational db built in?

  No.18358

>>18345
Nice. My personal preferences:

- No nested posts. Classical imageboard structure like this site. All posts are ordered by time.

- Since I block most scripts I would prefer minimal js. But some things are indeed comfortable like hovering over a post id and seeing its contents.

- A public API would be cool.

- I think I like PostgreSQL. Would have been my choice, too. (Even if I haven't used it extensively yet.)

- Doing everything from scratch would be a waste of time. It's nice if you want to learn something but not for actually getting things done.

But by the way, >>18278 got a point. Why start another project? Maybe it would be better to adapt something like above mentioned >>18342
The basics already exist and you can start implementing cool features and optimizations instead of starting from scratch again.

  No.18359

is there a telegram chat, IRC channel, or anything else outside of mumble that we can have a discussion and keep track of said discussion instead of this thread?

i'm also looking into helping with lainOS, and i wouldn't mind seeing if i can lend some of my knowledge fixing up what needs to be fixed. or even re-engineer completely.

  No.18360

GOD, YOU PEOPLE BROKE VICHAN AGAIN?
At least I got a minimal fraction of a bitcoin donation last time I did some work there.

  No.18361

>>18360
By the way, as >>18358 said, cut some of the js. Be as minimal as possible. On a slow connection I can see the board change colours, size, and it would be probnably twisting its head if it could. All of that well past the complete loading of the board.

  No.18362

>>18246
yeah, he said he wants it to be semifunctional before releasing the code
>>18247
yuuko's a he afaik
>>18359
you could probably make a telegram group and announce it in lainchan general, in the love chat and maybe in some other places, and it should work

also: lainos is probably something different from what you mean, there are some lainons working on a distro called laintoo.
LainOs does also exist, but it's a project that has been inactive since 2005 now iirc

  No.18364

>>18345
> Do we keep js to a minimum or go full on async/ajax everything?
Easiest way is assuming dollchan will work and leave it like KC.

> Do we want to offer a public api?

I prefer to use it. I'm an author of CatChan.

  No.18365

>>18345
>- Do we want nested posts(i.e. replies)?
No. Traditional IB is fine.

>- Do we keep js to a minimum or go full on async/ajax everything?

If it works without JS, that's a plus.

>- Do we want to offer a public api?

Not very important (web scrapping, etc.)

>- How does everyone feel about PostgreSQL?

MariaDB is a little bit faster, and most web developers are more familiar with it, IMHO.

>- Do we care about having a few dependencies or do we want to roll everything from scratch?

Use as many dependencies as you want. We can replace anything we want in the future if it is needed.

>Also, we should probably compile a list of wanted features.

My priorities:
A) Fast and reliable. This overrides everything else.
B) As little JS as possible. It should work reasonably well without JS.
C) Simple design, easily readable in small devices and text based browsers.

As a IB user, the features I'd like to see are:
A) (You), as in 8chan.
B) Select a text and click on the ID of the post to quote the selected text, as in 8chan.
C) List of responses of a post.
D) Embed images, webms and youtube videos. I'd like to be able to embed multiple of each.
E) Latest posts (as in "mega" here in Lainchan)

  No.18366

So, being the dedicated /λ/ moderator, I feel inclined to point out that I'm working on the Common Lisp effort.
The effort is gratis, so I'm not particularly inclined to make it a high priority, but work is steady.

A particular feature I desire that would be visible to users is multiple APIs. Using HTML or JSON is terrible. Communicating with a website shouldn't require complicated parsing nor a type system. This had me devising a numerical record API so a machine code or Forth could more easily be used to develop a Lainchan client.

An S-expression API arises rather naturally as a result of the language used.

The license will be AGPLv3.

The posting API will be regular across interfaces. A simple HTTP POST to the correct file will be all. Flags will include a legacy flag that will default to false if not passed. This will enable the ``>>'', ``>>//'', ``[spoiler][/spoiler]'', and ``[code][/code]'' syntaxes.

I'm not fond of in-band controlling, particularly in communications protocols, so a client should be able to specify ranges of characters within a comment to be spoilered, codified, or linked. This would simplify parsing posts in the S-expression and numerical record APIs significantly and will also allow for multiple means to enter formatting, which will decrease mistakes. Imagine being able to highlight a range to spoiler it, rather than using an ugly syntax. This is slightly more work for the server, but that's of no issue. This also allows for the user to choose a syntax for such.

Staff-visible features include deeper introspection of posts, so that more moderation is automated.

  No.18376

>>18366
I dont get how formatting of things like [spoiler] would tax the server more.
As I understand it now, the post would be saved as more or less plaintext, including those tags, on the server and delivered as html document (which is plaintext) to the users browser.
Only there would it be formatted with CSS or js.
So if anything, fancy tags put more stress on the browser than the server.

  No.18380

>>18358
>>18365
BTW, why do you hate JavaScript so much? Is that a security matter and you don't want to run scripts without your inspection, I found another way to get it. NoScript blocks js from sites, but not blocks user scripts in GreaseMonkey, so you can get full features without downloading site's scripts. I tried this with my CatChan script, but I think the dollchan as well.

  No.18401


  No.18402

What about Orphereus engine?

  No.18403

>>18366
I think that CL would be the most appropriate language, most of all because of the culture of the site (specifically this board).
While a very generic API would certainly be powerful, you have to remember than 99% of the traffic to the imageboard is going to be through HTTP, so remember to be pragmatic in your concerns.

  No.18404

File: 1472878267352.png (11.38 KB, 200x120, lainchan.png)


  No.18406

File: 1472888281775.png (236.1 KB, 200x104, tomislav-jagnjic-001.jpg)

Well, I'm happy to say I made a bit of progress on this today. Got the basic database schema defined and built out some basic templates.

I decided to go with bbcode for text formatting. Not too late to change if you guys think something else would be better.

Urls are going to look like this:
lainchan.org/programming/
programming board
lainchan.org/programming/1/
first thread on programming board
lainchan.org/programming/1/#115
post id 115 on the first thread on the programming board

Aiming for Support for the following file types:
jpg, png, gif, webm, mp3, pdf

Do we want support for multiple file uploads per post? It will be a bit more difficult, but I can make it happen.

Should have some more time to work on it tomorrow. I'll get a repo up for it then. What do you guys prefer to work with; github, bitbucket, or other?

  No.18407


>>18406
>I decided to go with bbcode for text formatting. Not too late to change if you guys think something else would be better.
Personally, I'd rather see markdown or something similar. On my imageboard I use ``` for code blocks and \\spoiler\\ for spoilers.

  No.18408

>>18406
Nice.

I personally prefer markdown like >>18407

Multiple pdfs is something I really like here, particularly since I am a bit obsessed with collecting books, so when anyone asks for a book about topic X I usually have 2-50.

What would be really nice, even if it opens up a security hole, would be to have a preview for the first page of the pdf/djvu/epub document instead of this lain placeholder like right now.
It opens up a security hole because to do that the server has to open the file. It should be manageable, it could be done by using a very simple pdf2png tool that runs with as little rights as possible in a dedicated directory on the server.

Github is something everyone knows, unfortunately they do have a political agenda which the pursue, so your files might be deleted from there a the drop of a hat. Might be smart to have Bitbucket as a backup repo, just in case.

  No.18409

>>18406
> What do you guys prefer to work with; github, bitbucket, or other?
I'm using GitHub but I was recommended to use GitGud(https://gitgud.io/users/sign_in) from people who was in gamergate side. He said gamergate was banned from GitHub, so they don't believe it. Lynxchan is hosting at GitGud.
However, I don't know GitHub's political stance, so this is not a recommendation, but just information.

  No.18410

>>18406
>>18408
>>18409
I recall someone posting a lain code hosting site, but I can't seem to find the url.

  No.18411

>>18376
Posts will be cached in each of the APIs, so there will be a verbatim and meta section for each post, along with the post's HTML, JSON, S-expression, and numerical form.
If the legacy flag is used, which would be defaulted to true in the website's posting form, the post would need to be processed to find the ranges. It would be a small amount of extra processing. Allowing formatting ranges to be specified would also require some verification, such as for post linking to contain numeric characters or a board name with numeric characters.

>>18403
>While a very generic API would certainly be powerful, you have to remember than 99% of the traffic to the imageboard is going to be through HTTP, so remember to be pragmatic in your concerns.
Yes. The most-commonly used APIs, HTML and JSON, should work mostly compatibly with vichan. The others are free to work in a manner actually being pleasant.

While I'm posting, I'll also ask why so many of you are using a database. I'm using the filesystem.

At the present, I intend for the structure to be fairly simple. Without going into much detail, threads, as an example, will be simple directories, with an OP file and then numbered response files. An imageboard is simple enough to allow a thread to be cached and added to by simple concatenation of a caching file, which is only invalidated upon post deletion or a public warning. The header, the caching file, and then the footer must then be dumped into the final file.

I may have been so vague as to make this difficult to understand, but I feel that the point was communicated well enough.

Another feature of an imageboard that is sorely lacking in the others is post protection. The intent is that the imageboard itself will be incapable of actually deleting files or causing other permanent damage. A program on the server would be run instead, to ``garbage collect'' the dead posts. This leaves four basic states for a post: deleted-by-user, deleted-by-staff, dead, and alive

I could go into more detail, but I suppose I'd be better suited by working on this again instead.

  No.18412

>>18411
>While I'm posting, I'll also ask why so many of you are using a database. I'm using the file system.

Because there isn't much difference in performance between a relational db and file system read/writes, a relational database has built in indexing and caching, and I'm more familiar with it.

The other benefit is that the database can be on one server and you can have multiple load balanced application servers connect to it.

You could do this with a file system data store as well, but I believe it would be much slower.

Also, if we want to have a useful site-wide search, it will be easier to implement with a relational db.

The database doesn't have to be something as heavy as postgresql either. We can use a hybrid like sqlite.

  No.18413

>>18411
>While I'm posting, I'll also ask why so many of you are using a database. I'm using the filesystem.
Performance? Ease of use? Transactions? Reliability? I think it's stupid not to use one.

  No.18415

>>18411
To expand on >>18413: if you see both the filesystem and the database as an API, the database is much more suited to this a job than a normal filesystem: if you use the filesystem you'll only end up reimplementing half of the functionality of a database with worse performance.
If you'd rather use a common lisp database there's lambdalite. Alas, it is designed not to scale, so it'd probably be better to use sqlite.

  No.18416

Why the hospitality towards databases? Use sqlite where you'd use fopen() and would implement a table-like structure yourself.

Not sure why you'd use sqllite when setting up a Postgres database isn't much extra effort and comes with a boatload of benefits.

  No.18418

>>18412
>>18413
>>18415
>>18416
I'm not particularly fond of SQL, which is complex enough to have injection vulnerabilities that I would find bothersome to prevent.

I'm also attempting to use few libraries. A filesystem interface is provided by standard Common Lisp. As it stands, I currently use an HTML-generation library, a thread library, and an implicit UNICODE library.

I simply don't see how an imageboard structure is complex enough to warrant a complicated database. As for searching, the ``raw'' textual content of a post will be in its own file, so even a simple tool such as grep would be sufficient for searching, even though a solution written in Common Lisp would probably both be preferable and efficient enough.

  No.18423

>>18418
You're being unreasonable. Like I said, if you don't use a database you're just doomed to reimplement half of its functionality poorly. A filesystem is just a poor man's database with one column.
Anyway, if you're that committed to having few dependencies what are you gonna do when you need thumbnails? Just send the whole image over, since imagemagick is too much bloat?

  No.18424

>>18410
https://github.com/lainchan/lainchan
You can find this at the bottom of thread.

  No.18425

>>18424
I am not talking about the lainchan github repo, I am talking about a code hosting website.

  No.18426

>>18411
> The intent is that the imageboard itself will be incapable of actually deleting files or causing other permanent damage.
I'm sorry too late, but this reminds the idea. Now you admins delete posts completely, or may be not, but we citizens can't see them at all anyway. This is an abuse of administrative power. You admin can delete ILLEGAL posts completely and immediately, but you must leave posts referable if you delete them by reasons of low quality, derailing or something from administration, because it is arguable sometimes, and we have a right to evaluate administrators. The easiest way is setting style.display = 'none'. Many systems adopt database, so they can compose as if the deleted posts weren't there from the beginning, this is bad. If you adopt simple file system, and if you want to leave them as a file, post deletion will be a matter because it sometime requires rewriting all the file since the post may be located at the head of the file. Then you can make a "dynamic" css for each thread, and name deleted posts in it to set style.display='none'. This can separate a large static html and a small dynamic css for good performance. Users can switch on/off the deleted posts easily. And also administrators can restore the deleted posts easily.

  No.18427

>>18424
He is talking about gitla.in

  No.18433

>>18423
>You're being unreasonable. Like I said, if you don't use a database you're just doomed to reimplement half of its functionality poorly. A filesystem is just a poor man's database with one column.
I'm not fond of filesystems, nor am I opposed to databases. I'm certainly not going to use an SQL database, however.
>Anyway, if you're that committed to having few dependencies what are you gonna do when you need thumbnails? Just send the whole image over, since imagemagick is too much bloat?
No. It's easy enough to write a function that can call an external program through the different interfaces different implementations provide. I'd dispatch to a command with this.

>>18426
>I'm sorry too late, but this reminds the idea. Now you admins delete posts completely, or may be not, but we citizens can't see them at all anyway. This is an abuse of administrative power. You admin can delete ILLEGAL posts completely and immediately, but you must leave posts referable if you delete them by reasons of low quality, derailing or something from administration, because it is arguable sometimes, and we have a right to evaluate administrators. The easiest way is setting style.display = 'none'. Many systems adopt database, so they can compose as if the deleted posts weren't there from the beginning, this is bad. If you adopt simple file system, and if you want to leave them as a file, post deletion will be a matter because it sometime requires rewriting all the file since the post may be located at the head of the file. Then you can make a "dynamic" css for each thread, and name deleted posts in it to set style.display='none'. This can separate a large static html and a small dynamic css for good performance. Users can switch on/off the deleted posts easily. And also administrators can restore the deleted posts easily.
I disagree.

  No.18434

>>18412
Django/Python guy back again. I haven't been able to work on the image board this weekend as I just deployed the beta of a new application and I was having trouble setting up the Email server.

Regardless, I'll probably have some time tomorrow to work on it and throw it up on bitbucket since that seems to be the preferred host.

  No.18445

>>18433
> I disagree.
Which aspects do you disagree? And what are you aiming for by your imageboard software?
Citing all my description is crazy. This is why we must evaluate administrators because your post is low quality definitely. If you cited only the points you disagree, we can easily understand your opinion and proceed to next step of discussion. But you didn't, so I need a redundant post to request an explanation. This is low quality discussion in kindergarden. I think admins must try to be high quality as long as you request us to be high quality.
And there are several imageboard software already. If you want to make another one, it's natural to think that you want to add new features which others don't have.

Again, which aspects, or all aspects, do you disagree? What are you aiming for?

  No.18446

>>18445
>Which aspects do you disagree?
I strongly disagree with the concept that administrative abuse of power is an issue here that must be prevented through the measures you've suggested.

>Citing all my description is crazy. This is why we must evaluate administrators because your post is low quality definitely. If you cited only the points you disagree, we can easily understand your opinion and proceed to next step of discussion.

I disagreed with the entirety of what you wrote, which is why I highlighted all of it.

>But you didn't, so I need a redundant post to request an explanation. This is low quality discussion in kindergarden. I think admins must try to be high quality as long as you request us to be high quality.

I do. You don't need to tell me this.

>And there are several imageboard software already. If you want to make another one, it's natural to think that you want to add new features which others don't have.

I'm not paying the other software, asides from vichan, any mind. I want a system that automates much more moderation and performs deep introspection on posts.

  No.18469

>>18446
> I do.
So, why aren't you a namefag?

There are some people who are writing imageboard software in this thread. Leaders or OP should be namefags/tripfags to get better efficiency in these thread. Too much namefag is a cancer, but too much anonfag like you is also a cancer. You should be "CommonLispMan".

CommonLispMan: CommonLisp, FileSystem instead of database, S-expressionAPI, aiming for autoban and deep introspection >>18366
Yuuko: Go
Django/Python guy: Python >>18345
OP: PHP?

From technical view, your suggestion is really stupid. You want an autoban system, but it doesn't require rewriting imageboard software at all, because autoban system is a bot on imageboard, not a imageboard software itself. And you want to inspect each post more to get better moderation, this requires database system inherently. For example, when you want to block multiple CPs from entire site, you must search it from all boards/threads. Database does this easily, but filesystem doesn't. As many stated, an imageboard software should adopt database as many did especially in case of focusing moderation.

So, I don't think you are trying to be high quality from both side of methodology of discussion and technical aspects on your post.

  No.18484

>>18469
I've already told you that I'm the dedicated /λ/ moderator.

>From technical view, your suggestion is really stupid. You want an autoban system, but it doesn't require rewriting imageboard software at all, because autoban system is a bot on imageboard, not a imageboard software itself.

I don't want an autobanning system. I want a system that will inspect posts for the staff.

>And you want to inspect each post more to get better moderation, this requires database system inherently. For example, when you want to block multiple CPs from entire site, you must search it from all boards/threads. Database does this easily, but filesystem doesn't. As many stated, an imageboard software should adopt database as many did especially in case of focusing moderation.

This isn't true. The intent is to queue each post after it's made and use a processing thread to run a variety of predicates on them and alert the staff when any of them return true.

>So, I don't think you are trying to be high quality from both side of methodology of discussion and technical aspects on your post.

I disagree. Regardless, I appreciate that we're both civil in this discussion. That in itself is relatively high quality.

  No.18496

>>18484
Just wanted to point out that functional programming often encourages non-standard solutions like this, and they yield awesome results. Check out Connel Elliots work on Functional Reactive Programming and videogames for some awesome examples of this.

I for one, think there's a bit of an argument for a light database here, or perhaps an in memory solution. At the very least a non standard ORM. The downside to keeping everything in memory is that when posts are gone, they are gone, and if the process crashes it's all gone.

On the other hand, the whole message queue and predicates thing can *totally* be done with an ORM of sorts on top of a traditional DB.

So my question for the /lamb/ moderator is how his inspection system would be smart, and superior to say, patching in a system that checks the posts against a bunch of regexes? The regex thing sounds like how I would implement it if I were being lazy.

/lamb/ moderator, do you have anything cooler? Natural Language Processing? Machine learning?

  No.18499

>>18359
Yeah there's an IRC channel
irc.freenode.net
Port: 6667
#lainchan-dev

  No.18500

File: 1473230075554.png (12.83 KB, 200x167, paradox_logical-300x250.jpg)

Wow this thread blew up...

Awesome, I love this site and will continue to help out however I can

I've already submitted two patches with Jove's help and intend to keep things up as long as I can, you guys are awesome keep it up!

  No.18501

>>18496
>Just wanted to point out that functional programming often encourages non-standard solutions like this, and they yield awesome results. Check out Connel Elliots work on Functional Reactive Programming and videogames for some awesome examples of this.
Feel free to provide a link you particularly enjoy. I've only read a small amount on this topic.

>I for one, think there's a bit of an argument for a light database here, or perhaps an in memory solution. At the very least a non standard ORM. The downside to keeping everything in memory is that when posts are gone, they are gone, and if the process crashes it's all gone.

That's precisely why I don't want to use an in-memory system. The Lainchan server loses power and is automatically restarted about once a month, from what I've gleamed from the server administrators.

>On the other hand, the whole message queue and predicates thing can *totally* be done with an ORM of sorts on top of a traditional DB.

The advantage of not using a database is reducing the nonstandard Common Lisp that will be used. I want as few dependencies on nonstandard features as reasonably possible.

I've not worked on this much lately, so the details are still vague. I should set a deadline for myself, say, in a week or so to have some specific parts of the system implemented.

>So my question for the /lamb/ moderator is how his inspection system would be smart, and superior to say, patching in a system that checks the posts against a bunch of regexes? The regex thing sounds like how I would implement it if I were being lazy.

I want to train the system on posts deemed bad. I want to build a system that will be able to detect marked words or patterns of words, even if they're modified.
So, a large database of word frequency, the words that follow them, and whatnot in posts deemed bad could be gradually built and later tested against.
It's difficult to tell precisely what I intend to do, because I've not done it yet. It would be nice to, say, flag posts that contain a large number of links relative to the rest of the comment, as a more introspective example.
Conceptually, there would be a human-reported queue, which we already have, and a machine-reported queue.

>/lamb/ moderator, do you have anything cooler? Natural Language Processing? Machine learning?

I suppose.

  No.18502

>>18501
Well, dependencies aside, unless lainchan has a baller hard drive on a super reliable file system (maybe ZFS?) I wouldn't trust persisting my web data to a flat file. Not to mention the security implications.

Any number of issues could arise due to concurrency, bit rot, race conditions, lack of transactional logic etc... you really want some kind of DB to store data in.

Now if you want to implement what is essentially ACID compliant data persistence in a Lispy fashion, I'm all ears to that. Sounds cool.

For what it's worth, I think you could keep it feeling lispy' by going with a nosql database or some sort. Without the SQL syntax you are free to write code that fits better with the functional ethos.

>So, a large database of word frequency, the words that follow them, and whatnot in posts deemed bad could be gradually built and later tested against.


If Lainchan went with this, how would you deal with the cawing over privacy? If you intend to train the system on real data, I feel it would be hard to avoid persisting people's posts indefinitely to train the machine.

Of course you haven't started yet, so you don't know, but I hope you keep that kind of worry in the front of your mind for this.

Link to FRP examples in Haskell:
https://wiki.haskell.org/Functional_Reactive_Programming

  No.18503

>>18502
>Well, dependencies aside, unless lainchan has a baller hard drive on a super reliable file system (maybe ZFS?) I wouldn't trust persisting my web data to a flat file. Not to mention the security implications.
I'm not certain which filesystem is being used.
I would think SQL is more prone to security issues than a filesystem. The web server simply wouldn't be allowed to access random files. What security implications are you considering?

>Any number of issues could arise due to concurrency, bit rot, race conditions, lack of transactional logic etc... you really want some kind of DB to store data in.

I've been discussing filesystem issues with the server administrators. The operating system configuration will bend to my program, not vice versa.
I'd be willing to add some conditional code to write a temporary file and then later rename it, however. Other small additions to the file-writing procedure would probably be fine.
An operating system configuration that creates copies of everything written may be used. I'm not certain.

>Now if you want to implement what is essentially ACID compliant data persistence in a Lispy fashion, I'm all ears to that. Sounds cool.

I don't particularly keep track of many of these acronyms. The very fact that one of the most-used operating systems in the world is this unreliable is in rather poor form.

>For what it's worth, I think you could keep it feeling lispy' by going with a nosql database or some sort. Without the SQL syntax you are free to write code that fits better with the functional ethos.

A database simply seems entirely too complicated for something this simple.

>>So, a large database of word frequency, the words that follow them, and whatnot in posts deemed bad could be gradually built and later tested against.

>If Lainchan went with this, how would you deal with the cawing over privacy? If you intend to train the system on real data, I feel it would be hard to avoid persisting people's posts indefinitely to train the machine.
We already make notes on IPs when they make bad posts. These notes generally contain the deleted post, but this is unstructured and would be annoying to sift through. I intend to automate it, by simply saving a post once it's marked as bad and then queuing it for consideration.
Privacy is entirely the responsibility of the individual. No one actually concerned with their privacy should trust us to maintain it for them. I believe we're trustworthy, but that shouldn't mean much to you.

>Of course you haven't started yet, so you don't know, but I hope you keep that kind of worry in the front of your mind for this.

I do.

The name of my attempt is ``Parallel Experiments Fileboard'', abbreviated as ``PEF''. I intend for it to be the ``automating, customizable, dynamic, and surveilling fileboard implementation''. That sounds rather cyberpunk and whatnot, doesn't it?

>Link to FRP examples in Haskell:

>https://wiki.haskell.org/Functional_Reactive_Programming
Thank you. I'll read this right now.

  No.18506

>>18484
No, I don't want to see your #mod tripcode. I do want each project leader to be namefags to avoid uncertainty, and all leaders other than you did this. For example, >>18406 was probably made by you, because it's uncertain that which project the post stated about from the post itself, since other project from Python/Django guy was running already.(>>18345) Some projects are running concurrently in this thread, so all posters must try to be clear that which project you are talking about.
However, according to inspection of each poster, >>18406 was estimated to be made by you as I stated, because others than you, "Space_!!neJOuDddBU" and "Python/Django" know this manner and they were tripfags/namefags or said their name in their post. (I prefer name field to be used, but some people don't read name field, so introducing themselves in each post is a way.) And also the post stated about file hierarchy. I think URL hierarchy is easy to be changed with database, so technical inspection also said >>18406 was yours. But these inspections are needless pains when you are namefag or state target project directly in the post.
BTW, #mod tripcode is too strong here. Making imageboard software is apart from that you are one of moderators. Some anon really have hostility to mods, so you don't have to show your #mod tripcode in these non-relational matters even if you are requested. And why you don't know these manners, which are that when you should be a namefag or when you must show a #mod tripcode, is because you are always using mod console where all posts have their IPs. Scheme is really simple. "Be anon as possible. Be namefag only if it goes well." As I stated, "CommonLispMan" is enough here. You'll realize this after you become to use always the same screen which we use. We just want to remove ambiguity, we don't want to know who you are or you are moderators or not.

However, you are one of mods and you can access to admins, the easiest way to build your software is,
1. Add 1 line to call your external program in Common Lisp into vichan suite. (Your program is called when every new post is made. See, http://php.net/manual/en/function.exec.php)
2. Test it.
3. Inspect how APIs you want.
(4. Request the APIs to Python/Django guy.)

Your program can be implemented as an external program. It's crazy to rewrite whole software to add just one Common Lisp subroutine. Call it from PHP. This way is independent from languages of board software, so you can use the same program without modifying from vichan(PHP), lynxchan(JavaScript), or Pyhon/Django guychan(Python)

>>18503
As for cyberpunk though I don't know the exact meaning, you should create a test board which is moderated ONLY by robot. If your program is successful, other boards or sites will adopt your AI algorithm and we human's freech will be under control of robot. Is this cyberpunk?

  No.18509

>>18506
>BTW, #mod tripcode is too strong here. Making imageboard software is apart from that you are one of moderators. Some anon really have hostility to mods, so you don't have to show your #mod tripcode in these non-relational matters even if you are requested.
I really don't care if someone doesn't like it.

>And why you don't know these manners, which are that when you should be a namefag or when you must show a #mod tripcode, is because you are always using mod console where all posts have their IPs. Scheme is really simple. "Be anon as possible. Be namefag only if it goes well." As I stated, "CommonLispMan" is enough here. You'll realize this after you become to use always the same screen which we use. We just want to remove ambiguity, we don't want to know who you are or you are moderators or not.

There's no pleasing you, is there? I'm certainly not doing that.

>However, you are one of mods and you can access to admins, the easiest way to build your software is,

>1. Add 1 line to call your external program in Common Lisp into vichan suite. (Your program is called when every new post is made. See, http://php.net/manual/en/function.exec.php)
>2. Test it.
>3. Inspect how APIs you want.
>(4. Request the APIs to Python/Django guy.)
>Your program can be implemented as an external program. It's crazy to rewrite whole software to add just one Common Lisp subroutine. Call it from PHP. This way is independent from languages of board software, so you can use the same program without modifying from vichan(PHP), lynxchan(JavaScript), or Pyhon/Django guychan(Python)
I've already tried replacing vichan gradually, but this was shot down because of interoperability issues the other staff didn't want to bother with.
The intent is to replace the entirety of vichan. I don't believe you understand how bad it is. There's not even a mechanism to automatically notify staff when reports are made. We use a bot that reads the HTML of the report queue, parses it, and alerts us with that. It's terrible.

  No.18513

>>18503

>I've been discussing filesystem issues with the server administrators. The operating system configuration will bend to my program, not vice versa


In programming it's tough to distinguish ambitious design from re-inventing the wheel. Based on your description, I don't think you understand the problems databases were invented to solve. Unless you plan on inventing your own file system, and running it on your own OS, then these problems will not be counteracted by any amount of configuration.

Sadly, there's no "--NO-RACE-CONDITION" flag in the Linux Kernel.

Transactions are not trivial to implement, and without them you cannot gaurantee data integrity. How do you plan on implementing your own transaction system?

How will your system deal with concurrency and data races?

How will your system scale?

How does you system manage I/O usage?

How will your system implement scaling to multiple database servers?

How will your system implement back up?

>I don't particularly keep track of many of these acronyms. The very fact that one of the most-used operating systems in the world is this unreliable is in rather poor form.


Atomicity, Consistency, Isolation, Durability. These are *crucial* to having a database that wont munch your data. File system operations using the bare syscall interface are not inherently Atomic, for instance. I'm not against your plan to re-implement Databases in a micro-lispy way but you need to understand the concurrency assumptions of the file system you are working on.

>A database simply seems entirely too complicated for something this simple


Not really. Not compared to what you'd have to do to implement the file system based method correctly. If you're worried about complexity, try sqllite. It's small enough that you could read all the source code in a few days.

Also keep in mind that this is *exactly* the sort of thing lisp performs poorly with, in the speed sense of the word performance. There's a reason databases tend to be in C, or Java.

Oh and that reminds me! There is a huge IO issue with using the File system as a database. Every time you write a file to the Filesystem you have to make a trip to the kernel / filesystem / and back. In CPU time this is YEARS. You have to invent a nifty threading system to get around this (hard!) or find a way to "spool" the data to disk without constantly making syscalls. Calling file() or whatever for every single post would be a performance disaster if Lainchan ever got popular (although you'd be right to say it's likely fast *enough* for the user base now.)

Modern databases have all manner of tricks to avoid this problem. I/O is a BIG DEAL for data persistence.

Anyway I'm not trying to shoot down your ideas, I just want to hear more about how you plan on getting around all these issues.

  No.18515

>>18513
>In programming it's tough to distinguish ambitious design from re-inventing the wheel. Based on your description, I don't think you understand the problems databases were invented to solve. Unless you plan on inventing your own file system, and running it on your own OS, then these problems will not be counteracted by any amount of configuration.
>Sadly, there's no "--NO-RACE-CONDITION" flag in the Linux Kernel.
Race conditions and whatnot will need to be handled inside my program, of course, but I can require the filesystem use a configuration that guarantees proper ordering of operations and whatnot.

>Transactions are not trivial to implement, and without them you cannot gaurantee data integrity. How do you plan on implementing your own transaction system?

I intend to handle all of this in a single file-writing function. Common Lisp provides FINISH-OUTPUT, which attempts to force all output to its destination and returns after this. I'll inspect SBCL's implementation of this, but it will probably be sufficient. Some UNIX-conditional code could easily be added to write to a temporary file and then rename it, which is atomic in UNIX.

Similarly, I would refuse to use anything except for Common Lisp's standard RANDOM procedure in a program, even one that requires good random numbers for cryptography or some other such purpose. Some implementations provide a suitable RANDOM, so the dependency would be noted and any implementation without a suitable RANDOM would be as good as defective for this purpose.

>How will your system deal with concurrency and data races?

The threading library I use provides condition variables. Please be more specific and rephrase your question, if this is not a sufficient answer.

>How will your system scale?

>How will your system implement scaling to multiple database servers?
The system is only ever intended to run on what Lainchan actually uses. Anything else is secondary, but would also probably require no extra effort.

>How does you system manage I/O usage?

Rephrase this.

>How will your system implement back up?

Considering the filesystem is being used, tar and gzip would probably be sufficient.

>Atomicity, Consistency, Isolation, Durability. These are *crucial* to having a database that wont munch your data. File system operations using the bare syscall interface are not inherently Atomic, for instance. I'm not against your plan to re-implement Databases in a micro-lispy way but you need to understand the concurrency assumptions of the file system you are working on.

This is why the filesystem configuration is important. I'm also not interested in re-implementing a database in Common Lisp. I'm interested in making the system simpler.

>Not really. Not compared to what you'd have to do to implement the file system based method correctly. If you're worried about complexity, try sqllite. It's small enough that you could read all the source code in a few days.

I'd prefer to not infect a Common Lisp program with an FFI requirement. It's horribly annoying when I can't load a program because I don't have a correct UNIX library and my distribution also doesn't support it.

>Also keep in mind that this is *exactly* the sort of thing lisp performs poorly with, in the speed sense of the word performance. There's a reason databases tend to be in C, or Java.

>Oh and that reminds me! There is a huge IO issue with using the File system as a database. Every time you write a file to the Filesystem you have to make a trip to the kernel / filesystem / and back. In CPU time this is YEARS. You have to invent a nifty threading system to get around this (hard!) or find a way to "spool" the data to disk without constantly making syscalls. Calling file() or whatever for every single post would be a performance disaster if Lainchan ever got popular (although you'd be right to say it's likely fast *enough* for the user base now.)
You're correct, as I've already considered this. I keep track of Lainchan usage, sitewide, and there's only a post every five minutes or so, on average, at best, so speed really isn't a concern. The first priority is writing software that functions correctly. Efficiency is a secondary concern and may very will never be an issue.
It's rather strange to be so concerned with data safety, yet then be worried about the syncing of the filesystem often degrading performance. Correct functioning is easily more important than speed will ever be.

>Modern databases have all manner of tricks to avoid this problem. I/O is a BIG DEAL for data persistence.

Yes, so I'll be performing many I/O operations.

>Anyway I'm not trying to shoot down your ideas, I just want to hear more about how you plan on getting around all these issues.

Please read this and rephrase the questions I've asked you to and other. I'm very interested in your concerns. It's a good way to discover and correct issues in design.

  No.18516

And nothing on lainchan was fixed...

  No.18517

>>18516
I've got Lainchan installed locally, was going to fix the admin hash issue listed on github. Just kind of like, getting around to it lol.

  No.18522

>>18516
The first thing that needs fixing is the admin

  No.18536

>>18522
Hey bro, if you don't like how kalyx runs things you're free to run your own chan.

  No.18537

>>18516
shhhh just let everyone talk about their own board software thx.

  No.18538

>>18516
What are you saying, I checked yesterday 3 fixes as I could see. A reasonable pulse. Maybe I'll check the irc later and ask what needs to happen...

  No.18540

>>18522
He fixed it. >>>/q/11629

  No.18541

>>18087
hey, I was just too lazy to set up SQL, I made the database abstract and was hoping that xentest would replace it with postgres.

  No.18762

Are people still interested either helping maintain the existing lainchan board software or migrating to something else (whatever that something else is) ?

Did the python prototype end up on bitbucket ?

  No.18767

>>18762
Migrate to lynxchan tbh. I already wrote a migration script.

https://github.com/SpaceDustTeapot/infinity2lynx

  No.18770

>>18767
Excellent. I'll be switching to lynxchan as soon as possible.

  No.18771

Lynxchan is B A E

  No.18772

>>18770
Admin tripcode when?

  No.18773

>>18770
LynxChan has decent problems with IPv6 (why doesn't support Lainchan the current internet btw?) and critical timing issues. Those are so bad that the systems just assumes that every 404-page will be there soon and just refreshes them. I just played a bit with it and it just doesn't feels right. Btw it's written in JavaScript.. come on lains.

  No.18775

>>18773
cannot possibly be worse than vichan.

  No.18776

>>18773
> critical timing issues. Those are so bad that the systems just assumes that every 404-page will be there soon and just refreshes them.
Well this is easily disproven. Here is a page that 404s. it doesn't reload http://lynxhub.com/autism/res/999.html

> I just played a bit with it and it just doesn't feels right.

muh feels

>Btw it's written in JavaScript.. come on lains.

It's written in node.js which is extremely efficient compared to the other languages like ruby, python, php. vichan is written in PHP. Are you seriously defending PHP?

  No.18777

>>18776
>Well this is easily disproven. Here is a page that 404s.
Maybe this host has a modified 404-template or this issue is fixed in newer versions. If you take a look at let's say endchan you'll see it.

>extremely efficient compared to

Compared to slow languages.. gz. PHP has got a really improvement with version 7 btw. And if you're comparing node.js with Erlang, Rust or Haskell it seems slow like hell.

  No.18778

>>18776
>It's written in node.js which is extremely efficient compared to the other languages like ruby, python, php. vichan is written in PHP. Are you seriously defending PHP?
To me, that may as well be as if comparing someone with a limp to a paraplegic. An efficient compiled language would be better.
JavaScript is a language made somewhat efficient only because of the pains of thousands working towards that.

  No.18788

>>18778


>>18778 is being a bit of a dick, and is pulling the 'ol

>PHP


meme, but they are right about node.js being an efficient language. It's also probably the best candidate we're going to see for a new imageboard system that people can actually contribute to.

Any new endeavor in making imageboard software is going to need a lot of contributors, many of whom have a very baseline understanding of software architecture and little time on their hands. It's important to have it written in a widespread language to allow people to contribute without learning an entire new language. Anything like Rust or Go is pretty much eliminated immediately as a candidate. I would make the case that it should be one of the following languages:

node.js
python
PHP

All have a pretty high number of people writing usable code in them right now, and python and node are actually taught in a lot of CS programs.

However, PHP and Python both sort of lose out on the efficiency front, so node.js it is for the final crown. You should look into node, it's not JS really (at least not the way you've probably used JS before).

The issue I, and a lot of other people in this thread have with lynx is that it uses a mongo DB backend.... which doesn't make any sense. Mongo doesn't have any of the advantages of common knowledge, choosing it eschews a relational schema for seemingly no reason other than to be different for the sake of being different. Following the criteria for choosing the main web development language above the logical choice for a new imageboard software would be PostgreSQL.

  No.18789

>>18788
sorry, >>18776 is being the dick not >>18778

  No.18790

>>18788
>Any new endeavor in making imageboard software is going to need a lot of contributors, many of whom have a very baseline understanding of software architecture and little time on their hands. It's important to have it written in a widespread language to allow people to contribute without learning an entire new language.
What a depressing outlook.

Imageboard software doesn't need many contributors, as it's able to be simple. Furthermore, I would hope that better could be expected from Lainchan than the lowest common denominator in programming knowledge.

  No.18791

>>18770

Please don't impersonate me.

Lainchan isn't switching to a new image board platform without a feature comparison and consultation from the users of Lainchan at the very least.

The audit hasn't finished yet, but the two factions of development are those that are maintaining the existing platform (https://github.com/lainchan/lainchan), and those that are working on new platforms as a replacement.

I just wanted to know if any lainons were interested in either faction, and whether the new platform faction had any additional contenders other than three (Lisp, Go and Rust https://github.com/installgen2/rustchan) that are already in development.

  No.18794

>>18791
I would like to suggest additional independant (not my project) contender: https://github.com/ahushh/Monaba
Feature rich IB in Haskell, not dead, responsive (though I don't know about scaling)

  No.18798

>>18790
>the lowest common denominator in programming knowledge
wew never change /lam/, you pretentious glitterboys.

  No.18805

>>18790
Are you for real? Take a quick walk around this board, it's full of people that are just getting the very beginnings of programming down.

And even if that wasn't true, who has both the technical competence to learn a new language and start fixing bugs but also has the free time to do that?

  No.18808

>>18798
JavaScript, Python, and PHP were recommended on the basis that they arguably comprise a lowest common denominator of programming knowledge, so I don't see why my being more explicit is considered pretentious.
A bad language being used because ``other people know it'' is similar to the way viruses spread.

>>18805
>Are you for real? Take a quick walk around this board, it's full of people that are just getting the very beginnings of programming down.
Why would they be contributing to an imageboard in the first place? There's a wide variety of more appropriate projects for them.

>And even if that wasn't true, who has both the technical competence to learn a new language and start fixing bugs but also has the free time to do that?

I would imagine the set of that someone would heavily overlap with the set of someones having the spare time to talk about programming on a board such as this.

Regardless, you're very much overvaluing and overestimating community development. An imageboard shouldn't need more than one individual to write it. So, anything else would be an extra, not a necessity.

I'm not trying to be rude, but this is simply the way I'm seeing this situation.

  No.18809

>>18808
A bad language being used because ``other people know it'' is similar to the way viruses spread.

Are you calling JS Python and PHP all "bad" languages? That's exactly why you're getting accusations of elitism in here, you're conflating popular with bad.

>Why would they be contributing to an imageboard in the first place? There's a wide variety of more appropriate projects for them.


Wait, wasn't that my point? Right here >>18788

>Regardless, you're very much overvaluing and overestimating community development. An imageboard shouldn't need more than one individual to write it. So, anything else would be an extra, not a necessity.


If that's true, how come we haven't switched yet to something better finished by a single person? Or how come the lainchan source hasn't been fixed yet by the primarily one person who keeps submitting commits?

I honestly am not trying to be rude here either, although I did get kinda cranky earlier in this post, but the truth is that an imageboard is going to need a lot of low skilled or at least low time-commitment contributors.

Working on an imageboard is going to take up the timeslot that normally went towards POSTING on that imageboard for people, i.e. when they're dodging work or wasting time while only half paying attention. People will fix bugs during that time if it's a language they already know, not if the bug is in some language they've only heard of.

  No.18810

>>18809
>Are you calling JS Python and PHP all "bad" languages?
Yes. I also consider them to be almost the same language, ALGOL.
I'm not trying to degrade any users of these languages, but I've yet to see anything pleasant to read written in them. I do use a single Python tool for some tasks, though, so I'm not saying nothing valuable can be written in them.

>That's exactly why you're getting accusations of elitism in here, you're conflating popular with bad.

I don't think this because the languages are popular.

>Wait, wasn't that my point? Right here >>18788

That wasn't the impression I had from reading that.

>If that's true, how come we haven't switched yet to something better finished by a single person? Or how come the lainchan source hasn't been fixed yet by the primarily one person who keeps submitting commits?

I've not worked much on my implementation, because it's not a particularly pressing problem.
The Lainchan source hasn't been fixed primarily by one person because it's a mess comprised of PHP.

>I honestly am not trying to be rude here either, although I did get kinda cranky earlier in this post, but the truth is that an imageboard is going to need a lot of low skilled or at least low time-commitment contributors.

I'm glad that we're both interested in discussing this issue in a civil manner.
I believe low-skilled or low commitment contributions is how monsters such as vichan are born. Software shouldn't be released with issues that are solved by such.

>Working on an imageboard is going to take up the timeslot that normally went towards POSTING on that imageboard for people, i.e. when they're dodging work or wasting time while only half paying attention. People will fix bugs during that time if it's a language they already know, not if the bug is in some language they've only heard of.

Couldn't we agree that learning a new language would be fun to do? Besides, I genuinely doubt the next imageboard implementation used will be a monster in the same family as vichan, necessitating such help.

  No.18811

File: 1474267476522.png (2.93 MB, 150x200, sicp1.jpg)

>>18809
I can't speak for PHP, but what I know of JS is soykaf and Python is very soykaf.

  No.18814

>>18811
>>18810
I dont quite get the hate for Phython.
PHP and JS I can understand (though it is possible to write very elegant things like monads in JS, its just very very hard to do so).
Python however is really great as gluecode and for little scripts, like a more powerful version of Bash (or powershell for Windows users)

  No.18815

You must understand what there are two separate things: programming (thoughts) and programming languages (alphabets). If you can program, then it doesn't matter what you use to write down your code, it can be assembler or javascirpt. But if you can't "think" properly then knowing alphabet at expert level will just not help.

And there are a lot of people who knows several "alphabets" but don't know how to program. And this is like "ME CODEZ GOOD LOOK IN RUBY. THIS IS HOW RUBY GREAT THINK I". And all this people say things like:

Lets write everything in node.js! (using five thousand modules what bury all that nice things node can give)
Lets write in C! (and this will eventually turn to reimplementing apache server for five years)
Lets write in Haskel! (so when I quit no one will be able to continue)

It is OK when at WhatsApp they not just use Erlang to write their backend, but also extend Eralng itself for their needs. It is also OK to write imageboard in Lua for fun and education.

But if you want to help Lainchan, stick with PHP. But do it right and learn from others' mistakes.

  No.18819

>>18814
Being better than bash isn't a huge accomplishment. Python is bad because declarations are implicit, there's a hard distinction between statements and expressions, no encapsulation, and duck typing. The result is a buggy mess that requires testing to have any confidence in.

  No.18820

>>18815
The other huge problem is that people like >>18810 get to try and flex their nerd-boners by scoffing at anything people already use.

"PHP, Python, and JS are all just ALGOL" Is such a stupid reductionist thing to say it's mind boggling, but around /lam/ it's par for the course.

There is a reason the people around here and other forums that bitch and whine about popular languages don't actually produce anything, and the code that's actually used is written in something widespread.

If you really care about building an imageboard platform in whatever your desired language is, fuarrrking BUILD IT.

But you won't, and you'll just keep posting snark in threads about how your pet project is totally better, you just haven't had time to finish it. That's why we have countless half-finished versions of imageboard software in Rust, Haskell, Go, ruby, who cares, but only about 2 actually usable codebases.

  No.18821

File: 1474323054923.png (490 B, 93x45, hunchentoot.gif)

>>18820
>The other huge problem is that people like >>18810 get to try and flex their nerd-boners by scoffing at anything people already use.
Hardly. >>18810 was pointing out that picking a popular language won't lead to a bunch of contributions. The majority of development is always done by a small number of contributors or a minority of contributors.

>"PHP, Python, and JS are all just ALGOL" Is such a stupid reductionist thing to say it's mind boggling, but around /lam/ it's par for the course.

Yes, many people in /lam/ know enough languages to see how similar PHP, Python, and JS are.

>There is a reason the people around here and other forums that bitch and whine about popular languages don't actually produce anything, and the code that's actually used is written in something widespread.

This isn't true. The majority of programmers bitch and whine but don't actually produce anything. There's more programs in popular languages because they're more popular.

>If you really care about building an imageboard platform in whatever your desired language is, fuarrrking BUILD IT.

The ironing.

>But you won't, and you'll just keep posting snark in threads about how your pet project is totally better, you just haven't had time to finish it. That's why we have countless half-finished versions of imageboard software in Rust, Haskell, Go, ruby, who cares, but only about 2 actually usable codebases.

Typical blub programmer snark. The library or application you need isn't there, so the community is dead.

  No.18824

>>18821
yeah... not a lot of that parses. Other than more snark what are you trying to say?

  No.18825

>>18821
>Typical blub programmer snark.
Can you link some of your projects, please?

  No.18834

>>18824
>yeah... not a lot of that parses.
That's your own fault. Learn to read.

>>18825
This isn't about me. Large active projects for languages such as Haskell, Scheme, Common Lisp, Emacs Lisp, and ML exist. It doesn't matter what I've done. It doesn't matter that you expect to be spoon fed. They still exist.

  No.18837

>>18834
It doesn't parse not because of his reading comprehension, because you tried to break down everything in my post and smugly refute it line by line but none of it makes any sense.

>Yes, many people in /lam/ know enough languages to see how similar PHP, Python, and JS are.


Clearly not what I said

>This isn't true. The majority of programmers bitch and whine but don't actually produce anything. There's more programs in popular languages because they're more popular.


Not... something people were arguing about? confusing to be cranky about? Confusing as to... what you were even trying to say there?

> The library or application you need isn't there, so the community is dead.


A complete non-sequitur to the point about those languages, which was that everyone picks them up starts something ambitious, and then quits, so the popular large codebases in use end up being from the languages people don't geek out about.

>The ironing.


Literally only smugness, contributes a sum total of zero to the conversation, and doesn't even try to prove you're different as clear by not linking anything

  No.18840

>>18834
>I-I can't link anything, so I'll just meme "spoonfeeding" lol!
21 repos with >1000 stars isn't very active, kys

  No.18846

>>18078
It's written in Rust, the over engineered PL which started the enforcement of CoC in the programming communities. It's also not very spread, not many know Rust and would be able to contribute. Anything related to Rust should be considered harmful.

  No.18847

>>18810
>Yes. I also consider them to be almost the same language, ALGOL.

This is pure ignorance. Javascript is distinct from Algol in purpose, philosophy and reality.

  No.18849

>>18815
>Lets write in C! (and this will eventually turn to reimplementing apache server for five years)

https://kore.io/
https://balde.rgm.io/

  No.18859

>>18846
I will drop Rust after I have finished my current project. It has some good ideas for sure (burrow checking, the great type system, pattern matching) but overall it feels just like another bondage-and-discipline language.
Apart from this, I don't really want to be a part of a community that values inclusion over merit and code quality.
I will start getting into more C and Lisp (Owl Lisp to be exact) in the coming months.

  No.18891

>>18859
Owl Lisp is a scam. The language has no future.

  No.18892

>>18891
>Owl Lisp is a scam.
Can you elaborate a little more on this one? Or are you just here to spill the soykaf?

  No.18895

>>18892
"purely functional"
there stateful functions everywhere and no way to recognize them.

  No.18907

>>18767
yeah lets move to something that is barely even complete

  No.18908

please stop making imageboard software!

its harder to make than you think, i know we need something new and better that works but we don't need another failed attempt to make an imageboard

  No.19859

Well, I'm back from a lengthy coma

I got a job repairing PC's, I'm making four dollars an hour while trying to go to college and study programming in my spare time so I might be able to contribute something meaningful

I didn't think this thread would still be here, something drew me back, I guess the same thing that drew me in in the first place

>148 replies

Holy Chao... You magnificent people really made something out of this thread huh... keep it up
oh yeah one last question
>kalyx sold lainchan
Someone wanna explain this, please

  No.19861

>>19859
>>>/q/11628

Welcome back.

  No.19922

>>19861
Thank you.


I'm just going to bulk reply to some posts


>>18076
>>18078
>>18178
>>18181
>>18235
>>18278
>>18279
>>18282
>>18285
>>18287
>>18293
>>18294
>>18324
>>18325
>>18326
>>18327
I'm not going to trawl through the whole thread

This was never about replacing lainchan or arguing about which programming language a new implementation should run, the intent was to raise awareness of the communities ability to contribute to and improve upon the existing implementation.

I understand that many of you don't like php and the existing vichan base, but this thread was, is, will be, about working on the existing board software.

I'm not trying to be harsh, but please don't post if all you're going to say are things like
>lainchan is bad
Irrelevant, this thread is about making it better
>rustchan is bad
lainchan does not run on rustchan
>vichan is bad
We're trying to improve upon it
>php is bad
You got me there, but most people know this, and it doesn't contribute anything to a dialogue about writing php

I understand that you're trying to voice an opinion and somewhat contribute to the discussion, but these responses are off topic and many of them are just opinion based conjecture

I don't know if it's too late in the thread's lifecycle to change direction but please ensure all following replies are related to discussion of the existing lainchan implementation, and provide something constructive

I still love you lainons, and I know you're better than all this.

  No.19927

please don't ever use lynxchan, eww. Linux is gay and y'all should stop creating new board software. PHP is fine.

  No.19940

>>19927
>plesae don't even use lynxchan, eww.
So what exactly went down between lynxchan and lainchan that causes you to say that?

>Linux is gay

no u

I have to imagine you gravitate more towards bsd then?

  No.19941

>>19927
oh I forgot
>please ensure all following replies are related to discussion of the existing lainchan implementation, and provide something constructive

Peace Kalyx, enjoy all that lainchan money.
In all seriousness this board has changed my life and I owe you big, I'll get you back someday.

All that out of the way this post is pure soykaf, there's nothing constructive here

  No.19943

>>18278
>better software that I can actually contribute to

See this is kind of the problem, if the software was better it wouldn't need to be worked on nearly as much, and this thread wouldn't exist, if all of lambda pitched in for a month we could have this board bugfree with time to spare

>That would take a complete rewrite


I know, that's the point

  No.19944

>>19943
Lainon you replied to here.

That's just wishful thinking. Nobody likes working on others' code, and nobody likes writing PHP. Combine the two and you've got the ultimate dev repeller, AKA vichan.

>>That would take a complete rewrite

>I know, that's the point
Well then, call all your friends and start working on a replacement. Don't expect anybody to give a shit about it until it's in good shape.
I've seen a dozen people in the thread a few weeks ago claiming they were working on their own replacement, and boasting about how much progress they made. I don't see any progress or links to public repos right now, gee, I wonder what happened.

  No.19945

>>19944

>I've seen a dozen people in the thread a few weeks ago claiming they were working on their own replacement, and boasting about how much progress they made. I don't see any progress or links to public repos right now, gee, I wonder what happened.


>This was never about replacing lainchan or arguing about which programming language a new implementation should run, the intent was to raise awareness of the communities ability to contribute to and improve upon the existing implementation.


>this thread was, is, will be, about working on the existing board software.


>these responses are off topic and many of them are just opinion based conjecture


>please ensure all following replies are related to discussion of the existing lainchan implementation


Anyone working on an implementation of their own needs to take discussion of it to another thread, this one is about improving the board software that the site actually uses, so whatever happened is irrelevant but I think I can speculate.

They lost interest when lainchan didn't automatically switch over to their vastly superior implementation made by such vastly superior people, that or they got interested, started working on a new board as a learning project, learned what they wanted and stopped

Either way you and I both know that lainchanSoft isn't realistically going to see replacement so we have to work with what we've got, which is pretty bad, but it's a hell of a lot better than it was when I started this thread, entire swathes of the codebase have been rewritten, error handling actually works now and provides helpful debug info which was a HUGE milestone considering how hard the code was to debug before

It's still bad, but it's better, which is the point of this thread

>Don't expect anybody to give a shit about it until it's in good shape.


I can't speak for anyone else but personally I consider it a privilege to work with the existing devteam, they really are great people and it makes slaving over such terrible code actually fun, beyond that, like it or not this is the software that the board actually runs, improving it improves the site, which is enough reason for me and quite a few others.

I can understand being critical of the existing code, but half the posts in this thread, including yours I'm sorry to say are excuses for why someone doesn't want to work to improve it, you don't have to justify yourself if you don't have the time or interest, I mean, shit I don't have the skills required, but I'm kind of learning as I go, and I'm having a blast doing it.

The developers are trying to make lainchan greater than it already is, and anyone who wants to be a part of that is welcome, if you don't that's okay too, but please don't come into a thread that's supposed to be about the board software and post all the reasons why you don't want to put in the time, it's pointless and inhibits discussion on actual improvements, if nobody wants to pitch in and post about it here, just let the thread die, this endless complaining is starting to get on my nerves.

>I don't want to help and here's every reason why


Just don't bother posting if that's all you're going to say. Those of us who are actually working on the board software are going to continue doing so, we'd love to get it to a point where more people are comfortable helping out but to do that we need more manpower, make some compromises, swallow your pride and help. Don't just make excuses for why you don't want to.

  No.19954

>>19945
You're right, I might have misunderstood the point of this thread.
I wasn't really trying to say why I don't want to help with the current codebase though, rather I was trying to discourage people from just wasting effort writing their own only to abandon it after a couple weeks, because somebody might actually make it and lainchan could actually be replaced, though that's a pretty long shot.
I guess it's more realistic to contribute to the existing software though. I'm glad the codebase has improved and people are working on it, and I wish you all the best. Maybe I'll chip to improve the html-generating code, since that's my biggest gripe with the website for now.

  No.19959

>>19954
>Maybe I'll chip to improve the html-generating code, since that's my biggest gripe with the website for now.
You know I've never actually heard that addressed on the irc before, would be a worthy contribution especially considering I don't think anyone would raise that issue otherwise

My biggest issue with the software is the overt structure, everything's cobbled into a bunch of different files that call each other, with otherwise simplistic subsystems being spread across multiple objects in different directories, this is why the code is so difficult to read, it becomes a lot easier if you know what you're looking for however, as you can run a search for any time that function is called throughout the parent directory and work backwards from there.

If you do make any changes make sure to post them here, it's a lot easier to get a server running on your system now that somebody fixed the installer
>>18093
my first patch involved adding one if statement to the top of install.php, and I had a lot of help to write the thing from jove, but I'm a much better programmer because of what I learned here, besides I'm not kidding when I say the devs are great people

Looking forward to those pull requests

  No.19962

for those that want to talk about other imageboard projects then this is the thread for you >>19458

thank you OP for keeping this thread on the rails.

  No.19964

Around six months ago I was an avid lurker in /dpt/ on 4chan's /g/ board, I loved those threads and seeing people come and discuss their projects, I knew about lainchan, and I lurked here every once in a while but I seldom posted and when I did it didn't really contribute to any larger discussion, just piped in when I had a question or two.

One day I came across an old USB hard disk I'd had sitting in a box for a year or two, and on this disk was some backups from an old laptop I'd given away some time ago. I mounted the drive and on it was this monster

http://pastebin.com/0JhzNjb5

yeah....

It wasn't pretty by any stretch of the imagination, anyhow /g/ crucified me for it, some of the crulest, foulest, most toxic comments I'd ever seen directed toward something I'd actually worked pretty hard on hurt, quite a lot.

I thought they'd give me pointers and help me improve, nope

At that point I felt pretty crushed, but I remembered lainchan had a programming board some place called /λ/ so I decided to take it here.

Some of the nicest most helpful people on the planet helped me turn that burning dumpster fire into a decent script, and then gave me some tips on optimization to boot.

http://pastebin.com/UKgKryYG

So why do I wanna help this place so bad?
Why do I think it's important that lainchan actually run on a decent backend, even if the work is boring, difficult, and largely impossible for the end user to notice?

Because you guys are worth it that's why.

  No.19965

>>19962
hold the phone....
We actually have a thread for that?

Then why has everyone been posting here?

  No.19966

>>19965
this thread was first to the party.

  No.19967

>>19966
Yeah but there's posts arguing about lynxchan in here from after that thread was created

  No.19970

>>19967
you can lead a horse to water, but you can't make it drink? lol

  No.19971

>>19970
Fair enough

  No.19975

>>19962
>>19966
>>19970
Hey, out of curiosity why are you saging the thread?

I'm seeing a lot of that in here

  No.19982

>>19975
They probably didn't think the content of their posts was important enough to warrant a bump. Lots of people do that.

  No.19984

File: 1478409353132.png (83.64 KB, 200x151, anchor_detection.png)

>>19945
>>19954
OK, so do you have an issue? If you don't have, I request this.

Anchor detection of vichan is awful. See pic, vichan can't detect anchors without blank after that. This can't be fixed in client side because the anchor may refer a reply in other thread. So this must be fixed in server side.
I'm sorry, I have no knowledge about PHP, so I don't contribute directly, but I'll check if it is fixed or not, and see the script if you tell the line. Probably you can fix it by fixing just a regular expression in the line.

  No.19987

>>19984
I know just about nothing when it comes to PHP or web development, and I'll be the first to admit that I have no idea what I'm doing, but I've got no problem with learning something new

So when you say anchors you mean the double '>' used when quoting a post right?

I'm not sure where that's handled, I'll probably start by tracking down the text input subsystem and then see where it's feeding to, I'll have to figure out if there's something being scanned on input, or in the database, either way it seems like it's only happening on a new line, taking a single > symbol as a greentext flag and >> for post number input

Interesting problem, thank you, I've been practically salivating for something to work on but I haven't been able to decide

  No.19988

>>19984
>>19987
>without blank after that
oh wait a minute, maybe I'm thinking about this wrong, it's parsing the string beginning at the >> character and is only breaking the parse when it encounters a ' ' character, so if it hit's something along the lines of >>19987 it should work correctly vs >>19987ttttttt version which should not, as it's looking for a post with the number "19987ttttttt" which doesn't exist

For this to work properly it should end the subroutine whenever it encounters a non-numeric character, I'm not sure if there's a function in php for this or if I'll just have it check against a list of 0-9 formatted as character strings, either way it should be much the same

Again to any actual programmers if that seems like a bunch of word-salad I'm sorry, I'm a self taught amateur and not a very good one

  No.19989

File: 1478419577011.png (132.73 KB, 200x188, terminated_by_a_period.png)

>>19987 > So when you say anchors you mean the double '>' used when quoting a post right? Yes. > oh wait a minute, maybe I'm thinking about this wrong It may be so. Nobody knows until someone finds the line. BTW, when it is terminated by a period, it works if its next letter is a newline, but it doesn't work with other letters. See pic. This is an odd behavior if the parser is implemented by a single regular expression, so the input may be parsed by for-loop. Regular expression search is slow usually, so server side people hate this, though I don't know the culture of PHP. Anyway, finding the line is a heavy work, but fixing the line is not so heavy. If you are a leaner and want to contribute something, this is suitable for you. Good luck!

  No.20011

>>19984
>>19989
Dude... what's with the pics?
polite sage

  No.20038

>>20011
What's wrong?

  No.20040

File: 1478527431430.png (191.61 KB, 200x102, 12191.png)

>>19987
>>19988
Sorry, the issue of >>19989 is fixed now. The posts was a search result, but it was too old. However, the issue of >>19984 isn't fixed now, so at least the kalyx knows the line, or he might leave some comments in repository. Pic related.

  No.20050

>>19959
Actually, I think that code has been cleaned up by somebody else already. The CSS is still a mess though.

  No.20085

>>20050
Last time I tried to learn a markup language I nearly shit a cat

It's so complex, yet you can do nothing with it, except convey and styleize existing data

  No.20087

>>20085
Honestly, it's not that bad. The problem is that it's very easy to make a big mess out of it, the language does you no favors if you don't know how to organize everything.

  No.20094

>>18536
he doesn't run lainchan anymore, tho.

  No.20107

I'd like to report possible bug if this correct thread.

is *>> not being recognized as * and >> expected feature?

  No.20178

>>20094
You just replied to a two month old post

When that was posted he DID run lainchan

  No.20253

File: 1479447879992.png (360.84 KB, 153x200, 1438216268853.png)

>>20094
>>20178
Damn race conditions.

  No.20328

File: 1479766802260.png (2.6 KB, 106x17, 2016-11-21-231937_106x17.png)

>>19927
>Linux is gay...

mhmmm....

  No.20330

>>19927
Ironic brewing soykaf is still brewing soykaf.

  No.20339

>>20085
CSS is pretty much unrefactorable without wanting to swallow a shotgun

The only option to make it better is to start over, or just use a framework like bootstrap or zurb, but you know how well that's going to go over with "muh bloat" fags.

  No.20381

>>20330
So "brewing soykaf" filters to "brewing soykaf" rather than "soykafposting"? Interesting...

  No.21928

>>18410

I too remember this. Can't find it in my history though. Anyone have a link?

  No.21929

>>21928
I think you are talking about https://gitla.in as mentioned in >>>/q/12673 .

  No.21930

>>21929

Yup! Thanks! This was it. I wonder if gitla.in is on gitla.in.

  No.22227

File: 1487770666678.png (3.87 KB, 167x200, lainsmall2.gif)

Back from the dead!

Hey guys, I've wanted to take a more active role in development for a long time now, hell I've wanted to take a more active role posting on the site for a long time now, but I've held off because coming back here made me feel bad that I hadn't been contributing, I didn't feel like I should make commits until I knew php really well, and I didn't feel like I should get to know php until I had learned a 'real language' like C, but I'll be entirely honest with you, I am bored to soykaf with C & C++. I like Python, I like Lisp, I like php (to a point)

I'm not going to get anywhere as a programmer if I have to drag myself to my keyboard, so I'll git gud at high level code I actually enjoy, before diving deeper, I'll have to eventually, but hopefully after having been exposed to more concepts that'll make the more archaic syntax easier to swallow, it's not that I don't understand it, it's just not as fun, and it's diffucult to focus on if I'm not making any real progress

Here's to lainchan!
See you lains on github

  No.22233

>>22227
I used to put unfair expectations on myself, but now I say that programming should be fun. I think you have the right attitude. Just hack on whatever you feel like, and eventually you'll find your way.

I'm agnostic to computer languages, they're tools that you can put on your toolbox. Lots of people are religious about it, "this language is better, etc." Python is awesome, C is awesome, PHP is awesome too.

  No.22235

>>22227
There is no such thing as a "real language".
There is, in my opinion, such a thing as a "real programmer", and it's a person who always strives to become better, without dismissing stuff just because it's not a "real language".
There is something to be gained by doing a bit of everything, even the stuff that you might find repulsive and unhelpful (PHP in my case, had to write it at work).
Just do what you think it's fun, and try to always learn new things.

  No.22250

>>18324
>>18325
I know a fair bit of python... I'd sort of like to learn how I could help the imageboard project... Any tips?

  No.22251

>>22250

The current imageboard software is written in PHP and JavaScript.

The main IRC bot for the Lainchan IRC server is based on Err (errbot.io) and hence is written in Python. Feel free to write any plugins for IRC that you think would be useful.

Alternatively if you really want to attempt yet another language port then the feature list in order to get functionality parity with the current software is at least

moderation dashboard
new board creation
board deletion and editing
uses database
user management
themes or extensions
reporting system / log
moderation log
ban list
ban appeals
search
configuration editor
user notes
extensions for donate page
extensions for stream page
extensions for irc page
extensions for rules page
name, email, subject, spolier image, file ,oekaki
trip codes
sticky, lock , raw html
file / post deletion and password
banners support
customisable header support
moderation actions, delete, delete by ip, delete by ip all boards, ban, ban
and delete, unsticky, sage, lock, move and edit
support for post formatting
support for reply linking
image / file upload
thumbnail image support
ddt support for layer ?
ImgOps iqdb
word filters
word / phrase blocking
anonymous naming scheme
board customization
api probably 4chan api compatible or similar
catalog extension
overboard extensions
recent posts
css themes
works with and without javascript
is performant and somewhat secure
hackable
and an appropriate migration script for both the database and the files on the filesystem for existing posts.

  No.22301

>>22227
So I figured I'd take a look at the actual database management code the site uses and as usual with the code around here the words "Schizophrenic Clusterfuck" come to mind pretty quickly but part of that is because I'm not really sure what I'm looking at, I still haven't quite figured out how posts are stored, but I figure I get a text on SQL and start pulling this soykaf apart

>>22250
How's the imaginary corn this year John?

I've so far submitted two whole patches to the site's software, and I barely know any php whatsoever, you don't need to know that much about programming in general to make a contribution

see these posts
>>18083
>>18086
>>18093

  No.22302

File: 1488162294479.png (590.3 KB, 200x133, lazrtag.png)

>>22251

Lainchan has always been where I and a lot of people come to for rare knowledge and perspectives on technological systems

>hackable


has any consideration been given to an advanced interface as an alternative? I currently use a plugin + edit-server in emacs to compose posts in my editor, but browse the rest of the site less monolithically by opening tabs.

a distributed back-end prototype would be /cyb/ too, as well as some sort of reputation and /soc/ system.

  No.22311

Are we still trying to contribute to the current Lainchan codebase? Looks like the last commit was on Jan 17th

  No.22312

>>22311
Also, I don't want to soykaf on Appleman too much, but there's little to no real leadership on trying to improve Lainchan's software. I have some free time to spend working on committing changes, but it's a real uphill battle for anyone to start contributing.

Take this open issue: https://github.com/lainchan/lainchan/issues/56

What even? There's no one able to replicate it, nobody actually even knows what the error message is, and the last time anyone mentioned anything was back in August. Yet I see mods complaining about this issue and even in this thread using it to talk about why Vichan software is really terrible.

Either that issue is not reproducible and so not important and the issue needs to be closed, or it is a real problem mods are running into and so one of them needs to chime in and explain what the actual problem is.

Huge numbers of the issues are like this, totally undocumented. I agree with the sentiment in the thread that we have a lot of people who have the ability to contribute code and it's more useful to contribute code to existing imageboard software than have every sophmore CS student try to make their own. But the people asking for those contributions, mods/admins, people that have gripes with Vichan, those are the people that should be documenting the problems they want fixed, and they're not picking up the slack on the documentation side.

The Issues section of the Lainchan github repo needs to totally overhauled. Issues that aren't important anymore need to be closed. Issues that are important need to be properly documented. There needs to be an outline for new issues to stop people from opening issues without having reproduction steps and information on where they found the issue, something like how Signal does their issue board https://github.com/WhisperSystems/Signal-Android/issues/new.

The PR section needs to be gone through and cleaned up. PRs that solve problems and have been code reviewed need to be merged. PRs without code review or from a new contributor need to be code reviewed.

The contributing and installing sections need to be COMPLETELY rewritten. I worked as web-developer for almost three years and the installation instructions were still confusing to me. Installation should be crystal clear, because we want people without technical knowledge to be installing Lainchan and looking for issues they can document.

The first two can pretty much only be done by people with ownership rights over the repo. It's those people that we need to see some leadership from initially, and from then on any mod who wants to see the software they use improve.

  No.22317

>>22312

Thanks for your feedback. It is probably better to provide such feedback in /q/ rather than /λ/ or via Github itself.

You don't want to soykaf on me, but you will anyway. You are saying there is little to no real leadership on trying to improve Lainchan, and that just is not true and is just soykaf.

I am only one person, I have made significant changes to the Lainchan software since taking ownership. I apologise that you think it s a real uphill battle for people to start contributing. I also apologise that my timeframe is not your timeframe, despite you not having specified what your timeframe or idea of leadership is.

I have no raised any new issues on Github, and am trying to close the existing ones, but as you say the reasoning and documentation on issues raised previous is sparse at best.

I review the existing issues and PRs at least once a week, but I don't always have time to work on them. (I am only one person, there are only 24 hours in each day).

The current outstanding 3 PRs have not been merged because they are all stylistic changes that haven't passed code review or haven't been tested in a wide enough browser configuration sample space to be consider valid.

I will look into making a issue report template for new Github issues.

Regarding the contribution and installation sections, I am not sure why those sections need to be rewritten.

I don't want people without technical knowledge installing Lainchan or Vichan and looking for issues in their installation, because 99% of their issues will be vichan configuration issues with their installation, and not related to Lainchan at all.

If you have further questions , please make a /q/ thread or ask your questions in #questions on Lainchan IRC or #lainchan-dev on Freenode.

  No.22320

>>22311
All things considered, that's quite recent.

>>22312
These aren't bad ideas, but they're going to take a lot of time in practice. Nobody gets paid, nobody has much time and the only people with a real commitment are overworked just doing the day to day things. We all know that a large part of the problem is that the codebase is so awful to work with that even surrounded by programmers it's hard to find people and most of the community efforts have gone towards things like easier installation and better error reporting but it's very slow going. Nobody really wants to do it and there's no incentive to offer. Coordination is a massive problem under these conditions. There's no 9-5, you have to catch people and hope they're in the mood to do something productive and people sometimes just disappear.

For instance the issue you linked happened during the last board reshuffle. It was a mistake in submitting the issue not to be more clear that the error message was "". The only mod who could tell us how to reproduce it wasn't available at the time and after the unrelated bug in moving replies was fixed that was used as a work around. The problem undoubtedly persists but it's no longer pressing and so nobody has the time or inclination to work out how to reproduce it. It's not ideal but what we are supposed to do? Nobody has any control over what people choose to work on or even if they'll work at all (other than themselves of course).

Hopefully we can get through all the boring, awkward stuff and make it easier for people to contribute but that's the same hope we've had for the past year and I can't really complain about that because I've spent as little time on it as anyone. There are no pressing issues and we're all lazy volunteers. Usually we'll get a bit of motivation after the meetings.

On the subject of meetings, please if you want to contribute or if you're already writing imageboard software, try to make it to the next one or post here if you can't. We all hate vichan and want a rewrite has been a thing for years now and it may be that we're better off trying to direct new contributers to that but it might also be that the rewrite projects are abandoned, nobody wants to start a new one, and we need to stick with vichan. Either way I think lowering the bar for contributers is going to be useful in the future.

>>22317
Don't take it personally. The codebase is and always has been a mess and it's easy for people used to business situations to look at it and not realise we have a fraction of the resources.

  No.22321

>>22317
Jeez man, chill out. It's really disconcerting to see the person in charge take everything that people say so personally.

I never claimed that everything in my post was your responsibility, in fact I kind of remember specifically pointing fingers at mods.

I know that it's a ton of work for just one person, which was exactly why I wrote what I wrote, the only way Lainchan matures as software is if a large group of people are working on it.

I get that all the documentation is difficult for one person to do, but that doesn't help anyone to hear. The point of being more rigorous about the things I mentioned is that it breaks up the work into documentation/programming sections and compartmentalizes tasks. It's way harder for anyone to contribute when the problem is "track down something wrong and fix it" instead of "explore the problem described in this issue with these steps to reproduce it". The end outcome of having stricter policies governing the Github page is that there's less work for people like you, and the alternative is just that people won't even bother and will work on something else. This is a way to make your roll EASIER.

>>22320
>Coordination is a massive problem under these conditions. There's no 9-5, you have to catch people and hope they're in the mood to do something productive and people sometimes just disappear.

That's why it's so important to have the Github page so straightforward and understandable. You lose people when there's an organizational barrier to surpass. If there is legitimately no time AT ALL, even to do this, then this is a total lost cause.

>For instance the issue you linked happened during the last board reshuffle. It was a mistake in submitting the issue not to be more clear that the error message was "". The only mod who could tell us how to reproduce it wasn't available at the time and after the unrelated bug in moving replies was fixed that was used as a work around.


We're still waiting for that mod? Since August?

> nobody has the time or inclination to work out how to reproduce it. It's not ideal but what we are supposed to do? Nobody has any control over what people choose to work on or even if they'll work at all (other than themselves of course).


Again, either it's inconsequential and so should be closed, or it's impactful and so someone who cares about it should find the time and inclination to reproduce it. This middle limbo isn't helpful to any party.

>Hopefully we can get through all the boring, awkward stuff and make it easier for people to contribute but that's the same hope we've had for the past year and I can't really complain about that because I've spent as little time on it as anyone. There are no pressing issues and we're all lazy volunteers. Usually we'll get a bit of motivation after the meetings.


Then we shouldn't be seeing threads like this OP bitching about the quality. I understand you aren't the OP so I'm not directing this at you. It's especially irksome to see mods, the people in a position to more properly document problems, complain about Vichan and call for a replacement without putting any effort into helping others help Vichan.

>Don't take it personally. The codebase is and always has been a mess and it's easy for people used to business situations to look at it and not realise we have a fraction of the resources.


I contribute to open source projects, I know that this is obviously not code someone was paid to right.

But the issues with the management of this site's code are worse than most OSS. There is a hell of a lot that needs to be learned from other projects if anything is going to improve. And again, if the response to that is "that's totally impossible, nobody has the time to run this like other Open Source projects, you can't expect that" than so be it. But that means it really is just going to stay garbage forever.

  No.22332

>>22321
>Jeez man, chill out. It's really disconcerting to see the person in charge take everything that people say so personally.
You had a go at him and claimed we needed leadership, which is bollocks, without understanding the situation at all. It doesn't matter how good a chief you are when you have no indians.

>but that doesn't help anyone to hear

Man I could say the same about your post. Criticism with no solutions just an assurance that it's a "lost cause".

> If there is legitimately no time AT ALL

You don't understand the conditions. You don't get to tell people what to do. They will write code. They won't write documenation because it's boring. Literally the only play at the moment is to wait until someone comes along who is willing to do this. Is that someone you?

>then this is a total lost cause.

No. It's not. It would be for most OSS, but we're not most OSS. We're not gonna shut down lainchan because of this and it's not gonna stop needing maintenence because we declared it a lost cause.

>We're still waiting for that mod? Since August?

He's gone now. Not coming back. Happens. Even before he was gone, the threads in question had been moved through the workaround so reproduction wasn't possible for anyone. Not great for the coders but the site comes first.

>it's inconsequential and so should be closed

Maybe, my point wasn't that the issue is a totally valid one that definately should be there. It was to give you some insight into how things are going to go down. We can sit and dream about perfect organisation but that's a catch 22 that we're at the wrong side of and so going is slow.

>without putting any effort into helping others help Vichan.

That's just not true. Do you know what irks me? Seeing the people who gave up jumping through a few hoops to install the board software complain that the people who work on the site every day aren't putting enough effort towards making life easier for them. That's not reasonable.

>But the issues with the management of this site's code are worse than most OSS.

We're not most OSS. Most OSS only gets off the ground because it has small group of very dedicated people. We don't. We can say how important it is that we do, but we don't. The few dedicated people that we have are busy with the site rather than the codebase.

>But that means it really is just going to stay garbage forever.

That would be true of most OSS. It would have been abandoned by now, nobody actually wants to work on it. I sure wouldn't have put any time in but unlike most OSS we aren't fueled by motivation for the project itself, we're fueled by the site. We're going to keep fixing bugs because we love lain. The handful of us that find the time and motivation to work with vichan are going to continue improving the environment and, slowly, we're going to pull our way out of this but we're not going to do that by pointing out obvious problems and expecting someone else to fix them or by declaring it a lost cause.

Anyway, back to something productive. I've been thinking more about the rewrites. At some point it seems necessary. Just the fact that vichan is PHP is enough to turn a lot of the people here away let alone that awful mess. At the same time, previous projects have had problems. I think, if anyone wants to try again, we could do more to ensure that even if they wander off someone else can pick up their work. Still, that's something to discuss at the meeting when we can have a better idea of who wants to do what.

  No.22337

>>22332
Why are you writing all of these responses assuming I don't understand how OSS contributions work? My criticisms of how Lainchan is managed aren't that someone isn't paid to write it (which... what? How did you even start to think my post was about that?), it's that it's not being managed efficiently, which makes it difficult for people to contribute.

>That would be true of most OSS. It would have been abandoned by now, nobody actually wants to work on it. I sure wouldn't have put any time in but unlike most OSS we aren't fueled by motivation for the project itself, we're fueled by the site. We're going to keep fixing bugs because we love lain. The handful of us that find the time and motivation to work with vichan are going to continue improving the environment and, slowly, we're going to pull our way out of this but we're not going to do that by pointing out obvious problems and expecting someone else to fix them or by declaring it a lost cause.


If this is the crux of your replies, than my point still stands. Why ask people to contribute? If the people in charge of the repo are so adamant that their way of doing things so far is the only way it could possibly work, and they're just mavericks fighting for what they love against all odds, and anyone pointing out mismanagement just doesn't understand how things work, then why even ask for input? Why urge people to contribute code? You can't complain that no one helps, that there's a tiny group of core contributors who do all the work, that there's no time, but then ALSO claim that there's no alternative, and that what you're currently doing is the only option, and that anyone asking for things to be run differently is just a hater who doesn't Get It, man.

The open issue about thread moving is the perfect example. You've taken the time out of your day here to argue vehemently that I'm totally wrong about how that issue is being handled, yet you've written here way more context and information about the issue than is on Github.

Just go write this there! Why would you not even take the time to provide that small bit of context? As it is, if people go to the repo they're kept in the dark about pertinent information. This system ensure the only people who even CAN contribute are the core group of die-hards with external knowledge. Anyone who has a weekend and checks out the Github repo to see if there's anything they can help with has their job made that much harder for them.

  No.22342

File: 1488374413956.png (77.71 KB, 200x200, PBNnFTr.jpg)

>>22312
>>22317
>>22321
>>22332
OP here, can we keep the flames turned down a bit? We all want the same thing here, to see lainchan improve, we're all on the same side.

>>22321
Then we shouldn't be seeing threads like this OP bitching about the quality. I understand you aren't the OP so I'm not directing this at you. It's especially irksome to see mods, the people in a position to more properly document problems, complain about Vichan and call for a replacement without putting any effort into helping others help Vichan.

I think there's a bit of misunderstanding here. This thread's just supposed to raise awareness about the state of the codebase and the average user's ability to contribute to it. Now weather or not that's the actual effect it's had is a question I can't answer but that was the intent.

I made this thread on a whim after talking to the previous site owner Kalyx over the mumble, and hearing him complain about the board migrations and how difficult the site could be at times to manage from a technical standpoint, that wasn't something that I was aware of at the time and so I assumed it could do with some improvements, which I figured lambda was rightfully positioned to provide, hence this thread. I didn't make it to complain, I love lain, and I want to see this site keep getting better.

  No.22344

>>22337
>Why ask people to contribute?
Because otherwise they wouldn't. If nobody had ever asked I wouldn't have contributed.

>If the people in charge of the repo are so adamant that their way of doing things so far is the only way it could possibly work

Nobody said that. My opening point was "good ideas, but they're going to take time." Again, we'd all love perfect organisation so that lots of people want to contribute but that's going to take work and that's a catch 22.

Also, "If the people in charge of the repo" makes me think you might be under the impression that I'm a mod. I'm not, I cannot commit that much time.

>anyone pointing out mismanagement just doesn't understand how things work

You labelled it a lost cause. You are used to similar but critically different scenarios. I know because I made the same mistakes when I first started working on this. We're a "lost cause" that we cannot abandon. What now?

>You can't complain that no one helps, that there's a tiny group of core contributors who do all the work, that there's no time, but then ALSO claim that there's no alternative

That's not what I'm saying. You pointed out the legitimate issues that cause this and offered a working alternative but that alternative is going to take time and effort to implement. We will spend that time and effort, as we have been for some time but, right here, right now, there's not many of us and we're lucky if we average an hour a month. That's just a reality and in that we have no alternative but to keep pushing forward and fix these things slowly. If you have a practical alternative to this I will reach through lainchan and kiss you but short of "do it all myself" I don't see one.

>You've taken the time out of your day here

Why haven't either us of us spent the time we spent here actually fixing problems? Because vichan is awful to work with and we'd rather be here.

>to argue vehemently that I'm totally wrong about how that issue is being handled

Not at all. I said "my point wasn't that the issue is a totally valid one that definately should be there." I think we're talking past each other. I agree with the criticisms you have but the solutions are going to take far longer than you might expect because we're a "lost cause".

>Why would you not even take the time to provide that small bit of context?

Because I was tired and annoyed that I wasn't going to be able to reproduce it and so the next time it was relevant would probably be another emergency and I just wanted to go to bed. Then I forgot about it. Which highlights another aspect of the situation. Morale ain't great (also I'm a lazy son of a bitch).

>This system ensure the only people who even CAN contribute are the core group of die-hards with external knowledge.

You overestimate our resources. There's no system at all. Even #lainchan-dev has been dead for months and it was created in an attempt to fix the same problems you've pointed out. We got as far as marginally better error reporting and installer (plus 2 whole bugs) before we lost steam. Lost cause? Sure. Give up? We can't.

>>22342
>OP here, can we keep the flames turned down a bit? We all want the same thing here, to see lainchan improve, we're all on the same side.
You are very right. My apologies, 22337, perhaps I took things a little personally. It's just that we are painfully aware of these problems and I don't know how closely you looked but these problems are deep. Vichan is awful through and through. More painful is the fact that the good solution here is to do it all myself but I just don't have time.

  No.22345

>>22344
Cont.

>Now weather or not that's the actual effect it's had is a question I can't answer.

It has. It's because of this thread that we improved the installer and error reporting. That's not a lot of work for 6 months, no, but it's what we got and it's better than nothing. On that note, while some of this has been wasted energy, again my apologies, we do have a bit of energy here and it seems remiss to waste more. The three main points were issues, PR and installation. For issues we want an issue guide written. We want to encourage people to give pertinent information while being sure it doesn't raise the barrier to entry too much. PR are more difficult and will probably have to wait for the meeting when we're a bit more coordinated. I'll look at the installation instructions some time this week.

  No.22349

>>22345
When are these meetings by the way, can I get a schedule? I'd like to attend if it's just on the mumble server or something.

  No.22358