A call to PHP's mt_rand generates only odd numbers - <AUTHOR> http://3v4l.org/dMbat <comment><USER2> Because max value should be "mt_getrandmax()" instead of "PHP_INT_MAX", it just gets a 32 bit number then scales it up.

see: [http://php.net/manual/en/function.mt- rand.php](http://php.net/manual/en/function.mt-rand.php)

Under caution:

The distribution of mt_rand() return values is biased towards even numbers on 64-bit builds of PHP when max is beyond 2^32. This is because if max is greater than the value returned by mt_getrandmax(), the output of the random number generator must be scaled up.

edit: this post went from 5 points to 1, which I don't care about(in ~500 days I posted less than 10 times and I have ~35 points), but who downvotes documentation, seriously? -_-

<comment><USER3> While documented, that is surprising behavior. If it takes in an int, shouldn't it be able to take in PHP_INT_MAX? And shouldn't it yell at you instead of just silently going about its day?

<comment><USER4> The PHP approach seems to be that any crazy behavior is acceptable as long as it's documented.

<comment><USER5> That's not a "crazy behavior", it's a limitation of the algorithm they use. mt_rand() only has approx. 2^32 possible seeds; why would you expect it to support ranges larger than 2^32?

The best thing to do is to not use mt_rand().

<comment><USER6> "Fixing" broken data silently is tremendously bad behaviour in general because you can't possibly know whether the caller knew that they were providing invalid data and whether the caller is going to be happy with your fix.

If you expect input parameters in some range and you get values out of that range, then you blow up. You don't silently truncate anything and you certainly don't reduce the entropy of your random number generator by nearly 50%.

<comment><USER7> This was my main doubt about PHP 7's scalar types, which will autocast values into the desired types. I don't expect the caller to know better than the callee what are the method's boundaries, and once casted you may not be able to see if the input was garbage. But yeah, when something breaks the method's author can wash their hands.

</comment></comment></comment></comment></comment></comment><comment><USER8> Quoting a Reddit comment ([https://www.reddit.com/r/lolphp/comments/3eaw98/mt_rand1_php...](https://www.reddit.com/r/lolphp/comments/3eaw98/mt_rand1_php_int_max_only_generates_odd_numbers/)):

 _The problem is way worse than you think. Check out what this looks like when printed in hexadecimal:[http://3v4l.org/XVTgS](http://3v4l.org/XVTgS)

Basically, what is going on is that PHP_INT_MAX is 2^63 - 1. mt_getrandmax() is 2^31 - 1. The way mt_rand() makes a random number when the limit is too large is that it makes a random number in the range [0,2^(31)), then it scales it to be a number in the range [0,MAX-MIN), and finally adds MIN._

So in your case, it scales everything by 2^32 and adds 1. Which is why the numbers are* extremely non-random _. [See my other comment in this thread for a more detailed explanation and some more test scripts that prove this is what is happening.]([https://www.reddit.com/r/lolphp/comments/3eaw98/mt_rand1_php...](https://www.reddit.com/r/lolphp/comments/3eaw98/mt_rand1_php_int_max_only_generates_odd_numbers/ctdhxha\)*)

</comment><comment><USER5> And that's another reason why it's a good thing that PHP 7 (coming out soon!) has a new function called random_int() which provides an unbiased distribution of integers powered by a CSPRNG (yes, it uses urandom, in case anyone asks).

My employer is leading the effort to expose a compatible interface in PHP 5 applications so developers can add one line to their composer.json file and start writing code for PHP 7. It's MIT licensed and should nearing its 1.0.0 release soon.

[https://github.com/paragonie/random_compat](https://github.com/paragonie/random_compat)

<comment><USER9> Using /dev/urandom is not a good thing. It's only needed to get secure random numbers (CSPRGs) very slowly. You'll drain it so that the apps which really need it will be out of seeds. To get random numbers fast, you need to use the good bits of a PRG based on an LCG.

Everybody should know by now that the mersenne twister is not only bad, but also slow.

Everybody should know by now that the first bits are good, and the last bits horrible. That's why you should not use modulo %, but rshift or better use Melissa E. O'Neill's PCG, which uses the first good bits to improve the latter worse bits. [http://www.pcg-random.org/](http://www.pcg-random.org/)

<comment><USER10> There is in practical terms no such thing as "draining a secure random number generator".

Most RNGs are at bottom stream ciphers. The stream cipher problem of stretching a small key into a very large keystream is fundamental to cryptography, and RNGs are an instance of that problem in the most favorable setting: no message boundaries and no coordinated state.

You don't in practice worry about AES-CTR "running out of key", and so you shouldn't worry about urandom "running out of entropy".

It's understandable why so many people believe this: the Linux urandom man page invents a whole parallel universe in which this is not only a live issue, but one with applications to specific kinds of cryptography! Until we find the appropriate incantations to shut down that particular portal to the world of the Elder Things, it's best just not to look at it.

<comment><USER11> Still no updates on this bug report: [https://bugzilla.kernel.org/show_bug.cgi?id=71211](https://bugzilla.kernel.org/show_bug.cgi?id=71211)

[tumbleweeds]

</comment></comment></comment></comment><comment><USER12> Using a loop of that length (for ($i=0;$i<10000;$i++)) on a site allowing people to execute code, and then linking it to HN effectively amounts to a do- it-yourself DDoS. I don't think I wanna be the host of that site right now.

<comment><USER13> Shouldn't they cache the result?

<comment><USER14> A lesson they're learning right now, I suppose.

<comment><USER15> To find out later that not everything can be cached, e.g. time(), rand(), file_get_contents()... to find out further that no sys or lib call that contains I/O can be cached. And then damn it, why bother caching at all?

</comment></comment></comment></comment><comment><USER16> I believe it's also generally an anti-pattern to do things like "num = rand() % max" or "num = rand() & bit_mask" where rand() returns an integer from a pseudo-random number generator, right?

PHP may not do a very good job at ensuring an even distribution throughout the space of possible integers, but for PRNGs in general (especially the quick & dirty ones), the _worst_ place to grab bits from is the least-significant bits.

(my source is that I hung out with a copy of Numerical Recipes in college; Numerical Recipes has a nice chapter for learning about PRNGs, along with example code for a number of implementations)

<comment><USER5> Yes, don't use % even with a CSPRNG!

[https://stackoverflow.com/a/31374501/2224584](https://stackoverflow.com/a/31374501/2224584)

<comment><USER10> It's true that's an anti-pattern, but it's not a particularly exploitable one in most of the places that really need CSPRNGs.

<comment><USER17> Agreed. It's a red flag for "expect more exploitable issues to be found around the corner" and can result in biased distributions, but it by itself does not break a RNG.

</comment></comment></comment></comment><comment><USER18> This is why you read the documentation. Don't deduce what a method does purely on its name and your common sense, you are probably wrong...

<comment><USER19> Yes. In fact I propose that giving methods pronounceable names is an anti- pattern. Method names should be random strings of characters. Then you don't fall into the temptation of not reading the documentation and assuming things. In fact, make them long enough so that you can't memorize them.

someObj.dbrdCfj34uW31U289u(x)

This avoids a lot of frustration. Imagine if this was called someObj.sqrt(x). People could jump to the conclusion that this takes the square root of a value, when in reality it only does so on weekdays. On weekends it returns the CPU temperature.

<comment><USER20> I suspect you are being facetious, but I've for a long time thought that this was actually an okay idea, even for systems less screwed up than PHP.

When I need to write a function with lots of complex interactions, I mash the keyboard rather than try to come up with a name that's misleadingly simple. That way you have to read the documentation.

</comment></comment></comment><comment><USER21> It's because there simply _are_ more odd numbers than even numbers...

(j/k!)

<comment><USER22> I think if you consider Z rather than N the opposite is true

Proof:

For ever number k there exists -k which has the same parity as k (that is, if k is even, -k is even as well)

For every k there is (k + 1) with opposite parity (same thing with -k and -(k + 1)

Now, if we count the numbers, from 1 to infinite, the number of even and odd numbers is the same

from 1 to -infinite the number of even and odd numbers is the same as well

And you get an extra zero, an even number

<comment><USER23> Intuitions based on assuming that you can treat "infinity" the way you would a finite number are often, as in this case, wrong.

The "infinity" referenced here, aleph-null, is provably both the cardinality of the set of even integers, and the set of odd integers. (And also the set of integers, and any other countably infinite set.)

So, unintuitive as it might be when thinking about finite subsets of the integers, there are not only as many positive integers as negative integers, but as many of either as there are _integers_.

(There are, however, _bigger_ infinite sets, there are, for instance, more reals than integers.)

See, [https://en.wikipedia.org/wiki/Aleph_number](https://en.wikipedia.org/wiki/Aleph_number)

<comment><USER4> Some fun examples about infinity:

There are as many prime numbers as there are integers.

There are as many fractions between 10 and 11 as there are integers.

There are _more_ real numbers between 41.00001 and 41.0002 than there are integers from -infinity to infinity. Even though both are "infinite."

</comment></comment></comment></comment><comment><USER24> I see your problem, PHP.</comment>


TPP Leak Reveals Take-Down Measures Softened – But DRM Rules Remain Harsh - <AUTHOR> http://www.forbes.com/sites/emmawoollacott/2015/07/08/tpp-leak-reveals-take-down-measures-softened-but-drm-rules-remain-harsh/ <comment><USER2> "require intermediaries to pass on notices of alleged infringement to their users" aka they can intimidate and mislead gullible users into paying penalties for copyright infringement even if they aren't legally required to.

As someone outside the US, this trade agreement seems like the US trying to impose its poisonous, backwards copyright and intellectual rights laws on the rest of the Western English speaking countries.

All behind closed doors of course, with no open debate, to the massive boon of greedy corporations and at the expense of the common man as per usual.

<comment><USER3> It's exactly that. Listen to Obama's State of the Union speech. He said it quite clearly. The TPP is about fixing international law and the terms of trade to benefit the US - as opposed to China (who has been pushing for other trade blocs with non-US law).

<comment><USER4> > _"...to benefit the US"_

More specifically, I think it benefits US _corporations_. There's a sleight of hand in politicians/lobbyists presenting it as benefiting the US as a whole.

<comment><USER3> The political elite seriously see absolutely no difference. There are a number of directions we could go to expand on that.

</comment></comment></comment></comment><comment><USER5> Can we just have a breakdown of companies who played a large part in the TPP formation so we can boycott them? Money seems like the only way to speak to these dickheads.

Here's something close - a list of supporting businesses on the US side: [http://tppcoalition.org/about/](http://tppcoalition.org/about/)

What do we have here... Apple, EBay, Facebook, Hewlett-Packard, IBM, Intel, Microsoft, Oracle, Xerox. This is going to be hard - I use every one of these companies every day. But what part did they play? If the press can find out, that will help the user make an informed decision.

<comment><USER6> Honestly, the more productive thing to do is organize and fundraise to change how money influences politics.

<comment><USER7> This is also one of those times when calling your Senator can work. The ones voting for it are kind of hoping that nobody notices. A lot of angry phone calls will convince them otherwise and could help give them cold feet.

It helps that there's not really a cohesive voting bloc in favor of the trade negotiations. It's just about the billionaires.

<comment><USER8> That's not going to help this time, because the TPP is fast-tracked and can't be filibustered, and has the overwhelming support of the Republican majority.

</comment></comment></comment></comment><comment><USER9> Free Trade Negotiated In Secret

<comment><USER3> They aren't free trade negotiations. They are protectionist trade deals meant to exclude China from trade in its region as it rises. (China has been trying, similarly, to arrange ASEAN trade deals to exclude the United States).

<comment><USER10> This is a bit of a myopic view isn't it? Given that these treaties often force Most Favored Nation status on the participants, the end result is lower tariffs overall (if only that they can't make it worse), so pro-free-trade

<comment><USER3> The reason I say this is that it's being used to exclude certain countries and it sets up rules that explicitly favor particular countries.

Given its strategic nature its role is to protect both Western powers and regional countries that want investment from the West and to grow against the rise of China.

Since it protects 40% of the world GDP at the explicit and planned sacrifice of other nations and because it is used to instantiate international laws that protect those same countries I call it protectionist. And if you look at the leaked memos it's really not so big a stretch. It's also been called protectionist by people not aware of its strategic value (e.g. Assange).

</comment></comment></comment></comment><comment><USER11> > the section on DRM circumvention is apparently pretty much unchanged from > previous versions. Previous leaks showed it criminalizes those who bypass > technical measures aimed at restricting copyrighted content — even if > they're being bypassed for reasons that don't contravene copyright law.

can someone explain how DRM would be enforced, and how someone could bypass it with "technical measures"?

<comment><USER12> For example DRM is present on most dvds and one can't watch dvds on Linux out of the box (for most distros). This can be bypassed by installing a library.

But you would never do this because this would be illegal...

<comment><USER13> Who cares about DVDs - Mozilla caved and added DRM (EME) to Firefox. These kinds of restrictions cut directly against freedom of speech and the press. This becomes yet another word game were you _de jure_ have legal rights, but _de facto_ do not because it is illegal to discuss the methods involved in actually exercising those rights.

/* before someone decides to repeat the propaganda that EME only applies to video (as if that is any better), remember the paranoid websites that try to disable the clipboard or show an _image_ of text instead of just adding the text. "one frame video of text" is inevitable */

<comment><USER11> I would be surprised if someone leaps to defend DRM in this context.

<comment><USER14> Why would you be surprised? Copyright maximalists advocate all sorts of things. One of the very early cases was DRM enforcement on PDFs.

[https://en.wikipedia.org/wiki/United_States_v._Elcom_Ltd](https://en.wikipedia.org/wiki/United_States_v._Elcom_Ltd).

<comment><USER11> i mean on HN.

</comment></comment></comment></comment></comment></comment><comment><USER15> A good article for establishing an anchoring bias in the naive masses. They'll be so relieved that it's not as bad as it COULD have been. Just like a flea market bargainer who quotes you an insanely high price then sells it to you for a 300% markup, but you think you're getting a discount. Reels em' in every time.

</comment><comment><USER16> So they asked for more, and settled for less.</comment>


American Oil Is Cheap Enough for Climate Activists to Buy It - <AUTHOR> https://www.bloomberg.com/news/articles/2020-04-20/american-oil-is-cheap-enough-for-climate-activists-to-buy-it <comment><USER2> "Pay us $30/barrel or we'll burn this up in the atmosphere."</comment>


To Improve Your Sense of Direction, Lose the Technology	(2017) - <AUTHOR> https://www.nytimes.com/2017/01/09/science/walking-directions-mobile-phone.html <comment><USER2> Before I go to a new city, town or any location, I like to review a map. I don't like to be lost.</comment>


Ask HN: Which of these courses would be most useful to a programmer? - <AUTHOR>

STA 525: Time Series Analysis Stationary and non-stationary models.  Autocorrelation and partial autocorrelation functions.  Autoregressive (AR), Moving Average (MA), Autoregressive Moving Average (ARMA), and Autoregressive Integrated Moving Average (ARIMA) models.  Models for seasonal time series.  Identification, estimation, diagnostic checking and forecasting.  Use of computer package such as SAS or Minitab.
STA 432: Applied Regression Analysis Matrix approach to regression models, least square estimation, correlation, multiple regression, transformation of variables, analysis of residuals, multicollinearity and auto- correlation. Use of computer packages for applied problems.
STA 420: Nonparametric Statistics Common nonparametric tests such as permutation tests, sign tests, Wilcoxon test, chi- square test, and rank correlation tests. Null distributions and their approximations.
MAT 470: Combinatorics Study of enumeration techniques, permutations, combinations, principle of inclusion and exclusion, finite fields, combinatorial designs, error-correcting codes. <comment><USER2> Combinatorics is some classic computer science-ish material, showing up in a lot of Knuth's writings.

The other topics may well be useful for specific applications, but having no idea about what you intend to do with this knowledge, I would vote for combinatorics as "most useful to a programmer".

</comment><comment><USER3> Programmer is a broad term. What area of programming interests you?

<comment><AUTHOR> Of course. I am still exploring the field, but I enjoy building things from scratch and general software engineering. I guess I'll be working in the San Francisco area for other companies until I start a software consulting business or launch my own product. At least that's a general idea.

I really enjoy destroy all software screencasts if that helps</comment></comment>


Begging for disruption: where biotech, grassroots, and microfunding overlap - <AUTHOR> http://www.fightaging.org/archives/2010/02/encouraging-transparency-in-life-science-fundraising.php

<comment><USER2> That amount of money (5-20000) actually doesn't seem like much for biotech stuff if you need lab access and supplies.

<comment><AUTHOR> Your instincts on that are wrong. There's a skilled postgrad fellow with papers to his name proving or disproving pulsed laser ablation of lipofuscin in nematodes for ~14k, for example. You should read the DIY Bio piece here for how people reduce costs for OTS items. There is huge bloat in OTS biotech prices, which can be traced all the way back to government funding of research if you care to - standard budget management, etc, etc.

[http://www.hplusmagazine.com/articles/bio/diy-bio-growing- mo...](http://www.hplusmagazine.com/articles/bio/diy-bio-growing-movement- takes-aging)

<comment><USER2> Ok, but whose lab is this person using and how much is he paying to use it?

My wife works in 'biotech' research, and it seems to me that even if you can scrimp on people fees, paying for equipment is going to be expensive unless you work in an area that doesn't require much of it.

Interesting article, and hopefully things will move in that direction, but I think 'build it yourself' can only get you so far. Hopefully that range will continue to expand though.</comment></comment></comment>


Your Game Doesn't Need UDP Yet (2013) - <AUTHOR> https://thoughtstreams.io/glyph/your-game-doesnt-need-udp-yet/ <comment><USER2> Reliable UDP is the best of both worlds ([http://tools.ietf.org/html/draft- ietf-sigtran-reliable-udp-0...](http://tools.ietf.org/html/draft-ietf-sigtran- reliable-udp-00)), and most decent networking libraries use that over TCP. You can make reliable and unreliable requests as needed and very required for any close to real-time game.

Enet is an open source version ([http://enet.bespin.org/](http://enet.bespin.org/)). But lots of industry platforms use it like Photon if using Unity or RakNet native direct. A network library not built on reliable and unreliable capablities (RUDP since running TCP and UDP same time is overkill) is going to be slow and overkill and you'll have to rewrite it (unless you are doing turn based). HTTP/S access also needed for other basic messages for states and setup etc.

RUDP is the best base of multiuser virtual environments that we have so far until protocols like SCTP ([http://tools.ietf.org/html/rfc2960](http://tools.ietf.org/html/rfc2960)) but those probably won't happen widespread, so RUDP it is on top of UDP and you don't need to write a library/toolkit/server, there are plenty. It is like writing TCP only you can pick and choose which messages are important/reliable/prioritized.

</comment><comment><USER3> This article is from last year, it isn't in response to the other UDP/TCP article on the front page published today. I don't know why it was submitted to HN in response to that article, the first one already does a good job describing trade offs and the right role for UDP. It could possibly use one more line: "If it's easier to do so, use TCP to prototype."

</comment><comment><USER4> Personally it seems to me that much of this is going to be game protocol dependent. I'd like to read some articles by game developers giving examples of their protocol and where UDP was useful and where multiple tuned TCP connections wouldn't have been enough.

Also, my understanding is we live in a buffer-bloated world where packet loss due to congestion is avoided at all costs with the exception of latency. In such cases non-TCP traffic still suffers horrific latency rather than being sanely dropped.

Thirdly, I'm not sure I buy the "Not all networks pass UDP" line. I'd like to think most players will be behind home routers that will NAT UDP traffic correctly, and you get the added advantage with UDP of being able to do hole- punching. Afaik you can't do hole-punching for TCP streams, which means requiring users to set-up forwarding rules themselves (Assuming their router doesn't support UPnP... _sigh_ ).

<comment><USER5> > I'd like to read some articles by game developers giving examples of their > protocol and where UDP was useful and where multiple tuned TCP connections > wouldn't have been enough.

Here's some articles from professional game developers that contain war stories about networked game programming. Unfortunately they are quite old and you might have already read these. I would love to see some newer ones.

This is the article referenced in the OP. The author of this wrote network code for some MechWarrior games. You can find more of his articles/talks with some war stories: [http://gafferongames.com/networking-for-game- programmers/](http://gafferongames.com/networking-for-game-programmers/)

This is pretty old but talks about real world networking issues that are still relevant today. In particular, they mention having TCP retransmission causing about one minute of latency. That figure has improved but not gone away since those times. "The Internet Sucks: Or, What I Learned Coding X-Wing vs. TIE Fighter": [http://www.gamasutra.com/view/feature/131781/the_internet_su...](http://www.gamasutra.com/view/feature/131781/the_internet_sucks_or_what_i_.php?page=1)

The two articles above both recommend using UDP (or at least regret using TCP). For a contrast, here's one about using TCP in a "real time" strategy game. "1500 Archers on a 28.8: Network Programming in Age of Empires and Beyond": [http://www.gamasutra.com/view/feature/3094/1500_archers_on_a...](http://www.gamasutra.com/view/feature/3094/1500_archers_on_a_288_network_.php)

The best conclusion we can draw is that the decision between TCP and UDP is a very application specific and advocating one over the other for all use cases is harmful.

<comment><USER6> That was 13 years ago... networks / algo / network programming changed a lot since that time.

<comment><USER5> > That was 13 years ago... networks / algo / network programming changed a lot > since that time.

Yes, a lot has changed but a lot has stayed the same. In particular, the speed of light is still the same that it used to be and the optimal round trip time across the world hasn't improved. Not a lot has changed with the fundamental nature of TCP or UDP either.

All of the articles I linked have valuable lessons that are still valid today. Also some stuff that isn't really relevant today.

But yeah - I'd love to see more recent articles on the subject.

<comment><USER7> Mauve wrote some interesting articles [1] back in 2012 on the roll-back principle being used in GGPO, which is a (semi) popular netcode used for fighting games.

In the likely event that you don't play fighting games, I'll break down briefly the needs of the genre. Fighting games are almost always animated at 60 frames per second. Different moves will come out in a certain number of frames, be active for a certain number of frames, and have recovery animation for a certain number of frames. When you have all of that information for a character, it's called (unsurprisingly) "frame data".

Let's say you and your opponent are standing right next to each other. You press light punch, and he presses heavy punch, and it turns out that he was just a little faster and pressed his punch button a tenth of a second before you did; that's six frames. HOWEVER, his heavy punch is a really slow button; it has ten frames of startup animation before the punch even comes out! Your light punch is much faster; it comes out in only 3 frames. So he hits punch, six frames pass, and then you press punch as well. Three more frames pass, and your punch is active, but he's still in the startup animation. So even though he hit a button well before you did, you're actually hitting him first.

There's a lot more to the strategy (if your punch hits him, he's going to go into some kind of hit animation; how long does that last? If you can get another attack to come out and hit him before that animation ends, then there's no way for him to block the second attack; this is the basis behind the concept of a combo in fighting games. Interestingly, it was initially a bug in Street Fighter 2.) but for the purposes of networking, all you need to understand is that frames are crucially important to a fighting game, there need to be sixty of them a second, and delaying even one or two frames can make the different between counterhitting your opponent with a light, or getting counterhit yourself with a heavy. It's worth clicking around on a couple of Mauve's posts, because they tend to be pretty interesting.

[1]: [http://mauve.mizuumi.net/2012/07/05/understanding- fighting-g...](http://mauve.mizuumi.net/2012/07/05/understanding-fighting- game-networking/)

</comment></comment></comment></comment></comment><comment><USER8> It's not a "premature" optimization if you know you're going to need it at some point. The thing that makes an optimization premature is if you're not sure you need it, but when it comes to networking you can generally calculate out pretty quickly how much data you're going to need to transfer and what latency you're going to need.

There are a lot of optimizations that you KNOW you'll need in a game upfront, and it's easier if you get it in your architecture early. (For instance, spacial partitioning trees and sprite packing)

Not to mention that, augmenting networking into a project later on is a tremendous pain. It's one of those things you have to build in from the start; so if you know you're going to need fast packet-based unreliable networking you'll save yourself a lot of pain by doing it from the start.

Realistically though, you should just use a library for networking instead of writing it yourself, if you can.

</comment><comment><USER9> I don't think UDP should be regarded as an optimization you add later. If you leave it to add after you've written the rest of your networking code, changing from ordered reliable delivery to unordered unreliable delivery is going to have a pretty profound effect, which you probably will want to have thought about from the start.

</comment><comment><USER10> I'm interested on the author's thoughts on using solutions like ENet, which offer both reliable (TCP-like) and unreliable (UDP-like) "channels".

I live somewhere where bandwidth is decent (12Mbps) but dropped packets are frequent (copper lines). Games that use UDP (TF2, CoD, NS2) work perfectly, in contrast to TCP games (WoW, Minecraft) which stutter to the point of being unplayable.

In my hobby game's engine (Source Engine-inspired), I use ENet. Even with high packet loss, variable latency, and limited bandwidth (simulated) the game remains playable; whereas when all the channels are set to 'reliable', it's the opposite.

Another consideration is NAT-punching. From the small amount I've read, it seems this is much easier to accomplish with UDP.

<comment><USER11> Your network sounds odd: If you get 12 Mbps when blasting UDP but you experience packet loss high enough to bog down TCP, it actually sounds like your network is congested and TCP is working as designed.

Your copper last mile modem (eg. ADSL2 or DOCSIS) has error correction DSP magic going on that is designed to adjust to the signal quality observed and trains the link paramters so that packet loss doesn't happen, at the expense of bandwidth. And you get a 12 MBps link speed, which sounds like your modem hasn't had to slow it down to a crawl to prevent packet loss. So congestion or other fault/misconfiguration in your ISP's access network?

Custom protocols on top of UDP are also supposed to respond to congestion by slowing down. See eg [http://tools.ietf.org/html/rfc5405#section-3.1](http://tools.ietf.org/html/rfc5405#section-3.1)

<comment><USER12> How about router buffer overflow? UDP can survive that (because routers feel free to throw excess in the bit bucket) but TCP cannot.

<comment><USER11> That could mean two things:

a) packets are arriving from a fast link and don't fit onto a slow link. Dropping packets signals TCP or your UDP protocol to adjust to the slower link speed, exactly the desired behaviour.

b) the router buffer is too small to handle uneven bursts of packets even when the destination link has spare capacity. This is a misbehaviour and will cause needless packet loss.

Then there's the "too much buffering" failure mode

c) the router buffer is too big, so that there is constantly a long queue of packets in the buffer at the upper limit of the link speed, causing excess delay. This is also called "buffer bloat" and is a sin often committed by consumer ADSL modems and such.

So, an UDP protocol with retransmission capability could possibly overcome b) at the cost of behaving counterproductively in the presence of real congestion. The remaining problems would be to estimate the actual link bandwidth, and figuring out how to retransmit the large portion of lost packets while retaining good app layer latency.

But that's a rare problem to have in the network because the failure mode is so obvious (TCP stops working properly even though your network is idle). c) is much more common.

<comment><USER12> But, a) is a buffer issue too. Of course no buffer is big enough if the stream is continuous. But the backoff works exactly because it doesn't overwhelm the router buffer, leaving it time between bursts to empty into the slower network.

When TCP 'backs off' that's failure to a streaming protocol - now we get to spend seconds retransmitting and performing 'slow start' probing to determine an ideal rate. Which blows the latency of time-critical packets to the point its useless (as covered elsewhere in this thread).

And this is almost always the upstream link - your local home or business network is probably gigabit. Your ISP link is very likely slower than that.

<comment><USER11> TCP would really suck if it went to multi-second coma on every bandwidth adjustment!

Buffer getting "overwhelmed" is exactly what causes TCP to adjust.

Fortunately TCP doesn't go to slow start immediately when it sees congestion in the network.

It first tries slowing down. There's a "congestion avoidance" phase as long as not too many packets are lost, "slow start" happens only when congestion avoidance gives up.

Excess buffering can infact mess up congestion avoidance in addition to causing needless additional latency, since it in effect postpones the timely signaling of link capacity. See the bits about congestion control at [https://www.bufferbloat.net/projects/bloat/wiki/TechnicalInt...](https://www.bufferbloat.net/projects/bloat/wiki/TechnicalIntro)

After this probing initially happens, TCP will remember the link bandwidth, window size etc even after periods of inactivity.

This is also how UDP based protocols are expected to behave (specced by IETF/IAB).

<comment><USER12> All cool if you have one connection and don't share it. But real apps on real computers have multiple apps running - while you're trying to communicate, email fires up and scans a dozen servers; your progeny upstairs clicks on a video; ROKU decides to update.

Bandwidth and window size are a fiction over time. TCP believes they will be stable (for many seconds); its tuned for old server-to-server connections, not the extremely dynamic network conditions in the average home/business today.

So you end up in slow start and congestion avoidance, and only after packets are dropped and resent pointlessly adding to congestion (as you point out).

I've spent years now examining traces of TCP catastrophes. It's because TCP is NOT dynamic enough that folks like my company are driven to finding alternatives.

So yes TCP really sucks. For many applications.

</comment></comment></comment></comment></comment></comment></comment><comment><USER6> Most MMORPG I know use TCP, we're talking about low latency messages and a lot of people in the same zone, so yes TCP is fine for most cases outside of FPS / RTS.

<comment><USER13> I'm pretty sure the original Everquest used UDP. I remember during beta a friend of mine would log into my account while I was still logged in, I could click on buttons to start elevators and such, and he could see the elevators move when I did that. With TCP, my connection would have been dropped and I wouldn't have been able to do that.

<comment><USER14> No that's not right. Both TCP and UDP are single source single destination formats. Eg, they both have a definite IP/port specified in their headers. A packet sent directly to your friend cannot get to you or vice versa. So what you experienced was simply the Everquest server sending the same duplicate information to both you and your friends, which could be done with both UDP and TCP.

</comment></comment></comment><comment><USER15> Why UDP isn't good for real-time applications:

      * lack of a connection
      * lack of order
      * lack of retransmission
      * lack of error checking
      * lack of flow and congestion control
      * lack of integrity/security

Why TCP isn't good for real-time applications:

      * latency
      * latency
      * latency
      * latency
      * latency
      * latency

SCTP's only advantages over TCP for real-time applications is unordered data delivery and selective acknowledgement. In this way we can still use the most recently arrived message instead of the correct ordered one, which will reduce latency in one area.

But the 'association' is still be affected by congestion control, especially with multiple failures in the same window. Using Reno SCTP, this may be mitigated, and it is argued that some congestion control is much better than none at all. But without evidence specific to an application's implementation, UDP is still the superior real-time protocol if you don't care about what data you're getting.

<comment><USER16> UDP has error checking in the form of a checksum. It's one of the few guarantees UDP has: your datagram either arrives complete, or not at all. TCP also has no real security to speak of, either.

</comment></comment><comment><USER5> I'd have to agree with the "yet" part, but most of the article wasn't very good advice.

If you're getting started with multiplayer game code, you should be fine with TCP for starters. Early in the project, most of the connections for testing will happen over a loopback interface and LAN anyway.

However, if you're doing a real time multiplayer game, you can't ship with TCP or your reputation (and sales, etc) will be ruined. No-one likes laggy gameplay.

In the above, I use the term "real time" as in a "soft real time software system", not real time as opposed to a turn based game. In other words, "real time" in the sense that if significant latency occurs, the game will produce incorrect results.

Arguably, most games do not fall under this category. E.g. a real time strategy game server has the option to "stop the world" and wait for all players to get back in sync. They are essentially very fast turn based games when it comes to analyzing it as a software system.

This means that most games can probably use TCP.

If you can't survive one second of latency, you must use UDP. You can bootstrap your project on TCP, but you can't use it over real networks.

> When everything is working perfectly and there is no packet loss (assuming > Nagle is disabled), UDP and TCP will perform approximately equivalently; > data gets through immediately, it's delivered to the application, there's no > need to retransmit.

This is important, both ways. When everything works correctly, either one will do. But in real world, everything doesn't work always smoothly. You won't know if your network code works well before you've tried it with several players across the world. On the other side of town is not far enough.

> And on most modern consumer networks, packet loss is very low.

This is true only if you measure using "ping" in a network with no contention. That is not a real world measurement.

In most consumer networks, the WAN throughput is smaller than LAN, so if you have several computers hooked up, the router will have to drop some packets if everyone attempts to send or receive at their maximum capacity.

Go play Counter Strike and have your little brother turn on a BitTorrent service or your wife watching movies on NetFlix. Packet loss _will_ occur.

> You may never even see the conditions where UDP should be faster.

It is _not_ about being faster. The throughput of TCP should be pretty much equal to UDP when you average over time. The pings should be similar most of the time.

It's all about latency. A single lost packet on TCP will inhibit all the packets sent after it until the situation is lost. This can be one second or more, regardless of the quality of the connection in ideal conditions.

The bottom line is: _know_ whether you will need UDP or not. Do not guess, measure and test it in real world networks. But you can still use TCP to bootstrap your project.

Regardless whether you use TCP or UDP your network game _must_ have a mechanism for dealing with latency, like stopping the world in an RTS game (over TCP) or predicting the movements of characters in an FPS game (over UDP). TCP does not magically solve all the problems in networking, it also creates some.

<comment><USER17> I like to ask "why is UDP perfect for VoIP calls?"

A packet showing up a second late is completely worthless. You don't want it at all. If the connection gets interrupted, well, it gets interrupted, and the people using it have to repeat themselves. But this beats hearing words (as if you would be so lucky as to have each word be its own packet) out of order.

<comment><USER18> Because voice and language have so much redundancy built in that dropping few packets will not degrade perceived call quality. On the other hand, waiting a quarter of a second to receive lost packet definitely will degrade call quality.

</comment></comment></comment><comment><USER19> >If you re-invent TCP on top of UDP without a thorough prior understanding of TCP, you will get it wrong.

I don't know why this is in there twice for emphasis. The use case for a custom TCP on top of UDP is pretty rare. More likely you will not want the kind of flow control and packet ordering that TCP spends its cycles doing.

<comment><USER5> And this isn't the only article that suggests that "re-inventing TCP" is what UDP network game code does.

Yes, you need to do some of the same things that TCP does, but not all of them and the ones you do should work differently.

Connection management is similar in TCP and UDP game protocols but you also need to keep track of ping and you probably don't need a fancy three way handshake either.

Reliability and in-order reception is something you _don 't_ need in UDP game code, especially reliability through retransmission. You need only semi- reliability, ie. knowing when a packet was lost. The way to handle a lost packet is application specific, but most likely you'd like to send the most up-to-date data instead of retransmitting the state from 100ms or one second ago.

Flow control needs to make sure that no more packets are sent than can be received but the goal is to minimize latency, not maximize throughput.

The whole idea of "implementing TCP over UDP" is just silly - why would you want to do that? There are very good reasons to use UDP and you should know when that is the case.

<comment><USER20> I think the point is that most of the time what you are doing is reinventing the basic idea of a TCP connection over UDP, with a few optimizations for your environment.

Now, the implementation may be different, but basically you have to deal with connection startup, connection teardown, packet loss, packet loss detection, and so forth.

In other words, what you are doing is taking the basic idea of TCP, and reimplementing a different take on that basic idea optimized for your application. Doing this benefits from a great deal of in-depth knowledge of current solutions, starting with TCP.

In other words, the danger is that you will try to do something TCP does without a real understanding of why it solves a problem in a particular way and come up with a very bad solution.

<comment><USER19> >connection startup

In some situations you do, but if the game has a matchmaking server you can just _go_.

>connection teardown

Packets stop when the game ends, no need to do anything special.

>packet loss

You have to deal with this but you don't have to use a similar method to what TCP does.

A minimal UDP protocol to meet the requirements of a game might not do nearly _anything_ TCP does, yet work perfectly fine. A fancier protocol might have a TCP-like channel, but that's not a guarantee. And it's not hard to use UDP and TCP at the same time.

<comment><USER20> > You have to deal with this but you don't have to use a similar method to > what TCP does.

Particularly if you are not using the similar methods, a thorough understanding of TCP is helpful.

Otherwise you run into the possibility of reinventing TCP badly.

</comment></comment></comment></comment></comment><comment><USER21> For reference it took me about a month and a half to get a udp system working for a game. I had 0 netcode experience.

</comment><comment><USER22> One time to seriously consider using UDP is when you find yourself implementing "UDP on top of TCP", e.g. implementing what's essentially a small-packet messaging protocol that uses TCP underneath. I find it disturbing when I have to reassemble messages read from a TCP socket and if the messages are small enough to fit into a UDP datagram I feel like I'm better off with UDP plus a lightweight retry mechanism.

</comment><comment><USER23> > In testing, on your LAN, on lo0, when there's not a lot going on in the > game, delivery is totally reliable, so the code path for recovering from > missed datagrams is never covered, the usability where users are dealing > with lost traffic is never stressed

The advice for this point should be "turn on the Network Link Conditioner" (or whatever the equivalent is for your OS of choice)

</comment><comment><USER24> A relevant paper from INET 97: _Characteristics of UDP Packet Loss: Effect of TCP Traffic_

[http://www.isoc.org/inet97/proceedings/F3/F3_1.HTM](http://www.isoc.org/inet97/proceedings/F3/F3_1.HTM)</comment>


Guerrilla Public Service Redux (2017) - <AUTHOR> https://99percentinvisible.org/episode/guerrilla-public-service/ <comment><USER2> I love a good forgery.

It's stories like this that can teach us how useless much of the things we think are "secure" are actually not.

I'm always frustrated with the bogus security measure out there that do nothing to stop the criminals and just serve as a hassle to honest people.

Checks are one of those. I have a micr font and a few nice check mockups in Photoshop for "verifying" checking accounts for direct deposit. I'll simply plug in the bank routing number and account number, print it out and write "void" on it. As if that is some kind of security. I also keep some blank checks in case I need to actually print a check. There is nothing special about them except for the number placement (magnetic ink hasn't been a thing for a long while, it's almost all optical now).

Another is a utility bill. I've had several occasions where a utility bill with your name on it is required to verify your location and identity and I either don't yet have the utilities in my name or they are in the name of a roommate. A quick scan, clone brush, and type tool and you've got a utility bill in your name.

I have never had anyone take a second glance at any of this stuff. It always works.

<comment><USER3> If you get caught, there's no plausible deniability. No way to pretend you just got confused, or that you were in a hurry and just marked "Yes" and signed without reading.

If you were e.g. applying for state welfare while living out of state, a forged bill with an in-state address would not get you caught, but may be crucial for proving ill intent if you get caught by unrelated means.

A lot of security measures add just that much security. It's easy to break, but breaking it removes plausible deniability.

Most home locks wouldn't stop even a person slightly below average strength, bump it with your shoulder a couple times, and you're in. But you can't then claim you got lost, confused, or thought it was your friend's house, or thought you heard someone say "come in". A surprised homeowner will be less hesitant to use available violence, and no court would believe you meant no harm.

<comment><USER4> This is an aspect of security that a lot of smart technical folks seem to have problems reasoning about. Technical systems sit within cultural and legal systems, and it is the totality of all of those that shapes our behavior.

<comment><USER5> Schuyler Towne has (several?) great talks on this, going through the history of physical security and our assumptions about perfect security vs. social and cultural symbols.

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

</comment></comment></comment></comment><comment><USER6> Throwaway account for obvious reasons. I think I got a job offer from telling this story.

I heard this Podcast a little while ago. I am a civil engineer and found it amusing. I apply for a job in transportation engineering with a big agency and go through the interview process. I passed the written exam and the second oral interview. Next interview is with heads of the organization. They are asking me good questions and I think they like me and my answers. One of them asks how I keep up with news and latest things happening in civil engineering. I mention podcasts as one of the mediums. Then to keep the conversation lively, I tell them about this story that I heard through 99% invisible. They all laughed and found it amusing. It's a transportation engineering job talking about a sign on the highway. I know my audience. Haha. And I followed up that podcasts are a great news medium and I wouldn't have heard this story if I wasn't listening to them. I like to think they liked me from my qualifications but this story pushed them into picking me.

I ended up declining the offer because I got a better offer somewhere else. I'm just glad to know I have a really good interview story.

<comment><USER7> Only a civil engineer would create a throwaway account to share such a mild anecdote.

<comment><USER8> Maybe it's the main account providing the anonymity. Posting something specific enough to be identifiable with a throwaway makes sense in that case.

</comment></comment></comment><comment><USER9> How it looks today: [https://email@example.com,-118.2563622,3a,75y,3...](https://email@example.com,-118.2563622,3a,75y,39.45h,97.97t/data=!3m6!1e1!3m4!1sB26OdicvltC4P9pyiLJnOg!2e0!7i16384!8i8192)

That part of the LA Freeway System has always been a mess, with the 5/10/60/101/110 all mashing together in one spot.

<comment><USER10> You can go back in time and look at the 2008 view and see the guerilla sign too.

While I was looking, I noticed that there is barbed wire around the pole that supports the sign, to prevent people from climbing up. But it's only on the pole that's in the middle of the freeway, not the one that is near the side of the road. Clearly not a lot of thought was put into this sign!

<comment><USER11> If I recall the story correctly, Caltrans replaced the guerrilla sign with an official one in the same location, and returned the replica to the artist.

<comment><USER10> Yeah, I think they mention that in the article. In 2008, you can see the original. In the most recent picture, you can see the official replacement.

<comment><USER11> I mean they replaced it back in ~2001 so 2008 was the official version. Not that it makes a real difference.

<comment><USER12> > More than eight years after Ankrom's sign went up, he got call from a friend > who noticed some workers taking it down.

<comment><USER11> Ah, okay.

</comment></comment></comment></comment></comment></comment></comment><comment><USER13> The highway construction outfit is some excellent social engineering.

For some reason this reminds me of the stories after Manhattan (?) legalized bee-keeping. People started confessing that they'd had clandestine hives for years. My favorite was the guy who made a fake AC unit, installed it on the roof, and bought a stereotypical AC repairman outfit that he wore every time he went to do maintenance work.

<comment><USER14> See also [https://telstarlogistics.typepad.com/telstarlogistics/2006/0...](https://telstarlogistics.typepad.com/telstarlogistics/2006/09/what_is_telstar.html)

"The short answer is that it's a scam for parking illegally in loading zones. The nerdy answer is that it's an ongoing experiment in corporate phenomenology, urban camouflage, and brand development."

<comment><USER15> Did you know you can get through the security cordons at international summits by simply arriving with flags on your car and your own motorcycle outriders? [https://youtu.be/TdnAaQ0n5-8?t=56](https://youtu.be/TdnAaQ0n5-8?t=56)

</comment></comment></comment><comment><USER16> Rob Cockerham's site is part of the Olde Web and is filled with things that are not-quite-similar to this, e.g. the "High-Profile Sculpture Replacement" [http://cockeyed.com/pranks/mall/plazaprank.html](http://cockeyed.com/pranks/mall/plazaprank.html)

<comment><USER17> Thanks for that trip down memory lane! Glad to see he's still at it.

</comment></comment><comment><USER18> I grew up during the Earth First! movement which started in the late 1970s on the coattails of various other forms of environmental civil disobedience and tree hugging.

I think what's changed today is that due to the national debt etc, most of us know that things are going wrong but we're so disenfranchised/disempowered that we feel helpless to do anything about it, even if we wanted to or knew we wanted to. It's not just that we haven't had a raise in 20-40 years, but that our bosses haven't had one, and neither have their bosses. We've reached chronic, systemic ineffectualism.

It changes things when we go from a "how do we stop those guys" perspective to a "how do we start helping society fix things" perspective.

</comment><comment><USER19> I always wonder what system the LA area is using for their signage. They seem to have a rule to mark exits as late or confusingly as possible. This leads to people suddenly swerving across all six lanes. It requires a certain skill to mark that badly....

<comment><USER20> Socal freeways usually have center signs every couple of miles letting you know what named exits are coming up in how many miles, then the named exit sign maybe half a mile before the exit, then the sign that just says exit with an arrow. Highway interchanges have overhead signs with lane indicators (although this particular one was deficient untill guerrila fixed).

It's pretty good as long as you're expected named exits. California built their highways before federal standards on numbering, so they were exempted from numbering exits until about 2000. In 2000, they decided to add exit numbers when replacing signs, and signs have a planned lifetime of 10 years, so anytime now everything should have exit numbers ;). It's gotten better, but there was a while where all the map software would tell you to take exits by number, but the numbers weren't posted (yet), a mix of better databases and more posted numbers and me moving out of CA means I don't recall seeing that in a while.

<comment><USER21> As Californian, I hate exit numbers. I typically know vaguely where I'm trying to go, but navigation apps nowadays often favor the exit numbers. Exit numbers are still poorly marked in a lot of places, and are typically harder to spot.

Missed an exit one time because Google Maps said "take exit 34C" and the exit number was only posted far down the offramp, after it was too late. Best part was Maps neglecting to say "for highway XXX", pretty much the most important highway for the area, which would have made navigating incredibly easy.

</comment></comment></comment><comment><USER22> Ah I'd heard about this earlier but the details are a lot of fun:

"He copied the height and thickness of existing interstate shields, copied their exact typeface, and even sprayed his sign with a thin glaze of overspray of gray house paint so that it wouldn't look too new."

Of course, not everyone should be doing this, but what a brilliant story!

<comment><USER23> The best part is that Caltrans inspected it and left it up!

</comment></comment><comment><USER24> This is like the real-world version of applying a userContent.css file to patch a UX flaw in a web application, except in this case he patched a UX flaw in the freeway.

As users of web applications and freeways, I think we tend to overestimate our expertise in designing solutions to the things that annoy us. This story had a happy outcome because the expert user was careful and competent. Thankfully the barrier to entry for submitting patches is relatively high.

<comment><USER25> He hacked the server, not the client.

</comment></comment><comment><USER26> (2001) - (the web page is dated 2017 but adds little to the original news reports of the day, e.g., [https://www.laweekly.com/guerrilla-public-service- the-man-wh...](https://www.laweekly.com/guerrilla-public-service-the-man-who- would-be-caltrans/) and [https://www.latimes.com/archives/la- xpm-2002-may-14-le-pea14...](https://www.latimes.com/archives/la- xpm-2002-may-14-le-pea14-2-story.html))

<comment><USER27> The comments date from 2015, not 2017.

</comment></comment><comment><USER28> The Charging Bull bronze is a piece of guerilla art. NYC towed it away after the artist put it near the New York Stock Exchange. Its current location isn't the original one.

It was a promotion for the artist, who wanted to sell four more of them.

</comment><comment><USER29> With the decline in street traffic and large increase in pedestrian traffic around my neighborhood, I'm thinking about buying a couple of street barricades and putting up "local traffic only - pedestrian right of way" signs.

</comment><comment><USER30> In my experience the transportation authorities care deeply about proper signage, and may have been happy to put up a new sign had he asked (did he?). It's not hard to print one in the machine shop, and definitely would have been less work than what this guy did.

</comment><comment><USER31> I'm glad it worked out in this case. He seemed careful and diligent. If the wrong person did it I could see this leading to people getting hurt (falling off the catwalk) or damage to cars (improper fastening). Overall I love it though.

<comment><USER32> >If the wrong person did it I could see this leading to people getting hurt (falling off the catwalk) or damage to cars (improper fastening)

I really don't like seeing this sort of whatifism whenever a story about somebody doing something that is not their day job comes up. It's amazing it's still considered safe to file your own taxes. The dude had the skills and he did the job and did it well. Hand wringing over what-ifs adds nothing to the discussion.

<comment><USER33> The risks should be discussed in order to discourage copycats. People have died from objects dropped from overpasses.

<comment><USER34> The risks aren't significantly different than from other things people do on a regular basis. People have died from objects falling out of the back of a pickup truck. People have died from a long list of shoddy home improvement projects. People have died (and killed others) from working in an official capacity for the Department of Transportation.

The answer is to do the things that you do safely, not to never do anything.

<comment><USER31> No one was suggesting that nothing should ever be done.

<comment><USER34> Someone was suggesting that we discourage people from doing something because of "risk", and that thing is not significantly more risky than other things people commonly do.

</comment></comment></comment></comment></comment></comment><comment><USER25> Related:

[https://en.m.wikipedia.org/wiki/Tactical_urbanism](https://en.m.wikipedia.org/wiki/Tactical_urbanism)

There's also a guerilla group that fills potholes in Seattle.

</comment><comment><USER35> Not far from me there was an indication to take an exit to get to another highway... but then no indication that you have to exit again to get to that highway. It was a sort of "go here to get there and then you're on your own" sort of sign.

I thought about doing something similar, but only as an amusing thought.

Fortunately they fixed the sign a few months later and gave extra indications where you needed to go.

</comment><comment><USER36> I dunno if this story is authentic...

In high school, a teacher told me about an artist who was applying for a job. The application required three pieces of art. The artist included two pieces of art and a note explaining that the third piece was the postage stamp drawn on the front.

</comment><comment><USER37> These are the best kind of hacks. And it makes me think about the high barriers that end up around fixing things like this. If he had tried to make an appeal to get it fixed through official channels, how long would it have taken? Would it have been fixed?

</comment><comment> y-c-o-m-b I've fantasized about doing this very thing for years!

There's a location here in Oregon that fails to tell motorists of a major traffic merge coming. If you miss the merge, you exit the freeway. Granted it's not difficult to get back on, but there's no way to know this in advance. Prior to the pandemic - at _minimum_ once a month - there would be a traffic incident here because people don't get any warning this merge is coming up so make drastic changes at the last second.

Here's the location on street view. Notice there's nothing indicating a merge is coming on the far right lane: [https://email@example.com,-122.7485804,3a,75y,...](https://email@example.com,-122.7485804,3a,75y,264.53h,84.9t/data=!3m6!1e1!3m4!1sF7hEjMeKbyFey8qK- gSq5g!2e0!7i16384!8i8192)

Once you enter the turn to go right, still no indication of an upcoming merge: [https://email@example.com,-122.7526115,3a,75y,...](https://email@example.com,-122.7526115,3a,75y,316.55h,83.31t/data=!3m6!1e1!3m4!1s9VrfwE5_IfPwIRE3Mijofg!2e0!7i16384!8i8192)

Here's the merge, but notice that it's not until further ahead that you're now being notified the far right lane is an exit lane: [https://firstname.lastname@example.com,-122.7554676,3a,75y,13...](https://firstname.lastname@example.com,-122.7554676,3a,75y,13.91h,65.91t/data=!3m6!1e1!3m4!1s91DvBwi8GWQF4vluqkXppA!2e0!7i16384!8i8192)

Result? A daily traffic nightmare and constant near-death experiences.

EDIT: BTW Google Maps makes it look like you have plenty of time to move from the exit lane and back onto the free-way, but it's an illusion. People are flying at high speeds on the left and you only have several seconds to get into the correct lane.

EDIT: Forgot to mention this funny part. Conversely on the other side of traffic for that same freeway (I-205), they DO make use of adequate signage. Here's one that shows a merge is coming up: [https://firstname.lastname@example.com,-122.749564,3a,75y,52...](https://firstname.lastname@example.com,-122.749564,3a,75y,52.45h,73.62t/data=!3m6!1e1!3m4!1sG_81ikj7rlgw4vDllYczHw!2e0!7i16384!8i8192)

About two miles down, they notify you well ahead of time that the far right lane will be an exit lane: [https://firstname.lastname@example.com,-122.7342592,3a,75y,8...](https://email@example.com,-122.7342592,3a,75y,82.24h,78.57t/data=!3m6!1e1!3m4!1sP5MeCDRt- MmPUMDV5-MARw!2e0!7i16384!8i8192)

<comment><USER38> Reminds me of this onramp to I-376 in Pittsburgh, where you have a stop sign (!) at the bottom of the onramp (!!), which then dumps you into an exit-only lane with a few hundred feet to merge left (!!!):

[https://firstname.lastname@example.com,-79.9328641,3a,75y,6...](https://firstname.lastname@example.com,-79.9328641,3a,75y,61.44h,86.21t/data=!3m6!1e1!3m4!1srgJ- yMNT1jxSMM3esna7_A!2e0!7i16384!8i8192)

I only took this ramp a handful of times before I learned to detour several miles to avoid it...

<comment><USER39> unless I'm missing some important context, the full stop seems like a really bad design choice here. where I live, that sort of entrance would just be marked "no merge area!". in dense traffic, people should probably stop, but in light traffic people could be going a lot faster; it really sucks merging into 65+ mph traffic from a full stop.

<comment><USER32> I suspect the whichever department is responsible for the intersection has some internal rules about where they put what kind of traffic signage and this merging area is too small for a proper merge with a yield sign so they just slapped a stop sign on it knowing full well that most drivers will treat it like a yield it in light traffic conditions.

Of course this causes problems when dutifully law abiding drivers from out of town follow the law to the letter and cause near misses or rear endings because they are behaving unexpectedly compared to normal traffic but that's not the problem of the people who put the sign there. Ignoring these kinds of edge cases and expecting someone else (often the courts) to sort it out on a case by case bases when it causes problems isn't exactly uncommon in government. It's like their version of an unanswered bug report from 2010 with a bunch of "hey I found this by googling and I have the same issue" comments below it.

</comment></comment></comment></comment><comment><USER40> How do we go about getting a bike lane across the Bay Bridge? From Market St to the new section that already has pedestrian access.

<comment><USER41> It's expensive, in the hundreds of millions of dollars: [https://mtc.ca.gov/our-work/plans-projects/bicycle- pedestria...](https://mtc.ca.gov/our-work/plans-projects/bicycle-pedestrian- planning/bay-bridge-west-span-bike-path)

<comment><USER40> It could start with a simple lane closure today, if traffic stays at the current levels.

Thanks for posting the link. Will look for info on how to fund/vote for this project. As mandelbrotwurst said below, it's a small cost to greatly improve mental and physical health.

<comment><USER41> I would love a 'temporary' bike lane like that.

</comment></comment></comment></comment><comment> 1-6 Slipping in code without alerting anyone... Fun!

<comment><USER42> And he did it while it was running in production.

<comment><USER43> [https://www.oddee.com/wp- content/uploads/_media/imgs/article...](https://www.oddee.com/wp- content/uploads/_media/imgs/articles2/a97287_g183_5-fix-flying.jpg)

</comment></comment></comment><comment><USER44> Kind of reminds me of the character of Archibald "Harry" Tuttle from the movie Brazil.

</comment><comment><USER45> It would be so cool if this turned into a movement. Kind of like open source public works.

<comment><USER46> I'm not sure we really want people trying this on their own initiative. This was a very good quality implementation, but most attempts at this would've consisted of a piece of cardboard and some spray paint.</comment></comment>


Idea: Patreon for social entrepreneurs - <AUTHOR> I am evaluating an idea of building a Patreon to help social entrepreneurs get started. They get month-to-month support from early backers. On the other side, entrepreneurs give regular progress update and focus on their venture. Similar to crowdfunding, people backing those entrepreneurs want to help and they actively fight a problem they care about.
While social startups also need to think of their business model, I think they face difficulties raising seed money as their Return on Investments sound less promising than typical tech startups. This idea could empower more social entrepreneurs to have a greater impact and not give up.
What are your thoughts on this idea? If you're a social entrepreneur, I would be very interested in your project and understanding how I can better help you do good! <comment><USER2> It sounds like you want to replace Patreon with Patreon.</comment>


Your pprof is showing - <AUTHOR> http://mmcloughlin.com/posts/your-pprof-is-showing <comment><USER2> The source code is not embedded in the binary! go tool pprof has to have access to the source code in order to print the source code. The binaries only contain source code coordinates for symbols.

<comment><AUTHOR> Thanks for pointing out the mistake. I will update the post accordingly.

I still think there are some valuable lessons here.

<comment><USER2> Yeah, this is a total footgun.</comment></comment></comment>


Ellison says Oracle eats own dogfood for cloud apps - <AUTHOR> http://www.theregister.co.uk/2012/10/03/ellison_oracle_cloud_dogfood/

<comment><USER2> He's probably lying. Amazon was for years.</comment>


Abel's Theorem in Problems and Solutions (2004) [pdf] - <AUTHOR> http://www.maths.ed.ac.uk/~v1ranick/papers/abel.pdf <comment><USER2> Note that from the preface these notes are based on a half year high school course. The high school certainly was a specialized math high school. Soviet education was superb.

I've perused the notes and they heavily rely on problem solving to learn the material. It seems like a Moore method style of exposition which I really like. Arnold is a master of mathematical writing and teaching.

We no longer teach the formulas for solving cubic and quartic polynomial equations. Nowadays we just teach linear and quadratic equations. For the most part every algebraic equation you can solve by hand that we teach in basic algebra is an equation that can be reduced to a linear equation or a quadratic equation. It's amazing how many applied problems can be accomplished by this reduction. With the rise of computers and easy numerical computations this isn't so important but imagine a scenario in which the useful applications all involved degree 5 or higher polynomials. Would we have progressed much?

<comment><USER3> > _imagine a scenario in which the useful applications all involved degree 5 > or higher polynomials. Would we have progressed much?_

You can always approximate a polynomial around a point with a lower-degree polynomial. They will only diverge farther out. As a result whenever physics produces a high-degree polynomial we can inspect certain behaviors in a lower degree. This doesn't help with every case, but it does enough for the situation that many questions become answerable.

<comment><USER2> Oh definitely. Thinking it about it more it's clear that part of my comment was I'll thought out. I was attempting to wonder if mathematics would have developed enough theory behind it in a universe in which low degree polynomials were difficult to solve or in which most applicable problems involved high degree polynomials. I think the answer is yes.

<comment><USER4> _I'll thought out_ = ill thought out

You must be posting from a phone.

#damnauto-corrupt

<comment><USER2> I am! Thanks for catching that mistake.</comment></comment></comment></comment></comment>