hellosystem / hello Goto Github PK

These distinctions are normally not clear to Mac users, where "the desktop" "just exists" (and WindowServer and "Quartz" somehow do the magic)...

• Display manager: What shows the login screen. Xfce uses lightdm. Since we don't want to show a login screen on a single-user personal system we may just as well want to use nodm as the display manager. This is set in /etc/X11/default-display-manager.
• Window manager: What applies theming to windows. Xfce uses xfwm4. Is it also resposible for drawing the drop shadow behind windows? Compiz is an OpenGL compositing window manager, which might be handy for smooth animation effects?

Very cool project, I like the idea!
I found out about it in this Reddit thread.

One thing that bothers me though is:
With hello mimicking the Apple Aqua desktop, couldn't there be an issue with Apple having copyright on the look and feel of the system? I'm not talking about copying actual icons - which definitely would be copyright infringement - but the style.
To give some examples:

• The three window actions in the top left corner
• The way the dock looks like and works
• The global menu

Can those parts be copied without any issues? What about gestures (e.g. trackpad as can be configured in macOS preferences -> trackpad)?

Thanks!

First of all, massive respect for the AppImage project.

Consumed a lot of your literature on Linux Usability. The freedom, without what I call structured growth has made the desktop a mess. Over the past two years, I did a lot of distro-hopping, before settling for the one I thought was the easiest to build on, (Arch Linux). Then began the endless search of the perfect desktop environment. GNOME, MATE, KDE Plasma, i3, XFCE, and what not.

I love tweaking bits and pieces more than freezing panels, weird, inconsistent design, so i3 becomes my choice, not that it was much help. And I am not talking about just GNOME environment. I am talking about GIMP and Inkscape. Open them alongside each other. The horrific visual torture that is presented is what I think you mean with messed up broken Desktop Linux.

I understand that this is a very specific scenario than what you have talked about, but this for me was the demonstration of a need for standards, which the UI developers could agree upon. I tried editing inkscape UI to look more like GIMP, took a few days break, and now I have no idea what to edit, and where to find them. I mean yeah it is a css file, but why does the attribute for the menubar have to be different. And that in my opinion is why we need more than just philosophy. More like one standard set, a guide for those developing the software.

If there could be one thing I could contribute, it would be to develop that set of design guidelines.

Make file manager package-savvy. If someone wants to delete a file that is in a package, offer to uninstall the package instead. If someone wants to move a file that is in a package, tell them that this is a bad idea or refuse to do it.

Example:

user@FreeBSD$ pkg which /usr/local/share/applications/featherpad.desktop 
/usr/local/share/applications/featherpad.desktop was installed by package featherpad-0.10.0_1

The file manager could make use of this kind of information for better drag-and-drop support for installed packages...

https://www.ubuntubuzz.com/2019/02/how-to-install-kvantum-engine-for-kde-on-ubuntu.html
might be a good basis for a designer to make a theme for hello.

sudo apt-get install g++ libx11-dev libxext-dev qtbase5-dev libqt5svg5-dev libqt5x11extras5-dev libkf5windowsystem-dev qttools5-dev-tools cmake checkinstall
unzip Downloads/Kvantum-master.zip 
cd Kvantum-master/
cd Kvantum/
mkdir build && cd build 
cmake .. 
make
sudo make install

Works. Then need to set it in qt5ct and need to gonfigure some things in Kvantum (again), e.g., "Dialog Button Layout".

But before we use it we need to understand the Gtk theming story.

If Qt cannot style Gtk apps so that they look indistinguishable, then we may need to go the other way around and make Qt look like Gtk, which is proven to be able to provide (near-?)indistinguishable results on Xubuntu.

We want as proper Command Key in the menu.

Is there a way to globally make Qt shortcuts use ⌘+... instead of Ctrl+...?

Find Qt-based system-config-printer replacement. Do you know any?

Must have: Create CUPS configuration without too much hassle, find printers using Zeroconf, support IPP Internet Printing Protocol, HPLIP etc.

Ideally automatically set up IPP printers without manual interaction (like Ubuntu and the Mac do).

