[Rescheduled to keep it visible--JR]
Introduction
For most people the holiday season is over. There are a few who have their winter holidays booked as we still have a few months of the skiing season to go yet, but I don't think that this affects any of our staff! So I offer a belated 'Happy New Year' and wish you all the very best for 2025.
Volunteers for the Board
Slightly less than 12 months ago I asked for volunteers to serve on the Board of SoylentNews and fortunately some people stepped forward and took on the 3 key roles (Chairman, Treasurer and Secretary). They have each contributed to the setting up of the site and getting us where we are today. However, they will soon be wanting to stand down from their current posts. The concept of the site is that the governance is provided by the community and that posts should be rotated occasionally. We are again seeking volunteers to assume one of the current positions. The roles are important, they are the most important posts on the site because without them there can be no site, but I don't think that they are particularly arduous. They are not roles that require a daily or even a weekly input. They maintain an overview of the site and they have an independent decision-making role in future site operations.
Volunteers for the posts should remember that they must be prepared to sign site legal business documents and therefore cannot maintain perfect anonymity. On the site we have not given any additional information other than their nicknames and user ids. Nevertheless, somewhere in the masses of paperwork and records that the US demands and maintains their names and contact details are recorded.
If you wish to volunteer for a post then you should have an account in good standing i.e. not banned or created within the last few months, and with a reasonable level of karma. Please volunteer either here in the comments or directly via email to admin@soylentnews.org. If you have volunteered for a post previously then it does not preclude you from volunteering again. If you have questions regarding a role then please raise them here. If appropriate, I will ask the person currently in that post to reply so that you get the information direct from 'the horses mouth'.
Once we have a volunteer or volunteers for a post we will hold an election for the community to approve and select a person for a post. This will be done openly and everyone with an active account created before the date and time that this Meta is published will have a single vote. The reason for this restriction is to prevent a mass of new accounts attempting to unfairly influence the outcome of the vote. The current Board will make the final decision on who is chosen.
Site Documentation
In December I published the new proposed documentation covering Policy, the Board, and other documents. Over the last few days the Wiki has been offline so I will repeat the links here:
- Soylent Phoenix - Policy
- Definitions and Common Terms
- Transfer of Assets Agreement
- Soylent Phoenix - Bylaws (including Board details)
- Soylent Phoenix - Tax Exemption Status
- Soylent Phoenix - Wire Transfers and Methods of Subscription
- Discussion Policy
It is 6 weeks since those documents were posted and I have included changes that have been proposed. There will be a vote to adopt them in the coming days.
Financial Statement
Dale, our Treasurer, is preparing a financial statement for our annual return to the IRS. We currently have $968.61. There was no money transferred from the previous site but we have received several donations and subscriptions. This is a healthy figure because our servers and data connections have also been donated by generous community members and so our outgoings are significantly less than they were previously. The spreadsheet can be found here. (Note that different pages can be selected using the tabs at the bottom of the display). Subscriptions and donations may be made using Paypal, Stripe or direct bank transfer. My grateful thanks go to Dale for his work on behalf of the site.
Future Plans
Improved Security and Accountability
Perhaps surprisingly, kolie discovered a significant security hole in the Rehash software which had been present since the original site began, and possibly from before that. Fortunately, there is no evidence that it was ever exploited. It has been fixed. Some parts of the code have never been worked on and it had been thought to have been secure when we first forked it. It appears to have never been fully tested.
Additionally, with the new software that is currently being written it will be possible for community members to have enhanced access via the site API. Some API functions will respond differently depending on the security level of the person accessing the site using it. As you can imagine this will require careful testing.
Some of you will have seen the software that will be used to remove spamming and doxxing information from public view. When the software is complete it will also give community members improved visibility on why some comments are removed from view. This will improve staff accountability to the community at large. Another benefit is that now nothing is actually removed from the database, it is only removed from display. It can therefore be restored should it be desired.
Rehash Code Rewrite
The Perl code, despite being very dated, is perhaps surprisingly well structured. It is possible that the Rehash code can be rewritten in a more popular and more supportable language function by function. This is a long term plan but it does appear to be a realistic one.
Suggestions
We have received a proposal that community members should have a better way of making suggestions for changes that will improve the site's function and use, rather than the current method of making a bug report. It is still only a proposal and we need to spend some time investigating the possibilities. Using the Wiki has been proposed and providing that we can securely protect the rest of the Wiki while granting access to community members to the Suggestions page it seems a good idea. The problem is that the Wiki is known to be vulnerable to external attacks and abuse unless a lot of additional software (and management) is employed. Leaving it open to ACs (and thus the whole world) will clearly not be possible so it has its a known limitation.
Anonymous Coward Contributions to this Discussion
It is a fact that if this discussion were to be open to ACs on the front pages it would quickly become a focus for Spam from a very small group of people. Therefore, the contents of this Meta will be reproduced as a journal belonging to "AC Friendly" [https://soylentnews.org/~AC+Friendly/journal/] and ACs will be welcome to comment there. Valid points of discussion will be copied across to the front page story under the username of "AC Friendly". If an AC wishes to respond to a specific comment then please link to that comment in the first line of your own comment. Spam in that journal will be treated appropriately.
(Score: 4, Insightful) by AnonTechie on Wednesday February 05, @04:11PM
Many thanks for the update. It is good to know that things are falling in place. Many many thanks for all your efforts. I look forward to many more submissions and informative discussions.
All the best ...
Albert Einstein - "Only two things are infinite, the universe and human stupidity, and I'm not sure about the former."
(Score: 3, Interesting) by hendrikboom on Wednesday February 05, @04:39PM (19 children)
That's something I've wondered about for a while.
* How feasible is it to do a incremental rewrite into a language with a greater tendency toward comprehensible, reliable code? How well would Perl interact with another language?
I don''t know Perl well enough to begin to answer this. And how well would Perl code interact with the data structures that are idiomatic in the other language?
* And what kind of language would be more appropriate? I'd want it to be statically and enforcably typed. Garbage collection is likely to be enough -- we don't need microsecond-scale responsiveness, so we don't need the bureaucratic lifetime management of Rust. My nominee for such a new language would be something like OCaml [ocaml.org]
(Score: 3, Interesting) by janrinok on Wednesday February 05, @04:53PM (1 child)
My own language preference would be Go, but I will be quite happy if another language is chosen. Go seems to be designed exactly for this role and is a relatively simple language for anyone to pick up. I know that others might disagree but I will see what they suggest instead. I would hope that those who argue for a specific language, particularly if it is obscure, will also be offering their time to help write the code.
I am not interested in knowing who people are or where they live. My interest starts and stops at our servers.
(Score: 2) by Undefined on Tuesday February 11, @11:27PM
This seems like it would be a good choice. It's open source and not huge, so it can be backed up in buildable form the version that's used to build the site to prevent developer-caused bitrot (as happened with the Python2==>Python3 transition); it's fast; and it's really good/fast/efficient at threading (Goroutines.)
My own usable expertise is in assembly, c, c++ and Python, but I have worked adjacent to Go programmers and been outright inundated with its benefits to the point of being well convinced. :)
(Score: 4, Interesting) by bzipitidoo on Wednesday February 05, @06:03PM
> How well would Perl interact with another language?
I can tell you from personal experience that the answer is "not well". It can be done, but it's a huge pain. This problem is one of the motivations that drove the creation of Perl 6 which has since been renamed to Raku. This problem is also a big reason why CPAN exists. CPAN has a huge collection of glue code to connect Perl programs to many popular C/C++ libraries. In some cases, a CPAN module is a rewrite in Perl of a C library, rather than glue code. That's great for connecting to popular libraries, but it's nigh useless (except as an example) if you're trying to connect to your own C code or some obscure C library. What is particularly disappointing about this is that Perl itself was written in C.
I needed to call some custom C functions from Perl. First, I read the docs hoping to find some direct way to do it. There is no such way. (Supposedly, Raku has a way.) Next, I tried SWIG. SWIG bloated the heck out of the code. 100k of additional source code just to call a C function from Perl! The solution that worked was to write a standalone C program linked to the C functions. The Perl program opened a UNIX socket and used system calls to launch the C program, passing along a command line parameter to give the C program the info it needed to open the other end of the socket and listen. The Perl side stuffed in all the data the C function might need, then waited until the C program sent back all that data with whatever alterations it had made.
(Score: 5, Insightful) by Unixnut on Wednesday February 05, @06:51PM
Quite frankly the answer to "comprehensible, reliable code" is to have better developers. I've written (and seen) many lines of very clear, comprehensible Perl code in my life. Likewise I've seen complete pigs breakfasts made out of all the other major programming languages out there. Including Python and its "there should be only one (clear) way to do something", which must have really taken a special kind of person to achieve.
As for reliability, Perl has been called many things by its detractors but "unreliable" is not one of them. Its an excellent language at what it is designed to do.
As for interacting with other languages, Perl is pretty much the same as the other interpreted languages. Frameworks for direct integrating with C are bloated (as is Python, the only other language I've tried it on), while the rest are non existent AFAIK. If you want to integrate with other languages you are better of writing your application to make use of internal APIs (pick something standard like JSON-RPC or well supported like ZeroMQ for example) and either network or socket based communication, and you can then have all different languages interact just fine.
That is one way I have done it in the past, while an alternative I used is to set up STDIN/STDOUT pipes between your code and the other code (After fork and exec-ing), and interact that way as you would through the terminal (this however is UNIX centric and you can't fan it out across a network later).
From my understanding its not so much that Perl is inappropriate (otherwise most of the dynamic web would not have been written in it originally) as much as there are not enough Perl developers willing to hack on the SN code (I have considered it myself, but truth be told I am way too busy as it is. Even my own open source projects have been dormant the last few years without me contributing to another one). As such offering an even more obscure language as a replacement does not seem like a good idea.
OCaml I think is just a bit too obscure a language. There is a small proportion of developers who know OCaml, and even fewer who know how to use it properly to its full abilities. Those that do can generally get very high paid jobs in the financial, defence, aerospace and other "high criticality" industries, so I am not sure how many of them would have the time and inclination to contribute their skills to SN.
If we are going to consider languages on merit alone, I would think Erlang [wikipedia.org] would be a better fit, as it seems to have been designed from the ground up for distributed/clustered network based applications, just what websites like SN are about.
However good luck finding decent developers in that (a shame really, as from what I've read I feel it may be the perfect language for the modern, web-based distributed technology world we currently inhabit).
As SNs issue is lack of developers with free time, they may well consider it best to just rewrite the thing in Python. Its the modern open source worlds version of "BASIC" at this point in time. Its simple enough for people to pick up, plus its still very popular. It is even taught as an introductory language in schools. So there is a huge number of people picking it up and who would like to hack on some code to improve their skills.
Likewise its tendency to enforce a single way of doing things (including up to code structure and whitespace) means it is easy even for non-expert developers to be guided into producing workable code, its relatively easy to do QA and review, and there is a plethora of linters and other tools to assist.
(Score: 1, Interesting) by Anonymous Coward on Friday February 07, @03:59AM (14 children)
Not expert, but IIRC a few years ago TMB (The Mighty Buzzard) being strongly in favor of perl for its rich string handling.
(Score: 5, Insightful) by janrinok on Friday February 07, @07:50AM (13 children)
That is true. But many of Perl's former advantages are much less important today because of the huge increase in computing power and improved programming languages since the turn of the millennium.
The problem is one of maintainability. There are simply too few people today who are using Perl. It is no longer popular nor is it taught in many universities or colleges. Despite its excellent string handling almost every popular language today can match it while at the same time incorporating more modern programming techniques as part of the language. Even the latest version of Perl is so different from the original that it warrants a new name. We are having to search for an old version of the language just to build today's software.
Every programmer has his favourite language or languages. It is natural that they would prefer to continue to program in the language with which they feel the most comfortable. But if that language has relatively few users then choosing it now would merely repeat the problem in years to come. My own view is that we should choose a language that is currently used by many sites as, in years to come, there will be more programmers who have had some experience in using that language even if it is superseded by something else.
A currently popular language would have another benefit. It is more likely that community members will have used that language and thus will be in a position to submit patches or to investigate bugs. With the extremely small programming staff that we have today that is also very important. What we also have to have is a system of continuous development/continuous integration (CD/CI) that is easy to use. That way, when staff change, it is easier for the new staff to continue to use the same system. It needs to be simple, effective and well documented. kolie is well on the way to ensuring that we have such a system.
I am not interested in knowing who people are or where they live. My interest starts and stops at our servers.
(Score: 5, Funny) by VLM on Friday February 07, @08:32PM (1 child)
The fun starts when you require special specific versions of add on libraries.
On Python you use venv and it "just works" in CD/CI pipelines.
On Perl you use, um, perlbrew, or plenv or Carton or App::Virtualenv or local::lib
Now I would opine, possibly even correctly, that App:Virtualenv is about as close to Python's venv as you will get and its main problem is the most recent release IIRC is 8 years old.
I wrote a ton of stuff in Perl "back in the day" and made well over a million dollars from it (not one lump sum, LOL, but over a decade or so, sure) However even I can't write stuff in Perl anymore.
I will say the people that wrote absolute shite code in Perl 20 years ago (whom are both "not me" and are the cause of complaints about Perl code quality) are almost entirely writing either Python spaghetti code now, or are heavily involved in Rust.
(Score: 2) by Undefined on Wednesday February 12, @12:00AM
The most reliable projects I've been involved with avoided using non-project outside libraries as much as humanly possible. Many times I've seen problems crop up due to library functionality that the original library maintainers either aren't motivated to fix, aren't around to fix, or will fix "sometime in the future." Every time we incorporated some black box, the project opened the door to yet another way to ghost up very difficult — even impossible — to fix problems.
Then (if you have the right version of the library code and someone who is willing to dig into it) you get to fix it yourself, and then the original maintainers update the thing without your fixes/patches and your version is replaced with it (always "because reasons") and all the problems you solved are back and broken just as bad — or even worse. And/or things you used are deprecated. Or gone.
Rehash is a relatively small project from my POV. I've written much larger projects on my own, although only one of the big ones was in Perl (and that was a very long time ago... I can no longer claim authoring expertise in Perl.) It shouldn't be that difficult to detail/specify the current Rehash functionality and then write it out fresh and largely self-contained.
Janrinok suggested Go as the (relatively) modern language to use; that seems like something really worth talking about. Among other benefits, it's a compiled language, so it is generally fast and its code can be extensively self-documented without adding executable weight as with scripting languages such as nominal Python and Perl. While speed isn't all that much of an issue these days with the incredible levels of compute power available, it's never a bad thing. Ditto RAM consumption. It's open source as well, and not all that large, so it can probably be kept available in stable, archived form so the Go developers don't accidentally [cough] throw sand into the gears.
(Score: 4, Informative) by bzipitidoo on Saturday February 08, @11:21PM (7 children)
How about a few numbers? How many lines (or bytes) of Perl code are we talking about? I have not looked around for a repository. Is there one, and if so, where is it?
> nor is it (Perl) taught in many universities or colleges
That's the kind of wrong thinking that we see from employers. Focus way too much on experience with a very specific version of a language. Programming is more universal than that. At the uni, programming is what should be taught, not specific programming languages. I really don't see it as any big deal to pick up a programming language such as Perl. A really good programmer won't be stopped by that. So I do not see a lack of Perl programmers really being a problem. Porting to a whole other language though, that's asking a lot.
(Score: 3, Informative) by janrinok on Sunday February 09, @04:10AM (6 children)
https://github.com/SoylentNews/rehash [github.com]
I am not interested in knowing who people are or where they live. My interest starts and stops at our servers.
(Score: 4, Informative) by bzipitidoo on Monday February 10, @07:24PM (5 children)
Okay, so about 64,000 lines of Perl code (some of which is comments) spread across 52 files. Skimming it very briefly, I saw some story and user handling, HTML construction, and database access and maintenance. Probably some user authentication and persistence (via cookies) in there. Also doubtless much spam filtering.
At heart, the code must get story and user info, from a database, and dynamically construct a webpage out of that for Apache to serve. The webpage uses the browser's textbox to collect comments, and that has to go into the database. Lot of details to all that. Such as, ignoring malicious spamming. What if some legit user is hacked, and the account is abused in an attempt to break the site somehow? I have seen the "slow down cowboy" message on the green site, and I guess that is intended to prevent a malicious actor from spamming the site with 100s of posts per second. All in all, a fair bit of functionality to port to another language. And the reason to contemplate a port is simply that Perl has lost popularity? Seems that good reasons to port are to deal with bit rot or language deficiencies that severely impact performance or usability or maintenance. Perhaps the easiest language to port to is a successor to Perl, that is, Raku. But I regard Raku as still too new and unpolished.
(Score: 2) by janrinok on Tuesday February 11, @07:33AM (4 children)
Another reason to rewrite is that nobody wants to work on old Perl code. Not only to maintain it, but to improve it and add new features. If you are offering to join the dev team alongside kolie then I think your offer will be gratefully received.
I am not interested in knowing who people are or where they live. My interest starts and stops at our servers.
(Score: 3, Interesting) by bzipitidoo on Tuesday February 11, @09:23PM (2 children)
My main hesitation is that I am badly pressed for time. Yeah, I could help, if I can find time. I have even used CPAN's DBIx, 15 years ago, on a gig. We used it to communicate with the Informix database engine.
But where do people want to take the code? Does the Perl code need cleaning up? Are there a few kludges in there that would be nice to rewrite, for performance reasons? And what new features are wanted? Or, do people want to start porting as is, and if so, to what? Go, you said. Someone else mentioned Erlang, and OCaml was also mentioned. I have not used any of those languages, but that's no problem, I can pick up whichever language is wanted. I mentioned Raku. Checking on a little something about Raku, I learned Apache has no mod_raku. But then, there's no mod_go or mod_erlang either. Is there any thought of ditching Apache too, and use Go to serve web pages directly? Is the LAMP stack still the premier way to host a web site, or is that now dated? The existence of mod_perl was, I'm sure, _the_ reason for using Perl in the first place.
(Score: 2) by Unixnut on Wednesday February 12, @10:56AM (1 child)
Alas it is the same situation with me, I would like to help but I am badly pressed for time. I keep thinking "when things calm down" and I have some free time to code for fun I would have a look, but things are just getting more hectic with time.
Thing is Perl is still in very high demand, in fact as fewer people learn Perl nowadays it feels like demand is going up, admittedly mostly to handle legacy code or to port it to something else due to lack of developers (companies want a popular language so they can get cheap coders). I actually started as a Python developer but picked up Perl a few years ago.
If you have a good grounding in comp-sci and motivation you can pick up any language. Perl if anything is the most different to the lot of them (to me in a good way) perhaps because it was designed by a linguist? Once you understand the thinking behind its design its the most enjoyable language to code in I've ever picked up, not sure why it is so much maligned. Outside of work I write most things in Perl (with occasional C/C++ when performance is paramount).
As for web coding, that is something I don't do much nowadays (most of it is backend/automation/devops type stuff) so I've stuck with Perl+CGI for small to medium sized applications.
Things however have moved forward with Perl web development, the main option I've heard good things about is Plack [plackperl.org]/PSGI [metacpan.org], where you can even get web servers with embedded PSGI (so you are not limited to apache/mod_perl). In addition there are some web frameworks that can assist with large web applications (e.g. see here for examples [linuxlinks.com] ).
From what I remember of the SN codebase, the main complaint was that it relies on some ancient perl-isms that Perl modern interpreters no longer support, requiring them to run an older unsupported version of mod_perl/apache and all the headache that causes. Is that still the case?
(Score: 1) by btsfh on Friday February 14, @01:33AM
The challenge is that perl folks are increasingly expensive as it declines in popularity. For a low budget nonprofit organization relying on the goodwill of volunteers, the goal should be to go with the easiest (most popular) language rather than the most optimized. CPU’s and RAM are cheap these days, but skilled developers will always be expensive.
(Score: 1) by btsfh on Friday February 14, @01:29AM
The last time I asked someone to update some old perl code to support ipvSucks(ipv6), i gained an enemy for life. He ended up taking a few months to completely rewrite the requirement in Python. On the bright side, the new Python code is beautiful and easy to maintain. As a corporate drone, it is usually easier to look for skills in “popular” languages than to build artisinal bespoke code.
(Score: 4, Insightful) by Freeman on Thursday February 13, @03:03PM (2 children)
Thinking about the things like:
It doesn't sit well with me that they are not viewable by users. The practice is ripe for administrative abuse. I don't mind them being treated as such. However, allowing users to click the message link and being able to see that indeed it was poop. Would alleviate my concerns.
Joshua 1:9 "Be strong and of a good courage; be not afraid, neither be thou dismayed: for the Lord thy God is with thee"
(Score: 3, Interesting) by janrinok on Thursday February 13, @03:34PM (1 child)
It will - I am still writing the software. What we have today is a way of doing soft deletes (i.e. nothing is actually deleted from the database, it simply doesn't display). In the past spam data was permanently deleted from the database.
I am writing an admin interface (and learning many new skills as I go - this is not my speciality - but we no longer have a large programming team). Currently it is 2 people, kolie and myself. And we are both wearing several hats. This is only one task that I am working on. We cannot do it on dev because there is no spamming on dev and I need a lot of data to work with. If an administrator cannot flag spam, review it and possible restore then it is unusable. Not all admins are programmers and the admin software has seen very little change since the site began and we need to have something that is usable by any administrator. Knowing exactly what we want the software to do and how to display the information we have requires that we start using it, and that is exactly what we are doing.
Our spammer is posting lots of spam everyday. I have code that can detect spam and identify the spammer, it can show me what it contains and allows me to carry out basic functions. I have not yet started on code to review and/or edit spam and remove doxxing content. Only when we reach that stage can we identify what information will be available to the community through their interface. There is no point, for example, in removing doxxing content and then flagging it up for everyone to see. That rather defeats the purpose.
If you want to see what the spam looks like I can make a post containing some.
I am not interested in knowing who people are or where they live. My interest starts and stops at our servers.
(Score: 2) by Freeman on Thursday February 13, @04:51PM
Ah, the doxxing thing is definitely something that we want to be poofed from existence. Thanks for the reply!
Joshua 1:9 "Be strong and of a good courage; be not afraid, neither be thou dismayed: for the Lord thy God is with thee"
(Score: 4, Informative) by VLM on Friday February 07, @08:41PM
Really, nobody?
I think the problem is the most "talkative" "involved" posters are probably the most controversial. If I volunteered (and I don't have the time for this stuff...) I would either have half the site vote against me or I'd feel obligated to no longer interact with the site, and I don't like either idea.
Strange idea: Look outside, like how corporate boards like to include outsiders (sometimes, anyway). My wife could probably do any of those jobs after being in the leadership teams of multiple girl scout troops, although she's not into tech SN stuff at all. Dealing with the worst of you can't be as bad as dealing with some of the other Scout moms, I'm sure she could handle it. Also we could fundraise by selling cookies. A strange but fairly serious idea. I wonder if this is a "startup idea". I was a treasurer of a scouting org back in the day, and the best fellow treasurers I met were just dudes trying to set up an accounting small business, not scouting dads who coincidentally invest as a hobby and played a hell of a lot of Railroad Tycoon as a kid. Although RRT2 the sequel was probably a gateway drug from computer games into the exciting world of finance and accounting; I wonder how many MBAs secretly played RRT2 as kids...
(Score: 3, Informative) by shrewdsheep on Saturday February 08, @12:26PM (3 children)
Please keep this topic fresh, maybe through regular Journal entries. I believe many here are committed enough to step in if otherwise thing would break down but would over-commit themselves time-wise in doing so (myself included). I believe it would help to put tasks on the wiki together with the time budget. Maybe also short tenures such as 6 months might be something to consider.
(Score: 3, Informative) by janrinok on Saturday February 08, @03:29PM (2 children)
There is no minimum tenure other than that we have to comply with US business regulations. One of the first tasks of a new committee is to update all of the official documentation.
I am not interested in knowing who people are or where they live. My interest starts and stops at our servers.
(Score: 2) by fliptop on Sunday February 09, @04:23AM (1 child)
For the code or business?
Our Constitution was made only for a moral and religious people. It is wholly inadequate to the government of any other.
(Score: 2) by janrinok on Sunday February 09, @04:43AM
For the business. The Board has no role in writing the code. The business function of the site is a vital, but completely separate, task.
The documents that need updating are the records of the Board composition, and the bank details and access to the finances. It is not a lot of work but it has to be done.
I am not interested in knowing who people are or where they live. My interest starts and stops at our servers.
(Score: 5, Interesting) by btsfh on Wednesday February 12, @02:15AM (4 children)
I am willing to serve as chairman if noone more qualified is available. I have previously served as treasurer of a 501(c)3 with zero staff and would prefer to not be the primary finance person again, and my ability to create minutes is rusty but would not preclude me from acting as secretary in a pinch. I have no objections to my name being on paperwork, or on the officers page, and would love to see how we can further improve SoylentNews in the future.
(Score: 3, Touché) by janrinok on Wednesday February 12, @02:53AM (3 children)
Noted - thanks.
I am not interested in knowing who people are or where they live. My interest starts and stops at our servers.
(Score: 2) by janrinok on Thursday February 13, @08:51AM (2 children)
I'm not sure why this warranted a 'Touche', but that is probably my own views on what 'Touche' is intended to indicate. I haven't taken any offence at receiving it.
I have exchanged emails with the volunteer and his desire not be involved with the actual book-keeping is noted. My brief response was not intended to discard his offer merely to indicate that I had seen it.
I am not interested in knowing who people are or where they live. My interest starts and stops at our servers.
(Score: 3, Insightful) by acid andy on Thursday February 13, @12:49PM
OK. I wanted to give you an upvote for acknowledging the volunteer and moving things forward but did not think Insightful or Interesting were really applicable. I appreciate that "Touche" was historically a term used in supposedly respectful combat between two individuals, and more recently in a lively, competitive back and forth in dialog. However, I did not really mean to imply that you were being in any way combative or competitive. It was a jokey choice of mod to upvote your brief response.
You did not in any way come across as discarding the offer. Given the context it is clear it will be considered.
If I had to mod this again I think Informative might have been a safer choice!
Phew! Hope that it is all cleared up now. I am slightly embarrassed that my only contribution to the topic is this.
Welcome to Edgeways. Words should apply in advance as spaces are highly limite—
(Score: 2, Insightful) by btsfh on Friday February 14, @01:22AM
I wouldn’t worry much about it. The fact the community interacted is a good thing, and the list of notes is both entertaining and extensive. At least one individual left a note about their moderation, which made sense to me. When in doubt, assume the best intentions from folks. It keeps the blood pressure lower. :)