I think in common usage, people expect an "emulator" to be a more sandboxed translation layer than Wine, for example, provides.
e.g. it's probably a security vuln if loading a Game Boy ROM reads arbitrary paths on your local filesystem determined by the ROM's code, not so much with Wine.
Someone made a cute demonstration that I think usefully encapsulates this a while ago. [1]
Mostly because the Gameboy doesn't have any IO register to reformat your hard disk. If the emulator interpreted some instruction as reformatting your hard disk, that would be a bug because it's not interpreting it as whatever it actually does on a real Gameboy.
Red Hat most memorably has tried it with "technically you are legally permitted to distribute these things we are giving you under contract but we will terminate your contract if you do."
Normalization of deviance, soft power, and the fact that managing up and managing down are not the same skillset.
Delegating authority is a velocity/democracy tradeoff. Polling 100k people about where to get lunch doesn't work.
So over time, any time someone does something that might be seen as unjust, if it's within the error bars for "unusual but not a hard line", shifts the line more and more, especially if the people in question are good at controlling what the people above them hear, or calling in favors to shield themselves, until you wind up with sentences like "well of course they got fired, they were working on $THAT_PROJECT, and everyone knows $MANAGER hates $THAT_PROJECT".
My understanding is that you can usually flash the BIOS from the BMC even if the BIOS is fucked, though it's a paid feature upgrade (though I think someone might have cracked the algorithm on older boards).
At least, it has been the case on several boards of mine, including an X10SDV which bricked itself, as far as I can tell, just from bad luck somehow.
As far as I can tell, the jumper dance was to enable the main BIOS to use the Management Engine controller to perform some other part of the flash, which would ordinarily be locked out with the jumpers in their normal position. But now that it's tried and failed, it won't try again, maybe?
You can be cashflow positive and still benefit from having a larger pool of cash to throw around, particularly in any situation involving hardware manufacturing.
If you tell your investors "our limiting factor is how fast we can spend to deliver on additional requirements for these new customers", then it can both be true that you're not going to miss payroll for 5 years no matter what happens tomorrow and more cash would be beneficial.
Many people who have ever had to deal with the long tail of insanities in physical hosting, like "the ceiling burst and dumped water on a rack", "the RAID controller's capacitors exploded and now you need to figure out what still works", or "for some reason three of the servers won't talk to this switch but talk to anything else using the same cables, and the switch ports work for other devices", would happily pay a premium to only deal with SaaS logistics.
(Those were all firsthand examples; I'm not saying everyone needs cloud providers, but there are reasons beyond "really good salespeople" that people opt for offloading those logistics.)
Ok but add up a trickle of those examples, with staff to handle them, and you're still comfortably in the black.
You dont even have extra organizational overhead. Every cloud first company has a head of devops sitting in the chair where head of infra would be. They somehow wind up with like half the staffing anyways compared to running bare metal.
Our colo experience was pretty smooth, nothing insane like that, and saved us a bundle. Apparently ymmv. I hate working with AWS APIs by comparison, some of the worst UX I've ever seen.
I've dealt with both. I am continually amazed that people not only pay for AWS, but that it is so complicated, and that they use it in all sorts of absurd ways, not even just hosting 'vms' but using all sorts of amazon tools to do trivial tasks. I am sorry I just dont get it. Is it like learning salesforce and once you're sucked in you're just in? I am so glad I do not work at an AWS shop anymore and am very glad to be in a position where we do not use it.
You get AWS certifications, use as many AWS services as possible to pad your CV with the service experience and certifications, get your arguments and "well architected" dogma from AWS sales. Then you can get paid more at the next company (or at least high salary offers to extract a raise).
Also building high complexity systems that require a big expensive cloud engineer staff gets you status and visibility. In a tight spot you can still blame AWS for problems.
(Reality is not quite so bleak as people are not completely cynical)
I actually do get public cloud as well as running your own racks. There is room for both. Your startup is growing 100% every quarter but you're not sure if you have real PMF yet? Yeah probably stick with cloud. Zombiecorn growing 10-20% yoy or not growing and you're paying the cloud $10M/y for 6yo CPUs? - pretty foolish to continue doing that.
This sounds like either an extremely bad experience or an account from many years ago. Things are better now.
Also like I said: physically racking only makes sense if you are huge. Managed bare metal is a whole market category and it’s spectacularly cheaper than big cloud for most work loads. For bandwidth it’s like 1000X cheaper. That is not an exaggeration.
...or "the UPS batteries caught on fire", or "the first unit failed and the contractor who was supposed to replace it replaced the second one instead, resulting in an outage".
Or something as stupid as, "vendor requires $50 failed DIMM replaced under warranty to be returned by UPS instead of chucked into the e-waste bucket, but UPS cannot pick up from DC because the driver can't be bothered to ring the bell on the DC gate".
That one alone probably resulted in our longest ever ticket.
I think the point is less to add features and more to lower the barrier to entry for people making mice, since, as you said, in large part keyboards and mice are appliances to the degree that it should rapidly converge to a stable set of features.
Plus, on a human level, I wouldn't be surprised if the teams working on mouse development were annoyed they couldn't show their past work in the same way...
to lower the barrier to entry for people making mice
The barrier is absolutely not firmware; you can get a single-chip sensor with a USB + PS/2 interface for cheap, no firmware required, and it's just plug-and-play on any PC. The mechanical design is the biggest hurdle.
I would imagine that it's plug and play until you start adding nonsense like customizable scripting on buttons or more than a certain button count as is standard on specialized gamer mice, but sure, fair enough.
"This is a platform you can build on", software and hardware specs included, is still a much nicer thing to iterate on than "it's commodity parts to slap together" for someone without familiarity with the processes involved at scale, and going from "this is an opaque piece of hardware that responds on guaranteed timing" to "this responds on guaranteed timing but also has more complex features" is still a substantial jump, since "building software that meets realtime timing requirements" is not a thing in a lot of people's wheelhouse.
Because at scale, that doesn't work, I think, even money no object, because it's a task that requires a lot of domain knowledge, but also is monotonous and offers little in the way of satisfaction or looking good on your resume, so the candidates you're trying to hire aren't very junior, and also are not going to like the work.
Why not? "At scale" is not an argument on its own. This is something where scale helps you because the number of different hardware you need to support is independent from the size of your customer base.
And if you really can't act responsibly "at scale" then you shouldn't be allowed that scale.
I have to imagine the answer was either "dedicated MSCC servers and EEE" depending on your level of cynicism or "it was just a tech demo that escaped".
e.g. it's probably a security vuln if loading a Game Boy ROM reads arbitrary paths on your local filesystem determined by the ROM's code, not so much with Wine.
Someone made a cute demonstration that I think usefully encapsulates this a while ago. [1]
[1] - https://gpfault.net/posts/drunk-exe.html
reply