/tech/ - Technology

>>17993
Upon further consideration, I think for just software design cloud systems architecture, ci/cd, deployment, itsm, and SRE could be cut out because all of that shit is really more the responsibility of the operators, not the devs.

the only traditional operator task i think maybe should be observability, that should be built in since its hard to do without observability having been an architectural goal from the very beginning.

>>17986
It really doesn't matter which language you choose as long as its not a scary language. Eg. Scala, C, C++, or any functional language really. I don't see the point of java if kotlin exists.
>>17989
Regarding the last block in the design, most chans will be deployed in a small VM instance, and that should be taken into account. Also monitoring and instrumenting is really valuable, so that's good. Something like opentelemtry.

The database and api design, plus the implementation are both the "same step". They inform each other at the design phase and will likely be implemented together.
>>17995
yeah, I got busy and couldn't finish a response. Here it is half baked.

>>17996
>Eg. Scala, C, C++, or any functional language really.
Clojures more purely functional than java and a jvm lang to boot.

>>17996
>most chans will be deployed in a small VM instance
maybe if it was more service/microservice oriented it could be a collection of cheap VMs (€5-10) rather than one single expensive VM. The cheapest OVHcloud vps hosts are ~ €4/$5. So you could get 24 cheapo services for microservices rather than one fat big server. Even if you want a beefier model you could get 12 medium servers, if it scales better than one fat server its worth it i guess.

Most chans receive zero new posts a day and happily run from a single perl script that has not been touched in a decade.

are we really wedded to scala? AFAIK Scala doesnt have a good API test framework like this: https://rest-assured.io/
unless someone here writes one. OTOH you can use rest assured with Kotlin. Kotlin seems to have alot better interop with existing java libraries.

There's a pretty good choice for all the people here saying they want jvm: CLOJURE

1. its a lisp, which floss and /g/ people love (scheme/cl)
2. Its more "purely" functional than Scala
3. It has way simpler syntax than Java or any other non lisp language since knowing () is literally 80% of the battle.
4. It has java library interop which is way easier than any other jvm lang other than maybe kotlin
5. It's a dead simple and a hellofa lot less big brained than scala, makes FP super easy for mere morals
6. Development cycle is faster due to it being dynamic, but still gets the benefit of AOT byetcode performance, once you're done developing/using the repl you can compile it to bytecode for production
7. No complex type hierarchies
8. Tooling is pretty good
9. No OOP option or object-functional, FP is literally forced.
10. Typical clojure style roughly corresponds to ML/OCaml with LISP syntax/expressions + hygienic macros, so you have to really TRYing to not write idiomatic code.
11. Good concurrency model (STM)

If you're writing in a domain where correctness is necessary (finance, embedded software) then static typing is a must. But for an imageboard? pfffff

Clojure is a no brainer, the only problem is that it's obscure, but trust me, when the entirety of syntax you have to learn is () most people can catch on pretty dang quick. Well ofc there are also vectors which use square brackets, and {} for edn, etc. but thats not that big a deal so maybe () is 80-90% of syntax rather than 100% like with other lisps. Still extremely simple. and the best part is you don't have to be some guy with a PHD in category theory.

>>11160
How would this imageboard be marketed?

>>18006
Through a marketing department with merchandise deals with sports clubs and Adidas and rappers

>>18006
Anime girl mascot

OTOH why shouldn't PHP be used?

If you want your imageboard to have mass adoption, maybe it should use the language every other IB uses? The vast majority of people setting up an IB are amateurs not java corporate devs let alone XYZfunctormonad FP wizards.

If you make it in PHP you've made it in a language they already understand and can fix, maintain, easily, rather than forcing them to learn a new language.

>>18012
Who's to say someone knows PHP? You're being very presumptive

I checked today and leftypol seems to be cached rapidly, what is the decision making process that decides if a website is to be actively monitored and cached?
>>18067
It's a very simple language to the int anyone can pick it up very easily with marginal experience programming.

