I develop an operating system running on bare metal :). It's sort of an appliance, but I don't think Xeons really qualify as embedded.

Codechef appears to use Python 3.1.2 for "Python3", which is pretty old (March 21st, 2010) and predates some significant performance improvements in Python3[0].

[0]: E.g., 3.3 adds a more efficient encoding for ASCII-subset unicode strings: http://docs.python.org/3/whatsnew/3.3.html#performance-and-r...

Fedora 22 is ... 3 releases out? So we're talking about 12-18 months depending on how soon F20 is due to be released. Still, I'm surprised, and I've been a Fedora contributor since FC5.

Or the cold.

Or lack of atmosphere...but I digress. Plus I am sure that latency would be better than earth based sat transmissions

You could use lasers to fix this problem too.

Bandwidth delay product tends to limit throughput at such high latencies, though.

Or FEC, and optionally reliable re-transmission. TCP won't work well due to the huge latencies involved.

TCP can work decently with high latency, it just needs bigger buffers and to be tuned for the delay. FEC is awesome.

The $69 models do N, but not AC :-(.

Edit: oh hello downvote, I'm glad you think AC is worthless to note.

Adblock plugins slurp down new lists without updating the plugin code itself. Newer techniques, sure, but I don't think ABP's release cycle is substantially faster than Firefox's.

Breed until they can't slaughter us all!

> gets in the way of having a deeply-nested project hierarchy"

Do people actually want deeply-nested project hierarchies?

For example, from a real-world, full operating system, the deepest path I can find[0] is in a build directory and 184 characters:

> "./ports/lang/python26/work/Python-2.6.1/portbld.static/build/temp.XXXXXX XXXXX-vHEAD-amd64-2.6/XXXXXX-home/XXXXX.git/src/ports/lang/python26/work/Python-2.6.1/Modules/_multiprocessing"

(Names changed to protect the "innocent.")

[0]:

    $ mkfifo ../names
    $ find . > ../names &
    $ python
    >>> with open("../names") as f:
    ...   l = 0
    ...   nm = None
    ...   for n in f.readlines():
    ...     if len(n) > l: l, nm = len(n), n
    ...   print l, nm

I've often seen normal people come up with deeply nested directory structures with long descriptive names and they get bitten hard by the 260 character limit. For example names like this are very common in my experience:

    C:\Documents and Settings\Joe Random User\My Documents\Some Cloud Software\Company\Projects\2013\156 Big Customer Inc\Locations\Someville Foostreet\Problem reports\2013-10-07 product not working\images\video of product not doing what it's supposed to do.avi

Also:

    find . | python -c 'import sys; print max(sys.stdin.readlines(), key=len)'

The longest I can find on my real-world, full operating system is also a build directory. However it's 349 characters:

    /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_v8/v8/work/v8-3.21.3/out/x64.release/.deps/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_v8/v8/work/v8-3.21.3/out/x64.release/obj.target/v8_base.x64/src/extensions/externalize-string-extension.o.d

That path looks like it's growing exponentially.

Not necessarily want, but I've come across it just by installing a node project into my home folder on XP, something along the lines of:

C:\Documents and Settings\____._______.________\project\node_modules\package\src\tests\somelib\helpers\test123\file.html

What made this troublesome for me is that my networked profile refused to sync while the file was there (and couldn't be removed without renaming each layer to single character folders. Additionally the profile sync failure copied back files I had deleted confusing the heck out of me :)

    $ find / -mindepth 10 | wc -L 
    273

I seem to have some slightly longer file paths on my home computer. Do I need that? Probably not. I could move those files somewhere else. But should I really have to worry about such things?

reached 248 here when run against my home dir. Interestingly the winner is the path to a transitive npm dependency five(!) levels down the dependency tree. The command I used:

    find -mindepth 10 | awk '{ print length(), $0 | "sort -n" }'  | tail

Right now, sure. But suppose some piece of software goes rogue and starts creating dirs and files. Further suppose that there's enough of them to fill the disk. OK, now your disk is full and nothing on the machine works, so you need to delete those deeply-nested files. Except, whoops!, the paths are too long, so you can't delete them with the command line. OK, now you're writing a script or burning some godawful boot CD to try to get to a safe mode or Linux kernel. All in order to delete some silly unnecessary files.

Problems like this aren't problems when everything is working normally. But that's beside the point. When the shit hits the fan and the system is only getting in your way and adding to the problems instead of helping solve them, it's really really really not fun.

I know, when the shit really hits the fan, visual studio is the tool I would use to try and clean up those messy directories.

</sarcasm>. The complaint is about Visual Studio's decision in particular, not the weakness of (some) (old) Win32 APIs.

Or use Cygwin, limited only by the OS (32K path IIRC).

Certain SBT plugins and build settings can generate really deep nested paths under the "target" folder of a project. I think the point of this is to enforce file immutability during the build process - whenever a file is modified by a build stage, a new file is created instead.

I could be completely misunderstanding this though since SBT is fairly complex.

I dont think people do, that doesnt mean it doesnt happen by accident. Until we can get file system as a database, and all of this can be abstracted, it can be a real issue. That said, the target here is a developer - a bit of careful planning can avoid said complications.