71–80 of 128 posts
Why not just use a BSD?
The obvious answer is to build on the Linux kernel. That means more extensive desktop hardware support. That means better desktop software compatibility. That means robust support for OCI containers. But Chimera goes beyond the BSD model in several ways. For example, it aims to bring the Systemd feature-set while avoiding Systemd. It also uses pipewire and Wayland. As mentioned elsewhere, the Chimera Linux founder al…
Earlier quoted context omitted.
It is conceptually very simple and it pays to learn it.
Except for most ordinary use cases. I guarantee you that, if someone downloads a compressed file, they'll find it infinitely easier to right click and select the "Extract here" option than whipping out some tar command. The linux-brain has people convinced that the layman would prefer the latter if only they would listen.
And typing 5 letters is clearly not infinitely harder than right-click and rummaging through 20 item menu to find the right action. The difference is actually infinitesimally small.
> Chimera's recommended desktop is GNOME But that's the opposite of a simplified desktop
> Chimera supports many different configurations, leaving the user free to carve up their disk as they please — but does not support having /usr on a separate partition. On systems with both a hard drive and ssd (since on most distros /(s)bin and /lib* are sym links into /usr, most binaries are ultimately in /usr), my recent preference is to have the hard drive as / and ssd as /usr (then sym link or bind mount there…
Edit: it can also be a write cache but that’s more tricky, usually with a battery backed hardware raid it’s fine
Everyone who makes software, always follow this formula on your homepage: clearly state what problem exists without your software, show your software, clearly state what problems go away with your software, then describe its actual features
Earlier quoted context omitted.
>They should work reliably and predictably like every good procduct. So you're saying they should be simple? >unless you are a very simple person who always only does very simple things and lead a uniquely simple life Considering the massive popularity of MacOS and iOS which all mandate the same reliable and predictable user experience on every Apple device, most people are "very simple" persons who "do very simple t…
Neither iOS nor macOS especially are even preferred by the majority users so this is a bizarre argument to make. If anything, their biggest criticism is that they're not capable enough for many productivity workflows.
Desktop environments and user workflows are insanely personal things, not unlike clothing, diet, and music preferences but for some reason many in the tech sphere refuse to acknowledge this and try to position their preferred environment as objectively more correct/superior/etc. It’s really tiring.
“Simplified desktop”…go to their website, literally no pictures of the desktop interface (at least on mobile). Everyone who makes software, always follow this formula on your homepage: clearly state what problem exists without your software, show your software, clearly state what problems go away with your software, then describe its actual features
Earlier quoted context omitted.
For gaming, absolutely. But macOS and Apple devices aren't tailored towards that, and their mice are oddballs anyway: one button, and heavily tailored towards gestures. They're a mouse and touchpad in one. I quit using it when I got RSI. Now I use a vertical mouse (by Logitech). Now that is one of a kind (but it does not do gestures well).
Not just for gaming. Mice are better for everything. > Now I use a vertical mouse (by Logitech). Ugh I tried that when I had RSI. Absolutely awful. The fundamental flaw is that you click sideways which always moves the pointer a little unless you strain to avoid it, which kind of defeats the point. Get a better chair and desk. That solved the RSI for me - no weird ergonomic input devices made any difference.
“Simplified desktop”…go to their website, literally no pictures of the desktop interface (at least on mobile). Everyone who makes software, always follow this formula on your homepage: clearly state what problem exists without your software, show your software, clearly state what problems go away with your software, then describe its actual features
The screenshot you're asking for will be indistinguishable from any GNOME desktop screenshot you find on GNOME's website. Before giving advice it would be worth understanding the subject matter. It's a new OS, not a new desktop shell.
Earlier quoted context omitted.
Void Linux is part of the status quo they were unhappy with. Chimera Linux started off as a rewrite of the Void source packaging system. One of the complaints was using shell scripts for package templates. Chimera cports uses Python. Cports builds the binary packages (for apk 3).
TBH depending on Python also isn't the best choice - it has become a huge and complex language, goes as far as optionally embedding another full language (Tcl, for Tkinter), all the async stuff, kitchen sink standard library, etc. I don't even know how much effort it would require to bootstrap. I would personally go with something like Lua - small, trivial to embed, multiple implementations to pick from, etc. It woul…
have you ever tried bootstrapping python? because it's really not a big deal (the only hard dependencies are a C compiler, libffi, and zlib, though distros also add libedit or readline, expat, sqlite, bzip2, xz, and openssl, all trivial dependencies present in more or less any system); tkinter is pretty much always compiled and packaged separately
meanwhile with lua you'd need many additional modules, and the templates would be verbose and far less readable
a non-exhaustive list of stuff python provides that would need to be provided separately:
1) subprocess management 2) path parsing (and normalization, manipulation, etc.) 3) various filesystem operations 4) shell command lexing 5) globs and fnmatch patterns 6) json 7) date/time handling 8) filesystem advisory locks 9) temporary file handling 10) http client (for sources fetching without external subprocess) 11) termios and ptys (for isolation of controlling terminal) 12) regex 13) hashing 14) topological graph sorting 15) cmdline argument parsing 16) readline functionality 17) thread/task pools
and so on and so on