>>18094
>It's a very simple language to the (po)int(?) anyone can pick it up very easily with marginal experience programming.
Really? If you wanted to, say, implement a feature where videos are automatically converted into webm's, would it be faster for a person to learn how to do that in PHP compared to another language?

>>18101
I would say so I only program casually but I guess you would only be using exec to run ffmpeg against the file to make a new file in this instance and it would be a simple task regardless for most any language.

>>18102
>>18101
yes, most php based imageboards convert using third party command line tools like ffmpeg, imagemagick, etc.

If we were to use PHP, what framework would it be written in? Codeigniter, laravel, slim, or symphony? Or something more obscure like cake/yii/phalcon/etc.

And would it use server side or a front end? for the most part its convention to use vue.js with php backends

Futaba-esque imageboards are a paradigm that needs to be dropped
4chan's legacy should be forgotten, not revived

>500 posts
>literally no good ideas or posts

starting to think imageboards are a failed path

>>18143
They are, like I said >>18142
The only people who begin to care about imageboards anymore are morbidly curious tourists and obsessed reactionaries, the first of which couldn't care enough to design newer software, and the second of which don't tend to have any real skills or talents or any drive for anything
Current imageboard maintainers like leftypol's devs will only go so far as to do small maintenance and feature additions to an existing software base

Also non-tech-wise:
Imageboards just suck
4chan always sucked even early on
It helped drain the mystery out of the internet
4chan and its main English language predecessor, Something Awful, more than anything else helped create and propagate the mythology of the implied straight white male internet dweller, with a repetitive "meme" vocabulary as a system of signals for it
Even to this day, stuff like QAnon and soyjaks spread throughout the Internet like a miasma wherever people tolerate it, taking up as much space as possible, killing off any discourse remotely interesting or novel

So, yeah
It's a dying space that was never really any good in the first place

>>18142
>>18143
>>18144
what specifically is wrong with the format though? You've described the type of people who use/used them, but is it inherent to the medium?

>>18147
Yeah
As it stands, every post is just a single self-contained <div> with its own media attachments and whatnot, which lets drive-by posts happen pretty easily, as well as dump threads, passive-aggressive responses that don't directly reply to whatever they're addressing, etc
Threads need to be "smarter"
They need to have coherent semantic links in some way

>>18154
what's not good enough about threads and >> links that they dont qualify as coherent semantic links?

To me the fact that every post is its own thing just makes it easier to visually identify individual posts. It's not very different from any other social media or chat (except for threaded/tree structured ones, which tbh just make it hard to see connected comments, only thing that makes it usable is collapsibility). I doubt the underlying html actually encourages drive-by posting and dumps, just appending the posts to the html in one div would allow the same exact thing with an uglier interface.

>>18154
>They need to have coherent semantic links in some way
so basically wikipedia then?

>>18158
No, not basically wikipedia then

>>18157
>what's not good enough about threads and >> links that they dont qualify as coherent semantic links?
Read any thread on any imageboard right now

>>18154
reddit comes to mind weirdly

>>18160
explain what you'd mean by semantic links. Do you mean making it a graph type social network?

I have to learn Go. Might make a pet imageboard project in Go and drop it before I even finish 10% of it.

>>18005
The category theory stuff is overrated. You really don't need to know much. Just practice. At least with scala.

In fact, after doing Scala for 2 years, I'll conclude that category abstraction libraries like Cats and CatsIO are actively harmful in actually using said abstractions. Either the language was not made to accommodate these category theory abstractions, or the Cats/CatsIO library sucks balls and was implemented wrong. I have more gripes with Scala 2, but they are too abstract to explain, unless you've had to wrestle with the compiler and type checker. Shit like "tagless final" for libraries sounds really cool, but whomever is still pushing that shit today is the devil. Namely, doobie fucking sucks, but it's one of the most used database libraries.

Anyways, my point is that category theory is not necessary nor necessarily useful to use scala, including it's functional abstraction libraries.

Clojure sounds nice. I haven't worked with a big system lisp, I've only done small functions and such. I've heard writing code in a Lisp is a pleasurable experience.
>>18154
So what do you propose?

There's some interesting imageboard concepts. There's a 3D imageboard/forum space. It's pretty weird. boorus are also considered imageboards. Reddit-style, or digg style forums aren't really imageboards. "bb" forums I guess are imageboards, assuming image posting is enabled, and are also the OG forums after usenet and mailing lists. I want to think that the format of imageboards and BB forums works for what they are used for. Namely sequential discussion. And reddit-style/HN-style forums are good for mainly one-off comments surrounding a specific OP.

I wonder if there's a way to get the best "features" of both platforms, and come up with a unique forum experience. How would this look?

>>18795 (me)
Besides reddit, another very popular platform is fbi.gov. As a non-discord user, I tend to underestimate the importance of the platform.

A good community nowadays has way less expectations of privacy than the internet in the early 00s and 10s. Interactivity, chat, quick response, self-moderation, hierarchy of moderation (drama), drama, lightweight "channels", etc.

One complaint I read about old BB style forums is that they're hard to parse. Part of it is due to the shit reply system. Another part is due to the layout of blocks per post, whereas fbi.gov has a more compressed view. There's also the ability to "spam" comments. On imageboards, each post is a huge block.
>>18796
Thanks. I'll definitely check it out. Might contribute even. My goal is mostly to learn Go, not to build anything. Unfortunately I don't have much time to spare to learning anyways.

>>18796
gochan's db schema was way too complicated IMO

>>18795
>>18798
Disc0rd is too insular, which causes it have very petty in-group dynamics (including grooming) and the most stilted conversations you could ever have. It was designed to be Slack but for gaming groups, not a general social platform.

>>14251
what does everyone think of the first pic for this DB? is schema in this post developed enough to use?

>>18803
Well, I'll give the same opinion I gave on that post, it's still to immature to be used. But you can begin developing and build out the schema as you go along. It's actually a common practice in many places. Ideally you would sketch out a database with as much domain knowledge as possible, but crucial parts of the domain are usually discovered as the software is built, so changing the database mid development is almost always inevitable.

whats everyone think of using PHP/laravel for an imageboard? more maintainable by normies who are used to php. could help with mass adoption

>>19091
I don't see a reason to use PHP in today's world. All other languages are good enough. Everyone's learning other languages nowadays.

PHP is not so different to, say, python or java. Just use what you're comfortable with and bias less shitty languages.

Btw, there was a work in progress for a technical design document for a new imageboard, no? I keep revisiting the idea of wanting to build an imageboard as a hobby, but it's way too overwhelming unless I have some reference to program from. I'm thinking of writing a TDD, but the amount of effort that would take is way more than the time I actually have for hobbies.

I'd start with a list of features, grouped by type, and separated into two or three phases. Phase 1 would be "mvp". Phase 2 would be "feature parity with vichan". Phase 3 would be "nice to have".

The description of Phase 1 and Phase 2 features would be the most important.

Afterwards, I'd start adding API endpoints to the features. How exactly will the front end achieve these tasks. I'm assuming the system will have an API. It's also important to remember the requirements, if the site is available with no javascript, then the API must account for that.

Then I'd start sketching out request and response objects for the API. Nothing too fancy.

Afterwards, I'd start building entity relational models based on the APIs, the constraints, and the request and response objects.

And I think the last step would be to annotate each feature with a description of the Front End implementation. How exactly will it be implemented in the front end?

So at the end you'd have a document that says something like:

Phase 1:
Posting:
User can create a thread:
The user can create a multimedia thread. The OP has name, subject, etc.
API:
POST /threads
or maybe
POST /boards/{boardId}/threads

Request object:
name: Text
body: Text

Response:
id: uuid

Related DB storage:
thread:
- original_post: Post (fk post) <- this is required for the implementation because x and y
- created_at: date
- is_anchored: bool

(this db part is just an example, doesn't have to be this way, it's loosely based on the example here >>14251)

