
Harvey – An effort to provide a modern, distributed, 64-bit operating system - floren
https://harvey-os.org/
======
malkia
I have more hope in projects like fuchsia, where separation of concerns is
taken seriously - there are providers for "things" and on the fly
configuration can glue several independent components to serve as one - for
example instead of "Google Maps", "Bing Maps", or "Apple Maps" \- you would
have several map data providers (maybe some with higher data quality for
specific regions), several map data viewers, several events, places, traffic,
etc. providers - and you end up with one combined view of all them, e.g. not
application but an user "story", as briefly explained here:

[https://fuchsia.googlesource.com/modular/+/master/docs/modul...](https://fuchsia.googlesource.com/modular/+/master/docs/module.md)

~~~
bastawhiz
> you would have several map data providers (maybe some with higher data
> quality for specific regions), several map data viewers, several events,
> places, traffic, etc. providers - and you end up with one combined view of
> all them

I think the doc you linked to doesn't support your idea; it sounds much more
like the replacement for activities and intents in Android than what you
described. The service providers have no incentive to supply data independent
of a full experience (why would Bing let you show maps in your app without
agreeing to a ToS? what if the map provider has different streets than the
traffic provider?), the app developers have no incentive to do this (if one
phone might display Bing maps and another Google in my app, how does that make
my life easier?), and the user probably doesn't want this (why am I seeing
grainy black and white satellite imagery in one area and high fidelity color
imagery in another?).

Think of the headache gluing all that data together. Every map viewer would
need to support the data format for every map provider. Every traffic service
would need to expose a protocol for querying traffic data on a stretch of
road, and you pray that they mostly work the same and know which streets are
which. You hope that every point-of-interest provider exposes the same set of
fields and level of detail you need to make them useful. And that doesn't
begin to touch on the intersection of rendering things well and the data
needed to make that work (which streets to show at each zoom level,
arrangement of points of interest, knowing which streets are important enough
to show traffic for, special cases like when freeways are closed...).

~~~
nine_k
There's a difference between the systems where this is difficult, and systems
where this is outright impossible.

On gluing things together: look at your nearest npm-based software project. It
may not be very pretty, but it works in a reasonable way.

~~~
SahAssar
NPM does not make it any easier to glue stuff together, we have had packaging
for decades. Just because you can pull in a package does not make it easy to
work with the api in a standardized way.

~~~
foota
Their point was that npm doesn't make it any easier but it's possible.

~~~
SahAssar
Please explain to me how npm makes it possible.

~~~
Chickenosaurus
I think the argument is Node.js projects are often stitched together from many
packages with different APIs and are therefore a good example for stitched
together programs that work.

The argument isn't very good in my opinion. Combining independent services
differs from combining libraries.

------
a1k0n
The landing page doesn't really explain what is interesting about Harvey. What
does it mean that it's distributed, exactly?

~~~
floren
I wish the mods hadn't changed the title; I chose the original title to focus
more on what's cool about it.

Anyway, Harvey is distributed in the same way that Plan 9 is/was distributed:
the services are meant to be run across a network. On a properly set up
network, you'll have an authentication server which does only authentication,
because that's the keys to the kingdom. Similarly, you'll have a file server
which ONLY serves files, and speaks to the auth server to manage access. Then
you'll have a CPU server which lets remote users connect and do stuff; it
mounts its root filesystem from the file server and authenticates users with
the auth server. You can also have terminal machines, which typically netboot,
get their root from the file server, authenticate with the auth server, and
basically act as a personal workstation for whoever sits down; when you're
done working, just save your work and reboot the terminal.

Of course it doesn't have to be run like that and many people don't, because
they don't want to run 4+ systems. You can combine auth, FS, and CPU services
onto one machine and just connect from a Windows, Linux, or Mac machine using
'drawterm' (think of it as an ssh equivalent).

~~~
euyyn
Honest question, not trying to be dismissive: This architecture sounds old to
me, as in things were built like that in the 80s or earlier but evolved past.
Is that so? If so, what makes those decisions newly relevant?

