SoylentNews is people
SoylentNews
I've been approached about working on a new privacy policy for SoylentNews and have agreed to do so. This journal is the first step in that process.
SN currently runs on Rehash, which is written in Perl and dates back to Slash 2.0. Many privacy-related considerations in Rehash are dictated by decisions made by the Slashdot admins nearly 25 years ago when they wrote the original code. The age of this code and its dependencies on tools like mod_perl make it nearly unmaintainable, meaning that SN may implement a new code base sooner rather than later. This is a pivotal time to discuss a new privacy policy for SN, an the decisions made now will likely influence the implementation of whichever new code base powers SN in the future.
SN has three primary stakeholders, which are 1) the ownership, 2) the staff, and 3) the community. To be successful, any site policy needs the support of all three of these stakeholders. That means the community needs to be actively engaged in the process.
My first steps will be to solicit input from the SN community and to spend most of my time listening. There are three important questions to discuss:
1) Problems: What privacy-related considerations are important to you, the members of the SN community? What are your concerns? As long as the issues are reasonably relevant to privacy, anything should be on the table here. This includes things like what user data gets stored, how long it is retained, who has access to it, the right to be forgotten, anonymous commenting, and anything that can reasonably be construed as a privacy issue.
2) Process: All three stakeholders must be supportive of any privacy policy for it to be effective. Therefore, once a privacy policy is drafted, we need a process for all three stakeholders to approve this. I anticipate the biggest questions here will be how you, the members of the SN community, get to voice your support or to request amendments to the policy. What process would the community like us to follow for enacting policy? Do all logged-in users get to vote? Does the community elect representatives?
3) Potential Solutions: Once you, the members of the SN community, make your privacy concerns heard, we need potential solutions for those concerns. These solutions will be limited by a few constraints. To allow for robust discussions and make SN a welcoming community, we need the ability to track abuse of the site (e.g., spam comments, sock puppet account creation, gaming the moderation system, etc...) to prevent disruption of the discussions. SN is required to comply with the laws in relevant jurisdictions such as the United States and the state of Delaware. Any solutions have to be practical, given the limited financial and human resources. Working within those constraints, SN policy should go above and beyond what is merely required by law, and to maximize the privacy of the members of the community.
I'll start by posting three journals at least 7-10 days apart to discuss each of these issues. For this journal, I want to focus on the first point, which is what privacy concerns you have, What is important to you, as members of the SN community, and what do we need to address in the new privacy policy? While any discussion of privacy matters is on-topic in this journal, I'd like to try to keep the discussion focused as much as possible on privacy-related problems that we need to address.
There are a few ground rules in this discussion:
1) If you're giving examples of specific privacy concerns, please don't include actual user names or people. Please use hypothetical terms, or use generic names like "person A" and "person B."
2) The new privacy policy is forward looking, meaning that the discussion should focus on how we can be better in the future, and not on holding people responsible for past mistakes or how the existing code is written.
3) Please keep the discussion civil and welcoming. Everyone deserves a chance to participate in this discussion and to be heard. Please keep the discussion constructive and refrain from posting personal attacks. Privacy is for everyone, and that means everyone deserves to be heard. I ask that you please don't try to dominate the discussion or shout other people down, and instead let everyone make their opinions known.
4) Please keep the discussion on-topic. Any privacy-related matters are on-topic, but issues like story selection are beyond the scope of this policy. Let's keep issues like politics out of this discussion, too.
5) Please don't moderate people down unless they're off-topic, trying to dominate the discussion, shouting people down, or posting personal attacks. Even if you disagree with someone else, please don't moderate them down unless they're violating the ground rules for this discussion. I want everyone to be heard.
I pledge that I'll read every comment that you post. My direct input to this discussion will be minimal, and I probably won't post at all except maybe to answer questions or ask for more detail if appropriate. I'm not here to debate with people. I just want to listen to your concerns. Anonymous Cowards are welcome in this discussion, but all comments that I post will be from the dalek account. I have unchecked the "willing to moderate" box in my user preferences, which means that I am not moderating any comments in this discussion. I am just here to listen.
I want to make these discussions as inclusive as possible. That means I intend to allow Anonymous Coward input to all of these journals. In exchange for keeping these discussions open, I ask that you please keep these discussions on track. I will post future journals, but for now, I want to know what your privacy concerns are, and what topics we need to address in the new privacy policy.
(Score: 2, Informative) by dalek on Tuesday May 30, @11:54PM (10 children)
I don't have a whole lot of experience with Perl, but I did look over the Rehash code several times to try to understand how parts of it worked.
One issue I'm aware of is that Rehash requires mod_perl and that it be running on Apache 2.2. This is out of date, I believe Apache 2.2 is unsupported, and my understanding is that changes to the code would be required to make it work on Apache 2.4. I have very little experience with mod_perl, so I'm not the right person to explain what these changes would entail.
I didn't think Perl was especially difficult to understand, so I don't think the problems are necessarily inherent to the programming language, except for the mod_perl dependency. The code is divided into several modules (https://github.com/SoylentNews/rehash/tree/master/Slash [github.com]), which is a reasonable design decision. But that also means that there needs to be some documentation on what functions are provided by each module and how those functions are expected to behave.
If I write a class in C++, any code using the class doesn't really have a need to know how the class works or the details of private functions and variables. However, I do need to define the expected behavior of public and protected functions and variables. It means that I know exactly how to use the class in other code because I know what the functions and variables do, and how they're expected to work. Having a well-defined interface also means that as long as I don't modify the expected behavior of the existing interface, I can update the class without breaking other code that depends on the class. I don't believe those sorts of well-defined interfaces and relevant documentation exist for Rehash. It means that if I start modifying how one module works, I have a high risk of breaking things elsewhere in the code. Similarly, I don't think there's a whole lot of documentation on what is actually stored in the database.
I think that if you work with Rehash enough to become familiar with what various parts of the code do, it's probably something that can be maintained. But an important first step would be to go through and properly document the various modules. I suspect that doing this and updating Rehash to work with Apache 2.4 would require a significant investment of time.
I don't think there's anything inherently wrong with Perl, though I don't really use it for any of my projects. When I looked over the code, my biggest concern was understanding how all of the pieces of the code fit together, how each module is expected to behave, and what all the tables and fields in the database do. This is just my opinion, and like I said, I have very limited experience with Perl. I could also be wrong about some or all of this, so other people might be able to give better answers.
EXTERMINATE
(Score: 2) by RS3 on Wednesday May 31, @01:38AM (9 children)
Spot on, on all fronts. I would not choose perl for a new project, but that said, I'm not sure what I would use, as every "back end" scripting language has pros, cons, becomes "viral", becomes "deprecated". IE, there's no such thing as "future proof", so I'm not sure how one would decide.
I know php is both loved and hated. Most of the haters are latched on to 20 years ago. A huge percentage of the web runs on php, so it can't be all that bad. I've been admin some servers including WordPress so I know some php, certainly setting it up, "tuning" it, etc. Current WordPress runs well on a very wide range of Apache, php, and mysql versions, so it is possible to have code that isn't too terribly version picky.
Again, everything you said about rehash, and another big problem is with mysql calls and lack of compatibility over versions. I don't know who (what kind of person) gets involved in a project like mysql, and decides it's okay to break older calls in a version update. I'm okay with augmenting function (method) calls, but flat-out breaking something is stupid.
Back to the original point: I'm doing a few quick searches and I can't get a solid picture of whether fastCGI is better than mod_perl.
Just as a very general statement: I'm not fond of people saying that something is "unmaintained". It might be that it's done and ready for use. :) We're all so overly used to being the beta test for pretty much all code, and we're all paying the price for it. I'd rather a global paradigm of code being tested properly before shipping. I know that would be difficult to do, economically, because things have eroded to where they are (especially MS OSes- more and more and more frequent and bigger and bigger updates). For sure, if something is in use, has problems, and the company / author isn't developing / maintaining / even reachable, then that's a problem, and since that's always a possibility, we're all nervous to use something that seems stale. But again, it might be mature and pretty solid, and maybe check the bug list (if there is one) to see how bad it is.
(Score: 1, Insightful) by Anonymous Coward on Wednesday May 31, @07:18AM (8 children)
The main problem with mod_perl is that it is exclusive to Apache httpd. Also that apparently some amount of internal server details are leaked to scripts so you apparently can end up with programs that only work with specific versions of Apache httpd. If you're actually writing a new web service in perl, use something like PSGI so you don't need to care about the actual mechanism that connects your application to the web server.
An incomplete and mostly wrong history lesson is in order!
In the glorious days of yore, the World Wide Web is born. A bunch of people writing web servers get together and come up with CGI to enable the web to interface with other systems. Perl quickly becomes popular for writing CGI programs. Life is great and everyone is happy.
Some time later, Netcraft confirms that September 1993 indeed never ended. Web servers are buckling under weight of several hundred AOLers each getting their own perl camel to personally handle their requests. FastCGI, which despite the name is nothing at all like CGI, is developed in an effort to address this problem.
Perl CGI programmers revolt, FastCGI is too hard in mid-1990s Perl, and rewriting working programs is silly. So mod_perl is born, which can run normal CGI perl scripts but uses one camel for many requests and is therefore much less messy. Programmers being programmers, mod_perl is then extended with zillions of extra hooks and features to cater to various niche use cases.
Later, Apache httpd falls from grace and nginx rises as the new king of web servers. Religious leaders preach that mod_perl is the product of the devil, while FastCGI is given to us by God. Moreover, all remaining perl programmers have finished their grey beards and can't be bothered with the web anymore.
(Score: 2) by RS3 on Wednesday May 31, @02:33PM
I'd love to know who you are. I can't thank you enough! I started in Linux / web 1994-5 ish, including setting up some local / experimental web servers, but I tend to do many things, so I didn't specialize / immerse enough to get deeply into the subculture. I knew of perl and CGI, but just "played" to see that it works. More recently, 2008 and forward, used some Matt Mullenweg toys like "formmail", and they work. Most of what I've dealt with is php-based, WordPress, Joomla / Drupal, and several specialty market CMSes like one for real estate (I don't know what ever happened with that- I don't do sales, customer contact, etc.)
One of the servers is on one hand embarrassingly old hardware, but at the same time I'm proud of how well it runs and fast it is, because I'm a relentless preener / tuner. Anyway, I've experimented a good bit with nginx and I found it a bit strange to configure (of course one can learn and get used to almost anything) but the bottom line: no performance improvement at all. If admin was a full-time job (and I've tried) things would be different, but I'm in a "do as much as you can for as little time & cost as possible" situation, so I can't research and play like most full-timers can. And I have shrinking interest in it, as I've often invested time and effort in things that go away, like Novell and buggy whips (why would someone whip a buggy though?).
You probably know that php can get a poop-ton of info out of Apache. IIRC much of that can be disabled in Apache conf.
I hadn't heard of PSGI, off to study up. Thank you!!
(Score: 2) by RS3 on Wednesday May 31, @02:35PM (4 children)
BTW, do you have any thoughts / suggestions for a better language to run a site like this? (there is no wrong answer, just curious)
(Score: 3, Informative) by bmimatt on Wednesday May 31, @10:29PM (3 children)
I am not the AC ^^, but I'm in consulting business and have been recommending/deciding on language choices for a couple decades and your question cuts to the root of the Perl issue, hence my response.
Whenever trying to decide on/recommend a language for a new project, one of the key questions is: how big does the potential maintainer pool is today, will be in 5, 10 years; how easy will it be for you to hire/train new developers down the road.
Languages like Python, ruby or (the dreaded) javascript have large enough young developer pools. I'd seriously consider Rust and Go if a more industrial grade language is preferred.
(Score: 2) by RS3 on Thursday June 01, @12:29AM
So COBOL then? :)
Seriously, that's really good wisdom and almost sounds obvious now that you've stated it. I wasn't even thinking of Go or Rust for back-end, but pretty much anything can be back-end these days.
Sometimes I cast javascript in a negative light, but really it's what the browser and OS allow javascript to do that I see as a potential problem. At some point it's best to run a browser in its own sandbox / VM, with only data pertinent to that usage contained in that VM.
(Score: 0) by Anonymous Coward on Monday June 05, @08:05PM
> seriously consider Rust
At the risk of coming over crabby, nobody should be seriously considering Rust™.
(Score: 2) by replic8tor on Saturday June 17, @02:04AM
Javascript ( TS ) - probably the fastest way to add code to something - tons of libs - a bit of a mess to code with and easy to shoot in the foot. great for prototyping
Python - not the worst choice - cleaner than JS but perf wise probably worse
Ruby - other languages better in every way
Go - ehh a mess - pretty stagnant in terms of growth - smaller community than the above
Rust - Fixes a lot of goes problems - fast as f - great eco system - coding is slower but less debugging - growing community and adoption
(Score: 0) by Anonymous Coward on Wednesday May 31, @10:52PM (1 child)
Nice fanfic but FastCGI was released publicly after mod_perl.
(Score: 0) by Anonymous Coward on Tuesday June 06, @07:30PM
As it comes from a proprietary software product, the very early history of FastCGI seems a bit lost to time, but I don't believe it is accurate to state that mod_perl predates FastCGI in any meaningful way.
This whitepaper[1] is dated April 1996 and mentions that FastCGI support is available in Open Market WebServer V2.0. We can also find the "Open Market FastCGI 1.0 Programmer's Guide[2], dated April 15, 1996, which describes a C library to adapt your existing C programs and a modified perl interpreter needed to use their new FCGI perl module. I'm was unable to find an exact date when Open Market WebServer V2.0 released but it is presumably around the same time as all this documentation. It is almost certain that Open Market's customers had some early access well before this date, and probably there was some hype around it in advance of the release, but hard to know for sure. Could probably dig through usenet archives to find more.
On the other hand, Apache has a pretty detailed history article for mod_perl[3] which says that the first ever code published was in March 25, 1996. Yes, that is 3 weeks earlier than April 15, 1996, but according to that same article it wasn't really usable at all until August of that year, and it wasn't until March 1997 (a full year after the first postings) that it was even possible to use CGI.pm with mod_perl, which basically the point when people could actually consider switching existing perl-based CGI systems to mod_perl.
So yes, while people might have started working on mod_perl a few weeks before FastCGI support was shipping in a widely-available commercial web server, mod_perl was not really useful until a full year later when it could actually run people's perl CGI programs.
[1] https://web.archive.org/web/20000816193415/http://fastcgi.com/devkit/doc/fastcgi-whitepaper/fastcgi.htm [archive.org]
[2] https://web.archive.org/web/20001018200938/http://fastcgi.com/devkit/doc/fastcgi-prog-guide/cover.htm [archive.org]
[3] https://perl.apache.org/about/history.html [apache.org]