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

> Many Europeans support this - they don't understand how government censorship can quickly get out of hand.

This argument can be made for government in general, although granted technology does make it easier for a smaller group to overreach. I'm a European and do hear your concern, but I feel comfortable supporting restrictions on speech _as long as_ there is also a functioning and just legal system that those restrictions operate within. Though there does seem to be a worrying trend towards technology bypassing the legal system and just giving enforcement agencies blanket access of late.

We all also have our own cultural biases and blind spots. I offer this not as whataboutism but as a different perspective: I'm _way_ more frightened by the authoritarian police culture (I base this on interactions with the police in a period I lived in the US) in the US than I am of the UK governments internet censorship. The internet censorship could do a lot of harm, but I think not as much potential harm as a large militarised police force willing to bust down doors on command from above.


There has never been a functioning and just legal system in the history of mankind. Not to mention that what is "just" is very much up to debate.


Well, sure, it's all relative and no system is perfect. Not every mother is perfect, doesn't mean I escort mine around the house at gunpoint whenever she visits.


Table buckets are currently quite hard to use for a lot of use cases as they _only_ support primitive types. No nested types.

Hopefully this will come at some point. Product looks very cool otherwise.


Yes _however_ the nodejs benchmark at least is handling each message asynchronously, whereas the go implementation is only handling connections asynchronously.

The client fires off all the requests before waiting for a response: https://github.com/matttomasetti/NodeJS_Websocket-Benchmark-... so the comparison isn't quite apples to apples.

Edit to add: looks like the same goes for the c++ and rust implementations. So I think what we might be seeing in this benchmark (particularly the node vs c++ since it is the same library) is that asynchronously handling each message is beneficial, and the go standard libraries json parser is slow.

Edit 2: Actually I think the c++ version is async for each message! Dont know how to explain that then.


Well, tcp streams are purely sequential. It’s the ideal use case for a single process, since messages can’t be received out of order. There’s no computational advantage to “handling each message asynchronously” unless the message handling code itself does IO or something. And that’s not the responsibility of the websocket library.


Good point!


Data is a bit light on the ground given we haven't had masses of EVs for all that long. But I wouldn't necessarily have this expectation based off of phones and laptops.

EVs have really high-end battery management systems and cooling, which will have a huge impact on battery life.

Heck even my phone is lasting better these days with just better software battery management in Android. My current oneplus 9 is going on three and a half years old and hasn't notably degraded in battery life. Whereas I'm pretty sure I remember all my previous phones having noticeable battery degradation after a year or so.


Definitely preferable to intersections. A roundabout means there is only one place to look for oncoming cars, rather than potentially 4.

Although ideally the crossing on a roundabout should be set back so far they arguably aren't even on the roundabout... so space is an issue.


The preference for 4 way stops in a country that otherwise prioritises traffic flow so much is really jarring. Traffic lights too to some extent.

About 5 years ago my wife an I were doing a California road trip. At one point on a relatively rural road -- I think it might have been Dry Creek road heading into Napa but cannae mind exactly -- we got stuck in traffic for around 45 minutes. We thought there must have been some huge accident or roadworks closing the road. But got the the end and nope... 4 way stop essentially letting one. car. through. at. a. time.

I distinctly remember exclaiming "why the f wasn't that a roundabout" after clearing. Funny that it is now one of my strongest memories of that trip haha.


4-way stops are bizarre to me having grown up in the UK where roundabouts/intersections with priority given for one direction are trusted and reliable traffic-calming measures.

I think one of the reasons a 4-way stop might be introduced is to improve safety where there was previously a 2-way stop (that people would blow through). I came across this in Canada recently. All I can say is the UK has drastically lower traffic-related deaths than Canada [0] and I think I've seen 2-3 stop signs in my entire life. I imagine North America's pedestrian hostility is a piece of this puzzle.

Don't get me started on North American highway interchanges. The UK's roundabout junction system is far superior, in my opinion.

[0]: https://en.wikipedia.org/wiki/List_of_countries_by_traffic-r...


