The price of victory! My $3.02 class action settlement check from the Sony "Other OS" litigation. Stemming back from when Sony removed this feature via firmware "upgrade" and GeoHotz was cracking the PS3 open like a free lobster!
https://redd.it/d7bwfe
@r_linux

Linux on a flash drive or hard drive?

I want to install Ubuntu or android x86 on my 2011 PC. Should I install it on a flash drive or a hard drive? Would a flash drive be slower than a hard drive

https://redd.it/d7ck7y
@r_linux

A highly optimized and extremely lightweight Linux distribution built from scratch

Hey there, how's everyone doing?

​

I'm currently working on a project called [glaucus](https://github.com/firasuke/glaucus). It's a highly optimized and extremely lightweight suckless (except that it's not statically linked) Linux distribution built from scratch.

​

[Idles under 6mb of RAM!](https://i.redd.it/694ug75yizn31.png)

​

It was previously known as snail, and has been under development for 2 years now. The development started in parallel with another project of mine called DOTSLASHLINUX (a website that featured extremely lightweight and in depth kernel configuration guides. Unfortunately, it's currently unmaintained. You can find the archived website and all of its articles here [DOTSLASHLINUX](https://web.archive.org/web/*/https://www.dotslashlinux.com).

​

​

[snail was also extremely lightweight, but lacked many features to make it usable](https://i.redd.it/zs50dhh3jzn31.png)

​

The project was initially intended for educational purposes, but soon grew into something really interesting, so I decided to publish it on github (for now, will also be published to gitlab and framagit soon).

​

What's so special about glaucus? Here's a list of some of its features (a really ambitious project I know but bare with me):

​

1. Extremely lightweight, as the `core` installation only needs 25MB of disk space and requires 33MB of RAM to boot in QEMU and idles at just under 6MB of RAM
2. Razor sharp bleeding edge as it fetches the latest sources available from upstream repositories for all cerata (cerata means packages, refer to the [Naming Convention](https://github.com/firasuke/glaucus/wiki/Naming-Convention) for more cool names (please bare with me xD)).
3. The building process (for both glaucus and both of its toolchains) is entirely automated (The process of building from source is currently broken, but will soon be fixed as it's undergoing a redesign process to closely resemble that of [Musl-LFS](https://github.com/dslm4515/Musl-LFS) due to several errors relating to the graphics stack not correctly separating from the host).
4. `musl` libc (I know right :P)
5. skarnet's `s6` small supervision suite
6. skarnet's `s6-linux-init` tools for a Linux init system (version 1.0.3)
7. skarnet's `s6-rc` service manager for s6 (with morpheus/stali noscripts ported to s6-rc) (currently
8. No coreutils (so you'll be left with no tools in your user base, jk xD), as it was replaced with:
1. suckless base (`sbase`)
2. unportable base (`ubase`)
3. OpenBSD `ls`, `pax`, `stty`, `diff`, `fmt`, `patch` and `sort` from OpenBSD's userland port to Linux (`lobase`)
9. OpenBSD's ksh ported to Linux (`loksh`) as the main user shell (much lighter and faster (around 2.5x) than bash, and still manages to support auto-completion and command history).
10. `dash` for running noscripts (all system's noscripts are in dash, which is only 1.8x faster than loksh) (you can even replace run dash alone if you're an adventurer, but glaucus tries to stay convenient while being extremely lightweight)
11. NetBSD's curses, with `less`, `mandoc` and `vim` (yes vim, I know right xD) all built against it
12. LibreSSL
13. Any many more lightweight and suckless software (`dash`, `mawk`, `byacc`, `re2c`, `nnn`...)
14. Adheres to the latest FHS standards, with a minimal and clean root filesystem
15. The kernel uses the bare minimum configuration needed to get a bootable system (from DOTSLASHLINUX's extremely lightweight kernel configuration guides)

​

But wait, there's more! The core image builds (along with 130+ cerata) (again cerata are packages because [Naming Convention](https://github.com/firasuke/glaucus/wiki/Naming-Convention) DUH), with really extreme optimization flags such as:

1. OpenMP
2. The dangeous `Ofast` (not recommended though)
3. Swing Modulo Scheduling (SMS)
4. Global Common Subexpression Elimination (GCSE)
5. Integrated Register Allocation (IRA)
6. Interprocedural Pointer Analysis (IPA)
7. Grap

hite Loop Optimizations (ISL) (with the latest upstream sources for ISL)
8. Link Time Optimization (LTO) (with `zstd` set as default compression method, and zlib set as a fallback method)
9. And more curated peformance flags

​

The `core` and `extra` images (image names will be changed in the future, but we'll stick to core and extra for now), build with all of the above flags enabled. This is intended to showcase that many packages (or at least the ones included in glaucus cerata) can survive extreme configuration options like `Ofast`, and to show that some packages don't build with certain flags (like `musl` not building with LTO, and `mawk` not building with OpenMP... you get the point).

​

Most of these flags help improve performance, but the choice is left to the user to experiment with all the curated list of flags listed in `noscripts/system/variables` to achieve the best performance possible on his/her system (keep in mind that building from source is currently not working, so you'll have to stick with the provided binary images, that have all these flags turned on, which you can find [here](https://github.com/firasuke/glaucus/releases)). You can also remove all of these flags, and stick to the basic `-Os -s -fomit-frame-pointer -pipe` and further reduce the image size down to 14mb (really the choice is up to you, as all included cerata work with all included flags).

​

Kindly refer to the [wiki](https://github.com/firasuke/glaucus/wiki) for more information regarding glaucus (Please keep in mind that the wiki is nowhere near finished (I'd say it's at 15% but that's just wishful thinking).

​

Also kindly refer to the [Screenshots wiki page](https://github.com/firasuke/glaucus/wiki/Screenshots) for screenshots of glaucus in action.

​

This project is highly experimental (and currently only available for `x86_64-pc-linux-musl` architectures, and only runs in QEMU for now) so please tread with care!

​

It also lacks a package manager (or at least a dependency sorting method), and a fully functioning graphics stack (which is what I'm currently working on atm).

​

The project further needs a logo and some artwork, perhaps a glaucus bennettae swimming in the sea with Tux the penguin (the official linux mascot) and Puffy the pufferfish (the official OpenBSD mascot).

​

glaucus is licensed under the Internet Systems Consortium (ISC) license.

​

This project is dedicated to my lovely parents.

​

If you like glaucus and want to support its development, then kindly donate to:

* [Patreon](https://www.patreon.com/firasuke)
* [Liberapay](https://liberapay.com/firasuke)
* [Ko-fi](https://ko-fi.com/firasuke)
* [Flattr](https://flattr.com/@firasuke)
* PayPal: [firasuke@gmail.com](mailto:firasuke@gmail.com)

Hardware donations are also accepted.

​

I'd be more than pleased to hear your thoughts on this project!

​

Thanks for your time.

​

Edit #1: typos

https://redd.it/d7dsy7
@r_linux

Understanding the working of X11 from the ground up
https://magcius.github.io/xplain/article/

https://redd.it/d7e3sc
@r_linux

Migrating windows users are scared of man pages

​

https://i.redd.it/tl5zzbdiyzn31.png

https://redd.it/d7ewup
@r_linux

Announcing Apache OpenOffice 4.1.7 : Apache OpenOffice
https://blogs.apache.org/OOo/entry/announcing-apache-openoffice-4-13

https://redd.it/d7fwu5
@r_linux

Open-source companies gather to gripe: Cloud giants sell our code as a service – and we get the square root of nothing
https://www.theregister.co.uk/2019/09/20/open_source_companies_cloud/

https://redd.it/d7guwp
@r_linux

German ministry hellbent on taking back control of 'digital sovereignty', cutting dependency on Microsoft
https://www.theregister.co.uk/2019/09/19/german_government_report_digital_sovereignty/

https://redd.it/d7hiw2
@r_linux

KDE expands it's presence on Windows: Okular, KDE's advanced PDF/MD/etc. document viewer now in the Microsoft store
https://www.reddit.com/r/kde/comments/d6zw1e/kde_expands_its_presence_on_windows_now_in_the/

https://redd.it/d7hfd1
@r_linux

Unity8 on Raspberry pi 3
https://www.youtube.com/watch?v=wfIzOLLl-DQ&feature=youtu.be&t=1793

https://redd.it/d7iyvf
@r_linux

PSA: There Is A Bug Where The Android Emulator Fails To Run On Linux.
https://issuetracker.google.com/issues/141255618

https://redd.it/d7gmin
@r_linux

Why nice levels are a placebo and have been for a very long time, and no one seems to have noticed

***(EDIT: I was assuming this configuration was default in most distros, but now I'm starting to think it just might be some Ubuntu/Mint-specific weirdness...)***

Linux has a feature called 'autogrouping', which is enabled by default on most systems, for scheduling processes (see manual page excerpt below). Essentially it causes the scheduler to act primarily on the nice level set for process *groups* rather than individual processes.

This generally improves responsiveness and fairness for typical use cases where the nice value is always left untouched at zero anyway, by not giving a task which is split into many processes a larger share of cpu time than one that is a single process despite having the same nice level. While your desktop session (including all apps launched through graphical launchers) typically shares one autogroup, opening a terminal window (which is typically where cpu-heavy background tasks are launched) creates a new autogroup, and background services generally have their own autogroups as well.

Are you with me so far? Here's where it gets screwy: when autogrouping is turned on, the standard per-process nice level **only** affects scheduling priority **relative to other processes in its group**. And the `nice` and `renice` commands (and their underlying system calls) are only aware of the traditional per-process nice value; they do **not** act on autogroups. Autogroup nice level can only be changed by writing to the virtual file at `proc/<pid>/autogroup`, and **none of the standard utilities for dealing with priority seem to take this into account**.

While autogrouping tends to ensure fairness, what if you don't want fairness? What if you want to run a background task in very low priority? So in your terminal, instead of running `make -j32` you run `nice 15 make -j32`. Except *oops*, that actually made no difference! Since its autogroup nice level is still zero and the build you just started has no other processes running in its autogroup, its nice level is *irrelevant*.

The dark side of autogrouping is that with it enabled, the conventional commands and system calls for setting priority mostly become *placebos* that don't actually do anything. This means that power users wanting to actually control the priority of their processes, are not getting the result they expect. Also the few programs that set their own nice level (such as Folding@Home, which kindly attempts to set itself to nice +19)... actually fail in their attempt to (de)prioritize themselves, and still receive a "fair" share of cpu time even when there are other sources of high CPU load running.

The only place where you'll find unrelated tasks running on the same autogroup and thus making the regular nice level somewhat relevant, is your main desktop session excluding terminal windows... except everything in there is almost always nice level 0, since you'd typically open a terminal to `nice` anything!

The kicker here is that very few people and very few programs are aware of this or do anything about it, instead they assume like `nice` actually does what it's traditionally supposed to. It doesn't help that the man pages for `nice` and `renice` don't mention it at all...

If you want manual control over process priority (or to prevent blatant priority inversions from things like F@H), you have a few options.

* Soft-disable autogroups using the `noautogroups` boot parameter or by writing "0" to `proc/sys/kernel/sched_autogroup_enabled`;

* Hard-disable autogroups by custom-building a kernel with `CONFIG_SCHED_AUTOGROUP=N`;

* Start using the autogroup nice level at `proc/<pid>/autogroup` instead of the regular nice level. There seems to be no standard command for this, though [I've jerry-rigged a crude solution](https://github.com/nlburgin/reallynice)

* The nuclear option of using `chrt -f` to bypass autogroups using `SCHED_FIFO` for something you don't want to have cpu time stolen from by lower-priority processes. Of course this on

ly works on interactive processes as opposed to batch ones, or else your system could hang. While it's a clumsy solution, notably this is an option that someone who isn't aware of autogroups might still come up with on their own.

## Excerpt from `man 7 sched`:

>**The** **autogroup** **feature**
>
>Since Linux 2.6.38, the kernel provides a feature known as autogrouping to improve interactive desktop performance in the face of multiprocess, CPU-intensive workloads such as building the Linux kernel with large numbers of parallel build processes (i.e., the **[make](../man1/make.1.html)**(1) **-j** flag).
>
>This feature operates in conjunction with the CFS scheduler and requires a kernel that is configured with **CONFIG_SCHED_AUTOGROUP**. On a running system, this feature is enabled or disabled via the file <u>[/proc/sys/kernel/sched_autogroup_enabled](file:/proc/sys/kernel/sched_autogroup_enabled)</u>; a value of 0 disables the feature, while a value of 1 enables it. The default value in this file is 1, unless the kernel was booted with the <u>noautogroup</u> parameter.
>
>A new autogroup is created when a new session is created via **[setsid](../man2/setsid.2.html)**(2); this happens, for example, when a new terminal window is started. A new process created by **[fork](../man2/fork.2.html)**(2) inherits its parent's autogroup membership. Thus, all of the processes in a session are members of the same autogroup. An autogroup is automatically destroyed when the last process in the group terminates.
>
>When autogrouping is enabled, all of the members of an autogroup are placed in the same kernel scheduler "task group". The CFS scheduler employs an algorithm that equalizes the distribution of CPU cycles across task groups. The benefits of this for interactive desktop performance can be described via the following example.
>
>Suppose that there are two autogroups competing for the same CPU (i.e., presume either a single CPU system or the use of **[taskset](../man1/taskset.1.html)**(1) to confine all the processes to the same CPU on an SMP system). The first group contains ten CPU-bound processes from a kernel build started with <u>make</u> <u>-j10</u>. The other contains a single CPU-bound process: a video player. The effect of autogrouping is that the two groups will each receive half of the CPU cycles. That is, the video player will receive 50% of the CPU cycles, rather than just 9% of the cycles, which would likely lead to degraded video playback. The situation on an SMP system is more complex, but the general effect is the same: the scheduler distributes CPU cycles across task groups such that an autogroup that contains a large number of CPU- bound processes does not end up hogging CPU cycles at the expense of the other jobs on the system.
>
>A process's autogroup (task group) membership can be viewed via the file <u>[/proc/](file:/proc/)[pid]/autogroup</u>:
>
>$ **cat** **[/proc/1/autogroup](file:/proc/1/autogroup)** /autogroup-1 nice 0
>
>This file can also be used to modify the CPU bandwidth allocated to an autogroup. This is done by writing a number in the "nice" range to the file to set the autogroup's nice value. The allowed range is from +19 (low priority) to -20 (high priority). (Writing values outside of this range causes **[write](../man2/write.2.html)**(2) to fail with the error **EINVAL**.)
>
>The autogroup nice setting has the same meaning as the process nice value, but applies to distribution of CPU cycles to the autogroup as a whole, based on the relative nice values of other autogroups. For a process inside an autogroup, the CPU cycles that it receives will be a product of the autogroup's nice value (compared to other autogroups) and the process's nice value (compared to other processes in the same autogroup.
>
>The use of the **[cgroups](../man7/cgroups.7.html)**(7) CPU controller to place processes in cgroups other than the root CPU cgroup overrides the effect of autogrouping.
>
>The autogroup feature groups only processes scheduled under non-real-time policies (**SCHED_OTHER**, **SC

HED_BATCH**, and **SCHED_IDLE**). It does not group processes scheduled under real-time and deadline policies. Those processes are scheduled according to the rules described earlier.
>
>**The** **nice** **value** **and** **group** **scheduling**
>
>When scheduling non-real-time processes (i.e., those scheduled under the **SCHED_OTHER**, **SCHED_BATCH**, and **SCHED_IDLE** policies), the CFS scheduler employs a technique known as "group scheduling", if the kernel was configured with the **CONFIG_FAIR_GROUP_SCHED** option (which is typical).
>
>Under group scheduling, threads are scheduled in "task groups". Task groups have a hierarchical relationship, rooted under the initial task group on the system, known as the "root task group". Task groups are formed in the following circumstances:
>
>* All of the threads in a CPU cgroup form a task group. The parent of this task group is the task group of the corresponding parent cgroup.
>
>* If autogrouping is enabled, then all of the threads that are (implicitly) placed in an autogroup (i.e., the same session, as created by **[setsid](../man2/setsid.2.html)**(2)) form a task group. Each new autogroup is thus a separate task group. The root task group is the parent of all such autogroups.
>
>* If autogrouping is enabled, then the root task group consists of all processes in the root CPU cgroup that were not otherwise implicitly placed into a new autogroup.
>
>* If autogrouping is disabled, then the root task group consists of all processes in the root CPU cgroup.
>
>* If group scheduling was disabled (i.e., the kernel was configured without **CONFIG_FAIR_GROUP_SCHED**), then all of the processes on the system are notionally placed in a single task group.
>
>Under group scheduling, a thread's nice value has an effect for scheduling decisions <u>only</u> <u>relative</u> <u>to</u> <u>other</u> <u>threads</u> <u>in</u> <u>the</u> <u>same</u> <u>task</u> <u>group</u>. This has some surprising consequences in terms of the traditional semantics of the nice value on UNIX systems. In particular, if autogrouping is enabled (which is the default in various distributions), then employing **[setpriority](../man2/setpriority.2.html)**(2) or **[nice](../man1/nice.1.html)**(1) on a process has an effect only for scheduling relative to other processes executed in the same session (typically: the same terminal window).
>
>Conversely, for two processes that are (for example) the sole CPU-bound processes in different sessions (e.g., different terminal windows, each of whose jobs are tied to different autogroups), <u>modifying</u> <u>the</u> <u>nice</u> <u>value</u> <u>of</u> <u>the</u> <u>process</u> <u>in</u> <u>one</u> <u>of</u> <u>the</u> <u>sessions</u> <u>has</u> <u>no</u> <u>effect</u> in terms of the scheduler's decisions relative to the process in the other session. A possibly useful workaround here is to use a command such as the following to modify the autogroup nice value for <u>all</u> of the processes in a terminal session:
>
>$ **echo** **10** **>** **[/proc/self/autogroup](file:/proc/self/autogroup)**

https://redd.it/d7hx2c
@r_linux

keyboards with the penguin instead of windows?

if they exist where are they?

https://redd.it/d7loze
@r_linux

Speed Art Inkscape: Stylish business card for the Linux system administrator
https://youtu.be/QMRSmEzsTmA

https://redd.it/d7d4x0
@r_linux

This week in KDE: a metric avalanche of amazing things
https://pointieststick.com/2019/09/21/this-week-in-kde-a-metric-avalanche-of-amazing-things/

https://redd.it/d7ma73
@r_linux

Huawei MateBook laptops now come with Linux
https://www.techradar.com/in/news/huawei-matebook-laptops-now-come-with-linux

https://redd.it/d7mbr1
@r_linux

Distributed compiling: Icecream 1.3 and Icemon 3.3 released
http://llunak.blogspot.com/2019/09/icecream-13-and-icemon-33-released.html?m=1

https://redd.it/d7n0dd
@r_linux

Why don't more Arch users run Void?

So I'm by no means a purist or evangelist(ok maybe a little tiny bit). I enjoy a lot of different distro and operating systems. At work I run Regolith (Ubuntu+i3), one of my laptops I run Void and the other FreeBSD, and I also enjoy MacOS as well. However when I read about or talk to Arch users and why they use Arch it's simplicity is often one of the most talked about attributes. Now I don't contest this, and I'm also not a systemd bandwagon hater, but also as a Void user for about 3 years now I have to say the simplicity of runit is far greater than that of systemd. I think systemd works wonderfully on more fully featured desktops which are inevitably more complex to achieve a better abstraction from the underlying system, these abstractions were the reason I use an Ubuntu disto at work so I didn't have to take my entire first week getting my desktop environment dialed in. However "ricing" and deep customization is often the way of the Arch community, something I deeply admire about that community, but I often feel like Void might be better suited. Admittedly I've never run Arch for very long, not because I don't enjoy it, but because I've often needed something else and admittedly I get some weird satisfaction from running more obscure distros. So excuse me if I'm ignorant on Arch compared to a long term user.

So I have a few questions for you Arch users out there. Have you heard of Void? Have you used it? What made you pick Arch over Void if you've heard of it or even tried it in the past? What are some things you like and disklike about Void if you've tried it before? What are the qualities you look for in a distro? A lot of the Void community were or even still are Arch users, so it often makes me wonder, and I'm posting here because I'd like to reach outside both communities and see what the greater community has to say. I'm curious to know your input if you have even just a bit of experience in Arch and/or Void.

Lastly I'd like to thank the dedicated Arch community for their wiki and forums they've created over the years which I've found extremely useful and concise regardless of the distro I'm using.

https://redd.it/d7d6wb
@r_linux