Hacker News new | past | comments | ask | show | jobs | submit | masklinn's comments login

> Why not?

Because that costs way more than you're paying for your connection. The business model is predicated upon oversuscription of the ISP's network because near enough nobody does that.


HEAD is counter-productive

Just GET with if-none-match and if-modified-since (based on the etag and last-modified you got in the previous response), and the server will return a 304 not modified with no content if nothing has changed, and the content otherwise.

With a HEAD you'd get the same result except now you'd need to ignore the cache headers from the HEAD response in order to fetch the content in a second request.


You speak of this confidently, but there are sites that return a not modified response when in truth they have modified the feed. It doesn't happen often, but I have seen it happen with more than one site. It is why I take the not modified response with a grain of salt.

> It would have been better to be able to first check if new data is available.

That... is what conditional requests do...


Which means: do not place extra mechanisms in the RSS when you can do the same with HTTP.

But then there is the problem of RSS clients that may not work properly (may not use that trick), without the user knowing it, and that of RSS servers that do not work correctly with "If-Modified-Since" (as noted in a nearby post).

Edit: but if the burden were placed on RSS instead, we could have had the trick of "I already have ...#10050, #10051 and #10052: just send me from #10053 on" - the feeds XML that is updated recently will contain more items than just the new ones. Similarly for the gaps: "the XML would contain from #10050 on, but there had been a surge of publications and now I am missing #10045 to #10049..."


> but if the burden were placed on RSS instead

That would be nice to have, but it's less realistic.

Some clients already speak proper HTTP, and others can too, with little modification. For modified RSS like this, you have to make a standard first, then push both servers and clients to use it.


It also requires a "smart" server, whereas you can serve your atom or rss feed statically with a standard HTTP server handling caching and conditional requests essentially free.

Yeah, although dumb servers could just return last N posts as usual. It's one more case to handle on the client, though. (The alternative is breaking compatibility with older feeds, which is way worse IMO.)

I assume it's an autocorrect of heap.

Blender's not even in C (the snippets are clearly C++), I wonder what the logic of having a sorted doubly linked list is: unless it's a skip list it's not like you can do bisection searches.

I guess a flat array could still be debatable if you're usually inserting near but not at the end, as it'll still need to move all the following elements. But it seems dubious.


> Is this common?

Very. For instance if you look at sorting algorithms on wikipedia they pretty much all list performance (best, worst, average) but also worst-case space complexity, in O notation.


> Very similar structures, with very different memory requirements and access speeds. I can count on one hand with no fingers the number of times I've seen an array used.

That is obvious when you actually check the access speed of arrays and find out it is about half that of lists on small integers (under 256), and worse on non-small integers. That is literally the opposite trade off of what you want in 99.99% of cases.

Deques are even less of a consideration, they’re unrolled linked lists so random access is impossible and iteration is slower, you use a deque when you need a deque (or at least a fifo), aka when you need to routinely manipulate the head of the collection.


It depends on your constraints. If you’re limited by RAM, arrays make a lot of sense for certain applications. If you need Python’s buffer protocol, again, they make a lot of sense.

As to deques, yes, they have specific uses, and being slightly smaller isn’t usually a selling point for them. My point was that I have seen many cases where an incorrect data structure was used, because a list or dict was “good enough.” And sure, they generally are, but if the language ships with other options, why wouldn’t you explore those?


> or you have some kind of sum-type á la Option<T> and cannot possibly construct null or zero-ish values.

Option types specifically allow defaulting (to none) even if the wrapped value is not default-able.

You can very much construct null or zero-ish values in such a langage, but it’s not universal, types have to be opted into this capability.


Exactly my point, you have to opt-in, and in practice you only do precisely where it's actually necessary. Which is completely different than "every single type can be a [null | zero value]". You cannot possibly construct some type A (that is not Option<A> or A@nullable or whatever) without populating it correctly.

Of course you need some way to represent "absence of a value", the matter is how: simple but incorrect, or complex but correct. And, simple/complex here can mean both the language (so performance tradeoff), and (initial) programmer ergonomics.

That's why I ask if you can have your cake and eat it too, the answer is no. Or you'll get sick sooner than later, in this case.


> You cannot possibly construct some type A (that is not Option<A> or A@nullable or whatever) without populating it correctly.

Except you can. The language runtime is clearly doing it when it stores [None|Some(x)] inline in a fixed size struct.


There is no way to store None | Some(x) in sizeof(x) bytes, for simple information theory reasons. What you can do is store between 1 and 8 optional fields with only 1 byte of overhead, by using a single bit field to indicate which of the optional fields is set or not (since no commonly used processor supports bit-level addressing, storing 1 extra bit still needs an entire extra byte, so the other 7 bits in that byte are "free").

> There is no way to store None | Some(x) in sizeof(x) bytes

That's subtlety incorrect. Almost all languages with NULLs in fact already do this, including C. On my machine sizeof(void*)=8, and pointers can in fact express Some(x)|None. The cost of that None is neither a bit not a byte, it's a single value. A singular bit pattern.

See the None that you talk about is grafted on. It wraps the original without interfacing with it. It extends the state by saying "whatever the value this thing has, its invalid". That's super wasteful. Instead of adding a single state, you've exploded the state space exponentially (in the literal sense).


I should have made that caveat: if X doesn't need all of the bits that it has, then yes, you can do this. But there is no way to know that this is the case for a generic type parameter, you can only do this if you know the semantics of the specific type you are dealing with, like the language does for pointer types.

I should also point out that in languages which support both, Option(int*) is a valid construct, and Some(nullptr) is thus not the same thing as None. There could even be valid reasons for needing to do this, such as distinguishing between the JSON objects {} and {"abc": null}. So you can't even use knowledge of built-in types to special-case your generic Option implementation. Even Option(Option(bool)) should be able to represent at least 4 distinct states, not 3: None, Some(None), Some(Some(true)), Some(Some(false)).


> I have to ask why you don't have a ton of unmanned drones down there. Literally remove the need to move somewhere for the people on board.

https://en.wikipedia.org/wiki/Electromagnetic_absorption_by_...

It's extremely hard to communicate long distance underwater, especially to do so discreetly.


If you're launching a fleet of drones, discretion is probably not a major concern.

A coded sonic pulse could have exceptionally long range. Sure your enemies would detect it, about half a second before they detect the drones.

A more practical concern is simply temperature and how long the drone's power supply can survive in the cold ocean.


Drones that sound like, act like, or maybe look like whales, might be the answer. If the adversary can't tell if its a whale or drone, likely to force them to waste a lot of resources and/or ammunition.

It's a compelling picture, but it seems like it would be rather harmful for real whales, and if chances are it's a drone rather than a whale, several actors might choose to fire regardless and find out later. Not that whales are the only option to mimic, but whatever is chosen had better be common enough to make the drones rare by comparison, and stay that way.

Jellyfish might be a nice option when conditions permit...


> It's extremely hard to communicate long distance underwater, especially to do so discreetly.

How does existing submarine cable infrastructure carry communications to subs?

Low-frequency AC current in the shield, data picked up magnetically?


Sound waves. Acoustic waves travel much farther and there are transmitting stations underwater.

Contrary to the other reply, ELF is not used and is impractical: https://en.wikipedia.org/wiki/Project_Sanguine

For VLF you can drag a very long antenna behind you, but most submarines just launch a buoy with a normal antenna to the surface and a fiber connection to allow them to stay below the surface.

https://www.navalnews.com/naval-news/2022/04/communication-a...


I did notice the bit in the Wikipedia article where they mention the US station isn't used for submarine comms anymore. Thanks for the higher quality info.


Don't whales communicate across oceans with moans?

You presume it has to be incredibly long range? I'd be surprised if that is necessarily the case. Could also flat out do cables to many of them at rest.

Is it fool proof? Almost certainly not. It doesn't have to compete with perfect, though. Just with what we have right now.


> You presume it has to be incredibly long range?

EM waves fall off exponentially inside a conductor like saltwater. A 1 kHz wave has a skin depth of 8.75 meters, vs the Virginia class' 10m width. A signal from the front to the back of the submarine would be attenuated by 10 million times.

Note that this is in addition to the normal problems with antennas. Your home router transmits at <100 mW. Say you spent a ton of money and made a super sensitive receiver that could operate from 140m on the low SNR of your router. In order to receive the same power at 140m on 1 kHz, you would need a 1 megawatt transmitter. It would be dumping 60% of its power in the first 8.75 meters of water. Not quite enough to boil it, but not far off.

That's your first problem. The second problem is that the wavelength of a 1 kHz signal is 299.8 km. Antenna effectiveness also falls off exponentially with size, and the smallest antennas are maybe 10% of the wavelength. A 1 km antenna does not work well for 1 km, and even then you have to let out a buoy with a long cable- which is how current submarines do it.

The third problem is that if the drones are 10s of km or less away from the sub, there's no point. That means you know where the sub is. The problem is knowing where to aim active sonar or drop depth charges, not aiming.


This is assuming I think you have to have radio communication with the drones at all times? I'd assume more that you have tethered trenches scattered throughout the ocean that you care about and can dispatch an absurd number of drones at will. No need to keep them moving on a regular basis. My general thought there was more that keeping an absurdly large fleet of mostly inactive drones a bit more hidden is almost certainly easier than keeping anything in motion and constant communication hidden.

Is it necessarily a good idea? Probably not? I was only poking at the "first principals" taking the assumption of constant radio communication as a given. Why? We don't even assume that for submarines with people on them.

Which, yes, we have people there so that they can think and respond with situational awareness to events. And I'm fully agreed that we don't want to jump straight to AI to replace people completely. But I also don't know why you wouldn't build a bit more smarts into deployments? And fully expect some of this to happen. (Realistically, I'm largely describing what science fiction used to imagine mine fields are like in the ocean?)


> You presume it has to be incredibly long range?

No. But you seem to presume engineers working on underwater communication are brainless morons.


No, I presume most of the press is brainless morons when it comes to talking about what the military is likely doing.

I assure you, you realize very quickly that most of military procurement are also brainless morons when you have to talk to them.

There's a big disconnect between the military and actual engineering. Yes, that one magic Xilinx part is cool, but you don't need to blow $10k extra on literally everything you buy. They suffer buzzwords and fads the same way everyone in civilian C suite does.


Ha! Fair. I should have scoped my statement largely to arm chair quarterbacks on the internet. With the full understanding and endorsement of what that implies about my contributions! :D

> Rallye stopped the insanity when Henri Toivonen burnt to death.

Alone it probably would not have done it, but the sanity of Group B (or lack thereof) had been in question for a while: earlier in the same season Joaquim Santos lost control of his car after avoiding a group of spectators (who'd routinely play chicken with cars) resulting in 3 deaths and 30 injuries.

And the previous season Bettega had died on the same course Toivonen and Cresto lost their lives on, and Vatanen was gravely injured in Argentina.


> who'd routinely play chicken with cars

I've never seen this, but can only imagine the stupidity of these spectators. To solve that, I'd have been in favor of awarding bonus points to drivers not avoid these "chickens"


Watch this: https://www.youtube.com/watch?v=6I5sTuSoMho

The drivers went all out straight onto the people and could only hope they would get away on time.


> I've never seen this, but can only imagine the stupidity of these spectators.

Unless you're 50+ you could never have seen it because it's long stopped. But watch old videos of group b and you'll see it, it was insane.


Tbh Group B had a problem of crowd control, not with the cars themselves.

Those Lancias hnnng


While that was a problem, the larger one was that the cars were too fast for the tires and safety equipment of the time.

In a 13 month period there were three fatal accidents that were down to drivers losing control and crashing on their own. The last two coming in successive months. The repeated accidents killed off Group B and the nascent Group S that was supposed to replace it.

Modern WRC cars much higher cornering speeds than the Group B cars because of advances in tire technology. They aren’t as fast in a straight line, but they are massively safer in the event of a crash.


Group B absolutely had a cars problem, 3 of the 4 accidents mentioned were not crowd related, there was literally no close witness (only a video from far away) to Toivonen and Cresta's accident.

The Lancias were some of the worst offenders to the cars issue, but not the only one: many drivers complained that the cars had gotten way too powerful to be safe in Corsica.

And safety equipment was lacking and not consistently applied, for instance fuel tank skid plates were usually left off on asphalt tracks like corsica, which is likely how Toivonen's lancia instantly caught fire when it went off the road.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: