throwasehasdwi

Same thing eh?

Uh no, Google is an advertising company. You know the terrible full page creepy ads taking over mobile that make the internet almost unusable and you can't block? Google is responsible for that.

With Google Jobs you're the product to be sold. Only this time it's not annoying ad's, they're offering your employment for sale, your life.

How long will it be until employers can look up all the information Google has about me? More importantly, how long will it be until users will be expected to give access to their "likes, skills, and interests" for targeted recruiting? At least LinkedIn is easy enough to keep separate from the rest of my life. Google knows everything about me.

Eh, acetone smells gross but I can understand why they weren't too concerned about it. It's one of the strongest solvents out there that's actually fairly safe biologically. It's really volatile and humans can smell it down to a couple dozon PPM. Not a pleasant olfactory combination. However, your body produces it in small amounts so you can readily detoxify it.

When given a choice between various mostly dangerous solvents, I Choose Acetone™

There's plenty of categories of products where the difference between high and low quality is nebulous, wine being maybe the most famous example. But beats is not one of them.

Holding them up to another $200 pair of headphones and listening to them side by side makes the difference obvious. The case molding is poor quality, lacks removable fasteners that make most expensive headphones repairable, and the leather isn't as soft. They don't get as loud as headphones with nice drivers. These things are obvious to anyone that tries them out.

The only thing Beats has going is the branding image of Dr Dre and now Apple. They're trendy and its the only reason they sell, besides that they're crap in almost every way.

Things might be better now that Apple owns the brand, as I haven't held a pair in a while.

beats are built REALLY badly, look at any of the teardowns. They also use garbage no-name drivers that are identical to what you get in $20 headphones, again look at the teardowns.

Most devices still encode and decode far more H264 and JPEG than newer generations. We shouldn't be stuck with the horse and buggy because we're waiting for cars to be autonomous. WebP is superior to JPEG and the most widely available alternative.

Isn't this just doing the same exact thing as iptables only worse since it's not transparent to the operating system?

I've created bad firewall rules by mistake many times and enforcing them transparently so the machines can't see them makes the issue almost impossible to debug and fix.

Of course I have the same gripe with AWS VPC setups I guess... I just think it's funny how the cloud keeps reinventing cloud versions of things that perform objectively worse than the original, but then everyone still uses them out of pure convenience or stupidity.

Nokia owns several HEVC patents, in fact I think they're currently suing apple about it. This is a veiled attempt to get everyone to use their patented tech so we can relive the mp3/mp4 clusterfuck. You would be a fool to use this for anything.

What's so bad about WebP? It's not the best thing in the universe but it beats JPEG and PNG and has a wide support base. With a shim it has native support in most browsers anyways since WebP is a just a single frame of video. And as a bonus you don't have to worry about someone suing you for royalties down the road.

Lead levels are only elevated in certain areas. Getting clean water might be as easy as your neighbor's hose. Flint authorities weren't treating the water properly and it corroded the pipes in some areas. Lead levels were expected to drop as soon as treatment resumed but it spooked everyone bad enough that it doesn't matter if the water is safe, they want new pipes. Lead pipes are not unusual at all in older cities and nobody else has this problem.

I don't see how a single small city whose water supply was tainted by incompetence of local water utilities is representative of the US as a whole. 99.99% of us have access to drinkable water.

They might look terrible but the utilities work. Biggest differentiator in 3rd world is poverty AND non functioning government.

The water, sewer, and electricity work well enough to be relied upon even in the poorest most remote parts of the US. This is not so in any 3rd world country

I second this. Powershell syntax is almost as bad as Bash. I have no idea why they didn't just make a command-line version of C#, it's a far better designed language.

Scala has the same problem as java. Too many different opinions on how to do things. Too much cruft and ways to shoot yourself.

I see Kotlin as a clean-up job of a lot of syntax design flaws in java.

JetBrians is possibly the best company on the planet to implement syntax improvements to Java, which is basically what Kotlin is.

