Bug202407211245 hubzilla account nomadic identity profile virtual private server failure

Sun, 21 Jul 2024 15:20:43 +0200

adminsforum@hubzilla.org

od schrieb den folgenden Beitrag Sun, 21 Jul 2024 15:20:50 +0200

Bug202407211245 hubzilla account nomadic identity profile virtual private server failure

@Hubzilla Development
@Hubzilla Support Forum

If you want to participate in the best part of fediverse, advance preparation is totally necessary.

Before anything data copies of accounts, channels, profiles is vital; follow the instructions in the help file attached.

See https://hub.hubzilla.de/item/baec89c4-7d0b-4501-8849-e2c7fcb21ae1

Do not upgrade/update constantly. Each version does not pass rigourous tests and new bugs will emerge. This is open source software; noone is a professional.

If a virtual private server is used. Data copies are even more essential.

If a hubzilla server dies, accounts, channels, profiles are likely to be corrupted when hubzilla is re-installed. For example, deletion of channels will break hubzilla. Deletion of profiles will break hubzilla. Create channels, profiles. Then re-install hubzilla. Somewhere, somehow, the hubzilla software breaks. Then, a database command will show differences:

SELECT id, profile_name, profile.fullname FROM profile;

id |      profile_name       |  fullname
----+-------------------------+-------------
  1 | Default Profile         | System
  2 | Default Profile         | ...
  7 | Default Profile         | ...
13 | Default Profile         | ...
18 | Default Profile         | ...
30 | Default Profile         | ...
(10 rows)

How can there be more id rows (e.g. an id '18' suggests there must have been 17 profiles created; where are they?) than total rows in the database

There are far too few hubzilla programmers to use hubzilla safely in sensitive environments (children, businesses, females, anyone not of the standard programmer demographic).

If you have sensitive connections with people that you need to keep private, DO NOT USE HUBZILLA. Have a look at all of your connections via: /hubzilladomain/poco/channelname

show all 54 comments

Sun, 21 Jul 2024 16:22:14 +0200

Der Pepe (Hubzilla) ⁂ ⚝

pepecyb@hub.hubzilla.hu

Do not upgrade/update constantly.

What kind of tip is THAT?

Releases are tested. In the eight years that I have been running Hubzilla Hubs, I have only very rarely experienced serious errors due to releases. And if there were real problems (not necessarily significant, but annoying), then there was a new update very quickly, which corrected the ‘slipped through’ error.

It should also be a matter of course to make a backup before an update. If you don't do this, you are bungee jumping without a leash.

Nevertheless, it is important to carry out updates as promptly as possible, especially if security-relevant errors have been corrected.

The tip is - to put it very nicely - ‘not good’!

How can there be more id rows (e.g. an id '18' suggests there must have been 17 profiles created; where are they?) than total rows in the database

No idea what's wrong with your hub... but with the hubs I use, the query shows exactly what it should... even if channels have been deleted in the meantime. The Id, which is not always consecutive, shows that there are channels that have been deleted in the meantime. The total number of rows indicated corresponds to the actual number of rows... at least at my place.

If you have sensitive connections with people that you need to keep private, DO NOT USE HUBZILLA. Have a look at all of your connections via: /hubzilladomain/poco/channelname

What a load of rubbish to claim that Hubzilla should not be used for sensitive purposes.

Your ‘/poco/’ (as well as the view on the channel page) only shows the connections because YOU have set it that way. Have a look at my test channel here: https://hub.hubzilla.hu/poco/havelock

It is set so that ONLY I can see the connections. This can be configured. How? Like this: Berechtigungssystem (unfortunately only in German)

I see this here more as a rant due to frustration... right? ?

Sun, 21 Jul 2024 17:41:19 +0200

Mark Nowiasz

buckaroo@hub.netzgemeinde.eu

