Multiple OS Vendors Release Security Patches After Misinterpreting Intel Docs - <AUTHOR> https://www.bleepingcomputer.com/news/security/multiple-os-vendors-release-security-patches-after-misinterpreting-intel-docs/ <comment><USER2> At first I thought this was an error in implementing new docs related to Meltdown/Spectre. But the original research paper:

[https://everdox.net/popss.pdf](https://everdox.net/popss.pdf)

the researcher wrote:

> _Somewhere around the release of the 8086, Intel decided to add a special > caveat to instructions loading the SS register...where loading SS with [`pop > ss` or `move ss`] would force the processor to disable external interrupts, > NMIs, and pending debug exceptions._

So it's a really, really old piece of documentation, dating from around 1980.

To call it a 'misinterpretation' rather than a vulnerability is extremely generous, given that most Intel engineers spent entire careers in the presence of code vulnerable to this 'misinterpretation' without calling the OS vendors out on their error.

<comment><USER3> On this particular thing I think the Intel docs are clear. This is where I implemented the same in JPC:

[https://github.com/ianopolous/JPC/blob/master/src/org/jpc/em...](https://github.com/ianopolous/JPC/blob/master/src/org/jpc/emulator/execution/decoder/Disassembler.java#L351)

<comment><USER4> The interrupt shadow itself is clear.

The specific implication of that for a mov ss ; syscall pair with a hardware breakpoint set on the first instruction is a lot more subtle.

<comment><USER3> Agreed, but that's just saying that combining two or more simple things results in a more complex thing. All platforms I know of describe each individual instruction and its consequences, and leave you to deduce the consequences of combining them.

</comment></comment></comment></comment><comment><USER5> I'm trying to understand this one, even if most of my ASM knowledge is from the 8086 era. My guess:

* When an interrupt, debug exception, ... occurs, the CPU pushes stuff on the stack as part of the task switch.

* The stack is managed by 2 registers: SS and (e/r)SP. To change your stack, you have to change both registers. If an interrupt happens and you've changed only 1, stuff gets pushed on an invalid stack and you're toast.

* To fix this, the CPU has a wild card: When you change SS, you get exactly 1 instruction that will not be interrupted. The idea is you use that instruction to change (e/r)SP and make the stack valid again. If there is a need for an interrupt, it will be delayed for 1 instruction.

* Now this being a security problem, what would happen if you use this second instruction to switch to kernel mode ? It turns out the delayed interrupt happens before the first kernel mode instruction, but in the kernel.

* And you can trigger the right kind of interrupt with debug exceptions and single stepping.

* And if you do this, the kernel tells the debugger not about the debugged program but about the kernel. Oops.

So to fix this, I suppose the kernel checks the debug exception info from the CPU, and if it is debugging the kernel it fixes things up so you go back 1 instruction.

<comment><USER6> > To fix this, the CPU has a wild card: When you change SS, you get exactly 1 > instruction that will not be interrupted. The idea is you use that > instruction to change (e/r)SP and make the stack valid again. If there is a > need for an interrupt, it will be delayed for 1 instruction.

I wonder, why could not they make a single instruction to change both SS and SP?

<comment><USER7> They could, but attackers would still use the approach that works for them.

And they can't really remove the old instructions because of backwards compatibility.

Whitelisting a limited set of instructions that can follow setting SS and making all others trap might be an option, though. It still would break backwards compatibility, but if the effective impact would be negligible, they could deem it acceptable.

<comment><USER7> Follow-up: not only could they, they did. [https://software.intel.com/sites/default/files/managed/7c/f1...](https://software.intel.com/sites/default/files/managed/7c/f1/253667-sdm- vol-2b.pdf), page 4-385:

"Loading the SS register with a POP instruction suppresses or inhibits some debug exceptions and inhibits interrupts on the following instruction boundary. (The inhibition ends after delivery of an exception or the execution of the next instruction.) This behavior allows a stack pointer to be loaded into the ESP register with the next instruction (POP ESP) before an event can be delivered. See Section 6.8.3, "Masking Exceptions and Interrupts When Switching Stacks," in Intel® 64 and IA-32 Architectures Software Developer's Manual, Volume 3A. _Intel recommends that software use the LSS instruction to load the SS register and ESP together_."

</comment></comment></comment></comment><comment><USER8> As far as I understand, what's happening is:

* There's an old feature which causes POP SS/MOV SS instructions to delay all interrupts until the next instruction has executed, to safely allow changing both SS and SP without an interrupt firing inbetween on a bad stack.

* If such an instruction itself causes an interrupt (by triggering a memory breakpoint through the debug registers), it is delayed (as intended).

* The delayed interrupt will fire after the second instruction _even if the second instruction disabled interrupts_.

* By means of the above, a MOV SS instruction triggering a #DB followed by an INT n instruction will cause the #DB exception to fire before the first instruction of the interrupt handler, even though this should be impossible (as entering the handlers sets IF=0, disabling interrupts).

* The OS #DB handler assumes GS has been fixed up by the previous interrupt handler, which in now under user control.

</comment><comment><USER9> The x86 ISA and its implementations are now in the spotlight of the whole security research community. There is probably a lot more to come since it accumulated a lot of cruft in the name of backwards compatibility.

I hope we learn a lot, and take the time to record the experience, for coming platforms like RISC-V and others.

Why is there no big CAVEATs document from intel detailing weird quirks. I strongly assume the intel arch engineers are well aware of many of those counter-intuitive behaviours in their products.

<comment><USER10> > I strongly assume the intel arch engineers are well aware of many of those > counter-intuitive behaviours in their products.

But it is likely just kind of distributed, organic knowledge that is hard to condense into a single document. Writing and maintaining such a thing would be a significant project, and (I am speculating here) not the kind of thing that significantly burnishes anyone's performance review.

That said, the whole community of assembly-hackers has even broader knowledge of the topic, and could start such a document out in the open. And Intel engineers might likely contribute their own two cents. (Unless lawyers forbid it).

<comment><USER9> I stumbled on a blogpost by bunnie huang which describes a liability angle, which I found to be plausible: [https://www.bunniestudios.com/blog/?p=5127](https://www.bunniestudios.com/blog/?p=5127) \- worth a read.

</comment></comment></comment><comment><USER11> Wow, the article shows that many vendors mis-read the docs: Apple, Microsoft, FreeBSD, Red Hat, Ubuntu, SUSE Linux, and other Linux distros...as well as VMware and Xen.

This is going to be a busy day!

<comment><USER12> > Apple, Microsoft, FreeBSD, Red Hat, Ubuntu, SUSE Linux, and other Linux > distros.

Just to clarify, this is kernel code. Listing 3 different (+ "other") Linux distros as affected is kinda bogus, it's not that they all made the same mistake, they just all use the same kernel.

<comment><USER13> Many of them use different versions of the same underlying Linux kernel, sometimes put together in different ways.

<comment><USER14> It seems improbable that there are multiple ways of putting together the kernel's handling of mov ss.

<comment><USER15> As an example, Red Hat doesn't ship major kernel upgrades except with major releases. If you're running RHEL 6, you're still on a 2.6 kernel and the fact that someone patched 4.x probably doesn't help you all that much unless you have the time to backport the change and confirm that it doesn't break something else.

</comment></comment></comment></comment></comment><comment><USER16> "Both Peterson and the CERT/CC team blamed the "unclear and perhaps even incomplete documentation"

Yet the article's title makes it seems like it was the OS implementors faults instead of Intel's.

I wonder for what reasons the website tries to shift/soften Intel's fault on this?

Seems like there's a trend in news articles to have incoherent titles in relation to content lately, it's really annoying...

</comment><comment><USER5> I wonder what happens if you execute multiple POP SS instructions. In fact, you could set up a 64K v86 mode segment containing only copies of the POP SS instruction. jmp far into it. When IP reaches the last instruction it wraps around and starts again. Will it ever be interrupted by anything? If the stack usage bothers it, just do MOV SS,AX

<comment><USER17> Tested it: you get an interrupt after only skipping one instruction

<comment><USER5> Thanks, both dooglius and Someone. One learns something everyday.

</comment></comment></comment><comment><USER18> > Fixing the bug and having synchronized patches out by yesterday was an > industry-wide effort, one that deserves praises, compared to the jumbled > Meltdown and Spectre patching process.

Is this a fair comparison? I feel like the patching techniques must have been easier to develop than for Meltdown/Spectre. Furthermore, if this affected the same kind of people in this community, maybe this time around benefitted from the communication channels of the previous exercises.

Maybe this isn't a comparison to try and badmouth the previous iteration, and instead just tried to show a general improvement in the industry—I just find it a bit unfair.

<comment><USER19> This is one of the first times that I know of that the Linux kernel and Windows kernel developers discussed a security issue together directly. So while the fix was much simpler than Meltdown/Spectre was (Linux was fixed with a patch that was written in 2015) overall, the communication between different OS kernel developers right now is very good.

And yes, it is all due to the horrible Meltdown/Spectre problem and how that was handled. We were not allowed to work together for that problem, and we do not want to that to happen again.

<comment><USER20> > We were not allowed to work together for that problem

How do you mean?

<comment><USER21> It was covered by NDA.

</comment></comment></comment></comment><comment><USER22> Interesting that some of the BSDs (Dragonfly, FreeBSD) are listed as Affected and others (NetBSD and OpenBSD) are listed as Not Affected.

<comment><USER23> Dragonfly descends from FreeBSD so it makes sense that it's affected.

The other BSD's have different kernels and vastly different development histories as well.

<comment><USER24> Some BSDs never allowed debug register writes in the first place, so they were immune.

</comment></comment></comment><comment><USER25> It's been so long I had to look it up: SS is the stack segment.

<comment><USER26> And furthermore, the current stack address is determined by the combination of two registers: ss for the segment and rsp/esp/sp for the stack pointer within the segment. I guess the strange behavior around modifying ss comes from the fact that you need to also modify sp immediately afterwards, because otherwise you are running with a wild stack address pointing to random memory. You also can't modify sp before modifying ss because then you are also running with a wild stack, and an interrupt could come in at any time and push things onto random memory.

</comment></comment><comment><USER27> I felt a great disturbance in the Force, as if thousands of voices suddenly cried out, _" Oops..."_

</comment><comment><USER28> The vulnerability notes[1] say Apple patched this on May 8, but my last security update was May 3 and I don't currently show any available updates... I wonder if the May 3 patch fixed this, or if my computer might not be affected.

[1][https://www.kb.cert.org/vuls/byvendor?searchview&Query=FIELD...](https://www.kb.cert.org/vuls/byvendor?searchview&Query=FIELD+Reference=631579&SearchOrder=4)

<comment><USER24> The May 3 patch fixed it. The nature of the fix was such that Linux and Mac OS were able to patch it early without revealing much.

In fact, the Linux fix was a patch I wrote in 2015 (for unrelated reasons) and just never got around to upstreaming.

<comment><USER29> Link to referenced patch: [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d8ba61ba58c88d5207c1ba2f7d9a2280e7d03be9)

</comment></comment></comment><comment><USER30> I'm super happy to see that the BSDs were contacted (with the exception of HardenedBSD).

<comment><USER31> HardenedBSD would just receive it downstream from OpenBSD, wouldn't it? It's like contacting the Linux Mint group while contacting Ubuntu is sufficient.

<comment><USER30> HardenedBSD is a separate OS forked from FreeBSD with its own kernel development. While the BSDs may share some code, they're essentially all different OS'. There is no upstream like Linux has. As a side-note after Spectre/Meltdown, Shawn Webb complained in a NYCBUG thread about getting not being able to get access to these embargoed vulnerabilities.

</comment></comment></comment><comment><USER32> Is there a PoC exploit source?

<comment><USER24> [https://lkml.kernel.org/r/67e08b69817171da8026e0eb3af0214b06...](https://email@example.comfirstname.lastname@example.com)

</comment></comment><comment> emily-c A bit tangentially related, but I've always wondered why the syscall instruction doesn't use the TSS for stack switching like int does. I guess it does give you more flexibility to load rsp from gs during a cpl 3 -> cpl 0 transition rather than consulting the TSS to switch it automatically. Can anyone weigh in on this?

</comment><comment><USER33> Can someone explain the risk factor? It cannot be remotely exploited or though browser if I'm reading it right. But a malicious program with user level access can get kernel access. So exposure to malware running on a limited account can get higher access?

</comment><comment><USER34> Archived version: [http://archive.is/DxUwA](http://archive.is/DxUwA)

</comment><comment><USER35> Is this also affecting code in 64 bit mode?

<comment><USER36> As the code in the paper is written for amd64 I would assume that it is affecting it.

In the other hand it is somewhat surprising, because loading anything into SS is mostly pointless operation.

<comment><USER35> This doesn't even make sense. Why would they keep a behavior that could be considered a bug when creating a new instruction set?

</comment></comment></comment><comment><USER37> Was illumos not affected?

</comment><comment><USER38> I'm sure the initial reaction here is going to be lamentation about the state of documentation. People will correctly point out that, if multiple entities misread the documentation, it just have been unclear. And they are right. But that doesn't make this Intel's fault alone. Clear or unclear, the documentation described behavior that was understood at the Intel organization, and the shipped product worked as described.

Where was the security testing at the OS level? Why can't there be automated test suites that catch unauthorized access issues before ship (if not before merge commit)? If your vendor delivers an insecure product and you don't discover it, how much blame do you share?

<comment><USER39> _Why can 't there be automated test suites that catch unauthorized access issues before ship (if not before merge commit)?_

Usually the search space is too large.

<comment><USER40> Isn't that what fuzzing is for?

<comment><USER41> Concolic testing would probably catch it, but only if the person that implemented the hardware model for the theorem prover understood the Intel documentation, which seems unlikely.

Basic fuzzing probably wouldn't catch this; as the other comments point out, the search space is probably too large, and the set of vulnerable executions is probably too small for an undirected random search.</comment></comment></comment></comment>


Pakka – The Smart, Secure Package Delivery Portal - <AUTHOR> http://nextpakk.com/smart-package-delivery-with-pakka-prevents-stolen-packages-and-missed-deliveries/ <comment><USER2>
      Wi-Fi enabled

What could possibly go wrong?

</comment><comment><USER3> That's a very small slot for putting packages through.

How do you handle a box?</comment>


Russell Beattie ends Mowser - <AUTHOR> http://www.russellbeattie.com/blog/the-end-of-mowser

<comment><USER2> no comments on the page - just wanted to give russel props for pursuing his dream and then putting himself out there when it didn't materialize. From the sound of it many people would have quit long before he did. @Russel: thanks for sharing your story.

</comment><comment><USER3> Among other things, this just proves the point: "the day job will be there for if your startup doesn't work out".

Well, at least he took a shot. Most people never get around to taking one.

</comment><comment><USER4> I use Mowser to browse on a slow connection. It's so much better than the alternatives (google mobile, phonifier) since it scales images as well.

Sorry to see it go.

</comment><comment><USER5> Wow. That was one honest blog post. After reading it I get the feeling that Russ sees the world clearly and will be on his feet again in no time.

</comment><comment><USER6> Solid technology, not so good marketing and positioning

</comment><comment><USER7> Sounds like you stuck with it as long as you could. Well done. Hope you learned a lot.

</comment><comment><USER8> Wow. That site is good. It makes for very fast browsing. I can make sure all text reasonably fits in a narrow area. Great for window management on my laptop.

</comment><comment><USER9> What is/was Mowser? There's no obvious link in the article. I'm guessing it had something to do with mobile browsing.

<comment><AUTHOR> Mowser = Mo(bile) + (Bro)wser

<http://mowser.com> is the right link. From their about page: "Mowser lets you view the Web on your mobile phone."

<comment><USER10> "Mowser lets you view the Web on your mobile phone."

Which was relevent back when mobile phones didn't have fully functioning web browsers. Since the iPhone though, there's really no need for such a service :/

</comment></comment></comment><comment><USER11> Gotta appreciate the candor here.

</comment><comment><USER12> Well, not entirely a surprise. I wonder what miker will be doing now?

</comment><comment><USER13> Sad story.</comment>


IO Monad Considered Harmful - <AUTHOR> http://blog.jle.im/entry/io-monad-considered-harmful <comment><USER4> I've been writing Haskell code for years, and this is one of the most singularly _useful_ articles I've read on it. I've certainly found the proliferation of "monad tutorials" and "learn this so you can print something" guides obnoxious, but it never occurred to me that IO really could be taught completely separately from monads.

Here's the outline of what the middle of a tutorial could look like, following this advice:

Here's how to print a string (putStr, putStrLn). Here's how to print something other than a string (show, print). Here's how to print two somethings in a row (>>). Here's how to read something and print that (>>=). Here's how to print something in a function other than main (:: IO ()). Here's how to read something in a function other than main (:: IO a, >>= again, return). Oh by the way, it turns out that pattern (return, >>=) is so common that Haskell gives it a special syntax (do notation). For instance, it works with the previously introduced Maybe. And with List. Remember typeclasses? You can write functions that work with IO, Maybe, _and_ List (Monad m => ...).

Even when actually talking about monads, the explanation should come first, and the term should come later. "It turns out these operations are a common enough pattern that Haskell gives them special syntax..." comes across much more sanely than "now we're going to introduce something [complicated] called a monad".

<comment><USER5> I think your suggestion is a relative improvement over most tutorials. But it's still unmanageably hard.

"Here's how to read something and then print that: >>=". Sure, like `getLine >>= putStrLn`. Technically speaking, that's correct. But this doesn't generalize at all.

Maybe I want to greet the user by name. How do I read the name, prepend "Hello, " to it, and then print that? This is a totally natural thing to want to do, and is very straightforward in Java. But our Haskell newbie hits a wall - none of your cases cover it!

Here's how I might write that today, without using do notation: `getLine >>= (return . (++) "Hello, ") >>= putStrLn`. Look at that - it's totally nuts, and I would not attempt to explain that to a Haskell neophyte.

Using do-notation, you can make things nicer:

        do
         name <- getLine
         putStrLn $ "Hello, " ++ name

but this introduces a bunch of new syntax to learn: the difference between let-in and let and <-, how do-notation works, etc.

I don't have a better approach than what you suggest. I suspect that this stuff simply can't be made easy.

<comment><USER4> > Here's how I might write that today, without using do notation: `getLine >>= > (return . (++) "Hello, ") >>= putStrLn`.

Don't write point-free code here. Here's a fairly simple version:

        getLine >>= \name -> putStrLn ("Hello, " ++ name)

The only novel thing there is the >>= operator itself. You don't even have to introduce return there; you can introduce return later.

<comment><USER6> Which can then be made to look exactly like the

      getLine >>= putStrLn

case by doing

      greet name = putStrLn ("Hello, " ++ name)
      main = getLine >>= greet

(Edited to include the definition of main)

<comment><USER5> If this is meant to be under main, you need a "let":

        main = do
          let greet name = putStrLn ("Hello, " ++ name)
          getLine >>= greet

For whatever reason, I didn't learn about the magic let syntax in do-notation until relatively late. Anyways this is very elegant, but not something I could have generated early on, especially because it mixes two different sequencing syntaxes (do-notation and >>=).

<comment><USER7> The 'do' is superfluous.

It would be much better as

        main = let greet name = putStrLn ("Hello, " ++ name)
                    in getLine >>= greet

</comment></comment></comment></comment></comment></comment><comment><USER5> I read the article, and it annoyed me, because the rebuttal is obvious and wasn't addressed.

The rebuttal is do-notation. The second program you write after Hello World is going to use two IO actions instead of one, and so you need a way to sequence them, and every tutorial is going to do that with do-notation. And suddenly all of the other syntax you learned, like how to declare a variable with let- in, or how arrows go -> that way, or how to call a function, is tossed out the window. And you'll spend ten minutes before you realize your indentation is wrong and then ten more fighting with how you declare a variable and then apply a function to it before it dawns on you, this is monads.

You don't have to use do-notation, sure. You can use >>= as an infix operator. It's still totally confusing.

The reality is that monads hit you hard and fast as soon as you want to do any IO. Not the monad laws or functors or whatever the tutorials focus on, but the nitty-gritty syntax. This is where I got stuck and gave up (twice), before I finally got it.

<comment><USER8> Yeah, no way around learning do-notation even for the simplest of programs. And do-notation is kind of a DSL with a totally different feel than the rest of the language. So getting started writing even simple toy programs in Haskell requires you to learn two languages. No denying that Haskell is a language with a very steep learning curve. (Or is it a very shallow learning curve? Never understood that metaphor. But you have to learn a lot to get started.)

However it might make sense in a tutorial or course to teach do-notation first as a DSL for IO in order to get started. And only later, when the student have a good understanding of the core language and type system, introduce monads and show how IO is a monad and how do-notation can be used with other monads.

The problem with the much maligned monad tutorials is that the audience typically is beginners who get stuck on on the IO monad and do-notation immediately after writing "hello world". But the tutorials try to explain monads as a general concept, which requires a pretty through understanding of things like higher kinded types and so on. An understanding the newbie getting stuck at "hello world" obviously doesn't have yet. Then the tutorials try to be accessible by using metaphors like a "monad is a specesuit", a "monad is burrito" etc. But knowing that a monad is a buritto doesn't help the newbie who gets inscrutable compile errors after adding a second putStrLn to "hello world".

<comment><USER9> In operations management, a "learning curve" is an efficiency curve plotted over time. I have most often seen it as a time-per-task-completed curve. The way it works is this:

The time it takes to produce widget 2 ^ t is BASE_TIME * LEARNING_RATE ^ t.

Example with 120 minute starting time and 90% learning rate:

Widget 1 (2 ^ 0) takes 120 (120 * 0.9 ^ 0) minutes to produce.

Widget 2 (2 ^ 1) takes 108 (120 * 0.9 ^ 1) minutes to produce.

Widget 4 (2 ^ 2) takes 97.2 (120 * 0.9 ^ 2) minutes to produce.

Widget 8 (2 ^ 3) takes 87.48 (120 * 0.9 ^ 3) minutes to produce.

Example with 120 minute starting time and 70% learning rate:

Widget 1 (2 ^ 0) takes 120 (120 * 0.7 ^ 0) minutes to produce.

Widget 2 (2 ^ 1) takes 84 (120 * 0.7 ^ 1) minutes to produce.

Widget 4 (2 ^ 2) takes 58.8 (120 * 0.7 ^ 2) minutes to produce.

Widget 8 (2 ^ 3) takes 41.16 (120 * 0.7 ^ 3) minutes to produce.

If you plotted a curve of minutes per widget over time, you would note that the graph for the 70% learning rate would have a much steeper slope than that of the 90% learning rate.

Looking at that you might say, "ah, high learning rates are great!" All else being equal, you would be correct. However, real world tasks with high learning rates often imply high base times and a proportionately large amount of time until proficiency or mastery is reached. That's why "steep learning curves" are "bad things", because it is going to take "a lot of effort" just to "get good" at the skill.

To bring the point home, here are some contrived examples of "90%" and "70%" skills:

Version control:

90% - copying and pasting files

70% - <USER2>

Word processing:

90% - Microsoft Word

70% - vim and latex

Databases:

90% - Excel documents in a shared folder

70% - <USER3>

Web design:

90% - your web host's website builder

70% - Ruby on Rails

70% - hand coding in notepad

This is just an introduction to the concept as I learned it. Two skills might have the same learning rate, but one might be much more productive than the other. Still this should help you understand the origin of "steep learning curve" and why that's usually considered a "bad thing."

</comment></comment></comment><comment><USER10> Here's how I like to explain Monads to people. I've been told it's a decent explanation. (It ignores the monad laws and such, but it's a decent conceptual overview.)

OK, so you know Java interfaces? Haskell has something just like that. They're called "type classes", though. But it works pretty much the same way. When you write out a class definition, you write A) the name of the class B) all the functions the class has to support and C) the types of those functions. (Like a Java interface definition.)

Haskell has a type class called "Monad". To "implement the monad interface", in Java parlance, you have to implement two functions. The first is called "bind", but it's written ">>=". Here's its definition:

        >>= :: m a -> (a -> m b) -> m b

Let's say our Monad was called `Foo`. In Java-land, this means the function takes a `Foo<a>`, a function that takes an `a` and returns a `Foo<b>`, and it uses those two things to return a `Foo<b>`.

The other function is "return", which is defined as

        return :: a -> m a

Which, in Java terminology, means it takes an `a` and returns a `Foo<a>`.

If you implement those two functions, you now have a Monad.

If you've been told that Monads do anything in particular, you've been told wrong. Monads don't necessarily have anything to do with IO, or sequencing, or state, or anything like that.

It _just so happens_ that those two functions (">>=" and "return") are _super_ useful for representing a whole lot of common things, which happen to include things like IO and stateful algorithms. Monads don't _have_ to do either of those things, but they certainly can.

<comment><USER11> Every explanation of every Haskell feature I encounter reads the same way as this. You define "return" as "return :: a -> m a" and say this means it takes "an a" (by which I assume you mean an object of type a?) and returns a "Foo" (an object of type Foo?).

The problem I have is: what on earth does this have to do with 'm'?

Is 'm' equivalent to 'Foo'?

If so, why don't you mention that? It isn't obvious to a newb who is lost in the welter of syntax.

Does 'm a' mean the same thing as Foo? If so, why not use 'Foo' in your Haskell rather than 'm', which is simply introduced without any description, mention or explanation? Is there some significance to the naming? This is the kind of question that a newb specifically cannot answer, and Haskell tutorials are notoriously lax about. They have a strong tendency to assume you know the syntax of the language, which they use to explain the syntax of the language.

You've given a nice, detailed explanation, but have failed to describe what 'm' is, and that means your average newb (me, or possibly even someone much, much smarter than me, as I'm told such people exist in profusion) is left making guesses. I'm pretty sure I know what the correct guesses are, but I really want to know: why did you use a completely different, unrelated, and opaque name for 'Foo' in your Haskell example, and then talk exclusively about 'Foo' in your explanation?

This isn't really a knock at you personally: as I said, every Haskell tutorial I've encountered has similar issues. I'm just deeply curious as to why this is the case (and painfully aware that my own explanations regarding other languages are likely as opaque to newbs as these Haskell explanations are to me.)

<comment><USER12> The fundamental problem is higher order types. When you define an interface in Java or C#, it has no way of referring to itself. Something like "compareTo" cannot say "the other type must be exactly equal to this". So lets invent such a syntax (using a keyword "as") and write the Monad interface:

        interface Monad as m {
            const m bind(m, Function<a,m>);
            const m return(a);
        }

If you fill in the implementing class for m (like IO or List or Maybe), you get the actual type signatures that would maybe be valid in C# or something.

</comment></comment></comment><comment><USER13> I've also experienced similar failures. I've tried to learn Haskell several times, and every time I meet the Monad section in the tutorial I lost my concentration. One of my friends who is proficient in Haskell told me to just start coding without trying to understand the advanced concepts, but I wasn't inclined to do that as Monads were hanging over my head, and I really wanted to understand what they are before writing some piece of code.

Funnily enough, things were changed after I learned Rust. (I know I'm saying like a Rust zealot, but it's true!) After using Rust's `Option` type, and realizing its `.map()` and `.and_then()` are similar to `fmap` and `>>=` in Haskell, I finally began to grasp what functors and monads are. And that led me to understand the "implementation details" of Haskell. Before that, I thought `seq` was purely written in Haskell. But it wasn't. It is basically a compiler magic, and GHC specializes `seq` to allow eager evaluation. The same thing goes with the IO type; the monad itself has nothing to do with making I/O be done. I/O is possible solely thanks to the implementation details of the IO type, which resides in GHC. Plus, I can also guess that that part of GHC is probably not written in Haskell, because it is not possible to make side effects in "real" Haskell.

So, Rust was my admirable Haskell teacher. (Thanks, Mozilla!) It's like a stepping stone between the imperative world and the functional world. The funny thing again is, after having fun with Rust for months, now I have less reasons to go back to learn Haskell... Rust is already _too_ powerful, performant, and easy to understand, so Haskell feels less appealing to me. Haskell had been enviable to me in the past, but now it isn't anymore, (un)fortunately.

<comment><USER14> There are lots of things in Haskell that I miss when I use rust, so I'd still encourage you to learn it. For example, concurrency in rust is OK, certainly nicer than other imperative languages, but Haskell has easily an order of magnitude more awesome to offer.

I recently wrote a library for testing concurrent code. It's basically fuzz testing of scheduler behaviour to root out race conditions. In most languages, you'd need a special compiler or runtime to do this, in Haskell it's a library.

</comment></comment><comment><USER15> I can definitely say that my short sidequest to Haskell began and ended with trying to figure out what a monad was, and concluding that this was a silly first topic as well. I am glad I wasn't the only one.

</comment><comment><USER16> The thing that makes an 'IO t' _data structure_ different from some arbitrary java bytecode, is that bytecode is an opaque black box, and represents commands that will be executed immediately, whereas an 'IO t' just "describes" the intended action, remains composable and is a first-class value (i.e. _data structure_ ) in your program.

It's necessary to draw a distinction between the "runtime" and "evaluation" in Haskell; it's not necessary afaik to draw this distinction in other languages, which I think is where the confusion comes from.

In Haskell _evaluation is pure_ , the runtime is not, but evaluation is what allows you to reason about your program.

<comment><USER5> IO t is a black box too. If it's a data structure, it's a crappy one: you can't pick it apart like a list, inspect it, or do anything except sequence it.

I didn't follow what you meant about "runtime vs evaluation." To me they seem hopelessly intertwined: if you evaluate head [], you get a runtime error.

<comment><USER17> It's not a black box in the sense you can move it around, evaluate later, not evaluate at all, etc. There is fundamentally nothing you can inspect about a general IO operation: it's a handle to a computation dealing with the external world.

<comment><USER5> I'm pretty sure you can move black boxes around in the real world too :)

There are definitely sensible things to do with "general IO operations." For example, consider `withArgs`, which replaces argv for the duration of an action. A natural approach is to pick through the received action, and replace all calls to `getArgs` with `return tempArgs`. But `withArgs` doesn't work this way because Haskell can't pick apart IO actions. Instead it uses a nasty FFI to modify a global. (It doesn't even look thread-safe: I'll bet withArgs "leaks" into other threads.)

It's also overbroad: IO encapsulates "real world" computations like deleting files, but also basic operations like getting argv! I'd argue it's a failure of Haskell that the type system does not distinguish between a function that erases your hard drive and a function that gets your command line arguments.

<comment><USER17> You either enforce 100% purity, or your language is not pure. Haskell chose to walk the former path. In that case reading global state needs to happen in the IO monad even if it is reading a couple of command line arguments. Though I completely agree it is nasty to change them in runtime, it is also assumed you know what you're doing when you tinker with them (cross-thread implications included.)

To a Haskell program, command line arguments are exactly the same outer world as your super important files.

</comment></comment></comment></comment></comment><comment><USER18> Ok, so we can't use the word monad because that's bad apparently. How do we answer "How does Haskell, a FP language where composition is a very important concept, compose IO actions?". Because that's almost always done using monadic actions.

Aside, I agree on the List monad thing. I never ever use the list monad, why would I. But if I'm managing state (i.e. IO, Reader/Writer, Conduit etc), then why wouldn't I use the name of the language construct that Haskell provides to manage state?

<comment><USER19> > How do we answer "How does Haskell, a FP language where composition is a > very important concept, compose IO actions?".

You can answer "By using the combinators provided for composing IO actions".

The fact that the structure encoded (some of) these operations happens to correspond to a monad is something that can be left unmentioned until later.

</comment></comment><comment><USER20> I wish the author had explained what the difference between using the IO type and using the IO type via the monadic interface looked like. As a Haskell beginner, this article just makes me more confused. Can someone share an example or clarify?

<comment><USER12> If you are starting Haskell, there is a wonderful little function you can use called `interact`, which has a type `(String -> String) -> IO ()`. This takes a String to String function, and turns it into an IO type that reads from STDIN, runs the function, and writes to STDOUT, lazily. Thus, you can just write `main = interact myFunction` and get everything you need to build complex Unix pipeline utilities without needing to worry about any impurity or composition. I suggest you stick to this until you are comfortable with the basic syntax, types, lazyness, and typeclasses of Haskell.

The problem with learning about the monad typeclass first is that it is a very very high level abstraction, and abstractions are near impossible to understand without a working understanding of examples that they might abstract.

<comment><USER20> This sounds amazing. I was one of those beginners who thought I had to learn monads right away to get anything done, became frustrated, and never progressed.

</comment></comment></comment><comment><USER21> "Only a Sith deals in absolutes" \- I see what you did there, you Sith Lord you!

</comment><comment><USER22> "Avoid success at all costs" comes to mind.

<comment><USER23> As per usual, it was meant to be read as "Avoid: (Success at all costs)" not "(avoid success) (at all costs)".

<comment><USER24> My understanding is more that it was meant to be read both ways, but with the former understood to be serious and the latter a joke.

</comment></comment></comment><comment><USER11> This is a fair reflection on one of the biggest barriers to newbs learning Haskell (which I've tried to do a couple of times and failed, in part because the syntax is weird and poorly explained, in part because the tutorials suck, and mostly because I'm not very smart, or so I'm told.)

The Haskell newb gets told two things very early on:

1) Haskell is pure pure pure!

2) Haskell can do IO via monads!

These statements are contradictory. Haskell is either pure, or can do IO (via monads or anything else.) No pure language can do IO. Period. End of story. Any claim to the contrary is simply, utterly, completely false. I don't care how much you wish it was true, or think it's possible to finesse the issue. You can't. And the worst thing you can possibly do is introduce a newb to the new language via a contradiction.

It's like idiots who introduce "negative resistance" with the up-front claim that a device has "negative resistance" without first introducing the generalized concept of resistance that the notion of "negative generalized resistance" depends on. Ordinary, unqualified "resistance" means V/I, not dV/dI, and if you use the unqualified term "resistance" in any other way you are deliberately and with malice aforethought creating confusion. Same goes for "negative temperature", doubled.

Want to teach Haskell? Start like this: "Haskell is an effectively pure language that hides side-effects behind opaque interfaces that return new objects that represent the modified state of the world, rather than old objects that have been modified. This trickery lets us reason about Haskell code in most cases as if it was pure _even though it is not_."

Claiming purity where there is none is terrible pedagogy. The newb will be confused and have a much harder time getting their head around the language. They will realize that the insiders are working in a different conceptual universe than they are, but won't see any way into that universe and will rightly assume that the insiders are being deliberately obtuse for the sole purpose of excluding newbs.

I am, as stated above, extremely stupid. As such, I am pretty ordinary in this regard. If you want people to learn the damned language, you have to cater to stupid people like me. So discard, play-down, reject and ignore the myth of purity, because that's what it is. A myth. Haskell is not pure. In a pure language the return value of a function depends only on its arguments, but any function that does IO can return any value whatsoever, regardless of what its arguments might be.

I'm sure Haskell purists will respond to this insisting that no, Haskell is really, truly, purely pure... for a certain definition of "purity". It isn't. Monads are a hack to cover necessary impurities. They are a good hack, but to redefine "pure" in such a way that accommodates monads--and this is what you have to do--is just like redefining "resistance" to accommodate "negative resistance". It's perfectly reasonable to generalize the definition of common terms, and perfectly confusing to use the generalization to imply that you mean "just perfectly ordinary resistance" when talking about "negative resistance," or "just perfectly ordinary purity" when talking about "purity with side effects hidden behind monads."

There is no particular value, use or virtue in claiming Haskell is "a truly pure functional language". Claiming the language is "effectively pure for most practical purposes, so you get the provability of pure functional programming by hiding side effects behind monads" seems far more useful. Why the Haskell community is so wedded to the myth of purity--and therefore so insistent about putting monads front and center, as the article rightly decries--is not clear. But the language and the community would be better for putting the myth and the monads behind them.

<comment><USER23> To go ahead and be that Haskell purist... in normal Haskell code there are no functions which execute side effects in the process of computing their results. Even a function like

        putStrLn :: String -> IO ()

merely produces an IO value. It is only when such a value is sequenced into something presented to the RTS as `main` that the effects are realized.

This seems like pedantry, but it allows you to construct and compose IO values in many ways (besides just sequentially evaluating them). This ends up giving you "macro like" powers.

<comment><USER11> Thanks for this answer. I think it points clearly to the source of confusion.

To be pedantic back at you, I'm pretty sure your explanation translates to: "So long as you never run a program, Haskell is a pure language."

Pedantically speaking, you can't have it both ways. Either the "Haskell" of the claim "Haskell is pure" includes the RTS or it does not. If it does, it is not pure but can run programs. If it does not, it is pure but cannot run programs.

A programming language that you can't run programs in is not very useful or interesting, so I'd really think it was a better move to define "Haskell" in such a way that programs can be run, and accept that under that definition Haskell is impure, although it retains a kind of effectively pure formalism that allows provability and such, which is awesome.

Either way, it is really important to emphasize in any description of the language that "At runtime Haskell is not pure". Otherwise newbs like me will simply be confused by the contradiction between the claim "Haskell [considered as an unexecutable language] is pure" and "Haskell [considered as a set of instructions to the RTS] is capable of doing IO". The two completely different meanings of "Haskell" must be made clear if profound confusion is to be avoided.

<comment><USER23> Eh, I don't care much about names. Purity-up-until-RTS being taken seriously makes it easy to think of computations both pure and impure. I get to choose whether to interpret IO as an imperative, impure language subset of Haskell or as a pure type. Both have their advantages.

If your language is impure then you usually can _only_ choose the former.</comment></comment></comment></comment>


The Tech Sector Is Over - <AUTHOR> https://ftalphaville.ft.com/2019/01/08/1546923600000/The-tech-sector-is-over-/ <comment><USER2> I mean this is true, Bookings is not a tech company, nor is Facebook (advertising). I do think Microsoft, Nvidia, Intel, or New Relic would still classify as technology companies for example. Some large companies are a bit trickier such as Amazon and Apple. The same could be said for whether Bayer is now a pharma company or agro-chemical company after the Monsanto acquisition. Overall, this just demonstrates the issues surrounding mass indexation. Technology trends can make index weights and exposures non-sensical depending on the pace of innovation, mergers, etc. My last startup used a distance metric on business segment revenue, named competitors, etc. to come up with a better taxonomy and distance metric for company comparisons versus single buckets.</comment>


Angular Feature Route Libraries - <AUTHOR> https://www.youtube.com/watch?v=nP7Yodr-WUA <comment><AUTHOR> Just did an angular talk for ngHouston on redistributing entire app features(routes and all) with angular cli libraries.</comment>


Successfully adopting React in your company - <AUTHOR> https://medium.com/@kensodev/successfully-adopting-react-application-in-your-company-c300668c61c4#.5yqnq74z7 <comment><USER2> How do you test presentation components, by comparing with some "ideal" result?

<comment><AUTHOR> Blank state, loading state... Making sure both of these work for the component (if needed).

Top X items and no more being rendered.

If there's a presentation logic like Red/Green for some number using Css classes, I will test that one out as well.

Stuff like that.</comment></comment>


Foursquare move to Scala/Lift - <AUTHOR> http://www.scala-lang.org/node/5130 <comment><USER2> _Average post rates of over 1 per second and peaks several orders of magnitude larger._

Are they running the server on a cell phone? Why would that necessitate a change to Scala from any language?</comment>


Some of my thoughts on the GitHub investment - <AUTHOR> http://cdevroe.com/links/github-investment/

<comment><AUTHOR> Also, if anyone has any questions...</comment>


Why Rust, or a Trip Report from My Satori with Rust and Functional Programming - <AUTHOR> https://christine.website/blog/why-rust-2020-02-15 <comment><USER2> I honestly didn't find anything of interest in this post. If you already know that rust / fp in general tend to have safe and sound type systems which enable developers to encode complex relationships in the type system to prevent race conditions and catch memory leaks at compile time then there is not much for you here. I suspect a lot of HNers who would be interested in this post already know that.

</comment><comment><USER3> This is an incredible basic article, and there's a lot of issues with it to boot which is surprising considering the author has performed talks at Go conferences:

Go's equivalent to Rust's Vec should have simply been []int64 instead of using list.List (which is a doubly-linked list, aka std::collections::LinkedList in Rust). And yes, I read the blurb at the end where they say they know slices exist. The issue is that they proved nothing useful by not using them. You don't need to recreate how slices work because _they already exist_, and is well-known it's all currently compiler magic (until they introduce generics).

In the JSON unmarshalling example, the reason you need struct tags in Go is because the JSON field name is different from the one given in the Go code. You'd have to do the exact same in Rust if they had named it similarly to the Go example ([https://serde.rs/field-attrs.html](https://serde.rs/field- attrs.html)).

The other stuff about catching concurrent issues is true, but working with concurrency in Rust is a testament to one's patience as well (especially when working with multiple processes/threads), so you're trading off usability with safety—and to be frank, it's pretty easy to remember that the only things that work concurrently are either atomic, use locks, or some sort of queue.

</comment><comment><USER4> So I found this analogy a little shallow. The tl;dr is:

Some languages are dynamic (Lua being ht example here but obviously there are many others eg Python). The author then chooses to differentiate types of statically typed languages to those with generics (Rust being the example) and those that don't (Go being the example).

I'm not sure that's a useful distinction because all type systems have limitations and there are many orthogonal dimensions. A language can have (or not) generic types while separately being able to define enumerated types (or not), as just one example.

The interesting thing (at least to me) about Rust is that Rust goes beyond describing types to describing (at compile-time) ownership of data. There is a developer cost to this and a compile-time cost. Personally my view is:

\- Compile time errors are cheaper to debug and fix than run-time errors. That's the whole point of having a type system: to catch errors at compile- time. Better that than a segfault. Rust is novel in that it eliminates a whole class of problems with data ownership, lifetimes and access. Not every problem of course.

\- Memory-safety is just too important such that Rust will increasingly fill a niche because this is just too easy to get wrong in, say, C/C++.

You do have to jump through hoops go properly describe ownership semantics so the Rust compiler can satisfy safety constraints. Like a type system, there are limitations to this and you can intuitively come up with examples that you know are safe but are hard if not impossible to describe to Rust. Rust does get better with this as time goes on.

Whatever the case, I'm very bullish on Rust.

<comment><USER5> Well as much as Rust covers all the main benefits and features compared to other languages, some companies can afford to switch to it but others think more carefully if such a switch is more trouble that it's worth.

It no doubt that the barrier to reading / learning Rust is still higher compared to other languages despite the languages safety guarantees and performance. It is still a new language that some large companies can afford to invest their time using it. However if a senior dev that pushes for a rust codebase and ends up leaving the project, the team would probably revert back to the second-best language that everyone knows rather than continue. It doesn't make any sense to use Rust for the sake of Rust or even strangely: "because everyone else is using it".

Even as a Rust user myself, the author has failed to mention about the quality of the crates ecosystem which mostly still have pre-1.0 libraries and aren't even stable yet and even a popular few had and still have unsafely issues.

In a typical production software house of 2025 for new server-side software, I would use Rust over C++ and JavaScript (Node). But for 2020? Kotlin/Kotlin Native sounds like a safer bet for some companies over Rust due to leveraging the existing Java ecosystem and being a safer alternative to Java.

<comment><USER6> > But for 2020? Kotlin/Kotlin Native sounds like a safer bet for some > companies over Rust due to leveraging the existing Java ecosystem and being > a safer alternative to Java.

You should consider plain Java tbh. Java 15+ is basically Kotlin anyway at this point. It's much easier to hire or outsource Java developers.

<comment><USER7> It's easier to find Java devs, but whenever I've been in contact with any they're also on average the lowest quality developers you can find. It's the language everybody learned at uni, so you get a lot of people that never did more than the bare minimum.

<comment><USER8> Just like any other language.

Are you aware that there are outsourcing projects doing Haskell, Scala and C++ as well.

Hint, the deliverables aren't usually what one would expect from the skill levels usually required by average users of those languages.

</comment></comment></comment></comment></comment><comment><USER6> "list" in Go is not equivalent to Rust vec. List is a linked list of boxed entities. Of course they can have different types because it is a linked list; each cell lives elsewhere on the heap. The Go equivalent to vec is an array or a slice, which does enforce the type.

As for the second example, it's more of a complaint about the library. There are libraries that enforce stricter checking. Or you can code gen or roll your own deserialization logic.

> but then the job of ensuring the sanity of the inputs is shunted to runtime > rather than stopped before the code gets deployed

It's always runtime, even in Rust. You get some blob from the network to deserialize, it will return an error if it's bad, just like in Go if you try to Unmarshal bad input to a struct.

Seems like people think Rust has this magical ability to prevent errors. Big expectations lead to big disappointments.

<comment><USER9> The complaint about interface{} is very legit in practice. Author says he deliberately picked on Go stdlib to illustrate. I suspect one had to struggle with the same to really get it.

How "stable" is Rust, libs and tooling ecosystem though.

<comment><USER6> Rust is getting better. It recently got async/await which imo is a much cleaner and undeniably faster way to do concurrency than Go's channels/CSP. It's not really fair to compare Rust's ecosystem to Go's because Rust doesn't have a trillion dollar company's halo effect. For the foreseeable future you will always be more likely to use Go than Rust at work.

</comment></comment></comment><comment><USER10> the first example is ok, everyone knows this is by design in go though. second one is grasping, what if you want different metadata on each property? it will end up looking similar, albeit more strongly typed than a string. its a little myopic rust task force feeling though

</comment><comment><USER11> AFAIK the only unique feature of Rust is a borrow checker, right? (compared to other feature-full languages, i.e. not Go)

Regarding the main example of author, it's great that the progressive side of Go team won, so generics are coming in Go 2.

<comment><USER6> Yes, I think that's the only new innovation in Rust. Everything else is just an incremental improvement on what already exists elsewhere. Supposedly the developer experience/ergonomics is a feature, but everyone I have met says the syntax is ugly. In terms of ease of getting started and using tooling, it really can't ever compete with the corporate languages like Go, Swift, Kotlin. I can't for the life of me understand why it keeps getting more popular. Memory safety? Security? C++ had the same safety characteristics for at least a decade with dozens of linters and sanitizers on the market, but people never used them or actively turned them off. Rust forces you to use a linter. Maybe it's for the best.

<comment><USER12> > but everyone I have met says the syntax is ugly

I like rust's syntax. It has very elegant macro syntax, expressions are values, and all that other good stuff.

There are some small parts of it that are ugly, but honestly Java and C++ are far uglier. Templates in c++ are awful. Java's wildcard syntax and lack of macros is ugly.

I find rust much prettier syntax-wise than most statically compiled languages. Prettier than Go or Java or c++.

> In terms of ease of getting started and using tooling, it really can't ever > compete with the corporate languages like Go, Swift, Kotlin

Why not? I don't see any reason why it can't compete. Heck, it's a pretty corporate language too in terms of its mozilla backing.

That being said, people constantly talk about how easy it is to get started with python, and python has even less corporate backing than rust. That point makes no sense to me.

> C++ had the same safety characteristics for at least a decade with dozens of > linters and sanitizers on the market

C++ does not, and did not, have safety features like rust's. C++ cannot guarantee ownership semantics are correct. It cannot identify data-races at compile-time. Leaving dangling references in C++ is trivial.

For example:

        std::vector<int> v = {1};
        auto ref = &v[0];
        v.push_back(10);
        std::cout << *ref;

That code compiles in c++ even though 'ref' may be invalid because 'v.push_back' may have reallocated the underlying memory. I don't know of any compile-time tooling for c++ that reliably catches that bug. It's a clear memory safety issue, and it's basically the exact thing rust's ownership system saves you from.

In short, I don't think you have a complete understanding of what rust's benefits are nor why it's innovative.

<comment><USER6> > Why not? I don't see any reason why it can't compete. Heck, it's a pretty > corporate language too in terms of its mozilla backing.

It's niche, been around for over a decade, still hasn't reached critical mass. Golang did. Numerous mainstream projects are in Go that drive entire industries now e.g. docker, k8s. Rust's biggest deployed code is the CSS renderer of a web browser with single digit market share. I'm not saying Golang is better on PL theoretic grounds (obviously it's worse), but it proves what corporate marketing can do, which we have known since the Sun era. Also Python was not that popular until the same corporation behind Golang decided to adopt it and hired Guido.

C++ compilers don't catch all the errors, but static analyzers do. Taking your code snippet as an example:

        % cppcheck ./main.cxx
        Checking main.cxx ...
        main.cxx:8:16: error: Using pointer to local variable 'v' that may be invalid. [invalidContainer]
        std::cout << *ref;
        ^
        main.cxx:6:13: note: Address of variable taken here.
        auto ref = &v [0];
        ^
        main.cxx:7:2: note: After calling 'push_back', iterators or references to the container's data may be invalid .
        v.push_back (10);
        ^
        main.cxx:5:19: note: Variable created here.
        std::vector<int> v = {1};
        ^

There are proprietary static analyzers that go much deeper and catch less obvious bugs. Even without paying, you have ASan, TSan, UBSan, valgrind, afl, among others to do runtime analysis or fuzzing to catch memory errors and data races. Unfortunately these aren't used as much as they should be. Maybe those programmers have a point. In practice, memory management is not remotely the most difficult or bug-prone part of software. If you are using C++11 or later, the standard practice is to never do raw new and delete. std::move(std::unique_ptr...) has the same benefits as Rust borrowing without the borrow checker (although it is not rocket science to detect use-after-move with analyzers). Arc <-> shared_ptr. Sure, Rust's versions are better, but let's not get carried away, it's <10x better than C++ (with 1/10000x the ecosystem, jobs, books, libraries, people).

<comment><USER13> > been around for over a decade,

Rust 1.0 happened in 2015; everything before that was incompatible with other releases, sometimes multiple times per day.

</comment></comment></comment></comment></comment><comment><USER14> tldr: I am going to present Go in the worst light possible by pretending it doesn't support typed containers. Hopefully you'll gloss over this and support my viewpoint.

Rust doesn't need an 'assist' but articles like this will certainly damage the, otherwise sterling, reputation of it's community.</comment>


If you're not looking to raise, do you take a VC's call?  - <AUTHOR>

My company is doing well, and I occasionally get calls from random VCs in Boston, NYC and SV doing their typical 'talent scouting'.
We have no interest in raising, or spending any time resources whatsoever on establishing relationships with investors.
Is there any value in it? I honestly can't see it and treat an investor call like Verizon trying to up-sell me. Is my head in the wrong place? <comment><AUTHOR> That post is well-met, but it doesn't really dive deep enough into why talking to investors is good.

Additionally, it's essentially saying to look into their portfolio to make connections, don't talk about your own company, and return the call to be "polite".

First, any VC's portfolio is going to be other startups; any strategic partnerships with other startups inevitably devolve into "mutual referral" territory, which is next to useless. It also forces you to stick your neck out for a company that may not exist in a few years (this goes for us, as well as them).

Second, it's impossible not to talk about your company when it's the sole reason the associate cold called you in the first place. How do you block and bridge that?

Third, not returning a cold call/email doesn't make you impolite.

</comment><comment><USER2> Brad Feld has a good article on the subject. I woud recommend it to you.

[http://www.feld.com/wp/archives/2012/08/how-to-respond- to-a-...](http://www.feld.com/wp/archives/2012/08/how-to-respond-to-a-cold- call-email-from-an-associate-at-a-big-vc-firm.html)

and I posted it here to HN:

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

Aside from agreeing with his advice, one constructive observation.

 _We have no interest in raising, or spending any time resources whatsoever on establishing relationships with investors._

The words "no" "any" "relationships" are sort of an odd mix in this sentenece. Consider how you are framing at the situation. As PG said in a recent post, if a company becomes big enough, there will be a market for its shares. So, the idea that you can be "doing well", or so well that you should never consider future investment, or even an exit, is a bit of a red herring.</comment>


Mall landlords struggling to find takers at a price they'll accept - <AUTHOR> https://www.bloomberg.com/news/articles/2018-06-12/owners-of-fading-malls-on-their-knees-as-buyer-pool-evaporates <comment><USER2> I remember learning that in the 90s some companies had this useless asset: gas pipelines that spanned the country, but had dried up and were not being used.

Other companies had a problem: how to acquire the rights to lay fiber from one end of the country to the other.

Some very smart person realized you could lay the fiber in the old pipes.

Question: what can be done with all that retail space? Is there a new use of space that will come up?

Related question: what are the properties of malls that we might use? (parking, close to residences, easy to walk through)

<comment><USER3> It could be a whole new flavor for YC or other incubators - don't come to SF and fight to find housing... come to the new Coding Mall - offices are in the East Wing, apartment in the West Wing, demos and sales kiosks in the former Sears, VC offices in the former JC Penney, and everyone meets up in the food court (which is still running, btw, to keep everyone fed) for informal discussions.

<comment><USER4> I'm not sure I'd want to live in an old mall, but I could see them being purposed for office space. Parking is already taken care of, and most have bus routes already in place. The existing food court would be ready for new tenants. Other types of tenants could fill where other retail (e.g. clothing, toys) once occupied, such as a gym/fitness company, FedEx/UPS offices, office supply stores, etc.

<comment><USER5> Yep, never understood why they don't convert malls into office spaces. Then again, in the Bay Area (at least South Bay) there are TONS of empty office buildings for rent. I'm guessing that they all just want too much. Maybe it's a zoning thing with the malls? Seems like they could do it with the one in Cupertino. For being Silicon Valley, sometimes this place really fails to impress with innovations like that. Instead, we have scooter startups.

<comment><USER6> Sometimes malls _are_ converted to office space. According to the documentary, Making of Riven, Cyan repurposed a strip mall as office space while they were waiting for the construction of a real office. They originally started out in some guy's garage after finishing Myst and crammed 12 people in there, then moved into the strip mall -- which they said was "like heaven" by comparison, but they didn't just stay in the strip mall because it was still too small for all the staff they wanted to bring on.

</comment></comment></comment></comment></comment><comment><USER7> Here's an anecdote about my experience at a mall yesterday. I needed some new shoes:

I went to the Skechers store. There were 4 people working. Not a single one ever offered to help me. I had to walk up to the counter and the girl looked shocked when I asked her to get me my size to try on. She handed me the box and walked away. I never saw her again and walked out without making a purchase.

I went over to Macy's to the men's shoe section. The section was about 5x the size of the Skechers store. There was one person working who was busy with a customer at the checkout. After waiting for 10+ minutes with no one to help, I left without ever trying on a pair of shoes.

Then I went to Ecco--they are a small shop with only a small number of shoes. While the salesperson was quite attentive and helped me out, the one pair of shoes they had in the store that were interesting to me didn't fit right so I left.

Tried to go to one more store only to discover that this particular location only carried women's shoes.

All told, this adventure had me in the mall for about 90 minutes and I had managed to try on 2 pairs of shoes. Throw in the drive and it was over 2 hours for nothing.

I went home, spent 20 minutes on Amazon Wardrobe, and I have 8 pairs of shoes in my size arriving at my house in a few days to try on.

Stores in a mall have a real opportunity to win on personal service and instant gratification. Hire someone to help me find shoes that fit me well and go with my own sense of style and who makes sure I go home happy. But if my choices are spend over 2 hours for nothing or go online, I'm choosing the latter every time.

<comment><USER8> To play devil's advocate here...

1) Are you incapable of finding the right size shoes yourself? The boxes are usually laid out fairly logically and it's pretty rare for there to actually be anything of use "in the back".

2) Hiring people to provide the level of service you're asking for would significantly increase the cost of labor over the minimum wage kids that usually staff these stores. I'm fairly certain the cost increase would guarantee the store goes out of business with the razor thin margins they usually have. Put another way, do you really think paying 50% more for higher quality employees would guarantee 50% more sales revenue?

A big reason online shopping wins is because no one has the expectation that an actual human will help them purchase things, and the labor and rent costs are tiny in comparison to retail.

<comment><USER9> I don't know what kind of stores you are used to but there is usually only one shoe on display. All the pairs are kept in the back of the store, you cannot try anything without help from the salesperson.

<comment><USER10> I'm not much of a shoe person, but I have literally never been to or heard of a place like this.

Including places like Modells, Macy's, Payless, Sports Authority, etc etc etc

<comment><USER11> Perhaps it's a cultural difference? Every shoe store I've been to in my whole life is like the parent poster mentioned: there's one pair of each model on display behind glass, and the salesperson goes to the back to get the boxes in your size.

<comment><USER12> Definitely a cultural difference, and I'm intrigued about this approach. I used to work the shoe department at K-Mart and spent most of my time cleaning up after people who tried shoes on and just left them in the middle of the aisle, or trashed the boxes getting them open (how???), or tossed their old shoes in the box and walked out wearing a brand new pair.

Maybe not as consumer-friendly as what I'm used to, but it sounds heavenly from the employee standpoint.

</comment></comment></comment></comment></comment></comment><comment><USER13> Malls were always predicated on the assumption that well-to-do suburbanites, increasing in wealth and in number due to relative prosperity in the upper subdivisions of salaried workers, would spend their disposable incomes on getting boutique, brand-signalling merchandise for themselves and their children.

This was a trend that was evidently worth commercially exploiting at a time when malls were being built, but by the 1990s the demand for brand-name goods climbed upmarket enough that a new distinction had to be drawn between a mainstream mall and an upscale mall for this strategy to remain effective. New malls were built at great cost, and they took the most desirable stores, leaving the older wave of malls struggling for enough business to pay for renovations, maintenance, debt, and ROI. This cycle repeated at least one other time, when the outdoor, disassembled 'lifestyle center' became the dominant design pattern in the mid-2000s, by which point the narrative that malls are "dying" had become widespread.

Rather, the market has segmented to a degree that the concept is only profitable at the highest end, while lower offerings are proving uncompetitive with other forces in the economy, like powerful mainstream retailers with lasting appeal (e.g. Target), low-price leaders (e.g. Walmart), reliable stores with strong curation (e.g. Costco), and the convenience of ordering online (e.g. Amazon). Then, it's worth noting that the generation that's 18-35 now spends less of their income on clothes than the generation that was 18-35 when malls were big [1], and apparel stores are about half of a typical mall's occupancy.

Compare all this to Europe and UAE. Malls are doing great there. What's different? Just about everything, from the concentration of population and the particulars of siting that draws a higher proportion of people, to the value- add of having such a variety of shops under one roof, to less competition from non-mall retailers, and brand signalling still being a desirable goal.

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

<comment><USER14> _Compare all this to Europe and UAE._

No, retailers are struggling in the UK at the moment, there have been a number of high profile closures and restructurings. We haven't got the same capacity problems of the US but shopping habits are definitely changing.

</comment></comment><comment><USER15> Malls, yuck! I find little attractive about them, and I'm not surprised no one's going any more. malls are dying because they're all based on materialist consumerism: something millennials want no part of.

Here's my suggestion. Fill them with Libraries, Gyms, yoga centers, Cafes, Restaurants, movie theaters, science museums, bike repair shops, ceramic hobby shops and indoor swimming pools, theaters and historic museums. That would get me going back in a heartbeat!

And for crying out loud, put those massive cement filled parking spaces underground. Replace all that extra space with Green trees, bushes, parks, bike lanes and outdoor gyms.

<comment><USER16> _> they're all based on materialist consumerism... Libraries, Gyms, yoga centers, Cafes, Restaurants, movie theaters, science museums, bike repair shops, ceramic hobby shops and indoor swimming pools, theaters and historic museums_

Aside from libraries and (some but certainly not all) museums, aren't all of these examples of things that fit well within materialist consumerism?

I also prefer yoga studios, expensive coffee, fancy restaurants to specialty knives, clothes shopping, shoe shopping, and food courts.

But those sorts of personal preferences are just matters of choosing what to consume, which doesn't seem like a fundamental or important difference.

<comment><USER15> The things I mentioned are mainly about experiences. For example, with a 5$ cup of coffee you get a great third place to hang out in an inspiring location, comfortable seat, stable table and wifi: it's not really about the coffee (for me anyways).

<comment><USER16> _> The things I mentioned are mainly about experiences_

I've become convinced that clothing and shoe shopping is also "mainly about the experience" for many people.

I don't get it, and I'm happy to see enough others who don't get it so that there's a critical mass of consumers for the business that provide the things I enjoy to thrive. But I do believe it's a matter of preference (and perhaps also of environmental/economic impact).

</comment></comment></comment></comment><comment><USER17> It's hard to explain how important malls were to some of my younger colleagues, or to folks who didn't grow up in some no-name midwestern suburb like I did. Malls were temples and town squares. They were facebook. They were the internet. Virtually all of your exposure to the "outside world" happened there.

Malls were incredibly well built and thought through. They were the crown jewel for many mid-size towns (perhaps next to sports stadiums). They boasted large, secure, climate controlled areas, often in places that had dramatic seasonal weather changes. They were a constant.

I think they represent a tremendous bargain, provided a good deal is struck, and someone knows what to do with the space. However, the window for this to happen is small. Spaces that are that large that fall into disrepair often are unsalvageable.

<comment><USER18> I think this might be US-centric phenomena. While we have some Malls in the UK, I believe most shops never really left the high-streets here (until the rise of the internet).

<comment><USER19> OP mentioned a "no-name midwestern suburb" \- in places like that, the main shopping street in the town often never existed in the first place. The land use goes straight from farms or ranch land to massive suburban housing developments with no functional town having ever existed in between.

Thats not how all of the US works thankfully, but in huge parts of the country which are still doing the suburban sprawl thing, its a pretty common pattern. The nearest city which existed before the 1950s might be an hour's drive away, everything is new and purpose-built by large scale commercial developers.

</comment></comment></comment><comment><USER20> Declining retail is one factor, but bad balance sheets are the other.

This type of development is fueled by favorable up-front tax and accounting treatments for development, but it requires constant growth for the companies to survive. When you get to the back-end of the 30 year loans, you're paying principal on a depreciated asset... the bag of tax tricks isn't enhancing profit anymore.

The fact that the operators are desperate is a good thing -- they'll be bankrupt soon and useful redevelopment of these massive properties can start taking place.

</comment><comment><USER21> When I was a kid in the 90s, I remember malls being much more of a destination --they had big atriums with fountains and indoor trees.

By the early 2000s, when I was in high school, they were much more utilitarian. This was way before online shopping was killing their profits.

I'm assuming it had something to do with consolidation and the new owners trying to extract maximum short term profits.

<comment><USER22> I also distinctly remember enjoying going to the mall as a kid because of the fountains and glass ceiling atrium, lots of seating spaces, is that not a thing anymore?

<comment><USER23> Portland's Clackamas Town Center used to have a beautiful skating rink, large fountains next to escalators, and foliage. This has mostly been replaced with a seating area, a larger food court, and more shops. It's considerably less appealing to just _be_ in, at least for me. I miss stuff like that.

</comment></comment></comment><comment><USER24> "It's a tough environment. I don't think anybody really anticipated the decline of the department store to happen as quickly as it did,"

Yeah, right, all you ostriches ignoring the advance of online retail for the last 15 years.

<comment><USER25> It's happening a lot slower than I expected.

</comment></comment><comment><USER26> Bloomberg had a fun little game a while back where you could play a mall owner trying to keep your property profitable... Lovely retro experience, worth checking out:

[https://www.bloomberg.com/features/american-mall- game/](https://www.bloomberg.com/features/american-mall-game/)

</comment><comment><USER27> Just turn them into community colleges, or satellite university locations. Put up some apartments and offer the full experience. You have plenty of parking.. plenty of land.

<comment><USER28> I would be a big fan of them converting the locations in to mixed use housing and retail.

</comment></comment><comment><USER29> I've been watching a lot of videos recently on visiting abandoned or dying malls in America and was wondering if it could be possible to convert them into residential/communal areas?

They could be almost self-contained; with housing, shops, entertainment, etc all under one roof.

</comment><comment><USER30> Malls need to move from Everything to Everyone to targeted segments of the consuming public.

My suggestion would be to rebuild the existing set of retail locations and target a group or niche to drive more traffic. For Example: Focus on Moms with kids from zero to 6. All the stores would cater to this group. You wouldn't see Athletic Shoe Stores or Abercrombie but store like Baby Gap, Carters, Gymboree or Children's Place. Add in Starbucks and a few other children friendly restaurants. Put in one or two play spaces for kids. Offer Free Babysitting if the Moms schedule appointments at a Yoga Center, Nail or Hair Salon. Make it a destination for Mom's to One Stop Shop for all their needs and a place where kids can play while they sit and watch or shop. Put in a couple of Pediatricians, Eye Doctors and a few Kids focused Dental Services. A Kids focused Movie Theatre and maybe even an aquatic center attached but for young kids. Make the entire place a destination. "THE" go-to place in town to shop for Moms with kids from infant to 6.

Or take an existing Mall and put in an indoor Skate Park. Fill it with stores catered to 16 to 25 year olds. Set the expectation that you expect Youth to "cruise" the locations. Add some security to make it safe and create a hangout where they will shop.

</comment><comment><USER30> My suggestion would be to rebuild the existing set of retail locations and target a group or niche to drive more traffice. For Example: Focus on Moms with kids from zero to 6. All the stores would cater to this group. You wouldn't see Athletic Shoe Stores or Abercrombies but store lke Baby Gap, Carters, Gymboree or Childrens Place. Add in Starbucks and a few other children friendly restaurants. Put in one or two play spaces for kids. Offer Free Babysitting if the Moms schedule appointments at a Yoga Center, Nail or Hair Salon. Make it a destination for Mom's to One Stop Shop for all their needs and a place where kids can play while they sit and watch or shop. Put in a couple of Pediatricians, Eye Doctors and a few Kids focused Dental Services. A Kids focused Movie Theatre and maybe even an aquatic center attached but for young kids. Make the entire place a desitination. "THE" go to place in town to shop for Moms with kids from infant to 6.

</comment><comment><USER31> Scottsdale AZ's Galleria struggled as a retail mall, tried other purposes and then it went business park. Seems to be working, do not read headlines about it being sold for pennies on the dollar anymore...

[http://galleriascottsdale.com/](http://galleriascottsdale.com/)

</comment><comment><USER32> I wonder if it makes sense to turn malls into office spaces. That'd keep the food court busy, too.

<comment><USER33> I was thinking the same thing. Co-working is on the rise, as are small rental office units with shared assets. Maybe they could turn a mall into a Googleplex for small business, with a game area, food court, pub/bar, gym, grocery/drug stores. I think a creative person with good business sense could pull it off.

</comment></comment><comment><USER34> There are several nice fancy style strip mall type places near me. All of them reportedly have sky high rents and several are largely empty and have been for years and all cycle through stores at a surprising rate. They keep up the malls just fine as if they're occupied, but they're mostly empty.

It seems like such a waste to not have something operating in there.

</comment><comment><USER35> Maybe they can turn large vacant malls into housing for the vast homeless populations found living in shantytowns and tent-cities throughout the west coast?

</comment><comment><USER36> In the common conception of markets no seller has enough power to sit on their laurels, they must sell their product in order to survive. It seems wrong to me that in the real estate market liquidity would drop as prices drop. There needs to be a cost associated with holding real estate so that there is turnover in good times and bad times.

<comment><USER37> Owners of real estate already pay property taxes. Are you just proposing that those be increased? And you think that will make real estate _more_ valuable? I'm missing something here...

<comment><USER36> >Are you just proposing that those be increased?

Sure, or an additional tax on unused or barely used real estate if we wanted to be targeted, but really I like the broad property tax.

>And you think that will make real estate more valuable?

No, I'm not trying to make real estate more valuable, actually I'm trying to make it less valuable by ensuring that the high levels of competition we see in booming real estate times carries over to the busts. If the costs are so low that people are just sitting on these properties and waiting for a magical moment when prices rise then obviously costs need to be increased to pressure these people to enter the market. Liquidity shouldn't drop when prices drop.

<comment><USER37> Increasing property tax in general is less bad than this "unused or barely used" tax idea. That sounds like a good way to turn all old malls into flea markets. That is, big messy places where anyone can sell anything she wants out of the back of her van, for $5 a day. "Anything she wants" will include a wide variety of items to which neighbors will object strenuously. In addition to the unsavory sales activity, other unsavory activity will also take place. There's no way any taxation scheme will pay for the required extra policing.

I won't be surprised if we _don 't_ see this happen...

</comment></comment></comment></comment><comment> polski-g 1) Do malls exist in Europe?

2) If yes, are they also failing?

</comment><comment><USER38> Stupid ClickBait Headline:

"That's proving difficult, with just a shallow pool of investors who are willing to take on a declining mall and even fewer who would pay what the landlords want."

How is that practically giving way?

You know what? I'll sell anything you can find in my garage for $2M USD. Anything and all things. Is that pratically giving away?

<comment><USER39> Depends on what's in your garage.</comment></comment>


A book tunnel ran between the Capitol and the Library of Congress - <AUTHOR> https://history.house.gov/Blog/2020/May/5-5-book_tunnel/ <comment><USER2> Quick! Put it back before POTUS convinces his cult to stoke the fires and purge all of the "fake liberal history" books!

<comment><USER3> Please don't do this here.</comment></comment>


"Gopher Protocol" Trademark by Gopher Protocol Inc - <AUTHOR> http://assignments.uspto.gov/assignments/q?db=tm&qt=sno&reel=&frame=&sno=87927131 <comment><AUTHOR> Actual TM is "GOPH Gopher Protocol" but title would have been too long. This looks very odd to me, coincidence with recent Gopher (the old protocol) revival attempts or something fishy going on?

<comment><USER2> It is curious. The company website for Gopher Protocol Inc. says very little in a lot of words.

It reads like they want to impress investors with buzzwords and acronyms, in the hope that they're daft enough fall for it.

Such gems as: "In order to manage the complexity of the system, Gopher is using validation techniques and methodologies in which functionality is verified by simulating and validating processes according to the system's description."

Also: "The hardware (CPU, RTC, more) and on-board software need to be synchronized together in order to execute a decision when to listen, go to sleep, wake up or remain in idle state."

I suppose that any increase in search traffic for 'Gopher Protocol' might get conveniently, though incorrectly, attributed to their company, which they can take to investors of a gullible disposition.</comment></comment>


Open Source Personal Finance Manager - <AUTHOR> http://seeker89.github.io/cozy-pfm/ <comment><USER2> First OSS PFM?

Really?

[http://skrooge.org/](http://skrooge.org/) [http://www.gnucash.org/](http://www.gnucash.org/) [http://kmymoney2.sourceforge.net/](http://kmymoney2.sourceforge.net/) ...

<comment><USER3> all those are desktop applications and don't all get your data back automatically from your bank...

Here we speak of an open source alternative to Mint, not to Money :-)

<comment><USER4> I had a bank that frequently double-charged me for services and threw my balance below zero. I wouldn't trust their records of what I spent for anything.

</comment></comment></comment><comment><USER5> But I _would_ give my bank credentials to Zuckerberg (say we meet at a restaurant in Palo Alto and he asks for it). The asymmetry of the situation means that he will lose much more than the meager amount in my account if he steals the money. So that questions is rather silly.

I understand that the question really means "give you credentials to Facebook", where Facebook is proxy to any big company. This is a harder question, but one that I face often in practice, giving out bank account info, SSID number, credit card numbers, etc. The answer, evidently (since I and millions of other people do give this information out) is yes. The above answer still applies, these companies still stand to lose more than me if this information leaks or they mismanage it.

In summary, the richer and visible an entity (real or corporate) is the better I feel about providing sensitive information, if it should be provided. This means that teh sort of main message used here ("would you give your account info to") is irrelevant. Being open source is a huge step up, but for the general public either it doesn't mean much or else is a detriment, since the thinking is that, if it's open, "hackers" can also see the code and find ways to exploit it.

So how can a small startup ever compete with large established companies, since this creates a chicken and egg problem?

<comment><USER6> I spent the better part of a year and a half on the premise that consumers care about data ownership. Spoiler alert, they don't. It's a similar concept in terms of what hackers tend to value.

There is a (small) niche of people that care about this stuff. But I can't help but feel that we, as hackers, try to communicate why others should care. Perhaps they should, I don't know. But what I do know is that they don't.

We end up wasting precious time and energy trying to convince someone who blatantly trusts Facebook that they should not. And we use phrases like "a company that's business is to sell your data".

I agree completely with you and after having worked at a large company (Yahoo!) on their security team I can confidently say that your data is safer with a large company than on some small or even self hosted software.

I'm not trying to convince hackers not to hack. I'm saying to not waste time convincing the general population. Scratch your itch and find the niche that actually cares about what you're building and talk their language.

</comment></comment><comment><USER7> First? What about [http://www.gnucash.org/](http://www.gnucash.org/) or any of the others?

<comment><USER8> Missing the "Cloud - based" part I think...

I agree with the idea of a free/open finance manager - definitely when it connects to the bank through online services.

I wrote a GPL'd finance app for OS X a few years ago, and tried to add online banking support, but other than OFX HTTP download, there didn't seem to be any standard specification for it at the time other than screen-scraping, which I don't think counts, so I didn't bother, given it would be different for each bank.

Another issue is that my bank would give abbreviated/limited names and descriptions of the data, which meant that there needed to be a "post import" step to tidy the data up to make it meaningful which was annoying.

I don't know what the state of things is now...

<comment><USER4> The last place I want my personal finance details is in "the cloud".

<comment><USER9> This is an open source project designed to be hosted on one of the "personal cloud" platforms that you can run yourself on your own hardware, or if you want, run on a VPS that you trust. That eliminates many of the concerns that people generally have about "the cloud," while still giving you the convenience of having it web-accessible from anywhere you want to check it.

<comment><USER4> Or I can use X11 forwarding over SSH to access GNUcash from my desktop which seems a lot safer than hoping that whatever VPS I have on the Internet is magically secure.

</comment></comment></comment></comment></comment><comment><USER10> Nice but I _really_ dislike the website for this. I don't know if there is a term for that design but I hope it doesn't become popular.

<comment><USER11> I might give Zuck my bank credentials but I would have no trust whatsoever in some random .cc site (whose demo doesn't work).

<comment><USER3> yep, but it is open and you can self host your Cozy. So far you can't say the same of FB :-)

</comment></comment></comment><comment><USER12> I know this sounds pedantic and distracts from your software, but that's because the website really distracts. With any service or product, make the focus on that thing instead of the website taking the limelight, because even if it works you still steal focus.

</comment><comment><USER13> That question that is now left unanswered is: "Do you trust yourself and your server enough to keep your bank account info?

oh wait... before that... do you trust your own bank? Sometimes I have my doubts.

</comment><comment><USER14> I was just mulling over this same problem last week. This approach is a big improvement over giving Mint or Wave (or their scraping partners) my credentials.

Last I looked GnuCash didn't support any online banking except HCBI (Germany). So beyond the simple online finance manager functions, maybe it would be worth thinking of re-purposing this as a banking transaction aggregator that could feed GnuCash or Ledger or whatever. That would give it a better focus on the value for me, at least.

What I would really like to see is a startup or open source project that can sell banks on a standard API with granular OAUTH and drive that difficult adoption cycle. Something in the spirit of the German HCBI, but built on REST with the ability to limit an app's access to read-only, get balance and get transaction options.

</comment><comment><USER15> Does GnuCash not count?

<comment><USER16> ...or kmymoney?

<comment><USER16> ...or grisbi?

<comment><USER3> On your desktop, they counted. But in the cloud, as an open alternative to Mint, they don't :-)

The value here is that you can get your bank informations, aggregated on you personal server, for free and on a platform you can hack...

</comment></comment></comment></comment><comment><USER17> > So, would I give my bank credentials to a company of which business model is > to sell its user's data?

I think this sentence is poorly written. I'd replace "of which" with "whose" and "user's" with "users'".

</comment><comment><USER18> This sounds awesome. I've been looking to build an alternative to Mint, but getting banking data (in an automated way) has always been a pain. I look forward to trying it out.

<comment><USER19> Yeah Mint has so many flaws and warts but without the backend integrations it would be very tough to create a competitor.

There was a good article a couple of years back about why Wesabe lost to Mint[1], written by one of the Wesabe co-founders. The biggest issue according to him was that they chose to write their own integrations instead of partnering with Yodlee.

Since that time, Mint has left the Yodlee platform, but it gave them a first- mover advantage that no one has been able to overcome.

[1] [http://blog.precipice.org/why-wesabe-lost-to- mint/](http://blog.precipice.org/why-wesabe-lost-to-mint/)

<comment><USER20> And Mint was purchased by Intuit, which already had the backend integrations for years due to Quicken.

<comment><USER21> Keep in mind Mint is somewhat restricted to US. There might be a market for similar apps for other regions.

</comment></comment></comment></comment><comment><USER22> demo link appears to not work - blank screen

<comment><USER23> Also seeing this.

Google Chrome Version 31.0.1650.57 OS X

</comment></comment><comment><USER24> I opened the page and saw "Would you give your bank credentials to Mark Zuckerberg?" and waiting for something to happen. About 10 seconds later I figured I should try scrolling.

</comment><comment><USER25> That title is such a lie.

</comment><comment><USER26> Gnucash comes to mind.</comment>