SoylentNews is people
SoylentNews
Site News
Join our Folding@Home team:
Main F@H site
Our team page
Support us: Subscribe Here
and buy SoylentNews Swag
We always have a place for talented people, visit the Get Involved section on the wiki to see how you can make SoylentNews better.
We have been informed by Linode (which hosts our servers) that there is some hardware maintenance being performed tonight. The impacted servers are 'fluorine' and 'neon'. Here is the message we received:
Linode continuously monitors the health of our equipment and we've been alerted to a condition which affects the physical server on which your Linode is hosted. While we have determined that this is not an emergency, this should be addressed in order to optimize the performance of your Linode. We have scheduled a maintenance window for the physical server on which your Linode is hosted:
Friday, September 16, 2016 at 1:00 AM EDT (5:00 AM UTC)
Downtime from this maintenance is expected to be no more than 1 hour. Please note, however, that the entire maintenance window may be required. Your Linode will be gracefully powered down and rebooted during the maintenance. Services not configured to start on a reboot will need to be manually started. If this time frame does not work for you, you have the option of migrating to another host which has these settings enabled.
Thanks to redundancy between our front end and database servers, our main site should remain functional. There will, however, be some minor inconveniences. During this period:
- we will not be able to process credit card payments,
- comment counts will not update, and
- emails and web notifications will not go out.
We appreciate your understanding and patience while the servers are being serviced.
We anticipate most of the affected services should auto-restart; those that do not will be addressed starting around 0600 CDT (0700 EDT / 1100 UTC).
UPDATE: All is shiny and happy again.
- Read More...
- 14 comments
from the int-21h-is-how-cool-kids-did-it dept.
I've made no secret that I'd like to bring original content to SoylentNews, and recently polled the community on their feelings for crowdfunding articles. The overall response was somewhat lukewarm mostly on dividing where money and paying authors. As such, taking that into account, I decided to write a series of articles for SN in an attempt to drive more subscriptions and readers to the site, and to scratch a personal itch on doing a retro-computing project. The question then became: What to write?
As part of a conversation on IRC, part of me wondered what a modern day keylogger would have looked running on DOS. In the world of 2016, its no secret that various three letter agencies engage in mass surveillance and cyberwarfare. A keylogger would be part of any basic set of attack tools. The question is what would a potential attack tool have looked like if it was written during the 1980s. Back in 1980, the world was a very different place both from a networking and programming perspective.
For example, in 1988 (the year I was born), the IBM PC/XT and AT would have been a relatively common fixture, and the PS/2 only recently released. Most of the personal computing market ran some version of DOS, networking (which was rare) frequently took the form of Token Ring or ARCNet equipment. Further up the stack, TCP/IP competed with IPX, NetBIOS, and several other protocols for dominance. From the programming side, coding for DOS is very different that any modern platform as you had to deal with Intel's segmented architecture, and interacting directly with both the BIOS, and hardware. As such its an interesting look at how technology has evolved since.
Now obviously, I don't want to release a ready-made attack tool to be abused for the masses especially since DOS is still frequently used in embedded and industry roles. As such, I'm going to target a non-IP based protocol for logging both to explore these technologies, while simultaneously making it as useless as possible. To the extent possible, I will try and keep everything accessible to non-programmers, but this isn't intended as a tutorial for real mode programming. As such I'm not going to go super in-depth in places, but will try to link relevant information. If anyone is confused, post a comment, and I'll answer questions or edit these articles as they go live.
More past the break ...
Looking At Our Target
Back in 1984, IBM released the Personal Computer/AT which can be seen as the common ancestor of all modern PCs. Clone manufacturers copied the basic hardware and software interfaces which made the AT, and created the concept of PC-compatible software. Due to the sheer proliferation of both the AT and its clones, these interfaces became a de-facto standard which continues to this very day. As such, well-written software for the AT can generally be run on modern PCs with a minimum of hassle, and it is completely possible to run ancient versions of DOS and OS/2 on modern hardware due to backwards compatibility.
A typical business PC of the era likely looked something like this:
- An Intel 8086 or 80286 processor running at 4-6 MHz
- 256 kilobytes to 1 megabyte of RAM
- 5-20 MiB HDD + 5.25 floppy disk drive
- Operating System: DOS 3.x or OS/2 1.x
- Network: Token Ring connected to a NetWare server, or OS/2 LAN Manager
- Cost: ~$6000 USD in 1987
To put that in perspective, many of today's microcontrollers have on-par or better specifications than the original PC/AT. From a programming perspective, even taking into account resource limitations, coding for the PC/AT is drastically different from many modern systems due to the segmented memory model used by the 8086 and 80286. Before we dive into the nitty-gritty of a basic 'Hello World' program, we need to take a closer look at the programming model and memory architecture used by the 8086 which was a 16-bit processor.
Real Mode Programming
If the AT is the common ancestor of all PC-compatibles, then the Intel 8086 is processor equivalent. The 8086 was a 16-bit processor that operated at a top clock speed of 10 MHz, had a 20-bit address bus that supported up to 1 megabyte of RAM, and provided fourteen registers. Registers are essentially very fast storage locations physically located within the processor that were used to perform various operations. Four registers (AX, BX, CX, and DX) are general purpose, meaning they can be used for any operation. Eight (described below) are dedicated to working with segments, and the final registers are the processor's current instruction pointer (IP), and state (FLAGS) An important point in understanding the differences between modern programming environments and those used by early PCs deals with the difference between 16-bit and 32/64-bit programming. At the most fundamental level, the number of bits a processor has refers to the size of numbers (or integers) it works with internally. As such, the largest possible unsigned number a 16-bit processor can directly work with is 2 to the power of 16 (minus 1) or 65,535. As the name suggests, 32-bit processors work with larger numbers, with the maximum being 4,294,967,296. Thus, a 16-bit processor can only reference up to 64 KiB of memory at a given time while a 32-bit processor can reference up to 4 GiB, and a 64-bit processor can reference up to 16 exbibytes of memory directly.
At this point, you may be asking yourselves, "if a 16-bit processor could only work with 64 KiB RAM directly, how did the the 8086 support up to 1 megabyte?" The answer comes from the segmented memory model. Instead of directly referencing a location in RAM, addresses were divided into two 16-bit parts, the selector and offset. Segments are 64 kilobyte selections of RAM. They could generally be considered the computing equivalent of a postal code, telling the processor where to look for data. The offset then told the processor where exactly within that segment the data it wanted was located. On the 8086, the selector represented the top 16-bits of an address, and then the offset was added to it to create 20-bits (or 1 megabyte) of addressable memory. Segments and offsets are referenced by the processor in special registers; in short you had the following:
- Segments
-
- CS: Code segment - Application code
- DS: Data segment - Application data
- SS: Stack segment - Stack (or working space) location
- ES: Extra segment - Programmer defined 'spare' segment
- Offsets
-
- SI - Source Index
- DI - Destination Index
- BP - Base pointer
- SP - Stack pointer
As such, memory addresses on the 8086 were written in the form of segment:offset. For example, a given memory address of 0x000FFFFF could be written as F000:FFFF. As a consequence, multiple segment:offset pairs could refer to the same bit of memory; the addresses F555:AAAF, F000:FFFF, and F800:7FFF all refer to the same bit of memory. The segmentation model also had important performance and operational characteristics to consider.
The most important was that since data could be within the same segment, or a different type of segment, you had two different types of pointers to work with them. Near pointers (which is just the 16-bit offset) deal with data within the same segment, and are very fast as no state information has to be changed to reference them. Far pointers pointed to data in a different selector and required multiple operations to work with as you had to not only load and store the two 16-bit components, you had to change the segment registers to the correct values. In practice, that meant far pointers were extremely costly in terms of execution time. The performance hit was bad enough that it eventually lead to one of the greatest (or worst) backward compatibility hacks of all time: the A20 gate, something which I could write a whole article on.
The segmented memory model also meant that any high level programming languages had to incorporate lower-level programming details into it. For example, while C compilers were available for the 8086 (in the form on Microsoft C), the C programming language had to be modified to work with the memory model. This meant that instead of just having the standard C pointer types, you had to deal with near and far pointers, and the layout of data and code within segments to make the whole thing work. This meant that coding for pre-80386 processors required code specifically written for the 8086 and the 80286.
Furthermore, most of the functionality provided by the BIOS and DOS were only available in the form of interrupts. Interrupts are special signals used by the process that something needs immediate attention; for examine, typing a key on a keyboard generates a IRQ 1 interrupt to let DOS and applications know something happened. Interrupts can be generated in software (the 'int' instruction) or hardware. As interrupt handling can generally only be done in raw assembly, many DOS apps of the era were written (in whole or in part) in intel assembly. This brings us to our next topic: the DOS programming model
Disassembling 'Hello World'
Before digging more into the subject, let's look at the traditional 'Hello World' program written for DOS. All code posted here is compiled with NASM
; Hello.asm - Hello World section .text org 0x100 _entry: mov ah, 9 mov dx, str_hello int 0x21 ret section .data str_hello: db "Hello World",'$'
Pretty, right? Even for those familiar with 32-bit x86 assembly programming may not be able to understand this at first glance what this does. To prevent this from getting too long, I'm going to gloss over the specifics of how DOS loads programs, and simply what this does. For non-programmers, this may be confusing, but I'll try an explain it below.
The first part of the file has the code segment (marked 'section .text' in NASM) and our program's entry point. With COM files such as this, execution begins at the top of file. As such, _entry is where we enter the program. We immediately execute two 'mov' instructions to load values into the top half of AX (AH), and a near pointer to our string into DX. Ignore 9 for now, we'll get to it in a moment. Afterwords, we trip an interrupt, with the number in hex (0x21) after it being the interrupt we want to trip. DOS's functions are exposed as interrupts on 0x20 to 0x2F; 0x21 is roughly equivalent to stdio in C. 0x21 uses the value in AX to determine which subfunction we want, in this case, 9, to write to console. DOS expects a string terminated in $ in DX; it does not use null-terminated strings like you may expect. After we return from the interrupt, we simply exit the program by calling ret.
Under DOS, there is no standard library with nicely named functions to help you out of the box (though many compilers did ship with these such as Watcom C). Instead, you have to load values into registers, and call the correct interrupt to make anything happen. Fortunately, lists of known interrupts are available to make the process less painful. Furthermore, DOS only provides filesystem and network operations. For anything else, you need to talk to the BIOS or hardware directly. The best way to think of DOS from a programming perspective is essentially an extension of the basic input/output functionality that IBM provided in ROM rather than a full operating system.
We'll dig more into the specifics on future articles, but the takeaway here is that if you want to do anything in DOS, interrupts and reference tables are the only way to do so.
Conclusion
As an introduction article, we looked at the basics of how 16-bit real mode programming works and the DOS programming model. While something of a dry read, it's a necessary foundation to understand the basic building blocks of what is to come. In the next article, we'll look more at the DOS API, and terminate-and-stay resident programs, as well as hooking interrupts.
- Read More...
- 2008 words in story
- 97 comments
from the Can-we-make-the-Top-400-by-Halloween? dept.
It has only been six short months since SoylentNews' Folding@Home team was founded, and we've made a major milestone: our team is now one of the top 500 teams in the world! We've already surpassed some heavy hitters like /. and several universities, including MIT. (But now is not the time to rest on our laurels. A certain Redmond-based software producer currently occupies #442.)
In case you aren't familiar with folding@home, it's a distributed computing project that simulates protein folding in an attempt to better understand diseases such as Alzheimer's and Huntington's and thereby help to find a cure. To that end, SoylentNews' team has completed nearly 16,000 work units.
If you'd like to contribute to our team by donating some spare CPU/GPU cycles, you can get started here. There are clients available for Linux, Windows, and OSX. Once you have installed the software, enter the TeamID 230319 to join us.
Feel free to join #folding on our IRC channel if you need any help, or just want to chat.
Thank you to all that have participated, and a special thanks to our top 10 folders:
- cmn32480
- Runaway1956
- Beldin65
- tibman
- LTKKane
- EricAlbers_ericalbers_com
- Kymation
- meisterister
- kurenai.tsubasa
- NotSanguine
Related Links:
http://folding.stanford.edu
http://fah-web.stanford.edu/cgi-bin/main.py?qtype=teampage&teamnum=230319
- Read More...
- 37 comments
In the ongoing battle of site improvements and shoring up security, I finally managed to scratch a long-standing itch and signed the soylentnews.org domain. As of right now, our chain is fully validated and pushed to all our end-points.
Right now, I'm getting ready to dig in with TheMightyBuzzard to work on improving XSS protection for the site, and starting to lay out new site features (which will be in a future post). As with any meta post, I'll be reading your comments below.
~ NCommander
- Read More...
- 36 comments
Are subjects passé in comments on the post-social media web? Or are they a valid feature to enable human eye-scanning and relevant search results?
It is the opinion of this anonymous submitter that putting "Subjects are an anachronism" [1] or "SubjectsinCommentsareStupid" [2] is unhelpful at best and spam at worst. SoylentNews has a long legacy going back to Chips & Dips, the predecessor site to Slashdot (from whose code SoylentNews was forked).
With that in mind, subjects are not a vestigial feature but a useful and defining one. It makes longer threads friendly to readers, and separates this site from Digg, Reddit, Voat, and so many other disposable social media sites. Just as email would be worse without subjects, so too would SoylentNews.
Ed Note: I'm of two minds as to running this story. This is presented as one person's opinion and makes a case for continuing to have a Subject for each comment. As noted, others do not feel the same way. As SoylentNews is a community, your input guides us. So, what say you? Should we continue as-is? Make subjects optional? Dispense with them entirely? Other? What benefits and/or problems are likely to result?
- Read More...
- 64 comments
So, during the last site update article, a discussion came up talking about how those who work and write for this site should get paid for said work. I've always wanted to get us to the point where we could cut a check to the contributors of SoylentNews, but as it stands, subscriptions more or less let us keep the lights on and that's about it.
As I was writing and responding to one specific thread, part of me started to wonder if there would be enough interest to try and crowdfund articles on specific topics. In general, meta articles in which we talk deploying HSTS or our use of Hesiod tend to generate a lot of interest. So, I wanted to try and see if there was an opportunity to both generate interesting content, and help get some funds back to those who donate their time to keep the lights on.
One idea that immediately comes to mind that I could write is deploying DNSSEC in the real world, and an active example of how it can help mitigate hijack attacks against misconfigured domains. Alternatively, on a retro-computing angle, I could cook something in 16-bit real mode assembly that can load an article from soylentnews.org. I could also do a series on doing (mostly) bare metal work; i.e., loading an article from PXE boot or UEFI.
However, before I get in too deep into building this idea, I want to see how the community feels about it. My initial thought is that the funds raised for a given article would dictate how long it would be, and the revenue would be split between the author, and the staff, with the staff section being divided at the end of the year as even as possible. The program would be open to any SN contributor. If the community is both interested and willing, I'll organize a staff meeting and we'll do a trial run to see if the idea is viable. If it flies, then we'll build out the system to be a semi-regular feature of the site
As always, leave your comments below, and we'll all be reading ...
~ NCommander
- Read More...
- 44 comments
from the fiddling-for-the-greater-good dept.
Since people seem to rather enjoy when I run articles on backend upgrades, here's another set of changes I made over the last week as I get back into the full swing working on the site.
The short list:
- Migrated Beryllium (which hosts wiki+IRC+mail) to Apache 2.4
-
- Upgraded said machine to PHP7
- Needed to support OCSP stapling
- Validating final checks before deploying HSTS to all public domains
- Upgraded MediaWiki, SquirrelMail, and YOURLS to PHP7 compatible versions
- Worked with TheMightyBuzzard and user comments to determine additional XSS protection headers we should deploy
- Found (and removed) SSLv3 support on postfix and dovecot
- Deployed DNSSEC on sylnt.us in preparation for signing soylentnews.org (here's the test results)
Read past the fold for more information.
Beryllium Upgrades
Beryllium is our "misc" services box. It basically hosts everything that isn't related to site infrastructure such as the wiki, our IRC server, and mail. Last week, I went through and fixed our SSL configuration on this machine to make sure that we were serving properly validated certificates, and that we had strong encryption on this box. While I succeeded on that front, for performance reasons, Apache 2.4 needed to be upgraded to support a somewhat obscure feature of TLS known as OCSP stapling.
What is OCSP stapling you ask? Well, to answer that, I need to take a moment to go into how SSL certificates work. Whenever a CA generates a certificate, they're essentially saying "this site is who it is and we're attesting to it". In a perfect world, a CA would never make a mistake, private keys would never leak, and we could always assume that a certificate is good. We don't live in that world, as such certificate authorities sometimes need to void a certificate. OCSP (which stands for the Online Certificate Status Protocol) is one of two ways to do this, and is the only method Let's Encrypt supports for certificate revocation.
OCSP is a replacement for older certificate revocation lists (CRLs) which in real-life rarely if ever worked as advertised. It's meant to allow the browser to update in real-time knowledge if a certificate is good or bad and react accordingly. OCSP however requires that the browser checks with a certificate authority's OCSP server, leaking the fact that user X is connecting to site Y. It also means that if access to the OCSP server is blocked, a user might not be aware that a certificate has been revoked. OCSP stapling solves both problems by having our servers grab the OCSP reply (which is timestamped), and sending it as part of the initial connection to our site, both increasing performance, and preventing a privacy leak.
Unfortunately, OCSP stapling requiring Apache 2.4 which required me to build it from source, and then migrate sites over from the older Apache 2.2 install. At the same time, I went through and upgraded PHP 7, and updated the other web applications we were using. For the most part, this was rather painless though I'm still tinkering with MediaWiki to make it happy on the new setup.
Beside the usual Apache pain, I went through and scanned our other major services and disabled SSLv3 support on postfix (SMTP) and dovecot. I need to go through and replace our self-signed certs with real ones here but that's a 'one step at a time thing'
XSS Mitigation
During the last site status article, an AC pointed us at this handy site showing security headers. As such, TheMightyBuzzard and I will be going through and enabling these (with the exception of public key pinning) on production sometime this week. HPKP requires quite a bit of planning to deploy and we're not ready to take that step just yet.
DNSSEC + sylnt.us
I've talked about wanted to deploy DNSSEC before, but various other things kept cropping up. That, and combined with outdated and misleading documentation kept me from actually getting around to doing this for ages. Over the weekend, I finally dug down and figured out the current best practices for DNSSEC, and with the help of audioguy, configured BIND to do automatic signing of the domain and uploaded our keys to our register.
As such, sylnt.us now has a fully validated signature chain, and a green key when checked with the DNSSEC validator. We will be signing soylentnews.org sometime in the near future, however, we ran into some DNS zone transfer issues between our nameservers and Linode which caused the RRSIG records to not properly upload. While this has been resolved for now, we're currently talking with Linode to understand why the transfer went pear-shapped and to prevent a second occurrence.
That's it for now. As always, post questions, comments below. I'll be reading!
~ NCommander
- Read More...
- 774 words in story
- 30 comments
So after an extended period of inactivity, I've finally decided to jump back into working on SoylentNews and rehash (the code that powers the site). As such, I've decided to scratch some long-standing itches. The first (and easiest) to deploy was HSTS to SoylentNews. What is HSTS you may ask?
HSTS stands for HTTP Strict Transport Security and is a special HTTP header that signifies that a site should only be connected to over HTTPS and causes the browser to automatically load encrypted versions of a website should it see a regular URL. We've forbid non-SSL connections to SN for over a year, but without HSTS in place, a man-in-the-middle downgrade attack was possible by intercepting the initial insecure page load.
One of the big views I have towards SoylentNews is we should be representative of "best practices" on the internet. To that end, we deployed IPv6 publicly last year, and went HTTPS-by-default not long after that. Deploying HSTS continues this trend, and I'm working towards implementing other good ideas that rarely seem to see the light of day.
Check past the break for more technical details.
[Continues...]
As part of prepping for HSTS deployment, I went through every site in our public DNS records, and made sure they all have valid SSL certificates, and are redirecting to HTTPS by default. Much to my embarrassment, I found that several of our public facing sites lacked SSL support at all, or had self-signed certificates and broken SSL configurations. This has been rectified.
Let this be a lesson to everyone. While protecting your "main site" is always a good idea, make sure when going through and securing your infrastructure that you check every public IP and public hostname to make sure something didn't slip through the gaps. If you're running SSLLabs against your website, I highly recommend you scan all the subjectAlternativeNames listed in your certificate. Apache and nginx can provide different SSL options for different VHosts, and its very important to make sure all of them have a sane and consistent configuration.
Right now, HSTS is deployed only on the main site, without "includeSubdomains". The reason for this is I wanted to make sure I didn't miss any non-SSL capable sites, and I'm still working on getting our CentOS 6.7 box up to best-practices (unfortunately, the version of Apache it ships with is rather dated and doesn't support OSCP stapling. I'll be fixing this, but just haven't gotten around to it yet).
Once I've fixed that, and am happy with the state of the site, SN, and her subdomains will be submitted for inclusion into browser preload lists. I'll run an article when that submission happens and when we're accepted. I hope to have another article this week on backend tinkering and proposed site updates.
Until then, happy hacking!
~ NCommander
- Read More...
- 472 words in story
- 62 comments
We just learned that our VM provider, Linode, had to perform some emergency reboots. Three of our servers have already been taken care of, but more are still to come. This led to our site being unavailable for a period of approximately an hour. Here is the reboot schedule:
Identified - Linode has received a Xen Security Advisory (XSA) that requires us to perform updates to our legacy Xen host servers. In order to apply the updates, hosts and the Linodes running on them must be rebooted. The XSAs will be publicly released by the Xen project team on July 26th. We must complete this maintenance before then.
Here's the schedule and status:
| Server | Purpose | Maintenance Schedule (UTC) |
|---|---|---|
| lithium | Development | Completed |
| magnesium | Frontend Proxy | Completed |
| sodium | Frontend Proxy | Completed |
| fluorine | Production Cluster | Completed |
| helium | Production Cluster | Completed |
| hydrogen | Production Cluster | Completed |
| neon | Production Cluster | Completed |
| beryllium | Services Cluster | Completed |
| boron | Services Cluster | Completed |
We apologize for any inconvenience.
[Update: It appears the second round of reboots has completed successfully, and, thanks to the advance notice, the site stayed up throughout. We anticipate that the site will still continue to operate normally through the last-scheduled reboot. Many thanks for your understanding and patience.]
[Update #2: We are taking advantage of a free offer from Linode, our hosting provider, to convert our VPSs (Virtual Private Servers) from Xen to KVM. The rebooting was required to repair a Xen vulnerability. As a bonus, the Xen to KVM conversion gives us a free upgrade to twice as much memory. The additional memory will provide much-needed additional headroom on our servers and possibly provide a performance improvement. Thanks to our redundancy, the changes should not be noticeable when we reboot/upgrade, except for the IRC and e-mail servers as they are single-hosted.]
[Update #3: Thanks to the tireless efforts of paulej72 well into the wee hours of this morning with able assistance by audioguy in straightening out some IP issues as well as Deucalion and TheMightyBuzzard providing guidance and support, all but two of our Xen servers have been upgraded to KVM. This free upgrade doubled the amount of memory available to our VMs, giving us some much-needed headroom. That leaves beryllium (IRC and email) and boron (DNS, Hesiod name service) as the two servers that have not been upgraded yet. Date/time is TBD.]
[Update #4: Boron will be reconfigured shortly, and then Bberyllium after that. Plan on an hour or two, though, obviously, we'll try to keep the downtime to a minimum!]
[Update #5: Boron's second upgrade for the ram sat in the queue for several hours, so Beryllium had to wait until paulej72 got up and finished it this morning (0830 EDT)]
- Read More...
- 46 comments
Two years ago, on 2014-07-04, SoylentNews received official confirmation of becoming a Public Benefit Corporation. Though there is no user-visible manifestation of this on the site (or any of the other services we provide), it does stand as an important milestone in our history.
A lot has happened since this site went live. Here are some numbers:
- 93 - polls posted.
- 170 - current subscribers.
- 1816 - journal articles posted.
- 6278 - registered nicknames.
- 12252 - stories posted to the site.
- 14556 - stories submitted.
- 369411 - comments posted.
- 41767215 - story hits we've counted (ignores AC hits)
Numbers, however, provide only part of the story. We have been able to keep the site up and running with only a few unplanned site outages, which is a far cry from how things were back when the site launched. To watch this community coalesce and grow to what it is today has been a heart-warming and enriching experience. I've read stories and comments that have changed my view of the world. All thanks to the tireless (and very occasionally tired) efforts of our all-volunteer staff and you, our community. And what a talented and selfless group of people we have! I am continually impressed with the knowledge and professionalism exhibited by the staff — I tip my hat to them all.
One of the comments to last year's story sums it up very well for me:
I[t] feels like much longer than a year ago, maybe because Soylent perfectly replaced the place Slashdot occupied in my heart. Except, it's better. NCommander, Eds, we really appreciate the work, spirit, and intent you've put into the community. It's a mark of distinction that this place feels more like a really big, walnut-panelled study filled with learned colleagues than it does a random, pointless forum. The latter is ubiquitous, the former unique.
It is my fervent hope that we will continue to earn your support and provide you with the best news discussion site we can.
- Read More...
- 47 comments
We have been made aware that there were some problems with our site's automatic notification of subscriptions expiring. We are looking into it. I was surprised to find that mine had run out and suspect that others may be similarly unaware.
Please take a moment to load the Subscription Page and verify your status. We appreciate your support and cannot run this site without it. This is a purely volunteer effort here -- none of the staff receive any financial remuneration for their efforts. Your contributions go entirely to keeping this site running.
Please accept my deep and heartfelt thanks to all of you who contribute to the site in other ways: those who helped get the site off the ground in the beginning whether they moved on or stayed. Those who submit stories, post and moderate comments, edit the stories, support our systems, maintain and update the software, and all-round do what they can to make this a community for all of us — we need all of you.
On behalf of all the staff here at SoylentNews, I thank you in advance for your support.
[Update — 2016-06-30 12:45:00 UTC] Many, many thanks to all of you who have updated their subscriptions!
Since this story originally posted, we've had 14 people renew; by my rough calculations, we are now at approximately $2688 towards our $3000 goal for funding this site for the first half of the year. As was noted in the comments, it is possible to give a gift subscription to another user on the site -- just enter their UID on the form. Also, one can change the amount from that offered to a larger value, if you wish. We have one member whose subscription ends in 2026!
- Read More...
- 41 comments
