date:20140110

Hello Chris,

Friday, January 10, 2014, 1:08:39 AM, you wrote:

 Right here is the big problem: you're not looking at this from the
 perspective of the average Gentoo developer. We don't care about market
 share. We don't care whether we're on top for another few years. There
 are several forks of Gentoo. I doubt most devs care about them. I
 personally know that we're not going to compete with Debian, which has a
 huge contributor, or Ubuntu or Red Hat, which have whole companies
 behind them. You're selling this as if you're selling to a company which
 wants to be on the top of the market and beating out competitors, and
 that's not what we are. We are a source-based distro that requires some
 effort from users, and people want that or they don't want it.
 What we need is a vote YES or NO. If you against it - vote NO. It's
 perfectly normal, if there would be no NO there would be no need voting.

Thank you for you opinion. 

The competition in open source world is much harder than with
commercial software. 3 commercial systems share 96% of the users.

1,6% of the users are shared by 296 Linux distros

You may think that you're outside this rules but the competition is natural 
on the planet and Gentoo is certainly competing weather you want it or not.

Competition was long before a human foot stood on the ground for the first 
time :-) And suddenly there is no competition in Linux world - do you really 
belive in it?


-- 
Best regards,
 Igormailto:lanthrus...@gmail.com

Re: [gentoo-dev] Portage QOS

Hello Heroxbd,

Friday, January 10, 2014, 4:16:47 AM, you wrote:

 The ebuilds have approximately the same time to install, the failure
 rate is about the same, emerge is getting slower.

 I am curious about the slowness of emerge.

 How about profile the portage and rewrite the time-crucial part in
 C/C++, or ideally, borrowing the counterpart from paludis? How feasible
 is that?

 I guess the dep-tree calculation is the slowest part.

If you had the PortageQOS you would see what change slowed down
Portage. And the problem could have already been fixed.
You could make fast and correct decisions. True, it could be possible
that some parts of the portage need to be rewritten. May be Python was
the wrong decision, may be it's better to use C++.

(Yes, I expect to be
condemned over here before I'm banned, a sacrifice for the better Gentoo
somebody had to make).

Do you remember how many problems portage had with Python? It's like
Gentoo is for Python not for anything else.

Why not to get rid of Python at all. What is so great in Python that
Gentoo exists for the sake of it?

And when next thing is introduced - you can see how it works
world wide. 

On some older PC the new portage works for 4-6 minutes before it FAILS.

If the portage is going to be a little bit smarter again - you would need a
new hardware to run it.

And nobody cares, of course it's better to hide don't know or run from
problems than know about them and fix them.

300 devs, are NOT ABLE to make portage fast in 8 years.

-- 
Best regards,
 Igormailto:lanthrus...@gmail.com

Re: [gentoo-dev] Re: Portage QOS

Am 10.01.2014 13:10, schrieb Igor:
 Hello Chris,
 
 Friday, January 10, 2014, 1:08:39 AM, you wrote:
 
 Right here is the big problem: you're not looking at this from the
 perspective of the average Gentoo developer. We don't care about market
 share. We don't care whether we're on top for another few years. There
 are several forks of Gentoo. I doubt most devs care about them. I
 personally know that we're not going to compete with Debian, which has a
 huge contributor, or Ubuntu or Red Hat, which have whole companies
 behind them. You're selling this as if you're selling to a company which
 wants to be on the top of the market and beating out competitors, and
 that's not what we are. We are a source-based distro that requires some
 effort from users, and people want that or they don't want it.
 What we need is a vote YES or NO. If you against it - vote NO. It's
 perfectly normal, if there would be no NO there would be no need voting.
 
 Thank you for you opinion. 
 
 The competition in open source world is much harder than with
 commercial software. 3 commercial systems share 96% of the users.
 
 1,6% of the users are shared by 296 Linux distros
 
 You may think that you're outside this rules but the competition is natural 
 on the planet and Gentoo is certainly competing weather you want it or not.
 
 Competition was long before a human foot stood on the ground for the first 
 time :-) And suddenly there is no competition in Linux world - do you really 
 belive in it?

There is no really competition for the non-enterprise systems. It is a
co-existance (one might even call it some kind of symbiosis).

Please take your business nonsense somewhere else. Honestly, you sound
like some suit with his powerpoint slides talking about buzz-words like
'competitors', 'keeping in power', 'QoS' …

There were also numerous threads already about the very same topic. Most
came to the conclusions that
a) Gentoo is not dying
b) the numbers used as arguments are inaccurate at best (how do you
count 'Gentoo users'? And do you want users or machines? And what with
persons using different systems)

- René

Re: [gentoo-dev] Portage QOS

Am 10.01.2014 13:23, schrieb Igor:
 You could make fast and correct decisions. 

There is no such thing as the single correct decision. Management people
often think there is, but this is because management people often have
no clue what they are talking about.

 
 Why not to get rid of Python at all. What is so great in Python that
 Gentoo exists for the sake of it?


What is so bad with Python? Also keep in mind: A bad/wrong algorithm
does not get better just because you change the implementation language.

 
 300 devs, are NOT ABLE to make portage fast in 8 years.
 

You obviously have no idea how Gentoo works.

- René

Re: [gentoo-dev] Portage QOS

Hello Heroxbd,

Friday, January 10, 2014, 4:16:47 AM, you wrote:

 The ebuilds have approximately the same time to install, the failure
 rate is about the same, emerge is getting slower.

 I am curious about the slowness of emerge.

 How about profile the portage and rewrite the time-crucial part in
 C/C++, or ideally, borrowing the counterpart from paludis? How feasible
 is that?

 I guess the dep-tree calculation is the slowest part.

And to think about it - Python is a slow big snake. And Gentoo is the
fastest of penguins.

So why do we send Gentoo for food riding on Python? If it were death
we send Gentoo for then I would choose Python but food?

Isn't it making them both slow and food isn't coming? 



-- 
Best regards,
 Igormailto:lanthrus...@gmail.com

Re: [gentoo-dev] Portage QOS

2014-01-10 Thread Patrick Lauer

