If this was ever added, making it opt-in is probably a better default, you are right on that. Especially since it would be something new.
1 Like
My main gripe with github accounts is that another organization than haiku has control over who may or may mot submit patches, That is more of a āwhat if they turn badā problem (I donāt think Microsoft has an interest to become notorious here, but then they are also huge and have to follow the whim of companies and lawmakers sometimes, like the youtube_dl case), itās not too much about the tracking though that certainly is part of it. I would definitely prefer there to have an ldap account i could use to submit patches, Itās not really nice to have to rely on others here :ļ»æ/ (and also locks me out of trivial patches since effort > rewards)
I donāt think HDS tracks too much, It could do so but doesnāt which i think is good. I would have no problem with a popcon type tracking, if users agree to it.
1 Like
I actually agree with you here that Haiku needs some sort of SSO for our accounts and I was originally annoyed with the GitHub requirement for Gerrit even though I have a GitHub account. I can try to look at options for account servers for Haiku. I have done a small bit with Keycloak at work, though it was very little and that was a while ago.
In addition, I should probably talk to you more about what I can do to get tracked less 
My point was HDS or the repo servers could currently log the IP address exposed by your Haiku machine, and furthermore HDS you can have an account so it could even know whose account is doing things. Which of course is required for things like comments or reviews.
Any download tracking thing I would consider would be part of the package system and designed so that it does not know or need to know your HDS account, and even on the server side we could studiously avoid logging IP addresses, etc. It would just be something like POST /download_increment id=package-name and the count for package-name gets incremented by one.
If you are against the whole concept of download counts for some other reason, that is a separate argument I think.
1 Like
Iāve spent good time thinking about this,
-
terminology largely sits outside of societal normatives for common parlance english
-
categories are too broadly defined
-
categories fall outside of common vernacular
-
UI has wall of text syndrome
-
search isnāt predictive or smart enough to use synonyms etc to allow for braoder language dialect useage etc.
-
no ranking by user reviews
-
no way to monetize developers
-
descriptions of functionality is often confusing to layperson
-
UI doesnāt offer program preview screen shots, tutorials comments etc
10 ui isnāt full screen
11 high dpi monitors can be difficult too read with default font sizes
there are many small issues lije Iām mentioning, some are simply data entry, others
design changes.
2 Likes
Maybe Iām missing something here but how is this tracking? Iām pretty sure your https connection to the Haikudepot server shows up in some log file already when you download a package (or even start the Haikudepot application)
If all that is done is simply a counter increased when you download a package there is next to no information that can be tracked back to you.
I agree with nephele that having something on the user machine sending data to some server is a bad idea for privacy reasons.
Itās also not needed: we can simply count the downloads from the package server side. The limitation is, we donāt know when people uninstall a package. Maybe they download something promising, but then uninstall it a few minutes later. But I think we can live with that.
With all the efforts we make to have our infrastructure self-hosted, it is a bit sad that github accounts are required. Please donāt blame people who donāt have a github account for that.
We should fix this on Haiku infra side, and not push people to get a Github account.
That is in no way an excuse to make things worse.
On the package repos, nothing is currently tracked (but we could collect aggregated stats, such as the total number of downloads per day or week of each package). On HaikuDepot side, I donāt know, the server gets to know a lot about what you do since it serves you several things on demand (at least screenshots, but I think also package descriptions?) and of course it stores your rating and comments if you decide to give some. This deserves a documentation page somewhere. Personally I think it is acceptable to do this without opt-in, but if we started to collect more stats (about package installation and uninstallation) I would consider these to require an opt-in. But I also donāt see what we would do with such detailed stats that we canāt do from what we already know from the package server. Do we need to know if people often install two packages together? How often they update their apps?
Also, anything we collect from HaikuDepot completely misses a whole set of our users or use cases where only pkgman or other installation methods are used. So the data wouldnāt even be all that useful.
I am still suggesting a website with lots of infos about software available for Haiku to discover. An easy and fast solution first.
This would be the fastest way to solve the problem to find accurate Software for new Haiku user.
Haiku is still Beta 2. So no need to be perfect here.
Haiku should become a heaven to develop for, yes. developer first.
So said it would be good to focus on a developer friendly Haiku Environment first.
Haiku is still Beta2ā¦
There should be a category for Haiku-native applications. Like, āNative Picksā.
4 Likes
I see the point but Iād rather present them as āDesigned for Haikuā. As long as you donāt need an emulator of some kind to run an app, you can say that it runs nativelyā¦
3 Likes
Change the wording as you see fit. 
You can see HDSās persisted data model here which is mostly up to date. You will observe that in the context of this discussion, the only thing of note recorded against the user are the user ratings. If you want to verify this then the source code is available for analysis. I can however only make comment on the HDS logic and not on anything at the infrastructural level.
HDS also keeps track of how many times users have viewed a version of a package. Unfortunately it only captures this from web-viewings at the present time. (I just opened ticket 16814 to make views from HaikuDepot count as well ā it would be quite easy to do actually. Maybe this needs an opt-in.) This counting mechanism avoids multiple views of the same package in a short space of time by keeping a one-way secure hash of the usersā IP addresses in memory only. This mechanism means that the data is collated in an anonymous manner from the perspective of HDS. You can see this on the model as view_counter on the pkg_version entity in the model diagram.
See here. This is a community project including this document so if you want to discuss this document then please do this on the HDS mailing list.
I tend to agree.
1 Like
This is also on the list here. Still comingā¦
1 Like
I should also note that the HDS system also streams out diagnostic logs that may contain information about usersā activity, but HDS never reads those logs back in.
On the other hand, on some operating systems developers, either OS developers or 3rd part, have fallen into the trap that something /looks/ very similar to some standard OS feature (like the olde Macintosh Finder or BeOS/Haiku Tracker) but behaves differently in several ways.
For instance, if a view which shows all the OS control panels looks very much like a folder window, but I canāt do all the same things in it that a real folder window permits, thatās confusing. It doesnāt matter that somebody thought some of those actions ādonāt apply to control panelsā or simply havenāt been implemented yet. What matters is that something which looks like it is a āThing1ā should behave entirely like a āThing1ā (and should not behave like āThing2, with a mask on its faceā).
2 Likes
Can we at least get a āCancelā button?
Itās kinda frustrating when an app install hangs and you have to kill the whole depotā¦
5 Likes
I am for separating HaikuDepot and managing installed packages. Maybe I will write InstalledPackages utility in HaikuUtils that will show list of installed packages including BeOS *.pkg packages. Also it will be able to hide auto-installed packages and auto-remove that packages.
Also it will be nice to have āmulti-packagesā: one file with multiple HPKG files inside so packages with a lot of dependencies like Libreoffice or Krita can be distributed by one file. When installing, already installed HPKGs will be skipped. Multi-package can also include repository URL for auto-update. Multi-package runtime can be implemented as 3rd-party component.
Generally I prefer web browser over package manager application because it is more flexible and donāt require adding additional repository URLs. BeOS SoftwareValet also opened NetPositive with package catalog instead of providing its own.
2 Likes