They have deep experience with the syntax of a bunch of different languages. They know what Java is missing because they've seen a ton of different things in diverse languages.

Looking at Kotlin myself, they got rid of almost all of the painful syntactical blunders in Java. I'm seriously considering picking it up for my next project just looking at their main page. It looks fantastic.

If you disagree with javascript losing dominance I guess you could say so. It's really just a way to make it easy to run whatever language you want in the browser in a cross-platform compatible way. I don't see this as a bad thing at all.

Java applets were far too ahead of their time. Now that we actually have the bandwidth and computing power to support Applets they would be far superior than the Frankenstein of CSS, JS, and HTML we have now.

It's not the overall objective but that's exactly the objective of a lot of people rooting for it. Think of how many people would be pissed off if they said "we're gonna try to replace javascript". Google did that with Dart and everyone gave them the finger... sunk cost fallacy.

Better to develop something for "performance" that just happens to be able to replace JS as a side benefit. Makes it a lot easier to swallow

You might be right about C++/Rust but I hear constant complaints from C#, Java, and Go devs about JS. It feels like about half of them would jump ship immediately given another choice. The truth is that even with all the advancements JS has made the tooling and features are still years behind some other mainstream languages.

The transpilers don't work that great and don't produce standard bytecode, in this regard WASM will be a game changer.

Yes. CoDel/AQM can only help bufferbloat if you control the bottleneck. However it's possible to artificially make your router the bottleneck if you get really steady bandwidth.

BBR only helps TCP but will help prevent bufferbloat along the whole path

right you are! My apologies, my familiarly with CoDel is limited to the Linux implementation

Realistically, as soon as WASM is a good alternative to JS a good part of websites won't use a single line of JS.

Regardless of arguments for and against whether this is a good idea, market pressure to open floodgates to other languages will be far too high to ignore.

My prediction is that WASM will quickly evolve into a new way to containerize applications, very close to a full-fledged VM/OS. The market constantly demands more features and faster execution. The only logical conclusion is that the web browser will become an operating system.

The generalish difference between JS and native code languages like C is about 10X. This varies from around 2X to 50X depending highly on what you're doing.

WASM should run at native speeds minus some special CPU instructions like vector stuff. So about as fast as highly optimized bytecode languages like Java, maybe 20% slower than optimized C.

CoDel is packet scheduling. It just dynamically creates "classes" for each flow to determine which ones are overfilling the buckets and selectively drops from those streams.

I try to talk about these things in a way that's easy for lay people to understand. Even among programmers QoS and packet scheduling are a niche topic

It's not trolling. It's a legitimate warning and they can choose to ignore the chorus to their own peril. The warnings get louder as they get more resistant to changing their name. Keeping the name for whatever reason IS going to cost them enterprise customers

you just cover them with a CSRF token embedded in page like ye olde days :)

JWT docs aren't accurate. Also why not just store JWT in the cookie? It's pretty trivial to use JWT in a cookie and do a sliding refresh on server side when its close to expiring. You can use JWT this way with zero code on the client.

Same with the "Random Token". You can easily just shove a secure random ID in a session cookie and use it. Doesn't pretty much every framework support this?

This docs is... not accurate for most of these.

By default, Windows machines use the algorithm NewReno. Older algorithms like NewReno are known for causing horrible buffer-bloat in comparison to algorithms like VEGAS which is used in Linux. The reason is pretty simple. The two main metrics used for determining when to send a packet in TCP are round trip delay and packet loss.

Reno/NewReno slow their send rate mainly when they detect lost packets, whereas VEGAS and similar mainly detect round trip delay but also respond to loss. The problem with primarily loss-based strategies is that most routers won't drop packets until their buffers are full. In modern times these buffers can be very large (many seconds). TCP Reno will keep sending packets until downstream routers have full buffers and drop packets, which could be when they're already holding seconds worth of data. This is buffer-bloat. Any packets that makes it to these routers will spend seconds waiting to be put on the wire.

