Modules vs Microservices - <AUTHOR> https://www.oreilly.com/ideas/modules-vs-microservices <comment><USER3> I don't have much ideology behind going with microservices vs. monolith, but what we've done on some recent projects is organize our code into modules that only communicate with each other through a narrow and well defined boundary layer. If we need to split a module out into a separate service, then it isn't nearly as much work to split it out later.

One of the practical issues we've had with microservices that need to interact with each other in real time is ensuring a consistent state across systems. For example, let's say I need to change the status of an object and afterwards, call a separate service to change state there as well. What happens if the call fails in some way? You can't just run all of this inside a single database transaction anymore. Now you have to design your code to deal with several potential failure points and edge cases, which adds complexity. The other consideration is all calls to a service should be idempotent if possible. It makes coding from the client side a lot easier if you can just fire off a call multiple times (in case of local or remote failure) and not have to worry about state.

Just some of my thoughts, since this stuff has been on my plate recently.

<comment><USER4> We've used microservices for around 6-7 years now. One thing we realized quite early was that letting each microservice store state "silos" independently was a bad idea. You run into the synchronization issue you describe.

Instead, we've moved the state to a central, distributed store that everyone talks to. This allows you to do atomic transactions. Our store also handles fine-grained permissions, so your auth token decides what you're allowed to read and write.

One non-obvious consequence is that some microservices now can be eliminated entirely, because their API was previously entirely about CRUD. Or they can be reduced to a mere policy callback -- for example, let's say the app is a comment system that allows editing your comment, but only within 5 minutes. ACLs cannot express this, so to accomplish this we have the store invoke a callback to the "owner" microservice, which can then accept or reject the change.

Another consequence is that by turning the data store into a first-class service, many APIs can be expressed as data, similar to the command pattern. For example, imagine a job system. Clients request work to be done by creating jobs. This would previously be done by POSTing a job to something like /api/jobs. Instead, in the new scheme a client just creates a job in the data store. Then the job system simply watches the store for new job objects.

Of course, this way of doing things comes with its own challenges. For example, how do you query the data, and how do you enforce schemas? We solved some of these things in a rather ad hoc way that we were not entirely happy with. For example, we didn't have joins, or a schema language.

So about a year ago we went back to the drawing board and started building our next-generation data store, which builds in and codifies a bunch of the patterns we have figured out while using our previous store. It has schemas (optional/gradual typing), joins, permissions, changefeeds and lots of other goodies. It's looking extremely promising, and already forms the foundation of a commercial SaaS product.

This new store will be open source. Please feel free to drop me an email if you're interested in being notified when it's generally available.

<comment><USER5> and how that central 'data store service' is different than a single 'database service' (rdbms or nosql - CRUD) that all microservices connect to and run there select/insert/update/delete/crud ops?

Other than api - rest vs whatever binary rpc protocol, it sounds very much like a standard database...

<comment><USER4> The difference may seem subtle, but I'd argue that it is a whole other paradigm. It's one of those things that you either get, or you don't, but it might take some time to fully appreciate.

First of all, we're not an RDBMS, and don't pretend to be. I love the relational model, but there's a long-standing impedance mismatch between it and web apps that I won't go into here. There are clearly pros and cons. Our data store _isn 't_ intended as a replacement for classical relational OLTP RDBMS workflows.

If you let all apps share a single RDBMS, you're inevitably going to be tempted to put app-specific stuff in your database. This one app needs a queue-like mechanism, this other app needs some kind of atomic counter support, etc. You may even create completely app-specific tables. How do you compartmentalize anything? How do you prevent different versions of apps to stick to the same strict schema? How do you incrementally upgrade your schemas without taking down all apps? How do you create denormalized changefeeds that encompass the data of all apps? How do you institute systemwide policies like role-based ACLs, without writing a layer in stored-procedures and triggers that everything goes through? Etc. There are tons of things that are difficult to do with SQL, even with stored procedures.

I would argue that if you go down that route, you'll inevitably reinvent the "central data store pattern", but poorly.

<comment><USER6> Fowler refers to this as the "Integration Database" pattern, and advises against it: [https://martinfowler.com/bliki/IntegrationDatabase.html](https://martinfowler.com/bliki/IntegrationDatabase.html)

The issue with a centralized data store is that your services are coupled together by the schemas of the objects that they share with other services. This means you can't refactor the persistence layer of your service without affecting other services.

All that said, a single source of truth does do away with distributed transactions, so I can see the appeal.

<comment><USER4> He seems to come at it from a slightly different angle, and I can see how his scenario isn't a good idea.

It's worth pointing out that you do have the same challenge in a siloed scenario, but the "bounded contexts" are separated by the applications themselves, which no chance of tight coupling because there's no way to tightly couple anything. In the silo version, apps can still point at each other's data (e.g. reference an ID in another app), there's just no way of guaranteeing that the data is consistent.

The coupling challenge is solved by design -- by avoiding designing yourself into tight couplings.

For example, let's say you desire every object to have an "owner", pointing at the user that "owns" the object. So you define a schema for User, and then every object points to its owner User. But now all apps are tightly coupled together.

In our apps, we typically don't intertwine schemas like that unless there's a clear sense of cross-cutting. An "owner" field would probably point to an object within the app's own schema: A "todoapp.Project" object can point its "owner" field at a "todoapp.User", whereas a "musicapp.PlaylistItem" can point to a "musicapp.User".

(Sometimes you _do_ have clear cross-cutting concerns. An example is a scheduled job to analyze text. The job object contains the ID of the document to analyze. The job object is of type "jobapp.Job". The "document_id" field can point to any object in the store. The job doesn't care what the document is -- all it cares about is that it has fields containing text that can be analyzed. So there's no tight coupling of schemas at all, only of data.)

However... I have played with the idea of a "data interface" concept. Like a Java or Go interface, it would be a type that expresses an abstract thing. So for example, todoapp could define an interface "User" that says it must have a name and an email address. Now in the schema for todoapp.TodoItem you declare the "owner" field as type "User". But it's an interface, not a concrete type. So now we can assign anything that "complies with" the interface. If todoapp.User has "name" and "email", we can assign that to the owner, and if musicapp.User also has "name" and "email" with the right types, it is also compatible. But I can't assign, say, accountingsystem.User because it has "firstName", "lastName" and "email", which are not compatible.

</comment></comment></comment></comment></comment></comment><comment><USER7> I know microservices are successful in many organizations but one downside I've experienced from the microservices hype is starting an application with microservices.

It's very difficult to get the system boundaries correct while you're still iterating on core functionality, and if you get it wrong you're in a world of pain. Refactoring becomes very hard and performance suffers from unnecessary network overhead. Deployment is harder. Coordination is harder. Developers can't run the whole system locally. Testing is harder. Basically, if you don't have a very well defined interface between components, it's going to hurt.

I would not recommend starting with a microservices architecture. Build a modular, well-factored application and split out pieces if they need to be scaled separately or there are other compelling benefits of a microservice.

To quote Kris Jenkins:

This is your return type: Int

This is your return type on microservices: IO (Logger (Either HttpError Int))

Microservices: Know the risks.

[https://twitter.com/krisajenkins/status/762901550696194048](https://twitter.com/krisajenkins/status/762901550696194048)

<comment><USER8> "Developers can't run the whole system locally."

Developers should be able to run the whole system locally.

<comment><USER7> I agree. In the system I'm currently working on, they can't. I think it would be possible to implement, but no one has been able to take the time (or, perhaps sees the value in it).

(OTOH, I kind of doubt developers at Google or Facebook run the whole thing locally, so there must be some kind of end state for this.)

<comment><USER8> If the alternative to microservices is a monolith, and you can run the monolith locally, then logically microservices can also be run locally. If it's difficult to run all the microservices locally then that's just a sign of weak tooling.

<comment><USER9> "Just a sign of weak tooling."

Why does technical overhead take a backseat whenever a microservices vs monolith discussion comes up?

Yes, in a perfect world every org would have sufficient time and engineering resources to implement microservices for better scalability and code quality. In the real world, setting up and maintaining microservices has huge technical overhead, I'd estimate double that of the equivalent monolithic architecture.

If your company isn't flush with cash and the product you're building will never need massive scaling then it makes no sense to use microservices, at least from a business perspective.

<comment><USER8> "Why does technical overhead take a backseat whenever a microservices vs monolith discussion comes up?"

I don't think it does, but that's kind of off topic.

"In the real world, setting up and maintaining microservices has huge technical overhead, I'd estimate double that of the equivalent monolithic architecture."

I agree.

<comment><USER10> If two different solutions don't share the same "off topic overhead", they aren't off topic.

</comment></comment></comment></comment></comment></comment></comment><comment><USER11> Beginning in 2003, and until the height of the SOA craze around 2010, the Service Component Architecture (SCA) was seen as the holy grail of service integration. It encompassed both local/in-process (or in-JVM) as well as networked services (SOAP and REST), was polyglot in that it defined API bindings for native, Java, and even PHP and Cobol, could access external services, and was still quite practical. For those needing it, it also supported authorization and transaction policies and protocols.

When commercial interest in SOA middleware products dropped sharply, further standardization of version 1.1 slowed down, and Oracle, sitting on the SCA board, voted down all specs that had been worked on without further explanation.

To this day I still haven't understood what makes microservices different from SOA in a technical sense. I can get that the term SOA was probably burnt at some point, but if there's a real lesson to be learned from SOA failures, I'd really like to know. Maybe SOA was seen as too complex because it addressed some of the harder problems such as transaction and authorization protocols/boundaries, BPM, etc. upfront?

<comment><USER12> For a while I was consulting a lot around SOA - particularly around the IBM stack, which was one of the biggest SOA evangelists in the early days.

SOA was too complex for sure, but it wasn't just that it was complex. It's that complexity didn't actually deliver the return.

Part of the issue was the way SOA was sold. You buy a BPM or a Rules Engine and suddenly you unlock all this value and you can compose things on the fly -- Rules Engines were particularly bad in this respect. Business users were told they'd be able to tweak rules on the fly. This was never a reality.

Then you get outright hits in terms of complexity. Those BPM systems with two- phase commit were monsters. In fact they were so complex it was _more_ likely to fail. When in the vast majority of cases, actual failure rates were rare and easily handled by a reconciliation process. So the tech never really matched the need.

On top of that, the consultants cost a fortune. Instead of a few test environments, you needed 7. Managing test data and rollout to end-users became a nightmare... And even then, as the technology wasn't mature, you'd hit hurdles very late. Dismal production performance was a common one.

It's a bit sad. A really interesting set of ideas and technologies - <USER2> really poorly sold and way past the hype to deliver. It's equally true of related technologies like CORBA.

<comment><USER11> Re: "rule engines"

I know exactly what you mean, having suffered through JRules projects, but don't consider rule/forward-chaining languages part of a SOA stack per se (I especially loved the idea that rule bases, unlike services, don't need testing, because they're end-user configuration parts, and because, like SQL, they're kindof declarative).

Reading through the answers, I still don't know how microservices are any different from SOA ):

</comment></comment></comment><comment><USER13> I co-founded startup 6 months ago, since day 1 we use micro-services. For us the biggest benefit was that at the begin we could hire people knowing different programming languages (we managed to build a team of 5 in 3-4 weeks) and they could build a small parts of the system communicating via http/RabbitMQ. Downside is that we had to have a CI&CD from day one and it costs us some resources.

I am not saying microservices are cure for everything and of course there is a place for well maintained monoliths but I find that even for smaller teams micro-services can be just easier than monolith.

<comment><USER14> I don't think using micro-services from day 1 is a wise use of resources. What if one of your engineers, who probably owns an entire service, quits? And it's in Haskell because she felt like it?

<comment><USER15> This is a totally nutty scenario. Microservices are not "do whatever you want!" \- they give you the freedom to choose your stack. It is _obviously still a business decision_ to choose Haskell and you've got other problems if developers are building things in random languages that they feel like using without a larger discussion.

The issue here isn't Haskell it's ownership and process.

<comment><USER14> Given how they described their org, it seems like a valid scenario. Extreme examples are tools for illustrating a point.

Micro services from day one is a premature optimization. Just saying that doesn't necessarily paint a picture of why it might be.

<comment><USER16> I agree, but I don't think microservices are properly classed as an optimization of any sort, premature or not. Microservices arise because a company can't communicate/manage itself internally.

This does not mean that you must have one giant 50MB executable to run your whole company, but it probably does mean most companies shouldn't have 60 200-line microservices.

<comment><USER17> I think that microservices may be an actual optimization when the application flow has several clearly separable tasks that have varying requirements and you need to divide the load over several machines. For example, one task may be mostly I/O heavy, another will use a lot of RAM and a third may mostly be CPU bound. When you distribute the load over multiple servers, microservices can make it easier to tailor each server to the needs of the services it runs. The I/O bound workload doesn't need 100GB RAM and the CPU bound workload may not need several gigabit interfaces.

That said, I haven't personally worked with a microservice-based architecture where this ever became a useful optimization. Often it is exactly as you say: a technological workaround for an organizational problem.

</comment></comment></comment></comment></comment></comment><comment><USER18> I used to make this argument. I'm not so convinced anymore. Much of this modularity can be achieved now, split you libraries into two, one for APIs and the other for Implementations. Then in your build, only include the API libraries as dependencies, and include both at runtime. It doesn't enforce runtime modularity, but it's generally good enough.

Why this isn't great, it encourages monolithic mindset. A huge benefit to microservices is that they are small! This means means that you have releases that are faster per service, build times that are faster per service, code that can be more easily reasoned about.

The author is correct that it introduces expensive cross service calls, so you do need to be thoughtful on your boundaries, but what you end up getting is simpler on a per instance basis. You don't need to become devops experts; there are plenty of options for deployment that handles a lot of this: heroku, gae, beanstalk. Hell, there's even still available to you for your own D.C., though I'd argue that if you're running in your own D.C. then you should think very hard on why that's important to your business (even if it's very large).

The earlier you have microservice architecture built into your stack, the easier it is to continue on that path, once you're monolithic, it's a huge amount of work to go back the other way.

<comment><USER19> A huge benefit to modules is that they are small! This means means that you have releases that are faster per module, build times that are faster per module, code that can be more easily reasoned about.

The earlier you have modular architecture built into your stack, the easier it is to continue on that path, once you're monolithic, it's a huge amount of work to go back the other way.

<comment><USER18> Have you considered what will happen when you're application has reached a muti-gig deployment? Where you have static resources commingled with business logic? Where you have rendering blended with DB access?

Modular systems are theoretically as good as SOA or microservices, but in practice they are not.

Failure can not be isolataed as easily, when there is a problem in the system, the entire thing crashes.

Also to your point; is that a single repo, or multi-repo source control system? In a single repo system your build and testing cycle becomes longer and longer for the entire service, regardless he size of changes, you have to deploy the entire thing. Every successful business with a monolithic deployment, regardless of repo structure, ends up in the same place (based on my experience): a large unwieldy beast, maintained by dozens or hundreds, or thousands of engineers, who each have limited knowledge of the runtime. It becomes slow, hard to deploy, hard to test, hard to make changes.

Microservices/SOA does not alleviate the need to good design, but it doesn't allow for the above to be true on a perservice basis, shortening turnaround for response to issues and deploying new features, it is better.

<comment><USER20> Holy crap!

How do you get multi-gb deployments? I mean at some point I suppose anything is possible but I'm used to binaries on my system being KB or low MB.

<comment><USER18> That qualifies as a microsservice in my book :)

To add more: you get there by not practicing SOA, never breaking up a service, working at a company constantly ships new product rather than focusing on restructuring the application, not having developers own both the build and deployment of the app such that they don't experience the pain; reasons, etc.

<comment><USER21> Come on, you can have million lines of code and still get binaries of few megabytes. If that counts as microservice then everything does.

This is a frequent problem when discussing microservices - nobody defines how large they actually are.

<comment><USER18> Size is not the only reason, sometimes it's about performance and system utlization.

Separation of concerns tends to be my strongest indicator for defining service boundaries.

</comment></comment></comment></comment></comment></comment></comment><comment><USER22> "The modularized monolith can be scaled horizontally as well, but you scale out all modules together."

That's not exactly true. Yes you probably have to ship the whole monolith, but who said that you also have to get traffic for all the parts? For example you have /users/ and /books/. You can configure your nodes to only serve /users/ and configure different (maybe more) nodes to serve /books/. The code sits there but who cares?

<comment><USER7> We did this at my last gig. The application was monolithic[1] but ran in multiple environments: web application, API, admin, backend workers.

It worked quite well. The one downside is we had to load all the code (it was Rails) so processes took more RAM than strictly necessary. But sharing data models across all these services was pretty easy.

[1] There were a few separate services, for example a documentation CMS.

</comment></comment><comment><USER23> I think the article is missing a key value of microservices, or at least smaller services: service ownership. With a monolith, who is on call for the service when something goes wrong? How does that person find an appropriate person to diagnose the issue in one of the 100 libraries included in the monolith? What does the monolith dashboard look like?

The great thing about small services is that a team developing a service can own it from top to bottom: including:

      1) being responsible for metrics, alarms, dashboards, and everything else required to monitor the service
      2) being oncall for the service and getting directly paged when their are problems

And of course, there are other social/organizational problems with a monolith, another example being deployments. I want to deploy my new feature but I'm blocked because someone introduced a bug in some unrelated library that's clogging the entire pipeline. Or, I have to release my feature according to the deployment schedule of the monolith, which may not make sense for my team. With smaller services, a team can own its own deployment pipeline and decide when it wants to deploy.

A third organizational benefit of smaller services comes process separation. GC'ed languages work really hard to help developers pretend that memory is free, but memory is still a finite shared resource and it only takes one misbehaving module to cause the whole process to start stalling in large GC pauses. With smaller services you get process separation which makes the problem much more tenable. And of course there are other exhaustible shared resources like threads, and file descriptors.

At the end of the day, I prefer smaller services because I like the social organization where a company consists of agile, autonomous teams owning their own services. I feel a monolith service actively discourages that and leads to social organizations that are less productive and successful.

<comment><USER24> Those are organizational concerns that you're conflating with microservices vs monolith. They're tangential. I see no reason why you can't assign team responsibility to individual modules vs microservices. You can collect metrics for both modules and microservices and publish them in a dashboard. Alarms and monitoring are probably unnecessary at the module level in most cases - you'd just do it once for the whole monolith.

<comment><USER23> Good point, but I don't think it's necessarily incorrect to conflate organizational concerns with architectural concerns. I am reminded specifically of Conway's law: [https://en.wikipedia.org/wiki/Conway%27s_law](https://en.wikipedia.org/wiki/Conway%27s_law)

It may be possible to deploy a monolith without having monolithic processes and organizations in place, but does anyone have experience successfully doing so in practice? And how easy is it compared to doing so with smaller services?

</comment></comment></comment><comment><USER25> For my employer, the _whole point_ of microservices is separate deploys. When we had hundreds of engineers committing on the monolith, a bad change in one out of the few dozen commits in a given day's upgrade could require rolling the whole thing back.

Now each service deploys (usually) one or two commits at a time, completely understood by the person who clicks the "upgrade' button. People working on unrelated code don't need to block each other's release velocity.

More disciplined interfaces could have solved the spaghetti problem, but lots of small services that a few people have absolute power over can move a lot faster than an integration/release process shared by thousands.

</comment><comment><USER26> I've advocated for this approach before, I think it's definitely true that a single code base is an optimal place work out early architectural decisions so you can optimize the interfaces and separation before committing to the overhead of multiple repos and deploy stacks.

One of the challenges, though, is making sure the whole team understands the vision and doesn't violate the intended separations. Working primarily in Rails, I've found it to be pretty terrible in this regard, both due to ruby's global namespace, but also just because there are no conventions to properly separate app-level modules (Rails Engines are a second-class citizen). Django is significantly better since it gives you apps as first-class citizens, and because of Python's explicit module import, but even still you can quickly end up with a ball of mud if you're not careful.

</comment><comment><USER27> We build a modular system based on Java with OSGi. It served us well but now we feel we have reached the limits of such a system and are looking at a more microservice based approach.

For example a modular system is not going to help you when a module is misbehaving since the whole thing still runs in the same process (JVM in our case). If someone introduces a resource leak in some trivial module the whole thing still comes down.

<comment><USER28> Exactly, that's one of the tradeoffs discussed in the article (author here).

Another pattern that might work, which I didn't include in the article, is to scale-out the modular application (assuming it's 'stateless') into several clusters. Each node in the clusters still has the whole modular application. However, each cluster will be responsible for handling a certain part of the API. Then, put a load-balancer/API gateway in front that can route different functional parts of your API to different clusters. Scale up the individual clusters as required by load. Even though all nodes contain all modules, depending on which cluster they're in, only a certain subset of modules really takes up CPU cycles. There's still no node-to-node communication necessary, since all nodes contain all logic.

Certainly not a pattern that's always applicable, but I've used it with success several times for webapps with REST backends.

<comment><USER27> For us scaling was never an issue; We did the stateless scale-out thing. Even solving statefull is relatively easy (at least in Java) with solutions like Hazelcast. The main drawback is there are usually only a few services in your monolith that are required to scale out. But you have to deploy the entire thing when scaling out.

As for OSGi, OSGi is complex; I dare to say that the complexity of OSGi rivals that of a microservice setup. If I had a nickle for every classloader issue I debugged... ORM was especially fun (For example wrote this piece way back: [http://www.datanucleus.org/products/datanucleus/jdo/osgi.htm...](http://www.datanucleus.org/products/datanucleus/jdo/osgi.html) ). But I must admit that I don't think we could have created (and maintained) such a large modular application without OSGi. Debugging itself is also way more complex. When an issue arises you spent a lot more time tracking down which module is misbehaving. Even though we had inserted lot's of probes (which ended up in graphite) and log statements (which ended up in graylog) to counter that.

In my experience writing smaller, simpler applications (which I acknowledge also have their own complexity with distributed debugging) are still easier to understand then an modularized application.

<comment><USER28> I'm with you on the complexity of OSGi, though some of the complexity plainly arises because it truly forces you to modularise vs. just winging it. In that regard, the new Java 9 module system has less of the service dynamics and classloading tricks going on. Very curious to see how the community will pick up the new module system.

</comment></comment></comment></comment><comment><USER29> At the start-up I currently work for, I designed the system to be composed of microservices (with Swagger/OpenAPI), even when it might've been easier to write modules, for scalability reasons. Before I was brought on as the first engineer, we had a series of contractors build a poorly architected monolith that had issues scaling. Microservices have enabled us to independently scale different parts of the service as load changes. It's also forced a very strong separation of concerns.

My main complaints are that we've run into various instances where we need to access some data in a different service, so we stuff it into some object so that the next service can pull it from the DB. However this is a solvable implementation issue.

The other complaints I have are that monitoring and profiling are much more involved. Additionally, setting up a new service can be painful if you don't have a template.

Overall, we've had a good experience with microservices and it's enabled us to deploy faster and scale simpler.

</comment><comment><USER30> Few advantages for Microservices over modules is - performance of one module impacting other modules. 1. Say one module is running slow, that will impact entire application. 2\. If we want to push code for one module, we need to push code for entire application. So there is no deployment isolation. 3. We have to have all the modules written in same programming language and same version of the programming language. Hence there is no clear path for upgrading version of programming language.

Micro Services addresses all these assuming we deploy Micro Services separating the services (including data). But the tradeoff is a bit of complexity and latency for the benefit of complete isolation and independence.

<comment><USER31> _1\. Say one module is running slow, that will impact entire application._

Why? Unless you're doing something silly like running the whole service on a single process+thread, the other workers should still respond just fine while the slow module is crunching away.

 _2\. If we want to push code for one module, we need to push code for entire application. So there is no deployment isolation._

Yes and no. In what sense does that worry you? You can still ship only changes to one module, using version control. And you can still do a gradual deployment, avoiding downtime. The only thing you can't easily do is take down a whole module while keeping the rest of the application running.

<comment><USER30> 1\. Because infrastructure resources are shared - like CPU & memory 2\. If all the modules are managed by same team, yes you are right. If we want each module to be managed by one pizza scrum team, we need need deployment isolation to avoid churns. Don't you think so?

</comment></comment></comment><comment><USER32> > Modules are natural units for code-ownership as well.

I read a snarky blog post a few years ago entitled "Blame-Oriented Software Design". It described legitimate design patterns that software developers in a Dilbert corporate environment can use to deflect blame and extra work caused by others' shoddy code. Examples include well-defined module boundaries, strongly-typed APIs, and extensive assertions and logging enabled in production code.

Unfortunately, I can no longer find this blog post, but I chuckle about it often enough that sometimes I consider rewriting what I remember of it myself. :)

</comment><comment><USER24> I've worked on both types of projects and I would never choose microservices over monolith if presented the option.

Rather, I agree with the author that proper separation into documented modules gives most of the benefits from microservices without any of the numerous drawbacks.

Microservices seriously increase the operational overhead. They increase the hardware expenses. They increase service latency through round trip times and unnecessary work. They increase the code complexity through unneeded serialization/deserialization and REST calls vs plain old function calls. They make debugging a lot harder. They give you all the pain of distributed systems and networking when all you previously needed was a function call.

With Go (and many other statically typed languages) you get proper modules that can't reach into the private implementation of other modules (even with reflection.) They can't have import cycles. The compiler will take care of alerting you when an API changes in an incompatible way. Likely all your modules will share a backend database(s) so you need to take care to use the public interface of the responsible module rather than reach around behind its back with direct queries - but that's a solvable organizational problem.

I wonder sometimes if the microservices craze isn't trying to find a technical solution to human problems that would be better dealt with via communication and creating solid organizational practices. Like team A doesn't trust team B and rather than work out a common set of norms and rules they just start using microservices to bypass dealing with the problem all together.

</comment><comment><USER33> For those of you happy with your use of micrsoservices, how many microservices does your team handle?

I don't mind microservices but I definitely think my company has taken it too far, for my team of 5 we have ~25 separate components/deployments which make up ~12 microservices. It makes it impossible to keep track of each service and be familiar with idiosyncrasies in each project.

</comment><comment><USER34> In my experience, the biggest obstructions to modularity are the "unknown unknowns". I can't tell you how many times I've been trying to set up some software where it turns out the installation was looking for file ABC in directory XYZ even though the documentation wasn't up to date and listed directory EFG (or nothing at all). Also, environment variables (i.e., global variables) are a pain and should be eliminated altogether. What would replace them? I'm not sure, but _any_ random idea has got to be an improvement of some sort over the current system.

Docker alleviates the environment hell problem somewhat, so it's easy to set up a bunch of contained microservices that aren't going to fall apart when the global environment changes.

We need more research into the complexity of programming patterns. The same patterns and anti-patterns keep popping up under different names in slightly different forms.

<comment><USER35> Speaking of random ideas: dump the globals into functions (one function per global) - that's right a dumb single-variable function. You can't monitor or pop an assert on a variable, but you can put slap asserts inside a stub function, etc. Plus you know a function ain't local. Globals are such poison that the minor inefficiency created by converting a few globals to functions is usually meaningless.

I begin to think that we need a richer vocabulary to address "complexity." To analyse it into various forms, (some of which are likely to be beneficial.) Separating code into lumps means more lumps; but fewer dependencies, more known absence of dependency... We keep using one word "complexity" to point to various things. Distinguishing between Complex(opposite of 'simple') and 'complicated' (opposite of 'easy') is a start I suppose, but I can't help thinking there are more careful distinctions that could be made.

</comment></comment><comment><USER36> I even found using submodules in git was really helpful as well even though it wasn't a module per say. For example in Mongo, I have models in node.js and it is really simple to share the model in every node project across the org as mongo models contain schema and validation etc.

</comment><comment><USER37> Recently I've seen a few folks use protobufs within parts of a monolith as a mechanism to enforce a strongly typed interface between components. This helps define a contract between teams without the overhead of a distributed system.

<comment><USER38> gRPC can do the same and define the service calls.

</comment></comment><comment><USER39> I found this a refreshing article that have a nuanced view of different solutions. Also I was glad it acknowledged that different solutions make sense at different scales and times in an organization's life.

</comment><comment><USER40> Watching a discussion like this really make me wonder this: what is a module, anyway? There are obviously varying aspects of modularity, such as:

* different code locations (e.g. functions)

* different namespaces (e.g. libraries / Python modules)

* different release cycles / distribution models (e.g. ES6/Java modules in this sense?)

* different OSes / languages / security models (e.g. microservices?)

Seems like people (including myself) are confused by putting these in a one- dimensional spectrum. The reality is probably never that simple.

</comment><comment><USER41> This is why I tend to build microservices that implement a bounded context. Then compose those different APIs, as necessary, to implement the public facing API.

I don't need granular level services, it places too much burden on operations, but I still get the separation of context, concerns and 'anti-corruption' layers that I'm looking for in my design.

</comment><comment><USER42> gen_server:start_link/3

The original microservice :-)

</comment><comment><USER43> I don't have a TV so somehow I missed the moment when "monolith" became a dirty word.

</comment><comment><USER44> His comments with regards to the lack of compile time checking of the interfaces between microservices couldn't help me but think of GraphQL. Using GraphQL as the layer between microservices could alleviate this issue. Specially if the usual "deprecate, don't version" approach of GraphQL is followed.

Normally GraphQL is talked about within the context of user facing applications interacting with servers but it could be quite useful for strongly typed machine to machine communication.

We already use GraphQL for our client facing API. We're going to start rolling out microservices at our startup and I think we'll use it for communication between microservices as well.

<comment><USER45> I'd recommend taking a look at gRPC.

<comment><USER44> Just took a look at gRPC. Thanks for the great recommendation!

</comment></comment></comment><comment><USER46> Be interested in if anyone has much experience in using an Actor type model instead of microservices. Things like Akka/.net / orleans / Erlangs OTP etc

</comment><comment><USER47> Isn't a microservice just a small application behind a network boundary? Moving what might be a big ball of mud into smaller ones?

</comment><comment><USER48> shouldn't the goal be to do whatever provides the most value and builds your product or business the fastest? if you waste time with a microservice architecture where you could've done more, faster with a monolithic app that seems like a poor use of time.

<comment><USER49> "If I had 8 hours to chop down a tree, I'd spend the first 6 sharpening my axe" \- Abraham Lincoln

If you delivered the initial thing in 4 weeks vs 8 but you'd spend way more in future development and developer time, would you say you made the right decision?

To put it another way, delivering the wrong thing faster doesn't make it any more right.

<comment><USER48> couldn't you just as easily say you build the wrong thing in more time with your hypothetical increase in future speed, but you go out of business because you never have any customers?

what you're saying is the right thing, if you have unlimited money.

</comment></comment></comment><comment><USER50> a micro service should be independent.

<comment><USER51> If a micro service is independent it makes no calls to other micro services. Thus the system has a single service and that service is a monolith. Contradiction, thus a micro service cannot be independent.

<comment><USER50> Lets say ycombinator.com was news.y, www.y and apply.y, all served from the same "monolith". And they decided to make them into separate micro-services ... The best way is to make them all independent!</comment></comment></comment>


How 'Waiting for "Superman"' Will Further Fuel the Education Debate - <AUTHOR> http://nymag.com/news/features/67966/ <comment><USER2> Just saw this last night in SF courtesy of the Commonwealth Club. Highly recommended.

You're shown that getting results is straightforward: get rid of poor teachers and reward good ones. One stat that was particularly interesting, from a Stanford researcher whose name I forget, was that replacing the worst 6-10% of teachers would put us on the same proficiency level as Finland.

Unfortunately, the system makes that very difficult. Many teachers are granted tenure, making them impossible to fire, and educators' compensation isn't designed to allow for performance incentives. Contracts demanded by unions are partially to blame.

Also, our education system was built for previous generations' economies. Professionals, scientists, technical workers, factory workers, and laborers were needed in different proportions than they are today. Now we have more highly skilled jobs without enough highly educated Americans to fill them. SV and schools in Redwood City and Woodside are mentioned specifically.

It examines the costs of poor education, like the staggering number of dropouts who end up in prison. Their incarceration cost could put them through private school with money left over for college.

Saying the film demonizes Weingarten is exaggerating. She doesn't look great, but there are clearly a lot of factors at work.

 _Waiting for Superman_ makes clear that the way forward is good teachers.

<comment><USER3> The problems are dual, and nobody likes the solutions.

On the one hand, yes, you have unions, which theoretically are sticking up for the workers but in practice spend a large % of their time and resources sticking up for the lousy workers who deserve to be fired anyways.

On the other hand, you have about half of the country devoted to relentlessly slashing education budgets in the name of "less government". In a small-l labor dominated industry, that effectively means smaller paychecks and/or more work for the same pay. So good teachers who are frustrated by the union shenanigans don't have a lot of other alternatives - who else is gonna stick up for them?

Real solutions would be a combination of big pay incentives for star teachers (not that I'd necessarily be a star, but why on _earth_ would I teach at those rates when I can be an engineer?), coupled with a much looser structure on tenure, more dynamic general situation, etc. That would be the kind of incentive to empower the good teachers and disempower the bad ones. But you can't just blame the unions without addressing the other side of the coin.

<comment><USER4> I would much rather you be an engineer than a teacher. Why on earth would we want to incentivize our creators and innovators to become teachers?

<comment><USER3> Well, 2 comments and we're 1 for 2 so I guess my 50% figure was right on.

I'll respond with a couple more questions: Do you place a value on increasing future "creation and innovation" by doing a good job of educating kids? If they learn exclusively from mediocre, by-the-book personalities, do you think that helps or hurts the "creation and innovation" parts of their brains?

<comment><USER5> Your question seems to be implicitly assuming that most great teachers could also have been great engineers. At the risk of stereotyping, I do not think that is true.

A great teacher must be dynamic, engaging, intelligent, able to connect with children so that they can teach creation and innovation. But an engineer must be intelligent, methodical, and able to master vast amounts of technical knowledge.

I suspect most people who make great engineers would not make great teachers, and vice versa. There will be some that could easily be great at either though.

Those, I think would better serve society by going into engineering for a few reasons. One is that the number capable of being a truly great engineer is smaller than the number capable of being a truly great teacher.

Both are significant for society, but one is more rare than the other. Also, it seems that the point of education is to be able to produce great makers such as engineers who do the work that holds society together. If we always direct our best minds to enhancing the best minds of the future, we will have highly educated children but little or no actual progress for those children to enjoy.

</comment></comment></comment></comment></comment><comment><USER6>
      I was stunned because [An Inconvenient Truth] was so
      powerful that my wife told me we couldn't burn incandescent
      bulbs anymore. She didn't become a zealot; she just
      realized that [climate change] was serious and we have to
      do something.

Well, that's _something_ , I guess. Not going to make much of a difference, though. As David Mackay says in _Sustainable Energy - without the hot air_ , "If everybody only does a little, the impact will only be a little."

</comment><comment><USER7> Articles about education too often end with platitudes about how we need real debate to make changes occur. I'd argue we need action... preferably from the private sector.

Judging by the lack of comments on this article so far, not many people here follow this issue. The DC public schools are a microcosm of the whole ed reform movement, and an example of how difficult it can be to navigate the politics of reforming a corrupt system.

Rhee has done a lot to improve the efficiency of the district (in terms of getting books and supplies where needed, and using school resources wisely), but at the end of the day, her approach to reform (command and control vs. consensus building) is what will likely end her tenure early.

Right now, the mayor who backed her (Fenty) is in a tight race with a candidate who is exploiting people's distrust in a government that, for better or worse, acts based on what it believes is right for the people, not what the people believe is right for them.

Or, in the tl;dr edition:

When working within the confines of politics, you can get short bursts of successful but temporary reform, or you can be safe politically while accomplishing very little. There's gotta be another way.

<comment><USER8> Could you explain how action from the private sector might help to reform the public education system. Unless you're referring to vouchers I'm not sure I understand the connection you're trying to make.

Also, I'm not sure its accurate to claim that Rhee might lose her position if Fenty isn't re-elected. His opponent seems to be on the same side of education reform as him and most of his claims to "anti government" policies are more in the realm of police and tax reform (at least as I understand it; I don't live in DC)

<comment><USER7> I apologize for the lack of clarity. Didn't want to get too far into the weeds, but I think after school is a great place to start. My favorite example of this are Japanese cram schools (Juku), which serve a much larger and varied function than most people who have heard of them realize.

Japan has an extensive network of for-profit after school programs that act as a check on the standards enacted in Japanese public schools. When the Ministry of Education decided to change its standards (which affect curriculum across the nation), the juku responded by offering tougher courses, balancing out any perceived weakening of the public schools. Rosegaard's book is my favorite on the subject of Juku: [http://www.amazon.com/Japanese-Education-Cram-School- Busines...](http://www.amazon.com/Japanese-Education-Cram-School- Business/dp/8791114918)

There is some inherent unfairness to that system, mainly having to do with parents who can and can't pay for juku. But there are ways to mitigate the issues caused by socioeconomic differences. Some of those issues have already been somewhat addressed in America by the Supplementary Educational Services (<http://www2.ed.gov/nclb/choice/help/ses/index.html>) portion of NCLB. The program essentially forces failing schools to pay for after school tutoring.

I'd prefer a better designed SES program, but I think after school could be more promising than charters or vouchers for several reasons:

1\. After school addresses the reality that children are as, if not more, affected by experiences outside of the normal school day 2\. It would help avoid many of the contentious issues surrounding teachers unions 3\. It would allow for innovative approaches to curriculum and teaching without the burdens of having to supply everything we expect from a school (music, art, gym programs; extracurriculars, tricked out facilities) 4\. It might stimulate a growth of small, education-oriented businesses in poor/minority communities (there are several successful, minority-owned tutoring companies in my hometown that rely on SES)

This isn't to say nothing should be done to reform schools from the inside. I just think we could use a two-pronged approach.

<comment><USER9> As someone who went through the tortuous education system in Taiwan, where the culture of cram schools also existed, and standardized testing was king, I would not wish it upon anyone. In fact, I think cram schools are one of the _worst_ ideas ever conceived in education.

All it does is created socially retarded (in the non-derogatory way) children unable to deal with anything that doesn't come out of a textbook, with no discernible life skills whatsoever.

I've spent _years_ unlearning things from that stage of my life, and I'm still not done. Every day I'm learning social norms and life knowledge that I honestly should have found out at age 12, not age 24. When you send kids to a public school for 8 hours, then spend the next 6 hours not interacting with people, and instead cramming for their next exam so they won't be hopelessly left behind, you're creating a massive social problem for later. When your children's only free time in a day is spent wolfing down packed dinner while the taxicab speeds from one cram class to another, you are doing yourself and your children a grave disservice.

There is a fundamental difference between _school_ and _education_ , one would be wise not to confuse the two.

 _More schooling_ is an absolutely _ass backwards_ solution to our educational problems. The solution is _better_ education, not slapping de facto mandatory private schools on top and making our kids work more hours than an EA employee.

<comment><USER7> Given a choice between what we have now and a cram school culture, I would prefer the latter. At least then the (predominantly poor, black, and latino) students our public education system routinely fails would have a fighting chance at a decent life.

That said, I don't want to give the impression that cram school culture should accepted and imported wholesale to America. I used cram schools as an example of outside forces based in capitalism acting as a self-correcting mechanism for a public school system. Given the political difficulties of transforming public schools, I think it would be helpful to have at least _one_ place students can go to receive an education.

</comment></comment></comment></comment></comment><comment><USER10> Single page: <http://nymag.com/print/?/news/features/67966/>

</comment><comment><USER11> "Most astonishing to Rhee was how easily the contract was finally approved. "The entire time the union was fighting us, they said, 'Our members are never gonna accept this'—then it passed by an 80 to 20 percent vote!" she exclaims."

Hah, never assume that the interests of the teachers and their union representatives (or any other set of elected officials) always coincide. Specifically, proposals to decrease the number of workers but raise their pay (and/or give large amounts of money to those layed off) often bring workers and unions into conflict.

<comment><USER12> I think that's just Rhee being dumb. You're in a negotiation. Of course they're going to say they can't accept this, until they do. Union staff almost never bargain contracts anyway. Typically it's done by a bargaining committee consisting of members, some of whom are elected officers but mostly just volunteers.

</comment></comment><comment><USER13> _sigh_

Lookit, if teachers unions were the main culprit, then education outcomes in right-to-work states (the South, mostly) would be significantly higher than states where teachers unions exist. This is not the case. The problem is one of attitudes (both familial and institutional) and one of teaching talent (the students who enroll in Schools of Education are below the median for GPA and SAT scores for universities that offer education degrees).

Attitudes are hard to explain; Friday Night Lights (the book) examines but doesn't explain. The quality of teaching stock is explainable, but no one likes the explanation - the opening of the workforce to women has taken a lot of high-quality women out of the classroom and into the previously male- dominated workforce. All those great women doctors, lawyers, managers, engineers, architects, and so on would have been teachers 50 years ago.

I don't have a good answer, but _Waiting for Superman_ 's demonization of Randi Weingarten and the unions is a terribly small portion of the problem. Boogeymen are easy to hate; it's harder to point the finger at ourselves.

<comment><USER14> I'm confused. In spite of being a right to work state, Alabama, Arizona and Arkansas [1] all have teachers unions.

<http://www.myaea.org/>

<http://www.arizonaea.org/>

<http://www.aeaonline.org/>

Why would you believe that right to work states would not have teachers unions? It's true that a right to work state will probably not have unions the workers don't want, but that isn't the same thing.

[1] I'm not cherry picking, just working down this list: [http://en.wikipedia.org/wiki/Right-to- work_law#U.S._states_w...](http://en.wikipedia.org/wiki/Right-to- work_law#U.S._states_with_right-to-work_laws)

<comment><USER13> _Every_ state has public sector employee unions. The UAW is also in most right-to-work states. But the vast majority of employees (public and private) are not members of those unions and I'm positive that teacher contracts in RTW states are not collectively bargained.</comment></comment></comment>


HBO Wants Google to Censor HBO.com - <AUTHOR> http://torrentfreak.com/hbo-wants-google-to-censor-hbo-com-130203/

<comment><USER2> Just from the screenshot in the article, it looks like at least 14 of the 23 links shown are completely legitimate (the HitFix.com, ihav.net, IGN.com, and HBO.com ones).

Since I read one of those sites (HitFix.com, a news/reviews site), I'm actually now curious how many of its articles have been spuriously removed from Google's index thanks to incorrect takedown requests like this one.

<comment><USER3> Google posts all their takedowns to ChillingEffects (<http://www.chillingeffects.org/>)

From their search HitFix seems to be hit a few times - [http://www.google.com/custom?q=HitFix.com&sa=Search&...](http://www.google.com/custom?q=HitFix.com&sa=Search&cof=T%3A%2300000%3BLW%3A200%3BALC%3A%230033ff%3BL%3Ahttp%3A%2F%2Fimages.chillingeffects.org%2Fchilling_effects.gif%3BLC%3A%230033cc%3BLH%3A25%3BBGC%3A%23FFFFFF%3BAH%3Aleft%3BVLC%3A%23336699%3BGL%3A0%3BS%3Ahttp%3A%2F%2Fwww.chillingeffects.org%3BGALT%3A%23339900%3BAWFID%3A11493b1bed6cf916%3B&domains=www.chillingeffects.org&sitesearch=www.chillingeffects.org) \- not too much though.

Studios are going to continue mass automated takedowns of legitimate content until there's some kind of punitive measure put in place for blatantly incorrect notices.</comment></comment>


Software is for little people - <AUTHOR> http://www.ruddwire.com/1085/politics/software-is-for-little-people/

<comment><USER2> hobbits?</comment>


Red Hat Pays MS Ransom Demands - <AUTHOR> http://boingboing.net/2012/05/31/lockdown-freeopen-os-maker-p.html

<comment><USER2> No mention of the fact that to obtain the 'Ready for Windows' certification (or whatever they'll call it) for x86 platforms, OEMs must offer the option to disable secure boot.

ARM doesn't have the same requirements, but phone manufactures have been doing this for years anyway so it's not an MS issue.

</comment><comment><USER3> That sounds pretty monopolistic to me. So because you are the dominant player in the market, and you know all manufacturers want your OS, you make it so any other OS vendor has to pay you for the right to use that OS on the "Windows- blessed" machines?

That sounds like a pretty scary future to me, and I don't like that Microsoft is getting away with abusing their monopoly power like this.

</comment><comment><AUTHOR> Red Hat is officially a billion company and it makes this real money not from consumers but from small to medium sized corporations giving them a bargain basement end-to-end OS solution.

It is not hard imagine that RH votes only with its pocket book and is "happy" to join the mutual extortion racket which modern intellectual property purveyors seem to have become.

This is on top of RH knuckling-under to Apple's patent extortion by removing the Launchy Launch-bar.

Should open source advocated be cheering RH in any fashion now?</comment>


MIT Developing Ionic Wind Thrusters as Efficient Alternative to Jet Engines - <AUTHOR> http://inhabitat.com/mit-developing-ionic-wind-thrusters-as-efficient-alternative-to-jet-engines/ <comment><USER2> So...Iron Man's repulsors? I always thought they might work like some ionic air thrust thing. It seemed to be the only way they COULD work, given an energy source powerful enough.</comment>


Graphic Design Is About to Be Upended by AI - <AUTHOR> https://www.wired.com/story/when-websites-design-themselves/?mbid=social_tw_backchannel <comment><USER2> As a tech journalist (and web designer on the side), I'm sick and tired of this "AI will disrupt x, y or z" idiocy. Especially when AI means "heavily scripted automated services".

Designers, including for the Web, won't be replaced by machine any soon. Companies value spending money on someone who knows how to best present their content and takes care of "all that techical stuff".

For simple websites, without much dynamic content, it's relatively cheap to hire someone good instead of using a service spitting out the nth Wix clone; for more high impact websites, forget about it: it's a strategic asset and you will have entire teams on it. Shall they automate part of their job and optimize it? Sure, they already do. And AI has nothing to do with it.</comment>


From a Farm in Egypt to Building a YC Computer Vision Startup for Fitness - <AUTHOR> http://techcrunch.com/2015/03/23/smartspot/ <comment><USER2> [http://www.smartspot.io](http://www.smartspot.io) because googling completely failed and I had to find it via product hunt

This looks like a fascinating product; if the founder's around, does it track back angles? Is it useful for dls/squats/cleans? Can it track bar paths? Can it track body angles over time, or does it (as of now) just track final angles?

<comment><USER3> Cofounder here. We do track back angle. Squat was our #1 priority, since so many people screw up.

It does track body angles over time! Check out the end of our video for a few different exercises: [https://www.youtube.com/watch?v=L_qaqoGXHDU](https://www.youtube.com/watch?v=L_qaqoGXHDU)

<comment><USER4> Out of curiosity, does it track and differentiate betwen both high-bar and low-bar squats? This is a pretty cool service.

<comment><USER3> Great question! It does and it doesn't - we can guide you with either type, but that's something that you (or your personal trainer) might better be able to dial in offline.

On our site, you'll be able to see your full 3D skeleton recording and do more investigation into your form - slow mo, frame by frame, and all that detail- oriented stuff.

</comment></comment></comment></comment><comment><USER5> This looks like a cool technology that will most likely be stuck in no man's land in its current incarnation.

Selling this at scale to gyms will be very difficult. Personal training is one the largest profit centers for gyms and at many gyms, personal training is _the_ most profitable profit center. Convincing members to sign up can be difficult though (at an average gym typically less than 10% of gym members use personal training services at any given time) so gym owners are going to be skeptical about anything that might deter members from trying personal training.

If this technology is as good as the founders say it is, it will be viewed by most gyms as a problem, not a solution. A gym isn't going to pay $2,500/unit for the privilege of potentially cannibalizing its personal training revenue. On the flip side, if the technology isn't as good as the founders say it is, a gym isn't going to pay $2,500/unit to add a piece of equipment that doesn't offer any benefit.

Another poster mentioned selling to individuals for home gyms. Notwithstanding the fact that this is a non-starter at anywhere near the $2,500 price point, the market for personal fitness equipment is unfathomably competitive. Customer acquisition costs are insane and you could easily spend millions of dollars just to launch a new product.

If there's any value here, it's in the computer vision technology. The question is whether the company and whoever invests will recognize that before it's too late.

</comment><comment><USER6> _Personal training, like hair cuts, is a non-tradable service._

But, this is part of the value of personal training. You're not going to miss your work out if you lose a hundred bucks by not going.

Also, there's value in motivation as well. Having someone there to push you to get those extra one or two reps is another big part of the value add of a personal trainer.

This is really cool, and I'm looking forward to seeing how the product evolves going forward. Props to Mr. Eldeeb for his amazing journey and the beginnings of an interesting startup. Sounds like the pressures of running a company might be a cakewalk compared to the rest of his life!

<comment><USER3> Cofounder Josh Augustin here. Motivation is a huge part of what a personal trainer does, and that's why we're going to help trainers reach out to their clients with email and SMS.

For people who have never been able to afford a personal trainer, like Moawia and I, this is an awesome alternative, and we believe it can be just as motivating.

<comment><USER7> Josh, given that the Smartspot is using a Kinect, are there plans for this to become an Xbox app? The motivational "hump" for working out in your living room is much lower than going to the gym (and cheaper too).

<comment><USER3> We feel that our tech is most useful when it's helping people do high-weight exercises better, without injuring -themselves, so we're targeting gyms first, but home gyms are definitely a possibility for the future.

</comment></comment></comment></comment><comment><USER8> Love the backstory. Fitness startups are pretty interesting, and I like that Smartspot is using computer vision (because I haven't seen anyone else doing it). I would love to see a performance comparison to Athos[1], which uses embedded sensors in workout gear to detect muscle balance and engagement.

[1] [http://liveathos.com](http://liveathos.com)

</comment><comment><USER9> This is awesome. About a year ago I bought a Kinect with the intent of doing something very similar. This story makes me want to get coding again.

I was excited by Amazon phone's stereo camera as well as Google's project tango. Depth sensing technology is very exciting indeed!

</comment><comment><USER10> Great Story!! I love the founder's journey! Nothing was handed to you. You worked hard for everything you have! I can identify with that. This company would have kicked butt at SXSW because we did not see many fitness companies there this year.

</comment><comment><USER11> If you search "Smart Spot" in Google I get this article at #3 and not the actual website at all. "Smartspot" returns the actual website as the last item on the list. You should up your SEO game!

</comment><comment><USER12> As a personal rant, you can ignore the rest if you can tell this is off-topic from here. I spent a lot of time in Egypt, I have a former Egyptian spouse, and I know many Egyptians. This country has so much potential, and it is all going to waste because variations of this story, kids struggling to even find time to invest in the sub-standard education they are provided, is common.

Now, like a few other expats who studied there with me in 2006-2007, I was really upset post-revolution. As expected, people wanted to bootstrap a nation far behind. There were, like in other public sector jobs, numerous protests by education sector staff and instructors about how it was bad, and not improving. Keep in mind in the average university students are paying a few hundred gineh (Egyptian pounds) per year. As a result, even higher education is swampy messy of inadequate staff and resources like our worst inner city middle schools. And this is the top of education chain in Egypt. Of course, as expected even in the most developed nations (I was scarred and disturbed by local politics, jaded from my time over there as I saw more parallels over time), this was put on the back burner when it is crucial to improving the general state of affairs. Not that many will address that, because it is not politically expedient.

No one really focuses on the education problem in Egypt. I know some people running companies there, if you can even believe it pre and post-revolution when internet cuts were common, web development firms. Egypt invested in, for its time, top-rate broadband availability in the region. It is one of the first Arab countries to have Internet backbone as part of the higher education networks in the 90s prior to the Zaki information economy push around the millenium. When I studied at the time, with everything else faulting, the Internet infrastructure, even for average consumer use, was surprisingly not bad. They even had cool joint degrees. If I had money to spare, I would have considered one.

[http://www.africabuild.eu/consortium/iti- mcit](http://www.africabuild.eu/consortium/iti-mcit)

So there is great infrastructure and potential for the Eldeebs I know and knew, pre-revolution at least. The sad reality is that stories like this are so common in Egypt, it is crazy. No kid, even the most motivated, cannot be expected to fight for enterpreneurship when he cannot eat and must work side jobs so his whole family can survive. Education, even when kids can get access, is terrible, in spite of great telecom infrastructure that was part of a perceived information economy bump in the future.

I generally think Ahmed Zuweil, a famous Egyptian technocrat and Nobel Chemistry Prize winner, is somewhat an asshole. But he used to run ads during Ramadan on Egyptian television the last few years underlining education is THE priority to make Egypt return even to a fraction of its true greatness.

If anyone thinks Eldeeb's story is moving, please look into orgs like this and many other Egyptian NGOs invested in education. Lord knows I do.

[http://www.zewailcity.edu.eg](http://www.zewailcity.edu.eg)

<comment><USER13> AIUI, Egypt is yet another African country that fell victim to land reform. The unique wrinkle to the story is that instead of taking the land from experienced farmers and giving it to the less capable masses, Mubarak took it from experienced farmers and gave it to corporate cronies. Less socialist, still disastrous! Egypt could feed itself 8,000 years ago, it could feed itself 800 years ago, and it could feed itself 80 years ago. Now, not so much...</comment></comment>


How do companies handle tax/payment for remote workers? - <AUTHOR> Just wondering when one is working remotely and say the parent company is in United States, how does the company handle tax/payment for remote workers ? I assume payment is wired but what about tax ? Parent company does not have any branch in the country remote worker is living. <comment><USER2> I'd say that if it's regular contract, you pay the tax in the country where the company resides (+ social / health tax). Freelancing is different and the pay is taxed in the country where you reside.

</comment><comment><USER3> I imagine in many cases this would be on a freelance/contract basis and in that case it would generally be the remote worker who is responsible for paying the appropriate taxes in their country

</comment><comment><USER4> Remote workers are usually on a contract and pay their own tax in their country.

If the company wants them to be a full employee, they have to pay tax/health based on the law of where the remote workers lives.

</comment><comment><USER5> In the US, the company only has to withhold income for statutory employees. If this presents problems, then the work is usually let by contract.</comment>


Ask HN: How do I hire for jobs I'm not an expert in? - <AUTHOR> <comment><USER2> How much would you pay for a service screening the candidates' CVs and assessing their skills for you?</comment>


Do the Simplest, "Dumbest" Possible Thing that Will Work - Inspired by Flickr - <AUTHOR> http://faso.com/code618/34151/do-the-simplest-dumbest-possible-thing-that-will-work-inspired-by-flickr

<comment><USER2> KISS, or KID, in the end, what this really means is, don't try and over architect something for the right way of doing things..

I've recently made the switch from being a high paid consultant, to entrepreneur, and I'm doing the same things..I got paid to come in and fix in my past career. First, get shit to work, then worry about optimizing it. Having the best deployment framework in place, is great, only if you have customers that need deployment.

</comment><comment><USER3> Seems like this might follow along with the KISS train of thought...some of the most beautiful things in life are not that complicated.</comment>


High-severity vulnerability in vBulletin is being actively exploited - <AUTHOR> https://arstechnica.com/information-technology/2019/09/public-exploit-code-spawns-mass-attacks-against-high-severity-vbulletin-bug/ <comment><USER2> So, the affected function, in includes/vb5/frontend/controller/bbcode.php was:

        function evalCode($code) {
            ob_start();
            eval($code);
            $output = ob_get_contents();
            ob_end_clean();
            return $output;
        }

... So anyone who looks at a codebase for eval would have found this. There is no doubt in my mind that when some people have claimed that this has been around for years... That it has definitely been around for years.

And as the fix is:

        // comment out. idk what it breaks but it's a fix for now
        //eval($code);

I don't think anyone even knows what the hell that eval was doing there in the first place.

<comment><USER3> Oh yes brings back memories from when I worked on vBulletin customizations over a decade ago. No doubt it is a remnant of the early plugin features but also the hacks one had to employ with PHP before namespaces and a proper OOP structure was introduced. Eval in PHP was the go-to for sorting out versioning mishaps and adding a layer of abstraction when one didn't exist. It was the Swiss Army knife of making difficult problems disappear so it makes sense to me that they had a specific method for this. Between versions 4 & 5 of PHP depending on whatever VHost was chosen eval was necessary sometimes just to start migrating over to version 5 because you could if...then...rewrite your eval("new code").

</comment></comment><comment><USER4> I find it so weird that they call this a commenting system. It is a forum or message board. Last thing I would call it is a commenting system. Never heard anybody calling vBulletin a commenting system.

<comment><USER5> When I last used it (years ago) there was a neat plugin that'd let you use it as a commenting system for a WordPress blog. Every blog post would get a new thread in a particular forum, and people could comment in both places.

<comment><USER6> I remember using or seeing something very similar for phpBB (a free software bulletin board web app). I think that kind of functionality existed for most extensible boards.

</comment></comment></comment><comment><USER7> No offense intended, but I really don't know how it's possible to write a forum with so many vulnerabilities. Forums aren't exactly rocket science. It's basic input validation and you're good to go. Many recent functions (in PHP) already sanitize input even if you forget. So things like parametrized SQL queries and browser same origin policies really help limit the attack surface.

I find it depressing that vBulletin has been getting hacked for so long that it's literally outlived several of the major vulnerability disclosure websites that have historically published exploits about it (like milw0rm -- still an amazing theme, btw.) Maybe PHP should throw warnings about eval and recommend an alternative function purely for expressions instead. In Python apparently eval evaluates expressions for a result and exec would do what PHP's eval would do instead. Something like that for PHP would be better than nothing.

<comment><USER8> Every piece of software is simple and easy when someone else has to write it.

Unnamed Goose Game? It's just a bunch of polygons and MIDI riffs. No big whoop.

Slack? It's just a chat agent. Just some input validation and syndication. Easy peasy.

Microsoft Windows? It's just a window manager running on DOS. No sweat, I could whip that up over the weekend.

</comment></comment><comment><USER9> I spun up a trial instance just for fun, and indeed, it's as easy and fool- proof as it sounds. This is something where some one can run some google dorks for the right forum and throw results into a twenty-line script.

Interestingly enough, it appeared as though google somehow sanitized the dork proposed in the actual post to return few to no forums, at least when I checked this morning. Checking now from a different IP returns a lot more; very weird.

The actual post to seclists for reference: [https://seclists.org/fulldisclosure/2019/Sep/31](https://seclists.org/fulldisclosure/2019/Sep/31)

Also, why on God's green earth to devs put version numbers so obviously in the software? For instance, on my web servers, I always turn off version number and platform, so an attacker can't easily go hunt down vulns from scraping the web. It seems as though it would be wise to make no version numbers that easily accessible the default.

<comment><USER10> You are advocating for security by obscurity. Which is a "deterrent" not a solution.

Version numbers help people get support and know when/where versions are fixed and if they are patched/updated.

A solution is running up to date software, and encouraging developers to release security fixes and for admins to care.

<comment><USER2> Version numbers can still be handed to people without having to appear in every single request.

It is a deterrent, and not a solution. But it does prevent the clouds of botnets from labeling you as definitely vulnerable and attacking you the moment a new 0-day gets purchased. The speed of attacks can outpace your speed of your upgrade process.

Security-in-depth should always be the way forward. This is just another tickbox you can use.

<comment><USER11> I agree, it's more like a "sane default".

</comment></comment></comment></comment><comment><USER12> > "Zerodium customers were aware of it since 3 years."

This is why we can't have nice things. Zerodium, thanks for being honest, but services such as yours are actively making the internet a worse place.

<comment><USER13> As someone that has sold exploit code to various brokers in the past, I don't think Zerodium are making the internet a worse place. I forget the exact year but it was around 2004 - 2006 one of my friends reported a vuln to phpbb, they openly mocked her and downplayed the issue with no fix. She put together a professional looking report on how it works and submitted it privately to the product team, she was then ignored and banned from their IRC. She then published the exploit publicly and they sued her, they forced her ISP to take punitive action and they contacted her college to try and get her suspended.

Fuck reporting vulns, fuck open disclosure. Just sell what you find to brokers.

Cahouki Bekrar says there are three options:

1\. Full disclosure so anyone/Govs can (ab)use it without limits/regulation

2\. Sell to Govs/brokers and get a decent revenue while limiting (ab)use

3\. Report to vendors & get sued, or get shitty bounties and/or your name in advisories

I agree with him.

<comment><USER14> > She then published the exploit publicly and they sued her

So you're saying that a bunch of volunteer open source developers collectively sued a security researcher? That sounds like it would have made for an epic Hacker News story. Do you have any documentation that this happened?

<comment><USER13> Look up 'santy worm' and the now defunct "howdark.com". It never ended up in court, it went as far as lawyers letters until they backed doen. It wasn't phpbb that sent the lawyers letters, it was a business owner that used phpbb that was hit by the santy worm. The lawsuit would have likely gone nowhere but she still had to spend cash on her own lawyers, she was 19 at the time and did nothing more than a standard vuln disclosure to the community. This isn't even an extreme case, there's much worse.

</comment></comment></comment></comment><comment><USER12> On an unrelated note, does anyone else get the feeling that the vBulletin website looks similar to what a Microsoft Support scammer might refer you to in order to download Remote Desktop software?

[https://www.vbulletin.com/](https://www.vbulletin.com/)

<comment><USER15> It all went to shit after the Internet Brands buyout.

They used to just dogfood their own software as their homepage: [https://web.archive.org/web/20070205162247/http://www.vbulle...](https://web.archive.org/web/20070205162247/http://www.vbulletin.com/)

</comment></comment><comment><USER16> Any recommendations for forum software, preferably open source?

I'm aware of Discourse and Flarum, which use more modern designs:

[https://www.discourse.org](https://www.discourse.org)

[https://flarum.org](https://flarum.org)

phpBB and Simple Machines Forum both use classic designs similar to vBulletin:

[https://www.phpbb.com](https://www.phpbb.com)

[https://simplemachines.org](https://simplemachines.org)

What's the best alternative to vBulletin?

<comment><USER17> Maybe Talkyard could be of interest — a bit like Discourse, but has HackerNews type threaded discussions and a basic Slack like chat: [https://www.talkyard.io](https://www.talkyard.io) (I'm developing it).

There are some improvements over HN: [https://www.talkyard.io/-32/how-hacker- news-can-be-improved-...](https://www.talkyard.io/-32/how-hacker-news-can-be- improved-3-things)

</comment></comment><comment><USER18> Honest question: is there any coordinated responder effort to use RCE vulns like this one to patch the vuln and secure affected systems? Not asking just about this exploit in particular but about the entire world of 0day Internet RCE.

<comment><USER19> There exist 'Anti-worms' like Anii-Santy and Welchia [1] which patch vulnerable hosts. And I've heard of malicious viruses that patch their host simply to ensure they have that host to themselves.

However, this is unambiguously illegal under anti-hacking laws like CFAA [2] which introduces a variety of practical difficulties.

[1] [https://en.wikipedia.org/wiki/Anti- worm](https://en.wikipedia.org/wiki/Anti-worm) [2] [https://en.wikipedia.org/wiki/Computer_Fraud_and_Abuse_Act](https://en.wikipedia.org/wiki/Computer_Fraud_and_Abuse_Act)

<comment><USER18> Thanks. I wonder if doing it under the control of a team like CERT could make it less illegal. Or, if there was a way for a company to publicly pre- authorize a non-prosecution agreement for 0day patch defense. Surprised I haven't seen more discussion about the idea.

</comment></comment></comment><comment><USER20> It would be easy to use the exploit to patch unpatched sites, rogue whitehat style...

</comment><comment><USER21> What does the string "2dmfrb28nu3c6s9j" represent?

</comment><comment><USER22> Man why would anyone install code like that.

It's script you can just read it guys, everyone fights so hard for open source and no one bothers reading anything.

<comment><USER23> I once took over a Wordpress site and the prior dev told me that he just torrented the plugins.

It took me all of 15 minutes to find code injections appended to the bottom of the code files.

...but that wasn't the interesting part. Since it was a very popular SEO plugin, I actually took the extra time and reported the attack code wordpress security scanners and the torrent site.

A month later I checked back and the plugin had been re-uploaded, but this time with the attack code heavily obfuscated and much more subtely hidden within the plugin.

...and this time when I reported it to the torrent site, the site admins banned me and actually IP blocked me.

tldr; The only open source code getting reviewed is heavily used stuff.

<comment><USER24> WordPress has commercial closed-source plug-ins available and one of the more popular ones happen to be a certain SEO-plug-in. You're certain it wasn't a pirated copy of a closed-source plugin?

Pirated closed-source themes and plug-ins for WordPress is a very common source of malware on WP sites.

<comment><USER25> I think that's implied by the use of torrents. Bittorrent is not commonly used as the official distribution channel by professional wordpress plugin authors, I believe.

</comment></comment></comment></comment><comment><USER26> PHP is a public remote shell. Why is this in the news?

<comment><USER27> Ok thanks for your contribution.

Now where is my facebook dot com shell?

<comment><USER28> Facebook hasn't been running stock PHP for years. They wrote their own compiler

<comment><AUTHOR> Its still PHP...</comment></comment></comment></comment>


Best Insights on Finding a Technical CoFounder - <AUTHOR> http://www.searchtrack.co/viewproject/330/finding-a-technical-co-founder <comment><AUTHOR> Since this seems like a question that many founders go through while building their business, I compiled a list of best links (that i could find) for understanding the aspects of finding a technical cofounder.

Hope it helps the community! Do share any other interesting links that you feel might be added to the list.</comment>


Octopus' sophistication driven by hundreds of previously unknown genes - <AUTHOR> http://arstechnica.com/science/2015/08/octopus-sophistication-driven-by-hundreds-of-previously-unknown-genes/ <comment><USER2> I really hope cephalopods survive what we're doing to the oceans. Not to mention farming them for food. The biosphere is a treasure and losing these species would be a loss inexpressible in dollars.

</comment><comment><USER3> In case you missed it, this out-of-the-water predatory behavior of an octopus is astounding to us mid-west folks:

[https://www.youtube.com/watch?v=F5fZu-1bt6Y](https://www.youtube.com/watch?v=F5fZu-1bt6Y)

</comment><comment><USER4> If they were really interested in discovering unknown genes, they should have used PacBio to sequence the whole genome instead of just 83% of it via Illumina. That assembly quality ("a contig N50-length of 5.4 kb and a scaffold N50-length of 470 kb") is truly awful compared to a PacBio assembly.

<comment><USER5> And also about a magnitude more expensive

<comment><USER4> Not any more, and especially not compared to the HiSeq 2000 used for that paper. PacBio's raw sequencing cost is now about on par with where the HiSeq was when it first launched. And because of the error profile you don't need as much coverage and it's a lot less effort to assemble. So the total project cost now is comparable, even if the raw sequencing cost is higher still.

</comment></comment></comment><comment><USER6> I have a question: Can genetic information be zipped ? As in a library of words, that restores condensed information to its full density?

<comment><USER7> Huh, interesting.

To look at that from the other direction... what are the implications if DNA is already optimally compressed?

TBH I'd be surprised if DNA were optimised for size rather than ease of access, but admit that I know next-to-nothing about it.</comment></comment>


Surprise: Most Top Donors Lean Strongly Democrat - <AUTHOR> http://www.opensecrets.org/orgs/list.php?order=A

<comment><USER2> No surprises here. Unions give to democrats who support them after getting elected, its a vicious cycle. And many of them are government unions using tax payer money, go figure. Big corporations always stay on the fence as they do not want to be on one side if the other side gets the reign.

</comment><comment><USER3> All that chart shows is that unions give more to Democrats, which is not surprising. But there is no way that I'm going to believe that unions give orders of magnitude more money than corporations. I'm not a campaign finance expert but what I would guess that this is showing that there is some loophole in transparency laws that is being exploited by corps, or that this chart isn't capturing some important source of money.

<comment><USER4> I get your skepticism, but are your really going to give more weight to the theoretical omitted data in your mind just to quell your own cognitive dissonance?

<comment><USER3> There are different ways money are pooled and complicated reporting requirements. If you think Republicans are just peachy than you are an idiot.</comment></comment></comment>


Alpine (Linux): User Handbook - <AUTHOR> https://beta.docs.alpinelinux.org/user-handbook/0.1a/index.html <comment><USER2> A genuine question - other than containers, does Alpine have a use? Do some people generally run Alpine as their distro of choice?</comment>


Severe vulnerabilities discovered in HTTP/2 protocol - <AUTHOR> http://www.zdnet.com/article/severe-vulnerabilities-discovered-in-http2-protocol/ <comment><AUTHOR> Full report (PDF): [http://www.imperva.com/docs/Imperva_HII_HTTP2.pdf](http://www.imperva.com/docs/Imperva_HII_HTTP2.pdf)

4 attack vectors were found, but not all web servers were vulnerable to them.</comment>


Rethinking the Airplane, for Climate's Sake - <AUTHOR> http://www.nytimes.com/2016/01/12/science/rethinking-the-airplane-for-climates-sake.html <comment><USER2> We wouldn't have to rethink the airplane at all if business travelers would just do digital meetings instead of in-person, on-site meetings.

I still know accountants who travel across the country every week so that they can have physical access to documents that should be digitized.

One of my neighbors recently flew from the US to Greece for a 4-hour meeting with a client.

The way businesses rely on air travel is outdated by at least 10 years.</comment>


Amazon Prime Pantry - <AUTHOR> http://www.amazon.com/gp/pantry/info/ref=pntry_wayfind_lm

<comment><USER2> Bottom line, with shipping a 12 pack of Cokes comes out to be around $5.50 (i.e. cost of 1/4 of a box in shipping)

Given that a typical deal on Coke in my area is around $4, that's prohibitively expensive. Too bad, I was looking forward to this service.

<comment><USER3> Water is VERY heavy to ship per value compared to using local water. Soda stream + 5:1 syrup a la [http://www.amazon.com/Dr-Pepper- Syrup-1-gallon/dp/B0086CXRC2](http://www.amazon.com/Dr-Pepper- Syrup-1-gallon/dp/B0086CXRC2) will do the cola very well and last months.</comment></comment>


To Dissect a Mockingbird: A Graphical Notation for the Lambda Calculus (1996) - <AUTHOR> http://dkeenan.com/Lambda/ <comment><USER3> I have this naive intuition that graphs are a universal encoding scheme, all theorems of category theory can be expressed as graphs, with the implication there is a massive unifying leap forward in maths that will result from expressing existing problems in terms that are consistent with such a representation. Maybe it's literary sci fi handwaving, but there must be a rules based level of abstraction that contains all we can conceive of and express. These diagrams appear to be an example of it.

<comment><USER4> > I have this naive intuition that graphs are a universal encoding scheme

I have thought of the same thing in the domain of neural nets. You want to understand an image? Build a graph of the objects and their relations. You want to understand a text? Turn it into a graph. Need to simulate the environment? You can represent it as a graph. Want to mine a huge database of common facts? Represent it as a graph (database of triplets subject-relation- object). Even the execution of a program could be better conceptualised as a graph.

Graphs seem like an universal format. Graph Neural Nets have been a blooming subfield lately, ever since Thomas Kipf's paper [1] which in three years has accumulated over 2300 citations.

The main difference between classical neural nets and GNNs is that GNNs have permutation invariance. You can rename the nodes of the graph and still have the same graph.

Previously neural nets only had translation invariance (CNN) and time invariance (RNNs). Graphs would solve the combinatorial explosion by virtue of their permutation invariance - a problem which limits previous models of neural nets. Instead of learning all possible combinations of input objects you learn the pairwise relations, then you can generalise those relations to new configurations.

On a side note, the insanely popular transformer architecture (based on soft attention) is a kind of implicit graph, where the connectivity is evaluated based on the dot product similarity of the key and query objects.

[1] [https://scholar.google.ro/scholar?hl=en&as_sdt=0%2C5&q=kipf+...](https://scholar.google.ro/scholar?hl=en&as_sdt=0%2C5&q=kipf+Semi- supervised+classification+with+graph+convolutional+networks&btnG=)

<comment><USER5> I'm definitely coming around to graph first systems like Fulcro and Datomic, with Datahike being a great Datomic introduction

</comment></comment></comment><comment><USER6> Is there are relationship between the lambda calculus and Brainfuck and other few instruction set languages?

Edit: well, an easy find, [https://esolangs.org/wiki/Lambda_Calculus_to_Brainfuck](https://esolangs.org/wiki/Lambda_Calculus_to_Brainfuck)

<comment><USER7> there's an isomorphism, because bf is np complete, as is simply typed lc.

simply speaking, bf can implement lc, and vice versa, which would proof the claim.

Edit: the ugly bit is that IO is always an ugly hack and potentially makes the program indetermined and thus impossible to proof a priory. but one can probably prove that they are equivalently unprovable.

<comment><USER8> > because bf is np complete, as is simply typed lc.

Do you mean turing complete?

</comment></comment></comment><comment><USER9> Another approach for visualizing lambda calculus is presented in [https://ycombinator.chibicode.com/functional-programming- emo...](https://ycombinator.chibicode.com/functional-programming-emojis) .

It looks quite different and I wonder which one is better? Or are they the same really?

<comment><USER10> Yet another is my Lambda Diagrams [1], an obsolete link for which appears at the bottom of the article.

[1] [https://tromp.github.io/cl/diagrams.htm](https://tromp.github.io/cl/diagrams.htm)

</comment></comment><comment><USER11> A js lambda to graphs parser and reducer [https://mbuliga.github.io/quinegraphs/lambda2mol.html](https://mbuliga.github.io/quinegraphs/lambda2mol.html)

</comment><comment><USER12> Oh wow, a reference to Laws of Form (George Spencer-Brown), takes me back!

<comment><USER13> Definitely an underrated piece of work.

<comment><USER14> "The Markable Mark" site is a great exposition of the Laws of Form: [http://www.markability.net/](http://www.markability.net/)

<comment><USER13> I think I benefited less from the letter of the Law, than through the spirit of it. My first exposure was very indirect coming from a decision analysis textbook, that motivated the construction of decision trees from something like the benefits of making distinctions, which were well-defined. (From that representation it becomes simple to analyze what conditional probabilities are relevant to your decision-making context.)

They cited GSB through Francisco Varela who proposed that making distinctions was the fundamental operation of all cognitive thought. I found the idea compelling (if we know the roots of thinking, could that give us the levers to improve it?) but found Varela to be near-impenetrable.

So I picked up GSB in hopes that this thin tome could shed some light on the manner.

My god. You start seeing distinctions then you start seeing them everywhere. You understand what computational types are and why the adjunctions are ubquitous – and important. You get a sense of why psychological time must exist. You get why information always requires there to be an observer, and how the combination of all perspectives will necessarily be empty - <USER2> limitations to comprehension form the richness of our universe. You see the freedom we have in letting some things be distinguished over others and why people get confused about whether mathematics is discovered or invented. Surely it is neither, or both: we let something be to find out what it is.

And the fact that you can draw a knot-theorist, a biologist, a decision theorist, and a Taoist out from the conceptual framework is a testament to how rich it is.

Still, eventually I'm going to have to learn how to calculate with it.

</comment></comment></comment></comment><comment><USER15> Link has been updated

<comment><USER16> Whoops - changed from [http://www.cs.virginia.edu/~evans/cs655-S00/readings/mocking...](http://www.cs.virginia.edu/~evans/cs655-S00/readings/mockingbird.html).

This was an invited repost of [https://news.ycombinator.com/item?id=890715](https://news.ycombinator.com/item?id=890715) and I forgot to update the link from long ago.

See [https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...](https://hn.algolia.com/?dateRange=all&page=0&prefix=true&query=by%3Adang%20repost%20invit&sort=byDate&type=comment) for more about invited reposts. There is a list of them at [https://news.ycombinator.com/invited](https://news.ycombinator.com/invited).</comment></comment>


Show HN: Sample for Apple's Vision and CoreML Frameworks - <AUTHOR> https://github.com/cgreening/VisionCoreMLSample <comment><AUTHOR> Put a slightly better video up on youtube - [https://www.youtube.com/watch?v=S33BNcnlxdU](https://www.youtube.com/watch?v=S33BNcnlxdU)

The demo is using the ResNet50 model. Everything is running locally on the phone. Phone does get quite hot!</comment>


Netbooks are dead. Long live the notebook - <AUTHOR> http://blogs.techrepublic.com.com/hiner/?p=3348

<comment><USER2> Clearly Microsoft sponsored FUD. I can't even open my wide-screen laptop in an economy-class airline seat, and if I could it would be dead in 2 hours anyway. I love my Eee PC 1000HE for traveling. It is easy to carry, and it gives me a Ubuntu desktop that lasts longer than I can on trips from California to Beijing.</comment>


Student loan debt causes a chain reaction in the housing market - <AUTHOR> http://www.bostonglobe.com/lifestyle/real-estate/2016/09/30/student-loan-debt-causes-chain-reaction-housing-market/p6DGy4f2px9vadMJnKr39O/story.html <comment><USER2> Increased student loans decreases demand for houses.

Okay...but doesn't this affect demand in general...cars, boats, houses, cruise tickets, etc.?

<comment><USER3> Yes, but the health of those markets isn't as central to the health of the economy as the health of the housing market is (maybe cars are, though to a much lesser extent). And to be clear, it's incredibly fucked up that the inability of debt-laden millennials to take on _more_ debt in the form of 30-year mortgages is a threat to the economy, but it is, and policy proposals addressing that fact need to start being made.

<comment><USER2> > central to the health of the economy

I've heard this so often. Usually, in the context of some BS excuse to keep prices always rising.

All praise real estate prices, the engine beyond true economic growth in the USA.</comment></comment></comment>