Re: [DNG] Memory management strategies.

[Didier Kryn]

Le 01/02/2016 17:52, Rainer Weikusat a écrit :

there's a known upper bound for the maximum number of objects which will
be needed
Some applications need to asynchronously create and destroy large 
numbers of objects while the total number of objects at any given time 
remains bounded. Creating them in one function or in one thread while 
deleting them in another can be a sensible way to organize the program 
if allocation/deallocation is efficient.


Didier

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] systemd is haunting me

[Didier Kryn]

Le 31/01/2016 23:59, Go Linux a écrit :

  I must check
for default-jre and gimp because both are pretty usefull.
Yep, default-jre, default-jre-headless and gimp are installed. If I 
try to remove libsystemd0, it only requires to remove also gvfs, 
gvfs-daemons and gvfs-fuse, but, as explained before, xfce4 needs them. 
The funny thing is that now it doesn't ask me to remove policykit I 
probably made an error in my first trial.


If you do a lot of sound manipulation, this is an area in which I 
can't help. Linux sound is a nightmare to me and I never found a 
sensible description of it all, so using pulseaudio by default because 
it mostly works out of the box. But there was a thread about it one or 
two weeks ago...


Didier

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Never say that again: was Debian is endorsed by Microsoft

[John Morris]

On Sat, 2016-01-30 at 17:03 +, Nuno Magalhães wrote:

> +1
> seems like kindergarten in here

Think this is the best response yet in this overlong thread.  Somebody
said something kinda childish and offtopic and a polite corrective
nudge to be a bit more adult was called for and should have ended the
affair.  But instead we got a full SJW meltdown and a Holiness Spiral
started cranking up as too many people started reaching for their
smelling salts and retiring to their feinting couches.


signature.asc
Description: This is a digitally signed message part
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Never say that again: was Debian is endorsed by Microsoft

[Rainer Weikusat]

John Morris  writes:
> On Sat, 2016-01-30 at 17:03 +, Nuno Magalhães wrote:
>
>> +1
>> seems like kindergarten in here
>
> Think this is the best response yet in this overlong thread.  Somebody
> said something kinda childish and offtopic and a polite corrective
> nudge to be a bit more adult was called for and should have ended the
> affair. But instead ...

... there comes the next guy who considers grossly impolite boilerplate
statements about other people terribly notewhorthy ...

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Memory management strategies.

[Rainer Weikusat]

Didier Kryn  writes:
> Le 01/02/2016 17:52, Rainer Weikusat a écrit :
>> there's a known upper bound for the maximum number of objects which will
>> be needed
>
> Some applications need to asynchronously create and destroy large
> numbers of objects while the total number of objects at any given time
> remains bounded. Creating them in one function or in one thread while
> deleting them in another can be a sensible way to organize the program
> if allocation/deallocation is efficient.

Aha ... and what is this now supposed to communicate? It looks like a
couple of unrelated statements to me which also don't seem to have any
relation to the idea to use an array as 'backing store' for memory
allocation, as opposed to, say, something which allocates page (frames)
via OS calls, eg, mmap, and divides these as required or even just a
'large' memory block acquired via malloc.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] Systemd at work: rm -rf EFI

[Wim]

Hi all,

It seems you can delete EFI vars if you're not careful. Someone found that
executing "rm -rf --no-preserve-root /" also deleted EFI vars, turning his MSI
Notebook into a brick.

It also seems mounting these is hardcoded into systemd:

https://bbs.archlinux.org/viewtopic.php?id=207549

efibootmgr needs to write to EFI vars, it seems. Here's Poettering's answer:

https://github.com/systemd/systemd/issues/2402

Well, you've probably guessed the answer - Won't fix.


Cheers,


Wim
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Systemd at work: rm -rf EFI

[Clarke Sideroad]

