Coding Sprint Results

Blog post by stippi on Tue, 2008-10-21 09:01

Wow. What a week. The Coding Sprint is over and I am very excited at what we achieved together! Haiku has become much more usable and polished thanks to all the fixes and improvements. For example, I can now use Beam to read and send my e-mail, which is obviously quite important for me to be able to use Haiku on a day by day basis. But that was certainly not all. Read on for a detailed listing of all the achievements.

We had a lot of fun in the group, the renewed Youth Hostel facilities are great. Like at the BeGeistert in Berlin, there is now a table soccer installation which we used from time to time to dope us with adrenalin and relax a bit from coding. But all in all, the coding absolutely dominated. It was actually quite intensive, on Wednesday, I realized that I had not been outside since Sunday evening. Ingo and Oliver were the most strict with getting up early, even though they stayed up late into the night. Poor Ingo was searching for a bug for a large portion of the sprint. But after the sprint, he was able to finally commit his hard work and now Haiku builds Haiku with twice the speed as before. The bug was actually a missing underscore, so that he used an unnamed auto locker, which then didn't lock at all... Overall, I'd say that this coding sprint was at least as successful as the one in January. And Haiku has taken another great leap towards the first alpha release. I want to thank everyone who was present and also the many developers who could not come, but who intensified their work during the sprint. This was very motivating. Many thanks also to the new contributors who send their patches! One of them, Clemens Zeidler, actually came by on two evenings and worked with us. He has contributed a large patch, which I need to commit ASAP, that enables broad support for Synaptic touch pads, including a preflet and two finger scrolling! Yay!

Team Work

  • Oliver Tappe and Ingo Weinhold fixed an important problem with binary compatibility to BeOS applications that caused a number of bugs ranging from certain applications crashing at startup to subtle bugs like menus missing in other applications and so on.
  • Marcus Overhagen and Michael Lotz fixed a problem in the PCI_IDE module that screwed up hard disk access and prevented many systems from booting when the partition was after a certain location on a hard drive. It also prevented the system from seeing partitions in the partition map that were located behind a certain offset (128 GB, IIRC).
  • Oliver Tappe and Stephan Aßmus
    • fixed some problems in the BWindow and app_server code regarding the notifications for mouse transit. This was also important for fixing certain drag&drop operations in the Deskbar to launch files with specific applications,
    • fixed BTextView class with regards to keeping the fTextRect member up to date in certain situations, which makes it more efficient and fixes some recently made visible bugs, among others, the "scroll bar becomes disabled when the window is resized" bug
    • and fixed another BTextView problem in LineHeight(), which caused the text entries in the Pe Find panel to be way too small on first launch.
  • Michael Lotz and Ingo Weinhold
    • introduced a tail command for the kernel debugger and
    • fixed a triple fault in the kernel debugger.
  • Axel Dörfler and Michael Lotz both improved the type-ahead feature in Tracker to quickly select folder entries.
  • Ingo Weinhold and François Revol fixed a problem in the kernel that prevented SoundPlay from ever playing the second song in the playlist.
  • Axel Dörfler and Stephan Aßmus worked on the StressTest app_server test application and located two more app_server deadlocks and crashing bugs.

Individual Struggle

Stephan Aßmus
  • did a lot of work on MediaPlayer with regards to cleaning up the file panel code and enabled playlist loading and saving. Some playback bugs were also fixed.
  • fixed BNodeInfo::GetTrackerIcon() to always retrieve the correct icon,
  • improved the rendering of the miniature windows in the Workspaces applet,
  • fixed some UI glitches in Deskbar when changing the menu background color,
  • fixed a few bugs in LaunchBox and made the icon size a preference setting,
  • fixed a crashing bug and several usability problems in the FileTypes preflet,
  • improved and fixed the InstalledPackages application,
  • located a performance problem in the POSIX strstr() function and replaced it by a public domain implementation which speeds up opening mails in Beam by several orders,
  • created a few new icons.
Alexandre Deckner
  • fixed several annoying Tracker bugs. Fast repeatedly right-clicking the Trash icon could crash Tracker because it didn't check if the cached Trash menu was already displayed,
  • fixed several bugs with regards to saving the window/view state of a folder. Some of the problems were especially annoying when using the single window navigation mode,
  • worked on BColorControl to fix some layout issues.
