Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Make Ubuntu packages 90% faster by rebuilding them

gist.github.com

Post reply on HN
Print view View original

341–350 of 375 posts

Re: Make Ubuntu packages 90% faster by rebuilding them

#341

Post by 77pt77 »

m000 wrote: post #314
77pt77 wrote: post #73

If you decide to go down this road just use Gentoo.

I haven't kept up with Gentoo. How long does it take these days to bootstrap a functional desktop from source? I remember when it was my main driver back in early '00s, running on a horribly underpowered PII at 266MHz. It would often be compiling 24/7 to keep up with the updates.

Haven't used it in a looong time, but by 2010 it was no longer that bad.

My first install was 2002 and it took my a good 24 hours to get X to boot.

It did catch a faulty memory DIM later on because the linking kept failing intermittently.

Re: Make Ubuntu packages 90% faster by rebuilding them

#342

Post by otsukare »

marcodiego wrote: post #14

Or, if you want to do it pain free, install guix on it.

How would you do the things mentioned in the article using Guix?

You could write your own custom package definitions, extending the default to change up compile flags and allocators, but then you need to do this for every single package (and maintain them all). I'm not sure Guix gives you much here, though maybe that's fine for one or two packages.

The most pain-free option I can think of is the --tune flag (which is similar to applying -march=native), but packages have to be defined as tunable for it to work (and not many are).

Is there another option?

Re: Make Ubuntu packages 90% faster by rebuilding them

#343

Post by usefulcat »

buttercraft wrote: post #298
usefulcat wrote: post #292

Earlier quoted context omitted.

I had thought that flagging was basically a request for a mod to have a look at something. But based on this case I now suspect that it's possible for a comment to be removed without a mod ever looking at it if enough people flag it.

Not removed but hidden. You can turn on showdead in your profile to see them.

My point was more that, at least in this case, it looks like a post was hidden without any moderator intervention.

If this is indeed what happened, it seems like a bad thing that it's even possible. Since many, perhaps most people probably don't have showdead enabled, it means that the 'flag' option is effectively a mega-downvote.

Re: Make Ubuntu packages 90% faster by rebuilding them

#344

Post by smarx007 »

ryao wrote: post #70
smarx007 wrote: post #60

Earlier quoted context omitted.

There are also many flags that should be enabled by default for non-debug builds like ubsan, stack protection, see https://news.ycombinator.com/item?id=35758898

UBSAN is usually a debug build only thing. You can run it in production for some added safety, but it comes at a performance cost and theoretically, if you test all execution paths on a debug build and fix all complaints, there should be no benefit to running it in production.

I think it's time for the C/C++ communities to consider a mindset shift and pivot to having almost all protectors, canaries, sanitizers, assertions (e.g. via _GLIBCXX_ASSERTIONS) on by default and recommended for use in release builds in production. The opposite (i.e, the current state of affairs) should be discouraged and begrudginly accepted in select few cases.

https://www.youtube.com/watch?v=gG4BJ23BFBE is a presentation that best represents my view on the kind of mindset that's long overdue to become the new norm in our industry.

Re: Make Ubuntu packages 90% faster by rebuilding them

#346

Post by fc417fc802 »

ryao wrote: post #329
fc417fc802 wrote: post #142

Earlier quoted context omitted.

I'm inclined to agree and would like to point out that if you take a hardline stance that any reliance on the attacker not knowing something makes it security by obscurity then things like keys become security by obscurity. That's obviously not a useful end result so that can't be the correct definition. It's useful to ask what the point being conveyed by the phrase is. Typically (at least as I've encountered it) it'…

What is missing from these two representations is the ability for something to become trivially bypassable once you know the trick to it. AnC is roughly that for ASLR.

I'd argue that AnC is a side channel attack. If I can obtain key material via a side channel that doesn't (at least in the general case) suddenly change the category of the corresponding algorithm.

Also IIUC to perform AnC you need to already have arbitrary code execution. That's a pretty big caveat for an attacker.

Re: Make Ubuntu packages 90% faster by rebuilding them

#348

Post by hy4000days »

m000 wrote: post #314
77pt77 wrote: post #73

If you decide to go down this road just use Gentoo.

I haven't kept up with Gentoo. How long does it take these days to bootstrap a functional desktop from source? I remember when it was my main driver back in early '00s, running on a horribly underpowered PII at 266MHz. It would often be compiling 24/7 to keep up with the updates.

[dead]

Re: Make Ubuntu packages 90% faster by rebuilding them

#349

Post by hy4000days »

77pt77 wrote: post #341
m000 wrote: post #314

Earlier quoted context omitted.

I haven't kept up with Gentoo. How long does it take these days to bootstrap a functional desktop from source? I remember when it was my main driver back in early '00s, running on a horribly underpowered PII at 266MHz. It would often be compiling 24/7 to keep up with the updates.

Haven't used it in a looong time, but by 2010 it was no longer that bad. My first install was 2002 and it took my a good 24 hours to get X to boot. It did catch a faulty memory DIM later on because the linking kept failing intermittently.

[dead]
Post reply on HN