VEGAS on the other hand will try to maintain a constant round trip delay. It uses TCP's ACK packets to gauge how long it takes packets to go back and forth and reduces send rate when this starts to rise. This keeps router buffers empty, delay low, and packet loss near zero. BBR is a further enhancement of the VEGAS delay sensing strategy.

As mentioned in this chain, CoDel is one strategy for "fixing' loss based aggressive protocols like TCP Reno. It detects "flows" (IP/port pair combinations) that are causing the local outbound buffers to overflow and starts selectively dropping packets on them. If all internet protocols were delay based like TCP VEGAS CoDel would not be needed to keep traffic flows "fair". Without using something like CoDel on your routers to punish aggressive strategies, scheduling algorithms like NewReno will cause your routers outgoing buffers to always be full and out-compete friendlier traffic like VEGAS that cuts itself back when buffers fill.

They are different beasts :), and yes it's very important to understand both because they work in different ways.

Most people that know of CoDel think it's a panacea for buffer-bloat on their LAN but BBR is actually much more likely to be effective. The important distinction is that CoDel only prevents buffer-bloat on the hop where it's running. CoDel manipulates packet order in outgoing local buffers to signal the congestion control protocols at higher levels such as TCP that buffers are overflowing. The drawback of CoDel is that it only works if your router is the slowest link.

If the bottleneck link is on your modem (most are), CoDel will only help if you artificially make your router the slowest link by limiting outgoing bandwidth to slightly lower than your modem upload speed. In practice most people don't know to do this.

BBR in comparison reduces buffer-bloat along the entire path of the packet, but has its own disadvantages. First, it only works on TCP connections. Second, it helps the most if machines on both ends are using it. Each end of the TCP connection uses its own congestion control. Thirdly, it can only be applied at a machine level. If you put CoDel on your slowest link it will help all the traffic going through it, but only if the bottleneck is at that link. BBR will help prevent bufferbloat from end-to-end through all links a TCP connection flows, but only prevents TCP buffer-bloat completely on your router if every machine on the LAN is using it.

Ideally you want to use both in every place you can.

CoDel is different from the packet scheduling algorithm even though both fight bufferbloat in different ways. CoDel is a congestion control algorithm for controlling what happens when outgoing buffers start overflowing. This is on a lower level than TCP and happens to any type of packet. The scheduling algorithm, like VEGAS or BBR, controls the transmit rate of only the TCP protocol.

When packets are being sent over the wires, the TCP scheduling algorithm (usually CUBIC, VEGAS, RENO, or now BBR) will send out packets until the parameters they monitor indicate the downstream device is about to overload. Then they will back off slightly to prevent packets from being lost. These TCP transmit strategies tend to either monitor packet loss rate or round trip time, sometimes both. What they do with these two parameters determines the biggest differences between the packet sending algorithms.

CODEL comes into affect when the scheduling algorithm decides it can't send out packets quickly enough without losing them, and they build up on local buffers. This can happen with TCP but also other internet protocols.

Something most people don't know is that without a scheduling algorithm like BBR,VEGAS, or RENO, you can send out packets at interface speed. In simpler protocols like UDP you need to do your own packet scheduling. Otherwise your machine will send out packets at interface speed until they are mostly dropped by the first slower link. This is why TCP has scheduling algorithms, they're all an attempt to monitoring the end to end link speed from A to B you can achieve without losing data.

Edit: BBR is a new TCP scheduling algorithm to fight buffer-bloat at the TCP level. Since the majority of internet traffic is TCP, wide adoption would cause a big improvement. TCP scheduling only affects outgoing packets, so its important to get this into Windows and Linux so we can get the full benefit of having buffer-bloat reduction on both ends. I'm looking at MS here because they're the last major OS running an aggressive and buffer-bloat causing TCP algorithm.

Everyone has been waiting for newer Java versions forever. The companies on the community board keep waffling around and trying to add more bloat to a spec that's already wildly late.