Most applications in Windows are either completely self-contained or they only have one dependency, so storing them locally is never an issue. I have a Windows 7 installation that has never been online even once. I’m pretty sure you can even do this in Windows 10, although Microsoft is moving in the direction of putting everything in the Windows Store. Up until very recently, requiring an internet connection to install software was basically a Unix thing.
Sounds like an intersting dev project to have a application to download programs and his dependencies without installing on the system. So people can create a cd or stick for local install
There is a small set of apps already included.
Limited usage, sure. But unusable, aka no usage possible, nope.
@phoudoin : he meant one cannot install any pre-downloaded .hpkg with double-click if there is no active internet conenction. It is a real flaw in HaikuDepot right now. (It tries to resolve the dependecies online or something).
Placing manually the hpkg file in packages folder should work.
So this is always reported into the bug tracker?
This could not be a big problem. Asking for internet activity, if not a message to the user with “check you internet connection”. If the user press on ignore the query of dependencies are left away.
If you ignore the dependency query, wouldn’t that just mean that the application is installed without its needed dependencies and the application won’t work?
No, in that case libsolv won’t let you install the package.
Haikuporter uses the Linux way when porting Linux software. Don’t place the blame on them, doing anything else would be silly and would force them to rebuild the whole universe whenever there is a security fix in a library used by everyone. This is just unreasonable.
What Haiku tries to do in this context, is bring an OS with a stable API, rich enough that developers don’t need to use 3rd party libraries. But this, of course, works only for native software.
As a result, the package system was designed to cover the needs of native software, first, and of ported software, when possible. If you install native software, in most cases there will be few dependencies and you can get away with just one hpkg file. The stable ABI also means we can update things software depends on, without a rebuild (as an example of this, see how it’s possible to add translators to add support for new picture formats in existing apps).
So, the blame for dependency hell is on Linux developers. The team at HaikuPorts is just doing its best to get these things running.
And a final note: the nightly images are meant for development purposes, and are kept small to speed up the process of downloading and installing them. When we ship the beta (like we did for the alphas), we will include a lot more software and build an image that fills a CD. So there will be a lot more included than in the nightlies, making the OS more usable out of the box.
Oh, okay, then, with an hpkg with dependencies already installed, it’s an issue, indeed.
One cannot “join the Inc”, it’s not a membership organisation. Haiku Inc. consists only of a small self-selecting board of directors.
Some years back, recognising that it was utterly dysfunctional the board were persuaded to say they’d work on opening it up to a wider membership. As you’d expect what they actually did was decide that they ought to hold some sort of meeting about that, which they didn’t have time for right then, and so they postponed it indefinitely. Clever.
Haiku doesn’t need a corporation at all. Haiku Inc exists as a manifestation of grandiose ideas by Phipps and co. who had this idea that they weren’t building a retro-computing system for a handful of hobbyists but a real alternative that was going to (yes, seriously, Phipps actually gave interviews and presentations about how he imagined this was going to happen) challenge Microsoft. What Haiku Inc. ought to have done at least five years ago was negotiate with an umbrella organisation (such as Software in the Public Interest), to handle the money and so on, then wind down gracefully. Picking a good “home” for the Haiku money would have required a bit of effort, and of course as interest dwindles it’s harder to find that effort, it may already be too late.
They hold meeting when needed and replaced several members of the board in an effort to improve things. However, most of the people who were originally running things have left (Matt Madia, Urias McCullough, Ryan Leavengood) and now the org is run by people who, as I mentionned, are also involved in other aspects of Haiku. They are doing some work to clear things up on the Inc side as well, but at the moment, keeping the infrastructure up and running is an higher priority for them.
Even if the board is self-selecting, some people managed to get in. That’s what I mean by “join the inc”: start by subscribing to their mailing list and asking where you can help - not by complaining that people trying to keep it running are not doing it right. They know already.
Thank you for this explanation. This does make a lot of sense. The needs of native applications come first. I suppose this also creates an incentive for both users and devs to prefer native whenever possible.
"Currently, Haiku is arguably the most convenient development environment. A nightly image (or stable release) of Haiku should contain all of the software needed to build its sources for x86.
So while Haiku is not the fastest, being able to immediately test the freshly compiled binaries and having the tool chain pre-installed certainly reduces the chances of headaches. On occasion, building Haiku on Haiku can be problematic if the host version is significantly out of date compared to the version being built. In this case, cross-compiling from another OS, or updating to a newer Haiku may be required to get things working again.
Haiku currently supports building itself, or having itself cross compiled on another platform."
I think this can get fixed if an “experienced” person can confirm the build process still works using
the recent nightly images (or even the R1a4 build). This is defined in the notes - so should abide by the claim.
I notes phoudoin said an Internet connection is needed to build Haiku. I may have overlooking this in the notes myself.
The other issue mentioned some packages were ‘broken’ builds. I experienced this myself downloading some recent dev packages.
So let us just say some concerns are legit and worth reviewing. There are always learning curves to consider as well as assumptions when things get automated. Maybe a nice confirmation that things are still working or can be done offline is all that is being asked here…
Guys, you can help to make the documentation crystal clear.
Here are the webpage, clone it, change it, send a PR.
Whilst Matt Madia’s leaving was publicly acknowledged (months and I suspect years after it became a reality) both Urias and Ryan are still listed on Haiku’s Inc’s official web site as I write this, and Ryan was the last board member to say anything on their official mailing list.
The last person to volunteer on their mailing list a few years back was told Ryan would be glad of assistance, subject to a bunch of conditions. The volunteer accepted anyway, so Ryan promised he’d put his work onto GitHub “as soon as I can” to give the volunteer somewhere to start and then… nothing. If Ryan has now quietly left Haiku Inc. too should I assume the years of software development he supposedly did for Haiku Inc. have also mysteriously vaporised? Who is now Treasurer, and thus in charge of the unknown sum of money held supposedly on behalf of the project?
Microsoft took off when Office became its killer app. Linux began to take off when Firefox became its killer app - because its separate development freed up Linux developers to work on other features (such as endless versions of window managers). Haiku, in contrast, is progressing very slowly because of the need to spend an inordinate amount of time just getting the browser to work properly If this problem could be solved somehow, Haiku would fly to R1 and beyond. As it is now, it is unlikely to get to R1 while its lead developer’s time is consumed by browser work.
Actually, some of these devs are moving very quickly. KDE 5.46, Qt 5.10.1, Scribus 1.5.2 are all updated recently. Qtwebengine is in progress. Right now I use Otter Browser for most things like Youtube.Also, Calligra Office Suite works with MS Office 2007 so I can edit things back and forth.
So, compiling Haiku on Haiku off-net or having newer Qtwebengine-based browsers like Falkon 3.x are no longer an arm’s reach - more like a finger’s throw…
Qtwebengine is in progress ???
I wasn’t aware of anyone working on a Qtwebengine port !, Are you working on it ?
Yes, it seems. just check his screenshot: https://github.com/haikuports/haikuports/issues/2544#issuecomment-388999920
The web browser is taking less than one dev. I work on it mostly alone and still do other things. So I don’t think it is slowing down the project that much.