On 01/10/2014 08:30 PM, Igor wrote:
 Hello Heroxbd,
 
 Friday, January 10, 2014, 4:16:47 AM, you wrote:
 
 The ebuilds have approximately the same time to install, the failure
 rate is about the same, emerge is getting slower.
 
 I am curious about the slowness of emerge.
 
 How about profile the portage and rewrite the time-crucial part in
 C/C++, or ideally, borrowing the counterpart from paludis? How feasible
 is that?
 
 I guess the dep-tree calculation is the slowest part.
 
 And to think about it - Python is a slow big snake. And Gentoo is the
 fastest of penguins.

No, Python isn't slow.

Bad code is bad. You can write bad code in any language.
 
 So why do we send Gentoo for food riding on Python? If it were death
 we send Gentoo for then I would choose Python but food?

I'm finding it very hard to stay polite, because ... honestly?

You have no idea what you're talking about.

If you want things to change - hire a few of us fulltime to work on
things, and you'll get the change you want.
Until then there's no need to point out that we are lacking manpower to
do large-scale changes, because that's been a constant in most
opensource projects since the 1960s.

Less talking, more doing - provide patches and stop polluting our
mailing list with your madness.

Re: [gentoo-dev] Portage QOS

Hello Heroxbd,

Friday, January 10, 2014, 4:27:00 AM, you wrote:

 IMHO, the bleeding-edgeness and stability form a balance. We cannot
 achieve both. Taking RHEL for example, it uses ancient software for the
 sake of stability. Gentoo is way off the other extreme.

 For the udev change, the upstream has been doing evil and eudev is not
 introduced as the default for Gentoo (yet).

 New software breaks things, and security-updated old software needs
 extra care: That's the fundamental problem we couldn't circumvent.

True, it's fundamentally impossible for Gentoo to get rid of all the
problems with ebuilds.

What I offer is to make the response and self-assessment on Gentoo
changes automated and fast. Then it will be getting better by itself.
The rate of experience Dev is attaining will jump several times up and
the level drudgery will decrease in the same proportion.

And it's perfectly in Gentoo style. This is the fastest penguin,
erroneously married to a snake because the marriage looked easy from
the first but now it's getting harder and harder.

We have the Penguin but forgot to add neurons to his skin.

He is poked but doesn't know about that and doesn't respond
because he can't feel.

-- 
Best regards,
 Igormailto:lanthrus...@gmail.com

Re: [gentoo-dev] Re: Portage QOS

Hello René,

Friday, January 10, 2014, 4:26:03 PM, you wrote:


 You may think that you're outside this rules but the competition is natural 
 on the planet and Gentoo is certainly competing weather you want it or not.

 Competition was long before a human foot stood on the ground for the first 
 time :-) And suddenly there is no competition in Linux world - do you really 
 belive in it?

 There is no really competition for the non-enterprise systems. It is a
 co-existance (one might even call it some kind of symbiosis).

 Please take your business nonsense somewhere else. Honestly, you sound
 like some suit with his powerpoint slides talking about buzz-words like
 'competitors', 'keeping in power', 'QoS' …

 There were also numerous threads already about the very same topic. Most
 came to the conclusions that
 a) Gentoo is not dying
 b) the numbers used as arguments are inaccurate at best (how do you
 count 'Gentoo users'? And do you want users or machines? And what with
 persons using different systems)

You're living right not in competition. If you're on an island
you compete with animals for food and water. If you're in a condo - hell, 
you know how many on this planet WISH to live in your house right now and 
what stops them from doing that?

And you belive that you're outside competition. It looks unreal.
Gentoo is in competition with other distros - it's real and happens
right now.

Are you absolutely sure that in the condition when nobody knows how
Portage works we may go that far as saying we have a healthy Penguin?

-- 
Best regards,
 Igormailto:lanthrus...@gmail.com

Re: [gentoo-dev] Re: Portage QOS

Am 10.01.2014 13:52, schrieb Igor:
 And you belive that you're outside competition. It looks unreal.
 Gentoo is in competition with other distros - it's real and happens
 right now.

Again, just because this science called 'Economics' believes,
everything is in competition, does not change reality.

 Are you absolutely sure that in the condition when nobody knows how
 Portage works we may go that far as saying we have a healthy Penguin?

