This would make a great tagline for a Haiku tee-shirt.
2 Likes
Here is the original SoundPlay site copy on archive.org. The author mention the free availability of the keyfile, but unfortunately the download ink don’t work. Please, check the second link to grab a copy:
https://web.archive.org/web/20130609080641/http://marcone.home.xs4all.nl/soundplay.html
The keyfile could be download from here:
4 Likes
Thanks! I miss Marco. He was a delight in the community and SoundPlay was a revolutionary application.
It would be best to build into 64bit Haiku a 32bit run mode for applications that need it. I think some Haiku devs were working on a possible solution.
2 Likes
That still leaves out available 32-bit hardware.
2 Likes
I really don’t understand why some people are pushing towards removing the already available and working support for the x86 32bit architecture.
Yes,it would be really nice to have a 32bit runtime on 64bit Haiku,because I use 64bit computers mostly and could try out some old BeOS apps then.
But there are still lots of devices which have a 32bit-only CPU or a 32bit UEFI so that a 64bit system can’t boot,even if the CPU supports it (I have the latter problem with one of my tablets).
It makes some sense to remove 32bit support from Winblows or even most Linux distributions,because they’re very bloated and slow,you won’t have much fun with them on old 32bit hardware.
Haiku,on the other hand,is fast and lightweight and still runs great on them,maybe it’s the only option to still use those old devices.
It would be a shame to remove support for 32bit devices,just because we can and some people think it’s outdated.
8 Likes
I’m with you in that. I hate seeing otherwise good computer hardware get trashed because operating systems like Windows are not optimized or supported to run on them anymore.
5 Likes
I don’t think that any Haiku developers want to drop 32-bit support, so I don’t think people need to worry. It would be nice to finish the work started to run 32-bit applications on a 64-bit Haiku. I think that will get resolved eventually. I agree revitalizing older computers is a niche that Haiku can and should serve.
16 Likes
32Bit is here , and to stay with us for a good long time .
This talk of “lot of broken stuff” and “problematic” is very exaggerated.
And again, this is one of those threads that easily devolve into more unpleasant message exchanges.
Better than complain that others shouldn´t use it, people could help with solving the bugs. or at least helping with the creation and data gathering about the theoretically-existing bugs.
2 Likes
It was once said that they wanted to reprogram beos and this was 32bit. That we want to keep the old programs running, all 32bit. And that at the earliest after the r1 circuit is with 32bit.
2 Likes
glibc decided to go this way. Their time_t handling is now extremely complex, they started this work 15+ years ago and they are still not done.
Yes, it’s possible to add a time64_t or something, but then it adds a layer of complexity either to the C library (so you can build your program using “time_t” in your code and it compiles to a 64bit type), or in programs (all developers must now use time64_t instead of time_t).
It is of couse possible, but it is the kind of extra complexity where I would say we have to stop being crazy and maintaining 32bit support with BeOS compatibility in this way. I’m happy to do it as long as it doesn’t have too many impacts on the other architectures. If someone comes up with a patch for this, and it does not create a whole mess in the C library like the glibc approach does, I’m fine with it. But it’s not something I wish to spend my time on.
Also, even if we fix this for new apps, old BeOS apps will be confused about it and show the wrong time. Making it really clear now that people still running BeOS apps are living in the past and they had ample time to consider their options to migrate to a supported solution/get the author to update their app for Haiku or publish the sourcecode/find someone to rewrite the app. We’re talking of a timeline of almost 40 years here (from 2001 to 2038). I consider this a more than reasonable lifetime for an ABI.
Hopefully, by 2038 we will have already shipped the R1 version and we can reconsider how we’re doing BeOS API support (or if we still do it at all). In that case, changing the ABI is fine, and we can simply make time_t a 64bit type.
Of course this says nothing of other possible 32bit architectures (ARM, PPC, …) where we don’t have plans for BeOS compatibility, so we can go with 64bit time_t from the start.
4 Likes
I think that API returning 64 bit UNIX time should be available on 32 bit x86 even if most apps will not use it. It allows to make 32 bit applications that really need it.
Use real_time_clock_usecs. This one will keep working for 584 500 years and is already available in BeOS.
But you don’t have any function to convert it to a date (strftime, strptime), no timezone handling (gmtime/localtime), etc. In Haiku you can use BDate, BTime and BDateTime but I don’t think they accept a bigtime_t as input yet. We could add that.
3 Likes
Does an OS depend on timestamps?
What if not?
Time is needed everywhere, from something visible like displaying the actual time of the day to many internal things. Not only in the OS itself but many applications rely on getting timestamps from the OS (through the API).
1 Like
Why drop support!? Keeping things on par for gcc11 on both 32bit and 64bit keeps us on edge (and helps sometimes to fix underlying issues), my focus will remain 32bit for as long as it can.
3 Likes
I think that this way of thinking about electronics is very problematic. We should keep in mind that not everyone want’s to constantly upgrade their computer. Most computers are used for rather simple tasks like word processing and other office tasks and for that, there are plenty of 32-Bit only machines out there which are way more than capable for this. I’d bet I could do my school-related tasks on a 2004 pentium 4 with 1.8 GHz without facing any problems.
Then, there are many people that can’t afford to just upgrade their tech, they don’t have the means. And they are dependent on having light operating systems that support their systems, like Haiku does. Dropping the 32-Bit architecture as long as supporting it would be feasable would be an act of unsolidarity in my opinion.
And just replacing old computers with new ones would cause totally unneccesary damage to our climate as well as causing a lot of suffering during production. I’d say that most newly bought computers could be, for what they are actually used, just be filled in by existing used computers. You just don’t need an i3 for using a word processor, a pentium 3/4 does the job just fine. So many new computers could thus be seen as a waste of carbon-emissions, labor and resources.
7 Likes
I personally am against fully dropping 32-bit x86 support until after R1. I have zero x86 hardware left which is 32-bit only… however in the spirit of providing a 1:1 replacement for BeOS, i’d like to see R1 run on older 32-bit x86 hardware… our minimum hardware target is still Pentium.
To be honest, we already made a concession of dropping the x86 (32-bit) in favor of the x86_gcc2 (32-bit) ports. (aka, instead of having two 32-bit x86 ports gcc2, and gcc11… we just have the “32-bit” port which is x86_gcc2 hybrid)
After R1 comes out, I think we’re fully justified dropping 32-bit x86.
The plan is to support R1 for quite some time with patches / updates. (thus why i’ve been working on our infrastructure to support stable branch builds)
8 Likes
I would just not quite understand why you would want to drop that architecture, especially since the Be/Haiku API is stable between architectures and most of the work (as far as I understand, I don’t want to downplay the task of maintaining an architecture) is already done. There are more packages for 32-bit than for 64-bit. And I don’t see how many simple tasks (many office-tasks) would change in a way so you’d require a faster computer.
But I very much understand if/why you’d like to drop the gcc2 part as it has to be quite annoing to conform to old standards.
1 Like
Ok, to clarify…
After R1 comes out, I think we’re fully justified dropping 32-bit gcc2 x86.
Nobody is really rushing to drop x86, just x86 gcc2. Post-R1 we could theoretically have a 32-bit compatibility layer (or gcc2 compatibility layer) that installs on x86_64. However that is pure speculation.
2 Likes