Just a thing I wanted to clarify. The user guide translator and other similar tools have started as side-projects and were not really part of Haiku at first. A few years ago it was quite a mess with svn and mercurial and github repos everywhere.
The sysadmin team is hard at work streamlining these things. Everything has been migrated away from SVN and mercurial, and now all repos are hosted in two places: the haiku organization at github, and our own Gerrit server. I hope someday everything will be on the Gerrit server, but not everyone will agree with this, for now.
So, yes, it is unfortunate that you landed in one of the wild and unexplored parts of the Haiku project codebases. I think people working on the C++ code would have less trouble than you did. We definitely should improve this. I think however that this is also one way you can contribute. Now that the website is also hosted on github, it is easy for anyone to improve the contributing guides and make these things more welcoming. And it is actually much easier to do so from an outsider perspective. People who are in the project for a too long time will simply grow tolerant to the issues.
FWIW, I donât get this feeling from @kneekoo at all.
I think he correctly pointed out some inadequacies in our documentation. Where I think he takes a wrong turn is, that he expects the current devs to correct this immediately. The hard truth is, that the project is fantastically understaffed and people work on things that are a) more important or b) more fun.
Or in case of the user guide translation tool, we just have the code by someone not longer around. Ironically, with his PHP expertise, he might be the best qualified to work on its docs and the codeâŚ
Looks to me like one person fixed the underlying problem and another closed the ticket. That your contribution in spotting the error and triggering the correct fix wasnât mentioned was a bit unfortunate and people should add a âThank youâ when closing the ticket (the comment itself was correct, the patched wasnât needed anymore). @waddlesplash is normally a polite fellow, so it might just be that he was in a hurry or distracted.
Thatâs fair. I scanned over the thread again (jeeze this thread is getting long) and I overstated things a bit and mixed up a few peoples comments.
Itâs easy to say people should do something, itâs harder to actually do something. When only a handful of people are working towards an endless work queue for a hobby, nothing is more frustrating and demoralizing than having people dump in demands and non-constructive feedback.
So it didnât work back then on Jul 30. The PR was closed Jul 31, because it did work without it, as confirmed by kneekoo on Aug 1, mentioning some backend fixes. Nevertheless you fixed it on Aug 26?
Itâs like an Escher painting⌠Hmm, maybe I donât actually want to know the details here, but just enjoy the contradiction.
For me more incoherent is what kneekoo wrote: âsomeone fixed it and didnât even care to mention it on GitHub, so the conclusion was âClosing as not-needed, then.ââ
Hereâs a timeline:
30 July: I submitted a pull request to fix a broken link;
30 or 31 July: Someone apparently fixed the link directly on the server, bypassing GitHub;
31 July: @PulkoMandy noticed the link worked, @kallisti5 agreed, and so did @waddlesplash - who closed the PR as no longer needed;
26 August: You fixed the exact broken link that I had fixed weeks before and your PR was approved;
8 September: I got curious about that file and I checked who fixed it. However, I didnât even think about checking the date of your commit and I assumed you were the one who fixed it on 30-31 July as a result of my PR.
What is incoherent is whatâs going on behind the doors. So far no one stepped up to say âI fixed thatâ. And it is mind boggling that 27 days later you changed the same broken link. This means:
Someone fixed it âby handâ on the server;
An automated process pulled the code from GitHub and âbrokeâ the link again;
Weeks later, you fixed it by submitting a GitHub PR (the right way).
So I wonder, if you guys know your way around so well, why did anyone bother to manually edit the file on the server if their contents get automatically overwritten by git syncs? Just because the link I proposed wasnât the one currently used? Then why didnât someone say âwait, this other link is the right oneâ in my PR, close it and properly fix the link in the first place?
I donât remember what was going on then and since Adrien and Alex had already chimed in I just went with what they decided and didnât look very closely as to what was going on. @korliâs fix is clearly the correct one.
The www domain is served from a global CDN which deploys using the build_for_deploy script in the scripts directory. Thatâs it, thereâs no magic; we donât have any access to the CDN besides pushing new states to it, and IIRC I have it locked so that it deploys from GitHub only (there is somehow a manual deploy process but I have no idea what it is.) So, no, nobody fixed it âby handâ, as that is actually impossible
My guess as to what really happened is this: The original pre-fix link was relative, i.e., it points to a file in the present directory. If the URL had a trailing slash (it appears to have as much when linked from the homepage), then the link worked. If it did not, the link hit a 404. Somehow, @kneekoo wound up visiting a link without a trailing slash while @pulkomandy and @kallisti5 visited it with one, so it worked for them, and thus the PR was closed. Somehow @korli hit the same bug and fixed it correctly.
Thatâs the only way by which nobody involved is wrong in that it worked or was broken for them, and also nobody âfixedâ it on the server as that is impossible.
Well, I didnât manually enter URLs. I clicked the big Get Haiku button on the front page, then I clicked the R1, Alpha 4.1 link. If everyone else did the same, then the code under the hood seems to be buggy. Because the only way we could end up with a 404 was if the Get Haiku button is sometimes offered without a trailing slash on the front page.
But there is a notice that the alpha 4.1 is not the current state and people need to take a nightly build.
Get Haiku!
While we work on the last few blockers before R1 Beta 1, it is strongly recommended you try out a nightly/development build.
The Anyboot image is the preferred distribution format. It can be written directly to a USB flash drive, empty disk, or written to CD/DVD media. It can also be used directly from various emulators such as QEMU, VirtualBox, VMWare, etc.
Previous Releases
Version Date
R1, Alpha 4.1 November 14th, 2012
R1, Alpha 3 June 20th, 2011
R1, Alpha 2 May 10th, 2010
R1, Alpha 1 September 14th, 2009
As a developer I need to be able to check whether a bug is a regression compared with another release. I needed to download the alpha4 end of August for this reason.
no available gui is linux specific. the x server itself predates linux. you could run all of them in any unix. you could run all of them side by side in any unix installation, even. they are each their own ux discussion that linux should never be mentioned in.
Well, convince the world to use a different catch-all term for âall those disparate user interfaces that get thrown on top of Linuxâ, and for lumping each of the hundreds or thousands of distros together handily. (-:
As things stand âLinux user interfaceâ seems to load the set into peopleâs minds, or at least as much of the set they know. Issues surrounding user interfaces on systems which use a Linux kernel tend to be similar or the same, due to similar sets of user interfaces available.
To me, convincing the random people to laboriously list out a fair sample of all the Linux-based systems theyâre aware of (due to lack of a convenient term for the lot) is about as futile as convincing most Americans that âseaweedâ is a horrible term and they should actually use separate descriptive terms for different kinds of sea plants. (-:
So, yes: { [ UI | UX ]+Linux } belongs until you can convince people in general that Linux is not a generic term for all the systems which use a Linux kernel. I suspect that cause is lost, much like Kleenex being conflated with facial tissue paper in USA, Hoover with vacuum cleaners (which never cleaned or created vacuums in the first place) in UK, and other brand names which have become so commonly used that they are now generic terms.
Youâre welcome to keep up the fight, though. Iâve mostly try not to get upset about it.
To all those involved, thank you for all the work you have done. We wouldnât even have a beta right now had you organized and done what you have done.
That said, I expect there to be bugs in betas.
When compiling sources, I presume I am going to need to be on-line at some point in time in order to acquire the dependencies I do not yet have, not to mention the sources them selves. Even if Haiku consisted of all in one programs that had no system decencies, I would still need to download that executable from the internet. I mean⌠this isnât 1994 man.
How old are you, son? Were you even alive in 1994? I was 11 years old and programming in C by then. Needless to say, my knowledge base by now is extensive. If you fail to understand my reasoning, itâs due to your lack of experience, imagination, and/or intelligence. The Haiku build process, as of when this post was created, was a broken pile of shit, and only a moron with low standards (or a CHILD) could argue otherwise. Does this help your understanding?
I donât know what the current status of Haiku is, as I havenât been keeping up with this thread, and only just noticed this latest moronic reply. I see a mention about a beta. I wonder if the problems I brought up been addressed, or have you cultists only continued to circle jerk each other while excusing mediocrity?
I see someone has lit a fire under the ass of ReactOS devs lately; likely something to do with the actions of Microsoft. Itâd be nice to see Haiku to likewise get its shit together and produce something worthwhile. If a beta has been released then I will go download it now and see what itâs about.
If itâs not 1994, then I guess there is no reason to use Haiku, is there?
Pretty sad that the benefits of putting everything in one nice easily downloaded zip file is such a radically foreign concept that it not only has to be explained, but SOLD to folks, like you Just Donât Get why that could possibly be a good idea or helpful at all.
@gladius has now been silenced until Jan 1 for their behavior. Constructive criticism is of course permitted; insults and other derogatory language are not.
But to answer the question: binary packages are downloaded during the build process to avoid requiring a bootstrap every time. You can of course either (a) download these manually, (b) build them yourself by doing a bootstrap build (but this will of course require downloading their source packages), or (c) extract them from an already-running Haiku image.
This hasnât been an issue up until the present. If there is an argument as to why this should be changed (e.g. security concerns; though this can be handled through bootstrapping already) then of course we will listen to it. But merely saying that our current process is âchildishâ and insulting maintainers over it is really not acceptable.