I was actually looking for a nicer theme (didn’t find one), but while doing so I also saw that the theme I’m using currently, Minima, didn’t look the same in the official demo as the one I was using. It turns out that this theme has been developing quite a lot on GitHub, but all that development has not been released officially (unofficially it’s referred to as v3), so we cannot use it through the regular channel of installing it as a Gem.

Luckily, it seems there is a way around this. A “remote theme”, activated through the jekyll-remote-theme plugin (add it to your plugins list in _config.yml), is the solution. Instead of specifying the theme in _config.yml, I now have a line saying remote_theme: jekyll/minima. This may look the same, but apparently now it is using the master branch GitHub version.

This theme has a bunch of extra social link icons in the footer, among which Google Scholar and StackOverflow, very nice.

But, of course, the reason I came here was favicons. Who the hell needs any of that social stuff. I just want an awesome favicon and I want it with minimum hassle! And that’s exactly what I get, because now instead of having to maintain a full head template, now there is a custom_head include which is empty and just gets in included in the head part of the HTML. Excellent! I just add a line there to add my favicon to all the pages and there’s no need to keep the rest of the file up to date when the template updates things in the default head include.

In the meantime, I also added back to the site some final permalinks to GIFs that I served from my previous site for my 2019 paper on Barcode (I guess GIPHY might have been a good place for those; oh well). However, it turns out that Minima by default adds links to all “miscellaneous” pages (i.e. everything other than blog posts, I guess) in the header, so all of a sudden I had three weird links with acronyms that nobody understands except those 4 others in the particular scientific niche the paper is about. Luckily, Minima also has a way to shut itself up: we can add a

header_pages:
  - about.markdown

section to _config.yml to make the list explicit.

I think this concludes my move to Jekyll! I’ll probably be tweaking things still in the future, but at least all the files I kept after the export are now used somewhere.

Overall, so far, I like the whole Jekyll experience. Especially writing blogposts in markdown is ideal, although I would like a quick post-generator that autofills dates and title and some other default header stuff, but just copy-pasting the last one works for now. Publishing changes takes a few minutes, because GitHub Actions needs to regenerate the site on every push. Let’s hope I never post my private keys in a blogpost by accident, I guess.

Varoufakis, bekend als Grieks minister van financiën, destijds lid van de Griekse socialisten, beschrijft zichzelf als een libertarische Marxist… Daar gingen mij de oren wel even van klapperen.

In het boek legt Varoufakis vervolgens uit hoe kapitalisme kan werken als systeem om de hele samenleving vooruit te helpen. En hoe het niet werkt, of dat zelfs tegenwerkt.

Kapitalisme werkt als je een bakker bent en je je brood sneller of lekkerder kunt bakken door een betere oven. Het werkt ook als je als broodfabriek een efficiëntere productielijn opzet door slimmere organisatie. In beide gevallen maak je eventjes dikke winst door je innovatie. Het vooruitzicht op die beloning motiveerde je om die verbeteringen te maken, om daarin te investeren. Vrij snel zal de concurrentie je weer inhalen en zal je winst weer op normaal niveau komen om je eigen brood op de plank te brengen. Uiteindelijk is iedereen er beter van geworden: meer of beter brood voor hetzelfde (of minder) geld, top!

Kapitalisme werkt echter niet als je Microsoft bent en 95% van alle computers (in de jaren 90 in elk geval) beheerst en daarom koppelverkoop kunt forceren (alternatieven wordt het moeilijk gemaakt). Of als je Amazon bent en alle goederen via jouw platform verkocht worden (zelfde verhaal). Als het “kapitaal” te groot wordt verdwijnt de concurrentiekracht. Op dat moment kun je je klanten gaan uitpersen; ze hebben geen alternatief. Dan ben je in feite een middeleeuwse landsheer, geen kapitalist. Dit geldt niet alleen voor monopolies, maar ook voor economische kartels.

Een overtuigd, ideologisch kapitalist, die gelooft dat het kapitalisme het beste systeem voor de meeste mensen is, die gelooft dat we daarmee uiteindelijk als collectief en als individuën beter uit zijn dan met elk ander systeem, kan dus geen ongelimiteerd economisch liberalisme steunen. Als je gelooft in kapitalisme, in de kracht van concurrentie en het nastreven van winst door hogere productiviteit, dan moet je absoluut tegen monopolies en kartels zijn. Daarvan weet je zeker dat de drijvende krachten van het kapitalisme verdwenen zijn. Daar worden we als samenleving en als individuën dus niet beter van.

Een overtuigd kapitalist zal monopolies en kartels dus willen tegengaan. Misschien door ze op te knippen. Misschien door als overheid rechtstreeks met monopolisten te concurreren, schaamteloos gesubsidieerd. Misschien door een monopolist aan strenge democratische controle en invloed onderhevig te maken, waardoor je effectief zo’n monopolist onderdeel maakt van de samenleving, een volksorgaan.

Kapitalisten kunnen zo bekeken trouwens zelfs onder een socialistisch systeem bestaan. Zolang er geen 100% winstbelasting of 100% kapitaalbelasting is kun je als individu kapitaal verzamelen. Ok, dit is waarschijnlijk niet het meest ideale kapitalistische stelsel, maar hun punt is: het kan wel.

Dat laat dus zien dat liberalisme en kapitalisme niet onlosmakelijk verbonden zijn, integendeel. Ongelimiteerd liberalisme leidt onvermijdelijk tot monopolies en kartels waardoor het kapitalisme niet meer werkt.

Zou dit geen politieke stroming op zichzelf kunnen zijn? Democratisch kapitalisme?

On January 3rd, I read the specification, which is rather dry stuff. No big surprises here, it just details all the ways in which TypeVarTuples can and cannot be used.

On January 8th (yeah, this is dry stuff, I need days to recuperate), I read the Rational and Rejected Ideas. Interesting to note is that some cases are explicitly not supported by this PEP, but are planned for future PEPs. One example is lack of support for

def repeat_each_element(x: Array[N]) -> Array[2*N]:
    ...

which could actually be a big problem for the ML purposes I have in mind, for instance for preprocessing functions. Another problematic omission is that arbitrary length ranks like batch or time are also planned to be supported “explicitly in a future PEP with a syntax such as Array[Batch, Time, ...]. That’s nice, but doesn’t help right now. Is it crucial? Dunno. Continuing…

The Alternatives section reiterates perfectly and succinctly the need for a static shape checking mechanism. It’s good to read we aren’t the only ones struggling with this.

It also gives some nice pointers to three existing alternative tools that enable dynamic shape checking. That means you have to run code and wait for it to fail, but at least it should then fail at the front and with helpful error messages. For those of you that cannot wait until all this type hint stuff is working, it may be worth looking into these tools. The three they mention are ShapeGuard, tsanley, and PyContracts. I know neither of them, but I applaud their devs for their noble work.

I wonder, by the way, whether in the meantime (i.e. since PEP 646 was published) these projects have included anything from this PEP… A quick GitHub search on their repos doesn’t reveal any hits on keywords PEP and 646, and also the README examples don’t seem to include any 646-like syntax… except PyContracts! It offers three alternative syntaxes, but number two looks a lot like that suggested in PEP 646, except in strings instead of just in plain Python. Given the example, this makes sense, because it goes beyond what 646 intends; PyContracts can also encode numerical lower limits, it seems.

Ok, back to PEP 646.

The next section, Grammar Changes, holds some fun implications as well. Due to the grammar change introduced in this PEP, star-unpacking of iterables can now also be used within brackets. This means we can now also index arrays using star-unpacking, something that wasn’t possible before and that can sometimes lead to very nice shorthand notation. Consider for instance the pre-646, slightly over-dramatic example

index = [1, 1, 2, 3, 5]
some_big_array[index[0], index[1], index[2], index[3], index[4]]

This can now be written

index = [1, 1, 2, 3, 5]
some_big_array[*index]

Noice.

After some uneventful postambles (is that a word?), the first appendix brings some slightly bad news. Yes, we can annotate array shapes, i.e. the numerical sizes of ranks within the shape. This is good. However, we cannot at the same time annotate rank semantics consistently across multiple functions. Unpacking that sentence: when we have two functions annotated as

def f1(a: Array[Batch, Time, Stuff]) -> Array[Batch, Time], Array[Stuff]: ...
def f2(a: Array[Time, Batch, Stuff]) -> Array[Stuff], Array[Batch, Time]: ...

the Batch in f1 has no relation to the Batch in f2 and similarly for Time and Stuff. The scope of these names is purely within the function definitions and has no meaning outside of the scope; the names are used to describe relations between input and output types. In this case, you can pass Literal[64] as one of the rank names to indicate that the array must have a size of 64. Then you also know that one of the output shapes will be 64. Quite useful, but you do lose semantics. If we pass the same array to these two functions, it will be wrong at least one of the times, semantically.

The appendix mentions another usecase where semantics are preserved, for instance by declaring the rank names in the global scope:

class Batch: ...
class Time: ...
class Stuff: ...

Now, the names in f1 and f2 are no longer just names within the functions definitions’ scopes. Arrays must now have these actual classes in their type hints to be allowed to pass them to the functions. However, there is now no way to specify explicit axis sizes.

… although, perhaps it is possible? In the ‘Why not both?’ section, “exploration of this approach” is left “to the future”. One option that the current syntax should allow is to have types with yet another bracketed sub-property that could be used to indicate size, e.g. something like Array[Batch[BatchSize]] where class Batch: ... somehow takes the size in. Who is brave enough to explore this option? Will this work at all in mypy or other checkers? One cannot assume that this syntax will only be used for this, so it will probably require a lot of work to make this work without some additional explicit language support (i.e. moar fancy new syntax).

Finally, on January 22nd, I read the last part of the PEP: appendix B. This discusses why “named tensors” don’t suffice. Xarray and other libraries take this approach of labeling axes with strings. However, you can’t check labels statically, they are dynamic by nature, so they cannot solve the same problems that type annotations do. While labels can certainly be an improvement over plain old meaningless numerical indices, in practice it turns out their usefulness is limited. In DIANNA, we also internally use Xarray and named axes as a first stab at this problem. It solves some problems for now, but also introduces new ones, for instance because there is no support for this approach in other libraries, making it is still quite a hassle to work with.

Conclusion: this is promising stuff. I would love to spend a week trying to get something based on this working…

