<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Hacker News: marmight</title><link>https://news.ycombinator.com/user?id=marmight</link><description>Hacker News RSS</description><docs>https://hnrss.org/</docs><generator>hnrss v2.1.1</generator><lastBuildDate>Thu, 23 Apr 2026 08:46:25 +0000</lastBuildDate><atom:link href="https://hnrss.org/user?id=marmight" rel="self" type="application/rss+xml"></atom:link><item><title><![CDATA[New comment by marmight in "X.org Security Advisory: multiple security issues X.Org X server and Xwayland"]]></title><description><![CDATA[
<p>Even a compositor is unnecessary to fix screen tearing these days: <a href="https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1006" rel="nofollow">https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests...</a></p>
]]></description><pubDate>Sun, 02 Nov 2025 21:55:54 +0000</pubDate><link>https://news.ycombinator.com/item?id=45793779</link><dc:creator>marmight</dc:creator><comments>https://news.ycombinator.com/item?id=45793779</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=45793779</guid></item><item><title><![CDATA[New comment by marmight in "Homomorphic encryption in iOS 18"]]></title><description><![CDATA[
<p>It depends which features you need, but interestingly Google has <i>another</i>, lighter weight gallery app called Google Gallery that does not have any cloud features built in.</p>
]]></description><pubDate>Wed, 15 Jan 2025 13:18:49 +0000</pubDate><link>https://news.ycombinator.com/item?id=42710465</link><dc:creator>marmight</dc:creator><comments>https://news.ycombinator.com/item?id=42710465</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=42710465</guid></item><item><title><![CDATA[New comment by marmight in "Self-experiment with L-theanine: effect on sleep and cognition"]]></title><description><![CDATA[
<p>I would have liked to have seen if there was any difference in the effects over time. I think it is easy to find something that helps with anxiety in the short term, but over enough time habituation, tolerance, and dependence can develop to most substances.</p>
]]></description><pubDate>Mon, 07 Oct 2024 17:15:48 +0000</pubDate><link>https://news.ycombinator.com/item?id=41768326</link><dc:creator>marmight</dc:creator><comments>https://news.ycombinator.com/item?id=41768326</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=41768326</guid></item><item><title><![CDATA[New comment by marmight in "I found an 8 years old bug in Xorg"]]></title><description><![CDATA[
<p>I don't know if it is sufficient to prevent the race, but the article does mention that they check for DestroyNotify events after the grab.</p>
]]></description><pubDate>Sun, 23 Jun 2024 16:43:06 +0000</pubDate><link>https://news.ycombinator.com/item?id=40768717</link><dc:creator>marmight</dc:creator><comments>https://news.ycombinator.com/item?id=40768717</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=40768717</guid></item><item><title><![CDATA[New comment by marmight in "The Scientific Method Part 5: Illusions, Delusions, and Dreams"]]></title><description><![CDATA[
<p>> I wonder if there's some nuance missed here. The natural follow-up question in my head is: can the scientific method ever support a supernatural explanation? What could such an explanation look like? How could it have predictive power whilst maintaining its supernaturalness?<p>In principle religious prophecy could fit the bill.  You could imagine a surprising and unambiguous religious prophecy about a future event, such as that the Yellowstone Caldera will erupt in February of 2025.  If a series of such prophecies were successfully made about various events spanning a variety of disciplines or topics, each attributing the knowledge to the same deity, it would be difficult for me to not attribute the predictions to the supernatural.<p>In practice though, religious prophecy tends to either fail in being surprising or in being unambiguous.  And when it is not unambiguous, it is not falsifiable.<p>edit: I would also add that it is important that the prophecy be about something that is independently verifiable as well.</p>
]]></description><pubDate>Thu, 02 May 2024 12:28:21 +0000</pubDate><link>https://news.ycombinator.com/item?id=40235386</link><dc:creator>marmight</dc:creator><comments>https://news.ycombinator.com/item?id=40235386</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=40235386</guid></item><item><title><![CDATA[New comment by marmight in "Porting to GCC 14: C language issues"]]></title><description><![CDATA[
<p><p><pre><code>  > The corrected standard C source code might look like this (still disregarding error handling and short writes):
  >
  >  void
  >  write_string (int fd, const char \*s)
  >  {
  >    write (1, s, strlen (s));
  >  }
