Honey I Discourse'd the RAM
-
-
I've said it before and I'll say it again; even fucking AOL 5.0 didn't waste as much memory as duck-sauce and it WAS a real time chat platform.
-
Edge fared a bit better, RAM-wise. (The CPU time is due to my scrolling attempts :) )
-
stupid loops or recursion aside, "how to use 1G RAM with a mere internet forum" even sounds like a challenge.
-
Hey, you remember Firefox, the browser infamous for its hilariously inefficient RAM usage?
-
Now with added inefficient CPU usage?
-
3.9% > 8.5% > 17,8%? <script> Not that you can trust cpu usage based on a single sample, but that didn't seem to concern you either.
-
Hey, you remember Firefox, the browser infamous for its hilariously inefficient RAM usage?
Firefox was just the early dawn of a new era of inefficiency.
... And I fear Discourse is as well.
-
... And I fear Discourse is as well.
The AAA video games industry has already been increasing their production-cost-to-gameplay ratio for several years.
Discourse is less of an inefficiency story and more of a story about people using technology they don't understand.
This forum is running inside a Docker instance on an otherwise empty VPS. But the docker instance wasn't distributed. You have to compile it yourself.
Oh, but the compilation script doesn't need any special stuff installed. Even though it's written in Ruby. So what's actually happening?
Well, the launcher script creates a Docker instance with Ruby in it, runs a one-line script to parse some YAML to get one key from it, and then deletes the docker instance. Or sometimes it crashes and doesn't delete the docker instance.
So they "fixed" that by including a script that runs inside another Docker instance and needs root access to the host machine and deletes any non-running container. Which is great if you only ever run one contai-- WAIT A SECOND, THAT NEGATES THE POINT OF CONTAIN-- correct, because they're using technology they don't understand.
-
So they "fixed" that by including a script that runs inside another Docker instance and needs root access to the host machine and deletes any non-running container. Which is great if you only ever run one contai-- WAIT A SECOND, THAT NEGATES THE POINT OF CONTAIN-- correct, because they're using technology they don't understand.
-
I'll just leave this here:
Specifically:
To run:
vagrant up
. Wait ages (about 30 mins).
-
Not bad! Granted, it was from a new process (i.e. didn't come here from somewhere else), but loading the same pages multiple times is cheating, no?
-
So they "fixed" that by including a script that runs inside another Docker instance and needs root access to the host machine and deletes any non-running container. Which is great if you only ever run one contai-- WAIT A SECOND, THAT NEGATES THE POINT OF CONTAIN-- correct, because they're using technology they don't understand.
I know how to fix that. What we need around here is a bit of software defined networking.
It's dynamic, manageable, cost-effective, adaptable, high-bandwidth, decoupled, programmable and abstracted. Clearly the kind of solution that will fulfill business requirements in terms of enhancing stakeholder experience around the underlying enterprise infrastructure going forward.
-
That tab loaded, then promptly crashed with "this tab had an error, so it was reloaded" in iOS 9.1 on an iPad Air 2.
-
Ok, yeah, holy crap, I opened this on my work computer now and the whole thing started dying. Assuming it started swapping to the HDD right away or something, had no problems at home, but I got more than double the RAM and an SSD there...
-
Granted, it was from a new process (i.e. didn't come here from somewhere else), but loading the same pages multiple times is cheating, no?
I completely closed Chrome before reopening it straight to that topic for the screenshot in the OP.
-
I completely closed Chrome before reopening it straight to that topic for the screenshot in the OP.
As did I with Firefox FYI.
-
I did the same here at work, where the machine has less RAM to play with and:
-
Vagrant creates a VM, doesn't it? It takes even more memory than the usual discourse if it does.
A simple docker pull would work too, if you upload a precompiled image. The stupidity is the way they embed the admin, email and database passwords in the image, so it's hard to share them. Most docker containers have some workaround for that.
-
Yeah, but that way it stays in the box. I didn't want cooties on my real machine.
-
-
So they "fixed" that by including a script that runs inside another Docker instance and needs root access to the host machine and deletes any non-running container.
.....
https://what.thedailywtf.com/uploads/default/_emoji/headdesk.png?v=0
..... owww......... the arrogant, culpable stupidity on display.....
RUN AWAY!
:flee:
-
For raisons, I had cause to disable JavaScript for my main (recreational) Browser. This is what you get:
Which I can understand and use. However, it just goes to show just how much work the Client does and I'm not sure if that is a good thing. A question I would ask is how much of what is done, in terms of stats and monitoring etc, is replicated by the back end?
Looking a topic:
...snip...
I don't see a mechanism, or even an intuitive clue, as to how I would reply.On the plus side, Page Navigation is back even if the pagination stuff isn't
-
discourse-sans-js-topic-bottom.png1431x881 60.4 KB
I don't see a mechanism, or even an intuitive clue, as to how I would reply.You can't reply without JS. Well, unless you want to craft your own HTTP requests, that is.
-
I don't see a mechanism, or even an intuitive clue, as to how I would reply.
You don't. It's really only designed for search engines to index it.
You'll note it also paginates topics.
-
I wonder if it would be possible to make a front-end for Discourse that wasn't a huge steaming pile, and if that would solve at least some of the problems with Discourse.
502 OK
-
I wonder if it would be possible to make a front-end for Discourse that wasn't a huge steaming pile, and if that would solve at least some of the problems with Discourse.
On my list for the Christmas break. Well, not the whole thing, but a proof-of-concept at least. I think I found a reasonable way (two, actually) to decouple the damned thing from all the Ember bullshit. Just need to see if I can make it use some native elements or if I have to feed it back to WebKit view. I'd prefer the former because it will be easier to get the quote-select and read tracking working properly without relying on JS.
-
it just goes to show just how much work the Client does and I'm not sure if that is a good thing.
I'm 100% sure it's not.A question I would ask is how much of what is done, in terms of stats and monitoring etc, is replicated by the back end?
Probably none. All hail the mighty Javascript!
-
It's dynamic, manageable, cost-effective, adaptable, high-bandwidth, decoupled, programmable
BINGO!
and abstracted. Clearly the kind of solution that will fulfill business requirements in terms of enhancing stakeholder experience around the underlying enterprise infrastructure going forward.
-
A question I would ask is how much of what is done, in terms of stats and monitoring etc, is replicated by the back end?
Probably none. All hail the mighty Javascript!If that were true, at least it would be consistent with itself by virtue of only being done in one place. That's not the way of doing things.
-
unless you want to craft your own HTTP requests
Now that would be really stupid thing to do, next you'll be suggesting I develop some form of HTML Form thingy where I can capture user data with an Input of some description and get it sent to the Sever on the click of a Button.
As if any of that was even possible because somebody would have done something like that by now if it was.
-
I think Discourse sends your username in an HTTP header so they can use nginx access logs for stats.
-
It got worse when I tried to load the edit history on the OP