The fact that details of the issue _will_ be disclosed publicly is an implicit threat. Sure it's not an explicit threat, but it's definitely an implicit threat. So the demand, too, is implicit: fix this before we disclose publicly, or else your vulnerability will be public knowledge.
You should not be threatened by the fact that your software has security holes in it being made public knowledge. If you are, then your goals are fundamentally misaligned with making secure software.
I don't think that you understand the point of the delayed public disclosure. If it wasn't a threat, then there'd be no need to delay -- it would be publicly disclosed immediately.
> During a fire in the Bronx, firemen laid 7,000ft of hose to get to a suitable water supply and the truck pumped as though it was dipping its feet into the ocean.
"7000 ft" sounds wrong to me. That's over a mile of hose. Feels like that's unnecessarily long. I'd love to learn more about this. Anyone know when or what fire this was?
The article mentions that the main pumping unit could draw water from 8 hydrants at once. So 7000 ft of total hose to get to 8 hydrants sounds like it makes sense.
I wonder if maybe it can't even use hydrants that are too near each other in the plumbing graph.
I wonder if maybe it can't even use hydrants that are too near each other in the plumbing graph.
There's a lot of variables in that equation. For example, say you have a "dead end" main that ends somewhere near the fire. If you connect to the last hydrant on the main and start flowing water, there's a good chance you won't get a lot of additional water by connecting to the next hydrant up the street. But if you connect to a hydrant that's on a main that is part of a loop, there's a better chance you'll be able to get more water by doing that.
And without getting into too much detail that would be boring to non-firefighters (probably)... there's actually two big variables for a given hydrant: the maximum volume of water it can supply (in GPM) and the pressure available at the hydrant. And those two things are related. Anyway, net-net, you can have a hydrant that is capable of - in principle - flowing, let's say 2000 GPM. But the pressure at the hydrant is only, say, 40 psi. That means you only have 20 psi (approximately) available[1] to overcome the friction loss in the supply hose between the hydrant and the engine. And that friction loss in turn is a function of the hose size and the flow rate.
Anyway, that results in a situation where you might have a hydrant that could supply you 2000GPM, but if your fire is, say, 1500 feet away, you might effectively only be able to take advantage of maybe 500GPM of that.
And that in turn leads into stuff like using a "four way" or "hydrant assist" valve, or having a relay engine sitting right on the hydrant (to minimize friction loss between the hydrant and the engine) and then using its pump to boost the pressure going to the attack engine. By using multiple engines like that, you can get closer to achieving that hypothetical 2000GPM (or whatever) flow.
It gets pretty complicated, but fortunately fires in urban areas where the municipal water system is the limiting factor seem to be relatively uncommon (but not unheard of!) in this day and age.
[1]: because you don't want to pull the residual pressure down too low or it can damage the water system, supply hose or your pump.
If they were all in a single line it probably wouldn't have worked -- series hydrodynamic hose impedance adds just like series resistance in a circuit and the pressure at the end would have been too low to be useful. But if it was 7000 feet arranged in several shorter parallel lines it's possible.
It's not uncommon to see an individual fire engine in the US with 800-1000 feet of supply hose. I don't know if that's a common configuration in a dense city like NYC, but it's certainly a reasonable amount per engine.
Yeah, I think Minecraft definitely still would have been a hit without any modding. Though it might not have become the absolute juggernaut that it is now without it -- it's hard to say for sure.
I know from my earliest memories that reading is possible from whole words if you are read to enough without being formally taught. Granted at that point my attention span was too lacking to really read books by myself, compared to being read to.
But that basically amounts to probably just learning phonics indirectly through examples and drawing patterns, and specifically is an exception and not the norm. And children's books even if they don't use the phonetic alphabet teach through example when read properly.
I don't know enough about whole language learning theory and its development aside from the fact that it has been discredited. Perhaps it was based off of the outliers and wrongly assuming that the higher end of the early literacy bell curve's techniques would be generally applicable?
Why rely on someone to intuit what you could just simply state explicitly? That sounds like you're just asking for trouble if someone doesn't think/intuit in exactly the same way that you do.
I'm honestly surprised there are people who think that only examples are fine. And I'm equally surprised there are people who think only reference docs are fine. It's so infuriating coming across a project that only has one kind and not the other.
It shouldn't be an either/or situation. Good documentation should include both the API spec _and_ examples. I believe the person you're replying to was complaining about documentation that's _only_ examples since it seems like that's what TFA was advocating for.
>> little help popup telling me places I can go. I really appreciate this because I don’t often use the “go to definition” or “go to reference” feature and I often forget the keyboard shortcut.
> Exactly! Pity this basic contextual help isn't more widespread, every single app that uses a lot of keybind sequences could benefit from it, especially if it becomes a bit smarter and only shows a popup if you don't finish the sequence right away
I agree 100%. This would be helpful in so many places. That was my favorite part of the article -- one little paragraph and screenshot, but it made me desperately crave that feature almost everywhere. I agree that it'd need to be smart about it -- after a timeout, as you mentioned, is a great idea. That way it can stay out of your way if you know what you're doing, and only pop up when you hesitate.
Sorry I'm exhausted and lazy.nvim is the package manager, but I meant lazyvim which is the distribution. Within this distribution I'm pretty sure it's which-key that provides a popup. If I type <leader> it pops with suggestion (and a little icon in front of each indicating if the next key has sub-commands or not).
I think kids aren't the best comparison with senior citizens when it comes to technology. I've got senior citizen parents and I've got nieces and nephews who are all under 10 years old. The kids are so much more adept at pretty much any technology they get their hands on when compared to my parents (iphones, nintendo switch, tv remotes, etc). They start off about as poorly as my parents do but quickly overcome them. My parents aren't tech illiterate, either -- my dad especially was quite a DOS power user back in the day, and to some degree has kept it up with his Windows usage too.
I think part of it might be due to the neural pathways still forming in the kids brains, but I also think a lot of it has to do with who they're around. The kids are around their parents who are using this tech all the time, while my parents don't have that benefit except for in comparatively small doses.
You seem to be confusing the concept of a language with the concept of program used to write in a language. DEML is a language (that's what the "L" is for). A program with a UI, graphical or otherwise, can be used to create a DAG, and then that DAG can be saved in a DEML representation.
With that in mind, what you seem to be bothered by (please correct me if I'm wrong) is actually that a language has been released without a UI to abstract away the process of writing it?
