Microsoft Has Manually Patched Their Equation Editor Executable - <AUTHOR> https://0patch.blogspot.com/2017/11/did-microsoft-just-manually-patch-their.html <comment><USER2> Notice the xchg, stosb and a loop instruction. This was definitely written by a skilled Asm programmer --- I've never seen even a compiler at -Os generate code like that.

This also compels me to "code-golf" the function even more:

         push edi
         mov edi, [esp+8]
         mov ecx, [esp+12]
         jecxz label2
        label1:
         push ecx
         call sub_416352
         stosb
         pop ecx
         test al, al
         loopnz label1
         jecxz label2
         dec edi
         salc
         stosb
        label2:
         pop edi
         ret

Original: 58 bytes; patched: 44; mine: 30.

I've done plenty of patching like this, and indeed the relative "sparseness" of compiler output very often allows the more functional version to be smaller than the original. It's amazing how many instructions the original wastes --- notice how _none_ of ebx, esi, or edi are used, yet they get needlessly pushed and popped; and despite saving those registers so they could be used locally, the compiler perplexingly decided to keep all the local variables on the stack instead. The "jump around a jump", with both of them being the "long" form (for destinations greater than 128 bytes away, not the case here) is equally horrible. This may actually be a case where today's compilers _will_ generate smaller code for the same source.

 _Note that in 32-bit code, memcpy is typically implemented by first copying blocks of 4 bytes using the movsd (move double word) instruction, while any remaining bytes are then copied using movsb (move byte). This is efficient in terms of performance, but whoever was patching this noticed that some space can be freed by only using movsb, and perhaps sacrificing a nanosecond or two._

On older processors this was true, but since Ivy Bridge a REP MOVSB will essentially be as fast but smaller. Look up "enhanced REP MOVSB" for more information.

<comment><USER3> How does this go with the often quoted mantra that you can only beat compilers today if you're an extremely skilled asm programmer? Or is the problem you describe just about executable size rather than speed?

<comment><USER4> Optimizing for size is easier because you only have exactly one metric to consider: how many bytes your instructions take.

When optimizing for speed you have to consider many factors like the relative speed of each instruction, cache behavior (including size of the cachelines, associativity, number of layers, relative speed of the layers...), pipelining, branch prediction, prefetching, whether moving your data to SIMD registers could be worth it, what to inline and what not to inline, what to unroll and what not to unroll, constraint solving to optimize things that can be computed or asserted statically etc...

<comment><USER5> And that's for a single processor! There's myriad CPUs the end user could be using.

<comment><USER6> x86 and x64 are the only two that someone could be using on desktop, right?

<comment><USER7> Timing rules can be very different even between different models of the same processor, let alone between different ranges (i3 vs i7) or generations (Skylake etc). An example: [https://gmplib.org/~tege/x86-timing.pdf](https://gmplib.org/~tege/x86-timing.pdf)

<comment><USER8> I don't think there are any differences between an i3 and i7 of the same generation in terms of instruction timings.

<comment><USER9> True, caches are a whole different story though.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER10> Binary hacking FTW.

The semi-official Debian server, alioth.debian.org, where a lot of random developer stuff is hosted, is stuck on Debian wheezy for various reasons. Most users, including myself (a Debian Developer) don't have root access to upgrade the server nor install new software.

The version of libapt-inst is too old to support Debian packages with control.tar.xz members (only control.tar.gz members). So we can't upload newer Debian packages to various custom APT repos that we host on that server.

I worked around this by looking at the libapt-inst source code, figuring out how to make it support control.tar.xz instead of control.tar.gz, and binary- patched libapt-inst.so to have this effect instead. It's actually fairly simple

1\. there is a check for control.tar.gz, the failure branch prints an error and then returns. I overwrite this with NOP so it goes into the "success" branch.

2\. then later it extracts the control.tar.gz member and pipes it through gzip. Luckily, nowhere else in the program uses the exact string "control.tar.gz" or "gzip" so I simply patch that string "control.tar.gz" -> "control.tar.xz" in the binary and also change "gzip" -> "xz\0\0".

(Actually given the change in (2), (1) is not necessary. But without it you get a bunch of spurious error messages.)

Applying this patch makes the resulting .so lose the ability of working with old control.tar.gz members (which is still needed of course). So my workaround does this:

LD_PRELOAD=libapt-inst.so.patched apt-ftparchive [..] && apt-ftparchive [..]

i.e. runs it once with the hack to pick up the new-style debs, and once again without the hack to pick up the old-style debs.

My motto is, "dirty solutions for dirty problems". :D :D :D

<comment><USER11> > The semi-official Debian server, alioth.debian.org, where a lot of random > developer stuff is hosted, is stuck on Debian wheezy for various reasons

Jeez. How is security maintained? That actually scares me a bit.

<comment><USER12> Wheezy is supported until the end of May 2018, so it still gets security patches.

</comment></comment></comment><comment><USER13> I'm surprised no one has noted the copyright is to Design Science - this is a small company in my hometown who are still around. I've spoken with their CEO a few times and I wouldn't be at all surprised if the source code was lost, or somehow at least wasn't being made available to Microsoft (I doubt it ever was). It's a really old school shop who seems to have largely been coasting on the licensing of this one component for the past couple decades and I wouldn't at all be shocked to find they no longer are capable of maintaining it themselves.

<comment><USER14> I noted it - thanks for the background info on the company! I also assume that either they are not able to maintain the software themselves, or they have lost the source code, but it might also be that setting up the toolchain to compile such an old piece of software is more effort than just patching the binary.

<comment><USER15> This is such an underappreciated aspect of code stewardship. There are powerful tools for source control and archiving. But ensuring that state of code could actually be built at an arbitrary date in the future is so much less assured.

</comment></comment></comment><comment><USER16> I once worked at a place which lost part of the source code for their giant mission-defining application. They spent a decade linking in object code for which there was no corresponding source code.

The build team was very proud when they announced that the application would finally start being built from the source code in version control.

Stuff happens!

<comment><USER17> Stuff happens, indeed, and more often than most of us realise.

Getting on for a decade ago now I was working at Red Gate when they bought .NET Reflector - a decompiler for .NET code - from Lutz Roeder. After the acquisition we started asking people what they were using it for.

Turns out a significant minority of them were trying to recover lost source code, or source code they never had in the first place (e.g., where a supplier went out of business). I don't remember the exact figure but it might even have run into low double-digit percentages. Bear in mind this is a tool that was being downloaded tens of thousands of times every month by all manner of people working for all kinds of organisations of every size and you can see the scale of the problem.

There were a couple of Reflector add-ins that would allow you to take a .NET binary and generate a C# or VB.NET Visual Studio project with all source code from it. The source code was never perfect and wouldn't likely compile first time, but it was certainly better than starting from scratch. Not surprisingly these add-ins were among the most popular.

Granted, times have changed, and I think source control is probably the default for almost everyone these days - although I would have expected that even in 2008 - but, bottom line: I think this sort of thing happens a _lot_ , for one reason or another.

<comment><USER18> Heh can say I know some guys who have done this, and I myself have done this (and with similar but open source tools) there's also the "what is this sketchy .NET app really doing" moment where you want to know it's not doing anything "funny" to your system and you peek at the code.

</comment></comment></comment><comment><USER19> There's only two reasons I can think of why they'd patch the binary directly: either they've lost the source-code, or they no longer have an environment they can build it in.

<comment><USER20> For ages Alan Kay has been claiming to know that MS has lost part of the Word codebase.

<comment><USER21> Microsoft has lost tons of code over the years. Even with the source, refactoring office which has people using file formats that are binary dumps of memory, is not trivial.

<comment><USER22> This was actually the Onus for the switch to the XML formats IIRC. Basically after the DOJ settlement they had the uneasy realization that the requirement to document the .doc format was going to be a nightmare because nobody had a complete spec of it. To make it worse the code wasn't very portable and customers were asking for x64 support pretty hard at the time.

<comment><USER23> Re: 64 bit is that about Excel? I found the idea of a Word document needing >4GB RAM somewhat absurd

<comment><USER24> Note that due to the way the 32-bit address space was laid out, a process could really use only about 2GB of RAM — the extra 2GB was reserved for the system based on old 386-era CPU limitations. Since that space had various things allocated in it, a normal program generally wouldn't get more than 1.7GB in a single allocation — e.g. according to [https://support.microsoft.com/en-us/help/313275/-not- enough-...](https://support.microsoft.com/en-us/help/313275/-not-enough- memory-error-messages-when-you-copy-formulas-over-large-ar) Excel 2003 had a heap limit of about 1GB.

The other thing to keep in mind is that Office documents are, in addition to being somewhat bloated internally, far more than just text. Think about all of the people writing things like documentation with hundreds of screenshots (all uncompressed BMPs), audio or video, etc. — and the people with those are far more likely to be at the kind of large corporations which expect value from their support contracts. There were multiple ways to deal with that problem but in general the easiest was switching to a 64-bit address space.

<comment><USER25> Recently they had to enable /LARGEADDRESSAWARE in 32-bit Outlook.

</comment></comment></comment></comment></comment></comment></comment><comment><USER26> While this _does_ suggest that they lost the source code for this program, it also shows an unbelievable amount of skill.

<comment><USER27> HN, where writing assembly shows an unbelievable amount of skill.

<comment><USER26> Not just writing assembly, rewriting a compiled object file without letting any of the addresses change, without having the source to work with, and presumably with almost no documentation, to patch a program that has been left untouched for almost 20 years.

<comment><USER28> I kind of agree with the sentiment. It isn't that crazy.

We do this as a matter of course all the time. Patching a small handful of instructions is pretty easy. You could learn to do it on a week or less if you are a decent programmer.

Do it well? Do it quickly? Do it idiomatically and in a short amount of time.... Takes real skill.

<comment><USER29> I used to patch games for infinite-lives, or to allow my serial numbers to be accepted. Doing this wasn't hard, as somebody who grew up writing assembly language on 8-bit machines in the 80s.

One fun self-challenge was always to make my modifications as small as possible. e.g. one-byte changes were a lot more impressive than two-byte changes.

<comment><USER28> Your own personal game genie.

It's interesting. I have observed if people learn on an 8 or 16 bit machine, like in Microcorruption, they tend to be able to pick up more complex ISAs much easier. It helps to know the first principles.

</comment></comment></comment></comment></comment></comment><comment><USER30> I have no specific insight to this patch, but I do have personal experience binary patching a popular Microsoft product.

My patch was to the VC++ compiler nearly 20 years ago. We had source, and my fix was also applied to the source (which I'd imagine is still there today), but a binary patch also made sense in the short term.

The binary that I patched was used to build another important Microsoft product, and this bug was found late in the product cycle where any compiler change was risky.

We weren't 100% confident we had the _exact_ sources used to build that version of the compiler (git would have been handy then), we only knew, plus or minus one day, what the sources where.

After carefully evaluating the binary patch versus the risk of building from uncertain source, the binary patch was taken to reduce risk.

I'm no reverse engineer, but this was a pretty interesting exercise in RE even though I had sources. I had no symbols, and the binary was optimized so that functions were not contiguous, cold paths were moved to the end of the binary. Just finding the code I needed to patch was not easy.

The code review was fun - a dozen or so compiler engineers reviewed the change on paper printouts - the most thorough review I've had in my career, and the only one that used paper.

To the best of my knowledge, this binary was never used to build anything other than that specific version of the product which I won't name - not that it matters really, the product is still in use, but that version is unlikely to be in use anywhere anymore.

<comment><AUTHOR> Thanks for sharing this. I suspected that "not being sure if you have the exactly right source code" could be a real world reason to patch a binary, and now I know.

</comment></comment><comment><USER31> That is both pretty impressive and horrific.

I wonder if they patched this way because they wanted to maintain as much binary compatibility as possible, or if they don't have the original source/couldn't reproduce the build process.

<comment><USER32> Horrific? This is what you do when you want to make sure you don't introduce any unintentional changes. Computers aren't magic, and there is nothing _wrong_ about patching a binary.

Compiling the software with a modern compiler or linking to a modern runtime is very likely to bring obscure bugs in the codebase to the surface. It's pretty hard to replicate the entire build process that produced the original binary, even if they have the source code and everything else on hand.

<comment><USER31> > Horrific? This is what you do when you want to make sure you don't introduce > any unintentional changes.

Horrific, because the average programmer would consider patching the binary a worst-case scenario.

> there is nothing wrong about patching a binary

I would only trust a skilled assembly programmer to do this task without creating other problems, and most businesses don't have those on retainer.

<comment><USER33> > Horrific, because the average programmer would consider patching the binary > a worst-case scenario.

That says more about the average programmer than it does about the reasonableness of binary patches.

I used to table in MASM on the 8088 and have dabbled a little on microcontrollers (6800) as well. But the last time I looked at modern x86, I was pretty lost.

<comment><USER34> Admittedly, x86 assembler is a total clustefuck.

</comment></comment></comment></comment></comment><comment><USER35> You have to know that the MSFT may not have the source code of Equation Editor, since it is a simplified version of MathType.

</comment><comment><USER36> This 'old' equation editor is a limited version of MathType ([https://en.wikipedia.org/wiki/MathType#Microsoft_Equation_Ed...](https://en.wikipedia.org/wiki/MathType#Microsoft_Equation_Editor)) that has been supplanted by a built-in equation editor.

Chances are that Microsoft doesn't have a license for bug fixes from Design Science (makers of MathType) anymore and isn't willing to pay for this fix.

Alternatively, Design Science may not be able to deliver a version that, for maximum backwards compatibility, has only this fix (to minimize risks, they would have to have kept an environment around that hosts the compiler used back then)

</comment><comment><USER37> One reason for doing it this way is possibly this:

> Well, have you ever met a C/C++ compiler that would put all functions in a > 500+ KB executable on exactly the same address in the module after > rebuilding a modified source code, especially when these modifications > changed the amount of code in several functions?

It's quite possible they are still contractually obligated to maintain some pretty old systems where changes to the .exe would produce unexpected behaviour. I had Access apps/databases crash on a system if they were built by a different version of Access.

</comment><comment><USER38> Slightly off-topic: what program is used to produce disassembly graphs as those in article?

<comment><USER39> [https://www.hex-rays.com/products/ida/](https://www.hex- rays.com/products/ida/)

IDA is widely regarded as the best disassembler and debugger out there. It comes with a price to match too though.

<comment><USER7> It is something of a rite of passage in the piracy community to crack your own copy of IDA Pro.

It's also a rite of passage to distribute cracked and boobytrapped copies on filesharing sites...

<comment><USER40> Oh, I remember the old "this will only work if your timezone is set to Moscow" version...

</comment></comment></comment></comment><comment><USER41> Ah, this brings up a lot of font memories of me in high school preparing presentations using this fine piece of software[0] before replacing it with a 1GB open source equation editor called LaTeX.

[0] It was actually quite usable once you got to know its warts.

</comment><comment> yoz-y The article mentions that the timestamp of compilation gets embedded into the binary. When does this happen? I am used to having identical binaries when recompiling the same source code with same flags (and compiler and so on and so on)

<comment><USER42> What compiler do you use? Almost all of them embed a compilation timestamp (which is one of the reasons reproducible builds are often a challenge).

<comment> yoz-y Mainly visual compiler and clang.

</comment></comment></comment><comment><USER43> Binary patching is a really common requirement in attack/defense CTF, and there are a few projects floating around to help with it.

Keypatch helps you do assembly overwrites in IDA Pro.

Binary Ninja lets you do assembly (and C shellcode!) overwrite patches, and even has undo.

I have my own project [1] for patching ELFs that relies on injecting additional segments and injecting a hook at any address, so as to not require in-place patches. It can also massage GCC/Clang output and inject _that_ reliably into an existing binary.

[1] [https://github.com/lunixbochs/patchkit](https://github.com/lunixbochs/patchkit)

I have my own story about this as well. A few years ago I released a port of Uplink: Hacker Elite for the OpenPandora handheld with a few game engine patches, and some people were running into a bug: the game would enter the "new game" screen on every launch, even if you already had a save game to load.

I and couldn't find the exact source I'd used to build it and didn't want to spend time making sure I got all of my bugfixes into the vanilla repository, so... I went digging with IDA, found the topmost branch to the "new game" wizard, and patched the address to go to the main menu function instead. At that point you could still click "new game" from the menu and it wouldn't go through the patched address (so "new game" still worked), but you could also load an existing game, thus fixing the bug!

I still have nothing on Notaz, who statically recompiled StarCraft and Diablo for that community :)

</comment><comment><USER44> It's an old program the source code for which may either not compile with the modern C++ compiler, or be lost. Back in 2000, Microsoft was using Visual Source Safe for managing its source code. I wouldn't be surprised if nobody can remember where the heck the VSS repository with that source code is located.

That leaves the binary monkey-patching as the only reasonable solution. I'm pretty sure Raymond Chen still works at Microsoft...

<comment><USER45> Binary patching is really only reasonable when the source code is indeed lost. If they had the code but simply needed a compiler that worked, they could have rebuilt it using the same toolchain and build environment it was built with to begin with. Old versions of Windows and MSVC are obviously still around.

</comment></comment><comment><USER46> Just a historical note: Patching used to be much more common. Back in the Vax VMS days the image file format (executables, not pictures) had a section for patches.

From the ANALYZE/IMAGE command…

 _Patch information --- Indicates whether the image has been patched (changed without having been recompiled or reassembled and relinked). If a patch is present, the actual patch code can be displayed. (VAX and Alpha only.)_

</comment><comment><USER47> And here I am, manually patching Docker containers...

<comment><USER48> Just why?

<comment><USER49> Because they are immutable /s

</comment></comment></comment><comment><USER50> I suppose the fact that they have patched the binary means they can never again patch the source?

<comment><USER51> They'd have to re-implement the patch in source before doing anything else to it. I wonder if they are no longer able to build from source anymore... why else would they resort to this?

<comment><USER50> As explained in the article and in other comments, it's possible that there are dependencies that rely on address continuity of contents or file size continuity.

</comment></comment></comment><comment><USER52> They probably just lost the ability to build it, or the source code can't be found. Happens quite often. 17 years is a /long/ time to maintain build systems and remember where you put the files.

<comment><USER53> I'm glad that most of the software development community seems to have settled on git. I get the feeling that I'll still have all of the source code for my projects in 20 years.

Redundant backups are especially important for software companies. It's scary to think how many startups give all cofounders and developers admin access to everything. It helps that git is distributed, but it's not hard to imagine a scenario where a ticked off former employee wipes everyone's laptops and deletes the hosted source code.

Even if you don't update the mirrors regularly, it's good to know that you have some copies of data in BitBucket/GitLab/Heroku/Google Drive.

<comment><USER54> I don't know if I would hold your breath. 10 years ago I think most people hadn't even heard of git (it was ~2 years old) and Google Code was the hot new thing, and GitHub was a year or so away from creation. At the time most people seemed to be pretty content Subversion and hosting on Sourceforge (before it turned evil) or Google Code, but in the next ~5 years everything changed. Granted git, GitHub, etc. have far more momentum that anything that came before, but this is a field where it feels like the only constant is change.

</comment></comment></comment><comment><USER55> If the thing is 17 years old an a replacement has existed since forever, what purpose does this file have today (Assuming I'm on a modern windows, I run either no ms office or a modern office version).

<comment><USER56> From the article:

> While Office has had a new Equation Editor integrated since at least version > 2007, Microsoft can't simply remove EQNEDT32.EXE (the old Equation Editor) > from Office as there are probably tons of old documents out there containing > equations in this old format, which would then become un-editable.

<comment><USER55> Ah. missed that. But obviously I'd be very happy for this program to be patched by replacing it with this program:

      MessageBox.Show("This document contains an old equation and you don't have the editor. Do you want to download the old editor?");

Becuase there comes a point in time when any time you bump into an equation like this, it's actually more likely to be a malicious one.

Even better if they could at least render the old equation statically using the new office, but not edit it. Then it would be almost insanely rare that anyone needs the old editor.

<comment><USER57> This is the kind of thing that can rapidly escalate to a CTO asking his Microsoft sales VP why he's spending $18M/year on upgrade and support contracts when a report that's worked "forever" can start talking back like Clippy.

Microsoft doesn't preserve backward compatibility because they're stubborn; it's a key part of their value proposition to some of their biggest clients.

<comment><USER55> This is the thing: I'm also a paying customer, I just don't pay as much. But I'd like to pay for more security/less compatibility, instead of the other way around.

This should also be very easy to do e.g. by noticing whether you are in a setting where there is any risk of the scenario you say. If it's a home machine for example, then don't worry about compatibility, focus on security.

<comment><USER58> We've seen where that leads to: there is plenty of software out there where you'd have to open every document you wrote with version N - 1 in version N to "convert it" to N's format, and version N + 1 can't read N - 1 files at all.

That can lead to a very ugly form of bitrot quickly. Do you convert every document you've ever touched every time, even ones you haven't needed in years, just in case? Do you worry that every time you convert a file it might corrupt the file in the process? Do you find some way to keep every version of the program available at all times and play try every version until it opens the file?

Backwards compatibility in general offers much greater means for archival.

In this specific example: losing backwards compatibility for ancient equations directly threatens the archival of math and science documents. That seems like it could have huge repercussions in some fields.

<comment><USER40> If I were designing the software, there would be a module which can upgrade a file format from version N to N+1.

That code is written in some kind of sandboxed VM/bytecode. You freeze the bytecode when you release a version.

When you release version 20 of the app, it has bytecode to convert 1 -> 2, 2->3, 3->4, etc, all the way to version 20. When it finds an old file, it runs all the updates as necessary.

If there is a bug in the updaters, it stays there forever.

If there is a security problem with the updaters, thats whats the sandbox is for.

</comment></comment></comment></comment></comment></comment></comment><comment><USER59> Reminds me of that time Mark Watney used a similar method to patch his rover's comms to connect to an old radio system.

</comment><comment><USER60> I wonder how the checked in the fix to the source control system?

<comment><USER61> 'FCIB', apparently: [https://blogs.msdn.microsoft.com/oldnewthing/20171114-00/?p=...](https://blogs.msdn.microsoft.com/oldnewthing/20171114-00/?p=97396)

<comment><USER62> > F-C-I-B or as a sort-of acronym eff-sib […] stands for "foreign checked-in > binary" […] The term FCIB didn't originally mean "foreign checked-in > binary". According to legend […] "Not another f—ing checked-in binary!"

</comment></comment></comment><comment><USER63> There are plenty of companies hooking into private APIs within Word and Excel with their "productivity tools". Probably an important MSFT customer was using one of these tools as a crucial part of their operations, so they convinced them not to break it. Just like how Google had to put special cases in Android to keep compatibility with some hacks Facebook was using in their app.

</comment><comment><USER64> I salute and respect the guy who did this while hoping I never have to do anything like this.

<comment><USER65> I was dreaming I'll _have_ to do something like that until it faded below the weight of modern <script src> programming. It is like dancing twist, rock and hardbass in the era of electronic arse shaking.

</comment></comment><comment><USER25> I noticed a 0F 1F NOP, which breaks older processors. This is in an update that goes back to Office 2007.

</comment><comment><USER27> So Microsoft lost the source code? Or maybe the engineer couldn't be bothered to set up the old toolchain used to build this executable?

<comment><USER66> Probably bought it in from a third party. Why'd you think Pinball went away?

<comment><USER67> Raymond Chen answered this question five years ago[0].

[0] [https://blogs.msdn.microsoft.com/oldnewthing/20121218-00/?p=...](https://blogs.msdn.microsoft.com/oldnewthing/20121218-00/?p=5803)</comment></comment></comment>


Game Over, Man. Game Over: Actor Bill Paxton Dead at 61 - <AUTHOR> http://www.theverge.com/2017/2/26/14742806/bill-paxton-obituary-aliens-titanic-big-love <comment><USER2> "The only critic you want to satisfy at the end of the day is time, and time's been kind to me."

Source: [http://www.vulture.com/2014/06/bill-paxton-on-trading- quotes...](http://www.vulture.com/2014/06/bill-paxton-on-trading-quotes-with- tom-cruise-edge-of-tomorrow-interview.html)</comment>


Substring searching in sub-linear time - <AUTHOR> http://blog.phusion.nl/2010/12/06/efficient-substring-searching/

<comment><USER3> Actually, Python does use a Boyer-Moore-Horspool variant internally for substring matching (I'm not sure about Ruby, though). See:

<http://effbot.org/zone/stringlib.htm>

Here's a link to the file in the Python SVN repo:

[http://svn.python.org/view/python/trunk/Objects/stringlib/fa...](http://svn.python.org/view/python/trunk/Objects/stringlib/fastsearch.h?revision=77470&view=markup)

<comment><USER4> Ruby 1.8.7 does too. Not sure about Oniguruma in 1.9

[https://github.com/ruby/ruby/blob/ruby_1_8_7/regex.c#L2751-2...](https://github.com/ruby/ruby/blob/ruby_1_8_7/regex.c#L2751-2789)

EDIT: Looks like 1.9 does too:

<https://github.com/ruby/ruby/blob/ruby_1_9_2/regint.h#L281>

</comment></comment><comment><USER5> Luckily, perl will optimize some constant regular expressions to use Boyer- Moore.

For example, if you do:

      $str =~ /foobarbaz/;

perl sees what you want and uses Boyer-Moore instead of a normal regex state machine.

This, and many other optimizations, is what 20 years of language development gets you.

<comment><AUTHOR> But still no JIT and no threads that don't take 20 seconds to spawn on a moderately sized app. :(

<comment><USER6> Actually, in all seriousness, deeply ingrained problems is also what 20 years of development gets you. That's why it's still important to have new up and coming languages getting created. Unfortunately there is no language so perfect it can escape this fate, and I wouldn't say Perl's problems stand out particularly on that front. It's a rare language that is even around to be criticized 20 years later, they all have their issues.

</comment></comment></comment><comment><USER7> Using an algorithm with a better average case and very bad worst case instead of an agorithm that always executes in linear time is pretty common - <USER2> example, in grep:

[http://ridiculousfish.com/blog/archives/2006/05/30/old- age-a...](http://ridiculousfish.com/blog/archives/2006/05/30/old-age-and- treachery/)

Makes sense, as long as you and the people using the code know the tradeoffs involved.

</comment><comment><USER8> (I posted this comment on the blog as well)

The poor performance of Turbo Boyer-Moore might be due to cache locality issues. If you jump from checking the end of the needle to the start of the needle, then there's a good chance that you'll cause a cache miss - which has the same cost as several hundred instructions. A modern Turbo Boyer-Moore would probably work backwards within the same cache line before jumping to the start of the needle. A couple of carefully chosen cache-preload instructions could make Turbo Boyer-Moore. For a good overview of cache effects, google "gallery of processor cache effects".

<comment><USER9> This is a plausible and knowledgeable-sounding argument; its only flaw is that it not true.

The only relevant 'several hundred instructions' cache miss on a Core 2 Duo is a L2 miss ("Last Level Cache" miss). The hardware pre-fetcher will pick up accesses to the data stream after the first 1-2 misses. No amount of minor local jumping around in Turbo-BM is going to affect this.

<comment><USER8> Thanks!

</comment></comment></comment><comment><USER10> See also <http://news.ycombinator.com/item?id=1626305> and <http://news.ycombinator.com/item?id=466845> and I was about to link to the rediculous fish post, but I see zdw beat me to it.</comment>


Devs make cracked game impossible to win - <AUTHOR> http://kottke.org/14/11/the-work-of-art-in-the-age-of-mechanical-reproduction

<comment><USER2> Since the dawn of time (well, the 1980s) copy protections have had booby- trap/fail pits. Some of those fail routines have been remarkably creative (and occasionally ridiculously destructive).

Delayed flags with adverse consequences, subtly changing CAD points or musical note timings or slowly corrupting user data if a dongle has bad wiring. Deliberate hardware damage, from the C64 disk drive happily being made to chew on its own heads to (arguably) setting counterfeit USB serial interface chips to a PID of 0. I've even seen one which quietly dropped to desktop with a virus when tripped (in fact this was the origin of that particular bootsector virus, which achieved an unexpectedly wide spread on its platform, and its own payload had a generation counter attached so you wouldn't notice for quite a while).

This one is curiously poetic. Very meta. But still a logic bomb.

 _Don 't_ booby-trap your code. It's incredibly unethical and stupid. Logic bombs misfire. Frequently.

<comment><USER3> I agree with you.

However, in this case they didn't booby-trap the real product. They released a special "pirate edition" torrent with the "piracy logic".

I'd consider it a kind of "collector's edition" ;)

</comment></comment><comment><USER4> Here is the original source with more details:

[http://www.greenheartgames.com/2013/04/29/what-happens- when-...](http://www.greenheartgames.com/2013/04/29/what-happens-when-pirates- play-a-game-development-simulator-and-then-go-bankrupt-because-of-piracy/)

</comment><comment><USER5> My immediate thought was about this interesting sounding book [1]

[http://www.amazon.com/Surreptitious-Software-Obfuscation- Wat...](http://www.amazon.com/Surreptitious-Software-Obfuscation-Watermarking- Tamperproofing/dp/0321549252)

</comment><comment><USER6> Although amusing at first, if this practice would become widespread everyone would just wait for cracked release of proper version from respectable cracker team. This game is in unique position though because it is itself about making games.

<comment><USER7> I don't think it's meant to be a one-size-fits-all technique for ending game piracy. It is amusing though.

</comment></comment><comment><USER8> This is so ironically genius. I love it. Kudos to the GDS Developers!

</comment><comment><USER9> I remember hearing about Rocksteady doing something similar with Batman: Arkham Asylum.

<comment><USER10> If I recall, in Arkham Asylum, it was impossible to win the big boss fight, but there was no messaging about it - it just happened.

<comment><USER11> You may be thinking of another game. In Arkham Asylum, they disabled the glide function ([1]), you definitely knew about that before the final boss.

Now, EarthBound had a hook like that one [2], where the game would first make it _much_ more annoying to get through the game (by churning out extra random encounters), and then when you get partway through the final boss the game will freeze _and delete your save game_.

[1] [http://forums.eidosgames.com/showthread.php?t=95030](http://forums.eidosgames.com/showthread.php?t=95030)

[2] [http://earthboundcentral.com/2011/05/earthbounds-copy- protec...](http://earthboundcentral.com/2011/05/earthbounds-copy-protection/)</comment></comment></comment>


A checklist of marketing ideas for side projects - <AUTHOR> https://www.sideprojectchecklist.com/ <comment><USER3> "Cold call ~20 people who might be good customers."

IMHO this is probably the first! thing you should do. To my own surprise people will give you money for your service even if you don't have a websites (and name, logo, slogan or anything else), and you send your 'product' via email.

And 3 out of 4 ideas don't survive these 20 calls - so you'll save a lot of time if you sell first and build later.

Emotionally that's not easy - of course - but it's what you will be doing all day anyway if it goes well, so why not start early?

<comment><USER4> That's extremely surprising to me; I'd have assumed that 19 out of 20 cold calls would be rejected _regardless of how good the product is_.

<comment><USER5> I guess if it's something that's genuinely interesting, it's the same kind of flattering as if a crew/group of students with a camera accosts you on the street to ask your opinion on something. I'm happy to provide feedback if it comes with no requirement to pay.

<comment><USER3> Totally agree! People's willingness to tell you about their thoughts is the N.1 way to get a call started.

Now imagine that group of students opened the conversation with: "I saw you raise your hand in C101 this morning, and thought your question was very interesting. What made you think of that?"

</comment></comment></comment></comment><comment><USER6> I do a lot of this stuff professionally so I was interested to take a look at an "outsiders" approach to this. Honestly, you've done an incredibly good job on this. Great suggestions!

<comment><AUTHOR> Thanks so much! To be fair, while my primary job has been as software developer for the past several years, I've worked in startups small enough to know what the marketing team was doing. You pick up a lot of general business knowledge working for a small company.

</comment></comment><comment><USER7> This is a great start! I noticed that 90% deals with MARCOM strategy with a bit of SWOT thrown-in too.

As someone who is responsible for bringing products to market on a daily basis, there is a considerable amount of strat being omitted which will better prepare you.

Pricing. Determine where you want to position your product in the market. Identify the competitors that compete on price vs the one's that compete on quality. Determine where you want to position your products and which competitors to go after. This should help you determine which customers you want to market towards as well. It also helps you determine the effort you can apply to each channel. [Spend more time on the difficult customer to obtain]. Michael Jordan didn't become Michael Jordan by practicing his dunk. He purposely worked on the weakest part of his game to make him the greatest.

<comment><USER8> Great ideas! I was wondering, what book/tutorial/website would you suggest to someone interested in digital marketing?

<comment><USER9> They might not be back. Here are some options that have made a splash here on HN over the years:

[https://news.ycombinator.com/item?id=14041248](https://news.ycombinator.com/item?id=14041248)

Justin Jackson as mentioned there is about to release an update to his "Marketing for Developers", so he's pitching a 24hr "deal" (meaning make sure the bundle is worth $100 to you; I don't necessarily recommend it) right now: [https://justinjackson.withcoach.com/marketing-for- developers...](https://justinjackson.withcoach.com/marketing-for- developers/buy?coupon=PREORDER)

You can see the stuff he gives away for free on YouTube here: [https://www.youtube.com/justinjackson](https://www.youtube.com/justinjackson)

<comment><USER8> Thanks! I'll definitely check them out.

</comment></comment></comment></comment><comment><USER10> There are so many things to do here- on top of actually building the side project itself. It's probably worth reading and understanding the benefits of each activity and then prioritising the ones that work for your business.

Just be careful not to deprioritize items because they're outside your comfort zone.

</comment><comment><USER11> Don't forget to create the product as well.

<comment><USER12> It would seem odd if the marketing checklist had "Create product", wouldn't it? :)

</comment></comment><comment><USER13> Great list! Might there be a market / an interest in a dashboard + chatbot for taking care of these things? Keeping track of milestones, doing the trivial signups an presenting how the different initiatives are performing and can be tuned?

<comment><USER14> I, as a very organised perfectionist, am so keen to have one. However, having said that, while it would be a great tool, I'm just not quite sure how many are willing to pay for it.

In my opinion, a tool providing insights (e.g. basic data science) besides tracking can provide at least a better value than a pure tracking tool. (Disclaimer: I'm working on one myself :])

Interesting enough, there's a similar checklist/dashboard idea for funding round in the UK ([https://seedlegals.com](https://seedlegals.com)), handling all the legal hiccups in a much cleaner and organised way. But their market is quite different and there's much higher incentive for customers to pay for it.

</comment></comment><comment><USER15> I like the way you have gone about this - very systematic and seems somewhat comprehensive (though of course more points may be added over time). Thanks for making it.

<comment><AUTHOR> Thanks! I hope that along with help from others we'll make it very comprehensive over time.

</comment></comment><comment><USER16> This is really, really helpful. I will try to do all of these things for the project I'm currently working on. But man, cold calling 20 people is going to be so much harder than actually building the thing.

<comment><AUTHOR> I don't think you _have_ to do every item on the list for every project; that's where you sort of need to know yourself and your audience.

That said, direct contact with your customers/users is extremely helpful. It might not have to be cold calls if you happen to have a good network already. I've never been good at cold outreach either, but I have no problem talking to people I know might be interested.

</comment></comment><comment><USER17> Great resource. The one name in there I didn't recognize was '7search'; I clicked through, but it seems to have shut down within the last week, so you can probably remove that.

<comment><AUTHOR> Good to know, thanks!

</comment></comment><comment><USER9> Do you have time to explain your choices and/or process as you used a static website generator + theme for this project's web site when it appears to be optimized for blogging?

Right now I'm looking at Hugo + Kube but there are so many not-normal things to use (Hugo + Github Pages all in source control but publishing different branches / folders, Kube using not-normal-Hugo stuff since it's got non-blog stuff, etc.) Is there a one-stop zero-to-hero guide anywhere for this kind of thing?

<comment><AUTHOR> Good question. I used GitHub pages and Jekyll for the site because it's something I've used before so I knew it would be easy to set up.

Initially this project is just a checklist and some supporting pages, but as I learn more, make updates, and use the checklist for my own side projects I'd like to write blog posts there as well. Having a blog in the same domain as your main project is also good for SEO from what I hear.

I don't have a good tutorial handy for the setup, but maybe that's something I could write about? It probably took two hours to customize the theme and get the landing page up, so pretty quick, but there were a couple gotchas the first time through.

<comment><USER9> Sharing the gotchas would help me a lot!

</comment></comment></comment><comment><USER18> This is brilliant, but it's in markdown. I've converted it to emacs orgmode so I can use org checklists and integrate into my todo list.

[https://github.com/deerpig/side-project- marketing/blob/maste...](https://github.com/deerpig/side-project- marketing/blob/master/marketing-checklist.org)

<comment><AUTHOR> Awesome! I've been considering adding alternative formats. Is there any way we can automate the conversion?

<comment><USER19> Pandoc ([https://pandoc.org/](https://pandoc.org/)) can do it: pandoc -f markdown -t org -o marketing-checklist.org marketing-checklist.md

<comment><USER18> Actually, that's what I used, but in this case the conversion didn't work very well. I had to do a lot of editing to get it formated so checklsts worked and get all of the links converted. Org is a bit more finicky than markdown...

I wish the pandoc conversion worked better because it would be nice not to have to update changes by hand.

It's all little things like making sure that there is only one space in every "\- [ ]" between the dash and open bracket.

The original placed the entire document under a level 2 header, so I placed all top headings under their own level one header. I also changed the bottom level of headings into boldface link items so that org could see all of the checklist items. If you open both versions side by side you'll see how I did it.

Again, thank you for the list, it really is fantastic. I'm considering creating a different version for NGOs and Non-Profits here in Cambodia. Marketing is a large part of what NGOs do to raise funds and there is a lot of overlap between commerical websites and non-profits. But there are a lot of resourses available for non-profits which could be added as well.

</comment></comment></comment></comment><comment><USER20> Wow, love it! Has anyone put this on PH yet?

Another one to add would be a LinkedIn bot for auto profile viewing. It's a pretty efficient way for people to see you viewed their profile, they view yours back, and check out your site/project.

</comment><comment><USER21> Nice idea thanks! One suggestion maybe add some sort of priority marking/ time spent for each one, as I would say some are definitely higher priority than others

<comment><AUTHOR> The way I do it is by having a planning time for the project before I start working on the checklist. During the planning time I'll remove or prioritize things that I think will be most impactful based on the customers.

</comment></comment><comment><USER22> Very well done. I really like checklists, I use them as my todo list, project organizer and general stuff. So I created Sorter to help me: is a webapp to organize ideas, tasks and information using bullet points and hashtags. It´s open source if you want to check [https://github.com/vitogit/sorter](https://github.com/vitogit/sorter)

</comment><comment><USER23> People hitting F5 on HN/Show/New is a great place to find people interested in promoting their side projects. Well played :-) (and thanks)

<comment><AUTHOR> Haha, know your audience is the first rule of marketing right?

Seriously though, it's open source and free, so while I know I'm tooting my own horn I hope it helps people anyway.

</comment></comment><comment><USER24> > _Free Promotional Channels / Write and distribute a Press Release._

For smaller projects this does not work at all. All it does is it attracts spam from various Indian "wire services" and that's it.

> _Paid Promotional Channels / StumbleUpon_

Only if you want to see how a 100% bounce rate with sub-second page stays looks like. Absolutely useless otherwise, although it is very attractively priced.

<comment><USER25> As a news-stand magazine editor I used to love getting properly targeted press releases for relevant products from small organisations. "Properly targeted" is the key: if you write one release and send the same thing to a thousand publications, of course it won't work.

<comment><USER24> In this case how would a press release be different from a targeted pitch email? Or would you skip the latter because it wasn't in a PR format?

</comment></comment></comment><comment><USER26> Here's a shared workflowy of the checklist for anyone who wants to use it: [https://workflowy.com/s/FSjJ.Z6V7qfO5CD](https://workflowy.com/s/FSjJ.Z6V7qfO5CD)

<comment><USER27> Thanks, I added it to my Workflowy account. By the way, is it added as a copy? I.e. if you change it in your account, will my copy also update or will it stay fixed?

<comment><USER26> Don't know, sorry - duplicate it to be safe :)

</comment></comment></comment><comment><USER28> Very comprehensive in detailing practical options for each step. Thank you!

</comment><comment><USER29> You should probably describe what Triberr is next to its mention, because their site is absolutely useless (at least on mobile).

</comment><comment><USER30> Thank you!! Launched a few weeks ago but still very useful.

</comment><comment><USER31> I did not see under which license you released the downloadable content. Mind sharing it here?

If you havent licensed it, one from creative commons might fit.

<comment><AUTHOR> It's in the Github repo, but MIT license.

I'll put a link to that in the site when I get a chance.

<comment><USER31> Thank you :)

</comment></comment></comment><comment><USER32> That's neat, thanks.

<comment><AUTHOR> You're very welcome.

</comment></comment><comment><USER33> very timely

</comment><comment><USER34> Wow ! I appreciate these marketing ideas! I've just discovered a great marketing tool - [https://voiptimecloud.com/online-contact-management- software...](https://voiptimecloud.com/online-contact-management-software/) . maybe someone will find it useful too!

<comment><USER9> I can't tell if yours is a spam account or not...

I understand I'm swinging through late but do you have time to expand on any affiliation you have with the company, but more helpfully share any details on why this particular $21/month tool helps you better than say, Skype?

<comment><USER34> Yeap, be sure to contact me by Skype - <USER2>

</comment></comment></comment><comment><USER35> An online marketing veteran here! This list is really good. I can actually help people here execute these to-dos for their side projects.</comment>


Sigaction: see who killed you, and more - <AUTHOR> http://rachelbythebay.com/w/2018/04/16/signal/ <comment><USER2> There's a lot of cool kings you can do with sigaction.

Trapping sigsegv is a _great way_ to do memory management.

        void sa(int _,siginfo_t*s,void*__){
          mmap((void*)((~PAGESZ-1)&(uintptr_t)s->si_addr),PAGESZ,
            PROT_READ|PROT_WRITE,MAP_FIXED|MAP_ANONYMOUS,-1,0);
        }

Want automatic logging of a big on-disk data structure? mmap some pages read- only map_private, trapping writes and logging the address (then remapping the page read+write). Then at "save time", write out page contents to a replay log, fsync+fdatasync+fcntl-F_FULLFSYNC, then rewrite the file using pwrite/write.

You can also implement big sparse hashmaps this way: Every time a server gets a request, it allocates a cell and tells the client about it. Those cells are read+write. If a cell gets checked in, the server simply decrements the counter, but if there's a page fault (read-only) the server can then take the slower path of finding the server that actually responds to it.

And so on.

<comment><USER3> I once implemented a specialized contiguous stack structure that used this trick to automatically reallocate the stack. (The stack was state for a compiler-generated backtracking NFA.) The handler would longjmp to code that realloc'd the stack and restarted the NFA. (No internal pointers so resetting the NFA state and restarting was trivial.) I forget the exact performance improvement, but compared to the original code with explicit boundary checks I think it was several multiples faster.

Unfortunately signal handlers are process-wide. These tricks are a bad idea for code that needs to play nice with other code (i.e. libraries, modules, etc) unless you know the process won't be multithreaded or you can own SIGSEGV.

In the above hack I used sigaltstack, which is thread-local, to communicate per-thread state to the handler, allowing the scheme to work multi-threaded and to detect unintended faults. (The alt stack memory region used special page-aligned offsets so I could derive a thread-local object that didn't overlap with the signal stack.) Still, such a scheme is too ugly to hide inside a blackbox component which is why these tricks rightly don't see much usage. Your code and my code could have never run in the same process.

<comment><USER4> > Unfortunately signal handlers are process-wide. These tricks are a bad idea > for code that needs to play nice with other code (i.e. libraries, modules, > etc) unless you know the process won't be multithreaded or you can own > SIGSEGV.

It's safe to handle processor trap-caused signals, since those are guaranteed to be delivered to the current thread. (SIGSEGV, SIGILL, SIGFPE, SIGBUS, SIGTRAP). The trickier part is that you can still send SIGSEGV and the like from another process, which means you have to distinguish between "is this signal caused by the processor or somebody else?" not to mention the general "is this signal in the code where I should handle it."

Of course, a saner OS (like Windows) would give you a more stack-based approach to handling hardware traps, so that a function can say "if I, or anything I call, gets a #DE, deliver SIGFPE to this location."

<comment><USER3> But an installed signal _handler_ is process-wide. There's no way for a thread to install a signal handler without potentially stepping on the toes of some other thread wanting to install its own handler. Contrast that with signal masks which are thread-local, permitting libraries to set and restore masks without disturbing global process state.

<comment><USER4> If you code your signal handler right, you could dispatch the signals you don't want to handle to another signal handler.

I'm not arguing that the POSIX signals API is in any way sane (it's not). It is _possible_ to build signal handlers correctly, but it is far from easy and certainly far harder than it has any right being.

<comment><USER3> Yes, but my point was that these tricks don't work well with libraries, which don't normally (if ever) expose a public API for chaining signal handlers, often couldn't do so as a practical matter, anyhow--see my example, below.

If you control the entire process and all the code, then sure. But even then one should avoid deviating from idiomatic, modular programming patterns without very good reason. Because signal handlers are process-wide they're global state; _sharing_ global state is not a friendly path when it comes to code maintenance and long-term project management.

Not too long ago both OpenBSD and macOS lacked sigtimedwait(), so for my Lua Unix module I wrote a "portable" implementation by longjmp'ing from a SIGALRM handler. It worked well and was correct but with the caveat that it shouldn't be used from multithreaded programs. I usually try to avoid multithreaded programming myself, but others embrace it. As both a user and author of libraries, caveats like this are a real PITA.

</comment></comment></comment></comment></comment></comment><comment><USER5> Signal handlers don't _have_ to be process-wide. See my detailed proposal for fixing the situation here: [https://www.facebook.com/notes/daniel- colascione/toward-shar...](https://www.facebook.com/notes/daniel- colascione/toward-shareable-posix-signals/10157129032641102/)

The trouble is that nobody is actually interested in fixing the core API. When I've raised the issue (and my proposal) with libc maintainers, the response has been a bizarre insistence that signals are somehow illegitimate, that the things people do with signals are wrong, and that everyone should just stop with signals despite there being no viable replacement mechanism.

As a result of this head-in-the-sand attitude, we're left with an awful decades old signals API and an absolute mess of ad-hoc libraries (which conflict with each other) to work around the worst of the problems.

This is how good systems ossify and eventually die.

<comment><USER6> My limited knowledge on this topic seems to indicate that some signals are per thread in terms of handler registration rather than process wide. At least if you register the handler in that thread. Am I incorrect ?

<comment><USER5> Signals are process wide. There is no confusion on this subject; people who claim there is are probably thinking of the delivery of process-directed signals, which is an entirely different subject. There is no current system for which sigaction acts per thread.

</comment></comment></comment><comment><USER7> Sigaction is pretty cool. Signals still suck though, if you need to stick to the POSIX specs.

It's crazy that so many standard library functions will fail with an EINTR errno if your program gets a signal while it's in a library function. Basically any library call that ever does any I/O of any kind (that means common stuff like open/dup/read/write, but also less obvious stuff like getpwuid).

Sigaction provides the SA_RESTART flag which _should_ auto-restart most calls, but it doesn't work everywhere. And the functions which do and don't auto- restart aren't documented anywhere that I've ever found.

As a result, any high-reliability program that installs signal-handlers basically needs to have a retry mechanism for every libc call that can result in an EINTR. Some functions might not need it, but I've never found a good way to tell which ones do and which ones don't. Select(), for example, doesn't support SA_RESTART. Neither does wait(). And that means they all need to be checked every time, if you're concerned with portability and reliability. And that's nuts.

IIf I could change one thing about sigaction in POSIX, it would be to add an SA_NOINTR flag to the sigaction API, which would let any POSIX library calls finish before presenting a signal.

That, plus I'd also add Linux's signalfd() to the POSIX standard so that we could do away with "this one weird trick from a DJB" that everybody uses now (and I'd make signalfd use the new SA_NOINTR).

<comment><USER8> Agreed. Years ago I wrote a daemon for Linux with glibc only, so I assumed I can just ignore EINTR everywhere, until I needed to use valgrind and suddenly had EINTRs everywhere.

Rather than making signalfd POSIX, if we play make-a-wish let's just go for kqueue. Signalfd feels somewhat hackish, even though its simplicity admittedly has some appeal too.

<comment><USER9> Signals are an example of false simplicity: they themselves are very simple at the cost of foisting the complexity on you and every library you use.</comment></comment></comment>


Ask HN: Good WP (or other) templates for a personal tech blog? - <AUTHOR>

<comment><USER2> I made an HTML5 template for programmers that you could adapt into Wordpress, Jekyll, and the like: [http://stephenbenedict.com/programmatic- style/](http://stephenbenedict.com/programmatic-style/)

</comment><comment><USER3> [https://pages.github.com/](https://pages.github.com/)</comment>


Show HN: Obey, JavaScript Data Modeling and Validation - <AUTHOR> https://github.com/TechnologyAdvice/obey <comment><AUTHOR> This is a (relatively) new library aimed at improving data modeling and validation in JavaScript. We're looking for (constructive) feedback on the approach of the library and areas where we can expand to make it more useful. Thanks for taking a look!</comment>


Fighter Pilots Face A Dismal Future - <AUTHOR> http://www.strategypage.com/htmw/htmoral/articles/20091102.aspx <comment><USER3> For those in the aerospace industry, are we seeing any movement towards unmanned commercial airplanes? Are the impediments mostly technical or social? Any rough timelines?

<comment><USER4> There are several problems for an unmanned commercial airplane. None of them are insurmountable, but they add up to making it easy to see how this will probably be the last sector that gets automated.

In a combat aircraft the advantages for getting rid of the pilot are numerous: less weight & volume for the pilot and their associated support kit, eliminating the pilot allows for plane geometries that are just not possible with a human onboard, eliminating the pilot enables maneuvers that would turn a pilot to jelly, etc. The pilot is probably the most expensive component of a combat aircraft. Eliminating the pilot opens up new mission profiles (e.g. you don't have to worry too much about the aircraft getting back to base.)

For a commercial aircraft the benefits of going unmanned are not as pronounced and in some cases are non-existent. In addition to the lack of benefits, you introduce additional costs related to liability (you can always blame pilot error for a problem, but if there is no pilot then it is the airlines fault for either not maintaining the system properly or for selecting the system in the first place) and the fact that passengers are not going to trust this system anytime soon.

The impediments are almost completely social, but the benefits are so slight that it does not make much sense to bother aiming for completely unmanned. What you are going to see (and in fact what has been happening for years now) is the increasing automation of cockpit tasks. There will always be a human being "at the controls" for the forseeable future, but what that actually means and how much active control they are exercising is going to be slowly changing.

<comment><USER5> > eliminating the pilot enables maneuvers that would turn a pilot to jelly

I think this is a common misperception. I believe the operational risk is that manuevers above 6g (varying on pilot and G-suit) reduces blood flow to the brain (by forcing it into the legs) and cause a blackout. See <http://en.wikipedia.org/wiki/G-LOC> Blackouts, even for a few seconds, can be devastating in the middle of a dogfight. I believe there is software in modern fighter jets for just when pilots blackout but I can't find it on google right now.

<comment><USER6> I didn't interpret evgen's comment as _literally_ turning a pilot to jelly. (Hrmm, there's an interesting visual.) For practical purposes, a pilot that's blacked out = jelly.

<comment><USER5> Oh, I was responding in general. Most articles, the one (linked included) talk about physical limitations about human pilots. I always thought it was something more gory until I found out about blackouts a few years ago.

</comment></comment></comment></comment></comment><comment><USER7> Sooner or later someone will make one cheap enough for police forces to buy. We ought to put some thought into whether that is going to be a good thing in the long run.

On the plus side:

      - faster response to 911 calls, since UAVs can avoid traffic, and if cheap enough,

they could be salted about the place in a powered off state.

      - less need for police to risk their lives, and consequently

better policing of gang-ridden areas.

On the minus side:

      - police become (even more) disconnected from the general

public, potentially developing a culture of impunity \- spread of surveillance

      - risk of abuse

      - risk of (black hat) hacking

</comment><comment><USER8> or Software Developers for UAVs Face An Exciting Future

It's fun to imagine that somewhere sometime a scrawny geek told a chiseled-jaw pilot "Go away or I will replace you with a very small shell script"

<comment><USER9> Not really. 200 software developers can write the code for every piece of flying drone that the U.S. has. While pilots where employed almost 1:1 for each piece of aircraft. Not to mention all the crew, flight controllers and maintenance people; I don't think a drone undergoes the same rigorous safety checks and standards as a manned plane. And as the military depends on more drone, the cheaper they will become.

<comment><USER10> One interesting development is that, with the growing number of UAVs, there aren't enough pilots to fly them all, so new operators are no longer required to have flying experience.

I heard an interview with "Wired for War"'s author who claimed that controls for some of these systems are modeled after X-box/PlayStation controls, both to capitalize on the ergonomics research done by console makers and to make it easier for young recruits who are already used to operating them.

<comment><USER11> [http://bigthink.com/pwsinger/pw-singer-on-video-games-and- wa...](http://bigthink.com/pwsinger/pw-singer-on-video-games-and-war)

indeed.

</comment></comment></comment></comment><comment><USER12> I would really like to see a competition where teams write opposing AIs for UAVs and the UAVs duke it out.

<comment><USER13> There are actually already some UAV AI competitions that accept student teams, though they're typically not competing in a dogfighting sense, more in a "follow a path, search for an object like x and take a picture of it", etc.

<comment><USER14> That's interesting, would you mind pointing me to an example of such a competition?

</comment></comment></comment><comment><USER15> Does anyone knows what kind of operating system UAVs have?

<comment><USER16> VxWorks: <http://www.electronicstalk.com/news/wia/wia277.html>

<comment><USER17> Typically. Occasionally you hear about one running Linux.

<comment><USER18> They would never use Linux for Avionics, because it would be far too expensive to get such a large and complex system certified for that kind of work.

Commercial planes use linux for non-critical functions like the in-flight entertainment. I can't think of anything that would be on a fighter plane that would be considered "non-critical" enough to not require a high-integrity system though.

<comment><USER17> Vxworks is typical, but Linux does happen sometimes. Most often for ground stations or auxiliary tools, sometimes for continuity between the development and deployed environment, sometimes because it's just a research project and certification isn't an issue.

I wouldn't claim it's common or that you'd be likely to see it in a deployed environment, but it's not totally unheard of. Throw Linux & UAV in Google - you'll see what I mean.

<comment><USER16> VxWorks isn't self hosting - the development may well be done on Linux.

I've definitely seen Linux (re?)booting on in-flight entertainment systems.

</comment></comment></comment></comment></comment></comment><comment><USER19> I feel like my eventual children, or maybe my children's children, will see a world where Americans don't go to was physically (or at least in large numbers). This whole war thing is going to be really weighted against the poorer countries who have to leave real people to die.

I see terrorist tactics (blowing up buildings, schools, etc.) as dominating their efforts.

That said, I think that if I were to do a defense startup now, it'd be towards detecting explosives, guns, etc. in large groups of people. If that technology falls behind, war's about to get a whole lot uglier.

<comment><USER20> I see my children's children living in a world without war.

Articles like this are interesting, but a little sickening in that they assume that continually increasing defense spending is actually a good idea.

I'd work for Swoopo long before I would work for a defense startup.

<comment><USER21> "I see my children's children living in a world without war."

Do you honestly believe that? I don't see how it's even possible unless we sedate everyone in some kind of matrix like false utopian state. It's good to dream though.

<comment><AUTHOR> Doesn't seem impossible. Within Western Europe that is close to a reality now, after endless centuries of war.

<comment><USER22> Western Europe is a pretty small slice of the world, and they've had peace for half a century, which on the scale of multiple centuries, is hardly cause to celebrate the dawning of the age of aquarius. I'm sure this isn't the first 50-year period without war in Western Europe.

<comment><AUTHOR> _I'm sure this isn't the first 50-year period without war in Western Europe._

Name one.

<comment><USER23> 100-150 AD.

<comment><AUTHOR> The society Tacitus describes in the _Germania_ in 98 is one constantly at war. See e.g. chapters 13 and 14:

<http://www.unrv.com/tacitus/tacitus-germania-3.php>

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER24> I am sure at the end of the 19th century horse drawn carriage makers faced a dismal future as well. Some professions simply die down and become irrelevant.

Interestingly enough this already happened to the Airforce in the late 60s. Airforce was running manned spy satellite missions, but because of the cost and the danger involved, those missions were being canceled in favor of unmanned satellite missions. So this is basically a repeat for Airforce.

</comment><comment><USER25> As someone who's worked with these systems, we faced quite a bit of this pilot-as-luddite resistance at first. Unfortunately this article doesn't really capture that many pilots are thankful that some flying computer will get blown away by a popup SA-6, rather than them. Nor does it convey that, while batches of UAVs can perform complicated tasks autonomously, they have not yet achieved air dominance.

<comment><USER16> When I worked in the City we came across a lot of trader-as-luddite resistance to new software too. Many feared being automated out of jobs. Those who got with the programme tho' found they were able to single-handedly managed more complex positions. I think we'll see the same sort of thing here, perhaps a single pilot with the right technology (controlling multiple UAVs?) will be able to carry out a mission that would previously have taken an entire squadron. As the article says, the Pentagon can buy UAVs faster than it can train fully-qualified fighter pilots.

</comment></comment><comment><USER26> I wonder how would you repell a state with sophisticated robot terminators war machines.

Lawn-motor robots? Perhaps arduino-controlled pistol gun with belt feed bullets?

I am worried about the future ability of a population's to resist a technological tyranny.

<comment><USER20> In the USA at least, the population has been completely unable to resist the state since the Civil War.

<comment><USER27> How do you figure that? The Civil War demonstrated nothing of the kind. It only showed that if you split both the populace and the military establishment in two, the side that has more railroads, factories, and soldiers is going to win.

<comment><USER28> I think the fact that the National Guard consists of nothing but fewer, lesser-trained soldiers with aging, outdated weapons/technology is a pretty good indicator that the population would never be able to take on the full might of the federal military branches.

<comment><USER29> Why do you think it would work like that? The model would probably be the IRA and gang warfare, not defined territory and set piece battles...

</comment></comment></comment></comment></comment><comment><USER30> This is a great article from the Atlantic profiling air force pilots and the F-22: <http://www.theatlantic.com/doc/200903/air-force>.

</comment><comment><USER31> "t's not just that most of the those American air force generals began their careers as fighter pilots. No, the reason is more practical. American air superiority has largely been the result of superior pilots. The U.S. didn't always have the best aircraft, but they always had the most talented and resourceful pilots. And that's what gave the U.S. its edge. Will that translate to software piloted fighters? Research to date seems to indicate it will."

I really need some real non-american references to believe in such a thing.

<comment><USER16> In WW2 German fighters were technologically superior. In Korea Russian MiGs were superior (the Sidewinder missile was developed specifically to combat MiGs that could cruise at an altitude American fighters couldn't reach, swoop down to attack, then return to safe altitude). Even in the Cold War, the MiG-25 could out-run any American fighter.

Whether the quality of American pilots was decisive in any of those conflicts is debatable, but the first part is certainly true. Many observers believe the Eurofighter Typhoon to be the most advanced fighter in the world today.

</comment></comment><comment><USER10> There was an excellent article in Esquire on UAVs, which focused on the daily lives of UAV operators: <http://www.esquire.com/features/unmanned- aircraft-1109-2>

Pretty amazing stuff. Most missions in Iraq and Afghanistan are flown via satellite from the US, truly remote controlled war. (Submitted it to HN at the time, but it only got 2 points ;))

</comment><comment><USER32> Remote-controlled war planes will probably return to being thought of as a niche/specialist weapon after the first time they are launched against an enemy with some actual engineering know-how. (Consider battery/solar-powered Tesla coils lofted on weather balloons, by the hundreds. Hell, spoofing GPS will probably do the trick.) Any signal can be jammed - especially a critically real-time one.

<comment><USER33> Given good enough automation, critical real-time signals will become unnecessary.

<comment><USER32> Barring Strong AI, the ultimate command to fire will remain under human (remote) control.

Navigation also requires a radio signal (unless you can shrink the mechanical inertial guidance system used in submarines to a flyable size; this is not only difficult but would likely raise the cost of the drones to heights extraordinary even by US military standards.)

<comment><USER34> Navigation does not require a radio system. Terrain Contour Matching aided by by Inertial Navigation Systems allows for fully autonomous navigation - <USER2> had this working with 1970s era Technology (Try and recall what a computer was like in the Mid 1970s and continue to be amazed at what engineers could get to work in a missile)

It was a big deal in Canada in the Late 80s/Early 90s - the United States used to test their (hopefully unarmed) cruise missiles over Canada - presumably we had a terrain profile that was useful to them. Or maybe it was the long stretches of unpopulated environment.

Now consider what your typical iPhone would be capable of doing. (Compass, GPS, Terrain Maps, Camera, Radio Signal...)

</comment></comment></comment></comment><comment><USER35> The article states that countries that want to attack the US are excited about this. The article forgets to mention that the US is doing most of the research into this field.

<comment><USER16> There's no data to support that. Who knows what China or India is working on? Even Iran is in this game.

<comment><USER36> While you are correct that we don't have any actual information to show that in this thread, it would seem plausible (if you compare the amount of money that the U.S. spends on research and the air force vs. e.g. Iran) that America's doing most of the heavy lifting here.

</comment></comment></comment><comment><USER37> Posted a related link a couple of weeks ago:

<http://news.ycombinator.com/item?id=898214>

</comment><comment><USER38> This is the beginning of a long-term trend, from a physically present combat force to an army of remote teleoperators.

<comment><USER39> Nope. Fighter planes are a special case because they're both significantly cheaper and with better performance without a pilot on board. I don't see infantry replaced any time soon.

<comment><USER16> Writer Lewis Page points out that the Infantry are the only branch of the military who can do something _other_ than blow stuff up from a distance. Demand for that type of operation is only going to increase.

Meanwhile the UK govt is cutting Infantry battalions and investing 10s of billions of GBP in Eurofighter and Nimrod. Because the Taliban's airforce and _submarine fleet_ are obviously the biggest threats we face...

Note also that it's only the USAF who require trained pilots to operate UAVs... Everyone else uses automated landing systems (etc) and regular troops fly them. It's one of the featured jobs in the British Army's recruiting campaign, there's a guy with a handset similar to an Xbox controller scouting ahead of his unit as they patrol.

</comment></comment></comment><comment><USER40> Thanks for posting this, very interesting.

More stuff like this on HN please.

</comment><comment><USER41> Also there is no way a program would have pulled off that 'land in the hudson river' thing that guy did a while back.

Everyone would have died on a computer plane.

</comment><comment><USER41> I think the Korean War will turn out to have been the golden age of the fighter pilot.</comment>


Humans are slamming into driverless cars and exposing a key flaw - <AUTHOR> https://www.autonews.com/article/20151218/OEM11/151219874/humans-are-slamming-into-driverless-cars-and-exposing-a-key-flaw <comment><USER2> Easy solution. Make ALL cars follow the law just as strictly as the driverless ones do. Cameras everywhere for enforcement. If driverless cars are a thing, then there's no reason we can't punish people by permanently taking away their drivers licenses for making even small mistakes.

When you drive, you are taking life and death into your hands. It's the ultimate responsibility. Cars kill as many people as guns in the US. If you don't take driving extremely seriously, or are incapable of doing it at an expert level without mistakes, then you shouldn't have the privilege of doing so.

<comment><AUTHOR> That will be just as easy as enforcing gun control. No politician would survive - American society is predicated on everyone being able to drive anywhere, anytime.

In the _vast_ majority of the US, if you can't or won't drive, you are regarded as abnormal, almost sub-human. A colleague of mine was eventually driven to the situation of having a non-drivers drivers license, because no one would accept checks without him showing his drivers license. And no, his passport wouldn't suffice, because the people behind the counter had never seen one and didn't accept that it was valid ID.

You'll never enforce stronger driving laws - driving is seen as a right, and you'll _never_ take it away.

<comment><USER3> Who said anything about stronger driving laws or taking away the right to drive? Whether or not you have the right to drive, you don't have the right to drive illegally - with today's laws.

These cars are, no doubt, going to have cameras and sensors everywhere, so I'd say forget about putting cameras everywhere, just use the on-board cameras/sensors on the driverless cars themselves to catch people breaking driving laws.

<comment><AUTHOR> I was responding to this:

        ... there's no reason we can't punish people by
        permanently taking away their drivers licenses
        for making even small mistakes.

That would require stronger driving laws.

</comment></comment></comment></comment><comment><USER4> Another interesting element to this is basic human body and behavioural language that can be used to telegraph intent.

As a pedestrian, making eye contact with a driver in order to determine intent is a key element of safety (which is why I detest folks who tint their windshield or front driver/passenger windows). The same is true driver-to- driver... folks often telegraph their moves via lane position, head movement, etc, before they actually make them, allowing an attentive driver to anticipate what someone else is going to do.

Automated vehicles obviously can't provide those signals, which may cause human drivers to struggle to predict their behaviour; doubly so if, as the article points out, they already operate in a way that violates local social norms among human drivers.

Worse, this can vary from place-to-place. Around the valley, extreme high speed on the freeway might be the norm, where elsewhere, that might be the exception (certainly around here, anything beyond 10kph above freeway speeds is atypical). Do these companies, then, need to somehow dynamically adjust to local norms?

</comment><comment><USER5> I too wonder about the choice of running into a bus of children or driving off a cliff. It presupposes that the car will get into that situation in the first place (which I have heard argued as unlikely) but when it does, what does it do. If it chooses to kill the occupants (drive off the cliff) then the vehicle manufacturer faces a wrongful death suit, if it hits the bus full of kids (and maybe injures/kills some) then its the bus driver's liability (we're assuming that if the bus were driving in a safe, predictable way the car won't have to make this choice).

So the manufacturer decides, take out the bus, we don't want to be liable. But the human occupant might have decided differently. There is at least a twilight zone episode in there. Asimov plowed the conundrum often in his robot series and it was one of the reasons I really enjoyed those books.

</comment><comment><USER6> Sounds like the problems will resolve on their own over time. As long as human drivers are at fault, they'll get more tickets, increased insurance rates, required defensive driving classes, etc.

I'm always pleased to see a vehicle other than mine that doesn't speed. I welcome the day one of them is driverless.

</comment><comment><USER7> First sentence reads like a huge shill. No thanks

> The self-driving car, that cutting-edge creation that's supposed to lead to > a world without accidents, is achieving the exact opposite right now: The > vehicles have racked up a crash rate double that of those with human > drivers.

</comment><comment><USER8> The key flaw is the humans!</comment>


Please do not port software to Windows (2001) - <AUTHOR> http://www.fefe.de/nowindows/ <comment><USER2> "companies like Microsoft try to limit people's freedoms."

According to the author this is bad. I agree with this point for the purpose of this discussion.

The author tries to limit people's freedoms.

The author tells me _I_ should try to limit people's freedoms.

For the sake of their freedoms.

P.s. I'm not familiar with the author or their software.

P.p.s. Luckily there's less need to port Linux software to Windows these days since Microsoft has partnered with Ubuntu to create a Windows Subsystem for Linux which is capable of running an Ubuntu user space and bash shell directly on Windows.

See [https://msdn.microsoft.com/en- us/commandline/wsl/about](https://msdn.microsoft.com/en- us/commandline/wsl/about)

and [https://msdn.microsoft.com/en- us/commandline/wsl/install_gui...](https://msdn.microsoft.com/en- us/commandline/wsl/install_guide)

<comment><USER3> No, the author doesn't try to limit anyone's freedom, he only asks people to understand him and to work against proprietary platforms, not prohibits them to do anything.

<comment><USER4> He doesn't prohibit them because he can't. He directly says as much in the second line of his piece. IF he could limit you, he would.

He then goes on to say that he won't permit his software to be compatible with other platforms like Visual Studio, _even at the cost of performance_.

If that's not cutting your nose off to spite your face, it's still definitely a direct attempt to limit your freedom.

<comment><USER3> No, he doesn't say that if he could he would limit you and that he won't permit his software to be compatible.

</comment></comment></comment></comment><comment><USER5> The author (Fefe) is a well-known member of the Chaos Computer Club (CCC). He has a well-known blog (in German) about hacker news that is widely read.

[https://en.wikipedia.org/wiki/Felix_von_Leitner](https://en.wikipedia.org/wiki/Felix_von_Leitner)

[https://de.wikipedia.org/wiki/Fefes_Blog](https://de.wikipedia.org/wiki/Fefes_Blog)

<comment><USER6> The CCC however hosts many productive, far less hostile members and positions!

Not that you implied different, but I think that this text isn't a great example for the many cool things the CCC does.

[https://www.ccc.de/en/](https://www.ccc.de/en/)

<comment><USER5> Yes, I agree. Also, this text is quite old and isn't all that representative of his blog either. The blog takes controversial positions, but is entertaining at the same time. It's sort of like a yellow-press newspaper for CCC hackers, if that makes sense.

</comment></comment></comment><comment><USER7> What an amazingly childish attitude. It's hard to have any respect for extremists like this - and that's exactly what they are. Extremists.

</comment><comment><USER8> Don't worry, nobody will.

If you hate people who use windows, then don't be surprised if they do same to you.

<comment><USER9> Looking at the list of code that this person created, I don't think it's wanted on Windows anyway. It's just a bunch of low-level utils that are already built-in to Windows or have better third-party alternatives.

If this guy had built something good like VLC media player - nobody would have listened to him and it would have been forked, ported and his version would have been forgotten by now.

(Oh and I bet more than half of his crummy apps will easily run on Apple's OS and Apple is arguably worse than Microsoft had ever been.)

</comment></comment><comment><USER10> I always find this sort of argument in the name of freedom interesting and perhaps a bit disingenuous. The GNU activists (for lack of a better generalization) actually do not argue for more freedom of choice, but rather only for who should have that freedom: whether freedom of choice rightfully belongs to the developer or the user, the producer or the consumer. By arguing chiefly for "greater freedom" they avoid the issue of why they consider the producer of a product as deserving a lesser moral latitude than a consumer of the product; their appeal becomes not a rational appeal for why, on moral grounds, a developer should be less free and instead make an emotional appeal to the users that they are entitled to the product as a moral imperative. It seems to me, the GNU activist is not making an argument about freedom whatever, but is essentially arguing for an application of altruism to the world of software development.

I think the author of the article makes that alternative intent of the movement clear in that they are uncomfortable with the freedom actually offered by GNU licenses. If even as a user of GNU software you somehow can perceived as helping a non-Libre developer (no matter how indirectly) you are condemnable morally by the reckoning of the author. I find this consistent with my assertion that the argument is not one of greater freedom, but philosophically an altruistic one.

</comment><comment><USER11> This article seems polite enough. The author gives some rational reasons, and at least marks the opinion parts with "I feel" type qualifications.

Why is everyone just picking apart the logic behind this? It makes me (a Linux user) think that Windows-ecosystem people feel entitled to a port of all software, "because Windows".

<comment><USER12> > It makes me (a Linux user) think that Windows-ecosystem people feel entitled > to a port of all software, "because Windows".

Actually it's quite the contrary, when you maintain a Windows-only piece of software you get constantly bugged by the few dozen Linux / OS X users.

I mean, your OS selection happened because "the many benefits your favorite OS brings you over Windows are way more important than not having software".

If you really want to run Windows software, why not install Wine, VirtualBox, or... Windows?

</comment></comment><comment><USER13> Attitudes like this are one of the many reasons why porting complicated OSS software (like SageMath) to Windows is so hard.

<comment><USER14> Hardly. This attitude is very rare among FOSS devs, the more common one being "I don't care if it works on Windows or not, as I don't use it; if you are willing to make it work on Windows with in way that does not make codebase suck too much for the rest of the world, go ahead, I accept patches".

<comment><USER13> You are right - this is just _one of many_ difficulties...

<comment><USER14> Well, I consider it perfectly fine and in line of what one can expect from FOSS. I develop what I want to develop, and you develop what you want. If we can collaborate, great, if not, we create separate projects.

</comment></comment></comment></comment><comment><USER15> A couple years later the author was involved in a security audit for Windows Vista: [https://blog.fefe.de/?ts=a81a5919](https://blog.fefe.de/?ts=a81a5919)

</comment><comment><USER16> He knows I can just open up a linux vm right???

</comment><comment><USER17> Well this is stupid, People need their freedom limited to make the software easier to use to some extent. So it's stupid argument he makes for his bias against windows. You like linux ? Fine, use it as you will. But don't prevent from others use whatever they feel comfortable to use. And nobody will listen to him. Unless he made his own specific Licence. Which could be problematic. But this kind of extreme behavior won't help people try to use Linux.

</comment><comment><USER18> Sure, then don't complain others don't port their software to your platform of choice.

</comment><comment><USER19> Sun? This must be 10 years old at least... (Or the author has not stepped out from the basement where he/she lives in the last decade)

Also after having checked his/her works I'm not sure why would anyone want to use them (on windows or otherwise). For most of them there are other alternatives with less bigot authors for whom, if needed, one might even send contribution.

Bigots like Stallman or this author do the most harm to the image of free software movement.

<comment><USER20> Freeloading seems to be ok for you, but if the free software comes with any kind of sentiment or vision, you call the authors bigots? Thanks. Noted.

<comment><USER19> In my definition of freedom no visionary should tell me what can I do or can't. Actually I don't consider GPL and derivatives free licenses.

<comment><USER20> That's great for you and all. And should you ever publish open source software, slap on any license you wish.

Calling other people bigots because you don't think their idea of free is free enough, however, is _very_ bad taste.

<comment><USER19> A gentleman does not argue about taste.

<comment><USER20> I beg to differ. Especially if anyone's public actions or expressions are of bad taste, it ought to be a matter of discussion.

Matters of _preference_ (another meaning of "taste"), however, are hard to argue about.

<comment><USER19> > I beg to differ. Especially if anyone's public actions or expressions are of > bad taste, it ought to be a matter of discussion.

I agree. that is why we are discussing why calling people who use windows ignorant supporters of evil is a form of bigotry.

<comment><USER20> > calling people who use windows ignorant supporters of evil Huh? Where does > it say that in the post? I'm getting the feeling that someone insulted your > favorite OS and now you think they are fanatic bigots. The text over 15 > years old. Maybe you just don't remember the Windows and Microsoft from back > then.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER21> EDIT: Just saw this is from 2001, so may be a tad bit justified in the MS context. I still stand by the "goes against the community spirit" thing though.

Doesn't this sort of closed-mindedness fly in the face of the spirit of FOSS and community? Plus, today's MS is not the evil empire of yesterday. I'd rather be in bed with them than, say, Oracle. Long time Java hating .NET guy here- so I am probably biased though.

<comment><USER14> I believe you are mistaken and giving them a too easy pass. They have improved, but not by much:

[1] [http://www.infoworld.com/article/2841412/open-source- softwar...](http://www.infoworld.com/article/2841412/open-source- software/microsoft-attacks-open-source-linux.html)

[2] [https://nudgedelastic.band/2016/01/i-am-still-not-buying- the...](https://nudgedelastic.band/2016/01/i-am-still-not-buying-the-new-open- source-friendly-microsoft-bullshit/)

[3] [http://www.infoworld.com/article/3042699/open-source- tools/m...](http://www.infoworld.com/article/3042699/open-source- tools/microsoft-loves-open-source-only-when-its-convenient.html)

</comment></comment><comment><USER22> I agree with this 100% Microsoft is responsible for destroying creative and better software than it produces itself If you cannot see the obvious you are part of the problem

</comment><comment><USER23> What about OS X?</comment>


Typeclassopedia - THE tutorial to understand typeclasses in Haskell - <AUTHOR> http://www.haskell.org/haskellwiki/Typeclassopedia

<comment><USER2> (this may be daunting; if one's not reasonably versed in haskell basics, read last 5 chapters of

<http://learnyouahaskell.com/chapters>

<comment><AUTHOR> I did read [http://learnyouahaskell.com/functors-applicative-functors- an...](http://learnyouahaskell.com/functors-applicative-functors-and-monoids/) and found myself unsure if I had understood anything at all. (Not a reflection of this book - which I do agree is fabolous.) And now am reading both (last 5 chapters) and this wiki in tandem.</comment></comment>


Social Distancing Is Over - <AUTHOR> https://www.washingtonpost.com/opinions/social-distancing-is-over/2020/06/05/73403a10-a750-11ea-b619-3f9133bbb482_story.html <comment><USER2> Yawn. Yes they do spread virus, as they did on March 8's in Madrid, and on the soccer play in Italy. And hey, yeah on the market in Wuhan.</comment>


Crockford on JavaScript -- Part 5: The End of All Things - <AUTHOR> http://developer.yahoo.com/yui/theater/video.php?v=crockonjs-5

<comment><USER2> Crockford cast the demons from ye scripture. I praise thee.

"I prefer to make the structure of my programs self-illuminating, eliminating the need for comments."

\--Douglas Crockford</comment>


Dear Lars, next time don't stop doing that weird drug  - <AUTHOR> http://scobleizer.com/2010/11/01/dear-lars-next-time-dont-stop-doing-that-weird-drug/ <comment><USER2> Google Wave is an excellent example of why it's so important to manage expectations. If it was released as being a nifty tool for early adopters, and given a few years to iterate based on user feedback, it could have lived up to its charge of becoming the new standard for collaboration and communication. Instead, it left people disappointed by promising everything before it was done cooking.

I'm still hopeful that the codebase will be worked on by the OSS community, and/or some enterprising hackers will come along and implement the core concept more effectively.

<comment><USER3> It's interesting that you mention wanting someone to implement the "core concept" more effectively, because I think that one of the biggest problems with Wave was that it didn't have a well-defined core concept. It was billed as the Next Big Thing, the replacement for email and instant messaging and everything else, but it wasn't particularly good at doing any of them, and nobody had any real idea of what it was supposed to be doing. "Do everything well" is a pretty problematic core concept.

I do think that something can be a subset of Wave's functionality and still be useful (I use Flowdock[0] every day, and wrote GitChat[1] for Rails Rumble, and both are essentially web-based persistent chat applications). However, I'm unsure if Wave's codebase is the best place to start. It's very hard to apply a new (much narrower) focus on top of an existing project than it is to start from scratch.

[0] <http://flowdock.com/> (Persistent chat with searchable tags, uploads, and some other useful features.)

[1] <http://gitchat.com/> (Flowdock-inspired persistent chat for open-source GitHub projects. Originally developed for Rails Rumble, and we haven't had a chance to work on it since, so it's still very buggy. It will definitely be stabilized/improved at some point though.)

<comment><USER4> The core concept is: a robust method for automatically merging concurrent changes to a published resource by collaborating users in real-time (OT). It's true that other key components of Wave were seen as essential to its success (in particular the federation protocol and the bots API) but those were still designed in support of the core use-case: real-time collaborative editing.

There was a ridiculous amount of hype about the project and all the things it might replace but that doesn't change the fact that its development was and is focused on solving an actual problem using real technological innovation.

<comment><USER3> This is actually exactly what I meant by a lack of focus. That may be the focus of the underlying codebase (and that may be where the innovation is), but the UI was just really a glorified chat room. It wasn't particularly suited to actually _doing_ real-time editing.

<comment><USER4> The UI from Google was little more than proof-of-concept. The ability to sync arbitrary data, not just chat text, on the fly is what will make Wave useful if it ever sees wide adoption. That really _is_ the core concept and not chat, as many seem to think. It's not accurate to say that there's no core concept.

</comment></comment></comment></comment></comment><comment><USER5> _"On Facebook they don't have spam. Why not? Because, unlike Google Wave, only people who I've friended AND who friended me back can send me messages. That's how Wave should have worked."_

I guess that depends on your definition of spam. To me, reminders every minute of what an acquaintance is doing certainly IS spam.

<comment><USER6> At least you can remove the annoying friends from your Facebook if you want.

</comment></comment><comment><USER7> When I could get my business partners to use Wave, we found it to be a very good brainstorming / organization tool. I still think there is an opportunity for someone to build a product on its open-source foundations: <http://code.google.com/p/wave-protocol/>

</comment><comment><USER8> "Everything we do needs to be shared. Everything."

Congrats, Zuckerberg would be proud of you. (pukes)</comment>