moring

> Do you expect your iPhone 16 battery press tool to still be useful in 2 phone generations ?

Let's assume a "no" for the sake of the discussion.

> How many times do you see yourself replacing the iPhone 16's battery ?

100s of times (for 100s of different phones, obviously), because otherwise you _would not be buying repair tools_!

The whole notion that you buy a set of high-tech tools and then use them only once or twice is the insanity that causes this whole discussion to even take place. These are tools intended for professional repair shops, not for consumers to repair their own phone.

This is fine. A problem arises when you assume that this will always be the case, for all developers, and then mandate that they omit comments, _without checking if your assumption is true for their case_.

IMHO that rule can be generalized: Whenever you make rules for other devs, make sure that the assumptions on which those rules are based are true, lest you interfere with their work in a negative way.

I remember defragmentation from ca. Windows 95 times, and it was totally different from this game. None of the files shown here is actually fragmented, only the used space is, and for some reason you can't place a two-block file across a "line break".

edit: I realized that the "lines" might be meant to represent disk cylinders in the pre-LBA era, but even then, a line should "wrap around" to itself instead of the next line.

> Is this a soft limit or a trajectory prediction?

I don't know. I just tried to frame the problem from a customer's point of view, because cloud vendors' statement that customers would not like a limit is (IMHO) limited by their POV. Customers do want a limit, but not the way that cloud vendors would implement it. I think a huge part of the problem is understanding what exactly it is that you need when you use a cloud service. (This is varying from customer to customer, and from service to service, of course. You usually have important services that must be running, and others where an outage would be unpleasant but not critical.)

> Nobody wants to spend any money really right? But you need to spend some to avoid losing service. That’s just a cost you don’t like but need to pay.

That is not the issue. From a customer's POV, I would be ready to spend extra to keep the service running, but there is a limit where I'd prefer an outage because I can't bear that much. There are two problems with that: First, the limit is blurry. Second, a simple hard limit would leave me with a huge bill AND an outage. I would want to be able to choose one of those evils, not be left with both. And these two problems compound.

> But I don’t know much about this at all. My whole experience was accidentally getting my own personal self a $500 AWS charge and then deciding they cloud services were dumb.

I don't think they are dumber than the alternative. If you run your own hardware, you have a hard limit in both cost and computing power. You could technically get that with the cloud too, but it is not usually offered because it doesn't really solve the problem, but neither does it for for your own hardware.

That said, it would be nice if the major clouds would offer a "hard limit" option, but it really only works for "unimportant" applications that are cost-sensitive and can take an outage.

I didn't mean to imply that. A hard limit at X that stays inactive <X, and at >X, leaves you with a bill of X and an outage is the easiest approach from a technical side: Terminate the service when X is reached, and bill exactly what was provided. It is something you would instantly come up with when asked to implement a cost limit, and you don't for a second put yourself in the customer's position.

Of course cloud vendors do put themselves in the customer's position, and that's why they say that customers would not be happy with a limit, even though they are asking for it.

This made me think. There is usually some "hard" cost limit X that you cannot / don't want to afford, so terminating the service is preferable.

There is also usually some "soft" limit Y < X that you don't want to exceed, and don't plan to exceed, but you'd rather pay >Y than face an outage.

But a hard limit would have to be set to X to avoid that outage, and if it gets exceeded, you'll face a bill of X and an outage.

So what a customer would actually need is to specify both X and Y, with the rule: If the cost would exceed X, then terminate it early so the cost doesn't actually exceed Y.

Sounds complicated to implement, but then, the current practice of waiving the bill is complicated too if you tried to formalize it.

