Live data from Hacker News

Make Ubuntu packages 90% faster by rebuilding them

gist.github.com

101–110 of 375 posts

Re: Make Ubuntu packages 90% faster by rebuilding them

#101
post #45

Misleading title, it's 90% of the faster time. It's about 45% faster. It's actually a little bit interesting, if you are interested in how we use language. You could argue that now you now get 90% more work done in the same amount of time, and that would align with other 'speed' units that we commonly use (miles per hour, words per minute, bits per second). However, the convention in computer performance is to measur…

I think you're right. I think you could say the package (as in the code) is 45% faster or that the package increases parsing rate by 90%. But mixing the two is confusing.

I think it's an interpretation issue. When you say it's 45% faster I interpret that as "the new package handles work at a rate of 145% when compared to the original, that is, 1.45 times as fast".

I would rephrase your comment as "the package takes 45% less time to process a given data set".

Re: Make Ubuntu packages 90% faster by rebuilding them

#102
post #69
post #59

Earlier quoted context omitted.

I would, and there is no shame in it, as far as I'm concerned. I don't need to outrun the bear. I just need to outrun you.

ASLR is not security through obscurity though. It forces attacker to get a pointer leak before doing almost anything (even arbitrary read and arbitrary write primitives are useless without a leak with ASLR). As someone with a bit of experience in exploit dev, it makes a world of a difference and is one of the most influential hardenings, next to maybe stack cookies and W^X.

ASLR is by definition security through obscurity. That doesn't make it useless, as there's nothing wrong with using obscurity as one layer of defenses. But that doesn't change what it fundamentally is: obscuring information so that an attacker has to work harder.

Re: Make Ubuntu packages 90% faster by rebuilding them

#103
post #69

Earlier quoted context omitted.

ASLR is not security through obscurity though. It forces attacker to get a pointer leak before doing almost anything (even arbitrary read and arbitrary write primitives are useless without a leak with ASLR). As someone with a bit of experience in exploit dev, it makes a world of a difference and is one of the most influential hardenings, next to maybe stack cookies and W^X.

I'm genuinely curious what was so undesirable about this sibling comment that it was removed: "ASLR obscures the memory layout. That is security by obscurity by definition. People thought this was okay if the entropy was high enough, but then the ASLR⊕Cache attack was published and now its usefulness is questionable." Usually when a comment is removed, it's pretty obvious why, but in this case I'm really not seeing i…

I assume people downvoted it because “ASLR obscures the memory layout. That is security by obscurity by definition” is just wrong (correct description here: https://news.ycombinator.com/item?id=43408039). It does say [flagged] too, though, so maybe that’s not the whole story…?

Re: Make Ubuntu packages 90% faster by rebuilding them

#104

[flagged]

Today it's 2.2GB of JSON files, tomorrow it's tens of petabytes of archived data that you need to look through for work. A speedup of 2x is nothing to scoff at.

As a broader comment though, this is how we learn and discover things. Just because the specific outcome here is "trivial" doesn't mean the approach or the lessons learnt aren't valuable.

I found it an interesting read despite not have any stake in the outcome.

Re: Make Ubuntu packages 90% faster by rebuilding them

#105
post #69

Earlier quoted context omitted.

ASLR is not security through obscurity though. It forces attacker to get a pointer leak before doing almost anything (even arbitrary read and arbitrary write primitives are useless without a leak with ASLR). As someone with a bit of experience in exploit dev, it makes a world of a difference and is one of the most influential hardenings, next to maybe stack cookies and W^X.

I'm genuinely curious what was so undesirable about this sibling comment that it was removed: "ASLR obscures the memory layout. That is security by obscurity by definition. People thought this was okay if the entropy was high enough, but then the ASLR⊕Cache attack was published and now its usefulness is questionable." Usually when a comment is removed, it's pretty obvious why, but in this case I'm really not seeing i…

Some people use the "flag" button as a "disagree" button or even a "fuck this guy" button. Unfortunately, constructive but unpopular comments get flagged to death on HN all the time.

Re: Make Ubuntu packages 90% faster by rebuilding them

#106

Earlier quoted context omitted.

I'm genuinely curious what was so undesirable about this sibling comment that it was removed: "ASLR obscures the memory layout. That is security by obscurity by definition. People thought this was okay if the entropy was high enough, but then the ASLR⊕Cache attack was published and now its usefulness is questionable." Usually when a comment is removed, it's pretty obvious why, but in this case I'm really not seeing i…

I assume people downvoted it because “ASLR obscures the memory layout. That is security by obscurity by definition” is just wrong (correct description here: https://news.ycombinator.com/item?id=43408039 ). It does say [flagged] too, though, so maybe that’s not the whole story…?

No, that other definition is the incorrect one. Security by obscurity does not require that the attacker is ignorant of the fact you're using it. Say I have an IPv6 network with no firewall, simply relying on the difficulty of scanning the address space. I think that people would agree that I'm using security by obscurity, even if the attacker somehow found out I was doing this. The correct definition is simply "using obscurity as a security defense mechanism", nothing more.

Re: Make Ubuntu packages 90% faster by rebuilding them

#107
post #76

Earlier quoted context omitted.

Are you arguing that ASLR is “security via obscurity”?

ASLR is technically a form of security by obscurity. The obscurity here being the memory layout. The reason nobody treated it that way was the high entropy that ASLR had on 64-bit, but the ASLR⊕Cache attack has undermined that significantly. You really do not want ASLR to be what determines whether an attacker takes control of your machine if you care about having a secure system.

[deleted]

Re: Make Ubuntu packages 90% faster by rebuilding them

#108

Earlier quoted context omitted.

I assume people downvoted it because “ASLR obscures the memory layout. That is security by obscurity by definition” is just wrong (correct description here: https://news.ycombinator.com/item?id=43408039 ). It does say [flagged] too, though, so maybe that’s not the whole story…?

No, that other definition is the incorrect one. Security by obscurity does not require that the attacker is ignorant of the fact you're using it. Say I have an IPv6 network with no firewall, simply relying on the difficulty of scanning the address space. I think that people would agree that I'm using security by obscurity, even if the attacker somehow found out I was doing this. The correct definition is simply "usin…

No, I would not agree that you would be using security by obscurity in that example. Not all security that happens to be weak or fragile and involves secret information somewhere is security by obscurity – it’s specifically the security measure that has to be secret. Of course, there’s not a hard line dividing secret information between categories like “key material” and “security measure”, but I would consider ASLR closer to the former side than the latter and it’s certainly not security by obscurity “by definition” (aside: the rampant misuse of that phrase is my pet peeve).

> The correct definition is simply "using obscurity as a security defense mechanism", nothing more.

This is just restating the term in more words without defining the core concept in context (“obscurity”).

Re: Make Ubuntu packages 90% faster by rebuilding them

#109
post #26

I’m almost more amazed that someone figured out jq’s syntax and got some use out of it. In all seriousness though, are you sure some of this isn’t those blocks being loaded into some kind of file system cache the second and third times? How about if you rebooted and then ran the mimalloc version?

jq has point-free programming. it's intuitive once you wrap your head around it. See this: https://en.wikipedia.org/wiki/Tacit_programming#jq

I wish I had seen this earlier. My mental model was close but not quite there to the point where I needed to think too hard about how to solve problems.

This is much more intuitive now.

Post reply on HN