Well, @Der Pepe (Hubzilla) said everything, I would like to add another thing: The Importance of backups! (BTW, at each update there's a strong advice to make backups!)

Without backups you're screwed, sooner or later. And we are talking about two different kind of Backups: Hubzilla's files and database backups, do not - especially if your using MySQL/mariadb/whatever flavor - use a file backup on database files, this is kind of Russian roulette. Use mariabackup (or xtrabackup for Persona/Oracle MySQL, pgbasebackup for PostgresQL). Do the backups often and automatically. If not you will be screwed sooner or later: I myself accidentally truncated a vital table, well, no big deal, since I'm backupping the database four times a day, so it was just a matter of restoring the DB to the last backup (Another point: Try a restore once in a while to test your backup).

This is not advanced administration, this is basic stuff if you value your data. It's not optional, it's a necessity if you run a server.

Sun, 21 Jul 2024 20:39:27 +0200

od@zotum.net

@Der Pepe (Hubzilla)

What kind of tip is THAT?

Simple, especially in consideration of recent news events. If the upgrade cannot be guaranteed not to ... up your system, ignore it.

Using a decades old dell inspiron machine with gnu/linux, no problems encountered so far

> Releases are tested

The QA test are sufficicently rigourous, otherwise quantities and qualities of bugs would decline over time. Programmers prefer to increase features than reduce bugs. It's an old, dick measure ego thing.

> The Id, which is not always consecutive, shows that there are channels that have been deleted

Of course. In a world of nomadic identity and the (wrong) opinion by a programmer that deleted channel should never be recovered, begs the question of where these channels have disappeared to.

> What a load of rubbish to claim that Hubzilla should not be used for sensitive purposes.

If you want people to be satisfied that their connections are freely accessible to everybody, good luck!

For example you have 257 connections. Supposing you escape abuse, persecution, etc. but one of your connections is known to your enemy? Your identity is thus exposed. You are privileged, so have probably never had to escape a dangerous environment.

> It is set so that ONLY I can see the connections

Excellent to know. Do you think a person that does not have your intelligence to configure their account, should _not_ have documentation to describe how to achieve their privacy?

> I see this here more as a rant due to frustration... right? ?

Bugs of this seriousness have both emotions. Meanwhile, programmer(s) prefer to discuss "buttons" with comments...

Sun, 21 Jul 2024 20:46:33 +0200

od@zotum.net

@Der Pepe (Hubzilla)

> This can be configured. How? Like this: Berechtigungssystem (unfortunately only in German)

Tried a certain web page translation service:

"
You can now select the appropriate permissions for each possible use (not all permission options are available for some uses because not all permissions are useful or usable in every case):

Only me

Only those you explicitly allow

Accepted connections

Any connections

Everyone on this website

All Hubzilla members

Everyone authenticated

Everyone on the Internet

Leaving the forum aside, the "Public" channel role is the most suitable if you want to have and use a typical social network account. This makes you public in many areas, but critical use by third parties is not permitted. However, if you really want to specify exactly which user, even which visitor, can do what with the data and posts, you have to select the "Custom" role and select the appropriate permissions for each possible use.
"

Excellent functionality, but needs documentation!

Sun, 21 Jul 2024 21:19:52 +0200

Harald Eilertsen

harald@hub.volse.no

@od

It's an old, dick measure ego thing.

Thanks! You really know how to make people value your input.

Sun, 21 Jul 2024 21:21:34 +0200

Der Pepe (Hubzilla) ⁂ ⚝

pepecyb@hub.hubzilla.hu

@od

Using a decades old dell inspiron machine with gnu/linux, no problems encountered so far

And it runs an equally old version of a social network that is publicly available on the Internet?
A publicly accessible service that is available on the Internet should always be as up-to-date as possible... this is a question of security.

Programmers prefer to increase features than reduce bugs. It's an old, dick measure ego thing.

Wow! ... ><(((º>

Of course. In a world of nomadic identity and the (wrong) opinion by a programmer that deleted channel should never be recovered, begs the question of where these channels have disappeared to.

The recent little discussion about restoring deleted channels must also be read and understood in full(!). Then it should be clear that the point is that the sovereignty over restoring a deleted channel must be with the admin in order to prevent the takeover of deleted channels - i.e. a kind of identity theft. The admin can indeed restore a deleted channel in the database... but he should only do so if he can be sure that the original owner wants to restore it.

It is possible. But it is not the user who has the decision here.

That is GOOD and RIGHT!

If you want people to be satisfied that their connections are freely accessible to everybody, good luck!

For example you have 257 connections. Supposing you escape abuse, persecution, etc. but one of your connections is known to your enemy? Your identity is thus exposed.

Yes, I decided to configure my main channel, which is also the admin channel of the instance, so that everyone can see my connections. Because I ‘stepped out of the hiding place’ by offering the hub.

If you want, you can even take a look at my legal notice and find contact details there... as well as in the privacy policy. And my nickname has been known on the net for over ten years and everyone knows who is behind it.

My conscious and deliberate decision.

However, I can always create a channel where I am not public in certain aspects and where I don't share my contacts with the world. I can even determine the latter (and others) very precisely... i.e. ‘only me’, ‘only my contacts’, only ‘users of my hub’, ...

You are privileged,...

What do you know about my "privileges"?

Excellent to know. Do you think a person that does not have your intelligence to configure their account, should not have documentation to describe how to achieve their privacy?

This is the only point on which I agree with you. Hubzilla's documentation could be greatly improved. It is rudimentary, partly outdated and mostly very technical (i.e. hardly comprehensible for the normal user).

Incidentally, THAT is the reason why I share my experiences and my (modest) knowledge with the world in the Hubzilla KnowledgeDB that I maintain.

Sun, 21 Jul 2024 22:46:23 +0200

od@zotum.net

@Der Pepe (Hubzilla)

A publicly accessible service that is available on the Internet should always be as up-to-date as possible... this is a question of security.

No thanks.
My machine, my risk, my responsibility, No programmer deserves the privilege to tell a user to do what (s)he wants.

Mon, 22 Jul 2024 08:31:15 +0200

Mark Nowiasz

buckaroo@hub.netzgemeinde.eu

Ladies and Gentlemen, it seems that we got a Sea lion here - with a dash of Insane Troll Logic. I'm out of this thread, refusing to feed the sea lion with what he craves most: attention

Mon, 22 Jul 2024 11:55:15 +0200

Der Pepe (Hubzilla) ⁂ ⚝

pepecyb@hub.hubzilla.hu

@Mark Nowiasz I immediately realised what this ‘discussion’ was all about. And I'm not in the habit of feeding.
On the other hand, untrue claims were made and, above all, the recommendation was made not to update Hubzilla. And the support forum has 312 connections, i.e. 311 connections without the TE, which could be sent in the wrong direction by the thread or the initial posting. That's why I wrote something about the individual points in a timely manner. ?

Thu, 25 Jul 2024 00:59:11 +0200

citc

citc@zotum.net

@Der Pepe (Hubzilla)

above all, the recommendation was made not to update Hubzilla

Perhaps "lost in translation", original post does not seem to state that.

As a teacher, see little benefit to use of latest software in general. Stability, reliability, "backwards compatibility" of greater importance. Wrote about this before: https://chemistryinthecity.neocities.org/content/entry2005.html

Thu, 25 Jul 2024 09:44:30 +0200

Der Pepe (Hubzilla) ⁂ ⚝

pepecyb@hub.hubzilla.hu

Do not upgrade/update constantly.

How should we interpret this statement?

He goes on to say that new versions are not really tested because only non-professionals work on Hubzilla. This means that every new version is a risk and should not be updated.

Each version does not pass rigourous tests and new bugs will emerge. This is open source software; noone is a professional.

Should we stick with the current version forever?

It may be right for individuals not to always switch to the latest programme versions. And for locally used software, which doesn't have a major impact on the system anyway, it is also rather harmless.

Here, however, we are talking about server software that provides direct access to the Internet and, above all, access to the software from the Internet (i.e. from outside). Errors here can have fatal consequences. If you operate a single-user instance in an otherwise quite isolated environment, old and possibly faulty versions are more or less your own risk. That is personal responsibility... but it also means that if you have not made any updates, you do not have to blame the project, but rather yourself, for the effects of errors.

The recommendation he made was very unfortunate in this form. Perhaps he should have recommended that updates should not be carried out immediately (although this also harbours risks... for the reasons mentioned), but that we should wait and see if and what problems are reported by other admins. Let's not kid ourselves, open source projects with relatively small developer and support staff are somehow always ‘banana products’ (they ‘mature’ at the ‘customer’). This is in the nature of things, because the people involved in the project cannot discover every conceivable problem - due to different environments.

However, Hubzilla is a project that I consider to be inconspicuous with regard to errors after the update. Since version 3.x, I have basically been involved in every update (for various hubs I have operated myself) and have only very rarely had any real problems after the updates. If there were - rarely - once, they were also fixed very quickly. I know of other software where it is more common to kick yourself in the teeth with an update.

@citc

Thu, 25 Jul 2024 13:14:10 +0200

citc

citc@zotum.net

@Der Pepe (Hubzilla)
>> Do not upgrade/update constantly.
>
> How should we interpret this statement?

Important word, "constantly". Who has the time to upgrade sequentially, version 1 to 100? For example, using firefox web browser, _personal_ behaviour is to "skip" versions. Current version is > 15 versions newer than personal version used! Sorry, but not going to find each version to upgrade in sequence. School software versions are always behind. Sorry, but not going harass the IT department to use version X.

> Should we stick with the current version forever?

English proverb: "if it is not broken, do not fix it". It is up to the user or network manager to decide, not a programmer who cannot possible know every environment.

> This means that every new version is a risk

Of course, by definition. Computer people must improve their non-technical project and people management knowledge.

It is impossible for an upgrade to be guaranteed success, therefore to tell people that they must upgrade, is fundamentally poor application of the scientific method.

A quick web search returns version 86 in 'codeberg' and 921 in 'framagit'; don't know which is necessarily suitable. Software people seem to embrace this "move fast, break things" mentality. This is a very poor risk management strategy; thankfully is not applied to other engineering disciplines.

Thu, 25 Jul 2024 14:36:15 +0200

Jupiter Rowland

jupiter_rowland@hub.netzgemeinde.eu

@citc

For example, using firefox web browser, _personal_ behaviour is to "skip" versions. Current version is > 15 versions newer than personal version used!

Normally, Firefox, like all good browsers, updates itself. Have you turned this off entirely so that you have to Google new Firefox versions, download them to your machine and install them manually?

Or are you running a Firefox version that's so old that it doesn't support auto-updates yet?

By the way, new Firefox versions don't ship only flashy new features that you may not need. They also fix critical security issues.

Who has the time to upgrade sequentially, version 1 to 100?

Browsers in particular a) don't necessarily have to be upgraded manually by using themselves (or other browsers) to download an installer to your machine, launching the installer and going through the whole install process step by step. They usually upgrade themselves in the background. And next time you launch them, you've got a new version without having done anything yourself.

Also, Firefox doesn't have to upgrade from one version to the next. Its auto-updater should be able to upgrade directly in one go from Firefox 1.5 to Firefox 128.0.

English proverb: "if it is not broken, do not fix it".

The Windows user's credo: "Install once, update absolutely never because updates are always such a hassle."

And so you have people who unironically daily-drive Windows XP SP2 on a machine connected to the Internet through a provider-issued router. Said Windows XP hasn't even received all patches or updates that were released for SP2. A round-about 20-year-old Norton or Kaspersky or McAfee install "secures" the system. And apart from some websites not working in IE6 as they should, the machine works. So why change anything?

Thu, 25 Jul 2024 15:01:15 +0200

citc

citc@zotum.net

Not a microsoft user, therefore used to full control. Firefox, as well as the computer operating system, are disabled to prevent _any_ changes without _personal_ permission.

Thu, 25 Jul 2024 15:01:33 +0200

Mark Nowiasz

buckaroo@hub.netzgemeinde.eu

@Jupiter Rowland

Normally, Firefox, like all good browsers, updates itself.

To be hones, this is something that I really, really hate, like the nudging (Version XYZ of foo is available). I want to be the one that determines when what software will be updated and I definitely don't want to be pestered into updated. That being said...

Who has the time to upgrade sequentially, version 1 to 100?

.
Me. On my Windows machines: choco upgrade -y all, on my Gentoo Linux machines: emerge -uDN @world @system Works like a charm, no nudging/pestering necessary.

I usually do it - pending really important CVEs, of course - on Friday, because on Saturday I usually backup my backups (so to speak) to an external hard drive.

Thu, 25 Jul 2024 15:05:45 +0200

Der Pepe (Hubzilla) ⁂ ⚝

pepecyb@hub.hubzilla.hu

@citc

Important word, "constantly".

I think "constantly" in this context means "always" and I think it's about the principle of updating.

Surely it was not meant that you should update all intermediate versions individually from a significantly older version. This is hardly possible with Hubzilla if you take the official route (utils/udall). With this script, Hubzilla is always updated to the latest release version.

English proverb: "if it is not broken, do not fix it".

Well... let's take a look at the updates that have taken place this year: they included 73 bug fixes. Only from version 8.8.5 to 8.8.6 were at least no bugs fixed. Hubzilla was not broken, but there were errors. Fixing them is legitimate and necessary.

Bug fixes are usually very important because they eliminate errors in use and, above all, security risks.

It is up to the user or network manager to decide, not a programmer who cannot possible know every environment.

You are presenting it as if @Mario Vavti is ‘forcing’ users or administrators to always and immediately carry out updates. He doesn't and he can't do that. He introduces new releases and recommends carrying out the update. But nobody is forced to do so.

Anyone who is of the opinion that an old version of a program (such as Firefox) is safe for themselves and can be used without hesitation... please, everyone has to judge for themselves and decide for themselves.

Anyone who is of the opinion that they can continue to use the old version of Hubzilla... also ok. That's also up to you to decide.

But at the moment when it is not a single-user instance, you should check your conscience. If you want to accept possible security risks for yourself that have been eliminated by bug fixes in a new version, that's ok... but you may be risking the security of other users of your instance. As the operator of an instance that is also open to other users, you also have a great responsibility... many admins may not even realise this.

It is impossible for an upgrade to be guaranteed success, therefore to tell people that they must upgrade, is fundamentally poor application of the scientific method.

Once again: Nobody says that an update MUST be carried out for a new release. It is usually recommended... and usually for good reason. But nobody is forced to carry out an update. Possibly at your own risk.

Software people seem to embrace this "move fast, break things" mentality.

I don't see this behaviour with Hubzilla. The frequency of updates is not extremely high. Most of them are minor releases with bug fixes (if an improvement or new function is ready, there's no reason why it shouldn't be included).

Above all, however, Mario reacts very quickly to real, critical bug reports, and then it can also happen (quite rarely) that two updates are released in quick succession. But then for the aforementioned reason.

Overall, Mario in particular is doing a very good job for Hubzilla in my eyes... and he really doesn't suffer from "featureitis".

Thu, 25 Jul 2024 15:21:28 +0200

citc

citc@zotum.net

Seems relatively high risk that after so many years, the team is so small. How sustainable is the management?

What is the general trend in bugs; is the quantity of bugs decreasing over time? If yes, this indicates good improvement and therefore gives good confidence.

Thu, 25 Jul 2024 15:59:02 +0200

Jupiter Rowland

jupiter_rowland@hub.netzgemeinde.eu

@Der Pepe (Hubzilla) Something else that should be mentioned, that might be of importance: compatibility with other versions and with other projects.

For example, sure, it's possible to keep a hub running on Hubzilla 3.0 from 2018 if you've set it up back then and never updated it.

But I don't think that Mario ensures perfect, 100% backwards compatibility that makes it safely possible to clone a channel between that hub and one that runs Hubzilla 9.2.1, especially seeing as Hubzilla introduced Zot6 in 2020.

So if you run a public hub with open registrations on Hubzilla 3.0, and users on your hub complain about cloning or syncing between instances being messed up, don't blame Hubzilla as a whole. Don't blame Mario for not supporting cloning between two hubs that are over six years and six major releases apart. And don't blame the other hubmins for running a much newer version than you.

Also, the newer a Hubzilla version is, the better its compatibility with non-Hubzilla Fediverse projects is. If today's Mastodon 4.2.10 doesn't play nicely with over-six-year-old Hubzilla 3.0, there's no point in filing a bug on Mastodon's GitHub about it.

Thu, 25 Jul 2024 16:05:43 +0200

Jupiter Rowland

jupiter_rowland@hub.netzgemeinde.eu

@citc

What is the general trend in bugs; is the quantity of bugs decreasing over time? If yes, this indicates good improvement and therefore gives good confidence.

New versions of Hubzilla generally remove more bugs than they introduce.

It's safe to say that the current version, Hubzilla 9.2.1, has the fewest bugs in at least recent history.

By the way, just because a bug was reported at some point, doesn't mean it was necessarily brand-new. In Hubzilla's code repository, bugs are often reported after having been around for years, but either nobody has noticed them, or nobody has reported them yet.

Also, bugs in Fediverse software don't always come to exist because the devs push out a new version with new, bleeding-edge features. They may just as well come to exist because another Fediverse server application changes, therefore breaking compatibility with Hubzilla as it is right now.

Thu, 25 Jul 2024 16:52:56 +0200

elmussol

elmussol@streams.elsmussols.net

Hat's off to @Giac El Vecio for finding new and innovative ways to push the envelope on finding edge cases for interaction between the various bits of the Fediverse. Con amor.

Thu, 25 Jul 2024 17:31:31 +0200

citc

citc@zotum.net

> But I don't think that Mario ensures perfect, 100% backwards compatibility that makes it safely possible

One person is a risk; a surprise after so many years. Consideration of the various bugs associated with nomadic identity clones, people should be informed somewhere, which version that this feature is no longer available.(example: clone and/or json file created with version '1`', is not compatible with version '2'). "Blame" is not necessary, only good documentation for people to decide themselves.

It would be good to see some numbers; example how many bugs in 2010, 2020, 2024

> They may just as well come to exist because another Fediverse server application changes, therefore breaking compatibility with Hubzilla as it is right now.

This seems far too common, indicative of insufficient strategic design.

Rhetorical question: how many programmers think about a so-called new feature, with no care for impact beyond their software? Such a thought makes the upgrade "recommendation" a mandate.

Thu, 25 Jul 2024 17:56:38 +0200

Jupiter Rowland

jupiter_rowland@hub.netzgemeinde.eu

@citc

This seems far too common, indicative of insufficient strategic design.

What would be sufficient strategic design?

If @Mike Macgirvin ?️ had laid out a development schedule for Mistpark, Friendica, the Red Matrix, Hubzilla, Osada, Zap, Mistpark 2020, Redmatrix 2020, Roadhouse and the streams repository for the next centuries to come with the intention of not even deviating from it only by a yotta, come what may? Oh, and for the rest of the Fediverse, Mastodon included, so it won't interfere with his plans?

Thu, 25 Jul 2024 18:30:05 +0200

Der Pepe (Hubzilla) ⁂ ⚝

pepecyb@hub.hubzilla.hu

@citc

The versions 4.0 from 8/03/2019, where the Zot6 protocol was also implemented, were important for internal compatibility... and 5.0 from 5./11/2020 where the complete switch to Zot6 was finally made. The v.4.x series was therefore practically a transition period where the old and the new protocol worked.

As far as I know, however, there are hardly any versions older than 8.x on the net (most are on 9.x anyway, 8s are only a handful). There are two really old(!) hubs... v. 3.2.1 (Hubzilla | Stephan Maus), a single-user instance and v. 4.4.1 (NymCub), an instance with two users. I don't know whether these are actually still being ‘used’, i.e. are active. I suspect that they are ‘corpses’.

The question of compatibility does not really arise at the moment. Nobody will be crazy enough to download a 3.x archive and then install an ancient version as a production system. Anyone setting up a new hub will pull the latest Git and thus have the latest version anyway.

It would be good to see some numbers; example how many bugs in 2010, 2020, 2024

This could be done by filtering in the repo (Issues), whereby there are also bug fixes where the error was reported here in the support forum, for example, but which never found their way into the error messages in the repo.

This seems far too common, indicative of insufficient strategic design.

Well, that's down to the other projects and not Hubzilla. One example from the recent past is the crappy display of posts of the type "Article" on Mastodon. Because they don't want to display them properly in the timeline, the "article" type has been put on ice as a federated post (it exists in ActivityPub, so it is intended) at Hubzilla for the time being.

Thu, 25 Jul 2024 19:00:28 +0200 zuletzt bearbeitet: Thu, 25 Jul 2024 19:03:11 +0200

citc

citc@zotum.net

@Jupiter Rowland

What would be sufficient strategic design?

Do not know, but looks to be very difficult. Perhaps the answer are regular meetings of "work groups" , but this requires high level collaborative skills. Most programmers display a selfish ego about "their" way being superior.

> The question of compatibility does not really arise at the moment

This does not show to be true, otherwise clones of accounts, channels would always be successful. It is not.

Thu, 25 Jul 2024 19:11:54 +0200

Jupiter Rowland

jupiter_rowland@hub.netzgemeinde.eu

@citc

Most programmers display a selfish ego about "their" way being superior.

Including Eugen Rochko and his entire staff of software developers.

Thu, 25 Jul 2024 19:16:17 +0200

citc

citc@zotum.net

Significant effort is necessary to grow the number of hubzilla programmers. Good software "per se" is not enough in the real world.

Thu, 25 Jul 2024 19:34:10 +0200

Der Pepe (Hubzilla) ⁂ ⚝

pepecyb@hub.hubzilla.hu

@citc

This does not show to be true, otherwise clones of accounts, channels would always be successful. It is not.

I have just done a test to check this statement. I registered with a hub with version 8.8.7 and then cloned a channel from my own hub (v. 9.2.1) there. No, absolutely no problems. A perfect clone.

WHAT are the problems with channels and cloning that you mean?

I have not encountered any cloning problems so far.

Thu, 25 Jul 2024 20:41:33 +0200

elmussol

elmussol@streams.elsmussols.net

Known @Mario Vavti (and @Mike Macgirvin ?️) for a long time and this doesn't fit. Confident that we are doing things a better way, sure, ego driven, nope not really.

Thu, 25 Jul 2024 20:45:55 +0200

_jayrope

jrp@hub.kliklak.net

@citc @Der Pepe (Hubzilla) I may add, that most of those weird problems seem to come from zotum... just a statistical remark, no pun intended. However, maybe there isn't much maintenance there, care in general, or more simply just a very specialized server config? I can't say. But i am self-hosting HZ since more than a year and have none of those problems, ever. All runs smoothly, and any troubles i have are thanks to my own customizations.

Thu, 25 Jul 2024 21:30:20 +0200

Der Pepe (Hubzilla) ⁂ ⚝

pepecyb@hub.hubzilla.hu

most of those weird problems seem to come from zotum

I have also suspected this for some time.

Fri, 26 Jul 2024 09:42:40 +0200

od@zotum.net

@Mark Nowiasz

Who has the time to upgrade sequentially, version 1 to 100?

.
Me. On my Windows machines: choco upgrade -y all, on my Gentoo Linux machines: emerge -uDN @world @system Works like a charm, no nudging/pestering necessary.

Out comes the ego...

The question is general; everyone should expect the real world answer to be (nerds, computer science professors, IT technicians yes, everybody else no)

Fri, 26 Jul 2024 09:46:01 +0200

od@zotum.net

@Der Pepe (Hubzilla)

I have just done a test to check this statement. I registered with a hub with version 8.8.7 and then cloned a channel from my own hub (v. 9.2.1) there. No, absolutely no problems. A perfect clone.

WHAT are the problems with channels and cloning that you mean?

This a a common mentality with the software world. Do one test personally, see success, then conclude that there is no problem.

Fri, 26 Jul 2024 09:51:54 +0200

Jupiter Rowland

jupiter_rowland@hub.netzgemeinde.eu

@od Fediverse software has to advance at a certain pace.

Critical, deal-breaking bugs have to be fixed ASAP.

Security holes have to be patched ASAP.

If Mastodon changes something that requires Hubzilla to change something itself or face defederation by incompatibility, Hubzilla has to do that ASAP.

Hubzilla can't afford a Debian-style two-year period of field testing such changes before rolling them out as stable, just for some people to wait for another six years until they let these changes at their own instances when they personally feel these changes have proven to be rock-solid stable enough.

Fri, 26 Jul 2024 10:00:11 +0200

od@zotum.net

@_jayrope

I may add, that most of those weird problems seem to come from zotum...

OK, but again, the typical nerd response ("host yourself"; "be a computer scientist/programmer/etc. to solve each problem") is not a real world answer.

If poorly configured server software exists in the public (similar to the option to display spam), the long term potential damage to hubzilla will occur.

Fri, 26 Jul 2024 10:08:51 +0200

od@zotum.net

@Jupiter Rowland
Sorry, but disagree.

It is not mandatory to follow the woolly mammoth, because of your personal preference to have a happy communication with your woolly mammoth connections.

The debian analogy is an excellent example, no coincidence of debian's reputation, longevity, stability, respect and significant community of users, programmers. Notice the claim that a personal test of stability is more superior than consensus. Out comes the ego again...

Fri, 26 Jul 2024 10:10:07 +0200

Ema エマ

ema@utasansh.in

@od We ask you to not get personal. Just describe your problems as detailed as possible so that people can actually try to help. Versions of involved hubs (origin, destination) and possible special configurations. State your steps and when and how you realized that cloning was not working. Also if you did a retry.
Mutual support is based on voluntary action. When you attack people, you close doors that were open. If these people open the doors again, then you're in luck.

Fri, 26 Jul 2024 10:18:25 +0200

od@zotum.net

Here we go.

Who is "we"? Where is the "personal"?

> When you attack people, you close doors that were open. If these people open the doors again, then you're in luck.

Total rubbish. You have already exhibited patriarchal behaviour ("don't like the style, don't like the message, let us close down debate")

If anyone feels attacked ad hominen as apposed to the observations, they are free request an apology.

Fri, 26 Jul 2024 12:07:10 +0200

Der Pepe (Hubzilla) ⁂ ⚝

pepecyb@hub.hubzilla.hu

@od

This a a common mentality with the software world. Do one test personally, see success, then conclude that there is no problem.

No, this is my way of getting to the bottom of possible problems when it is claimed that cloning and nomadic identity do not work without concrete examples, concrete misbehaviour in the instance of the reporting party, a concrete and detailed error description.

We do not know what problems you have encountered, what actually went wrong with you, what the environmental parameters were when the problem occurred.

If errors are claimed without more precise details, then my alarm bells go off and I carry out tests myself, because there could actually be an error. In this case, I selected one of the few hubs (registration open) with an older server version (there are hardly any) in order to possibly track down possible problems between the old and current version.

I didn't notice anything... and I'll let you know. Now it would have made sense for you to specifically name the problems (when, where and how it went wrong for you), which is what I asked for. Instead, I have to hear that I have a bad mentality.

So please again: What do you think is the reason why cloning doesn't work? What error did you encounter? What were the environment parameters (HZ version of the source hub, HZ version of the target hub, which hubs specifically, how did you try to clone... via file or network import)? What worked? What did not work?

Without this information, the claim in the initial posting is just an insubstantial accusation.

This is now my last attempt...

Fri, 26 Jul 2024 12:17:17 +0200

Jupiter Rowland

jupiter_rowland@hub.netzgemeinde.eu

@od

Who is "we"?

The owner of the channel @Hubzilla Support Forum and everyone who has moderator rights on the channel.

Fri, 26 Jul 2024 13:41:07 +0200

citc

citc@zotum.net

@Der Pepe (Hubzilla)

I have just done a test to check this statement. I registered with a hub with version 8.8.7 and then cloned a channel from my own hub (v. 9.2.1) there. No, absolutely no problems. A perfect clone.

WHAT are the problems with channels and cloning that you mean?

This reminds of the replication crisis in scientific research (important to realise from scientists' perspectives: replication is _not_ same as reproduction).

Does the computer industry not have some repository of systems somewhere, for people conduct tests in different permutations of environments? In this scenario, some sort of way to test _all_ versions, just to see the results?

Fri, 26 Jul 2024 14:08:47 +0200

Jupiter Rowland

jupiter_rowland@hub.netzgemeinde.eu

@citc

Does the computer industry not have some repository of systems somewhere, for people conduct tests in different permutations of environments? In this scenario, some sort of way to test _all_ versions, just to see the results?

This wouldn't be feasible.

Hubzilla has 99 releases on Framagit, but they only date back to version 1.12 from 2017 whereas Hubzilla was released in 2015. So there have to be more.

If you want to be on the safe side, you also have to add Red/the Red Matrix into the mix which Hubzilla used to be before it was Hubzilla. Red had 19 stable releases.

So let's assume 130 releases of Red, the Red Matrix and Hubzilla.

If you want the option to compare all of them with all of them, that'd be (130 * (130 - 1) / 2) = 8,385 combinations.

However, if you really want to be on the safe side, you'll have to take the underlying system into account. There are hundreds of Linux distributions. Any one of them could host a Hubzilla hub.

But you wouldn't be limited to each distro once. For non-rolling releases, you'd have to take into account each version that was officially supported at some point at least in the last five, if not even ten years. For Debian, this means seven versions all the way back to jessie (5 years) or nine versions all the way back to squeeze (10 years).

For rolling releases, you'd have to test each thinkable and possible combination of package versions (kernel, base files, Web server, PHP, database etc. etc. pp.) several years back.

And, of course, you'd have to take different Web servers as well into account as MySQL vs MariaDB vs PostgreSQL.

So yes, you'd have to take even edge cases into account such as someone running Hubzilla 3.8.8 on a server that's stuck on Ubuntu 16.10 "Yakkety Yak", but with nginx installed from Debian 6.0 stretch .deb packages and PostgreSQL manually compiled from manually patched sources in March, 2017.

Not even Microsoft has enough developer capacities for this to be even possible, much less feasible.

Fri, 26 Jul 2024 14:24:11 +0200

Harald Eilertsen

harald@hub.volse.no

@citc

Does the computer industry not have some repository of systems somewhere, for people conduct tests in different permutations of environments?

Sure it does. If you can pay for it.

Fri, 26 Jul 2024 14:36:52 +0200

Max Kostikov

kostikov@zotum.net

@Harald Eilertsen

Thanks! You really know how to make people value your input.

This is common for this person, so just ignore it.

Fri, 26 Jul 2024 14:47:36 +0200

od@zotum.net

@Der Pepe (Hubzilla)

Instead, I have to hear that I have a bad mentality.

So please again: What do you think is the reason why cloning doesn't work? What error did you encounter? What were the environment parameters (HZ version of the source hub, HZ version of the target hub, which hubs specifically, how did you try to clone... via file or network import)? What worked? What did not work?

Without this information, the claim in the initial posting is just an insubstantial accusation.

The bad mentality of the computer industry is not a criticism of individuals, it is an observation of common behaviours.

Ignore claim in this post, you can do as you want.

Others:
https://hubzilla.org/item/93de1590-a3e1-42c3-bfc1-3a85437136f4
https://hubzilla.org/item/3d44c288-3f2c-4f7f-a0d8-6af02439dc5a
https://hubzilla.org/display/f8353ad7-903d-4c5b-9bbc-5affb92b63de

Fri, 26 Jul 2024 15:16:11 +0200

Harald Eilertsen

harald@hub.volse.no

@Max Kostikov No worries, I do :) There's plenty of people in the community that has more constructive feedback, so I rather focus on their needs.

Sat, 27 Jul 2024 07:15:25 +0200

Tetris Life

tetrislife@zotum.net

I don't understand how the "we" here went along with the change in tack from "updates should be optional" to "sustainability of development"! Could atleast have got @citc to start a different thread. And responding to @od's insinuation about " developer ego", instead of pointing out the hubris of not providing version and platform details of what didn't work!

You folks are too nice for the Internet! A little pushback, please!

Sat, 27 Jul 2024 12:33:39 +0200

citc

citc@zotum.net

@Jupiter Rowland

These numbers are not problematic; pharmaceutical research is orders of magnitude larger. It is the sort of "thought experiment" that would be interesting to see done as "citizen science": volunteers around the world using their various computer resources. The bigger issue is that programmers seem disinterested in robust tests; there seems to be a continual, constant promotion of the so-called latest version.

As a scientist, backwards compatibility, stability are priorities. Files of presentations, documents of questions, reactions, diagrams etc., that are decades old, want to be viewed and used without worry about accessibility.

Accessibility is becoming an increasing problem because computer people forget that these objects (software, hardware) are _tools to do a job_. As an outsider, the analogy is a toolbox with spanners, screws, hammers. How is that bolt going to be fitted, if the latest version is a different design? How many designs are needed? Why is so much time spent to discuss the tools, without context about the purposes of the tools?

Personal motivation:
@Baldur Bjarnason
@Carl T. Bergstrom
https://calnewport.com
@Robert W. Gehl
@Cory Doctorow

Sat, 27 Jul 2024 20:53:21 +0200

Bill Statler

billstatler@forum.statler.ws

Simple solution: Hubzilla needs to hire 5-10 more developers. Since they are unpaid, this could be done at zero cost. I don't understand why that hasn't happened.

;-)

Sat, 27 Jul 2024 21:11:55 +0200

_jayrope

jrp@hub.kliklak.net

@Bill Statler I did almost choke with laughter ::))

