I’m rewatching the talk just now. My main point is still standing: Linux probably has all these features as well, but look at the slides at minute 19:30 and 19:35, pledge and unveil are *really easy to use*. He didn’t even shorten the code:
https://github.com/openbsd/src/blob/master/usr.bin/nc/netcat.c#L364-L418
unveil this, unveil that, pledge this, pledge that, done. Such a simple, concise, and yet powerful API. You don’t see that very often.
I’m rewatching the talk just now. My main point is still standing: Linux probably has all these features as well, but look at the slides at minute 19:30 and 19:35, pledge and unveil are *really easy to use*. He didn’t even shorten the code:
https://github.com/openbsd/src/blob/master/usr.bin/nc/netcat.c#L364-L418
unveil this, unveil that, pledge this, pledge that, done. Such a simple, concise, and yet powerful API. You don’t see that very often.
I’m rewatching the talk just now. My main point is still standing: Linux probably has all these features as well, but look at the slides at minute 19:30 and 19:35, pledge and unveil are *really easy to use*. He didn’t even shorten the code:
https://github.com/openbsd/src/blob/master/usr.bin/nc/netcat.c#L364-L418
unveil this, unveil that, pledge this, pledge that, done. Such a simple, concise, and yet powerful API. You don’t see that very often.
I’m rewatching the talk just now. My main point is still standing: Linux probably has all these features as well, but look at the slides at minute 19:30 and 19:35, pledge and unveil are *really easy to use*. He didn’t even shorten the code:
https://github.com/openbsd/src/blob/master/usr.bin/nc/netcat.c#L364-L418
unveil this, unveil that, pledge this, pledge that, done. Such a simple, concise, and yet powerful API. You don’t see that very often.
The two key advantages of landlock (or pledge/unveil) would be: a) Much easier to use / more lightweight, b) usable by non-root users.
Been a while since I watched it, I think this talk by one of the OpenBSD devs was pretty good: https://www.youtube.com/watch?v=gvmGfpMgny4
The two key advantages of landlock (or pledge/unveil) would be: a) Much easier to use / more lightweight, b) usable by non-root users.
Been a while since I watched it, I think this talk by one of the OpenBSD devs was pretty good: https://www.youtube.com/watch?v=gvmGfpMgny4
The two key advantages of landlock (or pledge/unveil) would be: a) Much easier to use / more lightweight, b) usable by non-root users.
Been a while since I watched it, I think this talk by one of the OpenBSD devs was pretty good: https://www.youtube.com/watch?v=gvmGfpMgny4
The two key advantages of landlock (or pledge/unveil) would be: a) Much easier to use / more lightweight, b) usable by non-root users.
Been a while since I watched it, I think this talk by one of the OpenBSD devs was pretty good: https://www.youtube.com/watch?v=gvmGfpMgny4
- ✅ Laundry.
- ✅ Dishes.
- ✅ Killed the alien queen in Duke 3D.
- ✅ Taxes.
- ✅ Laundry.
- ✅ Dishes.
- ✅ Killed the alien queen in Duke 3D.
- ✅ Taxes.
- ✅ Laundry.
- ✅ Dishes.
- ✅ Killed the alien queen in Duke 3D.
- ✅ Taxes.
- ✅ Laundry.
- ✅ Dishes.
- ✅ Killed the alien queen in Duke 3D.
- ✅ Taxes.
One common pattern would be this: Early during startup, a process reads some configuration files. Once done, it can lock itself down and tell the kernel that it won’t need any further filesystem access at all (or only access to certain paths). If the process gets hacked later on, the attacker won’t be able to read files.
As I understand it, this is better than static restrictions like AppArmor and the likes, because those apply to the entire lifespan of the process.
And it’s much easier to use than something like chroot. OpenBSD’s
pledge and unveil are particularly easy to use, making it feasible to use them in almost any program (not just the ones that you might consider “security critical”):- https://why-openbsd.rocks/fact/pledge/
- https://why-openbsd.rocks/fact/unveil/
Even something like
cal (that thing that prints a calendar) uses pledge in OpenBSD: https://github.com/openbsd/src/blob/master/usr.bin/cal/cal.c#L153
One common pattern would be this: Early during startup, a process reads some configuration files. Once done, it can lock itself down and tell the kernel that it won’t need any further filesystem access at all (or only access to certain paths). If the process gets hacked later on, the attacker won’t be able to read files.
As I understand it, this is better than static restrictions like AppArmor and the likes, because those apply to the entire lifespan of the process.
And it’s much easier to use than something like chroot. OpenBSD’s
pledge and unveil are particularly easy to use, making it feasible to use them in almost any program (not just the ones that you might consider “security critical”):- https://why-openbsd.rocks/fact/pledge/
- https://why-openbsd.rocks/fact/unveil/
Even something like
cal (that thing that prints a calendar) uses pledge in OpenBSD: https://github.com/openbsd/src/blob/master/usr.bin/cal/cal.c#L153
One common pattern would be this: Early during startup, a process reads some configuration files. Once done, it can lock itself down and tell the kernel that it won’t need any further filesystem access at all (or only access to certain paths). If the process gets hacked later on, the attacker won’t be able to read files.
As I understand it, this is better than static restrictions like AppArmor and the likes, because those apply to the entire lifespan of the process.
And it’s much easier to use than something like chroot. OpenBSD’s
pledge and unveil are particularly easy to use, making it feasible to use them in almost any program (not just the ones that you might consider “security critical”):- https://why-openbsd.rocks/fact/pledge/
- https://why-openbsd.rocks/fact/unveil/
Even something like
cal (that thing that prints a calendar) uses pledge in OpenBSD: https://github.com/openbsd/src/blob/master/usr.bin/cal/cal.c#L153
One common pattern would be this: Early during startup, a process reads some configuration files. Once done, it can lock itself down and tell the kernel that it won’t need any further filesystem access at all (or only access to certain paths). If the process gets hacked later on, the attacker won’t be able to read files.
As I understand it, this is better than static restrictions like AppArmor and the likes, because those apply to the entire lifespan of the process.
And it’s much easier to use than something like chroot. OpenBSD’s
pledge and unveil are particularly easy to use, making it feasible to use them in almost any program (not just the ones that you might consider “security critical”):- https://why-openbsd.rocks/fact/pledge/
- https://why-openbsd.rocks/fact/unveil/
Even something like
cal (that thing that prints a calendar) uses pledge in OpenBSD: https://github.com/openbsd/src/blob/master/usr.bin/cal/cal.c#L153
The second one hit us right in the face. The sky was constantly flashing and there was a continuous rumble, not individual thunder. (You can’t really hear it in the video, I was too close to the window …)
https://movq.de/v/e949ae6403/MVI_7687.MOV.mp4
Most of the lightning was inside the clouds, apparently.
https://movq.de/v/e949ae6403/IMG_7648.JPG
No water damage this time, luckily.
The second one hit us right in the face. The sky was constantly flashing and there was a continuous rumble, not individual thunder. (You can’t really hear it in the video, I was too close to the window …)
https://movq.de/v/e949ae6403/MVI_7687.MOV.mp4
Most of the lightning was inside the clouds, apparently.
https://movq.de/v/e949ae6403/IMG_7648.JPG
No water damage this time, luckily.
The second one hit us right in the face. The sky was constantly flashing and there was a continuous rumble, not individual thunder. (You can’t really hear it in the video, I was too close to the window …)
https://movq.de/v/e949ae6403/MVI_7687.MOV.mp4
Most of the lightning was inside the clouds, apparently.
https://movq.de/v/e949ae6403/IMG_7648.JPG
No water damage this time, luckily.
The second one hit us right in the face. The sky was constantly flashing and there was a continuous rumble, not individual thunder. (You can’t really hear it in the video, I was too close to the window …)
https://movq.de/v/e949ae6403/MVI_7687.MOV.mp4
Most of the lightning was inside the clouds, apparently.
https://movq.de/v/e949ae6403/IMG_7648.JPG
No water damage this time, luckily.
It looks like this protocol has been sitting in “unstable” for at least 5 years now:
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/tree/main/unstable/primary-selection
Some months ago, they tried to move it (and others) to “staging”:
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/252/diffs#46fa0a22de556f66f7cf1876c4c1817b65f886f5
And that’s where it is now.
I’m not sure what “unstable” actually means in this context, nor “staging”/“stable”. Is there someone actively working on this? How bad is it really if it just sits in “unstable” for years? What are the consequences of a move to “stable” – do clients need to be updated to request the new version? 🤔
It looks like this protocol has been sitting in “unstable” for at least 5 years now:
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/tree/main/unstable/primary-selection
Some months ago, they tried to move it (and others) to “staging”:
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/252/diffs#46fa0a22de556f66f7cf1876c4c1817b65f886f5
And that’s where it is now.
I’m not sure what “unstable” actually means in this context, nor “staging”/“stable”. Is there someone actively working on this? How bad is it really if it just sits in “unstable” for years? What are the consequences of a move to “stable” – do clients need to be updated to request the new version? 🤔
It looks like this protocol has been sitting in “unstable” for at least 5 years now:
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/tree/main/unstable/primary-selection
Some months ago, they tried to move it (and others) to “staging”:
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/252/diffs#46fa0a22de556f66f7cf1876c4c1817b65f886f5
And that’s where it is now.
I’m not sure what “unstable” actually means in this context, nor “staging”/“stable”. Is there someone actively working on this? How bad is it really if it just sits in “unstable” for years? What are the consequences of a move to “stable” – do clients need to be updated to request the new version? 🤔
It looks like this protocol has been sitting in “unstable” for at least 5 years now:
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/tree/main/unstable/primary-selection
Some months ago, they tried to move it (and others) to “staging”:
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/252/diffs#46fa0a22de556f66f7cf1876c4c1817b65f886f5
And that’s where it is now.
I’m not sure what “unstable” actually means in this context, nor “staging”/“stable”. Is there someone actively working on this? How bad is it really if it just sits in “unstable” for years? What are the consequences of a move to “stable” – do clients need to be updated to request the new version? 🤔
It was just moist walls, luckily. Never happened before, as far as I can tell. Still, it’s a little disconcerting, yeah. 😅
It was just moist walls, luckily. Never happened before, as far as I can tell. Still, it’s a little disconcerting, yeah. 😅
It was just moist walls, luckily. Never happened before, as far as I can tell. Still, it’s a little disconcerting, yeah. 😅
It was just moist walls, luckily. Never happened before, as far as I can tell. Still, it’s a little disconcerting, yeah. 😅
I had some water in my apartment, too, last week. Different situation, it’s a tower building and I’m far away from ground level. We checked afterwards but we have no idea how that water got in. It was a heavy thunderstorm, so the theory is that the massive air pressure just pushed it in through tiny cracks somewhere …
I had some water in my apartment, too, last week. Different situation, it’s a tower building and I’m far away from ground level. We checked afterwards but we have no idea how that water got in. It was a heavy thunderstorm, so the theory is that the massive air pressure just pushed it in through tiny cracks somewhere …
I had some water in my apartment, too, last week. Different situation, it’s a tower building and I’m far away from ground level. We checked afterwards but we have no idea how that water got in. It was a heavy thunderstorm, so the theory is that the massive air pressure just pushed it in through tiny cracks somewhere …
I had some water in my apartment, too, last week. Different situation, it’s a tower building and I’m far away from ground level. We checked afterwards but we have no idea how that water got in. It was a heavy thunderstorm, so the theory is that the massive air pressure just pushed it in through tiny cracks somewhere …
^C to copy it (it’s called the CLIPBOARD selection). They have intentionally not included the PRIMARY selection of X11 where you can just select some text to copy it and use the middle-mouse button to paste it.Almost 10 years ago, they started an initiative to bring back
PRIMARY:https://wiki.gnome.org/Initiatives/Wayland/PrimarySelection
That protocol is still “unstable” and thus not every Wayland client supports it:
https://wayland.app/protocols/primary-selection-unstable-v1
I honestly didn’t really look into this before and I didn’t know that it’s *still* unstable/unsupported, hence my confusion. (To be fair, I don’t know for certain if that particular protocol is already 10 years old. It looks like it because the copyright notice at the bottom says so, but no idea if that’s a reliable source.)
This is one of those things that are very subjective. The Wayland guys apparently thought that it was a “usability problem” to have two clipboards, so they removed one of them. Actually, the mechanism of X11 is totally generic, there are an “infinite” number of clipboards and we have just settled on using only two.
This is an interesting topic because Wayland is *so old* now that it looks like it has missed the developments of the last ~10 years or more: Way back in the past, I was indeed very confused about the different X11 clipboards because some clients used
CLIPBOARD (hit ^C) and others only used PRIMARY (middle-mouse) – but this has long settled down. *Most* clients now have something like ^C to explicitly copy data into CLIPBOARD and ^V to paste it. It’s the standard thing now. And then *on top of that* power-users can additionally use PRIMARY where you just select text. This is a good and powerful thing, if you ask me.I use both clipboards all the time. My mental model knows where the data goes.
PRIMARY is like a short-term clipboard and CLIPBOARD is long-term. I think this is much better than just having one clipboard and I kind of feel like making good use of this is what keeps me from having to install a clipboard manager.~
^C to copy it (it’s called the CLIPBOARD selection). They have intentionally not included the PRIMARY selection of X11 where you can just select some text to copy it and use the middle-mouse button to paste it.Almost 10 years ago, they started an initiative to bring back
PRIMARY:https://wiki.gnome.org/Initiatives/Wayland/PrimarySelection
That protocol is still “unstable” and thus not every Wayland client supports it:
https://wayland.app/protocols/primary-selection-unstable-v1
I honestly didn’t really look into this before and I didn’t know that it’s *still* unstable/unsupported, hence my confusion. (To be fair, I don’t know for certain if that particular protocol is already 10 years old. It looks like it because the copyright notice at the bottom says so, but no idea if that’s a reliable source.)
This is one of those things that are very subjective. The Wayland guys apparently thought that it was a “usability problem” to have two clipboards, so they removed one of them. Actually, the mechanism of X11 is totally generic, there are an “infinite” number of clipboards and we have just settled on using only two.
This is an interesting topic because Wayland is *so old* now that it looks like it has missed the developments of the last ~10 years or more: Way back in the past, I was indeed very confused about the different X11 clipboards because some clients used
CLIPBOARD (hit ^C) and others only used PRIMARY (middle-mouse) – but this has long settled down. *Most* clients now have something like ^C to explicitly copy data into CLIPBOARD and ^V to paste it. It’s the standard thing now. And then *on top of that* power-users can additionally use PRIMARY where you just select text. This is a good and powerful thing, if you ask me.I use both clipboards all the time. My mental model knows where the data goes.
PRIMARY is like a short-term clipboard and CLIPBOARD is long-term. I think this is much better than just having one clipboard and I kind of feel like making good use of this is what keeps me from having to install a clipboard manager.~
^C to copy it (it’s called the CLIPBOARD selection). They have intentionally not included the PRIMARY selection of X11 where you can just select some text to copy it and use the middle-mouse button to paste it.Almost 10 years ago, they started an initiative to bring back
PRIMARY:https://wiki.gnome.org/Initiatives/Wayland/PrimarySelection
That protocol is still “unstable” and thus not every Wayland client supports it:
https://wayland.app/protocols/primary-selection-unstable-v1
I honestly didn’t really look into this before and I didn’t know that it’s *still* unstable/unsupported, hence my confusion. (To be fair, I don’t know for certain if that particular protocol is already 10 years old. It looks like it because the copyright notice at the bottom says so, but no idea if that’s a reliable source.)
This is one of those things that are very subjective. The Wayland guys apparently thought that it was a “usability problem” to have two clipboards, so they removed one of them. Actually, the mechanism of X11 is totally generic, there are an “infinite” number of clipboards and we have just settled on using only two.
This is an interesting topic because Wayland is *so old* now that it looks like it has missed the developments of the last ~10 years or more: Way back in the past, I was indeed very confused about the different X11 clipboards because some clients used
CLIPBOARD (hit ^C) and others only used PRIMARY (middle-mouse) – but this has long settled down. *Most* clients now have something like ^C to explicitly copy data into CLIPBOARD and ^V to paste it. It’s the standard thing now. And then *on top of that* power-users can additionally use PRIMARY where you just select text. This is a good and powerful thing, if you ask me.I use both clipboards all the time. My mental model knows where the data goes.
PRIMARY is like a short-term clipboard and CLIPBOARD is long-term. I think this is much better than just having one clipboard and I kind of feel like making good use of this is what keeps me from having to install a clipboard manager.~
^C to copy it (it’s called the CLIPBOARD selection). They have intentionally not included the PRIMARY selection of X11 where you can just select some text to copy it and use the middle-mouse button to paste it.Almost 10 years ago, they started an initiative to bring back
PRIMARY:https://wiki.gnome.org/Initiatives/Wayland/PrimarySelection
That protocol is still “unstable” and thus not every Wayland client supports it:
https://wayland.app/protocols/primary-selection-unstable-v1
I honestly didn’t really look into this before and I didn’t know that it’s *still* unstable/unsupported, hence my confusion. (To be fair, I don’t know for certain if that particular protocol is already 10 years old. It looks like it because the copyright notice at the bottom says so, but no idea if that’s a reliable source.)
This is one of those things that are very subjective. The Wayland guys apparently thought that it was a “usability problem” to have two clipboards, so they removed one of them. Actually, the mechanism of X11 is totally generic, there are an “infinite” number of clipboards and we have just settled on using only two.
This is an interesting topic because Wayland is *so old* now that it looks like it has missed the developments of the last ~10 years or more: Way back in the past, I was indeed very confused about the different X11 clipboards because some clients used
CLIPBOARD (hit ^C) and others only used PRIMARY (middle-mouse) – but this has long settled down. *Most* clients now have something like ^C to explicitly copy data into CLIPBOARD and ^V to paste it. It’s the standard thing now. And then *on top of that* power-users can additionally use PRIMARY where you just select text. This is a good and powerful thing, if you ask me.I use both clipboards all the time. My mental model knows where the data goes.
PRIMARY is like a short-term clipboard and CLIPBOARD is long-term. I think this is much better than just having one clipboard and I kind of feel like making good use of this is what keeps me from having to install a clipboard manager.~
https://movq.de/v/0a0969059a/2024-06-25--19-59-29--58376.ogg
Still a noob, but I can see some progress and I enjoy playing very much. 😊
(Use headphones, probably sounds like crap otherwise.)
https://movq.de/v/0a0969059a/2024-06-25--19-59-29--58376.ogg
Still a noob, but I can see some progress and I enjoy playing very much. 😊
(Use headphones, probably sounds like crap otherwise.)
https://movq.de/v/0a0969059a/2024-06-25--19-59-29--58376.ogg
Still a noob, but I can see some progress and I enjoy playing very much. 😊
(Use headphones, probably sounds like crap otherwise.)