<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0">
  <channel>
    <title>Aus der Tiefe</title>
    <link>https://adminblog.math.fau.de/bauerm/2021/10/07/index.rss/bauerm</link>
    <description>Meldungen des Rechenzentrums in der Cauerstrasse 11</description>
    <language>de</language>
    <docs>http://blogs.law.harvard.edu/tech/rss</docs>
    <generator>blosxom/2.1.2</generator>

  <item>
    <title></title>
    <pubDate>Thu, 07 Oct 2021 00:00:00 +0200</pubDate>
    <link>https://adminblog.math.fau.de/bauerm/2021/10/07/index.rss/2021/10/07#ThursdayOctober7202114:14:50</link>
    <category>/bauerm</category>
    <guid isPermaLink="false">https://adminblog.math.fau.de/bauerm/2021/10/07/index.rss/bauerm/ThursdayOctober7202114:14:50</guid>
    <description>&lt;pre&gt;
	Wordpress, das Blogging Framework

	Wenn man in Wordpress&amp;trade; einen Blogeintrag mit post_name = &lt;em&gt;Mein Sommerurlaub 2021&lt;/em&gt; macht,
	und ein paar Tage sp&amp;auml;ter einen mit post_name = &lt;em&gt;Mein Sommerurlaub 2021&lt;/em&gt;, dann &amp;uuml;berschreibt
	der zweite den ersten. Und das ist OK so, weil das ist ein Blog Eintrag, und wenns einen neuen
	gleichen Namens gibt, dann soll der den alten ersetzen.
	
	Wenn man ein Kalender-Plugin in Wordpress einbaut, dessen &lt;b&gt;ENDPOINT&lt;/b&gt;
	&lt;em&gt;Events&lt;/em&gt; heisst, sieht man unter $url/events und $url/index.php/events den aktuellen
	Kalender, genau wie erwartet.

	Wenn danach jemand ein Posting anlegt, dass &lt;em&gt;Events&lt;/em&gt; heisst, dann ist der Kalender weg,
	und man sieht statt dessen dieses Posting. Weniger OK, das.
	
	Es n&amp;uuml;tzt nichts, das Posting umzubenennen. Ich hab knietief in DB-Dumps gew&amp;uuml;hlt,
	um den Eintrag zu finden, der die rewrite-rule vom Kalender kaputtmacht, und nix gefunden.
	Wenn man das Posting, das mal &lt;em&gt;Events&lt;/em&gt; hiess, aber kopiert und dann l&amp;ouml;scht,
	funktionierts wieder. Weissderhimmelwarum...

&lt;/pre&gt;</description>
  </item>
  <item>
    <title></title>
    <pubDate>Thu, 07 Oct 2021 00:00:00 +0200</pubDate>
    <link>https://adminblog.math.fau.de/bauerm/2021/10/07/index.rss/2021/10/07#ThursdayOctober7202115:25:26</link>
    <category>/bauerm</category>
    <guid isPermaLink="false">https://adminblog.math.fau.de/bauerm/2021/10/07/index.rss/bauerm/ThursdayOctober7202115:25:26</guid>
    <description>&lt;pre&gt;
        Nachtrag zu dem &lt;a href=&quot;https://adminblog.math.fau.de/2021/09/15&quot;&gt;SIGILL in libopenblas&lt;/a&gt;
        Post: Die libopenblas ist laut
           SageMath/build/pkgs/openblas/spkg-install.in
        mit
	   DYNAMIC_ARCH=1
	gebaut. D.h. die sollte alle Architekturen koennen. Man kann der openblas mitgeben,
	welche man moechte, und zwar mit 
	   OPENBLAS_CORETYPE=$ARCH
	wobei ARCH den hippen West-coast Intel-Codenamen angibt (&lt;em&gt;Sandybridge, Skylake, Nehalem, ...&lt;/em&gt;)
	Aber: das einzige, was sich aendert, wenn ich auf einem Sandybridge-Xeon das Sagemath
	mit 
	 env OPENBLAS_CORETYPE=Sandybridge 
	starte (und dann &lt;em&gt;plot(cos(x), (x,0,10))&lt;/em&gt; ausfuehrn lasse), ist,
	dass im Stacktrace nach dem SIGILL jetzt
	  /software/sagemath/.../lib/libopenblas.so.0(sdot_k_SANDYBRIDGE+0xfd)
	statt
	  /software/sagemath/.../lib/libopenblas.so.0(sdot_k_NEHALEM+0xfd)
	steht. Man fragt sich...
   
&lt;/pre&gt;</description>
  </item>
  </channel>
</rss>
