On 2016-04-18 8:17 PM, Alfred Perlstein wrote:
Can someone on the "too many packages" campaign here explain to me how
having too fine a granularity stops you from making macro packages
containing packages?
Because honestly I can't see how having granularity hurts at all when if
someone wanted to
Maybe what the "too many packages" folks need to do is write some code
to hide that it's so many packages.
:)
I think the rule of two feet should be applied here.
What we have is people that have worked quite hard to bring us something
that we can easily work with, and on the other hand some
On 2016-04-18 7:01 PM, Roger Marquis wrote:
Can you explain what would be accomplished by testing all or even a
fraction of the possible permutations of base package combinations? We
don't do that for ports.
The ports tree isn't a mandatory part of the system. And by definition
it could not b
Lyndon Nerenberg wrote:
There aren't enough seconds in the universe to test all the viable
combinations for one single release.
Can you explain what would be accomplished by testing all or even a
fraction of the possible permutations of base package combinations? We
don't do that for ports. O
On 2016-04-18 5:09 PM, Nathan Whitehorn wrote:
I'm not so sure about these statements. Maintaining groups of packages
can be easier, but it can be also be harder. The goal is to find the
right level. And I haven't seen a case where an 800-packages level of
granularity is helpful.
Not to mention
On 04/18/16 14:29, Alfred Perlstein wrote:
Guys please stop arguing about the number of packages. The high
granularity is VERY useful!
Managing large groups of small packages is much easier than just
having large packages.
I'm not so sure about these statements. Maintaining groups of packag
On Tue, Apr 19, 2016 at 12:43:08AM +0300, Slawa Olhovchenkov wrote:
> On Mon, Apr 18, 2016 at 12:01:46PM -0700, Sean Fagan wrote:
>
> > On Apr 18, 2016, at 11:52 AM, Lev Serebryakov wrote:
> > >
> > > I understand, that maybe it is too late, but ARE YOU KIDDING?! 755
> > > packages?! WHY?! What
On Mon, Apr 18, 2016 at 10:30:48PM +0200, Rainer Duffner wrote:
>
> > Am 18.04.2016 um 22:07 schrieb Lev Serebryakov :
> >
> > On 18.04.2016 22:40, Glen Barber wrote:
> >
> >> This granularity allows easy removal of things that may not be wanted
> >> (such as *-debug*, *-profile*, etc.) on syst
On Mon, Apr 18, 2016 at 12:21:28PM -0700, Nathan Whitehorn wrote:
>
>
> On 04/18/16 12:14, Glen Barber wrote:
> > On Mon, Apr 18, 2016 at 12:01:46PM -0700, Sean Fagan wrote:
> >> On Apr 18, 2016, at 11:52 AM, Lev Serebryakov wrote:
> >>> I understand, that maybe it is too late, but ARE YOU KIDD
On Mon, Apr 18, 2016 at 12:01:46PM -0700, Sean Fagan wrote:
> On Apr 18, 2016, at 11:52 AM, Lev Serebryakov wrote:
> >
> > I understand, that maybe it is too late, but ARE YOU KIDDING?! 755
> > packages?! WHY?! What are reasons and goals to split base in such
> > enormous number of packages?
>
Guys please stop arguing about the number of packages. The high
granularity is VERY useful!
Managing large groups of small packages is much easier than just having
large packages.
All this can be done by meta-packages which depend on larger package groups.
Later pkg can be augmented to "rem
On 18.04.2016 23:30, Rainer Duffner wrote:
> From the discussion, I believe it’s primarily driven by the need/desire to
> have small packages to make updates easier on the mirror-servers.
It is bad driver. Mirror servers are hardware. And this enormous
number of packages cause problems for peop
> Am 18.04.2016 um 22:07 schrieb Lev Serebryakov :
>
> On 18.04.2016 22:40, Glen Barber wrote:
>
>> This granularity allows easy removal of things that may not be wanted
>> (such as *-debug*, *-profile*, etc.) on systems with little storage. On
>> one of my testing systems, I removed the tests
On 18.04.2016 22:40, Glen Barber wrote:
> This granularity allows easy removal of things that may not be wanted
> (such as *-debug*, *-profile*, etc.) on systems with little storage. On
> one of my testing systems, I removed the tests packages and all debug
> and profiling, and the number of base
On Mon, Apr 18, 2016 at 08:05:05PM +, Glen Barber wrote:
> On Mon, Apr 18, 2016 at 11:02:12PM +0300, Slawa Olhovchenkov wrote:
> > > This granularity allows easy removal of things that may not be wanted
> > > (such as *-debug*, *-profile*, etc.) on systems with little storage. On
> > > one of
On Mon, Apr 18, 2016 at 03:42:20PM -0400, Ernie Luzar wrote:
> Slawa Olhovchenkov wrote:
> > On Mon, Apr 18, 2016 at 05:27:09PM +0300, Slawa Olhovchenkov wrote:
> >
> >> On Mon, Apr 18, 2016 at 04:16:01PM +0200, Baptiste Daroussin wrote:
> >>
> >>> On Mon, Apr 18, 2016 at 05:14:54PM +0300, Slawa
On Mon, Apr 18, 2016 at 07:40:10PM +, Glen Barber wrote:
> On Mon, Apr 18, 2016 at 12:21:28PM -0700, Nathan Whitehorn wrote:
> >
> >
> > On 04/18/16 12:14, Glen Barber wrote:
> > >On Mon, Apr 18, 2016 at 12:01:46PM -0700, Sean Fagan wrote:
> > >>On Apr 18, 2016, at 11:52 AM, Lev Serebryakov
On Mon, Apr 18, 2016 at 11:02:12PM +0300, Slawa Olhovchenkov wrote:
> > This granularity allows easy removal of things that may not be wanted
> > (such as *-debug*, *-profile*, etc.) on systems with little storage. On
> > one of my testing systems, I removed the tests packages and all debug
> > an
Slawa Olhovchenkov wrote:
On Mon, Apr 18, 2016 at 05:27:09PM +0300, Slawa Olhovchenkov wrote:
On Mon, Apr 18, 2016 at 04:16:01PM +0200, Baptiste Daroussin wrote:
On Mon, Apr 18, 2016 at 05:14:54PM +0300, Slawa Olhovchenkov wrote:
On Mon, Apr 18, 2016 at 10:05:12AM -0400, Nikolai Lifanov wrot
On Mon, Apr 18, 2016 at 12:21:28PM -0700, Nathan Whitehorn wrote:
>
>
> On 04/18/16 12:14, Glen Barber wrote:
> >On Mon, Apr 18, 2016 at 12:01:46PM -0700, Sean Fagan wrote:
> >>On Apr 18, 2016, at 11:52 AM, Lev Serebryakov wrote:
> >>>I understand, that maybe it is too late, but ARE YOU KIDDING?
On 04/18/16 12:14, Glen Barber wrote:
On Mon, Apr 18, 2016 at 12:01:46PM -0700, Sean Fagan wrote:
On Apr 18, 2016, at 11:52 AM, Lev Serebryakov wrote:
I understand, that maybe it is too late, but ARE YOU KIDDING?! 755
packages?! WHY?! What are reasons and goals to split base in such
enormous
On Apr 18, 2016, at 11:52 AM, Lev Serebryakov wrote:
>
> I understand, that maybe it is too late, but ARE YOU KIDDING?! 755
> packages?! WHY?! What are reasons and goals to split base in such
> enormous number of packages?
Just a guess, having done the same thing myself: it means that updates c
On Mon, Apr 18, 2016 at 12:01:46PM -0700, Sean Fagan wrote:
> On Apr 18, 2016, at 11:52 AM, Lev Serebryakov wrote:
> >
> > I understand, that maybe it is too late, but ARE YOU KIDDING?! 755
> > packages?! WHY?! What are reasons and goals to split base in such
> > enormous number of packages?
>
>
On 18.04.2016 21:52, Lev Serebryakov wrote:
> kerberos
Ok, kerberos could not be packetized at all, as it is compilation
option for many other programs in tree. But 755 packets doesn't solve
this problem too.
--
// Lev Serebryakov
signature.asc
Description: OpenPGP digital signature
On Mon, 18 Apr 2016, Hans Petter Selasky wrote:
Hi,
Are there any objections adding the following as part of documenting our
kernel's qsort function?
Index: sys/libkern/qsort.c
===
--- sys/libkern/qsort.c (revision 298202)
+++ s
On Monday, April 18, 2016 11:10:12 PM Howard Su wrote:
> I noticed several places there are code like this, especially in some arm
> low level drivers.
> EARLY_DRIVER_MODULE(aw_ccu, simplebus, aw_ccu_driver, aw_ccu_devclass,
> 0, 0, BUS_PASS_BUS + BUS_PASS_ORDER_MIDDLE);
>
> I feel the usage
On Saturday, April 16, 2016 01:25:09 PM Pedro Giffuni wrote:
> Hello;
>
> Using coccinelle, and some hand re-formatting, I generated a patch to
> make use of the nitems() macro in sys, which is too big for
> phabricator [1].
>
> I was careful to exclude anything from the contrib directory or
> an
On 03.03.2016 02:54, Glen Barber wrote:
> At present, the base system consists of 755 packages with the default
> build (empty src.conf(5) and make.conf(5)) for amd64. The number of
> packages depends on several factors, but for most cases a runtime binary
> is split into several components. In
On 04/18/16 01:56, Hans Petter Selasky wrote:
On 04/16/16 20:25, Pedro Giffuni wrote:
M sys/dev/usb/input/ukbd.c
M sys/dev/usb/serial/u3g.c
M sys/dev/usb/serial/uchcom.c
M sys/dev/usb/serial/umcs.c
M sys/dev/usb/serial/uplcom.c
Approved. Maybe you can remove the
On Mon, Apr 18, 2016 at 12:13 PM, Hans Petter Selasky
wrote:
> Did anyone try to generate such a fiendish set of data, and see how
> quadratic the FreeBSD's qsort() becomes?
>
Not me, but it has been done:
http://calmerthanyouare.org/2014/06/11/algorithmic-complexity-attacks-and-libc-qsort.html
On 04/18/16 16:49, Ed Schouten wrote:
2016-04-18 15:09 GMT+02:00 Hans Petter Selasky :
On 04/18/16 14:16, Aleksander Alekseev wrote:
I suggest also add a short description of how it was achieved
(randomization?).
I think the algorithm is switching to mergesort. I'll look up the paper and
add
I noticed several places there are code like this, especially in some arm
low level drivers.
EARLY_DRIVER_MODULE(aw_ccu, simplebus, aw_ccu_driver, aw_ccu_devclass,
0, 0, BUS_PASS_BUS + BUS_PASS_ORDER_MIDDLE);
I feel the usage of BUS_PASS_ORDER_MIDDLE is misused. There are another
macro EARLY_
> On Apr 18, 2016, at 10:59, Renato Botelho do Couto wrote:
>
> I’m trying to upgrade a -CURRENT amd64 installation from r297492 to r298203
> and got:
>
> c++ -O2 -pipe
> -I/usr/src/usr.bin/clang/llvm-tblgen/../../../contrib/llvm/include
> -I/usr/src/usr.bin/clang/llvm-tblgen/../../../contrib
On Mon, Apr 18, 2016 at 05:27:09PM +0300, Slawa Olhovchenkov wrote:
> On Mon, Apr 18, 2016 at 04:16:01PM +0200, Baptiste Daroussin wrote:
>
> > On Mon, Apr 18, 2016 at 05:14:54PM +0300, Slawa Olhovchenkov wrote:
> > > On Mon, Apr 18, 2016 at 10:05:12AM -0400, Nikolai Lifanov wrote:
> > >
> > > >
2016-04-18 15:09 GMT+02:00 Hans Petter Selasky :
> On 04/18/16 14:16, Aleksander Alekseev wrote:
>> I suggest also add a short description of how it was achieved
>> (randomization?).
>
> I think the algorithm is switching to mergesort. I'll look up the paper and
> add that correctly before commit.
I’m trying to upgrade a -CURRENT amd64 installation from r297492 to r298203 and
got:
c++ -O2 -pipe
-I/usr/src/usr.bin/clang/llvm-tblgen/../../../contrib/llvm/include
-I/usr/src/usr.bin/clang/llvm-tblgen/../../../contrib/llvm/tools/clang/include
-I/usr/src/usr.bin/clang/llvm-tblgen/../../../con
On Mon, Apr 18, 2016 at 04:16:01PM +0200, Baptiste Daroussin wrote:
> On Mon, Apr 18, 2016 at 05:14:54PM +0300, Slawa Olhovchenkov wrote:
> > On Mon, Apr 18, 2016 at 10:05:12AM -0400, Nikolai Lifanov wrote:
> >
> > > On 04/18/16 10:00, Ernie Luzar wrote:
> > > > 11.0 will have pkg base, thats ok,
On Mon, Apr 18, 2016 at 05:14:54PM +0300, Slawa Olhovchenkov wrote:
> On Mon, Apr 18, 2016 at 10:05:12AM -0400, Nikolai Lifanov wrote:
>
> > On 04/18/16 10:00, Ernie Luzar wrote:
> > > 11.0 will have pkg base, thats ok, but what does than mean for the
> > > base.txz file?
> > >
> > > It it going
On Mon, Apr 18, 2016 at 10:05:12AM -0400, Nikolai Lifanov wrote:
> On 04/18/16 10:00, Ernie Luzar wrote:
> > 11.0 will have pkg base, thats ok, but what does than mean for the
> > base.txz file?
> >
> > It it going to stay as part of FBSD install?
> >
> > I have many scripts for creating jails w
On 04/18/16 10:00, Ernie Luzar wrote:
> 11.0 will have pkg base, thats ok, but what does than mean for the
> base.txz file?
>
> It it going to stay as part of FBSD install?
>
> I have many scripts for creating jails which depend on the base.txz file.
It's even easier now:
# mkdir -p /usr/jails/
11.0 will have pkg base, thats ok, but what does than mean for the
base.txz file?
It it going to stay as part of FBSD install?
I have many scripts for creating jails which depend on the base.txz file.
___
freebsd-current@freebsd.org mailing list
https
On Mon, Apr 18, 2016 at 9:09 AM, Hans Petter Selasky wrote
> I think the algorithm is switching to mergesort. I'll look up the paper
> and add that correctly before commit.
>
No, it switches to insertion sort, assuming that it's acting on an already
sorted array. If that assumption is wrong you
On 04/18/16 14:16, Aleksander Alekseev wrote:
I suggest also add a short description of how it was achieved
(randomization?).
I think the algorithm is switching to mergesort. I'll look up the paper
and add that correctly before commit.
--HPS
___
fr
Hello.
I suggest also add a short description of how it was achieved
(randomization?).
On Mon, 18 Apr 2016 13:43:38 +0200
Hans Petter Selasky wrote:
> Hi,
>
> Are there any objections adding the following as part of documenting
> our kernel's qsort function?
>
> Index: sys/libkern/qsort.c
> =
Hi,
Are there any objections adding the following as part of documenting our
kernel's qsort function?
Index: sys/libkern/qsort.c
===
--- sys/libkern/qsort.c (revision 298202)
+++ sys/libkern/qsort.c (working copy)
@@ -45,6 +45,10
45 matches
Mail list logo
