curl -s -H 'Accept: application/json' https://twtxt.net/twt/mowsvgq
This gets you a twt which, when hashed again *now* using all the information from that API reply, does not yield the hash
mowsvgq but bjs6aua.But when you use the URL http://prismdragon.net/twtxt.txt for hashing instead of http://twtxt.prismdragon.net/twtxt.txt, it’s
mowsvgq.So I would expect Yarn to *either* know about
mowsvgq (showing the new URL http://prismdragon.net/twtxt.txt) *or* about bjs6aua (showing the old URL http://twtxt.prismdragon.net/twtxt.txt). But not mowsvgq with the old URL. 😅I don’t see how the second
# url = metadata field is relevant here. 🤔
curl -s -H 'Accept: application/json' https://twtxt.net/twt/mowsvgq
This gets you a twt which, when hashed again *now* using all the information from that API reply, does not yield the hash
mowsvgq but bjs6aua.But when you use the URL http://prismdragon.net/twtxt.txt for hashing instead of http://twtxt.prismdragon.net/twtxt.txt, it’s
mowsvgq.So I would expect Yarn to *either* know about
mowsvgq (showing the new URL http://prismdragon.net/twtxt.txt) *or* about bjs6aua (showing the old URL http://twtxt.prismdragon.net/twtxt.txt). But not mowsvgq with the old URL. 😅I don’t see how the second
# url = metadata field is relevant here. 🤔
curl -s -H 'Accept: application/json' https://twtxt.net/twt/mowsvgq
This gets you a twt which, when hashed again *now* using all the information from that API reply, does not yield the hash
mowsvgq but bjs6aua.But when you use the URL http://prismdragon.net/twtxt.txt for hashing instead of http://twtxt.prismdragon.net/twtxt.txt, it’s
mowsvgq.So I would expect Yarn to *either* know about
mowsvgq (showing the new URL http://prismdragon.net/twtxt.txt) *or* about bjs6aua (showing the old URL http://twtxt.prismdragon.net/twtxt.txt). But not mowsvgq with the old URL. 😅I don’t see how the second
# url = metadata field is relevant here. 🤔
curl -s -H 'Accept: application/json' https://twtxt.net/twt/mowsvgq
This gets you a twt which, when hashed again *now* using all the information from that API reply, does not yield the hash
mowsvgq but bjs6aua.But when you use the URL http://prismdragon.net/twtxt.txt for hashing instead of http://twtxt.prismdragon.net/twtxt.txt, it’s
mowsvgq.So I would expect Yarn to *either* know about
mowsvgq (showing the new URL http://prismdragon.net/twtxt.txt) *or* about bjs6aua (showing the old URL http://twtxt.prismdragon.net/twtxt.txt). But not mowsvgq with the old URL. 😅I don’t see how the second
# url = metadata field is relevant here. 🤔
uri field for this twt in its database, I guess? Disclaimer: I know nothing about the internals of Yarn. 😅
uri field for this twt in its database, I guess? Disclaimer: I know nothing about the internals of Yarn. 😅
uri field for this twt in its database, I guess? Disclaimer: I know nothing about the internals of Yarn. 😅
uri field for this twt in its database, I guess? Disclaimer: I know nothing about the internals of Yarn. 😅
Yarn’s API says that twt comes from the URL http://twtxt.prismdragon.net/twtxt.txt – but when using that URL for hashing, I get the hash
bjs6aua instead of mowsvgq. That’s not the correct hash, so jenny says the twt could not be found.Inspecting the feed using
jenny -D … yields the correct hash. When looking at the raw feed, we can see:
# nick = gallowsgryph
# description = Green living and permaculture enthusiast, writer, otherkin, weird.
# url = http://prismdragon.net/twtxt.txt
# url = https://dreamwidth.org/gallowsgryph/
# avatar = http://prismdragon.net/img/gallows.png#20241025
So it’s a different URL. When I use http://prismdragon.net/twtxt.txt for hashing, I get the correct hash.
Yarn’s API says that twt comes from the URL http://twtxt.prismdragon.net/twtxt.txt – but when using that URL for hashing, I get the hash
bjs6aua instead of mowsvgq. That’s not the correct hash, so jenny says the twt could not be found.Inspecting the feed using
jenny -D … yields the correct hash. When looking at the raw feed, we can see:
# nick = gallowsgryph
# description = Green living and permaculture enthusiast, writer, otherkin, weird.
# url = http://prismdragon.net/twtxt.txt
# url = https://dreamwidth.org/gallowsgryph/
# avatar = http://prismdragon.net/img/gallows.png#20241025
So it’s a different URL. When I use http://prismdragon.net/twtxt.txt for hashing, I get the correct hash.
Yarn’s API says that twt comes from the URL http://twtxt.prismdragon.net/twtxt.txt – but when using that URL for hashing, I get the hash
bjs6aua instead of mowsvgq. That’s not the correct hash, so jenny says the twt could not be found.Inspecting the feed using
jenny -D … yields the correct hash. When looking at the raw feed, we can see:
# nick = gallowsgryph
# description = Green living and permaculture enthusiast, writer, otherkin, weird.
# url = http://prismdragon.net/twtxt.txt
# url = https://dreamwidth.org/gallowsgryph/
# avatar = http://prismdragon.net/img/gallows.png#20241025
So it’s a different URL. When I use http://prismdragon.net/twtxt.txt for hashing, I get the correct hash.
Yarn’s API says that twt comes from the URL http://twtxt.prismdragon.net/twtxt.txt – but when using that URL for hashing, I get the hash
bjs6aua instead of mowsvgq. That’s not the correct hash, so jenny says the twt could not be found.Inspecting the feed using
jenny -D … yields the correct hash. When looking at the raw feed, we can see:
# nick = gallowsgryph
# description = Green living and permaculture enthusiast, writer, otherkin, weird.
# url = http://prismdragon.net/twtxt.txt
# url = https://dreamwidth.org/gallowsgryph/
# avatar = http://prismdragon.net/img/gallows.png#20241025
So it’s a different URL. When I use http://prismdragon.net/twtxt.txt for hashing, I get the correct hash.
avatar field has a #20240102 at the end: To trick yarnd into reloading it.
avatar field has a #20240102 at the end: To trick yarnd into reloading it.
avatar field has a #20240102 at the end: To trick yarnd into reloading it.
avatar field has a #20240102 at the end: To trick yarnd into reloading it.
https://www.youtube.com/watch?v=PeuH0YmWkI4
💛
https://www.youtube.com/watch?v=PeuH0YmWkI4
💛
https://www.youtube.com/watch?v=PeuH0YmWkI4
💛
https://www.youtube.com/watch?v=PeuH0YmWkI4
💛
https://rachelbythebay.com/w/2018/03/15/core/
It’s just that this also happens locally nowadays and, thus, much easier and more often (I bet few people run programs via NFS these days). 🫤
Not a fan of this. (Time will tell if I have the energy to discuss this on the Linux kernel mailing list.)
https://rachelbythebay.com/w/2018/03/15/core/
It’s just that this also happens locally nowadays and, thus, much easier and more often (I bet few people run programs via NFS these days). 🫤
Not a fan of this. (Time will tell if I have the energy to discuss this on the Linux kernel mailing list.)
https://rachelbythebay.com/w/2018/03/15/core/
It’s just that this also happens locally nowadays and, thus, much easier and more often (I bet few people run programs via NFS these days). 🫤
Not a fan of this. (Time will tell if I have the energy to discuss this on the Linux kernel mailing list.)
https://rachelbythebay.com/w/2018/03/15/core/
It’s just that this also happens locally nowadays and, thus, much easier and more often (I bet few people run programs via NFS these days). 🫤
Not a fan of this. (Time will tell if I have the energy to discuss this on the Linux kernel mailing list.)
Take this, for example:
https://codeberg.org/dwl/dwl/src/branch/main/Makefile#L64
The
install target of a Wayland compositor uses cp to copy the compiled binary to your bin directory. So, as of Linux 6.11, when you recompile this compositor and reinstall it, it will crash your entire Wayland session. 🧟💀🧟One way to avoid this crash is to use install instead of
cp. install calls unlink() before copying the data, thus avoiding this situation entirely. Not all Makefiles do that, though.
Take this, for example:
https://codeberg.org/dwl/dwl/src/branch/main/Makefile#L64
The
install target of a Wayland compositor uses cp to copy the compiled binary to your bin directory. So, as of Linux 6.11, when you recompile this compositor and reinstall it, it will crash your entire Wayland session. 🧟💀🧟One way to avoid this crash is to use install instead of
cp. install calls unlink() before copying the data, thus avoiding this situation entirely. Not all Makefiles do that, though.
Take this, for example:
https://codeberg.org/dwl/dwl/src/branch/main/Makefile#L64
The
install target of a Wayland compositor uses cp to copy the compiled binary to your bin directory. So, as of Linux 6.11, when you recompile this compositor and reinstall it, it will crash your entire Wayland session. 🧟💀🧟One way to avoid this crash is to use install instead of
cp. install calls unlink() before copying the data, thus avoiding this situation entirely. Not all Makefiles do that, though.
Take this, for example:
https://codeberg.org/dwl/dwl/src/branch/main/Makefile#L64
The
install target of a Wayland compositor uses cp to copy the compiled binary to your bin directory. So, as of Linux 6.11, when you recompile this compositor and reinstall it, it will crash your entire Wayland session. 🧟💀🧟One way to avoid this crash is to use install instead of
cp. install calls unlink() before copying the data, thus avoiding this situation entirely. Not all Makefiles do that, though.
- https://lwn.net/Articles/982034/
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2a010c412853
> Matching the behavior of most Unix systems, the Linux kernel has traditionally prevented writes to an executable file that is in use by a process somewhere in the system; that is the source of the "text file busy" message that some readers may have seen. This restriction is intended to prevent unpleasant surprises in running programs. Kernel developers have been phasing out this restriction for a few years, mostly because it does not really protect anything. As of 6.11, the kernel will no longer prevent writes to busy executable files; see this changelog for a lot more details.
Hm.
- https://lwn.net/Articles/982034/
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2a010c412853
> Matching the behavior of most Unix systems, the Linux kernel has traditionally prevented writes to an executable file that is in use by a process somewhere in the system; that is the source of the "text file busy" message that some readers may have seen. This restriction is intended to prevent unpleasant surprises in running programs. Kernel developers have been phasing out this restriction for a few years, mostly because it does not really protect anything. As of 6.11, the kernel will no longer prevent writes to busy executable files; see this changelog for a lot more details.
Hm.
- https://lwn.net/Articles/982034/
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2a010c412853
> Matching the behavior of most Unix systems, the Linux kernel has traditionally prevented writes to an executable file that is in use by a process somewhere in the system; that is the source of the "text file busy" message that some readers may have seen. This restriction is intended to prevent unpleasant surprises in running programs. Kernel developers have been phasing out this restriction for a few years, mostly because it does not really protect anything. As of 6.11, the kernel will no longer prevent writes to busy executable files; see this changelog for a lot more details.
Hm.
- https://lwn.net/Articles/982034/
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2a010c412853
> Matching the behavior of most Unix systems, the Linux kernel has traditionally prevented writes to an executable file that is in use by a process somewhere in the system; that is the source of the "text file busy" message that some readers may have seen. This restriction is intended to prevent unpleasant surprises in running programs. Kernel developers have been phasing out this restriction for a few years, mostly because it does not really protect anything. As of 6.11, the kernel will no longer prevent writes to busy executable files; see this changelog for a lot more details.
Hm.
text file busy. Example:First terminal:
$ cc -Wall -Wextra -o test test.c
$ cp test run
$ ./run
Second terminal:
$ cp test run
cp: cannot create regular file 'run': Text file busy
But on my machines today, it *crashes* the running program. 🤨 As soon as I run the
cp, I get a coredump:$ ./run
... time passes, I do "cp test run" in a second terminal ...
Bus error (core dumped)
How odd. Another mystery to solve …
text file busy. Example:First terminal:
$ cc -Wall -Wextra -o test test.c
$ cp test run
$ ./run
Second terminal:
$ cp test run
cp: cannot create regular file 'run': Text file busy
But on my machines today, it *crashes* the running program. 🤨 As soon as I run the
cp, I get a coredump:$ ./run
... time passes, I do "cp test run" in a second terminal ...
Bus error (core dumped)
How odd. Another mystery to solve …
text file busy. Example:First terminal:
$ cc -Wall -Wextra -o test test.c
$ cp test run
$ ./run
Second terminal:
$ cp test run
cp: cannot create regular file 'run': Text file busy
But on my machines today, it *crashes* the running program. 🤨 As soon as I run the
cp, I get a coredump:$ ./run
... time passes, I do "cp test run" in a second terminal ...
Bus error (core dumped)
How odd. Another mystery to solve …
text file busy. Example:First terminal:
$ cc -Wall -Wextra -o test test.c
$ cp test run
$ ./run
Second terminal:
$ cp test run
cp: cannot create regular file 'run': Text file busy
But on my machines today, it *crashes* the running program. 🤨 As soon as I run the
cp, I get a coredump:$ ./run
... time passes, I do "cp test run" in a second terminal ...
Bus error (core dumped)
How odd. Another mystery to solve …