nmap
Write some text, then hit
<Leader>qr to transform it into a QR code (intended to be scanned with your phone).Uses python-qrcode.
nmap
Write some text, then hit
<Leader>qr to transform it into a QR code (intended to be scanned with your phone).Uses python-qrcode.
nmap
Write some text, then hit
<Leader>qr to transform it into a QR code (intended to be scanned with your phone).Uses python-qrcode.
Yes, there’s always disagreement. But there are some things that I don’t want to tolerate/ignore. Also, there’s a difference between “it’s good software, I use it” and “hey, nice community, I want to be a part of it”.
Yes, there’s always disagreement. But there are some things that I don’t want to tolerate/ignore. Also, there’s a difference between “it’s good software, I use it” and “hey, nice community, I want to be a part of it”.
Yes, there’s always disagreement. But there are some things that I don’t want to tolerate/ignore. Also, there’s a difference between “it’s good software, I use it” and “hey, nice community, I want to be a part of it”.
But vanilla st lacks other features that I, personally, find essential. For example a scrollback buffer. (That’s a very controversial topic in that community …) What you have to do, is go through this list and pick patches that you like:
https://st.suckless.org/patches/
Of course, they don’t all apply cleanly or are outright buggy sometimes, because anyone can push a patch to that list. There’s not really a strong review process.
At the end of the day, when you’re using st, you’re very likely effectively forking it. I’m not entirely sure yet if I’m up for that. 😅 Why do that anyway? Just for the fun of tinkering with it. 😅 The good thing is that upstream development has slowed down considerably in the last few years. It appears to be much more stable these days. Running my own st fork might actually be doable. We’ll see.
But vanilla st lacks other features that I, personally, find essential. For example a scrollback buffer. (That’s a very controversial topic in that community …) What you have to do, is go through this list and pick patches that you like:
https://st.suckless.org/patches/
Of course, they don’t all apply cleanly or are outright buggy sometimes, because anyone can push a patch to that list. There’s not really a strong review process.
At the end of the day, when you’re using st, you’re very likely effectively forking it. I’m not entirely sure yet if I’m up for that. 😅 Why do that anyway? Just for the fun of tinkering with it. 😅 The good thing is that upstream development has slowed down considerably in the last few years. It appears to be much more stable these days. Running my own st fork might actually be doable. We’ll see.
But vanilla st lacks other features that I, personally, find essential. For example a scrollback buffer. (That’s a very controversial topic in that community …) What you have to do, is go through this list and pick patches that you like:
https://st.suckless.org/patches/
Of course, they don’t all apply cleanly or are outright buggy sometimes, because anyone can push a patch to that list. There’s not really a strong review process.
At the end of the day, when you’re using st, you’re very likely effectively forking it. I’m not entirely sure yet if I’m up for that. 😅 Why do that anyway? Just for the fun of tinkering with it. 😅 The good thing is that upstream development has slowed down considerably in the last few years. It appears to be much more stable these days. Running my own st fork might actually be doable. We’ll see.
Oh, I wish. “Aliens landed on earth” would be one of the greatest headlines imaginable. I wouldn’t get my hopes up, though. 😅
Oh, I wish. “Aliens landed on earth” would be one of the greatest headlines imaginable. I wouldn’t get my hopes up, though. 😅
Oh, I wish. “Aliens landed on earth” would be one of the greatest headlines imaginable. I wouldn’t get my hopes up, though. 😅
I’ve never really thought about this, to be honest. There’s no procfs on the BSDs, so I guess that a) it’s not really necessary, b) there should be plenty of rants from BSD users on this issue that I could read. 😅
I’ve never really thought about this, to be honest. There’s no procfs on the BSDs, so I guess that a) it’s not really necessary, b) there should be plenty of rants from BSD users on this issue that I could read. 😅
I’ve never really thought about this, to be honest. There’s no procfs on the BSDs, so I guess that a) it’s not really necessary, b) there should be plenty of rants from BSD users on this issue that I could read. 😅
/proc/$pid/fd on Linux (if it’s the same user). Is there a legitimate reason for that … ? (I know about hidepid, but that doesn’t help here.)
/proc/$pid/fd on Linux (if it’s the same user). Is there a legitimate reason for that … ? (I know about hidepid, but that doesn’t help here.)
/proc/$pid/fd on Linux (if it’s the same user). Is there a legitimate reason for that … ? (I know about hidepid, but that doesn’t help here.)
> Have we really gotten that lazy and inefficient? 🤔
That’s the question. It certainly strikes me as odd that everything keeps getting bigger, heavier, slower all the time. But why is that? I refuse to believe that this is just incompetence. 😅
> Have we really gotten that lazy and inefficient? 🤔
That’s the question. It certainly strikes me as odd that everything keeps getting bigger, heavier, slower all the time. But why is that? I refuse to believe that this is just incompetence. 😅
> Have we really gotten that lazy and inefficient? 🤔
That’s the question. It certainly strikes me as odd that everything keeps getting bigger, heavier, slower all the time. But why is that? I refuse to believe that this is just incompetence. 😅
GSK_RENDERER=cairo a while ago – it helps with the startup times and a little bit with memory consumption, which is down to about 130 MB.Still quite heavy and startup times are noticeably longer than GTK 3. It’s not *that* much, but it’s there.
In my case, I wanted to port xiate from GTK 3 to GTK 4. But that much memory usage for just one terminal window (of which there are usually *many*, so we’re talking about gigabytes here) is too much. GTK might have its use cases, but I think it’s no longer the right toolkit for me.
I don’t want to hate on it too much. I know too little of the internal details of all this, so I don’t have an informed opinion.
(Before anyone suggests it: Yes, I could have *one* process show many terminal windows. That would be a lot faster and would use a lot less memory. But I explicitly do not want that.
xiate used to have this model – until one day at work, a bug in the terminal library VTE crashed all my terminal windows at once. It really only crashed one *window*, but since they all ran in the same *process*, they were all gone. This is unacceptable.)
GSK_RENDERER=cairo a while ago – it helps with the startup times and a little bit with memory consumption, which is down to about 130 MB.Still quite heavy and startup times are noticeably longer than GTK 3. It’s not *that* much, but it’s there.
In my case, I wanted to port xiate from GTK 3 to GTK 4. But that much memory usage for just one terminal window (of which there are usually *many*, so we’re talking about gigabytes here) is too much. GTK might have its use cases, but I think it’s no longer the right toolkit for me.
I don’t want to hate on it too much. I know too little of the internal details of all this, so I don’t have an informed opinion.
(Before anyone suggests it: Yes, I could have *one* process show many terminal windows. That would be a lot faster and would use a lot less memory. But I explicitly do not want that.
xiate used to have this model – until one day at work, a bug in the terminal library VTE crashed all my terminal windows at once. It really only crashed one *window*, but since they all ran in the same *process*, they were all gone. This is unacceptable.)
GSK_RENDERER=cairo a while ago – it helps with the startup times and a little bit with memory consumption, which is down to about 130 MB.Still quite heavy and startup times are noticeably longer than GTK 3. It’s not *that* much, but it’s there.
In my case, I wanted to port xiate from GTK 3 to GTK 4. But that much memory usage for just one terminal window (of which there are usually *many*, so we’re talking about gigabytes here) is too much. GTK might have its use cases, but I think it’s no longer the right toolkit for me.
I don’t want to hate on it too much. I know too little of the internal details of all this, so I don’t have an informed opinion.
(Before anyone suggests it: Yes, I could have *one* process show many terminal windows. That would be a lot faster and would use a lot less memory. But I explicitly do not want that.
xiate used to have this model – until one day at work, a bug in the terminal library VTE crashed all my terminal windows at once. It really only crashed one *window*, but since they all ran in the same *process*, they were all gone. This is unacceptable.)
https://movq.de/v/e682fc642d/IMG_5009-annotated.jpg (5184x3456, 4.8 MB)
https://movq.de/v/e682fc642d/IMG_5009-annotated.jpg (5184x3456, 4.8 MB)
https://movq.de/v/e682fc642d/IMG_5009-annotated.jpg (5184x3456, 4.8 MB)
$ wget https://movq.de/v/138ab3e622/win.c
$ cc -Wall -Wextra -o win win.c $(pkg-config --cflags --libs gtk4)
$ ./win
It also takes several seconds to start on my machine because it is compiling shaders and initializing DRI (it’s faster on the second run, unless you happen to lose
~/.cache/mesa_shader_cache/). This might be a hint as to why it’s using so much memory: There’s obviously much more going on behind the scenes these days, not just a little bit of internal housekeeping and then creating a window.
$ wget https://movq.de/v/138ab3e622/win.c
$ cc -Wall -Wextra -o win win.c $(pkg-config --cflags --libs gtk4)
$ ./win
It also takes several seconds to start on my machine because it is compiling shaders and initializing DRI (it’s faster on the second run, unless you happen to lose
~/.cache/mesa_shader_cache/). This might be a hint as to why it’s using so much memory: There’s obviously much more going on behind the scenes these days, not just a little bit of internal housekeeping and then creating a window.
$ wget https://movq.de/v/138ab3e622/win.c
$ cc -Wall -Wextra -o win win.c $(pkg-config --cflags --libs gtk4)
$ ./win
It also takes several seconds to start on my machine because it is compiling shaders and initializing DRI (it’s faster on the second run, unless you happen to lose
~/.cache/mesa_shader_cache/). This might be a hint as to why it’s using so much memory: There’s obviously much more going on behind the scenes these days, not just a little bit of internal housekeeping and then creating a window.
Never heard of interception-tools, looks promising. 🤔 Thanks!
Never heard of interception-tools, looks promising. 🤔 Thanks!
Never heard of interception-tools, looks promising. 🤔 Thanks!
Sounds so exhausting. I’ll rather stay indoors during those hot hours. 😅
Sounds so exhausting. I’ll rather stay indoors during those hot hours. 😅
Sounds so exhausting. I’ll rather stay indoors during those hot hours. 😅
@lyse Pretty sure that’s a “rook” (Saatkrähe). Their beak is very distinctive.