Axel Dörfler
  • fixed a binary compatibility problem in the stat() function,
  • improved some window management behaviour in the app_server, mostly affecting workspaces,
  • fixed some bugs in the I/O scheduler,
  • implemented demangling of call dumps in the kernel. The end result is that you actually see the function parameter values in the kernel debugger stack traces.
  • fixed makebootable to also work on mounted BFS partitions. This will enable a much smoother experience when installing Haiku. :-)
  • improved the disk device manager API and now Tracker is able to tell whether a file system supports writing before mounting a partition. If it's read-only, there is no need to display the read-only nagging alert. He also worked on mounting file devices by path.
  • worked on better build system support for Virtual Box, which needs the VMDK disk images to have certain properties,
  • improved an algorithm in the block cache that significantly sped up certain file system operations on fragmented volumes.
Jérôme Duval
  • fixed bugs in some of his audio drivers,
  • updated several packages he maintains, like MESA and the timezone data to their current versions.
Humdinger
  • contributed a lot to the Welcome documentation/introduction and refactored the beginnings of a user guide from the welcome package,
  • wrote an extensive report on BeGeistert.
Michael Lotz
  • fixed a bug in BDirectory::Contains() that was the cause for certain Tracker crashes,
  • fixed some bugs in the disk management regarding USB card readers that have no media,
  • The ACPI bus_manager received a lot of love from him and a slew of bugs got fixed in the OS layer that connects the common ACPI code from Intel with the Haiku kernel.
  • implemented the new BMessage::HasSameData() method,
  • fixed serious problem in the kernel with regards to detecting the failure of certain types of allocations,
  • fixed two serious bugs in the recently introduced entry cache that could lead to programs overwriting the wrong files or directories.
François Revol
  • continued his work on the M68K port. He got it as far as the kernel running until it needs timers to work.
  • plunged into Icon-O-Matic and added several neat cross application work flow features, like clipboard support for importing styled text.
  • made NetSurf into a Replicant that can be embedded into the Desktop and other applications. He fixed BeHappy (an application to show documentation like the BeBook) to be able to use NetSurf instead of the previously hard-coded NetPositive. He added a new Optional Package for BeHappy.
  • added FAT32 support to the boot loader. This will eventually enable booting from a disk image that is located on a FAT32 volume.
Oliver Tappe
  • fixed a few bugs in the UDP network layer.
  • located a compatibility issue in the POSIX layer that prevented for example Beam to generate unique file names for saved e-mail files.
Ingo Weinhold
  • fixed a problem in the runtime_loader, certain exit hooks where not called on program termination,
  • did a slew of optimizations, memset() and memcpy() for the kernel now have versions written in assembler for the x86 platform. He also implemented a method to pin threads to CPUs to optimize some CPU synchronization issues.
  • fixed a serious race condition in the Unix FIFO implementation,
  • the page writer I/O priority is now dynamically adjusted,
  • fixed several kernel bugs and implemented more optimization, which overall sped up the Haiku image build in Haiku by a factor of two!

Outside Help

Quite a few developers were not present at the coding sprint, but contributed a lot of work during the week:

  • Stefano Ceccherini worked on the ACPI name space dump and added various other small fixes.
  • Rudolf Cornelissen fixed a problem in the IDE bus_manager which extends the support for certain mass storage controllers. Haiku was not bootable on systems with these controllers before (...including my desktop machine, thanks!!).
  • Stephen Deken sent a patch implementing a new BAffineTransform class and used it to enhance the BPolygon class.
  • Oliver Ruiz Dorantes checked in his latest Bluetooth L2CAP code.
  • René Gollent was always fast to fix build problems and other problems introduced by some of the commits. He also fixed the long standing issue that app_server mostly never remembered the number of workspaces the user configured.
  • Karsten Heimrich fixed a lot of bugs, among them some quite annoying ones that affected many applications. The mysterious crashes in many applications when they were quit turned out to be a problem with offscreen BWindows/BBitmaps!
  • David McPaul contributed a lot of fixes to media codecs that affect WAV and MP3 files. This improves seeking in certain media files.
  • Artur Wyszynski sent a large patch implementing a new BGradient Interface Kit class based on the Gradient class in Icon-O-Matic. There are several subtypes of gradients available and he implemented all the new BView drawing functions and the app_server backend! He even wrote a small demo application show-casing his work.
  • zuMi sent in batches of new icons, mainly for the background servers, among them a beautiful pidgeon icon for the mail_daemon. He also created a neat icon for NetSurf and several other applications and servers which are not even part of Haiku yet.

Does all this mean we are ready to release the alpha? Unfortunately, we have at least one remaining file system bug that corrupts data. We need this one fixed and hopefully we can find a reliable test case to reproduce it. Over the next weeks, I plan to pick up my work on the partitioning backend. It will be important to create and delete partitions from within DriveSetup. Then there is one remaining bug in the USB bus_manager which sometimes suddenly disables USB ports, so that input devices stop working. Once at least those two bugs are fixed, Haiku should be usable. I am very excited!

Comments

Re: Coding Sprint Results

Ok so that's about +10,000,000 points to you guys for some extreme effort! First thing I'm going to do when I finish work today involves the command "svn update"!

Re: Coding Sprint Results

you should add gcc to core version of Haiku...
I dont't thinik it should be that problem to compile the gcc if you can compile complete Haiku ...
i think that would attract much more devolpers to haiku... much more than a cups port, etc..

Re: Coding Sprint Results

Hi Bastian,

If you build your own Haiku you can get the build system to install a Haiku version of GCC. Otherwise the optional packages, including gcc, can be found at http://www.haiku-files.org/files/optional-packages/

Simon

Re: Coding Sprint Results

i dont think i will be able to/ have time to build haiku by myself.
i tried to install gcc on haiku, but it didn't work. I used senryou's edition and copied the development-folder to haiku-disk...
thank you for that link i will try the days but i think a gcc should ALWAYS be included like a texteditor...
(because haiku is at the moment just an development-version, not even alpha...)

Re: Coding Sprint Results

Quote:

(because haiku is at the moment just an development-version, not even alpha...)

Precisely :)

Even for a non-developer, it's amazingly easy to build haiku with the development tools, the instructions for doing this on Linux are easy to follow.

It can also be done on other operating systems.

In any case, the development tools are going to be distributed with Haiku when it's alpha per the proposals that were voted.

Re: Coding Sprint Results

Senryu (d.e) has all the development tools and entire source tree for Haiku in the 150 mb compressed file. Shouldn't need to add anything, just svn up to update the sources.

I think it would be great if Haiku would provide something similar, if not now, at least for the alpha.

Re: Coding Sprint Results

Woo, thanks for the report Stephan. Sounds like some really good progress has been made - I'm looking forward to svn up'ing my Haiku tonight to see if I can boot my new box without having to switch to the (slow to boot and unsupported in WinXP) AHCI-SATA bios. Think it may be the partitions-after-128GB bug.

Good work all round, I'm really looking forward to the alpha!

Simon

Re: Coding Sprint Results

tangobravo wrote:

Woo, thanks for the report Stephan. Sounds like some really good progress has been made - I'm looking forward to svn up'ing my Haiku tonight to see if I can boot my new box without having to switch to the (slow to boot and unsupported in WinXP) AHCI-SATA bios. Think it may be the partitions-after-128GB bug.

Just to follow up on this, I can indeed now boot Haiku from my SATA drive without having to enable the AHCI bios. I have to use the ATA bus manager rather than the IDE one though, which I think still doesn't support DMA and boots quite slowly (drive icon stays lit for about 30 seconds befroe boot continues), but nevertheless it is a great step forward.

Simon

Re: Coding Sprint Results

Absolutely worthy news. Thank you, all.

Re: Coding Sprint Results

A-ma-zing! I will have to install a new build to test all this, is the USB bug you mention related to input devices which stop working when a new input device is plugged in? This always happened when I plugged in my Wacom tablet, my mouse stopped working until I unplugged the Wacom.

I played with a recent build (last week?) yesterday and there seem to be mostly performance problems and Gobe Productive keeps crashing a lot. For the gradients, making a vector graphic in GP and filling it with a gradient and dragging that vector graphic is taxing the CPU very much for example. The AGG lib makes the GP graphics look so nice!

Thank you very much developers!

PS: Haiku seems more stable then KDE4.1!

Re: Coding Sprint Results

Thanks to all participants and Stippi for providing this detailed report!
One more thing was solved (though technically that was at BeGeistert and not the Sprint), that made all the difference to me: A bug was fixed that enabled me to mount large partitions (128gb+). Something about some 48bit LBA thing. Dunno if it was Axel, Ingo, or Michael...

Now, how about that ext2 write support...? :)

Anyways, well done everyone!

Re: Coding Sprint Results

Yes, but I mentioned it somewhere in the Team Effort section. I fully understand that it's lost among all the other changes listed... :-) I do anticipate that I missed something else though, the change log is quite long and I didn't include everything, but I may have missed something important and/or nice.

Re: Coding Sprint Results

"Yes, but I mentioned it somewhere in the Team Effort section."

Oh, how could I have missed that?

It is a long list... you all were busy little bees. (damn, punning was easier back then...) :)

Re: Coding Sprint Results

Wow, that sure is an impressive list! Sounds like you guys had fun :-)

At least I hope you had, because I sure loved to read about all that progress and, like many others too, I'm really looking forward to using Haiku.

Re: Coding Sprint Results

Have a baby for love, not for German engineering
http://www.youtube.com/watch?v=3qL_9Gmonuo

Re: Coding Sprint Results

Made in Canada too ;)

Looking at getting one, but not until 2010 when they get the VW engines lol.

Re: Coding Sprint Results

Hope this isn't too off-topic, but... I still can't get Haiku to run on my Intel G33BU motherboard with Core2Quad Q6600 CPU. The only way I can get it on the system at all, is using an IDE hard drive that works/loads perfectly on my Jetway V266B w/ Athlon XP 2000+ CPU system.

It goes as far as the chip symbol (5th icon), during bootup and it just stops there. Are Haiku's icons the exact same representation (as to what is going on in the boot process) as in BeOS? If so, then it's stopping just prior to engaging the remaining CPU's.

I've tried enabling/disabling various things in the BIOS (would EFI Boot mode help at all?), to no avail. I've tried disabling everything AND enabling the diagnostic display, in Haiku's Boot options. Nothing seems to work.

The diagnostic display shows that the drive is being accessed (start up, initialize, fail, restart... or something like that) and then begins (or tries) to load/execute the kernel drivers or something. And then the display just stops before it gets to another yellow highlighted [Press any key to continue...] prompt. And it never goes beyond that point.

Does anyone else have this exact same (not similar to... EXACT SAME) motherboard and gotten it to work? If so, what did you do?

Re: Coding Sprint Results

Try the ATA bus-manager rather than the IDE one, which is easy to switch if you're building your own image from source. Modify the haiku/trunk/src/add-ons/kernel/bus_managers/Jamfile by uncommenting the ATA line and commenting the IDE line. This bus manager is able to boot my modern Intel-based chipset motherboard off a SATA disk.

If you're not building from source it might be harder to switch but I think the official alpha release will switch to the ATA manager as the default. The ATA manager didn't support DMA last time I checked so is pretty slow - I suppose this will be fixed before it is enabled by default.

Simon

Re: Coding Sprint Results

I think you can just delete generic_ide_pci from the installation? That might be easier (access the disk through a BeOS Live CD, an emulator or swapping the drive into your other working computer to delete that file).

Re: Coding Sprint Results

No, that's bogus. Sorry Karl. :-)

Re: Coding Sprint Results

I'm just reiterating a comment by Marcus when I was trying to get my Asus laptop to boot:

'Please try to remove the generic_ide_pci driver from the image. Does it boot after that? '

http://dev.haiku-os.org/ticket/1671

is that bogus?

Re: Coding Sprint Results

Ok, this is just plum crazy... and I've waited long enough for it to be fixed and it still isn't.

