>How long will the downtime last?
'If' this place does go down, then it'd be untill I can arrange for some new board softwear or fix the one we're on now. Which... could take a while not gonna lie.

>Is the "forced update" a bump in php version (which I think was mentioned was incompatible with the ancient codebase?).
yup, that's exactly it. We sort of forgot about it months back but I got a reminder a couple days ago saying this will go into effect this month.

>Has one of the more modern imageboard backends (e.g. Lynxchan) been looked into
yeah we actually tried out Lynxchan and worked a bit with it's devs at one point and found it a convoluted pain to get working. If nothing else works, I'll have to look into that again. I wouldn't let the site stay down for good.

>>1915
cute cat

>>1916
>'If' this place does go down,
Can you deploy locally and see how much would break (most likely the entire site I'm guessing since kusaba x is about ~10 years old). I'm worried that if the site goes down for some time we'd lose a fraction of the already tiny community.

Also you're right I took a look at Lynxchan and it's dependencies are overkill. There's no need to use nodejs and Mongo for a simple low-traffic imageboard.

You might want try ViChan (or this modernized fork of Tinyboard: https://github.com/Circlepuller/Tinyboard). I don't think it would be very hard to get running since it's only dependency is on mysql. They also claim to have a migration script to automate the transition from kusaba x (although even doing manual migration shouldn't be too bad since the sql schemas seem pretty compatible, and stylesheets/etc. are easy to replicate manually).

Alternatively (and this would by my favored option if I were to start an imageboard), take a look at TinyIB. It has an extremely compact and readable codebase, and can be deployed anywhere with 0 dependencies (using a plaintext file to store posts). The downsides seem to be that that it currently lacks support for multiple boards (this could be worked around by having a deployment for each board), and that it does its templating directly in php which is a pain.

Post edited on 4th Nov 2019, 10:33am

>>1919
It's 2019. The web server and imageboard should be written Rust. Using any other language to implement a solution would be indicative of negligence and, frankly, toxicity.

>>1920
It's almost 2020. Which means it clearly needs to be rewritten in Go Haskell.

>>1921
I'm sure you meant V when you said Haskell.

>>1916
If you have to adopt an entirely new board software what are the chances you lose all the current posts? It'd be a real shame to see everything that's up currently get lost to time, will you archive and distribute it in any way?

Hearing this news makes me want to setup something like heritrix to crawl the site so I have a copy but if you already have a plan for that I won't bother.

>>1923
I'm pretty sure you can migrate posts since the schemas between kusaba and vichan aren't too different. Worst case if some new esoteric board software is used they might have to rig up a converter script. I hope the staff makes regular backups of the DB though, since without it this is moot.

>>1916
why isn't moving to a different host or self hosting being considered? is there something going on behind the scenes to prevent this? i would really hate to loose this lightweight and unique imageboard interface just because of the outdated codebase. there is too much material design/ web 3.0 garbage out there the internet already.

>>1925
PHP 5.6 is EOL'd anyway, so I don't think any shared hosting provider will continue to support it much longer. They could always self host or find a host that allows them to install arbitrary packages, but I don't think its wise to expose something that's no longer receiving security updates to the public internet.

There's a separate question as to why the hell PHP makes so many backwards incompatible changes every update.

>hate to loose this lightweight and unique imageboard interface... web 3.0 garbage out there the internet already.
None of the other imageboard software listed has an interface that's radically different than the existing one. In fact vichan/tinyboard has pretty much the exact same interface. Perhaps the only one that might be considered to have succumbed to modern webdev trends is Lynxchan, but that's mainly for its dependencies on nodejs and mongo.

That being said, it'd be nice if we had some more information how (hopefully not "if") the staff are planning to go forward. Seeing as this is pretty much the last imageboard & community that hasn't gone off a cliff in quality it'd be a shame to lose it.

>>1926
>There's a separate question as to why the hell PHP makes so many backwards incompatible changes every update.
My uninformed opinion is that old PHP is considered trash. So fixing that would require successive versions that remove or change existing functionality.

>>1915
Not a huge fan of changing the layout of an imageboard. Yet another aspect of the "old-ish" web going down and being replaced with standardized parts. I certainly hope the look and design of the website remains the same to as great an extent as possible.

>>1927
For what it is, it's an ok language if you view it through the original lens of being a simple domain specific language that serves as a templating system for web pages. There's a good talk by the creator of PHP here, and watching it helps one understand why PHP is the way it is.

https://www.youtube.com/watch?v=wCZ5TJCBWMg

"I had absolutely no idea… At every point along the way, I figured there were about six months of life left in PHP. Because that’s about the amount of time I thought it would take for somebody to write something real that could replace it, that also would work for me. And I kept waiting… And nothing did."

People really shouldn't be implementing complex business logic in PHP though.

>>1927
Also this is off topic and should maybe be a new thread, but I think SICP is highly overrated in terms of how useful it is. And especially recommending it to new programmers is downright insane. As a means of exploring the beauty of lambda calculus or as basic introduction to functional programming concepts, sure SICP and Scheme are fine. But going through it doesn't really make one a better programmer in any way other than improving your math skills, which can be done more directly by reading an algorithms book or doing project euler if you're so inclined.

Some people I've talked to about this think it should blow over without issue, all the same I'll try to test some stuff out and see about getting alternative software running. Been pretty busy with offline crap that I wont bore you guys with that's been keeping me from being more involved with this, but I should have time this weekend to figure something out.
Speaking of, one image board that sounded interesting was infinity-next, any thoughts on this? One way or another it's probably for the best to drop kusabax anyway, this softwear is held together with tape and bubble gum, and we're all out of bubble gum.

If TC does go down, with any luck it wont take me more than a few days to a week to get it back up in one form or another.

Okay, so I snagged a fresh copy of kusaba-x and installed it to another domain on php 7.2 and well, it worked just fine.

>>1929
Thanks for the insight. An abused tool is a used one, I guess. Advancing PHP at a precipitous rate seems to be a means to adapt to its actual usage. Thanks for the video, by the way.

>Also this is off topic and should maybe be a new thread, but I think SICP is highly overrated in terms of how useful it is.
I've read little of SICP, but it seems to iteratively and neatly build upon itself (Thanks in so small part to it using a lisp, I'm sure.), and making everything seem pretty easy to grasp. On the other hand, seeing as Python and whatever textbook has supplanted SICP, your opinion is aligned with MIT's admin.

>>1940
With the state of modern web dev, there's probably also something to be said about the relative "simplicity" of PHP in terms of the abstraction level. Though the actual language itself might be terrible to work with, it's pretty easy to see what it does: you give it a "templated" html file and the interpreter spits out a version with the stuff within the php tags evalauated. A small, natural improvement over raw CGI scripts (although personally as someone who hasn't touched webdev much, I adore CGI since I can just use any language and treat the browser as stdin/stdout. Since my personal pages are minimalistic anyway, generating html by hand isn't too much a pain). But on the flip-side this probably does quickly turn into spaghetti for more complex sites (but maybe we can just call that a feature, since you really shouldn't be writing web "3.0" client-side applications in the browser anyway. Create a native app!)

Now it's probably the case that more "modern" backends like nodejs/etc. don't *necessarily* have to be coupled with the entire ecosystem (it is after all just an interpreter like any other, and I'm sure you could coax it just being a simple cgi-esque interpreter), but it sure does seem that there's a lot more abstractions you've got to deal with: the entire npm craziness, frameworks that change every week, etc. Of course I could be wrong, but almost every intro has you download this mess of dependencies which seems like overkill for most static sites and simple CRUD-style apps.

>seeing as Python and whatever textbook has supplanted SICP, your opinion is aligned with MIT's admin.
Interestingly even though both Berkeley and MIT switched from scheme to python, Berkeley's course is still highly scheme influenced. Python is learned through the lens of environment frames, and there's a heavy emphasis on grokking lambdas, recursion, and the nature of first-class functions so it's not too different from scheme in that regard. The course also does culminate with a dive into scheme, and the final project is implementing a scheme interpreter in Python.

>>1941
What do you think about PHP frameworks?

>>1939
kusaba refuses to die! hopefully this means that we'll see those significant performance improvements promised with PHP7/7.2

Whatever happens, please keep the edit function if you can.

>>1944
I agree. It's a useful feature to fix little mistakes.

I would just like to say that I really like the layout and functionality of this site. I'm not into programming but all the other imageboard software I came across before feels worse.

Contacting Tohno-chan.