throwbsidbdk

Or just pull my old Ubuntu box out of the closet. No webcam, no mic, no problem.

Still, this is hilarious because only the truly desperate will put up with this crap, everyone else will just get their jobs somewhere else.

I can see why they might do this, anyone that can land a job with similar benefits somewhere else probably doesn't even apply, leaving them with the worst to choose from. Their climate gets even tougher because they "can't hire enough good engineers" and the cycle repeats.

Whatever happened to progressive jpg? You can get graceful degradation for free by just encoding your images that way

Maybe I was a hit too excited about the perl part. Perl perfected regex and the perl regex engine was integrated into other languages until it became a normal language feature.

Regex as we know it was largely a result of the adoption of perl and the flexibility of its regex engine

I think node is the funniest example. "Yay we can run js on the server now! This is the future!"

But wait, what other language can't you run on the server? I can't think of a popular language in existence before js to take so damn long just to have a web interface. It took js ten years! Even rust has a web server and it just hit 1.0. Oh and node is still single threaded, something horrific for servers that usually have 16+ cores.

I'm in the opposite camp, it feels like js is mutating quickly to try to fix the rediculous problems with the language because people are forced to use it.

You don't see such sweeping changes in other languages that have been around much longer and used more widely than js.

JavaScript just got a package manager, the module system was hacked on a few years ago and still isn't standardized, the build tools change every other year and still largely suck, it still doesn't support multithreading, the object system is super wonky, it doesn't support specific float/integers which seems to break math constantly. None of these things are an issue in any other language I can think of, these features are in language V1.0

I expect developers to jump ship immediately when a replacement without these core problems reaches critical mass.

Google has been looking into this for a while, and Dart was designed with the assumption that JavaScript fundamentally sucks and can't be fixed.

This has happened before... Look what happened the perl when Python started to gain steam. It used to be pretty much the #1 way to write websites, now you would be a fool to use perl over Python on almost anything.

I donno man, the longer I use typed languages the more I hate untyped ones, if only for the IDE help alone.

All the newer static languages use type inference anyways so its not that common to need to specify explicitly.

Besides, if you want to turn off the type system you can just cast to object or use "any" in the case of typescript.

JavaScript's untyped insanity is also the main reason it's around 10x slower than c# or Java.

Again js is a familiar example, but untyped "numbers" are HELL if you're trying to do any real math or implement a mathematical algorithm. I decided against porting one of my libs to JS for that reason alone.

A lot to lose and nothing to gain with dynamic typing.

I see the proliferation of JavaScript tools as a massive failure of the vanilla js standard library and ECMA. Most of the stuff out there just rebuilds basic language features that would be standard in other languages.

We wouldn't need node, npm, typescript, angular, react, web pack, or most of the bazillions of libraries out there if vanilla js had reasonable defaults.

It's causing horrid fragmentations probably won't go away until js is replaced maybe 5 years down the road.

The best we can hope for is a c++ style solution. A new language that's basically a massive preprocessor on top of the original that fixes as much as possible. My hope is in typescript for now

Fun factoid most have forgotten: regex is perl. The beginnings are elsewhere but regex as we know it was designed as part of the language and the engine was pulled out and reused when people found how useful it was.

Perls regex parser is still far above the features in more modern languages, supporting, among other things, code execution within capture groups. If I remember right the perl regex parser is actually Turing complete

I have heard whispers of this, and the mention of common on call hours seems to lend it some credibility

The failure mode doesn't matter much in practice. You need to track how many inserts you've done on both for practical reasons so with either you'll have a set cutoff before rebuild. Cuckoo filters are more likely to be used in place of counting bloom filters than vanilla ones.

You could always avoid duplicate inserts in cuckoo by checking contains before calling insert again. A modified insert-only-once routine would only have a small performance penalty. You can't use counting or deletion while doing this though, so its a trade-off. This same trade-off happens with counting bloom filters but they are much less space efficient.

Practically the use case for cuckoo filters over bloom probably lies in bi directional communication. Partner nodes can keep each other's state updated without needing to exchange a ton of data. Think distributed caches. So two data nodes exchange cuckoo filters of each other's data initially. As things fall out of their caches they can tell each other to delete those items from each other's filters by sending only the bucket index and fingerprint. Probably much smaller than the piece of data that represented originally. Since each data node independently knows what was in their cache there's no risk of false deletions. You can't really use bloom filters for this because you can't delete

What makes these so easy to detect that they're this secretive about it? There has to be obvious clues in the TCP/IP stack. 4g modems are opaque and proprietary so it's unlikely the fear of discovery lies there.

If I had to guess, they're probably detectable from TCP/IP, easily, in user land.

How? Just thinking about it, fragmented packets could be a possibility. If fragments are sent in the wrong order you need to reassemble them to find the proper destination. This requires keeping a fragment state table on the device doing the transparent forwarding. I've seen many transparent proxies that just drop these packets instead.