There were some slight hiccups in between the previous Jekyll post and this one. For some reason (I don’t think I did anything stupid… perhaps it was due to switching out the Jekyll Gem dependency in the Gemfile with the GitHub Pages Gem, as instructed by GitHub… not sure), things broke a bit, and jekyll serve wouldn’t run anymore. I found out that there is a jekyll doctor command that’s supposed to help out when things break, but apparently this was not such a case, because the good doctor sent me home with some aspirine and told me to come back in three months if my head still ached. I also did do a stupid thing btw, which was to try fixing things in a terminal that still had Ruby 3.3 loaded from before I downgraded to 3.2 (see previous post, so the error messages were allround confusing.

In the end (in a fresh, proper terminal), an apt error message told me that <internal:/Users/patrick/.rubies/ruby-3.2.2/lib/ruby/3.2.0/rubygems/core_ext/kernel_require.rb>:37:in require': cannot load such file -- webrick (LoadError). The fix, then, was to explicitly add webrick using bundle add webrick. Done! My jekyll serveing needs could again be fulfilled.

From whence did such needs stem? Foresooth, from getting me a fancy favicon! The default one is unacceptable to a man of my fine tastes, and I’m sure to yours as well, dearest scholar of my humble works.

Unfortunately, I cannot seem to get it in by simply overriding the head include with a appropriate link tag, as suggested here and suggested by common sense as well. Perhaps, though, the issue is simply with jekyll serve and putting it on GitHub will fix things through the use of a proper HTTP server? Let’s try it out, together with this post…

Edit 5 minutes later: nope, something else must be wrong, because as you can see, the favicon is still not being picked up… at least on the home page… But wait! It is in fact there on this very post! Did I add it to the wrong include? Is head not included in all pages? Nope, it does seem to be everywhere… Then what? The other older posts also don’t have it, only this favicon page…

Ok, well, at least something is working. Just gotta find the gremlins later.

Edit another 5 minutes later: ah, it just seems to be a browser cache issue. Favicon up and running!

It makes sense, because people try to build software generically. Nobody wants an image recognition tool that only works on images of 224 by 224 pixels. But, GODDAMNIT, if you do build a tool like that, I want it to fail IMMEDIATELY when I shove my mongrel of an array into its input face. Please, for the love of all that is holy, fail early, so that I know that I am an idiot, do not let me dive into your tool’s (and, usually, your dependencies’) code to figure this out all on my own over a full hour or two. It should be banned under some kind of international convention.

Now, of course, if only things were so simple. Usually, tools don’t hardcode shapes. What could happen instead, for instance, is that generic tools (without fixed shape constraints) basically get configured by one piece of input (the first, a reference item, whatever) and then that determines the kind of input you can feed the code from then on. To get type checking to work on such a code, you would probably have to use some kind of functional programming language or framework. The usual suspects in Python ML world are not that. They do their magic inside their bowels, as befits proper object oriented code. Worry not about my bowel-work, mortal, it doth not concern thine puny brains.

Nevertheless, after having sketched the urgency of the matter (at least to my puny brain), let’s say there are cases where it is possible to specify at the interface side of some function the desired shape. There are then several ways to do so:

1. One could write it in a docstring, but this can become quite tedious when another function in turn needs to copy this information in their docstring and so on. Someone at some point will neglect to include it and gone is your info.
2. One could simply check the input data’s shape dynamically inside the function. In performance critical applications, this is definitely out of the question; a check at every call would be too costly if the call is done a million times in a row. Also, an explicit check in code is kinda ugly and detracts from the actual business code.
3. One could use a language that does have built-in static type checks, hahaha no just kidding.
4. One could try to use type hints…

But do type hints allow for shape definition?

This is the question we asked ourselves in our final project session of the year. Since I’m now on holiday, and apparently I’m a workaholic, I went ahead and started looking into whether there’s already something out there on this front.

Of course, the first go-to stop is to check out what Numpy, the grandparent (a fit kind of grandparent, the kind that just keeps on living actively into their 90s, blatantly defying the laws of aging that ravage normal people, possibly some kind of alien?) of Python arrays, has to offer. Unfortunately, that turns out to be too little for shape typing purposes. Numpy can only say “this is an array of type x”, but nothing about shape or even number of dimensions. (It also has an ArrayLike type, which is nice, but totally irrelevant here.)

Despite this first slight but not unexpected disappointment, the Numpy page did offer one useful hint: they are waiting for everyone to have moved to Python 3.11 (I guess?), because that contains PEP 646: Variadic Generics.

This PEP is literally made for the exact usecase we’re talking about here!

However, it only provides the very basic constructs necessary for making this dream a reality. With this, someone could define a type of array with explicitly named dimensions and even with explicitly sized dimensions, i.e. a fully specified shape. But did someone do this already? And if not, what would it take? Probably defining the type alone is not enough for mypy to be able to check for its usage? For editors to parse it and provide useful hints while editing? Or is it? This is new territory for me.

I’ll be looking into this some more, because it’s sure as hell promising! The pain that a type like this could prevent… Autocompletion and helpful hints inside my editor powered by this, oh man, I can’t wait.

First question is of course whether we can automate this… The amount of content is so low that SURELY this will not pay off. Such is programmer life.

One annoying part of this is that my previous site was bilingual: it had both Dutch and English version pages. I’d still like that, but I think it’s also causing me to write less often than I’d like, so perhaps I should not make this a top priority for now.

A quick Google shows that indeed there’s a convenient Jekyll exporter plugin. Let’s go!

Logging in to my Wordpress admin page, showing me that again there’s a Wordpress update, I’m again strengthened in my resolve for this move. Why complicate a simple website with junk like a database and regular security updates? Who needs security anyway?! I just want to put a few simple pages online… Static files ftw!

Anyway, back to the exporter. It works as advertised (at least on my poorly maintained Wordpress v6.1.1 site) and outputs everything: both Dutch and English page variants, but also some uploaded files and figures I put on the site over the years. Blog posts are already put in a _posts folder and have the proper internal structure for Jekyll to immediately use it in my site’s _posts folder. Neat!

Since I only had a few posts and pages, I manually checked all the files to make sure there’s no nasty stuff in there, and it all seems pretty straightforward. Nice feature: permalinks from the previous website are also kept; they are put into the markdown header. That’s really excellent.

Trying to then step by step adding in the files, starting with

cp ~/Downloads/jekyll-export/_posts/2012-08-28-hoe-wordt-de-rente-op-studieschuld-bepaald.md egpbos.nl/_posts

The link Jekyll generates indeed is domain + permalink, very nice! The image I had in this post is still missing. We get that back in using

cp -r ~/Downloads/jekyll-export/wp-content egpbos.nl/

Unfortunately, this doesn’t fix everything completely. The URL to the image itself is not converted correctly, even though link URLs are. Fixing those manually (just grep -r '!\[' to find all images in the Jekyll export directory) involves just taking off the hardcoded domain names.

Also, since I am a dinosaur, my blogposts used <tt> occasionally instead of backticks, so replaced those here and there.

To keep things clean, you might want to remove empty directories, which the wp-content directory contains a lot of: find wp-content -type d -empty -delete. Also the weird wp-content/uploads/wpcode directory can be removed. And Wordpress generated a lot of thumbnail versions of images that I won’t be needing anymore either: find wp-content -type f -name '*x*' -delete.

The default Jekyll site only gives you a blog frontpage that shows a list of posts. I want to add some content as well, as I had on my previous website. This is as easy as adding content to index.markdown. For now, I’m just dumping both my English and Dutch texts and my portrait there. Can always polish later.

The last remaining pieces of content from my previous website are my CV and publications pages; sort of my portfolio. I’m just going to dump all that stuff in the about page that also conveniently was added in the default Jekyll site. I can’t seem to get the thumbnail image widths adjusted, so it’ll be messy.

Having imported everything, the final steps to get the site online are described well in the GitHub documentation. Done, here we are!

In all honesty, perhaps it was my own fault? Not really sure…

In the end, what fixed my issues (thanks to a hint here: https://www.moncefbelyamani.com/the-definitive-guide-to-installing-ruby-gems-on-a-mac/#keep-using-the-system-ruby-by-changing-the-installation-path-not-recommended) was to remove the .gemrc file that contained –user-install as a default option. This broke my stuff subtly, because it doesn’t play nice with ruby-install? Or at least not the way https://jekyllrb.com/docs/installation/macos/ suggests you use it? I think the point is that –user-install tries to install to .gem, but actually ruby-install expects things under .rubies/[your ruby version]/gems or something like that, so that doth not jive.

No matter how I try, installing Jekyll that way using gem doesn’t give me a runnable executable. If I follow the instructions blindly, I simply get a command not found. If I pay a bit more attention to the warning the gem installation process gives me (“WARNING: You don’t have /Users/patrick/.gem/ruby/3.2.0/bin in your PATH, gem executables will not run.”) and add that to my PATH (even though I’m actually using Ruby 3.2.2… suspicious) then I get an even more obscure error:

/Users/patrick/.rubies/ruby-3.2.2/lib/ruby/site_ruby/3.2.0/rubygems.rb:259:in `find_spec_for_exe': can't find gem jekyll (>= 0.a) with executable jekyll (Gem::GemNotFoundException)
	from /Users/patrick/.rubies/ruby-3.2.2/lib/ruby/site_ruby/3.2.0/rubygems.rb:278:in `activate_bin_path'
	from /Users/patrick/.gem/ruby/3.2.0/bin/jekyll:25:in `<main>'

Bizarre. Of course, the mismatch there in versions is a big red flag, but what is a complete Ruby noob to do?

After finding the aforementioned link, I ended up deleting .gemrc, the entire .gem and .rubies folders (.rubies is where ruby-install installs ruby (btw, why the hell does it have to completely compile the things?! conda ftw)). Then reinstalled ruby with ruby-install… update the chruby command in .zshrc (because the version changed from the previous time), and then redo the jekyll install.

There’s no need for “user-install” this way, because ruby-install is already in your home dir, so a “system-install” is also a user install.

Now stuff worked, finally!

… that is, I could run Jekyll to create a, but serving the site didn’t. Neither the command Jekyll itself suggests (bundle exec jekyll serve) nor the command suggested here (jekyll serve -l, also without -l) worked.

Let’s try ruby-install 3.2 then? 3.3 was only 2 days old at this point, a day after Christmas, so perhaps some bugs still had to be ironed out.

Another day later due to lack of patience to wait for the compilation to finish…

… it works! Had to regenerate the site with jekyll new egpbos.nl, because it complained about missing dependencies when I wouldn’t, but then it all works and jekyll serve -l serves the fresh site on localhost:4000.

Nieuwe plannen voor de vermogensbelasting:

• Nog steeds 30% belasting over een fictief rendement
• Het fictieve rendement wordt nu bepaald aan de hand van rentes van de afgelopen 5 jaar (vergelijkbaar met de berekening van de studieschuldrente)
• Het fictieve rendement wordt progressief, wat in veel gevallen realistischer zal zijn (hoe meer vermogen, hoe meer risico je je kunt permitteren en dus hoe meer rendement over de lange termijn):
  • Schijf 0: t/m € 25k belastingvrij (is nu voor 2015 € 21.330)
  • Schijf 1: € 25k t/m €125k 2,7%
  • Schijf 2: € 125k t/m €1M 4,7%
  • Schijf 3: vanaf € 1M 5,5%

Dit kunnen we vergelijken met de huidige vlaktaks van 30% op 4% fictief rendement. Bij welke vermogens betaal je minder en bij welke betaal je meer in dit nieuwe tarievenschema?

#!/usr/bin/env python
import numpy as np
import scipy.optimize as opt
import matplotlib.pyplot as plt
plt.style.use('ggplot')

b_nieuw = lambda v: 0.3 * ( (0.027 * np.clip(v-25000, 0, 100000)) + (0.047 * np.clip(v-125000, 0, 875000)) + (0.055 * np.max((v-1e6, np.zeros_like(v)), axis=0)) )
b0 = lambda v: 0.3*(0.04 * np.max((np.zeros_like(v), ( v - 21330 )), axis=0) )
x = np.linspace(0, 2e6, 100000)

d_b = lambda v: np.abs(b0(v) - b_nieuw(v))

break_even = opt.fmin(d_b, 200000)[0]

plt.semilogx(x, b0(x), label='oud')
plt.semilogx(x, b_nieuw(x), label='nieuw')

plt.xlim(10000, 2e6)

ylim = plt.ylim()
plt.semilogx((break_even,)*2, (ylim[0], b0(break_even)), 'k--')
plt.semilogx((plt.xlim()[0], break_even), (b0(break_even), b0(break_even)), 'k--')

plt.title(('Break even punt: {0:.2f} euro ({1:.2f} euro belasting)'
           ).format(break_even, b0(break_even)))

plt.grid(b=True, which='both')

plt.legend(loc='best')
plt.show()

Het effectieve percentage belasting dat je over je totale bedrag betaalt ziet er als volgt uit:

# effectieve rente
effectief_0 = b0(x) / x * 100
effectief_nieuw = b_nieuw(x) / x * 100

plt.figure()

plt.semilogx(x, effectief_0, label='oud')
plt.semilogx(x, effectief_nieuw, label='nieuw')

plt.xlim(10000, 2e6)

ylim = plt.ylim()
plt.semilogx((break_even,)*2, (ylim[0], b0(break_even) / break_even * 100), 'k--')
plt.semilogx((plt.xlim()[0], break_even), (b0(break_even) / break_even * 100, b0(break_even) / break_even * 100), 'k--')

plt.title(('Break even punt: {0:.2f} euro ({1:.2f} procent effectieve belasting)'
           ).format(break_even, b0(break_even) / break_even * 100))

plt.grid(b=True, which='both')

plt.legend(loc='best')

plt.show()

Update september 2016:

De plannen gaan in enigszins gewijzigde vorm in 2017 in werking. Voor mensen met een flink vermogen zijn de aanpassingen nog iets minder gunstig dan de oorspronkelijke plannen; zie de figuur hieronder.

Hiervoor kun je in het bovenste stukje Python b_nieuw vervangen met de volgende regels.

# versie 2017:
perc1 = 0.0163
perc2 = 0.055
tarief1 = 0.67 * perc1 + 0.33 * perc2
tarief2 = 0.21 * perc1 + 0.79 * perc2
tarief3 = perc2
b_nieuw = lambda v: 0.3 * ((tarief1 * np.clip(v - 25000, 0, 75000)) +
                           (tarief2 * np.clip(v - 100000, 0, 900000)) +
                           (tarief3 * np.max((v - 1e6, np.zeros_like(v)), axis=0)))

In my case, this seems to be caused by not having extended attributes support on my Linux system. In general, this could be caused by either simply not having enabled it at mount time (there’s a flag for that) or by using NFS which does not support them at all. In my case, it was both and since I’m not root I can’t change either.

If, like me, you’re stuck with such a system and still want to use Dropbox to synchronize from your OS X (which at any moment could strike upon your files with some metadata voodoo) you will need to manually tear out the metadata. The following steps will remedy your syncing issues, at the cost of losing OS X’s precious metadata. Use your Terminal to give the commands (where file is Schrödinger’s file in question):

<pre class="brush: plain; light: true; title: ; notranslate" title="">
mv file file_tmp
xattr -c file_tmp
mv file_tmp file

The xattr -c command removes all extended attributes. The moving might seem useless at first. However, without it, you might find (like I did) that the file still doesn’t sync, despite it having no more metadata. Even when you edit the file itself (e.g. if it’s a text file, add some text) Dropbox doesn’t sync the file to Linux anymore. Perhaps once a file’s “tainted”, Dropbox flags it as forever unusable for unsuitable file systems.

In any case, a little moving around makes Dropbox forget all about it’s past transgressions and starts syncing it just fine again. That is, until OS X does its black magic again and you can start all over. Perhaps scripting the above would be a good idea, but we leave that as an exercise to the reader.

Error opening terminal: unknown.

I found a related question on Stack Overflow. Adding a TERM environment variable turned out to be the solution. To do this in Condor, add a line like this to your Condor script:

environment    = "TERM=xterm"

If you want to add more variables, just use a space to separate them inside the quotation marks.