Check https://www.ukui.org as the basis for desktop and file manager.
It is used in Kylin and is Qt based.

https://vermaden.wordpress.com/2020/11/18/unbound-dns-blacklist/

https://github.com/psifidotos/applet-window-appmenu

Can we hook it into a very simple standalone Qt application that does not need a Plasma desktop and ideally has no Kf5 dependencies?

sudo apt-get update
sudo apt-get -y install xfce4-appmenu-plugin

Add "AppMenu Plugin" to the panel.

This is an Application Menu (Global Menu) plugin. It is built using the Unity protocol and libraries and provides all features found in the Unity implementation.

Also check out the Unity protocol and libraries and see if we can use this in a pure Qt desktop.

Tried installing a FreeBSD desktop using the official FreeBSD DVD today and utterly failed at getting to a working graphical desktop. In the end I went with NomadBSD where it worked instantly.

Hence the question, should we use initgfx in case we decide to go with FreeBSD?

Using the following components:

• Elasticsearch the search database engine itself
• fscrawler the filesystem indexing tool

See https://wiki.samba.org/index.php/Spotlight_with_Elasticsearch_Backend for instructions. Also see https://wiki.freebsd.org/Elastic.

Then integrate it into the https://github.com/helloSystem/Menu.

tracker is not an option since it is Gnome, Xdg, D-Bus infested. Too many dependencies on unwelcome technologies.

It has Compiz and looks a lot (too much?) like Mac OS X, but I fear that it may not be lean and elegant under surface (as they are referring to Gnome 3). On the other hand,

https://sourceforge.net/projects/pearl-desktop-9/ says

PDE features many pre-configured sessions which include PDE-FX the default, PDE-XF-FX and PDE which is very lightweight.

So maybe it is worth trying out.

https://github.com/distr1/ puts together a whole Linux system using (currently: uncompressed squashfs) images.

I am wondering whether we could use it to

• Put together a Live ISO that would contain essentially a folder of images
• To "remaster" the Live ISO, we would just have to add/remove/exchange some of the images
• At installation time, just copy over that folder of squashfs images, and have a modifyable/updateable system (by putting each FreeBSD pkg into an image)
• Being able to put together .app bundles by just putting the relevant images into the bundle

This would

• Speed up Live ISO generation significantly
• Simplify Live ISO generation
• Speed up CI significantly
• Speed up package management on the installed system
• Still allow us to use something vaguely similar to AppImages/.app bundles for applications

Can it be ported to FreeBSD? (I've been interested in FreeBSD lately because it is much more of a consistent platform than the various incompatible Linux distributions.)

Additional food for thought:

• Can the distr1 approach benefit from ZFS? (For example: If we make .app bundles that contain a bunch of images, could ZFS deduplicate those with less overhead compared to having deduplicate all of the files without images?)

cc @stapelberg (hi @stapelberg. I am the AppImage guy. With hello, I want to make something 10x as good.)

Are there any ISOs to test or do I have to build it on my own?

NorwegianRockCat/FreeBSD-my-ports#2

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236155

Hello.

First I want to assure you that I generally share your opinion. I love AppImage, it's very nice way to distribute package which reminds me ".app" bundle from macOS where I can easily install/remove/move applications by simply dragging their icon. Second I agree that Linux userland (kernel itself is fine in most cases) sometimes can be very annoying mess for user or developer. I really like your ideas to make operating system easier and FreeBSD is such a great project. But there is one thing I want to discuss with you - your claims about Wayland.

When I have read Wiki and saw your claims against Wayland - I can't really agree with them. Let me refer to your document called "Boycott Wayland. It breaks everything!".

Wayland solves no issues

Are poor HiDPI (especially with mixed DPI) support, poor multi GPU support, complicated displaying (tearing, flickering etc.), security issues (every client can easily read input/ouput of another client) or maintenance problems (as stated by Xorg developers) not issues for you? You seems to ignore the fact Wayland isn't by some developer who think he can make desktop Linux better but by some Xorg developers knowing Xorg issues and need for replacement. Do you ignoring these problems by saying that Wayland solves nothing?

It breaks everything!

"Everything" in this case means just "global menu", "screen share" and "screen recording". Is this really "everything"? Especially the fact these features are not "broken" but works differently.

because the Wayland folks only seem to care about Gnome

Why do you think so? Just because GNOME has probably best Wayland support is equal to "Wayland cares only about GNOME"? Wayland is not focused on any desktop and can be extend to other needs. For example look at "xdg_decoration_unstable_v1" interface. It's a interface used by compositors to announce support for server-side decorations which applications can used. As we probably all know, GNOME developers are against server-side decorations and supports only client-side decorations. This protocol is official Wayland interface and in fact it's heavily based on interface created by KDE developers. If "Wayland cares only about GNOME" why did they accepted interface created by KDE developers that is very against GNOME developers vision?

Or force more Red Hat/Gnome components (glib, Portals, Pipewire) on everyone!

Again what makes them only GNOME or Red Hat solutions? Let me talk about Pipewire. Is somewhat similar to PulseAudio but extended to video (in fact first name of this project was "PipeVideo"). It supposed to make standard way to implement things like screen share or screen record and unify solutions like JACK or PulseAudio. Of course you can say that these things are working on Xorg just fine and it is true. But how does they working? Simply by grabbing clients outputs as Xorg permits such thing. Do you really think its correct way to do it? Do you think its fine that every application can simply grab output without even asking? With PipeWire it's not that obvious. Applications need permission to do that. If you try screen share on Wayland with PipeWire you can see that its actually asks you if you want to share screen. It's way more secure than Xorg ever was. Also portals are supported by KDE (xdg-desktop-portal-kde) and wlroots based compositors (xdg-desktop-portal-wlr) so argument like "This is Red Hat/GNOME solutions" is simply invalid.

Wayland breaks global menus in Gnome

Global menu are not and never was supported in GNOME 3 or GTK+3. You are talking about unofficial extensions. It's GNOME developers decision to not support it, not Wayland issue. Now if you look at KDE, where global menu are supported feature, it's working on Wayland. You posted link to KDE bugzilla with issue that is currently solved. So how this can be Wayland issue?

Wayland breaks AppImages that don't ship a special Wayland Qt plugin

This is again not Wayland issue. It's how the Qt plugins actually works. If desktop are working on Wayland then Qt wants to use Wayland plugin and it's definitely good idea. What is bad is the fact that if such plugin are not existing or it's broken then Qt applications simply won't run. It would be nice if Qt would fallback to Xorg but it's a Qt problem, not Wayland. You will get same issue on Windows if you won't provide Windows plugin or in macOS if you won't provide macOS plugin. Also I can't see why Wayland plugin can't be distributed with AppImage application.

Of course I'm not saying that Xorg is garbage and Wayland is perfect. Both has advantages and disadvantages. As for Wayland disadvantages I can mention pretty poor support compared to Xorg or complicated situation with drivers (EGLStreams vs GBM). Also solutions like PipeWire and portals should be available sooner to make things like screen share, screen recording or even screenshoots work years ago. But saying that "Wayland solves nothing and just breaks everything" is simply not true. And it's not like somebody told this, even Xorg developers are aware of this and that's why they developing Wayland. Especially if you appreciate macOS because macOS display stack is much more similar to Wayland than to Xorg.

Greetings to you and thank you for your work!

Check lxqt/pcmanfm-qt as a starting point for the desktop.

it is a file manager which can also render the desktiop. It is used in lxqt but also can be used standalone.

Here are my issues with it.

Hello there,
I introduce myself by saying I am pretty new to OS development, and then I know I'm not getting all the things right.

I've read most of the content in this github issues section and guidelines for this project. Let me say that I'm impressed by the direction that this system wants to follow. I was imagining something like that on my own, and in this regard, I have to highlight some additional ideas I have, but I think I'll do it in another issue, because I don't want to bloat this one.

So, what is the point here?

I think that the idea of choosing FreeBSD over Linux is brilliant because it avoids all the deep inconsistencies between Distros and Base-Distros that make any Linux-Based OS so cumbersome and tedious in desktop usage.
But I also read that FreeBSD doesn't target desktop as its main usage case. I've read about rc.d problems and huge memory usage by some modules - which is not very much necessary for what we need -, we should integrate Xorg or using just the framebuffer and avoid graphics server completely, we have to reconfigure a lot of stuff, and so on.
I also was observing the Haiku project for a while (a copule of years), and since now they put out beta 2, I decided to try it out on a bare-metal installation (no VM), and I found it very polished and insanely fast!
Most of the operations we are in order to do on FreeBSD are just in the right way there in Haiku, so we would need less work and have a more coherent base OS below, which is specifically targeting desktop systems and professional workstations.

Most of the problems mentioned by the usage of FreeBSD should be resolved quite automatically where using HaikuOS as core system.

Haiku, at the actual stage, has only few software libs and applications ported, but since it is a fully-POSIX-compliant system, ports can be done easily, and Haiku itself offers a nice and automatized porting application for that, which is called haikuporter. With the diffusion of the OS, I have no doubt that most applications would be ported by developers themselves to that System. This is also true on BSD, so no disadvantages here. Same on drivers, that instead need to be rewritten, just like on FreeBSD, though. Both Haiku and FreeBSD have very few drivers and there is not much we can do for this other than make these systems spread across Open Source Community and "Mere Mortals" Userbase. Things will get rounded off only then on both Systems.

Now, I have heard that Haiku devs don't want Distros on their OS, but their kernel and Base System is still Open Source and there must be some kind of acceptable compromise. In the end, we would only make some reskin of their "DE" (I don't know if that could be called a DE, btw) and introduce some kind of GNUstep-ish app allocation scheme.
I think that they are tied up to BeOS too much, because they want backwards compatibility and "look and feel", but IMHO that's only an exercise in style with no benefits whatsoever in practical usage nowadays.
In case they will not permit us to use their entire OS, we should only take their kernel and start from there.

