So it's been awhile since I last wrote, and I'm a bit overdue for a status update. So, let me give you all the short version on what's been going on.
First, I've been doing a lot of backend work to drastically reduce the size of the SoylentNews bill month to month. We had a lot of infrastructure that was either unnecessary, or have gotten so many free tier upgrades that they were being vastly underutilized. Along the way, I've given a lot of fine tuning to bits, although I won't say its been problem free, since we went a few weeks without working sidebars. I'm truly sorry for the delays in getting up and running. My personal life chose to become very exciting in December, and I'm still dealing with the fallout of that entire mess. As such, what I had planned went a bit pear-shaped, and I went unexpectedly radio silent. ...
More past the break ...
The biggest problem is that most of the backend is undocumented. I wrote some documents in the early days of the site, but by and large, the site was mostly maintained by individuals who are no longer active on staff. The internal TechOps wiki was woefully out of date, and even I find myself struggling to know how the entire site is put together. Considering it's been online for over 9 years, and was a bit of a rush job out the gate, well, you know, it happens. I think at some point at the decade mark, I will want to chronicle more about SN's history, but let's first make sure we've got a site when we get there.
By and large, I'm not involved in the day to day operations. janrirok has been, and is, at this point the de facto project leader. My role with SoylentNews these days is kinda vague and undefined, since I stepped down privately in 2020, and then stepped back last November. I also find myself very uncertain if I want to even be involved at all, but, ultimately, I was here at the start, and while SoylentNews was always a collaborative project, I left a mark on both what this site is and will be that has persisted over the better part of a decade.
As such, I feel personally obligated to get SoylentNews to the best shape I can possibly get it, and give it the best chance of success I can give it. However, we're in the uncomfortable situation that we have a dated Perl codebase running on undocumented infrastructure that has been creaking along with no major reworks in almost all that time. You can imagine I've been having a fun time of this. Most of the relevant information mostly exists in my head, since I was the one who got Slashcode running all those years ago.
Right now, my biggest victory is I managed to get us off MySQL Cluster, and onto a more normal version of MySQL which drastically reduces memory and disk load in favor of slower load performance.
Moving forward, the solution is to have a reproducible deployment system, likely based around Docker, or possibly even Kubernetes, with all aspects of rehash (the site software) documented. We use GitHub to handle site development, and I think it would be in our best interests to integrate a full CI pipeline for both development and production environments. While implementing this, I also intend to entirely redo every aspect of the backend, complete with proper documentation, so something beside me can actually maintain it. After that, it will actually be practical for SoylentNews to survive past a single person, and we can have a more serious discussion on what the road forward looks like.
I do realize that the last few months have had a lot of ups and down, mixed with excitement and disappointment. I can't really say for sure where we're going, but you know? I want us to reach that decade mark together, and then we'll figure out where we're going beyond that.
Until next time,
~ N
(Score: 5, Insightful) by Rosco P. Coltrane on Wednesday February 01 2023, @04:04PM
Thanks N
(Score: 5, Insightful) by ElizabethGreene on Wednesday February 01 2023, @04:06PM (21 children)
Thank you for the work you're putting into this.
Do you intend to continue using Perl? I'd like to help, but it's not a language I'm particularly competent with.
(Score: 3, Informative) by RS3 on Wednesday February 01 2023, @06:49PM (15 children)
I don't and can't speak for NC, but it's quite a lot of code to convert to some other language.
For several years the main coder / admin was TMB who discussed perl vs. other languages. I didn't catch all of his writings, but I distinctly remember he thought perl had some very useful and powerful functions, in general string handling. He made a lot of good changes and fixes to this site.
The "rehash" code is hosted on (MS's) github. I believe the link is in the Wiki.
I'm (sole) admin for some WordPress sites, which is all php. Over the years people (including here) have railed against php, including saying it's "insecure". In 15+ years of hands-on (and the only) admin, I've had no security problems despite the constant attempts to attack aforementioned site servers.
Most of my programming has been in (good old) BASIC, C, Assembler, and a handful of other misc. languages. I've modded perl, php, python, and done a bit with Bash scripts. Point is I don't get to do enough programming to feel strongly one way or another.
Do you have any thoughts about a better language?
(Score: 3, Informative) by ElizabethGreene on Wednesday February 01 2023, @09:04PM (14 children)
I don't, and my hesitation may just be that I've never worked with "good" Perl. My exposure is only from scripts written by sysadmins trying get a job done. I'll look at the repo and see if there is anything I can do to help.
Sidebar: The Wiki link in the left navbar opens http://wiki.soylentnews.org/wiki/SoylentNews [soylentnews.org] which currently 404's.
Thanks!
(Score: 4, Informative) by RS3 on Wednesday February 01 2023, @11:01PM
What? Broken links? Here? :-} Based on what this site has gone through, I'm beyond thrilled how well it works. :)
I think that stuff is/was on another server, and it's in process of getting condensed into one server.
Anyway, some assembly required? (pun intended?)
https://github.com/SoylentNews/rehash/ [github.com]
(Score: 1, Insightful) by Anonymous Coward on Thursday February 02 2023, @03:38AM (12 children)
This site isn't written in "'good' Perl." It was and is great perl for when it was originally written. The problem is that there are decades of intervening best practices, kluges, developer churn, package changes, technology changes, threat modeling, and more in the mean time. I've made a number of suggestions on how various people could help in the past but no one has ever seemed interested in implementing or helping with. No one likes messing with pasta code or touching delicate stacks unless they have to and it is much easier to bikeshed anyway.
(Score: 2) by janrinok on Thursday February 02 2023, @09:13AM (11 children)
It isn't, IMO, a lack of interest or reluctance to help. If we rewrite the entire software it will take thousands of man-hours, a lot of volunteers, and will only introduce new bugs. There is absolutely zero chance of producing perfect bug-free software if we rewrite. And after all that effort we will only be where we started.
If we had tens of thousands of people in our community then it might theoretically be possible to achieve it by finding sufficient volunteers. We haven't got that size of community and never have had.
What NC is suggesting is a way in which as many people as are interested can contribute to the maintenance of the existing code, bug squashing, and the introduction of new features - and all the other good points that you raised regarding writing software in this day and age. The problem that we had is that it was difficult to set up your own local computer to behave identically to the ones that we had configured. It was using specially compiled versions of very old and insecure software, which has all been updated now. It was very difficult therefore for anyone who hadn't got access to our servers to work with the code - it often did not behave the same way on a local machine as it did on our servers. We could submit patches but they couldn't be tested locally. NC has rationalised all of that and intends to containerise the software so that anyone can have a working version on their local computer. If a group wishes to rewrite it from scratch they can do so - without risking what we already have. They can produce their own container and theoretically it can replace the existing one after testing etc.
Another problem is that of securing the personal data of all of our members. You will be able to have a copy of the container - but you will have to populate the database that it uses with false data to a certain extent. I am currently looking at that particular problem and it may be possible to use much of the live database but simply change the personal data so that it does not compromise individuals. This also means things like changing the moderation records so that it is not possible to see who has been moderating whom, removing ban records, and the changing the parameters used by the server to protect our site etc. Privacy and security remain essential.
(Score: 1, Insightful) by Anonymous Coward on Thursday February 02 2023, @10:35AM (10 children)
You're attacking a position I didn't offer nor have. Nowhere did I suggest a total rewrite. Nowhere did I suggest allowing unfettered access to prod by everyone. Heck, there are dozens of bugs that can be fixed, and I mean some really low-hanging fruit, without any access to production or by simply looking. But no one has attempted to fix even the simplest of ones (even things that take 5 minutes).
For example, I have pointed out a number of times that the following is invalid SQL (and would still be terrible for performance): "SELECT count(j.id), u.nickname, u.uid, MAX(j.date) AS date, MAX(id) FROM journals AS j, users AS u, users_info AS ui WHERE j.uid = u.uid AND j.uid = ui.uid AND ui.karma >= $min_karma GROUP BY u.nickname ORDER BY date DESC LIMIT $limit" but it is still there unpatched. I can't even remember when I spotted that originally because a database failure but it is still there causing problems to this day. I can't even count how many bad SQL practices are in your source verbatim, let alone the dynamically generated queries.
The fact is that this site from the perspective of a number of people I've discussed it with hasn't been in a position to appear serious about wanting help, let alone accepting any offered. Add onto the fact that the code rots every day and it gets even worse. I don't even know at this point if even NCommander knows if they are serious or not about helping and accepting help themselves.
Here is a tip for you though, for proper testing, you need both a set of known data and random data. Work on a proper faker for the latter will get you much closer to the former without having to worry about your users' personal data. It doesn't have to actually be production data, it just has to look like it. And be sure to load it up into prod.
(Score: 4, Informative) by janrinok on Thursday February 02 2023, @02:52PM (8 children)
No, they haven't, because there was nobody who knew how to rebuild the code or had any significant experience with Perl. If you make a change you have to test it. How do we install it on the development system for testing? If it passes how do we load it onto the server? If we release it and it crashes we would have had problems restarting it. People had produced patches - but there was nobody to check them, apply them. test them or integrate them. As NC mentions he has found them in the bug queue - unread and unprocessed.
Where is this line of incorrect SQL? To whom did you point this out and how? I cannot even begin to investigate why your suggestion has not been actioned if I have no starting point. I cannot find it in any of the comments - but it may be there somewhere. Nobody was looking at bug reports. The post that should have been doing so has been empty for over 18 months and before that he appears to have been distracted more with the building that he was converting into a home.
Discussed where? I cannot find this discussion - but again it may be there. If the discussion was not on this site I wouldn't have seen it, nor would anyone else.
They were always identical although we could modify the contents on development to test specific data that appeared to be causing a problem and insert 'fake' data to fully test the system. Our main tester and QA specialist was Bytram who has done a considerable amount of this work professionally. As you know he has also not been able to contribute the same way that he once did. Unfortunately, there are no test units written for the Perl code. Creating a set of known data for a database that comprises of millions of entries in dozens of tables, which all have to be related to each other is no trivial task. But thanks for the tip. I am looking at alternatives too.
Changing bad code for good, e.g. your SQL example, still requires testing. That SQL was doing something - it might have been corrupting the database or exhibiting a side effect that, once removed, affects code elsewhere.
He does - but we cannot magic Perl programmers who are prepared to volunteer their personal time out of thin air. The best way to make the code more accessible is to use containers then anyone can have a copy on their local computer. If they break it, they just undo what they have done or download another copy again. But that doesn't remove the need for someone to do all the other work associated with even simple changes. Unless, of course, you are volunteering for the post?
(Score: 0) by Anonymous Coward on Thursday February 02 2023, @11:27PM (3 children)
Sure NCommander does? Is that is why he said "I also find myself very uncertain if I want to even be involved at all." Does that really sound like someone who isn't on the fence at all to you? Because it sounds like the opposite to me. And I think it is folly to ask others to disco when no one else wants to or has ever appeared to want to dance or even clean the floor.
To take the rest from the top. Deploying isn't some magic. Worse case scenario you just patch the same file you changed on the repo and then restart the server. Perl deployment isn't some sort of magic incantation. Another ignored suggestion is enabling coverage, which is installing the proper module and changing a single line for mod_perl. Or that SQL bug that dates back before TMB and NCommander left. In fact, it was in the code you inherited (although TMB made it worse around 2018 IIRC). But TMB and all else didn't care to change that after being pointed out (IIRC, the response was "I don't do SQL"). Again, you wanted us to help but not accepting any. As to why that is invalid SQL, that is probably worth a post itself.
Your constructing fake data is the perfect example of where coverage would help. In addition to the data you get from diffing dumps and the logs, you have the actual code executed by your changes. This can help immensely in making procedures that make the same sort of SQL actions and in coming up with tests to exercise the code. I don't envy you though. Faking data can be a real pain when dealing with pasta code.
(Score: 2) by janrinok on Friday February 03 2023, @07:23AM (2 children)
He has stated previously that that it is the toxic environment that had developed that caused him to step away several years ago, and that environment exists today but is now found mainly in the journals. He also has a lot on his plate both professionally and personally. He does not relish the thought of being solely responsible the site's long-term maintenance. So he is making it easier for everyone else to have a working copy of the code and to be able to modify and test it rather than leave it to a single person. But isn't that what you are asking for?
Other than that you haven't answered a single question that I asked nor provided anything to support your claims of actions that you have taken in the past or discussions that you have had. if, for example, that piece of SQL is NOT in rehash then where is it? How do you know that it is so critical? Is it even used? You say that it has been there since we inherited the original code yet you have not identified it.
I'm sorry AC, but you give me nothing to go on other than obscure claims of bugs that you say you reported to TMB over 5 years ago and alleged discussions that cannot be found. Did you submit a bug report? Did you provide a diff that would correct the problem? From what you are saying it is impossible for anyone to know.
TMB has gone. We have to move forward from where we are today, not from where we might have been if things had been done differently many years ago.
(Score: 0) by Anonymous Coward on Friday February 03 2023, @08:23AM (1 child)
I understand you have invested a lot of blood, sweat, and tears in this place. But this comment reads as yet another example of what I am talking about. At this point I am seriously wondering if you can take any criticism of this website as anything other than a personal attack that requires deflection. That bug and quote of NCommander and basically everything I've tried to relate are all in support of the original thesis. Even that bug example was of one that is easily found just by looking at the source without any access to anything AND drives home the point of how no one on SN's staff short of NCommander (who, as we both have now said, is on the fence about staying or working with the code) seems to actually care. In fact your reply to the obvious SQL-102 bug reads to be more as not giving a shit either. It reads to me (which at this point is very colored by "bitten multiple times even more shy") as just more deflecting from SN's decisions and the environment and impressions that created to try and insinuate some fault on my side because SN can do no wrong.
Since you are apparently so worried about this example bug instead why it was used as an example: here, [github.com] knock yourself out.
(Score: 2) by janrinok on Friday February 03 2023, @12:07PM
I am not taking it as a personal attack. You were stating things that provided no useful information to me. Searching for the SQL string that you gave me came up blank.
I am not a programmer on this site. I am an editor who has stepped forward to try to keep the site active. I haven't got any responsibility for the code or how it is built. I could not answer any of your questions unless you gave me more information which you have now done. But I already have a copy of the code - what I am looking for is the bug report that raises the issue and, perhaps, the patch that fixes it. Or tell me where the issue was discussed and with whom. I cannot see who has done what to that code until I know which one I should be looking at. It might be SQL-102 to you - but the software that I worked on didn't use SQL.
My professional programming experience is all with specialist avionic equipment, usually EW related, which was used in operational military aircraft. The rules were simple. If you changed anything (anything!) in a file the software had to be fully tested. We could not include a file whose content contained any changes from the operationally accepted code without it going through a full testing regime. My only experience with Perl is in the early 2000s on some small projects. If it was containerised I could help find bugs and possibly provide fixes, but I am not going to be working on the live code.
Saying that software should be changed is easy - but who is going to change it? Nobody is stepping forward. Are you? Others have suggested rewriting it in a different language. Who do they envisage doing that work? There is no development team. Other than NC there is nobody today who has access or the ability to rebuild the code and put it onto our servers. There are 2 sysops volunteers who are chomping at the bit to get involved but until NC can give them access and the magic incantations they are doing their best to establish their own working versions of the code so that they can start getting familiar with it and how it is built. There is no testing team. We have a handful of editors who are keeping the front pages filled, someone working on IRC, wikis, log files etc, and NC.
You probably have a valid complaint - but it is impossible to tell from what you have said so far. We know what the problems are, what we need are people who are prepared to fix them. If it is so easy to fix that SQL why hasn't somebody provided the fix and changed the code? It seems to be that it is always somebody else's responsibility. But there there isn't a 'somebody else'.
(Score: 1, Informative) by Anonymous Coward on Friday February 03 2023, @01:51AM (3 children)
The statement "SELECT count(j.id), u.nickname, u.uid, MAX(j.date) AS date, MAX(id) FROM journals AS j, users AS u, users_info AS ui WHERE j.uid = u.uid AND j.uid = ui.uid AND ui.karma >= $min_karma GROUP BY u.nickname ORDER BY date DESC LIMIT $limit" is not compliant SQL. To simplify the statement to show the buggy behavior:
For those more familiar with SQL the bug should be immediately obvious. This query is creating a pivot table from a larger dataset. However, when creating a pivot table, the SELECT statement can only contain columns that give unique values. As a result, the SELECT clause can contain only 2 (or 3) types of columns: columns appearing in the GROUP BY clause, columns whose final call is an aggregate function, and (if you are using an SQL server that supports this part of the standard) "functionally unique" values. Functionally unique values are those that have a "functional dependence" such that the schema, constraints, query's relational algebra force them to be unique. Examples of those are columns that are UNIQUE NOT NULL, columns whose table's primary key appear in the GROUP BY, columns with a single NOT NULL value for all rows, DEFAULT-only columns, WHERE clause limitations, etc.
So back to the query. The query does not have a SELECT clause that is limited to unique values. Column b.uid does not appear in the GROUP BY. That column is not subject to an aggregate function. That column is also not functionally unique. The column isn't UNIQUE NOT NULL, nor does it's table's primary key appear in the GROUP BY, nor does it have a single NOT NULL value for all rows, nor is it a DEFAULT-only column, nor are there WHERE clause limitations, nor does it fall into any of the other categories of functionally unique values.
The fix is relatively simple. All you need to do is to decide on some version of that query that is limited to unique values. There are a number of ways to do that. Best part is that because application constraints force a bidirectional dependencies between u.uid and u.nickname (hence why the query works at all), there should be no changes to the rows returned and no side effects other than getting your code one step closer to standard compliance.
(Score: 3, Insightful) by janrinok on Saturday February 04 2023, @08:07AM (1 child)
Thanks for your interesting and informative post. But I had to smile at your closing remark - I have seen numerous bugs that were the results of side effects that nobody anticipated. Simple rule: if you change the code then you have to retest it.
(Score: 0) by Anonymous Coward on Sunday February 05 2023, @02:03AM
No matter what when you change code you end up deploying it to your test environment. The real key is to make sure you have a separate production environment you use too.
(Score: 0) by Anonymous Coward on Sunday February 05 2023, @02:22AM
The nice thing about declarative languages is that you are specifying what the results are instead of how to get there. The nice thing about DQL is that in itself it is free of side effects. Meaning that the only place for side effects is in the return value. Since the columns are not changed you only have to look at whether the rows are changed. Aggregate functions should return the same data per row as long as the groups are the same, so you can ignore them. Therefore, the only thing that can affect your groups short of a bug in MySQL making it non-compliant is the relationship between uid and nickname. However, the schema provides a UNIQUE constraint on uid, which limits the uid:nickname relationship to either a 1:1 or many:1. As mentioned, the application logic prevents multiple users from having the same nickname, which limits the relationship further to 1:1. The result is that the bugged and fixed should have the same result. Of course that "should" doesn't mean "must" because the underlying assumptions could be wrong in that MySQL has an error in their implementation of the standard, your DBI mutates either the query or model, or you have users with duplicate nicknames. If the query does return differently, there are fewer areas where the problem could be not to mention the fact that you have much deeper problems than just having to change a query. That is the nice thing about declarative languages, the distance between "should" and "must" is reduced. Either it works and returns exactly what you asked for or it doesn't and your problem is somewhere in the model.
(Score: 0) by Anonymous Coward on Thursday February 02 2023, @10:12PM
I even proofread and missed one right at the end. Instead of "prod" that should have been "testing," i.e. the dev server.
(Score: 4, Interesting) by DarkMorph on Wednesday February 01 2023, @09:41PM (2 children)
As though all effort to actually continue making improvements had halted entirely. I wonder what the situation really is.
Unrelated, chromatic's book Modern Perl is a good read. It's freely available as a PDF but I went ahead and bought the actual book. Despite the radical appearance of its syntax, Perl is a remarkably powerful language. In a crude way, I find it embarrassing that given this language's age, all the newer competing languages don't even bother to implement even the simpler of highly desirable features. Who wants to write a series of values and deal with a forest of quotes when you can just use qw() and forego the quotes entirely...
(Score: 2) by quietus on Thursday February 02 2023, @08:48AM
I still use Steven Holzner's Perl Black Book (Coriolis Open Press, now defunct) as a reference -- empathically, for me, the best [intro to] programming book ever written.
(Score: 3, Insightful) by janrinok on Thursday February 02 2023, @09:24AM
It was without a maintainer.
The last developer (TMB) left us in the middle of 2021 at short notice. There has been nobody in the development team since that time. That is the reason so many people were pleased to see NCommander return - he at least knew most about how it had been built. But what he found surprised (and shocked) even him. Updates and bug fixes had not been implemented for a long, long time, ceasing long before the departure of TMB. The task that NCommander thought he was going to do, and the one that is actually required differed considerably.
It is a much bigger task than even he had imagined which is why, when combined with new and existing professional and personal commitments, it is taking far longer than anyone believed would be the case.
(Score: 3, Interesting) by coolgopher on Wednesday February 01 2023, @11:31PM (1 child)
There's more to keeping a site running than the code of the frontend and backend. If you're versed in automation or sysadmin, those might also be skills that are appreciated here. And of course, everybody likes someone who can take rough technical notes and turn them into usable documentation!
(Score: 3, Informative) by janrinok on Thursday February 02 2023, @09:28AM
We are currently have 2 new sys-ops volunteers who will be joining us shortly. The problem is NC finding enough time to give them access and an introduction to the sys-ops area.
(Score: 5, Insightful) by jelizondo on Wednesday February 01 2023, @04:11PM
Thank you for your efforts on our behalf.
I wish I could do more than just suscribe and moderate, but such is life.
(Score: 3, Funny) by Anonymous Coward on Wednesday February 01 2023, @05:23PM
Hi NC, nice to hear from you. I'll add my thanks to the others, all your good work is appreciated. Time on SN is one of the nicer parts of my day.
But I can't resist responding to your comment on documentation, from tfa:
> ... so something beside me can actually maintain it.
I see you are looking ahead to an AI maintaining SN--very forward thinking(grin)!
(Score: 4, Insightful) by Barenflimski on Wednesday February 01 2023, @06:00PM
Appreciate your hard work!
(Score: 4, Insightful) by JoeMerchant on Wednesday February 01 2023, @06:49PM (3 children)
And: my sympathies. I launched my personal website in 1997, then got married a few years later, then got kids, then moved cross country twice and 100 miles about 10 years ago.
During all that, the personal website looks a lot like it did in 1998, but with various things tacked on here and there across the decades. I could probably cut the hosting costs from $200 per year to $50 or less, but at what cost of my personal time?
Speaking of which, it's long past time to contact the insurance company and re-classify myself as full time WFH... not sure what that will save, but probably a lot more than refining my web-hosting configuration.
🌻🌻 [google.com]
(Score: 1, Informative) by Anonymous Coward on Wednesday February 01 2023, @07:41PM (2 children)
> contact the insurance company and re-classify myself as full time WFH
Car insurance or homeowner/renter insurance??
I've always worked from home and I believe that my car insurance is cheap (for this part of western NY State) due to "pleasure use" only, low annual mileage and no commute. One of the pros of working from home, there are some cons too.
(Score: 2) by JoeMerchant on Wednesday February 01 2023, @10:38PM (1 child)
You know, there should be a break on Homeowner's too since the window for burglary break-ins is dramatically reduced... on the other hand, why would they offer a break for something their competitors aren't offering a break on?
🌻🌻 [google.com]
(Score: 0) by Anonymous Coward on Thursday February 02 2023, @12:24AM
> why would they offer a break for something their competitors aren't offering a break on?
Like other businesses, insurance companies love to get new customers, so the initial rate is attractive, then they ramp up over the years. To keep track of that, I use an experienced independent insurance agent. I lucked into "Joe" when I was personally shopping around for insurance, 30+ years ago, and I've followed him as he moved through a few different local agencies. To keep the commissions from my business, "Joe" shops around and he switches me to a new company every five years or so.
(Score: 5, Insightful) by pTamok on Wednesday February 01 2023, @07:32PM (3 children)
I wouldn't move from perl unless it is utterly broken. The first law of rural motor mechanics applies: "If it ain't broke, don't fix it."
It might be sub-optimal, but if it works, it has more going for it than unwritten and untested code. As you astutely point out, a higher priority is to document everything, so that you are no longer a SPOF. Rewrites and optimisation can come later.
There are many things that SoylentNews gets right: no javascript, and a moderation system that is pretty darn good. And no adverts!
Thank you again, and I hope the personal stuff is less overwhelming soon.
(Score: 3, Interesting) by DeathMonkey on Thursday February 02 2023, @09:21PM (2 children)
Define "broken." If you can't find Perl developers that sounds pretty broken to me!
Every time this topic comes up there are several people saying they are willing to help but they just don't know the tech.
Having such an incredibly feature-stable product to work from does make platform upgrades easier. Maybe it's time to just copy this exact same design onto something people know how to work with?
(just a thought, great job however you're doing it!)
(Score: 1, Interesting) by Anonymous Coward on Friday February 03 2023, @09:52AM
This project has three intersecting problems. 1) It is written in perl, which not a lot of people use and less use regularly everyday. 2) This website has a relatively small user base. 3) Some of the code and architecture is a beast and not the best to learn on. All three of those would make on-boarding difficult. There are things that can be done to make that easier, some of which NCommander is addressing, but it will be hard to overcome the big 3.
However, a total rewrite isn't exactly easy either. Before you begin, there is some serious questions to ask, such as "what language?" and "what architecture?" And I'm not sure those questions would even meet a consensus. Then you get the fun part of actually implementing it. The first 50% will probably fly by and feel great. But then you quickly start to realize why the 90-90 rule exists and that Hofstadter's law is always true. I'm not saying it can't be done, especially with a lot of existing work directly translatable, but there will be plenty of difficulty once you get to all the weird corner cases.
But if this site did decide on a rewrite, how sure could they even be that they would get developers for the new version? Two of the three main problems it has would still seem to apply.
(Score: 3, Interesting) by pTamok on Friday February 03 2023, @10:16AM
There is no lack of Perl developers.
However, there is a lack of Perl developers willing to work for free on a website where thanks are in short supply, and where there is plenty of kibbitzing, and a range of politically sensitive opinions. The problem is not Perl. Any Turing-complete language could be used, the problem is in finding people with the inclination and resources to follow 'the job' through and not give up in disgust, while keeping the website and community going. I'm not that person, for a variety of reasons, even though SoylentNews is one of the very few places on the Internet I choose to contribute to.
I have a great deal of respect for the people that do provide time and resources to keep the place going, despite the difficulties. Managing technical debt while providing a continuous service is remarkably difficult.
(Score: 4, Interesting) by quixote on Thursday February 02 2023, @04:20AM
Thanks to you, janrirok, and everyone who keeps one of the best sites on the web going!
(Score: 2) by janrinok on Sunday February 05 2023, @06:48AM
We have/had both. Currently with the rebuild taking place there is only 1 working system but that will change.