[HN Gopher] HaikuOS running on RISC-V hardware (HiFive Unmatched)
___________________________________________________________________
HaikuOS running on RISC-V hardware (HiFive Unmatched)
Author : iamnotarobotman
Score : 293 points
Date : 2021-07-17 18:57 UTC (1 days ago)
(HTM) web link (discuss.haiku-os.org)
(TXT) w3m dump (discuss.haiku-os.org)
| edvinbesic wrote:
| Are there any Pi/Nuc style boards one could get to run this on?
| I'm an old BeOS user and would love to have a little device to
| play with for nostalgia.
| grepfru_it wrote:
| I ran Haiku on my Nuc for awhile. It is starting to show its
| age, i.e. doesn't support locking your desktop, no multiuser
| support etc. As an also old BeOS user, it's purely nostalgia at
| this point
| qwerty456127 wrote:
| This is awesome but this is a rather strategic move. Hopefully
| RISC-V boards will emerge and this will become practical. Today,
| however, a RaspberryPI port could make more sense.
| yjftsjthsd-h wrote:
| It is strange to me that the RISC-V leapfrogged past the Pi
| port (per https://www.haiku-os.org/guides/building/port_status
| the ARM, including the Pi, _exists_ but isn 't very useful
| yet); I wonder why it made progress so fast even with poor
| hardware availability.
| rcarmo wrote:
| The Haiku community was quite resistant to the idea of
| supporting the Pi, a resistance which was only partly
| technical in nature.
|
| These days I would say it is essentially a matter of focus.
| Considering that the Pi 4 is a tiny little beast hardware-
| wise (certainly good enough to run as a light desktop, which
| is what I use it for), Haiku would be amazing on it, but I
| just don't see it happening (if it was meant to be, it would
| have come about by now).
| [deleted]
| gogopuppygogo wrote:
| Price and availability is my guess. I still have no idea how
| a $35 SoC like the Pi is profitable.
| dexterhaslem wrote:
| they're in bed w broadcom. also think of all the additional
| bite people end up buying to run em
| qwerty456127 wrote:
| Perhaps. But this means Broadcom propagates itself the
| adorably right way, beneficial to everybody. Also note
| "all the additional bite people end up buying" is mostly
| made by other parties, often small indy businesses. E.g.
| I have bought a 3D-printed chassis suiting my needs from
| a local vendor (and they also offer the source model and
| customization on demand).
| qwerty456127 wrote:
| This can hardly be an obstacle in porting the OS. The board
| is here, pretty polished, feature-rich, easily affordable
| and available.
|
| Obviously the HaikuOS developers have just found RISC-V
| easier and having more potential. Or somebody just has
| sponsored the effort.
| liberalbias998 wrote:
| It looks like it has almost leap=frogged past the PC port as
| well. (A cheap shot but it does not yet boot on my PC and I
| wish it did.) I have bought dedicated hardware to run
| interesting systems before; but feel like I am over that; low
| volume systems are expensive and stock PCs are cheaper and
| faster. I can see the attraction of RISC-V though, hope it
| takes off.
| bebop wrote:
| I think there are several reasons and my understanding is
| probably mostly wrong. First, the original port was using
| Uboot and then the focused shifted to uefi. Around the same
| time efforts shifted from a port to raspberry pi to use fdt
| and support for arbitrary boards. This should give a more
| flexible solution with the downside being less focused
| development.
|
| The risc-v port probably benefited from the work stated above
| and stayed focused on a particular board.
| Hello71 wrote:
| as far as i can tell, the whole point of haikuos at this
| point is "fun". as pointed out e.g. at https://en.wikipedia.o
| rg/wiki/Haiku_(operating_system)#Criti..., haiku will never
| be a "mainstream" os. it seems plausible to me that riscv
| enablement is more "fun" than figuring out how to mangle
| crappy proprietary drivers enough to barely run.
| [deleted]
| johndoe0815 wrote:
| This is an amazingly fast progress, can't wait to try it on my
| Unmatched board... and the port is more or less still the work of
| one or two persons IIRC.
| blt wrote:
| Tangentially, had anyone tried the HiFive Unmatched for
| numpy/matplotlib/browser type workloads on Linux?
| drmpeg wrote:
| There are no ports of Firefox or Chrome for RISC-V. I believe
| the JavaScript engine is the problem.
| blt wrote:
| Thanks. I'm kind of surprised that Firefox doesn't have the
| ability to compile with a pure C/C++ platform-independent
| javascript interpreter for odd architectures.
| classichasclass wrote:
| It does, actually: the POWER9 Raptor Talos II I'm typing
| this on uses the C++ interpreter entirely right now. (We're
| working on a JIT:
| https://www.talospace.com/2021/07/firefox-90-on-power-and-
| ji... ) I don't see any reason you couldn't build Firefox
| on a RISC-V system.
|
| EDIT: Actually, there is a reason, but it's not JavaScript.
| Firefox needs stubs written for XPCOM to map the ABI for
| XPConnect calls. Once this is done, it should "just work;"
| it's not difficult (I rewrote them for ppc64 myself).
| spijdar wrote:
| > Once this is done, it should "just work;"
|
| Unless it doesn't _cough_ ppc32 _cough_
|
| Nowadays you have to contend with Rust, LLVM, Skia, and
| the other porting headaches...
|
| There are XPCOM stubs for a lot of platforms in Mozilla.
| Mostly bitrotted, but even if they're fully restored, I
| just don't think Firefox is that portable anymore.
|
| Although apparently there's a RHEL package for Firefox on
| s390 that worked fairly recently, so I dunno.
|
| EDIT: Using Debian as an example, the latest version is
| available on x86{_64}, ARM{64}, mips64, and ppc64le. And
| s390x. ppc64 is in debports.
|
| 32 bit MIPS is lagging behind a few versions, no idea if
| it just hasn't been rebuilt or there's a new blocker.
| sparc64 is stuck on 62, it probably can be patched up but
| judging by some bug reports is sort of similar to
| ppc64{le} in needing some TLC, and I doubt anyone is
| really using it. hppa/m68k are stuck on 52/50, left
| behind with the move to Rust I'd assume.
|
| All I'm saying is in practice I'd expect porting firefox
| to a new platform to be a pretty involved effort. Even if
| you have LLVM and Rust support, there's a lot of moving
| parts inside, and it's not like the old days where most
| of the platform specific bits were inside NSPR.
| chrsw wrote:
| Nice progress. I'm already daydreaming about running HaikuOS on
| something like a RISC-V based MNT Reform.
| Htoioinan wrote:
| up
| eric__cartman wrote:
| It's always nice to see the wonderful advancements the HaikuOS
| devs make. As an operating system it's very nice and fun to use.
| It gives me the same vibes as old workstations from the 90s.
| Although it still has a bit longer to go before it could be
| considered as a daily driver for any useful assortment of
| applications.
| andi999 wrote:
| I am very pessimistic. I think it would need a strong usp or
| some killer app. Maybe going into hard real time direction
| might allow it to live in a niche in audio and machine
| operation console. But currently I don't see a path.
| ozfive wrote:
| This was the same argument for BeOS back in the day.
| techrat wrote:
| Realtime audio on hardware that isn't sold by Apple would be
| quite a killer reason to use Haiku. Especially seeing Apple
| is progressively abandoning the Pro, configurable market
| again.
| gjsman-1000 wrote:
| They released a Mac Pro, as configurable as you could
| desire, less than two years ago and have a replacement
| already in the works. They aren't abandoning the market.
| samatman wrote:
| I agree with that for what it's worth.
|
| People who aren't in the industry don't really realize
| that the Mac Mini is the entry-level into audio
| production for most people (iMac is the same for video).
| It has just enough to get started, and when you're making
| the big bucks the Mac Pro is in fact affordable for what
| you get.
|
| Developers only see MacBooks for so long that they forget
| the rest of the product line exists, yet it's there for a
| reason.
| jbluepolarbear wrote:
| What profession is the Mac Pro targeted? They used to be
| great for video production and 3D modeling, animation,
| and light baking, but the current version just isn't good
| enough and I'm seeing more and more professionals opt for
| a pc with a big dedicated gpu.
| michaelmrose wrote:
| It starts at 6000 and has similar specs to $2600 dell or
| alternatively a $1500 machine you could build.
|
| Just going from the dinky 256GB SSD your 6000 machine
| comes with to a more reasonable 2TB actually takes you to
| 6800.
|
| Furthermore for this very substantial price you are
| buying a machine on an arch they are in the process of
| abandoning a bigger issue than the price.
|
| To recap in 2013 the trash can came out. It was I guess
| OK but by 2015 its specs were noncompetitive. Between
| 2015-most of 2019 there was no real great answer for a
| mac tower. At the cusp of 2020 the new tower emerged
| followed 1 year later by the announcement that everything
| is moving to arm sooner or later.
|
| Out of the last 8 years there has been one year in which
| it was a great year to get a mac tower and only if you
| are rich.
| bboygravity wrote:
| Yes. But you get properly working real-time audio out of
| the box with the Mac Pro that you don't get with any PC
| system.
|
| Assuming that this is true (which it is based off of the
| other comments) then that is EASILY worth the extra 4000
| or even 10.000 USD to someone who needs real-time audio
| to do their recording or other audio creation job.
|
| When I became a professional (in another field than
| audio/music) I developed 0 tolerance for tech that didn't
| work or that has me fiddle around with it for hours to
| work. It financially just doesn't make any sense to spend
| your time on that. It also doesn't make any sense from a
| mental health and free-time point of view.
|
| I think that was the point (even though I'm not
| knowledgeable on the subject, other than having spent
| many day of my hobby-life trying to get Cubase to record
| with audio monitor (VST) without jittery latency on
| Windows and utterly failed).
| skavi wrote:
| realtime audio and good color management are two things a
| lot of people use macOS for..
| diskzero wrote:
| Our final pivot at Be was HARP, the Home Audio Reference
| Platform, which we thought would be a killer reason to use
| BeOS. It was not a success.
| squarefoot wrote:
| I would definitely consider Haiku for music if it had the
| same low latency capabilities as BeOS, but latency aside, a
| lot changed since the BeOS era: today pretty much all non
| consumer audio interfaces are external, therefore driver
| support for them is needed as well. Also it's not uncommon
| to see hybrid systems in which Linux runs a DAW and its
| plugins under WINE. It's a mess to configure and breaks
| very easily (lesson learned: don't do that in your
| tinkering machine that you upgrade often or install/compile
| different kernels etc. use a separate machine for
| Linux+music), so a WINE port would be useful as well, but I
| guess it'd be a huge job.
| kitsunesoba wrote:
| If I'm not mistaken it already has a bit of an audience as a
| replacement for old BeOS boxes in radio broadcasting.
| themodelplumber wrote:
| The Channel Caster 16, probably the most capable Haiku OS
| commercial system available at present. Yours for only
| $3199.
|
| http://www.tunetrackersystems.com/command-center-system-
| pack...
| bboygravity wrote:
| Wow, how cool is that. It seems rather ballsy of them to
| go for HaikuOS. Is it because of BeOS legacy software
| they had developed?
|
| They have another system at the bottom of the page for a
| mere 1600 USD.
| tialaramex wrote:
| Yes, this product historically was a BeOS product, and
| eventually it became cheaper to put together a version of
| Haiku with no show stopping bugs for their customers on
| hardware you can actually buy than to try to find
| hardware that would still run an obscure 1990s operating
| system.
|
| The very first versions of this product are essentially
| BeOS, plus an existing MP3-player type application, plus
| a little bit of software glue, the right off-the-shelf
| hardware and the know-how to use it for radio broadcast.
|
| It's definitely one of those products some HN regulars
| would dismiss as "I could basically make that in an
| hour". Me too. But, after an hour nobody else can
| maintain it and it doesn't work on anybody else's
| computer. The hard work is in turning that into a product
| that generates some net revenue, which is mostly non-
| technical work.
| brirec wrote:
| > probably the most capable Haiku OS commercial system
|
| Not knocking this Caster, but it might also be the ONLY
| Haiku OS commercial system
| nyanpasu64 wrote:
| I've heard that Haiku's audio APIs are similar to those of
| BeOS, which are harder to use than today's APIs. I hope they
| can be improved though, if Haiku is a better foundation for
| real-time media than standard Linux (or even realtime).
| tialaramex wrote:
| The BeOS Media APIs enshrine a strange way to think about
| multimedia latency, which is _maybe_ useful if your central
| idea is that you need to synchronise audio and video
| through different production pipelines, but doesn 't serve
| real time audio work at all.
|
| I believe Haiku did eventually fix some of the most
| egregious mistakes in their audio handling for example for
| years if you played silence it made everything else
| quieter, which is a classic goof+. But it's a long way from
| ideal for this application. You can of course use
| _anything_ , if your hobby is making music with Haiku,
| knock yourself out, same with a ZX Spectrum or a toy
| xylophone, but yeah, not ideal.
|
| + How do I mix samples for N channels together? Adding them
| together and dividing by N ought to work right? No.
| smallstepforman wrote:
| The Haiku MediaKit API was available 5 years before
| Fabrice Bellard published ffmpeg, and back in the early
| 90's BeInc's goal was to attract the next successor to
| the NewTek toaster, and to be the next real time audio
| mixer. This is why they emphasised chaining of media
| nodes and sorting our "performance time" synchronisation
| issues with their API. The famous BeOS marketing video
| demos such a device.
|
| BeOS kernel allows unique app access to a shared memory
| area, eliminating memory copies when sharing data. When
| creating the shared area, media apps can set several
| media access flags to engage the "fast path" if the
| devices have that buffer. These days modern graphics
| API's (eg. Vulkan) offer the same buffer creation hints
| to help the driver figure out where to best allocate
| memory (device local, host accessible etc). Because not
| all memory is equal.
|
| I've used both ffmpeg API and BMediaKit (I'm the author
| of a Haiku native video editor,
| https://github.com/smallstepforman/Medo). The BMediaKit
| API is trivially easy to use. ffmpeg is notoriously
| convoluted. Likewise, the native GUI API is also a
| pleasure to use. This is why my open source media editor
| is Haiku native (and not cross platform).
| grepfru_it wrote:
| Hey! Thanks for your contributions to the BeOS Ecosystem.
| The OS wouldn't be the same without it!
| viraptor wrote:
| Since Pipewire, the Linux view on audio is changing a lot.
| The latencies are not what they used to be. Even if Haiku
| becomes more usable, it's unlikely to achieve a massive
| difference.
| zozbot234 wrote:
| Does the PREEMPT_RT patchset matter wrt. audio latencies
| in Linux? That seems to be the biggest effort wrt. "low
| latency" workloads at least on the kernel side.
| viraptor wrote:
| It does for latency and reliability, but in my experience
| running the xanmod kernel with just preempt without rt
| provides low enough (sub-5ms) latency that I stopped
| caring about RT in my home recording use.
| snvzz wrote:
| 5ms is an eternity, and without PREEMPT_RT I get xruns at
| 5ms on jack, which is (still) far better than pipewire on
| the same hardware.
|
| Even with PREEMPT_RT, I can't even run 2ms pipelines
| without xruns.
|
| I don't think this is within the realm of fixable. Linux
| simply isn't a good design for this. Kernel too large and
| unpredictable. Who knows when or if execution will return
| to userspace.
| tialaramex wrote:
| People are weird about this. Because audio is ultimately
| a vibration moving through the air, _latency_ is
| equivalent to _distance_ because sound can only travel a
| few hundred metres per second.
|
| So, 5ms is _less than two metres_. When COVID-19 forced
| you to stand a little further away from people, did you
| find it added "an eternity" of latency to everything?
| No? You barely noticed? Right.
|
| One exercise that's interesting is you can build a
| physical loop (e.g. speaker plus microphone) and play
| with how long it takes samples to leave your software,
| turn into audio, then re-enter and come back to your
| software. You might find that to your disappointment a
| software stack may be giving you just 256 samples of
| latency but your _hardware_ adds say 8 milliseconds on
| top of that.
|
| This approach also helps you ensure you're doing apples
| to apples comparisons.
| LoveLeadAcid wrote:
| Audio latency is only measured in the air once it leaves
| a transducer. You're comparing apples to oranges here and
| deliberately misunderstanding the issue.
| snvzz wrote:
| Latency is the whole chain. That's Linux's latency, on
| top of everything else that could be there, such as
| however many meters of distance between speakers and
| listener in a live performance.
|
| In no way is it acceptable for Linux to add 5ms to the
| chain.
| viraptor wrote:
| It depends on the use case, I'm quite happy with 5ms :-)
|
| Ftr, on Pipewire on a Dell xps with iRig2, I'm getting
| 4.6ms reported with just PREEMPT. An xrun every few
| minutes if I try to go to ~2ms. I suspect I could get
| that working reliably with RT.
| 0des wrote:
| Conversely, in my own experience, Pipewire removed
| everything I held dear, destroyed my will to compute, and
| has somehow crippled my systems for the purposes of
| multitasking with any type of media playing.
|
| Hyperbole aside, I'm glad someone was looking at the
| audio situation, but this one seemed to knock me out of
| the game on every machine that received it. Examples of
| common scenarios for me: I can't have firefox open and
| virtualbox at the same time, or bitwig and firefox, or
| visual studio and audacious. Common pairs of apps cause a
| bitrate mismatch for whatever reason, and everything
| sounds like a heavily bitcrushed and ring modulated
| signal.
|
| The exception to this are machines that were installed
| with pipewire, rather than upgraded to pipewire. Also,
| using Cadence, a router type app helps, but
| inconsistently.
| viraptor wrote:
| Do you mean sample rate? This may help https://gitlab.fre
| edesktop.org/pipewire/pipewire/-/wikis/Con...
|
| Otherwise, have you raised the issue at
| https://gitlab.freedesktop.org/pipewire/pipewire/-/issues
| ? They're pretty responsive.
| agildehaus wrote:
| Why does everything need commercial success?
|
| It's survived for 20 years despite having none. It will
| continue as long as there are interested developers.
| qwerty456127 wrote:
| There isn't much needed to make an OS usable as a daily driver
| today. Just port Firefox.
| tempodox wrote:
| On a sarcastic note, I'd agree. But not in all seriousness :)
| qwerty456127 wrote:
| Why not serious in this case? A full-featured browser makes
| is the most important thing to make an OS usable today,
| isn't it? Of course I assume all the basic stuff like file
| system and device drivers, relevant multimedia codecs, bash
| or a likely-featured shell, SSH, basic GNU/BSD/alike
| command-line tools are already there. And that things like
| LibreOffice, ImageMagick, LaTeX, GnuPlot, Inkscape, VLC,
| runtimes like CPython and OpenJDK are next in the queue.
| But what is the most important thing which makes an OS
| usable today? For me it seems obvious it's the browser. If
| only there was a browser supporting all the today standards
| (including the H264 and AAC codecs support) I would already
| be able to do everything I need in it, the rest mentioned
| (after "And that things like") would just make my life
| slightly more convenient and fun.
| rhdxmr wrote:
| I am not a fan of HaikuOS. But I hope this OS evolves and be
| loved by plenty of users. I like diversity of open source
| projects like this.
| unixhero wrote:
| What's not to like?
| yjftsjthsd-h wrote:
| Personally, I found it painfully mouse-heavy (ditto Plan 9);
| on *nix, I can use i3+tmux+vimium+keynav and basically never
| touch the mouse. This matters particularly on laptops where
| the keyboard is good and the mouse, such as it is, sucks.
| AnIdiotOnTheNet wrote:
| Can't answer for parent, but my personal biggest gripes are:
|
| 1) No graphical acceleration yet
|
| 2) No application sandboxing mechanism (yet?)
|
| 3) A package manager that doesn't seem to have a reason to
| exist.
|
| To expand on 3: Native Haiku software really has no need for
| a package manager because it has no need for dependency
| management. It appears the only real reason to have it is so
| Qt can be installed as a dependency for the ports that need
| it. Why not just provide Qt in the base system? According to
| the developer I talked to, its because they want to encourage
| people to write against the native API. Ok, so why support
| this use case at all? Because ported software is better than
| no software. Either I am still misunderstanding something or
| this is an incredibly strange decision.
|
| Which isn't to say I don't like Haiku, indeed it understand
| Desktop as a usecase far better than any Linux distro that
| ever existed, I just have those particular gripes.
|
| As far as reasons others might not like it:
|
| 1) I hear that porting some POSIX software is a bit jank
|
| 2) There are no user accounts
|
| 3) Hardware support
| smallstepforman wrote:
| As always, AnIdiotOnTheNet has valid comments, but you
| cannot dismiss a journey because its too far, you need to
| start with the first steps and eventually you'll get there.
|
| 1) re: graphical acceleration, it will come when the user
| base increases, the 3 big players will eventually want skin
| in the game
|
| 2) re: sandbox mechanism, yes it's missing, however since
| Haiku has a read only package system, the damage a rogue
| app can cause is much smaller eliminating the need for
| sandboxing in the first place. Also, the Haiku system is
| easy to restore, and from a user point of view, I care more
| about preserving my data, not protecting a system that I
| can easily restore. This is also a fault of most OS's out
| there, they protect you from installing a driver, and do
| nothing for protecting your family photos.
|
| 3) see 2
|
| 1) re: posix, Haiku has similiar issues as the BSD's in
| that POSIX != Linux
|
| 2) it's coming in R2
|
| 3) see original 1
| amichail wrote:
| BTW, TeXmacs runs on HaikuOS:
| https://twitter.com/maxgubi/status/1235518013492740096
| fithisux wrote:
| I really like their approach.
| hankman86 wrote:
| Other than BeOS nostalgia: is there any good reason to prefer
| Haiku over [name any modern Linux distribution]? I can see that
| it's fun to hack on an OS and make it your own. But is Haiku
| actually known to do anything particularly well that other
| operating systems struggle with?
| smallstepforman wrote:
| At its core, Linux offers variety, while Haiku strives to be a
| unified system. There is only one official UI, one sound API,
| one filesystem, one preference system, etc. making Haiku easier
| to administer. The system kits are designed to work together.
|
| For instance, I created a from scratch video editor for Haiku
| which does 4K UHD videos with OpenGL based plugins, with over
| 30 effects, and 10 languages. The installer package with no
| dependancies is 1.3Mb (fits on a floppy disk).
| https://github.com/smallstepforman/Medo Under Linux, I would
| require many more dependancies since I have no guarantee what
| libraries or API's the users have installed.
| squarefoot wrote:
| > Under Linux, I would require many more dependancies since I
| have no guarantee what libraries or API's the users have
| installed.
|
| That is an unfortunate, probably unavoidable, byproduct of
| the freedom that brought Linux on so many computers,
| platforms and users. Everyone can write a software, or fork
| an existing one, nobody enforces a standard for development
| or integration. I guess it's not easy to build a giant free
| community around a free software and keep consistency. It's a
| mess, and has been a necessary one when the aim was to spread
| Linux as much as possible, but now we're paying the
| consequences. (Which is why I believe the day Microsoft will
| reveal their Linux distro, bringing stability and unification
| behind a known brand, is the day all non technical die-hard
| users and more importantly most commercial entities that use
| Linux will abandon the usual distributions, essentially
| killing them.) Haiku however was born as a clone of a closed
| system, and only recently is seeing some media coverage;
| there's no guarantee that, should it one day reach Linux'
| level of popularity, the influx of developers , users, and
| demand for more software, won't create the same issues there
| as well.
| marcodiego wrote:
| > That is an unfortunate, probably unavoidable, byproduct
| of the freedom that brought Linux on so many computers,
| platforms and users.
|
| People love to bash linux for this and they are right. The
| single feature that makes linux historically suck on the
| desktop is the one reason it succeeded everywhere else.
| soapdog wrote:
| I prefer Haiku over any Linux distro. For me it is the tight UX
| and GUI that makes it a very good desktop. I'd rather have more
| native developed software instead of ports but I understand why
| ports are crucial.
| rvz wrote:
| > is there any good reason to prefer Haiku over [name any
| modern Linux distribution]?
|
| That's the problem. There are too many Linux distributions to
| _' support'_. From a developer standpoint. I have to _' define
| Linux support'_ and need to draw the line somewhere and pick a
| Linux distro and write a guide for it.
|
| Several people will ask if their distro is also supported and
| another one will ask, followed by another one with the same
| question and then you would be updating more than 10
| troubleshooting guides and maintaining more than 10 CIs for
| 'official' support. That's very expensive and this is why you
| cannot target _' all'_ Linux users.
|
| On the other hand, I can support all Windows users 100% of the
| time. Same thing with macOS, and Haiku also has little to no
| fragmentation and that means I can give 1 CI per OS. Not 10 or
| 20. Even Redox gets it right with the same idea.
|
| It's nice to see an open-source OS for once that has a sane
| desktop, usable software and is unified just like Windows and
| macOS.
| rkido wrote:
| That's just because no one actually uses HaikuOS or RedoxOS
| (no offense to these wonderful projects of course). If these
| came even remotely close to the popularity of Linux, you'd
| have remixes, spin-offs, and eventually full-blown
| distributions.
|
| You can try to prevent it with project structure, but even
| something really unified like FreeBSD ended up having
| derivatives like GhostBSD as well as full-blown divergent
| forks like DragonFly BSD that are not necessarily compatible
| anymore with upstream.
| rvz wrote:
| Fuchsia is based on the same idea and has support to just
| one OS. The BSDs are not even a good example of _'
| something really unified'_ from the start anyway.
|
| The actual reason for all of this is that the distro's
| themselves (and the BSDs) bundle 'hundreds' of external
| third-party system packages as first party just to get a _'
| basic desktop working'_. I don't want to start pointing
| fingers at where a bug could be located at as it would be
| very painful to maintain and start searching through the
| whole Linux or BSD desktop stack. Good luck with that.
|
| The only difference with the BSDs is that they just have a
| different kernel. Everything else has the exact same
| software stack just like many Linux distros.
|
| Hence this, with having little to no OS fragmentation, it
| is also the reason why everyone only targets Mac and
| Windows. _' Official support'_ gets very expensive when 10
| or 20 distros need to be tested on a CI or guides need to
| be updated as users tweak or mess around with their Linux
| distro.
| asveikau wrote:
| > The only difference with the BSDs is that they just
| have a different kernel. Everything else has the exact
| same software stack just like many Linux distros.
|
| This is true once you install a bunch of desktop stuff
| from ports and packages, however, any of the *BSDs are
| much more cohesive than Linux in the base system.
|
| And I guess even the degree of desktop integration
| varies. On OpenBSD X11 is part of the standard
| installation. On FreeBSD it comes from ports.
| unixhero wrote:
| As a tinkerer I would love to run HaikuOS for the fun of it.
| BeOS gives a really enjoyable user experience and the things we
| can achieve make them more than good enough for me.
|
| This is not a workload os, or a workspace os, its a having fun
| os.
| snvzz wrote:
| BeOS was a good desktop, and Haiku reproduces it well,
| providing a high quality desktop experience.
|
| Meantime, the usual Linux desktops continue to fail at even the
| basics, such as low quality file dialogs that e.g. change your
| selection after you've already clicked.
|
| Other than that, BeOS system kits are elegant, so are its APIs
| for drivers and filesystems. Linux does instead have a huge,
| ugly, syscall interface.
|
| It just takes enough perspective to not see UNIX and its clones
| as the "end it all" of what an operating system should be, and
| then you'd realize it's actually pretty hard to come up with
| anything that Linux does better.
| hestefisk wrote:
| Has anyone here managed to get their hands on the HiFive? It
| looks really cool. Would love one of these devices as my daily
| driver.
| drmpeg wrote:
| I have one. They shipped back in the beginning of June. They're
| in stock at both Mouser and Crowd Supply.
|
| https://mouser.com/ProductDetail/SiFive/HF105-000?qs=zW32dvE...
|
| https://www.crowdsupply.com/sifive/hifive-unmatched
| hestefisk wrote:
| Thanks. Quite costly but might be worth it. What OS do you
| run on it?
| drmpeg wrote:
| I'm running Ubuntu 21.04. As for using it as a daily
| driver, you might be disappointed with the performance.
| It's slower than a Raspberry Pi 4. Also, no Firefox or
| Chrome browsers (yet). You have to use Epiphany.
|
| It's really targeted as a development platform and that's
| how I'm using it. I just SSH to it from my x86 box.
| brucehoult wrote:
| Yup, the CPUs are around half the speed of those in a
| Pi4, and around the same or a bit better than a Pi3. The
| RAM is much bigger and better than a Pi3 (16 GB of DDR4),
| and also bigger than the biggest Pi4. You can run a real
| GPU in the PCIe slot and a fast SSD in the M.2, so things
| that use a lot of I/O rather than CPU tend to be pretty
| snappy. The gig Ethernet also works well. So does
| ethernet on the Pi4, but Pi3 is a bit lacking.
|
| RISC-V CPU cores equivalent to the Pi4 were announced
| around 1.75 years ago and the way these things go are
| probably getting to the stage of working test chips right
| about now, and boards in the first half of next year.
|
| Obviously the price is much higher than a Pi, bit it's
| not out of line with x86 PCs (just a low slower). If
| you're actually working professionally on RISC-V software
| then the HiFive Unmatched is affordable, and enough more
| productive than the current alternatives to be worth it.
|
| Later in the year, the BeagleBoard BeagleV "StarLight"
| will have the same CPU specs as the HiFive Unmatched for
| $120 (4 GB RAM) to $150 (8 Gb RAM). That's still above Pi
| prices, but much closer. It will have I/O closer to Pi
| specs than PC specs.
|
| RISC-V is still in its infancy, but progress is rapid.
___________________________________________________________________
(page generated 2021-07-18 23:02 UTC)