steelbrain

Unlikely. They need the port for more than just the charging. Ever had a botched iOS update? You need that port to reset the iPhone

This looks too complicated, I prefer the simpler solution: tj/n (https://github.com/tj/n)

Installed using n-install (https://github.com/mklement0/n-install)

I am confused, is this piece making fun of Floppy disks or just documenting a fact?

If it's the former, I'd discourage the criticism because Floppy disks are working, and there's no good reason to redo the whole thing and potentially create a lot of bugs, that you'll then spend a wormhole amount of money fixing.

Change for the sake of change is a bad idea. Especially for equipment that has to be ultra-reliable.

1 - Never versions are not always more secure or more stable

2 - Not everyone who has the bandwidth to write something also has the bandwidth to rewrite very often just to keep using the latest and greatest APIs

and then you need extra engineering and production costs to cool those resistors :)

Putting a spin of whataboutism doesn’t make the OPs arguments any less valid

Maybe the game keeps them around so you can buy them back?

Can you please explain how you got to that conclusion?

I don't understand this way of thinking. Rust isn't magically fast. You can use most languages to write both performant and lazy code.

Also just so you know, Brave isn't "written" in Rust alone, it is a big software with a lot of parts, including but not limited to a rendering engine, a JS VM and a WASM engine.

The Rust part at most (unconfirmed) would be the glue that connects them together, and I doubt that's where the bottleneck is for most browsers.

Node.js has builtin HttpV2 support but no v3 support IIRC. Which is not a deal breaker because any production app should already have a load balancer/proxy in front of it, which do have QUIC support.

I don’t understand. There are entire nations (eg. Pakistan, Bangladesh) where meat is a delicacy and Rice and Wheat is what feeds the masses, the obesity ratio I’ve personally observed is nowhere near the US.

See also: https://www.hotelwifitest.com/

Although from personal experience, data on Hotel Wifi Test is often not reliable, at least for Dubai

The link seems incorrect. I think you meant to link it to

https://mobile.abc.net.au/news/2020-09-03/the-mystery-of-the... instead of

https://mobile.abc.net.au/news/?pfmredir=sm

Lookup the Kobo eReader

Edit: I see a neighbour and I had the same idea

> Pretty sure it will not. Nothing is lazy in JS by default:

It really depends on the logic written. You can solve the same thing in many different ways, the way chosen by the author doesn't seem to be a lazy one.

Not the language's fault. It's simply doing what is asked of it.

Eg, see https://news.ycombinator.com/item?id=24265507

Great idea! Couple of things I would change here:

- Instead of modifying prototype, which would pollute the environment for any other modules to work with - use regular old functions

- Instead of spreading the iterable to an array and then calling `.forEach` on it, I would just iterate the source generator directly, it would look like:

    for (const node of xpath(el, 'xpath')) {
      node.textContent = node.textContent.replace("Hello", "Greetings")
    }

Before Air travel became the norm, people used to travel by water, and unless you know how to swim, you may drown for whatever reason.

The educational institutions didn't want all that effort wasted so they started requiring swimming education for people.

Or something like that, don't quote me haha

Ex put.io customer, I downloaded a bunch of media to consume over a flight, except their App would not let me watch already-downloaded videos offline on a plane.

What part of their reply indicated they did not?

Source?

Author of `linter` / `linter-ui-default` here. The package in no place in its code rewrites the entire Atom package configuration. It does however observe it's own configuration. If observing in itself resets the Atom config, then it's out of the hands of the package and a bug in Atom core.

It's possible that one of the linter providers had that issue, and since Linter providers are only called by the linter package, they wouldn't exhibit the issue on their own. It's not uncommon to have issues that seem like it's the linter's fault since all of the providers do nothing and seem harmless unless invoked by the linter package.

I would've helped to debug this, had somebody pinged me on any of the issues. Oh well :)