I mean, as someone who was in that situation as a customer, we couldn't find a great cloud option for our needs, and we ended up building our first hardware lab with a bunch of macs.
It definitely caused us to buy macs we would have rented and shared.
Correct, us as well, but we’re mainly harvesting refurbished Mac Mini’s.
My biggest problem is the lack of a good CI/CD flow when you can’t work with images and virtual machines. We’re using ansible now to manage the fleet and I’m not a fan.
If they would more than 2 VMs, we’d still buy the hardware, we’d just buy larger ones and have more virtual machines on them. Very likely also use Linux as the host.
I hope one day Apple sees the light like Microsoft also did, but I’m not hopeful.
A big part of the reason is that Orion (and Apollo) reentry speeds are way higher due to the orbital mechanics involved in going to the moon and back. Today's was actually the fastest manned reentry ever attempted.
For reference the shuttle generally reentered at ~17.5K mph, and today's was 24K-25K mph.
It's not clear that we could build a craft with wings that could survive that. So then you're looking at adding fuel just to slow down, plus fuel for the weight of the wings themselves, plus fuel to carry all this extra fuel to the right place, etc.
Since these speeds are hard to grasp: That's about 416 miles a minute, or 7 miles a second. It traveled a mile in about the time it takes for a person to blink.
What would prevent them from entering into an orbit around Earth for a day or so and use that to slow down? Is that possible and would that make the reentry less risky?
Possible, but far too expensive due to the all of the fuel that would have to be carried the entire way and back. Expensive in a monetary sense, absolutely, but also in the sense that much less mass would be available for every other component of the mission.
Why not a simple switch, not unlike on SD cards (but implemented on the device, not host/reader, and enforced by said device)?
Though yes, two USB ports would definitely work; it's just that the concept might be better served by providing two different connectors (e.g. USB-A & USB-C), as is common nowadays.
> Prior to the industrial revolution, the natural world was nearly infinitely abundant. We simply weren't efficient enough to fully exploit it. That meant that it was fine for things like property and the commons to be poorly defined. If all of us can go hunting in the woods and yet there is still game to be found, then there's no compelling reason to define and litigate who "owns" those woods.
I mean, medieval Europe (speaking broadly) had pretty well defined property rights wrt hunting. In fact, the forester at the time was thought of as one of the most corrupt jobs, as they'd commonly have side hustles poaching and otherwise illegally extracting resources from the lands they enforced and kept others from utilizing in a similar way. Quis custodiet ipsos custodes?
Firefox's non-reasons are just as lame as Apple's non-reasons. These APIs aren't security risks, the user has to explicitly opt-in on every website that requests USB access, just like every other privacy-risky API that a website requests, like microphone and camera access. WebUSB is no different.
The only thing that has changed since camera and microphone access was allowed is that Apple now considers web apps to cut into their app store business, so they are unwilling to let any new APIs get approved that would make a web app as capable as a native app. This includes WebBluetooth and other APIs.
Apple is also getting sued by the DOJ for exactly this type of shady business practice.
And I don't really think what Firefox says is relevant, they are so cash-strapped I would not doubt that Apple pays them to have a negative opinion about new web APIs just so people like you can say "Firefox doesn't want it either".
The truth is there is no good reason to block WebUSB and WebBluetooth from becoming standards.
The user gets spammed with a million permissions popups a day and has no idea what they are actually accepting or what the risks are. The same looking permissions popup usually means something incredibly trivial like notifications or camera, while the webusb spec is exposing you to potentially high risks of damage to hardware or data theft.
>The user gets spammed with a million permissions popups a day and has no idea what they are actually accepting or what the risks are.
"A million" is quite the hyperbole. So let's just not do anything anymore because it might cause a permission popup? Or because some idiot might trust a scam website? That's your argument? Sorry, it's not a good argument.
>while the webusb spec is exposing you to potentially high risks of damage to hardware or data theft.
Please explain a realistic scenario where a website >that someone trusts< is going to "damage hardware or cause data theft".
I'll wait.
I don't care about someone's stupid grandfather that is going to find a way to get hacked one way or another - he's not a good reason to hold the rest of us back.
That’s the source of the issue. Apple sells products that are safe for someone’s stupid grandfather. WebUSB is not safe for people who don’t understand the implications. Which is most people.
>Apple sells products that are safe for someone’s stupid grandfather.
Then then they should be selling it in "grandfather mode". The rest of the non-stupid people that have iPhones (there are non-stupid people with iPhones, aren't there?) should be able to do what they want with their devices. But they can't because Apple puts profit over progress.
>The rest can choose a different browser.
Except on iOS you can't choose a different browser. Apple has blocked all other browsers on their mobile platform, so if you try to install Chrome, you're really just getting a Safari webview with a wrapper around it. It's just another example of abusive business tactics that the DOJ is suing Apple for.
On iOS you can’t use usb anyway. Even an actual app can’t use usb outside of the wrapper APIs for file access and stuff. So it doesn’t really matter what safari supports here. And on macOS you can use any browser you want.
As of July 7, 2024 the Gutenprint project has formally deprecated MacOS support. This means that no further MacOS-compatible binaries will be produced.
Gutenprint has not had an active MacOS maintainer for over three years, and the remaining developers lack the technical ability to produce MacOS binaries, much less undertake the substantial amount of work necessary to produce, test, and support binaries on newer (post-Mojave/10.14) MacOS releases.
It looks like it's just because they had no way to test, and bandwidth to deal with it. But should still mostly work, once whatever issue (that sounds like app notrization) is fixed.
It seems like the better option would have been to fix whatever was blocking them just two years ago, rather than this wild rube goldberg machine of a Linux VM emulated in a browser tab.
I mean, anyone is welcome to do just that! But I guess coding Rube Goldberg machines in JS (to push the boundaries of the web) is a thing I really kind of enjoy.
I mean, the core issue here is that proper engineering just isn't valued.
Social capital just isn't given out to people that fix things in a lot of these companies, but instead those who ship a 1.0a.
On the management/product side, the inevitable issues are problem for another quarter. On the engineering side, it's a problem for the poor shmucks who didn't get to jump to the next big thing.
Neither of those groups instructionally care about the mess they leave in their wake, and such guardrails they'd perceive as antithetical to releasing the next broken but new, fancy feature.
It definitely caused us to buy macs we would have rented and shared.
reply