~~~
floren
The architecture does indeed come from the late 80s/early 90s, but I think
it's more relevant today than ever. Separation of services is, in my opinion,
essential to security. By putting the authentication service off in its own
machine, you restrict the attacks that can be made on it; the auth server only
talks over a highly restricted protocol. On a standalone Unix system, users
log in to the same machine that stores the passwords. They're only a privilege
escalation exploit away from getting the hashes of everyone's password, and
these days privilege escalations are a dime a dozen.

When this scheme was designed, it was frankly a little bit nutty. The CPU,
auth, and file servers would be VAX or Sun systems, costing tens of thousands
of dollars, and the terminals would be either slightly cheaper Suns or IBM PC-
compatibles costing thousands of dollars themselves. Today, you could probably
cobble together a passable network for a few hundred dollars, assuming you use
cheap Atom boards for everything except the CPU server (which is meant to be a
beefy compute box, but let's be honest nothing in Plan 9 uses a lot of
cycles). This makes the architecture more sensible than ever.

~~~
cjhanks
It seems a bit older than that. Much of the design goals for Harvey were in
the early MULTICS systems of the 70's. In some ways I view Plan9 as Bell Labs
attempt to bridge the great components of MULTICS and UNIX together.

~~~
thisrod
The way I see that history, Multics was the second system that never shipped,
and Plan 9 was the fourth system that belatedly did ship Multics.

~~~
cjhanks
I don't mean to be argumentative. MULTICS was in use by Honeywell Aerospace
into the early 90's simulating physics models.

There was a centralized computer which was programmed via punch cards which
you could dial into to submit your specific simulation and later return to for
results.

~~~
thisrod
Good point. Multics was used just as much, or little, as Plan 9 was. We might
wish our predecessors had made the jump to distributed, securable operating
systems, but there was never a time at which it made sense to do so.

------
floren
Anyone who's wanted to play with Plan 9 should consider giving Harvey a look.
Getting started is a pretty easy process: you download the repo on your Linux
box (I believe it works on MacOS too), run a script to get the environment set
up, run a build command. Once everything's built (about 2 minutes on a decent
machine), run another script which boots Harvey in a QEMU VM. The VM will get
its root filesystem from the Linux box, so you can easily experiment, make
changes, test.

Harvey comes with pretty much everything you'd find on Plan 9. It also
supports Go, and there's a (work in progress, but functional) POSIX layer
which you can use to cross-compile POSIX programs.

~~~
drb91
It _does_ require a case-sensitive file system, so it takes some additional
effort to cross compile from the mac.

Not that that's unusual :)

------
ElijahLynn
"Harvey is a distributed operating system. It is direct descendant of Plan 9
from Bell Labs which was originally developed by the same group at Bell Labs
that invented Unix and C."