The net effect is much larger than the smallish overall effect appears to be. The request is much smaller and this has a surprisingly large effect because modern consumer connections are asymmetrical as much as 20/1. Those requests take 5-20 times as long per byte to send over the wire. Shrinking them this much decreases total request -> response time a lot more than it looks

Http was not designed for what we're using it for. The biggest problem is numerous requests, which is caused by http using TCP underneath, not by multiple requests in themselves being bad.

Bundling is not a best practice because anything about it is inherently better. It's only better because http is bad at delivering multiple responses efficiently.

I think HTTP/2 is a quite reasonable compromise compared to the ideal, which would be scrapping http and starting over. The biggest change is to multiplex requests over a single TCP socket, something that's been done by many other protocols over the years. The added complexity is needed because the alternative, running modified http over UDP, would break so much of our infrastructure that it's implausible.

To add to this, you can buy GPS time source dongles really cheap and in Linux it's not too hard to run one as a parallel/backup time source.

Especially when using distributed databases where write priority is determined by timestamp, someone wrecking havoc with your time source could bring down the database

My biggest issue with NTP is little control over who runs the servers. Unlike the CA system that has checks in place against bad actors, practically anyone can run an NTP pool.

It was discovered a while ago for example that some part of the Linux default NTP servers are run by shodan. So when your machine gets the time it lets shodan know you've got a server running so they can port scan you.

It would be stupid not to run a bunch of NTP servers if you wanted a to run a bot net. A free list of every running Linux server and countless IoT devices! Without having to actively scan IP space at all

Have you looked at Siphash? I remember reading recently that murmur has been found to have some predictable hashes independent of salts but a lot of big names still use it since it's fast and has good properties.

Okay thanks, that explains the why but doesn't make it sound less terrible. They essentially built a nosql database on top of MySQL. Forgivable years ago but this was in 2014...

Just noticed this article is 3 yrs old which is probably why some of the advice seems out of date. Needs a section on http2/spdy

I didn't know Erlang had been around that long, I've only seen it pop up within the last few years

Nothing hard but the various leaks of diplomatic cables and spy tools have made claims of state sponsored hacking undeniable. Everyone knows that all the big companies are getting hacked all the time thanks to the leaks.

How is a technical failure worse than a hack? One implies incompetence on your part, the other that you were attacked.

It's gotta be the case. Probably choose trip db based on cutting map into squares or hexagons. Dump all location data from drivers and riders into it real time. Sounds like they've got batch jobs running against these databases to discover surge areas and stuff. Probably designed to only hit only 1-2 databases at a time for calculations they do a lot.

This really looks like a crap design overall for a company started well in the age of nosql and stream processing.

>The entire trip store, which receives millions of trips every day, now runs on Dockerized MySQL databases together with other stores

It really does sound like this is part of the issue. Millions of trips is billions of db row per day. A document store is much more amenable to that kind of workload than MySQL

Is it not cool to call these things worker threads anymore?

Nothing wrong with the article but I'm getting annoyed by the trend to rename constructs and common patterns in new languages. Wasting time learning about Y in language B only to realize that it's exactly the same as Z in language A which you already knew

It sounds like Uber has a database cluster for roughly every employee?!! Uber has a single product that largely centers around 1 app. How can this be necessary?

I have a feeling... That they're dumping realtime GPS data into a bunch of these when they should be using something like Cassandra...

True. Even very successful database projects in Java have some issues with GC pauses.

Go seems to be, IMO, taking the things Java is best at and trying to make something better. Basically, how would you build Java today if you could do it again?

Companies have always shifted blame. I think there's just less disadvantage to admitting you were hacked than there used to be.

Companies used to keep that stuff under wraps to avoid looking weak, but it's so common now that it doesn't really hurt your brand to say it.

The truth will come out pretty quickly, anyone doing transit or peering can see any attack happen

Verilog does exactly this. You design the logic than simulate all the gates. I'm sure there's some open cores out there ready for simulation if someone wants to fiddle with it

Http2 fixes the speed issue and generally requires HTTPS, Eventually all http will be encrypted.

Unfortunately some big names are dragging their feet implelenting http2 in servers, even though most clients already support it.

Web based? Some things to read about:

Web - Rest services and token based authentication. Spa frontend driven by JSON APIs seems to be the most popular way to go.

Database - Cassandra is probably the closest to industry standard

Scaling servers - docker, kubernetes. I'm honestly not that familiar with this topic.

"Big data" processing - Apache zookeeper, hadoop, Apache spark and storm.

Data brokers - Kafka, rabbitmq

Document storage - ceph, lucune based solutions like some/elastic

I would also read about non-http messaging protocols like Google's protobufs, Apache arvo and the like. These protocols are preferable over http based protocol for exchanging data at scale because more efficient, simpler, and less processing overhead.