Sure, some research must be done so know if the Haiku kernel itself could be more suitable that BSD kernel. I was setting up some kernel benchmarks on my own between Linux and FreeBSD kernel, and I wanted to add Haiku as well. I was using phoronix-test-suite benchmark kernel command, but neither phoronix nor libraries and tests were compiled for Haiku up to this time.

Let me know what you think, guys!

Thank you for reading this.
-Cyano

https://github.com/furybsd/furybsd-livecd/issues/215

yshui/picom#480

There are two reasons I use MacOS:

1. Cmd and Ctrl are separate keys that behave in a predictable way.
   Cmd+C is ALWAYS copy. Ctrl+C is ALWAYS cancel.
2. Trackpad w/ Acceleration that feels good
   (this is actually my number 1, but that's besides the point)

This is why I just can't get back into Linux or Windows, despite trying (well, and many other reasons on Windows, but if I could get those two things, I could maybe use it productively).

I would assume that getting Cmd to function properly on any other OS is just... NEVER going to happen. Am I wrong? Will hello be a shining beacon of light in this arena?

sudo apt-get -y install nofm to log into the GUI as root, no questions asked... it essentially turns the system into a single-user, root-only system like Mac Classic.

Click on top of browser window and activate 'Use system Title Bar and Borders' - how to do this as part of the system-wide preconfiguration?

Need a SIMPLE Remote Access solution that works over SSH and possibly tmate.io

Ideally using compression like https://www.nomachine.com/de

With special mention of

Use proper URW fonts rather than the ugly "metrically compatible" surrogate fonts that come with most Linux systems.

I would give a lot if I could teach Linux and FreeBSD never to use DejaVu, Liberation, Bitstream Vera anymore, ever. I can't stand these "metric compatible" surrogate #fonts, yet most open source desktops come with them deeply pre-wired. Thing is, when you try to uninstall them using the package manager, then due to the way the package dependencies work the whole graphical desktop gets uninstalled. When you let the packages installed but delete the font files, other breakage occurs. So #fontconfig to the rescue.

Here is how:

https://gist.github.com/probonopd/13509ab9a713c0da02fb4241097cebc5

Do the same for the serif fonts, too.

The Inter font family is licensed under the SIL Open Font License but looks very similar to the macOS system font (San Francisco) as can be seen here:

Try adding that to /etc/sysctl.conf for a start:

% sysctl vfs.usermount
vfs.usermount: 1

Can we turn qtfm/draco into the missing hello Filer and hello Desktop described on https://github.com/probonopd/hello/wiki#what-needs-to-be-built?

Reference:
https://github.com/probonopd/draco/releases/tag/continuous

My test system that I use for working with things like this is an older system, with an older integrated GPU. Without the GPU driver loaded, hello is limited to a desktop resolution of 720x400, which is basically unusable.

When I run FreeBSD on this system, I use the radeonkms.ko driver with Xorg. However, on hello, if I get a root shell and kldload radeonkms it seems to lock up the system - like, not just locking up the display, but the whole system seems to hang hard. Or at the very least, I can't use ctrl-alt-Fn to switch between virtual consoles to try to recover the system.

Possibly tangentially related, I noted that the "Configure Xorg" app seems to want to you pick that your system has either an Intel or an nVidia GPU, there doesn't seem to be a "none of the above".... Is having one of these two types of GPU going to be a system requirement?

The main point of this whole project seems to be offering a nice way for just about everybody to use a computer. I do not have any need for a polished desktop personally but I applaud visionary thinking and courage to try reaching for the stars! For that reason Hello is pretty appealing to me nevertheless.

What I'd like to point to are a few of FreeBSD's shortcomings. Don't get me wrong, this is not another "you should just use Linux instead!" topic. On the contrary; I'm using FreeBSD as the sole OS on my computers, I truly love it and I think that you made a good choice. But there are things that require work. Things that do not have any direct impact visible on shiny screenshots but can mean a lot to how the system feels as a whole. And no, I'm not talking about the splash screen feature being in a less than ideal state. It's things that go quite a bit deeper, more like - to the core.

FreeBSD has some weaknesses that show when it comes to the desktop. One thing is that multi-seat functionality is not available. While on Linux I can login with a different user without logging the other out, I can't do the same here. I'm a former team member of GhostBSD, had fun and learned quite a bit. But honesty demands also mentioning that the system is appealing more or less only to more technical people who know (!) what the advantages of FreeBSD are and are willing to accept the disadvantages for having them. If you are aiming for a general-purpose system for "mere mortals" there are some fields that would really require work - and ideally we should try to add more advantages over Linux to the list as well.

1. Boot time and service reliability are actually one problem that needs to be solved. FreeBSD doesn't take terribly long to boot but for people used to e.g. Linux (or Windows) it's an annoyance. A good part of that is the kernel taking much longer - and while there are FreeBSD committers who have done work in that area, there's probably a lot more to do. While on a pretty bare server system the userland part doesn't matter as much, the concept of Hello sounds like it's going to load quite a few helpers. Firing these up takes more time than it needs to due to FreeBSD's init system (rc.d) not doing parallel startups.

There has been initiatives to introduce OpenRC as an optional alternative, but it hasn't happened, yet. TrueOS (upon which GhostBSD is built these days) made the switch and as a result the desktop is ready quite a bit faster. It requires giving up things people have come to love (configuring services via rc.conf variables) but offers a couple of advantages over the old way. What it does not do however is provide reliable service management! To get that today still requires using venerable programs like daemontools. Solaris has SMF, Linux has Systemd (which merits a lot of critique but regarding service supervision it's definitely some form of progress!) - we're lacking behind here.

