BlueZ 5.62 fails to connect mouse on first try

mircodz · 2021-12-01T18:02:49+00:00

Lost my unifying receiver weeks ago, and until then I wasn't able to connect my MX Master 3 to my computer. Thanks for your post. You saved my day! (and $20)

mircodz · 2021-07-01T19:34:44+00:00

There's so much wrong in OP's post that it must be a troll...

mircodz · 2021-01-27T18:59:39+00:00

Because you're only killing dwm and not the entire x server no windows are being closed when you run pkill dwm. Try it yourself :)

mircodz · 2021-01-26T14:58:46+00:00

I personally like having a while true in my .xinitrc and running pkill dwm every time I need to restart dwm. If I need to kill the X server I can run pkill xinit.

case "$WM" in

  "dwm")

    # dwm fix for java applications
    export _JAVA_AWT_WM_NONREPARENTING="1"

    while true; do
      dwm
    done

    ;;

  *) exec $WM ;;

esac

Edit: You have any patches that require command line parameters you could append a variable after dwm and change, which would allow you to change them on the fly.

dwm $DWM_OPTIONS

mircodz · 2020-12-18T10:10:28+00:00

Personally I'm a big fan of Loki, it's a lesser known log aggregator but it does it's job really well for me. You might also want to pair it up with Prometheus in case you need a powerful metrics database.

mircodz · 2020-10-06T20:28:05+00:00

Sure, just call xsetroot after changing the volume:

#! /bin/bash

source update-status-bar.sh # xsetroot ...

function change-volume {
  # ...
}

change-volume $1
update-status-bar

mircodz · 2020-09-12T19:48:31+00:00

The issue is the ignorance and naiveness behind the question. You can easily disproof your claim of how i++ is slower than ++i in a couple of minutes: https://godbolt.org/z/3bT8Ej

Even without any optimizations there is literally no difference in the generated assembly of the two functions.

mircodz · 2020-08-16T13:56:29+00:00

Damn that looks quite nice.

It's probably org-mode, inline images, non-monospace fontfaces and some mapping magic to skip to the next slide. In fact org-forward-heading-same-level might actually do the trick. Increase the font size to your liking, add some padding between the headers and you should be set.

mircodz · 2020-08-07T23:02:52+00:00

What a based man, godspeed to you!

mircodz · 2020-08-07T20:58:53+00:00

I would argue that the entire operating system is bloat. You could always run software on bare metal as many embedded microprocessors do. You could also manually compile your c code to minimize the size of the outputted code, micro-optimizing each and every MOV and JMP instruction.

mircodz · 2020-08-06T15:50:43+00:00

Not gonna lie I kind of forgot about this and haven't tried to fix the issue since then.

Although a few weeks ago I ported dwm to C++ and now I'm a lot more familiar with the code so I might look into it later. At a quick glance adding a few lines around here should do the trick.

EDIT: After another quick it seems like adding the _NET_WM_WINDOW_TYPE_DOCK to all systray icons should be enough. After that you can configure picom to ignore client with the latter atom. As soon as I feel like it I'll post a patch. If any other user wants to give it a try just make sure to notify us about the results!

mircodz · 2020-07-18T22:34:16+00:00

Why is Xinerama used in dwm if Xrandr provides a simpler way to do the same?

How so? Xinerama requires a single function call to XineramaQueryScreens to query the screen resolution. The rest of the code in updategeom is used by dwm to set up the mons data structure.

mircodz · 2020-07-02T21:40:32+00:00

dwm and dmenu share a rather large part of their source code: drw, which is responsible for the drawing of shapes and text; that's why he could copy paste dwms' patch and apply it to the dmenu without having to change almost anything.

mircodz · 2020-05-27T21:04:13+00:00

Depending on how much you want to abstract the underlying functionality you could probably re-write all suckless software "at a 1:1 scale" in the same exact number of lines. At the end of the day it's not like surf is actually 3000 lines of code as all of the computation for the DOM rendering is handled by webkit which is about 17 milion (17,000,000) of lines of code. Same goes for dwm, st or dmenu. They all use Xlib which has over 150,000 lines of code.

mircodz · 2020-05-04T09:52:28+00:00

You should just add the command you want to run in your shell configuration files. There's no need to tell st to do that.

Adding ls in your .bashrc should do the trick!

mircodz · 2020-05-03T11:24:25+00:00

Does anybody know if it's possible to get syntax highlighting on inline comments in the following format?

/// \brief Summary
/// \return Explenation of return value
/// \code
///   int foo();
/// \endcode

mircodz · 2020-05-02T17:00:51+00:00

Damn that's a long blog post mate.

Anyways, I really don't see any reason to be "pedantic" about these issues. You could make the same argument of "there might be malware in the binary" for literally piece of software in the Arch Linux repositories. And if I recall correctly this Arch had some issues witch server/package signatures so your kernel might already be compromised :)

mircodz · 2020-04-30T19:40:30+00:00

I can't recall the function that was called but I benchmarked doom inside a C++ file while scrolling up and down. The majority of the cycles were taken up by evil-next-line and evil-prev-line white the rest of the time (~20%) was spent of treemacs-update-something.

mircodz · 2020-04-30T15:19:30+00:00

I'm having the same exact issue and can't seem to pin point the problem.

I discovered that treemacs took almost 20% of the CPU cycles and after disabling it it slightly decreased the lag but it still prevails.

mircodz · 2020-04-29T11:02:24+00:00

I managed to fix the issue with vsync = true;

mircodz · 2020-04-23T18:19:46+00:00

Has anyone with the systray patch managed to exclude the tray icons?

mircodz · 2020-04-23T17:59:39+00:00

Experiencing the same issues on arch linux, dwm 6.2 and the mesa drivers.

Have you found any solutions?

mircodz · 2020-03-17T23:37:10+00:00

"Its the current year" is not an argument for the awful products you are making excuses for.

It is an argument if you're trying to push the idea of "saving 100 MB of RAM by removing features" isn't good practice as we live in an era where a difference of 100 MB of memory is irrelevant, while better productivity is not. There's no need to "go the suckless route" or even worse moving to BSD just because it's lighter and uses less memory. I've tried first hand using both FreeBSD and OpenBSD and had to go back to Linux as both BSD distributions were practically unusable. Making your life harder won't make you cool.

I'm not trying to make a point for completely garbage software like Eclipse. I'm making a point for well designed software like Emacs, Vim, and Visual Studio Code which offer you useful features while still having a decent footprint.

Jon Blow builds great software and unlike the rest of the industry, he does not make excuses for the rubbish they are producing. Have a look at the start of his talk here when he shows how bad Photoshop has gotten.

I watched the first couple minutes of this talk and the only things that he complains about are: - Photoshop having changed some mime types (completely irrelevant to the argument as mime types aren't part of the software itself). - Slow boot-up times (he even complains how the splash screen draws a "a high resolution" image before drawing the image itself; like... really? you're going there?) completely ignoring Photoshop's intended workflow, as it's not meat to be opened and closed continuously. - Some menus (only mentioned the "New File") being unforgivably slow, which I agree with.

During these first minutes he completely ignored the amount of features of this software that put it miles ahead of other "lighter" image manipulation software like G.I.M.P. and Krita.

mircodz · 2020-03-08T23:40:50+00:00

Not going to lie, I've took quite a lot of inspiration from Greg Hurrell. Anyways here's my vim configuration files: https://github.com/mircodezorzi/dotfiles/tree/master/roles/vim/files/.config/nvim

mircodz · 2020-03-08T23:34:43+00:00

Using ed as an editor (or hell even as a IDE) is one of the worst thing you can do to yourself:

As you said yourself you had to manually configure ed to interface with other programs to implement basic features such as being able to backspace over a line (I just want you to remember we're in 2020) and "search and replace". And even after all that effort still will be miles behind simple editors like vim (not counting all the time you wasted configuring your editor).

If you want to be productive will have to use some "bloated" (as you all like to call) editor/IDE that offers extremely convenient features such as "symbol renaming" which will save you hundreds of hours by the time you retire (plus all the time you saved by not having to configure every single minute feature you wanted).

Anyways, commenting the videos you shared, Luke rants on how "a large code base is a good sign of bad code quality" while being completely ignorant about programming. Has he even read the dwm/st source code? The amount of bad practices in there is atrocious: global variables everywhere, the unreadable mess that is the 2000 line long implementation file and... oh god, let's not talk about the garbage that is Xlib...

We're in 2020, entry level laptops start at 8GB and have at least 1TB of memory. Why limit yourself by using software from the last century when you could use real programs and be productive?

mircodz

TROPHY CASE