Hacker Newsnew | past | comments | ask | show | jobs | submit | Joker_vD's commentslogin

Windows "figured it out sooner" because it never really had to seriously deal with overcommitting memory: there is no fork(), so the memory usage figures of the processes are accurate. On Linux, however, the un-negotiable existence of fork() really leaves one with no truly good solution (and this has been debated for decades).

> Like if the FBI subpoenas my public key and I comply, that’s helping them?

If you're helping the FBI to do their job (conducting federal investigations), then yes, you are helping the FBI. Unless your definition of "to help" includes the absence of any possibly coercive circumstance.


An, so just semantics about “to help” and whether it involves volition.

> I suspect many people don't even know they are uncountable.

Well, most English speakers may not know the term, but they can feel the concept just fine.

> In French we can have both: le logiciel as some uncountable mass, or un/des/N logiciels if you need to count them.

This mostly works in English (and other European languages) as well, e.g. "Two teas/beers, please" etc. But in English this turn of phrase is much more restricted which is indeed a shame.

And let's not even start with pluralia tantum.


> Well, most English speakers may not know the term, but they can feel the concept just fine.

Oh yeah, I should have specified, I was speaking about non native speakers, and thinking about people speaking French or a similar language.


> MWI proponents have always argued decoherence leads to the entire world being put into superposition as decoherence just spreads entanglement to the environment.

Well, duh. It's not like classic objects actually exist, or the classical/quantum divide: everything is quantum, including the "observers". The "classical observer" is a crude approximation that breaks down to a pointy enough question. Just like shorting the perfect battery (with zero internal resistance) with a perfect wire (with zero external resistance) — this scenario is not an approximation of any possible real scenario so it's paradoxicality (infinite current!) is irrelevant.


Huh. Why is this emergency pool not statically allocated? Is it possible to tune the size of this pool on libc++ startup somehow? Because otherwise it absolutely should've been statically allocated.

I did mention it briefly in the post, but you can opt-in for a fixed-size statically allocated buffer by configuring libstdc++ with --enable-libstdcxx-static-eh-pool. Also, you can opt-out of the pool entirely by configuring the number of objects in the pool to zero with the environment variable GLIBCXX_TUNABLES=glibcxx.eh_pool.obj_count=0.

I wonder why it’s opt-in. Maybe it’s part of the whole “you only pay for what you use” ethos, i.e. you shouldn’t have to pay the cost for a static emergency pool if you don’t even use dynamic memory allocation.

    The use of these hook functions is not safe in multithreaded
    programs, and they are now deprecated.  From glibc 2.24 onwards,
    the __malloc_initialize_hook variable has been removed from the
    API, and from glibc 2.34 onwards, all the hook variables have been
    removed from the API.  Programmers should instead preempt calls to
    the relevant functions by defining and exporting malloc(), free(),
    realloc(), and calloc().

Yeah. Shame though because it gave you the option to control exactly when you hooked and didn't hook, which let stop and start debugging allocations based on arbitrary triggers.

The global variable approach was very useful and pretty low overhead.


You can still override malloc and call __libc_malloc if you do not want to bother with dlsym/RTLD_NEXT. These function aliases are undocumented, but for a quick experiment, that shouldn't matter.

If you only wanted to observe the behavior the post is discussing, it seems like `ltrace -e malloc` is a lot easier.

Yeah, the commercial firms invented them all on their own just to keep tracking customers and oversharing whatever data they gather with random third parties while still getting to complain about stupid laws that require them to do so [0].

[0] https://news.ycombinator.com/item?id=46521179


The EU's own government agencies use cookie banners on their websites.

> Microstamping requirements for guns

Eh, sounds kinda reasonable. Ammo already has unique serial numbers embedded in the butt of every cartridge (in some countries, not sure about the US), and guns do leave somewhat unique marks on the bullets upon firing so... sure, why not. Surprised it took that long TBF, the necessary technology has been commercially available since the early 90s, I think?

> 3D printers should have a magical algorithm to recognize all gun parts in their tiny embedded systems

Yeah, this one's seems unnecessary. Is weapon manufacturing without a license a crime? If yes, then whoever 3D-prints a gun can be prosecuted normally.

> Now, you need to verify your age... on your microwave?

Or on your gas stove. A travesty, really: I was taught how to operate a stove when I was in the second grade and never burned any houses down, thank you very much.


The micro stamping law is in no way reasonable because removing the micro stamping from the end of a firing pin is laughably trivial. The only people who won’t do this are people who weren’t going to break the law in the first place.

Even people who didn’t want to break the law might find themselves on the receiving end of law-enforcement if the firing pin wears such that the micro stamping is no longer identifiable.

The micro stamping law does nothing to prevent the flow of guns to people who should not have them, and does everything to prevent the use or purchase of guns by people who can lawfully own them - which is the whole point of a law like this. The people who make these laws are well aware of this.

The age verification law, coupled with the proposed hardware attestation that our good friend Lennart poettering is working on will ensure that anonymity on the Internet is gone. This is precisely what lawmakers are aiming for. And just like the micro stamping law, the intent of the law is not the literal word of the law.


> The micro stamping law is in no way reasonable because removing the micro stamping from the end of a firing pin is laughably trivial. The only people who won’t do this are people who weren’t going to break the law in the first place.

I'm curious, so if (when?) California ends up successfully hunting down some criminals with this, what is your new position going to be? They were going to get caught anyway, or something like that?


It'll never happen. As op said, it's laughably trivial to remove, and thus criminals will remove it.

Legitimate gun users will, at best, use their weapon in self defense, in which case they'll be sitting there waiting when the police arrive, so no need for microstamping.

The "crime of passion" so popular in TV shows are few and far between, and there's usually a huge amount of other evidence.


I think you're overestimating the intelligence of most criminals. And their gun logistics discipline.

If it were possible to do, it'd help.

Also, removing the marking mechanism would be a process crime. Process crimes are very useful for catching criminals.

Are you against serial numbers on guns too? You can always file those down.


The quote is indeed about the law being a nose of wax, to borrow an old English phrase, and how with sympathetic enough courts almost any decision could be upheld. But it's nothing new, precisely the same crime can yield drastically different judgements depending on e.g. the defensive attorney's experience.

> e.g. the defensive attorney's experience.

Which is another way of saying the defense's wealth.


> $system_stack_size

Does such thing even exist? And non-64 bit platforms the address space is small enough that with several threads of execution you may just be unable to grow your stack even up to $system_stack_size because it'd bump into something else.


> Does such thing even exist?

AFAIK no. There are default stack sizes, but they're just that, defaults, and they can vary on the same system: main thread stacks are generally 8MiB (except for Windows where it's just 1) but the size of ancillary stacks is much smaller everywhere but on linux using glibc.

It should be possible to get the stack root and size using `pthread_getattr_np`, but I don't know if there's anyone bothering with that, and it's a glibc extension.


.NET bothers with it, to support RuntimeHelpers.EnsureSufficientExecutionStack [1] and other things. See the pthreads calls used to here [2].

[1]: https://learn.microsoft.com/en-us/dotnet/api/system.runtime....

[2]: https://github.com/dotnet/runtime/blob/b6a3e784f0bb418fd2fa7...


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

Search: