[HN Gopher] Giving Haiku Beta 3 a try
___________________________________________________________________
Giving Haiku Beta 3 a try
Author : pjerem
Score : 105 points
Date : 2022-01-01 11:26 UTC (11 hours ago)
(HTM) web link (www.friendlyskies.net)
(TXT) w3m dump (www.friendlyskies.net)
| xyproto wrote:
| Is there a Linux distro out there that is themed to look like
| HaikuOS and works well?
| capableweb wrote:
| I guess you could look for themes (Gnome: https://www.gnome-
| look.org/p/1143497| XFCE: https://www.xfce-look.org/p/1013908/)
| but you won't get the same unified GUI as Haiku has, since
| everything is built with unification in mind, compared to the
| Linux ecosystem where modularity is usually king.
|
| I guess Elementary OS is as close to a unified GUI you come
| that runs with a Linux kernel, but it tries to look more like
| macOS than BeOS.
| rvense wrote:
| The looks are the least important part. It _works_ differently.
| Applications interact in a different way, there ' APIs
| (especially around filesystem metadata) that applications and
| scripts can use. It's not necessarily that the capabilities
| don't exist on other systems, it's just that they're exposed
| and most importantly used in a different way. It's also a
| system that was built from the ground up to be GUI-based. The
| command line is there, but it's not the primary means of doing
| anything much.
|
| There are BeOS/Haiku window decoration themes for at least XFCE
| and I think OpenBox. But looks are really not what Haiku is
| about.
| schleck8 wrote:
| > _The name of the project is simply "Haiku". Unfortunately,
| despite numerous attempts, the registration of haiku.org has not
| been possible; hence the reason for haiku-os.org._
|
| And guess what, the domain haiku.org is collecting dust. What a
| surprise with how civil the domain market is.
|
| https://www.haiku-os.org/about/faq/#why-isnt-it-called-haiku...
|
| https://haiku.org/
| KZerda wrote:
| Domains are used for more than just webhosting. The owner could
| have email accounts, etc, that use the haiku.org domain that
| they don't want to switch to another less recognizeable name.
| thewakalix wrote:
| Seems likely. Starting Nmap 7.80 (
| https://nmap.org ) at 2022-01-01 14:17 CST Initiating
| Parallel DNS resolution of 1 host. at 14:17 Completed
| Parallel DNS resolution of 1 host. at 14:17, 0.00s elapsed
| Initiating Connect Scan at 14:17 Scanning haiku.org
| (35.213.168.88) [11 ports] Completed Connect Scan at
| 14:17, 5.00s elapsed (11 total ports) Nmap scan report
| for haiku.org (35.213.168.88) Host is up. rDNS
| record for 35.213.168.88:
| 88.168.213.35.bc.googleusercontent.com PORT
| STATE SERVICE 21/tcp filtered ftp 25/tcp
| filtered smtp 53/tcp filtered domain 80/tcp
| filtered http 110/tcp filtered pop3 143/tcp
| filtered imap 443/tcp filtered https 587/tcp
| filtered submission 993/tcp filtered imaps
| 995/tcp filtered pop3s 3306/tcp filtered mysql
| Read data files from: /usr/bin/../share/nmap Nmap done:
| 1 IP address (1 host up) scanned in 5.06 seconds
| watermelon0 wrote:
| Those ports are commonly exposed when using a web hosting
| provider. Visiting above IP serves with TLS cert for
| Siteground, which is a popular provider.
| rvz wrote:
| Maybe if they had tons of cash somehow, they would have bought
| it already, just like how Signal was able to buy signal.org
| (even with or without donations) regardless.
|
| Assuming everyone here from many companies from large
| corporations / startups to small open-source companies know how
| expensive some domain names are.
| halpert wrote:
| What is your opinion on property rights?
| krono wrote:
| IANAL: As I understand it, dotcom domain names are leased
| rather than owned.
|
| Either way, if squatting of high value domains were illegal,
| you could make the case for some form of (civil) asset
| forfeiture, or eminent domain if the taker is a popular open
| source project. Not sure how I'd feel about this, though.
| halpert wrote:
| Rights of parties in a lease are also governed by property
| rights.
| analognoise wrote:
| There's no way business interests would ever allow asset
| forfeiture to help open source projects.
|
| It's a laughable idea.
| Fnoord wrote:
| Trademark perhaps?
| [deleted]
| krono wrote:
| The concept of "Eminent Domain" entails the state taking
| private property specifically for public use always.
|
| Which is why I mentioned it in relation to open source,
| separately from forfeiture :)
| fragmede wrote:
| Open source projects with no backing run by a single
| overworked and unpaid developer, yeah, but the legal arm
| of billion dollar open-source company Redhat definitely
| going to try _some_ shenanigans if you somehow managed to
| gain ownership of redhat.com
| gtsop wrote:
| I was completely oblivious to the existence of haiku until i saw
| a couple posts on HN. Is there any tl;dr version of how it is
| different than let's say a linux distro?
| Ygg2 wrote:
| It's derived from BeOS, rather than a Unix.
|
| Also it's a hybrid kernel written in C++, unlike Linux which is
| monolithic kernel in C.
| tialaramex wrote:
| > Also it's a hybrid kernel written in C++, unlike Linux
| which is monolithic kernel in C.
|
| "Hybrid" doesn't mean anything here. The "hybrid" design
| claims all the benefits of a monolithic kernel, without the
| disadvantages of a microkernel. Huh. Wait, let's read that
| again. It's a monolithic kernel with better marketing. Even
| the networking, which in BeOS back in the 1990s was genuinely
| userspace code - is baked inside the Haiku kernel just like
| the IP stack in Linux.
|
| C++ is not used very much in Haiku's kernel. This is because
| the Haiku kernel ABI boundaries are defined in C not C++ and
| because they're stuck with stuff from last century for
| compatibility reasons. If you know C++ 20 you will find
| Haiku's C++ dialect pretty archaic, they don't yet have C++
| 11 era smart pointers for example.
|
| In practice, unlike Linux the Haiku kernel has a very 1980s
| attitude to hardware, it's big on "probing" at boot time for
| devices, like DOS would have, making it a poor fit for modern
| intelligent peripherals. As a hack USB is treated a bit
| differently so that at least it has some sort of "hot plug"
| like a 1990s PC. Where Haiku tried to go beyond probing they
| chose something very strange, they focus on capability
| discovery. So Haiku's thing is, you want a sound device, lets
| look for a sound device, I can't see one, give up. In Linux,
| discovery is driven by the peripherals, so this is a PCI
| controller, let us explore the PCI bus, OK there's a USB
| controller on it, let's explore the USB bus, OK there's an
| Intel HDA controller on it, let's explore that, it's a PCM
| output. We can play sound through that. Haiku's approach
| might fit well in some other universe, but the Linux strategy
| matches how your hardware actually works in our universe.
| waddlesplash wrote:
| (Haiku developer here.) We have our own homegrown smart
| pointers and do make plenty of use of them, though we could
| stand to make more. Already pretty much any short-lived
| objects (i.e. that have no lifetime beyond the function
| they are immediately in) are smart-pointer-managed.
|
| The "probing" approach needs a rewrite and we know it. Most
| of that code is confined to about 2-3 files inside the
| kernel. It will be a big job to fix it, but we won't need
| to reinvent the world. Eventually I or someone else will
| probably get around to it, but we haven't needed it yet;
| the people who need PCI hotplugging will have to do without
| Haiku for now. (Or they can submit patches :)
| capableweb wrote:
| Which means:
|
| - Different Kernel (based on NewOS if I'm not wrong)
|
| - Alright POSIX support but not 100%
|
| - Haiku has is unified base/GUI/OS compared to Linux
| distributions, that often choose their own window
| managers/composers/custom kernels (sometimes) and so on. One
| example is that the GUI is driven by the kernel in Haiku, in
| comparison to Linux distributions that often use X11 or
| similar software between
|
| - Different bootloader that seems more Windows OS aware than
| GRUB et al
|
| - Haiku focuses on personal computing, compared to Linux that
| (mostly) feels to aim for server usage, with supporting
| personal computing. But sometimes those things are at odds,
| and Linux allows you to configure it to be better for one or
| the other use case, while Haiku aims strictly for personal
| computing.
|
| - Haiku/BeOS always had multithreading/multi-processor in
| mind for it's design. If it's faster/better or not I'm not
| sure, but the focus been there since early
|
| - OOP API for development of Haiku software (if that's better
| not is an exercise left to the reader)
|
| I think the biggest selling point of Haiku is it's unity
| regarding the entire operating system being designed for one
| specific use case: personal computing. So responsiveness of
| the GUI is prioritized because that's the best for personal
| usage, while Linux (can) make other tradeoffs while allowing
| you to customize it.
|
| I'm writing this from the perspective of someone who test-
| driven Haiku a couple of times but never used it full-time,
| but am a daily user of Linux distributions (Arch, NixOS and
| Ubuntu). Some things might be wrong, I'm happy to be
| corrected if so, but this is what I've gathered from my usage
| and reading about it a little every time it pops up
| somewhere.
| hestefisk wrote:
| Is it multi-user?
| orionblastar wrote:
| Not yet, like the Amiga there is no login. It is still in
| beta and needs hard drive encryption as well.
| AnIdiotOnTheNet wrote:
| What is the virtue of a multi-user desktop? There are
| vanishingly few use cases for such a beast.
| jhbadger wrote:
| I think most people with SOs or families see the benefit
| of having each user of a shared computer having their own
| user account.
| AnIdiotOnTheNet wrote:
| 1) We used to share desktops with family before multi-
| user was a thing desktops did.
|
| 2) With smartphones and tablets and the like providing
| most of the functionality that people once shared a
| desktop for (web browsing really), there seems little
| reason to share one anymore.
|
| 3) I think having multiple user _profiles_ one could
| switch between would cover almost any remaining use cases
| without the complication of multi-user in the kernel
| itself.
| em-bee wrote:
| for a usable multi-user system it is necessary to be able
| to protect files from other users. a simple profile is
| not enough.
|
| fortunately haiku does have multi-user support in the
| kernel, it's just not implemented in the GUI yet.
| AnIdiotOnTheNet wrote:
| > for a usable multi-user system it is necessary to be
| able to protect files from other users. a simple profile
| is not enough.
|
| That is what encryption is for. The big difference of
| course being that encryption is not one privilege
| escalation or boot disk away from being completely
| useless.
| em-bee wrote:
| ok, so if we don't have multi-user support in the kernel,
| but instead implement it only as a layer in the GUI, each
| user gets a partition or disk image that is encrypted as
| their home directory that is mounted on login. the
| file/partition is protected against deletion.
|
| i suppose that could work, but i see a few downsides to
| this approach: all processes run in the same space. if i
| want to run a process in the background my home directory
| has to be remain mounted, and thus potentially be exposed
| to the next user. or i'd have to create a second
| partition for this special process which only an
| experienced power user would do.
|
| so while i think this approach is possible, it doesn't
| look like it would make anything easier. on the contrary.
| the emergence of hostile apps on android demonstrates
| that privilege separation of processes is becoming more
| and more important.
|
| the current multi-user approach is not good enough even
| for that. but instead of simplifying multi-user support
| to a single user, we actually need to make it more
| complex to properly handle multi-user-per-process
| separation.
| AnIdiotOnTheNet wrote:
| Privilege separation for applications is not the same as
| having separate user accounts.
|
| > but instead of simplifying multi-user support to a
| single user, we actually need to make it more complex to
| properly handle multi-user-per-process separation.
|
| I disagree. This is such a small and vanishing use case
| that adding complexity for it is exactly what you
| shouldn't do.
| em-bee wrote:
| _Privilege separation for applications is not the same as
| having separate user accounts._
|
| true, and yes, maybe the whole system needs to be
| redesigned for that. but nevertheless, this needs to
| happen in the kernel. and once we have proper process
| separation, adding multi-user support on top of that
| seems almost trivial.
| michaelmrose wrote:
| Arguably you are one privilege escalation or boot disk
| away from being compromised to the point that the other
| user can acquire your passphrase or key from memory. If
| merely a passphrase it could even be gathered by a device
| between the keyboard and computer or plugged into a usb
| port.
|
| Security vs someone who has physical access to your
| machine while you aren't there will probably remain
| crappy.
| rvense wrote:
| I don't know the details about Haiku, but at the end of
| its life, BeOS had some kind of multiuser support, in
| that the OS was aware of UNIX-like permissions in the
| filesystem (and for processes _I think_ ). But there was
| no GUI for logging in, so you were always root.
|
| It was meant for single-user workstations. Not having
| multiple users was not really a problem, except that it
| made (makes) some people look down their noses. In this
| day and age, the main security issue on my workstation is
| that I all applications - including the browser that
| downloads a bunch of untrusted code and runs it willy-
| nilly - run as the same user that owns all my important
| files. I'm a lot more concerned about what's in my home
| directory than anything under /usr!
|
| So if and when Haiku adds security measures to isolate
| applications from each other, I would prefer they looked
| at some kind of sandboxing to isolate every app from each
| other, rather than just copying the basic UNIX model,
| which does basically nothing for the problems people
| actually have.
|
| (OK, if you need to share a computer which another person
| you can't have separate settings and browser histories
| etc., but.. I don't know if that's really such a big deal
| that it needs to be tackled before the other one)
| rzzzt wrote:
| > you were always root
|
| baron :)
| cable2600 wrote:
| HaikuOS https://www.haiku-os.org/ is a free and open source
| rewrite of BeOS using APIs it can run BeOS code and has had a
| lot of apps portered to it. It needs less memory than Linux and
| is more like ReactOS https://reactos.org/ when they add in the
| WINE porting to run WIN32 and WIN64 apps.
|
| BETA3 is stable enough to use a web browser and email program
| to get things done. It can be installed on old retro legacy PCs
| to make better use of them.
|
| Run it in a virtual machine first.
| fernandotakai wrote:
| nitpicking, but the OS is called just "haiku", not haikuos.
| nyanpasu64 wrote:
| Beta 3 won't boot on my Zen 3 desktop. Should I try the
| latest nightly, report a bug, or only run it on older
| hardware?
| waddlesplash wrote:
| (Haiku developer here.) It works on my Zen 2 machine and
| I'm pretty sure one other developer runs it on Zen 3. Note
| that you have to use the EFI loader (only on x86_64) and
| you might need to use the fail-safe video driver if you get
| a black screen after the splash. If that doesn't work, yes,
| file a ticket.
| fold3 wrote:
| I'd recommend older hardware or in a VM.
| kgraves wrote:
| Given the amount of progress in porting Wine [0], RISC-V [1], 3D
| Acceleration and now has finally a full time developer
| (waddlesplash)
|
| It very is astounding to see what the Haiku team has done with
| the resources they currently have on building what could be a
| useable alternative OS for the desktop.
|
| I can only kindly suggest more of us donate to Haiku [2] there
| still needs to be more browsers (Chrome / Firefox) and polished
| ARM support (think Raspberry Pis)
|
| [0] https://discuss.haiku-os.org/t/my-progress-in-porting-
| wine/1...
|
| [1] https://discuss.haiku-os.org/t/my-progress-on-real-risc-v-
| ha...
|
| [2] https://www.haiku-inc.org/donate/
| [deleted]
| discmonkey wrote:
| It would be great to implement some of the windowing improvements
| as an addition to a current linux windowing system.
|
| Pinning different applications together or being able to merge
| applications with tabs both sound useful... These sorts of ideas
| are why it's great to have another open source OS.
| djur wrote:
| Tabbed window managers have existed for X11 for ages, but the
| concept only seems to have remained popular in tiling WMs, not
| stacking WMs. KDE had built-in support for tabbed windows for a
| while but it looks like the feature disappeared a few years
| back, which suggests it wasn't being used much.
| michaelmrose wrote:
| Good points. Although tiling may be a departure wanted or
| unwanted from your normal workflow i3wm does provide support
| for tabbing arbitrary applications together however this
| neither supporting merging 2 tabbed application into a single
| level of tabs nor does it fully support using window manager
| tabs in place of application tabs because of the inherent lack
| of context that would require a deeper sort of integration.
|
| For example in your browser you might want in its UI to open a
| particular link in the background or foreground or perform an
| operation on all tabs or a subgroup thereof that is specific to
| browser tabs that wouldn't make sense in the broader context
| like bookmarking, saving a session, sending to another device
| etc.
|
| There is a good argument for opening a window in the fore or
| background being exposed to the application but it doesn't at
| present work that way.
|
| Regarding multitab operations, do you display only the options
| that make contextual sense or perhaps list all the options that
| make sense?
|
| Example 3 firefox tabs and 2 Emacs tabs in a group. Show
| bookmark all firefox tabs and save all Emacs tabs as operations
| that can be done to the group? Possibly show only the relevant
| options if some subset are selected. Example if only 3 firefox
| tabs are selected show only those operations.
|
| There is an argument for retaining multiple levels of tabbing
| at the OS level and the application level other than
| simplicity. Often when you want to perform a group operation
| the app is an already defined group for that operation, and in
| addition it often makes more sense to page through application
| tabs and windows separately rather than as a singular
| operation. For example going one window to the left for your
| editor while leaving the existing firefox tab focused rather
| than having to hit a different shortcut to jump up a level.
|
| I think it would be interesting if you could have like
| application windows automatically vertically tabbed like
| Firefox's tree style tabs and have a contextual option to
| either break out to a new tree or open a different applications
| link as a child tab of the tree.
|
| One could then optionally switch between showing trees side by
| side/top bottom or joining them into a horizontal tab group.
|
| Ideally operations performed on multiple tabs could be
| performed by hitting a singular hotkey or button that would
| present all relevant options without going into each apps menu
| or pressing a different key or ui per app.
|
| This would however be both complicated and require coordination
| between players that would likely be impossible.
| mssdvd wrote:
| On a side note, Emacs has been recently ported to Haiku.
| bluepoint wrote:
| you mean with gui? It was ported as a terminal application a
| while ago.
| mssdvd wrote:
| Yes, I do. It was merged to master a month ago.
| e3bc54b2 wrote:
| Which is a great boon for both Haiku and my old netbook. 9/10
| times I'm using terminal, browser and Emacs anyway, and Haiku
| is stupid fast. Now if only wireless support was bit better...
| mysterydip wrote:
| Good to see all the progress on Haiku. This might be a solution
| for a "modern windows 2000" from the discussion the other day.
___________________________________________________________________
(page generated 2022-01-01 23:02 UTC)