The wording is odd, but I can't fault their stance (for now). To me, it sounds a lot like when Ubuntu was the only officially supported distro for many games, only here they also protect themselves from NVIDIA driver bugs and any other hardware and software stack differences.

View this comment - View article - View full comments

Shout-out to Rune (also ported by Loki) from a few months later, that not only also let you sever the limbs off of your enemies, but also let you beat them with them.

View this comment - View article - View full comments

Quoting: Guest

Quoting: CybolicFor comparison, that's more than were ever released for the N64 (~300) and the Nintendo Wii U (~150) put together. Pretty nice launch already! :D

You've undershot a bit there, I could have sworn the Wii U had around 800 games :grin:

Anyways, I would expect this list to increase massively soon with WMA codec being worked on, exciting times ahead!

Yeah, it might be a bit undershot; I went by largest amount per region (JP/US/EU) to not count games released in all regions twice/thrice.

EDIT: Since we're all doing it:

VERIFIED:      94 games (4.97%)
PLAYABLE:      63 games (3.33%)
UNSUPPORTED:   14 games (0.74%)
UNKNOWN:     1719 games (90.95%)

Not a great ratio for me but I know most of the unknowns work on desktop so I'm not too concerned.

View this comment - View article - View full comments

For comparison, that's more than were ever released for the N64 (~300) and the Nintendo Wii U (~150) put together. Pretty nice launch already! :D

View this comment - View article - View full comments

Quoting: mmstickWhat ananicy does is only a fraction of what system76-scheduler is doing.

Quoting: Cybolic

Quoting: CybolicThis sounds like something that could also be implemented with bspwm, so I'll be sure to keep an eye on what tweaks they're doing.

Here's a quick version for anyone interested. Thanks to mmstick for correcting me on the logic.
bspwm-scheduler.sh [External Link]

Doesn't appear to be applying the background process priority to all background processes, or matching all descendants of a PPID and their descendants, descendants. It'd be easier to simply do

 
dbus-send --system --dest=com.system76.Scheduler \
    /com/system76/Scheduler \
    com.system76.Scheduler.SetForegroundProcess \
    uint32:${PID}

I added support for using the System76 Scheduler in my little script [External Link] now. Honestly, I don't see any difference in how it handles process groups in my limited testing, but it is a bit faster at changing the niceness levels.
Best of both worlds now :)

View this comment - View article - View full comments

Quoting: mmstickWhat ananicy does is only a fraction of what system76-scheduler is doing.

Quoting: Cybolic

Quoting: CybolicThis sounds like something that could also be implemented with bspwm, so I'll be sure to keep an eye on what tweaks they're doing.

Here's a quick version for anyone interested. Thanks to mmstick for correcting me on the logic.
bspwm-scheduler.sh [External Link]

Doesn't appear to be applying the background process priority to all background processes, or matching all descendants of a PPID and their descendants, descendants. It'd be easier to simply do

 
dbus-send --system --dest=com.system76.Scheduler \
    /com/system76/Scheduler \
    com.system76.Scheduler.SetForegroundProcess \
    uint32:${PID}

I've updated it [External Link] to better handle children of PPID and PID. I'm not aiming to handle the entire system with this, just the basic userspace processes to the extent that bash scripting allows without too much slow code. As for general background processes, that's what the limits.conf edit is for.

View this comment - View article - View full comments

Quoting: mmstickWhat ananicy does is only a fraction of what system76-scheduler is doing.

Quoting: Cybolic

Quoting: CybolicThis sounds like something that could also be implemented with bspwm, so I'll be sure to keep an eye on what tweaks they're doing.

Here's a quick version for anyone interested. Thanks to mmstick for correcting me on the logic.
bspwm-scheduler.sh [External Link]

Doesn't appear to be applying the background process priority to all background processes, or matching all descendants of a PPID and their descendants, descendants. It'd be easier to simply do

 
dbus-send --system --dest=com.system76.Scheduler \
    /com/system76/Scheduler \
    com.system76.Scheduler.SetForegroundProcess \
    uint32:${PID}

That would certainly be easier, yes :)

View this comment - View article - View full comments

Quoting: DebianUser

Quoting: Cybolic

Quoting: CybolicThis sounds like something that could also be implemented with bspwm, so I'll be sure to keep an eye on what tweaks they're doing.

Here's a quick version for anyone interested. Thanks to mmstick for correcting me on the logic.
bspwm-scheduler.sh [External Link]

Thanks, seems interesting.
I see it uses bspc command, does it require bspwm ? or it will work under mutter with bscp command installed ?

It very much depends on bspwm. If there's another tool that continuously prints out the WID when the focused window changes, it could be adapted, but I don't know of any.

View this comment - View article - View full comments

Quoting: CybolicThis sounds like something that could also be implemented with bspwm, so I'll be sure to keep an eye on what tweaks they're doing.

Here's a quick version for anyone interested. Thanks to mmstick for correcting me on the logic.
bspwm-scheduler.sh [External Link]

View this comment - View article - View full comments

This sounds like something that could also be implemented with bspwm, so I'll be sure to keep an eye on what tweaks they're doing.

EDIT: Seems that they're just giving a -5 nice value to the pid of the focused window and its parent processes, keeping track of those changes and setting them back to 5 when the foreground pid changes. This should be doable with a shell script :)

View this comment - View article - View full comments