If I want to know whether or not a penguin is healthy, I'd ask my mum
(she's a vet).

- René

Re: [gentoo-dev] Portage QOS

Hello Patrick,

Friday, January 10, 2014, 4:39:59 PM, you wrote:

No, Python isn't slow.
Bad code is bad. You can write bad code in any language.

Are you sure? Take a look here:

http://benchmarksgame.alioth.debian.org/u32q/benchmark.php?test=alllang=python3lang2=gppdata=u32q

of course these stats are all so fake, and you may not belive them.

I've been using C/C++ since school it's fast, even bad code is working fast.

I WOULD NEVER BELIVE PYTHON IS AS FAST AS C++ with math algorithms
that do calculate staff and not call functions from pre-complied
objects written in C/C++.

It's crazy that you're even trying to state it. Take a look at what
Python is producing in disasm and then look at it in G++.

So why do we send Gentoo for food riding on Python? If it were death
we send Gentoo for then I would choose Python but food?

I'm finding it very hard to stay polite, because ... honestly?
You have no idea what you're talking about.

Or vice versa.

If you want things to change - hire a few of us fulltime to work on
things, and you'll get the change you want.
Until then there's no need to point out that we are lacking manpower to
do large-scale changes, because that's been a constant in most
opensource projects since the 1960s.

Less talking, more doing - provide patches and stop polluting our
mailing list with your madness.

See tge subject of this letter. The whole point of this conversation is that
I offered to design it and program it and offered HARDWARE for it but we
can't get to the point because it's not clear for everyone if we need it.

If high command not needing it it will find means to kill it and I'm
very busy, really very busy - can't afford to spend that much time on
something not useful.

We're in the middle of negotiations here.

--
Best regards,
Igormailto:lanthrus...@gmail.com

Re: [gentoo-dev] Portage QOS

Hello Patrick,

Friday, January 10, 2014, 4:39:59 PM, you wrote:

 Bad code is bad. You can write bad code in any language.

BTW Perl is faster than Python too. 

Try writing quick sort in Perl, Ptyhon and G++ 

then dump the memory. 

And watch the miracle.

-- 
Best regards,
 Igormailto:lanthrus...@gmail.com

Re: [gentoo-dev] Portage QOS

Am 10.01.2014 14:05, schrieb Igor:
 Hello Patrick,
 
 Friday, January 10, 2014, 4:39:59 PM, you wrote:
 
 No, Python isn't slow.
 Bad code is bad. You can write bad code in any language.
 
 Are you sure? Take a look here:
 
 http://benchmarksgame.alioth.debian.org/u32q/benchmark.php?test=alllang=python3lang2=gppdata=u32q
 
 of course these stats are all so fake, and you may not belive them.
 
 I've been using C/C++ since school it's fast, even bad code is working fast.
 
 I WOULD NEVER BELIVE PYTHON IS AS FAST AS C++ with math algorithms

You do realize, that we are not doing math (read: number crunching) here?

And again: What is needed is streamlining the algorithms (discussion on
that already started as far as I could notice). An algorithm in O(n³) is
always¹ worse than O(n). The constant factor added by the language
difference is of no interest.

 It's crazy that you're even trying to state it. Take a look at what
 Python is producing in disasm and then look at it in G++.

For a larger project, it often is more important to have readable and
maintable code opposed to getting the last bit of performance. And
Python is _far_ more readable and concise than C or C++ (imho). Due to
lack of typechecking, I'm not so sure when it comes to maintainability
though (there are test suites of course).

- René

¹ For a large enough n.

Re: [gentoo-dev] Portage QOS

2014-01-10 Thread Rich Freeman

On Fri, Jan 10, 2014 at 7:41 AM, Igor lanthrus...@gmail.com wrote:
 What I offer is to make the response and self-assessment on Gentoo
 changes automated and fast. Then it will be getting better by itself.
 The rate of experience Dev is attaining will jump several times up and
 the level drudgery will decrease in the same proportion.

Sounds great.  Don't let commentary stand in your way.  Just post a
link to your code/patches when you have something to share, or if
you're looking for contributors to join you.  That's pretty-much how
every substantial improvement to any FOSS project starts out.

Rich

Re: [gentoo-dev] Portage QOS

2014-01-10 Thread heroxbd

Hi Igor,

Igor lanthrus...@gmail.com writes:

 I've been using C/C++ since school it's fast, even bad code is working fast.

 I WOULD NEVER BELIVE PYTHON IS AS FAST AS C++ with math algorithms
 that do calculate staff and not call functions from pre-complied
 objects written in C/C++.

 It's crazy that you're even trying to state it. Take a look at what
 Python is producing in disasm and then look at it in G++.

 So why do we send Gentoo for food riding on Python? If it were death
 we send Gentoo for then I would choose Python but food?

 I'm finding it very hard to stay polite, because ... honestly?
 You have no idea what you're talking about.

 Or vice versa.

 If you want things to change - hire a few of us fulltime to work on
 things, and you'll get the change you want.
 Until then there's no need to point out that we are lacking manpower to
 do large-scale changes, because that's been a constant in most
 opensource projects since the 1960s.

 Less talking, more doing - provide patches and stop polluting our
 mailing list with your madness.

 See tge subject of this letter. The whole point of this conversation is that
 I offered to design it and program it and offered HARDWARE for it but we
 can't get to the point because it's not clear for everyone if we need it.

 If high command not needing it it will find means to kill it and I'm
 very busy, really very busy - can't afford to spend that much time on
 something not useful.

I appreciate your intension to make Gentoo better, at the same time I
could not share the view with you.

Here is the checklist for you:

1. I got a brilliant idea! goto 2
2. Can I realize it by myself?
   Y, goto 6; N goto 3
3. Can I convince someone to do it for me?
   Y, goto 6; N goto 4
4. Can I hire someone to do it for me?
   Y, goto 6; N goto 5
5. Nothing could be achieved :(
6. After rounds of hard work, it comes true :D

Seems that you got stuck at 5. Sorry if you are not willing to adjust
your attitude, your subsequent will be ignored.

Some of the details of your proposal do interest me, such as an
automatic build.log / emerge --info uploader. Supporting mail reply to
bugzilla will even be cooler (which can be used to upload build.log and
emerge --info of course).

Cheers,
Benda

Re: [gentoo-dev] Portage QOS

2014-01-10 Thread Rich Freeman

On Fri, Jan 10, 2014 at 8:10 AM, Igor lanthrus...@gmail.com wrote:
 Hello Patrick,

 Friday, January 10, 2014, 4:39:59 PM, you wrote:

 Bad code is bad. You can write bad code in any language.

 BTW Perl is faster than Python too.

 Try writing quick sort in Perl, Ptyhon and G++

 then dump the memory.

 And watch the miracle.

I think you're missing the point.

If I ask somebody who knows nothing about algorithms to sort a list in
Python they're going to use foo.sort().  If I ask somebody who knows
nothing about algorithms to sort a list in C they're going to write a
bubble sort, and it will be WAY slower for anything more than a dozen
elements.

Honestly, you're writing as if you're talking to a bunch of people who
don't know anything about how computers work, and the reality is that
you'll be hard-pressed to find an audience more familiar with
compilers/toolchains/linkers/etc just about anywhere.

If you have the right algorithm nobody is arguing that it will run
faster if compiled from correctly-written C.  The problem is that
right now we don't have the right algorithm, and we're likely to get a
lot further with fixing that faster in a language like python than in
C.

But, nobody is opposing the work - there are two alternative package
managers for Gentoo today, and one of them is full-featured.  Neither
are written in python.

Rich

Re: [gentoo-dev] Portage QOS

2014-01-10 Thread Tom Wijsman

On Fri, 10 Jan 2014 18:10:05 +0900
hero...@gentoo.org wrote:

 Tom Wijsman tom...@gentoo.org writes:
 
  I am curious about the slowness of emerge.
 
  Try a --backtrack=0 approach, I no longer need to increase it. :)
 
 on a random box:
 
 time emerge --backtrack=0 -pe @world
 [...]
 real0m30.016s
 user0m29.268s
 sys 0m0.704s
 
 time emerge -pe @world
 [...]
 real0m35.037s
 user0m30.824s
 sys 0m1.136s
 
 not a big difference?

Well, it has to actually backtrack to make a difference; if there's no
need to, it won't differ. But when there is need to, it takes longer.

That's why it has been described as dynamic; you are either affected by
a lot of backtracking or you don't, seems you are on the lucky side now.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : tom...@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D


signature.asc
Description: PGP signature

Re: [gentoo-dev] Portage QOS

2014-01-10 Thread Tom Wijsman

On Fri, 10 Jan 2014 09:02:46 -0500
Rich Freeman ri...@gentoo.org wrote:

 On Fri, Jan 10, 2014 at 8:10 AM, Igor lanthrus...@gmail.com wrote:
 If I ask somebody who knows nothing about algorithms to sort a list in
 Python they're going to use foo.sort().  If I ask somebody who knows
 nothing about algorithms to sort a list in C they're going to write a
 bubble sort, and it will be WAY slower for anything more than a dozen
 elements.

This assumes that the person doesn't do it manually in Python and
doesn't make use of already implemented functionality (eg. qsort) in C,
which jumps out as the first Google result; generalizations like these
are subjective, because it's just your view and thoughts of reality.

 Honestly, you're writing as if you're talking to a bunch of people who
 don't know anything about how computers work, and the reality is that
 you'll be hard-pressed to find an audience more familiar with
 compilers/toolchains/linkers/etc just about anywhere.

Indeed, a lot of us are CompSci students have that algorithmic
complexity drilled in since the first year. If we need performance,
we'll put it to great use; an occasional prototype, not so much.

 If you have the right algorithm nobody is arguing that it will run
 faster if compiled from correctly-written C.  The problem is that
 right now we don't have the right algorithm, and we're likely to get a
 lot further with fixing that faster in a language like python than in
 C.

Actually, language doesn't even matter here; just push that power off
button 'n get back to paper, then fix it in even faster pseudo code. :)

(Well, unless you type pseudo code faster than you write it down ... :P)

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : tom...@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D


signature.asc
Description: PGP signature

Re: [gentoo-dev] Re: [PATCH] To enable ssp default in Gcc the toolchain.eclass need some changes.

2014-01-10 Thread Magnus Granberg

torsdag 09 januari 2014 23.18.28 skrev  Ryan Hill:
 On Thu, 09 Jan 2014 21:58:46 +0100
 
 Magnus Granberg zo...@gentoo.org wrote:
  Some time ago we discussed that we should enable stack smashing
  (-fstack-protector) by default.  So we opened a bug to track this [1].
  The affected Gcc version will be 4.8.2 and newer. Only amd64, x86, mips,
  ppc, ppc64 and arm will be affected by this change.
  
  You can turn off ssp by using the nossp USE flag or by adding
  -fno-stack-protector to the CFLAGS and/or CXXFLAGS. We are using the same
  patch as Debian/Ubuntu but with some Gentoo fixes.
  
  The patch will move the sed for the HARD_CFLAGS, ALLCFLAGS and
  ALLCXXFLAGS from do_gcc_PIE_patches() to make_gcc_hard().  We will
  make_gcc_hard() the default for all Gcc versions 4.8 and newer, and turn
  it on or off with hardened_gcc_works() that will make some sanity checks.
 
 I went ahead and spun a new patchset for the compiler-side stuff if anyone
 wants to start playing around.
 
 - apply the eclass patch from bug #484714 (the one attached to Magnus' email
 wouldn't apply for me but maybe my mailer mangled it)
 - in gcc-4.8.2.ebuild do:
 
 -PATCH_VER=1.3
 +PATCH_VER=1.4-ssptest
 
 -PIE_VER=0.5.8
 +PIE_VER=0.5.9-ssptest
 
 BTW Magnus, thanks for doing this.
Hi
Have patched toolchain.eclass with the patch and with your change.
Updated 4.8.2 updated with the needed changes and commit it.
The use hardened  gcc-specs-ssp  append-cflags $(test-flags-CC -fno-stack-
protector) in glibc's common.eblit is fixed to.
So default ssp is out in the tree :)
/Magnus



signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] Re: Portage QOS

2014-01-10 Thread Tom Wijsman

On Fri, 10 Jan 2014 16:52:12 +0400
Igor lanthrus...@gmail.com wrote:

 You're living right not in competition.If you're on an island
 you compete with animals for food and water. If you're in a condo -
 hell, you know how many on this planet WISH to live in your house
 right now and what stops them from doing that?
 
 And you belive that you're outside competition. It looks unreal.
 Gentoo is in competition with other distros - it's real and happens
 right now.

That's the marketing view on it; but now take a look from the customer
view, why am I and you on Gentoo or one of its derivatives and not
on some other distribution out there. Exactly, Gentoo provides some
things that are hard to find in other distributions; patching the
source, having more choice, remove features you don't need, etc...

Customers are looking for that; my thought exactly when I was looking
for Gentoo was I want to be able to easily manipulate what I use,
Gentoo's ability to just patch the source code is great for that.

I'd be scared of going to a binary distro, the distros where you are
source based are quite limited; if I'd quit Gentoo, I'm for sure I'll
either be on a Gentoo-derived distribution or build something similar.

The former makes me still be on Gentoo, or at least its idea; the
latter might be quite an effort that'll take quite some time too get
going, but I'll know for sure if that ever jumped my mind that I would
miss the Portage tree and so on.

So, other non-derived distros don't really look like competitors to me;
they might satisfy a set of our customers, but then you can just as
well realize that those customers have no real need for Gentoo and were
bound to leave sooner or later anyway.

As for derived distros; forking is great, right?

We are no longer using the old solid wheels that break or the old cars
that fail to continue to drive after a bit of usage; no, we are using
well designed, well implemented, well tested wheels and cars that
continue to drive for months to years.

And as an example, we also have ideas like those small cars which only
fit one person; who knows, that idea never catches on in public. But at
least we've satisfied the needs of a few people out there; not everyone
wants to have such a car, just a few persons that are in need for it.

 Are you absolutely sure that in the condition when nobody knows how
 Portage works we may go that far as saying we have a healthy Penguin?

Reverse engineering a car will not say anything about its health;
fixing its bugs, testing it and supporting it however will.

Otherwise we could claim solid wheels and old cars to still be healthy.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : tom...@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D


signature.asc
Description: PGP signature

[gentoo-dev] Re: [PATCH] To enable ssp default in Gcc the toolchain.eclass need some changes.

2014-01-10 Thread Ryan Hill

On Fri, 10 Jan 2014 01:35:09 -0500
Rick \Zero_Chaos\ Farina zeroch...@gentoo.org wrote:

 More to the point, this specific use flag appears to have no purpose
 what-so-ever.  If a user can do exactly the same with
 CFLAGS=-fno-stack-protector in make.conf, and it would be INSANE for a
 package to dep on gcc[nossp] then this is has got to be one of the most
 useless use flags in gentoo.

Having slept on it I'm starting to agree.  My first argument was that on
hardened ssp is -fstack-protector-all, which is much more expensive, and it
adds -fstack-check and -z,now to the linker by default as well.  The pie half
adds -fPIE but also a crtbeginP section for linking static libs with -pie.  So
there are situations where you want to disable one or both, if only for
testing.  But what I forgot is that hardened installs multiple gcc-config
profiles to switch these out on the fly.  So there goes that idea.

It might be useful to have these flags so we can mask them on archs that don't
support ssp/pie.  But that's always been true and it looks like sh is the only
place we've bothered for some reason.

 Not saying I would block this patch, not saying it has to be this
 second, but I see this use flag as a small example of things in
 toolchain which could probably be cleaned up if fresh eyes were to see
 things.

Yes, and believe it or not I appreciate the input.  I know I'm stubborn as hell
but eventually common sense gets through.


-- 
Ryan Hillpsn: dirtyepic_sk
   gcc-porting/toolchain/wxwidgets @ gentoo.org

47C3 6D62 4864 0E49 8E9E  7F92 ED38 BD49 957A 8463


signature.asc
Description: PGP signature

Re: [gentoo-dev] Re: [PATCH] To enable ssp default in Gcc the toolchain.eclass need some changes.

2014-01-10 Thread Magnus Granberg

torsdag 09 januari 2014 17.56.56 skrev  Ryan Hill:
 On Thu, 09 Jan 2014 21:58:46 +0100
 
 Magnus Granberg zo...@gentoo.org wrote:
  -   use hardened  make_gcc_hard
  +   if ( tc_version_is_at_least 4.8 || use hardened )  ! use vanilla ;
  then
 
 s/4.8/4.8.2
 
 Or should we wait until the next release (4.8.3 or 4.9.0)?  I think I'd
 prefer it but I don't have a good reason.
 
 What gcc-config profiles get installed after this patch?
We have only one now. But we can add a nossp but
i would only use it for debuging and it don't mix well with distcc.
The GCC_SPECS is not trasfered betvine the host and guest.

/Magnus



signature.asc
Description: This is a digitally signed message part.

[gentoo-dev] Re: [PATCH] To enable ssp default in Gcc the toolchain.eclass need some changes.

2014-01-10 Thread Ryan Hill

On Fri, 10 Jan 2014 16:24:38 +0100
Magnus Granberg zo...@gentoo.org wrote:

 Hi
 Have patched toolchain.eclass with the patch and with your change.
 Updated 4.8.2 updated with the needed changes and commit it.
 The use hardened  gcc-specs-ssp  append-cflags $(test-flags-CC -fno-stack-
 protector) in glibc's common.eblit is fixed to.

Cool, I forgot about that. ;)

 So default ssp is out in the tree :)

FYI it's masked for testing for now.  I will send out a news item
soon.


-- 
Ryan Hillpsn: dirtyepic_sk
   gcc-porting/toolchain/wxwidgets @ gentoo.org

47C3 6D62 4864 0E49 8E9E  7F92 ED38 BD49 957A 8463


signature.asc
Description: PGP signature

Re: [gentoo-dev] Re: Portage QOS

2014-01-10 Thread Mike Frysinger

please do not use html on the public mailing lists
-mike


signature.asc
Description: This is a digitally signed message part.

[gentoo-dev] Question, Portage QOS

Hello All,

Thank you for all our feedback!

It's very good that we have all many different views on the same
subject. The nature designed us in a way that some part of us is
to survive in almost any situation. If everyone thought the same
they would make the same decisions and the probability of survival
would decrease. So it's all very natural and I didn't expect it
going easy.

In project like that I can't rush to programming it without
everyone's approval. This part of the project should have been
implemented with the first portage version by it's creator. But as
I'm not this person I'll need the expertise of the whole community.


Let's agree on following - I'll design the system in details on paper.
When it's ready (~ 1.5 months) I'll get back here and share the details.

Then we all review it again everyone could contribute it's own view
and part and help to avoid some design problems if there are.

And then when the final version is ready and there is support and
understanding of everyone and everyone says YES and sees that system
could be helpful - I'll get in running in ~ 1.5 years alone or if
I find some help - faster. I would anyway need this design to
effectively program the soft. It's the first step, no matter if
there is the second.

Do we have an agreement on this one from everyone of the list?

Please vote.

-- 
Best regards,
 Igor  mailto:lanthrus...@gmail.com

Re: [gentoo-dev] Question, Portage QOS

2014-01-10 Thread Jon Portnoy

On Fri, Jan 10, 2014 at 08:48:30PM +0400, Igor wrote:
 Do we have an agreement on this one from everyone of the list?
 

Agreement on what, precisely...?

In open source, better implementations usually gain more mindshare.

If you think you can write one (and the project is interesting to you)
go forth and produce code! ;-)

Re: [gentoo-dev] Question, Portage QOS

2014-01-10 Thread Peter Stuge

Igor wrote:
 Let's agree on following - I'll design the system in details on paper.
 When it's ready (~ 1.5 months) I'll get back here and share the details.

You might be surprised how little people care about good design.

They choose kindof-working implementation every time.


//Peter

Re: [gentoo-dev] Question, Portage QOS

2014-01-10 Thread Ian Stakenvicius

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 10/01/14 11:48 AM, Igor wrote:
 Hello All,
 
 Thank you for all our feedback!
 
 It's very good that we have all many different views on the same 
 subject. The nature designed us in a way that some part of us is to
 survive in almost any situation. If everyone thought the same they
 would make the same decisions and the probability of survival would
 decrease. So it's all very natural and I didn't expect it going
 easy.
 
 In project like that I can't rush to programming it without 
 everyone's approval. This part of the project should have been 
 implemented with the first portage version by it's creator. But as 
 I'm not this person I'll need the expertise of the whole
 community.
 
 
 Let's agree on following - I'll design the system in details on
 paper. When it's ready (~ 1.5 months) I'll get back here and share
 the details.
 
 Then we all review it again everyone could contribute it's own
 view and part and help to avoid some design problems if there are.
 
 And then when the final version is ready and there is support and 
 understanding of everyone and everyone says YES and sees that
 system could be helpful - I'll get in running in ~ 1.5 years alone
 or if I find some help - faster. I would anyway need this design
 to effectively program the soft. It's the first step, no matter if 
 there is the second.
 
 Do we have an agreement on this one from everyone of the list?
 
 Please vote.
 


I think it's great you are looking for (developer) community feedback,
but it probably should be made clear that unless this project is going
to go through official channels (ie, GLEP), it will be an independent
project.  Not that there's anything wrong with this, but it sounds
like there are some assumptions that the design or implementation will
just automatically be integrated.

At this point, it doesn't sound like this project would be anywhere
near ready to go through official channels, so your best bet would
probably be to continue working on it as an independent project.  And
as such, agreement from everyone really has no meaning or value in
this context.

Good luck!
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iF4EAREIAAYFAlLQKtIACgkQ2ugaI38ACPCREgD+PUTaIF56RdLjFt64Xx8HraZJ
qxHdYKfhY4eGlrVcYssA/jsbCruhMgwvMdoJVqKKWuTlzpkVUCjodYtWU0RH/mxw
=gY62
-END PGP SIGNATURE-

[gentoo-dev] Question, Portage QOS v2

Hello All,

As there are questions at to what we vote.

--

Thank you for all our feedback!

In project like that I can't rush to programming it without
everyone's approval. This part of the project should have been
implemented with the first portage version by it's creator. But as
I'm not this person I'll need the expertise of the whole community.

Let's agree on following - I'll design the system in details on paper
but no code will be produced at this stage.

When it's ready (~ 1.5 months) I'll get back here and share the design
sketches with you.

Then we all review it again everyone could contribute it's own view
and part and help to avoid some design problems if there are.

I need an agreement on this stage from the list.

If you consider PortageQOS is not necessary please vote NO.
If you consider PortageQOS might have a chance and it depends on
implementation say YES.


Please vote.


If NO there is no need to spend time even on sketches.
If YES - there will be a system design ready and we could at least
imagine how it might work as a whole and benefits it might bring.



PS
No way PortageQOS will work without uniform agreement. That thing
was missing from portage design from the start and now with the legacy
it's either everyone is willing to give it a try or none. I don't want
to push somebody to something he doesn't see purpose for. There are
people here who spent lots of time on the project and it might be left
as is if they don't want any change.

-- 
Best regards,
 Igor  mailto:lanthrus...@gmail.com

Re: [gentoo-dev] Question, Portage QOS v2

2014-01-10 Thread Andreas K. Huettel

Am Freitag 10 Januar 2014, 21:18:58 schrieb Igor:
 Hello All,
 
 As there are questions at to what we vote.
 
 --

Realistically most people haven't even read your mails (too much bla).

-- 
Andreas K. Huettel
Gentoo Linux developer
kde, council

[gentoo-dev] Question, Portage QOS v3

Hello All,

As there are more questions rose.  See you can't just think of everything, 
what you need is an ability to improve fast :-)

--

Thank you for all our feedback!

In project like that I can't rush to programming it without
everyone's approval. This part of the project should have been
implemented with the first portage version by it's creator. But as
I'm not this person I'll need the expertise of the whole community.

Let's agree on following - I'll design the system in details on paper
but no code will be produced at this stage.

When it's ready (~ 1.5 months) I'll get back here and share the design
sketches with you.

Then we all review it again everyone could contribute it's own view
and part and help to avoid some design problems if there are.

I need an agreement on this stage from the list.

If you consider PortageQOS is not necessary please vote NO.
If you consider PortageQOS might have a chance and it depends on
implementation say YES.


Please vote.


If NO there is no need to spend time even on sketches.
If YES - there will be a system design ready and we could at least
imagine how it might work as a whole and benefits it might bring.


--

BY VOTING WE MAKE NO ASSUMPTION that the PROJECT is going to be INTEGRATED 
in GENTOO without further approval. 

At this stage the design will serve only as a demonstration that such 
system could actually be implemented and used for benefits of GENTOO 
project. 

If community finds the design worth trying we'll push it for approval 
and then it will be implemented.

--


PS
No way PortageQOS will work without uniform agreement. That thing
was missing from portage design from the start and now with the legacy
it's either everyone is willing to give it a try or none. I don't want
to push somebody to something he doesn't see purpose for. There are
people here who spent lots of time on the project and it might be left
as is if they don't want any change.

-- 
Best regards,
 Igor  mailto:lanthrus...@gmail.com

Re: [gentoo-dev] Question, Portage QOS v2

Hello Andreas,

Friday, January 10, 2014, 9:20:17 PM, you wrote:

 As there are questions at to what we vote.

 --

 Realistically most people haven't even read your mails (too much bla).

Please read the following and vote.

What PortageQOS will be able to accumulate: 

* Knowledge of the number of Gentoo distros installed world wide - knowing the 
trend how many users choose 
Gentoo and where Gentoo is really going down|up|stands still. 