</code></pre>
And disregarding the passed file descriptor! :)</p>
]]></description><pubDate>Mon, 19 Feb 2024 19:05:57 +0000</pubDate><link>https://news.ycombinator.com/item?id=39433414</link><dc:creator>marmight</dc:creator><comments>https://news.ycombinator.com/item?id=39433414</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=39433414</guid></item><item><title><![CDATA[New comment by marmight in "In surprise move, Gentoo Linux starts offering binaries"]]></title><description><![CDATA[
<p>Gentoo has an amazingly awesome feature where you can maintain your own patches  against packages in the Gentoo package system [1]. This feature can be useful when the corresponding upstream project is on life support, obstinate, you have eccentric desires, or otherwise your (or someone else's) patch has not been accepted upstream. The patched package will still continue to automatically receive updates with the patch automatically applied over time (at least as long as the patch can be applied without errors -- some maintenance may be required).<p>[1] <a href="https://wiki.gentoo.org/wiki//etc/portage/patches" rel="nofollow">https://wiki.gentoo.org/wiki//etc/portage/patches</a><p>I wish I knew more about NixOS or Guix -- do they have an equivalent feature?</p>
]]></description><pubDate>Thu, 04 Jan 2024 23:07:14 +0000</pubDate><link>https://news.ycombinator.com/item?id=38873574</link><dc:creator>marmight</dc:creator><comments>https://news.ycombinator.com/item?id=38873574</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=38873574</guid></item><item><title><![CDATA[New comment by marmight in "A cartographer drew a freehand map of North America (2019)"]]></title><description><![CDATA[
<p>It is labeled correctly on his map, but he is recorded as saying something incorrect in the article:<p>> Also Baffin Island in Greenland. So few people have been to that part of the world.<p>Baffin Island is in Canada.  Since this would be something silly for a cartographer to get wrong, I wonder if he didn't actually say "Baffin Island <i>and</i> Greenland" and his response was incorrectly transcripted.</p>
]]></description><pubDate>Sun, 24 Dec 2023 12:54:46 +0000</pubDate><link>https://news.ycombinator.com/item?id=38753164</link><dc:creator>marmight</dc:creator><comments>https://news.ycombinator.com/item?id=38753164</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=38753164</guid></item><item><title><![CDATA[New comment by marmight in "Wayland vs. X – Overview"]]></title><description><![CDATA[
<p>The tearing situation has also recently improved [1,2,3] in X.org, including your cited use case of multiple, rotated monitors, and even if you are not using a compositor, although these improvements are only present in the latest master branch and aren't in any release and thus not shipped by most Linux distributions.  I'm sure that the argument could be made about how Wayland still solves the tearing problem more optimally, and I think you should stick with Wayland if you are happy with it, but the tearing situation has improved dramatically on the X side of things since Wayland as well.<p>[1] <a href="https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1006" rel="nofollow noreferrer">https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests...</a><p>[2] <a href="https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1042" rel="nofollow noreferrer">https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests...</a><p>[3] <a href="https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1224" rel="nofollow noreferrer">https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests...</a></p>
]]></description><pubDate>Wed, 20 Dec 2023 15:09:15 +0000</pubDate><link>https://news.ycombinator.com/item?id=38709459</link><dc:creator>marmight</dc:creator><comments>https://news.ycombinator.com/item?id=38709459</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=38709459</guid></item><item><title><![CDATA[New comment by marmight in "The Linux graphics stack in a nutshell"]]></title><description><![CDATA[
<p>Tearing has more-or-less been fixed [1,2,3] in the latest version of X.org, although these changes are only present in the latest master branch and aren't in any official release and thus not shipped by most Linux distributions.  I'm sure the argument could be made about how these are just more kluges and how Wayland solves this problem more optimally, but the argument to switch to Wayland to not experience anymore tearing is weaker than it has ever been.<p>[1] <a href="https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1006" rel="nofollow noreferrer">https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests...</a><p>[2] <a href="https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1042" rel="nofollow noreferrer">https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests...</a><p>[3] <a href="https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1224" rel="nofollow noreferrer">https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests...</a></p>
]]></description><pubDate>Wed, 20 Dec 2023 14:02:38 +0000</pubDate><link>https://news.ycombinator.com/item?id=38708779</link><dc:creator>marmight</dc:creator><comments>https://news.ycombinator.com/item?id=38708779</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=38708779</guid></item><item><title><![CDATA[New comment by marmight in "Chrome may start restricting requests to private networks"]]></title><description><![CDATA[
<p>In general, an idempotent method is a method such that calling it one time is the same as calling it n times in a row for any n > 1.  However, idempotency doesn't require that calling the method one time is the same as calling it <i>zero</i> times, although such a method isn't excluded from the definition either.  So a stateless method is necessarily idempotent, but an idempotent method isn't necessarily stateless.</p>
]]></description><pubDate>Tue, 16 Nov 2021 15:37:16 +0000</pubDate><link>https://news.ycombinator.com/item?id=29241693</link><dc:creator>marmight</dc:creator><comments>https://news.ycombinator.com/item?id=29241693</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=29241693</guid></item><item><title><![CDATA[New comment by marmight in "Apple censors engraving service, report claims"]]></title><description><![CDATA[
<p>Some of the words Apple filters in China include 人权 (human rights), 正法 (dharma), 達賴 (Dalai [Lama]), 新聞自由 (Freedom of the press), and 艾未未 (Ai Weiwei [an artist and political dissident]). [1] There is no equivalent to these kinds of words in the US filter.<p>[1] <a href="https://citizenlab.ca/2021/08/engrave-danger-an-analysis-of-apple-engraving-censorship-across-six-regions/" rel="nofollow">https://citizenlab.ca/2021/08/engrave-danger-an-analysis-of-...</a></p>
]]></description><pubDate>Wed, 18 Aug 2021 19:57:21 +0000</pubDate><link>https://news.ycombinator.com/item?id=28226311</link><dc:creator>marmight</dc:creator><comments>https://news.ycombinator.com/item?id=28226311</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=28226311</guid></item><item><title><![CDATA[New comment by marmight in "Posix Threads Programming"]]></title><description><![CDATA[
<p>For folks interested in threads in C, I also recommend reading "Threads Cannot be Implemented as a Library" [1].  The summary is that Pthreads mostly works correctly as a library (1) because its functions execute memory fence instructions and (2) because its functions are treated as opaque functions by the C compiler, i.e., functions that might read or write from any global variable.  However, these properties do not generate thread-safe code under a number of conditions such as under the presence of certain compiler optimizations.  Thus, the paper argues that the compiler must be aware of threads and that threads cannot be implemented purely as a library.<p>[1] <a href="https://www.hpl.hp.com/techreports/2004/HPL-2004-209.pdf" rel="nofollow">https://www.hpl.hp.com/techreports/2004/HPL-2004-209.pdf</a></p>
]]></description><pubDate>Wed, 10 Feb 2021 13:55:39 +0000</pubDate><link>https://news.ycombinator.com/item?id=26089061</link><dc:creator>marmight</dc:creator><comments>https://news.ycombinator.com/item?id=26089061</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=26089061</guid></item><item><title><![CDATA[New comment by marmight in "How the Chinese Government Fakes Social Media Posts for Strategic Distraction [pdf]"]]></title><description><![CDATA[
<p>The authors are overstating their case when they assume that why the 50 cent party posters are not engaging in discussion must be a result of an intentional Chinese government strategy.  The moniker "50 cent party" comes from the idea that the members make 50 cents for each post they make.  They aren't really making 50 cents per post, but if they are operating in a system which incentivizes them to make more posts, then they are not going to engage in discussion because that takes too much time.  To get a higher post count it is easier to spam cheerleading posts that would be appropriate in any discussion context.  The more simple explanation for the observed behavior is human nature rather than an intentional Chinese government strategy.</p>
]]></description><pubDate>Wed, 15 Nov 2017 23:23:37 +0000</pubDate><link>https://news.ycombinator.com/item?id=15708992</link><dc:creator>marmight</dc:creator><comments>https://news.ycombinator.com/item?id=15708992</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=15708992</guid></item><item><title><![CDATA[New comment by marmight in "Unexecute"]]></title><description><![CDATA[
<p>Some previous discussion here: <a href="https://news.ycombinator.com/item?id=11001796" rel="nofollow">https://news.ycombinator.com/item?id=11001796</a></p>
]]></description><pubDate>Thu, 28 Jul 2016 17:36:13 +0000</pubDate><link>https://news.ycombinator.com/item?id=12181740</link><dc:creator>marmight</dc:creator><comments>https://news.ycombinator.com/item?id=12181740</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=12181740</guid></item><item><title><![CDATA[New comment by marmight in "Reversing the Petya ransomware with constraint solvers"]]></title><description><![CDATA[
<p>You're right insofar as you can't use the chroot command to escape a "chroot jail" because it automatically calls chdir() for you, but any root user can escape one by invoking the following linux system calls:<p><pre><code>  chdir("/"); /* go to / of "chroot jail" */
  mkdir("foo", ...); /* create directory in jail */
  chroot("foo"); /* change / to foo */
  /* fail to chdir("foo"); */
  chdir(".."); /* instead go up parent (there is nothing preventing you since you are no longer in the "chroot jail" since the jail is now foo and you never entered it) */
  chdir("..");
  /* ... */
  chdir(".."); /* . is now the real root */
  chroot("."); /* change / to the real root */
</code></pre>
This is why the man pages for the linux system call rightfully put "chroot jail" in scare quotes.  They are trivially escaped by a root user making basic linux system calls, and the man pages even sketch out how for you.  Some operating systems attempt to provide more secure chroot jails, but linux chroot() does not provide this.</p>
]]></description><pubDate>Sun, 24 Apr 2016 02:55:10 +0000</pubDate><link>https://news.ycombinator.com/item?id=11558364</link><dc:creator>marmight</dc:creator><comments>https://news.ycombinator.com/item?id=11558364</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=11558364</guid></item><item><title><![CDATA[New comment by marmight in "Reversing the Petya ransomware with constraint solvers"]]></title><description><![CDATA[
<p>Are you sure it's not even more trivially vulnerable than that?  From man 2 chroot:<p><i>This call does not change the current working directory, so that after the call '.' can be outside the tree rooted at '/'.  In particular, the superuser can escape from a "chroot jail" by doing:</i><p><i>mkdir foo; chroot foo; cd ..</i></p>
]]></description><pubDate>Sat, 23 Apr 2016 23:22:50 +0000</pubDate><link>https://news.ycombinator.com/item?id=11557856</link><dc:creator>marmight</dc:creator><comments>https://news.ycombinator.com/item?id=11557856</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=11557856</guid></item></channel></rss>