Show newer

@ccc Wait what? Im not sure i follow... air motion generates heat. If I take a large fan and run it in the middle of the room, the room will get hotter over time, not cooler. Not counting a few edge cases of course.

@ccc

I would argue that the "optimize late" even as a general guidline is bad advice.. You should almost never optimize at the very end, nor should you optimize too early for things that may never be. Just as you shouldnt spend all your time designing and building a single class that takes significant effort before moving on to the bigger application. In general you should be doing everything at once incrementally. Every step should have some portion of every aspect including architecture, implementation, and optimization, and those steps should be spread out throughout the process.

This big point here is that even if your application runs just fine without optimization, you should still be doing it. Mainly because the architecture you decide on, including the API you expose to the outside world (which you cant really change too easily) may make good quality optimizations impossible in the end, even if its workable during development.

@VictorVenema

See I would say you have the idea of "blocking" as a group correct, but have the application backwards.

The scenario you describe, of an instance blocking servers is basically "lets all share a block list, but also you are **required** to use my block list by simply being here", you arent blocking what the baddies, you are blocking your own users freedom on who they are allowed to see.

There is an inverse of this however that achieves exactly what you describe without the violation of your own users freedom. That is "An instance is a collection of users all held to the same local standard (the instances TOS). As such users can block baddies easily and enmasse by blocking a small handful of instances rather than large numbers of users". Since an instance has a specific set of moderation policies all an individual user has to do to block baddies is on their personal account is block a small handful of instances, the ones that allow baddies, and they have effectively blocked all the baddies with minimal effort. Same effect of keeping the baddies out with minimal effort, no need to violate users control or freedom to see owhat they want.

@VictorVenema

> I was going by your own description as a free speech server which does not block other instances. I guess in practice the differences will be small, within science people tend to behave. We are still small, but I have not had to do any moderation of our own people.

You would be correct in stating we almost never block other instances. But the reason for that actually comes from our LGBT community and the say they had early on when the topic was being discussed (I think 2 years ago at this point maybe, whenever it was GAB came to the fediverse).

Most LGBT-friendly servers at the time were blocking not just gab but massively blocking other servers. While some in the LGBT community were ok with this there were many who felt this put their safety and lives at risk. Many such users routinely monitored GAB accounts for mention of anything that may put their lives or community at risk, for example Milo doxxing someone, and when they saw this would disseminate it throughout the community and would allow them to take precautionary measures. Since defederating didnt improve their privacy in the other direction (A public post is still viewable by users of a server you defederate with outside of vanilla mastodon) it only served to put their lives at risk without protecting them in any way. Those users who wished to simply not see the content due to its vile nature could simply click a few buttons and block the domain at the account level, so no harm there either.

Anyway, as a result of this view there was a mass exodus at the time of LGBT users flooding in from other servers that were more oppressive of their own users freedom (defederation only limits their own local users and doesnt limit the users on the offending servers). Since QOTO was one of very very few servers that were welcoming to the LGBT community but federated with all servers this is where many of them wound up. It was a huge source of our early growth and why we are one of the larger servers around today.

> So you re-implement your additional features regularly in new Mastodon versions?

I'm not sure "re-implement" is the right word. We do pull in the upstream from mastodon vanilla when there are changes. Generally I have kept the code clean enough that even despite having significant code edits the merge process isnt too bad. Each new version does usually take me a day or sometimes more to integrate, but often its just a few hours of effort.

> In WordPress you have "hooks": Parts in the code where you can tell the program to call additional functions via a settings file.

Sadly mastodon has nothing like hooks and isnt even very configurable when it comes to core features (like toot size you have to physically edit the code). Gargron is a very opinionated developer and as such he wants to discourage people doing exactly what I did, he was mastodon servers to have some conformity to it and follow his opinionated idea of what is a good application. Therefore it very much is like maintaining a fork and is a proper development effort to maintain QOTO with all the code changes I have made.

@admin @GrassrootsReview

@GrassrootsReview

> It is good to have some options. Sounds like we moderate/block stronger to keep FediScience a friendly place where as much people as possible feels welcome.

Probably not, but I would need some examples to really judge. We have a fairly large LGBT community here and take pride in that and have no issue blocking someone if it is justified. We dont tolerate hate speech and have very little if any biggotry around here thankfully. We do however allow for a freedom of opinions outside of hate-speech and encourage people of all ends of the political, social, racial, and sexual spectrum to share theirs without fear of a ban hammer, again so long as they arent resorting to hate.

We also make sure we talk it out with users before banning with borderline situations. Generally we find it is important our users not need to be fearful of how they experss themselves and know when they make a mistake it will be addressed with an open-dialogue and not an outright ban.

I encourage you to look through the timeline, youll find most of our users are very accepting and I think the strong LGBT presence here is a reflection of that.

> Some of the additional QOTO features are once that would also be useful for us (equations, longer posts). How do you do this? Especially how are these features maintained each time Mastodon is updated?

Well, I modified the mastodon source code myself and continue to modify and improve it. Most of the features I've had to add personally over time. Some were partially or fully contributed by others and just integrated by me, others I developed from scratch. At the base we are mastodon though.

@VictorVenema @admin

@ccc Yes but that light gets absorbed by the room and also converted into heat, so still ultimately heat in the end.

