Live data from Hacker News

Make Ubuntu packages 90% faster by rebuilding them

gist.github.com

151–160 of 375 posts

Re: Make Ubuntu packages 90% faster by rebuilding them

#151
post #86

Gentoo linux is essentially made specifically for people like this, to be able to optimize one’s own linux rig for one’s specific usecase. After initial setup, it’s pretty simple and easy to use, I remember making a ton of friends at matrix’s Gentoo Linux channel, was fun times. https://www.gentoo.org/ Fun fact, initial ChromeOS was basically just custom Gentoo Linux install, I’m not sure if they still use Gentoo Lin…

> Gentoo linux is essentially made specifically for people like this, to be able to optimize one’s own linux rig for one’s specific usecase. That's true but worth noting that "optimize" here doesn't necessarily refer to performance. I've been using Gentoo for 20 years and performance was never the reason. Gentoo is great if you know how you want things to work. Gentoo helps you get there.

If it wasn't for performance, what was gained in using it over something like Slackware and building only the packages you needed to?

Re: Make Ubuntu packages 90% faster by rebuilding them

#152

Engineering is a compromise. The article shows most gains come from specialising the memory allocater. The thing to remember is that some projects are multithreaded, and allocate in one thread, use data in another and maybe deallocate in a 3rd. The allocator needs to handle this. So a speedup for one project may be a crash in another. Also, what about reallocation strategy? Some programs preallocate and never touch m…

That’s why it’s a bad idea to use one allocator for everything in existence . It’s terrible that everyone pays the cost of thread safety even for single threaded applications - or even multithreaded applications with disciplined resource management.

Re: Make Ubuntu packages 90% faster by rebuilding them

#153
post #48

Earlier quoted context omitted.

Load bearing assertions. Even Design by Contract in Eiffel turns off assertions in production.

Just because it's turned off by default doesn't mean it isn't load bearing. If you didn't ever encounter an ASSERT with side effects that were crucial to proper functioning, you just haven't seen enough ASSERT statements. Rule #1 of programming: If it can go wrong, it will.

That's before we even consider instances where assert was used to check a condition that should always be verified. In my personal projects I define a "require" macro that I use liberally.

Re: Make Ubuntu packages 90% faster by rebuilding them

#156
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 believe most people see security through obscurity has an attempt to hide an insecurity.

ASLR/KASLR intends to make attackers lives harder by having non consistent offsets of known data structures. Its not obscuring a security flaw, instead its raises an attacks 'single run' effectivness.

The ASLR attack that i believe is being referenced is specific to abuse within the browser, and running with a single process. This single attack vector does not mean that KASLR globally is not effective.

Your quote has some choice words, but its contextually poor.

Re: Make Ubuntu packages 90% faster by rebuilding them

#159
post #86

Earlier quoted context omitted.

> Gentoo linux is essentially made specifically for people like this, to be able to optimize one’s own linux rig for one’s specific usecase. That's true but worth noting that "optimize" here doesn't necessarily refer to performance. I've been using Gentoo for 20 years and performance was never the reason. Gentoo is great if you know how you want things to work. Gentoo helps you get there.

If it wasn't for performance, what was gained in using it over something like Slackware and building only the packages you needed to?

Long time ago when I was using it I preferred Gentoo because of ergonomics and better exposition to supply chain.

Slackware was very manual and some bits were drowned in its low level and long command chains. Gentoo felt easy but highlighted dependencies with a hard cost associated with compilation times.

Being a newb back then I enjoyed user friendliness with access to the machinery beneath. Satisfaction of a 1s boot time speedu, a result of 48h+ compilation, was unparalleled, too ;)

Re: Make Ubuntu packages 90% faster by rebuilding them

#160
post #99

ClickHouse will be faster for processing large JSON data files. The example from the gist will look like follows: ch -q "WITH arrayJoin(features) AS f SELECT f.properties.SitusCity WHERE f.properties.TotalNetValue Reference: https://jsonbench.com/

I'm willing to believe that will execute in less than 2 seconds, but it doesn't work as given.

Can you post a link to the JSON file?

Try this (the placement of FROM was incorrect):

    ch "WITH arrayJoin(features) AS f SELECT f.properties.SitusCity FROM 'a.json' WHERE f.properties.TotalNetValue 
Post reply on HN