Administration:
A moderator can do X or Y:
etc etc…..


The point of doing this would be to make sure that all the features of vichan are accounted for. This would be language, framework, etc etc agnostic. Perhaps the only non-agnostic part of it is that it probably assumes a relational DB. The other important part is that it lays down all the features and forces them to play together, allows them to be inspected and questioned. It will essentially force you to build the software taking into account all the features that are expected of the system.

Hopefully this document would serve as a guideline for the future developers who decide to build an imageboard system.

>>11528
>You should insert the files in the proper order and then order by id. there's no need for a "file order" field.
(not rat)
I disagree actually. Sequential ids are no longer "in". UUIDs are the future, kid. So file order is relevant here.

>>11265
Damn was I thorough. The amount of shit going on is just insane.


I found a federated imageboard software, and apparently the only remaining federated imageboard https://usagi.reisen/
I have no idea how ActivityPub works, but maybe it's a good thing to have at some point to ensure … something? Not even sure how none of this works.

>>21996
PHP is easy and a lot of people know it. You'll get many more people working on it. If you keep it to some niche language or framework like OCaml or Laravel, then you'd be best going to those language's communities and seeing if there is interest there.

PHP is a decent language for imageboards. Hell, you can even write a backend server in PHP to handle the requests and the database, and the API.

>>22011
Imageboards and forums should not be federated. They should be self-contained communities. Linking/web rings are fine, but no crossposting.

>>22012
Basically all procedural languages are pretty much the same. My issue with PHP isn't that the syntax is hard to learn or whatever. Basically all procedural and popular languages are picked up very quickly as long as you know another.

My issue with PHP is that it takes a lot of knowledge to not shoot yourself in the foot doing normal stuff. My issue with java is that it's a worse kotlin. Doing basic stuff you're probably going to be fine, but you'll also be fighting the libraries to find what you need and figuring out what you need to do to instantiate a SimpleObjectWriterFactoryInstance<ObjectWriterImpl>. Might as well just use kotlin, which comes with much better type protection than PHP or java.

Kotlin is an improved PHP. If you know PHP, you can do kotlin.
>>22013
Why do you say so?

>>22014
>what you need to do to instantiate a SimpleObjectWriterFactoryInstance<ObjectWriterImpl>.

class myClass {
    function __construct() {
    //some code
    }
}

$object = new myClass;

?

>>22013
I agree. They should allow for bridging though, so bunkers can conveniently backup or act as a cdn for the main board.

>>22015
It was a jab at java, not PHP.
https://stackoverflow.com/questions/2885173/how-do-i-create-a-file-and-write-to-it
Look at the hundreds of different ways to do something very simple: write shit to a file.

Half of these solutions will give you magic runtime errors if you try to run them.

an imageboard is such a goddamn simple type of software, I have no idea why there have been so many failed attempts to make a replacement for vichan. I can only assume it's because the people who aren't complete /g/-tier midwit larpers who have the skills to do this have other things they'd rather be doing, or maybe it's because the people who fall into a range of having the skills to do it and the interest to get bogged down in autistic design decisions instead of making something that Just Werks

source: I have a working, albeit very rough, imageboard engine written in Common Lisp that is currently like maybe 300 LOC and I could probably get it polished into a better state, add some fancy stuff like multithreading or liveboard features or whatever, but it's hard to get excited about something that isn't all that interesting

>>22102
>I have a working, albeit very rough, imageboard engine written in Common Lisp
Why not just add image posting to a proven textboard written in scheme?
http://textboard.org/

>>22112
personal preference of CL over scheme and also because as I said before, an imageboard is such a trivially simple piece of software that it's not like it would be unreasonably difficult to make another one, as much as it also is kind of boring and pointless

I've seen this textboard engine though and think it's neat for what it is

Hi there it's me, I am also visiting this website regularly, this site is truly nice and the users are actually sharing pleasant thoughts.

11 Ways To Destroy Your UK Pornstar Uk Pornstar