On 02/01/2016 08:59 PM, Clarke Sideroad wrote:
> On 02/01/2016 06:12 PM, Wim wrote:
>> Hi all,
>>
>> It seems you can delete EFI vars if you're not careful. Someone found
>> that executing "rm -rf --no-preserve-root /" also deleted EFI vars,
>> turning his MSI Notebook into a brick. 
>>
>> It also seems mounting these is hardcoded into systemd:
>>
>> https://bbs.archlinux.org/viewtopic.php?id=207549
>>
>> efibootmgr needs to write to EFI vars, it seems. Here's Poettering's answer:
>>
>> https://github.com/systemd/systemd/issues/2402
>>
>> Well, you've probably guessed the answer - Won't fix.
>>
> 
> The guy is unbelievable, but as you point out predictable.
> There  is a big difference between hosing a operating system install and
> bricking a piece of hardware.
> 
> Lots of hardware has bugs that need a work around and stuff like ROMs
> that should only be RW if required. Ignoring it, not even stating a
> logical position and closing the topic just shows the quality of the man
> and his products.
> 
> Looking around he seems to have a lot of apologist on his side that
> really don't have a grasp of the situation.
> 
> One wonders if it is confined only to the one piece of hardware or if
> there are others that may share the code, looks like a potential exploit
> to me.
> 
> Some of you can just be glad that there is no room on most embedded
> systems for the systemd shenanigans. (-;
> 
>

I just received this link in an email:
http://blog.virustotal.com/2016/01/putting-spotlight-on-firmware-malware_27.html

As usual I may be over reacting, but it may add a bit of perspective to
the problem of leaving the backdoor open with read write permissions.

Clarke



___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Systemd at work: rm -rf EFI

[Clarke Sideroad]

On 02/01/2016 06:12 PM, Wim wrote:
> Hi all,
> 
> It seems you can delete EFI vars if you're not careful. Someone found
> that executing "rm -rf --no-preserve-root /" also deleted EFI vars,
> turning his MSI Notebook into a brick. 
> 
> It also seems mounting these is hardcoded into systemd:
> 
> https://bbs.archlinux.org/viewtopic.php?id=207549
> 
> efibootmgr needs to write to EFI vars, it seems. Here's Poettering's answer:
> 
> https://github.com/systemd/systemd/issues/2402
> 
> Well, you've probably guessed the answer - Won't fix.
> 

The guy is unbelievable, but as you point out predictable.
There  is a big difference between hosing a operating system install and
bricking a piece of hardware.

Lots of hardware has bugs that need a work around and stuff like ROMs
that should only be RW if required. Ignoring it, not even stating a
logical position and closing the topic just shows the quality of the man
and his products.

Looking around he seems to have a lot of apologist on his side that
really don't have a grasp of the situation.

One wonders if it is confined only to the one piece of hardware or if
there are others that may share the code, looks like a potential exploit
to me.

Some of you can just be glad that there is no room on most embedded
systems for the systemd shenanigans. (-;


Clarke

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] systemd is haunting me

[Florian Zieboll]

On Mon, 1 Feb 2016 12:47:51 +0100
Didier Kryn  wrote:

>  Apparently synaptic keeps its config in its own config file 
> /etc/apt/apt.conf.d/99synaptic. Do you mean synaptic reads all config 
> files in order, and since 99synaptic is the last, it can override all 
> previous settings? 

For the fun of it, I just ran an "apt-get install --install-recommends
--no-install-recommends" and it chose to not install the recommends.
The same with contradicting lines in apt.conf(.d/*):

  APT::Install-Recommends "0";
  APT::Install-Recommends "1";

This will install the recommends, the other way around it won't.
Apparently there's still some behavior left in modern Linux that is
coherent with an autistic mindset, hahaha.

> I must confess I don't understand how this set of 
> config files is processed; there are quite a lot of files in 
> etc/apt/apt.conf.d/. There's a man for apt.conf, which doesn't exist
> and no man for apt.conf.d, which exists!

As with any of these newish "*.d/" folders, you can just

  $ cat apt.conf.d/* > apt.conf && rm -r apt.conf.d/ 

without any consequences regarding the configuration. AFAIU this is all
about easier deployment (and automated removal) of configurations - like
hitting some button on a shady website to add distribution independent
repositories to the sources.list. 

Regards,

Florian

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] systemd is haunting me

[Simon Hobson]

Florian Zieboll  wrote:

> For the fun of it, I just ran an "apt-get install --install-recommends
> --no-install-recommends" and it chose to not install the recommends.
> The same with contradicting lines in apt.conf(.d/*):
> 
>  APT::Install-Recommends "0";
>  APT::Install-Recommends "1";
> 
> This will install the recommends, the other way around it won't.
> Apparently there's still some behavior left in modern Linux that is
> coherent with an autistic mindset, hahaha.

Makes sense to me too - first entry sets/resets option, next entry resets/sets 
the same option - the last one taking effect.

> As with any of these newish "*.d/" folders, you can just
> 
>  $ cat apt.conf.d/* > apt.conf && rm -r apt.conf.d/ 
> 
> without any consequences regarding the configuration. AFAIU this is all
> about easier deployment (and automated removal) of configurations - like
> hitting some button on a shady website to add distribution independent
> repositories to the sources.list. 

More to the point, it means (in the general case) a number of packages can 
add/remove their own configs during package install/upgrade/removal just by 
adding/updating/removing "it's" config file from the conf.d directory. For 
another example, when installing Xen, it adds a file to Grub's conf.d to add 
the Xen boot options. Same with various web packages that put a file in 
/etc/apache2/conf.d.

IMO it's far better than trying to come up with some mechanism to *SAFELY* edit 
a shared config file.

It also means the user/admin can add their own config file, and if they name it 
to sort last then they can override any other default settings - but without 
impacting on the ability of a package to update it's own file. Once you get 
into editing the package supplied config file then upgrading gets a bit less 
automatic.

So overall I think this is "a good thing" - even though it does have one or two 
downsides.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Semi OT: Mailman, Lurker and referencing messages

[hellekin]

On 02/01/2016 10:49 AM, Florian Zieboll wrote:
> 
> Can Mailman predict the URL under which Lurker will archive the message
> it is processing "on the fly", or is there even a variable available? 
> 
> Quoting and referencing "third party" messages would be so much easier,
> if mails contained their own Lurker URL in the signature!
> 

This is an excellent idea.  Mailman developers already thought about it:
http://wiki.list.org/DEV/Stable%20URLs

I guess we can investigate and find out how to generate these from
mailman, and then have a nice URL like:
https://lurker.devuan.org/ to redirect to the relevant lurker
message.  This would also make Devuan Editors' lives easier when working
on the newsletter.

==
hk


-- 
 _ _ We are free to share code and we code to share freedom
(_X_)yne Foundation, Free Culture Foundry * https://www.dyne.org/donate/
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] About Devuan News

[hellekin]

On 02/01/2016 09:24 AM, Noel Torres wrote:
> 
> For familiar reasons I'm not able to continue working in the beautiful
> Devuan News work I started, but I love to know that it continues alive.
> Reading it is my main point of connection with the Devuan community and
> as such I need it to continue.
> 
> Thanks, thanks, thanks
> 

Many thanks to you Noel for having started on AD nulla* :)

* Week Zero After Devuan

==
hk

-- 
 _ _ We are free to share code and we code to share freedom
(_X_)yne Foundation, Free Culture Foundry * https://www.dyne.org/donate/
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Wifi device names: was systemd is haunting me

[Rainer Weikusat]

Steve Litt  writes:
> On Sun, 31 Jan 2016 18:20:12 -0500
> Steve Litt  wrote:

[...]

> ===
> #!/bin/sh
> lineno=${1:-1}
>
> fn=`mktemp`
>
> ip -o link | \
>   cut -d ' ' -f2 | \
>   grep ^w | \
>   tr -d : > $fn
>
> maxdev=`wc -l $fn | cut -d ' ' -f 1`
> if test $maxdev -lt $lineno; then
>echo =max$maxdev
> else
>   head $fn -n $lineno | \
>   tail -n 1
> fi
> rm $fn
> ===

[...]

> There are probably better ways to write this script, but I think the
> way I have it here exhibits the behavior I'd like.

'Better' is often very much a matter of opinion but here's one which
doesn't need a temporary file:

-
#!/bin/sh
want=${1:-1}
got=0

for dev in `ip -o link | sed -n 's/[^:]*: *\(w[^:]*\).*/\1/p'`;
do
got=`expr $got + 1`

test $got -eq $want && {
echo $dev
exit 0
}
done

echo =max$got

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Memory management strategies.

[Rainer Weikusat]

Didier Kryn  writes:
> Le 01/02/2016 17:16, Rainer Weikusat a écrit :
>> Rainer Weikusat  writes:
>>
>> [...]
>>
>>> A more problematic (for some definition of problematic) situation is
>>> when there are many objects of different sizes and if objects whose
>>> size is identical have vastly differing lifetimes. This introduces
>>> so-called 'external fragmentation' into the malloc heap
>> Additional information: The usual 'household number' associated with
>> that would be that an allocator is considered memory efficient if not
>> more than 50% of the memory managed by it is effectively lost due to
>> external fragementation.
>
> Note that if you manage your memory pool as an array then
> allocation and deallocation are extremely fast and can be done without
> consuming a single byte for book-keeping.

That's not possible unless the allocation size is always the same and
there's a known upper bound for the maximum number of objects which will
be needed. And there's also the "write FORTRAN in any language" aspect
;-) -- there are many unreal programmers on this planet.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Memory management strategies.

[Rainer Weikusat]

KatolaZ  writes:
> On Mon, Feb 01, 2016 at 05:36:38PM +0100, Didier Kryn wrote:
>
> [cut]
>
>> 
>> Note that if you manage your memory pool as an array then
>> allocation and deallocation are extremely fast and can be done
>> without consuming a single byte for book-keeping. I think this
>> almost trivial allocator actually fits with many cases. It can even
>> make sense to loose part of the memory if objects haven't all the
>> same size, provided this size is bounded.
>> 
>
> If you know in advance the typical sizes of chunks to be allocated,
> then reserving different sections of your array to chunks of different
> sizes can be quite efficient, and helps limiting external
> fragmenttion. This was more or less the strategy actually implemented
> in the original slab allocator of the Linux kernel, and might work
> decently.

The original slab allocator was implemented by Jeff Bonwick for the
SunOS kernel (5, not 4) and it decidedly didn't work in this way. It
used type-segregated, linked free lists and was based on some kind of
underlying 'page allocator'. This can be used to limit internal
fragmentation (memory lost due to bookkeeping overhead) and it's a good,
generally scheme for dealin with many types of objects of discrete sizes
but it's totally powerless agains external fragmention, ie, memory
consumed by inactive objects of a certain kind which can't be reused
because the inactive objects are interspersed with active ones.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] systemd is haunting me

