You can call it a Facebook alternative if you need to call it something. I just don't know whether that's true or not, because it may have been true back in 2010, but I *don't use Facebook*. So I don't really know whether or not that label might still apply.  For all I know they've now got a fizzlewig feature and people will resent something being called a Facebook alternative if it doesn't support fizzlewigs.

Next I tried free and Open Source Live on USB flash drive - and it worked from the first attempt!
Now I'm enjoying a speed of a new SSD with all my apps and data from HDD preserved :-)

I spent two evenings (officially) trying True Image to migrate from HDD to SSD. And it failed three times!
1. Failed to create backup image (invalid copy of main Windows partition), but told that backup completed successfully.
2. It told me that it couldn't restore that image to a new drive only after 2 hours of Restore process.
3. It refused to proceed with Backup, when I launched it from a boot device that it created, telling me that this is not available in a trial version...

After a long break I tried Profiler in Android Studio looking for a way to optimize performance of #AndStatus. And now it not only works, but allows me, at least on #Android emulator, to see most lengthy operations. As a result, a timeline loads at least three times faster. To be released in AndStatus v.39.
Profiler allows you to record your application's activity and present it as "Call chart", where you can see durations of execution for each method in the stack and easily figure out most lengthy.
Clicking on the method's bar in this call chart brings you to its source code...
I found out that Regex-related methods are the most time-consuming, and optimized them both via using compiled Pattern instead of regex strings, and by executing lengthy operations once only (i.e. I store result of such checks and reuse it later instead of repeating costly operations).
Doc on the #AndroidProfiler : https://developer.android.com/studio/profile/ https://loadaverage.org/attachment/4309407
@jaller94 Thank you very much for the contribution. The https://github.com/fastlane/fastlane really looks like a unifying way to store metadata for both F-Droid and Google Play, both of which #AndStatus uses.
I was especially impressed by the tool's (advertized...) feature "fastlane supply init: download metadata for an existing app to a local directory", which I understand as ability to initialize metadata with what is already stored in Play Store...
As you may know, AndStatus already has quite a lot of screenshots in Google Play Store https://play.google.com/store/apps/details?id=org.andstatus.app plus several (duplicating them...) - in AndStatus Wiki repository, see: https://github.com/andstatus/andstatus/wiki
It would be good to synchronize them, store in a single location and make available for all usages.
This is why I think that I should start with importing existing images / metadata from Google Play Store, and only after that update that images (if necessary) with your contributed screenshots.

Repost: The sad state of affairs in the social network and social forum world ..… Show more

The industrialisation of healthcare has made healthcare less about healing and more about treatment. The same thing can be said for the cybersecurity industry. nytimes.com/2018/02/24/opinion
URL: identi.ca/avadiax/note/ma8Asmb

Just finished reading Thinking in Java Fourth Edition by Bruce Eckel published in 2006. Although the book describes the state of Java of more than ten years ago, it still contains many valuable observation, explanations and advices. Due to the book's age, it should be read with a caution, more as a philosophical and historical book than as a student's textbook.
Anyway I didn't find any new book comparable by its quality with this one. Amount of work and mind put in it shows.
Thank you, Bruce!

Revelation of the day: "Compare Tab With Editor" plugin for IntelliJ Idea solves a problem comparing files, located far from each other in the file tree, when it's hard to scroll from one file to be compared to another.
Now you can compare just two Editor tabs.

Currently I'm refactoring User-related part of #AndStatus data model using recent amendments of #ActivityPub specification, which I initiated: distinction between a User (a real life person or an organisation...), Accounts of this user in concrete instances (Servers) of the global social network, and an Actor - the entity, which is actually present in Activities of the ActivityPub protocol.
Very helpful clarifications, allowing me to express clearly relations between different things inside the application. For example, now I'm working towards creation of views on a User across all networks, logically merging Actors of this User.
As a result, at the first step you will see e.g. actions/messages by andstatus@quitter.no Actor as actions by ONE Actor, even if you see these actions via several Servers, e.g. via mastodon.social and via GnuSocial.no, as on the attached screenshot.
The next step will be to merge Actors of one User into one view. E.g. set andstatus@loadaverage.org and andstatus@mastodon.social Actors as _one_ User. This cannot be done automatically due to current limitation of the #ActivityPub specification, but at least can be done manually for selected Users that you follow via their Actors in different networks... https://loadaverage.org/attachment/4021406

"A general guideline is “Use inheritance to express differences in behavior, and fields to express variations in state.”"
Bruce Eckel

