Exactly my thoughts. I don't understand whether I'm really spoiled, or is the crowd here weird about upgrading for some reason - if you have a laptop from 4-5 years ago, the new one would be 2-5x faster in vast majority of things - even if not critical for your workflow, it would feel SO MUCH nicer - so if it's something you use for 100h / week, shouldn't you try to make it as enjoyable as reasonably possible?
Other example - I'm by no means rich, but I have a $300 mechanical keyboard - it doesn't make me type faster and it doesn't have additional functionality to a regular $30 Logitech one - but typing on it feels so nice and I spend so much of my life doing it, that to me it's completely justified and needed to have this one then.
That’s a feature, not a bug, for some. When I upgraded to an M series chip MacBook, I had to turn up the heat because I no longer had my mini space heater.
The article isn't about solving those problems, it's about taking a few days longer to do the actual travel to save a bunch of money, since there's already massive delays on either end.
No, the article is saying "actually I was wrong about being longer and slotting in between airplane and cargo ship; we can be as fast as planes, but cheaper, and take a big slice of that whole huge market". Which is why they need to explain why airships won't also have customs etc.
We recreated this experiment in one of my university physics classes. It was a lot of work, and our results weren't nearly as good, but it was instructive and interesting. The equipment requirements were completely reasonable for an undergrad physics lab. I highly recommend giving it a try if you can.
> Usually not. You can ask your provider for a new number in a different city and they will issue it. Most Canadian providers are country-wide so you don't need to switch provide if you don't want to.
There's a way around this that I've done a few times. You port the number to VOIP (I use voip.ms) and then you set up that number to forward to whatever the new number you get given. Dialing out you still get your new number, but people dialing you can use the old number.
This was super handy when I had to move my mom from a retirement home in one city to another city a province away.
Spine is fantastic for artists, and it's integrations with various engines is really good. My biggest complaint about it is that it's very CPU heavy. A spine runtime that has less features but uses GPU skinning would be excellent, especially if it runs on the web. Ages ago I had to write a JS shim to the C runtime compiled to WASM and it worked well, but I still wish it used a lot more GPU and less CPU.
The skinning could be done GPU side but with caveats: the number of bones that can influence a vertex would be limited and matrix palettes might have to be split up, inducing multiple draw calls. There actually was a GPU skinner at some point iirc, and the load for common example skeletons was pretty much the same sadly.
It's being used by a lot of companies with WebGL tech stacks mostly deployed on low-powered slot machines. Quite a few web games in the Asian market also use it. However, three.js likely won't add anything for a 2D game. You'd be better served with Phaser or PixiJS (which is the industry standard in slot games it seems).
What if we stopped adding layers of abstraction? The idea of renderer-agnostic shaders is cool, but in general you want to write your shaders for a specific renderer for best performance.
If you're writing for three.js and GLSL you've already forgone best performance. This is for render agnostic web code - it could be running on anything from a low end android tablet to a gaming PC, in any browser engine new enough to support WebGL. Most developers who use it are looking for a usable API that works everywhere possible, and they don't really care that much about perf because it'll be faster than all the alternatives (JS, canvas, SVG, CSS) even if it's pretty slow for a GPU.
If the alternative is to manually maintain 2..10 (or so) versions of each shader for different shading languages, GLSL versions or shader variations manually, then code generation or transpilation from a common source is a pretty good compromise.
I'm kind of surprised that washing machines don't have that sort of filter already. I recently cleaned out two of the filters in my own washing machine and it did a pretty decent job catching a lot of things. I guess because it's so fine it would have to be cleaned out more?
You'd want a lot of pre-filters to catch bigger lint. And those pre-filters will need to be readily accessible for the user to clean out. And you'd want a system for detecting the filter is full to warn the user. Otherwise you're looking at a lot of unhappy people as their washing machine fails to drain a lot of the time as things clog up with lint.
I'm disappointed that the names aren't released already, but I'm glad that something's being done. Greenwashing is wildly annoying and always takes ages to investigate properly.
I daily drive the Keyboardio Model 100. I like it a lot, but I really would like to remap a few of the special characters. It works fantastically well for just arbitrary documents, but writing C++ is frustrating. The custom shape of all the keycaps makes it basically impossible to remap without just using clear keycaps.
