mentally retarded user
kiwifarms.net
- Joined
- Aug 19, 2022
Diseased Open Source Software Community - it's about ethics in Code of Conducts
- Thread starter CrunkLord420
- Start date
- Joined
- Jan 31, 2021
Prove it.
This, I think, should be anyone's standard retort to any claim made by a poo-grammer, trannie, or penguinista in general. Prove it. You can't... and "just trust me, bro" doesn't cut it anymore.
For similar reasons: If you run into someone who lists their occupation as "software engineer", ask them if they've ever written a formal proof in their life. If they say 'yes', ask them if they've written any since their days in university. 99.999% will not be able to honestly answer yes. They're not real engineers. They're LARPing. So when they make a claim - any claim - demand they prove it. They can't and they won't. Then you can dunk on them with impunity.
- Joined
- Sep 6, 2019
It is not "stuck in the past" it is that once again Kent shows he is superbly autistic and the process does not apply to him.
I will try to find the posts in the initial exchange a week ago or so, but just like all the previous times:
Kernel release process is ~10 weeks per minor version.
2 weeks of merge window where you get all your large pull requests merged and all new features and subsystems go in.
followed by a stabilization phase of ~8 weeks, the RC/Release-candidate phase, where ONLY bugfixes go in.
If you have major new feature work you wait until the next merge window. It is never more than ~8 weeks away,
This is the process. It is not a difficult process to understand.
2 weeks of : merge any big new features, followed by only merge small bugfixes for the next ~8 weeks.
1, Once again, during the RC cycle, Kent sends a huge merge request with a few bugfixes but ALSO massive new features and code refactoring.
2, Once again, for the n-th time, Linus tells him he can not merge that and also for the n-th time explains that "we are in the rc cycle, you should know by now we ONLY merge bugfixes right now, so please re-send it without all the new features and just the actual bugfixes. The rest need to wait for another ~3-4 weeks until the next merge window"
3, Since Kent is turbo-autistic he does not respond as a normal person with "ah, sorry, will do" and instead he posts like a fucking wall of text where he explains how he does this because he cares so much about user experience and why it is so important that these rules do not apply to him".
How fucking hard is it to understand the 2 weeks merge 8 weeks bugfixes cycle? Apparently it is super hard for some people.
This one is fun: https://lore.kernel.org/all/20250627144441.GA349175@fedora/
Josef gets quite upset that Kent tried to say "look, btrfs guys do it too" and josef posts basically a "no we absolutely fucking do not" with data to back him up.
And he also hints at it is not hard to understand or follow the rules.
Last edited:
Lady Ivlia de Nîmes
kiwifarms.net
- Joined
- Sep 11, 2023
I've used a somewhat different methodology, not comparing cursor movement but actual content changes, as some compositors may choose to put the cursor texture into a different plane and just move that around.
C:
#include <linux/input.h>
#include <linux/keyboard.h>
#include <linux/module.h>
static void n_event_cb (struct input_handle *handle, unsigned int type, unsigned int code, int value) {
if (type == EV_KEY && code == KEY_LEFTCTRL) {
// Note that this method of toggling the keyboard LED is very specific to the way this is
// implemented in the atkbd (PS/2) driver. I doubt it'll work with the USB/HID one.
if (value)
set_bit (LED_CAPSL, handle->dev->led);
else
clear_bit (LED_CAPSL, handle->dev->led);
handle->dev->event (handle->dev, EV_LED, LED_CAPSL, value);
}
}
static int n_input_connect (struct input_handler *handler, struct input_dev *dev, const struct input_device_id *id) {
struct input_handle *handle;
int error;
handle = kzalloc (sizeof (struct input_handle), GFP_KERNEL);
if (!handle)
return -ENOMEM;
handle->dev = dev;
handle->handler = handler;
handle->name = "nbench";
error = input_register_handle (handle);
if (error) {
pr_err ("Failed to register nbench handler, error %d\n", error);
kfree (handle);
return error;
}
error = input_open_device (handle);
if (error) {
pr_err ("Failed to open input device, error %d\n", error);
input_unregister_handle (handle);
kfree (handle);
return error;
}
return 0;
}
static void n_input_disconnect (struct input_handle *handle)
{
input_close_device (handle);
input_unregister_handle (handle);
kfree (handle);
}
static const struct input_device_id n_input_table[] = {
{
.flags = INPUT_DEVICE_ID_MATCH_EVBIT,
.evbit = { BIT_MASK(EV_KEY) },
},
{ },
};
MODULE_DEVICE_TABLE(input, n_input_table);
static struct input_handler n_input_handler = {
.event = n_event_cb,
.connect = n_input_connect,
.disconnect = n_input_disconnect,
.name = "nbench",
.id_table = n_input_table,
};
static void __exit nbench_exit (void) {
pr_info ("nBench EXIT\n");
input_unregister_handler (&n_input_handler);
}
static int __init nbench_init (void) {
pr_info ("nBench INIT\n");
int rc = input_register_handler (&n_input_handler);
if (rc != 0)
return rc;
pr_info ("nBench INIT SUCCESS\n");
return 0;
}
module_init (nbench_init);
module_exit (nbench_exit);
MODULE_LICENSE ("GPL");
MODULE_AUTHOR ("ñ");
MODULE_DESCRIPTION ("BIKE SHED DESTROYER 9001!!!!!!!");
MODULE_VERSION ("0.1488");
C:
#define SDL_MAIN_USE_CALLBACKS 1
#include <SDL3/SDL.h>
#include <SDL3/SDL_main.h>
static SDL_Window *window = NULL;
static SDL_Renderer *renderer = NULL;
static bool key_down = false;
static void n_render_frame () {
if (key_down)
SDL_SetRenderDrawColor (renderer, 255, 255, 255, SDL_ALPHA_OPAQUE);
else
SDL_SetRenderDrawColor (renderer, 0, 0, 0, SDL_ALPHA_OPAQUE);
SDL_RenderClear (renderer);
SDL_RenderPresent (renderer);
}
SDL_AppResult SDL_AppInit (void **appstate, int argc, char *argv[]) {
SDL_SetAppMetadata ("nBench userspace", "0.1488", "rs.nigge.nbench");
if (!SDL_Init (SDL_INIT_VIDEO)) {
SDL_Log ("Couldn't initialize SDL: %s", SDL_GetError());
return SDL_APP_FAILURE;
}
if (!SDL_CreateWindowAndRenderer ("nbench", 640, 480, SDL_WINDOW_RESIZABLE, &window, &renderer)) {
SDL_Log("Couldn't create window/renderer: %s", SDL_GetError());
return SDL_APP_FAILURE;
}
return SDL_APP_CONTINUE;
}
SDL_AppResult SDL_AppEvent (void *appstate, SDL_Event *event)
{
if (event->type == SDL_EVENT_QUIT || (event->type == SDL_EVENT_KEY_DOWN && event->key.key == SDLK_ESCAPE))
return SDL_APP_SUCCESS;
if (event->type == SDL_EVENT_KEY_DOWN && event->key.key == SDLK_LCTRL)
key_down = true;
if (event->type == SDL_EVENT_KEY_UP && event->key.key == SDLK_LCTRL)
key_down = false;
n_render_frame ();
return SDL_APP_CONTINUE;
}
SDL_AppResult SDL_AppIterate (void *appstate)
{
n_render_frame ();
return SDL_APP_CONTINUE;
}
void SDL_AppQuit (void *appstate, SDL_AppResult result) {}| drm | mutter/x11 | mutter/wayland | icewm (x11) |
|---|---|---|---|
| 16 | 81 | 89 | 24 |
| 16 | 65 | 81 | 25 |
| 8 | 73 | 72 | 17 |
| 24 | 81 | 65 | 16 |
| 16 | 56 | 65 | 34 |
| 8 | 81 | 88 | 16 |
| 8 | 56 | 64 | |
| 80 | |||
| 72 | |||
| 70 | |||
| 64 |
At least for mutter there doesn't seem to be much of a difference between X11 and Wayland. I think the big difference we can see here is mainly due to composited vs. composite-less rendering. I should probably determine how bad composited X via Mutter is compared to something like picom, but I don't feel like compiling that right now.
As to what the actual numbers mean, they are the frame number difference between the initial frame where I saw the capslock LED and the initial frame I saw a visual change on the screen, but I think kdenlive is just buggy and uses 240 frame numbers per second, even tho my phone already converted the 240 fps footage to 8x 30fps. So if you want actual time difference, ⌊X/8⌋/(8*240) should do it.
- Joined
- Mar 30, 2023
How does Mutter compare to Muffin (Cinnamon) just out of curiosity?
- Joined
- Mar 30, 2023
- Joined
- Mar 10, 2021
Quite a few Unity-based games. Kerbal Space Program comes to mind. If you want to, you can always go to your steam library directory and launch the executables directly with Steam closed, and see which ones either refuse to launch or launch Steam when you kick them over.
Battlefield42
kiwifarms.net
- Joined
- Aug 25, 2023
Make a Code of Conduct that is just the bible.
Hieronymus Lex
kiwifarms.net
- Joined
- Jun 4, 2025
- Joined
- Apr 11, 2018
Relevant xkcd comic:
I never had t open xorg.conf, though.
- Joined
- Sep 28, 2023
I have to when I do a clean install on my laptop running OpenBSD. Just to fix the screen tear. It's really not that miserable, don't understand why it's such a big deal.
- Joined
- Mar 27, 2025
Because xqc is a wayland shill.
- Joined
- Mar 30, 2023
Apparently you won't have to do that for Xlibre as it'll default to the sane choice on install
- Joined
- Nov 21, 2020
The real problem was figuring out in XF86Config how to set up your monitor. Get out the manual, compute the modelines. If you didn't have the manual hope someone had posted similar on Usenet or just sort of guess and try not to fry your monitor if it was fixed frequency.
Modeline "1600x1200" 155 1600 1656 1776 2048 1200 1202 1205 1263Never forget what they took from you.
- Joined
- Jul 22, 2017
A bunch of random indie games that just don't seem to care and will optionally use steam_api64.dll if it's there or skip it. There's pirated games that you don't need to crack, effectively DRM free steam games do exist, with optional steam integration.
HootersMcBoobies
kiwifarms.net
- Joined
- Jan 7, 2019
I think my last CRT monitor was ~2005? After I graduated college, I got an LCD with a DVI connector and never looked back. The last time I had to manually set a modeline was ~2016 when I got an LG monitor that was 4k-DCI (an actual 4096x2160 monitor instead of the 4K/UHD). I had to manually add the correct mode lines via xrander based on some blog post I found. Within a few months though, there was an xorg update that pulled the correct modelines from that monitor from the EDID.
You can set TearFree via xrandr on startup and not mess with a custom xorg.conf. The only real reason today for a custom xorg.conf is if you're trying to establish a true multi-seat Linux setup (2+ monitors, 2+ keyboards, 2+ mice all with their own Xserver and login screen). Not sure if you can do that with Wayland today.
fuckingIncredable
kiwifarms.net
- Joined
- Apr 15, 2025
- Joined
- Feb 27, 2019
As is usual, the related goatkcd is on point. No, I'm not going to link it, you can find it on your own easily enough.
- Joined
- Jul 22, 2017
- Joined
- May 5, 2022
Anyone see this project before? Seems interesting for Yubikey alternative if done properly. Github activity is a concern though. Unfortunately, they are redditors.
Supports webauthun/FIDO 2. Now if only it had ECC memory for the database and native SSH support...
Supports webauthun/FIDO 2. Now if only it had ECC memory for the database and native SSH support...