🗣 Things Our Customers Have Said About Discourse Thread
-
http://www.reddit.com/r/creepy/comments/14fqdd/creepy_old_photo_it_says_on_the_back_1888_aunt/
Aunt Velma...
-
Still sticking with old dude, duddette is an imposter. Are you an imposter boom?
-
Exactly. Do an image search or something. I found it...somewhere...someone had unearthed some old photos. This one had writing on the back about "Aunt Whatever never got married." The mind boggles, eh?
Wow. I assumed it was Andrew Jackson's brother or something.
-
someone had unearthed some old photos. This one had writing on the back about "Aunt Whatever never got married." The mind boggles, eh?
And I thought my great-grandmother was homely.
-
@Intercourse said:
You have to be fist-fucking me?
Where's the checkbox for "fuck off and die".
-
-
Yay for Diiscoursistency.
-
I know I'm not the first person to say that, especially that term.
-
I know, but it needed to be added in here.
-
Now that's just Discourseting.
-
Discourseting? Really? You can do better than that.
-
In psychiatry, derailment (also loosening of association, asyndesis, asyndetic thinking, knight's move thinking, or entgleisen) is a thought disorder characterized by discourse consisting of a sequence of unrelated or only remotely related ideas. The frame of reference often changes from one sentence to the next.[1][2]
-
-
Rerailing the topic?
-
-
Perhaps wikify the topic then? A-la the Discopaedia thread.
@matches, Thoughts on the matter?
@abarker, @boomzilla, potentially some work for ya to do...
-
Rerailing the topic?
The quote that I quoted was just too good, and I remembered this topic. I didn't even look at what was said before (like always, amirite?).
-
You can do whatever with it - I don't think I can wikify it.
-
Oh. Fun. I got a notification from @PJH, then when Boom quoted @PJH it put in a new notification for me... but when i clicked on the notification, it linked to the post ABOVE @PJH post.
-
Yeah, notifications are the best way to lose your reading position.
And there's no "mark unread" button, because who would ever need that
-
Somewhat related: it would be nice if, when I use search to find a topic which title I remember, it would send me to the first unread post rather than the top post.
-
Somewhat related: it would be nice if, when I use search to find a topic which title I remember, it would send me to the first unread post rather than the top post.
Seconded.
-
-
@PJH said:
This is Discourse, so it probably is string.
That seems to be what's holding most of the site together
Filed Under: Yes, I want to revive this topic!
-
Is one of the complaints "extremely slow on mobile".
-
Is one of the complaints "extremely slow on mobile".
You're going to have to wait the next 10 years for everything to load on mobile… ;)
[spoiler](OK, not quite that bad, but I couldn't resist…)[/spoiler]
-
I don't wanna defect Discosocks here but it does now work pretty well on my S5.
I assume it still sucks if you don't have a top end phone though.
-
it's pretty decent on the Nexus 5 and Nexus 7.... yeah.... i think that was koolaid i drank back there...
-
Discourse shit on the carpet again. I wish the developers had housebroken this dog before they unleashed it on the world.
-
out of disk space due to missing log rotation and redis leak, will look at both.
only way to "housebreak" this stuff is to run it in the wild on forums with heaps of reqs (like here due to bots etc) for extended periods with zero upgrades, which is what we are doing here.
will get it sorted
-
Being out of disk seems to do quite the number on Linux systems.
-
It's all Chrome's fault!!!!
(According to someone important and knowledgeable)
-
Being out of disk seems to do quite the number on Linux systems.
It does it to all sorts of systems. (Windows also doesn't like being quite that constrained these days either.) The real question is why people insist on under-provisioning their systems…
-
or filling to overflowing with logfiles
-
A turned-up log level would do it too, yes. I've broken a few OS installations that way. :) That's why I always like to provision generously; it doesn't cost all that much, and it saves you from so much trouble when things get busy…
-
Simple solution:
put discourse generated content on one partition, user content on the other, and system files on a third. If any fills to capacity run an rm -rf chosen randomly and assign that as the new content location.
-
Being out of disk seems to do quite the number on Linux systems.
Indeed it does. Only happened to me once (ironically, it was the syslog rotation fail) but it's a pain.
The real question is why people insist on under-provisioning their systems…
Well... In my case I let Debian installer create an lvm with separate
/
,/var
and/home
partitions. The sizes were completely acceptable since all data was residing in/home
. But a runaway log file would bite me in the ass even if/var
wasn't a separate partition. Unless you're advocating the 'single partition' approach (which would prolong the time until it failed).
-
Well... In my case I let Debian installer create an lvm with separate
/
,/var
and/home
partitions. The sizes were completely acceptable since all data was residing in/home
. But a runaway log file would bite me in the ass even if/var
wasn't a separate partition. Unless you're advocating the 'single partition' approach (which would prolong the time until it failed).The real problem is usually that log systems are not written to fail gracefully when it is impossible to log, so logging filling up takes everything else down (instead of just causing the log to not be written). Too many developers with no experience in what the failure modes actually are…
-
The real problem is usually that log systems are not written to fail gracefully when it is impossible to log
And in the case of text logs on a full disk, an option to just try and gzip the current log if it runs out of space might be worthwhile if your application tends to log a lot of stuff. But that would just be silly, I mean, why would anything else on the system want to use the disk space...
-
And in the case of text logs on a full disk, an option to just try and gzip the current log if it runs out of space might be worthwhile if your application tends to log a lot of stuff. But that would just be silly, I mean, why would anything else on the system want to use the disk space...
That doesn't work. You have to compress the logs before the disk becomes full or you run out of space during the compression process, since it doesn't remove the uncompressed version until the compression finishes. While it might be possible to do an in-place compression, it would be a good way to lose data (in particular, there's no guarantee that the compressed data will actually be shorter; it depends in part on the Shannon-complexity of the data).
-
You have to compress the logs before the disk becomes full or you run out of space during the compression process
So trigger compression when some threshold, say 90%, is reached. OTOH, if you're smart enough to do that, you're probably smart enough to have implemented rotation correctly, so you don't have the problem in the first place.
-
Or the real real question is why the logs aren't on a dedicated partition and set up so that if it's trying to log and can't it either whacks the oldest log or gives up and goes on without logging the new entries (while kicking off an error notification for administration).
-
Precisely. Though the redis problems would have still been the source of trouble. (I hope it's not redis itself that is the cause; the main developer of it is a nice guy, a former collaborator of mine…)
-
That is a real good strategy, easily enough done here, but doing this for all customers is going to be a pain unless I can figure out a way of bash scripting it into ./launcher.
-
redis consuming too much space is our fault, not antirez's :)
-
I think it's just one big continuous diarrhoea incident at this point.
Filed under: Discourse Customer Reviews
-
-
"This software fills up logfiles faster than a newborn fills a diaper, and with roughly as much shit."
-
Needs more snappy. (Kinda like discourse, I suppose)
-
I definitely recommend /var/log getting its own partition. I usually have important stuff in /var/lib that I need to get persisted more than logs.
Rotation is also important and you can't compress a log file if the application has it open. Well you could but probably will experience a loss of new log messages as well as no space recovered until the app closes the file handle.