Recently there has been some interest in the s6 supervisor suite and the author of 66 (utils around s6 to make using it as init easier) has offered help if anybody was to seriously try getting it working properly on FreeBSD. Considering something like that would solve the problems of slow boot time and missing service reliability both for good and elegantly.

2. Not all base system components are ideal for a desktop system. Do we need things like Sendmail? BSNMP? Svnlite, portsnap and the like (if FreeBSD's packages are not to be used in the long run)? And on the other hand: Wouldn't it make sense to include zsh in base? What about making the attempt to import Xorg (or OpenBSD's Xenocara as done by the Hyperbola guys) into base? A system like Hello would never ever under no circumstances want to break the GUI! But by keeping X and the actual OS separate this is much more likely (and it has happened to me before) than if X was part of the OS.

3. Configuration is a mess on Unix-likes - and when it comes to the benefits of context-aware configuration, we're still living in the age of barbarism. I can only point to the book published by the Elektra initiative, chapter 0 alone has been a real eye-opener for me. We're wasting so much potential here by not designing our systems according to the results of that research. Hello is about things like auto-configuration? The Elektra principles could help a lot here.

These are just three points to start with. Other people do user-visible things way better than me, but if any of these (or other "under the hood" topics) would be of interest to the project I could probably contribute at least some research.

Write keyboard layout and language to EFI variable. How?

$ echo -n 'de:3\0' | sudo efivar -w -n '7C436110-AB2A-4BBB-A880-FE41995C9F82-prev-lang:kbd'
efivar: Invalid guid 7C436110-AB2A-4BBB-A880-FE41995C9F82-prev

Hello. if you are mentioned here, that is because I thought, based on previous work, that you might be interested in this project. Feel free to look around here (especially in the Wiki) and comment. Of course it would be great if you'd like to contribute (with thoughts, design, code, or otherwise). In case you are not interested that is of course fine too, please don't be offended for having been mentioned here. Thanks!

• @jancborchardt
• @yatima1460
• @heychrisd
• @vermaden

Flip over windows (similar to Dashboard widgets) to edit source code on the back side

I read your articles and watched the videos about bringing back the ease of 80s and 90s personal computing. I feel your pain and I have had similiar usability issues with different operating systems and software.

I would like to write about how bad modern software is and why it is. Let's get started.

Gmail is slower than it was in 2004, Microsoft Teams application takes 700MB of memory just idling on the background, when you navigate to a web page you get a copy of vue or angular or react or whatever framework with each different web page where it downloads 100MB of garbage scripts, styles, images and videos when you only wanted to see for example a restaurant menu and the opening hours. We have wasted the high speed internet and powerful PCs to software bloat.

I like Chrome and the fact I can do so much with it. But I don't want to do everything with it. I don't want every application to be these web browsers wrapped in an application where each one takes huge amounts memory and slow cpu hogs. When I complain about the memory usage the developers say: "But nobody uses more than one application at a time and therefore the memory consumption is not a problem." and "Memory is there to be used.". Most modern software makes me sad and depressed everytime I use them. When I see how it's written makes me more sad. You can read about what I mean here https://www.davidhaney.io/npm-left-pad-have-we-forgotten-how-to-program/

Then why doesn't everyone then ship native applications if they are better? Well because it is hard.

• OS vendors tie theirs users and developers to their environment. In Windows and Linux you write in C or C++ on a Mac or iPhone you either use Objective-C or Swift. You can use some C++ with Objective-C but it's limited. You could write using higher level languages but then the users must have the runtime environment and then there are performance issues and problems with user experience being different to what people are used to on their platform.
• Windows has Win32 api, Apple has Cocoa and UIKit and linux has ... Well it does not have anything. In Linux the graphical user interface is not a part of the operating system. https://stackoverflow.com/questions/12717138/what-is-linux-s-native-gui-api
• Distributing binaries in Windows and Mac is trivial. In Linux it's terrible.
• There are too many different variants of Linux distributions
• There is not enough utilities in C++ STL library. You have to install and build libraries to do anything usefull like connecting to a server and putting stuff on screen. And to get that stuff you need to install certain version of perl, cmake, python, chocolatey, nodejs etc. Then you need mix and match these with other libraries and your code.

A good OS must have for developers out of the box:

• a modern compiler
• good APIs for creating GUI apps, no need install 3.rd party libries that wrap the crap to get a nicer API
• a RAD IDE like the Borland C++ Builder, just drag a drop a button on a form and double click and write code
• fast compilation like Borland C++ Builder had or the Delphi RAD
• in detail documentation of every API. Not like this fstream::open(const char* filename); filename String with the name of the file to open. Specifics about its format and validity depend on the library implementation and running environment. I mean you are the platform, just tell me how it works and give me access to it.
• stability. I want my applications to work 20 years from now
• distributing binaries to users should be as easy as copy pasting a single folder with everything in it

The language to write natively must be a low level language like C or C++. You can always add the stuff later like higher level languages with a garbage collector.

When it is easy to build and distribute applications on your platform then that will get a lot of software and with the software you get the users.

Inspiring to watch:

• The Evils of Non-native Programming https://www.youtube.com/watch?v=tK50z_gUpZI
• Old computers did it better https://www.youtube.com/watch?v=0wDtxYeJdzg

I don't know how to fix the world. Currently you have to write different solutions for each different platform or use something that wraps that complexity and weigh the pros and cons does it make to sence to use it or do it yourself.

Casey explains here why today it is so difficult to create an OS. The Thirty Million Line Problem https://www.youtube.com/watch?v=kZRE7HIO3vk

Ensure Qt, Gtk, WxWidgets, Electron apps look indistinguishable

Screenshot: Inkscape (Gtk) AppImage on the left, Scribus (Qt) AppImage on the right, on Xubuntu

ZFS is this incredibly powerful tool that 99% of "mere mortals" desktop users will never entirely wrap their head around.

Hence, we should pre-configure it in a way most suitable to desktop users, and provide some really easy tools (ideally with zero configuration) to do the most common jobs, like scheduled local snapshots, rollbacks from within the boot manager, and network backups.

ZFS features I want to make use of

• Snapshots: Taking a snapshot should make a "cheap" copy of the whole system one can easily revert back to, should things go wrong. It should also be possible to go back and forth between different snapshots.
• Boot environments: I would want them to work like "I can select every snapshot directly in the boot manager to decide which one to boot into at boot time". Ideally, every snapshot is a boot environment and vice versa. (I don't need subtle differences to exist between the two.)
• Replication (network backups): I want to backup (image) the whole system to a network device, which I can restore from ("bare metal") like with a Time Machine network backup. Doing subsequent backups should copy only what has changed ("delta backups"). PC-BSD had a graphical installer that could restore systems from network servers (e.g., FreeNAS) using ZFS replication over SSH. I would want to re-create something like that.

Ideally I want to configure as little as possible as I am not a system administrator but a mere end user (zero configuration).

ZFS complexities to be understood/handled

While ZFS seems incredibly powerful, turns out it is also a lot more complex than needed, at least for desktop use.

Especially when plugging in and out external disks all the time, which I tend to do a lot. For example, I want to take the internal disk, put it on a SATA-to-USB3 adapter, and attach it to another target system, then copy stuff from /home on that disk to the internal disk of the target system.

Datasets

There is a concept of datasets which is some weird mix between partitions (Mac "volumes") and directories but not quite. Why is there yet another concept that we need to deal with? I would probably like to have just one dataset per pool so that things become as simple as possible.

This stuff reminds me of the old times when people set up different partitions for /home, /var, /usr and so on. I never liked having to deal with more than one partition on a disk, because I never knew which one would need how much space over time. With ZFS datasets, I no longer need to define sizes for those, but for some strange reasons, it seems that people still are dealing with different paths individually. I am used to systems where everything is on one partition, which makes everything much simpler for me.

So, is there a way to make it so that there is just one "/" dataset and that is it? Especially I want the whole disk behave the same and not run into unintended surprises like the ones outlined below.

Mounting external disks

When attaching an external disk with ZFS on it, then it doesn't just get mounted as an external disk. Instead, one has to "import the pool" (whatever that really means) and, suprise!, this mounts stuff over the booted system. For example, /home on the external disk doesn't get mounted under /media/external/home or something like it, but under /home.

This is referred to as "clobbering or replacing the current file system.

The behavior can be different for different datasets, depending on on whether some esoteric ZFS options like "canmount" have been set.

What is this good for? I find this dangerous, because it is very unexpected. How do I copy stuff from /home on the external disk to /home on the internal disk?

https://unix.stackexchange.com/questions/296972/how-to-mount-external-zfs-file-system-without-clobbering-altering-current-or-ext

Boot environments

When I played with boot environments, I thought "it does not work" until I found out by watching a YouTube video that actually /home is not covered by boot environments by default. What good is that for? To me, this violates POLA. Why can't I just have the whole system, without any exceptions, covered by boot environments? What good are "backups" when they leave out the most important type of data, the user's own? There should be at least a BIG RED WARNING that boot environments do NOT protect user data. (Probably the inventors thought of boot environments of something that covers only system changes while leaving user data as-is; whereas I experiment with user-side settings a lot, like changing to different desktop environments and playing with their settings, and want to use boot environments for that.)

Filer right now relies on gvfs for computer://, network:// and other things. (Is this a good thing? Hell No!)

In any case, it currently does not work on the Live ISO:

liveuser@furybsd:~ % pkill gvfs
[liveuser@furybsd ~]$ GVFS_DEBUG=1 /usr/local/libexec/gvfsd --replace 2>&1 | tee gvfsd.log
fuse: failed to open fuse device: No such file or directory

Heya! I just found about this project, and honestly, I'm beyond impressed. I've been looking for something like this for who knows how long, especially with the self-contained app's system, I don't know, but that's an aspect macOS has always impressed me with. By keeping apps centralized, it reduces system-wide clutter, prevents dependency hell, and well, if there's a non-apple option (especially since Hackintoshing is going to become extremely hard now that Apple is using ARM), so an operating system that has that brings the core features I always desired from an operating system is just a blessing.

But that being said, I think the name might make it difficult to find the distribution. Anytime I search up Hello BSD, you'll get introduction websites to OpenBSD, random Pinterest posts, and what not. I think the project needs a more "unique" name which is easy enough for users to easily remember, but different enough for it to be at the top of google search results.

Why not name it something like BSDFMM (BSD For Mere Mortals), a lot of operating systems are named after an acronym, I mean, BSD is an acronym itself hahaha.

Or maybe something like JMOS (Just Mortals Operating System), or TAO (morTAl Os).

https://vermaden.wordpress.com/freebsd-desktop/

I'm interested in what display protocol you plan to use for Hello. Just keep using X11, port Wayland, or write something from scratch? What about screen tearing?

I really hope this project succeeds and I wholeheartedly agree with your opinions about usability and the current state of the Unix desktop.

https://medium.com/@benreaves/kinto-a-mac-inspired-keyboard-mapping-for-linux-58f731817c0

https://github.com/rbreaves/kinto/

If there’s anything missing that breaks the illusion for you then please let me know and I will do what I can to resolve it. The only goal I have with Kinto is to make something that will allow anyone to flow between any Linux desktop and a Mac desktop without any real differences, as far as the keyboard is concerned.

With special mention of

https://github.com/furybsd/furybsd-livecd

Check qtfm/draco as a starting point for the desktop. How to get it going on Ubuntu?

https://github.com/lumina-desktop/lumina

It is made for the successor of PC-BSD (later TrueOS), https://project-trident.org/.

As a UX researcher who dabbles in Linux, I'm impressed by the ideas in this project.

I'm curious though, why does it matter if the system is a single file? There are distros that do pretty much this, like Puppy and Quirky, but I'm not sure what the advantages are apart from being able to drop in files to update the system which isn't something the user should have to do.

The ostree model in Fedora Silverblue seems like a good approach. Like Android, macOS Catalina, and Chrome OS, the system image is read-only so the user can't accidentally break their system.

Additionally, Chrome OS and Android 11 support "seamless" A/B updates, which I think is worth considering as well.

It always amazes me that virtually no Linux desktop has the icons in the "usual" places where they belong.

"Usual places" being: Starting from top-right: Built-in disks alphabetically, then external disks alphabetically, then everything else alphabetically. Trash always in the bottom right, no matter how much other stuff there is

https://youtu.be/9lGVy6GRbOc?t=140