snom380

They don’t use TPU cores, but most of not all modern commercial helicopters and aircraft have vibration monitoring and reporting. I would assume the same is the case in many other industrial systems as well.

I think this is one of the cases where Apple doing hardware and software shines through. They’ve made macOS resume quickly from sleep, to the point where I’ve never really thought about/noticed the problem you’re describing. So the LED really isn’t needed for 99% of the users, the same way that you don’t have a power LED on iPhones or iPads. On recent models the login screen is there before you’ve fully opened the lid.

(It’s interesting in itself to track the history of power/sleep lights on MacBooks, since as far as I can remember they only turned on in the case where the internal display is off, or when the laptop was sleeping (pulsing light). Jony Ive even talked about it in the Objectified documentary: https://vimeo.com/7827217 )

Why doesn’t Apple need to innovate?

What’s your expectations that aren’t net? I find that the built in Preview app in MacOS works very well for my use.

This comes off as a bit of a FUD piece to sell the idea of serverless, like what Microsoft did with their Linux TCO play in the 2000s.

When Google was just Larry and Sergey, they didn't need an additional SRE person to help them set up and maintain their linux servers - they had enough competence to do so themselves. For someone else, renting a managed Windows server with a support agreement would be exactly the right choice.

Likewise, the 1xSRE for managed and 4xSRE for unmanaged K8s isn't substantiated. In my experience, that can be anything from 0 dedicated people and up depending on needs and circumstances. I imagine things like GKE Autopilot (auto-updates) and Fargate for EKS (serverless K8s pods) make it even easier.

It would be more interesting to me to see how their offering compares to other serverless vendors in price and features.

The analogy doesn’t fit, because in spite of its complexity, Kubernetes won the orchestrator wars. So, as mentioned in another comment, Kubernetes is VHS: Developed by a vendor that was more interested in spreading it than locking it down and monetizing it, thus ensuring that it gathered support by other vendors. Other orchestrators are still being used, but they’re not the default option that most would know about. And that’s fine.

There’s no reason to believe Kubernetes will stop dominating the orchestration market. There’s going to be more pressure from existing vendors to make it cheaper, better easier to deploy and and less complex. Likewise with VHS, you could rent a VHS Player (MovieBox) along with a movie if you didn’t feed comfortable with the investment of a VCR.

What’s going to kill Kubernetes, if anything, is likely a move away from container orchestration to something else, where the Kubernetes resource model somehow isn’t a good fit.

Likewise, VHS didn’t lose dominance, the videotape market just became irrelevant. IBM still dominates mainframes, Windows NT++ still dominates office/workgroup servers, and VMware still dominates virtualization.

I was under the impression that RPI chose "stock" Broadcom SoCs for their boards that, but the main problem with Broadcom is that they won't speak to you unless you have a substantial enough order?

From https://www.terraform.io/docs/cli/commands/refresh.html :

> You shouldn't typically need to use this command, because Terraform automatically performs the same refreshing actions as a part of creating a plan in both the terraform plan and terraform apply commands.

It's not true, and what you describe is correct.

I can only assume that the author has used some provider that hasn't implemented this properly (helm, I believe, is one example), or that they've run into one of the cases where terraform treats configuration/attachments to a resource as a separate resource (e.g. IAM role vs attached/inline IAM policies).

From my experience, terraform is almost always slow because it's making API calls out to the cloud providers, and a lot of that in turn is slow because many providers offer "eventually consistent" which terraform needs to compensate for by doing roundtrips to validate that changes are have become visible (applys failing because of that was a common problem in the early days of terraform).

> On terraform it's different, because of the tfstate. All the deployed elements are stored in the tfstate, re-running terraform won't update resources that are supposed to be in a specific state but are not.

This is incorrect, and makes me wonder how the author has used terraform. Terraform will certainly detect differences between managed and current state for the resources it manages whenever you do a plan/apply.

The major challenge is that terraform _can only reconcile resources or configuration values it knows about_, and that depends very much on how a particular cloud vendor or terraform provider has modelled resources. I believe the Helm provider is one example where it (at least in the past) haven't had a good way to reconcile state.

Does anyone know which of the "classic" minitel terminals had color displays? About the only one I've found is this on: https://sites.google.com/site/collectionminitel/equipements-...

Isn't that the case with any tool or service of some complexity? I'd probably have to look at docs or examples for most config files i write.

There's trade-off between a tool being too specific to a usecase vs being too generic with the associated "boilerplate". But I don't know how much simpler Kubernetes could be made while still covering the intended scope?

Do you think they're the exact same products, and that there's absolutely zero reason for anyone to prefer Slack over HipChat?

In my experience, Slack is the first chat application that both techies and non-techies actually use. I don't know why that is. But instead of asking when the hype is going to stop, it might be useful asking why the hype is there in the first place. [Edit:spelling]

If it's any help, I found this tool useful: https://www.haptictouchbar.com/ (I'd be surprised if Apple doesn't build this into the Touch Bar at some point.)

..the difference being, Apple can send the hardware, other companies often have to pay for product placements.

Part of what you get with ARM is certainly support, but a lot of it is also tooling, OS support and so on. There's a _lot_ of vendors outside the traditional big ones. And even the big ones like Samsung has used OpenRisc for service processors before.

Again, being able to spin your own chips isn't really at issue here, that's already possible. ARM and MIPS will likely happily let you continue to make chips based on old cores as long as you continue to pay your license fees.

The freedoms from the Open Source model is substantial enough to make it attractive on that basis alone, just as for Linux/BSD. One example is Western Digital transitioning to RISC-V for their hard drive controllers. I would imagine being able to add your own instructions without having to deal with NDAs and non competes with ARM will be attractive to a lot of OEMs.

Just like with Linux, it's difficult to anticipate what intersting things will come out of RISC-V, but one interesting example is a formally verified RISC-V core, picorv32: https://github.com/cliffordwolf/riscv-formal/tree/master/cor... (presentation here: https://www.youtube.com/watch?v=VU97ffHF_IQ). According to the author, this core will power safety critical applications at a synchrotron: https://theamphour.com/374-an-interview-with-clifford-wolf/

That graphic is most of the arguments made on that page. I don't see you can claim that it's used out of context?

That's the case today: ARM CPUs are sourced from different manufacturers and packaged together with other cores into SoCs, which have wildly varying support from their vendors. Some of these processors also have custom extensions. If you're worried about chip security when anyone can manufacture a chip, then sorry, we're already there, and RISC-V doesn't change that.

While the comparison to MythTV for a fun coment, this is exactly what ARM would like the high level decision makers to feel. Just as Microsoft tried with their "get the facts" campaign years ago.

Notwithstanding your terrible MythTV experience, there's seveal companies offering commercial support for Linux today, and a lot of effort has been put into making it as secure as the Windows equivalent. I suspect the same could happen with RISC-V.

There may not be one defining feature. For some it may be look and feel/attention to detail. It could be the number of well supported Slack integrations, or various enterprise features wrt message retention and deletion, SSO and auditing.

In practice, all the attempts I've seen at getting a significant number of non-techies in a company to use IRC have failed. At one company, we almost got everyone on Jabber, but it was never used much outside the tech circles. Slack? Everyone is using it and most seem happy about it, and it does a lot more than IRC.

I wear expensive clothing (without any visible branding) because I'm paying a company that pays fair wages to their workers and are working on reducing environmental footprint. Now that company isn't on Amazon, and I don't have a problem with Amazon selling their own brands, but if they end up making it more difficult for smaller companies to thrive, I consider it a negative.

I used to have the same opinion, but modern NiMH batteries have far longer shelf live than they used to, and the price is low enough that you can afford to keep some spares in an 8 battery charger ready to use. I do have a set of alkaline batteries, but I haven't used them in 3 years.

I find it more frustrating that network configuration tools seem to be added in layer after layer, like with the new netplan took in Ubuntu. To me it seems more complex than it needs to be.

Sorry, I don't even know what CPMs are. Could you provide a link?

The ROI for compliance is you get to do business with EU citizens and businesses.

What EU security directive are you thinking of, regarding IP addresses?

I don't think he whitewashes that it's a burden. But he does try to address some of the panic and hysteria.

I care about privacy. Perhaps Mattheij does as well, and that's why this is important to him. If you agree with the spirit of the legislation, then I think you should also consider this a great opportunity to do the right thing, instead of a hassle.