You can then try different features and see how a feature is met - if the 
number of systems increase 
then this feature is probably useful. It's a strategical job, somebody at the 
very top of the project should 
analyze databases and make conclusions. 

* Knowledge of the ebuild popularity - what ebuilds are popular and what are 
not - what ebuild to give an extra focus 
and what ebuild could wait

* Knowledge of ebuild quality. If some ebuilds fail on many systems - something 
is wrong and ebuild and may be portage 
need fixing. It's especially useful to make sure that all ebuilds have correct 
dependencies, missing dependencies, etc.

* A formal esteem of portage quality 
PortageQ = (the number of successful ebuilds/the number of all ebuild attempts)

Portage speed efficiency: 
Average time before build starts (or download starts)

How many times portage fails itself. 

* Immediate problem detection. If the number of PortageQ went down last day - 
there is some problem. 
(then you go to ebuild stats and see what is failing)

* Reducing load on bugtracker folks - the build problems will be detected 
automatically and solved according 
to their importance. There will be no need to supply bug tracker with ebuild 
logs and emerge --info if 
somebody wants to report a problem. 

* Team efficiency esteem. The stats will tell what ebuilds are failing most 
often. 

* Team automated info. When failure rate of a certain ebuild increase the 
maintainer is automatically 
informed and he can login in web-interface and see details how exactly ebuild 
failed. 
The same for the portage itself. Next day a maintainer could push a new ebuild 
in the portage and the 
problem might be solved.

It's not possible not to make mistakes. But it's possible to react on their 
consequences fast. 

* Knowledge what kernels are used by Gentoo users, how often they update their 
systems, what flags 
are used 

2nd turn goals: 

* to integrate forums.gentoo.org and bug tracker. People are offering great 
workarounds and solutions. But 
they're not known to the majority of Gentoo users. 

If a e-build fails - may be there is already a solution - and we can offer the 
solutions automatically from 
portage. Like:

There might be some work-arounds on this problem: 
[Gentoo Forum - qt-core ebuild fails - SOLVED] 
htpp://forums.gentoo.org/. 

There is a known bug on this ebuild: 
[Gentoo Bug - qt-core ebuild fails] 
htpp://forums.gentoo.org/. 

* to make Bug Tracker almost unmanned. We can use gathered infromation on 
failed e-builds to 
create bugs in Bug Tracker automatically and automatically set priorities 
according to the 
severity. 

The severity could be assigned automatically from package popularity and 
failure rate stats.

These are the bricks that will be added in the initial design.

-- 
Best regards,
 Igormailto:lanthrus...@gmail.com

Re: [gentoo-dev] Question, Portage QOS v3

2014-01-10 Thread Jeroen Roovers

On Fri, 10 Jan 2014 21:26:47 +0400
Igor lanthrus...@gmail.com wrote:

 In project like that I can't rush to programming it without
 everyone's approval.

You don't need anyone's approval to do anything. Just go for it.


 jer

Re: [gentoo-dev] Question, Portage QOS v2

Hello Andreas,

Friday, January 10, 2014, 9:20:17 PM, you wrote:


 Realistically most people haven't even read your mails (too much bla).

And one more goal - without PortageQOS you're forever stuck with
the legacy portage design.

If the team ever decides to change Portage you'll need feedback
on how the new portage works to patch it quickly in case there are
troubles. It's too risky to touch portage right now. Everyone
understands that this is a kamikaze job. 

-- 
Best regards,
 Igormailto:lanthrus...@gmail.com

Re: [gentoo-dev] Re: Portage QOS

2014-01-10 Thread Greg KH

On Fri, Jan 10, 2014 at 04:10:18PM +0400, Igor wrote:
 Hello Chris,
 
 Friday, January 10, 2014, 1:08:39 AM, you wrote:
 
  Right here is the big problem: you're not looking at this from the
  perspective of the average Gentoo developer. We don't care about market
  share. We don't care whether we're on top for another few years. There
  are several forks of Gentoo. I doubt most devs care about them. I
  personally know that we're not going to compete with Debian, which has a
  huge contributor, or Ubuntu or Red Hat, which have whole companies
  behind them. You're selling this as if you're selling to a company which
  wants to be on the top of the market and beating out competitors, and
  that's not what we are. We are a source-based distro that requires some
  effort from users, and people want that or they don't want it.
  What we need is a vote YES or NO. If you against it - vote NO. It's
  perfectly normal, if there would be no NO there would be no need voting.
 
 Thank you for you opinion. 
 
 The competition in open source world is much harder than with
 commercial software. 3 commercial systems share 96% of the users.

Really?  What market?  Last I looked, more Linux systems were being run
on processors than any other single kernel.

Don't confuse desktops for all of computing.

 1,6% of the users are shared by 296 Linux distros

Really?  And what is the number of total users you are talking about
here?

 You may think that you're outside this rules but the competition is natural 
 on the planet and Gentoo is certainly competing weather you want it or not.

No, we aren't competing with anyone, please realize that this is not how
Linux distros and the ecosystem works at all.

Remember, Red Hat is Gentoo's engineering team :)

good luck,

greg k-h

Re: [gentoo-dev] Portage QOS

On Fri, 10 Jan 2014 08:31:21 +0800
Patrick Lauer patr...@gentoo.org wrote:
 On 01/10/2014 08:16 AM, hero...@gentoo.org wrote:
  Igor lanthrus...@gmail.com writes:
  
  The ebuilds have approximately the same time to install, the
  failure rate is about the same, emerge is getting slower.
  
  I am curious about the slowness of emerge.
  
  How about profile the portage and rewrite the time-crucial part in
  C/C++, or ideally, borrowing the counterpart from paludis? How
  feasible is that?
 
 Last I checked paludis wasn't faster - on average portage was a few
 percents faster.

Your benchmark was comparing uncached behaviour, where bash is the slow
part and which users don't see. You were also not comparing like with
like -- any benchmarks of this nature should be taken with a heavy
pinch of salt, since Portage with everything turned on does less
validation that Paludis does with everything turned off...

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

Re: [gentoo-dev] Portage QOS

