A new logo for storagenode

[Mitsos]

But we have a new logo!

[Mitsos]

Perhaps this can help put things into perspective:

Mar 14 v1.100.1-rc

Changelog

Storagenode

• 21de0c3 storagenode/blobstore: store trash under per-day directories

@thepaul

We don’t have a fix yet. This situation is not considered ultra-high priority because the only data at risk of being lost is already in the trash. We definitely do see how it’s a problem for our SNOs, though, and we would like very much to fix it. The plan is to recognize the recursive directory problem and the unmigrated directories problem and correct them automatically on node start.

4 days ago v1.103.2

Changelog

Storagenode

• 67edcd9 web/storagenode: update STORJ logo

It is quite evident that it’s not sarcasm on my end. The only real testing that has been done in the past 18 days has been updating the storj logo and making sure it’s pretty. There has been absolutely NO testing performed on the trash improvements, otherwise this testing would have caught the (number of) bugs mentioned in this thread. The only reason I was able to catch the trash cleanup not updating the databases (which a simple diff on the resulting database files would have caught instantly past merge-testing on your end) was because the monitoring system I use showed decreasing disk space, yet the nodes were still reporting full.

I’m not being sarcastic: It is very evident where storj’s priorities are. We (as SNOs) can only follow those priorities. And the current priorities are:

• make the product look pretty
• test the possibility of having larger clients onboard by migrating data from the production satellites to the testing satellite

What is NOT a priority:

• making sure that nodes don’t constantly die left, right, above, below and center
• keeping an accurate track of used, trash and free space
• actually cleaning up the trash
• expecting the team to open a bug internally with all the provided logs, df, du outputs already provided

Some will still argue that what I’m saying above is not the case, not true or FUD. The quoted parts are there, as are all the replies. To each their own, other SNOs as well as I, are only trying to keep the (remaining) nodes online to the best of our abilities.

[snorkel]

For the fun of the debate, a new cloud icon poped up…

[Mitsos]

Just to keep the ball rolling:

[nerdatwork]

@snorkel

a new cloud logo

That’s an icon not a logo. There’s a difference between them.

[thepaul]

If you would like to try again, without the hostility, I’m happy to take questions.

[Mitsos]

If it’s not too much trouble, what exactly was hostile and warranted a flagged reply?

[arrogantrabbit]

@Mitsos

18 days has been updating the storj logo and making sure it’s pretty. There has been absolutely NO testing performed on the trash improvements,

I’d say logo update is way more important than some bug clearing out trash. No sarcasm.

Logo brings money. Clearing out trash doesn’t.

[jammerdan]

@arrogantrabbit

Clearing out trash doesn’t.

One more reason why trash should be paid.

[Alexey]

I’m sorry, that you thinks that’s the case.
We tested the trash behavior and it worked correctly, however, I think that we didn’t test several downgrades and upgrades, because it was not expected that we would need to downgrade.
Regarding not updated databases after the trash chore perhaps there is a bug has been introduced between changes.

@snorkel

a new cloud icon poped up…

… several months ago, here:

Add links to forum header

Same here. But even during daytime staring at the blaring white light all day is quite fatiguing. When the dark mode got wide adoption it was such a relief. I actually used color inversion though accessibility settings before Btw — the menu content is still white: [image]

[bre]

@Mitsos The simple answer is technical work regarding trash and marketing work regarding logos are done by entirely different teams, as in most companies.

The technical issues you point to are not things that can be solved by the the people who worked very hard on the rebranding project.

It’s important to appreciate how many diverse skill sets, teams and timelines comprise what you see from the outside, and have patience for each team to do what they do best.

[Mitsos]

bre, I get that. My flagged reply above would have led to “no they do not have commit access because they may introduce a bug without the developers having time to react to it” and my next reply would have been “so the developers actually had to devote some of their time to draft a commit, do all the relevant pull request stuff, merge it and commit it”.

I didn’t get there though, because someone broke the community guidelines:

Be Agreeable, Even When You Disagree
You may wish to respond to something by disagreeing with it. That’s fine. But remember to criticize ideas, not people. Please avoid:

Name-calling
Ad hominem attacks
Responding to a post’s tone instead of its actual content
Knee-jerk contradiction
Instead, provide reasoned counter-arguments that improve the conversation.

[bre]

I’m glad you understand what I am saying, and that you have been able to say the rest of what you meant.

Please be assured that the trash issue is being attended to as discussed in depth in other threads.

[jammerdan]

@bre

as discussed in depth in other threads.

I would be happy if some of the higher ranks would take part in these discussions. When I read quotes like this

@thepaul

We’re working on quite a few long-needed storagenode performance improvements right now,

it appears that long needed improvements have not been adequately addressed and required resources not allocated.
This comes together with my question

@jammerdan

Is there a systematic process in place for codewise node optimization?

And there is just silence on it. Like over the fact that Storj has literally hundreds of Terabytes of customer data left undeleted on their network while customers were told the data has been gone. Hushing up is never a trustworthy strategy for a company that praises itself for its transparency. I am starting to wonder how shall customers trust Storj to store and manage their passphrases for them in the future?

[littleskunk]

@jammerdan

it appears that long needed improvements have not been adequately addressed and required resources not allocated.

The part about required resources is wrong. First priority is and always was to fill the drive with paid customer data. That part deserves as many resources as we can. Some other tasks can simply wait.

[BrightSilence]

I have to say, I just don’t see the point of this topic. I understand that sometimes people just need to vent, but there is no new information mentioned, no specific actions requested and all topics mentioned have different threads with active engagement from Storjlings.

Attitude makes such a big difference. Whenever I have posted a serious concern about anything on my node it has always been appropriately addressed. Do I sometimes wish it was addressed faster? Sure. But me being louder about how unsatisfied I am isn’t going to change anything. In my experience, pointing out problems and bringing receipts (screenshots, logs, etc.) does make a difference.

So I encourage everyone to do what you can to be a part of the solution. At least for me that makes my time on this forum a lot more fun and fulfilling.

[thepaul]

@jammerdan

@thepaul

We’re working on quite a few long-needed storagenode performance improvements right now,

it appears that long needed improvements have not been adequately addressed and required resources not allocated.
This comes together with my question

I’m sorry I did not make this clear. By “long needed improvements”, I meant “things we have long known would improve storagenode performance, once we had resources to dedicate”. I did not mean “things that were absolutely required for making the software or the product work”. I think we have certainly allocated resources where required to make the business viable (by definition, because the business is currently viable), even though it would have been nice to get things done sooner.

@jammerdan

@jammerdan

Is there a systematic process in place for codewise node optimization?

And there is just silence on it. Like over the fact that Storj has literally hundreds of Terabytes of customer data left undeleted on their network while customers were told the data has been gone. Hushing up is never a trustworthy strategy for a company that praises itself for its transparency. I am starting to wonder how shall customers trust Storj to store and manage their passphrases for them in the future?

I don’t speak for the company in any official capacity, but I would think this not so much a case of “hushing up”, and more a case of “it’s not clear what you mean”. If I read the words literally, the answer is yes, of course there is a systematic process for optimization of the storage node code. It is hopefully pretty apparent from the outside that we use Github and Gerrit, which by themselves institute procedures and process for any code changes, whether for the satellite code, storage node code, or any other code. And we of course have procedures beyond that, but it’s not clear why you would want to know those. From your original comment, I think maybe what you’re getting at is “why aren’t you people updating the storage node software more” and the answer to that would be “because we had other things that we felt were more important to the success of the company which needed to be done first”. But maybe that’s also obvious and unhelpful, so I’m left with nothing much to say.

[thepaul]

@Mitsos

my next reply would have been “so the developers actually had to devote some of their time to draft a commit, do all the relevant pull request stuff, merge it and commit it”.

We have multiple teams of “developers”. As I said, the teams who generally work on the storage node software were not involved in the design or deployment of the new logo. It did not affect progress on the storage node.