(For the sake of this discussion, I'm ignoring all the technical difficulties of terminating a high-availability service at all.)

It seems to me that you can download the postcode list freely: https://osdatahub.os.uk/downloads/open/CodePointOpen

Something is missing here. If OS already has that data from RM and can make it available freely, why would they need to build another database?

How does OpenStreetMap solve it? OSM, more specifically OSM Nominatim, shows postcodes. Example: https://www.openstreetmap.org/search?lat=53.151778&lon=-1.16...

> Yes they are idiots. Well more likely they were cogs in a dysfunctional bureaucracy that is not allowed to do good work because it doesn't allow common sense to drive decision making. So the 'idiot' here is an organization, maybe, and not a person.

As I said, that turns your argument around: They did not make a bad UI because they are idiots, but rather they are idiots because they made a bad UI. This gives you zero insight to prevent future accidents.

> Yes, the UI was obviously terrible before the accident happened. My first thought when I saw the picture was, wow, that's terrible.

You saw that picture after you already knew that an accident happened. The interesting question is whether your conclusion would have been the same if you saw it without knowing about the accident.

I really suggest that you have a look at the CAST handbook, because every single of your arguments gets taken apart there: http://sunnyday.mit.edu/CAST-Handbook.pdf (also posted in another sub-thread, but this whole HN discussion shows that still too few people know about it)

Are the people who designed this UI idiots?

If no, then that contradicts your argument. Non-designers obviously do get it wrong.

If yes, your argument has become a "no true scotsman" -- it no longer makes a statement about the capability of anyone, but simply defines "idiot" as people who get the UI wrong.

Besides that, hindsight is 20/20. Was the UI obviously terrible before the accident happened?

It seems to me that an unspoken assumption in this thread is that "design" is purely theoretical work, performed by a designer.

If the behavior of a sleep-deprived sailor is an unknown variable, then the obvious solution is to get a sleep-deprived sailor involved in the design process. This is not particularly complex, and while _some_ money is involved, preventing this accident would basically give you a budget of $223 million, human lives not even taken into account.

Finding something or someone to blame -- whether it is an operator, the UI, training, whatever -- typically halts all insight-gaining processes, and is therefore not recommended. Especially if that something is "100% to blame".

It is not only the ship's UI that lacks review in the post-mortem analysis, but also the process that lead to it.

"Conspicuously absent from their recommendations was any discussion about user interface design."

_Why_ did the NTSB not review the user interface? What is their motivation, and the forces that influence their actions? Is the NTSB sufficiently staffed with experts on user interfaces? If not, why not?

> These specifications come from a document written in 1988.

Is the process to update Standard F1166 sufficient? (Probably not.) Why? Why is a document that is clearly outdated used to guide UI design in a newly designed ship? What are the incentives and forces that lead to this outdated standard being used, and no update fixing it?

Related: CAST handbook, http://sunnyday.mit.edu/CAST-Handbook.pdf

There were at least two other techniques back then.

The first is to write to another buffer (possibly in normal RAM, not video RAM), then when the frame is done copy the whole buffer at once, so every pixel gets changed only once.

The second is to write to another buffer that must be in video RAM too, then change the registers of the graphics hardware to use that buffer to generate pixels for the monitor to show.

They had different tradeoffs. Copying the whole buffer when done was expensive, changing an address register was cheap. But the details of the register were possibly hardware-dependent, and there was no real graphics driver framework in place. Also, to just "flip buffers" (as changing the address register was called), rendering to the off-screen buffer meant sending pixels to video RAM, which was (IIRC) slower to access than normal RAM (basically a NUMA architecture), so depending on how often a pixel gets overdrawn, rendering in normal RAM could be faster overall even with the final copy taken into account.

This makes me wonder why shells don't support a simple "undo". Though I think there will be a UI conflict between "undo autocomplete" / "undo paste" / other stuff that edits the current command line, and "undo the last command" which would need much deeper integration with the tools that get run.

By accompanying the binary with a formal description of the possible arguments, either as a separate file or embedded in the executable. But the latter is not really sustainable the more metadata you add, so more likely a separate file.

Applications already come with lots of metadata: man pages, icon, readable name, ... adding formal shell-completion information is just another one.

Besides that, the built-in command line tools already have auto-completion for their arguments. Though I think they do it by running scripts at shell startup, which isn't exactly the mechanism I would have used... but it works.

In your case, "that a.out I just compiled", this metadata would be missing, so no shell completion for you. But that is a niche use case anyway, and not at all what this post is about.

They are deviating from that already, aren't they? If they use one ECU per zone, then the peripherals in that zone can't be connected via CAN bus, otherwise they would need their own controller.

I think you'd want at least some "dumb" logic moved to the periphery, otherwise everything has to be conected directly to the CPU and you would still end up with tons of wiring. Also, some functions done in the periphery are ideal candidates for parallelization, such as the keyboard scanning the key matrix for pressed keys.

When I read this, my first thought was: Why do these ECUs have any deep logic at all? I would have expected all logic to be centralized at one point (or in a few points, but with each domain localized to one of them), and everything at the edge be dumb(1) port extenders. That's a single point of failure, of course, but as far as I understand the zonal approach has those too -- multiple SPOFs, actually. At least when it's a single SPOF, that problem can be better mitigated.

(1) "dumb" meaning no decision-making logic. It could still mean a lot of decision-less logic, from button debouncing to input signal filtering/processing and outputting compressed audio streams.

What makes an artillery shell so expensive compared to a drone?

> Think about it for a couple of minutes: teaching yourself a bunch of exploits and how to use them means you're investing your time in learning a bunch of tools and techniques that are going to go stale as soon as everyone has patched that particular hole.

No, it means that you learn practical aspects alongside theory, and that's very useful.

Could you find any hint about the "surplus O2" claim in that article? The only thing I found was fig. 1 which seems to imply a cycle which completely turns glucose and oxygen back to CO2 and water, making the whole thing a fancy solar cell without any emitted oxygen.

#3 can be solved by keeping it frozen.

> This has nothing to do with streaks or dopamine rushes or pleasing managers. This is about getting stuff done. To me, a developer who can't figure out ways to be productive by contributing tiny commits spread over time is a developer who is wasting space in a team.

This totally discounts any work that does not result in commits, such as requirements analysis, legacy code analysis, or code that results in insights but won't be merged.

But then, anyone who knows how incredibly valuable such work is will likely not want to argue whether they are "wasting space in a team" either, and leave on their part when confronted with such claims.

The numerous other email providers are... numerous. Every discussion like this ignores, to an absurd extent, how hard it is for non-tech people to gather information on these topics and make an informed choice: Information about which email providers are care about which aspects of privacy, which aspects of privacy and information security even exists, which email providers even exist, what they are doind with your data, what parts of what they are doing is a problem...

You can't even ask tech people to make a choice for you because they all say different things.

Other domains like cars, medicine, construction, whatever have established standards because they have recognized that individuals simply _cannot_ make an informed choice, even if they want. I'm eager to say that only information technology likes to call the user "unwilling" and "lazy" instead, but actually individuals from other domains do that too. Luckily, the established standards are mandatory, so their opinion doesn't count.

Do you know for what area of solar panels that is?

This seemed very much to me, so I immediately jumped to the conclusion that you might have mistaken kW and kWh, and were talking about energy for a whole day... but no, you're right. A quick google search gives 50 W/m^2 even for a rainy day, 150 W/m^2 for heavily clouded. So 1-2 kW might be a bit high, but not off by an order of magnitude. (Confirmed by looking up multiple sources to make sure they didn't confuse kW and kWh)

> What is the strength of the resulting cement?

According to the article, the clinker has the same composition as the "normal" one. The strength _should_ therefore be the same, but must still be tested of course. In case it is different, the analysis why this is the case would certainly be interesting.

> What is the energy input needed per kilo of output steel/concrete?

... compared to separate processing for steel and clinker. The article makes it sound like we get the clinker "for free" because the energy input is required to make steel anyway, but there is no word about whether it actually needs the same amount of energy with the added slag, or more.

Might be just a remark so people don't wonder if they missed the news about these crashes.

Wikipedia says that some subtypes of supercapacitors use chemical reactions, too.