I am running BeOS R5 PE (WIND distro; this version has always worked, to JAM Haiku builds with, on the Athlon XP 2000+ system (w/ 512Mb of DDR RAM) I'm still using, year after year).

This is ALL I need to do to set everything up:

I install (unZIP) BeOS Dev Tools, to /boot.
I install (unZIP) the Haiku cross compiler (version 080323) to /boot.
I rename UserBootscript.sample to UserBootscript
I run Subversion.pkg and get it installed.
I install (unZIP) Jam to /boot/home/config/bin.

At this point, I download the sources (via Terminal) using:

cd /boot/develop/HaikuTree
svn checkout svn://svn.berlios.de/haiku/haiku/trunk

When that is finished (and it finished just fine last night), I then run the configure script using:

configure --cross-tools-prefix /boot/apps/haiku/cross-tools/bin/i586-pc-haiku-

And this *NORMALLY* (as in, "always has in the past", since the last major change a year or two ago) results in going to the $ prompt a second or two later. which means it executed correctly.

But now, instead of that, I am getting this message:

GCC version 2.95.3-haiku-081024 is required!
Please download it from www.haiku-os.org...

The ONLY copy of "version 081024" I can find, is over at HaikuWare. But, upon trying to install it, it doesn't work... it won't unpack or something!

Can anyone explain what is happening and why and how to fix it?

Re: Coding Sprint Results

redo configure --build-cross-tools

Re: Coding Sprint Results

redo configure --build-cross-tool?

I don't understand. Do you mean I need to type:

configure --build-cross-tools at the $ prompt, in Terminal? Is that it? I go to /trunk and then type that?

Re: Coding Sprint Results

I'm in the same boat here. Evidently what these guys are saying is to download the whole goddamned GNU toolchain from the svn repository, and then configure/build it. I have neither the disk space nor the patience for that sort of messing about, one could spend half a lifetime trying to get GNU tools to work correctly.

The statement that you merely need to run:

configure --build-cross-tools

is also bulldust, from memory configure expects some more parameters.

FYI the gcc-2.95.3-haiku-081024 package on HaikuWare doesn't work. None of the files are executable in BeOS 5.0.3 Pro, and it isn't an attribute problem. OTOH if it's only supposed to work within Haiku then apparently we don't have any binary distro of the tools to build the repository.

Someone who is actually working on the code daily needs to take responsibility for keeping the tools built and available in distribution as binaries. It's bad enough that one has to install multiple packages out of zips, with half-baked installation instructions, without this added complication.

Would one of you geniuses either supply working, current version build tools on the setup page, or revert the SVN code base to use an earlier version please? Some of us would eventually like to try using this thing, and you sure won't get anyone to help fixing code bugs without it.

haiqu (and yes, I was using this nick long before the OS changed its name)
Be Dev ID 22586

Re: Coding Sprint Results

After realizing that BeOS R5 was no longer a viable option, I finally hunkered down with Ubuntu and couldn't believe how fast everything was! What took 2 hours to download/JAM in BeOS, took *25 minutes* in Ubuntu, on the exact same hardware! BeOS has had it's day in the sun... let it retire to a mere pleasant memory... use Ubuntu (32-bit). You WON'T be disappointed... you'll only bang your head, wishing you'd done it years ago! Seriously!

haiqu wrote:

I'm in the same boat here. Evidently what these guys are saying is to download the whole goddamned GNU toolchain from the svn repository, and then configure/build it. I have neither the disk space nor the patience for that sort of messing about, one could spend half a lifetime trying to get GNU tools to work correctly.

The statement that you merely need to run:

configure --build-cross-tools

is also bulldust, from memory configure expects some more parameters.

FYI the gcc-2.95.3-haiku-081024 package on HaikuWare doesn't work. None of the files are executable in BeOS 5.0.3 Pro, and it isn't an attribute problem. OTOH if it's only supposed to work within Haiku then apparently we don't have any binary distro of the tools to build the repository.

Someone who is actually working on the code daily needs to take responsibility for keeping the tools built and available in distribution as binaries. It's bad enough that one has to install multiple packages out of zips, with half-baked installation instructions, without this added complication.

Would one of you geniuses either supply working, current version build tools on the setup page, or revert the SVN code base to use an earlier version please? Some of us would eventually like to try using this thing, and you sure won't get anyone to help fixing code bugs without it.

haiqu (and yes, I was using this nick long before the OS changed its name)
Be Dev ID 22586

Re: Coding Sprint Results

I don't understand you people. You post a comment to a blog entry totally unrelated to your problem and expect any of the core haiku developers to notice you? I only noticed this comment because I am the author of the blog post and get notified on new comments, by email. I don't have time to go out and look for new comments on this site, and neither do the other Haiku developers. You guys expect us to produce code, but it doesn't cross your mind that you should at least use the proper communication channels so that we don't have to spend more time on communication than necessary?

It appears that almost no Haiku developer is using BeOS or ZETA any more for building Haiku. At least not those providing tool-chain packages. Sorry, but even when ZETA still ran on my hardware, it was about 20 times slower at building Haiku than Linux on the same machine.

If you absolutely need to build Haiku in BeOS/ZETA, IIRC you can hack your configure script to remove the constraint on a GCC version that is not available on BeOS. And then simply don't run configure anymore. You definitely don't need to build your own GCC on BeOS, I am not sure that even works.

Anyways, with the attitude you are showing, I am almost 100% sure that we won't get any help from you, even if the tool chain worked smoothly on BeOS. If you were one of those doer types that Haiku needs, you would have a) used the proper communication channels to even reach the people that matter or b) have tried to dig into the problem yourself. If you cannot dig into problems yourself, or at least try to get help in a friendly (i.e. non-insulting) manner, frankly, we don't need your help.

Re: Coding Sprint Results

Stephan,

I simply did a site search for 081024 and found two blog entries, both from the same frustrated developer and posted over 6 months ago. I suspected someone would be notified if I replied to one of them. Since I haven't even logged into this site in over 4 years, I could hardly know what the "proper communication channels" might be these days.

Just checked the repository and apparently GCC 4.3.3 is now in the main branch with GCC 2.95.3 being kept in the Legacy branch. It is set up to build for Haiku and not BeOS (checked version.c for that) so even if I did download the tools they'd need to be hacked into shape. I guess this verifies my concerns.

The reason I didn't simply modify the config script is that I have no idea what dependencies the later code has on the 081024 compiler. If there are none, then I'll simply hack the config files, but it makes me wonder why GCC was upgraded at all in that case. This in no way implies that I'm incapable of digging into it myself, I just needed information.

The project would have gotten a lot more help had such issues not been present throughout the last 7 or 8 years. Simply documenting how to do basic stuff is key to getting new people up and running fast, and currently the instructions for setting up are fairly useless. If everyone's cross-compiling from Linux then say so on the "getting started" page.

I spent months trying to get a clear idea of how to access the repository back in the beginning, and eventually gave up after several emails to Michael Phipps. Apparently the attitude of "we're 1337 hax0rs and so we don't need you anyhow" still prevails, unfortunately.

You might be interested to know that I worked on the original NewOS kernel with Travis, contributing to the HDD code, and in fact had NewOS running on a 486, which impressed him. And I didn't give him any attitude, because he knew what he was doing and deserved respect.

haiqu

Re: Coding Sprint Results

haiqu wrote:

I simply did a site search for 081024 and found two blog entries, both from the same frustrated developer and posted over 6 months ago.

Heh, that's a stretch ;)

What you found were the shotgun-style frustrations of a very vocal, and very non-self-educating stubborn non-developer who (at first) refused to build Haiku under any platform besides BeOS R5.

He blared this very same message all over the place until he finally got a response - on the mailing list IIRC - which is where most development-related discussion takes place.

After the aforementioned frustration, this person eventually started using Linux to build Haiku and can't believe how much faster/better it is for this task.

The "make my system work!" attitude certainly isn't getting Haiku anywhere and has become ever-so-common over the years - which is why you've gotten such a sour response here.

If you sent an email to mphipps directly for help so many years ago, then you relied on a single (busy) person to give you that help - which is exactly NOT how an open-source community works.

The answers mostly lie on mailing lists and IRC, and occasional this website comments and forums for new people who stumble through here.

Re: Coding Sprint Results

The "proper" communication channels have always been the mailing lists. Either one of the two would have been fine. That was the same over 4 years ago, when this site didn't even exist. But that's not the point. The point is that any grown-up should be familiar with the concepts of "We reap what we sow" and "It's not what you say, but how you say it". You basically declare us morons in your rant, so what do you expect? But I am not sure if I am spending my time here wisely, since in your new reply, you make it sound like we don't deserve any respect, because we don't know what we are doing. Funny that I type this on Haiku, which has become my main OS. And that wouldn't have been possible without some capable people fixing some remaining bugs in the NewOS kernel, let alone writing all the rest of the OS. That doesn't mean any disrespect to Travis' awesome work (whom I met and enjoyed in person), but it simply means that Travis cannot be the only one who knows what he is doing.

Sorry that BeOS and ZETA are a bit neglected as build platforms these days. We are trying hard to post working instructions, and all the GSoC students seem to make good use of them... You made it pretty clear yourself that you don't enjoy waiting hours for building the entire GNU toolchain. While that isn't even a requirement on BeOS, I don't enjoy waiting hours for a build either, which is why I use Linux to build Haiku. If I am not using Haiku itself, thanks to some people who know what they are doing.

Re: Coding Sprint Results

Facts: There were no mailing lists when I was last trying to get involved, and OpenBeOS had only just decided to use the NewOS kernel. This website or its predecessor must be older than 4 years, according to the system login I have been a member here for 4 years 38 weeks, albeit completely inactive.

Regardless of whether Linux is faster, leaving the BeOS platform unsupported for build tools is IMHO not very bright considering that it's the reason for the whole project. Apparently no-one built a BeOS tool package from the 081024 sources, and it may no longer be possible without a lot of work.

Since I don't use Linux any longer, I'll be hacking the scripts in the downloaded sources. Not an ideal situation, but it's apparently my only viable option.

Re: Coding Sprint Results

Matt created a patch for getting configure to work with the previous GCC 2.95.3 release for BeOS:

http://dev.haiku-os.org/ticket/3631

Maybe that works for you.

Best regards,
-Stephan

Re: Coding Sprint Results

Thanks Stephan, this patch is exactly what I already did this morning. I'm getting a few "missing file" errors and quite a few warnings, but the machine is chugging away and I should have a complete working build sometime today with any luck.

BTW the compilation speed isn't much of an issue here, since normally only changed files recompile. Hardly worth installing Ubuntu for the difference, especially when actual coding takes the majority of the time. I normally just cook dinner while doing a rebuild...

I won't reply to this thread any more, will be joining mailing lists instead. :-)

Cheerz.

Re: Coding Sprint Results

It's not just compile speed... I'm talking download speed as well.

On my Athlon XP 2000+ system, running BeOS R5 PE, it took about 2 hours to download the entire Haiku source tree. On Ubuntu 8.10... about 45 minutes. I kid you not! To JAM Haiku in BeOS R5 PE... *another* 2 hours. In Ubuntu 8.10... about 25 minutes!

Sure... go ahead and cook dinner while waiting HOURS for BeOS to do it's thing... but I'd rather have Haiku *waiting* for me, than me *waiting* for BeOS to *make* Haiku.

And, even when you're just doing minor updates, Ubuntu can pull down the latest revision of Haiku in a few minutes, when BeOS takes 15 minutes or more to do the same thing.... on the same hardware, on the same cable internet connection!

And don't EVEN get me started on how long it takes BeOS to delete the entire /develop directory, if something gets munged up. That takes 'bout an hour, too! Seriously!

BeOS has had it's day... it's time for it to be fondly remembered and retired for what it was back THEN, not what what it is today. It was GREAT back THEN. Today, it's nigh worthless! After seeing how fast Ubuntu was, I swore I'd never let BeOS R5 ever set foot on any hard drive I was going to be building Haiku on... it's just NOT WORTH IT!

What if I told you, my current Athlon X2 5000+ system can delete the entire /develop directory in about 2-4 minutes, in Ubuntu 8.10? Can you do that in BeOS? Can you use BeOS on a modern, dual core system at all? What if I told you I can do that AND have all the build tools and Haiku's entire source tree downloaded AND JAM'd, in under 2 hours?

Saving time in deleting/downloading/JAMing is what makes doing all those thing so much LESS painful than they used to be. I can tear everything down and be back up and running Haiku in so little time, I don't mind it so much when things go wonky. It's not just the hardware... Ubuntu is VASTLY faster than BeOS in EVERYTHING it does. And, on faster, more modern hardware, it's faster still!

BeOS is long past it's prime and officially dead. Haiku is alive today. The new future of BeOS! And Ubuntu is the path to downloading/JAMing that future!

And this coming from someone who struggled long in trying to keep BeOS as my chosen/preferred build platform for Haiku. And plenty too many will tell you what a PITA I've made myself, in striving to that end. But when the frustration grew beyond tolerability, I realized just how much a fool I had been not having switched to Ubuntu long ago.

Give it a try... you will NOT regret the savings in time you will see. Don't spend time waiting to get/JAM the latest revision of Haiku, using BeOS. Just do it with Ubuntu and get on with LIVING your life, not WASTING your time!

haiqu wrote:

Thanks Stephan, this patch is exactly what I already did this morning. I'm getting a few "missing file" errors and quite a few warnings, but the machine is chugging away and I should have a complete working build sometime today with any luck.

BTW the compilation speed isn't much of an issue here, since normally only changed files recompile. Hardly worth installing Ubuntu for the difference, especially when actual coding takes the majority of the time. I normally just cook dinner while doing a rebuild...

I won't reply to this thread any more, will be joining mailing lists instead. :-)

Cheerz.

Re: Coding Sprint Results

Thanks for your comments, and I appreciate your enthusiasm for Ubuntu's speed, but I have a different perspective. My first computer had an 8088 in it, and I started on the internet via CSIROnet in 1982, using an acoustic phone coupler. My first private connection to an ISP in 1994 used Trumpet Winsock on a 486SX-33 running Windows 3.1, and I was browsing it under Netscape 2.x

So speed is a relative thing. Besides, I'm 56 years old and so I don't have a social life any more. I can wait. :P

All the best.

haiqu

Re: Coding Sprint Results

Everyone these days is using Linux ( or BSD ) to build Haiku. Some people may even use Haiku itself to build Haiku or applications. Building on Linux is fast. I used to build on BeOS, about 2+ years ago, which was slower.

There are ( outdated ) instructions on how to build Haiku on Linux and if you read the comments they give tips and advice too to get you going. Plus there are people on the mailing list that will help you out too.

The proper developer channel is the mailing lists. The two popular ones are the General and Development ones. You'll always get help from the mailing list. The forums are for end users and are not really used these days.
http://www.haiku-os.org/community/ml

Stephan is a main developer and has put in lots of work into Haiku so understandable why he was offended by your ( negative ) remarks.

Re: Coding Sprint Results

Great work, thx to all busy developers making this possible.

Only two blocker bugs preventing HAIKU to become Alpha, hmmm.
Sounds very good. I'm excited too.

Unfortunately, I cannot download and test the 100MB+ Image as my connection is too slow for a huge file like this:
(haiku-pre-alpha-r30387-raw.zip 103.17MB 4:45PM 24th April, 2009)

The last raw-image (plain vanilla +-30MB) I tried is dated 20 February 2009.
Two days ago I tried to download the pre-alpha (haiku-pre-alpha-r30286-raw.zip 102.35MB 4:45PM 20th April, 2009) but it wont boot at all.
I have 3 Computers here P3, P4, and a core duo2 Notebook.

Usually I download the files, unzip it in Zeta and use mountimage to mount the image, then I mount the HAIKU partition and copy all files to it. Usually it worked but now it is no more booting.

Should I just wait for the Alpha Release?

I am eager to try and test the new builds but a plain vanilla would be still very helpful.

I think there are lots of people out there with a slow connection and old hardware. A lightweight HAIKU to install on older Hardware is very welcomed.
I think HAIKU should still try to please this user group and the old Computers too.

Re: Coding Sprint Results

Hi Bruno,

your method of installing Haiku is just not supported anymore. We have changed the directory structure, and now there is no more /boot/beos/system/zbeos on Haiku anymore. It's now /boot/system/haiku_loader. For this reason, the ZETA makebootable does not make a Haiku partition bootable anymore. You have to use the Haiku makebootable compiled for ZETA. I don't know if anyone made such an executable available yet. You can build it from the source, but it sounds like that would be a hassle for you. Sorry, I don't use ZETA anymore myself.

As for the slow computer user target audience... nobody ever said that Haiku was not supposed to run on slow computers anymore. We have every intention to make Haiku run well on slow computers.

Re: Coding Sprint Results

Ah, yes thx stippi,

I have zeta, haiku1, and haiku2 on my harddrive.
So thx for your hint that you changed something in the bootloader.
I copied the new makebootable to my haiku1 partition and made haiku2 bootable with it...
Now it works thx stippi.

But with the bootloader there is still lot of work to do.. isnt it?
If I rescan my CD or USB-pendrive it will still not find any HAIKU/Beos or Zeta image.

I missed it, that you changed the way the bootloader is working...
Maybe you could explain the reason for it, or a link for that change...

I am very happy that you still follow the way to support old hardware...
lots of very old hardware is still used for example in many asian counties as I know...
400MHz still very common there, and a modem connection speed with 56Kb.

Thx, for your help.

Re: Coding Sprint Results

@luposian Well, you may find ubuntu really fast but I think most of the speed issues you are talking about wouldn't exist had Be not went under and had updated their OS to support modern HW features

Ubuntu will barely run on systems that BeOS flat out screams on... a dual PII for instance even with 512mb ram ubuntu is a slug and won't play Dvd or do much multitasking at all

as far as hard drive performance I think that has to do with the size of the clusters in the filesystem and what the HW really has ... modern hardware have 4k iirc and BeOs only using 1k or something like that making disk access sub optimal

BeOS had its day.. it isn't the fastest kid on the street anymore just because it hasn't been updated in 7+ years or so.. I still think it is awesome though :-) nocks the socks off windows 98