@verius @veg05 The issue we have is that Mastodon dominates ActivityPub and anything that project decides to do on a whim is being written and hardwired into ActivityPub policy and is driving the specifications. Most of these decisions are short-sighted decisions that only benefit Mastodon, but they affect and limit all future uses of ActivityPub to the lowest common denominator of what works best for Mastodon. So basically they're strangling and killing the protocol before it even has a chance to be a multi-platform communications tool. To be fair, ActivityPub started with a bucket load of problems and none of them have yet been solved in a meaningful way. The specification is weak where it matters and too restrictive where it doesn't matter. If you bring an ActivityPub implementation to the table as we've done, it doesn't matter that you've tried to allow it to federate with the rest of the metaverse and be a communications tool on a level playing field. Your implementation is measured only by how well it federates with Mastodon. The level playing field has already been destroyed. Another few weeks like this and we'll have to abandon ActivityPub for any other use than communicating with Mastodon. That will be its only purpose and it will be unsuited for anything else. I'm well aware of the different federation protocols currently in use. I've implemented Diaspora, OStatus, ActivityPub and invented DFRN (friendica) and zot (red/hubzilla) and for the most part found ways for all of them to co-exist.
Why one-to-one relation of Actor to Account is an edge case; from https://github.com/w3c/activitypub/issues/260
Actor is actually User's virtual identity, their identifiable representative in a social network. Now please think about the Global Social Network ("federation of websites”), which is connected using #ActivityPub protocol.
How many different Actors would you use and how many Accounts?
I mostly use two different actors: "yvolk" as my personal Actor, and "#AndStatus” as my project's Actor. But I use (or used recently, so there is a history of my posts...) tens of Accounts to represent these two logical Actors at different Servers (websites). And I don't expect to switch to two Accounts for these two Actors any time soon. For many reasons... And as I see posts of other Users, they quite often use several Accounts e.g. for wider audience (different Servers have different audiences and different posts are visible from them...) and as a backup in a case of a server's outage or permanent shut down.
Due to limitation of most of existing Servers, each separate Account means a separate Actor (and ActivityPub copies this approach). But this is not what a User wants, when he or she creates the same ”MyCoolUserName" at different Servers. Ideally a User needs to decide if any new Account is for the same existing Actor or for a new one.
#ActivityPub currently not only doesn't give such an option. It confuses terminology and mixes User/Account/Actor notions so, that it's even impossible to express the need and clearly state current limitation of the protocol using terminology of this spec. But it will allow to clarify this using changes, resulted from this our discussion ;-)
And I see that a User who needs only one Account for his Actor, is usually a Newbie or someone, who doesn't use a Social Network actively. This is why I regard one-to-one Account to Actor relation as an edge case, not as a normal one.
More on fixing #ActivityPub spec from https://github.com/w3c/activitypub/issues/260
I understand that making "data model" correct by separating concerns would mean changes in the protocol specification, and I can understand eagerness of people, preparing the spec for a long time, to release it, at last, even not perfect. This is why I think that the most important thing now is to communicate clear and correct domain model and terminology, opening a way for future protocol improvements.
This means that decision on whether or not to fix the data model now shouldn't be anchored with changes, related to resolution of this issue #260.
E.g. despite still having "inbox URL" inside Actor object in a "data model" we should describe the URL as Account's attribute...
I continue my discussion with a team, creating #ActivityPub specification, doing my best to solve its conceptual mistake of presenting Users of the real world, their Accounts at servers and Actors of #ActivityStreams as synonyms, see https://github.com/w3c/activitypub/issues/260
From that discussion:
Account is not an Actor, it's an authorised communication channel, a way for an Actor to communicate in a Social Network using a Server... (more work on this phrase may be needed but the meaning is this). And this relation should be stated in the main part of the document, not in some "notes", exactly because this is a conceptual level statement, not an implementation intricacy...
At the edge case, which happens to be the only case currently covered by the ActivityPub spec, Actor relates to Account as one-to-one. And only for that edge case mixing attributes of Actor and of Account can be done, but only as a temporary hack, violating design patterns...
@cwebber@octodon.social Thank you for reply to the #ActivityPub issue at https://github.com/w3c/activitypub/issues/260
I followed the discussion there plus copying my follow-up below:
1. Let's go step by step. Explicitly stating that Actors and Users are different entities is a good way forward.
BTW the confusing phrase "users are represented as "actors" here" should also be changed to "users are mapped to actors" with addition, how (you suggested wording...)
Where can we see current draft for review how it looks now? You are too quick to state that the issue is resolved :-)
2. Let's check if the statement is valid:
* ""user" is technically an entity outside the protocol"
2.1 First of all the term is used tens times in the document, which describes the protocol: https://www.w3.org/TR/activitypub/
2.2. The term "user" is used for two different things, actually:
* for "natural person from a real world"
* and for "user's account at a Servetr" (my interpretation).
The second meaning is definitely "inside protocol". Just look at these phrases, from many available, for example:
* "This protocol permits a client to act on behalf of a user."
* "Client to server interaction takes place through clients posting Activities to a user's outbox"
My conclusion is that a User in the second meaning "user's account at a Server" is definitely a part of the protocol description.
3. As now we agreed on separation of an Actor from a User, let's look again, what we read in the document.
3.1 You know: there are many places, where the word user(s) should be replaced with a word Actor(s), e.g. here {again, one of many examples):
* "The Follow activity is used to subscribe to the activities of another user."
Attributes of a User are presented as attributes of an Actor in examples...
Show more

Follow friends and discover new ones. Publish anything you want: links, pictures, text, video. This server is run by the main developers of the Mastodon project. Everyone is welcome as long as you follow our code of conduct!