[Simon Wise]

On 02/02/16 01:58, Didier Kryn wrote:

Le 01/02/2016 14:13, Simon Hobson a écrit :

Florian Zieboll  wrote:


For the fun of it, I just ran an "apt-get install --install-recommends
--no-install-recommends" and it chose to not install the recommends.
The same with contradicting lines in apt.conf(.d/*):

APT::Install-Recommends "0";
APT::Install-Recommends "1";

This will install the recommends, the other way around it won't.
Apparently there's still some behavior left in modern Linux that is
coherent with an autistic mindset, hahaha.

Makes sense to me too - first entry sets/resets option, next entry resets/sets
the same option - the last one taking effect.


As with any of these newish "*.d/" folders, you can just

$ cat apt.conf.d/* > apt.conf && rm -r apt.conf.d/

without any consequences regarding the configuration. AFAIU this is all
about easier deployment (and automated removal) of configurations - like
hitting some button on a shady website to add distribution independent
repositories to the sources.list.

More to the point, it means (in the general case) a number of packages can
add/remove their own configs during package install/upgrade/removal just by
adding/updating/removing "it's" config file from the conf.d directory. For
another example, when installing Xen, it adds a file to Grub's conf.d to add
the Xen boot options. Same with various web packages that put a file in
/etc/apache2/conf.d.

IMO it's far better than trying to come up with some mechanism to *SAFELY*
edit a shared config file.

It also means the user/admin can add their own config file, and if they name
it to sort last then they can override any other default settings - but
without impacting on the ability of a package to update it's own file. Once
you get into editing the package supplied config file then upgrading gets a
bit less automatic.

So overall I think this is "a good thing" - even though it does have one or
two downsides.


very much so, on both counts. The only two alternatives are a README telling the 
user to go and edit certain files before using the package ... unpopular and not 
appropriate for many use cases, or introduce a centralised API that holds all 
usual configurations in a database and provides standard tools to read and 
modify it. This was the Microsoft registry solution, it is also the Gnome 
solution. It is much more problematic in my view. And requires the kind of API 
standardisation that devuan rejects.


An explicit advantage of multi files over an attempt to make a single point of 
configuration via an API is the network manager in gnome. Using the GUI will 
edit the files you would otherwise use for the setting. This will often undo 
carefully established manual settings. These manual settings are needed even if 
you prefer the GUI because the GUI only provides the way to set up commonly 
needed network stuff. So if your network is uncommon you had better purge the 
GUI since it will not understand or respect the weird settings you need. If you 
have the dedication to GUI and the resources of a global mega-corporation it is 
possible to make a similar GUI actually respect the under-lying settings ... but 
it is incredibly hard work, way beyond almost any organisation. OSX did achieve 
this (I do not know if they kept it though), but with unthinkable hours of 
developer time I am sure, it was years of effort even for them.






I fully agree that "this is a good thing". There remains one question:

On my laptop the file 99synaptic contains only one line:
APT::Install-Recommends "false";

If all the files are read by all apt tools, then the setting meant for synaptic
applies to all apt tools. If i'd purge synaptic, then the behaviour of apt-get
might change. Does it make sense? It seems to me that this file should contain
some indication tnat the setting applies only to synaptic.


it is in the apt configuration, it changes apt behaviour, it is in no way 
limited to synaptic, it is some change that the synaptic package felt was needed 
different from default settings ... I do not know synaptic but perhaps it deals 
with recommended in its own way and thus needed to tell apt-get not to do it. 
The name of the file indicates that this is an apt configuration added by the 
synaptic package. Many packages are more polite and do include comments in their 
files, where comments are allowed at that point in the .conf file of course!


Synaptic and the direct apt tools both use the same back-end, Synaptic makes the 
assumption that it will replace apt-get for the user so sets apt up to suit 
usage via Synaptic. It cannot really make any other assumptions, and certainly 
should undo those modifications if it is removed. And the whole arrangement is a 
lot!! less error prone than if it attempted to edit an apt.conf file each time. 
With more effort Synaptic could perhaps leave apt settings untouched, but they 
assume they are providing the new, improved GUI front end and for most of 

Re: [DNG] systemd is haunting me

[Simon Wise]

On 01/02/16 22:47, Didier Kryn wrote:

Le 01/02/2016 12:09, Florian Zieboll a écrit :

florian@nulldevice:~$ cat /etc/apt/apt.conf.d/01norecommend
APT::Install-Recommends "0";
APT::Install-Suggests "0";
#APT::AutoRemove::RecommendsImportant "0";

Synaptic will override this setting, if the relevant option is checked.


Apparently synaptic keeps its config in its own config file
/etc/apt/apt.conf.d/99synaptic. Do you mean synaptic reads all config files in
order, and since 99synaptic is the last, it can override all previous settings?
I must confess I don't understand how this set of config files is processed;
there are quite a lot of files in etc/apt/apt.conf.d/. There's a man for
apt.conf, which doesn't exist and no man for apt.conf.d, which exists!



the command tool for finding relevant man pages on your system is apropos ...

$ apropos apt



apt (1)  - annotation processing tool
apt (8)  - Advanced Package Tool
apt-cache (8)- query the APT cache
apt-cdrom (8)- APT CD-ROM management utility
apt-config (8)   - APT Configuration Query program
apt-extracttemplates (1) - Utility to extract debconf config and tem...
apt-file (1) - APT package searching utility - command-line ...
apt-forktracer (8)   - a utility for managing package versions
apt-ftparchive (1)   - Utility to generate index files
apt-get (8)  - APT package handling utility - - command-line...
apt-key (8)  - APT key management utility
apt-listbugs (1) - Lists critical bugs before each apt upgrade/i...
apt-mark (8) - mark/unmark a package as being automatically-...
apt-move (8) - move cache of Debian packages into a mirror h...
apt-offline (8)  - Offline APT Package manager
apt-secure (8)   - Archive authentication support for APT
apt-show-versions (1p) - Lists available package versions with distr...
apt-sortpkgs (1) - Utility to sort package index files
apt-zip (8)  - Use apt with removable media
apt-zip-inst (8) - Use apt with removable media
apt-zip-list (8) - Use apt with removable media
apt.conf (5) - Configuration file for APT
apt_preferences (5)  - Preference control file for APT



so looking at apt.conf I see as the very first text 'DESCRIPTION'

/etc/apt/apt.conf is the main configuration file shared by all
   the tools in the APT suite of tools, though it is by no means
   the only place options can be set. The suite also shares a
   common command line parser to provide a uniform environment.

   When an APT tool starts up it will read the configuration
   files in the following order:

1. the file specified by the APT_CONFIG environment variable
   (if any)

2. all files in Dir::Etc::Parts in alphanumeric ascending
   order which have either no or "conf" as filename extension
   and which only contain alphanumeric, hyphen (-),
   underscore (_) and period (.) characters. Otherwise APT
   will print a notice that it has ignored a file, unless
   that file matches a pattern in the
   Dir::Ignore-Files-Silently configuration list - in which
   case it will be silently ignored.

3. the main configuration file specified by Dir::Etc::main

4. the command line options are applied to override the
   configuration directives or to load even more
   configuration files.


Dir::Etc::Parts is in fact apt.conf.d/

as seen by going to the FILES section at the end of the manpage, either with a 
search for Dir::Etc::Parts or because you know a FILES section usually exists:


FILES
   /etc/apt/apt.conf
   APT configuration file. Configuration Item:
   Dir::Etc::Main.

   /etc/apt/apt.conf.d/
   APT configuration file fragments. Configuration Item:
   Dir::Etc::Parts.



so certainly finding this out does require a little familiarity with the linux 
documentation system, but it is all there and in exactly the discoverable 
places. There is a lot of information available, tool tips or a few help 
paragraphs could not come close to providing it. That is why very simplified GUI 
configurations eliminating all the uncommon settings are so popular.


Simon

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] systemd is haunting me

[Florian Zieboll]

On Mon, 1 Feb 2016 13:13:43 +
Simon Hobson  wrote:

> Florian Zieboll  wrote:
> 
> > As with any of these newish "*.d/" folders, you can just
> > 
> >  $ cat apt.conf.d/* > apt.conf && rm -r apt.conf.d/ 
> > 
> > without any consequences regarding the configuration. AFAIU this is
> > all about easier deployment (and automated removal) of
> > configurations - like hitting some button on a shady website to add
> > distribution independent repositories to the sources.list. 
> >
> > (...)
> 
> So overall I think this is "a good thing" - even though it does have
> one or two downsides.

Don't get me wrong, I didn't want to say that it's a "bad thing" - just
give an (perhaps somewhat polemic) example of its practical usage :)
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] systemd is haunting me

[Didier Kryn]

Le 01/02/2016 14:13, Simon Hobson a écrit :

Florian Zieboll  wrote:


For the fun of it, I just ran an "apt-get install --install-recommends
--no-install-recommends" and it chose to not install the recommends.
The same with contradicting lines in apt.conf(.d/*):

  APT::Install-Recommends "0";
  APT::Install-Recommends "1";

This will install the recommends, the other way around it won't.
Apparently there's still some behavior left in modern Linux that is
coherent with an autistic mindset, hahaha.

Makes sense to me too - first entry sets/resets option, next entry resets/sets 
the same option - the last one taking effect.


As with any of these newish "*.d/" folders, you can just

  $ cat apt.conf.d/* > apt.conf && rm -r apt.conf.d/

without any consequences regarding the configuration. AFAIU this is all
about easier deployment (and automated removal) of configurations - like
hitting some button on a shady website to add distribution independent
repositories to the sources.list.

More to the point, it means (in the general case) a number of packages can add/remove 
their own configs during package install/upgrade/removal just by adding/updating/removing 
"it's" config file from the conf.d directory. For another example, when 
installing Xen, it adds a file to Grub's conf.d to add the Xen boot options. Same with 
various web packages that put a file in /etc/apache2/conf.d.

IMO it's far better than trying to come up with some mechanism to *SAFELY* edit 
a shared config file.

It also means the user/admin can add their own config file, and if they name it 
to sort last then they can override any other default settings - but without 
impacting on the ability of a package to update it's own file. Once you get 
into editing the package supplied config file then upgrading gets a bit less 
automatic.

So overall I think this is "a good thing" - even though it does have one or two 
downsides.



I fully agree that "this is a good thing". There remains one question:

On my laptop the file 99synaptic contains only one line:
APT::Install-Recommends "false";

If all the files are read by all apt tools, then the setting meant 
for synaptic applies to all apt tools. If i'd purge synaptic, then the 
behaviour of apt-get might change. Does it make sense? It seems to me 
that this file should contain some indication tnat the setting applies 
only to synaptic.


Didier

Didier


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Memory management strategies.

[Didier Kryn]

Le 01/02/2016 17:16, Rainer Weikusat a écrit :

Rainer Weikusat  writes:

[...]


A more problematic (for some definition of problematic) situation is
when there are many objects of different sizes and if objects whose
size is identical have vastly differing lifetimes. This introduces
so-called 'external fragmentation' into the malloc heap

Additional information: The usual 'household number' associated with
that would be that an allocator is considered memory efficient if not
more than 50% of the memory managed by it is effectively lost due to
external fragementation.


Note that if you manage your memory pool as an array then 
allocation and deallocation are extremely fast and can be done without 
consuming a single byte for book-keeping. I think this almost trivial 
allocator actually fits with many cases. It can even make sense to loose 
part of the memory if objects haven't all the same size, provided this 
size is bounded.


Didier

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Memory management strategies.

[KatolaZ]

On Mon, Feb 01, 2016 at 05:36:38PM +0100, Didier Kryn wrote:

[cut]

> 
> Note that if you manage your memory pool as an array then
> allocation and deallocation are extremely fast and can be done
> without consuming a single byte for book-keeping. I think this
> almost trivial allocator actually fits with many cases. It can even
> make sense to loose part of the memory if objects haven't all the
> same size, provided this size is bounded.
> 

If you know in advance the typical sizes of chunks to be allocated,
then reserving different sections of your array to chunks of different
sizes can be quite efficient, and helps limiting external
fragmenttion. This was more or less the strategy actually implemented
in the original slab allocator of the Linux kernel, and might work
decently.

My2Cents

KatolaZ

-- 
[ Enzo Nicosia aka KatolaZ --- GLUG Catania -- Freaknet Medialab ]
[ me [at] katolaz.homeunix.net -- http://katolaz.homeunix.net -- ]
[ GNU/Linux User:#325780/ICQ UIN: #258332181/GPG key ID 0B5F062F ]
[ Fingerprint: 8E59 D6AA 445E FDB4 A153 3D5A 5F20 B3AE 0B5F 062F ]
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng