Hacker Newsnew | past | comments | ask | show | jobs | submit | shorbaji's commentslogin

I wonder what fraction of the hardware goes into hosting the human operator and into ensuring their safety. How much hardware cam be optimized away when there is no longer a human operator?


Very little. All the reduction gears, tires, and hydraulics are the same.

Basically you can get rid of the air conditioner and the seat. Most of the hazards related to heavy equipment involve hitting something outside the machine.

Rolling is the major hazard to an operator and you still want to avoid that without one.


With the construction equipment market at $160B, this certainly is quite a sizable niche. Specializing in it is clever.

And an $80M round sounds sane these days


> With the construction equipment market at $160B

Wouldn't the value of their target market be the pay of operators (~$30/hour)?


At first, yes. Longer term, self-driving construction vehicles will likely change the entire market - perhaps similar to how self-driving passenger cars would change that market. Vehicles will be designed differently and consumption-based business models would potentially make up a larger part of the market. Investors are probably see that opportunity.


> If you use WebSockets for "realtime push", then HTTP/2's server push feature could potentially be used as an alternative.

One thing to keep in mind with HTTP/2 server push is that a server can only send a push in response to a client request. So this isn't a drop-in "real-time push" mechanism. To implement the equivalent of real-time push would likely require client/server to keep a stream within the connection in the "open" state whereby the server can send continue to send data frames on that.


    One thing to keep in mind with HTTP/2 server push is that a server can only
    send a push in response to a client request.
This was the difference that I was not aware of, thanks. So HTTP/2 server push is just opportunistic, while WebSockets are real-time push with a persistent connection.


It certainly is a good idea.

Don't mean to hijack the thread, but I've been toying with the idea of having users use a data flow diagram to structure complex spreadsheets. Still have a pre-prototype stage and I'ld love to get your expert feedback on that idea. If interested please drop me a note.


Interesting. As I understand it, you use a spreadsheet as input and then create the data flow diagram. I certainly see how seeing the data flow diagram means better clarity and error-finding. So here is a question for you? What if we take it a step further and have users actually entered their complex spreadsheets in a tidy graphical data flow diagram which mapped back?


The problem is users like the presentation of a spreadsheet. So far, there seems to have been no evidence of this changing.

My question is why do they like it? My assertion would be because it is visual in how they want it. They are usually less interested in the complicated "how do I get this value" than they are "I want a value to be here." That is, even if it is wrong, they are more interested in seeing the data laid out in a way they specify than they are coming up with a data flow analysis of what they did.

And, really, I'm not sure this is that surprising. Having a tool show you how all of the data is linked together certainly can make for a good understanding of how the data was calculated. May even help fix mistakes. However, the table of data view of the spreadsheet is ultimately what you want. Just with no mistakes.


That is where I would love to take this. I think thats a bit more of a leap for the user as it forces them to think in the flow diagram way from the very beginning. I'd really like to see how users react to building a spreadsheet from scratch in this way.


Like Livesheets, you mean?


Yep. Livesheets more or less.


Thanks PG. Please do.


Ok, I unsubmitted it. If you change your mind just go to /apply and resubmit before the deadline.


True. As a broker of sorts, it is essential that AirBnB withhold details of the two parties. But the company need not hide that they do so. The certainly would not be ashamed if news broke out that they do so.

The transparency I speak about is slightly different. AirBnB where (I think) caught out when news broke of a landlord's home was vandalized. The company was heavily criticized for an arguably insufficiently transparent initial response.

Eventually, AirBnB were transparent in the sense that they acknowledged mistakes and acknowledged inherent risks to landlords. They used that transparency to improve the offering and promote the product accordingly. Kudos to Chesky and team!

At the risk of repeating myself, I see a parallel with Heroku's status dashboard. In a sense they are saying: "We won't mislead you. Hosting with us carries risk of downtime. Here is a dashboard so you see how well (or bad) we are doing." That too is an example of transparency leading to an improved service offering.

Heroku seem to have done it proactively. AirBnB did so reactively. Better late, of course, than never.


The debate of more vs. less transparency is not trivial. Regulatory and competitive considerations make this difficult. Sometimes it is simply human nature to be secretive - particularly when it comes to bad news.

The article focuses on transparency between management and employees. Transparency with customers and with the public is at least equally interesting.

A company can benefit from transparency. Heroku, for example, are transparent with their downtime (e.g. status.heroku.com). Another example is the case of AirBnB and the EJ debacle. Once AirBnB openly acknowledged that safety/security is a concern for landlords it adapted by rolling out an improved product (guarantees, safety features, etc).

Both of these are great examples of transparency at the core impacting the product and how it is marketed. These products are more valuable and more competitive because of transparency. Certainly this adds to revenues and likely the bottom line as well.

AirBnB could have adopted this approach earlier. So, the lack of transparency can be missed opportunity.


I am not involved with Stypi but I think the key points from the article are "it wants to let native applications like Photoshop sync changes between multiple users" and that "they’ve laid the groundwork to let other applications sync".

In other words a text editor is one instance of an application that can use the underlying service. Think about that for a second. The concept of collaborative editing as a service that can be adapted to ANY application is HUGE. For example, an engineering CAD app would be more powerful with this feature.

Going further,if you consider that machines can also "collaborate" then it get's even more interesting. An example of human/machine collaboration could be a real-time reporting application.


Congrats on the launch Stypi team. Just curious about the underlying tech. Are you using operational transformation (OT) like google docs does OR are you using an alternative such as causal trees (CT)?


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: