Topic: Kick-off Discussion: Existing Forum Temperature Check + Criticism (Read 4490 times)

If you have good contributions maybe it's a possibility in the future. Because we have gone off-topic and features and things are starting to show up in different threads. Let's do that. Create a thread for suggestions or features.

This thread is closed.

I am correcting you in how poorly this whole thing was handled and how sad all you have is barely anything to show (I loaded this on my dev machine half of it didn't even work ). I would love to starting code and help you guys out, how much are you going to pay me for my time?

You're right, but this repo is more than an API. It's misnamed because we were originally going to split things up more in multiple repositories. We decided we need to put this into a single repo instead for the following reasons:

1. Integration with the original forum requires some shim work that we did. You're totally right about not needing the data. And obviously our whole idea is to steal your data and sell it. (/sarcasm)
2. Supporting noscript is a big goal for us. Javascript in the browser isn't for everyone and I believe that information needs to be concise and not filled with unnecessary UI fluff.

This is my last response to you until you decide to be helpful and positive about the project. Before you insult our skills, take a look at our work and if you want to correct us in ANY way, please feel free to send over a pull request and we will evaluate it in a thread for EVERYONE to see and decide what's better. Open source means we are open to CONSTRUCTIVE criticism. Learn to contribute so that you can matter.

3 month is all you have is an api? You got to be kidding, this is a joke... 3 Months for an api, I build apis in less than 2-4 days. Come on guys you have $350k spend a little more time or hire another developer to help you. This is honestly the saddest thing ever.

Hey Gweedo,

The Github repo for the auction system has actually been public for awhile. I'm sure if you look through the Slickage profile on Github you'll find it. It's currently called Adness-API. There's also an Adness-Web for the SPA version of  the auction system. We haven't really started work on that section yet. We wanted to get the noscript version out first since that covers all users. As Wangbus said, we're finishing up right now and not taking in an issues or pull request yet. We want to finalize the alpha version before we do that.

https://github.com/slickage/adness-api

Why not make it transparent now so we can see how much work by commits are being done? How do we even know you started? I mean it is taking this long to do an ad auction system, that could be done in a week, I can't imagine the forum is going to be taking a year, it is looking like two years.

Everything going through GPG might be a possibility. I'd like to explore these options once we get the initial migration off the ground.

Although supporting the migration of this forum is the top priority, keep in mind that this is a separate product that's open sourced. We have a team that will funnel contributions from the public when the system becomes more stable.

Augusto Croppo is spot on. This is pathetic.

Perhaps an option to highlight threads created by established members or a way for user to suggest a threshold, below which new threads are hidden to them. Obviously, ignoring individual users works but I wonder the difference that just excluding new threads from those with less that X activity might be helpful. The current icons on the left of threads suggesting ?hot topics, aren't useful - perhaps those could highlight heros; friends; and users with less that 8 digit IDs  

"GPU" is also a "CPU". It is just a different name for the same concept. All algorithms use a considerable amount of processing power, whatever this power come from the main processor (CPU) or from a secondary processor (GPU).



No, this is the point you missed. You were paid $350000 (+ $750000) to develop a software from the scratch, but you cannot even implement GPG in the development because it is "CPU intensive".

LoL

If every developer was incompetent like you, we would not have this amazing "CPU intensive" algorithms to shrink the size of data being transmitted among electronic devices.

I didn't get any support on this comment before but will try again.
Could you please modify the watchlist such that a user can select from a list, threads that they want to return to (view) regardless if it has had a new post since their last visit.

Initial responses have been decent. I will be posting interesting posts to its own topic for further discussion after this week.

I agree, but it's more of a usability issue. I think users can and will get their GPG keys screwed up. We will try to put this feature in though. Just need to think about how to orchestrate it.

Actually most video games are GPU intensive and not CPU intensive, also any time you use a reasonably well written OpenGPL webpage, also CSS3 transform are all offloaded to the video card, also massive batch processing algorithms (CUDA) often make use of the GPU instead of the CPU because of the nature of the algorithm. Should I go on?

The point you've missed is that the intensive CPU processing, in this fictional scenario, all takes place on the server and not distributed on the client side.

How does it not fix that? If you have a mail server with a decent amount of cores it can use all the cores and process many at one time, I would say it should able to process about 500 emails at one time. You don't have really care about getting mail so that eliminates that processing. And if you really cared you can build your own really slim smtp server.

This only fixes one of the problems I listed, which is the mail server bogging down the web server. But it does not fix any of the other issues such as getting all the email out in a time-sensitive manner.

It is a bit weird I forgot where but there is a suggestion to use google search instead lol
Or was

LoL

Really? Tell me, which algorithm is not "CPU intensive"?

Oh dear, you guys are just pathetic... Yet another demonstration of incompetence for what you were massively paid to do.

EDIT: By the way, dear forum users, be careful to not open too many tabs in your browser with HTTPS loaded pages, it is very "CPU intensive", your computer could explode.

Or why doesn't the forum move the mail server off the web server, then BINGO who cares how long it takes because now it is off the web server. Can we just use our heads a little bit and problem solve.

GPG is a CPU intensive process. In most cases, this is not an issue because either messages are small or they are infrequent. But given the right circumstances, it could bog down the server and could be used as an attack vector much like DDOS or could even be paired with it (we need to make sure this is not possible). We have a lot of other features lined up that could be upsteam dependencies and we need to make sure that in all cases, the server is still responsive.

Let's take the email/GPG use case for example, if an email needed to be sent out to the entire user base. That email would have to be encrypted once per user and then sent out (Given everyone was using GPG). If there are (I'm making this number up) 100,000 users... Can you see how much work that would be for the CPUs? This would be on top of serving those same 100,000 user the forum as well. Now imagine if that email really didn't have anything important to say. That's a lot of work for really nothing. But what if the email did contain sensitive information? There are ways to mitigate the CPU issue by locking it down to a few or just one core but that comes with its own trade offs. The speed at which the emails are being sent out may be drastically lower. If the email isn't time-sensitive but contains sensitive information, this is fine. But what if a system wide breach of the DB were to occur and all user's login/pass were compromised. A time-sensitive and possibly information sensitive email needs to go out...

I could go on and on and keep playing what ifs. Each what if (corner case) does have a solution but some of them require that GPG is not universally used on all messages for the sake of speed. Which means more coding to ensure that logic is in place. Also, if none of the features run into issues like above then it's clearly a good idea to use GPG on everything.

This is why the idea of GPG on all communications is a toss up. It's a great idea and we'd love to implement it, but due to the nature of GPG being CPU intensive, we may need figure out a solution if two features align against each other. But since not all the forum features have been solidified, we can't make a firm decision on it right now. That's just the nature of software development.