Four way stops are common in lightly trafficked situations where the locals can't justify spending the money on anything but a few stop signs. For instance, the main street through a small town (<2k pop) might have traffic lights and maybe a circle for the one other major road it intersects, but where the two or three roads parallel to that intersect with other town roads, a four way stop makes the most sense. Most of the time a car gets to one, it will be alone. Since neither road is long and neither is expected to have fast cars anyway, a four way stop is the most natural and intuitive option way to sign it.

Four way stops are also common when two country roads of relatively equal weight intersect. There are so many roads like that, so many intersections, that the local government can't possibly afford lights or circles on all of them. If one of the roads is known to get substantially more traffic than the other than a two-way stop is usually used, but if it isn't obvious then a four way stop is the safe default. In these situations, pedestrians aren't a factor at all because the intersection is five miles away from a town and it's farmland on both sides of both roads. Virtually nobody is walking there, not even people walking their dogs (unpaved access roads are better for that anyway.)


I'm not sure why the four way stop "makes the most sense".

In Europe one road (perhaps arbitrarily) would be declared the main road, and the other road gets yield signs, or even just yield road markings (triangles).


If one is obviously a main road then it's a two way. If neither is, then it's a four way. If the intersection is lightly trafficked then there's not any reason not to make it a four way because it won't cause meaningful delays anyway. When a county has several hundred country road intersections that get a few dozen cars or less a day through them, it doesn't make sense to even spend time studying each one. Just throw up some stop signs and consider the matter resolved.


Or do what they do in the UK. For all of these, make them 'mini-roundabouts' which is literally a dot painted on the center of the road. You follow the rules of the roundabout without building one. Works just as efficiently as a four way stop with light traffic - actually more, since you don't need to stop if the intersection is empty.


And then every single car must stop. That's a huge waste of energy.

The European way requires half as many signposts, and at most half as much stopping and starting of cars.


Or, in the absence of any signage, it'd just be "right before left". Relatively common in the outskirts of cities where there isn't one road that has significantly more traffic than the other one.


Right before left is how four-way stops work. Putting the signs up doesn't cost much, so why skip them?


No, that’s not the same. On a 4-way stop you have to completely stop. Also how I remember my year in the US (I’m from NL) is that the first to reach the stop has right of way, not the “left” one. But I might be wrong on that last one? Didn’t have a drivers license at the time (but was surprised - and turned off from - 4-way stops).


That's how it works in my state. The right before left thing is just the tie breaker.


90% of stop signs in the US/Canada should actually be yield signs. Stop signs are reserved for "dangerous" intersections, ie spots where a driver can't safely see or make a decision without first stopping.

Throwing a red octagon at every single intersection of two roads is lazy and absurd. It encourages people to break the rules (just run the stop sign) and cause accidents (zone out, stop and go without actually looking).


There's a T intersection in Mission BC that has a stop sign that (for people turning right) should be a yield (at most) because to the left is a one-way after the intersection eg no one should be coming from there :) but the problem is it's single lane and people making a left there should stop.

When turning right, I and a lot of people barely bother slowing down. It's always a bit frustrating when someone does what the sign (and the law of course) says when the don't need too from a pragmatic point of view :-D.


Funny, I live in the US and I treat about 90% of stop signs as yield signs. My ex-wife would complain about it to me all the time as if I’m doing something wrong, but I never stopped lol


I presume you mean a rolling stop and not a yield?


Yeah, slow down to 3-5 mph and make sure there’s nobody coming, then keep going.


I like 4-way stops as a pedestrian because I can actually cross the road there. With roundabouts it's impossible to cross without asking really nicely or risking my life. US drivers do not stop for pedestrians so crossing that kind of infrastructure is often taking your life into your hands.


This can easily be solved with a camera. Not yielding to a pedestrian = instant fine.


Roundabouts should have only 1 direction you need to look at to cross. You don't have to watch 3-4 different directions like at a 4way stop.

