vegardx

I'm also a little bummed that they seem to have dropped the Pro Display XDR. I wanted a 32" display as the main display, and then use my existing two Studio Display vertically as secondary on each side.

I guess we're going to see how the support for DP Alt-Mode will be, as I'm not sure how much bandwidth that can provide, so 120Hz might be out of the question. But for now that has been a simple way to get around the lack of multiple display inputs, you just needed a separate KVM switch for it.

One thing that made Tahoe even worse is that Apple changed what they considered an update or upgrade, so for Tahoe it was suddenly considered as a update and not an upgrade, in all management solutions.

This force-upgraded a lot of Macs at work and we lost days of effective work across many engineers. The machines was practically useless for weeks.

They clearly don't care about power users anymore, and haven't for quite some time. It's so sad.

(I'm not a lawyer)

You should be careful about speaking in absolute terms when talking about copyright.

There is nothing that prevents multiple people from owning copyright to identical works. This is also why copyright infringement is such a mess to litigate.

I'd also be interested in knowing why you think code generated by LLMs can't be copyrighted. That's quite a statement.

There's also the problem with copyright law and different jurisdictions.

It would surprise me if it was, because of features like certificate transparency logs.

When this information is useful you've either got fundamental security related issues that needs to be addressed long before this, or you're dealing with threat actors with significant capabilities. In the latter case you've probably already taking this into account when you're creating your stuff, or you have the capability and technical understanding to know how to properly roll out your own PKI.

The overlap of people that suggest that you either run your own PKI or just distribute a wildcard certificate and have the technical understanding on how to do this in a secure way is minuscule. The rest of those people are probably better off using something like Lets Encrypt.

I don't understand why that is such a huge problem. The alternatives have much more severe problems, all from reusing a wildcard in many places to running your own PKI.

I'm going to chalk this up to the decline in Google search to save my embarrassment, because that was very straight forward, and I don't understand how I didn't find that. Admittedly, it's a couple of years since I looked and it could be a new feature.

Funnily enough one of the demonstrated use-cases of Apple Intelligence was looking up information like this.

I'm mostly happy with my Apple Watch, but you better hope that it doesn't calibrate itself poorly. There's no way to force it to recalibrate and it persists through full reset and even full replacement of the Apple Watch itself. I've more or less given up trying to fix it. So according to Apple I've been standing upright all waking hours for the last 3-4 years.

I've heard similar issues for people using crutches. They get like 3-5x the amount of steps, or not steps at all, and you've guessed it, no way to calibrate it.

(I'm sort of posting this in the hope that someone actually know how to force it to recalibrate)

I get the point you're trying to make here, and the sarcastic undertone, but I'd have issues living with myself if people died because of something that I was able to identify and that was preventable, and I did nothing.

The whole case strikes me as odd. Not only did the higher ups know about the problem, they also left a paper trail about keeping a lid on it and getting rid of the guy. This opens them up to a lot of scenarios, like:

- As demonstrated by this case, the information came out because of the wrongful termination

- If an accident had happened there's a fairly high chance that the investigators would uncover it, either because the engineer in question came forward or because they think they should have known about this, and cracks appear when they start asking questions.

An unspoken rule in a lot of fields is that you make sure that this kind of information never reaches the people that could be held liable for it. The people that are likely to be held responsible at least have to make it appear that they're not trying to suppress information like this. You quickly lose that ability if you actively try to get rid of people that tries to raise an issue. So they surround themselves with middle management that knows to not bring things up to them, without being explicitly told so.

I think that depends a lot on how the data is going to be used. It sounds like you're not really using EBS volumes for what they're great at; Durability.

While instance storage is ephemeral nothing really stop you from using it as a local cache in a clustered filesystem. If you have a somewhat read intensive workload then you might see performance close to matching that of using instance storage directly.

There are some fundamental limits to how fast a clustered filesystem can be, based on things like network latency and block size. Things like locking is an order of magnitude slower on a clustered filesystem compared to locally attached storage.

Having a low child mortality is important, and we've done so many good things in the last couple of decades, but I'm starting to think we're at the point now where the money you have to spend to make a meaningful difference is better spent in other areas of health care.

A classical example of this is in Norway. There's nothing that gives you access to more resources than being pregnant or being in care of a newborn. You can suffer from all kinds of mental health issues for your entire life, struggle to be a productive member of society and be in and out of temporary treatment and be on social benefits. But the moment someone is pregnant they get will be top priority for anything that is even remotely connected with child mortality, almost regardless of how benign something is.

I personally know several people that finally got the help they had been so desperately been begging for, just because they got pregnant. We could have saved them from literal decades of suffering by just providing good treatment early. I'm willing to bet that we'd even be in a position to spend even more money on reducing child mortality, because when you start doing the math of how much they ended up costing society it really adds up.

They don't even seem to specify what kind of charger they've tested. But I wouldn't be surprised if they found that a quarter of public L2-chargers were out of service. They have tons of failure points and usually very little internal logic to self-report.

Some of the early fast chargers (outside of Tesla) were notoriously bad, and a lot of them are still around, for better or worse. Many of the early AC and DC chargers were also without any kind of connectivity, making it hard to properly manage them. In the early days even some of the fast chargers at gas station weren't really network connected, and if they were it was poorly implemented. Not that different from pumps at the forecourt.

Making a wild guess that it was a Circle K-station that you went to? They were quite early to the market with fast chargers, and had a lot of reliability issues with some of the chargers. Like you suggested, it's usually software related, and you can often get them to work by just power-cycling them using the emergency stop button. If you hear the loud click from the metal contacts or the charger latches with the port and it doesn't start charging it's almost always a software glitch that a restart will fix.

For regular AC-charging all the logic is in the car, so the only thing you really need is some safety features on the outside, typically some ground fault protection and so on. But when you use a DC fast charger the charger itself and the cars battery management system has to work together, which I imagine can cause all kinds of edge cases where people have interpreted the standards differently. It didn't help that there were multiple different standards early on.

I don't really understand the argument you're trying to make. You want us to use less accurate meters and then pay a premium to cover those inaccuracies, which is supposed to be cheaper than just buying accurate meters? And then use some technology that doesn't seem to exist to detect losses and theft? If it was this easy we'd already be doing it.

These meters are more expensive, but not that much more expensive. The majority of the cost, by a long shot, comes from installing them. These meters also offer a lot of other capabilities, which greatly improves the reliability of the network. If you spread the cost of these meters over the projected lifespan we're talking about cents per month.

Everything I read seems to suggest that hydrogen is a pipe dream for energy storage, as the output efficiency is so low. And that's before accounting for all the issues of just storing and distributing it.

Solar panels and wind turbines produce electricity, the highest form of energy, directly. Instead of converting that to thermal or chemical energy for storage and then back to electricity for distribution, you're better off just storing it at as thermal energy at the destination. I think we often forget that thermal energy means everything from ~0 Kelvin. A heat exchanger can be very efficient.

I think there's going to be a lot of interesting stuff happening with dual-use PV panels and thermal heat exchangers. In some cold climates you generally want as much thermal energy as you can get your hands on.

For the last mile you're probably right, but the electricity has to come from somewhere. So you also need to size the production capacity, distribution network, sub-stations and whatnot to match the installed capacity. Things get really bad, really quickly, when demand and availability doens't match.

Are you sure you want less accurate meters? There's a lot of losses in the network itself, and without accurate meters it's hard to pinpoint where they are and if they can be fixed.

In Norway we quite recently switched to more accurate networked meters and at that time they said that as much as 30% of all electricity produced wasn't accounted for, which you end up paying for, one way or another. Some of these losses are from the network itself. But a not insignificant part was from people illegally tapping the grid or last-mile losses due to poorly maintained infrastructure that was hard to pinpoint without using expensive manpower to physically check every single connection.

There's a lower bound to how cheap electricity can be, the infrastructure to distribute it isn't free. Every country price this differently, but one way to solve this is to split the cost per kWh in use and transport, which is common in Europe.

In Norway we have a model like that, and it effectively sets a lower boundary of (depending a little on the region) around 0.50NOK/kWh, around 0.05$/kWh. The price for electricity quite often go into the negative during summer, but you still end up paying for the distribution.

I'm not going to pretend that there aren't edge cases and personal situations that would make it viable, but my initial comment was on consumers as a whole.

And we're talking about averages. So sure, if you have gas boiler you probably could get by with a 2,2kW or 3,6kW inverter, but just powering a simple kettle would likely trip a fuse. You can get around it with just being a little conscious about what you power up, and when you power things up, but I'd argue that most people don't want to deal with that.

And remember, if you're grid connected you either have to have a transfer switch or separate circuits if you want to use this as a backup when the grid goes down. It complicates things a whole lot.

Teslas "virtual power plant" is only for Tesla Powerwall. There's no V2G capabilities in any Teslas to date, and I don't think there's even hardware support for it. The Tesla Cybertruck has V2L capability, so it might have the necessary hardware to do V2G with some software updates, but I kinda doubt it.

The Tesla "virtual power plant" does reserve some capacity for you, and technically you can charge your car with that. A single Tesla Powerwall is "only" 10kWh, and with inverter losses and such you're likely seeing closer to 8kWh of usable energy if you charge your car with it. You're probably much better off just using it to run your appliances so you mitigate some of the losses with more inverters in the mix.

I don't really think consumers want or need this.

The battery chemistry used in most EV batteries are not really optimized for a lot of cycles, and they're somewhat expensive to replace, so you're much better off just buying batteries that are made for the purpose. You also have fairly limited inverter capacity in most EVs, as the inverter installed is scaled to run the cars AC and infotainment system, which doesn't really need that much.

You also have to deal with either having beefy automatic/manual transfer switch or separate isolated circuits to prevent back feeding the grid electricity in an outage or during maintenance.

There's a lot of people repurposing used Nissan Leaf-batteries for what you're describing.

I'm struggling a little bit to grasp all the concepts when we start talking about unikernels, wasm and so on. Hopefully that's just a sign of the maturity of it, and not a sign of my mental decline. But on paper (as I understand it) it looks /so cool/.

I don't really see how rootless containers change anything at all. You're still "just" one kernel privilege escalation away from breaking out. The level of isolation is much better in virtual machines, and the performance penalty is comparable these days.

The virtual machine images are a bit heavier, since you need a kernel and whatnot, but it's negligible at best. The memory footprint of virtual machines with memory deduplication and such means that you get very close to the footprint of containers. You have the cold start issue with microvms, but these days they generally start in less than a couple of hundred milliseconds, not that far off your typical container.

I think the lines between software and hardware-based are a little blurred these days with accelerator cards and whatnot. It's just a lot harder to come with the same level of guarantees when you're basically running a hypervisor on top of it.

In AWS you don't even do neighbour discovery through ARP. Or that's a lie, you do, you get a arp reply, but it's not from any of your devices on the network. And traffic is authenticated and authorized at both the source and destination, so you can't do fun things like manipulating arp tables. You get a lot of nice features when you have a fully software defined network, but it comes with a couple of caveats, like you mentioned here. I doubt we'll ever see "real multicast support" in the sense that network engineers are used to.

Compared to the amount of oil used for making fossil fuels plastic is almost a rounding error. So he's technically right, but not really if you look at th bigger picture.

In what way?

I've always found that Terraform does it exceptionally well, mostly because of the dependency graph and how good providers map resources so that they don't end up in a dead lock.

Wild guess: They use significantly more electricity than the average customer that does just about anything else with their hardware. The GPU can easily run at hundreds of watts, and when you add in the required cooling you're probably at 1.5-2x that in total power usage.

If you're lucky and it has a instance profile attached with appropriate role/policy attached you can use get caller identity to see what account it's running in: https://docs.aws.amazon.com/cli/latest/reference/sts/get-cal...

The for-profit company is happy, anyway. They get free data and you've priced the competition out of the market.

And they'll also be happy to disregard all your wishes for them to implement their own caching layer and if you have no way to block this kind of activity they absolutely will do it. As demonstrated in the example I gave you.

If you want to create an open source one which is free and promises not to track the user, you can, but then you need the data. If you end up with millions of users, who has more resources to set up caching servers, some individual idealist with zero revenue or the United States Government?

Me - as a taxpayer - isn't really keen on paying for everyone to build their application on top of it. If you create an open source application you can always tell the users how to obtain such a token.

This shouldn't even be a question. The government has to operate infrastructure that can handle millions of users for many other reasons. This should be something they're experienced in, and something like this should just fit into a slot in existing infrastructure. This is what it's for. If all you want is to provide the data for various scummy middlemen to wrap in ads and spyware then why is it an API at all instead of a static data dump / live feed with the latest changes?

Again - why should I as a taxpayer have to pay for that? For me, the taxpayer, the service is just as available and usable, even if I have to request a token to use the service. How do you propose you'd limit how a service can be consumed without some kind of token? We've already established that your other solutions doens't work. The alternative is likely just to not provide the service at all, which seems like a net loss for everyone involved, both for for-profit business, taxpayers and open source developers.