Sat, 27 Jul 2024 21:23:31 +0200

Jupiter Rowland

jupiter_rowland@hub.netzgemeinde.eu

@citc

These numbers are not problematic; pharmaceutical research is orders of magnitude larger.

I seriously doubt that.

Let's suppose we test Hubzilla 9.2.1 on 300 different Linux distributions in an average of 6 stable versions each. Let's assume that's 120 combinations of kernel and base files for each one of them. This means 48,000 combinations.

Let's suppose each of them can theoretically have 200 versions of Apache plus 200 versions of nginx, 250 versions of MySQL/MariaDB plus 250 versions of PostgreSQL and 2,000 combinations of versions of PHP packages.

So for testing Hubzilla 9.2.1, that'd be 19,200,000,000 combinations.

But we want to test Hubzilla 9.2.1 against all versions of Red, Red Matrix and Hubzilla ever released.

Let's assume 130 stable releases. But instances may run pre-release versions; Zotum does. So let's expand this to 700 releases.

These run on an even greater variety of versions. 300 distros, but an average of 15 versions with 3,000 combinations of kernels and base files each. This alone means 900,000 base system variants.

Now let's assume 1,200 Web server versions, 1,500 database versions and 5,000 combinations of PHP packages.

This means we've got 8,100,000,000,000,000 systems that can act as the servers for 700 versions of Red, Red Matrix and Hubzilla. All in all, we're talking about 5,670,000,000,000,000,000 possible combinations of Red/Red Matrix/Hubzilla servers to test our 19,200,000,000 Hubzilla 9.2.1 hubs against.