That said, if there's a huge bias towards cars coming from one direction (or out one direction), that can be very difficult to cross. And it has impacts on the roundabout's throughput too, and means that a roundabout might not be the most ideal. Similarly to how a roundabout that gets backedup into can fail catastrophically (you have to make sure there's negative pressure!)


> It has impacts on the roundabout's throughput too

For these use cases there's the turbo roundabout[0]. Depending on how you design it you can give certain directions slightly more priority, though they don't solve the pedestrian issue either.

[0]https://en.wikipedia.org/wiki/Roundabout#Turbo_roundabouts


>You cannot just take one part of that system and expect to magically reap the benefits.

Yeah, specifically people only focus on the "repo" bit. Build system, PRs, history browsing, etc all get handwaved away after you stick all the code in a single repo. These are the extra hard parts though!

I think if you were to properly implement "monorepos" in git world it would actually look a lot like a Github _organisation_, rather than a Github repository. Each git "repo" in the "org" would be a workspace with it's own segregated UI so that you can for example check out just that workspace, or see only that workspaces commits or issues -- but some features such as github actions workflow triggers and PRs would be able to span multiple workspaces.

Github doesn't really seem to have put much thought into really supporting monorepos though. They have added some support (e.g. codeowners) to support "repo"-as-monorepo, but have also added some features that could go towards supporting "org"-as-monorepo (e.g. dependabot dependency updates and the dependency graph). But it all stops well short of a complete monorepo toolset.


> It seems to be a necessary evil for a company to grow

Yep, the needs of a company change when and if it grows. Early days, a small team "getting shit done" is probably what you want to find your place in the market, make early customers happy, etc. But as you scale on all axes: time, headcount, headcount turnover, customer count, feature count and so on, that early pile of shit that got done can start to bog you down. Even worse if no one recognises the need to change and continues adding to the pile.

I've seen a few really brilliant engineers struggle with this in various ways: 1. Start hating their job but being confused because they love the company -- not realising that the company has become a very different beast to the early days. 2. Struggling to get out of the "get shit done" mentality and just floundering. Even becoming a net negative contributor in some cases.

Worth remembering this I think in an industry where rapidly changing companies are so common. Your company might be a good fit _now_ but that does not mean it will stay that way!


I think the biggest issue with the grandparent comment's approach is that it makes things extremely difficult for newcomers as was already mentioned. Turnover is inevitable in an organization and that means that eventually there will be a point where the person who wrote the initial code is no longer at the company. Touching that code is a pretty big liability if no one really understands how it works and that bogs down productivity a ton. Another reason why sometimes rewriting something is the right answer.


100% and one of the great things about k8s is that this diagram applies to essentially any application. Standardisation is awesome.


Proper standardization is awesome. De facto, corp-owned standarization not so much.


Unfortunately as a k8s user in the real world every container is slightly different and has numerous hacks in it to make it compatible with k8s in some way or another. So no.


This is an underappreciated point. I love k8s. I hate the shit people decide to do in k8s.

At a previous employer, we had a k8s cluster with a bunch of machines that were designed to a) load a filesystem kernel module inside the container (yes inside, not outside), b) mount /dev from the host in the container with Docker, and c) mount hard drives from the host /dev inside the container using the "mount" command.

In a twist that should surprise no one, those containers don't work well. And they failed to work in crazy, confusing ways for which there is no documentation to troubleshoot, because who in their right mind would do something like that?

I've had better luck in places that have a Platform as a Service team that owns the k8s infra. They generally have a lot more pushback to say "no, you're not going to do that on our cluster" which helps to tamp down some of the crazier ideas.


I'm not convinced you read your own links.

1. Is a report on the need to evaluate how prevalent the practice of recycling food scraps from manufacturing as feed actually is, as apparently the FDA (or the author of the report anyway) doesn't have access to good data on the topic.

2. Is advice that appears to be targeted at large institutions that want to _start_ recycling... doesn't really say much about the prevalence except that it isn't a novel idea.

Plus, the original article says: > Individual households were responsible for more than half of that, with the rest coming from retailers and the food service industry.


>1. Is a report on the need to evaluate how prevalent the practice of recycling food scraps from manufacturing as feed actually is, as apparently the FDA (or the author of the report anyway) doesn't have access to good data on the topic.

limited information on safety, not limited information on whether the practice is being done.

>2. Is advice that appears to be targeted at large institutions that want to _start_ recycling... doesn't really say much about the prevalence except that it isn't a novel idea.

No, the bottom of the page lists examples of businesses doing it on a large scale.

Moreover, the original comment claimed "We're not feeding wasted produce to livestock", which implies we weren't doing it at all, which the previous two links clearly disprove.


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

Search: