Live data from Hacker News

Does memory leak? (1995)

groups.google.com

231–240 of 289 posts

Re: Does memory leak? (1995)

#231

Earlier quoted context omitted.

You’ll find that for very serious, industrial applications, a conservative mindset prevails. C may not be trendy at the moment, but it powers the computing world. Its shortcomings are also extremely well known and also statically analyzable. Also, think about when flight software started being written. Was Rust an option? And once it came out, do you expect that programmers who are responsible for millions of people’…

You're advocating throwing baby out with bathwater. Rust interops with C seamlessly, doesn't it? You don't have to throw out good code to use a better language or framework. C may be statically analyzable to some degree, but if Rust's multithreading is truly provable, then new code can be Rust and of course still use the tried and true C libraries. Disclaimer: I still haven't actually learned any Rust, so my logic is…

Rust's official documentation on FFI ( https://doc.rust-lang.org/nomicon/ffi.html ) recommends using an external crate 'libc' to facilitate even the minimal FFI functionality. This crate is not part of Rust itself. It is apparently maintained by some of Rust's developers, but again, this is not an official Rust component. To me this does not seem like the kind of mature design you would rely on for interoperability with other languages.

Re: Does memory leak? (1995)

#232
post #220

Earlier quoted context omitted.

Even with an SSD, it's still bad. Much better than the several minutes it used to take with an HDD, but still annoying. I just tried deleting a node_modules folder with 18,500 files in it, hosted on an NVMe drive. Deleting from Windows Explorer, it took 20s. But then I tried `rmdir /s /q` from your SU link - 4s! I remember trying tricks like this back with an HDD, but don't remember it having such a dramatic impact.

>>> You've got time to make a cup of coffee if you need to delete a node_modules folder... > Deleting from Windows Explorer, it took 20s. > `rmdir /s /q` from your SU link - 4s OK, so you saw that your scenarios could run much better, especially if Windows Explorer is avoided. But in Explorer, is that time you measured with deleting to the Recycle Bin or with the Shift Delete (which deletes irreversibly but can be fa…

I pretty much exclusively use SHIFT-DEL (which has once or twice resulted in bad times!).

I didn't think about renaming then deleting - that's quite a nice workaround!

Re: Does memory leak? (1995)

#233
post #196
post #189

Earlier quoted context omitted.

What's your moral stance on developing defense mechanisms against Slaughterbot attacks? What if the best defense mechanism is killing the ones launching the attacks?

I think developing defense mechanisms against Slaughterbot attacks is a good idea, because certainly they will happen sooner or later. If the best defense mechanism is killing the ones launching the attacks, we will see several significant consequences: 1. Power will only be exercised by the anonymous and the reckless; government transparency will become a thing of the past. If killing the judge who ruled against you…

You paint a bleak future. Keep in mind though, there have been many dark moments in human history when a lot of people got killed for very bad reasons, and yet here we are.

is as easy and anonymous as buying porn on Amazon

I'm not sure ease of use is such a game changer. You can buy a drone today, completely anonymously, strap some explosives to it, remotely fly it into someone and detonate it, a few hundred yards away from you. Easily available cheap drones like that existed for at least a decade, yet I don't remember many cases where someone used them for this purpose. Does Slaughterbot-like product existence make it easier? If some terrorist wants to kill a bunch of people, how is it easier than just detonating a truck full of C4? To a terrorist this technology does not provide that much benefit over what's already available. How about governments? I don't see it - if a government wants someone dead, they will be dead (either officially, e.g. Bin Laden, or unofficially, Epstein-style). If a government wants a bunch of people dead, the difficulty lies not in technology, but in PR. I doubt there is a lack of trigger happy black ops types (or "patriots") ready to do whatever you can program a drone to do. Here I'm talking about democratic first world governments. It's even less clear if tyrannical governments would benefit a lot from this technology - sending a bunch of agents to arrest and execute people is just as effective. I don't think tactical difficulties of finding and physically shooting people is a big concern for decision makers. As you yourself pointed out, Khmer Rouge or North Korea had no problems doing that without any advanced technology.

you must kill them before they have a chance to deploy their forces.

Yes. And that's how it has been at least since 9/11 - CIA drone strikes all over the world. Honestly, I'd much rather have them only have done drone strikes if at all possible (instead of invading Iraq with boots on the ground).

more rapid and complete than nuclear weapons could ever have threatened

Sorry, I'm not seeing it - how would this change major conflicts and battlefields? If you have a battlefield, and you know who your enemy is, you don't really need Slaughterbots - you need big guns and missiles that can do real damage. It's much easier to defend soldiers against tiny drones than against heavy fire. If you don't know who your enemy is, say terrorists mixed in the crowd of civilians, how would face detection help you? As for precise military strikes - we're already doing it with drones, so nothing new here.

end up with everyone inevitably dead within a few days enjoy what remains of our lives before it ends them

You are being overly dramatic. Yes, terrorists and evil governments will keep murdering people just like they always have. No, this technology does not make it fundamentally easier. Is the world today a scary place to live in? Yes, but for very different reasons - think about what will start happening in a few decades when the global temperature rises a couple degrees, triggering potentially cataclysmic events affecting livelihood of millions, or global pollution contaminating air, water and food to the point where it's making people sick. I really hope we will develop advanced technology by that time to deal with those issues.

But of course it's way more fun to discuss advanced defense methods against killer drones. So let's do that :) I was thinking that some kind of a small EMP device could have been used whenever slaughterbots are detected, but after reading a little about EMPs it seems it would not be able to hurt them much because these drones are so small. I don't think nets of any kind would be effective - I just don't see how would you cover a city with nets. Underground fortresses and off-planet camps can only protect a small number of people. In some scenarios some kind of laser based defense system could be effective (deployed in high value/risk environments), and of course we can keep tons of similar drones ready to attack other drones at multiple locations throughout the city. Neither of these seem to be particularly effective against a large scale attack, and both require very good mass surveillance. I think that a combination of very pervasive surveillance with an ability to deliver defense drones quickly to the area of the attack (perhaps carried in a missile, fired automatically as soon as a threat level calculated by the surveillance system crosses some threshold) is the best option. The defense drones could be much more expensive than the attack drones, so be able to quickly eliminate them. Fascinating engineering challenge!

Re: Does memory leak? (1995)

#234
post #13

I think it's a bad mindset to leak resources even when it doesn't effectively matter. In non-garbage collected languages especially, because it's important to keep in mind who owns what and for how long. It also makes refactoring easier because leaked resources effectively become some sort of implicit global state you need to keep track of. If a function that was originally called only once at startup is not called r…

I think you are conflating two issues: while one should understand who owns what and for how long, it does not follow that one should always free resources even when it is not necessary, if doing so adds complexity and therefore more things to go wrong, or if it makes things slower than optimal. In this particular case, correctness was not primarily assured by a massive amount of testing (though that may have been do…

I feel like I've read about some rocket launch failures that were caused in part by launch delays leading to overflow and sign flipping, but can't find it now =/

It may be unwise to overide static analysis (a leak is found) with hueristics (the program won't run long enough to matter)

Re: Does memory leak? (1995)

#235

Earlier quoted context omitted.

https://sourceware.org/glibc/wiki/MallocInternals#Arenas_and...

Seems like a bit of an ideosyncratic use of the word. In tcmalloc these per thread zones are just called the thread cache (hence the name "thread caching malloc").

Glibc’s malloc has its own thread cache, which contains small chunks that can be accessed without locking at all: https://sourceware.org/glibc/wiki/MallocInternals#Thread_Loc.... (Interestingly, this cache used to be so optimized for speed at some point that it made a popular target for attackers, because it lacked many safety checks.)

Re: Does memory leak? (1995)

#236

Earlier quoted context omitted.

So I kind of disagree with the idea that arenas are all about deallocation at once. There's other contexts where you have separate arenas but don't plan on deallocating in blocks, mainly around when you have memory with different underlying semantics. "This block of memory is faster, but not coherent and needs to be manually flushed for DMA", "this block of memory is fastest but just not DMA capable at all", "there's…

I can’t remember the last time I read C code, but I do recall a particular time when I was reading a library that had been written with a great deal of attention to reliability. The first thing it did was allocate enough memory for the shutdown operations. That way on a malloc() failure, it could still do a a completely orderly shutdown. Or never start in the first place. From that standpoint, you could also categori…

> The first thing it did was allocate enough memory for the shutdown operations.

That is clever and beautiful. Have to look for chances to do similar to see if I can establish a new habit myself.

Re: Does memory leak? (1995)

#237

Earlier quoted context omitted.

First time I’ve heard of someone accepting or not accepting a job based on peer perception. Maybe you should re-evaluate who your peers are if they can’t accept you for your career choices?

Or maybe they trust/value their peer's judgement despite the fact that they themselves don't have any strong views on the subject?

Relying on other's opinions to make one of the most important decisions in your life -- where you will spend 40 hours or more week -- is pathetic. It's one thing to "trust/value" their peer's judgement, but it's quite another for their opinions to make your decisions for you. Good luck with that. Haha.

Re: Does memory leak? (1995)

#238

Earlier quoted context omitted.

You’ll find that for very serious, industrial applications, a conservative mindset prevails. C may not be trendy at the moment, but it powers the computing world. Its shortcomings are also extremely well known and also statically analyzable. Also, think about when flight software started being written. Was Rust an option? And once it came out, do you expect that programmers who are responsible for millions of people’…

Ada has existed for 40 years. This directly means it has nothing to do with being conservative.

And how many people know Ada vs. C? Orders of magnitude more right?

I think that’s the problem here - it’s important to analyze orders of magnitude accurately. C isn’t a little more conservative than Rust or Ada. It is orders of magnitude more conservative.

Re: Does memory leak? (1995)

#239

Earlier quoted context omitted.

You’ll find that for very serious, industrial applications, a conservative mindset prevails. C may not be trendy at the moment, but it powers the computing world. Its shortcomings are also extremely well known and also statically analyzable. Also, think about when flight software started being written. Was Rust an option? And once it came out, do you expect that programmers who are responsible for millions of people’…

> I can’t think of anything more important or critical than software that runs on a commercial airplane. Nuclear reactors?

I should have said “commercial airplanes are among the most important and critical things that use software.” It’s obviously difficult to determine the objective most important use case.

Re: Does memory leak? (1995)

#240

Earlier quoted context omitted.

> Rust interops with C seamlessly, doesn't it? From someone who works in a mixed C + Rust codebase daily (Something like 2-3M lines of C and 100k lines of Rust), yes and no. They're pretty much ABI compatible, so it's trivial to make calls across the FFI boundary. But each language has its own set of different guarantees it provides and assumes , so it's easy to violate one of those guarantees when crossing a FFI bou…

> On the rust side, it's that, plus the pointer must point to a valid region of memory (non-null) even if the slice is empty. Do you have a citation for that, because it seems obviously wrong[0] (since the slice points to zero bytes of memory) and I'm having trouble coming up with any situation that would justify it (except possibly using a NULL pointer to indicate the Nothing case of a Maybe datum)? 0: by which I me…

Well the docs have this to say [1]:

`data` must be non-null and aligned even for zero-length slices. One reason for this is that enum layout optimizations may rely on references (including slices of any length) being aligned and non-null to distinguish them from other data. You can obtain a pointer that is usable as data for zero-length slices using NonNull::dangling().

So yes, this requirement allows optimizations like having Option be the same size as &[T] (I just tested and this is the case today: both are the same size).

I'm not convinced that it's "wrong", though. If you want to be able to support slices of zero elements (without using an option/maybe type) you have to put something in the pointer field. C generally chooses NULL, Rust happens to choose a different value. But they're both somewhat arbitrary values. It's not immediately obvious to me that one is a better choice than the other.

[1] https://doc.rust-lang.org/std/slice/fn.from_raw_parts.html

Post reply on HN