Haiku, Inc. in Contempt of Its Community
I was watching the discussion on the mailing list because a user here posted this discussion in the forum (where I wouldn't have picked up on it at the mailing list because I generally don't read it).
Why do the administrators here censor valid discussions? Even if his technical explanation was/wasn't accurate he was right about one thing. If someone says something against Haiku, or package management, as he described; their comments get deleted, they get blacklisted, censored - that's sad. Of course Haiku developers, Haiku Inc. the administrators, can do whatever they want, it's their website - but it shows how close-minded, unwilling they are to discuss things or show that others think differently.
It would be nice if the administrators here would repost his post to show they are inclusive to discussions of all types (as many claim on the mailing list).
Comments
Re: Haiku, Inc. in Contempt of Its Community
For people interested in the troll posting: see mailinglist.
Before people cry "unfair" in categorizing him as troll, the original poster didn't engage into the conversation besides one strawmen filled posting.
Also, see the other recent "contribution".
Re: Haiku, Inc. in Contempt of Its Community
Karl, if you want to read more from this guy you should check out his blog: http://haikuossucks.blogspot.co.nz/
This fourm also states: "We reserve the right to moderate posts of an aggravating nature".
Trolling clearly falls under 'aggravating nature'
Re: Haiku, Inc. in Contempt of Its Community
Hi kvdman,
i follow the forum closely (as you can see thats that i often comment on new toppics). I didnt recognized that he posted here something.
And as you can se from the mailing list he is a rellay misbehaving troll (set up different mail accounts, sending nonsense to the mailing list and so on).
If it might happen that his post got delted because he just used the wrong way to communitcate. As far as i have learnd the haiku community is one of the moste polite.
And as you can see from the verry open mailinglist discussion the developer are always open to well-founded criticism.
I can understand that you are disappointed about the packagemanagement but acutlally i think its the future to go. I was also suprised by the way it turned out, but i really feel now this is the way to go.Acutally packagemenagement brought my intrest back into haiku (after i was frustrated about the lack of elegance of the layout api :-D).
Actually.. if you are willing (and i think you are more than capable) you could set up a hpkg repository for haiku (haikuware ;-) wich could be added to the haiku depot. And maybe could be the first Depot where developer can easily upload there packages and user can download it over the build in Haiku Depot app (or maybe you jump into the online frontend development).
At the moment there is no similar funciton in the main repository.. i am not shure how apps get added there at the moment.
This would be super awesom because i am not at all a friend of haikuporter.... for me this thing is way to much the "linux" way. :-D
Re: Haiku, Inc. in Contempt of Its Community
Hi folks,
I realize package management is the way to go (even though the open-ended contract cost a lot of money and the resultant product doesn't work properly after ~1.5 years). However, this particular post wasn't a troll's post - other posts of his perhaps.
I clearly recognized the technical detail into writing in the forum what he wrote, and it was the most sound argument I had ever seen criticizing package management; it must have taken him at least 2-3 hours just to write what he wrote - I thus felt sorry for him when the post was just deleted by the moderators! This was early Eastern Standard Time ~ 6 a.m.
Also the highly technical post he put on here (with the same subject name I used, isn't on the mailing list (perhaps it was deleted there as well).
So, I encourage the moderator to re-post his post. To prove that it was purposely moderated, here's the URL:
http://www.haiku-os.org/community/forum/re_haiku_inc_contempt_its_community
So, please re-post it for the public to see, and please advise us what he was trolling by that technical post and lets discuss it. Failure to re-post it and let us analyze will prove contrary, that Haiku or its moderators censor unreasonably and accuse people of trolling. I fail to see how that post was of an aggravating nature. Like many people know, Haiku's core just can't take valid criticism, even Haiku Inc. and the way it operates. Criticism is good, it makes people think, and brings about change. I volunteered to be on the board of directors at Haiku Inc. many times but always get ignored (even when their own board members state that the board 'is in crisis mode'). When I do criticize something, I am usually right about it, however annoying or unpleasant that is. Every democracy functions with an opposition that holds people accountable - that's not what happens at Haiku Inc (of course one would argue that Haiku isn't a democracy bla bla, but it sure would function a lot better if it were run more that way!). That's a side issue with the respect to the way Haiku Inc. is run, but it gives a general impression of what to expect when dealing with Haiku. FYI & i.e:
http://www.freelists.org/post/haiku-inc/Proposal-Joining-the-board-as-a-...
https://www.freelists.org/post/haiku-inc/Updating-the-donatometer,75
https://www.freelists.org/post/haiku-inc/Is-Haiku-Inc-operating-in-accor...
With regards to the 'troll's' second recent post on the mailing list:
https://www.freelists.org/post/haiku-development/HAIKU-REVOLUTION
That is trolling and would warrant moderation; but, if I spent the time to write that initial comment and it got unfairly moderated/deleted, I would also be angry and write something similar - so in a sense, trolling was forced upon him.
Re: Haiku, Inc. in Contempt of Its Community
The post was unpublished and not deleted. A sysadmin can republish it if they so wish.
Go read that blog I linked to. They were trolling 6 months prior to that 'HAIKU-REVOLUTION' message being posted, so the trolling was hardly 'forced'. Which with the fact that they have been sending abusive and harassing emails to Haiku developers and contributors for months, means that you have picked a strange bedfellow.
The post was just a rehash of what was posted on the mailing list but with a bit more eccentric rhetoric thrown in. If they wanted to retort, then they could of done so on the mailing list. The fact they posted here showed they wanted a bigger audience, something which you have given them.
Re: Haiku, Inc. in Contempt of Its Community
Re: Haiku, Inc. in Contempt of Its Community
Ok, I was unaware they were sending abusive and harassing email messages - how would I be? Emails are private and not public, so that has little to do with website moderation, and in my opinion shouldn't. Also, I don't really think what someone posts on external websites, their own blog, etc. should be grounds to immediately ban or moderate anything posted to Haiku's website. It should be a case by case basis. If an individual posted something aggravating, or a personal attack more than once and was warned, then yes, ban/moderate them.
To me, the arguments and points he raised seemed valid (in that post). Even a Haiku developer on the mailing list confirmed one of the points the 'troll' raised is a continuing problem with package management proving the discussion was useful. So, like I said, I thought the post was valid and insightful. Unpublished/deleted; same thing in terms of the public; it's inaccessible to the broader audience.
Further ModeenF, I am not arguing about package management and if it's useful or not; I already did say I realize it's Haiku's future (I could easily update Haiku before package management as well though FWIW). I just questioned the moderation of that particular post and criticized the way Haiku Inc is run.
@paradox
If there's any documentation how to set up a repository for Haiku Depot please send it. I may look into it. The problem is, of course, that Haikuware has non HPKG files - close to 3000. If the Haiku developers could somehow create a sandbox for legacy apps where Haiku Depot could install normal zips, 7zips, pkgs, etc. and protect the system (a lot of older apps just included system libraries and files that would over-write them) that'd be great. I think this is already implemented with the read-only directories though. If this were implemented and I put up a 3rd-party repository, all of the legacy applications that work or don't work on Haiku would sort themselves out by the way of 'user ratings'. Nobody will install the non-working apps if they see they have poor ratings/comments. That said, this is all useless because any ratings/comments that an app does or doesn't work may be invalid because Haiku is unfinished and this may change by R1 for app x,y,z. It's why I haven't moved to do anything at Haikuware or set up a repository yet. I think a good way to distinguish Haikuware's files or non HKPG files installed by Haiku Depot, would be to have a superscript icon on the icon's executable with a 'L' (legacy) or BeOS icon; and a disclaimer that the Haikuware repository contains apps that may not work or be compatible with Haiku (although, I've even read developers and users complaining about certain Haiku Depot applications that weren't working on Haiku. So in that sense, the package manager doesn't appear to solve much - it just proves the medium being used is only as good as the entity maintaining it).
Still, I see value in some of the applications at Haikuware. A good example, is, after 'PulkoMandy' publicly telling Haiku users 'not to use the junk on Haikuware' (thanks for the defamation!), and then contradicts himself by using the website himself to further advance WebPositive:
"The most important part is work to enable the HTTP part of the WebKit testsuite. I had completely missed the fact that WebKit had an HTTP testsuite before. This was pointed to me in the comments for one of the patches I sent to WebKit bugtracker. This testsuite needs a webserver with php and cgi support, and can use either lighttpd or apache 2. I decided to use lighttpd, which I know as I use it on my linux servers, and it is quite easy to port. PHP is more of a problem, while I could get it to compile after some build script hacking, the resulting php-cgi binary will KDL the system. I tried some older versions, but they all have the same problem.
Until this gets fixed, I'm using the old PHP 5.2 for BeOS port I found on Haikuware. This one seems to be working fine, and can be used to run the testsuite. And the result is the testsuite found a crash in our WebKit network code and several tests are timing out. I will have to fix those now."
https://www.haiku-os.org/blog/pulkomandy/2014-10-24_webkit_weekly_report...
@moderators - the copyright on Haiku's footer is out-dated... so you don't have to manually update it all the time :)
https://www.drupal.org/node/71106
Re: Haiku, Inc. in Contempt of Its Community
Thanks T-roll for the clear explanation of why package management is flawed and effectively resembles too much Linux package management!
You probably will be accused of trolling and so I add the opinion of another "troll":
http://news.softpedia.com/news/Linus-Torvalds-Says-Linux-Binary-Packages...
(yes objectively the Valve thing is trolling)
The annoying things are that:
Re: Haiku, Inc. in Contempt of Its Community
Re: Haiku, Inc. in Contempt of Its Community
Just out of curiosity, would there be any point in employing a Nix-like package manager paradigm in the system?
It seems like a very extendible and powerful solution to resolving packages that require different versions of libraries, and also managing linking to those libraries for individual packages.
Re: Haiku, Inc. in Contempt of Its Community
De facto the one implemented in Haiku is already a *nix Package Manager only a lot more complex that any one of them!
The correct solution that some version of Linux is trying to adopt too (Ubuntu for example) is to copy the Apple's Bundles, in a ideal world any software should use the system libraries as Package Manager would but in reality Open Source libraries rarely guarantee retrocompatibility and so one shall always bundle the application with his library version inside!
Anyway in the Apple world some important libraries / runtimes as Qt / Java are only in a place and considered an optional part of the OS: the correct guidelines of Apple development says that your should use those instead of your version if not no problem you bundle your library / libraries with your application! Nothing horrendous happens as Apple OSX is working for 10 years!
Another thing I don't like of Package Managers is that they do not permit an easy software discoverability: on Windows and Mac OSX if I need a browser and I don't know that I want Firefox I'll ask to Google and the first result is at 99% the software I want so I download and install it and I'm ready to go (let it go the little paradox that I'm doing an Internet search without a browser!).
In the Linux world (and the future Haiku world) in the Firefox site I don't found a package ready for my system (there are too much possibilities so the developer release the sources only) so I should open the Package Manager Application search for Firefox and probably I will not found it because it is not in the System default repositories and I have to add the repository by hand, on Linux probably, at this point, I've to resort to the terminal to edit by hand a file in a obscure path!
Re: Haiku, Inc. in Contempt of Its Community
Another thing I don't like of Package Managers is that they do not permit an easy software discoverability: on Windows and Mac OSX if I need a browser and I don't know that I want Firefox I'll ask to Google and the first result is at 99% the software I want so I download and install it and I'm ready to go (let it go the little paradox that I'm doing an Internet search without a browser!).
In the Linux world (and the future Haiku world) in the Firefox site I don't found a package ready for my system (there are too much possibilities so the developer release the sources only) so I should open the Package Manager Application search for Firefox and probably I will not found it because it is not in the System default repositories and I have to add the repository by hand, on Linux probably, at this point, I've to resort to the terminal to edit by hand a file in a obscure path!
I have been pushing for HaikuDepot to be more of a hybrid package manager/app store, plus a web frontend. This would be much like the hybrid web/desktop app of the Google play store, the Apple app store or the Windows app store.
A possability for the web frontend would be to fork and modify either the FirefoxOS Marketplace or the Ubuntu app store (https://apps.ubuntu.com/), both of which are opensource and could be made to connect to HaikuDepot Server (http://depot.haiku-os.org) for their screenshots, icons and ratings.
I can't say I am sold on the multiple software repository system, in fact I don't understand the rationale behind it at all. Mainly because it is only really in place in the Linux world for free/libre ideological reasons, which is not the case for Haiku at all.
I am aware however, that there is a logical separation into 4 distinct groups of software with Haiku core apps, Haiku core ports, Haiku extra apps and Haiku extra ports. The two core repositories should be officially part of the 'Haiku project' and managed as such, while the two extra repositories should community run and managed, but nonetheless integrated into the project overall.
But it not set out like this, rather it is split out into two distinct groups. One being apps and ports that devopers have a intrested in, while the other is ragtag fragmented group of software repositories that you have be 'in the know' to even know of their existence, plus who knows if they even will be there tomorrow.
I think the former categorisation is still possible, but the latter is the current course and it just is not substainable.
Re: Haiku, Inc. in Contempt of Its Community
I forgot how much the package manager costed, but, give the fact that ingo was working on it, it was for sure worth all the money. Given the abilities and experience of Ingo I would rate him easily as being worth more than 20.000 euro a month!
To have somebody as ingo (and stippi) on the mailing list, supervising and staying on the topic all the time is very precious, and one should be aware that it's very contra-productive to spam the official mailing list. If it's a normal forum, it's fine, you don't need to censor, since you are choosing what you read or not, but in the case of the mailing list, you are getting it per e-mail, that's something else, more invasive.
You must be aware that haiku has luckily enough very good developers, and if you write nonsense on the mailing list, you might "dissipate" all together many hours of the programmers, which is equivalent to a lot of money. And at a point you risk that certain developers are unhappy with that, and remove themselves from the mailing list.
Re: Haiku, Inc. in Contempt of Its Community
There is a small set of software you need installed to boot Haiku at all. These are dependencies of the Haiku package. Since they are essential to the system, it makes sense that there is some control on these and the Haiku devs can take care of that.
Fortunately, the available software is much more than these apps. Even before the package management was introduced, some of these apps were bundled with Haiku or available using the InstallOptionalPackage script. This was only a stopgap solution. The use of a repo managed by Haiku devs for the same purpose also is. It's not the role of the core devs to populate the repository and keep the packages working.
But then, who will do it? You may be tempted to answer "the community", but that doesn't make much sense. Our community is actually big enough that not everyone knows each other, and it is of course not organized or hierarchized in any way. There are people on IRC, on the mailing lists, on haiku-os.org forums, on haikuware forums, and a few other places (these are only the ones I know of). So, "the community" isn't an answer.
The closest we have to a package management team is HaikuPorts. This also predates the package management efforts (it was even called beports in the early days). It could be the duty of the HaikuPorts community to populate and manage a repository (it may seem that the people working at haikuports are the same as the Haiku developer team, but this is not completely true). That repository will probably have only packages built from recipes using haikuporter.
This is still not enough: some people prefer not to use haikuporter to build their packages. Either because they only repackage existing binaries, or because they want to use other tools (manually built packages, pkgsrc, whatever they think is suitable). These people are currently uploading their packages to several places, such as haikuware (which doesn't currently provide a way to use them with haikudepot), uwolke.ru (which does), or just upload them on their blog, put them on beshare, etc. The result is similar to the way software for Windows is distributed, with the risk of downloading from unsafe sources. The most open, but also possibly the most dangerous solution, as you get packages from unsafe sources.
Switching to a more centralized repository can be done only with enough manpower to manage it. If we go with something centralized but open (something like the Google Play Store), we would get some of the problems of the open distribution anyway: little visibility for apps, possibility of getting malware instead of the wanted app, etc. If we go with something more closed (similar to iOS app store), we will have to find a team of people willing to moderate the apps and set rules as to what is allowed and what isn't. This is going to require a lot of work.
Our package manager allows all of these ways. You can add repositories to your install, or you can get hpkg files from other sources and install them manually. So the Haiku project did his part of the job and delivered a tool that can do all these things. Now it is up to the "community" to use the tool and shape the ecosystem however they want. We are at the early times of this, and we will probably see some alternative repositories compete, merge and fork, and so on, until one of them becomes widely recognized as the place to get and upload software (like bebits was in the BeOS days).
Re: Haiku, Inc. in Contempt of Its Community
The following idea might not be agreeable for some, but it is just an idea:
How about a paid service which is purely for the convenience of installing packages from a "known source" (haiku repo). The apps themselves could be under a license of the author's choosing of course, but access to the repository would require a paid subscription (to fund the management of the repository). Apps can still be downloaded manually and installed outside the system.
Another (better?) option is to offer a split donation button so that when a package is installed, you can donate bitcoin or other currency to the author and package maintainer. The package maintainer could sign the package with their private key to verify that it was built by them from the source provided by the package's author, with the source download available as an option.
These ideas are not full solutions for anything but just to put out there.
Re: Haiku, Inc. in Contempt of Its Community
I can't say I am sold on the multiple software repository system, in fact I don't understand the rationale behind it at all. Mainly because it is only really in place in the Linux world for free/libre ideological reasons,
that's not true. it's there so software publishers have a direct line to users, which the vendor may control. in some cases, this means a repository that is available through subscription only, so only paying customers receive packages and their updates; also so that dependencies can be managed and system bloat avoided. those packages are almost always binaries (except in the case of arch and its derivatives). using package management in posix systems keeps the number of duplicated libraries down and it's generally only when dealing with source code that you'll end up with a lot of static libraries. the app store and the google play store use very similar systems, except with a single curated repository, which has stayed a pain in the ass for users and devs alike -- especially in the event of much needed updates and fixes being slowed held back by the bureaucracy of a centralized store.. if the act of adding a repository can be simplified (to be as simple as downloading and installing a package, let's say) then users ultimately will benefit.
Re: Haiku, Inc. in Contempt of Its Community
that's not true. it's there so software publishers have a direct line to users, which the vendor may control. in some cases, this means a repository that is available through subscription only, so only paying customers receive packages and their updates; also so that dependencies can be managed and system bloat avoided.
The Ubuntu software repositories are organized into four separate areas or "components", according to the level of support offered by Ubuntu and whether or not the program in question complies with Ubuntu's Free Software Philosophy.
So ideology doesn't come into it? Because 'Free Software Philosophy' sounds a lot like an ideology to me.
I don't think most end users would be happy, confident or competent enough to add a repository to get a specific piece of software and it does not coalign with the goal of creating an end use focused operating system.
those packages are almost always binaries (except in the case of arch and its derivatives). using package management in posix systems keeps the number of duplicated libraries down and it's generally only when dealing with source code that you'll end up with a lot of static libraries.
I am not arguing against package management, but rather against the fragmented fedralised design principles that have been added to the package management solution.
the app store and the google play store use very similar systems, except with a single curated repository, which has stayed a pain in the ass for users and devs alike -- especially in the event of much needed updates and fixes being slowed held back by the bureaucracy of a centralized store.. if the act of adding a repository can be simplified (to be as simple as downloading and installing a package, let's say) then users ultimately will benefit.
As I have stated, a centralised store can also just be a facade hiding a package management system behind it like apps.ubuntu.com or marketplace.firefox.com.
As for your comment about the Apple app store and the Google Play store being a pain in the arse for end users, how do you mean? I have never heard about end users complaining because the play store is a centralised system, plus the two main alternatives are two similar implementations from Amazon and Samsung, with F-Droid in a distant 4th place and only used by free/libre zealots.
A have merely advocated a repostry system like Ubunutu's Main, Restricted, Universe and Multiverse; only without ideology pushing. So it should be divided by the level of support offered, plus whether it is native software or a port. The Haiku devopers can maintained the software with the higher levels of support and the software with the lower levels of support can be maintained elsewhere by another group.
Re: Haiku, Inc. in Contempt of Its Community
There are several problems at play here. The first and most important one is that the haiku developer team is too small to manage a repository properly. The "core"/"extra" distinction seems a bit unclear to me, let's try to be sure we talk about the same thing.
I made a quick diagram. I renamed 'core' to 'high level of support' and 'extra' to 'low level of support', but otherwise it is nonetheless as I explained before. It is similar to the Ubuntu classification, but with free/libre & proprietary replaced with native & non-native.
But then, who will do it? You may be tempted to answer "the community", but that doesn't make much sense. Our community is actually big enough that not everyone knows each other, and it is of course not organized or hierarchized in any way. There are people on IRC, on the mailing lists, on haiku-os.org forums, on haikuware forums, and a few other places (these are only the ones I know of). So, "the community" isn't an answer.
The closest we have to a package management team is HaikuPorts. This also predates the package management efforts (it was even called beports in the early days). It could be the duty of the HaikuPorts community to populate and manage a repository (it may seem that the people working at haikuports are the same as the Haiku developer team, but this is not completely true). That repository will probably have only packages built from recipes using haikuporter.
I would still say the community, organised though a another organisation along the lines of HaikuPorts, only with more transparency (I mean who runs HaikuPorts? Who is in control? Who owns the rights to the logo? Who owns the URL?).
It could either be a sub-organisation of HSA or a new one based in NZ (to get around the software patents and that there is enough active people to start a new Asia-Pacific organisation).
I completely disagree about the size of our community. People not knowing one another is more the sign that it is fractured, rather than it being large. Although Haiku - as an OS - is meant to be intuitive, the Haiku web infrastructure is anything but intuitive. And this is not just me rehashing my previous Drupal 6 complaints, as the problems extend a lot further than that.
Check out this blog post for a look at it from fresh eyes:
http://haikudou.blogspot.co.nz/2015/02/some-recent-confusion-and-frustra...
This is still not enough: some people prefer not to use haikuporter to build their packages. Either because they only repackage existing binaries, or because they want to use other tools (manually built packages, pkgsrc, whatever they think is suitable). These people are currently uploading their packages to several places, such as haikuware (which doesn't currently provide a way to use them with haikudepot), uwolke.ru (which does), or just upload them on their blog, put them on beshare, etc. The result is similar to the way software for Windows is distributed, with the risk of downloading from unsafe sources. The most open, but also possibly the most dangerous solution, as you get packages from unsafe sources.
The devolper of ProjectConceptor (https://code.google.com/p/projectconceptor/) regularly wanders into IRC, posts here on the forum or asks at other places on how to get their app into HaikuDepot. But because this requires a Haiku developer who is willing give patronage to app developers, this never happens.
From reading Michel Clasquin-Johnson's blog, it doesn't sound as if his software repo is because he wants to run his own software repository, but because that is the only way to get his favourite software into HaikuDepot.
I think the work done by the Russian team (uwolke.ru) and Michel Clasquin-Johnson should be united as they both fit in the orange square my diagram above. Although some of the software would fit in the red square, but the bottom two squares are logicaly connected.
How long will these 3rd party software repos last?
Also, I thought Karl has made it quite clear that he is not intrested in package management nor HaikuDepot?
Switching to a more centralized repository can be done only with enough manpower to manage it. If we go with something centralized but open (something like the Google Play Store), we would get some of the problems of the open distribution anyway: little visibility for apps, possibility of getting malware instead of the wanted app, etc. If we go with something more closed (similar to iOS app store), we will have to find a team of people willing to moderate the apps and set rules as to what is allowed and what isn't. This is going to require a lot of work.
How are apps on Google Play store, iOS Store or the mac app store less visible? I find the UI of traditional package managers, such as Synaptic, absolutely terrible for discovering new apps (although admittedly quick to find and install apps you already know about).
I can't see how this would be harder to manage in the long run than the current fragmented system. And even if it is more work, at least it would be worth it in the long run, as it would be sustainable and wouldn't disappear as soon as someone becomes disinterested.
Although the software that fits into the blue and the green squares of my diagram need to be more restricted because of possabile system usage, software that fits into the red and orange squares can be community moderated. Although I think the bottom two should still be nonetheless integrated into the main project (similar to HaikuPorts), I now see that this is simply not possabile.
Now it is up to the "community" to use the tool and shape the ecosystem however they want. We are at the early times of this, and we will probably see some alternative repositories compete, merge and fork, and so on, until one of them becomes widely recognized as the place to get and upload software (like bebits was in the BeOS days).
This is the very point I just cant't understand, I just dont't understand this laissez faire attitude and the rationale behind it.
Is there really the time and resources to wait until a replacement for a BeBits/HaikuWare (that supports Package management) to pass though a process of natural selection?
Re: Haiku, Inc. in Contempt of Its Community
Some of the .hpkg files on Haikuware have been built with haikuporter and the recipes are on haikuports. They are on haikuware because there is no dev willing to add / update them in HaikuDepot.
Re: Haiku, Inc. in Contempt of Its Community
While there seems to be a lot of flack about PM, this does not stop programs being in delivered using zip files if you prefer.
My latest upload (see: http://haikuware.com/directory/view-details/utilities/miscellaneous/file...) is in ZIP file format and uses the new directory structures just fine. While it was work to get things working in the newer setup, it was not impossible work either.
If people don't like PM, stop the griping and start delivering code in compatible ZIP form instead.
I expect the next 4-6 programs I deliver to all be in ZIP format, and I expect there will be no problem with PM-Haiku either, in-fact I expect then to install even better than before as I learn about scripting.
Re: Haiku, Inc. in Contempt of Its Community
Some of the .hpkg files on Haikuware have been built with haikuporter and the recipes are on haikuports. They are on haikuware because there is no dev willing to add / update them in HaikuDepot.
I'd just like to add that the reason for this is that there's work on buildbots that will build/(check)/upload everything at haikuports automatically. Everyone hopes that those buildbots will be active soon. Doing this for hundreds of recipes manually (and do so again and again when they are updated) is not really practical.
That said, if there were only a handful of packages that people really want to see in HaikuDepot, I'd be willing to lend a hand.
Regards,
Humdinger
Re: Haiku, Inc. in Contempt of Its Community
I thought it was so because Haikuware was a better place to publish software.
EDIT: This forum doesn't quote correctly, it is not user friendly.If you are talking about yab, the recipes at Haikuports are only committed since two weeks. If not which packages?
Re: Haiku, Inc. in Contempt of Its Community
I thought it was so because Haikuware was a better place to publish software.
I thought Karl said he is not intrested in HaikuDepot/PackageManagement ?
Which is why I think we should steal the Ubuntu apps website (https://apps.ubuntu.com) and connect it to HDS.
(Steal = fork GPL'd code)
Re: Haiku, Inc. in Contempt of Its Community
That said, if there were only a handful of packages that people really want to see in HaikuDepot, I'd be willing to lend a hand.
For starters, Weather (formerly known as HaikuWeather) And Desknotes, which have both been recently been updated by Diver.
Justin Stressman has been asking for Minesweeper to be added to HaikuDepot. (the vector one, not the Raster based BeMines). Plus one of Dane's customers messaged me on G+ because they want the app SnapShot added to HaikuDepot.
When it comes to tools for app developers then: Einsteinium, Ponpokodiff, Microbe, Hdialog and Niue. (I would add BeLocalized to this list but it is Puck's app). Beezer is missing from HaikuDepot (1.0 works with PM), Beget/VWget and Remember which are all pretty core utilities.
If you want it narrowed down, I could create a poll on the google plus group to see what its (nearly) 500 members prefer?
Re: Haiku, Inc. in Contempt of Its Community
Hi!
I don't see the advantage of a website over the HaikuDepot app, but this may be discussed in a new thread...
Regards,
Humdinger
Re: Haiku, Inc. in Contempt of Its Community
Hi!
I don't see the advantage of a website over the HaikuDepot app, but this may be discussed in a new thread...
Or here: https://dev.haiku-os.org/ticket/11774
Anyway, Would you like me to create a poll of the most desired apps not in HaikuDepot?
Re: Haiku, Inc. in Contempt of Its Community
Re: Haiku, Inc. in Contempt of Its Community
I don't see the advantage of a website over the HaikuDepot app, but this may be discussed in a new thread...
Or here: https://dev.haiku-os.org/ticket/11774
I'm not sure a ticket is the right place for that sort of discussion.
Anyway, Would you like me to create a poll of the most desired apps not in HaikuDepot?
Why not, yes. Just make sure to mention that there has to be a working recipe at HaikuPorts for them.
Regards,
Humdinger
Re: Haiku, Inc. in Contempt of Its Community
Some of the .hpkg files on Haikuware have been built with haikuporter and the recipes are on haikuports. They are on haikuware because there is no dev willing to add / update them in HaikuDepot.
I thought it was so because Haikuware was a better place to publish software.
If you are talking about yab, the recipes at Haikuports are only committed since two weeks.
If not which packages?
The yab packages are important as the one in HaikuDepot is broken, it cannot build an executable that actually runs. This is due to changes that were made and not tested in the yab repository, haikuarchives/yab. the working repo is now at bbjimmy/yab to insure that the stuff is tested before commiting it.