That's 108,864,000,000,000,000,000,000,000,000 pairings between a Hubzilla 9.2.1 hub and a hub to test Hubzilla 9.2.1 against.

This is bound to fail because there aren't even enough computers on this planet to permanently run each possible server setup 24/7.

And this doesn't even take different configurations into account.

Sat, 27 Jul 2024 22:14:07 +0200

Der Pepe (Hubzilla) ⁂ ⚝

pepecyb@hub.hubzilla.hu

Ingenious calculation example, @Jupiter Rowland ???

But the fundamental question would be: WHY? What is the purpose of this?

If there were significant problems between average current Hubzilla installations on average server environments, we would know about it with several thousand users and around 80 (recorded) hubs. And that for exactly one Hub that is still running a 3.x version (how sick is that?), exactly one that is running 4.x (hmmm) and one that is running 5.x? One hub is 1.25% of all hubs.

The 3 hub is a ‘cadaver’ with one registered user and 0 active users, the 4 hub is also rather ‘dead’ with two monthly active users and the 5 hub seems to be a closed group with only two public postings and an average of 11 active users per month (although it is on the net, it is more of a club).

Why should such old versions, of which there is just one hub each, be tested for compatibility in any way?

This is a problem that doesn't even exist.

Sat, 27 Jul 2024 23:35:09 +0200

citc

citc@zotum.net

@Jupiter Rowland

Surely you realise chemical permutations and impacts on biochemistry; you've done some simplistic calculations that barely equate to a few moles of substances, but there is no need to divert the thought experiment into chemistry. ;)

As a thought experiment into design of suitable tests:

Is it necessary to test each hubzilla version on each gnu/linux version?

Is not the purpose of tests to reveal bug? Some bugs may be recessive and only emerge in unplanned or old versions. Whether this is beneficial or not, do not know, but wider and improved tests surely can only be good.

Sun, 28 Jul 2024 04:12:03 +0200

Tetris Life

tetrislife@zotum.net

@Bill Statler it hasn't happened because of PHP. Rewrite it in ... Erlang.

Sun, 28 Jul 2024 12:55:43 +0200

_jayrope

jrp@hub.kliklak.net

@citc @Jupiter Rowland @Bill Statler I do believe, that the testing going on after a new version has been released is good enough for the vast majority of cases, and @Mario Vavti and others have been recognized to fix bugs swiftly, which weren't occuring in dev versions/testing before. Let's not turn a mouse into an elephant.