[https://github.com/Harvey-OS/harvey](https://github.com/Harvey-OS/harvey)

------
dsp1234
Note that Plan 9 is already licensed under GPLv2 (with caveats I guess)[0][1]

[0] -
[https://news.ycombinator.com/item?id=7232042](https://news.ycombinator.com/item?id=7232042)

[1] -
[http://akaros.cs.berkeley.edu/files/Plan9License](http://akaros.cs.berkeley.edu/files/Plan9License)

~~~
floren
Ah, yeah, Harvey is based on that release, it's just had significant changes
made to the build system and the code itself. They're running continuous
integration and code quality checkers. The code now builds with GCC and Clang
and it builds pretty damn fast. It's a cool project and the people running it
are really friendly.

~~~
baq
thanks for that, was looking for a good reason why it's still C.

------
Animats
It's in C, offers POSIX, and apparently a big-kernel OS. Looks like another
Unix-type OS. Why?

An OS in Rust would be a step forward. An OS like QNX would be a step forward.
An OS like QNX in Rust would be just what the IoT world needs. But another
UNIX/Linux clone? Why?

~~~
Sir_Cmpwn
This is a plan9 descendant.

~~~
pjmlp
The actual end of line for Plan 9, was Inferno using Limbo as the userspace
language, but many seem to keep forgetting about it.

Harvey would be cool if they would continue Inferno, but with Go instead of
Limbo.

As it is, it isn't that much interesting from OS architecture point of view.

------
xj9
i take a lot of inspiration from plan 9, but a lot of the distributed
computing architecture that it is built around is severely outdated and based
on a lot of untrue assumptions. for example, you _can 't really_ expect to
have always-on, low latency internet access. especially if you get anywhere
near a mobile context. without good networking plan 9 falls on its ass. so you
have to consider, how do you implement the _shape_ of plan 9, without
depending on the mythical "reliable network"?

i don't have an answer exactly, but i _am_ looking for one[0]. we are using
the linux kernel because hardware support and you don't _really_ need any
special kernel features to implement a plan 9-like (read the paper, they
didn't to anything special kernel-wise). i'm in the process of copying my
offline notes into our wiki, so uh stay tuned or whatever.

i'm hoping to publish a really early preview build some time next week, but
we'll see how far i get while i'm on holiday. it'll be soon in any case.

[0]: [https://www.heropunch.io/%E5%8F%8B](https://www.heropunch.io/%E5%8F%8B)

------
digitalzombie
Nice to see all these new OS coming out.

I'm personally rooting for HURD
([https://www.gnu.org/software/hurd/hurd.html](https://www.gnu.org/software/hurd/hurd.html))
and Barrelfish([http://www.barrelfish.org/](http://www.barrelfish.org/))

~~~
codepie
Obligatory XKCD for operating systems:
[https://xkcd.com/1508/](https://xkcd.com/1508/)

------
rcarmo
This runs surprisingly well as a Docker container. The awkwardness of trying
to use rio on a laptop with a (non-existent) three-button mouse is still
there, though, and I hope other Plan9-related projects are considering
bringing the GUI UX up to speed, since using a trackpad with drawterm is still
awkward...

------
qwerty456127
> It can be built with gcc and clang

Again... I understand many will argue but I also believe many will agree: we
are to start phasing out C and write modern OSes in safe languages like Rust,
Haskell, Go, Crystal etc. Because code written in C is almost guaranteed to be
vulnerable. C has done its job when the hardware was slow and low on memory,
electronic data was rarely life-important and when there were no languages and
compilers that could be used as alternatives but that time has ended and now
we are to consider different priorities.

~~~
bb88
> we are to start phasing out C and write modern OSes in safe languages.

Linus Torvolds probably has the best answer to why not.

[https://www.reddit.com/r/programming/comments/1t0gfy/linus_t...](https://www.reddit.com/r/programming/comments/1t0gfy/linus_torvalds_on_the_question_if_there_is_a/)

"When I read C, I know what the assembly language will look like."

~~~
cmrdporcupine
Except in this day and age reading the assembly language doesn't give you the
same kind of insight into how the hardware will perform as it did 15 years
ago.

~~~
minipci1321
Oh, it might still give the same insight -- for example, when people reading
assembler today are the same ones who did that 15 years ago.

~~~
bb88
Or in BSD's case, 30 or 40 years ago.

------
meddlepal
I appreciate the minimal nothing fancy website design.

------
k3a
I appreciate the effort but I have a feeling that there is not enough
developers for existing free OSes and I am not sure it is very wise to
fragment the community even more.

------
kruhft
Quickstart: [https://github.com/Harvey-OS/harvey/wiki/Getting-
Started](https://github.com/Harvey-OS/harvey/wiki/Getting-Started)

------
eximius
I wonder how this compares with Redox OS. This is Plan 9-like, which Redox
could be with its 'everything is a URI' concept, but I haven't used either to
see.

------
desireco42
We really could use something new, so I am ready to give anything new a shot.
Something completely free and open to new ways of thinking.

------
jstewartmobile
Why so many haters? Just the fact that they've got Ron Minnich[0-1] on the
team--one of the guys fighting the good fight against all of the voodoo BS in
your Intel/AMD firmware--makes it worth a look IMHO.

[0]
[https://www.youtube.com/watch?v=iffTJ1vPCSo](https://www.youtube.com/watch?v=iffTJ1vPCSo)

[1] [https://lwn.net/Articles/738649/](https://lwn.net/Articles/738649/)