On Fri, 10 Jan 2014 09:16:47 +0900
hero...@gentoo.org wrote:
 or ideally, borrowing the counterpart from paludis? How feasible is
 that?

It's not.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

Re: [gentoo-dev] Portage QOS

On Thu, 9 Jan 2014 17:52:16 -0800
Patrick McLean chutz...@gentoo.org wrote:
 Why not just switch to using pkgcore as the default package manager.
 radhermit has been doing a lot of work lately getting EAPI 5 support
 added, and generally fixing bugs etc.

Pkgcore is dead (see: still no EAPI 5 support). If you're really
thinking about switching, the way to go is to write a client for
Paludis which mimics Portage's UI. But the politics make switching from
Portage to anything a lost cause.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

Re: [gentoo-dev] Portage QOS

On Fri, 10 Jan 2014 14:18:24 +0100
René Neumann li...@necoro.eu wrote:
 And again: What is needed is streamlining the algorithms (discussion
 on that already started as far as I could notice). An algorithm in
 O(n³) is always¹ worse than O(n). The constant factor added by the

Full dependency resolution is NP-hard... If you really wanted to
streamline the algorithms, you'd change the inputs slightly. Most of
the complexity of doing a decent job of dependency resolution comes from
dealing with crap input.

 ¹ For a large enough n.

...which could be larger than the number of atoms in the universe.
There are real world cases where an algorithm has an O(n^3) step that
takes a day, and a O(2^n) step that takes a second for most inputs. You
shouldn't be using O() to make performance comparisons.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

Re: [gentoo-dev] Question, Portage QOS v2

On Fri, 10 Jan 2014 21:46:18 +0400
Igor lanthrus...@gmail.com wrote:
 And one more goal - without PortageQOS you're forever stuck with
 the legacy portage design.
 
 If the team ever decides to change Portage you'll need feedback
 on how the new portage works to patch it quickly in case there are
 troubles. It's too risky to touch portage right now. Everyone
 understands that this is a kamikaze job. 

Uh, no. We already know lots of things that are wrong with the Portage
design. We also know how to fix those things. Neither of those is the
sticking point.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

Re: [gentoo-dev] Re: [PATCH] To enable ssp default in Gcc the toolchain.eclass need some changes.

2014-01-10 Thread Rick Zero_Chaos Farina

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/10/2014 10:50 AM, Ryan Hill wrote:
 On Fri, 10 Jan 2014 01:35:09 -0500
 Rick \Zero_Chaos\ Farina zeroch...@gentoo.org wrote:
 
 More to the point, this specific use flag appears to have no purpose
 what-so-ever.  If a user can do exactly the same with
 CFLAGS=-fno-stack-protector in make.conf, and it would be INSANE for a
 package to dep on gcc[nossp] then this is has got to be one of the most
 useless use flags in gentoo.
 
 Having slept on it I'm starting to agree.  My first argument was that on
 hardened ssp is -fstack-protector-all, which is much more expensive, and it
 adds -fstack-check and -z,now to the linker by default as well.  The pie half
 adds -fPIE but also a crtbeginP section for linking static libs with -pie.  So
 there are situations where you want to disable one or both, if only for
 testing.  But what I forgot is that hardened installs multiple gcc-config
 profiles to switch these out on the fly.  So there goes that idea.
 
 It might be useful to have these flags so we can mask them on archs that don't
 support ssp/pie.  But that's always been true and it looks like sh is the only
 place we've bothered for some reason.
 
 Not saying I would block this patch, not saying it has to be this
 second, but I see this use flag as a small example of things in
 toolchain which could probably be cleaned up if fresh eyes were to see
 things.
 
 Yes, and believe it or not I appreciate the input.  I know I'm stubborn as 
 hell
 but eventually common sense gets through.

Well, that's why I asked for your opinion ;-)  Now since I know you have
plenty to do I'll leave you with this though bouncing around in there.
When you are working on your updates, we would prefer that this nopie
and nossp flags to bye bye.  If you REALLY wanted a way to change the
gcc profile then do for the normal users what the hardened team does and
offer them multiple profiles.  Obviously we should involved docs team at
that point, but it makes much more sense to gcc-config 3 than rebuild
gcc with a different use flag.

Again, doesn't have to be this second, but I want it in your head since
I know you are working on this stuff right now.

Thanks!
Zero
 
 

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJS0D3YAAoJEKXdFCfdEflK1HEP/jdF9nwxpDde8j4PMypeZSm8
FKG0l3MmMr6+2joKkgZSLqVebiTcc8OtCgpk6UJJVEWSpNMWqrjqX5oTkIBAJisr
sGUVGJEAyDCCsNJwTtbW/sBKw5r5Xh1zLk92T55YhaWBMTJPc4UzSqhpr+TBZ8wJ
T77XOIPtxOdZYjubGqIm4lSWsgT/o0F0S6kge75iYm81omuBtZpAze6ePE2DteTj
IinauiMUhqkTYXv6AXdBNv4dDLiInyDrdlUIFbWlawxsx64Wpt77j3jA2fHrRmEf
8MPvoRzLpX/7DPMDaS3WyGBVpM8CPNTaxQiXjC+giXNj4jkJyop/m6Q4a00wYvQg
C+1o6JMEsYNlrIuSooInFxQ5OqARzna4lFc7Jp6+eMaBE4NhYkPkxJ7KOerD3IvI
yW1lSN5gte/zxgm3Ny/96Zw/6+Jx5ffQNc8bCgE2+TxDG0wwB5qZGn/w6dl6gFYX
jXD5dFmw3C5T2HhTIZ6j9n8b0MNkT71CzFA2O4EzEyPrI3b8KTmU6PkppT/Vwlo4
EHc/EUWdjSCPH/FzzJdcNbFUdvLCigZQqvaggN3Qjh/YyJRECXz6Hy2M8VTOg18a
XVE36Z5/DNeobeBQ5XaKLcb5po22wJueJzKFdEK+GaSewzn+FXsNCquVZV9Y3lZC
epKNxmbxtX/Uqx8q9+74
=++P6
-END PGP SIGNATURE-

Re: [gentoo-dev] Portage QOS