The only argument you could make (and I've made this before) is loss due to 1) light escaping through your windows, 2) RF emissions from the computer that escape into the far field and do not get reabsorbed within my home.

Keep in mind both of these are extremely minimal in terms of total power output, you are talking less than 0.1% easily. Also keep in mind the argument about light applies to all heaters. heat escapes as light in the infrared which windows are transparent to. So from point #1 a computer is no more inefficient than an electric heater. For point #2 a computer is probably a bit less efficient than an electric heater on point #2 but it is also so minimal as to be insignificant.

@mur2501 Well this is the amount it will deal with when im doing development, not just as a stress test. This scenario is what I do in order to calculate the algorithm across 25 different stocks to see how well it performs. Then i use that data to tweak the algorithm to try to improve it and run it again. So this is a normal use case for the algorithm during analysis and planning phase.

As for when it is running in the wild and actually buying and selling stock, it would run in the current scenario once a day before market open to pre-establish back-data. Then once every minute it would ingest one additional datapoint per stock.

@mur2501 not particularly large, 100,000 data points per stock (1 min price data for one year across 24 stocks, only for the time the market is in session though not 24/hours). So about 3 million data points in total. However my algo doesn't just run through it one time either, it has to copy it to 24 separate processes first and each of the 24 processes need to process the 3 million points (all the stocks, not just one for each process) and then a final process combines the 3 million or so output from the underlying processes to combine it back into a final 3 million dataset.

processing one of the 24 streams for one of the 25 stocks takes about 20 seconds using 24 out of 32 of my cores. I'll know shortly how this much heavier processing load takes to finish.

@mur2501

I only ever used keybase. It is easier to set up and as far as i know the only one with direct mastodon integration (namely, it gives you a little green check mark on the mastodon side when your verified)

@torresjrjr

LOL the algo is up to consuming 20 gigs right now on this stress test. Good thing I have 64 gigs of high speed memory :)

@torresjrjr

> - It doesn't encourage you to download needless software.

I dont think encouraging you to download needless software is a bad thing, so long as it is encouragement and not a requirement. In fact I'd say writing a custom app that is essentially a wrapper to other tools but makes using the service easier is a good thing. This is doubly so when you consider that every action you want to do in keybase gives you the exact commands to run both with their software and using plain linux commands. So they really make it so there is no pressure of any kind to use their software.

> - It encourages you to handle your PGP keys individually, and not depend on some external acount on some platform.

While I do agree that in terms of "encouragement" it should warn and discourage you giving it your pgp key, as that is just bad practice in my eyes if your particularly security aware. But it is still only encouragement and is entierly optional. So to me having provided the option, particularly when there is no disadvantage to not following it, is perfectly acceptable. More options means more power for the user to choose, power often means you have the option to choose things that may not be what others recommend or even choices that may be less secure. But that is, ultimately, your choice and I am pro-choice :)

@mur2501

Stress testing my algo across 600 simultaneous threads at once on a 32 core CPU at once. This thing is a beast when it comes to parallelization!

@torresjrjr

that is true, though the owners of keybase would not be able to present any security concerns, presuming you dont hand them your private key (most users dont).

Keyooxide is a great choice too. Any mechanism for proving to me you own the key associated with your account is good by me.

@mur2501 @trinsec @users @keyoxide

@ccc I dont entierly agree with this. In fact in my current situation that would be devastating if I took that advice.

What I would say is you shouldnt optimize something arbitrarily nor as a matter of fact before submitting a class. What you should be doing, however, is having profiling of the app as part of your CI suite so you can see the hot spots in your code and where time is being spent as you go. You should have the awareness of the final design your headed for if this will be a problem and do some combination of optimize or adjust your design to account for this. There is not absolute "when to optimize".

The reason for that is manifold, but here are some reasons waiting to the very end to optimize can be detrimental:

1) The poor performance of a component can slow down testing, and ultimately development to such an extent that it hinders development time significantly.

2) Generally projects are never truly finished. Any project worth its salt will be a living project and will likely always be improved upon iteratively

3) Architecture can be a limiting factor in performance. For example you can often optimize things significantly when done in catches where you couldn't do it when you operate on a per-element approach. If the architecture is designed to handle per-element access in the way its designed but not bulk access it may be impossible to optimize effectively later on. In extreme cases this may require the fundamental architecture to be rewritten and cost significant development time. By doing performance testing earlier on this would have been recognized and the architecture adapted before the project gets too far.

@ccc Actually thats not true, all heaters are 100% efficient, though some may come from more expensive energy sources that would be better used doing something other than heating. But a computer will be just as efficient at heating a home as an electric heater would be.

By the way if you want extra security in this scenario and protection against malicious users pretending to be you to get into your account then post your GPG key in your bio or verify with keybase. This will allow me an addition vector to verify you should you get locked out that wont rely on email.

@trinsec @mur2501 @torresjrjr @users

Deleted email i can get you in much faster as i can detect the email was deleted.

@trinsec @mur2501 @torresjrjr @users

I get a sort of perverse pleasure as I watch my algorithm use up 24 out of 32 of my CPU cores at 100%... this is what it was all for. No more running the heater for me!

Show older
CleverLibre Social

CleverLibre Social is an inclusive social instance for open discussion, learning, and community.
All cultures welcome.
Hate speech and harassment strictly forbidden.