Ask HN: What will self driving cars do to real estate? - <AUTHOR> It seems inevitable that self driving cars are coming. When they do, they will change housing dynamics in a fundamental way.
Will this change make city living more or less desirable?
A few forces could be at work here:
* Parking lots in major cities are free'd up because they no longer make sense creating more housing real estate. City living is more affordable.
* Traffic Congestion is reduced so commutes are shorter creating more demand for suburb living.
* Distances feel shorter because they are no longer inconvenient so living outside the city makes more sense - more suburb demand.
* City living gets even more desirable because of the abundance of cheap self-driving cabs not available in more rural areas - city prices go up.
* More?
I'm sure some of these things will have a very little impact while others will have huge impact. I just wonder about the net result. Any speculation? <comment><USER2> I see two opposing forces:

Self driving cars could encourage sprawl by making commuting long distances more practical. If you could be working during your commute instead of driving, and didn't need to find parking once you arrive, a 2-hour commute could become practical. That would intensify the "car culture" that currently drives municipal planning, but would reduce the harmful effects. As you mention, less space wasted on parking, less congestion etc.

On the other hand, driverless cars will be a big boost for Uber, Lyft, Zipcar, GetAround and the like. That could make city living more desirable, because car-on-demand only works well when there are lots of available cars nearby. Folks that live out in the boonies would still have to own their own cars, and so wouldn't benefit as much from the technology as city-dwellers. Also, spending less space on parking has a bigger effect in the city where space is already tight, so we might see even higher density in the inner city.

<comment><USER3> I think that's about right. To your "on the other hand" though, I'm inclined to think that where density is already high, robo-driving doesn't change the equation of car + $10-20/hr driver all that much. (Especially given that some of those costs--cleaning, etc.--have to be shifted to a non-driver.) Therefore, I expect easier driving = more driving (which is more or less basic economics.)

<comment><USER4> Some no frills car sharing companies make their users clean the car. And if you get a dirty car you can order a new one and the previous driver gets billed. And small one person Robo cars could also be build much simpler and cheaper.

<comment><USER5> Correct, you'll be rating the previous passenger in your Uber's once we have self driving vehicles. Same mechanics will apply.

<comment><USER6> There could well be discriminatory billing - clean conscientious passengers pay less than drunk party goers.

</comment></comment></comment></comment></comment><comment><USER7> While lot of people are thinking about how the self driving cars will effect commute specially to work. We really don't know how the workplace is going to change. I think the conventional workplace is ripe for change. Will there will be more need to commute to work as opposed to more remote working with say virtual workplace with better virtual reality. Obviously some of the jobs can't be done unless you are physically present, but I am would like to think these jobs will get lesser and lesser. If I have to go to workplace lesser, I as well might leave far off from workplace. Also with self-driving cars will be lot as stressful as driving. I would assume self-driving cars will give us the chance to work farther from workplace. And less dependent on near to prime location.

<comment><USER8> Programmers are the prime example for a job that can be done remotely, and yet there are tons of articles about the problems it causes. The problem of staying in contact with your workplace hardly can be solved with virtual reality.

<comment><USER9> Remote work can only function if the teams have both the communications tooling to support it and the team and organisational culture aspects to keep it up. I find most fail at the latter, because they don't know how to be sufficient enough in communication with the tools they have. Talking to face the face has much more communication bandwidth than anything else out there.

<comment><USER10> Personally I would have expected to see a 4 or 5 times imporvement n productivity from not being in an office where I was interupted maybe once an hour on average. Saying that a more competent manager could have probably elimiated a lot of that (instead he caused way more interuptions).

<comment><USER11> Study after study says otherwise. For various reasons, small teams working in a huddle together for short sprints is the most effective way to organize a development team.

<comment><USER10> I was a team of one constantly getting pestered by end users who were to stupid to fill out an excel sheet properly. Or incompetent managers who were completely unorganized.

</comment></comment></comment></comment></comment></comment><comment><USER12> Why would self-driving cars reduce traffic congestion? If my car drove itself, I'd be less incentivized to use public transportation. I'd probably be willing to put up with a slightly longer door-to-door time than if I used public transportation because it would be more convenient: I'd rather surf the web in my own car than have to pay attention to stops, schedules, transfers, etc. Congestion would probably be different: it would be less stop-and-go and more uniformly slow speeds.

<comment><USER13> Because they could be better drivers. For example a "perfect" driver communicating with one in front of him could, eventually, tailgate with an inch at much higher speeds. If we approximate (for arguments sake) traffic as a fluid, by bernoulli's principal there will be more capacity for a given lane.

Said in another way, if the car can get there quickly it'll be off the streets sooner and another one will take its spot.

Also a "perfect" driver wouldn't make the stupid mistakes ppl do all the time, the most annoying one staring at gory accidents. And even accidents wouldn't occur as often.

But this all assumes that the AI gets even more sophisticated.

<comment><USER14> You're covering the available efficiencies in the use of existing road network capacity, and assuming that demand is static.

In fact, I think that if car ownership is cheaper, journeys can be made by anybody, and the experience is less stressful, many more people will travel by car.

I wouldn't be at all surprised if autonomous cars produce even worse congestion than today.

<comment><USER13> Well that's the theory. What ends up happening is always up in the air.

I did read somewhere that the average "commute" has stayed constant throughout history - about 45 min - be it walking, omnibus, trolley or car. So you're probably right, things will shift to fill up the free time

</comment></comment></comment></comment><comment><USER15> Well, here is something that recently occurred to me:

I'm a member of a typical 2 car suburban family. I work and my wife is a stay- at-home mom. Truthfully, I only need a car to get myself to and from work, while my wife needs a car for ferrying kids to and from school (and activities), shopping, errands, etc. Thus, we need two cars.

My car spends most of its day sitting in the parking lot at my office building, unneeded. However, if I can drive myself to work and then order my car to drive itself home for my wife to use (who would hopefully send the car to come and fetch me at the end of the workday), we could easily become a one car family. Which would be nice. Of course, I live about a half an hour from my workplace -- this might not work as well with a 2 hour commute.

<comment><USER16> If you own or hire SDCs, does your wife still ferry the kids around? Or do they ride alone to the destinations you've approved in the car's parental controls?

I expect the "Soccer Mom" occupation to disappear.

<comment><USER15> Well, with older children I might allow this. Young kids would need to be accompanied by a responsible human. Robots haven't earned that level of trust yet.

In any case, these technologies won't come along in time to help my current situation. I do hope SDCs become generally available in time to prevent an elderly jcadam from plowing into a farmer's market sometime in the 2050s/2060s. Hey, I guess 'senior mobility' would be another good application of SDCs.

</comment></comment></comment><comment><USER17> From my perspective, the annoying thing about either driving or using public transport is it feels like wasted time. Sure, you can listen to some Great Courses while you're on a long drive, but apart from that you're trying carefully not to get in a crash. If you're on a subway or bus there's barely any space, so most kinds of work are out of the question. So the self-driving car will be a massive improvement because it frees up your time.

Net, everyone gains an hour or two each day.

Assuming the SDC is reasonably cheap to run:

\- The school run changes significantly. You don't need to live quite so near school any more. Yes, there is such a thing as the school bus, but that ties everyone to the same schedule and some parents are not comfortable with sending smaller kids on it. Depends a lot on the culture where this SDC lands. (Where I live, kids walk themselves to school. I lived in places where you sent kids on public transport, too. Or a school bus.) In any case, it means you don't have to be with the kid as they go to school. And they can do whatever after school activity they like, it doesn't need coordination with public transport.

\- You can get drunk anywhere, not just where there are cabs/trains/buses nearby. You can keep partying until you literally faint in your car.

\- You can live quite far away from work. An SDC with a bed could be a comfy commute. You can get things done while commuting. Heck, someone will build a house where the bedroom moves (or just park in your garage, but someone will build it in). Brush your teeth, get into your car, wake up where you need to be.

\- You don't even need a fixed address if your SDC is a camper van. Combine it with a remote job and you are on a constant tour. I reckon someone will do this reasonably soon and show us.

\- Think of all the things that are limited by having to go home afterwards (clubbing), or are normally quite remote (eg race tracks). They can all be made more attractive if nobody feels they're wasting time getting to them. It's possible there will be extra rush hours during each day.

</comment><comment><USER18> * For some families, it's no longer necessary to have two cars -- the car can drive itself back home for the other person(s) to use during the day. Or neighbors could even share cars.

* Centralized parking at the neighborhood level for cars to be out of sight and charging while not needed. Services could be built off of this concept to handle cleaning, maintenance, etc.

* Reduction in need for street parking in busy areas. Cars can drive themselves away to "orbit" or be parked while the owner is shopping/eating/etc. This allows for alternate uses for the space ... bike lanes, or just better pedestrian zones.

* Smaller lot sizes are possible for homes if driveways and large garages are not needed/downsized. Smaller parking lots for apartment/condos are also possible. This makes denser real estate developments possible, especially in suburban areas.

</comment><comment><USER19> I would think real estate will become more spread out.

Personally, I wouldn't mind a 1.5 hour commute each way if I could code the whole time rather than drive, and if my car was electric.

<comment><USER20> If you ever choose to start a family, this number might not be as appealing. Just speaking from experience.

<comment><USER19> Paying a million dollars for a house in SF isn't an appealing number either, compared to $350k in Santa Rosa.

<comment><USER21> That 350k might go up once we have self driving cars.

<comment><USER19> That was my original point.

