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