Haiku R2 what would BeOS be today?


#1

Haiku R1 will be out soon enough (hehe) so time to think about what Haiku R2 will be. If Be had survived what would they have built or what would you like Haiku R2 to be like?


#3

Let’s party like it’s 1998 again!


#4

Just my opinion, nothing more… but here it goes:

  • For BeOS v24 (probably would be where it would be by now) the kernel would have been rewritten by then, like how Haiku has the NewOS kernel.
  • Judging by what the Mac OS (X; on BSD) and the Palm OS (webOS; on Linux) historically did, if such a plan proved to be impossible, an alternate base would’ve most likely been picked.

More than likely, I think option #1 (a next gen Be kernel) would’ve been done as Be had talented engineers who were dedicated to keeping BeOS unique to itself working on it.

But what else would’ve changed, do I think? Again, just my little opinion…

  • Once again, summoning parallel history as a metric, the UI would have inevitably changed by now and would’ve been given a name, like “Maui” or similar. Every other UI from Palm to Gnome/KDE to even Windows is named and also much different than when Maui last left off in 2000. Already, in Dano, springboarded, pulsating buttons were taking place, and most likely, Be would’ve evolved with a compositor, animation, gradients, and a smooth new look, but would have remained true to itself. It would probably also have new, enhanced icons (maybe even vectorized versions like Haiku), new decorators, and pervasive thumbnail views (integrated in Tracker, in the Twitcher, etc.)
  • Live previews in Deskbar would’ve happened; maybe larger app blocks would’ve happened as well.
  • As an answer to the Dock, and later the Superbar in Windows 7, something like an enhanced LaunchBox would’ve taken shape.
  • Multiple user support would’ve been added by now, with a lock screen
  • Improvements to several preflets like Backgrounds
  • Open and save boxes would have adopted a filtering-first UI across the system.
  • BeOS would support Bluetooth and Wifi like Haiku currently does, and probably would also support printing to ePrint, AirPrint, or similar as well.
  • BeOS would have added universal access by then in addition to the magnifier, like text to speech, writing support, and speech recognition.
  • Cursor handedness for left and right, grayscale mode, and other goodies probably would have been added as well.
  • Full display scaling and orientation would have been added.
  • Help would have been added to the Be menu and also in apps, like in StyledEdit. Be never got a chance to finish after R5; I think they would have got to this somewhere between R5 and v24 (my estimate, based on the speed of 3.x to 5).
  • DriveSetup would’ve been more modern like the one in Haiku. Solid state drives would be supported like Haiku.
  • Like Haiku, notifications would’ve been added. Except, and it’s just me… I think they would’ve added them as a replicant that could optionally live in the Deskbar.
  • Speaking of replicants, after Tiger and Vista, Be would’ve had to revamp their replicant system. Sometime after Vista, Be would have added a central manager for replicants (say, the Replicator?) and would have made them easier to add and close that way.
  • I do believe Be would have added a New Tab button to all apps like what Firefox (or Opera, depending on who you ask) did for the browser to make tabbing more obvious.
  • The zoom button would’ve changed, probably, to a “full screen” symbol and behavior like macOS did in 10.10.
  • An attribute based universalized search much more powerful than Spotlight would have been made; imagine the untethered power of People or Mail inside Preferences or the applications folders in Tracker. Not even Spotlight would have been as awesome as that!
  • MediaPlayer and ShowImage would’ve evolved into a metadata aware super center, connecting to phones, iPods (probably the originals with a special add-on), and palmtops.
  • Getting much crazier, I wholeheartedly theorize Be would have come up with time aware attributes in addition to the others to create dynamic snapshots and queries to revert the system to a timeframe like Haiku does now.
  • Packages or bundles would have become a thing for sure.
  • Home and/or full disk encryption would’ve happened.
  • Like the Mac, the calculator would do quick conversions.
  • BeIDE probably would’ve evolved to look and act like XCode.

I do NOT believe Be would connect to the cloud. Maybe IA would if Be was still around, but the professional, desktop oriented edition would keep things local.

There’s many other things besides this quick list I could think up here and now, but there’s some of my theory of what BeOS would have looked like today. :slight_smile: And also some of these are what I think Haiku R2 is going to add to itself after R5 compatibility is achieved with R1. :smile:


#6

Haiku R2 should make it’s aim to clone BeOS R3.


#8

Sorry, I’m tired after a very busy weekend at FOSDEM, I should probably take some rest before replying.

I didn’t want this to sound offending or agressive. I just think the Aqua look, while great for its time (and possibly better than what MacOS looks today), is now outdated and not something I’d like to see added in Haiku.


#9

Sounds like there is a need for an archaeological dig into the Glass Elevator project and whatever has been captured in discussions there. Who knows where that stuff may be. Anyone here ever involved in that back in the past?


#10

FWIW, I don’t see either @PulkoMandy or @bullfrog remotely approaching incivility that would justify pointing them to the netiquette. IMO it read quite obviously toungue-in-cheek.


#13

What did I say that was uncivil or disagreeing? Yes my comment was sarcasm, but meant to be a lighthearted joke. And not directed at anyone, just a general response to OP. Perhaps a cultural misunderstanding is afoot?


#14

1998 doesn’t even make sense Aqua wasn’t introduced until Macworld San Francisco
in 2000. All the same here is the BeOS Colors! app featuring Aqua pinstripes http://maybe.de/software/colors/gfx/screenshot.jpg circa 2001. Be’s untimely demise allowed us to circumvent that all too popular anti-design pattern.


#15

Id love to see my comments on the cover of NY Times.


#16

I think it was more of a loose pun on the Prince song of a similar name rather than be an accurate date relevant to the timeline.


#17

I recall hardware video acceleration being the major bit of GE that was slated for R2. Most of GE was keeping up with the Joneses type stuff. Much of it has already been implemented, such as improved package management.

I think a modernized Deskbar replacement was also talked about in early GE talks.


#18

Thing’s I would want to see in Deskbar is a less clunky application list (fewer clicks to swtich applications), I set mine to always expand to slightly mitigate this.

I think windows should not be able to get lost off the screen as they currently can… they should also fit themselves into the available screen space automatically. (open many windows on a large resolution then switch to a smaller one)

QuickLaunch integrated directly into deskbar. Click the menu then type… drills down into all applications system wide, click in a menu and type filters that submenu etc…

File search input directly. Click search textbox. Should also exist in Tracker to increase discoverability.

An directly organizable menu ala windows 9x-XP. Being able to organize things how I want was alway nice… the drawback was people from other computers loosing usability but being able to quicklaunch from the menu would mostly negate that drawback.

BeOS would definitely have had hardware accelerated OpenGL/OpenCL/Vulkan and some audio/video acceleration API. Actually realtime audio… this may require hardware development as most sound card vendors have given up on latency.

An IDE with RAD, auto completion, code refactoring, version control integration, integration with the packaging system. Compiler as a service perhaps? Interactive C++ via Cling?

I think Be developers would have written more cool example applications.

I think they would have been intrigued by developing critical areas of code in Rust or some other verified language to increase code quality especially in drivers.

Potentially a desktop focused clustering API, so you can boot up compute nodes and attach them to your workstation to complete rendering work faster etc… or to just auto offload work to a second computer so you start a transcoding application and your NAS automatically runs it in the background instead of on your laptop.


#19

I think Be would have shifted away from sample applications over time. They did that to try to attract application developers, but as the ecosystem grows, there is less need for that.

Rust in the kernel? Probably not. Be had a kernel written in C. It’s already nice we got one in C++. You would be surprised how hacky and messy the BeOS code was, they weren’t this much into making things clean and safe.

Anyway, I’d rather look at the actual future of Haiku, rather than what BeOS could have been?


#20
  1. What about multiuser?
  2. Jails and such?
  3. Can the GUI be optional?
  4. How far away is ARMish Haiku-OS?

#21
  • We already have the posix multi-user stuff, just no multi-user in the GUI.
  • See first response.
  • Not as such in the default install, but command line junkies have no big issue using Haiku through ssh and the terminal. You can make terminal full screen.
  • ARM is still hopeful, but not a current focus.

#Note:
Haiku is not focused on being a server os. The focus is on the desktop.


#22

Neither was Mozilla… but that’s a debt you have to pay off at some point. I think they were pretty open minded though, and their kernel in C would have interoperated with Rust well unlike C++ (although Haiku uses a subset that woudln’t be too bad to interop with Rust in some areas like drivers).

I think replicants are a largely unfinished technology that BeOS may have polished further… to make things more reconfigurable to a users taste without having to rewrite code. I mean I can imagine a group of system replicants used throughout the system to great effect, Menu Tray and Task list as swappable to your preference replicants. So you could have a Deskbar that looks exactly like BeOS, or swap out the relplicants with more modern features.

Deskbar itself would then just become a draggable around the desktop replicant container. This in some way Mirrors how you can reconfigure FireFox’s UI (to varying degrees depending on version).


#23

Reminds me of Clemens demonstrating the ALM layout manager at a BeGeistert a long time ago. Nothing to do with Replicants, but with it he could drag buttons and any other views around and re-arrange the GUI of a test app. The views resizing to fill the space etc.


#24

OpenBinder was suppose to be a new IPC mechanism in BeOS R6 which never saw the light of day. Dianne Hackborn released the source of OpenBinder while at Palm (http://www.angryredplanet.com/~hackbod/openbinder/) and Binder did eventually make its way into Android. Theoretically OpenBinder could be picked up and turned into the next version of replicants but I’m not holding my breath.


#25

One thing I’d like to see is stack n tile extrapolated out to be like a tiling window manager. Window resizing would be automated to make full use of the screen space. You could also use key combos to switch, resize and manage window layout without resorting to mousing.