</comment></comment></comment></comment></comment><comment><USER22> This may derail the discussion but it's hard to discuss this question without first wondering the impact of self-driving cars to _mass transit_. At least in New York, being near a subway stop is a very nice amenity and commercial development typically flourishes around each stop regardless of neighborhood. If stepping into a self-driving car is as easy as walking 50 feet to the nearest subway stop, will real estate around subways command less of a premium?

I guess the bigger question is, will subways have as much demand once self- driving cars become big? Obviously, no, if the cost for hailing a self-driving car becomes almost as inexpensive as a subway. But there are things the city of New York could do to impact that, such as reduce street capacity (i.e. increasing pedestrian and bike capacity).

But that's just New York. Everywhere else in the U.S. where mass transit is not a daily option, automated cars will be a daily habit. Inevitably, as more and more people migrate to New York and expect automated cars to be the default option, it's hard to imagine subways (and buses) winning out, absent some major limitation in self-driving car production or capability.

New York will always be an anomaly...but yes, I'd have to agree with your speculation that suburban living would become much more attractive without having to worry about car ownership or driving. And this would most definitely impact commuters to New York. But if self-driving cars become a ubiquitous option, will there be the political appetite to continue subsidizing mass transit rail, such as the kind that is currently used to bring in upstate workers to the city today?

<comment><USER23> A royal commission did a study on "Traffic in Towns" in 1963 and concluded it would be impossible to serve a city with London-like size and density with cars even if you put the buildings up on stilts and built multiple levels of roads an highways -- the problem is that you can't support a high enough level of traffic on highway offramps.

New York City is pretty close to the maximum limit of car capacity it can support. For one thing there are only so many cars that can travel on so many lanes through bridges and tunnels. If you tried to add more lanes, you'd have the same kind of problems connecting those to surface streets that you get in the "Jetsons in London" scenario.

Robert Moses did have some plans for urban removal on the southern side of midtown to accomodate more traffic (and destroy traffic demand) but it didn't happen.

(Note the response to the car in most American cities was urban removal -- you can often find a big empty space in a second or third tier city that has a 'civic center' plopped down on it.)

Manhattan looks pretty much the same today with all the cabs that it would look like with self-driving cars.

<comment><USER24> The cars don't necessarily have to come back to surface streets just like the subways don't.

</comment></comment></comment><comment><USER25> I'm going to play the spoiler and say that I think everyone here is on the wrong track. In the short term, yes, I think it will business-as-usual, with some of the ideas being discussed here happening.

But think of the transition from horse to automobile. If you didn't predict the invention of the airplane, your guesses about transportation in the future would have been pretty far off.

I think the questions to ask are: -why will anyone commute to work in the future, when telecommuting becomes more and more lifelike? -what will "work" even look like? We can't be that far away from most service jobs being replaced by computers/robots. -Why would anyone go shopping, when anything they want can be delivered to them instantly or even printed on-site?

<comment><USER26> Yes but in the same vein we can't really predict why people will want to go from point A to point B in the future. Today the main reason is to go to work or go shopping but we may have much more free time and simple want to go to different places/activities.

</comment></comment><comment><USER27> By making automotive transport easier and more convenient, the obvious consequence is a general increase in automotive traffic.

In city centers the worst externality of cars is the space they hog. Self- driving electric cars won't fix that; instead they are likely to increase the utilization of that space: unlike with humans where congested traffic suggests the drivers to look for alternative options such as mass transit, an empty car doesn't mind waiting in traffic by itself.

Suburbia is likely to expand further because if you can work a few hours in your car that means you can afford to live further away in a cheaper location. And school kids can get to school in a car by themselves, so the total number of automotive miles is likely to go up.

</comment><comment><USER28> Self driving electric cars mean that tunnels are more cost effective (no fumes, closer tolerances in tunnel sizing, greater capacity), so we can go 3D (no need for stop lights, we just have cloverleaf interchanges underground with sloped ramps so that passengers feel no lateral acceleration which means higher speeds are ok). Now the surface can be for pedestrians (like Venice) and of course no need for parking lots at all.

This means greater density is possible increasing the value of central real estate. But also means that further commutes are much faster, increasing the value of outlying real estate? Or does it, what does this suggest for real estate investing?

<comment><USER13> I agree that a narrower tunnel costs less (displaced rock is quadratic with tunnel diameter), but is it cheap enough to offset capital costs for all but a few extra worthy projects?

I'd love to have underground streets.... But $$$....

<comment><USER28> Look at the rate of subway construction in China[1]. Self driving cars + tunnel means the subway comes to you, the riders don't need to go to the station. In the US tunnels seem like a rare and expensive thing, but they're very commonplace.

[1] [http://www.businessinsider.com/why-china-is-tunneling-a- mind...](http://www.businessinsider.com/why-china-is-tunneling-a-mind- boggling-800-miles-in-2-years-2013-3)

The difficulty of public works projects in the US is a legitimate question. But it's a separate question from what self driving cars will make possible (especially for the 90%+ of people who live outside the US).

</comment></comment></comment><comment><USER29> I have been thinking about this as well. One idea I've been wondering about:

* Will more remote vacation destinations, including owning a second home in these areas, be more in demand? Buying or renting a vacation house that's a 5-6 hour drive away may not be as ideal if you have to drive yourself there. If you own or can rent a self driving car though, the trip may not seem quite as far. Longer road trips may become more popular, and geographical far places may feel closer than they used to. Demand in coastal or mountainous locations currently far removed from cities may increase.

<comment><USER30> I think robocars will soon lead to robolandyachts. It'll be pretty tempting to rent a comfortable autonomous land vehicle that you tell the scheduling package that "I can leave after 1800 and I want to be at the Grand Canyon at 0800" \- it tells you back the available vehicle systems and their amenities and what view the reserved parking spots at the endpoint have, and you and your family travel overnight without further attendance.

<comment><USER19> Are you just talking about RVs?

<comment><USER5> You can't go to sleep in an RV and wake up at a predefined destination.

<comment><USER19> So... you're talking about self-driving RV's right?

</comment></comment></comment></comment></comment><comment><USER31> I think it gets worse before it gets better. Early generation self driving cars will move slower than human piloted cars, who take greater safety risks in the name of speed.

</comment><comment><USER32> I live in outer London and commute into the centre most days by bus then train then tube. Most people around where I live do the same. I could drive, but it costs too much to park and the time is wasted time, whereas I can read on public transport. If I had a self-driving car, the downside of driving would be removed, so I'd be much more tempted to drive. I guess many others would too, but London wouldn't cope. The upshot of this is that London's congestion charge zone would inevitably be expanded and the charge to drive into London increased still further to keep congestion manageable.

I suspect that most cities that have good public transport would suffer similarly as commuters are tempted back onto the roads. The inevitable response would be London-style congestion charging becoming widespread, because few large European-style cities would cope with any significant fraction of the population switching from public transport to self-driving cars. In the end, due to such charging, I suspect we'd end up back in a similar status quo once the dust had settled, with most people still taking public transport.

On the other had, my kids would probably love to be able to get around the suburbs without me needing to taxi them.

<comment><USER4> Parking spaces could be tranformed to roads. And streets or even whole cities alloted to Robo Cars only and then used much more efficiently.

</comment></comment><comment><USER33> I grew up in an older, mixed suburb; a common complaint I've heard from young people who grew up in other circumstances is they grew up in huge multi-square mile monolithic subdivisions with nothing to do within walking distance as a kid. One interesting social effect of self driving cars would be "mom" (it always seems to be mom stuck with the job) no longer has to taxi drive their kid everywhere... Essentially every little kids has private limo service.

So if the closest public library is 5 miles down the interstate, a kid living there can get a similar life experience to my burb where the library was about 10 minute bike ride away. Wanna go to the park, fine. Wanna go to the library, fine. If kids still hang out at the mall, they can go there too. Friends house is 7 miles away? The self driving car won't care.

And a second-level social effect is the self driving car may eliminate helicopter parent attitudes toward kids being unsupervised... Well, maybe.

Another social effect people have not discussed is employers love sick employees to show up to work, cough on everyone to demonstrate their devotion to the cause, not to mention primate dominance (I can make you work when you're near dead, not vice versa). Often when I call in sick its not because I can't sit quietly and appear to be busy, similar to sitting on my couch, its because I literally can't safely drive when I'm this sick or medicated or sleepless or vomiting or whatever. Self driving cars mean workplaces are going to be even more like a sweatshop from centuries past at least WRT illness. The lower classes packed cheek to jowl sneezing and coughing on each other while moaning in pain... There are people who get off on other people suffering like that and they're going to really like self driving cars.

</comment><comment><USER34> Some of the sensors involved cost $8000+ a pop [1]. The immense R&D expenses will need to be recouped from the vehicle price too. Expect sky high prices and little market penetration while the patents are in effect (20+ years).

[1] [http://articles.sae.org/13899/](http://articles.sae.org/13899/)

</comment><comment><USER26> I think the impact of self-driving cars on real estate will vary wildly by geography as well as their adoption rate.

Urban roads in the US and Canada are quite wide and probably make it much easier to make an effective and safe transportation solution out of this technology. This isn't the case in Europe where urban roads are considerably narrower, regardless of city size. The same can be said about Japan as a whole and other large asian metro areas - Hong Kong, Singapore, Shanghai, Beijing, Seoul. Much tougher.

Europe and Japan also have a much denser rail networks than most of the US, which in turn will cause a different impact on real estate.

Driverless urban buses will probably be adopted much earlier as there are exclusive bus lanes in most medium and large metro areas throughout the world but I don't see it changing the dynamics in a fundamental way.

</comment><comment><USER35> Scenario: Long-term, everyone switches to using robo-taxis and doesn't own a car. The robo-taxis can communicate and co-ordinate.

You're looking at an ~85% drop in the number of cars required (today only ~15% of cars are on the road at peak times). The cars are used heavily in the day, but still need to park somewhere at night. Either way, 85% less parking required. This can probably be fulfilled without street parking. Easier to have centralized charging without street parking.

With intelligent driving, you can probably get away with single-lane streets (each way), with either an expanded turning lane at the corners, or preferably round-abouts.

This leads to a lot more real estate available in cities. Something like 20% more, due to single streets and less parking. That's a big increase in quantity supplied, leading to a big price drop.

<comment><USER36> Since cars in motion take up strictly more room than cars at rest, you could accommodate all cars via dynamic street parking. At night, 6 lane thoroughfares could become 2 lane streets with the other 4 lanes devoted to parking.

</comment></comment><comment><USER37> Negligible impact on real estate.

If you live in the vast majority of the landmass that has no public transportation, your commute isn't long enough for a self-driving car to register on the factors in where you live. If you live in places with great public transportation, then it seems like it matters less--you now inherit issues (and cost) with parking and maintenance you didn't have before.

If you're looking for real estate impact, consider the aging population and the ability of self-driving cars to keep people in their houses longer than they normally would. Along with the factors above, I see the big beneficiaries being the service providers (anything from Uber to grocery stores to healthcare providers) who can now optimize location and distribution differently.

</comment><comment><USER38> This might seem minor compared to the other real estate trends that self driving cars will bring about, but it's interesting to think about what might happen to all the land in urban and suburban American that is currently on- street parking. Hopefully we'll see some creative uses for it, such as gardens, bike lanes, or outdoor seating for cafes, instead of just letting it lie underutilized. Maybe on some streets we'll get something similar to the woonerfs [1] in the Netherlands, with streets being shared by cyclists, pedestrians, and slow moving self driving cars.

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

</comment><comment><USER39> The impact will be very wide, and certainly not limited to real estate, although there will be huge effects there to be sure. It's a transformation not less significant than the development of the Internet itself. Cars will not have to be heavily built to withstand collisions, we will not need controlled intersections, highways will be able to have fewer lanes, roadways and bridges will be able to be of lighter construction because of the reduction in vehicle weight, speeds will be able to be much higher than they are now, enabling fast travel between cities, etc. It's going to be huge.

</comment><comment><USER40> > Parking lots in major cities are free'd up because they no longer make sense > creating more housing real estate.

Buildings will continue to exist, this will only have an effect on large parking lots which will be torn down and replaced by housing, but these are already rare enough in cities.

> Traffic Congestion is reduced so commutes are shorter creating more demand > for suburb living.

If you have to travel 30-50 km to the city centres, even autonomous cars will not solve the issue that this distance needs time for travel.

</comment><comment><USER41> If self-driving cars make Uber or similar even less expensive, then people could just as easily prefer to live in the city without a car because it would be easier to get one on demand. Then they can have increased "walkability", which appears to be increasingly desirable.

On the other hand if transportation is more transparent then they may prefer the lower cost of suburbs and travel more.

There's different forces pulling in different directions, so it's hard to pick which way it will go.

</comment><comment><USER42> Everyone seems to assume that robocars won't work in less densely populated areas, but I'm not so sure. In areas of little traffic it's possible to schedule trips further ahead of time. In addition, much greater speeds might allow a given number of robocars to serve a much bigger area. I'm sure there is a cutoff somewhere, but I think eventually it will be at a much lower population density than many expect.

</comment><comment><USER43> I think what's going to change is parking lots. There will be less demand for parked cars. Also, eventually entire streets will have less parked cars, leading to nice-looking streets like there were before the 20th century. I consider all the cars akin to "garbage" since they are not being used.

What will really change real estate patterns is increased support for telecommuting, both with tools and cultural acceptance.

</comment><comment><USER44> I've studied transportation network design in university. Here are some knowns:

1\. You can, literally, not build enough highways for the demand. As you rack up lanes buildings get further away from each other. This means more drivers and more driving. Attempts to elevate or bury highways are only cost effective in very specific circumstances.

2\. Peak flow (cars per minute) is at around 80km/hr, although sometimes increasing flow further is only a temporary salve, as exit points (the city downtown streets) block.

3\. People are likely to respond to incentives. For example, dynamic pricing on the 407, higher rates during rush hour have pushed out enough traffic to maintain a high flow, even during rush hour. (Though some argue that this has resulted in more spillover to the 401, the closest competing route. I've yet to see a competent paper proving this either way.)

Consider that Uber _already_ has ride sharing code in test markets. With algorithms that work together to minimize driving friction, and with surge pricing to deal with supply and demand at peak rush hour here is what I envision:

1\. Way more capacity to get _close_ to the city.

2\. Much more expensive to get _into_ the city, as capacity increases to the perimeter. With surge pricing, only the very rich will be able to afford a car alone. The poor will either get to the downtown core with a denser option (like a self driving bus) or they will get into the city at an earlier time, even if it means waiting around for work to start. Also, I see "surge insurance" being popular with the poor, since a 10x commute on a single bad day (due to weather or a unexpected road closure).

So where does this leave us? In the short term the core get's more expensive. The closure of a few parking lots is not going to make up for the built in surge pricing of self driving cars. When the price goes up, some companies move to the edge of the core. Leading prices to go up there as well.

The people that really get hosed are the people in the zone just outside of that. Suburban homes no longer command a large premium, since what would have been an unthinkable distance previous years (say, 175kms from core) is now completely reasonable. A software developer can sit alone in a self driving car that drives 150 km/h for an hour, get some work done, then pick up some co-passangers for the last 25kms to offset the cost. Get in work by 10:30am leave by 4:00pm, get some work done on the way home. Maybe watch a show. By 5:30 he's on his hobby farm.

Now all of this is in a relative context. If the Canadian housing market is too bubbly, and across the board it goes down then I'm just arguing it will go down more in the suburbs than elsewhere.

</comment><comment><USER45> Until self-_fueling_ cars are a thing, all of your points, which are predicated on "never stop moving" are moot.

<comment><AUTHOR> It's just a prototype but Telsa made an automatic refueling snake-thing that is super cool!

[https://www.youtube.com/watch?v=ut3sELMOyTM](https://www.youtube.com/watch?v=ut3sELMOyTM)

<comment><USER45> Nice find! Pretty much what I was looking for.

There may be a bit of overlap with self-driving ICE cars, though. I'm wondering if that would be more difficult to handle.

Either way, I had been looking for this story, ever since people started talking about modern self-driving cars. Don't know how it slipped through.

</comment></comment></comment><comment><USER46> I suspect that shopping centers will tax their member stores to pay for a self-driving bus that can pick people up in the neighborhood. They'll have to be at least close to wheelchair accessible so people can take carts on them rather than carrying their heavy groceries and home goods.

</comment><comment><USER47> HN discussion from a little more than a year back. [https://news.ycombinator.com/item?id=8059480](https://news.ycombinator.com/item?id=8059480)</comment>


Infinit announces Project Dropboxe - <AUTHOR> http://blog.infinit.one/infinit-announces-project-dropboxe/ <comment><USER2> Both of them remind me Plan 9's "single most important feature"[1]:

> all mounted file servers export the same file-system-like interface, > regardless of the implementation behind them. Some might correspond to local > file systems, some to remote file systems accessed over a network, some to > instances of system servers running in user space (like the window system or > an alternate network stack), and some to kernel interfaces. To users and > client programs, all these cases look alike.

And Rob Pike once said[2]:

> When I was on Plan 9, everything was connected and uniform. Now everything > isn't connected, just connected to the cloud, which isn't the same thing. > And uniform? Far from it, except in mediocrity. This is 2012 and we're still > stitching together little microcomputers with HTTPS and ssh and calling it > revolutionary. I sorely miss the unified system view of the world we had at > Bell Labs, and the way things are going that seems unlikely to come back any > time soon.

[1] [http://www.catb.org/esr/writings/taoup/html/plan9.html](http://www.catb.org/esr/writings/taoup/html/plan9.html)

[2] [https://usesthis.com/interviews/rob.pike/](https://usesthis.com/interviews/rob.pike/)

<comment><USER3> On P9 at Bell labs, everything could be connected and uniform. In the real world with corporate firewalls, HTTPS is very nearly the only reliable option for connecting to other computers.

On top of that, the fact that most workstations in this world do not have public IP addresses, and p2p becomes really a non-starter.

<comment><USER4> This seemingly destructive segmentation of the Internet is precisely what will lead to its successor: a collection of "overlay networks" built on top of the existing IP stack. We're already seeing it in many ways, with Tor and VPNs as two commonly used examples. But overlay networks are not just advantageous for packet transport. They can represent any decentralized network. BitCoin is an overlay network, in that it's literally a payment network, is a payment network, built on top of existing IP infrastructure.

We are going to see more and more of these "overlays" as the Internet "re- decentralizes". Sure, what we know as "the Internet" is becoming increasingly centralized, and people are right to be concerned. But there is nothing to fear, so long as we can build more abstractions on top of the Internet as we know it. Let Amazon, Google, and the big "clouds" centralize as much of the Internet as they want. They are only digging their own grave, because the next revolution, the "Internet 2.0" will be as decentralized as its predecessor. Only instead of being built on the "dumb pipes" of copper and fiber, it will be built on the "dumb pipes" of the existing, increasingly centralized, Internet.

The more the Internet infrastructure consolidates itself, the more it provides an opportunity to re-decentralize on top of it.

<comment><USER5> What you say made me think of hamachi, a nice vpn overlay network for windows (at first) from the late 90s, and guess what happened to it?

> For paid subscribers Hamachi runs in the background on idle computers. The > feature was previously available to all users, but became restricted to paid > subscribers only [0]

More short sighted business practices as usual.

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

<comment><USER4> You should check out the ipop project [0], the technology behind socialvpn and groupvpn. They have an active and extensive github. [1]

The problem with technology like Hamachi, and even IPOP, is that the nature of NAT traversal means that for any given p2p network, "supernodes" will always be required. IPOP uses STUN/TURN (the same technology as WebRTC) for NAT- traversal. According to Google usage stats (can't find the URL right now), about 10% of p2p connetions over STUN/TURN require relaying all packets over the TURN server. So that means for every ten nodes, at least one will need a supernode to connect to the others.

At first glance, the requirement of "supernodes" seems to impede the proliferation of true p2p networks, because it introduces a point of failure into the system controlled by one entity but relied upon by many. The problem is that "supernodes" cost money, and somebody needs to pay for them. So you end up with companies like LogMeIn, happy to provide a "p2p" solution, as long as you pay them to maintain the requisite supernodes.

However, there is no requirement that one centralized entity supply the "supernodes" in a network. It's 2016, we have "the cloud," and anyone can launch a "supernode," aka a cloud server with a public IP that can assist in NAT traversal.

I hope we will see more business models based around a combination of "p2p" and "federated" network architectures, where they are federated in the sense that a group of "super-peers" provides the "supernodes" required for functional NAT traversal on the rest of the strictly p2p network.

[0] [http://ipop-project.org/](http://ipop-project.org/)

[1] [https://github.com/ipop-project](https://github.com/ipop-project)

(Shameless plug: You should also check out my senior thesis, TorCoin: [http://dedis.cs.yale.edu/dissent/papers/hotpets14-torpath- ab...](http://dedis.cs.yale.edu/dissent/papers/hotpets14-torpath-abs) \-- I've been thinking about this a lot since then, but that was my first real exploration of the ideas I'm trying to express here.)

<comment><USER5> Interesting abstract, but what about just asking for donations?

Freenode does that, and so does public radio, but they seem uniquely positioned to do that. If I were running a bunch of STUN/TURN servers I wonder where I would ask for donations.

Makes me wonder how the Internet came to be. Something about DARPA funding?

<comment><USER4> The cost of a supernode is more than just monetary. There is a cost to the network when one single entity controls all the supernodes, because in almost all cases that means they have some disproportionate level of power over routing or quality of service. You wouldn't want one company running every Tor exit node, because then it's not decentralized.

A business model that relies on donations to one, or a few, entities controlling the supernodes perpetuates the centralization of infrastructure. Not to mention that donations are historically the most cost inefficient solution, especially compared to "market forces." If the efficiency of a decentralized system depends on the number and quality of supernodes, then some economic mechanism must exist to incentivize peers to become "super peers." The competition will ensure that the super peers who survive are the ones with the highest quality nodes at the lowest cost.

Then the question becomes, who pays the cost that gets distributed to the supernodes? In the case of TorCoin, we wanted to avoid the situation where people need to pay to join the Tor network. So our solution was a cryptocurrency with "proof of bandwidth" as its "proof of work." Just like a single Bitcoin represents some amount of CPU power that was expended to "mine" the BitCoin, a single TorCoin would represent some amount of bandwidth that was transferred to "mine" the TorCoin.

The idea was that a TorCoin would have value outside of Tor, and Tor was simply the mechanism used to mine it. So relay operators would mine TorCoins, then sell them on an exchange just like they would any other altcoin. This way they get value from providing bandwidth to Tor users, but the users do not need to pay for the service.

However this gets complicated very fast, because you're not talking about one person mining coins with one CPU, but pairs of people mining coins by transferring bandwidth between each other. So the priority of the paper was addressing the threat of collusion, where two malicious nodes (possibly controlled by the same actor) spoof terabytes of bandwidth between each other, flooding the market with TorCoins. Our key insight was "TorPath," a circuit selection mechanism that ensures every circuit participating in the TorCoin mining scheme is "privately-addressable but publicly verifiable." So each TorCoin (or part of a TorCoin) would represent a circuit that actually existed, and anyone could verify that via a public ledger, without revealing the identity of the circuit participants.

I think the idea of non-CPU "proof of work" schemes is very interesting in general, and bandwidth is one of the most profitable venues to apply it to. For example, imagine if the BGP system were operated along an incentive scheme like this, where instead of "circuits" we are talking about "peering." The path selection mechanism we devised would work in any routing system with multiple participants, not just Tor.

</comment></comment></comment></comment></comment></comment></comment><comment><USER6> Great marketing. I'd never heard of Infinit before. Now I have.

Can anyone describe to me how it differs from MaidSafe? [http://maidsafe.net/](http://maidsafe.net/)

<comment><USER7> They have an excellent comparison FAQ:

[http://infinit.sh/faq?q=&hPP=20&idx=infinit_sh_faq&p=0&is_v=...](http://infinit.sh/faq?q=&hPP=20&idx=infinit_sh_faq&p=0&is_v=1)

Maidsafe isn't on there, probably because it hasn't really launched yet, but Storj, IPFS, Wuala and others are. Should give you a good feel for what Infinit is doing.

<comment><USER3> Ceph is listed as "block" model when it's actually a distributed object store. Part of this is confusion because there has been both a block store and a filesystem built on top of Ceph (the latter named CephFS). But at its lowest level it's clearly an object store, not a block store.

</comment></comment></comment><comment><USER8> I have to admit the situation is a little funny, but Dropbox will probably have an easier time justifying their use of the word "Infinite" that Infinit justifying "Dropboxe".

<comment><USER9> Both infinite and dropbox are standard dictionary words.

Dropboxes are also not limited to the physical world, as many online educational software platforms (that pre-date Dropbox the company) call their shared storage areas for assignment submissions a "dropbox".

<comment><USER10> I think the parent comment meant that Infinite is a word, and also a sensible name for Dropbox to name their product. Dropboxe is a silly neologism that only makes sense in the context of Dropbox's recent press, and not a good name for a product outside of this context.

<comment><USER11> >I think the parent comment meant that Infinite is a word, and also a sensible name for Dropbox to name their product. Dropboxe is a silly neologism that only makes sense in the context of Dropbox's recent press, and not a good name for a product outside of this context.

* Infinit is not releasing a product, this is a satirical post which "rebrands" their base service under a faux name.

* Dropbox is releasing a service which directly competes with Infinit called Infinite

If you think Dropbox can directly compete with Infinit using Infinite, then you should join me for my new Googl search engine!!

<comment><USER12> Such are the risks of naming your company after a common word that describes the product.

<comment><USER11> >Such are the risks of naming your company after a common word that describes the product.

What? Not at all! Infinit has a trademark and will almost assuredly destroy Dropbox in court, including getting an injunction against even using the Dropbox Infinite name during the case.

The real risk is on Dropbox: Not doing their homework and attempting to name a product something that happens to be legally too close to a trademark from a competitor.

What you're saying is that it would be acceptable for me to make a Googol search engine, since googol is a real word and it's Google's fault for picking a name so similar to a real word.

EDIT: Also consider that Infinit is as close to the word Infinite as iPhone is to the word "phone". Do you think Apple assumed the same risks you bring up by naming their product 1 letter away from a common word?

</comment></comment></comment></comment></comment></comment><comment><USER13> Ha! Reminds me of Nick Lowe's reaction to David Bowie's Low.

[https://s-media-cache- ak0.pinimg.com/736x/f6/a2/a1/f6a2a1ca4...](https://s-media-cache- ak0.pinimg.com/736x/f6/a2/a1/f6a2a1ca47c79fc0f0f7a2f38a0ff5f2.jpg)

[https://tomhuntington.files.wordpress.com/2009/10/bowi- and-r...](https://tomhuntington.files.wordpress.com/2009/10/bowi-and- record.jpg)

<comment><USER14> or the band "Green"'s response to the R.E.M album "Green":

[https://en.wikipedia.org/wiki/Green_(band)](https://en.wikipedia.org/wiki/Green_\(band\))

(look under the heading "Singles")

xD

</comment></comment><comment><USER15> Never heard of infinit.sh, but it looks great. The repo is almost empty, though ([https://github.com/infinit/infinit](https://github.com/infinit/infinit)).

Is the code completely open source? Could I setup infinit.sh inside my own infrastructure?

<comment><USER16> We're open sourcing parts of our code as soon as we consider it modular and well documented enough. We started with our build system but the plan is to open source everything over the coming weeks!

And yes, that's exactly why it was made for. Have a look at our examples of deployments: [https://infinit.sh/documentation/deployments](https://infinit.sh/documentation/deployments)

<comment><USER17> That sounds like I will be able to deploy infinit.sh on my NAS (QNAP 469), running some ARM Linux flavor?

<comment><USER18> We don't build the FS for ARM just yet but since we use a lot of the same code we did for our file transfer application that runs on Android and iOS, it shouldn't be too difficult to do.

Feel free to add and upvote what you'd like to see: [http://infinit- sh.uservoice.com](http://infinit-sh.uservoice.com)

</comment></comment></comment></comment><comment><USER19> Terrifically smart jab at Dropbox. If only more companies could take up this sort of attack, lawsuits would stop complicating life.

<comment><USER20> We've yet to see where this ends, however. Legal papers may be next.

<comment><USER21> You didn't read the post, did you?

> Sorry Dropbox, we couldn't resist. It's quite an honor that you decided to > use our name for something we've been building with our peer to peer file > system over the last few years.

<comment><USER22> It's pretty unreasonable of them to assume Dropbox even heard of their company or what they were building, when using an extremely common dictionary word.

<comment><USER23> In the world of product branding and trademarks, companies pay people to make sure they're not stepping on toes and opening themselves up to be sued. To have a product that does the same thing and is called almost the same thing is pretty sketchy. The smartest thing for Dropbox to do is just rename it, especially since it hasn't launched.

</comment></comment></comment></comment></comment><comment> mark-r Reminds me of the time back in 1977 when David Bowie came out with an album called "Low", and Nick Lowe followed with an EP called "Bowi".

</comment><comment><USER24> This is seriously a big deal for the storage industry! Basically what you have created is something in high demand, yet lacking in the storage industry because of its complexity.

What I've read so far is that this is a storage solution that seamlessy integrates several storage technologies, including your own. This storage layer will have cross platform clients, using Fuse and Dokany with user sessions per client managed by your Infinit Storage Service. The end-users do not have to learn a new technology/user-interface and just get an external hard drive. Very similar to how Bitcasa works, with the exception that you give the power of the actual storage architecture to the system administrators. This mean we can freely choose our own storage cluster, for example Ceph or Infinit's own.

And as you plan to release this has open source, you allow a lot of new businesses to grow which together will manage to challenge Dropbox, Amazon, Azure and so on.

For the last few months I have been working on building a Dokany client that used Ceph Rados-GateWay with Erasure Coding. Where I live we have really fast fiber internet with extremely low latency. Dokany is really performant and can easily manage to read/write 30-80MS/s between two clients living in Norway and Denmark(same ISP). It's a lot of work though, and there are several corner cases that causes issues. However if I scrap mine and start using your technology, I can take advantage of your great work and I can contribute back mine to make it even better. My final point being, with this it should possible to offer high performance "remote drives" to end-users. In some cases maybe even faster than an external hard drive. A partnership with a local ISP could offer them a great incentive to use this technology to sell even faster internet access to their existing customers. The best part, this traffic is inside their own network which means less money has to be paid for internet bandwidth. I know my ISP is desperate for something like this, and I guess a lot of other ISP's around the world is highly interested in offering something similar too.

<comment><USER18> Thanks, we think the same :)

You can join us on Slack or IRC so that we can chat more!

</comment></comment><comment><USER25> This is what they're (Infinit) are already doing, isn't it? I can see why they might be a little annoyed at the name Infinite, but it's not like infinite is an unreasonable name for Dropbox to pick for their project...

<comment><USER26> With trademark, the test for a new name depends on whether the name can cause confusion with an existing trademark. When it's the same industry then it's pretty cut-and-dried in favor of the existing mark owner.

Reasonability of the name has nothing to do with whether or not Dropbox can use "Project Infinite". That's the point that Dropboxe makes. Dropbox can either fight that name (which really, they must or lose their own mark meaning anyone can use "Dropbox") and lose their Project Infinite name as well.

<comment><USER27> I think they're being a little silly. If you use a relatively mainstream word from the language in which you do business (and which happens to be virtually identical in all languages anywhere near where you do do business), you don't (shouldn't) have a leg to stand on, IMO. You can't reasonably arrive at Dropboxe independently. But is everyone at Dropbox really supposed to tip-toe around being careful not to name a project after a common word if it's pronounced the same as a company that was accepted to a tech incubator just 2 years ago?

<comment><USER28> > If you use a relatively mainstream word from the language in which you do > business

What about "Windows"? Or "Word"? Or "Office"? It's difficult to find words that are more "mainstream" than that. Yet, Microsoft does just fine.

<comment><USER27> Yeah and if Microsoft made tongue-in-cheek blog posts about IBM because they had something called "Project Officer" we'd all roll our eyes.

</comment></comment></comment></comment></comment><comment><USER29> It looks like Tahoe-LAFS, but without redundancy. Am I missing something?

<comment><USER16> It's indeed similar to Tahoe-LAFS. The largest differences are that you can build hybrid infrastructures with Infinit (local storage and cloud storage) and that we try to make it really accessible and easy to setup. We made a comparison page that sums it up here: [https://infinit.sh/documentation/comparison/tahoe- lafs](https://infinit.sh/documentation/comparison/tahoe-lafs)

<comment><USER29> Tahoe is listed as homogeneous, but there are arbitrary backends, including cloud ones like Dropbox.

<comment><USER30> Note exactly, Tahoe only has Tahoe nodes chatting between each other; it can be the decision of a given Tahoe node to actually store content in the cloud rather than on the local file system, but that's a node-specific decision, not something that each Tahoe client has to speak.

</comment></comment></comment></comment><comment><USER31> This is really interesting for my growing photo archive where syncing isn't important (and even potentially problematic) but where covenience is! I need to take a look at this, thanks.

<comment><USER32> For uses like this, I really want the ability to prevent any user (myself included) from deleting or modifying preexisting files: no matter how a client screws up, I want to be able to get old data back. I wonder how Infinit handles this.

<comment><USER18> We plan to add versioning for exactly this. It's on our roadmap which you can find here: [https://infinit.sh/documentation/roadmap](https://infinit.sh/documentation/roadmap)

<comment><USER32> Fantastic! I hope it allows rollback to an earlier version of the entire filesystem, too. I know people who have lost large amounts of data on Dropbox because some client-side issue (malware or just plain error) deleted everything. I think they also had some online backup service that could roll back files but only if the file was still there, which is useless.

Will you also support deduplication (files, blocks, context-aware blocks, or otherwise)?

<comment><USER18> We already offer replication so that if a node goes down (or loses data) clients can still get their files.

We could add deduplication to our system but it's not a priority for us just yet

</comment></comment></comment></comment></comment><comment><USER33> The real question is which one will win on HN.

/best right now:

        12. Dropbox Project Infinite (dropbox.com)
        741 points by maguay 3 days ago | flag | 288 comments

        ...

        17. In Reaction to Dropbox's Project Infinite, Infinit Announced Project Dropboxe (infinit.one)
        693 points by winta 5 hours ago | flag | 92 comments

</comment><comment><USER34> What are Infinit using for the Windows file system? Dokany? How is it working?

<comment><USER18> Yep, we're using FUSE for OS X on Mac and Dokany for Windows

<comment><USER34> Thanks, will you be open sourcing your FUSE and Dokany bindings?

Are you getting any blue screens of death with Dokany? Is it stable enough?

<comment><USER18> We're planning on open sourcing our implementation for the FS. We want to do it responsibly (i.e.: not a giant code dump) so it's going to take a little time. You can see our build system here: [https://github.com/infinit/drake](https://github.com/infinit/drake)

We haven't publicly released our Windows client yet but our internal build hasn't had stability issues.

<comment><USER34> Thanks, looking forward to learning from the source.

</comment></comment></comment></comment></comment><comment><USER35> Thanks to Infinit for this, it was right on my humour sweet spot!

</comment><comment><USER36> This is really, really cool. Anyone know where they prefer to post issues/requests? Looks like Github is mostly dead[1], but there is a uservoice[2].

I'm debating replacing Camlistore with this - i prefer Camlistore, but this appears to have better tooling, and easier for me to peer with nontech people

[1]: [https://github.com/infinit/infinit/issues](https://github.com/infinit/infinit/issues) [2]: [https://infinit-sh.uservoice.com](https://infinit-sh.uservoice.com)

<comment><USER18> We're still working to open source the code and put in place the infrastructure to manage a community. I'd encourage you to chat with us on IRC (freenode #infinit) or on Slack (see bottom of our homepage [https://infinit.sh](https://infinit.sh))

</comment></comment><comment><USER37> In a similar vein, I'm disappointed RedTube didn't launch something called "RedTube You" in reaction to "YouTube Red"

<comment><USER27> "In Soviet Russia..."

</comment></comment><comment><USER38> Online (cloud) storage seems to be a pretty silly business to operate or invest in, given the amount of solutions available and also the "threat" of open solutions that will inevitably become popular (such as IPFS). Also, essentially, storage is a commodity product. It is ready for a race to the bottom.

<comment><USER39> They compare Infinit with IPFS: [http://infinit.sh/documentation/comparison/ipfs](http://infinit.sh/documentation/comparison/ipfs)

"Note however that IPFS does not focus on providing high-level file system functionalities such as access control, POSIX compliance "

<comment><USER38> Yes, IPFS was just an example.

Also IPFS is being developed as a basic layer. Since it is open, we may expect many independent developers to provide things like access control, and a POSIX API on top of it.

</comment></comment></comment><comment><USER40> This is hilarious :) Also, it's a terrible thing for our friends at Infinit.

</comment><comment><USER41> "Project Dropboxen"

</comment><comment><USER42> So when the train needs to break it generates energy for storage that can be used later uphill etc. Simple and interesting, especially for regions with a lot of variation of heights.

<comment><USER43> Methinks your comment is misplaced.

But I did have a moment of joy at the Monty Python-esque comedy it brought on :)

<comment><USER42> LOL yes it is, was supposed to go to another article.

</comment></comment></comment><comment><USER44> Exactly what I've been looking for! Does anyone know if I could run this on a couple of Rasberry Pi 3?

<comment><USER18> We don't do any ARM builds yet. It uses the same C++ backend we built for our file transfer application which runs on iOS and Android so it shouldn't be too hard for us to get it working on a Raspberry Pi.

<comment><USER44> Alright, good to hear that it is within reach. In our startup what we want that we can't get from Dropbox/Google is privacy. I've been looking at owncloud which would give us privacy but redundancy seems complicated and therefore my excitement about you guys. The possibility to start out super cheap with two RasPi3 and external drives and in the future migrate to more scalable solutions like S3 would make this product pretty awesome for everyone from home tinkerers to enterprises.

</comment></comment></comment><comment><USER45> You could do this all day. Like an _infinite_ loop. ( ͡° ͜ʖ ͡°)

</comment><comment><USER46> Base on FuseFS

</comment><comment><USER47> Such data. Many byte. Wow!

</comment><comment><USER48> In reaction to Infinite's reaction to Dropbox's action, I announce my "Reaction".

</comment><comment><USER42> Dropbox? No thanks, no integrity there. I'm looking forward to protonmails comming equivalent. Security and integrity for the win! It does not matter that I've nothing to hide, nsa etc has no right to prive in my personal life.</comment>


The Mission to Decentralize the Internet - <AUTHOR> http://www.newyorker.com/online/blogs/elements/2013/12/the-mission-to-decentralize-the-internet.html

<comment><USER2> > On Monday, eight major tech firms, many of them competitors, united to > demand an overhaul of government transparency and surveillance laws.

Not long ago they _united_ under the PRISM project to spy on their users. What a quick change of heart.

And again, there's already a similar call for reform started by Mozilla months ago (in June), which none of the PRISM companies supported. They were busy releasing copycat reports denying everything back then.

[https://stopwatching.us/](https://stopwatching.us/)

<comment><USER3> > Not long ago they united under the PRISM project to spy on their users. What > a quick change of heart.

Yes, but then they did it for your safety, and because they care about you. Now they're doing it because...well, they're starting to lose money.

<comment><USER4> A slightly less cynical view: They were in the dark about who else was involved and didn't fancy picking a fight with USG alone (and with an unknown amount of public support). Now that things became public and they know who else is involved, they can at least co-ordinate, knowing that at least one segment of the public cares.

<comment><USER5> It's always easier to oppress the man who believes he stands alone.

</comment></comment></comment></comment><comment><USER6> While Google, Amazon, etc. being centralized might be bad in some ways (and good in others), I'm less concerned with that kind of centralization (because there are alternatives). The most dangerous centralization is at the ISP level, because it's the first gateway to the internet. When I saw the article title I was hoping it would be about that. Unfortunately, wired internet connections make for a really good natural monopoly, so until we have super fast wireless internet everywhere, I don't expect a solution. If any wifi mesh net appears, it would be a good start, but I'm skeptical it would become widespread.

The other dangerous centralization of the internet is the DNS system. I know, technically it's decentralized because there even thousands of root name servers. But politically it's centralized under ICANN. Domains are controlled by registrars and governments. That's not necessarily a bad thing, but a truly distributed system would help guarantee a neutral internet. There are some good solutions for this already, namely Namecoin ([http://dot- bit.org](http://dot-bit.org)), which uses proof of work and a bitcoin-like blockchain as a P2P DNS. Namecoin uses the .bit TLD, but probably the largest barrier to adoption is that it's not accessible by default on devices because it's not ICANN sanctioned and therefore not in the root name servers. There are workarounds for this. ICANN could add Namecoin to the root servers but then it would still be under the control of ICANN. The true solution would be for ISPs to add it to their DNS. If the ISP decentralization is solved, this becomes trivial.

In my opinion, this is the only real way to guarantee net neutrality and prevent censorship.

<comment><USER7> I absolutely agree that ISPs are the nexus point for a truly decentralized internet. I've honestly been surprised that ISPs haven't leveraged/abused their oligopoly more than they have.

> If any wifi mesh net appears, it would be a good start, but I'm skeptical it > would become widespread.

We do have cjdns, Project Meshnet and the Hyperboria network in Seattle. Still pretty fledgling, though.

[http://en.wikipedia.org/wiki/Cjdns](http://en.wikipedia.org/wiki/Cjdns)

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

[http://hyperboria.net/](http://hyperboria.net/)

</comment></comment><comment><USER8> Centralized systems are almost asking to be spying on, laws or not. Even if the NSA does not have the right to do what it did, I'm sure they'd end up doing by using corruption, and there are many ways to do it. Worse, it would open the door to a lot of other shady practices, and I'm sure criminal would make a buck out of it.

The fact that a huge quantity of information is put in one place increases the risk it will peeked into by a lot.

Decentralized systems are a little more difficult to maintain and develop, but are so much cheaper and eliminate the risk of mass surveillance. There are still security risks depending on designs, but honestly I think decentralized has a lot of future, the advantages and features it brings counter balances the disadvantages by a lot.

I wish bittorrent inc would produce more technologies and some competitor would really be cool.

<comment><USER3> I agree. As long as big companies become so good at tracking and making money through surveillance themselves, it's just too irresistible for spy agencies not to try and get that data one way or another.

That's why companies need to at least use forward secrecy, keep data at rest encrypted, and also delete more ephemeral data a lot more quickly.

Google used to delete the data they have on their users every 6 months. I don't think they plan on ever deleting anything they have anymore now. That's the wrong way to go about it. Tracking data should not exist for more than a few months at most, and private communications should not be held for more than a year. Of course, it would be so much easier for the user, if everything was end-to-end encrypted, and then it wouldn't need to be deleted.

</comment></comment><comment><USER9> The easiest path to decentralization is to either:

1 Give every user a publicly reachable IP address at their home or business, or

2 Give every user an account with some remote organization that with a publicly reachable IP address, where the user can be listed in some sort of IP address directory. (Some users now use "dynamic DNS" for this purpose.)

I say 1 is better than 2.

The first big hurdle in the problem of decentralization is reachability; 30 years later, users of today's internet are not "directly" connected for two way communication. By getting users past this initial hurdle of end-to-end connectivity, it opens up the problem of centralization for all developers to solve. The user can pick and choose her software to make direct connections to other users, or she can choose none of it.

The www is a given. Every web developer assumes users can access the www. Direct connections to other users should also be a given. And every developer should be able to assume that users can connect to each other.

It's clear that users want direct connections to each other. They want to communicate. The success of store and forward solutions like email over several decades is proof. What's not clear is that they want (or need) a middleman to broker their connections.

<comment><USER4> I agree and I'm working on a tool that helps with this [1] but based on domain names. Of course that still depends on the registrars (e.g Verisign) but we believe it's easier for folks to remember names rather than numbers and then _use_ the infrastructure. There's a paper we wrote that goes over the architecture and examples, in case you're interested [2].

[1] [http://nymote.org/software/signpost/](http://nymote.org/software/signpost/)

[2] [http://nymote.org/docs/2013-foci- signposts.pdf](http://nymote.org/docs/2013-foci-signposts.pdf)

<comment><USER9> ".. we believe it's easier for folks to remember names rather than numbers..."

Yes, but regardless of whether they use names or numbers, they still cannot get "public reachability" (a public IP address and allowance of unsolicited ingress traffic) without either getting a publicly reachable IP address (ISP's in the US call this a "business class" account) i.e. option 1 or somehow involving at least one computer that already has public reachability i.e. option 2 or 3.

At least, _I_ know of no other way.

If you know how to create public reachability without giving the user a publicly reachable IP address or involving a computer that already has public reachability, please develop and release the code; I think you are a networking genius and have done the impossible!

In any event, my point is that it's probably better that the computer that already has public reachability be owned and controlled _by the user_, not some third party "provider". The user should only need one provider to communicate over the internet: their ISP. I say just give users a publicly reachable IP address: "upgrade" their account with the ISP to allow unsolicited ingress connections.

A myriad of communications and data synchronization solutions will follow. I reckon developers would love to write code for an end-to-end network. It would certainly be more functional that one where eevrything must be done via HTTP through a "web browser".

OCaml NaCl and dnscurve. Nice work! I hope your project succeeds!

<comment><USER10> ipv6 should bring everyone to publich reachability - eliminating the need for NAT due to ip address shortage.

<comment><USER9> Technically, it is not "NAT" that prevents what I am calling "reachability". It is "firewalls".

</comment></comment></comment></comment></comment><comment><USER11> I'm really surprised [http://tent.io](http://tent.io) has not been mentioned here.

Tent is a protocol that allows users to pick and choose a datastore provider for use with any tent compatible application. The provider can be centralised, on the user's own infrastructure or anywhere in between.

Applications can be installed locally (without a dependency on communicating with another server, other than the user's chosen datastore) or hosted on a web server.

Users get to choose where (and control how) an application stores their data, and developers don't need to think about infrastructure, user management or authorisation when designing and building their app.

The protocol is at v0.3 and is not ready for the mainstream yet, but it's coming, and (for me) has the potential to replace a bunch of web apps I regularly use (think dropbox, gmail, github etc.).

</comment><comment><USER12> Unfortunately, I've become sadly apathetic to online privacy concerns. There are always going to be people willing to pay those with the skills to spy. In the past, PI's are HUMINT were really the only ways to get "private" information. The internet makes it easier, and allows it to scale massively (the same characteristics that caused the internet to generate the massive economic gains of the last 20 years). I've just shifted to assume that anything that can be spied on is (semi) public. It's suboptimal, and sad, but I've made the choice of trading privacy for convenience, since I'll never stop using Google or Facebook or Twitter or Amazon. Or storing my credit cards and using online banking. Until someone designs a better option (which I expect will fight a constant battle against surveillance).

<comment><USER4> I seem to come across this view more often and it saddens me. It doesn't have to be all or nothing. For example, if someone really wants to break into my house they probably will but that doesn't mean I'm not going to bother locking my doors and windows in the future.

I'm in favour of making it harder for the seemingly casual surveillance to take place using means that _already_ exist, like encryption and decentralised systems. If more devs etc took that view and built things that were properly secure by default then maybe things would be different. However, such systems aren't really compatible with advertising-based business models and there's a real trade-off in terms of speed to build (that's why - sometimes - 'security' feels like it's slapped on at the end).

<comment><USER12> I think I agree with you. The locking the house doors and windows is a good analogy. I'd love for it to be more difficult for the surveillance state. It just seems like the safer way to proceed is to assume my digital life is public (especially since I don't have anything in particular to hide). Just as I lock my doors and windows despite the utopian society involving unlocked doors all the time.

<comment><USER4> If I were getting started on FB and social media now, I would also default to 'public' and treat posts accordingly. However, I first got involved when it was private and I treated it very differently (this was before I became aware of what I was really giving access to).

I'd also question your comment about having nothing in particular to hide. Everyone has things they don't want to make public but perhaps you won't appreciate what they are until someone exposes them for you? You're using a pseudonym here but would you post the following information:

Who you are, where you live, how much you earn, whether you ever had any STIs, the last time you told a little white lie (to whom and and about what), whether you have kids (what school?).

If your reaction to the above is that it's none of my business, you'd be absolutely right but if you really have "nothing to hide" then why not post answers here for the world? Perhaps some of it is 'public' anyway and I could dig up and post it for you but if I did, how would you feel? My point here is that you _do_ have many things you don't want broadcast to the world and I'm trying to provoke you into thinking about them. Privacy is a complex thing and you might find the following article interesting.

[https://chronicle.com/article/Why-Privacy-Matters-Even- if/12...](https://chronicle.com/article/Why-Privacy-Matters-Even-if/127461/)

</comment></comment></comment></comment><comment><USER13> Good article that hits on an important subject: decentralized privacy- enhancing systems have a tough battle against easy to use consumer friendly services from Google, Facebook, etc.

I have some hope that local grid networks will catch on. Also cheap appliances that are easy to use and offer local cloud services may eventually catch on.

Not to sound too political, but this is the fight between large corporations and/or financial elites firming up their control of _everything_. I am not even sure how much personal effort I will put into these peoples' causes, and I am a long time supporter of the FSF, EFF, and ACLU.

</comment><comment><USER14> Decentralized systems suck.

Look at any protocol or network service designed to be fully decentralized. Inefficient routing, unstable communication, high latency and low bandwidth. You have to do a lot more work to achieve things that would otherwise be simple and straightforward.

Take human communications, for example. They're largely decentralized by default, but we use centralized services to improve efficiency. If some piece of information needs to be disseminated to a large population over a period of time, we first record the message, then we post it in a centralized location viewable by lots of clients[1]. Those clients can then go back and distribute the information to its connected peers[2], but technology also allows us to distribute subscriptions of this information to a wider population in a variety of media[3]. ([1]stone tablets, [2]town crier, [3]newspapers/television)

Modern people are afraid of centralization in the Internet because they are suddenly realizing they have no real control over the content or medium. But this is the case with all other forms of centralized mass communication, too. People are also afraid of their lack of control over their data, which is tantamount in these days to a form of property. Anyone would freak out if the contents of their house were suddenly only available at the discretion of some conglomerate!

But you don't need "decentralization" to keep a backup of your data. Most of it originates from you anyway, and you can store it before you publish it. Some service providers even provide methods to download all your data, though obviously you can't rely on everyone providing you that option (unless someone passes a law...)

On top of all this, the internet is already a system of decentralized networks and services. You can just hook in your own services into the network at any point therein and maintain them yourself. The only restriction is really by the ISP, and there's lots of those to choose from in most developed countries. Personally I think we should consider the internet a combination of utility and public highway, since at this point we all need access, but we also need competition due to the sensitivity of limits on network access.

<comment><USER4> > _"... the internet is already a system of decentralized networks and > services. You can just hook in your own services into the network at any > point therein and maintain them yourself."_

Sure, but I'd argue we should be making it _easier_ for developers to build more decentralised systems. Very few people seem to be working on tools and OSS products at that level and that's because the problems are challenging (of the kind that a startup wouldn't/shouldn't attempt - hence an active area of work in university [1]). There are plenty of things that _require_ centralisation but I'd argue that just as many _don 't_ need to be centralised but just end up that way by default.

[1] [http://nymote.org](http://nymote.org) (I'm working on these tools with others)

<comment><USER14> > _I 'd argue we should be making it easier for developers to build more > decentralised systems_

Why?

<comment><USER4> Ok, let's start with your points.

 _" Inefficient routing, unstable communication, high latency and low bandwidth"_: If I have two devices (phone and laptop) on the same wifi network (e.g. home or work) and I want to send something between them, why should it first go via a cloud service? In my case, photo backups from my phone to my laptop, which happens via PhotoStream at the moment, or files from my laptop to my phone. If a route can easily be formed across the nearest AP then it's shorter, more stable, probably higher bandwidth and certainly lower latency than via the cloud. As the number of devices I own grows, this use case will become more prevalent (think "Internet of Things").

 _" You have to do a lot more work to achieve things that would otherwise be simple and straightforward"_: Sure, but you haven't asked _why_ this is the case (and who 'you' is), which is just as important to examine. At the moment, you _as a developer_ have to do more work in order to build decentralised systems because not enough _free OSS tools exist yet_. The main reason that using a central server is easier is because the tools, techniques and knowledgebase have become 'standardised' but that doesn't preclude there being _better_ ways of doing things. I'm advocating tools that make it easier to build decentralised services and products.

Decentralised systems are more resilient than their centralised counterparts. Any large-scale service/product ends up being decentralised behind the scenes and if you don't believe me, ponder for a moment how the likes of Google, Facebook et. al., manage to deal with so many users across the globe. They _have_ to make their own tools to solve the same kinds of problems I'm alluding to. I'm merely advocating that we try to 'productize' such tools so that any developer can pick them up and incorporate them from the very beginning. Real world examples of such things are how Skype worked in the early days, Dropbox's LAN sync [1] and even Spotify [2], where P2P can improve user experience and _reduce_ their bandwidth costs. I don't know how their systems work but this clearly demonstrates the business value in P2P.

As you say yourself, _" the internet is already a system of decentralized networks and services"_ but don't dismiss the work taken to get there and the value that the lack of centralisation brings. Those same benefits can be gained elsewhere provided the appropriate tools/infrastructure are made available and useable.

Hypothesis: If there were FOSS tools that make it easier to create secure, decentralised systems, more developers would create secure, decentralised products.

[1] [https://www.dropbox.com/help/137/en](https://www.dropbox.com/help/137/en)

[2] [http://community.spotify.com/t5/Help-Desktop-Linux-Mac- and/U...](http://community.spotify.com/t5/Help-Desktop-Linux-Mac- and/Unadvertised-P2P-feature/m-p/400160#M46512)

<comment><USER14> _> If I have two devices (phone and laptop) on the same wifi network (e.g. home or work) and I want to send something between them_

Then you do a Bluetooth transfer, or CIFS/SMB file share, or FTP, or HTTP, or IrDA, or USB, etc. Why would you use a cloud service?

Everyone involved has to do more work to support decentralized services. Users, developers, admins, etc. The only thing you may not need more of is infrastructure. Just because you've made it easier to build a service does not mean the service is easier to use.

No, these products are still centralized. They are merely made more redundant, fault-tolerant and highly-available. They may also be distributed, which is different than decentralized.

I never said there aren't benefits to decentralized systems. As I said, they can be useful. Centralized systems are just easier to create/use/maintain, are more reliable, and are faster. Depending on the application.

<comment><USER4> > _" Then you do a Bluetooth transfer, or CIFS/SMB file share, or FTP, or > HTTP, or IrDA, or USB, etc. Why would you use a cloud service?"_

I suppose this is what you say to people who extol the virtues of Dropbox or BitTorrent Sync? It almost sounds like you've completely missed the wave of stuff that's happening, which I find hard to believe (or you're being deliberately obtuse).

> _" No, these products are still centralized. They are merely made more > redundant, fault-tolerant and highly-available."_

How do you suppose they are made redundant, fault-tolerant and highly- available? I've tried to describe how in my previous comment and you haven't given any counterpoints.

> _" They may also be distributed, which is different than decentralized."_

Ok, this made me think as I tend to use the words interchangeably. Some quick Google searching doesn't clarify anything either (I find conflicting versions). Ovearall, I get the feeling that you have a different view of what 'centralised' means but even then, you haven't given any examples of why such things are more reliable or faster, whereas I've tried to do so.

<comment><USER14> 'The wave of stuff that's happening' is not some crazy new paradigm shift. It's remote network services. Why you would use a remote network service when all your files are available locally, I have no idea. People are weird.

The easiest way to think of this is in terms of network architecture. A Client-Server model of network architecture is by definition centralized; you have one or more clients, and only one server. The client connects to the server to do whatever it wants. In a decentralized model, the server is any node with the ability to serve the requests of the clients - which often includes other clients.

It would take too much time to explain how all of that stuff works, but suffice to say that just because there's more than one computer involved or more than one process involved does not make it a decentralized service. If the client is still just talking to one thing (on the frontend), it's basically centralized.

To explain how centralized architecture is faster, consider a simple example where there is one client, and three nodes distributing a file. The client has to first find and identify the nodes, which usually takes more time than just resolving a single server, because it has to "search" for its peer nodes. Then it has to request a file, which is probably split up into pieces and little requests are sent to each node. Each node then sends the client the pieces. The client then reassembles them on its end to create the finished file. Compare this to a server, where from lookup to file transfer, there is one continuous operation; there is no need to communicate with multiple nodes or track multiple connections or piece together files. Also with the distributed model, you are at the mercy of all the nodes in the network, not just one, and all of the different networks those nodes might be on. You also may end up doing 3x the network operations, depending on protocols, chunk sizes, etc. Because you can't bet on the source of the file coming from one reliable place, network latency may go up, and bandwidth may also go down - in practice over the internet this is virtually guaranteed vs a central server's large pipe.</comment></comment></comment></comment></comment></comment></comment>


US wireless: After the spectrum rush - <AUTHOR> http://www.ft.com/intl/cms/s/0/b5e2e9f0-b686-11e4-95dc-00144feab7de.html#axzz3tewM2viI <comment><USER2> Paywalled. Usual tricks (new set of cookies, Google as a referrer, etc) don't work.</comment>


Imagebackground Remover Tool - <AUTHOR> https://removeit.io <comment><AUTHOR> Hey fellow developers and hackers. I've made a tool for removing the background of images for free. I would love to hear your feedback about it:)

</comment><comment><USER2> Absolutely awesome. Will save me so much time!! Thanks.

<comment><AUTHOR> Thank you for your positive feedback. Let me hear how you like it in the long run. May I know what exactly you will use removeit.io for?</comment></comment>


Lost Murals of Isla Vista - <AUTHOR> https://localwiki.org/islavista/Lost_Murals_of_Isla_Vista

<comment><USER2> As a former UCSB student and Isla Vista local, this makes me sad...</comment>


VHDL Verification Course - <AUTHOR> http://www.stefanvhdl.com/ <comment><USER2> This is quite dated from a modern chip development perspective. If you are interested in learning more of where the industry is today on functional verification look at things like SystemVerilog and Contrained random verification. Things are moving to use libraries/methodologies on top of SystemVerilog like UVM (or OVM and VMM before it). Doulous has quite good introductions: [https://www.doulos.com/knowhow/sysverilog/uvm/](https://www.doulos.com/knowhow/sysverilog/uvm/)

<comment><USER3> I haven't gotten a chance to learn UVM yet; is it as awful as VMM? VMM is (arguably) better than nothing, but there's a lot about it that's really broken [1], which can be very frustrating if you're trying to build large- scale exercisers.

If you're interested in the subject, I also recommend reading the book "SystemVerilog for Verification" [2]; it is "the book" on the subject, and although it teaches VMM, it's an excellent reference on the concept of verification to begin with. (It suffers some from the same problem that Kent Beck's Test Driven Development book has -- it verifies excessively simple things -- but IMO, the techniques that it teaches scale much better than Beck's techniques inasmuch as they're actually possible to use in real world applications.)

[1] For instance, for some laughs, take a look at the API reference for the channel datastructure, vmm_channel: [http://www.vmmcentral.org/uvm_vmm_ik/files2/vmm_channel- sv.h...](http://www.vmmcentral.org/uvm_vmm_ik/files2/vmm_channel-sv.html) \-- there is just so much bizarrely wrong that I can't even list it all. "Sneak" is a good place to start, though...

[2] [http://www.amazon.com/SystemVerilog-Verification-Learning- Te...](http://www.amazon.com/SystemVerilog-Verification-Learning-Testbench- Language/dp/1461407141)

<comment><USER4> For history, UVM (the Universal Verification Methodology -- gee that's original) is basically the same as OVM, which was a SystemVerilog port of eRM (aka Specman). VMM is the SystemVerilog equivalent of RVM (from Vera).

I loved working with RVM and VMM, as to me channel-based transaction (and transactor and scoreboard) programming is very natural and simple to understand. And it's the route that newer languages like Go have taken.

UVM (and all the predecessors) have gone the route of TLM (transaction-level modeling), which has no explicit channels. So many of the objects talk directly to other objects, which adds unnecessary coupling.

However, the big thing that I dislike with UVM is that it is basically Enterprise Java for SystemVerilog. They have made the API's into this cookie- cutter complex enterprise abstraction, where you have to follow the macros and recipes per the book. Everyone must use the built-in macros, and use packages and factories and sequences and agents and virtual components. And your employees start talking in UVM-speak ("oh that's in his UVC").

</rant>

</comment></comment></comment><comment><USER5> Oh boy VHDL, got my final on that on Tuesday. Nice to have learned it, but personally I appreciate the abstraction provided, by even C.

What is the applicability of this skill in the modern chip development industry?

<comment><USER6> Have you checked out the two-process method described in [0]? I used it to implement a dual-core MIPS subset with some relative ease. It was definitely better than dataflow style! Using records and enums also greatly improves ModelSim waveforms.

A project done in dataflow: [https://github.com/jevinskie/aes-over- pcie/tree/master/sourc...](https://github.com/jevinskie/aes-over- pcie/tree/master/source)

The MIPS project in two-process: [https://github.com/jevinskie/mips--/tree/master/project4/sou...](https://github.com/jevinskie/mips--/tree/master/project4/source)

[0]: [http://www.gaisler.com/doc/vhdl2proc.pdf](http://www.gaisler.com/doc/vhdl2proc.pdf)

</comment></comment><comment><USER7> The course assumes some knowledge of VHDL. Could somebody suggest a course/book on Verilog or VHDL for beginners?

<comment><USER8> This intro to FPGAs should get you started.

[http://dlnmh9ip6v2uc.cloudfront.net/datasheets/Dev/FPGA/Intr...](http://dlnmh9ip6v2uc.cloudfront.net/datasheets/Dev/FPGA/IntroToSpartanFPGABook.pdf)</comment></comment>


Articles to Learn about BTC, ETH, and Crypto - <AUTHOR> https://www.nateliason.com/blog/bitcoin-crypto-reading-list <comment><USER2> The Bitcoin Standard by Saifedean Ammous is an excellent book on the economics behind bitcoin as well.</comment>


In praise of micromanagement - <AUTHOR> http://www.bbc.com/capital/story/20131003-in-praise-of-micromanagement <comment><USER2> What this article describes is not micormanagement. It is more about company leaders imposing their will on the company's products.

From my experience, this is false:

"There is a natural limit to when micromanagement makes sense. Once a job, or a company, becomes too complex or too big, it becomes that much harder to gain the visibility and time you need to stay expert. This is a real danger zone for would-be micromanagers. You just don't have enough time in the day, or energy in the belly, to keep up at the pace that is necessary. Either you embrace the principle of selective micromanagement, or you go down trying to do what cannot be done."

Of course there is no limit, just add another layer of management. They now micromanage their subordinates.

This is why there is a CTO, then a Software Director, then managers of different groups, and then technical leads. In my experience a completely flat structure doesn't last.

Promotions are necessary to maintain talent and ensure employees are held accountable.

My feeling is the majority of company success is from top down leadership and vision.

A company needs a vision and goals and the employees need to own a piece of that success or failure.

</comment><comment><USER3> _> One key: micromanagers must be experts._

Don't forget that. If you aren't an expert, cut that micromanagement nonsense out, step aside, and let the experts do their jobs.

<comment><USER4> You should also reevaluate whether you truly are an expert as time goes by. If you were an expert 20 years ago, that doesn't mean you're still one.

</comment></comment><comment><USER5> Seems like it's really about praising selective micromanagement: leaders going very deep into what they are very good at, and what's more important, and letting others focus on the rest.

</comment><comment><USER2> Funny how this is a regurgitation of this similar article:

[http://www.businessweek.com/articles/2012-10-11/in-praise- of...](http://www.businessweek.com/articles/2012-10-11/in-praise-of- micromanagers)

</comment><comment><USER6> Maybe we need to come up with a different word all together. I propose _macromanager_

Micromanager has a negative connotation for good reason. Nobody wants to be micromanaged. Nobody wants someone managing the minutiae of their everyday jobs.

</comment><comment><USER7> Very annoying that because I live in the UK I can't access this article :/

<comment><USER8> [http://www.uswebproxy.com/index.php?q=aHR0cDovL3d3dy5iYmMuY2...](http://www.uswebproxy.com/index.php?q=aHR0cDovL3d3dy5iYmMuY29tL2NhcGl0YWwvc3RvcnkvMjAxMzEwMDMtaW4tcHJhaXNlLW9mLW1pY3JvbWFuYWdlbWVudA%3D%3D&hl=3ed)

;), also viable use hidemyass, use a vpn with an exit point in the US, tunnel over SSH.

Region locking content is just idiotic.

</comment></comment><comment><USER9> micromanagement != QA</comment>


Scaling Engineering Culture at Twitter - <AUTHOR> http://www.infoq.com/presentations/twitter-scalability-culture

<comment><AUTHOR> > _Raffi Krikorian (VP of Engineering) discusses the software engineering > challenges met re-architecting Twitter and the cultural change impact that > came with it._</comment>